Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upManaging documentation repos from qubes-builder #2705
Comments
andrewdavidwong
added
C: doc
C: website
enhancement
labels
Mar 15, 2017
andrewdavidwong
added this to the
Documentation/website milestone
Mar 15, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
jpouellet
Mar 15, 2017
Contributor
To implement this cleanly requires the following changes:
- a way to use a different set of keys for verifying docs changes (separate from developer keys)
- changing qubes-builder/scripts/verify-git-tag to import keyring according to env var instead of hard-coded qubes-developers-keys.asc
- addition of qubes-documenters-keys.asc (or similar) keyring to qubes-builder containing qubes-secpack/keys/doc-signing/* keys
- creation of "Qubes Master Documentation Signing Key" signing the above keys to have a clean single point to root trust at (like is done currently for master key signing developer keys), or alternately just sign doc signing keys with existing master signing key
- changing qubes-builder/scripts/verify-git-tag to allow specifying a key to ultimately trust (if we use a separate master doc signing key as described above)
- creating another builder.conf with something like:
# vim: ft=make ts=4 sw=4 # Tracking the Qubes documentation repos GIT_BASEURL ?= https://github.com GIT_PREFIX ?= QubesOS/ KEYRING_DIR_GIT = $(BUILDER_DIR)/keyrings/docs SRC_DIR = qubes-doc COMPONENTS = \ qubesos.github.io \ qubes-attachment \ qubes-posts \ qubes-doc \ qubes-hcl about:: @echo "qubes-docs.conf"
Thoughts? @rootkovska particularly thoughts on signing the docs keys from the master key and/or creating a master docs signing key?
jpouellet
commented
Mar 15, 2017
•
edited
Edited 1 time
-
jpouellet
edited Mar 15, 2017 (most recent)
edited
-
Mar 15, 2017 (most recent)
|
To implement this cleanly requires the following changes:
Thoughts? @rootkovska particularly thoughts on signing the docs keys from the master key and/or creating a master docs signing key? |
jpouellet
changed the title from
qubes-builder-style repo updating for qubes docs
to
Managing documentation repos from qubes-builder
Mar 15, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
jpouellet
Mar 15, 2017
Contributor
Also, to maintain the ability to jekyll serve this would either require either replacing the qubesos.github.io submodules with symlinks to e.g. ../qubes-doc, or providing a way to specify per-component SRC_DIR to retain nested repo heirarchy. I think I prefer the former for simplicity.
|
Also, to maintain the ability to |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
jpouellet
Mar 15, 2017
Contributor
Allowing this to be integrated into the same builder.conf as the normal src would probably require renaming qubesos.github.io to qubes-website or something because otherwise we can't use GIT_PREFIX=QubesOS/qubes-. Some thought is also required for how handle different SRC_DIR (if we want to) and separate KEYRING_GIT_DIR (which we would need to do to prevent docs signing keys from being valid when verifying src components). Perhaps it's best to just require separate builder.confs.
Requiring separate builder.confs for src vs. docs is really a non-issue for me since I have separate VMs for src and docs (with access to different respective split-gpg VMs for src vs docs signing keys). We may want to recommend this practice anyway since my docs repo has a larger attack surface (runs a browser for local testing, and has network access because building docs offline is currently broken) whereas my src VM is more locked down.
jpouellet
commented
Mar 15, 2017
•
edited
Edited 1 time
-
jpouellet
edited
Mar 15, 2017 (most recent)
edited
-
Mar 15, 2017 (most recent)
|
Allowing this to be integrated into the same builder.conf as the normal src would probably require renaming qubesos.github.io to qubes-website or something because otherwise we can't use Requiring separate builder.confs for src vs. docs is really a non-issue for me since I have separate VMs for src and docs (with access to different respective split-gpg VMs for src vs docs signing keys). We may want to recommend this practice anyway since my docs repo has a larger attack surface (runs a browser for local testing, and has network access because building docs offline is currently broken) whereas my src VM is more locked down. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
jpouellet
Mar 15, 2017
Contributor
Although perhaps the disjoint signing key sets issue will need to be resolved for qubes-contrib components anyway and we can revisit merging builder.confs after.
|
Although perhaps the disjoint signing key sets issue will need to be resolved for qubes-contrib components anyway and we can revisit merging builder.confs after. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Mar 16, 2017
Member
creation of "Qubes Master Documentation Signing Key" signing the above keys to have a clean single point to root trust at (like is done currently for master key signing developer keys), or alternately just sign doc signing keys with existing master signing key
Definitely not signing doc keys with existing master key. In many places (either scripts or documentation) we assume that if something (code/iso image/package etc) is signed by a key signed by Qubes Master Key, then it's ok. And surely we don't want to allow (leaked/stolen etc) doc signing key to be used to produce valid code/release signature.
Allowing this to be integrated into the same builder.conf as the normal src would probably require renaming qubesos.github.io to qubes-website or something because otherwise we can't use GIT_PREFIX=QubesOS/qubes-.
Separete builder.conf (and the whole qubes-builder instance) is a good idea anyway, even if running in the same VM (which is not so good idea, as you already noticed).
Also, to maintain the ability to jekyll serve this would either require either replacing the qubesos.github.io submodules with symlinks to e.g. ../qubes-doc, or providing a way to specify per-component SRC_DIR to retain nested repo heirarchy. I think I prefer the former for simplicity.
Do you mean locally, or committed in repository? If the later, it's no-go, there must be submodules, because otherwise github pages would not download them.
Slightly unrelated: having option to specify trusted keys for a given component (regardless of being signed by the master key) would be useful anyway. Some time ago I'd say to have list of full key fingerprints, but now I'm not sure if that would be enough...
BTW I assume you've seen qubesos.github.io/_utils/update-submodules, right? It's hooked to push into any website related repository.
To be honest, I don't think this all isn't that useful, since most changes are in just one repository (qubes-doc) and standard git is (IMHO) good enough to handle it...
Definitely not signing doc keys with existing master key. In many places (either scripts or documentation) we assume that if something (code/iso image/package etc) is signed by a key signed by Qubes Master Key, then it's ok. And surely we don't want to allow (leaked/stolen etc) doc signing key to be used to produce valid code/release signature.
Separete builder.conf (and the whole qubes-builder instance) is a good idea anyway, even if running in the same VM (which is not so good idea, as you already noticed).
Do you mean locally, or committed in repository? If the later, it's no-go, there must be submodules, because otherwise github pages would not download them. Slightly unrelated: having option to specify trusted keys for a given component (regardless of being signed by the master key) would be useful anyway. Some time ago I'd say to have list of full key fingerprints, but now I'm not sure if that would be enough... BTW I assume you've seen To be honest, I don't think this all isn't that useful, since most changes are in just one repository (qubes-doc) and standard git is (IMHO) good enough to handle it... |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
jpouellet
Mar 16, 2017
Contributor
Definitely not signing doc keys with existing master key. In many places (either scripts or documentation) we assume that if something (code/iso image/package etc) is signed by a key signed by Qubes Master Key, then it's ok. And surely we don't want to allow (leaked/stolen etc) doc signing key to be used to produce valid code/release signature.
ACK. I think doc-master would be a good idea still.
Do you mean locally, or committed in repository? If the later, it's no-go, there must be submodules, because otherwise github pages would not download them.
Hmm... I guess I know less about Qubes infra than I thought. I assumed by all the cloudflare arguments on the ML that we were no longer actually using github pages, but rather had another server rebuilding on its own, and that the qubesos.github.io name was a historical artifact.
BTW I assume you've seen qubesos.github.io/_utils/update-submodules, right? It's hooked to push into any website related repository.
sigh. Nope. That (fetching all submodules & verifying sigs) is why I looked into this in the first place. Closing now. Can track looking into per-component keys in separate issue.
ACK. I think doc-master would be a good idea still.
Hmm... I guess I know less about Qubes infra than I thought. I assumed by all the cloudflare arguments on the ML that we were no longer actually using github pages, but rather had another server rebuilding on its own, and that the qubesos.github.io name was a historical artifact.
sigh. Nope. That (fetching all submodules & verifying sigs) is why I looked into this in the first place. Closing now. Can track looking into per-component keys in separate issue. |
jpouellet
closed this
Mar 16, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
andrewdavidwong
Mar 16, 2017
Member
Hmm... I guess I know less about Qubes infra than I thought. I assumed by all the cloudflare arguments on the ML that we were no longer actually using github pages [...]
FWIW, these are two of the FAQ entries I added in response to the recurring Cloudflare arguments (note that they both state that we use GitHub Pages + Cloudflare):
https://www.qubes-os.org/doc/user-faq/#should-i-trust-this-website
https://www.qubes-os.org/doc/user-faq/#why-doesnt-this-website-have-security-feature-x
FWIW, these are two of the FAQ entries I added in response to the recurring Cloudflare arguments (note that they both state that we use GitHub Pages + Cloudflare): https://www.qubes-os.org/doc/user-faq/#should-i-trust-this-website |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
jpouellet
Mar 16, 2017
Contributor
And what about {deb,yum,ftp}.qubes-os.org?
$ dig yum.qubes-os.org
; <<>> DiG 9.10.4-P6-RedHat-9.10.4-3.P6.fc24 <<>> yum.qubes-os.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63556
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;yum.qubes-os.org. IN A
;; ANSWER SECTION:
yum.qubes-os.org. 7 IN CNAME focaccia.qubes-os.org.
focaccia.qubes-os.org. 7 IN A 82.94.215.165
;; Query time: 24 msec
;; SERVER: 10.137.2.1#53(10.137.2.1)
;; WHEN: Thu Mar 16 03:22:03 EDT 2017
;; MSG SIZE rcvd: 84
$ whois 82.94.215.165
[Querying whois.ripe.net]
[whois.ripe.net]
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf
% Note: this output has been filtered.
% To receive output for a database update, use the "-B" flag.
% Information related to '82.94.215.0 - 82.94.215.255'
% Abuse contact for '82.94.215.0 - 82.94.215.255' is 'abuse@xs4all.nl'
inetnum: 82.94.215.0 - 82.94.215.255
netname: geekheim-net
descr: Geekheim
country: NL
admin-c: EJ513-RIPE
tech-c: EJ513-RIPE
tech-c: XS42-RIPE
status: ASSIGNED PA
remarks: Please send email to "abuse@xs4all.nl" for complaints
remarks: regarding portscans, DoS attacks and spam.
mnt-by: XS4ALL-MNT
created: 2006-04-26T15:27:18Z
last-modified: 2006-04-26T15:27:18Z
source: RIPE # Filtered
role: XS4ALL Internet NOC
address: XS4ALL Internet BV
address: Postbus 1848
address: 1000BV Amsterdam
address: The Netherlands
phone: +31 20 3987654
fax-no: +31 20 3987604
abuse-mailbox: abuse@xs4all.nl
admin-c: CB127
admin-c: KAI11-RIPE
tech-c: CB127
tech-c: RZ2757-RIPE
tech-c: KAI11-RIPE
tech-c: MVS5
tech-c: TFR-RIPE
nic-hdl: XS42-RIPE
mnt-by: XS4ALL-MNT
created: 2002-01-30T10:14:53Z
last-modified: 2016-10-12T10:52:01Z
source: RIPE # Filtered
person: Elisa Jasinska
address: Javastraat 114 II
address: 1094 HN Amsterdam
address: The Netherlands
phone: +31 6 23234891
nic-hdl: EJ513-RIPE
mnt-by: ELA-MNT
created: 2006-04-26T15:27:18Z
last-modified: 2011-05-05T13:06:24Z
source: RIPE # Filtered
% Information related to '82.92.0.0/14AS3265'
route: 82.92.0.0/14
descr: XS4ALL networking
origin: AS3265
mnt-by: XS4ALL-MNT
created: 2003-11-25T11:51:48Z
last-modified: 2003-11-25T11:51:48Z
source: RIPE # Filtered
% This query was served by the RIPE Database Query Service version 1.88 (ANGUS)
Some ITL-owned server I presume?
|
And what about {deb,yum,ftp}.qubes-os.org? Some ITL-owned server I presume? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Mar 16, 2017
Member
And what about {deb,yum,ftp}.qubes-os.org?
Some ITL-owned server I presume?
Yes, something like this.
Yes, something like this. |
jpouellet commentedMar 15, 2017
It would be nice if we could use the same
make prepare-merge,make show-unmerged,make do-merge, workflow for properly verifying signatures and updating all components under qubesos.github.io repo.Other targets like
make check(check for any uncommited changes and unsigned tags) would be nice too.Maybe all this requires is a separate builder.conf with the docs components listed and a different keyring for the docs signing keys? But perhaps slightly more complicated (if you want to be able to jekyll serve locally) since the repos are expected to be subdirs of each other rather than separate dirs.
In any case, this would be nice to investigate and document.