5 ms·

I think this can be made much more difficult by enforcing a policy of open builds for open source. It shouldn't be possible to inject build files from a local m

I think this can be made much more difficult by enforcing a policy of open builds for open source. It shouldn't be possible to inject build files from a local machine. All build assets should come from the source repository. Artifacts should come from Github Actions or some other tool that has a clear specification of where all inputs came from. Perhaps Github could play a role in helping to automate any inconveniences here.

maclockard 3y ago
I think that trust needs to be 'pushed deeper' than that so to speak. While this would be an improvement, what happens if there is a malicious actor at Github? This may be unlikely, but would be even harder to detect since so much of the pipeline would be proprietary. Ideally, we would have a mechanism to verify that a given build _matches_ the source for a release. Then it wouldn't matter where it was built, we would be able to independently verify nothing funky happened.
- gregwebs 3y ago
  Vendor independent build providence is certainly the long-term goal. In the immediate-term moving away from mystery tarballs towards version control gets us a step closer. One of the best things about Golang is that packages are shared direct via source repositories (Github) rather than a package repository containing mystery tarballs. I understand the appeal of package repositories, but without proper security constraints it's a security disaster waiting to happen.
dboreham 3y ago
Yes the whole "let's take a mystery meat tarball from a repo that isn't the project repo" seems suspect. Github+ even has a scheme for signing artifacts such that you have some level of trust they came from inside their Actions system, derived from some git commit. This would allow the benefits of a modular build for a large product like a distro, while preserving a chain of trust in its component parts. +Not advocating a dependency on Github per se -- the same sort of artifact attestation scheme could be implemented elsewhere.
- shp0ngle 3y ago
  as I wrote in a different thread, some projects don't have any source control. From the big ones - 7z, ncurses are both tarballs only.
  - patmorgan23 3y ago
    They need to join us in the 80s and start using source control.
- account42 3y ago
  Yeah lets make the entire open source ecosystem reliant on Microsoft. No thanks.
qerti 3y ago
Wasn’t the payload in a blob in the tests, which is in the source repo? If you were to clone the repo then build from source, you’d have the backdoor, right? Surely distros aren’t using binaries sent by maintainers
- jsnell 3y ago
  No. The payload was in the checked in test files, but the test files were inert. They were only activated by the tarball having different build files than the repository (or rather, different build files than would be generated by autotools for the repository), which extracted the payload from the test files and injected it into the output binary.

maclockard 3y ago

I think that trust needs to be 'pushed deeper' than that so to speak. While this would be an improvement, what happens if there is a malicious actor at Github? This may be unlikely, but would be even harder to detect since so much of the pipeline would be proprietary. Ideally, we would have a mechanism to verify that a given build _matches_ the source for a release. Then it wouldn't matter where it was built, we would be able to independently verify nothing funky happened.

gregwebs 3y ago
Vendor independent build providence is certainly the long-term goal. In the immediate-term moving away from mystery tarballs towards version control gets us a step closer. One of the best things about Golang is that packages are shared direct via source repositories (Github) rather than a package repository containing mystery tarballs. I understand the appeal of package repositories, but without proper security constraints it's a security disaster waiting to happen.

dboreham 3y ago

Yes the whole "let's take a mystery meat tarball from a repo that isn't the project repo" seems suspect. Github+ even has a scheme for signing artifacts such that you have some level of trust they came from inside their Actions system, derived from some git commit. This would allow the benefits of a modular build for a large product like a distro, while preserving a chain of trust in its component parts. +Not advocating a dependency on Github per se -- the same sort of artifact attestation scheme could be implemented elsewhere.

shp0ngle 3y ago
as I wrote in a different thread, some projects don't have any source control. From the big ones - 7z, ncurses are both tarballs only.
- patmorgan23 3y ago
  They need to join us in the 80s and start using source control.
account42 3y ago
Yeah lets make the entire open source ecosystem reliant on Microsoft. No thanks.

qerti 3y ago

Wasn’t the payload in a blob in the tests, which is in the source repo? If you were to clone the repo then build from source, you’d have the backdoor, right? Surely distros aren’t using binaries sent by maintainers

jsnell 3y ago
No. The payload was in the checked in test files, but the test files were inert. They were only activated by the tarball having different build files than the repository (or rather, different build files than would be generated by autotools for the repository), which extracted the payload from the test files and injected it into the output binary.