compliance with the license requires that further distributions retain or
reproduce copyright notices."
For more details, see the web page.
--- David A. Wheeler
Unix line-endings (\n), but if I clone a Windows
repo,
most of the tools will quietly use that other format, and I wouldn't normally
even notice.
This kind of thing *can* create mysterious reproduction problems, so I think
it's in scope
for this mailing list.
--- David A. Wheeler
ar "reproducible builds are impractical". Yes, in some cases
they're hard, but clearly there are cases where it's practical.
--- David A. Wheeler
oad the rest, and the cryptographic hashes for
what is not bundled.
--- David A. Wheeler
to me if this was some sort of special set of "test
packages" or if they were the normal Arch Linux packages.
--- David A. Wheeler
uild reproducibly while varying the
build-path,
reproducible builds are easier to create, and that's a good thing even if not
strictly required.
--- David A. Wheeler
a
container/chroot or similar that makes it easy to implement "must compile with
these paths",
while *fixing* this is often a lot of work.
I suggest focusing on ensuring everyone knows what the executable files
contain, first.
if people can add more flexibility to their build process, all the better, but
that added flexibility
comes at a cost of time and effort that is NOT as important.
--- David A. Wheeler
ws.
My webpage on DDC has become a complicated meander of cross-references to many
works that are DDC-adjacent, including reproducible builds, bootstrappable
builds, quines, and recreating Thompson's attack demonstration. As always, you
can see more here: <https://dwheeler.com/trusting-trust/>
--- David A. Wheeler
e part of every
Linux distro package's test suite. Then it's immediately clear that something
went wrong.
--- David A. Wheeler
>> On Aug 2, 2023, at 8:31 AM, Chris Lamb wrote:
>> Hi all,
>> Please review the draft for July's Reproducible Builds report:
>> https://reproducible-builds.org/reports/2023-07/?draft
> On Aug 2, 2023, at 10:04 AM, David A. Wheeler wrote:
> Sphinx just me
calls for list and tuple datatypes. As a result,
documentation generated by Sphinx will be more likely to be automatically
reproducible.
(Sorry I can't hop on to the git repo right now, but I hope that helps.)
--- David A. Wheeler
"it's possible to create reproducible builds" or
"the packages people are using are the reproducible builds".
Sorry if this is obvious to everyone else.
--- David A. Wheeler
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
> On Jun 2, 2023, at 12:26 PM, Andreas Enge 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
urrent version of OSSGadget and the answer is what it says". It's a very
straightward operational definition once put that way :-).
--- David A. Wheeler
s/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
> On May 30, 2023, at 10:51 AM, David A. Wheeler wrote:
> I'll file an issue with OSSGadget <https://github.com/microsoft/OSSGadget/>
> to propose that they rename "semantically reproducible build" to
> "semi-reproducible build",
> but I can't
s
what they were calling it before I asked them to clarify things with a
different term).
Again, if a builder is willing to create fully reproducible builds, that's even
better.
But many users can't change what the builders choose to do, so it's better
to have an alternative to "hope nothing goes wrong".
--- David A. Wheeler
kbuild/reproducible-builds.html
If that page doesn't cover the need, and you find a solution, please propose an
improvement to that document. Thanks!
---David A. Wheeler
process),
it's useful to look for some *workable* backoff alternatives. The backoffs may
not give
you all you wanted, but they can at least help users focus on their biggest
risks first.
In any case, I thought it'd be important for this group to learn about this
approach,
in cases where it might be useful to you.
--- David A. Wheeler
On Sun, 28 May 2023 21:10:36 -0700, Vagrant Cascadian
wrote:
> Do such tools actually exist, or are we talking about something
> theoretical here? I am nervous about investing too much energy in
> something without a specific, precise, working proof of concept.
>
> In your earlier mention o
put the official binary.
For a Linux *distributor* this makes sense. If you have control over the
build process, a more rigorous build process is great, and hardening that
build process against attacks is a wonderful idea (e.g., OpenSSF's SLSA).
As a *recipient* who has no control over the build process used by
someone else to create their package, I need some workable
alternatives to estimate risk.
Thanks!
--- David A. Wheeler
e malicious code
to execute in a reasonably-coded app, then that *would* be a problem.
"What's reasonable" is hard to truly write down, but a
whitelisted list of specific filenames seems like a reasonable place
to start.
Sure, ideally everything would have a reproducible build.
Since that day isn't here, what can we do to take piecemeal
steps towards that?
--- David A. Wheeler
ontrast, and
that makes it clear that a normal "reproducible build" is the stronger test
(at the cost of being sometimes harder to achieve).
--- David A. Wheeler
producible build is *also* a semantically reproducible build.
My hope is that if someone wants a reproducible build, they'll use that term.
However, If they want to talk about this backoff approach, they'll have a
clearly
*different* but *related* term they can use, eliminating a sourc
nism, and then have *actual* packages reproducible, than
be strongly confident in the packages no one uses.
--- David A. Wheeler
Maybe call it "Ways to combine reproducible builds with signatures and other
metadata"?
--- David A. Wheeler
> On Feb 1, 2023, at 2:07 PM, FC Stegerman wrote:
>
> * "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:
>>
bedded within executables.
That's wrong, but making it clear to others why it's wrong would be helpful.
Is there agreement on adding such a page?
--- David A. Wheeler
> On Feb 1, 2023, at 12:12 PM, Marc Prud'hommeaux via rb-general
> wrote:
>
>
> I recently
id,
reproduce the item being signed, and so on.
If you have to understand the nuances of the ELF or PE format to determine
if a signature is valid, you've already failed.
--- David A. Wheeler
to attest something
about the thing signed. Merging them into one object leads to all sorts
of strange conundrums like this.
--- David A. Wheeler
s not to eliminate all possible risk - that is impractical.
Instead, the goal is to reduce risks to acceptable levels. We can do a *lot*
today to reduce those risks. Today, what's under attack is the software... so
let's do our part to counter those attacks.
--- David A. Wheeler
> On Oct 5, 2022, at 3:50 PM, Chris Lamb wrote:
>
> Hi all,
>
> Please review the draft for September's Reproducible Builds report:
>
> https://reproducible-builds.org/reports/2022-09/?draft
As always, thanks! A few proposed tweaks below.
--- David A. Wheeler
==
#x27;t
release built
software, and that timestamp differences by *themselves* don't indicate
malicious changes.
If you have opinions (pro or con) please post on that GitHub issue.
For your convenience, I've copied the main text of the issue below.
--- David A. Wheeler
Som
le.
Their press release is here:
https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/3146465/nsa-cisa-odni-release-software-supply-chain-guidance-for-developers/
--- David A. Wheeler
uild being reproduced (NOT for the actual
running kernel).
The latter *does* work fine for a container (as I noted earlier).
Again, this is informed speculation on my part. I'm trying to anticipate a
potential
problem so that GitBOM & reproducible builds can work together. If anyone has
better ideas,
or can show that my concerns aren't real, I'd love to know.
Thanks!
--- David A. Wheeler
tweak to this would then be straightforward: Delete the PGO data and
ensure that you can rebuild it & pass all tests. It's a few extra steps in the
automated release process.
--- David A. Wheeler
before they become problems.
I'm posting to reproducible-builds, but also plan to post to this for GitBOM, so
that both communities can look at the issue.
Details below.
--- David A. Wheeler
==
BACKGROUND
GitBOM is explained at <https://gitbom.dev/>. As they expla
o annoying to lose a nontrivial amount of performance?
Thoughts? Does anyone have any better ideas for making PGO reproducible?
Thanks.
--- David A. Wheeler
m/rust-lang/rust/issues/97955> (now closed)
that --remap-path-prefix can be used to solve the problem today, and
is a trick Bazel & Nix use. That said, I agree that the better long-term
solution is to make the *default* reproducible.
Thanks.
--- David A. Wheeler
*is* a good first step.
If you know of other build tools where this is a problem, I encourage
filing bug reports with them too.
Thanks!
--- David A. Wheeler
x27;s easier if
they're always handled separately; it reduces the risk of incorrect handling.
--- David A. Wheeler
lnerabilities, and also to update their software faster when
vulnerabilities
are found. So yes, let's get those countermeasures going for advanced attacks.
But don't build the back wall high when the attacker can walk through the front
door.
--- David A. Wheeler
Quick clarification: When I said:
> You can (and should) build environments...
I meant:
> You can (and should) *harden* build environments...
--- David A. Wheeler
to them).
It won't be perfect (nothing ever is), but it will at least start to
provide a counterweight to endlessly adding unnecessary complexity.
If you have other suggestions on how to counter these I'd
love to hear them :-).
--- David A. Wheeler
library, was especially
annoying.
Hopefully all of these have been addressed now. I can't remember if I reported
these to the GCC developers, I hope I did but it's been years now.
The moral of the story is that if you want something to work through different
versions, you have to run automated tests for it :-).
--- David A. Wheeler
inks GitHub *does* need to change something, I’d like to know
exactly what practical change is desired.
--- David A. Wheeler
> On Oct 23, 2021, at 3:01 PM, Paul Spooren wrote:
>
>
>
>> On 23. Oct 2021, at 08:55, Bernhard M. Wiedemann
>> wrote:
>>
>>
>>
>>> On 23/10/2021 20.14, David A. Wheeler wrote:
>>>
>>> A given version of tar shoul
iler will generate different results.
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 would
you suggest as an alternative?
--- David A. Wheeler
cboot.html
In tccboot, you boot a tiny C compiler which can compile the Linux kernel, and
then boot from there.
--- David A. Wheeler
ing *CAN* be deterministic.
The problem is that some low-level implementations fail to be deterministic
(e.g., because they don’t force a sort order).
I think it’s not that hard from a technical view. It’s just that the people at
those levels need to agree that it’s an issue & be willing to fix it.
--- David A. Wheeler
The Linux Foundation doesn’t currently fund the
reproducible-builds.org project itself
(we have in the past), we *do* currently fund some individuals working on
reproducible builds work.
Real life is complicated to capture :-).
--- David A. Wheeler
ecurity work, including more
about progress on reproducible builds.
--- David A. Wheeler
be
able to
Perform the attacks, and that’s a *good* thing.
--- David A. Wheeler
s to contest any tests that
cannot be replicated.
--- David A. Wheeler
lds (e.g., GNU Mes).
Bootstrappable builds & DDC aren’t really competitors, because
they can work well together to even-more-powerfully counter such attacks.
The recording is wiggly (it wasn’t professionally recorded), but it should be
understandable.
Enjoy!
--- David A. Wheeler
ly imperfect.
How about this as the 1-sentence summary?:
“sigstore is designed to enable simpler cryptographic signing & signature
verification”?
--- David A. Wheeler
uild *is* generated from a given source; sigstore can let you
verify that you got the *correct* source or build.
--- David A. Wheeler
> On Jan 30, 2021, at 7:22 AM, Holger Levsen wrote:
>
> On Fri, Jan 29, 2021 at 05:39:01PM -0500, David A. Wheeler wrote:
>> What would be especially helpful for accelerating deployment of verified
>> reproducible builds in a few key places? E.g., what tools, infrastruc
ible builds in a few key places? E.g., what tools, infrastructure,
people paid to do XYZ?
Thanks!
--- David A. Wheeler
igh-quality results. I don’t approve of
arrogance, but I *do* appreciate that they have to say “no” a lot. Which is why
r-b needs *more* media attention; those engineers need to prioritize what’s
important, and so we need to make it clearer that this is important.
--- David A. Wheeler
ts (DDC & bootstrapping).
The long-term goal should be that “we can ensure that all OSS compiled code is
accurately represented by its source code”. The source code may include
malicious statements, but source code is what developers review, so we’ve
fundamentally changed the game to ensure tha
Winds, and none of them mention
reproducible builds, even though reproducible builds is clearly a
countermeasure to this problem. Perhaps journalists will eventually learn about
reproducible builds; that would be nice!
--- David A. Wheeler
PS: Here are some articles about the attack on SolarWi
e need to step up our compiler diversity and OS diversity for for
> future tests!
Excellent!
--- David A. Wheeler
to gain confidence in a
reproducible bootstrap.
Thanks so much!
--- David A. Wheeler
ing forward to the day where typical installations have 100%
reproducible
software. But getting there requires that it be easy to achieve.
This looks like it might help us get there. Thanks!
--- David A. Wheeler
On July 27, 2019 9:42:40 AM EDT, Chris Lamb wrote:
>Just in case it helps, this might not be exactly what you are after
>but the thread on debian-devel may contain some info or references
>that contain the answers you seek:
>
> https://lists.debian.org/debian-devel/2019/07/threads.html#00391
Tha
This seems unfortunate... and maybe it's fixable long-term.
--- David A. Wheeler
___
rb-general@lists.reproducible-builds.org mailing list
To change your subscription options, visit
https://lists.reproducible-builds.org/listinfo/rb-general.
To unsu
On Thu, 02 May 2019 05:41:38 -0400, "Chris Lamb" wrote:
> Please review the draft for April's Reproducible Builds report:
>
> https://reproducible-builds.org/reports/2019-04/?draft
Looks good. As always, thanks for doing tha
> On Thu, Apr 18, 2019 at 05:03:18PM -0400, David A. Wheeler wrote:
> > A build is reproducible if given the same source code, build environment,
> > and build instructions, any party can independently verify all specified
> > artifacts it produces (e.g., executables) by
> On Thu, Apr 04, 2019 at 11:25:25AM -0400, David A. Wheeler wrote:
> > The front page has this definition:
> > > Reproducible builds are a set of software development practices that
> > > create an independently-verifiable path from source to binary code.
> >
uot; if you think that artifacts is too
abstract.
Can we simply copy this definition to the front page & use this definition
instead on https://reproducible-builds.org/ ?
Sorry to (re)start a definition war, but when I came back to look at the
definition (while trying to explain it to someone e
>I have been looking at making GNU Octave build reproducibly.
As an Octave user, that is excellent!
> Similarly to other interpreted
>languages, the compiler options used are stashed in the binary for later use.
I don't know what everyone else here believes, but I recommend that those not
be
e.
Every time a package is made reproducible eliminates another place
where binaries can have undetected malicious code inserted
(assuming the toolsuite is not malicious), and the continued progress
might even dissuade attackers from trying.
--- David A. Wheeler
__
rom the ASF, and thought you'd like to
know.
--- David A. Wheeler
___
rb-general@lists.reproducible-builds.org mailing list
To change your subscription options, visit
https://lists.reproducible-builds.org/listinfo/rb-general.
To unsubscribe, se
tain properties. That work might be of use in this case as
well.
More general information about my approach is here:
https://dwheeler.com/trusting-trust/
--- David A. Wheeler
___
rb-general@lists.reproducible-builds.org mailing list
To change your sub
On November 18, 2018 12:29:39 PM EST, Gerardo Ballabio
wrote:
>Richard Parkins wrote:
>> Most binary file comparators just compare bytes, which doesn't detect
>deletions or insertions.
My personal workaround is to generate 1 byte in hexadecimal on each line, and
then use regular diff -u. Diff
think the 57% figure is a big deal - it's an astonishing achievement, really.
But it is a little tricky to explain. Thanks again for the help!
--- David A. Wheeler
___
rb-general@lists.reproducible-builds.org mailing list
To change your subscription op
>I would skip the numbers or put them last in the news bit.
>Or mention our non-real-world (higher) reproducibility percentage as
>well, otherwise this is plain confusing, despite the TL;DR explaination
>that follows.
I like the idea of including the non real world percentage as well, and
expla
;, but
of the actual "real world" Debian packages including corroborating
.buildinfo files.
Does that capture things correctly?
I'll try to add something like that in a little bit to the announcement file,
but I fear I'm stating someth
ne's been doing. Quite the opposite; I think this is *important*.
--- David A. Wheeler
___
rb-general@lists.reproducible-builds.org mailing list
To change your subscription options, visit
https://lists.reproducible-builds.org/listinfo/rb-general.
ffs" where different organizations in different
places can build things & verify that they got the same result.
That might give a lot more visibility to the reproducible builds work.
It might even be easier to get funding for the remaining pieces:
"Parts X and Y as delivered to users ar
he weekly reports might be a
> better reflection of this quotidian work rather than the mailing
> list which will by-and-large just handle the exceptional cases.
Understand.
My email may have come off harshly, and I didn't mean it that way.
I'm a big fan of the reproducible build
from following the mailing
list. In any case, once more "real systems people use" are reproducible, I
think it will be much easier to get additional people to improve their
flexibility (e.g., improving tar programs).
-- David A. Wheeler
_
> On 2018-10-23, "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.
On Tue, 23 Oct 2018 11:01:19 -0700, Vagrant Cascadian
wrote:
> There ar
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.
The Debian web page on this shows the progress on packages, which is
impressive, but it doesn't give any sense of how many of the most important
packages are
86 matches
Mail list logo
