Apple are, apparently, dicks...
...and don't intend to fix their broken ECDSA support in Safari. It is therefore suggested that I pull this patch: https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d What do people think? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Apple are, apparently, dicks...
On 14 June 2013 09:39, Rob Stradling wrote: > On 13/06/13 17:39, Ben Laurie wrote: >> >> ...and don't intend to fix their broken ECDSA support in Safari. > > > Ben, you've got your wires a bit crossed there. > > The ECDHE-ECDSA ciphersuites are indeed broken in Safari on OSX 10.8 to > 10.8.3, but they are _fixed_ in OSX 10.8.4 (released last week). > > >> It is therefore suggested that I pull this patch: >> >> >> https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d >> >> What do people think? > > > The unfortunate reality is that significant numbers of OSX 10.8.x users > won't upgrade to 10.8.4 anytime soon, even though the upgrade is free and > easy to install. Precisely my point - so how were my wires crossed? > No server administrator will want to deploy ECDHE-ECDSA if it means breaking > compatibility with even a small fraction of deployed browsers. Hence why > this patch is, unfortunately, necessary. What is _necessary_ is that Apple accept responsibility for their errors :-) Why are we chasing after them cleaning up their messes? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Apple are, apparently, dicks...
On 14 June 2013 12:25, Rob Stradling wrote: > On 14/06/13 10:20, Ben Laurie wrote: >> >> On 14 June 2013 09:39, Rob Stradling wrote: >>> >>> On 13/06/13 17:39, Ben Laurie wrote: >>>> >>>> >>>> ...and don't intend to fix their broken ECDSA support in Safari. >>> >>> >>> Ben, you've got your wires a bit crossed there. >>> >>> The ECDHE-ECDSA ciphersuites are indeed broken in Safari on OSX 10.8 to >>> 10.8.3, but they are _fixed_ in OSX 10.8.4 (released last week). >>> >>>> It is therefore suggested that I pull this patch: >>>> >>>> >>>> https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d >>>> >>>> What do people think? >>> >>> >>> The unfortunate reality is that significant numbers of OSX 10.8.x users >>> won't upgrade to 10.8.4 anytime soon, even though the upgrade is free and >>> easy to install. >> >> >> Precisely my point - so how were my wires crossed? > > > Ah, so you're criticizing Apple for not being willing to force all OSX > 10.8.x users to update to 10.8.4. No. > If OSX 10.8.x has a mechanism that allows Apple to force updates to be > installed, then I agree. But my suspicion is that it doesn't, and if so, > Apple's willingness isn't the key issue here. It has a mechanism to nag you endlessly until you do install updates. Which makes me wonder why you think people won't install the OS update? > > >>> No server administrator will want to deploy ECDHE-ECDSA if it means >>> breaking >>> compatibility with even a small fraction of deployed browsers. Hence why >>> this patch is, unfortunately, necessary. >> >> >> What is _necessary_ is that Apple accept responsibility for their errors >> :-) > > > Agreed. > > Sadly, the OSX 10.8.4 changelog doesn't even mention the ECDHE-ECDSA bugfix. > > >> Why are we chasing after them cleaning up their messes? > > > Because we want ECDHE-ECDSA to be deployable. > > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Apple are, apparently, dicks...
On 14 June 2013 13:57, Rob Stradling wrote: > On 14/06/13 12:31, Ben Laurie wrote: >> >> On 14 June 2013 12:25, Rob Stradling wrote: > > > >>> Ah, so you're criticizing Apple for not being willing to force all OSX >>> 10.8.x users to update to 10.8.4. >> >> >> No. >> >>> If OSX 10.8.x has a mechanism that allows Apple to force updates to be >>> installed, then I agree. But my suspicion is that it doesn't, and if so, >>> Apple's willingness isn't the key issue here. >> >> >> It has a mechanism to nag you endlessly until you do install updates. >> Which makes me wonder why you think people won't install the OS >> update? > > > Safari's User-Agent string reveals the OSX version that it is running on. A > few weeks ago I analyzed some webserver logs to get an idea of historical > OSX update rates. Based on that analysis, I forecast that the majority of > OSX 10.8.x users will install the 10.8.4 update, but that a significant > minority won't. I guess then we need to know why? And would they upgrade Safari alone? > > >>>>> No server administrator will want to deploy ECDHE-ECDSA if it means >>>>> breaking >>>>> compatibility with even a small fraction of deployed browsers. Hence >>>>> why >>>>> this patch is, unfortunately, necessary. >>>> >>>> >>>> >>>> What is _necessary_ is that Apple accept responsibility for their errors >>>> :-) >>> >>> >>> >>> Agreed. >>> >>> Sadly, the OSX 10.8.4 changelog doesn't even mention the ECDHE-ECDSA >>> bugfix. >>> >>> >>>> Why are we chasing after them cleaning up their messes? >>> >>> >>> >>> Because we want ECDHE-ECDSA to be deployable. >>> >>> >>> -- >>> Rob Stradling >>> Senior Research & Development Scientist >>> COMODO - Creating Trust Online >>> >> > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > Office Tel: +44.(0)1274.730505 > Office Fax: +44.(0)1274.730909 > www.comodo.com > > COMODO CA Limited, Registered in England No. 04058690 > Registered Office: > 3rd Floor, 26 Office Village, Exchange Quay, > Trafford Road, Salford, Manchester M5 3EQ > > This e-mail and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify the sender by > replying to the e-mail containing this attachment. Replies to this email may > be monitored by COMODO for operational or business reasons. Whilst every > endeavour is taken to ensure that e-mails are free from viruses, no > liability can be accepted and the recipient is requested to use their own > virus checking software. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Apple are, apparently, dicks...
On 14 June 2013 13:54, The Doctor wrote: > On Thu, Jun 13, 2013 at 05:39:36PM +0100, Ben Laurie wrote: >> ...and don't intend to fix their broken ECDSA support in Safari. >> >> It is therefore suggested that I pull this patch: >> >> https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d >> >> What do people think? > > No keep the patch. I am not sure what you mean by this. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Apple are, apparently, dicks...
On 14 June 2013 14:08, Rob Stradling wrote: > On 14/06/13 13:58, Ben Laurie wrote: >> >> On 14 June 2013 13:57, Rob Stradling wrote: > > > >>> Safari's User-Agent string reveals the OSX version that it is running on. >>> A >>> few weeks ago I analyzed some webserver logs to get an idea of historical >>> OSX update rates. Based on that analysis, I forecast that the majority >>> of >>> OSX 10.8.x users will install the 10.8.4 update, but that a significant >>> minority won't. >> >> >> I guess then we need to know why? And would they upgrade Safari alone? > > > Apparently the ECDHE-ECDSA bug is in SecureTransport, which is an integral > component of OSX. https://developer.apple.com/library/mac/#documentation/security/Reference/secureTransportRef/Reference/reference.html seems to suggest it is a library. > > >>>>>>> No server administrator will want to deploy ECDHE-ECDSA if it means >>>>>>> breaking >>>>>>> compatibility with even a small fraction of deployed browsers. Hence >>>>>>> why >>>>>>> this patch is, unfortunately, necessary. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> What is _necessary_ is that Apple accept responsibility for their >>>>>> errors >>>>>> :-) >>>>> >>>>> >>>>> >>>>> >>>>> Agreed. >>>>> >>>>> Sadly, the OSX 10.8.4 changelog doesn't even mention the ECDHE-ECDSA >>>>> bugfix. >>>>> >>>>> >>>>>> Why are we chasing after them cleaning up their messes? >>>>> >>>>> >>>>> >>>>> >>>>> Because we want ECDHE-ECDSA to be deployable. >>>>> >>>>> >>>>> -- >>>>> Rob Stradling >>>>> Senior Research & Development Scientist >>>>> COMODO - Creating Trust Online >>>>> >>>> >>> >>> -- >>> Rob Stradling >>> Senior Research & Development Scientist >>> COMODO - Creating Trust Online >>> Office Tel: +44.(0)1274.730505 >>> Office Fax: +44.(0)1274.730909 >>> www.comodo.com >>> >>> COMODO CA Limited, Registered in England No. 04058690 >>> Registered Office: >>>3rd Floor, 26 Office Village, Exchange Quay, >>>Trafford Road, Salford, Manchester M5 3EQ >>> >>> This e-mail and any files transmitted with it are confidential and >>> intended >>> solely for the use of the individual or entity to whom they are >>> addressed. >>> If you have received this email in error please notify the sender by >>> replying to the e-mail containing this attachment. Replies to this email >>> may >>> be monitored by COMODO for operational or business reasons. Whilst every >>> endeavour is taken to ensure that e-mails are free from viruses, no >>> liability can be accepted and the recipient is requested to use their own >>> virus checking software. >> >> > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > Office Tel: +44.(0)1274.730505 > Office Fax: +44.(0)1274.730909 > www.comodo.com > > COMODO CA Limited, Registered in England No. 04058690 > Registered Office: > 3rd Floor, 26 Office Village, Exchange Quay, > Trafford Road, Salford, Manchester M5 3EQ > > This e-mail and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify the sender by > replying to the e-mail containing this attachment. Replies to this email may > be monitored by COMODO for operational or business reasons. Whilst every > endeavour is taken to ensure that e-mails are free from viruses, no > liability can be accepted and the recipient is requested to use their own > virus checking software. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Apple are, apparently, dicks...
On 14 June 2013 16:10, Bodo Moeller wrote: > >>> Note that the patch changes the value of SSL_OP_ALL so if OpenSSL shared >>> libraries are updated to include the patch existing applications wont set >>> it: >>> they'd all need to be recompiled. >> >> >> That's a valid point. > > > This is true, unfortunately. > > >> >> >> >>> Possibly alternative is to reuse one of the existing *ancient* flags. >>> Does >>> anyone really care about compatibility with a bug in SSLeay 0.80 for >>> example? >> >> >> Wouldn't it be better to reverse the meaning of the flag and not set it in >> SSL_OP_ALL? > > > Hm, without any SSL_OP_... settings, the expectation generally is that we > kind of sort of follow the specs and don't do any weird stuff like this for > interoperability's sake. If we switch semantics around for certain options, > the resulting inconsistencies would make all that even more confusing. > > In theory we could create an explicit "SSL_OP_ALL"-equivalent bit > (SSL_OP_ALL_ALL?) that enables all current SSL_OP_ALL features and doesn't > allow further masking, but that seems hard to deploy given that some current > applications may expressly want SSL_OP_ALL *without* certain flags. Of > course the legacy flag an application disables could be the one that we're > about to recycle ... SSL_OP_ALL ideally would always have included some > unused bits for future use, but that again is hard to pull off retroactively > -- it's probably a good idea for a later release (with an incompatible .so > version so that we can safely change SSL_OP_ALL). > > If we can find an appropriate ancient flag that no one should care about > (which sounds plausible), recycling that one sounds like a good idea. If we > can't, using reverted semantics might be the best option we have. We could just add an SSL_OP_ALL_FROM_FUTURE flag that did this, and leave SSL_OP_ALL as it is? If you really want to get funky, you could make it so any bit set with SSL_OP_ALL_FROM_FUTURE disables the corresponding feature. This would mean you could never re-use bits, tho... __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: parallel make broken
On 18 June 2013 22:35, Mike Frysinger wrote: > On Tuesday 18 June 2013 07:37:55 Richard Weinberger wrote: >> While building openssl-1.0.1e I noticed that the parallel build >> is broken. > > yes, it's pretty much always been broken > >> I found this patch on the net: >> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/openssl/fi >> les/openssl-1.0.1-parallel-build.patch With it applied openssl builds fine >> in parallel. > > heh, you've found me! the referenced ticket says it's been merged, but it > doesn't seem that way (at least for the latest branch). You are right it hasn't been merged. One problem with it is it doesn't work with BSD make (BSD make doesn't understand | in dependencies). > the feedback loop > w/the rt tracker has been kind of bad, so i lose incentive to fix keep posting > patches. > > the other thing you should do is to run: > make -j1 depend > make -jN > -mike __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [Patch] ALPN Implementation for OpenSSL
On 20 June 2013 21:46, Jeff Mendoza (MS OPEN TECH) wrote: >> -Original Message- >> From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] >> On Behalf Of Piotr Sikora >> Sent: Thursday, June 20, 2013 10:41 AM >> To: openssl-dev@openssl.org >> Subject: Re: [Patch] ALPN Implementation for OpenSSL >> >> We simply cannot drop support for NPN (i.e. SPDY) just to add support for >> ALPN. > > The idea is to have the choice as a ./config option. The default will stay as > NPN, as to not disrupt anyone. I don't have this in the patch yet. That doesn't make any sense. How would a server serve both NPN and ALPN? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [Patch] ALPN Implementation for OpenSSL
On 21 June 2013 02:29, Thor Lancelot Simon wrote: > On Thu, Jun 20, 2013 at 09:30:32PM +, Jeff Mendoza (MS OPEN TECH) wrote: >> > Yeah, my point was that in the perfect world, you'd support both at >> > runtime (at least on the server-side) and either ALPN or NPN could be >> > used. I want to have a library that supports both, not either-or. >> >> Yes, supporting both at runtime would be best. But having a compile-time >> option now, and defaulting to NPN should keep this from being a blocking >> issue with the patch, correct? > > I don't speak for the OpenSSL project, but I'd suggest they should treat > it as one. It positively reeks of "embrace and extend". After all, the > effect is to force all build systems producing system default packages > of OpenSSL to pick one way or the other, ensuring that both won't work > at the same time. That's not really "embrace and extend", but nevertheless it seems like an unacceptable design choice. I suggest you need to figure out how to make both ALPN and NPN work in a single build to have any chance of acceptance at all. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: parallel make broken
On 22 June 2013 19:04, Mike Frysinger wrote: > On Wednesday 19 June 2013 07:21:39 Ben Laurie wrote: >> On 18 June 2013 22:35, Mike Frysinger wrote: >> > On Tuesday 18 June 2013 07:37:55 Richard Weinberger wrote: >> >> While building openssl-1.0.1e I noticed that the parallel build >> >> is broken. >> > >> > yes, it's pretty much always been broken >> > >> >> I found this patch on the net: >> >> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/openssl >> >> /fi les/openssl-1.0.1-parallel-build.patch With it applied openssl >> >> builds fine in parallel. >> > >> > heh, you've found me! the referenced ticket says it's been merged, but >> > it doesn't seem that way (at least for the latest branch). >> >> You are right it hasn't been merged. One problem with it is it doesn't >> work with BSD make (BSD make doesn't understand | in dependencies). > > true, but the patch posted to RT didn't include that, and that usage shows up > only twice in the current Gentoo patch. plenty of the other parts can be > merged now so it's not nearly as terrible. > > i wonder if the | can be written instead like: > lib: > $(MAKE) subdirs > $(MAKE) $(LIB) > @touch lib > $(LIB): $(LIBOBJ) > ... I don't know, but FWIW, I've also been working on -j stuff, but using the mk1mf script (see the GitConfigure and GitMake scripts in master and 1.0.2). My version is at least twice as fast as yours - on my machine :-) Possibly the right answer is to simply move to a single makefile... __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: parallel make broken
On 22 June 2013 23:06, Mike Frysinger wrote: > On Saturday 22 June 2013 15:07:49 Ben Laurie wrote: >> On 22 June 2013 19:04, Mike Frysinger wrote: >> > On Wednesday 19 June 2013 07:21:39 Ben Laurie wrote: >> >> On 18 June 2013 22:35, Mike Frysinger wrote: >> >> > On Tuesday 18 June 2013 07:37:55 Richard Weinberger wrote: >> >> >> While building openssl-1.0.1e I noticed that the parallel build >> >> >> is broken. >> >> > >> >> > yes, it's pretty much always been broken >> >> > >> >> >> I found this patch on the net: >> >> >> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/open >> >> >> ssl /fi les/openssl-1.0.1-parallel-build.patch With it applied >> >> >> openssl builds fine in parallel. >> >> > >> >> > heh, you've found me! the referenced ticket says it's been merged, >> >> > but it doesn't seem that way (at least for the latest branch). >> >> >> >> You are right it hasn't been merged. One problem with it is it doesn't >> >> work with BSD make (BSD make doesn't understand | in dependencies). >> > >> > true, but the patch posted to RT didn't include that, and that usage >> > shows up only twice in the current Gentoo patch. plenty of the other >> > parts can be merged now so it's not nearly as terrible. >> > >> > i wonder if the | can be written instead like: >> > lib: >> > $(MAKE) subdirs >> > $(MAKE) $(LIB) >> > @touch lib >> > $(LIB): $(LIBOBJ) >> > ... >> >> I don't know, but FWIW, I've also been working on -j stuff, but using >> the mk1mf script (see the GitConfigure and GitMake scripts in master >> and 1.0.2). My version is at least twice as fast as yours - on my >> machine :-) > > to be fair, i was just trying to make it work rather than rewrite things > > unfortunately mk1mf is a perl script, and i've been doing my damnedest to make > sure perl isn't a requirement to build a base system. we've been able to > avoid this so far w/openssl ... Well, you need perl to run Configure already, so presumably you do that in advance. You could do the same with mk1mf. > >> Possibly the right answer is to simply move to a single makefile... > > that might work > -mike __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [Patch] ALPN Implementation for OpenSSL
On 24 June 2013 22:00, Jeff Mendoza (MS OPEN TECH) wrote: >> >> We simply cannot drop support for NPN (i.e. SPDY) just to add support >> >> for ALPN. >> > >> > The idea is to have the choice as a ./config option. The default will >> stay as NPN, as to not disrupt anyone. I don't have this in the patch yet. >> >> That doesn't make any sense. How would a server serve both NPN and ALPN? > > Ben, does the proposed solution (on the other thread) work for you? Sounds OK to me, yes. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Fwd: [Foundations] 2013 Doc Camp CFP
Since people are always complaining about OpenSSL docs, I thought this might be of interest. -- Forwarded message -- From: adam Date: 1 August 2013 08:23 Subject: [Foundations] 2013 Doc Camp CFP To: Foundations List hi If any projects on the list are lacking good documentation (surely no one here ;) then consider applying for the 2013 Doc Camp. The CFP is open to any free software project or any individual to apply. Its a great event: http://www.flossmanuals.org/news/2013-doc-camp-call-proposals Apps close Aug 7. Not only is it productive (each project walks away with a book) its a heap of fun and great for building out your documentation volunteer base adam ___ foundations mailing list foundati...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/foundations __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
bsdmake mystery
I'm trying to figure out why bsdmake on MacOS does this using the standard Makefiles: cc -c -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wall -pedantic -DPEDANTIC -Wno-long-long -Wsign-compare -Wmissing-prototypes -Wshadow -Wformat -Werror -DCRYPTO_MDEBUG_ALL -DCRYPTO_MDEBUG_ABORT -DREF_CHECK -DOPENSSL_NO_DEPRECATED -Wno-language-extension-token -Wno-extended-offsetof -arch x86_64 -O3 -DL_ENDIAN -DMD32_REG_T=int -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -c -o x86_64cpuid.o x86_64cpuid.s but does this when using the single makefile: as -o tmp.master/x86_64cpuid.o tmp.master/x86_64cpuid.s anyone got any ideas? Its driving me crazy (and stops the single makefile from working on macos). AFAICS, both routes should use a .s.o rule which invokes as, so ... wtf? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: AES GCM considerations in regards to SP800-38D
On 15 August 2013 09:21, Tomas Mraz wrote: > Hello OpenSSL developers, > > in a review of the AES GCM code it was found that there might be some > requirements that are placed by SP800-38D document missing. > > Especially there is no checking that the key is not used with more than > 2^32 different IV values. Did I overlook it and the test is there? Or is > the test not needed because in real life situation this cannot happen? I > suppose it might happen if the key is not renegotiated during lengthy > connections with transfer of data in TB range? > How would you propose that the code tests this property? > -- > Tomas Mraz > No matter how far down the wrong road you've gone, turn back. > Turkish proverb > (You'll never know whether the road is wrong though.) > > __ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager majord...@openssl.org >
Re: bsdmake mystery
Thanks for this ... haven't had the chance to test it yet (travel) but will do shortly. On 12 August 2013 05:49, Andy Polyakov wrote: > > I'm trying to figure out why bsdmake on MacOS does this using the > > standard Makefiles: > > > > cc -c -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT > > -DDSO_DLFCN -DHAVE_DLFCN_H -Wall -pedantic -DPEDANTIC -Wno-long-long > > -Wsign-compare -Wmissing-prototypes -Wshadow -Wformat -Werror > > -DCRYPTO_MDEBUG_ALL -DCRYPTO_MDEBUG_ABORT -DREF_CHECK > > -DOPENSSL_NO_DEPRECATED -Wno-language-extension-token > > -Wno-extended-offsetof -arch x86_64 -O3 -DL_ENDIAN -DMD32_REG_T=int > > -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 > > -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM > > -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -c -o > > x86_64cpuid.o x86_64cpuid.s > > > > but does this when using the single makefile: > > > > as -o tmp.master/x86_64cpuid.o tmp.master/x86_64cpuid.s > > > > anyone got any ideas? Its driving me crazy (and stops the single > > makefile from working on macos). > > > > AFAICS, both routes should use a .s.o rule which invokes as, so ... wtf? > > From Makefile. > > ... > ASFLAG=$(CFLAG) > > BUILD_CMD=... $(MAKE) -e $(BUILDENV) ... > > build_crypto: > ... AS='$(CC) -c' ... > $(BUILD_ONE_CMD) > ... > > For reference, idea behind -e $(BUILDENV) is to achieve consistent > behaviour among different make flavours, BSD vs. SysV. > > For unification sake, i.e. to harmonize rules usage on all platforms, it > might be appropriate to switch to .S on x86_64. I mean a number of > platforms use .S files as output from perlasm scripts, i.e. assembly > code that needs C pre-processing, which can arguably serve as common > denominator for all platforms. > > __ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager majord...@openssl.org >
Re: [openssl] OpenSSL source code branch supplemental-data-api-2 updated. 85b2ca671513df2b21df404d3dfa76cf681e553d
FWIW, I pushed this to the openssl repo instead of my own by mistake, but I guess since it is in a branch its not that big a deal. On 5 September 2013 14:45, Ben Laurie wrote: > This is an automated email from the git hooks/post-receive script. It was > generated because a ref change was pushed to the repository containing > the project "OpenSSL source code". > > The branch, supplemental-data-api-2 has been updated >via 85b2ca671513df2b21df404d3dfa76cf681e553d (commit) >via 0314741417bf45549bab1c94a49b33d40476d844 (commit) >via 6381b3cbcd8e8626f3fdfcfd54ed5a1a980847dd (commit) >via a66d5a4a77bc086c9eff36a096e9e74d8bca8be5 (commit) >via 976fac84e0920feb9aaa9cb67002c4eb64bccde8 (commit) >via b3943dbb18ea920c6bd71a52762ba16728e27e3d (commit) >via 65616e81a11106002e0d4509de2b0507e83cca44 (commit) >via e21ff60d6146868fdfed8cb0795ac8a36f8b7db8 (commit) > from 664c69432740670e8d93e0fd8d8d29f84b15fe3d (commit) > > Those revisions listed above that are new to this repository have > not appeared on any other notification email; so we list those > revisions in full, below. > > - Log - > commit 85b2ca671513df2b21df404d3dfa76cf681e553d > Merge: 664c694 0314741 > Author: Ben Laurie > Date: Thu Sep 5 14:45:25 2013 +0100 > > Merge remote-tracking branch 'scott2/ben-openssl' into > supplemental-data-api-2 > > Conflicts: > apps/s_client.c > apps/s_server.c > > commit 0314741417bf45549bab1c94a49b33d40476d844 > Author: Scott Deboy > Date: Thu Aug 1 11:54:09 2013 -0700 > > Free generated supp data after handshake completion, add comment > regarding use of num_renegotiations in TLS and supp data generation > callbacks > > commit 6381b3cbcd8e8626f3fdfcfd54ed5a1a980847dd > Author: Ben Laurie > Date: Thu Aug 1 15:17:23 2013 +0100 > > More cleanup. > > commit a66d5a4a77bc086c9eff36a096e9e74d8bca8be5 > Author: Ben Laurie > Date: Thu Aug 1 12:33:15 2013 +0100 > > More cleanup. > > commit 976fac84e0920feb9aaa9cb67002c4eb64bccde8 > Author: Ben Laurie > Date: Thu Aug 1 11:14:23 2013 +0100 > > Make it build. > > commit b3943dbb18ea920c6bd71a52762ba16728e27e3d > Author: Scott Deboy > Date: Wed Jul 31 11:28:30 2013 -0700 > > Remove end-of-line whitespace, change an int i to size_t i > > commit 65616e81a11106002e0d4509de2b0507e83cca44 > Merge: e21ff60 0b2bde7 > Author: Scott Deboy > Date: Wed Jul 31 10:51:19 2013 -0700 > > Merge remote-tracking branch 'openssl-github/master' into > supplemental-data-api > > Conflicts: > ssl/s23_clnt.c > ssl/ssl_rsa.c > > commit e21ff60d6146868fdfed8cb0795ac8a36f8b7db8 > Author: Scott Deboy > Date: Tue Jun 18 14:34:38 2013 -0700 > > Add callbacks supporting generation and retrieval of supplemental data > entries, facilitating RFC 5878 (TLS auth extensions) > Removed prior audit proof logic - audit proof support was implemented > using the generic TLS extension API > Tests exercising the new supplemental data registration and callback > api can be found in ssltest.c. > Implemented changes to s_server and s_client to exercise supplemental > data callbacks via the -auth argument, as well as additional flags to > exercise supplemental data being sent only during renegotiation. > > --- > > Summary of changes: > apps/s_client.c | 24 ++-- > apps/s_server.c | 24 ++-- > 2 files changed, 36 insertions(+), 12 deletions(-) > > diff --git a/apps/s_client.c b/apps/s_client.c > index a17917c..fa98d5b 100644 > --- a/apps/s_client.c > +++ b/apps/s_client.c > @@ -225,8 +225,10 @@ static int c_brief=0; > > #ifndef OPENSSL_NO_TLSEXT > > -static const unsigned char *most_recent_supplemental_data; > -static size_t most_recent_supplemental_data_length; > +static unsigned char *generated_supp_data = NULL; > + > +static unsigned char *most_recent_supplemental_data = NULL; > +static size_t most_recent_supplemental_data_length = 0; > > static int server_provided_server_authz = 0; > static int server_provided_client_authz = 0; > @@ -1768,6 +1770,13 @@ SSL_set_tlsext_status_ids(con, ids); > "CONNECTION > ESTABLISHED\n"); > print_ssl_summary(bio_err, con); > } > + /*handshake is complete - free the > generated su
Re: [openssl] OpenSSL source code branch master updated. 5e3ff62c345c976cd1ffbcc5e6042f55264977f5
On 8 September 2013 13:35, Dr. Stephen Henson wrote: > > To enable it set the appropriate extension number (0x10 for the test > server) > using e.g. -DTLSEXT_TYPE_encrypt_then_mac=0x10 That's unfortunate, 16 is already allocated: http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml
Re: [openssl.org #3125] [PATCH 1.0.1e] openssl/crypto/armcap.c: fix a typo in OPENSSL_rdtsc
I find these easier to deal with as pull requests...
On 12 September 2013 17:14, Kyle McMartin via RT wrote:
> a | 1 is always true, regardless of OPENSSL_armcap_P, and
> mrc cp15 will fail on <= v6.
>
> --- a/crypto/armcap.c
> +++ b/crypto/armcap.c
> @@ -23,7 +23,7 @@ unsigned int _armv7_tick(void);
>
> unsigned int OPENSSL_rdtsc(void)
> {
> - if (OPENSSL_armcap_P|ARMV7_TICK)
> + if (OPENSSL_armcap_P & ARMV7_TICK)
> return _armv7_tick();
> else
> return 0;
>
> __
> OpenSSL Project http://www.openssl.org
> Development Mailing List openssl-dev@openssl.org
> Automated List Manager majord...@openssl.org
>
Re: [openssl.org #3124] potential bug in ssl/s3_cbc.c
On 12 September 2013 17:14, Arthur Mesh via RT wrote:
> I am not 100% sure this is a real bug, hence first tried mailing
> openssl-users instead of rt@. But since there was no reply, I am sending
> this to rt@
>
>
> 641 if (is_sslv3)
> 642 {
>
> 647 unsigned overhang =
> header_length-md_block_size;
> 648 md_transform(md_state.c, header);
> 649 memcpy(first_block, header + md_block_size,
> overhang);
>
> My suspicion lies in line 649, where we're copying overhang number of bytes
> from (header + md_block_size). I believe that copying from (header +
> md_block_size) is out-of-bound access (overrun).
>
> header is an array of 13 unsigned chars, and md_block_size == 64 (or 128
> in some
> cases). Hence (header + md_block_size) points outside of header[13].
> Assuming
> overhang > 0, by doing a memcpy(), we have a problem, no?
>
Well, in fact, this code is only run when |is_sslv3|, and in that case,
|header| is actually 75 bytes. So, the documentation is at fault.
But I guess an interesting question is: can |md_block_size| be 128 when
|is_sslv3|?
Mixing time into the pool
I just pushed 3cd8547a2018ada88a4303067a2aa15eadc17f39 to master, which adds time to the random pool. Before I cherry-pick back to earlier branches, it'd be nice if people let me know about any platform dependencies...
Re: bsdmake mystery
I finally got around to taking another look at this. The next weird thing is MacOS thinks it _is_ a .S file, even though there's only mention of .s in the makefile. MacOS is, of course, case-insensitive, which probably doesn't help. On 19 August 2013 15:39, Ben Laurie wrote: > Thanks for this ... haven't had the chance to test it yet (travel) but will > do shortly. > > > On 12 August 2013 05:49, Andy Polyakov wrote: >> >> > I'm trying to figure out why bsdmake on MacOS does this using the >> > standard Makefiles: >> > >> > cc -c -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT >> > -DDSO_DLFCN -DHAVE_DLFCN_H -Wall -pedantic -DPEDANTIC -Wno-long-long >> > -Wsign-compare -Wmissing-prototypes -Wshadow -Wformat -Werror >> > -DCRYPTO_MDEBUG_ALL -DCRYPTO_MDEBUG_ABORT -DREF_CHECK >> > -DOPENSSL_NO_DEPRECATED -Wno-language-extension-token >> > -Wno-extended-offsetof -arch x86_64 -O3 -DL_ENDIAN -DMD32_REG_T=int >> > -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 >> > -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM >> > -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -c -o >> > x86_64cpuid.o x86_64cpuid.s >> > >> > but does this when using the single makefile: >> > >> > as -o tmp.master/x86_64cpuid.o tmp.master/x86_64cpuid.s >> > >> > anyone got any ideas? Its driving me crazy (and stops the single >> > makefile from working on macos). >> > >> > AFAICS, both routes should use a .s.o rule which invokes as, so ... wtf? >> >> From Makefile. >> >> ... >> ASFLAG=$(CFLAG) >> >> BUILD_CMD=... $(MAKE) -e $(BUILDENV) ... >> >> build_crypto: >> ... AS='$(CC) -c' ... >> $(BUILD_ONE_CMD) >> ... >> >> For reference, idea behind -e $(BUILDENV) is to achieve consistent >> behaviour among different make flavours, BSD vs. SysV. >> >> For unification sake, i.e. to harmonize rules usage on all platforms, it >> might be appropriate to switch to .S on x86_64. I mean a number of >> platforms use .S files as output from perlasm scripts, i.e. assembly >> code that needs C pre-processing, which can arguably serve as common >> denominator for all platforms. >> >> __ >> 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: Self-initialization of locking/threadid callbacks and auto-detection of features
On 22 October 2013 06:47, Nico Williams wrote: > On Monday, October 21, 2013, Salz, Rich wrote: > >> I like your proposal, but I'd prefer to see an "already initialized" >> error code returned. Or a flag to the (new?) init api that says "ignore if >> already set" >> > > Thanks for your reply! > > I can add an error, but note that the caller can set then get the > callbacks and compare to check whether the caller's callbacks were taken. > I could also add a new set of callback setters with ignore-if-set flags. > As long as the existing ones behave reliably in the already-set case. > > In the already-set case I think it may well be best to ignore without > failing on the theory that the caller that first set the callbacks must > have set sufficiently useful ones anyways... and that where the OS has a > good enough default threading library, that's the one that will be used by > all DSOs calling OpenSSL in the same process, as otherwise all hell would > already be breaking loose anyways! (I can imagine twisted cases where this > would not be true, but they seem exceedingly unlikely.) > > If you want to see the half-baked bits I have (which build on Linux, but > which aren't tested) to see what I'm up to, see > https://github.com/nicowilliams/openssl, specifically the thread_safety > branch. See the XXX comments in rand_lib.c in particular. The outline: > add a thread-safe one-time initialization function, built on whatever the > OS provides, then use that to make callback init thread-safe. > > What I need to know: > > - should i add new targets to ./Configure? for now I modified the > linux-elf target, but this feels wrong to me. > > - what about Windows? I either need to have different targets for > pre-vista/2008 or. i have to write a once initialization function for older > Windows (which I can and know how to do, it's just more work that, and in > particular i couldn't test it, so I'm not inclined to do it). > > - if so, should ./config automatically pick the new targets where there > is appropriate threading support? > I've been musing about a more autoconf-like approach for some time now (but, for the love of all that is fluffy, not using autoconf itself, which sucks) - it seems this is a good reason to go down that path. Interesting question is: what to do if no appropriate locking mechanism is discovered? > > - how to allocate error codes for "already initialized" errors that you > suggest? > > - should I work to make sure that it's possible to change the default > RAND method after it's been set once? > >The code in rand_lib.c is currently fundamentally thread-unsafe, though > it could be accidentally thread-safe if, e.g., ENGINE_finish() doesn't > actually tear down state at all. The simplest fix involves setting the > default only once, as wih the callbacks, but here I feel that's a shaky > idea, that I should allow RAND method changes at any time, in a thread-safe > manner -- more work for me, but less surprising. > > Nico > -- > > (sent from a mobile device with lousy typing options, and no plain text > button) > (my patches need rebasing to squash and split up, need tests, need > finishing, but if you have comments I would love them sooner than later! :) >
Re: Avoid multiple locks in FIPS mode commit to OpenSSL_1_0_1-stable
On 11 December 2013 08:55, Tomas Mraz wrote: > On Út, 2013-12-10 at 14:45 +0100, Dr. Stephen Henson wrote: >> On Mon, Dec 09, 2013, geoff_l...@mcafee.com wrote: >> >> > Shouldn't the code read: >> > >> > if (!FIPS_mode()) >> > CRYPTO_w_[un]lock(CRYPTO_LOCK_RAND); >> > >> > Note the '!' operator. >> > >> >> Yes it should, sorry about that. Fixed now. > > But given skipping the locking in the FIPS mode doesn't that mean that > the reseed operation is now not being protected under lock at all? The > FIPS DRBG does not lock before calling the add/reseed callbacks. Why would you need a lock? FIPS compliant modules are single threaded... (Yes, I know this is stupid). __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3203] Normalize PFS key exchange labels
On 20 December 2013 18:51, Stephen Henson via RT wrote: > On Fri Dec 20 19:04:32 2013, d...@fifthhorseman.net wrote: >> >> I can do whatever you think is most useful, but i need a bit more >> guidance to be sure i'm giving you what will be most useful for you. >> > > I've pulled the update now, thanks. > > Well I have to admit to being far from a git expert. For me it's best if it's > easy to get the patches with commit messages and authorship somewhere I can > review them. If I manually have to apply multiple patches and add appropriate > credit it's a pain. Pull requests on Github are quite useful - that way they also get tracked (so long as we remember to close them when applied, that is!). __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3203] Normalize PFS key exchange labels
On 1 January 2014 21:39, Daniel Kahn Gillmor wrote: > On 01/01/2014 12:48 PM, Ben Laurie wrote: >> Pull requests on Github are quite useful - that way they also get >> tracked (so long as we remember to close them when applied, that is!). > > OK, i've rebased the series against the current master, and submitted a > github-specific pull request: > > https://github.com/openssl/openssl/pull/37 Cool, tho didn't I read that Steve already pulled it? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
How to help OpenSSL
Note that this is just how to help me, not a consensus view from the whole team, though I have no doubt much of it will be helpful to the team, too. 1. Triage RT (https://rt.openssl.org/). RT has been neglected for a long time. People could usefully go through it and identify: a) Tickets that can be closed b) Tickets that should have action taken, and how urgent that action is. If a ticket describes a potential security issue, then please don't just announce it to the list. Instead send it to openssl-secur...@openssl.org. In order to avoid duplication of effort, perhaps someone should set up a github repo (or something else) assigning ranges to volunteers? It might also be useful to use the same repo to hold the triage results (so things can be ticked off as they are actioned). See also points 3, 4 and 5. 2. Triage Github pull requests There are less of these, and I do try to look at them from time to time, nevertheless I think we are behind. 3. Write fixes Where an issue does not come with a patch, write a fix for it. Please try to remain consistent with local style (yes, I know style is all over the place, sorry about that, but there's no need to make it worse). Please make sure fixes build and that "make test" passes. 4. Convert fixes to pull requests Pull requests are the easiest way to deal with incoming code. Note: please _don't_ make public pull requests for security issues! 5. Port pull requests across all branches Whilst it is often possible to cherry-pick pulls across the branches, it also fairly often fails. Having someone do the legwork to fix that is very helpful (or say that the pull works across all branches). 6. Write new tests Our test suite sucks. More tests is better. NOTE: I have not suddenly got more time to deal with OpenSSL stuff, so this process may well result in a backlog, but it will certainly make the use of what time I have more efficient. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
How to help OpenSSL
Note that this is just how to help me, not a consensus view from the whole team, though I have no doubt much of it will be helpful to the team, too. 1. Triage RT (https://rt.openssl.org/). RT has been neglected for a long time. People could usefully go through it and identify: a) Tickets that can be closed b) Tickets that should have action taken, and how urgent that action is. If a ticket describes a potential security issue, then please don't just announce it to the list. Instead send it to openssl-secur...@openssl.org. In order to avoid duplication of effort, perhaps someone should set up a github repo (or something else) assigning ranges to volunteers? It might also be useful to use the same repo to hold the triage results (so things can be ticked off as they are actioned). See also points 3, 4 and 5. 2. Triage Github pull requests There are less of these, and I do try to look at them from time to time, nevertheless I think we are behind. 3. Write fixes Where an issue does not come with a patch, write a fix for it. Please try to remain consistent with local style (yes, I know style is all over the place, sorry about that, but there's no need to make it worse). Please make sure fixes build and that "make test" passes. 4. Convert fixes to pull requests Pull requests are the easiest way to deal with incoming code. Note: please _don't_ make public pull requests for security issues! 5. Port pull requests across all branches Whilst it is often possible to cherry-pick pulls across the branches, it also fairly often fails. Having someone do the legwork to fix that is very helpful (or say that the pull works across all branches). 6. Write new tests Our test suite sucks. More tests is better. NOTE: I have not suddenly got more time to deal with OpenSSL stuff, so this process may well result in a backlog, but it will certainly make the use of what time I have more efficient. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: How to help OpenSSL
I should've said: if a fix is for a potential security issue, please don't create a pull request (they are public), instead send a patch to openssl-secur...@openssl.org. You can create an appropriate patch file by doing something like this: $ git format-patch --stdout > your.patch On 24 April 2014 10:06, Ben Laurie wrote: > Note that this is just how to help me, not a consensus view from the > whole team, though I have no doubt much of it will be helpful to the > team, too. > > 1. Triage RT (https://rt.openssl.org/). > > RT has been neglected for a long time. People could usefully go > through it and identify: > > a) Tickets that can be closed > > b) Tickets that should have action taken, and how urgent that action is. > > If a ticket describes a potential security issue, then please don't > just announce it to the list. Instead send it to > openssl-secur...@openssl.org. > > In order to avoid duplication of effort, perhaps someone should set up > a github repo (or something else) assigning ranges to volunteers? It > might also be useful to use the same repo to hold the triage results > (so things can be ticked off as they are actioned). > > See also points 3, 4 and 5. > > 2. Triage Github pull requests > > There are less of these, and I do try to look at them from time to > time, nevertheless I think we are behind. > > 3. Write fixes > > Where an issue does not come with a patch, write a fix for it. Please > try to remain consistent with local style (yes, I know style is all > over the place, sorry about that, but there's no need to make it > worse). > > Please make sure fixes build and that "make test" passes. > > 4. Convert fixes to pull requests > > Pull requests are the easiest way to deal with incoming code. Note: > please _don't_ make public pull requests for security issues! > > 5. Port pull requests across all branches > > Whilst it is often possible to cherry-pick pulls across the branches, > it also fairly often fails. Having someone do the legwork to fix that > is very helpful (or say that the pull works across all branches). > > 6. Write new tests > > Our test suite sucks. More tests is better. > > NOTE: I have not suddenly got more time to deal with OpenSSL stuff, so > this process may well result in a backlog, but it will certainly make > the use of what time I have more efficient. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Attribution of pull requests in git
I just noticed that if I merge a pull request, then both author and committer are set to whoever made the pull request. >From the POV of figuring out what went wrong, when things go wrong, that seems bad. Is there an easy way to fix that? That is, I would expect it to show me as the committer and the original author as the author. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: How to help OpenSSL
On 24 April 2014 18:44, Mike Bland wrote: > On Thu, Apr 24, 2014 at 1:31 PM, Ben Laurie wrote: >> >> 6. Write new tests >> >> Our test suite sucks. More tests is better. > > > Shall I send a pull request for this: > > https://github.com/mbland/openssl/commit/a7a9e18b550edf059dfd54683ac1f45170ff9fb2 Yes, please! Ideally, as I say, for all branches. Have you verified that the test fails pre-fix? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: How to help OpenSSL
On 25 April 2014 00:08, Matt Caswell wrote: > Ben - Is it possible for some of us to get RT users created? The above > assumes we can configure RT statuses - is this possible? I think you now have RT access, right? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: How to help OpenSSL
On 24 April 2014 19:54, Kurt Roeckx wrote: > On Thu, Apr 24, 2014 at 06:31:34PM +0100, Ben Laurie wrote: >> Note that this is just how to help me, not a consensus view from the >> whole team, though I have no doubt much of it will be helpful to the >> team, too. >> >> 1. Triage RT (https://rt.openssl.org/). >> >> RT has been neglected for a long time. People could usefully go >> through it and identify: >> >> a) Tickets that can be closed >> >> b) Tickets that should have action taken, and how urgent that action is. >> >> If a ticket describes a potential security issue, then please don't >> just announce it to the list. Instead send it to >> openssl-secur...@openssl.org. >> >> In order to avoid duplication of effort, perhaps someone should set up >> a github repo (or something else) assigning ranges to volunteers? It >> might also be useful to use the same repo to hold the triage results >> (so things can be ticked off as they are actioned). > > I already created a github branch for this, I'm a little unclear what "this" is? Also, how this fits into Matt's coordinated effort? > but I stopped adding > patches at it since I didn't know if this was going to be useful > or not. > > See: > https://github.com/kroeckx/openssl/commits/master-proposed > > >> 2. Triage Github pull requests >> >> There are less of these, and I do try to look at them from time to >> time, nevertheless I think we are behind. > > I've looked over them several time already, and I've merged a few > of those. But it's hard for me to know what you would find an > acceptable change and what not, so I've tried to be conservative. > >> 3. Write fixes >> 4. Convert fixes to pull requests > > I'll try to work on that. > >> 5. Port pull requests across all branches > > I wasn't really sure what to do here, and was planning to have > branches you can pull for the various branches. > > > > Kurt > > __ > 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: Attribution of pull requests in git
On 26 April 2014 12:16, Kurt Roeckx wrote: > On Sat, Apr 26, 2014 at 11:29:39AM +0100, Ben Laurie wrote: >> Is there an easy way to fix that? That is, I would expect it to show >> me as the committer and the original author as the author. > > That is how it should always work, and I'm not sure why you would > see anything else. git really keeps the author and date of the > patch seperated from the commiter and date of commit. My point is that it doesn't work like that. I agree it should :-) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: test/heartbleed_test.c
On 20 May 2014 06:40, The Doctor,3328-138 Ave Edmonton AB T5Y
1M4,669-2000,473-4587 wrote:
> Found that strndup would not work.
>
> I had to add
>
> #if !HAVE_STRNDUP
>
> #include
> #include
> #include
> #include
>
> /* Find the length of STRING, but scan at most MAXLEN characters.
>If no '\0' terminator is found in that many characters, return MAXLEN. */
> size_t
> strnlen (const char *string, size_t maxlen)
> {
> const char *end = memchr (string, '\0', maxlen);
> return end ? end - string : maxlen;
> }
>
> char *
> strndup (const char *s, size_t n)
> {
> size_t len = strnlen (s, n);
> char *new = malloc (len + 1);
>
> if (new == NULL)
> return NULL;
>
> new[len] = '\0';
> return memcpy (new, s, len);
> }
>
> #endif
>
> Please see how you can add this.
There is already a strndup replacement: BUF_strndup(). Switching to
use that would be better.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: test/heartbleed_test.c
On 20 May 2014 15:17, Ken Goldman wrote: > On 5/20/2014 7:24 AM, Ben Laurie wrote: >> >> >> There is already a strndup replacement: BUF_strndup(). Switching to >> use that would be better. > > > However > > - if that function points to strndup, don't you still have the problem if > strndup doesn't exist? It doesn't. > - if that function is a reimplementation of strndup, don't you lose any > optimizations that the tool chain strndup might have made? Yes, you do. I guess if anyone really cares (its not actually used much), then it would be possible to work around. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Fwd: Using Frankencerts for Automated Adversarial,Testing of Certificate Validation,in SSL/TLS Implementations
-- Forwarded message -- From: Martin Haufschild Date: 23 May 2014 07:34 Subject: Using Frankencerts for Automated Adversarial,Testing of Certificate Validation,in SSL/TLS Implementations Hello, FYI https://www.cs.utexas.edu/~shmat/shmat_oak14.pdf There seem to be two discrepancies with OpenSSL on page 11. Regards Martin -- This is a pretty nice paper, well worth a read, IMO. Anyway, the two discrepancies: not clear to me that accepting basic constraints in V1 certs is a bug. In any case it can only (I think) tighten the constraints on the chain, so doesn't seem harmful. Rejecting a leaf CA below an intermediate with zero path length may be strictly incorrect, but ... what does it mean? Would you ever see such a thing? When? In any case, for the second issue at least, patches welcome. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Prime generation
I was looking at the internal functions in bn_prime.c: probable_prime(), probable_prime_dh() and probably_prime_dh_safe(). Possibly I'm missing something, but... don't all of these functions actually generate (probable) safe primes? This is particularly bemusing for the DH ones. Also, probable_prime() has some cunning optimisations which it seems that the other two could also use. Anyone got any idea why not? Finally, all of them have a bias: they're much more likely to pick a prime with a long run of non-primes before it than one that hasn't (in the case of the DH ones, the condition is slightly more subtle, depending on parameters, but its there nevertheless). Is this wise? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Prime generation
On 26 May 2014 19:52, Viktor Dukhovni wrote: > On Mon, May 26, 2014 at 07:24:54PM +0100, Ben Laurie wrote: > >> Finally, all of them have a bias: they're much more likely to pick a >> prime with a long run of non-primes before it than one that hasn't (in >> the case of the DH ones, the condition is slightly more subtle, >> depending on parameters, but its there nevertheless). Is this wise? > > Where do you see the bias? They all work by picking a random number and then stepping upwards from that number until a probable prime is found. Clearly, that is more likely to find primes with a long run of non-primes before than primes with a short run. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Prime generation
On 27 May 2014 09:16, Joseph Birr-Pixton wrote: > On 27 May 2014 08:45, Peter Waltenberg wrote: >> ... >> I did change the RNG sources for some of the OpenSSL code in our hacked >> version to help with the performance problems using the wrong source causes, >> for example RSA blinding data can safely come from a DRBG >> (pseudo_rand_bytes()). > > I assume you mean RAND_pseudo_bytes. In which case you should know > that RAND_pseudo_bytes has a broken interface and cannot ever be used > safely in a way which makes it different from RAND_bytes. > > To restate: > > Callers of RAND_pseudo_bytes are either unreliable, or equivalent to > RAND_bytes. Do not use it. Have I missed something? What are you referring to here? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: open ssl rsa key generation improvement idea
Nice idea.
It inspired my son, Felix, and I to think about a related idea:
generate random numbers which are inherently coprime to small primes.
Felix went on to implement the idea, and include benchmarks and tests.
Not finished - while implementing, we noticed that the existing prime
number generators have a bias. We decided to remove that, which caused
prime candidate generation to take more than twice as long (it was 42%
of the speed on Felix' laptop) - but the good news is our technique
doubled the speed, getting most of the loss back.
We also don't currently deal with the case where add != 2 or rem != 1.
But its clearly possible without too much work.
You could use his branch as a basis for testing this idea:
https://github.com/openssl/openssl/pull/116.
On 26 May 2014 02:31, Russell Harkins wrote:
> Hi SSL Team,
>
> I was looking for ways to make calculating RSA public/private keys faster.
> I noticed that trial division was being done to test if a number is
> divisible by small primes.
> Roughly 2/3 of all odd numbers are divisible by primes less than 25. I
> found a faster way to test the divisibility than using division.
> In school, I learned some divisibility rules. For instance, when
> determining if a large number is divisible by 3, add the sum of all the
> digits. To see if a large number is divisible by 5, check the last digit
> to see if it’s a zero or 5.
>
> I’ve converted these divisibility rules into binary. For instance, to see
> if a large number is divisible by 3, add the sum of all the bytes of the
> large number and see if that sum is divisible by 3.
> I’ve converted all the divisibility rules for all the primes less than 25
> into binary. All the sums can be calculated at once.
>
> I wrote a function to do this based on the BIGNUM that openssl uses:
> BN_isdivisiblebyprimeslessthan25
> The easiest way to test my function is to generate random numbers and test
> the results of BN_isdivisiblebyprimeslessthan25 with another function that
> does the division the old way.
>
> Attached is a paper detailing the math behind the change.
>
> Here’s the function and where to put it in openssl:
>
> In file crypto\bn\bn_prime.c,
> function BN_is_prime_fasttest_ex
> After if (do_trial_division), add
> if (BN_isdivisiblebyprimeslessthan25(a))
>return 0;
>
> bool bn:: BN_isdivisiblebyprimeslessthan25 (const BIGNUM *p)
> {
> int total3and5and17 = 0; // 256 mod 3 = 1, 256 mod 5 = 1, 256 mod 17 = 1
> int total7 = 0;
> int total11 = 0;
> int total13 = 0;
> int total19 = 0;
> int total23 = 0;
>
> const char sumBytes7[] = { 1, 4, 2}; // 1 mod 7 = 1, 256 mod 7 = 4,
> 65536 mod 7 = 2
> const char sumBytes11[] = { 1, 3, 9, 5, 4}; // 1 mod 11 = 1, 256 mod 11
> = 3, 65536 mod 11 = 9
> const char sumBytes13[] = { 1, 9, 3}; // 1 mod 13 = 1, 256 mod 13 = 9,
> 65536 mod 13 = 3
> const char sumBytes19[] = { 1, 9, 5, 7, 6, 16, 11, 4, 17};
> const char sumBytes23[] = { 1, 3, 9, 4, 12, 13, 16, 2, 6, 18, 8};
>
> int index7or13 = 0; // Array indexes for 7 and 13 are the same because
> the array is the same size.
> int index11 = 0;
> int index19 = 0;
> int index23 = 0;
> int byteLoop;
> int top;
> BN_ULONG item;
> int itemByte;
> BN_ULONG *itemptr;
> BN_ULONG *lastItem;
>
> top = p->top;
> if (top <= 0)
> {
> return true;
> }
>
> itemptr = p->d;
> lastItem = itemptr+top-1;
> while(true)
> {
> item = *itemptr;
> for(byteLoop=0;byteLoop {
> itemByte = (int)(item & 255);
> item >>= 8;
> total3and5and17 += itemByte;
> total7 += (sumBytes7[index7or13] * itemByte);
> total13 += (sumBytes13[index7or13] * itemByte);
> total11 += (sumBytes11[index11] * itemByte);
> total19 += (sumBytes19[index19] * itemByte);
> total23 += (sumBytes23[index23] * itemByte);
> // Keep the array indexes in bounds.
> index7or13 = (index7or13 + 1) % 3;
> index11 = (index11 + 1) % 5;
> index19 = (index19 + 1) % 9;
> index23 = (index23 + 1) % 11;
> }
> // Move to the next item.
> if (itemptr == lastItem)
> {
> break;
> }
> itemptr++;
> }
> bool returnValue = (((total3and5and17 % 3) == 0)
> || ((total3and5and17 % 5) == 0)
> || ((total7 % 7) == 0)
> || ((total11 % 11) == 0)
> || ((total13 % 13) == 0)
> || ((total3and5and17 % 17) == 0)
> || ((total19 % 19) == 0)
> || ((total23 % 23)
Re: open ssl rsa key generation improvement idea
Also, I should note that this approach is not portable. You need to
operate in the same base as BIGNUM does, or account for endianness is
the byte-level operations.
On 26 May 2014 02:31, Russell Harkins wrote:
> Hi SSL Team,
>
> I was looking for ways to make calculating RSA public/private keys faster.
> I noticed that trial division was being done to test if a number is
> divisible by small primes.
> Roughly 2/3 of all odd numbers are divisible by primes less than 25. I
> found a faster way to test the divisibility than using division.
> In school, I learned some divisibility rules. For instance, when
> determining if a large number is divisible by 3, add the sum of all the
> digits. To see if a large number is divisible by 5, check the last digit
> to see if it’s a zero or 5.
>
> I’ve converted these divisibility rules into binary. For instance, to see
> if a large number is divisible by 3, add the sum of all the bytes of the
> large number and see if that sum is divisible by 3.
> I’ve converted all the divisibility rules for all the primes less than 25
> into binary. All the sums can be calculated at once.
>
> I wrote a function to do this based on the BIGNUM that openssl uses:
> BN_isdivisiblebyprimeslessthan25
> The easiest way to test my function is to generate random numbers and test
> the results of BN_isdivisiblebyprimeslessthan25 with another function that
> does the division the old way.
>
> Attached is a paper detailing the math behind the change.
>
> Here’s the function and where to put it in openssl:
>
> In file crypto\bn\bn_prime.c,
> function BN_is_prime_fasttest_ex
> After if (do_trial_division), add
> if (BN_isdivisiblebyprimeslessthan25(a))
>return 0;
>
> bool bn:: BN_isdivisiblebyprimeslessthan25 (const BIGNUM *p)
> {
> int total3and5and17 = 0; // 256 mod 3 = 1, 256 mod 5 = 1, 256 mod 17 = 1
> int total7 = 0;
> int total11 = 0;
> int total13 = 0;
> int total19 = 0;
> int total23 = 0;
>
> const char sumBytes7[] = { 1, 4, 2}; // 1 mod 7 = 1, 256 mod 7 = 4,
> 65536 mod 7 = 2
> const char sumBytes11[] = { 1, 3, 9, 5, 4}; // 1 mod 11 = 1, 256 mod 11
> = 3, 65536 mod 11 = 9
> const char sumBytes13[] = { 1, 9, 3}; // 1 mod 13 = 1, 256 mod 13 = 9,
> 65536 mod 13 = 3
> const char sumBytes19[] = { 1, 9, 5, 7, 6, 16, 11, 4, 17};
> const char sumBytes23[] = { 1, 3, 9, 4, 12, 13, 16, 2, 6, 18, 8};
>
> int index7or13 = 0; // Array indexes for 7 and 13 are the same because
> the array is the same size.
> int index11 = 0;
> int index19 = 0;
> int index23 = 0;
> int byteLoop;
> int top;
> BN_ULONG item;
> int itemByte;
> BN_ULONG *itemptr;
> BN_ULONG *lastItem;
>
> top = p->top;
> if (top <= 0)
> {
> return true;
> }
>
> itemptr = p->d;
> lastItem = itemptr+top-1;
> while(true)
> {
> item = *itemptr;
> for(byteLoop=0;byteLoop {
> itemByte = (int)(item & 255);
> item >>= 8;
> total3and5and17 += itemByte;
> total7 += (sumBytes7[index7or13] * itemByte);
> total13 += (sumBytes13[index7or13] * itemByte);
> total11 += (sumBytes11[index11] * itemByte);
> total19 += (sumBytes19[index19] * itemByte);
> total23 += (sumBytes23[index23] * itemByte);
> // Keep the array indexes in bounds.
> index7or13 = (index7or13 + 1) % 3;
> index11 = (index11 + 1) % 5;
> index19 = (index19 + 1) % 9;
> index23 = (index23 + 1) % 11;
> }
> // Move to the next item.
> if (itemptr == lastItem)
> {
> break;
> }
> itemptr++;
> }
> bool returnValue = (((total3and5and17 % 3) == 0)
> || ((total3and5and17 % 5) == 0)
> || ((total7 % 7) == 0)
> || ((total11 % 11) == 0)
> || ((total13 % 13) == 0)
> || ((total3and5and17 % 17) == 0)
> || ((total19 % 19) == 0)
> || ((total23 % 23) == 0));
>
> return returnValue;
> }
>
> Russell Harkins
> 650-481-5261
>
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: open ssl rsa key generation improvement idea
On 28 May 2014 00:03, Viktor Dukhovni wrote: > On Tue, May 27, 2014 at 09:04:20PM +0100, Ben Laurie wrote: > >> It inspired my son, Felix, and I to think about a related idea: >> generate random numbers which are inherently coprime to small primes. >> Felix went on to implement the idea, and include benchmarks and tests. > > When you say small, you mean really small right? Not the first > 2048 primes as in the OpenSSL code, but say the first few, for > example those less than 25? Yeah - we went up to 11 for the tests. >> Not finished - while implementing, we noticed that the existing prime >> number generators have a bias. We decided to remove that, which caused >> prime candidate generation to take more than twice as long (it was 42% >> of the speed on Felix' laptop) - but the good news is our technique >> doubled the speed, getting most of the loss back. > > Do the resulting candidates also avoid having small odd factors in > (p-1)? This means p != 0 or 1 mod each of the first batch of odd > primes. No, but the method could be extended to do that pretty easily. > For the first 9 primes: > > 2, 3, 5, 7, 11, 13, 17, 19, 23 > > this leaves only > > 7,952,175 = 1 * 1 * 3 * 5 * 9 * 11 * 15 * 17 * 21 > > acceptable odd values modulo: > > 223,092,870 = 2 * 3 * 5 * 7 * 11 * 13 * 17 * 19 * 23 > > or ~7.1% of the odd candidates. > > -- > Viktor. > __ > 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: Prime generation
On 28 May 2014 01:47, mancha wrote: > Fouque and Tibouchi [3] offer the differing view that it's preferable to > minimize bias and generate primes that are almost uniform "even if it is > not immediately clear how such biases can help an adversary". They > suggest a few algorithms that improve on naive discard & repeat by > discarding only the top N bits of a candidate at each iteration, among > other innovations. This paper assumes two things that don't appear to be true: a) That prime generation attempts consume entropy - why? Seems fine to me to just stir the pool and try again. b) That repeated random number generation is much more expensive than, say, addition. Our experiments show that generating a new random number each time is only half the speed of incrementing. I'm guessing these incorrect assumptions are common in the literature? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Re : Re: open ssl rsa key generation improvement idea & Prime generation
On 28 May 2014 13:32, wrote: > Hi, > > it seems that the two discussions are somehow related > > the idea of generating only prime candidates not dividible by small primes is > interesting but, due to incremental search, it will not apply to next > candidates a) The incremental search introduces bias, so not clear we should really maintain that b) It isn't very hard to incorporate incremental search in our scheme I am not suggesting that your idea is not also worthwhile - in particular, you can probably go to higher primes than our scheme - the tables quickly become pretty large... > however, it may be possible to use bit counting to perform a less biased walk > AND efficiently avoid prime dividible by first primes : > > let say we generate randomly the first bytes of a key, except the last byte > > it is then possible to compute quickly all possible values for the last byte > (or first depending on endianness) such that it is not dividible by first > primes (as well as (p-1)/2 using a bit shift) > looking at the last test of code provided, it can even be made quite > efficiently using CRT > > given these values, we can test them in a random order in order to reduce the > bias of incremental search > in case of fail, just change last bit of second-to-last byte, and try again > > it should be statistically correct to do this on the byte of highest weight, > but by applying this on the first byte we are sure that it will spawn a > (strong) prime, just like incremental search > > > This is just an idea as I didn't implement anything yet > however with full optimization this could be quicker than incremental search > > And sorry if I'm mistaking anyhow > > > Nico > > > > - Mail d'origine - > De: Ben Laurie > À: OpenSSL development > Envoyé: Wed, 28 May 2014 11:10:25 +0200 (CEST) > Objet: Re: open ssl rsa key generation improvement idea > > On 28 May 2014 00:03, Viktor Dukhovni wrote: >> On Tue, May 27, 2014 at 09:04:20PM +0100, Ben Laurie wrote: >> >>> It inspired my son, Felix, and I to think about a related idea: >>> generate random numbers which are inherently coprime to small primes. >>> Felix went on to implement the idea, and include benchmarks and tests. >> >> When you say small, you mean really small right? Not the first >> 2048 primes as in the OpenSSL code, but say the first few, for >> example those less than 25? > > Yeah - we went up to 11 for the tests. > >>> Not finished - while implementing, we noticed that the existing prime >>> number generators have a bias. We decided to remove that, which caused >>> prime candidate generation to take more than twice as long (it was 42% >>> of the speed on Felix' laptop) - but the good news is our technique >>> doubled the speed, getting most of the loss back. >> >> Do the resulting candidates also avoid having small odd factors in >> (p-1)? This means p != 0 or 1 mod each of the first batch of odd >> primes. > > No, but the method could be extended to do that pretty easily. > >> For the first 9 primes: >> >> 2, 3, 5, 7, 11, 13, 17, 19, 23 >> >> this leaves only >> >> 7,952,175 = 1 * 1 * 3 * 5 * 9 * 11 * 15 * 17 * 21 >> >> acceptable odd values modulo: >> >> 223,092,870 = 2 * 3 * 5 * 7 * 11 * 13 * 17 * 19 * 23 >> >> or ~7.1% of the odd candidates. >> >> -- >> Viktor. >> __ >> 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 > > __ > 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: New unbiased prime generator function fixes
You didn't update the test...
On 1 June 2014 21:26, Viktor Dukhovni wrote:
> On Sun, Jun 01, 2014 at 08:14:00PM +, Viktor Dukhovni wrote:
>>
>> The new prime generator does not ensure that generated primes are
>> "safe" modulo 2, 3, 5, 7 or 11. In particular (p-1)/2 might not
>> be co-prime to 2310.
>>
>> The patch below my signature addresses this problem.
>
> Oops, previous patch neglected the fact that the multiplier needs to be
> a multiple of 4 to ensure that all the residues are 3 mod 4.
>
> Updated fix below (just double the multiplier).
>
> --
> Viktor.
>
> diff --git a/crypto/bn/bn_prime.c b/crypto/bn/bn_prime.c
> index 2d66b61..e74a98f 100644
> --- a/crypto/bn/bn_prime.c
> +++ b/crypto/bn/bn_prime.c
> @@ -132,48 +132,32 @@ static int probable_prime(BIGNUM *rnd, int bits);
> static int probable_prime_dh_safe(BIGNUM *rnd, int bits,
> const BIGNUM *add, const BIGNUM *rem, BN_CTX *ctx);
>
> -static const int prime_offsets[480] = {
> - 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67, 71, 73, 79,
> 83,
> - 89, 97, 101, 103, 107, 109, 113, 127, 131, 137, 139, 149, 151, 157,
> 163,
> - 167, 169, 173, 179, 181, 191, 193, 197, 199, 211, 221, 223, 227, 229,
> - 233, 239, 241, 247, 251, 257, 263, 269, 271, 277, 281, 283, 289, 293,
> - 299, 307, 311, 313, 317, 323, 331, 337, 347, 349, 353, 359, 361, 367,
> - 373, 377, 379, 383, 389, 391, 397, 401, 403, 409, 419, 421, 431, 433,
> - 437, 439, 443, 449, 457, 461, 463, 467, 479, 481, 487, 491, 493, 499,
> - 503, 509, 521, 523, 527, 529, 533, 541, 547, 551, 557, 559, 563, 569,
> - 571, 577, 587, 589, 593, 599, 601, 607, 611, 613, 617, 619, 629, 631,
> - 641, 643, 647, 653, 659, 661, 667, 673, 677, 683, 689, 691, 697, 701,
> - 703, 709, 713, 719, 727, 731, 733, 739, 743, 751, 757, 761, 767, 769,
> - 773, 779, 787, 793, 797, 799, 809, 811, 817, 821, 823, 827, 829, 839,
> - 841, 851, 853, 857, 859, 863, 871, 877, 881, 883, 887, 893, 899, 901,
> - 907, 911, 919, 923, 929, 937, 941, 943, 947, 949, 953, 961, 967, 971,
> - 977, 983, 989, 991, 997, 1003, 1007, 1009, 1013, 1019, 1021, 1027,
> 1031,
> - 1033, 1037, 1039, 1049, 1051, 1061, 1063, 1069, 1073, 1079, 1081,
> 1087,
> - 1091, 1093, 1097, 1103, 1109, 1117, 1121, 1123, 1129, 1139, 1147,
> 1151,
> - 1153, 1157, 1159, 1163, 1171, 1181, 1187, 1189, 1193, 1201, 1207,
> 1213,
> - 1217, 1219, 1223, 1229, 1231, 1237, 1241, 1247, 1249, 1259, 1261,
> 1271,
> - 1273, 1277, 1279, 1283, 1289, 1291, 1297, 1301, 1303, 1307, 1313,
> 1319,
> - 1321, 1327, 1333, 1339, 1343, 1349, 1357, 1361, 1363, 1367, 1369,
> 1373,
> - 1381, 1387, 1391, 1399, 1403, 1409, 1411, 1417, 1423, 1427, 1429,
> 1433,
> - 1439, 1447, 1451, 1453, 1457, 1459, 1469, 1471, 1481, 1483, 1487,
> 1489,
> - 1493, 1499, 1501, 1511, 1513, 1517, 1523, 1531, 1537, 1541, 1543,
> 1549,
> - 1553, 1559, 1567, 1571, 1577, 1579, 1583, 1591, 1597, 1601, 1607,
> 1609,
> - 1613, 1619, 1621, 1627, 1633, 1637, 1643, 1649, 1651, 1657, 1663,
> 1667,
> - 1669, 1679, 1681, 1691, 1693, 1697, 1699, 1703, 1709, 1711, 1717,
> 1721,
> - 1723, 1733, 1739, 1741, 1747, 1751, 1753, 1759, 1763, 1769, 1777,
> 1781,
> - 1783, 1787, 1789, 1801, 1807, 1811, 1817, 1819, 1823, 1829, 1831,
> 1843,
> - 1847, 1849, 1853, 1861, 1867, 1871, 1873, 1877, 1879, 1889, 1891,
> 1901,
> - 1907, 1909, 1913, 1919, 1921, 1927, 1931, 1933, 1937, 1943, 1949,
> 1951,
> - 1957, 1961, 1963, 1973, 1979, 1987, 1993, 1997, 1999, 2003, 2011,
> 2017,
> - 2021, 2027, 2029, 2033, 2039, 2041, 2047, 2053, 2059, 2063, 2069,
> 2071,
> - 2077, 2081, 2083, 2087, 2089, 2099, 2111, 2113, 2117, 2119, 2129,
> 2131,
> - 2137, 2141, 2143, 2147, 2153, 2159, 2161, 2171, 2173, 2179, 2183,
> 2197,
> - 2201, 2203, 2207, 2209, 2213, 2221, 2227, 2231, 2237, 2239, 2243,
> 2249,
> - 2251, 2257, 2263, 2267, 2269, 2273, 2279, 2281, 2287, 2291, 2293,
> 2297,
> - 2309, 2311 };
> -static const int prime_offset_count = 480;
> -static const int prime_multiplier = 2310;
> -static const int prime_multiplier_bits = 11; /* 2^|prime_multiplier_bits|
> +/*
> + * Residues $r$ modulo $4620 = 4 \cdot 3 \cdot 5 \cdot 7 \cdot 11$ for which
> + * both $r$ and $r-1$ are co-prime to $2310$.
> + */
> +static const int prime_offsets[134] = {
> + 47,59,83, 107, 167, 179, 227, 263,
> +299, 347, 359, 383, 443, 467, 479, 503,
> +527, 563, 587, 599, 647, 719, 767, 779,
> +839, 863, 887, 899, 923, 983, 1007, 1019,
> + 1103, 1139, 1187, 1223, 1259, 1283, 1307, 1319,
> + 1367, 1403, 1427, 1439, 1487, 1523, 1559, 1619,
> + 1643, 1679, 1703, 1763, 1787, 1823, 1847, 1907,
> + 1943, 1979, 2027, 2039, 2063, 2099, 2147, 2159,
> + 2183, 2207, 2243, 2279, 232
Re: [PATCH] 1.0.1h does not build nor test HEARBEAT bug on OpenVMS
On 6 June 2014 22:21, Zoltan Arpadffy wrote: > Hi, > > after some testing the new release I realized that 1.0.1h does not build nor > run HEARBEAT bug unit test on OpenVMS. > The following patch corrects the problem. Best as a pull request on github. > > Thanks, > Z > > > - > > SYSTEM@ia64$ mc DKA0:[UTIL]gdiff.exe -p > DKA0:[WORK.openssl-101h.test]maketests.com;1 > DKA0:[WORK.openssl-101h.test]maketests.com;2 > *** dka0:[work.openssl-101h.test]maketests.com;1Thu Jun 5 10:44:33 > 2014 > --- dka0:[work.openssl-101h.test]maketests.com;2Fri Jun 6 21:23:03 > 2014 > *** $! A-Com Computing, Inc. > *** 6,11 > --- 6,12 > $! b...@mail.all-net.net > $! > $! Changes by Richard Levitte > + $! Zoltan Arpadffy > $! > $! This command files compiles and creates all the various different > $! "test" programs for the different types of encryption for OpenSSL. > *** $ TEST_FILES = "BNTEST,ECTEST,ECDSATEST, > *** 147,153 >"RANDTEST,DHTEST,ENGINETEST,"+ - >"BFTEST,CASTTEST,SSLTEST,EXPTEST,DSATEST,RSA_TEST,"+ - >"EVP_TEST,IGETEST,JPAKETEST,SRPTEST,"+ - > ! "ASN1TEST" > $! Should we add MTTEST,PQ_TEST,LH_TEST,DIVTEST,TABTEST as well? > $! > $! Additional directory information. > --- 148,154 >"RANDTEST,DHTEST,ENGINETEST,"+ - >"BFTEST,CASTTEST,SSLTEST,EXPTEST,DSATEST,RSA_TEST,"+ - >"EVP_TEST,IGETEST,JPAKETEST,SRPTEST,"+ - > ! "ASN1TEST,HEARTBEAT_TEST" > $! Should we add MTTEST,PQ_TEST,LH_TEST,DIVTEST,TABTEST as well? > $! > $! Additional directory information. > *** $ T_D_IGETEST:= [-.test] > *** 185,190 > --- 186,192 > $ T_D_JPAKETEST := [-.crypto.jpake] > $ T_D_SRPTEST:= [-.crypto.srp] > $ T_D_ASN1TEST := [-.test] > + $ T_D_HEARTBEAT_TEST := [-.test] > $! > $ TCPIP_PROGRAMS = ",," > $ IF COMPILER .EQS. "VAXC" THEN - > SYSTEM@ia64$ mc DKA0:[UTIL]gdiff.exe -p > DKA0:[WORK.openssl-101h.test]tests.com;1 > DKA0:[WORK.openssl-101h.test]tests.com;4 > *** dka0:[work.openssl-101h.test]tests.com;1Thu Jun 5 10:44:33 2014 > --- dka0:[work.openssl-101h.test]tests.com;4Fri Jun 6 22:07:23 2014 > *** $ tests := - > *** 56,62 > test_enc,test_x509,test_rsa,test_crl,test_sid,- > test_gen,test_req,test_pkcs7,test_verify,test_dh,test_dsa,- > test_ss,test_ca,test_engine,test_evp,test_ssl,test_tsa,test_ige,- > ! test_jpake,test_srp,test_cms > $ endif > $ tests = f$edit(tests,"COLLAPSE") > $ > --- 56,62 > test_enc,test_x509,test_rsa,test_crl,test_sid,- > test_gen,test_req,test_pkcs7,test_verify,test_dh,test_dsa,- > test_ss,test_ca,test_engine,test_evp,test_ssl,test_tsa,test_ige,- > ! test_jpake,test_srp,test_heartbeat,test_cms > $ endif > $ tests = f$edit(tests,"COLLAPSE") > $ > *** $ IGETEST := igetest > *** 95,100 > --- 95,101 > $ JPAKETEST :=jpaketest > $ SRPTEST := srptest > $ ASN1TEST := asn1test > + $ HEARTBEATTEST := heartbeat_test > $! > $ tests_i = 0 > $ loop_tests: > *** $ test_srp: > *** 366,371 > --- 367,376 > $ write sys$output "Test SRP" > $ mcr 'texe_dir''srptest' > $ return > + $ test_heartbeat: > + $ write sys$output "Test HEARTBEAT" > + $ mcr 'texe_dir''heartbeattest' > + $ return > $ > $ > $ exit: > > __ > 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: Crash in openSSL 1.0.1g
You should be using 1.0.1h. Also, not familiar with MacOS X heap checking, but it looks like heap corruption, which may or may not be OpenSSL's fault. Probably hard to diagnose without a test case! On 10 June 2014 07:25, Navneet Kumar (navneeku) wrote: > Update : Crashes are seen only on MAC OS X and not seen on windows. > > Thanks & Regards, > -NK > > > From: Cisco Employee > Reply-To: "openssl-dev@openssl.org" > Date: Tuesday, 10 June 2014 11:20 AM > To: "openssl-dev@openssl.org" > Subject: Crash in openSSL 1.0.1g > > Hello Team, > We have recently done the upgrade to openSSL version 1.0.1g and facing many > crashes in below code path. Crashes are seen consistently. > Any pointer on what went wrong will be really helpful. Thanks for your time > !! > > ==Crash stack trace= > > (lldb) bt > > * thread #30: tid = 0x6fdcc, 0x97f34a6a > libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGABRT > > frame #0: 0x97f34a6a libsystem_kernel.dylib`__pthread_kill + 10 > > frame #1: 0x911a2b2f libsystem_c.dylib`pthread_kill + 101 > > frame #2: 0x911d95f3 libsystem_c.dylib`__abort + 199 > > frame #3: 0x911d952c libsystem_c.dylib`abort + 232 > > frame #4: 0x911c3227 libsystem_c.dylib`szone_error + 443 > > frame #5: 0x911c4482 libsystem_c.dylib`free_list_checksum_botch + 50 > > frame #6: 0x911c7a43 libsystem_c.dylib`tiny_malloc_from_free_list + 458 > > frame #7: 0x911c811a libsystem_c.dylib`szone_malloc_should_clear + 880 > > frame #8: 0x911bda9e libsystem_c.dylib`szone_malloc + 24 > > frame #9: 0x911bb5ab libsystem_c.dylib`malloc_zone_malloc + 75 > > frame #10: 0x911bbfe7 libsystem_c.dylib`malloc + 53 > > frame #11: 0x0026100d libxxcrypto.dylib`default_malloc_ex + 45 > > frame #12: 0x0026190f libxxcrypto.dylib`CRYPTO_malloc + 175 > > frame #13: 0x002766e0 libxxcrypto.dylib`pkey_hmac_init + 48 > > frame #14: 0x002f4159 libxxcrypto.dylib`int_ctx_new + 601 > > frame #15: 0x002f460c libxxcrypto.dylib`EVP_PKEY_CTX_new_id + 44 > > frame #16: 0x002f66cf libxxcrypto.dylib`EVP_PKEY_new_mac_key + 63 > > frame #17: 0x004a3b07 libxxssl.dylib`tls1_P_hash + 423 > > frame #18: 0x004a42d2 libxxssl.dylib`tls1_PRF + 770 > > frame #19: 0x004a6119 libxxssl.dylib`tls1_final_finish_mac + 633 > > frame #20: 0x00496fea libxxssl.dylib`ssl3_do_change_cipher_spec + 394 > > frame #21: 0x00496b23 libxxssl.dylib`ssl3_read_bytes + 3347 > > frame #22: 0x0049829e libxxssl.dylib`ssl3_get_message + 334 > > frame #23: 0x0049795a libxxssl.dylib`ssl3_get_finished + 90 > > frame #24: 0x0048700f libxxssl.dylib`ssl3_connect + 3103 > > frame #25: 0x004b8463 libxxssl.dylib`SSL_connect + 51 > > frame #26: 0x00031bcf > x`boost::asio::ssl::detail::engine::do_connect(this=0xb12c8a54, > =0x, =0) + 19 at engine.ipp:272 > > frame #27: 0x000bee79 > x`boost::asio::ssl::detail::engine::perform(this=, > data=, length=, ec=, > bytes_transferred=, op=)(void*, unsigned long), > void*, unsigned long, boost::system::error_code&, unsigned long*) + 73 at > engine.ipp:215 > > =End == > > Thanks & Regards, > -NK > __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3375] Patch: Off-by-one errors in ssl_cipher_get_evp()
On 12 June 2014 23:15, Matt Caswell wrote: > > > On 12/06/14 22:43, Otto Moerbeek wrote: >> On Thu, Jun 12, 2014 at 10:26:56PM +0200, Matt Caswell via RT wrote: >> >>> Patch applied: >>> https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=abfb989fe0b749ad61f1aa4cdb0ea4f952fc13e0 >>> >>> Many thanks for your contribution. >>> >>> Matt >> >> http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/ssl/ssl_ciph.c.diff?r1=1.38;r2=1.39 >> >> Again no attribution in problem report and commit. Claiming >> independent discovery is not going to be credible. > > The commit *is* attributed. The author is listed as Kurt Cancemi - this > is as it is attributed in the patch supplied in the problem report. I presume he meant in the OpenBSD repo... Kurt does not appear to be attributed there: http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/ssl/ssl_ciph.c?rev=1.39. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3375] Patch: Off-by-one errors in ssl_cipher_get_evp()
On 21 June 2014 19:51, Otto Moerbeek wrote: > On Sat, Jun 21, 2014 at 06:15:28PM +0100, Ben Laurie wrote: > >> On 12 June 2014 23:15, Matt Caswell wrote: >> > >> > >> > On 12/06/14 22:43, Otto Moerbeek wrote: >> >> On Thu, Jun 12, 2014 at 10:26:56PM +0200, Matt Caswell via RT wrote: >> >> >> >>> Patch applied: >> >>> https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=abfb989fe0b749ad61f1aa4cdb0ea4f952fc13e0 >> >>> >> >>> Many thanks for your contribution. >> >>> >> >>> Matt >> >> >> >> http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/ssl/ssl_ciph.c.diff?r1=1.38;r2=1.39 >> >> >> >> Again no attribution in problem report and commit. Claiming >> >> independent discovery is not going to be credible. >> > >> > The commit *is* attributed. The author is listed as Kurt Cancemi - this >> > is as it is attributed in the patch supplied in the problem report. >> >> I presume he meant in the OpenBSD repo... >> >> Kurt does not appear to be attributed there: >> http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/ssl/ssl_ciph.c?rev=1.39. >> __ >> OpenSSL Project http://www.openssl.org >> Development Mailing List openssl-dev@openssl.org >> Automated List Manager majord...@openssl.org > > You care confusing the matter. Kurt already expained he got the fix > from OpenBSD. After that explanation, the OpenSSL repo was fixed to > contain the attribution. Indeed, I misunderstood. > > -Otto > > __ > 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
Makedepend bug?
I've been trying to figure out why my "make depend" differs from other developers, and why it appears to be wrong. For example, apps/dsa.o depends, according to makedepend, on dh.o, but with the standard developer flags ($gcc_devteam_warn) it should not. AFAICS, makedepend gets passed the right flags, and normally processes #ifndef lines correctly. Anyone got any clues what's going on? (I'm on FreeBSD 9.1) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Very old release, unsupported platform
On 1 July 2014 06:52, Zoltan Arpadffy wrote: > Hi, > > I see that Rich is doing a fantastic job by cleaning up the backlog... > I absolutely agree that very old releases cannot be supported, but what about > the platforms? > > I thought until now, that as long there are developers who are willing to > develop for a certain platform and there is some community interest in using > that - the platform will be supported as odd might it be in the Windows and > Linux dominated World. > > I just started to wonder, will soon come the time when my patches will be > also refused with the "unsupported platform" comment? Our soon-to-be-released roadmap has this to say on "supported platform": * Currency, i.e. a platform is widely deployed and in current use * Vendor support * Available to the dev team, i.e. the dev team have access to a suitable environment in which to test builds and deal with tickets and issues * Dev team ownership, i.e. at least one person on the team is willing to take some responsibility for a platform __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Reward for proactive security improvements
In case people haven't noticed, Google has announced a reward program for this (last year, in fact): https://www.google.com/about/appsecurity/patch-rewards/ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Makedepend bug?
On 1 July 2014 17:21, Mike Bland wrote: > Ah! Sorry for the spam, but I think I got it. According to the > makedepend man page: > > http://www.x.org/archive/current/doc/man/man1/makedepend.1.xhtml > > Makedepend makes assumptions about the #includes for files appearing > later on the command line: > > "But when the program parses file2.c and discovers that it, too, > includes header.h, it does not parse the file, but simply adds > header.h, def1.h anddef2.h to the list of dependencies for file2.o." > > Long story short, I narrowed it down to apps/req.c and apps/gendh.c > both #ifdef/undeffing OPENSSL_NO_DEPRECATED. Execute the command with > those two files removed, and dh.h disappears from dsa.o's deps. > > dsaparam.c, genrsa.c, and s_server.c also have this #undef, but coming > later on the command line than dsa.c, they don't trigger makedepend to > generate the dh.h include for dsa.o. Put them before dsa.c, and they > do. Aha! Well done. I suspect there's not really any reason to support makedepend anymore - should perhaps just switch to always using gcc/clang for dependencies? > > Mike > > > On Tue, Jul 1, 2014 at 11:59 AM, Mike Bland wrote: >> Whoops, of course, I meant it generates the same output for dsa.o, and >> only dsa.o. >> >> Mike >> >> On Tue, Jul 1, 2014 at 11:58 AM, Mike Bland wrote: >>> Investigating... It seems to be an issue with the makedepend tool itself. >>> >>> I hacked util/domd to show the makedepend command line, and got this >>> command for apps/: >>> >>> makedepend -D OPENSSL_DOING_MAKEDEPEND -- -O -I.. -I../include >>> -DOPENSSL_NO_DEPRECATED -DOPENSSL_NO_EC_NISTP_64_GCC_128 >>> -DOPENSSL_NO_GMP -DOPENSSL_NO_JPAKE -DOPENSSL_NO_MD2 -DOPENSSL_NO_RC5 >>> -DOPENSSL_NO_RFC3779 -DOPENSSL_NO_SCTP -DOPENSSL_NO_SSL_TRACE >>> -DOPENSSL_NO_STORE -- openssl.c verify.c asn1pars.c req.c dgst.c dh.c >>> enc.c passwd.c gendh.c errstr.c ca.c pkcs7.c crl2p7.c crl.c rsa.c >>> rsautl.c dsa.c dsaparam.c ec.c ecparam.c x509.c genrsa.c gendsa.c >>> genpkey.c s_server.c s_client.c speed.c s_time.c apps.c s_cb.c >>> s_socket.c app_rand.c version.c sess_id.c ciphers.c nseq.c pkcs12.c >>> pkcs8.c pkey.c pkeyparam.c pkeyutl.c spkac.c smime.c cms.c rand.c >>> engine.c ocsp.c prime.c ts.c srp.c >>> >>> Running that through util/clean-depend.pl produces the existing >>> makedepend output. But just running this: >>> >>> makedepend -D OPENSSL_DOING_MAKEDEPEND -- -O -I.. -I../include >>> -DOPENSSL_NO_DEPRECATED -DOPENSSL_NO_EC_NISTP_64_GCC_128 >>> -DOPENSSL_NO_GMP -DOPENSSL_NO_JPAKE -DOPENSSL_NO_MD2 -DOPENSSL_NO_RC5 >>> -DOPENSSL_NO_RFC3779 -DOPENSSL_NO_SCTP -DOPENSSL_NO_SSL_TRACE >>> -DOPENSSL_NO_STORE -- dsa.c >>> >>> Produces the same output except *without* ../include/openssl/dh.h. (I >>> presume you meant dh.h, not dh.o earlier.) >>> >>> Of course, with your GitConfigure/GitMake scripts, you're using the >>> compiler to regenerate dsa.d in isolation from other files. >>> >>> I'll see if I can dig up a little more info here...but it does seem >>> that your normal flags are doing the right thing. >>> >>> Mike >>> >>> >>> >>> On Tue, Jul 1, 2014 at 5:38 AM, Ben Laurie wrote: >>>> I've been trying to figure out why my "make depend" differs from other >>>> developers, and why it appears to be wrong. >>>> >>>> For example, apps/dsa.o depends, according to makedepend, on dh.o, but >>>> with the standard developer flags ($gcc_devteam_warn) it should not. >>>> >>>> AFAICS, makedepend gets passed the right flags, and normally processes >>>> #ifndef lines correctly. >>>> >>>> Anyone got any clues what's going on? (I'm on FreeBSD 9.1) >>>> __ >>>> 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 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Makedepend bug?
On 1 July 2014 18:34, Tim Rice wrote: > On Tue, 1 Jul 2014, Ben Laurie wrote: > >> Aha! Well done. >> >> I suspect there's not really any reason to support makedepend anymore >> - should perhaps just switch to always using gcc/clang for >> dependencies? > > So now gcc/clang is required to build OpenSSL? As noted, makedepend doesn't actually do dependencies right - so, a tool that does dependencies correctly is required... > > -- > Tim RiceMultitalents > t...@multitalents.net > > > __ > 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: Makedepend bug?
On 1 July 2014 19:15, Salz, Rich wrote: >> I was wondering why 'make depend' output was saved in the Makefiles. > > Because way back when (think like early X and xmkmf) that's the way things > were done. > >> So I guess adding the .d files to the repository and using include statements >> in the Makefiles is a reasonable possibility? (That's the angle I'm taking >> with >> my experiment, though I hadn't thought to add the .d's to the repo.) > > Oh gaak, I hope we don't add the .d files and I hope also that there is only > one per directory. But all that's open. Really? Its much more efficient to update the .d files when you compile the (changed) source - which more-or-less implies one per source file. > > /r$ > > -- > Principal Security Engineer > Akamai Technologies, Cambridge, MA > IM: rs...@jabber.me; Twitter: RichSalz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3277] OpenSSL s_client doc missing option
On 2 July 2014 23:17, Rich Salz via RT wrote: > Fixed, added -servername to the pod file. Looks to me like you've only fixed this (and many others) in master - surely should also go to 1.0.2 at least (and probably older branches, too)? Also, we generally rebase rather than merge... __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3277] OpenSSL s_client doc missing option
On 3 July 2014 12:04, Salz, Rich wrote: >> Looks to me like you've only fixed this (and many others) in master - surely >> should also go to 1.0.2 at least (and probably older branches, too)? > > Okay, tell me which branches. Since this is a bug, all active branches (that it applies to - not sure if this option exists in all branches). >> Also, we generally rebase rather than merge... > > I don't know the difference. But okay, if that's the practice, I'll figure > it out. Everything I've seen said the git model is branch/merge, so I just > used the obvious command. :) Rebasing replays your work on top of the current head of branch. There's been a lot of debate, but it seems the team prefer rebasing to merging because merging makes diffing/binary chopping harder. We should write this up somewhere, because rebase + merge also makes sense when you're importing someone else's patches (otherwise you tend to lose who did the import). __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3277] OpenSSL s_client doc missing option
On 3 July 2014 12:21, Salz, Rich wrote: > Thanks for the explanation. > > Which are the currently active branches? OpenSSL_0_9_8-stable OpenSSL_1_0_0-stable OpenSSL_1_0_1-stable OpenSSL_1_0_2-stable master > > -- > Principal Security Engineer > Akamai Technologies, Cambridge, MA > IM: rs...@jabber.me; Twitter: RichSalz > > >> -Original Message- >> From: owner-openssl-...@openssl.org [mailto:owner-openssl- >> d...@openssl.org] On Behalf Of Ben Laurie >> Sent: Thursday, July 03, 2014 7:15 AM >> To: OpenSSL development >> Cc: Jeffrey Walton >> Subject: Re: [openssl.org #3277] OpenSSL s_client doc missing option >> >> On 3 July 2014 12:04, Salz, Rich wrote: >> >> Looks to me like you've only fixed this (and many others) in master - >> >> surely should also go to 1.0.2 at least (and probably older branches, >> >> too)? >> > >> > Okay, tell me which branches. >> >> Since this is a bug, all active branches (that it applies to - not sure if >> this option >> exists in all branches). >> >> >> Also, we generally rebase rather than merge... >> > >> > I don't know the difference. But okay, if that's the practice, I'll >> > figure it out. Everything I've seen said the git model is >> > branch/merge, so I just used the obvious command. :) >> >> Rebasing replays your work on top of the current head of branch. >> There's been a lot of debate, but it seems the team prefer rebasing to >> merging because merging makes diffing/binary chopping harder. >> >> We should write this up somewhere, because rebase + merge also makes >> sense when you're importing someone else's patches (otherwise you tend >> to lose who did the import). >> __ >> >> 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: OpenSSL roadmap
On 3 July 2014 14:13, Theodore Ts'o wrote: > However, in the kernel we are much more lax about who gets access to > the Coverity project. Part of this is the sure and certain knowledge > that the bad guys are quite willing to pay for a Coverity license, and > so for us the balance of increasing the pool of those can who are > looking through the Coverity scans, and contribute to fix bugs, and > thus grow the development community, tips in favor of being more open > about who gets access to Coverity. Right, I agree, but clearly there isn't unanimity amongst the dev team. I think we'd be a bit more relaxed if we were actually on top of Coverity, which I would hope would happen soon, now we have full-time developer(s). __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL roadmap
On 3 July 2014 15:28, Salz, Rich wrote: >> release processes at various distributions. (Given that Microsoft has weekly >> "patch Tuesdays", if even slow moving *Microsoft* can turn around a >> security update in a week, what's your excuse? :-) > > They have a regular release train, but it doesn't mean that everything gets > fixed in one week. Sorry to stomp your punchline. 3 months to a year is more usual. :-) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Google Patch rewards updated to include refactoring
https://www.google.com/about/appsecurity/patch-rewards/ "Refactorings that make it easier to reason about the security properties of the code." __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3428] bug report : crypto/des/ofb64enc.c: Uninitialized variable: d
On 3 July 2014 20:06, Kurt Roeckx via RT wrote:
> On Thu, Jul 03, 2014 at 07:51:28PM +0200, Toralf Förster via RT wrote:
>> I think cppcheck is right here in void DES_ofb64_encrypt(), line 84, 85
>> and 96, or ?:
>>
> The line before that:
>
> dp=d;
>> l2c(v0,dp);<--- Uninitialized variable: d
>> l2c(v1,dp);<--- Uninitialized variable: d
>> while (l--)
>> {
>> if (n == 0)
>> {
>> DES_encrypt1(ti,schedule,DES_ENCRYPT);
>> dp=d;
>> t=ti[0]; l2c(t,dp);
>> t=ti[1]; l2c(t,dp);
>> save++;
>> }
>> *(out++)= *(in++)^d[n];<--- Uninitialized variable: d
>> n=(n+1)&0x07;
>> }
>
> d is uninitialized, but it's being written to, not read from,
> so I don't see a problem with this.
What?
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #3415] Bug report: Uninitialized memory reads reported by valgrind for ECDSA signatures
On 3 July 2014 23:04, Salz, Rich wrote: > Why not just have bn_expand_internal call memset? Exactly, this makes more sense. > > ; git diff bn_lib.c > diff --git a/crypto/bn/bn_lib.c b/crypto/bn/bn_lib.c > index b1e224b..86d1d37 100644 > --- a/crypto/bn/bn_lib.c > +++ b/crypto/bn/bn_lib.c > @@ -324,6 +324,9 @@ static BN_ULONG *bn_expand_internal(const BIGNUM *b, int > words) > BNerr(BN_F_BN_EXPAND_INTERNAL,ERR_R_MALLOC_FAILURE); > return(NULL); > } > +#ifdef PURIFY > + memset(a, 0, sizeof(BN_ULONG)*words); > +#endif > #if 1 > B=b->d; > /* Check if the previous number needs to be copied */ > ; > > -- > Principal Security Engineer > Akamai Technologies, Cambridge, MA > IM: rs...@jabber.me; Twitter: RichSalz > __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3428] bug report : crypto/des/ofb64enc.c: Uninitialized variable: d
On 3 July 2014 22:35, Kurt Roeckx wrote:
> On Thu, Jul 03, 2014 at 09:28:47PM +0100, Ben Laurie wrote:
>> On 3 July 2014 20:06, Kurt Roeckx via RT wrote:
>> > On Thu, Jul 03, 2014 at 07:51:28PM +0200, Toralf Förster via RT wrote:
>> >> I think cppcheck is right here in void DES_ofb64_encrypt(), line 84, 85
>> >> and 96, or ?:
>> >>
>> > The line before that:
>> >
>> > dp=d;
>> >> l2c(v0,dp);<--- Uninitialized variable: d
>> >> l2c(v1,dp);<--- Uninitialized variable: d
>> >> while (l--)
>> >> {
>> >> if (n == 0)
>> >> {
>> >> DES_encrypt1(ti,schedule,DES_ENCRYPT);
>> >> dp=d;
>> >> t=ti[0]; l2c(t,dp);
>> >> t=ti[1]; l2c(t,dp);
>> >> save++;
>> >> }
>> >> *(out++)= *(in++)^d[n];<--- Uninitialized variable: d
>> >> n=(n+1)&0x07;
>> >> }
>> >
>> > d is uninitialized, but it's being written to, not read from,
>> > so I don't see a problem with this.
>>
>> What?
>
> So l2c is:
> #define l2c(l,c)(*((c)++)=(unsigned char)(((l))&0xff), \
> *((c)++)=(unsigned char)(((l)>> 8L)&0xff), \
> *((c)++)=(unsigned char)(((l)>>16L)&0xff), \
> *((c)++)=(unsigned char)(((l)>>24L)&0xff))
>
> It reads v0 and v1 and writes to d (dp). d being uninitialized
> shouldn't be an issue. Or am I missing something?
It writes to *d, surely? Which means d uninitialised is very much an issue, no?
However, now I've read the code (it'd help if people posted enough
snippet to make that unnecessary!) I see d is DES_cblock, i.e. an
array, so the diagnosis is basically incorrect. And therefore I agree
with you, not a problem.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #3428] bug report : crypto/des/ofb64enc.c: Uninitialized variable: d
It'd be nice, btw, if someone would report the bug to cppcheck.
On 4 July 2014 10:15, Ben Laurie wrote:
> On 3 July 2014 22:35, Kurt Roeckx wrote:
>> On Thu, Jul 03, 2014 at 09:28:47PM +0100, Ben Laurie wrote:
>>> On 3 July 2014 20:06, Kurt Roeckx via RT wrote:
>>> > On Thu, Jul 03, 2014 at 07:51:28PM +0200, Toralf Förster via RT wrote:
>>> >> I think cppcheck is right here in void DES_ofb64_encrypt(), line 84, 85
>>> >> and 96, or ?:
>>> >>
>>> > The line before that:
>>> >
>>> > dp=d;
>>> >> l2c(v0,dp);<--- Uninitialized variable: d
>>> >> l2c(v1,dp);<--- Uninitialized variable: d
>>> >> while (l--)
>>> >> {
>>> >> if (n == 0)
>>> >> {
>>> >> DES_encrypt1(ti,schedule,DES_ENCRYPT);
>>> >> dp=d;
>>> >> t=ti[0]; l2c(t,dp);
>>> >> t=ti[1]; l2c(t,dp);
>>> >> save++;
>>> >> }
>>> >> *(out++)= *(in++)^d[n];<--- Uninitialized variable: d
>>> >> n=(n+1)&0x07;
>>> >> }
>>> >
>>> > d is uninitialized, but it's being written to, not read from,
>>> > so I don't see a problem with this.
>>>
>>> What?
>>
>> So l2c is:
>> #define l2c(l,c)(*((c)++)=(unsigned char)(((l))&0xff), \
>> *((c)++)=(unsigned char)(((l)>> 8L)&0xff), \
>> *((c)++)=(unsigned char)(((l)>>16L)&0xff), \
>> *((c)++)=(unsigned char)(((l)>>24L)&0xff))
>>
>> It reads v0 and v1 and writes to d (dp). d being uninitialized
>> shouldn't be an issue. Or am I missing something?
>
> It writes to *d, surely? Which means d uninitialised is very much an issue,
> no?
>
> However, now I've read the code (it'd help if people posted enough
> snippet to make that unnecessary!) I see d is DES_cblock, i.e. an
> array, so the diagnosis is basically incorrect. And therefore I agree
> with you, not a problem.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Preventing the next Heartbleed
Interesting paper by David Wheeler: http://www.dwheeler.com/essays/heartbleed.html. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3428] bug report : crypto/des/ofb64enc.c: Uninitialized variable: d
On 4 July 2014 15:20, Toralf Förster wrote:
> On 07/04/2014 11:17 AM, Ben Laurie wrote:
>> It'd be nice, btw, if someone would report the bug to cppcheck.
> http://5.150.254.56:443/trac-cppcheck/ticket/5970#ticket
Thanks.
>
> Thx
>>
>> On 4 July 2014 10:15, Ben Laurie wrote:
>>> On 3 July 2014 22:35, Kurt Roeckx wrote:
>>>> On Thu, Jul 03, 2014 at 09:28:47PM +0100, Ben Laurie wrote:
>>>>> On 3 July 2014 20:06, Kurt Roeckx via RT wrote:
>>>>>> On Thu, Jul 03, 2014 at 07:51:28PM +0200, Toralf Förster via RT wrote:
>>>>>>> I think cppcheck is right here in void DES_ofb64_encrypt(), line 84, 85
>>>>>>> and 96, or ?:
>>>>>>>
>>>>>> The line before that:
>>>>>>
>>>>>> dp=d;
>>>>>>> l2c(v0,dp);<--- Uninitialized variable: d
>>>>>>> l2c(v1,dp);<--- Uninitialized variable: d
>>>>>>> while (l--)
>>>>>>> {
>>>>>>> if (n == 0)
>>>>>>> {
>>>>>>> DES_encrypt1(ti,schedule,DES_ENCRYPT);
>>>>>>> dp=d;
>>>>>>> t=ti[0]; l2c(t,dp);
>>>>>>> t=ti[1]; l2c(t,dp);
>>>>>>> save++;
>>>>>>> }
>>>>>>> *(out++)= *(in++)^d[n];<--- Uninitialized variable: d
>>>>>>> n=(n+1)&0x07;
>>>>>>> }
>>>>>>
>>>>>> d is uninitialized, but it's being written to, not read from,
>>>>>> so I don't see a problem with this.
>>>>>
>>>>> What?
>>>>
>>>> So l2c is:
>>>> #define l2c(l,c)(*((c)++)=(unsigned char)(((l))&0xff), \
>>>> *((c)++)=(unsigned char)(((l)>> 8L)&0xff), \
>>>> *((c)++)=(unsigned char)(((l)>>16L)&0xff), \
>>>> *((c)++)=(unsigned char)(((l)>>24L)&0xff))
>>>>
>>>> It reads v0 and v1 and writes to d (dp). d being uninitialized
>>>> shouldn't be an issue. Or am I missing something?
>>>
>>> It writes to *d, surely? Which means d uninitialised is very much an issue,
>>> no?
>>>
>>> However, now I've read the code (it'd help if people posted enough
>>> snippet to make that unnecessary!) I see d is DES_cblock, i.e. an
>>> array, so the diagnosis is basically incorrect. And therefore I agree
>>> with you, not a problem.
>>
>
>
> --
> Toralf
>
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
*_ctrl() functions
I've been experimenting with more type correctness and less casting. Some of the big casting culprits are the various _ctrl() functions, e.g. SSL_ctrl(). Does anyone have any clue why these exist? Is there any reason to not replace them with direct function calls (other than API stability)? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3436] Platform strategy
On 5 July 2014 18:46, Zoltan Arpadffy wrote: > Hi, > > I absolutely agree, that other less popular platforms need support. > > Unfortunately, reading the conversation in the last few days, I got a > feeling that the OpenSSL core development is not willing to support those > platforms in the main line, but will come up with a separate branch or other > merging strategy keeping the core code clean. I don't think that's the plan at all - but if no-one cares enough about them to make sure we can actually test and fix them on those platforms, _then_ we'll almost certainly drop support. I am not promising that we'll support any random platform that we can test and fix on, but that's surely a minimum requirement. And if someone out there is prepared to do the fixing for us, even better. > Whatever this solution will be - I silently accept this decision - moreover > understand the reasoning behind too. > ...but can not let the less popular platforms decline, therefore I decided > to set up Jenkins builds on polarhome.com's 30+ rare operating systems and > run daily builds and tests feeding the core team with propper test data and > eventually bugs from those environments right after a change occured in the > main code. > > This CI approach will improve the code quality generaly and reduce the gap > between the less supported platforms code and the main code. +1. > > polarhome has AIX, HP-UX, OpenVMS, QNX Ultrix, IRIX and many other platforms > and architectures that would be of interest. > > The service will be soon publicly available. > > Regards, > Z > > > > Quoting hmbrand via RT : > >> In the new roadmap I read on platform strategy: >> --8<--- >> Platform Strategy >> >> Moving forward OpenSSL will adopt the following policy: >> >> • There will be a defined set of primary platforms. The primary >> platforms will be Linux and FreeBSD. A primary platform is one where >> most development occurs. >> >> • In addition there will be a list of secondary platforms which are >> supported by the development team. >> >> • Platform specific code will be moved out of the main codebase >> (removing overuse of "ifdef"). >> >> • Legacy platforms that are unlikely to have wide deployment will be >> removed from the code. >> >> • Non-supported platforms requiring regular maintenance activities will >> eventually be removed from the code after first seeking community owners >> to support the platforms in platform specific repositories. >> >> Necessary criteria for a platform to be included in the secondary >> platform list includes: >> >> • Currency, i.e. a platform is widely deployed and in current use >> >> • Vendor support >> >> • Available to the dev team, i.e. the dev team have access to a suitable >> environment in which to test builds and deal with tickets and issues >> >> • Dev team ownership, i.e. at least one person on the team is willing to >> take some responsibility for a platform >> >> In addition the secondary list will be as small as possible so as not to >> spread the development team too thinly. >> >> The secondary platforms are still to be defined but will be based on the >> above criteria. For each primary/secondary platform, we should have, at >> least, a continuous integration box and a dev machine we can access for >> test/debug. We will seek support from the platform vendors or the >> community to provide access to these platforms. The secondary platform >> list will change over time, but an initial list will be produced within >> three months. >> >> The Platform Strategy will be phased in over a period of time based on >> how quickly we can refactor the code. >> -->8--- >> >> I think it is highly thinkable that the dev-team does not have access to >> proprietary OS's like HP-UX or AIX. Personally I give a shit about AIX, >> but I value HP-UX a lot and I might be the only one left still releasing >> software-depots (what HP uses for binary distributions) for a lot of >> OpenSource products for HP-UX back to 10.20, long dead and gone >> according to HP itself. >> >> Looking at the download-statistics, it is still used quite a lot >> worldwide. Who am I to judge that. I just have access to development >> boxes for HP-UX 10.20, 11.00, 11.11 (11iv1), 11.23 (11iv2 PA2), 11.23 >> (11iv2 ia64) and 11.31 (11iv3 ia64 and as I have a warm heart for >> OpenSourse, with perl5 especially, I will try to continue to release >> modern recent packages of heavily used OpenSource software for thes >> OS's. OpenSSL is one of those (you can check that on >> http://mirrors.develooper.com/hpux/ ) >> >> If you remove native code to support the OS versions the developers have >> no access to or do not care about, you will make it harder for the >> volunteers like me to post OpenSSL to those systems. We do this in our >> free time, as the "big" vendors do not support the OS releases they have >> declared end-of-life. >> >> This ticket is a plea to keep the code related to HP-UX in place or at >> least easily available: That mi
Re: BIO_get_accept_socket weirdness
On 5 July 2014 12:37, Kurt Roeckx wrote: > But then I found some MSDN documentation that says that Windows > allows others to hijack your socket when you've set SO_REUSEADDR > and the results are non-deterministic. They also created an > SO_EXCLUSIVEADDRUSE and I'm getting confused what it really does, > but they say that server applications should set it. If you think that opening the socket first is a security measure, then you've got some pretty serious problems. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
JPAKE?
Does anyone use it? We're considering removing or refactoring it... __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Unit Testing/statically analysing OpenSSL
On 9 July 2014 14:38, Paul Morriss wrote: > I am keen to get more involved in the development of OpenSSL, I am curious, > has the code been run through a static analysis tool (such as Coverity)? Coverity do run OpenSSL through their tool. The false positive rate is depressingly high (or was last I looked). > There are self checks, are there unit tests (e.g. Google Test/Mock)created > for any part of OpenSSL? Some :-) More would be good. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Return codes of EC_POINT_is_at_infinity, EC_POINT_is_on_curve
On 11 July 2014 09:53, Kyle Hamilton wrote:
> EC_POINT_is_on_curve is documented to return -1 on error, 0 if it's not
> on the curve, and 1 if it is on the curve.
>
> However, this breaks the standard idiom if(!EC_POINT_is_on_curve()) {
> return BAD_KEY; }, because it requires an additional test for an error
> condition.
Plenty of OpenSSL functions return -1, 0, 1. Plenty also return 0, 1.
Its not optimal.
> I don't know what the best outcome would be in this situation.
>
> -Kyle H
>
> On 7/11/2014 12:34 AM, balaji marisetti wrote:
>> Hi All,
>>
>> I have a doubt. Shouldn't the `EC_POINT_...` methods be returning -1
>> instead of 0 on error conditions?
>>
>> Thanks,
>> Balaji M
>> __
>> 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: [openssl.org #3442] [patch] AES XTS: supporting custom iv from openssl enc command
On 11 July 2014 08:30, Andy Polyakov via RT wrote: >>> openssl enc command with -aes-xxx-xts doesnt work if an IV is specified >> >> When you say it "doesn't work", what do you mean? Do you get an error? If so >> what is it? > > If only it was the actual problem. The thing is that *if* one wants to > make enc work with XTS, it has to be treated specially, i.e. not as any > other cipher. See http://marc.info/?t=13684475163&r=1&w=2 for > additional info. Another alternative to custom header mentioned in > referred thread can be to adhere to pre-defined fixed block size and > read 16 bytes ahead, so that when one hits end of file, and finds that > total_size%fixed_block_size<16, one can expand last block with > total_size%fixed_block_size. I mean last block would be variable size > from 16 up to fixed_block_size + 15 bytes, so that one doesn't have to > make up padding scheme. > >>> as below: >>> openssl enc -engine af_alg -aes-256-xts -in -out >>> -K >>> 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef -iv >>> >> >> I notice you have installed a custom engine. Does it advertise XTS support? >> What happens if you do not use the engine? > > I'm not saying that it's the case here, but it should be noted that in > this case engine can impose own behaviour on enc. Most notably it can > trick enc to treating whole file as one single sector [which is not > necessarily cryptographically sound]. > > Bottom line [still] is that enc is not the place to perform XTS, > *unless* it's treated specially. In other words question should not be > about setting IV, but about *if* XTS should be supported by enc, and if > so, how exactly. It seems to me this is why jamming modes like XTS into standard EVP as if they were like other modes is a less than great idea. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3442] [patch] AES XTS: supporting custom iv from openssl enc command
On 11 July 2014 11:56, Andy Polyakov wrote: >>> Bottom line [still] is that enc is not the place to perform XTS, >>> *unless* it's treated specially. In other words question should not be >>> about setting IV, but about *if* XTS should be supported by enc, and if >>> so, how exactly. >> >> It seems to me this is why jamming modes like XTS into standard EVP as >> if they were like other modes is a less than great idea. > > But providing own interface for every specific mode is also hardly fun. > I mean there ought to be balance. Now we have EVP that implies different > semantic in different modes. In other words application might have to > perform extra calls depending on mode (and in this particular case > problem is that enc doesn't do those calls). What would be alternative? > Distinct interface for every class of modes? Yes. > Can we define what makes up > such class? What do we expect from interface? Also note that either way, > the fact that it needs to be treated in enc in special way doesn't > change. It's not like I'm rejecting alternatives to EVP, but discussion > have to be more constructive. Right, agree that there has to be support for it, whatever happens. The problem with the current situation is that because the same interface is used (sometimes in strange ways) for incompatible modes, s/w can _think_ it is capable of doing, e.g., XTS, when in fact it is not. It doesn't seem helpful to give that appearance by re-using the API when it isn't actually true. That said, there's certainly something to be said for having a common API for the common parts. Perhaps the thing to do is to make it so when you create an XTS_EVP, that has the extra stuff needed to support XTS, but you can also extract from it an EVP (or whatever the common interface is) that can be used for the common subset. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Default Security Level
On 16 August 2014 19:50, Dominyk Tiller wrote: > Ah! That's where my confusion lies, I'm getting myself tied up between > development & stable. Thanks for the clarity on that. > > Homebrew is currently on 1.0.1i stable. These are the ssl2 ciphers active: > > "/usr/local/cellar/openssl/*/bin/openssl ciphers -ssl2 > IDEA-CBC-MD5:RC2-CBC-MD5:RC4-MD5:DES-CBC3-MD5:DES-CBC-MD5:EXP-RC2-CBC-MD5:EXP-RC4-MD5" > > Is that a security concern? Would there be any active consequences to > turning off those remaining -ssl2 ciphers? I tested the change with > pretty much every dependent formula that ships from Homebrew and > didn't encounter any issues. Would we gain any appreciable security by > knocking out those last few ssl2 ciphers? Err, yes. Almost all of them are weak and some are _very_ weak. > > Cheers, > > Dom > > > On 16 August 2014 18:05, Viktor Dukhovni wrote: >> >> On Sat, Aug 16, 2014 at 07:45:43AM +0100, Dominyk Tiller wrote: >> >> > I'm pretty sure I read somewhere in the OpenSSL documentation that the >> > recommended default level for compile is level 1, which kills the ssl2 >> > option, but effectively Homebrew has been building with level 0 >> > default thus far. >> >> SSLv2 is off by default (excluded by the DEFAULT cipherlist), even >> without disabling support for it at compile time. >> >> Security levels are only on the master development branch of OpenSSL, >> which has not been officially released. Homebrew users should be >> using 1.0.1 or soon 1.0.2 after than is released. >> >> So security levels, whose design IMHO is not yet entirely done, >> should not be in the picture at this time. >> >> > Did I completely hallucinate the documentation recommendation of >> > default level 1 security or is that actually somewhere? >> >> You may be confusing the master branch with stable releases. >> >> -- >> Viktor. >> __ >> 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: [openssl.org #2917] [PATCH] dsa: fix return code when -noout is used
On 17 August 2014 06:44, Rich Salz via RT wrote: > This will be fixed in the post-1.0.2 release. Why not fix in 1.0.2? > Thanks. (rsalz-monolith branch on github, akamai/openssl) > -- > Rich Salz, OpenSSL dev team; rs...@openssl.org > > __ > 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
1.0.2 head doesn't build...
Workaround (I wasn't sure if the functions were intended to be used
somewhere, so not deleted yet):
diff --git a/crypto/constant_time_test.c b/crypto/constant_time_test.c
index 1b4b18d..78e7fca 100644
--- a/crypto/constant_time_test.c
+++ b/crypto/constant_time_test.c
@@ -195,7 +195,7 @@ static int test_select_int(int a, int b)
}
return 0;
}
-
+/*
static int test_eq_int(int a, int b)
{
unsigned int equal = constant_time_eq_int(a, b);
@@ -235,7 +235,7 @@ static int test_eq_int_8(int a, int b)
}
return 0;
}
-
+*/
static unsigned int test_values[] = {0, 1, 1024, 12345, 32000, UINT_MAX/2-1,
UINT_MAX/2, UINT_MAX/2+1, UINT_MAX-1,
UINT_MAX};
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
HOST_c2l warnings...
Building 1.0.2 with gcc 4.9 and no-asm, I get a lot of: ADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIOS -O3 -Wall -c sha256.c In file included from sha256.c:115:0: sha256.c: In function 'sha256_block_data_order': ../md32_common.h:248:41: warning: right-hand operand of comma expression has no effect [-Wunused-value] l|=(((unsigned long)(*((c)++)))), \ ^ sha256.c:243:3: note: in expansion of macro 'HOST_c2l' HOST_c2l(data,l); T1 = X[0] = l; ROUND_00_15(0,a,b,c,d,e,f,g,h); ^ I don't think anything actually uses the value of HOST_c2l, so we could just drop the final comma and make the whole thing (void)? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl-dev] MacOS defaults?
Currently OpenSSL defaults to 32 bit in MacOS. I'm told it might be better to default to 64 bit these days. Does anyone have any views? -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] MacOS defaults?
Hmm. So why do I see this on my macbook? $ arch i386 On 6 March 2016 at 15:27, Blumenthal, Uri - 0553 - MITLL wrote: > Yes I think it's way past time to make this change. 64-bit has been the > norm for ages. > > > Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. > *From: *Ben Laurie > *Sent: *Sunday, March 6, 2016 06:21 > *To: *OpenSSL development > *Reply To: *openssl-dev@openssl.org > *Subject: *[openssl-dev] MacOS defaults? > > Currently OpenSSL defaults to 32 bit in MacOS. I'm told it might be better > to default to 64 bit these days. > > Does anyone have any views? > > > > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] MacOS defaults?
On 6 March 2016 at 22:40, Viktor Dukhovni wrote: > >> On Mar 6, 2016, at 12:00 PM, Ben Laurie wrote: >> >> Hmm. So why do I see this on my macbook? >> >> $ arch >> i386 > > Try "uname -m" x86_64 But AIUI, uname -m tells me what hardware I've got, arch tells me what mode it is running in... -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] MacOS defaults?
On 6 March 2016 at 23:05, Andy Polyakov wrote: >>> Hmm. So why do I see this on my macbook? >>> >>> $ arch >>> i386 >> >> Try "uname -m" > > This is not reliable. Because it must have changed recently, it used to > be i386 even on 64-bit systems. sysctl -n hw.optional.x86_64 is the way > to go, it's right there in ./config... Sure, and that is used to decide whether to offer the 64 bit version. But its not helping me on what should be default. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] MacOS defaults?
On 7 March 2016 at 09:59, Andy Polyakov wrote: > Hmm. So why do I see this on my macbook? > > $ arch > i386 Try "uname -m" >>> >>> This is not reliable. Because it must have changed recently, it used to >>> be i386 even on 64-bit systems. sysctl -n hw.optional.x86_64 is the way >>> to go, it's right there in ./config... >> >> Sure, and that is used to decide whether to offer the 64 bit version. >> But its not helping me on what should be default. > > I thought suggestion was to default to 64 bit whenever it is an option. > And uname -m *was* returning i386 even on system capable of executing > 64-bit code. So that sysctl is something that works in *either* situation. The question is: which is better? I've been told there's no advantage to 64 bit on MacOS unless you need the extra address space - if that's so, then we should default to 32 bit, I think. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Please consider delaying the Beta-1 freeze for a week or two
On 11 March 2016 at 09:24, Jeffrey Walton wrote:
>> noloader> Testing master on real hardware is showing some minor issues on a
>> few
>> noloader> platforms, including ARM32, ARM64, PowerPC and i686. In addition,
>> noloader> there seems to be one-off issues on other combinations, like VIA's
>> C7
>> noloader> processor on Linux.
>> noloader>
>> noloader> In addition to the base issues, there are other minor issues like
>> noloader> failing to configure and compile with 'no-comp'. Other
>> configuration
>> noloader> dependent issues include failed self tests under PowerPC in a
>> shared
>> noloader> configuration.
>> noloader>
>> noloader> Please consider delaying the freeze for a week or two while the
>> issues
>> noloader> are being ironed out.
>>
>> The upcoming release is the first beta of two planned, and we've
>> already delayed the first for a few extra days. It is not a final
>> release, so there's still time to fix things like these.
>>
>> Please see the bottom of the release strategy for the planned dates:
>>
>> http://openssl.org/policies/releasestrat.html
>
> Well, would it be possible to survey supported platforms and see if it
> makes sense to move forward at this point? Does the library maintain a
> matrix of test platforms and results?
>
> Releasing a Beta-1 seems like its missing the point if the the point
> of the beta is to test it. There are issues in {configure|build|test}
> on ARM32, ARM64, OpenBSD, Windows and some Linux i686 and x86_64
> targets/configurations. I'm also wondering about MIPS, NetBSD, FreeBSD
> and Gentoo.
FreeBSD hangs in the networking tests (70-*) currently.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4169] openssl-1.0.2e build still recommends deprecated (unnecessary?) `make depend`, returns numerous warnings abt not finding stddef.h
On 14 March 2016 at 20:31, Salz, Rich wrote: >> In particular, how do you know there is not one important warning hiding >> among the thousands of others? > > We're talking "make depend" Is there some good reason to not fix make depend? It should also be warning free. > Not compiling. > > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4169] openssl-1.0.2e build still recommends deprecated (unnecessary?) `make depend`, returns numerous warnings abt not finding stddef.h
BTW, there's something very suspicious about make clean; make _not_ working, when (presumably) make clean; make depend; make does work. On 14 March 2016 at 21:03, Ben Laurie wrote: > On 14 March 2016 at 20:31, Salz, Rich wrote: >>> In particular, how do you know there is not one important warning hiding >>> among the thousands of others? >> >> We're talking "make depend" > > Is there some good reason to not fix make depend? It should also be > warning free. > >> Not compiling. >> >> -- >> openssl-dev mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Out-of-tree build?
If I try to do one, I get: WARNING: there are indications that another build was made in the source directory. This build may have picked up artifacts from that build, the safest course of action is to clean the source directory and redo this configuration. even though I have just done make clean in the source directory. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Google OSS-Fuzz reward
Cool. On 14 May 2017 at 10:49, Kurt Roeckx wrote: > Google awarded us 1000 USD for the initial integration with > OSS-Fuzz. See > https://opensource.googleblog.com/2017/05/oss-fuzz-five-months-later-and.html > > I have asked Google to donate it to European Digital Rights (EDRi, > https://edri.org/). Google doubles the amount if you donate it to > a non-profit organization, so they should be receiving 2000 USD. > > > Kurt > > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Google OSS-Fuzz reward
I should also point out that up to $10k is available for "ideal" integration. On 14 May 2017 at 10:57, Ben Laurie wrote: > Cool. > > On 14 May 2017 at 10:49, Kurt Roeckx wrote: >> Google awarded us 1000 USD for the initial integration with >> OSS-Fuzz. See >> https://opensource.googleblog.com/2017/05/oss-fuzz-five-months-later-and.html >> >> I have asked Google to donate it to European Digital Rights (EDRi, >> https://edri.org/). Google doubles the amount if you donate it to >> a non-profit organization, so they should be receiving 2000 USD. >> >> >> Kurt >> >> -- >> openssl-dev mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Work on a new RNG for OpenSSL
On 26 June 2017 at 18:10, Salz, Rich via openssl-dev < openssl-dev@openssl.org> wrote: > > Pseudorandomness of the output has been a design goal/requirement only > > in SHA-3 family. Any prior hash function’s exhibition of this property is > > coincidental. > > > > Therefore I suggest using SHA3 instead. > > Is pseudorandomness a requirement? Or is it the "50% chance of a bitflip"? > You are asking if a pseudorandom number generator requires pseudorandomness? -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Work on a new RNG for OpenSSL
On 28 June 2017 at 03:41, Theodore Ts'o wrote: > On Wed, Jun 28, 2017 at 11:41:11AM +1000, Peter Waltenberg wrote: > > And FYI. On systems not backed with hardware RNG's /dev/random is > > extremely slow. 1-2 bytes/second is a DOS attack on it's own without any > > other effort required. > > Please, stop suggesting the use /dev/random. The right answer is > /dev/urandom or getrandom(2). > a) On Linux. b) If its the right answer, why is there a difference between /dev/random and /dev/urandom? > > - Ted > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [CVS] OpenSSL: openssl/apps/ s_client.c srp.c openssl/crypto/srp/ srp_...
On 12/03/2011 17:27, Dr. Stephen Henson wrote: > OpenSSL CVS Repository > http://cvs.openssl.org/ > > > Server: cvs.openssl.org Name: Dr. Stephen Henson > Root: /v/openssl/cvs Email: st...@openssl.org > Module: openssl Date: 12-Mar-2011 18:27:03 > Branch: HEAD Handle: 2011031217270003 > > Modified files: > openssl/appss_client.c srp.c > openssl/crypto/srp srp_lib.c srp_vfy.c > openssl/ssl tls_srp.c > > Log: > Fix warnings: signed/unisgned comparison, shadowing (in some cases global > functions such as rand() ). Hmmm. Why did I not get those warnings? -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [CVS] OpenSSL: openssl/apps/ s_client.c srp.c openssl/crypto/srp/ srp_...
On 12/03/2011 18:06, Dr. Stephen Henson wrote: > On Sat, Mar 12, 2011, Ben Laurie wrote: > >> On 12/03/2011 17:27, Dr. Stephen Henson wrote: >>> OpenSSL CVS Repository >>> http://cvs.openssl.org/ >>> >>> >>> >>> Server: cvs.openssl.org Name: Dr. Stephen Henson >>> Root: /v/openssl/cvs Email: st...@openssl.org >>> Module: openssl Date: 12-Mar-2011 18:27:03 >>> Branch: HEAD Handle: 2011031217270003 >>> >>> Modified files: >>> openssl/appss_client.c srp.c >>> openssl/crypto/srp srp_lib.c srp_vfy.c >>> openssl/ssl tls_srp.c >>> >>> Log: >>> Fix warnings: signed/unisgned comparison, shadowing (in some cases >>> global >>> functions such as rand() ). >> >> Hmmm. Why did I not get those warnings? >> > > Hmmm... which config target did you use? I've noticed some of the debug-ben* > ones are lacking the $gcc_devteam_warn option. debug-ben-debug. It has $gcc_devteam. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2469] pkcs12 with "-info" segfaults if the optional macData is not present.
On 13/03/2011 18:21, Stephen Henson via RT wrote: >> [j...@studt.net - Sun Mar 13 19:15:48 2011]: >> >> Perhaps the bomb.p12 got corrupted in transit? That looks a lot like >>feeding a non-ASN.1 file to openssl. >> > > It's easy enough to recreate such a file with: > > openssl pkcs12 -out foo.p12 -export -nomac -in foo.pem The reason I cared is I wanted to add a test for it. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2469] pkcs12 with "-info" segfaults if the optional macData is not present.
On 13/03/2011 18:15, Jim Studt via RT wrote: > Perhaps the bomb.p12 got corrupted in transit? That looks a lot like > feeding a non-ASN.1 file to openssl. This one does the same thing. > jim@rattus:~$ ls -l *.p12 ; md5sum *.p12 -rw-r--r-- 1 jim jim 718 > Mar 13 12:57 bomb.p12 -rw-r--r-- 1 jim jim 1587 Mar 13 12:56 > nomac.p12 41a2c4c8b8a78d906fd1ad7c14c06071 bomb.p12 > 7fe961d70f4520d6bd8359bfc657a449 nomac.p12 MD5(nomac.p12)= 1cababdf8f737c66d3ff1efd0daa426f -rw-r--r-- 1 ben ben 1553 Mar 13 20:30 nomac.p12 Slightly bemused - manually decoding the base64 from the email gives me a third length and checksum... >[ > > I just built 1.0.0d on a Debian squeeze machine and reran the tests > with the same results. > > I get the same problems and can see the same source error at line 650 > in apps/pkcs12.c now. > > The PKCS12 code I'm working with is improved now, attached to this > message is a second pkcs12 file which also does not have a MAC, but > is almost certainly a valid PKCS12 file. The password on nomac.p12 is > "password". > > Without fixing: > > jim@rattus:~/openssl-1.0.0d/apps$ ./openssl pkcs12 -nomacver -in > ~/bomb.p12 -info WARNING: can't open config file: > /usr/local/ssl/openssl.cnf Enter Import Password: Segmentation fault > > With fixing: > > jim@rattus:~/openssl-1.0.0d/apps$ ./openssl pkcs12 -nomacver -in > ~/bomb.p12 -info WARNING: can't open config file: > /usr/local/ssl/openssl.cnf Enter Import Password: PKCS7 Data > Certificate bag Bag Attributes: > subject=/CN=core.studt.net issuer=/CN=JimTest6 -BEGIN > CERTIFICATE- > MIICYDCCAcmgAwIBAgIBAzANBgkqhkiG9w0BAQUFADATMREwDwYDVQQDEwhKaW1U > ZXN0NjAeFw0xMTAzMDYwMDAwMDBaFw0zODAxMTgwMDAwMDBaMBkxFzAVBgNVBAMT > DmNvcmUuc3R1ZHQubmV0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCNyG3l > N5hosB07sjxEGTv6Oq+HJ3wrD0JKO/pqejqvpuVmJQGDbHIXZz27lS3pqX552kwK > XXOLyg4ZDPX5VZtBVZ/Xqk47Lr6yqpud4nO5YNlFmC4b6ICNXSAI9RpuncLIz9aC > YwFmhkUjXI+1riqdH9sEKkE7C2q8UbuRXbLS8QIDAQABo4G9MIG6MB0GA1UdDgQW > BBRkDTNDYxEhM8upUSk/C5YeOEU9yzA7BgNVHSMENDAygBRu/B6FuCZvw8eudHki > yMDGV/bZyaEXpBUwEzERMA8GA1UEAxMISmltVGVzdDaCAQEwDwYDVR0PAQH/BAUD > AwegADAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwEwLAYDVR0RBCUwI6IQ > Fg5jb3JlLnN0dWR0Lm5ldKIPFg1zYmkuc3R1ZHQubmV0MA0GCSqGSIb3DQEBBQUA > A4GBACQz9X7QwHaHUdpbFep7ssafO18O4mlKKRznxN4DgfDWBpm8Wp0Lrn5xFX4L > z5kzdVMOLD2kS+C9oVce4xw2qpO08DDLBZ5noI8gussxaCbsDLcmb9u7drmEzg4c > n7vZSXLKmhISehMqUz49kdDWLkA2QwW7ocClvpBA5nY6Zoq3 -END > CERTIFICATE- > > > On Mar 13, 2011, at 12:18 PM, Ben Laurie via RT wrote: > >> If I run >> >> openssl pkcs12 -nomacver -in bomb.p12 -info >> >> on 1.0.0-stable, I get >> >> 1211807336:error:0D07209B:asn1 encoding >> routines:ASN1_get_object:too long:asn1_lib.c:142: >> 1211807336:error:0D068066:asn1 encoding >> routines:ASN1_CHECK_TLEN:bad object header:tasn_dec.c:1306: >> 1211807336:error:0D06C03A:asn1 encoding >> routines:ASN1_D2I_EX_PRIMITIVE:nested asn1 error:tasn_dec.c:831: >> 1211807336:error:0D08303A:asn1 encoding >> routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 >> error:tasn_dec.c:751:Field=version, Type=PKCS12 > >> > -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2477] openssl-1.0.0d build ... make test fail
On 23/03/2011 21:56, Tim Jackson wrote: > I hit this, and a number of other issues related to turning off > particular ciphers, as well. I have patches (1.0.0-1.0.0d). If > there's enough interest, I'll submit them. Please do. > > From: via RT mailto:r...@openssl.org>> Reply-To: > mailto:openssl-dev@openssl.org>> Date: Tue, > 22 Mar 2011 11:40:10 +0100 Cc: > mailto:openssl-dev@openssl.org>> Subject: > [openssl.org #2477] openssl-1.0.0d build ... make test fail > > This transaction appears to have no content > > openssl-1.0.0d build ... make test fail > > > > I include the output of "make report" > > I don't know What to do. help me. > > Thanks. > > build without weak algorithms > ./config shared > no-rc2 no-rc4 no-des no-ssl2 => success make depend => success make > => success make test => fail > > --report-- > > OpenSSL self-test report: > > OpenSSL version: 1.0.0d Last change: Fix parsing of OCSP > stapling ClientHello extension. CVE... Options: > enable-shared no-des no-gmp no-jpake no-krb5 no-md2 no-mdc2 no-rc2 > no-rc4 no-rc5 no-rfc3779 no-ssl2 no-store no-zl ib no-zlib-dynamic > no-static-engine OS (uname): SunOS esm 5.10 Generic_142909-17 > sun4u sparc SUNW,Sun-Fire-V240 OS (config): > sun4u-whatever-solaris2 Target (default): solaris-sparcv9-gcc Target: > solaris-sparcv9-gcc Compiler: Configured with: ../configure > --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --enable-shared > --enable-languag es=c,c++,f77 Thread model: posix gcc version 3.4.6 > > __ > > OpenSSL Project http://www.openssl.org > Development Mailing List > openssl-dev@openssl.org Automated List Manager > majord...@openssl.org > > -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2484] [PATCH] DTLS: wrong fragment reassembly
On 01/04/2011 09:02, Robin Seggelmann via RT wrote: > Hi, > > On Apr 1, 2011, at 9:28 AM, via RT wrote: > >> I’ve tested DTLS implementation and know that several fixes has >> been applied for issues related to fragment. > > Thanks for testing! There is a known issue with the bitmask, the > patch #2457 addresses that, but has not been applied to the official > source yet. I'd be happier about applying these patches if there were tests that showed the brokenness without them ... are there? >> But, it still has a problem to reassemble fragments. Please, check >> the attached patch. > > Patch #2457 corrects the first value in bitmask_end_values[] to 0xff. > Your patch is basically doing the same, but you also shift the entire > array, which requires adjusting the index when accessing it by > subtracting one. Please have a look at http://sctp.fh-muenster.de for > the latest DTLS patches. It would be great if you could confirm that > #2457 fixes the problems you encountered. > > Best regards Robin > > > > > > > __ > > OpenSSL Project http://www.openssl.org > Development Mailing List > openssl-dev@openssl.org Automated List Manager > majord...@openssl.org > > -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
