On lun, dic 01, 2014 at 11:18:19 +0100, Tollef Fog Heen wrote: > > > Is this intentional, or is that a bug in either gnutls, curl, or the software > > > using these libraries? > > > > AFAICT this is due to the gnutls26 -> gnutls28 switch. Using libgnutls-dev to > > build curl instead of libgnutls28-dev makes it possible to point CURLOPT_CAINFO > > to a single leaf certificate and have the verification succeed. > > > > FWIW the current behaviour is the same with openssl. I don't know if there's a > > reason for it though. > > Can we get it reverted/fixed? If you are asking if curl is gonna go back to gnutls26, I don't think that's gonna happen. AFAICT it's not maintained upstream anymore and gnutls28 provides stuff like ECC support that's IMO more important. As for fixing it, you need to discuss this with the gnutls maintainers. > We consider it a security-related regression compared to wheezy and while we > could run private builds of the code on debian.org, that'd be pretty silly > (and a waste of manpower). What does "security-related regression" mean? (if anything this makes security checks tighter). The problem, I think, is that you provide curl (and thus gnutls) with a CA certificate that doesn't actually sign the end certificate of the site you are trying to connect to (even if the two are the same certificate). Again, I don't know if this is intended or not, you need to talk with the gnutls maintainers. Cheers
Attachment:
signature.asc
Description: Digital signature