Re: caesar(6) to accept negative argument

2019-05-15 Thread Ted Unangst
Otto Moerbeek wrote: > We're computing modulo 26 here. Negative numbers have a positive > equivalent. So you diff adds code for no benefit. I think the amount of code added is an acceptable cost for improved user experience. We could use this argument to remove subtraction from bc, but that would

Re: free() sizes for ahc(4)

2019-05-14 Thread Ted Unangst
Miod Vallat wrote: > Note ahc_set_name() gets invoked with the dv_xname field of a struct > device, so it's not a good idea to free anything, should it be invoked > more than once. nice catch.

Re: softraid(4): fix wrong malloc size and zero sized free calls

2019-05-13 Thread Ted Unangst
Jan Klemkow wrote: > Hi, > > The diff mainly add sizes to free(9) calls. But, while here fix a > malloc(9) call with the wrong size in sr_ioctl_installboot(). > omi->omi_som is allocated with size of struct sr_meta_crypto, but used > as struct sr_meta_boot later. > > One free(9) with size zero

Re: add newline for tpm0: dmesg line

2019-05-13 Thread Ted Unangst
f. holop wrote: > dmesg: > > ... > acpibtn2 at acpi0: PWRB > tpm0 at acpi0: TPM_ addr 0xfed4/0x5000acpivideo0 at acpi0: GFX0 > acpivout0 at acpivideo0: DD1F > ... thanks

Re: sv(4): fix free with zero size

2019-05-13 Thread Ted Unangst
Jan Klemkow wrote: > Hi, > > The following diff fixes "free with zero size" in sv(4). Builds and > stats the kernel with sv at pci and audio at sv enabled. ok

Re: chroot vs su vs doas

2019-05-13 Thread Ted Unangst
Martijn van Duren wrote: > >> Would > >> doas -c /rootdir somecmd > >> be of any use ? > > > > Not particularly opposed, but the extend of this option should be > > examined. E.g. do we want to extend it to the config to be something > > similar to -u and limit it's use for certain commands? > >

Re: chroot vs su vs doas

2019-05-13 Thread Ted Unangst
Martijn van Duren wrote: > > But what would it hurt to allow root usage ? > > Specifically, > > > > doas -u ${BUILDUSER} some unquoted command > > > > as run by root. This would not open any security hole, would it ? > > I don't see any and I've been bitten by having a rootshell open and >

Re: cmdfile for config -ef

2019-05-11 Thread Ted Unangst
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

cmdfile for config -ef

2019-05-11 Thread Ted Unangst
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. Index: config.8 === RCS file: /home/cvs/src/usr.sbin/config/config.8,v retrieving revision 1.66

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

2019-05-10 Thread Ted Unangst
Ingo Schwarze wrote: > Ouch. No, it does not. Thanks for spotting the regression. > > The following patch preserves the parsing behaviour > and correctly stores the number of seconds into tm_gmtoff. oops, missed that case too. this looks correct.

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

2019-05-10 Thread Ted Unangst
Ingo Schwarze wrote: > Now let's get to the more serious part. > Hiltjo observed that %Z and %z produce wrong results. > > First of all, neither POSIX nor XPG define tm_gmtoff nor %Z nor %z: > > https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html >

Re: ssl(8), fix text about web browsers and SAN

2019-05-10 Thread Ted Unangst
Stuart Henderson wrote: > it's standard behaviour for web browsers to not use hostnames in > Subject at all but require SAN. current ssl(8) text suggests "some new" > and "deprecated" rather than "stopped supporting". > > comments/ok? I was trying to avoid argument "but my browser still works"

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

2019-05-09 Thread Ted Unangst
Ingo Schwarze wrote: > I'm not mixing anything else into this diff. The other bugs should > be handled separately. > > OK? Works for me. (with additional comment removal)

Re: stack trace / free(0) in isascan()

2019-05-09 Thread Ted Unangst
Sebastien Marie wrote: > > So calling free() with cf->cf_attach->ca_devsize should be fine. > Diff below. ok. didn't get to this one yet.

