1 |
On Sun, Aug 10, 2003 at 07:27:37PM -0400, Kurt Lieber wrote: |
2 |
> OK, I guess this one is an infrastructure GLEP to approve/reject. I'd also |
3 |
> like to get input from seemant as the devrel manager. |
4 |
> |
5 |
> I have security concerns about running fingerd, but I can see how the |
6 |
> benefits outweigh the risks in this case. |
7 |
|
8 |
I thought some people might, im not sure what the specific issues you |
9 |
have are, but I know that a lot of people have had the "finger == bad" |
10 |
hammered into them, partly due to the information leakage, and partly as |
11 |
some of the early (pre 1980s) implementations were famously poor. |
12 |
|
13 |
I'm confident it is totally secure to use fingerd, and i included the |
14 |
list of famous sites using fingerd as precedent...but i understand it |
15 |
still makes some admins nervous :) |
16 |
|
17 |
> However, there are still several |
18 |
> areas that I don't see being addressed by this GLEP: |
19 |
> |
20 |
> 1) We already suffer from what I call "information sprawl" right now, |
21 |
> meaning we have the same information spread out across multiple places, |
22 |
> with no one place being the "master repository". The net result of this is |
23 |
> that users have to hunt through multiple repositories to try to find out |
24 |
> which one the developer chose to use for their particular query. |
25 |
|
26 |
agreed, but i think the specific type of information that would be kept |
27 |
in .plans is not available in any easy form right now, i guess tracking |
28 |
cvs commits and searching through usernames with bugzilla is the closest |
29 |
way you can get to an activity report, which is just not practical for |
30 |
most users, and even developers in a rush would probably not bother. |
31 |
|
32 |
> What ensures that the data available via fingerd will be a) complete |
33 |
> (meaning how will you ensure all developers participate) and b) up-to-date? |
34 |
> IMO, we need to identify one master source of information and *ensure* that |
35 |
> is used and kept up-to-date. If we want to provide multiple avenues to |
36 |
> access that info, that's fine, but we need one database, not multiple ones. |
37 |
> |
38 |
|
39 |
imho, if all developers just created a ~/.pgpkey the fingerd will be |
40 |
worth having (i'll explain below why i think this is the best medium for |
41 |
key distribution). In the implementations i have seen, people have |
42 |
always kept their .plans reasonably up to date, its an easy way to keep |
43 |
people notified of things that they are working on (or an in depth |
44 |
description of their responsibilities, etc) and if the finger daemon was |
45 |
well known about (mentioned in gwn, for example) it will give users a |
46 |
chance to check for updates before firing off an email. |
47 |
|
48 |
> 2) Tangental to the issue above, we've already talked about placing things |
49 |
> like GPG keys on the web site in XML format and pulling the other info (dev |
50 |
> name, location, projects, etc.) in via XML as well. Why is the fingerd |
51 |
> solution a better one? Items on the web site are updated hourly. I can't |
52 |
> think of too many cases where that type of freshness isn't timely enough. |
53 |
> |
54 |
> --kurt |
55 |
|
56 |
Yep, i suggested a fingerd at the time. imho, its the best way for |
57 |
distributing keys. |
58 |
|
59 |
making the keys available via the website is not ideal, getting it into |
60 |
a keyring involves a few steps, eg: |
61 |
|
62 |
1) fire up web browser, navigate to query page |
63 |
2) enter dev name, and then copy and paste key into text |
64 |
or copy and paste url for wget to fetch |
65 |
3) gpg --import < saved_file |
66 |
4) rm saved_file, etc, etc. |
67 |
|
68 |
and putting the keys onto keyservers would involve getting users to |
69 |
check fingerprints, and distributing those fingerprints (agreed, checks |
70 |
should always be made anyway, but in reality i cant see that happening). |
71 |
making the keys available via finger means it will be simple to get any |
72 |
keys into gpg from the command line on one line, eg: |
73 |
|
74 |
$ finger klieber@g.o | gpg --import |
75 |
|
76 |
the user can be confident the key is really yours, and only one basic |
77 |
command is required (you can test this with my key, my address is in my |
78 |
.sig). |
79 |
|
80 |
Also, should a developer revoke or regenerate a key, they would have to |
81 |
contact someone with cvs access to the website to update it, with |
82 |
fingerd they can just login (or scp) to dev.g.o and update the key |
83 |
themselves, which would take effect immediately. I am totally confident |
84 |
this is the simplest and best medium for distributing developer keys. |
85 |
|
86 |
Thanks, Tavis. |
87 |
|
88 |
-- |
89 |
------------------------------------- |
90 |
taviso@××××××××××××.org | finger me for my gpg key. |
91 |
------------------------------------------------------- |
92 |
|
93 |
-- |
94 |
gentoo-dev@g.o mailing list |