Re: vlan tagging surgery

2014-04-21 Thread Theo de Raadt
Henning Brauer lists-openbsdtech at bsws.de writes: And lot of (possible) encapsulation subsystems in the middle: vlan, vlan-in-vlan, ipsec, you name it. VLAN IS NOT AN ENCAPSULATION. Well, vlan(4) says: vlan, svlan - IEEE 802.1Q/1AD encapsulation/decapsulation pseudo-device

Re: more axeing at openssl

2014-04-22 Thread Theo de Raadt
This replaces RAND_{,pseudo_}bytes() calls with equivelant arc4random_buf(3) calls for apps/ and ssl/ (crypto/ still has a bunch). Actually last time this was discussed, the idea was to leave this as-is for now. Then we can decide if the stronger of the two should remain a seperate name.

Re: [patch ping.c] replace malloc memset with calloc

2014-04-22 Thread Theo de Raadt
You are now clearing only the first time. malloc memset can be replaced with calloc in ping.c. Please see below for patch details: Index: ping.c === RCS file: /cvs/src/sbin/ping/ping.c,v retrieving revision 1.100 diff -u

Re: LibreSSL OPENSSL_malloc... removal

2014-04-22 Thread Theo de Raadt
The removal of OPENSSL_malloc/OPENSSL_free ... etc will cause a LOT of pain Which is why they are not removed. There is non négligeable number of applications which are strongly depending on this functionality, they use it for example to allocate SSL data structures in memory shared

Re: pckbd volume keys (part 2): knob to pass keystrokes

2014-04-29 Thread Theo de Raadt
this diff applies on top of the previous one; it adds the hw.kbdvolume sysctl(1) entry to select how pckbd ukbd volume keys are handled: hw.kbdvolume=0 pass keystrokes to upper layer as we do for regular keys, thus usable by X apps as hot-keys or whatever. hw.kbdvolume=1

Re: patch: use a lookup table in BIO_get_port()

2014-04-29 Thread Theo de Raadt
Don't bother with diffs to b_sock.c. Instead, if you have code which uses it, talk to krw. There is a monster diff coming which rewrites it all. And by the way, all that code disapears and is replaced by 2 lines. Not sure this is sensible as it encourages people to simply update the table.

Re: IPv6 by default

2014-04-29 Thread Theo de Raadt
I know that what I proposed cannot go in at the moment. It's my end goal. The goal is ridiculous. If anything, it should be sorted by the best addresses first. Today the best addresses are IPv4. There is no dynamic method to determine best, but measurements all over the world show that IPv4

Re: Switch getopt example to getprogname()

2014-04-29 Thread Theo de Raadt
Date: Tue, 29 Apr 2014 11:31:48 +0200 From: Tristan Le Guern tlegu...@bouledef.eu Hi, This patch for /usr/share/misc/getopt enforces the use of getprogname() instead of __progname. Is this desirable? If so I also have a patch for style(9). getprogname(3) isn't really more

Re: IPv6 by default

2014-04-29 Thread Theo de Raadt
Someone has to take the first/next step, and that's a very traditional role for OpenBSD. Apply these kinds of changes to your entire production network, and report back in 6 months if you are still running them.

Re: IPv6 by default

2014-04-29 Thread Theo de Raadt
However, based on available evidence, IPv4 is not better than IPv6 in every respect for everyone. You've written a long mail and completely missed the point. This is not a conversation about your IPv6 connection. It is about what the sensible default should be for everyone.

Re: data modified on freelist, tmpfs-related?

2014-04-30 Thread Theo de Raadt
On Wed, Apr 30, 2014 at 03:38:39PM +0200, Mark Kettenis wrote: Date: Wed, 30 Apr 2014 13:39:20 +0100 From: Stuart Henderson st...@openbsd.org Seen when running e2fsprogs regression tests with /tmp on tmpfs I'm not surprised; tmpfs contains some serious bugs. I recommend not

Re: Questions about LibreSSL

2014-04-30 Thread Theo de Raadt
I have been following the recent LibreSSL developments quite active and would like to contribute. I have some questions: - The accelerated assembly code for the crypto, is that gonna stay? Of course. Why do you think anyone would try to break code which works? - Why not use uint32_t

