[gentoo-dev] Finger GLEP

[gentoo-dev] Finger GLEP

[Tavis Ormandy]

[-- 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

Re: [gentoo-dev] Finger GLEP

[Kurt Lieber]

[-- Attachment #1: Type: text/plain, Size: 1612 bytes --]

On Sun, Aug 10, 2003 at 10:39:14PM +0000 or thereabouts, Tavis Ormandy wrote:
> Hey, please find attached a glep proposal for a Gentoo.org Finger
> Daemon in docutils text.

OK, I guess this one is an infrastructure GLEP to approve/reject.  I'd also
like to get input from seemant as the devrel manager.

I have security concerns about running fingerd, but I can see how the
benefits outweigh the risks in this case.  However, there are still several
areas that I don't see being addressed by this GLEP:

1) We already suffer from what I call "information sprawl" right now,
meaning we have the same information spread out across multiple places,
with no one place being the "master repository".  The net result of this is
that users have to hunt through multiple repositories to try to find out
which one the developer chose to use for their particular query.

What ensures that the data available via fingerd will be a) complete
(meaning how will you ensure all developers participate) and b) up-to-date?
IMO, we need to identify one master source of information and *ensure* that
is used and kept up-to-date.  If we want to provide multiple avenues to
access that info, that's fine, but we need one database, not multiple ones.

2) Tangental to the issue above, we've already talked about placing things
like GPG keys on the web site in XML format and pulling the other info (dev
name, location, projects, etc.) in via XML as well.  Why is the fingerd
solution a better one?  Items on the web site are updated hourly.  I can't
think of too many cases where that type of freshness isn't timely enough.

--kurt

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Finger GLEP

[Seemant Kulleen]

[-- Attachment #1: Type: text/plain, Size: 984 bytes --]

I'm inclined to agree with Kurt here.  I don't know that we should be
opening more ports than necessary, for starters, and I don't know that
the benefits necessarily outweigh the risks here.  The idea for the
devrel dev/herd/project pages will be to have a uniform portal to all
sorts of info.

If it's something that can be easily automated from the existing
databases that we create for devs, projects, herds then I guess I have
no problem for that end.  Security risks are an infrastructure issue. 
In other words, to summarise, I'm not particularly enthusiastic about
this, nor am I particularly disinclined.  However, some discussion on
the issues Kurt brought up (some of which are repeated above) would go a
long way :)

Thanks,


-- 
Seemant Kulleen
Developer and Project Co-ordinator,
Gentoo Linux					http://dev.gentoo.org/~seemant

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3458780E
Key fingerprint = 23A9 7CB5 9BBB 4F8D 549B 6593 EDA2 65D8 3458 780E

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Finger GLEP

[Tavis Ormandy]

On Sun, Aug 10, 2003 at 07:27:37PM -0400, Kurt Lieber wrote:
> OK, I guess this one is an infrastructure GLEP to approve/reject.  I'd also
> like to get input from seemant as the devrel manager.
> 
> I have security concerns about running fingerd, but I can see how the
> benefits outweigh the risks in this case.  

I thought some people might, im not sure what the specific issues you
have are, but I know that a lot of people have had the "finger == bad"
hammered into them, partly due to the information leakage, and partly as
some of the early (pre 1980s) implementations were famously poor.

I'm confident it is totally secure to use fingerd, and i included the
list of famous sites using fingerd as precedent...but i understand it
still makes some admins nervous :)

> However, there are still several
> areas that I don't see being addressed by this GLEP:
> 
> 1) We already suffer from what I call "information sprawl" right now,
> meaning we have the same information spread out across multiple places,
> with no one place being the "master repository".  The net result of this is
> that users have to hunt through multiple repositories to try to find out
> which one the developer chose to use for their particular query.

agreed, but i think the specific type of information that would be kept
in .plans is not available in any easy form right now, i guess tracking
cvs commits and searching through usernames with bugzilla is the closest
way you can get to an activity report, which is just not practical for
most users, and even developers in a rush would probably not bother. 

> What ensures that the data available via fingerd will be a) complete
> (meaning how will you ensure all developers participate) and b) up-to-date?
> IMO, we need to identify one master source of information and *ensure* that
> is used and kept up-to-date.  If we want to provide multiple avenues to
> access that info, that's fine, but we need one database, not multiple ones.
>

