Sigstore protects Apt archives: apt-verify and apt-sigstore | Hacker News Reader

Sigstore protects Apt archives: apt-verify and apt-sigstore

blog.josefsson.org

51 pointspabs320 comments

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?

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

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?

> What does this add?

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

Go ahead and prep your downvote, but please stop re-inventing pgp. _loud sigh_.

There’s something to be said to have the same pgp key sign a contributor license agreement, that pgp key signs the commits, that pgp signs the release artifacts, same key with an ssh subkey accesses build servers. Using key base we can see what keys control related Social media and emails.

Honestly the _only_ thing missing of an immutable chain for releases hashes.

Now get off my lawn.

I don’t see how pgp and sigstore are equivalent

They have similarities in that they both can be used to sign things, but the architecture is completely different and sigstore is designed for different tradeoff - namely to be much easier to get started with and use.

sigstore is trying to replace pgp signing adding cloud?

Hash verification is extremely important to protect against supply chain attacks on apt.

Also, apt itself is supposed to be protected by distro’s key, but did any distro ever wrote how master keys are securely stored? Is there any other reasonable way to know that apt and entire Linux supply chain hasn’t been compromised already?

I would very much like to hear an answer to that from somebody who understands the subject deeply. Honestly, these days, I use containers for almost anything unusual and I don't update much either - precisely because anything you install with `apt` would have access to ALL of your system or at least limited access in read-only mode for some files and directories. And I would like to know if anyone can answer the same question for FreeBSD.

docker by default gives root access.

I praise the effort. I don't think it's worth it with Linux. FreeBSD or OpenBSD are the only desktop-usable operating systems that actually make me less worried about my own OS spying on me in one way or another. For one thing, Browsers or their engines even -- they are large software projects created or financed by corporate money -- and they almost never run by users from containers; up until now (I just checked) Google Chrome was not even present on Flathub, so the fact that it is there now is an improvement. But most people don't install Google Chrome from there. Same goes for Firefox, in case you naively believed it isn't as nasty. And, frankly, I don't actually know to which degree Flatpak or Snap isolates them from the system. As a matter of fact, I'm pretty sure, they can still collect all the necessary fingerprinting data even while somewhat isolated.

I know how to run them from a container or even a VM and use X client-server architecture to isolate them - that's how it should be. To set it up, though, requires time and careful considerations and knowledge of many things. I may have most of the knowledge, but not the time. And then again, a malicious vendor has many different ways to fool the system, yet as a user one only has to make a single mistake to allow them to do what they intended to do -- as opposed to preventing it.

So the larger problem isn't signatures. It's the loopholes and vulnerabilities, introduced intentionally or by negligence, that have the potential to compromise an OS. Almost all software should be isolated from the filesystem or any other information that would allow it to uniquely identify your machine (like why the hell does Google Chrome need to know my webcam model and possibly its serial number, which fonts are installed, my GPU and CPU models and a ton of other things?). By the same token, all software shall have no network access UNLESS it's enabled explicitly and one should also be able to block browsers or any other software (including your operating system) from sending telemetry -- by blocking all possible ip-addresses & domain names that aren't associated with the same websites you visit or when some other software truly requires such access. And, frankly, I wish I didn't have to spend hours and days setting up firewalls and closing up all those holes. It isn't because I have things to hide. It's because it's simply wrong. If you need a shallow reason why, I'll give you one: I pay for electricity and for my internet access. No software vendor, open-source or not, for good reasons or not so good reasons, shall have the right to send a network request and, thus, send or receive data from the network without my explicit permission. That has to be the default.

Update: and if they're allowed to send telemetry (again, by users themselves and explicitly) users should have the key to inspect the encrypted data that's being sent before it is sent. My machine, my rules. The irony is that the non-free, proprietary operating systems abuse privacy rights even more than the open-source ones, while I'd actually pay for the opposite happily if someone would design a system that is provably non-malicious, has the properties described above and doesn't require a lot of time and effort to achieve the desired things related to privacy and security.

Reply on news.ycombinator.com