Mailing List Archive: 0.4.1 released

0.4.1 released

Oct 7, 1998, 6:18 AM

Post #1 of 6 (894 views)

Hi,

I have released gnupg 0.4.1, it is available at

ftp://ftp.guug.de/pub/gcrypt/gnupg-0.4.1.tar.gz

diff file: ftp://ftp.guug.de/pub/gcrypt/diffs/gnupg-0.4.1.diff.gz
a new Windoze binary is also availabe in the binary directory.

See

http://www.d.shuttle.de/isil/gnup/mirros.html

for a list of mirror sites.

What's new:

* A secondary key is used when the primary key is specified but cannot
be used for the operation (if it is a sign-only key).

* GNUPG can now handle concatenated armored messages: There is still a
bug if different kinds of messages are mixed.

* Iterated+Salted passphrases now work. If want to be sure that PGP5
is able to handle them you may want to use the options
"--s2k-mode 3 --s2k-cipher-algo cast5 --s2k-digest-algo sha1"
when changing a passphrase.

* doc/OpenPGP talks about OpenPGP compliance, doc/HACKING gives
a few hints about the internal structure.

* Checked gnupg against the August 1998 draft (07) and I believe
it is in compliance with this document (except for one point).

* Fixed some bugs in the import merging code and rewrote some
code for the trustdb.

Please report bugs to g10@net.lut.ac.uk

I hope to setup a anon CVS next week.

Werner

Re: 0.4.1 released [ In reply to ]

Oct 7, 1998, 11:35 AM

Post #2 of 6 (884 views)

make[1]: Entering directory `/home/jamsrc/gnupg-0.4.1/mpi'
cd .. && automake --gnu --include-deps mpi/Makefile
cd .. \
&& CONFIG_FILES=mpi/Makefile CONFIG_HEADERS= /bin/sh ./config.status
creating mpi/Makefile
linking ./mpi/i386/mpih-add1.S to mpi/mpih-add1.S
linking ./mpi/i386/mpih-mul1.S to mpi/mpih-mul1.S
linking ./mpi/i386/mpih-mul2.S to mpi/mpih-mul2.S
linking ./mpi/i386/mpih-mul3.S to mpi/mpih-mul3.S
linking ./mpi/i386/mpih-lshift.S to mpi/mpih-lshift.S
linking ./mpi/i386/mpih-rshift.S to mpi/mpih-rshift.S
linking ./mpi/i386/mpih-sub1.S to mpi/mpih-sub1.S
make[1]: Leaving directory `/home/jamsrc/gnupg-0.4.1/mpi'
make[1]: Entering directory `/home/jamsrc/gnupg-0.4.1/mpi'
make[1]: *** No rule to make target `libmpi.a.c', needed by `libmpi.a.o'. Stop.
make[1]: Leaving directory `/home/jamsrc/gnupg-0.4.1/mpi'
make: *** [all-recursive] Error 1
[jam@athene gnupg-0.4.1]$

-----

Hmm... what's needed?

jam

Re: 0.4.1 released [ In reply to ]

warner at lothar

Oct 7, 1998, 3:05 PM

Post #3 of 6 (879 views)

gnupg-0.4.1:

linux-powerpc: all tests pass

solaris-sparc:
./configure --with-included-gettext: compiles fine
still have missing __muldi3 when loading tiger module
(I was wrong before. u64=u32*u32 isn't enough. To get muldi3 the kludge
needs more: a u64=u32*u64 multiply worked for me. Sorry.)
after patching md_stop_debug() to have the right kind of multiply:
two tests fail. genkey seems to time out early (not sure why, the 'expect'
code called for a timeout of 600, but it seemed to give up after maybe 10
seconds).

encryptp.test fails with:

(../g10/gpg --homedir . --yes) failed
gpg: note: secret key 2E5FA4F4 is NOT protected.
gpg: note: cipher algorithm 4 not found in preferences
gpg: [don't know]: invalid packet (ctb=67)
FAIL: encryptp.test

I hope to investigate these more later.

thanks,
-Brian
warner@lothar.com

Re: 0.4.1 released [ In reply to ]

lynch at cognitivearts

Oct 7, 1998, 3:39 PM

Post #4 of 6 (881 views)

For the 0.4.1 binary from the web-site:

gpg --homedir /f/data/cpp/gpg --gen-key

just prints the banner and exits with no other message.

Trying to compile for myself on Cygwin32 beta 19 on top of Windoze NT:

configure goes okay. :-)

A) I have to add "#define __MINGW32__ 1" to congif.h by hand, since it's
not set by whatever compiler comes bundled with Cygwin (gnu gcc, I
believe).

B) Take out "#define HAVE_TCGETATTR" so I can type in a password without
locking up the whole machine.

Then, it pukes on compiling tdbio.c:

76: #if __MINGW32__
77: if( mkdir( fname ) )
78: #else

claiming that mkdir has two arguments, which, in Windoze, it don't...

I'm so confused...

-- "TANSTAAFL" Rich lynch@cognitivearts.com webmaster@ and www. all of:
R&B/jazz/blues/rock - jademaze.com music industry org - chatmusic.com
acoustic/funk/world-beat - astrakelly.com sculptures - olivierledoux.com
my own company - l-i-e.com uncommon ground - uncommonground.com

Re: 0.4.1 released [ In reply to ]

warner at lothar

Oct 7, 1998, 4:03 PM

Post #5 of 6 (878 views)

> gnupg-0.4.1:
>
> solaris-sparc:
> two tests fail. genkey seems to time out early (not sure why, the 'expect'
> code called for a timeout of 600, but it seemed to give up after maybe 10
> seconds).
>
> encryptp.test fails with:
>
> (../g10/gpg --homedir . --yes) failed
> gpg: note: secret key 2E5FA4F4 is NOT protected.
> gpg: note: cipher algorithm 4 not found in preferences
> gpg: [don't know]: invalid packet (ctb=67)
> FAIL: encryptp.test
>
>
> I hope to investigate these more later.

Both failures are a direct result of the rand-dummy warnings (since Solaris
has no /dev/random). encryptp.test fails because the log_info() message "gpg:
warning: using insecure random number generator" gets merged in stdout with
the output crypttext, which then shows up as bogus input crypttext to the
decrypt side of the pipe. genkey1024.test seems to fail because the warning
message is emitted during prime generation (in the middle of the ...+++...
sequence) and terminates the 'expect' clause early. If I #ifdef out the
warning messages, all tests pass. So the only solaris patch necessary is the
different __muldi3 kludge. (although a real RNG would be nice too).

thanks,
-Brian
warner@lothar.com

Re: 0.4.1 released [ In reply to ]

Oct 8, 1998, 2:11 AM

Post #6 of 6 (878 views)

Brian Warner <warner@lothar.com> writes:

> Both failures are a direct result of the rand-dummy warnings (since Solaris
> has no /dev/random). encryptp.test fails because the log_info() message "gpg:
> warning: using insecure random number generator" gets merged in stdout with

Merged with stdout? Ahhh, yes, due to the run-gpg script.
I'll put this message into the run-gpg patterns.

> decrypt side of the pipe. genkey1024.test seems to fail because the warning
> message is emitted during prime generation (in the middle of the ...+++...
> sequence) and terminates the 'expect' clause early. If I #ifdef out the
> warning messages, all tests pass. So the only solaris patch necessary is the
> different __muldi3 kludge. (although a real RNG would be nice too).

I think it is okay, that this test fails: there is no RNG ;-)

Werner