Re: [PATCH] BUG/MINOR: ssl: fix 0-RTT for BoringSSL

[Olivier Houchard]

On Wed, Aug 07, 2019 at 03:09:26PM +0200, Emmanuel Hocdet wrote:
> Hi,
> 
> Two patches to fix (and simplify) 0-RTT for BoringSSL.
> If you can consider them.
> 
> ++
> Manu
> 

Applied, thanks !

Olivier

[PATCH] BUG/MINOR: Fix prometheus '# TYPE' and '# HELP' headers

[Anthonin Bonnefoy]

From: Anthonin Bonnefoy 

Prometheus protocol defines HELP and TYPE as a token after the '#' and
the space after the '#' is necessary.
This is expected in the prometheus python client for example
(https://github.com/prometheus/client_python/blob/a8f5c80f651ea570577c364203e0edbef67db727/prometheus_client/parser.py#L194)
and the missing space is breaking the parsing of metrics' type.
---
 contrib/prometheus-exporter/service-prometheus.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/contrib/prometheus-exporter/service-prometheus.c 
b/contrib/prometheus-exporter/service-prometheus.c
index 67914f602..9b9ef2ea8 100644
--- a/contrib/prometheus-exporter/service-prometheus.c
+++ b/contrib/prometheus-exporter/service-prometheus.c
@@ -1126,11 +1126,11 @@ static int promex_dump_metric_header(struct appctx 
*appctx, struct htx *htx,
types = promex_st_metric_types;
}
 
-   if (istcat(out, ist("#HELP "), max) == -1 ||
+   if (istcat(out, ist("# HELP "), max) == -1 ||
istcat(out, name, max) == -1 ||
istcat(out, ist(" "), max) == -1 ||
istcat(out, desc[appctx->st2], max) == -1 ||
-   istcat(out, ist("\n#TYPE "), max) == -1 ||
+   istcat(out, ist("\n# TYPE "), max) == -1 ||
istcat(out, name, max) == -1 ||
istcat(out, ist(" "), max) == -1 ||
istcat(out, types[appctx->st2], max) == -1 ||
-- 
2.19.1

PATCH: save some electricity on travis-ci (run non mainstream builds only daily)

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

Hello,

please find attached patch.


Thanks!
Ilya Shipitsin
From 4331513404b73b760e0095b09893a226bd30b574 Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin 
Date: Wed, 7 Aug 2019 18:51:24 +0500
Subject: [PATCH] BUILD: travis-ci: trigger non-mainstream configurations only
 on daily builds. Let us save some electricity of Travis-CI

---
 .travis.yml | 24 
 1 file changed, 8 insertions(+), 16 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index bf4e9d3cd..a65662496 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -22,14 +22,10 @@ cache:
 
 matrix:
   include:
-  - os: linux
-if: type != cron
-compiler: gcc
-env: TARGET=linux-glibc FIFTYONEDEGREES_SRC="contrib/51d/src/trie"
   - os: linux-ppc64le
-if: type != cron
+if: type == cron
 compiler: gcc
-env: TARGET=linux-glibc OPENSSL_VERSION=1.1.1c LABEL="linux-ppc64le"
+env: TARGET=linux-glibc OPENSSL_VERSION=1.0.2r LABEL="linux-ppc64le"
   - os: linux
 if: type != cron
 compiler: clang
@@ -45,27 +41,23 @@ matrix:
   curl -s "https://scan.coverity.com/scripts/travisci_build_coverity_scan.sh; | bash || true
 fi
   - os: linux
-if: type != cron
-compiler: clang
-env: TARGET=linux-glibc OPENSSL_VERSION=1.1.0j
-  - os: linux
-if: type != cron
+if: type == cron
 compiler: clang
-env: TARGET=linux-glibc OPENSSL_VERSION=1.0.2r
+env: TARGET=linux-glibc OPENSSL_VERSION=1.1.0j FIFTYONEDEGREES_SRC="contrib/51d/src/trie"
   - os: linux
 if: type != cron
 compiler: clang
 env: TARGET=linux-glibc LIBRESSL_VERSION=2.9.2
   - os: linux
-if: type != cron
+if: type == cron
 compiler: clang
 env: TARGET=linux-glibc LIBRESSL_VERSION=2.8.3
   - os: linux
-if: type != cron
+if: type == cron
 compiler: clang
 env: TARGET=linux-glibc LIBRESSL_VERSION=2.7.5 EXTRA_OBJS="contrib/prometheus-exporter/service-prometheus.o"
   - os: linux
-if: type != cron
+if: type == cron
 compiler: clang
 env: TARGET=linux-glibc BORINGSSL=yes
   - os: linux
@@ -77,7 +69,7 @@ matrix:
 compiler: clang
 env: TARGET=osx FLAGS="USE_OPENSSL=1" OPENSSL_VERSION=1.1.1c
   - os: windows
-if: type != cron
+if: type == cron
 install:
   - choco install bash make libssl-devel cygwin-devel gcc-core libgcc1 binutils lua-devel libpcre-devel zlib-devel --source cygwin
 script:
-- 
2.20.1

Re: patch: enable Coverity scan in travis-ci builds

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

ср, 7 авг. 2019 г. в 13:45, Willy Tarreau :

> On Wed, Aug 07, 2019 at 01:15:28PM +0500,  ??? wrote:
> > btw, Willy, we can exclude some exotic build targets from "on push" to
> "on
> > cron"
> >
> > by changing "if: type != cron" --> "if: type == cron"
> >
> >
> > probably boringssl, cygwin, libressl ?
>
> I indeed think that all non-latest and non-mainstream versions could be
> daily only. I'm probably fine with keeping the latest libressl as it
> significantly increases coverage. Thus we could keep something like this
> "on push" :
>
>   - linux-glibc with threads+openssl 1.1.1 on x86 + gcc
>

I would leave this one with clang. We run ASAN on clang builds.
I will revisit this after I get running gcc with sanitizers (it does not
work as expected on travis-ci)



>   - linux-glibc with threads+libressl 2.9.2 on x86 + clang
>   - linux-glibc without SSL nor threads on x86 + clang or gcc (no
> preference)
>   - osx with openssl-1.1.1 + clang
>
> And these ones would be "on cron" :
>   - linux-ppc64le
>   - linux + openssl-1.1.0
>   - linux + openssl-1.0.2
>   - linux + libressl-2.8.3
>   - linux + libressl-2.7.5
>   - linux + boringssl
>   - linux+51d/tree
>   - cygwin
>
> Note that some variants could be combined to save on builds. For example
> we can have linux-ppc64le build with openssl-1.0.2 to test the two at once,
> and linux+openssl-1.1.0 test with 51d/tree. In practice we don't need the
> level of detail indicating what broke, we just need to know if we broke
> anything, so heavy combinations are welcome.
>
> Just my two cents,
> Willy
>

Re: [cache] allow caching of OPTIONS request

[Baptiste]

On Wed, Aug 7, 2019 at 3:18 PM William Lallemand 
wrote:

> On Wed, Aug 07, 2019 at 12:38:05PM +0200, Baptiste wrote:
> > Hi there,
> >
> > Please find in attachement a couple of patches to allow caching responses
> > to OPTIONS requests, used in CORS pattern.
> > In modern API where CORS is applied, there may be a bunch of OPTIONS
> > requests coming in to the API servers, so caching these responses will
> > improve API response time and lower the load on the servers.
> > Given that HAProxy does not yet support the Vary header, this means this
> > feature is useful in a single case, when the server send the following
> > header "set access-control-allow-origin: *".
> >
> > William, can you check if my patches look correct, or if this is totally
> > wrong and then I'll open an issue on github for tracking this one.
> >
>
> Looks good to me, pushed in master.
>
> --
> William Lallemand
>

Great, thanks!

Baptiste

Re: [cache] allow caching of OPTIONS request

[William Lallemand]

On Wed, Aug 07, 2019 at 12:38:05PM +0200, Baptiste wrote:
> Hi there,
> 
> Please find in attachement a couple of patches to allow caching responses
> to OPTIONS requests, used in CORS pattern.
> In modern API where CORS is applied, there may be a bunch of OPTIONS
> requests coming in to the API servers, so caching these responses will
> improve API response time and lower the load on the servers.
> Given that HAProxy does not yet support the Vary header, this means this
> feature is useful in a single case, when the server send the following
> header "set access-control-allow-origin: *".
> 
> William, can you check if my patches look correct, or if this is totally
> wrong and then I'll open an issue on github for tracking this one.
> 

Looks good to me, pushed in master.

-- 
William Lallemand

[PATCH] BUG/MINOR: ssl: fix 0-RTT for BoringSSL

[Emmanuel Hocdet]

Hi,

Two patches to fix (and simplify) 0-RTT for BoringSSL.
If you can consider them.

++
Manu



0001-BUG-MINOR-ssl-fix-0-RTT-for-BoringSSL.patch
Description: Binary data


0002-MINOR-ssl-ssl_fc_has_early-should-work-for-BoringSSL.patch
Description: Binary data

Re: [cache] allow caching of OPTIONS request

[Baptiste]

Hi Vincent,

HAProxy does not follow the max-age in the Cache-Control anyway.
Here is what the configuration would look like:

backend X
  http-request cache-use cors if METH_OPTIONS
  http-response cache-store cors if METH_OPTIONS

cache cors
 total-max-size 64
 max-object-size 1024
 max-age 60

You see, the time the object will be cached by HAProxy is defined in your
cache storage bucket.

Baptiste




On Wed, Aug 7, 2019 at 1:47 PM GALLISSOT VINCENT 
wrote:

> Hi there,
>
>
> May I add that, in the CORS implementation, there is a specific header
> used for the caching duration: *Access-Control-Max-Age*
>
> This header is supported by most of browsers and its specification is
> available : https://fetch.spec.whatwg.org/#http-access-control-max-age
>
> One would think of using this header value instead of the well known
> Cache-Control header when dealing with CORS and OPTIONS requests.
>
> Cheers,
> Vincent
>
> --
> *De :* Baptiste 
> *Envoyé :* mercredi 7 août 2019 12:38
> *À :* HAProxy; William Lallemand
> *Objet :* [cache] allow caching of OPTIONS request
>
> Hi there,
>
> Please find in attachement a couple of patches to allow caching responses
> to OPTIONS requests, used in CORS pattern.
> In modern API where CORS is applied, there may be a bunch of OPTIONS
> requests coming in to the API servers, so caching these responses will
> improve API response time and lower the load on the servers.
> Given that HAProxy does not yet support the Vary header, this means this
> feature is useful in a single case, when the server send the following
> header "set access-control-allow-origin: *".
>
> William, can you check if my patches look correct, or if this is totally
> wrong and then I'll open an issue on github for tracking this one.
>
> Baptiste
>

RE: [cache] allow caching of OPTIONS request

[GALLISSOT VINCENT]

Hi there,


May I add that, in the CORS implementation, there is a specific header used for 
the caching duration: Access-Control-Max-Age

This header is supported by most of browsers and its specification is available 
: https://fetch.spec.whatwg.org/#http-access-control-max-age

One would think of using this header value instead of the well known 
Cache-Control header when dealing with CORS and OPTIONS requests.

Cheers,
Vincent


De : Baptiste 
Envoyé : mercredi 7 août 2019 12:38
À : HAProxy; William Lallemand
Objet : [cache] allow caching of OPTIONS request

Hi there,

Please find in attachement a couple of patches to allow caching responses to 
OPTIONS requests, used in CORS pattern.
In modern API where CORS is applied, there may be a bunch of OPTIONS requests 
coming in to the API servers, so caching these responses will improve API 
response time and lower the load on the servers.
Given that HAProxy does not yet support the Vary header, this means this 
feature is useful in a single case, when the server send the following header 
"set access-control-allow-origin: *".

William, can you check if my patches look correct, or if this is totally wrong 
and then I'll open an issue on github for tracking this one.

Baptiste

[cache] allow caching of OPTIONS request

[Baptiste]

Hi there,

Please find in attachement a couple of patches to allow caching responses
to OPTIONS requests, used in CORS pattern.
In modern API where CORS is applied, there may be a bunch of OPTIONS
requests coming in to the API servers, so caching these responses will
improve API response time and lower the load on the servers.
Given that HAProxy does not yet support the Vary header, this means this
feature is useful in a single case, when the server send the following
header "set access-control-allow-origin: *".

William, can you check if my patches look correct, or if this is totally
wrong and then I'll open an issue on github for tracking this one.

Baptiste
From b1ed59901522dc32fa112e77c93c9a723ecc2189 Mon Sep 17 00:00:00 2001
From: Baptiste Assmann 
Date: Wed, 7 Aug 2019 12:24:36 +0200
Subject: [PATCH 2/2] MINOR: http: allow caching of OPTIONS request

Allow HAProxy to cache responses to OPTIONS HTTP requests.
This is useful in the use case of "Cross-Origin Resource Sharing" (cors)
to cache CORS responses from API servers.

Since HAProxy does not support Vary header for now, this would be only
useful for "access-control-allow-origin: *" use case.
---
 src/cache.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/src/cache.c b/src/cache.c
index 5b4062384..001532651 100644
--- a/src/cache.c
+++ b/src/cache.c
@@ -560,8 +560,8 @@ enum act_return http_action_store_cache(struct act_rule *rule, struct proxy *px,
 	if (!(txn->req.flags & HTTP_MSGF_VER_11))
 		goto out;
 
-	/* cache only GET method */
-	if (txn->meth != HTTP_METH_GET)
+	/* cache only GET or OPTIONS method */
+	if (txn->meth != HTTP_METH_GET && txn->meth != HTTP_METH_OPTIONS)
 		goto out;
 
 	/* cache key was not computed */
@@ -1058,6 +1058,9 @@ int sha1_hosturi(struct stream *s)
 	ctx.blk = NULL;
 
 	switch (txn->meth) {
+	case HTTP_METH_OPTIONS:
+		chunk_memcat(trash, "OPTIONS", 7);
+		break;
 	case HTTP_METH_HEAD:
 	case HTTP_METH_GET:
 		chunk_memcat(trash, "GET", 3);
@@ -1093,10 +1096,10 @@ enum act_return http_action_req_cache_use(struct act_rule *rule, struct proxy *p
 	struct cache_flt_conf *cconf = rule->arg.act.p[0];
 	struct cache *cache = cconf->c.cache;
 
-	/* Ignore cache for HTTP/1.0 requests and for requests other than GET
-	 * and HEAD */
+	/* Ignore cache for HTTP/1.0 requests and for requests other than GET,
+	 * HEAD and OPTIONS */
 	if (!(txn->req.flags & HTTP_MSGF_VER_11) ||
-	(txn->meth != HTTP_METH_GET && txn->meth != HTTP_METH_HEAD))
+	(txn->meth != HTTP_METH_GET && txn->meth != HTTP_METH_HEAD && txn->meth != HTTP_METH_OPTIONS))
 		txn->flags |= TX_CACHE_IGNORE;
 
 	http_check_request_for_cacheability(s, >req);
-- 
2.17.1

From e3aee8fe302e108e2652842f537dc850978d2e59 Mon Sep 17 00:00:00 2001
From: Baptiste Assmann 
Date: Mon, 5 Aug 2019 16:55:32 +0200
Subject: [PATCH 1/2] MINOR: http: add method to cache hash

Current HTTP cache hash contains only the Host header and the url path.
That said, request method should also be added to the mix to support
caching other request methods on the same URL. IE GET and OPTIONS.
---
 src/cache.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/src/cache.c b/src/cache.c
index 9cef0cab6..5b4062384 100644
--- a/src/cache.c
+++ b/src/cache.c
@@ -1041,9 +1041,9 @@ enum act_parse_ret parse_cache_store(const char **args, int *orig_arg, struct pr
 	return ACT_RET_PRS_OK;
 }
 
-/* This produces a sha1 hash of the concatenation of the first
- * occurrence of the Host header followed by the path component if it
- * begins with a slash ('/'). */
+/* This produces a sha1 hash of the concatenation of the HTTP method,
+ * the first occurrence of the Host header followed by the path component
+ * if it begins with a slash ('/'). */
 int sha1_hosturi(struct stream *s)
 {
 	struct http_txn *txn = s->txn;
@@ -1056,6 +1056,16 @@ int sha1_hosturi(struct stream *s)
 
 	trash = get_trash_chunk();
 	ctx.blk = NULL;
+
+	switch (txn->meth) {
+	case HTTP_METH_HEAD:
+	case HTTP_METH_GET:
+		chunk_memcat(trash, "GET", 3);
+		break;
+	default:
+		return 0;
+	}
+
 	if (!http_find_header(htx, ist("Host"), , 0))
 		return 0;
 	chunk_memcat(trash, ctx.value.ptr, ctx.value.len);
-- 
2.17.1

Re: patch: enable Coverity scan in travis-ci builds

[Dinko Korunic]

Hi,

This has been disabled as soon as we have started testing out Travis-CI 
integration with Coverity, so we are all good.
Cheers!


Kind regards,
D.

> On 7 Aug 2019, at 09:50, Илья Шипицин  wrote:
> 
> Dinko, can you please disable your schedule (is it cron or whatever) ?
> 
> ср, 7 авг. 2019 г. в 12:07, Willy Tarreau mailto:w...@1wt.eu>>:
> Hi Ilya,
> 
> On Tue, Aug 06, 2019 at 10:55:47AM +0500,  ??? wrote:
> > 1) follow to https://travis-ci.com/haproxy/haproxy/settings 
> > 
> > 
> > 
> > 2) setup COVERITY_SCAN_TOKEN = P6rHpv1618gwKWkVs7FfKQ
> > 
> > 3) setup daily schedule
> 
> All done now (with Dinko's new token). Thanks very much for the
> screenshot, it did help me.
> 
> Let's see how it goes now. It says it's scheduled in about a minute.
> 
> Willy

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

Re: [ANNOUNCE] haproxy-2.0.4

[Aleksandar Lazic]

Am 06.08.2019 um 17:56 schrieb Willy Tarreau:
> Hi,
> 
> HAProxy 2.0.4 was released on 2019/08/06. It added 30 new commits after
> version 2.0.3.
> 
> This release mainly addresses a thread deadlock issue in the queue
> management, a significant number of H2 issues, and the usual lot of htx,
> stream, lua and check fixes.
> 
> When working on Patrick Hemmer's bug reported a month ago (thanks Patrick
> for all your traces by the way) I had a fairly long head scratching, trying
> to figure how such impossible stuff could be present in the traces, until I
> started to build a nice collection of fixes for various small bugs which
> very likely explain a number of remaining issues people have been facing on
> HTTP/2 namely on gRPC, as well as what Luke noticed with his map server. So
> the opportunity was too great to produce a new version and wipe all these
> problems at once from possible candidates for future bug reports. I've
> spent so much time on this ones that I simply don't remember what the other
> ones were about, but the changelog will help.
> 
> I'd suggest that anyone using HTTP/2 or having had a bad experience with
> it (particularly with spurious resets or with stalled transfers) gives 2.0.4
> a try.
> 
> I'm also interested in feedback on the smtp/mysql/pgsql checks. It was
> reported in issue 187 that we recently started to close checks a bit too
> aggressively, which was indeed right. I relaxed this for the protocols
> where I knew we were supposed to be nice with the server and close first
> at the expense of accumulating TIME_WAITs. The reporter didn't see any
> improvement though it was OK for me. Thus if anyone is having issues
> where a checked server logs errors about aborted connections, please test
> this version as well.
> 
> I've already updated the 1.9 branch with all pending fixes but I'm not sure
> it's worth emitting 1.9.10 yet since most of these are mostly annoying but
> not serious enough to force everyone to upgrade again. However since 1.8
> definitely needs a new one, we might still have to emit one of each branch
> (as I don't want anyone to face regressions when upgrading from the latest
> stable of a branch to the latest stable of a more recent branch).
> 
> Now it's time to let my old worn out brain have some rest...
> 
> Please find the usual URLs below :
>Site index   : http://www.haproxy.org/
>Discourse: http://discourse.haproxy.org/
>Slack channel: https://slack.haproxy.org/
>Issue tracker: https://github.com/haproxy/haproxy/issues
>Sources  : http://www.haproxy.org/download/2.0/src/
>Git repository   : http://git.haproxy.org/git/haproxy-2.0.git/
>Git Web browsing : http://git.haproxy.org/?p=haproxy-2.0.git
>Changelog: http://www.haproxy.org/download/2.0/src/CHANGELOG
>Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/

Image with TLS 1.3, lua and prom available:
https://hub.docker.com/r/me2digital/haproxy20-centos
```
HA-Proxy version 2.0.4 2019/08/06 - https://haproxy.org/
Build options :
  TARGET  = linux-glibc
  CPU = generic
  CC  = gcc
  CFLAGS  = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv
-Wno-unused-label -Wno-sign-compare -Wno-unused-parameter
-Wno-old-style-declaration -Wno-ignored-qualifiers -Wno-clobbered
-Wno-missing-field-initializers -Wtype-limits
  OPTIONS = USE_PCRE=1 USE_PCRE_JIT=1 USE_PTHREAD_PSHARED=1 USE_REGPARM=1
USE_OPENSSL=1 USE_LUA=1 USE_SLZ=1

Feature list : +EPOLL -KQUEUE -MY_EPOLL -MY_SPLICE +NETFILTER +PCRE +PCRE_JIT
-PCRE2 -PCRE2_JIT +POLL -PRIVATE_CACHE +THREAD +PTHREAD_PSHARED +REGPARM
-STATIC_PCRE -STATIC_PCRE2 +TPROXY +LINUX_TPROXY +LINUX_SPLICE +LIBCRYPT
+CRYPT_H -VSYSCALL +GETADDRINFO +OPENSSL +LUA +FUTEX +ACCEPT4 -MY_ACCEPT4 -ZLIB
+SLZ +CPU_AFFINITY +TFO +NS +DL +RT -DEVICEATLAS -51DEGREES -WURFL -SYSTEMD
-OBSOLETE_LINKER +PRCTL +THREAD_DUMP -EVPORTS

Default settings :
  bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Built with multi-threading support (MAX_THREADS=64, default=1).
Built with OpenSSL version : OpenSSL 1.1.1c  28 May 2019
Running on OpenSSL version : OpenSSL 1.1.1c  28 May 2019
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3
Built with Lua version : Lua 5.3.5
Built with network namespace support.
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT
IP_FREEBIND
Built with libslz for stateless compression.
Compression algorithms supported : identity("identity"), deflate("deflate"),
raw-deflate("deflate"), gzip("gzip")
Built with PCRE version : 8.32 2012-11-30
Running on PCRE version : 8.32 2012-11-30
PCRE library supports JIT : yes
Encrypted password support via crypt(3): yes
Built with the Prometheus exporter as a service

Available polling systems :
  epoll : pref=300,  test result OK
   poll : pref=200,  test result OK
 select : pref=150,  test result OK
Total: 3 (3 

Re: patch: enable Coverity scan in travis-ci builds

[Willy Tarreau]

On Wed, Aug 07, 2019 at 01:15:28PM +0500,  ??? wrote:
> btw, Willy, we can exclude some exotic build targets from "on push" to "on
> cron"
> 
> by changing "if: type != cron" --> "if: type == cron"
> 
> 
> probably boringssl, cygwin, libressl ?

I indeed think that all non-latest and non-mainstream versions could be
daily only. I'm probably fine with keeping the latest libressl as it
significantly increases coverage. Thus we could keep something like this
"on push" :

  - linux-glibc with threads+openssl 1.1.1 on x86 + gcc
  - linux-glibc with threads+libressl 2.9.2 on x86 + clang
  - linux-glibc without SSL nor threads on x86 + clang or gcc (no preference)
  - osx with openssl-1.1.1 + clang

And these ones would be "on cron" :
  - linux-ppc64le
  - linux + openssl-1.1.0
  - linux + openssl-1.0.2
  - linux + libressl-2.8.3
  - linux + libressl-2.7.5
  - linux + boringssl
  - linux+51d/tree
  - cygwin

Note that some variants could be combined to save on builds. For example
we can have linux-ppc64le build with openssl-1.0.2 to test the two at once,
and linux+openssl-1.1.0 test with 51d/tree. In practice we don't need the
level of detail indicating what broke, we just need to know if we broke
anything, so heavy combinations are welcome.

Just my two cents,
Willy

Re: patch: enable Coverity scan in travis-ci builds

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

btw, Willy, we can exclude some exotic build targets from "on push" to "on
cron"

by changing "if: type != cron" --> "if: type == cron"


probably boringssl, cygwin, libressl ?

ср, 7 авг. 2019 г. в 12:07, Willy Tarreau :

> Hi Ilya,
>
> On Tue, Aug 06, 2019 at 10:55:47AM +0500,  ??? wrote:
> > 1) follow to https://travis-ci.com/haproxy/haproxy/settings
> >
> >
> > 2) setup COVERITY_SCAN_TOKEN = P6rHpv1618gwKWkVs7FfKQ
> >
> > 3) setup daily schedule
>
> All done now (with Dinko's new token). Thanks very much for the
> screenshot, it did help me.
>
> Let's see how it goes now. It says it's scheduled in about a minute.
>
> Willy
>

Re: patch: enable Coverity scan in travis-ci builds

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

Dinko, can you please disable your schedule (is it cron or whatever) ?

ср, 7 авг. 2019 г. в 12:07, Willy Tarreau :

> Hi Ilya,
>
> On Tue, Aug 06, 2019 at 10:55:47AM +0500,  ??? wrote:
> > 1) follow to https://travis-ci.com/haproxy/haproxy/settings
> >
> >
> > 2) setup COVERITY_SCAN_TOKEN = P6rHpv1618gwKWkVs7FfKQ
> >
> > 3) setup daily schedule
>
> All done now (with Dinko's new token). Thanks very much for the
> screenshot, it did help me.
>
> Let's see how it goes now. It says it's scheduled in about a minute.
>
> Willy
>

Re: patch: enable Coverity scan in travis-ci builds

[Willy Tarreau]

Hi Ilya,

On Tue, Aug 06, 2019 at 10:55:47AM +0500,  ??? wrote:
> 1) follow to https://travis-ci.com/haproxy/haproxy/settings
> 
> 
> 2) setup COVERITY_SCAN_TOKEN = P6rHpv1618gwKWkVs7FfKQ
> 
> 3) setup daily schedule

All done now (with Dinko's new token). Thanks very much for the
screenshot, it did help me.

Let's see how it goes now. It says it's scheduled in about a minute.

Willy