[openssl.org #3286] DTLS client crash while clearing (freeing) the dtls1_buffer_record queue (buffered_app_data)
Fixed now, thanks for the report. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: AW: Which platforms will be supported in the future on which platforms will be removed?
On Tue, Jun 03, 2014 at 02:22:07PM +1000, Peter Waltenberg wrote: One of the uglier problems is that unless you can build/test on all the platforms on each change you'll almost certainly break platforms unexpectedly - that lack of hardware has been one of the long term problems and it's likely one of the inhibtors to cleanup as well. There's a very simple solution to that problem, especially since we now have the support and attention of many hardware companies. The rule should be very simple. If a company doesn't contribute either (a) exclusive, dedicated hardware, or (b) reliable, continuous access to hardware, it doesn't get supported by the OpenSSL developers. Period. If it's not important for a company to provide access to hardware, then they can take on the support burdens of providing OpenSSL support to their platform, or clearly *they* don't care about the security of their users. And if they don't care, again, it's not fair to impose a security tax on the rest of the Internet. (And especially in the case of embedded products, it's not enough that OpenSSL provide a new release with a security fix; the company needs to be willing to create a firmware load and get it to all of its 10 year old customers. And if they aren't willing to provide hardware to critical infrastructure provider such as OpenSSL, it seems unlikely they will be creating a new firmware load anyway, so what's the point?) The Linux kernel doesn't tie itself in knots wringing its hands about how it can't make forward progress because it might break, say, the break the m68k or alpha port. They continue to exist only because a number of m68k and alpha maintainers are sufficiently motivated to keep them alive, *and* the impact on the core code is largely nil. If a largely dead architecture or CPU started getting in the way of everyone else, it would either have to get fixed so it wasn't getting in the way, or it would be removed. (Which, for example, was the decision of the x86 maintainers over the fate of 80386 support.) Cheers, - Ted __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: AW: Which platforms will be supported in the future on which platforms will be removed?
On Tue, Jun 3, 2014 at 7:10 AM, Theodore Ts'o ty...@mit.edu wrote: There's a very simple solution to that problem, especially since we now have the support and attention of many hardware companies. The rule should be very simple. If a company doesn't contribute either (a) exclusive, dedicated hardware, or (b) reliable, continuous access to hardware, it doesn't get supported by the OpenSSL developers. Period. [ details schnipped ] Hi, Ted. This is lucid, cogent advice. I hope everyone reads this twice. The most constrained resource is developer time, and it should prioritized based on some calculus that includes an awareness of which versions on which platforms have what level of deployment, an internal roadmap that serves as a strategic guide, and resources made available by companies that need custom or embedded versions. The roadmap is key - it needs to include, as Rich Salz took the trouble to point out, a clear declaration of EOL for the entire matrix of versions x platforms. Without that, assigning priority to features in new versions is a promise without real commitment. In addition to a public roadmap, a disciplined approach to managing feature backlog is key for the developers and committers. While we're full of good ideas for innovation and improvement, let's not forget the committed efforts of those who continue to shepherd the project, especially Stephen Henson, who has kept it together in much the same way as Keith Richards did the Stones. - M __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
patch for make depend, chacha
Hi, pls see attached. Is there somebody working on it to get Chacha/Poly cipher suites production ready? Cheers, Dirk --- crypto/chacha/Makefile.orig 2014-06-03 10:49:51.082287334 +0200 +++ crypto/chacha/Makefile 2014-06-03 10:50:07.496433689 +0200 @@ -21,7 +21,7 @@ APPS= LIB=$(TOP)/libcrypto.a -LIBSRC= +LIBSRC=chacha_vec.c LIBOBJ=$(CHACHA_ENC) SRC= $(LIBSRC)
RE: AW: Which platforms will be supported in the future on which platforms will be removed?
especially Stephen Henson, who has kept it together in much the same way as Keith Richards did the Stones. With no disrespect intended to either man, I have to say that this is an analogy that never would have occurred to me in a million years. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz
RE: patch for make depend, chacha
Is there somebody working on it to get Chacha/Poly cipher suites production ready? It's expected that the way the ciphers are used will change as it goes through the IETF TLS group. Therefore, Google has not been encouraging folks to pick up and use these patches other than an on your own basis until after the they're done. (They == IETF and GOOG I suppose:) /r$ -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz
Re: [openssl.org #3374] Do not advertise ECC ciphersuites in SSLv2 client hello
On Tue, Jun 03, 2014 at 06:01:03PM +0200, Tomas Mraz via RT wrote:
openssl advertises ECC ciphersuites in SSLv2 client hello if ssl23
method is used. This is incorrect because the TLS extensions that
indicate supported curves and point formats cannot be sent in SSLv2
client hello. The attached patch ensures that no ECC ciphersuites are
sent in SSLv2 client hello.
This looks about right, where do you still use SSLv2? Nowadays,
you should probably have SSLv2 disabled.
diff -up openssl-1.0.1e/ssl/s23_lib.c.ssl2noec openssl-1.0.1e/ssl/s23_lib.c
--- openssl-1.0.1e/ssl/s23_lib.c.ssl2noec 2013-02-11 16:26:04.0
+0100
+++ openssl-1.0.1e/ssl/s23_lib.c 2014-05-06 15:51:54.053293674 +0200
@@ -107,6 +107,13 @@ int ssl23_put_cipher_by_char(const SSL_C
long l;
/* We can write SSLv2 and SSLv3 ciphers */
+ /* but no ECC ciphers */
+ if (c-algorithm_mkey == SSL_kECDHr ||
+ c-algorithm_mkey == SSL_kECDHe ||
+ c-algorithm_mkey == SSL_kEECDH ||
+ c-algorithm_auth == SSL_aECDH ||
+ c-algorithm_auth == SSL_aECDSA)
+ return 0;
if (p != NULL)
{
l=c-id;
--
Viktor.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: AW: Which platforms will be supported in the future on which platforms will be removed?
I don't disagree (or I certainly don't disagree completely) with anything that has been said so far. But I think it's easy to assign disproportionate angst to this or that problem. For example, and that's all this is, but one of the most serious issues I think we have in the openssl code is that macros are (ab)used heavily because the we have a legacy rule against the use of inlines. One of the other guys can probably remember why this is (I don't), but I would suspect that it *is* related to support for some obscure platform or toolchain. My point is that if we collapse the issue down to trimming the list of supported platforms, we could overlook the actual benefits in many cases. In this example, we may miss the fact that the no-inlines rule is in fact no longer justified. I've been in the bowels of the linux kernel over the last few years (though nothing compared to Ted), and it's vivid to me how inlines, however evil they might appear to some people, are still much less evil than macros. (In nearly all cases.) A similar example is for symbols like NO_SYS_UN_H. You'll find #ifdefs for that whenever there are headers and code that deal with domain sockets. I agree with Ted about the fact that it's much better to get rid of the #ifdefs where that stuff is used, and instead #ifdef it (or arch/-split it) in the one place where domain socket stuff is *declared*. #ifdef the called, not the caller. Any sensible and pragmatic approach to reviewing the list of supported platforms should include an effort to qualify these kinds of downstream effects. (Ie. does removing or keeping a particular platform change anything? Or allow anything to be changed for the better?) Implicit in the discussion about platforms is the question of the build system. I have a number of thoughts on this too, but have refrained from doing anything about them so far because I could easily bite off more than I can chew, time-wise. In fact, I've heard that the use of ordinals might be avoidable even on windows, and it's clearly useless everywhere else (except VMS?), but it's a maintenance hassle all the time for everyone who is making updates (especially across more than one branch). A discussion about platforms ought to address this too. While I'm on a roll, another example. Things like crypto/dso/ really only exist to cover the fact that there is no notion of arch/ in the code-base. I dare say there are a number of other places and abstractions where, if we used a more OS/kernel style of coding, things might simplify down. Loading and using a shared-library would have a single *internal* API, and that API itself would be implemented within the appropriate sub-directory of arch to suit the target platform. As things stand, we have an *exported* DSO API, which is pluggable by built-in and/or caller-provided modules, despite the fact that on a sensible system only one such module exists and there would be no reason for a caller to plug in a replacement. I wrote that DSO stuff, so I'm not hating on anyone but myself, but it was done that way because that's in keeping with how everything else is done, it seemed (and seems) to be the consistent thing to do. In other words, it's symptomatic of a more general issue. A discussion about platforms ought to address this sort of thing too. Which leads me I guess to a bigger issue, or meta-issue: compatibility. In addition to everything that has already been said, a major issue that I haven't seen mentioned is the fact that openssl has always been painstakingly backwards compatible at an API level. Many years ago, the use of OPENSSL_NO_DEPRECATED started cropping up (I don't recall if I started that or joined in), but all of those symbols are still there. In other words, we introduced the mechanism that *would* allow us to phase things out from one major release to the next but never actually pulled the trigger. (If you build with OPENSSL_NO_DEPRECATED, some legacy things disappear, and the idea is that in a major release all the DEPRECATED stuff could be amputated from the source. Rinse and repeat.) Again, if blame is to be had then I'll take a double. It may be that rounding up a list of platforms seems to be the easiest problem to attack and perhaps it inspires more motivation. It can't be bad exercise in and of itself. But I suspect that all it will do is clear away some modestly-bounded level of cruft, it is unlikely to repair structurally-important problems without harder discussions being had. (Coding assumptions like inlines, portability philosophy such as modules-vs-arch, build system, backward compatibility, ...) On Tue, Jun 3, 2014 at 12:10 PM, Salz, Rich rs...@akamai.com wrote: especially Stephen Henson, who has kept it together in much the same way as Keith Richards did the Stones. With no disrespect intended to either man, I have to say that this is an analogy that never would have occurred to me in a million years. /r$ -- Principal Security Engineer Akamai
[openssl.org #3370] 1.0.1g / Windows / patch - wrong OPENSSL_EC_NISTP_64_GCC_128 definition in ec_lcl.h
Patch applied: https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=8e3231642b89332fa56ed2b6f501e28722e2048e Thanks for your contribution. Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3372] Possible patch for typo fix in version number of dylib
Hi Lubu Thanks for your submission. However this is intentional and won't be changed. Closing this ticket. Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: AW: Which platforms will be supported in the future on which platforms will be removed?
It's a simple solution, and obvious and I don't think it'll work. This is NOT the Linux kernel, the Linux kernel is directly funded by several of the larger companies, they have employees contributing directly on the kernel, with access to internal hardware resources. OpenSSL doesn't. Yes, it has people funded by the larger companies USING OpenSSL with access to hardware resources , but they don't usually contribute directly to OpenSSL - consumers, not producers. They may contrinute the occasional patch, butthat's about it. There's a problem of scale here between the kernel and OpenSSL. Donating server scale hardware would be a punishment, not a benefit. You have to power it, you have to find space for it and it's noisy, and on the other side of the equation, there's no way those companies are going to let outsiders into their corporate networks. I think the best you'd manage is insisting that larger companies wanting support run some sort of continuous build system internally and feed results back to the OpenSSL team. Alternately, the OpenSSL team could give people from those companies checkin access - but that has more fishhooks than the obvious, export compliance is the obvious problem, but there are other issues, trust for example. Peter From: Theodore Ts'o ty...@mit.edu To: openssl-dev@openssl.org Date: 04/06/2014 12:18 AM Subject:Re: AW: Which platforms will be supported in the future on which platforms will be removed? Sent by:owner-openssl-...@openssl.org On Tue, Jun 03, 2014 at 02:22:07PM +1000, Peter Waltenberg wrote: One of the uglier problems is that unless you can build/test on all the platforms on each change you'll almost certainly break platforms unexpectedly - that lack of hardware has been one of the long term problems and it's likely one of the inhibtors to cleanup as well. There's a very simple solution to that problem, especially since we now have the support and attention of many hardware companies. The rule should be very simple. If a company doesn't contribute either (a) exclusive, dedicated hardware, or (b) reliable, continuous access to hardware, it doesn't get supported by the OpenSSL developers. Period. If it's not important for a company to provide access to hardware, then they can take on the support burdens of providing OpenSSL support to their platform, or clearly *they* don't care about the security of their users. And if they don't care, again, it's not fair to impose a security tax on the rest of the Internet. (And especially in the case of embedded products, it's not enough that OpenSSL provide a new release with a security fix; the company needs to be willing to create a firmware load and get it to all of its 10 year old customers. And if they aren't willing to provide hardware to critical infrastructure provider such as OpenSSL, it seems unlikely they will be creating a new firmware load anyway, so what's the point?) The Linux kernel doesn't tie itself in knots wringing its hands about how it can't make forward progress because it might break, say, the break the m68k or alpha port. They continue to exist only because a number of m68k and alpha maintainers are sufficiently motivated to keep them alive, *and* the impact on the core code is largely nil. If a largely dead architecture or CPU started getting in the way of everyone else, it would either have to get fixed so it wasn't getting in the way, or it would be removed. (Which, for example, was the decision of the x86 maintainers over the fate of 80386 support.) Cheers, - Ted __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: AW: Which platforms will be supported in the future on which platforms will be removed?
On Wed, Jun 04, 2014 at 09:14:18AM +1000, Peter Waltenberg wrote: This is NOT the Linux kernel, the Linux kernel is directly funded by several of the larger companies, they have employees contributing directly on the kernel, with access to internal hardware resources. Yes, and I'm saying people aren't thinking big enough. OpenSSL is critical infrastructure. There's a reason why the Linux Foundation's Critical Infrastructure Initiative is funding two people to work full time on making OpenSSL better. (ObDisclosure: I'm on the CII technical advisory board.) If there are resources you need, people should *ask*. There may be solutions you haven't thought of. For example, one mechanism that has been used before is to have the hardware donated to the Oregon State University's Open Source Lab. IBM has used this to make Power systems available to open source developers, for example. So there are ways to get access to machines without requiring that you pay for the power and hosting fees. Don't assume that the answer is that can't be done, so we need to keep horrible macros and #ifdef's and be really hesitant making changes lest we break some dead architecture that might not being maintained, or for some router company that might not take an updated OpenSSL to support some hardware which is ten years old. There may very well be solutions you haven't thought of yet. I think the best you'd manage is insisting that larger companies wanting support run some sort of continuous build system internally and feed results back to the OpenSSL team. And this is also not hard. Now that OpenSSL is using git, it's really trivially easy have companies do this and feed results back. Intel has a team in China doing this for pretty much every single major kernel developer's git tree. I can push an ext4 to a test git branch, and if I've forgotten to run sparse (a static code analyzer) and fix any problems, within *minutes* I'll get back an e-mail indicating that my pushed test code has introduced new code warnings. And this is done *before* my code hits linux-next, or Linus's mainline tree. You don't think OpenSSL isn't similarly important? And that companies won't provide similar continuous testing if you ask? Especially after all of notice that was raised after the Heartbeat scare (which admittedly wasn't even the worse SSL bug in the last couple of months), this is really a good time to ask companies for this kind of support. Cheers, - Ted __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
