encryption.openssl.devel (date)

Re: [openssl.org #181] Makefile enhancement requests

Date: Sat Feb 01 00:18:13 2003
From: "Aleksi Suhonen via RT" <rt@xxxxxxxxxxx>

In-reply-to: <rt-181@xxxxxxxxxxx>
References: <rt-181@xxxxxxxxxxx>


Hello,

Quote from "Richard Levitte via RT":
} > > * When linking the libraries, make sure that libssl finds libcrypto
} > > and that they both find all their external dependencies at run time.
} > > This is accomplished by the -R, -rpath or --rpath flags which behave
} > > just like the -L flag. It is not necessary when all libraries can be
} > > found using the default paths. To recap: giving --prefix to config
} > > should automatically add -R${prefix}/lib and giving -L... to config
} > > should automatically generate the same -R...
} > > (Which flag to use depends on which compiler one is using.)

} Isn't there a case when the -L and the -R arguments have different
} arguments?

Yes, in hind sight I see I made a generalization. Normally one tries to
link against libraries that are already installed, in which case the -L
and -R match, but in your case you are linking against libraries that
haven't been installed yet.

} For example, the openssl program is linked against libssl and libcrypto
} in the parent directory, so the linking command includes -L.. .
} However, the -R switch would indicate where the libraries are found by
} default, so adding such a switch should look like this, roughly:
} -R${prefix}/lib, even when we have a -L.. .  Right?

Yes, that is correct.

-L tells the linker where to find the libraries when linking and
-R tells the dynamic run-time linker where to find the libraries when
running the program.

This is also true when trying to dynamically link a library that wants
to dynamically link another library. (E.g. libssl uses libcrypto, so
when creating libssl.so the linker should be told where libcrypto.so
will finally reside when installed.)

To check that everything works the way it should, try installing
openssl in /some/weird/directory and then compiling some other piece
of software, like openssh, against it.

To debug the link paths, use ldd -v [library | executable]. On
Solaris you should also give the flag -s to ldd to see the verbose
search path. I couldn't find a similar flag in the Linux Debian
Unstable ldd. I couldn't find a linker debugger on the OSF1 (Tru64)
machine I have access to and the HP-UX machine I have access to is
down at the moment.

--
	Aleksi Suhonen

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@xxxxxxxxxxx
Automated List Manager                           majordomo@xxxxxxxxxxx



[openssl.org #488] BUG REPORT: openbsd 3.2, openssl 0.9.7 fails to compile

Date: Sat Feb 01 09:59:26 2003
From: "James Nobis via RT" <rt@xxxxxxxxxxx>

In-reply-to: <rt-488@xxxxxxxxxxx>
References: <rt-488@xxxxxxxxxxx>

i saw the latest openssl so I decided to compile it
before compile the new php and apache, however it
fails to compile with the following:

gcc -E -DOUT asm/dx86unix.cpp | as -o asm/dx86-out.o
des-586.s: Assembler messages:
des-586.s:2458: Error: Unimplemented segment type
135296 in
parse_operand(.L009cbc_enc_jmp_table-.L008PIC_point(%edx))
des-586.s:2645: Error: Unimplemented segment type
135296 in
parse_operand(.L033cbc_enc_jmp_table-.L032PIC_point(%edx))
*** Error code 1

Stop in /home/quel/openssl-0.9.7/crypto/des (line 96
of Makefile.ssl).
*** Error code 1

Stop in /home/quel/openssl-0.9.7/crypto (line 73 of
Makefile.ssl).
*** Error code 1

Stop in /home/quel/openssl-0.9.7 (line 225 of
Makefile).

attached is the output of ./config though I do not
believe it will be helpful

-quel@xxxxxxx



__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@xxxxxxxxxxx
Automated List Manager                           majordomo@xxxxxxxxxxx



[openssl.org #488] BUG REPORT: openbsd 3.2, openssl 0.9.7 fails to compile

Date: Sat Feb 01 12:48:05 2003
From: "Stephen Henson via RT" <rt@xxxxxxxxxxx>

In-reply-to: <rt-488@xxxxxxxxxxx>
References: <rt-488@xxxxxxxxxxx>

[quelrod@xxxxxxxxx - Sat Feb  1 11:00:48 2003]:

> i saw the latest openssl so I decided to compile it
> before compile the new php and apache, however it
> fails to compile with the following:
> 
> gcc -E -DOUT asm/dx86unix.cpp | as -o asm/dx86-out.o
> des-586.s: Assembler messages:
> des-586.s:2458: Error: Unimplemented segment type
> 135296 in
> parse_operand(.L009cbc_enc_jmp_table-.L008PIC_point(%edx))
> des-586.s:2645: Error: Unimplemented segment type
> 135296 in
> parse_operand(.L033cbc_enc_jmp_table-.L032PIC_point(%edx))
> *** Error code 1
> 

This is covered in the FAQ.

Steve.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@xxxxxxxxxxx
Automated List Manager                           majordomo@xxxxxxxxxxx



Re: [openssl.org #359] Calling SSL_read and SSL_write with non-empty error stack may cause an error

Date: Sat Feb 01 15:05:14 2003
From: Ben Laurie <ben@xxxxxxxxxxxxx>

References: <rt-359-3720.3.38446694872758@xxxxxxxxxxx> <3E3AC8F3.4070901@xxxxxxxxxxxxx> <Pine.WNT.4.50.0301312357430.192-100000@BUENO>

Arne Ansper wrote:

I just checked. Seems that SSL_CTX_use_certificate_chain_file has a same
problem. Other uses of ERR_peek_error seem to be immune to the old entries
in error stack.


One theory is that applications should not call arbitrary OpenSSL
functions while there is stuff in the error queue.

A second theory is that OpenSSL should always clear the error queue by
calling ERR_clear_error() if stuff left in the error queue might cause
confusion later.

How can it cause confusion (I think I missed something here)? You should
only look at the error stack if you got an error, surely?


There are places (three if I remember correctly) in OpenSSL that look at
the error stack and when there is something decide that something went
wrong.

Like I say, they should only do this if there was an error reported, surely?

When the ticket was opened I proposed that one should not use the contents
of the error stack for anything else other than reporting the error. If
you must differentiate between two types of errors that may happen in some
function, add an additional parameter to the function (of type int* for
example) that can carry out the special error condition from the function.

I guess that's an alternative, but I don't see why it should be needed.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@xxxxxxxxxxx
Automated List Manager                           majordomo@xxxxxxxxxxx



Re: [openssl.org #359] Calling SSL_read and SSL_write with non-empty error stack may cause an error

Date: Sat Feb 01 20:21:40 2003
From: Arne Ansper <arne@xxxxxxxxxxxx>

In-reply-to: <3E3BE1FB.2080504@xxxxxxxxxxxxx>
References: <rt-359-3720.3.38446694872758@xxxxxxxxxxx> <3E3AC8F3.4070901@xxxxxxxxxxxxx> <Pine.WNT.4.50.0301312357430.192-100000@BUENO> <3E3BE1FB.2080504@xxxxxxxxxxxxx>


> Like I say, they should only do this if there was an error reported, surely?

No. Take a look at the SSL_CTX_use_certificate_chain_file:

    ret=SSL_CTX_use_certificate(ctx,x);
    if (ERR_peek_error() != 0)
        ret = 0;  /* Key/certificate mismatch doesn't imply ret==0 ... */

> I guess that's an alternative, but I don't see why it should be needed.

To make it explicit. Right now the function that is called does not know
that the error code it puts into error stack will be used to make some
decision by caller. There is implicit dependency and it is bad for code
maintenance.

Arne

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@xxxxxxxxxxx
Automated List Manager                           majordomo@xxxxxxxxxxx



Re: [CVS] OpenSSL: openssl/crypto/engine/ engine.h openssl/crypto/evp/ c_a...

Date: Sun Feb 02 07:15:22 2003
From: Richard Levitte - VMS Whacker <levitte@xxxxxxxxxxxxxx>

In-reply-to: <20030201205530.434F427F66F@xxxxxxxxxxxxxxxxxx>
References: <20030201205530.434F427F66F@xxxxxxxxxxxxxxxxxx>

In message <20030201205530.434F427F66F@xxxxxxxxxxxxxxxxxx> on Sat,  1 Feb 2003 21:55:30 +0100 (CET), "Ben Laurie" <ben@xxxxxxxxxxx> said:

ben>   OpenSSL CVS Repository
ben>   http://cvs.openssl.org/
ben>   ____________________________________________________________________________
ben> 
ben>   Server: cvs.openssl.org                  Name:   Ben Laurie
ben>   Root:   /e/openssl/cvs                   Email:  ben@xxxxxxxxxxx
ben>   Module: openssl                          Date:   01-Feb-2003 21:55:30
ben>   Branch: HEAD                             Handle: 2003020120552900
ben> 
ben>   Modified files:
ben>     openssl/crypto/engine   engine.h
ben>     openssl/crypto/evp      c_all.c
ben> 
ben>   Log:
ben>     Fix warning.
ben> 
ben>   Summary:
ben>     Revision    Changes     Path
ben>     1.49        +3  -0      openssl/crypto/engine/engine.h
ben>     1.13        +1  -0      openssl/crypto/evp/c_all.c
ben>   ____________________________________________________________________________
ben> 
ben>   patch -p0 <<'@@ .'
ben>   Index: openssl/crypto/engine/engine.h
ben>   ============================================================================
ben>   $ cvs diff -u -r1.48 -r1.49 engine.h
ben>   --- openssl/crypto/engine/engine.h	30 Jan 2003 17:39:21 -0000	1.48
ben>   +++ openssl/crypto/engine/engine.h	1 Feb 2003 20:55:29 -0000	1.49
ben>   @@ -685,6 +685,9 @@
ben>     * values. */
ben>    void *ENGINE_get_static_state(void);
ben>    
ben>   +#if defined(__OpenBSD__) || defined(__FreeBSD__)
ben>   +void ENGINE_setup_bsd_cryptodev(void);
ben>   +#endif
ben>    
ben>    /* BEGIN ERROR CODES */
ben>    /* The following lines are auto generated by the script mkerr.pl. Any changes

Hmm?  What warning do you get if something is declared but never
defined?

-- 
Richard Levitte   \ Spannvägen 38, II \ LeViMS@xxxxxxxxxxxxxx
Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
                    \      SWEDEN       \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis                -- poei@xxxxxxx
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@xxxxxxxxxxx
Automated List Manager                           majordomo@xxxxxxxxxxx



Re: [CVS] OpenSSL: openssl/crypto/engine/ engine.h openssl/crypto/evp/ c_a...

Date: Mon Feb 03 15:15:25 2003
From: Ben Laurie <ben@xxxxxxxxxxxxx>

References: <20030201205530.434F427F66F@xxxxxxxxxxxxxxxxxx> <20030202.081155.28792340.levitte@xxxxxxxxxxxxxx>

Richard Levitte - VMS Whacker wrote:
In message <20030201205530.434F427F66F@xxxxxxxxxxxxxxxxxx> on Sat,  1 Feb 2003 21:55:30 +0100 (CET), "Ben Laurie" <ben@xxxxxxxxxxx> said:

ben>   OpenSSL CVS Repository
ben>   http://cvs.openssl.org/
ben>   ____________________________________________________________________________
ben> ben> Server: cvs.openssl.org Name: Ben Laurie
ben>   Root:   /e/openssl/cvs                   Email:  ben@xxxxxxxxxxx
ben>   Module: openssl                          Date:   01-Feb-2003 21:55:30
ben>   Branch: HEAD                             Handle: 2003020120552900
ben> ben> Modified files:
ben>     openssl/crypto/engine   engine.h
ben>     openssl/crypto/evp      c_all.c
ben> ben> Log:
ben>     Fix warning.
ben> ben> Summary:
ben>     Revision    Changes     Path
ben>     1.49        +3  -0      openssl/crypto/engine/engine.h
ben>     1.13        +1  -0      openssl/crypto/evp/c_all.c
ben>   ____________________________________________________________________________
ben> ben> patch -p0 <<'@@ .'
ben>   Index: openssl/crypto/engine/engine.h
ben>   ============================================================================
ben>   $ cvs diff -u -r1.48 -r1.49 engine.h
ben>   --- openssl/crypto/engine/engine.h	30 Jan 2003 17:39:21 -0000	1.48
ben>   +++ openssl/crypto/engine/engine.h	1 Feb 2003 20:55:29 -0000	1.49
ben>   @@ -685,6 +685,9 @@
ben>     * values. */
ben>    void *ENGINE_get_static_state(void);
ben> ben> +#if defined(__OpenBSD__) || defined(__FreeBSD__)
ben>   +void ENGINE_setup_bsd_cryptodev(void);
ben>   +#endif
ben> ben> /* BEGIN ERROR CODES */
ben>    /* The following lines are auto generated by the script mkerr.pl. Any changes

Hmm?  What warning do you get if something is declared but never
defined?

Huh? The warning is that it is called but not declared.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@xxxxxxxxxxx
Automated List Manager                           majordomo@xxxxxxxxxxx



patch to 0.9.7 -performacne

Date: Mon Feb 03 15:16:32 2003
From: David Brumley <dbrumley@xxxxxxxxxxxx>

Hi,
I wrote awhile back about a patch to 0.9.7 in rsa_eay.c, but never heard
back.  Is this the wrong forum?

The patch is to rsa_eay.c (attached), which adds cacheing of the
montgomery context for n (in addition to p and q).  This patch improves
efficiency...normally the verify at the end of CRT does not use a cached
context.  In 0.9.7 right now, R^{-1} (Ri) for n must be recomputed on
every decryption, an expensive operation.

-david
--- rsa_eay.c.orig	2003-01-20 19:16:46.000000000 -0800
+++ rsa_eay.c	2003-01-20 19:17:54.000000000 -0800
@@ -533,6 +533,31 @@
 			if (bn_mont_ctx)
 				BN_MONT_CTX_free(bn_mont_ctx);
 			}
+
+		if (rsa->_method_mod_n == NULL)
+			{
+			BN_MONT_CTX* bn_mont_ctx;
+			if ((bn_mont_ctx=BN_MONT_CTX_new()) == NULL)
+				goto err;
+			if (!BN_MONT_CTX_set(bn_mont_ctx,rsa->n,ctx))
+				{
+				BN_MONT_CTX_free(bn_mont_ctx);
+				goto err;
+				}
+			if (rsa->_method_mod_n == NULL) /* other thread may have finished first */
+				{
+				CRYPTO_w_lock(CRYPTO_LOCK_RSA);
+				if (rsa->_method_mod_n == NULL)
+					{
+					rsa->_method_mod_n = bn_mont_ctx;
+					bn_mont_ctx = NULL;
+					}
+				CRYPTO_w_unlock(CRYPTO_LOCK_RSA);
+				}
+			if (bn_mont_ctx)
+				BN_MONT_CTX_free(bn_mont_ctx);
+			}
+
 		}
 		
 	if (!BN_mod(&r1,I,rsa->q,ctx)) goto err;
@@ -565,7 +590,7 @@
 
 	if (rsa->e && rsa->n)
 		{
-		if (!rsa->meth->bn_mod_exp(&vrfy,r0,rsa->e,rsa->n,ctx,NULL)) goto err;
+		if (!rsa->meth->bn_mod_exp(&vrfy,r0,rsa->e,rsa->n,ctx,rsa->_method_mod_n)) goto err;
 		/* If 'I' was greater than (or equal to) rsa->n, the operation
 		 * will be equivalent to using 'I mod n'. However, the result of
 		 * the verify will *always* be less than 'n' so we don't check

RE: [openssl.org #463] PATCH

Date: Mon Feb 03 15:23:17 2003
From: "Shklover, Vladimir" <vshklover@xxxxxxxx>

Maybe it will change when all legal issues are resolved, I hope.
For now, I want to be sure that all possible combinations for aix 
shared build are tested (so far successfully) and when corresponding
changes could be included into the next release? I hope everything is OK.

Vladimir

-----Original Message-----
From: Rich Salz via RT [mailto:rt@xxxxxxxxxxx]
Sent: Wednesday, January 22, 2003 11:15 AM
To: Shklover, Vladimir
Cc: openssl-dev@xxxxxxxxxxx
Subject: Re: [openssl.org #463] PATCH



> 2)Perhaps I did not make it clear but our policy is not to include 
> any cryptographic software directly into our applications.

You might want to reconsider this policy.  Do you expect much revenue 
from the banned country list?  Is it worth the development and support 
cost of keeping track with openssl versions?  Are you sure that you are 
not in violation if you say "install openssl on your own"?  (The answer 
to that last question *used* to be:  yes, you are in violation.  Now, I 
don't know.)

	/r$
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@xxxxxxxxxxx
Automated List Manager                           majordomo@xxxxxxxxxxx



Re: [openssl.org #359] Calling SSL_read and SSL_write with non-empty error stack may cause an error

Date: Mon Feb 03 15:24:28 2003
From: moeller@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx (Bodo Moeller)

In-reply-to: <Pine.WNT.4.50.0302012217100.1848-100000@BUENO >
References: <3E3BE1FB.2080504@xxxxxxxxxxxxx> <Pine.WNT.4.50.0302012217100.1848-100000@BUENO >

Arne Ansper <arne@xxxxxxxxxxxx>:

>> Like I say, they should only do this if there was an error reported, surely?

> No. Take a look at the SSL_CTX_use_certificate_chain_file:
> 
>     ret=SSL_CTX_use_certificate(ctx,x);
>     if (ERR_peek_error() != 0)
>         ret = 0;  /* Key/certificate mismatch doesn't imply ret==0 ... */

Actually I think this is a bug in SSL_CTX_use_certificate() -- if it
intentionally ignores an error returned by X509_check_private_key(),
it should call ERR_clear_error().

The reason why I did not fix this when I looked at this some time ago
is some rather weird code in ssl_set_cert(), the function used by
SSL_CTX_use_certificate() from which X509_check_private_key() is
called.  (If you look at ssl_set_cert(), you'll see that it switches
from SSL_PKEY_DH_RSA to SSKL_PKEY_DH_DSA and the other way around,
which does not appear to make much sense.)  Investigating this has
been on my "to do" list for a while.  Once this has been resolved,
the lines

     if (ERR_peek_error() != 0)
        ret = 0;  /* Key/certificate mismatch doesn't imply ret==0 ... */

can be removed from SSL_CTX_use_certificate_chain_file().


-- 
Bodo Möller <moeller@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@xxxxxxxxxxx
Automated List Manager                           majordomo@xxxxxxxxxxx



RE: [openssl.org #479] support version independent upgrade

Date: Mon Feb 03 15:28:13 2003
From: "Jim Sahaj" <jims@xxxxxxxxxxxx>

Actually, I'd prefer that I wouldn't have to relink and redistribute my application every
time a security patch comes out for OpenSSL.  I haven't seen any issues in our application
upgrading from 0.9.6 to 0.9.7 using this non version technique on our local development nodes.

The version technique doesn't just prevent backward compatibility but it 
prevents users from getting potential security upgrades that *may* work
just fine.  It's definitely not a desirable distribution scenario as it sits now. 
It forces developers to do relinks and redistribute whether they're needed or not.

-----Original Message-----
From: Richard Levitte - VMS Whacker [mailto:levitte@xxxxxxxxxxxxxx]
Sent: Monday, January 27, 2003 2:10 PM
To: openssl-dev@xxxxxxxxxxx; rt@xxxxxxxxxxx
Cc: Jim Sahaj
Subject: Re: [openssl.org #479] support version independent upgrade 


In message <rt-479-3593.13.1951656450017@xxxxxxxxxxx> on Mon, 27 Jan 2003 22:40:24 +0100 (MET), " via RT" <rt@xxxxxxxxxxx> said:

rt> Currently, on many Unix platforms I link my application against 
rt> libssl.so and libcrypto.so. Typically, these are links set to resolve 
rt> down to the versioned types of these files, like libssl.so.0.9.7 and 
rt> libcrypto.so.0.9.7.  The internal names of these shared objects 
rt> include the major and minor version so even though I link against the 
rt> shared objects without the version, such as libssl.so, my application 
rt> becomes tied to the versioned shared objects at link time, for 
rt> instance libssl.so.0.9.7.

There's a reason: until OpenSSL 1, we don't guarantee backward binary
compatibility.  There are technical reasons for this, like the need to
make changes to published structures (it may be argued that it
shouldn't be needed, but to achieve such flexibility, we either need
to hide them (which would require huge changes for everyone) or redo
them in such a way that they become rather generic) and other stuff.

Because of this, we're forced to do what we currently do with shared
libraries.  Perhaps you'd prefer that your applications crash
mysteriously and in an unrecoverable manner?

-- 
Richard Levitte   \ Spannvägen 38, II \ LeViMS@xxxxxxxxxxxxxx
Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
                    \      SWEDEN       \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis                -- poei@xxxxxxx
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@xxxxxxxxxxx
Automated List Manager                           majordomo@xxxxxxxxxxx



Re: [CVS] OpenSSL: openssl/crypto/engine/ engine.h openssl/crypto/evp/ c_a...

Date: Mon Feb 03 15:29:33 2003
From: Richard Levitte - VMS Whacker <levitte@xxxxxxxxxxxxxx>

In-reply-to: <3E3D106E.8050900@xxxxxxxxxxxxx>
References: <20030201205530.434F427F66F@xxxxxxxxxxxxxxxxxx> <20030202.081155.28792340.levitte@xxxxxxxxxxxxxx> <3E3D106E.8050900@xxxxxxxxxxxxx>

In message <3E3D106E.8050900@xxxxxxxxxxxxx> on Sun, 02 Feb 2003 12:34:54 +0000, Ben Laurie <ben@xxxxxxxxxxxxx> said:

ben> Richard Levitte - VMS Whacker wrote:
ben> > Hmm?  What warning do you get if something is declared but never
ben> > defined?
ben> 
ben> Huh? The warning is that it is called but not declared.

Ah.  Sorry, my brain was apparently out for lunch or something.

-- 
Richard Levitte   \ Spannvägen 38, II \ LeViMS@xxxxxxxxxxxxxx
Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
                    \      SWEDEN       \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis                -- poei@xxxxxxx
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@xxxxxxxxxxx
Automated List Manager                           majordomo@xxxxxxxxxxx



[openssl.org #451] SX6 port

Date: Mon Feb 03 15:33:01 2003
From: "Stephen Henson via RT" <rt@xxxxxxxxxxx>

In-reply-to: <rt-451@xxxxxxxxxxx>
References: <rt-451@xxxxxxxxxxx>

[wendyp@xxxxxxxx - Sat Feb  1 00:59:01 2003]:

> $ ./openssl req -x509 -new -nodes -out sscert.pem -rand /tmp/somefile
> Generating a 1024 bit RSA private key
> ............++++++
> ..............................++++++
> writing new private key to 'privkey.pem'
> -----
> You are about to be asked to enter information that will be
> incorporated
> into your certificate request.
> What you are about to enter is what is called a Distinguished Name or
> a DN.
> There are quite a few fields but you can leave some blank
> For some fields there will be a default value,
> If you enter '.', the field will be left blank.
> -----
> Country Name (2 letter code) [AU]:
> State or Province Name (full name) [Some-State]:
> Locality Name (eg, city) []:
> Organization Name (eg, company) [Internet Widgits Pty Ltd]:
> Organizational Unit Name (eg, section) []:
> Common Name (eg, YOUR name) []:
> Email Address []:
> 
> 

OK so that seems to work. Maybe its just when x509 does it.

Can you try: 

openssl req -new -nodes -out req.pem -rand /tmp/somefile

then 

openssl x509 -req -in req.pem -out sscert.pem -signkey privkey.pem

if that second command dumps core then a stack trace under a debugger
would help a lot.

Thanks, Steve.


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@xxxxxxxxxxx
Automated List Manager                           majordomo@xxxxxxxxxxx



Re: no-err option

Date: Mon Feb 03 15:36:31 2003
From: Bodo Moeller <moeller@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>

In-reply-to: <OF98DDEE62.17B36444-ONC1256CBE.0035653D@xxxxxxxxxx>; from MWITZEL@xxxxxxxxxx on Thu, Jan 30, 2003 at 11:02:33AM +0100
References: <OF98DDEE62.17B36444-ONC1256CBE.0035653D@xxxxxxxxxx>

On Thu, Jan 30, 2003 at 11:02:33AM +0100, Martin Witzel wrote:

> This refers to 0.9.7. I have not verified it with earlier versions
> 
> When I setup the build process with the 'config no-err' option, I get a lot
> of _link_ errors in the apps directory, because the complete crypto/err
> directory is skipped in the build process (compliments of 'Configure' which
> modifies Makefile.org) and the applications which reference error functions
> do not find them.
[...]
> There are two options to make no-err work: go over the apps code which
> references error functions and exclude all references there when no-err is
> on. Then the code in crypto/err may be safely excluded altogether during
> the build process.  OR correct the compiler switches in crypto/err to make
> crypto/err compile and link some stripped down version of the error
> routines; in this case we could leave the references to functions in
> crypto/err in the apps code. The code which they call would not do much,
> however.

Another option is to abandon no-err instead of trying to make it work ...
some code systematically relies on the error queue being available
(look for ERR_peek_error() and ERR_peek_last_error()).

Do you think that there is a strong reason for keeping (and repairing)
no-err?


-- 
Bodo Möller <moeller@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@xxxxxxxxxxx
Automated List Manager                           majordomo@xxxxxxxxxxx



openssl req prompting behavior

Date: Mon Feb 03 15:37:25 2003
From: "Joel Daniels" <joeld@xxxxxxxxxxxx>

The "openssl req" command, when set up to prompt for the Distinguished Name,
uses fgets() to read the Distinguished Name fields.  This means that if
someone uses the backspace key, a 0x08 character is inserted wherever they
typed the backspace key.  Would it be possible/easy to add support for the
GNU readline library to avoid this problem, at least on Linux machines?

   - Joel Daniels

P. S.  I am not on the openssl-dev list, so please CC me in on any replies.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@xxxxxxxxxxx
Automated List Manager                           majordomo@xxxxxxxxxxx



[PATCH] version independent link on solaris

Date: Mon Feb 03 15:41:10 2003
From: "Jim Sahaj" <jims@xxxxxxxxxxxx>

The following allows for a version independent link on Solaris. Before, when I linked against libssl.so and libcrypto.so
there would be a dependency between libssl.so and libcrypto.so.0.9.7 because the dynamic section name contained 
the major and minor versions.
I removed the versions from the shared object's dynamic section names so that linking against the version independent
shared objects will work without any version dependencies.
-----
diff -e old new
ed - Makefile.org << '-*-END-*-'
363c
			-h lib$$i.so \
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@xxxxxxxxxxx
Automated List Manager                           majordomo@xxxxxxxxxxx



[PATCH] version independent link on unixware7

Date: Mon Feb 03 15:42:13 2003
From: "Jim Sahaj" <jims@xxxxxxxxxxxx>

The following allows for a version independent link on Unixware7. Before, when I linked against libssl.so and libcrypto.so
there would be a dependency between libssl.so and libcrypto.so.0.9.7 because the dynamic section name contained 
the major and minor versions.
I removed the versions from the shared object's dynamic section names so that linking against the version independent
shared objects will work without any version dependencies.

---
diff -e old new
ed - Makefile.org << '-*-END-*-'
403c
			-h lib$$i.so \
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@xxxxxxxxxxx
Automated List Manager                           majordomo@xxxxxxxxxxx



RE: [openssl.org #463] PATCH

Date: Mon Feb 03 15:45:55 2003
From: "Shklover, Vladimir" <vshklover@xxxxxxxx>

1)I checked "env OBJECT_MODE=64 make" in openssl-0.9.7-snapshot... for 2 cases:
  -automatically configured by  "./Configure aix64-cc ... shared",
   using *.exp files
  -when Makefile.org is modified to use -bautoexp instead of using
   *.exp files (the changes are the same which you asked for 32 bit)
   and then "./Configure aix64-cc ... shared" is run 
In both cases static and shared libraries were successfully built.
As I said earlier, usual "make" can also work for aix64-cc, with *.exp
(ld -b64 -r -o ..., nm -X 64 ...) as well as with -bautoexp (I have already 
sent you corresponding changes). Now, whether you want to build by usual 
"make", "env OBJECT_MODE=64 make", with *.exp or -bautoexp, is up to you. 
Does it finally cover all possible combinations you wanted to test?

*******************Mainly for US based developers******************

2)Perhaps I did not make it clear but our policy is not to include 
any cryptographic software directly into our applications. The reason 
is that one of the latest US laws prohibits exporting cryptography
to certain countries (especially those supporting terrorism). OpenSSL 
itself, as I understand, is legally OK for public availability because 
it is non-commersial and already posted on the Web. However, we are not
in the position to export it (although using it is always OK). This, 
in fact, is said in references from openssl README files

http://www.bis.doc.gov/Encryption/PubAvailEncSourceCodeNofify.html 
http://w3.access.gpo.gov/bis/ear/pdf/740.pdf Section 740.13(e), p.25

Therefore, the acceptable legal solution for us is to build application 
which can use openssl but in such a way that the user himself would be 
responsible for installation of openssl, creating libssl.so & libcrypto.so 
which would then be dynamically loaded by our application. Those who started 
before the mentioned law was adopted, didn't have to worry at that time. 
Of course, you can say that openssl is accessible to everyone from the Web 
but that is another question because you are allowed to export your own, 
non-commersial product (although I am not a lawyer to give any legal 
conclusion). Maybe, we will add some addiditional measures which would not 
allow unauthorized users to use SSL in our software. Anyway, this our
policy based on the law and for now it remains in effect. Do I understand
that binary compatibility for shared libraries is expected since 1.0 release?

Vladimir

-----Original Message-----
From: Andy Polyakov via RT [mailto:rt@xxxxxxxxxxx]
Sent: Tuesday, January 21, 2003 3:14 PM
To: Shklover, Vladimir
Cc: openssl-dev@xxxxxxxxxxx
Subject: Re: [openssl.org #463] PATCH



> 1)I just got aix64-cc shared build succeed with -bautoexp. It was possible to
> modify Makefile pretty similar to aix43-cc.
  ^^^^^^ But the challenge is to construct the rule which can be
parametrized through configure line. But as already mentioned, I'd
appreciate if you could verify if 'env OBJECT_MODE=64 make' works with
snapshot configured with './Configure aix64-cc shared'.

> 2)You are right, the version openssl-0.9.7 did not contain 0.9.7
> extention for aix but in my changes (which appear to be in snapshot
> version) I included these extentions to be consistent with other
> platforms where shared build contain these extention.

Right! Without access I'm bound to miss such things:-)

> I made experimental builds without extentions just for myself;
> I didn't send you such changes to Makefile. The reason I did that for
> myself is that if you link a module, say module.so with soname
                                                          ^^^^^^ Does
AIX support soname or similar option? There was nothing of that sort in
ld manual page I've found on the web...

> libcrypto.so.0.9.6, you can not then dynamically load it with
> libcrypto.so.0.9.7.

And that is *intentional*! We don't want users to load 0.9.7 library
into an application originally linked with 0.9.6.

> (we are not physically including libssl.so... & libcrypto.so... into
> our software and SSL connection will work if the user installs openssl
> himself).

You should *not* rely on this and should consider providing copy of
shared libs with your application. Yes, it might appear a bit
meaningless, you could as well link it statically, but that's the way
it. Binary compatibility is *not* provided across OpenSSL releases and
interchanging .so modules *might* result in unpredictable result and it
will be hell to troubleshoot. A.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@xxxxxxxxxxx
Automated List Manager                           majordomo@xxxxxxxxxxx



RSA Methods based on cyptoAPI

Date: Mon Feb 03 15:46:50 2003
From: Aonzo Emanuele <Emanuele.Aonzo@xxxxxxxx>

Hi,
I'm trying to develop some RSA methods based on Microsoft CryptoAPI.
I need to know if exists some open source code or example for the
implementation of rsa_priv_enc and rsa_priv_dec unsing the private key on a
smart card.

Thank you very much
Emanuele
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@xxxxxxxxxxx
Automated List Manager                           majordomo@xxxxxxxxxxx



[PATCH]shared objects for 64bit AIX

Date: Mon Feb 03 15:47:43 2003
From: "Jim Sahaj" <jims@xxxxxxxxxxxx>

The patch below builds shared objects for 64bit AIX for openssl097.
-------------------------
diff -e old new:
ed - Configure << '-*-END-*-'
443c
"aix64-cc",   "cc:-O -DAIX -DB_ENDIAN -qmaxmem=16384 -q64::(unknown):::SIXTY_FOUR_BIT_LONG RC4_CHAR::::::::::dlfcn:aix64-shared::-b64::ranlib -X64:-X 64",
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@xxxxxxxxxxx
Automated List Manager                           majordomo@xxxxxxxxxxx



[openssl.org #489] patch to 0.9.7 -performacne

Date: Mon Feb 03 16:16:17 2003
From: "David Brumley via RT" <rt@xxxxxxxxxxx>

In-reply-to: <rt-489@xxxxxxxxxxx>
References: <rt-489@xxxxxxxxxxx>

Hi,
I wrote awhile back about a patch to 0.9.7 in rsa_eay.c, but never heard
back.  Is this the wrong forum?

The patch is to rsa_eay.c (attached), which adds cacheing of the
montgomery context for n (in addition to p and q).  This patch improves
efficiency...normally the verify at the end of CRT does not use a cached
context.  In 0.9.7 right now, R^{-1} (Ri) for n must be recomputed on
every decryption, an expensive operation.

-david
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@xxxxxxxxxxx
Automated List Manager                           majordomo@xxxxxxxxxxx



Re: patch to 0.9.7 -performacne

Date: Mon Feb 03 16:20:20 2003
From: Richard Levitte - VMS Whacker <levitte@xxxxxxxxxxxxxx>

In-reply-to: <1043351591.1106.6.camel@xxxxxxxxxxxxxxxxxxxxxxx>
References: <1043351591.1106.6.camel@xxxxxxxxxxxxxxxxxxxxxxx>

In message <1043351591.1106.6.camel@xxxxxxxxxxxxxxxxxxxxxxx> on 23 Jan 2003 11:53:09 -0800, David Brumley <dbrumley@xxxxxxxxxxxx> said:

dbrumley> I wrote awhile back about a patch to 0.9.7 in rsa_eay.c, but
dbrumley> never heard back.  Is this the wrong forum?

It's in our RT database, it just hasn't been dealt with yet...

-- 
Richard Levitte   \ Spannvägen 38, II \ LeViMS@xxxxxxxxxxxxxx
Redakteur@Stacken  \ S-168 35  BROMMA  \ T: +46-8-26 52 47
                    \      SWEDEN       \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis                -- poei@xxxxxxx
Member of the OpenSSL development team: http://www.openssl.org/

Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@xxxxxxxxxxx
Automated List Manager                           majordomo@xxxxxxxxxxx



Re: RSA Methods based on cyptoAPI

Date: Mon Feb 03 17:22:33 2003
From: "Dr. Stephen Henson" <steve@xxxxxxxxxxx>

In-reply-to: <A35076F7A9C6F8428FE93EBB81B005DE011E9F42@xxxxxxxxxxxxxxxxxxx>
References: <A35076F7A9C6F8428FE93EBB81B005DE011E9F42@xxxxxxxxxxxxxxxxxxx>

On Fri, Jan 24, 2003, Aonzo Emanuele wrote:

> Hi,
> I'm trying to develop some RSA methods based on Microsoft CryptoAPI.
> I need to know if exists some open source code or example for the
> implementation of rsa_priv_enc and rsa_priv_dec unsing the private key on a
> smart card.
> 

I've some private code that does this but nothing released.

CryptoAPI does not have an equivalent of rsa_priv_enc. It does however have an
equivalent to rsa_sign which you can get to in a roundabout way by creating
appopriate messages digest contexts and setting the digest value, then signing
the context. This will give you enough for general message digest signing
(e.g. S/MIME, certificate signing) and SSL client authentication.

rsa_priv_dec in theory is provided by CryptDecrypt() and this does work for
some CSPs: the enhanced CSP can handle this. However many smart card
CSPs do not implement the necessary functionality. Workarounds exist if
the CSP handles the conventional key exchange using CryptImportKey() provided
you want a standard key size.

Steve.
--
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.demon.co.uk/
Email: shenson@xxxxxxxxxxxxxxxxxxxxxxxxxxx, PGP key: via homepage.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@xxxxxxxxxxx
Automated List Manager                           majordomo@xxxxxxxxxxx



Re: [openssl.org #451] SX6 port

Date: Mon Feb 03 17:59:49 2003
From: "Wendy Palm via RT" <rt@xxxxxxxxxxx>

In-reply-to: <rt-451@xxxxxxxxxxx>
References: <rt-451@xxxxxxxxxxx>



Stephen Henson via RT wrote:

> [wendyp@xxxxxxxx - Sat Feb  1 00:59:01 2003]:
> 
> 
>>$ ./openssl req -x509 -new -nodes -out sscert.pem -rand /tmp/somefile
>>Generating a 1024 bit RSA private key
>>............++++++
>>..............................++++++
>>writing new private key to 'privkey.pem'
>>-----
>>You are about to be asked to enter information that will be
>>incorporated
>>into your certificate request.
>>What you are about to enter is what is called a Distinguished Name or
>>a DN.
>>There are quite a few fields but you can leave some blank
>>For some fields there will be a default value,
>>If you enter '.', the field will be left blank.
>>-----
>>Country Name (2 letter code) [AU]:
>>State or Province Name (full name) [Some-State]:
>>Locality Name (eg, city) []:
>>Organization Name (eg, company) [Internet Widgits Pty Ltd]:
>>Organizational Unit Name (eg, section) []:
>>Common Name (eg, YOUR name) []:
>>Email Address []:
>>
>>
>>
> 
> OK so that seems to work. Maybe its just when x509 does it.
> 
> Can you try: 
> 
> openssl req -new -nodes -out req.pem -rand /tmp/somefile


$ ./openssl req -new -nodes -out req.pem -rand /tmp/somefile

Generating a 1024 bit RSA private key
............................++++++
..........................................++++++
writing new private key to 'privkey.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:


> 
> then 
> 
> openssl x509 -req -in req.pem -out sscert.pem -signkey privkey.pem


$ ./openssl x509 -req -in req.pem -out sscert.pem -signkey privkey.pem

Signature ok
subject=/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=Eric the Young
core dumping
Bus error (core dumped)


> if that second command dumps core then a stack trace under a debugger
> would help a lot.


will have to wait a bit.  i've never done that before and it's hiding the #$%!
core file.  i'll forward another email when i have one for you.




-- 
wendy palm
Cray OS Sustaining Engineering, Cray Inc.
wendyp@xxxxxxxx, 651-605-9154

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@xxxxxxxxxxx
Automated List Manager                           majordomo@xxxxxxxxxxx



Re: [openssl.org #451] SX6 port

Date: Mon Feb 03 20:59:16 2003
From: "Wendy Palm via RT" <rt@xxxxxxxxxxx>

In-reply-to: <rt-451@xxxxxxxxxxx>
References: <rt-451@xxxxxxxxxxx>

how's this?

*  0 getrn(lh = 0x0000000404092290, data = 0x000000040409d930, rhash = 0x0000008000001a40), line 430 in "lhash.c"
    1 lh_insert(lh = 0x0000000404092290, data = 0x000000040409d930), line 189 in "lhash.c"
    2 OBJ_add_object(obj = 0x0000000404088a00), line 253 in "obj_dat.c"
    3 OBJ_create(oid = 0x40400c990 "2.99999.3", sn = 0x40400c9a0 "SET.ex3", ln = 0x40400c9b0 "SET x509v3 extension 3"), line 660 in "obj_dat.c"
    4 x509_main(argc = 0, argv = 0x0000008000000278), line 621 in "x509.c"
    5 do_cmd(prog = 0x000000040408e120, argc = 8, argv = 0x0000008000000238), line 379 in "openssl.c"
    6 main(Argc = 8, Argv = 0x0000008000000238), line 298 in "openssl.c"
    7 _start(0x8, 0x8000000238, 0x8000000280) at 0x40000057c


Stephen Henson via RT wrote:

> [wendyp@xxxxxxxx - Sat Feb  1 00:59:01 2003]:
> 
> 
>>$ ./openssl req -x509 -new -nodes -out sscert.pem -rand /tmp/somefile
>>Generating a 1024 bit RSA private key
>>............++++++
>>..............................++++++
>>writing new private key to 'privkey.pem'
>>-----
>>You are about to be asked to enter information that will be
>>incorporated
>>into your certificate request.
>>What you are about to enter is what is called a Distinguished Name or
>>a DN.
>>There are quite a few fields but you can leave some blank
>>For some fields there will be a default value,
>>If you enter '.', the field will be left blank.
>>-----
>>Country Name (2 letter code) [AU]:
>>State or Province Name (full name) [Some-State]:
>>Locality Name (eg, city) []:
>>Organization Name (eg, company) [Internet Widgits Pty Ltd]:
>>Organizational Unit Name (eg, section) []:
>>Common Name (eg, YOUR name) []:
>>Email Address []:
>>
>>
>>
> 
> OK so that seems to work. Maybe its just when x509 does it.
> 
> Can you try: 
> 
> openssl req -new -nodes -out req.pem -rand /tmp/somefile
> 
> then 
> 
> openssl x509 -req -in req.pem -out sscert.pem -signkey privkey.pem
> 
> if that second command dumps core then a stack trace under a debugger
> would help a lot.
> 
> Thanks, Steve.
> 
> 


-- 
wendy palm
Cray OS Sustaining Engineering, Cray Inc.
wendyp@xxxxxxxx, 651-605-9154

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@xxxxxxxxxxx
Automated List Manager                           majordomo@xxxxxxxxxxx



Re: [openssl.org #451] SX6 port

Date: Mon Feb 03 21:01:06 2003
From: "Wendy Palm via RT" <rt@xxxxxxxxxxx>

In-reply-to: <rt-451@xxxxxxxxxxx>
References: <rt-451@xxxxxxxxxxx>

i forgot to add-

dbx's message says:

SIGSEGV (absentee space fault) in getrn at line 430 in file "lhash.c"
couldn't read "lhash.c"

Wendy Palm wrote:

> how's this?
> 
> *  0 getrn(lh = 0x0000000404092290, data = 0x000000040409d930, rhash = 
> 0x0000008000001a40), line 430 in "lhash.c"
>    1 lh_insert(lh = 0x0000000404092290, data = 0x000000040409d930), line 
> 189 in "lhash.c"
>    2 OBJ_add_object(obj = 0x0000000404088a00), line 253 in "obj_dat.c"
>    3 OBJ_create(oid = 0x40400c990 "2.99999.3", sn = 0x40400c9a0 
> "SET.ex3", ln = 0x40400c9b0 "SET x509v3 extension 3"), line 660 in 
> "obj_dat.c"
>    4 x509_main(argc = 0, argv = 0x0000008000000278), line 621 in "x509.c"
>    5 do_cmd(prog = 0x000000040408e120, argc = 8, argv = 
> 0x0000008000000238), line 379 in "openssl.c"
>    6 main(Argc = 8, Argv = 0x0000008000000238), line 298 in "openssl.c"
>    7 _start(0x8, 0x8000000238, 0x8000000280) at 0x40000057c
> 
> 
> Stephen Henson via RT wrote:
> 
>> [wendyp@xxxxxxxx - Sat Feb  1 00:59:01 2003]:
>>
>>
>>> $ ./openssl req -x509 -new -nodes -out sscert.pem -rand /tmp/somefile
>>> Generating a 1024 bit RSA private key
>>> ............++++++
>>> ..............................++++++
>>> writing new private key to 'privkey.pem'
>>> -----
>>> You are about to be asked to enter information that will be
>>> incorporated
>>> into your certificate request.
>>> What you are about to enter is what is called a Distinguished Name or
>>> a DN.
>>> There are quite a few fields but you can leave some blank
>>> For some fields there will be a default value,
>>> If you enter '.', the field will be left blank.
>>> -----
>>> Country Name (2 letter code) [AU]:
>>> State or Province Name (full name) [Some-State]:
>>> Locality Name (eg, city) []:
>>> Organization Name (eg, company) [Internet Widgits Pty Ltd]:
>>> Organizational Unit Name (eg, section) []:
>>> Common Name (eg, YOUR name) []:
>>> Email Address []:
>>>
>>>
>>>
>>
>> OK so that seems to work. Maybe its just when x509 does it.
>>
>> Can you try:
>> openssl req -new -nodes -out req.pem -rand /tmp/somefile
>>
>> then
>> openssl x509 -req -in req.pem -out sscert.pem -signkey privkey.pem
>>
>> if that second command dumps core then a stack trace under a debugger
>> would help a lot.
>>
>> Thanks, Steve.
>>
>>
> 
> 


-- 
wendy palm
Cray OS Sustaining Engineering, Cray Inc.
wendyp@xxxxxxxx, 651-605-9154

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@xxxxxxxxxxx
Automated List Manager                           majordomo@xxxxxxxxxxx



RE: [openssl.org #474] Status Changed to: open

Date: Mon Feb 03 21:03:08 2003
From: "SWoloszyn@xxxxxxxxxxxxxxxxx via RT" <rt@xxxxxxxxxxx>

In-reply-to: <rt-474@xxxxxxxxxxx>
References: <rt-474@xxxxxxxxxxx>


We found some serious build issues with the original submission
(openssl-lunaca3-patch-0.9.7.tar.gz) and we are busy updating the patch.  I
expect the update will be necessary before this ticket is closed.

Let me know when you have the chance to examine the update and/or if I
should just post it.


Regards,

Steve Woloszyn 

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@xxxxxxxxxxx
Automated List Manager                           majordomo@xxxxxxxxxxx



[openssl.org #489] patch to 0.9.7 -performacne

Date: Tue Feb 04 02:57:59 2003
From: "Geoff Thorpe via RT" <rt@xxxxxxxxxxx>

In-reply-to: <rt-489@xxxxxxxxxxx>
References: <rt-489@xxxxxxxxxxx>

This ticket seems to be one and the same as #475 - and as mentioned in
that ticket's history, you need to resubmit the patch with a CC to the
appropriate US agency; please see the last entry in the ticket history at;

    http://www.aet.tu-cottbus.de/rt2/Ticket/Display.html?id=475

My reading of that suggests that you copy the email to crypt@xxxxxxxxxxx
and enc@xxxxxxxxx

As for the patch itself, I'll follow up in the original ticket shortly.
This ticket is now closed.

-- 
Geoff Thorpe, RT/openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@xxxxxxxxxxx
Automated List Manager                           majordomo@xxxxxxxxxxx



[openssl.org #475] [Fwd: patch to 0.9.7 -performacne]

Date: Tue Feb 04 03:05:00 2003
From: "Geoff Thorpe via RT" <rt@xxxxxxxxxxx>

In-reply-to: <rt-475@xxxxxxxxxxx>
References: <rt-475@xxxxxxxxxxx>

As mentioned in ticket 489 (which is now closed), this ticket was not
forgotten, it is waiting on the patch being submitted with a copy to the
appropriate US agencies.

For the patch itself, I'm not sure about the location (or necessity) of
_method_mod_n initialisation you've inserted - but I'll wait for the
resubmission before analysing this properly (could just be me being
obtuse and scanning the diff too quickly ...)

-- 
Geoff Thorpe, RT/openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@xxxxxxxxxxx
Automated List Manager                           majordomo@xxxxxxxxxxx



Re: openssl req prompting behavior

Date: Tue Feb 04 16:16:50 2003
From: Bodo Moeller <moeller@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>

In-reply-to: <000701c2c264$7f956310$16e1ab3f@JOELDXP >; from joeld@xxxxxxxxxxxx on Wed, Jan 22, 2003 at 04:20:37PM -0600
References: <000701c2c264$7f956310$16e1ab3f@JOELDXP >

On Wed, Jan 22, 2003 at 04:20:37PM -0600, Joel Daniels wrote:

> The "openssl req" command, when set up to prompt for the Distinguished Name,
> uses fgets() to read the Distinguished Name fields.  This means that if
> someone uses the backspace key, a 0x08 character is inserted wherever they
> typed the backspace key.

If the backspace key results in a 0x08 character and this is not what
you want, then you should either call

     stty erase '^h'

before starting

     openssl req ...

or reconfigure the keyboard so that the backspace key sends 0x7f (DEL)
instead.  This has nothing to do with OpenSSL; you'll observer the
same behaviour if you run, say, 'cat'.


-- 
Bodo Möller <moeller@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@xxxxxxxxxxx
Automated List Manager                           majordomo@xxxxxxxxxxx



new here:smartcard engine

Date: Tue Feb 04 16:24:37 2003
From: Henning Follmann <hfollmann@xxxxxxxxxxxxxxx>

Hello I am new in this mailinglist.
Currently I am trying to figure out a solution for a specific problem.
The aim is to have a CA with the private key stored on a smartcard
(cryptoflex).
My attempt would be writing an engine which uses the smartcard for RSA
encryption/decryption/signing but I am not sure I am on the right track.
I am also not sure where to start writing an engine for openssl and how
to integrate in the library.

Any pointer appreciated,
thanks,
Henning

-- 
Henning Follmann          |   hfollmann@xxxxxxxxxxxxxxx

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@xxxxxxxxxxx
Automated List Manager                           majordomo@xxxxxxxxxxx



Re: [openssl.org #475] TSU Notification - Encryption

Date: Tue Feb 04 17:34:59 2003
From: "David Brumley via RT" <rt@xxxxxxxxxxx>

In-reply-to: <rt-475@xxxxxxxxxxx>
References: <rt-475@xxxxxxxxxxx>

On Mon, 2003-02-03 at 19:06, Geoff Thorpe via RT wrote:
> 
> As mentioned in ticket 489 (which is now closed), this ticket was not
> forgotten, it is waiting on the patch being submitted with a copy to the
> appropriate US agencies.
> 
> For the patch itself, I'm not sure about the location (or necessity) of
> _method_mod_n initialisation you've inserted - but I'll wait for the
> resubmission before analysing this properly (could just be me being
> obtuse and scanning the diff too quickly ...)
> 
> -- 
> Geoff Thorpe, RT/openssl.org

Attached is my patch to openssl 0.9.7.  This message is CC'ed to the
appropriate US gov't parties.

Thanks!
-david


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@xxxxxxxxxxx
Automated List Manager                           majordomo@xxxxxxxxxxx



Win32 update to the ssleay32.def file

Date: Tue Feb 04 21:31:10 2003
From: "Joseph Ferner" <josephferner@xxxxxxx>

In OpenSSL 0.9.7 SSL_add_dir_cert_subjects_to_stack (ssl_cert.c) was
added for Win32 but was omitted in the ssleay32.def file.  Could this be
added?

It would also be nice to have ssl3_send_alert (s3_pkt.c) in the .def
file as well.  OpenLDAP with SSL support would then compile without
complaining on Win32.

Thanks
Joe


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@xxxxxxxxxxx
Automated List Manager                           majordomo@xxxxxxxxxxx



[openssl.org #475] [Fwd: patch to 0.9.7 -performacne]

Date: Tue Feb 04 21:55:31 2003
From: "Geoff Thorpe via RT" <rt@xxxxxxxxxxx>

In-reply-to: <rt-475@xxxxxxxxxxx>
References: <rt-475@xxxxxxxxxxx>

[dbrumley@xxxxxxxxxxxx - Tue Feb  4 18:36:33 2003]:

> Attached is my patch to openssl 0.9.7.  This message is CC'ed to the
> appropriate US gov't parties.

OK. Thanks David for sorting out the US obligations, and for bringing
the missing _method_mod_n initialisation to our attention.

I've attached an alternative diff to yours - it includes your changes
verbatim, but wraps up all _method_mod_<whatever> initialisations with
macro-wrappers to a helper function and "#if 0"'s out the existing code
(including your additional one). BTW: This buys about 1.5% speed-up for
RSA private key ops on my desktop which is of course better than a kick
in the pants :-) Thanks again. I'll let this patch linger for a day or
two in case anyone wants to sanity-check first.

BTW: the patch is for the head of CVS but should apply to 0.9.7 with an
offset of 3 lines or so, though I haven't tried (migrating your original
patch the other direction worked in this fashion, however).

-- 
Geoff Thorpe, RT/openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@xxxxxxxxxxx
Automated List Manager                           majordomo@xxxxxxxxxxx



[openssl.org #276] How to get session id for external session cache in openssl

Date: Wed Feb 05 00:36:20 2003
From: "Geoff Thorpe via RT" <rt@xxxxxxxxxxx>

In-reply-to: <rt-276@xxxxxxxxxxx>
References: <rt-276@xxxxxxxxxxx>

[jaenicke - Tue Sep 10 08:58:13 2002]:
--snip--
> I have thus bounced your mail into the request tracker, such that a
> suitable API will be added.

(just dredging through some older tickets ...)

I've attached an ultra-simple suggestion (the attached diff probably
won't propogate to openssl-dev though, so I guess you have to surf the
request tracker). Anyway, does this seem to do what's required?

-- 
Geoff Thorpe, RT/openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@xxxxxxxxxxx
Automated List Manager                           majordomo@xxxxxxxxxxx



[openssl.org #276] How to get session id for external session cache in openssl

Date: Wed Feb 05 00:38:11 2003
From: "Geoff Thorpe via RT" <rt@xxxxxxxxxxx>

In-reply-to: <rt-276@xxxxxxxxxxx>
References: <rt-276@xxxxxxxxxxx>

[geoff - Wed Feb  5 01:37:55 2003]:
--snip--
> request tracker). Anyway, does this seem to do what's required?

Damn, let's try that again ... the diff *is* now attached to the RT ticket.

-- 
Geoff Thorpe, RT/openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@xxxxxxxxxxx
Automated List Manager                           majordomo@xxxxxxxxxxx



[openssl.org #484] openssl question

Date: Wed Feb 05 01:35:41 2003
From: "Stephen Henson via RT" <rt@xxxxxxxxxxx>

In-reply-to: <rt-484@xxxxxxxxxxx>
References: <rt-484@xxxxxxxxxxx>

[steve - Fri Jan 31 20:40:28 2003]:

> [levitte@xxxxxxxxxxxxxx - Fri Jan 31 07:56:07 2003]:
> 
> > In message <rt-484-3709.13.2591267074665@xxxxxxxxxxx> on Fri, 31 Jan
> > 2003 04:59:36 +0100 (MET), " via RT" <rt@xxxxxxxxxxx> said:
> >
> > rt>
> > rt> Do you have any ideia when?
> >
> > 0.9.8 at the earliest.
> 
> 0.9.8 at the latest :-)
> 
> I'm currently testing some code that handles IPv6 and I'll check it
> into
> 0.9.8-dev in the next day or so.
> 

IPv6 code now checked into 0.9.8. Let me know of any problems.

Steve.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@xxxxxxxxxxx
Automated List Manager                           majordomo@xxxxxxxxxxx



Re: Win32 update to the ssleay32.def file

Date: Wed Feb 05 16:38:37 2003
From: Bodo Moeller <moeller@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>

In-reply-to: <000401c2cc94$e87a7200$6400a8c0@josephwks >; from josephferner@xxxxxxx on Tue, Feb 04, 2003 at 04:32:24PM -0500
References: <000401c2cc94$e87a7200$6400a8c0@josephwks >

On Tue, Feb 04, 2003 at 04:32:24PM -0500, Joseph Ferner wrote:

> In OpenSSL 0.9.7 SSL_add_dir_cert_subjects_to_stack (ssl_cert.c) was
> added for Win32 but was omitted in the ssleay32.def file.  Could this be
> added?

Thanks for the report, this is now fixed.

> It would also be nice to have ssl3_send_alert (s3_pkt.c) in the .def
> file as well.  OpenLDAP with SSL support would then compile without
> complaining on Win32.

ssl3_send_alert() is not part of the "officially" exported API (you
don't find in anywhere in include/openssl/*.h), so it is correct
that it does not appear in the .def file.


-- 
Bodo Möller <moeller@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
PGP http://www.info