Re: nextafterl(3) possible bug
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.
ld.so take 2
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 to get wrong.
This also hold fo changes to _dl_reallocarray, since it does not zero,
while the old _dl_malloc did.
Some parts of this diff extracted from a diff by deraadt@
Pleas review and test.
-Otto
Index: Makefile
===
RCS file: /cvs/src/libexec/ld.so/Makefile,v
retrieving revision 1.49
diff -u -p -r1.49 Makefile
--- Makefile5 Jun 2014 08:41:09 - 1.49
+++ Makefile5 Jun 2014 11:22:35 -
@@ -15,7 +15,7 @@ VPATH=${.CURDIR}/../../lib/libc/string
SRCS= ldasm.S boot.c loader.c resolve.c dlfcn.c dl_printf.c rtld_machine.c
SRCS+= path.c util.c sod.c strsep.c strtol.c dir.c library_subr.c dl_prebind.c
SRCS+= dl_realpath.c dl_uname.c dl_dirname.c strlcat.c strlen.c trace.c
-SRCS+= malloc.c
+SRCS+= malloc.c reallocarray.c
.if (${MACHINE_ARCH} == i386)
SRCS+= library_mquery.c
Index: dir.c
===
RCS file: /cvs/src/libexec/ld.so/dir.c,v
retrieving revision 1.17
diff -u -p -r1.17 dir.c
--- dir.c 13 Aug 2013 05:52:17 - 1.17
+++ dir.c 5 Jun 2014 11:22:35 -
@@ -68,7 +68,7 @@ _dl_opendir(const char *name)
return (NULL);
}
if (_dl_fcntl(fd, F_SETFD, FD_CLOEXEC) 0 ||
- (dirp = _dl_malloc(sizeof(*dirp))) == NULL) {
+ (dirp = _dl_calloc(1, sizeof(*dirp))) == NULL) {
_dl_close(fd);
return (NULL);
}
Index: dl_prebind.c
===
RCS file: /cvs/src/libexec/ld.so/dl_prebind.c,v
retrieving revision 1.13
diff -u -p -r1.13 dl_prebind.c
--- dl_prebind.c13 Nov 2013 05:41:41 - 1.13
+++ dl_prebind.c5 Jun 2014 11:22:35 -
@@ -200,7 +200,8 @@ prebind_symcache(elf_object_t *object, i
if (i = NUM_STATIC_OBJS) {
objarray = objarray_static[0];
} else {
- objarray = _dl_malloc(sizeof(elf_object_t *) * i);
+ objarray = _dl_reallocarray(NULL,
+ sizeof(elf_object_t *), i);
}
obj = _dl_objects;
Index: library.c
===
RCS file: /cvs/src/libexec/ld.so/library.c,v
retrieving revision 1.67
diff -u -p -r1.67 library.c
--- library.c 20 Aug 2012 23:25:07 - 1.67
+++ library.c 5 Jun 2014 11:22:35 -
@@ -195,7 +195,7 @@ _dl_tryload_shlib(const char *libname, i
TRUNC_PG(phdp-p_offset));
} else
res = NULL; /* silence gcc */
- next_load = _dl_malloc(sizeof(struct load_list));
+ next_load = _dl_calloc(1, sizeof(struct load_list));
next_load-next = load_list;
load_list = next_load;
next_load-start = start;
Index: library_mquery.c
===
RCS file: /cvs/src/libexec/ld.so/library_mquery.c,v
retrieving revision 1.44
diff -u -p -r1.44 library_mquery.c
--- library_mquery.c20 Aug 2012 23:25:07 - 1.44
+++ library_mquery.c5 Jun 2014 11:22:35 -
@@ -158,6 +158,7 @@ _dl_tryload_shlib(const char *libname, i
size = off + phdp-p_filesz;
if (size != 0) {
+ /* XXX */
ld = _dl_malloc(sizeof(struct load_list));
ld-start = NULL;
ld-size = size;
@@ -171,7 +172,7 @@ _dl_tryload_shlib(const char *libname, i
ROUND_PG(size) == ROUND_PG(off + phdp-p_memsz))
break;
/* This phdr has a zfod section */
- ld = _dl_malloc(sizeof(struct load_list));
+ ld = _dl_calloc(1, sizeof(struct load_list));
ld-start = NULL;
ld-size = ROUND_PG(off + phdp-p_memsz) -
ROUND_PG(size);
Index: loader.c
===
RCS file: /cvs/src/libexec/ld.so/loader.c,v
retrieving revision 1.147
diff -u -p -r1.147 loader.c
--- loader.c16 Feb 2014 01:16:38 - 1.147
+++ loader.c5 Jun 2014 11:22:35 -
@@ -280,8 +280,10 @@ _dl_load_dep_libs(elf_object_t *object,
} *liblist;
int *randomlist;
- liblist = _dl_malloc(libcount *
Re: ld.so take 2
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 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 to get wrong.
This also hold fo changes to _dl_reallocarray, since it does not zero,
while the old _dl_malloc did.
Some parts of this diff extracted from a diff by deraadt@
Pleas review and test.
-Otto
Index: Makefile
===
RCS file: /cvs/src/libexec/ld.so/Makefile,v
retrieving revision 1.49
diff -u -p -r1.49 Makefile
--- Makefile 5 Jun 2014 08:41:09 - 1.49
+++ Makefile 5 Jun 2014 11:22:35 -
@@ -15,7 +15,7 @@ VPATH=${.CURDIR}/../../lib/libc/string
SRCS=ldasm.S boot.c loader.c resolve.c dlfcn.c dl_printf.c
rtld_machine.c
SRCS+= path.c util.c sod.c strsep.c strtol.c dir.c library_subr.c
dl_prebind.c
SRCS+= dl_realpath.c dl_uname.c dl_dirname.c strlcat.c strlen.c trace.c
-SRCS+= malloc.c
+SRCS+= malloc.c reallocarray.c
.if (${MACHINE_ARCH} == i386)
SRCS+= library_mquery.c
Index: dir.c
===
RCS file: /cvs/src/libexec/ld.so/dir.c,v
retrieving revision 1.17
diff -u -p -r1.17 dir.c
--- dir.c 13 Aug 2013 05:52:17 - 1.17
+++ dir.c 5 Jun 2014 11:22:35 -
@@ -68,7 +68,7 @@ _dl_opendir(const char *name)
return (NULL);
}
if (_dl_fcntl(fd, F_SETFD, FD_CLOEXEC) 0 ||
- (dirp = _dl_malloc(sizeof(*dirp))) == NULL) {
+ (dirp = _dl_calloc(1, sizeof(*dirp))) == NULL) {
_dl_close(fd);
return (NULL);
}
Index: dl_prebind.c
===
RCS file: /cvs/src/libexec/ld.so/dl_prebind.c,v
retrieving revision 1.13
diff -u -p -r1.13 dl_prebind.c
--- dl_prebind.c 13 Nov 2013 05:41:41 - 1.13
+++ dl_prebind.c 5 Jun 2014 11:22:35 -
@@ -200,7 +200,8 @@ prebind_symcache(elf_object_t *object, i
if (i = NUM_STATIC_OBJS) {
objarray = objarray_static[0];
} else {
- objarray = _dl_malloc(sizeof(elf_object_t *) * i);
+ objarray = _dl_reallocarray(NULL,
+ sizeof(elf_object_t *), i);
}
obj = _dl_objects;
Index: library.c
===
RCS file: /cvs/src/libexec/ld.so/library.c,v
retrieving revision 1.67
diff -u -p -r1.67 library.c
--- library.c 20 Aug 2012 23:25:07 - 1.67
+++ library.c 5 Jun 2014 11:22:35 -
@@ -195,7 +195,7 @@ _dl_tryload_shlib(const char *libname, i
TRUNC_PG(phdp-p_offset));
} else
res = NULL; /* silence gcc */
- next_load = _dl_malloc(sizeof(struct load_list));
+ next_load = _dl_calloc(1, sizeof(struct load_list));
next_load-next = load_list;
load_list = next_load;
next_load-start = start;
Index: library_mquery.c
===
RCS file: /cvs/src/libexec/ld.so/library_mquery.c,v
retrieving revision 1.44
diff -u -p -r1.44 library_mquery.c
--- library_mquery.c 20 Aug 2012 23:25:07 - 1.44
+++ library_mquery.c 5 Jun 2014 11:22:35 -
@@ -158,6 +158,7 @@ _dl_tryload_shlib(const char *libname, i
size = off + phdp-p_filesz;
if (size != 0) {
+ /* XXX */
ld = _dl_malloc(sizeof(struct load_list));
ld-start = NULL;
ld-size = size;
@@ -171,7 +172,7 @@ _dl_tryload_shlib(const char *libname, i
ROUND_PG(size) == ROUND_PG(off + phdp-p_memsz))
break;
/* This phdr has a zfod section */
- ld = _dl_malloc(sizeof(struct load_list));
+ ld = _dl_calloc(1, sizeof(struct load_list));
ld-start = NULL;
ld-size = ROUND_PG(off + phdp-p_memsz) -
ROUND_PG(size);
Index: loader.c
===
RCS file: /cvs/src/libexec/ld.so/loader.c,v
retrieving revision 1.147
diff
Re: ld.so take 2
+ 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 bat
Re: pf anchor references
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 others. The problem I have is that
it's truly a rabbit's hole: almost every bug I hit is a feature
in disguise.
One thing that I particularly hate is called an anchor reference.
A good example of this is a ruleset like this:
anchor foo {
block all
}
anchor foo
If you believe it should be a syntax error let me disappoint you.
The second 'anchor foo' is just a reference to the anchor named
foo defined before:
# echo -e 'anchor foo {\n block all\n}\nanchor foo' | pfctl -f -
# pfctl -a '*' -sr
anchor foo all {
block drop all
}
anchor foo all {
block drop all
}
# echo -e 'pass all' | pfctl -a 'foo' -f -
# pfctl -a '*' -sr
anchor foo all {
pass all flags S/SA
}
anchor foo all {
pass all flags S/SA
}
And to demonstrate a reference specified by an absolute path we can
add anchor /foo inside foo:
# echo -e 'anchor /foo' | pfctl -a 'foo' -f -
This obviously gets us an endless loop if we decide to print out
contents recursively (pfctl -a '*' -sr). Thankfully this doesn't
affect ruleset evaluation in the kernel.
The basic question I have is why do we need this dangerous and (at
least in my eyes) pretty useless mechanism?
Any opinions on this? Does anyone make any sensible use of it?
Should we try to simplify this by removing ambiguous functionality?
Cheers,
Mike
While I've got a few responses on tech supporting me, I should
probably ask misc@ as well for additional scrutiny. And besides,
I've come up with an example that might simplify ruleset creation
for say multiple customer vlans or rdomains. Does anyone use it
like that? This looks like an anchor template that we want to
specify but not use directly in the main ruleset, but it plays
somewhat nicely with quick anchors.
(The ruleset below was tested and works correctly)
Cheers,
Mike
block all
anchor customer1 quick on rdomain 1 {
anchor /allow-egress
anchor /allow-ssh
anchor /allow-icmp-echo
}
anchor customer2 quick on rdomain 2 {
anchor /allow-egress
anchor /allow-ssh
}
pass in quick on rdomain 0 proto tcp to (self) port ssh
pass out quick on rdomain 0
# end of ruleset evaluation
block quick
anchor allow-ssh {
pass in proto tcp to (self) port ssh
}
anchor allow-icmp-echo {
pass in inet proto icmp to (self) icmp-type echoreq code 0
}
anchor allow-egress {
pass out
}
Re: ld.so take 2
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 realloc method, since actually that is better
for security right off the bat
Indeed nicer. atm it does not make a difference, since
_dl_reallocarray is always called with NULL. I'll write up a simple
realloc tonight.
-Otto
Re: ld.so take 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. It took me many days to get it working the first time.. Please check carefully. In summary: current ld.so malloc() has an implicit bzero. This is moving us to no implicit bzero, the callee has to that work. Just like the intrinsic behaviours of the libc variants. At the same time, the more sophisticated calloc() and reallocarray() versions are added...
Re: ld.so take 2
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 02:22:01PM +0200, Otto Moerbeek wrote:
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 to get
wrong.
This also hold fo changes to _dl_reallocarray, since it does not
zero,
while the old _dl_malloc did.
Some parts of this diff extracted from a diff by deraadt@
Pleas review and test.
-Otto
RCS file: /cvs/src/libexec/ld.so/dl_prebind.c,v
retrieving revision 1.13
diff -u -p -r1.13 dl_prebind.c
--- dl_prebind.c 13 Nov 2013 05:41:41 - 1.13
+++ dl_prebind.c 5 Jun 2014 11:22:35 -
@@ -200,7 +200,8 @@ prebind_symcache(elf_object_t *object, i
if (i = NUM_STATIC_OBJS) {
objarray = objarray_static[0];
} else {
-objarray = _dl_malloc(sizeof(elf_object_t *) * i);
+objarray = _dl_reallocarray(NULL,
+sizeof(elf_object_t *), i);
Nit, so please disregard if considered bikeshedding at this point, but for
style the sizeof and i should be switched.
/Alexander
Re: syncing libc and libkern
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 required to be in libc by the current C and POSIX standards.
Yes, that's correct. This doesn't remove str{cat,cpy} from libc
(haha, I wish that were possible), only removes it from the list
of things that are to be copied from libc to libkern.
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.
Re: syncing libc and libkern
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.
Patch: ifconfig - fix SIGSEGV
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=optimized out) at
/usr/src/lib/libc/string/strlcpy.c:37
#1 0x00413a45 in _fillhostent (h=0x200f7f800, r=0x84c620 _hostent,
buf=optimized out, len=4096) at /usr/src/lib/libc/asr/gethostnamadr.c:73
#2 0x00413ceb in _gethostbyname (h_errnop=optimized out,
buflen=optimized out, buf=optimized out, ret=optimized out, af=optimized
out,
name=optimized out) at /usr/src/lib/libc/asr/gethostnamadr.c:125
#3 gethostbyname2 (name=optimized out, af=2) at
/usr/src/lib/libc/asr/gethostnamadr.c:152
#4 0x0040ae78 in in_getaddr (s=0x7f7d6f93 -asdf, which=1) at
/usr/src/sbin/ifconfig/ifconfig.c:4556
#5 0x004019b4 in setifaddr (addr=0x7f7d6f93 -asdf, param=0) at
/usr/src/sbin/ifconfig/ifconfig.c:1112
#6 0x00400b01 in main (argc=1, argv=0x7f7d6d78) at
/usr/src/sbin/ifconfig/ifconfig.c:738
And here a patch that fixes the problem for me. Hope this is the right
place to errx().
Another thing i observed is that when calling ifconfig re0 awdawd
it behaves like calling ifconfig re0 up but i have not looked into
this.
Tested against -current amd64
Regards,
Fabian
Index: ifconfig.c
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
retrieving revision 1.283
diff -u -p -r1.283 ifconfig.c
--- ifconfig.c 12 May 2014 08:47:37 - 1.283
+++ ifconfig.c 5 Jun 2014 17:17:17 -
@@ -4552,14 +4552,15 @@ in_getaddr(const char *s, int which)
errx(1, %d: bad prefixlen, bits);
in_getprefix(p, MASK);
memcpy(sin-sin_addr, tsin.sin_addr, sizeof(sin-sin_addr));
- } else if (inet_aton(s, sin-sin_addr) == 0) {
+ } else if (inet_aton(s, sin-sin_addr) == 1) {
if ((hp = gethostbyname(s)))
memcpy(sin-sin_addr, hp-h_addr, hp-h_length);
else if ((np = getnetbyname(s)))
sin-sin_addr = inet_makeaddr(np-n_net, INADDR_ANY);
else
errx(1, %s: bad value, s);
- }
+ } else
+ errx(1, %s: bad value, s);
}
/* ARGSUSED */
Re: smtpd fixes backport
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 fixes to smtpd since 5.5
release. If you're using smtpd on 5.5, you probably want to apply them.
(My plan is to commit to stable eventually, but since it's very
important not to introduce regressions, I'm asking for a little help
testing the backport.)
++
fix writing of multiline To and Cc headers
issue spotted, fix tested and okayed krw@
++
fix header parsing issue in enqueuer leading to From: header being
stripped in some cases
ok eric@
++
when locally enqueuing messages without specifying a domain for sender
or recipient, the local domain is assumed. this was correctly handled
at the smtp level, but headers were not updated to reflect that.
issue experienced by several people, fix tested by ajacoutot@ and I
ok eric@
++
The enqueue utility should not add a User-Agent header to emails.
ok gilles jcs
Index: enqueue.c
===
RCS file: /cvs/src/usr.sbin/smtpd/enqueue.c,v
retrieving revision 1.75
diff -u -p -r1.75 enqueue.c
--- enqueue.c 4 Feb 2014 15:44:05 - 1.75
+++ enqueue.c 30 May 2014 19:59:19 -
@@ -159,6 +159,47 @@ qp_encoded_write(FILE *fp, char *buf, si
}
}
+static void
+send_header(FILE *fout, const char *line, size_t len)
+{
+ int i;
+
+ if (strncasecmp(To:, line, 3) != 0
+ strncasecmp(Cc:, line, 3) != 0
+ strncasecmp(Bcc:, line, 4) != 0
+ strncasecmp(From:, line, 5) != 0) {
+ send_line(fout, 0, %.*s, (int)len, line);
+ return;
+ }
+ if (len = sizeof pstate.buf) {
+ send_line(fout, 0, %.*s, (int)len, line);
+ return;
+ }
+
+ /* XXX
+ * To, Cc and Bcc may need rewrite, we can reuse the
+ * msg recipients field since former content has already
+ * been used at this point.
+ */
+ memset(pstate, 0, sizeof(pstate));
+ memcpy(pstate.buf, line, len);
+ pstate.buf[len] = 0;
+ pstate.wpos = len - 1;
+ msg.rcpts = NULL;
+ msg.rcpt_cnt = 0;
+
+ if (strncasecmp(From:, line, 5) == 0) {
+ parse_addr_terminal(1);
+ send_line(fout, 0, %s\n, msg.from);
+ }
+ else {
+ parse_addr_terminal(0);
+ for (i = 0; i msg.rcpt_cnt; ++i)
+ send_line(fout, 0, %s%s%s\n, i 0 ? \t : ,
+ msg.rcpts[i], i msg.rcpt_cnt - 1 ? , : );
+ }
+}
+
int
enqueue(int argc, char *argv[])
{
@@ -336,9 +377,6 @@ enqueue(int argc, char *argv[])
send_line(fout, 0, Content-Transfer-Encoding:
quoted-printable\n);
}
- if (!msg.saw_user_agent)
- send_line(fout, 0, User-Agent: %s enqueuer (%s)\n,
- SMTPD_NAME, Demoostik);
/* add separating newline */
if (noheader)
@@ -366,7 +404,10 @@ enqueue(int argc, char *argv[])
if (msg.saw_content_transfer_encoding || noheader ||
inheaders || !msg.need_linesplit) {
- send_line(fout, 0, %.*s, (int)len, line);
+ if (inheaders)
+ send_header(fout, line, len);
+ else
+ send_line(fout, 0, %.*s, (int)len, line);
if (inheaders buf[0] == '\n')
inheaders = 0;
continue;
--
Gilles Chehade
https://www.poolp.org @poolpOrg
new OpenSSL flaws
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. OpenBSD / LibreSSL did not receive any heads-up from OpenSSL. So hold on, we'll try to have errata out in a few hours.
Re: new OpenSSL flaws
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 (obviously) given a heads up to prepare them over the last few days. OpenBSD / LibreSSL did not receive any heads-up from OpenSSL. So hold on, we'll try to have errata out in a few hours. Theo, I'm just curious, but, this happened in the past? Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: new OpenSSL flaws
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 (obviously) given a heads up to prepare them over the last few days. OpenBSD / LibreSSL did not receive any heads-up from OpenSSL. So hold on, we'll try to have errata out in a few hours. Theo, I'm just curious, but, this happened in the past? Sure, it has happened in the past. But probably not to this degree. Some sort of timeline has been published. Read between the lines. http://seclists.org/oss-sec/2014/q2/466
Re: new OpenSSL flaws
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 available, but that is because they were (obviously) given a heads up to prepare them over the last few days. OpenBSD / LibreSSL did not receive any heads-up from OpenSSL. So hold on, we'll try to have errata out in a few hours. Theo, I'm just curious, but, this happened in the past? Sure, it has happened in the past. But probably not to this degree. Some sort of timeline has been published. Read between the lines. http://seclists.org/oss-sec/2014/q2/466 Hmmm, the first thing I did on that page was ctrl + f OpenBSD: not found. It's very interesting that this happened, to this degree as you mentioned, just after you guys forked OpenSSL. I've disable most of the daemons that use ssl in my systems, until this errata comes along. Don't hush it, specially since you guys didn't got notified of this. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: new OpenSSL flaws
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 known to good. Then if an asssement has been done, and it is determined to be important, disclosure occurs, of course after the commit is already public. Everyone including the vendors had the opportunity to get the information in a fair and equal way. - The other main process used by some open source groups, is to quarantine important repairs. A fix is firsst disclosed all affected parties, or at least the right concerned subset. This creates a delay before information availability, but the coordination is intended to provide a benefit. Everyone generally gets the information in a fair and equal way. Both processses have their place. Each software group has their own limitations and needs which will drive their selection. Is clear that the second process -- intending to also take an ethical path for disclosure -- should not specifically exclude a part of the community. Unfortunately I find myself believing reports that the OpenSSL people intentionally asked others for quarantine, and went out of their way to ensure this information would not come to OpenBSD and LibreSSL. There, I've said it.
Re: new OpenSSL flaws
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 a fix is commited as soon as the improvement is known to good. Then if an asssement has been done, and it is determined to be important, disclosure occurs, of course after the commit is already public. Everyone including the vendors had the opportunity to get the information in a fair and equal way. - The other main process used by some open source groups, is to quarantine important repairs. A fix is firsst disclosed all affected parties, or at least the right concerned subset. This creates a delay before information availability, but the coordination is intended to provide a benefit. Everyone generally gets the information in a fair and equal way. Both processses have their place. Each software group has their own limitations and needs which will drive their selection. Is clear that the second process -- intending to also take an ethical path for disclosure -- should not specifically exclude a part of the community. Unfortunately I find myself believing reports that the OpenSSL people intentionally asked others for quarantine, and went out of their way to ensure this information would not come to OpenBSD and LibreSSL. There, I've said it. 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 hidden agenda, in that this stupid disclosure was indeed, carefully planed. One can never have too many conspiracy theories. Specially after what has been happening the last year. Thanks for the clarification. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: new OpenSSL flaws
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 than a month ago by the way their #3317 bug was fixed, commiting a different fix from the proposed one and introducing a stupid *and obvious* bug in the process - which got fixed the next day after otto@ mentioned it to the OpenSSL developers). If you can't trust people to apply one-liner fixes correctly, can you trust them for anything serious? Miod
Re: new OpenSSL flaws
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 2006: http://www.gergely.risko.hu/debian-dsa1571.en.html
Re: LibreSSL SRP fix
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 didn't hurt that much and spared me having to wade through OpenSSL code, so I never investigated it. What makes me wonder a bit is that the documentation states: | In OpenSSL 0.9.7 and later if digest contexts are not cleaned up after | use memory leaks will occur. Obviously, this doesn't specify what cleaning up actually means, or whether this applies to statically/stack allocated or EVP_MD_CTX_create created contexts or both, or anything really helpful at all, but it might suggest that there is some dynamic allocation happening somewhere in there, which in turn could be a reason for failure? All those checks certainly don't help with clarity, and any avoidable need for error checks certainly would help with the robustness of the API, so I am all for throwing out unnecessary checks, I'd just like to be reasonably sure they are actually unnecessary ;-) However, I think maybe the free() and BN_clear_free() fixes are still applicable? The free() is just moved down to ensure it happens even in case one of the new error checks causes an early return, so it's not needed if those aren't needed. The BN_clear_free() fix is independent from that, yeah. Regards, Florian
Re: new OpenSSL flaws
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/oss-sec/2014/q2/233 Dear Anonymous, That discussion is unrelated. I made a personal statement that I did not wish to participate in another private mailing list, stating my reasons as clearly as I could. My personal participation in such a mailing list is very distinct from OpenSSL's social responsibility to inform - the 10+ developers working on LibreSSL (I am only a minor part of that sub-group). - the security-concerned sub-group of OpenBSD (I play a big part in that, but not in regards to the SSL subset, so at most I would have handed this to the LibreSSL subgroup) Dr. Henson of OpenSSL knew who to contact. The other members of the private mailing list were witness to the disclosure gap. The choice was made there. I cannot be held responsible for this lack of notification.
[PATCH] usr.sbin/pkg_add: rename Persistant to Persistent
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 willing to cook up another diff if nobody else is working on it
already.
Index: usr.sbin/pkg_add//Makefile
===
RCS file: /work/cvsroot/src/usr.sbin/pkg_add/Makefile,v
retrieving revision 1.80
diff -p -u -r1.80 Makefile
--- usr.sbin/pkg_add//Makefile 14 Apr 2014 10:56:11 - 1.80
+++ usr.sbin/pkg_add//Makefile 5 Jun 2014 21:43:04 -
@@ -35,7 +35,7 @@ PACKAGES= \
OpenBSD/PackageRepository.pm \
OpenBSD/PackageRepository/HTTP.pm \
OpenBSD/PackageRepository/Installed.pm \
-OpenBSD/PackageRepository/Persistant.pm \
+OpenBSD/PackageRepository/Persistent.pm \
OpenBSD/PackageRepository/SCP.pm \
OpenBSD/PackageRepository/Source.pm \
OpenBSD/PackageRepositoryList.pm \
Index: usr.sbin/pkg_add//OpenBSD/PackageRepository/HTTP.pm
===
RCS file: /work/cvsroot/src/usr.sbin/pkg_add/OpenBSD/PackageRepository/HTTP.pm,v
retrieving revision 1.11
diff -p -u -r1.11 HTTP.pm
--- usr.sbin/pkg_add//OpenBSD/PackageRepository/HTTP.pm 18 Mar 2014 18:53:29
- 1.11
+++ usr.sbin/pkg_add//OpenBSD/PackageRepository/HTTP.pm 5 Jun 2014 21:44:26
-
@@ -19,10 +19,10 @@
use strict;
use warnings;
-use OpenBSD::PackageRepository::Persistant;
+use OpenBSD::PackageRepository::Persistent;
package OpenBSD::PackageRepository::HTTP1;
-our @ISA = qw(OpenBSD::PackageRepository::Persistant);
+our @ISA = qw(OpenBSD::PackageRepository::Persistent);
sub urlscheme
{
return 'http';
Index: usr.sbin/pkg_add//OpenBSD/PackageRepository/Persistant.pm
===
RCS file: usr.sbin/pkg_add//OpenBSD/PackageRepository/Persistant.pm
diff -N usr.sbin/pkg_add//OpenBSD/PackageRepository/Persistant.pm
--- usr.sbin/pkg_add//OpenBSD/PackageRepository/Persistant.pm 18 Mar 2014
18:53:29 - 1.4
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,141 +0,0 @@
-# ex:ts=8 sw=4:
-# $OpenBSD: Persistant.pm,v 1.4 2014/03/18 18:53:29 espie Exp $
-#
-# Copyright (c) 2003-2014 Marc Espie es...@openbsd.org
-#
-# Permission to use, copy, modify, and distribute this software for any
-# purpose with or without fee is hereby granted, provided that the above
-# copyright notice and this permission notice appear in all copies.
-#
-# THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
-# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
-# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
-# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
-# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
-# ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
-# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
-
-use strict;
-use warnings;
-
-package OpenBSD::PackageRepository::Persistant;
-our @ISA=qw(OpenBSD::PackageRepository::Distant);
-
-our %distant = ();
-
-sub may_exist
-{
- my ($self, $name) = @_;
- my $l = $self-list;
- return grep {$_ eq $name } @$l;
-}
-
-sub grab_object
-{
- my ($self, $object) = @_;
-
- my $cmdfh = $self-{cmdfh};
- my $getfh = $self-{getfh};
-
- print $cmdfh ABORT\n;
- while ($getfh) {
- last if m/^ABORTED/o;
- }
- print $cmdfh GET , $self-{path}.$object-{name}..tgz, \n;
- close($cmdfh);
- $_ = $getfh;
- chomp;
- if (m/^ERROR:/o) {
- $self-{state}-fatal(transfer error: #1, $_);
- }
- if (m/^TRANSFER:\s+(\d+)/o) {
- my $buffsize = 10 * 1024;
- my $buffer;
- my $size = $1;
- my $remaining = $size;
- my $n;
-
- do {
- $n = read($getfh, $buffer,
- $remaining $buffsize ? $remaining :$buffsize);
- if (!defined $n) {
- $self-{state}-fatal(Error reading: #1, $!);
- }
- $remaining -= $n;
- if ($n 0) {
- syswrite STDOUT, $buffer;
- }
- } while ($n != 0 $remaining != 0);
- exit(0);
- }
-}
-
-sub maxcount
-{
- return 1;
-}
-
-sub opened
-{
- my $self = $_[0];
- my $k = $self-{host};
- if (!defined $distant{$k}) {
- $distant{$k} = [];
- }
- return $distant{$k};
-}
-
-sub list
-{
- my ($self) = @_;
- if (!defined $self-{list}) {
- if (!defined $self-{controller}) {
-
Re: new OpenSSL flaws
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 hidden agenda, in that this stupid disclosure was indeed, carefully planed. One can never have too many conspiracy theories. Specially after what has been happening the last year. Thanks for the clarification. Mark Cox claims that the reason OpenBSD was not told is because OpenBSD is not on the distros mailing list and if we were then they'd be able to work with other distros on issues in advance. It's at http://oss-security.openwall.org/wiki/mailing-lists/distros . Not saying I believe or disbelieve him, but it can't hurt to join even if it is only until 5.6 comes out. - Matthew Martin
Re: new OpenSSL flaws
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 hidden agenda, in that this stupid disclosure was indeed, carefully planed. One can never have too many conspiracy theories. Specially after what has been happening the last year. Thanks for the clarification. Mark Cox claims that the reason OpenBSD was not told is because OpenBSD is not on the distros mailing list and if we were then they'd be able to work with other distros on issues in advance. It's at http://oss-security.openwall.org/wiki/mailing-lists/distros . Not saying I believe or disbelieve him, but it can't hurt to join even if it is only until 5.6 comes out. That is an interesting claim. It sounds like we should test it, rather than take it as fact. Let's ask the right people. Kurt and Solar -- You are the primary contacts for the oss-security email list. Are you are aware of any operating system, product suppliers, or service providers who were notified early by OpenSSL... but are not found on the private mailing list? I think it would be poor style to ask for specific names, but a vague statement confirming or denying things would be nice. There are claims that attendance on your private email list is required sufficient for early disclosure from OpenSSL. Thanks in advance for any clarity you can supply to this question.
Re: new OpenSSL flaws
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 vendor who was in control of deciding where the notification would go. Right. That's a good one. I will not join that list. It would not have helped. I do not do work in SSL; there's 10 other people on our group who do that. Shall I send a request that all 10 of our SSL sub-group join that list, because there's a lot of SSL-related shit coming down the pipe soon? Heck, why don't they just let anyone join...
Re: new OpenSSL flaws
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 I felt the list was not being used for advanced disclosure in a practical means, I didn't see the reason for it. - but I would be open to it if it was being used for advanced disclosure.. my words on june 2 ended with: In a nutshell, I suppose I'm asking you - does this help if the list only gets notification at the same time, basically, as public release? Or are there some rules for participants? The reply I got said they couldn't give any details because there were not any - so obviously as of June 2, someone who was on and maintained that list did not feel that there was any need to be on the list for advance disclosure of bugs. For the record, we didn't get advance notice of Heartbleed either, so this is nothing new. On Thu, Jun 5, 2014 at 2:43 PM, Martin, Matthew phy1...@utdallas.edu 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. My real concern is if this something else, a hidden agenda, in that this stupid disclosure was indeed, carefully planed. One can never have too many conspiracy theories. Specially after what has been happening the last year. Thanks for the clarification. Mark Cox claims that the reason OpenBSD was not told is because OpenBSD is not on the distros mailing list and if we were then they'd be able to work with other distros on issues in advance. It's at http://oss-security.openwall.org/wiki/mailing-lists/distros . Not saying I believe or disbelieve him, but it can't hurt to join even if it is only until 5.6 comes out. - Matthew Martin
Re: new OpenSSL flaws
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 that someone else would also ask him that. Anyway, this kind of thing hurts the entire FLOSS movement. The whole point of writing a open source project is collaboration. It seems that OpenSSL took a step backward on this. Now, I wonder, if there won't be LibreSSL code appearing on OpenSSL. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: new OpenSSL flaws
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. My real concern is if this something else, a hidden agenda, in that this stupid disclosure was indeed, carefully planed. One can never have too many conspiracy theories. Specially after what has been happening the last year. Thanks for the clarification. Mark Cox claims that the reason OpenBSD was not told is because OpenBSD is not on the distros mailing list and if we were then they'd be able to work with other distros on issues in advance. The distros and linux-distros lists are a good way to contact *some* OS distributions and Amazon. http://oss-security.openwall.org/wiki/mailing-lists/distros But there are clearly a number of others for whom an OpenSSL bug would have big impact who are not on that list (OS such as OpenBSD and Apple, large scale hosting providers, etc). Many of these are listed on the security contacts page on the wiki, and actually, the page with information about sending to the distros list (which submitters cannot ignore as it has the required pgp key) says: Please notify upstream projects/developers of the affected software, other affected distro vendors link to http://oss-security.openwall.org/wiki/vendors, and/or affected Open Source projects before notifying one of these mailing lists in order to ensure that these other parties are OK with the maximum embargo period that would apply.
Re: new OpenSSL flaws
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 practical means of early disclosure. Nor were we informed it was anything beyond experimental. On 5 Jun 2014 17:39, Stuart Henderson s...@spacehopper.org wrote: 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. My real concern is if this something else, a hidden agenda, in that this stupid disclosure was indeed, carefully planed. One can never have too many conspiracy theories. Specially after what has been happening the last year. Thanks for the clarification. Mark Cox claims that the reason OpenBSD was not told is because OpenBSD is not on the distros mailing list and if we were then they'd be able to work with other distros on issues in advance. The distros and linux-distros lists are a good way to contact *some* OS distributions and Amazon. http://oss-security.openwall.org/wiki/mailing-lists/distros But there are clearly a number of others for whom an OpenSSL bug would have big impact who are not on that list (OS such as OpenBSD and Apple, large scale hosting providers, etc). Many of these are listed on the security contacts page on the wiki, and actually, the page with information about sending to the distros list (which submitters cannot ignore as it has the required pgp key) says: Please notify upstream projects/developers of the affected software, other affected distro vendors link to http://oss-security.openwall.org/wiki/vendors, and/or affected Open Source projects before notifying one of these mailing lists in order to ensure that these other parties are OK with the maximum embargo period that would apply.
Re: new OpenSSL flaws
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 claims all over the place regarding a list RUN BY YOU. FACT: Kurt Seifried and Solar Designer are the two primary operators of the openwall security list, the declared access point for security issues affecting Linux operating systems. There are claims being lodged that disclosure of these OpenSSL problems happened on that list. There are claims that we did not get this disclosure because OpenBSD is not on that list. Particularily me, Bob, and Todd Miller. Kurd, is that true? Is that how you see it? Were disclosures handled there, or via another platform or method? ANSWER THE QUESTION. If you won't answer this question, noone should ever trust you again for anything. I'm done playing games with you Theo. You were invited to join distros publicly and flamed me. I privately emailed Bob Beck inviting him to join, and he flamed me (but then apologized), You both said no. I can't do anything more. I wish you the best of luck in your future endeavors. I am not playing any games. Let's look at the facts. Kurd Seifried is an official Red Hat security officer (of sorts, but probably not tomorrow) Kurt, is Mark Cox your supervisor? A claim is being made that disclosure to OpenBSD needs to be on a Russian email list run by you (Kurt Seifried) and Solar Designer (not going to include his real name) for access to early disclosure of important security information. SO ANSWER THE FUCKING QUESTION, KURT. Or else, if you are a wimp, have your Mark Cox answer the fucking question. Red Hat and OpenSSL -- answer the fucking question. Why was the OpenBSD user community excluded from this information? Why are there public accusation -- from Red Hat officers -- that OpenBSD developers only get advance access to information if they join a Russian located email list? ps. Who is Mark Cox? I've never heard of him.
[no subject]
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.net (mother.openwall.net [195.42.179.200]) by cvs.openbsd.org (8.14.8/8.12.1) with SMTP id s564LjFg027340 for dera...@cvs.openbsd.org; Thu, 5 Jun 2014 22:21:46 -0600 (MDT) Received: (qmail 19629 invoked from network); 6 Jun 2014 04:21:39 - Received: from localhost (HELO 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...@cvs.openbsd.org Subject: Re: that private mailing list Message-ID: 20140606042105.gb26...@openwall.com References: 201406052157.s55lvh7j020...@cvs.openbsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 201406052157.s55lvh7j020...@cvs.openbsd.org User-Agent: Mutt/1.4.2.3i Hi Theo, I'll reply only in private first, because I am referring to the past discussion we had in private and that you didn't want to be made public. Also, please note that I wrote the below with no hard feelings, and I don't mean to offend you. I am just being sincere and direct. I think that is your preferred way to communicate, so I've adopted it. :-) On Thu, Jun 05, 2014 at 03:57:43PM -0600, Theo de Raadt wrote: I only know parts. It sound like some people who claim they stand up for what is right really don't stand up for what is right. 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. Now you're saying you actually wanted folks on your team to be notified, just not you personally. Hmm? As you had mentioned to me in the private discussion when stu@ wanted to get OpenBSD onto distros, you didn't want folks on your team to accept any kind of embargo. I wish we had that discussion in public, as I had suggested at the time. You objected to that. (And I understand that with that discussion in public you might not have been willing to blame some others in it, which would possibly hamper my understanding of your position. So your objection did make some sense.) Now you appear to be misinforming folks on your own team (I hope not intentionally) that those evil people on distros list and OpenSSL maintainers deliberately didn't want to notify you. You might be right about OpenSSL maintainers (although I think you are not) - I just don't know, and can't speak for them - but at least for me (as someone who was notified via distros list) it appeared that you actually didn't want your team to be notified in a manner that would impose any restrictions on when you can commit a fix. So, believe it or not, it didn't even occur to me to put your project in a position where your folks would be asked to accept an embargo, which you didn't want. Would you like me to suggest (to whoever reports an issue) that someone on your team (who?) be notified next time an OpenSSL issue is brought up on distros? (It doesn't have to be one person on your team - it can be several. This is to address Bob's comment on your lists.) What about issues in other projects (not OpenSSL)? Which other projects would you also like notifications about? It appears that you've made a (political) decision for your projects not to join distros (or possibly any such channels in general), but are now asking for people/projects to be notifying your folks anyway when appropriate (whatever that means), and this is difficult for everyone. How do you suggest we make things better (in whatever sense you like) going forward? /sd --- End of Forwarded Message
Re: new OpenSSL flaws
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; they don't give a sh*t about it (as shown less than a month ago by the way their #3317 bug was fixed, commiting a different fix from the proposed one and introducing a stupid *and obvious* bug in the process - which got fixed the next day after otto@ mentioned it to the OpenSSL developers). If you can't trust people to apply one-liner fixes correctly, can you trust them for anything serious? I think this Networkworld article says it all... (and since when did interesting, critical analysis come from Networkworld!?) http://www.networkworld.com/article/2360229/microsoft-subnet/critical-flaw-in-encryption-has-been-in-openssl-code-for-over-15-years.html If you don't think that Robin Seggelmann is a paid stooge actively trying to sabotage OpenSSL (an idea rooted in paranoia?) then you may at least think he is careless, unable to use critical thought, and certainly doesn't need commit access to any source code repository. Am I late to the party? Or is it time to re-audit every single character of his code? In the mean time, let Dr. Stephen N. Strangelove continue his mad plan to support VMS and Windows 3.1. Let him play games with LibreSSL competitors by denying advance notice. Perhaps next time Otto won't bother to inform them about their new stupid, obvious flaws in return? It's low class for Dr. Strangelove and his team to behave like this, after the many repetitive attempts from @openbsd.org to bring OpenSSL into the new century. OpenSSH became the de-facto standard because it was the only serious free alternative for a long time. OpenSSL has always been free. So the culture difference is precisely what will drive people for, or away from OpenSSL. (People from the culture of supporting ancient software and broken standards are going to choose OpenSSL every time!)
Re: that private mailing list
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 only via distros list, but at all. Now you're saying you actually wanted folks on your team to be notified, just not you personally. Hmm? Really? Let's see it. I'm questioning your judgment after reading the next bit. As you had mentioned to me in the private discussion when stu@ wanted to get OpenBSD onto distros, you didn't want folks on your team to accept any kind of embargo. I wish we had that discussion in public, as I had suggested at the time. You objected to that. (And I understand that with that discussion in public you might not have been willing to blame some others in it, which would possibly hamper my understanding of your position. So your objection did make some sense.) Now you appear to be misinforming folks on your own team (I hope not intentionally) that those evil people on distros list and OpenSSL maintainers deliberately didn't want to notify you. You might be right about OpenSSL maintainers (although I think you are not) - I just don't know, and can't speak for them - but at least for me (as someone who was notified via distros list) it appeared that you actually didn't want your team to be notified in a manner that would impose any restrictions on when you can commit a fix. So, believe it or not, it didn't even occur to me to put your project in a position where your folks would be asked to accept an embargo, which you didn't want. This reads like some kind of strange combination of arbitrary logic and reasoning to justify this in your own mind. Firstly, an embargo is crap and you know it. That implies a formal process with contracts and legal implications. (More plainly, did YOU sign?) A heads-up from OpenSSL to the key people is all it would have taken. (Sorry, I guess that's only appropriate when those key people aren't aiming at improving their shitty product.) Would you like me to suggest (to whoever reports an issue) that someone on your team (who?) be notified next time an OpenSSL issue is brought up on distros? (It doesn't have to be one person on your team - it can be several. This is to address Bob's comment on your lists.) What about issues in other projects (not OpenSSL)? Which other projects would you also like notifications about? It appears that you've made a (political) decision for your projects not to join distros (or possibly any such channels in general), but are now asking for people/projects to be notifying your folks anyway when appropriate (whatever that means), and this is difficult for everyone. How do you suggest we make things better (in whatever sense you like) going forward? Seriously? I think the situation here is PLAINLY OBVIOUS. Here in the real world, key OpenBSD members should be trusted to do the RIGHT THING in a typical situation like this. This isn't the first time this has happened nor the last time it will. Hopefully next time someone has common sense. I think we can all agree, OpenSSH has been successful at mitigating this same kind of problem with ALL of the other players. Maybe you need some coffee? Chris
