We are still at the early stages of RPKI deployment, so if we make it easier to
plug things into BIRD1 is beneficial given the wide deployment scale.
Only /very/ recently was rpki-client packaged for some of the Linux distros, so
if we add support for all formats now - it’ll improve the
On Wed, Mar 04, 2020 at 07:48:28AM -0700, Theo de Raadt wrote:
> Job Snijders wrote:
>
> > I think we still need to support BIRD 1 for the foreseeable future, NIC.CZ
> > hasn’t communicated plans to deprecate BIRD1 and still supports it; and
> > BIRD1 still is widely deployed.
> >
> > I’m
Job Snijders wrote:
> I think we still need to support BIRD 1 for the foreseeable future, NIC.CZ
> hasn’t communicated plans to deprecate BIRD1 and still supports it; and BIRD1
> still is widely deployed.
>
> I’m somewhat preferential to just generate all 3 BIRD flavors if -B is given
> as
I think we still need to support BIRD 1 for the foreseeable future, NIC.CZ
hasn’t communicated plans to deprecate BIRD1 and still supports it; and BIRD1
still is widely deployed.
I’m somewhat preferential to just generate all 3 BIRD flavors if -B is given as
command line option.
Kind regards,
On Wed, Mar 4, 2020, at 00:55, Robert Scheck wrote:
> > The idea is you can specify many outputs. That will make the commandline
> > very long, especially for the way we run it in cron.
>
> Oh! I'm sorry, I didn't see the idea of specifying many outputs.
Yeah, its nice to do things in one batch
On 03/03/20(Tue) 11:37, Martin Pieuchot wrote:
> Currently em_hw_init() uses some hardcorded values to configure TX
> rings. Diff below convert it to use the value of the first queue.
> This is currently a no-op. It makes the code consistent with the
> rest of the driver and reduce the size of
Hi,
pfkeyv2.c:1091:pfkeyv2_send(struct socket *so, void *message, int len)
leaks memory in the SADB_REGISTER case (line 1579).
It reuses void *freeme multiple times to build up void *headers[].
headers[] are bcopy'ed to another buffer inside of pfkeyv2_sendmessage()
(line 2064) so as the name
After migrating my home setup from nginx reverse proxying to relayd, i
noticed my iOS devices having issues connecting through Websockets.
After debugging, i noticed that relayd adds the "Connection: close"
regardless of upgrade being requested.
This issue is also reported on a blog-post using
An accidentally unterminated string in httpd.conf results in
the famed yacc "syntax error" message.
For instance:
root "/
}
}
# "hi" <- line xx: syntax error
The loop starting at line 1515 in httpd parse.y
}
switch (c) {
case '\'':
case '"':
Hi,
On Tue, 3 Mar 2020 20:45:17 +0100
Martijn van Duren wrote:
> I don't agree with this diff, even though you're right with it being
> broken. Right now the regress test uses it/tries to use it and even
> though someone trying to run regress on an actual production machine
> somewhat deserves
I noticed that some regress test fail since February 7:
- run-args-server-tls-reconnect.pl
- run-args-server-tls-tcp.pl
- run-args-tls-cipher-null.pl
(http://bluhm.genua.de/regress/results/regress-ot6.html)
It is related to changes in LibreSSL. Is this intended? Should the regress
tests be
This reads fine to me and fixes the regress test location.
Does anyone else want to chime in?
martijn@
On 3/4/20 9:11 PM, Robert Klein wrote:
> Hi,
>
> On Tue, 3 Mar 2020 20:45:17 +0100
> Martijn van Duren wrote:
>
>> I don't agree with this diff, even though you're right with it being
>>
Committed, thanks.
On 3/4/20 9:11 PM, Robert Klein wrote:
> Hi,
>
> On Tue, 3 Mar 2020 20:45:17 +0100
> Martijn van Duren wrote:
>
>> I don't agree with this diff, even though you're right with it being
>> broken. Right now the regress test uses it/tries to use it and even
>> though someone
13 matches
Mail list logo