[openssl.org #2517] [PATCHES] - Misc misspellings, source and docs
The attached patches fix various misspellings in both source and pod files.
Affects all versions; applies against revision in CVS as of May 14 2011
--- a/crypto/asn1/asn1_err.c
+++ b/crypto/asn1/asn1_err.c
@@ -306,7 +306,7 @@
{ERR_REASON(ASN1_R_UNKNOWN_PUBLIC_KEY_TYPE),unknown public key type},
{ERR_REASON(ASN1_R_UNKNOWN_SIGNATURE_ALGORITHM),unknown signature algorithm},
{ERR_REASON(ASN1_R_UNKNOWN_TAG) ,unknown tag},
-{ERR_REASON(ASN1_R_UNKOWN_FORMAT),unkown format},
+{ERR_REASON(ASN1_R_UNKOWN_FORMAT),unknown format},
{ERR_REASON(ASN1_R_UNSUPPORTED_ANY_DEFINED_BY_TYPE),unsupported any defined by type},
{ERR_REASON(ASN1_R_UNSUPPORTED_CIPHER) ,unsupported cipher},
{ERR_REASON(ASN1_R_UNSUPPORTED_ENCRYPTION_ALGORITHM),unsupported encryption algorithm},
--- a/apps/ca.c
+++ b/apps/ca.c
@@ -148,7 +148,7 @@
static const char *ca_usage[]={
usage: ca args\n,
\n,
- -verbose- Talk alot while doing things\n,
+ -verbose- Talk a lot while doing things\n,
-config file- A config file\n,
-name arg - The particular CA definition to use\n,
-gencrl - Generate a new CRL\n,
--- a/apps/ecparam.c
+++ b/apps/ecparam.c
@@ -105,7 +105,7 @@
*in the asn1 der encoding
*possible values: named_curve (default)
* explicit
- * -no_seed - if 'explicit' parameters are choosen do not use the seed
+ * -no_seed - if 'explicit' parameters are chosen do not use the seed
* -genkey - generate ec key
* -rand file - files to use for random number input
* -engine e- use engine e, possibly a hardware device
@@ -286,7 +286,7 @@
BIO_printf(bio_err,
explicit\n);
BIO_printf(bio_err, -no_seed if 'explicit'
- parameters are choosen do not
+ parameters are chosen do not
use the seed\n);
BIO_printf(bio_err, -genkey generate ec
key\n);
--- a/crypto/evp/encode.c
+++ b/crypto/evp/encode.c
@@ -250,7 +250,7 @@
/* We parse the input data */
for (i=0; iinl; i++)
{
- /* If the current line is 80 characters, scream alot */
+ /* If the current line is 80 characters, scream a lot */
if (ln = 80) { rv= -1; goto end; }
/* Get char and put it into the buffer */
--- a/doc/crypto/ASN1_generate_nconf.pod
+++ b/doc/crypto/ASN1_generate_nconf.pod
@@ -61,7 +61,7 @@
=item BINTEGER, BINT
Encodes an ASN1 BINTEGER type. The Bvalue string represents
-the value of the integer, it can be preceeded by a minus sign and
+the value of the integer, it can be preceded by a minus sign and
is normally interpreted as a decimal value unless the prefix B0x
is included.
--- a/doc/crypto/BN_BLINDING_new.pod
+++ b/doc/crypto/BN_BLINDING_new.pod
@@ -48,7 +48,7 @@
BN_BLINDING_convert_ex() multiplies Bn with the blinding factor BA.
If Br is not NULL a copy the inverse blinding factor BAi will be
-returned in Br (this is useful if a BRSA object is shared amoung
+returned in Br (this is useful if a BRSA object is shared among
several threads). BN_BLINDING_invert_ex() multiplies Bn with the
inverse blinding factor BAi. If Br is not NULL it will be used as
the inverse blinding.
--- a/doc/apps/config.pod
+++ b/doc/apps/config.pod
@@ -119,7 +119,7 @@
information.
The section pointed to by Bengines is a table of engine names (though see
-Bengine_id below) and further sections containing configuration informations
+Bengine_id below) and further sections containing configuration information
specific to each ENGINE.
Each ENGINE specific section is used to set default algorithms, load
--- a/doc/crypto/pem.pod
+++ b/doc/crypto/pem.pod
@@ -201,7 +201,7 @@
PEM_write_bio_PKCS8PrivateKey() and PEM_write_PKCS8PrivateKey()
write a private key in an EVP_PKEY structure in PKCS#8
EncryptedPrivateKeyInfo format using PKCS#5 v2.0 password based encryption
-algorithms. The Bcipher argument specifies the encryption algoritm to
+algorithms. The Bcipher argument specifies the encryption algorithm to
use: unlike all other PEM routines the encryption is applied at the
PKCS#8 level and not in the PEM headers. If Bcipher is NULL then no
encryption is used and a PKCS#8 PrivateKeyInfo structure is used instead.
--- a/doc/ssl/SSL_CTX_set_verify.pod
+++ b/doc/ssl/SSL_CTX_set_verify.pod
@@ -169,8 +169,8 @@
failure, if wished. The callback realizes a verification depth limit with
more informational output.
-All verification errors are printed, informations about the certificate chain
-are printed on request.
+All verification errors are printed; information about the certificate chain
+is printed on request.
The example is realized for a server that does allow but not require client
certificates.
--- a/doc/crypto/EVP_BytesToKey.pod
+++ b/doc/crypto/EVP_BytesToKey.pod
@@ -17,7 +17,7 @@
EVP_BytesToKey() derives a key and IV from various parameters. Btype is
the cipher to derive the key and
[openssl.org #2518] [PATCHES] - pod2man Errors
The attached patches fix various errors/warnings in pod files. Most are due to recent mods to pod2man utility, which now issues warnings [which unfortunately end up in manpage source output], when subsequent item tags are not 'sequential' .. Affects all versions; applies against revision in CVS as of May 14 2011 --- a/doc/ssl/SSL_CTX_set_client_CA_list.pod +++ b/doc/ssl/SSL_CTX_set_client_CA_list.pod @@ -66,16 +66,16 @@ =over 4 -=item 1 - -The operation succeeded. - =item 0 A failure while manipulating the STACK_OF(X509_NAME) object occurred or the X509_NAME could not be extracted from Bcacert. Check the error stack to find out the reason. +=item 1 + +The operation succeeded. + =back =head1 EXAMPLES --- a/doc/apps/genpkey.pod +++ b/doc/apps/genpkey.pod @@ -114,6 +114,8 @@ The number of bits in the generated parameters. If not specified 1024 is used. +=back + =head1 DH PARAMETER GENERATION OPTIONS =over 4 --- a/doc/apps/openssl.pod +++ b/doc/apps/openssl.pod @@ -287,8 +287,6 @@ SHA-1 Digest -=back - =item Bsha224 SHA-224 Digest @@ -305,6 +303,8 @@ SHA-512 Digest +=back + =head2 ENCODING AND CIPHER COMMANDS =over 10 --- a/doc/ssl/SSL_accept.pod +++ b/doc/ssl/SSL_accept.pod @@ -44,10 +44,13 @@ =over 4 -=item 1 +=item Elt0 -The TLS/SSL handshake was successfully completed, a TLS/SSL connection has been -established. +The TLS/SSL handshake was not successful because a fatal error occurred either +at the protocol level or a connection failure occurred. The shutdown was +not clean. It can also occur of action is need to continue the operation +for non-blocking BIOs. Call SSL_get_error() with the return value Bret +to find out the reason. =item 0 @@ -55,13 +58,10 @@ by the specifications of the TLS/SSL protocol. Call SSL_get_error() with the return value Bret to find out the reason. -=item Elt0 +=item 1 -The TLS/SSL handshake was not successful because a fatal error occurred either -at the protocol level or a connection failure occurred. The shutdown was -not clean. It can also occur of action is need to continue the operation -for non-blocking BIOs. Call SSL_get_error() with the return value Bret -to find out the reason. +The TLS/SSL handshake was successfully completed, a TLS/SSL connection has been +established. =back --- a/doc/ssl/SSL_connect.pod +++ b/doc/ssl/SSL_connect.pod @@ -41,10 +41,13 @@ =over 4 -=item 1 +=item Elt0 -The TLS/SSL handshake was successfully completed, a TLS/SSL connection has been -established. +The TLS/SSL handshake was not successful, because a fatal error occurred either +at the protocol level or a connection failure occurred. The shutdown was +not clean. It can also occur of action is need to continue the operation +for non-blocking BIOs. Call SSL_get_error() with the return value Bret +to find out the reason. =item 0 @@ -52,13 +55,10 @@ by the specifications of the TLS/SSL protocol. Call SSL_get_error() with the return value Bret to find out the reason. -=item Elt0 +=item 1 -The TLS/SSL handshake was not successful, because a fatal error occurred either -at the protocol level or a connection failure occurred. The shutdown was -not clean. It can also occur of action is need to continue the operation -for non-blocking BIOs. Call SSL_get_error() with the return value Bret -to find out the reason. +The TLS/SSL handshake was successfully completed, a TLS/SSL connection has been +established. =back --- a/doc/ssl/SSL_do_handshake.pod +++ b/doc/ssl/SSL_do_handshake.pod @@ -45,10 +45,13 @@ =over 4 -=item 1 +=item Elt0 -The TLS/SSL handshake was successfully completed, a TLS/SSL connection has been -established. +The TLS/SSL handshake was not successful because a fatal error occurred either +at the protocol level or a connection failure occurred. The shutdown was +not clean. It can also occur of action is need to continue the operation +for non-blocking BIOs. Call SSL_get_error() with the return value Bret +to find out the reason. =item 0 @@ -56,13 +59,10 @@ by the specifications of the TLS/SSL protocol. Call SSL_get_error() with the return value Bret to find out the reason. -=item Elt0 +=item 1 -The TLS/SSL handshake was not successful because a fatal error occurred either -at the protocol level or a connection failure occurred. The shutdown was -not clean. It can also occur of action is need to continue the operation -for non-blocking BIOs. Call SSL_get_error() with the return value Bret -to find out the reason. +The TLS/SSL handshake was successfully completed, a TLS/SSL connection has been +established. =back --- a/doc/ssl/SSL_shutdown.pod +++ b/doc/ssl/SSL_shutdown.pod @@ -92,10 +92,13 @@ =over 4 -=item 1 +=item -1 -The shutdown was successfully completed. The close notify alert was sent -and the peer's close notify alert was received. +The shutdown was not successful because a fatal error occurred either +at the protocol level or a connection failure occurred.
We want to submit a patch to support VIA Padlock
Hi OpenSSL developers, We have found that Michal and Harald have worked on the SHA1/224/256 patch and RNG patch for VIA, http://marc.info/?l=openssl-devm=122027889502874w=2 http://marc.info/?l=openssl-devm=115243758508970w=2 but unfortunately, these patches have been not merged into the OpenSSL upstream now. In addition, we found some other people have pay attention to VIA Padlock JM submitted a SHA1/224/256 patch http://marc.info/?l=openssl-devm=128786191732264w=2 Timo has propose some question about via-mont.pl http://marc.info/?l=openssl-devm=124945660509287w=2 However, they never received any feedback on the list, so that I am confused whether I should resume Michal and Harald'work and submit other patches for VIA PadLock to OpenSSL. Therefore, I hope some OpenSSL developers can help me on the following questions: 1. If I resume the Michal and Harald' work on SHA1/224/256 patch and RNG patch, are you interested in it? 2. Thevia-mont.plseems no to be used, is there any taboo against it or some bad history I are missing ? If yes, please tell me. 3. If I want to submit a patch which implements modular multiplication and modular exponentiation by calling VIA PadLock hardware instruction, should I write it in a individual Perl script like via-mont.pl, or wrap it in the RSA/DSA method to be implemented in PadLock engine ? Or both are required? In any case, we are here to wait for your replies and we have time to do anything that can make the work go on. So please talk to me. Thanks very much for your attention and help. Brily 2011-05-16 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: We want to submit a patch to support VIA Padlock
Hi, 2011/5/16 brill...@viatech.com.cn: Hi OpenSSL developers, We have found that Michal and Harald have worked on the SHA1/224/256 patch and RNG patch for VIA, http://marc.info/?l=openssl-devm=122027889502874w=2 http://marc.info/?l=openssl-devm=115243758508970w=2 but unfortunately, these patches have been not merged into the OpenSSL upstream now. In addition, we found some other people have pay attention to VIA Padlock JM submitted a SHA1/224/256 patch http://marc.info/?l=openssl-devm=128786191732264w=2 I have made enhanved versions of the SHA support including partial Nano support and proper optimizations for the earlier variant that does finalizing hashing only. They are both on OpenSSL RT. Latest versions of my patch set for 1.0-branch is at: http://git.alpinelinux.org/cgit/aports.git/tree/main/openssl Timo has propose some question about via-mont.pl http://marc.info/?l=openssl-devm=124945660509287w=2 However, they never received any feedback on the list, so that I am confused whether I should resume Michal and Harald'work and submit other patches for VIA PadLock to OpenSSL. Therefore, I hope some OpenSSL developers can help me on the following questions: 1. If I resume the Michal and Harald' work on SHA1/224/256 patch and RNG patch, are you interested in it? Please take a look at my SHA patches, they should implement everything properly. RNG patches you might need to fix. 2. Thevia-mont.plseems no to be used, is there any taboo against it or some bad history I are missing ? If yes, please tell me. I think the OpenSSL core code is missing montgomery multiplication abstraction. It seems to be compile time option only to pick which implementation is used. So to get the montgomery stuff enabled by default, you'd probably also need to implement abstraction support for it. 3. If I want to submit a patch which implements modular multiplication and modular exponentiation by calling VIA PadLock hardware instruction, should I write it in a individual Perl script like via-mont.pl, or wrap it in the RSA/DSA method to be implemented in PadLock engine ? Or both are required? They work on different levels of the openssl library. Implementing via-mont.pl would be probably easier. Doing the implementation only in RSA/DSA method of the padlock module would enable the multiplication acceleration only for certain operations of the library. So I'd probably go with via-mont.pl and adding the required abstraction layer. In any case, we are here to wait for your replies and we have time to do anything that can make the work go on. So please talk to me. Thanks very much for your attention and help. Thanks, Timo __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Problem performing SSL handshake in FIPS mode
Hi. I'm trying to test the current CVS HEAD with
FIPS_set_module_mode(1).
It's looking fairly promising to me, but I currently have one problem:
While performing an SSL handshake, I get
1208113320:error:060A80A3:digital envelope routines:FIPS_DIGESTINIT:disabled
for fips:fips_md.c:179:
This sounded a bit weird to me, since I've tried my best to set up my
application to use only FIPS-validated algorithms, but to no avail. I
added some debugging printouts to my libcrypto, and from what I could
understand, the digest in question is MD5. When I patched openssl to
say MD5 was a FIPS-approved digest, it worked.
The program I'm using is attached, and also output from a separate
'openssl s_client -connect -showcerts'.
Does anyone have any ideas as to why MD5 appears in this handshake?
#include stddef.h
#include openssl/fips.h
#include openssl/fips_rand.h
#include openssl/rand.h
#include openssl/err.h
#include stdio.h
#include string.h
#include openssl/ssl.h
#include sys/socket.h
#include unistd.h
#include fcntl.h
#include arpa/inet.h
static int attempt_handshake(void)
{
SSL_CTX *ctx = SSL_CTX_new(TLSv1_client_method());
SSL *ssl;
int ret;
BIO *bio;
if (!ctx) {
ERR_print_errors_fp(stderr);
return 1;
}
if (!SSL_CTX_set_cipher_list(ctx, FIPS:!MD5:@STRENGTH)) {
ERR_print_errors_fp(stderr);
return 1;
}
ssl = SSL_new(ctx);
if (!ssl)
return 1;
bio = BIO_new_connect((char*) 10.47.1.58:5061);
BIO_set_nbio(bio, 1);
if (!bio) {
fprintf(stderr, Failed to open read/write BIO\n);
BIO_free(bio);
SSL_free(ssl);
SSL_CTX_free(ctx);
return 1;
}
SSL_set_bio(ssl, bio, bio);
while (1) {
int sslerr;
ret = SSL_connect(ssl);
if (ret 0) {
ret = 0;
fprintf(stderr, SSL handshake completed!\n);
break;
}
if (ret = 0)
sslerr = SSL_get_error(ssl, ret);
if (sslerr == SSL_ERROR_WANT_WRITE || sslerr == SSL_ERROR_WANT_READ ||
sslerr == SSL_ERROR_WANT_ACCEPT || sslerr == SSL_ERROR_WANT_CONNECT
||
sslerr == SSL_ERROR_NONE) {
fprintf(stderr, Handshake continue (%d, %d)\n, ret, sslerr);
ERR_print_errors_fp(stderr);
ret = 0;
} else {
fprintf(stderr, Failed to SSL_connect()\n);
ERR_print_errors_fp(stderr);
ret = 1;
break;
}
}
SSL_shutdown(ssl);
SSL_free(ssl);
SSL_CTX_free(ctx);
return ret;
}
int main(void)
{
size_t i;
unsigned char obuf[2048];
//const unsigned char key[] = { 0xab, 0xcd, 0x42, 0x12, 0x12, 0x32 };
ERR_load_crypto_strings();
SSL_load_error_strings();
SSL_library_init();
OpenSSL_add_all_algorithms();
//FIPS_x931_set_key(key, sizeof key);
//FIPS_x931_seed(key, sizeof key);
//RAND_set_rand_method(FIPS_x931_method());
RAND_set_rand_method(FIPS_drbg_method());
if (!FIPS_module_mode_set(1)) {
ERR_print_errors_fp(stderr);
return EXIT_FAILURE;
}
memset(obuf, 0, sizeof obuf);
for (i = 0; i 100; ++i) {
unsigned char buf[2048];
if (!RAND_pseudo_bytes(buf, sizeof buf) ||
memcmp(buf, obuf, sizeof obuf) == 0) {
ERR_print_errors_fp(stderr);
return EXIT_FAILURE;
}
memcpy(obuf, buf, sizeof buf);
}
fprintf(stderr, Running with RAND_METHOD %p\n, RAND_get_rand_method());
fprintf(stderr, ssleay %p, x931 %p, drbg %p\n, RAND_SSLeay(),
FIPS_x931_method(), FIPS_drbg_method());
return attempt_handshake();
}
[14:13:52][hgb@prentice:/data/revo/main]1086 openssl s_client -connect
10.47.1.58:5061 -showcerts -tls1
CONNECTED(0003)
depth=0 C = NO, ST = Akershus, L = Lysaker, O = TANDBERG ASA, OU = RD, CN =
rdvcs1.rd.tandberg.com, emailAddress = support...@tandberg.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = NO, ST = Akershus, L = Lysaker, O = TANDBERG ASA, OU = RD, CN =
rdvcs1.rd.tandberg.com, emailAddress = support...@tandberg.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 C = NO, ST = Akershus, L = Lysaker, O = TANDBERG ASA, OU = RD, CN =
rdvcs1.rd.tandberg.com, emailAddress = support...@tandberg.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/C=NO/ST=Akershus/L=Lysaker/O=TANDBERG
ASA/OU=RD/CN=rdvcs1.rd.tandberg.com/emailAddress=support...@tandberg.com
i:/C=NO/ST=Akershus/L=Lysaker/O=TANDBERG ASA/CN=TAA ROOT
CA/emailAddress=roo...@tandberg.com
-BEGIN CERTIFICATE-
MIICjjCCAk2gAwIBAgIBDDAJBgcqhkjOOAQDMIGDMQswCQYDVQQGEwJOTzERMA8G
A1UECBMIQWtlcnNodXMxEDAOBgNVBAcTB0x5c2FrZXIxFTATBgNVBAoTDFRBTkRC
RVJHIEFTQTEUMBIGA1UEAxMLVEFBIFJPT1QgQ0ExIjAgBgkqhkiG9w0BCQEWE3Jv
b3RjYUB0YW5kYmVyZy5jb20wHhcNMDkxMDE1MTAwNDA4WhcNMTExMDA1MTAwNDA4
Re: [openssl.org #2470] [PATCH] Cygwin: Don't call ERR_remove_state from DllMain
Ping? On Mar 22 12:03, Corinna Vinschen via RT wrote: On Mar 17 09:11, Corinna Vinschen via RT wrote: Hi, the below patch is against current CVS HEAD, but it should be applied to all supported branches of OpenSSL, starting with 0.9.8. On systems running on the Windows platform, there's a DllMain function in crypto/cryptlib.c which always calls ERR_remove_state(0) if an application thread exits. While this may be ok for native Windows applications, it's wrong for applications running under Cygwin, given that Cygwin is a POSIX environment. Not only that compliant applications are written so that they call ERR_remove_state by themselves right before exiting from a thread, the gratuitous ERR_remove_state call in DllMain also potentially crashes threaded applications. For examples see http://bugs.python.org/issue3947 and http://cygwin.com/ml/cygwin/2008-11/msg00341.html The latest openssl package in the Cygwin net distribution also has this patch applied. Here's the patch against latest CVS. However, it would be nice if it could be applied in the 0.9.8 branch as well. Thanks, Corinna Index: crypto/cryptlib.c === RCS file: /home/cvs/cvsroot/src/openssl/crypto/cryptlib.c,v retrieving revision 1.87 diff -u -p -r1.87 cryptlib.c --- crypto/cryptlib.c 3 Feb 2011 23:12:01 - 1.87 +++ crypto/cryptlib.c 22 Mar 2011 11:02:45 - @@ -208,7 +208,7 @@ BOOL WINAPI DllMain(HINSTANCE hinstDLL, case DLL_THREAD_ATTACH: break; case DLL_THREAD_DETACH: -#ifndef OPENSSL_FIPS +#if !defined(OPENSSL_FIPS) !defined(__CYGWIN__) ERR_remove_state(0); #endif break; -- Corinna Vinschen Cygwin Project Co-Leader Red Hat __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org -- Corinna Vinschen Cygwin Project Co-Leader Red Hat __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2470] [PATCH] Cygwin: Don't call ERR_remove_state from DllMain
Ping? On Mar 22 12:03, Corinna Vinschen via RT wrote: On Mar 17 09:11, Corinna Vinschen via RT wrote: Hi, the below patch is against current CVS HEAD, but it should be applied to all supported branches of OpenSSL, starting with 0.9.8. On systems running on the Windows platform, there's a DllMain function in crypto/cryptlib.c which always calls ERR_remove_state(0) if an application thread exits. While this may be ok for native Windows applications, it's wrong for applications running under Cygwin, given that Cygwin is a POSIX environment. Not only that compliant applications are written so that they call ERR_remove_state by themselves right before exiting from a thread, the gratuitous ERR_remove_state call in DllMain also potentially crashes threaded applications. For examples see http://bugs.python.org/issue3947 and http://cygwin.com/ml/cygwin/2008-11/msg00341.html The latest openssl package in the Cygwin net distribution also has this patch applied. Here's the patch against latest CVS. However, it would be nice if it could be applied in the 0.9.8 branch as well. Thanks, Corinna Index: crypto/cryptlib.c === RCS file: /home/cvs/cvsroot/src/openssl/crypto/cryptlib.c,v retrieving revision 1.87 diff -u -p -r1.87 cryptlib.c --- crypto/cryptlib.c 3 Feb 2011 23:12:01 - 1.87 +++ crypto/cryptlib.c 22 Mar 2011 11:02:45 - @@ -208,7 +208,7 @@ BOOL WINAPI DllMain(HINSTANCE hinstDLL, case DLL_THREAD_ATTACH: break; case DLL_THREAD_DETACH: -#ifndef OPENSSL_FIPS +#if !defined(OPENSSL_FIPS) !defined(__CYGWIN__) ERR_remove_state(0); #endif break; -- Corinna Vinschen Cygwin Project Co-Leader Red Hat __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org -- Corinna Vinschen Cygwin Project Co-Leader Red Hat __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2471] [PATCH] util/cygwin.sh from CVS HEAD should be applied to 0.9.8 branch
Ping?
On Mar 17 12:44, Corinna Vinschen via RT wrote:
Hi,
would you mind to apply the below patch to util/cygwin.sh in the 0.9.8
branch, too? It has been applied only to HEAD, accidentally.
Thanks,
Corinna
--- openssl-0.9.8r/util/cygwin.sh 2005-06-23 22:55:35.0 +0200
+++ openssl-0.9.8r-1/util/cygwin.sh 2011-02-08 19:22:45.010931465 +0100
@@ -7,8 +7,8 @@
# Uncomment when debugging
#set -x
-CONFIG_OPTIONS=--prefix=/usr shared no-idea no-rc5 no-mdc2
-INSTALL_PREFIX=/tmp/install
+CONFIG_OPTIONS=--prefix=/usr shared zlib no-idea no-rc5
+INSTALL_PREFIX=/tmp/install/INSTALL
VERSION=
SUBVERSION=$1
@@ -66,7 +66,7 @@ function create_cygwin_readme()
./config ${CONFIG_OPTIONS}
- The IDEA, RC5 and MDC2 algorithms are disabled due to patent and/or
+ The IDEA and RC5 algorithms are disabled due to patent and/or
licensing issues.
EOF
}
@@ -124,8 +124,12 @@ strip usr/bin/*.exe usr/bin/*.dll usr/li
chmod u-w usr/lib/engines/*.so
# Runtime package
-find etc usr/bin usr/lib/engines usr/share/doc usr/ssl/certs \
- usr/ssl/man/man[157] usr/ssl/misc usr/ssl/openssl.cnf usr/ssl/private \
+tar cjf libopenssl${VERSION//[!0-9]/}-${VERSION}-${SUBVERSION}.tar.bz2 \
+ usr/bin/cyg*dll
+# Base package
+find etc usr/bin/openssl.exe usr/bin/c_rehash usr/lib/engines usr/share/doc \
+ usr/ssl/certs usr/ssl/man/man[157] usr/ssl/misc usr/ssl/openssl.cnf \
+ usr/ssl/private \
-empty -o \! -type d |
tar cjfT openssl-${VERSION}-${SUBVERSION}.tar.bz2 -
# Development package
@@ -135,6 +139,7 @@ tar cjfT openssl-devel-${VERSION}-${SUBV
ls -l openssl-${VERSION}-${SUBVERSION}.tar.bz2
ls -l openssl-devel-${VERSION}-${SUBVERSION}.tar.bz2
+ls -l libopenssl${VERSION//[!0-9]/}-${VERSION}-${SUBVERSION}.tar.bz2
cleanup
--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #2471] [PATCH] util/cygwin.sh from CVS HEAD should be applied to 0.9.8 branch
Ping?
On Mar 17 12:44, Corinna Vinschen via RT wrote:
Hi,
would you mind to apply the below patch to util/cygwin.sh in the 0.9.8
branch, too? It has been applied only to HEAD, accidentally.
Thanks,
Corinna
--- openssl-0.9.8r/util/cygwin.sh 2005-06-23 22:55:35.0 +0200
+++ openssl-0.9.8r-1/util/cygwin.sh 2011-02-08 19:22:45.010931465 +0100
@@ -7,8 +7,8 @@
# Uncomment when debugging
#set -x
-CONFIG_OPTIONS=--prefix=/usr shared no-idea no-rc5 no-mdc2
-INSTALL_PREFIX=/tmp/install
+CONFIG_OPTIONS=--prefix=/usr shared zlib no-idea no-rc5
+INSTALL_PREFIX=/tmp/install/INSTALL
VERSION=
SUBVERSION=$1
@@ -66,7 +66,7 @@ function create_cygwin_readme()
./config ${CONFIG_OPTIONS}
- The IDEA, RC5 and MDC2 algorithms are disabled due to patent and/or
+ The IDEA and RC5 algorithms are disabled due to patent and/or
licensing issues.
EOF
}
@@ -124,8 +124,12 @@ strip usr/bin/*.exe usr/bin/*.dll usr/li
chmod u-w usr/lib/engines/*.so
# Runtime package
-find etc usr/bin usr/lib/engines usr/share/doc usr/ssl/certs \
- usr/ssl/man/man[157] usr/ssl/misc usr/ssl/openssl.cnf usr/ssl/private \
+tar cjf libopenssl${VERSION//[!0-9]/}-${VERSION}-${SUBVERSION}.tar.bz2 \
+ usr/bin/cyg*dll
+# Base package
+find etc usr/bin/openssl.exe usr/bin/c_rehash usr/lib/engines usr/share/doc \
+ usr/ssl/certs usr/ssl/man/man[157] usr/ssl/misc usr/ssl/openssl.cnf \
+ usr/ssl/private \
-empty -o \! -type d |
tar cjfT openssl-${VERSION}-${SUBVERSION}.tar.bz2 -
# Development package
@@ -135,6 +139,7 @@ tar cjfT openssl-devel-${VERSION}-${SUBV
ls -l openssl-${VERSION}-${SUBVERSION}.tar.bz2
ls -l openssl-devel-${VERSION}-${SUBVERSION}.tar.bz2
+ls -l libopenssl${VERSION//[!0-9]/}-${VERSION}-${SUBVERSION}.tar.bz2
cleanup
--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: Problem performing SSL handshake in FIPS mode
On Mon, May 16, 2011, Henrik Grindal Bakken wrote: Hi. I'm trying to test the current CVS HEAD with FIPS_set_module_mode(1). It's looking fairly promising to me, but I currently have one problem: While performing an SSL handshake, I get 1208113320:error:060A80A3:digital envelope routines:FIPS_DIGESTINIT:disabled for fips:fips_md.c:179: The rest of OpenSSL cannnot currently use the FIPS module correctly in all cases. You'll get quite a few problems like this. For now only the things in README.FIPS will work. This sounded a bit weird to me, since I've tried my best to set up my application to use only FIPS-validated algorithms, but to no avail. I added some debugging printouts to my libcrypto, and from what I could understand, the digest in question is MD5. When I patched openssl to say MD5 was a FIPS-approved digest, it worked. The program I'm using is attached, and also output from a separate 'openssl s_client -connect -showcerts'. Does anyone have any ideas as to why MD5 appears in this handshake? MD5 is a mandatory algorithm for TLS 1.1 and 1.0. As a result the use of MD5 is permitted solely for use in TLS in FIPS mode. Handling this requires some exception code in the ssl library which isn't currently in place for HEAD. 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
Re: [openssl.org #2470] [PATCH] Cygwin: Don't call ERR_remove_state from DllMain
On May 16 07:46, David Schwartz wrote: Shouldn't this code be removed on all platforms? It seems that the issue Cygwin is having could occur on any platform, perhaps it just happens not to on Win32 with the default locking callbacks. It should be obvious that calling any OpenSSL functions that require the locking callbacks to be intact would be illegal at thread attach time. That would give the application no opportunity to register the callbacks or set up any data structures they require. It seems the same argument should apply here. What if the application has already torn down the structures required to make the callbacks work? My understanding was that fundamentally, OpenSSL never ran any of its own threads or 'magically' called its own functions so the application had complete control over when OpenSSL functionality was invoked. This allows the application to set up and tear down any of the callback functions. This includes both the threaded functions and memory management. This seems a gratuitous violation of fundamental API design principles. The documentation at http://www.openssl.org/docs/crypto/ERR_remove_state.html says: Since error queue data structures are allocated automatically for new threads, they must be freed when threads are terminated in order to avoid memory leaks. So non-broken applications are already calling this function at a time they know it is safe to do so. Why call it at a potentially dangerous time outside of the control over the application that manages the library and thread lifetimes? I agree. I'm not sure this will potentially crash on native Win32, too. But I didn't want to break another platform so I just created a patch for Cygwin. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Need Help Using OpenSSL SHA 384 and ECDSA code from test drivers sha512.c and ecdsatest.c
I am using sha 384 and ECDSA code examples in test drivers sha512.c and ecdsatest.c as templates for test tool code. But cannot determine what the hash seed is for sha 384 or the parameters used by ecdsatest.c routines x9_62_tests and test_builtin. Can someone help me find these? Is there a Crypto User's Manual? Thanks, Fred Freitag
RE: We want to submit a patch to support VIA Padlock
Hi, Timo Thanks for your reply. I have made enhanved versions of the SHA support including partial Nano support and proper optimizations for the earlier variant that does finalizing hashing only. They are both on OpenSSL RT. Latest versions of my patch set for 1.0-branch is at: http://git.alpinelinux.org/cgit/aports.git/tree/main/openssl Please take a look at my SHA patches, they should implement everything properly. RNG patches you might need to fix. In fact, I have read your patch for SHA, and it seems to complete everythin. So my patch for SHA isimplemented based on it, and just a few modification is applied. If you don't mind, I would like to send my patch to you as soon as I finish it. 2. Thevia-mont.plseems no to be used, is there any taboo against it or some bad history I are missing ? If yes, please tell me. I think the OpenSSL core code is missing montgomery multiplication abstraction. It seems to be compile time option only to pick which implementation is used. So to get the montgomery stuff enabled by default, you'd probably also need to implement abstraction support for it. Thank you very much for your advice. I just have a basic knowledge of OpenSSL, so I do not understand what the abstraction means. I guess you mean that montgomery multiplication is not exported to developers as a interface, such as engine, so I have to implement by myself. If it is, that's really a tough problem for me. 3. If I want to submit a patch which implements modular multiplication and modular exponentiation by calling VIA PadLock hardware instruction, should I write it in a individual Perl script like via-mont.pl, or wrap it in the RSA/DSA method to be implemented in PadLock engine ? Or both are required? They work on different levels of the openssl library. Implementing via-mont.pl would be probably easier. Doing the implementation only in RSA/DSA method of the padlock module would enable the multiplication acceleration only for certain operations of the library. So I'd probably go with via-mont.pl and adding the required abstraction layer. That's a good news for me if you would like to go with the work for abstraction layer. Exactlly speaking, I just want to padlock engine in OpenSSL can use the hardware-implemented modular multiplication and modular exponentiation, so I prefer to doing the implemenation in RSA/DSA method of padlock engine. However, I have to use some individual asm files in my implementation such as supporting for WIN32 or WIN64, so perl script like via-mont.pl is also needed to generate cross-platform code. Do you have any suggestion on my implemenation? Thanks ! Thanks, Timo Regards, __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