imho, if all developers just created a ~/.pgpkey the fingerd will be
worth having (i'll explain below why i think this is the best medium for
key distribution). In the implementations i have seen, people have
always kept their .plans reasonably up to date, its an easy way to keep
people notified of things that they are working on (or an in depth
description of their responsibilities, etc) and if the finger daemon was
well known about (mentioned in gwn, for example) it will give users a
chance to check for updates before firing off an email. 

> 2) Tangental to the issue above, we've already talked about placing things
> like GPG keys on the web site in XML format and pulling the other info (dev
> name, location, projects, etc.) in via XML as well.  Why is the fingerd
> solution a better one?  Items on the web site are updated hourly.  I can't
> think of too many cases where that type of freshness isn't timely enough.
> 
> --kurt

Yep, i suggested a fingerd at the time. imho, its the best way for
distributing keys.

making the keys available via the website is not ideal, getting it into
a keyring involves a few steps, eg:

1) fire up web browser, navigate to query page
2) enter dev name, and then copy and paste key into text
   or copy and paste url for wget to fetch
3) gpg --import < saved_file
4) rm saved_file, etc, etc.

and putting the keys onto keyservers would involve getting users to
check fingerprints, and distributing those fingerprints (agreed, checks
should always be made anyway, but in reality i cant see that happening).
making the keys available via finger means it will be simple to get any
keys into gpg from the command line on one line, eg:

$ finger klieber@gentoo.org | gpg --import

the user can be confident the key is really yours, and only one basic
command is required (you can test this with my key, my address is in my
.sig).

Also, should a developer revoke or regenerate a key, they would have to
contact someone with cvs access to the website to update it, with
fingerd they can just login (or scp) to dev.g.o and update the key 
themselves, which would take effect immediately. I am totally confident 
this is the simplest and best medium for distributing developer keys.

Thanks, Tavis.

-- 
-------------------------------------
taviso@sdf.lonestar.org | finger me for my gpg key.
-------------------------------------------------------

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Finger GLEP

[Grant Goodyear]

[-- Attachment #1: Type: text/plain, Size: 684 bytes --]

> 2) Tangental to the issue above, we've already talked about placing things
> like GPG keys on the web site in XML format and pulling the other info (dev
> name, location, projects, etc.) in via XML as well.  Why is the fingerd
> solution a better one?  Items on the web site are updated hourly.  I can't
> think of too many cases where that type of freshness isn't timely enough.

Speaking of which, there had also been talk of adding gpg keys,
etcetera, to each dev's ldap data.  I'm fairly agnostic about having
fingerd running, but I do agree that we should try to centralize that
data as much as possible.

Best,
g2boojum
-- 
Grant Goodyear <g2boojum@gentoo.org>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Finger GLEP

[Tavis Ormandy]

On Sun, Aug 10, 2003 at 04:36:56PM -0700, Seemant Kulleen wrote:
> I'm inclined to agree with Kurt here.  I don't know that we should be
> opening more ports than necessary, for starters, and I don't know that
> the benefits necessarily outweigh the risks here. 

Sure, running services you dont need is never a good idea, but crippling
a box to be extra paranoid about security is a shame.

Besides, finger is a mature protocol and the implementations available
are widely used by some of the most respected
developers/projects/universities out there, and installed by default on
many systems, (Slackware, fex.) Finger is also really simple, you can 
audit it in a few hours if you want to.

> The idea for the
> devrel dev/herd/project pages will be to have a uniform portal to all
> sorts of info.
> 

thats cool, but im certain keeping a .plan up to date will be easier
than updating a webpage, and distributing keys with finger couldnt be
simpler.

imho, running fingerd also says something about a project..UNIX
heritage, classic internet, and things like that :)

-- 
-------------------------------------
taviso@sdf.lonestar.org | finger me for my gpg key.
-------------------------------------------------------

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Finger GLEP

[Spider]

