[qubes-users] Qubes Canary 029

[Andrew David Wong]

Dear Qubes Community,

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:



Learn how to obtain and authenticate the qubes-secpack and all the
signatures it contains:



View all past canaries:



```

---===[ 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
that a series of canaries was not created in advance.

This declaration is merely a best effort and is provided without any
guarantee or warranty. It is not legally binding in any way to anybody.
None of the signers should be ever held legally responsible for any of
the statements made here.


Proof of freshness
---

Mon, 13 Dec 2021 01:15:23 +

Source: DER SPIEGEL - International 
(https://www.spiegel.de/international/index.rss)
Resurrection of the SP: The Unexpected Rise of Germany's New Chancellor, 
Olaf Scholz
BioNTech Founder Şahin on the Omicron Variant: “It Will Make Scientific 
Sense To Offer Booster after Three Months”

City of Warriors: Resistance Across the Border to the Myanmar Military Junta
Deadly Intrigue: The Story of the Destruction of an Aid Organization
The One-Man State: Viktor Orbán and the Fall of Democracy in Hungary

Source: NYT > World News 
(https://rss.nytimes.com/services/xml/rss/nyt/World.xml)

Haiti’s Leader Kept a List of Drug Traffickers. His Assassins Came for It.
‘Our Boat Was Surrounded by Dead Bodies’: W

Re: [qubes-users] USB controllers

[Franz]

>
>
>
>
> Is it possible for you to boot a live distro from USB and see if the
>>> same issues exist?
>>>
>>
> If I boot from a live Debian everything works. I tried 5 times one after
> the other and it was much faster and the mouse worked, immediately after
> tried Qubes and the mouse did not work. So it seems Qubes specific.
>
>
Just to note that I made some improvements: I bought two different PCI USB
controllers, connected the mouse and keyboard to one of them and kept the
other one for connecting hard disks, USB keys, file transfers, and
sometimes a printer. Everything works reliably.

Regarding the noise of the fans, I bought a water cooling system with a
radiator outside of the room, to keep it silent.

The only remaining issue is that it is slow. It is slower than my x230. But
x230 has 16G RAM and ME, while with this KCMA-D8 I have 32G RAM, no ME and
coreboot.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAPzH-qA2LqvWG_im_WfZp9yofQaMNdFKiVY37XTA%2B3e6Hsbfmw%40mail.gmail.com.