Recent searches
Search options
Administered by:
We're starting a sprint to look at all the issues preventing #ReproducibleBuilds in all the apps we ship. Most of the issues are simple fixes in the upstream code, like unsorted outputs or timestamps included in the build.
You can help make the #FreeSoftware #Android ecosystem be more reproducible! See the failures here and help us report them upstream: https://verification.f-droid.org/failed.html
@fdroidorg F-Droid Basic is not reproduceable >:{
@voxel @fdroidorg It is now. v1.20.0 and newer are all reproducible, for example: https://verification.f-droid.org/org.fdroid.basic_1020050.apk.json
The "failed" page only shows failures since we are highlighting those to fix them. Check the JSON API for the full history, e.g. https://verification.f-droid.org/org.fdroid.basic.json
@captainepoch, is the current version of @husky in mainline @fdroidorg? I see su.xash.husky 1.2.2's build failing to reproduce but that was released mid-2022 (sorry don't remember when you started to take over the maintenance).
@cnx @fdroidorg @captainepoch @husky All our rebuilds of Husky from v1.4.0 til v1.5.3 have been reproducible, so most likely, the newer ones still are. We'll see for sure once our rebuilders catch up with the backlog.
@fdroidorg I'd also suggest looking at and linking to @IzzyOnDroid's great documentation for app devs on what to watch for: https://gitlab.com/IzzyOnDroid/repo/-/wikis/Reproducible-Builds, which is much more helpful than just creating upstream issues to say "broken, please fix" without detailed steps.
(By the way, if someone wants to try building Reproducible Builds themselves, I'd strongly suggest looking at https://gitlab.com/IzzyOnDroid/repo/-/wikis/Verification-Builder, which powers the #IzzyOnDroid #ReproducibleBuild system, covering over 30% of IoDs 1223 apps already)
@fdroidorg I know you don't like to link to us as you don't want to "endorse" 3rd-party repos – but maybe it's time you forget your grudges, and to accept the expertise you're offered? After all, aren't your RBs using our tools (as our repo still uses yours)? Haven't we adopted from each other in both directions? We have no issues linking to you (the wiki @SylvieLorxu just mentioned does that, for example). Your turn now 
@IzzyOnDroid @fdroidorg @SylvieLorxu Hear, hear! IzzyOnDroid & F-Droid are COMPLEMENTARY. The success of one helps the other, I thought that was clear, c'mon! 
@IzzyOnDroid @fdroidorg @SylvieLorxu Talking about RB, it would awesome to be able to list RB app only on the app ! (Maybe using different repo ?)
@IzzyOnDroid @fdroidorg @SylvieLorxu And a way to rotate keys from F-Droid ones to the dev ones :)
@S1m now, that's not possible with @fdroidorg anymore; support for this was broken for fdroidserver in January, unfortunately. It's still possible with IzzyOnDroid, though, as we used a different patch (and yes, we have at least 1 app which uses key rotation (Occtax), and our documentation recommends that for key changes). Though we don't need that for RBs, as RB verification runs on a separate track here, so we can "make apps RB" even after they have been listed here for a while. @SylvieLorxu
@IzzyOnDroid @S1m @fdroidorg @SylvieLorxu we aim to support signer key rotation. We would greatly appreciate it if those who know about bugs would file them in our issue tracker so that we can track them. Also, we welcome contributions there.
@eighthave @S1m @fdroidorg @SylvieLorxu Good to know your stance on this has changed now – back in April, when we warned about breaking support for key rotation (it was still supported before that MR was merged), it was not important: https://gitlab.com/fdroid/fdroidserver/-/merge_requests/1466#note_1886368290
Had you accepted our contributions back then, APKs with rotated keys would still work with fdroidserver (as they do at IzzyOnDroid, where those contributions have been implemented).
@IzzyOnDroid @S1m @fdroidorg @SylvieLorxu The issue you are pointing to is only for APKs that have APKv1 signatures. That means apps with minSdkVersion less than 24 (Android 6 and older). That is devices that have not had an OS update since 2015. That is maybe a couple of percent of Android users? So I decided my limited time was better spent elsewhere rather than sinking days of work to supporting a small percentage of apps on a tiny percentage of devices. That said, I welcome contributions.
@eighthave @S1m @fdroidorg @SylvieLorxu I won't delve into that again, Hans, so let's stop that here please. You've spent 2 weeks of that valuable time on an alternative implementation back then instead of accepting contributions offered to you by experts (not mine, I'm not expert in that area). And sorry, but our time is limited, too, so we cannot sink days into fixing that again for you
@S1m @IzzyOnDroid @fdroidorg For #IzzyOnDroid you could use #rbtui (https://apt.izzysoft.de/fdroid/index/apk/dev.bg.rbtlui) to see the RB status of all apps. It contains a button to open the IzzyOnDroid page for that app for installation. It's not perfect, but it would sort of allow you to browse RB apps for now :)
@SylvieLorxu @IzzyOnDroid @fdroidorg This is after seing this page I thought it would be cool to be built-in F-Droid apk
@S1m This is on the ToDo list for our repo browser – and AFAIR also for Droid-ify and Neo Store. It would need an index containing those details, which our builders provide.But as we don't build all apps from @fdroidorg (only some), it would cover all of our RB apps but only some of theirs currently. For browsing RB apps covered by rbtlog builders, there's Ben's rbtlui: https://apt.izzysoft.de/packages/dev.bg.rbtlui @SylvieLorxu
@IzzyOnDroid @fdroidorg @SylvieLorxu I would be happy to see your repo become #FreeSoftware! As you well know, F-Droid only endorses verifiable free software projects.
It is also great to see all your work on #ReproducibleBuilds. We are continuing to build upon our years of effort there. Our approach is focused on identifying issues and getting things fixed upstream as much as possible. Then devs do not need to use any special tools to achieve reproducible builds.
Indeed. Merely reporting failures upstream is easy. And whilst sometimes fixes can also be quite easy, some expertise is often required to figure out what to do about observed differences.
See e.g. https://github.com/TeamNewPipe/NewPipe/issues/11754
Good documentation can help a lot here. As is having people with RB expertise, like @IzzyOnDroid, helping developers to debug issues :)
You also need people to develop and maintain the RB tooling and workarounds everything relies on. And to report things like compiler bugs to Google. Which so far has been pretty much just me.
@SylvieLorxu @fdroidorg @IzzyOnDroid
Yes, there is plenty of low hanging fruit like embedded timestamps or nondeterministic ordering. Many apps are already easily reproducible or require only small fixes.
But the ecosystem is constantly moving: old toolchain and dependency bugs get fixed, but new ones keep popping up.
Reproducible Builds are not just an item on a checklist, something you (ask upstreams to) enable and then you're done. Especially when it's a hard requirement like at F-Droid where new builds no longer being reproducible means users will not be able to get updates.
It's an ongoing process involving not just upstream app developers, but also maintainers of repositories, clients, and rebuilders; those involved in outreach and writing documentation; developers and maintainers of tooling, toolchains, and dependencies. And often requires a lot of collaborative debugging :)
It requires teamwork and an ongoing commitment to investigate and fix new issues when they pop up.
@SylvieLorxu @fdroidorg @IzzyOnDroid I totally agree that people should only file useful issues based on concrete solutions. Most of the #ReproducibleBuilds issues we are seeing in our mass rebuilds are the classic timestamps and sort order issues. These are generally easy to spot in the #diffoscope output we are providing. For fixing timestamps, I recommend https://reproducible-builds.org/docs/source-date-epoch/ For sort order issues, usually the dev has to just add sorting to the code, like https://codeberg.org/iNPUTmice/Conversations/commit/37f51949fda2f04cd64eab76a1cc91343695f52e
@fdroidorg
Cool, thanks!
Uhm, now that I see the diffs for my #TKCompanionApp, how can I tackle them?
I don't know what to do...
@AAMfP @fdroidorg It looks our current rebuild hasn't reached your latest releases yet. Based on the output from v6.8.0, it looks like an issue from the tooling itself that is likely fixed in newer versions. I don't recognize the specific issue, perhaps someone else does? I'll try to bump up the priority of rebuilding your latest release.
https://verification.f-droid.org/name.bresciani.marco.tkcompanionapp_680.apk.diffoscope.html
@eighthave
Thanks!
No hurry, actually: I simply wanted to understand and see if I can do something to help.
@fdroidorg
@fdroidorg You might want to mention that unlike the rebuilders run by e.g. @IzzyOnDroid, which verify APKs built and published by upstreams, in a build environment customised for that, your linked verification server reproduces F-Droid's builds (which may be patched), using F-Droid's build environment. That's kind of important when you're going to report issues upstream.
@obfusk @fdroidorg @IzzyOnDroid I agree it is important to mention when there are patches, and the build environment is also often relevant. We use a minimal Debian/stable build environment both in CI containers and in production VMs to provide as neutral a build environment as possible. Plus we also like that #Debian is the most reproducible base OS that is currently feasible to use for Android builds.