Re: [openssl-dev] Build issue

[Matthew Stickney]

Aha, victory! Turns out this was a line-ending problem: after removing
the mingw perl, the mkdef.pl debug output had (among many, many other
things), the following when I went looking for MD2 references:

> DEBUG: include/openssl/md2.h: found tag OPENSSL_NO_MD2^M = -1

I checked, and sure enough the md2 header had windows line endings.
core.autocrlf was false, and core.eol was lf, so I'm not sure how only
some headers had the wrong line endings, but an "rm -rf * && git
checkout ." produced a working build.

Thanks for the time and assistance, everybody.

-Matt Stickney

On Wed, Aug 2, 2017 at 4:07 AM, Matt Caswell <m...@openssl.org> wrote:
>
>
> On 02/08/17 03:19, Matthew Stickney wrote:
>> Ok, progress (sort of)! It turns out I was indeed using the wrong
>> version of perl -- I was using the perl that was installed as part of
>> the msys2 base-devel group, not the mingw-w64--perl package,
>> which is a whole separate thing.
>
>
> Errr no. You were right the first time - you should be using the msys2
> perl. This is my perl --version output:
>
> This is perl 5, version 22, subversion 1 (v5.22.1) built for
> x86_64-msys-thread-multi
>
> Do NOT use the mingw perl (I think Richard misspoke when he said this
> before - the "matching perl" requirement means that using msys2 shell
> requires msys2 perl).
>
> Just to check - you are using the msys2 shell right?
>
> Matt
>
>
>>
>> However, having installed the mingw-w64 version of perl, the configure
>> script is failing because it thinks this is a unix-like platform, but
>> perl is producing windows-style paths:
>>
>>> This perl implementation doesn't produce Unix like paths (with forward slash
>>> directory separators).  Please use an implementation that matches your
>>> building platform.
>>
>>> This Perl version: 5.22.0 for MSWin32-x64-multi-thread
>>
>> I can't follow the configure script well enough to tell where it's
>> detecting the relevant bits from -- the build_scheme key seems to be
>> responsible for triggering the unix-checker.pm script that fails, but
>> grep only turns up two references to it: the readme, and the configure
>> script. Is this an issue with msys2+mingw-w64 environments?
>>
>> -Matt Stickney
>>
>> On Tue, Aug 1, 2017 at 8:54 AM, Sergio NNX <sfhac...@hotmail.com> wrote:
>>>> Ok, I have still not been able to reproduce this.
>>>
>>> Neither have I!
>>>
>>>
>>> I've just downloaded OpenSSL 1.1.0f and built it from source.
>>>
>>> This is my configuration:
>>>
>>>
>>> Microsoft Windows [Version 10.0.15063]
>>>
>>> This is perl 5, version 24, subversion 1 (v5.24.1)
>>>
>>> GCC v6.3.0 (64-bit)
>>>
>>>
>>> ./config mingw64  
>>>
>>> make depend
>>>
>>> make all
>>>
>>>
>>> After a while, I get the executable and libraries.
>>>
>>>
>>> OpenSSL 1.1.0f  25 May 2017
>>> built on: reproducible build, date unspecified
>>> platform: mingw64
>>>
>>>
>>> perl util/mkdef.pl 32 crypto debug 2> mkdef-debug.txt > /dev/null
>>> [It generates a huge file (125MB)]
>>>
>>> Cheers.
>>>
>>> Ser/
>>>
>>>
>>> P.S.: Try to use a more specific subject next time!
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Build issue

[Matthew Stickney]

Ok, progress (sort of)! It turns out I was indeed using the wrong
version of perl -- I was using the perl that was installed as part of
the msys2 base-devel group, not the mingw-w64--perl package,
which is a whole separate thing.

However, having installed the mingw-w64 version of perl, the configure
script is failing because it thinks this is a unix-like platform, but
perl is producing windows-style paths:

> This perl implementation doesn't produce Unix like paths (with forward slash
> directory separators).  Please use an implementation that matches your
> building platform.

> This Perl version: 5.22.0 for MSWin32-x64-multi-thread

I can't follow the configure script well enough to tell where it's
detecting the relevant bits from -- the build_scheme key seems to be
responsible for triggering the unix-checker.pm script that fails, but
grep only turns up two references to it: the readme, and the configure
script. Is this an issue with msys2+mingw-w64 environments?

-Matt Stickney

