Re: apmd: fix error message

On Wed, Jul 24, 2019 at 11:21:00PM +0200, Alexander Bluhm wrote: > There is one more %m: > > logmsg(LOG_ERR, "cannot fetch power status: %m"); Thanks, fixed to logmsg(LOG_ERR, "cannot fetch power status: %s", strerror(errno)); This leaves one occurence of "%m"

bgpd RIB rework part 4

This is a bit bigger then planned but the change is a bit more substantial. First of all this removes 'route-collector yes|no' from the config. The old route-collector mode is removed because it causes confusion and the same can be done by using 'rde rib Loc-RIB no evaluate'. On top of this it is

Re: unveil in process accounting and lastcomm

On Thu, Jul 18, 2019 at 04:13:10PM +0200, Alexander Bluhm wrote: > $ lastcomm | grep -e '-[A-Z]U' > pflogd -FU root__ 0.00 secs Thu Jul 18 14:19 (2:33:22.00) Oops, I have forgotten to show the userland part of my diff. Do we want unveil violators in the daily mail? We can

Re: unveil in process accounting and lastcomm

On Thu, Jul 25, 2019 at 12:00:48PM +0200, Alexander Bluhm wrote: > Do we want unveil violators in the daily mail? We can turn it off > if we get too many false positives. Janne Johansson recommend to mention lastcomm(1) in unveil(2) man page. Diff for daily, lastcomm(1), unveil(2). Kernel has

Re: zero tmpkeyiv in openssl enc

Sure, looks fine in this micro context so maybe someone copying code from here as an example will do better. Though note that wider-scoped key/iv still contain the key material after EVP_CipherInit_ex and so on. Doesn't appear we've sprinkled many explicit_bzero's into openssl(1) in general given

Re: unveil in process accounting and lastcomm

On Thu, 25 Jul 2019 12:00:48 +0200, Alexander Bluhm wrote: > Do we want unveil violators in the daily mail? We can turn it off > if we get too many false positives. I think so. If it becomes annoying we can turn it off by default. - todd

Re: unveil in process accounting and lastcomm

Todd C. Miller wrote: > On Thu, 25 Jul 2019 12:00:48 +0200, Alexander Bluhm wrote: > > > Do we want unveil violators in the daily mail? We can turn it off > > if we get too many false positives. > > I think so. If it becomes annoying we can turn it off by default. I'm not sure how any of

Re: itimerdecr(): simplify code

On Thu, 25 Jul 2019 11:00:03 -0500, Scott Cheloha wrote: > > However, if the "itp->it_value.tv_sec >= 0" is true, that means > > that "itp->it_value.tv_sec" must also be true. > > which is not correct, as itp->it_value.tv_sec could be zero. Sigh, still too early I guess. > What we really want

add pkg-config files for readline, editline, ncurses

mrsh[1], a cross-platform shell, can use readline in interactive mode. It's configure script detects the presence of readline using pkg-config(1). Thus, this patch adds a pkg-config file for our readline. I just copied over the generate_pkgconfig.sh script/make rules found in other libraries and

Re: itimerdecr(): simplify code

On Thu, 25 Jul 2019 09:53:42 -0500, Scott Cheloha wrote: > Woohoo, slow morning, nearly missed that bug. Your conditional > is incorrect because it rejects timevals of whole seconds, e.g. > tv_sec == 1 and tv_usec == 0. Whoops, too early for me I guess. However, as I think about this further,

Re: itimerdecr(): simplify code

On Thu, Jul 25, 2019 at 09:37:20AM -0600, Todd C. Miller wrote: > On Thu, 25 Jul 2019 09:53:42 -0500, Scott Cheloha wrote: > > > Woohoo, slow morning, nearly missed that bug. Your conditional > > is incorrect because it rejects timevals of whole seconds, e.g. > > tv_sec == 1 and tv_usec == 0. >

Re: unveil in process accounting and lastcomm

On Thu, Jul 18, 2019 at 05:44:21PM -0400, Bryan Steele wrote: > On Thu, Jul 18, 2019 at 11:46:46AM -0400, Bryan Steele wrote: > > On Thu, Jul 18, 2019 at 04:13:10PM +0200, Alexander Bluhm wrote: > > > Hi, > > > > > > Can we track unveil(2) violators in process accounting lastcomm(1)? > > > This

