e master-worker code, however that does not explain why the
old
worker does not quit.
--
William Lallemand
On Tue, Nov 28, 2017 at 02:56:55PM +0100, William Lallemand wrote:
> On Tue, Nov 28, 2017 at 12:22:04PM +0100, Emmanuel Hocdet wrote:
> > ok, i should have something strange because it’s easy to reproduce in my
> > environnement.
> >
> > When i look lsof i see on mas
e:
ret = pipe(mworker_pipe);
if (ret < 0) {
ha_alert("[%s.main()] Cannot create
master pipe.\n", argv[0]);
exit(1);
}
This code will guarantee that the whole master-worker quit if there is a
problem.
--
William Lallemand
and 1 FDs in the pipe, we also need to rely on
setsid() to do a proper tty detach. This is already done in -D mode without -W,
maybe
this part of the code should me moved elsewhere, but we have to be careful not
to break the daemon mode w/o mworker.
--
William Lallemand
+0100, PiBa-NL wrote:
> Thanks for the review, new patch attached that basically incorporates
> all your comments.
> Regards,
> PiBa-NL / Pieter
>
--
William Lallemand
ly daemonize. */
> + fclose(stdin); fclose(stdout);
> fclose(stderr);
> + global.mode &= ~MODE_VERBOSE;
> + global.mode |= MODE_QUIET; /* ensure
> that we won't say anything from now */
> + setsid();
> + }
> +
> mworker_wait();
> /* should never get there */
> exit(EXIT_FAILURE);
Cheers,
--
William Lallemand
-failure: killing
> every workers with SIGTERM\n");
I prefer to leave this one, because otherwise the user won't understand why it
killed the workers, and a grep on "exit-on-failure" in the documentation will
find "no-exit-on-failure" so that's not a problem.
--
William Lallemand
I think the old processes did not receive the SIGTTOU for an unknown reason,
or did not unbind once it received the signal.
Maybe you could try to compare what's happening on your solaris-like system and
your ubuntu with the -dR option, using strace on linux and truss on solaris.
Regards,
--
William Lallemand
s post is not correct for the
seamless reload (-x + expose-fd), but only for a "classic" reload.
During a seamless reload, the new process try to get the FDs of the listeners
using the unix socket.
Did you try the seamless reload using -x without the master-worker?
--
William Lallemand
ndeed receiving the SIGTTOU
> signal from the master (200 times), so the worker must not have been
> unbinding.
>
Okay, so it looks like that the unbinding with SIGTOUT does not work on your
OS, but the seamless reload seems to work...
According to the code commentary that's a known problem on Solaris, maybe we
should add a note in the documentation about it.
Regards,
--
William Lallemand
play the error after the
chroot for the setuid and setgid, and we don't have access to /dev/null after
this, maybe we could open /dev/null in the master, do the chroot/setuid/setgid
and then do the dup2 in the worker.
--
William Lallemand
On Thu, Dec 28, 2017 at 12:54:27AM +0100, William Lallemand wrote:
> I think that's better to open /dev/null and dup2 with 0, 1, 2 so we won't
> have any
> surprise with an fprintf(stderr, ".. anywhere in the code.
>
Hi,
I made a patch which does exactly that, h
> Otherwise I'm reasonably confident that this should be enough to close
> all pending issues related to the master-worker now.
>
> Willy
>
I agree, it's better to merge them with fclose()
--
William Lallemand
n.
>
> Any insights appreciated.
>
I'm able to reproduce the problem thanks to your detailed example, it looks
like a regression in the code.
I will check the code to see what's going on.
--
William Lallemand
On Wed, Jan 03, 2018 at 06:41:01PM +0100, William Lallemand wrote:
> I'm able to reproduce the problem thanks to your detailed example, it looks
> like a regression in the code.
>
> I will check the code to see what's going on.
I found the issue, would you mind trying the a
fail, you should have this kind of errors:
[WARNING] 004/135908 (12013) : Failed to connect to the old process socket
'/tmp/sock4'
[ALERT] 004/135908 (12013) : Failed to get the sockets from the old process!
Are you seeing anything like this?
--
William Lallemand
(be patient)
> apr_socket_recv: Connection reset by peer (104)
> Total of 3031 requests completed
>
I'm able to reproduce, looks like it happens with the nbthread parameter only,
I'll try to find the problem in the code.
--
William Lallemand
That one can really make you crazy if you are in this exact case :-)
--
William Lallemand
>From ce9920d284e55600ef324a322a3aed92dd2af02f Mon Sep 17 00:00:00 2001
From: William Lallemand
Date: Tue, 9 Jan 2018 23:12:27 +0100
Subject: [PATCH] BUG/MEDIUM: mworker: execvp failure depending on a
n
file, that's probably your backend server which is doing the compression.
--
William Lallemand
ad also work with multiprocess
> > configurations? (nbproc > 1).
>
> Can i assume the answer is no for both questions?
>
>
> Veiko
>
Hello Veiko,
Indeed, the seamless reload is only available since HAProxy 1.8.
It supports multiprocess configuration.
--
William Lallemand
In commit abbf607 ("MEDIUM: cli: Add payload support") some cli keywords
without usage message have been added at the beginning of the keywords
array.
cli_gen_usage_usage_msg() use the kw->usage == NULL to stop generating
the usage message for the current keywords array. With those keywords at
the
n be represented
BUG/MEDIUM: http: don't always abort transfers on CF_SHUTR
BUG/MEDIUM: ssl: properly protect SSL cert generation
--
William Lallemand
last process
> > but I sometimes get: "Pid: 28271"(!) which is a > 24 hours old
> > process.
> >
> > Is there something we are doing wrongly?
>
> After some more testing, I don't have this issue using haproxy v1.8.8
> (rollbacked for > 12 hours). I hope I don't speak too fast.
>
Hi,
I managed to reproduce something similar with the 1.8.8 version. It looks like
letting a socat connected to the socket helps.
I'm looking into the code to see what's happening.
--
William Lallemand
On Thu, May 24, 2018 at 11:00:29PM +0200, William Dauchy wrote:
> On Thu, May 24, 2018 at 12:01:38PM +0200, William Lallemand wrote:
> > I managed to reproduce something similar with the 1.8.8 version. It looks
> > like
> > letting a socat connected to the socket helps.
>
ading' on the systemctl status haproxy to
check that.
Unfortunately the only way to know when the service is ready is with systemd,
but I planned to make the status available on the stats socket in the future.
--
William Lallemand
Hi Tim,
On Tue, May 29, 2018 at 09:33:48PM +0200, Tim Düsterhus wrote:
>
> @William Lallemand Possibly the sd_notifyf should be moved below
> mworker_unblock_signals in mworker_wait?
>
This shouldn't happen with or without systemd. I can reproduce it without
using systemd, w
On Wed, May 30, 2018 at 07:57:03PM +0200, Tim Düsterhus wrote:
> William,
>
> Am 30.05.2018 um 19:45 schrieb William Lallemand:
> >> @William Lallemand Possibly the sd_notifyf should be moved below
> >> mworker_unblock_signals in mworker_wait?
> >>
> >
use the seamless reload should migrate to HAProxy 1.8, the
stable team won't support this feature in previous branches.
Cheers,
--
William Lallemand
ker mode, you just have to kill -USR2 the master which will launch
a new process with -sf -x by itself.
Cheers,
--
William Lallemand
uld at least build with TARGET=linux2628 for the latest default
features.
Cheers,
--
William Lallemand
Hi guys,
Sorry for the late reply, I manage to reproduce and fix what seams to be the
bug.
The signal management was not handled correctly with threads.
Could you try those patches and see if it fixes the problem?
Thanks.
--
William Lallemand
>From d695242fb260538bd8db323715d627c4a9dea
On Thu, Jun 07, 2018 at 12:02:46PM +0200, Willy Tarreau wrote:
> On Thu, Jun 07, 2018 at 11:50:45AM +0200, William Lallemand wrote:
> > /* block signal delivery during processing */
> > +#ifdef USE_THREAD
> > + pthread_sigmask(SIG_SETMASK, &blocked_s
On Fri, Jun 08, 2018 at 02:10:44PM +0200, William Dauchy wrote:
> On Thu, Jun 07, 2018 at 11:50:45AM +0200, William Lallemand wrote:
> > Sorry for the late reply, I manage to reproduce and fix what seams to be
> > the bug.
> > The signal management was not handled c
On Fri, Jun 08, 2018 at 06:20:21PM +0200, Willy Tarreau wrote:
> On Fri, Jun 08, 2018 at 04:31:30PM +0200, William Lallemand wrote:
> > That's great news!
> >
> > Here's the new patches. It shouldn't change anything to the fix, it only
> > changes the
The bug happens with an existing entry, when you try to overwrite the
value with wrong data, for example, a string when the type is INT.
The code path was not secure and tried to set *err and *merr while
err = merr = NULL when performing an http action.
Must be backported in 1.6, 1.7, 1.8.
---
s
ny feature and
> > only increases verbosity in case of problem, do you want it to be
> > backported to 1.8 as well ?
>
>
> It should great !
>
> Thierry
Backported to 1.8.
--
William Lallemand
On Tue, Jun 12, 2018 at 04:00:25PM +0200, William Dauchy wrote:
> Hello William L,
>
> On Fri, Jun 08, 2018 at 04:31:30PM +0200, William Lallemand wrote:
> > That's great news!
> >
> > Here's the new patches. It shouldn't change anything to the f
On Tue, Jun 12, 2018 at 04:56:24PM +0200, William Dauchy wrote:
> On Tue, Jun 12, 2018 at 04:33:43PM +0200, William Lallemand wrote:
> > Those processes are still using a lot of CPU...
> > Are they still delivering traffic?
>
> they don't seem to handle any traffi
)
> pl_cpu_relax();
>
That's interesting, we can suppose that this bug is not related anymore to the
signal problem we had previously.
Looks like it's blocking in the thread sync point.
Are you able to do a backtrace with gdb? that could help a lot.
Thanks,
--
William Lallemand
et is unbind at this
moment :/
But you could try a netstat or ss to see if the listeners are still binded in
this process.
--
William Lallemand
On Thu, Jun 21, 2018 at 05:10:35PM +0200, William Dauchy wrote:
> On Thu, Jun 21, 2018 at 5:03 PM William Lallemand
> wrote:
> > Maybe one client was still connected on a frontend (including the stats
> > socket).
> > The process first unbind the listeners, and then
On Fri, Jun 22, 2018 at 12:03:22PM +0200, William Dauchy wrote:
> On Thu, Jun 21, 2018 at 5:21 PM William Lallemand
> wrote:
> > Once you are sure this is not a bug and that a client is still connected,
> > you
> > could use the keyword 'hard-stop-after' to fo
may dead-lock
BUG/MEDIUM: lua/socket: Buffer error, may segfault
MINOR: lua: Increase debug information
BUG/MAJOR: ssl: Random crash with cipherlist capture
BUG/MAJOR: ssl: OpenSSL context is stored in non-reserved memory slot
William Lallemand (5):
BUG/MEDI
absent from the logs when empty? And is there a way to
> force a "" or - sign when they are empty, to play nice with log parsers?
>
> Thanks,
> Julien
>
It's a bug, indeed, and thierry's patch is the right way to fix it.
--
William Lallemand
erator in 'else' (Makefile:206)
> *** Parse error: Missing dependency operator (Makefile:207)
> *** Parse error: Need an operator in 'else' (Makefile:213)
> [...]
You should install and use GNU Make, not the BSD one.
--
William Lallemand
gt; if that makes sense (anyone ever dreamed of having haproxy in their
> watches ?).
That's good news, we'll finally get ride of these filthy pointers!
--
William Lallemand
aproxy/openssl-compat.h
> That guard does not depend anymore on HA_OPENSSL_VERSION
Thanks, merged!
--
William Lallemand
g56.html
> >
> >
> >
> >
> >
> >
> >
> > Thanks,
> >
> > -- Daniel
> >
> >
> >
>
> Hi,
>
> Thank you Daniel for reporting / fixing this.
> The patch looks correct and may be applied.
>
> Baptiste
Thanks, applied.
--
William Lallemand
will need to be pushed each time a ticket expired.
--
William Lallemand
On Wed, Mar 24, 2021 at 11:29:03AM +0500, Илья Шипицин wrote:
> ping
>
> сб, 20 мар. 2021 г. в 22:43, Илья Шипицин :
>
> > while refactoring HA_OPENSSL_VERSION usage,
> > I've found unused definitions. nice.
> >
> >
> > Ilya
> >
Thanks, merged.
--
William Lallemand
On Wed, Mar 24, 2021 at 11:29:19AM +0500, Илья Шипицин wrote:
> ping
>
> вс, 21 мар. 2021 г. в 13:02, Илья Шипицин :
>
> > Hello,
> >
> > yet another patch that reduces number of HA_OPENSSL_VERSION use
> >
> > Ilya
> >
> >
> >
Thanks, merged.
--
William Lallemand
PATCH] BUILD: ssl: use feature guard instead of openssl
> > version for ecdh functions
> > To: HAProxy , Willy Tarreau
> > Delivered-To: haproxy@formilux.org
> > List-Id: Haproxy
> >
> > ping
> >
> > ??, 21 ???. 2021 ?. ? 13:02, ??? :
> >
> > > Hello,
> > >
> > > yet another patch that reduces number of HA_OPENSSL_VERSION use
> > >
> > > Ilya
> > >
> > >
> > >
>
> - End forwarded message -
>
Thanks, both merged.
--
William Lallemand
one of you please have a look ?
>
I'll take a look.
--
William Lallemand
On Thu, Mar 25, 2021 at 12:52:42AM +0500, Илья Шипицин wrote:
> Hello,
>
> yet another patch that removes several occurrences of HA_OPENSSL_VERSION
> also, fetches enabled for BoringSSL and LibreSSL-2.7.0 and higher
>
> Ilya
Looks good, pushed in master, thanks!
--
William Lallemand
On Fri, Mar 26, 2021 at 11:47:48PM +0500, Илья Шипицин wrote:
> Hello,
>
> yet another patch that removes few HA_OPENSSL_VERSION usage.
>
> Ilya
Pushed in master, thanks.
--
William Lallemand
nks for the report, I can reproduce the problem, I'm investigating.
--
William Lallemand
On Thu, Apr 01, 2021 at 02:26:07PM +0200, William Lallemand wrote:
> On Thu, Apr 01, 2021 at 10:19:31AM +, Jarno Huuskonen wrote:
> > Hello,
> >
> > I'm seeing a regression with 2.2.12 and using rsa and ecdsa certs on bind.
> > (cert1.pem.ecdsa
> > c
=haproxy-2.2.git
Changelog: http://www.haproxy.org/download/2.2/src/CHANGELOG
Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/
---
Complete changelog :
William Lallemand (2):
BUG/MEDIUM: ssl: ckch_inst->ctx not assigned with multi-bundle
certificates
REGTE
ne, but it's for a new major release so
it's fine in my opinion.
--
William Lallemand
On Wed, May 05, 2021 at 09:11:08AM +0500, Илья Шипицин wrote:
> Hello,
>
> LibreSSL-3.3.3 just released. patch attached.
>
> thanks,
> Ilya
Thanks, pushed in master.
--
William Lallemand
nd build without -Werror in order to see the
-Wdeprecated-declarations warnings.
* port haproxy to the new API (long term goal) to be able to build
with openssl 3.0.0 with -Werror.
>
> @William Lallemand has an appetite to make it
> green ;)
>
I'll fix what I can to be able to
ll users and they
can be relevant at some point, not only for OpenSSL, but for the other
libs that are linked with haproxy.
In my opinion we should only disable them for this specific build of
OpenSSL 3.0.0 on the CI, not for everyone in the Makefile.
--
William Lallemand
do something like:
make DEBUG_CFLAGS="-g -Wno-deprecated-declarations"
--
William Lallemand
On Mon, Jun 07, 2021 at 05:08:32PM +0500, Илья Шипицин wrote:
> пн, 7 июн. 2021 г. в 16:31, William Lallemand :
>
> > On Mon, Jun 07, 2021 at 04:02:00PM +0500, Илья Шипицин wrote:
> > > sorry, I do not have much spare time to implement that in short time
> > > per
On Mon, Jun 07, 2021 at 02:09:33PM +0200, Tim Düsterhus wrote:
> Subject: Re: [PATCH] CI: enable openssl-3.0.0 builds
>
> William,
>
> On 6/7/21 1:30 PM, William Lallemand wrote:
> > On Mon, Jun 07, 2021 at 04:02:00PM +0500, Илья Шипицин wrote:
> >> sorry, I
On Mon, Jun 07, 2021 at 02:17:24PM +0200, William Lallemand wrote:
>
> On Mon, Jun 07, 2021 at 02:09:33PM +0200, Tim Düsterhus wrote:
> >
> > William,
> >
> > On 6/7/21 1:30 PM, William Lallemand wrote:
> > > On Mon, Jun 07, 2021 at 04:02:00PM +0500, Иль
probably be tested on macos to be certain it's
> OK there as well, and I don't know how to get the CPU count there (or
> maybe we could just force it to a low value like 2 or 4).
>
> Willy
>
Looks fine to me, but from what I remember when debugging some reg-tests
there was only one CPU available, I hope I'm wrong.
--
William Lallemand
Hello guys,
I couldn't find a way to launch an alpine job easily with github actions so
instead I wrote one for cirrus-ci, It will help debugging Docker images
and musl problems.
Example of the run here: https://cirrus-ci.com/task/5985082050609152
I'll push it in the master if that's fine with y
This commit adds a CI job to cirrus-ci which builds HAProxy on Alpine
Linux, allowing to build and test HAProxy with musl.
OpenSSL, PCRE2, Lua 5.3 as well as the prometheus exporter are enabled.
GNU grep was purposely installed to run the reg-test script.
---
.cirrus.yml | 13 +
1 fi
e able to make this work I
prefer to run it from github actions, otherwise we'll go with cirrus.
Thanks,
--
William Lallemand
e they are built on the docker hub.
> also, there's small caveat, github actions runs agent inside docker
> container, it might have issues with older libc (or musl).
> but it worth a try
>
Let's hope it works in this case.
--
William Lallemand
er if we could do it with the
alpine image.
I you want to build with the musl-gcc wrapper you will need to link the
linux headers in the musl headers directory otherwise it won't work the
way their package is done.
--
William Lallemand
ll running though.
According to their documentation they are running the CI
on the actual CPU not a emulated one, so still beter than qemu.
--
William Lallemand
ing section. However the final line will show that a few tests
> have been skipped:
>
> 0 tests failed, 4 tests skipped, 105 tests passed
>
> I don't think this is going to be an issue. But if it is, please complain!
>
Hm the only problem I have with this, is that we won't be able to see why a
test was excluded.
--
William Lallemand
s missing.
>
Looks like a good idea imho, it could even be used to provide several
kind of regex depending of which regex library you use for example.
--
William Lallemand
https://github.com/haproxy/haproxy/commit/1b095cac9468d0c3eeb157e9b1a2947487bd3c83
I thought it disappeared completely from the interface, good to know!
Thanks
--
William Lallemand
der make -j.
> >
> > Let's wait for the remaining tests to conclude.
>
> OK that's a net win, openssl-3.0.0-alpha17 dropped from 8'29 to 2'55.
> I've just excluded versions 1.x from both the parallel build and the
> build_sw target and that's good now.
>
> Willy
Great improvement, thanks!
--
William Lallemand
_256_GCM_SHA384
>
> and the corresponding log-format :
>
> %ci:%cp [%tr] %ft %b/%s %TR/%Tw/%Tc/%Tr/%Ta %ST %B %CC \
> %CS %tsc %ac/%fc/%bc/%sc/%rc %sq/%bq %hr %hs %{+Q}r \
> *%[conn_err_code]/%[ssl_fc_hsk_err]/%[ssl_c_err]/%[ssl_c_ca_err]* \
> *%sslv/%sslc*
>
I saw that you hesitated between "conn_status" and "conn_err_code", the
"conn_" prefix could be confusing at some point once you try to have
errors on the frontend and the backend side in the same log-format, I
think something starting by "fc_conn_" would be more understandable.
That seems good to me, we only need frontend info IMHO. People who need
the SSL backend connection are not the most common case so they could
make their own log-format with it.
--
William Lallemand
On Thu, Jul 08, 2021 at 02:48:32PM +0200, Willy Tarreau wrote:
> On Thu, Jul 08, 2021 at 02:18:32PM +0200, William Lallemand wrote:
> > I saw that you hesitated between "conn_status" and "conn_err_code", the
> > "conn_" prefix could be confusing at some
n the case of communication between the master and the
workers, if we expose this to users we will probably have a lot of
corner cases to handle.
This keyword is only meant to say to a worker that it must keep the
communication with the master even if it's trying to exit, so we could
do some maintenance or debugging over the master CLI.
--
William Lallemand
ll active, and any feedback is welcome if that helps to
> further improve the situation for users.
>
We need feedback about this, it will probably change in the future, the
github thread is available here:
https://github.com/haproxy/haproxy/issues/693
Don't hesitate to report your problems or needs in the ticket.
--
William Lallemand
going to remove this line.
Is there anyone against it, or did I miss a particular usecase?
Thanks,
--
William Lallemand
temd during a reload, because kill can't achieve that. It's not
really a problem to be in "wait" mode, if you do a reload again with a
working configuration it will be in a normal state. The wait mode is
just a state where the master only supervise the previous workers and
- William added a new config predicate "ssllib_name_startswith" to
> detect the type of SSL library in "-cc" rules.
Actually it's Rémi's patches. It completes the "openssl_version_atleast"
predicate that was previously done and allow us to be very precise in
the test selection, which was not the case before.
--
William Lallemand
allback because openSSL
couldn't finish the handshake.
However, in the case of a resume, no error was reported, but openSSL
didn't had any handshake to do, so the connection was still accepted
even though the SNI wasn't matching.
--
William Lallemand
lly it is
recommended to update its .ocsp at the same time before committing, so
it could add again the Certificate ID in the OCSP tree. It's the only
HAProxy can know that OCSP was activated.
Once its done, you can use the "set ssl ocsp-response", like you were
using before.
Look at the example in the documentation:
https://cbonte.github.io/haproxy-dconv/2.4/management.html#9.3-set%20ssl%20cert
Regards,
--
William Lallemand
t, currently vtc expects 21, but some openssl variations return 20
>
> X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE = 21
> X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY = 20
>
> cheers,
> Ilya
Thanks, applied.
--
William Lallemand
SSL cache).
>
Hi Thierry,
Could you update the lua documentation at
http://www.arpalert.org/haproxy-api.html?
It looks like neither the 2.4 version nor the 2.5 were published.
Also the 2.4-dev link seems to be the master, maybe you could rename
"2.4dev" into "master" directly?
Thanks,
--
William Lallemand
a95d3a8895a6232b5b0ce5c9cb5c0 Mon Sep 17 00:00:00 2001
Thanks Daniel, I merged it into master.
--
William Lallemand
, a warning has been
> > added if the OT_USE_VARS variable is used.
> >
> > If appropriate, please apply this commit.
> >
> > Best regards.
> >
>
> sorry, i forgot the patch. :(
>
Hi Miroslav, In which versions this patch should be backported?
Thanks
--
William Lallemand
On Tue, Dec 28, 2021 at 12:14:37PM +0100, Miroslav Zagorac wrote:
>
> Hello William,
>
> I think that this commit can be applied to branches 2.5 and 2.6-dev.
>
>
> Best regards.
>
Thanks, I added the information about the backport in the patch and I
pushed it
.3.17, 2.2.20, in the
master of the soon to be released 2.0.27.
The change in `show proc` was made to remove the relative PID because
HAProxy is not multi-process anymore.
But if you parse the output by splitting the spaces and keeping the
right field with the header you shouldn't have a parsing problem.
--
William Lallemand
remove the implicit behavior
> > > - then work on the missing commands for the health checks
> >
> > Do you think we can conclude on it?
>
> Just merged after our discussion on it :-)
>
Can we also mark it as deprecated in 2.5? patch attached
--
William Lallemand
On Wed, Jan 19, 2022 at 03:32:35PM +0100, Willy Tarreau wrote:
> Subject: Re: [PATCH] BUG/MEDIUM: server: avoid changing healthcheck ctx with
> set server ssl
>
> On Wed, Jan 19, 2022 at 03:24:44PM +0100, William Lallemand wrote:
> > On Tue, Jan 18, 2022 at 12:07:21PM +0100, W
#x27;ll let the guys in charge of that decides,
but the development of QUIC in HAProxy is made with quictls currently.
--
William Lallemand
/haproxy -W -f haproxy.cfg
68703 pts/14 Sl+0:00 ./haproxy -sf 68686 -x sockpair@3 -W -f
haproxy.cfg
The biggest benefit is that you don't have to configure anything
anymore to do a hitless reload.
--
William Lallemand
et_X509_PUBKEY(x)
>
> BoringSSL defines that function since
> https://boringssl.googlesource.com/boringssl/+/33f8d33af0dcb083610e978baad5a8b6e1cfee82
Merged.
--
William Lallemand
On Fri, Feb 04, 2022 at 09:57:25AM +0100, Remi Tricot-Le Breton wrote:
>
>
> On 02/02/2022 17:49, William Lallemand wrote:
> >
> >> Subject: [PATCH 2/7] BUILD: SSL: define X509_OBJECT for BoringSSL
> >>
> >> X509_OBJECT is opaque in BonringSSL, sinc
On Fri, Feb 04, 2022 at 11:18:50AM +0100, William Lallemand wrote:
> On Fri, Feb 04, 2022 at 09:57:25AM +0100, Remi Tricot-Le Breton wrote:
> >
> >
> > On 02/02/2022 17:49, William Lallemand wrote:
> > >
> > >> Subject: [PATCH 2/7] BU
On Fri, Feb 04, 2022 at 11:52:06AM +0100, William Lallemand wrote:
>
> I just tried to build with the latest boringSSL version, the problem is
> on our side:
>
> We are defining X509_OBJECT_get0_X509_CRL() because it does not exist in
> boringSSL, and inside it we are access
201 - 300 of 702 matches
Mail list logo