On Tue, Aug 1, 2017 at 8:54 AM, Sergio NNX  wrote:
>> Ok, I have still not been able to reproduce this.
>
> Neither have I!
>
>
> I've just downloaded OpenSSL 1.1.0f and built it from source.
>
> This is my configuration:
>
>
> Microsoft Windows [Version 10.0.15063]
>
> This is perl 5, version 24, subversion 1 (v5.24.1)
>
> GCC v6.3.0 (64-bit)
>
>
> ./config mingw64  
>
> make depend
>
> make all
>
>
> After a while, I get the executable and libraries.
>
>
> OpenSSL 1.1.0f  25 May 2017
> built on: reproducible build, date unspecified
> platform: mingw64
>
>
> perl util/mkdef.pl 32 crypto debug 2> mkdef-debug.txt > /dev/null
> [It generates a huge file (125MB)]
>
> Cheers.
>
> Ser/
>
>
> P.S.: Try to use a more specific subject next time!
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Build issue

[Matthew Stickney]

I swear I sent my last reply to the list; either my mail client is
messing with me, or I'm going crazy. There's no reason for this to be
off-list, and that wasn't my intention in the first place.

Anyhow: util/libcrypto.num doesn't seem to have anything unusual in it
associated with '_num', so that's fine, but then neither does
crypto.def, so it seems like it's not an issue with util/mkdef.pl. I
mean, obviously the error is /somewhere/

-Matt Stickney

On Mon, Jul 31, 2017 at 10:22 AM, Matthew Stickney <mtstick...@gmail.com> wrote:
> Thanks for the suggestion, and my apologies: I didn't intend to take
> this off-list. I'll check libcrypto.num when I get back on the machine
> tonight. If it helps, I am building this with 64-bit mingw, but I
> don't see how that would have an effect (there are build warnings
> earlier in the process, but from what I've seen they look harmless).
>
> -Matt Stickney
>
> On Mon, Jul 31, 2017 at 10:17 AM, Richard Levitte <levi...@openssl.org> wrote:
>> util/mkdef.pl picks up all the data from configdata.pm, and regarding
>> options, it looks at $config{options}, which includes everything
>> that's disabled by default.
>>
>> This all is an issue that I'm currently labeling *weird*, 'cause it
>> makes no sense at all.  Most of all, this line really has me gawking,
>> scratching my head and generally looking silly:
>>
>> Error: _num does not have a number assigned
>>
>> Basically, it looks like *something* is getting ba-a-a-a-dly parsed,
>> and I have no idea if that's in util/libcrypto.num (could you try and
>> grep for '_num' and possibly '^_num' to see if you can find something
>> weird?) or if it's a serious corner case cock up in util/mkdef.pl.
>>
>> Worst thing is, I haven't been able to reproduce...  I am going to try
>> again just now, with the hope that 32-bit mingw doesn't make a
>> difference...
>>
>> Cheers,
>> Richard
>>
>> In message <a1a9f917-a155-f7c4-f71e-4f4c3de4d...@akamai.com> on Mon, 31 Jul 
>> 2017 09:02:15 -0500, Benjamin Kaduk <bka...@akamai.com> said:
>>
>> bkaduk> Whoops, I missed that this was unicast when skimming mail over the 
>> weekend.
>> bkaduk> Looping back in Richard, at least, though if you don't mind, putting 
>> the list back would be best.
>> bkaduk>
>> bkaduk> Richard, my (extremely) quick skim of mkdef.pl is that it is only 
>> picking up explicitly set options
>> bkaduk> and not things disabled by default; does that seem plausible?
>> bkaduk>
>> bkaduk> -Ben
>> bkaduk>
>> bkaduk> On 07/28/2017 10:38 PM, Matthew Stickney wrote:
>> bkaduk>
>> bkaduk>  [1] has the contents of my crypto.def file, although I don't see
>> bkaduk> anything especially odd in there (not that I would know, really).
>> bkaduk>
>> bkaduk> I removed the offending symbols from crypto.def, and that caused the
>> bkaduk> previously-failing command to succeed. I added some print statements
>> bkaduk> to mkdef.pl and configured with "./configure mingw64 no-rc5 no-md2",
>> bkaduk> and mkdef.pl appeared to be adding them to its list of disabled
>> bkaduk> algorithms, but the MD2 and RC5 symbols are still in crypto.def. I'm
>> bkaduk> no perl hacker, but I'll play around with it a bit.
>> bkaduk>
>> bkaduk> If I hand-remove the undefined symbols, building libssl fails with
>> bkaduk> undefined references if I run make again, and if I run make again
>> bkaduk> after that, building engines/e_capi.o fails with similar errors
>> bkaduk> (probably related, but seems strange that libssl is ignored after the
>> bkaduk> first failure). Some logs below.
>> bkaduk>
>> bkaduk> -Matt Stickney
>> bkaduk>
>> bkaduk> [1] 
>> https://gist.github.com/mtstickney/eac60bb98cafc9b978407cbb0a466cdc
>> bkaduk> [2] 
>> http://openssl.6102.n7.nabble.com/Issues-with-latest-snapshot-td36148.html
>> bkaduk>
>> bkaduk> perl ./util/mkrc.pl libssl-1_1-x64.dll | windres --target=pe-x86-64 
>> -o rc.o
>> bkaduk> LD_LIBRARY_PATH=.: gcc -DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS 
>> -DOPENSSL_NO_STATI
>> bkaduk> C_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT 
>> -DOPENSSL_BN_AS
>> bkaduk> M_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM 
>> -DRC4_ASM -DM
>> bkaduk> D5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM 
>> -DECP_NISTZ256_ASM -DPADLOC
>> bkaduk> K_ASM -DPOLY1305_ASM -DOPENSSLDIR="/usr/local/ssl" 
>> -DENGINESDIR="/usr/local/lib/
>> b

