From dwheeler at dwheeler.com  Fri Jun  2 14:46:16 2023
From: dwheeler at dwheeler.com (David A. Wheeler)
Date: Fri, 2 Jun 2023 10:46:16 -0400
Subject: Introducing: Semantically reproducible builds
In-Reply-To: <CAFVSqg0nbaf-wOM301tXR8B0Ni_4gtXkpw98RVhwuoveB01Z2Q@mail.gmail.com>
References: <CALDQ5NwOmGCm3nZ6Zf9mzPaxUGgMOBoe9u3VHWY6YbpZiaevjw@mail.gmail.com>
 <CAFVSqg0nbaf-wOM301tXR8B0Ni_4gtXkpw98RVhwuoveB01Z2Q@mail.gmail.com>
Message-ID: <E9B33CD2-E32F-46CB-8DFD-69121D4A1A06@dwheeler.com>



> On May 31, 2023, at 10:36 AM, Ed Warnicke <hagbard at gmail.com> wrote:
> 
> I tend to think about reproducible builds in this generalizable way:
> 
> A build is reproducible if equivalent inputs (source, build tools, build tool invocation, etc) to the build result in equivalent outputs.

Fair enough. The immediate issue is to reduce confusion.

The OSSGadget developers have decided to switch to the term "semantic equivalency"
and "semantically equivalent":
> A project build is `semantically equivalent` if its build results can be either recreated exactly (a bit for bit [reproducible build](https://en.wikipedia.org/wiki/Reproducible_builds)), or if the differences between the release package and a rebuilt package are not expected to produce functional differences in normal cases.

Links:
https://github.com/microsoft/OSSGadget/issues/426
https://github.com/microsoft/OSSGadget/pull/429

Their oss-reproducible tool, part of OSSGadget, uses a variety of steps to determine if a build is semantically equivalent.

--- David A. Wheeler


From hagbard at gmail.com  Fri Jun  2 15:10:20 2023
From: hagbard at gmail.com (Ed Warnicke)
Date: Fri, 2 Jun 2023 10:10:20 -0500
Subject: Introducing: Semantically reproducible builds
In-Reply-To: <E9B33CD2-E32F-46CB-8DFD-69121D4A1A06@dwheeler.com>
References: <CALDQ5NwOmGCm3nZ6Zf9mzPaxUGgMOBoe9u3VHWY6YbpZiaevjw@mail.gmail.com>
 <CAFVSqg0nbaf-wOM301tXR8B0Ni_4gtXkpw98RVhwuoveB01Z2Q@mail.gmail.com>
 <E9B33CD2-E32F-46CB-8DFD-69121D4A1A06@dwheeler.com>
Message-ID: <CAFVSqg3sUavu5Po=Dmw79Y57XWazQydKr0_WWz0nRsWjSeLafA@mail.gmail.com>

> A project build is `semantically equivalent` if its build results can be
either recreated exactly (a bit for bit [reproducible build](
https://en.wikipedia.org/wiki/Reproducible_builds)), or if the differences
between the release package and a rebuilt package are not expected to
produce functional differences in normal cases.

This is why I was attempting to bring things back to desired
characteristics.  Intrinsic in what I suggested, talking about equivalent
outputs, is that you have a definition of equivalence that is sufficiently
precise that any two independent parties given the definition of
equivalence and a pair of outputs will always produce the same answer as to
whether the outputs are equivalent.  I don't think that "the differences
between the release package and a rebuilt package are not expected to
produce functional differences in normal cases" meets that basic criteria.
I could easily imagine two independent parties having differing
opinions wrt whether two outputs are equivalent under that definition.

Say I have an executable with a typo in its 'usage'.  I fix the typo in the
'usage' and decide to assert that the executable is semantically equivalent
to the previous executable.  From my point of view, its not functionally
different, because I don't consider 'usage' to be functional.  Someone else
may be *parsing* the usage, and does consider that to be a 'functional'
difference.

It's incredibly easy to convince yourself that your differences between two
executables aren't "not expected to produce functional differences in
normal cases".  You have "expected" "functional difference" and "normal
cases" to work with as blank spaces into which almost any definition can be
pushed.

Please don't get me wrong, the OSSGadget folks may be doing *really* good
work.  My complaint is that the definition of "Semantically Reproducible"
is effectively unusable as written above.  Can it be tightened ups to
something that at the very least meets the characteristics:

- Two independent parties given the definition of equivalence and a pair of
outputs will always produce the same answer as to whether the outputs are
equivalent.

Ed

On Fri, Jun 2, 2023 at 9:46?AM David A. Wheeler <dwheeler at dwheeler.com>
wrote:

>
>
> > On May 31, 2023, at 10:36 AM, Ed Warnicke <hagbard at gmail.com> wrote:
> >
> > I tend to think about reproducible builds in this generalizable way:
> >
> > A build is reproducible if equivalent inputs (source, build tools, build
> tool invocation, etc) to the build result in equivalent outputs.
>
> Fair enough. The immediate issue is to reduce confusion.
>
> The OSSGadget developers have decided to switch to the term "semantic
> equivalency"
> and "semantically equivalent":
> > A project build is `semantically equivalent` if its build results can be
> either recreated exactly (a bit for bit [reproducible build](
> https://en.wikipedia.org/wiki/Reproducible_builds)), or if the
> differences between the release package and a rebuilt package are not
> expected to produce functional differences in normal cases.
>
> Links:
> https://github.com/microsoft/OSSGadget/issues/426
> https://github.com/microsoft/OSSGadget/pull/429
>
> Their oss-reproducible tool, part of OSSGadget, uses a variety of steps to
> determine if a build is semantically equivalent.
>
> --- David A. Wheeler
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20230602/3822daf7/attachment.htm>

From holger at layer-acht.org  Fri Jun  2 15:17:29 2023
From: holger at layer-acht.org (Holger Levsen)
Date: Fri, 2 Jun 2023 15:17:29 +0000
Subject: Introducing: Semantically reproducible builds
In-Reply-To: <E9B33CD2-E32F-46CB-8DFD-69121D4A1A06@dwheeler.com>
References: <CALDQ5NwOmGCm3nZ6Zf9mzPaxUGgMOBoe9u3VHWY6YbpZiaevjw@mail.gmail.com>
 <CAFVSqg0nbaf-wOM301tXR8B0Ni_4gtXkpw98RVhwuoveB01Z2Q@mail.gmail.com>
 <E9B33CD2-E32F-46CB-8DFD-69121D4A1A06@dwheeler.com>
Message-ID: <ZHoICaM2lOI4orRj@layer-acht.org>

hi,

I was busy with the Debian Hamburg Reunion 2023 last week and the first
half of this, so I only started catching up on this thread yesterday...

On Fri, Jun 02, 2023 at 10:46:16AM -0400, David A. Wheeler wrote:
> Fair enough. The immediate issue is to reduce confusion.
> 
> The OSSGadget developers have decided to switch to the term "semantic equivalency"
> and "semantically equivalent":

...and now I'm glad to read this! As several other have pointed out in this
thread the previously discussed term would have been very confusing, so I'm
happy you've found something else.


-- 
cheers,
	Holger

 ???????
 ???????  holger@(debian|reproducible-builds|layer-acht).org
 ???????  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ???

"Any fool can know. The point is to understand." - A. Einstein 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20230602/ec138251/attachment.sig>

From dwheeler at dwheeler.com  Fri Jun  2 15:39:42 2023
From: dwheeler at dwheeler.com (David A. Wheeler)
Date: Fri, 2 Jun 2023 11:39:42 -0400
Subject: Introducing: Semantically reproducible builds
In-Reply-To: <CAFVSqg3sUavu5Po=Dmw79Y57XWazQydKr0_WWz0nRsWjSeLafA@mail.gmail.com>
References: <CALDQ5NwOmGCm3nZ6Zf9mzPaxUGgMOBoe9u3VHWY6YbpZiaevjw@mail.gmail.com>
 <CAFVSqg0nbaf-wOM301tXR8B0Ni_4gtXkpw98RVhwuoveB01Z2Q@mail.gmail.com>
 <E9B33CD2-E32F-46CB-8DFD-69121D4A1A06@dwheeler.com>
 <CAFVSqg3sUavu5Po=Dmw79Y57XWazQydKr0_WWz0nRsWjSeLafA@mail.gmail.com>
Message-ID: <8FC11319-1CA6-47EF-AD0A-2AA6D787ADCB@dwheeler.com>



> On Jun 2, 2023, at 11:10 AM, Ed Warnicke <hagbard at gmail.com> wrote:
> Please don't get me wrong, the OSSGadget folks may be doing *really* good work.  My complaint is that the definition of "Semantically Reproducible" is effectively unusable as written above.  Can it be tightened ups to something that at the very least meets the characteristics:
> 
> - Two independent parties given the definition of equivalence and a pair of outputs will always produce the same answer as to whether the outputs are equivalent.

Sadly, different parties can disagree. We sometimes even see that on this mailing list :-).

I think the OSSGadget folks aren't fussed about this, because they're merely using this definition to explain what they're doing.

I think their answer on "are these semantically equivalent" would be, "run the current version of OSSGadget and the answer is what it says". It's a very straightward operational definition once put that way :-).

--- David A. Wheeler


From andreas at enge.fr  Fri Jun  2 16:26:08 2023
From: andreas at enge.fr (Andreas Enge)
Date: Fri, 2 Jun 2023 18:26:08 +0200
Subject: Introducing: Semantically reproducible builds
In-Reply-To: <8FC11319-1CA6-47EF-AD0A-2AA6D787ADCB@dwheeler.com>
References: <CALDQ5NwOmGCm3nZ6Zf9mzPaxUGgMOBoe9u3VHWY6YbpZiaevjw@mail.gmail.com>
 <CAFVSqg0nbaf-wOM301tXR8B0Ni_4gtXkpw98RVhwuoveB01Z2Q@mail.gmail.com>
 <E9B33CD2-E32F-46CB-8DFD-69121D4A1A06@dwheeler.com>
 <CAFVSqg3sUavu5Po=Dmw79Y57XWazQydKr0_WWz0nRsWjSeLafA@mail.gmail.com>
 <8FC11319-1CA6-47EF-AD0A-2AA6D787ADCB@dwheeler.com>
Message-ID: <ZHoYIMM7ge1PI7J6@jurong>

Hello,

Am Fri, Jun 02, 2023 at 11:39:42AM -0400 schrieb David A. Wheeler:
> I think the OSSGadget folks aren't fussed about this, because they're merely using this definition to explain what they're doing.
 
my first reaction also was "this is not a definition"! They are a few vague
words describing a property that, defined strictly (for instance something
like: "Two binaries are semantically equivalent if run in any environment
with any input they produce identical outputs and side effects"), is
certainly undecidable - it requires being able to decide the halting problem.

Reproducible builds are easily decidable and imply what one really wants,
semantic equivalence.

Of course one can then pile up any number of heuristics and one-sided tests
and conclude that one has not found a proof that two different binaries are
semantically inequivalent, but this is not a proof that they are semantically
equivalent (just as no number of tests proves that some code is correct).

> I think their answer on "are these semantically equivalent" would be, "run the current version of OSSGadget and the answer is what it says". It's a very straightward operational definition once put that way :-).

Then they could call it "OSSGadget-equivalent"...

Andreas


From chris at reproducible-builds.org  Fri Jun  2 17:15:24 2023
From: chris at reproducible-builds.org (Chris Lamb)
Date: Fri, 02 Jun 2023 13:15:24 -0400
Subject: Please review the draft for May's report
Message-ID: <168572459657.306602.8704383662448454994@copycat>

Hi all,

Please review the draft for May's Reproducible Builds report:

  https://reproducible-builds.org/reports/2023-05/?draft

? or, via the Git repository itself:

  https://salsa.debian.org/reproducible-builds/reproducible-website/blob/master/_reports/2023-05.md

I intend to publish it no earlier than:

  $ date -d 'Mon, 05 Jun 2023 17:00 -0000'

  https://time.is/compare/1700_05_Jun_2023_in_UTC

?

Please feel free and commit/push to drafts directly without the overhead of
sending patches or merge requests. You should make your changes to the
"_reports/2023-05.md" file in the "reproducible-website" repository:

  $ git clone https://salsa.debian.org/reproducible-builds/reproducible-website
  $ cd reproducible-website
  $ sensible-editor _reports/2023-05.md

I am happy to reword and/or rework additions prior to publishing. If you
currently do not have access to the above repository, you can request access
by following the instructions at:

  https://reproducible-builds.org/contribute/salsa/


Regards,

-- 
      o
    ?   ?      Chris Lamb
   o     o     reproducible-builds.org ?
    ?   ?
      o

From dwheeler at dwheeler.com  Fri Jun  2 21:36:09 2023
From: dwheeler at dwheeler.com (David A. Wheeler)
Date: Fri, 2 Jun 2023 17:36:09 -0400
Subject: Introducing: Semantically reproducible builds
In-Reply-To: <ZHoYIMM7ge1PI7J6@jurong>
References: <CALDQ5NwOmGCm3nZ6Zf9mzPaxUGgMOBoe9u3VHWY6YbpZiaevjw@mail.gmail.com>
 <CAFVSqg0nbaf-wOM301tXR8B0Ni_4gtXkpw98RVhwuoveB01Z2Q@mail.gmail.com>
 <E9B33CD2-E32F-46CB-8DFD-69121D4A1A06@dwheeler.com>
 <CAFVSqg3sUavu5Po=Dmw79Y57XWazQydKr0_WWz0nRsWjSeLafA@mail.gmail.com>
 <8FC11319-1CA6-47EF-AD0A-2AA6D787ADCB@dwheeler.com> <ZHoYIMM7ge1PI7J6@jurong>
Message-ID: <EDB796AD-7720-4C7C-978F-6C6429C798E3@dwheeler.com>



> On Jun 2, 2023, at 12:26 PM, Andreas Enge <andreas at enge.fr> wrote:
> 
> Hello,
> 
> Am Fri, Jun 02, 2023 at 11:39:42AM -0400 schrieb David A. Wheeler:
>> I think the OSSGadget folks aren't fussed about this, because they're merely using this definition to explain what they're doing.
> 
> my first reaction also was "this is not a definition"! They are a few vague
> words describing a property that, defined strictly (for instance something
> like: "Two binaries are semantically equivalent if run in any environment
> with any input they produce identical outputs and side effects"), is
> certainly undecidable - it requires being able to decide the halting problem.

The proof of that is charmingly short. Here's the summary from my 2009 PhD dissertation
<https://dwheeler.com/trusting-trust/dissertation/html/wheeler-trusting-trust-ddc.html> section 5.6.1:

"Note that equality is a stricter relationship than equivalence. Two executables may be considered equivalent in an environment if they always produce equal outputs given equal inputs, even if their internal structure and/or values are different. Two executables that are equal are always equivalent, but equivalent executables need not be equal. Unfortunately, determining if two executables E1 and E2 are equivalent is undecidable in the general case. This is because if there was any decision procedure D capable of determining equivalence, it could be invoked by E1 and E2. If found equivalent they could perform different operations, and if found different they could act the same [Cohen1984, part 4]. Even in very special cases it is often difficult to determine the equivalence of two unequal executables. Instead of focusing on the difficult-to-determine equivalence relationship, we will instead focus on the stricter equality relationship, which is a far easier and more practical test to perform. Proof #2 and proof #3 will show that under certain common conditions, two executables will be equal (not just equivalent), so limiting proof #1 to equality does not significantly limit its practical utility."

> Reproducible builds are easily decidable and imply what one really wants,
> semantic equivalence.
> 
> Of course one can then pile up any number of heuristics and one-sided tests
> and conclude that one has not found a proof that two different binaries are
> semantically inequivalent, but this is not a proof that they are semantically
> equivalent (just as no number of tests proves that some code is correct).
> 
>> I think their answer on "are these semantically equivalent" would be, "run the current version of OSSGadget and the answer is what it says". It's a very straightward operational definition once put that way :-).
> 
> Then they could call it "OSSGadget-equivalent"...

I don't see the need for that. Practically all other security measures are heuristic estimates,
and we simply require information on who did the work & why they believe their claim is correct.

In this case, "We believe the posted package BAR is semantically equivalent to a regenerated package
(and thus is semantically equivalent to what the BAR source code says it will do)
because we organization ORG ran OSSGadget version FOO <with hash HASH>, and the tool
determined that they were semantically equivalent." We use tools to make assertions all the time.
If the tool gets it wrong, we try to fix the tool, and that updated tool has a new version number
to let us identify pr?cisely what it does and does not do.

This si similar to statements like "We (organization ORG) use process XYZ to
evaluate the security of software BAR; we found vulnerabilities <list> and once those are
fixed we believe the software is adequately secure." I love the press towards proof and
exactitude, but remember where we're starting from :-).

--- David A. Wheeler


From lamby at debian.org  Mon Jun  5 17:40:42 2023
From: lamby at debian.org (Chris Lamb)
Date: Mon, 05 Jun 2023 10:40:42 -0700
Subject: Please review the draft for May's report
In-Reply-To: <168572459657.306602.8704383662448454994@copycat>
References: <168572459657.306602.8704383662448454994@copycat>
Message-ID: <82acd5dd-654e-4d61-ac81-8edaae18fd2a@app.fastmail.com>

Chris Lamb wrote:

> Please review the draft for May's Reproducible Builds report:

This has now been published ? thanks to all who contributed. If
you have a moment, please share the following link:

  https://reproducible-builds.org/reports/2023-05/

? and also consider retweeting:

  https://twitter.com/ReproBuilds/status/1665775526466969600


Regards,

-- 
      o
    ?   ?      Chris Lamb
   o     o     reproducible-builds.org ?
    ?   ?
      o

From martin.monperrus at gnieh.org  Wed Jun  7 13:50:41 2023
From: martin.monperrus at gnieh.org (Martin Monperrus)
Date: Wed, 7 Jun 2023 15:50:41 +0200
Subject: breaking CI if build is not reproducible?
Message-ID: <7c4ab551-6c4d-0bb3-2054-171fb734fff2@gnieh.org>

Hi all,

We're researching on build reproducibility.

Are you aware of any project where reproducibility is checked in a continuous integration pipeline?

(For instance, by building twice in CI and comparing the output)

If yes, thanks to share here or via private email.

Thanks a lot!

Martin & the Chains project at KTH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20230607/0142bde9/attachment.htm>

From richard.purdie at linuxfoundation.org  Wed Jun  7 13:52:59 2023
From: richard.purdie at linuxfoundation.org (Richard Purdie)
Date: Wed, 07 Jun 2023 14:52:59 +0100
Subject: breaking CI if build is not reproducible?
In-Reply-To: <7c4ab551-6c4d-0bb3-2054-171fb734fff2@gnieh.org>
References: <7c4ab551-6c4d-0bb3-2054-171fb734fff2@gnieh.org>
Message-ID: <12c2a478c6fa7735703d763f179ff242e284fd6e.camel@linuxfoundation.org>

On Wed, 2023-06-07 at 15:50 +0200, Martin Monperrus wrote:
> ?We're researching on build reproducibility.
> ?
> ?Are you aware of any project where reproducibility is checked in a
> continuous integration pipeline?
> ?
> ?(For instance, by building twice in CI and comparing the output)
> ?
> ?If yes, thanks to share here or via private email.

The Yocto Project does, here:

https://autobuilder.yoctoproject.org/typhoon/#/builders/117

Cheers,

Richard

From dwheeler at dwheeler.com  Wed Jun  7 14:42:30 2023
From: dwheeler at dwheeler.com (David A. Wheeler)
Date: Wed, 7 Jun 2023 10:42:30 -0400
Subject: breaking CI if build is not reproducible?
In-Reply-To: <7c4ab551-6c4d-0bb3-2054-171fb734fff2@gnieh.org>
References: <7c4ab551-6c4d-0bb3-2054-171fb734fff2@gnieh.org>
Message-ID: <8D1CDAF9-360E-412C-BBF7-739B058FA235@dwheeler.com>


> On Jun 7, 2023, at 9:50 AM, Martin Monperrus <martin.monperrus at gnieh.org> wrote:
> 
> Hi all,
> 
> We're researching on build reproducibility.
> 
> Are you aware of any project where reproducibility is checked in a continuous integration pipeline?

I think the Tor project does, but you'd need to ask them to verify.

Some relevant links you might find useful are here:
https://dwheeler.com/trusting-trust#reproducible
It's rather a stream of just some related links & commentary, but I try to put "interesting related things" there.

--- David A. Wheeler


From boklm at mars-attacks.org  Wed Jun  7 17:21:22 2023
From: boklm at mars-attacks.org (Nicolas Vigier)
Date: Wed, 7 Jun 2023 19:21:22 +0200
Subject: breaking CI if build is not reproducible?
In-Reply-To: <8D1CDAF9-360E-412C-BBF7-739B058FA235@dwheeler.com>
References: <7c4ab551-6c4d-0bb3-2054-171fb734fff2@gnieh.org>
 <8D1CDAF9-360E-412C-BBF7-739B058FA235@dwheeler.com>
Message-ID: <20230607172122.7x4hjqi53lzwjv72@mars-attacks.org>

On Wed, 07 Jun 2023, David A. Wheeler wrote:

> 
> > On Jun 7, 2023, at 9:50 AM, Martin Monperrus <martin.monperrus at gnieh.org> wrote:
> > 
> > Hi all,
> > 
> > We're researching on build reproducibility.
> > 
> > Are you aware of any project where reproducibility is checked in a continuous integration pipeline?
> 
> I think the Tor project does, but you'd need to ask them to verify.

We manually check that each new Tor Browser release is reproducible.
But we currently don't do that in CI.


From hans at guardianproject.info  Mon Jun 12 11:48:33 2023
From: hans at guardianproject.info (Hans-Christoph Steiner)
Date: Mon, 12 Jun 2023 13:48:33 +0200
Subject: breaking CI if build is not reproducible?
In-Reply-To: <20230607172122.7x4hjqi53lzwjv72@mars-attacks.org>
References: <7c4ab551-6c4d-0bb3-2054-171fb734fff2@gnieh.org>
 <8D1CDAF9-360E-412C-BBF7-739B058FA235@dwheeler.com>
 <20230607172122.7x4hjqi53lzwjv72@mars-attacks.org>
Message-ID: <1fa34886-b608-b7aa-fd37-a2421aa33226@guardianproject.info>



Nicolas Vigier:
> On Wed, 07 Jun 2023, David A. Wheeler wrote:
> 
>>
>>> On Jun 7, 2023, at 9:50 AM, Martin Monperrus <martin.monperrus at gnieh.org> wrote:
>>>
>>> Hi all,
>>>
>>> We're researching on build reproducibility.
>>>
>>> Are you aware of any project where reproducibility is checked in a continuous integration pipeline?
>>
>> I think the Tor project does, but you'd need to ask them to verify.
> 
> We manually check that each new Tor Browser release is reproducible.
> But we currently don't do that in CI.

F-Droid does it when app updates are submitted via merge request.

https://gitlab.com/fdroid/fdroiddata/-/merge_requests/

.hc

-- 
Signal: +13478504872
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://keys.openpgp.org/search?q=EE6620C7136B0D2C456C0A4DE9E28DEA00AA5556

From martin.monperrus at gnieh.org  Mon Jun 12 14:03:53 2023
From: martin.monperrus at gnieh.org (Martin Monperrus)
Date: Mon, 12 Jun 2023 16:03:53 +0200
Subject: breaking CI if build is not reproducible?
In-Reply-To: <1fa34886-b608-b7aa-fd37-a2421aa33226@guardianproject.info>
References: <7c4ab551-6c4d-0bb3-2054-171fb734fff2@gnieh.org>
 <8D1CDAF9-360E-412C-BBF7-739B058FA235@dwheeler.com>
 <20230607172122.7x4hjqi53lzwjv72@mars-attacks.org>
 <1fa34886-b608-b7aa-fd37-a2421aa33226@guardianproject.info>
Message-ID: <d974b45f-76ae-09cf-6c75-cd86c9e5bebc@gnieh.org>

Thanks @all for the valuable pointers. --Martin & all from Chains <https://chains.proj.kth.se/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20230612/5f8070ea/attachment.htm>

From vagrant at reproducible-builds.org  Tue Jun 13 23:05:27 2023
From: vagrant at reproducible-builds.org (Vagrant Cascadian)
Date: Tue, 13 Jun 2023 16:05:27 -0700
Subject: PackagingCon, Berlin, October 26-28 2023
Message-ID: <87sfavarpk.fsf@wireframe>

This seems like it might be a good conference for a reproducible builds
talk:

  https://packaging-con.org/

Call For Proposals closes end of July:

  https://cfp.packaging-con.org/2023/cfp

It is also the weekend before the Reproducible Builds World Summit in
Hamburg, so not too far from Berlin.

Unfortunately, not sure I will be able to make it, but... hopefully
someone can!

live well,
  vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20230613/d5db7df9/attachment.sig>

From email at marcelfourne.de  Fri Jun 16 09:03:20 2023
From: email at marcelfourne.de (Marcel =?iso-8859-1?Q?Fourn=E9?=)
Date: Fri, 16 Jun 2023 11:03:20 +0200
Subject: New research paper about Reproducible-Builds at IEEE 44th IEEE
 Symposium on Security and Privacy
Message-ID: <ZIwlWCOiCD6fYJ9Z@rechner.localdomain>

Dear all,

as some of you may know, since I worked with you on this, we just released our paper
"It?s like flossing your teeth: On the Importance and Challenges of Reproducible Builds for Software Supply Chain Security"
at IEEE S&P 2023 (informally "Oakland", https://sp2023.ieee-security.org/program-papers.html) and presented a short talk about it at the symposium.
While a talk recording may be published in the future, I want to share the final paper with you all, including an additional appendix:

https://publications.teamusec.de/2023-oakland-repro/

The focus of the paper is about security aspects of reproducible builds and why we need them as a prerequisite for any software supply chain security not founded on signing and trusting binaries of which we don't know how they were created.
I hope for further feedback from you and just like the interest from people during the conference - being encouraged to ramble about SBOMs on stage, how they behave more like hopefully kept up-to-date documentation.

Anyway, I hope to be of help and thank those of you who helped me compile this paper specifically as well as all of you for your interest and other work!

Cheers
Marcel

[N.B.: I had to change my previous mail address due to procmail rules and forgot to subscribe the new one. This is a repost of my initial mail.]

From email at marcelfourne.de  Fri Jun 16 08:54:52 2023
From: email at marcelfourne.de (Marcel =?iso-8859-1?Q?Fourn=E9?=)
Date: Fri, 16 Jun 2023 10:54:52 +0200
Subject: New research paper about Reproducible-Builds at IEEE 44th IEEE
 Symposium on Security and Privacy
Message-ID: <ZIwjXJeqJE+2gdHt@rechner.localdomain>

Dear all,

as some of you may know, since I worked with you on this, we just released our paper
"It?s like flossing your teeth: On the Importance and Challenges of Reproducible Builds for Software Supply Chain Security"
at IEEE S&P 2023 (informally "Oakland", https://sp2023.ieee-security.org/program-papers.html) and presented a short talk about it at the symposium.
While a talk recording may be published in the future, I want to share the final paper with you all, including an additional appendix:

https://publications.teamusec.de/2023-oakland-repro/

The focus of the paper is about security aspects of reproducible builds and why we need them as a prerequisite for any software supply chain security not founded on signing and trusting binaries of which we don't know how they were created.
I hope for further feedback from you and just like the interest from people during the conference - being encouraged to ramble about SBOMs on stage, how they behave more like hopefully kept up-to-date documentation.

Anyway, I hope to be of help and thank those of you who helped me compile this paper specifically as well as all of you for your interest and other work!

Cheers
Marcel

From marmarek at invisiblethingslab.com  Sun Jun 18 14:08:12 2023
From: marmarek at invisiblethingslab.com (Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?=)
Date: Sun, 18 Jun 2023 16:08:12 +0200
Subject: breaking CI if build is not reproducible?
In-Reply-To: <7c4ab551-6c4d-0bb3-2054-171fb734fff2@gnieh.org>
References: <7c4ab551-6c4d-0bb3-2054-171fb734fff2@gnieh.org>
Message-ID: <ZI8PzCNr0K0bMhtp@mail-itl>

On Wed, Jun 07, 2023 at 03:50:41PM +0200, Martin Monperrus wrote:
> Hi all,
> 
> We're researching on build reproducibility.
> 
> Are you aware of any project where reproducibility is checked in a continuous integration pipeline?
> 
> (For instance, by building twice in CI and comparing the output)
> 
> If yes, thanks to share here or via private email.

Qubes OS fails CI on non-reproducible packages too. We do that by using
reprotest and comparing against initial build in another CI job.
Currently we test that on Fedora and Debian (bookworm and bullseye), but
due to upstream issues, Fedora jobs are allowed to fail.

-- 
Best Regards,
Marek Marczykowski-G?recki
Invisible Things Lab
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20230618/7f51c226/attachment.sig>

From larry at doolittle.boa.org  Wed Jun 21 17:04:09 2023
From: larry at doolittle.boa.org (Larry Doolittle)
Date: Wed, 21 Jun 2023 10:04:09 -0700
Subject: Argument about reproducible builds on usenet in 1999
Message-ID: <ZJMtiVxu0+fO9xPz@doolittle.boa.org>

Friends -

December 1999 thread titled "Time independent checksum(cksum)" on comp.unix.programming.
Huge thanks to emolinare, who managed to save most of usenet and publish
it to usenetarchives.com in 2020.  I'm pretty sure this link will
get you to the thread:
  https://www.usenetarchives.com/view.php?id=comp.unix.programmer&mid=PDgyaDhsMyR2ZWYkMUBubnJwMS5kZWphLmNvbT4

The topics will all be very familiar to readers of this list.
It starts with Jayan asking about comparing binaries that might have
difference in their embedded timestamps.
Foreshadowing diffoscope, amiright?

The antagonist is David Schwartz, who correctly says "There are dozens
of complex reasons why what seems to be the same sequence of operations
might produce different end results," but goes on to say "I totally
disagree with your general viewpoint that compilers must provide for
reproducability [sic]."

Dwight Tovey and I (Larry Doolittle) argue for reproducible builds.
I assert "Any program -- especially a mission-critical program like a
compiler -- that cannot reproduce a result at will is broken."  Also
"it's commonplace to take a binary from the net, and check to see if
it was trojaned by attempting to recreate it from source."

Anyway, a possibly interesting trip down memory lane.  Is there a place in
reproducible-builds.org to talk about history?  The concept is clearly
much older than 1999.

  - Larry

From lunar at debian.org  Thu Jun 22 12:19:11 2023
From: lunar at debian.org (=?UTF-8?B?SsOpcsOpbXkgQm9iYmlv?=)
Date: Thu, 22 Jun 2023 14:19:11 +0200
Subject: Argument about reproducible builds on usenet in 1999
In-Reply-To: <ZJMtiVxu0+fO9xPz@doolittle.boa.org>
References: <ZJMtiVxu0+fO9xPz@doolittle.boa.org>
Message-ID: <fafd0210-1e83-21e7-2e5b-6d7fb46157eb@debian.org>

Hi!

On 21/06/2023 19:04, Larry Doolittle wrote:
> December 1999 thread titled "Time independent checksum(cksum)" on comp.unix.programming.
> Huge thanks to emolinare, who managed to save most of usenet and publish
> it to usenetarchives.com in 2020.  I'm pretty sure this link will
> get you to the thread:
>    https://www.usenetarchives.com/view.php?id=comp.unix.programmer&mid=PDgyaDhsMyR2ZWYkMUBubnJwMS5kZWphLmNvbT4
> 
> The topics will all be very familiar to readers of this list.
> It starts with Jayan asking about comparing binaries that might have
> difference in their embedded timestamps.
> Foreshadowing diffoscope, amiright?

Thanks for raising this up! :)

> Anyway, a possibly interesting trip down memory lane.  Is there a place in
> reproducible-builds.org to talk about history?  The concept is clearly
> much older than 1999.

The website has a page on history: https://reproducible-builds.org/docs/history/
If you feel like writing about these discussions, I guess it would be more than welcome.

The source for this page is visible online:
https://salsa.debian.org/reproducible-builds/reproducible-website/-/blob/master/_docs/history.md

The page is still very Debian-centric, as it was lifted from the Debian Wiki. It is missing a lot of events since 2016 (!) and could also benefit from contributions from other communities.

The best way would be to submit a merge request. How to join the group on the Salsa forge is explained on the following page https://reproducible-builds.org/contribute/salsa/

Cheers,
Lunar

From chris at reproducible-builds.org  Fri Jun 23 16:32:55 2023
From: chris at reproducible-builds.org (Chris Lamb)
Date: Fri, 23 Jun 2023 17:32:55 +0100
Subject: =?UTF-8?Q?diffoscope_243_released_=F0=9F=92=A0?=
Message-ID: <168753683200.1018908.13200387735100962112@copycat>

Hi,

The diffoscope maintainers are pleased to announce the release of
version 243 of diffoscope.

diffoscope tries to get to the bottom of what makes files or
directories different. It will recursively unpack archives of many
kinds and transform various binary formats into more human-readable
form to compare them. It can compare two tarballs, ISO images, or PDF
just as easily.

Version 243 includes the following changes:

  [ Chris Lamb ]
  * Drop Jenkins build reference in README.rst.

  [ Ed Maste ]
  * Update FreeBSD package names

  [ Mattia Rizzolo ]
  * Improve the documentation on to produce that binary blob that in the arsc
    comparator.

## Download

Version 243 is available from Debian unstable as well as PyPI, and
will shortly be available on other platforms surely. More details can
be found here:

   https://diffoscope.org/

? but source tarballs may be located here:

  https://diffoscope.org/archive/

The corresponding Docker image may be run via (for example):

  $ docker run --rm -t -w $(pwd) -v $(pwd):$(pwd):ro \
      registry.salsa.debian.org/reproducible-builds/diffoscope a b


## Contribute

diffoscope is developed within the "Reproducible builds" effort.

  - Git repository
    https://salsa.debian.org/reproducible-builds/diffoscope

  - Docker image, eg.
    registry.salsa.debian.org/reproducible-builds/diffoscope
    https://salsa.debian.org/reproducible-builds/diffoscope

  - Issues and feature requests
    https://salsa.debian.org/reproducible-builds/diffoscope/issues

  - Contribution instructions (eg. to file an issue)
    https://reproducible-builds.org/contribute/salsa/


Regards,

-- 
      o
    ?   ?      Chris Lamb
   o     o     reproducible-builds.org ?
    ?   ?
      o