Error "Lowest supported "strict_min_version" is 58.0"

Add-ons addons.mozilla.org
#1

Hello, I have a number of API calls which are each protected by a test on the FF version in my add-on code, so that I can support down to “strict_min_version”: “56.0”.
Some of my users are still on FF 56 …

In the past submits, and until now, that resulted in a warning on the AMO “Submit a New Version” page (and 53 detailed warnings in the report, all related to that).

Now, the detailed report is the same, but the “Submit a New Version” gives me the error

" Your add-on failed validation with 1 error.

  • Lowest supported “strict_min_version” is 58.0."

and I cannot submit anymore.

How can I continue to support all versions down to 56.0 with this new behavior of the add-on validation page ?

(for now, I am raising to 58.0 to be able to submit my latest version, but this will penalize my 56.0 users :frowning: )

#2

And here I am, the exact opposite, waiting for the new Firefox ESR to be released each October so that I can move the strict_min_version to latest ESR, and use all the new features that were released for the past year! :slight_smile:

For example, this October, I’m looking forward to use Popover API and groupBy!

Anyway, I don’t think it’s a good idea to support unsupported browsers, which are full of known security holes. One wrong click on the google search page and your PC is infected!

Now, regarding the problem you are having, there may be one solution - you can change the min-version also after the submission!
Like this:

image
image1813×936 141 KB

Click the “Manage Status and Versions”, then click the specific version and then change the version in the Compatibility section.

2 Likes
#3

Or maybe just omit the key from manifest.json. I don’t think it is required?

1 Like
#4

Yes, that works, thank you !
Well, agree with you, but it is not my choice to use an old version … this is the choice of my users, and I am not going to impose anything to others, I simply try to respect their views / choice.

#5

It looks like the FF 58 requirement was added because AMO has retired the use of SHA-1. This algorithm was previously for signature verification purposes. Basically, AMO signs an XPI so that Firefox (or other tools) can verify that the file has not been modified since AMO signed it. Add-ons are now signed with PKCS7 SHA256 and COSE ES256, which is only available in Firefox 58 and above.

EDIT: When I first came to this thread I also thought @stig’s suggestion would work, but I’m pretty sure that this signing change means that even if you remove the minimum version field from the manifest, users on older browsers will encounter an error when attempting to install that version. That may be worse overall for those users than keeping the minimum version flag and preventing updates from reaching them.

I empathize with your desire to keep your add-on working for as many users as possible. While I would strongly encourage these users to update to a newer versions of Firefox due to a plethora of security issues with old web browsers, it’s ultimately their choice to stick with 56.

If you want to go the extra mile for these users, I see two options:

  1. Make an unsigned, non-updating version of the add-on available on your (project’s) website.
  2. Self host and distribute a version that can automatically update itself. If you go this route, you’ll need to make sure that you properly configure and host an update manifest for your add-on.
3 Likes
#6

… but I’m pretty sure that this signing change means that even if you remove the minimum version field from the manifest, users on older browsers will encounter an error when attempting to install that version. That may be worse overall for those users than keeping the minimum version flag and preventing updates from reaching them.

Agree with you that if signing is the issue, then there is no point in playing with that paremeter …
This https://bugzilla.mozilla.org/show_bug.cgi?id=1180826 confirms that SHA256 was introduced as part of FF58.
I couldn’t find anything saying that SHA-1 signing was retired on AMO, do you have a pointer at something along that line that you could share ?

Thank you much for the detailed answer.

#7

I believe this change was indirectly referenced in the Firefox 128.0 and ESR 115.13.0, which both contain the following line:

The root certificate used to verify add-ons and signed content has been renewed to avoid upcoming expiration.

#8

However, if I look at the .xpi of my add-on which was generated yesterday, I still see SHA1 inside:

Name: changeLog.txt
Digest-Algorithms: SHA1 SHA256
SHA1-Digest: i7yHGzaG9CLfs4E2n3M0XID1wig=
SHA256-Digest: kRigRm6XM8SVPQy/DQftTzxo2xym5kIKQdlFkhbOHro=
#9

I should say up top that I’m not an encryption expert so I’m not 100% confident I have all the details right here. This is a best effort response.

@aaFn, I think you’re looking at the META-INF/manifest.mf or a similar file. AFAIK those digests come from the JAR format on which XPI is based. Those digests are for the contents of the packaged files for content verification purposes, not the signature of the package itself.

If you want to see how the package was signed, you’ll need to use a specialized tool like xpidump or openssl to extract information about signature. The two relevant files here are META-INF/mozilla.rsa and META-INF/cose.sig. You can use openssl to get information about algorithm used for the PKCS7 signature as follows:

openssl pkcs7 -inform der -in META-INF/mozilla.rsa -text -print | grep md_algs -A 1

It doesn’t look like there are standard tools to extract information about COSE signatures (or at least I haven’t found them), so in that case your best bet is to use xpidump for that.