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
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.
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
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
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
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.
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
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.
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.
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
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
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
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
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
* 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
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?
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
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.
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
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
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
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
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
+ 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
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
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.
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
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
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:
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,
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
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
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
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
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
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
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
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
It should not use kevent. That makes the code non-portable. Use poll().
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
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
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
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,
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,
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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?
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
|
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
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
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
With your attitude, I beg you to please go run some other
operating system.
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
Why haven't you left yet Shawn?
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
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
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
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
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
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
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:
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
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.
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
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
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)
+
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
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
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.
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
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
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
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.
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,
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
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
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
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
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
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
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
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...
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
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.
Newish Ricoh sdhc chipsets initialize into a high speed mode that is
not compatible with our existing sdmmc stack. At activate we push
the chipset into the older modes; we need to do the same at resume
time.
Fixes the x230.
Index: sdhc_pci.c
Oops, only do the ricoh fixup on the specific ricoh chips.
Index: sdhc_pci.c
===
RCS file: /cvs/src/sys/dev/pci/sdhc_pci.c,v
retrieving revision 1.15
diff -u -p -u -r1.15 sdhc_pci.c
--- sdhc_pci.c 13 Jul 2014 23:10:23 -
so is there a better way to just build a kernel? i'm not going to build a
whole release just for one kernel, especially when experimenting. and i mean
a RAMDISK kernel. i think its great the things i can do with openbsd, even
when it is not what is intended.
tough.
I'm sorry, but this is the
That utility is grossly disgusting. It's a pity we can't delete
it completely [...]
Why not?
:-)
1 - 100 of 2804 matches
Mail list logo
