GLEP:12

Warning
This GLEP is no longer maintained in the Gentoo Wiki and remains here only as a historical record. Please visit https://www.gentoo.org/glep/glep-0012.html for the current version of this GLEP.

GLEP 12: Gentoo.org Finger Daemon
Type	Standards Track
Status	Rejected
Author	Tavis Ormandy <taviso@gentoo.org>
Editor
Replaces
Replaced by	(none)
Requires
Post History

Reason for rejection

Information about Gentoo development is already significantly fragmented. Although this GLEP has its merits, the fact that it is a separate source of information, rather than simply another conduit to existing sources of information, poses more problems than it solves. Were this GLEP to be resubmitted/modified so that finger was nothing more than an interface into existing sources of information, it would probably be accepted.

Abstract

The finger protocol is documented in rfc742 and rfc1196 , a simple protocol that returns a human readable report about a particular user of the system. Typically, the information returned will be details such as full name, location, etc. These details are entirely optional and are obtained from the system passwd file, which of course can be edited or removed with the standard chfn(1) command.

The finger daemon will also return the contents of three files from the users home directory, should they exist and be readable.

• ~/.project - which should contain information about the project currently being worked on.
• ~/.plan - which might contain work being done or a TODO style list.
• ~/.pgpkey - which would contain a PGP/GnuPG public key block.

The finger protocol is mature, secure and widely used in the UNIX community. There are clients available for all major operating systems, and web-based clients for those that don't.

Motivation

Gentoo developers are already aware of the importance of User Relations .

It is essential to keep the community up to date with current goals, status updates, and information from the development team. Currently it is suggested users track mailing lists, monitor the Gentoo bugzilla, developer IRC channels and cvs commits.

While the resources to track developer progress and activity are made available to users, they are not in a form usable to many people. Keeping track of development is a tedious challenge, even for developers. For non-technical users wishing to track the progress of a developer, using mailing lists and Bugzilla may not be a practical option.

Developers may also need a way to quickly find out the progress or activity of other developers, different time zones sometimes makes it difficult for developers to catch each other on IRC, and making already high-volume mailing lists even more cluttered with status updates is not desirable.

A method that would allow individual developers to keep a log of their activities and plans that were instantly accessible to anyone who was interested would be desirable, I propose running a finger daemon on gentoo.org, or dev.gentoo.org and forwarding requests there from gentoo.org.

Running a developer finger daemon would improve inter developer communication, user communication and relations, and reduce workload on developers who have to respond to queries from users on project status updates.

In the future, it is foreseen that portage will require a cryptographically secure means of verifying ebuilds acquired from an rsync mirror are identical to those checked into the portage tree by a developer . Making developer keys available to users for manually checking the integrity of files, or patches sent to them is important. It has long been known that encouraging the use of gpg among developers is desirable .

Should a security vulnerability of a serious nature ever be reported, standard procedure is to inform vendors before releasing the information to full disclosure security discussion lists. Making the relevant maintainer's key easily obtainable will allow reporters to encrypt their reports.

Rationale

Providing a finger daemon will allow users to instantly access information on developers, and all details of that developers current projects that they decide to share.

GPG keys for all developers will be instantly available, and the output of the finger devname@gentoo.org command can be piped into gpg --import to instantly add it to the user's keyring.

The following projects use finger for user-developer communications,:

Latest kernel releases, and developer information.

   $ finger @kernel.org

Developers and organisers are encouraged to keep .plans about theiractivity.

   $ finger nugget@distributed.net

Latest NASA news, and information from engineers.

   $ finger nasanews@space.mit.edu 

Slackware developers.

   $ finger volkerdi@slackware.com

FreeBSD developers.

   $ finger nakai@freebsd.org

Implementation and Security

Some admins are concerned about the security of running a finger daemon on their machines, the class of security issues involved with the finger protocol are commonly referred to as "information leaks" .

This means an attacker may be able to use a finger daemon to identify valid accounts on their target, which they would then try to obtain access to.

This scenario does not apply to this implementation, as the Gentoo developer names are already well publicised

No security issues have ever been reported with the fingerd available in Gentoo Portage. Finger is used worldwide by universities, unix systems, and development projects.

Adding dummy users, will be trivial and allow projects such as gentoo-docs, gentoo-alpha, gentoo-ppc, etc to maintain .plans and .projects. This will allow the projects to maintain more technical details or status updates not suitable for their project webpages.

Adding data to a plan is a lot simpler than updating webpages.

Example Query

Should a user want information about the author, this might be the output of a finger query:

   $ finger taviso@gentoo.org 
   Login: taviso                  Name: Tavis Ormandy 
       Directory: /home/taviso        Shell: /bin/bash 
   Last login: dd-mmm-yyyy 
   Mail last read dd-mmm-yyy 
       Project:
       Currently working on implementing XXX, and porting XXX to XXX.
   Plan:
       dd-mmm-yyyy
       Investigating bug #12345, testing patch provided in #12236 
       Write documentation for new features in XXX.
       dd-mmm-yyyy
       Contact acmesoft regarding license for xxx in portage.
   PGP Key: 
   -----BEGIN PGP PUBLIC KEY BLOCK----- 
   Version: GnuPG v1.2.1 (Linux) 
   (...) 
   -----END PGP PUBLIC KEY BLOCK-----

Copyright

This document is released under the Open Publications License.