GitLab

[Hack]

Hi,

Why do you use GitHub instead of GitLab?

[Ivan Mitev]

On 05/09/2017 09:46 PM, Hack wrote:
> Hi,
>
> Why do you use GitHub instead of GitLab?

Most likely because the devs historically chose github and it works well
for the project's needs ?

If your question is instead related to the trust/security/... (or lack
thereof) of github vs. gitlab, github isn't a trusted infrastructure [1]
so it's not a concern.

Hope this helps,

ivan


[1]
https://www.qubes-os.org/doc/user-faq/#what-does-it-mean-to-distrust-the-infrastructure

[Hack]

On 05/09/2017 09:13 PM, Ivan Mitev wrote:
>
>
> On 05/09/2017 09:46 PM, Hack wrote:
>> Hi,
>>
>> Why do you use GitHub instead of GitLab?
>
> Most likely because the devs historically chose github and it works well
> for the project's needs ?
>

Useless answer, as it does not give any explanation (see below ↓)…

GitLab works well, there is even a Qubes OS repository added, 2 years
ago, by Wojtek Porczyk, but it is not used. Why?

> If your question is instead related to the trust/security/... (or lack
> thereof) of github vs. gitlab, github isn't a trusted infrastructure [1]
> so it's not a concern.
>
> Hope this helps,
>
> ivan
>
>
> [1]
> https://www.qubes-os.org/doc/user-faq/#what-does-it-mean-to-distrust-the-infrastructure
>
>

From your link:
"We believe that many attempts to make the infrastructure appear
trustworthy actually provide only the illusion of security and are
ultimately a disservice to real users."

With all due respect, I find this "philosophy" so stupid…

From what I have studied, open source software are more secure than
closed source software. And there is plenty of studies on internet that
say the same thing… So GitLab is better…

Now if we take a concrete example:
I have a wife, children, and I have the choice to live in a quite
suburb in Glendale, or to live in the worst place in Detroit.

I know that I can be in danger in Glendale, but statistically, I know
that Glendale should be better for my family.

So what? Should I go to Detroit because I can be potentially in danger
too in Glendale? And because I would be less prudent at Glendale, I have
to go to Detroit to protect my family and myself, in a better way? Well,
as I am not dumb, I will choose Glendale rather than Detroit…

The same thing apply with software: Gnu/Linux is a better choice than
Windows.

So I use Gnu/Linux, rather than Windows (and GitLab rather than GitHub)…
But if I follow your line of reasoning, I should choose Windows? Because
it will "disservice to real users", as I will feel being in more secure
area… It makes no sense…

More security is better… not less…

And finally, it is sad to use GitHub, because:
1. even if you cannot trust any infrastructure, yet, you can prefer
a better one…
2. you prone paranoia, but do wired choices (including your GitHub
choice)…
3. your "choice", to use GitHub, does not help open source…
4. your "philosophy" sucks, because it is hypocritical (open source
is better, and more secure, but only when it comes from us, but wait, do
not trust us too much… and trust GitHub (closed source), but not too
much…; blah blah blah…);
5. it is egotistical to use GitHub instead of GitLab, "no
solidarity", free for all…

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

No, that doesn't follow. This is about the infrastructure, not the
endpoints.

> More security is better… not less…
>

We agree, but we disagree about what constitutes "more security." We
believe that what many people regard as "more security" is actually the
illusion of security, and we believe that having more of the illusion of
security is worse than having less of it.

> And finally, it is sad to use GitHub, because:
> 1. even if you cannot trust any infrastructure, yet, you can prefer
> a better one…
> 2. you prone paranoia, but do wired choices (including your GitHub
> choice)…
> 3. your "choice", to use GitHub, does not help open source…
> 4. your "philosophy" sucks, because it is hypocritical (open source
> is better, and more secure, but only when it comes from us, but wait, do
> not trust us too much… and trust GitHub (closed source), but not too
> much…; blah blah blah…);
> 5. it is egotistical to use GitHub instead of GitLab, "no
> solidarity", free for all…
>

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJZF2EEAAoJENtN07w5UDAwvB0QAMFZgz67cNJYm3JfcsQEKWJN
x1R5DhuS0BTfwDsW7BLWS0OhRdXO28MIgFRa+9MCiVLnvbCxySM37Gymq8q8q7H6
V0nO4kwvs2q6swcESIurb+shzVw18ApM5ZVNRKX9Xi3rD2Na6Bjr33oocboxrehw
6Ib8Zk+6c6XhPlCeotKxguq1W7ZvCIz+/N1fpTvmPJrpccGLHqX8nQTPxN3I1gc6
rliCD7kHnM7ePfjMDFsCuxR7Uq3diq3NiKQhxb93Njqvq0efwFpuymHCEgeyf63Q
1GEun0qz9B3A9XSmaFjP+swcQ9M+c3INXenfcOpJ+Fh+ua+MWAf7V3tgcv1c27Qa
Fg7GPLJlgwdbWyBUkeKO0YlZtYdciAw+xLTA+KKDZfP5zrmNzSPssJ0pNh7ZuPzU
8x/lgVszB060MnBvlyH5fyrtikp5fZ/ukWnRbzkCT0+EORoLM824WIRjntPMD5Tx
7V88zHRGbQyxEh9XA+i7RUBFpm/7eg3Y6W47l9B7EfC/8/p6IWr3QFCwG1hictCh
samEv29IUIqUkisKpPK8If4aTK840R3Z1OGQcqZmst4H84kEmrq5yvCYlhDq44Xh
0L035BSqx8lTPvvW2VylGe/8U7Fbbe51ofln9ScXoBpXlHsP5pmcaz4P4ucidlER
H+xrnlzlscKa6prWmpf9
=/+Th
-----END PGP SIGNATURE-----

[Leo Gaspard]

On 05/13/2017 09:40 PM, Andrew David Wong wrote:
> We agree, but we disagree about what constitutes "more security." We
> believe that what many people regard as "more security" is actually the
> illusion of security, and we believe that having more of the illusion of
> security is worse than having less of it.

I don't want to take a stance on this GitHub vs GitLab issue, but just a
fact that strikes me as a really recent Qubes user (something like a few
weeks):

There *is* need for security in the infrastructure.

Not when the Qubes system is running. Just during the first installation.

I didn't have the masterkey at hand. My solution has been to ask a few
people I know with different ISPs to check out the webpage with it, but
it is hosted by GitHub.

How, for trust initialization, am I to know 427F 11FD 0FAA 4B08 0123
F01C DDFA 1A3E 3687 9494 is actually Qubes master key and not GitHub's
MitM signing key?

Now I've made that leap of faith, but I knew no-one who could confirm it
to me, except... this GitHub web page.