[-- Attachment #1: Type: text/plain, Size: 494 bytes --]

begin  quote
On Mon, 11 Aug 2003 00:17:30 +0000
Tavis Ormandy <taviso@gentoo.org> wrote:

I'm all in favour of enabling finger on dev.gentoo.org, Both for Keys
and .plan following. If somone wants to use a more web-spiffy front for
the same info its a simple task to reformat a textpage automagically to
html in a case such as this.



//Spider



-- 
begin  .signature
This is a .signature virus! Please copy me into your .signature!
See Microsoft KB Article Q265230 for more information.
end

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Finger GLEP

[Aron Griffis]

[-- Attachment #1: Type: text/plain, Size: 1360 bytes --]

I really like this idea for the following reasons:

1. Information about devs should be sourced from the devs home
   directory.  It means each dev can maintain their own data, and it
   avoids the problem of having a separate area of which devs need to be
   aware.  Using fingerd automatically meets this "requirement".

2. If we want to make dev information available on the web as well, it
   can easily be harvested (once per hour, as somebody mentioned the
   website is updated) from the dev's home dirs.

3. I agree with Tavis regarding the ease of using finger to lookup
   per-developer information such as gpg keys.  Using the web is not
   quick.

4. I think it would be fantastically easy to have a cvs project hosted
   in my home directory on dev.g.o with .plan etc. symlinks in the
   proper $HOME.  (For example $HOME/.plan -> $HOME/cvsroot/finger/plan).  
   This would allow me to have a finger project on my home workstation
   which I could then update whenever appropriate.

5. I believe that finger indicates the last time that the information
   presented was updated.  This makes it apparent whether a given dev's
   information is current.

It seems like a good (usable/maintainable/secure) solution to me, and as
Tavis has mentioned, it's already in use by a number of major open
source projects.

Aron

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Finger GLEP

[Paul de Vrieze]

> 2) Tangental to the issue above, we've already talked about placing
> things like GPG keys on the web site in XML format and pulling the other
> info (dev name, location, projects, etc.) in via XML as well.  Why is
> the fingerd solution a better one?  Items on the web site are updated
> hourly.  I can't think of too many cases where that type of freshness
> isn't timely enough.

To that respect, what do you think of adding a www.gentoo.org/raw
directory that servers up the raw xml without it first being processed by
axkit. This
would allow automatic systems to profit from the fact that our data is in
xml.

Paul

-- 
Paul de Vrieze
Researcher
Mail: pauldv@cs.kun.nl
Homepage: http://www.devrieze.net




--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Finger GLEP

[Paul de Vrieze]

Aron Griffis said:
> I really like this idea for the following reasons:
>
> 1. Information about devs should be sourced from the devs home
>    directory.  It means each dev can maintain their own data, and it
> avoids the problem of having a separate area of which devs need to be
> aware.  Using fingerd automatically meets this "requirement".
>

There are advantages and disadvantages. For pgp keys I personally believe
that this is not the way to go. In case a dev box gets rooted it is very
easy for a hacker to update a .gpgkey file, but if we would have an
authenticated and automated process changing the key in the ldap database
(through an easy to use script) that would increase security a lot while
still getting all the data at one place. I think the plan file can indeed
be sourced from a .plan file in the homedir. But a gpg in general hardly
gets updated, so a bit more formal access is waranted in this case.

I believe the choice has been made to centralize the developer database on
ldap. As such I believe that if we want to provide a finger service it
will need to be ldap aware and pull most information from ldap, and/or
other sources. For example for projects the current plan is to create
project.xml files containing information about the project. Including who
is part of the project. There is no final structure yet, but once we do
have it, it will be the definite authority on who works on which project.
I believe having people maintain seperate information in their homedirs is
not the way to go as it will lead to incomplete and inaccurate data, and
also diminishes the need for developers to keep the definite information
up to date. (Yes that means that I think the next version of the developer
list will be autogenerated)

> 2. If we want to make dev information available on the web as well, it
>    can easily be harvested (once per hour, as somebody mentioned the
> website is updated) from the dev's home dirs.
>
> 3. I agree with Tavis regarding the ease of using finger to lookup
>    per-developer information such as gpg keys.  Using the web is not
> quick.
>
I don't mind the use of finger as the retrieval protocol, but in this case
the server probably needs to be updated to get its information from other
sources.

>
> It seems like a good (usable/maintainable/secure) solution to me, and as
> Tavis has mentioned, it's already in use by a number of major open
> source projects.

Well, I see the use of finger as a protocol for information retrieval, but
I don't think that a standard fingerd will do the job. One way to do
things is to have a configuration file somewhere that specifies plugin
programs that supply the fingerd with information. What I mean is for
example the following:

/etc/fingerd/plugins:
getplan=/usr/gentoo/bin/getplan

and
"getplan pauldv" would then return my plan (by catting .plan from my homedir)
"getkey pauldv" though would get my key from the ldap server and would
output it to fingerd

Paul

-- 
Paul de Vrieze
Researcher
Mail: pauldv@cs.kun.nl
Homepage: http://www.devrieze.net




--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Finger GLEP

[Kurt Lieber]

[-- Attachment #1: Type: text/plain, Size: 3226 bytes --]

On Mon, Aug 11, 2003 at 12:02:10AM +0000 or thereabouts, Tavis Ormandy wrote:
> > What ensures that the data available via fingerd will be a) complete
> > (meaning how will you ensure all developers participate) and b) up-to-date?
> > IMO, we need to identify one master source of information and *ensure* that
> > is used and kept up-to-date.  If we want to provide multiple avenues to
> > access that info, that's fine, but we need one database, not multiple ones.
> 
> imho, if all developers just created a ~/.pgpkey the fingerd will be
> worth having (i'll explain below why i think this is the best medium for
> key distribution). 

