RE: OpenSSL 1.0.1 released
Hello, Thank you very much for 1.0.1 release. It builds and works perfect on OpenVMS Alpha and IA64 architectures - as long I could test it. Unfortunately, it is still not possible to build on VAX architecture, because the [openssl.org #2653] [BUG] OpenSSL 1.0.1 OpenVMS issues on VAX is sill not solved. Thank you. Regards, Z -Original Message- From: OpenSSL [mailto:open...@master.openssl.org] Sent: den 14 mars 2012 16:09 To: openssl-annou...@master.openssl.org; openssl-...@master.openssl.org; openssl-us...@master.openssl.org Subject: OpenSSL 1.0.1 released -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL version 1.0.1 released === OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.1 of our open source toolkit for SSL/TLS. This new OpenSSL version is a new feature release. For a complete list of changes, please see http://www.openssl.org/source/exp/CHANGES. The most significant changes are: o TLS/DTLS heartbeat support. o SCTP support. o RFC 5705 TLS key material exporter. o RFC 5764 DTLS-SRTP negotiation. o Next Protocol Negotiation. o PSS signatures in certificates, requests and CRLs. o Support for password based recipient info for CMS. o Support TLS v1.2 and TLS v1.1. o Preliminary FIPS capability for unvalidated 2.0 FIPS module. o SRP support. We consider OpenSSL 1.0.1 to be the best version of OpenSSL available and we strongly recommend that users of older versions upgrade as soon as possible. OpenSSL 1.0.1 is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.1.tar.gz Size: 4453920 MD5 checksum: 134f168bc2a8333f19f81d684841710b SHA1 checksum: a6476d33fd38c2e7dfb438d1e3be178cc242c907 The checksums were calculated using the following commands: openssl md5 openssl-1.0.1.tar.gz openssl sha1 openssl-1.0.1.tar.gz Yours, The OpenSSL Project Team. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEVAwUBT2CkBKLSm3vylcdZAQJv6wgAmrvhkXBB0rOI2Yt5YkgShq7BqqogFJk7 TBCHP6gR133L08e+WibwLc3HZS8eU2oAyyOYjBiTjO2Dyg5jkkslku2pyX9R8iZd vb0k/ZTuzmNO/6dDYwejbYdLjrPmTKWrcofa9GooWhiFBOzi3fbY0pAIWjHBoY07 LK8HxVzqQ+v/fg3ingqNpD5qJ6y13i4S8wzMPRL/4ox3evRSsEZ2ZTRqCfxwIbQk hZHfNL2sCZ+i/BoPKYxezhRweftDKQJtAm17femzymbQ0NVZfKi2i4kcd0GXS4Ow eaeMwpXdAGDGcj/HzaqxH1lEkKDQB+H9fo9MT2gqawjntiRt6K/oyQ== =yHMc -END PGP SIGNATURE- __ 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
[openssl.org #2730] [PATCH] solving #2670 BUG
Hello, Please find the included patch that solves [openssl.org #2670] [BUG] OpenSSL 1.0.1 beta 1 released (on VMS FAILED) TITAN2_ZAY $ diff USRDSK:ZAY.WORK.OPENSSL-101-BETA3.CRYPTO.BIOBIO.H;1 USRDSK:ZAY.WORK.OPENSSL-101-BETA3.CRY PTO.BIOBIO.H;4 File USRDSK:ZAY.WORK.OPENSSL-101-BETA3.CRYPTO.BIOBIO.H;1 72 #include stdint.h 73 #endif ** File USRDSK:ZAY.WORK.OPENSSL-101-BETA3.CRYPTO.BIOBIO.H;4 72 # ifndef VMS 73 # include stdint.h 74 # else 75 # include inttypes.h 76 # endif 77 #endif Also, OpenSSL version 1.0.1 Beta 3 is tested and it works very well, except that I have been forced to set #define OPENSSL_NO_SCTP ...because SCTP comes with TCPIP 5.7 ECO 2 and I do not have access to those systems. Regards, Z -Original Message- From: OpenSSL [mailto:open...@master.openssl.org] Sent: den 24 februari 2012 00:27 To: openssl-annou...@master.openssl.org; openssl-...@master.openssl.org; openssl-us...@master.openssl.org Subject: OpenSSL 1.0.1 beta 3 released -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL version 1.0.1 Beta 3 OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ OpenSSL is currently in a release cycle. The third beta is now released. This is expected to be the final beta depending on the number of bugs reported. The beta release is available for download via HTTP and FTP from the following master locations (the various FTP mirrors you can find under http://www.openssl.org/source/mirror.html): o http://www.openssl.org/source/ o ftp://ftp.openssl.org/source/ The file names of the beta are: o openssl-1.0.1-beta3.tar.gz Size: 4451351 MD5 checksum: dc141587e0d374bdb0c7b97f770fff5e SHA1 checksum: 32105cbcc1bc6bc959102b2d70eb16ed1da732ce The checksums were calculated using the following command: openssl md5 openssl-1.0.1-beta3.tar.gz openssl sha1 openssl-1.0.1-beta3.tar.gz Please download and test them as soon as possible. This new OpenSSL version incorporates 55 documented changes and bugfixes to the toolkit (for a complete list see http://www.openssl.org/source/exp/CHANGES). Also check the latest snapshots at ftp://ftp.openssl.org/snapshot/ or CVS (see http://www.openssl.org/source/repos.html) to avoid reporting previously fixed bugs. Since the second beta the following has happened: - Improved TLS v1.2 client authentication interop. - MDC2 signature format compatibility fix. - ABI compatibility fixes. - Other fixes. Reports and patches should be sent to openssl-b...@openssl.org. Discussions around the development of OpenSSL should be sent to openssl-dev@openssl.org. Anything else should go to openssl-us...@openssl.org. The best way, at least on Unix, to create a report is to do the following after configuration: make report That will do a few basic checks of the compiler and bc, then build and run the tests. The result will appear on screen and in the file testlog. Please read the report before sending it to us. There may be problems that we can't solve for you, like missing programs. Yours, The OpenSSL Project Team. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEVAwUBT0bJ2qLSm3vylcdZAQJv1Qf9G5Vf7BgbdhHW+psSd3s6Z8zeijxSkZl1 cue84LkJEDRr7Tkbyk2eGuLR5cNiuH5u9waPlf31zCWsoh2cOl2fMDm+3LTB6Wqk 9zU8gkaarUFZxYxbRJa2VVDTOEzbW/qO/Gabjt/dkh/0xb2iKZvTVGr8G8xK0PVN aYhehHEHl6yxJv2V8uPZgxOC0KIMRXIj3zy/Db/Aeu9FRH1vFCHg4o+HjvaMfXRd Ahhwsh4HLaKQ3GZZKHGBlIzFANd6QJM0Q96tf2rVdINq9CZ3iw7KnbHUXNH26H3P VSfxF0sZcbl2PvQ0EnTKuKLt3QXkea9Ihtf7h7srTP4VikKbkAeh8Q== =27QW -END PGP SIGNATURE- __ 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.org #2730] [PATCH] solving #2670 BUG
Hello, BTW: Isn't SCTP support off by default (at least this is what is intended)? No, it is unfortunately not off by default. ... but applying the following patch OPENSSL_NO_SCTP is easily made default. File DKA400:[ZOLI.OPENSSL-101-BETA3]MAKEVMS.COM;2 506 $ WRITE H_FILE /* STCP support comes with TCPIP 5.7 ECO 2 507 $ WRITE H_FILE * enable on newer systems / 2012-02-24 arpadffy */ 508 $ WRITE H_FILE #define OPENSSL_NO_SCTP 509 $ WRITE H_FILE ** File DKA400:[ZOLI.OPENSSL-101-BETA3]MAKEVMS.COM;1 506 $ WRITE H_FILE Regards, Z From: Michael Tuexen [michael.tue...@lurchi.franken.de] Sent: Friday, February 24, 2012 7:49 PM To: openssl-dev@openssl.org Subject: Re: [openssl.org #2730] [PATCH] solving #2670 BUG On Feb 24, 2012, at 5:47 PM, Arpadffy Zoltan via RT wrote: Hello, Please find the included patch that solves [openssl.org #2670] [BUG] OpenSSL 1.0.1 beta 1 released (on VMS FAILED) TITAN2_ZAY $ diff USRDSK:ZAY.WORK.OPENSSL-101-BETA3.CRYPTO.BIOBIO.H;1 USRDSK:ZAY.WORK.OPENSSL-101-BETA3.CRY PTO.BIOBIO.H;4 File USRDSK:ZAY.WORK.OPENSSL-101-BETA3.CRYPTO.BIOBIO.H;1 72 #include stdint.h 73 #endif ** File USRDSK:ZAY.WORK.OPENSSL-101-BETA3.CRYPTO.BIOBIO.H;4 72 # ifndef VMS 73 # include stdint.h 74 # else 75 # include inttypes.h 76 # endif 77 #endif Also, OpenSSL version 1.0.1 Beta 3 is tested and it works very well, except that I have been forced to set #define OPENSSL_NO_SCTP BTW: Isn't SCTP support off by default (at least this is what is intended)? Best regards Michael ...because SCTP comes with TCPIP 5.7 ECO 2 and I do not have access to those systems. Regards, Z -Original Message- From: OpenSSL [mailto:open...@master.openssl.org] Sent: den 24 februari 2012 00:27 To: openssl-annou...@master.openssl.org; openssl-...@master.openssl.org; openssl-us...@master.openssl.org Subject: OpenSSL 1.0.1 beta 3 released -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL version 1.0.1 Beta 3 OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ OpenSSL is currently in a release cycle. The third beta is now released. This is expected to be the final beta depending on the number of bugs reported. The beta release is available for download via HTTP and FTP from the following master locations (the various FTP mirrors you can find under http://www.openssl.org/source/mirror.html): o http://www.openssl.org/source/ o ftp://ftp.openssl.org/source/ The file names of the beta are: o openssl-1.0.1-beta3.tar.gz Size: 4451351 MD5 checksum: dc141587e0d374bdb0c7b97f770fff5e SHA1 checksum: 32105cbcc1bc6bc959102b2d70eb16ed1da732ce The checksums were calculated using the following command: openssl md5 openssl-1.0.1-beta3.tar.gz openssl sha1 openssl-1.0.1-beta3.tar.gz Please download and test them as soon as possible. This new OpenSSL version incorporates 55 documented changes and bugfixes to the toolkit (for a complete list see http://www.openssl.org/source/exp/CHANGES). Also check the latest snapshots at ftp://ftp.openssl.org/snapshot/ or CVS (see http://www.openssl.org/source/repos.html) to avoid reporting previously fixed bugs. Since the second beta the following has happened: - Improved TLS v1.2 client authentication interop. - MDC2 signature format compatibility fix. - ABI compatibility fixes. - Other fixes. Reports and patches should be sent to openssl-b...@openssl.org. Discussions around the development of OpenSSL should be sent to openssl-dev@openssl.org. Anything else should go to openssl-us...@openssl.org. The best way, at least on Unix, to create a report is to do the following after configuration: make report That will do a few basic checks of the compiler and bc, then build and run the tests. The result will appear on screen and in the file testlog. Please read the report before sending it to us. There may be problems that we can't solve for you, like missing programs. Yours, The OpenSSL Project Team. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEVAwUBT0bJ2qLSm3vylcdZAQJv1Qf9G5Vf7BgbdhHW+psSd3s6Z8zeijxSkZl1 cue84LkJEDRr7Tkbyk2eGuLR5cNiuH5u9waPlf31zCWsoh2cOl2fMDm+3LTB6Wqk 9zU8gkaarUFZxYxbRJa2VVDTOEzbW/qO/Gabjt/dkh/0xb2iKZvTVGr8G8xK0PVN aYhehHEHl6yxJv2V8uPZgxOC0KIMRXIj3zy/Db/Aeu9FRH1vFCHg4o+HjvaMfXRd Ahhwsh4HLaKQ3GZZKHGBlIzFANd6QJM0Q96tf2rVdINq9CZ3iw7KnbHUXNH26H3P VSfxF0sZcbl2PvQ0EnTKuKLt3QXkea9Ihtf7h7srTP4VikKbkAeh8Q== =27QW -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager
[openssl.org #2670] [BUG] OpenSSL 1.0.1 beta 1 released (on VMS FAILED)
Hello, I have tested the OpenSSL 1.0.1 beta 1 release on OpenVMS Alpha and IA64 and the build fails with the following error: Compiling The mem_dbg.c File. (LIBRARY,LIB) #include stdint.h .^ %CC-F-NOINCLFILEF, Cannot find file stdint.h specified in #include directive. at line number 72 in file USRDSK:[ZAY.WORK.OPENSSL-101-BETA1.INCLUDE.OPENSSL]BIO.H;1 Compiling The cversion.c File. (LIBRARY,LIB) #include stdint.h .^ %CC-F-NOINCLFILEF, Cannot find file stdint.h specified in #include directive. at line number 72 in file USRDSK:[ZAY.WORK.OPENSSL-101-BETA1.INCLUDE.OPENSSL]BIO.H;1 Compiling The ex_data.c File. (LIBRARY,LIB) ... hundreds of times. The problem is that VMS does not have stdint.h at all. Please read more about in http://h71000.www7.hp.com/portability/portingguidelines.html For example: - 4.1.1. int64_t and uint64_t In UNIX or Linux, int64_t and uint64_t data types are defined in the stdint.h, sys.h or types.h header files. However, in OpenVMS, these data types are defined in the inttypes.h header file. Hence, the header file inttypes.h must be included when porting to OpenVMS systems. -- ... also I have noticed that the [openssl.org #2652] [PATCH] OpenSSL 1.0.1 OpenVMS issues is not included - and the build will fail for that reason as well... as well as the [openssl.org #2653] [BUG] OpenSSL 1.0.1 OpenVMS issues on VAX is not addressed at all. Seems, it has arrived the time for Richard to start the merging work. Thank you. Regards, Z -Original Message- From: OpenSSL [mailto:open...@master.openssl.org] Sent: den 3 januari 2012 15:18 To: openssl-annou...@master.openssl.org; openssl-...@master.openssl.org; openssl-us...@master.openssl.org Subject: OpenSSL 1.0.1 beta 1 released -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL version 1.0.1 Beta 1 OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ OpenSSL is currently in a release cycle. The first beta is now released. The beta release is available for download via HTTP and FTP from the following master locations (the various FTP mirrors you can find under http://www.openssl.org/source/mirror.html): o http://www.openssl.org/source/ o ftp://ftp.openssl.org/source/ The file names of the beta are: o openssl-1.0.1-beta1.tar.gz Size: 4445727 MD5 checksum: 2501e8caf6724c5ad747ac0d6df00c3d SHA1 checksum: a97fd63356a787e9ddc9f157ce4b964459a41f40 The checksums were calculated using the following command: openssl md5 openssl-1.0.1-beta1.tar.gz openssl sha1 openssl-1.0.1-beta1.tar.gz Please download and test them as soon as possible. This new OpenSSL version incorporates 52 documented changes and bugfixes to the toolkit (for a complete list see http://www.openssl.org/source/exp/CHANGES). Also check the latest snapshots at ftp://ftp.openssl.org/snapshot/ or CVS (see http://www.openssl.org/source/repos.html) to avoid reporting previously fixed bugs. Reports and patches should be sent to openssl-b...@openssl.org. Discussions around the development of OpenSSL should be sent to openssl-dev@openssl.org. Anything else should go to openssl-us...@openssl.org. The best way, at least on Unix, to create a report is to do the following after configuration: make report That will do a few basic checks of the compiler and bc, then build and run the tests. The result will appear on screen and in the file testlog. Please read the report before sending it to us. There may be problems that we can't solve for you, like missing programs. Yours, The OpenSSL Project Team... Mark J. Cox Ben Laurie Andy Polyakov Ralf S. Engelschall Richard Levitte Geoff Thorpe Dr. Stephen Henson Bodo Möller Ulf Möller Lutz JänickeNils Larsch -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEVAwUBTwMMMKLSm3vylcdZAQIx4Qf8DULWe5abAiYw1s7Eu1bcC84ffEbtxvo7 qdnz1PWs2RXYFl47jH+B8BA45cJp4WylDhk3KLgkOpEKJk0xHkmPc0Al3vCzRcFg +XzSyQ6lrUrw3b8s3hL8wA91brRF7LLrnmv/0KArh7Mmh5GilSwSHlrLCC/NL9vG 0rEmURWAMTfDpcRd3wlC7Jh3Uev5N9pjFMWorZcIlX/rCBy9xwTnulO6MmU9Vr03 2WHu5ZEeqdoFraryCGRFBMhb0IV7BKus5X/wTQl1amA3cTL8tUV6yCyg5FwCdL/e GHKa/KA9He3/M6Ab4RjBlE6Hduy2ui1rR6f9g5+ZSWhsP8aXqxCmPg== =tftU -END PGP SIGNATURE- __ 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
[BUG] OpenSSL 1.0.1 beta 1 released (on VMS FAILED)
Hello, I have tested the OpenSSL 1.0.1 beta 1 release on OpenVMS Alpha and IA64 and the build fails with the following error: Compiling The mem_dbg.c File. (LIBRARY,LIB) #include stdint.h .^ %CC-F-NOINCLFILEF, Cannot find file stdint.h specified in #include directive. at line number 72 in file USRDSK:[ZAY.WORK.OPENSSL-101-BETA1.INCLUDE.OPENSSL]BIO.H;1 Compiling The cversion.c File. (LIBRARY,LIB) #include stdint.h .^ %CC-F-NOINCLFILEF, Cannot find file stdint.h specified in #include directive. at line number 72 in file USRDSK:[ZAY.WORK.OPENSSL-101-BETA1.INCLUDE.OPENSSL]BIO.H;1 Compiling The ex_data.c File. (LIBRARY,LIB) ... hundreds of times. The problem is that VMS does not have stdint.h at all. Please read more about in http://h71000.www7.hp.com/portability/portingguidelines.html For example: - 4.1.1. int64_t and uint64_t In UNIX or Linux, int64_t and uint64_t data types are defined in the stdint.h, sys.h or types.h header files. However, in OpenVMS, these data types are defined in the inttypes.h header file. Hence, the header file inttypes.h must be included when porting to OpenVMS systems. -- ... also I have noticed that the [openssl.org #2652] [PATCH] OpenSSL 1.0.1 OpenVMS issues is not included - and the build will fail for that reason as well... as well as the [openssl.org #2653] [BUG] OpenSSL 1.0.1 OpenVMS issues on VAX is not addressed at all. Seems, it has arrived the time for Richard to start the merging work. Thank you. Regards, Z -Original Message- From: OpenSSL [mailto:open...@master.openssl.org] Sent: den 3 januari 2012 15:18 To: openssl-annou...@master.openssl.org; openssl-...@master.openssl.org; openssl-us...@master.openssl.org Subject: OpenSSL 1.0.1 beta 1 released -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL version 1.0.1 Beta 1 OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ OpenSSL is currently in a release cycle. The first beta is now released. The beta release is available for download via HTTP and FTP from the following master locations (the various FTP mirrors you can find under http://www.openssl.org/source/mirror.html): o http://www.openssl.org/source/ o ftp://ftp.openssl.org/source/ The file names of the beta are: o openssl-1.0.1-beta1.tar.gz Size: 4445727 MD5 checksum: 2501e8caf6724c5ad747ac0d6df00c3d SHA1 checksum: a97fd63356a787e9ddc9f157ce4b964459a41f40 The checksums were calculated using the following command: openssl md5 openssl-1.0.1-beta1.tar.gz openssl sha1 openssl-1.0.1-beta1.tar.gz Please download and test them as soon as possible. This new OpenSSL version incorporates 52 documented changes and bugfixes to the toolkit (for a complete list see http://www.openssl.org/source/exp/CHANGES). Also check the latest snapshots at ftp://ftp.openssl.org/snapshot/ or CVS (see http://www.openssl.org/source/repos.html) to avoid reporting previously fixed bugs. Reports and patches should be sent to openssl-b...@openssl.org. Discussions around the development of OpenSSL should be sent to openssl-dev@openssl.org. Anything else should go to openssl-us...@openssl.org. The best way, at least on Unix, to create a report is to do the following after configuration: make report That will do a few basic checks of the compiler and bc, then build and run the tests. The result will appear on screen and in the file testlog. Please read the report before sending it to us. There may be problems that we can't solve for you, like missing programs. Yours, The OpenSSL Project Team... Mark J. Cox Ben Laurie Andy Polyakov Ralf S. Engelschall Richard Levitte Geoff Thorpe Dr. Stephen Henson Bodo Möller Ulf Möller Lutz JänickeNils Larsch -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEVAwUBTwMMMKLSm3vylcdZAQIx4Qf8DULWe5abAiYw1s7Eu1bcC84ffEbtxvo7 qdnz1PWs2RXYFl47jH+B8BA45cJp4WylDhk3KLgkOpEKJk0xHkmPc0Al3vCzRcFg +XzSyQ6lrUrw3b8s3hL8wA91brRF7LLrnmv/0KArh7Mmh5GilSwSHlrLCC/NL9vG 0rEmURWAMTfDpcRd3wlC7Jh3Uev5N9pjFMWorZcIlX/rCBy9xwTnulO6MmU9Vr03 2WHu5ZEeqdoFraryCGRFBMhb0IV7BKus5X/wTQl1amA3cTL8tUV6yCyg5FwCdL/e GHKa/KA9He3/M6Ab4RjBlE6Hduy2ui1rR6f9g5+ZSWhsP8aXqxCmPg== =tftU -END PGP SIGNATURE- __ 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
[openssl.org #2652] [PATCH] OpenSSL 1.0.1 OpenVMS issues
Hello, I have tested OPENSSL-1.0.1-STABLE-SNAP-20111209 on AXP and IA64 with 32 and 64 bist pointer size and found few OpenVMS related problems. The following patches are needed in order to get clean compile and successful build. 1. missing srtp.h header file TITAN2_ZAY $ diff MAKEVMS.COM;1 MAKEVMS.COM;4 File USRDSK:ZAY.WORK.OPENSSL-101-STABLE-SNAP-20111209MAKEVMS.COM;1 787 $ EXHEADER := ssl.h, ssl2.h, ssl3.h, ssl23.h, tls1.h, dtls1.h, kssl.h 788 $ copy sys$disk:[.ssl]'exheader' sys$disk:[.include.openssl] ** File USRDSK:ZAY.WORK.OPENSSL-101-STABLE-SNAP-20111209MAKEVMS.COM;4 787 $ EXHEADER := ssl.h, ssl2.h, ssl3.h, ssl23.h, tls1.h, dtls1.h, kssl.h, srtp.h 788 $ copy sys$disk:[.ssl]'exheader' sys$disk:[.include.openssl] Number of difference sections found: 1 Number of difference records found: 1 2. solv problems with %CC-W-LONGEXTERN, The external identifier name exceeds 31 characters TITAN2_ZAY $ diff .CRYPTOSYMHACKS.H;1 .CRYPTOSYMHACKS.H;3 File USRDSK:ZAY.WORK.OPENSSL-101-STABLE-SNAP-20111209.CRYPTOSYMHACKS.H;1 198 ** File USRDSK:ZAY.WORK.OPENSSL-101-STABLE-SNAP-20111209.CRYPTOSYMHACKS.H;3 198 #undef ssl_add_clienthello_use_srtp_ext 199 #define ssl_add_clienthello_use_srtp_ext ssl_add_clihello_use_srtp_ext 200 #undef ssl_add_serverhello_use_srtp_ext 201 #define ssl_add_serverhello_use_srtp_ext ssl_add_serhello_use_srtp_ext 202 #undef ssl_parse_clienthello_use_srtp_ext 203 #define ssl_parse_clienthello_use_srtp_ext ssl_parse_clihello_use_srtp_ext 204 #undef ssl_parse_serverhello_use_srtp_ext 205 #define ssl_parse_serverhello_use_srtp_ext ssl_parse_serhello_use_srtp_ext 206 #undef SSL_CTX_set_next_protos_advertised_cb 207 #define SSL_CTX_set_next_protos_advertised_cb SSL_CTX_set_next_protos_adv_cb 208 #undef SSL_CTX_set_next_proto_select_cb 209 #define SSL_CTX_set_next_proto_select_cb SSL_CTX_set_next_proto_sel_cb 210 Number of difference sections found: 1 Number of difference records found: 12 TITAN2_ZAY $ diff .utilssleay.num.1 .utilssleay.num.3 File USRDSK:ZAY.WORK.OPENSSL-101-STABLE-SNAP-20111209.UTILSSLEAY.NUM;1 ** File USRDSK:ZAY.WORK.OPENSSL-101-STABLE-SNAP-20111209.UTILSSLEAY.NUM;3 320 ssl_add_clihello_use_srtp_ext 362 EXIST:VMS:FUNCTION 321 ssl_add_serhello_use_srtp_ext 363 EXIST:VMS:FUNCTION 322 ssl_parse_clihello_use_srtp_ext 364 EXIST:VMS:FUNCTION 323 ssl_parse_serhello_use_srtp_ext 365 EXIST:VMS:FUNCTION 324 SSL_CTX_set_next_protos_adv_cb 366 EXIST:VMS:FUNCTION 325 SSL_CTX_set_next_proto_sel_cb 367 EXIST:VMS:FUNCTION Number of difference sections found: 1 Number of difference records found: 6 3. add missing source file d1_srtp.c TITAN2_ZAY $ diff .sslssl-lib.com File USRDSK:ZAY.WORK.OPENSSL-101-STABLE-SNAP-20111209.SSLSSL-LIB.COM;2 221 d1_both,d1_enc,d1_srtp,+ - 222 ssl_lib,ssl_err2,ssl_cert,ssl_sess,+ - ** File USRDSK:ZAY.WORK.OPENSSL-101-STABLE-SNAP-20111209.SSLSSL-LIB.COM;1 221 d1_both,d1_enc,+ - 222 ssl_lib,ssl_err2,ssl_cert,ssl_sess,+ - Number of difference sections found: 1 Number of difference records found: 1 I am currently testing on VAX and there may come some VAX specific changes as well - but it will take some time, as the VAX hardware is much slower then IA64 and AXP. Thank you. Regards, Z -Original Message- From: Dr. Stephen Henson [mailto:st...@openssl.org] Sent: den 9 december 2011 00:36 To: OpenSSL Announce ML; OpenSSL Developer ML; OpenSSL User Support ML Subject: Release of OpenSSL 1.0.1 approaching... OpenSSL 1.0.1 is expected to be released in the next few weeks. There have been many changes since OpenSSL 1.0.0 including: o PSS signatures in certificates, requests and CRLs. o Support for password based recipient info for CMS. o Support TLS v1.2 and TLS v1.1. o Preliminary FIPS capability for unvalidated 2.0 FIPS module. o SRP support. Users are encouraged to test recent snapshots of OpenSSL 1.0.1 and report any problems via the request tracker (r...@openssl.org). The actual 1.0.1 release date will depend on the number and severity of issues uncovered. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org
[openssl.org #2653] [BUG] OpenSSL 1.0.1 OpenVMS issues on VAX
Hello, In my earlier mail I have sent a patch that is needed for OpenVMS AXP and IA64. Here is a list of issues on OpenVMS VAX 1. %CC-E-NOLONGLONG, In this declaration, 64-bit integral types are not supported issue cbc128.c typedef long long i64; ^ %CC-E-NOLONGLONG, In this declaration, 64-bit integral types are not supported on this platform. At line number 20 in DKA400:[ZOLI.OPENSSL-101-STABLE-SNAP-20111209.CRYPTO.MODES]MODES_LCL.H;1. typedef unsigned long long u64; ^ %CC-E-NOLONGLONG, In this declaration, 64-bit integral types are not supported on this platform. At line number 21 in DKA400:[ZOLI.OPENSSL-101-STABLE-SNAP-20111209.CRYPTO.MODES]MODES_LCL.H;1. } %VCG-I-NOBJECT, No object file produced. At line number 202 in DKA400:[ZOLI.OPENSSL-101-STABLE-SNAP-20111209.CRYPTO.MODES]CBC128.C;1. %VCG-I-SUMMARY, Completed with 2 error(s), 0 warning(s), and 1 informational messages. At line number 202 in DKA400:[ZOLI.OPENSSL-101-STABLE-SNAP-20111209.CRYPTO.MODES]CBC128.C;1. This is a general problem and there are many files like: MODES_LCL.H, BN_NIST.C 2. %CC-W-LONGEXTERN, The external identifier name exceeds 31 characters; truncated issue in EC_LCL.H This is en easy to fix issue - I just wonder why it does not come with IA64 or AXP build ec_lib.c int ec_GFp_nistp224_point_get_affine_coordinates(const EC_GROUP *group, const EC_POINT *point, BIGNUM *x, BIGNUM *y, BN_CTX *ctx ); ^ %CC-W-LONGEXTERN, The external identifier name exceeds 31 characters; truncated to EC_GFP_NISTP224_POINT_GET_AFFIN. At line number 411 in DKA400:[ZOLI.OPENSSL-101-STABLE-SNAP-20111209.CRYPTO.EC]EC_LCL.H;1. int ec_GFp_nistp224_have_precompute_mult(const EC_GROUP *group); ^ %CC-W-LONGEXTERN, The external identifier name exceeds 31 characters; truncated to EC_GFP_NISTP224_HAVE_PRECOMPUTE. At line number 415 in DKA400:[ZOLI.OPENSSL-101-STABLE-SNAP-20111209.CRYPTO.EC]EC_LCL.H;1. int ec_GFp_nistp256_point_get_affine_coordinates(const EC_GROUP *group, const EC_POINT *point, BIGNUM *x, BIGNUM *y, BN_CTX *ctx ); ^ %CC-W-LONGEXTERN, The external identifier name exceeds 31 characters; truncated to EC_GFP_NISTP256_POINT_GET_AFFIN. At line number 420 in DKA400:[ZOLI.OPENSSL-101-STABLE-SNAP-20111209.CRYPTO.EC]EC_LCL.H;1. I think that by solving these issues even on VAX would build correctly. Thank you. Regards, Z Hello, In my earlier mail I have sent a patch that is needed for OpenVMS AXP and IA64. Here is a list of issues on OpenVMS VAX 1. %CC-E-NOLONGLONG, In this declaration, 64-bit integral types are not supported issue cbc128.c typedef long long i64; ^ %CC-E-NOLONGLONG, In this declaration, 64-bit integral types are not supported on this platform. At line number 20 in DKA400:[ZOLI.OPENSSL-101-STABLE-SNAP-20111209.CRYPTO.MODES]MODES_LCL.H;1. typedef unsigned long long u64; ^ %CC-E-NOLONGLONG, In this declaration, 64-bit integral types are not supported on this platform. At line number 21 in DKA400:[ZOLI.OPENSSL-101-STABLE-SNAP-20111209.CRYPTO.MODES]MODES_LCL.H;1. } %VCG-I-NOBJECT, No object file produced. At line number 202 in DKA400:[ZOLI.OPENSSL-101-STABLE-SNAP-20111209.CRYPTO.MODES]CBC128.C;1. %VCG-I-SUMMARY, Completed with 2 error(s), 0 warning(s), and 1 informational messages. At line number 202 in DKA400:[ZOLI.OPENSSL-101-STABLE-SNAP-20111209.CRYPTO.MODES]CBC128.C;1. This is a general problem and there are many files like: MODES_LCL.H, BN_NIST.C 2. %CC-W-LONGEXTERN, The external identifier name exceeds 31 characters; truncated issue in EC_LCL.H This is en easy to fix issue I just wonder why it does not come with IA64 or AXP build ec_lib.c int ec_GFp_nistp224_point_get_affine_coordinates(const EC_GROUP *group, const EC_POINT *point, BIGNUM *x, BIGNUM *y, BN_CTX *ctx ); ^ %CC-W-LONGEXTERN, The external identifier name exceeds 31 characters; truncated to EC_GFP_NISTP224_POINT_GET_AFFIN. At line number 411 in DKA400:[ZOLI.OPENSSL-101-STABLE-SNAP-20111209.CRYPTO.EC]EC_LCL.H;1. int ec_GFp_nistp224_have_precompute_mult(const EC_GROUP *group); ^ %CC-W-LONGEXTERN, The external identifier name exceeds 31 characters; truncated to EC_GFP_NISTP224_HAVE_PRECOMPUTE. At line number 415 in DKA400:[ZOLI.OPENSSL-101-STABLE-SNAP-20111209.CRYPTO.EC]EC_LCL.H;1. int ec_GFp_nistp256_point_get_affine_coordinates(const EC_GROUP *group, const EC_POINT *point, BIGNUM *x, BIGNUM *y, BN_CTX *ctx ); ^ %CC-W-LONGEXTERN, The external identifier name exceeds 31 characters; truncated to EC_GFP_NISTP256_POINT_GET_AFFIN. At line number 420 in DKA400:[ZOLI.OPENSSL-101-STABLE-SNAP-20111209.CRYPTO.EC]EC_LCL.H;1. I think that by solving these issues even on
[openssl.org #2593] [PATCH] 1.0.1-STABLE build fails on VMS
Hello, I have tested both the new 1.0.0e and the recent snapshot OPENSSL-1.0.1-STABLE-SNAP-20110907 on Alpha, IA64 platforms with both 32 and 64 bit pointer size and on a VAX. The release builds perfect. All test pass. The 1.0.1-stable snapshot needed those patches below to build, but after that everything works perfect. Obviously, the VMS make files have been forgotten and have not been updated as the development evolved. TOR_ZAY $ mc DSA102:[GNU.BIN]gdiff -p MAKEVMS.COM;1 MAKEVMS.COM;4 *** makevms.com;1 Fri Mar 25 18:00:20 2011 --- makevms.com;4 Thu Sep 8 12:21:33 2011 *** $ CONFIG_LOGICALS := AES,- *** 256,261 --- 256,262 CAMELLIA,- CAST,- CMS,- + CMAC,- COMP,- DEPRECATED,- DES,- *** $ SDIRS := , - *** 705,711 BUFFER, BIO, STACK, LHASH, RAND, ERR, - EVP, ASN1, PEM, X509, X509V3, CONF, TXT_DB, PKCS7, PKCS12, - COMP, OCSP, UI, KRB5, - !CMS, PQUEUE, TS, JPAKE, SRP, STORE $! $ EXHEADER_ := crypto.h, opensslv.h, ebcdic.h, symhacks.h, ossl_typ.h $ EXHEADER_'ARCHD' := opensslconf.h --- 706,712 BUFFER, BIO, STACK, LHASH, RAND, ERR, - EVP, ASN1, PEM, X509, X509V3, CONF, TXT_DB, PKCS7, PKCS12, - COMP, OCSP, UI, KRB5, - !CMS, CMAC, PQUEUE, TS, JPAKE, SRP, STORE $! $ EXHEADER_ := crypto.h, opensslv.h, ebcdic.h, symhacks.h, ossl_typ.h $ EXHEADER_'ARCHD' := opensslconf.h *** $ EXHEADER_OCSP := ocsp.h *** 758,763 --- 759,765 $ EXHEADER_UI := ui.h, ui_compat.h $ EXHEADER_KRB5 := krb5_asn.h $ EXHEADER_CMS := cms.h + $ EXHEADER_CMAC := cmac.h $ EXHEADER_PQUEUE := pqueue.h $ EXHEADER_TS := ts.h $ EXHEADER_JPAKE := jpake.h TOR_ZAY $ mc DSA102:[GNU.BIN]gdiff -p CRYPTO-LIB.COM;1 CRYPTO-LIB.COM;24 *** crypto-lib.com;1Thu Sep 8 16:30:27 2011 --- crypto-lib.com;24 Thu Sep 8 12:46:48 2011 *** $ ENCRYPT_TYPES = Basic,+ - *** 117,123 BUFFER,BIO,STACK,LHASH,RAND,ERR,+ - EVP,EVP_2,EVP_3,ASN1,ASN1_2,PEM,X509,X509V3,+ - CONF,TXT_DB,PKCS7,PKCS12,COMP,OCSP,UI,KRB5,+ - ! CMS,PQUEUE,TS,JPAKE,SRP,STORE $! $! Check To Make Sure We Have Valid Command Line Parameters. $! --- 117,123 BUFFER,BIO,STACK,LHASH,RAND,ERR,+ - EVP,EVP_2,EVP_3,ASN1,ASN1_2,PEM,X509,X509V3,+ - CONF,TXT_DB,PKCS7,PKCS12,COMP,OCSP,UI,KRB5,+ - ! CMS,CMAC,PQUEUE,TS,JPAKE,SRP,STORE $! $! Check To Make Sure We Have Valid Command Line Parameters. $! *** $! *** 207,213 $ APPS_DES = DES/DES,CBC3_ENC $ APPS_PKCS7 = ENC/ENC;DEC/DEC;SIGN/SIGN;VERIFY/VERIFY,EXAMPLE $ ! $ LIB_ = cryptlib,mem,mem_clr,mem_dbg,cversion,ex_data,cpt_err,ebcdic,uid,o_time,o_str,o_dir $ LIB_MD2 = md2_dgst,md2_one $ LIB_MD4 = md4_dgst,md4_one $ LIB_MD5 = md5_dgst,md5_one --- 207,213 $ APPS_DES = DES/DES,CBC3_ENC $ APPS_PKCS7 = ENC/ENC;DEC/DEC;SIGN/SIGN;VERIFY/VERIFY,EXAMPLE $ ! $ LIB_ = cryptlib,mem,mem_clr,mem_dbg,cversion,ex_data,cpt_err,ebcdic,uid,o_time,o_str,o_dir,o_init $ LIB_MD2 = md2_dgst,md2_one $ LIB_MD4 = md4_dgst,md4_one $ LIB_MD5 = md5_dgst,md5_one *** $ LIB_DES = set_key,ecb_enc,cbc_enc,+ *** 224,238 fcrypt,xcbc_enc,rpc_enc,cbc_cksm,+ - ede_cbcm_enc,des_old,des_old2,read2pwd $ LIB_RC2 = rc2_ecb,rc2_skey,rc2_cbc,rc2cfb64,rc2ofb64 ! $ LIB_RC4 = rc4_skey,rc4_enc $ LIB_RC5 = rc5_skey,rc5_ecb,rc5_enc,rc5cfb64,rc5ofb64 $ LIB_IDEA = i_cbc,i_cfb64,i_ofb64,i_ecb,i_skey $ LIB_BF = bf_skey,bf_ecb,bf_enc,bf_cfb64,bf_ofb64 $ LIB_CAST = c_skey,c_ecb,c_enc,c_cfb64,c_ofb64 $ LIB_CAMELLIA = camellia,cmll_misc,cmll_ecb,cmll_cbc,cmll_ofb,+ - ! cmll_cfb,cmll_ctr $ LIB_SEED = seed,seed_ecb,seed_cbc,seed_cfb,seed_ofb ! $ LIB_MODES = cbc128,ctr128,cts128,cfb128,ofb128 $ LIB_BN_ASM = [.asm]vms.mar,vms-helper $ IF F$TRNLNM(OPENSSL_NO_ASM) .OR. ARCH .NES. VAX THEN - LIB_BN_ASM = bn_asm --- 224,238 fcrypt,xcbc_enc,rpc_enc,cbc_cksm,+ - ede_cbcm_enc,des_old,des_old2,read2pwd $ LIB_RC2 = rc2_ecb,rc2_skey,rc2_cbc,rc2cfb64,rc2ofb64 ! $ LIB_RC4 = rc4_skey,rc4_enc,rc4_utl $ LIB_RC5 = rc5_skey,rc5_ecb,rc5_enc,rc5cfb64,rc5ofb64 $ LIB_IDEA = i_cbc,i_cfb64,i_ofb64,i_ecb,i_skey $ LIB_BF = bf_skey,bf_ecb,bf_enc,bf_cfb64,bf_ofb64 $ LIB_CAST = c_skey,c_ecb,c_enc,c_cfb64,c_ofb64 $ LIB_CAMELLIA = camellia,cmll_misc,cmll_ecb,cmll_cbc,cmll_ofb,+ - ! cmll_cfb,cmll_ctr,cmll_utl $ LIB_SEED = seed,seed_ecb,seed_cbc,seed_cfb,seed_ofb ! $ LIB_MODES = cbc128,ctr128,cts128,cfb128,ofb128,ccm128,gcm128,xts128 $ LIB_BN_ASM = [.asm]vms.mar,vms-helper $ IF F$TRNLNM(OPENSSL_NO_ASM) .OR. ARCH .NES. VAX THEN - LIB_BN_ASM = bn_asm *** $ LIB_BN = bn_add,bn_div,bn_exp,bn_lib, *** 241,249
RE: [openssl.org #2593] [PATCH] 1.0.1-STABLE build fails on VMS
-101-STABLE-SNAP-20110 907.CRYPTO.SRP]SRP_LIB.C;1. %VCG-I-SUMMARY, Completed with 14 error(s), 0 warning(s), and 1 informational messages. At line number 357 in DKA400:[ZOLI.OPENSSL-101-STABLE-SNAP-20110 907.CRYPTO.SRP]SRP_LIB.C;1. Regards, Z -Original Message- From: Arpadffy Zoltan via RT [mailto:r...@openssl.org] Sent: den 9 september 2011 09:12 Cc: openssl-dev@openssl.org Subject: [openssl.org #2593] [PATCH] 1.0.1-STABLE build fails on VMS Hello, I have tested both the new 1.0.0e and the recent snapshot OPENSSL-1.0.1-STABLE-SNAP-20110907 on Alpha, IA64 platforms with both 32 and 64 bit pointer size and on a VAX. The release builds perfect. All test pass. The 1.0.1-stable snapshot needed those patches below to build, but after that everything works perfect. Obviously, the VMS make files have been forgotten and have not been updated as the development evolved. TOR_ZAY $ mc DSA102:[GNU.BIN]gdiff -p MAKEVMS.COM;1 MAKEVMS.COM;4 *** makevms.com;1 Fri Mar 25 18:00:20 2011 --- makevms.com;4 Thu Sep 8 12:21:33 2011 *** $ CONFIG_LOGICALS := AES,- *** 256,261 --- 256,262 CAMELLIA,- CAST,- CMS,- + CMAC,- COMP,- DEPRECATED,- DES,- *** $ SDIRS := , - *** 705,711 BUFFER, BIO, STACK, LHASH, RAND, ERR, - EVP, ASN1, PEM, X509, X509V3, CONF, TXT_DB, PKCS7, PKCS12, - COMP, OCSP, UI, KRB5, - !CMS, PQUEUE, TS, JPAKE, SRP, STORE $! $ EXHEADER_ := crypto.h, opensslv.h, ebcdic.h, symhacks.h, ossl_typ.h $ EXHEADER_'ARCHD' := opensslconf.h --- 706,712 BUFFER, BIO, STACK, LHASH, RAND, ERR, - EVP, ASN1, PEM, X509, X509V3, CONF, TXT_DB, PKCS7, PKCS12, - COMP, OCSP, UI, KRB5, - !CMS, CMAC, PQUEUE, TS, JPAKE, SRP, STORE $! $ EXHEADER_ := crypto.h, opensslv.h, ebcdic.h, symhacks.h, ossl_typ.h $ EXHEADER_'ARCHD' := opensslconf.h *** $ EXHEADER_OCSP := ocsp.h *** 758,763 --- 759,765 $ EXHEADER_UI := ui.h, ui_compat.h $ EXHEADER_KRB5 := krb5_asn.h $ EXHEADER_CMS := cms.h + $ EXHEADER_CMAC := cmac.h $ EXHEADER_PQUEUE := pqueue.h $ EXHEADER_TS := ts.h $ EXHEADER_JPAKE := jpake.h TOR_ZAY $ mc DSA102:[GNU.BIN]gdiff -p CRYPTO-LIB.COM;1 CRYPTO-LIB.COM;24 *** crypto-lib.com;1Thu Sep 8 16:30:27 2011 --- crypto-lib.com;24 Thu Sep 8 12:46:48 2011 *** $ ENCRYPT_TYPES = Basic,+ - *** 117,123 BUFFER,BIO,STACK,LHASH,RAND,ERR,+ - EVP,EVP_2,EVP_3,ASN1,ASN1_2,PEM,X509,X509V3,+ - CONF,TXT_DB,PKCS7,PKCS12,COMP,OCSP,UI,KRB5,+ - ! CMS,PQUEUE,TS,JPAKE,SRP,STORE $! $! Check To Make Sure We Have Valid Command Line Parameters. $! --- 117,123 BUFFER,BIO,STACK,LHASH,RAND,ERR,+ - EVP,EVP_2,EVP_3,ASN1,ASN1_2,PEM,X509,X509V3,+ - CONF,TXT_DB,PKCS7,PKCS12,COMP,OCSP,UI,KRB5,+ - ! CMS,CMAC,PQUEUE,TS,JPAKE,SRP,STORE $! $! Check To Make Sure We Have Valid Command Line Parameters. $! *** $! *** 207,213 $ APPS_DES = DES/DES,CBC3_ENC $ APPS_PKCS7 = ENC/ENC;DEC/DEC;SIGN/SIGN;VERIFY/VERIFY,EXAMPLE $ ! $ LIB_ = cryptlib,mem,mem_clr,mem_dbg,cversion,ex_data,cpt_err,ebcdic,uid,o_time,o_str,o_dir $ LIB_MD2 = md2_dgst,md2_one $ LIB_MD4 = md4_dgst,md4_one $ LIB_MD5 = md5_dgst,md5_one --- 207,213 $ APPS_DES = DES/DES,CBC3_ENC $ APPS_PKCS7 = ENC/ENC;DEC/DEC;SIGN/SIGN;VERIFY/VERIFY,EXAMPLE $ ! $ LIB_ = cryptlib,mem,mem_clr,mem_dbg,cversion,ex_data,cpt_err,ebcdic,uid,o_time,o_str,o_dir,o_init $ LIB_MD2 = md2_dgst,md2_one $ LIB_MD4 = md4_dgst,md4_one $ LIB_MD5 = md5_dgst,md5_one *** $ LIB_DES = set_key,ecb_enc,cbc_enc,+ *** 224,238 fcrypt,xcbc_enc,rpc_enc,cbc_cksm,+ - ede_cbcm_enc,des_old,des_old2,read2pwd $ LIB_RC2 = rc2_ecb,rc2_skey,rc2_cbc,rc2cfb64,rc2ofb64 ! $ LIB_RC4 = rc4_skey,rc4_enc $ LIB_RC5 = rc5_skey,rc5_ecb,rc5_enc,rc5cfb64,rc5ofb64 $ LIB_IDEA = i_cbc,i_cfb64,i_ofb64,i_ecb,i_skey $ LIB_BF = bf_skey,bf_ecb,bf_enc,bf_cfb64,bf_ofb64 $ LIB_CAST = c_skey,c_ecb,c_enc,c_cfb64,c_ofb64 $ LIB_CAMELLIA = camellia,cmll_misc,cmll_ecb,cmll_cbc,cmll_ofb,+ - ! cmll_cfb,cmll_ctr $ LIB_SEED = seed,seed_ecb,seed_cbc,seed_cfb,seed_ofb ! $ LIB_MODES = cbc128,ctr128,cts128,cfb128,ofb128 $ LIB_BN_ASM = [.asm]vms.mar,vms-helper $ IF F$TRNLNM(OPENSSL_NO_ASM) .OR. ARCH .NES. VAX THEN - LIB_BN_ASM = bn_asm --- 224,238 fcrypt,xcbc_enc,rpc_enc,cbc_cksm,+ - ede_cbcm_enc,des_old,des_old2,read2pwd $ LIB_RC2 = rc2_ecb,rc2_skey,rc2_cbc,rc2cfb64,rc2ofb64 ! $ LIB_RC4 = rc4_skey,rc4_enc,rc4_utl $ LIB_RC5 = rc5_skey,rc5_ecb,rc5_enc,rc5cfb64,rc5ofb64 $ LIB_IDEA = i_cbc,i_cfb64,i_ofb64,i_ecb,i_skey $ LIB_BF = bf_skey,bf_ecb,bf_enc,bf_cfb64,bf_ofb64 $ LIB_CAST
RE: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
Hello Steven, I'm having a good time, even if no one else cares. I do care. I apologize for being silent, but I have been very busy with less open source issues. I have tested your changes on IA64 and they work well, indeed. It was a bit tricky with the unusual extra 64 parameter for tests and install - but it worked perfect. Thank you very much for all effort. Hope, Richard will merge them into the code and we'll be lucky to see them in the next release. Regards, Z -Original Message- From: Steven M. Schweda [mailto:s...@antinode.info] Sent: den 14 mars 2011 13:27 To: openssl-dev@openssl.org Subject: Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS New (complete) replacement file kit: http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0d_s4.zip This includes a util/libeay.num with OPENSSL_strcasecmp, and updated builders. Previously, LINK commands in the builders lacked explicit /[NO]MAP options, so, in batch mode, where the default is /MAP, image map files (.MAP) were spewed out into the source directories. Now, for a NODEBUG build, there should be explicit /NOMAP options everywhere (except for the main shared images, as before, whether that actually makes sense or not). For a DEBUG build, there should be explicit /MAP options which specify appropriate architecture-specific destination directories, so that a .MAP file appears next to the corresponding .EXE file (leaving the source directories unmolested). More builders which open files in DCL should now have ON CONTROL_C error handling which will more reliably close these files if the user whacks the things mid-stream. Some of the test/*.com procedures are still vulnerable. I'm having a good time, even if no one else cares. 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.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
Steven, I am sorry, I could not test your changes yet - I'll do it, hopefully, during this week. ...but to be honest, I am more curious what is Richard's opinion about your changes. Regards, Z From: Steven M. Schweda [s...@antinode.info] Sent: Sunday, March 06, 2011 2:53 AM To: openssl-dev@openssl.org Subject: Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS I apparently forgot to include the modified/new start-up procedures (VMS/openssl_startup.com, VMS/openssl_undo.com) in previous update collections: http://antinode.info/ftp/openssl/1_0_0d/openssl-1_0_0d_s2c.zip 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.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
Hello, I seem to have 1.0.0d builds working on VMS Great news, I would be happy to try the build with your changes. Could you please send some instructions where the patch can be found? Or it would be the best to post the diffs here, making available for Richard to merge into the code. Thank you, Steven. Best regards, Z -Original Message- From: Steven M. Schweda [mailto:s...@antinode.info] Sent: den 28 februari 2011 07:28 To: openssl-dev@openssl.org Subject: Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS I seem to have 1.0.0d builds working on VMS with 32- or 64-bit pointers, but I'm still waiting for some guidance on how to make some of the needed changes: 1. I need a macro/typedef for an integer with the same size as a pointer. On non-VMS systems intptr_t might be suitable, but not on VMS, so it appears to me that some new OpenSSL-specific thing must be added. I can get it defined appropriately on VMS. Elsewhere, I don't care; size_t (as is used now), intptr_t, whatever. But I'd be happier (others, too, I'd guess) if someone else chose the name, placement, and other details. I've identified two places where use of size_t caused problems on VMS with 64-bit pointers, crypto/bn/bn_mont.c and crypto/bn/bn_nist.c. It might be wise to scan the code for other inappropriate uses of size_t, as I haven't done that. 2. The argv-using apps/*.c programs need reform to use argc instead of looking for a NULL terminator at the end of argv[]. (Looking for a NULL makes sense for envp[], which is expected to be NULL-terminated, but not so much for argv[], where it causes bad behavior on VMS Alpha with 64-bit pointers, and where argc is obviously available and suitable.) I've converted apps/cms.c and apps/smime.c, because those were causing test failures. My current scheme changes code like this: [...] int MAIN(int argc, char **argv) [...] char **args; [...] args = argv + 1; [...] while (*args) [or similar] [...] args++; [...] to code like this: [...] int MAIN(int argc, char **argv) [...] int argi; char **args; [...] argi = 1; args = argv[argi])[0]; [...] while (argi argc) [or similar] [...] args = argv[++argi]; [...] The maintainer(s) may prefer some other scheme/details, so I'm reluctant to fiddle with the other, similar programs in that collection until someone higher up nods, or complains, or something. (Also, I wouldn't bet that any other of those programs gets tested on VMS, so there's probably some risk in my making the changes to them.) For the ones I have changed, I can supply patches or whole replacement files, if anyone is interested. If some decision maker can settle these pending items, then I can pack this batch of changes into a form which might be more easily adopted into the main code base. Other changes: I've added a C macro, OPENSSL_NO_SETVBUF_IONBF, which is defined only on VMS, and which is used to bracket instances of setvbuf(..., _IONBF, ...). On VMS, this use of setvbuf() is unsupported, and is incompatible with 64-bit pointers. Everyone else can ignore this new macro, and get the same behavior as before. I've modified the VMS builders to allow the user to specify a path to a zlib object library (expecting zlib.h to be in the same directory). I've also done some tidying in the VMS builders (typography, lame code reduction, ...). I've added a new VMS-specific header file, crypto/vms_rms.h to reduce the code clutter involved with NAM versus NAML (RMS file name) structures (in crypto/LPdir_vms.c and crypto/dso/dso_vms.c). I use essentially similar stuff in many other projects. You're welcome to it. (I haven't added a copyright heading.) Steven M. Schweda sms@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.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
Hello, It is interesting that not forcing the /pointer_size=64 - the build is OK (by running @makevms all nodebug) Until now, I believed that DCC will use 64-bit pointers on a 64-bit architecture when the pointer size is not explicitly specified. LIBCRYPTO.OLB;312952 15-FEB-2011 11:40:04.66 (/pointer_size not specified - everything is OK) LIBCRYPTO.OLB;212501 10-FEB-2011 18:28:46.78 (/pointer_size=64 FAILED) LIBCRYPTO32.OLB;2 12404 15-FEB-2011 11:40:05.13 (/pointer_size=32) LIBCRYPTO32.OLB;1 12404 10-FEB-2011 18:28:47.14 (/pointer_size=32) Seems, there is some kind of smart cast around descriptors when not explicitly specified that the pointers' size is 64-bit. It is time to dig deeper into the literature. Regards, Z -Original Message- From: Steven M. Schweda [mailto:s...@antinode.info] Sent: den 14 februari 2011 19:52 To: openssl-dev@openssl.org Subject: Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS From: Arpadffy Zoltan via RT r...@openssl.org I have tested 1.0.0d release on OpenVMS and found many warnings during th= e build with 64bits pointer size that produced many annoying warning mess= ages during linking against the library - like: Building The BNTEST Test Program. %ILINK-W-COMPWARN, compilation warnings module: DSO_VMS file: USRDSK:[ZAY.WORK.OPENSSL-100D.IA64.EXE.CRYPTO]LIBCRYPTO.OLB= ;1 You get the LINK warning bacause you didn't fix the compiler warnings. Unfortunately the 64bit pointer size build on ALPHA has the very same fai= l. Compaq C V6.4-008 on OpenVMS Alpha V7.3-2 That's not _un_fortunate, that's _fortunate_. _Un_fortunate would be if you got results on Alpha which differed from those on IA64. Compiling The o_dir.c File. (LIBRARY,LIB) (*ctx)-filespec_dsc.dsc$a_pointer =3D (*ctx)-filespec; ...^ %CC-W-MAYLOSEDATA2, In this statement, (*ctx)-filespec has a larger da= ta size than short pointer to char. Assignment can result in data loss. at line number 121 in file USRDSK:[ZAY.WORK.OPENSSL-100D.CRYPTO]LPDIR_VMS= .C;1 Well, yeah. I'd expect a complaint every time you use a 32-bit descriptor in a 64-bit-pointer environment. While I've never used one, I assume that that's why 64-bit descriptors exist, and I'd guess that you'll need to fix all the (VMS-specific) code which uses descriptors. Knowing nothing, I'd assume that you'd need to add some 64-bit-descriptor declarations, contitional on __INITIAL_POINTER_SIZE (if __INITIAL_POINTER_SIZE == 64, say). With any luck, the consumers of these descriptors might accept either descriptor type. setvbuf(in, NULL, _IONBF, 0); /* don't do buffered reads */ ..^ %CC-W-MAYLOSEDATA2, In this statement, in has a larger data size than = short p ointer to short pointer to struct _iobuf. Assignment can result in data= loss. at line number 147 in file USRDSK:[ZAY.WORK.OPENSSL-100D.CRYPTO.RAND]RAND= FILE.C; Apparently (stdio,h), setvbuf() is in the category of functions and declarations which do not support 64 bit pointers being passed (or returned). I'd guess that you'll need to disable that code on VMS, at least when 64-bit pointers are used. (It may be unwise to have the behavior on VMS depend on the pointer size, so it might be better to disable it always on VMS.) Any such change should include a good explanation in its comments. Steven M. Schweda sms@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.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
Hello Steven, The time for that might actually have been near when you were first thinking about saying /POINTER_SIZE = 64. Yes, you are right... I was running ahead without learning enough about the topic. Then, after all, I think, the best solution would be to leave as it is and close this (#2449) issue. We can continue to live with default (/NOPOINTER_SIZE) and optional 32-bit build (/POINTER_SIZE=32) Maybe, it would be useful to change the makevms.com script that do not allow /POINTER_SIZE=64 parameter, but in those cases change that to /NOPOINTER_SIZE instead. What is your opinion? Regards, Z -Original Message- From: Steven M. Schweda [mailto:s...@antinode.info] Sent: den 15 februari 2011 14:48 To: openssl-dev@openssl.org Subject: Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS From: Arpadffy Zoltan zoltan.arpad...@scientificgames.se It is interesting that not forcing the /pointer_size=3D64 - the build is OK= (by running @makevms all nodebug) Interesting, perhaps, but not really news. HELP CC /POINTER_SIZE [...] Specifying /POINTER_SIZE=32 directs the compiler to assume that all pointers are 32-bit pointers. But unlike the default of /NOPOINTER_SIZE, /POINTER_SIZE=32 enables use of the #pragma pointer_size long and #pragma pointer_size short preprocessor directives to control pointer size throughout your program. [...] Until now, I believed that DCC will use 64-bit pointers on a 64-bit archite= cture when the pointer size is not explicitly specified. If DCC is anything like DEC/Compaq/HP C, then no, as documented. Seems, there is some kind of smart cast around descriptors when not explici= tly specified that the pointers' size is 64-bit. HELP CC Language_topics Preprocessor #pragma Look for pointer_size. It is time to dig deeper into the literature. The time for that might actually have been near when you were first thinking about saying /POINTER_SIZE = 64. Note that (as I read the stuff) most of the RMS structures, including FAB and NAM[L], support only 32-bit pointers/descriptors, so all those file names can't use 64-bit pointers/descriptors. I took a quick look at this stuff and decided that some thought would be needed to decide how to make it work. I suspect that some string copying will be needed for the RMS stuff. Steven M. Schweda sms@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.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
Hello, Why have a build option which doesn't work? Actually, it works good enough to keep, as we can still use the following options: - 32 for build with /POINTER_SIZE=32 - that is used often together with older applications. - for build with default /NOPOINTER_SIZE (that is definitely not compatible nor exchangeable with /POINTER_SIZE=32 built libraries. Therefore, the important thing that is needed to be noted for such dummy dreamers like me, that parameter 64 is not equal to parameter - and those two are not exchangeable. Hmmm also make a side note, that the current OpenSSL code is not able to be built with full 64-bit pointer size option - but as we lived so far without it - we can continue to use the OpenSSL libraries as it is, until somebody really needs 64-bit pointer size. Thank you, Steven. Regards, Z -Original Message- From: Steven M. Schweda [mailto:s...@antinode.info] Sent: den 15 februari 2011 15:40 To: openssl-dev@openssl.org Subject: Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS From: Arpadffy Zoltan zoltan.arpad...@scientificgames.se Then, after all, I think, the best solution would be to leave as it is and = close this (#2449) issue. We can continue to live with default (/NOPOINTER_SIZE) and optional 32-bit = build (/POINTER_SIZE=3D32) Maybe, it would be useful to change the makevms.com script that do not allo= w /POINTER_SIZE=3D64 parameter, but in those cases change that to /NOPOINTE= R_SIZE instead. What is your opinion? My opinion is that if a build with 64-bit pointers is important, then the VMS-specific code should be fixed enough to let it work. If it's not important, then why do _anything_ with /POINTER_SIZE? Why have a build option which doesn't work? As usual, it might be nice to know how HP handled this, but I'm not holding my breath while we wait to hear from them. Steven M. Schweda sms@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.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
Steven, You are right again - as always. I checked the HP's code and indeed, they use $ USER_CCFLAGS == /pointer_size=64 This means that the HP SSL product really does deliver both 32 and 64 bit libraries. It would be fruitful, if somebody competent could look into the HP's code and see how they solved the 64-bit descriptors issue. Regards, Z -Original Message- From: Steven M. Schweda [mailto:s...@antinode.info] Sent: den 15 februari 2011 16:14 To: openssl-dev@openssl.org Subject: Re: [openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS From: Arpadffy Zoltan zoltan.arpad...@scientificgames.se Why have a build option which doesn't work? Actually, it works good enough to keep, as we can still use the following o= ptions: - 32 for build with /POINTER_SIZE=3D32 - that is used often together with o= lder applications. - for build with default /NOPOINTER_SIZE (that is definitely not compati= ble nor exchangeable with /POINTER_SIZE=3D32 built libraries. A library built using /POINTER_SIZE=32 is _not_ the same as one built using /NOPOINTER_SIZE? Really? I can see where /POINTER_SIZE=64 would be different. How is /POINTER_SIZE=32 different? (I can also see where it might be important to say /POINTER_SIZE=64=ARGV, when building a main program with 64-bit pointers, too.) Therefore, the important thing that is needed to be noted for such dummy dr= eamers like me, that parameter 64 is not equal to parameter - and those = two are not exchangeable. Perhaps everyone else reads the HELP (or the other documentation). Hmmm also make a side note, that the current OpenSSL code is not able to be= built with full 64-bit pointer size option - but as we lived so far withou= t it - we can continue to use the OpenSSL libraries as it is, until somebod= y really needs 64-bit pointer size. Define we. HP supplies SSL$LIBCRYPTO_SHR.EXE, SSL$LIBCRYPTO_SHR32.EXE, SSL$LIBSSL_SHR.EXE, and SSL$LIBSSL_SHR32.EXE. I thought that the whole idea was to get the OpenSSL builder(s) to create SSL_LIBCRYPTO_SHR.EXE/OLB, SSL_LIBCRYPTO_SHR32.EXE/OLB, SSL_LIBSSL_SHR.EXE/OLB, and SSL_LIBSSL_SHR32.EXE/OLB, that is, 32- and 64-bit libraries and shared images. (Even if no one wanted to add the SSL_ prefixes.) Did I miss something? Steven M. Schweda sms@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
[openssl.org #2449] [BUG] openssl 1.0.0d warnings during build and ACCVIO on OpenVMS
Hello, I have tested 1.0.0d release on OpenVMS and found many warnings during the build with 64bits pointer size that produced many annoying warning messages during linking against the library - like: Building The BNTEST Test Program. %ILINK-W-COMPWARN, compilation warnings module: DSO_VMS file: USRDSK:[ZAY.WORK.OPENSSL-100D.IA64.EXE.CRYPTO]LIBCRYPTO.OLB;1 ...that most likely produces an ACCVIO I have build on an IA64 environment HP C V7.2-001 on OpenVMS IA64 V8.3 and got: test BN_mont Montgomery multiplication test failed! %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00649D580064 9D50, PC=00274650, PS=001B Improperly handled condition, image exit forced. Signal arguments: Number = 0005 Name = 000C 00649D5800649D50 00274650 001B Register dump: R0 = R1 = 007D R2 = 7ACAF340 R3 = 00032A00 R4 = 7FFCF818 R5 = 7FFCF8B0 R6 = 100A R7 = 0001 R8 = R9 = 0014 R10 = 12D061D4 R11 = 12D061C0 SP = 7ACAF330 TP = 7B722D40 R14 = 7B8E19DC R15 = 7ACAF330 R16 = 0001 R17 = FFDD R18 = 001A R19 = 0040 R20 = 12D061D4 R21 = 12D061C0 R22 = 8002A330 R23 = 001DB1A9 R24 = 0011 R25 = 0001 R26 = 5964280C R27 = 31750614 R28 = 0008 R29 = 0011 R30 = B2C85018 R31 = 7ACAF7C5 PC = 00274650 BSP/STORE = 07FDBFFD4448 / 07FDBFFD4290 PSR = 101308026030 IIPA = 00274640 B0 = 00032A30 B6 = 00032A00 B7 = 000326B0 Interrupted Frame RSE Backing Store, Size = 4 registers R32 = 00649D5800649D50 R33 = 881A3D00 R34 = R35 = C205 It is interesting that the 32 bit pointer size build has not had such problems at all. Unfortunately the 64bit pointer size build on ALPHA has the very same fail. Compaq C V6.4-008 on OpenVMS Alpha V7.3-2 test BN_mont Montgomery multiplication test failed! %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0038BF880038BF80, PC=00228FB4, PS=001B Improperly handled condition, image exit forced. Signal arguments: Number = 0005 Name = 000C 0038BF880038BF80 00228FB4 001B Register dump: R0 = 0002 R1 = 0038BF880038BF80 R2 = 80023F70 R3 = 7AE07340 R4 = 0001 R5 = 000ED530 R6 = R7 = 7AE073E8 R8 = 000ED550 R9 = 0002 R10 = 80023F70 R11 = 7FFCDBE0 R12 = 7FFCDA60 R13 = 7AF247E0 R14 = R15 = 7AF23E20 R16 = 0038BF880038BF80 R17 = 7AE07340 R18 = 7AE072E8 R19 = 0001 R20 = 00CB R21 = 0020 R22 = 23A567C0 R23 = R24 = 0014 R25 = 0001 R26 = 00228E2C R27 = 0004CE58 R28 = 2825CECD R29 = 7AE07260 SP = 7AE07260 PC = 00228FB4 PS = 201B @MAKEVMS.COM ALL 64 nodebug Compiling The o_dir.c File. (LIBRARY,LIB) (*ctx)-filespec_dsc.dsc$a_pointer = (*ctx)-filespec; ...^ %CC-W-MAYLOSEDATA2, In this statement, (*ctx)-filespec has a larger data size than short pointer to char. Assignment can result in data loss. at line number 121 in file USRDSK:[ZAY.WORK.OPENSSL-100D.CRYPTO]LPDIR_VMS.C;1 %LIBRAR-W-COMCOD, compilation warnings in module O_DIR file USRDSK:[ZAY.WORK.OPE NSSL-100D.IA64.OBJ.CRYPTO]O_DIR.OBJ;1 dso_vms.c p-filename_dsc.dsc$a_pointer = p-filename; ^ %CC-W-MAYLOSEDATA2, In this statement, p-filename has a larger data size than short pointer to char. Assignment can result in data loss. at line number 212 in file USRDSK:[ZAY.WORK.OPENSSL-100D.CRYPTO.DSO]DSO_VMS.C;1 p-imagename_dsc.dsc$a_pointer = p-imagename;
VMS build successful on all platforms
Hello, I am happy to inform you that I have successfully build latest 1.0.1 STABLE snapshot on IA64, Alpha and VAX platform both with 64 and 32 pointer size. All tests pass well except: signed content test streaming BER format, DSA key: OK Fatal VMS error (status=1409588) at PERLKIT:[SOURCE]VMS.C;1, line 4747 at cms-test.pl line 393. %LIB-F-INVARG, invalid argument(s) OpenSSL 1.0.1-dev xx XXX built on: 11-JAN-2011 10:35:12.60 platform: VMS VAX V7.2 options: bn(32,32) md2(int) rc4(ptr,char) des(ptr,cisc,2,long) idea(int) blowfish(idx) compiler: /POINTER_SIZE= OPENSSLDIR: N/A ...because my VAX does not have perl installed at all. Also building on VAX required extra parameters in order to come over the TCPIP linking problem: Building OpenSSL [.VAX.EXE.APPS] Applications. No Debugger Information Will Be Produced During Compile. Compiling With Compiler Optimization. Using VAXC 'C' Compiler. TCP/IP library spec: Main Compiling Command: CC/OPTIMIZE/NODEBUG/NOLIST/INCLUDE=(SYS$DISK:[-],SYS$DISK:[-.CRYPTO])/DEFINE=(FLAT_INC=1,MONOLITH,VAXC,TCPIP _TYPE_NONE) Compiling On A VAX Machine. Using Linker Option File SYS$DISK:[-.VAX.EXE.APPS]VAX_VAXC_OPTIONS.OPT. Compiling The OPENSSL.C File. [...] Compiling The TS.C File. OPENSSL needs a TCP/IP library. Can't link. Skipping... The winning command line looks like below (if you have HP's TCPIP product) @makevms ALL nodebug DECC TCPIP or @makevms ALL nodebug VAXC TCPIP Please note, that the 5th parameter is not straight forward: TITAN2_ZAY $ @makevms USAGE: @MAKEVMS.COM [Target] [Pointer size] [Debug option] Compiler ...even thou it is correctly handled in the build script: TITAN2_ZAY $ @makevms ALL NODEBUG whatever Using DECC 'C' Compiler. The Option WHATEVER Is Invalid. The Valid Options Are: SOCKETSHR : To link with SOCKETSHR TCP/IP library. UCX: To link with UCX TCP/IP library. TCPIP : To link with TCPIP TCP/IP (post UCX) library. NONE : To not link with a specific TCP/IP library. I would suggest adding the 5th parameter as well to the help/usage line like for example: USAGE: @MAKEVMS.COM [Target] [Pointer size] [Debug option] Compiler TCP/IP lib Thank you Richard, for hard work and well done code merge that lead us to enjoy OpenSSL provided cutting edge functionality on OpenVMS platform and making the VMS user's community independent of HP OPENSSL product (that is usually years behind the official OpenSSL releases both in features and security fixes) Regards, Z
[openssl.org #2425] [PATCH] VMS build fails - buf_str is missing in .cryptoCRYPTO-LIB.COM
Hello, VMS build fails with %LINK-W-NUDFSYMS, 3 undefined symbols: %LINK-I-UDFSYM, BUF_STRDUP %LINK-I-UDFSYM, BUF_STRLCAT %LINK-I-UDFSYM, BUF_STRLCPY ...because buf_str is not listed among BUFFER files in .cryptoCRYPTO-LIB.COM Please, find the patch that solves the problem. TITAN2_ZAY $ diff .cryptoCRYPTO-LIB.COM File USRDSK:ZAY.WORK.OPENSSL-101-STABLE-SNAP-20110110.CRYPTOCRYPTO-LIB.COM;2 234 $ LIB_BUFFER = buffer,buf_err,buf_str 235 $ LIB_BIO = bio_lib,bio_cb,bio_err,+ - ** File USRDSK:ZAY.WORK.OPENSSL-101-STABLE-SNAP-20110110.CRYPTOCRYPTO-LIB.COM;1 234 $ LIB_BUFFER = buffer,buf_err 235 $ LIB_BIO = bio_lib,bio_cb,bio_err,+ - Number of difference sections found: 1 Number of difference records found: 1 Thank you. Regards, Z Hello, VMS build fails with %LINK-W-NUDFSYMS, 3 undefined symbols: %LINK-I-UDFSYM, BUF_STRDUP %LINK-I-UDFSYM, BUF_STRLCAT %LINK-I-UDFSYM, BUF_STRLCPY because buf_str is not listed among BUFFER files in .cryptoCRYPTO-LIB.COM Please, find the patch that solves the problem. TITAN2_ZAY $ diff .cryptoCRYPTO-LIB.COM File USRDSK:ZAY.WORK.OPENSSL-101-STABLE-SNAP-20110110.CRYPTOCRYPTO-LIB.COM;2 234 $ LIB_BUFFER = buffer,buf_err,buf_str 235 $ LIB_BIO = bio_lib,bio_cb,bio_err,+ - ** File USRDSK:ZAY.WORK.OPENSSL-101-STABLE-SNAP-20110110.CRYPTOCRYPTO-LIB.COM;1 234 $ LIB_BUFFER = buffer,buf_err 235 $ LIB_BIO = bio_lib,bio_cb,bio_err,+ - Number of difference sections found: 1 Number of difference records found: 1 Thank you. Regards, Z
[openssl.org #2407] RE: [BUG] On VMS VAX the APPS and ENGINES build fails
Hello, I forward again a VAX related part of the mail to RT in hope that this issue will not be forgotten. While the VMS build on IA64 and ALPHA architecture works perfect on VAX the APPS and ENGINES build fails (openssl-1.0.1-stable-SNAP-20101215) A bit weird, that on VAX during APPS build appeared the following text: Building The SSLTEST Test Program. SSLTEST Needs A TCP/IP Library. Can't Link. Skipping... Therefore the OPENSSL executable is not linked. I have not investigated deeper, but guess it have not found the TCPIP product libraries by default as it did successfully on other architectures. I have tried to submit the TCPIP parameter, but did not help :( -- ...also on VAX the ENGINES build fails because can not find the include files: Compiling The 4758cca Library Files. (ENGINES) e_4758cca #include hw_4758_cca.h .^ %CC-F-NOINCLFILE, Cannot find file hw_4758_cca.h specified in #include directive. At line number 73 in DKA400:[ZOLI.OPENSSL-101-STABLE-SNAP-20101215.ENGINES]E_4758CCA.C;1. #include hw_4758_cca.h .^ %VCG-I-NOBJECT, No object file produced. At line number 73 in DKA400:[ZOLI.OPENSSL-101-STABLE-SNAP-20101215.ENGINES]E_4758CCA.C;1. %LINK-W-NUDFSYMS, 2 undefined symbols: %LINK-I-UDFSYM, BIND_ENGINE %LINK-I-UDFSYM, V_CHECK %LINK-W-USEUNDEF, undefined symbol BIND_ENGINE referenced in psect $$ENGINE offset %X in module ENGINE file DKA400:[ZOLI.OPENSSL-101-STABLE-SNAP-20101215.VAX.OBJ.ENGINES]ENGINE_VECTOR.OBJ;5 In fact none of the include files are found from VENDOR_DEFNS because: Main C Compiling Command: CC/OPTIMIZE/NODEBUG/NOLIST/INCLUDE=(SYS$DISK:[],SYS$DISK:[-],SYS$DISK:[.ENGINE.VENDOR_DEFNS])/DEFINE=( FLAT_INC=1,VAXC,TCPIP_TYPE_NONE,DSO_VMS) While ALPHA and IA64 correctly used SYS$DISK:[.VENDOR_DEFNS] The following patch (that adds SYS$DISK:[.VENDOR_DEFNS] to the include path) fixes this minor problem: TITAN2_ZAY $ diff .ENGINESMAKEENGINES.COM File USRDSK:ZAY.WORK.OPENSSL-101-STABLE-SNAP-20101215.ENGINESMAKEENGINES.COM;2 783 /INCLUDE=(SYS$DISK:[],SYS$DISK:[-],SYS$DISK:[.VENDOR_DEFNS],SYS$DISK:[.ENGINE.VENDOR_DEFNS]) + - 784 CCEXTRAFLAGS ** File USRDSK:ZAY.WORK.OPENSSL-101-STABLE-SNAP-20101215.ENGINESMAKEENGINES.COM;1 783 /INCLUDE=(SYS$DISK:[],SYS$DISK:[-],SYS$DISK:[.ENGINE.VENDOR_DEFNS]) + - 784 CCEXTRAFLAGS File USRDSK:ZAY.WORK.OPENSSL-101-STABLE-SNAP-20101215.ENGINESMAKEENGINES.COM;2 815 /INCLUDE=(SYS$DISK:[],SYS$DISK:[-],SYS$DISK:[.VENDOR_DEFNS],SYS$DISK:[.ENGINE.VENDOR_DEFNS]) + - 816 CCEXTRAFLAGS ** File USRDSK:ZAY.WORK.OPENSSL-101-STABLE-SNAP-20101215.ENGINESMAKEENGINES.COM;1 815 /INCLUDE=(SYS$DISK:[],SYS$DISK:[-],SYS$DISK:[.ENGINE.VENDOR_DEFNS]) + - 816 CCEXTRAFLAGS Number of difference sections found: 2 Number of difference records found: 2 Thank you. Regards, Z Hello, I forward again a VAX related part of the mail to RT in hope that this issue will not be forgotten. While the VMS build on IA64 and ALPHA architecture works perfect on VAX the APPS and ENGINES build fails (openssl-1.0.1-stable-SNAP-20101215) A bit weird, that on VAX during APPS build appeared the following text: Building The SSLTEST Test Program. SSLTEST Needs A TCP/IP Library. Can't Link. Skipping... Therefore the OPENSSL executable is not linked. I have not investigated deeper, but guess it have not found the TCPIP product libraries by default as it did successfully on other architectures. I have tried to submit the TCPIP parameter, but did not help :( -- ...also on VAX the ENGINES build fails because can not find the include files: Compiling The 4758cca Library Files. (ENGINES) e_4758cca #include hw_4758_cca.h .^ %CC-F-NOINCLFILE, Cannot find file hw_4758_cca.h specified in #include directive. At line number 73 in DKA400:[ZOLI.OPENSSL-101-STABLE-SNAP-20101215.ENGINES]E_4758CCA.C;1. #include hw_4758_cca.h .^ %VCG-I-NOBJECT, No object file produced. At line number 73 in DKA400:[ZOLI.OPENSSL-101-STABLE-SNAP-20101215.ENGINES]E_4758CCA.C;1. %LINK-W-NUDFSYMS, 2 undefined symbols: %LINK-I-UDFSYM, BIND_ENGINE %LINK-I-UDFSYM, V_CHECK %LINK-W-USEUNDEF, undefined symbol BIND_ENGINE referenced in psect $$ENGINE offset %X in module ENGINE file DKA400:[ZOLI.OPENSSL-101-STABLE-SNAP-20101215.VAX.OBJ.ENGINES]ENGINE_VECTOR.OBJ;5 In fact none of the include files are found from VENDOR_DEFNS because: Main C Compiling Command: CC/OPTIMIZE/NODEBUG/NOLIST/INCLUDE=(SYS$DISK:[],SYS$DISK:[-],SYS$DISK:[.ENGINE.VENDOR_DEFNS])/DEFINE=(
RE: [openssl.org #2099] [PATCH] OpenSSL 1.0.0 beta4 release (OpenVMS)
Hello Richard, Is parts of this still an issue or can I simply close this ticket? I have verified the listed issues and seem all of them are resolved in openssl-1.0.1-stable-SNAP-20101215 and I would suggest closing the ticket. Thank you, Richard. Regards, Z -Original Message- From: Richard Levitte via RT [mailto:r...@openssl.org] Sent: den 16 december 2010 01:18 To: Arpadffy Zoltan Cc: openssl-dev@openssl.org Subject: [openssl.org #2099] [PATCH] OpenSSL 1.0.0 beta4 release (OpenVMS) Is parts of this still an issue or can I simply close this ticket? [zoltan.arpad...@scientificgames.se - Fri Nov 13 09:12:58 2009]: Hello, Can you (and others in this thread) please submit bug fix patches to the request tracker (r...@openssl.org) so they don't get overlooked?? Please note this is the official submit to RT (mail already submitted to the list) Additionally to SMS's changes (below)... here are the changes that are needed to be added in order to get OpenVMS build correctly. The only extra improvement is that I used the unused second variable to configure the pointer size (32 or 64). TODO: The CA.COM is not usable as it is therefore both tests: TESTCA.COM and TESTTSA.COM fail. Regards, Z TOR_ZAY $ gdiff -p DSA104:USERS.ZAY.WORK.OPENSSL-100-BETA4- ORIGMAKEVMS.COM DSA104:USERS.ZAY.WORK.OPENSSL-100-BETA4MAKEVMS.COM *** dsa104:users.zay.work.openssl-100-beta4-origmakevms.com Tue Aug 25 09:30:02 2009 --- dsa104:users.zay.work.openssl-100-beta4makevms.comThu Nov 12 11:01:00 2009 *** $! End *** 347,356 $! $ ENDIF $! - $! There are many places where this is needed. - $! - $ WRITE H_FILE #define _XOPEN_SOURCE_EXTENDED - $! $! Close the [.CRYPTO.ARCH]OPENSSLCONF.H file $! $ CLOSE H_FILE --- 347,352 *** $ TIME = F$TIME() *** 386,392 $! $! Write The [.CRYPTO.ARCH]BUILDINF.H File. $! ! $ WRITE H_FILE #define CFLAGS /* Not filled in for now */ $ WRITE H_FILE #define PLATFORM VMS ''ARCH' ''VMS_VER' $ WRITE H_FILE #define DATE ''TIME' $! --- 382,388 $! $! Write The [.CRYPTO.ARCH]BUILDINF.H File. $! ! $ WRITE H_FILE #define CFLAGS /pointer_size=''POINTER_SIZE'/float=g /* compiler flags */ $ WRITE H_FILE #define PLATFORM VMS ''ARCH' ''VMS_VER' $ WRITE H_FILE #define DATE ''TIME' $! *** $! Tell The User We Are Partly Rebuildin *** 410,416 $! $ WRITE SYS$OUTPUT Rebuilding The '[.APPS]MD4.C', '[.APPS]MD5.C' And '[.APPS]RMD160.C' Files. $! ! $ DELETE SYS$DISK:[.APPS]MD4.C;*,MD5.C;*,RMD160.C;* $! $! Copy MD4.C from [.CRYPTO.MD4] into [.APPS] $! --- 406,412 $! $ WRITE SYS$OUTPUT Rebuilding The '[.APPS]MD4.C', '[.APPS]MD5.C' And '[.APPS]RMD160.C' Files. $! ! $ DELETE /NOLOG SYS$DISK:[.APPS]MD4.C;*,MD5.C;*,RMD160.C;* $! $! Copy MD4.C from [.CRYPTO.MD4] into [.APPS] $! *** $! *** 431,438 $! First, We Have To Rebuild The [.TEST] Directory, So Delete $! All The C Files That Are Currently There Now. $! ! $ DELETE SYS$DISK:[.TEST]*.C;* ! $ DELETE SYS$DISK:[.TEST]EVPTESTS.TXT;* $! $! Copy all the *TEST.C files from [.CRYPTO...] into [.TEST] $! --- 427,434 $! First, We Have To Rebuild The [.TEST] Directory, So Delete $! All The C Files That Are Currently There Now. $! ! $ DELETE /NOLOG SYS$DISK:[.TEST]*.C;* ! $ DELETE /NOLOG SYS$DISK:[.TEST]EVPTESTS.TXT;* $! $! Copy all the *TEST.C files from [.CRYPTO...] into [.TEST] $! *** $! *** 755,761 $!Tell The User We Don't Know What They Want. $! $ WRITE SYS$OUTPUT ! $ WRITE SYS$OUTPUT USAGE: @MAKEVMS.COM [Target] [not-used option] [Debug option] Compiler $ WRITE SYS$OUTPUT $ WRITE SYS$OUTPUT Example: @MAKEVMS.COM ALL NORSAREF NODEBUG $ WRITE SYS$OUTPUT --- 751,757 $!Tell The User We Don't Know What They Want. $! $ WRITE SYS$OUTPUT ! $ WRITE SYS$OUTPUT USAGE: @MAKEVMS.COM [Target] [Pointer size] [Debug option] Compiler $ WRITE SYS$OUTPUT $ WRITE SYS$OUTPUT Example: @MAKEVMS.COM ALL NORSAREF NODEBUG $ WRITE SYS$OUTPUT *** $! End The P1 Check. *** 794,799 --- 790,825 $! $ ENDIF $! + $! 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 Arguement Check. + $! + $ ENDIF + $ ENDIF + $! End
RE: [openssl.org #2393] [PATCH] 32/64 bit pointer_size choice in the VMS build
of difference sections found: 2 Number of difference records found: 2 Thank you. Regards, Z -Original Message- From: Richard Levitte via RT [mailto:r...@openssl.org] Sent: den 16 december 2010 01:12 To: Arpadffy Zoltan Cc: openssl-dev@openssl.org Subject: [openssl.org #2393] [PATCH] 32/64 bit pointer_size choice in the VMS build I've now tested to build with the pointer size arguments 32, 64 and . The scripts appear to do what they should, so I'm resolving this ticket. However, a warning: with the pointer size specified to 32 or 64, there are warnings about pointer size differences (short pointer vs. long pointer), which might have pretty serious results. It's an effort of its own to resolve those problems, but I'd say that requires separate tickets, as this one was about changes to the build scripts. -- Richard Levitte levi...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #2393] [PATCH] 32/64 bit pointer_size choice in the VMS build
Hello Richard, Thank you for taking the time to move this issue forward. There are things missing in the patch, such as actually using /POINTER_SIZE with the compiling steps The pointer size is set from the makevms.com file with the following line: $ WRITE H_FILE #define CFLAGS /pointer_size=''POINTER_SIZE' /* compiler flags */ Unfortunately, I currently only have Alphas to test on. I hope someone else can test on other platforms. I have tested the patch on IA64 built on: 7-DEC-2010 11:34:44.59 platform: VMS IA64 V8.3 compiler: /pointer_size=32 but have access to VAX (@polarhome.com), Alpha and IA64 as well. Regards, Z -Original Message- From: Richard Levitte via RT [mailto:r...@openssl.org] Sent: den 14 december 2010 11:01 To: Arpadffy Zoltan Cc: openssl-dev@openssl.org Subject: [openssl.org #2393] [PATCH] 32/64 bit pointer_size choice in the VMS build I've started on it. There are things missing in the patch, such as actually using /POINTER_SIZE with the compiling steps, but otherwise it seems fairly sound. I'll work the rest out. Unfortunately, I currently only have Alphas to test on. I hope someone else can test on pther platforms. [zoltan.arpad...@scientificgames.se - Tue Dec 14 05:44:53 2010]: Hello I'm sending again to RT - otherwise it might be forgotten. I would appreciate any comment. Thank you. Regards, Z -Original Message- From: Arpadffy Zoltan [mailto:zoltan.arpad...@scientificgames.se] Sent: den 7 december 2010 12:54 To: Richard Levitte; openssl-dev@openssl.org Subject: RE: buid STABLE-SNAP-20101124 on platform: VMS IA64 V8.3 Hello Richard, I am sorry for delay, but I am quite busy nowadays. Zoltan.Arpadffy Zoltan.Arpadffy ...I am dreaming of the possibility to choose between the 64 and the 32 bit version build and reuse this not-used option in MAKEVMS.COM Zoltan.Arpadffy Zoltan.Arpadffy During the summer I have submitted a patch for this feature... wonder is there any chance for this code to be merged in? Zoltan.Arpadffy Zoltan.Arpadffy Richard Levitte I recall discussing it, because it seemed to be a no-op... but I can't recall getting to an answer (and I'll admit not being a good Zoltan.Arpadffy participant in that discussion). Zoltan.Arpadffy Zoltan.Arpadffy This would be very useful as there are still users that link against 32 bit libraries for some reasons. Zoltan.Arpadffy From other side the current 64 bits build stays as a default and you would not see any difference if the 32 bit parameter is not explicitly used. Zoltan.Arpadffy Zoltan.Arpadffy I'll prepare a patch against STABLE-SNAP-20101124 and when I'm ready I'll submit it again. Richard Levitte I'll have a look at it when I get it :-) Please, review the attached patch (against STABLE-SNAP-20101124). Changes is short: USAGE: @MAKEVMS.COM [Target] Pointer size Debug option Compiler Like @MAKEVMS.COM ALL Defaults: Pointer size = 64 (VAX 32) Debug option= NODEBUG Libraries with pointer_size=32 has a 32 sufix in the name (LIBCRYPTO32, LIBSSL32) pointer_size=64 is the default (except on VAX) and produces standard libraries (LIBCRYPTO, LIBSSL) It works well on my system. ALL TESTS SUCCESSFUL. OpenSSL 1.0.1-dev xx XXX built on: 7-DEC-2010 11:34:44.59 platform: VMS IA64 V8.3 options: bn(64,64) md2(int) rc4(ptr,int) des(ptr,risc1,16,long) idea(int) blowfish(idx) compiler: /pointer_size=32 OPENSSLDIR: N/A Thank you. Regards, Z -- Richard Levitte levi...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2393] [PATCH] 32/64 bit pointer_size choice in the VMS build
Hello I'm sending again to RT - otherwise it might be forgotten. I would appreciate any comment. Thank you. Regards, Z -Original Message- From: Arpadffy Zoltan [mailto:zoltan.arpad...@scientificgames.se] Sent: den 7 december 2010 12:54 To: Richard Levitte; openssl-dev@openssl.org Subject: RE: buid STABLE-SNAP-20101124 on platform: VMS IA64 V8.3 Hello Richard, I am sorry for delay, but I am quite busy nowadays. Zoltan.Arpadffy Zoltan.Arpadffy ...I am dreaming of the possibility to choose between the 64 and the 32 bit version build and reuse this not-used option in MAKEVMS.COM Zoltan.Arpadffy Zoltan.Arpadffy During the summer I have submitted a patch for this feature... wonder is there any chance for this code to be merged in? Zoltan.Arpadffy Zoltan.Arpadffy Richard Levitte I recall discussing it, because it seemed to be a no-op... but I can't recall getting to an answer (and I'll admit not being a good Zoltan.Arpadffy participant in that discussion). Zoltan.Arpadffy Zoltan.Arpadffy This would be very useful as there are still users that link against 32 bit libraries for some reasons. Zoltan.Arpadffy From other side the current 64 bits build stays as a default and you would not see any difference if the 32 bit parameter is not explicitly used. Zoltan.Arpadffy Zoltan.Arpadffy I'll prepare a patch against STABLE-SNAP-20101124 and when I'm ready I'll submit it again. Richard Levitte I'll have a look at it when I get it :-) Please, review the attached patch (against STABLE-SNAP-20101124). Changes is short: USAGE: @MAKEVMS.COM [Target] Pointer size Debug option Compiler Like @MAKEVMS.COM ALL Defaults: Pointer size = 64 (VAX 32) Debug option= NODEBUG Libraries with pointer_size=32 has a 32 sufix in the name (LIBCRYPTO32, LIBSSL32) pointer_size=64 is the default (except on VAX) and produces standard libraries (LIBCRYPTO, LIBSSL) It works well on my system. ALL TESTS SUCCESSFUL. OpenSSL 1.0.1-dev xx XXX built on: 7-DEC-2010 11:34:44.59 platform: VMS IA64 V8.3 options: bn(64,64) md2(int) rc4(ptr,int) des(ptr,risc1,16,long) idea(int) blowfish(idx) compiler: /pointer_size=32 OPENSSLDIR: N/A Thank you. Regards, Z pointer_size.patch Description: Binary data
RE: buid STABLE-SNAP-20101124 on platform: VMS IA64 V8.3
Hello Richard, I am sorry for delay, but I am quite busy nowadays. Zoltan.Arpadffy Zoltan.Arpadffy ...I am dreaming of the possibility to choose between the 64 and the 32 bit version build and reuse this not-used option in MAKEVMS.COM Zoltan.Arpadffy Zoltan.Arpadffy During the summer I have submitted a patch for this feature... wonder is there any chance for this code to be merged in? Zoltan.Arpadffy Zoltan.Arpadffy Richard Levitte I recall discussing it, because it seemed to be a no-op... but I can't recall getting to an answer (and I'll admit not being a good Zoltan.Arpadffy participant in that discussion). Zoltan.Arpadffy Zoltan.Arpadffy This would be very useful as there are still users that link against 32 bit libraries for some reasons. Zoltan.Arpadffy From other side the current 64 bits build stays as a default and you would not see any difference if the 32 bit parameter is not explicitly used. Zoltan.Arpadffy Zoltan.Arpadffy I'll prepare a patch against STABLE-SNAP-20101124 and when I'm ready I'll submit it again. Richard Levitte I'll have a look at it when I get it :-) Please, review the attached patch (against STABLE-SNAP-20101124). Changes is short: USAGE: @MAKEVMS.COM [Target] Pointer size Debug option Compiler Like @MAKEVMS.COM ALL Defaults: Pointer size = 64 (VAX 32) Debug option= NODEBUG Libraries with pointer_size=32 has a 32 sufix in the name (LIBCRYPTO32, LIBSSL32) pointer_size=64 is the default (except on VAX) and produces standard libraries (LIBCRYPTO, LIBSSL) It works well on my system. ALL TESTS SUCCESSFUL. OpenSSL 1.0.1-dev xx XXX built on: 7-DEC-2010 11:34:44.59 platform: VMS IA64 V8.3 options: bn(64,64) md2(int) rc4(ptr,int) des(ptr,risc1,16,long) idea(int) blowfish(idx) compiler: /pointer_size=32 OPENSSLDIR: N/A Thank you. Regards, Z pointer_size.patch Description: pointer_size.patch
RE: VMS upgrades and OpenSSL
Hello, Meanwhile the problem is solved... all this is caused by the new C-RTL that handles wrong programming habits on a different way, like non initialized variables are not memsetted etc. In one word: this is not an OpenSSL issue. However, what is interesting that using session cache caused also problems in the multithreaded (AST) network application running under VMS 8.3, therefore it was needed to turn off (SSL_SESS_CACHE_OFF) Regards, Z -Original Message- From: Arpadffy Zoltan [mailto:zoltan.arpad...@scientificgames.se] Sent: den 1 december 2010 12:56 To: openssl-dev@openssl.org Subject: VMS upgrades and OpenSSL Hello, this is a very much VMS related question. I have recently noticed that a VMS executable is sensitive to VMS upgrade if statically linked with an OpenSSL library. OpenSSL (0.9.8.h) is build under VMS 7.3-2 and statically linked with an executable. This runs perfect on a VMS 7.3-2 system. When the VMS is upgraded to VMS 8.3 the very same executable fails with SSL error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt error message in the function SSL_CTX_use_PrivateKey_file(ctx, serverKey, SSL_FILETYPE_PEM) Does anybody have any experience eventually a suggestion that could lead to a solution? Thank you in advance. Regards, Z __ 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
VMS upgrades and OpenSSL
Hello, this is a very much VMS related question. I have recently noticed that a VMS executable is sensitive to VMS upgrade if statically linked with an OpenSSL library. OpenSSL (0.9.8.h) is build under VMS 7.3-2 and statically linked with an executable. This runs perfect on a VMS 7.3-2 system. When the VMS is upgraded to VMS 8.3 the very same executable fails with SSL error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt error message in the function SSL_CTX_use_PrivateKey_file(ctx, serverKey, SSL_FILETYPE_PEM) Does anybody have any experience eventually a suggestion that could lead to a solution? Thank you in advance. Regards, Z __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: buid STABLE-SNAP-20101124 on platform: VMS IA64 V8.3
Hello Richard, Richard Levitte However, resolving all those concealed devices is still a good thing, so I suggest this strategy: $ ROOT = F$PARSE(sys$disk:[-]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. - ][ - [ - ] $ ROOT = ROOT_DEV + [ + ROOT_DIR $ DEFINE/NOLOG SSLROOT 'ROOT'.APPS.] /TRANS=CONC Sounds perfect, except that you missed a nasty coma sign. The first line should look like this: $ ROOT = F$PARSE(sys$disk:[-]A.;0SYNTAX_ONLY,NO_CONCEAL) - A.;0 Richard Levitte Does this happen when you made that SSLROOT definition change given above? You see, openssl-vms.cnf defined RANDFILE on its own You are right... when the SSLROOT is well defined there is no problem with the RANDFILE during tests. Zoltan.Arpadffy ...I am dreaming of the possibility to choose between the 64 and the 32 bit version build and reuse this not-used option in MAKEVMS.COM Zoltan.Arpadffy During the summer I have submitted a patch for this feature... wonder is there any chance for this code to be merged in? Richard Levitte I recall discussing it, because it seemed to be a no-op... but I can't recall getting to an answer (and I'll admit not being a good participant in that discussion). This would be very useful as there are still users that link against 32 bit libraries for some reasons. From other side the current 64 bits build stays as a default and you would not see any difference if the 32 bit parameter is not explicitly used. I'll prepare a patch against STABLE-SNAP-20101124 and when I'm ready I'll submit it again. Thank you. Regards, Z -Original Message- From: Richard Levitte [mailto:rich...@levitte.org] Sent: den 29 november 2010 21:59 To: openssl-dev@openssl.org; Arpadffy Zoltan Subject: Re: buid STABLE-SNAP-20101124 on platform: VMS IA64 V8.3 In message fa849bbcfec13e42a34ae60ebc2d724720d4ad5...@sgmail1 on Thu, 25 Nov 2010 16:55:21 +0100, Arpadffy Zoltan zoltan.arpad...@scientificgames.se said: Zoltan.Arpadffy Solution: Zoltan.Arpadffy Zoltan.Arpadffy In tests.com replace Zoltan.Arpadffy $ sslroot = f$parse(sys$disk:[-.apps];syntax_only) - ].;+ .] Zoltan.Arpadffy $ define /translation_attributes = concealed sslroot 'sslroot' Zoltan.Arpadffy Zoltan.Arpadffy with Zoltan.Arpadffy $ ROOT = F$PARSE(__here,[]A.;0,,,SYNTAX_ONLY,NO_CONCEAL) - A.;0 Zoltan.Arpadffy $ ROOT_DEV = F$PARSE(ROOT,,,DEVICE,SYNTAX_ONLY) Zoltan.Arpadffy $ ROOT_DIR = F$PARSE(ROOT,,,DIRECTORY,SYNTAX_ONLY) - Zoltan.Arpadffy- .][00 - [00. - ][ - [ - ] - .TEST Zoltan.Arpadffy $ ROOT = ROOT_DEV + [ + ROOT_DIR Zoltan.Arpadffy $ DEFINE/NOLOG SSLROOT 'ROOT'.APPS.] /TRANS=CONC I partly agree. If you have placed the openssl source under, say, FOO:[FOSS.TEST.OPENSSL-1_0_1-DEV], it will fail. However, resolving all those concealed devices is still a good thing, so I suggest this strategy: $ ROOT = F$PARSE(sys$disk:[-]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. - ][ - [ - ] $ ROOT = ROOT_DEV + [ + ROOT_DIR $ DEFINE/NOLOG SSLROOT 'ROOT'.APPS.] /TRANS=CONC The rationale being that no subdirectory of the OpenSSL source tree will be on a different device, or at the top of any device. Zoltan.Arpadffy This is a bit more complicated, but works with complicated concealed paths as well. Yup. Zoltan.Arpadffy I noticed that Zoltan.Arpadffy --- TEST_AES Zoltan.Arpadffy ... is empty as the commented code shows: Zoltan.Arpadffy Zoltan.Arpadffy $ test_aes: Zoltan.Arpadffy $! write sys$output test AES Zoltan.Arpadffy $! !mcr 'texe_dir''aestest' Zoltan.Arpadffy Zoltan.Arpadffy ...seems there is no aestest at all. Is there any purpose that this is here? None, other than to mimic this from Makefile: test_aes: #$(AESTEST) # @echo test Rijndael # ../util/shlib_wrap.sh ./$(AESTEST) Zoltan.Arpadffy The test dies with Zoltan.Arpadffy Zoltan.Arpadffy Sign the certificate? [y/n]:2071080376:error:24064064:random number generator:SSLEAY_RAND_BYTES:PRNG not seeded:USRDSK Zoltan.Arpadffy :[ZAY.WORK.OPENSSL-101-STABLE-SNAP-20101124.CRYPTO.RAND]MD_RAND.C;1:522:You need to read the OpenSSL FAQ, http://www.o Zoltan.Arpadffy penssl.org/support/faq.html Zoltan.Arpadffy 2071080376:error:04088003:rsa routines:RSA_setup_blinding:BN lib:USRDSK:[ZAY.WORK.OPENSSL-101-STABLE-SNAP-20101124.CRY Zoltan.Arpadffy PTO.RSA]RSA_LIB.C;1:426: Zoltan.Arpadffy 2071080376:error:04066044:rsa routines:RSA_EAY_PRIVATE_ENCRYPT:internal error:USRDSK:[ZAY.WORK.OPENSSL-101-STABLE-SNAP Zoltan.Arpadffy -20101124.CRYPTO.RSA]RSA_EAY.C;1:403: Zoltan.Arpadffy 2071080376:error:0D0C3006:asn1 encoding routines:ASN1_item_sign:EVP lib:USRDSK
buid STABLE-SNAP-20101124 on platform: VMS IA64 V8.3
Hello,
I have tested the OPENSSL-1.0.1-STABLE-SNAP-20101124 on platform: VMS IA64 V8.3
Here are the results and the patches.
The build went fine except the following informational messages...
These are not VMS specific issues, but regardless good to keep in mind and fix
soon or later.
bss_dgram.c
if (timeleft.tv_sec 0)
^
%CC-I-QUESTCOMPARE, In this statement, the unsigned expression timeleft.tv_sec
is being compared with a relational operator to a constant whose value is not g
reater than zero. This might not be what you intended.
at line number 226 in file USRDSK:[ZAY.WORK.OPENSSL-101-STABLE-SNAP-20101124.CRY
PTO.BIO]BSS_DGRAM.C;1
s23_clnt.c
(p[2] = SSL3_VERSION_MINOR p[2] = TLS1_1_VERSION_MINOR)
..^
%CC-I-QUESTCOMPARE, In this statement, the unsigned expression p[2] is being c
ompared with a relational operator to a constant whose value is not greater than
zero. This might not be what you intended.
at line number 622 in file USRDSK:[ZAY.WORK.OPENSSL-101-STABLE-SNAP-20101124.SSL
]S23_CLNT.C;1
gost94_keyx
if (*outlen = 0)
^
%CC-I-QUESTCOMPARE, In this statement, the unsigned expression *outlen is bein
g compared with a relational operator to a constant whose value is not greater t
han zero. This might not be what you intended.
at line number 180 in file USRDSK:[ZAY.WORK.OPENSSL-101-STABLE-SNAP-20101124.ENG
INES.CCGOST]GOST94_KEYX.C;1
Here are the errors and the patches that needs to be applied before I reached
the:
ALL TESTS SUCCESSFUL.
OpenSSL 1.0.1-dev xx XXX
built on: 25-NOV-2010 12:23:57.59
platform: VMS IA64 V8.3
options: bn(64,64) md2(int) rc4(ptr,int) des(ptr,risc1,16,long) idea(int)
blowfish(idx)
compiler: information not available
OPENSSLDIR: N/A
The test first dies with the text below, because the sslroot is nor correctly
set:
2071080376:error:02001006:system library:fopen:no such device or address:USRDSK:
[ZAY.WORK.OPENSSL-101-STABLE-SNAP-20101124.CRYPTO.BIO]BSS_FILE.C;1:163:fopen('SS
LROOT:[00]OPENSSL-VMS.CNF','r')
2071080376:error:2006D002:BIO routines:BIO_new_file:system lib:USRDSK:[ZAY.WORK.
OPENSSL-101-STABLE-SNAP-20101124.CRYPTO.BIO]BSS_FILE.C;1:168:
2071080376:error:0E078002:configuration file routines:DEF_LOAD:system lib:USRDSK
:[ZAY.WORK.OPENSSL-101-STABLE-SNAP-20101124.CRYPTO.CONF]CONF_DEF.C;1:199:
2071080376:error:02001006:system library:fopen:no such device or address:USRDSK:
[ZAY.WORK.OPENSSL-101-STABLE-SNAP-20101124.CRYPTO.BIO]BSS_FILE.C;1:163:fopen('SS
LROOT:[00]OPENSSL-VMS.CNF','r')
2071080376:error:2006D002:BIO routines:BIO_new_file:system lib:USRDSK:[ZAY.WORK.
OPENSSL-101-STABLE-SNAP-20101124.CRYPTO.BIO]BSS_FILE.C;1:168:
2071080376:error:0E078002:configuration file routines:DEF_LOAD:system lib:USRDSK
:[ZAY.WORK.OPENSSL-101-STABLE-SNAP-20101124.CRYPTO.CONF]CONF_DEF.C;1:199:
%BACKUP-E-OPENIN, error opening USRDSK:[ZAY.WORK.OPENSSL-101-STABLE-SNAP-2010112
4.TEST]P.TXT-CLEAR;1 as input
-RMS-E-FNF, file not found
2071080376:error:02001006:system library:fopen:no such device or address:USRDSK:
[ZAY.WORK.OPENSSL-101-STABLE-SNAP-20101124.CRYPTO.BIO]BSS_FILE.C;1:163:fopen('SS
LROOT:[00]OPENSSL-VMS.CNF','r')
2071080376:error:2006D002:BIO routines:BIO_new_file:system lib:USRDSK:[ZAY.WORK.
OPENSSL-101-STABLE-SNAP-20101124.CRYPTO.BIO]BSS_FILE.C;1:168:
2071080376:error:0E078002:configuration file routines:DEF_LOAD:system lib:USRDSK
:[ZAY.WORK.OPENSSL-101-STABLE-SNAP-20101124.CRYPTO.CONF]CONF_DEF.C;1:199:
Solution:
In tests.com replace
$ sslroot = f$parse(sys$disk:[-.apps];syntax_only) - ].;+ .]
$ define /translation_attributes = concealed sslroot 'sslroot'
with
$ 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
This is a bit more complicated, but works with complicated concealed paths as
well.
I noticed that
--- TEST_AES
... is empty as the commented code shows:
$ test_aes:
$! write sys$output test AES
$! !mcr 'texe_dir''aestest'
...seems there is no aestest at all. Is there any purpose that this is here?
The test dies with
Sign the certificate? [y/n]:2071080376:error:24064064:random number
generator:SSLEAY_RAND_BYTES:PRNG not seeded:USRDSK
:[ZAY.WORK.OPENSSL-101-STABLE-SNAP-20101124.CRYPTO.RAND]MD_RAND.C;1:522:You
need to read the OpenSSL FAQ, http://www.o
penssl.org/support/faq.html
2071080376:error:04088003:rsa routines:RSA_setup_blinding:BN
lib:USRDSK:[ZAY.WORK.OPENSSL-101-STABLE-SNAP-20101124.CRY
PTO.RSA]RSA_LIB.C;1:426:
2071080376:error:04066044:rsa routines:RSA_EAY_PRIVATE_ENCRYPT:internal
error:USRDSK:[ZAY.WORK.OPENSSL-101-STABLE-SNAP
-20101124.CRYPTO.RSA]RSA_EAY.C;1:403:
RE: OpenSSL 1.0.0a-dev on VMS
Hello,
I have checked both the 1.0.0 and 0.9.8 20100414 snapshots and it look
much-much better.
Thank you very much Richard and Steven.
I got almost clean compile in both branches
On OPENSSL-098-STABLE-SNAP-20100414 got the following informational message and
a warning.
bss_dgram.c
if (timeleft.tv_sec 0)
^
%CC-I-QUESTCOMPARE, In this statement, the unsigned expression
timeleft.tv_sec is being compared with a relational op
erator to a constant whose value is not greater than zero. This might not be
what you intended.
at line number 220 in file
USRDSK:[ZAY.WORK.OPENSSL-098-STABLE-SNAP-20100414.CRYPTO.BIO]BSS_DGRAM.C;1
---
d1_both.c
item = pqueue_find(s-d1-buffered_messages, seq64be);
.^
%CC-W-CVTDIFTYPES, In this statement, seq64be of type pointer to unsigned
char, is being converted to unsigned lon
g long.
at line number 623 in file
USRDSK:[ZAY.WORK.OPENSSL-098-STABLE-SNAP-20100414.SSL]D1_BOTH.C;1
item = pitem_new(seq64be, frag);
.^
%CC-W-CVTDIFTYPES, In this statement, seq64be of type pointer to unsigned
char, is being converted to unsigned lon
g long.
at line number 679 in file
USRDSK:[ZAY.WORK.OPENSSL-098-STABLE-SNAP-20100414.SSL]D1_BOTH.C;1
%LIBRAR-W-COMCOD, compilation warnings in module D1_BOTH file
USRDSK:[ZAY.WORK.OPENSSL-098-STABLE-SNAP-20100414.IA64.OB
J.SSL]D1_BOTH.OBJ;1
-
On OPENSSL-100-STABLE-SNAP-20100414 got just the informational message. No harm
to keep it... but it improves the code if we fix it.
bss_dgram.c
if (timeleft.tv_sec 0)
^
%CC-I-QUESTCOMPARE, In this statement, the unsigned expression
timeleft.tv_sec is being compared with a relational op
erator to a constant whose value is not greater than zero. This might not be
what you intended.
at line number 226 in file
USRDSK:[ZAY.WORK.OPENSSL-100-STABLE-SNAP-20100414.CRYPTO.BIO]BSS_DGRAM.C;1
-
From other side the tests went fine as well, except that the SSLROOT
environment variable is not set correctly from the TESTS.COM causeing the
following error:
Testing key generation with NIST Binary-Curve B-571 ok
cat
2071080376:error:02001006:system library:fopen:no such device or
address:USRDSK:[ZAY.WORK.OPENSSL-100-STABLE-SNAP-20100
414.CRYPTO.BIO]BSS_FILE.C;1:126:fopen('SSLROOT:[00]openssl.cnf','r')
2071080376:error:2006D002:BIO routines:BIO_new_file:system
lib:USRDSK:[ZAY.WORK.OPENSSL-100-STABLE-SNAP-20100414.CRYPTO
.BIO]BSS_FILE.C;1:131:
2071080376:error:0E078002:configuration file routines:DEF_LOAD:system
lib:USRDSK:[ZAY.WORK.OPENSSL-100-STABLE-SNAP-2010
0414.CRYPTO.CONF]CONF_DEF.C;1:199:
2071080376:error:02001006:system library:fopen:no such device or
address:USRDSK:[ZAY.WORK.OPENSSL-100-STABLE-SNAP-20100
414.CRYPTO.BIO]BSS_FILE.C;1:126:fopen('SSLROOT:[00]openssl.cnf','r')
2071080376:error:2006D002:BIO routines:BIO_new_file:system
lib:USRDSK:[ZAY.WORK.OPENSSL-100-STABLE-SNAP-20100414.CRYPTO
.BIO]BSS_FILE.C;1:131:
2071080376:error:0E078002:configuration file routines:DEF_LOAD:system
lib:USRDSK:[ZAY.WORK.OPENSSL-100-STABLE-SNAP-2010
0414.CRYPTO.CONF]CONF_DEF.C;1:199:
%BACKUP-E-OPENIN, error opening
USRDSK:[ZAY.WORK.OPENSSL-100-STABLE-SNAP-20100414.TEST]P.TXT-CLEAR;1 as input
-RMS-E-FNF, file not found
...by using a more conventional approach SSLROOT is set correctly and ALL test
PASS happily :)
I have used the following patch in order to make it work.
TITAN2_ZAY $ diff .testtests.com;1 .testtests.com;5
File USRDSK:ZAY.WORK.OPENSSL-100-STABLE-SNAP-20100414.TESTTESTS.COM;1
15 $ sslroot = f$parse(sys$disk:[-.apps];syntax_only) -
].;+ .]
16 $ define /translation_attributes = concealed sslroot 'sslroot'
**
File USRDSK:ZAY.WORK.OPENSSL-100-STABLE-SNAP-20100414.TESTTESTS.COM;5
15 $ set default '__here'
16 $ set default [-.apps]
17 $ sslroot = f$parse( f$environment( default), , , ,
no_conceal)
18 $ sslroot = sslroot - ][ - .00 - ].; + .]
19 $ define /translation_attributes = concealed sslroot 'sslroot'
---
Unfortunately, the install (install.com) do not work at all.
The install directory structure is created, but, except for the include
directory, they are not populated.
Regards,
Z
-Original Message-
From: Dr. Stephen Henson [mailto:st...@openssl.org]
Sent: den 13 april 2010 17:03
To: openssl-dev@openssl.org
Cc: s...@antinode.info
Subject: Re: OpenSSL 1.0.0a-dev on VMS
On Tue, Apr 13, 2010, Richard Levitte wrote:
Steven,
RE: OpenSSL 1.0.0 released - VMS
Hello, I am happy that 1.0.0 is released. Thank you all for the hard work and time spent for the community. I was really hoping and looking for a VMS ready 1.0.0 release. Some of us have sent many patches, suggestions - unfortunately, not all of those changes have got through to the released code. Therefore, I sadly need to rapport the following build failures on OpenVMS (IA64) system. (see at the bottom) ... after all, I wonder has been tested this 1.0.0 release at all? Obviously, not on the OpenVMS platform - and this should be a clear responsibility of the project member who is responsible for the VMS code health. ...all patches has arrived. I understand if there is no time for merging in into some beta release... but please - this is an official release of one of the most important security related software... and it is delivered untested. I am starting to speculate that there might be some personal interest in not providing functional OpenVMS code, because I can not imagine what could stop a professional and responsible code reviewer to merge into the code a patch submitted by developers that is obviously needed to achieve proper functionality. I have written earlier also, but here it is again: I would be glad to provide any help, including coding, even donating a box running OpenVMS for the OpenSSL community, whatever else - in order to have OpenSSL code build on OpenVMS as well. Please, ensure us, all developers that this project is worth spending time and effort... and our patches will land into the code soon or later improving the stability and the functionality for everybody's benefit. ...otherwise seeing that our work is for nothing... it is not an uplifting feeling :( 1. 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.CRYPTO]CVERSION.C;1 2. - Compiling The UI Library Files. (LIBRARY,LIB) ui_err.c ui_lib.c int UI_method_set_prompt_constructor(UI_METHOD *method, char *(*prompt_constructor)(UI* ui, const char* object_desc, const char* object_name)); ^ %CC-W-LONGEXTERN, The external identifier name exceeds 31 characters; truncated to UI_METHOD_SET_PROMPT _CONSTRUCTO. at line number 313 in file USRDSK:[ZAY.WORK.OPENSSL-100.INCLUDE.OPENSSL]UI.H;2 char* (*UI_method_get_prompt_constructor(UI_METHOD *method))(UI*, const char*, const char*); ^ %CC-W-LONGEXTERN, The external identifier name exceeds 31 characters; truncated to UI_METHOD_GET_PROMPT _CONSTRUCTO. at line number 319 in file USRDSK:[ZAY.WORK.OPENSSL-100.INCLUDE.OPENSSL]UI.H;2 %LIBRAR-W-COMCOD, compilation warnings in module UI_LIB file USRDSK:[ZAY.WORK.OPENSSL-100.IA64.OBJ.CRYPT O]UI_LIB.OBJ;1 3. --- %ILINK-W-COMPWARN, compilation warnings module: UI_LIB file: USRDSK:[ZAY.WORK.OPENSSL-100.IA64.EXE.CRYPTO]LIBCRYPTO.OLB;1 %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.IA64.OBJ.APPS]SPEED.OBJ;1 %ILINK-W-USEUNDEF, undefined symbol SSLEAY_VERSION referenced section: $CODE$ offset: %X000117A0 slot: 2 module: SPEED file: USRDSK:[ZAY.WORK.OPENSSL-100.IA64.OBJ.APPS]SPEED.OBJ;1 %ILINK-W-USEUNDEF, undefined symbol SSLEAY_VERSION referenced section: $CODE$ offset: %X00011A50 slot: 2 module: SPEED file: USRDSK:[ZAY.WORK.OPENSSL-100.IA64.OBJ.APPS]SPEED.OBJ;1 %ILINK-W-USEUNDEF, undefined symbol SSLEAY referenced section: $CODE$ offset: %X03F0 slot: 2 module: VERSION file: USRDSK:[ZAY.WORK.OPENSSL-100.IA64.OBJ.APPS]VERSION.OBJ;1 %ILINK-W-USEUNDEF, undefined symbol SSLEAY_VERSION referenced section: $CODE$ offset: %X0410 slot: 2 module: VERSION file: USRDSK:[ZAY.WORK.OPENSSL-100.IA64.OBJ.APPS]VERSION.OBJ;1 %ILINK-W-USEUNDEF, undefined symbol SSLEAY_VERSION referenced section: $CODE$ offset: %X0460 slot: 2 module: VERSION file: USRDSK:[ZAY.WORK.OPENSSL-100.IA64.OBJ.APPS]VERSION.OBJ;1 Regards, Z -Original Message- From: OpenSSL [mailto:open...@openssl.org] Sent: den 29 mars 2010 16:52 To: openssl-dev@openssl.org; openssl-us...@openssl.org; openssl-annou...@openssl.org Subject: OpenSSL 1.0.0 released -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL version 1.0.0 released == __ OpenSSL Project
RE: OpenSSL 0.9.8n v. VMS
Hello, I just simply can not believe, that in an open source project, vital, port related changes needs to be submitted so many times... and nothing happens. I suggest taking Steven M. Schweda into the OpenSSL project team with shared OpenVMS responsibility (and commit rights) beside Richard Levitte. Thank you. Regards, Z -Original Message- From: Steven M. Schweda [mailto:s...@antinode.info] Sent: den 24 mars 2010 17:35 To: openssl-dev@openssl.org Subject: OpenSSL 0.9.8n v. VMS An OpenSSL 0.9.8n kit which appears to work on VMS should be available at: http://antinode.info/ftp/openssl/0_9_8n/openssl-0_9_8n_s1.zip The suggested changes are the same as for 0.9.8m: http://antinode.info/ftp/openssl/0_9_8m/ Not amazingly, old complaints/questions persist: As previously explained, I claim that some of these changes are closer to minimal than to optimal: crypto/o_init.c: Loose extern declarations, instead of a header file. makevms.com: Still overwrites a symlink, apps/md4.c, with crypto/md4/md4.c. (Who uses/needs apps/md4.c?) util/libeay.num: Excludes pqueue_print() on VAX, instead of providing working 32-bit code (crypto/pqueue/pqueue.c). 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
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
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 s...@antinode.info said: sms From: Richard Levitte rich...@levitte.org 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 s...@antinode.info said: sms From: Richard Levitte rich...@levitte.org 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
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 rich...@levitte.org 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
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 zoltan.arpad...@scientificgames.se 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
Thank you Richard, I'm am testing openssl-1.0.0-stable-SNAP-20100127.tar.gz 3.8 MB 27/01/2010 06:15:00 It builds correctly. During tests I go the following errors: 1. SSLROOT is not defined correctly in .testtests.com sslroot definition is replaced $ 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. could not pass through this point... I have seen that earlier as well, but now it can not find the seed file at all in the current directory. 2071080376:error:24064064:random number generator:SSLEAY_RAND_BYTES:PRNG not seeded:USRDSK:[ZA Y.WORK.OPENSSL-100-STABLE-SNAP-20100127.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-20100127.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 00127.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-20100127. CRYPTO.ASN1]A_SIGN.C;1:279: Do you have any idea what to do? In fact there still exists all issues that I have sent in Monday 2010-01-25 19:59 3. Manually started JPAKETEST fails!!! TITAN2_ZAY $ mc USRDSK:ZAY.WORK.OPENSSL-100-STABLE-SNAP-20100125.IA64.EXE.TESTJPAKETES T.EXE p = F9E5B365665EA7A05A9C534502780FEE6F1AB5BD4F49947FD036DBD7E905269AF46EF28B 0FC07487EE4F5D20FB3C0AF8E700F3A2FA3414970CBED4 4FEDFF80CE78D800F184BB82435D137AADA2C6C16523247930A63B85661D1FC817A51ACD 96168E95898A1F83A79FFB529368AA7833ABD1B0C3AEDDB14D 2E1A2F71D99F763F g = 2 q = 7CF2D9B2B32F53D02D4E29A2813C07F7378D5ADEA7A4CA3FE81B6DEBF482934D7A377945 87E03A43F727AE907D9E057C738079D17D1A0A4B865F6A 27F6FFC0673C6C0078C25DC121AE89BD56D16360B291923C98531DC2B30E8FE40BD28D66 CB0B474AC4C50FC1D3CFFDA949B4553C19D5E8D861D76ED8A6 970D17B8ECCFBB1F A-B s1 B-A s1 A-B s2 B-A s2 Alice's key = 3722C81D780857B4AAE63D109950698938A846C11E616ED29419A986C6D813E35F6969F9 B2C70DD399437978DEAE71606425ADF08D7D 3459B0D8EB19B21D732A038A478B0BAF7A818E5266D75A1097D3F43384D6A9F2DD774AB6 7D282DF907DD2519F2A5185792DAE8C742BD4D4E91340DDBB0 8956856284831D9E3C475BF150 Bob's key = 3722C81D780857B4AAE63D109950698938A846C11E616ED29419A986C6D813E35F6969F9 B2C70DD399437978DEAE71606425ADF08D7D 3459B0D8EB19B21D732A038A478B0BAF7A818E5266D75A1097D3F43384D6A9F2DD774AB6 7D282DF907DD2519F2A5185792DAE8C742BD4D4E91340DDBB0 8956856284831D9E3C475BF150 A-B s3a B-A s3b A-B s1 B-A s1 A-B s2 B-A s2 Alice's key = A7F469FF38ED3BA3225E1B05A8B44F3643A9128E4E0D2E225744CD58DE55C5D02276E401 1B27A91AEEF3AE6B43D827CC61E6D2E933A5 E8C0601A0E25B434402F8AB9C04855F06794436D592FBE922ED027A37B285207C30F63A2 5115433DA1F8499CB8B5A09D945981489C18CED798944B873E 37DA5200793F2F5283A3BA2704 Bob's key = F2FFD37A8934C66480E43F126DC9EB79CBD4F82ACC0686434407A83AFCCC467FDDD50B5C 5DCE74CCE490027033E411701F80C62DE0F9 BFC1611DBD2F1249C3ACC13E724AFBFC10120F57DC304DD6EF7A972DBA33C5008776486A CAF4A0EE5AB2958E8585A0A94BF7E77805DED664956532DBDC 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.ARCH]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
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 zoltan.arpad...@scientificgames.se 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
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 .testtests.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:ZAY.WORK.OPENSSL-100-STABLE-SNAP-20100125.IA64.EXE.TESTJPAKETEST.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.ARCH]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 at upcoming snapshots. I've applied
the recent changes suggest by Steven M. Schweda s...@antinode.info
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
RE: OpenSSL 1.0.0 beta5 release v. VMS
Hello, I have applied the following changes: TITAN2_ZAY $ diff .cryptosymhacks.h File USRDSK:ZAY.WORK.OPENSSL-100-BETA5.CRYPTOSYMHACKS.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:ZAY.WORK.OPENSSL-100-BETA5.CRYPTOSYMHACKS.H;1 179 Number of difference sections found: 1 Number of difference records found: 8 TITAN2_ZAY $ diff .utillibeay.num File USRDSK:ZAY.WORK.OPENSSL-100-BETA5.UTILLIBEAY.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:ZAY.WORK.OPENSSL-100-BETA5.UTILLIBEAY.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, ^
RE: OpenSSL 1.0.0 beta4 release
Hello Richard, I have tested the OPENSSL-100-STABLE-SNAP-20091116 and it looks much better. Thank you for the merge. I have two small remarks: 1. I'm still missing the pointer size choice. I think that it is wise to give the possibility to choose between 64 and 32 bit pointer size build. 2. Meanwhile the new development introduced four new functions that are longer than 32 chars. K-W-NUDFSYMS, 4 undefined symbols: %ILINK-I-UDFSYM,SSL_ADD_CLIENTHELLO_RENEGOTIATE %ILINK-I-UDFSYM,SSL_ADD_SERVERHELLO_RENEGOTIATE %ILINK-I-UDFSYM,SSL_PARSE_CLIENTHELLO_RENEGOTIA %ILINK-I-UDFSYM,SSL_PARSE_SERVERHELLO_RENEGOTIA Is there any possibility to handle these long function names issue automatically... with some coding rules or with merging trigger, that would solve automatically those VMS issues. Honestly, having that long function names is more sign of ignorance, than structure and good coding practice. Thank you. Regards, Z -Original Message- From: Richard Levitte [mailto:rich...@levitte.org] Sent: den 13 november 2009 09:44 To: openssl-dev@openssl.org; Arpadffy Zoltan Subject: Re: OpenSSL 1.0.0 beta4 release In message 839c820b5c926b4b89713b3a6ed68d2aae5...@sgstmail.scigames.at on Fri, 13 Nov 2009 09:14:07 +0100, Arpadffy Zoltan zoltan.arpad...@scientificgames.se said: Zoltan.Arpadffy ... my only wish is to get a clean build on OpenVMS Zoltan.Arpadffy when I download the code next time. That's what we all want in the end... Can I suggest you have a look at today's snapshot (that goes for Stephen as well) and go from there? -- 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.org #2099] [PATCH] OpenSSL 1.0.0 beta4 release (OpenVMS)
Hello, Can you (and others in this thread) please submit bug fix patches to the request tracker (r...@openssl.org) so they don't get overlooked?? Please note this is the official submit to RT (mail already submitted to the list) Additionally to SMS's changes (below)... here are the changes that are needed to be added in order to get OpenVMS build correctly. The only extra improvement is that I used the unused second variable to configure the pointer size (32 or 64). TODO: The CA.COM is not usable as it is therefore both tests: TESTCA.COM and TESTTSA.COM fail. Regards, Z TOR_ZAY $ gdiff -p DSA104:USERS.ZAY.WORK.OPENSSL-100-BETA4-ORIGMAKEVMS.COM DSA104:USERS.ZAY.WORK.OPENSSL-100-BETA4MAKEVMS.COM *** dsa104:users.zay.work.openssl-100-beta4-origmakevms.com Tue Aug 25 09:30:02 2009 --- dsa104:users.zay.work.openssl-100-beta4makevms.comThu Nov 12 11:01:00 2009 *** $! End *** 347,356 $! $ ENDIF $! - $! There are many places where this is needed. - $! - $ WRITE H_FILE #define _XOPEN_SOURCE_EXTENDED - $! $! Close the [.CRYPTO.ARCH]OPENSSLCONF.H file $! $ CLOSE H_FILE --- 347,352 *** $ TIME = F$TIME() *** 386,392 $! $! Write The [.CRYPTO.ARCH]BUILDINF.H File. $! ! $ WRITE H_FILE #define CFLAGS /* Not filled in for now */ $ WRITE H_FILE #define PLATFORM VMS ''ARCH' ''VMS_VER' $ WRITE H_FILE #define DATE ''TIME' $! --- 382,388 $! $! Write The [.CRYPTO.ARCH]BUILDINF.H File. $! ! $ WRITE H_FILE #define CFLAGS /pointer_size=''POINTER_SIZE'/float=g /* compiler flags */ $ WRITE H_FILE #define PLATFORM VMS ''ARCH' ''VMS_VER' $ WRITE H_FILE #define DATE ''TIME' $! *** $! Tell The User We Are Partly Rebuildin *** 410,416 $! $ WRITE SYS$OUTPUT Rebuilding The '[.APPS]MD4.C', '[.APPS]MD5.C' And '[.APPS]RMD160.C' Files. $! ! $ DELETE SYS$DISK:[.APPS]MD4.C;*,MD5.C;*,RMD160.C;* $! $! Copy MD4.C from [.CRYPTO.MD4] into [.APPS] $! --- 406,412 $! $ WRITE SYS$OUTPUT Rebuilding The '[.APPS]MD4.C', '[.APPS]MD5.C' And '[.APPS]RMD160.C' Files. $! ! $ DELETE /NOLOG SYS$DISK:[.APPS]MD4.C;*,MD5.C;*,RMD160.C;* $! $! Copy MD4.C from [.CRYPTO.MD4] into [.APPS] $! *** $! *** 431,438 $! First, We Have To Rebuild The [.TEST] Directory, So Delete $! All The C Files That Are Currently There Now. $! ! $ DELETE SYS$DISK:[.TEST]*.C;* ! $ DELETE SYS$DISK:[.TEST]EVPTESTS.TXT;* $! $! Copy all the *TEST.C files from [.CRYPTO...] into [.TEST] $! --- 427,434 $! First, We Have To Rebuild The [.TEST] Directory, So Delete $! All The C Files That Are Currently There Now. $! ! $ DELETE /NOLOG SYS$DISK:[.TEST]*.C;* ! $ DELETE /NOLOG SYS$DISK:[.TEST]EVPTESTS.TXT;* $! $! Copy all the *TEST.C files from [.CRYPTO...] into [.TEST] $! *** $! *** 755,761 $!Tell The User We Don't Know What They Want. $! $ WRITE SYS$OUTPUT ! $ WRITE SYS$OUTPUT USAGE: @MAKEVMS.COM [Target] [not-used option] [Debug option] Compiler $ WRITE SYS$OUTPUT $ WRITE SYS$OUTPUT Example: @MAKEVMS.COM ALL NORSAREF NODEBUG $ WRITE SYS$OUTPUT --- 751,757 $!Tell The User We Don't Know What They Want. $! $ WRITE SYS$OUTPUT ! $ WRITE SYS$OUTPUT USAGE: @MAKEVMS.COM [Target] [Pointer size] [Debug option] Compiler $ WRITE SYS$OUTPUT $ WRITE SYS$OUTPUT Example: @MAKEVMS.COM ALL NORSAREF NODEBUG $ WRITE SYS$OUTPUT *** $! End The P1 Check. *** 794,799 --- 790,825 $! $ ENDIF $! + $! 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 Arguement Check. + $! + $ ENDIF + $ ENDIF + $! End The P2 Check. + $! $! Check To See If P3 Is Blank. $! $ IF (P3.EQS.NODEBUG) TOR_ZAY $ gdiff -p DSA104:USERS.ZAY.WORK.OPENSSL-100-BETA4-ORIG.crypto.pqueuepqueue.h DSA104:USERS.ZAY.WORK.OPENSSL-100-BETA4.CRYPTO.PQUEUEPQUEUE.H *** dsa104:users.zay.work.openssl-100-beta4-orig.crypto.pqueuepqueue.h Sat May 16 18:17:46 2009 --- dsa104:users.zay.work.openssl-100-beta4.crypto.pqueuepqueue.h Thu Nov 12 10:12:12 2009 *** *** 64,69 --- 64,74 #include stdlib.h #include string.h + #ifdef OPENSSL_SYS_VMS + #include resource.h + #include sys/timeb.h + #endif + typedef struct _pqueue *pqueue; typedef struct _pitem TOR_ZAY $ gdiff -p DSA104:USERS.ZAY.WORK.OPENSSL-100-BETA4-ORIG.appss_socket.c
RE: OpenSSL 1.0.0 beta4 release
Hello, I use the following compilers: HP C V7.2-001 on OpenVMS IA64 V8.3 Compaq C V6.4-008 on OpenVMS Alpha V7.3-2 These were the changes that I applied - and rewarded me with clean compile and usable libraries. For sure you know better the code... and there might be better solutions. Please, include what you feel that is right. ... my only wish is to get a clean build on OpenVMS when I download the code next time. Thank you Richard. Regards, Z -Original Message- From: Richard Levitte [mailto:rich...@levitte.org] Sent: den 12 november 2009 22:56 To: openssl-dev@openssl.org; Arpadffy Zoltan Subject: Re: OpenSSL 1.0.0 beta4 release In message 839c820b5c926b4b89713b3a6ed68d2aae5...@sgstmail.scigames.at on Thu, 12 Nov 2009 16:26:57 +0100, Arpadffy Zoltan zoltan.arpad...@scientificgames.se said: Zoltan.Arpadffy Hello, Zoltan.Arpadffy Zoltan.Arpadffy Additionally to SMS's changes... here are the changes that are needed to Zoltan.Arpadffy be added in order to get OpenVMS build correctly. Okay, since I'm obviously in an interactive mood (and it's been requested anyway ;-)), there are a couple of your patches that I don't understand: Zoltan.Arpadffy TOR_ZAY $ gdiff -p Zoltan.Arpadffy DSA104:USERS.ZAY.WORK.OPENSSL-100-BETA4-ORIG.crypto.pqueuepqueue.h Zoltan.Arpadffy DSA104:USERS.ZAY.WORK.OPENSSL-100-BETA4.CRYPTO.PQUEUEPQUEUE.H Zoltan.Arpadffy Zoltan.Arpadffy *** dsa104:users.zay.work.openssl-100-beta4-orig.crypto.pqueuepqueue.h Sat May 16 18:17:46 2009 Zoltan.Arpadffy --- dsa104:users.zay.work.openssl-100-beta4.crypto.pqueuepqueue.h Thu Nov 12 10:12:12 2009 Zoltan.Arpadffy *** Zoltan.Arpadffy *** 64,69 Zoltan.Arpadffy --- 64,74 Zoltan.Arpadffy #include stdlib.h Zoltan.Arpadffy #include string.h Zoltan.Arpadffy Zoltan.Arpadffy + #ifdef OPENSSL_SYS_VMS Zoltan.Arpadffy + #include resource.h Zoltan.Arpadffy + #include sys/timeb.h Zoltan.Arpadffy + #endif Zoltan.Arpadffy + Zoltan.Arpadffy typedef struct _pqueue *pqueue; Zoltan.Arpadffy Zoltan.Arpadffy typedef struct _pitem Why? I see nothing in that header file that would need anything from resource.h or sys/timeb.h... is it really something needed in one of the .c files? Then I think it's better to change there. Zoltan.Arpadffy TOR_ZAY $ gdiff -p Zoltan.Arpadffy DSA104:USERS.ZAY.WORK.OPENSSL-100-BETA4-ORIG.appss_socket.c Zoltan.Arpadffy DSA104:USERS.ZAY.WORK.OPENSSL-100-BETA4.appss_socket.c Zoltan.Arpadffy *** dsa104:users.zay.work.openssl-100-beta4-orig.appss_socket.c Wed Aug 26 13:21:50 2009 Zoltan.Arpadffy --- dsa104:users.zay.work.openssl-100-beta4.appss_socket.cThu Nov 12 10:47:18 2009 Zoltan.Arpadffy *** Zoltan.Arpadffy *** 72,78 Zoltan.Arpadffy recursive header file inclusion, resulting in the compiler complaining Zoltan.Arpadffy that u_int isn't defined, but only if _POSIX_C_SOURCE is defined, which Zoltan.Arpadffy is needed to have fileno() declared correctly... So let's define u_int */ Zoltan.Arpadffy ! #if defined(OPENSSL_SYS_VMS_DECC) !defined(__U_INT) Zoltan.Arpadffy #define __U_INT Zoltan.Arpadffy typedef unsigned int u_int; Zoltan.Arpadffy #endif Zoltan.Arpadffy --- 72,78 Zoltan.Arpadffy recursive header file inclusion, resulting in the compiler complaining Zoltan.Arpadffy that u_int isn't defined, but only if _POSIX_C_SOURCE is defined, which Zoltan.Arpadffy is needed to have fileno() declared correctly... So let's define u_int */ Zoltan.Arpadffy ! #if (defined(VMS) || defined(__VMS)) !defined(__U_INT) Zoltan.Arpadffy #define __U_INT Zoltan.Arpadffy typedef unsigned int u_int; Zoltan.Arpadffy #endif Why? it includes e_os2.h, which defines OPENSSL_SYS_VMS_DECC if DEC C (Compaq C? HP C?) is used. Does this mean the definitions in e_os2.h need to be updated? Zoltan.Arpadffy TOR_ZAY $ gdiff -p Zoltan.Arpadffy DSA104:USERS.ZAY.WORK.OPENSSL-100-BETA4-ORIG.appss_server.c Zoltan.Arpadffy DSA104:USERS.ZAY.WORK.OPENSSL-100-BETA4.appss_server.c Zoltan.Arpadffy *** dsa104:users.zay.work.openssl-100-beta4-orig.appss_server.c Wed Oct 28 18:49:38 2009 Zoltan.Arpadffy --- dsa104:users.zay.work.openssl-100-beta4.appss_server.cThu Nov 12 10:47:57 2009 Zoltan.Arpadffy *** Zoltan.Arpadffy *** 165,171 Zoltan.Arpadffy recursive header file inclusion, resulting in the compiler complaining Zoltan.Arpadffy that u_int isn't defined, but only if _POSIX_C_SOURCE is defined, which Zoltan.Arpadffy is needed to have fileno() declared correctly... So let's define u_int */ Zoltan.Arpadffy ! #if defined(OPENSSL_SYS_VMS_DECC) !defined(__U_INT) Zoltan.Arpadffy #define __U_INT Zoltan.Arpadffy typedef unsigned int u_int; Zoltan.Arpadffy #endif Zoltan.Arpadffy --- 165,171 Zoltan.Arpadffy recursive header file inclusion, resulting in the compiler complaining Zoltan.Arpadffy that u_int isn't defined, but only if _POSIX_C_SOURCE is defined, which Zoltan.Arpadffy is needed to have
RE: OpenSSL 1.0.0 beta4 release
Hello, I have already made the correction off all remaining issues... 32/64 bit pointer size handling. I still have some minor issues around tests.com... but in about an hour I will be able to submit a patch. Regards, Z -Original Message- From: Richard Levitte [mailto:rich...@levitte.org] Sent: den 12 november 2009 15:07 To: openssl-dev@openssl.org; s...@antinode.info Subject: Re: OpenSSL 1.0.0 beta4 release I just committed the suggested changes. I try to find the time checking the problems with the tests within the next few days. Cheers, Richard In message 0915433492_20202...@antinode.info on Wed, 11 Nov 2009 15:43:34 -0600 (CST), Steven M. Schweda s...@antinode.info said: sms From: open...@master.openssl.org (OpenSSL) sms smsOpenSSL version 1.0.0 Beta 4 sms [...] smsSince the third beta, the following has happened: sms [...] sms - Build system fixes including VMS. sms [...] sms smsNot entirely successful. Around here: sms sms ALP $ cc /version sms HP C V7.3-009 on OpenVMS Alpha V8.3 sms sms I tried: sms @ makevms.com ALL NODEBUG DECC TCPIP sms @ [.test]tests.com sms sms sms ALP $ gdiff -u makevms.com_orig makevms.com sms --- makevms.com_orig2009-08-25 02:30:02 -0500 sms +++ makevms.com 2009-11-11 13:21:47 -0600 sms @@ -349,7 +349,7 @@ sms $! sms $! There are many places where this is needed. sms $! sms -$ WRITE H_FILE #define _XOPEN_SOURCE_EXTENDED sms +$!!! WRITE H_FILE #define _XOPEN_SOURCE_EXTENDED sms $! sms $! Close the [.CRYPTO.ARCH]OPENSSLCONF.H file sms $! sms smsWhat, too many things were working correctly? This _seriously_ sms breaks the build. Why was this added? is needed is not a helpful sms explanation. sms sms sms --- apps/install.com_orig 2009-05-15 11:37:04 -0500 sms +++ apps/install.com 2009-11-11 14:16:15 -0600 sms @@ -57,7 +57,7 @@ sms $ sms $ SET NOON sms $ COPY CA.COM WRK_SSLEXE:CA.COM/LOG sms -$ SET FILE/PROT=W:RE WRK_SSLVEXE:CA.COM sms +$ SET FILE/PROT=W:RE WRK_SSLEXE:CA.COM sms $ COPY OPENSSL-VMS.CNF WRK_SSLROOT:[00]OPENSSL.CNF/LOG sms $ SET FILE/PROT=W:R WRK_SSLROOT:[00]OPENSSL.CNF sms $ SET ON sms smsBeside being simpler and perhaps a bit faster, using COPY /PROTECTION sms instead of separate COPY and SET FILE /PROTECTION commands (as sms previously suggested) would halve the opportunities for careless errors sms of this type. sms sms sms --- crypto/crypto-lib.com_orig 2009-08-25 02:22:08 -0500 sms +++ crypto/crypto-lib.com 2009-11-11 10:48:40 -0600 sms @@ -193,7 +193,8 @@ sms $ LIB_SEED = seed,seed_ecb,seed_cbc,seed_cfb,seed_ofb sms $ LIB_MODES = cbc128,ctr128,cfb128,ofb128 sms $ LIB_BN_ASM = [.asm]vms.mar,vms-helper sms -$ IF F$TRNLNM(OPENSSL_NO_ASM) THEN LIB_BN_ASM = bn_asm sms +$ IF F$TRNLNM(OPENSSL_NO_ASM) .OR. ARCH .NES. VAX THEN - sms + LIB_BN_ASM = bn_asm sms $ LIB_BN = bn_add,bn_div,bn_exp,bn_lib,bn_ctx,bn_mul,bn_mod,+ - smsbn_print,bn_rand,bn_shift,bn_word,bn_blind,+ - smsbn_kron,bn_sqrt,bn_gcd,bn_prime,bn_err,bn_sqr,+LIB_BN_ASM+,+ - sms smsEven if MACRO32 code were faster on an Alpha, the MACRO32 compiler sms there won't compile vms.mar. sms sms sms --- crypto/symhacks.h_orig 2009-05-15 11:00:08 -0500 sms +++ crypto/symhacks.h 2009-11-11 10:56:52 -0600 sms @@ -138,6 +138,8 @@ sms #define X509_policy_node_get0_qualifiers X509_pcy_node_get0_qualifiers sms #undef X509_STORE_CTX_get_explicit_policy sms #define X509_STORE_CTX_get_explicit_policy X509_STORE_CTX_get_expl_policy sms +#undef X509_STORE_CTX_get0_current_issuer sms +#define X509_STORE_CTX_get0_current_issuer X509_STORE_CTX_get0_current_iss sms sms /* Hack some long CRYPTO names */ sms #undef CRYPTO_set_dynlock_destroy_callback sms smsYet another %CC-W-LONGEXTERN complaint. sms sms sms --- util/libeay.num_orig 2009-11-04 07:29:58 -0600 sms +++ util/libeay.num2009-11-11 14:00:31 -0600 sms @@ -4168,4 +4168,5 @@ sms X509_STORE_set_verify_cb4543 EXIST::FUNCTION: sms X509_STORE_CTX_get0_current_crl 4544 EXIST::FUNCTION: sms X509_STORE_CTX_get0_parent_ctx 4545 EXIST::FUNCTION: sms -X509_STORE_CTX_get0_current_issuer 4546 EXIST::FUNCTION: sms +X509_STORE_CTX_get0_current_issuer 4546 EXIST:!VMS:FUNCTION: sms +X509_STORE_CTX_get0_current_iss 4546 EXIST:VMS:FUNCTION: sms smsSee crypto/symhacks.h. sms sms smstest/testenc.com seems to fail. SSLROOT not defined? (If you sms thought that it worked, what were you testing?) Apparently, sms test/tests.com exits on error, so no test results after that. sms sms smsAre there any plans to get this stuff to work properly before the sms actual release? The beta kits so far have not been encouraging. I've sms given up on seeing several previously suggested changed adopted, but it sms would be nice if, for example, a simple build simply worked. sms sms
RE: [PATCH] OpenSSL 1.0.0 beta3 release v. VMS
Hello, It has passed few months and it is getting closer to the official release of v1.0.0. I have recently checked out the source from the CVS and tested the VMS build and in order to finalize issues from my TODO lis: - add support for building 32 and 64 bits libraries - testca and testtsa fails (can not find .rnd file) Unfortunately, the build failed. Wonder: 1. is it right assumption that the last cvs checkout should contain all recent patches, changes for 1.0.0? 2. Have all VMS related changes that I have sent been merged into the code? (1.0.0beta3 builds nice with my patches on VMS) 3. How should we proceed? Should I send a new patch that corrects VMS build against latest code from the cvs? I would like to see openssl building correctly on OpenVMS before 1.0.0 is released. Hope that this is a common goal. Thank you in advance. Regards, Z -Original Message- From: Richard Levitte [mailto:rich...@levitte.org] Sent: den 25 augusti 2009 10:09 To: openssl-dev@openssl.org; Arpadffy Zoltan Subject: Re: [PATCH] OpenSSL 1.0.0 beta3 release v. VMS In message 839c820b5c926b4b89713b3a6ed68d2aae4...@sgstmail.scigames.at on Fri, 21 Aug 2009 17:36:08 +0200, Arpadffy Zoltan zoltan.arpad...@scientificgames.se said: Zoltan.Arpadffy Zoltan.Arpadffy Zoltan.Arpadffy Hello Richard, Zoltan.Arpadffy Zoltan.Arpadffy If those who do commit to the repository, I believe I'm the only one Zoltan.Arpadffy dealing with the VMS parts of the kit... Zoltan.Arpadffy Zoltan.Arpadffy I tested OPENSSL-VMS_64BIT-SNAP-20090821 as I was expecting that my Zoltan.Arpadffy changes would be there. Zoltan.Arpadffy I was wrong :( Yes. I'm committing your changes (as well as sms') directly to the 1.0.0 branch as well as the 0.9.8 branch. 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: [PATCH] OpenSSL 1.0.0 beta3 release v. VMS
Hello Richard, If those who do commit to the repository, I believe I'm the only one dealing with the VMS parts of the kit... I tested OPENSSL-VMS_64BIT-SNAP-20090821 as I was expecting that my changes would be there. I was wrong :( I wonder, where do you apply the patches and patch suggestions? Is there any source snapshot that is possible to test? Thank you. Have a nice weekend. Regards, Z __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [PATCH] OpenSSL 1.0.0 beta3 release v. VMS
Hello, I haven't had a VAX account for a long time... someone give me one and I'll play... You can create your own account at http://www.polarhome.com/service/shell/ ... and just drop me a mail informing me what is you username. Regards, Z __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [PATCH] OpenSSL 1.0.0 beta3 release v. VMS
Hello, Copied files? What's copied? In makevms.com ALL target will do a SOFTLINKS by the way, that will do a lot of coping around. I agree that with the right /INCLUDE parameter it would be more appropriate to build. I'll add this as well to my TODO list. - test with other compilers than DECC Who uses anything else? The build scripts are prepared for VAXC and for GCC as well. I share your opinion that these compilers are not used that often nowadays... but on old vaxes VAXC still rules and GCC might get a wing in the future. It is worth testing at all, unfortunately I do not have environment for that. OPTIONAL TODO - in order to make life more compatible we could use the same logicals like HP's SSL product - I mean SSL$ROOT instead of SSLROOT If there _is_ a good reason to make a change like this, please explain why In the past almost 10 years nobody used any other SSL on OpenVMS but HP's. I know that it is utopist thought - but I would prefer to have one SSL library on OpenVMS - even better it that would be supported by HP itself. It is rather easy to make few steps towards HP's SSL build that might motivate and encourage HP to send back their changes to the openssl community. Like this the whole OpenVMS community would benefit... as well as HP's supported SSL product build would be trivial and reduce to regression tests and repackaging. I am an optimist and unitarist who still believe in tolerance and free will's good choices. Regards, Z -Original Message- From: Steven M. Schweda [mailto:s...@antinode.info] Sent: den 15 augusti 2009 18:39 To: openssl-dev@openssl.org Subject: Re: [PATCH] OpenSSL 1.0.0 beta3 release v. VMS From: Arpadffy Zoltan zoltan.arpad...@scientificgames.se This patch corrects build on OpenVMS systems. I haven't looked at it yet, but ... As VMS does not have a make clean function yet, it was hard to separate the really modified files from the copied (poor symlink imitation on VMS) etc. Copied files? What's copied? I thought that I had eliminated all the file copying (and the need for any symlinks). TODO: [...] - test with other compilers than DECC Who uses anything else? OPTIONAL TODO - in order to make life more compatible we could use the same logicals like HP's SSL product - I mean SSL$ROOT instead of SSLROOT I changed the library names from xxx to SSL_xxx to look more like HP's SSL$xxx (and so I could find them), but I don't see a good reason to go further than that. I believe that many people and procedures use these SSL* logical names to determine which SSL package is being used. Making everything look exactly the same would seem likely to cause more trouble than leaving them different. If there _is_ a good reason to make a change like this, please explain why, how, and so on, and why it wouldn't break a lot of existing stuff. 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: [PATCH] OpenSSL 1.0.0 beta3 release v. VMS
Hello, No. OK. ...seems SMS is also against... and I am keen to bow in front of democracy :) Regards, Z -Original Message- From: Richard Levitte [mailto:rich...@levitte.org] Sent: den 17 augusti 2009 10:37 To: openssl-dev@openssl.org; Arpadffy Zoltan Subject: Re: [PATCH] OpenSSL 1.0.0 beta3 release v. VMS In message 839c820b5c926b4b89713b3a6ed68d2aae4...@sgstmail.scigames.at on Fri, 14 Aug 2009 19:15:12 +0200, Arpadffy Zoltan zoltan.arpad...@scientificgames.se said: Zoltan.Arpadffy OPTIONAL TODO Zoltan.Arpadffy - in order to make life more compatible we could use the same logicals Zoltan.Arpadffy like HP's SSL product - I mean SSL$ROOT instead of SSLROOT No. $ in logical names and such are not recommended outside of DEC/Compaq/HP, they have reserved that character for their own use for ages. Also, if we use the same and we ave a versioning conflict between the products, there will be trouble. And I really see no reason why two products, even though one is based on the other, should compete over logical names. 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: [PATCH] OpenSSL 1.0.0 beta3 release v. VMS
Hello, You are right... There were lot of try and fail play around the headers and I wanted to submit the patch before the sunset - therefore I haven't checked it over. 1. _XOPEN_SOURCE_EXTENDED issue. Yes, it would be good to have it defined for all VMS systems, but the main reason was the struct timeval that is in the time.h ... depending on that define. But I have found resource.h an include file made to solve issues around this. 2. It is a copy paste mistake, because of the reason explained above :( Part: + #if defined(OPENSSL_SYS_WIN32) || defined(OPENSSL_SYS_VMS) + #include sys/timeb.h + #endif Should not be there - please ignore it. Regards, Z -Original Message- From: Richard Levitte [mailto:rich...@levitte.org] Sent: den 17 augusti 2009 11:10 To: openssl-dev@openssl.org; Arpadffy Zoltan Subject: Re: [PATCH] OpenSSL 1.0.0 beta3 release v. VMS In message 839c820b5c926b4b89713b3a6ed68d2aae4...@sgstmail.scigames.at on Fri, 14 Aug 2009 19:15:12 +0200, Arpadffy Zoltan zoltan.arpad...@scientificgames.se said: Zoltan.Arpadffy Mandatory information: Zoltan.Arpadffy Request type: PATCH Zoltan.Arpadffy OS and arch: OpenVMS ALPHA, IA64 Zoltan.Arpadffy OpenSSL version: 1.0.0 beta 3 I've looked through it, and applied almost all of it. There are just two things I wonder about, and haven't applied yet: In makevms.com: *** $! *** 342,347 --- 343,349 $ WRITE H_FILE #undef OPENSSL_EXPORT_VAR_AS_FUNCTION $ WRITE H_FILE #define OPENSSL_EXPORT_VAR_AS_FUNCTION $! + $ WRITE H_FILE #define _XOPEN_SOURCE_EXTENDED $! End $! $ ENDIF This would only define that logical for VAX. Is it really not needed for Alpha and ia64? Please understand me, adding that logical there is probably a very good idea... I've been conservative and only added it on file-per-file basis, and that's probably not the wisest. *** openssl-100-beta3/SSL/DTLS1.H Wed Jun 17 13:38:26 2009 --- openssl-100-beta3-work/SSL/DTLS1.H Fri Aug 14 09:40:39 2009 *** *** 62,67 --- 62,74 #include openssl/buffer.h #include openssl/pqueue.h + #if defined(OPENSSL_SYS_WIN32) || defined(OPENSSL_SYS_VMS) + #include sys/timeb.h + #endif + #ifdef OPENSSL_SYS_VMS + #include resource.h + #include sys/timeb.h + #endif #ifdef OPENSSL_SYS_WIN32 /* Needed for struct timeval */ #include winsock.h This seems odd to me. Or rather, the first added conditional. I doubt Win32 needs sys/timeb.h, as it uses a different mechanism (as far as I understand, I'm not the Windows hacker here ;-)), and it seems redundant to include sys/timeb.h twice for VMS. So far as I can see, only the second added conditional makes sense... 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 beta3 release v. VMS
Hello, I have put some effort and succeeded to build version 1.0.0 Beta 3 on OpenVMS. ... actually the lion part of the job was already done by SMS and properly merged up to 1.0.0 Beta - as you can read at http://antinode.info/ftp/openssl/0_9_8j/notes_0_9_8j.txt I was forced to change few make files and some headers, configuration files etc. and would like to provide a patch. As you probably know VMS has a different DIFF output than UNIX diff and is not able to produce patch output. Please advice, how can I share my changes. May I submit a standard VMS diff output here? Thank you in advance. Regards Zoltan Arpadffy -Original Message- From: Steven M. Schweda [mailto:s...@antinode.info] Sent: den 15 juli 2009 21:48 To: openssl-dev@openssl.org Subject: OpenSSL 1.0.0 beta3 release v. VMS From: Dr. Stephen Henson st...@openssl.org OpenSSL version 1.0.0 Beta 3 The VMS build fails pretty quickly. The VMS builders seem to have gained some of the changes I've suggested for 0.9.8k (like $ ARCH = F$EDIT( F$GETSYI( ARCH_NAME), UPCASE) ), but there's still a lot of junk (like, for example, $ IF ARCH .EQS. AXP where ARCH is now never AXP), and, I fear, much, much more. Should I be trying to do something to (re-) straighten out the mess, or is it already better than it seems, or does someone think that it works, or what? 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 beta3 release v. VMS
Hello, It would be my pleasure to work with you. As redesign and create the make files for the VMS build is a bigger task, I suggested earlier making a design together and splitting the tasks. I am very interested in VMS build - to be independent from HP SSL releases. Regards, Z -Original Message- From: Steven M. Schweda [mailto:s...@antinode.info] Sent: den 15 juli 2009 21:48 To: openssl-dev@openssl.org Subject: OpenSSL 1.0.0 beta3 release v. VMS From: Dr. Stephen Henson st...@openssl.org OpenSSL version 1.0.0 Beta 3 The VMS build fails pretty quickly. The VMS builders seem to have gained some of the changes I've suggested for 0.9.8k (like $ ARCH = F$EDIT( F$GETSYI( ARCH_NAME), UPCASE) ), but there's still a lot of junk (like, for example, $ IF ARCH .EQS. AXP where ARCH is now never AXP), and, I fear, much, much more. Should I be trying to do something to (re-) straighten out the mess, or is it already better than it seems, or does someone think that it works, or what? 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: OpenVMS build issues
Richard, I still believe in fairy tales and the power of non-funded, contributed, open source development. You have the idea and you are responsible for the VMS code health and we are at least three who want to do the job. This is not that huge work as the code itself compiles... just the build procedure needs to be redesigned and updated. Please, organize the work and split among us. You said you have an AXP. I run at home both AXP and VAX (www.polarhome.com) and have access to IA64 environment at work. Let do the job... together with your competent leading we can develop a permanent solution in no time. Thank you. Regards, Z -Original Message- From: Richard Levitte [mailto:rich...@levitte.org] Sent: den 29 maj 2009 21:56 To: openssl-dev@openssl.org; Arpadffy Zoltan Subject: Re: OpenVMS build issues I'll be honest with you; I've wanted to redo the whole build system for VMS so it can be automatically generated from the Unix makefiles, the same way the build system for Windows is made. I can see some common building blocks that this would be generated from, similar to the crap that's repeated over all the current build scripts. It's a pretty big job... The only thing I've lacked it *funded* time. I only have so much non-funded time to spend... 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
OpenVMS build issues
Hello, I have made an attempt to build 0.9.8k on OpenVMS - and this is a disaster :( This was the very first time that tried to build openssl on VMS from original openssl.org release and I find out that provided VMS build scripts are not up to date. Some ten years ago extremely lot of effort is put into the OpenVMS port of openssl. I see also that there were still some efforts to update those scripts too as the source has evolved/developed but the scripts have not been tested and do not build the libraries and the executables correctly... moreover the VMS build supports just VAX and AXP architecture but not IA64. Then I realized that the HP SSL releases made from the official openssl.org releases do compile and build correctly. Seems HP put en extra effort every time to update and tune the VMS build scripts for a chosen openssl.org release. The following questions arise and I would like to discuss with somebody what the possibilities are and how to solve those issues. 1. I understand that the openssl license does not force HP to share, provide, publish and merge back the HP changes to the openssl.org source. I also understand that if HP would like to make sure that the next openssl.org release would be VMS compatible that HP would submit the changes... But the HP sources are public as well and the working solution is available for everybody. The question is: Is it legal to use HP's solution and merge into the openssl source? 2. Is there anybody here that works for HP and who is willing to do it? 3. HP SSL is a well done VMS port of openssl, unfortunately it is released every 3-4 year. The current latest release is 1.3 that is based 0.9.7e (released Oct 2004) that is a few years old release. My opinion is that a security product should be released much more often - specially that the OpenVMS users are so dependent of the HP SSL releases and the openssl.org releases do not build on VMS. Does anybody can take up that question with HP? As I am personally very interested that openssl runs and builds correctly on OpenVMS, I am willing to contribute... just wonder why this is not done so far? Is there any special reason or just nobody needed it? Nobody wanted to hassle around with it? With making a proper functional make/build scripts for VMS everybody would benefit. Primarily we, OpenVMS users would benefit as well as HP who could skip the development and maintenance of its own SSL releases. Please respond and advice. Thank you. Regards, Zoltan Arpadffy