Re: unveil in process accounting and lastcomm

On Thu, Jul 25, 2019 at 10:06:52AM -0400, Bryan Steele wrote: > On Thu, Jul 18, 2019 at 05:44:21PM -0400, Bryan Steele wrote: > > On Thu, Jul 18, 2019 at 11:46:46AM -0400, Bryan Steele wrote: > > > On Thu, Jul 18, 2019 at 04:13:10PM +0200, Alexander Bluhm wrote: > > > > Hi, > > > > > > > > Can we

Re: itimerdecr(): simplify code

On Thu, 25 Jul 2019 09:47:53 -0500, Scott Cheloha wrote: > I've been thinking for a while about adding another macro to sys/time.h > to handle this very common case, "timerisexpired": > > #define timerisexpired(tv) ((tv)->tv_sec < 0 || !timerisset((tv))) > > for chipping away at relative

bgpd, change order of filter_set imsgs

This changes the way filtersets are passed on config reloads (and also for bgpctl network commands). Now the sets are sent first and then moved into the object that follows the filter_set with TAILQ_CONCAT(). The benefit of this is that IMSG_RECONF_FILTER will have the full rule ready when

Re: itimerdecr(): simplify code

On Wed, 24 Jul 2019 19:05:16 -0500, Scott Cheloha wrote: > We can simplify the itimerdecr() code with the sys/time.h macros. > I think this is a lot easier to decipher. > > With the macros we don't need special logic to correctly handle the > reload if the decrement exceeds the time remaining in

Re: itimerdecr(): simplify code

On Thu, Jul 25, 2019 at 08:33:25AM -0600, Todd C. Miller wrote: > On Wed, 24 Jul 2019 19:05:16 -0500, Scott Cheloha wrote: > > > We can simplify the itimerdecr() code with the sys/time.h macros. > > I think this is a lot easier to decipher. > > > > With the macros we don't need special logic to

Re: itimerdecr(): simplify code

On Thu, Jul 25, 2019 at 09:47:53AM -0500, Scott Cheloha wrote: > On Thu, Jul 25, 2019 at 08:33:25AM -0600, Todd C. Miller wrote: > > On Wed, 24 Jul 2019 19:05:16 -0500, Scott Cheloha wrote: > > > > > We can simplify the itimerdecr() code with the sys/time.h macros. > > > I think this is a lot

remove duplicate definitions of LAPIC_ID_MASK and LAPIC_ID_SHIFT

ok? Index: sys/arch/amd64/include/i82489reg.h === RCS file: /cvs/src/sys/arch/amd64/include/i82489reg.h,v retrieving revision 1.4 diff -u -p -u -p -r1.4 i82489reg.h --- sys/arch/amd64/include/i82489reg.h 21 Jul 2015 04:48:33 -

Remove some sigvec Xr's

We should only cross-reference the obsolete sigvec(3) function from the signal compat manuals and sigaction(2). This also syncs the SEE ALSO section in ualarm(3) match that of alarm(3). We could reference signal(3) in csh instead of sigaction(2) if that's what people prefer. - todd Index:

signify: -z implies -q

Poking around signify and learned that `verifyzdata` calls `verifymsg` with `1` hardcoded in the `quiet` parameter. I do appreciate that there is a distinction between case 'z' setting `quiet = 1` vs `verifyzdata` passing `1` as an argument, so maybe this diff doesn't quiet capture a truth:

Re: signify: -z implies -q

On 2019-07-26 03.02.43 +, Mike Burns wrote: > Poking around signify and learned that `verifyzdata` calls `verifymsg` > with `1` hardcoded in the `quiet` parameter. > > I do appreciate that there is a distinction between case 'z' setting > `quiet = 1` vs `verifyzdata` passing `1` as an

Re: remove duplicate definitions of LAPIC_ID_MASK and LAPIC_ID_SHIFT

On Thu, Jul 25, 2019 at 4:44 PM Kevin Lo wrote: > ok? > Yes, please. guenther@

Re: Remove some sigvec Xr's

On Thu, Jul 25, 2019 at 1:04 PM Todd C. Miller wrote: > We should only cross-reference the obsolete sigvec(3) function from > the signal compat manuals and sigaction(2). > > This also syncs the SEE ALSO section in ualarm(3) match that of > alarm(3). > ok guenther@ We could reference signal(3)