It looks like nothing got done about this :-(.
Is there any (GPL-compatible) TLS HTTP client library or tool in
jessie which allows me to specify explicitly the expected End Entity
certificate ?
At the moment I'm using curl and wget. I was using --cacert=blah
--capath=/dev/null and it did DTRT s
* Ian Jackson , 2014-12-05, 14:28:
But what about all the other callers of curl ? I'm thinking
particularly of LWP::UserAgent et al.
LWP::UserAgent doesn't use curl; it uses OpenSSL via IO::Socket:SSL.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a su
Tollef Fog Heen writes ("Re: curl and certificate verification in jessie"):
> ]] Daniel Kahn Gillmor
> > Unfortunately, this is quite a subtle API change, and it's not clear how
> > to do it safely or sanely.
>
> For curl, it sounds like a simple curl_set_
On Thu, 4 Dec 2014, Ian Jackson wrote:
> Each time you generate an EE key which you intend to use this way,
[…]
This assumes you can control the server key/cert you want to trust.
> Daniel Kahn Gillmor writes ("Re: curl and certificate verification in
> jessie"):
> >
]] Daniel Kahn Gillmor
> On 12/04/2014 10:41 AM, Ian Jackson wrote:
>
> > I'm not an expert on TLS but I was under the impression that this
> > behaviour - requiring that TLS authentication be done by a nontrivial
> > certificate chain - was specified by the standards (presumably X.509
> > rathe
Ian Jackson writes ("Re: curl and certificate verification in jessie"):
> Daniel Kahn Gillmor writes ("Re: curl and certificate verification in
> jessie"):
> > It seems to narrowly solve the case in question, but possibly at the
> > risk of making the semanti
Daniel Kahn Gillmor writes ("Re: curl and certificate verification in jessie"):
> It seems to narrowly solve the case in question, but possibly at the
> risk of making the semantics of the API even more confusing than it
> already is.
If they didn't want the API to be fu
On 12/04/2014 01:48 PM, Ian Jackson wrote:
> Daniel Kahn Gillmor writes ("Re: curl and certificate verification in
> jessie"):
>> So, the idea is that when you "accept" an EE cert, you need to do it
>> with an explicit associate to a specific peer'
Daniel Kahn Gillmor writes ("Re: curl and certificate verification in jessie"):
> So, the idea is that when you "accept" an EE cert, you need to do it
> with an explicit associate to a specific peer's name, not just the cert
> itself. newer versions of GnuTLS p
On 12/04/2014 10:41 AM, Ian Jackson wrote:
> I'm not an expert on TLS but I was under the impression that this
> behaviour - requiring that TLS authentication be done by a nontrivial
> certificate chain - was specified by the standards (presumably X.509
> rather than TLS). I could be wrong.
FWIW
Tollef Fog Heen writes ("Re: curl and certificate verification in jessie"):
> Ian Jackson:
> > Each time you generate an EE key which you intend to use this way,
> > also create an ad-hoc single-shot CA. Generate one EE certificate
> > using the CA, on the EE pu
]] Ian Jackson
> Tollef Fog Heen writes ("Re: curl and certificate verification in jessie"):
> > No, it doesn't necessarily. As dkg points out, I can no longer say
> > «this service should have this particular cert». This makes us
> > vulnerable to compromi
n TLS). I could be wrong.
Tollef Fog Heen writes ("Re: curl and certificate verification in jessie"):
> No, it doesn't necessarily. As dkg points out, I can no longer say
> «this service should have this particular cert». This makes us
> vulnerable to compromises of t
]] Alessandro Ghedini
> 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
> > > lib
On Mon, 1 Dec 2014, Alessandro Ghedini wrote:
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
buil
On 12/01/2014 01:50 PM, Alessandro Ghedini wrote:
> 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. Usin
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 o
[ not sure what's the point of CCing debian-devel, but I kept it. I removed Ian
from the chain though, since he hasn't been much involved with curl lately ]
On sab, nov 29, 2014 at 01:10:20 +0100, Peter Palfrader wrote:
> Hi,
>
> I recently started to move parts of debian.org's infrastructure to
Hi,
I recently started to move parts of debian.org's infrastructure to jessie. I
noticed a regression with software using curl to do https with certificate
verification.
On wheezy, this works:
| weasel@mipsel-manda-01:~$ cat /etc/apt/apt.conf.d/puppet-https-buildd
| Acquire::https::buildd.debia
19 matches
Mail list logo
