From gnupg-doc-request@gnupg.org  Sun Mar  5 09:12:58 2000
Received: (from slist@localhost)
	by pharos.hsp.de id JAA09564;
	Sun, 5 Mar 2000 09:12:58 +0100
Resent-Date: Sun, 5 Mar 2000 09:12:58 +0100
Date: 5 Mar 2000 17:11:23 +0900
Message-ID: <20000305081123.8682.qmail@anjyu.secom-sis.co.jp>
From: IIDA Yosiaki <y-iida@secom.co.jp>
To: gnupg-doc@gnupg.org
Subject: Possible errata for GPH English edition
Resent-Message-ID: <CD9EcD.A.ZVC.Kchw4@pharos>
Resent-From: gnupg-doc@gnupg.org
X-Mailing-List: <gnupg-doc@gnupg.org> archive/latest/17
X-Loop: gnupg-doc@gnupg.org
Precedence: list
Resent-Sender: gnupg-doc-request@gnupg.org

  Enjoy!

------------------------------------------------------------
--- c2.sgml~	Sun Dec 12 19:58:07 1999
+++ c2.sgml	Fri Feb 18 14:34:15 2000
@@ -75,7 +75,7 @@
 <para>
 Britain used machines to guess keys during World War 2.
 The German Enigma had a very large key space, but the British built
-speciailzed computing engines, the Bombes, to mechanically try 
+specialized computing engines, the Bombes, to mechanically try 
 keys until the day's key was found.
 This meant that sometimes they found the day's key within hours of
 the new key's use, but it also meant that on some days they never
@@ -125,7 +125,7 @@
 <!-- inlineequation -->
 <emphasis>n(n-1)/2</emphasis> keys
 are needed for each pair of people to communicate privately.
-This may be ok for a small number of people but quickly becomes unwieldly
+This may be ok for a small number of people but quickly becomes unwieldy
 for large groups of people.
 </para>
 
@@ -330,7 +330,7 @@
 An algorithm that does work is to use a public key algorithm to
 encrypt only the signature.
 In particular, the hash value is encrypted using the signer's private
-key, and anbody can check the signature using the public key.
+key, and anybody can check the signature using the public key.
 The signed document can be sent using any other encryption algorithm
 including none if it is a public document.
 If the document is modified the signature check will fail, but this
--- c4.sgml~	Sun Sep 19 09:58:44 1999
+++ c4.sgml	Sun Feb 20 03:53:00 2000
@@ -15,7 +15,7 @@
 drastically different security needs.
 This complicates key management.
 Socially, using &gnupg; is not strictly a personal decision.
-To use &gnupg effectively both parties communicating must use it.
+To use &gnupg; effectively both parties communicating must use it.
 Finally, as of 1999, laws regarding digital encryption, and in particular
 whether or not using &gnupg; is legal, vary from country to country and 
 is currently being debated by many national governments.
@@ -87,7 +87,7 @@
 encrypted messages.
 Protecting your private key prevents an attacker from simply using your
 private key to decrypt encrypted messages and sign messages in your name.
-Correctly managing your web of trust prevents attackers from masquarading
+Correctly managing your web of trust prevents attackers from masquerading
 as people with whom you communicate.
 Ultimately, addressing these issues with respect to your own security
 needs is how you balance the extra work required to use &gnupg; with
@@ -185,7 +185,7 @@
 This may be inconvenient or impossible for you to do.
 For example, you may not own your own machine and must use a computer 
 at work or school, or it may mean you have to physically disconnect
-your computer from your cable modem every time you want to use &gnupg;
+your computer from your cable modem every time you want to use &gnupg;.
 </para>
 
 <para>
@@ -209,7 +209,7 @@
 a passphrase that is easier to guess than a random 128-bit key.
 If the passphrase is a word, it is much cheaper to try all the
 words in the dictionaries of the world's languages.
