3 ms·

I don't get it. What does this add? Debian packages are already gpg signed. Majority (and Debian is working toward the goal of all) packages have reproducibl

I don't get it. What does this add? Debian packages are already gpg signed. Majority (and Debian is working toward the goal of all) packages have reproducible builds. Their CI system even automatically does multiple consecutive builds of packages to automatically detect issues with reproducibility. So, in the majority of cases, you can verify that the binary package you installed matches the source package it is claimed to be built from. You have to go to extra effort to install an unsigned package / package that fails signature verification with what currently exists. So, you are not going to accidentally install a package that fails signature verification with just the current protections in place. So, am I missing something? Or, does this new thing add nothing to the protections that are already present by default?

goodpoint 3y ago
> What does this add? Sigstore in general? A fancy, colorful website that GPG does not have.
a_vanderbilt 3y ago
It's an unpopular take, but I think Debian is less than ideal with how they secure packages. Per-package signing is not the expectation in Debian-land, and the two main ways of signing packages aren't supported by the main repos. They strip the code-signatures even if you submit a package with them. The usual response I receive is "the package hashes list is signed so it gets security by proxy". What about software obtained off-repo? How do I know that the code the developer wrote is what I am running? Package signatures give us that ability. RPM has adopted per-package signing as the default years ago, why doesn't Debian?
- sillystuff 3y ago
  Individual package signing does seem more straightforward. But, signing a file containing a list of hashes of the individual package files, as Debian does, accomplishes the same verification of package integrity when installing from a repo. I'm guessing the genesis was since Debian already checked package hashes to ensure no download issues, adding a cryptographic signature to the file containing those hashes was an easy, minimal change that would not break existing clients that didn't know to check it. Off repo is a use case that IMO should be strongly discouraged (as should adding random repos), but to your point, if you have no choice, a per-package sig would be useful.
- bombolo 3y ago
  > How do I know that the code the developer wrote is what I am running? Because of reproducible builds?
  - a_vanderbilt 3y ago
    How would you reproduce the build on systems that are not capable of performing the build due to hardware or practical constraints? If I am obtaining closed-source packages, how do I reproduce those builds? The benefit of signing is adjacent, but not the same as the need to confirm the output of the build process.
    - bombolo 3y ago
      If you're getting closed source, certainly debian has nothing to do with it and you have to take issue with your distributor?
      - a_vanderbilt 3y ago
        Debian defines the package format and fosters the culture around that format. Third-parties who wish to distribute software via Debian packages have to use the standard that Debian has decided upon. I am taking up the issue with Debian, as the distributor of the Debian package format.
        bombolo 3y ago
        Ok. But what kind of magic signature do you want to know that the code you're running matches the source, if the software is closed source and you have no access to the source? Your requirement makes no sense. Are you a product manager? :D
        a_vanderbilt 3y ago
        Re-read my initial reply to the thread. It is stated.
yencabulator 3y ago
Since they're linking to rekor and talking about Certificate Transparency, it's likely the general goal is what CT wants: That the server cannot provide malicious response X to just the victim, while looking innocent to others. Certificate Transparency forces the signer to publish the fact that they sign something, leading to such attacks being noticeable, in the sense that "there was an extra thing signed and it's not the usual thing". With TLS, the idea is that big corporations can tail the CT log and make sure there have been no extra certificates created for their domains. (I can't vouch for whether this work achieves that goal. Something needs to check the inclusion proof in the client, before trusting the data. Auditors need to tail the CT log.)

goodpoint 3y ago

> What does this add? Sigstore in general? A fancy, colorful website that GPG does not have.

a_vanderbilt 3y ago

It's an unpopular take, but I think Debian is less than ideal with how they secure packages. Per-package signing is not the expectation in Debian-land, and the two main ways of signing packages aren't supported by the main repos. They strip the code-signatures even if you submit a package with them. The usual response I receive is "the package hashes list is signed so it gets security by proxy". What about software obtained off-repo? How do I know that the code the developer wrote is what I am running? Package signatures give us that ability. RPM has adopted per-package signing as the default years ago, why doesn't Debian?

sillystuff 3y ago
Individual package signing does seem more straightforward. But, signing a file containing a list of hashes of the individual package files, as Debian does, accomplishes the same verification of package integrity when installing from a repo. I'm guessing the genesis was since Debian already checked package hashes to ensure no download issues, adding a cryptographic signature to the file containing those hashes was an easy, minimal change that would not break existing clients that didn't know to check it. Off repo is a use case that IMO should be strongly discouraged (as should adding random repos), but to your point, if you have no choice, a per-package sig would be useful.
bombolo 3y ago
> How do I know that the code the developer wrote is what I am running? Because of reproducible builds?
- a_vanderbilt 3y ago
  How would you reproduce the build on systems that are not capable of performing the build due to hardware or practical constraints? If I am obtaining closed-source packages, how do I reproduce those builds? The benefit of signing is adjacent, but not the same as the need to confirm the output of the build process.
  - bombolo 3y ago
    If you're getting closed source, certainly debian has nothing to do with it and you have to take issue with your distributor?
    - a_vanderbilt 3y ago
      Debian defines the package format and fosters the culture around that format. Third-parties who wish to distribute software via Debian packages have to use the standard that Debian has decided upon. I am taking up the issue with Debian, as the distributor of the Debian package format.
      - bombolo 3y ago
        Ok. But what kind of magic signature do you want to know that the code you're running matches the source, if the software is closed source and you have no access to the source? Your requirement makes no sense. Are you a product manager? :D
        a_vanderbilt 3y ago
        Re-read my initial reply to the thread. It is stated.

yencabulator 3y ago

Since they're linking to rekor and talking about Certificate Transparency, it's likely the general goal is what CT wants: That the server cannot provide malicious response X to just the victim, while looking innocent to others. Certificate Transparency forces the signer to publish the fact that they sign something, leading to such attacks being noticeable, in the sense that "there was an extra thing signed and it's not the usual thing". With TLS, the idea is that big corporations can tail the CT log and make sure there have been no extra certificates created for their domains. (I can't vouch for whether this work achieves that goal. Something needs to check the inclusion proof in the client, before trusting the data. Auditors need to tail the CT log.)