Hi Rémi,
On Tue, Oct 20, 2015 at 10:39:16AM +0200, Remi Gacogne wrote:
> Hi,
>
> On 10/19/2015 05:01 PM, Willy Tarreau wrote:
> >> [1] https://www.mail-archive.com/haproxy@formilux.org/msg19962.html
> >> [2] https://www.mail-archive.com/haproxy@formilux.org/msg19995.html
> >
> > Regarding the
Hi,
On 10/19/2015 05:01 PM, Willy Tarreau wrote:
>> [1] https://www.mail-archive.com/haproxy@formilux.org/msg19962.html
>> [2] https://www.mail-archive.com/haproxy@formilux.org/msg19995.html
>
> Regarding the second one, maybe Rémi's review could help. I noticed that
> you used
Le 19/10/2015 17:01, Willy Tarreau a écrit :
On Mon, Oct 19, 2015 at 03:06:44PM +0200, Christopher Faulet wrote:
OK so the unused objects in the tree have a refcount of 1 while the used
ones have 2 or more, thus the refcount is always valid. Good that also
means we must not test if the tree is
On Tue, Oct 20, 2015 at 02:14:37PM +0200, Christopher Faulet wrote:
> Le 20/10/2015 14:07, Willy Tarreau a écrit :
> >On Tue, Oct 20, 2015 at 01:59:52PM +0200, Willy Tarreau wrote:
> >>Then my understanding is that we should instead proceed differently :
> >> - the cert is generated. It gets a
On Tue, Oct 20, 2015 at 01:59:52PM +0200, Willy Tarreau wrote:
> Then my understanding is that we should instead proceed differently :
> - the cert is generated. It gets a refcount = 1.
> - we assign it to the SSL. Its refcount becomes two.
> - we try to insert it into the tree. The tree
Le 20/10/2015 14:07, Willy Tarreau a écrit :
On Tue, Oct 20, 2015 at 01:59:52PM +0200, Willy Tarreau wrote:
Then my understanding is that we should instead proceed differently :
- the cert is generated. It gets a refcount = 1.
- we assign it to the SSL. Its refcount becomes two.
- we
Hi Christopher,
On Tue, Oct 20, 2015 at 01:32:57PM +0200, Christopher Faulet wrote:
> >But then how do we know that an SSL_CTX is still in use when we want to
> >evict it from the cache and that we must not free it ? Is it just the
> >fact that between the moment it's picked from the cache using
On Tue, Oct 20, 2015 at 03:00:42PM +0200, Christopher Faulet wrote:
> Le 20/10/2015 14:41, Willy Tarreau a écrit :
> >On Tue, Oct 20, 2015 at 02:14:37PM +0200, Christopher Faulet wrote:
> >>Le 20/10/2015 14:07, Willy Tarreau a écrit :
> >>>On Tue, Oct 20, 2015 at 01:59:52PM +0200, Willy Tarreau
So I can confirm with your reproducer that it's OK now. I've merged
the proposed fix with copies of your long detailed analysis. Thanks
for being so patient to explain me :-)
We'll have to wait for the last pending DNS fixes and I'll emit 1.6.1
so that we get rid of these annoying early bugs.
Le 20/10/2015 14:41, Willy Tarreau a écrit :
On Tue, Oct 20, 2015 at 02:14:37PM +0200, Christopher Faulet wrote:
Le 20/10/2015 14:07, Willy Tarreau a écrit :
On Tue, Oct 20, 2015 at 01:59:52PM +0200, Willy Tarreau wrote:
Then my understanding is that we should instead proceed differently :
Hi Willy,
Le 16/10/2015 19:07, Willy Tarreau a écrit :
The SSL_CTX and SSL objects are reference-counted objects, so there is
no problem.
When a SSL_CTX object is created, its refcount is set to 1. When a SSL
connection use it, it is incremented and when the connection is closed,
it is
On Mon, Oct 19, 2015 at 03:06:44PM +0200, Christopher Faulet wrote:
> >OK so the unused objects in the tree have a refcount of 1 while the used
> >ones have 2 or more, thus the refcount is always valid. Good that also
> >means we must not test if the tree is null or not in ssl_sock_close(),
> >we
Hi Christopher,
sorry for the delay, I spent the whole day in meetings :-/
On Fri, Oct 16, 2015 at 11:42:38AM +0200, Christopher Faulet wrote:
> Le 16/10/2015 10:38, Willy Tarreau a écrit :
> >Thus this sparks a new question : when the cache is disabled, are we sure
> >to always free the ssl_ctx
Le 15/10/2015 16:55, Willy Tarreau a écrit :
Hi Christopher,
On Thu, Oct 15, 2015 at 03:22:52PM +0200, Christopher Faulet wrote:
Le 15/10/2015 14:45, Seri, Kim a écrit :
Christopher Faulet writes:
I confirm the bug. Here is a very quick patch. Could you confirm that it
works
Hi Christopher,
On Fri, Oct 16, 2015 at 10:03:06AM +0200, Christopher Faulet wrote:
> First the LRU tree is only initialized when the SSL certs generation is
> configured on a bind line. So, in the most of cases, it is NULL (it is
> not the same thing than empty).
> When the SSL certs
Hi Willy, Christopher,
> Ideally we'd have the info in the ssl_ctx itself, but I remember that Emeric
> told me a while ago that we couldn't store anything in an ssl_ctx. Thus I
> can understand that we can't easily "tag" the ssl_ctx as being statically
> or dynamically allocated, which is why I
Le 16/10/2015 10:38, Willy Tarreau a écrit :
Thus this sparks a new question : when the cache is disabled, are we sure
to always free the ssl_ctx on all error paths after it's generated ? Or
are we certain that we always pass through ssl_sock_close() ?
That's a good question. By greping on
Le 15/10/2015 10:51, Seri, Kim a écrit :
Hi, all
HAProxy 1.6.0 crashes in multiple certificates environment as belows,
bind :443 ssl crt test.com.pem crt test2.com.pem ecdhe prime256v1
but, in single certificate environment, haproxy doesn't crash.
bind :443 ssl crt test.com.pem ecdhe
Christopher Faulet writes:
> I confirm the bug. Here is a very quick patch. Could you confirm that it
> works for you ?
>
Hi,
I can confirm this patch fixes the crash!!
cf. because of my mail service, I've changed my e-mail
Thanks a lot.
Seri
Le 15/10/2015 14:45, Seri, Kim a écrit :
Christopher Faulet writes:
I confirm the bug. Here is a very quick patch. Could you confirm that it
works for you ?
Hi,
I can confirm this patch fixes the crash!!
cf. because of my mail service, I've changed my e-mail
Thanks a lot.
Hi Christopher,
On Thu, Oct 15, 2015 at 03:22:52PM +0200, Christopher Faulet wrote:
> Le 15/10/2015 14:45, Seri, Kim a écrit :
> >Christopher Faulet writes:
> >
> >>I confirm the bug. Here is a very quick patch. Could you confirm that it
> >>works for you ?
> >>
> >
> >Hi,
> >
> >I
21 matches
Mail list logo