Theo de Raadt on OpenSSL vulnerabilities coming on the 19th(marc.info)
marc.info
Theo de Raadt on OpenSSL vulnerabilities coming on the 19th
http://marc.info/?l=openbsd-misc&m=142654095813320&w=2
72 comments
> The OpenSSL group do not tell the LibreSSL group about vulnerabilities
that they are fixing in upcoming releases.
> Why? Well, they just don't. That's the whole story.
Then the story sucks, security of core components underlying the internet is bigger than any one group.
Respect for end users would indicate that a simple heads up of a high severity bug to someone on the LibreSSL team would be the way to go.
> Why? Well, they just don't. That's the whole story.
Then the story sucks, security of core components underlying the internet is bigger than any one group.
Respect for end users would indicate that a simple heads up of a high severity bug to someone on the LibreSSL team would be the way to go.
Well, according to (also unsourced, so no clue what the "real" story is) comments on the sister submisson [1] it is because LibreSSL doesn't want to take part in the embargo on reported vulnerabilities.
[1] https://news.ycombinator.com/item?id=9216815
[1] https://news.ycombinator.com/item?id=9216815
That's because they patch within a couple of days and don't want their systems unpatched for long (30 to 60 days!) when there is a known issue out in the wild. The flaws tend to get leaked, the temptation is big because there are huge money incentives.
I bet if the embargo were for 5 days they would reconsider. But good luck with that with members like Microsoft, Cisco, Oracle, which a terrible reputation of postponing things the maximum possible.
I bet if the embargo were for 5 days they would reconsider. But good luck with that with members like Microsoft, Cisco, Oracle, which a terrible reputation of postponing things the maximum possible.
> I bet if the embargo were for 5 days they would reconsider.
Here's a page describing the list in question:
http://oss-security.openwall.org/wiki/mailing-lists/distros
Here's the embargo policy:
> Please note that the maximum acceptable embargo period for issues disclosed to these lists is 14 to 19 days .... In fact, embargo periods shorter than 7 days are preferable.
Here's a page describing the list in question:
http://oss-security.openwall.org/wiki/mailing-lists/distros
Here's the embargo policy:
> Please note that the maximum acceptable embargo period for issues disclosed to these lists is 14 to 19 days .... In fact, embargo periods shorter than 7 days are preferable.
19 days is an eternity for a security-oriented OS aimed at critical infrastructure like firewalls and proxies.
19 days is nothing compared to how long it has taken non-linux firewall and proxy vendors to patch things in the past.
Makes you wonder why people buy those products.
And a lot of those vendors just never do. And a lot of users never update anyway. There's no reason to keep my enterprise servers insecure because Johnny Linksys doesn't have a patch that he's never going to install anyway.
It's not "in the wild."
OpenBSD is making the gamble that either a) they can pressure the adults doing coordinated disclosure to stop doing that via their excellent people skills, or b) that they are so awesome that they can find the problems before everyone else.
NB: I love OpenBSD from a security POV, but that doesn't mean what the leaders of the project do is always correct for security.
OpenBSD is making the gamble that either a) they can pressure the adults doing coordinated disclosure to stop doing that via their excellent people skills, or b) that they are so awesome that they can find the problems before everyone else.
NB: I love OpenBSD from a security POV, but that doesn't mean what the leaders of the project do is always correct for security.
We mostly don't know if it is already "in the wild" or not, if it will be found independently during the embargo period, if it will leak out of one of the organizations "in the know", ...
Didn't people find traces of hearthbleed attacks that happened months before it was published?
There are good arguments for very short embargo periods, especially if you mostly care about the security of your users. (of course, in a perfect world every vendor would be willing/able to release patches after 24 h or so, and it wouldn't matter, but we don't have one of those...)
Didn't people find traces of hearthbleed attacks that happened months before it was published?
There are good arguments for very short embargo periods, especially if you mostly care about the security of your users. (of course, in a perfect world every vendor would be willing/able to release patches after 24 h or so, and it wouldn't matter, but we don't have one of those...)
It's hardly just OpenBSD. Read Al Viro's comment to http://lwn.net/Articles/601958/ He notes that Linus left the list due to the same policy.
So what about having the dinosaurs sort out and coordinate release dates initially, then giving a few days heads up to LibreSSL (and others).
At least it would minimize the risk of zero-daying LibreSSL users.
... but I guess, this isn't where the problem is?
At least it would minimize the risk of zero-daying LibreSSL users.
... but I guess, this isn't where the problem is?
That is true. OpenBSD/Theo refuses to take part in embargos, which means they don't get a heads up. Don't have a citation right now, but Theo said that publicly when Hardbleed or so happened.
Not true.
In which case and assuming that is accurate then
> Why? Well, they just don't. That's the whole story.
Could have been
> Why? Well, we'd have liked to but they don't embargo reported bugs and we do.
Clearer for everyone.
Assuming it's true.
> Why? Well, they just don't. That's the whole story.
Could have been
> Why? Well, we'd have liked to but they don't embargo reported bugs and we do.
Clearer for everyone.
Assuming it's true.
Wouldn't that be "they embargo reported bugs and we don't"? (Or at least, I suspect LibreSSL wants to keep to its own embargo schedule.)
> > Why? Well, they just don't. That's the whole story.
It's not the whole story. Here's the whole story:
http://lwn.net/Articles/601958/
"As it turns out, de Raadt had been asked if he wanted to join the distros list back in early May."
"[de Raadt:] So I'll decline."
It's not the whole story. Here's the whole story:
http://lwn.net/Articles/601958/
"As it turns out, de Raadt had been asked if he wanted to join the distros list back in early May."
"[de Raadt:] So I'll decline."
Way to cherry pick of a cherry picking. Theo meant he has no time to join yet another mailing list where OpenSSL security issues are very likely way less an 1% of the messages. Also, it's a Linux mailing list and he maintains a BSD distro, not much in common. I remember back in 98 he said he processed about 2500 emails a day (using a custom set of emacs macros). "I'm more an email processing system than a developer, sigh" (paraphrasing)
Why can't OpenSSL have an simple early warning list like most other major software packages. It's only adding one CC field.
Why can't OpenSSL have an simple early warning list like most other major software packages. It's only adding one CC field.
It would be nice if he'd said that, rather than "Well, they just don't." which completely misrepresents the situation. AFAIK, he has never requested such a thing, anyway. The only requests I see come from third party apologists, not from him.
He just complains that they don't give him access, when in fact they offered him access.
> Theo meant he has no time to join yet another mailing list where OpenSSL security issues are very likely way less an 1% of the messages.
Is it really that hard to filter for /openssl/i/?
He just complains that they don't give him access, when in fact they offered him access.
> Theo meant he has no time to join yet another mailing list where OpenSSL security issues are very likely way less an 1% of the messages.
Is it really that hard to filter for /openssl/i/?
We asked for advance notice in the past. We received advance notice in the past. This time we didn't. Now we did, again.
[deleted]
Is it really that hard to have a vulnerabilities mailer for important stuff?
You've just described the mailing list that de Raadt refuses to join.
From the context, it sounds like he was asked to join a linux distro security mailer, which wouldn't make sense. Isn't there an OpenSSL mailer for this stuff?
There are two lists: linux-distros and distros, the latter including FreeBSD and NetBSD. (Why is OpenSolaris - or whatever it's called this year - not in there too?)
Nevertheless, it should be doable for OpenSSL to also mail LibreSSL; it is a bit of a special case, after all.
Nevertheless, it should be doable for OpenSSL to also mail LibreSSL; it is a bit of a special case, after all.
To me it seems mostly a difference in principles. If OpenSSL and others work with embargoes and LibreSSL/OpenBSD doesn't accept them, there is no solution that satisfies both sides.
The amount of mails sounds like a strange argument to me. I can't imagine that they couldn't find one of the regular consumers of the mailing list willing to pass relevant ones on, assuming it were clear that LibreSSL is an accepted recipient of the information.
That said, I don't expect much in the way of goodwill or willingness to compromise on any side here.
The amount of mails sounds like a strange argument to me. I can't imagine that they couldn't find one of the regular consumers of the mailing list willing to pass relevant ones on, assuming it were clear that LibreSSL is an accepted recipient of the information.
That said, I don't expect much in the way of goodwill or willingness to compromise on any side here.
To me it seems mostly a difference in principles. If OpenSSL and others work with embargoes and LibreSSL/OpenBSD doesn't accept them, there is no solution that satisfies both sides.
Indeed, this is the main point, OpenBSD developers are proponents of full-disclosure:
http://www.openbsd.org/security.html
This paragraph summarizes it very well:
Security information moves very fast in cracker circles. On the other hand, our experience is that coding and releasing of proper security fixes typically requires about an hour of work -- very fast fix turnaround is possible. Thus we think that full disclosure helps the people who really care about security.
Indeed, this is the main point, OpenBSD developers are proponents of full-disclosure:
http://www.openbsd.org/security.html
This paragraph summarizes it very well:
Security information moves very fast in cracker circles. On the other hand, our experience is that coding and releasing of proper security fixes typically requires about an hour of work -- very fast fix turnaround is possible. Thus we think that full disclosure helps the people who really care about security.
> Also, it's a Linux mailing list and he maintains a BSD distro, not much in common.
No, you're thinking of linux-distros@. linux-distros@ is where issues that affect Linux only go. distros@ covers issues that are relevant to both BSD and Linux - distros@ membership is FreeBSD+NetBSD+linux-distros@.
No, you're thinking of linux-distros@. linux-distros@ is where issues that affect Linux only go. distros@ covers issues that are relevant to both BSD and Linux - distros@ membership is FreeBSD+NetBSD+linux-distros@.
I must be missing something, because I don't understand what's so difficult about filtering out the irrelevant emails.
[deleted]
This argument has always bugged me. Even if the mailing list was openssl-private-security-announce-embargoed (which it isn't), shouldn't openssl still attempt to identify and notify the large downstream consumers of openssl even if they're not on the list?
This mailing list conversation sounds like a cartoon bureaucrat saying "Well, I'd LOVE to help you, but you didn't tick checkbox 16-A on your X-23 form last week."
This mailing list conversation sounds like a cartoon bureaucrat saying "Well, I'd LOVE to help you, but you didn't tick checkbox 16-A on your X-23 form last week."
The distros list works on the principle that, at least in part, it's about people who are participating in the security-fix process. Of course some of the benefit is you get to stage your fixes early, but you also agree to be another set of eyes on the patch, run your local build and regression tests, etc. If someone brings an issue to the distros list without a patch, the patch needs to get written by someone. And so forth.
My employer repackages Ubuntu into a virtual appliance, but since we're firmly downstream and haven't yet had the time to get deeply involved in upstream security work, we're not allowed on the distros list. (We haven't asked, but the policy is pretty clear.) I think that's pretty fair, even if I personally dislike that end result.
See for instance, the disastrous handling around Shellshock, where no details were given on the distros list, the announcement went public, and it took a few days (in public) for people, mostly people on distros@, to realize that the patch was incomplete and two more patches were needed. It's not clear the distros list worked any better than a public announcement would have.
The other argument is that embargoes always get harder to enforce as you add more people to them. The distros list is the successor of the old vendor-sec list, which was more lenient about membership and always had suspicions of leaks (until someone broke into the mail server....). See, for instance, the messy handling of Heartbleed's embargo:
http://www.theage.com.au/it-pro/security-it/heartbleed-discl...
I think that if there's going to be a private disclosure process at all, it's better that it's bureaucratic instead of friends telling their friends at CloudFlare and Akamai, under the table, that they should patch.
My employer repackages Ubuntu into a virtual appliance, but since we're firmly downstream and haven't yet had the time to get deeply involved in upstream security work, we're not allowed on the distros list. (We haven't asked, but the policy is pretty clear.) I think that's pretty fair, even if I personally dislike that end result.
See for instance, the disastrous handling around Shellshock, where no details were given on the distros list, the announcement went public, and it took a few days (in public) for people, mostly people on distros@, to realize that the patch was incomplete and two more patches were needed. It's not clear the distros list worked any better than a public announcement would have.
The other argument is that embargoes always get harder to enforce as you add more people to them. The distros list is the successor of the old vendor-sec list, which was more lenient about membership and always had suspicions of leaks (until someone broke into the mail server....). See, for instance, the messy handling of Heartbleed's embargo:
http://www.theage.com.au/it-pro/security-it/heartbleed-discl...
I think that if there's going to be a private disclosure process at all, it's better that it's bureaucratic instead of friends telling their friends at CloudFlare and Akamai, under the table, that they should patch.
I have always hated embargoes for things like that because they end up benefitting the worst companies - the big ones - over the people who actually need the help.
Yeah, but based on the work of the LibreSSL team http://opensslrampage.org/ I wouldn't use OpenSSL for anything else if possible
OpenBSD's scorched earth policy regarding OpenSSL is so anti-community it's ridiculous. OpenSSL served the entire internet for years. I'm happy that it's been forked - nice that could even happen at all - and some of the cruft responsible for the recent flood of exploits will be fixed/removed, but the hate just seems petty.
What's petty about removing bad code? If someone came into your (work or FOSS) project and just started removing code at the clip they were, you'd probably be extremely upset. At best, it would take way too long to get the approvals by the community. They made the decision that with the changes they wanted (and in their opinion needed) to make would not be worth the politics involved. I don't blame them for that decision. As a byproduct, they are now maintainers of their own system, and as shown by OpenSSH, they are very good stewards of critical systems. Then they ported it back to Linux, and got a call added to the kernel. I wouldn't call that petty.
I think it would have been better had OpenSSL just been straight up fixed rather than forked, but can you legitimately see a way for that to have happened?
To my knowledge, the OpenBSD guys have not hated on the OpenSSL guys in any way, they have hated on the code itself, which was objectively bad code with many latent bugs. Any comments about not knowing how to write secure code resulted from what was produced: insecure code.
I think it would have been better had OpenSSL just been straight up fixed rather than forked, but can you legitimately see a way for that to have happened?
To my knowledge, the OpenBSD guys have not hated on the OpenSSL guys in any way, they have hated on the code itself, which was objectively bad code with many latent bugs. Any comments about not knowing how to write secure code resulted from what was produced: insecure code.
> What's petty about removing bad code?
Nothing. But no one said anything about removing bad code.
Have you looked at that page? Their comments are extremely rude:
"So the OpenSSL codebase does “get the time, add it as a random seed” in a bunch of places inside the TLS engine, to try to keep entropy high. I wonder if their moto is “If you can’t solve a problem, at least try to do it badly”."
"Old news, but OpenSSL doesn’t give a fuck whether or not memory was freed. It’s all good."
It's hostile, unprofessional, and unnecessary. I understand these kinds of comments in a private IRC channel or something, but publicly ridiculing someone else's software, especially mission critical software that's been used for years across many platforms, is uncalled for.
It really gave me a bad taste for the LibreSSL project, and all just for some petty sniping.
Nothing. But no one said anything about removing bad code.
Have you looked at that page? Their comments are extremely rude:
"So the OpenSSL codebase does “get the time, add it as a random seed” in a bunch of places inside the TLS engine, to try to keep entropy high. I wonder if their moto is “If you can’t solve a problem, at least try to do it badly”."
"Old news, but OpenSSL doesn’t give a fuck whether or not memory was freed. It’s all good."
It's hostile, unprofessional, and unnecessary. I understand these kinds of comments in a private IRC channel or something, but publicly ridiculing someone else's software, especially mission critical software that's been used for years across many platforms, is uncalled for.
It really gave me a bad taste for the LibreSSL project, and all just for some petty sniping.
> It's hostile, unprofessional, and unnecessary.
It might be "unprofessional" which is to say, it's not polite (and since they're giving it away - why would it be "professional" -- they're not (necessarily) getting paid for the work) -- but it's not really disproportionately hostile, and most of all, I disagree that it's "unnecessary".
As evidenced in part by recent security issues, and in part by what the libressl project has dug up/cut away: the code base was horrid for the purpose (providing authentication and confidentiality). Much worse than merely "not good".
I think the (rightfully) hostile attitude helps others realize just how bad things were/are. And I welcome it. I'm sure a few developers are hurt by the comments, but all of your quotes above are pretty much factual and concrete: it's not name calling for the sake of being rude; it's a wake-up call. I'd be surprised if not a few "victims" of those comments aren't also glad that errors are both found and pointed out. Just as if you hacked together a not-quite working break system for a car, you'd prefer being called out as a hack, and someone fixing it, rather than having lots of people get hurt. The stakes involving openssl can actually be life or death.
It might be "unprofessional" which is to say, it's not polite (and since they're giving it away - why would it be "professional" -- they're not (necessarily) getting paid for the work) -- but it's not really disproportionately hostile, and most of all, I disagree that it's "unnecessary".
As evidenced in part by recent security issues, and in part by what the libressl project has dug up/cut away: the code base was horrid for the purpose (providing authentication and confidentiality). Much worse than merely "not good".
I think the (rightfully) hostile attitude helps others realize just how bad things were/are. And I welcome it. I'm sure a few developers are hurt by the comments, but all of your quotes above are pretty much factual and concrete: it's not name calling for the sake of being rude; it's a wake-up call. I'd be surprised if not a few "victims" of those comments aren't also glad that errors are both found and pointed out. Just as if you hacked together a not-quite working break system for a car, you'd prefer being called out as a hack, and someone fixing it, rather than having lots of people get hurt. The stakes involving openssl can actually be life or death.
So being rude is what you do if it's "important" and the other party didn't have an optimal solution?
Looking at the long history of openbsd and some similar projects, I think being rude like that is what you do when you're too far on to the spectrum to effectively articulate an argument. It probably has something to do with lack of empathy as well... There are very real reasons why their project and user base is the size it is.
Looking at the long history of openbsd and some similar projects, I think being rude like that is what you do when you're too far on to the spectrum to effectively articulate an argument. It probably has something to do with lack of empathy as well... There are very real reasons why their project and user base is the size it is.
> So being rude is what you do if it's "important" and the other party didn't have an optimal solution?
No, being direct is what you do if it's important. I agree that the above quotes aren't polite, but I don't think they're terribly rude. If I publish half-assed code that is hopelessly structured (even if there are reasons for it; "There's too much old cruft", "I don't have time to ...") -- I wouldn't mind getting called on my bullshit. If you suck, and someone point out to you, that you do, in fact suck -- then you should thank that someone.
Sure, it might be nicer if they're polite about it -- but it's really not that big of a deal.
No, being direct is what you do if it's important. I agree that the above quotes aren't polite, but I don't think they're terribly rude. If I publish half-assed code that is hopelessly structured (even if there are reasons for it; "There's too much old cruft", "I don't have time to ...") -- I wouldn't mind getting called on my bullshit. If you suck, and someone point out to you, that you do, in fact suck -- then you should thank that someone.
Sure, it might be nicer if they're polite about it -- but it's really not that big of a deal.
[deleted]
openssh has incredibly broad usage
I work on an open source project in my dayjob, and I can tell you I'd be far less inclined to work with an individual who curses at other developers and makes tons of disparaging comments about my work or the work of others. It creates a hostile and unwelcoming environment, which is not the kind of environment I want to be in.
But there was no cursing at other developers in the above quotes? It was some mild (and justified) ridicule. And an implication that they didn't give a fuck -- which might be a little crude. But it's kind of hard to argue that it might not be accurate criticism.
You're obviously not a "rock star" or "code ninja" then. What's next, you're not going to have tits in your slides ???
Good news in this case: you're not obliged to subscribe to [email protected]. Nor is anybody else... you don't even have to dig the archives or the third party blogs that publicize the commits.
But those who follow the commits know that the developers like to express their minds in the commit messages whether it is bad code written by one of them or somebody else. They're not targetting and publicly shaming some project while throwing insults straight at developers.
But those who follow the commits know that the developers like to express their minds in the commit messages whether it is bad code written by one of them or somebody else. They're not targetting and publicly shaming some project while throwing insults straight at developers.
Agreed. There is a place to be gentle towards others' code, but security is one of the areas where we shouldn't care a mote about developers' feelings, only about the quality of the code.
It may be hostile and unprofessional, but it is necessary. Given the OpenBSD developer have been able to pull a number of important patches directly from the OpenSSL bug tracker and fix issues in LibreSSL, it's clear that polite and professional didn't work either.
Would you have known that parts of the OpenSSL code base was so badly (and unprofessionally ) implemented if the OpenBSD developers hadn't been somewhat aggressive?
Would you have known that parts of the OpenSSL code base was so badly (and unprofessionally ) implemented if the OpenBSD developers hadn't been somewhat aggressive?
It's punishment, it's shamming, and it is absolutely necessary. It will discourage poor programmers and great programmers who don't know enough about security from half-assing critical software.
> It's hostile, unprofessional, and unnecessary.
Well I guess you do what's normal when you think someone is being unprofessional: stop buying their products and stop doing business with them.
Oh wait...
Well I guess you do what's normal when you think someone is being unprofessional: stop buying their products and stop doing business with them.
Oh wait...
Scorching the earth is the right thing to do. OpenSSL is the sick man of the internet and its community has been dysfunctional to non-functional for years, much like its code. The massive injection of money won't solve that problem in the long term. The security patches ought to be integrated with LibreSSL immediately, not after an embargo period dictated by the vendors who have essentially bought out OpenSSL.
There can be more than one bad actor in a play.
> OpenSSL served the entire internet for years.
Well, it gave the entire Internet a false sense of security for years, at least.
> …the hate just seems petty.
Have you read some of the cruft that the LibreSSL guys removed? OpenSSL has been a horrid mess. Sometimes you gotta admit that a Yugo is a really, really, really bad car.
Well, it gave the entire Internet a false sense of security for years, at least.
> …the hate just seems petty.
Have you read some of the cruft that the LibreSSL guys removed? OpenSSL has been a horrid mess. Sometimes you gotta admit that a Yugo is a really, really, really bad car.
False sense of security? They provided the best SSL stack for years, and for free. Everybody knew for long that OpenSSL was a mess, and the harsh reality is that no one wanted to take care of it beside the few (almost benevolent) OpenSSL developers.
So now, the OpenBSD guys come in with their almighty attitude, while they knew about it for years and didn't bother to do anything about it before. No one wanted to do that job before Heartbleed, so yeah, it's really uncalled for to be that rude. We should all be grateful the OpenSSL team did what they did for so long.
So now, the OpenBSD guys come in with their almighty attitude, while they knew about it for years and didn't bother to do anything about it before. No one wanted to do that job before Heartbleed, so yeah, it's really uncalled for to be that rude. We should all be grateful the OpenSSL team did what they did for so long.
You must been living on an island over the last years.
"OpenSSL was the best SSL stack for years?" Best no, only fast.
PolarSSL (now "mbed TLS") is the best, to the best definition of best.
Still better than OpenSSL, which was known to be fast but insecure and poorly managed, are the stacks used the biggest clients:
PolarSSL (now "mbed TLS") is the best, to the best definition of best.
Still better than OpenSSL, which was known to be fast but insecure and poorly managed, are the stacks used the biggest clients:
* NSS used by Chrome, Mozilla, et al
* GnuTLS used by exim, GNOME, et al.
Even the OpenBSD people seem to think it's a car worth keeping, just in need of an engine overhaul and better maintenance. They didn't throw out OpenSSL and write their own SSL library (like they have with other things), but rather forked it and cleaned it up.
Theo has a reputation for this attitude. He's not entirely unlike Linus in that he's brilliant and people don't want to deal with him.
If the fix is already committed for any of the vulnerabilities, then the answer is a simple github search away:
https://github.com/openssl/openssl/compare/OpenSSL_1_0_1l......
https://github.com/openssl/openssl/compare/OpenSSL_1_0_2...O...
Some interesting commits:
https://github.com/openssl/openssl/commit/327de270d583e716bc...
https://github.com/openssl/openssl/commit/f5ee5213073870493a...
https://github.com/openssl/openssl/commit/51527f1e3564f210e9...
https://github.com/openssl/openssl/compare/OpenSSL_1_0_1l......
https://github.com/openssl/openssl/compare/OpenSSL_1_0_2...O...
Some interesting commits:
https://github.com/openssl/openssl/commit/327de270d583e716bc...
https://github.com/openssl/openssl/commit/f5ee5213073870493a...
https://github.com/openssl/openssl/commit/51527f1e3564f210e9...
It is weird, two of them (CVE-2015-0288 and CVE-2015-0209) are listed here also with links to patches, https://security-tracker.debian.org/tracker/source-package/o...
Why have embargo on the vulnerabilities if you publish patches anyway? Which makes me think that the patches has not been committed yet and that the embargoed are different ones than these.
I found an OpenSSL bug that was assigned CVE-2015-0208 and it is still embargoed near as I can tell.
[deleted]
I can't say I feel comfortable with an announcement of "there's a vulnarability ranked high but we won't patch it until the 19th". I get why they do it that way and I prefer this announcement to nothing but it's still somewhat unsettling.
They obviously know a lot more about security than I do so I'll live with that decision.
They obviously know a lot more about security than I do so I'll live with that decision.
It's less than ideal but the obvious remediation is to update OpenSSL. Of course, if there are any other remediations it would be nice to know about them sooner. I know I'll have customers bugging me before Thursday.
Oh great, egos is programming leading to worse security situations for everybody.
Yeah Theo they made a fork of your code because it was insecure - that doesn't mean you should hope for them to fail just so you can say "they had a bug too".
Yeah Theo they made a fork of your code because it was insecure - that doesn't mean you should hope for them to fail just so you can say "they had a bug too".
Who exactly made a fork of Theo's code?
Also, I don't see how you can read any ill intent out of the email alone. It shouldn't be unreasonable for the OpenSSL devs to share vulnerabilities with LibreSSL. I don't think he would use it for any malicious purposes. Though I guess it makes you want to err on the side of caution when he comes up with such classics as declaring Apache 2.0 proprietary for no other reason that it has more lines of text than the previous version.
Also, I don't see how you can read any ill intent out of the email alone. It shouldn't be unreasonable for the OpenSSL devs to share vulnerabilities with LibreSSL. I don't think he would use it for any malicious purposes. Though I guess it makes you want to err on the side of caution when he comes up with such classics as declaring Apache 2.0 proprietary for no other reason that it has more lines of text than the previous version.
I'd think tomjen3 meant "Yeah Theo made a fork of (...)" instead of "Yeah Theo they". Looks like he originally wrote "Yeah they made a fork (...)", then he rephrased and forgot to delete the "they".
Not sure what he's saying. That the OpenSSL group are going to send the LibreSSL group vulnerabilities? That the LibreSSL group are about to disclose OpenSSL vulnerabilities? Just a bit confused!
Okay, a later story just appeared, I quote:
Okay, a later story just appeared, I quote:
"This or earlier LibreSSL releases may also address issues that are to be revealed
by The OpenSSL Project Team on the 19th of March, 2015."
He is referring to https://mta.openssl.org/pipermail/openssl-announce/2015-Marc...
"This story is probably redundant now, then."
given obsd has/is doing a post heartbleed code review on OpenSSL since April 2014 to build LibreSSL [0] is it wise to assume this?
[0] http://arstechnica.com/information-technology/2014/04/openss...
given obsd has/is doing a post heartbleed code review on OpenSSL since April 2014 to build LibreSSL [0] is it wise to assume this?
[0] http://arstechnica.com/information-technology/2014/04/openss...
http://marc.info/?l=openbsd-misc&m=142660009729096&w=2