On Thu, Sep 25, 2025 at 2:11 PM Spyros Seimenis <[email protected]> wrote: >> >> with >> Qubes OS this is extremely easy because of the hardware isolation >> model used in Qubes. You can have a VM with no network access, into >> which you copy files that you need to sign, then copy them back out >> once they have been signed (or you can use qubes-split-gpg, which >> allows you to essentially use an airgapped vault VM as a virtual >> Yubikey of sorts). > > > Thanks for the detailed answer! This sounds indeed very interesting (and I > agree with your points about the security of open source fw code). My point > about building trust in a way that scales is the same even with this > approach. You have to factor in that it is much more difficult to collect the > necessary information, from a more complex system, required to prove that a > particular key was actually created and used with a setup like this **and** > cryptographically verify them compared to a hw token/HSM approach. > > To give an example, once I have a signature produced by a key generated in a > yubikey, an automated service in launchpad could run one command to attest > that the key used was indeed generated in a yubikey [1]. We then implicitly > put our trust to the yubikey's manufacturer and for many this is enough. With > HSMs it is similar, you are essentially paying the HSM manufacturer for > trusting them. > > We should have clear guidelines about what are the requirements for an > alternative method to be considered as trusted as the ones I mentioned above > (what are the necessary attestations, how feasible it is to automate > verification as a whole/in parts etc). For the Qubes example, I want to see > cryptographic proof that the signing happened inside the "air-gapped" qube, > proof that the key was indeed generated inside of it and cannot leave it, > proof that you have set up your system properly and that your system comes > from a manufacturer I consider trusted so that I can trust its hardware > isolation mechanisms etc. (turtles all the way down) and I also want a system > to do that verification for me as much as possible.
I think you're approaching this from the standpoint of Ubuntu being a corporate project with security requirements from employees. That would be great if that is what Ubuntu was, but that is not what Ubuntu is. Ubuntu is a community project with a largely volunteer-based workforce. As such, we have traditionally always taken steps to ensure that the volunteers who work as part of Ubuntu are highly trusted - we work with them on a personal level for months before trusting them with archive upload privileges, ensuring that they are non-malicious, constructive members of the community who know what they're doing and will work closely with the rest of Ubuntu to do their job correctly. If someone is trustworthy enough to do everything else with their development work correctly, I see no reason they shouldn't be trusted to do their key management correctly, provided they have been trained on how to manage their keys just like they were trained on how to manage packages. Ensuring that the key comes from a source that is somehow considered objectively trustworthy is essentially enforcing an enterprise policy across a non-enterprise community. It's also very insufficient as far as real-world security goes; a person could just use a mini Yubikey that's left inserted into their machine at all times, meaning anyone who runs off with the machine (or even gets near it for a few seconds) can simply take the key (and maybe the machine too) and now have upload privileges to the archive. Or the developer could install persistent malware that implants itself into packages in some form prior to signing, and so on. No amount of enterprise policy or attestation will change the fact that if the person using the key doesn't know what they're doing, bad things can easily happen. A sufficiently trained user doesn't need the enterprise policy to keep bad things from happening, and they might be actively made less secure or otherwise unable to do their job because of the policy. A huge portion of our developer community with archive upload rights is not employed by Canonical. The entirety of that community is highly trusted. To cut off that trust when it comes to signing keys is strange and sets a very bad precedent for how things are done with Ubuntu as a community. -- Aaron > [1]: https://developers.yubico.com/PKI/yubico-ca-certs.txt -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
