More on this:
> However, I'm not sure if the current options -B, -c, -j and -o are that
> great. Maybe something like "-o " would be
> more powerful and more flexible?
btw, in almost all other commmands -o (along with -f) indicates an filename,
not a format.
So that isn't the letter you want.
>
> job@ suggested to move this from GitHub to tech@ list (as upstream):
>
> 1. Currently, BIRD 1.x support in rpki-client seems to be broken: As per
>BIRD upstream the "combined format" produced by rpki-client can't be
>used as-is with BIRD 1.x due to separated daemons (and configuration
>
Hi,
job@ suggested to move this from GitHub to tech@ list (as upstream):
1. Currently, BIRD 1.x support in rpki-client seems to be broken: As per
BIRD upstream the "combined format" produced by rpki-client can't be
used as-is with BIRD 1.x due to separated daemons (and configuration
file
Oops, sorry for the mixup below. I got the e-mail bounced from someone
and it used their 'From' instead of the original. Regardless,
technical contend stands. :)
On 3/2/20, Mateusz Guzik wrote:
> On 2/29/20, Visa Hankala wrote:
>> There is a bug in how rw_exit_read() and rw_exit_write() use
>> W
On 2/29/20, Visa Hankala wrote:
> There is a bug in how rw_exit_read() and rw_exit_write() use
> WITNESS_UNLOCK(). The fast paths call WITNESS_UNLOCK() after releasing
> the actual lock. This leads to a use-after-free in the checker if the
> lock is dynamically allocated and another thread happens
Hi,
in ldapd and ldapctl the "-r directory" command line argument does not
work:
ldapd fork/execs itself but the directory command line argument is not
given to the execvp call which then uses the default data directory.
ldapctl has a thinko/typo which causes the data_db to be always opened
in t
That's quite a hack you wrote, but I think any nicer way of doing it is
going to require a big rewrite..
Patrick Wildt wrote:
> as it turns out, puc(4) has trouble with 64-bit BARs. The issue is that
> puc(4) tries to map every BAR before doing anything else. While iter-
> ating over the BARs
On 2020-03-02, Lauri Tirkkonen wrote:
> Thanks for the input, and ping - is there still something about this
> diff that I should fix?
I'm kinda busy, but I should be able to look into it eventually.
> Date: Mon, 2 Mar 2020 13:56:11 +0100
> From: Patrick Wildt
>
> Hi,
>
> as it turns out, puc(4) has trouble with 64-bit BARs. The issue is that
> puc(4) tries to map every BAR before doing anything else. While iter-
> ating over the BARs it assumes the next BAR is always 4 bytes after the
> o
Hi,
as it turns out, puc(4) has trouble with 64-bit BARs. The issue is that
puc(4) tries to map every BAR before doing anything else. While iter-
ating over the BARs it assumes the next BAR is always 4 bytes after the
other. For 64-bit BARs that's wrong. On a device with a 64-bit BAR, it
will
10 matches
Mail list logo