4 ms·

I do trust github with anything where any dishonesty on their part would be discoverable from the end result. Just a single piece of strong evidence that githu

I do trust github with anything where any dishonesty on their part would be discoverable from the end result. Just a single piece of strong evidence that github the company had injected malware into something (rather than a github user) would end their business.

perihelions 3y ago
I think we should have learned this lesson by now. The revelation that GitHub deliberately injects malware into things would be unlikely to "end their business": it would contentiously divide their userbase between purists who believe repo hosts should not be injecting malware into people's FOSS projects, and pragmatists who defend the trust-and-safety reasons for injecting malware into FOSS (say, to assist US intelligence preventing terror attacks). We've had this recurring discussion in many forms, and the typical result is that peoples' capacity for outrage wears out quickly. Who still remembers, for instance, that the GitHub entity sabotaged its users by giving the NSA backdoors to its private infrastructure [0]? How much business is Microsoft missing out on today, in 2024, because of that betrayal of trust? Essentially none, right? They're bigger than ever. GitHub sneaking NSA malware onto their platform—maybe selectively serving it to certain targets—would be perfectly in character with their past behavior. It would be smart business sense (they're a major DoD vendor). It'd be totally irrational to have a faith-based trust that they wouldn't do this. (There's a precedent: the FOSS host SourceForge destroyed itself by making the error of judgement of injecting code into people's repos [1]. But that was a decade ago: the Overton Window's shifted a lot. What SourceForge lost their business for doing in 2013—injecting ads—is something Microsoft comfortably gets away with today, on Windows desktops). [0] https://news.ycombinator.com/item?id=6027779 https://news.ycombinator.com/item?id=6027779 ("How Microsoft handed the NSA access to encrypted messages" (2013)) [1] https://en.wikipedia.org/wiki/SourceForge#Adware_controversy https://en.wikipedia.org/wiki/SourceForge#Adware_controversy
- hyperpape 3y ago
  Whether or not you draw a distinction, it seems plausible that the world as a whole would draw a distinction between sharing encrypted messages with the NSA and deliberately injecting malware into widely distributed software. Corporations can look at the former and think it is unlikely to affect them. So regardless of how bad its prior behavior is, it makes sense that Microsoft has more of a reason to try to keep software distributed through GitHub as secure as it reasonably can.
  - peteradio 3y ago
    How about they just put a checkbox in the settings (checked by default of course) to install the malware. If you have a problem with it you can navigate to the settings and uncheck the install malware box. Now of course you may need to check from time to time if the box has reverted back to its natural checked state because of some backend update.
  - tsimionescu 3y ago
    Still, if the NSA wants to target a "rogue state" with malware through GitHub, they are much much more likely than not to comply. Even if it were ever discovered that they did so, and if it were ever widely publicized, it would not affect the majority of GitHub paying customers (which are US or EU companies, which by and large don't care if their geopolitical rivals are served malware).
- lupusreal 3y ago
  It may seem inconceivable that github would infect downloads with malware, but 20 years ago sourceforge doing it would have seemed inconceivable. They did though. You're saying that it happened before so it won't happen again, but that's silly. Anybody with sense back then would have already known that sourceforge's reputation would be ruined by it, just as everybody knows githubs reputation would be ruined. But you can't count on businesses being run on common sense.
  - perihelions 3y ago
    You misread my comment: I'm saying it absolutely could happen and there's no sound reason to assume it won't.
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

perihelions 3y ago

I think we should have learned this lesson by now. The revelation that GitHub deliberately injects malware into things would be unlikely to "end their business": it would contentiously divide their userbase between purists who believe repo hosts should not be injecting malware into people's FOSS projects, and pragmatists who defend the trust-and-safety reasons for injecting malware into FOSS (say, to assist US intelligence preventing terror attacks). We've had this recurring discussion in many forms, and the typical result is that peoples' capacity for outrage wears out quickly. Who still remembers, for instance, that the GitHub entity sabotaged its users by giving the NSA backdoors to its private infrastructure [0]? How much business is Microsoft missing out on today, in 2024, because of that betrayal of trust? Essentially none, right? They're bigger than ever. GitHub sneaking NSA malware onto their platform—maybe selectively serving it to certain targets—would be perfectly in character with their past behavior. It would be smart business sense (they're a major DoD vendor). It'd be totally irrational to have a faith-based trust that they wouldn't do this. (There's a precedent: the FOSS host SourceForge destroyed itself by making the error of judgement of injecting code into people's repos [1]. But that was a decade ago: the Overton Window's shifted a lot. What SourceForge lost their business for doing in 2013—injecting ads—is something Microsoft comfortably gets away with today, on Windows desktops). [0] https://news.ycombinator.com/item?id=6027779 https://news.ycombinator.com/item?id=6027779 ("How Microsoft handed the NSA access to encrypted messages" (2013)) [1] https://en.wikipedia.org/wiki/SourceForge#Adware_controversy https://en.wikipedia.org/wiki/SourceForge#Adware_controversy

hyperpape 3y ago
Whether or not you draw a distinction, it seems plausible that the world as a whole would draw a distinction between sharing encrypted messages with the NSA and deliberately injecting malware into widely distributed software. Corporations can look at the former and think it is unlikely to affect them. So regardless of how bad its prior behavior is, it makes sense that Microsoft has more of a reason to try to keep software distributed through GitHub as secure as it reasonably can.
- peteradio 3y ago
  How about they just put a checkbox in the settings (checked by default of course) to install the malware. If you have a problem with it you can navigate to the settings and uncheck the install malware box. Now of course you may need to check from time to time if the box has reverted back to its natural checked state because of some backend update.
- tsimionescu 3y ago
  Still, if the NSA wants to target a "rogue state" with malware through GitHub, they are much much more likely than not to comply. Even if it were ever discovered that they did so, and if it were ever widely publicized, it would not affect the majority of GitHub paying customers (which are US or EU companies, which by and large don't care if their geopolitical rivals are served malware).
lupusreal 3y ago
It may seem inconceivable that github would infect downloads with malware, but 20 years ago sourceforge doing it would have seemed inconceivable. They did though. You're saying that it happened before so it won't happen again, but that's silly. Anybody with sense back then would have already known that sourceforge's reputation would be ruined by it, just as everybody knows githubs reputation would be ruined. But you can't count on businesses being run on common sense.
- perihelions 3y ago
  You misread my comment: I'm saying it absolutely could happen and there's no sound reason to assume it won't.

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