[PunchyHamster]

I know why they are useful. I am arguing they are waste of time for effort involved.

Forcing devs to use hardware keys to sign commits/CI requests would be actual security improvement, thwarting many supply chain attacks that only worked coz the attacker got to developer credentials. Hardware keys at least have option to make some operations require physically pressing the key so there is chance developer will notice.

But thanks to reproducible builds, at least someone can... validate that the binary code of vulnerable package can be reproduced. Very fucking useful.

I am not saying it is useless. I am saying it is one of highest hanging fruits on security tree.

[uecker]

A hardware key does not help if the developer's machine is compromised, as there is no change to understand what is signed anymore, or do you think the hardware key will show all the source code on its little display before signing?

With reproducible builds, you do not need to trust that the system that build the binary was not compromised, because this would be detected immediately.

Source compromises are still an issue, but there is a much bigger change that they are detected. Also if there is a compromise, reproducible builds allow you to later track it to the source. For an infected binary it is much more difficult to understand how it got there and what else might be compromised.

[PunchyHamster]

The way at least YK works is that you can set it up that pressing a key is requires for signing so at least "silently steals creds and sends malicious code" case (which is vast majority of compromises) gets handled

> Also if there is a compromise, reproducible builds allow you to later track it to the source.

They do not. Git log and build logs allow for that.

Reproductive builds only have value after the source. They protect build servers from being compromised (and then only if some other uncompromised environment is also running verification passes), if the bug is at source reproductive builds are exactly as valuable as writing commit that was used for build in app's code/package metadata.

[uecker]

If your compiler (or other tool or automatic build environment) is compromised and inserts a backdoor in the binary during building, the fact that you need to hold a key while signing or not is completely irrelevant.

git log and build logs do not help you at all, if you can not even determine that the compromised binary has any relation to the build log or the source you may want to look it. This is what reproducible builds give you. You are right that it does not protect against compromised sources.

[rstuart4133]

> I know why they are useful. I am arguing they are waste of time for effort involved.

Not being reproducible is a bug.

There is no reason for a build to not be reproducible, but somehow we let the built binaries become infested with timestamps, login names and file system paths. We recently moved to reproducible builds at work, and discovered that our login names and local home directory paths were being shipped in every release. No one was was very happy about leaking PPI like that.

You may not consider it worth the effort, but you aren't the one putting in the effort so I'm not sure why that matters to you. It is very much worth the effort to those people doing the work. Debian is a do-orcracy and so the people doing the work get to make the decisions.