Re: RE : Build openssl-SNAP-20030529 (Windows)

In message <000201c32773$babfcc40$2200a8c0 <at> cdes> on Sat, 31 May 2003 14:54:09 +0200, "p b"
<phbgt <at> wanadoo.fr> said:

phbgt> "When I configure openssl-SNAP-20030529 with ms/do_ms, and then I compile
phbgt> with nmake -f ms\nt.mak, store.h is not copied in /inc32/openssl
phbgt> 
phbgt> 
phbgt> If I copy that file, there's an incompatibility signed/unsigned in
phbgt> crypto/ecdh/ech_ossl.c line 193.
phbgt> 
phbgt> I had made a cast (size_t), 
phbgt> 
phbgt> Then in crypto\engine\eng-ctrl.c line 281, I get the message :
phbgt> 
phbgt> Warning C4113 : 'void <_cdecl *><>' is different than 'void <_cdecl
phbgt> *><void>' 
phbgt> For the 5th parameters 
phbgt> "

I've fixes for that in my work directory, just haven't committed yet.
I'm currently running a test compile to make sure I got everything
right.

--

-- 
Richard Levitte   \ Tunnlandsvägen 3  \ LeViMS <at> stacken.kth.se
Redakteur <at> Stacken  \ S-168 36  BROMMA  \ T: +46-8-26 52 47
                    \      SWEDEN       \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis                -- poei <at> bofh.se
Member of the OpenSSL development team: http://www.openssl.org/

[openssl.org #634] [PATCH] bogus links to des_modes.7

I've noticed that openssl installs the man page des_modes.7 and makes
three links to it called Modes.7, of.7, and DES.7 (because the title is
"Modes of DES").

To fix this, I have modified util/extract-names.pl, util/point.sh, and
Makefile.org, in order to extract the name as a single string with
embedded spaces and to create the symbolic link that way. Diffs are
attached.

Of course, a man page file name with embedded spaces isn't very useful
anyway, but it's better than having "of.7". Maybe something should be
changed in doc/crypto/des_modes.pod.

Matthew Fischer
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

[openssl.org #356] Bug in CRLF translation in PKCS7_sign

[peter <at> ansiblesw.com - Fri Nov 22 10:27:16 2002]:

> 
> OS: Windows, but I think it is a cross-platform bug.
> Version: 0.9.6g
> 
> In the following function which is called from
> PKCS7_sign, if the source text contains a line of text
> which is exactly a mutiple of MAX_SMLEN-2 characters
> long and has a CRLF line ending, then the gets call
> will return a buffer which ends with just a CR, and
> then on the next call a line that contains just an LF,
> which will result in two CRLF pairs being put into the
> output.
> 
> A harmless bit of buggy coding is also present.  The
> value of len is not checked in the inner while loop. 
> Any line which only contains CR or LF characters will
> cause len to go to 0, and the memory location
> linebuf[-1] will be read.  Its extremely unlikely that
> the value at that location is a CR or LF, so usually
> the loop terminates anyway.  But, its not nice to go
> out of bounds, and I imagine memory protection faults
> could be triggered on some platforms.
> 
> This only affects callers who do not pass PKCS7_BINARY
> in the flags parameter (our work-around was to
> normalize the line endings ourselves and then pass
> PKCS7_BINARY).

[openssl.org #624] [BUG] SMIME decrypt fails when encrypted file size is 9383 bytes

I've tried this on the latest 0.9.7-stable version and it fails with a
base64 decoding error.

The cause is that the base64 BIO is rather broken as I discovered when I
attempted to run some exhaustive non-blocking I/O tests on it a while ago. 

Since the changes were quite extensive, it could break other things like
PEM if I got it wrong, it only seemed to affect non blocking I/O and no
one else appeared to have noticed I didn't commit the fixes to the
stable tree. 

However now that it does affect blocking I/O and someone has noticed 
I've got a good reason to fix the stable version too.

If you don't want to wait until the next snapshot you can just copy
bio_b64.c from the 0.9.8-dev version to 0.9.7b.

Steve.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

64-bit vs 32-bit systems

Re: 64-bit vs 32-bit systems

> It looks to me like a 64-bit client cant connect to a 32-bit server.  

nope, it works.

> The ASN1 structures/headers have int's and longs scattered throughout 
> them (and probably in other parts of the openssl libraries).  In fact, 
> the 32-bit server fails to recieve a connection with the error "bad asn1 
> object header".

The ASN1 structures are local forms that are created from wire
representations (DER).  Look at the various i2d_xxx and d2i_xxx functions.

If you're having problems, it's not because something is wrong in the
place where you're looking. :)
	/r$
--

-- 
Rich Salz, Chief Security Architect
DataPower Technology         http://www.datapower.com
XS40 XML Security Gateway    http://www.datapower.com/products/xs40.html

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

[openssl.org #635] Manual pages.

Hi,
   I have a request.
   Pls let me know where from can I download the whole 'man pages'
documentation.
   If possible pls add a 'search' option on the website
   so that I can search on the commands I would like to know about, among
the documentation pages.

   Thanks for your hard, sustaining work on openssl.

rgds,
s prabhakar.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Re: 64-bit vs 32-bit systems

Hello,

DJohnson <at> chrysalis-its.com wrote:
>   64-bit vs 32-bit systems
> 
> It looks to me like a 64-bit client cant connect to a 32-bit server.

> The ASN1 structures/headers have int's and longs scattered throughout 
> them (and probably in other parts of the openssl libraries).  In fact, 
> the 32-bit server fails to recieve a connection with the error "bad asn1 
> object header".

That are 2 different kind of shoes.

Structures and headers are not direct related to the data
on the wire..

I think you have configured on a 32 bit system
and build on a 64 bit system,
or build the library on a 32 bit system and your program
on a 64 bit system...

> My question is, how self contained is this software.  Could the longs be 
> replace by ints to keep the structures the same size on both systems?  

Why ?

You need the headers only if you build a program.
And you shouldn't link a openssl build on a 32 bit system
with a program build on a 64 bit system...

> Has this issue been discusses before?

AFAIK not.

perhaps openssl should migrate to the types defined in stding.h ?
But that comes with ISO C99, so an fallback should be supported...

Bye

Goetz

--

-- 
Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0,  Fax: +49-(0)40 80 80 26 -126

RE: 64-bit vs 32-bit systems

Blinding breaks engines?

Hi, the changes to enable blinding by default in 0.9.7b appear to break
when an ENGINE is in use (for all the ENGINEs I've tested), with an
assertion failure:

openssl: bn_lib.c:254: BN_num_bits: Assertion `l != 0' failed.

and backtrace as follows:

#4  0x080b97c7 in BN_num_bits (a=0x81e4fd4) at bn_lib.c:254
#5  0x080ce940 in ubsec_mod_exp (r=0x81e4fd4, a=0x81e4fd4, p=0x81cdde8, 
m=0x81cdfb8, ctx=0x81e4fd0)
    at hw_ubsec.c:578
#6  0x080cee37 in ubsec_mod_exp_mont (r=0x81e4fd4, a=0x81e4fd4, 
p=0x81cdde8, m=0x81cdfb8, ctx=0x81e4fd0,
    m_ctx=0x0) at hw_ubsec.c:722
#7  0x080bf6e6 in RSA_blinding_on (rsa=0x81cdf28, p_ctx=0x81e4fd0) at 
rsa_lib.c:354
#8  0x080bd1aa in rsa_eay_blinding (rsa=0x81cdf28, ctx=0x81e4fd0) at 
rsa_eay.c:202
#9  0x080bd574 in RSA_eay_private_encrypt (flen=36,
etc

As I understand it, blinding is not needed when using a hardware
accelerator.  So, is the correct fix to set RSA_FLAG_NO_BLINDING on a
per-engine basis, for example as below, or is there something more
subtle that can be done?

--- ./crypto/engine/hw_ubsec.c.blind	Thu Jun  5 12:49:08 2003
+++ ./crypto/engine/hw_ubsec.c	Thu Jun  5 12:55:15 2003
 <at>  <at>  -118,6 +118,12  <at>  <at> 
 static int ubsec_rand_status(void);
 #endif

+static int ubsec_rsa_init(RSA *r)
+{
+  r->flags |= RSA_FLAG_NO_BLINDING;
+  return(1);
+}
+
 #define UBSEC_CMD_SO_PATH		ENGINE_CMD_BASE
 static const ENGINE_CMD_DEFN ubsec_cmd_defns[] = {
 	{UBSEC_CMD_SO_PATH,
 <at>  <at>  -138,6 +144,7  <at>  <at> 
 	NULL,
 	ubsec_rsa_mod_exp,
 	ubsec_mod_exp_mont,
+	ubsec_rsa_init,
 	NULL,
 	NULL,
 	0,
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org