Hacker News Reader

Comment by eikenberry | Hacker News Reader

This plus reproducible builds will go a long ways toward preventing it.

I would be careful about claiming built artifacts play much role in the visibility of repository-delivered malware. Consider "reflections on trusting trust" for attacks on reproducible builds, and also that all the major scripting languages (PyPI, Ruby gems, and npm) have had malicious packages inserted over the last year or so.

> all the major scripting languages (PyPI, Ruby gems, and npm) have had malicious packages inserted

None of those package repositories are maintained by a limited set of curators.

Debian's repositories and other linux distributions repositories are curated.

Uploading a malicious package to npm is as easy as typing 'npm publish'.

> "reflections on trusting trust"

It's a very useful piece of art and a thought experiment.

In practice, it's not interesting for the average package. Very few packages are self-hosting and in such a position to leverage that sort of clever trickery.

A good debian maintainer will also review code of their packages and make sure such trickery has no chance to be afood (e.g. by preventing a gem from downloading a custom ruby interpreter to bootstrap itself, but rather manually bootstrapping up themselves).

The point of "... trusting trust" is not really the specific bug, but rather the observation that the whole supply chain matters. Built artifacts as exist on disk in the repo are a relatively small piece of that.

> None of those package repositories are maintained by a limited set of curators.

It's always interesting to me how few people seemingly know this. Python package maintainers realize how easy it is to add packages to PyPI, but many admins and even SOC operators inherently trust it because they think that it "must be reviewed by someone".

Also, there have been plenty of security issues with Ubuntu and Debian: https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue52#Commu... https://www.linuxinsider.com/story/32240.html

Also there have been bugs in apt: https://www.fosslinux.com/6167/massive-security-bug-found-in...

Also the official ISO from the Mint website: https://arstechnica.com/information-technology/2016/02/linux...

Also the AUR malware mentioned on thread: https://www.bleepingcomputer.com/news/security/malware-found...

Also the kernel.org compromise: https://www.zdnet.com/article/linux-kernel-source-code-repos...

Edit: let's throw in the redhat ceph intrusion while we're at it (note that this includes InkTank). https://www.zdnet.com/article/red-hats-ceph-and-inktank-code...

> The point of "... trusting trust" is not really the specific bug, but rather the observation that the whole supply chain matters.

There's a really fascinating project by the authors of TUF called in-toto[1] that addresses exactly this problem.

[1] https://in-toto.github.io/

I don't like when "Reflections on trusting trust" is used as an excuse to throw the hands in the air and not doing anything. Sure, it's not perfect, but the reproducible-builds people are doing important work that makes it considerably harder to inject malware into distribution repos.

I'm sorry, but the logical fallacy of "We must do something; This is something; Therefore, we must do this." is the worst attitude to have for security. Not only you will never end with anything actually important done, it will also justify all the evil that will be done in the name of security.

And nobody says that not doing anything is ok, but please do it properly, do some basic threat modeling first.

P.S. I'm not against reproducible builds, I think they are useful for many things, just not for security. They may even let us do decentralized trustless peer-to-peer build system someday.

The hard part about the security of built artifacts is not building them, it's auditing the source looking for bugs. Reproducible-builds doesn't audit the source, but many act like they think it does. Added to this is the host of other security issues with the chain between the developers keyboard and your system. This solves none of them, but many act like they think it does.

Therefore, in my view it provides a smallish real benefit and a large moral hazard.

Science is hard. Superstition is fast and might save your job, at least for awhile.

I want this on a shirt.

>A good debian maintainer will also review code of their packages and make sure such trickery has no chance to be afood

Except for that time that Debian developers "knowing better" completely neutered most cryptography on all updated Debian systems[1]:

>Affected keys include SSH keys, OpenVPN keys, DNSSEC keys, and key material for use in X.509 certificates and session keys used in SSL/TLS connections. Keys generated with GnuPG or GNUTLS are not affected, though.

Massive, rapid key rotation schemes had do be implemented to cover their screwup because all keys were trivially enumerable, to the point where all affected keys were blacklisted[2].

[1] https://www.debian.org/security/2008/dsa-1571

[2] https://security.stackexchange.com/questions/3422/what-is-th...

Reproducible builds can't prevent hidden malware. They don't do much at all for security.

They can't prevent it but they can help it become visible. Without reproducible builds, nobody has an easy way to verify that a specific binary corresponds to a specific deemed safe bit of source code. There can still be source code based attacks by upstream maintainers of course. In fact most attacks in the past were in source based languages like JavaScript but without reproducible builds the situation would be much worse.

> In fact most attacks in the past were in source based languages like JavaScript but without reproducible builds the situation would be much worse.

This is incorrect. It wouldn't make a single difference.

It forces logging of the malware, globally. That's worse than maybe getting caught.

If you assume that the build systems and the distribution are secure.

If somebody had stolen the signing keys and could do a https://www.cloudflare.com/learning/security/glossary/bgp-hi... there will be no trace.

Bugs in the build system are just bugs, quite possibly security bugs but still set in stone. Reproducible builds have no point if you distribution is broken and cant actually cant verify they are reproduced. You could have just asked "What if the reproduced build isn't?". It's not a reason to not be able to reproduce the image.

We know how to publish the input and output hashes. It's one of the use cases for a global ledger. Using CF's trust root would be pointless.

Reply on news.ycombinator.com