Re: LibreSSL 2.2.2 release

2015-08-11 Thread Theo de Raadt
I'm wondering out loud if these versions should follow the openbsd shlib major minor numbers. That is where we are careful about semantic versioning for api change/add/remove One note. If that is decided, on occasion libressl-portable could skip a release number. Probably fine for everyone.

Re: get rid of em_realign()

2015-08-13 Thread Theo de Raadt
Regarding other strict-alignment architectures, em(4) is probably one of the more popular gigabit ethernet options for those architectures that have PCI slots. I don't think any of these machines are severely memory starved, but memory might be limited to something like 256MB of physical

Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

2015-08-09 Thread Theo de Raadt
Awful lot of noise wherein people tell someone else what they should need to do with their time and their code. To the best of my knowledge, we've cited and/or thanked Maxime in the commits fixing the issues he's found, and we're glad to continue to receive his reports, whether or not

Re: Less strict requirement for USB_REQUEST ioctl

2015-08-10 Thread Theo de Raadt
ludovic coues schreef op 2015-08-10 23:29: 2015-08-10 22:56 GMT+02:00 Martin Pieuchot m...@openbsd.org: On 30/07/15(Thu) 12:18, Ludovic Coues wrote: Right now, an USB_REQUEST ioctl will fail with an EBADF error if done on a device opened as read-only. With this patch, the ioctl will fail

Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

2015-08-10 Thread Theo de Raadt
I am also of the opinion that if somebody/a method can discover bugs, they should report them. And if they can't, that method should be disclosed to allow others to continue their work. And my opinion is that Sam should back his opinions with lots of money.

Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

2015-08-10 Thread Theo de Raadt
It feels wasteful to develop a seemingly comprehensive and modular code scanner which will inherently find heaps of bugs, and then not release it or allow others to work with it. Sam, since you think throwing opinions out there is valuable Let me give me yours. I think you should talk

Re: Possible fix for i217 problem

2015-08-04 Thread Theo de Raadt
On 2015/08/04 22:40, Stefan Fritsch wrote: someone mentioned to me the i217-LM problems that were reported on misc end of May. It is possible that the patch below helps. This fixes my Dell poweredge T20: em0 at pci0 dev 25 function 0 Intel I217-LM rev 0x04: msi, address f8:b1:56:...

Re: softdep by default on AMD64

2015-07-23 Thread Theo de Raadt
There is no way this diff is going in. When softdep is 100% reliable, then we can talk. Enabling it prematurely is ridiculous. Considering the defects are clearly described as lockups, disk space corruption -- with such a suggestion I must ask --who's side are you on?? There was a great

Re: [patch] Remove archaic manual sizing from dump(8)

