Re: wall(1) unveil for non-root users

2019-05-16 Thread Theo de Raadt
Philip Guenther wrote: > On Wed, May 15, 2019 at 10:54 PM Theo de Raadt wrote: > > Martijn van Duren wrote: > > > I don't see much point in the check. > > > > If we don't have write permissions open(2) will fail. > > If we open it based on S_IWOTH p

Re: wall(1) unveil for non-root users

2019-05-15 Thread Theo de Raadt
Martijn van Duren wrote: > I don't see much point in the check. > > If we don't have write permissions open(2) will fail. > If we open it based on S_IWOTH permissions than checking for S_IWGRP > without considering who is in that group seems really absurd to me. > > So I'd be OK with patch 1

Re: sensorsd(8) unveil for -f option

2019-05-15 Thread Theo de Raadt
That looks good. Do others using sensorsd concur? Anton Borowka wrote: > sensorsd(8) currently only unveils /etc/sensorsd.conf for reading, but > the config file can be changed with the -f option (which is currently > not working). > > The patch moves unveil and pledge after the options

Re: wall(1) unveil for non-root users

2019-05-15 Thread Theo de Raadt
Anton Borowka wrote: > wall(1) does not work correctly for non-root users at the moment because > ttymsg() needs read access for the tty devices, but only write access is > unveiled. Because it cannot access any devices nothing is printed. > > This patch adds read access for /dev. Don't know if

Re: enable cy(4) by default on amd64