Re: malloc freelists

2014-05-01 Thread Theo de Raadt
Sorry, badly phrased reply. I didn't mean to imply it was a bad idea, but you didn't explain at all why 4, and not 3 or 6, or 42 ? If it's good with 4, it ought to be better with more, right ? any data point or rationale for choosing 4 ? Why does Ted have to explain his heuristic? Should

Re: not quite another erratum

2014-05-05 Thread Theo de Raadt
The process which came to the conclusion below took about 15-20 hours of accumulated developer time over the weekend. I'm almost running out of fingers counting developers. I wish we had the resources so that we could dedicate people to this in a more serious way. At least if we could dedicate

Re: [patch] libssl/src/ssl/ssl_rsa.c

2014-05-08 Thread Theo de Raadt
Your diff does not solve a problem. In case this is considered important enough... Remove unused ret from SSL_use_PrivateKey(). - Michael Index: ssl_rsa.c === RCS file: /cvs/src/lib/libssl/src/ssl/ssl_rsa.c,v retrieving

Re: NOINET6 by default

2014-05-22 Thread Theo de Raadt
* Mark Kettenis mark.kette...@xs4all.nl [2014-05-15 00:15]: I don't think this is a good idea; didn't we establish the other day that ifconfig if eui64 already did what your +inet6 does? almost, it's ifconfig if inet6 eui64 - but that isn't all THAT intuitive. I like +inet6 as the opposite

Re: libssl remove SSL_(set|get)_(time|timeout)

2014-05-29 Thread Theo de Raadt
I'm not sure how much, and if this breaks anything in Ports. Then you need to go find out. According to github it isn't used much. Whoa. Think about that for a while. You want to disrupt the application authors ... now?

Re: libssl remove SSL_(set|get)_(time|timeout)

2014-05-29 Thread Theo de Raadt
On Thu, May 29, 2014 at 21:00, Alexander Schrijver wrote: I'm not sure how much, and if this breaks anything in Ports. According to github it isn't used much. We're going to keep this for a while. We would like to keep as much API compatibility as possible, even when the API is mostly

Re: 9p

2014-05-30 Thread Theo de Raadt
However, as we've seen with lots of things that touch vfs it's pretty easy to get to 80 or 90 percent functionality and then the last 10% is a royal red pain in the butt, with possibly awful crashing bugs. The word possibly makes that sentence too optimistic.

Re: 9p

2014-05-30 Thread Theo de Raadt
Yes, that's true. you *WILL* have awful crashing or hanging bugs to chase ;) Welcome to the midlayer. Wine bottles are optional but highly recommended. And dual purpose. 1) drink it with pleasure in the company of a VFS hacker 2) when the midlayer breaks, beat the VFS hacker over the head

Re: [PATCH 4/7] use BIO_write instead of an unchecked write()

2014-05-31 Thread Theo de Raadt
Your change is wrong. There have been lots of discussion about trying to use intrinsics as much as possible. Even though this is the openssl command, I think the consideration is also valid here. You've just run into the reason for using intrinsics as much as possible. BIO_write is different

Re: [PATCH 1/3] Check output of write() to stdout

2014-06-01 Thread Theo de Raadt
This diff is very dissapointing. Check for errors on write. Since SIGPIPE is ignored, play nicely with pipelines by aborting on EPIPE. --- src/apps/s_server.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/apps/s_server.c b/src/apps/s_server.c index

Re: [PATCH 2/7] fix type string conversion warning

2014-06-02 Thread Theo de Raadt
On Mon, Jun 02, 2014 at 12:33:14PM -0400, Ted Unangst wrote: What compiler warns about this? It's perfectly fine to pass a nonconst string to a function that takes a const string. char * vs unsigned char *? So this is a great way to lose focus. The agenda is a step-by-step refactoring

Re: 9p

2014-06-04 Thread Theo de Raadt
Matthew, you obviously did not spot the evil 9p/util.h yet. This file ought to be named ozymandias.h. Also, I am vetoing the addition of -fms-extensions to the kernel build options. Whatever files require this option to build needs to be fixed to be proper, unambiguous, C99, instead. I

Re: ld.so take 2

