Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published
In message <20160117172321.gd16...@calimero.vinschen.de> on Sun, 17 Jan 2016 18:23:21 +0100, Corinna Vinschen said: vinschen> Just to be clear, this does not help unless the -s option is dropped vinschen> from the linker command line. This part of my patch (or something along vinschen> the lines) is still necessary, otherwise building the debuginfo files vinschen> fails. No worries, those previous patches are on my todo list Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published
In message <20160117171738.gb16...@calimero.vinschen.de> on Sun, 17 Jan 2016 18:17:38 +0100, Corinna Vinschen said: vinschen> On Jan 17 17:30, Richard Levitte wrote: vinschen> > In message <20160117153235.gb9...@calimero.vinschen.de> on Sun, 17 Jan 2016 16:32:35 +0100, Corinna Vinschen said: vinschen> > [...] vinschen> > vinschen> This is pretty non-standard. By not allowing to extend CFLAGS from the vinschen> > vinschen> environment, you require all distros to patch the OpenSSL package to fit vinschen> > vinschen> their needs in terms of the build flags. vinschen> > vinschen> > Actually, I forgot another possibility, to just pass them on the vinschen> > Configure / config command line, like so: vinschen> > vinschen> > ./config -ggdb -O2 -pipe -Wimplicit-function-declaration \ vinschen> > -fdebug-prefix-map=${BUILDDIR}=/usr/src/debug/openssl-1.1.0-pre2-1 \ vinschen> > -fdebug-prefix-map=${SOURCEDIR}=/usr/src/debug/openssl-1.1.0-pre2-1 vinschen> > vinschen> > Basically, anything start with a dash or plus that Configure doesn't vinschen> > recognise as its own, it will pass down: vinschen> > vinschen> > * if it starts with -l. -L or -Wl, into EX_LIBS, which is vinschen> > essentially flags to the linker. vinschen> > * otherwise, into CFLAG / CFLAGS. vinschen> > vinschen> > Can't believe I forgot to mention that, considering I use it all the vinschen> > time... vinschen> vinschen> This works. I can't believe this worked so simple all the time. Is vinschen> that documented somewhere? If not, it certainly should. Badly, I have to admit. Looks like this in the big wall of commenting at the beginning of Configure: # - + compiler options are passed through vinschen> > If my info about the Configure command line above wasn't good enough, vinschen> > I do have a fairly simple idea on how to allow for using environment vinschen> > variables to expand the diverse flag items, more or less directly into vinschen> > the target structure. vinschen> vinschen> I guess it's your choice then. The above seems to work vinschen> nicely for us, so there's no pressure. Well, the path of least resistance and all that ;-) Seriously, it'll stay on my mind, but unless someone screams bloody murder, it's not gonna be on my top ten priority list. I'm sure you understand. Of course, if someone else in the team feels compelled, by all means! vinschen> It would be good to know if that helps for Debian as well, vinschen> of course. Yup, agreed. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published
On Jan 17 18:17, Corinna Vinschen wrote: > On Jan 17 17:30, Richard Levitte wrote: > > In message <20160117153235.gb9...@calimero.vinschen.de> on Sun, 17 Jan 2016 > > 16:32:35 +0100, Corinna Vinschen said: > > [...] > > vinschen> This is pretty non-standard. By not allowing to extend CFLAGS > > from the > > vinschen> environment, you require all distros to patch the OpenSSL package > > to fit > > vinschen> their needs in terms of the build flags. > > > > Actually, I forgot another possibility, to just pass them on the > > Configure / config command line, like so: > > > > ./config -ggdb -O2 -pipe -Wimplicit-function-declaration \ > > -fdebug-prefix-map=${BUILDDIR}=/usr/src/debug/openssl-1.1.0-pre2-1 \ > > -fdebug-prefix-map=${SOURCEDIR}=/usr/src/debug/openssl-1.1.0-pre2-1 > > > > Basically, anything start with a dash or plus that Configure doesn't > > recognise as its own, it will pass down: > > > > * if it starts with -l. -L or -Wl, into EX_LIBS, which is > > essentially flags to the linker. > > * otherwise, into CFLAG / CFLAGS. > > > > Can't believe I forgot to mention that, considering I use it all the > > time... > > This works. I can't believe this worked so simple all the time. > [...] Just to be clear, this does not help unless the -s option is dropped from the linker command line. This part of my patch (or something along the lines) is still necessary, otherwise building the debuginfo files fails. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat signature.asc Description: PGP signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published
On Jan 17 17:30, Richard Levitte wrote: > In message <20160117153235.gb9...@calimero.vinschen.de> on Sun, 17 Jan 2016 > 16:32:35 +0100, Corinna Vinschen said: > [...] > vinschen> This is pretty non-standard. By not allowing to extend CFLAGS from > the > vinschen> environment, you require all distros to patch the OpenSSL package > to fit > vinschen> their needs in terms of the build flags. > > Actually, I forgot another possibility, to just pass them on the > Configure / config command line, like so: > > ./config -ggdb -O2 -pipe -Wimplicit-function-declaration \ > -fdebug-prefix-map=${BUILDDIR}=/usr/src/debug/openssl-1.1.0-pre2-1 \ > -fdebug-prefix-map=${SOURCEDIR}=/usr/src/debug/openssl-1.1.0-pre2-1 > > Basically, anything start with a dash or plus that Configure doesn't > recognise as its own, it will pass down: > > * if it starts with -l. -L or -Wl, into EX_LIBS, which is > essentially flags to the linker. > * otherwise, into CFLAG / CFLAGS. > > Can't believe I forgot to mention that, considering I use it all the > time... This works. I can't believe this worked so simple all the time. Is that documented somewhere? If not, it certainly should. > vinschen> CFLAGS+=$(OPENSSL_CFLAGS) > > += is a GNU make extension, and therefore a no can do. We need to > stay with generic make. I expected that but had to point it out ;) > vinschen> OPENSSL_CFLAGS= -D_WINDLL -DOPENSSL_PIC -DZLIB > -DOPENSSL_THREADS[...etc...] > vinschen> CFLAGS="${BUILD_CFLAGS) $(OPENSSL_CFLAGS)" > vinschen> > vinschen> and the package build system has to set $BUILD_CFLAGS. That would > vinschen> be sufficient as well. > > If my info about the Configure command line above wasn't good enough, > I do have a fairly simple idea on how to allow for using environment > variables to expand the diverse flag items, more or less directly into > the target structure. I guess it's your choice then. The above seems to work nicely for us, so there's no pressure. It would be good to know if that helps for Debian as well, of course. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat signature.asc Description: PGP signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published
In message <20160117153235.gb9...@calimero.vinschen.de> on Sun, 17 Jan 2016 16:32:35 +0100, Corinna Vinschen said: vinschen> On Jan 17 14:56, Richard Levitte wrote: vinschen> > In message <20160117131603.ga10...@roeckx.be> on Sun, 17 Jan 2016 14:16:04 +0100, Kurt Roeckx said: vinschen> > vinschen> > kurt> On Sun, Jan 17, 2016 at 01:14:14AM +0100, Richard Levitte wrote: vinschen> > kurt> > OPT_FLAGS would be for optimizing, do I get that right? I suggest you vinschen> > kurt> > have a look at Configurations/10-main.conf, you might notice vinschen> > kurt> > configuration items like debug_cflags, release_cflags, debug_lflags vinschen> > kurt> > and release_lflags. If you have a look at my refactor-build branch, vinschen> > kurt> > you will see a fairly thorough Configurations/README. If you look the vinschen> > kurt> > commit titled "Refactor config - move templates docs asm templates to vinschen> > kurt> > Configurations", you'll find the documentation that's applicable to vinschen> > kurt> > what Configure in the master branch supports... later editions are vinschen> > kurt> > currently only supported in my branch. vinschen> > kurt> vinschen> > kurt> In Debian we have a system that where you can override things like vinschen> > kurt> the CFLAGS, and I wonder how easy it will be to integrate that vinschen> > kurt> with your new system. vinschen> > kurt> [...] vinschen> > kurt> Is there an easy way to I can override the flags with vinschen> > kurt> dpkg-buildflags? vinschen> > vinschen> > I see where you're going with this. vinschen> > vinschen> > As it is right now, there is no way to affect Configure via the vinschen> > environment, except for the names of certain commands. Personally, vinschen> > I'd say that using those should be done carefully. I have no plans to vinschen> > expand on the use of environment variables... vinschen> > vinschen> > However, there is always the possibility to quickly write up a small vinschen> > config target for yourself in Configurations, and have them inherit vinschen> > the items for an already existing target. For example: vinschen> > vinschen> > cflags=` ... dpkg-buildflags --get CFLAGS`; \ vinschen> > cat < Configurations/01-debian-tmp.conf vinschen> > %targets = ( vinschen> > "debian-linux-x86_64" => { vinschen> > inherit_from => [ "linux-x86_64" ], vinschen> > cflags => "$cflags", vinschen> > } vinschen> > ); vinschen> > 1; vinschen> > EOF vinschen> > vinschen> > If you want to just append or prepend your flags, you do this with the vinschen> > cflags item: vinschen> > vinschen> > cflags => sub { join(" ", $@, "$cflags"); }, vinschen> > vinschen> > In my refactor-build branch, I've added some lazy functions to do the vinschen> > same: vinschen> > vinschen> > cflags => add("$cflags"), vinschen> > vinschen> > or vinschen> > vinschen> > cflags => add_before("$cflags"), # to prepend vinschen> > vinschen> > Did that help? vinschen> vinschen> This is pretty non-standard. By not allowing to extend CFLAGS from the vinschen> environment, you require all distros to patch the OpenSSL package to fit vinschen> their needs in terms of the build flags. Actually, I forgot another possibility, to just pass them on the Configure / config command line, like so: ./config -ggdb -O2 -pipe -Wimplicit-function-declaration \ -fdebug-prefix-map=${BUILDDIR}=/usr/src/debug/openssl-1.1.0-pre2-1 \ -fdebug-prefix-map=${SOURCEDIR}=/usr/src/debug/openssl-1.1.0-pre2-1 Basically, anything start with a dash or plus that Configure doesn't recognise as its own, it will pass down: * if it starts with -l. -L or -Wl, into EX_LIBS, which is essentially flags to the linker. * otherwise, into CFLAG / CFLAGS. Can't believe I forgot to mention that, considering I use it all the time... vinschen> Why is that necessary? It's no problem at all with autotool vinschen> or cmake-based configurations, and it's really *needed* by vinschen> distros. Before we all go off on a tangent, I'd like to point out that I'm only stating how it works as it is right now. We're not strangers to making changes, even though carefully most of the times ;-) vinschen> CFLAGS+=$(OPENSSL_CFLAGS) += is a GNU make extension, and therefore a no can do. We need to stay with generic make. vinschen> OPENSSL_CFLAGS= -D_WINDLL -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS[...etc...] vinschen> CFLAGS="${BUILD_CFLAGS) $(OPENSSL_CFLAGS)" vinschen> vinschen> and the package build system has to set $BUILD_CFLAGS. That would vinschen> be sufficient as well. If my info about the Configure command line above wasn't good enough, I do have a fairly simple idea on how to allow for using environment variables to expand the diverse flag items, more or less directly into the target structure. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project
Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published
On Jan 17 14:56, Richard Levitte wrote: > In message <20160117131603.ga10...@roeckx.be> on Sun, 17 Jan 2016 14:16:04 > +0100, Kurt Roeckx said: > > kurt> On Sun, Jan 17, 2016 at 01:14:14AM +0100, Richard Levitte wrote: > kurt> > OPT_FLAGS would be for optimizing, do I get that right? I suggest you > kurt> > have a look at Configurations/10-main.conf, you might notice > kurt> > configuration items like debug_cflags, release_cflags, debug_lflags > kurt> > and release_lflags. If you have a look at my refactor-build branch, > kurt> > you will see a fairly thorough Configurations/README. If you look the > kurt> > commit titled "Refactor config - move templates docs asm templates to > kurt> > Configurations", you'll find the documentation that's applicable to > kurt> > what Configure in the master branch supports... later editions are > kurt> > currently only supported in my branch. > kurt> > kurt> In Debian we have a system that where you can override things like > kurt> the CFLAGS, and I wonder how easy it will be to integrate that > kurt> with your new system. > kurt> [...] > kurt> Is there an easy way to I can override the flags with > kurt> dpkg-buildflags? > > I see where you're going with this. > > As it is right now, there is no way to affect Configure via the > environment, except for the names of certain commands. Personally, > I'd say that using those should be done carefully. I have no plans to > expand on the use of environment variables... > > However, there is always the possibility to quickly write up a small > config target for yourself in Configurations, and have them inherit > the items for an already existing target. For example: > > cflags=` ... dpkg-buildflags --get CFLAGS`; \ > cat < Configurations/01-debian-tmp.conf > %targets = ( > "debian-linux-x86_64" => { > inherit_from => [ "linux-x86_64" ], > cflags => "$cflags", > } > ); > 1; > EOF > > If you want to just append or prepend your flags, you do this with the > cflags item: > > cflags => sub { join(" ", $@, "$cflags"); }, > > In my refactor-build branch, I've added some lazy functions to do the > same: > > cflags => add("$cflags"), > > or > > cflags => add_before("$cflags"), # to prepend > > Did that help? This is pretty non-standard. By not allowing to extend CFLAGS from the environment, you require all distros to patch the OpenSSL package to fit their needs in terms of the build flags. Why is that necessary? It's no problem at all with autotool or cmake-based configurations, and it's really *needed* by distros. Ideally you simply define CFLAGS differently, along the lines of OPENSSL_CFLAGS= -D_WINDLL -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS[...etc...] CFLAGS+=$(OPENSSL_CFLAGS) This way, the package build system can simply set CFLAGS to the desired value, as is typical. Alternatively, you can support a specific variable, e.g. OPENSSL_CFLAGS= -D_WINDLL -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS[...etc...] CFLAGS="${BUILD_CFLAGS) $(OPENSSL_CFLAGS)" and the package build system has to set $BUILD_CFLAGS. That would be sufficient as well. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat signature.asc Description: PGP signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published
Hi Richard, On Jan 17 01:14, Richard Levitte wrote: > In message <20160116183724.gi12...@calimero.vinschen.de> on Sat, 16 Jan 2016 > 19:37:24 +0100, Corinna Vinschen said: > > vinschen> Who had this funny idea to use the Windows definitions when > building for > vinschen> Cygwin? > > I'm afraid that is lost in the thin web of history ;-) Heh :) > vinschen> > vinschen> > vinschen> Please, please, please, Cygwin is a *POSIX* layer. Please don't use > vinschen> Windows functions on Cygwin, use POSIX functions and POSIX methods, > vinschen> *unless* it's really necessary. > > vinschen> > > I hear ya. > > vinschen> Last but not least, we have a small build problem when building for > the > vinschen> distro: To build the packages with additional debuginfo packages, > the > vinschen> packages must not be built with the -s option, plus we have to > induce a > vinschen> few options for the sake of creating the debuginfo information. Up > to > vinschen> 1.0.2 we do this by tweaking openssl's build system. We add an > expression > vinschen> $(OPT_CFLAGS) to the CFLAGS definition for that. If there's a > better, > vinschen> easier way to do this, I'd be grateful for a hint. > > OPT_FLAGS would be for optimizing, do I get that right? Uh no, I think OPT stands for "optional" in this case. I didn't invent the name, actually :) > I suggest you > have a look at Configurations/10-main.conf, you might notice > configuration items like debug_cflags, release_cflags, debug_lflags > and release_lflags. If you have a look at my refactor-build branch, > you will see a fairly thorough Configurations/README. If you look the > commit titled "Refactor config - move templates docs asm templates to > Configurations", you'll find the documentation that's applicable to > what Configure in the master branch supports... later editions are > currently only supported in my branch. I did that, but I don't see that the new build system would allow that any better than the previous build system. There's still no way to induce optional build flags into a build, unless you manually override CFLAGS, which is quite a burdon. In our case the options in OPT_CFLAGS added by the build systems are something along the lines of -ggdb -O2 -pipe -Wimplicit-function-declaration \ -fdebug-prefix-map=${BUILDDIR}=/usr/src/debug/openssl-1.1.0-pre2-1 \ -fdebug-prefix-map=${SOURCEDIR}=/usr/src/debug/openssl-1.1.0-pre2-1 This is required to make sure that the debuginfo is created during the build at all, and to make sure the mapping in the debuginfo is not using the build paths, but rather the installation paths. Otherwise the debuginfo pointer in the object files will point to the wrong paths. The above is provided by the package build system and depends on the path the build is done in, as well as the version of the package. This info is added by the package build system for all packages built for the distro. However, what that means is, we need to have a way to induce variable content into the release_cflags from "outside". This is usually no problem at all for packages with, e.g., autotool-based configuration. It's also not a Cygwin-specific problem. I dare say that many distro package builders have certain requirements to add variable build options to a build to allow distro-specific build options. It would be really nice if the OpenSSL build systems would allow that by default. Otherwise distros will always have to patch the package before being able to build it in a distro-specific way. > vinschen> The attached patchset fixes all of the above. With this, > vinschen> openssl-1.1.0-pre2 builds fine for Cygwin. > > I'll have a closer look at all that tomorrow. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat signature.asc Description: PGP signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published
In message <20160117131603.ga10...@roeckx.be> on Sun, 17 Jan 2016 14:16:04 +0100, Kurt Roeckx said: kurt> On Sun, Jan 17, 2016 at 01:14:14AM +0100, Richard Levitte wrote: kurt> > OPT_FLAGS would be for optimizing, do I get that right? I suggest you kurt> > have a look at Configurations/10-main.conf, you might notice kurt> > configuration items like debug_cflags, release_cflags, debug_lflags kurt> > and release_lflags. If you have a look at my refactor-build branch, kurt> > you will see a fairly thorough Configurations/README. If you look the kurt> > commit titled "Refactor config - move templates docs asm templates to kurt> > Configurations", you'll find the documentation that's applicable to kurt> > what Configure in the master branch supports... later editions are kurt> > currently only supported in my branch. kurt> kurt> In Debian we have a system that where you can override things like kurt> the CFLAGS, and I wonder how easy it will be to integrate that kurt> with your new system. kurt> kurt> We have a tool called dpkg-buildflags. By default it now returns: kurt> $ dpkg-buildflags kurt> CFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security kurt> CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2 kurt> CXXFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security kurt> FCFLAGS=-g -O2 -fstack-protector-strong kurt> FFLAGS=-g -O2 -fstack-protector-strong kurt> GCJFLAGS=-g -O2 -fstack-protector-strong kurt> LDFLAGS=-Wl,-z,relro kurt> OBJCFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security kurt> OBJCXXFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security kurt> kurt> In the 1.0.2 branch I use this: kurt> my $debian_cflags = `dpkg-buildflags --get CFLAGS` . `dpkg-buildflags --get CPPFLAGS` . `dpkg-buildflags --get LDFLAGS` . "-Wa,--noexecstack -Wall"; kurt> kurt> And then use $debian_cflags in the targets. kurt> kurt> There were was no way to separate clfags/lfdlags, so I needed to kurt> combine it. kurt> kurt> dpkg-buildflags can return different things depending on environment variables. kurt> Some examples: kurt> $ DEB_BUILD_OPTIONS=noopt dpkg-buildflags --get CFLAGS kurt> -g -O0 -fstack-protector-strong -Wformat -Werror=format-security kurt> kurt> $ DEB_BUILD_OPTIONS=hardening=-all dpkg-buildflags --get CFLAGS kurt> -g -O2 kurt> kurt> $ DEB_CFLAGS_APPEND=-O3 dpkg-buildflags --get CFLAGS kurt> -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -O3 kurt> kurt> kurt> There are environment variables for both the maintainer to set the kurt> defaults and someone who then wants to build the package with kurt> different settings. kurt> kurt> (I should move the -Wa,--noexecstack -Wall to environment kurt> variables.) kurt> kurt> Is there an easy way to I can override the flags with kurt> dpkg-buildflags? I see where you're going with this. As it is right now, there is no way to affect Configure via the environment, except for the names of certain commands. Personally, I'd say that using those should be done carefully. I have no plans to expand on the use of environment variables... However, there is always the possibility to quickly write up a small config target for yourself in Configurations, and have them inherit the items for an already existing target. For example: cflags=` ... dpkg-buildflags --get CFLAGS`; \ cat < Configurations/01-debian-tmp.conf %targets = ( "debian-linux-x86_64" => { inherit_from => [ "linux-x86_64" ], cflags => "$cflags", } ); 1; EOF If you want to just append or prepend your flags, you do this with the cflags item: cflags => sub { join(" ", $@, "$cflags"); }, In my refactor-build branch, I've added some lazy functions to do the same: cflags => add("$cflags"), or cflags => add_before("$cflags"), # to prepend Did that help? Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published
On Sun, Jan 17, 2016 at 01:14:14AM +0100, Richard Levitte wrote: > OPT_FLAGS would be for optimizing, do I get that right? I suggest you > have a look at Configurations/10-main.conf, you might notice > configuration items like debug_cflags, release_cflags, debug_lflags > and release_lflags. If you have a look at my refactor-build branch, > you will see a fairly thorough Configurations/README. If you look the > commit titled "Refactor config - move templates docs asm templates to > Configurations", you'll find the documentation that's applicable to > what Configure in the master branch supports... later editions are > currently only supported in my branch. In Debian we have a system that where you can override things like the CFLAGS, and I wonder how easy it will be to integrate that with your new system. We have a tool called dpkg-buildflags. By default it now returns: $ dpkg-buildflags CFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2 CXXFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security FCFLAGS=-g -O2 -fstack-protector-strong FFLAGS=-g -O2 -fstack-protector-strong GCJFLAGS=-g -O2 -fstack-protector-strong LDFLAGS=-Wl,-z,relro OBJCFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security OBJCXXFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security In the 1.0.2 branch I use this: my $debian_cflags = `dpkg-buildflags --get CFLAGS` . `dpkg-buildflags --get CPPFLAGS` . `dpkg-buildflags --get LDFLAGS` . "-Wa,--noexecstack -Wall"; And then use $debian_cflags in the targets. There were was no way to separate clfags/lfdlags, so I needed to combine it. dpkg-buildflags can return different things depending on environment variables. Some examples: $ DEB_BUILD_OPTIONS=noopt dpkg-buildflags --get CFLAGS -g -O0 -fstack-protector-strong -Wformat -Werror=format-security $ DEB_BUILD_OPTIONS=hardening=-all dpkg-buildflags --get CFLAGS -g -O2 $ DEB_CFLAGS_APPEND=-O3 dpkg-buildflags --get CFLAGS -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -O3 There are environment variables for both the maintainer to set the defaults and someone who then wants to build the package with different settings. (I should move the -Wa,--noexecstack -Wall to environment variables.) Is there an easy way to I can override the flags with dpkg-buildflags? Kurt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published
In message <20160116183724.gi12...@calimero.vinschen.de> on Sat, 16 Jan 2016 19:37:24 +0100, Corinna Vinschen said: vinschen> Who had this funny idea to use the Windows definitions when building for vinschen> Cygwin? I'm afraid that is lost in the thin web of history ;-) vinschen> vinschen> vinschen> Please, please, please, Cygwin is a *POSIX* layer. Please don't use vinschen> Windows functions on Cygwin, use POSIX functions and POSIX methods, vinschen> *unless* it's really necessary. vinschen> I hear ya. vinschen> Last but not least, we have a small build problem when building for the vinschen> distro: To build the packages with additional debuginfo packages, the vinschen> packages must not be built with the -s option, plus we have to induce a vinschen> few options for the sake of creating the debuginfo information. Up to vinschen> 1.0.2 we do this by tweaking openssl's build system. We add an expression vinschen> $(OPT_CFLAGS) to the CFLAGS definition for that. If there's a better, vinschen> easier way to do this, I'd be grateful for a hint. OPT_FLAGS would be for optimizing, do I get that right? I suggest you have a look at Configurations/10-main.conf, you might notice configuration items like debug_cflags, release_cflags, debug_lflags and release_lflags. If you have a look at my refactor-build branch, you will see a fairly thorough Configurations/README. If you look the commit titled "Refactor config - move templates docs asm templates to Configurations", you'll find the documentation that's applicable to what Configure in the master branch supports... later editions are currently only supported in my branch. vinschen> The attached patchset fixes all of the above. With this, vinschen> openssl-1.1.0-pre2 builds fine for Cygwin. I'll have a closer look at all that tomorrow. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published
On Jan 16 20:01, Corinna Vinschen wrote: > On Jan 16 19:59, Kurt Roeckx wrote: > > On Sat, Jan 16, 2016 at 07:42:50PM +0100, Corinna Vinschen wrote: > > > On Jan 16 19:37, Corinna Vinschen wrote: > > > > On Jan 14 15:44, Richard Levitte wrote: > > > > > -BEGIN PGP SIGNED MESSAGE- > > > > > Hash: SHA1 > > > > > > > > > > > > > > >OpenSSL version 1.1.0 pre release 2 (alpha) > > > > >=== > > > > > > > > I tried to build this for Cygwin and got some problems. > > > > [...] > > > > The attached patchset fixes all of the above. With this, > > > > openssl-1.1.0-pre2 builds fine for Cygwin. > > > > > > I added another patch to this mail which sets the default CPU for 32 bit > > > Cygwin builds to i686, as outlined in another mail. Cygwin won't run on > > > older CPUs anyway. The path depends on the 2nd patch from my previous > > > mail. > > > > Is gcc configure to only produce i686 code on cygwin, and so can > > we maybe drop the -march instead? > > Oh yes, indeed. Sorry I missed that :} Here's the changed patch. Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat From 544d74273588d8d3e887a2b0b32d2e5afb76d7d9 Mon Sep 17 00:00:00 2001 From: Corinna Vinschen Date: Sat, 16 Jan 2016 19:39:37 +0100 Subject: [PATCH] On 32 bit Cygwin, build for 686 CPUs only Cygwin only supports at least i686 on 32 bit. Just build for the default CPU type. Signed-off-by: Corinna Vinschen --- Configurations/10-main.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Configurations/10-main.conf b/Configurations/10-main.conf index d732a82..14ed3a7 100644 --- a/Configurations/10-main.conf +++ b/Configurations/10-main.conf @@ -1224,7 +1224,7 @@ "Cygwin" => { inherit_from => [ asm("x86_asm") ], cc => "gcc", -cflags => "\$(OPT_CFLAGS) -DTERMIOS -DL_ENDIAN -march=i486 -Wall", +cflags => "\$(OPT_CFLAGS) -DTERMIOS -DL_ENDIAN -Wall", debug_cflags => "-g -O0", release_cflags => "-O3 -fomit-frame-pointer", sys_id => "CYGWIN", -- 2.5.0 signature.asc Description: PGP signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published
On Jan 16 19:59, Kurt Roeckx wrote: > On Sat, Jan 16, 2016 at 07:42:50PM +0100, Corinna Vinschen wrote: > > On Jan 16 19:37, Corinna Vinschen wrote: > > > On Jan 14 15:44, Richard Levitte wrote: > > > > -BEGIN PGP SIGNED MESSAGE- > > > > Hash: SHA1 > > > > > > > > > > > >OpenSSL version 1.1.0 pre release 2 (alpha) > > > >=== > > > > > > I tried to build this for Cygwin and got some problems. > > > [...] > > > The attached patchset fixes all of the above. With this, > > > openssl-1.1.0-pre2 builds fine for Cygwin. > > > > I added another patch to this mail which sets the default CPU for 32 bit > > Cygwin builds to i686, as outlined in another mail. Cygwin won't run on > > older CPUs anyway. The path depends on the 2nd patch from my previous > > mail. > > Is gcc configure to only produce i686 code on cygwin, and so can > we maybe drop the -march instead? Oh yes, indeed. Sorry I missed that :} Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat signature.asc Description: PGP signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published
On Sat, Jan 16, 2016 at 07:42:50PM +0100, Corinna Vinschen wrote: > On Jan 16 19:37, Corinna Vinschen wrote: > > On Jan 14 15:44, Richard Levitte wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA1 > > > > > > > > >OpenSSL version 1.1.0 pre release 2 (alpha) > > >=== > > > > I tried to build this for Cygwin and got some problems. > > [...] > > The attached patchset fixes all of the above. With this, > > openssl-1.1.0-pre2 builds fine for Cygwin. > > I added another patch to this mail which sets the default CPU for 32 bit > Cygwin builds to i686, as outlined in another mail. Cygwin won't run on > older CPUs anyway. The path depends on the 2nd patch from my previous > mail. Is gcc configure to only produce i686 code on cygwin, and so can we maybe drop the -march instead? Kurt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published
On Jan 16 19:37, Corinna Vinschen wrote: > On Jan 14 15:44, Richard Levitte wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > > >OpenSSL version 1.1.0 pre release 2 (alpha) > >=== > > I tried to build this for Cygwin and got some problems. > [...] > The attached patchset fixes all of the above. With this, > openssl-1.1.0-pre2 builds fine for Cygwin. I added another patch to this mail which sets the default CPU for 32 bit Cygwin builds to i686, as outlined in another mail̀‡. Cygwin won't run on older CPUs anyway. The path depends on the 2nd patch from my previous mail. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat From 3dca00f13e7ba3e798ef3f0cc059881056d1f43d Mon Sep 17 00:00:00 2001 From: Corinna Vinschen Date: Sat, 16 Jan 2016 19:39:37 +0100 Subject: [PATCH] On 32 bit Cygwin, build for 686 CPUs only Cygwin only supports at least i686 on 32 bit. Just build for this CPU type. Signed-off-by: Corinna Vinschen --- Configurations/10-main.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Configurations/10-main.conf b/Configurations/10-main.conf index d732a82..02f9878 100644 --- a/Configurations/10-main.conf +++ b/Configurations/10-main.conf @@ -1224,7 +1224,7 @@ "Cygwin" => { inherit_from => [ asm("x86_asm") ], cc => "gcc", -cflags => "\$(OPT_CFLAGS) -DTERMIOS -DL_ENDIAN -march=i486 -Wall", +cflags => "\$(OPT_CFLAGS) -DTERMIOS -DL_ENDIAN -march=i686 -Wall", debug_cflags => "-g -O0", release_cflags => "-O3 -fomit-frame-pointer", sys_id => "CYGWIN", -- 2.5.0 signature.asc Description: PGP signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published
On Jan 14 15:44, Richard Levitte wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > >OpenSSL version 1.1.0 pre release 2 (alpha) >=== I tried to build this for Cygwin and got some problems. First, with 1,0.2, we built the Cygwin package with the options enable-tlsext and no-krb5. The 1.1.0 notes mention that Kerberos ciphersuite support has been removed, so am I right that "no-krb5" just isn't required anymore? And what about "enable-tlsext"? Is that unchangable default now? Second, it doesn't build. I configured as usual for the Cygwin distro with the following set of options: shared zlib enable-camellia enable-seed enable-rfc3779 enable-cms \ enable-md2 no-idea no-rc5 [omitting enable-tlsext and no-krb5] The build bailed out with the following error: gcc [...] -c -o ct_lib.o ct_lib.c In file included from /usr/include/w32api/windows.h:95:0, from ../../include/openssl/async.h:60, from ../../ssl/ssl_locl.h:166, from ct_lib.c:63: ../../ssl/ssl_locl.h:1110:5: error: expected specifier-qualifier-list before '(' token X509_EXTENSIONS *tlsext_ocsp_exts; ^ : recipe for target 'ct_lib.o' failed Who had this funny idea to use the Windows definitions when building for Cygwin? Please, please, please, Cygwin is a *POSIX* layer. Please don't use Windows functions on Cygwin, use POSIX functions and POSIX methods, *unless* it's really necessary. And please, if you really think that Cygwin is lacking and you have to fall back to using Windows stuff, please *ask* first. It's really not helpful to use too much native Windows stuff because you're circumventing Cygwin's POSIX lauer and you might (i.e will) inadvertently break something in POSIX applications built for Cygwin. In this case, since Cygwin supports pthreads, why don't you use async_posix.h, which is the right thing to do on a POSIX system. While I was looking into this, I also found the snippet in apps/speed.c which completely breaks Cygwin POSIX-like signal handling by using native Win32 functions rather than POSIX signal functions. Please, please, don't. Additionally it turned out that the configury used two different macros to control a Cygwin build for no good reason, OPENSSL_SYS_CYGWIN and OPENSSL_SYS_WIN32_CYGWIN. Last but not least, we have a small build problem when building for the distro: To build the packages with additional debuginfo packages, the packages must not be built with the -s option, plus we have to induce a few options for the sake of creating the debuginfo information. Up to 1.0.2 we do this by tweaking openssl's build system. We add an expression $(OPT_CFLAGS) to the CFLAGS definition for that. If there's a better, easier way to do this, I'd be grateful for a hint. The attached patchset fixes all of the above. With this, openssl-1.1.0-pre2 builds fine for Cygwin. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat From ab1dba32d73a6c3df6bfebe68c9bd4440260b0d6 Mon Sep 17 00:00:00 2001 From: Corinna Vinschen Date: Sat, 16 Jan 2016 19:30:48 +0100 Subject: [PATCH 1/2] Use POSIX functions on Cygwin, not Win32 function Signed-off-by: Corinna Vinschen --- apps/speed.c| 10 +- crypto/async/arch/async_posix.h | 2 +- crypto/async/arch/async_win.h | 2 +- include/openssl/async.h | 2 +- test/asynctest.c| 4 ++-- 5 files changed, 6 insertions(+), 14 deletions(-) diff --git a/apps/speed.c b/apps/speed.c index d45a6f9..5bf1685 100644 --- a/apps/speed.c +++ b/apps/speed.c @@ -94,16 +94,8 @@ # include #endif -#if defined(_WIN32) || defined(__CYGWIN__) +#if defined(_WIN32) # include -# if defined(__CYGWIN__) && !defined(_WIN32) - /* - * should define _WIN32, which normally is mutually exclusive - * with __CYGWIN__, but if it didn't... - */ -# define _WIN32 - /* this is done because Cygwin alarm() fails sometimes. */ -# endif #endif #include diff --git a/crypto/async/arch/async_posix.h b/crypto/async/arch/async_posix.h index c247888..475b56f 100644 --- a/crypto/async/arch/async_posix.h +++ b/crypto/async/arch/async_posix.h @@ -54,7 +54,7 @@ #define OPENSSL_ASYNC_ARCH_ASYNC_POSIX_H #include -#if defined(OPENSSL_SYS_UNIX) && defined(OPENSSL_THREADS) +#if (defined(OPENSSL_SYS_UNIX) || defined(OPENSSL_SYS_CYGWIN)) && defined(OPENSSL_THREADS) # include diff --git a/crypto/async/arch/async_win.h b/crypto/async/arch/async_win.h index b247f59..31f2482 100644 --- a/crypto/async/arch/async_win.h +++ b/crypto/async/arch/async_win.h @@ -55,7 +55,7 @@ * This is the same detection used in cryptlib to set up the thread local * storage that we depend on, so just copy that */ -#if defined(_WIN32) || defined(__CYGWIN__) +#if defined(_WIN32) #include # define ASYNC_WIN # define ASYNC_ARCH diff --git a/include/openssl/async.h b/include/openssl/async.h index de5ef89..d130a36 100644 --- a/include/openssl
Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published
On Thu, Jan 14, 2016 at 03:35:48PM -0500, Viktor Dukhovni wrote: > Thanks for the prompt error report. If you're willing to share your > test chains, and if it is likely to be not too difficult to include > them with the OpenSSL bundled tests, that might be worth looking into. All the test case I use with hostapd/wpa_supplicant hwsim testing are available in the public git://w1.fi/hostap.git repository under the tests/hwsim directory. Most cases that are of interest to OpenSSL are in these files: http://w1.fi/cgit/hostap/plain/tests/hwsim/test_ap_eap.py http://w1.fi/cgit/hostap/plain/tests/hwsim/test_suite_b.py The certificates used in the tests are in this directory: http://w1.fi/cgit/hostap/tree/tests/hwsim/auth_serv For the time being, all the certificates are from the repository, but some of the OCSP responses used in the test cases are created dynamically when executing the test cases. > We definitely need more chain verification test cases, and yours failed > with the unpatched "openssl verify" when used just right: > > $ openssl verify -trusted ca-incorrect.pem -untrusted ca.pem \ > -purpose sslserver server.pem > > The untrusted ca.pem came up trusted incorrectly. The new DANE-specific > chain tests are much more comprehensive at this time than the non-DANE > ones, we'll need to address that before the final release. Ah, I didn't even think of the possibility of the CA certificate sent by the server getting trusted, so I just ran openssl verify with -CAfile.. I have been mainly focusing on different areas for EAP-TLS/TTLS/PEAP/FAST testing, so the number of chain verification tests that depend on internal OpenSSL functionality is still quite small. I'm hoping to increase this, but it will take quite a bit of time and effort to get that done.. I have higher priority on covering the additional constraints for validation based on the steps that wpa_supplicant can do on top of the OpenSSL chain validation (e.g., checking specific domain suffix and other subject/altsubject information and OCSP) and handling different formats of certificate and private key encoding. Based on a quick search through the test cases, these are the trivial combinations that can be executed with openssl verify. This assumes the commands are run within that tests/hwsim/auth_server directory. OPENSSL=openssl echo "Should succeed" $OPENSSL verify -trusted ca.pem -purpose sslserver server.pem $OPENSSL verify -trusted ca.pem -untrusted ca.pem -purpose sslserver server.pem $OPENSSL verify -trusted ca.pem -purpose sslclient user.pem $OPENSSL verify -trusted iCA-user/ca-and-root.pem -untrusted iCA-server/cacert.pem -purpose sslserver iCA-server/server.pem $OPENSSL verify -trusted iCA-server/ca-and-root.pem -untrusted iCA-user/cacert.pem -purpose sslclient iCA-user/user.pem $OPENSSL verify -trusted ca.pem -purpose sslserver server-eku-client-server.pem $OPENSSL verify -trusted ca.pem -purpose sslserver server-long-duration.pem $OPENSSL verify -trusted sha512-ca.pem -purpose sslserver sha512-server.pem $OPENSSL verify -trusted sha512-ca.pem -purpose sslserver sha384-server.pem $OPENSSL verify -trusted sha512-ca.pem -purpose sslclient sha512-user.pem $OPENSSL verify -trusted sha512-ca.pem -purpose sslclient sha384-user.pem $OPENSSL verify -trusted ec-ca.pem -purpose sslserver ec-server.pem $OPENSSL verify -trusted ec-ca.pem -purpose sslclient ec-user.pem $OPENSSL verify -trusted ec2-ca.pem -purpose sslserver ec2-server.pem $OPENSSL verify -trusted ec2-ca.pem -purpose sslclient ec2-user.pem echo "Should fail" $OPENSSL verify -trusted ca-incorrect.pem -untrusted ca.pem -purpose sslserver server.pem $OPENSSL verify -trusted ca-incorrect.pem -purpose sslserver server.pem $OPENSSL verify -trusted ca-incorrect.pem -untrusted ca.pem -purpose sslclient user.pem $OPENSSL verify -trusted ca-incorrect.pem -purpose sslclient user.pem $OPENSSL verify -trusted ca.pem -purpose sslserver server-eku-client.pem $OPENSSL verify -trusted ca.pem -purpose sslserver server-expired.pem -- Jouni MalinenPGP id EFC895FA ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published
> On Jan 14, 2016, at 3:21 PM, Jouni Malinen wrote: > > On Thu, Jan 14, 2016 at 03:15:12PM -0500, Viktor Dukhovni wrote: >> >>> On Jan 14, 2016, at 2:38 PM, Viktor Dukhovni >>> wrote: >>> >>> Thanks. That's enough info. Patch below. >> >> Or pull the master branch from github. > > Thanks! I confirmed that both the patch on top of pre-rel 2 (+ CRL fix) > and the current master branch snapshot fixed all the test cases that I > saw failing previously. Thanks for the prompt error report. If you're willing to share your test chains, and if it is likely to be not too difficult to include them with the OpenSSL bundled tests, that might be worth looking into. We definitely need more chain verification test cases, and yours failed with the unpatched "openssl verify" when used just right: $ openssl verify -trusted ca-incorrect.pem -untrusted ca.pem \ -purpose sslserver server.pem The untrusted ca.pem came up trusted incorrectly. The new DANE-specific chain tests are much more comprehensive at this time than the non-DANE ones, we'll need to address that before the final release. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published
On Thu, Jan 14, 2016 at 03:15:12PM -0500, Viktor Dukhovni wrote: > > > On Jan 14, 2016, at 2:38 PM, Viktor Dukhovni > > wrote: > > > > Thanks. That's enough info. Patch below. > > Or pull the master branch from github. Thanks! I confirmed that both the patch on top of pre-rel 2 (+ CRL fix) and the current master branch snapshot fixed all the test cases that I saw failing previously. -- Jouni MalinenPGP id EFC895FA ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published
> On Jan 14, 2016, at 2:38 PM, Viktor Dukhovni > wrote: > > Thanks. That's enough info. Patch below. Or pull the master branch from github. -- Viktor. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published
On Thu, Jan 14, 2016 at 08:35:26PM +0200, Jouni Malinen wrote: > Anyway, the incorrect > CA and the only certificate that was configured as trusted on the client > was this one: > http://w1.fi/cgit/hostap/plain/tests/hwsim/auth_serv/ca-incorrect.pem > while the server used this certificate: > > http://w1.fi/cgit/hostap/plain/tests/hwsim/auth_serv/server.pem > and this issuer: > http://w1.fi/cgit/hostap/plain/tests/hwsim/auth_serv/ca.pem Thanks. That's enough info. Patch below. diff --git a/crypto/x509/x509_vfy.c b/crypto/x509/x509_vfy.c index c395acc..24ca9e3 100644 --- a/crypto/x509/x509_vfy.c +++ b/crypto/x509/x509_vfy.c @@ -580,7 +580,11 @@ static int check_trust(X509_STORE_CTX *ctx, int num_untrusted) int num = sk_X509_num(ctx->chain); int trust; -if (DANETLS_HAS_TA(dane) && num_untrusted > 0) { +/* + * Check for a DANE issuer at depth 1 or greater, if it is a DANE-TA(2) + * match, we're done, otherwise we'll merely record the match depth. + */ +if (DANETLS_HAS_TA(dane) && num_untrusted > 0 && num_untrusted < num) { switch (trust = check_dane_issuer(ctx, num_untrusted)) { case X509_TRUST_TRUSTED: case X509_TRUST_REJECTED: @@ -614,12 +618,13 @@ static int check_trust(X509_STORE_CTX *ctx, int num_untrusted) return X509_TRUST_UNTRUSTED; } -if (ctx->param->flags & X509_V_FLAG_PARTIAL_CHAIN) { +if (num_untrusted > num && ctx->param->flags & X509_V_FLAG_PARTIAL_CHAIN) { /* * Last-resort call with no new trusted certificates, check the leaf * for a direct trust store match. */ -x = sk_X509_value(ctx->chain, 0); +i = 0; +x = sk_X509_value(ctx->chain, i); mx = lookup_cert_match(ctx, x); if (!mx) return X509_TRUST_UNTRUSTED; @@ -2894,7 +2899,7 @@ static int build_chain(X509_STORE_CTX *ctx) trust = check_dane_pkeys(ctx); if (trust == X509_TRUST_UNTRUSTED && sk_X509_num(ctx->chain) == ctx->num_untrusted) -trust = check_trust(ctx, 1); +trust = check_trust(ctx, ctx->num_untrusted+1); } switch (trust) { -- Viktor. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published
On Thu, Jan 14, 2016 at 12:08:06PM -0500, Viktor Dukhovni wrote: > Well I rewrote the certificate chain verification code, perhaps some more > polish is needed. Please, if possible, send the chain being verified > (the leaf and and "untrusted" certs), plus the trusted roots (clearly > marked as such), and I'll look into it. I'm not sure this is going to be helpful since this is a very basic case and I cannot reproduce this with openssl verify. Anyway, the incorrect CA and the only certificate that was configured as trusted on the client was this one: http://w1.fi/cgit/hostap/plain/tests/hwsim/auth_serv/ca-incorrect.pem while the server used this certificate: http://w1.fi/cgit/hostap/plain/tests/hwsim/auth_serv/server.pem and this issuer: http://w1.fi/cgit/hostap/plain/tests/hwsim/auth_serv/ca.pem Not even the issue subject name match here.. Still, I'm getting this with pre-rel 2 on the client: SSL: SSL_connect:SSLv3/TLS read server hello OpenSSL: RX ver=0x303 content_type=22 (handshake/certificate) TLS: tls_verify_cb - preverify_ok=1 err=0 (ok) ca_cert_verify=1 depth=1 buf='/C=FI/O=w1.fi/CN=Root CA' TLS: tls_verify_cb - preverify_ok=1 err=0 (ok) ca_cert_verify=1 depth=0 buf='/C=FI/O=w1.fi/CN=server.w1.fi' And TLS handshake completes successfully. With OpenSSL 1.0.2d, this fails (as expected): SSL: SSL_connect:SSLv3 read server hello A OpenSSL: RX ver=0x303 content_type=22 (handshake/certificate) TLS: Certificate verification failed, error 19 (self signed certificate in certificate chain) depth 1 for '/C=FI/O=w1.fi/CN=Root CA' So this has to be something with how the chain verification code gets configured.. I'll see if I can find the commit that changed the behavior to make it a bit more easier to figure out what exactly may have happened. -- Jouni MalinenPGP id EFC895FA ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published
On Thu, Jan 14, 2016 at 06:47:49PM +0200, Jouni Malinen wrote: > Many of the negative test cases that verify that server certificate > chain validation works by using mismatching trust roots (i.e., server > certificate is not issued by any of the trusted CA certificates) are > failing. You should be able to test chains with "openssl verify(1)". This runs X509_verify_cert() in pretty much the same manner as with a live TLS connection. # Trusted root set and matching purpose: $ openssl verify \ -trusted rootcert.pem \ -untrusted rootcert.pem -untrusted cacert.pem \ -purpose sslserver eecert.pem; echo $? eecert.pem; excho $? eecert.pem: OK 0 # No trusted root $ openssl verify \ -untrusted rootcert.pem -untrusted cacert.pem \ -purpose sslserver eecert.pem; echo $? CN = Issuer CA error 20 at 1 depth lookup: unable to get local issuer certificate error eecert.pem: verification failed 2 # Wrong purpose $ openssl verify \ -trusted rootcert.pem \ -untrusted rootcert.pem -untrusted cacert.pem \ -purpose sslclient eecert.pem; echo $? CN = example.com error 26 at 0 depth lookup: unsupported certificate purpose error eecert.pem: verification failed 2 Instead of "-trusted" you can use "-CAfile" and/or "-CApath" as usual, but "-trusted" gives more precise control, because then *only* the certs in that file are trusted, otherwise the default verify locations may also be in play. It would be great if you could reproduce any failures outside of EAP, just by checking the chain. > OpenSSL allows the TLS handshake to be completed with the > verify callback (set with SSL_set_verify(ssl, SSL_VERIFY_PEER, func)) > reports preverify_ok=1 and err=0 for the root CA and the server > certificate even though the client side has not configured that root CA > as trusted. Please send the chain, and the trust store certificates. Are you using CAfile/CApath/both? > Is there really an intentional change in OpenSSL > requiring something additional to be done to configure peer certificate > validation to result in failure with the latest pre release? No, but the implementation has changed considerably, for the better in terms of code maintainability, but new issues are a possibility. -- Viktor. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published
On Thu, Jan 14, 2016 at 05:39:39PM +, Viktor Dukhovni wrote: > See patch just posted, and also pushed to github. This will likely fix > the CRL issue. > > commit 311f27852a18fb9c10f0c1283b639f12eea06de2 > Author: Viktor Dukhovni > Date: Thu Jan 14 12:23:35 2016 -0500 > > Always initialize X509_STORE_CTX get_crl pointer Thanks! This applied on top of pre-rel 2 does indeed resolve the CRL issue I saw. -- Jouni MalinenPGP id EFC895FA ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published
On Thu, Jan 14, 2016 at 06:47:49PM +0200, Jouni Malinen wrote: > EAP server side is crashing (segmentation fault) in a pretty strange way > when using CRL validation as part of the TLS handshake. This is my test > case ap_wpa2_eap_tls_check_crl which shows following in valgrind for the > hostapd process that went through the TLS server side exchange. It looks > like a crash in OpenSSL check_revocation(), but I guess I'll need to > enable more debug symbols somewhere to get bit more helpful output. This > same test case worked fine with pre release 1. The test case ends up > using a code path that executes cs = SSL_CTX_get_cert_store() and > X509_STORE_set_flags(cs, X509_V_FLAG_CRL_CHECK). > > ==627== Conditional jump or move depends on uninitialised value(s) > ==627==at 0x6174D5: check_revocation (in > /home/jm/Git/hostap/hostapd/hostapd) > ==627==by 0x618280: verify_chain (in /home/jm/Git/hostap/hostapd/hostapd) > ==627==by 0x55782F: ssl_add_cert_chain (in > /home/jm/Git/hostap/hostapd/hostapd) > ==627==by 0x575157: ssl3_output_cert_chain (in > /home/jm/Git/hostap/hostapd/hostapd) > ==627==by 0x569D3C: ossl_statem_server_construct_message (in > /home/jm/Git/hostap/hostapd/hostapd) > ==627==by 0x56461D: state_machine (in /home/jm/Git/hostap/hostapd/hostapd) > ==627==by 0x5513BB: SSL_accept (in /home/jm/Git/hostap/hostapd/hostapd) > ==627==by 0x50AF9C: openssl_handshake (tls_openssl.c:3180) > ==627==by 0x50AF9C: openssl_connection_handshake (tls_openssl.c:3273) > ==627==by 0x508A21: eap_server_tls_phase1 (eap_server_tls_common.c:316) > ==627==by 0x4C41B1: eap_tls_process_msg (eap_server_tls.c:247) > ==627==by 0x508C6B: eap_server_tls_process (eap_server_tls_common.c:468) > ==627==by 0x4C40C3: eap_tls_process (eap_server_tls.c:259) > ==627== > ==627== Use of uninitialised value of size 8 > ==627==at 0x61742D: check_revocation (in > /home/jm/Git/hostap/hostapd/hostapd) > ==627==by 0x662C55F: ??? > ==627==by 0xE: ??? > ==627==by 0x654653F: ??? See patch just posted, and also pushed to github. This will likely fix the CRL issue. commit 311f27852a18fb9c10f0c1283b639f12eea06de2 Author: Viktor Dukhovni Date: Thu Jan 14 12:23:35 2016 -0500 Always initialize X509_STORE_CTX get_crl pointer -- Viktor. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published
> On Jan 14, 2016, at 11:47 AM, Jouni Malinen wrote: > > Many of the negative test cases that verify that server certificate > chain validation works by using mismatching trust roots (i.e., server > certificate is not issued by any of the trusted CA certificates) are > failing. OpenSSL allows the TLS handshake to be completed with the > verify callback (set with SSL_set_verify(ssl, SSL_VERIFY_PEER, func)) > reports preverify_ok=1 and err=0 for the root CA and the server > certificate even though the client side has not configured that root CA > as trusted. This worked fine with pre release 1, so I'm quite concerned > about the change in behavior when nothing in the application side > changed and an untrusted server certificate suddenly became trusted by > OpenSSL update.. Is there really an intentional change in OpenSSL > requiring something additional to be done to configure peer certificate > validation to result in failure with the latest pre release? > > EAP server side is crashing (segmentation fault) in a pretty strange way > when using CRL validation as part of the TLS handshake. This is my test > case ap_wpa2_eap_tls_check_crl which shows following in valgrind for the > hostapd process that went through the TLS server side exchange. It looks > like a crash in OpenSSL check_revocation(), but I guess I'll need to > enable more debug symbols somewhere to get bit more helpful output. This > same test case worked fine with pre release 1. The test case ends up > using a code path that executes cs = SSL_CTX_get_cert_store() and > X509_STORE_set_flags(cs, X509_V_FLAG_CRL_CHECK). Well I rewrote the certificate chain verification code, perhaps some more polish is needed. Please, if possible, send the chain being verified (the leaf and and "untrusted" certs), plus the trusted roots (clearly marked as such), and I'll look into it. -- -- Viktor. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published
On Thu, Jan 14, 2016 at 03:44:18PM +0100, Richard Levitte wrote: >OpenSSL version 1.1.0 pre release 2 (alpha) >OpenSSL 1.1.0 is currently in alpha. OpenSSL 1.1.0 pre release 2 has now >been made available. For details of changes and known issues see the >release notes at: > > http://www.openssl.org/news/openssl-1.1.0-notes.html I needed to do following updates to hostapd/wpa_supplicant to build against this (to a snapshot that worked with 1.1.0 pre release 1): - use EVP_CIPHER_CTX_new() and dynamic allocation instead of having EVP_CIPHER_CTX ctx on stack and using EVP_CIPHER_CTX_init(&ctx) (I guess this was an expected change, but for some reason, pre release 1 did not force this) - replace "SSL_CIPHER **cipher" with "const SSL_CIPHER **cipher" in the SSL_set_session_secret_cb() callback function (I did not notice any comment about this in the changelog; was there supposed to be something? This broke API compatibility.. The change itself is fine and I already had to do some with BoringSSL, but it would be nice to get this type of incompatible API changes noted clearly) As far as functionality is concerned, I did see number of new issues when running through my automated test setup and especially the EAP test cases. I haven't yet looked at what exactly caused these, but these did not look exactly good, so that's why a quick note here first to see if anything sounds familiar and someone would already know why the behavior changed between pre release 1 and 2. Many of the negative test cases that verify that server certificate chain validation works by using mismatching trust roots (i.e., server certificate is not issued by any of the trusted CA certificates) are failing. OpenSSL allows the TLS handshake to be completed with the verify callback (set with SSL_set_verify(ssl, SSL_VERIFY_PEER, func)) reports preverify_ok=1 and err=0 for the root CA and the server certificate even though the client side has not configured that root CA as trusted. This worked fine with pre release 1, so I'm quite concerned about the change in behavior when nothing in the application side changed and an untrusted server certificate suddenly became trusted by OpenSSL update.. Is there really an intentional change in OpenSSL requiring something additional to be done to configure peer certificate validation to result in failure with the latest pre release? EAP server side is crashing (segmentation fault) in a pretty strange way when using CRL validation as part of the TLS handshake. This is my test case ap_wpa2_eap_tls_check_crl which shows following in valgrind for the hostapd process that went through the TLS server side exchange. It looks like a crash in OpenSSL check_revocation(), but I guess I'll need to enable more debug symbols somewhere to get bit more helpful output. This same test case worked fine with pre release 1. The test case ends up using a code path that executes cs = SSL_CTX_get_cert_store() and X509_STORE_set_flags(cs, X509_V_FLAG_CRL_CHECK). ==627== Conditional jump or move depends on uninitialised value(s) ==627==at 0x6174D5: check_revocation (in /home/jm/Git/hostap/hostapd/hostapd) ==627==by 0x618280: verify_chain (in /home/jm/Git/hostap/hostapd/hostapd) ==627==by 0x55782F: ssl_add_cert_chain (in /home/jm/Git/hostap/hostapd/hostapd) ==627==by 0x575157: ssl3_output_cert_chain (in /home/jm/Git/hostap/hostapd/hostapd) ==627==by 0x569D3C: ossl_statem_server_construct_message (in /home/jm/Git/hostap/hostapd/hostapd) ==627==by 0x56461D: state_machine (in /home/jm/Git/hostap/hostapd/hostapd) ==627==by 0x5513BB: SSL_accept (in /home/jm/Git/hostap/hostapd/hostapd) ==627==by 0x50AF9C: openssl_handshake (tls_openssl.c:3180) ==627==by 0x50AF9C: openssl_connection_handshake (tls_openssl.c:3273) ==627==by 0x508A21: eap_server_tls_phase1 (eap_server_tls_common.c:316) ==627==by 0x4C41B1: eap_tls_process_msg (eap_server_tls.c:247) ==627==by 0x508C6B: eap_server_tls_process (eap_server_tls_common.c:468) ==627==by 0x4C40C3: eap_tls_process (eap_server_tls.c:259) ==627== ==627== Use of uninitialised value of size 8 ==627==at 0x61742D: check_revocation (in /home/jm/Git/hostap/hostapd/hostapd) ==627==by 0x662C55F: ??? ==627==by 0xE: ??? ==627==by 0x654653F: ??? ==627== vex amd64->IR: unhandled instruction bytes: 0x6E 0x6F 0x6E 0x65 0x0 0x52 0x53 0x41 vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.n=0x0 ESC=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==627== Invalid read of size 4 ==627==at 0x75FFEA: ??? (in /home/jm/Git/hostap/hostapd/hostapd) ==627==by 0xFFF00038F: ??? ==627==by 0x20441A6D1E48C1FF: ??? ==627==by 0xFFF00038F: ??? ==627==by 0xFFF00038F: ??? ==627==by 0x1: ??? ==627==by 0x654653F: ??? ==627== Address 0x1003029407 is not stack'd, malloc'd or (recently) free'd -- Jouni Malinen
[openssl-dev] OpenSSL version 1.1.0 pre release 2 published
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL version 1.1.0 pre release 2 (alpha) === OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ OpenSSL 1.1.0 is currently in alpha. OpenSSL 1.1.0 pre release 2 has now been made available. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-1.1.0-notes.html Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. The alpha release is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.0-pre2.tar.gz Size: 4948288 SHA1 checksum: d7a26cce5d4cc2b491996489d5385e0640bb92ef SHA256 checksum: 09e7470462e263ae853bc7a8fdb07fa439651c5f70aab4573c1a87ee2537a7ac The checksums were calculated using the following commands: openssl sha1 openssl-1.1.0-pre2.tar.gz openssl sha256 openssl-1.1.0-pre2.tar.gz Please download and check this alpha release as soon as possible. Bug reports should go to r...@openssl.org. Please check the release notes and mailing lists to avoid duplicate reports of known issues. Yours, The OpenSSL Project Team. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJWl7A8AAoJENXp5D99+e6MB2kQAJU5fn49JZ7YPx1VByhn873B UptNfbXozRn7ceLoDxMuZlwhbZEV/2BVc37bocagTsuU2gu2RedCE4WS/Kdk9j7q 9IK7pgInLgK2gTMXuPzKFz2qxAxtSi5QJC7BRqq88gR03dl0qXuJ+eCW2Y+zKiDt 2WgAFKrbTW9reDZs2a6WLJEY2lQdsc4eKMkVfCPZTPNpwMUsXipv7egJYC5XchBG ZM1nq8KbmwtVn1EIjH3pUxKbRIPhfza3OCwKQqWsx1XHga7fA4Cz/u+NiswcubGv fC+Aei30Ygi3oR8QG2tdEYMWQaa54hvn06/1bh6tVi8GcXGhFXj+gUTr6dw4TlGx wB/H3bII9slNkGC3w5kcVbSdCmH7ThTDKqeHbqPTVooOJMXMKj5EBXGKkkJ/O8Xg P3cDhqw48LgTW6BtM0ItZE7yHrApPaJr4MWTBQj4uqUIQz0SSUnxCE7xpSJS5UPE A/oi0p+Mzr3bJG+39lzDEqhFWxR/WP5cU9mWo68b002qwSzcOPm8RpMfqGfNJDyg P5OVJnykeI0JU8rR85fTdJFvcGgESOfv1HnSa9sGIMLhEA6Y4GwDhM804AV9xQ3+ trLd1Y5WYTcgc8yx181psw541N1Hsxl15Jm2sPcMMYdiK5YVbi1y+K3NGfnmKnYT /79DbTCo0r02h0k1X8JI =It+h -END PGP SIGNATURE- ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev