Firefox does not recognise tarball XPI

[WhyNotHugo]

Have you searched for an existing issue?

• [x] Yes, I tried searching and reviewed the pinned issues

Brief Summary

Firefox does not recognise the tarball generated when placed into /usr/lib/firefox/browser/extensions/. It properly recognises zipballs, or the raw contents of the tarball unpacked into this location.

Expected Versus Actual Behavior

Build system produces a tarball as XPI which Firefox does not recognise.

Steps to Reproduce

npm ci
npm run build

KeePassXC-Browser Debug Information

n/a

[WhyNotHugo]

4016f42734decf1cece314c01be48890b876effe switched from packaging the plugin as a zipball to packaging it as a tarball. I suspect this may be the culprit, but I'm not 100% sure.

• 1.8.9 was known to work fine
• 1.9.7 produces a tarball that does not work

Testing on firefox-141.0-r0

[varjolintu]

Hmm. The -a option in tar should recognize the .zip at the end of the filename and compress it as a normal Zip archive.

[WhyNotHugo]

I believe this only applies when decompressing?

Doesn't work with GNU tar:

> tar -acf test.zip x
> file test.zip
test.zip: POSIX tar archive (GNU)
> tar --version
tar (GNU tar) 1.35

Nor with busybox tar:

> busybox tar -acf test.zip x 
> file test.zip
test.zip: POSIX tar archive (GNU)

BSD tar doesn't have a -a flag.

[varjolintu]

Maybe I need to introduce some exceptions with certain operating systems that have different tar versions available.

[droidmonkey]

Im surprised this would work anywhere. ZIP is a special format and is not tar'd first. You would need to directly call zip program directly.

https://www.geeksforgeeks.org/linux-unix/zip-command-in-linux-with-examples/#

https://www.gnu.org/software/tar/manual/html_node/gzip.html

Scroll down to the -a section, it lists what is compatible

[varjolintu]

Not sure if zip command is automatically available in operating systems either. tar is more widely supported (even in Windows), but I was not aware that some BSD systems or GNU tar doesn't support the zip format. I tested that particular commit with just Windows 10/11, macOS and Linux.

[WhyNotHugo]

Perhaps deterministic-zip is a reasonable dependency.

Aside from fixing the issue at hand, it'll make builds reproducible, a nice addition for such a security-sensitive tool.

The source is mostly self-contained in a single file.

[varjolintu]

Quickly testing that library doesn't seem to produce a zip file I can uncompress directly in macOS.

Looking at the file via zipinfo shows strange stuff:

-rw----     0.0 fat     6453 bl defN 80-Jan-01 12:01 popups/popup.html
-rw----     0.0 fat     5067 bl defN 80-Jan-01 12:01 popups/popup.js

Compared to a "normal" compression:

-rw-r--r--  2.0 unx     2587 bX defN 25-Aug-06 08:59 popups/popup_login.html
-rw-r--r--  2.0 unx     5067 bX defN 25-Aug-06 08:59 popups/popup.js

I think it's best to use https://www.npmjs.com/package/adm-zip instead.

[varjolintu]

I have been giving this some thought. Zipping the sources is a crucial part of our release process, and concerning possible attack vectors I'm not really in favor for adding dependency for any library, even if it dismisses reproducible builds. I'd rather rely on OS level binaries for zipping. So with BSDs we'd have to find some other solution than tar.

[WhyNotHugo]

BSD and Linux (both musl and gnu) don’t support this custom flag for tar.

We can use zip if it is available and tar -a as a fallback. Would this cover all cases?

The only risk is that a manual build on systems without zip may still fail (depending on which tar is available), but for downstream pipelines with declared dependencies that won’t be an issue.