On 2022-06-02, Theo de Raadt wrote:
But please consider this impact of the change you propose.
>
> There is one additional flag, VIS_NOSLASH, which inhibits the doubling of
> backslashes and the backslash before the default format (that is, control
> characters are represented by
Err.
Index: extern.h
===
RCS file: /home/cvs/src/bin/pax/extern.h,v
retrieving revision 1.60
diff -u -p -r1.60 extern.h
--- extern.h23 Mar 2020 20:04:19 - 1.60
+++ extern.h27 May 2022 00:30:36 -
@@ -284,7 +284,7
On 2022-05-26, Todd C. Miller wrote:
> Our tar's -O flag is only used when creating an archive, it is
> unused for extraction. I'd prefer that we use the same option
> letter as GNU tar and bsdtar for this.
That would look something like this.
tar can read and write archive files from stdin/out, but cannot extract files
to stdout. This may be kinda esoteric, but there's a few uses. Archive of log
files, etc., where you want to check for something without extracting to a
tmp file.
I tried working around this by renaming to /dev/fd/1,
On 2022-05-15, Mark Kettenis wrote:
> > From: "Ted Unangst"
> > Date: Sat, 14 May 2022 20:23:39 -0400
> >
> > The cpu hz sensor is more accurate and updates faster than than the value
> > currently used for hw.cpuspeed. So return that value (scaled).
>
The cpu hz sensor is more accurate and updates faster than than the value
currently used for hw.cpuspeed. So return that value (scaled).
This doesn't set cpuspeed directly because the acpi does that and it's hard
to create a whole system of priority overrides. I think it's simpler and
maybe even
On 2022-05-03, Moritz Buhl wrote:
> Hi tech@,
>
> Syzkaller found a few crashes in pf_anchor_global_RB_REMOVE.
> https://syzkaller.appspot.com/bug?id=a97f712331903ce38b8c084a489818b9bb5c6fcb
> and also
> https://syzkaller.appspot.com/text?tag=CrashLog=15ace9aaf0
>
> The call stack is
I don't think we need to concern ourselves with cross awk compatibility here.
Despite the misleading comment, /usr/bin/awk supports toupper.
Index: makesyscalls.sh
===
RCS file: /home/cvs/src/sys/kern/makesyscalls.sh,v
retrieving
On 2022-04-30, Visa Hankala wrote:
> I am in two minds about EVFILT_USER. On the one hand, having it on
> OpenBSD might help with ports. On the other hand, it makes the kernel
> perform a task that userspace can already handle using existing
> interfaces.
I agree you could do this with just a
On 2022-04-30, Alexander Bluhm wrote:
> Hi,
>
> Can we install the btrace scripts to /usr/share/btrace/ ? The
> directory already exists, only the Makefile is not linked to the
> build.
>
> And I would like to use #! to make them executable.
It's weird to have exec files in share?
I think
btrace needs a little more help printing very large numbers. If you have
something
like 2^61 in your histogram, it gets printed as 1K because that's what's left
over
after dividing by G and M. Add some more units, and it prints as 1E.
(It seems like there might be another bug, because I'm not
On 2022-03-17, Alexander Bluhm wrote:
> On Thu, Mar 17, 2022 at 01:07:12AM +0100, Mark Kettenis wrote:
> > > Date: Thu, 17 Mar 2022 01:01:46 +0100 (CET)
> > > From: Mark Kettenis
> > >
> > > > Date: Thu, 17 Mar 2022 00:47:15 +0100
> > > > From: Alexander Bluhm
> > > >
> > > > Hi,
> > > >
> >
On 2022-03-03, Theo Buehler wrote:
> This is missing in setusercontext(3).
Of course.
>
> Index: gen/login_cap.3
> ===
> RCS file: /cvs/src/lib/libc/gen/login_cap.3,v
> retrieving revision 1.18
> diff -u -p -r1.18 login_cap.3
> ---
On 2022-02-26, Dave Voutila wrote:
> Following the discusion on misc@ and a diff from tedu@ [1], here's a bit
> more work cleaning up the issue in vmd(8) to prevent vmd dying if a user
> tries to create a vm with memory above the rlimit.
>
> I changed tedu's diff a bit to make it less verbose and
On 2022-02-06, Ted Unangst wrote:
> On 2022-02-05, Matthew Martin wrote:
> > On Sat, Jan 29, 2022 at 06:25:32PM -0600, Matthew Martin wrote:
> > > On Sat, Jan 29, 2022 at 07:10:00PM -0500, Ted Unangst wrote:
> > > > I believe it would be better to add setrtab
On 2022-02-05, Matthew Martin wrote:
> On Sat, Jan 29, 2022 at 06:25:32PM -0600, Matthew Martin wrote:
> > On Sat, Jan 29, 2022 at 07:10:00PM -0500, Ted Unangst wrote:
> > > I believe it would be better to add setrtable to id pledge.
>
> ping
>
> Also ar
A go program that uses pledge("dns") mostly works except for two
incompatibilities with the way golang's dns library works. Otherwise
pledge("rpath") is required.
1. go likes to stat /etc/hosts to check for changes. I think this is
reasonable behavior. Patch below adds a whitelist to the kernel
I believe it would be better to add setrtable to id pledge.
On 2022-01-29, Matthew Martin wrote:
> It would be nice to have the ability to set a user's rtable upon login.
> This would be useful both for road warrior VPN setups (put both the VPN
> interface and user in an rdomain other than 0) and
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
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
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
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
>
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. :)
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"
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
===
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
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
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
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
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
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.
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
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
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
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.
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
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
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
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
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
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
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.
> &
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 -
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
---
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.
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
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:
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
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
>
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,
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
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:
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
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,
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.)
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
> >
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
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;
> +
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
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?
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
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
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
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,
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
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
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
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
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
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
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':
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
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
Klemens Nanni wrote:
> Initialize stack variables directly instead of using global state in
> between.
>
> OK?
sure
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:
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
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
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
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
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
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
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.
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
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
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
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
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,
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
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.
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
f. holop wrote:
> dmesg:
>
> ...
> acpibtn2 at acpi0: PWRB
> tpm0 at acpi0: TPM_ addr 0xfed4/0x5000acpivideo0 at acpi0: GFX0
> acpivout0 at acpivideo0: DD1F
> ...
thanks
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
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?
> >
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
>
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
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
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.
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
>
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"
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)
1 - 100 of 1656 matches
Mail list logo
