From gnupg-doc-request@gnupg.org Mon Jul 3 06:35:40 2000 Received: (from slist@localhost) by pharos.hsp.de id GAA06176; Mon, 3 Jul 2000 06:35:40 +0200 Resent-Date: Mon, 3 Jul 2000 06:35:40 +0200 From: y-iida@secom.co.jp Message-ID: <95073BDE9378D311BB21009027AFCA86021F3255@exs01.intra.secom.co.jp> Reply-To: gnupg-doc@gnupg.org To: gnupg-doc@gnupg.org Subject: Possible errata for DETAILS file Date: Mon, 3 Jul 2000 13:35:19 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-2022-jp" Resent-Message-ID: <5OB6h.A.dgB.cgBY5@pharos> Resent-From: gnupg-doc@gnupg.org X-Mailing-List: archive/latest/37 X-Loop: gnupg-doc@gnupg.org Precedence: list Resent-Sender: gnupg-doc-request@gnupg.org --- ../share/src/gnupg/gnupg-1.0.1h/doc/DETAILS Tue Jun 27 19:09:26 2000 +++ DETAILS Sun Jul 2 19:13:02 2000 @@ -119,7 +119,7 @@ The signature key has expired. No arguments yet. KEYREVOKED - The used key has been revoked by his owner. No arguments yet. + The used key has been revoked by its owner. No arguments yet. BADARMOR The ASCII armor is corrupted. No arguments yet. @@ -198,7 +198,7 @@ BEGIN_DECRYPTION END_DECRYPTION Mark the start and end of the actual decryption process. These - are also emmited when in --list-only mode. + are also emitted when in --list-only mode. BEGIN_ENCRYPTION END_ENCRYPTION @@ -214,7 +214,7 @@ "char" is the character displayed with no --status-fd enabled, with the linefeed replaced by an 'X'. "cur" is the current amount done and "total" is amount to be done; a "total" of 0 indicates that - the toatal amount is not known. 100/100 may be used to detect the + the total amount is not known. 100/100 may be used to detect the end of operation. SIG_CREATED @@ -263,31 +263,31 @@ There is an experimental feature which allows for unattended generation of keys controlled by a parameter file. This feature is not very well tested and does only make sense for some -very special applications. Please don't complain if we decide to chnage +very special applications. Please don't complain if we decide to change the behaviour of this command. To use this feature, you use --gen-key together with --batch and feed the -parameters either form stdin or from a file given on the commandline. +parameters either from stdin or from a file given on the commandline. The format of this file is as follows: o Text only, line length is limited to about 1000 chars. - o You must use UTF-8 encoding to specifiy non-ascii characters. - o Empty lines are ignored - o Leading and trailing spaces are ignored - o A hash sign as the first non white space character indicates a comment line + o You must use UTF-8 encoding to specify non-ascii characters. + o Empty lines are ignored. + o Leading and trailing spaces are ignored. + o A hash sign as the first non white space character indicates a comment line. o Control statements are indicated by a leading percent sign, the arguments are separated by white space from the keyword. o Parameters are specified by a keyword, followed by a colon. Arguments - are speparated by white space. + are separated by white space. o The first parameter must be "Key-Type", control statements may be placed anywhere. o Key generation takes place when either the end of the parameter file is reached, the next "Key-Type" parameter is encountered or at the controlstatement "%commit" - o Control staements: + o Control statements: %echo - Print + Print . %dry-run - Suppress actual key generation (useful for syntax checking) + Suppress actual key generation (useful for syntax checking). %commit Perform the key generation. An implicit commit is done at the next "Key-Type" parameter. @@ -302,8 +302,8 @@ this file is created (and overwrites an existing one). Both control statements must be given. o The order of the parameters does not matter except for "Key-Type" - which must be the first parameter. The paramtyers are only for the - generated keyblock and paramters from previous key generations are not + which must be the first parameter. The parameters are only for the + generated keyblock and parameters from previous key generations are not used. Some syntactically checks may be performed. The currently defined parameters are: Key-Type: | @@ -311,7 +311,7 @@ primary key. The algorithm must be capable of signing. This is a required parameter. Key-Length: - Length of the key in bits. Default is 1024 + Length of the key in bits. Default is 1024. Subkey-Type: | This generates a secondary key. Currently only one subkey can be handled. @@ -476,16 +476,16 @@ 1 u32 next next sigrec of this uid or 0 to indicate the last sigrec. 6 times - 1 u32 Local_id of signators dir or shadow dir record + 1 u32 Local_id of signatures dir or shadow dir record 1 byte Flag: Bit 0 = checked: Bit 1 is valid (we have a real directory record for this) - 1 = valid is set (but my be revoked) + 1 = valid is set (but may be revoked) Record type 8: (shadow directory record) -------------- - This record is used to reserved a LID for a public key. We + This record is used to reserve a LID for a public key. We need this to create the sig records of other keys, even if we do not yet have the public key of the signature. This record (the record number to be more precise) will be reused @@ -614,7 +614,7 @@ + future extensions. These length markers must be inserted into the data + stream just before writing the data out. + -+ This 2 byte filed is large enough, because the application must buffer ++ This 2 byte field is large enough, because the application must buffer + this amount of data to prepend the length marker before writing it out. + Data block sizes larger than about 32k doesn't make any sense. Note + that this may also be used for compressed data streams, but we must use @@ -633,8 +633,8 @@ Usage of gdbm files for keyrings ================================ - The key to store the keyblock is it's fingerprint, other records - are used for secondary keys. fingerprints are always 20 bytes + The key to store the keyblock is its fingerprint, other records + are used for secondary keys. Fingerprints are always 20 bytes where 16 bit fingerprints are appended with zero. The first byte of the key gives some information on the type of the key. @@ -742,11 +742,11 @@ keys. -A better way to to this would be a request like: +A better way to do this would be a request like: /pks/lookup/?op= -this can be implemented using Hurd's translator mechanism. +This can be implemented using Hurd's translator mechanism. However, I think the whole key server stuff has to be re-thought; I have some ideas and probably create a white paper. -- iida From gnupg-doc-request@gnupg.org Tue Jul 4 14:14:00 2000 Received: (from slist@localhost) by pharos.hsp.de id OAA13212; Tue, 4 Jul 2000 14:14:00 +0200 Resent-Date: Tue, 4 Jul 2000 14:14:00 +0200 From: y-iida@secom.co.jp Message-ID: <95073BDE9378D311BB21009027AFCA86021F3266@exs01.intra.secom.co.jp> Reply-To: gnupg-doc@gnupg.org To: gnupg-doc@gnupg.org Subject: Possible errata for FAQ file Date: Tue, 4 Jul 2000 21:13:45 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Resent-Message-ID: Resent-From: gnupg-doc@gnupg.org X-Mailing-List: archive/latest/38 X-Loop: gnupg-doc@gnupg.org Precedence: list Resent-Sender: gnupg-doc-request@gnupg.org --- ../share/src/gnupg/gnupg-1.0.1h/doc/FAQ Mon Jun 5 21:34:34 2000 +++ FAQ Mon Jul 3 14:35:42 2000 @@ -126,7 +126,7 @@ gpg --rfc1991 --cipher-algo 3des ... Please don't pipe the data to encrypt to gpg but give it as a filename; - other wise, pgp 2 will not be able to handle it. + otherwise, pgp 2 will not be able to handle it. Q: How can I conventional encrypt a message, so that PGP can decrypt it? A: You can't do this for PGP 2. For PGP 5 you should use this: @@ -145,7 +145,7 @@ we (on Linux the /dev/random device) must collect some random data. It is really not easy to fill the Linux internal entropy buffer; I talked to Ted Ts'o and he commented that the best way to fill the buffer - is to play with your keyboard. Good security has it's price. What I do + is to play with your keyboard. Good security has its price. What I do is to hit several times on the shift, control, alternate, and capslock keys, because these keys do not produce output to the screen. This way you get your keys really fast (it's the same thing pgp2 does). @@ -187,7 +187,7 @@ q = Undefined (no value assigned) n = Don't trust this key at all m = There is marginal trust in this key - f = The key is full trusted. + f = The key is full trusted u = The key is ultimately trusted; this is only used for keys for which the secret key is also available. @@ -282,7 +282,7 @@ other keys. "validity", or calculated trust, is a value which says how much GnuPG thinks a key is valid (that it really belongs to the one who claims to be the owner of the key). - For more see the chapter "The Web of Trust" in the Manual + For more see the chapter "The Web of Trust" in the Manual. Q: How do I interpret some of the informational outputs? A: While checking the validity of a key, GnuPG sometimes prints @@ -342,7 +342,7 @@ where pgpkeyring is the original keyring and not the GnuPG one you might have created in the first step. - Q: Are the headerlines of a cleartext signater part of the signed + Q: Are the headerlines of a cleartext signature part of the signed material? A: No. For example you can add or remove "Comment:" lines. They have a purpose like the mail header lines. However a "Hash:" @@ -357,7 +357,7 @@ Q: PGP 5.x, 6.x does not like my secret key. A: PGP probably bails out on some private comment packets used by GnuPG. These packets are fully in compliance with OpenPGP; however PGP is not - really OpenPGP aware. A workaround is to eport the secret keys with + really OpenPGP aware. A workaround is to export the secret keys with this command: gpg --export-secret-keys --no-comment -a your-key-id @@ -376,7 +376,7 @@ A: You should use the option --batch and don't use passphrases as there is usually no way to store it more secure than the secret keyring itself. The suggested way to create the keys for the - automated envirionment ist: + automated environment is: On a secure machine: 1. If you want to do automatic signing, create a signing subkey for your key (edit menu, choose "addkey" and the DSA). @@ -384,7 +384,7 @@ implementation) 3. gpg --export-secret-subkeys --no-comment foo >secring.auto 4. Copy secring.auto and the public keyring to a test directory. - 5. Cd to this diectory + 5. Cd to this diectory. 6. gpg --homedir . --edit foo and use "passwd" to remove the passphrase from the subkeys. You may also want to remove all unused subkeys. -- iida From gnupg-doc-request@gnupg.org Thu Jul 6 12:38:55 2000 Received: (from slist@localhost) by pharos.hsp.de id MAA06437; Thu, 6 Jul 2000 12:38:55 +0200 Resent-Date: Thu, 6 Jul 2000 12:38:55 +0200 From: y-iida@secom.co.jp Message-ID: <95073BDE9378D311BB21009027AFCA86021F3270@exs01.intra.secom.co.jp> To: gnupg-doc@gnupg.org Subject: Erratum for gpg.sgml file Date: Thu, 6 Jul 2000 19:38:37 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Resent-Message-ID: Resent-From: gnupg-doc@gnupg.org X-Mailing-List: archive/latest/39 X-Loop: gnupg-doc@gnupg.org Precedence: list Resent-Sender: gnupg-doc-request@gnupg.org --- gpg.sgml Thu Jul 6 00:17:48 2000 +++ - Thu Jul 6 09:17:50 2000 @@ -805,7 +805,7 @@ Set the name of the native character set. This is used to convert some strings to proper UTF-8 encoding. -Valid values for &ParmName; are: +Valid values for &ParmName; are: iso-8859-1This is the default Latin 1 set. -- iida From gnupg-doc-request@gnupg.org Mon Jul 10 12:57:19 2000 Received: (from slist@localhost) by mail.hsp.de (8.10.2/8.10.2) id e6AAvJb10738; Mon, 10 Jul 2000 12:57:19 +0200 Resent-Date: Mon, 10 Jul 2000 12:57:19 +0200 Date: Mon, 10 Jul 2000 13:13:56 +0200 From: Lord of the Lists To: gnupg-doc@gnupg.org Subject: Re: Extensive coverage in Japanese Message-ID: <20000710131356.P1050@djebel.gnupg.de> Mail-Followup-To: gnupg-doc@gnupg.org References: <200007100943.CAA31196@server-1.visp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.8i In-Reply-To: <200007100943.CAA31196@server-1.visp.net>; from hideki@allcity.net on Mon, Jul 10, 2000 at 11:43:05AM +0200 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: Werner Koch Resent-Message-ID: Resent-From: gnupg-doc@gnupg.org X-Mailing-List: archive/latest/41 X-Loop: gnupg-doc@gnupg.org Precedence: list Resent-Sender: gnupg-doc-request@gnupg.org On Mon, 10 Jul 2000, Hideki Saito wrote: > Of course, this is quite useless unless you can read Japanese ;) Looks funny :-) > Also, am I supporsed to use GnuPG logo? (If there's problem I'll > remove it right away) No problem. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From gnupg-doc-request@gnupg.org Mon Jul 24 13:47:44 2000 Received: (from slist@localhost) by mail.hsp.de (8.10.2/8.10.2) id e6OBlix12260; Mon, 24 Jul 2000 13:47:44 +0200 Resent-Date: Mon, 24 Jul 2000 13:47:44 +0200 From: y-iida@secom.co.jp Message-ID: <95073BDE9378D311BB21009027AFCA86021F32C6@exs01.intra.secom.co.jp> Reply-To: gnupg-doc@gnupg.org To: gnupg-doc@gnupg.org Subject: Possible errata for gpg.sgml file Date: Mon, 24 Jul 2000 20:47:22 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Resent-Message-ID: Resent-From: gnupg-doc@gnupg.org X-Mailing-List: archive/latest/42 X-Loop: gnupg-doc@gnupg.org Precedence: list Resent-Sender: gnupg-doc-request@gnupg.org Hi. Enjoy the patch at the end. For me, ``anem muts'' was very tough! I hope that it is the correct one. --- gpg.sgml~ Sat Jul 22 20:21:05 2000 +++ gpg.sgml Sun Jul 23 15:10:29 2000 @@ -160,8 +160,8 @@ --verify-files This is a special version of the --verify command which does not work with -detached signatures. The command expects the files to bee verified either -on the commandline or reads the filenames from stdin; each anem muts be on +detached signatures. The command expects the files to be verified either +on the commandline or reads the filenames from stdin; each name must be on separate line. The command is intended for quick checking of many files. @@ -440,7 +440,7 @@ Same as --export, but does export the secret keys. This is normally not very useful and a security risk. -the second form of the command has the special property to +The second form of the command has the special property to render the secret part of the primary key useless; this is a GNU extension to OpenPGP and other implementations can not be expected to successful import such a key. @@ -770,8 +770,8 @@ --keyring &ParmFile; -Add &ParmFile to the list of keyrings. -If &ParmFile begins with a tilde and a slash, these +Add &ParmFile; to the list of keyrings. +If &ParmFile; begins with a tilde and a slash, these are replaced by the HOME directory. If the filename does not contain a slash, it is assumed to be in the home-directory ("~/.gnupg" if --homedir is not used). @@ -1101,7 +1101,7 @@ --escape-from-lines Because some mailers change lines starting with "From " -to "<From " it is good to handle such lines in a special +to ">From " it is good to handle such lines in a special way when creating cleartext signatures. All other PGP versions do it this way too. This option is not enabled by default because it would violate rfc2440. @@ -1221,7 +1221,7 @@ GnuPG uses a file to store it's internal random pool over invocations. This makes random generation faster; however sometimes write operations -are not desired. This option can be used to achive that with the cost of +are not desired. This option can be used to achieve that with the cost of slower random generation. @@ -1297,7 +1297,7 @@ Changes the output of the list commands to work faster; this is achieved by leaving some parts empty. Some applications don't need the user ID and the trust information given in the listings. By using this options they -can get a faster listing. The excact behaviour of this option may change +can get a faster listing. The exact behaviour of this option may change in future versions. @@ -1473,7 +1473,7 @@ Verify the signature of the file but do not output the data. The second form is used for detached signatures, where