2014-06-05 Thread Theo de Raadt
+ if (optr != NULL) { + _dl_write(STDERR_FILENO, msg1, sizeof(msg1) - 1); + _dl_exit(7); + } I think this is a trap. A true realloc is not much to add. It can be the simple always realloc method, since actually that is better for security right off the

Re: ld.so take 2

2014-06-05 Thread Theo de Raadt
The new malloc has been comitted, so now take the next step. This changes _dl_malloc to a regular non-zeroing _dl_malloc and uses _dl_calloc and _dl_reallocarray. This needs carefull review. Yes very careful. Otto is basing this part off ugly ld.so refactoring tree I shared with him. It

Re: syncing libc and libkern

2014-06-05 Thread Theo de Raadt
However, seeing as things are maintained separately (for good reasons), perhaps copy-to-libkern itself should just be removed since it's basically pointless at this point and hasn't been used for about a decade. I think that is the right direction. Then, do a seperate cleanup.

Re: new OpenSSL flaws

2014-06-05 Thread Theo de Raadt
Em 05-06-2014 15:42, dera...@cvs.openbsd.org escreveu: We are sorry that the errata for these libssl security issues are not up yet. The majority of these issues are in our ssl library as well. Most other operating system vendors have patches available, but that is because they were

Re: new OpenSSL flaws

2014-06-05 Thread Theo de Raadt
There are two main open-source processes for dealing with discovery of security issues and disclosure of that information to the greater community. - One common process is that generally followed by OpenBSD. In this proocess a bug is found, and a fix is commited as soon as the improvement is

Re: new OpenSSL flaws

2014-06-05 Thread Theo de Raadt
Is clear that the second process -- intending to also take an ethical path for disclosure -- should not specifically exclude a part of the community. They specifically exclude parts of the community that specifically say they don't want to be INCLUDED. See:

Re: new OpenSSL flaws

2014-06-05 Thread Theo de Raadt
That's exactly my though. Specially, because FreeBSD and NetBSD were warned, but not OpenBSD. If this was only a rant or any childish behavior from them, it's something stupid and, of course, not the right thing to do. But hey, we're all human. My real concern is if this something else,

Re: new OpenSSL flaws

2014-06-05 Thread Theo de Raadt
Not saying I believe or disbelieve him, but it can't hurt to join even if it is only until 5.6 comes out. Another way to phrase this is The OpenBSD user community should accept they have suffered because Theo declined an invitation to a private email list, entirely unrelated to the

Re: new OpenSSL flaws

2014-06-05 Thread Theo de Raadt
I suggest you talk to Mark Cox who actually handled this stuff. I'm not sure why you are asking two people (myself and Solar) who are NOT part of the OpenSSL team about whom the OpenSSL team notified. Kurt, if Mark Cox is the person who handled this stuff, fine. Who cares? I am hearing

[no subject]

2014-06-05 Thread Theo de Raadt
pvt.openwall.com) (127.0.0.1) by localhost with SMTP; 6 Jun 2014 04:21:39 - Received: by pvt.openwall.com (Postfix, from userid 503) id 82DA048BCE; Fri, 6 Jun 2014 08:21:05 +0400 (MSK) Date: Fri, 6 Jun 2014 08:21:05 +0400 From: Solar Designer so...@openwall.com To: Theo de Raadt dera

Re: mfi(4) vs WT and WB

2014-06-06 Thread Theo de Raadt
Which has an OK battery but still reports itself as being in WT mode: So what's the status of this WT/WB flag? Can't it be trusted for PERC 6/i and maybe other adapters? If so, a man page blurp would be needed imo. Difficult experiences have taught me to mistrust all the sensors

Re: increase netcat's buffer...

2014-06-09 Thread Theo de Raadt
A better patch is probably the following which also increases the size of the buffer to at least 64k: Agreed. One thing to be aware of. That function is syncronous. It will read as much as it can get, then it will do an atomic write operation to flush the buffer out the other way. If

Re: [PATCH] Use mkstemp instead of mktemp.

2014-06-10 Thread Theo de Raadt
And you tested to make sure that it works after your change? Fascinating. mktemp was removed from POSIX 2008 for security reasons. --- usr.bin/nc/netcat.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/usr.bin/nc/netcat.c b/usr.bin/nc/netcat.c index

