From 4ed1a6e1d4fcb1ba272a4fb3931b33d1c6fbee0d Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sat, 13 Apr 2024 16:25:47 +0200 Subject: Adding upstream version 2023.12.24. Signed-off-by: Daniel Baumann --- cheatsheets/index.txt | 37 ++++++++ cheatsheets/infrastructure/adding-new-member.txt | 23 +++++ cheatsheets/infrastructure/git.txt | 111 +++++++++++++++++++++++ cheatsheets/infrastructure/kaufmann.txt | 21 +++++ cheatsheets/infrastructure/ldap.txt | 53 +++++++++++ cheatsheets/infrastructure/rt.txt | 74 +++++++++++++++ cheatsheets/keyring/adding_dd.txt | 2 + cheatsheets/keyring/adding_dm.txt | 95 +++++++++++++++++++ cheatsheets/keyring/pulling_hkp_changes.txt | 82 +++++++++++++++++ cheatsheets/keyring/removing_dd_key.txt | 36 ++++++++ cheatsheets/keyring/updating_dd_key.txt | 109 ++++++++++++++++++++++ 11 files changed, 643 insertions(+) create mode 100644 cheatsheets/index.txt create mode 100644 cheatsheets/infrastructure/adding-new-member.txt create mode 100644 cheatsheets/infrastructure/git.txt create mode 100644 cheatsheets/infrastructure/kaufmann.txt create mode 100644 cheatsheets/infrastructure/ldap.txt create mode 100644 cheatsheets/infrastructure/rt.txt create mode 100644 cheatsheets/keyring/adding_dd.txt create mode 100644 cheatsheets/keyring/adding_dm.txt create mode 100644 cheatsheets/keyring/pulling_hkp_changes.txt create mode 100644 cheatsheets/keyring/removing_dd_key.txt create mode 100644 cheatsheets/keyring/updating_dd_key.txt (limited to 'cheatsheets') diff --git a/cheatsheets/index.txt b/cheatsheets/index.txt new file mode 100644 index 0000000..32bada7 --- /dev/null +++ b/cheatsheets/index.txt @@ -0,0 +1,37 @@ +Infrastructure +============== + +Git tree - infrastructure/git.txt +Request Tracker - infrastructure/rt.txt +kaufmann.debian.org layout - infrastructure/kaufmann.txt +HKP keyserver - infrastructure/hkp.txt + +Keyring handling +================ + +As a general rule, keyring requests arrive via Debian's RT, and we +usually ask people to open a ticket so it is kept as a reference. + +When you are working with a request, claim the ticket and set it to +the "open" state from RT's web interface. + +Once it is done, send a message (either reply to RT's message on the +mail or via RT's web interface - taking care to use "reply" and not +"comment", to make it visible to the submitter) telling the change is +done in the working tree, and explaining we might take some time to +publish the changes - Something like this: + + The changes you have requested have been pushed to our working + tree, and will be included in the next keyring push. Please be + patient - We batch several requests together, and tend to do + approximately one push per month. + +The operations on keyring are on a separate file each, for ease of +reference. They are: + +Adding a DD key - keyring/adding_dd.txt +Removing a DD key - keyring/removing_dd.txt +Updating a DD key - keyring/updating_dd.txt +Adding a DM key - keyring/adding_dm.txt +Promoting a DM to DD - keyring/dm_to_dd.txt + 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 --.dak-commands via ftp to ftp-master. It + should look like the following: + + +----------------------------------------------------------------------- + | Archive: ftp.debian.org + | Uploader: Ansgar Burchardt *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 +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. + diff --git a/cheatsheets/keyring/adding_dd.txt b/cheatsheets/keyring/adding_dd.txt new file mode 100644 index 0000000..830c61b --- /dev/null +++ b/cheatsheets/keyring/adding_dd.txt @@ -0,0 +1,2 @@ +Adding a DD key +=============== diff --git a/cheatsheets/keyring/adding_dm.txt b/cheatsheets/keyring/adding_dm.txt new file mode 100644 index 0000000..5a03ca3 --- /dev/null +++ b/cheatsheets/keyring/adding_dm.txt @@ -0,0 +1,95 @@ +Adding a DM key +=============== + +- Request must be signed by somebody in the DM team (currently: + anibal, enrico, xoswald). Always check it has been signed by them + using their currently registered Debian key! + +- Request must include: + - Full DM key fingerprint + - Agreement URL (message sent by prospective DM where he agrees with + DFSG, SC, DMUP, and giving an overview of his current work in + Debian) + - One or more DD advocates (messages signed by DDs confirming + applicant has done Debian work and requesting him to be accepted) + - It _may_ also include a bug number (in the regular Debian BTS) + that should be closed when the request is dealt with. If so, close + it in debian/changelog. + +- Procedure: + + I am following the request for Javier Merino (RT #2466). Of course, + replace keys with adequate values. + + $ gpg --verify < (copy of RT message) + (...) + gpg: Signature made Thu 26 Aug 2010 01:14:41 PM CDT using RSA key ID 464B8DE3 + gpg: Good signature from "Xavier Oswald " + gpg: aka "Xavier Oswald " + gpg: aka "Xavier Oswald " + gpg: WARNING: This key is not certified with a trusted signature! + gpg: There is no indication that the signature belongs to the owner. + Primary key fingerprint: DE46 8D1D 2744 CF28 5431 1CD7 85B9 0D23 464B 8DE3 + # I have never met xoswald, but «grep 464B8DE3 keyids» gives me + # «0x85B90D23464B8DE3 Xavier Oswald » and verifying + # the fingerprint matches + + $ gpg --keyserver $KEYSERVER --recv-key 6B1BAEC2CA5D4EA7439803612DCE3F2836D4E4F5 + gpg: requesting key 36D4E4F5 from hkp server nisamox.fciencias.unam.mx + gpg: key 36D4E4F5: public key "Javier Merino Cacho " imported + gpg: 3 marginal(s) needed, 1 complete(s) needed, classic trust model + gpg: depth: 0 valid: 3 signed: 163 trust: 0-, 0q, 0n, 0m, 0f, 3u + gpg: depth: 1 valid: 163 signed: 405 trust: 154-, 0q, 0n, 5m, 4f, 0u + gpg: depth: 2 valid: 12 signed: 99 trust: 12-, 0q, 0n, 0m, 0f, 0u + gpg: next trustdb check due at 2010-09-10 + gpg: Total number processed: 1 + gpg: imported: 1 + + $ gpg --export 6B1BAEC2CA5D4EA7439803612DCE3F2836D4E4F5 > /tmp/key + + $ ./scripts/add-key /tmp/key debian-maintainers-gpg/ + (...) + # A screen listing all of the applicant's signatures which are + # in the Debian keyring appears. At very least, one DD should + # have signed his key, unless specific reasons + # (i.e. geographical) have been already discussed. Take note of + # the respective key IDs. If they are too many, just note the + # first four or five, in this case: 5D8CDA7B 74974824 95930EDE + # E1C21845 + Are you sure you want to update this key? (y/n) + y + adding debian-maintainers-gpg/0x2DCE3F2836D4E4F5 + + # Note this addition in debian/changelog - Just make sure before + # doing this you are not modifying an already uploaded changelog + # entry! + $ dch -a 'Add new DM key 0x2DCE3F2836D4E4F5 (Javier Merino) (RT #2466) (Closes: #593475)' + + $ git commit + # And that's it. For the VCS log, we use the following format: +------------------------------------------------------------ +Add new DM key $DM_KEY ($DM_NAME) (RT #$RT_NUM) + +Add new DM key $DM_KEY as requested by DM team ($PERSON) + Signed by existing DD keys: $SIGN1 $SIGN2 $SIGN3 $SIGNN +Agreement: + $AGREE_URL +Advocates: + $DD1_ACCOUNT - $ADVOCATE1_URL + $DD2_ACCOUNT - $ADVOCATE2_URL + $DD3_ACCOUNT - $ADVOCATE3_URL +------------------------------------------------------------ + +i.e. + +------------------------------------------------------------ +Add new DM key 0x2DCE3F2836D4E4F5 (Javier Merino) (RT #2466) + +Add new DM key 0x2DCE3F2836D4E4F5 as requested by DM team (xoswald) + Signed by existing DD keys: 5D8CDA7B 74974824 95930EDE E1C21845 +Agreement: + http://lists.debian.org/debian-newmaint/2010/08/msg00020.html +Advocates: + vdanjean - http://lists.debian.org/debian-newmaint/2010/08/msg00021.html +------------------------------------------------------------ + diff --git a/cheatsheets/keyring/pulling_hkp_changes.txt b/cheatsheets/keyring/pulling_hkp_changes.txt new file mode 100644 index 0000000..67969c6 --- /dev/null +++ b/cheatsheets/keyring/pulling_hkp_changes.txt @@ -0,0 +1,82 @@ +Pulling changes from the HKP server +=================================== + +We run a HKP (HTTP Keyserver Protocol) keyserver to allow for public +querying on Debian keys and to allow DDs and DMs to update their keys, +i.e., sending more signatures. Updating the keyrings from this HKP +server is "pulling" HKP changes. + +There's a script call pull-updates that takes a keyring and a keyring +dir, explodes the keyring and looks for keys that have changed, then +calls update-key for each of them. This is a bit of a labour intensive +task, but it does mean we don't automatically allow things like adding +a new UID that's complete nonsense. I have some local patches to make +it a bit easier in terms of automatically generating an update.log +which is the same format as in the changelog of what was altered; I'll +commit them at some point soon. + +So, to import the HKP updates, we pull the keyrings first from: + + kaufmann.debian.org:/srv/keyring.debian.org/keyrings-new/debian-{keyring,nonupload,maintainers}.gpg + +and second, from: + + kaufmann.debian.org:/srv/keyring.debian.org/pending-updates/debian-{keyring,nonupload,maintainers}.gpg + +$ scp kaufmann.debian.org:/srv/keyring.debian.org/keyrings-new/debian-{keyring,nonupload,maintainers}.gpg . +debian-keyring.gpg 100% 30MB 2.5MB/s 00:12 +debian-maintainers.gpg 100% 1058KB 529.1KB/s 00:02 +debian-maintainers.gpg 100% 48KB 59.6KB/s 00:00 +$ for i in keyring nonupload maintainers; do ./scripts/pull-updates debian-${i}.gpg debian-${i}-gpg/ +(...a long list of keys later...) +Updated keys are: +0x8351C3C268AC5746 0xE5273D986BE3C423 0xED1A3933B2CFCDD8 +gpg: keyring `/tmp/jetring.qGSB7NPt/secring.gpg' created +gpg: keyring `/tmp/jetring.qGSB7NPt/pubring.gpg' created +gpg: /tmp/jetring.qGSB7NPt/trustdb.gpg: trustdb created +Running gpg-diff: +0x8351C3C268AC5746 Robert Alan Larson +Are you sure you want to update this key? (y/n) +y +Updated key. +gpg: keyring `/tmp/jetring.mHhg5onR/secring.gpg' created +gpg: keyring `/tmp/jetring.mHhg5onR/pubring.gpg' created +gpg: /tmp/jetring.mHhg5onR/trustdb.gpg: trustdb created +Running gpg-diff: +0xE5273D986BE3C423 Paul Wise +Are you sure you want to update this key? (y/n) +y +Updated key. +gpg: keyring `/tmp/jetring.ZJnN1JpE/secring.gpg' created +gpg: keyring `/tmp/jetring.ZJnN1JpE/pubring.gpg' created +gpg: /tmp/jetring.ZJnN1JpE/trustdb.gpg: trustdb created +Running gpg-diff: +0xED1A3933B2CFCDD8 Philipp Kern +Are you sure you want to update this key? (y/n) +y +Updated key. + +In this process, we must check the changes we pull in "make sense" — +keys should not add unrelated UIDs, weaker subkeys, or excessive +amounts of signatures. + +A log of the changes is stored in updates.log: + +$ cat update.log +0x8351C3C268AC5746 Robert Alan Larson +0xE5273D986BE3C423 Paul Wise +0xED1A3933B2CFCDD8 Philipp Kern + +So, add the following to the changelog: + + * Updates from keyring.debian.org HKP interface: + 0x8351C3C268AC5746 Robert Alan Larson + 0xE5273D986BE3C423 Paul Wise + 0xED1A3933B2CFCDD8 Philipp Kern + +Repeat the process for the other downloaded keyrings. + +After processing the second set of keys (at kaufmann's +/srv/keyring.debian.org/pending-updates), the three keyrings should be +removed (as they are checked to be empty when updating the keyrings at +kaufmann -- see infrastructure/kaufmann.txt) diff --git a/cheatsheets/keyring/removing_dd_key.txt b/cheatsheets/keyring/removing_dd_key.txt new file mode 100644 index 0000000..a416e7d --- /dev/null +++ b/cheatsheets/keyring/removing_dd_key.txt @@ -0,0 +1,36 @@ +Removing a DD key +================= + +Some more verbosity would not hurt... Anyway, little is better than none. + +- Emeritus + +| # Deal with RT #142 +| # Straightforward resignation, debian-private mail confirmed, +| # move key to emeritus +| ./script/move-key 0xFCF6DD4539CCF0C7 emeritus-keyring-gpg/ + +The move-key script will move the key from any of the active keyrings +it is currently located on. + +If the key is not moved due to the maintainer explicitly resigning +(i.e. expelled, deceased, MIA), the key should be removed entirely. + +Changelog entry: +------------------------------------------------------------ + * Move 0xFCF6DD4539CCF0C7 (Akira TAGOH) to emeritus (RT #142) +------------------------------------------------------------ + +Commit message: +------------------------------------------------------------ +Move 0xFCF6DD4539CCF0C7 (Akira TAGOH) to emeritus (RT #142) + + Akira has retired from Debian. + Message-Id: <20070731.194218.174801666.tagoh@debian.org> +------------------------------------------------------------ + +- MIA + +Eventually, the MIA team comes up with a list of people not answering +to the WAT ping (Where Are They?). The main difference for us is that, +instead of moving the key to emeritus-keyring-gpg, it is removed entirely. diff --git a/cheatsheets/keyring/updating_dd_key.txt b/cheatsheets/keyring/updating_dd_key.txt new file mode 100644 index 0000000..46f4456 --- /dev/null +++ b/cheatsheets/keyring/updating_dd_key.txt @@ -0,0 +1,109 @@ +Updating a DD key +================= + +- Key updates should be for a reason (i.e. lost control of earlier + key, or moving to stronger key). + +- Request must include: + - Old key (full fingerprint) + - New key (full fingerprint) + - Inline signature with OLD key + +- New key must be signed by at least two DDs (and more if possible); + if the old key is particularly well connected, we have requested the + person to get more signatures in order to avoid weakening the + overall web of trust. The new key must also be signed with the old + one (except in cases, say, where the old one was lost). + +- Procedure + + I am following the request for Giovanni Mascellani (RT #2473). Of + course, replace keys with adequate values. As you can see, this + request mentioned only the key IDs, so full fingerprint was + requested. + + # Before anything else, retrieve both keys, to be able to do the + # following checks + $ gpg --keyserver $KEYSERVER --recv-key \ + 1EB63D43E2014DDF67BD003FFCB0BB5C5F1FBF70 \ + 82D119A840C6EFCA6F5AF9459EDCC991D9AB457E + gpg: requesting key 5F1FBF70 from hkp server nisamox.fciencias.unam.mx + gpg: requesting key D9AB457E from hkp server nisamox.fciencias.unam.mx + gpg: key 5F1FBF70: public key "Giovanni Mascellani (Poisson) + # " imported + gpg: key D9AB457E: public key "Giovanni Mascellani + # " imported + gpg: 3 marginal(s) needed, 1 complete(s) needed, classic trust model + gpg: depth: 0 valid: 3 signed: 163 trust: 0-, 0q, 0n, 0m, 0f, 3u + gpg: depth: 1 valid: 163 signed: 409 trust: 154-, 0q, 0n, 5m, 4f, + # 0u + gpg: depth: 2 valid: 12 signed: 99 trust: 12-, 0q, 0n, 0m, 0f, 0u + gpg: next trustdb check due at 2010-09-10 + gpg: Total number processed: 2 + gpg: imported: 2 (RSA: 1) + + $ gpg --verify < (copy of RT message) + (...) + gpg: Signature made Sun 29 Aug 2010 07:30:03 AM CDT using RSA key ID E1889B00 + gpg: Good signature from "Giovanni Mascellani (Poisson) " + gpg: aka "Giovanni Mascellani " + gpg: aka "Giovanni Mascellani " + gpg: aka "Giovanni Mascellani " + gpg: aka "Giovanni Mascellani (DM) " + gpg: aka "Giovanni Mascellani (SNS) " + gpg: aka "[jpeg image of size 8171]" + gpg: WARNING: This key is not certified with a trusted signature! + gpg: There is no indication that the signature belongs to the owner. + Primary key fingerprint: 1EB6 3D43 E201 4DDF 67BD 003F FCB0 BB5C 5F1F BF70 + Subkey fingerprint: 409F 2383 802D B40C CA04 9AF9 810A 9F69 E188 9B00 + + - Helper script + + We have a script called "replace-key". When called, it takes care to + do all of the steps described from here until the commit step. + + You should call it using both keys' long (64 bit) keyids: + + $ ./script/replace-key FCB0BB5C5F1FBF70 9EDCC991D9AB457E + + + $ gpg --export D9AB457E > /tmp/key + # DD keys (past and present), names and identities are kept in + # the plaintext file 'keyids' - Confirm and get the requester's + # Debian account name in case it's not listed as one of the + # identities + + $ grep 5F1FBF70 keyids + 0xFCB0BB5C5F1FBF70 Giovanni Mascellani + # Old keys are removed from the repository. + + $ git rm debian-keyring-gpg/0xFCB0BB5C5F1FBF70 + rm 'debian-keyring-gpg/0xFCB0BB5C5F1FBF70' + + $ ./scripts/add-key /tmp/key debian-keyring-gpg/ + # A screen listing all of the requester's signatures which are + # in the Debian keyring appears. At very least, two DD should + # have signed his key, unless specific reasons + # (i.e. geographical) have been already discussed. Take note of + # the respective key IDs. If they are too many, just note the + # first four or five, in this case: F2C423BC 33FC40A4. + # Also take note that the old key (5F1FBF70) has also signed + # it. + Are you sure you want to update this key? (y/n) + y + adding debian-keyring-gpg/0x9EDCC991D9AB457E + Enter full name of new key: Giovanni Mascellani + Enter Debian login of new key: gio + + # Note this addition in debian/changelog - Just make sure before + # doing this you are not modifying an already uploaded changelog + # entry! + $ dch -a 'Replace 0xFCB0BB5C5F1FBF70 with 0x9EDCC991D9AB457E (Giovanni Mascellani) (RT #2473)' + +- Git commit + + In order for the parse-git-changelog script to work, we adhere to + machine-parsable information in the changelog. If you used the + replace-key script, you will find it creates a git-commit-template + file. It just needs you to fill in the Debian user IDs for the + New-key-certified-by field. -- cgit v1.2.3