less discriminatory battlestar

2019-05-08 Thread Ted Unangst
there are lists of annointed usernames in battlestar. this creates an unfair playing field! worse, there is a list of "bad" people! and i'm almost one of them! -static const char *const badguys[] = { - "wnj", - "root", - "ted", - 0 -}; Index: com1.c

Re: Avoid system(3) in ikectl

2019-05-08 Thread Ted Unangst
Reyk Floeter wrote: > I meant: could you use /* */ instead of //? oh, sure. done. > Yes, it looks slightly better. > > grumble OK reyk thanks. Matthew, thanks.

Re: ftpd(8): rm dead code and simplifies popen clone

2019-05-08 Thread Ted Unangst
Jan Klemkow wrote: > - * Special version of popen which avoids call to shell. This ensures noone > + * Special version of popen which avoids call to shell. This ensures none If we don't like noone, the correct spelling is no one. Rest of the diff seems like a good improvement.

Re: Avoid system(3) in ikectl

2019-05-08 Thread Ted Unangst
Reyk Floeter wrote: > On Wed, May 08, 2019 at 06:44:32PM -0400, Ted Unangst wrote: > > Ted Unangst wrote: > > > Matthew Martin wrote: > > > > I did that originally [1], but Reyk preferred the varargs approach [2], > > > > so I changed the patch

Re: Avoid system(3) in ikectl

2019-05-08 Thread Ted Unangst
Ted Unangst wrote: > Matthew Martin wrote: > > I did that originally [1], but Reyk preferred the varargs approach [2], > > so I changed the patch to match. > > Sorry, only wading into the thread at this point. Seems not everybody has the > same taste in code... Well, we h

Re: Avoid system(3) in ikectl

2019-05-08 Thread Ted Unangst
Matthew Martin wrote: > I did that originally [1], but Reyk preferred the varargs approach [2], > so I changed the patch to match. Sorry, only wading into the thread at this point. Seems not everybody has the same taste in code... Well, we have the original. Let me bring that back.

Re: Avoid system(3) in ikectl

2019-05-08 Thread Ted Unangst
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 simpler. > > char *pkcs_args[] = > PATH_OPENSSL, >

Re: Avoid system(3) in ikectl

2019-05-08 Thread Ted Unangst
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) * sizeof(*argv)); > > > > > > Our source tree is exceedingly sparing in the use of alloca(). >

Re: libevent: prevent integer overflow in kqueue

2019-05-07 Thread Ted Unangst
Tobias Stoeckmann wrote: > This patch avoids a possible integer overflow on excessively large > amount of events added to an event base in kqueue mode (default). > > Just as with previous changes, this is very unlikely to trigger and > is a just a defensive measure. > > Changes in this diff: >

Re: libevent: endless loop on excessively large buffers

2019-05-02 Thread Ted Unangst
Tobias Stöckmann wrote: > Generally this is a rather theoretical case. Normal users are not > allowed to allocate so much memory. But better be safe than sorry, > especially if login.conf values were adjusted (or the process runs > as root). > > This patch completely removes "unsigned int" from

Re: libevent: remove non-monotonic compat code

2019-04-30 Thread Ted Unangst
Jeremie Courreges-Anglas wrote: > So the diff below removes the fallback path and all associated code and > variables. I have left out some minor cleanups for now to ease reviews. makes sense to me.

signify xr sysupgrade.8

2019-04-26 Thread Ted Unangst
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: /home/cvs/src/usr.bin/signify/signify.1,v retrieving revision 1.46 diff

Re: tmpfile and pledge

2019-04-25 Thread Ted Unangst
Martijn van Duren wrote: > Is there a sound reason to keep this code here that I'm overlooking > or can we please remove it? I'll add that the umask calls make this function unsafe in a threaded program, which I think is unexpected.

Re: Booting Threadripper 2950x with -current