You still haven't explained how we will ensure the data are up to date and
complete.  imo, this method of distribution is only useful if there is 100%
participation.  A cornerstone of your argument is that it's easy for the
user to "finger developer@gentoo.org" to get their key.  My point is that's
useless if they can't rely upon *always* being able to get that
information.

> making the keys available via the website is not ideal, getting it into
> a keyring involves a few steps, eg:
> 
> 1) fire up web browser, navigate to query page
> 2) enter dev name, and then copy and paste key into text
>    or copy and paste url for wget to fetch
> 3) gpg --import < saved_file
> 4) rm saved_file, etc, etc.

Or, you could just do:

wget http://keys.gentoo.org/devname.gpg

which would be trivially easy to set up.  We could even use mod_rewrite to
redirect that to a public keyserver relieving us from having to administer
anything locally.  (see below for why all keys will be on public
keyservers)

> and putting the keys onto keyservers would involve getting users to
> check fingerprints, and distributing those fingerprints (agreed, checks
> should always be made anyway, but in reality i cant see that happening).

Checks need to be mandatory and, afaik, are on the feature list to be built
into Portage.  Thus, keys *will* be on public keyservers and checks *will*
be made.

> making the keys available via finger means it will be simple to get any
> keys into gpg from the command line on one line, eg:
> 
> $ finger klieber@gentoo.org | gpg --import

or $ wget http://keys.gentoo.org/devname.gpg | gpg --import

My point is there are multiple 'easy' ways of accomplishing this task.
finger is not the only solution.

> Also, should a developer revoke or regenerate a key, they would have to
> contact someone with cvs access to the website to update it, with
> fingerd they can just login (or scp) to dev.g.o and update the key 
> themselves, which would take effect immediately. I am totally confident 
> this is the simplest and best medium for distributing developer keys.

No, if a dev needs to revoke a key, they need to send out a revocation and
yank it from all the keyservers.  Devs would still be able to do this
outside of cvs using the mod_rewrite example I mentioned above. 

Again, I am open to considering the idea of running fingerd as an alternate
means of transporting data, but at this point, I am not convinced that
storing things in /home directories is the right/best solution.  

--kurt

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Finger GLEP

[Tavis Ormandy]

On Mon, Aug 11, 2003 at 05:22:06AM -0400, Kurt Lieber wrote:
> On Mon, Aug 11, 2003 at 12:02:10AM +0000 or thereabouts, Tavis Ormandy wrote:
> > 
> > imho, if all developers just created a ~/.pgpkey the fingerd will be
> > worth having (i'll explain below why i think this is the best medium for
> > key distribution). 
> 
> You still haven't explained how we will ensure the data are up to date and
> complete.  imo, this method of distribution is only useful if there is 100%
> participation.  A cornerstone of your argument is that it's easy for the
> user to "finger developer@gentoo.org" to get their key.  My point is that's
> useless if they can't rely upon *always* being able to get that
> information.
> 

Well, however you choose to distribute keys theres the problem of
getting everybody to create one..thats hardly a huge issue, and the
problem exists for every method of distribution..using a keys.gentoo.org
webserver is still "rendered useless" if you cant get everybody to
generate and upload a key, how do you propose to deal with that?

