Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published

2016-01-17 Thread Richard Levitte 
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

2016-01-17 Thread Corinna Vinschen 
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

2016-01-17 Thread Corinna Vinschen 
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

2016-01-17 Thread Richard Levitte 
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

Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published

2016-01-17 Thread Corinna Vinschen 
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

2016-01-17 Thread Corinna Vinschen 
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

2016-01-17 Thread Richard Levitte 
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

2016-01-17 Thread Richard Levitte 
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

2016-01-16 Thread Corinna Vinschen 
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

Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published

2016-01-16 Thread Kurt Roeckx 
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

2016-01-16 Thread Corinna Vinschen 
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

2016-01-16 Thread Corinna Vinschen 
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

2016-01-16 Thread Richard Levitte 
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

2016-01-15 Thread Jouni Malinen 
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

2016-01-14 Thread Jouni Malinen 
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()
  (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

Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published

2016-01-14 Thread Viktor Dukhovni 

> 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

2016-01-14 Thread Viktor Dukhovni 

> 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

2016-01-14 Thread Jouni Malinen 
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

2016-01-14 Thread Viktor Dukhovni 

> 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

2016-01-14 Thread Jouni Malinen 
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

2016-01-14 Thread Viktor Dukhovni 
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

2016-01-14 Thread Jouni Malinen 
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

2016-01-14 Thread Viktor Dukhovni 
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