mirror of
git://git.gnupg.org/gnupg.git
synced 2025-07-02 22:46:30 +02:00
Fix more spelling
* NEWS, acinclude.m4, agent/command-ssh.c, agent/command.c, agent/gpg-agent.c, agent/keyformat.txt, agent/protect-tool.c, common/asshelp.c, common/b64enc.c, common/recsel.c, doc/DETAILS, doc/HACKING, doc/Notes, doc/TRANSLATE, doc/dirmngr.texi, doc/faq.org, doc/gpg-agent.texi, doc/gpg.texi, doc/gpgsm.texi, doc/instguide.texi, g10/armor.c, g10/gpg.c, g10/keyedit.c, g10/mainproc.c, g10/pkclist.c, g10/tofu.c, g13/sh-cmd.c, g13/sh-dmcrypt.c, kbx/keybox-init.c, m4/pkg.m4, sm/call-dirmngr.c, sm/gpgsm.c, tests/Makefile.am, tests/gpgscm/Manual.txt, tests/gpgscm/scheme.c, tests/openpgp/gpgv-forged-keyring.scm, tests/openpgp/multisig.test, tests/openpgp/verify.scm, tests/pkits/README, tools/applygnupgdefaults, tools/gpg-connect-agent.c, tools/mime-maker.c, tools/mime-parser.c: minor spelling cleanup. Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
This commit is contained in:
Daniel Kahn Gillmor
NIIBE Yutaka
parent
215180d1ce
commit
0d67241e31
43 changed files with 81 additions and 79 deletions
14
doc/DETAILS
14
doc/DETAILS
|
|
@ -15,6 +15,8 @@ This is the DETAILS file for GnuPG which specifies some internals and
|
|||
parts of the external API for GPG and GPGSM.
|
||||
|
||||
* Format of the colon listings
|
||||
|
||||
*
|
||||
The format is a based on colon separated record, each recods starts
|
||||
with a tag string and extends to the end of the line. Here is an
|
||||
example:
|
||||
|
|
@ -91,7 +93,7 @@ described here.
|
|||
ultimately valid.
|
||||
- w :: The key has a well known private part.
|
||||
- s :: The key has special validity. This means that it might be
|
||||
self-signed and expected to be used in the STEED sytem.
|
||||
self-signed and expected to be used in the STEED system.
|
||||
|
||||
If the validity information is given for a UID or UAT record, it
|
||||
describes the validity calculated based on this user ID. If given
|
||||
|
|
@ -120,7 +122,7 @@ described here.
|
|||
|
||||
The creation date of the key is given in UTC. For UID and UAT
|
||||
records, this is used for the self-signature date. Note that the
|
||||
date is usally printed in seconds since epoch, however, we are
|
||||
date is usually printed in seconds since epoch, however, we are
|
||||
migrating to an ISO 8601 format (e.g. "19660205T091500"). This is
|
||||
currently only relevant for X.509. A simple way to detect the new
|
||||
format is to scan for the 'T'. Note that old versions of gpg
|
||||
|
|
@ -136,7 +138,7 @@ described here.
|
|||
Used for serial number in crt records. For UID and UAT records,
|
||||
this is a hash of the user ID contents used to represent that
|
||||
exact user ID. For trust signatures, this is the trust depth
|
||||
seperated by the trust value by a space.
|
||||
separated by the trust value by a space.
|
||||
|
||||
*** Field 9 - Ownertrust
|
||||
|
||||
|
|
@ -715,7 +717,7 @@ pkd:0:1024:B665B1435F4C2 .... FF26ABB:
|
|||
Tofu information. The fingerprint is the fingerprint of the
|
||||
primary key and the mbox is in general the addr-spec part of the
|
||||
userid encoded in UTF-8 and percent escaped. The fingerprint is
|
||||
indentical for all TOFU_USER lines up to a NEWSIG line.
|
||||
identical for all TOFU_USER lines up to a NEWSIG line.
|
||||
|
||||
*** TOFU_STATS <validity> <sign-count> 0 [<policy> [<tm1> <tm2> <tm3> <tm4>]]
|
||||
|
||||
|
|
@ -930,7 +932,7 @@ pkd:0:1024:B665B1435F4C2 .... FF26ABB:
|
|||
commencing with a letter or such a string prefixed with a
|
||||
numerical error code and an underscore; e.g.: "151011327_EOF".
|
||||
*** SUCCESS [<location>]
|
||||
Postive confirmation that an operation succeeded. It is used
|
||||
Positive confirmation that an operation succeeded. It is used
|
||||
similar to ISO-C's EXIT_SUCCESS. <location> is optional but if
|
||||
given should not contain spaces. Used only with a few commands.
|
||||
|
||||
|
|
@ -987,7 +989,7 @@ pkd:0:1024:B665B1435F4C2 .... FF26ABB:
|
|||
<name> is a percent-plus escaped filename describing the
|
||||
mountpoint for the current operation (e.g. used by "g13 --mount").
|
||||
This may either be the specified mountpoint or one randomly
|
||||
choosen by g13.
|
||||
chosen by g13.
|
||||
|
||||
*** PINENTRY_LAUNCHED <pid>
|
||||
This status line is emitted by gpg to notify a client that a
|
||||
|
|
|
|||
|
|
@ -326,7 +326,7 @@ Note that such a comment will be removed if the git commit option
|
|||
and related constants
|
||||
- g10/openfile.c :: Create/Open Files
|
||||
- g10/keyserver.h :: Keyserver access dispatcher.
|
||||
- g10/packet.h :: Defintion of OpenPGP structures.
|
||||
- g10/packet.h :: Definition of OpenPGP structures.
|
||||
- g10/passphrase.c :: Passphrase handling code
|
||||
|
||||
- g10/pubkey-enc.c :: Process a public key encoded packet.
|
||||
|
|
|
|||
16
doc/Notes
16
doc/Notes
|
|
@ -7,7 +7,7 @@ There are two ways:
|
|||
|
||||
1. Let gpg-agent do this for you. Since version 1.9.9 you need to
|
||||
add the option --allow-mark-trusted gpg-agent.conf or when
|
||||
invoking gpg-agent. Everytime gpgsm notices an untrusted root
|
||||
invoking gpg-agent. Every time gpgsm notices an untrusted root
|
||||
certificate gpg-agent will pop up a dialog to ask whether this
|
||||
certificate should be trusted. This is similar to whatmost
|
||||
browsers do.
|
||||
|
|
@ -22,7 +22,7 @@ There are two ways:
|
|||
the fingerprints of the trusted root certificates. There are
|
||||
comments on the top explaining the simple format. The current
|
||||
CVS version allows for colons in the fingerprint, so you can
|
||||
easily cut and paste it from whereever you know that this is the
|
||||
easily cut and paste it from wherever you know that this is the
|
||||
correct fingerprint.
|
||||
|
||||
An example for an entry in the trustlist.txt is:
|
||||
|
|
@ -199,12 +199,12 @@ dirmngr
|
|||
libgcrypt
|
||||
libksba
|
||||
libassuan [statically linked]
|
||||
libldap [system libary]
|
||||
liblber [system libary]
|
||||
libsasl [system libary, required by libldap]
|
||||
libdb2 [system libary, required by libsasl]
|
||||
libcrypt [system libary, required by libsasl - OOPS]
|
||||
libpam [system libary, required by libsasl]
|
||||
libldap [system library]
|
||||
liblber [system library]
|
||||
libsasl [system library, required by libldap]
|
||||
libdb2 [system library, required by libsasl]
|
||||
libcrypt [system library, required by libsasl - OOPS]
|
||||
libpam [system library, required by libsasl]
|
||||
[Standard system libraries]
|
||||
|
||||
pinentry-curses
|
||||
|
|
|
|||
|
|
@ -8,9 +8,9 @@ strings can accept multiple values that mean essentially the same
|
|||
thing.
|
||||
|
||||
For example, the string "yes" in English is "sí" in Spanish. However,
|
||||
some users will type "si" (without the accent). To accomodate both
|
||||
some users will type "si" (without the accent). To accommodate both
|
||||
users, you can translate the string "yes" as "sí|si". You can have
|
||||
any number of alternate matches seperated by the | character like
|
||||
any number of alternate matches separated by the | character like
|
||||
"sí|si|seguro".
|
||||
|
||||
The strings that can be handled in this way are of the form "yes|yes",
|
||||
|
|
|
|||
|
|
@ -496,7 +496,7 @@ This directory may contain extra certificates which are preloaded
|
|||
into the interal cache on startup. Applications using dirmngr (e.g. gpgsm)
|
||||
can request cached certificates to complete a trust chain.
|
||||
This is convenient in cases you have a couple intermediate CA certificates
|
||||
or certificates ususally used to sign OCSP responses.
|
||||
or certificates usually used to sign OCSP responses.
|
||||
These certificates are first tried before going
|
||||
out to the net to look for them. These certificates must also be
|
||||
@acronym{DER} encoded and suffixed with @file{.crt} or @file{.der}.
|
||||
|
|
@ -784,7 +784,7 @@ revoked or one of the usual error codes from libgpg-error.
|
|||
@end example
|
||||
|
||||
Check whether the certificate with @var{fingerprint} (the SHA-1 hash of
|
||||
the entire X.509 certificate blob) is valid by consulting the appropiate
|
||||
the entire X.509 certificate blob) is valid by consulting the appropriate
|
||||
OCSP responder. If the fingerprint has not been given or the
|
||||
certificate is not known by Dirmngr, the function inquires the
|
||||
certificate using:
|
||||
|
|
@ -816,7 +816,7 @@ revoked or one of the usual error codes from libgpg-error.
|
|||
|
||||
Put a certificate into the internal cache. This command might be
|
||||
useful if a client knows in advance certificates required for a test and
|
||||
wnats to make sure they get added to the internal cache. It is also
|
||||
wants to make sure they get added to the internal cache. It is also
|
||||
helpful for debugging. To get the actual certificate, this command
|
||||
immediately inquires it using
|
||||
|
||||
|
|
@ -831,7 +831,7 @@ as a binary blob.
|
|||
|
||||
@noindent
|
||||
The return code is 0 for success; i.e. the certificate has not been
|
||||
succesfully cached or one of the usual error codes from libgpg-error.
|
||||
successfully cached or one of the usual error codes from libgpg-error.
|
||||
|
||||
@node Dirmngr VALIDATE
|
||||
@subsection Validate a certificate for debugging
|
||||
|
|
@ -883,7 +883,7 @@ as a binary blob.
|
|||
@c @var{fingerprint} is optional and expected to be the SHA-1 has of the
|
||||
@c DER encoding of the certificate under question. It is to be HEX
|
||||
@c encoded. The rationale for sending the fingerprint is that it allows
|
||||
@c dirmngr to reply immediatly if it has already cached such a request. If
|
||||
@c dirmngr to reply immediately if it has already cached such a request. If
|
||||
@c this is not the case and no certificate has been found in dirmngr's
|
||||
@c internal certificate storage, dirmngr will request the certificate using
|
||||
@c the Assuan inquiry
|
||||
|
|
@ -905,7 +905,7 @@ as a binary blob.
|
|||
@c available for the certificate and the certificate itself is not listed
|
||||
@c in this CRL, @code{GPG_ERR_CERT_REVOKED} to indicate that the certificate is
|
||||
@c listed in the CRL or @code{GPG_ERR_NO_CRL_KNOWN} in cases where no CRL or no
|
||||
@c information is available. The first two codes are immediatly returned to
|
||||
@c information is available. The first two codes are immediately returned to
|
||||
@c the caller and the processing of this request has been done.
|
||||
@c
|
||||
@c Only the @code{GPG_ERR_NO_CRL_KNOWN} needs more attention: Dirmngr now
|
||||
|
|
@ -941,7 +941,7 @@ as a binary blob.
|
|||
@c * Try to load a CRL from all configured servers (ldapservers.conf)
|
||||
@c in turn. The first server returning a CRL is used.
|
||||
@c * @code(crl_cache_insert) is then used to actually insert the CRL
|
||||
@c into the cache. If this failed we give up immediatley without
|
||||
@c into the cache. If this failed we give up immediately without
|
||||
@c checking the rest of the servers from the first step.
|
||||
@c * Ready.
|
||||
@c
|
||||
|
|
@ -1013,7 +1013,7 @@ as a binary blob.
|
|||
@c sure that @code{validate_cert_chain} does not try to lookup the CRL we
|
||||
@c are currently processing. This would be a catch-22 and may indicate a
|
||||
@c broken PKI. However, due to overlapping expiring times and imprecise
|
||||
@c clocks thsi may actually happen.
|
||||
@c clocks this may actually happen.
|
||||
@c
|
||||
@c For historical reasons the Assuan command ISVALID is a bit different
|
||||
@c to CHECKCRL but this is mainly due to different calling conventions.
|
||||
|
|
@ -1072,8 +1072,8 @@ as a binary blob.
|
|||
@c If the issuer's certificate has been found, the signature of the
|
||||
@c actual certificate is checked and in case this fails the error
|
||||
@c #code{GPG_ERR_BAD_CERT_CHAIN} is returned. If the signature checks out, the
|
||||
@c maximum cahin length of the issueing certificate is checked as well as
|
||||
@c the capiblity of the certificate (i.e. whether he may be used for
|
||||
@c maximum chain length of the issuing certificate is checked as well as
|
||||
@c the capability of the certificate (i.e. whether he may be used for
|
||||
@c certificate signing). Then the certificate is prepended to our list
|
||||
@c representing the certificate chain. Finally the loop is continued now
|
||||
@c with the issuer's certificate as the current certificate.
|
||||
|
|
|
|||
|
|
@ -73,7 +73,7 @@ update this FAQ in the next month. See the section "Changes" for recent updates
|
|||
item to note is that starting with GnuPG version 1.1.92 the file
|
||||
containing user options and settings has been renamed from "options"
|
||||
to "gpg.conf". Information in the FAQ that relates to the options
|
||||
file may be interchangable with the newer gpg.conf file in many
|
||||
file may be interchangeable with the newer gpg.conf file in many
|
||||
instances. See question
|
||||
[[#gnupg-no-longer-installs-a-options-file-is-it-missing][GnuPG no longer installs a ~/.gnupg/options file. Is it missing?]]
|
||||
for details.
|
||||
|
|
@ -491,7 +491,7 @@ update this FAQ in the next month. See the section "Changes" for recent updates
|
|||
On a secure machine:
|
||||
|
||||
1. If you want to do automatic signing, create a signing subkey for
|
||||
your key. Use the interactive key editing menu by issueing the
|
||||
your key. Use the interactive key editing menu by issuing the
|
||||
command
|
||||
: gpg --edit-key keyID
|
||||
enter "addkey" and select the DSA key type).
|
||||
|
|
@ -651,7 +651,7 @@ update this FAQ in the next month. See the section "Changes" for recent updates
|
|||
:CUSTOM_ID: how-do-i-verify-signed-packages
|
||||
:END:
|
||||
|
||||
must first have the vendor, organisation, or issueing person's key
|
||||
must first have the vendor, organisation, or issuing person's key
|
||||
Before you can verify the signature that accompanies a package, you
|
||||
imported into your public keyring. To prevent GnuPG warning
|
||||
messages the key should also be validated (or locally signed).
|
||||
|
|
@ -1278,7 +1278,7 @@ update this FAQ in the next month. See the section "Changes" for recent updates
|
|||
and where it is easy to exchange the passphrases (e.g. with your boy
|
||||
friend or your wife). The advantage is that you can change the
|
||||
passphrase from time to time and decrease the risk, that many old
|
||||
messages may be decrypted by people who accidently got your passphrase.
|
||||
messages may be decrypted by people who accidentally got your passphrase.
|
||||
|
||||
You can add and copy keys to and from your keyring with the 'gpg
|
||||
--import' and 'gpg --export' command. 'gpg --export-secret-keys' will
|
||||
|
|
|
|||
|
|
@ -76,7 +76,7 @@ the included Secure Shell Agent you may start the agent using:
|
|||
@c interface that the owner has access to, but the supplicant does not).
|
||||
@c
|
||||
@c The rationale for this separation is that it allows access to the
|
||||
@c secret key to be tightly controled and audited, and it doesn't permit
|
||||
@c secret key to be tightly controlled and audited, and it doesn't permit
|
||||
@c the the supplicant to either copy the key or to override the owner's
|
||||
@c intentions.
|
||||
|
||||
|
|
|
|||
|
|
@ -2265,7 +2265,7 @@ The available filter types are:
|
|||
|
||||
@item drop-sig
|
||||
This filter drops the selected key signatures on user ids.
|
||||
Self-signatures are not consideres.
|
||||
Self-signatures are not considered.
|
||||
Currently only implemented for --import-filter.
|
||||
|
||||
@end table
|
||||
|
|
@ -2423,7 +2423,7 @@ this is implicitly enable for secret keys.
|
|||
|
||||
@item --with-wkd-hash
|
||||
@opindex with-wkd-hash
|
||||
Print a Web Key Directory indentifier along with each user ID in key
|
||||
Print a Web Key Directory identifier along with each user ID in key
|
||||
listings. This is an experimental feature and semantics may change.
|
||||
|
||||
@item --with-secret
|
||||
|
|
|
|||
|
|
@ -852,7 +852,7 @@ updated; new distributions of this software should come with an updated
|
|||
list but it is still the responsibility of the Administrator to check
|
||||
that this list is correct.
|
||||
|
||||
Everytime @command{gpgsm} uses a certificate for signing or verification
|
||||
Every time @command{gpgsm} uses a certificate for signing or verification
|
||||
this file will be consulted to check whether the certificate under
|
||||
question has ultimately been issued by one of these CAs. If this is the
|
||||
case the user will be informed that the verified signature represents a
|
||||
|
|
@ -1110,7 +1110,7 @@ certificate signing request):
|
|||
@item Serial: @var{sn}
|
||||
If this parameter is given an X.509 certificate will be generated.
|
||||
@var{sn} is expected to be a hex string representing an unsigned
|
||||
integer of arbitary length. The special value @samp{random} can be
|
||||
integer of arbitrary length. The special value @samp{random} can be
|
||||
used to create a 64 bit random serial number.
|
||||
|
||||
@item Issuer-DN: @var{issuer-name}
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ get that whole thing up and running.
|
|||
|
||||
** Building the software
|
||||
|
||||
Building the software is decribed in the file @file{INSTALL}. Given
|
||||
Building the software is described in the file @file{INSTALL}. Given
|
||||
that you are already reading this documentation we can only give some
|
||||
extra hints
|
||||
|
||||
|
|
@ -62,7 +62,7 @@ user installation this can be done once for all users on a machine.
|
|||
Specific changes on a per-user base are also possible.
|
||||
@end itemize
|
||||
|
||||
@c decribe how to maintain trustlist.txt and /etc/gnupg/trustlist.txt.
|
||||
@c describe how to maintain trustlist.txt and /etc/gnupg/trustlist.txt.
|
||||
|
||||
|
||||
@c ** How to get the ssh support running
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue