Fix 738 log addon version

[g-k]

fix #738

Changes:

• rename test vars PASSINGTESTCASES to validSignerConfigs and FAILINGTESTCASES to invalidSignerConfigs to avoid confusion with other vars named testcases
• use go embed directives (1.16+) https://pkg.go.dev/embed to remove bytestrings from source files and expose the files for other tools to inspect (e.g. unzip -l)
  • add .zip to the omni.ja files so zip tools recognize them as zips
• test sign file against the ublock and omni.ja fixtures
• run TestSign{Data,File} test cases in parallel saved ~6s on local testing of the package
• log the addon manifest.json top-level version field and .browser_specific_settings.gecko.id field using
  • extractGeckoIDAndVersionFromWebextManifest, which assumes the version field is a string per the MDN docs. This was the laziest option to fix log signed XPI or addon version number #738 since it doesn't modify the repack func return values or the sign file interface.

[coveralls]

Pull Request Test Coverage Report for Build 7222

• 27 of 32 (84.38%) changed or added relevant lines in 1 file are covered.
• 18 unchanged lines in 2 files lost coverage.
• Overall coverage decreased (-0.3%) to 71.212%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
signer/xpi/jar.go	27	32	84.38%

Files with Coverage Reduction	New Missed Lines	%
signer/xpi/xpi.go	5	80.0%
signer/xpi/x509.go	13	74.85%

Totals
Change from base Build 7212:	-0.3%
Covered Lines:	3243
Relevant Lines:	4554

---

💛 - Coveralls

[willdurand]

I think applications is an alias for browser_specific_settings. In addition, this prop is optional.

Is it OK to not log the add-on ID all the time?

[willdurand]

Some more information:

1. the version should be mandatory
2. the GUID (same value as the Gecko ID) is somehow inserted in the signature of a signed XPI so I suppose there is a way to always get the GUI somewhere?

[g-k]

I think applications is an alias for browser_specific_settings. In addition, this prop is optional.

TIL! I didn't see that key on MDN or in the webext spec, but these pages suggest Fx <48 required it:

• https://stackoverflow.com/questions/37127330/unrecognized-manifest-key-applications-warning-for-google-chrome
• https://support.mozilla.org/en-US/questions/1217302

so it probably predates standardization and we might have to sign addons with that key.

Is it OK to not log the add-on ID all the time?

Yes, I have a few test cases for partial matches and XPIs signed in other modes (privileged, hotfix, etc.) probably won't include the an ID or might use the other key.

8b4f491 adds test cases for:

• a manifest with applications set to an empty obj
• a manifest with applications.gecko set to an empty obj
• a manifest with applications.gecko.id set to an empty str
• a manifest with applications.gecko.id set to an addon ID
• a manifest with a version and both IDs set (in which case we'll prefer the browser settings ID)

Once we have some logs, I'll try to confirm we can correlate them with signed addons. If not, we might need pass the data out to the "signing operation succeeded" lines.

[g-k]

Some more information:

1. the `version` should be mandatory

Hmm, extractAddonIDAndVersionFromWebextManifest could return an error and we could log it as a warning instead of info level.

If other XPI types that don't include a manifest, we won't log warnings. If they do, we might log some extra warnings but that'd be fine.

2. the GUID (same value as the Gecko ID) is somehow inserted in the signature of a signed XPI so I suppose there is a way to _always_ get the GUI somewhere?

Does addons-server generate that and send it as Options.ID?

[willdurand]

Does addons-server generate that and send it as Options.ID?

I think so, yes: https://github.com/mozilla/addons-server/blob/80f526e84084a776f9f379301e11250202f9a8ab/src/olympia/lib/crypto/signing.py#L77

[willdurand]

r+wc

[willdurand]

addons-linter won't accept a manifest with the two props but it's good to be defensive here.

[g-k]

Thanks Will!

Follow up items from comments and original issue:

• return parsed ID and version to SignFile in xpi
  • log parsed ID and version with the "signing operation succeeded" lines instead of from the repacking code
  • when signing in mode ModeAddOn and ModeAddOnWithRecommendation check the lints:
    • warn for a missing manifest.json file
    • warn for multiple IDs: applications.gecko.id and browser_specific_settings.gecko.id
    • warn for manifest ID not matching request Options.ID
    • warn for a missing version

Warnings return errors if we want to do more linting in autograph and other web extension signers pass for legitimate uses.