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/infrastructure/rt.txt | 74 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 cheatsheets/infrastructure/rt.txt (limited to 'cheatsheets/infrastructure/rt.txt') 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. + -- cgit v1.2.3