> What does this add?

Sigstore in general? A fancy, colorful website that GPG does not have.

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?

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.

> How do I know that the code the developer wrote is what I am running?

Because of reproducible builds?

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.

If you're getting closed source, certainly debian has nothing to do with it and you have to take issue with your distributor?

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.

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

Re-read my initial reply to the thread. It is stated.

gpg can be used to sign a single file, if for any reason you download a single .deb instead of using a repository.

If your supplier doesn't sign them… take it with them?

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.)