bugreport/feature request

[Janusz A. Urbanowicz]

> "Janusz A. Urbanowicz" <alex at bofh.torun.pl> writes:
> 
> > Splitting keyring option into keyring and additional-keyring. 
> 
> What I want to do is do check fro RO keyrings and don't update them at
> all. 

A good idea. But I'd suggest a possibility of _declaring_ a RO keyring.

> > be used. Key disabling (and revocation ?) should apply to both keyrings.
> 
> Disabling would work but revocations are a problem because the
> samllest entity the key management code handles is the keyblock and
> therefore we would have to copy the keyblock to a RW keyring and add
> the revocation there.
> 
> Things are getting too complicated.  The real way to handle the things
> you need is a local keyserver.  Thomas Roessler has a keyserver proxy
> which might be extented to fulfill your requirements (I guess you find
> it somewhere at ftp.mutt.org)

I'll have a look at it, tomorrow. But what I think a real solution would be
an alternative source for keys (additional to keyring[s]) that probably
should be LDAP based.

> > This option should be also settable in system-wide options file (in case
> > such a feature will ever exist). This way admins could keep system-wide
> 
> My opionion is that key distribution should be handled automagically
> and the user should not have to think about it.  This is the reason
> for removing the trust parameters from the keyrings.

I agree.

Maybe should I start to look at how to implement keyring-via-LDAP ? What do
you thing, guys'n'gals ?

Alex
-- 
   *   | Janusz A. "Alex" Urbanowicz,                 |  DSS: 1024/0x21939169
 --+~| | http://eris.phys.uni.torun.pl/~alex/         |  D-H: 2048/0xA2E48564
 \_|/  |                                              |_ RSA: 512/0xAB425659
   |   | WAR IS PEACE FREEDOM IS SLAVERY ERASE IS BACKSPACE -- rms