Re: grep: add --null flag

2021-01-24 Thread Ted Unangst
On 2021-01-25, Sebastian Benoit wrote: > Sebastian Benoit(be...@openbsd.org) on 2021.01.25 00:27:05 +0100: > > Theo de Raadt(dera...@openbsd.org) on 2021.01.24 16:01:32 -0700: > > > Stuart Henderson wrote: > > > > > > > On 2021/01/24 12:10, Theo de Raadt wrote: > > > > > I completely despise

Re: grep: add --null flag

2021-01-24 Thread Ted Unangst
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 though, just patch the implementation once. > > (TBH: I have still to look at how to write a regression test for this) > > Omar

Re: doas sprinkle some more CFLAGS

2020-12-19 Thread Ted Unangst
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 int > match(uid_t uid, gid_t

Re: doas: improve error message

2020-10-08 Thread Ted Unangst
On 2020-10-09, Klemens Nanni wrote: > In case `cmd' and `args' in doas.conf(5) do not match, the generated > log message is unclear and might be read as if the command executed but > failed, i.e. returned non-zero: > > # cat /etc/doas.conf > permit nopass kn cmd echo args foo >

Re: apmd(8) and hw.perfpolicy quirks

2020-09-27 Thread Ted Unangst
On 2020-09-27, Jeremie Courreges-Anglas wrote: > The diff below teaches apmd(8) -H to set hw.perfpolicy="manual" and > hw.setperf=100, instead of setting hw.perfpolicy="high". sure. if you would like to own this, by all means. :)

Re: apmd(8) and hw.perfpolicy quirks

2020-09-23 Thread Ted Unangst
On 2020-09-23, Jeremie Courreges-Anglas wrote: > ok? Seems fine. > Note: I inlined the apmd(8)->apm(8) perfpolicy conversion for now, which > brings a question. I find it weird that there is a special "high" > perfpolicy (effectively similar to perfpolicy=manual + setperf=100) but > no "low"

Re: PATCH: better error return for exFAT filesystem

2020-08-09 Thread Ted Unangst
On 2020-08-09, Jonathan Gray wrote: > mount_msdos(8) knows about EINVAL and will print "not an MSDOS filesystem" I think mount_msdos could also inspect the filesytem for the common case of exfat confusion. Index: mount_msdos.c ===

Re: disable libc sys wrappers?

2020-07-13 Thread Ted Unangst
On 2020-07-09, Theo de Raadt wrote: > > Added a -T option to ktrace for transparency. I got ambitious here and made > > it take suboptions, anticipating that other transparency modifications may > > be desired. > > Please don't do that. Here is a simpler version. Index: lib/libc/dlfcn/init.c

Re: disable libc sys wrappers?

2020-07-09 Thread Ted Unangst
On 2020-07-09, Theo de Raadt wrote: > Hang on. Do people ever want to force time calls, outside of ktrace? > I doubt it. Should ktrace maybe have a flag, similar to -B with LD_BIND_NOW, > which sets the new environment variable? Maybe -T? The problem smells very > similar to the root cause for

Re: pshared semaphores

2020-07-09 Thread Ted Unangst
On 2020-07-08, Mark Kettenis wrote: > > From: "Ted Unangst" > > Date: Wed, 08 Jul 2020 05:20:23 -0400 > > > > On 2020-07-08, Ted Unangst wrote: > > > I think this makes sem_init(pshared) work. > > > > Whoops, need more context to incl

Re: disable libc sys wrappers?

2020-07-09 Thread Ted Unangst
On 2020-07-08, Theo de Raadt wrote: > I think we need something like this. > > Documenting it will be a challenge. > > I really don't like the name as is too generic, when the control is only > for a narrow set of "current time" system calls. I thought I'd start with something, but lots of

disable libc sys wrappers?

2020-07-08 Thread Ted Unangst
Not sure how useful this will be, but I think it could be helpful to still see section (2) functions in ktrace, even if there's magic to avoid that. As proof of concept, if env LIBC_NOSYSWRAPPERS is set, the libc timecounters are turned off. Now I see lots of gettimeofday syscalls in ktrace

