Qubes Canary 034

News
1

Editor’s note: An earlier version of this post mistakenly contained the text of an older canary. This has been corrected below. As always, we encourage readers to verify the cryptographic signatures on canaries, which can always be found in the Qubes security pack (qubes-secpack).

We have published a new Qubes canary. The text of this canary is reproduced below. This canary and its accompanying cryptographic signatures will always be available in the Qubes security pack (qubes-secpack).


                    ---===[ Qubes Canary 034 ]===---


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 March 02, 2023.

2. There have been 87 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 last
   fourteen days of May 2023. 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
----------------------

None.


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
-------------------

Thu, 02 Mar 2023 09:45:31 +0000

Source: DER SPIEGEL - International (https://www.spiegel.de/international/index.rss)
Dubious Alliance: How Present Is the Far Right in Germany's New Peace Movement?
Kaja Kallas: Estonia's High-Profile Prime Minister - a Star in the Making
The Special Tribunal Debate: "An Arrest Warrant Against Putin Would Be Immense"
The War in Ukraine: China Is Reportedly Negotiating with Russia To Supply Kamikaze Drones
Volodymyr Zelenskyy's Heroes: Ukraine's Best Respond to the Earthquake in Turkey

Source: NYT > World News (https://rss.nytimes.com/services/xml/rss/nyt/World.xml)
How Russia Lost an Epic Tank Battle, Repeating Earlier Mistakes
Kyiv Sends Reinforcements to Besieged Bakhmut
Bola Tinubu Elected to Be Nigeria’s Next President
Video: How an Israeli Raid on a Safe House Ended With Civilians Killed
Bola Tinubu’s Victory Extends His Party’s Time in Power in Nigeria

Source: BBC News - World (https://feeds.bbci.co.uk/news/world/rss.xml)
Greece train crash: Angry protests erupt after disaster
India PM Modi urges G20 foreign ministers to overcome differences
How fake copyright complaints are muzzling journalists
Whiskey fungus lawsuit forces Jack Daniels to halt building project
Indian guru's fictional country attended UN events

Source: Blockchain.info
000000000000000000037ab2816f3100fc37acee47a63571b5d3b7ca72145906


Footnotes
----------

[1] This file should be signed in two ways: (1) via detached PGP
signatures by each of the signers, distributed together with this canary
in the qubes-secpack.git repo, and (2) via digital signatures on the
corresponding qubes-secpack.git repo tags. [2]

[2] Don't just trust the contents of this file blindly! Verify the
digital signatures! Instructions for doing so are documented here:
https://www.qubes-os.org/security/pack/

--
The Qubes Security Team
https://www.qubes-os.org/security/
This is a companion discussion topic for the original entry at https://www.qubes-os.org/news/2023/03/02/canary-034/
3 Likes
2

Have I missed something:

1. The date of issue of this canary is December 04, 2022.

– according to the text on GitHub, it should be:

1. The date of issue of this canary is March 02, 2023.

…

3

Umm… it is March 02, 2023. The Qubes Canary 034 | Qubes OS also shows previous canary instead :thinking:
I can see correct canary on github: qubes-secpack/canaries/canary-034-2023.txt at master · QubesOS/qubes-secpack · GitHub

Can we fix it please?

1 Like
4

I’m legitimately curious as to whether this was an unintentional mistake, or as to whether this is an indication that something has actually gone awry; as it does say in the qubes-os documentation regarding qubes canaries:

-If the canaries should suddenly cease.
-If one or more signers begin declining to sign them.
-Or, if the included statements change significantly without plausible explanation

Then this may indicate that something has gone wrong.

Technically, in this case, if this was not an unintentional mistake, then the canaries have indeed ceased, without technically ceasing.

I’m relatively new to this, so anyone with more time on the ground would be more than appreciated if you chime in.

2 Likes
5

Didn’t happen.

I’ll check later today. We shouldn’t just assume this happened, but it’ll take a few minutes to do this.

Didn’t happen.

IF the version in the repository is correctly signed, then I wouldn’t assume anything more than @adw maybe being tired or distracted and having made a copy & paste mistake when updating the website (will also check who actually did that).

I’ll report back later, but YOU SHOULDN’T TRUST ME either. Instead go and check yourself.

1 Like
6

Wrong content tracked by

Qubes Canary 034 published with Qubes Canary 033 information · Issue #8068 · QubesOS/qubes-issues · GitHub

7

Ok, here we go:

user@qubes:~$ git clone https://github.com/QubesOS/qubes-secpack
Cloning into 'qubes-secpack'...                                                                                        
remote: Enumerating objects: 4061, done.                                                                               
remote: Counting objects: 100% (1470/1470), done.                                                                      
remote: Compressing objects: 100% (739/739), done.                                                                     
remote: Total 4061 (delta 741), reused 1410 (delta 730), pack-reused 2591                                              
Receiving objects: 100% (4061/4061), 1.64 MiB | 1.73 MiB/s, done.                                                      
Resolving deltas: 100% (1908/1908), done.                                                                              

user@qubes:~$ qubes-gpg-client-wrapper --import qubes-secpack/keys/*/*
cat: qubes-secpack/keys/core-devs/retired: Is a directory
cat: qubes-secpack/keys/release-keys/retired: Is a directory
cat: qubes-secpack/keys/security-team/retired: Is a directory
gpg: key 063938BA42CFA724: "Marek Marczykowski-G_recki (Qubes OS signing key) <marmarek@invisiblethingslab.com>" not changed
gpg: key 8C05216CE09C093C: "HW42 (Qubes Signing Key) <hw42-qubes@ipsumj.de>" not changed
gpg: key DA0434BC706E1FCF: "Simon Gaiser (Qubes OS signing key) <simon@invisiblethingslab.com>" not changed
gpg: key 8CE137352A019A17: 1 signature not checked due to a missing key
gpg: key 8CE137352A019A17: "Andrew David Wong (Qubes Documentation Signing Key)" not changed
gpg: key AAA743B42FBC07A9: "Brennan Novak (Qubes Website & Documentation Signing) <bnvk@invisiblethingslab.com>" not changed
gpg: key B6A0BB95CA74A5C3: "Joanna Rutkowska (Qubes Documentation Signing Key) <joanna@invisiblethingslab.com>" not changed
gpg: key F32894BE9684938A: "Marek Marczykowski-G_recki (Qubes Documentation Signing Key) <marmarek@invisiblethingslab.com>" not changed
gpg: key 6E7A27B909DAFB92: "Hakisho Nukama (Qubes Documentation Signing Key)" not changed
gpg: key 485C7504F27D0A72: "Sven Semmler (Qubes Documentation Signing Key) <Sven@SvenSemmler.org>" not changed
gpg: key BB52274595B71262: "unman (Qubes Documentation Signing Key) <unman@thirdeyesecurity.org>" not changed
gpg: key DC2F3678D272F2A8: 1 signature not checked due to a missing key
gpg: key DC2F3678D272F2A8: "Wojtek Porczyk (Qubes OS documentation signing key) <woju@invisiblethingslab.com>" not changed
gpg: key FD64F4F9E9720C4D: 1 signature not checked due to a missing key
gpg: key FD64F4F9E9720C4D: "Zrubi (Qubes Documentation Signing Key)" not changed
gpg: key DDFA1A3E36879494: "Qubes Master Signing Key" 1 new signature
gpg: key 1848792F9E2795E9: "Qubes OS Release 4 Signing Key" 1 new signature
gpg: key D655A4F21830E06A: "Marek Marczykowski-G_recki (Qubes security pack) <marmarek@invisiblethingslab.com>" not changed
gpg: key ACC2602F3F48CB21: "Qubes OS Security Team <security@qubes-os.org>" 3 new signatures
gpg: key 4AC18DE1112E1490: "Simon Gaiser (Qubes Security Pack signing key) <simon@invisiblethingslab.com>" not changed
gpg: Total number processed: 17
gpg:              unchanged: 14
gpg:         new signatures: 5
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   5  signed:  20  trust: 0-, 0q, 0n, 0m, 0f, 5u
gpg: depth: 1  valid:  20  signed:   1  trust: 16-, 0q, 0n, 0m, 4f, 0u

user@qubes:~$ qubes-gpg-client-wrapper --fingerprint DDFA1A3E36879494
pub   rsa4096 2010-04-01 [SC]
      427F 11FD 0FAA 4B08 0123  F01C DDFA 1A3E 3687 9494
uid           [ultimate] Qubes Master Signing Key

user@qubes:~$ cd qubes-secpack/
user@qubes:~/qubes-secpack$ git tag -v `git describe`
object 266e14a6fae57c9a91362c9ac784d3a891f4d351
type commit
tag marmarek_sec_266e14a6
tagger Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> 1677757924 +0100

Tag for commit 266e14a6fae57c9a91362c9ac784d3a891f4d351
gpg: Signature made Thu Mar  2 05:52:04 2023 CST
gpg:                using RSA key 2D1771FE4D767EDC76B089FAD655A4F21830E06A
gpg: Good signature from "Marek Marczykowski-Górecki (Qubes security pack) <marmarek@invisiblethingslab.com>" [full]

user@qubes:~/qubes-secpack$ cd canaries/
user@qubes:~/qubes-secpack/canaries$ qubes-gpg-client-wrapper --verify canary-034-2023.txt.sig.marmarek canary-034-2023.txt
gpg: Signature made Thu Mar  2 05:51:48 2023 CST
gpg:                using RSA key 2D1771FE4D767EDC76B089FAD655A4F21830E06A
gpg: Good signature from "Marek Marczykowski-Górecki (Qubes security pack) <marmarek@invisiblethingslab.com>" [full]
user@qubes:~/qubes-secpack/canaries$ qubes-gpg-client-wrapper --verify canary-034-2023.txt.sig.simon canary-034-2023.txt
gpg: Signature made Thu Mar  2 03:47:52 2023 CST
gpg:                using RSA key EA18E7F040C41DDAEFE9AA0F4AC18DE1112E1490
gpg: Good signature from "Simon Gaiser (Qubes Security Pack signing key) <simon@invisiblethingslab.com>" [full]

Switching into my vault qube since --check-signatures seems to be not supported by qubes-gpg-client-wrapper.

user@vault:~$ gpg --check-signatures 2D1771FE4D767EDC76B089FAD655A4F21830E06A
pub   rsa4096 2015-01-05 [SC]
      2D1771FE4D767EDC76B089FAD655A4F21830E06A
uid           [  full  ] Marek Marczykowski-Górecki (Qubes security pack) <marmarek@invisiblethingslab.com>
sig!         DDFA1A3E36879494 2021-11-29  Qubes Master Signing Key
sig!3        D655A4F21830E06A 2021-11-29  Marek Marczykowski-Górecki (Qubes security pack) <marmarek@invisiblethingslab.com>

gpg: 2 good signatures
user@vault:~$ gpg --check-signatures EA18E7F040C41DDAEFE9AA0F4AC18DE1112E1490
pub   rsa4096 2018-11-05 [SC]
      EA18E7F040C41DDAEFE9AA0F4AC18DE1112E1490
uid           [  full  ] Simon Gaiser (Qubes Security Pack signing key) <simon@invisiblethingslab.com>
sig!3        4AC18DE1112E1490 2018-11-05  Simon Gaiser (Qubes Security Pack signing key) <simon@invisiblethingslab.com>
sig!         DDFA1A3E36879494 2018-11-26  Qubes Master Signing Key

gpg: 2 good signatures

So all the signatures check out and I consider the canary 34 valid.

Regarding the website and the respective forum post (triggered automatically by the website update): that looks like a simple copy and paste mistake to me.

2 Likes
8

Yep, this is exactly what happened. Sorry about that, guys. I was AFK and didn’t see this until now. Just pushed a fix:

From my comment on #8068:

To be clear: This was just me being dumb and forgetting to copy/paste the new canary text after substituting “033” for “034” in the announcement text and rewriting the announcement portion. It has nothing to do with the original canary file in the Qubes security pack (qubes-secpack) or the signatures on that file, which everyone is always encouraged to verify. :slight_smile:

4 Likes
9

Also, thank you, @Sven, for reminding everyone about how the canary (and signature-checking in general) is supposed to work.

As Joanna once said, the Qubes website will surely be compromised at some point, which is why we’ve instituted measures that allow us to avoid trusting the infrastructure. Although this was an unintentional mistake on my part, it’s important that we periodically remind the Qubes community of these measures and how to check things properly. Even though I sign my commits for the Qubes website repos and subrepos, I’m not a member of the Qubes security team, and my signature doesn’t go on QSBs or canaries in the qubes-secpack. When I repost stuff from the qubes-secpack onto the website, it’s mainly for visibility, like hanging up a poster on a wall with an arrow pointing toward the actual QSB, canary, or other secpack item.[*]

Btw, that reminds me of this great xkcd comic:

image

[*] In fact, the announcements used to not reproduce the text at all and just contained a link to it, but some folks requested that we also put the text inside the announcement, so I started doing that.

1 Like
10

I believe you.

Just as a thought experiment:

If there were a situation in the future in which the Qubes team were being forced to implement a backdoor and sign a canary, which seems unlikely but not impossible, and then modified the canary slightly to warn people, and people noticed and the people forcing them noticed, and then if they were pressured to provide an explanation, wouldn’t it seem something like this?

In a situation like this, someone with a high threat model like a dissident in a country lacking human rights for dissidents could revert to previous iso and reload backups of their qubes from when the last canary was signed until any new code has been out and people have a chance to see if the code does anything differently? Since qubes is open-source it would be possible to put in a back-door temporarily, but people would eventually find it right, since there are people who compile code and compare sha512 fingerprints with the updates and the code is posted online?

Is there a way to compile the posted new code for the updates, check the hash, and then compare it to the hash of the code dom0 updates if a person wanted to do that?

also thank you to adw for everything you do for the community. this is not criticism of you. you do so much for all of us and i am grateful i am able to use qubes

11

No, because there was nothing unusual with the actual canary, only with a repost of the canary.

Actual canary: https://github.com/QubesOS/qubes-secpack/blob/main/canaries/canary-034-2023.txt

Repost of canary: https://www.qubes-os.org/news/2023/03/02/canary-034/

As you can see from the signed Git log of the actual canary, it never had the same mistake as the repost.

If the actual canary signers were under duress and wanted to subtly signal this somehow, you’d look for something like:

  • The canary actually dies (missed deadline with no explanation)
  • An important statement goes missing from the canary with no correction or explanation
  • Someone who was previously signing canaries permanently stops signing them without explanation

Things that should not worry you would be things like:

  • The actual canary in the sec-pack is fine, but reposts are late or absent on the website, mailing lists, forum, Twitter, Mastodon, Reddit, Facebook, LinkedIn, etc. (The deadline is for the canary itself, not reposts. Also, we don’t have control over third-party platforms.)
  • The canary is signed at the last minute but before the deadline. (People get busy and procrastinate sometimes.)
  • One signature is earlier or later than the other, but both are present within a reasonable period of time. (Sometimes one signer is out of town or something, but we try to plan the deadlines around this.)
  • Something changes without breaking the “rules.” (E.g., next canary is expected in last 14 days of May instead of first 14 days of June like usual, but that’s simply because the latter conflicts with a scheduled vacation. There’s no canary rule that says it has to be the first part of the month.)
  • Something unusual happens but is reasonable, announced in advance, and the appropriate statements are signed (e.g., when Joanna left the security team and was succeeded by Simon).

In general, it’s not realistic for a person or organization to exist that never changes, has zero turnover, never makes mistakes, etc., so you should expect such occurrences periodically.

Also, remember that canaries are fundamentally a social scheme, not a technical one.

Probably a bad idea, because they could be missing out on security updates. If they do download security updates, then those are signed by the same security team who signs the canaries. In order to meaningfully distrust the security team, you’d have to audit the code yourself or find someone you trust more to do it for you. (Seeing whether the code does anything malicious can only meaningfully be done by auditing the source code. You have to assume that a sophisticated adversary would be able to hide on a running system that’s effectively blue-pilled.)

Not my area of expertise, so I can’t comment authoritatively. Since all the Qubes code is open-source, that might be possible. But since not everything is a reproducible build yet, it might not work.

Appreciate it. It was my fault for being lazy and manually copy/pasting for canary announcements instead of writing a script like I did for QSBs. I’ve now fixed that process error, so hopefully that’ll be one fewer mistake I make in the future.

12

@adw this “incident” although harmless got me thinking too. Specifically: there are only two signers (Marek & Simon). Obviously the circle of security team members needs to be small and select (as in actually technically able and willing to actively check for integrity all the time).

Questions:

- without going into detail, are Marek and Simon located within the same legal framework (same country or within EU)?
- would it be possible and make sense to add a third signer on a different continent? (I suppose the issue here is to identify a qualified person and I don't know what other effects this would have on the team/flow)

I perfectly understand the “social vs. technical” and that a canary is always going to be imperfect. So this is not a request to change anything but simply me being curious.

13

I’d prefer to let @marmarek and Simon (not tagged because not on forum) answer that themselves, if they choose to do so.

  • would it be possible and make sense to add a third signer on a different continent? (I suppose the issue here is to identify a qualified person and I don’t know what other effects this would have on the team/flow)

I think the hardest part would, indeed, be finding a suitable third member of the Qubes security team. There are a lot of considerations that go into that, many of which are not obvious. At least that’s my impression. I don’t feel qualified to go into more detail than that, since I’m also fundamentally an observer of that process, albeit closer to it. Again, @marmarek would be the one to ask.

The most surprising thing to me is that so many people apparently interpret my Qubes News reposts of canaries (and, presumably, QSBs) as somehow authoritative, rather than the equivalent of verbose hyperlinks, which is fundamentally what they are. That’s quite eye-opening and, to my mind, calls into question the utility of these security schemes. After all, if the people who these schemes are designed to protect don’t understand them or know how to use them at a fundamental level, then how much protection are they really providing? I suppose in an actual crisis situation, more knowledgeable folks would step up and explain things to everyone, like you did, and maybe that’s enough.

Perhaps what I should do is add a section to these announcements that explains what they are and provides instructions for how to verify them, rather than just linking to all of that information (which I already do), since apparently no one clicks on links. :slight_smile:

1 Like
14

@adw I understand how it is supposed to work and it’s also a good opportunity for everyone to get a refresher. As you are well aware the subject matter (Qubes OS / security) lends it self to paranoid thinking. While in itself a good thing it can also get out of hand, especially when details are poorly understood.

In this specific case my paranoid reaction, before looking into the details went along the lines of: @adw is the community organizer and close to the core team. Is he trying to signal to us that something is afoot?

You’ve made perfectly clear that that’s not the case and that it was a simple copy & paste issue. And you’ve also made clear that …

I don’t know if that’s easily possible, but maybe we could automate the News post based on the sec-pack commit, just as e.g. the HCL updates when qubes-hcl is updated?

It could be as generic as:

“A new canary has been commited to the security pack. See here how to verify it”

I lack the skills to do this, but maybe there is a Jekyll expert out there willing to lend a hand?

1 Like
15

The problem is that if only this aspect of it is automated, then that leaves the mailing list and social media announcements out, and when those don’t occur around the same time as the website announcement, people have historically gotten confused. I’m sure there are ways to automate all of it (and I’d be open to it), but so far it hasn’t happened.

As mentioned above, we used to have brief announcements like this, but some folks complained that the announcements (specifically the ones on the mailing list, IIRC) were useless for plain text email users, since they were devoid of content and required clicking a hyperlink to even read the announcement. This is why I started adding the actual text to the announcements.

Anyway, I’ve been working on some scripts that I hope will serve to generate even better announcements more consistently.

1 Like