summaryrefslogtreecommitdiffstats
path: root/cheatsheets/infrastructure
diff options
context:
space:
mode:
authorDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-28 09:19:41 +0000
committerDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-28 09:19:41 +0000
commita27c8b00ebf173659f22f53ce65679e94e7dfb1b (patch)
tree02c68ec259348b63c6328896aa73265eb7b3d730 /cheatsheets/infrastructure
parentInitial commit. (diff)
downloaddebian-keyring-a27c8b00ebf173659f22f53ce65679e94e7dfb1b.tar.xz
debian-keyring-a27c8b00ebf173659f22f53ce65679e94e7dfb1b.zip
Adding upstream version 2022.12.24.upstream/2022.12.24upstream
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'cheatsheets/infrastructure')
-rw-r--r--cheatsheets/infrastructure/adding-new-member.txt23
-rw-r--r--cheatsheets/infrastructure/git.txt111
-rw-r--r--cheatsheets/infrastructure/kaufmann.txt21
-rw-r--r--cheatsheets/infrastructure/ldap.txt53
-rw-r--r--cheatsheets/infrastructure/rt.txt74
5 files changed, 282 insertions, 0 deletions
diff --git a/cheatsheets/infrastructure/adding-new-member.txt b/cheatsheets/infrastructure/adding-new-member.txt
new file mode 100644
index 0000000..6b2c7ec
--- /dev/null
+++ b/cheatsheets/infrastructure/adding-new-member.txt
@@ -0,0 +1,23 @@
+When adding a new member to the keyring-maint team there are various
+steps which need to be performed.
+
+ * Signed email to DSA (admin@rt.debian.org, remember to add Debian RT
+ in the subject). This should include the name + Debian username of
+ the new team member and ask for the following:
+
+ * User addition to keyring group (which will allow access to
+ kaufmann)
+ * Addition to "Keyring Maintainers" LDAP object to enable editing of
+ fingerprint objects
+ * User account on rt.debian.org with access to the 2 keyring queues
+ * Addition to keyring-maint@debian.org email alias
+ * Import new member's Debian key into debian-trustedkeys.gpg
+ * Potential modification of dsa-misc/scripts/sync-keyring to include
+ new member's fingerprint
+
+ * Inform the NM Front Desk team with username, email address +
+ fingerprint details so keyring/git_ops.py and keyring/housekeeping.py
+ can be updated with the additional details
+
+ * Inform FTP master of the new member + fingerprint so they can be
+ added to DM-Admin / AdminFingerprints in dak.conf
diff --git a/cheatsheets/infrastructure/git.txt b/cheatsheets/infrastructure/git.txt
new file mode 100644
index 0000000..353957d
--- /dev/null
+++ b/cheatsheets/infrastructure/git.txt
@@ -0,0 +1,111 @@
+Git working tree
+----------------
+
+Keyring work is coordinated in the Git tree living in
+/srv/keyring.debian.org/master-keyring.git/ at keyring.debian.org
+(which is an alias to kaufmann.debian.org). You need to have an
+account on kaufmann to get access to the working tree. The URL for the
+Git repository is:
+
+ ssh://kaufmann.debian.org/srv/keyring.debian.org/master-keyring.git/
+
+Note that, before March 2014, we used to work on a Bazaar tree. When
+the tree was imported over to Git, the only bit of lost information
+were the commit signatures. The Bazaar tree up to that point (left at
+commit #1297) is still available in Kaufmann, at
+/srv/keyring.debian.org/master-keyring/ (probably we should replace it
+to avoid confusions!).
+
+Public tree copy
+----------------
+
+There is a public copy of the tree we push to whenever we push the
+updates; it is available at Debian's Git server:
+
+ https://salsa.debian.org/debian-keyring/keyring.git
+
+This tree can also be browsed online at:
+
+ http://salsa.debian.org/debian-keyring/keyring
+
+So, when you push a new revision, do:
+
+ $ git push git@salsa.debian.org:debian-keyring/keyring.git master
+
+Signing commits
+---------------
+
+All commits should be GPG-signed. To do so, specify your signing key
+to Git, like:
+
+ $ git config user.signingkey 0x0000DEAD0000BEEF
+
+And remember to always specify the '-S' switch when committing!
+
+Note that if you use debcommit, you can ask it to always sign commits
+by either setting its DEBCOMMIT_SIGN_COMMITS configuration variable or
+by specifying --sign-commit in the command line.
+
+** Note: A nice Git hook can be of use here to remind us if we're
+ missing -S
+
+Parsing the Git changelog
+-------------------------
+
+When pushing a new keyring revision, you can use
+./script/parse-git-changelog to automate several steps. Pipe it the
+changelog since the last uploaded revision (remember to tag it!):
+
+$ git log 2014.11.19.. | scripts/parse-git-changelog
+
+It will create three files: rt-update, ldap-update and dak-update. For
+the two first ones, look in the respective cheatsheets; for the
+dak-update; refer to Ansgar Burchardt's message (Message-ID:
+<87tx2uvcti.fsf@deep-thought.43-1.org>):
+
+ Hi,
+
+ as DM permissions are bound to specific keys they need to be updated if
+ a DM changes his key. Currently I do so from time to time (usually when
+ somebody has problems uploading packages), but it would be nice if you
+ could tell dak that keys changed.
+
+ To do so, please wait until the new keys have been installed and then
+ upload a <user>-<YYYYMMDD>-<HHMM>.dak-commands via ftp to ftp-master. It
+ should look like the following:
+
+ +-----------------------------------------------------------------------
+ | Archive: ftp.debian.org
+ | Uploader: Ansgar Burchardt <ansgar@debian.org> *optional*
+ | Cc: keyring-maint@debian.org *optional*
+ |
+ | Action: dm-migrate
+ | From: 3C0B6EB0AB2729E8CE2255A7385AE490868EFA66
+ | To: 5691 873A A9B1 C18E 3CEE 82E6 0F8C E0BF 4E85 E61B
+ | Reason: Replace 0x385AE490868EFA66 with 0x0F8CE0BF4E85E61B (Stefan Völkel) (RT #5318)
+ |
+ | Action: dm-migrate
+ | From: B86CB5487CC4B58F0CA3856E7EE852DEE6B78725
+ | To: FBF3 EEAF A780 7802 B56B 27A9 70A8 FEE0 74B3 ED3A
+ | Reason: Replace 0x7EE852DEE6B78725 with 0x70A8FEE074B3ED3A (Yauheni Kaliuta) (RT #5251)
+ |
+ | Action: dm-remove
+ | Fingerprint: ~bla~
+ | Reason: ~blubb~
+ +-----------------------------------------------------------------------
+
+ Plus a GPG cleartext signature around everything.
+
+ The Uploader and Cc fields are optional; if Uploader is not given email
+ replies are sent to the primary UID of the key that was used to sign the
+ file. Whitespace in fields with fingerprints is ignored to make life
+ easier. The Reason field is optional and just for informational use.
+
+ Would it be possible for you to do this?
+
+ Ansgar
+
+Do note that ftp to ftp-master is no longer possible. We can place the
+file in its place by scp:
+
+ $ scp ${user}-${date}-${time}.dak-commands ssh.upload.debian.org:/srv/upload.debian.org/UploadQueue/
diff --git a/cheatsheets/infrastructure/kaufmann.txt b/cheatsheets/infrastructure/kaufmann.txt
new file mode 100644
index 0000000..cd5f60e
--- /dev/null
+++ b/cheatsheets/infrastructure/kaufmann.txt
@@ -0,0 +1,21 @@
+Pushing the changes to kaufmann.debian.org
+==========================================
+
+'mosca$' means the commands should be run on your own computer (it's
+gwolf's desktop name); of course, 'kaufmann$' means said steps are to
+be run from kaufmann.
+
+mosca$ make
+mosca$ make test
+
+This will complain about expired keys and other common
+mistakes. Double check its output - Sometimes weak subkeys are added,
+they will be reported here!
+
+mosca$ gpg --clearsign output/sha512sums.txt
+mosca$ mv output/sha512sums.txt.asc output/sha512sums.txt
+mosca$ scp scripts/update-keyrings kaufmann.debian.org:
+mosca$ scp -r output/ kaufmann.debian.org:
+mosca$ git push git@salsa.debian.org:debian-keyring/keyring.git master
+mosca$ ssh kaufmann
+kaufmann$ ./update-keyrings ./output
diff --git a/cheatsheets/infrastructure/ldap.txt b/cheatsheets/infrastructure/ldap.txt
new file mode 100644
index 0000000..c0b63ee
--- /dev/null
+++ b/cheatsheets/infrastructure/ldap.txt
@@ -0,0 +1,53 @@
+We can now directly update LDAP records - That means that key updates
+can now be handled directly by us. There are several tools that can be
+used for this purpose - I'm using ud-info. For this, I have to use the
+Debian password (and given I dislike passwords, I always regenerate it
+by following http://db.debian.org/password.html and throwing it away).
+
+keyring-maint has access to updating DD keys, but _not_ to change
+their account status - That is, creating new DD accounts and retiring
+DDs requires reassigning the tickets to DSA.
+
+To edit a DD's entry, we specify his username - In this case, I will
+edit Julien Danjou (acid)'s record (only the first couple of lines
+shown), and a short menu of actions:
+
+$ ud-info -r -u acid
+Accessing LDAP entry for 'acid' as 'gwolf'
+gwolf's password:
+
+Julien Danjou <acid@debian.org>
+Password last changed : Mon 13/10/2008 UTC
+PGP/GPG Key Fingerprints: 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD
+ Unix User ID : 'acid' (id=2491, gid=800)
+(...)
+ a) Arbitary Change
+ r) retire developer
+ R) Randomize Password
+ L) Lock account and disable mail
+ p) Change Password
+ u) Switch Users
+ x) Exit
+
+We request an arbitrary change for the "keyfingerprint"
+attribute. Note that it appears as empty - Disregardl
+
+Change? a
+Attr? keyfingerprint
+Old value: ''
+Press enter to leave unchanged and a single space to set to empty
+New? 5361 BD40 015B 7438 2739 101A 611B A950 8B78 A5C2
+Setting.
+
+The record will be shown again. Note that the old key will still be
+shown! You can switch user ('u') to the same user again and verify the
+change is in place.
+
+
+*** Helper script helps!
+
+ The parse-git-changelog script will generate a ldap-update
+ file. Each line contains the updates for a user: Debian login,
+ old key fingerprint, new key fingerprint.
+
+ Following that file is a real time saver for this step! :)
diff --git a/cheatsheets/infrastructure/rt.txt b/cheatsheets/infrastructure/rt.txt
new file mode 100644
index 0000000..4d4ff95
--- /dev/null
+++ b/cheatsheets/infrastructure/rt.txt
@@ -0,0 +1,74 @@
+Request Tracker (rt.debian.org)
+-------------------------------
+
+ [ Note: This file is basically a copy of Jonathan's "brain dump"
+ series, where he explained the workings of keyring to Gunnar, who
+ is writing this paragraph in third person. Hopefully, this will
+ reach somebody else in the future! ;-) ]
+
+ [ Note much later on: The text following here describes interaction
+ using the Web interface. It is valid, but we have found much easier
+ to use the `rt' command in the `rt4-clients' package.
+
+ The parse-git-changelog script will output a script that uses rhis
+ command and greatly simplifies closing and reasigning tickets when
+ many changes are involved.]
+
+
+So, RT. Why not just bugs.debian.org? I think the original rationale
+was that there's the potential for sensitive information to need to be
+tracked, in a similar manner to DSA. For example last week we had a DD
+with a potentially compromised key; wise to keep that information
+limited until the key was removed from the active keyring.
+
+I don't know if you've used Debian RT at all; it lives at:
+
+http://rt.debian.org/
+
+and you can get read only access to the public bits with the username
+guest and password readonly
+
+That will get you access to the "Keyring" queue, which is the public
+one. The one you can't see is "Keyring - Incoming" which currently has
+a bunch of key replacement requests sitting in it. These aren't
+particularly sensitive I guess, but I prefer to keep them private
+until implemented. Most of them are just waiting for post DebConf
+signatures to trickle in to help limit damage to the WoT.
+
+The Keyring queue at present has a couple of new DDs (which I'll sort
+out within the next week) and some older key replacements. However if
+you look through the closed tickets in that queue you should be able
+to match them up to the Git commits - anything that came from an RT
+ticket should have the ticket number in the changelog (occasionally
+this doesn't happen, but it's a mistake). Nothing closed should end up
+in the "Keyring - Incoming" queue; it all gets moved to Keyring at the
+point it's closed, so everything is eventually public.
+
+Users tend to create new tickets by emailing keyring@rt.debian.org -
+they need to put "Debian RT" in the subject to get it past the rt.d.o
+spam stuff and hopefully they also put something helpful in there as
+well, but often they don't. It's easy enough to retitle in RT. Tickets
+that come in via this interface end up in the "Keyring - Incoming"
+queue.
+
+One major problem with RT to note is that it mangles PGP/MIME
+signatures, so everything has to be done with inline signatures. I've
+also seen some mangling of those but only on mail from Joerg so I'm
+not sure if it's him or RT that's the problem.
+
+The other use for RT is asking DSA to make updates to LDAP; every user
+has an associated fingerprint (or multiple fingerprints, but at
+present that's only users with v3 + v4 keys). For "New DD" tickets
+that came from DAM I just reassign them to DSA once I've added the key
+and then they can deal with the account creation (the key needs added
+before the account so the initial password can be sent out
+encrypted). When I remove keys or do key replacements I just create a
+new ticket (via signed mail to admin@rt.debian.org); usually I've
+batched up a bunch of changes so I send one mail with details of all
+the removals/changes and reasoning. See RT #1667, #1664 or #1520 for
+examples of these mails.
+
+ *** Note - As of August 2010, we can now do the LDAP updates
+ ourselves. We should update this text with the pertinent
+ information / procedure.
+