pshared semaphores

2020-07-08 Thread Ted Unangst
I think this makes sem_init(pshared) work. I have a test program from Lauri Tirkkonen and if I've understood it correctly, it works now. The essence of the diff is that we must eliminate the indirection so that the application can properly allocate (mmap) the semaphore into shared memory.

Re: pshared semaphores

2020-07-08 Thread Ted Unangst
On 2020-07-08, Ted Unangst wrote: > I think this makes sem_init(pshared) work. Whoops, need more context to include the header file changes. Index: include/semaphore.h === RCS file: /home/cvs/src/include/semaphore.h,v retriev

Re: Avoid offline cpu in automatic frequency scheduling

2020-05-28 Thread Ted Unangst
On 2020-05-28, Solene Rapenne wrote: > > > In the current case, if you have offline cpu (because of hw.smt=0), > > > the total will still sum all the idle cpu and it's unlikely that > > > the total threshold is ever reached before the per cpu one. > > > > > > so, this diff skip offline cpus in

Re: Untangle proc * in VOP_*

2020-03-23 Thread Ted Unangst
On 2020-03-23, Martin Pieuchot wrote: > Most of the VOP_* methods include an argument of type "struct proc *" > called `a_p'. This pointer is always set to `curproc' as confirmed by > the diff below. The diff has been though base build with NFS on amd64 > and sparc64 as well as a full port bulk

Re: librthread sem_t opaqueness, storage & unnamed semaphore sharing

2020-03-02 Thread Ted Unangst
On 2020-03-02, Lauri Tirkkonen wrote: > Thanks for the input, and ping - is there still something about this > diff that I should fix? I'm kinda busy, but I should be able to look into it eventually.

Re: librthread sem_t opaqueness, storage & unnamed semaphore sharing

2020-02-24 Thread Ted Unangst
Martin Pieuchot wrote: > On 24/02/20(Mon) 11:29, Lauri Tirkkonen wrote: > > On Mon, Feb 24 2020 10:24:53 +0100, Martin Pieuchot wrote: > > > On 23/02/20(Sun) 14:48, Lauri Tirkkonen wrote: > > > > I was working on a make jobserver implementation that uses POSIX > > > > semaphores as job tokens

refer to pointers as non-null

2020-01-31 Thread Ted Unangst
Noticed this in wait.2, though I imagine other occurences abound. I believe non-null is clearer when refering to a pointer than non-zero, which is a bit 80s, and less likely to be mistaken for the value pointed to. This same page also refers to non-zero values, fwiw. Index: wait.2

Re: Teach du(1) the -m flag, disk usage in megabytes

2020-01-26 Thread Ted Unangst
Jonathan Gray wrote: > On Sun, Jan 26, 2020 at 11:59:33AM -0500, David Goerger wrote: > > This diff teaches du(1) the -m flag, report disk usage in megabytes. > > This brings us in line with implementations in the other BSDs, Linux, > > and Illumos. > > Why is it needed? -k is required by

Re: apmd: fix autoaction timeout

2020-01-25 Thread Ted Unangst
Jeremie Courreges-Anglas wrote: > > The diff below improves the way apmd -z/-Z may trigger. > > I think the current behavior is bogus, incrementing and checking > apmtimeout like this doesn't make much sense. this all seems reasonable to me. > - I think we want some throttling mechanism, like

apmd poll every minute

2020-01-24 Thread Ted Unangst
Sometimes (particuarly if you are using apmd -z) the default polling interval of 10 minutes is a bit lazy and we fail to respond to low battery situations before they become no battery situations. Perhaps something smarter could be done, but the simplest change is to reduce the default polling

Re: acpivout(4): directly call ws_[gs]et_param

2020-01-23 Thread Ted Unangst
Patrick Wildt wrote: > acpivout_[gs]et_param don't know if they are being called by itself > or by someone else. I don't need to grab it again, I just need to > have it before calling an ACPI method. But when acpivout(4) calls > itself, it already has it, so taking it again would break it, as

Re: acme-client calloc fix

2020-01-22 Thread Ted Unangst
Matthew Martin wrote: > On Wed, Jan 22, 2020 at 12:44:18AM -0500, Ted Unangst wrote: > > should not size the size until the allocation succeeds, or the free path > > will > > try to deref the null array. > &

semicolon reduction

2020-01-21 Thread Ted Unangst
don't need semicolon after } in statements. Index: ifconfig/brconfig.c === RCS file: /home/cvs/src/sbin/ifconfig/brconfig.c,v retrieving revision 1.24 diff -u -p -r1.24 brconfig.c --- ifconfig/brconfig.c 24 Oct 2019 18:54:10 -

acme-client calloc fix

2020-01-21 Thread Ted Unangst
should not size the size until the allocation succeeds, or the free path will try to deref the null array. Index: json.c === RCS file: /home/cvs/src/usr.sbin/acme-client/json.c,v retrieving revision 1.14 diff -u -p -r1.14 json.c ---

Re: piixpm(4) on ATI SBx00

2020-01-21 Thread Ted Unangst
Karel Gardas wrote: > > > On 1/21/20 2:33 AM, Claudio Jeker wrote: > > Please test this since I can't test this properly at the moment. > > Would like to, but all hunks fail on today current: it's been committed.

Re: check hhmm for leave

2020-01-21 Thread Ted Unangst
Scott Cheloha wrote: > > 1) it isn't documented that + can take a smaller number > > 2) it will be hard to train people to use +0001 > > These are my concerns as well. > > An idea I had a while back was to drop support for +hhmm and just > support +minutes, like we do with shutdown(8). The

check hhmm for leave

2020-01-21 Thread Ted Unangst
In testing leave, I found it accepts "12" and will alarm at 00:12, which is probably not desirable. this check thats the specified time has 4 digits so that the hour/minute math works properly. Index: leave.c === RCS file:

leave.1

2020-01-21 Thread Ted Unangst
Rewrite some of the page to avoid second person. Index: leave.1 === RCS file: /home/cvs/src/usr.bin/leave/leave.1,v retrieving revision 1.16 diff -u -p -r1.16 leave.1 --- leave.1 13 Jul 2018 16:59:46 - 1.16 +++ leave.1

Re: [patch] signify's file name parsing broken

2020-01-21 Thread Ted Unangst
Ted Unangst wrote: > MarcusMüller wrote: > > I've just stumbled across a malfunction in signify: It cannot handle > > file names that contain a `)` character, when checking a list of hashes > > generated by `sha256` command line utilities (`sha256sum --tags` on >

Re: key guessing for signify -C

2020-01-20 Thread Ted Unangst
Theo Buehler wrote: > Two small things for signify -C: > > Contrary to what usage suggests, the -p pubkey argument for signify -C > is optional in that signify will use the key specified in the untrusted > comment. In -V mode, the key can be tied down a little by specifying -t. > > Right now,

Re: [patch] signify's file name parsing broken

2020-01-20 Thread Ted Unangst
MarcusMüller wrote: > I've just stumbled across a malfunction in signify: It cannot handle > file names that contain a `)` character, when checking a list of hashes > generated by `sha256` command line utilities (`sha256sum --tags` on > Linux). This fix is unfortunately rather complicated for

Re: nfs mp vnode list remove safe

2020-01-14 Thread Ted Unangst
Alexander Bluhm wrote: > Hi, > > There is no remove and no sleep in this loop. So _SAFE is unnecessary. > > ok? sure, with one bonus note. > > bluhm > > Index: nfs/nfs_subs.c > === > RCS file:

Re: dangling vnode panic

2020-01-09 Thread Ted Unangst
Martin Pieuchot wrote: > On 09/01/20(Thu) 10:46, Alexander Bluhm wrote: > > Without this diff my regress machines became so unstable, that they > > often do not finish the test run. > > > > With this diff, they run fine. No regressions. > > Sadly this is a workaround. What is the issue? We're

Re: Scrolling in top(1)

2020-01-05 Thread Ted Unangst
Vadim Zhukov wrote: > Today I get really upset and angry due limitation of top(1): it shows > only hrrm, top processes (thank you, Chromium). Now here is a diff that > allows you to scroll process list by line or by half a screen. > > I've used the '0' and '9' keys to scroll down and up,

Re: Add -R alias to -r for scp(1)

2020-01-01 Thread Ted Unangst
Kurt Mosiejczuk wrote: > cp(1) uses -R for recursive copy. scp(1) uses -r. This diff adds -R as an > alias for -r to scp(1) for those assuming consistency with cp(1). But it doesn't implement cp -R semantics. It does the copy the way cp -r does. (For symlinks, etc.)

Re: uvm_mapanon() & trylock

2019-12-01 Thread Ted Unangst
Martin Pieuchot wrote: > On 08/11/19(Fri) 17:54, Martin Pieuchot wrote: > > uvm_mapanon() is called in two occasions: mmap(2) and sigaltstack(2). > > Both code paths are obviously in process context an can sleep. That > > explains why none of them set the UVM_FLAG_TRYLOCK when calling such > >

Re: [PATCH] make: implement jobserver and use it to avoid exponential behavior

2019-11-27 Thread Ted Unangst
Marc Espie wrote: > reorganizing a large part of usr.bin or usr.sbin to just be one > single variation of bsd.prog.mk with multiple progs and multiple object > files... works just fine for, say 95% of the binaries in those directories > > (considering there are lots of directories with one single

Re: hexdump in boot loader

2019-11-26 Thread Ted Unangst
Alexander Bluhm wrote: > + > + for (n = 1; n < cmd.argc; n++) { > + p = cmd.argv[n]; > + if (*p == '0') { > + p++; > + if (*p == 'x' || *p == 'X') { > + p++; > + b = 16; > +

Re: Go vs uvm_map_inentry()

2019-11-03 Thread Ted Unangst
Martin Pieuchot wrote: > The last, now reverted change, to uvm_map_inentry() exposes a race that > is reproducible while building lang/go on amd64 which makes uvm_fault() > fail, resulting a in a SIGSEV of at least one of the processes. > Interestingly the machine cannot reproduce the race if the

Re: _pbuild user to have priority=5

2019-11-01 Thread Ted Unangst
Theo de Raadt wrote: > What about all the other users who aren't in staff? > > I think the approach is right. Push non-interactive down. The same then for src build user?

Re: uvm_map_inentry() & KERNEL_LOCK()

2019-10-31 Thread Ted Unangst
Theo de Raadt wrote: > In uvm_map_inentry_fix(), two variables in the map are now being read > without a per-map read lock, this was previously protected by the > kernel lock > > if (addr < map->min_offset || addr >= map->max_offset) > return (FALSE); > > When I wrote

random safety for pbkdf

2019-10-15 Thread Ted Unangst
In the event that a program uses invalid parameters, I think we should overwrite the key with random data. Otherwise, there's a chance the program will continue with a zero key. It may even appear to work, encrypting and decrypting data, but with a weak key. Random data means it fails closed, and

Re: top: align CPU lines horizontally

2019-10-12 Thread Ted Unangst
Klemens Nanni wrote: > On Sat, Oct 12, 2019 at 05:38:13PM -0500, Scott Cheloha wrote: > > Also, just count how many spaces we need to print ncpuonline, > > then use that when printing the individual CPU lines. > Yup, here's a minimal diff that does that without additional buffers and > globals but

Re: top: align CPU lines horizontally

2019-10-12 Thread Ted Unangst
Klemens Nanni wrote: > On Sat, Oct 12, 2019 at 09:53:44AM -0600, Theo de Raadt wrote: > > I am suggesting you put the spaces after the cpu#. > Is this better? > > 4 CPUs: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 0.0% intr, 100% > idle > > CPU 0 : 0.0% user, 0.0% nice, 0.0% sys,

Re: more grep options (for zstdgrep)

2019-10-07 Thread Ted Unangst
While I'm looking at the man page, a minor clarification. "All long options are provided" can be read to mean that every gnu option is provided. This is not intended, and a simple reordering makes things clearer imo. Index: grep.1

more grep options (for zstdgrep)

2019-10-06 Thread Ted Unangst
The zstd package includes a zstdgrep script, which should behave like zgrep, however it assumes a few gnu grep behaviors we don't support. 1. --label=name prints a custom label, so you can get file.txt, not file.txt.zst in the output. 2. It uses - for stdin instead of a missing argument. Both

Re: pretty borders for slitherins

2019-09-26 Thread Ted Unangst
Nicholas Marriott wrote: > OK seems like it is always using ACS which is correct. > > I just remembered jmc asked me about this before and it turned out that > ACS doesn't work with the DRM console - I don't think the font have the > right symbol for either ACS or UTF-8 line drawing, but there

Re: pretty borders for slitherins

2019-09-25 Thread Ted Unangst
Scott Cheloha wrote: > On Mon, Sep 23, 2019 at 06:23:32PM -0400, Ted Unangst wrote: > > snake and worm draw boxes, but they can be prettier by using the default > > style, which will use line drawing instead of ugly -*| characters. > > > > should do the right thing

pretty borders for slitherins

2019-09-23 Thread Ted Unangst
snake and worm draw boxes, but they can be prettier by using the default style, which will use line drawing instead of ugly -*| characters. should do the right thing on a vt100, but only tested in xterm. Index: snake/snake.c === RCS

Re: msdosfs: remove timezone support

2019-08-30 Thread Ted Unangst
Scott Cheloha wrote: > The FAT file system hails from Redmond and so it tracks a timezone. > OpenBSD implicitly uses the kernel timezone when selecting which > timezone to use when mounting a FAT file system. > > This support is undocumented. > > This patch removes that support. > > The upshot

Re: Removing the kernel timezone: date(1): drop -d dst and -t minutes_west

2019-08-07 Thread Ted Unangst
Scott Cheloha wrote: > - while ((ch = getopt(argc, argv, "ad:f:jr:ut:z:")) != -1) > + while ((ch = getopt(argc, argv, "af:jr:uz:")) != -1) > switch(ch) { > case 'a': > slidetime = 1; > break; > - case 'd':

Re: Removing the kernel timezone: date(1): drop -d dst and -t minutes_west

2019-08-07 Thread Ted Unangst
Scott Cheloha wrote: > It doesn't mean anything. I guess I'm still gunshy about removing > options and breaking things after the lock(1) thing. If the default behavior changes, and the option is now meaningless, but still results in the *same* behavior, keep the option. The user still obtains

Re: csh - remove empty and duplicate unnecessary lines

2019-07-29 Thread Ted Unangst
Kalwe Caramalac wrote: > Hi, this is my first diff submission, forgive me if have any error, > if anyone has any tips on how to do this i appreciate it. > @@ -588,7 +585,6 @@ dopopd(Char **v, struct command *t) > void > dfree(struct directory *dp) > { > - > if (dp->di_count != 0) { It's

Re: apmd: zap useless globals

2019-07-21 Thread Ted Unangst
Klemens Nanni wrote: > Initialize stack variables directly instead of using global state in > between. > > OK? sure

Re: grep -ob: behave like ggrep, adapt documentation

2019-07-16 Thread Ted Unangst
Christopher Zimmermann wrote: > Hi, > > I just tried to find the byte position of a string within a binary file > using grep. Our base grep -bo let me down because it will only display > the position of the '\n' delimited line, not the position of the > pattern. > > That's what our grep(1) says:

more doas.1 tweaks

2019-06-21 Thread Ted Unangst
I think this wording clarifies what's happening. 1. Start by talking about creating a new environment. That's what we always do. Everything afterwards is an operation performed on this new environment. 2. Move the list of magic variables out of doas.conf. I think it's better to document this in

doas environmental security

2019-06-20 Thread Ted Unangst
I've made some changes to how doas handles environment variables recently. The diffs were in previous emails, and have been committed. Thanks to Sander Bos for pointing out some particular edge cases with the old handling. There are two (or more) ways to run doas. In the first, you use it to run

doas fix PATH inheritance

2019-06-17 Thread Ted Unangst
espie found a bug. we reset PATH in the parent too soon, and then it's not possible to change it back via setenv. instead of trying to move code around, save a copy of the path before we mess with it and make it available later. this lets setenv { PATH=$PATH } work. Index: doas.c

Re: new env defaults for doas

2019-06-17 Thread Ted Unangst
Todd C. Miller wrote: > On Mon, 17 Jun 2019 12:58:00 -0400, "Ted Unangst" wrote: > > > Committed this. I'm not entirely happy with the wording. I think hiding them > > under an option in the config man page is the wrong place. The default > > behavior should be

Re: new env defaults for doas

2019-06-17 Thread Ted Unangst
Ted Unangst wrote: > Yes, I think it's better to always reset these things. Here's a diff. > > 1. Always set HOME, PATH, SHELL etc to the target. Committed this. I'm not entirely happy with the wording. I think hiding them under an option in the config man page is the wrong place. Th

Re: new env defaults for doas

2019-06-16 Thread Ted Unangst
Martijn van Duren wrote: > > 2. When doing keepenv, nothing changes, except addition of above. > > It feels inconsistent to make keepenv behave different here. > - It may allow certain applications to behave unexpected compared to > without keepenv (e.g. scripts that use $HOME/.cache). > - The

Re: new env defaults for doas

2019-06-15 Thread Ted Unangst
Martijn van Duren wrote: > I'm not convinced that LOGIN_SETPATH is a good idea here. From what I > gathered that sets PATH from login.conf(5), while most environments I > know will use .profile to set it and could cause unexpected behaviour > if the my and targ PATH are reset to unexpected values.

new env defaults for doas

2019-06-12 Thread Ted Unangst
This has come up a few times before. For background, the default rule for doas is to copy a few environment settings from the user and omit the rest. This is to prevent confusion, and also supposedly for security. However, some of the alleged safe variables like PATH probably aren't that safe. And

Re: fsync(2) and I/O errors

2019-06-11 Thread Ted Unangst
Maximilian Lorlacks wrote: > This looks okay to me. > > (plus two months ping) oh, good news, committed two months ago. sorry, forgot to reply. > > ‐‐‐ Original Message ‐‐‐ > On Tuesday, April 16, 2019 8:19 PM, Ted Unangst wrote: > > > Oh, right, I reword

Re: use getpwuid_r in doas

2019-06-10 Thread Ted Unangst
Ted Unangst wrote: > I have a coming change which will need to access both the calling user and > target users' passwd entries. In order to accomplish this, we need to switch > to the reentrant flavor of getpwuid. No behaviorial change, but I think this > is clearer and less error p

use getpwuid_r in doas

2019-05-21 Thread Ted Unangst
I have a coming change which will need to access both the calling user and target users' passwd entries. In order to accomplish this, we need to switch to the reentrant flavor of getpwuid. No behaviorial change, but I think this is clearer and less error prone as well, versus reusing a pointer to

Re: snake: unveil + pledge earlier

2019-05-20 Thread Ted Unangst
Jake Champlin wrote: > - readscores(1); > penalty = loot = 0; > initscr(); > + if (unveil(scorepath, "rwc") == -1) > + err(1, "unveil"); > +#ifdef LOGGING > + if (unveil(logpath, "rwc") == -1) > + err(1, "unveil"); > + logfile = fopen(logpath,

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

  1   2   3   4   5   6   7   8   9   10   >