Re: [openssl-dev] Build issue

[Matthew Stickney]

With a make distclean, ./config, make depend (didn't appear to do
anything), and a make, I'm getting the essentially the same thing:

Error: _num does not have a number assigned
/usr/bin/perl ./util/mkrc.pl libcrypto-1_1-x64.dll | windres --target=pe-x86-64
-o rc.o
LD_LIBRARY_PATH=: gcc -DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC
_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM
_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD
5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK
_ASM -DPOLY1305_ASM -DOPENSSLDIR="/usr/local/ssl" -DENGINESDIR="/usr/local/lib/e
ngines-1_1" -DL_ENDIAN -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -m64 -Wall -O3
 -D_MT -D_WINDLL -static-libgcc -shared -Wl,-Bsymbolic -Wl,--out-implib,libcrypt
o.dll.a crypto.def rc.o -o libcrypto-1_1-x64.dll -Wl,--whole-archive libcrypto.a
 -Wl,--no-whole-archive -lws2_32 -lgdi32 -lcrypt32
Cannot export MD2: symbol not defined
Cannot export MD2_Final: symbol not defined
Cannot export MD2_Init: symbol not defined
Cannot export MD2_Update: symbol not defined
Cannot export MD2_options: symbol not defined
Cannot export RC5_32_cbc_encrypt: symbol not defined
Cannot export RC5_32_cfb64_encrypt: symbol not defined
Cannot export RC5_32_decrypt: symbol not defined
Cannot export RC5_32_ecb_encrypt: symbol not defined
Cannot export RC5_32_encrypt: symbol not defined
Cannot export RC5_32_ofb64_encrypt: symbol not defined
Cannot export RC5_32_set_key: symbol not defined
collect2.exe: error: ld returned 1 exit status

