root
/
openssl
mirror of https://github.com/openssl/openssl.git
1
0
Fork 0
Code Issues Actions 7 Packages Projects Releases Wiki Activity

Fix typos and repeated words 

Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/12370)
This commit is contained in:
Gustaf Neumann 2020-07-04 21:58:30 +02:00 committed by Dr. Matthias St. Pierre
parent 7a989af738
commit 6328d3673f
143 changed files with 322 additions and 322 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
NOTES.ANDROID
View File

@ -6,8 +6,8 @@
-------------------
Beside basic tools like perl and make you'll need to download the Android
NDK. It's available for Linux, Mac OS X and Windows, but only Linux
version was actually tested. There is no reason to believe that Mac OS X
NDK. It's available for Linux, macOS and Windows, but only Linux
version was actually tested. There is no reason to believe that macOS
wouldn't work. And as for Windows, it's unclear which "shell" would be
suitable, MSYS2 might have best chances. NDK version should play lesser
role, the goal is to support a range of most recent versions.

2
NOTES.PERL
View File

@ -109,7 +109,7 @@
$ cpan -f -i Text::Template
Note: on VMS, you must quote any argument that contains upper case
Note: on VMS, you must quote any argument that contains uppercase
characters, so the lines above would be:
$ cpan -i "Text::Template"

2
NOTES.VMS
View File

@ -18,7 +18,7 @@
An ANSI C compiled is needed among other things. This means that
VAX C is not and will not be supported.
We have only tested with DEC C (a.k.a HP VMS C / VSI C) and require
We have only tested with DEC C (aka HP VMS C / VSI C) and require
version 7.1 or later. Compiling with a different ANSI C compiler may
require some work.

10
NOTES.WIN
View File

@ -12,11 +12,11 @@
and require --cross-compile-prefix option. While on MSYS[2] it's solved
rather by placing gcc that produces "MinGW binary" code 1st on $PATH.
This is customarily source of confusion. "Hosted" applications "live" in
emulated file system name space with POSIX-y root, mount points, /dev
emulated filesystem name space with POSIX-y root, mount points, /dev
and even /proc. Confusion is intensified by the fact that MSYS2 shell
(or rather emulated execve(2) call) examines the binary it's about to
start, and if it's found *not* to be linked with MSYS2 POSIX-y thing,
command line arguments that look like file names get translated from
command line arguments that look like filenames get translated from
emulated name space to "native". For example '/c/some/where' becomes
'c:\some\where', '/dev/null' - 'nul'. This creates an illusion that
there is no difference between MSYS2 shell and "MinGW binary", but
@ -26,7 +26,7 @@
it's referred to in quotes here, as "MinGW binary", it's just as
"native" as it can get.)
Visual C++ builds, a.k.a. VC-*
Visual C++ builds, aka VC-*
==============================
Requirement details
@ -47,7 +47,7 @@
the other hand oldest one is known not to work. Everything between
falls into best-effort category.
- Netwide Assembler, a.k.a. NASM, available from https://www.nasm.us,
- Netwide Assembler, aka NASM, available from https://www.nasm.us,
is required. Note that NASM is the only supported assembler. Even
though Microsoft provided assembler is NOT supported, contemporary
64-bit version is exercised through continuous integration of
@ -132,7 +132,7 @@
If you link with static OpenSSL libraries then you're expected to
additionally link your application with WS2_32.LIB, GDI32.LIB,
ADVAPI32.LIB, CRYPT32.LIB and USER32.LIB. Those developing
non-interactive service applications might feel concerned about
noninteractive service applications might feel concerned about
linking with GDI32.LIB and USER32.LIB, as they are justly associated
with interactive desktop, which is not available to service
processes. The toolkit is designed to detect in which context it's

2
doc/man1/CA.pl.pod
View File

@ -164,7 +164,7 @@ Create the CA directories and files:
CA.pl -newca
enter cacert.pem when prompted for the CA file name.
enter cacert.pem when prompted for the CA filename.
Create a DSA certificate request and private key (a different set of parameters
can optionally be created first):

2
doc/man1/ca.pod
View File

@ -219,7 +219,7 @@ DNs match the order of the request. This is not needed for Xenroll.
=item B<-noemailDN>
The DN of a certificate can contain the EMAIL field if present in the
request DN, however it is good policy just having the e-mail set into
request DN, however, it is good policy just having the e-mail set into
the altName extension of the certificate. When this option is set the
EMAIL field is removed from the certificate' subject and set only in
the, eventually present, extensions. The B<email_in_dn> keyword can be

2
doc/man1/enc.pod
View File

@ -240,7 +240,7 @@ a strong block cipher, such as AES, in CBC mode.
All the block ciphers normally use PKCS#5 padding, also known as standard
block padding. This allows a rudimentary integrity or password check to
be performed. However since the chance of random data passing the test
be performed. However, since the chance of random data passing the test
is better than 1 in 256 it isn't a very good test.
If padding is disabled then the input data must be a multiple of the cipher

2
doc/man1/ocsp.pod
View File

@ -176,7 +176,7 @@ Specify the responder URL. Both HTTP and HTTPS (SSL/TLS) URLs can be specified.
=item B<-host hostname:port>, B<-path pathname>
If the B<host> option is present then the OCSP request is sent to the host
B<hostname> on port B<port>. B<path> specifies the HTTP path name to use
B<hostname> on port B<port>. B<path> specifies the HTTP pathname to use
or "/" by default. This is equivalent to specifying B<-url> with scheme
http:// and the given hostname, port, and pathname.

2
doc/man1/pkcs12.pod
View File

@ -245,7 +245,7 @@ This option is only interpreted by MSIE and similar MS software. Normally
encryption purposes but arbitrary length keys for signing. The B<-keysig>
option marks the key for signing only. Signing only keys can be used for
S/MIME signing, authenticode (ActiveX control signing) and SSL client
authentication, however due to a bug only MSIE 5.0 and later support
authentication, however, due to a bug only MSIE 5.0 and later support
the use of signing only keys for SSL client authentication.
=item B<-macalg digest>

2
doc/man1/pkcs8.pod
View File

@ -285,7 +285,7 @@ one million iterations of the password:
Test vectors from this PKCS#5 v2.0 implementation were posted to the
pkcs-tng mailing list using triple DES, DES and RC2 with high iteration
counts, several people confirmed that they could decrypt the private
keys produced and Therefore it can be assumed that the PKCS#5 v2.0
keys produced and therefore, it can be assumed that the PKCS#5 v2.0
implementation is reasonably accurate at least as far as these
algorithms are concerned.

2
doc/man1/pkeyutl.pod
View File

@ -38,7 +38,7 @@ B<openssl> B<pkeyutl>
=head1 DESCRIPTION
The B<pkeyutl> command can be used to perform low level public key operations
The B<pkeyutl> command can be used to perform low-level public key operations
using any supported algorithm.
=head1 OPTIONS

8
doc/man1/s_client.pod
View File

@ -427,11 +427,11 @@ File to send output of B<-msg> or B<-trace> to, default standard output.
=item B<-nbio_test>
Tests non-blocking I/O
Tests nonblocking I/O
=item B<-nbio>
Turns on non-blocking I/O
Turns on nonblocking I/O
=item B<-crlf>
@ -781,14 +781,14 @@ is that a web client complains it has no certificates or gives an empty
list to choose from. This is normally because the server is not sending
the clients certificate authority in its "acceptable CA list" when it
requests a certificate. By using B<s_client> the CA list can be viewed
and checked. However some servers only request client authentication
and checked. However, some servers only request client authentication
after a specific URL is requested. To obtain the list in this case it
is necessary to use the B<-prexit> option and send an HTTP request
for an appropriate page.
If a certificate is specified on the command line using the B<-cert>
option it will not be used unless the server specifically requests
a client certificate. Therefore merely including a client certificate
a client certificate. Therefore, merely including a client certificate
on the command line is no guarantee that the certificate works.
If there are problems verifying a server certificate then the

4
doc/man1/s_server.pod
View File

@ -432,9 +432,9 @@ used in conjunction with B<-early_data>.
=item B<-id_prefix val>
Generate SSL/TLS session IDs prefixed by B<val>. This is mostly useful
for testing any SSL/TLS code (eg. proxies) that wish to deal with multiple
for testing any SSL/TLS code (e.g. proxies) that wish to deal with multiple
servers, when each of which might be generating a unique range of session
IDs (eg. with a certain prefix).
IDs (e.g. with a certain prefix).
=item B<-rand file...>

4
doc/man1/s_time.pod
View File

@ -177,14 +177,14 @@ is that a web client complains it has no certificates or gives an empty
list to choose from. This is normally because the server is not sending
the clients certificate authority in its "acceptable CA list" when it
requests a certificate. By using L<s_client(1)> the CA list can be
viewed and checked. However some servers only request client authentication
viewed and checked. However, some servers only request client authentication
after a specific URL is requested. To obtain the list in this case it
is necessary to use the B<-prexit> option of L<s_client(1)> and
send an HTTP request for an appropriate page.
If a certificate is specified on the command line using the B<-cert>
option it will not be used unless the server specifically requests
a client certificate. Therefore merely including a client certificate
a client certificate. Therefore, merely including a client certificate
on the command line is no guarantee that the certificate works.
=head1 BUGS

2
doc/man1/sess_id.pod
View File

@ -142,7 +142,7 @@ The PEM encoded session format uses the header and footer lines:
Since the SSL session output contains the master key it is
possible to read the contents of an encrypted session using this
information. Therefore appropriate security precautions should be taken if
information. Therefore, appropriate security precautions should be taken if
the information is being output by a "real" application. This is however
strongly discouraged and should only be used for debugging purposes.

92
doc/man1/ts.pod
View File

