Hello everyone,
Not sure if this is already addressed. Today I got a CVE report of several
issues with Lua 5.3.5 up to 5.4.
I believe Lua 5.4 is currently recommended to build with HAproxy 2.x?
Before I open an issue on github I would like to ask if these are already known
/ addressed:
Lua 5.3
Hello haproxy.com
We are a web development company, with goals in harnessing our client's
online presence by making well structured and up to date websites and
mobile applications for them to explore more into the online business world.
If you have a website, we would like to do a first free ana
Hello,
On Wed, 29 Jul 2020 at 10:23, Froehlich, Dominik
wrote:
>
> Hello everyone,
>
> Not sure if this is already addressed. Today I got a CVE report of several
> issues with Lua 5.3.5 up to 5.4.
>
> I believe Lua 5.4 is currently recommended to build with HAproxy 2.x?
>
> Before I open an issu
Hi Lukas,
Thanks for the reply.
My query goes along the lines of which Lua version is compatible with HAproxy
and contains fixes to those CVEs.
I could not find a specific instruction as to which Lua version can be used to
build HAproxy / has been tested for production use.
We are consuming a
On 7/29/20 11:16 AM, Froehlich, Dominik wrote:
Hi Lukas,
Thanks for the reply.
My query goes along the lines of which Lua version is compatible with HAproxy
and contains fixes to those CVEs.
I could not find a specific instruction as to which Lua version can be used to
build HAproxy / has been
Patch applied, thanks guys!
Willy
On Tue, Jul 28, 2020 at 02:58:57PM +0200, Baptiste wrote:
> Hi Jerome,
>
> Thanks a lot for the debugging and the fix.
> This is all good and can be applied.
Great, patch applied then. Thanks guys!
Willy
Hello,
On Wed, 29 Jul 2020 at 11:16, Froehlich, Dominik
wrote:
>
> Hi Lukas,
>
> Thanks for the reply.
> My query goes along the lines of which Lua version is compatible with HAproxy
> and contains fixes to those CVEs.
> I could not find a specific instruction as to which Lua version can be used
Travis is becoming overall increasingly unreliable lately. We've already
seen that the timing sensitive tests regularly fail and thus they were
disabled.
GitHub Actions VMs are working well, possibly allowing to use custom runners
for special tasks in the future.
In addition to this better perfor
Ilya,
List,
Am 29.07.20 um 18:49 schrieb Tim Duesterhus:
> [long snip]
You can find an example run of that GitHub Action workflow here:
https://github.com/TimWolla/haproxy/actions/runs/187396816
I've attached a screenshot of how nice it looks in the commit overview
compared to Travis.
The buil
ср, 29 июл. 2020 г. в 21:49, Tim Duesterhus :
> Travis is becoming overall increasingly unreliable lately. We've already
> seen that the timing sensitive tests regularly fail and thus they were
> disabled.
>
> GitHub Actions VMs are working well, possibly allowing to use custom
> runners
> for spe
generally, there was an idea of keeping "developer velocity" as high as
possible.
i.e. to perform check in 3-5 min after the push.
Github Actions allows 4 parallel builds (same as Travis CI), I thought of
moving some builds to GH actions.
also, that was a reason to move some rare configurations to
ср, 29 июл. 2020 г. в 21:49, Tim Duesterhus :
> Travis is becoming overall increasingly unreliable lately. We've already
> seen that the timing sensitive tests regularly fail and thus they were
> disabled.
>
> GitHub Actions VMs are working well, possibly allowing to use custom
> runners
> for spe
Hello,
I am running pretty big LB installation with http compression and SSL
termination enabled.
I was very surprised that 70-80% of cpu is spent on "gzip". Also, I found
that SLZ is much better than ZLIB in terms of cpu usage.
however, ZLIB is enabled by default in many distros and docker imag
Tim,
there's also gitlab official mirror (ran by William)
https://gitlab.com/haproxy.org/haproxy
in theory we can use gitlab-ci as well :)
ср, 29 июл. 2020 г. в 21:49, Tim Duesterhus :
> Travis is becoming overall increasingly unreliable lately. We've already
> seen that the timing sensitive
Ilya,
Am 29.07.20 um 18:58 schrieb Илья Шипицин:
> generally, there was an idea of keeping "developer velocity" as high as
> possible.
> i.e. to perform check in 3-5 min after the push.
>
> Github Actions allows 4 parallel builds (same as Travis CI), I thought of
> moving some builds to GH action
Ilya,
Am 29.07.20 um 19:22 schrieb Илья Шипицин:
> there's also gitlab official mirror (ran by William)
> https://gitlab.com/haproxy.org/haproxy
>
>
> in theory we can use gitlab-ci as well :)
>
Please no more external services! I've specifically reimplemented the
Travis tests in GitHub Action
Ilya,
Am 29.07.20 um 18:55 schrieb Илья Шипицин:
>> +for ssl in [
>> + "stock",
>> + "OPENSSL_VERSION=1.0.2u",
>> + "OPENSSL_VERSION=1.1.0l",
>> + "OPENSSL_VERSION=1.1.1f",
>> + "LIBRESSL_VERSION=2.9.2",
>> +
ср, 29 июл. 2020 г. в 22:27, Tim Düsterhus :
> Ilya,
>
> Am 29.07.20 um 19:22 schrieb Илья Шипицин:
> > there's also gitlab official mirror (ran by William)
> > https://gitlab.com/haproxy.org/haproxy
> >
> >
> > in theory we can use gitlab-ci as well :)
> >
>
> Please no more external services! I'
Ilya,
Am 29.07.20 um 19:05 schrieb Илья Шипицин:
>> Known issues:
>> - Apparently the git commit is not properly detected during build. The HEAD
>> currently shows as 2.3-dev1.
>>
>
> there's something wrong with git checkout (or the way we use it)
>
> have a look (do not ask me why, I've no i
Hello,
On Wed, 29 Jul 2020 at 19:19, Илья Шипицин wrote:
> however, ZLIB is enabled by default in many distros and docker images.
> any idea why ZLIB is chosen by default ?
Because zlib is known, packaged and used everywhere and by everyone
while slz is a niche library. It would need a marketin
ср, 29 июл. 2020 г. в 22:33, Tim Düsterhus :
> Ilya,
>
> Am 29.07.20 um 19:05 schrieb Илья Шипицин:
> >> Known issues:
> >> - Apparently the git commit is not properly detected during build. The
> HEAD
> >> currently shows as 2.3-dev1.
> >>
> >
> > there's something wrong with git checkout (or t
On Wed, Jul 29, 2020 at 10:22:33PM +0500, Илья Шипицин wrote:
> Tim,
>
> there's also gitlab official mirror (ran by William)
> https://gitlab.com/haproxy.org/haproxy
>
>
> in theory we can use gitlab-ci as well :)
>
I don't want this to be considered an "official" mirror, I deliberately
wrote
Hello,
I did not like SSL_LIB, SSL_INC after arm64 switched to stock lib (in an
ugly way).
let us make stock lib first class citizen.
Cheers,
Ilya Shipitcin
From 6ff056e7ded7784fcb4020ea8f37b12b23c855b6 Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin
Date: Thu, 30 Jul 2020 01:47:55 +0500
Subject:
Hi Ilya,
thanks for this. Two minor comments (just let me know, I can adjust
the patches before merging them if you confirm):
>- os: linux
> if: type == cron
> compiler: clang
> env: TARGET=linux-glibc LIBRESSL_VERSION=2.9.2
> EXTRA_OBJS="contrib/prometheus-exporter/service-pr
чт, 30 июл. 2020 г. в 07:48, Willy Tarreau :
> Hi Ilya,
>
> thanks for this. Two minor comments (just let me know, I can adjust
> the patches before merging them if you confirm):
>
> >- os: linux
> > if: type == cron
> > compiler: clang
> > env: TARGET=linux-glibc LIBRESSL_VERSI
On Thu, Jul 30, 2020 at 08:25:16AM +0500, ??? wrote:
> > EXTRA_OBJS="contrib/prometheus-exporter/service-prometheus.o" CC=clang-9
> > > +name: libressl-2.9.2 | prometheus-exporte
> >
> > I guess this was "prometheus-exporter" above (missing "r") ?
> >
>
> oops.
> can you please fix it
Tim, let us move this activity to GH issue ?
as for failing osx builds, I think it might be due to long folder name
https://github.com/TimWolla/haproxy/runs/924097118?check_suite_focus=true#step:10:361
it is 100+ characters. there's also unix socket in that dir, which has
limitation on filenam
28 matches
Mail list logo