Open quantumpacket opened 5 months ago
qubes-secpack is not a replacement for keyservers (however broken they are). It's a place for keys that should be trusted to sign various official releases. Various repositories do contain commits (or tags) signed by other people (because we do accept contributions!), but that doesn't mean you should trust any of them. qubes-builder takes care of verifying if there is a tag signed with a trusted key. Especially, it is not the goal to have key for every contributor in the qubes-secpack repo. To put it differently, qubes-secpack should include keys of all maintainers, not necessarily all developers. In practice, I think the only missing keys are of @fepitre (maintainer of contrib-related repositories), @adrelanos (maintainer of template-whonix repository)
Sorry if I'm misunderstanding the process here...
qubes-builder takes care of verifying if there is a tag signed with a trusted key
I see here that it is checking the maintainer's keys in the committed keyring.
However, for tags signed by developers, where in the verification chain is QubeOS vouching that these signed tags and the code being committed has been reviewed by QubesOS? Shouldn't the tag be signed by a trusted source (QubesOS) as final approval that the code is legit?
Especially, it is not the goal to have key for every contributor in the qubes-secpack repo.
Why are contributors signing tags, opposed to just signing commits? I would expect the tag signing to be done by one of the trusted keys.
In your Matrix response you said:
commits are signed by their authors, which may or may not be part of the core team; what you should use for sources verification is signed tag, which should be signed by one of the core team member, with a key included in the secpack
So only trust tags signed by a core team member? Any tags after or prior of such a trusted tag should be considered untrusted? If so, we will advise the auditors to only get the latest trusted tag to audit.
Have I understood correctly that qubes-builder does check for trusted keys, but that the secpack is also missing a couple of active maintainer keys? Does this block them from releasing in practice? If the process as documented isn't what is actually in use, that would already be a useful audit finding.
I understand from this that there's no concern over the existence of unverifiable signed tags, just that they shouldn't be trusted.
Why are contributors signing tags, opposed to just signing commits? I would expect the tag signing to be done by one of the trusted keys.
See https://www.qubes-os.org/doc/code-signing/
However, for tags signed by developers, where in the verification chain is QubeOS vouching that these signed tags and the code being committed has been reviewed by QubesOS? Shouldn't the tag be signed by a trusted source (QubesOS) as final approval that the code is legit?
The benefit of tags is that a single commit can have multiple of them. This allows multi-stage process - for example one developer writes something and signs it, another reviews it and adds its own tag and finally maintainer reviews too (or trust the review of the other developer and just verifies its tag) and adds its own tag. All tags are left in place to keep evidence, but for the actual release only the maintainer tag counts.
Have I understood correctly that qubes-builder does check for trusted keys, but that the secpack is also missing a couple of active maintainer keys? Does this block them from releasing in practice? If the process as documented isn't what is actually in use, that would already be a useful audit finding.
You can see which key is used where here (for R4.2). qubes-builder repo has its own copy of the keys for easier bootstrapping
but for the actual release only the maintainer tag counts
That makes a lot more sense. Thanks for clearing that up.
Query on If you come across a repo with any unsigned commits, you should not add any of your own signed tags or commits on top of them unless you personally vouch for the trustworthiness of the unsigned commits.
(source): do maintainers ever trust that a developer has done this? If not, is this guidance needed? If so, should it also be added to https://www.qubes-os.org/doc/code-signing/ ? Without knowing how maintainers treat this (is this also documented somewhere?), I see potential for commits to go unreviewed here.
Any pull request is reviewed based on previous trusted version (regardless of what github ui shows), so if somebody include some extra commits found somewhere, they will get reviewed in the process too (and if they weren't included intentionally, that will get noticed there). But also, the convenient way of getting sources is to use qubes-builder, that does verify relevant tags
The problem you're addressing (if any)
This was suggested in the Matrix room by @marmarek
@drivingreturns and I are putting together the Code Audit Program as discussed on the forum. As a first step, we want to be able to fully verify the authenticity of the source code.
According to the docs, we should be able to verify any signed tag. So we are retroactively verifying every tag to best ensure the integrity of the repositories. However, there are many public keys missing from the Qubes Security Pack, which hinders us from doing a full verification.
All these missing keys have been used to sign tags:
The solution you'd like
All keys that have been used to sign a tag in any of the QubesOS repositories should have their public key added to the Qubes Security Pack. Not all of them are/were core developers as far as I am aware, so those keys should probably go in a separate directory. Some keys are still active, others are expired/retired.
I would also like to suggest this be policy going forward. Such that a tag should not be signed with a key unless that key is in the Qubes Security Pack. Otherwise, it puts the signed tag in a less than ideal state for verification. One must now find the correct key, verify it, etc. How do we know the QubesOS team trusts this key for tagging?
The value to a user, and who that user might be
The user has the convenience to trust all the verified keys in the Qubes Security Pack, opposed to trying to painstakingly locate them one by one, verifying the fingerprints, etc. This allows the user the ability to verify any tag in any of the repositories. This is vital for a source code audit as it will prevent auditors from potentially being served an alternate version of the code signed by an unknown key, as a common threat model among QubesOS users includes Microsoft and state actors.