On 03/29/11 22:51, Ron Wilson wrote: > On Tue, Mar 29, 2011 at 11:02 AM, Jan Danielsson > <[email protected]> wrote: >> The reason I used environment variables was that I couldn't figure >> out a good interface for managing certificates/keys. > > One option, which could also solve the password protected cert issue, > would be to do as some versions of SSH do: A seperate cert management > agent. The agent, when starting, would allow the user to specify which > certs to make available, prompting for passwords as needed, then would > background itself and use inter-process communications to receive and > respond to requests from client processes. (Naturally, you would want > the agent to terminate when the user logs out.)
Hmm.. I'm intrigued, but not completely convinced. An ssh/gpg:esque agent solves the issue of having to re-enter the password, which is obviously good if one does many operations within a short time-span over https, but I'm not sure it would be the proper tool to keep track of which certificates to associate with a particular project. It could obviously be used for it, but I think it'll lead to unnecessary complexity in the fossil code. To translate the environment variables to something which is more "fossilic", I'm currently thinking along the lines of adding a new sub-command "cert": $ fossil cert add myfoo --key ~/.certs/my.key --cert ~/.certs/my.crt --cafile ~/.certs/ca.crt Creates a "container" called "myfoo" which contains references to the client key, certificate and cafile as specified above. At this point it doesn't actually do anything apart from being stored in the global configuration. (Imagine ~ being expaned in the examples below). $ fossil cert list myfoo key=~/.certs/my.key cert=~/.certs/my.crt cafile=~/.certs/ca.crt Self-explanatory. Aim for easily machine-parsable output. $ fossil clone --cert myfoo https://foo.org/pub/proj proj.fossil [---] Every sub-command which takes an https url will support the "cert" operation, which points out a "container". When the cert-option is used, an association between the url and the cert container will automatically be added to the global configuration (or overwritten if one already exist). Next time foo.org is referenced via https, the association will be "invoked" and the myfoo "container" will be used. $ fossil cert disassociate https://repos.foo.org This will make sure that any ssl operations to http://repos.foo.org will no longer be fed the contents of myfoo. (Essentially, this is to cover the very odd case where a server first requires a client certificate, and at a later date doesn't, but the user wants to keep the "myfoo" container for other systems). $ fossil cert delete myfoo Will remove the "myfoo" container, and all associated url assocations. The major problem with the current environment variable solution is that there's no easy and logical way to remove an association which has previously been established, and removing caching would require the variables to be passed every time (or adding them to the shell's exported environment variables, but this could quickly become annoying if one switches between different repositories from different sources in the same shell (I know I do)). And adding a single sub-command specifically for removing an association seems overkill. The above system would allow users to only specify a cafile/capath, solving the problems described in ticket 727af73f46. Any obvious caveats I've missed? Would sticking it all in the global config table be okay, or would a new dedicated table for certificate management be preferable? >> Finally, a known limitation is that it doesn't support password >> protected client keys. This is on my ToDo-list. > See above. I'll start by adding a simple password callback (as supported by OpenSSL), and see how annoying it is to re-enter the password all the time. I suspect you're right though, so I'll start planning for an agent of some sort. Thanks for the feedback. -- Kind regards, Jan Danielsson
signature.asc
Description: OpenPGP digital signature
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
