Re: OpenSSL 1.0.0 beta5 release v. VMS
> Date: Thu, 18 Feb 2010 06:28:04 -0600 (CST)
>
> From: Arpadffy Zoltan
>
> > Also if it is not too late, it would be nice to add 32 at the end of the
> > sharable images if the are build with 32 bits pointer size (64 is the
> > default).
> >
> > I mean to have like this:
> > LIBCRYPTO32.OLB;1
> > LIBSSL32.OLB;1
> > LIBCRYPTO.OLB;1
> > LIBSSL.OLB;1
> > SSL_LIBCRYPTO_SHR32.EXE;1
> > SSL_LIBSSL_SHR32.EXE;1
> > SSL_LIBCRYPTO_SHR.EXE;1
> > SSL_LIBSSL_SHR.EXE;1
>
>For the record, HP's shareable images look like this:
>
> Directory SYS$COMMON:[SYSLIB]
>
> SSL$LIBCRYPTO_SHR.EXE;1
> SSL$LIBCRYPTO_SHR32.EXE;1
> SSL$LIBSSL_SHR.EXE;1
> SSL$LIBSSL_SHR32.EXE;1
>
>While not entirely trivial, it would be relatively easy to re-jigger
> the VMS builders to use different product-file directories for builds
> with /POINTER_SIZE = 32 and /POINTER_SIZE = 64 ('ARCH = ARCH+ "32"', or
> whatever), and then to produce (and install) the results with
> HP-like names. Also, I know of nothing which would stop users from
> linking (SET FILE /ENTER) any desired old names to the newer (better)
> "SSL_LIB*[32]" names. So, why, exactly, aren't we doing this?
Did I miss the discussion when this was all resolved? Or is no
decision the decision, so it'll all stay as it is (that is, different
from, and not so good as, HP's scheme)?
Other lingering complaints...
"vms/install.com" still hard-codes the procedure's own location
inside OPENSSL_STARTUP.COM, which causes everything to fail if the user
renames the installation directory. I'd prefer that OPENSSL_STARTUP.COM
use its own location to find the installation directory, as previously
suggested.
"makevms.com" still writes architecture-specific stuff into a
generated OPENSSLCONF.H file. I claim that all that stuff could be done
(once) in the "opensslconf.h.in" source file, as previously suggested.
When I last looked, "makevms.com" was still copying various source
and test files around, cluttering/corrupting the original source tree in
an unnecessary attempt to complensate for the lack of symbolic links on
VMS file systems (until recently, at least). Revised builder schemes to
avoid this have been previously suggested.
There are probably more items which belong here, but it's been a
while since I went through this frustrating exercise.
Or would evryone be happier if I just went away? (Or is VMS itself
(even) more of a nuisance than I am?)
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
From: Arpadffy Zoltan
> Also if it is not too late, it would be nice to add 32 at the end of the
> sharable images if the are build with 32 bits pointer size (64 is the
> default).
>
> I mean to have like this:
> LIBCRYPTO32.OLB;1
> LIBSSL32.OLB;1
> LIBCRYPTO.OLB;1
> LIBSSL.OLB;1
> SSL_LIBCRYPTO_SHR32.EXE;1
> SSL_LIBSSL_SHR32.EXE;1
> SSL_LIBCRYPTO_SHR.EXE;1
> SSL_LIBSSL_SHR.EXE;1
For the record, HP's shareable images look like this:
Directory SYS$COMMON:[SYSLIB]
SSL$LIBCRYPTO_SHR.EXE;1
SSL$LIBCRYPTO_SHR32.EXE;1
SSL$LIBSSL_SHR.EXE;1
SSL$LIBSSL_SHR32.EXE;1
While not entirely trivial, it would be relatively easy to re-jigger
the VMS builders to use different product-file directories for builds
with /POINTER_SIZE = 32 and /POINTER_SIZE = 64 ('ARCH = ARCH+ "32"', or
whatever), and then to produce (and install) the results with
HP-like names. Also, I know of nothing which would stop users from
linking (SET FILE /ENTER) any desired old names to the newer (better)
"SSL_LIB*[32]" names. So, why, exactly, aren't we doing this?
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
Hello, Also if it is not too late, it would be nice to add 32 at the end of the sharable images if the are build with 32 bits pointer size (64 is the default). I mean to have like this: LIBCRYPTO32.OLB;1 LIBSSL32.OLB;1 LIBCRYPTO.OLB;1 LIBSSL.OLB;1 SSL_LIBCRYPTO_SHR32.EXE;1 SSL_LIBSSL_SHR32.EXE;1 SSL_LIBCRYPTO_SHR.EXE;1 SSL_LIBSSL_SHR.EXE;1 This is also just a thought. Regards, Z -Original Message- From: Steven M. Schweda [mailto:s...@antinode.info] Sent: den 17 februari 2010 06:09 >Speaking of which, it's still not too late to add those "SSL_" >prefixes to the shared image names. Just a thought. -Original Message- From: Steven M. Schweda [mailto:s...@antinode.info] Sent: den 17 februari 2010 06:09 __ 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
> --- openssl-1.0.0-stable-SNAP-20100211/test/tests.com_orig2010-01-24
> 19:04:13 -0600
> +++ openssl-1.0.0-stable-SNAP-20100211/test/tests.com 2010-02-16 15:22:02
> -0600
> [...]
> +$set default '__here'
> +$sslroot = f$parse("sys$disk:[-.apps];""syntax_only") - "].;"+ ".]"
> +$define /translation_attributes = concealed sslroot 'sslroot'
> [...]
Isn't this the stuff we also decided to change to something more like
the following?
$ set default '__here'
$ set default [-.apps]
$ sslroot = f$parse( f$environment( "default"), , , , "no_conceal")
$ sslroot = sslroot - "][" - ".00" - "].;" + ".]"
$ define /translation_attributes = concealed sslroot 'sslroot'
$ set default '__here'
Either way, "set default '__here'" needs to be done before the other
work. (And, with "set default [-.apps]", it needs to be done again,
afterward.)
I'm losing track of which fixes are not getting incorporated into the
official source.
Speaking of which, it's still not too late to add those "SSL_"
prefixes to the shared image names. Just a thought.
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
> [...]
>Still many test problems like these:
>
> [...]
> Testing key generation with
> NIST Binary-Curve B-571
> .
> .
> .
> .
> ok
> cat
> WARNING: can't open config file: SSLROOT:[00]openssl.cnf
> WARNING: can't open config file: SSLROOT:[00]openssl.cnf
> [...]
--- openssl-1.0.0-stable-SNAP-20100211/test/tests.com_orig 2010-01-24
19:04:13 -0600
+++ openssl-1.0.0-stable-SNAP-20100211/test/tests.com 2010-02-16 15:22:02
-0600
@@ -12,14 +12,16 @@
$ texe_dir := sys$disk:[-.'__arch'.exe.test]
$ exe_dir := sys$disk:[-.'__arch'.exe.apps]
$
-$ sslroot = f$parse("sys$disk:[-.apps];""syntax_only") - "].;"+ ".]"
-$ define /translation_attributes = concealed sslroot 'sslroot'
-$
-$ set default '__here'
-$
$ on control_y then goto exit
$ on error then goto exit
$
+$ set default '__here'
+$ sslroot = f$parse("sys$disk:[-.apps];""syntax_only") - "].;"+ ".]"
+$ define /translation_attributes = concealed sslroot 'sslroot'
+$ write sys$output "''__proc"
+$ show logical sslroot
+$ directory /date /protection /size sslroot:[00]openssl.cnf
+$
$ if p1 .nes. ""
$ then
$ tests = p1
It might be nice if tests.com announced itself, instead of starting
silently. The "show logical sslroot" command helps the user find the
files being used. The "directory" command provides a quick failure if
"openssl.cnf" is not where it should be. These are not required for
proper operation. Setting the default directory properly before
assigning that value to the symbol "sslroot" is required. More white
space is ok with me.
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
From: Arpadffy Zoltan
> meanwhile I have tested the latest snapshot
> openssl-1.0.0-stable-SNAP-20100210.tar.gz and the build failed again,
> [...]
> Compiling The cversion.c File. (LIBRARY,LIB)
>
> #include "buildinf.h"
> .^
> %CC-F-NOINCLFILEF, Cannot find file "buildinf.h" specified in #include
> directive.
> at line number 62 in file
> USRDSK:[ZAY.WORK.OPENSSL-100-STABLE-SNAP-20100210.CRYPTO]CVERSION.C;1
[...]
The builder seems to be looking in the wrong place.
SYS$DISK:[.''ARCH'] -> SYS$DISK:[-.''ARCH'.CRYPTO]
ALP $ gdiff -u openssl-1.0.0-stable-SNAP-20100211/crypto/crypto-lib.com_orig
openssl-1.0.0-stable-SNAP-20100211/crypto/crypto-lib.com
--- openssl-1.0.0-stable-SNAP-20100211/crypto/crypto-lib.com_orig
2009-11-12 09:02:05 -0600
+++ openssl-1.0.0-stable-SNAP-20100211/crypto/crypto-lib.com2010-02-16
14:00:48 -0600
@@ -1034,7 +1034,9 @@
THEN CC = "CC/DECC"
$ CC = CC + "/''CC_OPTIMIZE'/''DEBUGGER'/STANDARD=ANSI89" + -
"/NOLIST/PREFIX=ALL" + -
-
"/INCLUDE=(SYS$DISK:[],SYS$DISK:[.''ARCH'],SYS$DISK:[-],SYS$DISK:[.ENGINE.VENDOR_DEFNS],SYS$DISK:[.EVP],SYS$DISK:[.ASN1])"
+ -
+ "/INCLUDE = (SYS$DISK:[], SYS$DISK:[-.''ARCH'.CRYPTO]," + -
+ " SYS$DISK:[-], SYS$DISK:[.ENGINE.VENDOR_DEFNS]," + -
+ " SYS$DISK:[.EVP], SYS$DISK:[.ASN1])" + -
CCEXTRAFLAGS
$!
$!Define The Linker Options File Name.
@@ -1068,7 +1070,9 @@
$ ENDIF
$ IF F$TRNLNM("DECC$CC_DEFAULT").EQS."/DECC" THEN CC = "CC/VAXC"
$ CC = CC + "/''CC_OPTIMIZE'/''DEBUGGER'/NOLIST" + -
-
"/INCLUDE=(SYS$DISK:[],SYS$DISK:[.''ARCH'],SYS$DISK:[-],SYS$DISK:[.ENGINE.VENDOR_DEFNS],SYS$DISK:[.EVP],SYS$DISK:[.ASN1])"
+ -
+ "/INCLUDE = (SYS$DISK:[], SYS$DISK:[-.''ARCH'.CRYPTO],"+ -
+ " SYS$DISK:[-], SYS$DISK:[.ENGINE.VENDOR_DEFNS],"+ -
+ " SYS$DISK:[.EVP], SYS$DISK:[.ASN1])" + -
CCEXTRAFLAGS
$ CCDEFS = """VAXC""," + CCDEFS
$!
@@ -1100,7 +1104,9 @@
$!Use GNU C...
$!
$ CC = "GCC/NOCASE_HACK/''GCC_OPTIMIZE'/''DEBUGGER'/NOLIST" + -
-
"/INCLUDE=(SYS$DISK:[],SYS$DISK:[.''ARCH'],SYS$DISK:[-],SYS$DISK:[.ENGINE.VENDOR_DEFNS],SYS$DISK:[.EVP],SYS$DISK:[.ASN1])"
+ -
+ "/INCLUDE = (SYS$DISK:[], SYS$DISK:[-.''ARCH'.CRYPTO],"+ -
+ " SYS$DISK:[-], SYS$DISK:[.ENGINE.VENDOR_DEFNS],"+ -
+ " SYS$DISK:[.EVP], SYS$DISK:[.ASN1])" + -
CCEXTRAFLAGS
$!
$!Define The Linker Options File Name.
Still many test problems like these:
[...]
Testing key generation with
NIST Binary-Curve B-571
.
.
.
.
ok
cat
WARNING: can't open config file: SSLROOT:[00]openssl.cnf
WARNING: can't open config file: SSLROOT:[00]openssl.cnf
base64
WARNING: can't open config file: SSLROOT:[00]openssl.cnf
WARNING: can't open config file: SSLROOT:[00]openssl.cnf
WARNING: can't open config file: SSLROOT:[00]openssl.cnf
[...]
> I just wonder is there any chance to keep the VMS build clean and
> stable?
Apparently not much of a chance. ("Chance is the fool's name for
Fate," I always say.)
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
Richard, -Original Message- From: Richard Levitte [mailto:rich...@levitte.org] Sent: den 29 januari 2010 11:51 To: openssl-dev@openssl.org Subject: Re: OpenSSL 1.0.0 beta5 release v. VMS In message <10012822544299_20205...@antinode.info> on Thu, 28 Jan 2010 22:54:43 -0600 (CST), "Steven M. Schweda" said: sms> From: Richard Levitte sms> sms> > In the mean time, I believe the latest snapshot has all my changes to sms> > date, which includes most if not all the patches I've seen from you in sms> > the latest few days... Worked for me, please try it out. meanwhile I have tested the latest snapshot openssl-1.0.0-stable-SNAP-20100210.tar.gz and the build failed again, when I was happy to see some clean builds earlier (like openssl-1.0.0-stable-SNAP-20100128.tar.gz for ex.) I have found the following failures. Compiling The cversion.c File. (LIBRARY,LIB) #include "buildinf.h" .^ %CC-F-NOINCLFILEF, Cannot find file "buildinf.h" specified in #include directive. at line number 62 in file USRDSK:[ZAY.WORK.OPENSSL-100-STABLE-SNAP-20100210.CRYPTO]CVERSION.C;1 and Compiling The TS.C File. %ILINK-W-NUDFSYMS, 2 undefined symbols: %ILINK-I-UDFSYM,SSLEAY %ILINK-I-UDFSYM,SSLEAY_VERSION %ILINK-W-USEUNDEF, undefined symbol SSLEAY_VERSION referenced section: $CODE$ offset: %X00011740 slot: 2 module: SPEED file: USRDSK:[ZAY.WORK.OPENSSL-100-STABLE-SNAP-20100210.IA64.OBJ.APPS]SPEED.OB J;1 I just wonder is there any chance to keep the VMS build clean and stable? Is there anything that I can do, help, contribute in order to achieve a stable VMS build, that almost any time I download a stable openssl code, I can be sure that it will build on VMS too? Richard, you are responsible for the VMS code health and through that for the VMS build status as well. I know that you are very busy (I guess like all of us here), but there should not be committed any VMS related code before a "clean VMS build" test passed. Please advice and order what can I do? I am willing to help and contribute to achieve a stable VMS build. Thank you. Regards, Z -Original Message- From: Richard Levitte [mailto:rich...@levitte.org] Sent: den 29 januari 2010 11:51 To: openssl-dev@openssl.org Subject: Re: OpenSSL 1.0.0 beta5 release v. VMS In message <10012822544299_20205...@antinode.info> on Thu, 28 Jan 2010 22:54:43 -0600 (CST), "Steven M. Schweda" said: sms> From: Richard Levitte sms> sms> > In the mean time, I believe the latest snapshot has all my changes to sms> > date, which includes most if not all the patches I've seen from you in sms> > the latest few days... Worked for me, please try it out. __ 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
In message <10012822544299_20205...@antinode.info> on Thu, 28 Jan 2010 22:54:43 -0600 (CST), "Steven M. Schweda" said: sms> From: Richard Levitte sms> sms> > In the mean time, I believe the latest snapshot has all my changes to sms> > date, which includes most if not all the patches I've seen from you in sms> > the latest few days... Worked for me, please try it out. sms> sms>"@ INSTALL.COM [dir]" from "openssl-1.0.0-stable-SNAP-20100127.tar.gz" sms> failed for me. Early on, when "crypto/install.com" was trying to copy sms> header files: sms> sms> [...] sms> %COPY-S-COPIED, ALP$DKA100:[UTILITY.SOURCE.OPENSSL.openssl-1^.0^.0-stable-SNAP-2 sms> 0100127.crypto]opensslv.h;1 sms> copied to WRK_SSLROOT:[INCLUDE]opensslv.h;1 (8 blocks) sms> %COPY-E-OPENIN, error opening ALP$DKA100:[UTILITY.SOURCE.OPENSSL.openssl-1^.0^.0 sms> -stable-SNAP-20100127.crypto]OPENSSLCONF.H; as input sms> -RMS-E-FNF, file not found sms> [...] sms> sms> And that seems to abort the procedure. sms> sms>With the "beta5" kit, it found that file: sms> sms> [...] sms> %COPY-S-COPIED, ALP$DKA0:[UTILITY.SOURCE.OPENSSL.openssl-1^.0^.0-beta5.crypto]op sms> ensslv.h;1 sms> copied to WRK_SSLROOT:[INCLUDE]opensslv.h;1 (8 blocks) sms> %COPY-S-COPIED, ALP$DKA0:[UTILITY.SOURCE.OPENSSL.openssl-1^.0^.0-beta5.crypto]op sms> ensslconf.h;1 sms> copied to WRK_SSLROOT:[INCLUDE]opensslconf.h;1 (12 blocks) sms> [...] sms> sms>The "beta5" kit included that file (VMSTAR listing): sms> sms> -rw-r--r-- 0/0 5960 Jan 20 09:09:10 2010 openssl-1.0.0-beta5/crypto/op sms> ensslconf.h sms> sms> But I don't see it in the "SNAP" kit. There seems to be a generated sms> file, "[.crypto.ALPHA]OPENSSLCONF.H". Is that what we should be copying sms> to to the destination "include" directory? Yes. crypto/install.com wasn't in sync with what makevms.com does. I'm changing that now, and will try it out in a few minutes. The snapshot shouldn't contain any opensslconf.h, as it should be generated on Unix as well... Why there is one is beyond my comprehension for now. I'll see it I can get some time to investigate that. sms>P.S.: I'm subscribed to the openssl-dev list, so direct e-mail is sms> redundant. Noted ;-) Cheers, Richard -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ "Life is a tremendous celebration - and I'm invited!" -- from a friend's blog, translated from Swedish __ 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
Hello, I have tested OPENSSL-100-STABLE-SNAP-20100128 and the build went well. But the tests still fail: 1. the rootssl issue, that worked well after changing to your patch 2. The tests fails and ends with seed related issue. Do yo8 have any idea how to solve this? There is a .rnd file in the current directory and even setting the RANDFILE environment variable did not help. Certificate is to be certified until Jan 28 15:27:12 2011 GMT (365 days) Sign the certificate? [y/n]:2071080376:error:24064064:random number generator:SSLEAY_RAND_BYTES:PRNG not seeded:USRDSK:[ZA Y.WORK.OPENSSL-100-STABLE-SNAP-20100128.CRYPTO.RAND]MD_RAND.C;1:519:You need to read the OpenSSL FAQ, http://www.openssl.o rg/support/faq.html 2071080376:error:04088003:rsa routines:RSA_setup_blinding:BN lib:USRDSK:[ZAY.WORK.OPENSSL-100-STABLE-SNAP-20100128.CRYPTO. RSA]RSA_LIB.C;1:426: 2071080376:error:04066044:rsa routines:RSA_EAY_PRIVATE_ENCRYPT:internal error:USRDSK:[ZAY.WORK.OPENSSL-100-STABLE-SNAP-201 00128.CRYPTO.RSA]RSA_EAY.C;1:403: 2071080376:error:0D0C3006:asn1 encoding routines:ASN1_item_sign:EVP lib:USRDSK:[ZAY.WORK.OPENSSL-100-STABLE-SNAP-20100128. CRYPTO.ASN1]A_SIGN.C;1:279: 3. the recently fixed testtsa.com has the same problem. @testtsa.com Setting up TSA test directory... Creating CA for TSA tests... Creating a new CA for the TSA tests... unable to load 'random state' This means that the random number generator has not been seeded with much random data. Generating a 1024 bit RSA private key Error Generating Key 2071080376:error:24064064:random number generator:SSLEAY_RAND_BYTES:PRNG not seeded:USRDSK:[ZAY.WORK.OPENSSL-100-STABLE-SN AP-20100128.CRYPTO.RAND]MD_RAND.C;1:519:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html 2071080376:error:04081003:rsa routines:RSA_BUILTIN_KEYGEN:BN lib:USRDSK:[ZAY.WORK.OPENSSL-100-STABLE-SNAP-20100128.CRYPTO. RSA]RSA_GEN.C;1:208: Do you have any suggestion? Thank you. Regards, Z -Original Message- From: Steven M. Schweda [mailto:s...@antinode.info] Sent: den 29 januari 2010 05:55 To: openssl-dev@openssl.org Subject: Re: OpenSSL 1.0.0 beta5 release v. VMS From: Richard Levitte > In the mean time, I believe the latest snapshot has all my changes to > date, which includes most if not all the patches I've seen from you in > the latest few days... Worked for me, please try it out. "@ INSTALL.COM [dir]" from "openssl-1.0.0-stable-SNAP-20100127.tar.gz" failed for me. Early on, when "crypto/install.com" was trying to copy header files: [...] %COPY-S-COPIED, ALP$DKA100:[UTILITY.SOURCE.OPENSSL.openssl-1^.0^.0-stable-SNAP-2 0100127.crypto]opensslv.h;1 copied to WRK_SSLROOT:[INCLUDE]opensslv.h;1 (8 blocks) %COPY-E-OPENIN, error opening ALP$DKA100:[UTILITY.SOURCE.OPENSSL.openssl-1^.0^.0 -stable-SNAP-20100127.crypto]OPENSSLCONF.H; as input -RMS-E-FNF, file not found [...] And that seems to abort the procedure. With the "beta5" kit, it found that file: [...] %COPY-S-COPIED, ALP$DKA0:[UTILITY.SOURCE.OPENSSL.openssl-1^.0^.0-beta5.crypto]op ensslv.h;1 copied to WRK_SSLROOT:[INCLUDE]opensslv.h;1 (8 blocks) %COPY-S-COPIED, ALP$DKA0:[UTILITY.SOURCE.OPENSSL.openssl-1^.0^.0-beta5.crypto]op ensslconf.h;1 copied to WRK_SSLROOT:[INCLUDE]opensslconf.h;1 (12 blocks) [...] The "beta5" kit included that file (VMSTAR listing): -rw-r--r-- 0/0 5960 Jan 20 09:09:10 2010 openssl-1.0.0-beta5/crypto/op ensslconf.h But I don't see it in the "SNAP" kit. There seems to be a generated file, "[.crypto.ALPHA]OPENSSLCONF.H". Is that what we should be copying to to the destination "include" directory? P.S.: I'm subscribed to the openssl-dev list, so direct e-mail is redundant. SMS. __ 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
From: Richard Levitte > In the mean time, I believe the latest snapshot has all my changes to > date, which includes most if not all the patches I've seen from you in > the latest few days... Worked for me, please try it out. "@ INSTALL.COM [dir]" from "openssl-1.0.0-stable-SNAP-20100127.tar.gz" failed for me. Early on, when "crypto/install.com" was trying to copy header files: [...] %COPY-S-COPIED, ALP$DKA100:[UTILITY.SOURCE.OPENSSL.openssl-1^.0^.0-stable-SNAP-2 0100127.crypto]opensslv.h;1 copied to WRK_SSLROOT:[INCLUDE]opensslv.h;1 (8 blocks) %COPY-E-OPENIN, error opening ALP$DKA100:[UTILITY.SOURCE.OPENSSL.openssl-1^.0^.0 -stable-SNAP-20100127.crypto]OPENSSLCONF.H; as input -RMS-E-FNF, file not found [...] And that seems to abort the procedure. With the "beta5" kit, it found that file: [...] %COPY-S-COPIED, ALP$DKA0:[UTILITY.SOURCE.OPENSSL.openssl-1^.0^.0-beta5.crypto]op ensslv.h;1 copied to WRK_SSLROOT:[INCLUDE]opensslv.h;1 (8 blocks) %COPY-S-COPIED, ALP$DKA0:[UTILITY.SOURCE.OPENSSL.openssl-1^.0^.0-beta5.crypto]op ensslconf.h;1 copied to WRK_SSLROOT:[INCLUDE]opensslconf.h;1 (12 blocks) [...] The "beta5" kit included that file (VMSTAR listing): -rw-r--r-- 0/0 5960 Jan 20 09:09:10 2010 openssl-1.0.0-beta5/crypto/op ensslconf.h But I don't see it in the "SNAP" kit. There seems to be a generated file, "[.crypto.ALPHA]OPENSSLCONF.H". Is that what we should be copying to to the destination "include" directory? P.S.: I'm subscribed to the openssl-dev list, so direct e-mail is redundant. SMS. __ 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
Hello Steven, > The following looks ok to me (but so did the previous stuff): The difference is noticeable. This one works perfect for me too :) Thank you very much... It would be good if Richard could merge this into the tests.com file. Regards, Z -Original Message- From: Steven M. Schweda [mailto:s...@antinode.info] Sent: den 27 januari 2010 22:13 To: openssl-dev@openssl.org Subject: Re: OpenSSL 1.0.0 beta5 release v. VMS From: Arpadffy Zoltan > Could you please write that DEFINE/NOLOG SSLROOT [...] _You_'re the one with all the "00" stuff, so I thought that I could get _you_ to do it. Sigh. The following looks ok to me (but so did the previous stuff): $ $ set default '__here' $ set default [-.apps] $ sslroot = f$parse( f$environment( "default"), , , , "no_conceal") $ sslroot = sslroot - "][" - ".00" - "].;" + ".]" $ define /translation_attributes = concealed sslroot 'sslroot' $ set default '__here' $ By the way, building on HP-UX and Solaris, I noticed thet the JPAKE stuff is "experimental", and not included in the builds by default. And, if it is included, the test fails in the same way. If it really doesn't work, then perhaps it should be excluded from the VMS build. (Or done last.) 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
In message <10012715132025_20205...@antinode.info> on Wed, 27 Jan 2010 15:13:20 -0600 (CST), "Steven M. Schweda" said: sms>By the way, building on HP-UX and Solaris, I noticed thet the sms> JPAKE stuff is "experimental", and not included in the builds by sms> default. And, if it is included, the test fails in the same way. sms> If it really doesn't work, then perhaps it should be excluded sms> from the VMS build. (Or done last.) To brand some algorithms as experimental is fairly new and hasn't been reflected in the VMS build fu. I'll have a look at it tomorrow. In the mean time, I believe the latest snapshot has all my changes to date, which includes most if not all the patches I've seen from you in the latest few days... Worked for me, please try it out. Cheers, Richard -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ "Life is a tremendous celebration - and I'm invited!" -- from a friend's blog, translated from Swedish __ 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
From: Arpadffy Zoltan > Could you please write that DEFINE/NOLOG SSLROOT [...] _You_'re the one with all the "00" stuff, so I thought that I could get _you_ to do it. Sigh. The following looks ok to me (but so did the previous stuff): $ $ set default '__here' $ set default [-.apps] $ sslroot = f$parse( f$environment( "default"), , , , "no_conceal") $ sslroot = sslroot - "][" - ".00" - "].;" + ".]" $ define /translation_attributes = concealed sslroot 'sslroot' $ set default '__here' $ By the way, building on HP-UX and Solaris, I noticed thet the JPAKE stuff is "experimental", and not included in the builds by default. And, if it is included, the test fails in the same way. If it really doesn't work, then perhaps it should be excluded from the VMS build. (Or done last.) 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
Hello Steven, Could you please write that DEFINE/NOLOG SSLROOT on a way that you described and test on your system (I guess ODS5) and I could test on mine later as well. Thank you in advance. Regards, Z -Original Message- From: Steven M. Schweda [mailto:s...@antinode.info] Sent: den 27 januari 2010 15:08 To: openssl-dev@openssl.org Subject: Re: OpenSSL 1.0.0 beta5 release v. VMS From: Arpadffy Zoltan > I have been forced to do it on more old fashioned way in order to get > this work > > $ ROOT =3D F$PARSE(__here,"[]A.;0",,,"SYNTAX_ONLY,NO_CONCEAL") - > "A.;0" > $ ROOT_DEV =3D F$PARSE(ROOT,,,"DEVICE","SYNTAX_ONLY") > $ ROOT_DIR =3D F$PARSE(ROOT,,,"DIRECTORY","SYNTAX_ONLY") - >- ".][00" - "[00." - "][" - "[" - "]" - > ".TEST" > $ ROOT =3D ROOT_DEV + "[" + ROOT_DIR > $ DEFINE/NOLOG SSLROOT 'ROOT'.APPS.] /TRANS=3DCONC Using '- ".TEST"' like that will fail on an ODS5 file system where the directory is named "test", not "TEST". Better to use something like this: ROOT_DIR = F$PARSE(ROOT,,,"DIRECTORY","SYNTAX_ONLY") - - ".][00" - "[00." - "][" - "[" set default "''ROOT_DEV'[''ROOT_DIR'" set default [-.apps] Then use f$environment( "DEFAULT") to get the actual dev:[dir] string, and add the dot to that. "SET DEFAULT [-]" is safe on any file system. 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
From: Arpadffy Zoltan > I have been forced to do it on more old fashioned way in order to get > this work > > $ ROOT =3D F$PARSE(__here,"[]A.;0",,,"SYNTAX_ONLY,NO_CONCEAL") - > "A.;0" > $ ROOT_DEV =3D F$PARSE(ROOT,,,"DEVICE","SYNTAX_ONLY") > $ ROOT_DIR =3D F$PARSE(ROOT,,,"DIRECTORY","SYNTAX_ONLY") - >- ".][00" - "[00." - "][" - "[" - "]" - > ".TEST" > $ ROOT =3D ROOT_DEV + "[" + ROOT_DIR > $ DEFINE/NOLOG SSLROOT 'ROOT'.APPS.] /TRANS=3DCONC Using '- ".TEST"' like that will fail on an ODS5 file system where the directory is named "test", not "TEST". Better to use something like this: ROOT_DIR = F$PARSE(ROOT,,,"DIRECTORY","SYNTAX_ONLY") - - ".][00" - "[00." - "][" - "[" set default "''ROOT_DEV'[''ROOT_DIR'" set default [-.apps] Then use f$environment( "DEFAULT") to get the actual dev:[dir] string, and add the dot to that. "SET DEFAULT [-]" is safe on any file system. 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
e To EXIT. $! $ GOTO TIDY $! $! End The Valid Argument Check. $! $ ENDIF $ ENDIF $! End The P2 Check. ... and further down add this to compiler flags: $! Write The [.CRYPTO.]BUILDINF.H File. $! $ WRITE H_FILE "#define CFLAGS ""/pointer_size=''POINTER_SIZE'/float=g"" /* compiler flags */" Can anybody send a comment regarding those issues? Thank you in advance. Regards, Z -Original Message- From: Richard Levitte [mailto:rich...@levitte.org] Sent: den 27 januari 2010 02:20 To: openssl-dev@openssl.org; s...@antinode.info Subject: Re: OpenSSL 1.0.0 beta5 release v. VMS OK, I've gone through and tested the script... it works for me, I hope it works for you. Cheers, Richard In message <20100125.112009.189705375.rich...@levitte.org> on Mon, 25 Jan 2010 11:20:09 +0100 (CET), Richard Levitte said: richard> I just had a look at testtsa.com, and yeah, the corresponding shell richard> script has evolved since testtsa.com was last updated. Working on it richard> right now. richard> richard> Cheers, richard> Richard richard> richard> In message <10012423165954_20205...@antinode.info> on Sun, 24 Jan 2010 23:16:59 -0600 (CST), "Steven M. Schweda" said: richard> richard> sms> From: Richard Levitte richard> sms> richard> sms> > Might be a fault in test/testtsa.com... I'll see if I can find richard> sms> > something there... richard> sms> richard> sms>I got some improvement by trying harder to preserve case in some richard> sms> places: richard> sms> richard> sms> -$ call create_tsa_cert 1 tsa_cert richard> sms> +$ call create_tsa_cert 1 "tsa_cert" richard> sms> richard> sms> -$ call create_tsa_cert 2 non_tsa_cert richard> sms> +$ call create_tsa_cert 2 "non_tsa_cert" richard> sms> richard> sms> Knowing nothing, I'd guess that the missing "TSA_CERT" was actually richard> sms> supposed to be "tsa_cert". I normally run with Parse Style: Extended, richard> sms> and that may make me more vulnerable to these things. Or, it could just richard> sms> be lame DCL. (Finally, there's a good reason to use: richard> sms> X = "aBc" richard> sms> instead of: richard> sms> X := aBc richard> sms> among other things.) richard> sms> richard> sms> And correcting some file names: richard> sms> richard> sms> -$ open/write file VMStsa-response1.create_tsa_cert richard> sms> +$ open/write file VMStsa-response_1.create_tsa_cert richard> sms> richard> sms> -$ define/user sys$input VMStsa-response.create_tsa_cert richard> sms> +$ define/user sys$input VMStsa-response_1.create_tsa_cert richard> sms> richard> sms> -$ open/write file VMStsa-response2.create_tsa_cert richard> sms> +$ open/write file VMStsa-response_2.create_tsa_cert richard> sms> richard> sms> -$ define/user sys$input VMStsa-response.create_tsa_cert richard> sms> +$ define/user sys$input VMStsa-response_2.create_tsa_cert richard> sms> richard> sms> Creating a file named one thing and then using a file named some other richard> sms> thing looked suspicious to me. richard> sms> richard> sms>The next problem I saw in that test: richard> sms> richard> sms> unable to load certificates: ./tsaca.pem richard> sms> richard> sms> seems to be an inability to find a file specified in the ".cnf" file: richard> sms> richard> sms> certs = $dir/tsaca.pem richard> sms> richard> sms> The shell script seems to say things like "-out tsaca.pem -keyout richard> sms> tsacakey.pem", while the DCL never mentions "tsaca.pem". Either more richard> sms> code theft or else less would seem to be in order here. richard> sms> richard> sms> richard> sms> richard> sms>Steven M. Schweda s...@antinode-info richard> sms>382 South Warwick Street(+1) 651-699-9818 richard> sms>Saint Paul MN 55105-2547 richard> sms> __ richard> sms> OpenSSL Project http://www.openssl.org richard> sms> Development Mailing List openssl-dev@openssl.org richard> sms> Automated List Manager majord...@openssl.org - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ "Life is a tremendous celebration - and I'm invited!" -- from a friend's blog, translated from Swedish __ 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
OK, I've gone through and tested the script... it works for me, I hope it works for you. Cheers, Richard In message <20100125.112009.189705375.rich...@levitte.org> on Mon, 25 Jan 2010 11:20:09 +0100 (CET), Richard Levitte said: richard> I just had a look at testtsa.com, and yeah, the corresponding shell richard> script has evolved since testtsa.com was last updated. Working on it richard> right now. richard> richard> Cheers, richard> Richard richard> richard> In message <10012423165954_20205...@antinode.info> on Sun, 24 Jan 2010 23:16:59 -0600 (CST), "Steven M. Schweda" said: richard> richard> sms> From: Richard Levitte richard> sms> richard> sms> > Might be a fault in test/testtsa.com... I'll see if I can find richard> sms> > something there... richard> sms> richard> sms>I got some improvement by trying harder to preserve case in some richard> sms> places: richard> sms> richard> sms> -$ call create_tsa_cert 1 tsa_cert richard> sms> +$ call create_tsa_cert 1 "tsa_cert" richard> sms> richard> sms> -$ call create_tsa_cert 2 non_tsa_cert richard> sms> +$ call create_tsa_cert 2 "non_tsa_cert" richard> sms> richard> sms> Knowing nothing, I'd guess that the missing "TSA_CERT" was actually richard> sms> supposed to be "tsa_cert". I normally run with Parse Style: Extended, richard> sms> and that may make me more vulnerable to these things. Or, it could just richard> sms> be lame DCL. (Finally, there's a good reason to use: richard> sms> X = "aBc" richard> sms> instead of: richard> sms> X := aBc richard> sms> among other things.) richard> sms> richard> sms> And correcting some file names: richard> sms> richard> sms> -$ open/write file VMStsa-response1.create_tsa_cert richard> sms> +$ open/write file VMStsa-response_1.create_tsa_cert richard> sms> richard> sms> -$ define/user sys$input VMStsa-response.create_tsa_cert richard> sms> +$ define/user sys$input VMStsa-response_1.create_tsa_cert richard> sms> richard> sms> -$ open/write file VMStsa-response2.create_tsa_cert richard> sms> +$ open/write file VMStsa-response_2.create_tsa_cert richard> sms> richard> sms> -$ define/user sys$input VMStsa-response.create_tsa_cert richard> sms> +$ define/user sys$input VMStsa-response_2.create_tsa_cert richard> sms> richard> sms> Creating a file named one thing and then using a file named some other richard> sms> thing looked suspicious to me. richard> sms> richard> sms>The next problem I saw in that test: richard> sms> richard> sms> unable to load certificates: ./tsaca.pem richard> sms> richard> sms> seems to be an inability to find a file specified in the ".cnf" file: richard> sms> richard> sms> certs = $dir/tsaca.pem richard> sms> richard> sms> The shell script seems to say things like "-out tsaca.pem -keyout richard> sms> tsacakey.pem", while the DCL never mentions "tsaca.pem". Either more richard> sms> code theft or else less would seem to be in order here. richard> sms> richard> sms> richard> sms> richard> sms>Steven M. Schweda s...@antinode-info richard> sms>382 South Warwick Street(+1) 651-699-9818 richard> sms>Saint Paul MN 55105-2547 richard> sms> __ richard> sms> OpenSSL Project http://www.openssl.org richard> sms> Development Mailing List openssl-dev@openssl.org richard> sms> Automated List Manager majord...@openssl.org - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ "Life is a tremendous celebration - and I'm invited!" -- from a friend's blog, translated from Swedish __ 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
Hello,
I have downloaded openssl-1.0.0-stable-SNAP-20100125.tar.gz and tested and it
looks much better then earlier.
Thank you.
However there are still some issues left with tests.
1. in <.test>tests.com sslroot definition does not work
$ sslroot = f$parse("sys$disk:[-.apps];""syntax_only") - "].;"+ ".]"
$ define /translation_attributes = concealed sslroot 'sslroot'
I have been forced to do it on more old fashioned way in order to get this work
$ ROOT = F$PARSE(__here,"[]A.;0",,,"SYNTAX_ONLY,NO_CONCEAL") - "A.;0"
$ ROOT_DEV = F$PARSE(ROOT,,,"DEVICE","SYNTAX_ONLY")
$ ROOT_DIR = F$PARSE(ROOT,,,"DIRECTORY","SYNTAX_ONLY") -
- ".][00" - "[00." - "][" - "[" - "]" - ".TEST"
$ ROOT = ROOT_DEV + "[" + ROOT_DIR
$ DEFINE/NOLOG SSLROOT 'ROOT'.APPS.] /TRANS=CONC
2. there are still problems with testtsa.com but Richard works on that if I
understood correctly.
Using configuration from [-]CATSA.CNF
Error Loading extension section TSA_CERT
2071080376:error:02001002:system library:fopen:no such file or
directory:USRDSK:[ZAY.WORK.OPENSSL-100-STABLE-SNAP-20100125
.CRYPTO.BIO]BSS_FILE.C;1:126:fopen('./demoCA/index.txt-attr','r')
3. Manually started JPAKETEST fails!!!
TITAN2_ZAY $ mc
USRDSK:JPAKETEST.EXE
p =
F9E5B365665EA7A05A9C534502780FEE6F1AB5BD4F49947FD036DBD7E905269AF46EF28B0FC07487EE4F5D20FB3C0AF8E700F3A2FA3414970CBED4
4FEDFF80CE78D800F184BB82435D137AADA2C6C16523247930A63B85661D1FC817A51ACD96168E95898A1F83A79FFB529368AA7833ABD1B0C3AEDDB14D
2E1A2F71D99F763F
g = 2
q =
7CF2D9B2B32F53D02D4E29A2813C07F7378D5ADEA7A4CA3FE81B6DEBF482934D7A37794587E03A43F727AE907D9E057C738079D17D1A0A4B865F6A
27F6FFC0673C6C0078C25DC121AE89BD56D16360B291923C98531DC2B30E8FE40BD28D66CB0B474AC4C50FC1D3CFFDA949B4553C19D5E8D861D76ED8A6
970D17B8ECCFBB1F
A->B s1
B->A s1
A->B s2
B->A s2
Alice's key =
3722C81D780857B4AAE63D109950698938A846C11E616ED29419A986C6D813E35F6969F9B2C70DD399437978DEAE71606425ADF08D7D
3459B0D8EB19B21D732A038A478B0BAF7A818E5266D75A1097D3F43384D6A9F2DD774AB67D282DF907DD2519F2A5185792DAE8C742BD4D4E91340DDBB0
8956856284831D9E3C475BF150
Bob's key =
3722C81D780857B4AAE63D109950698938A846C11E616ED29419A986C6D813E35F6969F9B2C70DD399437978DEAE71606425ADF08D7D
3459B0D8EB19B21D732A038A478B0BAF7A818E5266D75A1097D3F43384D6A9F2DD774AB67D282DF907DD2519F2A5185792DAE8C742BD4D4E91340DDBB0
8956856284831D9E3C475BF150
A->B s3a
B->A s3b
A->B s1
B->A s1
A->B s2
B->A s2
Alice's key =
A7F469FF38ED3BA3225E1B05A8B44F3643A9128E4E0D2E225744CD58DE55C5D02276E4011B27A91AEEF3AE6B43D827CC61E6D2E933A5
E8C0601A0E25B434402F8AB9C04855F06794436D592FBE922ED027A37B285207C30F63A25115433DA1F8499CB8B5A09D945981489C18CED798944B873E
37DA5200793F2F5283A3BA2704
Bob's key =
F2FFD37A8934C66480E43F126DC9EB79CBD4F82ACC0686434407A83AFCCC467FDDD50B5C5DCE74CCE490027033E411701F80C62DE0F9
BFC1611DBD2F1249C3ACC13E724AFBFC10120F57DC304DD6EF7A972DBA33C5008776486ACAF4A0EE5AB2958E8585A0A94BF7E77805DED664956532DBDC
BA4602C2AD1791C917F9CFDF19
A->B s3a
Bob fails to process Alice's step 3a
2071080376:error:3106706A:lib(49):JPAKE_STEP3A_process:hash of hash of key
mismatch:USRDSK:[ZAY.WORK.OPENSSL-100-STABLE-SN
AP-20100125.CRYPTO.JPAKE]JPAKE.C;1:443:
4. igetest - exe does not exists at all. We're not building at all?
5. I have suggested earlier and sent a patch for using the second (currently
empty, unused) parameter for configuring 32 or 64 bit pointer size.
I still think that it would be useful to have.
$!
$! Check To See If P2 Is Blank.
$!
$ IF (P2.EQS."32")
$ THEN
$POINTER_SIZE = "32"
$ ELSE
$ IF (P3.EQS."64")
$ THEN
$ POINTER_SIZE = "64"
$ ELSE
$!
$!Tell The User Entered An Invalid Option..
$!
$ WRITE SYS$OUTPUT ""
$ WRITE SYS$OUTPUT "The Option ",P2," Is Invalid. The Valid Options Are:"
$ WRITE SYS$OUTPUT ""
$ WRITE SYS$OUTPUT "32 : Compile with 32 bit pointer size"
$ WRITE SYS$OUTPUT "64 : Compile with 64 bit pointer size"
$ WRITE SYS$OUTPUT ""
$!
$!Time To EXIT.
$!
$ GOTO TIDY
$!
$! End The Valid Argument Check.
$!
$ ENDIF
$ ENDIF
$! End The P2 Check.
... and further down add this to compiler flags:
$! Write The [.CRYPTO.]BUILDINF.H File.
$!
$ WRITE H_FILE "#define CFLAGS ""/pointer_size=''POINTER_SIZE'/float=g"" /*
compiler flags */"
Regards,
Z
-Original Message-
From: Richard Levitte [mailto:rich...@levitte.org]
Sent: den 25 januari 2010 01:26
To: openssl-dev@openssl.org; s...@antinode.info
Subject: Re: OpenSSL 1.0.0 beta5 release v. VMS
For VMS folks, please have a look
Re: OpenSSL 1.0.0 beta5 release v. VMS
From: Richard Levitte > I just had a look at testtsa.com, and yeah, the corresponding shell > script has evolved since testtsa.com was last updated. Working on it > right now. Skipping that one, ... ALP $ @ tests test_ige Test IGE mode %DCL-W-ACTIMAGE, error activating image SYS$DISK:[-.ALPHA.EXE.TEST]IGETEST -CLI-E-IMAGEFNF, image file not found ALP$DKA0:[UTILITY.SOURCE.OPENSSL.OPENSSL-1 ^.0^.0-BETA5.ALPHA.EXE.TEST]IGETEST.EXE; ALP $ @ tests test_jpake Test JPAKE [...] A->B s3a Bob fails to process Alice's step 3a 2075840056:error:3106706A:lib(49):JPAKE_STEP3A_process:hash of hash of key misma tch:ALP$DKA0:[UTILITY.SOURCE.OPENSSL.openssl-1^.0^.0-beta5.crypto.jpake]jpake.c; 1:443: ALP $ @ tests test_cms CMS consistency test Can't find OpenSSL executable at cms-test.pl line 68. %RMS-F-SYN, file specification syntax error 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
I just had a look at testtsa.com, and yeah, the corresponding shell script has evolved since testtsa.com was last updated. Working on it right now. Cheers, Richard In message <10012423165954_20205...@antinode.info> on Sun, 24 Jan 2010 23:16:59 -0600 (CST), "Steven M. Schweda" said: sms> From: Richard Levitte sms> sms> > Might be a fault in test/testtsa.com... I'll see if I can find sms> > something there... sms> sms>I got some improvement by trying harder to preserve case in some sms> places: sms> sms> -$ call create_tsa_cert 1 tsa_cert sms> +$ call create_tsa_cert 1 "tsa_cert" sms> sms> -$ call create_tsa_cert 2 non_tsa_cert sms> +$ call create_tsa_cert 2 "non_tsa_cert" sms> sms> Knowing nothing, I'd guess that the missing "TSA_CERT" was actually sms> supposed to be "tsa_cert". I normally run with Parse Style: Extended, sms> and that may make me more vulnerable to these things. Or, it could just sms> be lame DCL. (Finally, there's a good reason to use: sms> X = "aBc" sms> instead of: sms> X := aBc sms> among other things.) sms> sms> And correcting some file names: sms> sms> -$ open/write file VMStsa-response1.create_tsa_cert sms> +$ open/write file VMStsa-response_1.create_tsa_cert sms> sms> -$ define/user sys$input VMStsa-response.create_tsa_cert sms> +$ define/user sys$input VMStsa-response_1.create_tsa_cert sms> sms> -$ open/write file VMStsa-response2.create_tsa_cert sms> +$ open/write file VMStsa-response_2.create_tsa_cert sms> sms> -$ define/user sys$input VMStsa-response.create_tsa_cert sms> +$ define/user sys$input VMStsa-response_2.create_tsa_cert sms> sms> Creating a file named one thing and then using a file named some other sms> thing looked suspicious to me. sms> sms>The next problem I saw in that test: sms> sms> unable to load certificates: ./tsaca.pem sms> sms> seems to be an inability to find a file specified in the ".cnf" file: sms> sms> certs = $dir/tsaca.pem sms> sms> The shell script seems to say things like "-out tsaca.pem -keyout sms> tsacakey.pem", while the DCL never mentions "tsaca.pem". Either more sms> code theft or else less would seem to be in order here. sms> sms> sms> sms>Steven M. Schweda s...@antinode-info sms>382 South Warwick Street(+1) 651-699-9818 sms>Saint Paul MN 55105-2547 sms> __ sms> OpenSSL Project http://www.openssl.org sms> Development Mailing List openssl-dev@openssl.org sms> Automated List Manager majord...@openssl.org - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ "Life is a tremendous celebration - and I'm invited!" -- from a friend's blog, translated from Swedish __ 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
From: Richard Levitte > Might be a fault in test/testtsa.com... I'll see if I can find > something there... I got some improvement by trying harder to preserve case in some places: -$ call create_tsa_cert 1 tsa_cert +$ call create_tsa_cert 1 "tsa_cert" -$ call create_tsa_cert 2 non_tsa_cert +$ call create_tsa_cert 2 "non_tsa_cert" Knowing nothing, I'd guess that the missing "TSA_CERT" was actually supposed to be "tsa_cert". I normally run with Parse Style: Extended, and that may make me more vulnerable to these things. Or, it could just be lame DCL. (Finally, there's a good reason to use: X = "aBc" instead of: X := aBc among other things.) And correcting some file names: -$ open/write file VMStsa-response1.create_tsa_cert +$ open/write file VMStsa-response_1.create_tsa_cert -$ define/user sys$input VMStsa-response.create_tsa_cert +$ define/user sys$input VMStsa-response_1.create_tsa_cert -$ open/write file VMStsa-response2.create_tsa_cert +$ open/write file VMStsa-response_2.create_tsa_cert -$ define/user sys$input VMStsa-response.create_tsa_cert +$ define/user sys$input VMStsa-response_2.create_tsa_cert Creating a file named one thing and then using a file named some other thing looked suspicious to me. The next problem I saw in that test: unable to load certificates: ./tsaca.pem seems to be an inability to find a file specified in the ".cnf" file: certs = $dir/tsaca.pem The shell script seems to say things like "-out tsaca.pem -keyout tsacakey.pem", while the DCL never mentions "tsaca.pem". Either more code theft or else less would seem to be in order here. 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
For VMS folks, please have a look at upcoming snapshots. I've applied the recent changes suggest by Steven M. Schweda and changed test/CAtsa.cnf following his comments on the use of $ENV::HOME there... I have performed no tests yes following the changes, so I do not know what the result will be. I'll keep on working on this in the week that follows. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ "Life is a tremendous celebration - and I'm invited!" -- from a friend's blog, translated from Swedish __ 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
In message <10012317353256_20205...@antinode.info> on Sat, 23 Jan 2010 17:35:32
-0600 (CST), "Steven M. Schweda" said:
sms>One cause seems to be this stuff in "tests/CAtsa.cnf":
sms>
sms> [...]
sms> # This definition stops the following lines choking if HOME isn't
sms> # defined.
sms> HOME= .
sms> RANDFILE= $ENV::HOME/.rnd
sms> [...]
sms>
sms> All the other "tests/*.cnf" files seem to say this (which seems to be
sms> harmless):
sms>
sms> RANDFILE = ./.rnd
Unless someone gives me a really good reason for CAtsa.cnf being
different than the other config files, I think change CAtsa.cnf is the
way to go. It's just a test, basically...
sms>That still leaves all this stuff:
sms>
sms> [...]
sms> -
sms> Using configuration from [-]CATSA.CNF
sms> Error Loading extension section TSA_CERT
sms> 2075840056:error:02001002:system library:fopen:no such file or
directory:ALP$DKA
sms>
0:[UTILITY.SOURCE.OPENSSL.openssl-1^.0^.0-beta5.crypto.bio]bss_file.c;1:126:fope
sms> n('./demoCA/index.txt-attr','r')
sms> 2075840056:error:2006D080:BIO routines:BIO_new_file:no such
file:ALP$DKA0:[UTILI
sms> TY.SOURCE.OPENSSL.openssl-1^.0^.0-beta5.crypto.bio]bss_file.c;1:129:
sms> 2075840056:error:0E078072:configuration file routines:DEF_LOAD:no such
file:ALP$
sms>
DKA0:[UTILITY.SOURCE.OPENSSL.openssl-1^.0^.0-beta5.crypto.conf]conf_def.c;1:197:
sms> 2075840056:error:0E06D06C:configuration file routines:NCONF_get_string:no
value:
sms>
ALP$DKA0:[UTILITY.SOURCE.OPENSSL.openssl-1^.0^.0-beta5.crypto.conf]conf_lib.c;1:
sms> 334:group=CA_default name=email_in_dn
sms> [...]
sms>
sms>So far, I haven't tried to figure out what this test is trying to do,
sms> so I have no real idea where it's going wrong.
Might be a fault in test/testtsa.com... I'll see if I can find
something there...
Cheers,
Richard
-
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
--
Richard Levitte rich...@levitte.org
http://richard.levitte.org/
"Life is a tremendous celebration - and I'm invited!"
-- from a friend's blog, translated from Swedish
__
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
> Several complaints saying:
> unable to write 'random state'
One cause seems to be this stuff in "tests/CAtsa.cnf":
[...]
# This definition stops the following lines choking if HOME isn't
# defined.
HOME= .
RANDFILE= $ENV::HOME/.rnd
[...]
All the other "tests/*.cnf" files seem to say this (which seems to be
harmless):
RANDFILE = ./.rnd
Apparently (details not verified, but looking plausible, so far, to
me), that "$ENV::HOME" construct gets evaluated (using getenv()) to a
VMS form of the logical name SYS$LOGIN. In my case, that was
"sys$sysroot:[sysmgr]", and the resulting VMS-UNIX mixed-form path,
"sys$sysroot:[sysmgr]/.rnd" causes the I/O failures.
The code in crypto/rand/randfile.c:RAND_file_name() handles the VMS
situation properly (no added "/"), but there's nothing anywhere to cope
with UNIX-like path formation in a ".cnf" file. The "$ENV::" evaluator
could be rigged to handle "HOME" as a special case. Simply substituting
"/sys$login" instead of calling getenv() would probably work, but if
"RANDFILE = ./.rnd" is good enough for all the other tests, then there's
probably no point in adding the code clutter. (Real users on VMS would
be unlikely to use a construct like this, I'd guess.)
That still leaves all this stuff:
[...]
-
Using configuration from [-]CATSA.CNF
Error Loading extension section TSA_CERT
2075840056:error:02001002:system library:fopen:no such file or directory:ALP$DKA
0:[UTILITY.SOURCE.OPENSSL.openssl-1^.0^.0-beta5.crypto.bio]bss_file.c;1:126:fope
n('./demoCA/index.txt-attr','r')
2075840056:error:2006D080:BIO routines:BIO_new_file:no such file:ALP$DKA0:[UTILI
TY.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
[...]
So far, I haven't tried to figure out what this test is trying to do,
so I have no real idea where it's going wrong.
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
In message <1001134848_20205...@antinode.info> on Fri, 22 Jan 2010 22:13:48
-0600 (CST), "Steven M. Schweda" said:
sms> From: Kyle Hamilton
sms>
sms> > Lower-case ssl_* appears to be specifically related to the
sms> > implementation of the secure renegotiation indicator extension. In
sms> > any case, they are internal routines and shouldn't be exported at all,
sms> > I should think, unless other extension parsing/adding code is
sms> > exported.
sms>
sms>That sounds right. Leaving "util/ssleay.num" unchanged seems to be
sms> ok. (I get carried away sometimes.)
sms>
sms>On the test front, there seem to be places where definitions of some
sms> logical names and symbols seem to be assumed, but a clean environment
sms> won't have them. So far, I claim:
sms>
sms> gdiff -u test/tests.com_orig test/tests.com
sms> --- test/tests.com_orig2009-11-13 02:45:52 -0600
sms> +++ test/tests.com 2010-01-22 20:58:35 -0600
sms> @@ -13,6 +13,9 @@
sms> $ exe_dir := sys$disk:[-.'__arch'.exe.apps]
sms> $
sms> $ set default '__here'
sms> +$ sslroot = f$parse( "sys$disk:[-.apps];", , , , "syntax_only") - -
sms> + "].;"+ ".]"
sms> +$ define /translation_attributes = concealed sslroot 'sslroot'
sms> $
sms> $ on control_y then goto exit
sms> $ on error then goto exit
sms> @@ -291,5 +294,6 @@
sms> $
sms> $
sms> $ exit:
sms> +$ deassign sslroot
sms> $ set default '__save_default'
sms> $ exit
sms>
sms>In "test/testenc.com", running openssl fails when
sms> "crypto/bio/bss_file.c" can't find "SSLROOT:[00]openssl.cnf", which,
sms> I claim, is because SSLROOT is undefined.
sms>
sms>
sms> gdiff -u test/testtsa.com_orig test/testtsa.com
sms> --- test/testtsa.com_orig 2006-03-29 22:29:38 -0600
sms> +++ test/testtsa.com 2010-01-22 20:34:46 -0600
sms> @@ -3,7 +3,9 @@
sms> $!
sms> $
sms> $ __arch := VAX
sms> -$ if f$getsyi("cpu") .ge. 128 then __arch := AXP
sms> +$ if f$getsyi("cpu") .ge. 128 then -
sms> + __arch = f$edit( f$getsyi( "ARCH_NAME"), "UPCASE")
sms> +$ if __arch .eqs. "" then __arch := UNK
sms> $ exe_dir := sys$disk:[-.'__arch'.exe.apps]
sms> $
sms> $ openssl := mcr 'f$parse(exe_dir+"openssl.exe")'
sms>
Applied.
sms>Also, is there any reason to use "mcr" here instead of "$"?
I don't remember by now, but generally speaking, I've seen cases where
a command symbol like that gets expanded, such as something like this
(simplified for the same of the example):
$ 'openssl' blah-di-blah
Can't remember the reason behind it, it was probably something on the
complex end of things, but I do tend to use mcr instead of $ in some
cases.
Cheers,
Richard
--
Richard Levitte rich...@levitte.org
http://richard.levitte.org/
"Life is a tremendous celebration - and I'm invited!"
-- from a friend's blog, translated from Swedish
__
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
In message <10012216542748_20205...@antinode.info> on Fri, 22 Jan 2010 16:54:27 -0600 (CST), "Steven M. Schweda" said: sms>I think that some of the tests still have problems, but these changes sms> seem to help with the build: sms> sms> sms> gdiff -u crypto/symhacks.h_orig crypto/symhacks.h sms> --- crypto/symhacks.h_orig 2009-11-12 08:04:26 -0600 sms> +++ crypto/symhacks.h 2010-01-22 16:05:16 -0600 sms> @@ -177,6 +177,15 @@ sms> #undef SSL_COMP_get_compression_methods sms> #define SSL_COMP_get_compression_methods SSL_COMP_get_compress_methods sms> sms> +#undef ssl_add_clienthello_renegotiate_ext sms> +#define ssl_add_clienthello_renegotiate_ext ssl_add_clnthello_reneg_ext sms> +#undef ssl_add_serverhello_renegotiate_ext sms> +#define ssl_add_serverhello_renegotiate_ext ssl_add_srvrhello_reneg_ext sms> +#undef ssl_parse_clienthello_renegotiate_ext sms> +#define ssl_parse_clienthello_renegotiate_ext ssl_parse_clnthello_reneg_ext sms> +#undef ssl_parse_serverhello_renegotiate_ext sms> +#define ssl_parse_serverhello_renegotiate_ext ssl_parse_srvrhello_reneg_ext sms> + sms> /* Hack some long ENGINE names */ sms> #undef ENGINE_get_default_BN_mod_exp_crt sms> #define ENGINE_get_default_BN_mod_exp_crt ENGINE_get_def_BN_mod_exp_crt sms> sms>Spaces or tabs? Seeing no consistency, I chose (copied) spaces. sms> sms> sms> gdiff -u ssl/ssl-lib.com_orig ssl/ssl-lib.com sms> --- ssl/ssl-lib.com_orig 2009-05-15 11:37:06 -0500 sms> +++ ssl/ssl-lib.com2010-01-22 15:58:50 -0600 sms> @@ -180,7 +180,7 @@ sms>"ssl_lib,ssl_err2,ssl_cert,ssl_sess,"+ - sms>"ssl_ciph,ssl_stat,ssl_rsa,"+ - sms>"ssl_asn1,ssl_txt,ssl_algs,"+ - sms> - "bio_ssl,ssl_err,kssl" sms> + "bio_ssl,ssl_err,kssl,t1_reneg" sms> $! sms> $! Tell The User That We Are Compiling The Library. sms> $! Applying right now. sms> gdiff -u util/ssleay.num_orig util/ssleay.num sms> --- util/ssleay.num_orig 2009-07-08 04:13:24 -0500 sms> +++ util/ssleay.num2010-01-22 16:10:26 -0600 sms> @@ -259,3 +259,11 @@ sms> SSL_set_session_ticket_ext_cb 308 EXIST::FUNCTION: sms> SSL_set1_param 309 EXIST::FUNCTION: sms> SSL_CTX_set1_param 310 EXIST::FUNCTION: sms> +ssl_add_clienthello_renegotiate_ext 311 EXIST:!VMS:FUNCTION: sms> +ssl_add_clnthello_reneg_ext 311 EXIST:VMS:FUNCTION: sms> +ssl_add_serverhello_renegotiate_ext 312 EXIST:!VMS:FUNCTION: sms> +ssl_add_srvrhello_reneg_ext 312 EXIST:VMS:FUNCTION: sms> +ssl_parse_clienthello_renegotiate_ext 313 EXIST:!VMS:FUNCTION: sms> +ssl_parse_clnthello_reneg_ext 313 EXIST:VMS:FUNCTION: sms> +ssl_parse_serverhello_renegotiate_ext 314 EXIST:!VMS:FUNCTION: sms> +ssl_parse_srvrhello_reneg_ext 314 EXIST:VMS:FUNCTION: This part is done automatically with "make update", which I will also do. Cheers, Richard -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ "Life is a tremendous celebration - and I'm invited!" -- from a friend's blog, translated from Swedish __ 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
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
Re: OpenSSL 1.0.0 beta5 release v. VMS
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
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
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
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
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