imho, even if for some reason a developer decides not to upload a key,
the finger daemon will still provide information like last time mail was
received, last login, etc...still useful in my opinion.

> which would be trivially easy to set up.  We could even use mod_rewrite to
> redirect that to a public keyserver relieving us from having to administer
> anything locally.  (see below for why all keys will be on public
> keyservers)
> 

sure, im not disputing its possible, but distributing keys via http is
ugly imho.

> Checks need to be mandatory and, afaik, are on the feature list to be built
> into Portage.  Thus, keys *will* be on public keyservers and checks *will*
> be made.
> 

of course, but people will still want and need to add developer keys to
their personal keyrings. 

> > making the keys available via finger means it will be simple to get any
> > keys into gpg from the command line on one line, eg:
> > 
> > $ finger klieber@gentoo.org | gpg --import
> 
> or $ wget http://keys.gentoo.org/devname.gpg | gpg --import
> 
> My point is there are multiple 'easy' ways of accomplishing this task.
> finger is not the only solution.
> 

well, more like 

	$ wget -O - -q http://keys.gentoo.org/devname.gpg | gpg --import

and good luck getting people to remember that. surely you can
agree that accessing the key via finger (especially as the request is in
the form of an email address) is a much more elegant solution?

> Again, I am open to considering the idea of running fingerd as an alternate
> means of transporting data, but at this point, I am not convinced that
> storing things in /home directories is the right/best solution.  
> 
> --kurt

none of the issues apply solely to my solution, and im certain the
benefits outweigh the drawbacks.

-- 
-------------------------------------
taviso@sdf.lonestar.org | finger me for my gpg key.
-------------------------------------------------------

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Finger GLEP

[Tavis Ormandy]

On Mon, Aug 11, 2003 at 10:24:40AM +0200, Paul de Vrieze wrote:
> 
> There are advantages and disadvantages. For pgp keys I personally believe
> that this is not the way to go. In case a dev box gets rooted it is very
> easy for a hacker to update a .gpgkey file, but if we would have an
> authenticated and automated process changing the key in the ldap database
> (through an easy to use script) that would increase security a lot while
> still getting all the data at one place.

Thats no more secure than the finger solution, once a developer's box is
rooted, all bets are off. At this point the hacker can already trojan
gpg/ssh/whatever and harvest all the passphrases and key pairs he wants, 
rendering the gpg key useless.

> As such I believe that if we want to provide a finger service it
> will need to be ldap aware and pull most information from ldap, and/or
> other sources. For example for projects the current plan is to create
> project.xml files containing information about the project. Including who
> is part of the project.

maybe, but im a fan of the simplicity of finger. The name and location
is the standard information from the passwd file, and three plain text
files the dev can configure as they see fit. 

-- 
-------------------------------------
taviso@sdf.lonestar.org | finger me for my gpg key.
-------------------------------------------------------

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Finger GLEP

[Paul de Vrieze]

Tavis Ormandy said:
>
> well, more like
>
> 	$ wget -O - -q http://keys.gentoo.org/devname.gpg | gpg --import
>
> and good luck getting people to remember that. surely you can
> agree that accessing the key via finger (especially as the request is in
> the form of an email address) is a much more elegant solution?

No, more like gpg --search-keys devname@gentoo.org or
gpg --recv-keys <fingerprint>

Paul

-- 
Paul de Vrieze
Researcher
Mail: pauldv@cs.kun.nl
Homepage: http://www.devrieze.net




--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Finger GLEP

[Tavis Ormandy]

On Mon, Aug 11, 2003 at 02:37:39PM +0200, Paul de Vrieze wrote:
> 
> Tavis Ormandy said:
> >
> > well, more like
> >
> > 	$ wget -O - -q http://keys.gentoo.org/devname.gpg | gpg --import
> >
> 
> No, more like gpg --search-keys devname@gentoo.org or
> gpg --recv-keys <fingerprint>
> 
> Paul
> 

even more like, 

$ mozilla http://keys.gentoo.org/
<navigate to developers key page, copy and paste fingerprint>
$ gpg --search-keys devname@gentoo.org
<confirm fingerprint on key server matches key you received>

Anybody can publish a key to a keyserver, if your going to use that
method you still need to distribute fingerprints and key id's.

