Re: [openssl-users] Dealing with RFC2553 and RFC3493 where NI_MAXHOST and NI_MAXSERV no longer exist

[Erik Forsberg]

hmm, been reading this whole thread.
I dont have any current issues building with Sun Studio 12.6 in  2011 mode (but 
I only do Intel x86 and x86_64)
However, I do have a preference for using gcc for openssl builds though.
Do note however, that in my opinion, for Solaris, one MUST do the -R linker 
options
to avoid runtime issues with Solaris builds of OpenSSL, But I suppose thats for 
everyone to
discover for themselves. I discovered it the hard way during the 1.0.1 era.
The -strict mode I think is impossible as of now
(dot-asm) I do want to see your PR for adding support for -R to get 
incorporated, been sitting for a while -:)

Here are my preferred config settings for Solaris cc

   "efca-x64-cc" => {
   inherit_from=> [ "solaris-common", asm("x86_64_asm") ],
   CC  => "cc",
   CFLAGS  => add_before(picker(debug  => "-g",
 release => "-xO5 -xdepend 
-xbuiltin")),
   cflags  => add_before("-m64 -xarch=generic -xstrconst 
-std=gnu11"),
   cppflags=> add(threads("-D_REENTRANT")),
   lib_cppflags=> add("-DL_ENDIAN"),
   lflags  => add(threads("-mt")),
   ex_libs => add(threads("-lpthread")),
   bn_ops  => "SIXTY_FOUR_BIT_LONG",
   perlasm_scheme  => "elf",
   shared_cflag=> "-KPIC",
   shared_ldflag   => add_before("-G -dy -z text 
-R\$(INSTALLTOP)/\$(LIBDIR)"),
   multilib=> "/64",
   },

>-- Original Message --
>
>On 1/18/19 1:53 AM, Dennis Clarke wrote:
>> 
>> Going in circles trying to compile 1.1.1a with strict C99 and no
>> optimizations and with a ready to debug and single step resultant
>> library. 
>
>Ignore all this.  Thou shalt not C99 here.
>
>Dennis
>
>-- 
>openssl-users mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Binary Distribution DLL Names

[Grahame Grieve]

thanks very much. I will see what I can do about the indy distribution
which seems to have fallen behind

Grahame


On Sat, Jan 19, 2019 at 9:27 AM Matt Caswell  wrote:

>
>
> On 18/01/2019 11:51, Grahame Grieve wrote:
> > I got no response to this. I presume that mean that this is a stupid
> question,
> > but I'm afraid I don't understand why
> >
> > Grahame
> >
> >
> > On Mon, Jan 14, 2019 at 11:45 PM Grahame Grieve
> >  grah...@healthintersections.com.au>>
> > wrote:
> >
> > Hi
> >
> > I have a 64bit windows application that uses openSSL, and I am using
> the
> > indy distribution from https://indy.fulgan.com/SSL/. This makes the
> file
> > names of the openssl dlls libeay32.dll and ssleay32.dll (even though
> they
> > are 64bit).
>
>
> That distribution is OpenSSL 1.0.2 which uses those old names.
>
>
> > Other distributions use other names (libcrypto-XX-x64.dll etc)
>
> Other distributions you have seen are probably using OpenSSL 1.1.0 or 1.1.1
> which use the new names.
>
> >
> > I believe that the filename variations are at the root of an issue I
> have
> > with openSSL. My symptoms are this: when I run my unit tests that do
> (among
> > other things) a bunch of tests of my SSL server, all is good.
> However,
> > anytime I load the mysql odbc driver into the memory space, I get an
> memory
> > corruption problem in libeay32.dll when shutting down. Google
> suggests that
> > this is due to a build mismatch between the two dlls... I'm guessing
> that
> > mysql is loading some other dll variant of openssl and some build
> mismatch
> > is arising ?
> >
> > I'm clutching at straws here, but has this been an issue before? is
> there
> > any policy issue around distrubution filenames? Is there any other
> likely
> > cause why loading the mysql odbc driver causes memory corruptions in
> openssl
> > when shutting down?
>
> I've not seen it before. The distribution filenames vary based on the
> version of
> OpenSSL you are using.
>
> Matt
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>


-- 
-
http://www.healthintersections.com.au / grah...@healthintersections.com.au
/ +61 411 867 065
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] is there an API to list all the TLS 1.3 cipher suite names?

[Jordan Brown]

On 1/17/2019 5:33 PM, Jordan Brown wrote:
> Am I missing something?


Seems I was.  Thanks, all.

-- 
Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Dealing with RFC2553 and RFC3493 where NI_MAXHOST and NI_MAXSERV no longer exist

[Dennis Clarke]

On 1/18/19 1:53 AM, Dennis Clarke wrote:


Going in circles trying to compile 1.1.1a with strict C99 and no
optimizations and with a ready to debug and single step resultant
library. 


Ignore all this.  Thou shalt not C99 here.

Dennis

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Dealing with RFC2553 and RFC3493 where NI_MAXHOST and NI_MAXSERV no longer exist

[Dennis Clarke]

Going in circles trying to compile 1.1.1a with strict C99 and no
optimizations and with a ready to debug and single step resultant
library.  Ran headlong into crypto/bio/b_addr.c where we see :

   176  /*-
   177   * addr_strings - helper function to get host and service names
   178   * @ap: the BIO_ADDR that has the input info
   179   * @numeric: 0 if actual names should be returned, 1 if the numeric
   180   * representation should be returned.
   181   * @hostname: a pointer to a pointer to a memory area to store the
   182   * host name or numeric representation.  Unused if NULL.
   183   * @service: a pointer to a pointer to a memory area to store the
   184   * service name or numeric representation.  Unused if NULL.
   185   *
   186   * The return value is 0 on failure, with the error code in the 
error

   187   * stack, and 1 on success.
   188   */
   189  static int addr_strings(const BIO_ADDR *ap, int numeric,
   190  char **hostname, char **service)
   191  {
   192  if (BIO_sock_init() != 1)
   193  return 0;
   194
   195  if (1) {
   196  #ifdef AI_PASSIVE
   197  int ret = 0;
   198  char host[NI_MAXHOST] = "", serv[NI_MAXSERV] = "";
   199  int flags = 0;
   200
.
.
.

Where we see NI_MAXHOST and NI_MAXSERV used however those did exist in 
RFC2553 and then were removed in RFC3493 and thus strict C99 halts in a 
noisey way unless __EXTENSIONS__ is defined.


"crypto/bio/b_addr.c", line 198: error: undefined symbol: NI_MAXHOST
"crypto/bio/b_addr.c", line 198: error: variable length array can not be 
initialized: host

"crypto/bio/b_addr.c", line 198: error: undefined symbol: NI_MAXSERV
"crypto/bio/b_addr.c", line 198: error: variable length array can not be 
initialized: serv

c99: acomp failed for crypto/bio/b_addr.c

Right.

If I attempt to use "extensions" and other things then this compiles
just fine and the process fails in other places.  For now, however, the
values NI_MAXHOST and NI_MAXSERV don't really exist in netdb.h as
far as I can see.

Dennis
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] is there an API to list all the TLS 1.3 cipher suite names?

[Sam Roberts]

On Thu, Jan 17, 2019 at 5:40 PM Jordan Brown
 wrote:
> On 1/14/2019 4:09 AM, Matt Caswell wrote:
>
> This works more "by accident". There is no ciphersuite alias called 
> "TLSv1.3", so using it as above results in no ciphersuites matched. Since the 
> TLSv1.3 ciphersuites are on by default anyway that's all that you get back.
>
>
> From what you say, and based on experimentation, it seems like the TLSv1.3 
> ciphersuites are enabled even if you explicitly say to disable them.

3 of 5 TLS1.3 cipher suites are enabled by default

I'm having to reverse engineer the intention, but I think that it was
thought that the cipher list API with its mini language was too
complex, so there is a new API for setting TLS1.3 cipher suites,
_set_ciphersuites(), and for openssl cipher, you can pass args to it
using the -ciphersuites option. You can also pass an empty string ""
to clear them.

Another reason for the second API and the odd interactions between
them may be that there are existing apps calling the set_cipher_list()
APIs.. if their arg applied to TLS1.3 ciphers, it would always clear
them, so existing apps wouldn't use TLS1.3 even though they were
theoretically capable.

Anyhow, you are seeing that seperation of two APIs, each configuring
suites for different protocol familes (pre/post TLS1.3).
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Binary Distribution DLL Names

[Grahame Grieve]

I got no response to this. I presume that mean that this is a stupid
question, but I'm afraid I don't understand why

Grahame


On Mon, Jan 14, 2019 at 11:45 PM Grahame Grieve <
grah...@healthintersections.com.au> wrote:

> Hi
>
> I have a 64bit windows application that uses openSSL, and I am using the
> indy distribution from https://indy.fulgan.com/SSL/. This makes the file
> names of the openssl dlls libeay32.dll and ssleay32.dll (even though they
> are 64bit).  Other distributions use other names (libcrypto-XX-x64.dll etc)
>
> I believe that the filename variations are at the root of an issue I have
> with openSSL. My symptoms are this: when I run my unit tests that do (among
> other things) a bunch of tests of my SSL server, all is good. However,
> anytime I load the mysql odbc driver into the memory space, I get an memory
> corruption problem in libeay32.dll when shutting down. Google suggests that
> this is due to a build mismatch between the two dlls... I'm guessing that
> mysql is loading some other dll variant of openssl and some build mismatch
> is arising ?
>
> I'm clutching at straws here, but has this been an issue before? is there
> any policy issue around distrubution filenames? Is there any other likely
> cause why loading the mysql odbc driver causes memory corruptions in
> openssl when shutting down?
>
> thanks
> Grahame
> --
> -
> http://www.healthintersections.com.au / grah...@healthintersections.com.au
> / +61 411 867 065
>


-- 
-
http://www.healthintersections.com.au / grah...@healthintersections.com.au
/ +61 411 867 065
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] is there an API to list all the TLS 1.3 cipher suite names?

[Hubert Kario]

On Friday, 18 January 2019 02:33:20 CET Jordan Brown wrote:
> On 1/14/2019 4:09 AM, Matt Caswell wrote:
> > This works more "by accident". There is no ciphersuite alias called
> > "TLSv1.3", so using it as above results in no ciphersuites matched.
> > Since the TLSv1.3 ciphersuites are on by default anyway that's all
> > that you get back.
> 
> From what you say, and based on experimentation, it seems like the
> TLSv1.3 ciphersuites are enabled even if you explicitly say to disable them.
> 
> $ openssl ciphers SHA384:\!TLS_AES_256_GCM_SHA384
> *TLS_AES_256_GCM_SHA384*:TLS_CHACHA20_POLY1305_SHA256:[...]
> 
> $ openssl ciphers AES:-SHA384
> *TLS_AES_256_GCM_SHA384*:TLS_CHACHA20_POLY1305_SHA256:[...]
> 
> That doesn't seem right.  Am I missing something?

see man 1 ciphers
section "TLS v1.3 cipher suites" specifies all ciphers that are supported for 
TLS 1.3 while -ciphersuites is used to change which are enabled

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] in the department of "ain't no perfect"

[Hubert Kario]

On Friday, 18 January 2019 05:45:11 CET Jakob Bohm via openssl-users wrote:
> On 16/01/2019 21:25, Viktor Dukhovni wrote:
> >> On Jan 15, 2019, at 10:29 AM, Eliot Lear 
> > The naïve model of using the signer and recipient keys as long-term
> > verification and decryption keys is deeply flawed for data retention.
> > This is a bit part of the reason why end-to-end email encryption has
> > negligible adoption, the storage infrastructure to make it usable was
> > never built.
> 
> As explained above, most of that storage infrastructure is in
> fact in place, but the major e-mail clients lack the code to use
> it.  For example the "openssl cms" command (used by some unix mail
> clients, such as Mutt) doesn't have an option to specify the "as of"
> date extracted from an external trusted source.

it does in newer versions (it is definitely present in 1.1.0i):
 -attime intmax verification epoch time

> Nor does it have
> an option to input a recorded OCSP response or CRL to be validated
> and used according to that "as of" date.

that's true

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] is there an API to list all the TLS 1.3 cipher suite names?

[Benjamin Kaduk]

On Fri, Jan 18, 2019 at 01:33:20AM +, Jordan Brown wrote:
> On 1/14/2019 4:09 AM, Matt Caswell wrote:
> > This works more "by accident". There is no ciphersuite alias called
> > "TLSv1.3", so using it as above results in no ciphersuites matched.
> > Since the TLSv1.3 ciphersuites are on by default anyway that's all
> > that you get back.
> 
> 
> From what you say, and based on experimentation, it seems like the
> TLSv1.3 ciphersuites are enabled even if you explicitly say to disable them.
> 
> $ openssl ciphers SHA384:\!TLS_AES_256_GCM_SHA384
> *TLS_AES_256_GCM_SHA384*:TLS_CHACHA20_POLY1305_SHA256:[...]
> 
> $ openssl ciphers AES:-SHA384
> *TLS_AES_256_GCM_SHA384*:TLS_CHACHA20_POLY1305_SHA256:[...]
> 
> That doesn't seem right.  Am I missing something?

Presumably.  The TLS 1.3 ciphersuites are entirely separate from the traditional
cipher list:

-ciphersuites val
Sets the list of TLSv1.3 ciphersuites. This list will be combined with
any TLSv1.2 and below ciphersuites that have been configured. The format
for this list is a simple colon (":") separated list of TLSv1.3
ciphersuite names. By default this value is:

 
TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA25

-Ben
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] crypto/objects/o_names.c problem with Solaris 10 and strict Oracle Studio 12.6 c99

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
> Dennis Clarke
> Sent: Thursday, January 17, 2019 23:56
>
> Thank you for the great reply where clearly you have seen ifdeffery
> nonsense bite you.  I get caught between a rock and a hrd place here
> every time because if I try to go with just ordinary cc and just some
> transition loosey goosey not-really-compliant or strict CFLAGS then I
> arrive in a different ugly place :
>
>
> ${LDCMD:-/opt/developerstudio12.6/bin/cc} -m64 -xarch=sparc -g -Xa
> -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff
> -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc
> -ftrap=%none -xbuiltin=%none -xunroll=1 -xstrconst -Xa -m64 -xarch=sparc
> -g -Xa -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff
> -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc
> -ftrap=%none -xbuiltin=%none -xunroll=1 -L. -mt  \
>  -o test/rsa_complex test/rsa_complex.o \
>   -lsocket -lnsl -ldl -lrt -lpthread
> Undefined   first referenced
>   symbol in file
> OPENSSL_sk_pop_free test/rsa_complex.o [etc]