Re: We can dump(8) more than 2TB

2014-06-12 Thread Theo de Raadt
Date: Thu, 12 Jun 2014 15:14:29 -0400 From: Ted Unangst t...@tedunangst.com On Thu, Jun 12, 2014 at 21:07, Christian Weisgerber wrote: After writing 2TB (INT_MAX * TP_BSIZE), dump(8) stops reporting progress because the blockswritten variable has wrapped around to negative. It

Re: diff: add tuning variables to config(8)

2014-06-16 Thread Theo de Raadt
Followings are our kernel variables' default: - sb_max: 256K - tcbhash_size: 128 - udbhash_size: 128 These variables are sometime too small for busy server or gateway. I'd like to modify config(8) to customize these variables without recompiling the kernel. If we

Re: increase netcat's buffer...

2014-06-17 Thread Theo de Raadt
It should not use kevent. That makes the code non-portable. Use poll().

Re: compare memcmp with 0

2014-06-19 Thread Theo de Raadt
Always explicitly compare memcmp with 0. I find this adds clarity. If you don't care which way a different comparison points, then why not use bcmp? Because knowledge of the difference in is scarce. Someone will screw it up. It could be argued that the bcmp manual page does a poor job

Re: compare memcmp with 0

2014-06-19 Thread Theo de Raadt
If we use timingsafe_bcmp widely (safe as that may be), it's very hard to convey the idea that there are circumstances when it is not safe. Using timingsafe_memcmp raises its awareness and will make it other developers' default choice. Exactly. It is easier to develop a pattern/meme when the

boringssl and such

2014-06-20 Thread Theo de Raadt
Few things to note... I suspect everyone working on LibReSSL is happy to hear the news about BoringSSL. Choice is good!! Their priority is on safety, not on ABI compatibility. Just like us. Over time, I suspect google's version will also become 'reduced API', since they require less legacy

Re: porting arc4random (was Re: boringssl and such)

