Help build the last independent browser.
13
Replies
0
Boosts
https://wiki.mozilla.org/Software_Update:MAR
THEY FUCKING RIPPED OFF THE ZIP FILE FORMAT
Why not use ZIP or some other standard file format?
This question was given a fair amount of consideration. Ultimately, we decided to go with a custom file format because using
libjarwould have required a fair bit of hacking.
that's why you don't use "libjar", which is for java programs, but the rust zip crate that I FUCKING BUILT
Writing custom code was a simpler option, and it resulted in less code (mar_read.c is less than 300 lines of code).
that's so much more than the examples in https://docs.rs/zip
Moreover, the update system does not need a standard file format.
yeah, it needs a bullshit one
@hipsterelectron it worked for Quake2 let them cook??
/s
https://firefox-source-docs.mozilla.org/tools/update-verify/index.html
Update verify is test that runs before each Firefox Release (excluding Nightlies) are shipped. Its main purpose is to ensure that users who receive the release through an update MAR (Mozilla ARchive) end up in the same place as a fresh install would get them. This helps us to ensure that partial MARs work in future updates, and that code signatures are valid regardless of how a user arrived at a new version.
not something that requires a standard format
the only diff they added since 2015 is wrong https://wiki.mozilla.org/index.php?title=Software_Update%3AMAR&type=revision&diff=1197510&oldid=1100385
2: RSA-PKCS1-SHA384 (4096 bits / 512 bytes)
the fact that SHA-384 makes use of the same 512-byte block as SHA-512 is a fun fact at best and not remotely correct when presented in this fashion
The elements stored in the archive are
bzip2compressed binary diffs, generated using a variation of bsdiff. So, being able to unpack the archive file using standard tools wouldn't be very useful in and of itself.
https://docs.rs/zip/latest/zip/read/struct.ZipArchive.html#method.by_index_raw
we have a method for that actually
anyway the .sig files they provided are not valid signature data. i have no clue what they are
but more importantlly i have no way to check their fucking .asc signature because I CAN'T FUCKING FIND THEIR PUBLIC KEY ANYWHERE ON THEIR ENTIRE FUCKING WEBSITE
gpg: assuming signed data in 'firefox-157.0a1.en-US.linux-x86_64.tar.xz'
gpg: Signature made Thu 03 Sep 2026 07:53:43 PM EDT
gpg: using RSA key 827E658608679618CD349F93678E455D76767AA3
gpg: Can't check signature: No public key
can't we just run `gpg --recv-keys 827E658608679618CD349F93678E455D76767AA3` here?
(probably a dumb question)
@calx absolutely right! i currently have mine set to use keys.openpgp.org (the upstream default pulls from fucking ubuntu packager keyservers for some reason), although they are very clearly a faction of the IETF NSA fuckboy contingent: https://keys.openpgp.org/about/faq/
Why is there no support for identities that aren't email addresses?
We require explicit consent to distribute identity information. Identities that aren't email addresses, such as pictures or website URLs, offer no simple way for us to acquire this consent.
a randomly-generated cryptographic keypair alone provides the strongest possible notion of consent! they don't even do the basic shit that every darknet market and even darknet forums are now requiring users to do, which is to generate some random challenge and sign it with the public key, and simply refuse to accept any declared keypair without a successful challenge response
the weaponization of "consent" here did genuinely shock and appall me the first time i read it, but it's just a really tired trope to me at this poiint. the reason they need an email address is so they can surveil who the key belongs to! it's literally just that
@calx more specifically to this problem:
the reason i was able to identify arch linux blatantly backdooring the emacs PKGBUILD was because i could independently confirm that the key fingerprint they copied over to a subdir of the build dir (https://gitlab.archlinux.org/archlinux/packaging/packages/emacs/-/blob/main/PKGBUILD?ref_type=heads) corresponded to eli zaretskii's 4096-bit RSA key
@calx unfortunately, i spent the last 23 minutes finding so much fucking bullshit you wouldn't fucking believe
@calx exactly as you described, a fingerprint of a public key should be sufficient proof, given some other assumptions--in particular, firefox didn't specify how we know to trust and verify their key material!
compare for example to yubico (https://circumstances.run/@hipsterelectron/116336526842775057), who actually does two things exactly right here! [even though i clown on them in that thread a lot lol]
@calx see https://developers.yubico.com/yubikey-manager/Releases/
Below is a list of all available downloads ordered by version, starting with the most recent version.
Releases are signed using the keys listed here.
and in particular this page here https://developers.yubico.com/Software_Projects/Software_Signing.html is actually one of the most well-done example of how "trust" and "integrity" is SO much more than just using a "cryptographic" checksum/signature. you have to describe your own structure of internal trust if you want anyone else to rely on you