Am I missing something, or is this just because Configure somehow gave you a 
makefile for the tests that doesn't actually link the OpenSSL libraries? 
There's just libsocket, libnsl, libdl, librt, and libpthread there.

I don't know how that would have happened, but I haven't looked at the 
Configure for 1.1.1 as closely as I have the 1.0.2. (I was primarily 
responsible for hacking my team's OpenSSL builds for the 1.0.2 line, but a 
different developer for 1.1.1 implemented our move to that release.)

It appears for our Solaris 11 SPARC build of 1.1.1 we're using stock OpenSSL 
Configure with "solaris-sparcv9-gcc" as the target (or solaris64-sparcv9-gcc 
for 64-bit builds). If memory serves, we used to use the Sun/Oracle 
implementation (SUNWspro) in older products, but that would have been with 
OpenSSL 1.0.2 or possibly earlier. I'm not sure when we switched to gcc on 
Solaris. So unfortunately I don't have any more-specific advice for building 
1.1.1 using the Developer Studio toolchain.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] is there an API to list all the TLS 1.3 cipher suite names?

[Vitezslav Cizek]

Hi,

V Fri, 18 Jan 2019 01:33:20 +
"Jordan Brown"  napsáno:

> On 1/14/2019 4:09 AM, Matt Caswell wrote:
> > This works more "by accident". There is no ciphersuite alias called
> > "TLSv1.3", so using it as above results in no ciphersuites matched.
> > Since the TLSv1.3 ciphersuites are on by default anyway that's all
> > that you get back.  
> 
> 
> From what you say, and based on experimentation, it seems like the
> TLSv1.3 ciphersuites are enabled even if you explicitly say to
> disable them.
> 
> $ openssl ciphers SHA384:\!TLS_AES_256_GCM_SHA384
> *TLS_AES_256_GCM_SHA384*:TLS_CHACHA20_POLY1305_SHA256:[...]
> 
> $ openssl ciphers AES:-SHA384
> *TLS_AES_256_GCM_SHA384*:TLS_CHACHA20_POLY1305_SHA256:[...]
> 
> That doesn't seem right.  Am I missing something?

