--- pgp/doc/newfor23.doc 2018/04/24 16:41:29 1.1.1.2 +++ pgp/doc/newfor23.doc 2018/04/24 16:42:45 1.1.1.3 @@ -1,100 +1,100 @@ -News for PGP 2.3a - -There was a bug in PGP's handling of clear-signed messages when lines -were terminated with CR-LF pairs. This has been revamped. The previous -limit on the length of lines in clear-signed messages has been eliminated. - -The randseed.bin file was not closed when read, which resulted in it -not being rewritten with a new value under some operating systems. -Fixed. - -Not all of the bytes in randseed.bin were being used, resulting in less -randomness than desired when picking session keys. While it did not make -the compromise of session keys likely, it was undesirable and has been fixed. - -PGP should now compile with less difficulty under OS/2. -The Turbo C makefile was incorrect. Fixed. -The VMS build files were out of date. Fixed. - -PGP was not accepting octal escapes in the language.txt file that did not -begin with \0. \377 is now acceptable. -The language.txt file got mangled in the middle somehow. Fixed. - -News for PGP 2.3 - -This PGP 2.3 release has several bug fixes over PGP 2.2, and a few -new (although somewhat esoteric) features. Among them are: - -- An important bug: there was a bug with compression under MS-DOS which - caused the wrong piece of memory to be freed, with results that ranged - from none to undecodable messages to machine crashes. - -- When adding keys, PGP now properly closes all the files it opens, so - you don't run out of file handles (MS-DOS) or file descriptors (UNIX). - -- Sometimes PGP would not properly ask the user to set trust parameters - when keys were validated by adding new signatures. This has been - fixed. - -- When PGP messages are sent through a MIME mail system, a conflict - arises over the use of the '=' character. PGP can now decode ASCII - armored messages which have been mangled by MIME's quoting mechanism. - -- PGP previously kept track of one pass phrase (from the PGPPASS - environment variable, the file descriptor named by the PGPPASSFD - environment variable, a -z option, or previous user - prompts), and tried it if it needed a subsequent pass phrase. This - caused bugs if you attempted something that required two pass phrases, - such as pgp -sc (sign and conventionally encrypt). PGP now keeps - track of any number of pass phrases, including multiple -z options, - and uses them as necessary. Mostly, it just Does The Right Thing, - but if you care, the exact algorithm is as follows: - - - There is a pool of private-key pass phrases that starts out with the - contents of the PGPPASS environment variable (if any), and has every - pass phrase that is successfully used to unlock a private key added - to it. When a private key needs unlocking, every pass phrase in the - pool is tried first. - - There is a list of PGP pass phrases available for use by whatever needs - one. This is initialized with the -z command-line options and the - phrase read from the PGPPASSFD file descriptor. When a pass phrase - is needed, it is taken from the front of that list. When a pass - phrase is needed to unlock a secret key, every key on the list is tried, - and if it "fits" and unlocks the secret key, it is moved to the key - pass phrase pool. - - If the above fails to produce a pass phrase, the user is prompted to - supply one. - - Key generation (we need all the keystrokes we can get for random-number - accumulation) and key signing (to make sure the user really means to do - what they're doing) are exceptions; the user is always prompted for a - pass phrase under those circumstances. - -New options: - -+pkcs_compat=n - This defaults to 1, which tells PGP to generate encryption key - and signature blocks in a format derived from the PKCS standards. - This format is understood (but not generated) by PGP 2.2. If set - to 0, the old format is generated, which may be needed for - portability to PGP versions before 2.2. PGP is still incompatible - with the PKCS standards in many ways, but in future, values of 2 - or higher may be used to produce formats which are more compatible. - -Other notes: - -The MS-DOS executable was compiled with Borland C++ version 3.0, optimized -for maximum speed, except that jump optimisation was turned off. If it -is turned on, the Transform() function in md5.c is compiled incorrectly. -The pgp.prj file that was used is included in the source distribution. - -Thanks to everyone who worked on PGP and sent in bug reports. Two who -didn't make it into the manual are to Lindsay DuBois for a bit of last- -minute translation, and Reptilian Research for support in developing PGP. - -And thanks to the Cypherpunks who managed to get PGP so much attention -in Wired magazine recently. - -I hope you enjoy PGP! - - -Colin +News for PGP 2.3a + +There was a bug in PGP's handling of clear-signed messages when lines +were terminated with CR-LF pairs. This has been revamped. The previous +limit on the length of lines in clear-signed messages has been eliminated. + +The randseed.bin file was not closed when read, which resulted in it +not being rewritten with a new value under some operating systems. +Fixed. + +Not all of the bytes in randseed.bin were being used, resulting in less +randomness than desired when picking session keys. While it did not make +the compromise of session keys likely, it was undesirable and has been fixed. + +PGP should now compile with less difficulty under OS/2. +The Turbo C makefile was incorrect. Fixed. +The VMS build files were out of date. Fixed. + +PGP was not accepting octal escapes in the language.txt file that did not +begin with \0. \377 is now acceptable. +The language.txt file got mangled in the middle somehow. Fixed. + +News for PGP 2.3 + +This PGP 2.3 release has several bug fixes over PGP 2.2, and a few +new (although somewhat esoteric) features. Among them are: + +- An important bug: there was a bug with compression under MS-DOS which + caused the wrong piece of memory to be freed, with results that ranged + from none to undecodable messages to machine crashes. + +- When adding keys, PGP now properly closes all the files it opens, so + you don't run out of file handles (MS-DOS) or file descriptors (UNIX). + +- Sometimes PGP would not properly ask the user to set trust parameters + when keys were validated by adding new signatures. This has been + fixed. + +- When PGP messages are sent through a MIME mail system, a conflict + arises over the use of the '=' character. PGP can now decode ASCII + armored messages which have been mangled by MIME's quoting mechanism. + +- PGP previously kept track of one pass phrase (from the PGPPASS + environment variable, the file descriptor named by the PGPPASSFD + environment variable, a -z option, or previous user + prompts), and tried it if it needed a subsequent pass phrase. This + caused bugs if you attempted something that required two pass phrases, + such as pgp -sc (sign and conventionally encrypt). PGP now keeps + track of any number of pass phrases, including multiple -z options, + and uses them as necessary. Mostly, it just Does The Right Thing, + but if you care, the exact algorithm is as follows: + + - There is a pool of private-key pass phrases that starts out with the + contents of the PGPPASS environment variable (if any), and has every + pass phrase that is successfully used to unlock a private key added + to it. When a private key needs unlocking, every pass phrase in the + pool is tried first. + - There is a list of PGP pass phrases available for use by whatever needs + one. This is initialized with the -z command-line options and the + phrase read from the PGPPASSFD file descriptor. When a pass phrase + is needed, it is taken from the front of that list. When a pass + phrase is needed to unlock a secret key, every key on the list is tried, + and if it "fits" and unlocks the secret key, it is moved to the key + pass phrase pool. + - If the above fails to produce a pass phrase, the user is prompted to + supply one. + + Key generation (we need all the keystrokes we can get for random-number + accumulation) and key signing (to make sure the user really means to do + what they're doing) are exceptions; the user is always prompted for a + pass phrase under those circumstances. + +New options: + ++pkcs_compat=n + This defaults to 1, which tells PGP to generate encryption key + and signature blocks in a format derived from the PKCS standards. + This format is understood (but not generated) by PGP 2.2. If set + to 0, the old format is generated, which may be needed for + portability to PGP versions before 2.2. PGP is still incompatible + with the PKCS standards in many ways, but in future, values of 2 + or higher may be used to produce formats which are more compatible. + +Other notes: + +The MS-DOS executable was compiled with Borland C++ version 3.0, optimized +for maximum speed, except that jump optimisation was turned off. If it +is turned on, the Transform() function in md5.c is compiled incorrectly. +The pgp.prj file that was used is included in the source distribution. + +Thanks to everyone who worked on PGP and sent in bug reports. Two who +didn't make it into the manual are to Lindsay DuBois for a bit of last- +minute translation, and Reptilian Research for support in developing PGP. + +And thanks to the Cypherpunks who managed to get PGP so much attention +in Wired magazine recently. + +I hope you enjoy PGP! + + -Colin