/[gentoo]/xml/htdocs/proj/en/glep/glep-0012.txt
Gentoo

Contents of /xml/htdocs/proj/en/glep/glep-0012.txt

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.1 - (show annotations) (download)
Mon Aug 11 14:32:44 2003 UTC (11 years ago) by g2boojum
Branch: MAIN
File MIME type: text/plain
new glep

1 GLEP: 12
2 Title: Gentoo.org Finger Daemon
3 Version: $Revision: $
4 Last-Modified: $Date: $
5 Author: Tavis Ormandy <taviso@gentoo.org>
6 Status: Draft
7 Type: Standards Track
8 Created: 10-Aug-2003
9 Post-History: 11-Aug-2003
10
11 Abstract
12 ========
13
14 The finger protocol is documented in rfc742 [1]_ and rfc1196 [2]_, a simple
15 protocol that returns a human readable report about a particular user
16 of the system. Typically, the information returned will be details such as
17 full name, location, etc. These details are entirely optional and are obtained
18 from the system passwd file, which of course can be edited or removed with the
19 standard chfn(1) [3]_ command.
20
21 The finger daemon will also return the contents of three files from the users home
22 directory, should they exist and be readable.
23
24
25 * ~/.project - which should contain information about the project currently being worked on.
26 * ~/.plan - which might contain work being done or a TODO style list.
27 * ~/.pgpkey - which would contain a PGP/GnuPG [4]_ public key block.
28
29 The finger protocol is mature, secure and widely used in the UNIX community.
30 There are clients available for all major operating systems, and web-based
31 clients for those that dont.
32
33 Motivation
34 ==========
35
36 Gentoo developers are already aware of the importance of User Relations [9]_ .
37
38 It is essential to keep the community up to date with current goals, status
39 updates, and information from the development team. Currently it is suggested
40 users track mailing lists, monitor the Gentoo bugzilla, developer IRC
41 channels and cvs commits.
42
43 While the resources to track developer progress and activity are made
44 available to users, they are not in a form usable to many people. Keeping
45 track of development is a tedious challenge, even for developers. For
46 non-technical users wishing to track the progress of a developer, using
47 mailing lists and bugzilla may not be a practical option.
48
49 Developers may also need a way to quickly find out the progress or activity of
50 other developers, different time zones sometimes makes it difficult for
51 developers to catch each other on IRC, and making already high-volume mailing
52 lists even more cluttered with status updates is not desirable.
53
54 A method that would allow individual developers to keep a log of their
55 activities and plans that were instantly accesible to anyone who was
56 interested would be desirable, I propose running a finger daemon on
57 gentoo.org, or dev.gentoo.org and forwarding requests there from gentoo.org.
58
59 Running a developer finger daemon would improve inter developer communication,
60 user communication and relations, and reduce workload on developers who have to
61 respond to queries from users on project status updates.
62
63 In the future, it is foreseen that portage will require a cryptographically
64 secure means of verifying ebuilds aquired from an rsync mirror are identical
65 to those checked into the portage tree by a developer [10]_ . Making developer keys
66 available to users for manually checking the integrity of files, or patches
67 sent to them is important. It has long been known that encouraging the
68 use of gpg among developers is desirable [5]_ .
69
70 Should a security vulnerability of a serious nature ever be reported,
71 standard procedure [6]_ is to inform vendors before releasing the information
72 to full disclosure security discussion lists. Making the relevant maintainer's
73 key easily obtainable will allow reporters to encrypt their reports.
74
75 Rationale
76 =========
77
78 Providing a finger daemon will allow users to instantly access information on
79 developers, and all details of that developers current projects that they decide
80 to share.
81
82 GPG keys for all developers will be instantly availble, and the output of the
83 finger devname@gentoo.org command can be piped into gpg --import to instantly
84 add it to the users keyring.
85
86 The following projects use finger for user-developer communications,::
87
88 Latest kernel releases, and developer information.
89 $ finger @kernel.org
90
91 Developers and organisers are encouraged to keep .plans about their
92 activity.
93 $ finger nugget@distributed.net
94
95 Latest NASA news, and information from engineers.
96 $ finger nasanews@space.mit.edu
97
98 Slackware developers.
99 $ finger volkerdi@slackware.com
100
101 FreeBSD developers.
102 $ finger nakai@freebsd.org
103
104 Implementation and Security
105 ===========================
106
107 Some admins are concerned about the security of running a finger daemon on their
108 machines, the class of security issues involved with the finger protocol are
109 commonly referred to as "information leaks" [7]_.
110
111 This means an attacker may be able to use a finger daemon to identify valid
112 accounts on their target, which they would then try to obtain access to.
113
114 This scenario does not apply to this implementation, as the gentoo developer
115 names are already well publicised. [8]_
116
117 No security issues have ever been reported with the fingerd available in gentoo
118 portage. Finger is used worldwide by universities, unix systems, and development
119 projects.
120
121 Adding dummy users, will be trivial and allow projects such as gentoo-docs,
122 gentoo-alpha, gentoo-ppc, etc to maintain .plans and .projects. This will allow
123 the projects to maintain more technical details or status updates not suitable
124 for their project webpages.
125
126 Adding data to a plan is a lot simpler than updating webpages.
127
128 Example Query
129 =============
130
131 Should a user want information about the author, this might be the output of
132 a finger query::
133
134 $ finger taviso@gentoo.org
135 Login: taviso Name: Tavis Ormandy
136 Directory: /home/taviso Shell: /bin/bash
137 Last login: dd-mmm-yyyy
138 Mail last read dd-mmm-yyy
139 Project:
140
141 Currently working on implementing XXX, and porting XXX to XXX.
142
143 Plan:
144
145 dd-mmm-yyyy
146
147 Investigating bug #12345, testing patch provided in #12236
148
149 Write documentation for new features in XXX.
150
151 dd-mmm-yyyy
152
153 Contact acmesoft regarding license for xxx in portage.
154
155 PGP Key:
156
157 -----BEGIN PGP PUBLIC KEY BLOCK-----
158 Version: GnuPG v1.2.1 (Linux)
159 (...)
160 -----END PGP PUBLIC KEY BLOCK-----
161
162 References
163 ==========
164
165 .. [1] http://www.ietf.org/rfc/rfc0742.txt
166 .. [2] http://www.ietf.org/rfc/rfc1196.txt
167 .. [3] http://www.gentoo.org/dyn/pkgs/sys-apps/shadow.xml
168 .. [4] http://www.gnupg.org
169 .. [5] <20030629040521.4316b135.seemant@gentoo.org>
170 .. [6] http://www.oisafety.org/process.html
171 .. [7] http://search.linuxsecurity.com/cgi-bin/htsearch?words=information%20leak
172 .. [8] http://www.gentoo.org/main/en/devlist.xml
173 .. [9] http://www.gentoo.org/proj/en/devrel/user-relations.xml
174 .. [10] http://www.gentoo.org/news/en/gwn/20030407-newsletter.xml
175
176 Copyright
177 =========
178
179 This document is released under the Open Publications License.

  ViewVC Help
Powered by ViewVC 1.1.20