2014-06-21 Thread Theo de Raadt
having just this evening updated Android to the current arc4random (https://android-review.googlesource.com/#/c/99052/), i was confused by the single use of explicit_bzero amongst the many calls to memset in the same file. as for portability, Linux requires MAP_PRIVATE anywhere you use MAP_ANON,

Re: NOINET6 by default

2014-06-23 Thread Theo de Raadt
I'm volunteering for this job. I know that other people have already expressed interest in such a task. Can we please postpone ifp-if_xflags |= IFXF_NOINET6; until the situation is more clear? I think 5.6 is a safe bet. No. Apparently you are the only one who keeps postponing action,

Re: infnan.3

2014-06-24 Thread Theo de Raadt
It's obvious that whole page needs a content update by a VAX expert. that is correct. All the rest of the discussion is moot. Only miod and martynas can swing this the right way. I disagree with Ted about making this a seperate page, since that would remove a vital component of floating point

Re: POSIX-compliant page fault error codes

2014-06-24 Thread Theo de Raadt
Matthew -- fine, you collected information. Thank you. It is quite clear that POSIX set in stone an accident, a significant error in my opinion. Anyone with enough expertise can recognize this is an accident in the SVR4 codebase, which ended up being ratified (in quotes, because the more

Re: slightly stricter check for genentropy_urandom

2014-06-25 Thread Theo de Raadt
Here is a minor diff to do a little more strict checking on the device id for urandom. It would be a shame if someone replaced a genuine urandom with a /dev/null or some other predictable device. if a file is not special st_rdev will be 0 so S_ISCHR isn't needed anymore. So you are trying

Re: slightly stricter check for genentropy_urandom

2014-06-25 Thread Theo de Raadt
On 06/25/14 21:15, Theo de Raadt wrote: Here is a minor diff to do a little more strict checking on the device id for urandom. It would be a shame if someone replaced a genuine urandom with a /dev/null or some other predictable device. if a file is not special st_rdev will be 0 so

Re: slightly stricter check for genentropy_urandom

2014-06-25 Thread Theo de Raadt
Hello tech@, Here is a minor diff to do a little more strict checking on the device id for urandom. It would be a shame if someone replaced a genuine urandom with a /dev/null or some other predictable device. that's what the ioctl is for Actually, the ioctl does not do actually

Re: Unnecessary mmap flags?

2014-06-26 Thread Theo de Raadt
1. MAP_COPY is redefined as an alias for MAP_PRIVATE, and the other useless MAP_* flags are redefined to 0. They're also hidden from the kernel to make sure no kernel code accidentally depends on them still. 2. Adds COMPAT_O55_MAP_COPY so we can stay binary compatible with any OpenBSD 5.5

Re: Unnecessary mmap flags?

2014-06-27 Thread Theo de Raadt
MAP_HASSEMAPHORE is used in rthread_sem.c, but it doesn't do anything, so I suspect it's just cargo culting based on man page misinformation? Are there architectures that actually have restrictions on semaphore memory? There architectures where atomic instructions only work on pages

Re: POSIX-compliant page fault error codes

2014-06-29 Thread Theo de Raadt
To prevent this from happening, the X server will install a signal handler for SIGBUS, check if a shared memory object is being accessed and patch things up (by mmap'ing anonymous memory on top of the mapping). This code can be extended of course by handling SIGSEGV as well. But this means

Re: Rename MAP_ANON to MAP_ANONYMOUS

2014-06-30 Thread Theo de Raadt
I don't think MAP_ANONYMOUS is being proposed for standardization because it's perceived to be of older origin than MAP_ANON or anything. I'm pretty sure the focus is instead because it's perceived to have greater 'market share' among present day systems and applications. Oh come on, the pussy

Re: more deadbeef

2014-07-08 Thread Theo de Raadt
how would you like your deadbeef? well done? since we support variable poison values, we should invert the patterns sometimes to find bugs where the deadbeef values hide the bugs. (we can of course do even more with extra tricksy bit patterns, but start with this.) I have been worried

Re: Add MAP_ANONYMOUS as a synonym for MAP_ANON

2014-07-10 Thread Theo de Raadt
On Thu, Jul 10, 2014 at 11:50:18AM -0700, Matthew Dempsky wrote: Diff below defines MAP_ANONYMOUS as a synonym for MAP_ANON, keeping MAP_ANON as canonical in following BSD heritage. If MAP_ANON is going to be the canonical value then shouldn't you change MAP_PRIVATE to MAP_ANON instead of

Re: lynx: disable old protocols

2014-07-11 Thread Theo de Raadt
Pretty standard thing in several companies I do work for is to have an intranet page with http://, ssh://, telnet:// and finger:// (amazingly) links to various devices on the network. Having to read the source and escape to a shell would be somewhat worse than what I get on a base install

Re: lynx: disable old protocols

2014-07-11 Thread Theo de Raadt
I don't see a good reason to get rid of this. What is the rationale? Daniel appears to have made a mistake asking for approval on the wrong list. He's new here, take it easy on him.

Re: PATCH: add more malloc.conf details to malloc.3

2014-07-11 Thread Theo de Raadt
I am a bit concerned. The description is trying too hard to be overly precise, and may be cumbersome for the typical reader of this page. Index: lib/libc/stdlib/malloc.3 === RCS file: /cvs/src/lib/libc/stdlib/malloc.3,v

Re: lynx: disable old protocols

2014-07-11 Thread Theo de Raadt
On 2014/07/11 01:18, Theo de Raadt wrote: I too use gopher in lynx regularly, and would miss support. There is = still a surprisingly active community using gopher. (floodgap, et al.) So install a package. Should we just move lynx to packages? It is nice to have something in base. Moving

Re: lynx: disable old protocols

2014-07-11 Thread Theo de Raadt
I find lynx really handy to have in base, e.g. installing on a new machine, users can just go to openbsd.org and cut and paste a pkg_path prior to installing anything, and read the faq. that is why it is in base. but someone on the list wants to visit the openbsd gopher page to get that

Re: lynx: disable old protocols

2014-07-11 Thread Theo de Raadt
If lynx was removed from base, and only available in ports... how many of you would even know of it's existance and use it?

Re: [PATCH] rdomain support on rc.d

2014-07-11 Thread Theo de Raadt
Penned by Mike Belopuhov on 20140711 6:49.19, we have: | On 11 July 2014 10:29, Antoine Jacoutot ajacou...@bsdfrog.org wrote: | On Thu, Jul 10, 2014 at 06:51:01PM +0200, Loďc BLOT wrote: | Hello all, | I use rdomains to split routing domains per company and also separate |

Re: CVS: cvs.openbsd.org: src

2014-07-11 Thread Theo de Raadt
I'm worried that bogus codepaths will be taken in software that expects a certain openssl version - things failing to build we can cope with in ports easily enough, I'm more concerned about software that does build but behaves incorrectly at runtime. If the software is that fragile, then I am

Re: lynx: disable old protocols

2014-07-12 Thread Theo de Raadt
If there's a security hole related to gopher or bibp, let's fix it, let's not up and drop support for those protocols because of it. People do use these protocols even in 2014. let's is a contraction for let us. Basically the community must audit lynx, if they want it to remain in base. Those

Re: CVS: cvs.openbsd.org: src

2014-07-12 Thread Theo de Raadt
I am however curious about the rational behind this change. Does it solve any particular problem/risk? I seldomly use this style in my own scripts when I need to be able to dynamically determine variables at runtime. So it might be wise to know what hidden daemons I might be facing. The

Re: lynx: disable old protocols

2014-07-13 Thread Theo de Raadt
With your attitude, I beg you to please go run some other operating system.

Re: lynx: disable old protocols

2014-07-13 Thread Theo de Raadt
Why haven't you left? Please leave. On Sat, 2014-07-12 at 23:58 -0700, William Orr wrote: wrt. auditing it, should we send patches here? Or upstream? I'd send them both places, if they apply cleanly to both sets of code. Otherwise, send them here. I'd love to be proven wrong about the

Re: lynx: disable old protocols

2014-07-13 Thread Theo de Raadt
Why haven't you left yet Shawn?

Re: lynx: disable old protocols

2014-07-13 Thread Theo de Raadt
You demand us to do work? Please leave immediately. On Sun, 2014-07-13 at 02:01 -0600, Theo de Raadt wrote: Why haven't you left yet Shawn? Because for the moment, I still am an OpenBSD user. And you haven't answered my question why there's been no exploit of this poor quality code

Re: mallocarray() in sys/dev, first pass

2014-07-13 Thread Theo de Raadt
Index: ic/malo.c - ring-data = malloc(count * sizeof (struct malo_rx_data), M_DEVBUF, - M_NOWAIT); + ring-data = mallocarray(count, sizeof (struct malo_rx_data), + M_DEVBUF, M_NOWAIT); Might as well s/sizeof (/sizeof(/ while you're here. And fix the interrupt handler

Re: use mallocarray in kern

2014-07-13 Thread Theo de Raadt
And some others from exec that follow a slightly different pattern. This is the pattern I have been following as well. As for the final diff, I've been giving up on the known constant scenario. It seems expensive. Index: exec_script.c

Re: use mallocarray in kern

2014-07-13 Thread Theo de Raadt
On Sun, Jul 13, 2014 at 17:52, Theo de Raadt wrote: And some others from exec that follow a slightly different pattern. This is the pattern I have been following as well. As for the final diff, I've been giving up on the known constant scenario. It seems expensive. Meh. :) I

Re: faster malloc in threads

2014-07-14 Thread Theo de Raadt
Anyway, I still like the idea, but I wonder if now right after the hackathon is the right time. But please continue experimenting with this during my vacation ;-) Changing the error message would be a good thing, to distinguish the various calls to munmap. Timing is bad. We need to fix the

Re: [PATCH] libressl: add dummy egd functions

2014-07-14 Thread Theo de Raadt
Ted Unangst tedu at tedunangst.com writes: Any system that actually uses egd is so hopelessly broken you are better off just turning around and walking away. No software in 2014 should be using egd; no software in 2014 should support using egd by accident. This is wrong. The egd protocol is

Re: trunk on RAMDISK_CD

2014-07-15 Thread Theo de Raadt
Please don't send such mails if you didn't test yourself. Tree will lock right away. naddy's mpbios RAMDISK_CD mail reminded me that I have put trunk into RAMDISK_CD here for some time. Without, upgrading of machines with trunk is unecessarily hard, since, well, you won't get your trunk

Re: DNS control port additions to /etc/services

2014-07-15 Thread Theo de Raadt
On Tue, Jul 15, 2014 at 12:22:37PM +0100, Craig R. Skinner wrote: Suggestion of add NSD, Unbound BIND control ports to /etc/services: Makes sense to me. Anyone want to OK this? Index: etc/services === RCS file:

Re: DNS control port additions to /etc/services

2014-07-15 Thread Theo de Raadt
Date: Tue, 15 Jul 2014 17:17:45 +0200 From: Antoine Jacoutot ajacou...@bsdfrog.org But be careful, this is not a user-editable file anymore, so we need to take into account that some stuffs that may not appear obvious to us may still be needed by people. That's a mistake. You're supposed

Re: DNS control port additions to /etc/services

2014-07-15 Thread Theo de Raadt
BIND uses TCP for the control socket, so if this does go in, please do not list the UDP one. Correct. For any service that runs on only one protocol, do not list the other protocol.

Re: LibreSSL and GOST crypto

2014-07-16 Thread Theo de Raadt
On Wed, Jul 16, 2014 at 12:29 PM, Dmitry Eremin-Solenikov dbarysh...@gmail.com wrote: I have started looking into GOST (re)implementation for LibreSSL. I would like to know, how much do you want for LibreSSL to mimic the OpenSSL behaviour. I have been pointed that I did not formulate

Re: PATCH: further kernel malloc - mallocarray

2014-07-16 Thread Theo de Raadt
I would really really prefer if we can keep these as const*const conversions instead of const, const. We will see performance losses from doing this operation at runtime. On Wed, Jul 16, 2014 at 04:54:49AM +, Doug Hogan wrote: + if ((fake_table = mallocarray(3, sizeof(struct

Re: improve srandomdev

2014-07-16 Thread Theo de Raadt
On 07/13/2014 06:31 PM, Jean-Philippe Ouellet wrote: On Sun, Jul 13, 2014 at 04:03:53PM +0200, Brent Cook wrote: On Jul 13, 2014, at 3:58 PM, Ted Unangst t...@tedunangst.com wrote: @@ -411,6 +404,9 @@ static long random_l(void) { int32_t i; + + if (use_arc4random) +

Re: PATCH: further kernel malloc - mallocarray

2014-07-16 Thread Theo de Raadt
From: Theo de Raadt dera...@cvs.openbsd.org Date: Wed, 16 Jul 2014 08:18:34 -0600 I would really really prefer if we can keep these as const*const conversions instead of const, const. Indeed, conversion to mallocarray only makes sence if one of the multiplication operands

Re: PATCH: further kernel malloc - mallocarray

2014-07-16 Thread Theo de Raadt
static __inline int MULT_OVERFLOWS(int x, int y) { const intmax_t max = 1UL sizeof(size_t) * 4; return ((x = max || y = max) x 0 SIZE_MAX / x y); } (or maybe a macro version) in some public header someplace, and associated assertions it where applicable. The coding

Re: improve srandomdev

2014-07-16 Thread Theo de Raadt
That is false. Please read the actual code. The new variation uses srandomdev() as an indicator that random() gets hooked direct to arc4random. The guts of the algorithm are never used again. I did, that's why fwiw and needed, as in look, you fixed a bug without noticing. Oh, ok.

Re: lynx: disable old protocols

2014-07-16 Thread Theo de Raadt
On Wed, 2014-07-16 at 13:56 -0500, patric conant wrote: I'd also like to point out that Shawn has broken the social contract here, it's well known that it's generally considered rude to direct developers, in this forum. Every single free or open-source software project I have ever used has

Re: lynx: disable old protocols

2014-07-16 Thread Theo de Raadt
For the rest of us who prefer to use software instead of demanding changes, this simply means using OpenBSD in a strictly-isolated environment becomes a bit more difficult. This statement makes no sense. Why would you strictly isolate the environment? Because you want security. In that

Re: Miscellaneous LibreSSL portability fixes

2014-07-17 Thread Theo de Raadt
On 17/07/14 04:26, Bob Beck wrote: Steve, sorry, but GNU/kFreeBSD is not going to happen right now. We are too busy with other things. I understand, actually I wasn't asking for that. I think having lots of platform-specific implementations would be unclean, I was only hoping the existing

Re: Only what you need

2014-07-18 Thread Theo de Raadt
Something that has been in my eye for a while; how about those users and groups? $ cat /etc/passwd|wc -l 56 $ cat /etc/group |wc -l 75 Maybe one group for write access to /var, one for /etc, etc? Or we could run them all as root.

Re: [DIFF] sftp-server.8, sshd_config.5 after syslog_r change

2014-07-18 Thread Theo de Raadt
Unfortunately, no. The ssh manual pages are also used by the -portable effort. We do not bother documenting these divergences; there is little harm. Actually you could submit a new diff which suggest that logging might need a /dev/log setup. If written carefully to cover both kinds of systems,

Re: res_random.c: 'static' is not at beginning of declaration

2014-07-21 Thread Theo de Raadt
revision 1.21 date: 2014/07/20 04:22:34; author: guenther; state: Exp; lines: +2 -2; commitid: x7aBoxPF8nZvW5Z0; From ISO/IEC 9899:1999 and 9899:201x, 6.11.5 - Storage-class specifiers: The placement of a storage-class specifier other than at the beginning of the declaration

Re: PATCH: overflow behavior in malloc(9)

2014-07-22 Thread Theo de Raadt
On Tue, Jul 22, 2014 at 21:21, Doug Hogan wrote: On Tue, Jul 22, 2014 at 02:51:17AM -0400, Jean-Philippe Ouellet wrote: That is misleading in the M_CANFAIL case. I'm not terribly good at wording things, but I suggest something more like this instead: Hmm I think it's only misleading in the

Re: [PATCH, libressl] discuss: removal of padding extension?

2014-07-23 Thread Theo de Raadt
Quick background: Some router firmwares from F5 have a bug that they fail if the SSL handshake is between 256 and 511 bytes. Following up that openssl and other major ssl implementations introduced a TLS padding extension that does nothing else than padding the handshake if it is

Re: [DIFF] sftp-server.8, sshd_config.5 after syslog_r change

2014-07-28 Thread Theo de Raadt
Unfortunately, no. The ssh manual pages are also used by the -portable effort. We do not bother documenting these divergences; there is little harm. Actually you could submit a new diff which suggest that logging might need a /dev/log setup. If written carefully to cover both kinds of

Re: /dev/crypto removal (3bis): DTYPE_CRYPTO

2014-08-19 Thread Theo de Raadt
I don't know if we recycle them somehow, but just in case... --- sys/sys/file.h +++ sys/sys/file.h ... -#defineDTYPE_CRYPTO5 /* crypto */ +/* was define DTYPE_CRYPTO5 */ When it goes, this is the way to document it, yep. ...but you better delete the

Re: PATCH: rtsol support for RA DNS options

2014-09-21 Thread Theo de Raadt
I didn't realize autoconf was in in the kernel and plumbed up through ifconfig. Centralizing this stuff seems like a cleaner way to do it than having rtsol/rtsold, in which case this patch is barking up the wrong tree. Yes, you are working in an old tree. Has any thought been given to

Re: PATCH: rtsol support for RA DNS options

2014-09-21 Thread Theo de Raadt
One way to manage the file is the openresolv script I mentioned earlier. The idea is that entities like dhclient invoke it with resolver information they want to use and the script merges requests from multiple sources. I do not understand how this solution will practically work. Seeing as

Re: chmod.c undefined behavior

2014-09-24 Thread Theo de Raadt
I mght be wrong, but why not just initialize to NULL? I am watching this thread to spot people who should never be OpenBSD developers...

Re: chmod.c undefined behavior

2014-09-24 Thread Theo de Raadt
That main function is good, standard style. Unnecessary goto, variables defined far away from where they are used, monster function, variables are not commented what they do, not all functions are commented what they do.. To me, it looks like that there is no intention to optimize readability

Re: chmod.c undefined behavior

2014-09-24 Thread Theo de Raadt
I have about million lines of build and other errors under review where I have found anomalies. Some of them seems to be errors in OpenBSD, most of them are errors in code. Yet somehow out of those million you decided to send in a patch which introduced a bug. I believe I know your type.

  1   2   3   4   5   6   7   8   9   10   >