4 ms·

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

51 points by pabs3 4y ago

DethNinja 4y ago
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?
- madwebness 4y ago
  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.
  - bombolo 4y ago
    docker by default gives root access.
exabrial 4y ago
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.
- klysm 4y ago
  I don’t see how pgp and sigstore are equivalent
  - dlor 4y ago
    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.
  - bombolo 4y ago
    sigstore is trying to replace pgp signing adding cloud?
sillystuff 4y ago
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 4y ago
  > What does this add? Sigstore in general? A fancy, colorful website that GPG does not have.
- a_vanderbilt 4y 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 4y 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.
madwebness 4y ago
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.

51 points by pabs3 4y ago

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?

madwebness 4y ago
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.
- bombolo 4y ago
  docker by default gives root access.

exabrial 4y ago

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.

klysm 4y ago
I don’t see how pgp and sigstore are equivalent
- dlor 4y ago
  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.
- bombolo 4y ago
  sigstore is trying to replace pgp signing adding cloud?

sillystuff 4y ago

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 4y ago
> What does this add? Sigstore in general? A fancy, colorful website that GPG does not have.
a_vanderbilt 4y 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 4y 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.

madwebness 4y ago

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.