For anyone running across this, we also were affected by this issue and
worked with the Asterisk community to produce the patch referenced here:
https://issues.asterisk.org/jira/browse/ASTERISK-28576
This will return nonzero values to prevent the hard assert, for anyone that
is using packaged
> Actually, that is also the format and mechanism with Microsoft Win32 tools,
> they just use the DOS-like file name "foo.lib" instead of "libfoo.a" to
> maintain makefile compatibility with their older Intel OMF-based toolchains.
> The object files inside > the archive are in COFF format, as
Thank you for the suggestion. Will try that.
Regarding the static library, the term 'linking' I used was more tongue in
cheek but nonetheless. However my current concern here is meeting libSSL
and libCrypto's dependencies on host libraries on Linux platform. For
instance, when I talked about
On Wed, Nov 13, 2019 at 01:47:31PM -0500, SP wrote:
> Following an OS upgrade of the server I have been unable to start sshd
> service. On this server some software is upgraded from the OS packages
> whereas others are manually built. Openssl is manually built from source.
> After the upgrade
Following an OS upgrade of the server I have been unable to start sshd
service. On this server some software is upgraded from the OS packages
whereas others are manually built. Openssl is manually built from
source. After the upgrade of the OS the error message I get when
starting sshd is
Thanks Rich,
On Wed, Nov 13, 2019 at 12:34 PM Salz, Rich wrote:
> *>*For using 1.1.0, we only need to call RAND_bytes() ?
>
>
>
> Yes. But do check the return value of RAND_bytes.
>
Hi,
They're macros, defined in SKM_DEFINE_STACK_OF() in safestack.h. If you
DEFINE_STACK_OF(Foo), you'll automatically end up with a sk_Foo_num() macro.
Cheers,
-Dave
> On Nov 13, 2019, at 12:20, Jason Schultz wrote:
>
> Hello-
>
> I am updating my Linux application from using OpenSSL
On Wed, Nov 13, 2019 at 12:23:37PM -0500, Jason Qian via openssl-users wrote:
> Here is the code for creating the key (openssl-0.9.8h)
Is this is a new question? It seems to no longer be related to DH
key agreement.
> int AESCipher::createKey(unsigned char *buf, int keySize) {
> char
>For using 1.1.0, we only need to call RAND_bytes() ?
Yes. But do check the return value of RAND_bytes.
On 13/11/2019 17:20, Jason Schultz wrote:
> Hello-
>
> I am updating my Linux application from using OpenSSL 1.0.2 to 1.1.1 in
> preparation for OpenSSL 3.0 (and of course the EOL of 1.0.2). I'm
> confused about the function in the subject line as well as other,
> related sk_X509_* functions.
Thanks Rich and Tomas,
Here is the code for creating the key (openssl-0.9.8h)
int AESCipher::createKey(unsigned char *buf, int keySize) {
char seed[256];
::sprintf(seed, "%ldXXX_XXX_H__x__xxx_x_xxx__INCLUDED_",
MiscUtils::generateId());
RAND_seed(seed, ::strlen(seed));
> On Nov 12, 2019, at 3:14 AM, Tomas Mraz wrote:
>
> Could it be a padding issue? I.E. use DH_compute_key_padded() instead.
Do we have an open issue to document DH_compute_key_padded(3)?
It should be documented right next to DH_compute_key(3), with
some words to suggest that the caller needs to
Hello-
I am updating my Linux application from using OpenSSL 1.0.2 to 1.1.1 in
preparation for OpenSSL 3.0 (and of course the EOL of 1.0.2). I'm confused
about the function in the subject line as well as other, related sk_X509_*
functions.
My code has always used these functions, and
>RAND_seed(seed, ::strlen(seed));
>RAND_bytes(buf, keySize / 8);
I don’t know where you are getting the seed, but it is typically binary data,
not a C string.
If you are using 1.1.0 or later, you do not need to seed things.
On Wed, 2019-11-13 at 11:11 -0500, Jason Qian wrote:
> Hi Tomas,
>
>Using DH_compute_key_padded() seems fixed the problem.
>
> I have one more question regarding a similar issue but this time is
> about AES key generation.
>
> I think the problem is related to RAND_seed or
On 13/11/2019 15:23, Michael Wojcik wrote:
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
Aijaz Baig
Sent: Wednesday, November 13, 2019 01:45
I am trying to statically link libssl.a and libcrypto.a into a static library
of my own
which I will be using in an
Hi Tomas,
Using DH_compute_key_padded() seems fixed the problem.
I have one more question regarding a similar issue but this time is about
AES key generation.
I think the problem is related to RAND_seed or RAND_bytes (someone also
mentioned on another thread).
RAND_seed(seed,
On Tuesday, 12 November 2019 21:22:51 CET, Benjamin Kaduk via openssl-users
wrote:
On Tue, Nov 12, 2019 at 01:13:49PM -0700, Phil Neumiller wrote:
Thanks for all the useful device. I was able to get the server to accept
this client hello message.
If you're willing/able to share, it can be
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
> Aijaz Baig
> Sent: Wednesday, November 13, 2019 01:45
> I am trying to statically link libssl.a and libcrypto.a into a static library
> of my own
> which I will be using in an application (Linux).
You can't link
On 13/11/2019 09:22, Umamaheswari Nagarajan wrote:
> The following apis seems to be unavailable or modified in 1.1.1c,
>
> ENGINE_cleanup
This still exists, but was converted from a function to a macro that
does nothing. You no longer need to call it. OpenSSL 1.1.0+ cleans
itself up
Hi,
We are upgrading the openSSL version from 1.0.2j to 1.1.1c in our product.
The following apis seems to be unavailable or modified in 1.1.1c,
ENGINE_cleanup
RAND_cleanup
CRYPTO_lock
RSA_PKCS1_SSLeay
DH_get_ex_new_index
DSA_get_ex_new_index
RSA_get_ex_new_index
Please advise on the
On 2019-11-12 10:30 p.m., Patrick Herbst wrote:
>
> I'm not creating a new socket because it is UDP, and i'm assuming only
> one client. If you use a BIO_new_dgram, then you dont need to
You assumed one client, and you got one client. What's the problem :-)
> Even if i were the "connect" the
22 matches
Mail list logo
