News for hackers. Stuff that matters.
Re:Linus' reply on Git and SHA-1 collision by stonogo on Friday February 24, 2017 @02:43AM (#13721806)
Sounds like sentence three is where you got it wrong. You should be pulling your software to a development host, building it after verification, and uploading the deployment package to an artifact repository inside your security perimeter. Sentence three becomes 'pull library X from my artifact server.'

There is no way to securely deploy a package directly from the internet. The sooner you understand that, the sooner you'll be able to sleep through needless catastrophes like this hypothetical attack -- or leftpad.js.

Re:Linus' reply on Git and SHA-1 collision by Perseids on Friday February 24, 2017 @04:04AM (#13722164)
> There is no way to securely deploy a package directly from the internet.

Fetching a file from the internet and verifying it against a hash or signature is the only way to securely deploy a package from the internet. This is exactly one of the use cases theses cryptographic primitives are built for. Don't blame the users when they utilize the tools the way they are supposed to be, blame the tools when they fail when doing so.

And by the way, if you ever need to run `apt-get upgrade` or `apt-get install` on your production server from a public mirror, then you are guilty of "deploying a package directly from the internet", too. (My apologies and congratulations if don't.)

Re:Linus' reply on Git and SHA-1 collision by raverbashing on Friday February 24, 2017 @04:50AM (#13722340)
apt-get can (and do) check signatures of repos

But yeah, you could put an unverified repos to be used

Re:Linus' reply on Git and SHA-1 collision by Perseids on Friday February 24, 2017 @05:47AM (#13722565)
For the argument at hand (Can you deploy anything on a production server from a third party that is only verified cryptographically?) signatures and hashes fulfill the same function (and btw I also wrote "verifying it against a hash or signature" above). More to the point, under the hood GPG signatures only sign a hash of the file in question anyway. Verifying a file via a GPG signature is strictly less secure than verifying it by its hash (assuming you use the same hash function as the signature).
Re:Linus' reply on Git and SHA-1 collision by lmm on Friday February 24, 2017 @05:02AM (#13722406)
Git has tag signing, surely there's a way to clone a specific tag and check the signature against a specific GPG key fingerprint?
Re:Linus' reply on Git and SHA-1 collision by nhaehnle on Friday February 24, 2017 @06:22AM (#13722689)
Tag signatures only cover the mapping from tag name to commit hash. In other words, specifying a manually-verified commit hash is actually more secure.

Tag signatures are mostly worthless now from a crypto point of view -- with the caveat that you can still get some value from them if you still trust sha1 to be secure against second-preimage attacks.

Re:Linus' reply on Git and SHA-1 collision by heartsucker on Friday February 24, 2017 @06:19AM (#13722678)

    git checkout 0.1.0
    git tag -v 0.1.0
Re:Linus' reply on Git and SHA-1 collision by amingilani on Friday February 24, 2017 @04:01AM (#13722153)
Either way he'd be pulling from Github.com at some point, whether in the build environment or production. He won't ever know that the repository was compromised.

Besides, some people use Heroku simply to deploy their rails or node apps, and they don't have an artefacts server.