Hans-Christoph Steiner @eighthave@librem.one

@Fr333k one has to do everything to survive the dark, cold, deeply foggy winter! So why not embrace the dark!

@captainepoch @cnx @fdroidorg @husky hehe you're welcome. That's perfect! If we focus on fixing things upstream as much as possible, many apps will just automatically become #ReproducibleBuilds without the devs even being aware. Your message made me feel like we're on the right track, thanks!

@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.

@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.

@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.

@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

@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

@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.

@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.

@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

@D22 @fdroidorg It will download the F-Droid.apk, and if a device is available via adb, it will try to install it using adb. We have some other ideas how to help the user get the APK installed from the desktop, we are also open to ideas and suggestions.

@hyakinthos @zacchiro The Tor Project is not a good candidate, they have actually been trying to lessen their involvement in browser work for a while. It is difficult and resource intensive. It does help that #Mullvad is now contributing. More orgs and devs should join in!

This is the example of the kind of feature that the #DigitalMarketsAct is driving #Google to implement. It could have been implemented long ago, but there was no pressure for Google to do so. Notice how they implemented it in #PlayServices, not Android. Apps that implement this are then tied to Google's proprietary stuff. That's their way of maintaining control of the ecosystem. https://www.theverge.com/2024/11/21/24302562/android-restore-credentials-transfer-restore-key

I would love to see an analysis of the power dynamics of how all the browser companies are working together on the #Chromium code base. Of course, #Google has an oversized influence, both because #Chrome is dominant but also because Chromium is a Google project. I can't imagine #Microsoft is a pushover there. #Brave, #Opera and #Vivaldi probably have much less sway, but could join together. Are there useful avenues for #Firefox resources to have more impact in the Chromium ecosystem?

@hyakinthos @zacchiro I'd say we should judge them based on their decades long track record rather than details of the manifesto. Plus is there any organization or approach that can realistically replace #Mozilla?

@zacchiro I get the feeling, but I think that's unfair the decades of work Mozilla has already put in to keeping the browser ecosystem more focused on users. Mozilla is a problematic organization for sure, but it is also the only major force in the browser ecosystem with some kind of focus on putting users first. What else is there?