Comparing contents or the archive is actually a pretty tricky tradeoff. Comparing contents is very vulnerable to parser misalignment but the archive might have timestamps or signatures that are hard to replicate. The 4KiB part is just going to be a great post (about Telegram I guess?) - ThreadSky

filippo.abyssdomain.expert • 38 days ago

Comparing contents or the archive is actually a pretty tricky tradeoff. Comparing contents is very vulnerable to parser misalignment but the archive might have timestamps or signatures that are hard to replicate.

The 4KiB part is just going to be a great post (about Telegram I guess?)

Comments

matthewdgreen.bsky.social•38 days ago

Yep. I want to collect all 10,000 issues we had and put them down in one post (written by the student) but this stuff is alarming.

retr0.id•38 days ago

if it were me I'd definitely write my own deterministic archiver (assuming they don't already exist)

matthewdgreen.bsky.social•38 days ago

I was expecting the output of this would be an APK that I could just hash and compare to the one in the Play Store.

I’m sort of reluctantly willing to accept that this isn’t possible, maybe. But I really don’t like the way their diff tool works.

retr0.id•38 days ago

yeah to be clear I mean, if I was the one producing the apk in the first place. trying to ascertain equivalence of two apks sounds like an absolute nightmare - apk/zip is a really poorly specced format imho (which is why weird parsing bugs are common)

retr0.id•38 days ago

but I suppose, you could take both apks, unpack them, deterministically repack both, and compare the resulting files

natanael.bsky.social•38 days ago

That will cover embedded files not not zip metadata influenced app behavior.

Honestly I'd just zero out all timestamps them check if they're identical

lberrymage.dev•37 days ago

This. If the purpose is verifying reproducible builds, I'd be extremely careful about trusting the archive metadata and assuming Python archive parsing behavior is consistent with Android's (i.e. I wouldn't). That assumption has bitten too many people before.

natanael.bsky.social•38 days ago

Honestly if you're going all for new tools for deterministic reproducible builds, I'd define deterministic packing tools including sigs, define exactly what metadata differences are tolerated and how to "normalize" on comparison, and maybe even throw in a VRF tag last to block all zip manipulation

opliko.dev•38 days ago

It was an issue in Telegram's https://apkdiff.py but it was fixed in 2020: https://github.com/DrKLO/Telegram/pull/1545

opliko.dev•38 days ago

Hmm... Actually it seems it was only properly fixed in 2023 - before then you could add anything after the entire first file and it wouldn't find the difference.

In the argument order from docs (https://core.telegram.org/reproducible-builds) it would catch code added to the store app, but not code removed...

opliko.dev•38 days ago

(this commit fixed it finally: https://github.com/TelegramOrg/Telegram-Android/commit/2628a581478f1a30197ed0fc37165b17a3c97c98#diff-52e8eacd44edcc08bb5ed26b304c63a75a6bfd49056fb6c71a5b4a14d7659ffc)

matthewdgreen.bsky.social•38 days ago

It still seems to be there in the current code we pulled from the site. But this is very helpful!

Have you gotten the repro builds to actually work? My student is struggling with tooling problems.

matthewdgreen.bsky.social•38 days ago

Sorry when I say “current code” what I mean is: the latest release that supports repro builds. Which is two point releases off from what’s in the store. (I think 11.4 something vs 11.6 latest.)

Maybe if I pull from master we’ll also get the latest? We’re trying to follow the instructions though.

matthewdgreen.bsky.social•38 days ago

Also am I being dense about this commit?

Comments

Posting Rules

Reply