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
>&g
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
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:
nfigure 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...@opens
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
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
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
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
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
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
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
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
12 matches
Mail list logo