4 ms·

"If you download a binary package that still leaves you trusting the packager who built and signed it" I'm agreeing with that. I'm also saying you're already d

"If you download a binary package that still leaves you trusting the packager who built and signed it" I'm agreeing with that. I'm also saying you're already doing it for a whole distro. Why not the compiler they can ship with it on top of that? If you don't trust repo, then you need to be doing more than reproducibly building a compiler's source.

lmm 10y ago
I fully intend to do more, in the long term. But reducing the scope of what I trust is a good start. 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.
- nickpsecurity 10y ago
  "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

I fully intend to do more, in the long term. But reducing the scope of what I trust is a good start. 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.

nickpsecurity 10y ago
"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.