@ -101,23 +101,23 @@ the hash to the TSA.
=item 2.
The TSA attaches the current date and time to the received hash value,
signs them and sends the time stamp token back to the client. By
signs them and sends the timestamp token back to the client. By
creating this token the TSA certifies the existence of the original
data file at the time of response generation.
=item 3.
The TSA client receives the time stamp token and verifies the
The TSA client receives the timestamp token and verifies the
signature on it. It also checks if the token contains the same hash
value that it had sent to the TSA.
=back
There is one DER encoded protocol data unit defined for transporting a time
stamp request to the TSA and one for sending the time stamp response
There is one DER encoded protocol data unit defined for transporting
a timestamp request to the TSA and one for sending the timestamp response
back to the client. The B<ts> command has three main functions:
creating a time stamp request based on a data file,
creating a time stamp response based on a request, verifying if a
creating a timestamp request based on a data file,
creating a timestamp response based on a request, verifying if a
response corresponds to a particular request or a data file.
There is no support for sending the requests/responses automatically
@ -128,7 +128,7 @@ requests either by ftp or e-mail.
=head2 Time Stamp Request generation
The B<-query> switch can be used for creating and printing a time stamp
The B<-query> switch can be used for creating and printing a timestamp
request with the following options:
=over 4
@ -154,7 +154,7 @@ see L<openssl(1)/COMMAND SUMMARY>.
=item B<-data> file_to_hash
The data file for which the time stamp request needs to be
The data file for which the timestamp request needs to be
created. stdin is the default if neither the B<-data> nor the B<-digest>
parameter is specified. (Optional)
@ -175,7 +175,7 @@ The default is SHA-1. (Optional)
=item B<-tspolicy> object_id
The policy that the client expects the TSA to use for creating the
time stamp token. Either the dotted OID notation or OID names defined
timestamp token. Either the dotted OID notation or OID names defined
in the config file can be used. If no policy is requested the TSA will
use its own default policy. (Optional)
@ -193,7 +193,7 @@ response. (Optional)
=item B<-in> request.tsq
This option specifies a previously created time stamp request in DER
This option specifies a previously created timestamp request in DER
format that will be printed into the output file. Useful when you need
to examine the content of a request in human-readable
format. (Optional)
@ -212,13 +212,13 @@ instead of DER. (Optional)
=head2 Time Stamp Response generation
A time stamp response (TimeStampResp) consists of a response status
and the time stamp token itself (ContentInfo), if the token generation was
successful. The B<-reply> command is for creating a time stamp
response or time stamp token based on a request and printing the
A timestamp response (TimeStampResp) consists of a response status
and the timestamp token itself (ContentInfo), if the token generation was
successful. The B<-reply> command is for creating a timestamp
response or timestamp token based on a request and printing the
response/token in human-readable format. If B<-token_out> is not
specified the output is always a time stamp response (TimeStampResp),
otherwise it is a time stamp token (ContentInfo).
specified the output is always a timestamp response (TimeStampResp),
otherwise it is a timestamp token (ContentInfo).
=over 4
@ -237,7 +237,7 @@ used, see B<CONFIGURATION FILE OPTIONS> for details. (Optional)
=item B<-queryfile> request.tsq
The name of the file containing a DER encoded time stamp request. (Optional)
The name of the file containing a DER encoded timestamp request. (Optional)
=item B<-passin> password_src
@ -282,19 +282,19 @@ B<default_policy> config file option. (Optional)
=item B<-in> response.tsr
Specifies a previously created time stamp response or time stamp token
Specifies a previously created timestamp response or timestamp token
(if B<-token_in> is also specified) in DER format that will be written
to the output file. This option does not require a request, it is
useful e.g. when you need to examine the content of a response or
token or you want to extract the time stamp token from a response. If
the input is a token and the output is a time stamp response a default
token or you want to extract the timestamp token from a response. If
the input is a token and the output is a timestamp response a default
'granted' status info is added to the token. (Optional)
=item B<-token_in>
This flag can be used together with the B<-in> option and indicates
that the input is a DER encoded time stamp token (ContentInfo) instead
of a time stamp response (TimeStampResp). (Optional)
that the input is a DER encoded timestamp token (ContentInfo) instead
of a timestamp response (TimeStampResp). (Optional)
=item B<-out> response.tsr
@ -304,7 +304,7 @@ stdout. (Optional)
=item B<-token_out>
The output is a time stamp token (ContentInfo) instead of time stamp
The output is a timestamp token (ContentInfo) instead of timestamp
response (TimeStampResp). (Optional)
=item B<-text>
@ -323,8 +323,8 @@ for all available algorithms. Default is builtin. (Optional)
=head2 Time Stamp Response verification
The B<-verify> command is for verifying if a time stamp response or time
stamp token is valid and matches a particular time stamp request or
The B<-verify> command is for verifying if a timestamp response or
timestamp token is valid and matches a particular timestamp request or
data file. The B<-verify> command does not use the configuration file.
=over 4
@ -345,18 +345,18 @@ specified with this one. (Optional)
=item B<-queryfile> request.tsq
The original time stamp request in DER format. The B<-data> and B<-digest>
The original timestamp request in DER format. The B<-data> and B<-digest>
options must not be specified with this one. (Optional)
=item B<-in> response.tsr
The time stamp response that needs to be verified in DER format. (Mandatory)
The timestamp response that needs to be verified in DER format. (Mandatory)
=item B<-token_in>
This flag can be used together with the B<-in> option and indicates
that the input is a DER encoded time stamp token (ContentInfo) instead
of a time stamp response (TimeStampResp). (Optional)
that the input is a DER encoded timestamp token (ContentInfo) instead
of a timestamp response (TimeStampResp). (Optional)
=item B<-CApath> trusted_cert_path
@ -430,7 +430,7 @@ See L<ca(1)> for description. (Optional)
=item B<serial>
The name of the file containing the hexadecimal serial number of the
last time stamp response created. This number is incremented by 1 for
last timestamp response created. This number is incremented by 1 for
each response. If the file does not exist at the time of response
generation a new file is created with serial number 1. (Mandatory)
@ -487,7 +487,7 @@ the components is missing zero is assumed for that field. (Optional)
=item B<clock_precision_digits>
Specifies the maximum number of digits, which represent the fraction of
seconds, that need to be included in the time field. The trailing zeroes
seconds, that need to be included in the time field. The trailing zeros
must be removed from the time, so there might actually be fewer digits,
or no fraction of seconds at all. Supported only on UNIX platforms.
The maximum value is 6, default is 0.
@ -530,13 +530,13 @@ openssl/apps/openssl.cnf will do.
=head2 Time Stamp Request
To create a time stamp request for design1.txt with SHA-1
To create a timestamp request for design1.txt with SHA-1
without nonce and policy and no certificate is required in the response:
openssl ts -query -data design1.txt -no_nonce \
-out design1.tsq
To create a similar time stamp request with specifying the message imprint
To create a similar timestamp request with specifying the message imprint
explicitly:
openssl ts -query -digest b7e5d3f93198b38379852f2c04e78d73abdd0f4b \
@ -546,7 +546,7 @@ To print the content of the previous request in human readable format:
openssl ts -query -in design1.tsq -text
To create a time stamp request which includes the MD-5 digest
To create a timestamp request which includes the MD-5 digest
of design2.txt, requests the signer certificate and nonce,
specifies a policy id (assuming the tsa_policy1 name is defined in the
OID section of the config file):
@ -568,7 +568,7 @@ below assume that cacert.pem contains the certificate of the CA,
tsacert.pem is the signing certificate issued by cacert.pem and
tsakey.pem is the private key of the TSA.
To create a time stamp response for a request:
To create a timestamp response for a request:
openssl ts -reply -queryfile design1.tsq -inkey tsakey.pem \
-signer tsacert.pem -out design1.tsr
@ -577,44 +577,44 @@ If you want to use the settings in the config file you could just write:
openssl ts -reply -queryfile design1.tsq -out design1.tsr
To print a time stamp reply to stdout in human readable format:
To print a timestamp reply to stdout in human readable format:
openssl ts -reply -in design1.tsr -text
To create a time stamp token instead of time stamp response:
To create a timestamp token instead of timestamp response:
openssl ts -reply -queryfile design1.tsq -out design1_token.der -token_out
To print a time stamp token to stdout in human readable format:
To print a timestamp token to stdout in human readable format:
openssl ts -reply -in design1_token.der -token_in -text -token_out
To extract the time stamp token from a response:
To extract the timestamp token from a response:
openssl ts -reply -in design1.tsr -out design1_token.der -token_out
To add 'granted' status info to a time stamp token thereby creating a
To add 'granted' status info to a timestamp token thereby creating a
valid response:
openssl ts -reply -in design1_token.der -token_in -out design1.tsr
=head2 Time Stamp Verification
To verify a time stamp reply against a request:
To verify a timestamp reply against a request:
openssl ts -verify -queryfile design1.tsq -in design1.tsr \
-CAfile cacert.pem -untrusted tsacert.pem
To verify a time stamp reply that includes the certificate chain:
To verify a timestamp reply that includes the certificate chain:
openssl ts -verify -queryfile design2.tsq -in design2.tsr \
-CAfile cacert.pem
To verify a time stamp token against the original data file:
To verify a timestamp token against the original data file:
openssl ts -verify -data design2.txt -in design2.tsr \
-CAfile cacert.pem
To verify a time stamp token against a message imprint:
To verify a timestamp token against a message imprint:
openssl ts -verify -digest b7e5d3f93198b38379852f2c04e78d73abdd0f4b \
-in design2.tsr -CAfile cacert.pem
@ -628,7 +628,7 @@ You could also look at the 'test' directory for more examples.
=item *
No support for time stamps over SMTP, though it is quite easy
No support for timestamps over SMTP, though it is quite easy
to implement an automatic e-mail based TSA with L<procmail(1)>
and L<perl(1)>. HTTP server support is provided in the form of
a separate apache module. HTTP client support is provided by
@ -638,7 +638,7 @@ L<tsget(1)>. Pure TCP/IP protocol is not supported.
The file containing the last serial number of the TSA is not
locked when being read or written. This is a problem if more than one
instance of L<openssl(1)> is trying to create a time stamp
instance of L<openssl(1)> is trying to create a timestamp
response at the same time. This is not an issue when using the apache
server module, it does proper locking.

28
doc/man1/tsget.pod
View File

@ -24,15 +24,15 @@ B<-h> server_url
=head1 DESCRIPTION
The B<tsget> command can be used for sending a time stamp request, as
specified in B<RFC 3161>, to a time stamp server over HTTP or HTTPS and storing
the time stamp response in a file. This tool cannot be used for creating the
The B<tsget> command can be used for sending a timestamp request, as
specified in B<RFC 3161>, to a timestamp server over HTTP or HTTPS and storing
the timestamp response in a file. This tool cannot be used for creating the
requests and verifying responses, you can use the OpenSSL B<ts(1)> command to
do that. B<tsget> can send several requests to the server without closing
the TCP connection if more than one requests are specified on the command
line.
The tool sends the following HTTP request for each time stamp request:
The tool sends the following HTTP request for each timestamp request:
POST url HTTP/1.1
User-Agent: OpenTSA tsget.pl/<version>
@ -53,7 +53,7 @@ written to a file without any interpretation.
=item B<-h> server_url
The URL of the HTTP/HTTPS server listening for time stamp requests.
The URL of the HTTP/HTTPS server listening for timestamp requests.
=item B<-e> extension
@ -64,8 +64,8 @@ the input files. Default extension is '.tsr'. (Optional)
=item B<-o> output
This option can be specified only when just one request is sent to the
server. The time stamp response will be written to the given output file. '-'
means standard output. In case of multiple time stamp requests or the absence
server. The timestamp response will be written to the given output file. '-'
means standard output. In case of multiple timestamp requests or the absence
of this argument the names of the output files will be derived from the names
of the input files and the default or specified extension argument. (Optional)
@ -124,7 +124,7 @@ The name of an EGD socket to get random data from. (Optional)
=item [request]...
List of files containing B<RFC 3161> DER-encoded time stamp requests. If no
List of files containing B<RFC 3161> DER-encoded timestamp requests. If no
requests are specified only one request will be sent to the server and it will be
read from the standard input. (Optional)
@ -139,35 +139,35 @@ arguments.
=head1 EXAMPLES
The examples below presume that B<file1.tsq> and B<file2.tsq> contain valid
time stamp requests, tsa.opentsa.org listens at port 8080 for HTTP requests
timestamp requests, tsa.opentsa.org listens at port 8080 for HTTP requests
and at port 8443 for HTTPS requests, the TSA service is available at the /tsa
absolute path.
Get a time stamp response for file1.tsq over HTTP, output is written to
Get a timestamp response for file1.tsq over HTTP, output is written to
file1.tsr:
tsget -h http://tsa.opentsa.org:8080/tsa file1.tsq
Get a time stamp response for file1.tsq and file2.tsq over HTTP showing
Get a timestamp response for file1.tsq and file2.tsq over HTTP showing
progress, output is written to file1.reply and file2.reply respectively:
tsget -h http://tsa.opentsa.org:8080/tsa -v -e .reply \
file1.tsq file2.tsq
Create a time stamp request, write it to file3.tsq, send it to the server and
Create a timestamp request, write it to file3.tsq, send it to the server and
write the response to file3.tsr:
openssl ts -query -data file3.txt -cert | tee file3.tsq \
| tsget -h http://tsa.opentsa.org:8080/tsa \
-o file3.tsr
Get a time stamp response for file1.tsq over HTTPS without client
Get a timestamp response for file1.tsq over HTTPS without client
authentication:
tsget -h https://tsa.opentsa.org:8443/tsa \
-C cacerts.pem file1.tsq
Get a time stamp response for file1.tsq over HTTPS with certificate-based
Get a timestamp response for file1.tsq over HTTPS with certificate-based
client authentication (it will ask for the passphrase if client_key.pem is
protected):

2
doc/man1/verify.pod
View File

@ -336,7 +336,7 @@ in PEM format.
=head1 VERIFY OPERATION
The B<verify> program uses the same functions as the internal SSL and S/MIME
verification, therefore this description applies to these verify operations
verification, therefore, this description applies to these verify operations
too.
There is one crucial difference between the verify operations performed

2
doc/man1/x509.pod
View File

@ -255,7 +255,7 @@ Prints out the start and expiry dates of a certificate.
=item B<-checkend arg>
Checks if the certificate expires within the next B<arg> seconds and exits
non-zero if yes it will expire or zero if not.
nonzero if yes it will expire or zero if not.
=item B<-fingerprint>

2
doc/man3/ASN1_INTEGER_get_int64.pod
View File

@ -81,7 +81,7 @@ instead.
In general an B<ASN1_INTEGER> or B<ASN1_ENUMERATED> type can contain an
integer of almost arbitrary size and so cannot always be represented by a C
B<int64_t> type. However in many cases (for example version numbers) they
B<int64_t> type. However, in many cases (for example version numbers) they
represent small integers which can be more easily manipulated if converted to
an appropriate C integer type.

2
doc/man3/ASN1_STRING_length.pod
View File

@ -72,7 +72,7 @@ In general it cannot be assumed that the data returned by ASN1_STRING_data()
is null terminated or does not contain embedded nulls. The actual format
of the data will depend on the actual string type itself: for example
for an IA5String the data will be ASCII, for a BMPString two bytes per
character in big endian format, and for an UTF8String it will be in UTF8 format.
character in big endian format, and for a UTF8String it will be in UTF8 format.
Similar care should be take to ensure the data is in the correct format
when calling ASN1_STRING_set().

4
doc/man3/ASN1_TIME_set.pod
View File

@ -117,7 +117,7 @@ one or both (depending on the time difference) of B<*pday> and B<*psec>
will be positive. If B<to> represents a time earlier than B<from> then
one or both of B<*pday> and B<*psec> will be negative. If B<to> and B<from>
represent the same time then B<*pday> and B<*psec> will both be zero.
If both B<*pday> and B<*psec> are non-zero they will always have the same
If both B<*pday> and B<*psec> are nonzero they will always have the same
sign. The value of B<*psec> will always be less than the number of seconds
in a day. If B<from> or B<to> is NULL the current time is used.
@ -167,7 +167,7 @@ format.
=head1 BUGS
ASN1_TIME_print(), ASN1_UTCTIME_print() and ASN1_GENERALIZEDTIME_print()
do not print out the time zone: it either prints out "GMT" or nothing. But all
do not print out the timezone: it either prints out "GMT" or nothing. But all
certificates complying with RFC5280 et al use GMT anyway.
Use the ASN1_TIME_normalize() function to normalize the time value before

10
doc/man3/ASN1_TYPE_get.pod
View File

@ -33,7 +33,7 @@ up after the call.
ASN1_TYPE_set1() sets the value of B<a> to B<type> a copy of B<value>.
ASN1_TYPE_cmp() compares ASN.1 types B<a> and B<b> and returns 0 if
they are identical and non-zero otherwise.
they are identical and nonzero otherwise.
ASN1_TYPE_unpack_sequence() attempts to parse the SEQUENCE present in
B<t> using the ASN.1 structure B<it>. If successful it returns a pointer
@ -62,12 +62,12 @@ length octets).
ASN1_TYPE_cmp() may not return zero if two types are equivalent but have
different encodings. For example the single content octet of the boolean TRUE
value under BER can have any non-zero encoding but ASN1_TYPE_cmp() will
value under BER can have any nonzero encoding but ASN1_TYPE_cmp() will
only return zero if the values are the same.
If either or both of the parameters passed to ASN1_TYPE_cmp() is NULL the
return value is non-zero. Technically if both parameters are NULL the two
types could be absent OPTIONAL fields and so should match, however passing
return value is nonzero. Technically if both parameters are NULL the two
types could be absent OPTIONAL fields and so should match, however, passing
NULL values could also indicate a programming error (for example an
unparsable type which returns NULL) for types which do B<not> match. So
applications should handle the case of two absent values separately.
@ -80,7 +80,7 @@ ASN1_TYPE_set() does not return a value.
ASN1_TYPE_set1() returns 1 for success and 0 for failure.
ASN1_TYPE_cmp() returns 0 if the types are identical and non-zero otherwise.
ASN1_TYPE_cmp() returns 0 if the types are identical and nonzero otherwise.
ASN1_TYPE_unpack_sequence() returns a pointer to an ASN.1 structure or
NULL on failure.

4
doc/man3/ASYNC_WAIT_CTX_new.pod
View File

@ -50,7 +50,7 @@ job in B<*fd>. The number of file descriptors returned will be stored in
B<*numfds>. It is the caller's responsibility to ensure that sufficient memory
has been allocated in B<*fd> to receive all the file descriptors. Calling
ASYNC_WAIT_CTX_get_all_fds() with a NULL B<fd> value will return no file
descriptors but will still populate B<*numfds>. Therefore application code is
descriptors but will still populate B<*numfds>. Therefore, application code is
typically expected to call this function twice: once to get the number of fds,
and then again when sufficient memory has been allocated. If only one
asynchronous engine is being used then normally this call will only ever return
@ -117,7 +117,7 @@ success or 0 on error.
On Windows platforms the openssl/async.h header is dependent on some
of the types customarily made available by including windows.h. The
application developer is likely to require control over when the latter
is included, commonly as one of the first included headers. Therefore
is included, commonly as one of the first included headers. Therefore,
it is defined as an application developer's responsibility to include
windows.h prior to async.h.

2
doc/man3/ASYNC_start_job.pod
View File

@ -166,7 +166,7 @@ otherwise.
On Windows platforms the openssl/async.h header is dependent on some
of the types customarily made available by including windows.h. The
application developer is likely to require control over when the latter
is included, commonly as one of the first included headers. Therefore
is included, commonly as one of the first included headers. Therefore,
it is defined as an application developer's responsibility to include
windows.h prior to async.h.

2
doc/man3/BF_encrypt.pod
View File

@ -60,7 +60,7 @@ recipient needs to know what it was initialized with, or it won't be able
to decrypt. Some programs and protocols simplify this, like SSH, where
B<ivec> is simply initialized to zero.
BF_cbc_encrypt() operates on data that is a multiple of 8 bytes long, while
BF_cfb64_encrypt() and BF_ofb64_encrypt() are used to encrypt an variable
BF_cfb64_encrypt() and BF_ofb64_encrypt() are used to encrypt a variable
number of bytes (the amount does not have to be an exact multiple of 8). The
purpose of the latter two is to simulate stream ciphers, and therefore, they
need the parameter B<num>, which is a pointer to an integer where the current

2
doc/man3/BIO_ADDR.pod
View File

@ -42,7 +42,7 @@ BIO_ADDR_free() frees a B<BIO_ADDR> created with BIO_ADDR_new().
BIO_ADDR_clear() clears any data held within the provided B<BIO_ADDR> and sets
it back to an uninitialised state.
BIO_ADDR_rawmake() takes a protocol B<family>, an byte array of
BIO_ADDR_rawmake() takes a protocol B<family>, a byte array of
size B<wherelen> with an address in network byte order pointed at
by B<where> and a port number in network byte order in B<port> (except
for the B<AF_UNIX> protocol family, where B<port> is meaningless and

2
doc/man3/BIO_ADDRINFO.pod
View File

@ -94,7 +94,7 @@ information they should return isn't available.
The BIO_lookup_ex() implementation uses the platform provided getaddrinfo()
function. On Linux it is known that specifying 0 for the protocol will not
return any SCTP based addresses when calling getaddrinfo(). Therefore if an SCTP
return any SCTP based addresses when calling getaddrinfo(). Therefore, if an SCTP
address is required then the B<protocol> parameter to BIO_lookup_ex() should be
explicitly set to IPPROTO_SCTP. The same may be true on other platforms.

2
doc/man3/BIO_connect.pod
View File

@ -55,7 +55,7 @@ Enables regular sending of keep-alive messages.
=item BIO_SOCK_NONBLOCK
Sets the socket to non-blocking mode.
Sets the socket to nonblocking mode.
=item BIO_SOCK_NODELAY

2
doc/man3/BIO_ctrl.pod
View File

@ -109,7 +109,7 @@ Filter BIOs if they do not internally handle a particular BIO_ctrl()
operation usually pass the operation to the next BIO in the chain.
This often means there is no need to locate the required BIO for
a particular operation, it can be called on a chain and it will
be automatically passed to the relevant BIO. However this can cause
be automatically passed to the relevant BIO. However, this can cause
unexpected results: for example no current filter BIOs implement
BIO_seek(), but this may still succeed if the chain ends in a FILE
or file descriptor BIO.

2
doc/man3/BIO_get_data.pod
View File

@ -25,7 +25,7 @@ the BIO. This data can subsequently be retrieved via a call to BIO_get_data().
This can be used by custom BIOs for storing implementation specific information.
The BIO_set_init() function sets the value of the BIO's "init" flag to indicate
whether initialisation has been completed for this BIO or not. A non-zero value
whether initialisation has been completed for this BIO or not. A nonzero value
indicates that initialisation is complete, whilst zero indicates that it is not.
Often initialisation will complete during initial construction of the BIO. For
some BIOs however, initialisation may not complete until after additional steps

4
doc/man3/BIO_parse_hostserv.pod
View File

@ -19,10 +19,10 @@ BIO_parse_hostserv
=head1 DESCRIPTION
BIO_parse_hostserv() will parse the information given in B<hostserv>,
create strings with the host name and service name and give those
create strings with the hostname and service name and give those
back via B<host> and B<service>. Those will need to be freed after
they are used. B<hostserv_prio> helps determine if B<hostserv> shall
be interpreted primarily as a host name or a service name in ambiguous
be interpreted primarily as a hostname or a service name in ambiguous
cases.
The syntax the BIO_parse_hostserv() recognises is:

2
doc/man3/BIO_read.pod
View File

@ -55,7 +55,7 @@ NUL is not included in the length returned by BIO_gets().
=head1 NOTES
A 0 or -1 return is not necessarily an indication of an error. In
particular when the source/sink is non-blocking or of a certain type
particular when the source/sink is nonblocking or of a certain type
it may merely be an indication that no data is currently available and that
the application should retry the operation later.

2
doc/man3/BIO_s_accept.pod
View File

@ -143,7 +143,7 @@ however because the accept BIO will still accept additional incoming
connections. This can be resolved by using BIO_pop() (see above)
and freeing up the accept BIO after the initial connection.
If the underlying accept socket is non-blocking and BIO_do_accept() is
If the underlying accept socket is nonblocking and BIO_do_accept() is
called to await an incoming connection it is possible for
BIO_should_io_special() with the reason BIO_RR_ACCEPT. If this happens
then it is an indication that an accept attempt would block: the application

4
doc/man3/BIO_s_bio.pod
View File

@ -144,7 +144,7 @@ without having to go through the SSL-interface.
...
BIO_new_bio_pair(&internal_bio, 0, &network_bio, 0);
SSL_set_bio(ssl, internal_bio, internal_bio);
SSL_operations(); /* e.g SSL_read and SSL_write */
SSL_operations(); /* e.g. SSL_read and SSL_write */
...
application | TLS-engine
@ -167,7 +167,7 @@ without having to go through the SSL-interface.
...
As the BIO pair will only buffer the data and never directly access the
connection, it behaves non-blocking and will return as soon as the write
connection, it behaves nonblocking and will return as soon as the write
buffer is full or the read buffer is drained. Then the application has to
flush the write buffer and/or fill the read buffer.

2
doc/man3/BIO_s_connect.pod
View File

@ -106,7 +106,7 @@ If blocking I/O is set then a non positive return value from any
I/O call is caused by an error condition, although a zero return
will normally mean that the connection was closed.
If the port name is supplied as part of the host name then this will
If the port name is supplied as part of the hostname then this will
override any value set with BIO_set_conn_port(). This may be undesirable
if the application does not wish to allow connection to arbitrary
ports. This can be avoided by checking for the presence of the ':'

2
doc/man3/BIO_s_file.pod
View File

@ -78,7 +78,7 @@ in stdio behaviour will be mirrored by the corresponding BIO.
On Windows BIO_new_files reserves for the filename argument to be
UTF-8 encoded. In other words if you have to make it work in multi-
lingual environment, encode file names in UTF-8.
lingual environment, encode filenames in UTF-8.
=head1 RETURN VALUES

2
doc/man3/BIO_set_callback.pod
View File

@ -31,7 +31,7 @@ BIO_callback_fn_ex, BIO_callback_fn
=head1 DESCRIPTION
BIO_set_callback_ex() and BIO_get_callback_ex() set and retrieve the BIO
callback. The callback is called during most high level BIO operations. It can
callback. The callback is called during most high-level BIO operations. It can
be used for debugging purposes to trace operations on a BIO or to modify its
operation.

8
doc/man3/BN_add.pod
View File

@ -68,16 +68,16 @@ For division by powers of 2, use BN_rshift(3).
BN_mod() corresponds to BN_div() with I<dv> set to B<NULL>.
BN_nnmod() reduces I<a> modulo I<m> and places the non-negative
BN_nnmod() reduces I<a> modulo I<m> and places the nonnegative
remainder in I<r>.
BN_mod_add() adds I<a> to I<b> modulo I<m> and places the non-negative
BN_mod_add() adds I<a> to I<b> modulo I<m> and places the nonnegative
result in I<r>.
BN_mod_sub() subtracts I<b> from I<a> modulo I<m> and places the
non-negative result in I<r>.
nonnegative result in I<r>.
BN_mod_mul() multiplies I<a> by I<b> and finds the non-negative
BN_mod_mul() multiplies I<a> by I<b> and finds the nonnegative
remainder respective to modulus I<m> (C<r=(a*b) mod m>). I<r> may be
the same B<BIGNUM> as I<a> or I<b>. For more efficient algorithms for
repeated computations using the same modulus, see

2
doc/man3/BN_bn2bin.pod
View File

@ -37,7 +37,7 @@ memory.
BN_bn2binpad() also converts the absolute value of B<a> into big-endian form
and stores it at B<to>. B<tolen> indicates the length of the output buffer
B<to>. The result is padded with zeroes if necessary. If B<tolen> is less than
B<to>. The result is padded with zeros if necessary. If B<tolen> is less than
BN_num_bytes(B<a>) an error is returned.
BN_bin2bn() converts the positive integer in big-endian form of length

2
doc/man3/BN_generate_prime.pod
View File

@ -127,7 +127,7 @@ For instance, to reach the 128 bit security level, B<nchecks> should be set to
If B<cb> is not B<NULL>, B<BN_GENCB_call(cb, 1, j)> is called
after the j-th iteration (j = 0, 1, ...). B<ctx> is a
pre-allocated B<BN_CTX> (to save the overhead of allocating and
preallocated B<BN_CTX> (to save the overhead of allocating and
freeing the structure in a loop), or B<NULL>.
BN_GENCB_call() calls the callback function held in the B<BN_GENCB> structure

2
doc/man3/BN_mod_mul_montgomery.pod
View File

@ -49,7 +49,7 @@ the result in I<r>.
BN_from_montgomery() performs the Montgomery reduction I<r> = I<a>*R^-1.
BN_to_montgomery() computes Mont(I<a>,R^2), i.e. I<a>*R.
Note that I<a> must be non-negative and smaller than the modulus.
Note that I<a> must be nonnegative and smaller than the modulus.
For all functions, I<ctx> is a previously allocated B<BN_CTX> used for
temporary variables.

4
doc/man3/BN_set_bit.pod
View File

@ -37,11 +37,11 @@ BN_mask_bits() truncates B<a> to an B<n> bit number
shorter than B<n> bits.
BN_lshift() shifts B<a> left by B<n> bits and places the result in
B<r> (C<r=a*2^n>). Note that B<n> must be non-negative. BN_lshift1() shifts
B<r> (C<r=a*2^n>). Note that B<n> must be nonnegative. BN_lshift1() shifts
B<a> left by one and places the result in B<r> (C<r=2*a>).
BN_rshift() shifts B<a> right by B<n> bits and places the result in
B<r> (C<r=a/2^n>). Note that B<n> must be non-negative. BN_rshift1() shifts
B<r> (C<r=a/2^n>). Note that B<n> must be nonnegative. BN_rshift1() shifts
B<a> right by one and places the result in B<r> (C<r=a/2>).
For the shift functions, B<r> and B<a> may be the same variable.

2
doc/man3/CMS_verify.pod
View File

@ -94,7 +94,7 @@ useful if one merely wishes to write the content to B<out> and its validity
is not considered important.
Chain verification should arguably be performed using the signing time rather
than the current time. However since the signing time is supplied by the
than the current time. However, since the signing time is supplied by the
signer it cannot be trusted without additional evidence (such as a trusted
timestamp).

2
doc/man3/CRYPTO_THREAD_run_once.pod
View File

@ -93,7 +93,7 @@ On Windows platforms the CRYPTO_THREAD_* types and functions in the
openssl/crypto.h header are dependent on some of the types customarily
made available by including windows.h. The application developer is
likely to require control over when the latter is included, commonly as
one of the first included headers. Therefore it is defined as an
one of the first included headers. Therefore, it is defined as an
application developer's responsibility to include windows.h prior to
crypto.h where use of CRYPTO_THREAD_* types and functions is required.

4
doc/man3/CRYPTO_memcmp.pod
View File

@ -19,13 +19,13 @@ contents of the memory regions pointed to by B<a> and B<b>.
=head1 RETURN VALUES
CRYPTO_memcmp() returns 0 if the memory regions are equal and non-zero
CRYPTO_memcmp() returns 0 if the memory regions are equal and nonzero
otherwise.
=head1 NOTES
Unlike memcmp(2), this function cannot be used to order the two memory regions
as the return value when they differ is undefined, other than being non-zero.
as the return value when they differ is undefined, other than being nonzero.
=head1 COPYRIGHT

6
doc/man3/DES_random_key.pod
View File

@ -120,7 +120,7 @@ is returned. If the key is a weak key, then -2 is returned. If an
error is returned, the key schedule is not generated.
DES_set_key() works like
DES_set_key_checked() if the I<DES_check_key> flag is non-zero,
DES_set_key_checked() if the I<DES_check_key> flag is nonzero,
otherwise like DES_set_key_unchecked(). These functions are available
for compatibility; it is recommended to use a function that does not
depend on a global variable.
@ -137,7 +137,7 @@ DES_ecb_encrypt() is the basic DES encryption routine that encrypts or
decrypts a single 8-byte I<DES_cblock> in I<electronic code book>
(ECB) mode. It always transforms the input data, pointed to by
I<input>, into the output data, pointed to by the I<output> argument.
If the I<encrypt> argument is non-zero (DES_ENCRYPT), the I<input>
If the I<encrypt> argument is nonzero (DES_ENCRYPT), the I<input>
(cleartext) is encrypted in to the I<output> (ciphertext) using the
key_schedule specified by the I<schedule> argument, previously set via
I<DES_set_key>. If I<encrypt> is zero (DES_DECRYPT), the I<input> (now
@ -156,7 +156,7 @@ The macro DES_ecb2_encrypt() is provided to perform two-key Triple-DES
encryption by using I<ks1> for the final encryption.
DES_ncbc_encrypt() encrypts/decrypts using the I<cipher-block-chaining>
(CBC) mode of DES. If the I<encrypt> argument is non-zero, the
(CBC) mode of DES. If the I<encrypt> argument is nonzero, the
routine cipher-block-chain encrypts the cleartext data pointed to by
the I<input> argument into the ciphertext pointed to by the I<output>
argument, using the key schedule provided by the I<schedule> argument,

2
doc/man3/DH_get0_pqg.pod
View File

@ -81,7 +81,7 @@ DH_get0_engine() returns a handle to the ENGINE that has been set for this DH
object, or NULL if no such ENGINE has been set.
The DH_get_length() and DH_set_length() functions get and set the optional
length parameter associated with this DH object. If the length is non-zero then
length parameter associated with this DH object. If the length is nonzero then
it is used, otherwise it is ignored. The B<length> parameter indicates the
length of the secret exponent (private key) in bits.

4
doc/man3/DH_set_method.pod
View File

@ -45,7 +45,7 @@ DH_set_method() selects B<meth> to perform all operations using the key B<dh>.
This will replace the DH_METHOD used by the DH key and if the previous method
was supplied by an ENGINE, the handle to that ENGINE will be released during the
change. It is possible to have DH keys that only work with certain DH_METHOD
implementations (eg. from an ENGINE module that supports embedded
implementations (e.g. from an ENGINE module that supports embedded
hardware-protected keys), and in such cases attempting to change the DH_METHOD
for the key can have unexpected results.
@ -64,7 +64,7 @@ B<DH_METHOD>s.
DH_set_default_method() returns no value.
DH_set_method() returns non-zero if the provided B<meth> was successfully set as
DH_set_method() returns nonzero if the provided B<meth> was successfully set as
the method for B<dh> (including unloading the ENGINE handle if the previous
method was supplied by an ENGINE).

4
doc/man3/DSA_set_method.pod
View File

@ -46,7 +46,7 @@ DSA_set_method() selects B<meth> to perform all operations using the key
B<rsa>. This will replace the DSA_METHOD used by the DSA key and if the
previous method was supplied by an ENGINE, the handle to that ENGINE will
be released during the change. It is possible to have DSA keys that only
work with certain DSA_METHOD implementations (eg. from an ENGINE module
work with certain DSA_METHOD implementations (e.g. from an ENGINE module
that supports embedded hardware-protected keys), and in such cases
attempting to change the DSA_METHOD for the key can have unexpected
results. See L<DSA_meth_new> for information on constructing custom DSA_METHOD
@ -64,7 +64,7 @@ B<DSA_METHOD>s.
DSA_set_default_method() returns no value.
DSA_set_method() returns non-zero if the provided B<meth> was successfully set as
DSA_set_method() returns nonzero if the provided B<meth> was successfully set as
the method for B<dsa> (including unloading the ENGINE handle if the previous
method was supplied by an ENGINE).

4
doc/man3/DTLSv1_listen.pod
View File

@ -35,7 +35,7 @@ message then the amplification attack has succeeded.
If DTLS is used over UDP (or any datagram based protocol that does not validate
the source IP) then it is susceptible to this type of attack. TLSv1.3 is
designed to operate over a stream-based transport protocol (such as TCP).
If TCP is being used then there is no need to use SSL_stateless(). However some
If TCP is being used then there is no need to use SSL_stateless(). However, some
stream-based transport protocols (e.g. QUIC) may not validate the source
address. In this case a TLSv1.3 application would be susceptible to this attack.
@ -98,7 +98,7 @@ will be set up ready to continue the handshake. the B<peer> value will also be
filled in.
A return value of 0 indicates a non-fatal error. This could (for
example) be because of non-blocking IO, or some invalid message having been
example) be because of nonblocking IO, or some invalid message having been
received from a peer. Errors may be placed on the OpenSSL error queue with
further information if appropriate. Typically user code is expected to retry the
call to DTLSv1_listen() in the event of a non-fatal error.

4
doc/man3/ECDSA_SIG_new.pod
View File

@ -5,7 +5,7 @@
ECDSA_SIG_get0, ECDSA_SIG_get0_r, ECDSA_SIG_get0_s, ECDSA_SIG_set0,
ECDSA_SIG_new, ECDSA_SIG_free, ECDSA_size, ECDSA_sign, ECDSA_do_sign,
ECDSA_verify, ECDSA_do_verify, ECDSA_sign_setup, ECDSA_sign_ex,
ECDSA_do_sign_ex - low level elliptic curve digital signature algorithm (ECDSA)
ECDSA_do_sign_ex - low-level elliptic curve digital signature algorithm (ECDSA)
functions
=head1 SYNOPSIS
@ -40,7 +40,7 @@ functions
=head1 DESCRIPTION
Note: these functions provide a low level interface to ECDSA. Most
Note: these functions provide a low-level interface to ECDSA. Most
applications should use the higher level B<EVP> interface such as
L<EVP_DigestSignInit(3)> or L<EVP_DigestVerifyInit(3)> instead.

2
doc/man3/EC_GROUP_new.pod
View File

@ -84,7 +84,7 @@ specific PK B<params>.
EC_GROUP_set_curve() sets the curve parameters B<p>, B<a> and B<b>. For a curve
over Fp B<p> is the prime for the field. For a curve over F2^m B<p> represents
the irreducible polynomial - each bit represents a term in the polynomial.
Therefore there will either be three or five bits set dependent on whether the
Therefore, there will either be three or five bits set dependent on whether the
polynomial is a trinomial or a pentanomial.
In either case, B<a> and B<b> represents the coefficients a and b from the
relevant equation introduced above.

2
doc/man3/EC_POINT_new.pod
View File

@ -148,7 +148,7 @@ EC_POINT_get_Jprojective_coordinates_GFp() respectively.
Points can also be described in terms of their compressed co-ordinates. For a
point (x, y), for any given value for x such that the point is on the curve
there will only ever be two possible values for y. Therefore a point can be set
there will only ever be two possible values for y. Therefore, a point can be set
using the EC_POINT_set_compressed_coordinates() function where B<x> is the x
co-ordinate and B<y_bit> is a value 0 or 1 to identify which of the two
possible values for y should be used.

20
doc/man3/ENGINE_add.pod
View File

@ -181,7 +181,7 @@ implementation includes the following abstractions;
=head2 Reference counting and handles
Due to the modular nature of the ENGINE API, pointers to ENGINEs need to be
treated as handles - ie. not only as pointers, but also as references to
treated as handles - i.e. not only as pointers, but also as references to
the underlying ENGINE object. Ie. one should obtain a new reference when
making copies of an ENGINE pointer if the copies will be used (and
released) independently.
@ -252,15 +252,15 @@ operational ENGINE for a given cryptographic purpose.
To obtain a functional reference from an existing structural reference,
call the ENGINE_init() function. This returns zero if the ENGINE was not
already operational and couldn't be successfully initialised (eg. lack of
already operational and couldn't be successfully initialised (e.g. lack of
system drivers, no special hardware attached, etc), otherwise it will
return non-zero to indicate that the ENGINE is now operational and will
return nonzero to indicate that the ENGINE is now operational and will
have allocated a new B<functional> reference to the ENGINE. All functional
references are released by calling ENGINE_finish() (which removes the
implicit structural reference as well).
The second way to get a functional reference is by asking OpenSSL for a
default implementation for a given task, eg. by ENGINE_get_default_RSA(),
default implementation for a given task, e.g. by ENGINE_get_default_RSA(),
ENGINE_get_default_cipher_engine(), etc. These are discussed in the next
section, though they are not usually required by application programmers as
they are used automatically when creating and using the relevant
@ -278,7 +278,7 @@ In the case of other abstractions like RSA, DSA, etc, there is only one
"algorithm" so all implementations implicitly register using the same 'nid'
index.
When a default ENGINE is requested for a given abstraction/algorithm/mode, (eg.
When a default ENGINE is requested for a given abstraction/algorithm/mode, (e.g.
when calling RSA_new_method(NULL)), a "get_default" call will be made to the
ENGINE subsystem to process the corresponding state table and return a
functional reference to an initialised ENGINE whose implementation should be
@ -328,7 +328,7 @@ is something for the application to control. Some applications
will want to allow the user to specify exactly which ENGINE they want used
if any is to be used at all. Others may prefer to load all support and have
OpenSSL automatically use at run-time any ENGINE that is able to
successfully initialise - ie. to assume that this corresponds to
successfully initialise - i.e. to assume that this corresponds to
acceleration hardware attached to the machine or some such thing. There are
probably numerous other ways in which applications may prefer to handle
things, so we will simply illustrate the consequences as they apply to a
@ -417,7 +417,7 @@ so that it can be initialised for use. This could include the path to any
driver or config files it needs to load, required network addresses,
smart-card identifiers, passwords to initialise protected devices,
logging information, etc etc. This class of commands typically needs to be
passed to an ENGINE B<before> attempting to initialise it, ie. before
passed to an ENGINE B<before> attempting to initialise it, i.e. before
calling ENGINE_init(). The other class of commands consist of settings or
operations that tweak certain behaviour or cause certain operations to take
place, and these commands may work either before or after ENGINE_init(), or
@ -477,7 +477,7 @@ boolean success or failure.
}
Note that ENGINE_ctrl_cmd_string() accepts a boolean argument that can
relax the semantics of the function - if set non-zero it will only return
relax the semantics of the function - if set nonzero it will only return
failure if the ENGINE supported the given command name but failed while
executing it, if the ENGINE doesn't support the command name it will simply
return success without doing anything. In this case we assume the user is
@ -490,7 +490,7 @@ It is possible to discover at run-time the names, numerical-ids, descriptions
and input parameters of the control commands supported by an ENGINE using a
structural reference. Note that some control commands are defined by OpenSSL
itself and it will intercept and handle these control commands on behalf of the
ENGINE, ie. the ENGINE's ctrl() handler is not used for the control command.
ENGINE, i.e. the ENGINE's ctrl() handler is not used for the control command.
openssl/engine.h defines an index, ENGINE_CMD_BASE, that all control commands
implemented by ENGINEs should be numbered from. Any command value lower than
this symbol is considered a "generic" command is handled directly by the
@ -556,7 +556,7 @@ by applications, administrations, users, etc. These can support arbitrary
operations via ENGINE_ctrl(), including passing to and/or from the control
commands data of any arbitrary type. These commands are supported in the
discovery mechanisms simply to allow applications to determine if an ENGINE
supports certain specific commands it might want to use (eg. application "foo"
supports certain specific commands it might want to use (e.g. application "foo"
might query various ENGINEs to see if they implement "FOO_GET_VENDOR_LOGO_GIF" -
and ENGINE could therefore decide whether or not to support this "foo"-specific
extension).

2
doc/man3/ERR_get_error.pod
View File

@ -45,7 +45,7 @@ messages.
ERR_get_error_line(), ERR_peek_error_line() and
ERR_peek_last_error_line() are the same as the above, but they
additionally store the file name and line number where
additionally store the filename and line number where
the error occurred in *B<file> and *B<line>, unless these are B<NULL>.
ERR_get_error_line_data(), ERR_peek_error_line_data() and

2
doc/man3/ERR_print_errors.pod
View File

@ -29,7 +29,7 @@ B<u> as the callback parameters.
The error strings will have the following format:
[pid]:error:[error code]:[library name]:[function name]:[reason string]:[file name]:[line]:[optional text message]
[pid]:error:[error code]:[library name]:[function name]:[reason string]:[filename]:[line]:[optional text message]
I<error code> is an 8 digit hexadecimal number. I<library name>,
I<function name> and I<reason string> are ASCII text, as is I<optional

4
doc/man3/ERR_put_error.pod
View File

@ -39,14 +39,14 @@ descriptions. For example, the function ssl3_read_bytes() reports a
SSLerr(SSL_F_SSL3_READ_BYTES, SSL_R_SSL_HANDSHAKE_FAILURE);
Function and reason codes should consist of upper case characters,
Function and reason codes should consist of uppercase characters,
numbers and underscores only. The error file generation script translates
function codes into function names by looking in the header files
for an appropriate function name, if none is found it just uses
the capitalized form such as "SSL3_READ_BYTES" in the above example.
The trailing section of a reason code (after the "_R_") is translated
into lower case and underscores changed to spaces.
into lowercase and underscores changed to spaces.
Although a library will normally report errors using its own specific
XXXerr macro, another library's macro can be used. This is normally

4
doc/man3/EVP_DigestInit.pod
View File

@ -68,7 +68,7 @@ EVP_MD_CTX_pkey_ctx, EVP_MD_CTX_set_pkey_ctx - EVP digest routines
=head1 DESCRIPTION
The EVP digest routines are a high level interface to message digests,
The EVP digest routines are a high-level interface to message digests,
and should be used instead of the cipher-specific functions.
=over 4
@ -338,7 +338,7 @@ This function has no return value.
=head1 NOTES
The B<EVP> interface to message digests should almost always be used in
preference to the low level interfaces. This is because the code then becomes
preference to the low-level interfaces. This is because the code then becomes
transparent to the digest used and much more flexible.
New applications should use the SHA-2 (such as L<EVP_sha256(3)>) or the SHA-3

4
doc/man3/EVP_DigestSignInit.pod
View File

@ -20,7 +20,7 @@ EVP_DigestSign - EVP signing functions
=head1 DESCRIPTION
The EVP signature routines are a high level interface to digital signatures.
The EVP signature routines are a high-level interface to digital signatures.
EVP_DigestSignInit() sets up signing context B<ctx> to use digest B<type> from
ENGINE B<e> and private key B<pkey>. B<ctx> must be created with
@ -110,7 +110,7 @@ The error codes can be obtained from L<ERR_get_error(3)>.
=head1 NOTES
The B<EVP> interface to digital signatures should almost always be used in
preference to the low level interfaces. This is because the code then becomes
preference to the low-level interfaces. This is because the code then becomes
transparent to the algorithm used and much more flexible.
EVP_DigestSign() is a one shot operation which signs a single block of data

4
doc/man3/EVP_DigestVerifyInit.pod
View File

@ -19,7 +19,7 @@ EVP_DigestVerify - EVP signature verification functions
=head1 DESCRIPTION
The EVP signature routines are a high level interface to digital signatures.
The EVP signature routines are a high-level interface to digital signatures.
EVP_DigestVerifyInit() sets up verification context B<ctx> to use digest
B<type> from ENGINE B<e> and public key B<pkey>. B<ctx> must be created
@ -62,7 +62,7 @@ The error codes can be obtained from L<ERR_get_error(3)>.
=head1 NOTES
The B<EVP> interface to digital signatures should almost always be used in
preference to the low level interfaces. This is because the code then becomes
preference to the low-level interfaces. This is because the code then becomes
transparent to the algorithm used and much more flexible.
EVP_DigestVerify() is a one shot operation which verifies a single block of

2
doc/man3/EVP_EncodeInit.pod
View File

@ -29,7 +29,7 @@ EVP_DecodeBlock - EVP base 64 encode/decode routines
=head1 DESCRIPTION
The EVP encode routines provide a high level interface to base 64 encoding and
The EVP encode routines provide a high-level interface to base 64 encoding and
decoding. Base 64 encoding converts binary data into a printable form that uses
the characters A-Z, a-z, 0-9, "+" and "/" to represent the data. For every 3
bytes of binary data provided 4 bytes of base 64 encoded data will be produced

10
doc/man3/EVP_EncryptInit.pod
View File

@ -120,7 +120,7 @@ EVP_enc_null
=head1 DESCRIPTION
The EVP cipher routines are a high level interface to certain
The EVP cipher routines are a high-level interface to certain
symmetric ciphers.
EVP_CIPHER_CTX_new() creates a cipher context.
@ -427,8 +427,8 @@ Sets the CCM B<L> value. If not set a default is used (8 for AES).
=item EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_AEAD_SET_IVLEN, ivlen, NULL)
Sets the CCM nonce (IV) length. This call can only be made before specifying an
nonce value. The nonce length is given by B<15 - L> so it is 7 by default for
Sets the CCM nonce (IV) length. This call can only be made before specifying
a nonce value. The nonce length is given by B<15 - L> so it is 7 by default for
AES.
=back
@ -468,10 +468,10 @@ This call is only valid when decrypting data.
=head1 NOTES
Where possible the B<EVP> interface to symmetric ciphers should be used in
preference to the low level interfaces. This is because the code then becomes
preference to the low-level interfaces. This is because the code then becomes
transparent to the cipher used and much more flexible. Additionally, the
B<EVP> interface will ensure the use of platform specific cryptographic
acceleration such as AES-NI (the low level interfaces do not provide the
acceleration such as AES-NI (the low-level interfaces do not provide the
guarantee).
PKCS padding works by adding B<n> padding bytes of value B<n> to make the total

2
doc/man3/EVP_OpenInit.pod
View File

@ -16,7 +16,7 @@ EVP_OpenInit, EVP_OpenUpdate, EVP_OpenFinal - EVP envelope decryption
=head1 DESCRIPTION
The EVP envelope routines are a high level interface to envelope
The EVP envelope routines are a high-level interface to envelope
decryption. They decrypt a public key encrypted symmetric key and
then decrypt data using it.

2
doc/man3/EVP_PKEY_CTX_ctrl.pod
View File

@ -290,7 +290,7 @@ parameter generation. Use 0 for PKCS#3 DH and 1 for X9.42 DH.
The default is 0.
The EVP_PKEY_CTX_set_dh_pad() macro sets the DH padding mode. If B<pad> is
1 the shared secret is padded with zeroes up to the size of the DH prime B<p>.
1 the shared secret is padded with zeros up to the size of the DH prime B<p>.
If B<pad> is zero (the default) then no padding is performed.
EVP_PKEY_CTX_set_dh_nid() sets the DH parameters to values corresponding to

2
doc/man3/EVP_PKEY_CTX_new.pod
View File

@ -31,7 +31,7 @@ If B<ctx> is NULL, nothing is done.
=head1 NOTES
The B<EVP_PKEY_CTX> structure is an opaque public key algorithm context used
by the OpenSSL high level public key API. Contexts B<MUST NOT> be shared between
by the OpenSSL high-level public key API. Contexts B<MUST NOT> be shared between
threads: that is it is not permissible to use the same context simultaneously
in two threads.

2
doc/man3/EVP_PKEY_keygen.pod
View File

@ -51,7 +51,7 @@ generation callback.
The function EVP_PKEY_CTX_get_keygen_info() returns parameters associated
with the generation operation. If B<idx> is -1 the total number of
parameters available is returned. Any non negative value returns the value of
that parameter. EVP_PKEY_CTX_gen_keygen_info() with a non-negative value for
that parameter. EVP_PKEY_CTX_gen_keygen_info() with a nonnegative value for
B<idx> should only be called within the generation callback.
If the callback returns 0 then the key generation operation is aborted and an

2
doc/man3/EVP_SealInit.pod
View File

@ -17,7 +17,7 @@ EVP_SealInit, EVP_SealUpdate, EVP_SealFinal - EVP envelope encryption
=head1 DESCRIPTION
The EVP envelope routines are a high level interface to envelope
The EVP envelope routines are a high-level interface to envelope
encryption. They generate a random key and IV (if required) then
"envelope" it by using public key encryption. Data can then be
encrypted using this key.

4
doc/man3/EVP_SignInit.pod
View File

@ -17,7 +17,7 @@ EVP_SignInit, EVP_SignInit_ex, EVP_SignUpdate, EVP_SignFinal
=head1 DESCRIPTION
The EVP signature routines are a high level interface to digital
The EVP signature routines are a high-level interface to digital
signatures.
EVP_SignInit_ex() sets up signing context I<ctx> to use digest
@ -48,7 +48,7 @@ The error codes can be obtained by L<ERR_get_error(3)>.
=head1 NOTES
The B<EVP> interface to digital signatures should almost always be used in
preference to the low level interfaces. This is because the code then becomes
preference to the low-level interfaces. This is because the code then becomes
transparent to the algorithm used and much more flexible.
When signing with DSA private keys the random number generator must be seeded.

4
doc/man3/EVP_VerifyInit.pod
View File

@ -19,7 +19,7 @@ EVP_VerifyInit, EVP_VerifyUpdate, EVP_VerifyFinal
=head1 DESCRIPTION
The EVP signature verification routines are a high level interface to digital
The EVP signature verification routines are a high-level interface to digital
signatures.
EVP_VerifyInit_ex() sets up verification context B<ctx> to use digest
@ -49,7 +49,7 @@ The error codes can be obtained by L<ERR_get_error(3)>.
=head1 NOTES
The B<EVP> interface to digital signatures should almost always be used in
preference to the low level interfaces. This is because the code then becomes
preference to the low-level interfaces. This is because the code then becomes
transparent to the algorithm used and much more flexible.
The call to EVP_VerifyFinal() internally finalizes a copy of the digest context.

2
doc/man3/HMAC.pod
View File

@ -69,7 +69,7 @@ EVP_shake256().
HMAC_CTX_new() creates a new HMAC_CTX in heap memory.
HMAC_CTX_reset() zeroes an existing B<HMAC_CTX> and associated
HMAC_CTX_reset() zeros an existing B<HMAC_CTX> and associated
resources, making it suitable for new computations as if it was newly
created with HMAC_CTX_new().

2
doc/man3/OCSP_cert_to_id.pod
View File

@ -52,7 +52,7 @@ corresponding parameter can be set to B<NULL>.
OCSP_cert_to_id() and OCSP_cert_id_new() return either a pointer to a valid
B<OCSP_CERTID> structure or B<NULL> if an error occurred.
OCSP_id_cmp() and OCSP_id_issuer_cmp() returns zero for a match and non-zero
OCSP_id_cmp() and OCSP_id_issuer_cmp() returns zero for a match and nonzero
otherwise.
OCSP_CERTID_free() does not return a value.

2
doc/man3/OCSP_request_add1_nonce.pod
View File

@ -57,7 +57,7 @@ performance reasons. As a result they do not support nonces.
The return values of OCSP_check_nonce() can be checked to cover each case. A
positive return value effectively indicates success: nonces are both present
and match, both absent or present in the response only. A non-zero return
and match, both absent or present in the response only. A nonzero return
additionally covers the case where the nonce is present in the request only:
this will happen if the responder doesn't support nonces. A zero return value
indicates present and mismatched nonces: this should be treated as an error

4
doc/man3/OCSP_resp_find_status.pod
View File

@ -112,7 +112,7 @@ no freeing of the results is necessary.
OCSP_check_validity() checks the validity of B<thisupd> and B<nextupd> values
which will be typically obtained from OCSP_resp_find_status() or
OCSP_single_get0_status(). If B<sec> is non-zero it indicates how many seconds
OCSP_single_get0_status(). If B<sec> is nonzero it indicates how many seconds
leeway should be allowed in the check. If B<maxsec> is positive it indicates
the maximum age of B<thisupd> in seconds.
@ -167,7 +167,7 @@ can then take appropriate action based on the status of the certificate.
An OCSP response for a certificate contains B<thisUpdate> and B<nextUpdate>
fields. Normally the current time should be between these two values. To
account for clock skew the B<maxsec> field can be set to non-zero in
account for clock skew the B<maxsec> field can be set to nonzero in
OCSP_check_validity(). Some responders do not set the B<nextUpdate> field, this
would otherwise mean an ancient response would be considered valid: the
B<maxsec> parameter to OCSP_check_validity() can be used to limit the permitted

4
doc/man3/OCSP_sendreq_new.pod
View File

@ -34,7 +34,7 @@ response header maximum line length of B<maxline>. If B<maxline> is zero a
default value of 4k is used. The OCSP request B<req> may be set to B<NULL>
and provided later if required.
OCSP_sendreq_nbio() performs non-blocking I/O on the OCSP request context
OCSP_sendreq_nbio() performs nonblocking I/O on the OCSP request context
B<rctx>. When the operation is complete it returns the response in B<*presp>.
OCSP_REQ_CTX_free() frees up the OCSP context B<rctx>.
@ -96,7 +96,7 @@ corresponding BIO can be examined to determine which operation (read or
write) should be retried and appropriate action taken (for example a select()
call on the underlying socket).
OCSP_sendreq_bio() does not support retries and so cannot handle non-blocking
OCSP_sendreq_bio() does not support retries and so cannot handle nonblocking
I/O efficiently. It is retained for compatibility and its use in new
applications is not recommended.

4
doc/man3/OPENSSL_LH_COMPFUNC.pod
View File

@ -51,7 +51,7 @@ an unsigned long hash value for its key field. The hash value is
normally truncated to a power of 2, so make sure that your hash
function returns well mixed low order bits. The B<compare> callback
takes two arguments (pointers to two hash table entries), and returns
0 if their keys are equal, non-zero otherwise.
0 if their keys are equal, nonzero otherwise.
If your hash table
will contain items of some particular type and the B<hash> and
@ -196,7 +196,7 @@ all such parameters as constant.
As an example, a hash table may be maintained by code that, for
reasons of encapsulation, has only "const" access to the data being
indexed in the hash table (ie. it is returned as "const" from
indexed in the hash table (i.e. it is returned as "const" from
elsewhere in their code) - in this case the LHASH prototypes are
appropriate as-is. Conversely, if the caller is responsible for the
life-time of the data in question, then they may well wish to make

2
doc/man3/OPENSSL_config.pod
View File

@ -41,7 +41,7 @@ initialization (that is before starting any threads).
There are several reasons why calling the OpenSSL configuration routines is
advisable. For example, to load dynamic ENGINEs from shared libraries (DSOs).
However very few applications currently support the control interface and so
However, very few applications currently support the control interface and so
very few can load and use dynamic ENGINEs. Equally in future more sophisticated
ENGINEs will require certain control operations to customize them. If an
application calls OPENSSL_config() it doesn't need to know or care about

2
doc/man3/OPENSSL_ia32cap.pod
View File

@ -102,7 +102,7 @@ and RORX;
=item bit #64+19 denoting availability of ADCX and ADOX instructions;
=item bit #64+21 denoting availability of VPMADD52[LH]UQ instructions,
a.k.a. AVX512IFMA extension;
aka AVX512IFMA extension;
=item bit #64+29 denoting availability of SHA extension;

10
doc/man3/OPENSSL_init_crypto.pod
View File

@ -39,13 +39,13 @@ needs so no explicit initialisation is required. Similarly it will also
automatically deinitialise as required.
However, there may be situations when explicit initialisation is desirable or
needed, for example when some non-default initialisation is required. The
needed, for example when some nondefault initialisation is required. The
function OPENSSL_init_crypto() can be used for this purpose for
libcrypto (see also L<OPENSSL_init_ssl(3)> for the libssl
equivalent).
Numerous internal OpenSSL functions call OPENSSL_init_crypto().
Therefore, in order to perform non-default initialisation,
Therefore, in order to perform nondefault initialisation,
OPENSSL_init_crypto() MUST be called by application code prior to
any other OpenSSL function calls.
@ -216,10 +216,10 @@ The filename, application name, and flags can be customized by providing a
non-null B<OPENSSL_INIT_SETTINGS> object.
The object can be allocated via B<OPENSSL_init_new()>.
The B<OPENSSL_INIT_set_config_filename()> function can be used to specify a
non-default filename, which is copied and need not refer to persistent storage.
nondefault filename, which is copied and need not refer to persistent storage.
Similarly, OPENSSL_INIT_set_config_appname() can be used to specify a
non-default application name.
Finally, OPENSSL_INIT_set_file_flags can be used to specify non-default flags.
nondefault application name.
Finally, OPENSSL_INIT_set_file_flags can be used to specify nondefault flags.
If the B<CONF_MFLAGS_IGNORE_RETURN_CODES> flag is not included, any errors in
the configuration file will cause an error return from B<OPENSSL_init_crypto>
or indirectly L<OPENSSL_init_ssl(3)>.

4
doc/man3/OPENSSL_init_ssl.pod
View File

@ -23,14 +23,14 @@ needs so no explicit initialisation is required. Similarly it will also
automatically deinitialise as required.
However, there may be situations when explicit initialisation is desirable or
needed, for example when some non-default initialisation is required. The
needed, for example when some nondefault initialisation is required. The
function OPENSSL_init_ssl() can be used for this purpose. Calling
this function will explicitly initialise BOTH libcrypto and libssl. To
explicitly initialise ONLY libcrypto see the
L<OPENSSL_init_crypto(3)> function.
Numerous internal OpenSSL functions call OPENSSL_init_ssl().
Therefore, in order to perform non-default initialisation,
Therefore, in order to perform nondefault initialisation,
OPENSSL_init_ssl() MUST be called by application code prior to
any other OpenSSL function calls.

4
doc/man3/PEM_read_bio_PrivateKey.pod
View File

@ -206,7 +206,7 @@ RSA structure. The public key is encoded using a PKCS#1 RSAPublicKey
structure.
The B<RSA_PUBKEY> functions also process an RSA public key using
an RSA structure. However the public key is encoded using a
an RSA structure. However, the public key is encoded using a
SubjectPublicKeyInfo structure and an error occurs if the public
key is not RSA.
@ -387,7 +387,7 @@ The pseudo code to derive the key would look similar to:
=head1 BUGS
The PEM read routines in some versions of OpenSSL will not correctly reuse
an existing structure. Therefore the following:
an existing structure. Therefore, the following:
PEM_read_bio_X509(bp, &x, 0, NULL);

2
doc/man3/PKCS7_verify.pod
View File

@ -91,7 +91,7 @@ useful if one merely wishes to write the content to B<out> and its validity
is not considered important.
Chain verification should arguably be performed using the signing time rather
than the current time. However since the signing time is supplied by the
than the current time. However, since the signing time is supplied by the
signer it cannot be trusted without additional evidence (such as a trusted
timestamp).

2
doc/man3/RAND_DRBG_new.pod
View File

@ -56,7 +56,7 @@ its type and to instantiate it.
The optional B<flags> argument specifies a set of bit flags which can be
joined using the | operator. Currently, the only flag is
RAND_DRBG_FLAG_CTR_NO_DF, which disables the use of a the derivation function
RAND_DRBG_FLAG_CTR_NO_DF, which disables the use of the derivation function
ctr_df. For an explanation, see [NIST SP 800-90A Rev. 1].
If a B<parent> instance is specified then this will be used instead of

2
doc/man3/RAND_DRBG_set_callbacks.pod
View File

@ -77,7 +77,7 @@ does not satisfy the conditions requested by [NIST SP 800-90C], then
it must also indicate an error by returning a buffer length of 0.
See NOTES section for more details.
The B<cleanup_entropy>() callback is called from the B<drbg> to to clear and
The B<cleanup_entropy>() callback is called from the B<drbg> to clear and
free the buffer allocated previously by get_entropy().
The values B<out> and B<outlen> are the random buffer's address and length,
as returned by the get_entropy() callback.

2
doc/man3/RAND_add.pod
View File

@ -62,7 +62,7 @@ usage by the random seed sources. Some seed sources maintain open file
descriptors by default, which allows such sources to operate in a
chroot(2) jail without the associated device nodes being available. When
the B<keep> argument is zero, this call disables the retention of file
descriptors. Conversely, a non-zero argument enables the retention of
descriptors. Conversely, a nonzero argument enables the retention of
file descriptors. This function is usually called during initialization
and it takes effect immediately.

6
doc/man3/RAND_load_file.pod
View File

@ -17,7 +17,7 @@ RAND_load_file, RAND_write_file, RAND_file_name - PRNG seed file
=head1 DESCRIPTION
RAND_load_file() reads a number of bytes from file B<filename> and
adds them to the PRNG. If B<max_bytes> is non-negative,
adds them to the PRNG. If B<max_bytes> is nonnegative,
up to B<max_bytes> are read;
if B<max_bytes> is -1, the complete file is read.
Do not load the same file multiple times unless its contents have
@ -37,7 +37,7 @@ file. B<buf> points to a buffer of size B<num> in which to store the
filename.
On all systems, if the environment variable B<RANDFILE> is set, its
value will be used as the seed file name.
value will be used as the seed filename.
Otherwise, the file is called C<.rnd>, found in platform dependent locations:
=over 4
@ -57,7 +57,7 @@ Otherwise, the file is called C<.rnd>, found in platform dependent locations:
=back
If C<$HOME> (on non-Windows and non-VMS system) is not set either, or
B<num> is too small for the path name, an error occurs.
B<num> is too small for the pathname, an error occurs.
=head1 RETURN VALUES

2
doc/man3/RSA_blinding_on.pod
View File

@ -19,7 +19,7 @@ measure the time of RSA decryption or signature operations, blinding
must be used to protect the RSA operation from that attack.
RSA_blinding_on() turns blinding on for key B<rsa> and generates a
random blinding factor. B<ctx> is B<NULL> or a pre-allocated and
random blinding factor. B<ctx> is B<NULL> or a preallocated and
initialized B<BN_CTX>.
RSA_blinding_off() turns blinding off and frees the memory used for

4
doc/man3/RSA_private_encrypt.pod
View File

@ -2,7 +2,7 @@
=head1 NAME
RSA_private_encrypt, RSA_public_decrypt - low level signature operations
RSA_private_encrypt, RSA_public_decrypt - low-level signature operations
=head1 SYNOPSIS
@ -16,7 +16,7 @@ RSA_private_encrypt, RSA_public_decrypt - low level signature operations
=head1 DESCRIPTION
These functions handle RSA signatures at a low level.
These functions handle RSA signatures at a low-level.
RSA_private_encrypt() signs the B<flen> bytes at B<from> (usually a
message digest with an algorithm identifier) using the private key

2
doc/man3/RSA_set_method.pod
View File

@ -51,7 +51,7 @@ RSA_set_method() selects B<meth> to perform all operations using the key
B<rsa>. This will replace the RSA_METHOD used by the RSA key and if the
previous method was supplied by an ENGINE, the handle to that ENGINE will
be released during the change. It is possible to have RSA keys that only
work with certain RSA_METHOD implementations (eg. from an ENGINE module
work with certain RSA_METHOD implementations (e.g. from an ENGINE module
that supports embedded hardware-protected keys), and in such cases
attempting to change the RSA_METHOD for the key can have unexpected
results.

8
doc/man3/SSL_CONF_cmd.pod
View File

@ -79,7 +79,7 @@ B<ClientHello>.
The B<value> argument is a colon separated list of groups. The group can be
either the B<NIST> name (e.g. B<P-256>), some other commonly used name where
applicable (e.g. B<X25519>) or an OpenSSL OID name (e.g B<prime256v1>). Group
applicable (e.g. B<X25519>) or an OpenSSL OID name (e.g. B<prime256v1>). Group
names are case sensitive. The list should be in order of preference with the
most preferred group first.
@ -95,7 +95,7 @@ servers
The B<value> argument is a curve name or the special value B<auto> which
picks an appropriate curve based on client and server preferences. The curve
can be either the B<NIST> name (e.g. B<P-256>) or an OpenSSL OID name
(e.g B<prime256v1>). Curve names are case sensitive.
(e.g. B<prime256v1>). Curve names are case sensitive.
=item B<-cipher>
@ -359,7 +359,7 @@ B<ClientHello>.
The B<value> argument is a colon separated list of groups. The group can be
either the B<NIST> name (e.g. B<P-256>), some other commonly used name where
applicable (e.g. B<X25519>) or an OpenSSL OID name (e.g B<prime256v1>). Group
applicable (e.g. B<X25519>) or an OpenSSL OID name (e.g. B<prime256v1>). Group
names are case sensitive. The list should be in order of preference with the
most preferred group first.
@ -548,7 +548,7 @@ The value is a string without any specific structure.
=item B<SSL_CONF_TYPE_FILE>
The value is a file name.
The value is a filename.
=item B<SSL_CONF_TYPE_DIR>

6
doc/man3/SSL_CTX_dane_enable.pod
View File

@ -122,7 +122,7 @@ SSL_get0_dane_tlsa() can be used to retrieve the fields of the TLSA record that
matched the peer certificate chain.
The return value indicates the match depth or failure to match just as with
SSL_get0_dane_authority().
When the return value is non-negative, the storage pointed to by the B<usage>,
When the return value is nonnegative, the storage pointed to by the B<usage>,
B<selector>, B<mtype> and B<data> parameters is updated to the corresponding
TLSA record fields.
The B<data> field is in binary wire form, and is therefore not NUL-terminated,
@ -136,7 +136,7 @@ SSL_CTX_dane_set_flags() and SSL_dane_set_flags() can be used to enable
optional DANE verification features.
SSL_CTX_dane_clear_flags() and SSL_dane_clear_flags() can be used to disable
the same features.
The B<flags> argument is a bitmask of the features to enable or disable.
The B<flags> argument is a bit mask of the features to enable or disable.
The B<flags> set for an B<SSL_CTX> context are copied to each B<SSL> handle
associated with that context at the time the handle is created.
Subsequent changes in the context's B<flags> have no effect on the B<flags> set
@ -173,7 +173,7 @@ certificate or a public key that fails to parse.
The functions SSL_get0_dane_authority() and SSL_get0_dane_tlsa() return a
negative value when DANE authentication failed or was not enabled, a
non-negative value indicates the chain depth at which the TLSA record matched a
nonnegative value indicates the chain depth at which the TLSA record matched a
chain certificate, or the depth of the top-most certificate, when the TLSA
record is a full public key that is its signer.

2
doc/man3/SSL_CTX_set_alpn_select_cb.pod
View File

@ -114,7 +114,7 @@ provided by the callback.
=head1 NOTES
The protocol-lists must be in wire-format, which is defined as a vector of
non-empty, 8-bit length-prefixed, byte strings. The length-prefix byte is not
nonempty, 8-bit length-prefixed, byte strings. The length-prefix byte is not
included in the length. Each string is limited to 255 bytes. A byte-string
length of 0 is invalid. A truncated byte-string is invalid. The length of the
vector is not in the vector itself, but in a separate variable.

4
doc/man3/SSL_CTX_set_generate_session_id.pod
View File

@ -108,8 +108,8 @@ server id given, and will fill the rest with pseudo random bytes:
/*
* Prefix the session_id with the required prefix. NB: If our
* prefix is too long, clip it - but there will be worse effects
* anyway, eg. the server could only possibly create 1 session
* ID (ie. the prefix!) so all future session negotiations will
* anyway, e.g. the server could only possibly create 1 session
* ID (i.e. the prefix!) so all future session negotiations will
* fail due to conflicts.
*/
memcpy(id, session_id_prefix, strlen(session_id_prefix) < *id_len ?

4
doc/man3/SSL_CTX_set_info_callback.pod
View File

@ -50,7 +50,7 @@ the callback function was called. If B<ret> is 0, an error condition occurred.
If an alert is handled, SSL_CB_ALERT is set and B<ret> specifies the alert
information.
B<where> is a bitmask made up of the following bits:
B<where> is a bit mask made up of the following bits:
=over 4
@ -64,7 +64,7 @@ per state in some situations.
Callback has been called to indicate exit of a handshake function. This will
happen after the end of a handshake, but may happen at other times too such as
on error or when IO might otherwise block and non-blocking is being used.
on error or when IO might otherwise block and nonblocking is being used.
=item SSL_CB_READ

2
doc/man3/SSL_CTX_set_max_cert_list.pod
View File

@ -39,7 +39,7 @@ received from a faulty or malicious peer, a maximum size for the certificate
chain is set.
The default value for the maximum certificate chain size is 100kB (30kB
on the 16bit DOS platform). This should be sufficient for usual certificate
on the 16-bit DOS platform). This should be sufficient for usual certificate
chains (OpenSSL's default maximum chain length is 10, see
L<SSL_CTX_set_verify(3)>, and certificates
without special extensions have a typical size of 1-2kB).

20
doc/man3/SSL_CTX_set_mode.pod
View File

@ -18,13 +18,13 @@ SSL_CTX_set_mode, SSL_CTX_clear_mode, SSL_set_mode, SSL_clear_mode, SSL_CTX_get_
=head1 DESCRIPTION
SSL_CTX_set_mode() adds the mode set via bitmask in B<mode> to B<ctx>.
SSL_CTX_set_mode() adds the mode set via bit mask in B<mode> to B<ctx>.
Options already set before are not cleared.
SSL_CTX_clear_mode() removes the mode set via bitmask in B<mode> from B<ctx>.
SSL_CTX_clear_mode() removes the mode set via bit mask in B<mode> from B<ctx>.
SSL_set_mode() adds the mode set via bitmask in B<mode> to B<ssl>.
SSL_set_mode() adds the mode set via bit mask in B<mode> to B<ssl>.
Options already set before are not cleared.
SSL_clear_mode() removes the mode set via bitmask in B<mode> from B<ssl>.
SSL_clear_mode() removes the mode set via bit mask in B<mode> from B<ssl>.
SSL_CTX_get_mode() returns the mode set for B<ctx>.
@ -50,8 +50,8 @@ the behaviour of write().
Make it possible to retry SSL_write_ex() or SSL_write() with changed buffer
location (the buffer contents must stay the same). This is not the default to
avoid the misconception that non-blocking SSL_write() behaves like
non-blocking write().
avoid the misconception that nonblocking SSL_write() behaves like
nonblocking write().
=item SSL_MODE_AUTO_RETRY
@ -64,9 +64,9 @@ If such a non-application data record was processed, the flag
B<SSL_MODE_AUTO_RETRY> causes it to try to process the next record instead of
returning.
In a non-blocking environment applications must be prepared to handle
In a nonblocking environment applications must be prepared to handle
incomplete read/write operations.
Setting B<SSL_MODE_AUTO_RETRY> for a non-blocking B<BIO> will process
Setting B<SSL_MODE_AUTO_RETRY> for a nonblocking B<BIO> will process
non-application data records until either no more data is available or
an application data record has been processed.
@ -121,10 +121,10 @@ default since 1.1.1.
=head1 RETURN VALUES
SSL_CTX_set_mode() and SSL_set_mode() return the new mode bitmask
SSL_CTX_set_mode() and SSL_set_mode() return the new mode bit mask
after adding B<mode>.
SSL_CTX_get_mode() and SSL_get_mode() return the current bitmask.
SSL_CTX_get_mode() and SSL_get_mode() return the current bit mask.
=head1 SEE ALSO

18
doc/man3/SSL_CTX_set_options.pod
View File

@ -23,16 +23,16 @@ SSL_get_secure_renegotiation_support - manipulate SSL options
=head1 DESCRIPTION
SSL_CTX_set_options() adds the options set via bitmask in B<options> to B<ctx>.
SSL_CTX_set_options() adds the options set via bit mask in B<options> to B<ctx>.
Options already set before are not cleared!
SSL_set_options() adds the options set via bitmask in B<options> to B<ssl>.
SSL_set_options() adds the options set via bit mask in B<options> to B<ssl>.
Options already set before are not cleared!
SSL_CTX_clear_options() clears the options set via bitmask in B<options>
SSL_CTX_clear_options() clears the options set via bit mask in B<options>
to B<ctx>.
SSL_clear_options() clears the options set via bitmask in B<options> to B<ssl>.
SSL_clear_options() clears the options set via bit mask in B<options> to B<ssl>.
SSL_CTX_get_options() returns the options set for B<ctx>.
@ -45,7 +45,7 @@ Note, this is implemented via a macro.
=head1 NOTES
The behaviour of the SSL library can be changed by setting several options.
The options are coded as bitmasks and can be combined by a bitwise B<or>
The options are coded as bit masks and can be combined by a bitwise B<or>
operation (|).
SSL_CTX_set_options() and SSL_set_options() affect the (external)
@ -161,7 +161,7 @@ the session. In this way the server can operate statelessly - no session
information needs to be cached locally.
The TLSv1.3 protocol only supports tickets and does not directly support session
ids. However OpenSSL allows two modes of ticket operation in TLSv1.3: stateful
ids. However, OpenSSL allows two modes of ticket operation in TLSv1.3: stateful
and stateless. Stateless tickets work the same way as in TLSv1.2 and below.
Stateful tickets mimic the session id behaviour available in TLSv1.2 and below.
The session information is cached on the server and the session id is wrapped up
@ -340,13 +340,13 @@ and renegotiation between OpenSSL and unpatched clients or servers.
=head1 RETURN VALUES
SSL_CTX_set_options() and SSL_set_options() return the new options bitmask
SSL_CTX_set_options() and SSL_set_options() return the new options bit mask
after adding B<options>.
SSL_CTX_clear_options() and SSL_clear_options() return the new options bitmask
SSL_CTX_clear_options() and SSL_clear_options() return the new options bit mask
after clearing B<options>.
SSL_CTX_get_options() and SSL_get_options() return the current bitmask.
SSL_CTX_get_options() and SSL_get_options() return the current bit mask.
SSL_get_secure_renegotiation_support() returns 1 is the peer supports
secure renegotiation and 0 if it does not.

2
doc/man3/SSL_CTX_set_psk_client_callback.pod
View File

@ -135,7 +135,7 @@ A connection established via a TLSv1.3 PSK will appear as if session resumption
has occurred so that L<SSL_session_reused(3)> will return true.
There are no known security issues with sharing the same PSK between TLSv1.2 (or
below) and TLSv1.3. However the RFC has this note of caution:
below) and TLSv1.3. However, the RFC has this note of caution:
"While there is no known way in which the same PSK might produce related output
in both versions, only limited analysis has been done. Implementations can

2
doc/man3/SSL_CTX_set_read_ahead.pod
View File

@ -21,7 +21,7 @@ SSL_CTX_get_default_read_ahead
=head1 DESCRIPTION
SSL_CTX_set_read_ahead() and SSL_set_read_ahead() set whether we should read as
many input bytes as possible (for non-blocking reads) or not. For example if
many input bytes as possible (for nonblocking reads) or not. For example if
B<x> bytes are currently required by OpenSSL, but B<y> bytes are available from
the underlying BIO (where B<y> > B<x>), then OpenSSL will read all B<y> bytes
into its buffer (providing that the buffer is large enough) if reading ahead is

2
doc/man3/SSL_CTX_set_session_cache_mode.pod
View File

@ -96,7 +96,7 @@ session caching (callback) that is configured for the SSL_CTX. This flag will
prevent sessions being stored in the internal cache (though the application can
add them manually using L<SSL_CTX_add_session(3)>). Note:
in any SSL/TLS servers where external caching is configured, any successful
session lookups in the external cache (ie. for session-resume requests) would
session lookups in the external cache (i.e. for session-resume requests) would
normally be copied into the local cache before processing continues - this flag
prevents these additions to the internal cache as well.

Some files were not shown because too many files have changed in this diff Show More