Qubes Canary 029 www.qubes-os.org/news/20…nary-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: github.com/QubesOS…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