2 ms·

"If I can go from trusting every binary packager working for the distro to trusting only the binary packagers of packages in build-essential, that's a huge win.

"If I can go from trusting every binary packager working for the distro to trusting only the binary packagers of packages in build-essential, that's a huge win." This is true unless the repo you're using can be accessed by malicious parties or contain code from them. As in, if you're avoiding packages from person A but not B and both have write access to the repo, its server, or its network then your security is unchanged. If different source/binaries are completely isolated by different people, then your choice might reduce your risk in event one becomes malicious.

lmm 10y ago
> This is true unless the repo you're using can be accessed by malicious parties or contain code from them. As in, if you're avoiding packages from person A but not B and both have write access to the repo, its server, or its network then your security is unchanged. If different source/binaries are completely isolated by different people, then your choice might reduce your risk in event one becomes malicious. A and B sign the packages they build with their own PGP keys, no? (Cool thought: with reproducible builds, multiple independent packagers could perform the build locally and upload the package signature - only the first packager would have to upload the actual package, but we could check the others' signatures to increase our confidence that no funny business was going on)
- nickpsecurity 10y ago
  That's a good idea. It's even in my distributed, subversion-resistant, SCM scheme from years ago. ;) As I told Wheeler, you can get extra benefits with reproducible builds on top of what I recommend. I just encourage people solve the root problems first. He did too with his SCM security page but did this stuff for event high-assurnce security (esp SCM). That sadly was what happened.
  - lmm 10y ago
    I don't know about "solving the root problems". There are a lot of things that need to be done to get us to secure software, and in many cases there are multiple "blockers". I consider a security effort valuable when it both a) provides some improvement today, even if a fairly trivial one and b) will be useful in the end state we're aiming for , and I think reproducible builds qualify.

lmm 10y ago

> This is true unless the repo you're using can be accessed by malicious parties or contain code from them. As in, if you're avoiding packages from person A but not B and both have write access to the repo, its server, or its network then your security is unchanged. If different source/binaries are completely isolated by different people, then your choice might reduce your risk in event one becomes malicious. A and B sign the packages they build with their own PGP keys, no? (Cool thought: with reproducible builds, multiple independent packagers could perform the build locally and upload the package signature - only the first packager would have to upload the actual package, but we could check the others' signatures to increase our confidence that no funny business was going on)

nickpsecurity 10y ago
That's a good idea. It's even in my distributed, subversion-resistant, SCM scheme from years ago. ;) As I told Wheeler, you can get extra benefits with reproducible builds on top of what I recommend. I just encourage people solve the root problems first. He did too with his SCM security page but did this stuff for event high-assurnce security (esp SCM). That sadly was what happened.
- lmm 10y ago
  I don't know about "solving the root problems". There are a lot of things that need to be done to get us to secure software, and in many cases there are multiple "blockers". I consider a security effort valuable when it both a) provides some improvement today, even if a fairly trivial one and b) will be useful in the end state we're aiming for , and I think reproducible builds qualify.