2019-04-23 Thread Ted Unangst
Bryan Steele wrote: > > I just got through building a new desktop machine and thought I'd > > install OpenBSD -current on it. The install kernel booted quite fast, > > but now that I have the real kernel there, it takes approximately 5 > > minutes to boot. The vast majority of the time is spent

Re: libevent: Protect integer multiplications (min_heap)

2019-04-23 Thread Ted Unangst
Tobias Stoeckmann wrote: > On Mon, Apr 22, 2019 at 01:24:13PM -0400, Ted Unangst wrote: > > ah, good catch. I don't think it's wrong (until it overflows) but needs to > > be > > fixed. Needs some more review then. Thanks. > > I have added following changes: >

Re: libevent: Protect integer multiplications (min_heap)

2019-04-22 Thread Ted Unangst
Tobias Stoeckmann wrote: > Changing n means that at least timeout_correct in event.c must be > adjusted as well, because it is used as an unsigned: ah, good catch. I don't think it's wrong (until it overflows) but needs to be fixed. Needs some more review then. Thanks.

Re: libevent: Protect integer multiplications (min_heap)

2019-04-20 Thread Ted Unangst
Tobias Stoeckmann wrote: > I would like to protect min_heap_push against integer overflows, > which could either be triggered on a 64 bit system with massive > amounts of RAM (to overflow s->n) or on a 32 bit system with tight > memory layout (overflowing a * sizeof *p). > > Both cases are

Re: libevent: Protect integer multiplications (min_heap)

2019-04-18 Thread Ted Unangst
Ted Unangst wrote: > (and then reformat to be knf, but after changes that require review.) mostly mechanical.. we'll get to real changes eventually :) Index: min_heap.h === RCS file: /cvs/src/lib/libevent/min_heap.h,v retriev

Re: libevent: Protect integer multiplications (min_heap)

2019-04-17 Thread Ted Unangst
Theo de Raadt wrote: > So the diff presented falls short of what should be done here; > insufficient lines deleted. we're not getting to the fun part yet, but this unfold some complex operations to assist human readers. -min_child -= min_child == s->n ||

Re: fsync(2) and I/O errors

2019-04-16 Thread Ted Unangst
Oh, right, I reworded it slightly, but I think this is something we should note. Index: fsync.2 === RCS file: /home/cvs/src/lib/libc/sys/fsync.2,v retrieving revision 1.14 diff -u -p -r1.14 fsync.2 --- fsync.2 10 Sep 2015

Re: introduce 'pfctl -FR' to reset settings to defaults

2019-04-03 Thread Ted Unangst
Alexandr Nedvedicky wrote: > below is the diff I'd like to commit. this is fine with me.

Re: nvme_pci.c patch for MSI-X

2019-04-01 Thread Ted Unangst
Mark Kettenis wrote: > > Date: Thu, 28 Mar 2019 09:00:35 -0700 > > From: Chris Cappuccio > > > > I think the current MSI-X implementation is a minimal skeleton, > > enough for some devices under virtualization. I don't know if it's > > enough for NVMe on real hardware. > > The main problem is

Re: sbin/wsconsctl: show more data

2019-03-27 Thread Ted Unangst
Frederic Cambus wrote: > On Mon, Mar 18, 2019 at 08:02:09PM +0200, Artturi Alm wrote: > > > > Revised diff below iterating on what Artturi previously sent, and > > > a snippet of wsconsctl output with the diff applied: > > > > > > display.width=1600 > > > display.height=900 > > >

Re: pfctl should allow administrator to flush _anchors

2019-03-25 Thread Ted Unangst
Alexandr Nedvedicky wrote: > it is, however -Fall operates on main ruleset only. -Fall also does > not reset limits and timeouts. Hence my first idea was to introduce > '-FNuke', which kills all rulesets and tables. > > I don't want to change behaviour of existing option

Re: remove date from signify zsig

2019-03-18 Thread Ted Unangst
Andre Stoebe wrote: > Hi, > > I, too, would like to have a way of signing the gzip archive in a > reproducible way, so here's a diff that uses -n, similar to gzip(1). Thanks. I think it's more consistent to store a zero time stamp. This diff is a little simpler and avoids some variable reabuse.

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

2019-03-17 Thread Ted Unangst
Hiltjo Posthuma wrote: > Not all BSD man pages reference the same RFCs, like RFC5322. The OpenBSD > strptime(3) man page (%z) describes military/nautical zones are supported. > > - NetBSD supports it (correctly since only a few months ago and it is not in > stable or backported). > - FreeBSD

Re: xterm and wcwidth()

2019-03-08 Thread Ted Unangst
Matthieu Herrb wrote: > I would prefer a diff that just add a &&!defined(__OpenBSD__) to the > condition before the definition of systemWcwidthOk(). This will cause > less risk of conflicts in future updates and clearly show the > intention. If you prefer that, I would suggest the following to

Re: xterm and wcwidth()

2019-03-08 Thread Ted Unangst
Lauri Tirkkonen wrote: > in other words, xterm is (and was) using its own idea of how many > columns characters take up. The way this manifested itself to me was > that I received some email that contained emoji characters in the > subject, and they look fine in mutt when I use another terminal

Re: reverse scroll direction wstpad

2019-03-05 Thread Ted Unangst
Ulf Brosziewski wrote: > BTW, reverting the scroll direction is also possible by configuring > a "ZAxisMapping" in ws(4), with an xorg.conf like this one: > > Section "InputClass" > Identifier "touchpad_scroll_buttons" > MatchIsTouchPad "true" > Option "ZAxisMapping" "5 4" >

reverse scroll direction wstpad

2019-03-02 Thread Ted Unangst
One more quick hack. I have become accustomed to scroll going in the reverse direction. Previously set a negative delta with synclient. Again, not sure how to connect this to wsconsctl, but here's what I'm running. Index: wstpad.c

one button only tapping

2019-03-01 Thread Ted Unangst
I used to use synclient to configure taps for only a single button. I find two and three button taps problematic, resulting in crazy highlighting and pasting. New computer uses wstpad, however, so there's no more synclient. Patch below changes wstpad to only report button clicks for single taps.

apm doesn't take arguments

2019-02-28 Thread Ted Unangst
apm should not silently ignore bonus args. Index: apm.c === RCS file: /cvs/src/usr.sbin/apm/apm.c,v retrieving revision 1.34 diff -u -p -r1.34 apm.c --- apm.c 14 Aug 2018 06:38:33 - 1.34 +++ apm.c 28 Feb 2019

Re: remove date from signify zsig

2019-02-25 Thread Ted Unangst
Marc Espie wrote: > On Mon, Feb 25, 2019 at 03:02:42PM -0500, Ted Unangst wrote: > > Andre Stoebe wrote: > > > Hi, > > > > > > I, too, would like to have a way of signing the gzip archive in a > > > reproducible way, so here's a diff that uses

Re: Harmonize examples in signify man page

2019-02-25 Thread Ted Unangst
Matthias Schmidt wrote: > Hi, > > while looking at signify's man page I noticed that the names of the > arguments in the EXAMPLES section change (newkey.sec vs key.sec, etc). > The diff harmonizes the examples. It makes it easier to follow the examples. I don't think the intention was to

Re: remove date from signify zsig

2019-02-25 Thread Ted Unangst
Andre Stoebe wrote: > Hi, > > I, too, would like to have a way of signing the gzip archive in a > reproducible way, so here's a diff that uses -n, similar to gzip(1). > > However, if that's a bad idea, I'm fine with continuing to use an > unsigned gzip archive and creating a sigfile with

Re: remove date from signify zsig

2019-02-24 Thread Ted Unangst
Stuart Henderson wrote: > On 2019/02/23 18:02, Ted Unangst wrote: > > signify -z adds a date= line to the header, but nothing reads it. It's also > > not very useful, since it's outside the signature. It would still not be > > useful, because nothing about the signify de

remove date from signify zsig