Yes.
TLS 1.3 ciphers are configured differently, you need to use
the -ciphersuites option.

See https://www.openssl.org/docs/man1.1.1/man1/ciphers.html

Try
# openssl ciphers -v -ciphersuites '' SHA384

  Vita

-- 
Vítězslav Čížek Emergency Update Team (EMU)
"Whilst you sleep, we're probably saving the universe."
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] The less than perfect way to compile a debug library

[Dennis Clarke]

On 1/18/19 3:32 AM, Dennis Clarke wrote:



This is based on the sickly things that happen on Solaris as documented 
by various people at :


fixed .. done

https://github.com/openssl/openssl/pull/7721/commits/23dcef5ad68efe6f6882328de5948ae682fb




https://github.com/openssl/openssl/issues/6912


Dennis

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] The less than perfect way to compile a debug library

[Dennis Clarke]

This is based on the sickly things that happen on Solaris as documented 
by various people at :


https://github.com/openssl/openssl/issues/6912

One must do :

/*
 * Copyright 2018 The OpenSSL Project Authors. All Rights Reserved.
 *
 * Licensed under the OpenSSL license (the "License").  You may not use
 * this file except in compliance with the License.  You can obtain a copy
 * in the file LICENSE in the source distribution or at
 * https://www.openssl.org/source/license.html
 */

