Thanks for the feedback, I mis-worded when I said fixed. I am fully aware that it doesn't handle every case, the purpose was more to generate discussion about possible solutions and improve upon the patch until it is. My apologies for the miscommunication.
I'm unclear as to whether or not you have a more robust solution staged locally as you say you might have fixed it. If you do, I would be happy to test on what machines I have. I intend on fixing my windows machine today so that I can do testing there. If you have not, I will likely have some time today to attend to the issue and would not have any problem implementing such a candidate selection solution as you describe. I did already patch a local copy of fossil to suit my needs, but I'm not interested in maintaining any sort of fork for too long. I'm much more interested in seeing a robust solution make it into mainline - regardless of who produces such a solution or how it's implemented. Thanks, -B On Tue, Mar 23, 2010 at 11:09 AM, D. Richard Hipp <d...@hwaci.com> wrote: > > On Mar 23, 2010, at 1:59 PM, Brian Smith wrote: > >> Not to be impatient, just wanted to clarify that there is a patch to >> fix the issue described here. >> > > I don't really have a way of testing it. I set out trying to make > arrangements to test it over the weekend, but I ran out of time. I'm > currently engaged by more pressing matters. > > The patch is also incomplete - it only works for Debian and CentOS. > My SuSE system, for example, does not have a single certificate file > to hand over to SSL_CTX_load_verify_locations() interface. Instead, > you have to pass in a directory as the third argument. And the patch > has no provision for win32. How many other variations might be > lurking out there? > > I also prefer an approach where there is a list of candidate > certificate files and/or directories which we loop through until an > appropriate certificate file/directory is located. That would make it > much easier to add variations for new and different installations. I > might have entered such a change over the weekend, but I have no way > of testing it.... > > If you have to have a patched Fossil right away, clone the Fossil > repository and patch it yourself in your clone. I intend to > understand the problem better and work out a means of testing the > solution before I put it in the official tree. > >> -B >> >> On Sun, Mar 21, 2010 at 4:57 PM, Brian Smith <br...@linuxfood.net> >> wrote: >>> Hi All, >>> >>> With the patch from ticket >>> <http://www.fossil-scm.org/index.html/info/45f89e504b>, bare SSL >>> syncing now works properly with self-signed certificates. However, >>> Fossil doesn't load the system certificate store on Centos/linux (and >>> probably other *nix type platforms as well). Which means that if you >>> present a certificate signed by an external party (CAcert or >>> Verisign, >>> for example), fossil will fail the verification with >>> X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY which normally means >>> that >>> the list of trusted certificates is not complete [1]. >>> >>> There are few solutions to this problem. First, we could load the >>> system certificate store. >>> Though, that's not as simple as it sounds, since, there is no >>> standardized location across *nix distributions for the system store. >>> After just a quick survey, Centos stores them at >>> /etc/pki/tls/cert.pem, Debian stores them as a bundle in >>> /etc/ssl/certs/ca-certificates.crt (and that's generated from single >>> files under /usr/share/ca-certificates), FreeBSD stores them at >>> /usr/local/share/certs/ca-root-nss.crt, Arch appears to store them in >>> the same way as Debian, OpenSolaris doesn't even include any by >>> default. You get the idea. >>> The second solution is to prompt, or otherwise encourage the user to >>> manually specify the path to the certificate chain. This has the >>> advantage of maximum control, but may be a little "frightening" to >>> new/less savvy users. >>> >>> Probably the best solution is do some runtime detection and allow the >>> user to override if the auto detection doesn't work quite right. It's >>> probably even worthwhile to allow the user to manually load (via a >>> new >>> command? web ui?) certificates into the global fossil configuration >>> for those situations where they don't have the ability to modify the >>> system certificate store and/or don't want maintain their own >>> certificate bundle. >>> >>> I've attached a patch which does some simple detection of system >>> certificate stores. I've tested it on OS X (10.6), Centos 5.3, >>> Debian >>> 5.0, and FreeBSD 7.2. I need someone to test on Windows since my >>> Windows VM is broken at the moment. On OS X, we don't actually need >>> to >>> load the system or login stores since they appear to have patched >>> openssl to do that for us. >>> >>> [1] See manpage verify(1) from the openssl distribution. >>> >> <detect-platform- >> certs.patch>_______________________________________________ >> fossil-users mailing list >> fossil-users@lists.fossil-scm.org >> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > D. Richard Hipp > d...@hwaci.com > > > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
