Correct documentation spelling errors detected using codespell.
Reported by Jens Schleusener.
ticket: 8891
tags: pullup
target_version: 1.18-next
specifies **X509_user_identity** on the command line.
**pkinit_kdc_hostname**
- The presense of this option indicates that the client is willing
+ The presence of this option indicates that the client is willing
to accept a KDC certificate with a dNSName SAN (Subject
Alternative Name) rather than requiring the id-pkinit-san as
defined in :rfc:`4556`. This option may be specified multiple
# only principals in OTHER.REALM are matched.
#
# s/@OTHER\.REALM$// removes the realm name, leaving behind the
- # principal name as the acount name.
+ # principal name as the account name.
auth_to_local = RULE:[1:$1@$0](.*@OTHER\.REALM)s/@OTHER\.REALM$//
# Also allow principals from the default realm. Omit this line
The result of these commands will be two files, cakey.pem and
cacert.pem. cakey.pem will contain a 2048-bit RSA private key, which
must be carefully protected. cacert.pem will contain the CA
-certificate, which must be placed in the filesytems of the KDC and
+certificate, which must be placed in the filesystems of the KDC and
each client host. cakey.pem will be required to create KDC and client
certificates.
Overflow checks for ulogentries times block size?
-If file can't be made the size indicated by ulogentries, shoud we
+If file can't be made the size indicated by ulogentries, should we
truncate or error out? If we error out, this could blow out when
resizing the log because of a too-large log entry.
The following is a description of a black-box unit test of the
OpenV*Secure Admin Database API (osa_adb). Each API function is
-listed, followed by the tests that shoud be performed on it.
+listed, followed by the tests that should be performed on it.
The tests described here are based on the ``OV*Secure Admin Server
Implementation Design'' revision 1.14.
\end{verbatim}
%
\begin{description}
-\item[key_data_ver] The verion number of the structure. Versions 1
+\item[key_data_ver] The version number of the structure. Versions 1
and 2 are currently defined. If key_data_ver is 1 then the key is
either a random key (not requiring a salt) or the salt is the normal
v5 salt which is the same as the realm and therefore doesn't need to
specify the API version number that the program will use by
\v{\#define}ing USE_KADM5_API_VERSION; for example, define that symbol
to be 1 to use KADM5_API_VERSION_1. This will ensure that the correct
-functional protoypes and data structures are defined. If no version
+functional prototypes and data structures are defined. If no version
symbol is defined, the most recent version supported by the header
files will be used.
\item[KADM5_BAD_LENGTH] Invalid password length
\item[KADM5_BAD_POLICY] Illegal policy name
\item[KADM5_BAD_PRINCIPAL] Illegal principal name.
-\item[KADM5_BAD_AUX_ATTR] Invalid auxillary attributes
+\item[KADM5_BAD_AUX_ATTR] Invalid auxiliary attributes
\item[KADM5_BAD_HISTORY] Invalid password history count
\item[KADM5_BAD_MIN_PASS_LIFE] Password minimum life is greater
then password maximum life
\item[KADM5_PASS_Q_CLASS] Password does not contain enough
character classes
\item[KADM5_PASS_Q_DICT] Password is in the password dictionary
-\item[KADM5_PASS_REUSE] Cannot resuse password
+\item[KADM5_PASS_REUSE] Cannot reuse password
\item[KADM5_PASS_TOOSOON] Current password's minimum life has not
expired
\item[KADM5_POLICY_REF] Policy is in use
compatibility. It is identical to kadm5_init_with_password.
These three functions open a connection to the kadm5 library and
-initialize any neccessary state information. They behave differently
+initialize any necessary state information. They behave differently
when called from local and remote clients.
In KADM5_API_VERSION_2, these functions take a kadm5_config_params
functionality. If the passwords don't match the string ``New passwords do
not match - password not changed.'' will be copied into msg_ret, and the
error code KRB5_LIBOS_BADPWDMATCH will be returned. For other errors that
-ocurr while reading the new password, copy the string ``<com_err message$>$
+occur while reading the new password, copy the string ``<com_err message$>$
occurred while trying to read new password.'' followed by a blank line and
the string specified by CHPASS_UTIL_PASSWORD_NOT_CHANGED into msg_ret and
return the error code returned by krb5_read_password.
\end{verbatim}
Free memory that was allocated by a call to kadm5_get_policy. If
-the argument is NULL, the function returns succesfully.
+the argument is NULL, the function returns successfully.
AUTHORIZATION REQUIRED: none (local operation)
Any code whose behavior depends on the API version should be written
so as to be compatible with future, currently unknown API versions on
-the grounds that any particuarly piece of API behavior will most
+the grounds that any particular piece of API behavior will most
likely not change between versions. For example, in the current
system, the code is not written as ``if this is VERSION_1, do X, else
if this is VERSION_2, do Y''; instead, it is written as ``if this is
Server library functions must know how many and what type of arguments
to expect, and must operate on those arguments correctly, based on the
API version with which they are invoked. The API version is contained
-in the handle that is alwasy passed as their first argument, generated
+in the handle that is always passed as their first argument, generated
by kadm5_init_* (to which the client specified the API version to use
at run-time).
an API handle that contains the API version requested by the client;
otherwise the function semantics might not be correct. One
possibility would be for the server to call kadm5_init for each client
-request, specifing the client's API version number and thus generating
+request, specifying the client's API version number and thus generating
an API handle with the correct version, but that would be
prohibitively inefficient. Instead, the server dips down in the
server library's internal abstraction barrier, using the function
the declarations of both kadm5_get_principal and kadm5_get_policy
did. Thus, to use the caller's API handle, kadm5_chpass_principal
will have to have a separate code path for each API version, even
-though it itself did not change bewteen versions, and duplicate a lot
+though it itself did not change between versions, and duplicate a lot
of logic found elsewhere in the library.
Instead, each API handle contains a ``local-use handle,'' or lhandle,
kadm5 function to perform operations that they client will see and for
its own benefit, since the semantics of the recursively-called kadm5
function may depend on the API version specified and the client may be
-depending on a particular version's behavior. Future implementators
+depending on a particular version's behavior. Future implementors
should avoid creating a situation in which this is possible.
\section{Server Main}
\end{enumerate}
Functions which modify the database acquire an exclusive lock, others
-acqure a shared lock. osa_adb_iter_T acquires an exclusive lock for
+acquire a shared lock. osa_adb_iter_T acquires an exclusive lock for
safety but as stated below consequences of modifying the database in
the iteration function are undefined.
Iterates over every entry in the database. For each entry ent in the
database db, the function (*func)(data, ent) is called. If func
returns an error code, osa_adb_iter_T returns an error code. If all
-invokations of func return OSA_ADB_OK, osa_adb_iter_T returns
+invocations of func return OSA_ADB_OK, osa_adb_iter_T returns
OSA_ADB_OK. The function func is permitted to access the database,
but the consequences of modifying the database during the iteration
are undefined.
\section{Function Details}
This section discusses specific design issues for Admin API functions
-that are not addresed by the functional specifications.
+that are not addressed by the functional specifications.
\subsection{kadm5_create_principal}
\section{Introduction}
The following is a description of a black-box unit test of the KADM5
-API. Each API function is listed, followed by the tests that shoud be
+API. Each API function is listed, followed by the tests that should be
performed on it.
The tests described here are based on the ``Kerberos Administration
\numtest{102.5}{
\Version{KADM5_API_VERSION_2}
-\Reason{Obeys the admin_server field of the configuratin parameters,
+\Reason{Obeys the admin_server field of the configuration parameters,
if set with a host name and port number.}
\Conditions{RPC}
}
\numtest{116}{
\Version{KADM5_API_VERSION_2}
\Reason{Two calls to init with clients having different privileges
-succeedes, and both clients maintain their correct privileges.}
+succeeds, and both clients maintain their correct privileges.}
\Priority{Bug fix}
\Conditions{RPC}
\Status{Implemented}
\numtest{10}{
\Priority{Low}
-\Reason{Connects to correct server when mutliple handles exist}
+\Reason{Connects to correct server when multiple handles exist}
\Conditions{client}
}
\numtest{44}{
\Priority{Low}
-\Reason{Connects to correct server when mutliple handles exist}
+\Reason{Connects to correct server when multiple handles exist}
\Conditions{RPC}
}
\numtest{14}{
\Priority{Low}
-\Reason{Connects to correct server when mutliple handles exist}
+\Reason{Connects to correct server when multiple handles exist}
\Conditions{RPC}
}
\numtest{44}{
\Priority{Low}
-\Reason{Connects to correct server when mutliple handles exist}
+\Reason{Connects to correct server when multiple handles exist}
\Conditions{RPC}
}
\numtest{17}{
\Priority{Low}
-\Reason{Connects to correct server when mutliple handles exist}
+\Reason{Connects to correct server when multiple handles exist}
\Conditions{RPC}
}
\numtest{184}{
\Priority{Low}
-\Reason{Connects to correct server when mutliple handles exist}
+\Reason{Connects to correct server when multiple handles exist}
\Conditions{RPC}
}
\numtest{34}{
\Priority{Low}
-\Reason{Connects to correct server when mutliple handles exist}
+\Reason{Connects to correct server when multiple handles exist}
\Conditions{RPC}
}
\numtest{16}{
\Priority{Low}
-\Reason{Connects to correct server when mutliple handles exist}
+\Reason{Connects to correct server when multiple handles exist}
\Conditions{RPC}
}
\numtest{31}{
\Priority{Low}
-\Reason{Connects to correct server when mutliple handles exist}
+\Reason{Connects to correct server when multiple handles exist}
\Conditions{RPC}
}
\numtest{14}{
\Priority{Low}
-\Reason{Connects to correct server when mutliple handles exist}
+\Reason{Connects to correct server when multiple handles exist}
\Conditions{RPC}
}
\numtest{31}{
\Priority{Low}
-\Reason{Connects to correct server when mutliple handles exist}
+\Reason{Connects to correct server when multiple handles exist}
\Conditions{RPC}
}
\numtest{22}{
\Priority{Low}
-\Reason{Connects to correct server when mutliple handles exist}
+\Reason{Connects to correct server when multiple handles exist}
\Conditions{RPC}
}
- Plugin to test password quality :ref:`pwqual_plugin`
- Plugin to synchronize password changes :ref:`kadm5_hook_plugin`
- Parallel KDC
- - GSS-API extentions for SASL GS2 bridge :rfc:`5801` :rfc:`5587`
+ - GSS-API extensions for SASL GS2 bridge :rfc:`5801` :rfc:`5587`
- Purging old keys
- Naming extensions for delegation chain
- Password expiration API
complex. In the normal course of events, an RPC call comes in, is
authenticated, and is then dispatched to the appropriate procedure.
For client- and service-side authentication flavors to communicate
-indepedent of the server implemented above the RPC layer, the
+independent of the server implemented above the RPC layer, the
service-side flavor must be able to send a reply to the client
directly and {\it prevent} the call from being dispatched.
\section{GSS-API Authentication Flavor}
-The following sections describe the implemetation of the GSS-API
+The following sections describe the implementation of the GSS-API
authentication flavor for Sun RPC.
\subsection{Authentication Algorithms}
since the application server may have registered multiple service
names and there is no way to determine {\it a priori} which service a
token is for, _svcauth_gssapi calls gss_accept_sec_context once for
-each registered credential until one of them succeedes. The code
+each registered credential until one of them succeeds. The code
assumes that GSS_S_FAILURE is the only error that can result from a
credential mismatch, so any other error terminates the loop
immediately.
\subsubsection{RPC Calls}
After the GSS-API context is established, both the server and the
-client posess a client handle and a corresponding sequence number.
+client possess a client handle and a corresponding sequence number.
Each call from the client contains the client handle as the
``credential'' so that the server can identify which context to apply
to the call.
authentication mechanism for the actual server. Any message whose
auth_msg field is true is processed by the authentication mechanism;
any message whose auth_msg is false is passed to the application
-server's dispatch function if authentication suceeds. All messages
+server's dispatch function if authentication succeeds. All messages
must have an auth_msg of true until the context is established, since
authentication cannot succeed until it is.
number is one greater than the previous value sent by
auth_gssapi_marshall.
-Finally, auth_gssapi_unwrap, invokved by the client-side RPC mechanism
+Finally, auth_gssapi_unwrap, invoked by the client-side RPC mechanism
after auth_gssapi_validate succeeds, performs the same operation as
svc_auth_gssapi_unwrap.
the first call.
The sequence_number field contains the sequence number that will be
-used when transmitting RPC calls to the server and verifing the
+used when transmitting RPC calls to the server and verifying the
server's responses after the context is initialized.
The def_cred field is true if gss_init_sec_context created a default
/*
* Mask of ticket flags in the TGT which should be converted into KDC
- * options when using the TGT to get derivitive tickets.
+ * options when using the TGT to get derivative tickets.
*
* New mask = KDC_OPT_FORWARDABLE | KDC_OPT_PROXIABLE |
* KDC_OPT_ALLOW_POSTDATE | KDC_OPT_RENEWABLE
* request used for user to user
* authentication.
* @li #AP_OPTS_MUTUAL_REQUIRED - Request a mutual authentication packet from
- * the reciever.
+ * the receiver.
* @li #AP_OPTS_USE_SUBKEY - Generate a subsession key from the current
* session key obtained from the credentials.
*
*
* This function sets the replay cache in @a auth_context to @a rcache. @a
* rcache will be closed when @a auth_context is freed, so the caller should
- * relinguish that responsibility.
+ * relinquish that responsibility.
*
* @retval 0 Success; otherwise - Kerberos error codes
*/
krb5_timestamp *authtime_out, char **princname_out);
/**
- * Allow the appplication to override the profile's allow_weak_crypto setting.
+ * Allow the application to override the profile's allow_weak_crypto setting.
*
* @param [in] context Library context
* @param [in] enable Boolean flag
projects / thirdparty / krb5.git / commitdiff
