Rewrote SecurityPack in Markdown.

This commit is contained in:
Axon 2015-06-05 03:19:01 +00:00
parent 32288f9eb9
commit 7b31877f17
No known key found for this signature in database
GPG Key ID: 8CE137352A019A17

View File

@ -8,126 +8,122 @@ redirect_from: /wiki/SecurityPack/
Qubes Security Pack
===================
1. [Qubes Security Pack](#QubesSecurityPack)
1. [Introduction](#Introduction)
2. [History and Rationale](#HistoryandRationale)
3. [How to Obtain, Verify, and Read](#HowtoObtainVerifyandRead)
Introduction
------------
The **Qubes Security Pack (QSP)** is a Git repository which contains:
- [All Qubes Security Bulletins (QSBs)](/doc/SecurityBulletins/)
- [All PGP keys](https://keys.qubes-os.org/keys/)
- [Warrant canaries](https://en.wikipedia.org/wiki/Warrant_canary)
- Other security-related information and announcements (such as key revocations)
* [Qubes Security Bulletins (QSBs)](/doc/SecurityBulletins/)
* [Qubes PGP keys](https://keys.qubes-os.org/keys/)
* [Qubes warrant canaries](https://canarywatch.org/qubesOS/)
* Security-related information and announcements (e.g., key revocations)
The QSP is located here:
The official location of the QSP is:
`https://github.com/QubesOS/qubes-secpack`
[(link)](https://github.com/QubesOS/qubes-secpack)
> [https://github.com/QubesOS/qubes-secpack](https://github.com/QubesOS/qubes-secpack)
History and Rationale
---------------------
On 2013-01-05, Joanna Rutkowska announced the QSP and explained its rationale in an [email](https://groups.google.com/d/msg/qubes-devel/twkOEaMLtNI/lZyGx6_jFCEJ) to the Qubes mailing lists:
On 2013-01-05, Joanna Rutkowska announced the QSP and explained its rationale in
an [email](https://groups.google.com/d/msg/qubes-devel/twkOEaMLtNI/lZyGx6_jFCEJ)
to the Qubes mailing lists:
{% highlight trac-wiki %}
Hello,
Hello,
A new Qubes Security Bulletin has been just released and is available here:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-013-2015.txt
As per the previous discussions about recent problems with verifying
digital signatures on messages sent to Google Groups (thanks to
automatic footer addition by Google), we have decided to change the way
we publish Qubes Security Bulletins, as well as other security-related
info pertinent to the Qubes Project.
Starting today, we will be maintain a Git repository -- "Qubes Security
Pack" -- which will contain all the QSBs released so far, all the keys,
warrant canaries [1], and potentially some additional info or
announcements (e.g. key revocations). The whole repo can be found here:
https://github.com/QubesOS/qubes-secpack
Note that all the keys distributed there should be signed by Qubes
Master Key. The Master Key is also attached in the repo, but should
really be obtained/verified using a different channel.
Additionally, most of the files are signed by core Qubes
developers (currently by Marek and myself) via detached signatures as
well as git tag signatures.
The are several advantages of using Git to distribute all these information:
1) Git repo is a collection of files, some of which can be detached GPG
signatures for other files and we can ensure all these files are
distributed together.
2) Git makes it easy for people to clone and redistribute these
collection of files, as well as to easily host them and view on the Web.
3) Git provides for signed tags mechanisms which is another mean we
utilize to ensure integrity of the distributed files.
A few words about the Warrant Canary which we've just introduced today,
and which can be seen here:
https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-001-2015.txt
Even though we're not providing any kind of services (such as e.g. email
hosting), that could be searched or tapped by authorities, there are
other possibilities that worry us [2], in the light of various recent
law "developments", such as those that might be coercing people to hand
over their private keys to authorities.
Until we fully decentralize the root of trust for Qubes, something that
requires the move to deterministic builds [3], and so won't happen
very soon, the possibility of having to disclose any of the Qubes
signing keys to anybody might have pretty serious consequences for those
who decided to entrust Qubes with anything serious. And we would like to
somehow minimize these consequences with this canary thing.
Additionally the canary is a nice way of ensuring "freshness" of our
messaging to the community.
Of course the canary doesn't solve all the problems. E.g. if my signing
keys were somehow stolen without our knowledge, it wouldn't help.
Neither it could help in case me being or becoming a miscreant. And
probably it doesn't address many other potential problems, which could
only be solved one day with a multi-signature scheme. But anyway, until
that time, this is the best we can do, I think.
And congrats to Jann for the very interesting clipboard attack (even
though mostly theoretical, still very cool)!
Thanks,
joanna.
--
The Qubes Security Team
https://www.qubes-os.org/doc/SecurityPage
[1] http://en.wikipedia.org/wiki/Warrant_canary
[2] Especially myself, because I'm currently the Root Of Trust for all
Qubes binaries :/
[3] Deterministic builds are required because it's the only way we can
implement multiple signature scheme for distributed binaries.
A new Qubes Security Bulletin has been just released and is available here:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-013-2015.txt
As per the previous discussions about recent problems with verifying
digital signatures on messages sent to Google Groups (thanks to
automatic footer addition by Google), we have decided to change the way
we publish Qubes Security Bulletins, as well as other security-related
info pertinent to the Qubes Project.
Starting today, we will be maintain a Git repository -- "Qubes Security
Pack" -- which will contain all the QSBs released so far, all the keys,
warrant canaries [1], and potentially some additional info or
announcements (e.g. key revocations). The whole repo can be found here:
https://github.com/QubesOS/qubes-secpack
Note that all the keys distributed there should be signed by Qubes
Master Key. The Master Key is also attached in the repo, but should
really be obtained/verified using a different channel.
Additionally, most of the files are signed by core Qubes
developers (currently by Marek and myself) via detached signatures as
well as git tag signatures.
The are several advantages of using Git to distribute all these information:
1) Git repo is a collection of files, some of which can be detached GPG
signatures for other files and we can ensure all these files are
distributed together.
2) Git makes it easy for people to clone and redistribute these
collection of files, as well as to easily host them and view on the Web.
3) Git provides for signed tags mechanisms which is another mean we
utilize to ensure integrity of the distributed files.
A few words about the Warrant Canary which we've just introduced today,
and which can be seen here:
https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-001-2015.txt
Even though we're not providing any kind of services (such as e.g. email
hosting), that could be searched or tapped by authorities, there are
other possibilities that worry us [2], in the light of various recent
law "developments", such as those that might be coercing people to hand
over their private keys to authorities.
Until we fully decentralize the root of trust for Qubes, something that
requires the move to deterministic builds [3], and so won't happen
very soon, the possibility of having to disclose any of the Qubes
signing keys to anybody might have pretty serious consequences for those
who decided to entrust Qubes with anything serious. And we would like to
somehow minimize these consequences with this canary thing.
Additionally the canary is a nice way of ensuring "freshness" of our
messaging to the community.
Of course the canary doesn't solve all the problems. E.g. if my signing
keys were somehow stolen without our knowledge, it wouldn't help.
Neither it could help in case me being or becoming a miscreant. And
probably it doesn't address many other potential problems, which could
only be solved one day with a multi-signature scheme. But anyway, until
that time, this is the best we can do, I think.
And congrats to Jann for the very interesting clipboard attack (even
though mostly theoretical, still very cool)!
Thanks,
joanna.
--
The Qubes Security Team
https://www.qubes-os.org/doc/SecurityPage
[1] http://en.wikipedia.org/wiki/Warrant_canary
[2] Especially myself, because I'm currently the Root Of Trust for all
Qubes binaries :/
[3] Deterministic builds are required because it's the only way we can
implement multiple signature scheme for distributed binaries.
{% endhighlight %}
How to Obtain, Verify, and Read
-------------------------------
The following example demonstrates one method of obtaining the QSP, verifying its contents, and reading them.
The following example demonstrates one method of obtaining the QSP, verifying
its contents, and reading them.
1. Clone the QSP repo.
1. Clone the QSP repo.
{% highlight trac-wiki %}
```
[user@qubes ~]$ git clone https://github.com/QubesOS/qubes-secpack.git
Cloning into 'qubes-secpack'...
remote: Counting objects: 195, done.
@ -135,11 +131,11 @@ The following example demonstrates one method of obtaining the QSP, verifying it
Receiving objects: 100% (195/195), 130.94 KiB | 207.00 KiB/s, done.
Resolving deltas: 100% (47/47), done.
Checking connectivity... done.
{% endhighlight %}
```
2. Import the included PGP keys.
2. Import the included PGP keys.
{% highlight trac-wiki %}
```
[user@qubes ~]$ gpg --import qubes-secpack/keys/*/*
gpg: directory `/home/user/.gnupg' created
gpg: new configuration file `/home/user/.gnupg/gpg.conf' created
@ -167,11 +163,11 @@ The following example demonstrates one method of obtaining the QSP, verifying it
gpg: Total number processed: 17
gpg: imported: 17 (RSA: 17)
gpg: no ultimately trusted keys found
{% endhighlight %}
```
3. Verify and trust the Qubes Master Signing Key.
{% highlight trac-wiki %}
```
[user@qubes ~]$ gpg --edit-key 36879494
gpg (GnuPG) 1.4.18; Copyright (C) 2014 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
@ -211,15 +207,20 @@ The following example demonstrates one method of obtaining the QSP, verifying it
unless you restart the program.
gpg> q
{% endhighlight %}
```
> **Important!**
**Important!**
> In order to verify the authenticity of the Qubes Master Signing Key prior to trusting it, you should obtain the Qubes Master Signing Key fingerprint from a trustworthy source (ideally, multiple sources) *other than* this website and visually compare it (them) to the fingerprint displayed in the preceding step, ensuring they match. You can read more about digital signatures and key verification [here](/doc/VerifyingSignatures/).
In order to verify the authenticity of the Qubes Master Signing Key prior to
trusting it, you should obtain the Qubes Master Signing Key fingerprint from
a trustworthy source (ideally, multiple sources) *other than* this website
and visually compare it (them) to the fingerprint displayed in the preceding
step, ensuring they match. You can read more about digital signatures and
key verification [here](/doc/VerifyingSignatures/).
1. Verify and read the canaries.
4. Verify and read the canaries.
{% highlight trac-wiki %}
```
[user@qubes ~]$ cd qubes-secpack/canaries/
[user@qubes canaries]$ gpg --verify canary-001-2015.txt.sig.joanna canary-001-2015.txt
gpg: Signature made Mon Jan 5 20:21:40 2015 UTC using RSA key ID 92C7B3DC
@ -233,11 +234,11 @@ The following example demonstrates one method of obtaining the QSP, verifying it
---===[ Qubes Canary #1 ]===---
[...]
{% endhighlight %}
```
2. Verify and read the QSBs.
5. Verify and read the QSBs.
{% highlight trac-wiki %}
```
[user@qubes canaries]$ cd ../QSBs/
[user@qubes QSBs]$ gpg --verify qsb-013-2015.txt.sig.joanna qsb-013-2015.txt
gpg: Signature made Mon Jan 5 21:22:14 2015 UTC using RSA key ID 92C7B3DC
@ -251,6 +252,4 @@ The following example demonstrates one method of obtaining the QSP, verifying it
---===[ Qubes Security Bulletin #13 ]===---
[...]
{% endhighlight %}
```