Re: new OpenSSL flaws
Em 07-06-2014 00:04, Solar Designer escreveu: > tools and ethics are separate things It seems like you got to the real issue now. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: Dumbing down the recent SSL stuff for users
Em 06-06-2014 22:11, patric conant escreveu: > So we knew that OpenSSL had some problems, indicated by the fact that they > were blissfully unaware that Valgrind gave warnings when compiling their > code, from the Debian debacle. They knew, just didn't care. > Then Heartbleed came along, and people knew > how bad things really were, and then members of the OpenBSD got together > and started working hard on cleaning up and auditing the OpenSSL codebase, > which lead to some other people going through through the changes for > indications as to what sort of vulnerabilities the original had. That > eventually lead to this most recent round of vulnerabilities which > professional courtesy dictated that the affected parties get enough time to > patch their offerings before public disclosure, except for the OpenBSD team. The cleanup didn't necessarily had anything to do with these disclosures. The fact is, that many people, not just OpenBSD developers, started actually looking the code. > > As a user I should probably just run snapshots to cut my window of > vulnerability as much as possible, for the foreseeable future, as this > problem's likely to get worse before it get's better, at the actual > inclusion of LibreSSL in OpenBSD. > > Does this sound right, did I miss some important subtleties? That depends on your requirements. Snapshots can sometimes be broken. It happens. Also, the it's hard to follow current. If you can, and can deal with the problems that come with it, then ok. If not, you might just follow stable. You don't even need to apply and compile the patches, if you trust the guys at mtier. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: new OpenSSL flaws
To clarify and for the record: Being on the distros list is not mandatory to receive advance notification of security issues. The list is just a tool. People reporting security issues to the distros list are encouraged to also "notify upstream projects/developers of the affected software, other affected distro vendors, and/or affected Open Source projects". OpenBSD having declined to use the tool shouldn't be interpreted e.g. by OpenSSL as a reason not to notify LibreSSL directly. I don't know if such reasons exist or not, but OpenBSD not being on distros is not it. I do think OpenBSD would benefit from using the tool, increasing the percentage of issues you do receive advance notification for, if you'd like that. However, tools and ethics are separate things. Alexander
Dumbing down the recent SSL stuff for users
Misc, So we knew that OpenSSL had some problems, indicated by the fact that they were blissfully unaware that Valgrind gave warnings when compiling their code, from the Debian debacle. Then Heartbleed came along, and people knew how bad things really were, and then members of the OpenBSD got together and started working hard on cleaning up and auditing the OpenSSL codebase, which lead to some other people going through through the changes for indications as to what sort of vulnerabilities the original had. That eventually lead to this most recent round of vulnerabilities which professional courtesy dictated that the affected parties get enough time to patch their offerings before public disclosure, except for the OpenBSD team. As a user I should probably just run snapshots to cut my window of vulnerability as much as possible, for the foreseeable future, as this problem's likely to get worse before it get's better, at the actual inclusion of LibreSSL in OpenBSD. Does this sound right, did I miss some important subtleties?
Re: new OpenSSL flaws
Le 06/06/2014 12:47, Eric Furman a écrit : > > On Fri, Jun 6, 2014, at 04:20 AM, Renaud Allard wrote: >> On 06/06/2014 05:18 AM, Eric Furman wrote: >>> On Thu, Jun 5, 2014, at 08:36 PM, Giancarlo Razzolini wrote: Em 05-06-2014 21:23, David Goldsmith escreveu: > Probably ipfilter > > http://christopher-technicalmusings.blogspot.com/2009/03/switching-firewalls-from-ipf-to-pf-on.html > If it is indeed ipfilter, I don't think OpenSSL will have the same fate. There is lots of money on it, and even more now, that the Linux Foundation is funding them directly. I believe that LibreSSL and OpenSSL will live alongside for a long time. >>> >>> That's a valid opinion, but as I said, I doubt it. >>> Vendors aren't stupid. With all that has happened lately, >>> given a choice the switch will not take long. >>> >>> >> Given a choice, perhaps. But some will stick with OpenSSL only because >> they want the money given by FIPS certification. >> > > This is a joke, right? I think you are sadly misinformed. > This is OPEN SOFTWARE. Vendors will choose the least problematic > software. > You are naive. Ah. > I think you underestimate the intelligence of SSL Vendors. > Free software is fantastic, we all benefit, but Vendors choose > the best solutions. Given the current circumstances > Libre.SSL WILL prevail. > > I HAD TO CHANGE MY PASSWORD AT ALL OF MY ONLINE BANKING ACCOUNTS! > THEY KNOW THAT OPENSSL IS SHIT! HOW LONG DO YOU THINK THEY WILL > CONTINUE TO USE SHITE FROM OPENSSL? > THEY ARE NOT STUPID! > Thank you > Because LibreSSL is bug-free? You think that in only 2 months LibreSSL has become the "least problematic" SSL software, and that everyone should use this instead of the usual "OpenSSL shit"? You are trying to convince us that LibreSSL is secure, and that if there's a bug, it's because of OpenSSL. I just find it a bit too easy, especially when most of the OpenSSL "shit" is included in LibreSSL. That, is great, naive joke. (and I'm not blaming LibreSSL)
standard FAQ procedure ... in chroot
Dear misc readers,
I try to understand why MAKEDEV is failing inside my chroot, while i
can manually create some dev with mknod .
Like:
SCRIPT ${DESTDIR}/dev/MAKEDEV dev/MAKEDEV
SPECIAL cd dev; sh MAKEDEV ramdisk
sh: [1]: mknod: console: Invalid argument
sh: [1]: mknod: tty: Invalid argument
AFAIK everything else is ok inside the CHROOT.
Help is welcome.
--
-
() ascii ribbon campaign - against html e-mail
/\
Re: debugging vio issue?
On Fri, Jun 6, 2014 at 12:27 PM, Giancarlo Razzolini wrote: > Em 06-06-2014 13:18, Christoph Borsbach escreveu: >> Hi, >> sorry, I don't know that, it's a VM at a hoster. I have no acces to the >> underlying host. > So, it could be a problem with the qemu/kvm version being a old one. > Mine is 2.0.0. > > Cheers, > > -- > Giancarlo Razzolini > GPG: 4096R/77B981BC > So i wanted to try the workaround ukc> change 199 199 vio* at virtio* flags 0x0 change [n] y flags [0] ? 2 on the previously broken : # uname -a # Linux raid 2.6.32-27-pve #1 SMP Tue Feb 11 16:18:29 CET 2014 x86_64 GNU/Linux # kvm --version # QEMU emulator version 1.7.0, Copyright (c) 2003-2008 Fabrice Bellard with last snapshot # uname -a OpenBSD bsd64.my.domain 5.5 GENERIC#167 amd64 i pkg_add iperf and if i used -d i encounter transfer problem between host and vm , yet my previous statement is somewhat true: host: Client connecting to 192.168.10.129, TCP port 5001 TCP window size: 57.1 KByte (default) [ 5] local 192.168.10.104 port 49871 connected with 192.168.10.129 port 5001 [ ID] Interval Transfer Bandwidth [ 5] 0.0-60.0 sec 0.00 ▒ ▒▒s 2459345519135549440 Bytes/sec best os ever: [ 9] 0.0-64.9 sec 17179869184 GBytes 2273912692 Gbits/sec [ 14] local 192.168.10.129 port 5001 connected with 192.168.10.104 port 49905 Waiting for server threads to complete. Interrupt again to force quit. [ 14] 0.0- 1.5 sec 48.1 KBytes 258 Kbits/sec -- - () ascii ribbon campaign - against html e-mail /\
Re: debugging vio issue?
Em 06-06-2014 13:18, Christoph Borsbach escreveu: > Hi, > sorry, I don't know that, it's a VM at a hoster. I have no acces to the > underlying host. So, it could be a problem with the qemu/kvm version being a old one. Mine is 2.0.0. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: debugging vio issue?
On Fri, Jun 06, 2014 at 11:23:12 -0300, Giancarlo Razzolini wrote: > Em 06-06-2014 09:31, Christoph Borsbach escreveu: > > Hello everyone, > > I just wanted to report that I too had this problem (sporadic hangs of the > > vio0-Interface) with 5.5-stable/amd64 in a KVM-VM. I tried the solution > > described by Philip Guenther and voilá, the problems are gone. I did no > > tests > > with regard to the performance, it seems alright. > > > > $ dmesg |grep vio > > vio0 at virtio0: RingEventIdx disabled by UKC: address > What is your underlying network in QEMU/KVM. I never had issues with vio > and I'm running 5.5 stable/amd64. I use it with macvtap on the host. And > some of them are isolated networks, where there is no hardware > interaction, it's all software based. I guess I'm lucky. Hi, sorry, I don't know that, it's a VM at a hoster. I have no acces to the underlying host. Regards, Christoph
Re: debugging vio issue?
On 06/06/2014 06:23 PM, Giancarlo Razzolini wrote: Em 06-06-2014 09:31, Christoph Borsbach escreveu: Hello everyone, I just wanted to report that I too had this problem (sporadic hangs of the vio0-Interface) with 5.5-stable/amd64 in a KVM-VM. I tried the solution described by Philip Guenther and voilá, the problems are gone. I did no tests with regard to the performance, it seems alright. $ dmesg |grep vio vio0 at virtio0: RingEventIdx disabled by UKC: address What is your underlying network in QEMU/KVM. I never had issues with vio and I'm running 5.5 stable/amd64. I use it with macvtap on the host. And some of them are isolated networks, where there is no hardware interaction, it's all software based. I guess I'm lucky. Cheers, QEMU/KVM Hi! In KVM-VM ( snapshot - 5 june) vio now can create vlans but they don't work properly. With e1000 driver in QEMU/KVM vlans works ok. Anyway thanks for vio ! Alex
Re: debugging vio issue?
On Fri, Jun 6, 2014 at 10:23 AM, Giancarlo Razzolini wrote: > Em 06-06-2014 09:31, Christoph Borsbach escreveu: >> Hello everyone, >> I just wanted to report that I too had this problem (sporadic hangs of the >> vio0-Interface) with 5.5-stable/amd64 in a KVM-VM. I tried the solution >> described by Philip Guenther and voilá, the problems are gone. I did no tests >> with regard to the performance, it seems alright. >> >> $ dmesg |grep vio >> vio0 at virtio0: RingEventIdx disabled by UKC: address > What is your underlying network in QEMU/KVM. I never had issues with vio > and I'm running 5.5 stable/amd64. I use it with macvtap on the host. And > some of them are isolated networks, where there is no hardware > interaction, it's all software based. I guess I'm lucky. > > Cheers, > > -- > Giancarlo Razzolini > GPG: 4096R/77B981BC > with proxmox 3 , if you load the link it stops working quickly. but the perf are amazing. -- - () ascii ribbon campaign - against html e-mail /\
Re: debugging vio issue?
Em 06-06-2014 09:31, Christoph Borsbach escreveu: > Hello everyone, > I just wanted to report that I too had this problem (sporadic hangs of the > vio0-Interface) with 5.5-stable/amd64 in a KVM-VM. I tried the solution > described by Philip Guenther and voilá, the problems are gone. I did no tests > with regard to the performance, it seems alright. > > $ dmesg |grep vio > vio0 at virtio0: RingEventIdx disabled by UKC: address What is your underlying network in QEMU/KVM. I never had issues with vio and I'm running 5.5 stable/amd64. I use it with macvtap on the host. And some of them are isolated networks, where there is no hardware interaction, it's all software based. I guess I'm lucky. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: new OpenSSL flaws
Em 06-06-2014 10:55, Dan Becker escreveu: > As a simple user who influences these decisions in deployments, I can > tell you my desire is to ssh tunnel all my openssl connections until > the guys who make SSH finish fixing ssl. > > Look at SSH's track record compared to OpenSSL. > > It's not practical but that is my desire :) And how tunneling your ssl connections through ssh, helps you? The heartbleed bug was both server and client side. These new bugs from yesterday, some of them are both server and client side. Tunneling your ssl connections with ssh isn't going to help you. Yes, the OpenSSH track record is way better than OpenSSL's. I might be wrong, and I hope to be. But I suspect it will be a bumpy ride for a while using either LibreSSL or OpenSSL. OpenSSL will be hopefully bumpier than LibreSSL's. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: new OpenSSL flaws
Giancarlo Razzolini wrote: Writing in caps doesn't make your assumption correct. I'd really like that everybody would switch to LibreSSL. But It will not be as simple as you are putting. First of all, there are lots of money involved. And now, even more, because the Linux Foundation is funding OpenSSL. So, there are politics involved also. And, unfortunately, I believe that LibreSSL will share some of the bugs of OpenSSL for some time to come. And, don't fool yourself, it will have new bugs. I had to change lots of passwords too, so I know what you're talking about. Funny thing, that I didn't needed to change any of my banking passwords. Cheers, As a simple user who influences these decisions in deployments, I can tell you my desire is to ssh tunnel all my openssl connections until the guys who make SSH finish fixing ssl. Look at SSH's track record compared to OpenSSL. It's not practical but that is my desire :) --Dan
Re: new OpenSSL flaws
On 6 June 2014 14:38, Giancarlo Razzolini wrote: > Em 06-06-2014 07:47, Eric Furman escreveu: > ... > talking about. Funny thing, that I didn't needed to change any of my > banking passwords. I don't know what, if anything, you're implying there. Banks are generally conservative places IT-wise, and I suspect that in many cases they were simply running old versions of OpenSSL that weren't affected by Heartbleed. I know for a fact that that is the case for at least one fairly big bank. This current problem, of course, goes back to older versions of OpenSSL so there's a lot more work to be done. -Andre
Re: new OpenSSL flaws
Em 06-06-2014 07:47, Eric Furman escreveu: > This is a joke, right? I think you are sadly misinformed. > This is OPEN SOFTWARE. Vendors will choose the least problematic > software. > You are naive. > I think you underestimate the intelligence of SSL Vendors. > Free software is fantastic, we all benefit, but Vendors choose > the best solutions. Given the current circumstances > Libre.SSL WILL prevail. > > I HAD TO CHANGE MY PASSWORD AT ALL OF MY ONLINE BANKING ACCOUNTS! > THEY KNOW THAT OPENSSL IS SHIT! HOW LONG DO YOU THINK THEY WILL > CONTINUE TO USE SHITE FROM OPENSSL? > THEY ARE NOT STUPID! > Thank you Writing in caps doesn't make your assumption correct. I'd really like that everybody would switch to LibreSSL. But It will not be as simple as you are putting. First of all, there are lots of money involved. And now, even more, because the Linux Foundation is funding OpenSSL. So, there are politics involved also. And, unfortunately, I believe that LibreSSL will share some of the bugs of OpenSSL for some time to come. And, don't fool yourself, it will have new bugs. I had to change lots of passwords too, so I know what you're talking about. Funny thing, that I didn't needed to change any of my banking passwords. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: new OpenSSL flaws
Hi, Since I've seen many commits yesterday on cvs@ and no errata yet, I'd like to ask if the current snapshots (05/06/2014) are updated with the patches in question? Should we wait for more to come or are these adequate? Specificaly i386/ (base55.tgz) = 8abfa9412a017e04ca6ff4f49a27d2dacd750493901e253a06de19c051073306 59303662 Jun 5 14:06 i386/base55.tgz amd64/ (base55.tgz) = d50a32f44cf0e1062311daebe435c0829556965ce12457dc21d4a7269d489186 64040035 Jun 5 14:39 amd64/base55.tgz which are listed now on ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/ thanks, Giannis
Re: new OpenSSL flaws
On 06/06/14 15:24, Markus Rosjat wrote: Let's hope then that when LibreSSL is in production it will not share the same vulnerabilities with OpenSSL. Otherwise, what's the point? G well I don't know much but the point in removing 90k of c code lines from something that is messed up means to make it more solid but that's just my point of view and I'm just a dummy It is something, but removal of windows/obsolete OS code does not make crypto, protocols and design stronger. It sure makes it easier to parse and correct/audit various parts of the code. Anyway I'm not putting flames on LibreSSL project here. I too hope it becomes a better product than OpenSSL and also that it will not share the same vulnerabilities. G
Re: bash(1) 'read -n 1' in ksh(1)?
Hello Patrick, All, pkesh...@gmail.com (patrick keshishian), 2014.06.04 (Wed) 12:02 (CEST): > On 6/4/14, Marcus MERIGHI wrote: > > Hello, > > > > In my attempts to write a simple script that lets the user select > > options with a single key stroke I found no other way than to use bash > > and its built-in read command with -n 1. > > > > I am looking for a way to do this in ksh(1). Any ideas? Please... > > maybe something like this: works, and feels a little bit deeper down the rabbit hole than I could go myself. Thanks so much for taking me there! Bye, Marcus > --- 8< --- > #!/bin/sh > > # TODO handle signals! > stty -icanon > > # ask question > echo "1. Sing a song." > echo "2. Read a book." > echo "3. Go to sleep." > echo -n "Make a choice: " > # read answer > ans=`dd count=1 2>/dev/null` > > # TODO validation > > # print answer > echo "" > echo "ans=$ans" > > # reset > stty icanon > --- >8 --- > > --patrick > > > > Some snippets from the bash(1) man page: > > > > read [-ers] [-a aname] [-d delim] [-i text] [-n nchars] [-N nchars] [-p > > prompt] [-t timeout] [-u fd] [name ...] > > One line is read from the standard input, or from the file [...] > > -n nchars > > read returns after reading nchars characters rather than > > waiting for a complete line of input, but honor a > > delimiter if fewer than nchars characters are read > > before the delimiter. > > > > Thanks in advance, Marcus > > > !DSPAM:538eef49152732022416572!
Re: debugging vio issue?
On Wed, May 28, 2014 at 11:37:54 -0700, Philip Guenther wrote: > On Wed, May 28, 2014 at 11:26 AM, Adam Thompson wrote: > > > Don't have a good answer for you, but I have similar problems with vio(4). > > Switching to e1000 on the KVM side solved my random hangs completely. > > > > The vio(4) manpage mentions > Setting flags to 0x02 disables the RingEventIndex feature. This can be > tried as a workaround for possible bugs in host implementations or vio > at > the cost of slightly reduced performance. > > Have any of you tested that to see whether it improves the situation? Hello everyone, I just wanted to report that I too had this problem (sporadic hangs of the vio0-Interface) with 5.5-stable/amd64 in a KVM-VM. I tried the solution described by Philip Guenther and voilá, the problems are gone. I did no tests with regard to the performance, it seems alright. $ dmesg |grep vio vio0 at virtio0: RingEventIdx disabled by UKC: address Thanks and have a nice day, Christoph
Re: new OpenSSL flaws
Am 06.06.2014 14:15, schrieb Kapetanakis Giannis: On 06/06/14 14:49, Dmitrij D. Czarkoff wrote: Eric Furman said: Given the current circumstances Libre.SSL WILL prevail. I hope you are right, but I actually believe that the circumstances of this thread may work against LibreSSL - most likely the time difference between vulnerability disclosure and patches for LibreSSL would be percieved as security risk. Let's hope then that when LibreSSL is in production it will not share the same vulnerabilities with OpenSSL. Otherwise, what's the point? G well I don't know much but the point in removing 90k of c code lines from something that is messed up means to make it more solid but that's just my point of view and I'm just a dummy -- Markus Rosjatfon: +49 351 8107223mail: ros...@ghweb.de G+H Webservice GbR Gorzolla, Herrmann Königsbrücker Str. 70, 01099 Dresden http://www.ghweb.de fon: +49 351 8107220 fax: +49 351 8107227 Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before you print it, think about your responsibility and commitment to the ENVIRONMENT
Re: new OpenSSL flaws
On 06/06/14 14:49, Dmitrij D. Czarkoff wrote: Eric Furman said: Given the current circumstances Libre.SSL WILL prevail. I hope you are right, but I actually believe that the circumstances of this thread may work against LibreSSL - most likely the time difference between vulnerability disclosure and patches for LibreSSL would be percieved as security risk. Let's hope then that when LibreSSL is in production it will not share the same vulnerabilities with OpenSSL. Otherwise, what's the point? G
Re: new OpenSSL flaws
Eric Furman said: > Given the current circumstances Libre.SSL WILL prevail. I hope you are right, but I actually believe that the circumstances of this thread may work against LibreSSL - most likely the time difference between vulnerability disclosure and patches for LibreSSL would be percieved as security risk. -- Dmitrij D. Czarkoff
Re: new OpenSSL flaws
On 06/06/2014 12:47 PM, Eric Furman wrote: > > That's a valid opinion, but as I said, I doubt it. > Vendors aren't stupid. With all that has happened lately, > given a choice the switch will not take long. > > >> Given a choice, perhaps. But some will stick with OpenSSL only because >> they want the money given by FIPS certification. >> > This is a joke, right? I think you are sadly misinformed. > This is OPEN SOFTWARE. Vendors will choose the least problematic > software. > You are naive. > I think you underestimate the intelligence of SSL Vendors. > Free software is fantastic, we all benefit, but Vendors choose > the best solutions. Given the current circumstances > Libre.SSL WILL prevail. > > I HAD TO CHANGE MY PASSWORD AT ALL OF MY ONLINE BANKING ACCOUNTS! > THEY KNOW THAT OPENSSL IS SHIT! HOW LONG DO YOU THINK THEY WILL > CONTINUE TO USE SHITE FROM OPENSSL? > THEY ARE NOT STUPID! > Thank you Let's say, I hope you are right and I am wrong. I don't believe in FIPS for cryptography, but commercial entities might have a hard time removing themselves from a market. BTW, in my country, for all banks I know, you need to enter an OTP for each transaction you do online As said: I hope you are right and I am wrong. [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: new OpenSSL flaws
On Fri, Jun 6, 2014, at 04:20 AM, Renaud Allard wrote: > On 06/06/2014 05:18 AM, Eric Furman wrote: > > On Thu, Jun 5, 2014, at 08:36 PM, Giancarlo Razzolini wrote: > >> Em 05-06-2014 21:23, David Goldsmith escreveu: > >>> Probably ipfilter > >>> > >>> > >> http://christopher-technicalmusings.blogspot.com/2009/03/switching-firewalls-from-ipf-to-pf-on.html > >>> > >> If it is indeed ipfilter, I don't think OpenSSL will have the same fate. > >> There is lots of money on it, and even more now, that the Linux > >> Foundation is funding them directly. I believe that LibreSSL and OpenSSL > >> will live alongside for a long time. > > > > That's a valid opinion, but as I said, I doubt it. > > Vendors aren't stupid. With all that has happened lately, > > given a choice the switch will not take long. > > > > > Given a choice, perhaps. But some will stick with OpenSSL only because > they want the money given by FIPS certification. > This is a joke, right? I think you are sadly misinformed. This is OPEN SOFTWARE. Vendors will choose the least problematic software. You are naive. I think you underestimate the intelligence of SSL Vendors. Free software is fantastic, we all benefit, but Vendors choose the best solutions. Given the current circumstances Libre.SSL WILL prevail. I HAD TO CHANGE MY PASSWORD AT ALL OF MY ONLINE BANKING ACCOUNTS! THEY KNOW THAT OPENSSL IS SHIT! HOW LONG DO YOU THINK THEY WILL CONTINUE TO USE SHITE FROM OPENSSL? THEY ARE NOT STUPID! Thank you
Re: new OpenSSL flaws
On 06/06/2014 05:18 AM, Eric Furman wrote: On Thu, Jun 5, 2014, at 08:36 PM, Giancarlo Razzolini wrote: Em 05-06-2014 21:23, David Goldsmith escreveu: Probably ipfilter http://christopher-technicalmusings.blogspot.com/2009/03/switching-firewalls-from-ipf-to-pf-on.html If it is indeed ipfilter, I don't think OpenSSL will have the same fate. There is lots of money on it, and even more now, that the Linux Foundation is funding them directly. I believe that LibreSSL and OpenSSL will live alongside for a long time. That's a valid opinion, but as I said, I doubt it. Vendors aren't stupid. With all that has happened lately, given a choice the switch will not take long. Given a choice, perhaps. But some will stick with OpenSSL only because they want the money given by FIPS certification.
Re: that private mailing list
I've dropped CC to secur...@redhat.com, secur...@yandex.ru from this reply, because I don't feel like spamming them. I kept the CC to to...@yandex-team.ru, who I know is an OpenBSD user. On Thu, Jun 05, 2014 at 10:57:56PM -0600, Theo de Raadt wrote: > Solar and Kurt, a few questions: I think you shouldn't be addressing these to Kurt - at least not any more than to anyone else who's active on oss-security and distros. > Your one-word answers to the following questions will decide your > reputation regarding open source security, my reputation regarding > open source security, or the reputation of others. I participate in this discussions primarily for reasons unrelated to anyone's reputation. I think it's impossible to provide useful yes/no answers to your questions, but since you asked for those so explicitly, I'll try to provide both (mostly useless) yes/no answers (based on formal interpretation of your questions), as well as hopefully more useful longer answers. > 1. Was full and complete advance disclosure of this issue >managed via your list? > >Answer yes or no. One word. "Yes", assuming that the word "managed" applies to Mark's notification that we can request the full detail from him explicitly. > 2. Previous to this morning, were you aware that OpenBSD was not >receiving this information? > >Answer yes or no. One word. "No", I was not aware, but given our past discussion I (personally) thought you wouldn't want to receive it under an embargo. So frankly even if I were aware, I would probably not be alarmed if I heard that you were not being notified. I think this will be different now that you seem to have expressed a different preference. > 3. In your hearts, do you believe that a subtantial subset of open source >OS users, via their vendor contacts, should ever accept a late delivery >of information for any reason? > >Answer yes or no. One word. I wish it could have been a "no", but that's too idealistic. So it's arguably "yes", because the world is large and not perfect, and sometimes balanced decisions need to be made - e.g., I respect one's preference not to be subjected to an embargo vs. giving them a chance to prepare for the public disclosure in advance. I guess your users care not only about receiving security patches timely, but also about your position on larger issues - such as whether embargoes should even exist. I wouldn't be surprised if a substantial subset of your users (so a subset of a subset of the open source software users at large) would accept a delayed patch for the reason of OpenBSD maintaining a stance against advance notifications (if you/they believe those are more bad than good). Especially given that OpenBSD is able to patch issues really fast, and the delay ends up being small. So your decision (or so I thought) not to receive advance notification didn't sound too unreasonable to me (for your project). > 4. Were you party to a late disclosure to OpenBSD? > >Answer yes or no. One word. Are you asking if I contributed to the disclosure to OpenBSD being late? By my inaction, "yes", and I've explained why I did not act. The same could apply to anyone else who was notified in advance, but did not ask for a notification to OpenBSD to be made. I do accept that my responsibility may be greater due to me hosting the distros list. > I wish it wasn't this way, but when were OpenBSD users asked their > point of view regarding their security? I don't know. I guess it's primarily your task, as a leader, to ask them how they'd like the balance between "timely patches" and "anti-embargo stance" adjusted. > Right now, I am asking for an account of who caused them to not know > at the same time as others. There were multiple events leading to this. In my case, the most important event was that Jan-Feb 2012 discussion we had - but this definitely doesn't explain why others did not notify you. Alexander
