of that SSL object drops to zero it will
call BIO_free_all() on the underlying wbio and rbio. Which means also
the chained BIOs underlying the SSL BIO will have their refcount
dropped and they will be properly freed.
Tomas Mraz, OpenSSL
On Mon, 2022-10-03 at 09:35 -0700, Jay Foster wrote:
Your response
ext(sslbio, socketbio);
The SSL BIO should always have a next BIO if properly initialized.
Tomas Mraz, OpenSSL
On Thu, 2022-09-29 at 13:02 -0700, Jay Foster wrote:
I have an application that constructs a chain of BIOs. Sometimes
this
chain also includes an SSL BIO. Years ago, I ran into a prob
I have an application that constructs a chain of BIOs. Sometimes this
chain also includes an SSL BIO. Years ago, I ran into a problem that
caused BIO_flush() to segfault on the SSL BIO. This turned out to
happen because the SSL BIO is added using SSL_set_bio() instead of
BIO_push().
I am trying to build the 1.1.1p and 3.0.4 versions of OpenSSL. Each
version now fails in the same place (test/v3ext.c). The error is about
undefined ASIdentifiers, etc. in the newly added test_asid() function.
It looks like the newly added test_asid() function needs an '#ifndef
On 9/27/21 7:33 AM, Michael Richardson wrote:
Jay Foster wrote:
> While migrating some applications from OpenSSL 1.0.2 (and 1.1.1) to
> 3.0.0, I have noticed that the SSL_CTX_set_default_verify_paths()
> function is much slower in 3.0.0. In 1.0.0 it would take
While migrating some applications from OpenSSL 1.0.2 (and 1.1.1) to
3.0.0, I have noticed that the SSL_CTX_set_default_verify_paths()
function is much slower in 3.0.0. In 1.0.0 it would take about 0.1
seconds and in 3.0.0 it takes over 3 seconds.
strace indicates that the extra time is
On 5/28/2019 10:39 AM, Jay Foster wrote:
I built OpenSSL 1.1.1c from the recent release, but have noticed what
seems like a significant performance drop compared with 1.1.1b. I
notice this when starting lighttpd. With 1.1.1b, lighttpd starts in a
few seconds, but with 1.1.1c, it takes
I built OpenSSL 1.1.1c from the recent release, but have noticed what
seems like a significant performance drop compared with 1.1.1b. I
notice this when starting lighttpd. With 1.1.1b, lighttpd starts in a
few seconds, but with 1.1.1c, it takes several minutes.
I also noticed that with
With the recent release of OpenSSL 1.1.1, I tried to cross compile it
for a 32-bit ARM architecture. I observe many compiler warnings similar
to the following:
crypto/ec/curve448/curve448.c:30: warning: integer constant is too large
for 'long' type
crypto/ec/curve448/curve448.c:30: warning:
I have used the following snippet (along with some others) in the e_os.h
header file:
# if defined(__ECOS)
# define __INITIAL_POINTER_SIZE 0
# define GETPID_IS_MEANINGLESS
# define NO_CHMOD
# define NO_SYSLOG
# define HAVE_LONG_LONG 1
# define HAVE_LONG_DOUBLE 1
#
It is very likely that your text file also contains a newline at the
end, so getting the same result as with the echo command would be
expected. If it is indeed the newline that is making the difference,
you could try using the echo command with the '-n' option to suppress it.
Jay
On
On 11/17/2015 9:56 AM, Jeffrey Walton wrote:
We can significantly reduce that liability by removing any assembler
optimisations. Also just because something is available doesn't mean it
has to be "default". We can have good defaults whilst keeping old crypto.
Zooko Wilcox O'Hearn recently gave
On 6/19/2015 1:11 PM, Michael Wojcik wrote:
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
Of Jay Foster
Sent: Friday, June 19, 2015 15:51
I got my application to compile and link. It seemed to run OK, but when
I tried to run it on a different Windows machine
On 6/19/2015 2:09 PM, Jay Foster wrote:
On 6/19/2015 1:11 PM, Michael Wojcik wrote:
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On
Behalf
Of Jay Foster
Sent: Friday, June 19, 2015 15:51
I got my application to compile and link. It seemed to run OK, but
when
I tried to run
On 6/18/2015 7:55 PM, Thomas J. Hruska wrote:
On 6/18/2015 4:46 PM, Jay Foster wrote:
I'm new to building OpenSSL with Windows. I'm trying to build OpenSSL
1.0.2c for Windows, but get a linking error
tmp32dll\x86cpuid.obj : fatal error LNK1112: module machine type 'X86'
conflicts with target
On 6/19/2015 8:30 AM, Jay Foster wrote:
On 6/18/2015 7:55 PM, Thomas J. Hruska wrote:
On 6/18/2015 4:46 PM, Jay Foster wrote:
I'm new to building OpenSSL with Windows. I'm trying to build OpenSSL
1.0.2c for Windows, but get a linking error
tmp32dll\x86cpuid.obj : fatal error LNK1112: module
On 6/19/2015 8:55 AM, Michael Wojcik wrote:
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
Of Jay Foster
Sent: Friday, June 19, 2015 11:49
I started over from a clean directory and the build completed. On
linux, I would end up with two libraries (libssl, libcrypto). I
On 6/19/2015 10:52 AM, Jay Foster wrote:
On 6/19/2015 8:55 AM, Michael Wojcik wrote:
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On
Behalf
Of Jay Foster
Sent: Friday, June 19, 2015 11:49
I started over from a clean directory and the build completed. On
linux, I would end up
I'm new to building OpenSSL with Windows. I'm trying to build OpenSSL
1.0.2c for Windows, but get a linking error
tmp32dll\x86cpuid.obj : fatal error LNK1112: module machine type 'X86'
conflicts with target machine type 'x64'
I googled for this error, but the solutions mention changing
What is the down side of truncating a hash? For example, an SHA-256
hash is 256 bits. Is it any less secure if one was to drop the last 128
bits to make a 128 bit hash or take the MD5 hash of the SHA-256 hash to
get a 128 bit hash? It does not seem that such an action would make it
any
have any minimum requirements for the libc version or
kernel version? I am currently building against libc version 2.5 with
the kernel at 2.6.30.
Mike
-- Forwarded message --
From: Jay Foster jayf0s...@roadrunner.com
mailto:jayf0s...@roadrunner.com
To: openssl-users@openssl.org
building against libc version 2.5 with
the kernel at 2.6.30.
Mike
-- Forwarded message --
From: Jay Foster jayf0s...@roadrunner.com
mailto:jayf0s...@roadrunner.com
To: openssl-users@openssl.org mailto:openssl-users@openssl.org
Cc:
Date: Fri, 13 Feb 2015 08:48:12 -0800
Subject
I have successfully built OpenSSL 1.0.0..., 1.0.1..., and 1.0.2 also on
an ARM926EJ linux based system. I used the 'no-ssl2 no-ssl3 linux-armv4
shared' options (plus some others). I found that it works with and
without the ARM assembly accelerations (no-asm option), even though the
ARM926EJ
I ran into this as well, but fixed it. The issue for me was my build
environment was for a cross compilation. It had some extra
compiler/linker options that caused the compiler to search the sysroot
path header files before the ones specified by -Ipath statements. The
result was the
There seems to be a difference between the SSL (protocol) version and
the Cipher version/description. You might try the following debug code
to clarify.
printf(SSL Version: %s\n, SSL_get_version(ssl));
const SSL_CIPHER *ciph = SSL_get_current_cipher(ssl);
if (ciph)
{
I downloaded the OpenSSL 1.0.0o source but I am running into a new
problem when trying to compile it. The 'make depend' step fails with:
s3_lib.c:2507:4: error: #error Code needs update for SSLv23_method()
support beyond TLS1_VERSION.
d1_lib.c:273:4: error: #error Code needs update for
On 10/15/2014 3:01 PM, Jay Foster wrote:
I downloaded the OpenSSL 1.0.0o source but I am running into a new
problem when trying to compile it. The 'make depend' step fails with:
s3_lib.c:2507:4: error: #error Code needs update for SSLv23_method()
support beyond TLS1_VERSION.
d1_lib.c:273:4
27 matches
Mail list logo
