On 03/30/11 03:56, Ron Wilson wrote: > On Tue, Mar 29, 2011 at 7:41 PM, Jan Danielsson > <[email protected]> wrote: >> 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. > > I think your own proposal answers this question: > >> 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
Yes, well, I'm a firm believer of the philosophy that my initial ideas aren't perfect, so I'm looking for alternative ideas and/or (constructive) criticisms. :) I've implemented the basic "cert" subcommand in the jan-clientcert branch. It works more or less as I documented in my last mail. Please test and comment. See: $ fossil help cert It requires a new table in the global configuration database, and I'm not entirely sure how to conditionally add it, so to test it, either add it manually through the sqlite3 subcommand (see src/schema.c for the table definition) or temporarily move the original database out of the way: $ mv ~/.fossil ~/.fossil.orig ..then test the "fossil cert" commands. The basic idea is that there's a "certs" table like so: name | type | filepath --------+--------+--------------------- myfoo | ckey | /home/foo/.certs/my.key myfoo | ccert | /home/foo/.certs/my.crt myfoo | cafile | /etc/ssl/ca.crt This table defines a "credential group" (by name). These rows are added through the "fossil cert add" command. In global_config URL's are associated with the these credential groups by adding rows as: name | values ------------------------------+------------------ certgroup:repos.mycompany.com | myfoo These associations are displayed by the "cert list" command. And they will implicitly be created when the --cert <cert group> option is used with 'clone' or similar subcommand (this part isn't implemented yet). I'm tempted to move the server certificate cache to the "certs" table, since I feel it belongs there. These would then be added using a slightly different format: name | type | filepath --------------------+--------+--------------------- myfoo | ckey | /home/foo/.certs/my.key repos.mycompany.com | server | ---- BEGIN CERTIFICATE ----- Any objections to this change? The only effect it'll have on users of https is that they'll have to accept the server certificate again. And if they like to tidy up, they would clean up global_config with a sqlite3 command: DELETE FROM global_config WHERE name LIKE 'cert:%'; On a slight tangent: If someone where to add certificate verification to the fossil server mode in the future, one could use certificate groups to specify which certificates/crl's/keys to use. > Replace the file paths with cert and key IDs. Sorry, I don't understand what you mean. X509 certificates have a serial number, but the private key's don't. And since there's (unfortunately) no predefined location for these files the serial number is of no use on its own; one must specify the entire paths. Or did I completely misunderstand what you meant? > Now that you have mentioned it, it occurs to me that you might be able > to use gpg's agent. I'll look into if it's possible to hook into ssh-agent and/or gpg-agent. -- 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
