Re: [openssl-dev] Work on a new RNG for OpenSSL
On 28 June 2017 at 03:41, Theodore Ts'owrote: > 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: [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] 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 <b...@links.org> wrote: > Cool. > > On 14 May 2017 at 10:49, Kurt Roeckx <k...@roeckx.be> 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
Cool. On 14 May 2017 at 10:49, Kurt Roeckxwrote: > 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
[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] [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 <b...@links.org> wrote: > On 14 March 2016 at 20:31, Salz, Rich <rs...@akamai.com> 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
On 14 March 2016 at 20:31, Salz, Richwrote: >> 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] Please consider delaying the Beta-1 freeze for a week or two
On 11 March 2016 at 09:24, Jeffrey Waltonwrote: >> 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] MacOS defaults?
On 7 March 2016 at 09:59, Andy Polyakovwrote: > 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] MacOS defaults?
On 6 March 2016 at 23:05, Andy Polyakovwrote: >>> 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 6 March 2016 at 22:40, Viktor Dukhovni <openssl-us...@dukhovni.org> wrote: > >> On Mar 6, 2016, at 12:00 PM, Ben Laurie <b...@links.org> 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?
Hmm. So why do I see this on my macbook? $ arch i386 On 6 March 2016 at 15:27, Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu> 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
[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] We're working on license changes
On Sat, 21 Nov 2015 at 22:39 Kurt Roeckx <k...@roeckx.be> wrote: > On Sat, Nov 21, 2015 at 10:09:51PM +0000, Ben Laurie wrote: > > On Sat, 21 Nov 2015 at 21:14 Kurt Roeckx <k...@roeckx.be> wrote: > > > > > On Sat, Nov 21, 2015 at 12:02:22PM -0800, Quanah Gibson-Mount wrote: > > > > --On Saturday, November 21, 2015 8:24 PM +0100 Kurt Roeckx < > > > k...@roeckx.be> > > > > wrote: > > > > >>So the MPLv2 is compatible with the APLv2. The MPLv2 is compatible > > > with > > > > >>the GPLv2 and the APLv2 is copmatible with GPLv3. The MPLv2 has > patent > > > > >>language along the same lines as the APLv2. I haven't looked into > it > > > > >>and I am not a lawyer, but would it be possible to dual license > via the > > > > >>MPLv2 and the APLv2? If so, that would keep the patent > protections and > > > > >>allow both GPLv2 and GPLv3 compatibility. > > > > > > > > > >I think the answer to that is complicated. The safest way to look > > > > >at this, at what most people seem to be doing, is that if it all > > > > >ends up in 1 "program", all licenses must be complied with at the > > > > >same time and so must be compatible. > > > > > > > > That's an interesting take I've not encountered. Our legal office > has us > > > > elect specifically which license we will be using when pulling in > > > software > > > > with multiple licenses. > > > > > > I think there was a misunderstanding of what I was trying to say. > > > If you have software A with license B or C, and software D makes > > > use of that with license E or F. If that in turn makes use of G > > > with license H or I, you will need to find a combination of > > > (B || C) && (E || F) && (H || I) where you have 3 license that are > > > compatible, not just 2 from (B || C) && (E || F), and then 2 from > > > (E || F) && (H || I). > > > > > > > Well, now you put it that way, I have to disagree. > > > > Let's say: > > > > A and D are compatible because B and E are. > > D and G are compatible because F and H are. > > G and A are compatible because I and C are. > > > > Who has been harmed here? > > Some people will argue that A is then covered by both B and C at > the same time and you need to comply with both, Who is the "you" that needs to comply with both? All the complying has already been done. Only A, D and G need comply, and they do. > it's no longer an > option to use either B or C. The same goes for D being both E > and F, and G being both H and I. > > If you drop the last line, because there is no direct link between > A and G, you end up with just B, E, F and H you need to comply > with at the same time. But some will argue that that is not good > enough because they're all linked together. > > > 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] We're working on license changes
On Sat, 21 Nov 2015 at 21:14 Kurt Roeckxwrote: > On Sat, Nov 21, 2015 at 12:02:22PM -0800, Quanah Gibson-Mount wrote: > > --On Saturday, November 21, 2015 8:24 PM +0100 Kurt Roeckx < > k...@roeckx.be> > > wrote: > > >>So the MPLv2 is compatible with the APLv2. The MPLv2 is compatible > with > > >>the GPLv2 and the APLv2 is copmatible with GPLv3. The MPLv2 has patent > > >>language along the same lines as the APLv2. I haven't looked into it > > >>and I am not a lawyer, but would it be possible to dual license via the > > >>MPLv2 and the APLv2? If so, that would keep the patent protections and > > >>allow both GPLv2 and GPLv3 compatibility. > > > > > >I think the answer to that is complicated. The safest way to look > > >at this, at what most people seem to be doing, is that if it all > > >ends up in 1 "program", all licenses must be complied with at the > > >same time and so must be compatible. > > > > That's an interesting take I've not encountered. Our legal office has us > > elect specifically which license we will be using when pulling in > software > > with multiple licenses. > > I think there was a misunderstanding of what I was trying to say. > If you have software A with license B or C, and software D makes > use of that with license E or F. If that in turn makes use of G > with license H or I, you will need to find a combination of > (B || C) && (E || F) && (H || I) where you have 3 license that are > compatible, not just 2 from (B || C) && (E || F), and then 2 from > (E || F) && (H || I). > Well, now you put it that way, I have to disagree. Let's say: A and D are compatible because B and E are. D and G are compatible because F and H are. G and A are compatible because I and C are. Who has been harmed here? ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init
On Sat, 17 Oct 2015 at 06:35 Kurt Roeckx via RTwrote: > On Fri, Oct 16, 2015 at 09:44:22PM +, Kaduk, Ben via RT wrote: > > On 10/16/2015 04:35 PM, Kurt Roeckx via RT wrote: > > > On Fri, Oct 16, 2015 at 06:50:36PM +, Kurt Roeckx via RT wrote: > > >> On Fri, Oct 16, 2015 at 04:50:59PM +, Matt Caswell via RT wrote: > > >>> In a well-behaved program there is no undefined behaviour. The "buf + > > >>> len < buf" check will always evaluate to false, so in that sense is > > >>> useless but it *is* well defined. > > >> The defined behaviour for the "buf + len" part is as far as I know > > >> that you're that the pointer should point inside the allocated > > >> object or 1 byte after it. So as long as "len" is in the valid > > >> range, the "buf + len" part should be well defined. The test with > > >> -1 is clearly undefined. > > >> > > >> As far as I know in the comparison pointers they should point > > >> to the same object. But the check seems to imply that they might > > >> not point to the same object or that buf is not the base of the > > >> object. But since len is unsigned only the option that they don't > > >> point to the same object seems to be left. > > >> > > >> So it's unclear to me if this is defined behaviour or not. > > > So thinking about this some more, it seems to be a check for > > > undefined behaviour that probably itself is still defined. > > > > > > That probably also means the compiler can assume that it's always > > > false and eliminate the check, it's probably just not smart enough > > > yet. > > > > > > > I think it is unambiguous that there are values of unsigned char *buf > > and size_t len for which evaluating (bug + len < buf) invokes undefined > > behavior -- the sheer act of performing the addition buf + len can > > produce undefined behavior, even before any comparison. I am as-yet > > uncertain whether the case when buf points into the middle of an object > > and len is (size_t)-1 invokes undefined behavior, but I am inclined to > > believe that it is also undefined behavior. > > Just to clarify what I mean, buf + len can both have defined and > undefined meaning, it depends on the value of len, so the compiler > can probably not say anything about that part without knowing all > the callers of that code. As long as it has a defined meaning the > compiler will probably do it. buf + len < buf also seems to have > a defined meaning, but in all defined meanings it's false, and so > the compiler can just optimize that part away. > > Anyway, I would really like this to be changed. > +1 > > > 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] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init
On Sat, 17 Oct 2015 at 06:35 Kurt Roeckx via RTwrote: > On Fri, Oct 16, 2015 at 09:44:22PM +, Kaduk, Ben via RT wrote: > > On 10/16/2015 04:35 PM, Kurt Roeckx via RT wrote: > > > On Fri, Oct 16, 2015 at 06:50:36PM +, Kurt Roeckx via RT wrote: > > >> On Fri, Oct 16, 2015 at 04:50:59PM +, Matt Caswell via RT wrote: > > >>> In a well-behaved program there is no undefined behaviour. The "buf + > > >>> len < buf" check will always evaluate to false, so in that sense is > > >>> useless but it *is* well defined. > > >> The defined behaviour for the "buf + len" part is as far as I know > > >> that you're that the pointer should point inside the allocated > > >> object or 1 byte after it. So as long as "len" is in the valid > > >> range, the "buf + len" part should be well defined. The test with > > >> -1 is clearly undefined. > > >> > > >> As far as I know in the comparison pointers they should point > > >> to the same object. But the check seems to imply that they might > > >> not point to the same object or that buf is not the base of the > > >> object. But since len is unsigned only the option that they don't > > >> point to the same object seems to be left. > > >> > > >> So it's unclear to me if this is defined behaviour or not. > > > So thinking about this some more, it seems to be a check for > > > undefined behaviour that probably itself is still defined. > > > > > > That probably also means the compiler can assume that it's always > > > false and eliminate the check, it's probably just not smart enough > > > yet. > > > > > > > I think it is unambiguous that there are values of unsigned char *buf > > and size_t len for which evaluating (bug + len < buf) invokes undefined > > behavior -- the sheer act of performing the addition buf + len can > > produce undefined behavior, even before any comparison. I am as-yet > > uncertain whether the case when buf points into the middle of an object > > and len is (size_t)-1 invokes undefined behavior, but I am inclined to > > believe that it is also undefined behavior. > > Just to clarify what I mean, buf + len can both have defined and > undefined meaning, it depends on the value of len, so the compiler > can probably not say anything about that part without knowing all > the callers of that code. As long as it has a defined meaning the > compiler will probably do it. buf + len < buf also seems to have > a defined meaning, but in all defined meanings it's false, and so > the compiler can just optimize that part away. > > Anyway, I would really like this to be changed. > +1 > > > 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] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init
On Fri, 16 Oct 2015 at 01:32 Matt Caswell via RTwrote: > > > On 15/10/15 20:53, Alexander Cherepanov via RT wrote: > > On 2015-10-15 15:41, Matt Caswell via RT wrote: > >> The purpose of the sanity check is not then for security, but to guard > >> against programmer error. For a correctly functioning program this test > >> should never fail. For an incorrectly functioning program it may do. It > >> is not guaranteed to fail because the test could be compiled away but, > >> most likely, it will. We can have some degree of confidence that the > >> test works and does not get compiled away in most instances because, as > >> you point out, an explicit check for it appears in packettest.c and, to > >> date, we have had no reported failures. > > > > What was not entirely clear from the original bug report is that, while > > the check is not compiled away, it's compiled into something completely > > different from what is written in the source. Specifically, the check > > "buf + len < buf" is optimized into "len >> 63" on 64-bit platform, i.e. > > "(ssize_t)len < 0" or "len > SIZE_MAX / 2". This is not a check for > > overflow at all, it doesn't even depend on the value of "buf". > > > > If this is what was intended then it's better to write it explicitly. If > > this is not what was intended then some other approach is required. > > I'd say that is an instance of the compiler knowing better than us how > big |len| would have to be in order to trigger an overflow. Those rules > are going to be platform specific so we should not attempt to second > guess them, but instead let the optimiser do its job. > If it is, then the compiler is wrong, surely? e.g. if buf is 0xfff...fff, and len is 1, you get an overflow, which the optimised version does not catch. What I'm not understanding from this thread is what the argument is against avoiding undefined behaviour? ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init
On Fri, 16 Oct 2015 at 01:32 Matt Caswell via RTwrote: > > > On 15/10/15 20:53, Alexander Cherepanov via RT wrote: > > On 2015-10-15 15:41, Matt Caswell via RT wrote: > >> The purpose of the sanity check is not then for security, but to guard > >> against programmer error. For a correctly functioning program this test > >> should never fail. For an incorrectly functioning program it may do. It > >> is not guaranteed to fail because the test could be compiled away but, > >> most likely, it will. We can have some degree of confidence that the > >> test works and does not get compiled away in most instances because, as > >> you point out, an explicit check for it appears in packettest.c and, to > >> date, we have had no reported failures. > > > > What was not entirely clear from the original bug report is that, while > > the check is not compiled away, it's compiled into something completely > > different from what is written in the source. Specifically, the check > > "buf + len < buf" is optimized into "len >> 63" on 64-bit platform, i.e. > > "(ssize_t)len < 0" or "len > SIZE_MAX / 2". This is not a check for > > overflow at all, it doesn't even depend on the value of "buf". > > > > If this is what was intended then it's better to write it explicitly. If > > this is not what was intended then some other approach is required. > > I'd say that is an instance of the compiler knowing better than us how > big |len| would have to be in order to trigger an overflow. Those rules > are going to be platform specific so we should not attempt to second > guess them, but instead let the optimiser do its job. > If it is, then the compiler is wrong, surely? e.g. if buf is 0xfff...fff, and len is 1, you get an overflow, which the optimised version does not catch. What I'm not understanding from this thread is what the argument is against avoiding undefined behaviour? ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Continuous Integration for OpenSSL
On Mon, 24 Aug 2015 at 19:35 Matt Caswell m...@openssl.org wrote: On 24/08/2015 10:08, Ben Laurie wrote: On Mon, 24 Aug 2015 at 03:56 Salz, Rich rs...@akamai.com mailto:rs...@akamai.com wrote: On Sat, 22 Aug 2015 at 01:56 Salz, Rich rs...@akamai.com mailto:rs...@akamai.com wrote: Thanks! We have several cross-compile builds running on Cisco's build farm. The more the merrier. I am sure ARM would be appreciated. Are these linked from the website somewhere? No. John Foley @Cisco posted bout them, I think, and Matt has a login and is careful about failures. Seems to me they should be on the website. BTW I tracked it down: http://openssl-sanity.cisco.com:8080/ However, doesn't appear to be up. :-( It's up; link is wrong: https://openssl-sanity.cisco.com:8443/ Ah, thanks. So, should we link to this (and any other CI sites) from the website? Also, next stupid question, if I look there, I see for example: https://openssl-sanity.cisco.com:8443/job/1_0_1_mips/ How do I find out how that's being built? Matt ___ 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] Continuous Integration for OpenSSL
On Mon, 24 Aug 2015 at 03:56 Salz, Rich rs...@akamai.com wrote: On Sat, 22 Aug 2015 at 01:56 Salz, Rich rs...@akamai.com wrote: Thanks! We have several cross-compile builds running on Cisco's build farm. The more the merrier. I am sure ARM would be appreciated. Are these linked from the website somewhere? No. John Foley @Cisco posted bout them, I think, and Matt has a login and is careful about failures. Seems to me they should be on the website. BTW I tracked it down: http://openssl-sanity.cisco.com:8080/ However, doesn't appear to be up. :-( I believe it also (at least when working) sends email on failures - would be nice if those went to a list... ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Continuous Integration for OpenSSL
On Mon, 24 Aug 2015 at 09:53 Alessandro Ghedini alessan...@ghedini.me wrote: On Sat, Aug 22, 2015 at 12:55:43am +, Salz, Rich wrote: Thanks! We have several cross-compile builds running on Cisco's build farm. The more the merrier. I am sure ARM would be appreciated. Does this mean that you are not oging to enable Travis CI? If anything this buildfarm didn't seem to catch the 25efcb44 build failure. Additionally Travis automatically builds pull requests submitted on GitHUb, in order to give immediate feedback to submitter and reviewer. So I think it still makes sense to have Travis alongside this Cisco buildfarm (as you said, the more the merrier), but if you don't agree then both #63 and #373 pull requests can be closed (if anything, two less open PRs...). I've just +1'ed #373 - if another OpenSSL dev will also do that, I'll push it... ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Continuous Integration for OpenSSL
On Sat, 22 Aug 2015 at 01:56 Salz, Rich rs...@akamai.com wrote: Thanks! We have several cross-compile builds running on Cisco's build farm. The more the merrier. I am sure ARM would be appreciated. Are these linked from the website somewhere? ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3992] [PATCH] Allow RFC6962 Signed Certificate Timestamps to be disabled
On Thu, 6 Aug 2015 at 14:14 David Woodhouse via RT r...@openssl.org wrote: This code does open-coded division on 64-bit quantities and thus when building with GCC on 32-bit platforms will require functions such as __umoddi3 and __udivdi3 from libgcc. In constrained environments such as firmware, those functions may not be available. So make it possible to compile out SCT support, which in fact (in the case of UEFI) we don't need anyway. I am curious why you think you don't need CT for UEFI? ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3992] [PATCH] Allow RFC6962 Signed Certificate Timestamps to be disabled
On Thu, 6 Aug 2015 at 14:14 David Woodhouse via RT r...@openssl.org wrote: This code does open-coded division on 64-bit quantities and thus when building with GCC on 32-bit platforms will require functions such as __umoddi3 and __udivdi3 from libgcc. In constrained environments such as firmware, those functions may not be available. So make it possible to compile out SCT support, which in fact (in the case of UEFI) we don't need anyway. I am curious why you think you don't need CT for UEFI? ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] common factors in (p-1) and (q-1)
On Sat, 1 Aug 2015 at 14:22 mancha manc...@zoho.com wrote: On Fri, Jul 31, 2015 at 06:46:22PM +, Viktor Dukhovni wrote: On Fri, Jul 31, 2015 at 11:19:39AM -0700, Bill Cox wrote: Cool observation. From running a bit of Python code, it looks like the probability that GCD(p-1, p-q) == 4 is a bit higher than 15%, at least for random numbers between 2048 and 4096 bits long. It looks like putting in a GCD(p-1, q-1) check will slow down finding suitable p and q by around a factor of 6.5. A smaller slow-down would be incurred one were to restrict both of p,q to 3 mod 4. In that case 2 would be the largest common even factor of (p-1) and (q-1), and any appreciably large common odd factor (necessarily above 17863 due to how each of p/q is chosen) would be very rare. Is there a good argument for adding the gcd test? How big does the common factor have to be for any information it might provide to be substantially useful in finding 1/e mod phi(m)? The larger the common factor is, the smaller the probability of p-1 and q-1 sharing it (for a given sufficiently large prime factor r of (p-1), the probability of (q-1) also having that factor is 1/(r-1)). If say r needs be 80 bits long to be useful in attacking RSA 1024, then only ~1 in 2^80 (p-1,q-1) pairs will have such a common factor, which is sufficiently rare not warrant any attention. Also one still needs to be able to fully factor (n-1). After tens of thousands of trials, I managed to generate a (p,q,n) triple with a 1024-bit modulus n in which (p-1,q-1) have a common odd factor. n = 123727085863382195696899362818055010267368591819174730632443285012648773223152448218495408371737254282531468855140111723936275062312943433684139231097953508685462994307654703316031424869371422426773001891452680576333954733056995016189880381373567072504551999849596021790801362257131899242011337424119163152403 e = F_4 = 65537 gcd(p-1,q-1) = 2 * 28559 What can the OP tell us about d, p or q? Can anyone produce a full factorization of n - 1? n-1 = 2 * 3^3 * 7 * 13 * 67 * 2399 * 28559 * 5485062554686449262177590194597345407327047899375366044215091312099734701911004226037445837630559113651708968440813791318544450398897628672342337619064712331937685677843283385813601700381667290503026724160750373906990713551823941904482040860073543880341612964100618466865014941425056336718955019 That is not a prime factorisation. -- https://twitter.com/mancha140 ___ 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] FreeBSD build broken?
On 8 June 2015 at 13:27, John Foley fol...@cisco.com wrote: Is anyone having problems building 1.0.2-stable on FreeBSD? It appears the following commit may have broken the build: https://github.com/openssl/openssl/commit/f877da9cedb95df94105d7292f8e0963175e58dc Here's the error we're seeing: [jenkins@freebird ~/tmp/openssl-OpenSSL_1_0_2-stable]$ gmake depend making depend in crypto... gmake[1]: Entering directory '/usr/home/jenkins/tmp/openssl-OpenSSL_1_0_2-stable/crypto' ../util/domd: makedepend: not found mv: Makefile.new: No such file or directory Makefile:136: recipe for target 'local_depend' failed gmake[1]: *** [local_depend] Error 127 gmake[1]: Leaving directory '/usr/home/jenkins/tmp/openssl-OpenSSL_1_0_2-stable/crypto' Makefile:466: recipe for target 'depend' failed gmake: *** [depend] Error 1 makedepend is provided by the port devel/makedepend. ___ 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
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
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
Re: [openssl.org #2917] [PATCH] dsa: fix return code when -noout is used
On 17 August 2014 06:44, Rich Salz via RT r...@openssl.org 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
Re: Default Security Level
On 16 August 2014 19:50, Dominyk Tiller dominyktil...@gmail.com 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 openssl-us...@dukhovni.org 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 #3442] [patch] AES XTS: supporting custom iv from openssl enc command
On 11 July 2014 11:56, Andy Polyakov ap...@openssl.org 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: Unit Testing/statically analysing OpenSSL
On 9 July 2014 14:38, Paul Morriss paul.morr...@tokenbay.co.uk 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
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
*_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 z...@polarhome.com 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 r...@openssl.org: 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 might include *not* using libtool, as that was once created to make linking on other systems than Linux easier, but it only complicated things for those
Re: BIO_get_accept_socket weirdness
On 5 July 2014 12:37, Kurt Roeckx k...@roeckx.be 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
Re: [openssl.org #3428] bug report : crypto/des/ofb64enc.c: Uninitialized variable: d
On 3 July 2014 22:35, Kurt Roeckx k...@roeckx.be wrote: On Thu, Jul 03, 2014 at 09:28:47PM +0100, Ben Laurie wrote: On 3 July 2014 20:06, Kurt Roeckx via RT r...@openssl.org 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 b...@links.org wrote: On 3 July 2014 22:35, Kurt Roeckx k...@roeckx.be wrote: On Thu, Jul 03, 2014 at 09:28:47PM +0100, Ben Laurie wrote: On 3 July 2014 20:06, Kurt Roeckx via RT r...@openssl.org 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 toralf.foers...@gmx.de 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 b...@links.org wrote: On 3 July 2014 22:35, Kurt Roeckx k...@roeckx.be wrote: On Thu, Jul 03, 2014 at 09:28:47PM +0100, Ben Laurie wrote: On 3 July 2014 20:06, Kurt Roeckx via RT r...@openssl.org 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
Re: [openssl.org #3277] OpenSSL s_client doc missing option
On 2 July 2014 23:17, Rich Salz via RT r...@openssl.org 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 rs...@akamai.com 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 rs...@akamai.com 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 rs...@akamai.com 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 ty...@mit.edu 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 rs...@akamai.com 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 r...@openssl.org 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
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 z...@polarhome.com 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 mbl...@acm.org 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 mbl...@acm.org 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 mbl...@acm.org 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 b...@links.org 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 t...@multitalents.net 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 rs...@akamai.com 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
[openssl.org #3241] Patch: Constify openssl tables.
As you know, constification is my vice. The stuff that works easily has been committed to master at 8892ce7. Other branches/attribution not dealt with. __ 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 m...@openssl.org 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: 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) navne...@cisco.com wrote: Update : Crashes are seen only on MAC OS X and not seen on windows. Thanks Regards, -NK From: Cisco Employee navne...@cisco.com Reply-To: openssl-dev@openssl.org openssl-dev@openssl.org Date: Tuesday, 10 June 2014 11:20 AM To: openssl-dev@openssl.org 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=unavailable, data=unavailable, length=unavailable, ec=unavailable, bytes_transferred=unavailable, op=unavailable)(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: [PATCH] 1.0.1h does not build nor test HEARBEAT bug on OpenVMS
On 6 June 2014 22:21, Zoltan Arpadffy z...@polarhome.com 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 rich...@levitte.org + $! Zoltan Arpadffy arpad...@polarhome.com $! $! 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: New unbiased prime generator function fixes
You didn't update the test... On 1 June 2014 21:26, Viktor Dukhovni openssl-us...@dukhovni.org 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, 2327, 2363, 2447, 2459, + 2483, 2543, 2567, 2579, 2603, 2627, 2687,
Re: open ssl rsa key generation improvement idea
On 28 May 2014 00:03, Viktor Dukhovni openssl-us...@dukhovni.org 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 manc...@zoho.com 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, nicolas@free.fr 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 b...@links.org À: OpenSSL development openssl-dev@openssl.org 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 openssl-us...@dukhovni.org 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: Prime generation
On 27 May 2014 09:16, Joseph Birr-Pixton jpix...@gmail.com wrote: On 27 May 2014 08:45, Peter Waltenberg pwal...@au1.ibm.com 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 russ...@russellharkins.info 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;byteLoopsizeof(BN_ULONG);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
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 russ...@russellharkins.info 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;byteLoopsizeof(BN_ULONG);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
Fwd: Using Frankencerts for Automated Adversarial,Testing of Certificate Validation,in SSL/TLS Implementations
-- Forwarded message -- From: Martin Haufschild martin.haufsch...@uni-rostock.de 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
Re: test/heartbleed_test.c
On 20 May 2014 06:40, The Doctor,3328-138 Ave Edmonton AB T5Y 1M4,669-2000,473-4587 doc...@doctor.nl2k.ab.ca wrote: Found that strndup would not work. I had to add #if !HAVE_STRNDUP #include stdio.h #include string.h #include sys/types.h #include malloc.h /* 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: 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 revision to diff against --stdout your.patch On 24 April 2014 10:06, Ben Laurie b...@links.org 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 mbl...@acm.org wrote: On Thu, Apr 24, 2014 at 1:31 PM, Ben Laurie b...@links.org 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 fr...@baggins.org 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 k...@roeckx.be 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 k...@roeckx.be 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
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: [openssl.org #3203] Normalize PFS key exchange labels
On 1 January 2014 21:39, Daniel Kahn Gillmor d...@fifthhorseman.net 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
Re: [openssl.org #3203] Normalize PFS key exchange labels
On 20 December 2013 18:51, Stephen Henson via RT r...@openssl.org 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 d...@fifthhorseman.net 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
Re: Avoid multiple locks in FIPS mode commit to OpenSSL_1_0_1-stable
On 11 December 2013 08:55, Tomas Mraz tm...@redhat.com 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: Self-initialization of locking/threadid callbacks and auto-detection of features
On 22 October 2013 06:47, Nico Williams n...@cryptonector.com 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: 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 b...@links.org 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 ap...@openssl.org 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
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: [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 r...@openssl.org 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 r...@openssl.org 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 { snip 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|?
Re: [openssl] OpenSSL source code branch master updated. 5e3ff62c345c976cd1ffbcc5e6042f55264977f5
On 8 September 2013 13:35, Dr. Stephen Henson st...@openssl.org 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] 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 b...@openssl.org 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 b...@links.org 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 sde...@secondstryke.com 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 b...@links.org Date: Thu Aug 1 15:17:23 2013 +0100 More cleanup. commit a66d5a4a77bc086c9eff36a096e9e74d8bca8be5 Author: Ben Laurie b...@links.org Date: Thu Aug 1 12:33:15 2013 +0100 More cleanup. commit 976fac84e0920feb9aaa9cb67002c4eb64bccde8 Author: Ben Laurie b...@links.org Date: Thu Aug 1 11:14:23 2013 +0100 Make it build. commit b3943dbb18ea920c6bd71a52762ba16728e27e3d Author: Scott Deboy sde...@secondstryke.com 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 sde...@secondstryke.com 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 sde...@secondstryke.com 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 supp data allocated in the callback */ + if (generated_supp_data) + { + OPENSSL_free(generated_supp_data); + generated_supp_data = NULL
Re: AES GCM considerations in regards to SP800-38D
On 15 August 2013 09:21, Tomas Mraz tm...@redhat.com 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 ap...@openssl.org 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
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
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 a...@flossmanuals.net Date: 1 August 2013 08:23 Subject: [Foundations] 2013 Doc Camp CFP To: Foundations List foundati...@lists.freedesktop.org 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
Re: [Patch] ALPN Implementation for OpenSSL
On 24 June 2013 22:00, Jeff Mendoza (MS OPEN TECH) jemen...@microsoft.com 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
Re: parallel make broken
On 22 June 2013 23:06, Mike Frysinger vap...@gentoo.org wrote: On Saturday 22 June 2013 15:07:49 Ben Laurie wrote: On 22 June 2013 19:04, Mike Frysinger vap...@gentoo.org wrote: On Wednesday 19 June 2013 07:21:39 Ben Laurie wrote: On 18 June 2013 22:35, Mike Frysinger vap...@gentoo.org 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 21 June 2013 02:29, Thor Lancelot Simon t...@panix.com 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 vap...@gentoo.org wrote: On Wednesday 19 June 2013 07:21:39 Ben Laurie wrote: On 18 June 2013 22:35, Mike Frysinger vap...@gentoo.org 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: [Patch] ALPN Implementation for OpenSSL
On 20 June 2013 21:46, Jeff Mendoza (MS OPEN TECH) jemen...@microsoft.com 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
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 rob.stradl...@comodo.com 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 rob.stradl...@comodo.com wrote: On 14/06/13 10:20, Ben Laurie wrote: On 14 June 2013 09:39, Rob Stradling rob.stradl...@comodo.com 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 rob.stradl...@comodo.com wrote: On 14/06/13 12:31, Ben Laurie wrote: On 14 June 2013 12:25, Rob Stradling rob.stradl...@comodo.com wrote: snip 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 doc...@doctor.nl2k.ab.ca 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 rob.stradl...@comodo.com wrote: On 14/06/13 13:58, Ben Laurie wrote: On 14 June 2013 13:57, Rob Stradling rob.stradl...@comodo.com wrote: snip 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