confirming that this patch fixes the failing numpy regress test on i386.
let me know if you want me to test a different diff.
Here's a better diff, inspired by what FreeBSD has.
ok?
ok with me. numpy works with this diff too.
Hi,
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. I left some malloc calls since they do not
require zero'ing according to my analysis, but this easy
OK,
Grrr... messed this up, sent thw wrong version. Both the To: header
and the text contain errors, but the intend should be clear. Diff is
the right version.
Take care when replying.
-Otto
On Thu, Jun 05, 2014 at 02:22:01PM +0200, Otto Moerbeek wrote:
Hi,
The new malloc has
+ 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
On Mon, Jun 02, 2014 at 17:51 +0200, Mike Belopuhov wrote:
Hi,
I've been chasing some bugs in the pfctl anchor code for a couple
of weeks and I'm not astonished at how loose the handling is in
general. Lot's of rules and checks are being violated by some
code paths while honoured by
On Thu, Jun 05, 2014 at 09:04:25AM -0600, Theo de Raadt wrote:
+ 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
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
On June 5, 2014 2:34:00 PM CEST, Otto Moerbeek o...@drijf.net wrote:
OK,
Grrr... messed this up, sent thw wrong version. Both the To: header
and the text contain errors, but the intend should be clear. Diff is
the right version.
Take care when replying.
-Otto
On Thu, Jun 05, 2014 at
On Wed, Jun 04, 2014 at 08:02:06PM +, Miod Vallat wrote:
First, str{cat,cpy} were vehemently expunged from the kernel many years ago,
so stop trying to keep them around.
Index: lib/libc/Makefile.inc
Hello, this is libc you are butchering in. I'm afraid strcat and strcpy
are still
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.
Hi tech@,
when calling ifconfig(8) with a not supported option like below, it
segfaults.
ifconfig [interface] -someParameterNotSupportedWithALeadingMinus
ifconfig re0 -adaw
ifconfig iwn0 -media
Here's a backtrace:
#0 strlcpy (dst=0x84c658 _entbuf+24 , src=0x0,
if we're going to backport stuff like the User-Agent diff we might as
well backport some of the real minor bugfixes too :-)
i'll go over the changes and prepare something in the next couple days
On Fri, May 30, 2014 at 07:40:57PM -0400, Ted Unangst wrote:
There have been some rather important
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 (obviously) given a heads up to prepare them over
the last few
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
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
Em 05-06-2014 15:57, Theo de Raadt escreveu:
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
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
Em 05-06-2014 16:27, Theo de Raadt escreveu:
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
Now you have and example of how they are unwilling to work with you next
time someone asks why not work with OpenSSL on fixing it. Pretty direct
proof.
The culture gap between OpenSSL and OpenBSD/LibreSSL is UNFIXABLE.
We believe in peer review; they don't give a sh*t about it (as shown
less
On Thu, Jun 05, 2014 at 08:02:58PM +, Miod Vallat wrote:
If you can't trust people to apply one-liner fixes correctly, can you
trust them for anything serious?
I really don't like to point fingers, but...
It is done by the same people that introduced
the Debian random number bug back in
Hi,
That said, I think the DigestUpdate and similar checks are unnecessary
and complicate the code more than they help. Those functions really
can't fail.
Hmm, which ones specifically? In particular for DigestUpdate I always
wondered why that should fail, but adding a few error checks usually
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:
The diff below fixes the spell-o in OpenBSD::PackageRepository::Persistant's
name.
All regress tests still pass on amd64.
On a related note, the regress tests now require user interaction because the
packages created added during the tests are unsigned. I haven't looked into
that yet but am
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, a
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
We are not on a linux distros mailing list, because we are not a linux
distribution. And this private mailing list is not really an
acknowledged conduit for vulnerability release.
I was asked by someone privately if *I* would be on that mailing list
on June 2nd.
I said I would consider it, but
Em 05-06-2014 19:43, Bob Beck escreveu:
For the record, we didn't get advance notice of Heartbleed either, so
this is nothing new.
Bob,
I didn't knew that. I feel like I've released a monster (Cthulhu
anyone?). I was just curious when I asked Theo if this did happened
before. It's possible
On 2014/06/05 20:43, Martin, Matthew wrote:
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.
I may also remind people that those lists are acknowledged right at the top
as experimental. They also do not allow for non personal subscriptions, so
they aren't very practical for this. What if I was away for a day or
three.. Or more.. Essentially this is a nice experiment, but not really a
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
Fcc: +outbox
Subject: Re: that private mailing list (fwd) Solar Designer: Re: that private
mailing list
I haven't even read this.
I don't care.
if this is the situation with open source disclosure, all of you
users are fucked.
--- Forwarded Message
Received: from
Miod Vallat [m...@online.fr] wrote:
Now you have and example of how they are unwilling to work with you next
time someone asks why not work with OpenSSL on fixing it. Pretty direct
proof.
The culture gap between OpenSSL and OpenBSD/LibreSSL is UNFIXABLE.
We believe in peer review;
Theo de Raadt [dera...@cvs.openbsd.org] wrote:
From: Solar Designer so...@openwall.com
To: Theo de Raadt dera...@cvs.openbsd.org
Hi Theo,
I can't comment about OpenSSL folks, but my own impression certainly was
that you didn't want your project to be provided advance notification -
not
34 matches
Mail list logo