From now on I can be pretty confident about always receiving the updates
and any of my future system being installed with the same OS, but that's
not helpful if the key was not actually Qubes' in the first place.

Even though identity continuity already makes attacks (way) harder, in
my opinion trust initialization can only be done by some amount of trust
in the infrastructure, that is not perfect security but should be enough
to reasonably assume the webpage is indeed showing the right fingerprint.

That said, whether GitLab would provide more or less confidence in this
is an entirely different debate, to which I'd rather avoid participating.

Cheers,
Leo

[Hack]

On 05/13/2017 09:40 PM, Andrew David Wong wrote:

But why that doesn't follow? It is very subjective… Nothing prevents it,
mostly when the infrastructure hosts the endpoints…

Sorry, but I do not understand your logic.

>> More security is better… not less…
>>
>
> We agree, but we disagree about what constitutes "more security." We
> believe that what many people regard as "more security" is actually the
> illusion of security, and we believe that having more of the illusion of
> security is worse than having less of it.
>

It is a dialogue of the deaf…

I think it is a useless talk, and I do not want to troll.

Anyway, thank you for your attention.

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

You wrote: "So I use Gnu/Linux, rather than Windows (and GitLab rather

than GitHub)… But if I follow your line of reasoning, I should choose
Windows?"

For a personal computer user, the question of whether to use Gnu/Linux
or Windows is a question about which OS to install on an endpoint. We
distinguish between endpoints and the infrastructure. While we distrust
the infrastructure, we do not distrust endpoints. On the contrary, we
believe that endpoints should be trustworthy, which is why we've created
Qubes OS.

It does not follow from our distrust of the infrastructure that we think
you should choose Windows, since that choice is a choice about your
endpoint, which we think should be trustworthy.

>>>> More security is better… not less…
>>>>
>
> We agree, but we disagree about what constitutes "more security." We
> believe that what many people regard as "more security" is actually the
> illusion of security, and we believe that having more of the illusion of
> security is worse than having less of it.
>
>
>> It is a dialogue of the deaf…
>
>>>> And finally, it is sad to use GitHub, because:
>>>> 1. even if you cannot trust any infrastructure, yet, you can prefer
>>>> a better one…
>>>> 2. you prone paranoia, but do wired choices (including your GitHub
>>>> choice)…
>>>> 3. your "choice", to use GitHub, does not help open source…
>>>> 4. your "philosophy" sucks, because it is hypocritical (open source
>>>> is better, and more secure, but only when it comes from us, but wait, do
>>>> not trust us too much… and trust GitHub (closed source), but not too
>>>> much…; blah blah blah…);
>>>> 5. it is egotistical to use GitHub instead of GitLab, "no
>>>> solidarity", free for all…
>>>>
>
>>
>

> I think it is a useless talk, and I do not want to troll.
>
> Anyway, thank you for your attention.
>

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJZF2iRAAoJENtN07w5UDAwvS4P/2B5IVUjFmT58D13qAabL0CD
PTltxppDEtlXbPgtUi/q0a6kuzfnd1/UDhnLM2NUe+wr2pu/Q+YFjmJFBwIoSD7f
4kAbntWXRNqRQ5DlXfPaqKyzO4+rY1aCqrKldsOETrQOpKOUl3+sCU/1YeV3ju48
NgULVNv+j/GKW4TjK8raOYmNgsrTQpUJEj38VFJECdqp50//xaZlR+yvv3EUEysR
np1+D3vQ+PWiDgydllSmUH+pXTQy0mWrkPBcjrX7nPAB8UBEa34J7cNTgDVkh0pE
gW91FhHO0GmETGo9xUNIGNqk6UCNSPi89XR+LK3iVqRLFIcQQ8VkvJfEkHywspOK
x+DLpH7vKvCCMsBscjlZNlAQCUm4XipEMe0c31EzfTdE3I6C+OPZY9AuBSORkr2l
5aMOxajRZsswWwvusQI28vBvwIGvdxDZrn4emEwBmC+LLyDykDCnbpClP8Ioetf9
Id4wQGawFz+dya2BMlvAYWROUiSW/8sjdZMsb1l2tsA41NNoKqBfe0hk/t/XFVuW
BGj1+8p+4A2GEzKuaFnn8XlKJpk+VUpfguK8nTJwKY8GedMSvcoijV9UWH47s5k1
BabFfVDjZ17oDt1+ii5GNn4EW/cFBQ+MoMxPWMo70CvFdA0siIrUHayJ2B7OlAlY
9gm+f6CVZmHvc/TnrYSR
=OJ9F
-----END PGP SIGNATURE-----

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

There are many other methods you could use to attempt to verify the
master key fingerprint aside from relying on the Qubes website. Here's
a brief, non-exhaustive list:

* Use different search engines to search for the fingerprint.
* Use Tor to view and search for the fingerprint on various websites.
* Use various VPNs and proxy servers.
* Use different Wi-Fi networks (work, school, internet cafe, etc.).
* Ask people to post the fingerprint in various forums and chat rooms.
* Check against PDFs and photographs in which the fingerprint appears
(e.g., slides from a talk or on a T-shirt).
* Repeat all of the above from different computers and devices.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJZF2odAAoJENtN07w5UDAwyYMP/jknWPBwjDlqAd6haYQjfaBB
f6KoBJ76cva5s3VYY64/FOHAYmRgS/Sci+xFzQrAdIYPiMgBrDZz2Cr6kfasa04o
iZ/iFNQRdvh8JIU2lQ54IrGvUk8LO7cw+4tLkM8HdRCvrR+MaPj5yCNrbontQZhM
fYAL8AYgYkfNnZS2qMsvclBrxCBancZgNkwOtHZpsDPYlmU8K5lHQ2gc59zOE3rZ
kdECElLUwl4CY/ZLFQPDGdIkkwVgKAO2rsaIRAUwY2ck2r1DMcAlQU7QY0VNz6BV
iYXv4VMQyMCAnO2ogJN3ehO2GLNc/4+D+3ZathgIqSWSqOusrRTiaU9TrLHbcSOT
rUS3Dd/HU5X8fzNxufhNGMzpEDi6M8NE1D6XvoNDidTlmzrLP7gvmvZ8tXbczMk8
ejOL7ilb8sQai3aGMasaVAkuWHUSooy9I1ZtSo44JcWGn4DGvu/mI2x9ODOiU/Hg
W2IHg632J0Nln79UWmWEujWZ4nNR3WltxcBopTb3uDFr0TzXI1cryQbq47GPFowZ
0hDIj8F2C1s6h4Ytkdobdnqa4KmxLt8fO+EI0mBzx7+8rzdKaetGVZoOTurKR1UK
lPHPSroCng3c/C87i2tBA5DN+2IYTLffV0Ivx/vaipr4FMWZuLJbkQi+QsCxoOi8
sA9wzmDbFkhbKae+X1Kh
=AlBx
-----END PGP SIGNATURE-----

[Felipe Dau]

On Sat, May 13, 2017 at 03:18:39PM -0500, Andrew David Wong wrote:
> There are many other methods you could use to attempt to verify the
> master key fingerprint aside from relying on the Qubes website. Here's
> a brief, non-exhaustive list:
>
> * Use different search engines to search for the fingerprint.
> * Use Tor to view and search for the fingerprint on various websites.
> * Use various VPNs and proxy servers.
> * Use different Wi-Fi networks (work, school, internet cafe, etc.).
> * Ask people to post the fingerprint in various forums and chat rooms.
> * Check against PDFs and photographs in which the fingerprint appears
> (e.g., slides from a talk or on a T-shirt).
> * Repeat all of the above from different computers and devices.

Good examples! It would be nice if these were also on the verification
page [0].

I would like suggest an additional approach that might be useful as
well, which is using the debian-keyring. Assuming that the system
which you are using to download Qubes is running a legitimate Debian
(oh well), then you can easily verify Qubes' master key, as most of
the ones that signed it are either in that keyring or were signed by
others that are. This is what Tails instructs users to verify their
key in one of their guides [1].

Thanks,
-Felipe

[0]: https://www.qubes-os.org/security/verifying-signatures/
[1]: https://tails.boum.org/install/expert/usb/index.en.html#verify-key

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Thanks. I've added this information to the document.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJZF3wUAAoJENtN07w5UDAwX9UQAKbGZgP1G4u0OX7l5BBPtwW6
aCe2xzFQOoXXg9ux8sGyrrEDtkcEiYABv6lCocnb1cAwW+rCOnX8k8y1xonwbtRH
Z216wgAo1Pnlme8HKkEFR/TXAY3k5+9ABSDLv3Q613knzJFm3yj37hOQkotNHGjV
RLWfRsC4GbC5gAPTryZEbcsea4EPjKxo7549WH9p9OYjP7Sz1KxtMISmHtH9WaBe
qH+9zlL/JzV+Ivmt7QMA3aTMNhla4rOFLrZGLWGNer6WyEryd6CQkoL1AwtOJcek
cisMzclf30CtLmqUiTfbMT3vm4uIjavElgFiCww8AwC/TRrBtPHtuRTlOHunaCZj
oIRnd2lV1ztutPwILMbB9r8p1WL5mPfjY3uedigdwPhX1ML/hrqgx3e6YuwelkFV
O4jSJrzdEspyzknqz7evSGweoKc3HGpbwICFwk2Fm+C8R1NbYufUem/5fMC2XQEV
CZPDsYaO5oJITrJNfFi9PAeZQZpApUA2q33MEqJVK+Pwa20jwZyLplHLBg/CTVBE
nv1TVPpT/1Znd7ASXGhJsAtvbOqyUFjGkB/2NXwkuCIg7Gb9MyvQJAm01L4OOMgY
Ag/lgCNaPOqnk26OTnyrK5UODk8Zcy41YioEJvNSx1OkBLpM8CEeD+4/+tN5yFZt
es56EhrkF5JoGUPlKUCe
=S0N0
-----END PGP SIGNATURE-----

[Felipe Dau]

On Sat, May 13, 2017 at 04:35:18PM -0500, Andrew David Wong wrote:
> Thanks. I've added this information to the document.

Great!

Thanks,
-Felipe

[Peter Todd]

On Sat, May 13, 2017 at 03:18:39PM -0500, Andrew David Wong wrote:
> There are many other methods you could use to attempt to verify the
> master key fingerprint aside from relying on the Qubes website. Here's
> a brief, non-exhaustive list:
>
> * Use different search engines to search for the fingerprint.
> * Use Tor to view and search for the fingerprint on various websites.
> * Use various VPNs and proxy servers.
> * Use different Wi-Fi networks (work, school, internet cafe, etc.).
> * Ask people to post the fingerprint in various forums and chat rooms.
> * Check against PDFs and photographs in which the fingerprint appears
> (e.g., slides from a talk or on a T-shirt).
> * Repeat all of the above from different computers and devices.

Don't forget the PGP web-of-trust.

For me personally this is a very short trust path with multiple connections.
For example:

1) my PGP key is 0x7FAB114267E4FA04
2) I've signed Nicolas Vigier (boklm)'s key, IIRC after a keysigning a few
years back at a Tor conference.
3) Nicolas Vigier has signed the Qubes Master Signing Key.

Which you can see here: https://pgp.cs.uu.nl/paths/7fab114267e4fa04/to/2067001b1b678a63.html

A few more paths:

Me to Ola Bini: https://pgp.cs.uu.nl/mk_path.cgi?FROM=7FAB114267E4FA04&TO=295c746984af7f0c&PATHS=trust+paths
Me to Holger Levsen: https://pgp.cs.uu.nl/mk_path.cgi?FROM=7FAB114267E4FA04&TO=091AB856069AAA1C&PATHS=trust+paths

Unfortunately the tools to actually find these paths all kinda suck, but they
do at least the paths exist. The one I used to find the above is
https://pgp.cs.uu.nl/, however it has the significant limitation that it only
works for keys in the "strong set" - the Qubes signing key is *not* in that set
because it has never signed another key that is in that set.

IMO the Qubes project should fix this.

--
https://petertodd.org 'peter'[:-1]@petertodd.org

[Chris Laprise]

On 05/13/2017 05:35 PM, Andrew David Wong wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 2017-05-13 16:01, Felipe Dau wrote:
>> On Sat, May 13, 2017 at 03:18:39PM -0500, Andrew David Wong wrote:
>>> There are many other methods you could use to attempt to verify the
>>> master key fingerprint aside from relying on the Qubes website. Here's
>>> a brief, non-exhaustive list:
>>>
>>> * Use different search engines to search for the fingerprint.
>>> * Use Tor to view and search for the fingerprint on various websites.
>>> * Use various VPNs and proxy servers.
>>> * Use different Wi-Fi networks (work, school, internet cafe, etc.).
>>> * Ask people to post the fingerprint in various forums and chat rooms.
>>> * Check against PDFs and photographs in which the fingerprint appears
>>> (e.g., slides from a talk or on a T-shirt).
>>> * Repeat all of the above from different computers and devices.

Also, the point about Tor implies there are many different PGP key
servers where a key can be looked up. Its not hard to do.

