Re: BIRD 1.x/2.x support at rpki-client

2020-03-02 Thread Theo de Raadt
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.

Re: BIRD 1.x/2.x support at rpki-client

2020-03-02 Thread Theo de Raadt
> 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 >

BIRD 1.x/2.x support at rpki-client

2020-03-02 Thread Robert Scheck
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

Re: Fix use of WITNESS_UNLOCK() in rw_exit_{read,write}()

2020-03-02 Thread Mateusz Guzik
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 >>

Re: Fix use of WITNESS_UNLOCK() in rw_exit_{read,write}()

2020-03-02 Thread Mateusz Guzik
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

fix ldapd/ldapctl data directory handling

2020-03-02 Thread Robert Klein
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

Re: puc(4): 64-bit BARs

2020-03-02 Thread Theo de Raadt
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

Re: librthread sem_t opaqueness, storage & unnamed semaphore sharing

2020-03-02 Thread Ted Unangst
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.

Re: puc(4): 64-bit BARs

2020-03-02 Thread Mark Kettenis
> 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 >

puc(4): 64-bit BARs

2020-03-02 Thread 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 other. For 64-bit BARs that's wrong. On a device with a 64-bit BAR, it will