Description of problem: The default elinks configuration is insecure and renders SSL/TLS support practically useless. Please enable "connection.ssl.cert_verify" by default and accompany it with a huge fat warning for an user who would want to disable it. By the way, why is elinks linked with OpenSSL when the NSS patch is done? Version-Release number of selected component (if applicable): elinks-0.12-0.12.pre3.fc11.i586 Additional info: Originally reported here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510417 links package was patched to verify certificates upon its initial import.
(In reply to comment #0) > Description of problem: > > The default elinks configuration is insecure and renders SSL/TLS support > practically useless. > > Please enable "connection.ssl.cert_verify" by default and accompany it with a > huge fat warning for an user who would want to disable it. Thanks for the report, but I am afraid this feature is not implemented enough to be enabled by default. Have you tried to open a web page with an untrusted certificate? It just displays a big window with short text "SSL error" and button OK. There is no way to temporarily trust a certificate and no information about what exactly has failed. Moreover technically not skilled user doesn't know how to import certificates to NSS database. > By the way, why is elinks linked with OpenSSL when the NSS patch is done? Good catch. It seems like --without-openssl configure option is missing. I'll fix it tomorrow.
(In reply to comment #1) > (In reply to comment #0) > > Description of problem: > > > > The default elinks configuration is insecure and renders SSL/TLS support > > practically useless. > > > > Please enable "connection.ssl.cert_verify" by default and accompany it with a > > huge fat warning for an user who would want to disable it. > > Thanks for the report, but I am afraid this feature is not implemented enough > to be enabled by default. Have you tried to open a web page with an untrusted > certificate? It just displays a big window with short text "SSL error" and > button OK. There is no way to temporarily trust a certificate and no > information about what exactly has failed. Still much better that putting the user into risk of having his credit card number stolen. In fact, user should _not_ ever even temporarily accept a bad certificate. Even Firefox tries to discourage him from doing so by making the certificate accept procedure painful. > Moreover technically not skilled > user doesn't know how to import certificates to NSS database. Um, yes, see, I'm such user as well. System-wide NSS database in /etc/pki/nssdb should contain the root certificates and thus should serve sufficiently well as default? > > By the way, why is elinks linked with OpenSSL when the NSS patch is done? > > Good catch. It seems like --without-openssl configure option is missing. I'll > fix it tomorrow. Enabling connection.ssl.cert_verify warns me that I'm going to have to configure OpenSSL. It should probably mention NSS, if it is used.
> Good catch. It seems like --without-openssl configure option is missing. I'll > fix it tomorrow. Nope, it has been caused by bad BuildRequires. I removed the BuildRequire openssl-devel and added BuildRequires for krb5-devel, nss-devel and pkgconfig. Now it is fixed in CVS, but I am unable to build it because koji F-11 builds are completely broken right now. Ondra is going to solve the issue with the default value of "connection.ssl.cert_verify" tomorrow.
Default configuration file and certificate verification enabled by default should be done in elinks-0.12-0.14.pre3.fc12 ... F-11 fix could be best handled by 0day update I guess...
I've conducted some testing against elinks-0.12-0.15.pre3.fc12 and it seems to works perfectly. Please build it into dist-f11.
(In reply to comment #5) > I've conducted some testing against elinks-0.12-0.15.pre3.fc12 and it seems to > works perfectly. Please build it into dist-f11. F-11 build is ready: http://koji.fedoraproject.org/koji/buildinfo?buildID=100359 You can try to request a freeze override according to https://fedoraproject.org/wiki/ReleaseEngineering/FinalFreezePolicy But it is too late I think. If the request is rejected, then the build will be submitted as a post-release update. Please do not forget to test the package before requesting the freeze override.
Thanks Kamil. I've filed a pull-up ticket for Fedora 11: https://fedorahosted.org/rel-eng/ticket/1697
As the releng ticket is closed and F11 build tagged, closing RAWHIDE.