1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
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.
|
