Re: rpki-client http keep-alive support

2021-04-16 Thread Theo de Raadt
> The benefit of using keep-alive is less CPU time wasted on constant TLS > handshakes. I did not notice any speed improvements. And... not bouncing between inconsistant CA endpoints. Further discussion about that problem will occur elsewhere.

Re: relayd regress tcp performance

2021-04-15 Thread Theo de Raadt
> Should we back it out for release? Diff below. I think so.

Re: rpki-client vs expat API madness

2021-04-12 Thread Theo de Raadt
> + line = XML_GetCurrentLineNumber(p); I think you can simplify your larger diff and avoid the temporary variable by doing: warnx("%s: XML error at line %llu: %s", s->local, (unsigned long long)XML_GetCurrentLineNumber(p),

Re: wcwidth of soft hyphen

2021-04-05 Thread Theo de Raadt
So, your argument is that displays should remain broken forever. > The bug in NetBSD and Linux should be fixed, but that's off-topic here. If you cannot explain how this problem is going to be fixed (reversed) in these opposing ecosystems (and it is not just Linux and NetBSD), then you've closed

Re: monotonic time going back by wrong skews

2021-04-05 Thread Theo de Raadt
Mark Kettenis wrote: > Before you go further down this path, please realize that "fixing" the > TSC this way is racy in much the same ways as determining the skew is. > If an SMM or a VM exit happens between reading the TSC and the actual > write to the MSR, the new value of the TSC will be off

Re: printf.9: document limited conversion specification syntax

2021-04-04 Thread Theo de Raadt
Yep, all good Jason McIntyre wrote: > yep, better than mine. ok > jmc > > On 4 April 2021 14:41:13 BST, Klemens Nanni wrote: > >On Sun, Apr 04, 2021 at 07:17:27AM +0100, Jason McIntyre wrote: > >> On Sun, Apr 04, 2021 at 01:22:23AM +0200, Klemens Nanni wrote: > >> > @@ -119,6 +119,17 @@ send

Re: rpki-client: don't leak d->uri in add_delta()

2021-04-01 Thread Theo de Raadt
Yep. Theo Buehler wrote: > d->uri was allocated by xstrdup(), so needs to be freed. Was going back > and forth between the below and adding free(d->uri). > > Index: rrdp_notification.c > === > RCS file:

Re: rpki-client use setproctitle(3)

2021-03-31 Thread Theo de Raadt
Absolutely -- this allows me to skip a few steps when tracing. Claudio Jeker wrote: > It is time to use setproctitle() in rpki-client. > Right now there are three processes, soon it will be four. > This should help identify the different processes. > I did not change the proc title of the main

Re: disable PPP_BSDCOMP by default

2021-03-25 Thread Theo de Raadt
Balder Oddson wrote: > On Thu, Mar 25, 2021 at 03:40:15PM -0600, Theo de Raadt wrote: > > Stuart Henderson wrote: > > > > > > Not having read the code, case in point on principle, I'm arguing that > > > > there should be solid reasoning to enable it b

Re: disable PPP_BSDCOMP by default

2021-03-25 Thread Theo de Raadt
Stuart Henderson wrote: > > Not having read the code, case in point on principle, I'm arguing that > > there should be solid reasoning to enable it by default, as those with a > > need for it can certainly enable it and build a kernel. > > It's not that simple, using a custom kernel means you

Re: Permit reading kern.somaxconn with unix pledge

2021-03-25 Thread Theo de Raadt
I have reviewed all the pledge using programs in the tree, and I do not see additional risk from this change. Who wants to take care of the commit? Josh Rickmar wrote: > The kern.somaxconn sysctl was previously permitted under the inet > pledge, which allowed pledged Go applications to listen

Re: disable PPP_BSDCOMP by default

2021-03-25 Thread Theo de Raadt
No way for this diff. This is the wrong way. Surely there are ways to disable compression negotion on specific sessions, but removing the code from the kernel is the wrong knob. Balder Oddson wrote: > Compression in PPP was great in the age of ISDN to increase speeds. > The more common use

Re: sdmmc(4) off-by-one on boundary check

2021-03-24 Thread Theo de Raadt
Marcus Glocker wrote: > On Tue, Mar 23, 2021 at 09:52:42AM -0600, Theo de Raadt wrote: > > > Mark Kettenis wrote: > > > > > > > Index: sys/dev/sdmmc/sdmmc_scsi.c > > > > > ==

Re: sdmmc(4) off-by-one on boundary check

2021-03-23 Thread Theo de Raadt
Mark Kettenis wrote: > > > Index: sys/dev/sdmmc/sdmmc_scsi.c > > > === > > > RCS file: /cvs/src/sys/dev/sdmmc/sdmmc_scsi.c,v > > > retrieving revision 1.59 > > > diff -u -p -u -p -r1.59 sdmmc_scsi.c > > > ---

Re: sdmmc(4) off-by-one on boundary check

2021-03-23 Thread Theo de Raadt
That is what I envisioned. It is just an off-by-one on the bounds check. Marcus Glocker wrote: > On Tue, Mar 23, 2021 at 08:29:06AM -0600, Theo de Raadt wrote: > > > Marcus Glocker wrote: > > > > > Index:

Re: sdmmc(4) off-by-one on boundary check

2021-03-23 Thread Theo de Raadt
Marcus Glocker wrote: > Index: sys/dev/sdmmc/sdmmc_scsi.c > === > RCS file: /cvs/src/sys/dev/sdmmc/sdmmc_scsi.c,v > retrieving revision 1.59 > diff -u -p -u -p -r1.59 sdmmc_scsi.c > --- sys/dev/sdmmc/sdmmc_scsi.c15 Oct 2020

Re: update explicit_bzero test to not assume SIGSTKSZ to be constant

2021-03-22 Thread Theo de Raadt
Fine with me. The malloc'd memory is not identical to bss memory, but this still matches the spirit of the test. Brent Cook wrote: > In the next version of Linux glibc, SIGSTKSZ is defined at runtime if > source is built with _GNU_SOURCE. On LibreSSL-portable, this is set to > bring in

Re: arm64: make cwfg(4) report battery information to apm(4)

2021-03-21 Thread Theo de Raadt
Klemens Nanni wrote: > > So which is better: > > > > (1) try to emit some information for the people who quicky-use the apm > > interface > > > > (2) change apm to not print those lines on architectures where we are > > unsure. > > > > I think (1) is acceptable for a tool which has never

Re: arm64: make cwfg(4) report battery information to apm(4)

2021-03-21 Thread Theo de Raadt
The sensor framework generally does not know where a sensor is. A sensor could reside on some device which has been plugged in, rather than be the primary sensor. But the users of apm are only hoping for best effort. meaning "some information", not "perfect information". Many PC BIOS have lied

Re: apm, apmd: ship manual pages on powerpc64

2021-03-21 Thread Theo de Raadt
Jason McIntyre wrote: > On Sat, Mar 20, 2021 at 07:29:11PM -0600, Theo de Raadt wrote: > > There is a pattern we've followed in the past, that when a manpage applies > > to more than 2 (or 3?) architectures, then we simply make it MI. > > > > So MANSUBDIR would get

Re: vmm crash on 6.9-beta

2021-03-20 Thread Theo de Raadt
Otto Moerbeek wrote: > On Fri, Mar 19, 2021 at 04:15:31PM +, Stuart Henderson wrote: > > > On 2021/03/19 17:05, Jan Klemkow wrote: > > > Hi, > > > > > > I had the same issue a few days ago a server hardware of mine. I just > > > ran 'cvs up'. So, it looks like a generic bug in FFS and

Re: apm, apmd: ship manual pages on powerpc64

2021-03-20 Thread Theo de Raadt
There is a pattern we've followed in the past, that when a manpage applies to more than 2 (or 3?) architectures, then we simply make it MI. So MANSUBDIR would get deleted, and then the sets would be updated. People with old systems will retain the old files, but I think man(1) selects the MI

Re: mg: Fix Coverity Scan warning: Insecure data handling

2021-03-09 Thread Theo de Raadt
Todd C. Miller wrote: > On Tue, 09 Mar 2021 20:14:19 +, Mark Lumsden wrote: > > > Here is a diff from Joachim Wiberg's version of mg. > > > > "The strlcpy() function is guaranteed to never copy more than 'len - 1' > > bytes, so there is no need to check if we copied more. This is a bogus >

Re: sendsyslog kernel buffer

2021-03-08 Thread Theo de Raadt
Vitaliy Makkoveev wrote: > > On Mon, Mar 08, 2021 at 01:37:51AM +0300, Vitaliy Makkoveev wrote: > >> I wonder they were not buffered. But does it make sense to drop the > >> most recent messages? > > > > The oldest message should be kept. In my experience you get most > > information why

Re: sendsyslog kernel buffer

2021-03-08 Thread Theo de Raadt
Alexander Bluhm wrote: > I hope to have addressed all issues. > > On Sun, Mar 07, 2021 at 11:50:24AM +, Visa Hankala wrote: > > This copyin() can also result in copying the buffer from userspace twice. > > This might not be a problem with log data though. > > Is double copyin a problem? I

Re: safer sigcode page filling

2021-03-08 Thread Theo de Raadt
Miod Vallat wrote: > > It would be better if it contained "trap" instructions. We still don't > > have an ideal way of doing that tho. > > That would work, but that would make the code a bit more complicated. > And I'm not sure it's worth doing anyway. Running into an unmapped page > will

Re: safer sigcode page filling

2021-03-08 Thread Theo de Raadt
I see I misunderstood, and this does what is desired. Miod Vallat wrote: > The code responsible for filling a page with repeated copies of the > signal trampoline code assumes that PAGE_SIZE % sigfillsz == 0. > > While this is true on all currently supported OpenBSD platforms, this > might not

Re: safer sigcode page filling

2021-03-08 Thread Theo de Raadt
I guess the rest of the page contains 0? It would be better if it contained "trap" instructions. We still don't have an ideal way of doing that tho. Miod Vallat wrote: > The code responsible for filling a page with repeated copies of the > signal trampoline code assumes that PAGE_SIZE %

Re: Elaborate on dhcpleased(8) requirement to interface state

2021-03-07 Thread Theo de Raadt
Paul Kelly wrote: > So...here is a proposal for updating various man pages to try help > others who make a similar migration to dhcpleased. It's a bit of a > scattershot approach and the wording can probably be improved, but it is > hopefully consistent with the existing pattern for describing

Re: Ignore /tmp/.Xauth* in daily

2021-03-06 Thread Theo de Raadt
Matthieu Herrb wrote: > Linux, systemd and XDG have inventend this /run/user/$uid tmpfs that > is created automagically and they use that in place of /tmp for > volatile things that don't beloing to $HOME, but this is not a can of > worms I want to open now. Awesome, another directory to drop

Re: Ignore /tmp/.Xauth* in daily

2021-03-06 Thread Theo de Raadt
Vadim Zhukov wrote: > сб, 6 мар. 2021 г. в 20:53, Theo de Raadt : > > > > Vadim Zhukov wrote: > > > > > > The backup dir can be configured to something else, but it needs to be > > > > writeable by the user whois login in. It could be a subdir o

Re: Ignore /tmp/.Xauth* in daily

2021-03-06 Thread Theo de Raadt
Vadim Zhukov wrote: > > The backup dir can be configured to something else, but it needs to be > > writeable by the user whois login in. It could be a subdir of /tmp (if > > the rc.d script takes care of creating it) or I can remove that > > feature from xenodm and fail the login if /home is not

Re: Ignore /tmp/.Xauth* in daily

2021-03-06 Thread Theo de Raadt
Matthieu Herrb wrote: > On Sat, Mar 06, 2021 at 09:56:34AM -0700, Theo de Raadt wrote: > > Matthieu Herrb wrote: > > > > > On Fri, Mar 05, 2021 at 09:10:32PM +0300, Vadim Zhukov wrote: > > > > чт, 4 мар. 2021 г. в 02:02, Vadim Zhukov : > > > >

Re: Ignore /tmp/.Xauth* in daily

2021-03-06 Thread Theo de Raadt
Matthieu Herrb wrote: > On Fri, Mar 05, 2021 at 09:10:32PM +0300, Vadim Zhukov wrote: > > чт, 4 мар. 2021 г. в 02:02, Vadim Zhukov : > > > > > > Hello all. > > > > > > Since xenodm has DEF_USER_AUTH_DIR set to "/tmp", we need to ignore > > > /tmp/.Xauth* in daily cleanup, don't we? > > > > > >

Re: pcidump(8): add missing PCI classes

2021-03-05 Thread Theo de Raadt
Fix dump() to convert subclass == NULL into something else, or maybe the fix should be in pci_subclass() itself. Converting NULL to %s into "(null)" is non-standard and has led to sloppier code, there have been efforts improve the whole tree enough that we could one day simply crash on such

Re: snapshot upgrade hangs with "iwm0: DAD detected duplicate"

2021-03-02 Thread Theo de Raadt
It is a bug in dhclient introduced a few days ago. Thomas L. wrote: > Hi, > > current snapshot hangs during sysupgrade after rootfs mount with > > iwm0: DAD detected duplicate IPv6 address fe80:1::164f:8aff:fe25:dbef: NS > in/out=1/1, NA in=0 > iwm0: DAD complete for

Re: rpki-client, unify err() for out of memory situation

2021-03-02 Thread Theo de Raadt
Theo Buehler wrote: > On Tue, Mar 02, 2021 at 02:09:37PM +0100, Claudio Jeker wrote: > > This diff just brings all err(3) calls for out of memory situations to one > > form: err(1, NULL); > > It is not very helpful to tell if malloc, strdup or asprintf failed with no > > mem. Just one common

Re: Mesa leak in intel iris driver

2021-02-27 Thread Theo de Raadt
Stuart Henderson wrote: > On 2021/02/27 11:50, Theo de Raadt wrote: > > To see the problem, It is better to look at "UVM amap" in "vmstat -m" > > > > UVM amap 32835 1690K 2636K 78644K 268129080 > > 16,32,64,128,256,512,1024,409

Re: Mesa leak in intel iris driver

2021-02-27 Thread Theo de Raadt
Theo Buehler wrote: > On Sat, Feb 27, 2021 at 12:21:35AM +1100, Jonathan Gray wrote: > > Bring in a change which was backported to Mesa 20.1 but not 20.0. > > This is for inteldrm with >= gen8/broadwell hardware. > > /var/log/Xorg.0.log with 'DRI driver: iris' and 'xdriinfo' will > > show

Re: Userspace syscall dispatch

2021-02-26 Thread Theo de Raadt
There is nothing beyond SIGILL. Why would we want such a thing? We are operating in a source-code-available world. Why would any one us want to encourage a must-run-binaries future? The history of syscall-compatibility in BSD operating systems has been forgotten. Back in the NetBSD days,

Re: have m_copydata use a void * instead of caddr_t

2021-02-24 Thread Theo de Raadt
I agree. Alexander Bluhm wrote: > On Wed, Feb 24, 2021 at 04:27:03PM +1000, David Gwynne wrote: > > it's a start though. cocci and i came up with this to push in after. > > Less casting is better. OK bluhm@ > > > Index: arch/armv7/sunxi/sxie.c > >

Re: rpki-client don't clobber poll events

2021-02-23 Thread Theo de Raadt
Definately! It will round-trip through poll() less often. Claudio Jeker wrote: > It is perfectly fine to wait for read and write at the same time. > The code in rpki-client should do that too, I think it will not matter > but it is what I intended. > > -- > :wq Claudio > > Index: main.c >

Re: sparc64/clock.c: use ANSI-style function definitions

2021-02-23 Thread Theo de Raadt
Scott Cheloha wrote: > Any reason not to ANSIfy these? While we're here we can kill some > ARGUSED comments, too. Absolutely, go ahead with that. > I don't have a sparc64 machine so I'd appreciate a test compile. It compiles fine.

Re: rpki-client lock down rsync process further

2021-02-23 Thread Theo de Raadt
OK with me. I'll say it again, the unveils in here are misguided. Almost as misguided as the mmap's (which prevents large file transfer, and there are other problems..) Claudio Jeker wrote: > There is no need for cpath or the unveil of . in the rsync process. > That process just does

Re: occasional SSIGSEGV on C++ exception handling

2021-02-22 Thread Theo de Raadt
Bryan Steele wrote: > On Tue, Feb 23, 2021 at 06:23:22PM +1100, Jonathan Gray wrote: > > On Tue, Feb 23, 2021 at 08:10:54AM +0100, Otto Moerbeek wrote: > > > On Mon, Feb 22, 2021 at 08:58:07PM -, Miod Vallat wrote: > > > > > > > > > > > > No problem, real-life often takes precedence. > > >

Re: ping graphical display

2021-02-20 Thread Theo de Raadt
Stuart Henderson wrote: > On 2021/02/20 09:20, Remi Locherer wrote: > > On February 19, 2021 8:56:31 PM UTC, Stuart Henderson > > wrote: > > >Canvassing opinions on having . and ! this way around. I'm using . for > > >response, ! for no response, which makes more sense to me but it's been > >

Re: doas needs doas.conf

2021-02-19 Thread Theo de Raadt
Jan Stary wrote: > Say explicitly that doas needs doas.conf to exist, > and point to the example one. > > Jan > > > Index: doas.1 > === > RCS file: /cvs/src/usr.bin/doas/doas.1,v > retrieving revision 1.25 > diff -u -p

Re: if calloc() needs nmemb and size, why doesn't freezero()?

2021-02-19 Thread Theo de Raadt
Luke Small wrote: > malloc(3) already speaks to programmers who might use int multiplication and > telling > them to test for int multiplication overflow in malloc(), so you presume that > they are > already prepared to use something smaller than size_t, when you could have > just said: >

Re: malloc junking tweaks

2021-02-18 Thread Theo de Raadt
This diff will land in snapshots.

Re: if calloc() needs nmemb and size, why doesn't freezero()?

2021-02-18 Thread Theo de Raadt
Luke Small wrote: > However, calloc(ptr, nmemb, size) may have been called using smaller int > variable types which would overflow when multiplied. In which case the allocation would not have succeeded. > Where if the variables > storing the values passed to nmemb and size are less than or

Re: RTR support for bgpd

2021-02-17 Thread Theo de Raadt
Claudio Jeker wrote: > Sure. Lets do that. I just checked, bgpd does not use getservbyname() for > the BGP connection either (it uses a define). Maybe that should be changed > as well. Yeah, no kidding.

Re: RTR support for bgpd

2021-02-17 Thread Theo de Raadt
Regarding port 323, +If not specified the default +.Ic port +is +.Em 323 . and +rtr: RTR address { + currtr = get_rtr(&$2); + currtr->remote_port = 323; + if (insert_rtr(currtr) == -1) { +

Re: if calloc() needs nmemb and size, why doesn't freezero()?

2021-02-17 Thread Theo de Raadt
> > Would it be too much hand-holding to put in the manpage that to avoid > potential > > freeezero() integer overflow, > > it may be useful to run freezero() as freezero((size_t)nmemb * > (size_t)size); > > Wow, Those casts make it very clear you don't understand C, if you do > that kind

Re: if calloc() needs nmemb and size, why doesn't freezero()?

2021-02-17 Thread Theo de Raadt
Luke Small wrote: > I guess I always thought there'd be some more substantial overflow mitigation. You have to free with the exact same size as allocation. nmemb and size did not change. The math has already been checked, and regular codeflows will store the multiple in a single variable

Re: if calloc() needs nmemb and size, why doesn't freezero()?

2021-02-17 Thread Theo de Raadt
Luke Small wrote: > if calloc() and recallocarray() needs nmemb and size, why doesn't > freezero()? > > Should there be a freeczero(size_t nmemb, size_t size) ? Performing the nmemb*size overflow detection a second time provides no benefit.

Re: distrib: arm64: remove gratitious customization from mr.fs

2021-02-14 Thread Theo de Raadt
I like that. Sebastien Marie wrote: > Hi, > > arm64 ramdisk has customization in mr.fs target, in order to create > usr/mdec/pine64 and usr/mdec/rpi directories (files will be copied > inside them by runlist.sh). > > I will argue that mr.fs target isn't the place for such per-arch >

Re: distrib: make rdsetroot -x to work again

2021-02-14 Thread Theo de Raadt
ESTDIR}/usr/mdec/cdboot > ${.OBJDIR}/cd-dir/${OSREV}/${MACHINE}/cdboot > mkhybrid -a -R -T -L -l -d -D -N -o ${.OBJDIR}/${CDROM} \ > - -A "OpenBSD ${OSREV} amd64 bootonly CD" \ > + -A "OpenBSD ${OSREV} ${MACHINE} bootonly CD" \ > -P &qu

Re: distrib: reduce differences between archs: use ${MACHINE} when possible

2021-02-14 Thread Theo de Raadt
Sebastien Marie wrote: > Please note I am unsure about sgi: disklabel -w is using > "OpenBSD/sgi " as packid, and I changed it to "OpenBSD/${MACHINE}". > But the packid used isn't uniform across archs, so it might not matter. I think you mean "volid", this is the -V option. The thing to

Re: random manual pages

2021-02-12 Thread Theo de Raadt
Nelson H. F. Beebe wrote: > Thanks for the comments, Theo. > > I wasn't clear in my posting about distinguishing deterministic from > nondeterministic generators. The former are required for reproducible > simulations Perhaps. Even then they often criminally abused, ie. Neil Ferguson --

Re: random manual pages

2021-02-12 Thread Theo de Raadt
Hi Nelson - Nelson H. F. Beebe wrote: > Thanks, Theo, for this good advice about random-number generators: In this discussion, I made no comments about "random-number generators". Instead I commented on "deterministic generators", which have been incorrectly placed inside subsystems claiming

random manual pages

2021-02-11 Thread Theo de Raadt
Reading a recent junk-thread, I realized the algorithms for rand and random have changed numerous times since the late 80's. As such you cannot trust that a seed given 20 years ago, produces the same sequence today. I did a rough study of the commits to our versions. Other operating systems

Re: isakmpd link dynamically

2021-02-10 Thread Theo de Raadt
Oh wait I misread. When I re-ordered rc in Slovenia many years ago, I got it right. So, I think we should move these two daemons. Addendum: shared library linking increases the .so footprint, and cross-.so ROP attacks are a tiny bit more difficult in OpenBSD.

Re: isakmpd link dynamically

2021-02-10 Thread Theo de Raadt
Alexander Bluhm wrote: > Hi, > > Every time we ship a libcrypto erratum, we have to relink isakmpd. > I think that isakmpd and iked are in /sbin due to a historic mistake. > Probably it is for people who mount /usr via NFS over IPsec. That was the reason originally. Today I am not sure it

Re: diff: tcp ack improvement

2021-02-08 Thread Theo de Raadt
Claudio Jeker wrote: > On Mon, Feb 08, 2021 at 07:46:46PM +0100, Alexander Bluhm wrote: > > On Mon, Feb 08, 2021 at 07:03:59PM +0100, Jan Klemkow wrote: > > > On Mon, Feb 08, 2021 at 03:42:54PM +0100, Alexander Bluhm wrote: > > > > On Wed, Feb 03, 2021 at 11:20:04AM +0100, Claudio Jeker wrote: >

Re: diff: tcp ack improvement

2021-02-08 Thread Theo de Raadt
Yes it is unacceptable. Alexander Bluhm wrote: > On Wed, Feb 03, 2021 at 11:20:04AM +0100, Claudio Jeker wrote: > > Just commit it. OK claudio@ > > If people see problems we can back it out again. > > This has huge impact on TCP performance. > >

Re: execve -1 errno 12 Cannot allocate memory

2021-02-02 Thread Theo de Raadt
Philippe Meunier wrote: > Theo de Raadt wrote: > >Otto Moerbeek wrote: > >> Fixing a particluar issue is fine, but more important is an assessment > >> it does not break other things. In particular, does this limit the VM > >> for data available to any pro

Re: execve -1 errno 12 Cannot allocate memory

2021-02-01 Thread Theo de Raadt
Otto Moerbeek wrote: > On Mon, Feb 01, 2021 at 10:24:31PM -0500, Philippe Meunier wrote: > > > Anyone? > > Fixing a particluar issue is fine, but more important is an assessment > it does not break other things. In particular, does this limit the VM > for data available to any program (which

Re: pfsync(4), mention about carp demotion

2021-02-01 Thread Theo de Raadt
It should use 'demotion counter' everywhere. Stuart Henderson wrote: > On 2021/02/01 14:32, Klemens Nanni wrote: > > On Mon, Feb 01, 2021 at 01:13:20PM +, Stuart Henderson wrote: > > > I think this needs documenting somewhere; I had to use the source to > > > remember what triggered

Re: grep: add --null flag

2021-01-24 Thread Theo de Raadt
Stuart Henderson wrote: > On 2021/01/24 12:10, Theo de Raadt wrote: > > I completely despise that the option is called "--null". > > > > Someone was a complete idiot. > > gnu grep has both --null and -z for this (why do they do that?!). > If it's adde

Re: grep: add --null flag

2021-01-24 Thread Theo de Raadt
I completely despise that the option is called "--null". Someone was a complete idiot. Ted Unangst wrote: > On 2021-01-22, Omar Polo wrote: > > > > quasi three-weekly ping. > > > > Is this such a bad idea? > > This seems reasonable. I think there's no need to change print line calls >

Re: [PATCH v3 (resend)] tee: Add -q, --quiet, --silent option to not write to stdout

2021-01-24 Thread Theo de Raadt
Otto Moerbeek wrote: > On Sun, Jan 24, 2021 at 01:18:46PM +0100, Alejandro Colomar wrote: > > > This is useful for using tee to just write to a file, > > at the end of a pipeline, > > without having to redirect to /dev/null > > > > Example: > > > > echo 'foo' | sudo tee -q /etc/foo; > > > >

Re: explicit_bzero csalt

2021-01-21 Thread Theo de Raadt
I guess so, though I cannot imagine a program-context where bcrypt_newhash stack's can be leaked in a dangerous way. Programs that create these hashes end up knowing more, or having more power. Peter J. Philipp wrote: > Hi, > > On IRC, someone and I were arbitrarily going through bcrypt.c and

Re: vacation.1: correct .forward file example

2021-01-21 Thread Theo de Raadt
Jason McIntyre wrote: > On Thu, Jan 21, 2021 at 12:47:15PM +, Stuart Henderson wrote: > > On 2021/01/21 12:43, Jason McIntyre wrote: > > > On Thu, Jan 21, 2021 at 11:15:48AM +0100, Martin Vahlensieck wrote: > > > > Hi > > > > > > > > I think the backslash at the beginning of the line is an

Re: [PATCH] Make cat(1) and split(1) reference each other

2021-01-10 Thread Theo de Raadt
Donovan Watteau wrote: > Theo de Raadt wrote: > > I disagree with this. > > > > Because next you'll be asking for the ls manpage to list "rm" and "touch"... > > That's not my personal intent no, but I get your point. > > concatenating/sp

Re: [PATCH] Make cat(1) and split(1) reference each other

2021-01-10 Thread Theo de Raadt
I disagree with this. Because next you'll be asking for the ls manpage to list "rm" and "touch"... Donovan Watteau wrote: > Hi, > > Ten years ago, a teacher of mine asked why "the command which > concatenates files never mentions the command which splits files". > > Ten years later, I still

Re: compress sparc64 bsd.rd

2021-01-02 Thread Theo de Raadt
Miod Vallat wrote: > Up until 6.5, sparc64 bsd.rd were gzipped kernels. This got lost during > the Great Installation Media Unification of the 6.6 release cycle, and > since then bsd.rd are uncompressed. > > The following diff ought to fix this and bring back sparc64 netboot > times down to

Re: extern int optreset not needed

2020-12-27 Thread Theo de Raadt
Take note this change is fine for modern POSIX systems, but there are earlier systems where unistd.h did not contain these externs. That is why these externs were placed. As such, this change makes the software less portable against such ancient systems. At this point, I'm fine with that. Jan

Re: smtpd: trim down on filter processes

2020-12-27 Thread Theo de Raadt
fork_filter_process() does not feel like the right name for the function anymore. Take note the exit value of the process (as seen by wait elsewhere) will be subtly differe after this conversion from system() to execve(). Upon failure, rather than being 127, it is now 1. Martijn van Duren

Re: Rename SIMPLEQ_ to STAILQ_, diff 1/7

2020-12-26 Thread Theo de Raadt
Christian Weisgerber wrote: > Theo de Raadt: > > > What is lacking in this converstation is the justification. > > Why? > > Providing STAILQ in OpenBSD will simplify porting to OpenBSD. > (Reality check: There is one port affected by this.) > > Switchin

Re: Rename SIMPLEQ_ to STAILQ_, diff 1/7

2020-12-26 Thread Theo de Raadt
Todd C. Miller wrote: > On Sat, 26 Dec 2020 10:45:21 -0700, "Theo de Raadt" wrote: > > > > This diff renames SIMPLEQ_* to STAILQ_* in /usr/src/sys/sys to unify > > > with FreeBSD and Linux. > > > > More than half the stuff being touched doesn't ex

Re: Rename SIMPLEQ_ to STAILQ_, diff 1/7

2020-12-26 Thread Theo de Raadt
Denis Fondras wrote: > Le Sat, Dec 26, 2020 at 06:23:41PM +0100, Mark Kettenis a écrit : > > > > This diff renames SIMPLEQ_* to STAILQ_* in /usr/src/sys/sys to unify > > > > with FreeBSD and Linux. > > > > > > > > I added aliases at the end of queue.h to avoid breaking base too much. > > > >

Re: Rename SIMPLEQ_ to STAILQ_, diff 1/7

2020-12-26 Thread Theo de Raadt
> This diff renames SIMPLEQ_* to STAILQ_* in /usr/src/sys/sys to unify > with FreeBSD and Linux. More than half the stuff being touched doesn't exist in FreeBSD or Linux. SIMPLEQ_ goes back to 97. Why is this the direction to go??? Denis, you appear to be making an arbitrary decision and not

Re: Rename SIMPLEQ_ to STAILQ_, diff 1/7

2020-12-26 Thread Theo de Raadt
Martin Pieuchot wrote: > On 26/12/20(Sat) 18:23, Mark Kettenis wrote: > > [...] > > NetBSD and Solaris both provide SIMPLEQ_* and STAILQ_*. I'm not sure > > removing one in favour of the other is helpful. > > It would be helpful to provide both set of macros for some time to ease > the

Re: acme-client(1): dns-01

2020-12-24 Thread Theo de Raadt
Daniel Moch wrote: > I like being able to specify a user to run the script as. In my case > it's sufficient to run the script as 'nobody'. Regarding this second sentence: never use nobody for another purpose. It has other purposes, and if people follow this pattern of using nobody then

Re: tsleep(9): add global "nowake" channel

2020-12-23 Thread Theo de Raadt
I agree. This chunk below is really gross and does not follow the special wakeup channel metaphor. It is *entirely clear* that a called "nowake" has no wakeup. Like duh. > +/* > + * nowake is a global sleep channel for threads that do not want > + * to receive wakeup(9) broadcasts. > + */ >

Re: prototype of delay(9) is inconsistent

2020-12-21 Thread Theo de Raadt
catching underflow which results in infinite delays is probably very handy. Scott Cheloha wrote: > The manpage for delay(9) suggests that the prototype is: > > void delay(int); > > But on armv7, arm64, hppa, macppc, and powerpc64 the input is unsigned > or a u_int instead of an int. Like

Re: doas sprinkle some more CFLAGS

2020-12-20 Thread Theo de Raadt
Ted Unangst wrote: > On 2020-12-18, Martijn van Duren wrote: > > So I ended up in doas again, this time with the CFLAGS I use for most of > > my other projects. This popped up a few new not very exciting warnings. > > Diff below compiles clean with both clang and gcc on amd64. > > > static

Re: kdump: show scope for v6 addresses if set

2020-12-20 Thread Theo de Raadt
Florian Obser wrote: > On Sun, Dec 20, 2020 at 02:34:09PM +0100, Claudio Jeker wrote: > > On Sun, Dec 20, 2020 at 01:39:57PM +0100, Otto Moerbeek wrote: > > > Hi, > > > > > > scope is there, just not shown. While there, use proper constants for > > > two sizes. > > > > > > -Otto > > > > > >

Re: [diff] src/usr.sbin/smtpd: add a forward-file option

2020-12-19 Thread Theo de Raadt
There are thousands of people with smtpd configurations, and sysmerge is not going to handle this. We cannot expect them all to change their files. This is madness. Gilles, I think you should be adding an option that blocks it optionally, and then some operators can use that. If they wish. I

Re: [diff] src/usr.sbin/smtpd: add a forward-file option

2020-12-19 Thread Theo de Raadt
Todd C. Miller wrote: > I like this direction but I worry about breaking existing configs. > How are we going to alert existing users that they need to update > their configs if the behavior silently changes? I think the configuration is backwards. Every endpoint box will need these new

Re: nosuid more partitions that no longer have suid executables

2020-12-16 Thread Theo de Raadt
the term "suid" includes setgid executables... so your conclusions are way wrong. Heck, you should give it a try. Good luck logging in afterwards. Josh Rickmar wrote: > Playing around with find ${dir} -type f -perm -04000, I see that there > are no longer any more suid executables placed in

Re: rc.d(8) for tcpbench

2020-12-15 Thread Theo de Raadt
Stuart Henderson wrote: > On 2020/12/15 16:33, Theo de Raadt wrote: > > Jan Klemkow wrote: > > > > > On Tue, Dec 15, 2020 at 03:43:38PM -0700, Theo de Raadt wrote: > > > > Jan Klemkow wrote: > > > > > > > > > for fr

Re: rc.d(8) for tcpbench

2020-12-15 Thread Theo de Raadt
Jan Klemkow wrote: > On Tue, Dec 15, 2020 at 03:43:38PM -0700, Theo de Raadt wrote: > > Jan Klemkow wrote: > > > > > for frequent performance test it would be nice to just start tcpbench > > > as a regular service. tcpbench gets an extra user and group wi

Re: rc.d(8) for tcpbench

2020-12-15 Thread Theo de Raadt
Jan Klemkow wrote: > for frequent performance test it would be nice to just start tcpbench > as a regular service. tcpbench gets an extra user and group with this > diff and is already pledged to "stdio". Thus, there should be no > security risk to do this even in hostile environments. You're

Re: Poison file names

2020-12-13 Thread Theo de Raadt
> I don't think it is worth doing without doing all of it. Series of commits.

Re: delays in sensors thread

2020-12-10 Thread Theo de Raadt
Mark Kettenis wrote: > Well, we deliberately chose not to do that since that would lead to a > gazillion of kernel threads if you have lots of sensor drivers. > > Sensor drivers that are "good citizens" should probably continue to > use the sensor thread. Butfor things like asmc(4) that handle

Re: delays in sensors thread

2020-12-10 Thread Theo de Raadt
Marcus Glocker wrote: > Hi All, > > I recently started to play around with uvideo(4) and uaudio(4) on my > amd64 iMacs. There I quickly noticed regular freezes when streaming > USB video or audio. On some of those machines it was very frequent, > like every few seconds the video or audio

Re: FT232H variant in uftdi(4)

2020-12-09 Thread Theo de Raadt
I'm not sure about this chunk. There are fdti chipsets that expose two uftdi, with a ucom each. But maybe there are chipsets that expose one uftdi, which has two ucom? It could be saying such a model is not supported. If that is the gap, it is wrong to say ucom needs extending. uftdi would

Re: rw_lock_held() & friends

2020-12-07 Thread Theo de Raadt
That's all fine, until someone uses this not for KASSERT, but as part of their logic. while(!rw_read_held(lock)) { do something; } I think this kind of thing fleads to people building "try" APIs. Martin Pieuchot wrote: > Simple diff below to add the

Re: snmp trap usage

2020-11-30 Thread Theo de Raadt
ok Martijn van Duren wrote: > I missed an argc check which causes snmp trap to segfault if called with > too few arguments instead of showing usage. > > OK? > > martijn@ > > Index: snmpc.c > === > RCS file:

  1   2   3   4   5   6   7   8   9   10   >