Open Keisial opened 2 years ago
Excuse my ignorance, but why is it necessary to manually authenticate the package signing keys? Doesn't Qubes OS do this for the user automatically? (Of course, this assumes that the the Qubes installation was installed from an authentic ISO, but we've already worked out a way for users to authenticate their ISOs.)
(Attempted to make issue title more descriptive. Let me know if I've misinterpreted anything.)
Excuse my ignorance, but why is it necessary to manually authenticate the package signing keys? Doesn't Qubes OS do this for the user automatically? (Of course, this assumes that the the Qubes installation was installed from an authentic ISO, but we've already worked out a way for users to authenticate their ISOs.)
@Keisial what is your use-case?
You would already have the signing keys if you are using the provided templates. Are you creating your own template? You would need to import those signing keys from somewhere. You want to test a package from a release into another? You might need the corresponding key. Maybe just to verify that nobody tampered with the repositories configured on your template?
(This is mostly a continuation of #4212)
Qubes OS 4 uses several Packages Signing Keys for their package repositories, namely:
EE88DA5FB2B7082919C8826D19205A11FDE3D0AA
)A55DC100FFD712ADB92B5B1043B760F197CA1BF5
)These keys were hard to find (issue #4212), which was fixed by publishing them on https://keys.qubes-os.org/keys/ This allows fetching the cryptographic material.
However, such keys might not be the real ones. Per Qubes OS threat model the infrastructure must be distrusted since keys.qubes-os.org might be compromised.
It is possible to verify these keys by extracting them from the templates inside the official image, but that's a needlessly convoluted process:
Expected:
Include the package signing keys in the qubes-secpack (probably in a new
keys/packages-signing-keys
folder) and/or sign them by the Release 4 Signing Key or the QMSK.