Re: haproxy -v doesn't show commit used when building from 2.0 repository?

[Willy Tarreau]

On Thu, Aug 01, 2019 at 08:41:22PM +0200, PiBa-NL wrote:
> Works for me, building latest commit in 2.0 repository now haproxy -v shows:
> "HA-Proxy version 2.0.3-7343c71 2019/08/01 - https://haproxy.org/; for me.
> Thanks for your quick fix :).

Ah great, thanks for confirming!
Willy

Re: haproxy -v doesn't show commit used when building from 2.0 repository?

[PiBa-NL]

Hi Willy,

Op 1-8-2019 om 6:21 schreef Willy Tarreau:

Hi Pieter,

On Wed, Jul 31, 2019 at 10:56:54PM +0200, PiBa-NL wrote:

Hi List,

I have build haproxy 2.0.3-0ff395c from sources however after running a
'haproxy -v' it shows up as: 'HA-Proxy version 2.0.3 2019/07/23 -
https://haproxy.org/' this isn't really correct imho as its a version based
on code committed on date 7/30. And i kinda expected the commit-id to be
part of the version shown?

I know what's happening, I always forget to do it with each new major
release. We're using Git attributes to automatically patch files
"SUBVERS" and "VERDATE" when creating the archive :

$ cat info/attributes
SUBVERS export-subst
VERDATE export-subst

And this is something I forget to re-create with each new repository,
I've fixed it now. It will be OK with new snapshots starting tomorrow.

Thanks!
Willy


Works for me, building latest commit in 2.0 repository now haproxy -v 
shows: "HA-Proxy version 2.0.3-7343c71 2019/08/01 - 
https://haproxy.org/; for me. Thanks for your quick fix :).


Regards,
PiBa-NL (Pieter)

Re: Recent BoringSSL build breakage

[Willy Tarreau]

On Thu, Aug 01, 2019 at 11:17:36AM +0200, Emmanuel Hocdet wrote:
> Yep, i already built with the change.  Fix included.

Now pushed, thank you! Let's hope all checks turn green now.

> I'm looking at BORINGSSL_API_VERSION for compatibility evolution, but for now
> is not incremented as i would expect.

I think it's only for major changes but not minor one. Ideally they
should start to use "#define foo foo" when they define something so that
it becomes possible for their users to do stuff like the following :

   #if defined(BORINGSSL) && !defined(foo)
   static inline foo()
   { 
blah();
   }
   #endif

Cheers,
Willy

Re: Coverity scans?

[Илья Шипицин]

also, I've no idea what to specify in COVERITY_SCAN_NOTIFICATION_EMAIL
(which is mandatory)

чт, 1 авг. 2019 г. в 12:32, Dinko Korunic :

