Adding upstream version 2023.12.24.upstream/2023.12.24

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

11 files changed, 643 insertions, 0 deletions

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 <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.
+
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 <xoswald@debian.org>"
+  gpg:                 aka "Xavier Oswald <x.oswald@free.fr>"
+  gpg:                 aka "Xavier Oswald <xoswald@gmail.com>"
+  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 <xoswald>» 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 <javier.merino@alumnos.unican.es>" 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 <blarson>
+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 <pabs>
+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 <pkern>
+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 <blarson>
+0xE5273D986BE3C423 Paul Wise <pabs>
+0xED1A3933B2CFCDD8 Philipp Kern <pkern>
+
+So, add the following to the changelog:
+
+  * Updates from keyring.debian.org HKP interface:
+    0x8351C3C268AC5746 Robert Alan Larson <blarson>
+    0xE5273D986BE3C423 Paul Wise <pabs>
+    0xED1A3933B2CFCDD8 Philipp Kern <pkern>
+
+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)
+        # <mascellani@poisson.phc.unipi.it>" imported
+  gpg: key D9AB457E: public key "Giovanni Mascellani
+        # <mascellani@poisson.phc.unipi.it>" 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) <mascellani@poisson.phc.unipi.it>"
+  gpg:                 aka "Giovanni Mascellani <gio@debian.org>"
+  gpg:                 aka "Giovanni Mascellani <g.mascellani@gmail.com>"
+  gpg:                 aka "Giovanni Mascellani <g.mascellani@tiscali.it>"
+  gpg:                 aka "Giovanni Mascellani (DM) <mascellani@mail.dm.unipi.it>"
+  gpg:                 aka "Giovanni Mascellani (SNS) <giovanni.mascellani@sns.it>"
+  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 <gio>
+      # 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.