* FC Stegerman [2023-05-29 13:14]:
[...]
> > I find it hard to believe it could so close that you can programatically
> > determine something is (probably!) mostly harmless and yet still have it
> > be implausible to go all the way to make a properly reproducible build.
> &g
* Vagrant Cascadian [2023-05-29 06:10]:
[...]
> I still expect it will be harder to actually do "semantically
> reproducible builds" than "fully reproducible builds".
>
> To be honest, it sounds like a lot of extra work to avoid fixing things
> properly...
+1
> I find it hard to believe it coul
Hi!
I added some graphs to F-Droid's overview of apps published with
Reproducible Builds [1].
- FC
[1] https://gitlab.com/fdroid/fdroiddata/-/issues/2844
Hi!
I've just released apksigcopier [1] (a tool for copying android APK
signatures in order to verify reproducible builds) v1.1.1.
And reproducible-apk-tools [2] (a set of scripts to make android APKs
reproducible or find out why they are not) v0.2.2 a week ago and
v0.2.3 today.
>From the apksig
* Hans-Christoph Steiner [2023-02-03 07:58]:
> This W3C MiniApp format sounds a lot like JAR signatures, aka APK v1
> signatures. Although not an ideal format, it is at least well understood
> and explored.
Actually, "between the final entry and the zip's central directory" is
exactly where the
[... some context elided since this is getting quite long ...]
* "David A. Wheeler" [2023-02-01 20:48]:
> > Unfortunately, you've left out the details of the archive format here,
> > when they are actually quite important.
> >
> > You now need to unpack an archive (e.g. a .zip or .tar) before yo
* "David A. Wheeler" [2023-02-01 17:20]:
> > Agreed. And I often wish Android had used detached signatures. Though
> > detached signatures would have made distributing APKs more challenging:
> > a single file is much more convenient for end users.
>
> Sure, but the solution is trivial.
>
> Cre
* Marc Prud'hommeaux [2023-02-01 18:12]:
> I recently noticed a similar vulnerability in the W3C MiniApp
> packaging draft [...]
Interesting, thanks for the info!
> But in the context of an Android app, where it sounds like it has
> runtime access to the original .apk artifact and signing data, t
* "David A. Wheeler" [2023-02-01 01:38]:
> > On Jan 31, 2023, at 5:18 PM, FC Stegerman wrote:
> > We must thus ask ourselves "what is the program's environment"? I
> > think environment variables, date/time, etc. are obviously part of the
> >
* Nicolas Vigier [2023-01-31 11:42]:
> On Tue, 31 Jan 2023, FC Stegerman wrote:
> > We already know that embedded signatures [1] pose a challenge for
> > reproducible builds.
> >
> > And it's not too hard to imagine a program detecting which key it's
>
Hi!
We already know that embedded signatures [1] pose a challenge for
reproducible builds.
And it's not too hard to imagine a program detecting which key it's
signed with and changing its behaviour based on that; which I think is
inherently unavoidable.
But the Android APK Signature Scheme v2/v3
Hi!
"Towards a reproducible F-Droid" was just published [1] in F-Droid
news :)
- FC
[1] https://f-droid.org/en/2023/01/15/towards-a-reproducible-fdroid.html
Hi (again)!
Today's v0.2.1 reproducible-apk-tools [1] release adds a convenience
wrapper for modifying (and optionally zipaligning) files in-place as
well as examples on how to integrate the tools with gradle to run them
automatically as part of the build process to make it reproducible.
- FC
[1
Hi!
Today's v0.2.0 release adds several new subcommands/scripts (and fixes
a bug); the full list is now:
fix-compresslevel - recompress with different compression level
fix-newlines - change line endings from LF to CRLF (or vice versa)
sort-apk - sort (and realign) the ZIP entries of an APK
sort-
* "Bernhard M. Wiedemann via rb-general"
[2022-12-14 20:30]:
> a colleague of mine is rather skeptic towards bootstrapping and
> reproducible-builds.
> [...]
> In the end, it would be useful to collect some well-worded / well-thought
> counter-arguments on r-b.o (if we don't have that already)
>
Hi!
* FC Stegerman [2022-12-06 02:14]:
> TL;DR: we added 11 new apps using reproducible builds in November,
> making for a total of 31 RB apps in F-Droid as of December 1st [1].
I'd like to clarify that this is a list of apps that are using our RB
support [2] to publish APKs si
* Holger Levsen [2022-12-08 17:44]:
> On Tue, Dec 06, 2022 at 02:14:11AM +0100, FC Stegerman wrote:
> > TL;DR: we added 11 new apps using reproducible builds in November,
> > making for a total of 31 RB apps in F-Droid as of December 1st [1].
>
> that's really cool,
Hi (again)!
I looked at how several android messenger apps claiming to have
reproducible builds actually verify that they do [1].
TL;DR: It's quite possible these messengers actually have reproducible
builds, but the verification scripts they use don't actually allow us
to verify whether they do.
Hi!
TL;DR: we added 11 new apps using reproducible builds in November,
making for a total of 31 RB apps in F-Droid as of December 1st [1].
- FC
[1] https://gitlab.com/fdroid/fdroiddata/-/issues/2844
Hi!
I'd like to introduce reproducible-apk-tools (or repro-apk) [1], a
tool used by F-Droid to make android APKs with minor differences
(caused by e.g. building on different operating systems) fully
reproducible. At the moment, it consists of two scripts/subcommands:
The fix-newlines script/subc
Hi!
> apksigcopier [1] is a tool for copying android APK signatures from a
> signed APK to an unsigned one (in order to verify reproducible
> builds). It can also be used to compare two APKs with different
> signatures.
This release adds support for APKs signed by zipflinger/signflinger
(e.g. usi
* kpcyrd [2022-10-16 23:57]:
> multiple people in Arch Linux noticed the output of our `git archive`
> command doesn't match the tarball served by github anymore.
>
> First I suspected an update in our gzip package until I found this line in
> the git 2.38.0 release notes:
>
> > * Teach "git arc
22 matches
Mail list logo
