On 03/16/11 00:37, Dmitry Chestnykh wrote: >> I figured out why no one is explaining to me how to specify >> which client certificate to use when connecting with https: Because >> fossil doesn't support it yet. :) > > You're right :-) > http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg04069.html
I promise I won't simply grep and extrapolate again. :) >> Our development server only allows fully verified certificate >> chains when connecting to it (with the exception of ssh); I added >> support for specifying a certificate and key file to my local fossil >> copy, and now I can properly access our repositories through https >> (via apache and cgi). However, it seems appropriate to implement this >> properly so that everyone can benefit from it. > > What's the user interface for specifying a certificate and key file? I just added hardcoded support for ~/.pki/clientkey.pem and ~/.pki/clientcrt.pem. To get that basic functionality, it's really as simple as adding two lines of code(!). However, as for how I'll implement the real solution; that's still open for discussion. As I figure, the two most "fossilic" solutions would be one of the two: 1) Store key/certificate (or reference to them) in the local datastore (_FOSSIL_) 2) Store key/certificate (or reference to them) in the global datastore (~/.fossil) Option 1 has a painfully obvious chicken-and-egg problem, as the certificate/key may be required to even get a clone of the repository. Also, conceptually, a client certificate is normally issued to a person, not a service. Therefore it makes much more sense to have a global certificate store of some kind (to identify the person who owns the home directory, rather than the specific repository). So my first goal is to add a command line interface (including a web gui interface?) to manage client certificates/keys, bundling them together into some named data entity in the global data store (~/.fossil). Then when a clone & open are performed, the user can - through a switch - choose which certificate entity to use to connect to the server. This information will be - through some magical means - stored in the local (_FOSSIL_) data store for future use (for push/pull/sync) after an open. I need to read up on ~/.fossil and _FOSSIL_ though to see if there's any risk of accidental information leak when pushing/pulling. The question is if the client key should be stored in the database, or if it's safer to store a reference to it instead, and keep the actual key outside (in the file system). Any input from seasoned fossil developers on this is much appreciated. > I don't use client certificates, but I agree that fossil should support them. Yeah; for some (like me) it's an actual requirement. On that note.. Planning a little bit further into the future here. Is anyone interested in "full" support for PKI in fossil? For instance, signing commits using a client key belonging to a certificate, adding means to distribute public certificates for purposes of verification, etc. The way the repo data can be sync'd could make it almost ideal for sharing certificates. And I would obviously add support for signing commits using smart cards (using PKCS#11). In the industry I work, web of trust signatures are not accepted. (I'm not saying this is right, but it's the way it is). In fact, smart cards are the only accepted mechanism for signing digital documents. I'm not saying that it's in any way implied that we'd get new users by supporting PKI, but it could open a door which is most definitely closed right now. Anyway, this is just some random brainstorming. If anyone sees any value in it, let me know. -- Kind regards, Jan Danielsson
signature.asc
Description: OpenPGP digital signature
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
