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