3 ms·

"oops, our bad, we'll improve security" It won't end their business and it's currently a single point of failure. Having and checking pgp signatures would mea

by Aachen 3y ago

"oops, our bad, we'll improve security" It won't end their business and it's currently a single point of failure. Having and checking pgp signatures would mean the developer and Microsoft/GitHub have to both get compromised, which is a risk I'd much more readily take than github never ever getting compromised for security-critical software like ssh or its dependencies Edit: realised this isn't true unless github starts doing code reviews. The developer can still always push anything. But by having digital signatures, you could require both devs to OK a change or release. Or, at least not everything is compromised if github is compromised: every developer would have to be compromised separately to forge all signatures. Using github as the single point of trust seems like an exceedingly large problem waiting to happen at least once in our lifetimes

londons_explore 3y ago
Since the code, the build process, and the final signed tarball would all be made available to the public in the case of these 'verified builds', it would only take one person to rebuild and diff the results to uncover any malpractice by github. Obviously in most cases, any differences will be bits of the build process that are nondeterministic like including timestamps in the final binary.
woodruffw 3y ago
One of the key observations from PyPI’s removal of PGP support was that virtually nobody actually verified the signatures uploaded to the index (when they were actual signatures, and not just garbage or error files), and that most of their backing keys were expired, weak, or otherwise impossible to publicly establish. Independent signatures do mean that the author could stymie a compromise of their source host. But on net, users are worse maintainers of cryptographic key materials (and worse users of obtuse ecosystems like PGP) than big companies are. That doesn’t mean we shouldn’t enable user signing; only that we need better, more misuse-resistant tools for it.
- Aachen 3y ago
  In response to the last sentence (copying function broke here, idk why but so I can't easily quote): agreed, though it seems odd to throw out the existing solution before having a new one, preferring no solution over a partial one

by Aachen 3y ago

londons_explore 3y ago

Since the code, the build process, and the final signed tarball would all be made available to the public in the case of these 'verified builds', it would only take one person to rebuild and diff the results to uncover any malpractice by github. Obviously in most cases, any differences will be bits of the build process that are nondeterministic like including timestamps in the final binary.

woodruffw 3y ago

One of the key observations from PyPI’s removal of PGP support was that virtually nobody actually verified the signatures uploaded to the index (when they were actual signatures, and not just garbage or error files), and that most of their backing keys were expired, weak, or otherwise impossible to publicly establish. Independent signatures do mean that the author could stymie a compromise of their source host. But on net, users are worse maintainers of cryptographic key materials (and worse users of obtuse ecosystems like PGP) than big companies are. That doesn’t mean we shouldn’t enable user signing; only that we need better, more misuse-resistant tools for it.

Aachen 3y ago
In response to the last sentence (copying function broke here, idk why but so I can't easily quote): agreed, though it seems odd to throw out the existing solution before having a new one, preferring no solution over a partial one