aes key wrap ciphertext with custom test vector: test fails

2010-01-22 Thread protagora27 protagora27
I have downloaded openssl-0.9.8l and I have builded
openssl with

1) ./config --prefix=/home/luca/zz/tmpopenssl/
--openssldir=/home/luca/zz/tmpopenssl/openssldir shared

2) make

3) make test

4)make install

It's all ok.

I want to test aes_wrap.c under sourceopenssl/crypto/aes.

My goal is to generate  a cyphertext from palintext with len=0x160
My test vector is a incremental pattern [0...0x5f].
I go under sourceopenssl/crypto/aes and then I run:

gcc -I.. -I../.. -I../../include   -DAES_WRAP_TEST
-L/home/luca/zz/tmpopenssl/lib/. -lssl  -L/home/luca/zz/tmpopenssl/lib/.
-lcrypto   -o aes_wrap aes_wrap.c

If I check:

ldd aes_wrap:

linux-gate.so.1 =>  (0xb7fd3000)
libssl.so.0.9.8 => /home/luca/zz/tmpopenssl/lib/libssl.so.0.9.8 
(0xb7f8c000)
libcrypto.so.0.9.8 => /home/luca/zz/tmpopenssl/lib/libcrypto.so.0.9.8
(0xb7e4)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7ce1000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7cdd000)
/lib/ld-linux.so.2 (0xb7fd4000)

 It's ok.

If i run aes_wrap with  nist test vector  i see all ok.

But if i run aes key wrap with incremental pattern I get a non correct
result because
cypertext is not correct ( i know it from other open source lib)
Why?

Following is  my changed aes_wrap.c  to see output cyphetext:

#include "cryptlib.h"
#include 
#include 

static const unsigned char default_iv[] = {
  0xA6, 0xA6, 0xA6, 0xA6, 0xA6, 0xA6, 0xA6, 0xA6,
};

int AES_wrap_key(AES_KEY *key, const unsigned char *iv,
unsigned char *out,
const unsigned char *in, unsigned int inlen)
{
unsigned char *A, B[16], *R;
unsigned int i, j, t;
if ((inlen & 0x7) || (inlen < 8))
return -1;
A = B;
t = 1;
memcpy(out + 8, in, inlen);
if (!iv)
iv = default_iv;

memcpy(A, iv, 8);

for (j = 0; j < 6; j++)
{
R = out + 8;
for (i = 0; i < inlen; i += 8, t++, R += 8)
{
memcpy(B + 8, R, 8);
AES_encrypt(B, B, key);
A[7] ^= (unsigned char)(t & 0xff);
if (t > 0xff)   
{
A[6] ^= (unsigned char)((t & 0xff) >> 8);
A[5] ^= (unsigned char)((t & 0xff) >> 16);
A[4] ^= (unsigned char)((t & 0xff) >> 24);
}
memcpy(R, B + 8, 8);
}
}
memcpy(out, A, 8);

for (i=0; i< (inlen + 8); i++)   //modified to see output
   printf("%2X ",out[i]);
printf("\n");

return inlen + 8;
}

int AES_unwrap_key(AES_KEY *key, const unsigned char *iv,
unsigned char *out,
const unsigned char *in, unsigned int inlen)
{
unsigned char *A, B[16], *R;
unsigned int i, j, t;
inlen -= 8;
if (inlen & 0x7)
return -1;
if (inlen < 8)
return -1;
A = B;
t =  6 * (inlen >> 3);
memcpy(A, in, 8);
memcpy(out, in + 8, inlen);
for (j = 0; j < 6; j++)
{
R = out + inlen - 8;
for (i = 0; i < inlen; i += 8, t--, R -= 8)
{
A[7] ^= (unsigned char)(t & 0xff);
if (t > 0xff)   
{
A[6] ^= (unsigned char)((t & 0xff) >> 8);
A[5] ^= (unsigned char)((t & 0xff) >> 16);
A[4] ^= (unsigned char)((t & 0xff) >> 24);
}
memcpy(B + 8, R, 8);
AES_decrypt(B, B, key);
memcpy(R, B + 8, 8);
}
}
if (!iv)
iv = default_iv;
if (memcmp(A, iv, 8))
{
OPENSSL_cleanse(out, inlen);
return 0;
}
return inlen;
}