2019-05-13 Thread Theo de Raadt
Does this driver correctly support cua(4) device nodes? If it doesn't, then my position would be "no, that is a minimum required featureset". And 'd' dialout support isn't the same, it must be cua. (Quirky different behaviours between tty devices are super annoying and end up as complaints on

Re: sys_pledgepid() clean patch; comments?

2019-05-11 Thread Theo de Raadt
I disagree strongly with the direction. Processes should follow the promises previous code made. Developers should be "mindful" of their program's rules & model, if they can't design properly and keep the situation in their head in a 'static fashion', they don't stand a chance in hell of doing

Re: cmdfile for config -ef

2019-05-11 Thread Theo de Raadt
Ted Unangst wrote: > Benjamin Baier wrote: > > On Sat, 11 May 2019 11:18:02 -0400 > > "Ted Unangst" wrote: > > > > > This adds a new option to config, -c cmdfile, that allows reading commands > > > from a file instead of stdin. This makes it easier to script. > > > > Interesting. Can the

Re: Avoid system(3) in ikectl

2019-05-08 Thread Theo de Raadt
Ted Unangst wrote: > ca_exec or ca_system I could go either way, but there's no longer sh involved, > so that's why I went back to exec. Even more accurate to name it ca_execv(), since this is a argv[] interface.

Re: Avoid system(3) in ikectl

2019-05-08 Thread Theo de Raadt
This feels approximately right to me.

Re: Avoid system(3) in ikectl

2019-05-08 Thread Theo de Raadt
Matthew Martin wrote: > On Wed, May 08, 2019 at 04:22:16PM -0600, Theo de Raadt wrote: > > Isn't something like better -- to avoid marshalling code to convert > > arguments -> array? > > > > char *pkcs_args[] = > > PATH_OPENSSL, > > &qu

Re: Avoid system(3) in ikectl

2019-05-08 Thread Theo de Raadt
Ted Unangst wrote: > Theo de Raadt wrote: > > Isn't something like better -- to avoid marshalling code to convert > > arguments -> array? > > this requires mixing declarations and code, but all our compilers are c99 > compliant now, and this does make ca_system simp

Re: Avoid system(3) in ikectl

2019-05-08 Thread Theo de Raadt
Ted Unangst wrote: > Matthew Martin wrote: > > ping > > > > On Thu, Apr 25, 2019 at 11:21:00PM -0500, Matthew Martin wrote: > > > On Thu, Apr 25, 2019 at 08:59:56PM -0600, Theo de Raadt wrote: > > > > > + argv = alloca((n + 1) * siz

Re: The default value of kern.bufcachepercent is 20, not 80.

2019-05-05 Thread Theo de Raadt
I'm going to fix this permanently. > The kern.bufcachepercent entry in sysctl(2) still claims the default > value is 80, even though it was changed to 20 recently. > > > Index: ./lib/libc/sys/sysctl.2 > === > RCS file:

Re: More randomness for efiboot on amd64

2019-05-04 Thread Theo de Raadt
Nice. Mike -- does this collide with your current work, or does it not impact it? Mark Kettenis wrote: > The UEFI standard defines an (optional) protocol for getting random > numbers. A while back I wrote support for this for the arm64 > bootloader. But we should use this on amd64 as well.

Re: drop rpath from openssl(1) ciphers

2019-04-30 Thread Theo de Raadt
I am a bit sceptical, and worry that some internal function may do something. > openssl ciphers doesn't seem to need to open any files to show the full list > of > ciphers, or manually selected so drop rpath from pledge. > > OK? > > Index: ciphers.c >

Re: Conditional sysupgrade

2019-04-27 Thread Theo de Raadt
Florian Obser wrote: > It has the date and time with seconds resolution in there. Not just the built > number. Yes from KARL on one machine, and snapshot/release builds on a different machine. Could this not false-positive? > On April 27, 2019 9:57:59 PM GMT+02:00, Theo de Raadt

Re: Conditional sysupgrade

2019-04-27 Thread Theo de Raadt
> As Florian suggested I compared kern.version to what from both bsd and bsd.mp. Do not do that. kern.version in snapshots and releases are completely arbitrary, based on whether I delete an obj tree, then the version numbers begin anew. This heuristic will false-positive.

Re: signify xr sysupgrade.8

2019-04-26 Thread Theo de Raadt
Ted Unangst wrote: > Simplify examples section. The magic recipe is contained in sysupgrade, so we > can omit it, and instead add a .xr to sysupgrade.8. > > > Index: signify.1 > === > RCS file:

Re: Avoid system(3) in ikectl

2019-04-25 Thread Theo de Raadt
> + argv = alloca((n + 1) * sizeof(*argv)); Our source tree is exceedingly sparing in the use of alloca(). This will not do.

Re: Talking about time (ntpd -s)

2019-04-24 Thread Theo de Raadt
sven falempin wrote: > Dear Tech reader, > > NTPD -S is useful, when a device is in storage for a while the clock is in > disarray. > But this assume the network exists, the fixed 15 seconds timeout makes > sense, > nevertheless it could be too long or too short. > >

OpenBSD 6.5 released -- Apr 24 2019

2019-04-24 Thread Theo de Raadt
-- - THANKS --- Ports tree and package building by Pierre-Emmanuel Andre, Landry Breuil, Visa Hankala, Stuart Henderson, Peter Hessler, and Christian Weisgerber. Base and X system builds by Kenji Aoyama, The

Re: new man page: rcsfile.5

2019-04-23 Thread Theo de Raadt
Fabio Scotoni wrote: > > According to the Berne Convention, even though you cannot give away > > the moral rights that constitute the core of Copyright, you can give > > away the economic rights arising from a Work. Some publishers of > > software (for example the FSF) ask for that. But in

Re: Tighten nl(1) pledge(2) a bit

2019-04-20 Thread Theo de Raadt
Rafael Neves wrote: > Hi tech@, > > The Patch 1 below tighten pledge(2) promises to stdio, after the > freopen(3) call, I've commited this. > and replaces an exit(3) call to return, so the > stack protector could be used. I'm still not a huge fan of those. I don't recall ever seeing an

Re: pfctl: dot not load directories

2019-04-19 Thread Theo de Raadt
I don't see the point of this, and think you are cargo culting. Shall we change all the fopen() calls in src/bin to use the same idiom? No. What happens is you point at a directory, and either read zero bytes or garbage, and you get what you asked for. So I believe this function should *not

Re: dwxe: resetting interface on watchdog timeout

2019-04-18 Thread Theo de Raadt
Sebastien Marie wrote: > On Wed, Apr 17, 2019 at 04:32:04PM -0700, Jungle Boogie wrote: > > On Wed 17 Apr 2019 9:44 AM, Sebastien Marie wrote: > > > Hi, > > > > > > With a pine64, I am experimenting regulary dwxe watchdog > > > timeout. Usually it is a sign that something doesn't work in the

Re: libevent: Protect integer multiplications (min_heap)

2019-04-16 Thread Theo de Raadt
Theo de Raadt wrote: > Reading this min_heap.h code for the first time, I shuddered because it > reminded me of the exploit mitigation mechanism in openssl which prevent > heartbleed from being exploitable in the presence of our fine otto > malloc. Oops, this is more corre

Re: libevent: Protect integer multiplications (min_heap)

2019-04-16 Thread Theo de Raadt
Reading this min_heap.h code for the first time, I shuddered because it reminded me of the exploit mitigation mechanism in openssl which prevent heartbleed from being exploitable in the presence of our fine otto malloc. It is a deferred deallocation mechanism *precisely* what prevents bugs from

Re: [patch] remove reference to HOSTALIASES in hostname(7)

2019-04-15 Thread Theo de Raadt
Your deletion is highly excessive. Hiltjo Posthuma wrote: > Hi, > > I noticed the man page hostname(7) still references the environment variable > HOSTALIASES. This functionality seems to be removed in the commit: > >

Re: iked curve25519

2019-04-02 Thread Theo de Raadt
I think this is the right time to do this. Stuart Henderson wrote: > On 2019/03/30 13:43, Theo de Raadt wrote: > > I think we should switch, waiting doesn't help. > > > > Reyk Floeter wrote: > > > > > I like the idea of switching it to the proper ID.

Re: rsync: add --one-file-system

2019-04-01 Thread Theo de Raadt
Looking at real rsync, it appears the 'x' option is passed to the other side (your code does not do this), and there is also some special case for >1 -x option. Intuitively the client and server must do slightly different things especially when combined with --delete, or if one of them finds a

Re: [PATCH] bgpctl(8): improve user interface for RPKI Origin Validation

2019-04-01 Thread Theo de Raadt
Job Snijders wrote: > Dear all, > > I've consulted with numerous user interface experts, their consistent > advice was to facilitate internalization by provoking simpler, stronger > emotions through the text based interface. > > bgpctl(8) will now provide simplified 'SAD' or 'HAPPY' ascii

Re: improve rsync(1) manual page

2019-04-01 Thread Theo de Raadt
Ingo Schwarze wrote: > >> * Change the misleading argument placeholder "portnumber" to "service"; > >>even the default ("rsync") isn't a number. In the description, > >>mention services(5), and also mention the default. > > > I don't object, but I wonder how much detail is needed.

Re: Removing PF

2019-04-01 Thread Theo de Raadt
Todd C. Miller wrote: > On Mon, 01 Apr 2019 07:01:03 +0200, Claudio Jeker wrote: > > > There have been internal discussions about OpenBSD also removing the pf > > packet filter after the upcoming 6.5 release. Instead a switch to > > using David Gwynne's new bpf filter will happen. > > The

Re: improve rsync(1) manual page

2019-04-01 Thread Theo de Raadt
Christian Weisgerber wrote: > > * Remove excessive verbosity from -g and -o, and improve precision: > > I find "Set the group name to match the source" incomprehensible. > The example given in the previous text may be unelegant, but it helps > me understand what this actually does, Yes,

Re: sys/dev/x86emu/x86emu.c: repair "} if"

2019-03-31 Thread Theo de Raadt
Yes, very weird. There are about 20 more in the base tree. Some of them are missing "else", but some are not. > I'm grepping the tree for "} if" lines... > > I'm confident that these were intended as "else if", compare the > corresponding ror_* functions. Also, it doesn't actually change >

Re: httpd(8): Adapt to industry wide current best security practices

2019-03-31 Thread Theo de Raadt
relayd needs this also. It is a very often a bump in the wire, protecting cisco devices. Florian Obser wrote: > OK? > > diff --git server_http.c server_http.c > index 6c8549d2b41..f04a15bd056 100644 > --- server_http.c > +++ server_http.c > @@ -1176,7 +1176,7 @@ server_response(struct httpd

Re: iked curve25519

2019-03-30 Thread Theo de Raadt
I think we should switch, waiting doesn't help. Reyk Floeter wrote: > I like the idea of switching it to the proper ID. > > Reyk > > > Am 30.03.2019 um 20:31 schrieb Stuart Henderson : > > > > curve25519 had a proper ID (31) assigned in 2016 but we still have > > the draft private-use ID in

Re: rsync: add --del, remove --no-delete

2019-03-30 Thread Theo de Raadt
OK for both. Christian Weisgerber wrote: > * Add --del as alias for --delete, because I've grown used to this > shorter option. For GPL rsync, these behave identically when > talking to rsync 3.0.0 or newer. > > * Drop --no-delete. In GPL rsync, the "no-" prefix is only available > for

Re: invalid netmasks should be reported

2019-03-29 Thread Theo de Raadt
ok deraadt Klemens Nanni wrote: > On Wed, Mar 27, 2019 at 12:34:52PM +0100, Petr Hoffmann wrote: > > I noticed it is possible to specify an invalid netmask, > > e.g. 1.1.1.1/10/20 and still get the address loaded into a table. I > > conjecture this was introduced by the following change: > > >

Re: hibernate_io function

2019-03-28 Thread Theo de Raadt
Mike Larkin wrote: > On Thu, Mar 28, 2019 at 07:02:11AM +, Shivaprashanth H wrote: > > hi Larkin, > > > > yes. I am looking to port the hibernate feature from openbsd to freebsd. > > > > so in freebsd, i see dev/ada > > > > I don't know what physical device that corresponds to. According

Re: pfctl should allow administrator to flush _anchors

2019-03-25 Thread Theo de Raadt
Alexandr Nedvedicky wrote: > how about making the '-U' (or whatever name we agree) undocumented. We can > also make the option available if pfctl will get compiled with 'DEBUG' > option (assuming we are doing regress on debug bits anyway). no, it should be documented. but few

Re: diff: reboot(8): document the -l option

2019-03-25 Thread Theo de Raadt
When you see a comment like this, it means it is intentionally undocumented. It is the current mechanism shutdown uses. It could use a different mechanism in the future. It is done this way so that noone else depends on it. If you document this user-visible, they will come to depend on it,

Re: [patch] improve strptime(3) %z timezone parsing

2019-03-24 Thread Theo de Raadt
My position is we should delete support. Hiltjo Posthuma wrote: > On Sun, Feb 24, 2019 at 01:11:39PM +0100, Hiltjo Posthuma wrote: > > Hi, > > > > I noticed some things in the strptime(3) implementing when parsing timezone > > strings using the %z format string. > > > > 1. I noticed the

Re: A driver for the Exar XR21V1410 USB-to-serial chip

2019-03-24 Thread Theo de Raadt
OK with me, but you'll also need a man page, and Xr that from usb.4 Mark Kettenis wrote: > In principle this hardware implements the standard USB Communication > Device Class interface which is supported by umodem(4). However, the > hardware enables hardware flow control bu default in CDC

Re: pfctl should allow administrator to flush _anchors

2019-03-24 Thread Theo de Raadt
Alexandr Nedvedicky wrote: > On Sun, Mar 24, 2019 at 09:51:13AM +0100, Denis Fondras wrote: > > On Sun, Mar 24, 2019 at 09:24:34AM +0100, Alexandr Nedvedicky wrote: > > > I think all the above calls for a new standalone option, which I named as > > > 'Unconfigure'. Patch below suggest

Re: ospfd: Warn when the router ID changes during config reload

2019-03-23 Thread Theo de Raadt
Sebastian Benoit wrote: > Mitchell Krome(mitchellkr...@gmail.com) on 2019.03.23 20:27:17 +1000: > > Was messing around with ospf and got myself into a situation where the > > router ID's were the same on two boxes because I only did a reload on > > one of them when I changed the loopback IP's. >

Re: rasops(9): revert changes in rasops32_putchar()?

2019-03-23 Thread Theo de Raadt
Mateusz Guzik wrote: > You may notice pagezero uses rep. Background page zeroing was removed > quite some time ago. I see OpenBSD still has it, but it is most likely > detrimental by now. If it is to be kept, a pagezero variant utilizing > non-temporal stores still makes sense but a different

Re: rsync: gettimeofday+TIMEVAL_TO_TIMESPEC -> UTIME_NOW

2019-03-22 Thread Theo de Raadt
Kristaps Dzonsons wrote: > >> ... it says the modification time is a time_t. Which means we only > >> have seconds, not subseconds. > > > > Fair enough. The protocol predates common availability of nanosecond > > file timestamps. > > It's worse than that. It's 32-bit time_t. Your docs say

Re: rsync: gettimeofday+TIMEVAL_TO_TIMESPEC -> UTIME_NOW

2019-03-22 Thread Theo de Raadt
Kristaps Dzonsons wrote: > >> ... it says the modification time is a time_t. Which means we only > >> have seconds, not subseconds. > > > > Fair enough. The protocol predates common availability of nanosecond > > file timestamps. > > It's worse than that. It's 32-bit time_t. Do negative

Re: usb drivers & arches (Re: [4/4] Re: Add support for Meinberg DCF600USB to umbg(4))

2019-03-22 Thread Theo de Raadt
Paul de Weerd wrote: > On Fri, Mar 22, 2019 at 11:53:20AM +, Stuart Henderson wrote: > | This is a more general thing actually, the list of USB drivers is rather > | haphazard at the moment. List below (to fit <80 cols I've snipped i386 > | which has all drivers present in any other GENERIC

Re: [patch] Re: Possible sasyncd memory leak ?

2019-03-21 Thread Theo de Raadt
Otto Moerbeek wrote: This lex operation seems ridiculous. Normal one does lex of free-standing digit sequences into a "number token" only if the sequence is fully digits -- see the code around pfctl/parse.y line 5368 Or don't lex numbers instead, but consider them strings (with the correct

Re: smtpctl, mailer.conf: drop send-mail (was: mail(1): use "sendmail" as argv[0] for sendmail)

2019-03-19 Thread Theo de Raadt
Have you verified there are *no other programs* in the entire greater ecosystem using that name? > On Tue, Mar 19 2019 07:26:41 -0600, Todd C. Miller wrote: > > On Tue, 19 Mar 2019 10:33:07 +0200, Lauri Tirkkonen wrote: > > > > > ping - doesn't look removed yet :) > > > > Committed. > >

Re: acme-client: remove free() before exits in main()

2019-03-09 Thread Theo de Raadt
Otto Moerbeek wrote: > On Sat, Mar 09, 2019 at 11:23:22AM +0100, Sebastian Benoit wrote: > > > We free a few strings in main(), some others we dont. We should either > > free() all strings consistently or not free them at all, because it does not > > hurt to keep them until exit(). > > > > The

Re: Avoid system(3) in ikectl

2019-03-06 Thread Theo de Raadt
I'm not sure why this matters. Fundamentally system is fork+exec via a shell. So you write it as minimal fork+exec. What is the particular benefit you see here, is it security -- and if so, what is the security benefit? Have you identified a quoting problem? Can you pinpoint the issue and

Re: mail(1): use "sendmail" as argv[0] for sendmail

2019-03-04 Thread Theo de Raadt
Todd C. Miller wrote: > On Mon, 04 Mar 2019 16:38:37 +0100, Gilles Chehade wrote: > > > I wish we had an historian who could enlighten us as to why both exist. > > That code actually predates sendmail and was in the original revision > when delivermail was still in use. Sendmail itself never

Re: install.sub: less aggressive library relink cleanup

2019-03-01 Thread Theo de Raadt
Makes sense. Sorry for getting it wrong. Theo Buehler wrote: > During upgrades all library link kits are now removed early on - right > after mounting the file systems. This leaves a number of questions where > the user can choose to abort the upgrade, or possibilities for things to > go

Re: Neuter shm calls from X swrast_dri.so

2019-02-24 Thread Theo de Raadt
>> Date: Sun, 24 Feb 2019 10:44:25 -0500 >> From: Todd Mortimer >> >> A few weeks ago I noticed that firefox tabs were getting killed for >> running afoul of pledge(2). It seems that the problem was some calls to >> shmget(2) from the X swrast_dri.so lib that seem to have come from the >> new

Re: Executing rc.d on rdomain != 0

2019-02-19 Thread Theo de Raadt
I think that's really gross. route domains are a concept usable by some people, not everyone should need to see this. > I think rc.d should specify the routing domain explicitly when it > executes the daemon program even if the daemon's rtable is configured > 0 since the executed routing domain

Re: bgpd use long long instead of int64_t

2019-02-18 Thread Theo de Raadt
Claudio Jeker wrote: > On Mon, Feb 18, 2019 at 10:11:03PM +0100, Mark Kettenis wrote: > > > Date: Mon, 18 Feb 2019 21:59:38 +0100 > > > From: Claudio Jeker > > > > > > In some places bgpd just wants something bigger then a 32bit int. > > > Instead of using int64_t or u_int64_t use (unsigned)

Re: bgpd use long long instead of int64_t

2019-02-18 Thread Theo de Raadt
Mark Kettenis wrote: > > Date: Mon, 18 Feb 2019 21:59:38 +0100 > > From: Claudio Jeker > > > > In some places bgpd just wants something bigger then a 32bit int. > > Instead of using int64_t or u_int64_t use (unsigned) long long which is at > > least 64bit and therefor good enough. Makes the

Re: strptime: %e and leading space

2019-02-17 Thread Theo de Raadt
Ted Unangst wrote: > > I do believe it should be possible to round trip data through these functions > with the same format string. > On that basis alone, I concur.

Re: scan_ffs(8) and FFS2 filesystems

2019-02-08 Thread Theo de Raadt
Jason McIntyre wrote: > On Fri, Feb 08, 2019 at 09:35:35PM +0100, Jeremie Courreges-Anglas wrote: > > > > > > I think it's fair to give the user a chance to understand why > > scan_ffs(8) won't help in this case. > > > > ok? > > > > hi. > > i'm not sure if it's a bug, but it sure seems

Re: llvm: libc++(abi) and libunwind 7.0.1

2019-02-04 Thread Theo de Raadt
I think patrick should go for it. Mark Kettenis wrote: > I've tested this on arm64, armv7 and sparc64. Done a full make build > on arm64 and armv7. Didn't quite get that far on sparc64 since I had > to shut down my machine to get some sleep. But I sucessfully built > clang with the new

Re: wscons: free size

2019-01-31 Thread Theo de Raadt
Yes the queue is always that size. Anton Lindqvist wrote: > Comments? OK? > > Index: dev/wscons/wsevent.c > === > RCS file: /cvs/src/sys/dev/wscons/wsevent.c,v > retrieving revision 1.18 > diff -u -p -r1.18 wsevent.c > ---

Re: strlcpy() or strscpy()?

2019-01-29 Thread Theo de Raadt
Martijn van Duren wrote: > I think the others have given a decent explanation, but I would like to > elaborate a little furter. I strongly agree with your points, but a few comments. > OK, so strscpy won't read any more data from src than count bytes, which > could save you from reading from

Re: register DoT in /etc/services?

2019-01-27 Thread Theo de Raadt
Damien Miller wrote: > On Sun, 27 Jan 2019, Theo de Raadt wrote: > > > I need to add I worry for the future, the 512-1023 reserved space is > > being gobbled at a rapid pace by new services, which not only decreases > > the port# entropy but reduces the total number

Re: register DoT in /etc/services?

2019-01-27 Thread Theo de Raadt
unbound does so also Anything known-port which is potentially serviced by a daemon in the base must be listed in /etc/services, so that it can be added to the net.inet.{tcp,udp}.baddynamic lists at boot by /etc/rc. Otherwise, the random port allocator (reserved, non-reserved, and high) may

Re: strlcpy() or strscpy()?

2019-01-27 Thread Theo de Raadt
0sjfoij...@firemail.cc wrote: > Recently on LCA2019, Joel Sing made a presentation about "Security > Vulnerability Mitigations"[1] > (very good, btw). He suggests function strlcpy(3) as a secure API. > In the same conference, though, Kees Cook ("Making C Less Dangerous in > the Linux kernel"[2]),

Re: grep: convert fgetln to getline

2019-01-24 Thread Theo de Raadt
Scott Cheloha wrote: > > On Jan 24, 2019, at 06:19, Lauri Tirkkonen wrote: > > > > [...] > > > > I haven't done any actual measurements though, so it's possible my > > reading is wrong. > > Is there a "grepbench" or canonical corpus we can use to get a 95% > CI on this and future changes?

Re: iwn: zap unused function parameter from iwn_stop()

2019-01-24 Thread Theo de Raadt
>> just a comment: >> >> drivers with firmware have often had special parameters to the stop or >> reset functions to indicate a difference between "stop moving traffic" >> or "shut it all down". We seem to keep switching this back and forth. >> Reason is we've had some very bizzare failure

Re: grep: convert fgetln to getline

2019-01-24 Thread Theo de Raadt
>On Thu, Jan 24 2019 04:22:20 -0700, Theo de Raadt wrote: >> I would like to know if this does more malloc. I worry it is an additional >> level of malloc per line. > >It does do more malloc than plain fgetln since fgetln does no copying, >but nowhere near every lin

Re: iwn: zap unused function parameter from iwn_stop()

2019-01-24 Thread Theo de Raadt
just a comment: drivers with firmware have often had special parameters to the stop or reset functions to indicate a difference between "stop moving traffic" or "shut it all down". We seem to keep switching this back and forth. Reason is we've had some very bizzare failure conditions in drivers,

Re: grep: convert fgetln to getline

2019-01-24 Thread Theo de Raadt
I would like to know if this does more malloc. I worry it is an additional level of malloc per line. >On Wed, Jan 23 2019 18:01:24 -0500, Ted Unangst wrote: >> Lauri Tirkkonen wrote: >> > > > oh, interesting. that's sloppy. can you please fix that first, >> > > > separately? >> > > >> > >

Re: sensors hiding with pledge

2019-01-21 Thread Theo de Raadt
This approach seems backwards. It is hiding sensors from programs which are pledged (ie. we put effort into security, therefore a fig leaf for privacy) But.. in programs we cannot pledge, we continue exporting. Yes chrome is pledged so permanently has no access to the information. I am not

Re: return value check in snprintf(3) example code

2019-01-18 Thread Theo de Raadt
Ted Unangst wrote: > Theo Buehler wrote: > > According to our documentation and all the standards I checked, > > snprintf() returns a negative value on error, not necessarily -1. > > This confused me quite a bit recently so I suggest to adjust the > > example code as follows: > > I don't know.

Re: arp timeouts and refresh arp entries before they expire

2019-01-17 Thread Theo de Raadt
- if (la_hold_total < LA_HOLD_TOTAL && la_hold_total < nmbclust / 64) { + if (la_hold_total < nmbclust / 64) { I have disagreed with claudio about this aspect of the diff. The refresh attempt is the crucial problem to fix, because of what it has done to tcp with slowstart etc. If

Re: file(1) better ideas to recognize rust language code?

2019-01-14 Thread Theo de Raadt
No, I'm sure that isn't right. > Didn't find any other examples. At the moment rust code is recognized > as ASCII C program text. > > Index: usr.bin/file/magdir/rust > === > RCS file: usr.bin/file/magdir/rust > diff -N

Re: minor ttyflags(8) diff

2019-01-13 Thread Theo de Raadt
Miod Vallat wrote: > > > Opening a pseudo-tty (/dev/tty[p-zP-T][0-9a-zA-Z]) causes the kernel to > > > allocate a struct tty for it, as well as ring buffers for tty data. This > > > memory will not get released if the pseudo-tty is closed, for it may be > > > opened again in the future. > > > >

Re: minor ttyflags(8) diff

2019-01-13 Thread Theo de Raadt
Miod Vallat wrote: > Opening a pseudo-tty (/dev/tty[p-zP-T][0-9a-zA-Z]) causes the kernel to > allocate a struct tty for it, as well as ring buffers for tty data. This > memory will not get released if the pseudo-tty is closed, for it may be > opened again in the future. The change seems

Re: typos in src/distrib/miniroot/install.sub

2019-01-13 Thread Theo de Raadt
Thanks.

Re: Virtio 1.0 for the kernel

2019-01-10 Thread Theo de Raadt
arm64 also uses this subsystem, and as a result this diff breaks all those kernels. You ask how to run arm64 Uhm, you didn't even try to compile it.

Re: locale in locate(1)

2019-01-10 Thread Theo de Raadt
> Does locate(1) need to setlocale(3)? Since you ask the question, yes. Oh wait, was your question rhetorical? It lacks facts. Who's time are you wasting? > Index: locate/locate.c > === > RCS file:

Re: locale in locate(1)

2019-01-10 Thread Theo de Raadt
Scott Cheloha wrote: > The ctype wizard may also have a very elegant explanation clarifying > whether this is correct or not. The diffs received are annoying. What problem does it solve? What are the downsides? Is there any education in the diffs as to why the changes are needed, so that

Re: Implement Event()/Signal()/Wait() AML operations

2019-01-10 Thread Theo de Raadt
Ted Unangst wrote: > Ted Unangst wrote: > > > > Does 0x come from ACPI? Can we give that a name? > > > > I thought sleeping for one tick is kinda weird, but I see what it's doing > > with > > the acpi_dotask loop. This feels precarious, but whatever. > > So upon further thought, this is

Re: trunk shouldnt care if it's stacked

2019-01-09 Thread Theo de Raadt
Philip Guenther wrote: > On Wed, Jan 9, 2019 at 1:11 AM Klemens Nanni wrote: > > > On Wed, Jan 09, 2019 at 01:12:31PM +1000, David Gwynne wrote: > > > -#define TRUNK_MAX_STACKING 4 /* maximum number of stacked > > trunks */ > > Is this an arbitrary limit or does it conceal other

Re: install(1) could fail due to race

2019-01-07 Thread Theo de Raadt
Ted Unangst wrote: > Todd C. Miller wrote: > > On Mon, 07 Jan 2019 22:55:54 +, Christian Weisgerber wrote: > > > > > Oooh, that short period can be the time between disk flushes (30s?) > > > with softupdates. I think that's one of the scenarios where you > > > can run out of disk space if

Re: sbin/wsconsctl: show more data

2019-01-07 Thread Theo de Raadt
Ted Unangst wrote: > Artturi Alm wrote: > > display.width=1920 > > display.height=1200 > > display.depth=32 > > display.emulations=vt100 > > display.col_x_row=120x37 > > display.font_wxh=16x32 > > now that we've all had a chance to weigh in on the font, why are you adding > this weird x format?

Re: kcov: enable retguard

2019-01-07 Thread Theo de Raadt
That's great! > Hi, > The problems caused by enabling both kcov and retguard was due to the > increased kernel size. Now that NKL2_KIMG_ENTRIES has been bumped on > amd64, it's no longer a problem. > > Comments? OK? > > Index: arch/amd64/conf/Makefile.amd64 >

Re: replacing timeout_add() with timeout_add_msec()

2019-01-06 Thread Theo de Raadt
Amit Kulkarni wrote: > Even on amd64, I won't be able to test, because of missing hardware. > If you think something is wrong, please will you let me have your > feedback? I'm a bit stunned at the zeal to push untested diffs into the tree (you didn't ask anyone to test it for you)

Re: replacing timeout_add() with timeout_add_msec()

2019-01-06 Thread Theo de Raadt
Amit Kulkarni wrote: > Hi, > > Referring to the end of mpi's message, and also mlarkin@ later comment > https://marc.info/?l=openbsd-tech=154577028830964=2 > > I am trying to replace some easy timeout_add() calls with timeout_add_msec(). > > My current understanding with the occurences of

Re: adjust rdate example

2019-01-06 Thread Theo de Raadt
Ingo Schwarze wrote: > Hm, you have a point. > > I guess i got confused by my experience with LC_CTYPE; even though > that is also a standard variable, its effects on different programs > vary wildly, so the text for LC_CTYPE reads very differently in > different utility manual pages, and it is

Re: adjust rdate example

2019-01-05 Thread Theo de Raadt
Ted Unangst wrote: > Ingo Schwarze wrote: > > Congrats, you found a documentation bug. > > > > Apparently, the rdate(8) program supports the TZ environment variable, > > but the manual page does not say so. An ENVIRONMENT section is missing > > and should be added. It is not a good idea to

Re: adjust rdate example

2019-01-05 Thread Theo de Raadt
Ingo Schwarze wrote: > >> Demonstrate printing a time modified by TZ instead. > > Congrats, you found a documentation bug. > > Apparently, the rdate(8) program supports the TZ environment variable, > but the manual page does not say so. An ENVIRONMENT section is missing > and should be added.

Re: adjust rdate example

2019-01-05 Thread Theo de Raadt
First off, what a weird example you found. But more on the matter. Is your change even good advice? pool.ntp.org is attackable via unauthenticated DNS, and based upon past experience who can say if their administrators can even keep their infrastructure secure. Furthermore, the ntp protocol

Re: sbin/wsconsctl: show more data

2019-01-05 Thread Theo de Raadt
> I do NOT like this idea of being stuck with that for the next 10 years. when do make statements like that, why do you continue to believe any of us care about any of your opinions?

Re: sbin/wsconsctl: show more data

2019-01-05 Thread Theo de Raadt
You are failing to provide a proper bug report that has details, instead, it we got a convoluted diff and an extremely vague description that makes no sense. that makes it very hard to care. > On Sat, Jan 05, 2019 at 01:50:22AM +0200, Artturi Alm wrote: > > Hi, > > > > guessing i'm not the only

Re: unveil file(1)

2019-01-04 Thread Theo de Raadt
Ted Unangst wrote: > Theo de Raadt wrote: > > > unveil isn't really buying much if you pledge "rpath" immediately after, > > > so if you want just add another pledge here instead, that is fine. > > > > "rpath" is obviously cheaper than unveil

Re: unveil file(1)

2019-01-04 Thread Theo de Raadt
> Just saying "you should not do that" will not prevent any user to do it > anyway. That is not what I was saying. Most of us strive to write utilities in the most efficient way. We don't use system features in programs that don't require it. We write a sparing but sufficient userland. That's

Re: unveil file(1)

2019-01-04 Thread Theo de Raadt
> But, is the situation with unveil(2) worst that before ? It seems to me > a user could already doing vnode comsuption with just opening as many > file descriptors it can (and fork and repeat when RLIMIT_NOFILES is > reached for the process). No, it is a little different. An unveil is a tighter

Re: unveil file(1)

2019-01-03 Thread Theo de Raadt
> unveil isn't really buying much if you pledge "rpath" immediately after, > so if you want just add another pledge here instead, that is fine. "rpath" is obviously cheaper than unveil of even 1 file.

  1   2   3   4   5   6   7   8   9   10   >