-Even if the word is permuted, &eg, k3wldood, it is still easier
+Even if the word is permuted, &eg;, k3wldood, it is still easier
 to try dictionary words with a catalog of permutations.
 The same problem applies to quotations.
 In general, passphrases based on natural-language utterances
@@ -363,7 +363,7 @@
 </para>
 
 <para>
-Regardless of your own security needs, through, you should 
+Regardless of your own security needs, though, you should 
 <emphasis>always be careful</emphasis> when signing other keys.
 It is selfish to sign a key with just enough confidence in the key's
 validity to satisfy your own security needs.
@@ -470,8 +470,8 @@
 then it is not possible to sign the key yourself.
 You must rely on the signatures of others and hope to find a chain
 of signatures leading from the key in question back to your own.
-To have any chance of finding a chain, you must take the intitive
-and get your key signed by others outside of your intitial web of trust.
+To have any chance of finding a chain, you must take the initiative
+and get your key signed by others outside of your initial web of trust.
 An effective way to accomplish this is to participate in key
 signing parties.
 If you are going to a conference look ahead of time for a key
@@ -485,7 +485,7 @@
 
 <para>
 Keep in mind, though, that this is optional.
-You have no obligation to either publically advertise your key or
+You have no obligation to either publicly advertise your key or
 sign other people's keys.
 The power of &gnupg; is that it is flexible enough to adapt to your
 security needs whatever they may be.
--- c5.sgml~	Sat Oct  2 11:54:12 1999
+++ c5.sgml	Sun Feb 27 11:35:14 2000
@@ -111,7 +112,7 @@
 For example, the specification imposes three arbitrary trust levels
 onto the user: none, marginal, and complete.
 All degrees of trust felt by the user must be fit into one of those
-three cubby holes.
+three cubbyholes.
 The key validation algorithm is also difficult for non-computer scientists
 to understand, particularly the notions of &ldquo;marginals needed&rdquo; and
 &ldquo;completes needed&rdquo;.
--- c6.sgml~	Sun Dec 19 01:25:19 1999
+++ c6.sgml	Mon Feb 21 14:12:05 2000
@@ -89,7 +89,7 @@
 
 <para>
 This command creates a signature file that can be used 
-to verify that the orginal file 
+to verify that the original file 
 <replaceable class="parameter">filename</replaceable> has not
 been changed.  
 Verification of the file using a detached signature is done using the 
@@ -157,7 +157,7 @@
 This command encrypts a document using a symmetric algorithm with
 a key derived from a passphrase supplied by you during execution.
 The key should be selected to make it difficult to randomly guess the key.
-To decrypt a document encrypted in this manner use the command.
+To decrypt a document encrypted in this manner use the command
 <link linkend="decrypt"><option>decrypt</option></link>.
 </para>
 </refsect1>
@@ -279,7 +279,7 @@
 <para>
 This command generates a private/public key pair for use in encrypting, 
 decrypting, and signing of messages.
-You will br prompted for the kind of key you wish to create, the key 
+You will be prompted for the kind of key you wish to create, the key 
 size, and the key's expiration date.
 </para>
 </refsect1>
@@ -327,7 +327,7 @@
 </refnamediv>
 <refsynopsisdiv>
 <synopsis>
-send-keys <replaceable class="parameter">key</replaceable>
+<option>send-keys</option> <replaceable class="parameter">key</replaceable>
 </synopsis>
 </refsynopsisdiv>
 
@@ -815,7 +815,7 @@
 
 <para>
 Makes a signature on the current key.
-If th  key is not yet signed by the default user or the user 
+If the key is not yet signed by the default user or the user 
 given with the option
 <link linkend="local-user"><option>local-user</option></link>, 
 the program displays the information of the key again, together with
@@ -844,7 +844,7 @@
 
 <para>
 Revoke a signature.
-Asks for each signature makde by a one of the private keys whether
+Asks for each signature made by a one of the private keys whether
 a revocation certificate should be generated.
 </para>
 </refsect2>
