security-and-privacy/gnupg
security-and-privacy/gnupg
1
0
Fork 0
mirror of git://git.gnupg.org/gnupg.git synced 2024-12-22 10:19:57 +01:00
Code Activity

doc: Minor fix.

Browse Source 
--

Due to todays reminder:

  On Tue 2014-04-22 18:46:15 -0400, Daniel Kahn Gillmor wrote:
  > With --trust-model=always, all keys and user IDs are considered
  > automatically valid; they are not automatically trusted (setting
  > universal ownertrust to anything other than "ultimate" would be
  > insufficient to acheive the effect of --trust-model=always, due to
  > --max-cert-depth and certificate path reachability).
  >
  > Thanks to Nicolai Josuttis for pointing out this documentation
  error.
This commit is contained in:
Werner Koch 2014-10-03 20:19:08 +02:00
parent 0943c7cc23
commit 0c52bfa395
2 changed files with 9 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
NEWS
View File

@ -1,3 +1,10 @@
Noteworthy changes in version 2.1.0 (unreleased)
------------------------------------------------
* For a complete list of changes see the lists of changes for the
2.1.0 beta versions below.
Noteworthy changes in version 2.1.0-beta864 (2014-10-03)
--------------------------------------------------------
@ -11,7 +18,7 @@ Noteworthy changes in version 2.1.0-beta864 (2014-10-03)
* gpg: Default keyring is now created with a .kbx suffix.
* gpg: Add a shortcut to key capabilies menu (e.g. "=e" sets the
* gpg: Add a shortcut to the key capabilies menu (e.g. "=e" sets the
encryption capabilities).
* gpg: Fixed obsolete options parsing.

2
doc/gpg.texi
View File

@ -1425,7 +1425,7 @@ Set what trust model GnuPG should follow. The models are:
@item always
@opindex trust-mode:always
Skip key validation and assume that used keys are always fully
trusted. You generally won't use this unless you are using some
valid. You generally won't use this unless you are using some
external validation scheme. This option also suppresses the
"[uncertain]" tag printed with signature checks when there is no
evidence that the user ID is bound to the key. Note that this