2015-07-26 Thread Theo de Raadt
On 2015-07-23, Michael McConville mmcco...@sccs.swarthmore.edu wrote: --- sbin/dump/main.c23 May 2015 05:17:20 - 1.56 +++ sbin/dump/main.c15 Jun 2015 23:16:10 - @@ -115,7 +115,7 @@ main(int argc, char *argv[]) usage(); obsolete(argc,

Re: OpenBSD::Tame perl wrapper for tame(2)

2015-07-21 Thread Theo de Raadt
This is extremely premature. The tame() in my devtree already has major incompatible changes.

Re: Patch to add -l flag to cat(1)

2015-07-22 Thread Theo de Raadt
So, what's the story with the -l option? What change/fix in OpenBSD base requires it? Nothing requires it explicitly, more the question of if having the ability for cat to set exclusive locks on its stdout so that multiple calls to the same cat command will cause the the output to be

Re: [patch] Disklabel message tweak

2015-07-17 Thread Theo de Raadt
This is another trivial patch, but I've always found the disklabel message No label changes confusing. For example, if you print (p), add a label (a), write (w), print to check your changes (p), and then quit (q), it seems odd to be told No label changes. Index: sbin/disklabel/editor.c

Re: Get Ruby 2.2 test suite passing

2015-07-17 Thread Theo de Raadt
Ted Unangst wrote: Jeremy Evans wrote: As an aside, crypt(passwd, $2) returns : instead of NULL. I'm not sure if that's a security issue, but I think it is and we should fix it. I'll see if I can get a patch for that and send it to tech@. This is a weird edge case where niels

Re: Get Ruby 2.2 test suite passing

2015-07-17 Thread Theo de Raadt
The only objection I can see is something stupid that does not check the error condition, derefs NULL, drops a core file in an insecure place, and therefore leaks information. To my mind this is a buggy program, combined with an insecure configuration, and we shouldn't be trying to save

Re: Get Ruby 2.2 test suite passing

2015-07-17 Thread Theo de Raadt
my perspective is: absent clear knowledge of what programs are doing, attempts to second guess them in a library function are perilous. let us be standards compliant, and then at least any resulting holes are clearly the program's fault. such programs always deference the pointer. So I agree

tame(2) WIP

2015-07-18 Thread Theo de Raadt
I have been working for a while on a subsystem to restrict programs into a reduced feature operating model. Other people have made such systems in the past, but I have never been happy with them. I don't think I am alone. Generally there are two models of operation. The first model requires a

Re: tame(1), like nice(1) but for permissions

2015-07-20 Thread Theo de Raadt
Sorry, should have made things clearer. I just meant that chroot was a bad comparison. I can't see any sane use of a tame(1) at the moment. No, no no, Ted's comments are completely valid. You cannot replace the narrow chroot calls in the privsep daemons with chroot(8) run externally. Any

Re: tame(1), like nice(1) but for permissions

2015-07-20 Thread Theo de Raadt
On Mon, Jul 20, 2015 at 12:04:43PM -0400, Ted Unangst wrote: chroot is probably the best comparision. yes, we provide a chroot(1), but There is no chroot(1). :p practically nothing uses it. everything is instead calling chroot(2) on its own. the things that do use chroot(1) are doing so

Re: doas failsafe

2015-07-21 Thread Theo de Raadt
Ability to define alias in the doas config file might be nice. Just like ssh with the ssh_config file. I have always wanted a .lsrc file, which would allow me to override the special options for ls, as well. That's kind of what you are talking about, right? No, I think you are serious. And

Re: doas failsafe

2015-07-21 Thread Theo de Raadt
Less code running with setuid root, the better. That is the entire point.

Re: change from vt220 to pccon0 for AMD/Intel consoles

2015-07-15 Thread Theo de Raadt
There are pccon* terminal descriptions for AMD/Intel PC consoles in /etc/termcap.I have been using them on various computers since 2011 without problems. I suggest to use pccon0 instead of vt220 by default for amd64 and i386because vt220 has not good support of navigation and function keys

Re: axphy(4): new dumb driver for axe(4) phys

2015-10-23 Thread Theo de Raadt
> First I added a custom reset function, but it turned out the problem was > elsewhere. So the current driver is just pretty printf'ing the model and > the phy. > > And you're right, it's not worth getting this in tree so forget about > this diff. correct. ukphy is named a bit strangely.

Re: does anoybody use ul?

2015-10-23 Thread Theo de Raadt
> > From: "Ted Unangst" > > Date: Fri, 23 Oct 2015 03:47:56 -0400 > > > > ul appears somewhat useless for its intended purpose. > > > > echo _xxx_ | ul does not result in underlined text in an xterm, so I doubt > > many people are using this. > > > > Unlike, say, mandoc,

Re: documenting multiple standards

2015-10-25 Thread Theo de Raadt
>>From wcrtomb(3): > > The wcrtomb() function conforms to ISO/IEC 9899/AMD1:1995 (``ISO C90, > Amendment 1''). The restrict qualifier is added at ISO/IEC 9899/1999 > (``ISO C99''). > >This wording is confusing. Is it implying that we don't use a restrict >qualifier? (We do.) > >If a

rip6query(8)

2015-10-26 Thread Theo de Raadt
does anyone use rip6query? we don't have a ripquery I cannot imagine the use for this too. Either you are using rip6 protocol, or you aren't. Does this perhaps still exist because route6d isn't like our other daemons with a "fib-update" mode?

Re: utf8 hack for ls

2015-10-26 Thread Theo de Raadt
> Damien Miller wrote: > > rather than scattering hacks in each program that needs to > > output utf8 to the console, how about making something > > for libutil that they all can use? > > Yes, that is certainly the plan, but I think it's easier to see what's needed > if we convert a few programs

Re: sed: better error message

2015-10-26 Thread Theo de Raadt
> Jérémie Courrèges-Anglas wrote: > > Michael McConville writes: > > > It looks like it can be pretty easily replaced with calls to err(3), > > > errx(3), warn(3), warnx(3), etc. > > > > Not sure about this, you'd have to repeat the same code over and over to > > print the

Re: boot from softraid, backspace in passphrase prompt

2015-10-28 Thread Theo de Raadt
Since people are typing blind, can you add support for ^U as well? > I want correct typing mistakes when booting from softraid crypto disks. > Can we handle at least the backspace key, plz^Hease? :) > > diff --git sys/arch/amd64/stand/libsa/softraid.c > sys/arch/amd64/stand/libsa/softraid.c >

Re: pledge(2) and spamd(8)

2015-10-28 Thread Theo de Raadt
> I was just trying to pledge(2) spamd(8), nevertheless came across 2 > priviliges kern_pledge.c is missing for this to work. > > First spamd(8) needs to read sysctl kern.maxfiles in order to see if it > can launch with that value or not, and second if the multicast options > are passed as

Re: pledge(2) and spamd(8)

2015-10-28 Thread Theo de Raadt
> Also, I wonder what the point of having a sanity check against > kern.maxfiles at all is, especially with the arbitrary-feeling > additional rule of "maxcon may not exceed kern.maxfiles - 200". It feels > redundant to me, and it sort of makes a promise of protection it can't > uphold. That code

Re: pair(4) (was: connect routing domains on layer 2)

2015-10-26 Thread Theo de Raadt
> On 10/24/15 06:46, Reyk Floeter wrote: > > vether doesn't help as it is not transmitting any traffic. > > in other words, "vether is a bridge endpoint" "pair is a bridge link" > This may be a dead topic, but doesn't bridge_output() transmit for > vether(4)? > Or am I missing the point entirely?

Re: __predict_false for pledge

2015-10-26 Thread Theo de Raadt
> On Mon, Oct 26, 2015 at 8:46 AM, Michael McConville wrote: > > We have a pretty strong guarantee that it can only happen once per > > process... > ... > > --- sys/sys/syscall_mi.h9 Oct 2015 01:17:18 - 1.11 > > +++ sys/sys/syscall_mi.h26 Oct 2015

Re: __predict_false for pledge

2015-10-26 Thread Theo de Raadt
> Not sure how people feel about these annotations. This is a pretty > classic use case, though. No, the classic case is when the condition is a single variable, rather than a condition "always true && rarely true".

Re: move cron socket to /var/run/cron.sock (pledge)

2015-11-11 Thread Theo de Raadt
> Grmbl. I've hard a hard time trying to understand *why* this would be > needed. The answer is pledge(2), who makes chmod(2) fail with EPERM > instead of killing the process. > > I find this confusing. IMO pledge(2) should let the kernel do the > appropriate security checks for chown(2).

Re: chmod(1) -f flag is still used?

2015-11-12 Thread Theo de Raadt
Your process here is really strange. You see something, then you write a diff before answering your own question, then you send a mail asking a question with the diff already present as an investment. In OpenBSD, we have a 20 year old repository that explains why a change was made. Before the

pledge telnet

2015-11-13 Thread Theo de Raadt
I really want to delete telnet entirely, but there are still occasions when someone might want to use it on an intranet. Other telnet tools are probably worse shape. This adds two pledge calls. The subshell and skey support are removed (you can use ^Z), and you cannot start a new telnet

Re: pledge telnet

2015-11-13 Thread Theo de Raadt
> > I really want to delete telnet entirely, > > I often use it for testing unencrypted SMTP and HTTP across the > Internet. Which tool would you recommend for that purpose? nc(1). > You might wish to cross-check these three points though: > > * Does "inet" actually allow the following

Re: pledge("stdio") for arch(1)/machine(1)

2015-11-13 Thread Theo de Raadt
> This straightforward pledge("stdio") is one of the last uncommitted ones > from Theo's big 'tame in userland' diff and seems to have been > overlooked so far. I think arch.c gains no value from being pledged. It adds a system call to a program which makes no user-input decisions.

Re: pledge telnet

2015-11-13 Thread Theo de Raadt
> > > > I really want to delete telnet entirely, > > > > > > I often use it for testing unencrypted SMTP and HTTP across the > > > Internet. Which tool would you recommend for that purpose? > > > > nc(1). > > I use telnet fairly often for connecting to things like crappy switches, > crappy

Re: pledge telnet

2015-11-13 Thread Theo de Raadt
> > On 2015/11/13 09:59, Theo de Raadt wrote: > > > > > I really want to delete telnet entirely, > > > > > > > > I often use it for testing unencrypted SMTP and HTTP across the > > > > Internet. Which tool would you recommend for that

Re: pledge telnet

2015-11-13 Thread Theo de Raadt
> It is similar to (optional) XMODEM/ZMODEM disciplines over serial, IMO. No, it is similar to over the INTERNET, because the INTERNET is nothing at all like a serial line, the later generally being nicely contained to a single room. > The goal is to delete classic telnet entirely and make it

Re: pledge telnet

2015-11-13 Thread Theo de Raadt
> Can telnet be extended to coexist with nc -F? Manual only mentions ssh. Please don't email while driving your horse buggy.

Re: give cron a sensible default max load_avg for batch jobs

2015-11-13 Thread Theo de Raadt
> This patch changes the default setting to 1.5 * > (number_of_cpus_in_system) instead, which I find better matches modern > behaviour. A larger number is sensible in this position. I would propose 8. I don't agree with a calculation like that; the amount of work a system can do should not be

Re: pledge route(8) with '-n' flag

2015-11-16 Thread Theo de Raadt
> On 16/11/15(Mon) 10:03, Ricardo Mestre wrote: > > Hello! > > > > Like Benoit said, monitor still needs dns all the time, but since pledge > > was being called there again with dns pledge then I thought it wouldn't > > abort. Taking that into consideration and looking at it a little bit > >

Re: Reducing compilation warnings in imsg.c on FreeSBD

2015-11-16 Thread Theo de Raadt
> Both OSs define getdtablesize() as sysconf(_SC_OPEN_MAX). sysconf(3) > returns a long, so it seems more correct to make getdtablesize(3) return > a long or ssize_t. The return value has to be signed because sysconf(3) > is specified by POSIX to return -1 and set errno on failure. Don't be

Re: Reducing compilation warnings in imsg.c on FreeSBD

2015-11-16 Thread Theo de Raadt
> > Both OSs define getdtablesize() as sysconf(_SC_OPEN_MAX). sysconf(3) > > returns a long, so it seems more correct to make getdtablesize(3) return > > a long or ssize_t. The return value has to be signed because sysconf(3) > > is specified by POSIX to return -1 and set errno on failure. > >

Re: pledge mv(1)

2015-11-16 Thread Theo de Raadt
> If only rename(2)'ing then it only needs "stdio rpath cpath", > nevertheless if we need to copy to a different partition it also needs > "wpath fattr" for writing and chmod/chown operations, and finally "proc > exec" are needed due to (extracted directly from mv(1)'s man page) -> > "Should the

Re: Better ASR support in ospfd

2015-11-15 Thread Theo de Raadt
> On Mon, Oct 26, 2015 at 04:40:12PM +0100, Claudio Jeker wrote: > > ospfd has some issues with self-originated networks and building summary > > entries for those in case the router is an ABR (area border router). > > This diff should hopefully fix all of the troubles. It changes a bit the > >

Re: move cron socket to /var/run/cron.sock

2015-11-11 Thread Theo de Raadt
> There's limited backward compatibility so you can run a new crontab > with an older cron daemon. Why? That makes no sense. This kind of compat bubbles up. It should be deleted within a week, so why bother writing it...

Re: pledge audioctl

2015-11-17 Thread Theo de Raadt
> I am trying to add pledge(2) to audioctl(1), > but it gets SIGABRT'ed under any pledge promises. > (Indeed, I have pledged everything in a desperate attempt.) > > Looking at gdb and a ktrace, /dev/audioctl gets opened fine, > but then it fails on an ioctl in getinfo() > > 23472 audioctl CALL

Re: printf(3) wording

2015-11-17 Thread Theo de Raadt
> > > > i don;t know how these implementations work, so it's hard to say. > > > > perhaps they are interpolated. maybe use cvs to track down the author > > > > and ask them? > > > > > > > > whatever the outcome, if you want to change this text you probably want > > > > to adjust a few more: > > >

Re: [PATCH] rcs: buf_free/rcsnum_free

2015-11-01 Thread Theo de Raadt
> > I think it should be moved into Attic. It's not like we've been nice to > > the pcc tree-import either after it lacked attention. > > I agree, it has been unlinked from the build for more than 5 years. I don't agree. I still have some hope. Yes, it has problems. But go look at the code in

Re: Tweaks to malloc(3) manpage

2015-11-01 Thread Theo de Raadt
> 1. I don't see much reason to mention calloc() as an alternative to > reallocarray() when it's the worse option. calloc() still remains the portable option. Something should probably still be mentioned here, otherwise people fall back to unchecked malloc -- no matter what is stated further

Re: Drop register keyword from less(1)

2015-11-01 Thread Theo de Raadt
less is code imported on a regular basis from upstream. Look at the commit log. > Every one of these is in a var declaration, so a megadiff is probably > the easiest way to do it. > > ok? > > > Index: brac.c > === > RCS file:

Re: tcpdump: stop building SLIP support

2015-11-04 Thread Theo de Raadt
Why? We don't have decnet code either, yet it is nice to sniff it if you see it. > Some time ago mpi removed the sl(4) driver, IIUC this makes a bunch of > code useless in tcpdump. > > The diff below only removes the define. If people prefer, I could also > kill some noise by removing the

Re: chgrp(1) & chown(8): mark -h and -R as mutually exclusive

2015-11-05 Thread Theo de Raadt
I don't think it makes it clearer; it makes it more confusing. The usage messages of programs are not a sufficent grammer to exactly describe what conflicts with what. Taken too far, it would bewilder newcomers. > the command line arguments -h and -R for chgrp and chown are mutually >

Re: save less

2015-11-06 Thread Theo de Raadt
>On Sat, Nov 07, 2015 at 12:12:55AM -0500, Michael McConville wrote: >> Ted Unangst wrote: >> > less has a peculiar estrdup function. unlike ecalloc etc., it only >> > prints an error but doesn't quit. But the callers don't seem to check >> > for null. And in many places they call a function

Re: Drop register keyword from less(1)

2015-11-02 Thread Theo de Raadt
> I think we should move to the Illumos fork, it looks good. I've got it > building easily enough, will take a look at porting our changes at some > point. I was the first one to bring it up with Todd about 4 weeks ago. I am a big fan of this, becuase it will allow us to pledge^Wrefactor it

Re: cvs(1) simplification

2015-11-02 Thread Theo de Raadt
> I can tell that rev can be VERY large... Wait, am I remembering these > (Open)CVS internals all of a sudden again? :P Some of us have memories wired for guilt.

Re: fix ksh histfile owner

2015-10-08 Thread Theo de Raadt
> ksh does a little dance to try and gift history files to their original owner > if it's somehow running as a different user. this of course only works as > root, and is probably a terrible idea. When I found this with tame, I got worried about the implications of how ksh is opening the file in

Re: reference syscall.h in pledge.2

2015-10-21 Thread Theo de Raadt
>Does it make sense to reference the syscall numbers in pledge(2)? No not really. By 5.9 release the kernel printf's will go away, and people won't get such alerts. Maybe they will get kernel log's, but I will consider generating them with system call names.

Re: compress: tighter pledge

2015-10-16 Thread Theo de Raadt
> Here's an attempt to tighten compress/gzip's pledge: > > Due to the use of fts(3), we always require rpath, even for > gzip out. > > We only write to stdio and never to any files... > * if we are in cat mode (-c, zcat) > * if we are in test mode (-t) > * if there are no file arguments and

Re: pledge csh nice = death

2015-10-19 Thread Theo de Raadt
> It looks like csh would currently need to pledge("id") in order for the > builtin nice to work --- setpriority() is called in three places > depending on how nice is invoked. However, adding "id" to a shell > seems a bit scary. > > Would it be preferable to mark > [SYS_setpriority] =

Re: pledge(2) and exec

2015-10-10 Thread Theo de Raadt
> I am however curious to this patch. By pledging ksh with exec it appears > to me that once a pledged process is execve(2)d it looses it's already > made pledges. Yes, because that is what it needs. > This to me seems like > something that might be undesirable (find remote code

Re: ftp: ctype interfaces need unsigned chars

2015-10-10 Thread Theo de Raadt
> Some isfoo(char) usages crept back into ftp Hmm. I wonder how we can keep these errors out of base. Having to re-audit all the time is painful.

Re: npppd: simplify and lock down priv_open()

2015-10-10 Thread Theo de Raadt
> Currently, npppd's PRIVSEP_OPEN message (abstracted as priv_open()) > accepts arbitrary open() flags and passes a mode argument. That > seems...unwise. > > In particular, it never passes O_CREAT, so the mode argument isn't needed. > Indeed, the only open 'flags' it needs are O_RDONLY and

Re: kdump perjury: syscall 5

2015-10-10 Thread Theo de Raadt
> Index: sys/kern/kern_pledge.c > === > RCS file: /var/cvs/src/sys/kern/kern_pledge.c,v > retrieving revision 1.4 > diff -u -p -r1.4 kern_pledge.c > --- sys/kern/kern_pledge.c9 Oct 2015 05:30:03 - 1.4 > +++

Re: ftp: ctype interfaces need unsigned chars

2015-10-10 Thread Theo de Raadt
> as well as this: > > > --- tcpdump/print-ipsec.c > > +++ /tmp/cocci-output-17550-499a71-print-ipsec.c > > @@ -101,7 +101,7 @@ esp_init (char *espspec) > > s[0] = espkey[2*i]; > > s[1] = espkey[2*i + 1]; > > s[2] = 0; > > - if (!isxdigit(s[0]) ||

Re: prefer dprintf() over snprintf()+write()

2015-10-12 Thread Theo de Raadt
> Actually, plain old printf should be OK in ping.c since buffering > is disabled for ping -f. If you want to keep dprintf(), I think > we can lose the setbuf() call. Whatever you decide, it would > be nice to make ping6.c match. No, disagree strongly. ping is doing this inside a signal

Re: Permitting the override of MACHINE_ARCH in amd64/param.h

2015-10-12 Thread Theo de Raadt
> I was wondering if it would be possible to allow the override the > definition of MACHINE_ARCH /__MACHINE_ARCH in amd64/param.h by wrapping > them around ifndef statement. > > Index: sys/arch/amd64/include/param.h > === > RCS file:

Re: prefer dprintf() over snprintf()+write()

2015-10-12 Thread Theo de Raadt
> Ah, I didn't realize that pinger() was still called via a signal > handler in ping. It looks like ping6 is better in this regard. ping and ping6 need to be merged, as happened to traceroute. First step: make all ping6's options match ping options. Rename ping6 options with wild abandon if

Re: ttyname

2015-10-12 Thread Theo de Raadt
> When guenther@ switched isatty(3) to F_ISATTY, he forgot ttyname(3). That was a change I made. > With this, simple callers of ttyname(3) like tty(1) and who(1) no > longer need pledge("tty"). That is correct, these programs could do without the ability to set modes on the tty. I think this

Re: Char cleanup in lex(1)

2015-10-12 Thread Theo de Raadt
Our tree uses lex pretty much as-is from upstream, so this refactoring isn't the way to go. If you find an actual bug however.. fix them, using the established practice. > When scanning for is*() function uses with signed chars, I found that > lex(1) uses an unecessary #define for unsigned char.

Re: tame userland diff

2015-10-05 Thread Theo de Raadt
> Assume you have a bad program1 and you write your tame(2)-ed program2 that > disallows execution of program1. But you also have to use my un-tame(2)-ed > program3 that allows execution of program1. How does your tame(2)-ed > program2 protect you now against executing program1 ? You still risk

Re: tame userland diff

2015-10-05 Thread Theo de Raadt
> The problem of exec(2) is if we permit it (without herited tame flags) > your program has a way to go out his expected behaviour. For example, if > a tamed program has a bug that permit execution of code, the attacker > would just has to do "exec(something-else)" to escape the imposed > policy.

pledge in -current

2015-10-12 Thread Theo de Raadt
Many will have observed that pledge(2) usage is being pushed into the source tree at a very rapid pace. I'd like if everyone looks in their dmesg logs for pledge errors. But please don't immediately mail a report! Instead, look for if someone else reports an error in the same command. If noone

Re: Microsoft Now OpenBSD Foundation Gold Contributor

2015-07-09 Thread Theo de Raadt
Kenneth R Westerback, 08 Jul 2015 10:13: The OpenBSD Foundation is happy to announce that Microsoft has made a significant financial donation to the Foundation. This donation is in recognition of the role of the Foundation in supporting the OpenSSH project. This donation makes Microsoft

Re: Microsoft Now OpenBSD Foundation Gold Contributor

2015-07-11 Thread Theo de Raadt
it flatters me somewhat that you read so much into my simple astonishment about a news item that does in most geek circles provoke the response no way, hell froze over. I quote from your original mail: this is very impressive news, although for me for all the wrong reasons. Have all

Re: tcpdump -A: really printable characters

2015-07-11 Thread Theo de Raadt
Index: tcpdump.c === RCS file: /cvs/src/usr.sbin/tcpdump/tcpdump.c,v retrieving revision 1.70 diff -u -p -r1.70 tcpdump.c --- tcpdump.c 18 Apr 2015 18:28:38 - 1.70 +++ tcpdump.c 11 Jul 2015 20:35:11

tcpdump: make BIOCGSTATS a priv operation

2015-07-11 Thread Theo de Raadt
This moves the BIOCGSTATS ioctl operation done by the tcpdump process (at ^C time, but not at -c count expiration) into a service provided by the privsep monitor. Had a bit of help from canacar, who wrote the original privsep code with otto. Will be needed for tame. Index: privsep.c

Re: sndiod_flags=NO in /etc/rc.conf on recent snapshots

2015-11-17 Thread Theo de Raadt
> I only just noticed that, trying to watch a video while having a web > browser open at the same time, I don't get any sound. > > Only going through recent daily insecurity emails, had I found out that: > > sndiod_flags= > > in /etc/rc.conf, has been changed to: > > sndiod_flags=NO >

Re: Pledge shutdown halt

2015-11-17 Thread Theo de Raadt
> > Anybody see this on shutdown?=C2=A0 > > shutdown -hp now > > *** FINAL System shutdown message from i...@ianm-openbsd.xxx.edu.au > > System going down IMMEDIATELY=C2=A0 > > System shutdown time has arrived=20 > > halt: revoke: Inappropriate ioctl for device I

Re: MALLOC_STATS and pledge

2015-11-14 Thread Theo de Raadt
> On 2015/11/14 14:01, David CARLIER wrote: > > Might be indeed, there are other use cases with valgrind and protexec > > and so on ..., utrace might be a good suggestion too except maybe a > > need for an exception in pledge's side then. > > btw, valgrind currently ssems to be quite broken with

Re: increase initialization time for serverworks sata

2015-11-14 Thread Theo de Raadt
> Don't tell me this fixes SATA on the xserve G5... I did try that back in the day. I cranked all the delays, and nothing helped. No interrupts came in, ever.

Re: MALLOC_STATS and pledge

2015-11-13 Thread Theo de Raadt
> I ve tried to discuss this point with Otto Moerbeek but he might be > very busy so I throw the topic here if you do not mind ... > > I have the habit to enable MALLOC_STATS but with the recent pledge > feature, it s now difficult to debug some pledged applications with > MALLOC_OPTIONS=D as,

Re: MALLOC_STATS and pledge

2015-11-13 Thread Theo de Raadt
> An idea would be to open the fd at init time, which should be early > enough for most cases (i.e. before the first pledge(2) call). Big > drawback is the open fd all the time until program exits. Keeping a fd open through libc runtime is not going to fly. It isn't just the fragility of it.

Re: [PATCH] doas authentication type

2015-08-27 Thread Theo de Raadt
security model. How many users of that functionality will there be? We only need to concern ourselves with the cost; you have to justify the benefit. How many people were doing this with sudo, and how many will need this with doas? While I understand it's a good idea to limit

Re: [PATCH] doas authentication type

2015-08-27 Thread Theo de Raadt
Sorry, I think adding an option is too much. I just committed halex's o= riginal diff to only change the type. I thought he was going to do that by now.= Hi Ted, The thing is, my patch doesn't do the same thing at all as the one which adds auth-doas. My patch lets the user choose

Re: syslogd optarg

2015-08-27 Thread Theo de Raadt
On Thu, Aug 27, 2015 at 10:13:25AM -0600, Theo de Raadt wrote: Why not strdup? And now with strdup() as suggested by Theo. ok, because such style is not really a leak. Index: usr.sbin/syslogd/syslogd.c === RCS file: /data

Re: [PATCH] doas authentication type

2015-08-27 Thread Theo de Raadt
How many users of that functionality will there be? We only need to concern ourselves with the cost; you have to justify the benefit. How many people were doing this with sudo, and how many will need this with doas? My current model is to use my yubikey when sudo'ing. Occasionally

Using tame() in userland

2015-08-27 Thread Theo de Raadt
This is for those of you interested in tame, and skilled enough to play along. This is a set of almost 100 diffs to programs in the tree to use tame. These have been done by myself, doug, florian, semarie, and a few other people I forget. I would make a rough guess these changes took about 100

Re: pool allocator names

2015-08-29 Thread Theo de Raadt
* pool_allocator_multi_ni: A multi page allocator that is *not* safe for use in interrupts. Also less efficient than pool_allocator_single. It allocates kva from kernel_map, which is significantly more plentyful. We are the knights who say non-interruptable. Honestly, ni feels a

Re: [patch] cat's main never return

2015-08-29 Thread Theo de Raadt
just saw that cat's *main* function does never return even though there is a return value, exit(3) is called instead. Is there any reason why or is it just historically, cause it's a bit confusing? If exit(3) is always called, than why not changing the return value to *void*? Other

Re: [patch] return instead of exit(3) in src/bin/

2015-08-30 Thread Theo de Raadt
As suggested by deraadt@ and tobias@ it might be better to use the *return* statement instead of exit(3) inside the *main* function, to let the stack protector do its work. This diff removes such calls in all *src/bin/* tools, except those who already use it. I think I didn't miss a call

Re: ksh sanatizing argv redundant

2015-08-31 Thread Theo de Raadt
> Martijn van Duren wrote: > > Hello tech@, > > > > I took a quick glance at ksh and one of the first things I noticed was > > that it uses some sanatizing code on argv. When looking at execve(2) I > > see that EINVAL or EFAULT are returned when argv isn't properly > > formatted. I've also

Re: sendsyslog error log

2015-09-01 Thread Theo de Raadt
Seems good to me. I wouldn't bother with disabling this in SMALL_KERNEL. Space is not short enough to complicate the code for ~200 bytes. > To make syslog reliable, I want to see log messages about failed > log atempts. sendsyslog(2) seems a good place to detect and report > the problem. > >

Re: nfs pool diff

2015-09-03 Thread Theo de Raadt
>The only pool_get() call uses PR_WAITOK, and the pool_put() calls are >only done from the nfsd main loop, so process context. OK. Thanks that explains how one makes sure.. >No I'm not an NFS hacker! 3 kettenis Actually lots of people are NFS hackers. 1 aaron 1 damien 1 dlg 1

Re: sqlite 3.8.11.1

2015-09-09 Thread Theo de Raadt
> > Not attaching the diff because of the size, available at > > http://rhaalovely.net/~landry/stuff/sqlite-3.8.11.1.diff.gz > > And i forgot to mention that it went in an amd64 bulk build without > fallout, thanks to ajacoutot@ So, one architecture has been tested. Now there is a request for

Re: sqlite 3.8.11.1

2015-09-09 Thread Theo de Raadt
This is a really stupid way to treat the base source tree. > thanks to the hard work of jturner@, here's a 650kb gzipped update to > sqlite 3.8.11.1, bumping shlib to 31.0. This is needed for upcoming > firefox 41 update, but anyone is welcome to look into the update itself. > > Not attaching

Re: Remove useless NULL casts from mv(1)

2015-09-14 Thread Theo de Raadt
>Michael McConville wrote: >> Index: mv.c >> === >> RCS file: /cvs/src/bin/mv/mv.c,v >> retrieving revision 1.40 >> diff -u -p -r1.40 mv.c >> --- mv.c 24 Aug 2015 00:10:59 - 1.40 >> +++ mv.c 14 Sep 2015 13:38:13 -

<    2   3   4   5   6   7   8   9   10   11   >