> Hey Илья,
>
> Looks fine and clean. I guess that we would use existing project name
> (Haproxy) or you would like to continue with your own?
>
> Last, I wonder do we really need verbose (V=1) builds and do you think if
> they make sense for Coverity builds?
>
>
> Thanks,
> D.
>
> On 30 Jul 2019, at 10:35, Илья Шипицин  wrote:
>
> Dinko,
>
> please have a look
>
> https://github.com/chipitsine/haproxy/blob/coverity/.travis.yml#L37-L45
>
>
> what do you think (if we will move that to
> https://github.com/haproxy/haproxy) ?
>
> ср, 17 июл. 2019 г. в 16:36, Dinko Korunic :
>
>> Dear Илья,
>>
>> I’ve increased your access level to Contributor/Member. I terms of
>> Travis-CI scans, there are some catch22s with current Coverity suite as it
>> is compiled against ancient glibc and ancient kernel headers and
>> requires vsyscall=emulate kernel boot option to properly work — not sure if
>> that will be possible on Travis VMs at all.
>>
>> I have actual weekly builds that are auto-published to our Coverity Scan
>> account and they well, require manual interventions, flagging and some day
>> to day work to get to more usable levels — let me know if you need a hand
>> with this. You should have all the access required for doing so right now.
>>
>>
>> Kind regards,
>> D.
>>
>> On 17 Jul 2019, at 13:18, Илья Шипицин  wrote:
>>
>> Hello, yep, contributor/member would be nice. Also, I can setup automated
>> travis-ci scans
>>
>> On Wed, Jul 17, 2019, 3:27 PM Dinko Korunic 
>> wrote:
>>
>>> Hey Илья,
>>>
>>> Let me know if you would like Contributor/Member role for your account
>>> on Haproxy Coverity account. I was initially more involved and I have
>>> started configuring modules and parts of code blocks into coherent units,
>>> but stopped at some point due to lack of time and interest.
>>>
>>> There have been a lot of false positives however, I dare to say even in
>>> excessive volumes.
>>>
>>> > On 17 Jul 2019, at 07:48, Илья Шипицин  wrote:
>>> >
>>> > Hello, I played with Coverity. Definitely it shows "issues resolved"
>>> after bugfixes pushed to git. I know Willy does not like static analysis
>>> because of noise. Anyway, it finds bugs, why not to use it?
>>>
>>>
>>> Kind regards,
>>> D.
>>>
>>> --
>>> Dinko Korunic   ** Standard disclaimer applies **
>>> Sent from OSF1 osf1v4b V4.0 564 alpha
>>>
>>>
>>>
>> --
>> Dinko Korunic   ** Standard disclaimer applies **
>> Sent from OSF1 osf1v4b V4.0 564 alpha
>>
>>
>
> --
> Dinko Korunic   ** Standard disclaimer applies **
> Sent from OSF1 osf1v4b V4.0 564 alpha
>
>

Re: [PATCH] BUG/MAJOR: http/sample: use a static buffer for raw -> htx conversion

[Christopher Faulet]

Le 01/08/2019 à 06:17, Willy Tarreau a écrit :

Hi Richard,

On Wed, Jul 31, 2019 at 02:03:26PM -0700, Richard Russo wrote:

I've attached a patch to fix a bug in http sampling on raw connections. This
fixes crashes experienced with a frontend configuration similar to:

frontend haproxy_v4_http_0
   mode tcp
   bind ipv4@:80
   default_backend chat
   tcp-request inspect-delay 60s
   tcp-request content reject unless { req_len gt 0 }
   acl example_com req.hdr(host) -m str example.com
   acl example_org req.hdr(host) -m str example.org
   acl example_net req.hdr(host) -m str example.net
   acl chat path -m str /chat
   acl post method -m str POST
   use_backend chat if chat post # explicitly send chunked transfer encoded 
chat to chatd
   use_backend cdn if example_com
   use_backend cdn if example_org
   use_backend cdn if example_net

If the host header in inbound requests is not example.com, the check for
example.org will use the wrong trash buffer, and sometimes results in
crashes. I wasn't able to get a clear crash reproduction, but the call to
htx_get_next_blk() in src/http_htx.c:http_find_header would be called with
blk way out of range, and the loop will walk memory until it happens to find
an exit condition, or it reads unmapped memory and segfaults. Most often, it
seems the wrong trash buffer still has the old htx buffer, so it usually
doesn't crash.

I found the blk pointer was out of range in my core dumps, and added logging
in htx_get_next when pos > htx->tail; from there it was pretty easy to figure
out what happened.

I solved this by using a thread local static buffer for the raw buffer to htx
conversion, but there's probably other ways to fix it.


I think your patch is right. I'll let Christopher check it and merge it,
but indeed there's a problem here since buffers allocated using
get_trash_chunk() are just for local use and should never be passed
across functions since they will be reassigned.



It is good to me too. However, I will slightly amend it to use per-thread 
init/deinit callbacks. This way, valgrind lovers will not be hurt... or at 
least, not more than before :)


Thanks Richard !
--
Christopher Faulet

Re: Recent BoringSSL build breakage

[Emmanuel Hocdet]