@@ -1081,7 +1081,7 @@
 
 <para>
 This is a shortcut for the subcommand 
-<link linkend="lsign">lsign</link>.
+<link linkend="lsign">lsign</link>
 within the command
 <link linkend="edit-key">edit-key</link>.
 </para>
--- c7.sgml~	Mon Feb  7 00:27:05 2000
+++ c7.sgml	Sat Feb 26 10:40:57 2000
@@ -78,7 +78,7 @@
 
 <para>
 This option takes the output from commands and prints it to
-the filename given to it as a parameter
+the filename given to it as a parameter.
 </para> </refsect1>
 </refentry>
 
@@ -545,7 +545,7 @@
 load-extension
 </refname>
 <refpurpose>
-specifies an extension to load.
+specifies an extension to load
 </refpurpose>
 </refnamediv>
 <refsynopsisdiv>
@@ -614,7 +614,7 @@
 <para>
 This only allows the import
 - key validation will fail and you have to check
-the  validity  of  the key my other means.  This
+the  validity  of  the key by other means.  This
 hack is needed for some  German  keys  generated
 with  pgp 2.6.3in. You should really avoid using
 it, because OpenPGP has better mechanics  to  do
@@ -885,7 +885,7 @@
 yes
 </refname>
 <refpurpose>
-assume &ldquo;yes&rdquo to most questions
+assume &ldquo;yes&rdquo; to most questions
 </refpurpose>
 </refnamediv>
 <refsynopsisdiv>
@@ -911,7 +911,7 @@
 no
 </refname>
 <refpurpose>
-assume &ldquo;no&rdquo to most questions
+assume &ldquo;no&rdquo; to most questions
 </refpurpose>
 </refnamediv>
 <refsynopsisdiv>
@@ -1021,7 +1021,7 @@
 <para>
 The filename <replaceable class="parameter">file</replaceable> may
 also be prefixed with a scheme.
-The scheme &ldquo;gnupg-ring:&rdquo makes the specified file the
+The scheme &ldquo;gnupg-ring:&rdquo; makes the specified file the
 default keyring.
 The scheme &ldquo;gnupg-gdbm:&rdquo; makes the specified file the
 GDBM ring.
@@ -1534,9 +1534,9 @@
 </title>
 
 <para>
-Option arguments following this option are assumed to be encoded
-encoded in the character set specified with the option <link
-linkend="charset"><option>charset</option></link>.
+Option arguments following this option are assumed to be
+encoded in the character set specified with the option 
+<link linkend="charset"><option>charset</option></link>.
 This is the default behavior for &gpg;.
 </para>
 </refsect1>
@@ -1563,7 +1563,7 @@
 </title>
 
 <para>
-This options is processed before an attempt is made to open an options
+This option is processed before an attempt is made to open an options
 file.
 </para>
 </refsect1>
@@ -1759,7 +1759,7 @@
 </title>
 
 <para>
-This option affects only the generation of secret keys
+This option affects only the generation of secret keys.
 Output of option (comment?) packets is disabled since version 0.4.2
 of &gnupg;.
 </para>
@@ -2020,7 +2020,7 @@
 The parameter <replaceable class="parameter">n</replaceable> sets the
 maximum length of a chain of certified keys leading from an ultimately
 trusted key to a key being validated.
-The default is 5
+The default is 5.
 </para>
 </refsect1>
 </refentry>
@@ -2053,7 +2053,7 @@
 supported digest algorithms.
 Note that this option may violate the OpenPGP requirement that a
 160-bit digest algorithm be used for DSA.
-For symmetric encryption, the default algorithm is RIPEMD-160
+For symmetric encryption, the default algorithm is RIPEMD-160.
 </para>
 </refsect1>
 </refentry>
@@ -2112,7 +2112,7 @@
 
 <para>
 The parameter <replaceable class="parameter">name</replaceable> specifies