--

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2017-05-13 18:21, Peter Todd wrote:
> On Sat, May 13, 2017 at 03:18:39PM -0500, Andrew David Wong wrote:
>> There are many other methods you could use to attempt to verify the
>> master key fingerprint aside from relying on the Qubes website. Here's
>> a brief, non-exhaustive list:
>>
>> * Use different search engines to search for the fingerprint.
>> * Use Tor to view and search for the fingerprint on various websites.
>> * Use various VPNs and proxy servers.
>> * Use different Wi-Fi networks (work, school, internet cafe, etc.).
>> * Ask people to post the fingerprint in various forums and chat rooms.
>> * Check against PDFs and photographs in which the fingerprint appears
>> (e.g., slides from a talk or on a T-shirt).
>> * Repeat all of the above from different computers and devices.
>
> Don't forget the PGP web-of-trust.
>

Good point. Added.

> For me personally this is a very short trust path with multiple connections.
> For example:
>
> 1) my PGP key is 0x7FAB114267E4FA04
> 2) I've signed Nicolas Vigier (boklm)'s key, IIRC after a keysigning a few
> years back at a Tor conference.
> 3) Nicolas Vigier has signed the Qubes Master Signing Key.
>
> Which you can see here: https://pgp.cs.uu.nl/paths/7fab114267e4fa04/to/2067001b1b678a63.html
>
> A few more paths:
>
> Me to Ola Bini: https://pgp.cs.uu.nl/mk_path.cgi?FROM=7FAB114267E4FA04&TO=295c746984af7f0c&PATHS=trust+paths
> Me to Holger Levsen: https://pgp.cs.uu.nl/mk_path.cgi?FROM=7FAB114267E4FA04&TO=091AB856069AAA1C&PATHS=trust+paths
>
> Unfortunately the tools to actually find these paths all kinda suck, but they
> do at least the paths exist. The one I used to find the above is
> https://pgp.cs.uu.nl/, however it has the significant limitation that it only
> works for keys in the "strong set" - the Qubes signing key is *not* in that set
> because it has never signed another key that is in that set.
>
> IMO the Qubes project should fix this.
>

It's unclear to me whether there's any practical way to perform such a
signing without exposing the QMSK to unacceptable risk. Joanna wrote [1]
that the QMSK was generated on an airgapped machine and that the private
key has never left that machine (and hopefully never will). I infer from
context that this refers to a physically (as opposed to virtually)
airgapped machine. Since the QMSK was generated there (and, presumably,
Release Signing Keys (RSKs) are also generated there), this entails that
some GPG-like program (probably GPG itself) is installed in whatever OS
is running on that machine. Let's refer to this as QMSK's "environment."

Clearly, both the QMSK and RSK public keys get transferred off of the
airgapped machine somehow, since we have copies of them. I assume that
such transfers are only one-way and are tightly controlled. That is,
only public keys are allowed to leave the QMSK's environment, and
nothing is allowed to enter. In particular, it's safe to assume that
there is no networking (or else it wouldn't be an air gap) and that no
freely rewritable USB drives (i.e., drives without write-protect
switches) are plugged into that machine. (This is inferred from the fact
that Joanna was warning the world about the dangers of plugging USB
devices into machines years before BadUSB.) This suggests that some kind
of read-only medium is used to enforce the one-way transfers.

If all this is correct, then the only way for the QMSK to sign another
key is to:

(1) Generate the key in the QMSK's environment;
(2) Transfer the key to the QMSK's environment.

(1) is the method used to create RSKs, but it's not clear whether this
would help with getting the QMSK into the strong set. Would it be
sufficient for the QMSK to generate a key that subsequently enters the
strong set? Even so, this would introduce new complications to the Qubes
PGP trust model. For example, should the strong set key generated by the
QMSK be considered just as trustworthy as the QMSK itself? Should it be
used to verify RSKs and Qubes ISOs? If not, can such accidental misuse
be prevented, and if so, by what means should that be enforced?

(2), meanwhile, requires transferring the key to the QMSK's environment
via:

(3) The network;
(4) A storage medium;
(5) Manual input.

Let's assume that (5) would be too cumbersome and error-prone to qualify
as "practical." (3) would, again, entail that the machine is no
longer airgapped. (4) is inherently risky. The riskiest storage media
are, presumably, those with rewritable firmware, such as many
conventional USB drives. Even with less risky media (e.g., CD-ROMs or
even floppy disks), however, we can't rule out the possibility that a
malformed PGP public key block might try to exploit a hypothetical
vulnerability in GPG. So, in general, (2) may not be worth the risk.


[1] https://www.qubes-os.org/security/verifying-signatures/#importing-qubes-signing-keys

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJZGKvVAAoJENtN07w5UDAwt4QP/3APMZl7IQ/39pP/Y8iAet4n
azKYxQTfz6paoCTk7UqWcfsmlbP6hzPqoADmK5GDtDPgqhN8bRCH+6s0MKjsCDPP
9IVIAHZ8G36O8+c/zrbHHxm6zUoweYuciXJQYc3CdKPNnlNr/p7T89Zrea0SBJ2O
kkMtPvXkr0OgGniz4ZCSpxjD+OlSM/jwMNSGiaNoSM7j9EdP4XaRIc4rNkoVifFx
9baA2xFYRlozQ+gDTeDtKx08h1TPGP3nVwvcpld3j21stBBonlyveu7TJ8Zi54i1
To5GzOFTbBy0IHbmoN8SB0zgWAPIGksNXLs4cBGms7PMC1yjTVLojq2B0O26rkWL
PcQzIv7Cnnr9J9VIGnWLe1DkjjL1CA57EPL//F/M0mPA2OCQeNllOV1fXRbKqzc0
basdNd4Lsh13cw/iodcJDnlaUjRqup3b2RJjtD38ZpJuQAd6R2MDVtAbW/nQ0LiE
AQBlHSPYds0uwel5fQC1Newj6oB0QUTwzJXx+7T/a+PP2LoQgadjvI3+YJLOUQ/O
BfI4eFkhP+xKWfuCvTjXHFTpVpb5oB1wb7WnEDDnDXqnhWkh6W0ugIIkOVLhKfgM
92iZJnfPtvnOEimBUx5xiHv805pSWxps/4xJzLmfnKQ9//MoTbqp5/19crSyu8nO
CLzc1iqx3+j7BuJOlEX6
=h+YB
-----END PGP SIGNATURE-----

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2017-05-14 14:11, Andrew David Wong wrote:
> In particular, it's safe to assume that there is no networking (or
> else it wouldn't be an air gap) and that no freely rewritable USB
> drives (i.e., drives without write-protect switches) are plugged
> into that machine.

(Of course, even the presence of a write-protect switch governing the
normally user-accessible storage area doesn't entail that the firmware
isn't rewritable.)

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJZGK6pAAoJENtN07w5UDAwqucP/2IEaLG6lzrp4+/ucakfLWgr
aUXkANeyaAHio1914kRnLUT5EeTFOqAnL5FY2pUVVabBEkyzsEdMqflWDzXsCU70
3HI7JEyGH+p/Jn0Xv5zgdUP6REdW2dD7fOWui0nUNyiPLvrWcZukPzKgQgfMGip2
0PabTGsqYluY/M6ljdjagHdvjwg25mLkICv4m0o9fkFiGTUCslHAC0Z66pKlVVTG
Xsi1LFsZ1WzHAMSeik9yXWCA72vYK5DBeiG2o0N1CY7gHNsXxHnxCTa8Ce/e6XtH
tUo0NzmEUtaLxBwRPiPnyyZaIGLsBWIfLhok+4xoRthG3ZaKMEi7DZN40uxWNIuf
zMHCnzUw/RhE7r3GTVIdGZIvyIMXPcb83cLh8FXujTfHQL3HYl01rOkxHpc3FFDX
0mjzj52SBCpVcuHyGHKJtuJCRvYguhikf1CZX1pZ2grz6uMxu2lAC2dr28qO5KZ1
16PwAfMMEmounW6WHMrIN5XhkBXLsFbiiRFJZS30+UXvTdkz0yIigHy7IZpUCSov
jHztFJhR/oad9I8i6Ts3oHbkvRfGOKRGxI6hMSzCUet5WYjqQZC4aSH407mSfz2E
aFepAcPgr86sZqjWtAaE7dAg6+SZ5mfpjl7F0QYvc3G6v1A26qJbd3WgRi+JTPNH
KCKZMDSjSf4AH4FxpIrx
=d8w5
-----END PGP SIGNATURE-----

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2017-05-13 22:06, Chris Laprise wrote:
> On 05/13/2017 05:35 PM, Andrew David Wong wrote:
>> On 2017-05-13 16:01, Felipe Dau wrote:
>>> On Sat, May 13, 2017 at 03:18:39PM -0500, Andrew David Wong wrote:
>>>> There are many other methods you could use to attempt to verify the
>>>> master key fingerprint aside from relying on the Qubes website. Here's
>>>> a brief, non-exhaustive list:
>>>>
>>>> * Use different search engines to search for the fingerprint.
>>>> * Use Tor to view and search for the fingerprint on various websites.
>>>> * Use various VPNs and proxy servers.
>>>> * Use different Wi-Fi networks (work, school, internet cafe, etc.).
>>>> * Ask people to post the fingerprint in various forums and chat rooms.
>>>> * Check against PDFs and photographs in which the fingerprint appears
>>>> (e.g., slides from a talk or on a T-shirt).
>>>> * Repeat all of the above from different computers and devices.
>
> Also, the point about Tor implies there are many different PGP key
> servers where a key can be looked up. Its not hard to do.
>

Thanks. Added explicitly.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJZGK7DAAoJENtN07w5UDAwxRkP/1S07cJ7xWmdeAJBaNlGukHY
ZtfNPS4l8hLTbqfTn3msEegQgRJ48AADrFWN+Ne1qEzi03QGjGJm5V5WrDdr9V26
VVzAUbGvp8OWg6kU9DC2w4DNr60MsU85HXZBtWw8RS/Dmgiy9hjmac+ZyfU1h3GR
mZSj3EXZcSJFlsjt0fvQTsHFJXSOemj4ghG6U3rUti56LcOZ1mbB853ePk3KptqS
hiC4DA6xmYuMtV1MeOGBO5NiVECwv79nVkvS8/y2t1RdtBlYKFkf6uKE2uZRhQJv
tslCCbBZwOcZgqUePHiAvCKBXU1pTAX3IYLGonARCr0gaAPB6Uw57PV9RSYxuGDc
Jp3g1857AcoIjZsTgjdNZDs7rp9Sj9ikcrIhFAEFzo5QxsH6qUK1Wt5Bfwx1sImY
7mTzLIyTvUY/EOH2LCcq8iB4Y64SYy5h+zyp19M/w+kCrjEQSe6flzcC/bkWf0nm
2kGhGAOBXfb6bioNuzOjHXLuKah7sHECOiu0cGeJypsTbjkwHb1rEgMBKDIgvDf+
4m9mzwgHRLN9pQmUi+qMl41xzs0PjbJydm6KzFcZZ2xGG2y8L8poqq66y8IwJ0IU
4QruiuuTnO8kfnpH5xJnAjPi3AGsUsUvj+3XMZ7gON9Hbhb0fWoUEI3maKrM2Ait
Azhl4h8y8s1N2w9hFyVa
=naO/
-----END PGP SIGNATURE-----

[Jean-Philippe Ouellet]

Uhh... except it *has* signed other keys, for example:

$ gpg2 --list-sigs marmarek
pub rsa4096 2014-03-05 [SC]
0064428F455451B3EBE78A7F063938BA42CFA724
uid [ unknown] Marek Marczykowski-Górecki (Qubes OS signing
key) <marm...@invisiblethingslab.com>
sig 3 063938BA42CFA724 2014-03-05 Marek Marczykowski-Górecki
(Qubes OS signing key) <marm...@invisiblethingslab.com>
sig EE570349A603BCB6 2014-03-05 Marek Marczykowski (Qubes OS
signing key) <marm...@invisiblethingslab.com>
sig DDFA1A3E36879494 2014-04-30 Qubes Master Signing Key
sig 3 063938BA42CFA724 2014-04-30 Marek Marczykowski-Górecki
(Qubes OS signing key) <marm...@invisiblethingslab.com>

This is the reason we can initially import only the master signing
key, trust it, and have all other valid Qubes signing keys trusted
transitively. This is done for example here [1].

[1]: https://github.com/QubesOS/qubes-builder/blob/3352cd4363a25debd77ced0a1fa752944ac1ef2f/scripts/verify-git-tag#L25

[Peter Todd]

Ah! Well that makes things much easier.

So Marek's Qubes OS signing key (0x063938BA42CFA724) is also not in the strong
set, because it hasn't cross-signed any keys that are. To get it into the
strong set Marek just needs to sign another key in the strong set with that key
and in turn have a strong set key sign 0x063938BA42CFA724. It'd make sense if
he also uses that key to sign the Qubes Master Signing Key, though the last two
steps might not be needed (I'm not 100% sure what exact definition is used for
the strong set). Regardless, the last two steps are cryptographically correct
as all those signatures are valid statements to make, so I don't see any reason
not to do them (modulo security concerns like those Andrew David Wong raised).

Of course, this is all a bit of a silly song and game, but we don't have a good
alternative right now for web-of-trust-based validation. :/

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Oh, wow! That raises some questions about the way the QMSK is handled.

> This is the reason we can initially import only the master signing
> key, trust it, and have all other valid Qubes signing keys trusted
> transitively. This is done for example here [1].
>
> [1]: https://github.com/QubesOS/qubes-builder/blob/3352cd4363a25debd77ced0a1fa752944ac1ef2f/scripts/verify-git-tag#L25
>

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJZGRDFAAoJENtN07w5UDAwB6AQAJciK2nVcGtbRtqv6JGUK46V
42y3xfUtSk45lP/ABtUdmwXWuDVTOfq8qFoK5AuBScmZEeihzbxum1lsyPNwghGz
zEM7oleroio23a+Jbfhv0JGWMFfQBQQ5Z+F19X0aT2UPq6c5WMHdWyPU2N5OSlAM
rrCYjc+WEmiOhKJSiMmns1zlC1R/mUejR/xzdAMaG9WxLm/hKPxtVtFcuKfUfFVe
xgHUOBh++n7OVism4/g9kCaoecYtEFZoz/r3AE75T0UOl4fe4U+KCvmRnXZzz6v2
eQWgpNbCAVEy+cMq/bfEQKrC1jbDxVpP3llIj42JRuRjdxv1i3ZKP2YaBMH/tXHG
Nsxzzd6lXdx0ODbsroV+iZohKGZqRJvSy+L7NOCuTCgL/1xB/FcnLBynncw4CQlG
rTPgd1tankyHenhPmoQuZuqOjvZx4aWIHqRRrsPIJjPvIidgknBpahjedzx8spmN
PSW52INkuesSCZGd5T3Y2AZVTr5o82XfdIKLeKKhwnBf5rPW9TjyKhDVl15sPniJ
AwOVvWWpPwdxKthZfNT5P6zK5lgofuqC5BiZAmDbI6TO+Wh7Ja06/uhyNLg5p7Cr
o4rtDoBKDQfEBIEJCQbm/t9ZAmf25Gher3DLB4U56sIjZEgn3yow6BdhliTEgyzu
FRBnrHuxtYkHSr6pxSdt
=XrqU
-----END PGP SIGNATURE-----

[Peter Todd]

On Sun, May 14, 2017 at 02:11:30PM -0500, Andrew David Wong wrote:
> > Unfortunately the tools to actually find these paths all kinda suck, but they
> > do at least the paths exist. The one I used to find the above is
> > https://pgp.cs.uu.nl/, however it has the significant limitation that it only
> > works for keys in the "strong set" - the Qubes signing key is *not* in that set
> > because it has never signed another key that is in that set.
> >
> > IMO the Qubes project should fix this.
> >
>
> It's unclear to me whether there's any practical way to perform such a
> signing without exposing the QMSK to unacceptable risk. Joanna wrote [1]
> that the QMSK was generated on an airgapped machine and that the private
> key has never left that machine (and hopefully never will). I infer from
> context that this refers to a physically (as opposed to virtually)
> airgapped machine. Since the QMSK was generated there (and, presumably,
> Release Signing Keys (RSKs) are also generated there), this entails that
> some GPG-like program (probably GPG itself) is installed in whatever OS
> is running on that machine. Let's refer to this as QMSK's "environment."

Ah, that's quite a restrictive set of security concerns. Good point!

> Clearly, both the QMSK and RSK public keys get transferred off of the
> airgapped machine somehow, since we have copies of them. I assume that
> such transfers are only one-way and are tightly controlled. That is,
> only public keys are allowed to leave the QMSK's environment, and
> nothing is allowed to enter. In particular, it's safe to assume that
> there is no networking (or else it wouldn't be an air gap) and that no
> freely rewritable USB drives (i.e., drives without write-protect
> switches) are plugged into that machine. (This is inferred from the fact
> that Joanna was warning the world about the dangers of plugging USB
> devices into machines years before BadUSB.) This suggests that some kind
> of read-only medium is used to enforce the one-way transfers.

Note that other mechanisms exist to get data out of such an environment safely,
assuming that the environment itself is uncompromised(i):

1) CD/DVD writers
2) Serial ports w/ RX pins removed (also possible with ethernet)
3) Taking a photo of the screen (hopefully with OCR rather than by hand!)


