Core Infrastructure Initiative(linuxfoundation.org)
linuxfoundation.org
Core Infrastructure Initiative
http://www.linuxfoundation.org/programs/core-infrastructure-initiative
87 comments
Indeed! I 100% agree.
I know you didn't say this, but I do think its important to dispel the notion that this is somehow a "response" to LibreSSL. As far as I can tell, it's not; the two initaitives started in parallel. The Linux Foundation started reaching out to companies to join them in supporting projects that are important and not necessarily visible -- starting with OpenSSL -- at the same time the LibreSSL project was starting.
When I asked Jim Zemlin (Linux Foundation executive director) about LibreSSL yesterday, he wasn't familiar enough with the project -- but was certainly open to the idea of all projects working together (or even having CII support something like LibreSSL if it had the type of adoption that would make it a core part of the open web).
Even if this project had been in place when Theo and the OpenBSD guys forked OpenSSL, I still think they would have forked it and started LibreSSL. After all, they have their own ideas about crypto and security and their own plans for how to run a project.
And even assuming LibreSSL can become a true drop-in replacement for all existing OpenSSL installations (which I truly doubt), that doesn't mean it will. Look at MySQL vs. MariaDB. Maria is finally gaining default status in important projects, but it's hardly replaced MySQL and realistically speaking, it probably won't.
So even if you want to argue that LibreSSL is going to do a better job with fixing OpenSSL's flaws (which may or may not be true), the reality is, OpenSSL is not going to go away.
Given that reality, doesn't it make sense to at least have the biggest stakeholders in the project offer it support so that the small dev team can stop with the contract work and work on making OpenSSL better?
I know you didn't say this, but I do think its important to dispel the notion that this is somehow a "response" to LibreSSL. As far as I can tell, it's not; the two initaitives started in parallel. The Linux Foundation started reaching out to companies to join them in supporting projects that are important and not necessarily visible -- starting with OpenSSL -- at the same time the LibreSSL project was starting.
When I asked Jim Zemlin (Linux Foundation executive director) about LibreSSL yesterday, he wasn't familiar enough with the project -- but was certainly open to the idea of all projects working together (or even having CII support something like LibreSSL if it had the type of adoption that would make it a core part of the open web).
Even if this project had been in place when Theo and the OpenBSD guys forked OpenSSL, I still think they would have forked it and started LibreSSL. After all, they have their own ideas about crypto and security and their own plans for how to run a project.
And even assuming LibreSSL can become a true drop-in replacement for all existing OpenSSL installations (which I truly doubt), that doesn't mean it will. Look at MySQL vs. MariaDB. Maria is finally gaining default status in important projects, but it's hardly replaced MySQL and realistically speaking, it probably won't.
So even if you want to argue that LibreSSL is going to do a better job with fixing OpenSSL's flaws (which may or may not be true), the reality is, OpenSSL is not going to go away.
Given that reality, doesn't it make sense to at least have the biggest stakeholders in the project offer it support so that the small dev team can stop with the contract work and work on making OpenSSL better?
OpenSSL needs a competitor to keep them honest, because clearly they've failed at their duty to push back on TLS WG features, failed at deprecating old code (Tandem multiplication, really?) and failed at writing secure code.
I thought GnuTLS would have been the alternative to OpenSSL but apparently it fell short.
For a while, GnuTLS was faster to support newer TLS standards. But again, same boat of not taking a leadership approach to engage TLS WG.
More implementations:
https://en.wikipedia.org/wiki/Comparison_of_TLS_Implementati...
More implementations:
https://en.wikipedia.org/wiki/Comparison_of_TLS_Implementati...
Was there a project management level reason to it, or was it just not the right combination of people? Anybody know more?
nss and nspr, to name one alternative.
My impression is that the CII is far more corporate, just from the quick-skim overview. That can be good, but can also up a whole can of competitive interest worms.
Both very good solutions although i prefer the Linux Foundations answer.
I'm amazed however that it took the Heartbleed incident to make big companies realize that hey we have been using these free and open source pieces of software everywhere maybe we should contribute back with some money or a few full time employees working on it.
I'm amazed however that it took the Heartbleed incident to make big companies realize that hey we have been using these free and open source pieces of software everywhere maybe we should contribute back with some money or a few full time employees working on it.
I think pretty solid arguments can be made for the position that the Linux Foundation approach is the better route actually.
As also noted, pretty solid arguments can be made that the OpenBSD approach is the better approach. My point was that they're not mutually exclusive, and this is definitely a win-win scenario, as we have the potential to get
1. A rock-solid open source SSL library
2. Less surprises in the future.
> pretty solid arguments can be made that the OpenBSD approach is the better approach
Not really. OpenBSD is making a OpenSSL replacement for OpenBSD. They might make a portable version, but they might not. They have made it clear they are not putting the FIPS compliance stuff back in and there's a good chance a lot of those sponsors are interested in that.
Secondly, you don't get to choose where donations go in OpenBSD. You donate to OpenBSD and they distribute wherever. You don't get to say 'I need this money to go to improving the SSL library.' That can be kind of an issue for things like this.
Not really. OpenBSD is making a OpenSSL replacement for OpenBSD. They might make a portable version, but they might not. They have made it clear they are not putting the FIPS compliance stuff back in and there's a good chance a lot of those sponsors are interested in that.
Secondly, you don't get to choose where donations go in OpenBSD. You donate to OpenBSD and they distribute wherever. You don't get to say 'I need this money to go to improving the SSL library.' That can be kind of an issue for things like this.
FIPS is actively harmful to security by virtue of being an empty and ill-conceived certification. Removing FIPS from an otherwise best available option is to the benefit of the industry at large.
By comparison, glossy marketing of a security effort offers no security benefits, and plenty of room within which to hide bad ideas such as FIPS.
By comparison, glossy marketing of a security effort offers no security benefits, and plenty of room within which to hide bad ideas such as FIPS.
As others have said, the technical arguments against FIPS don't mean anything when a huge potential customer requires it.
And huge potential customers don't mean anything to a non-profit open source ecosystem that actually care about security.
Come on. We have every reason to believe that an OpenBSD library will be easily portable. That's their way. And FIPS was evil and had to go.
You think they can be made, but can you make them?
Money on its own can't code though. Money or no money, you need people who can and will start fixing shit.
Money on its own can't code though. Money or no money, you need people who can and will start fixing shit.
Holy crap, Microsoft donating to the Linux Foundation. Cats and dogs, living together. It's the end of days for real this time.
My one real question: How well has the Linux Foundation managed its money in the past? Are they going to be an effective steward of this fund?
My one real question: How well has the Linux Foundation managed its money in the past? Are they going to be an effective steward of this fund?
I asked Jim Zemlin -- the Linux Foundation boss -- about Microsoft and if he ever could have predicted this would happen. He just laughed, but I could tell he enjoyed the irony too.
The Linux Foundation handles the Linux kernel, so they have a good track record in that regard. They also have worked on some less-successful (but very well-managed) initiatives like Meego and now Tizen.
The members are big corporations and as a result, the auditing process and outlay of funds isn't something I'd be concerned with.
The greater (potential) concern would be over how the corporate sponsors could influence a project. Zemlin assured me that the SOP is not to interfere with existing operational structures or governances of a project -- so they wouldn't have any impact on how the OSF is run, for instance -- and certainly, in the case of the Linux kernel, corporate sponsorship hasn't dictated Linus's direction of the project.
That said, I think the level of influence a corporation could have over a project is probably directly related to how a project is initially structured. Tizen, as an example, is in partnership with the Linux Foundation, but is largely led by Samsung and Intel. That's totally fine, and was that way by design.
I would be concerned about projects that might not have strong leaders (like Linus). Of course, one could argue that if that's the case, the project might have bigger problems than being co-opted by other entities.
The Linux Foundation handles the Linux kernel, so they have a good track record in that regard. They also have worked on some less-successful (but very well-managed) initiatives like Meego and now Tizen.
The members are big corporations and as a result, the auditing process and outlay of funds isn't something I'd be concerned with.
The greater (potential) concern would be over how the corporate sponsors could influence a project. Zemlin assured me that the SOP is not to interfere with existing operational structures or governances of a project -- so they wouldn't have any impact on how the OSF is run, for instance -- and certainly, in the case of the Linux kernel, corporate sponsorship hasn't dictated Linus's direction of the project.
That said, I think the level of influence a corporation could have over a project is probably directly related to how a project is initially structured. Tizen, as an example, is in partnership with the Linux Foundation, but is largely led by Samsung and Intel. That's totally fine, and was that way by design.
I would be concerned about projects that might not have strong leaders (like Linus). Of course, one could argue that if that's the case, the project might have bigger problems than being co-opted by other entities.
There was time ,maybe a year back, where Microsoft turned out to be one of the Top contributors to Linux Kernel. They had to fix some issue on Linux kernel to run on HyperV
There was time ,maybe a year back, where Microsoft turned out to be one of the Top contributors to Linux Kernel. They had to fix some issue on Linux kernel to run on HyperV
Let's be very clear on this subject, though: Microsoft was doing it for their own benefit. It wasn't altruism.
Let's be very clear on this subject, though: Microsoft was doing it for their own benefit. It wasn't altruism.
Yeah, I remember reading about that. Was a pleasant surprise.
The Linux ecosystem has a shit-load of money and OpenBSD claims to not seen a dime of it, despite Linux'es use of OpenSSH Portable. [0] One would think something as vital as OpenSSH would get a reasonable share of funding, rather than a huge lump-sum being showered on a single project in turmoil with questionable stewardship.
[0] http://www.openbsd.org/openssh/
[0] http://www.openbsd.org/openssh/
Agreed, I think the Linux foundation can fix this issue along with others by financially contributing to OpenSSH, OpenSSL, LibreSSL and other tools that we use (iptables, OpenSMTPD, Postfix, Dovecot, etc).
I think if Linux extended an olive branch to engage the three main BSD's, that would be a smart political and actual move. Religousity doesn't scale anything but egos and pitchfork-toting, angry people looking for an ego-oriented leader.
A wise Microsoft, which we might be seeing, would know that a bad Linux security foundation is just plain bad for business, for the Internet ecosystem and general trust in it (after all, most people don't know what sort of server they're connecting to), for sales of desktop Windows to surf in that ecosystem, etc.
A pragmatic Microsoft might be edging away from a "Windows or Death!" attitude. Didn't we read that after they bought Skype they replaced its skeezy "volunteer" supernodes with 10,000 systems running Linux? E.g. https://www.google.com/search?q=microsoft+skype+linux+supern...
A pragmatic Microsoft might be edging away from a "Windows or Death!" attitude. Didn't we read that after they bought Skype they replaced its skeezy "volunteer" supernodes with 10,000 systems running Linux? E.g. https://www.google.com/search?q=microsoft+skype+linux+supern...
I interpreted that as part of their legal obligation to add eavesdropping capability to Skype, which was probably quite difficult with the more decentralized network. But overall, I'm pleasantly surprised by the number of pleasant surprises coming from Microsoft lately.
Lawful intercept could be added without routing all traffic to their nodes. Perhaps MS correctly realised that offering a service which uses arbitrary amounts of computing and bandwidth from users is a crappy thing to do and not in-line with an MS offering?
As expected no Apple. I have always been fascinated how Apple gets a lot of developer love and yet is completely absent in most (all?) conference/event sponsorship, initiatives etc.
Apple uses a lot of different technology than Linux does, though. Even down to their fileutils, cp, find, mv, chmod, etc. are all BSD-variants and not GNU; they ship with cURL and not wget; and they use/prefer LLVM/Clang over GCC, and so on.
They also ship software like OpenSSL, but they actively discourage its use in Mac software in favour of SecureTransport.
Don't get me wrong, they should give back (and they do), but it's kind of surprising how much of the standard Linux stack they don't actually ship.
They also ship software like OpenSSL, but they actively discourage its use in Mac software in favour of SecureTransport.
Don't get me wrong, they should give back (and they do), but it's kind of surprising how much of the standard Linux stack they don't actually ship.
You mean GNU stack :). They use plenty of FreeBSD code.
What for? Apple discourages the use of OpenSSL[1] and instead use their own open source library[2] which also has an API present inside of Cocoa and iOS.
1: https://developer.apple.com/library/mac/documentation/securi...
2: http://opensource.apple.com/source/Security/Security-55471/
1: https://developer.apple.com/library/mac/documentation/securi...
2: http://opensource.apple.com/source/Security/Security-55471/
No Apple fan here, but to be fair they give some apps back (eg: cups)
They hired the main developer of CUPS to adapt it for OS X. The license of CUPS ensures they continue to share it - the GPL and LGPL - they even had to explicitly add a licensing exception for Apple's (and other company's) binary printer drivers. I would bet money if Apple had CUPS under a BSD license they would not be sharing their improvements so leisurely.
Really? Because they did that with WebKit. They made huge modifications to KHTML and KJS, released them back (admittedly in kind of an amateurish way at the start), and also open-sourced their proprietary component, WebKit, which wraps WebCore and JSCore up in a nice, manageable interface. They didn't have to, but they did.
They also have a lot of contributions to LLVM/Clang, as well as several other open-source projects.
They also have a lot of contributions to LLVM/Clang, as well as several other open-source projects.
Of course they had to share webkit, KHTML and KJS were under the LGPL so they had to. What they didn't have to share was the apps based on top of webkit such as Safari and they didn't share Safari.
KHTML/KJS was LGPL, so they had to release it. LLVM and Clang is a better argument, until you realize that Apple hired on the guy from the project after their GCC grand plans collapsed - the only visible reason they shifted strategies was to keep from having to open source components of their proprietary IDE XCode.
It's very well established that Apple is allergic to the GPL, and is willing to pay good money to avoid dealing with it whenever possible.
It's very well established that Apple is allergic to the GPL, and is willing to pay good money to avoid dealing with it whenever possible.
He has a point though, Apple and other deep-pockets should in someway contribute and/or endorse software they use since ages and donate some $$ to Open/Net/Free BSDs.
They have their own Unix.
I hope that OpenSSH developers get some funding too. OpenSSH is clearly a core infrastructure, and they had financial difficulty in the past.
Mozilla Foundation once donated 10K USD to OpenSSH after OpenSSH's call for donation. Not many others did.
Mozilla Foundation once donated 10K USD to OpenSSH after OpenSSH's call for donation. Not many others did.
Are the OpenBSD people still saying that money donated for OpenSSH will be used to develop OpenBSD?
OpenBSD is great but it has its own agenda. Linux Foundation does have a Linux in it, maybe that tells something.
Plus, Libressl can pull in whatever changes future openssl will have. I think it's a win-win for both sides.
I used OpenBSD in the past, but nowadays it's all Linux for everything, from server to desktop to my cellphone.
also i don't think there's anything stopping the Linux Foundation from sponsoring libressl porting effort.
I think the opposite will be true... openssl will be pulling in what libressl does, and it probally not be long before many of the distro's drop openssl...
Alternative possibility: OpenSSL & LibreSSL pull from eachother, but OpenSSL incorporates more new features sooner. Banks run LibreSSL- much as they run OpenSSL 0.98 today- and hip new startups that want New Feature X run OpenSSL- much as they run OpenSSL 1.0.1f today.
So to get this straight, the Linux Foundation has responded to OpenSSL problems by creating a web page, a committee and are soliciting dollars from sponsors and grass roots?
OpenBSD responds by rolling up sleeves and fixing the problem.
OpenBSD responds by rolling up sleeves and fixing the problem.
I get the feeling that these companies are throwing money at trying to fix the problems (in other projects besides OpenSSL that are fundamental), and not talent/manpower.
[deleted]
Their web page says OpenSSL group is their first candidate for funding. It's puzzling that they would choose to fund such a corrupt and incompetent organization over LibreSSL, which is actually fixing the code and ultimately is what will actually be used.
Or maybe it's not so mysterious, the principle companies involved have a long record of benefiting from OpenSSH and never contributing to that either.
Or maybe it's not so mysterious, the principle companies involved have a long record of benefiting from OpenSSH and never contributing to that either.
LibreSSL is a fork for OpenBSD and doesn't have all the functionality of openSSL (e.g., no Windows support), so it's not a given that LibreSSL will actually become the standard. Also, despite the issues with openSSL, there is significant name recognition for it. That means that funding and improving openSSL can potentially lead to a better outcome than funding libreSSL. I mean this in the sense that funding something else (e.g., LibreSSL) could result in a situation where people still use openSSL because they know the name but that the improvements are going elsewhere. Sure, you can say that people should switch, but name recognition can be tough to overcome.
I think as long as LibreSSL plans on ripping out the FIPS stuff, it's not going to replace OpenSSL in a huge number of places. Don't get me wrong, I think it's the right decision for the OpenBSD guys, and for the security of the library, but it's definitely going to limit adoption.
FIPS support is such a rare requirement (and such an awful one) that I'm willing to bet LibreSSL, once it's 'finished' and buildable on the typical Linux system, will be gladly adopted by pretty much everyone who can. Distros will probably prefer LibreSSL whenever possible, with the exception of Debian, unless the licensing issue can be resolved (which I hope it is because GnuTLS is awful).
The vast majority of people who use OpenSSL don't need FIPS compliance, and LibreSSL will provide them with a more solid, better reviewed, more secure, lightweight, reliable drop-in replacement. It's hard to argue with that.
The vast majority of people who use OpenSSL don't need FIPS compliance, and LibreSSL will provide them with a more solid, better reviewed, more secure, lightweight, reliable drop-in replacement. It's hard to argue with that.
FIPS support will be required by RedHat, SuSE and any other vendor that wants to do business with the US (and many other) federal governments.
If none of the major vendors will ship a non-FIPS certified crypto lib, then where exactly will it get used?
If none of the major vendors will ship a non-FIPS certified crypto lib, then where exactly will it get used?
To make the code auditing easier a number of code paths irrelevant to OpenBSD were removed.
Once the code is audited and bugs corrected portability is next. This will only happen if the right team is in place, the community wants it, and sufficient funding is secured.
Once the code is audited and bugs corrected portability is next. This will only happen if the right team is in place, the community wants it, and sufficient funding is secured.
This is untrue. It removed Windows build support, not Windows support.
That's not exactly accurate. In its current form, you couldn't compile OpenBSD's libssl on Windows even if you had a build system for it.
However, I don't think this is a bad thing. To do a massive clean up, you must be able to focus on code that you can actually compile and test. Dead code, code behind ifdefs is likely to rot. If it wasn't very rotten already.
It is better to do a fresh port of a cleaned up code base for modern systems.
However, I don't think this is a bad thing. To do a massive clean up, you must be able to focus on code that you can actually compile and test. Dead code, code behind ifdefs is likely to rot. If it wasn't very rotten already.
It is better to do a fresh port of a cleaned up code base for modern systems.
Like removing long long multiplication just for Tandem.
The OpenBSD guys are applying their knowledge in system designs to sanitize the code and making it more standard. It doesn't qualify them to work on the algorithm parts.
How many years have you been benefiting from the work that was put behind OpenSSL ? What about being a bit grateful for the amazing work they did with basically no funding ?
How many years have you been benefiting from the work that was put behind OpenSSL ? What about being a bit grateful for the amazing work they did with basically no funding ?
It is amazing to me that I buy a computer with an OS and aparently zero of that money goes to the people writing some of the important code used in that OS.
Windows used to use BSD stuff for the network stack. OSX uses a lot of BSD stuff. These are not poor companies. Including a per-licence donation of a few US cents would have been a significant contribution.
Windows used to use BSD stuff for the network stack. OSX uses a lot of BSD stuff. These are not poor companies. Including a per-licence donation of a few US cents would have been a significant contribution.
I think Microsoft was maintaining their own fork of the BSD stuff. The money for support was going to the internal team maintaining it.
> It doesn't qualify them to work on the algorithm parts.
Since they also develop OpenSSH, wouldn't that qualify them to also work on the algorithm parts?
Since they also develop OpenSSH, wouldn't that qualify them to also work on the algorithm parts?
For some of the core crypto stuff, yes.
But, TLS is a huge spec, and I think the OpenSSL guys are going to have more experience in things like "Older (and widely deployed) F5 networking devices attempt to parse a TLS Handshake as SSLv2 first, which means that due to the overlapping structure, an SSLv3/TLS client-hello of length 256 - 511 bytes, it can't tell if a certain byte is a "message type" of 1 (SSLv3/TLS) or it is the "length high bits" to be 1 (SSLv2). Therefore, despite no mention in the spec, it's useful to pad out the CLIENT_HELLO to remove the ambiguity." (Just to use a recent example)
TLS is a horrible mess of a spec, and the real-world implementations are even grittier. While I'm not knocking the OpenBSD guys at all (and I think what they're doing is great), let's not forget that OpenSSL got it's place because despite the code quality, it's one of the most fully-featured TLS stacks out there due to the knowledge and experience of it's developers. I hope to see lots of code flowing in both directions between the two projects.
But, TLS is a huge spec, and I think the OpenSSL guys are going to have more experience in things like "Older (and widely deployed) F5 networking devices attempt to parse a TLS Handshake as SSLv2 first, which means that due to the overlapping structure, an SSLv3/TLS client-hello of length 256 - 511 bytes, it can't tell if a certain byte is a "message type" of 1 (SSLv3/TLS) or it is the "length high bits" to be 1 (SSLv2). Therefore, despite no mention in the spec, it's useful to pad out the CLIENT_HELLO to remove the ambiguity." (Just to use a recent example)
TLS is a horrible mess of a spec, and the real-world implementations are even grittier. While I'm not knocking the OpenBSD guys at all (and I think what they're doing is great), let's not forget that OpenSSL got it's place because despite the code quality, it's one of the most fully-featured TLS stacks out there due to the knowledge and experience of it's developers. I hope to see lots of code flowing in both directions between the two projects.
I've actually been wondering lately, if a for of openssh would be a good idea, with the goal of ripping out version 1 support, some other cruft, and eg: arcfour and other algorithms that seem a bit redundant and potentially dangerous (to me) these days.
So far, I'm thinking that the odds that I'd introduce some horrible bug (either along the lines of the Debian ssl keygen bug) or perhaps more likely increase vulnerability to timing attacks outweighs the potential benefits (a tighter, more transparent code base, with fewer features and hopefully fewer bugs).
So far, I'm thinking that the odds that I'd introduce some horrible bug (either along the lines of the Debian ssl keygen bug) or perhaps more likely increase vulnerability to timing attacks outweighs the potential benefits (a tighter, more transparent code base, with fewer features and hopefully fewer bugs).
I don't know about corrupt and incompetent... maybe under-resourced and apathetic babysitters of a legacy-ridden codebase.
I don't mind it if people fund and contribute to OpenSSL. Improved software is improved software whether you prefer another fork or not.
However, I will personally refrain from funneling money into any project if it is not clear that money will make a difference. It's like donating to charities who cannot ensure the money actually ends up in the right place and actually helps the lives of the people who they (cl)aim to help. I'm more likely to donate to projects that have proven their worth, like OpenBSD. The proof, hard work, should come first. Donations might follow.
However, I will personally refrain from funneling money into any project if it is not clear that money will make a difference. It's like donating to charities who cannot ensure the money actually ends up in the right place and actually helps the lives of the people who they (cl)aim to help. I'm more likely to donate to projects that have proven their worth, like OpenBSD. The proof, hard work, should come first. Donations might follow.
> The proof, hard work, should come first. Donations might follow.
Part of the problem with funding open source is that an agent acting only in their own short term interests is going to say: "ok, someone already did the hard work, the results are free!", and won't donate anything.
Part of the problem with funding open source is that an agent acting only in their own short term interests is going to say: "ok, someone already did the hard work, the results are free!", and won't donate anything.
That's not a problem with funding open source. That might be a problem with getting money if you start doing open source and expect money in return.
What other people do (or don't do) doesn't really matter. If I refuse to donate to a project, and Apple makes a non-free derivative of that project, that project is still free and you can still fund it.
What other people do (or don't do) doesn't really matter. If I refuse to donate to a project, and Apple makes a non-free derivative of that project, that project is still free and you can still fund it.
It's very much a problem with funding open source because no one pays for the developers, leading to stuff like openssl in its current state, that everyone depends on, but no one pays for!
I agree with your assessment of who to donate to, by the way, I'm just saying that the whole thing is a bit difficult.
I agree with your assessment of who to donate to, by the way, I'm just saying that the whole thing is a bit difficult.
> That's not a problem with funding open source. That might be a problem with getting money if you start doing open source and expect money in return.
This is a distinction without difference. If you're not getting money for doing open source development, your open source development has no funding.
This is a distinction without difference. If you're not getting money for doing open source development, your open source development has no funding.
How exactly are they corrupt?
It's worth noting that a number of the businesses that are contributing will have a need to provide FIPS compliant services, something LibreSSL has completely thrown out the window.
I think it's spectacularly naive to assume LibreSSL will be widely adopted beyond FreeBSD just because it's a cleaner codebase.
The primary goal of LibreSSL is to fix the OpenSSL codebase for OpenBSD. If other communities like the changes there could be a portable versions as alluded by the LibreSSL web site.
Think OpenSSH -> OpenSSH-portable.
Think OpenSSH -> OpenSSH-portable.
Just because.
What if it also had fewer bugs, is more receptive to contributed bug fixes, runs clean in Valgrind, etc.?
What if it also had fewer bugs, is more receptive to contributed bug fixes, runs clean in Valgrind, etc.?
The point of LibreSSL is to be a potential competitor and an apparent existential threat to scare OpenSSL into getting its house in order.
I don't think that's the point. I think OpenBSD devs just want secure code, and they get it by doing the work. So that's what they do. No hidden agendas.
If this fork makes OpenSSL developers be more responsive to patch fixes and have them improve their documentation it's a win for OpenSSL and their users at large.
OpenBSD is already reaping the benefits from a better TSL implementation in -current so it's a win for our project as well.
This is a win win scenario.
OpenBSD is already reaping the benefits from a better TSL implementation in -current so it's a win for our project as well.
This is a win win scenario.
Exactly. When a popular security project has no clear competition, a code "monopoly" may exist and it's much easier to get complacent. By introducing "competition," it tends to keep both projects adversarial and vigilant... which is exactly what a security project needs.
Looks like somebody is trying hard to prevent LibreSSL from becoming widely adapted.
> By raising funds at a neutral organization like The Linux Foundation, the industry can effectively give projects the support they need while ensuring that open source projects retain their independence and community-based dynamism.
I somehow can't imagine an organization named "Linux Foundation" to give money to OpenBSD and other non-Linux related open source projects.
> By raising funds at a neutral organization like The Linux Foundation, the industry can effectively give projects the support they need while ensuring that open source projects retain their independence and community-based dynamism.
I somehow can't imagine an organization named "Linux Foundation" to give money to OpenBSD and other non-Linux related open source projects.
I think you're over-thinking it. I imagine this was done solely in response to heartbleed itself, not OpenBSD's fork. It's a good charter, I'm happy it's being done.
Yes, they've obviously been working on this announcement for a few weeks. You can't get all those big players on board in the time since libressl was announced.
> I somehow can't imagine an organization named "Linux Foundation" to give money to OpenBSD and other non-Linux related open source projects.
Why not ? I could imagine them giving money to OpenSSH developers at least, seeing how it is part of the core infrastructure.
Also, would you have imagined Microsoft giving money to an organization named "Linux Foundation" ?
Why not ? I could imagine them giving money to OpenSSH developers at least, seeing how it is part of the core infrastructure.
Also, would you have imagined Microsoft giving money to an organization named "Linux Foundation" ?
If the money was given to the Linux Foundation by Microsoft, I guess anything goes.
LibreSSL and openSSLRampage is the OpenBSD response, and, it's absolutely in keeping with their character. I admire the "Fuck it, let's just fix this shit" attitude that goes along with it.
The Core Infrastructure Initiative is the Linux Foundation's response.
They're two valid ways of dealing with the problem. the LibreSSL way is more direct, targetted, and, in a way, satisfying, especially if you run OpenBSD, and can gain from these efforts relatively quickly.
The "Core Infrastructure Initiative" is looking at it from a more holistic perspective and saying: OK, OpenSSL was in trouble and nobody noticed, what other projects are in the same situation, and how can we prevent what happened to OpenSSL from happening to other projects.
Neither way is necessarily "The only right way", or even better than the other way. In fact, both approaches complement each other. OpenBSD fixes the actual current problem child, Linux Foundation is on the hunt for the next problem child