-the name of the digest algorithm to be used for mangling passphrases
+the name of the digest algorithm to be used for mangling passphrases.
 The default algorithm is RIPEMD-160.
 </para>
 </refsect1>
@@ -2264,7 +2264,7 @@
 This option is useful for cleartext signatures on patch files.
 Messages signed this way should not be sent via email because all spaces
 and line endings are hashed too.
-This option cannot be used for data which which has five dashes at the
+This option cannot be used for data which has five dashes at the
 beginning of a line.
 A special header line is used to tell &gnupg; that this option has
 been used.
------------------------------------------------------------
--
  iida

From gnupg-doc-request@gnupg.org  Sun Mar  5 15:08:50 2000
Received: (from slist@localhost)
	by pharos.hsp.de id PAA27919;
	Sun, 5 Mar 2000 15:08:50 +0100
Resent-Date: Sun, 5 Mar 2000 15:08:50 +0100
Date: Sun, 5 Mar 2000 09:15:53 -0500 (EST)
From: "J. Michael Ashley" <jashley@ct39416-a.nblvil1.in.home.com>
Reply-To: jashley@acm.org
To: IIDA Yosiaki <y-iida@secom.co.jp>
cc: gnupg-doc@gnupg.org
Subject: Re: Possible errata for GPH English edition
In-Reply-To: <20000305081123.8682.qmail@anjyu.secom-sis.co.jp>
Message-ID: <Pine.LNX.4.10.10003050914550.5987-100000@ct39416-a.nblvil1.in.home.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Resent-Message-ID: <9W-_jC.A.I0G.ypmw4@pharos>
Resent-From: gnupg-doc@gnupg.org
X-Mailing-List: <gnupg-doc@gnupg.org> archive/latest/18
X-Loop: gnupg-doc@gnupg.org
Precedence: list
Resent-Sender: gnupg-doc-request@gnupg.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

IIDA,

Thanks for the patch.  I've reviewed, applied them, and checked them
into the CVS repository.

Mike

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjjCbBwACgkQBwMqlokEyOKY5QCcCc9WU2gbNpnnEDW8EmDvsHkK
v9sAn04EU8MrqqjiMxd4Q2DiFbuXADF1
=Ef3I
-----END PGP SIGNATURE-----

From gnupg-doc-request@gnupg.org  Tue Mar 14 19:55:48 2000
Received: (from slist@localhost)
	by pharos.hsp.de id TAA07386;
	Tue, 14 Mar 2000 19:55:48 +0100
Resent-Date: Tue, 14 Mar 2000 19:55:48 +0100
Date: Tue, 14 Mar 2000 18:39:10 +0100
From: Horacio MG <homega@ciberia.es>
To: "GPH" <gnupg-doc@gnupg.org>
Subject: GPH and WWW
Message-ID: <20000314183713.A388@ciberia.es>
Reply-To: homega@ciberia.es (Horacio)
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 1.0i
X-Editor: Vim 5.5
X-DSA/EG-KeyID: 0x42337AE6
X-RSA-KeyID: 0x32D4A925
Resent-Message-ID: <-TJv9D.A.XzB.0soz4@pharos>
Resent-From: gnupg-doc@gnupg.org
X-Mailing-List: <gnupg-doc@gnupg.org> archive/latest/19
X-Loop: gnupg-doc@gnupg.org
Precedence: list
Resent-Sender: gnupg-doc-request@gnupg.org

I am assuming that any changes to the www pages and the handbook would
be commited to the cvs and an announcement would show on
gnupg-commit-watchers@gnupg.org (thus there's been no changes for a
while), is this right?

Werner, the website is simple and effective, but a bit dull.  Don't you
think it's about time for a revamp or you rather leave it as it is now?
May be adding a few more pages, links...  feed the cow...

... may be a statement or info about Echelon?   Just a thought!


Cheers,

-- 
Horacio					Anno MMDCCLIII aUC
homega@ciberia.es			Valencia - ESPAŅA
--------------------------------------------------------------------
Key fingerprint = F4EE AE5E 2F01 0DB3 62F2  A9F4 AD31 7093 4233 7AE6

From gnupg-doc-request@gnupg.org  Wed Mar 15 10:37:21 2000
Received: (from slist@localhost)
	by pharos.hsp.de id KAA12379;
	Wed, 15 Mar 2000 10:37:21 +0100
Resent-Date: Wed, 15 Mar 2000 10:37:21 +0100
Date: Wed, 15 Mar 2000 10:42:41 +0100
From: Werner Koch <wk@gnupg.org>
To: GPH <gnupg-doc@gnupg.org>
Subject: Re: GPH and WWW
Message-ID: <20000315104241.A30386@djebel.gnupg.de>
Mail-Followup-To: GPH <gnupg-doc@gnupg.org>
References: <20000314183713.A388@ciberia.es>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.1.8i
In-Reply-To: <20000314183713.A388@ciberia.es>; from homega@ciberia.es on Tue, Mar 14, 2000 at 06:39:10PM +0100
X-URL: http://www.openit.de
X-PGP-KeyID: 621CC013
X-Request-PGP: finger:wkoch@sigtrap.guug.de        
Sender: Werner Koch <wk@gnupg.de>
Resent-Message-ID: <0S3asB.A.XBD.Rn1z4@pharos>
Resent-From: gnupg-doc@gnupg.org
X-Mailing-List: <gnupg-doc@gnupg.org> archive/latest/20
X-Loop: gnupg-doc@gnupg.org
Precedence: list
Resent-Sender: gnupg-doc-request@gnupg.org

On Tue, 14 Mar 2000, Horacio MG wrote:

> I am assuming that any changes to the www pages and the handbook would
> be commited to the cvs and an announcement would show on
> gnupg-commit-watchers@gnupg.org (thus there's been no changes for a

This is only for gnupg, but I can use this address for the other modules
too.

> Werner, the website is simple and effective, but a bit dull.  Don't you
> think it's about time for a revamp or you rather leave it as it is now?
> May be adding a few more pages, links...  feed the cow...

No time.  However, if some wants to write something up, send it to me and I
put it up.  Please read
http://www.gnu.gorg/admin/how-to-translate-the-web-pages.txt  
to learn a little bit about the scripts used to build the pages.


   Werner

From gnupg-doc-request@gnupg.org  Wed Mar 15 14:20:23 2000
Received: (from slist@localhost)
	by pharos.hsp.de id OAA23371;
	Wed, 15 Mar 2000 14:20:23 +0100
Resent-Date: Wed, 15 Mar 2000 14:20:23 +0100
Date: Wed, 15 Mar 2000 08:27:24 -0500 (EST)
From: "J. Michael Ashley" <jashley@ct39416-a.nblvil1.in.home.com>
Reply-To: jashley@acm.org
To: GnuPG documentation mailing list <gnupg-doc@gnupg.org>
Subject: solicitation for handbook additions
Message-ID: <Pine.LNX.4.10.10003150804570.1151-100000@ct39416-a.nblvil1.in.home.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Resent-Message-ID: <O2pfu.A.ItF.X44z4@pharos>
Resent-From: gnupg-doc@gnupg.org
X-Mailing-List: <gnupg-doc@gnupg.org> archive/latest/21
X-Loop: gnupg-doc@gnupg.org
Precedence: list
Resent-Sender: gnupg-doc-request@gnupg.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Guys,

I am planning to add new material to the GPH.  There are a few things in
the TODO file that need addressed, other holes in the manual to fill, and
perhaps new topics to cover.  If you have anything you'd like to see in the
manual, please let me know.  

Mike

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjjPj8IACgkQBwMqlokEyOJMwACfaZaT8F5IQXW4w/ASmemKPFrw
9+YAn3lOZ8TD3uuK2GEuMZzSo9CQQGa/
=HXxA
-----END PGP SIGNATURE-----

From gnupg-doc-request@gnupg.org  Thu Mar 23 13:09:18 2000
Received: (from slist@localhost)
	by pharos.hsp.de id NAA08574;
	Thu, 23 Mar 2000 13:09:18 +0100
Resent-Date: Thu, 23 Mar 2000 13:09:18 +0100
Date: Thu, 23 Mar 2000 07:16:59 -0500 (EST)
From: "J. Michael Ashley" <jashley@ct39416-a.nblvil1.in.home.com>
Reply-To: jashley@acm.org
To: avid <bioboy@arches.uga.edu>
cc: GnuPG documentation mailing list <gnupg-doc@gnupg.org>
Subject: Re: Gnu Privacy Handbook
In-Reply-To: <Pine.A41.4.10.10003180308540.151806-100000@arch14.cc.uga.edu>
Message-ID: <Pine.LNX.4.10.10003230655060.776-100000@ct39416-a.nblvil1.in.home.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Resent-Message-ID: <MIFB_D.A.5FC.ulg24@pharos>
Resent-From: gnupg-doc@gnupg.org
X-Mailing-List: <gnupg-doc@gnupg.org> archive/latest/22
X-Loop: gnupg-doc@gnupg.org
Precedence: list
Resent-Sender: gnupg-doc-request@gnupg.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 18 Mar 2000, avid wrote:
> I tried to check the signature
> with the provided .asc file using "gpg --verify gnupg-1.0.1.tar.gz.asc
> gnupg-1.0.1.tar.gz" as described in Chapter 2, Getting Started, and was
> greeted with
> ~
> gpg: Warning: using insecure memory!
> gpg: Signature made Thu 16 Dec 1999 04:41:03 AM EST using DSA key ID 57548DCD
> gpg: Can't check signature: public key not found
> 
> im assuming this is not a bug, and that i have done something wrong.
> But after reading the handbook i don't know what im doing wrong,

This is a hole in the manual.  In general there are several "use cases"
that the manual does not cover.  The next major revision of the manual
needs to fill in as many such gaps as possible.  I'm always happy when
readers identify them, just like you've done.

> I have, to date, read the entire handbook, excluding
> the the command reference section (which appears to be very dry reading:))

Incidentally, the command reference section is taken from the manual page
and is out-of-date, incomplete, and overall in very, very bad shape.
It's mostly useless except as a place to start with experiementation.
The purpose of getting it into the manual was to encourage comments
and suggestions for improvements, and that's happened in a few cases.
Feel free to make suggestions.

> Im hope you will agree that for gpg, and encryption in general to
> flourish it's use must not be too obtuse, obscure, in use.

Yes.

> In the narrative flow of the beginnign chapters, i.e. 1-4, it does not help
> the reader to gloss over technical details too much. 

I disagree.  The goal of the handbook is to empower users who are just
computer literate.  The handbook is missing that target, though, and is 
inadequate for for truly novice users.

I'm certain that providing more technical details is exactly the wrong
approach to take to reach the goal.  Most PGP documentation is technology
oriented, and I've had to spend time with friends explaining things
at a higher level so they can see the "big picture" before going into
the details.

Fortunately, for the geeks, though, books like Zimmerman's PGP manual
and Schneier's "Applied Cryptography" fill in the details that the GPH
currently omits.

> I would feel
> much more empowered as a document-reading user to be told where to go
> to learn more about the internals [...]
> (geeks love references, annotation, and ultimately it is geeks of greater
> or lesser degree who convince and then help their less techno-headed
> friends to use nifty new technology). 

Being helpful is healthy.  My vision, though, is a manual that allows
users to be independent of the geek community.

Mike

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjjaC0EACgkQBwMqlokEyOKN8gCff0EXeeGpG5UyMCOF64B9ZoWK
73UAoOQcePcH6cO7kfAsLJOfY6I+lGHW
=1FGl
-----END PGP SIGNATURE-----