4 ms·

I wouldn't put it past the US to coerce Microsoft into injecting malicious payloads into these types of projects. EFF is putting complete trust in Microsoft's i

I wouldn't put it past the US to coerce Microsoft into injecting malicious payloads into these types of projects. EFF is putting complete trust in Microsoft's infrastructure: there's no out-of-band verification not served up by Microsoft itself (is there? It's just GitHub.com's TLS, and in-band SHA-1 hashes stored in the repo itself, which Microsoft controls; it can serve whatever bytes it wants, or different bytes on different requests...) Microsoft has billions of dollars in US intelligence-cloud contracts and should leap at a chance to get an edge in on those. They've done things like this before; they provided incredible (and illegal!) cooperation with the NSA back at the time of the Snowden Leaks[0]. [0] https://www.theguardian.com/world/2013/jul/11/microsoft-nsa-collaboration-user-data https://www.theguardian.com/world/2013/jul/11/microsoft-nsa-... ("Microsoft handed the NSA access to encrypted messages" (2013))

throw0101d 1y ago
> I wouldn't put it past the US to coerce Microsoft into injecting malicious payloads into these types of projects. EFF is putting complete trust in Microsoft's infrastructure: there's no out-of-band verification not served up by Microsoft itself Isn't a git commit trail basically a Merkle tree of checksums? If any developer tried to do a pull or fetch they'd suddenly get a bunch of strange commit messages, wouldn't they? Also: code signing is / can become a thing.
- RS-232 1y ago
  Technically a Merkle DAG
  - goku12 1y ago
    Both are correct. The commit history is a Merkle DAG. The tree under each commit is a Merkle tree.
- some_furry 1y ago
  > Also: code signing is / can become a thing. To that end, I started a project last month so that code signing can be done in multiple geographical locations at once: https://github.com/soatok/freeon https://github.com/soatok/freeon
- therein 1y ago
  GP was probably referring to the binary releases on the GitHub repo.
- perihelions 1y ago
  I don't know why you'd trust a checksum structure your adversary has complete control over. That Merkle tree prevents the naive case where the adversary tries to serve a version of a repo, to a client who already has an older version, differing in a part the client already has. (The part the client has local checksums for). They shouldn't do that. The git client tells the server what commits it doesn't have, so this is simple to check. Code signing could be a safeguard if people did it, but here they don't so it's moot. I found no mention of a signing key in this repo's docs. The checksum tree could be a useful audit if there were a transparency log somewhere that git tools automatically checked against, but there isn't so it's moot. We put full trust in Microsoft's versions. Lots of things could be helpful, but here and now in front of us is a source tree fully in Microsoft's control, with no visible safeguards against Microsoft doing something evil to it. Just like countless others. It's the default state of trust today.
  - marginalia_nu 1y ago
    Because the developers have just that on their local machine...? Git is a distributed vcs after all. Every checkout is its own complete git "hub".
    - perihelions 1y ago
      Because GitHub can serve different bytes to different people. You log in as one of the project's devs, you get your own consistent, correct view of your project; some other people get malware instead. How do you reconcile the full picture? No one distrusts GitHub. There's no public log which git tools generically check against to see if GitHub is attempting something evil, the way they do with certificate transparency. GitHub is the public log. Git may be designed as a distributed VCS; and it'd be a different situation if it were used that way in practice. For many projects, GitHub has a full MITM. They could even—forget about the checksums—bifurcate the views in between devs—accept commits from one dev, send over those commits with translated Merkle trees to another dev who has a corrupted history, and they'd never figure it out.
      - saagarjha 1y ago
- untitaker_ 1y ago
  I think GP is talking about a scenario where Microsoft would serve either malicious source tree or binaries to just one user, not all of them. that would be fairly hard to detect. but in such scenarios we'd also have to start asking questions about the state of the entire CA ecosystem.
  - tstenner 1y ago
    Or detected easily with package builders like Arg Linux's makepkg that ship a hash along with the source URL. As soon as one user gets a different file, he has an alert and the compromised package for later analysis
    - untitaker_ 1y ago
      like I said, if you assume your adversary is the US government then they might as well start issuing rogue TLS certs to target individuals.
- stephen_g 1y ago
  It'd be a lot of trouble to interfere with the source, yes. I think the release files is the place they could most easily tamper - generally they're stored on Github infra so the files could be changed, and the checksum on the download page also altered (or different files and different checksums provided to different people if targeted). Unless the builds are totally reproducible it'd be tricky to catch.
  - philihp 1y ago
    Possible, yes, but pretty damming to Microsoft's reputation if proof that their infrastructure has been compromised and anyone realizes it's happening. This sort of thing killed Sourceforge when they started shipping adware bundled into installers of the programs they distributed.
    - type0 1y ago
      You can't compare it sourceforge, MS is too big to fail
