From: Tavis Ormandy <taviso@gentoo.org>
To: glep@gentoo.org
Cc: gentoo-dev@gentoo.org
Subject: [gentoo-dev] Finger GLEP
Date: Sun, 10 Aug 2003 22:39:14 +0000 [thread overview]
Message-ID: <20030810223914.GB27538@sdf.lonestar.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 242 bytes --]
Hey, please find attached a glep proposal for a Gentoo.org Finger
Daemon in docutils text.
--
-------------------------------------
taviso@sdf.lonestar.org | finger me for my gpg key.
-------------------------------------------------------
[-- Attachment #2: finger_glep.txt --]
[-- Type: text/plain, Size: 6671 bytes --]
GLEP: 12
Title: Gentoo.org Finger Daemon
Version: $Revision: $
Last-Modified: $Date: $
Author: Tavis Ormandy <taviso@gentoo.org>
Status: Draft
Type: Standards Track
Created: 10-Aug-2003
Post-History:
Abstract
========
The finger protocol is documented in rfc742 [1]_ and rfc1196 [2]_, 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) [3]_ 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 [4]_ 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 dont.
Motivation
==========
Gentoo developers are already aware of the importance of User Relations [9]_ .
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 accesible 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 aquired from an rsync mirror are identical
to those checked into the portage tree by a developer [10]_ . 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 [5]_ .
Should a security vulnerability of a serious nature ever be reported,
standard procedure [6]_ 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 availble, and the output of the
finger devname@gentoo.org command can be piped into gpg --import to instantly
add it to the users 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 their
activity.
$ 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" [7]_.
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. [8]_
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-----
References
==========
.. [1] http://www.ietf.org/rfc/rfc0742.txt
.. [2] http://www.ietf.org/rfc/rfc1196.txt
.. [3] http://www.gentoo.org/dyn/pkgs/sys-apps/shadow.xml
.. [4] http://www.gnupg.org
.. [5] <20030629040521.4316b135.seemant@gentoo.org>
.. [6] http://www.oisafety.org/process.html
.. [7] http://search.linuxsecurity.com/cgi-bin/htsearch?words=information%20leak
.. [8] http://www.gentoo.org/main/en/devlist.xml
.. [9] http://www.gentoo.org/proj/en/devrel/user-relations.xml
.. [10] http://www.gentoo.org/news/en/gwn/20030407-newsletter.xml
Copyright
=========
This document is released under the Open Publications License.
[-- Attachment #3: Type: text/plain, Size: 37 bytes --]
--
gentoo-dev@gentoo.org mailing list
next reply other threads:[~2003-08-10 22:39 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-10 22:39 Tavis Ormandy [this message]
2003-08-10 23:27 ` [gentoo-dev] Finger GLEP Kurt Lieber
2003-08-10 23:36 ` Seemant Kulleen
2003-08-11 0:17 ` Tavis Ormandy
2003-08-11 0:57 ` Spider
2003-08-11 0:02 ` Tavis Ormandy
2003-08-11 9:22 ` Kurt Lieber
2003-08-11 11:35 ` Tavis Ormandy
2003-08-11 12:37 ` Paul de Vrieze
2003-08-11 12:59 ` Tavis Ormandy
2003-08-11 13:33 ` Kurt Lieber
2003-08-11 14:01 ` Tavis Ormandy
2003-08-11 0:03 ` Grant Goodyear
2003-08-11 8:05 ` Paul de Vrieze
2003-08-11 1:17 ` Aron Griffis
2003-08-11 8:24 ` Paul de Vrieze
2003-08-11 12:09 ` Tavis Ormandy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030810223914.GB27538@sdf.lonestar.org \
--to=taviso@gentoo.org \
--cc=gentoo-dev@gentoo.org \
--cc=glep@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox