Picon

[openssl.org #2419] 1.0.0c build on Intel Core i3 ignores my "--prefix=" option, installs in /usr. How to fix?

Hello,

I'm trying to build openssl 1.0.0c on an Intel i3 box.

Atm, I'm using GCC version:

  gcc version 4.5.0 20100604 [gcc-4_5-branch revision 160292] (SUSE
  Linux)

As i3-specific march/mtune FLAGS are apaprently not available until GCC
4.6:

 Support for Intel Core i3/i5/i7 processors is now available through the
 -march=corei7 and -mtune=corei7 options.
 http://www.gnu.org/software/gcc/gcc-4.6/changes.html

I'm using

  setenv CFLAGS "-O2 -march=native -mtune=native"

I'm able to build with no errors but "--prefix=" seems to be ignored.  I
specify "--prefix=/usr/local/ssl --openssldir=/usr/local/ssl" to
./Configure, but it gets build, and installed, incorrectly to
"--prefix=/usr", and more of a problem -- "--libdir=/usr/lib64
--libexecdir=/usr/lib64".

Here's what I'm doing:

cd /usr/local/src/openssl/openssl-1.0.0c
./Configure shared --prefix=/usr/local/ssl --openssldir=/usr/local/ssl
(Continue reading)

Sebastian Andrzej Siewior | 2 Jan 23:14 2011

Bug#440538: [PATCH] ecrypto/ecdsa: fix a zero change in the test suite

At the end of the testsuite in test_builtin() happens the following:
- a previously created signature gets modified at a random spot
- this signature is compared against the data which was used to create the
  signature.

Now, in theory the last step should always fail in reality is passed
sometimes. The modification algorithm did the following:
|	offset = sig[10] % 66;
|	dirt = sig[11];
|	dirt = dirt ? dirt : 1;
|	sig[offset] ^= dirt;

If sig[10] is 0xa7 and sig[11] is 0x9e the last line evolves to:
|	sig[35] ^= 0x9e;

The signature consists of two BIGNUMs encoded as ASN1 string. sig[34] and
sig[35] is the begin of the second and last number. sig[35] contains the
length of this number and its content is 0x1e. Now, 0x9e ^ 0x1e = 0x80
and this is a special value. It means that the length of the value is
"infinite" i.e. everything until the end of the stream. So the ASN1 parser
considers the remaining data as the last element. Since there is nothing
after it, it succeeds. This random modification was a zero change.

This change ensures that something like this does not happen again. If we
do a zero change by accident (R and S are unchanged) we make a third
change and hope that something will change now.

Signed-off-by: Sebastian Andrzej Siewior <sebastian <at> breakpoint.cc>
---
 crypto/ecdsa/ecdsatest.c |   87 +++++++++++++++++++++++++++++++++++++++++++---
(Continue reading)

Stephen Henson via RT | 3 Jan 01:47 2011
Picon

[openssl.org #2412] Resolved: Dropped 'L' suffix on OPENSSL_VERSION_NUMBER

According to our records, your request has been resolved. If you have any
further questions or concerns, please respond to this message.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Stephen Henson via RT | 3 Jan 02:10 2011
Picon

[openssl.org #2413] Resolved: [Patch] fix definition typo in bss_dgram.c

According to our records, your request has been resolved. If you have any
further questions or concerns, please respond to this message.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

The Doctor | 3 Jan 06:36 2011
Picon

assert issue in openssl-1.0.1-stable-SNAP-20110103

All right, when attempting to compile openssl-1.0.1-stable-SNAP-20110103

I got

making all in crypto/stack...
making all in crypto/lhash...
making all in crypto/rand...
making all in crypto/err...
making all in crypto/evp...
making all in crypto/asn1...
making all in crypto/pem...
making all in crypto/x509...
making all in crypto/x509v3...
making all in crypto/conf...
making all in crypto/txt_db...
making all in crypto/pkcs7...
making all in crypto/pkcs12...
making all in crypto/comp...
making all in crypto/ocsp...
making all in crypto/ui...
making all in crypto/krb5...
making all in crypto/cms...
making all in crypto/pqueue...
making all in crypto/ts...
making all in crypto/jpake...
making all in crypto/store...
if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then  (cd ..; make libcrypto.so.1.0.0);  fi
libcrypto.a(v3_asid.o): In function `v3_asid_validate_path_internal':
/usr/source/openssl-1.0.1-stable-SNAP-20110103/crypto/x509v3/v3_asid.c:802: undefined
reference to `assert'
(Continue reading)

Uri Simchoni | 3 Jan 13:22 2011

Non empty error stack failing non-blocking SSL IO

I’m using OpenSSL 0.9.8i, and have noticed the following scenario:

-          Some OpenSSL crypto function returns with an error, leaving a description of the error on the error queue

-          The application neglects to call ERR_clear_error()

-          SSL_read() is then called on a non-blocking socket and returns because there’s no input available

-          Calling SSL_get_error() returns SSL_ERROR_SSL instead of SSL_ERROR_WANT_READ, because the error queue is not empty.

 

Would it be possible to modify the code so that blocking socket takes precedence over the error queue?

If not, what is the recommended programming practice with non-blocking sockets?

-          ensure the everybody call ERR_clear_error() after an error

-          call ERR_clear_error() before SSL read/write (but if that’s recommended why isn’t it inside SSL_read/SSL_write)

 

Thanks,

Uri

 

Andrey Kulikov | 4 Jan 02:12 2011
Picon

What is the REALLY proper way to use an ENGINE?

If we take a look at any ENGINE_load_XXX function, we find that they all has similar structure:

    ENGINE *toadd = engine_XXX();
    if(!toadd) return;
    ENGINE_add(toadd);
    ENGINE_free(toadd);
    ERR_clear_error();

My question is: why we need call ENGINE_free(toadd) ??
Somewhere inside it calls EVP_PKEY_asn1_free(), which besides everything else desroy all AMETH structures, created during engine initialization via EVP_PKEY_asn1_set_* .

So, let's consider following example:

    CRYPTO_malloc_init();
    ERR_load_crypto_strings();
    ENGINE_load_builtin_engines();

    e = ENGINE_by_id("XXX");
    ENGINE_set_default(e, ENGINE_METHOD_ALL);
    OpenSSL_add_all_algorithms();
    OpenSSL_add_ssl_algorithms();

    EVP_PKEY *signing_key = ENGINE_load_private_key(e, NULL, NULL, NULL);

    // bla-bla-bla...

And, if in engine load priv func we write something like
    EVP_PKEY *pkey = EVP_PKEY_new();
    pkey->ameth = ENGINE_get_pkey_asn1_meth(eng, NID_id_SOME_NID);

it's not gonna work, because all ASN1 structures, carefully created by engine via calls to EVP_PKEY_asn1_set_* are invalid and possibly corrupted at this moment.

Is it a design issue, or provided example is invalid (but it taken from openssl sources, hm...)?

Andrey Kulikov | 4 Jan 02:57 2011
Picon

Re: What is the REALLY proper way to use an ENGINE?

Update: adding
ENGINE_init(e)
after
e = ENGINE_by_id("XXX");

doesn't make any difference, as in my case functional reference count is 8(???) at the moment of ENGINE_init(e)  call, so engine is not re-initialised. :(

On 4 January 2011 04:12, Andrey Kulikov <amdeich <at> gmail.com> wrote:
If we take a look at any ENGINE_load_XXX function, we find that they all has similar structure:

    ENGINE *toadd = engine_XXX();
    if(!toadd) return;
    ENGINE_add(toadd);
    ENGINE_free(toadd);
    ERR_clear_error();

My question is: why we need call ENGINE_free(toadd) ??
Somewhere inside it calls EVP_PKEY_asn1_free(), which besides everything else desroy all AMETH structures, created during engine initialization via EVP_PKEY_asn1_set_* .

So, let's consider following example:

    CRYPTO_malloc_init();
    ERR_load_crypto_strings();
    ENGINE_load_builtin_engines();

    e = ENGINE_by_id("XXX");
    ENGINE_set_default(e, ENGINE_METHOD_ALL);
    OpenSSL_add_all_algorithms();
    OpenSSL_add_ssl_algorithms();

    EVP_PKEY *signing_key = ENGINE_load_private_key(e, NULL, NULL, NULL);

    // bla-bla-bla...

And, if in engine load priv func we write something like
    EVP_PKEY *pkey = EVP_PKEY_new();
    pkey->ameth = ENGINE_get_pkey_asn1_meth(eng, NID_id_SOME_NID);

it's not gonna work, because all ASN1 structures, carefully created by engine via calls to EVP_PKEY_asn1_set_* are invalid and possibly corrupted at this moment.

Is it a design issue, or provided example is invalid (but it taken from openssl sources, hm...)?


Dr. Stephen Henson | 4 Jan 04:23 2011
Picon

Re: What is the REALLY proper way to use an ENGINE?

On Tue, Jan 04, 2011, Andrey Kulikov wrote:

> If we take a look at any ENGINE_load_XXX function, we find that they all has
> similar structure:
> 
>     ENGINE *toadd = engine_XXX();
>     if(!toadd) return;
>     ENGINE_add(toadd);
>     ENGINE_free(toadd);
>     ERR_clear_error();
> 
> My question is: why we need call ENGINE_free(toadd) ??

To avoid a memory leak.

When you call engine_XXX() you get a reference to the ENGINE. When it is added
to the ENGINE list the reference count is incremented. When you call
ENGINE_free() the count is decremented and the ENGINE is freed only if the
reference count is zero.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

aerowolf | 4 Jan 04:50 2011
Picon

Re: Non empty error stack failing non-blocking SSL IO

If your program ignores the error queue, your program is doing the equivalent of not checking errno after
every system call.  The program is required to deal with the error queue, because it is OpenSSL's only
mechanism for informing the application code of the wide variety of potential protocol and
authentication issues.

The program should absolutely not be doing the same things in the cases of SSL_get_error() returning
SSL_ERROR_SSL and SSL_WANT_READ.  (It may be that someone missed a break statement at the end of one case
and it's falling through to the next.)  Either way, this is not anomalous behavior on OpenSSL's part.

After you call SSL_read() and get zero bytes, you must determine why you got zero bytes, and that's where you
should call SSL_get_error(). If it returns SSL_ERROR_SSL, you must check the error queue to determine
exactly why the SSL session is in an error state.  (The reason for the queue is because you're supposed to be
interested in and handle every error that comes up in the process, not merely the most-recent.)

-Kyle H

On Mon, Jan 3, 2011 at 4:22 AM, Uri Simchoni <uris <at> ctera.com> wrote:
> I’m using OpenSSL 0.9.8i, and have noticed the following scenario:
>
> -          Some OpenSSL crypto function returns with an error, leaving a
> description of the error on the error queue
>
> -          The application neglects to call ERR_clear_error()
>
> -          SSL_read() is then called on a non-blocking socket and returns
> because there’s no input available
>
> -          Calling SSL_get_error() returns SSL_ERROR_SSL instead of
> SSL_ERROR_WANT_READ, because the error queue is not empty.
>
>  
>
> Would it be possible to modify the code so that blocking socket takes
> precedence over the error queue?
>
> If not, what is the recommended programming practice with non-blocking
> sockets?
>
> -          ensure the everybody call ERR_clear_error() after an error
>
> -          call ERR_clear_error() before SSL read/write (but if that’s
> recommended why isn’t it inside SSL_read/SSL_write)
>
>  
>
> Thanks,
>
> Uri
>
>  

Attachment (smime.p7s): application/pkcs7-signature, 5446 bytes

Gmane