gpg: key 50C78B6F9FF2EC85: 1 signature not checked due to a missing key
Users asked about this multiple times in forums (where we misinterpreted and didn’t know what they’re talking about) and on telegram / matrix chat. Not sure my changes made it better or worse. Changed version would avoid that issue but Whonix ™ Signing Key itself has the same issue.
gpg: key 8D66066A2EEACCDA: 104 signatures not checked due to missing keys
How we could resolve this? Should Whonix ™ Signing Key become a draft for a new template? We could have separate Whonix_Signing_Key wiki pages for Whonix VirtualBox and Whonix KVM?
Then for any signature not checked due to a missing key messages we could say "advanced users check Whonix_Signing_Key/VirtualBox or Whonix_Signing_Key/KVM.
I think it predates the templates. This page has the relevant steps because it refers to my key while the KVM templates are incorrect because they refer to releases signed with yours
Is there a way to suppress these confusing messages?
A template that includes steps for all versions of Whonix and the relevant subsection is linked to from each ports respective wiki page
I think it predates the templates. This page has the relevant steps because it refers to my key while the KVM templates are incorrect because they refer to releases signed with yours
Could you please update the KVM page(s) which call the wiki templates?
That should all be editable through wiki template variables. That was
why the whole exercise was done. It’s a good exercise for future use of
signify (available for VirtualBox releases already) and codecrypt
signatures.
Is there a way to suppress these confusing messages?
I haven’t found any.
A template that includes steps for all versions of Whonix and the relevant subsection is linked to from each ports respective wiki page
I am not sure I understand. What would happen with Whonix_Signing_Key
page? What subection? If we had subsections VirtualBox vs KVM then we
wouldn’t use a wiki template?
On a second thought, turning Whonix ™ Signing Key into a template could be
difficult. Instructions for OpenPGP Web of Trust will be different.
[1] Establishing my signing key through OpenPGP Web of Trust
realistically requires establishing a trust path through Debian keyring.
[2] Establishing your signing key through OpenPGP Web of Trust would
require doing [1] first (verify trust path to my key) and then use my
key to establish trust path to your key.
But somehow template(s) either way. There’s lots of text passages which
are best when shared to keep up with gpg (that “signature not checked
due to a missing key” message seems new).
Speaking of PQ some final group candidates have software implementations available on their project sites that can sign and verify the safer stateless signatures not available in codecrypt at the moment, I will open a separate thread for this if you are interested in compiling/packaging them and I will figure out how to use them
Interesting.
No, I don’t think I’ll compile/package codecrypt.
APT uses gpg internally. Therefore we’re bound to a lower security level anyhow, i.e. non-PQCrypto level. If we have gpg / signify signed releases we’re on par, i.e non-PQCrypto level. PQCrypto level signed releases is a nice bonus but wouldn’t really increase security a lot.
Now I also wonder if it’s up to us to explain how to use the OpenPGP web of trust? It is possible to verify either key through the OpenPGP web of trust. We can certainly add a hint how to do that. But do we ought to document in detail (each command and output) how to use the OpenPGP web of trust?
Disadvantage of having OpenPGP web of trust documentation:
It makes Whonix look needlessly complicated. Most users were never aware of any software verification possibilities and never did it before. Then users don’t benefit from it anyhow. Users easily conclude it’s too difficult to use, not safe without software verification and then just download and install hidemyass or something without software verification.
Effort to create and maintain this documentation.
By extension this arguments could be made for all software signature verification instructions. We offer signing key, and signatures. But why Whonix must have signature verification instructions? Are we trying to fix upstream issues, that is bad usability / bad documentation? Or is it activism spreading gpg and software signature verification concepts?
From a security (non-activism) only perspective, as per Conceptual Challenges in Digital Signatures Verification: software signature verification is something users need to ask for. It’s not something vendors can offer to users.
IMO The detailed page should be moved elsewhere as a reference to interested users who might want to learn about the WoT (for some reason). The templates should instead show the simplest instructions possible and limit explanations of errors to “this can be safely ignored” and moves on to getting the user up and running.
Not great. If it’s pasted, then it’s still duplicated, standlone, going to divert over time, not using any wiki template. And we’d have major differences on VirtualBox vs KVM verification instructions.
There are these two KVM wiki pages, based on using wiki templates:
Verify Virtual Machine Images on Linux - that template could be deprecate/unsupported if too much effort to update, separate screenshots for KVM, keep maintained or otherwise not worthwhile.
Perhaps my software verification wiki template approach is too complicated?
A) My approach was (current at time of writing): shared software verification wiki templates with the bits which must be different being entered at a wiki page which imports the template using wiki template variables.
B) Another approach would be: no whole shared wiki template but instead move text blocks which make sense to be shared into wiki templates. Then any wiki page which needs any text block can simply re-use shared text blocks from wiki templates. There wouldn’t be any template variables. The variable (differnet VirtualBox vs KVM) parts would be directly on the wiki pages.
C) Yet another apporach would be to have fully independent wiki pages. No templates. All text blocks would be duplicated and therefore diverts more and more over time.
It’s not just 1 link. It’s ~ 5 steps with different inputs commands and output messages.
Depending how it’s implemented, that would be confusing.
There could be one chapter for VirtualBox and one for KVM.
Was requested by @madaidan on telegram. I guess @madaidan is using it. Haven’t heard any other reports yet. I’ll add a wiki comment to encourage usage reports in Whonix forums.
Signing anything under a stateful sig scheme with the same key more than once destroys its verification guarantees vs stateless that can withstand multiple uses. This is very likely to happen when used in a virtual environment and forgetting to backup the keychain after singing a build when its sig key counter is run down.
codecrypt only includes stateful schemes as of yet (XMSS)
Hash-based signature schemes use one-time signature schemes as their building block. A given one-time signing key can only be used to sign a single message securely. Indeed, signatures reveal part of the signing key. The security of (hash-based) one-time signature schemes relies exclusively on the security of an underlying hash function.
That is a good question. Due to low interest (inquiries and poll) and due to it being complicated enough already I guess suffices as is. Perhaps improve existing documentation to include KVM. I don’t know any other project offering multiple signature schemes to compare. What do you think?