[openssl-commits] [openssl] master update
Rich Salz
rsalz at openssl.org
Fri Jul 31 16:29:47 UTC 2015
The branch master has been updated
via 740ceb5b0c844f1fe9b96983cc175d19795e7aa0 (commit)
from 898ea7b855541b5809e25944c8dada7b50775fd3 (commit)
- Log -----------------------------------------------------------------
commit 740ceb5b0c844f1fe9b96983cc175d19795e7aa0
Author: Rich Salz <rsalz at akamai.com>
Date: Fri Jul 31 11:52:57 2015 -0400
Various doc fixes from GH pull requests
Thanks folks:
348 Benjamin Kaduk
317 Christian Brueffer
254 Erik Tews
253 Erik Tews
219 Carl Mehner
155 (ghost)
95 mancha
51 DominikNeubauer
Reviewed-by: Dr. Stephen Henson <steve at openssl.org>
-----------------------------------------------------------------------
Summary of changes:
CHANGES | 2 +-
README | 2 +-
apps/s_client.c | 2 +-
doc/HOWTO/keys.txt | 5 ++---
doc/apps/pkcs12.pod | 2 +-
doc/apps/req.pod | 11 +++++------
doc/crypto/EVP_EncryptInit.pod | 2 +-
doc/crypto/EVP_SealInit.pod | 2 +-
doc/crypto/engine.pod | 10 +++++-----
9 files changed, 18 insertions(+), 20 deletions(-)
diff --git a/CHANGES b/CHANGES
index c5be241..cd75e0b 100644
--- a/CHANGES
+++ b/CHANGES
@@ -162,7 +162,7 @@
[mancha <mancha1 at zoho.com>]
*) Fix eckey_priv_encode so it immediately returns an error upon a failure
- in i2d_ECPrivateKey.
+ in i2d_ECPrivateKey. Thanks to Ted Unangst for feedback on this issue.
[mancha <mancha1 at zoho.com>]
*) Fix some double frees. These are not thought to be exploitable.
diff --git a/README b/README
index 40c2e83..13464f2 100644
--- a/README
+++ b/README
@@ -1,7 +1,7 @@
OpenSSL 1.1.0-dev
- Copyright (c) 1998-2011 The OpenSSL Project
+ Copyright (c) 1998-2015 The OpenSSL Project
Copyright (c) 1995-1998 Eric A. Young, Tim J. Hudson
All rights reserved.
diff --git a/apps/s_client.c b/apps/s_client.c
index a5fddca..f4132c8 100644
--- a/apps/s_client.c
+++ b/apps/s_client.c
@@ -588,7 +588,7 @@ OPTIONS s_client_options[] = {
"SRP username into second ClientHello message"},
{"srp_moregroups", OPT_SRP_MOREGROUPS, '-',
"Tolerate other than the known g N values."},
- {"srp_strength", OPT_SRP_STRENGTH, 'p', "Minimal mength in bits for N"},
+ {"srp_strength", OPT_SRP_STRENGTH, 'p', "Minimal length in bits for N"},
#endif
#ifndef OPENSSL_NO_NEXTPROTONEG
{"nextprotoneg", OPT_NEXTPROTONEG, 's',
diff --git a/doc/HOWTO/keys.txt b/doc/HOWTO/keys.txt
index 7ae2a3a..ba0314f 100644
--- a/doc/HOWTO/keys.txt
+++ b/doc/HOWTO/keys.txt
@@ -40,9 +40,8 @@ consider insecure or to be insecure pretty soon.
3. To generate a DSA key
-A DSA key can be used for signing only. This is important to keep
-in mind to know what kind of purposes a certificate request with a
-DSA key can really be used for.
+A DSA key can be used for signing only. It is important to
+know what a certificate request with a DSA key can really be used for.
Generating a key for the DSA algorithm is a two-step process. First,
you have to generate parameters from which to generate the key:
diff --git a/doc/apps/pkcs12.pod b/doc/apps/pkcs12.pod
index 8e0d917..7449848 100644
--- a/doc/apps/pkcs12.pod
+++ b/doc/apps/pkcs12.pod
@@ -216,7 +216,7 @@ key is encrypted using triple DES and the certificate using 40 bit RC2.
these options allow the algorithm used to encrypt the private key and
certificates to be selected. Any PKCS#5 v1.5 or PKCS#12 PBE algorithm name
-can be used (see B<NOTES> section for more information). If a a cipher name
+can be used (see B<NOTES> section for more information). If a cipher name
(as output by the B<list-cipher-algorithms> command is specified then it
is used with PKCS#5 v2.0. For interoperability reasons it is advisable to only
use PKCS#12 algorithms.
diff --git a/doc/apps/req.pod b/doc/apps/req.pod
index 9e8e1ab..2ce2bca 100644
--- a/doc/apps/req.pod
+++ b/doc/apps/req.pod
@@ -30,7 +30,6 @@ B<openssl> B<req>
[B<-keygen_engine id>]
[B<-[digest]>]
[B<-config filename>]
-[B<-subj arg>]
[B<-multivalue-rdn>]
[B<-x509>]
[B<-days n>]
@@ -506,16 +505,16 @@ Examine and verify certificate request:
Create a private key and then generate a certificate request from it:
- openssl genrsa -out key.pem 1024
+ openssl genrsa -out key.pem 2048
openssl req -new -key key.pem -out req.pem
The same but just using req:
- openssl req -newkey rsa:1024 -keyout key.pem -out req.pem
+ openssl req -newkey rsa:2048 -keyout key.pem -out req.pem
Generate a self signed root certificate:
- openssl req -x509 -newkey rsa:1024 -keyout key.pem -out req.pem
+ openssl req -x509 -newkey rsa:2048 -keyout key.pem -out req.pem
Example of a file pointed to by the B<oid_file> option:
@@ -531,7 +530,7 @@ expansion:
Sample configuration file prompting for field values:
[ req ]
- default_bits = 1024
+ default_bits = 2048
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
attributes = req_attributes
@@ -572,7 +571,7 @@ Sample configuration containing all field values:
RANDFILE = $ENV::HOME/.rnd
[ req ]
- default_bits = 1024
+ default_bits = 2048
default_keyfile = keyfile.pem
distinguished_name = req_distinguished_name
attributes = req_attributes
diff --git a/doc/crypto/EVP_EncryptInit.pod b/doc/crypto/EVP_EncryptInit.pod
index 6d897da..3dfc55d 100644
--- a/doc/crypto/EVP_EncryptInit.pod
+++ b/doc/crypto/EVP_EncryptInit.pod
@@ -114,7 +114,7 @@ EVP_CIPHER_CTX_init() initializes cipher contex B<ctx>.
EVP_EncryptInit_ex() sets up cipher context B<ctx> for encryption
with cipher B<type> from ENGINE B<impl>. B<ctx> must be initialized
before calling this function. B<type> is normally supplied
-by a function such as EVP_des_cbc(). If B<impl> is NULL then the
+by a function such as EVP_aes_256_cbc(). If B<impl> is NULL then the
default implementation is used. B<key> is the symmetric key to use
and B<iv> is the IV to use (if necessary), the actual number of bytes
used for the key and IV depends on the cipher. It is possible to set
diff --git a/doc/crypto/EVP_SealInit.pod b/doc/crypto/EVP_SealInit.pod
index 7d793e1..19112a5 100644
--- a/doc/crypto/EVP_SealInit.pod
+++ b/doc/crypto/EVP_SealInit.pod
@@ -25,7 +25,7 @@ encrypted using this key.
EVP_SealInit() initializes a cipher context B<ctx> for encryption
with cipher B<type> using a random secret key and IV. B<type> is normally
-supplied by a function such as EVP_des_cbc(). The secret key is encrypted
+supplied by a function such as EVP_aes_256_cbc(). The secret key is encrypted
using one or more public keys, this allows the same encrypted data to be
decrypted using any of the corresponding private keys. B<ek> is an array of
buffers where the public key encrypted secret key will be written, each buffer
diff --git a/doc/crypto/engine.pod b/doc/crypto/engine.pod
index 5eb065c..7f6cd43 100644
--- a/doc/crypto/engine.pod
+++ b/doc/crypto/engine.pod
@@ -192,7 +192,7 @@ to use the pointer value at all, as this kind of reference is a guarantee
that the structure can not be deallocated until the reference is released.
However, a structural reference provides no guarantee that the ENGINE is
-initiliased and able to use any of its cryptographic
+initialised and able to use any of its cryptographic
implementations. Indeed it's quite possible that most ENGINEs will not
initialise at all in typical environments, as ENGINEs are typically used to
support specialised hardware. To use an ENGINE's functionality, you need a
@@ -201,8 +201,8 @@ specialised form of structural reference, because each functional reference
implicitly contains a structural reference as well - however to avoid
difficult-to-find programming bugs, it is recommended to treat the two
kinds of reference independently. If you have a functional reference to an
-ENGINE, you have a guarantee that the ENGINE has been initialised ready to
-perform cryptographic operations and will remain uninitialised
+ENGINE, you have a guarantee that the ENGINE has been initialised and
+is ready to perform cryptographic operations, and will remain initialised
until after you have released your reference.
I<Structural references>
@@ -370,7 +370,7 @@ I<Using a specific ENGINE implementation>
Here we'll assume an application has been configured by its user or admin
to want to use the "ACME" ENGINE if it is available in the version of
OpenSSL the application was compiled with. If it is available, it should be
-used by default for all RSA, DSA, and symmetric cipher operation, otherwise
+used by default for all RSA, DSA, and symmetric cipher operations, otherwise
OpenSSL should use its builtin software as per usual. The following code
illustrates how to approach this;
@@ -401,7 +401,7 @@ I<Automatically using builtin ENGINE implementations>
Here we'll assume we want to load and register all ENGINE implementations
bundled with OpenSSL, such that for any cryptographic algorithm required by
-OpenSSL - if there is an ENGINE that implements it and can be initialise,
+OpenSSL - if there is an ENGINE that implements it and can be initialised,
it should be used. The following code illustrates how this can work;
/* Load all bundled ENGINEs into memory and make them visible */
More information about the openssl-commits
mailing list