Hi Willy,Le 1 août 2019 à 10:07, Willy Tarreau  a écrit :Hi Manu,On Travis CI there was a fairly recent regression on BoringSSL whichhappened between 03e09f3 and a7a0f99 a day ago. It breaks on definitionof EVP_PKEY_base_id() in openssl-compat.h, which was not modified, andI guess this issue was hidden by the simultaneous breakage of libresslby latest changes.It looks like latest BoringSSL now defines this function and that thedefinition above could be removed. Could you please have a look whenyou have a moment and possibly propose a patch so that we can fix thosebuild reports (especially if you find that other places need to betouched) ?For reference, first breakage :    https://travis-ci.com/haproxy/haproxy/builds/121281529Last known good build:    https://travis-ci.com/haproxy/haproxy/builds/121258130Yep, i already built with the change.  Fix included.I'm looking at BORINGSSL_API_VERSION for compatibility evolution, but for nowis not incremented as i would expect.// BORINGSSL_API_VERSION is a positive integer that increments as BoringSSL// changes over time. The value itself is not meaningful. It will be incremented// whenever is convenient to coordinate an API change with consumers. This will// not denote any special point in development. A consumer may use this symbol in the preprocessor to temporarily build// against multiple revisions of BoringSSL at the same time. It is not// recommended to do so for longer than is necessary.#define BORINGSSL_API_VERSION 9++Manu

0001-BUILD-ssl-BoringSSL-add-EVP_PKEY_base_id.patch
Description: Binary data

Re: Coverity scans?

[Илья Шипицин]

чт, 1 авг. 2019 г. в 12:32, Dinko Korunic :

> Hey Илья,
>
> Looks fine and clean. I guess that we would use existing project name
> (Haproxy) or you would like to continue with your own?
>

I would move to "haproxy/haproxy"
however, proper token must be set in travis-ci environment (if token is not
set, build is skipped)


>
> Last, I wonder do we really need verbose (V=1) builds and do you think if
> they make sense for Coverity builds?
>

I'll polish it for a few days and will submit a patch


>
>
> Thanks,
> D.
>
> On 30 Jul 2019, at 10:35, Илья Шипицин  wrote:
>
> Dinko,
>
> please have a look
>
> https://github.com/chipitsine/haproxy/blob/coverity/.travis.yml#L37-L45
>
>
> what do you think (if we will move that to
> https://github.com/haproxy/haproxy) ?
>
> ср, 17 июл. 2019 г. в 16:36, Dinko Korunic :
>
>> Dear Илья,
>>
>> I’ve increased your access level to Contributor/Member. I terms of
>> Travis-CI scans, there are some catch22s with current Coverity suite as it
>> is compiled against ancient glibc and ancient kernel headers and
>> requires vsyscall=emulate kernel boot option to properly work — not sure if
>> that will be possible on Travis VMs at all.
>>
>> I have actual weekly builds that are auto-published to our Coverity Scan
>> account and they well, require manual interventions, flagging and some day
>> to day work to get to more usable levels — let me know if you need a hand
>> with this. You should have all the access required for doing so right now.
>>
>>
>> Kind regards,
>> D.
>>
>> On 17 Jul 2019, at 13:18, Илья Шипицин  wrote:
>>
>> Hello, yep, contributor/member would be nice. Also, I can setup automated
>> travis-ci scans
>>
>> On Wed, Jul 17, 2019, 3:27 PM Dinko Korunic 
>> wrote:
>>
>>> Hey Илья,
>>>
>>> Let me know if you would like Contributor/Member role for your account
>>> on Haproxy Coverity account. I was initially more involved and I have
>>> started configuring modules and parts of code blocks into coherent units,
>>> but stopped at some point due to lack of time and interest.
>>>
>>> There have been a lot of false positives however, I dare to say even in
>>> excessive volumes.
>>>
>>> > On 17 Jul 2019, at 07:48, Илья Шипицин  wrote:
>>> >
>>> > Hello, I played with Coverity. Definitely it shows "issues resolved"
>>> after bugfixes pushed to git. I know Willy does not like static analysis
>>> because of noise. Anyway, it finds bugs, why not to use it?
>>>
>>>
>>> Kind regards,
>>> D.
>>>
>>> --
>>> Dinko Korunic   ** Standard disclaimer applies **
>>> Sent from OSF1 osf1v4b V4.0 564 alpha
>>>
>>>
>>>
>> --
>> Dinko Korunic   ** Standard disclaimer applies **
>> Sent from OSF1 osf1v4b V4.0 564 alpha
>>
>>
>
> --
> Dinko Korunic   ** Standard disclaimer applies **
> Sent from OSF1 osf1v4b V4.0 564 alpha
>
>

Re: [PATCH] BUG/MAJOR: http/sample: use a static buffer for raw -> htx conversion

[Christopher Faulet]

Le 01/08/2019 à 11:17, Christopher Faulet a écrit :

Le 01/08/2019 à 06:17, Willy Tarreau a écrit :

Hi Richard,

On Wed, Jul 31, 2019 at 02:03:26PM -0700, Richard Russo wrote:

I've attached a patch to fix a bug in http sampling on raw connections. This
fixes crashes experienced with a frontend configuration similar to:

frontend haproxy_v4_http_0
mode tcp
bind ipv4@:80
default_backend chat
tcp-request inspect-delay 60s
tcp-request content reject unless { req_len gt 0 }
acl example_com req.hdr(host) -m str example.com
acl example_org req.hdr(host) -m str example.org
acl example_net req.hdr(host) -m str example.net
acl chat path -m str /chat
acl post method -m str POST
use_backend chat if chat post # explicitly send chunked transfer encoded 
chat to chatd
use_backend cdn if example_com
use_backend cdn if example_org
use_backend cdn if example_net

If the host header in inbound requests is not example.com, the check for
example.org will use the wrong trash buffer, and sometimes results in
crashes. I wasn't able to get a clear crash reproduction, but the call to
htx_get_next_blk() in src/http_htx.c:http_find_header would be called with
blk way out of range, and the loop will walk memory until it happens to find
an exit condition, or it reads unmapped memory and segfaults. Most often, it
seems the wrong trash buffer still has the old htx buffer, so it usually
doesn't crash.

I found the blk pointer was out of range in my core dumps, and added logging
in htx_get_next when pos > htx->tail; from there it was pretty easy to figure
out what happened.

I solved this by using a thread local static buffer for the raw buffer to htx
conversion, but there's probably other ways to fix it.


I think your patch is right. I'll let Christopher check it and merge it,
but indeed there's a problem here since buffers allocated using
get_trash_chunk() are just for local use and should never be passed
across functions since they will be reassigned.



It is good to me too. However, I will slightly amend it to use per-thread
init/deinit callbacks. This way, valgrind lovers will not be hurt... or at
least, not more than before :)

Thanks Richard !



Merged now and backported to 2.0 and 1.9.

--
Christopher Faulet

Re: Coverity scans?

[Dinko Korunic]

Hi Илья,

Haproxy Coverity project token is: 9Zw8bB4a
Given that it’s per-project token, that can be hardcoded in TravisCI 
configuration without any issues.

In regards to notification mails, well for now I think that can have your and 
my mail for now until we think of something better. Willy, any suggestions 
here? Those mails which come from Coverity usually confirm a code submission 
for analysis, defect status changes and a state of defects for a current build.

Илья, given that you have been doing Coverity for extended periods of time in 
SoftEther projects, did you have any luck with custom Coverity Scan function 
models yet?


Kind regards,
D.


> On 1 Aug 2019, at 11:59, Илья Шипицин  wrote:
> 
> also, I've no idea what to specify in COVERITY_SCAN_NOTIFICATION_EMAIL (which 
> is mandatory)
> 
> чт, 1 авг. 2019 г. в 12:32, Dinko Korunic  >:
> Hey Илья,
> 
> Looks fine and clean. I guess that we would use existing project name 
> (Haproxy) or you would like to continue with your own?
> 
> Last, I wonder do we really need verbose (V=1) builds and do you think if 
> they make sense for Coverity builds?
> 
> 
> Thanks,
> D.
> 
>> On 30 Jul 2019, at 10:35, Илья Шипицин > > wrote:
>> 
>> Dinko,
>> 
>> please have a look
>> 
>> https://github.com/chipitsine/haproxy/blob/coverity/.travis.yml#L37-L45 
>> 
>> 
>> 
>> what do you think (if we will move that to 
>> https://github.com/haproxy/haproxy ) ?
>> 
>> ср, 17 июл. 2019 г. в 16:36, Dinko Korunic > >:
>> Dear Илья,
>> 
>> I’ve increased your access level to Contributor/Member. I terms of Travis-CI 
>> scans, there are some catch22s with current Coverity suite as it is compiled 
>> against ancient glibc and ancient kernel headers and requires 
>> vsyscall=emulate kernel boot option to properly work — not sure if that will 
>> be possible on Travis VMs at all.
>> 
>> I have actual weekly builds that are auto-published to our Coverity Scan 
>> account and they well, require manual interventions, flagging and some day 
>> to day work to get to more usable levels — let me know if you need a hand 
>> with this. You should have all the access required for doing so right now.
>> 
>> 
>> Kind regards,
>> D.
>> 
>>> On 17 Jul 2019, at 13:18, Илья Шипицин >> > wrote:
>>> 
>>> Hello, yep, contributor/member would be nice. Also, I can setup automated 
>>> travis-ci scans
>>> 
>>> On Wed, Jul 17, 2019, 3:27 PM Dinko Korunic >> > wrote:
>>> Hey Илья,
>>> 
>>> Let me know if you would like Contributor/Member role for your account on 
>>> Haproxy Coverity account. I was initially more involved and I have started 
>>> configuring modules and parts of code blocks into coherent units, but 
>>> stopped at some point due to lack of time and interest.
>>> 
>>> There have been a lot of false positives however, I dare to say even in 
>>> excessive volumes.
>>> 
>>> > On 17 Jul 2019, at 07:48, Илья Шипицин >> > > wrote:
>>> > 
>>> > Hello, I played with Coverity. Definitely it shows "issues resolved" 
>>> > after bugfixes pushed to git. I know Willy does not like static analysis 
>>> > because of noise. Anyway, it finds bugs, why not to use it?
>>> 
>>> 
>>> Kind regards,
>>> D.
>>> 
>>> -- 
>>> Dinko Korunic   ** Standard disclaimer applies **
>>> Sent from OSF1 osf1v4b V4.0 564 alpha
>>> 
>>> 
>> 
>> -- 
>> Dinko Korunic   ** Standard disclaimer applies **
>> Sent from OSF1 osf1v4b V4.0 564 alpha
>> 
>> 
> 
> -- 
> Dinko Korunic   ** Standard disclaimer applies **
> Sent from OSF1 osf1v4b V4.0 564 alpha
> 

-- 
Dinko Korunic   ** Standard disclaimer applies **
Sent from OSF1 osf1v4b V4.0 564 alpha

Re: Coverity scans?

[Илья Шипицин]

чт, 1 авг. 2019 г. в 15:23, Dinko Korunic :

> Hi Илья,
>
> Haproxy Coverity project token is: 9Zw8bB4a
> Given that it’s per-project token, that can be hardcoded in TravisCI
> configuration without any issues.
>
> In regards to notification mails, well for now I think that can have your
> and my mail for now until we think of something better. Willy, any
> suggestions here? Those mails which come from Coverity usually confirm a
> code submission for analysis, defect status changes and a state of defects
> for a current build.
>
> Илья, given that you have been doing Coverity for extended periods of time
> in SoftEther projects, did you have any luck with custom Coverity Scan
> function models yet?
>

I don't know how models could help.
personally, I see that after Willy does some "bug is fixed" commit,
Coverity reports "null pointer deerefence is resolved"
Coverity is very good in catching null pointer derefence (even if we do not
know how it might be exploited). Currently, haproxy has tens of them
unresolved.



>
>
> Kind regards,
> D.
>
>
> On 1 Aug 2019, at 11:59, Илья Шипицин  wrote:
>
> also, I've no idea what to specify in COVERITY_SCAN_NOTIFICATION_EMAIL
> (which is mandatory)
>
> чт, 1 авг. 2019 г. в 12:32, Dinko Korunic :
>
>> Hey Илья,
>>
>> Looks fine and clean. I guess that we would use existing project name
>> (Haproxy) or you would like to continue with your own?
>>
>> Last, I wonder do we really need verbose (V=1) builds and do you think if
>> they make sense for Coverity builds?
>>
>>
>> Thanks,
>> D.
>>
>> On 30 Jul 2019, at 10:35, Илья Шипицин  wrote:
>>
>> Dinko,
>>
>> please have a look
>>
>> https://github.com/chipitsine/haproxy/blob/coverity/.travis.yml#L37-L45
>>
>>
>> what do you think (if we will move that to
>> https://github.com/haproxy/haproxy) ?
>>
>> ср, 17 июл. 2019 г. в 16:36, Dinko Korunic :
>>
>>> Dear Илья,
>>>
>>> I’ve increased your access level to Contributor/Member. I terms of
>>> Travis-CI scans, there are some catch22s with current Coverity suite as it
>>> is compiled against ancient glibc and ancient kernel headers and
>>> requires vsyscall=emulate kernel boot option to properly work — not sure if
>>> that will be possible on Travis VMs at all.
>>>
>>> I have actual weekly builds that are auto-published to our Coverity Scan
>>> account and they well, require manual interventions, flagging and some day
>>> to day work to get to more usable levels — let me know if you need a hand
>>> with this. You should have all the access required for doing so right now.
>>>
>>>
>>> Kind regards,
>>> D.
>>>
>>> On 17 Jul 2019, at 13:18, Илья Шипицин  wrote:
>>>
>>> Hello, yep, contributor/member would be nice. Also, I can setup
>>> automated travis-ci scans
>>>
>>> On Wed, Jul 17, 2019, 3:27 PM Dinko Korunic 
>>> wrote:
>>>
 Hey Илья,

 Let me know if you would like Contributor/Member role for your account
 on Haproxy Coverity account. I was initially more involved and I have
 started configuring modules and parts of code blocks into coherent units,
 but stopped at some point due to lack of time and interest.

 There have been a lot of false positives however, I dare to say even in
 excessive volumes.

 > On 17 Jul 2019, at 07:48, Илья Шипицин  wrote:
 >
 > Hello, I played with Coverity. Definitely it shows "issues resolved"
 after bugfixes pushed to git. I know Willy does not like static analysis
 because of noise. Anyway, it finds bugs, why not to use it?


 Kind regards,
 D.

 --
 Dinko Korunic   ** Standard disclaimer applies **
 Sent from OSF1 osf1v4b V4.0 564 alpha



>>> --
>>> Dinko Korunic   ** Standard disclaimer applies **
>>> Sent from OSF1 osf1v4b V4.0 564 alpha
>>>
>>>
>>
>> --
>> Dinko Korunic   ** Standard disclaimer applies **
>> Sent from OSF1 osf1v4b V4.0 564 alpha
>>
>>
> --
> Dinko Korunic   ** Standard disclaimer applies **
> Sent from OSF1 osf1v4b V4.0 564 alpha
>
>

Re: Coverity scans?

[Dinko Korunic]

Hey Илья,

Looks fine and clean. I guess that we would use existing project name (Haproxy) 
or you would like to continue with your own?

Last, I wonder do we really need verbose (V=1) builds and do you think if they 
make sense for Coverity builds?


Thanks,
D.

> On 30 Jul 2019, at 10:35, Илья Шипицин  wrote:
> 
> Dinko,
> 
> please have a look
> 
> https://github.com/chipitsine/haproxy/blob/coverity/.travis.yml#L37-L45 
> 
> 
> 
> what do you think (if we will move that to https://github.com/haproxy/haproxy 
> ) ?
> 
> ср, 17 июл. 2019 г. в 16:36, Dinko Korunic  >:
> Dear Илья,
> 
> I’ve increased your access level to Contributor/Member. I terms of Travis-CI 
> scans, there are some catch22s with current Coverity suite as it is compiled 
> against ancient glibc and ancient kernel headers and requires 
> vsyscall=emulate kernel boot option to properly work — not sure if that will 
> be possible on Travis VMs at all.
> 
> I have actual weekly builds that are auto-published to our Coverity Scan 
> account and they well, require manual interventions, flagging and some day to 
> day work to get to more usable levels — let me know if you need a hand with 
> this. You should have all the access required for doing so right now.
> 
> 
> Kind regards,
> D.
> 
>> On 17 Jul 2019, at 13:18, Илья Шипицин > > wrote:
>> 
>> Hello, yep, contributor/member would be nice. Also, I can setup automated 
>> travis-ci scans
>> 
>> On Wed, Jul 17, 2019, 3:27 PM Dinko Korunic > > wrote:
>> Hey Илья,
>> 
>> Let me know if you would like Contributor/Member role for your account on 
>> Haproxy Coverity account. I was initially more involved and I have started 
>> configuring modules and parts of code blocks into coherent units, but 
>> stopped at some point due to lack of time and interest.
>> 
>> There have been a lot of false positives however, I dare to say even in 
>> excessive volumes.
>> 
>> > On 17 Jul 2019, at 07:48, Илья Шипицин > > > wrote:
>> > 
>> > Hello, I played with Coverity. Definitely it shows "issues resolved" after 
>> > bugfixes pushed to git. I know Willy does not like static analysis because 
>> > of noise. Anyway, it finds bugs, why not to use it?
>> 
>> 
>> Kind regards,
>> D.
>> 
>> -- 
>> Dinko Korunic   ** Standard disclaimer applies **
>> Sent from OSF1 osf1v4b V4.0 564 alpha
>> 
>> 
> 
> -- 
> Dinko Korunic   ** Standard disclaimer applies **
> Sent from OSF1 osf1v4b V4.0 564 alpha
> 
> 

-- 
Dinko Korunic   ** Standard disclaimer applies **
Sent from OSF1 osf1v4b V4.0 564 alpha

Recent BoringSSL build breakage

[Willy Tarreau]

Hi Manu,

On Travis CI there was a fairly recent regression on BoringSSL which
happened between 03e09f3 and a7a0f99 a day ago. It breaks on definition
of EVP_PKEY_base_id() in openssl-compat.h, which was not modified, and
I guess this issue was hidden by the simultaneous breakage of libressl
by latest changes.

It looks like latest BoringSSL now defines this function and that the
definition above could be removed. Could you please have a look when
you have a moment and possibly propose a patch so that we can fix those
build reports (especially if you find that other places need to be
touched) ?

For reference, first breakage :
https://travis-ci.com/haproxy/haproxy/builds/121281529

Last known good build:
https://travis-ci.com/haproxy/haproxy/builds/121258130

Thanks,
Willy

Re: Coverity scans?

[Tim Düsterhus]

Dinko,

Am 01.08.19 um 12:20 schrieb Dinko Korunic:
> Haproxy Coverity project token is: *snip*
> Given that it’s per-project token, that can be hardcoded in TravisCI 
> configuration without any issues.

I'm not sure if the token is meant to kept secret, but I wanted to let
you know that you sent it to the public mailing list.

Best regards
Tim Düsterhus