/*
 * Check to see if there is a conflict between complex.h and openssl/rsa.h.
 * The former defines "I" as a macro and earlier versions of the latter use
 * for function arguments.
 */
#if defined(__STDC_VERSION__)
# if __STDC_VERSION__ >= 199901L
#  include 
# endif
#endif
#include 
#include 

/* per https://github.com/openssl/openssl/issues/6912 */
#pragma weak OPENSSL_sk_pop_free
#pragma weak OPENSSL_sk_dup
#pragma weak OPENSSL_sk_pop
#pragma weak OPENSSL_sk_num
#pragma weak OPENSSL_sk_new
#pragma weak OPENSSL_sk_set
#pragma weak OPENSSL_sk_free
#pragma weak OPENSSL_sk_find
#pragma weak OPENSSL_sk_push
#pragma weak OPENSSL_sk_sort
#pragma weak OPENSSL_sk_zero
#pragma weak OPENSSL_sk_is_sorted
#pragma weak OPENSSL_sk_shift
#pragma weak OPENSSL_sk_value
#pragma weak OPENSSL_sk_delete_ptr
#pragma weak OPENSSL_sk_unshift
#pragma weak OPENSSL_sk_new_null
#pragma weak OPENSSL_sk_set_cmp_func
#pragma weak OPENSSL_sk_reserve
#pragma weak OPENSSL_sk_new_reserve
#pragma weak OPENSSL_sk_delete
#pragma weak OPENSSL_sk_insert
#pragma weak OPENSSL_sk_deep_copy
#pragma weak OPENSSL_sk_find_ex

int main(int argc, char *argv[])
{
/* There are explicitly no run time checks for this one */
return EXIT_SUCCESS;
}

That is horrific but allows a strict C99 compile to proceed.

Dennis
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] compile hell : fatal: symbol referencing errors. OPENSSL_sk_pop_free etc etc etc

[Dennis Clarke]

On 1/18/19 1:05 AM, Dennis Clarke wrote:


So it seems to no longer matter if I try strict C99 or just cc with or
without strict CFLAGS. I always arrive at the same place :


Ignore this .. fixed .. done .. closed ... not even a correct issue.

Thou shalt not pass C99 here.  Thus sayeth the Salz and so let it be 
written ...



Dennis

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] compile hell : fatal: symbol referencing errors. OPENSSL_sk_pop_free etc etc etc

[Dennis Clarke]

So it seems to no longer matter if I try strict C99 or just cc with or
without strict CFLAGS. I always arrive at the same place :

${LDCMD:-/opt/developerstudio12.6/bin/cc} -m64 -xarch=sparc -g -Xa 
-errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff 
-xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc 
-ftrap=%none -xbuiltin=%none -xunroll=1 -Qy -xdebugformat=dwarf 
-xstrconst -Xa -m64 -xarch=sparc -g -Xa -errfmt=error -erroff=%none 
-errshort=full -xstrconst -xildoff -xmemalign=8s -xnolibmil -xcode=pic32 
-xregs=no%appl -xlibmieee -mc -ftrap=%none -xbuiltin=%none -xunroll=1 
-Qy -xdebugformat=dwarf -L. -mt  \

-o test/rsa_complex test/rsa_complex.o \
 -lsocket -lnsl -ldl -lrt -lpthread
