On Thu, Jun 05, 2014 at 07:39:01PM +0200, Fabian Raetz wrote:
> Hi tech@,
Please ignore this thread!
A reboot after rebuilding userland fixed the problem. Sorry!
>
> when calling ifconfig(8) with a not supported option like below, it
> segfaults.
>
> ifconfig [interface] -someParameterNo
Theo,
On Thu, Jun 05, 2014 at 04:38:24PM -0600, Theo de Raadt wrote:
> Kurt and Solar --
>
> You are the primary contacts for the oss-security email list.
Kurt is not. I guess the reason why you got such impression was because
Kurt invited you to join distros recently, not knowing that you had
I'll top-post this one time, to quote Chris' message in its entirety.
I've dropped the CC to secur...@redhat.com - it felt too spammy to be
sending them this. I've added Kurt, who is already involved in the
discussion.
Theo -
Thank you for (apparently) forwarding my reply to your team. I was
un
Theo de Raadt [dera...@cvs.openbsd.org] wrote:
> From: Solar Designer
> To: Theo de Raadt
>
> 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 only via distros list, but at all.
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 re
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 mother.openwall.
> 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 cl
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
p
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 h
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
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 as
> 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 th
> > 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
> > somethi
> 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
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 wi
> >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: http://seclists.org/
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 usual
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
> 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
le
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
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 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 vendo
> 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 bec
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 (
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 days.
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
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, siz=
> 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.
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
>
On June 5, 2014 2:34:00 PM CEST, Otto Moerbeek 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 02:2
> 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
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 "alwa
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 o
+ 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 b
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 b
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 t
36 matches
Mail list logo
