Adding upstream version 2022.12.24.upstream/2022.12.24upstream

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

1 files changed, 74 insertions, 0 deletions

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.
+