Request for review: keychain

[Alexander Dalloz]

Am Mi, den 13.07.2005 schrieb Chip Turner um 18:24:

> > http://www.uni-x.org/keychain.sh.2.txt
> 
> Overall a good start!  But, this script is a bit complicated.  Some comments:

Thanks Chip! Though your words mean roughly "kick it to dust" ;>

> 1) The differentiation between rsa keys, dsa keys, and gpg keys is a
> bit unnecessary since they all end up on the command line anyway.

I would say that at least a differentiation is necessary between dsa +
rsa keys and gpg keys. Last ones need an additional tool (gpg-agent),
which is not (yet) part of Core, but in gnupg2 from Extras. And the gpg
keys has to be named by key ID number, while ssh keys can be loaded
simply from file names.

> 2) You can just use 'local FOO=""' instead of FOO="" and then worrying
> about unsetting FOO.
> 
> 3) Along with 2, you can have a 'set -u' that will require all vars
> declared, thus ensuring you don't end up with FOOs that need localing
> or unsetting that you didn't realize

2) and 3) noted.

> 4) It would be nicer if a user just doing 'touch ~/.keychainrc' would
> activate it.  Creating empty configs for users who don't know anything
> about keychain (maybe the admin just installed it for herself!) is
> confusing, especially since it isn't done silently.  Basically I'd
> personally rather it be 'if keychainrc exists, set some defaults that
> would load all the keys, then source the user's file letting them
> override our defaults' and not 'require multiple settings in user's
> config to have the system work properly'

I must confess that from there I am starting to fail to see what's the
user's gain or system's improvement from such kind of an opt-in. How
would the user know that he has to touch a ~/.keychainrc or even how and
which defaults to override? With respect to the said in 5) I can only
imagine that the user has to read a readme or man page. But then he will
be as quick to copy & paste the example code from "man 1 keychain"
(enhanced by Ville's patch) for the different shells into his
~/.bash_profile or ~/.login.

> 5) creating files in a user's homedir silently is naughty, esp for
> software they've never ever run.

I think thats debatable. There are so many hidden files and dirs
(.<file> | .<dir>) from programs / tools in the user's homedir which he
hardly all know about, and each (?) tools creates them silently.

> 6) The 'which keychain' is unnecessary since your script is part of
> the keychain rpm -- one goes with the other :)

Thats pretty correct :)

> 7) chmod'ing to 640 is bad if a user has a umask of 077, etc.

Thinking ... thinking ... can you please elaborate, Chip? You speak
about the case, where a user explicitly wants that files in his home can
not be read by the group? Would a "chmod 600" make things better or am I
misunderstanding your comment?

> 8) General scripting rule of thumb: when you nest four if loops deep,
> something else is probably wrong.

Don't want to be picky or to say my script suggestion is best you can
think of, but frankly /etc/profile.d/lang.sh isn't much less complicated
and has if I count correctly if clauses of 3 depth steps ;) And that
thumb rule would disqualify the keychain wrapper script itself.

> Chip

Finally my suggestion: Taking what I commented to point 4) I would drop
the idea of whatever kind of additional script and let the user, willing
to make use of keychain, copy & paste what he needs into his profile
file in home. He then certainly know if he wants to customize what keys
will be loaded automatically at login.

Alexander


-- 
 
1024D/866ED681 2005-07-11 Alexander Dalloz (Fedora Project) <alex at dalloz.de>
Key fingerprint = CD40 0A91 7814 C1E4 5940  8E0E 1FD5 C316 866E D681

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://listman.redhat.com/archives/fedora-extras-list/attachments/20050714/f2b21430/attachment.sig>