#ifdef AES_WRAP_TEST

int AES_wrap_unwrap_test(const unsigned char *kek, int keybits,
 const unsigned char *iv,
 const unsigned char *eout,
 const unsigned char *key, int keylen)
{
unsigned char *otmp = NULL, *ptmp = NULL;
int r, ret = 0;
AES_KEY wctx;
otmp = OPENSSL_malloc(keylen + 8);
ptmp = OPENSSL_malloc(keylen);
if (!otmp || !ptmp)
return 0;
if (AES_set_encrypt_key(kek, keybits, &wctx))
goto err;
r = AES_wrap_key(&wctx, iv, otmp, key, keylen);
if (r <= 0)
goto err;

if (eout && memcmp(eout, otmp, keylen))
   

[openssl.org #2151] MGF1 not exported in 1.0.0

2010-01-22 Thread Kenneth Goldman via RT

Between 0.9.8 and 1.0.0, the function rsa_oaep.c:MGF1() was changed to
static.

This breaks backward compatibility.  IMHO, the static keyword should be
removed.

(Copying the users mailing list.  My hope is that I can gather some
community support for
the importance of backward compatibility.)

--
Ken Goldman   kg...@watson.ibm.com
914-784-7646 (863-7646)

Between 0.9.8 and 1.0.0, the function rsa_oaep.c:MGF1() was changed to static.

This breaks backward compatibility.  IMHO, the static keyword should be removed.

(Copying the users mailing list.  My hope is that I can gather some community support for
the importance of backward compatibility.)

--
Ken Goldman   kg...@watson.ibm.com   
914-784-7646 (863-7646)


RE: OpenSSL 1.0.0 beta5 release v. VMS

2010-01-22 Thread Arpadffy Zoltan
Hello,

I have applied the following changes:

TITAN2_ZAY $ diff <.crypto>symhacks.h

File USRDSK:SYMHACKS.H;2
  179   #undef ssl_parse_serverhello_renegotiate_ext
  180   #define ssl_parse_serverhello_renegotiate_ext
ssl_parse_servhello_reneg_ext
  181   #undef ssl_parse_clienthello_renegotiate_ext
  182   #define ssl_parse_clienthello_renegotiate_ext
ssl_parse_clihello_reneg_ext
  183   #undef ssl_add_serverhello_renegotiate_ext
  184   #define ssl_add_serverhello_renegotiate_ext
ssl_add_servhello_reneg_ext
  185   #undef ssl_add_clienthello_renegotiate_ext
  186   #define ssl_add_clienthello_renegotiate_ext
ssl_add_clihello_reneg_ext
  187
**
File USRDSK:SYMHACKS.H;1
  179


Number of difference sections found: 1
Number of difference records found: 8


TITAN2_ZAY $ diff <.util>libeay.num

File USRDSK:LIBEAY.NUM;2
 4174   X509_subject_name_hash_old  4548
EXIST::FUNCTION:MD
 4175   ssl_parse_serverhello_renegotiate_ext   4549
EXIST:!VMS:FUNCTION:
 4176   ssl_parse_servhello_reneg_ext   4549
EXIST:VMS:FUNCTION:
 4177   sl_parse_clienthello_renegotiate_ext4550
EXIST:!VMS:FUNCTION:
 4178   ssl_parse_clihello_reneg_ext4550
EXIST:VMS:FUNCTION:
 4179   ssl_add_serverhello_renegotiate_ext 4551
EXIST:!VMS:FUNCTION:
 4180   ssl_add_servhello_reneg_ext 4551
EXIST:VMS:FUNCTION:
 4181   ssl_add_clienthello_renegotiate_ext 4552
EXIST:!VMS:FUNCTION:
 4182   ssl_add_clihello_reneg_ext  4552
EXIST:VMS:FUNCTION:
 4183
**
File USRDSK:LIBEAY.NUM;1
 4174   X509_subject_name_hash_old  4548
EXIST::FUNCTION:MD5


Number of difference sections found: 1
Number of difference records found: 10

It does a clean compile, but the functions can not be found in the
library.

Compiling The TS.C File.
%ILINK-W-NUDFSYMS, 4 undefined symbols:
%ILINK-I-UDFSYM,SSL_ADD_CLIHELLO_RENEG_EXT
%ILINK-I-UDFSYM,SSL_ADD_SERVHELLO_RENEG_EXT
%ILINK-I-UDFSYM,SSL_PARSE_CLIHELLO_RENEG_EXT
%ILINK-I-UDFSYM,SSL_PARSE_SERVHELLO_RENEG_EXT
%ILINK-W-USEUNDEF, undefined symbol SSL_ADD_CLIHELLO_RENEG_EXT
referenced
section: $CODE$
offset: %X0890  slot: 2
module: T1_LIB
file:
USRDSK:[ZAY.WORK.OPENSSL-100-BETA5.IA64.EXE.SSL]LIBSSL.OLB;1
%ILINK-W-USEUNDEF, undefined symbol SSL_ADD_CLIHELLO_RENEG_EXT
referenced
section: $CODE$
offset: %X0A50  slot: 2
module: T1_LIB
file:
USRDSK:[ZAY.WORK.OPENSSL-100-BETA5.IA64.EXE.SSL]LIBSSL.OLB;1
%ILINK-W-USEUNDEF, undefined symbol SSL_ADD_SERVHELLO_RENEG_EXT
referenced
section: $CODE$
offset: %X1D60  slot: 2
module: T1_LIB
file:
USRDSK:[ZAY.WORK.OPENSSL-100-BETA5.IA64.EXE.SSL]LIBSSL.OLB;1
%ILINK-W-USEUNDEF, undefined symbol SSL_ADD_SERVHELLO_RENEG_EXT
referenced
section: $CODE$
offset: %X1EA0  slot: 2
module: T1_LIB
file:
USRDSK:[ZAY.WORK.OPENSSL-100-BETA5.IA64.EXE.SSL]LIBSSL.OLB;1
%ILINK-W-USEUNDEF, undefined symbol SSL_PARSE_CLIHELLO_RENEG_EXT
referenced
section: $CODE$
offset: %X2DD0  slot: 2
module: T1_LIB
file:
USRDSK:[ZAY.WORK.OPENSSL-100-BETA5.IA64.EXE.SSL]LIBSSL.OLB;1
%ILINK-W-USEUNDEF, undefined symbol SSL_PARSE_SERVHELLO_RENEG_EXT
referenced
section: $CODE$
offset: %X3AE0  slot: 2
module: T1_LIB
file:
USRDSK:[ZAY.WORK.OPENSSL-100-BETA5.IA64.EXE.SSL]LIBSSL.OLB;1


What I am doing wrong?

Any help would be highly appreciated as VMS community would like to have
an usable and fully functional 1.0.0 release.

Thank you in advance.

Regards, 
Z 

-Original Message-
From: Steven M. Schweda [mailto:s...@antinode.info] 
Sent: den 21 januari 2010 20:00
To: openssl-dev@openssl.org
Subject: OpenSSL 1.0.0 beta5 release v. VMS

> o openssl-1.0.0-beta5.tar.gz

ALP $ cc /version
HP C V7.3-009 on OpenVMS Alpha V8.3

@ makevms.com ALL "" NODEBUG DECC TCPIP
[...]
Compiling On A ALPHA Machine.
[You have to admire these messages.]
Building The SYS$DISK:[-.ALPHA.EXE.SSL]LIBSSL.OLB Library.
[...]
t1_lib.c

int ssl_parse_serverhello_renegotiate_ext(SSL *s, unsigned char *d, int
len,
^
%CC-W-LONGEXTERN, The external identifier name exceeds 31 characters;
truncated to "SSL_PARSE_SERVERHELLO_RENEGOTIA".
at line number 1072 in file
ALP$DKA0:[UTILITY.SOURCE.OPENSSL.openssl-1^.0^.0-beta5.ssl]ssl_locl.h;1

int ssl_parse_clienthello_renegotiate_ext(SSL *s, unsigned char *d, int
len,
^
%CC-W-LONGEXTERN, The external identifier name exceeds 31 characters;
truncated to "SSL_PARSE_CLIENTHELLO_RENEGOTIA".
at line number 1076 in file
ALP$DKA0:[UTILITY.SOURCE.OPENSSL.openssl-1^.0^.0-beta5.ssl]ssl_locl.h;1

int ssl_add_serverhello_renegotiate_ext(SSL *s, unsigned char *p, int
*len,
^
%CC-W-LONGEXTERN, The external identifier name exceeds 31 characters;
truncated to "SSL_ADD_SERVERHELLO_RENEGOTIATE".
at line n

Regression in OPENSSL_cleanse in v1.0?

2010-01-22 Thread Martin Paljak
Hello.

It appears that in v1.0 something relating to OPENSSL_cleanse has changed. Most 
notably it crashes whenever len is zero. This was not the case with 0.9.8.

Here is a small test program:

#include 
int main()
{
 char *foo = malloc(1);
 if (!foo) {
  printf("malloc()");
  exit(1);
 }
 OPENSSL_cleanse(foo, 1);
 printf("cleaned one byte\n");
 OPENSSL_cleanse(foo, 0);
 printf("cleaned zero bytes\n");
}


With 0.9.8l it produces the expected two lines:
cleaned one byte
cleaned zero bytes

With 1.0.0-beta4 (under gdb):
cleaned one byte

Program received signal SIGSEGV, Segmentation fault.
0x0014bd6f in OPENSSL_cleanse () from /usr/lib/libcrypto.so.10

The interesting thing here is that the implementation of mem_clr.c has not 
changed between 0.9.8(k) and 1.0.0-beta5.

Is OPENSSL_cleanse supposed to be callable with zero length?

Tried it on Ubuntu 9.10 with 0.9.8g and 1.0.0-beta4, OSX with 0.9.8l and Fedora 
12 with 1.0.0-beta4.

Any hints?

-- 
Martin Paljak
http://martin.paljak.pri.ee
+3725156495

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: Regression in OPENSSL_cleanse in v1.0?

2010-01-22 Thread Tomas Mraz
On Fri, 2010-01-22 at 19:19 +0200, Martin Paljak wrote: 
> Hello.
> 
> It appears that in v1.0 something relating to OPENSSL_cleanse has
> changed. Most notably it crashes whenever len is zero. This was not
> the case with 0.9.8.
...
> The interesting thing here is that the implementation of mem_clr.c has
> not changed between 0.9.8(k) and 1.0.0-beta5.
It did not and it is 0 byte length safe. The problem is with assembler
implementations which underflow with 0 byte length and overwrite memory.

> Is OPENSSL_cleanse supposed to be callable with zero length?
That's a question I did a very quick overview of the calls to
OPENSSL_cleanse() in openssl and did not found anything suspicious at
first sight that it would call it eventually with 0 bytes but there are
definitely places that might need some deeper review.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: OpenSSL 1.0.0 beta5 release v. VMS

2010-01-22 Thread Steven M. Schweda
From: Arpadffy Zoltan 

> I have applied the following changes:

> TITAN2_ZAY $ diff <.crypto>symhacks.h
> [...]

   Plausible.  (I'd bet that output from GNU "diff" would be more
popular here.)

> TITAN2_ZAY $ diff <.util>libeay.num
> [...]

   I didn't look closely at this.  "util/ssleay.num" may be a better
place for these things.


> It does a clean compile, but the functions can not be found in the
> library.
> [...]
> What I am doing wrong?

   Expecting any of this stuff to work easily?

   I'd guess that the new "ssl/t1_reneg.c" needs to be included in
"ssl/ssl-lib.com".  Look for the scrambled mess of module names at
"LIB_SSL =".  (Remember that these module names are in this disorder
because this way it's so easy to update the list when it's changed.  See
how much that helped?  But someday it'll all be automatic.  I'm holding
_my_ breath.  You?)

> Any help would be highly appreciated as VMS community would like to have
> an usable and fully functional 1.0.0 release.

   WAKE UP!  You're asleep and dreaming.

> >I assume that these things need to be added to "crypto/symhacks.h"
> >and/or "util/libeay.num".

   Well, "util/.num".  Probably.  (Perhaps?)



   Steven M. Schweda   s...@antinode-info
   382 South Warwick Street(+1) 651-699-9818
   Saint Paul  MN  55105-2547
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: OpenSSL 1.0.0 beta5 release v. VMS

2010-01-22 Thread Kyle Hamilton
Really, what needs to happen is that, in the case of VMS with a
limited C compiler that doesn't handle long symbols, the long symbols
need to be truncated in the *.num files.  (This shouldn't need to be
done for any other platform at this instant, but...)

There's currently no conflict, so there's no current major issue --
but it's something the developers need to keep in mind, that there are
arbitrary symbol length limits on at least one of the
somewhat-supported platforms.

-Kyle H

On Fri, Jan 22, 2010 at 1:20 PM, Steven M. Schweda  wrote:
> From: Arpadffy Zoltan 
>
>> I have applied the following changes:
>
>> TITAN2_ZAY $ diff <.crypto>symhacks.h
>> [...]
>
>   Plausible.  (I'd bet that output from GNU "diff" would be more
> popular here.)
>
>> TITAN2_ZAY $ diff <.util>libeay.num
>> [...]
>
>   I didn't look closely at this.  "util/ssleay.num" may be a better
> place for these things.
>
>
>> It does a clean compile, but the functions can not be found in the
>> library.
>> [...]
>> What I am doing wrong?
>
>   Expecting any of this stuff to work easily?
>
>   I'd guess that the new "ssl/t1_reneg.c" needs to be included in
> "ssl/ssl-lib.com".  Look for the scrambled mess of module names at
> "LIB_SSL =".  (Remember that these module names are in this disorder
> because this way it's so easy to update the list when it's changed.  See
> how much that helped?  But someday it'll all be automatic.  I'm holding
> _my_ breath.  You?)
>
>> Any help would be highly appreciated as VMS community would like to have
>> an usable and fully functional 1.0.0 release.
>
>   WAKE UP!  You're asleep and dreaming.
>
>> >    I assume that these things need to be added to "crypto/symhacks.h"
>> >    and/or "util/libeay.num".
>
>   Well, "util/.num".  Probably.  (Perhaps?)
>
> 
>
>   Steven M. Schweda               s...@antinode-info
>   382 South Warwick Street        (+1) 651-699-9818
>   Saint Paul  MN  55105-2547
> __
> OpenSSL Project                                 http://www.openssl.org
> Development Mailing List                       openssl-dev@openssl.org
> Automated List Manager                           majord...@openssl.org
>
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: OpenSSL 1.0.0 beta5 release v. VMS

2010-01-22 Thread Steven M. Schweda
   I think that some of the tests still have problems, but these changes
seem to help with the build:


gdiff -u crypto/symhacks.h_orig crypto/symhacks.h
--- crypto/symhacks.h_orig  2009-11-12 08:04:26 -0600
+++ crypto/symhacks.h   2010-01-22 16:05:16 -0600
@@ -177,6 +177,15 @@
 #undef SSL_COMP_get_compression_methods
 #define SSL_COMP_get_compression_methods   SSL_COMP_get_compress_methods
 
+#undef ssl_add_clienthello_renegotiate_ext
+#define ssl_add_clienthello_renegotiate_ext ssl_add_clnthello_reneg_ext
+#undef ssl_add_serverhello_renegotiate_ext
+#define ssl_add_serverhello_renegotiate_ext ssl_add_srvrhello_reneg_ext
+#undef ssl_parse_clienthello_renegotiate_ext
+#define ssl_parse_clienthello_renegotiate_ext   ssl_parse_clnthello_reneg_ext
+#undef ssl_parse_serverhello_renegotiate_ext
+#define ssl_parse_serverhello_renegotiate_ext   ssl_parse_srvrhello_reneg_ext
+
 /* Hack some long ENGINE names */
 #undef ENGINE_get_default_BN_mod_exp_crt
 #define ENGINE_get_default_BN_mod_exp_crt  ENGINE_get_def_BN_mod_exp_crt

   Spaces or tabs?  Seeing no consistency, I chose (copied) spaces.


gdiff -u ssl/ssl-lib.com_orig ssl/ssl-lib.com
--- ssl/ssl-lib.com_orig2009-05-15 11:37:06 -0500
+++ ssl/ssl-lib.com 2010-01-22 15:58:50 -0600
@@ -180,7 +180,7 @@
"ssl_lib,ssl_err2,ssl_cert,ssl_sess,"+ -
"ssl_ciph,ssl_stat,ssl_rsa,"+ -
"ssl_asn1,ssl_txt,ssl_algs,"+ -
-   "bio_ssl,ssl_err,kssl"
+   "bio_ssl,ssl_err,kssl,t1_reneg"
 $!
 $! Tell The User That We Are Compiling The Library.
 $!


gdiff -u util/ssleay.num_orig util/ssleay.num
--- util/ssleay.num_orig2009-07-08 04:13:24 -0500
+++ util/ssleay.num 2010-01-22 16:10:26 -0600
@@ -259,3 +259,11 @@
 SSL_set_session_ticket_ext_cb   308EXIST::FUNCTION:
 SSL_set1_param  309EXIST::FUNCTION:
 SSL_CTX_set1_param  310EXIST::FUNCTION:
+ssl_add_clienthello_renegotiate_ext 311EXIST:!VMS:FUNCTION:
+ssl_add_clnthello_reneg_ext 311EXIST:VMS:FUNCTION:
+ssl_add_serverhello_renegotiate_ext 312EXIST:!VMS:FUNCTION:
+ssl_add_srvrhello_reneg_ext 312EXIST:VMS:FUNCTION:
+ssl_parse_clienthello_renegotiate_ext   313EXIST:!VMS:FUNCTION:
+ssl_parse_clnthello_reneg_ext   313EXIST:VMS:FUNCTION:
+ssl_parse_serverhello_renegotiate_ext   314EXIST:!VMS:FUNCTION:
+ssl_parse_srvrhello_reneg_ext   314EXIST:VMS:FUNCTION:


   I changed the abbreviations a little from the first suggestions.  I
assumed that the "!VMS" things should be added.  Someone who knows
something may wish to revise that.  I saw no other lower-case "ssl_*"
things, which I find worrying.



   Steven M. Schweda   s...@antinode-info
   382 South Warwick Street(+1) 651-699-9818
   Saint Paul  MN  55105-2547
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: OpenSSL 1.0.0 beta5 release v. VMS

2010-01-22 Thread Kyle Hamilton
On Fri, Jan 22, 2010 at 2:54 PM, Steven M. Schweda  wrote:
>  SSL_set_session_ticket_ext_cb           308    EXIST::FUNCTION:
>  SSL_set1_param                          309    EXIST::FUNCTION:
>  SSL_CTX_set1_param                      310    EXIST::FUNCTION:
> +ssl_add_clienthello_renegotiate_ext     311    EXIST:!VMS:FUNCTION:
> +ssl_add_clnthello_reneg_ext             311    EXIST:VMS:FUNCTION:
> +ssl_add_serverhello_renegotiate_ext     312    EXIST:!VMS:FUNCTION:
> +ssl_add_srvrhello_reneg_ext             312    EXIST:VMS:FUNCTION:
> +ssl_parse_clienthello_renegotiate_ext   313    EXIST:!VMS:FUNCTION:
> +ssl_parse_clnthello_reneg_ext           313    EXIST:VMS:FUNCTION:
> +ssl_parse_serverhello_renegotiate_ext   314    EXIST:!VMS:FUNCTION:
> +ssl_parse_srvrhello_reneg_ext           314    EXIST:VMS:FUNCTION:
>
>
>   I changed the abbreviations a little from the first suggestions.  I
> assumed that the "!VMS" things should be added.  Someone who knows
> something may wish to revise that.  I saw no other lower-case "ssl_*"
> things, which I find worrying.

Lower-case ssl_* appears to be specifically related to the
implementation of the secure renegotiation indicator extension.  In
any case, they are internal routines and shouldn't be exported at all,
I should think, unless other extension parsing/adding code is
exported.

-Kyle H
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: OpenSSL 1.0.0 beta5 release v. VMS

2010-01-22 Thread Steven M. Schweda
From: Kyle Hamilton 

> Lower-case ssl_* appears to be specifically related to the
> implementation of the secure renegotiation indicator extension.  In
> any case, they are internal routines and shouldn't be exported at all,
> I should think, unless other extension parsing/adding code is
> exported.

   That sounds right.  Leaving "util/ssleay.num" unchanged seems to be
ok.  (I get carried away sometimes.)

   On the test front, there seem to be places where definitions of some
logical names and symbols seem to be assumed, but a clean environment
won't have them.  So far, I claim:

gdiff -u test/tests.com_orig test/tests.com
--- test/tests.com_orig 2009-11-13 02:45:52 -0600
+++ test/tests.com  2010-01-22 20:58:35 -0600
@@ -13,6 +13,9 @@
 $  exe_dir := sys$disk:[-.'__arch'.exe.apps]
 $
 $  set default '__here'
+$  sslroot = f$parse( "sys$disk:[-.apps];", , , , "syntax_only") - -
+"].;"+ ".]"
+$  define /translation_attributes = concealed sslroot 'sslroot'
 $
 $  on control_y then goto exit
 $  on error then goto exit
@@ -291,5 +294,6 @@
 $
 $
 $ exit:
+$  deassign sslroot
 $  set default '__save_default'
 $  exit

   In "test/testenc.com", running openssl fails when
"crypto/bio/bss_file.c" can't find "SSLROOT:[00]openssl.cnf", which,
I claim, is because SSLROOT is undefined.


gdiff -u test/testtsa.com_orig test/testtsa.com
--- test/testtsa.com_orig   2006-03-29 22:29:38 -0600
+++ test/testtsa.com2010-01-22 20:34:46 -0600
@@ -3,7 +3,9 @@
 $!
 $
 $  __arch := VAX
-$  if f$getsyi("cpu") .ge. 128 then __arch := AXP
+$  if f$getsyi("cpu") .ge. 128 then -
+  __arch = f$edit( f$getsyi( "ARCH_NAME"), "UPCASE")
+$  if __arch .eqs. "" then __arch := UNK
 $  exe_dir := sys$disk:[-.'__arch'.exe.apps]
 $
 $  openssl := mcr 'f$parse(exe_dir+"openssl.exe")'

   Old/obsolete use of "AXP" instead of the new f$getsyi( "ARCH_NAME").

   Also, is there any reason to use "mcr" here instead of "$"?


   Next thing(s) I haven't looked into:

Several complaints saying:
  unable to write 'random state'
(An example appears below.)

Also:

[...]
unable to write 'random state'
writing new private key to 'tsa_key1.pem'
-
Using configuration from [-]CATSA.CNF
Error Loading extension section TSA_CERT
2075840056:error:2006D080:BIO routines:BIO_new_file:no such 
file:ALP$DKA0:[UTILITY.SOURCE.OPENSSL.openssl-1^.0^.0-beta5.crypto.bio]bss_file.c;1:129:
2075840056:error:0E078072:configuration file routines:DEF_LOAD:no such 
file:ALP$DKA0:[UTILITY.SOURCE.OPENSSL.openssl-1^.0^.0-beta5.crypto.conf]conf_def.c;1:197:
2075840056:error:0E06D06C:configuration file routines:NCONF_get_string:no 
value:ALP$DKA0:[UTILITY.SOURCE.OPENSSL.openssl-1^.0^.0-beta5.crypto.conf]conf_lib.c;1:334:group=CA_default
 name=email_in_dn
unable to write 'random state'
[...]


   Are these problems new, or was I just not paying attention before?



   Steven M. Schweda   s...@antinode-info
   382 South Warwick Street(+1) 651-699-9818
   Saint Paul  MN  55105-2547
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org