\cc @XilaiZhang this will impact codesigning in two different parts: identifying if the file requires signing and also on the signing tool detecting if it needs to unzip twice.

\cc @XilaiZhang this will impact codesigning in two different parts: identifying if the file requires signing and also on the signing tool detecting if it needs to unzip twice.

thanks for the info! Yeah I think the current topology covers this case.

based on the insights from flutter/flutter#124322 (comment) we would skip signing this file since it is debug symbols and not executables. On the signing tool side, this file will be skipped since if no signing metadata is found upon the first unzip, the file will be skipped.

\cc @XilaiZhang this will impact codesigning in two different parts: identifying if the file requires signing and also on the signing tool detecting if it needs to unzip twice.

thanks for the info! Yeah I think the current topology covers this case.

based on the insights from flutter/flutter#124322 (comment) we would skip signing this file since it is debug symbols and not executables. On the signing tool side, this file will be skipped since if no signing metadata is found upon the first unzip, the file will be skipped.

This also applies to FlutterMacOS.framework.zip and any other potential double zipped artifacts.

\cc @XilaiZhang this will impact codesigning in two different parts: identifying if the file requires signing and also on the signing tool detecting if it needs to unzip twice.

thanks for the info! Yeah I think the current topology covers this case.

based on the insights from flutter/flutter#124322 (comment) we would skip signing this file since it is debug symbols and not executables. On the signing tool side, this file will be skipped since if no signing metadata is found upon the first unzip, the file will be skipped.

This is covered at the recipes level: https://flutter-review.googlesource.com/c/recipes/+/42560

Thanks for explaining! I added the changes needed for codesign metadata in comments.

I tested the correctness of the new change by downloading the artifacts built from bab6f0e engine v2 bucket, and run codesign locally on it.

ACK

\cc @XilaiZhang this will impact codesigning in two different parts: identifying if the file requires signing and also on the signing tool detecting if it needs to unzip twice.

thanks for the info! Yeah I think the current topology covers this case.
based on the insights from flutter/flutter#124322 (comment) we would skip signing this file since it is debug symbols and not executables. On the signing tool side, this file will be skipped since if no signing metadata is found upon the first unzip, the file will be skipped.

This is covered at the recipes level: https://flutter-review.googlesource.com/c/recipes/+/42560

Umm I left a comment in recipe. Sorry if I misunderstood, umm I think in the recipe we are requiring the zip to be codesigned, but we are supplying empty configs. My understanding is that the codesign tool might detect the binary in the zip and report a failure due to the empty config. Or maybe we are planning to add more commits in this pr

\cc @XilaiZhang this will impact codesigning in two different parts: identifying if the file requires signing and also on the signing tool detecting if it needs to unzip twice.

thanks for the info! Yeah I think the current topology covers this case.
based on the insights from flutter/flutter#124322 (comment) we would skip signing this file since it is debug symbols and not executables. On the signing tool side, this file will be skipped since if no signing metadata is found upon the first unzip, the file will be skipped.

This is covered at the recipes level: https://flutter-review.googlesource.com/c/recipes/+/42560

Umm I left a comment in recipe. Sorry if I misunderstood, umm I think in the recipe we are requiring the zip to be codesigned, but we are supplying empty configs. My understanding is that the codesign tool might detect the binary in the zip and report a failure due to the empty config. Or maybe we are planning to add more commits in this pr

Details:

• The double zip behavior is temporary, ~couple of weeks until it is fixed.
• Having the inner zip with the correct structure(metadata with correct paths) would have been the easiest way to remove the outer zip, preventing additional disruption when the outer zip is removed.

@XilaiZhang implemented your suggestions and added to TODOs to follow up when removing the outer zip folders.

@christopherfujino @jmagman any concerns about adding the double zip logic to the dsym artifact?

any concerns about adding the double zip logic to the dsym artifact?

I don't think the tool knows anything about the dSYM artifact, I don't think it downloads it at all. Users manually download it https://github.com/flutter/flutter/wiki/Crashes (and macOS isn't mentioned). Was that artifact actually causing issues somewhere? (I know the .framework was flutter/flutter#124911 (comment)).

any concerns about adding the double zip logic to the dsym artifact?

I don't think the tool knows anything about the dSYM artifact, I don't think it downloads it at all. Users manually download it https://github.com/flutter/flutter/wiki/Crashes (and macOS isn't mentioned). Was that artifact actually causing issues somewhere? (I know the .framework was flutter/flutter#124911 (comment)).

It was not causing any issues but when checking all the artifacts I found the legacy dsym artifact is double zipped. I'm trying to get all the artifacts generated by engine v2 aligned with the legacy artifacts to avoid new disruptions during the migration.