i) Note how this assumption is less stringent than the requirements for the
Zcash trusted setup that I participated in, as in that case we wanted to be
able to create an audit log of all data that left the trusted setup computer;
we may have failed at that goal as DVD-R's are not strictly read-only once
written.

> If all this is correct, then the only way for the QMSK to sign another
> key is to:
>
> (1) Generate the key in the QMSK's environment;
> (2) Transfer the key to the QMSK's environment.

While Jean-Philippe Ouellet noticed that the QMSK *has* signed other keys, even
if it hadn't you've nearly hit on the solution. Basically do:

1) Generate binding key pair in QMSK's environment
2) Sign QMSK with binding key
3) Sign binding key with QMSK
4) Transfer binding *keypair* out of QMSK's environemnt to secondary environment
5) Transfer strong-set pubkey into secondary environment
6) Sign that key with binding key
7) Transfer binding pubkey and signature on strong-set key to keyservers
8) Sign binding pubkey with a strong-set key

> (1) is the method used to create RSKs, but it's not clear whether this
> would help with getting the QMSK into the strong set. Would it be
> sufficient for the QMSK to generate a key that subsequently enters the
> strong set? Even so, this would introduce new complications to the Qubes
> PGP trust model. For example, should the strong set key generated by the
> QMSK be considered just as trustworthy as the QMSK itself? Should it be
> used to verify RSKs and Qubes ISOs? If not, can such accidental misuse
> be prevented, and if so, by what means should that be enforced?

It doesn't have to be as trustworthy as the QMSK: can and should verify
multiple web-of-trust paths. GnuPG's default settings are to expect to see
three separate paths, and you can easily tell it to consider the binding key as
non-trustworthy when calculating those paths (with the command `gpg --update-trustdb`)

Remember that the binding key idea I outline above - which again I think we've
nearly accomplished anyway with Marek's Qubes OS signing key - is just a hack
to get PGP web-of-trust path finders to see the QMSK as part of the PGP strong
set. Once that's done it'll be much easier to find paths to the QMSK with tools
like https://pgp.cs.uu.nl, but you'd still be verifying paths distinct from
this binding key hack. Equally, the alternatives people use right now are
probably often much more risky in practice than the above. :/

Finally, we also might manage to get the maintainers of https://pgp.cs.uu.nl
and similar tools to manually add the QMSK (and similar keys) to their
pathfinder databases!

> (2), meanwhile, requires transferring the key to the QMSK's environment
> via:

<snip>

