undefined | Better HN

0 pointsMomsAVoxell1mo ago0 comments

Reproducible builds are applicable not only to respond to ‘attacks’, a subject you seem to be bikeshedding, but also for other reasons too.

Anyone having to maintain a code base or a distributed fleet of devices will gain from this decision, immensely, as their operational periods come and go.

Reproducible builds are about longevity as much as they are about security.

Please don’t make bold claims about ‘no reason and little benefit’ while demonstrating ignorance of this hard fact: reproducible builds should have been the norm, in computing, from the get-go.

0 comments

6 comments · 2 top-level

bluGill1mo ago· 3 in thread

I longevity is harmed though. Your certs need to expire in a few years we think that your toolchain will not be downloadable.

yjftsjthsd-h1mo ago

> your toolchain will not be downloadable.

Why not? Debian has a fantastic track record of providing old versions, for instance here's the build tools from Debian 2.0 from 1998:

https://mirrors.accretive-networks.net/debian-archive/debian...

MomsAVoxellOP1mo ago

Those problems need to be solved as well.

bluGill1mo ago

I don't think they do, actually. Longevity sounds good, but in reality anything that's old probably has critical security holes and so you shouldn't use it anyway.

3 more replies

PunchyHamster1mo ago· 1 in thread

> Anyone having to maintain a code base or a distributed fleet of devices will gain from this decision, immensely, as their operational periods come and go.

Just baking in build ID and commit is enough. What you think reproducible builds add ?

> Please don’t make bold claims about ‘no reason and little benefit’ while demonstrating ignorance of this hard fact: reproducible builds should have been the norm, in computing, from the get-go.

So far not a single person in the thread gave me concrete example (as in existing project, existing problem, no other solution can solve it). Just claiming it's better based on their feelings. Come on, be the first one.

MomsAVoxellOP1mo ago

I already gave you an example, you dismissed it because you know better, but it is clear that you haven’t thought this through from the perspective of systems designers who have to deploy a base OS, with expected lifetimes of years, across a large fleet of devices.

Think industrial applications, such as rail and heavy industry transportation. We use reproducible builds here as part of a wider safety-critical protocol which guarantees that what we are running is what we expect to run - nothing more, nothing less.

Reproducible builds are certifiable. They can be relied on in environments where certification costs millions and takes years.

Think outside your consumer box for a minute.

j / k navigate · click thread line to collapse

0 comments

6 comments · 2 top-level

bluGill1mo ago· 3 in thread

I longevity is harmed though. Your certs need to expire in a few years we think that your toolchain will not be downloadable.

yjftsjthsd-h1mo ago

> your toolchain will not be downloadable.

Why not? Debian has a fantastic track record of providing old versions, for instance here's the build tools from Debian 2.0 from 1998:

https://mirrors.accretive-networks.net/debian-archive/debian...

MomsAVoxellOP1mo ago

Those problems need to be solved as well.

bluGill1mo ago

I don't think they do, actually. Longevity sounds good, but in reality anything that's old probably has critical security holes and so you shouldn't use it anyway.

3 more replies

PunchyHamster1mo ago· 1 in thread

> Anyone having to maintain a code base or a distributed fleet of devices will gain from this decision, immensely, as their operational periods come and go.

Just baking in build ID and commit is enough. What you think reproducible builds add ?

MomsAVoxellOP1mo ago

Reproducible builds are certifiable. They can be relied on in environments where certification costs millions and takes years.

Think outside your consumer box for a minute.

j / k navigate · click thread line to collapse