cc: Warning: multiple use of -Q option, previous one discarded.
Undefined   first referenced
 symbol in file
OPENSSL_sk_pop_free test/rsa_complex.o
OPENSSL_sk_dup  test/rsa_complex.o
OPENSSL_sk_pop  test/rsa_complex.o
OPENSSL_sk_num  test/rsa_complex.o
OPENSSL_sk_new  test/rsa_complex.o
OPENSSL_sk_set  test/rsa_complex.o
OPENSSL_sk_free test/rsa_complex.o
OPENSSL_sk_find test/rsa_complex.o
OPENSSL_sk_push test/rsa_complex.o
OPENSSL_sk_sort test/rsa_complex.o
OPENSSL_sk_zero test/rsa_complex.o
OPENSSL_sk_is_sortedtest/rsa_complex.o
OPENSSL_sk_shifttest/rsa_complex.o
OPENSSL_sk_valuetest/rsa_complex.o
OPENSSL_sk_delete_ptr   test/rsa_complex.o
OPENSSL_sk_unshift  test/rsa_complex.o
OPENSSL_sk_new_null test/rsa_complex.o
OPENSSL_sk_set_cmp_func test/rsa_complex.o
OPENSSL_sk_reserve  test/rsa_complex.o
OPENSSL_sk_new_reserve  test/rsa_complex.o
OPENSSL_sk_delete   test/rsa_complex.o
OPENSSL_sk_insert   test/rsa_complex.o
OPENSSL_sk_deep_copytest/rsa_complex.o
OPENSSL_sk_find_ex  test/rsa_complex.o
ld: fatal: symbol referencing errors. No output written to test/rsa_complex
gmake[1]: *** [Makefile:3561: test/rsa_complex] Error 2
gmake[1]: Leaving directory 
'/usr/local/build/openssl-1.1.1a_SunOS5.10_sparc64vii+.005'

gmake: *** [Makefile:169: all] Error 2

corv $

Attempts to use C99 and strict CFLAGS simply falls into a hell with some
oddball strcmpcase function issue regardless if I use strings.h or not
so let's just stay here and try to figure out what do I need to do to
get a debug non-stripped and not optimized build out of 1.1.1a?

Certainly did not have these issues with 1.1.1 or any of the pre-release
versions. Not that I recall.

So .. any thoughts?

Dennis
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Binary Distribution DLL Names

[Matt Caswell]

On 18/01/2019 11:51, Grahame Grieve wrote:
> I got no response to this. I presume that mean that this is a stupid question,
> but I'm afraid I don't understand why
> 
> Grahame
> 
> 
> On Mon, Jan 14, 2019 at 11:45 PM Grahame Grieve
>  >
> wrote:
> 
> Hi
> 
> I have a 64bit windows application that uses openSSL, and I am using the
> indy distribution from https://indy.fulgan.com/SSL/. This makes the file
> names of the openssl dlls libeay32.dll and ssleay32.dll (even though they
> are 64bit).


That distribution is OpenSSL 1.0.2 which uses those old names.


> Other distributions use other names (libcrypto-XX-x64.dll etc)

Other distributions you have seen are probably using OpenSSL 1.1.0 or 1.1.1
which use the new names.

> 
> I believe that the filename variations are at the root of an issue I have
> with openSSL. My symptoms are this: when I run my unit tests that do 
> (among
> other things) a bunch of tests of my SSL server, all is good. However,
> anytime I load the mysql odbc driver into the memory space, I get an 
> memory
> corruption problem in libeay32.dll when shutting down. Google suggests 
> that
> this is due to a build mismatch between the two dlls... I'm guessing that
> mysql is loading some other dll variant of openssl and some build mismatch
> is arising ? 
> 
> I'm clutching at straws here, but has this been an issue before? is there
> any policy issue around distrubution filenames? Is there any other likely
> cause why loading the mysql odbc driver causes memory corruptions in 
> openssl
> when shutting down? 

I've not seen it before. The distribution filenames vary based on the version of
OpenSSL you are using.

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

Re: [openssl-users] in the department of "ain't no perfect"

[Eliot Lear]

On 17.01.19 21:20, Hubert Kario wrote:
> then I'd say that showing the date from within the signature will be more 
> confusing than helpful to the administrator

Nevermind the date, you can't even get the expiration error
programmatically.




signature.asc
Description: OpenPGP digital signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users