Mailing List Archive: 0.9.1

0.9.1

Jan 9, 1999, 12:01 PM

Post #1 of 18 (836 views)

Hi,

I have just released version 0.9.1 of GnuPG. This release fixes some
of the bugs which showed up since the 0.9.0 and some of the long
outstanding bugs. There are still other bugs and due to some complete
recoding old bugs may occur ;-)

ftp://ftp.gnupg.org/pub/gcrypt/gnupg-0.9.1.tar.gz (978k)

or a diff against 0.9.0

ftp://ftp.gnupg.org/pub/gcrypt/diffs/gnupg-0.9.1.diff.gz (118k)

This one is not signed becuase I found out too late that the
verification of not-dash-escaped files does not work anymore.

Werner

Noteworthy changes in version 0.9.1
-----------------------------------

* Polish language support.

* When querying the passphrase, the key ID of the primary key is
displayed along with the one of the used secondary key.

* Fixed a bug occurring when decrypting pgp 5 encrypted messages,
fixed an infinite loop bug in the 3DES code and in the code
which looks for trusted signatures.

* Fixed a bug in the mpi library which caused signatures not to
compare okay.

* Rewrote the handling of cleartext signatures; the code is now
better maintainable (I hope so).

* New status output VALIDSIG only for valid signatures together
with the fingerprint of the signer's key.

Bugs
----
* clearsig: keep lineendings as they are. Remember that trailings
blanks are not hashed. Funny: pgp263in works fine even with
a source file with CR,LF but GnuPG and pgp263in has problems
if the clearsign has been created by pgp263ia.
Needs more investigation - anyone?

Important
----------
* Check revocation and expire stuff. PLEASE: THIS MUST BE TESTED!

* Check calculation of key validity. PLEASE: IT IS IMPORTED THAT
THIS GET TESTED.

* It has been reported that lockfiles are not removed in all cases.
cleanup is done with atexit() and all signals trigger exit() -
anything wrong with this? - ah yes: a signal while still in
dotlock_make

* See why we always get this "Hmmm public key lost"

* print a warning when a revoked/expired secret key is used.

* Allow the use of a the faked RNG only for keys which are
flagged as INSECURE.

Needed
------
* remove more "Fixmes"

* Replace Blowfish by Twofish and add the new encrypted packet typ
which has a MACing option (append SHA1 hash to the plaintext and
encrypt this all) - We need an identifier for Twofish to put this
one into the cipher preferences.

* The -export-dynamic flag to ld works only for FreeBSD 3.0. It does
not exist on FreeBSD's 2.2.x version of ld.
Also, on my FreeBSD 2.2-stable box, i simply removed the
-Wl,-export-dynamic flag from my Makefile and it linked and seems to
be working OK so far.

Re: 0.9.1 [ In reply to ]

md at linux

Jan 9, 1999, 3:23 PM

Post #2 of 18 (833 views)

Permalink

On Jan 09, Werner Koch <wk@isil.d.shuttle.de> wrote:

