From b680cf39ed5bc37e0eb7eb86ad8599bf92df3f2b Mon Sep 17 00:00:00 2001 From: marha Date: Sun, 23 Jan 2011 19:50:13 +0000 Subject: Updated to openssl-1.0.0c --- openssl/doc/apps/smime.pod | 8 ++++---- openssl/doc/crypto/EVP_PKEY_verify.pod | 2 +- openssl/doc/crypto/EVP_PKEY_verifyrecover.pod | 2 +- openssl/doc/ssl/SSL_CTX_set_options.pod | 13 +------------ 4 files changed, 7 insertions(+), 18 deletions(-) (limited to 'openssl/doc') diff --git a/openssl/doc/apps/smime.pod b/openssl/doc/apps/smime.pod index 42c0733bc..e4e89af84 100644 --- a/openssl/doc/apps/smime.pod +++ b/openssl/doc/apps/smime.pod @@ -343,7 +343,7 @@ Create a cleartext signed message: openssl smime -sign -in message.txt -text -out mail.msg \ -signer mycert.pem -Create an opaque signed message +Create an opaque signed message: openssl smime -sign -in message.txt -text -out mail.msg -nodetach \ -signer mycert.pem @@ -397,11 +397,11 @@ it with: -----BEGIN PKCS7----- -----END PKCS7----- -and using the command, +and using the command: openssl smime -verify -inform PEM -in signature.pem -content content.txt -alternatively you can base64 decode the signature and use +Alternatively you can base64 decode the signature and use: openssl smime -verify -inform DER -in signature.der -content content.txt @@ -427,7 +427,7 @@ Ideally a database should be maintained of a certificates for each email address. The code doesn't currently take note of the permitted symmetric encryption -algorithms as supplied in the SMIMECapabilities signed attribute. this means the +algorithms as supplied in the SMIMECapabilities signed attribute. This means the user has to manually include the correct encryption algorithm. It should store the list of permitted ciphers in a database and only use those. diff --git a/openssl/doc/crypto/EVP_PKEY_verify.pod b/openssl/doc/crypto/EVP_PKEY_verify.pod index 10633da3f..f93e5fc6c 100644 --- a/openssl/doc/crypto/EVP_PKEY_verify.pod +++ b/openssl/doc/crypto/EVP_PKEY_verify.pod @@ -69,7 +69,7 @@ Verify signature using PKCS#1 and SHA256 digest: /* Error */ /* Perform operation */ - ret = EVP_PKEY_verify(ctx, md, mdlen, sig, siglen); + ret = EVP_PKEY_verify(ctx, sig, siglen, md, mdlen); /* ret == 1 indicates success, 0 verify failure and < 0 for some * other error. diff --git a/openssl/doc/crypto/EVP_PKEY_verifyrecover.pod b/openssl/doc/crypto/EVP_PKEY_verifyrecover.pod index e2a2a8c6f..f3605eb82 100644 --- a/openssl/doc/crypto/EVP_PKEY_verifyrecover.pod +++ b/openssl/doc/crypto/EVP_PKEY_verifyrecover.pod @@ -74,7 +74,7 @@ Recover digest originally signed using PKCS#1 and SHA256 digest: /* Error */ /* Determine buffer length */ - if (EVP_PKEY_verifyrecover(ctx, rout, &routlen, sig, siglen) <= 0) + if (EVP_PKEY_verifyrecover(ctx, NULL, &routlen, sig, siglen) <= 0) /* Error */ rout = OPENSSL_malloc(routlen); diff --git a/openssl/doc/ssl/SSL_CTX_set_options.pod b/openssl/doc/ssl/SSL_CTX_set_options.pod index 310db84b3..cc588f3a7 100644 --- a/openssl/doc/ssl/SSL_CTX_set_options.pod +++ b/openssl/doc/ssl/SSL_CTX_set_options.pod @@ -78,18 +78,7 @@ this breaks this server so 16 bytes is the way to go. =item SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG -ssl3.netscape.com:443, first a connection is established with RC4-MD5. -If it is then resumed, we end up using DES-CBC3-SHA. It should be -RC4-MD5 according to 7.6.1.3, 'cipher_suite'. - -Netscape-Enterprise/2.01 (https://merchant.netscape.com) has this bug. -It only really shows up when connecting via SSLv2/v3 then reconnecting -via SSLv3. The cipher list changes.... - -NEW INFORMATION. Try connecting with a cipher list of just -DES-CBC-SHA:RC4-MD5. For some weird reason, each new connection uses -RC4-MD5, but a re-connect tries to use DES-CBC-SHA. So netscape, when -doing a re-connect, always takes the first cipher in the cipher list. +As of OpenSSL 0.9.8q and 1.0.0c, this option has no effect. =item SSL_OP_SSLREF2_REUSE_CERT_TYPE_BUG -- cgit v1.2.3