On Mon, May 03, 2021 at 10:40:53AM -0600, Theo de Raadt wrote:
> This needs a cast from time_t to long long, otherwise the code won't compile
> or operate correctly on laggard legacy 32-bit time_t systems.
thanks, fixed!
OK?
Index: usr.sbin/rpki-client/extern.h
Ashton Fagg wrote:
> On Mon, 3 May 2021 at 10:17, Theo de Raadt wrote:
> > So if the messages were just 'unveil %s: error' or 'unveil: %s: error'
> > I would be thrilled, as this allows users to realize why the program is
> > not working right.
>
> Florian/Theo,
>
> Thanks for the reviews.
>
"Theo de Raadt" writes:
> No, it is either:
>
> err(1, "unveil %s", path)
>
> or
>
> err(1, "unveil: %s", path)
>
> I remain undecided between those two, i don't particularily like two :: in
> a error message.
Ok splendid. I've regenerated these, this time including dhcpleased and
slaacd since
On Mon, 3 May 2021 at 10:17, Theo de Raadt wrote:
> So if the messages were just 'unveil %s: error' or 'unveil: %s: error'
> I would be thrilled, as this allows users to realize why the program is
> not working right.
Florian/Theo,
Thanks for the reviews.
So it sounds like err(1, "unveil: %s
Job Snijders wrote:
> @@ -24,15 +24,16 @@ output_csv(FILE *out, struct vrp_tree *v
...
> +
> + if (fprintf(out, "AS%u,%s,%u,%s,%lld\n", v->asid, buf,
> + v->maxlength, v->tal, v->until) < 0)
> return -1;
This needs a cast from time_t to long
Job Snijders wrote:
> AS38971,178.57.71.0/24,24,ripe,2021-05-04T05:39:30Z
This time format is human readable, but these files are largely part
of the machinery. And now they need expensive parsing when used.
Are you sure this shouldn't be an integer since the epoch?
On Mon, May 03, 2021 at 08:37:52AM -0600, Theo de Raadt wrote:
> Job Snijders wrote:
>
> > AS38971,178.57.71.0/24,24,ripe,2021-05-04T05:39:30Z
>
> This time format is human readable, but these files are largely part
> of the machinery. And now they need expensive parsing when used.
>
>
The RTR session was opened with a blocking connect() call. This is rather
bad if the RTR peer does not exist since then bgpd will block until the
connect timed out. This diff makes the connect() call non-blocking.
With this connecting to non-existing RTR servers no longer blocks the main
process.
Florian Obser writes:
> There are 4 or five cases how unveil is called, depending on how
> you count. The permission seems to be always a string literal or NULL.
> The path can be:
>
> 1) a string literal
> 2) a #define
> 3) a variable
> 4) the empty string literal ""
For the archives, I
On Mon, May 03, 2021 at 08:50:36PM -0400, Dave Voutila wrote:
> If debug state in the logging routines isn't set, messages from
> fatal{,x} and warn{,x} don't get flushed to stderr, so running vmd
> un-daemonized can result in the process exiting at startup with no
> discernable message reason
Broke the parsing on Undeadly :-(
Ross
Index: errata69.html
===
RCS file: /cvs/www/errata69.html,v
retrieving revision 1.3
diff -u -p -r1.3 errata69.html
--- errata69.html 3 May 2021 20:12:53 - 1.3
+++ errata69.html
As of kern_time.c v1.150 these syscalls don't need the kernel lock.
ok?
Index: syscalls.master
===
RCS file: /cvs/src/sys/kern/syscalls.master,v
retrieving revision 1.209
diff -u -p -r1.209 syscalls.master
--- syscalls.master 18
On Tue, May 04, 2021 at 03:39:30PM +1000, Ross L Richardson wrote:
> Broke the parsing on Undeadly :-(
Fixed, thanks.
>
> Ross
>
>
> Index: errata69.html
> ===
> RCS file: /cvs/www/errata69.html,v
> retrieving revision 1.3
> diff
If debug state in the logging routines isn't set, messages from
fatal{,x} and warn{,x} don't get flushed to stderr, so running vmd
un-daemonized can result in the process exiting at startup with no
discernable message reason other than the ambiguous exit code (1).
OK?
Index: vmd.c
Florian Obser wrote:
> In this hunk alone you have three out of five and you log them all
> differently. I think this should be unified as
> fatal("unveil(\"%s\", \"%s\")", _PATH_RESCONF, "wc");
> fatal("unveil(\"%s\", \"%s\")", /etc/resolv.conf.tail, "r");
>
Theo de Raadt wrote:
> Florian Obser wrote:
>
> > In this hunk alone you have three out of five and you log them all
> > differently. I think this should be unified as
> > fatal("unveil(\"%s\", \"%s\")", _PATH_RESCONF, "wc");
> > fatal("unveil(\"%s\", \"%s\")", /etc/resolv.conf.tail,
Le Mon, May 03, 2021 at 03:01:13PM +0200, Claudio Jeker a écrit :
> The RTR connect code calls addr2sa() as an argument to connect() but also
> uses the len argument in both calls. It seems in some cases this is
> optimised the wrong way. I think it is better to write this code using two
> steps
Hi all,
The below changeset adds a column containing the soonest expiration
moment to rpki-client(8)'s CSV and JSON output. This can be useful to CA
operators to monitor progression/stalling of the signer pipeline, but
also to relying parties who wish to avoid routing based on stale RPKI
data.
A
Ashton Fagg writes:
> Fixes the following warning:
>
> sysctl.c:835:18: warning: format specifies type 'char *' but the argument has
> type 'void *' [-Wformat]
> string, newval);
> ^~
>
"Theo de Raadt" writes:
> Florian Obser wrote:
>
>> In this hunk alone you have three out of five and you log them all
>> differently. I think this should be unified as
>> fatal("unveil(\"%s\", \"%s\")", _PATH_RESCONF, "wc");
>> fatal("unveil(\"%s\", \"%s\")", /etc/resolv.conf.tail,
On Sun, May 02, 2021 at 09:00:21PM -0400, Ashton Fagg wrote:
> "Theo de Raadt" writes:
>
> > Showing the symbolic name is not doing anywhere else in the tree.
> >
> > Most likely they should be
> >
> >err(1, "unveil: %s", path);
>
> Per Theo's advice, updated diffs are attached.
The RTR connect code calls addr2sa() as an argument to connect() but also
uses the len argument in both calls. It seems in some cases this is
optimised the wrong way. I think it is better to write this code using two
steps like it is done in other places.
OK?
--
:wq Claudio
Index: bgpd.c
Dave Voutila writes:
> The conclusion of my previous fixes to vmd(8) [1] changes the event
> handling in vmctl(8) to support receiving IMSG_VMDOP_TERMINATE_VM_EVENTs
> from the control process. (This removes a XXX comment from vmd.)
>
> For clarity, the messaging logic was changed previously:
>
On Fri, Apr 30, 2021 at 10:03:49PM -0500, Scott Cheloha wrote:
> > On Apr 28, 2021, at 03:47, Claudio Jeker wrote:
> >
> > There are various time fields in the JSON output.
> > last_read, last_write, last_updown on sessions, last_update for rib
> > entries and last_change for sets. Currently
24 matches
Mail list logo