On Thu, Jul 27, 2017 at 11:54 PM, Blumenthal, Uri - 0553 - MITLL
<u...@ll.mit.edu> wrote:
> Instead of "make clean" try "make distclean", then reconfigure and rebuild 
> (don't forget "make depend").
>
> Regards,
> Uri
>
> Sent from my iPhone
>
>> On Jul 27, 2017, at 23:24, Matthew Stickney <mtstick...@gmail.com> wrote:
>>
>>> On Thu, Jul 27, 2017 at 3:29 PM, Richard Levitte <levi...@openssl.org> 
>>> wrote:
>>> Have you tried a 'make clean' and then rebuild?
>>
>> Yep, and building from the 1.1.0 stable branch (failed with different
>> errors), and from a new master.
>>
>>> On Thu, Jul 27, 2017 at 3:24 PM, Benjamin Kaduk <bka...@akamai.com> wrote:
>>> Can you paste the actual linker invocation that is failing?
>>
>> I can certainly try. 'make 2>&1 1>build.log' doesn't seem to work
>> quite correctly under MSYS2, so I have a build log, and errors,
>> separately. This looks like the relevant part of the build log:
>> make -f ./Makefile.shared -e \
>>ECHO=echo \
>>PLATFORM=mingw64 \
>>PERL="/usr/bin/perl" SRCDIR='.' DSTDIR="." \
>>INSTALLTOP='/usr/local' LIBDIR='lib' \
>>LIBDEPS=' '""' -lws2_32 -lgdi32 -lcrypt32 ' \
>>LIBNAME=crypto SHLIBVERSION=1.1 \
>>STLIBNAME=libcrypto.a \
>>SHLIBNAME=libcrypto.dll.a SHLIBNAME_FULL=libcrypto-1_1-x64.dll \
>>CC='gcc' CFLAGS='-DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS
>> -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2
>> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
>> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM
>> -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM
>> -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\""
>> -DENGINESDIR="\"/usr/local/lib/engines-1_1\"" -DL_ENDIAN
>> -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -m64 -Wall -O3 -D_MT
>> -D_WINDLL' \
>>LDFLAGS='' SHARED_LDFLAGS='-static-libgcc ' \
>>RC='windres' SHARED_RCFLAGS='--target=pe-x86-64' \
>>link_shlib.mingw-shared
>> make[2]: Entering directory '/c/Users/mts/Desktop/openssl'
>> /usr/bin/perl ./util/mkrc.pl libcrypto-1_1-x64.dll | windres
>> --target=pe-x86-64 -o rc.o
>> LD_LIBRARY_PATH=: gcc -DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS
>> -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2
>> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
>> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM
>> -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM
>> -DPOLY1305_ASM -DOPENSSLDIR="/usr/local/ssl"
>> -DENGINESDIR="/usr/local/lib/engines-1_1" -DL_ENDIAN
>> -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -m64 -Wall -O3 -D_MT
>> -D_WINDLL -static-libgcc -shared -Wl,-Bsymbolic
>> -Wl,--out-implib,libcrypto.dll.a crypto.def rc.o -o
>> libcrypto-1_1-x64.dll -Wl,--whole-archive libcrypto.a
>> -Wl,--no-whole-archive -lws2_32

Re: [openssl-dev] Build issue

[Matthew Stickney]

On Thu, Jul 27, 2017 at 3:29 PM, Richard Levitte  wrote:
> Have you tried a 'make clean' and then rebuild?

Yep, and building from the 1.1.0 stable branch (failed with different
errors), and from a new master.

On Thu, Jul 27, 2017 at 3:24 PM, Benjamin Kaduk  wrote:
> Can you paste the actual linker invocation that is failing?

I can certainly try. 'make 2>&1 1>build.log' doesn't seem to work
quite correctly under MSYS2, so I have a build log, and errors,
separately. This looks like the relevant part of the build log:
make -f ./Makefile.shared -e \
ECHO=echo \
PLATFORM=mingw64 \
PERL="/usr/bin/perl" SRCDIR='.' DSTDIR="." \
INSTALLTOP='/usr/local' LIBDIR='lib' \
LIBDEPS=' '""' -lws2_32 -lgdi32 -lcrypt32 ' \
LIBNAME=crypto SHLIBVERSION=1.1 \
STLIBNAME=libcrypto.a \
SHLIBNAME=libcrypto.dll.a SHLIBNAME_FULL=libcrypto-1_1-x64.dll \
CC='gcc' CFLAGS='-DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS
-DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM
-DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM
-DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\""
-DENGINESDIR="\"/usr/local/lib/engines-1_1\"" -DL_ENDIAN
-DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -m64 -Wall -O3 -D_MT
-D_WINDLL' \
LDFLAGS='' SHARED_LDFLAGS='-static-libgcc ' \
RC='windres' SHARED_RCFLAGS='--target=pe-x86-64' \
link_shlib.mingw-shared
make[2]: Entering directory '/c/Users/mts/Desktop/openssl'
/usr/bin/perl ./util/mkrc.pl libcrypto-1_1-x64.dll | windres
--target=pe-x86-64 -o rc.o
LD_LIBRARY_PATH=: gcc -DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS
-DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM
-DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM
-DPOLY1305_ASM -DOPENSSLDIR="/usr/local/ssl"
-DENGINESDIR="/usr/local/lib/engines-1_1" -DL_ENDIAN
-DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -m64 -Wall -O3 -D_MT
-D_WINDLL -static-libgcc -shared -Wl,-Bsymbolic
-Wl,--out-implib,libcrypto.dll.a crypto.def rc.o -o
libcrypto-1_1-x64.dll -Wl,--whole-archive libcrypto.a
-Wl,--no-whole-archive -lws2_32 -lgdi32 -lcrypt32

The error messages also contain these, which seem interesting:
Error: _num does not have a number assigned
Cannot export MD2: symbol not defined
Cannot export MD2_Final: symbol not defined
Cannot export MD2_Init: symbol not defined
Cannot export MD2_Update: symbol not defined
Cannot export MD2_options: symbol not defined
Cannot export RC5_32_cbc_encrypt: symbol not defined
Cannot export RC5_32_cfb64_encrypt: symbol not defined
Cannot export RC5_32_decrypt: symbol not defined
Cannot export RC5_32_ecb_encrypt: symbol not defined
Cannot export RC5_32_encrypt: symbol not defined
Cannot export RC5_32_ofb64_encrypt: symbol not defined
Cannot export RC5_32_set_key: symbol not defined
collect2.exe: error: ld returned 1 exit status
make[2]: *** [Makefile.shared:260: link_shlib.mingw] Error 1
make[1]: *** [Makefile:658: libcrypto.dll.a] Error 2
make: *** [Makefile:139: all] Error 2

-Matt Stickney
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Build issue

[Matthew Stickney]

Possibly. The original errors and hanging perl process have been
replaced with an enormous number of "undefined reference" errors. For
example:
libssl.a(tls_srp.o):tls_srp.c:(.text+0xc4c): undefined reference to `BN_ucmp'
libssl.a(tls_srp.o):tls_srp.c:(.text+0xd45): undefined reference to
`OPENSSL_cleanse'
libssl.a(tls_srp.o):tls_srp.c:(.text+0xd5f): undefined reference to `SRP_Calc_A'
collect2.exe: error: ld returned 1 exit status

I don't know enough about the build system to know whether the
mkdef.pl change might be responsible for this, or whether this is a
separate issue. To follow up on my previous post, the configure line
was indeed "./config", and this is commit 1843787173. Any other data
that I should collect?

-Matt Stickney
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Build issue

[Matthew Stickney]

I'm away from the machine in question right now, but:

> Also, presumably the perl is the msys perl, but please confirm -- it must be 
> "matching" in order for things to work.

It's definitely the msys perl. I'll check the config line tonight, but
I'm virtually certain that it was "./config" in it's entirety.

> Can you state what OpenSSL version this is

I'll get the commit hash tonight, but this was the tip of master as of
about 9pm EDT last night, so I'd imagine that util/mkdef.pl in master
still has whatever the issue is.

-Matt Stickney

On Tue, Jul 25, 2017 at 2:59 PM, Richard Levitte  wrote:
> In message 
> 

[openssl-dev] Build issue

[Matthew Stickney]

I've been trying to build OpenSSL to work on a new feature, but I've
had problems with the build hanging. I'm building on Windows 10 with
mingw-w64 under msys2; perl is v5.24, and I installed the
Text::Template module from CPAN.

I'm not sure what's relevant, but the hang is definitely in a perl
script of some sort, because there's a perl.exe process uses a
constant chunk of CPU (I suspect this might be a busy-wait, but I
don't know for sure). There are some odd errors before the hang; I've
pasted the log below.

Any ideas? I'm happy to provide more information if that's needed.

-Matt Stickney

make[2]: Entering directory '/c/Users/mts/Desktop/openssl'
File include/openssl/ssl.h: cannot parse: ()()))
#INFO::;
File include/openssl/ssl.h: cannot parse: ()()))
#INFO::DEPRECATEDIN_1_1_0;
File include/openssl/ssl.h: cannot parse: ()
#INFO::;
File include/openssl/ssl.h: cannot parse: ()


enum;
File include/openssl/tls1.h: cannot parse: ()

#INFO::;
File include/openssl/tls1.h: cannot parse: ()

#INFO::;
File include/openssl/asn1.h: cannot parse: ()
#INFO::;
File include/openssl/asn1.h: cannot parse: ()
#INFO::;
File include/openssl/asn1.h: cannot parse: ()
#INFO::;
File include/openssl/asn1.h: cannot parse: ()
#INFO::;
File include/openssl/asn1.h: cannot parse: ()
#INFO::;
File include/openssl/asn1.h: cannot parse: ()

#INFO::;
File include/openssl/asn1.h: cannot parse: ()

#INFO::;
File include/openssl/asn1.h: cannot parse: ()

#INFO::;
File include/openssl/asn1.h: cannot parse: ()

#INFO::;
File include/openssl/bio.h: cannot parse: ()())
#INFO::;
File include/openssl/bio.h: cannot parse: ()())
#INFO::;
File include/openssl/bio.h: cannot parse: ()())
#INFO::;
File include/openssl/bio.h: cannot parse: ()())
#INFO::;
File include/openssl/bio.h: cannot parse: ()())
#INFO::;
File include/openssl/bio.h: cannot parse: ()())
#INFO::;
File include/openssl/bio.h: cannot parse: BIO_CLOSE|BIO_FP_READ,()())
#INFO::;
File include/openssl/bio.h: cannot parse: ()())
#INFO::;
File include/openssl/cms.h: cannot parse: ()
#INFO::;
<-- hang happens here -->
make[2]: *** [Makefile.shared:260: link_shlib.mingw] Interrupt
make[1]: *** [Makefile:655: libcrypto.dll.a] Interrupt
make: *** [Makefile:136: all] Interrupt
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Windows system cert store

[Matthew Stickney]

I should have read the previous post more carefully:
CertGetEnhancedKeyUsage() is definitely the function for returning the
certificate usages reported by the system store manager (either the
ones set in the cert itself, the ones in the "extended property" that
can be set at will, or the effective combination of the two depending
on the flags passed).

You may have been looking at a different version of IE than what I've
got on my Windows 7 VM, but at least here IE doesn't allow you to set
certificate purposes: it has a dialog that looks just like that (under
the "Advanced" button in the certificate list), but that's only used
to select the set of usages you want to display if you choose
"" in the "Intended Purpose" dropdown at the top
(it's effectively just a customizable display filter).

I've been reading through OpenSSL's verification code a bit, and from
what I'm seeing it looks like purposes could be set for an existing
certificate by setting the appropriate bits in the ex_kusage or
ex_xkusage fields, at least for standard usages. Is that right?

-Matt Stickney

On Wed, Jul 12, 2017 at 11:26 AM, Matthew Stickney <mtstick...@gmail.com> wrote:
> On Wed, Jul 12, 2017 at 8:48 AM, Dr. Stephen Henson <st...@openssl.org> wrote:
>> Yes they're external properties. The certificate encoding returned can't be
>> modified of course because that would break the signature.
>
> That's a good point (I'm a little embarassed to have missed that).
>
>
>> I think I did some experiments with CertGetEnhancedKeyUsage()[...]
>
> It looks like another good candidate might be
> CertGetCertificateContextProperty() with the CERT_CTL_USAGE_PROP_ID
> flag. At least in principle, that's pulling usage information from the
> cert context, rather than the cert itself. I'll do some testing after
> work tonight.
>
> -Matt Stickney
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Windows system cert store

[Matthew Stickney]

On Wed, Jul 12, 2017 at 8:48 AM, Dr. Stephen Henson  wrote:
> Yes they're external properties. The certificate encoding returned can't be
> modified of course because that would break the signature.

That's a good point (I'm a little embarassed to have missed that).


> I think I did some experiments with CertGetEnhancedKeyUsage()[...]

It looks like another good candidate might be
CertGetCertificateContextProperty() with the CERT_CTL_USAGE_PROP_ID
flag. At least in principle, that's pulling usage information from the
cert context, rather than the cert itself. I'll do some testing after
work tonight.

-Matt Stickney
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Windows system cert store

[Matthew Stickney]

The Certificate Manager in Windows does allow you to change the trust
settings for root certs (including the purposes reported by openssl
x509 -purpose), although those changes don't appear to be reflected in
the cert dumped from the store (so they must be stored externally).

I think the original concern could have been one of two things (or
possibly both): 1) assuming the cert itself has purpose information,
that needs to be reflected in its use after being added to the cert
store (I assume the verification code is already checking this if it's
a property of the cert), or 2) that a user's choice to (un-)trust
certain certificates is respected, however unusual. I'm not aware of
any facility on Linux to modify the trust status of certs, so I think
this is an issue unique to Windows.

-Matt Stickney

On Sun, Jul 9, 2017 at 7:08 AM, Kurt Roeckx  wrote:
> On Sun, Jul 09, 2017 at 09:15:32AM +0200, Richard Levitte wrote:
>> In message 
>> 

[openssl-dev] Windows system cert store

[Matthew Stickney]

Back in 2010, there was some discussion on this list of adding code to
load certificates from the system cert store on Windows by default,
since the default verification paths typically don't point to anything
(this was ticket #2158, which was ultimately rejected). I have some
interest in picking up where this was left off, but I'm a little out
of my depth and have some questions.

Last time around, the sticking point was certificate purposes: we
don't want to add a certificate that's only trusted for client
authentication as trusted for server authentication. I still need to
figure out how to extract purposes from the windows certs, but I'm
also having a hard time seeing how you'd set x509 purposes in openssl.
Where should I be looking?

-Matt Stickney
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev