| 28 Sep 2020 |
 _hc | look at any other RB effort, they are all doing bit-for-bit exact for the distributed file, which are usually archives | 14:41:29 |
| _hc | Java JARs, Debian .debs (ar+tar), etc. | 14:41:42 |
| _hc | FYI using v1 sigs already gives you your 'close enough' standard | 14:42:48 |
 kitsunyan | But the problem is that keys are private to developers. How archives can be required to become reproducible, if only developer has keys? If different people sign the apk with their own keys, apks will obviously different. | 14:44:39 |
| kitsunyan | Which means apk format itself isn't supposed to be 1:1 matched. | 14:45:09 |
| kitsunyan | And old v1 scheme wasn't reproducible in that sense as well. Extracting keys and running jarsigner is a data matching, not archives binarily. | 14:46:23 |
| kitsunyan | Moreover, the process of packaging ar and tar archives is much simplier due to simple archive format and tools. | 14:48:39 |
| kitsunyan | But Android packaging tools is a mess. JarFile, AGP, aapt, aapt2, apksigner, and even Java itself. There seem to be no consistency at all. | 14:50:32 |
| kitsunyan | I didn't succeeded in building 1:1 archives using python script, tbh. Neither I will with ZipFile from Java because it's too simple. To enable "1:1 bibary matching" reproducible builds, there should be a fdroid-specific "contract" to how to pack and sign apks, which should be followed both by application developers and fdroid buildserver. This is complex, because it will either require more metadata from developers (like order of files in archive, offsets, etc), or require a fdroid-specific packaging packaging script to be used by developers. | 14:56:10 |
| _hc | if the build result is bit-for-bit reproducible, then the signature applies regardless of who has the keys | 14:57:00 |
| kitsunyan | And then, the question is "what we are supposed to archieve by these means". | 14:57:12 |
| _hc | I think you should read up on reproducible-builds.org | 14:57:21 |
| _hc | specificially buildinfo files and the like | 14:58:04 |
| kitsunyan | In reply to @eighthave:matrix.org
if the build result is bit-for-bit reproducible, then the signature applies regardless of who has the keys Only if proper tools are used. We don't have them. | 15:01:28 |
| _hc | we make them! | 15:25:12 |
 mimi89999 | When will there the build run? | 17:10:50 |
 Gregor | https://www.xda-developers.com/google-play-store-in-app-billing-clarity-android-12-third-party-app-stores/ | 18:04:44 |
|  daniel (quite) left the room. | 18:07:44 |
 mvdan | that's surprisingly good news. | 22:06:27 |
 cdesai | "Google hasn’t shared exactly what changes they’re making to Android" let's see | 22:12:06 |
| cdesai | https://android-developers.googleblog.com/2020/09/listening-to-developer-feedback-to.html source link | 22:18:18 |
| 29 Sep 2020 |
| _hc | izzy: is there an fdroiddata repo for the izzysoft repo? I'm making a CLI repo curation tool, so it would be nice t have access to the .yml files | 08:53:59 |
 wb9688 | Do binary-only repos have a fdroiddata thingy? | 08:55:20 |
| _hc | if you want them to, sure | 09:00:38 |
| _hc | for example https://gitlab.com/guardianproject/fdroid-metadata | 09:01:05 |
 izzy | _hc: currently not. Shall I make the files available to you by some other means (eg ZIP them up and send by mail)? | 09:04:48 |
| _hc | izzy: thanks, but I don't need a ZIP. I mostly was looking for examples for people to learn from. If you don't have an fdroiddata-like repo, then no big deal. I'll use the guardianproject repo as the example | 09:05:47 |
| _hc | I can get all the info from the index file | 09:05:53 |
| izzy | Almost, yes. Some things like MaintainerNotes are missing there. | 09:06:20 |
| _hc | izzy: do you use [[app.id]] links in izzysoft? | 09:41:38 |
