2021-12-14 05:04:55
Qubes Canary 029
https://www.qubes-os.org/news/2021/12/13/canary-029/
We have published Qubes Canary 029. The text of this canary is
reproduced below.
This canary and its accompanying signatures will always be available in
the Qubes security pack (qubes-secpack).
View Qubes Canary 029 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-029-2021.txt
Learn how to obtain and authenticate the qubes-secpack and all the
signatures it contains:
https://www.qubes-os.org/security/pack/
View all past canaries:
https://www.qubes-os.org/security/canary/
---===[ Qubes Canary 029 ]===---
Statements
-----------
The Qubes security team members who have digitally signed this file [1]
state the following:
1. The date of issue of this canary is December 13, 2021.
2. There have been 74 Qubes security bulletins published so far.
3. The Qubes Master Signing Key fingerprint is:
427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3E 3687 9494
4. No warrants have ever been served to us with regard to the Qubes OS
Project (e.g. to hand out the private signing keys or to introduce
backdoors).
5. We plan to publish the next of these canary statements in the first
fourteen days of March 2022. Special note should be taken if no new
canary is published by that time or if the list of statements changes
without plausible explanation.
Special announcements
----------------------
Many PGP keys in the Qubes security pack (qubes-secpack) that are used
elsewhere in the project (such as the Qubes builder), including the
Qubes Master Signing Key (QMSK), were signed or self-signed using the
SHA-1 hash function. Unlike some other uses of SHA-1, its use in our PGP
signatures does not pose a noteworthy security risk unless an adversary
is capable of performing a successful preimage attack (not merely a
collision attack). Since there are presently no known feasible attacks
against the preimage resistance of full SHA-1, our use of SHA-1 in PGP
signatures does not currently pose a relevant security risk.
Nonetheless, as a preemptive defense-in-depth enhancement and to support
deprecation of SHA-1 in tooling, we have decided to re-(self-)sign many
of these keys using SHA-256 or SHA-512. [3]
In addition, the qubes-secpack contains several expired code signing
keys, old release keys, and keys belonging to individuals who are no
longer active Qubes developers. We have decided to move these keys into
new "retired" subdirectories. (We've decided to move them rather than
delete them, since some users may wish to use them to authenticate old
signatures. Note that this is merely a matter of convenience, since even
deleted files always remain in the Git repository's history and can
always be retrieved that way.)
To be clear, none of the actions described here constitute a response to
any security incident. To our knowledge, the keys in the qubes-secpack
are not and have never been at risk. No key fingerprints have changed as
a result of these actions. We consider this updating and cleanup of the
keys to be more of a "housekeeping" task.
Disclaimers and notes
----------------------
We would like to remind you that Qubes OS has been designed under the
assumption that all relevant infrastructure is permanently compromised.
This means that we assume NO trust in any of the servers or services
which host or provide any Qubes-related data, in particular, software
updates, source code repositories, and Qubes ISO downloads.
This canary scheme is not infallible. Although signing the declaration
makes it very difficult for a third party to produce arbitrary
declarations, it does not prevent them from using force or other means,
like blackmail or compromising the signers' laptops, to coerce us to
produce false declarations.
The proof of freshness provided below serves to demonstrate that this
canary could not have been created prior to the date stated. It shows
203 views02:04
Q