2019-02-23 Thread Ted Unangst
signify -z adds a date= line to the header, but nothing reads it. It's also not very useful, since it's outside the signature. It would still not be useful, because nothing about the signify design cares about when something was signed. It does cause trouble, however, because signing the same

move variable in signify/zsig.c

2019-02-23 Thread Ted Unangst
There's exactly one global variable in signify, but it could be local. We do write to this variable, but not to move data between functions. Index: zsig.c === RCS file: /cvs/src/usr.bin/signify/zsig.c,v retrieving revision 1.15 diff

Re: more mem for dirhash

2019-02-21 Thread Ted Unangst
Jeremie Courreges-Anglas wrote: > I may be naive, but shouldn't dirhash memory be accounted with/like > buffer cache memory (freed when other sybsystems need it)? Probably. The limit exists in part because there is no backpressure.

more mem for dirhash

2019-02-20 Thread Ted Unangst
UFS dirhash has a limit on how much memory is used to prevent runaway allocations. I believe the default limit (2MB) is rather conservative. It was picked to avoid causing trouble back when machines were tiny and dirhash was new. For example, a maildir with 100K files takes about 3MB of memory.

Re: strptime: %e and leading space

2019-02-17 Thread Ted Unangst
Klemens Nanni wrote: > I came across this thanks to a nicely detailed bug report about > mail/isync's `CopyArrivalDate' feature, which uses strptime(3). Quote: > > The IMAP protocol specifies a date format beginning with a > day-of-month space-padded to two characters. The %d

Re: dd conv=fsync

2019-02-15 Thread Ted Unangst
Alexander Bluhm wrote: > We should not implement the magic which device allows fsync(2) into > dd(1). Just do what the user says, if it is nonsense, give him an > error. sure. ok.

Re: dd conv=fsync

2019-02-14 Thread Ted Unangst
Alexander Bluhm wrote: > GNU dd has the conv=fsync feature which does an fsync(2) after final > write to output. I find this useful for write performance measurement > through the file system without buffer cache optimization. Others > may like the reliable storage guarantee of fsync(2). > > Do

Re: install(1) broken

2019-02-10 Thread Ted Unangst
Marc Espie wrote: > Something similar to this perhaps ? > Not fully tested yet, but it should avoid the race of trying to > unlink tempfile several times, and also fix the file name in error messages. That's probably better.

Re: install(1) broken

2019-02-09 Thread Ted Unangst
Marc Espie wrote: > hey, your commit to install(1) broke something. > > Specifically lang/go-boostrap now produces a broken package which can't > be used to build go. > > All the go/bootstrap/pkg/tool/openbsd_amd64/* > have lost their x bit > > Relevant fake install information, it definitely

Re: scan_ffs(8) and FFS2 filesystems

2019-02-09 Thread Ted Unangst
gwes wrote: > > > On 02/08/19 15:35, 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? > > > > > > --- scan_ffs.8.~1.16.~ Mon Mar 24 00:28:46 2008 > > +++ scan_ffs.8 Fri Feb 8

help kmem pressure in pool

2019-02-06 Thread Ted Unangst
We have iterated on various designs to reduce pressure on kmem map over time. One of the problems is that sometimes you want to allocate something in intr context (NOWAIT), and other times in process context (WAITOK), but then at free time they get all glommed together. This happens in pool.

Re: missing regex fix from FreeBSD?

2019-02-04 Thread Ted Unangst
enh wrote: > it seems like OpenBSD did cherrypick this FreeBSD regex fix... > > https://github.com/freebsd/freebsd/commit/981dd2aa38f37e4d0dd86225c619e900fc03d82e#diff-d7c26714f9432399b202eefcedb97491 That's an odd way to phrase applying a diff that was sent to OpenBSD... > ...but not this one,

Re: games/fortune translation fix

2019-02-02 Thread Ted Unangst
Jason McIntyre wrote: > though i suspect "asperity" would have most of us reaching for our > dictionaries, it's not neccessarily a bad thing. it seems the > best fit to me. That may be construed as the one going to the stars is the one with the asperity, however. I think the intention is to

