On 18/04/2024 15.45, Chris Lamb wrote:
To that end, what conferences are folks on this list still going to,
and, hopefully, still getting something from? I mean, there must be
some exceptions other than FOSDEM… :)
My list has become rather short:
rb conf (if within Europe)
openSUSE conf,
Hi,
today I want to share with you two successes on our path to total
reproducibility in openSUSE:
Through the persistence of my colleague Jan Zerebecki and the help of
mls (SUSE's rpm maintainer) we made nice progress on
https://bugzilla.opensuse.org/show_bug.cgi?id=1148824
to finally
On 21/03/2024 21.38, kpcyrd wrote:
- libjpeg-turbo: this package contains a .jar file that is built by
CMake and contains timestamps of the buildtime, but there's no way in
CMake to pass --date to the jar executable to normalize this
You could use strip-nondeterminism for post-processing
On 14/02/2024 16.19, Santiago Torres-Arias wrote:
1. can we study the conflicting interestes (i.e., above) that stop
reproducibility from happening.
Yes, that should be possible. The above summarized my experience from
the 1000 patches and bug-reports I did and the interactions with
On 19/01/2024 21.03, Chris Lamb wrote:
Was there any reason to reject >ULONG_MAX? I'm touching this code,
and don't see a reason for it; it looks very arbitrary; especially
since some systems can have 32-bit long, but 64-bit time_t. Should I
just drop that check, or keep it? And why?
There
Sometimes people wonder:
Why is not everything reproducible yet?
And the general reason is that there are other interests that result in
added non-determinism.
I collected some with examples
Performance (PGO, benchmarking, -march=native, parallelism/races)
On 23/11/2023 17.53, Ludovic Courtès wrote:
The implementations are also very different: for instance, Chez
implements a native ahead-of-time compiler whereas Guile has bytecode
compilation plus just-in-time compilation. Thus problems and solutions
for one implementation are unlikely to
Hi,
in openSUSE there are some packages that so far refuse to build
reproducibly. The common theme around them is that they use scheme or
lisp to produce binaries with a 'dump' command.
e.g. for scheme48 I extracted this reproducer:
pushd ~/rpmbuild/BUILD/scheme48-*/ps-compiler
../go -h
On 08/11/2023 16.38, Pol Dellaiera wrote:
you define functions doing I/O as Impure functions.
But without I/O, no build output can be written, so all builds must use
impure functions.
In practice we see non-determinism from approx 10 sources, such as
documented in
Dear fellow R-B-ings
Just 2 weeks ago, when I re-reviewed the remaining ~120 major issues in
openSUSE, I pretty much skipped over LibreOffice (and only this one),
noting it down as "various issues", because some years ago, when I had
previously taken a closer look, there had been so many
On 11/09/2023 09.25, Helmut Grohne wrote:
It also
is unclear how it affects reproducible builds since such builds depend
on the performance characteristics of the system performing the build.
It is worth noting that the performance (execution time) of a
build-system does not matter for
On 25/08/2023 06.56, kpcyrd wrote:
It seems the order for this has an impact on the elf binary.
```
find . -type f -perm -u+w -print0 2>/dev/null | while IFS= read -rd ''
binary ; do
This should be trivial to fix with
find . -type f -perm -u+w -print0 2>/dev/null |
sort -z |
while IFS=
On 02/08/2023 11.26, Carles Pina i Estany wrote:
Hi,
This is Debian specific but I cannot find a reproducible builds Debian
specific mailing list. Let me know if I should ask elsewhere. Feel free
to send me some pointers to read it myself.
TL;DR: I'm trying to build hello-traditional from
On 29/05/2023 06.10, Vagrant Cascadian wrote:
Do such tools actually exist, or are we talking about something
theoretical here?
https://github.com/openSUSE/build-compare/ is in use for 13 years.
And strip-nondeterminism can be used to build another such tool.
They will only ever be able to
On 29/05/2023 05.25, David A. Wheeler wrote:
If you have tips on common likely errors, please post, I think
that would be of interest to many.
https://github.com/openSUSE/build-compare/issues/53
https://github.com/openSUSE/build-compare/issues/33
I agree, that it is good to give it a name (I have called it
semi-reproducible before), but we should be clear on communicating the
disadvantages.
In openSUSE we have been working towards repeatable semantically
reproducible builds for over a decade [1] using our open-build-service
and a
On 06/04/2023 10.28, Larry Doolittle wrote:
I'm trying to make a process to generate byte-for-byte reproducible zip files.
Try adding the -X option to the zip call.
It will suppress adding of extended attributes (atime/ctime).
And with
On 09/03/2023 23.34, Vagrant Cascadian wrote:
On 2023-03-08, aho...@0w.se wrote:
We seem to be the first project offering bootstrappable and verifiable
builds without any binary seeds.
The project's website is at [1]
...
[1] the site is available through the Tor/onion network
(for the
On 25/02/2023 16.56, Anthony Harrison wrote:
More tools are in the pipeline, including one to generate an SBOM from
an installed platform distribution or package (currently works for
Debian systems, work in progress for RPM based systems) and an audit
tool. I hope to publish these in the
On 18/12/2022 02.09, Martin via rb-general wrote:
Controlling hardware is essential
https://www.bunniestudios.com/blog/?p=5706
Covers the topic of why open-source hardware is not enough to build
trustable devices.
TLDR: there are ways to subvert silicon that cannot be detected, even
Hi,
a colleague of mine is rather skeptic towards bootstrapping and
reproducible-builds.
E.g. he wrote
https://fy.blackhats.net.au/blog/html/2021/05/12/compiler_bootstrapping_can_we_trust_rust.html
and the effect can also be seen in his packaging such as
Hi,
there is an interesting rb-related argument in a PR, but I want to avoid
that too many rb-people hop in there and instead would appreciate, if
you could contribute to a cohesive argument at
https://etherpad.opensuse.org/p/scons-rb-argument
that then gets posted there by 1 representative.
Muhammad Hassan wrote:
> Do you feel there is potential for detecting build unreproducibility
> statically (without executing adversarial rebuilds)?
Yes, there are a number of potentially troublesome strings listed in
https://github.com/bmwiedemann/reproducibleopensuse/blob/master/howtodebug#L31
On 17/06/2022 11.12, Chris Lamb wrote:
> Hi Roland,
>
>> would enabling LTO cause reproducible issues?
>> If I remember correctly, Bernhard mentioned some issues, which got
>> 'solved' by using less parallel builds (-j1 or -j4?).
>
> Good question. There was definitely at least one
On 10/03/2022 04.23, Bernhard M. Wiedemann wrote:
> Hi,
>
> I submitted a rb workshop session proposal for
> https://events.opensuse.org/conferences/oSC22
>
> Even if that is not accepted, this conf would be an opportunity for a
> small meetup of rb people.
>
> Who
On 06/05/2022 22.48, John Neffenger wrote:
> Starting yesterday, for the first time, the JDK can create reproducible
> builds of the JDK!
That is great news. Thank you John, Magnus and Andrew for taking care of
this.
I tried to get a double-build test working on openSUSE with
On 22/03/2022 13.46, Chris Lamb wrote:
> Just wondering if anyone on this list is aware of any real-world
> instances where RB practices have made a difference and flagged
> something legitimately "bad"?
Maybe not "bad" as in "malicious", but certainly I detected and fixed
some bad quality
On 16/03/2022 17.54, Marc Haber wrote:
> [tl;dr building with faketime yields Debian package with timestamps
> different from building without faketime, causing reprotest to fail]
It might be a problem with how faketime works:
https://github.com/wolfcw/libfaketime/issues/183
For openSUSE, I
Hi,
I submitted a rb workshop session proposal for
https://events.opensuse.org/conferences/oSC22
Even if that is not accepted, this conf would be an opportunity for a
small meetup of rb people.
Who would be interested to join? Add yourself to
https://dudle.inf.tu-dresden.de/NUE-rb-meetup-2022/
On 01/03/2022 17.59, Mattia Rizzolo wrote:
> Hello everybody,
>
> in the past month or two we have seen how, at least in Europe and in the
> Americas, rules slowly opened up so that people could move around again.
> As such, some of us were thinking if this could be a good idea to
> physically
On 23/02/2022 11.53, Thomas Schmitt wrote:
> When trying to convince programmers of the additional complexity it does
> not really help that
> https://reproducible-builds.org/docs/source-date-epoch/
> says:
> "At present, we do not have a proposal that includes anything
>resembling a
Hi Vagrant,
I missed you in IRC where you wondered why openSUSE's gcc shows as
reproducible in http://ismypackagereproducibleyet.org/?pkg=gcc
Our 'gcc' is just a meta-package that pulls in gcc11 or whatever version
is current.
Since around gcc9, we were also able to build gcc reproducibly if we
On 21/01/2022 02.21, Chris Lamb wrote:
> Thanks for forwarding this. Do you, or anyone else on this list in
> fact, have an intention to submit or attend at this point?
Since it has been silent so far, and I hope I do not have to travel to
Texas for this presentation,
I have now submitted a
Forwarded Message
Subject:Announcing SupplyChainSecurityCon, and other Open Source
Summit NA 2022 Events
Date: Wed, 19 Jan 2022 07:33:24 -0800
From: The Linux Foundation
Reply-To: no-re...@linuxfoundation.org
To: linuxcom...@lsmod.de
Announcing
On 23/10/2021 20.14, David A. Wheeler wrote:
>
> A given version of tar should produce deterministic results. However, if
> tar is updated, it’s not really
> reasonable to expect that the result will be identical.
> It’s reasonable for GitHub to change its default tar implementation. What
>
On 21/10/2021 13.13, Mattia Rizzolo wrote:
> "Thanks" to COVID-19, we, of course, skipped 2020, and we were
> previously hoping to run an event in 2021. But too much of the world is
> still not really viable when it comes to travelling and meeting people
> etc., even before considering our own
On 06/09/2021 11.17, Magnus Ihse Bursie wrote:
> I'm working for Oracle in the Build Group for OpenJDK [1], which is
> primary responsible for creating a built artifact of the OpenJDK source
> code. I also have a general interest in all things about building in
> general, so I've been lurking on
On 31/08/2021 15.53, Chris Lamb wrote:
> Indeed, needing to
> extract parts of the ISO to recreate it is slightly sub-optimal, if
> only because it would require someone to download it first before
> attempting to recreate it (rather than just possessing the minuscule
> .buildinfo file
On 20/08/2021 01.16, kpcyrd wrote:
>
> I uploaded a github repo that distributes a Hello World in various
> formats (ELF binary, Docker image, 3rd party(!) Arch Linux package) and
> documented every file and command needed to reproduce the artifacts
> bit-for-bit:
>
>
On 12/08/2021 08.48, Wolf Vollprecht wrote:
> we're organizing a conference about software package management:
> https://packaging-con.org/
>
> It's the first time that this event happens: we are trying to bring together
> many different package management communities, compare approaches,
On 05/08/2021 17.18, Santiago Torres-Arias wrote:
> Part of what I'm hoping is to involve r-b within IronHacks in
> the forseeable future: so as to encourage a hackathon on finding and
> cataloging reproducibility issues.
Well, there is this high-level collection of the 10 basic issues I found
On 29/05/2021 14.30, Marcus Hoffmann via rb-general wrote:
> we're trying to hunt down an unreproducible apk build.
>
> We currently have a diff between two dex files which diffoscope can't
> really tell us anything about:
> https://bubu1.eu/diffoscope_dex.html
>
> Anyone got any idea what's
On 24/04/2021 17.59, Roland Clobus wrote:
> I've looked the reproducible report for apt-cacher-ng [1].
> It looks like it is caused by a linker flag: -Wl,--build-id=sha1
man ld says
> --build-id=style
> If style is omitted, "sha1" is used.
So this is just the default made explicit.
If you
On 14/04/2021 19.02, Chris Lamb wrote:
> A quick update: as permitted by IEEE, the paper is now available in an
> open access / preprint capacity:
>
>https://ieeexplore.ieee.org/document/9403390
>https://arxiv.org/abs/2104.06020
I reviewed the latter and found some issues:
> doing so
On 06/04/2021 02.24, Daniel Shahaf wrote:
> I don't understand from that post what's so significant about sigstore,
> even after having followed the link to upstream's press release.
I think, the problem that it tries to address is that most (90%?) of
upstreams publish just tarballs/zipfiles
On 30/01/2021 17.27, David A. Wheeler wrote:
> Technically correct, the best kind of correct :-). And to be fair, there
> *are* some reproducible builds (as others have noted).
on that topic, openSUSE is somewhere around 96% verifiable (modulo some
missing mtime normalization) and I am also
Thanks for the interesting concept.
On 17/01/2021 13.40, Fredrik Strömberg wrote:
> https://system-transparency.org/
> https://mullvad.net/en/blog/2019/6/3/system-transparency-future/
> https://mullvad.net/nl/blog/2019/8/7/open-source-firmware-future/
in
On 21/12/2020 22.28, Richard Purdie wrote:
> OE-Core is about 800 pieces of software generating ~11,000
> packages of which we have about 65 marked as not reproducible at
> present. We're obviously working on improving those 65, and the
> techniques used will "just work" to a large extend
A bit delayed are the meeting minutes from our IRC meeting on debugging
reproducibility issues:
http://meetbot.debian.net/reproducible-builds/2020/reproducible-builds.2020-11-16-18.08.html
Here is a dump of the etherpad notes for that topic:
bmwiedemann once wrote
On 12/08/2020 19.44, jathan wrote:
> On 12/08/2020 10:54, Holger Levsen wrote:
>> Hi Jathan,
>>
>> On Fri, Aug 07, 2020 at 04:10:25PM -0500, jathan wrote:
>>> I was visiting the Reproducible Builds websitesite and the Debian Salsa
>>> repo looking for some list of "To do tasks" in the team. Do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Am 24.07.20 um 22:10 schrieb John Scott:
> I'm not subscribed, please keep me CC'd.
>
> I'm working on adding metadata to the JavaScript on
> reproducible-builds.org so software like LibreJS can know it's free
> and where the source code can be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Am 08.06.20 um 07:52 schrieb Daniel Shahaf:
> Besides, there was no question, no concrete request, no clickable
> URL…
https://walletscrutiny.com/ was mentioned, though.
IMHO an interesting and worthwhile project. It probably could use more
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/04/2020 06.03, Hervé Boutemy wrote:
> The big question is: where is the database that tells that a binary
> artifact is reproducible? Who should one trust for such a database?
> based on what proof?
There was the idea that rebuilders sign
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
As discussed on the last summit in Marrakesh, I made a working draft for
https://ismypackagereproducibleyet.org/
With only 92 lines of code, it is still rather simple.
It is free of JavaScript.
It does not map package names as you will see at
On 2/9/20 9:57 AM, Chris Lamb wrote:
Hi Otto,
Unfortunately none of the changes I made seemed to solve this..
10.3.22 is still unreproducible in unstable due to RocksDB, TokuDB and
Mroonga.
I had that old patch in rocksdb
https://github.com/facebook/rocksdb/pull/2848
but that is long merged
On 15/12/2019 09.12, Lars Wirzenius wrote:
> Hi,
>
> One of my hobby projects is vmdb2 (https://vmdb2.liw.fi/), which
> creates disk images with Debian installed. I was wondering whether it
> would be possible to generate system images reproducibly.
>
> A quick experiment with debootstrap, which
Hi,
because there are people out there that might not like Mailing Lists for
discussion or getting the latest updates, I opened
https://www.reddit.com/r/reproduciblebuilds/
You are all invited to join and post there.
Ciao
Bernhard M.
___
Am 09.12.19 um 16:50 schrieb Santiago Torres-Arias:
>>> It all boils down as to where did a backdooring compiler come from, and how
>>> is it backdooring the build.
>> Backdooring a compiler can be as simple as adding an optimization without
>> fully understanding the impact
>> (See GCC
TLDR:
The goal of reproducible builds is to reduce the likelyhood of running
software that was corrupted (during build)
At https://etherpad.opensuse.org/p/reproduciblebuilds-goal
I added a small FAQ around it. You are welcome to contribute there with
refinements or extra questions+answers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 30/11/2019 13.20, Holger Levsen wrote:
>> I also added an rbplot.pl script to graph the package status over
>> time like Debian does. http://rb.zq1.de/compare.factory/graph.png
>> shows the current state.
> wow, very nice!
>
> any idea what has
Hi
like last year (see
https://lists.reproducible-builds.org/pipermail/rb-general/2018-December/001301.html
)
as preparation to our summit in December, I wanted to once again collect
last year's changes in rpm and openSUSE that were relevant to
reproducible builds.
The collection below is in a
On 13/08/2019 02.18, Vagrant Cascadian wrote:
> On 2019-08-01, Bernhard M. Wiedemann wrote:
>> On 31/07/2019 16.50, Vagrant Cascadian wrote:
>> solved:
>>
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=32342 gzip
>> https://git.savannah
On 31/07/2019 16.50, Vagrant Cascadian wrote:
> This talk will mention some of the past and current issues in
> toolchains needed to realize Reproducible Builds in the real world.
> Let's work together to fix outstanding issues and further these
> efforts!
in case you need input, here are 9
On 22/07/2019 03.47, jathan wrote:
> I would propose myself to do these trainings, but I still find
> it very difficult and my technical knowledge is not enough. It would be
> good if Holger, lamby, Vagrant or any other member of the team with the
> experience and confidence they already have,
Hi,
while scanning for typos, I noticed that there are several variants of
our favourite terms used.
e.g. in reproducible-website repo:
find -type f -name \*.md |
xargs grep -h -v strip-nondeterminism |
egrep -o '(un|in|non|not)-?(determin|reproduc)' |
sort | uniq -c | sort -n
1
I share Arnout's concerns.
With openSUSE we have the https://openbuildservice.org/ (OBS)
and there I had previously entertained similar thoughts.
On 19/06/2019 12.50, Arnout Engelen wrote:
> On Wed, Jun 19, 2019 at 12:29 PM Lars Wirzenius wrote:
>> On Sun, May 19, 2019 at 01:09:40PM +0300,
On 12/06/2019 15.07, Bernhard M. Wiedemann wrote:
> I'll also test a cross-ppc64le-gcc8 build to see if it behaves worse,
> but would not expect so.
For the record: the cross compilation was also reproducible (without PGO).
___
rb-g
On 12/06/2019 14.42, Sebastian Huber wrote:
> do you have a log of the cross compiler build which shows the GCC
> configure command line? An example for a proven reproducible build would
> be a big help for me.
This week, I confirmed that openSUSE's gcc9 + gcc8 can build
reproducibly (non-cross)
On 29/04/2019 15.17, Holger Levsen wrote:
> On Wed, Mar 06, 2019 at 04:06:16PM +0100, Bernhard M. Wiedemann wrote:
>> Without these macros, mtimes of files are not normalized. This is
>> because that had some negative effects on python .pyc files.
>> Build Date and Build H
On 23/01/2019 00.08, David A. Wheeler wrote:
> FYI, the "legal-disc...@apache.org" mailing list is having an active
> discussion about doing reproducible builds for Apache Software Foundation
> (ASF) projects under the topic "RE: Binary channels". You can see that here:
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
regarding https://github.com/uoaerg/wavemon/pull/59
I thought, we do not need to do this kind of patch anymore since gcc
natively supports SOURCE_DATE_EPOCH to override __DATE__ and __TIME__
and everyone interested in reproducible builds sets this
somewhat offtopic
On 20/12/2018 09.59, Daniel Shahaf wrote:
> Hash functions are usually defined in terms of collision resistance.
> The constructions above have not been proven to be collision resistant,
> and moreover, they might not *be* collision resistant — even if h() is.
> Therefore, we
On 18/12/2018 15.44, Eric Myhre wrote:
> I think it's fairly open to interpretation. Implementing it as
> h(h(➡),■) would be more or less the same semantics, no?
you could even use h(h(➡),h(■))
so that you only have to hash ■ output data once.
A bit like .buildinfo files
or foo.tar.xz.sha256.asc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 23/10/2018 14.51, David A. Wheeler wrote:
> How close is the core of Debian to being reproducibly built? By
> core I mean the packages that you always have to install no matter
> what.
Coincidentally, I just answered a similar question for
74 matches
Mail list logo