We're in agreement that's a less-than-wise idea. :)

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Great points. Thanks! I think your setup would have been preferable,
since I'm pretty sure Marek's key was generated on a different machine
(in which case some kind of riskier transfer must have occurred, but
perhaps special precautions were taken).

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJZGRY2AAoJENtN07w5UDAw70cQAMe+9BoYiaWe6c0V2QIIvPZf
tbKP4jIKpDvJf5uO01QKSSH+FwMmuvZNYeRin0zJg8u9GS1sg6p5Rosj7zgXO86P
XwuxZ1PvqdStWEgk9AfsAPeU/4SXraCNloE0KPUDoWtapnrn7PDD7NyWop3/vxvY
VqoGa2x0LQ4Ue8DCc18ttEgrLxMWkeNZ8h2iB4nf7sCg40RZUgArzYOEUtztokJg
//GT3hlZjjx8GgHPOXgNkfR95TYaVwrP/ZqMYxsui8pZ8BxwBkh6DSm449KCYCkz
l262Scw6iKUXuFHRxELNj84/c2d5CyUGnN7BAt0AXJYm+k8rGl1/KH9FNpGxVDEf
EP6aBSyLFfK25iMZ8jICwOFK3++xfD1I+7w1+fkepTvZScchmAg0wMjg0cHVEMiB
NJaAkXxjalur1oexBG2NcTZoLVzO9yoFcVQX6rEmmv2Y+DZVj6opX/RMDabTUcgz
1545UHYL8h8kmOut4BJml1ZVbJbFRc6S98gwY2kmaoru6K4t4U/LSZVKh80+/atW
XiIngh0t5zwHN6G1I142mXFuUM6Qta4PmrBxn0oFXlg5EbzRnVfdvVjzKNtt1rvf
AeMeAszY56mDtLt8seXChh8qn8avDqIDm55bYGDPk5+QKBG4rIyhG204Xuv15AgW
+KrtRrHxUY0XTpGixElu
=TJWs
-----END PGP SIGNATURE-----

[Peter Todd]

On Sun, May 14, 2017 at 09:45:13PM -0500, Andrew David Wong wrote:
> >> (2), meanwhile, requires transferring the key to the QMSK's environment
> >> via:
> >
> > <snip>
> >
> > We're in agreement that's a less-than-wise idea. :)
> >
>
> Great points. Thanks! I think your setup would have been preferable,
> since I'm pretty sure Marek's key was generated on a different machine
> (in which case some kind of riskier transfer must have occurred, but
> perhaps special precautions were taken).

However, if that was done, is it really Marek's key?