Re: sysctl(2): KERN_CACHEPCT is capped at ~3GB

2019-01-31 Thread Ted Unangst
Alex Holst wrote: > Quoting Mark Kettenis (mark.kette...@xs4all.nl): > > An accurate description would be that the percentage is actually the > > percentage of "DMA-reachable" physical memory the buffer cache may > > use. The minimum percentage is 5% and the maximum is 90%. > > > > But

Re: fsync(2) and I/O errors

2019-01-31 Thread Ted Unangst
Ted Unangst wrote: > > Keeping a buf with an error in the delayed write list would probably have > > some > > serious consequences. When would we ever remove it? > > Thought about this some more. The best approach may be to set a flag in > the vnode that there

Re: archaic quotes in calendar

2019-01-31 Thread Ted Unangst
Anthony J. Bentley wrote: > Jason McIntyre writes: > > in the man page you have used Sq. that will make it mark up the same as > > it already does: > > > > (`*') fwiw there was already an existing sq in the man page. I only fixed the one using literal single quotes. > There's a difference:

Re: sysctl kern.pool.XXX

2019-01-30 Thread Ted Unangst
Amit Kulkarni wrote: > This comment below is misleading. There are no such sysctl's. The defines are > only used in kern/subr_pool.c > ... to implement the sysctls. What are you talking about? > > > diff --git sys/pool.h sys/pool.h > index d2f05227b7a..e97f774a272 100644 > --- sys/pool.h >

tar t and broken pipes

2019-01-30 Thread Ted Unangst
I have a very large (gzipped) archive and I've forgotten exactly how the contents are structured. (is it stuff, tedu/stuff, etc.) I run tar ztf bananas.tgz | head. This prints out a few lines, and then... nothing. For a long time. head is long gone, but tar is still chugging away. Aren't

Re: grep: convert fgetln to getline

2019-01-30 Thread Ted Unangst
Lauri Tirkkonen wrote: > In summary: sorry for the bug I introduced - please apply the diff above > to fix memory mapping files in grep. As for the fgetln->getline > conversion, I think this result should show that fgetln is not > particularly smart about how it's calling mmap -- getline seems

Re: ASN1_get_object.3

2019-01-30 Thread Ted Unangst
Kristaps Dzonsons wrote: > > Attached is a manpage for ASN1_get_object(3), ASN1_put_object(3), and > > ASN1_put_eoc(3). Having the first function documented would have saved > > me a lot of time. (I did the others for symmetry.) > > > > In short, they encode or decode ASN.1 data structures

archaic quotes in calendar

2019-01-29 Thread Ted Unangst
Run calendar without a calendar file. calendar: no calendar file: ``calendar'' or ``~/.calendar/calendar'' I think these fake double quotes are really ugly. It's been a long time since the typical font rendered them symmetrically. Also, fix another instance in the man page. There's more to be

Re: install(1) could fail due to race

2019-01-27 Thread Ted Unangst
Ingo Schwarze wrote: > If people here agree with the general direction of making -S the > default and removing the fragile non-S mode (see the patch below), > i'll run a full make build and make release and then ask for OKs. Just checking we didn't forget about this. Seems the right thing to do.

Re: fsync(2) and I/O errors

2019-01-27 Thread Ted Unangst
Ted Unangst wrote: > Maximilian Lorlacks wrote: > > Good day, > > > > It seems that fsync(2) may data after returning EIO once[1]. This > > behaviour seems to cause problems with databases such as PostgreSQL > > and goes contrary to the man page's descri

Re: fsync(2) and I/O errors

2019-01-26 Thread Ted Unangst
Maximilian Lorlacks wrote: > Good day, > > It seems that fsync(2) may data after returning EIO once[1]. This > behaviour seems to cause problems with databases such as PostgreSQL > and goes contrary to the man page's description, which says that > "fsync() and fdatasync() should be used by

Re: grep: convert fgetln to getline

2019-01-23 Thread Ted Unangst
Lauri Tirkkonen wrote: > > > oh, interesting. that's sloppy. can you please fix that first, separately? > > > > Sure, here it is. > > Could you please take a look at it? It's been a couple weeks. yup, sorry, slipped by. committed.

Re: friendlier doas persist

2019-01-23 Thread Ted Unangst
Stuart Henderson wrote: > On 2019/01/22 21:46, Ted Unangst wrote: > > The persist feature in doas (actually the kernel side implementation) has > > some > > additional checks. The idea was to prevent accidental usage, but in practice > > it seems this is making life mo

friendlier doas persist

2019-01-22 Thread Ted Unangst
The persist feature in doas (actually the kernel side implementation) has some additional checks. The idea was to prevent accidental usage, but in practice it seems this is making life more difficult than necessary. It's cost without benefit. This diff relaxes the session checks so it should be

sensors hiding with pledge

2019-01-21 Thread Ted Unangst
We recently had a thread about adding more sensors, but then the browser will use them to spy on us, and everybody was sad. We allow hw.sensors even for pledge processes because ntpd needs to read the time. However, ntpd only needs to read the time. This diff zeroes out sensors other than

Re: replacing timeout_add() with timeout_add_msec()

2019-01-21 Thread Ted Unangst
Scott Cheloha wrote: > > > diff --git sys/arch/sparc64/dev/fd.c sys/arch/sparc64/dev/fd.c > > > index 8d548062f83..654d8c95524 100644 > > > --- sys/arch/sparc64/dev/fd.c > > > +++ sys/arch/sparc64/dev/fd.c > > > @@ -1632,7 +1632,7 @@ loop: > > > fdc->sc_state = RECALCOMPLETE; > > >

snake bug

2019-01-19 Thread Ted Unangst
mlarkin discovered that if the treasure lands on the snake, you won't see it. it's still there, but invisible. this fixes the display to draw the correct character. Index: snake.c === RCS file: /cvs/src/games/snake/snake.c,v

Re: [PATCH] systat reports inaccurate statistics for disk i/o speed

2019-01-19 Thread Ted Unangst
Bryan Linton wrote: > Hello tech@, > > I'd appreciate it if someone could review both this patch and my > analysis. There is no reason for etime to be a global. We can make it a local with the correct value in the two functions that use it, avoiding future problems as well. Index: vmstat.c

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

2019-01-18 Thread Ted Unangst
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. I guess it's technially correct,

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

2019-01-15 Thread Ted Unangst
Nicholas Marriott wrote: > I think I would avoid adding more of these at the moment, especially > ones that aren't very specific (why is "package" Go and not Java?) and Because I've never written a java package. :)

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

2019-01-14 Thread Ted Unangst
Matteo Niccoli wrote: > Didn't find any other examples. At the moment rust code is recognized > as ASCII C program text. src/usr.bin/file/text.c has an array of special matches for text. It has various omissions, though. is matched as SGML. import means Java, but not python or go. etc. I

Re: off by one ksh

2019-01-13 Thread Ted Unangst
Ingo Schwarze wrote: > Feel free to either commit the complete patch below or commit > only your part and optionally OK one, two, or three of my additional > changes. These look ok with one comment. > @@ -141,8 +141,11 @@ mpset(char *mptoparse) > mmsg = strchr(mpath, '?');

off by one ksh

2019-01-13 Thread Ted Unangst
By inspection, it appears possible this access will underrun if the first character is a %. Index: mail.c === RCS file: /cvs/src/bin/ksh/mail.c,v retrieving revision 1.25 diff -u -p -r1.25 mail.c --- mail.c 7 Jan 2019 20:50:43

Re: locale in locate(1)

2019-01-13 Thread Ted Unangst
Ingo Schwarze wrote: > So, here is some cleanup: > * garbage collect useless hand-rolled lookup tables > * merge one-line helper functions into callers > * garbage collect obfuscating macros > * fix one format string error (%d used for u_int) > * garbage collect setlocale(3) and > * garbage

Re: Virtio 1.0 for the kernel

2019-01-11 Thread Ted Unangst
Stefan Fritsch wrote: > On Fri, 11 Jan 2019, Ted Unangst wrote: > A simple inline function does not work because memb is the name of a > member of a struct. But combined with a macro it would work. Like this: yeah, that looks pretty normal.

Re: Virtio 1.0 for the kernel

2019-01-11 Thread Ted Unangst
Stefan Fritsch wrote: > +#define CREAD(sc, memb) > \ > + ({ > \ > + struct virtio_pci_common_cfg c; > \ > +

Re: LC_NUMERIC in wprintf(3)

2019-01-11 Thread Ted Unangst
Ingo Schwarze wrote: > That stuff is a very serious trap not only for the unwary, but also > for experienced programmers. Less than a month ago, i discussed > the matter with a senior programmer from the GNU project who has > been maintaining important software over there for a long time and >

Re: locale in locate(1)

2019-01-10 Thread Ted Unangst
Scott Cheloha wrote: > > On Jan 10, 2019, at 14:35, Jan Stary wrote: > > > > Does locate(1) need to setlocale(3)? > > locate(1) uses tolower(3), the results of which can be affected by > locale settings. locate(1)'s database is, at least in theory, portable. > If you don't explicitly set the

Re: LC_TIME in calendar(1)

2019-01-10 Thread Ted Unangst
Jan Stary wrote: > calendar imho doesn't need to setlocale(LC_TIME, ...) > before and after strftime(3), as LC_TIME is ignored. iirc, our current practice is to delete locale related calls where the functionality isn't implemented, so this and the other diffs are ok.

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

2019-01-09 Thread Ted Unangst
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 pretty bad. If the new task

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

2019-01-09 Thread Ted Unangst
Mark Kettenis wrote: > Index: dev/acpi/dsdt.c > === > RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v > retrieving revision 1.243 > diff -u -p -r1.243 dsdt.c > --- dev/acpi/dsdt.c 19 Aug 2018 08:23:47 - 1.243 > +++ dev/acpi/dsdt.c

Re: install(1) could fail due to race

2019-01-07 Thread Ted Unangst
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 you have softupdates enabled. >

Re: install(1) could fail due to race

2019-01-07 Thread Ted Unangst
Lauri Tirkkonen wrote: > On Mon, Jan 07 2019 15:48:25 -0500, Ted Unangst wrote: > > Lauri Tirkkonen wrote: > > > Hi, it seems install(1) has a race condition: in create_newfile, it > > > first unlinks the target file and then tries to open it with > > > O_CRE

Re: sbin/wsconsctl: show more data

2019-01-07 Thread Ted Unangst
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? speaking of ugly... it should print

Re: install(1) could fail due to race

2019-01-07 Thread Ted Unangst
Lauri Tirkkonen wrote: > Hi, it seems install(1) has a race condition: in create_newfile, it > first unlinks the target file and then tries to open it with > O_CREAT|O_EXCL. > The below diff essentially removes the -S option and makes install > always use temp files (ie. -S is always on),

Re: grep: convert fgetln to getline

2019-01-07 Thread Ted Unangst
Lauri Tirkkonen wrote: > On Sun, Jan 06 2019 14:02:16 -0500, Ted Unangst wrote: > > Lauri Tirkkonen wrote: > > > Hi, another simple diff converting fgetln usage to getline. > > > > > > I also considered converting grep_fgetln to grep_getline, but that would >

Re: grep: convert fgetln to getline

2019-01-06 Thread Ted Unangst
Lauri Tirkkonen wrote: > Hi, another simple diff converting fgetln usage to getline. > > I also considered converting grep_fgetln to grep_getline, but that would > mean that for FILE_MMAP we'd have to copy the string. So this diff keeps > the grep_fgetln interface as is, but avoids using fgetln

  1   2   3   4   5   6   7   8   9   10   >