Re: OpenBGPD 7.0 released
On Fri, 04 Jun 2021, Claudio Jeker wrote: > We have released OpenBGPD 7.0, which will be arriving in the > OpenBGPD directory of your local OpenBSD mirror soon. https://ftp.openbsd.org/pub/OpenBSD/OpenBGPD/ unfortunately lacks a openbgpd-7.0.tar.gz.asc as it seems... Regards, Robert pgpIp3L8gw1ot.pgp Description: PGP signature
Mention -N to shutdown(2) network socket after EOF in man nc(1)
Jakub Jelen reported at Fedora that "nc -l 8080" (terminal #1) and "echo XXX | nc localhost 8080" (terminal #2) keeps hanging both client and server after reading the EOF, even the last sentence of "CLIENT/SERVER MODEL" in the man page of nc(1) says "The connection may be terminated using an EOF (‘^D’)." Based on Freenode #openbsd IRC the observed behaviour is correct but the man page should be updated, so my proposal is posted below. As I'm not sure if -N should be added to 'server' and 'client' side, I've cloned the "DATA TRANSFER" section, which covers the 'client' side only. Feel free to adjust my proposal as necessary. Thanks, Robert --- nc.12020-02-12 14:46:36.831500390 + 1.95 +++ nc.12021-03-30 02:22:34.545148296 +0200 @@ -414,7 +414,7 @@ .Pq or a second machine , connect to the machine and port being listened on: .Pp -.Dl $ nc 127.0.0.1 1234 +.Dl $ nc -N 127.0.0.1 1234 .Pp There should now be a connection between the ports. Anything typed at the second console will be concatenated to the first, @@ -427,7 +427,10 @@ .Sq client . The connection may be terminated using an .Dv EOF -.Pq Sq ^D . +.Pq Sq ^D +if the +.Fl N +flag was given. .Sh DATA TRANSFER The example in the previous section can be expanded to build a basic data transfer model.
Re: rpki-client: reject bad URLs in cert files
On Wed, 02 Dec 2020, Claudio Jeker wrote: > Be stricter in what we accept as URL. Nobody should use silly encodings > like UTF-8 or other crap in the embedded URLs. I also consider any kind of > space as a failure (use %20 instead if that is really needed). Really? So ȓþʞí.idna2008.example.net is never going to happen? Not that it likely would work in the portable currently, but I'm still thinking about. Btw, ACE of above: xn--eda7ay6d6p.idna2008.example.net. I did not yet check if delegated RPKI allows ACE-only or even the UTF-8 representation... Regards, Robert pgp_PRMKPF4fb.pgp Description: PGP signature
Minor change in rpki-client.8
Following claudio@'s recent change from "-rlt" to "-rt" in rpki-client [1], I would like to propose this minor change to rpki-client.8 hereby: diff --git a/src/usr.sbin/rpki-client/rpki-client.8 b/src/usr.sbin/rpki-client/rpki-client.8 index 06d3490..ec1e4ae 100644 --- a/src/usr.sbin/rpki-client/rpki-client.8 +++ b/src/usr.sbin/rpki-client/rpki-client.8 @@ -76,7 +76,7 @@ instead of .Xr openrsync 1 to fetch repositories. It must accept the -.Fl rlt , +.Fl rt , .Fl -address and .Fl -delete Regards, Robert [1] https://github.com/rpki-client/rpki-client-openbsd/commit/dfb8acbffdb9e9874b4707a05f1a99149b305cf8.patch
Re: BIRD 1.x/2.x support at rpki-client
On Fri, 06 Mar 2020, Sebastian Benoit wrote: > Note that I haven't tried this with bird 1 or 2 yet ;) > comments, oks? I did not try it yet, but I think BIRD 1 also needs something like "define force_roa_table_update = %lld;" and maybe some table definition. I will try BIRD 1 and 2 during the weekend explicitly and provide specific feedback or suggest diffs. Regards, Robert
Re: BIRD 1.x/2.x support at rpki-client
On Fri, 06 Mar 2020, Job Snijders wrote: > I believe Robert is referring to this snippet of code: > > > https://patch-diff.githubusercontent.com/raw/kristapsdz/rpki-client/pull/21.patch Exactly. Regards, Robert
Re: BIRD 1.x/2.x support at rpki-client
On Mon, 02 Mar 2020, Theo de Raadt wrote: > Can't we assume bird1 will go away eventually? Yes, sooner or later. Likely later for OpenBSD when looking to net/bird/1 and net/bird/2 co-existence, thus ongoing BIRD 1.x compatibility might be more important for OpenBSD than for rpki-client downstreams such as Fedora (which only ships BIRD 2.x). And I expect I[SX]Ps to be quite conservative, too. Could maybe somebody with real-world insights comment on this, please? > Or why don't those people convert json to their required format -- make > it their problem? Are you referring to BIRD 1.x or 2.x here? I would prefer native BIRD 2.x compatibility rather having to convert json around. Nevertheless, I'm not sure if it's fair to remove the BIRD 1.x compatibility (which is currently broken anyway). > 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. On Mon, 02 Mar 2020, Theo de Raadt wrote: > btw, in almost all other commmands -o (along with -f) indicates an filename, > not a format. > > So that isn't the letter you want. Personally, I do not care about the letter for the option, that was just a quick example to explain my idea. > As written today with mkstemp + unveil/pledge, each output format > function can only output one file. Using one format name to create > multiple outputs is going to require some restructuring. I see. Honestly, my downstream needs would be satisfied with "-B" leading to BIRD 2.x compatible output only (avoiding new options and restructuring), but I don't want to behave like a bull in a china shop. Thus in the end it's your decision as upstream... Regards, Robert
BIRD 1.x/2.x support at rpki-client
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 files) for IPv4 and IPv6. 2. Lack of BIRD 2.x support in rpki-client, which requires a different output/configuration format (semi-finished pull request at GitHub). To cover this, job@ suggested to maybe generate bird1-ipv6, bird1-ipv4 and bird2 when using -B option. The option currently leads to "bird" file with BIRD 1.x support only. 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? Opinions? Regards, Robert
