mirror of
git://git.gnupg.org/gnupg.git
synced 2024-12-22 10:19:57 +01:00
build: Update README.maint.
-- Also fixed some typos.
This commit is contained in:
Werner Koch
parent
b453226f56
commit
6b54759976
14
README.maint
14
README.maint
@ -23,10 +23,7 @@ Release process:
|
||||
* Decide whether you want to update the automake standard files
|
||||
(Mainly config.guess and config.sub).
|
||||
|
||||
* [1.4 only] Update gpg.texi and gpgv.texi from master:
|
||||
make -C doc update-source-from-gnupg-2
|
||||
|
||||
* [1.4 and 2.0] Copy needed texinfo files from master:
|
||||
* [2.0] Copy needed texinfo files from master:
|
||||
make -C doc update-source
|
||||
|
||||
* Run:
|
||||
@ -34,11 +31,9 @@ Release process:
|
||||
|
||||
* Write NEWS entries and set the release date in NEWS.
|
||||
|
||||
* [1.4 and 2.0] In configure.ac set "my_isgit" to "no".
|
||||
|
||||
* Commit all changes to GIT with a message of "Release n.m.o."
|
||||
|
||||
* Tag the revision with the string "gnupg-x.y.z".
|
||||
* Create a signed tag with the name "gnupg-x.y.z".
|
||||
|
||||
* Run "./autogen.sh --force"
|
||||
(--force is required for the git magic in configure.ac and a good
|
||||
@ -64,11 +59,12 @@ Release process:
|
||||
|
||||
* Copy the files to the FTP server
|
||||
|
||||
* Update the webpages - at least the file swdb.wml needs an update.
|
||||
* Update the webpages - at least the file swdb.mac needs an update.
|
||||
|
||||
* Add a new headline to NEWS.
|
||||
|
||||
* Bump "my_version" up and set "my_isgit" back to "yes" in configure.ac
|
||||
* Bump the version number in configure.ac up, add an empty NEWS
|
||||
entry, commit, and push that.
|
||||
|
||||
* Write an announcement.
|
||||
|
||||
|
||||
@ -103,7 +103,7 @@ https://gnupg.org/faq/whats-new-in-2.1.html
|
||||
`secring.gpg'. The only difference is that secring stored in addition
|
||||
to the public part also the private part of the key pair. The secret
|
||||
keyring thus contained only the keys for which a private key is
|
||||
availaable, that is the user’s key. It required a lot of code to keep
|
||||
available, that is the user’s key. It required a lot of code to keep
|
||||
both versions of the key in sync and led to sometimes surprising
|
||||
inconsistencies.
|
||||
|
||||
@ -198,8 +198,8 @@ https://gnupg.org/faq/whats-new-in-2.1.html
|
||||
|
||||
Thus only the name and the mail address are required. For all other
|
||||
parameters the default values are used. Many graphical frontends
|
||||
works in the same way. Note that GPG prints a hint for the old time
|
||||
GPG users on how to get the full option menu.
|
||||
works in the same way. Note that /gpg/ prints a hint for the old time
|
||||
gpg users on how to get the full option menu.
|
||||
|
||||
|
||||
1.4 Support for ECC
|
||||
@ -381,7 +381,7 @@ https://gnupg.org/faq/whats-new-in-2.1.html
|
||||
│ sub rsa2048/72A4D018 2014-11-04
|
||||
╰────
|
||||
|
||||
Another common operation is to sign a key. gpg can do this directly
|
||||
Another common operation is to sign a key. /gpg/ can do this directly
|
||||
from the command line by giving the fingerprint of the to-be-signed
|
||||
key:
|
||||
|
||||
@ -478,7 +478,7 @@ https://gnupg.org/faq/whats-new-in-2.1.html
|
||||
A deficit of the OpenPGP protocol is that signatures carry only a
|
||||
limited indication on which public has been used to create a
|
||||
signature. Thus a verification engine may only use this “long key id”
|
||||
to lookup the the key in its own store or from a public keyserver.
|
||||
to look up the the key in its own store or from a public keyserver.
|
||||
Unfortunately it has now become possible to create a key with a long
|
||||
key id matching the key id of another key. Importing a key with a
|
||||
long key id already used by another key in gpg’s local key store was
|
||||
@ -522,7 +522,7 @@ https://gnupg.org/faq/whats-new-in-2.1.html
|
||||
server from the pool.
|
||||
|
||||
The new /dirmngr/ in GnuPG does not use the implicit round-robin of
|
||||
the DNS resolver but uses its own DNS lookup and keeps an internal
|
||||
the DNS resolver but uses its own DNS look up and keeps an internal
|
||||
table of all hosts from the pool along with the encountered aliveness
|
||||
state. Thus after a failure (timeout) of a request, /dirmngr/ flags a
|
||||
host as dead and randomly selects another one from the pool. After a
|
||||
@ -544,10 +544,10 @@ https://gnupg.org/faq/whats-new-in-2.1.html
|
||||
──────────────────────────
|
||||
|
||||
The format GnuPG has always used for the public keyring is actually a
|
||||
slighly extended version of the on-the-wire format for OpenPGP key
|
||||
slightly extended version of the on-the-wire format for OpenPGP key
|
||||
exchange. This format is quite inflexible to work with when random
|
||||
access to keys in the keyring is required. In fact /gpg/ always
|
||||
parsed all keys in the kering until it encountred the desired one.
|
||||
parsed all keys in the keyring until it encountered the desired one.
|
||||
With a large keyring (more than a few thousand keys) this could be
|
||||
quite slow.
|
||||
|
||||
@ -570,9 +570,9 @@ https://gnupg.org/faq/whats-new-in-2.1.html
|
||||
`pubring.gpg' file and not know anything about keys stored in the
|
||||
keybox file.
|
||||
|
||||
To convert an existsing `pubring.gpg' file to the keybox format, you
|
||||
To convert an existing `pubring.gpg' file to the keybox format, you
|
||||
first rename the file to (for example) `publickeys' so it won’t be
|
||||
recognized by any GnupG version and then you run the command
|
||||
recognized by any GnuPG version and then you run the command
|
||||
|
||||
╭────
|
||||
│ $ gpg2 --import publickeys
|
||||
@ -597,12 +597,12 @@ https://gnupg.org/faq/whats-new-in-2.1.html
|
||||
──────────────────────────
|
||||
|
||||
The /scdaemon/, which is responsible for accessing smardcards and
|
||||
other tokens, has received may updates. In particilar pluggable USB
|
||||
readers with a fixed card now work smoothless and simlar to standard
|
||||
other tokens, has received may updates. In particular plugable USB
|
||||
readers with a fixed card now work smoothless and similar to standard
|
||||
readers. The latest features of the /gnuk/ token are supported. Code
|
||||
for the HSM smartcard has been added. More card readers with a PIN
|
||||
pad are supported. The internal CCID driver does now also work with
|
||||
certain non-auto configration equipped readers.
|
||||
certain non-auto configuration equipped readers.
|
||||
|
||||
|
||||
1.14 New format for key listings
|
||||
@ -692,8 +692,8 @@ https://gnupg.org/faq/whats-new-in-2.1.html
|
||||
|
||||
This command downloads all direct dependencies, checks the signatures
|
||||
using the GnuPG version from the build system (all Linux distros
|
||||
feature a suitable GnuPG tool), builds everthing from source, and uses
|
||||
NSIS to create the installer. Although this sounds easy, some
|
||||
feature a suitable GnuPG tool), builds everything from source, and
|
||||
uses NSIS to create the installer. Although this sounds easy, some
|
||||
experience in setting up a development machine is still required.
|
||||
Some versions of the toolchain exhibit bugs and thus your mileage may
|
||||
vary. Support for keyserver access over TLS is currently not
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user