Yes, in a perfect world everybody would double check everything, but
thats not going to happen.

by using a finger server, users can be reasonably confident they are
getting the correct key.

I can see im not convincing you of this idea :) Thanks for your feedback 
though, very interesting.

-- 
-------------------------------------
taviso@sdf.lonestar.org | finger me for my gpg key.
-------------------------------------------------------

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Finger GLEP

[Kurt Lieber]

[-- Attachment #1: Type: text/plain, Size: 1746 bytes --]

On Mon, Aug 11, 2003 at 11:35:19AM +0000 or thereabouts, Tavis Ormandy wrote:
> Well, however you choose to distribute keys theres the problem of
> getting everybody to create one..thats hardly a huge issue, and the
> problem exists for every method of distribution..using a keys.gentoo.org
> webserver is still "rendered useless" if you cant get everybody to
> generate and upload a key, how do you propose to deal with that?

The efforts we have underway with secure portage will require developers to
have and maintain a GPG key.  It will also require them to place said key
on a public keyserver.  

> none of the issues apply solely to my solution, and im certain the
> benefits outweigh the drawbacks.

Well, at this point, I'm inclined to reject this GLEP and/or ask you to
re-work it to incorporate some of the changes suggested by myself and
others.  Specifically: 

* Data needs to be maintained in one central repository.  
* I'm not opposed to offering fingerd as a means of data transport, as long
  as it pulls data from the central repository mentioned above.
* I'd also be open to allowing devs the option of *supplementing* the
  information available via fingerd by creating a .plan or whatever.
  However, the core info (GPG key, name, herds info, etc.) needs to be
  maintained in the central repository.

Basically, I see the benefits of offering fingerd as a service to our users
and am willing to support that, infrastructure-wise.  I do not agree,
however, that fingerd should be the *primary* method of distributing this
info, nor do I support the idea of storing critical information such as GPG
keys in developer home dirs -- at least not as the primary "official"
repository.

--kurt

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Finger GLEP

[Tavis Ormandy]

On Mon, Aug 11, 2003 at 09:33:14AM -0400, Kurt Lieber wrote:
> 
> The efforts we have underway with secure portage will require developers to
> have and maintain a GPG key.  It will also require them to place said key
> on a public keyserver.  
> 

Cool, problem solved.

> Well, at this point, I'm inclined to reject this GLEP and/or ask you to
> re-work it to incorporate some of the changes suggested by myself and
> others.  Specifically: 
> 

Cool, it was just a proposal.

> * Data needs to be maintained in one central repository.  

I never meant to dispute this, i have no problem with storing
information wherever you like. The .plans, .projects and .pgpkeys in my
proposal would be a means of easily distributing pgpkeys (for _NON_
portage use, eg personal keyrings, encrypting emails, verifying patches, 
etc, etc), and presenting information for interested users that would be 
up to the developer to maintain, eg status updates, project activities, etc.

> * I'm not opposed to offering fingerd as a means of data transport, as long
>   as it pulls data from the central repository mentioned above.

Well, im not so keen on that idea, although not totally opposed if your
not open to discussion on it. 

The proposal was meant as a means for a developer to easily keep some 
information that applies to them personally, and their work on any 
projects, etc. And would be entirely up to them as to the format.

> * I'd also be open to allowing devs the option of *supplementing* the
>   information available via fingerd by creating a .plan or whatever.
>   However, the core info (GPG key, name, herds info, etc.) needs to be
>   maintained in the central repository.

This is essentially what i was proposing.

> Basically, I see the benefits of offering fingerd as a service to our users
> and am willing to support that, infrastructure-wise.  

Excellent!

> I do not agree, however, that fingerd should be the *primary* method of distributing this
> info.

I totally agree, and would not have proposed this.

> nor do I support the idea of storing critical information such as GPG
> keys in developer home dirs -- at least not as the primary "official"
> repository.

well, if by primary repository you mean where secure portage will obtain
the keys from, i dont mind that at all. The finger server in my proposal
would be for the benfit of users, and other developers, not a means of
implementing the improvements to portage.

-- 
-------------------------------------
taviso@sdf.lonestar.org | finger me for my gpg key.
-------------------------------------------------------

--
gentoo-dev@gentoo.org mailing list