(this just to let Italian users know that I'm not dead)

>I have just released version 0.9.1 of GnuPG. This release fixes some
I'm sorry but I haven't translated yet last two releases.
I hope to update the translation before next month.

--
ciao,
Marco

Re: 0.9.1 [ In reply to ]

walterk at dip

Jan 9, 1999, 6:07 PM

Post #3 of 18 (830 views)

Permalink

Moin,

>I have just released version 0.9.1 of GnuPG.

Is "(main key ... " the same as "primary key" ?

Gruss,
Walter
--
Walter Koch Hochdahl am Neandertal
walterk@mail.dip.de ham:dg9ep@db0iz
http://home.pages.de/~dg9ep/ qrv:db0iz-9

Re: 0.9.1 [ In reply to ]

wk at isil

Jan 10, 1999, 5:57 AM

Post #4 of 18 (831 views)

Permalink

Walter Koch <walterk@dip.de> writes:

> >I have just released version 0.9.1 of GnuPG.
>
> Is "(main key ... " the same as "primary key" ?

Yes. Only used to keep the line below 80 chars. I can change it if
this leads to confusion.

Re: 0.9.1 [ In reply to ]

warner at lothar

Jan 10, 1999, 6:07 AM

Post #5 of 18 (830 views)

Permalink

0.9.1: I get some occasional segfaults during 'make check' unless I use
--with-included-zlib. It's strange, I have zlib-1.1.2 on one machine, and
zlib-1.1.3 on another, and both of them fail on occasion (maybe half of the
time) when built with just ./configure, but both pass tests solidly several
times in a row when built with --with-included-zlib.

mailcrypt-gpg: there's a one-character patch in mc-gpg.el needed to handle the
extra keyid emitted in the NEED_PASSPHRASE status message. I'll be fixing some
other stuff and will put a new patch up on my web site
<http://www.lothar.com/tech/crypto/> soon, but in case anyone suddenly finds
decryption failing (symptom: mailcrypt asks you for a "password for
conventional encryption" all the time), try removing the "$" from line 526 of
mc-gpg.el that says

(if (re-search-forward "NEED_PASSPHRASE \$\\S +\$$" nil t)

cheers,
-Brian

Re: 0.9.1 [ In reply to ]

wk at isil

Jan 10, 1999, 6:09 AM

Post #6 of 18 (833 views)

Permalink

Marco d'Itri <md@linux.it> writes:

> >I have just released version 0.9.1 of GnuPG. This release fixes some
> I'm sorry but I haven't translated yet last two releases.
> I hope to update the translation before next month.

That's okay. I'll tell you when it is time to check that the
translations are all okay for the 1.0

Werner

Re: 0.9.1 [ In reply to ]

wk at isil

Jan 10, 1999, 6:41 AM

Post #7 of 18 (830 views)

Permalink

Brian Warner <warner@lothar.com> writes:

> 0.9.1: I get some occasional segfaults during 'make check' unless I use
> --with-included-zlib. It's strange, I have zlib-1.1.2 on one machine, and
> zlib-1.1.3 on another, and both of them fail on occasion (maybe half of the

So I'll better keep 1.0.4 for now as the included version.
I should check this.

Re: 0.9.1 [ In reply to ]

jam at jamux

Jan 10, 1999, 3:54 PM

Post #8 of 18 (835 views)

Permalink

Is this pubring stuff a problem or just a kink? Should gpg wait to
try to grab the pubring until it has something to do?

-------------- cut here ---->8 ---< head
$ echo Helo | gpg --clearsign

You need a passphrase to unlock the secret key for
user: "John A. Martin <jam@acm.org>"
1024-bit DSA key, ID BFE25F2F, created 1998-09-19

Enter passphrase:
gpg: Interrupt caught ... exiting
$
$ echo Helo | gpg --clearsign | gpg
gpg: /home/jam/.gnupg/pubring.gpg: can't open gdbm file: Can't be writer
gpg: keyblock resource `/home/jam/.gnupg/pubring.gpg': file open error
gpg: OOPS in close enum_keyblocks - ignored
gpg: key BFE25F2F: secret key without public key - skipped
gpg: OOPS in close enum_keyblocks - ignored
gpg: key 3B986635: secret key without public key - skipped

You need a passphrase to unlock the secret key for
user: "John A. Martin <jam@acm.org>"
1024-bit DSA key, ID BFE25F2F, created 1998-09-19

Enter passphrase:
gpg: Interrupt caught ... exiting

gpg: Interrupt caught ... exiting
$
$ grep -v '^#' ~/.gnupg/options

no-greeting
lock-once
keyring gnupg-gdbm:~/.gnupg/pubring.gpg
no-default-keyring

load-extension skipjack
load-extension tiger
load-extension twofish

escape-from-lines
---- 8<------- cut here ----------> tail

Same without lock-once.

How about letting something like 'gpg --version -v', list the
effective options?

jam

Re: 0.9.1 [ In reply to ]

wk at isil

Jan 11, 1999, 1:22 PM

Post #9 of 18 (830 views)

Permalink

"John A. Martin" <jam@jamux.com> writes:

> Is this pubring stuff a problem or just a kink? Should gpg wait to
> try to grab the pubring until it has something to do?

problematic: The secret keys are checked on startup and therefore we
need to read some keys from the pubring. Someting for finetuning.

> gpg: /home/jam/.gnupg/pubring.gpg: can't open gdbm file: Can't be writer
> gpg: keyblock resource `/home/jam/.gnupg/pubring.gpg': file open error
> gpg: OOPS in close enum_keyblocks - ignored

Ooops :-)

> How about letting something like 'gpg --version -v', list the
> effective options?

Okay.

Re: 0.9.1 [ In reply to ]

steve at gbnet

Jan 11, 1999, 5:23 PM

Post #10 of 18 (831 views)

Permalink

On Sat, Jan 09, 1999 at 08:01:36PM +0100, Werner Koch wrote:

> I have just released version 0.9.1 of GnuPG. This release fixes some
> of the bugs which showed up since the 0.9.0 and some of the long
> outstanding bugs. There are still other bugs and due to some complete
> recoding old bugs may occur ;-)
> ftp://ftp.gnupg.org/pub/gcrypt/gnupg-0.9.1.tar.gz (978k)

I'm still getting undefined macros
(i.e. ./configure: syntax error at line 555: `AM_CONFIG_HEADER' unexpected ?)

This is on Solaris 2.6, using Sun Sparcworks ...

Any ideas ?

Steve

--
NetTek Ltd tel +44-171 483 1169 fax +44-181 444 6103
Flat 2, 43 Howitt Road, Belsize Park, London NW3 4LU
Epage steve-pager@gbnet.net [body of text only]

Re: 0.9.1 [ In reply to ]

Bodo_Moeller at public

Jan 11, 1999, 11:34 PM

Post #11 of 18 (830 views)

Permalink

Werner Koch <wk@isil.d.shuttle.de>:

> I have just released version 0.9.1 of GnuPG. [...]

I compiled it on a Solaris 2.6 system. When I tried to create a key,
it looked as if the program froze at the moment when actual key
creation was to begin. After having set the GNUPG_RNDUNIX_DBG and
GNUPG_RNDUNIX_DBGALL environment variables and trying again I found
out that nothing could have been further from the truth: rndunix's
slow random polling function was busily executing over and over again
(without finding too much randomness), and the program never had
enough. After some 10000 lines of debugging output, I stopped it (and
manually added things like "xwd -root" to the slow poll command table,
which finally got me my key).

As a quick workaround, rndunix could give up after some attempts if it
cannot gather enough randomness. Then the usual "INSECURE"
warning/error messages should be generated (as in the dummy random
number generator case) -- at least the user will know what is going
wrong.

In the long run, probably there should be some provisions for random
seeding in the option/configuration file parser (possibly with support
for something like PGP's randseed.bin -- with manual randomness
gathering via keyboard timings for slow interactive commands such as
key generation and automatic [low-entropy] randomness updating for
non-interactive or "less-interactive" commands such as encryption).

Re: 0.9.1 [ In reply to ]

wk at isil

Jan 12, 1999, 12:46 AM

Post #12 of 18 (830 views)

Permalink

Bodo Moeller <Bodo_Moeller@public.uni-hamburg.de> writes:

> Werner Koch <wk@isil.d.shuttle.de>:
>
> slow random polling function was busily executing over and over again
> (without finding too much randomness), and the program never had
> enough. After some 10000 lines of debugging output, I stopped it (and
> manually added things like "xwd -root" to the slow poll command table,

xwd -root yields more than one meg of data but I have some doubts that
there is much random in it.

Is here someone how as experience with Peter Gutmann's crtlib on
Solaris?

> warning/error messages should be generated (as in the dummy random
> number generator case) -- at least the user will know what is going

Or print a notice like the /dev/random code does.

> In the long run, probably there should be some provisions for random
> seeding in the option/configuration file parser (possibly with support
> for something like PGP's randseed.bin -- with manual randomness
> gathering via keyboard timings for slow interactive commands such as
> key generation and automatic [low-entropy] randomness updating for
> non-interactive or "less-interactive" commands such as encryption).

Or tell Sun to implement Tytso's /dev/random which has a BSD style
license. I'd prefer such a sulution.

Werner

Re: 0.9.1 [ In reply to ]

warner at lothar

Jan 12, 1999, 2:19 AM

Post #13 of 18 (832 views)

Permalink

wk@isil.d.shuttle.de (Werner Koch) writes:
> Or tell Sun to implement Tytso's /dev/random which has a BSD style
> license. I'd prefer such a sulution.

I've been pondering this a bit.. (I had a similar problem, trying the
self-tests on my solaris box.. it took maybe an hour or so, driving the load
average up to about 10 in the meantime. Half the tests failed with "bus
errors" but that's another matter).

If we turned the rndunix code into a persistent daemon, with a pair of unix
sockets to correspond to /dev/random and /dev/urandom, couldn't that drop into
place on any system that supported such sockets? It could have internal timers
and run all manners of strange programs to obtain entropy, it could maintain
an entropy count and block on reads of /tmp/random when the entropy was low.
There would be issues of "should it be started automatically" and if so,
should it die automatically, but users (like me) who know what it does would
just start it from rc.local and let it live forever.

Except for the lack of the special ioctls (to measure or change entropy
count), would such a device be at all discernible from the real kernel-based
/dev/random?

ponderously,
-Brian

Re: 0.9.1 [ In reply to ]

wk at isil

Jan 12, 1999, 3:53 AM

Post #14 of 18 (832 views)

Permalink

Brian Warner <warner@lothar.com> writes:

> If we turned the rndunix code into a persistent daemon, with a pair of unix
> sockets to correspond to /dev/random and /dev/urandom, couldn't that drop into

That's the way we do it. It also has the advantage that we don't have
to care about GPL/cryptlib license conflicts. I'd suggest not to call
it /tmp/[u]random but /tmp/[u]entropy and use a message format to
pass information about the entroy quality along with the bytes of
entropy.

What's need is a buffer as the entropy pool. The /dev/random code
together with the current rndunix.c is a goof starting point for such
a daemon.

Brian - do you have the time to work on it?

> There would be issues of "should it be started automatically" and if so,
> should it die automatically, but users (like me) who know what it does would

Print a message that the user should either ask the sysadm to install
the daemon or to put it into his ~/.profile. - ah yes: we need an
option (or better an environment var) to tell GnupG the name of the
sockets.

> Except for the lack of the special ioctls (to measure or change entropy
> count), would such a device be at all discernible from the real kernel-based
> /dev/random?

No and given the fact that the kernel based /dev/random is only used
to seed the GnuPG RNG there is should be not much difference.

Werner

Re: 0.9.1 [ In reply to ]

roessler at guug

Jan 12, 1999, 5:19 AM

Post #15 of 18 (832 views)

Permalink

On Tue, Jan 12, 1999 at 08:46:14AM +0100, Werner Koch wrote:

>> slow random polling function was busily executing over and over
>> again (without finding too much randomness), and the program never
>> had enough. After some 10000 lines of debugging output, I stopped
>> it (and manually added things like "xwd -root" to the slow poll
>> command table,

> xwd -root yields more than one meg of data but I have some doubts that
> there is much random in it.

Other things I've seen to get randomness include:

- Hashing the system log files.
- Hashing the output of "ls -lu" [that's atime] for a couple of
often-used system direcotries, like /bin, /usr/bin, /lib,
/usr/lib, /etc, and the like.
- Hashing the contents of your mail folders
- Hashing the output of ps axwm
- Hashing the output of netstat

Note that most of this is from Markus Kuhn's one-time password
package. From otpw/conf.h:

------------------------------
/*
* List of shell commands that produce high entropy output.
* The output of all these commands will be hashed together with
* timing information to seed the random number generator
*/

#define ENTROPY_CMDS \
"head -c 20 /dev/random 2>&1", \
"ls -lu /etc/. /tmp/. / /usr/. /bin/. /usr/bin/.", \
"PATH=/usr/ucb:/bin:/usr/bin;ps lax", \
"last | head -50", \
"uptime;netstat -n;hostname;date;w", \
"cd $HOME; cat .pgp/randseed.bin .ssh/random_seed .otpw 2>&1", \
"PATH=/usr/bin/X11/;xwd -root -silent 2>&1||xwd -root 2>&1"

/*
* Environment variable settings for the entropy generating
* shell commands
*/

#define ENTROPY_ENV \
"PATH=/bin:/usr/bin:/sbin:/usr/sbin:/etc:/usr/etc:/usr/ucb"
------------------------------

tlr
--
Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/
2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1
> Hi! I'm Signature Virus 99! Copy me into your signature and join the fun!

Re: 0.9.1 [ In reply to ]

Bodo_Moeller at public

Jan 12, 1999, 9:46 PM

Post #16 of 18 (830 views)

Permalink

Werner Koch <wk@isil.d.shuttle.de>:

> xwd -root yields more than one meg of data but I have some doubts that
> there is much random in it.

It depends, obviously. There's plenty of space on the screen to
display random stuff (a 80*25 xterm window with .5 bits of entropy per
character is enough for our purposes, and thus other software can
easily be used to gather randomness) -- of course you cannot expect
good output if you simply start up X and do "xwd -root" for your
default screen.

>> In the long run, probably there should be some provisions for random
>> seeding in the option/configuration file parser [...]

> Or tell Sun to implement Tytso's /dev/random which has a BSD style
> license. I'd prefer such a sulution.

Surely that would be better, but we have to expect /dev/random-less
machines to stick around for quite some time. The existence of
/dev/random is nothing software should rely on; there are many OSs,
and not everyone will be willing (or able) to switch to newer versions
or other OSs to have /dev/random.

Bodo M"oller
<bmoeller@acm.org>

Re: 0.9.1 [ In reply to ]

wk at isil

Jan 13, 1999, 2:44 AM

Post #17 of 18 (832 views)

Permalink

Thomas Roessler <roessler@guug.de> writes:

> Other things I've seen to get randomness include:
>
> - Hashing the system log files.
> - Hashing the output of "ls -lu" [that's atime] for a couple of
> often-used system direcotries, like /bin, /usr/bin, /lib,
> /usr/lib, /etc, and the like.
> - Hashing the contents of your mail folders
> - Hashing the output of ps axwm
> - Hashing the output of netstat

But hashing is not what we need for the GnuPG RNG as this is done
internally in the random number generator. A simple form of
compression is good enough before putting it as entropy into the
gnupg RNG. Even adding non random data to the internal RNG does
not do any harm.

I suggest to read the paper about Practically Strong Random Number;
I found out that it is still available at Peter Gutmann's homepage:

http://www.cs.auckland.ac.nz/~pgut001

Werner

Re: 0.9.1 [ In reply to ]

warner at lothar

Jan 15, 1999, 12:54 AM

Post #18 of 18 (837 views)

Permalink

wk@isil.d.shuttle.de (Werner Koch) writes:

> Brian Warner <warner@lothar.com> writes:
>
> > If we turned the rndunix code into a persistent daemon, with a pair of
> > unix sockets to correspond to /dev/random and /dev/urandom, couldn't that
> > drop into
>
> That's the way we do it. It also has the advantage that we don't have
> to care about GPL/cryptlib license conflicts. I'd suggest not to call
> it /tmp/[u]random but /tmp/[u]entropy and use a message format to
> pass information about the entroy quality along with the bytes of
> entropy.
>
> What's need is a buffer as the entropy pool. The /dev/random code
> together with the current rndunix.c is a goof starting point for such
> a daemon.
>
> Brian - do you have the time to work on it?

I'll see what I can do. I was thinking about it a bit further.. you'd need
named pipes instead of sockets (since you can't open() a socket), and since
the daemon would have no way of knowing how much data had been read, you can't
keep track of entropy as accurately as the kernel device can (hmm, maybe with
userfs...:). So you basically have to fill the fifo until you cannot write any
more, then refill if necessary, losing some fixed amount (8k?) of bytes per
reading process.

If I did it in perl, would that seriously impair anybody's ability to use it?

If the interface is as simple as 'dd if=/tmp/uentropy of=bits', read as much
as you want, would that be enough? Or is there a good reason for a control
port of some kind (to query entropy state and do the ioctl-ish things that
/dev/random can do), or to allow writes that might add to the entropy pool?

> Print a message that the user should either ask the sysadm to install
> the daemon or to put it into his ~/.profile. - ah yes: we need an
> option (or better an environment var) to tell GnupG the name of the
> sockets.

If it is a system-wide thing, I would put it in /tmp or even (perhaps a little
pretentious here) /dev. If a user starts it for themselves we could just throw
it in ~/.gnupg/[u]entropy.

> > Except for the lack of the special ioctls (to measure or change entropy
> > count), would such a device be at all discernible from the real
> > kernel-based /dev/random?
>
> No and given the fact that the kernel based /dev/random is only used
> to seed the GnuPG RNG there is should be not much difference.

About how much entropy is used? I have a little perl/gtk bar-graph widget to
show me how much entropy is available in my /dev/random pool (the default
maximum is 4096 bits), and when generating keys it all gets used up
(encrypting messages is maybe 1000 bits? Hard to be sure). Given that the
userspace random device will invariably spill some entropy, we should have it
use a larger pool.

Do you think there is a use for the /dev/random -equivalent for which reads
block when there isn't enough entropy available? Or just the /dev/urandom
version which depletes the entropy count but doesn't stop when it gets to
zero?

Off to figure out named fifos...

-Brian