aduffy 1y ago
You’re welcome to read the code yourself once you check it out, it’s not very big. Supply chain attacks are a thing but I don’t think this is one.
untitaker_ 1y ago
I don't think there are many options to host sourcecode and binaries in a way that is safe against an adversary like the US, and especially in such a way that technically illiterate users are protected. Because you'd have to assume that CAs are not off-limits either then.
deleted 1y ago
[deleted]

throw0101d 1y ago

> I wouldn't put it past the US to coerce Microsoft into injecting malicious payloads into these types of projects. EFF is putting complete trust in Microsoft's infrastructure: there's no out-of-band verification not served up by Microsoft itself Isn't a git commit trail basically a Merkle tree of checksums? If any developer tried to do a pull or fetch they'd suddenly get a bunch of strange commit messages, wouldn't they? Also: code signing is / can become a thing.

RS-232 1y ago
Technically a Merkle DAG
- goku12 1y ago
  Both are correct. The commit history is a Merkle DAG. The tree under each commit is a Merkle tree.
some_furry 1y ago
> Also: code signing is / can become a thing. To that end, I started a project last month so that code signing can be done in multiple geographical locations at once: https://github.com/soatok/freeon https://github.com/soatok/freeon
therein 1y ago
GP was probably referring to the binary releases on the GitHub repo.
perihelions 1y ago
I don't know why you'd trust a checksum structure your adversary has complete control over. That Merkle tree prevents the naive case where the adversary tries to serve a version of a repo, to a client who already has an older version, differing in a part the client already has. (The part the client has local checksums for). They shouldn't do that. The git client tells the server what commits it doesn't have, so this is simple to check. Code signing could be a safeguard if people did it, but here they don't so it's moot. I found no mention of a signing key in this repo's docs. The checksum tree could be a useful audit if there were a transparency log somewhere that git tools automatically checked against, but there isn't so it's moot. We put full trust in Microsoft's versions. Lots of things could be helpful, but here and now in front of us is a source tree fully in Microsoft's control, with no visible safeguards against Microsoft doing something evil to it. Just like countless others. It's the default state of trust today.
- marginalia_nu 1y ago
  Because the developers have just that on their local machine...? Git is a distributed vcs after all. Every checkout is its own complete git "hub".
  - perihelions 1y ago
    Because GitHub can serve different bytes to different people. You log in as one of the project's devs, you get your own consistent, correct view of your project; some other people get malware instead. How do you reconcile the full picture? No one distrusts GitHub. There's no public log which git tools generically check against to see if GitHub is attempting something evil, the way they do with certificate transparency. GitHub is the public log. Git may be designed as a distributed VCS; and it'd be a different situation if it were used that way in practice. For many projects, GitHub has a full MITM. They could even—forget about the checksums—bifurcate the views in between devs—accept commits from one dev, send over those commits with translated Merkle trees to another dev who has a corrupted history, and they'd never figure it out.
    - saagarjha 1y ago
untitaker_ 1y ago
I think GP is talking about a scenario where Microsoft would serve either malicious source tree or binaries to just one user, not all of them. that would be fairly hard to detect. but in such scenarios we'd also have to start asking questions about the state of the entire CA ecosystem.
- tstenner 1y ago
  Or detected easily with package builders like Arg Linux's makepkg that ship a hash along with the source URL. As soon as one user gets a different file, he has an alert and the compromised package for later analysis
  - untitaker_ 1y ago
    like I said, if you assume your adversary is the US government then they might as well start issuing rogue TLS certs to target individuals.
stephen_g 1y ago
It'd be a lot of trouble to interfere with the source, yes. I think the release files is the place they could most easily tamper - generally they're stored on Github infra so the files could be changed, and the checksum on the download page also altered (or different files and different checksums provided to different people if targeted). Unless the builds are totally reproducible it'd be tricky to catch.
- philihp 1y ago
  Possible, yes, but pretty damming to Microsoft's reputation if proof that their infrastructure has been compromised and anyone realizes it's happening. This sort of thing killed Sourceforge when they started shipping adware bundled into installers of the programs they distributed.
  - type0 1y ago
    You can't compare it sourceforge, MS is too big to fail

aduffy 1y ago

You’re welcome to read the code yourself once you check it out, it’s not very big. Supply chain attacks are a thing but I don’t think this is one.

untitaker_ 1y ago

I don't think there are many options to host sourcecode and binaries in a way that is safe against an adversary like the US, and especially in such a way that technically illiterate users are protected. Because you'd have to assume that CAs are not off-limits either then.

deleted 1y ago

[deleted]