I'd want to think carefully about putting my name on such a key if I hadn't
generated it on my machine. OTOH, Marek doesn't appear to have actually signed
that key with any other key, so maybe he and I agree on this point. :)

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I'm not saying that it would have been preferable for *Marek's* key to
have been generated in the QMSK environment. Rather, I'm saying that
it would have been preferable for a Strong Set Signing Key (SSSK) to
have been generated in the QMSK environment and used to get the QMSK
into the Strong Set, as you proposed, *instead of* Marek's key ever
having been signed by the QMSK. (But again, I don't know what special
precautions might have been taken in that case. Maybe it's fine.)

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJZGR17AAoJENtN07w5UDAwWFIQAKdiVVMR8634Db01+KcZLuGv
xUeyf6yU25vGpLKdgRA2VirU0in/X/6pPsQmw5CxUgS8ANTiaC1kb+iimjhlDVfG
BizlzioybHLx+VMl6mftw/dSVGjiUnZsgaP75wJYtF/05uxOzV1KrFpiaKVc0HSg
4Ay3ZcrJCAGMHlK1m9WM1GMvybG2Os5B++xxMj7vnkFqX58zThrinRrGG+w3xnMh
rzh271rekRDq2kg4KYgUJwrtpFyQT6RZkT0T0tPCosoFIUuPpkq3+0FaWRlLgd15
Ev/8la88IfQSjaCb8Qpgpt8hN6SMkB0rwVHAuH4EJwksc/ZWTh5uyCwBVRrKHpze
r6Ie2jIIDTVHxXXrUf63vXYJ8nHhb2jSTSLSkPT+V1l47Hb2a+hroZfoNxI+TrtI
F7sJUxYweySWrOYYvedo1T6coMOTdSt/qzHsRiOhKDPgX4HrDD2T3EN04k0NsdL4
59ROe3jZGGc50hzi55hhpt4KJBladoQ8ZUwMSSKXCV1UL3RBnC6LKKoZ5wtaBIx6
fgSOGDbSHqdZW347sX7BlZnX596lV5QT19EnjmbmPPacxNXT1hLpa/A7sObJtCF0
W+eefrbpiLjRIrwIv9Dn8eKcErsjm/+Z6yh1GpBT8mXuQyBQsQpa8Wi/1hRDhykx
1SqJU4PlCej9nNBeu1YV
=y59E
-----END PGP SIGNATURE-----

[Matteo]

> I didn't have the masterkey at hand. My solution has been to ask a few
> people I know with different ISPs to check out the webpage with it, but
> it is hosted by GitHub.
>
> How, for trust initialization, am I to know 427F 11FD 0FAA 4B08 0123
> F01C DDFA 1A3E 3687 9494 is actually Qubes master key and not GitHub's
> MitM signing key?

That's a common problem

here you can find the fingerprint:
https://github.com/rootkovska/rootkovska.github.io/tree/master/keys
https://keys.qubes-os.org/keys/
https://www.youtube.com/watch?v=S0TVw7U3MkE (near the end 46:51)
https://hyperelliptic.org/PSC/slides/psc2015_qubesos.pdf (last slide)
https://twitter.com/rootkovska/status/496976187491876864

-every site is in https
-one is even a video

as you can see it's not only on github :)
i omitted not https versions and keyservers
if someone knows more let me/us know!

bye
Matteo

[Joanna Rutkowska]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sun, May 14, 2017 at 10:16:13PM -0500, Andrew David Wong wrote:
> On 2017-05-14 21:52, Peter Todd wrote:
> > On Sun, May 14, 2017 at 09:45:13PM -0500, Andrew David Wong wrote:
> >>>> (2), meanwhile, requires transferring the key to the QMSK's
> >>>> environment via:
> >>>
> >>> <snip>
> >>>
> >>> We're in agreement that's a less-than-wise idea. :)
> >>>
> >>
> >> Great points. Thanks! I think your setup would have been
> >> preferable, since I'm pretty sure Marek's key was generated on a
> >> different machine (in which case some kind of riskier transfer
> >> must have occurred, but perhaps special precautions were taken).
> >
> > However, if that was done, is it really Marek's key?
> >
> > I'd want to think carefully about putting my name on such a key if
> > I hadn't generated it on my machine. OTOH, Marek doesn't appear to
> > have actually signed that key with any other key, so maybe he and I
> > agree on this point. :)
> >
>
> I'm not saying that it would have been preferable for *Marek's* key to
> have been generated in the QMSK environment. Rather, I'm saying that
> it would have been preferable for a Strong Set Signing Key (SSSK) to
> have been generated in the QMSK environment and used to get the QMSK
> into the Strong Set, as you proposed, *instead of* Marek's key ever
> having been signed by the QMSK. (But again, I don't know what special
> precautions might have been taken in that case. Maybe it's fine.)
>

Hi, thanks for the interesting discussion and many good points. This has
inspired me to create this ticket:

https://github.com/QubesOS/qubes-issues/issues/2818

Let's discuss there.

Thanks,
joanna.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJZHu+MAAoJEDOT2L8N3GcYGxkP/A6xPFKnAI8tOao+P7B7wmGl
Ua5eaQP3Ps7SJGmlQu+oNkrIcOL5MHPkU1UqjBP+sgRAoBbeXhBuoZ/xXKRTYKdk
kjo4TKY9atvUVzV8mymIk7NyTHqhktlRf9GdHKbQ+0equp4/pmmf5fVTEmxZFoVT
x8rFxIdxsQDgjtWoKyCndnbDPlNfdzsLBj6/QhrBjlt86zREr4aZ7/D6KRrVUggK
4GuhT6tMMRVXL6LvF7mbw5cz0aLiVLODvhY0YFzUInEXIvp7UGlKpcPjsFJtPlFu
RHIXdNiiJHZCr1qgV2IjEpAVK/p+AxqJVu7X7Jt38fjvEcrkVPWvGcyafq59UpZp
+DuKGQjFufQoB36F8q0fl8rqfaR0bG9WoNzh6tE23k4T0cZzy1UpCOb7fz1XYWuj
csKAxkS1FvljT6v/7D1LoFo7mrPJaOruqZNRn5Yd6nc/OHJAM23r/O2fhFKNPR2O
CSpeiqPCwzGcoca+x7ptPv4j0Bp27Gt9WsR/HqcTb2p6PVkKpZw0gC0P85tQ2H2K
aPZFwajCDQa4PUY+hNzbMg9UW7gMPYOxL2INd6y1i9dt3K/IRIg8ou8FqMIk4vC3
IhyR8OcRwsXmki43oKVIbHZ6cFCo/MYs8xWjTs+x/bFKWxYlDBqzDePdoddOyuAT
FjRmp2HS7bRiXtRPO+Jg
=uVuG
-----END PGP SIGNATURE-----

[Frank]

Not if those keys were generated and signed in the QMSK-Environment before they were transferred to their owners, right?

>
>> This is the reason we can initially import only the master signing
>> key, trust it, and have all other valid Qubes signing keys trusted
>> transitively. This is done for example here [1].
>>
>> [1]: https://github.com/QubesOS/qubes-builder/blob/3352cd4363a25debd77ced0a1fa752944ac1ef2f/scripts/verify-git-tag#L25
>>
>
> - --
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBCgAGBQJZGRDFAAoJENtN07w5UDAwB6AQAJciK2nVcGtbRtqv6JGUK46V
> 42y3xfUtSk45lP/ABtUdmwXWuDVTOfq8qFoK5AuBScmZEeihzbxum1lsyPNwghGz
> zEM7oleroio23a+Jbfhv0JGWMFfQBQQ5Z+F19X0aT2UPq6c5WMHdWyPU2N5OSlAM
> rrCYjc+WEmiOhKJSiMmns1zlC1R/mUejR/xzdAMaG9WxLm/hKPxtVtFcuKfUfFVe
> xgHUOBh++n7OVism4/g9kCaoecYtEFZoz/r3AE75T0UOl4fe4U+KCvmRnXZzz6v2
> eQWgpNbCAVEy+cMq/bfEQKrC1jbDxVpP3llIj42JRuRjdxv1i3ZKP2YaBMH/tXHG
> Nsxzzd6lXdx0ODbsroV+iZohKGZqRJvSy+L7NOCuTCgL/1xB/FcnLBynncw4CQlG
> rTPgd1tankyHenhPmoQuZuqOjvZx4aWIHqRRrsPIJjPvIidgknBpahjedzx8spmN
> PSW52INkuesSCZGd5T3Y2AZVTr5o82XfdIKLeKKhwnBf5rPW9TjyKhDVl15sPniJ
> AwOVvWWpPwdxKthZfNT5P6zK5lgofuqC5BiZAmDbI6TO+Wh7Ja06/uhyNLg5p7Cr
> o4rtDoBKDQfEBIEJCQbm/t9ZAmf25Gher3DLB4U56sIjZEgn3yow6BdhliTEgyzu
> FRBnrHuxtYkHSr6pxSdt
> =XrqU
> -----END PGP SIGNATURE-----
>

> --
> You received this message because you are subscribed to the Google Groups "qubes-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel...@googlegroups.com.
> To post to this group, send email to qubes...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/357f5e92-5e60-ab8c-5426-38dc4b0e3b06%40qubes-os.org.
> For more options, visit https://groups.google.com/d/optout.

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2017-05-20 03:02, Frank wrote:
>> Oh, wow! That raises some questions about the way the QMSK is
>> handled.
> Not if those keys were generated and signed in the QMSK-Environment
> before they were transferred to their owners, right?
>

As I wrote above, I'm pretty sure that's not the case with respect to
Marek's key.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJZINUjAAoJENtN07w5UDAwUJAP/30qsHvfmsbKOhlKMPZCTMU3
3MjRViqbMDENGxdDiHnkNXLsZeR2d4g2TT5YEDtg4FX2IbHtbFydc+vNDwa3A1BB
yXjhPU3PClQgucrM9jN0wkl4NU+QHDUfJRQEpzGhPODO84ATbG4DYjUfY46+ibNU
lXW96HebPm9Tywk4Ntv2G1IqIaTpnxzBqm4XIZbOg5PE2DG4rEJ0oUMH/KDzHpeR
I6t7AMIwd7eviIzRmcbVtWk32TMXum+sldil61xAqRGZmfBDC39jVmgumAoMUjNy
KwX/Ih7ivUcFk/nfSJiUXbMZaqF5l72YjR4+MRO532BIvbUFokGENQrslw+lNtDe
91i4JpsfDS7l9MvbICtKHxcqwW96MkrMcbhxXT8mVyl4/7LpG46zyg4dgOHpJF11
FXp/ryPjaJST1MFS3q3opngN7UJYKAY8KcSWXCetKWhgo9gSmjrHf/6kBPJmzMZC
1cW2AAsBC9YT4Fb2HKSOEois6o6/si71nnAxKHqT83q7/D3Q3nIoWwVZfqm/wbL/
URRHYnIA9GFn9t9BCYShth6fiDDqYckGysk8Co2R4a88fV0vkR3wjARo2CR/8bHt
AnlKj63gVcl7MyhmvpJE8uB5hJCJwa/MImgmzRAmO3/MpOfOevexXKVKxukgpHRs
fPQiqpWwjZQF3f/xvoX5
=LtKv
-----END PGP SIGNATURE-----