Re: Openssl build errors on zLinux and HP-ita
I could not get this working even on a 11.23 machine having latest (last one released in December 2007). Can anyone tell me the impact of not using +sectionmerge since it is not working on 11.23. I am also evaluating the possibility of using 11.31 and tried building openssl on it, however, getting different error while bulding fips code this time: + cc -I. -I.. -I../include -DOPENSSL_FIPSCANISTER +Z -DOPENSSL_PIC -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -D_REENTRANT -Ae +DD64 +O3 +Olit=all -z -DB_ONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -DHMAC_EXT=sha1 -Wl,+sectionmerge -r -nostdlib -o fipscanister.o fips_start.o fipo ../crypto/aes/aes_ecb.o ../crypto/aes/aes_ofb.o ../crypto/bn/bn_add.o ../crypto/bn/bn_blind.o ../crypto/bn/bn_ctx.o ../crypto/bn/bn_div.o ../crypto/bn/bn_/bn/bn_gcd.o ../crypto/bn/bn_lib.o ../crypto/bn/bn_mod.o ../crypto/bn/bn_mont.o ../crypto/bn/bn_mul.o ../crypto/bn/bn_nist.o ../crypto/bn/bn_prime.o ../cryp ../crypto/bn/bn_shift.o ../crypto/bn/bn_sqr.o ../crypto/bn/bn_word.o ../crypto/bn/bn_x931p.o ../crypto/buffer/buf_str.o ../crypto/cmac/cmac.o ../crypto/cryypto/des/cfb64enc.o ../crypto/des/cfb_enc.o ../crypto/des/ecb3_enc.o ../crypto/des/ofb64ede.o ../crypto/des/fcrypt.o ../crypto/des/set_key.o ../crypto/dh/dhto/dh/dh_key.o ../crypto/dsa/dsa_gen.o ../crypto/dsa/dsa_key.o ../crypto/dsa/dsa_ossl.o ../crypto/ec/ec_curve.o ../crypto/ec/ec_cvt.o ../crypto/ec/ec_key.o _mont.o ../crypto/ec/ec_mult.o ../crypto/ec/ecp_nist.o ../crypto/ec/ecp_smpl.o ../crypto/ecdh/ech_key.o ../crypto/ecdh/ech_ossl.o ../crypto/ecdsa/ecs_ossl.o_des3.o ../crypto/evp/e_null.o ../crypto/evp/m_sha1.o ../crypto/evp/m_dss1.o ../crypto/evp/m_dss.o ../crypto/evp/m_ecdsa.o ../crypto/hmac/hmac.o ../crypto/m ../crypto/modes/cfb128.o ../crypto/modes/ctr128.o ../crypto/modes/gcm128.o ../crypto/modes/ofb128.o ../crypto/modes/xts128.o ../crypto/rsa/rsa_eay.o ../crypt.o ../crypto/rsa/rsa_none.o ../crypto/rsa/rsa_oaep.o ../crypto/rsa/rsa_pk1.o ../crypto/rsa/rsa_pss.o ../crypto/rsa/rsa_ssl.o ../crypto/rsa/rsa_x931.o ../ca1dgst.o ../crypto/sha/sha256.o ../crypto/sha/sha512.o ../crypto/thr_id.o ../crypto/uid.o ../crypto/ia64cpuid.o ../crypto/bn/bn-ia64.o ../crypto/bn/ia64-mon/aes/aes_cbc.o ../crypto/aes/aes-ia64.o ../crypto/des/des_enc.o ../crypto/des/fcrypt_b.o ../crypto/sha/sha1-ia64.o ../crypto/sha/sha256-ia64.o ../crypto/shaa64.o sha/fips_sha1_selftest.o hmac/fips_hmac_selftest.o rand/fips_rand.o rand/fips_rand_selftest.o rand/fips_drbg_lib.o rand/fips_drbg_hash.o rand/fips_drbs_drbg_ec.o rand/fips_drbg_selftest.o rand/fips_drbg_rand.o rand/fips_rand_lib.o des/fips_des_selftest.o aes/fips_aes_selftest.o dsa/fips_dsa_selftest.o dsaa/fips_rsa_selftest.o rsa/fips_rsa_sign.o rsa/fips_rsa_lib.o dh/fips_dh_lib.o utl/fips_err.o utl/fips_md.o utl/fips_enc.o utl/fips_lck.o utl/fips_mem.o ecdsgn.o ecdsa/fips_ecdsa_selftest.o ecdh/fips_ecdh_selftest.o cmac/fips_cmac_selftest.o fips_end.o (Bundled) cc: warning 922: -Ae is unsupported in the bundled compiler, ignored. (Bundled) cc: warning 922: +O3 is unsupported in the bundled compiler, ignored. (Bundled) cc: warning 922: +Olit=all is unsupported in the bundled compiler, ignored. (Bundled) cc: warning 922: -r is unsupported in the bundled compiler, ignored. ld: Unsatisfied symbol main in file no file 1 errors. *** Error exit code 1 Stop. *** Error exit code 1 Stop. *** Error exit code 1 Stop. How to identify, from so many files which one it is complaining for? :( Another build issue on HP-PA: I am getting following error on HP-PA while building fips capable openssl: make[2]: Entering directory `/openssl/hp-pa/openssl-1.0.1h' [ -z libcrypto ] || cc +Z -DOPENSSL_PIC -DOPENSSL_THREADS -DDSO_DL -D_REENTRANT +DA2.0 +DS2.0 +O3 +Optrs_strongly_typed -Ae +ESlit -DB_ENDIAN -DMD32_XARRAY -D_REENTRANT -I/openssl/hp-pa/fips/include -Iinclude \ -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso \ /openssl/hp-pa/fips/lib/fips_premain.c /openssl/hp-pa/fips/lib/fipscanister.o \ libcrypto.a -Wl,+s -ldld /usr/ccs/bin/ld: Duplicate symbol $global$ in files /opt/langtools/lib/crt0.o and /openssl/hp-pa/fips/lib/fipscanister.o /usr/ccs/bin/ld: Duplicate symbol $START$ in files /opt/langtools/lib/crt0.o and /openssl/hp-pa/fips/lib/fipscanister.o /usr/ccs/bin/ld: Duplicate symbol $ARGV in files /opt/langtools/lib/crt0.o and /openssl/hp-pa/fips/lib/fipscanister.o /usr/ccs/bin/ld: Duplicate symbol _environ in files /opt/langtools/lib/crt0.o and /openssl/hp-pa/fips/lib/fipscanister.o /usr/ccs/bin/ld: Duplicate symbol _CPU_REVISION in files /opt/langtools/lib/crt0.o and /openssl/hp-pa/fips/lib/fipscanister.o /usr/ccs/bin/ld: Duplicate symbol _CPU_KEYBITS_1 in files /opt/langtools/lib/crt0.o and /openssl/hp-pa/fips/lib/fipscanister.o /usr/ccs/bin/ld: Duplicate symbol _FPU_MODEL in files /opt/langtools/lib/crt0.o and /openssl/hp-pa/fips/lib/fipscanister.o /usr/ccs/bin/ld: Duplicate symbol _mcount in files /opt/langtools/lib/crt0.o and
Re: [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX
And an additional follow-up, with docs and refined code. On Fri, Sep 19, 2014 at 2:48 AM, Fedor Indutny fe...@indutny.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here is an example of how it could be used (in my TLS terminator): https://github.com/indutny/bud/compare/master...feature/async-key-ex Basically, if you have ever used async SSL API, you should be aware of things like: SSL_ERROR_WANT_READ SSL_ERROR_WANT_WRITE In addition to these two, my patch adds: SSL_ERROR_WANT_SIGN SSL_ERROR_WANT_RSA_DECRYPT If one of these is returned - you may get the data that should be signed/decrypted with: SSL_get_key_ex_data() SSL_get_key_ex_len() Get the key type (in case of SIGN): SSL_get_key_ex_type() // Returns EVP_PKEY_RSA, EVP_PKEY_ECC And get signature digest nid with: SSL_get_key_ex_md() Please be aware of the fact that `md` could be `NID_md5_sha1`, take a look at bud's code to figure out what should be done in this case (basically, you'll need to use raw `RSA_decrypt_private()`). After performing sign/decrypt (which could happen in other thread, or on a different server) you should call: SSL_supply_key_ex() to supply the result and continue handshake process. At this point `SSL_read()`/`SSL_write()` will start returning proper values. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJUG2D2AAoJENcGPM4Zt+iQJdoQAKZxbcGpzHFktSbU3uDocy3R fywWmqkYnoJ5jWF3xn4Excv4dAGhMfb/7tm9nt9zyV8g0Qsu8ChqWTl+kgK+hj9o mV+3jhqPDWR2VhmAC3J5ZsCpNm3IW/iNgGiU+u/k9N2i0WHjYSoTHM/NooN5GIu2 KKhNXPw1Y05yxOZWmbUInMl/uscGWDtzylRNyJpfLFFu3JDQy1sBTKD6UAZC5ERY 7LUZ1TqVdk1DPY3Tf/j4IaB9Ds9teGLGj63J8upJhDjWHibFzV5bx6X+FjknUB9M xaebV4yfHZNRHseBu2ZqTQ2f2MNnXVisdzJRX6oyYeyq872MsJjAFhbFhFTi0sTI T8Y9n8cjuctbn+zTISVyVqEEBl8udWTY1t14SJ9lNcdU3xAf9OzEBVdORpUDqFl+ zteRC145o7gs7mEtJjyBpy8mhXB3mc13ZkC2qaJIyqkqAPODu/xlqCga7oaogHNy Q2wy0HUeX69Ra0ada3TcJQgB14qESj3Uvq1hcgFk7SEXBxkU5NJ2OcItvU1+emd7 hRlQvDqiiQcK9WgsdOIKZpovtT3FswhsIy0Tv77Nx9PY04urOTEgmhPJHveCJOQq i0apvI09YgimXs4Sd5h3rs9TsKrDtG0BG0jM1zfo5zbcKE2IbMpmzOc84MxkwUSl tPV48uw46UVpu4zOOByM =zJGs -END PGP SIGNATURE- On Sat, Sep 13, 2014 at 10:59 PM, Fedor Indutny fe...@indutny.com wrote: Here is an additional patch, to expose the type of key that should be used for a signature. On Thu, Sep 11, 2014 at 10:59 AM, Fedor Indutny via RT r...@openssl.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello devs! Here is a patch that implements asynchronous RSA key operation mode for a TLS/SSL implementation in OpenSSL. Here is some technical info about it: Support async RSA exchange by providing new SSL_want_rsa_sign(), SSL_want_rsa_decrypt() API methods. After getting such want values - SSL_supply_key_ex_data() should be invoked to continue handshake with a sign/decrypt data that was received from the remote server. - --- ssl/s3_srvr.c | 398 - ssl/ssl.h | 28 ssl/ssl3.h | 6 + ssl/ssl_lib.c | 31 - ssl/ssl_locl.h | 2 + ssl/ssl_rsa.c | 24 ++-- ssl/ssltest.c | 116 - test/testssl | 6 + 8 files changed, 475 insertions(+), 136 deletions(-) -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJUEWeCAAoJENcGPM4Zt+iQPcoP/0R9wJz0gvqi5QFiGiAyOXyD uWWB+lkGlB4r6AOhu1D02tQaQTaiRhSO3theSMOCZ4fQ+BMqZdyk37zq/6Z/rjnJ jkd062SgYeh8WCvoJSoNF+gSeDgM/WnWw2q6R1Ls+DuYdQstym9+VIgx3LLd0LO8 19mYHPUms0TFkzPfLqST4keHyZlLa1HzsEpdEQ8TWaU1vqqSrH6NfvPDjwwzMVWG yMOW8tM8I2WDU9V6zMm+Mr7qmU/zowwVmOnVu0Mi8wBpcpN1GvFGbN8oXispnLc/ uccrKK1l98p3wnI0uXe5SmXWB5ksaEtz6CMewZotRgKR8dluwEHqIZ1mzE4+TMxK iFDqUlCcRIjGgssGyjbHC23inwDeN1lZjOxE0G0dhzJZcYAYWJ2rWSQQGxBJJy5Z VFxaElNImDyZ9uUFUtEhzGoaAV7isC9h78anTFzJMuJLTiukHERwFPvRgU/HQPNx EG481cmnjJ2M2hyWRBrvCna8SftUPmGHczqDPD+Tt4Ry/msoZpdwEcLNossl6GcF wXoAMeV5Jg8CenVobdLDQ53G1pJCcY58Zk+Ep9Va+DqfoEsyHc+XhhApMP8B4leC R2mwi0KVL5F6NPhqJmDi1aXKtUu4A50j3yk35aJrEjQCKv3BW1gHvlL763Sve/GL CAsACbfGic+GRS52Pmo2 =f3GH -END PGP SIGNATURE- 0001-ssl-SSL_MODE_ASYNC_KEY_EX.patch Description: Binary data 0001-ssl-SSL_MODE_ASYNC_KEY_EX.patch.sig Description: Binary data
Re: [openssl.org #3535] TS high-precision time malformation - demo
Am 18.09.2014 um 20:03 schrieb Salz, Rich: The default time comes from the gettimeofday() system call (see def_time_cb in ts_rsp_sign.c). I don't see any openssl bug here. It does, but I agree with the OP: the *textual formatting* of the fractional second in ./crypto/ts/ts_rsp_sign.c is wrong. It must include leading zeroes: BIO_snprintf(p, 2 + precision, .%06ld, usec); instead of the current BIO_snprintf(p, 2 + precision, .%ld, usec); There's a dot . before the %ld, so any usec below 10 would be incorrectly formatted. Example: usec=5 Expected: .05 Real: .5 Regards, Rainer __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Openssl build errors on zLinux and HP-ita
I could not get this working even on a 11.23 machine having latest (last one released in December 2007). ... latest what? I mean it appears that you missed something. But more relevant question is what does ld -V return, what patches are installed. But please don't show the list and ask which patches should be installed. Or at least don't expect answer from me, as I don't know. As already mentioned, the references to specific ld versions is simply something that was observed to not work and then work in specific situation, it's just two dots on the mesh, that's all. Can anyone tell me the impact of not using +sectionmerge since it is not working on 11.23. It was mentioned it the beginning of thread: it didn't do the sectionmerge (*which was resulting in crash upon startup*). It should be noted that crash is one possibility, another possibility is that initialization test is rendered *non-compliant* with validation requirements. I am also evaluating the possibility of using 11.31 and tried building openssl on it, however, getting different error while bulding fips code this time: + cc -I. -I.. -I../include -DOPENSSL_FIPSCANISTER +Z -DOPENSSL_PIC -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -D_REENTRANT -Ae +DD64 +O3 (Bundled) cc: warning 922: ^ Real, i.e. unbundled, compiler is absolute requirement for OpenSSL on HP-UX in any situation. Another build issue on HP-PA: I am getting following error on HP-PA while building fips capable openssl: make[2]: Entering directory `/openssl/hp-pa/openssl-1.0.1h' [ -z libcrypto ] || cc +Z -DOPENSSL_PIC -DOPENSSL_THREADS -DDSO_DL -D_REENTRANT +DA2.0 +DS2.0 +O3 +Optrs_strongly_typed -Ae +ESlit -DB_ENDIAN -DMD32_XARRAY -D_REENTRANT -I/openssl/hp-pa/fips/include -Iinclude \ -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso \ /openssl/hp-pa/fips/lib/fips_premain.c /openssl/hp-pa/fips/lib/fipscanister.o \ libcrypto.a -Wl,+s -ldld /usr/ccs/bin/ld: Duplicate symbol $global$ in files /opt/langtools/lib/crt0.o and /openssl/hp-pa/fips/lib/fipscanister.o I don't have comment on this, because I don't have access to HP-PA system with vendor compiler. I can only say that goal is that fipscanister.o looks exactly like any other .o file generated by compiler, and just like any other such file it shouldn't have symbols otherwise found in crt0.o. The fact that crt0.o symbols made their way to fipscanister.o indicates that something went wrong at fipscanister.o link stage and -r flag was not respected. Is it possible that it also was linked with bundled compiler? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3537] Bug in TS_check_status_info() and misleading comments
In the TS_check_status_info() there is bug where instead of appending
the ',' character to the failure info texts this character overwrites
the previous failure info text with strcpy() call.
Also the TS_STATUS_BUF_SIZE is named incorrectly as it does not relate
to status text but to the failure info text.
The attached patch fixes these minor bugs.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
diff --git a/crypto/ts/ts_rsp_verify.c b/crypto/ts/ts_rsp_verify.c
index 3c7f816..ec0d37e 100644
--- a/crypto/ts/ts_rsp_verify.c
+++ b/crypto/ts/ts_rsp_verify.c
@@ -87,8 +87,6 @@ static int TS_find_name(STACK_OF(GENERAL_NAME) *gen_names, GENERAL_NAME *name);
/*
* Local mapping between response codes and descriptions.
- * Don't forget to change TS_STATUS_BUF_SIZE when modifying
- * the elements of this array.
*/
static const char *TS_status_text[] =
{ granted,
@@ -101,11 +99,15 @@ static const char *TS_status_text[] =
#define TS_STATUS_TEXT_SIZE (sizeof(TS_status_text)/sizeof(*TS_status_text))
/*
- * This must be greater or equal to the sum of the strings in TS_status_text
+ * This must be greater or equal to the sum of the strings in TS_failure_info
* plus the number of its elements.
*/
-#define TS_STATUS_BUF_SIZE 256
+#define TS_FAILURE_INFO_BUF_SIZE 256
+/*
+ * Don't forget to change TS_FAILURE_INFO_BUF_SIZE when modifying
+ * the elements of this array.
+ */
static struct
{
int code;
@@ -482,7 +484,7 @@ static int TS_check_status_info(TS_RESP *response)
long status = ASN1_INTEGER_get(info-status);
const char *status_text = NULL;
char *embedded_status_text = NULL;
- char failure_text[TS_STATUS_BUF_SIZE] = ;
+ char failure_text[TS_FAILURE_INFO_BUF_SIZE] = ;
/* Check if everything went fine. */
if (status == 0 || status == 1) return 1;
@@ -509,7 +511,7 @@ static int TS_check_status_info(TS_RESP *response)
TS_failure_info[i].code))
{
if (!first)
- strcpy(failure_text, ,);
+ strcat(failure_text, ,);
else
first = 0;
strcat(failure_text, TS_failure_info[i].text);
Re: [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX
Sorry for a noise, here is even better version of this patch. Without BUF_MEM_grow() calls, which were actually useless, and with clearer state management. On Fri, Sep 19, 2014 at 12:30 PM, Fedor Indutny fe...@indutny.com wrote: And an additional follow-up, with docs and refined code. On Fri, Sep 19, 2014 at 2:48 AM, Fedor Indutny fe...@indutny.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here is an example of how it could be used (in my TLS terminator): https://github.com/indutny/bud/compare/master...feature/async-key-ex Basically, if you have ever used async SSL API, you should be aware of things like: SSL_ERROR_WANT_READ SSL_ERROR_WANT_WRITE In addition to these two, my patch adds: SSL_ERROR_WANT_SIGN SSL_ERROR_WANT_RSA_DECRYPT If one of these is returned - you may get the data that should be signed/decrypted with: SSL_get_key_ex_data() SSL_get_key_ex_len() Get the key type (in case of SIGN): SSL_get_key_ex_type() // Returns EVP_PKEY_RSA, EVP_PKEY_ECC And get signature digest nid with: SSL_get_key_ex_md() Please be aware of the fact that `md` could be `NID_md5_sha1`, take a look at bud's code to figure out what should be done in this case (basically, you'll need to use raw `RSA_decrypt_private()`). After performing sign/decrypt (which could happen in other thread, or on a different server) you should call: SSL_supply_key_ex() to supply the result and continue handshake process. At this point `SSL_read()`/`SSL_write()` will start returning proper values. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJUG2D2AAoJENcGPM4Zt+iQJdoQAKZxbcGpzHFktSbU3uDocy3R fywWmqkYnoJ5jWF3xn4Excv4dAGhMfb/7tm9nt9zyV8g0Qsu8ChqWTl+kgK+hj9o mV+3jhqPDWR2VhmAC3J5ZsCpNm3IW/iNgGiU+u/k9N2i0WHjYSoTHM/NooN5GIu2 KKhNXPw1Y05yxOZWmbUInMl/uscGWDtzylRNyJpfLFFu3JDQy1sBTKD6UAZC5ERY 7LUZ1TqVdk1DPY3Tf/j4IaB9Ds9teGLGj63J8upJhDjWHibFzV5bx6X+FjknUB9M xaebV4yfHZNRHseBu2ZqTQ2f2MNnXVisdzJRX6oyYeyq872MsJjAFhbFhFTi0sTI T8Y9n8cjuctbn+zTISVyVqEEBl8udWTY1t14SJ9lNcdU3xAf9OzEBVdORpUDqFl+ zteRC145o7gs7mEtJjyBpy8mhXB3mc13ZkC2qaJIyqkqAPODu/xlqCga7oaogHNy Q2wy0HUeX69Ra0ada3TcJQgB14qESj3Uvq1hcgFk7SEXBxkU5NJ2OcItvU1+emd7 hRlQvDqiiQcK9WgsdOIKZpovtT3FswhsIy0Tv77Nx9PY04urOTEgmhPJHveCJOQq i0apvI09YgimXs4Sd5h3rs9TsKrDtG0BG0jM1zfo5zbcKE2IbMpmzOc84MxkwUSl tPV48uw46UVpu4zOOByM =zJGs -END PGP SIGNATURE- On Sat, Sep 13, 2014 at 10:59 PM, Fedor Indutny fe...@indutny.com wrote: Here is an additional patch, to expose the type of key that should be used for a signature. On Thu, Sep 11, 2014 at 10:59 AM, Fedor Indutny via RT r...@openssl.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello devs! Here is a patch that implements asynchronous RSA key operation mode for a TLS/SSL implementation in OpenSSL. Here is some technical info about it: Support async RSA exchange by providing new SSL_want_rsa_sign(), SSL_want_rsa_decrypt() API methods. After getting such want values - SSL_supply_key_ex_data() should be invoked to continue handshake with a sign/decrypt data that was received from the remote server. - --- ssl/s3_srvr.c | 398 - ssl/ssl.h | 28 ssl/ssl3.h | 6 + ssl/ssl_lib.c | 31 - ssl/ssl_locl.h | 2 + ssl/ssl_rsa.c | 24 ++-- ssl/ssltest.c | 116 - test/testssl | 6 + 8 files changed, 475 insertions(+), 136 deletions(-) -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJUEWeCAAoJENcGPM4Zt+iQPcoP/0R9wJz0gvqi5QFiGiAyOXyD uWWB+lkGlB4r6AOhu1D02tQaQTaiRhSO3theSMOCZ4fQ+BMqZdyk37zq/6Z/rjnJ jkd062SgYeh8WCvoJSoNF+gSeDgM/WnWw2q6R1Ls+DuYdQstym9+VIgx3LLd0LO8 19mYHPUms0TFkzPfLqST4keHyZlLa1HzsEpdEQ8TWaU1vqqSrH6NfvPDjwwzMVWG yMOW8tM8I2WDU9V6zMm+Mr7qmU/zowwVmOnVu0Mi8wBpcpN1GvFGbN8oXispnLc/ uccrKK1l98p3wnI0uXe5SmXWB5ksaEtz6CMewZotRgKR8dluwEHqIZ1mzE4+TMxK iFDqUlCcRIjGgssGyjbHC23inwDeN1lZjOxE0G0dhzJZcYAYWJ2rWSQQGxBJJy5Z VFxaElNImDyZ9uUFUtEhzGoaAV7isC9h78anTFzJMuJLTiukHERwFPvRgU/HQPNx EG481cmnjJ2M2hyWRBrvCna8SftUPmGHczqDPD+Tt4Ry/msoZpdwEcLNossl6GcF wXoAMeV5Jg8CenVobdLDQ53G1pJCcY58Zk+Ep9Va+DqfoEsyHc+XhhApMP8B4leC R2mwi0KVL5F6NPhqJmDi1aXKtUu4A50j3yk35aJrEjQCKv3BW1gHvlL763Sve/GL CAsACbfGic+GRS52Pmo2 =f3GH -END PGP SIGNATURE- 0001-ssl-SSL_MODE_ASYNC_KEY_EX.patch Description: Binary data 0001-ssl-SSL_MODE_ASYNC_KEY_EX.patch.sig Description: Binary data
Re: Openssl build errors on zLinux and HP-ita
On Fri, Sep 19, 2014 at 3:05 PM, Andy Polyakov ap...@openssl.org wrote: I could not get this working even on a 11.23 machine having latest (last one released in December 2007). ... latest what? I mean it appears that you missed something. But more relevant question is what does ld -V return, what patches are installed. But please don't show the list and ask which patches should be installed. Or at least don't expect answer from me, as I don't know. As already mentioned, the references to specific ld versions is simply something that was observed to not work and then work in specific situation, it's just two dots on the mesh, that's all. I meant latest patch.. I ate that word Can anyone tell me the impact of not using +sectionmerge since it is not working on 11.23. It was mentioned it the beginning of thread: it didn't do the sectionmerge (*which was resulting in crash upon startup*). It should be noted that crash is one possibility, another possibility is that initialization test is rendered *non-compliant* with validation requirements. Right. I shouldn't have asked this question again. Apologies. I am also evaluating the possibility of using 11.31 and tried building openssl on it, however, getting different error while bulding fips code this time: + cc -I. -I.. -I../include -DOPENSSL_FIPSCANISTER +Z -DOPENSSL_PIC -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -D_REENTRANT -Ae +DD64 +O3 (Bundled) cc: warning 922: ^ Real, i.e. unbundled, compiler is absolute requirement for OpenSSL on HP-UX in any situation. Okay. Let me try getting unbundled compiler and try compiling Another build issue on HP-PA: I am getting following error on HP-PA while building fips capable openssl: make[2]: Entering directory `/openssl/hp-pa/openssl-1.0.1h' [ -z libcrypto ] || cc +Z -DOPENSSL_PIC -DOPENSSL_THREADS -DDSO_DL -D_REENTRANT +DA2.0 +DS2.0 +O3 +Optrs_strongly_typed -Ae +ESlit -DB_ENDIAN -DMD32_XARRAY -D_REENTRANT -I/openssl/hp-pa/fips/include -Iinclude \ -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso \ /openssl/hp-pa/fips/lib/fips_premain.c /openssl/hp-pa/fips/lib/fipscanister.o \ libcrypto.a -Wl,+s -ldld /usr/ccs/bin/ld: Duplicate symbol $global$ in files /opt/langtools/lib/crt0.o and /openssl/hp-pa/fips/lib/fipscanister.o I don't have comment on this, because I don't have access to HP-PA system with vendor compiler. I can only say that goal is that fipscanister.o looks exactly like any other .o file generated by compiler, and just like any other such file it shouldn't have symbols otherwise found in crt0.o. The fact that crt0.o symbols made their way to fipscanister.o indicates that something went wrong at fipscanister.o link stage and -r flag was not respected. Is it possible that it also was linked with bundled compiler? It is not. Here is the output: bash-2.05$ which cc /bin/cc bash-2.05$ what /bin/cc /bin/cc: $Revision: 92453-07 linker linker crt0.o B.11.64 080728 $ LINT B.11.11.22 CXREF B.11.11.22 HP92453-01 B.11.11.22 HP C Compiler $ PATCH/11.00:PHCO_27774 Oct 3 2002 09:45:59 $ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3165] tru64-alpha-cc compatibility fixes
Hi, http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=d1cf23ac86c05b22b8780e2c03b67230564d2d34 With cross-reference to http://rt.openssl.org/Ticket/Display.html?id= can you confirm that preproc=/tmp/.$@.S assignment works? Thanks for following this up. The only issues I'm seeing on Tru64 V4 from OpenSSL now are code-related build errors; your makefile changes are good. Starting with a plain ./config (defaults for everything), I get two build errors, described below. Once those are fixed---and the attached patch has my changes---the build completes successfully, and the test suite passes. Error the first: cc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -DOPENSSL_THREADS -pthread -DDSO_DLFCN -DHAVE_DLFCN_H -std1 -tune host -fast -readonly_strings -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DGHASH_ASM -c b_sock.c cc: Error: b_sock.c, line 630: The member sa_in6 has an incomplete type. (incompmem) struct sockaddr_in6 sa_in6; ^ cc: Error: b_sock.c, line 862: The member sa_in6 has an incomplete type. (incompmem) struct sockaddr_in6 sa_in6; ^ *** Exit 1 Stop. This is the same IPv6-support issue reported earlier in the ticket. I suggest to resort for adding -DOPENSSL_USE_IPV6=0 at config time. I couldn't reproduce the problem on two different systems, so it's some problem with yours. As for suggestion to add defined(IPPROTO_IPV6), no, it's not appropriate. Error the second: cc -I../crypto -I.. -I../include -DOPENSSL_THREADS -pthread -DDSO_DLFCN -DHAVE_DLFCN_H -std1 -tune host -fast -readonly_strings -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DGHASH_ASM -c s3_cbc.c cc: Error: ../crypto/constant_time_locl.h, line 79: Missing ;. (nosemi) static inline unsigned int constant_time_msb(unsigned int a); --^ cc: Error: ../crypto/constant_time_locl.h, line 84: Missing ;. (nosemi) static inline unsigned int constant_time_lt(unsigned int a, unsigned int b); --^ cc: Error: ../crypto/constant_time_locl.h, line 86: Missing ;. (nosemi) static inline unsigned char constant_time_lt_8(unsigned int a, unsigned int b); --^ cc: Error: ../crypto/constant_time_locl.h, line 91: Missing ;. (nosemi) static inline unsigned int constant_time_ge(unsigned int a, unsigned int b); --^ [several more instances and unrelated warnings elided] *** Exit 1 Stop. Reason: The compiler doesn't understand the inline keyword. It's being discussed internally. BTW, defining inline with defined(__DECC) is formally incorrect, because DEC C *would* accept inline if you pass -c99. Still needing a fix is randfile.c, though on Tru64 V4 it doesn't give me trouble. You mentioned I am building with non-default arguments but never specified which ones. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3165] tru64-alpha-cc compatibility fixes
On Fri, 2014 Sep 19 21:36+0200, Andy Polyakov via RT wrote: I suggest to resort for adding -DOPENSSL_USE_IPV6=0 at config time. I couldn't reproduce the problem on two different systems, so it's some problem with yours. What system(s) are you testing on? Mine is Digital UNIX V4.0G (Rev. 1530). As for suggestion to add defined(IPPROTO_IPV6), no, it's not appropriate. It can be some other symbol, but this system is an example where the presence of AF_INET6 is not enough to assume IPv6 support: $ grep AF_INET6 /usr/include/*/*.h /usr/include/sys/socket.h:#define AF_INET6 26 /* IPV6: UDP, TCP, etc. */ /usr/include/sys/socket.h:#define PF_INET6 AF_INET6 $ grep sockaddr_in6 /usr/include/*.h /usr/include/*/*.h (no output) It's being discussed internally. BTW, defining inline with defined(__DECC) is formally incorrect, because DEC C *would* accept inline if you pass -c99. $ which cc /usr/ccs/bin/cc $ cc -c hello.c cc: Error: hello.c, line 1: Missing ;. (nosemi) static inline int foofunc(void) --^ $ cc -c99 -c hello.c cc: Error: hello.c, line 1: Missing ;. (nosemi) static inline int foofunc(void) --^ You mentioned I am building with non-default arguments but never specified which ones. That was previously. This time, I just used whatever ./config gave me, to make the bug-reporting easier. On an unrelated note: Is it necessary to use /tmp for temporary files? Instead of /tmp/.$@, what about something like tmp.$@ or tmp..$@, creating them in the build tree? --Daniel -- Daniel Richard G. || sk...@iskunk.org My ASCII-art .sig got a bad case of Times New Roman. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3165] tru64-alpha-cc compatibility fixes
I suggest to resort for adding -DOPENSSL_USE_IPV6=0 at config time. I couldn't reproduce the problem on two different systems, so it's some problem with yours. What system(s) are you testing on? We have discussed it earlier, 5.1. And was under impression that you target 5.1 too. You had older compiler, but system headers should have been same. Mine is Digital UNIX V4.0G (Rev. 1530). Even more reason to resort additional argument. I mean if something is broken and/or is not up to contemporary standard, why is it source code that is expected to be twisted to accommodate outdated system? When it's possible to work around the problem without modifying code. It's being discussed internally. BTW, defining inline with defined(__DECC) is formally incorrect, because DEC C *would* accept inline if you pass -c99. $ which cc /usr/ccs/bin/cc $ cc -c hello.c cc: Error: hello.c, line 1: Missing ;. (nosemi) static inline int foofunc(void) --^ $ cc -c99 -c hello.c cc: Error: hello.c, line 1: Missing ;. (nosemi) static inline int foofunc(void) --^ Works for me with C V6.5. inline is part of C99, so that if compiler accepts -c99 and fails to compile recognize inline as keyword, it's formally a bug. So that guarding with __DECC alone is still formally inappropriate. You mentioned I am building with non-default arguments but never specified which ones. That was previously. This time, I just used whatever ./config gave me, to make the bug-reporting easier. And you still don't provide coherent problem description. I mean last time it was problem with non-specified argument on 5.1, now it's on 4.0. There is no place for guessing and implying in bug reports. Well, formally speaking defining _XOPEN_SOURCE in the middle is inappropriate. Such macros should be defined first... But it wasn't me who added it, so I don't know the rationale... __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3165] tru64-alpha-cc compatibility fixes
On Fri, 2014 Sep 19 23:54+0200, Andy Polyakov via RT wrote: What system(s) are you testing on? We have discussed it earlier, 5.1. And was under impression that you target 5.1 too. You had older compiler, but system headers should have been same. I have a 5.1 system too (though no access to it currently), but the goal was to get things working on both 4.0 and 5.1 so that I can build OpenSSH on both systems. If OpenSSL works on 4.0, then it will probably also work on 5.1 (but not necessarily the other way around). Mine is Digital UNIX V4.0G (Rev. 1530). Even more reason to resort additional argument. I mean if something is broken and/or is not up to contemporary standard, why is it source code that is expected to be twisted to accommodate outdated system? When it's possible to work around the problem without modifying code. There's a difference between modifying code, and modifying the auto- configuration. OpenSSL supports systems that don't have IPv6, so that is all that is needed in code. The problem is in detecting whether or not IPv6 is available. And yes, you can work around the problem by giving an argument, but the reason for having all that cpp logic in e_os.h is so that this isn't necessary. (As for outdated systems, how about NEXTSTEP? :-) Works for me with C V6.5. inline is part of C99, so that if compiler accepts -c99 and fails to compile recognize inline as keyword, it's formally a bug. So that guarding with __DECC alone is still formally inappropriate. Okay, then do you have a better idea? Getting a bug-fix from Compaq is not possible. Here is some information on the compiler version: $ cc -V cc (cc) Digital UNIX Compiler Driver 3.11 Compaq C V6.1-119 on Digital UNIX V4.0G (Rev. 1530) $ echo __DECC __DECC_VER ver.c $ cc -E ver.c # 1 ver.c 1 60190119 And you still don't provide coherent problem description. I mean last time it was problem with non-specified argument on 5.1, now it's on 4.. There is no place for guessing and implying in bug reports. I apologize for not specifying the non-default arguments I used earlier, because I thought the new build error was more interesting. Yes, that prevents you from reproducing the error, and that is not helpful. For now, however, I am testing with a plain, default build, because if that kind of build gives errors then it is a particularly bad problem. I want OpenSSL to build cleanly on 4.0 and 5.1, and it is almost there. Well, formally speaking defining _XOPEN_SOURCE in the middle is inappropriate. Such macros should be defined first... But it wasn't me who added it, so I don't know the rationale... I think someone did it this way because OPENSSL_SYS_VXWORKS is #defined in e_os2.h, which is obtained via e_os.h. They didn't realize that _XOPEN_SOURCE is useless if a system header has already been seen. Maybe if the conditional were moved up and changed to use OPENSSL_SYSNAME_VXWORKS? Isn't that supposed to be #defined on the compiler command line? (Or maybe use some compiler built-in symbol, like __VXWORKS__) --Daniel -- Daniel Richard G. || sk...@iskunk.org My ASCII-art .sig got a bad case of Times New Roman. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
