mirror of
https://github.com/QubesOS/qubes-doc.git
synced 2024-12-25 07:19:33 -05:00
Improve qubes-secpack page
- Swap section order - Normalize heading capitalization and syntax - Add redirect
This commit is contained in:
Andrew David Wong
parent
6043c6e51d
commit
c6beef25f5
@ -5,6 +5,7 @@ permalink: /security/pack/
|
||||
redirect_from:
|
||||
- /doc/security-pack/
|
||||
- /en/doc/security-pack/
|
||||
- /security-pack/
|
||||
- /doc/SecurityPack/
|
||||
- /wiki/SecurityPack/
|
||||
- /qsp/
|
||||
@ -33,105 +34,8 @@ official location is:
|
||||
|
||||
<https://github.com/QubesOS/qubes-secpack>
|
||||
|
||||
History and Rationale
|
||||
---------------------
|
||||
|
||||
On 2013-01-05, Joanna Rutkowska announced the `qubes-secpack` and explained its
|
||||
rationale in an
|
||||
[email](https://groups.google.com/d/msg/qubes-devel/twkOEaMLtNI/lZyGx6_jFCEJ)
|
||||
to the Qubes mailing lists:
|
||||
|
||||
```
|
||||
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.
|
||||
|
||||
```
|
||||
|
||||
How to Obtain, Verify, and Read
|
||||
-------------------------------
|
||||
## How to obtain, verify, and read
|
||||
|
||||
The following example demonstrates one method of obtaining the `qubes-secpack`,
|
||||
verifying its contents, and reading them.
|
||||
@ -271,3 +175,101 @@ The same procedures can be applied to any directory or file in the
|
||||
signatures) are provided to ensure that the system is robust (e.g., against a
|
||||
potential failure in Git tag-based verification) and to give users more options
|
||||
to verify the files.
|
||||
|
||||
|
||||
## History and rationale
|
||||
|
||||
On 2013-01-05, Joanna Rutkowska announced the `qubes-secpack` and explained its
|
||||
rationale in an
|
||||
[email](https://groups.google.com/d/msg/qubes-devel/twkOEaMLtNI/lZyGx6_jFCEJ)
|
||||
to the Qubes mailing lists:
|
||||
|
||||
```
|
||||
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.
|
||||
|
||||
```
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user