From win@huh.org  Wed May  1 00:25:01 2002
From: win@huh.org (Winona Brown)
Date: Tue Apr 30 23:25:01 2002
Subject: AIX bug malloc(0)
Message-ID: <20020430212626.GA1048@arghh.huh.org>

make with aix5.1 compiler vac5 (xlc) was failing in checks until I added 
   if (n == 0)
       n = 1;
before calling malloc.

The technical reference for AIX 5L 5.1 says:

If the malloc or valloc subroutine is called with a size of 0, the subroutine
returns a null pointer

The better way to fix this would probably be to allow a NULL being returned
if malloc(0) was called.  

gnupg-1.0.7/util/memory.c

Winona



From redbird@rbisland.cx  Wed May  1 08:38:01 2002
From: redbird@rbisland.cx (Gordon Worley)
Date: Wed May  1 07:38:01 2002
Subject: gnupg 107 compilation on solaris 8
In-Reply-To: <200204301744.KAA00577@fionn.es.net>
Message-ID: <CB457866-5CC5-11D6-BDCA-000A27B4DEFC@rbisland.cx>

On Tuesday, April 30, 2002, at 01:44  PM, Michael Helm wrote:

>> ./configure --enable-static-rnd=unix
>
> Had exactly the same effect -- option apparently doesn't work

Trying throwing --disable-dynload into the mix.

--
Gordon Worley                     `When I use a word,' Humpty Dumpty
http://www.rbisland.cx/            said, `it means just what I choose
redbird@rbisland.cx                it to mean--neither more nor less.'
PGP:  0xBBD3B003                                  --Lewis Carroll



From BigBootyHoe69699@aol.com  Wed May  1 11:02:01 2002
From: BigBootyHoe69699@aol.com (BigBootyHoe69699@aol.com)
Date: Wed May  1 10:02:01 2002
Subject: Free Trail!! NO FEES!
Message-ID: <200204302358.DAA09114@cobi.coqui.net>

Mail from  (BigBootyHoe69699@aol.com) 
     on Wednesday, May 1, 2002 at 03:58:50
---------------------------------------------------------------------------

:: RIGHT NOW!  FREE Membership Available!  Don't know how long this offer will last, get it while you still can! We have BEAUTIFUL girls and they are just one click away from showing you the BEST time of your life! <a href="http://rd.yahoo.com/dir/?http://members.lycos.co.uk/g00dstuff">Click here</a>

---------------------------------------------------------------------------
A Service of Coqui.Net             bug-octave-request@bevo.che.utexas.edu,bug-octave@bevo.che.utexas.edu,help-octave-request@bevo.che.utexas.edu,help-octave@bevo.che.utexas.edu,announce-request@gnupg.org,gnupg-users-request@gnupg.org,gnupg-users@gnupg.org,gnupg-devel-request@gnupg.org,gnupg-devel@gnupg.org,bug-bison-request@gnu.org,


From BigBootyHoe69699@aol.com  Wed May  1 11:11:02 2002
From: BigBootyHoe69699@aol.com (BigBootyHoe69699@aol.com)
Date: Wed May  1 10:11:02 2002
Subject: Free Trail!! NO FEES!
Message-ID: <200205010008.EAA09698@cobi.coqui.net>

Mail from  (BigBootyHoe69699@aol.com) 
     on Wednesday, May 1, 2002 at 04:08:08
---------------------------------------------------------------------------

:: RIGHT NOW!  FREE Membership Available!  Don't know how long this offer will last, get it while you still can! We have BEAUTIFUL girls and they are just one click away from showing you the BEST time of your life! <a href="http://rd.yahoo.com/dir/?http://members.lycos.co.uk/g00dstuff">Click here</a>

---------------------------------------------------------------------------
A Service of Coqui.Net             bug-octave-request@bevo.che.utexas.edu,bug-octave@bevo.che.utexas.edu,help-octave-request@bevo.che.utexas.edu,help-octave@bevo.che.utexas.edu,announce-request@gnupg.org,gnupg-users-request@gnupg.org,gnupg-users@gnupg.org,gnupg-devel-request@gnupg.org,gnupg-devel@gnupg.org,bug-bison-request@gnu.org,


From hideki@allcity.net  Thu May  2 03:26:02 2002
From: hideki@allcity.net (Hideki Saito)
Date: Thu May  2 02:26:02 2002
Subject: 15MB files on photo
Message-ID: <200205020026.g420Qli28732@server-1.visp.net>

I found some problem with photo capability of 1.0.7 on Win32 
compilation.

If you try to display graphics, it is actually a bogus JPG file.

I have tried with the option i_view32 %i as a photo-viewer argument, 
and it returns "unknown header" error.

Then I tried i_view32 %I to see what actual "TEMP.JPG" is like, and it 
turns out be a 12MB - 15MB garbage file.

Is there any workaround to this?

-- 
Hideki Saito mailto:hideki@allcity.net


From dshaw@jabberwocky.com  Thu May  2 03:50:02 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Thu May  2 02:50:02 2002
Subject: 15MB files on photo
In-Reply-To: <200205020026.g420Qli28732@server-1.visp.net>
References: <200205020026.g420Qli28732@server-1.visp.net>
Message-ID: <20020502005106.GA25856@akamai.com>

On Wed, May 01, 2002 at 05:27:42PM -0700, Hideki Saito wrote:
> I found some problem with photo capability of 1.0.7 on Win32 
> compilation.
> 
> If you try to display graphics, it is actually a bogus JPG file.
> 
> I have tried with the option i_view32 %i as a photo-viewer argument, 
> and it returns "unknown header" error.
> 
> Then I tried i_view32 %I to see what actual "TEMP.JPG" is like, and it 
> turns out be a 12MB - 15MB garbage file.

Hmm.  Are you using a Mingw32 or Cygwin build?

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From hideki@allcity.net  Thu May  2 05:04:02 2002
From: hideki@allcity.net (Hideki Saito)
Date: Thu May  2 04:04:02 2002
Subject: 15MB files on photo
In-Reply-To: <20020502005106.GA25856@akamai.com>
References: <200205020026.g420Qli28732@server-1.visp.net>
 <20020502005106.GA25856@akamai.com>
Message-ID: <200205020205.g4225Fi03599@server-1.visp.net>

Mingw32 build it is...

>On Wed, May 01, 2002 at 05:27:42PM -0700, Hideki Saito wrote:
>> I found some problem with photo capability of 1.0.7 on Win32 
>> compilation.
>> 
>> If you try to display graphics, it is actually a bogus JPG file.
>> 
>> I have tried with the option i_view32 %i as a photo-viewer argument, 
>> and it returns "unknown header" error.
>> 
>> Then I tried i_view32 %I to see what actual "TEMP.JPG" is like, and it 
>> turns out be a 12MB - 15MB garbage file.
>
>Hmm.  Are you using a Mingw32 or Cygwin build?
>
>David
>
>-- 
>   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
>+---------------------------------------------------------------------------+
>   "There are two major products that come out of Berkeley: LSD and UNIX.
>      We don't believe this to be a coincidence." - Jeremy S. Anderson
>
>_______________________________________________
>Gnupg-devel mailing list
>Gnupg-devel@gnupg.org
>http://lists.gnupg.org/mailman/listinfo/gnupg-devel

-- 
Hideki Saito mailto:hideki@allcity.net


From mwy-gpg41@the-youngs.org  Thu May  2 06:43:01 2002
From: mwy-gpg41@the-youngs.org (Michael Young)
Date: Thu May  2 05:43:01 2002
Subject: feature request: always-trust [<keyring>]
References: <E172PDG-0002qc-00@trithemius.gnupg.org>
Message-ID: <003d01c1f18b$83100d60$c23fa8c0@transarc.ibm.com>

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

Jeff Breidenbach <jab@debian.org> asked for:
> What: ability to specify that everything in a specific
>       keyring will trusted by default.

This sounds like a reasonable request to me.  As you note, there
is already an "--always-trust" switch -- it's just global.
But I'm not one of the people you need to convince.

> Why:  In Debian, I can have a list of hundreds of developer=20
>       keys stored  in locally in /usr/share/keyrings/debian-keyring.gpg.
>       This file is trusted by me, dynamic, and is maintained by the
>       Debian Project. So I use the file as one of my keyrings.

I know you didn't ask for workarounds, but in case your request
isn't filled in a timely manner...

Could you convince whoever is maintaining the keyring to sign the keys
using some well-known "Debian Project" key?  Then, you could use the
existing trust mechanisms (up to and including the "--trusted-key"
switch).  This would also let you (or others) pick up keys from
keyservers, rather than rely purely on secure delivery of the shared
keyring file.

Failing that, you could automatically generate (local) signatures for
everything on the trusted keyring.  I would use a local key specific
to this purpose.  This requires some trickery: the "--batch" switch
disallows signing; the "--yes" switch has no effect.  It seems that
you need to use the "--command-fd" gadgetry (and in theory use the
"--status-fd" switch to know what to feed it), as in (using csh syntax):

    foreach x (`gpg --with-colons --list-keys | awk -F: '/^pub/{print $5}'`)
 echo YES | \
 gpg -u your_project_key --command-fd 0 --lsign-key $x
    end


While we're asking for features, I'll repeat my plea for one that
would help out on this workaround.  I'd sorely like to be able to use
the "--edit-key" commands (of which "--lsign" is a special case)
without having to deal with all of the questions.  It would be fine to
reuse an existing switch (like "--batch" or "--expert") or grow a new
one ("--just-do-it" or "--really-yes") to carry this meaning.
The same principle could be applied to disable the questions
about key size :-).

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQA/AwUBPNC1xFMkvpTT8vCGEQLqGQCgqMt4mcmi0OZOv543gBEwuY7H/8sAoOBV
0ESwD3C1sgvl99gAShvD9O3m
=tZW3
-----END PGP SIGNATURE-----




From wk@gnupg.org  Thu May  2 09:59:02 2002
From: wk@gnupg.org (Werner Koch)
Date: Thu May  2 08:59:02 2002
Subject: AIX bug malloc(0)
In-Reply-To: <20020430212626.GA1048@arghh.huh.org> (Winona Brown's message
 of "Tue, 30 Apr 2002 16:26:26 -0500")
References: <20020430212626.GA1048@arghh.huh.org>
Message-ID: <87znzjkpa0.fsf@alberti.gnupg.de>

On Tue, 30 Apr 2002 16:26:26 -0500, Winona Brown said:

> The better way to fix this would probably be to allow a NULL being returned
> if malloc(0) was called.  

Well yes, this would be better for debugging.  For now I took the easy
path out.

Thanks,

  Werner



From dbely@mail.ru  Thu May  2 19:04:02 2002
From: dbely@mail.ru (Dmitry Bely)
Date: Thu May  2 18:04:02 2002
Subject: 1.0.7 under Win32
Message-ID: <r8kufslp.fsf@mail.ru>

I have found some minor problems in GnuPG 1.0.7 that prevent it from
compiling out of the box. I have also fixed the bug in write_server() that
existed from the very beginning (Win32 API function WriteFile() doesn't
work with TCP/IP sockets). Due to that all HTTP-related stuff
("--recv-keys" option etc.) was broken under Win32. Are you interested in
the patch?

Hope to hear from you soon,
Dmitry




From tracy_d@xypro.com  Thu May  2 21:22:02 2002
From: tracy_d@xypro.com (Tracy Ding)
Date: Thu May  2 20:22:02 2002
Subject: A question?
Message-ID: <32E0F1DAB878D511826D00A0CCD7949203EE55@xypro.com>

Hello,
Currently I am working on Gnupg 1.0.6 stuff. 
I installed Gnupg 1.0.6 in my pc.
The command "gpg --print-md SHA1 Keypc"
  the putput is "Keypc: 69BB D5CF 491B C3BB F286  143A 4BC9 F8E8 7DCD"

But in OSS system ( I upload the source codes to Tandem OSS, compiled them )
I got different result.
"
 gpg --print-md SHA1 Keypc
gpg: Please note that you don't have secure memory on this system
gpg: WARNING: program may create a core file!
Keypc: 8653 FDF4 2F70 F2E2 E2D9  AFD4 CB7F 2531 9A85 E088
$ "                          

I tested it for MD5, the result is different too. 
I am totally lost, any help is appreciated.


Regards

Tracy Ding

                        


From wk@gnupg.org  Fri May  3 09:25:02 2002
From: wk@gnupg.org (Werner Koch)
Date: Fri May  3 08:25:02 2002
Subject: A question?
In-Reply-To: <32E0F1DAB878D511826D00A0CCD7949203EE55@xypro.com> (Tracy
 Ding's message of "Thu, 2 May 2002 11:22:16 -0700")
References: <32E0F1DAB878D511826D00A0CCD7949203EE55@xypro.com>
Message-ID: <87elgtiw4c.fsf@alberti.gnupg.de>

On Thu, 2 May 2002 11:22:16 -0700, Tracy Ding said:

> But in OSS system ( I upload the source codes to Tandem OSS, compiled them )
> I got different result.

Did you got any compiler diagnostics when building it?

Am I right that most checks fail if you do a "make check"?



From dshaw@jabberwocky.com  Fri May  3 17:40:02 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Fri May  3 16:40:02 2002
Subject: 15MB files on photo
In-Reply-To: <200205020205.g4225Fi03599@server-1.visp.net>
References: <200205020026.g420Qli28732@server-1.visp.net> <20020502005106.GA25856@akamai.com> <200205020205.g4225Fi03599@server-1.visp.net>
Message-ID: <20020503144106.GD6647@akamai.com>

> >On Wed, May 01, 2002 at 05:27:42PM -0700, Hideki Saito wrote:
> >> I found some problem with photo capability of 1.0.7 on Win32 
> >> compilation.
> >> 
> >> If you try to display graphics, it is actually a bogus JPG file.
> >> 
> >> I have tried with the option i_view32 %i as a photo-viewer argument, 
> >> and it returns "unknown header" error.
> >> 
> >> Then I tried i_view32 %I to see what actual "TEMP.JPG" is like, and it 
> >> turns out be a 12MB - 15MB garbage file.
> >
> >Hmm.  Are you using a Mingw32 or Cygwin build?

On Wed, May 01, 2002 at 07:06:11PM -0700, Hideki Saito wrote:
> Mingw32 build it is...

The problem is forward slashes in the photo path.  Before you compile,
you need to change g10defs.h:

Change these:
#define DIRSEP_C '/'
#define DIRSEP_S "/"

To these:
#define DIRSEP_C '\\'
#define DIRSEP_S "\\"

The Win32 internals do allow either / or \, but the photo viewer uses
system(), and that calls command, and command does not allow forward
slashes.

As for the large garbage file in i_view32, I was able to duplicate the
problem here so I see it as well, but I don't know where the garbage
came from.  I suspect that i_view32 gets upset if it gets forward
slashes in a pathname.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From tracy_d@xypro.com  Sat May  4 00:26:01 2002
From: tracy_d@xypro.com (Tracy Ding)
Date: Fri May  3 23:26:01 2002
Subject: Help ...
Message-ID: <32E0F1DAB878D511826D00A0CCD7949203EE5D@xypro.com>

Hello,

I installed gnupg-1.0.7 into a linux machine. 
It is i486 machine. 
I got a probelm when generating a key pair.

"
Not enough random bytes available.  Please do some other work to give
the OS a chance to collect more entropy! (Need 300 more bytes)     
"
The program stuck there waiting for more bytes.
Any help is appreciated.


Thanks

Tracy Ding


From ajs@ajs.com  Sat May  4 00:56:01 2002
From: ajs@ajs.com (Aaron Sherman)
Date: Fri May  3 23:56:01 2002
Subject: Help ...
In-Reply-To: <32E0F1DAB878D511826D00A0CCD7949203EE5D@xypro.com>
References: <32E0F1DAB878D511826D00A0CCD7949203EE5D@xypro.com>
Message-ID: <1020463004.22284.38.camel@pps>

On Fri, 2002-05-03 at 17:26, Tracy Ding wrote:

> I installed gnupg-1.0.7 into a linux machine. 
> It is i486 machine. 
> I got a probelm when generating a key pair.
> 
> "
> Not enough random bytes available.  Please do some other work to give
> the OS a chance to collect more entropy! (Need 300 more bytes)     
> "
> The program stuck there waiting for more bytes.
> Any help is appreciated.

As the message suggests, you should do more work and let the OS collect
more random bytes. Go! Do work! ;-)




From mutz@kde.org  Sat May  4 01:07:02 2002
From: mutz@kde.org (Marc Mutz)
Date: Sat May  4 00:07:02 2002
Subject: Help ...
In-Reply-To: <32E0F1DAB878D511826D00A0CCD7949203EE5D@xypro.com>
References: <32E0F1DAB878D511826D00A0CCD7949203EE5D@xypro.com>
Message-ID: <200205040007.16685@sendmail.mutz.com>

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

[ reordering lines of original post ]

On Friday 03 May 2002 23:26, Tracy Ding wrote:
<snip>
> The program stuck there waiting for more bytes: <snip>
> Not enough random bytes available.  Please do some other work to give
> the OS a chance to collect more entropy! (Need 300 more bytes)
<snip>

Sorry, you _can_ read, can you? :-(
You can: start bonnie in the background, hit the keyboard monkey-style, move 
the mouse wildly (maybe dragging a window around), or all at once... :-o

Marc

- -- 
Marc Mutz <mutz@kde.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE80woT3oWD+L2/6DgRAgu4AKCCKdzJ2nXvolRZm98mjNNwek1VjACff0Uy
pNJ03crlAlHhb412P6omRw4=
=axlJ
-----END PGP SIGNATURE-----



From dmitri@users.sourceforge.net  Sat May  4 01:29:02 2002
From: dmitri@users.sourceforge.net (Dmitri)
Date: Sat May  4 00:29:02 2002
Subject: Help ...
In-Reply-To: <200205040007.16685@sendmail.mutz.com>
References: <32E0F1DAB878D511826D00A0CCD7949203EE5D@xypro.com>
 <200205040007.16685@sendmail.mutz.com>
Message-ID: <1020464977.1668.228.camel@usb.networkfab.com>

--=-rwHiFvOaMeYb2BeHJUTK
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Fri, 2002-05-03 at 15:07, Marc Mutz wrote:

> On Friday 03 May 2002 23:26, Tracy Ding wrote:
> <snip>
> > The program stuck there waiting for more bytes: <snip>
> > Not enough random bytes available.  Please do some other work to give
> > the OS a chance to collect more entropy! (Need 300 more bytes)
> <snip>
>=20
> Sorry, you _can_ read, can you? :-(
> You can: start bonnie in the background, hit the keyboard monkey-style, m=
ove=20
> the mouse wildly (maybe dragging a window around), or all at once... :-o

I believe, the original cry for help was not unfounded. Here is why.

First of all, the message "Not enough random bytes available" may be
perceived by novices as an ERROR. It is phrased this way. Failed. No
luck. Come back in next millennium. Or something like that.

Secondly, the advice "Please do some other work" can be understood as
"give the computer more time, and meanwhile do something different, like
walking the dog..." If the user does that, the dog gets the entropy -
not the computer ;-)

Apparently, in this very case the user left the computer alone for some
time, and then complained that the program does not go anywhere.

This is because only computer geeks would equal "some other work" to
"some other work with this computer". Normal people have other "work" to
do. Naturally, if the computer is just left there then no new entropy
comes in, and nothing ever happens (until updatedb runs at night,
probably).

So messages may need to be softened up to be understood by all the
normal people ;-)

Dmitri


--=-rwHiFvOaMeYb2BeHJUTK
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA80w9RXksyLpO6T4IRAsPsAKCaVlUel2/AiKiLcqjzRgX8iLVSxQCgkZXw
oc6f+yGziDnxLzIz3u0+Ewc=
=kmrA
-----END PGP SIGNATURE-----

--=-rwHiFvOaMeYb2BeHJUTK--



From wk@gnupg.org  Sat May  4 16:31:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Sat May  4 15:31:01 2002
Subject: Help ...
In-Reply-To: <1020464977.1668.228.camel@usb.networkfab.com> (Dmitri's
 message of "03 May 2002 15:29:37 -0700")
References: <32E0F1DAB878D511826D00A0CCD7949203EE5D@xypro.com>
 <200205040007.16685@sendmail.mutz.com>
 <1020464977.1668.228.camel@usb.networkfab.com>
Message-ID: <87n0vgdomh.fsf@alberti.gnupg.de>

On 03 May 2002 15:29:37 -0700, Dmitri  said:

> So messages may need to be softened up to be understood by all the
> normal people ;-)

I agree.  I will reword the messages.

 Werner



From jas@extundo.com  Sat May  4 18:21:02 2002
From: jas@extundo.com (Simon Josefsson)
Date: Sat May  4 17:21:02 2002
Subject: update to gettext 0.11.2?
Message-ID: <iluu1pohr9p.fsf@extundo.com>

What about updating to gettext 0.11.2?  I had difficulties getting the
current gettext in gnupg to work.

I put a patch to do this up at http://josefsson.org/gnupg-gettext.diff
(due to size, ~230KB), altough it seems to remove some comments in
po/*.po so maybe not all of it should be applied.



From wk@gnupg.org  Sat May  4 19:57:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Sat May  4 18:57:01 2002
Subject: update to gettext 0.11.2?
In-Reply-To: <iluu1pohr9p.fsf@extundo.com> (Simon Josefsson's message of
 "Sat, 04 May 2002 17:22:26 +0200")
References: <iluu1pohr9p.fsf@extundo.com>
Message-ID: <871ycrdf4e.fsf@alberti.gnupg.de>

On Sat, 04 May 2002 17:22:26 +0200, Simon Josefsson said:

> What about updating to gettext 0.11.2?  I had difficulties getting the
> current gettext in gnupg to work.

As soon as it appears in Woody.

  Werner



From jgre@tzi.de  Mon May  6 12:12:02 2002
From: jgre@tzi.de (Janico Greifenberg)
Date: Mon May  6 11:12:02 2002
Subject: Importing and using keys with GPGME
Message-ID: <20020506062658.GA478@tzi.de>

Hello,
when I import a public key with gpgme_op_import() the key appears in my keyring
but when I want to use it for encryption (with gpgme_op_encrypt_sign()) I get
a GPGME_No_Data Error. When I use this key with gpg in the command line, I need
to confirm that I want to use this untrusted key. Is to possible to do
something like that with gpgme (I mean overriding the error) or do I have to
sign the key and how can I do this with gpgme?

Thanks in advance
       Janico
-- 
Warning! Taking anyone (especially yourself) too serious will be harmful


From hideki@allcity.net  Mon May  6 14:17:02 2002
From: hideki@allcity.net (Hideki Saito)
Date: Mon May  6 13:17:02 2002
Subject: 15MB files on photo
In-Reply-To: <20020503144106.GD6647@akamai.com>
References: <200205020026.g420Qli28732@server-1.visp.net>
 <20020502005106.GA25856@akamai.com>
 <200205020205.g4225Fi03599@server-1.visp.net>
 <20020503144106.GD6647@akamai.com>
Message-ID: <200205061118.g46BIYg20489@sasami.anime.net>

Yes, this worked.
Thanks.

Here are files, in case anyones are interested.
http://hp.vector.co.jp/authors/VA019487/gnupg-w32-1.0.7-hs.zip
http://hp.vector.co.jp/authors/VA019487/hs-gnupg-w32-1.0.7-hs.zip.sig


>
>On Wed, May 01, 2002 at 07:06:11PM -0700, Hideki Saito wrote:
>> Mingw32 build it is...
>
>The problem is forward slashes in the photo path.  Before you compile,
>you need to change g10defs.h:
>
>Change these:
>#define DIRSEP_C '/'
>#define DIRSEP_S "/"
>
>To these:
>#define DIRSEP_C '\\'
>#define DIRSEP_S "\\"
>
>The Win32 internals do allow either / or \, but the photo viewer uses
>system(), and that calls command, and command does not allow forward
>slashes.
>
>As for the large garbage file in i_view32, I was able to duplicate the
>problem here so I see it as well, but I don't know where the garbage
>came from.  I suspect that i_view32 gets upset if it gets forward
>slashes in a pathname.
>


-- 
Hideki Saito mailto:hideki@allcity.net


From wk@gnupg.org  Mon May  6 14:55:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Mon May  6 13:55:01 2002
Subject: Importing and using keys with GPGME
In-Reply-To: <20020506062658.GA478@tzi.de> (jgre@tzi.de's message of "Mon, 6
 May 2002 08:26:59 +0200")
References: <20020506062658.GA478@tzi.de>
Message-ID: <87lmax1oac.fsf@alberti.gnupg.de>

On Mon, 6 May 2002 08:26:59 +0200, Janico Greifenberg said:

> when I import a public key with gpgme_op_import() the key appears in my keyring
> but when I want to use it for encryption (with gpgme_op_encrypt_sign()) I get
> a GPGME_No_Data Error. When I use this key with gpg in the command line, I need

In general it does not make sense to encrypt something to someone whom
you don't trust.  So the best way is to locally sign the sign.

Using

  gpgme_recipients_add_name_with_validity (rset, name, GPGME_VALIDITY_FULL);

you should be able to overide it.




From Weimer@CERT.Uni-Stuttgart.DE  Tue May  7 10:43:02 2002
From: Weimer@CERT.Uni-Stuttgart.DE (Florian Weimer)
Date: Tue May  7 09:43:02 2002
Subject: Expiration and V3/V4 self signatures
Message-ID: <87helk8ksv.fsf@CERT.Uni-Stuttgart.DE>

* packet.h, parse-packet.c (parse_key), getkey.c (merge_keys_and_selfsig,
merge_selfsigs_main): a v3 key with a v4 self-sig must never let the v4
self-sig express a key expiration time that extends beyond the original v3
expiration time.

* keyedit.c (sign_uids): If --expert it set, allow re-signing a uid to
promote a v3 self-sig to a v4 one.  This essentially deletes the old v3
self-sig and replaces it with a v4 one.

Don't these two features conflict with each other?

-- 
Florian Weimer 	                  Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898


From wk@gnupg.org  Tue May  7 11:07:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Tue May  7 10:07:01 2002
Subject: Expiration and V3/V4 self signatures
In-Reply-To: <87helk8ksv.fsf@CERT.Uni-Stuttgart.DE> (Florian Weimer's
 message of "Tue, 07 May 2002 09:43:44 +0200")
References: <87helk8ksv.fsf@CERT.Uni-Stuttgart.DE>
Message-ID: <877kmgwfb8.fsf@alberti.gnupg.de>

On Tue, 07 May 2002 09:43:44 +0200, Florian Weimer said:

> * packet.h, parse-packet.c (parse_key), getkey.c (merge_keys_and_selfsig,
> merge_selfsigs_main): a v3 key with a v4 self-sig must never let the v4
> self-sig express a key expiration time that extends beyond the original v3
> expiration time.

> * keyedit.c (sign_uids): If --expert it set, allow re-signing a uid to
> promote a v3 self-sig to a v4 one.  This essentially deletes the old v3
> self-sig and replaces it with a v4 one.

> Don't these two features conflict with each other?

No.  Why should they?

As you know the expiration time in a v3 key is stored unchangeable
with the key whereas it is store in a self-signature with a v4 key.
The first change makes sure that the expiration time from a v4
signature on a v3 key can not be used to extend the expiration time
over the one set with the v3 key and the latter change simply promotes
a v3 self-signature to a v4 self-signature with an expiration time
(set to the one from the v3 key).

  Werner



From p_perego@modiano.com  Tue May  7 13:37:02 2002
From: p_perego@modiano.com (Paolo Perego)
Date: Tue May  7 12:37:02 2002
Subject: GPGME: verify signature question
Message-ID: <200205071237.54986.p_perego@modiano.com>

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

Hi ,guys. I'm not subscribed to thie ML so please cc me. I'm using gpg 1.=
07=20
and gpgme 0.3.6 on my suse linux box. I'm developing a tool that parse a=20
mailbox looking for mails and, if thie mails are signed, try to verify th=
e=20
signature ( not detached ). The messages are in rfc2015 form, so the cont=
ent =20
type is "multipart/signed" and the signed data is divided from the signat=
ure=20
by the boundary.

I wrote the code to verify the signature but I think I did not pass the r=
ight=20
body and signature content to gpgme_op_verify. Can you please gave me som=
e=20
links, examples ( not mail usent agent sources, please. ) about how verif=
y a=20
signed message vailidity.

Thanks a lot
Paolo
- --=20
$>cd /pub
$>more beer

(0>
//\  Perego Paolo <p_perego@modiano.com> - www.sikurezza.org/angel
V_/_ 'It's seems the hardest life I've never known'
I'm Linux drow 2.4.17-4GB - SuSE Linux 7.3 (i386) powered.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE8166Ae2SOXFIw7OcRAlFvAJ46Eu6wq4UrsiisYz7WE1xcGIAJYwCgmsWX
r2/3n7ue4jzOlCyISocqUQE=3D
=3DbzUP
-----END PGP SIGNATURE-----



From wk@gnupg.org  Tue May  7 14:13:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Tue May  7 13:13:01 2002
Subject: GPGME: verify signature question
In-Reply-To: <200205071237.54986.p_perego@modiano.com> (Paolo Perego's
 message of "Tue, 7 May 2002 12:37:45 +0200")
References: <200205071237.54986.p_perego@modiano.com>
Message-ID: <87k7qgus5c.fsf@alberti.gnupg.de>

On Tue, 7 May 2002 12:37:45 +0200, Paolo Perego said:

> signature ( not detached ). The messages are in rfc2015 form, so the content  
> type is "multipart/signed" and the signed data is divided from the signature 

BTW, rfc3156 is the successor or 2015, only minor changes but you
should use this as a reference,

> body and signature content to gpgme_op_verify. Can you please gave me some 
> links, examples ( not mail usent agent sources, please. ) about how verify a 

Be sure to include the header lines of the part and don't include the
CR/LF right before the terminating boundary.

What's wrong with looking at other sources?

  Werner



From p_perego@modiano.com  Tue May  7 15:18:02 2002
From: p_perego@modiano.com (Paolo Perego)
Date: Tue May  7 14:18:02 2002
Subject: GPGME: verify signature question
In-Reply-To: <87k7qgus5c.fsf@alberti.gnupg.de>
References: <200205071237.54986.p_perego@modiano.com> <87k7qgus5c.fsf@alberti.gnupg.de>
Message-ID: <200205071418.58964.p_perego@modiano.com>

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

Alle 13:14, marted=EC 7 maggio 2002, Werner Koch ha scritto:

> BTW, rfc3156 is the successor or 2015, only minor changes but you
> should use this as a reference,
Sure. I omissed that I downloaded also the new rfc. :)

> Be sure to include the header lines of the part and don't include the
> CR/LF right before the terminating boundary.
Is the signature calculated from the first "--boundary" or also the mail=20
header are hashed by gpg?

> What's wrong with looking at other sources?
Nothing at all.  I was checking out mutt and sylpheed-claws sources. But =
they=20
parse mime headers in various point of the code and I was not able to gue=
ss=20
what exactly they pass to gpgme_op_verify().

Thank again. I think this afternoon will be plenty of signature checking=20
attempts :)
Paolo
- --=20
$>cd /pub
$>more beer

(0>
//\  Perego Paolo <p_perego@modiano.com> - www.sikurezza.org/angel
V_/_ 'It's seems the hardest life I've never known'
I'm Linux drow 2.4.17-4GB - SuSE Linux 7.3 (i386) powered.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE818Yxe2SOXFIw7OcRAm2fAJ96qivoJ1SUH8JxGDjUkyguwvnK3wCgh96n
4ivWYObqgTQF7ikNsJTAAUs=3D
=3Ddhyt
-----END PGP SIGNATURE-----



From wk@gnupg.org  Tue May  7 15:37:02 2002
From: wk@gnupg.org (Werner Koch)
Date: Tue May  7 14:37:02 2002
Subject: GPGME: verify signature question
In-Reply-To: <200205071418.58964.p_perego@modiano.com> (Paolo Perego's
 message of "Tue, 7 May 2002 14:18:50 +0200")
References: <200205071237.54986.p_perego@modiano.com>
 <87k7qgus5c.fsf@alberti.gnupg.de>
 <200205071418.58964.p_perego@modiano.com>
Message-ID: <87g014uo6m.fsf@alberti.gnupg.de>

On Tue, 7 May 2002 14:18:50 +0200, Paolo Perego said:

> Is the signature calculated from the first "--boundary" or also the mail 
> header are hashed by gpg?

  Subject: a signed message
  
  -=-=-=
  Content-Type: whatever/foo

  This is the content which might be encoded in any way as
  specified by a encoding header.  For signature verification there 
  is nothing we have to care about.

  -=-=-=
  Content-Type: application/pgp-signature

What you hash is this string in C notation:

  "Content-Type: whatever/foo\r\n\r\nThis is the content which might"
  " be encoded in any way as\r\nspecified by a encoding header.  For"
  "  signature verification there\r\nis nothing we have to care about.\r\n"

And you might want to keep in mind that such a PGP/MIEM object may be
embedded in other MIME objects or the whatever/foo conetnt type might
be a multipart/mixed or whatever you can imagine.

gpg --debug 512

is of great help here because it creates files dbgmd*.<somecode> with
the actually hashed content.


  Werner



From p_perego@modiano.com  Tue May  7 15:42:01 2002
From: p_perego@modiano.com (Paolo Perego)
Date: Tue May  7 14:42:01 2002
Subject: GPGME: verify signature question
In-Reply-To: <87g014uo6m.fsf@alberti.gnupg.de>
References: <200205071237.54986.p_perego@modiano.com> <200205071418.58964.p_perego@modiano.com> <87g014uo6m.fsf@alberti.gnupg.de>
Message-ID: <200205071443.13524.p_perego@modiano.com>

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

Alle 14:39, marted=EC 7 maggio 2002, Werner Koch ha scritto:
[snip]

> What you hash is this string in C notation:
>
>   "Content-Type: whatever/foo\r\n\r\nThis is the content which might"
>   " be encoded in any way as\r\nspecified by a encoding header.  For"
>   "  signature verification there\r\nis nothing we have to care about.\=
r\n"
Perfect. At the same time I guess I must pass the string "-----BEGIN PGP=20
SIGNATURE-----.... -----END PGP SIGNATURE-----" as signature in=20
gpgme_op_verify(). Am I right am not I?

> And you might want to keep in mind that such a PGP/MIEM object may be
> embedded in other MIME objects or the whatever/foo conetnt type might
> be a multipart/mixed or whatever you can imagine.
Sure, but my application is really simple and it needs just to validate t=
he=20
sender identity! :)

Thanks for the help guys [ and excuse me for my poor english :P ]
Paolo
- --=20
$>cd /pub
$>more beer

(0>
//\  Perego Paolo <p_perego@modiano.com> - www.sikurezza.org/angel
V_/_ 'It's seems the hardest life I've never known'
I'm Linux drow 2.4.17-4GB - SuSE Linux 7.3 (i386) powered.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE818vge2SOXFIw7OcRAszgAJ9KpVTx0wzW/hFS8H3i//HQBzZJ3ACeImPY
VZM84JDhKchJecuG4yTz/eI=3D
=3DwMhM
-----END PGP SIGNATURE-----



From wk@gnupg.org  Tue May  7 15:57:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Tue May  7 14:57:01 2002
Subject: GPGME: verify signature question
In-Reply-To: <200205071443.13524.p_perego@modiano.com> (Paolo Perego's
 message of "Tue, 7 May 2002 14:43:07 +0200")
References: <200205071237.54986.p_perego@modiano.com>
 <200205071418.58964.p_perego@modiano.com>
 <87g014uo6m.fsf@alberti.gnupg.de>
 <200205071443.13524.p_perego@modiano.com>
Message-ID: <87u1pkt8oc.fsf@alberti.gnupg.de>

On Tue, 7 May 2002 14:43:07 +0200, Paolo Perego said:

> Perfect. At the same time I guess I must pass the string "-----BEGIN PGP 
> SIGNATURE-----.... -----END PGP SIGNATURE-----" as signature in 
> gpgme_op_verify(). Am I right am not I?

Yes.  

  Werner



From redbird@rbisland.cx  Tue May  7 18:58:02 2002
From: redbird@rbisland.cx (Gordon Worley)
Date: Tue May  7 17:58:02 2002
Subject: GnuPG 1.0.7 configure with dynload modules
Message-ID: <4B21FE3D-61D3-11D6-B33A-000A27B4DEFC@rbisland.cx>

Okay, I'm having a bit of trouble here and hopefully someone has some 
insights.

I'm trying to patch GnuPG 1.0.7 to run on Darwin (Mac OS X).  Everything 
is working except for one thing.  I have patched cipher/dynload.c to 
work as we did in 1.0.6 and it compiles fine and looks like it will 
work.  The problem comes when make tries to make the checks.  The 
problem is that tiger has not been compiled earlier.  Yet, when 
configure was run, it said that it would:

                 Configured for: Darwin (powerpc-apple-darwin5.4)
     Dynamically linked modules: rndunix rndegd tiger
      Statically linked modules: rndlinux sha1 rmd160 md5

So, anyone have any ideas on how to get tiger (and rndunix and rndegd; I 
checked and they haven't been compiled either) to compile short of doing 
it by hand?

Thanks.

--
Gordon Worley                     `When I use a word,' Humpty Dumpty
http://www.rbisland.cx/            said, `it means just what I choose
redbird@rbisland.cx                it to mean--neither more nor less.'
PGP:  0xBBD3B003                                  --Lewis Carroll



From bgallia@orion.it.luc.edu  Wed May  8 00:34:03 2002
From: bgallia@orion.it.luc.edu (B. Galliart)
Date: Tue May  7 23:34:03 2002
Subject: AIX malloc(0) is null
Message-ID: <Pine.A41.4.40.0205071551390.12276-100000@orion.it.luc.edu>

How many people believe in testing if their computer is out of memory by
requesting the allocation of *0* bytes?

So, what is wrong with the following picture:
  gpg: out of  memory while allocating 0 bytes

GNUPG v1.07 *REQUIRES* the use of m-guard on AIX to ensure that GPG never
attempts malloc(0) (m-gaurd always allocates at least 5 bytes).  There is
just something brain dead about requesting *nothing* and exiting if you do
not get *something*.  Please update memory.c to skip malloc if 0 bytes are
requested or update the configure script to automatically include m-gaurd
if malloc(0) returns null.

Thanks



From dshaw@jabberwocky.com  Wed May  8 00:46:02 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Tue May  7 23:46:02 2002
Subject: AIX malloc(0) is null
In-Reply-To: <Pine.A41.4.40.0205071551390.12276-100000@orion.it.luc.edu>
References: <Pine.A41.4.40.0205071551390.12276-100000@orion.it.luc.edu>
Message-ID: <20020507214715.GB3487@akamai.com>

On Tue, May 07, 2002 at 04:35:11PM -0500, B. Galliart wrote:
> How many people believe in testing if their computer is out of memory by
> requesting the allocation of *0* bytes?
> 
> So, what is wrong with the following picture:
>   gpg: out of  memory while allocating 0 bytes

Fixed in 1.0.8.  See
  http://lists.gnupg.org/pipermail/gnupg-users/2002-May/013022.html
for temporary patch.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From bgallia@orion.it.luc.edu  Wed May  8 08:34:01 2002
From: bgallia@orion.it.luc.edu (B. Galliart)
Date: Wed May  8 07:34:01 2002
Subject: AIX malloc(0) is null
In-Reply-To: <20020507214715.GB3487@akamai.com>
Message-ID: <Pine.A41.4.40.0205080024590.12276-100000@orion.it.luc.edu>

Wow, fixed 6.5 hours before I post.  That is increditable timing.

You wouldn't have a trick up your sleeve for the problem below.  I can
recreate the issue with both gcc v2.9 and gcc v3.04 but IBM's v3.6.4 C
compiler goes through without a problem.  Is this a GNUPG or GCC issue?

mpih-div.c: In function `mpihelp_mod_1':
mpih-div.c:86: warning: implicit declaration of function `__udiv_w_sdiv'
mpih-div.c:100: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:100: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:106: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:106: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:136: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:136: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c: In function `mpihelp_divrem':
mpih-div.c:290: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:354: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c: In function `mpihelp_divmod_1':
mpih-div.c:447: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:447: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:453: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:453: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:482: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:482: Can't find a register in class `MQ_REGS' while reloading `asm'.




From wk@gnupg.org  Wed May  8 11:31:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Wed May  8 10:31:01 2002
Subject: AIX malloc(0) is null
In-Reply-To: <Pine.A41.4.40.0205080024590.12276-100000@orion.it.luc.edu> ("B.
 Galliart"'s message of "Wed, 8 May 2002 00:35:29 -0500 (CDT)")
References: <Pine.A41.4.40.0205080024590.12276-100000@orion.it.luc.edu>
Message-ID: <87znzbjc8h.fsf@alberti.gnupg.de>

On Wed, 8 May 2002 00:35:29 -0500 (CDT), B Galliart said:

> mpih-div.c:86: warning: implicit declaration of function `__udiv_w_sdiv'
> mpih-div.c:100: Can't find a register in class `MQ_REGS' while reloading `asm'.

This is more a problem of using GCC with the native as(1)  I have
no instant solution for this.  Compiling GMP should yield the same
problems.

   Werner



From order@elite-code-runner.com  Wed May  8 21:14:02 2002
From: order@elite-code-runner.com (Bolder Computer Solutions)
Date: Wed May  8 20:14:02 2002
Subject: Cover Your Tracks
Message-ID: 47494851946830.70799.qmail@elite-code-runner.com

                                             Cover your Tracks

We at Bolder Computer Solutions have been looking for a software developer that has the state of the art software programs, at the right price, which can protect all of us on the Internet. We found Elite Code Runner!!! Elite Code Runner has products designed at blocking Hackers from your computer, software designed to delete all traces of your surfing and also your document and history files, and software to let you know where your children, your employees, your friends, and anyone that uses your computer, have gone when they are using your computer. 

                                                 Trace Breaker

Trace Breaker is a software program that is designed to erase all traces of your travels around the Internet. We have also added the ability to this software programs to clear all your history files from the internet, clear your cookies, delete the typed URL's, Windows Recent files, Office Recent files, and your Document files. These are all user selectable allowing you to keep the files you choose.

Trace Breaker $ 49.95

Name :______________________________________________________________
Address :____________________________________________________________
City State Zip______________________________________  _____   ___________
Amount Enclosed :_$______________

                      We except company checks or Money orders.
***** Add $6.95 shipping and Handling for each package you order. *****
***** Make all checks payable to Bolder Computer Solutions.            *****
Mail to:

Bolder Computer Solutions
27 Shethar Street
P.O. Box 25
Hammondsport, NY 14840-0025

Shipping as soon as checks clear. Immediately with Money orders.

***** Print this ad, circle selections and mail with payment                 *****




From andreas@xss.co.at  Thu May  9 14:34:02 2002
From: andreas@xss.co.at (Andreas Haumer)
Date: Thu May  9 13:34:02 2002
Subject: gnupg-1.0.7: missing dependencies in checks/Makefile
Message-ID: <3CDA5EDF.990C18F8@xss.co.at>

Hi!

I found a small problem in the checks/Makefile for gnupg-1.0.7

Some of the checks there need a script "gpg_dearmor", which
itself is created by make on the fly. But this dependency
is not explicitly listed in the Makefile, so a "make -j2"
(or any build with more than one job running simultaneously) 
fails on our Dual CPU development server.

I'd suggest to add "gpg_dearmor" to the dependency section of
all make targets where this script is used (just like it 
already is for target "./pubring.gpg")

Regards,

- andreas

-- 
Andreas Haumer                     | mailto:andreas@xss.co.at
*x Software + Systeme              | http://www.xss.co.at/
Karmarschgasse 51/2/20             | Tel: +43-1-6060114-0
A-1100 Vienna, Austria             | Fax: +43-1-6060114-71


From mwy-gpg41@the-youngs.org  Thu May  9 21:52:01 2002
From: mwy-gpg41@the-youngs.org (Michael Young)
Date: Thu May  9 20:52:01 2002
Subject: Notation data format: "user" name space rejected
References: <E175fVC-0001KU-00@trithemius.gnupg.org>
Message-ID: <007201c1f78a$9a6d81e0$ebc42609@transarc.ibm.com>

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

The latest draft of RFC2440 describes two name spaces for notation
data, one of which GnuPG rejects as invalid.  Specifically, the
RFC describes the "user" name space:

>    Names in the user name space consist of a UTF-8 string tag followed
>    by "@" followed by a DNS domain name. Note that the tag MUST NOT
>    contain an "@" character. For example, the "sample" tag used by
>    Example Corporation could be "sample@example.com".

When I try to generate such a notation, I get this error:
    log_error(_("a notation name must have only letters, "
  "digits, dots or underscores and end with an '='\n") );

(My test used 1.0.6, but it doesn't appear to have changed in the
latest source.)

At first glance, it would appear that adding the "@" character
to the check on the line before the log_error() would be sufficient.
But neither the "tag" nor the DNS domain name should need to meet
these tight restrictions (alphanumeric/dot/underscore).  So, I
would suggest looking for a "@" first, at which point almost
anything goes.  Does that seem reasonable?

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQA/AwUBPNrFJFMkvpTT8vCGEQKhpgCg2dVswZWsaKwSZGkvQh7Cg3UYDjoAoMCz
tgIKnXkM0nKFPmSe2YWZRWXQ
=U8xW
-----END PGP SIGNATURE-----




From Dr. Carter" <Have_Open_Mind@yahoo.com  Thu May  9 22:02:01 2002
From: Dr. Carter" <Have_Open_Mind@yahoo.com (Dr. Carter)
Date: Thu May  9 21:02:01 2002
Subject: To: g10 as a Good Person - Conduct Education in the 21st Century
Message-ID: <4140-2200254919350630@oemcomputer>

Dear g10:

You may ask yourself
      >    How to make people respect you
      >    How to win friends
      >    How to let your conduct help your health, work, job, career, re=
lationships, spirit,  mind, well-being, =2E=2E=2E
      >    How to make your life smoother and happier=20
      >    How to do whatever you like without being unpleasant to other p=
eople=20
      >    How to develop good conduct in your children or students=20
      >    How to make the world peaceful and better

You can find all the answers to these questions, and much more, in this gr=
eat handbook:
=20
"Complete Conduct Principles for the 21st Century" by Dr=2E John Newton=20=


It is the best educational GIFT idea for children, friends, relatives, cla=
ssmates, students, parents, teachers, other educators, =2E=2E=2E, particul=
arly at this special time=2E=20

BENEFITS to each individual reader: Many! -- such as for health, work, job=
, career, self-improvement, education, relationships, spirit, mind, well-b=
eing, and much more -- almost all the areas that are important to you in t=
he 21st century=2E People around you will benefit, too=2E (Please see the =
PREFACE of the book for details=2E)=20

EVERYONE may find this handbook useful and helpful, regardless of age (fro=
m children to oldsters), occupation, rank, status, gender, religious belie=
fs, nationality, country, or region=2E=20

If you are a parent or a teacher, you can learn how to develop good conduc=
t in your children or students from this handbook=2E Please advise your ch=
ildren or students to read the book=2E It will result in great benefits fo=
r both you and them=2E=20

(Note: If you are interested in the issue of School Violence, Youth Proble=
ms, Violence Prevention, or Conduct Education in the 21st Century, please =
see the APPENDIX below=2E) =20

This book is a must for EVERYONE to be better prepared for personal conduc=
t for the 21st century=2E=20

The book's content is obvious from its title=2E The complete useful conduc=
t principles cover not only what we should do, but also what we should not=
 do -- especially those faults people make often and easily=2E=20

This timely, unique, and very important handbook is designed to suit most =
people, and is self-contained and user-friendly=2E=20

This book is significantly different and better than competitive works=2E

Some of its innovative contents may help solve problems that Western cultu=
re cannot=2E=20

The book's merit and importance have been recognized and praised by many e=
xperts, elected public officials, and world leaders=2E

How to make the world peaceful and better ---
You can find the solution in the book=2E
Let's work together to make the world peaceful and better!=20

The author, John Newton, holds a Ph=2ED=2E from MIT, and does researches a=
t Harvard=2E His long-term research on "The personal conduct in the human =
society of the 21st century" resulted in this book=2E It is published by N=
icer Century World Organization, headquartered beside Harvard University a=
nd MIT, two leading institutes of new knowledge and literature=2E

The book is available in two types of binding: Hardcover (ISBN 0967370574;=
 case bound, Smyth sewn; with dust jacket) and Paperback (ISBN 0967370582;=
 perfect bound)=2E Both editions are unabridged, and are printed on 60 lb,=
 natural, acid-free, excellent and healthful paper=2E You can get the book=
 from many fine on-line bookstores and traditional bookstores=2E For your =
convenience, I herewith provide you with a link directly to the book page =
in the shopping directory of Yahoo!, the world's No=2E 1 Internet director=
y:

http://shopping=2Eyahoo=2Ecom/shop?d=3Db&id=3D3680641&clink=3Ddmpr-hm/rp&c=
f=3Dsetup

Some bookstores there offer great discounts (for a limited time)=2E Note t=
hat some of the bookstores may disappear there if out-of-stock=2E In that =
case, you may want to go to another bookstore=2E Of course, you may freely=
 go to other bookstores at any time, even if they are not listed in Yahoo!=
=2E

Please forward this e-mail to people you know -- children, friends, relati=
ves, classmates, students, parents, teachers, other educators, =2E=2E=2E, =
because they can benefit from it, too=2E This can be a wonderful kindness =
you provide to them!

g10, best wishes to you!


Sincerely yours,

Tom Carter, Ph=2ED=2E
President, Nicer Century World Organization
Massachusetts, USA

(Nicer Century World Organization is an educational, non-profit, non-parti=
san organization; it endeavors to make the 21st century nicer than ever be=
fore=2E To accomplish its mission, Nicer Century World Organization is pro=
ud to introduce this book=2E)=20

-----------------------------------------------------------

APPENDIX: School Violence, Youth Problems, Violence Prevention, and Conduc=
t Education in the 21st Century

In recent years school violence has made many pieces of nation-shaking hig=
hlighted headline news, which have astounded the Americans=2E It may happe=
n at any school, at any time, and by students of any age=2E Some experts b=
elieve this is the most important national crisis the U=2ES=2E is facing=2E=
=20

"In the 21st century the problem will happen not only continuously in the =
U=2ES=2E but also in lots of other countries all over the world, if we do =
not act=2E" said Dr=2E John Newton in the late 20th century=2E Recent trag=
edies have proved this warning prediction=2E

"The most effective and proper way to solve the problem is appropriate con=
duct education=2E" said Dr=2E Newton=2E

"The significance of the problem" is much more important than "the number =
of people killed in schools"=2E=20

In addition to shooting and killing, other kinds of school violence, such =
as rape, sexual assault, aggravated assault, robbery, bullying, mugging, f=
ighting, theft, harassment, =2E=2E=2E, and other youth problems, like suic=
ide, suicide attempt, suicide inclination, pessimism, sense of inferiority=
, lose of  self-control, relationship problems, emotion problems, drug abu=
se, discrimination, =2E=2E=2E, cannot be ignored, either=2E

Some measures may handle a few "symptoms" temporarily and partially but ar=
e not solutions for education, particularly in view of our responsibilitie=
s for the whole society=2E

Now an effective, proper, comprehensive, deep-rooted and permanent solutio=
n is needed!

The book, "Complete Conduct Principles for the 21st Century" by Dr=2E John=
 Newton, is regarded as "the very one that can effectively help solve the =
problem of school violence in a right way" by some experts in education, i=
ncluding Dr=2E Steve White, who pointed out clearly: "If students, teacher=
s and parents can learn the conduct principles in this book well, then tha=
t 'unsolvable' problem will be solved=2E  It is not difficult at all to le=
arn them, because the book is a simple, easy, clear, convenient and self-c=
ontained handbook, well designed to suit most people=2E" The book was also=
 praised as "a compendium of concisely expressed, practical, informative, =
pertinent, workable advice" by Michael J=2E Carson, a professional book re=
viewer=2E

"Unlike most books of this subject, it is NOT a religious book, nor is a c=
ollection of old conduct rules=2E"=20

As analyzed in the Preface of the book, "from now on learning good conduct=
 should be placed as No=2E 1 in education=2E"=20

The book's merit and importance have been recognized and praised by many e=
ducation experts, elected public officials, and world leaders=2E Some educ=
ational units, ranging from the level of nation or state to individual sch=
ool or university, have ordered the book either as textbook/reference book=
 or as an active action to prevent school violence, to improve education a=
nd to benefit students, teachers & parents=2E=20

"The book will also be effective for violence prevention for the whole soc=
iety=2E"

Hence, to prevent school violence and other violence, to improve education=
, and to benefit students, teachers, parents, & the whole society, I earne=
stly request you to inform the students, teachers, parents, school library=
 and other relevant people you know of the availability of the book=2E

A reasonable method you may consider choosing is to simply  forward this l=
etter to them=2E

Although it will be helpful and appreciated, it is NOT necessary that you =
state any endorsement or the like=2E

Your efforts to prevent school violence and other violence, to improve edu=
cation, and to benefit students, teachers, parents, & the whole society wi=
ll be highly appreciated=2E




From dshaw@jabberwocky.com  Thu May  9 22:16:01 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Thu May  9 21:16:01 2002
Subject: Notation data format: "user" name space rejected
In-Reply-To: <007201c1f78a$9a6d81e0$ebc42609@transarc.ibm.com>
References: <E175fVC-0001KU-00@trithemius.gnupg.org> <007201c1f78a$9a6d81e0$ebc42609@transarc.ibm.com>
Message-ID: <20020509191712.GC3323@akamai.com>

On Thu, May 09, 2002 at 02:52:00PM -0400, Michael Young wrote:

> The latest draft of RFC2440 describes two name spaces for notation
> data, one of which GnuPG rejects as invalid.  Specifically, the
> RFC describes the "user" name space:
> 
> >    Names in the user name space consist of a UTF-8 string tag followed
> >    by "@" followed by a DNS domain name. Note that the tag MUST NOT
> >    contain an "@" character. For example, the "sample" tag used by
> >    Example Corporation could be "sample@example.com".
> 
> When I try to generate such a notation, I get this error:
>     log_error(_("a notation name must have only letters, "
>   "digits, dots or underscores and end with an '='\n") );
> 
> (My test used 1.0.6, but it doesn't appear to have changed in the
> latest source.)

It hasn't.  The problem here is that between 2440 and one of the
succeeding 2440bis drafts the spec here changed slightly, so there is
a bit of a 'moving target' effect.  I'll look into it.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From karlsson@hal-pc.org  Thu May  9 22:39:02 2002
From: karlsson@hal-pc.org (Brian M. Carlson)
Date: Thu May  9 21:39:02 2002
Subject: force-v4-certs and digest-algo
Message-ID: <20020509194024.GB6949@stonewall>

--DKU6Jbt7q3WqK7+M
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

I have set force-v4-certs in my options file. I also have digest-algo RIPEM=
D160
set. Yet, my signatures still are made with SHA1, which I deprecate strongl=
y.
If I have a preference on my key, I'd prefer that gpg choose that, unless
I choose a digest-algo option, in which case gpg uses that. gpg has done
neither.

Is that possible without a rewrite of the code?

--=20
Brian M. Carlson
<karlsson@hal-pc.org>
OpenPGP: 0x351336B2DCA1913A

--DKU6Jbt7q3WqK7+M
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Ubi libertas, ibi patria.

iQEVAwUBPNrQqOWR/8lWBVPnAQPyhQf6AwTw3UZm/jq0or8fw45VcIA2BN5czunY
gzKRWn47HW5aRwWNE4x1tOEfhOZbeg7CFxFM4lEKmuCTL8Qu4/+xCk79z9ne58eS
Ke25JxVgpQ6Q046LyBbaPaKtJFaF9U+YqbO4KJZ8E5/LSUCoBmdEgwFgnWyCVizp
yLZEDgA3kdId6BZoZ7OdiM+yKKnIRc1qd9QJ0N2MfpvTwG7f59oNKRTOqWoDR5Am
112UvcYJtYoMjP3/dP3mDUk71qkoExkwbuQbMwQvTYjDNH6jU7U5DKTcikPQSTYR
LlFjeumAVe6janjDnh6vlfy1nAv/Iq6uAADclh7DHVNVGRI1AQshAw==
=ObM8
-----END PGP SIGNATURE-----

--DKU6Jbt7q3WqK7+M--


From dshaw@jabberwocky.com  Thu May  9 22:50:01 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Thu May  9 21:50:01 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <20020509194024.GB6949@stonewall>
References: <20020509194024.GB6949@stonewall>
Message-ID: <20020509195108.GE3323@akamai.com>

On Thu, May 09, 2002 at 07:40:24PM +0000, Brian M. Carlson wrote:

> I have set force-v4-certs in my options file. I also have
> digest-algo RIPEMD160 set. Yet, my signatures still are made with
> SHA1, which I deprecate strongly.  If I have a preference on my key,
> I'd prefer that gpg choose that, unless I choose a digest-algo
> option, in which case gpg uses that. gpg has done neither.

Let me make sure I understand what you are doing.  You want your key
signatures - not data signatures - to use RIPEMD160 and not SHA1?

--digest-algo only applies to data signatures.

Why do you strongly deprecate SHA1?

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From mutz@kde.org  Thu May  9 23:36:05 2002
From: mutz@kde.org (Marc Mutz)
Date: Thu May  9 22:36:05 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <20020509194024.GB6949@stonewall>
References: <20020509194024.GB6949@stonewall>
Message-ID: <200205092236.31196@sendmail.mutz.com>

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 09 May 2002 21:40, Brian M. Carlson wrote:
> I have set force-v4-certs in my options file. I also have digest-algo
> RIPEMD160 set. Yet, my signatures still are made with SHA1,
<snip>

Well, according to the micalg parameter of your mp/signed, your last messag=
e=20
_was_ RIMEMD160.

Marc

=2D --=20
Marc Mutz <mutz@kde.org>
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE82t3N3oWD+L2/6DgRAlcvAJoDRQr+9AIq9J1k4jioo1LiPufPIgCgtFag
/LWfdENWjoE8xSHeFk67tNU=3D
=3DxDxC
=2D----END PGP SIGNATURE-----



From karlsson@hal-pc.org  Thu May  9 23:54:02 2002
From: karlsson@hal-pc.org (Brian M. Carlson)
Date: Thu May  9 22:54:02 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <20020509195108.GE3323@akamai.com>
References: <20020509194024.GB6949@stonewall> <20020509195108.GE3323@akamai.com>
Message-ID: <20020509205512.GC6949@stonewall>

--bKyqfOwhbdpXa4YI
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, May 09, 2002 at 03:51:08PM -0400, David Shaw wrote:
> On Thu, May 09, 2002 at 07:40:24PM +0000, Brian M. Carlson wrote:
>=20
> > I have set force-v4-certs in my options file. I also have
> > digest-algo RIPEMD160 set. Yet, my signatures still are made with
> > SHA1, which I deprecate strongly.  If I have a preference on my key,
> > I'd prefer that gpg choose that, unless I choose a digest-algo
> > option, in which case gpg uses that. gpg has done neither.
>=20
> Let me make sure I understand what you are doing.  You want your key
> signatures - not data signatures - to use RIPEMD160 and not SHA1?
>=20
> --digest-algo only applies to data signatures.
>=20
> Why do you strongly deprecate SHA1?

SHA1 was created by the US government. I feel that the US government does n=
ot
have its citizens best interest at heart in the realm of cryptography, and
sometimes not with privacy in general. I prefer RIPEMD160 as it was created
independently outside of the US. Anyway, whatever my reason, shouldn't it
be my choice?

digest-algo has worked before, with my RSA key and with my ElGamal 20 key (=
see
sig) on key signatures. I might be able to dig them up for you.

--=20
Brian M. Carlson
<karlsson@hal-pc.org>
OpenPGP: 0x351336B2DCA1913A

--bKyqfOwhbdpXa4YI
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Ubi libertas, ibi patria.

iQEVAwUBPNriMOWR/8lWBVPnAQMc1Af/Wm+U4ujICM9ur9JRxWBhRVR5zuiPhxVT
RtpmsROW/0opBSi3e1Y1BUwzO6f6z1M+1lD65xuTsCG57nzIsNNmgVI/CH7SZrBj
RXbp8DuLt0WTGsXvGrJRqGNrrPtLg9FsaGz+rWgylStNyujzg2dpNbDti6YkqoN5
IcFckpX5KxW3kIbFZ/9JR41LzxwiR4reZoiIrXCnkarGvSYlbtnSREkmYhdrSkaH
Dn+BY05stL4mfuKXEpuEAgK9qVIt14xx8QyjevlYkpl80AD5Hw+O1mR1eqb7OLnQ
NL8rBwOd4Dhgejq06WP3+pEujAqxssjRmOddPguvRbvbItwUAHLnaQ==
=SIup
-----END PGP SIGNATURE-----

--bKyqfOwhbdpXa4YI--


From karlsson@hal-pc.org  Thu May  9 23:58:01 2002
From: karlsson@hal-pc.org (Brian M. Carlson)
Date: Thu May  9 22:58:01 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <20020509195108.GE3323@akamai.com>
References: <20020509194024.GB6949@stonewall> <20020509195108.GE3323@akamai.com>
Message-ID: <20020509205912.GD6949@stonewall>

--at6+YcpfzWZg/htY
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, May 09, 2002 at 03:51:08PM -0400, David Shaw wrote:
> On Thu, May 09, 2002 at 07:40:24PM +0000, Brian M. Carlson wrote:
>=20
> > I have set force-v4-certs in my options file. I also have
> > digest-algo RIPEMD160 set. Yet, my signatures still are made with
> > SHA1, which I deprecate strongly.  If I have a preference on my key,
> > I'd prefer that gpg choose that, unless I choose a digest-algo
> > option, in which case gpg uses that. gpg has done neither.
>=20
> Let me make sure I understand what you are doing.  You want your key
> signatures - not data signatures - to use RIPEMD160 and not SHA1?

Yes. I want all my uses of the hash function for signatures to be with
RIPEMD160. I also use s2k-digest-algo RIPEMD160, but that is unrelated.=20

--=20
Brian M. Carlson
<karlsson@hal-pc.org>
OpenPGP: 0x351336B2DCA1913A

--at6+YcpfzWZg/htY
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Ubi libertas, ibi patria.

iQEVAwUBPNrjIOWR/8lWBVPnAQM1gAgAgtNXo8MtYjBW6bhwPPXZtWAQ5Ssl4UXD
Z07RkNGCe8ITiomTbddFWZO7o+gxEF0NX/eLaMTARtGmDqGWypeSpIuIGM1Z2qfG
vZ9wlUV9MZdvk0mmWhRpIlT1DzLpKsAwzOExUCPBZVV1X6ALUhjG7Y16RIzfVZZc
CzO+nyQIjRYO12iShNDQCVJW6R6751Fc6Cx/BViTu5FzAQ877VYrRi/Gls4E2+Al
Ke/M+su62b9jadyGRiiYC41DtEG/NIl8Mi+qGjwZRGt8PIJ45r3Ugg4tLjnfBjjr
vV5kWauq8CxR2O38Ty14EhTOFrUe518Abi36Hbuxgaqvqh/3GPSG4w==
=aAr/
-----END PGP SIGNATURE-----

--at6+YcpfzWZg/htY--


From rjhansen@inav.net  Fri May 10 00:21:01 2002
From: rjhansen@inav.net (Robert J. Hansen)
Date: Thu May  9 23:21:01 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <20020509205512.GC6949@stonewall>
References: <20020509194024.GB6949@stonewall>
 <20020509195108.GE3323@akamai.com>  <20020509205512.GC6949@stonewall>
Message-ID: <1020979199.32490.9.camel@numbers>

> SHA1 was created by the US government. I feel that the US government does not
> have its citizens best interest at heart in the realm of cryptography, and

SHA-1 isn't used for message security; it's used for message
authentication.  The NSA's mandate includes keeping US Gov't traffic
secure, and as such, deliberately creating a faulty hash
algorithm--especially one that's heavily used throughout the USG--would
be counter to the NSA's mandate.

Then there's also the intense peer review, and the fact that it's SHA-1,
not SHA-0... SHA-0 had a nasty, but very subtle, bug.  Who found the
bug, publicized it, and issued a fix?  The NSA.

While I agree there's a lot of room for skepticism on the NSA's motives,
it appears to me that throwing out SHA-1 is tossing the baby out with
the bathwater.  Still--if it floats your boat, use RIPEMD160.

> independently outside of the US. Anyway, whatever my reason, shouldn't it
> be my choice?

Not necessarily.  The axiom which guides GnuPG is "be liberal in what
you accept, but conservative in what you generate".  If I recall,
RIPEMD-160 is a SHOULD, not a MUST.  It would be entirely consistent and
RFC-conformant for GnuPG to accept RIPEMD-160 in traffic, but to only
use SHA-1 for output.

I'm not suggesting we do that, by the by.  I'm just pointing out that
"shouldn't it be my choice?" isn't always something you answer with a
"yes".  There's a time and a place for strict enforcement of policy.




From dshaw@jabberwocky.com  Fri May 10 00:31:01 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Thu May  9 23:31:01 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <20020509205512.GC6949@stonewall>
References: <20020509194024.GB6949@stonewall> <20020509195108.GE3323@akamai.com> <20020509205512.GC6949@stonewall>
Message-ID: <20020509213137.GB6484@akamai.com>

On Thu, May 09, 2002 at 08:55:13PM +0000, Brian M. Carlson wrote:
> On Thu, May 09, 2002 at 03:51:08PM -0400, David Shaw wrote:
> > On Thu, May 09, 2002 at 07:40:24PM +0000, Brian M. Carlson wrote:
> > 
> > > I have set force-v4-certs in my options file. I also have
> > > digest-algo RIPEMD160 set. Yet, my signatures still are made with
> > > SHA1, which I deprecate strongly.  If I have a preference on my key,
> > > I'd prefer that gpg choose that, unless I choose a digest-algo
> > > option, in which case gpg uses that. gpg has done neither.
> > 
> > Let me make sure I understand what you are doing.  You want your key
> > signatures - not data signatures - to use RIPEMD160 and not SHA1?
> > 
> > --digest-algo only applies to data signatures.
> > 
> > Why do you strongly deprecate SHA1?
> 
> SHA1 was created by the US government. I feel that the US government does not
> have its citizens best interest at heart in the realm of cryptography, and
> sometimes not with privacy in general. I prefer RIPEMD160 as it was created
> independently outside of the US. Anyway, whatever my reason, shouldn't it
> be my choice?

Sure, I'm just curious.

There is one "danger" of making RIPEMD160 key signatures, in that it
is not a required algorithm in OpenPGP.  There can be implementations
that do not support it, and so key signatures using it are not
universally usable.  This means that two different implementations may
have two different views of the web of trust, which is not a great
thing.

That said, they're your signatures, and you need to make them in a way
that you are comfortable with.  The two "bigs", PGP and GnuPG both
support RIPEMD160.

> digest-algo has worked before, with my RSA key and with my ElGamal
> 20 key (see sig) on key signatures. I might be able to dig them up
> for you.

ElGamal key signatures use RIPEMD160 by default.  What version of
GnuPG did you do the RSA one with?  It certainly couldn't have been
1.0.6 or 1.0.7.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From rabbi@quickie.net  Fri May 10 00:44:01 2002
From: rabbi@quickie.net (Len Sassaman)
Date: Thu May  9 23:44:01 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <1020979199.32490.9.camel@numbers>
Message-ID: <Pine.LNX.4.30.QNWS.0205091430390.10536-100000@thetis.deor.org>

On 9 May 2002, Robert J. Hansen wrote:

> Not necessarily.  The axiom which guides GnuPG is "be liberal in what
> you accept, but conservative in what you generate".  If I recall,
> RIPEMD-160 is a SHOULD, not a MUST.  It would be entirely consistent and
> RFC-conformant for GnuPG to accept RIPEMD-160 in traffic, but to only
> use SHA-1 for output.

First of all: RIPEMD-160 is neither a MUST or a SHOULD. (It's neither a
required, not suggested, algorithm in OpenPGP. Don't be surprised if
implementations do not support or understand RIPEMD-160 signatures).

Secondly, DSS is defined as requiring SHA-1. Consequently, SHA-1 has
received more attention than other 160-bit hash algorithms by
cryptographers. RIPEMD-160 is considered by many to be just as strong, but
it certainly hasn't received the same level of scrutiny.

Notice, also, that the security of PGP signatures is somewhat dependant
upon all of the hashes that the implementation allows. I draw your
attention to section 13 of RCF 2440bis05:

     * There is a somewhat-related potential security problem in
       signatures. If an attacker can find a message that hashes to the
       same hash with a different algorithm, a bogus signature
       structure can be constructed that evaluates correctly.

       For example, suppose Alice DSA signs message M using hash
       algorithm H. Suppose that Mallet finds a message M' that has the
       same hash value as M with H'. Mallet can then construct a
       signature block that verifies as Alice's signature of M' with
       H'. However, this would also constitute a weakness in either H
       or H' or both. Should this ever occur, a revision will have to
       be made to this document to revise the allowed hash algorithms.


So, if any of the hash algorithms are broken, we could be in quite a bit
of trouble. (This is my argument against adding in SHA-256, etc., until
there is a clear benefit (such as larger DSA keys) to doing so.)


Len



From karlsson@hal-pc.org  Fri May 10 01:25:02 2002
From: karlsson@hal-pc.org (Brian M. Carlson)
Date: Fri May 10 00:25:02 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <Pine.LNX.4.30.QNWS.0205091430390.10536-100000@thetis.deor.org>
References: <1020979199.32490.9.camel@numbers> <Pine.LNX.4.30.QNWS.0205091430390.10536-100000@thetis.deor.org>
Message-ID: <20020509222550.GE6949@stonewall>

--pY3vCvL1qV+PayAL
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, May 09, 2002 at 02:44:43PM -0700, Len Sassaman wrote:
> On 9 May 2002, Robert J. Hansen wrote:
>=20
> > Not necessarily.  The axiom which guides GnuPG is "be liberal in what
> > you accept, but conservative in what you generate".  If I recall,
> > RIPEMD-160 is a SHOULD, not a MUST.  It would be entirely consistent and
> > RFC-conformant for GnuPG to accept RIPEMD-160 in traffic, but to only
> > use SHA-1 for output.
>=20
> First of all: RIPEMD-160 is neither a MUST or a SHOULD. (It's neither a
> required, not suggested, algorithm in OpenPGP. Don't be surprised if
> implementations do not support or understand RIPEMD-160 signatures).

While this may be true, it is a de facto SHOULD, just like IDEA is.
=20
> Secondly, DSS is defined as requiring SHA-1. Consequently, SHA-1 has
> received more attention than other 160-bit hash algorithms by
> cryptographers. RIPEMD-160 is considered by many to be just as strong, but
> it certainly hasn't received the same level of scrutiny.

The last time I used my DSA key, other than to update its expiration date,
was over a year ago. I use my RSA key almost exclusively. When I don't, I
use my ElGamal type 20 key. (I know how you feel about ElGamal 20 keys ;-)
There is no reason that DSA couldn't use any other 160 bit hash. Neverthele=
ss,
I *do* use SHA1 with DSA.

> Notice, also, that the security of PGP signatures is somewhat dependant
> upon all of the hashes that the implementation allows. I draw your
> attention to section 13 of RCF 2440bis05:
<snip>

I am quite aware of the requirements for a collision-resistant hash functio=
n.
I own Applied Cryptography and have read it several times. I have also read
other works on the subject, including the definition of RIPEMD160.

--=20
Brian M. Carlson
<karlsson@hal-pc.org>
OpenPGP: 0x351336B2DCA1913A

--pY3vCvL1qV+PayAL
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Ubi libertas, ibi patria.

iQEVAwUBPNr3buWR/8lWBVPnAQOEHgf/VW62sV76aCca5/02aJxU1XaFrmsmbdKg
wyrngl6Q+AwIp/aS7WdjJrcQtL7B1d71fxh6e8NsNj2t3Nxcn4FJka49EmFzyzFb
189PLjqEEYa5gbYVaMrr6MAhFxa1pJWegpTfuGzba8uLVXdowZku76xwvMArldMC
i7pSnUDmPUh1yUjgmPMnDDHktkXjt9UvbuU96VTu2yxD54oOqhCeArxuaSENjXhA
GJyhJy4u9X3ShCB78M5eVfdl25JdZu2D7TFPuxV4Uh0TOqDKadBvei+pQYsComVc
mn4qxdJ2iwpquYOhGixcmHjgiNeP5UrzJaI7jW/YdM+I70Y6yqzNIw==
=zbnQ
-----END PGP SIGNATURE-----

--pY3vCvL1qV+PayAL--


From rabbi@quickie.net  Fri May 10 01:29:02 2002
From: rabbi@quickie.net (Len Sassaman)
Date: Fri May 10 00:29:02 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <20020509222550.GE6949@stonewall>
Message-ID: <Pine.LNX.4.30.QNWS.0205091526130.14462-100000@thetis.deor.org>

On Thu, 9 May 2002, Brian M. Carlson wrote:

> > First of all: RIPEMD-160 is neither a MUST or a SHOULD. (It's neither a
> > required, not suggested, algorithm in OpenPGP. Don't be surprised if
> > implementations do not support or understand RIPEMD-160 signatures).
>
> While this may be true, it is a de facto SHOULD, just like IDEA is.

Untrue. If it isn't listed as SHOULD in the document, it isn't a SHOULD.
There are no "de facto SHOULDs."

IDEA is a SHOULD in RFC 2440. Its status has since changed, I believe.





From rjhansen@inav.net  Fri May 10 05:47:01 2002
From: rjhansen@inav.net (Robert J. Hansen)
Date: Fri May 10 04:47:01 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <20020509222550.GE6949@stonewall>
References: <1020979199.32490.9.camel@numbers>
 <Pine.LNX.4.30.QNWS.0205091430390.10536-100000@thetis.deor.org>
 <20020509222550.GE6949@stonewall>
Message-ID: <1020998781.524.11.camel@numbers>

> While this may be true, it is a de facto SHOULD, just like IDEA is.

Be careful. Going further down this road will lead us to the World of
Microsoft.  There's a razor's edge between saying "we will support the
spec, including all SHOULDs" and saying "we will support the spec, plus
whatever additional things we feel are de-facto standards".  The one way
is the Free Software/Open Source way.  The other way is the Microsoft
Embrace and Extend way (q.v., their Kerberos implementation).

Unless the spec lists it as a MUST or a SHOULD, I honestly don't think
GnuPG should generate it.  Be liberal in what you accept, but very
conservative in what you generate.  (I know that Len says RIPEMD-160
isn't a SHOULD, and I have no reason to doubt him.  However, I haven't
checked RFC2440/2015/3156 myself yet, so I'll hedge it with an
`unless'.)

> There is no reason that DSA couldn't use any other 160 bit hash. Nevertheless,

Sure there is.  If DSA used any other 160-bit hash, it wouldn't be DSA
anymore because the DSA spec demands SHA.  Insofar as whether or not the
DSA spec could be changed to accept RIPEMD-160, and whether or not the
resulting system would still be secure... who knows?  Cryptosystems are
fragile things; known-strong algorithms can interact with each other to
produce weak systems.





From dshaw@jabberwocky.com  Fri May 10 07:23:01 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Fri May 10 06:23:01 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <1020998781.524.11.camel@numbers>
References: <1020979199.32490.9.camel@numbers> <Pine.LNX.4.30.QNWS.0205091430390.10536-100000@thetis.deor.org> <20020509222550.GE6949@stonewall> <1020998781.524.11.camel@numbers>
Message-ID: <20020510042351.GB662@akamai.com>

On Thu, May 09, 2002 at 09:46:18PM -0500, Robert J. Hansen wrote:

> Unless the spec lists it as a MUST or a SHOULD, I honestly don't think
> GnuPG should generate it.  Be liberal in what you accept, but very
> conservative in what you generate.  (I know that Len says RIPEMD-160
> isn't a SHOULD, and I have no reason to doubt him.  However, I haven't
> checked RFC2440/2015/3156 myself yet, so I'll hedge it with an
> `unless'.)

He's right.  SHA1 is the only MUST hash, and MD5 is the only SHOULD.

Still, the spec is not the beginning and the end of GnuPG.  GnuPG
certainly does things that are contrary to the spec (and documents
them carefully and gives the user the ability to turn them off).  For
example, when generating a clear signature, by default a line
beginning with "From " is escaped, probably in violation of a strict
reading of RFC2440.  The reason it does this is that clearsigned
documents are often emailed and otherwise the mail system would
probably break the signature when it changed "From " to ">From ".  PGP
does the same thing.

Another good example is the v3 sigs problem.  Most versions of PGP
don't handle v4 sigs on data, but the RFC says they are a SHOULD.  If
GnuPG blindly followed the SHOULD it would make itself incompatible
with PGP.

The --openpgp flag in GnuPG turns all of this off and makes it use a
rigid following of RFC2440.  If you use that flag though, you'll have
problems communicating with the rest of the world.

> > There is no reason that DSA couldn't use any other 160 bit hash. Nevertheless,
> 
> Sure there is.  If DSA used any other 160-bit hash, it wouldn't be DSA
> anymore because the DSA spec demands SHA.  Insofar as whether or not the
> DSA spec could be changed to accept RIPEMD-160, and whether or not the
> resulting system would still be secure... who knows?

Not quite correct.  The DSA algorithm can use any 160-bit hash.  The
DSS spec is DSA+SHA1 (plus some other details that don't matter here).
OpenPGP does not specify DSS signatures - it specifies DSA and can
thus use any 160-bit hash.

I agree with Len in general on being very careful with adding new
algorithms to OpenPGP, and in turn to GnuPG.  However, in the specific
case of RIPEMD-160, it's already part of the standard and both PGP and
GnuPG already support it.  There is no question on whether to add it -
it's already added.  There is also no evidence that it is not just as
secure as SHA1 is.

I don't see any particular reason for someone to not use RIPEMD-160
for data signatures - if there is a compatibility problem they're only
hurting themselves.  I do wish people would not use it for key
signatures, as a compatibility problem there affects the web of trust.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From Andreas.Lippek@DePfa.com  Fri May 10 08:59:02 2002
From: Andreas.Lippek@DePfa.com (Lippek, Andreas, IT-TR)
Date: Fri May 10 07:59:02 2002
Subject: unsubscribe
Message-ID: <A04A1C51B715E44C81D53F49C8DD08A70AD9D9@fraexx01.DEPFA-BANK.COM>


-----Original Message-----
From: Robert J. Hansen [mailto:rjhansen@inav.net]
Sent: Freitag, 10. Mai 2002 04:46
To: Brian M. Carlson
Cc: gnupg-devel@gnupg.org; rabbi@quickie.net
Subject: Re: force-v4-certs and digest-algo


> While this may be true, it is a de facto SHOULD, just like IDEA is.

Be careful. Going further down this road will lead us to the World of
Microsoft.  There's a razor's edge between saying "we will support the
spec, including all SHOULDs" and saying "we will support the spec, plus
whatever additional things we feel are de-facto standards".  The one way
is the Free Software/Open Source way.  The other way is the Microsoft
Embrace and Extend way (q.v., their Kerberos implementation).

Unless the spec lists it as a MUST or a SHOULD, I honestly don't think
GnuPG should generate it.  Be liberal in what you accept, but very
conservative in what you generate.  (I know that Len says RIPEMD-160
isn't a SHOULD, and I have no reason to doubt him.  However, I haven't
checked RFC2440/2015/3156 myself yet, so I'll hedge it with an
`unless'.)

> There is no reason that DSA couldn't use any other 160 bit hash.
Nevertheless,

Sure there is.  If DSA used any other 160-bit hash, it wouldn't be DSA
anymore because the DSA spec demands SHA.  Insofar as whether or not the
DSA spec could be changed to accept RIPEMD-160, and whether or not the
resulting system would still be secure... who knows?  Cryptosystems are
fragile things; known-strong algorithms can interact with each other to
produce weak systems.




_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel


From rabbi@quickie.net  Fri May 10 20:11:02 2002
From: rabbi@quickie.net (Len Sassaman)
Date: Fri May 10 19:11:02 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <1020998781.524.11.camel@numbers>
Message-ID: <Pine.LNX.4.30.QNWS.0205101003070.3958-100000@thetis.deor.org>

On 9 May 2002, Robert J. Hansen wrote:

> > While this may be true, it is a de facto SHOULD, just like IDEA is.
>
> Be careful. Going further down this road will lead us to the World of
> Microsoft.  There's a razor's edge between saying "we will support the
> spec, including all SHOULDs" and saying "we will support the spec, plus
> whatever additional things we feel are de-facto standards".  The one way
> is the Free Software/Open Source way.  The other way is the Microsoft
> Embrace and Extend way (q.v., their Kerberos implementation).

To further clarify what I was saying:

The entire point of the IETF, and of the RFC system, is to eliminate the
"de facto standards" mess, and give us actual standards.

> Unless the spec lists it as a MUST or a SHOULD, I honestly don't think
> GnuPG should generate it.  Be liberal in what you accept, but very
> conservative in what you generate.  (I know that Len says RIPEMD-160
> isn't a SHOULD, and I have no reason to doubt him.  However, I haven't
> checked RFC2440/2015/3156 myself yet, so I'll hedge it with an
> `unless'.)

Well, 2015/3156 don't cover this, so that's easy. But if you want to see
for yourself, it's section 9.4 of RFC2440bis5:

http://search.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-05.txt

> > There is no reason that DSA couldn't use any other 160 bit hash.
>
> Sure there is.  If DSA used any other 160-bit hash, it wouldn't be DSA
> anymore because the DSA spec demands SHA.  Insofar as whether or not the
> DSA spec could be changed to accept RIPEMD-160, and whether or not the
> resulting system would still be secure... who knows?  Cryptosystems are
> fragile things; known-strong algorithms can interact with each other to
> produce weak systems.

You are confusing DSA (the algorithm) with DSS (the standard). DSS
mandates DSA and SHA-1. DSA, however, could be used with any strong hash
function that is sufficiently long.

--Len.












From rjhansen@inav.net  Fri May 10 21:51:01 2002
From: rjhansen@inav.net (Robert J. Hansen)
Date: Fri May 10 20:51:01 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <Pine.LNX.4.30.QNWS.0205101003070.3958-100000@thetis.deor.org>
Message-ID: <Pine.LNX.4.44L0.0205101348180.7060-100000@soli.inav.net>

> The entire point of the IETF, and of the RFC system, is to eliminate the
> "de facto standards" mess, and give us actual standards.

... and to further elaborate my point (which follows from that): a 
standard quickly devolves to near-uselessness if people start extending it 
willy-nilly.  Look at the UNIX Wars, or "This Site Best Viewed In".  A 
standard ought be adhered to unless there are clear and compelling reasons 
not to do so.  I don't see any clear and compelling reason to use 
RIPEMD-160, and so I don't.  (Let me say, though, that it's not my 
intention to speak for anyone but me.)

> You are confusing DSA (the algorithm) with DSS (the standard). DSS

D'oh.  My goof.





From dshaw@jabberwocky.com  Fri May 10 22:19:01 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Fri May 10 21:19:01 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <Pine.LNX.4.44L0.0205101348180.7060-100000@soli.inav.net>
References: <Pine.LNX.4.30.QNWS.0205101003070.3958-100000@thetis.deor.org> <Pine.LNX.4.44L0.0205101348180.7060-100000@soli.inav.net>
Message-ID: <20020510192021.GA14633@akamai.com>

On Fri, May 10, 2002 at 01:52:32PM -0500, Robert J. Hansen wrote:
> > The entire point of the IETF, and of the RFC system, is to eliminate the
> > "de facto standards" mess, and give us actual standards.
> 
> ... and to further elaborate my point (which follows from that): a 
> standard quickly devolves to near-uselessness if people start extending it 
> willy-nilly.  Look at the UNIX Wars, or "This Site Best Viewed In".  A 
> standard ought be adhered to unless there are clear and compelling reasons 
> not to do so.  I don't see any clear and compelling reason to use 
> RIPEMD-160, and so I don't.  (Let me say, though, that it's not my 
> intention to speak for anyone but me.)

Just to be clear here, using RIPEMD-160 is completely and totally
adhering to the OpenPGP standard in every possible way.  There are
certainly minor compatibility reasons not to use it, but it is
definitely part of the standard.  To put this in context, other
completely optional parts of the standard are Blowfish, Twofish, and
every AES above 128 bits.

Using "Joe's Random Hash Algorithm 128" would be willy-nilly. ;)

Werner and I discussed it, and I've added the ability to pick the hash
when making a key signature (--cert-digest-algo) to 1.0.8.  I do hope
people will not use this feature (and the manual explains why it isn't
a good idea), but in the end, it is up to them what hash they use.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From dgc@uchicago.edu  Fri May 10 22:29:02 2002
From: dgc@uchicago.edu (David Champion)
Date: Fri May 10 21:29:02 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <20020510192021.GA14633@akamai.com>
References: <Pine.LNX.4.30.QNWS.0205101003070.3958-100000@thetis.deor.org> <Pine.LNX.4.44L0.0205101348180.7060-100000@soli.inav.net> <20020510192021.GA14633@akamai.com>
Message-ID: <20020510192938.GF9707@dust.uchicago.edu>

* On 2002.05.10, in <20020510192021.GA14633@akamai.com>,
*	"David Shaw" <dshaw@jabberwocky.com> wrote:
> 
> Using "Joe's Random Hash Algorithm 128" would be willy-nilly. ;)

But I've tested it thoroughly, and I'm certain it's quite secure -- our
reference code remains uncracked! The source is even available (for a
nominal licensing fee) to anyone who passes our trust audit. Why are you
repressing us?

--
Joe
Joe's Codes, Ltd.
Call for a quote! +1-900-SAF-CODE


From sandeep_sikka@hotmail.com  Sat May 11 01:12:02 2002
From: sandeep_sikka@hotmail.com (Sandeep Sikka)
Date: Sat May 11 00:12:02 2002
Subject: GPG 1.0.6 bug - sign/encrypt/decrypt 0 bytes.
Message-ID: <F1024t5BD8wbVGkJmiW00014762@hotmail.com>

Hi,

If I sign/encrypt & then decrypt 0 bytes, I get junk. I don't get 0 bytes. 
If I use even one byte, I have no problems. If I just encrypt/decrypt 0 
bytes, I get 0 bytes in return. But if I sign, I have problems. Is this a 
known bug with GPG? Or am I not understanding & using GPG properly?

Thanks!

Sandeep.

----
sikka@debian:~$ gpg --version
gpg (GnuPG) 1.0.6
Copyright (C) 2001 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.
----

sikka@debian:~$ gpg --list-keys
/u3/sikka/.gnupg/pubring.gpg
----------------------------
pub  1024D/85DEA7EC 2002-05-10 Sandeep Sikka (test key) 
<sikka@iamtesting.com>
sub  1024g/64B4BEA2 2002-05-10
----

# Encrypt 0 bytes - NO PROBLEM
sikka@debian:~$ echo -n | gpg -ea -r sikka@iamtesting.com -u 
sikka@iamtesting.com | gpg --decrypt
gpg: NOTE: secret key 85DEA7EC is NOT protected.
gpg: NOTE: secret key 85DEA7EC is NOT protected.
gpg: encrypted with 1024-bit ELG-E key, ID 64B4BEA2, created 2002-05-10
      "Sandeep Sikka (test key) <sikka@iamtesting.com>"
----

# Sign/encrypt one byte - NO PROBLEM
sikka@debian:~$ echo X | gpg -sea -r sikka@iamtesting.com -u 
sikka@iamtesting.com | gpg --decrypt
gpg: NOTE: secret key 85DEA7EC is NOT protected.
gpg: NOTE: secret key 85DEA7EC is NOT protected.
gpg: encrypted with 1024-bit ELG-E key, ID 64B4BEA2, created 2002-05-10
      "Sandeep Sikka (test key) <sikka@iamtesting.com>"
X
gpg: Signature made Fri May 10 18:05:33 2002 EDT using DSA key ID 85DEA7EC
gpg: Good signature from "Sandeep Sikka (test key) <sikka@iamtestng.com>"
----

# Sign/Encrypt 0 bytes - PROBLEM CASE
sikka@debian:~$ echo -n | gpg -sea -r sikka@iamtesting.com -u 
sikka@iamtesting.com | gpg --decrypt
gpg: NOTE: secret key 85DEA7EC is NOT protected.
gpg: NOTE: secret key 85DEA7EC is NOT protected.
gpg: encrypted with 1024-bit ELG-E key, ID 64B4BEA2, created 2002-05-10
      "Sandeep Sikka (test key) <sikka@iamtesting.com>"
?b<ÜDfbùú4RÞNbÄÃ ÁF>/èLErå9æCmÜsâ(×t
----











_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com



From dshaw@jabberwocky.com  Sat May 11 01:26:01 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Sat May 11 00:26:01 2002
Subject: GPG 1.0.6 bug - sign/encrypt/decrypt 0 bytes.
In-Reply-To: <F1024t5BD8wbVGkJmiW00014762@hotmail.com>
References: <F1024t5BD8wbVGkJmiW00014762@hotmail.com>
Message-ID: <20020510222724.GE14633@akamai.com>

On Fri, May 10, 2002 at 05:12:17PM -0500, Sandeep Sikka wrote:
> Hi,
> 
> If I sign/encrypt & then decrypt 0 bytes, I get junk. I don't get 0 bytes. 
> If I use even one byte, I have no problems. If I just encrypt/decrypt 0 
> bytes, I get 0 bytes in return. But if I sign, I have problems. Is this a 
> known bug with GPG? Or am I not understanding & using GPG properly?

This was fixed in GnuPG 1.0.7.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From benfell@greybeard95a.com  Sun May 12 08:07:01 2002
From: benfell@greybeard95a.com (David Benfell)
Date: Sun May 12 07:07:01 2002
Subject: configure produces zero length Makefile
In-Reply-To: <040301c1f050$f71bf8e0$ede3c23f@KR6X.ORG>
References: <040301c1f050$f71bf8e0$ede3c23f@KR6X.ORG>
Message-ID: <20020512050748.GF17531@raven.parts-unknown.org>

--FN+gV9K+162wdwwF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello all,

When I ran configure (with --prefix=3D/usr), I observed the following:

configure: creating ./config.status
config.status: creating Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating intl/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating po/Makefile.in
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating util/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating mpi/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating cipher/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating g10/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating keyserver/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating keyserver/gpgkeys_mailto
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating keyserver/gpgkeys_test
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating doc/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating tools/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating zlib/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating checks/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating config.h
config.status: config.h is unchanged
config.status: linking ./mpi/i386/mpih-add1.S to mpi/mpih-add1.S
config.status: linking ./mpi/i386/mpih-mul1.S to mpi/mpih-mul1.S
config.status: linking ./mpi/i386/mpih-mul2.S to mpi/mpih-mul2.S
config.status: linking ./mpi/i386/mpih-mul3.S to mpi/mpih-mul3.S
config.status: linking ./mpi/i386/mpih-lshift.S to mpi/mpih-lshift.S
config.status: linking ./mpi/i386/mpih-rshift.S to mpi/mpih-rshift.S
config.status: linking ./mpi/i386/mpih-sub1.S to mpi/mpih-sub1.S
config.status: linking ./mpi/generic/mpi-asm-defs.h to
mpi/mpi-asm-defs.h
config.status: creating po/POTFILES
config.status: creating po/Makefile
g10defs.h is unchanged

                Configured for: GNU/Linux (i686-pc-linux-gnu)
    Dynamically linked modules: rndunix rndegd tiger
     Statically linked modules: rndlinux sha1 rmd160 md5

make: *** No targets.  Stop.
root@home:/usr/local/src/gnupg-1.0.7 # ls -al Makefile*
-rw-r--r--    1 root     root            0 May  1 22:51 Makefile
-rw-r--r--    1 1000     1000         1800 Dec 21 11:49 Makefile.am
-rw-rw-r--    1 1000     1000        16187 Apr 29 08:06 Makefile.in

I tried attaching the configure log, but this caused the e-mail to
exceed the 40KB limit for posting.

This is on a SuSE 7.1 system which has been heavily upgraded, mostly
from source.


--=20
David Benfell, LCP
benfell@parts-unknown.org
---
Resume available at http://www.parts-unknown.org/resume.html

--FN+gV9K+162wdwwF
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iQEXAwUBPN34pHw5zqzgtjVOFANyiQP+K4WF/Blma96kAoPpp2UcW+5icMc6r4/L
lxC3csAUn5lCKHvuLMEpQoOUYHvS0fbIPQAc2GLdkwdyihPXsO5pMSF65/QennDY
XvEFZcgQVkpgW7RAqMzV3iLVPJLCkjeQqx3uMwFFqpiZm6LPnp+2Ce2xDmyXWGJk
LqyTRC8k0F8D/AwH0OSKeerkovm3pDc4YrrzZ5pLhQlG6pNp8j3sVZ6Wc3jb/YV9
2sLHb/k+o1uw7wPIp3R8v7OEd0smVgr6qb9r4ZMRdyBV2TbzZs2sXIqbkXHYeN94
D+zWJRcH1ZlSveQt0aCuUxKEEiEbvXLx1z0Hyf2CcZxD9qCyqOUiDBkr
=TMp9
-----END PGP SIGNATURE-----

--FN+gV9K+162wdwwF--


From srm_dfr@hotmail.com  Sun May 12 17:16:02 2002
From: srm_dfr@hotmail.com (eloj %20)
Date: Sun May 12 16:16:02 2002
Subject: encrypting to public key crashes gnupg 1.0.6-2 (win32)
Message-ID: <F125KpO2DTSWFSSEfLM00015e40@hotmail.com>

I was helping a friend set up GnuPG 1.0.6-2 Win32 yesterday. When all was 
set up we discovered that no-one seemed able to encrypt to his key.

The crash is reproducably on several installations.

'The instruction at "0x74fad613" referenced memory at "0x024a5000". The 
memory could not be "written".'

I haven't bothered testing on 1.0.7 since there is no officiall win32-port 
yet.

Anyone willing to take a look at the key and see if they can reproduce the 
problem? A developer with a what-will-become win32 build maybe.

I won't post the key here since the secret key doesn't exist any more and 
there is no revocation should it slip into the wild, but if anyone wants it 
contact me at eddy klopper net.


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.



From redbird@rbisland.cx  Sun May 12 19:58:01 2002
From: redbird@rbisland.cx (Gordon Worley)
Date: Sun May 12 18:58:01 2002
Subject: configure produces zero length Makefile
In-Reply-To: <20020512050748.GF17531@raven.parts-unknown.org>
Message-ID: <3057365C-65C9-11D6-A13F-000A27B4DEFC@rbisland.cx>

On Sunday, May 12, 2002, at 01:07  AM, David Benfell wrote:

> make: *** No targets.  Stop.
> root@home:/usr/local/src/gnupg-1.0.7 # ls -al Makefile*
> -rw-r--r--    1 root     root            0 May  1 22:51 Makefile
> -rw-r--r--    1 1000     1000         1800 Dec 21 11:49 Makefile.am
> -rw-rw-r--    1 1000     1000        16187 Apr 29 08:06 Makefile.in

This looks a lot like what happens on Darwin.  While it's not likely the 
same but, it's worth mentioning that if your sh is really zsh, you need 
to go through the configure script and change all instances of 'CDPATH=' 
to 'unset CDPATH'.

--
Gordon Worley                     `When I use a word,' Humpty Dumpty
http://www.rbisland.cx/            said, `it means just what I choose
redbird@rbisland.cx                it to mean--neither more nor less.'
PGP:  0xBBD3B003                                  --Lewis Carroll



From benfell@greybeard95a.com  Mon May 13 01:25:01 2002
From: benfell@greybeard95a.com (David Benfell)
Date: Mon May 13 00:25:01 2002
Subject: configure produces zero length Makefile
In-Reply-To: <3057365C-65C9-11D6-A13F-000A27B4DEFC@rbisland.cx>
References: <20020512050748.GF17531@raven.parts-unknown.org> <3057365C-65C9-11D6-A13F-000A27B4DEFC@rbisland.cx>
Message-ID: <20020512222543.GA803@raven.parts-unknown.org>

--opJtzjQTFsWo+cga
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, 12 May 2002 12:56:22 -0400, Gordon Worley wrote:
>=20
> On Sunday, May 12, 2002, at 01:07  AM, David Benfell wrote:
>=20
> >make: *** No targets.  Stop.
> >root@home:/usr/local/src/gnupg-1.0.7 # ls -al Makefile*
> >-rw-r--r--    1 root     root            0 May  1 22:51 Makefile
> >-rw-r--r--    1 1000     1000         1800 Dec 21 11:49 Makefile.am
> >-rw-rw-r--    1 1000     1000        16187 Apr 29 08:06 Makefile.in
>=20
> This looks a lot like what happens on Darwin.  While it's not likely the=
=20
> same but, it's worth mentioning that if your sh is really zsh,

Yup, I did that.  I hate bash.  I'd had some problems with
initialization scripts as a result but solved those with simpler,
customized language.

> you need=20
> to go through the configure script and change all instances of 'CDPATH=3D=
'=20
> to 'unset CDPATH'.
>=20
Good catch.  Really good catch.  Thank you.

--=20
David Benfell
benfell@parts-unknown.org
---
There's an old proverb that says just about whatever you want it to.
                                [from fortune]

--opJtzjQTFsWo+cga
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iQEXAwUBPN7r53w5zqzgtjVOFAPNjgP/dX6kgpVCSzo+OcVIYjkSD1GxvhG5XJg2
Z+GaPWdIWrX/tqfYW/OjP8KyIHJXKXY+faIlUcLHiAlfAJYBTMzecJxLJZSxbvAk
wvMOt9tki4EFlmGvrvCNs26j4wOWzmV0nEby7s5DJtWY+QKcx2aLFCrgA/k/0gMz
e9Ilf9o1ApYEAIPfaTCDgeR2Ki0xv/1F0W2V37f95yECF6dQdXSgTy8k2ZdCS+3l
pHJiMEHPlSvdPNTuqwIJ+dtjzj02RUbldjt6tsu7vmRatdX7MfL+WbuE0eSULhpy
GqW8SiVszaQ1AH/Ck3mioZ/Qh53jpMPmek95d+LJnqGSeulImmyBa8S9
=xzIa
-----END PGP SIGNATURE-----

--opJtzjQTFsWo+cga--


From request@logos.net  Mon May 13 07:11:02 2002
From: request@logos.net (request@logos.net)
Date: Mon May 13 06:11:02 2002
Subject: Verba Volant
Message-ID: <E1777dv-00057k-00@porta.u64.de>

13-MAY-02
We have been requested to insert the following email address, "gnupg-devel@gnupg.org", in the Verba Volant Newsletter database. Through this daily service you will receive a quotation, selected from amongst the most celebrated philosophers, writers and poets of all time and translated into many languages and dialects by volunteers worldwide.
If you would like to confirm your subscription to Verba Volant, please click on the following link: 
http://www.logos.net/owa-l/press.subscribe?lang=en&email=gnupg-devel@gnupg.org 
If you do not wish to click on the link, your subscription will be cancelled.
Thank you for your time.
Verba Volant



13-MAY-02
Il nous a été demandé d'ajouter l'adresse électronique "gnupg-devel@gnupg.org" dans la liste des destinataires de Verba Volant, un service qui tous les jours vous adressera une citation sélectionnée parmi les œuvres des meilleurs philosophes, écrivains, poètes de tous les temps et traduite en de très nombreuses langues grâce à des volontaires du monde entier.
Pour confirmer l'inscription à Verba Volant, veuillez vous connecter au lien suivant:
http://www.logos.net/owa-l/press.subscribe?lang=fr&email=gnupg-devel@gnupg.org 
Si vous préférez ne pas cliquer sur le lien, vous ne recevrez rien.

Merci dans tous les cas de nous avoir accordé quelques secondes.
Verba Volant



13-MAY-02
Se nos ha solicitado insertar la dirección de correo electrónico "gnupg-devel@gnupg.org" en el listado de envíos de Verba Volant, un servicio que diariamente le enviará citas elegidas entre los mejores filosofos, escritores, poetas, etc., traducidas a varios idiomas y dialectos. Dichas citas están traducidas por voluntarios que se conectan a nuestra web desde todo el mundo.
Si quiere confirmar la suscripción a Verba Volant, le rogamos entre en: 
http://www.logos.net/owa-l/press.subscribe?lang=es&email=gnupg-devel@gnupg.org 
Si no entra en la dirección señalada no recibirá las citas.
Muchas gracias por el tiempo que nos ha dedicado.
Verba Volant



13-MAY-02
Ci è stato chiesto di inserire l'indirizzo di posta elettronica "gnupg-devel@gnupg.org" nell’elenco dei destinatari di Verba Volant, un servizio che ogni giorno ti invierà una citazione scelta tra quelle dei migliori filosofi, scrittori, poeti di tutti i tempi e tradotta in moltissime lingue e dialetti grazie alla collaborazione di volontari da tutto il mondo.
Se desideri confermare l'iscrizione, ti preghiamo di collegarti al seguente link:
http://www.logos.net/owa-l/press.subscribe?lang=it&email=gnupg-devel@gnupg.org 
Nel caso preferissi non cliccare sul link, non riceverai nulla. 

Grazie comunque per i secondi che ci hai dedicato.
Cordiali saluti.






From wk@gnupg.org  Mon May 13 10:17:07 2002
From: wk@gnupg.org (Werner Koch)
Date: Mon May 13 09:17:07 2002
Subject: [Administriva] MLs closed
Message-ID: <87wuu8tt1s.fsf@alberti.gnupg.de>

Hi!

I am getting annoyed of all the spam so I finally closed the mailing
lists.  From now on only subscribers are allowed to post.  Messages
from non-subscribers are held for approval but the chance that I find
time to actual approve a message is not very high.  Hopefully we don't
get too much spam with faked From addresses.

If someone wants to volunteer as a listmaster please drop me a note.

  Werner



From Fabian.Rodriguez@Toxik.com  Tue May 14 00:24:01 2002
From: Fabian.Rodriguez@Toxik.com (Toxik - Fabian Rodriguez)
Date: Mon May 13 23:24:01 2002
Subject: Verifying signatures via WWW interface
In-Reply-To: <F1024t5BD8wbVGkJmiW00014762@hotmail.com>
Message-ID: <MJEDILLCNFHIFGNJHDMGAELHDNAA.Fabian.Rodriguez@Toxik.com>

Hello,

I'd like to know if it's logical to offer to people to verify signatures of
short texts via a web interface. I'm trying to understand some other
applications of OpenPGP/gnupg.

I thought having public keys of the signers on a local keyring would be
enough but GPG sends these warnings after displaying date and author
information:

  Could not find a valid trust path to the key.  Let's see whether we
  can assign some missing owner trust values.

  No path leading to one of our keys found.

  gpg: WARNING: This key is not certified with a trusted signature!
  gpg:          There is no indication that the signature belongs to the
owner.
  gpg: Fingerprint: A6EF 1DF9 39CC 873C 5855  D7BA 93E0 2B96 73AE 57A0

Of course, we don't want to store a private key for this particular
application, what would be required to have a trust path ? The local keyring
only has public keys in this example.

Thanks for any information on this.

Fabián Rodríguez - Toxik Technologies, Inc.
www.toxik.com · (514) 528-6945 @221
OpenPGP: 0x5AF2A4D5




From dmitri@users.sourceforge.net  Tue May 14 00:41:02 2002
From: dmitri@users.sourceforge.net (Dmitri)
Date: Mon May 13 23:41:02 2002
Subject: Verifying signatures via WWW interface
In-Reply-To: <MJEDILLCNFHIFGNJHDMGAELHDNAA.Fabian.Rodriguez@Toxik.com>
References: <MJEDILLCNFHIFGNJHDMGAELHDNAA.Fabian.Rodriguez@Toxik.com>
Message-ID: <1021326141.10775.387.camel@usb.networkfab.com>

--=-gZHvrlblTtvpVcErg0oN
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Mon, 2002-05-13 at 14:22, Toxik - Fabian Rodriguez wrote:

> I'd like to know if it's logical to offer to people to verify signatures =
of
> short texts via a web interface.

As long as you don't mind sending your plaintext over the network, and
telling anyone who cares to sniff the traffic what messages and who
receives, and from who, and when...

> I thought having public keys of the signers on a local keyring would be
> enough but GPG sends these warnings after displaying date and author
> information:
>=20
>   Could not find a valid trust path to the key.  Let's see whether we
>   can assign some missing owner trust values.
>=20
>   No path leading to one of our keys found.
>=20
>   gpg: WARNING: This key is not certified with a trusted signature!
>   gpg:          There is no indication that the signature belongs to the
> owner.

You need to sign the public key of that other person. It will tell GnuPG
that you believe that the key belongs to that person. You should find
more detailed explanations in many places, such as www.gnupg.org ...

Dmitri


--=-gZHvrlblTtvpVcErg0oN
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA84DM9XksyLpO6T4IRAmonAJ4vxm2ezpDKvIxCoQWIbMHdM/gvvgCeIy/K
Wy9CSIJMcJaEZIWAGLcvOqs=
=geGL
-----END PGP SIGNATURE-----

--=-gZHvrlblTtvpVcErg0oN--



From gnupg-devel@gnupg.org  Tue May 14 01:08:02 2002
From: gnupg-devel@gnupg.org (Matthew Byng-Maddick)
Date: Tue May 14 00:08:02 2002
Subject: Verifying signatures via WWW interface
In-Reply-To: <1021326141.10775.387.camel@usb.networkfab.com>; from dmitri@users.sourceforge.net on Mon, May 13, 2002 at 02:42:21PM -0700
References: <MJEDILLCNFHIFGNJHDMGAELHDNAA.Fabian.Rodriguez@Toxik.com> <1021326141.10775.387.camel@usb.networkfab.com>
Message-ID: <20020513230901.A26054@colon.colondot.net>

On Mon, May 13, 2002 at 02:42:21PM -0700, Dmitri wrote:
> On Mon, 2002-05-13 at 14:22, Toxik - Fabian Rodriguez wrote:
> > I'd like to know if it's logical to offer to people to verify signatures of
> > short texts via a web interface.
> As long as you don't mind sending your plaintext over the network, and
> telling anyone who cares to sniff the traffic what messages and who
> receives, and from who, and when...

This is less of an issue (since we're talking about verifying signatures,
it may well have come in in plaintext) than an ability to trust that the
website is not just telling you that a signature is verified, without
having bothered to do the calculation. Or alternatively telling you it
isn't when it might have done.

It's easier to verify that a binary on your disk hasn't been modified.

MBM

-- 
Matthew Byng-Maddick         <mbm@colondot.net>           http://colondot.net/


From lists@lina.inka.de  Tue May 14 01:24:02 2002
From: lists@lina.inka.de (Bernd Eckenfels)
Date: Tue May 14 00:24:02 2002
Subject: Verifying signatures via WWW interface
In-Reply-To: <MJEDILLCNFHIFGNJHDMGAELHDNAA.Fabian.Rodriguez@Toxik.com>
References: <F1024t5BD8wbVGkJmiW00014762@hotmail.com> <MJEDILLCNFHIFGNJHDMGAELHDNAA.Fabian.Rodriguez@Toxik.com>
Message-ID: <20020513222452.GA30503@lina.inka.de>

On Mon, May 13, 2002 at 05:22:01PM -0400, Toxik - Fabian Rodriguez wrote:
> Of course, we don't want to store a private key for this particular
> application, what would be required to have a trust path ? The local keyring
> only has public keys in this example.

You can eighter ignore the message or lsign all your keys in the keying with
a "trusted" key. you do not need to store the trusted key on the system, you
can mark a public key as trusted. this is used like this:

a) user sends you key, you verify it and sign it
b) you store the signed key on a automatic signature checking device. in
order to avoid to have to store your signature generating key on that device
you just place the public key there and mark it trusted. this has the
advantage (over blindly trusting al keys in keyring) that adding keys to the
keyring is not a priveledged application and does not need a trusted channel
to the verifier.

hope this is clear, i use this for a B2Bi Server which is able to check
incoming messages from trading partners and decides if they are known, based
on a "accept" lsign from operating staff. this even works with a keyserver.

Greetings
Bernd


From aphex@nullify.org  Wed May 15 00:45:07 2002
From: aphex@nullify.org (Keith Ray)
Date: Tue May 14 23:45:07 2002
Subject: GnuPG 1.0.7a+ DIRSEP
Message-ID: <1021412756.3ce185948636c@mail.nullify.org>

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

I have noticed that new DIRSEPs have been committed to the GnuPG 1.07a+
tree.  I would like to include them in a future win32 release, but I am
unsure about whether to change certain paths or not.

Currently, I use the following defaults:

[HKEY_CURRENT_USER\Control Panel\Mingw32\NLS]
"MODir"="C:/GnuPG/Locale"

[HKEY_CURRENT_USER\Software\GNU\GnuPG]
"HomeDir"="C:/GnuPG"

load-extension Lib/idea
load-extension Lib/tiger
load-extension Lib/sha2

Should all of these be changed from '/' to '\' in 1.0.7a+ versions?

  -- Keith

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (MingW32) - GPGshell v2.28

iD8DBQE84YQuBxrjkHkmmhIRAnpmAJ9NWRLU6zqvEVM99nfagGOk31xSTwCdEtoA
bt5GQF46qvVrfBhgVBCQCiI=
=xzfO
-----END PGP SIGNATURE-----


From aphex@nullify.org  Fri May 17 01:50:02 2002
From: aphex@nullify.org (Keith Ray)
Date: Fri May 17 00:50:02 2002
Subject: [BUG FIX] Win32 Performance Counters
Message-ID: <1021589460.3ce437d487922@mail.nullify.org>

In cipher/rndw32.c, GnuPG attempts to gather physical disk performance counter
data for random number generation.  However, if the IOCTL_DISK_PERFORMANCE call
fails for any reason, GPG displays:

"NOTE: you should run 'diskperf -y' to enable the disk statistics"

I created a debug version of GnuPG and called GetLastError() and got:

"The data area passed to a system call is too small."

I did some investigating and found that the Win32 header files from Mingw32/CPD
are incorrect.  Both the LARGE_INTEGER and DISK_PERFORMANCE struct are smaller
than required.  Once these changes were made, I was able to produce a working
GnuPG that successfully called IOCTL_DISK_PERFORMANCE.  However, GCC gave the
following warning:

In file included from
/usr/local/lib/mingw32-cpd/lib/gcc-lib/i386--mingw32/2.95.2wk20010117/../../../../i386--mingw32/include/windows.h:48,
                 from rndw32.c:69:
/usr/local/lib/mingw32-cpd/lib/gcc-lib/i386--mingw32/2.95.2wk20010117/../../../../i386--mingw32/include/Windows32/Structures.h:1080:
warning: unnamed struct/union that defines no instances


mingw32-cpd/i386--mingw32/include/Windows32/Structures.h
--------------------------------------------------------

typedef struct _LARGE_INTEGER {
  DWORD LowPart;
  LONG  HighPart;
} LARGE_INTEGER, *PLARGE_INTEGER;

typedef struct _DISK_PERFORMANCE {
  LARGE_INTEGER BytesRead;
  LARGE_INTEGER BytesWritten;
  LARGE_INTEGER ReadTime;
  LARGE_INTEGER WriteTime;
  DWORD ReadCount;
  DWORD WriteCount;
  DWORD QueueDepth;
} DISK_PERFORMANCE ;


Microsoft Platform SDK\Include\WinIoCtl.h
-----------------------------------------

typedef struct _DISK_PERFORMANCE {
        LARGE_INTEGER BytesRead;
        LARGE_INTEGER BytesWritten;
        LARGE_INTEGER ReadTime;
        LARGE_INTEGER WriteTime;
        LARGE_INTEGER IdleTime;
        DWORD ReadCount;
        DWORD WriteCount;
        DWORD QueueDepth;
        DWORD SplitCount;
        LARGE_INTEGER QueryTime;
        DWORD   StorageDeviceNumber;
        WCHAR   StorageManagerName[8];
} DISK_PERFORMANCE, *PDISK_PERFORMANCE;


Microsoft Platform SDK\Include\WinNT.h
--------------------------------------

typedef union _LARGE_INTEGER {
    struct {
        DWORD LowPart;
        LONG HighPart;
    };
    struct {
        DWORD LowPart;
        LONG HighPart;
    } u;
    LONGLONG QuadPart;
} LARGE_INTEGER;


From keith@nullify.org  Fri May 17 11:33:01 2002
From: keith@nullify.org (Keith Ray)
Date: Fri May 17 10:33:01 2002
Subject: GnuPG 1.0.7a+ DIRSEP
Message-ID: <1021412447.3ce1845f9a7bd@mail.nullify.org>

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

I have noticed that new DIRSEPs have been committed to the GnuPG 1.07a+
tree.  I would like to include them in a future win32 release, but I am
unsure about whether to change certain paths or not.

Currently, I use the following defaults:

[HKEY_CURRENT_USER\Control Panel\Mingw32\NLS]
"MODir"="C:/GnuPG/Locale"

[HKEY_CURRENT_USER\Software\GNU\GnuPG]
"HomeDir"="C:/GnuPG"

load-extension Lib/idea
load-extension Lib/tiger
load-extension Lib/sha2

Should all of these be changed from '/' to '\' in 1.0.7a+ versions?

  -- Keith

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (MingW32) - GPGshell v2.28

iD8DBQE84YQuBxrjkHkmmhIRAnpmAJ9NWRLU6zqvEVM99nfagGOk31xSTwCdEtoA
bt5GQF46qvVrfBhgVBCQCiI=
=xzfO
-----END PGP SIGNATURE-----


From chris@netservers.co.uk  Fri May 17 11:33:04 2002
From: chris@netservers.co.uk (Chris Wilson)
Date: Fri May 17 10:33:04 2002
Subject: Operation on read-only filesystem
Message-ID: <Pine.LNX.4.44.0205151157380.11907-200000@localhost>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

--8323328-471549807-1021460765=:11907
Content-Type: TEXT/PLAIN; charset=US-ASCII

Dear GnuPG developers,

I have been trying to get GnuPG working on a read-only filesystem, and I 
think I have hit the same problem as Patrick Higgins 
(http://lists.gnupg.org/pipermail/gnupg-devel/2000-July/005221.html), that 
the trust database is opened read-write. His suggestion of a --read-only 
option seems like a good one. If I wrote a patch to add this option, would 
anyone care to integrate it with GnuPG?

I have also been maintaining my batch-sign patch, and just updated it to 
GPG 1.0.7. This fixes what I believe to be a bug in GnuPG, that for no 
apparent reason, signing keys is disabled in batch-mode. The patch is very 
simple, and I hope you will consider applying it.

Cheers, Chris.
-- 
   ___ __     _
 / __// / ,__(_)_  | Chris Wilson -- UNIX Firewall Lead Developer |
/ (_ / ,\/ _/ /_ \ | NetServers.co.uk http://www.netservers.co.uk |
\ _//_/_/_//_/___/ | 21 Signet Court, Cambridge, UK. 01223 576516 |

--8323328-471549807-1021460765=:11907
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="gpg-batchsign-1.0.7.patch"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.44.0205151206050.11907@localhost>
Content-Description: 
Content-Disposition: attachment; filename="gpg-batchsign-1.0.7.patch"

ZGlmZiAtcnUyIGdudXBnLTEuMC43L2cxMC9rZXllZGl0LmMgZ251cGctMS4w
LjctY2hyaXMvZzEwL2tleWVkaXQuYw0KLS0tIGdudXBnLTEuMC43L2cxMC9r
ZXllZGl0LmMJTW9uIEFwciAyOSAxNTozNDoyMSAyMDAyDQorKysgZ251cGct
MS4wLjctY2hyaXMvZzEwL2tleWVkaXQuYwlXZWQgTWF5IDE1IDExOjUyOjMz
IDIwMDINCkBAIC04NzEsNCArODcxLDEyIEBADQogICAgIGludCBoYXZlX2Nv
bW1hbmRzID0gISFjb21tYW5kczsNCiANCisgICAgaWYoIHNpZ25fbW9kZSAp
IHsNCisgICAgICAgIGNvbW1hbmRzID0gTlVMTDsNCisgICAgICAgIGFwcGVu
ZF90b19zdHJsaXN0KCAmY29tbWFuZHMsIHNpZ25fbW9kZSA9PSAxPyAic2ln
biI6DQorICAgICAgICAgICAgICAgICAgICAgICAgICAgc2lnbl9tb2RlID09
IDI/ImxzaWduIjoNCisgICAgICAgICAgICAgICAgICAgICAgICAgICBzaWdu
X21vZGUgPT0gMz8ibnJzaWduIjoibnJsc2lnbiIpOw0KKyAgICAgICAgaGF2
ZV9jb21tYW5kcyA9IDE7DQorICAgIH0NCisNCiAgICAgaWYgKCBvcHQuY29t
bWFuZF9mZCAhPSAtMSApDQogICAgICAgICA7DQpAQCAtODc2LDEyICs4ODQs
NCBAQA0KIAlsb2dfZXJyb3IoXygiY2FuJ3QgZG8gdGhhdCBpbiBiYXRjaG1v
ZGVcbiIpKTsNCiAJZ290byBsZWF2ZTsNCi0gICAgfQ0KLQ0KLSAgICBpZigg
c2lnbl9tb2RlICkgew0KLQljb21tYW5kcyA9IE5VTEw7DQotCWFwcGVuZF90
b19zdHJsaXN0KCAmY29tbWFuZHMsIHNpZ25fbW9kZSA9PSAxPyAic2lnbiI6
DQotCQkJICAgc2lnbl9tb2RlID09IDI/ImxzaWduIjoNCi0JCQkgICBzaWdu
X21vZGUgPT0gMz8ibnJzaWduIjoibnJsc2lnbiIpOw0KLQloYXZlX2NvbW1h
bmRzID0gMTsNCiAgICAgfQ0KIA0K
--8323328-471549807-1021460765=:11907--


From andy.ozment@cc.gatech.edu  Fri May 17 11:33:06 2002
From: andy.ozment@cc.gatech.edu (Andy Ozment)
Date: Fri May 17 10:33:06 2002
Subject: Wrong signature on idea.c, broken link
Message-ID: <3CE2BF5E.C58AAD75@cc.gatech.edu>

I'm new to gpg, so I apologize if these "bugs" are really my ignorance
rather than a bug.

1. In an attempt to get the idea module, I went to the page
<http://www.gnupg.org/why-not-idea.html>

I downloaded the files idea.c and idea.c.sig. I then tried to check the
sig:
$ gpg --verify idea.c.sig idea.c
gpg: Warning: using insecure memory!
gpg: please see http://www.gnupg.org/faq.html for more information
gpg: Signature made Fri Aug 17 03:34:05 2001 EDT using DSA key ID
621CC013
gpg: Can't check signature: public key not found

$ gpg --list-keys
pub  1024D/57548DCD 1998-07-07 Werner Koch (gnupg sig) <dd9jn@gnu.org>

It appears to me, then, that idea.c was not signed with the key that
signed the entire distribution (57548DCD, Werner Koch). Is this
intentional? I could not find the key that did sign the file anywhere on
the site.



2. On a completely different note, on the page
<http://www.gnupg.org/docs.html>, the link "list of bugs" which points
to <http://bugs.guug.de/Bugs/db/pa/lgnupg.html> is broken.


Please copy any responses to me, as I am not a member of this list.
Again, if this is not really a mistake and is just me being dumb, then I
apologize for being an annoying newbie!
Thanks!
Andy

-- 
  Andy Ozment
  Research Scientist
  Georgia Tech College of Computing


From avbidder@fortytwo.ch  Fri May 17 18:16:01 2002
From: avbidder@fortytwo.ch (Adrian 'Dagurashibanipal' von Bidder)
Date: Fri May 17 17:16:01 2002
Subject: secure sign & encrypt
Message-ID: <1021648640.7790.33.camel@atlas>

--=-ivbC0F0YEu2PvLP9b4+Z
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Yo!

After having read the paper refernced in the ongoing 'signing &
encrypting' thread on gpg-users

http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html

I feel that these flaws are quite serious, as non-experts (like me)
almost automatically assume end-to-end security if they receive
encrypted mail. I'm not on this list very long, so I didn't get previous
discussions of this (are theare *searchable* archives?)

How about this extension of the openPGP standard:

the signature (openpgp-)packet of a signed & encrypted msg includes an
additional (signed!!!) subpacket of the new type 'intended encryption
key'. when gpg is told to verify a message and finds such a subpacket,
it prints an error message if=20
 - the message is not encrypted
 - the message is encrypted, but not with the intended key.
conventional signed & encrypted msgs produce a warning along the lines
of 'it can not be asserted that this message was encrypted by the
original sender. See <URL> for more information'.

(Of course, more than one 'intended encryption key' subpackets must be
allowed)

Yes, this is not rfc - but I got the impression that the gpg people are
not against extending the standard if there are valid reasons (cf.
picture id)


And while I'm at it (though this is tangential here, I know):

extension to the OpenPGP-MIME RFC 3156: Add the To:, From: and Subject:
headers of the mail to the (signed) MIME headers of multipart/signed
msgs and bug the mailreader people to verify the mail headers with
these.



comments?
-- vbi


--=20
secure email with gpg                 avbidder@fortytwo.ch: key id
0x92082481
                                      avbidder@acter.ch:    key id
0x5E4B731F


--=-ivbC0F0YEu2PvLP9b4+Z
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA85R8Awj49sl5Lcx8RAoCrAJ4gCplIzL9U8Y4AAaQ7frEEQ2jCDwCeIwRY
W/I1c7oXs6zxmSt0mlGzGJw=
=TqKC
-----END PGP SIGNATURE-----

--=-ivbC0F0YEu2PvLP9b4+Z--


From jharris@widomaker.com  Fri May 17 21:10:02 2002
From: jharris@widomaker.com (Jason Harris)
Date: Fri May 17 20:10:02 2002
Subject: Wrong signature on idea.c, broken link
In-Reply-To: <3CE2BF5E.C58AAD75@cc.gatech.edu>
References: <3CE2BF5E.C58AAD75@cc.gatech.edu>
Message-ID: <20020517181046.GA317@p5.widomaker.com>

--FL5UXtIhxfXey3p5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, May 15, 2002 at 04:04:46PM -0400, Andy Ozment wrote:

> I'm new to gpg, so I apologize if these "bugs" are really my ignorance
> rather than a bug.

You've been using (commercial) PGP all this time?  :(

> 1. In an attempt to get the idea module, I went to the page
> <http://www.gnupg.org/why-not-idea.html>
>=20
> I downloaded the files idea.c and idea.c.sig. I then tried to check the
> sig:
> $ gpg --verify idea.c.sig idea.c
> gpg: Warning: using insecure memory!
> gpg: please see http://www.gnupg.org/faq.html for more information
> gpg: Signature made Fri Aug 17 03:34:05 2001 EDT using DSA key ID
> 621CC013
> gpg: Can't check signature: public key not found
>=20
> $ gpg --list-keys
> pub  1024D/57548DCD 1998-07-07 Werner Koch (gnupg sig) <dd9jn@gnu.org>
>=20
> It appears to me, then, that idea.c was not signed with the key that
> signed the entire distribution (57548DCD, Werner Koch). Is this
> intentional? I could not find the key that did sign the file anywhere on
> the site.

Use the keyservers, Luke!

(However, it doesn't look like Werner has cross-signed all his keys...)

pub  1024D/621CC013 1998-07-07 Werner Koch <werner.koch@guug.de>
     Key fingerprint =3D ECAF 7590 EB34 43B5 C7CF  3ACB 6C7E E1B8 621C C013
sig?       FF3EAA0B 1998-07-07  [User id not found]
sig        0C9857A5 1998-07-08  Werner Koch <werner.koch@guug.de>
sig        9265FAFB 2001-11-03  Derek Gaston <dgaston@umr.edu>
sig        513AEFD9 2000-09-25  Hans-Joerg Hoexer <hshoexer@rommel.stw.uni-=
erlangen.de>
sig        82957B66 2000-07-11  Hideki Saito <hideki@allcity.net>
sig        C5E88112 2000-02-22  Ruediger Hahn <ruedi007@topmail.de>
sig        5B0358A2 1999-03-15  Werner Koch <wk@gnupg.org>
sig        B1CC03AA 1999-06-21  Javier Kohen <jkohen@tough.com>
sig        621CC013 1999-11-12  Werner Koch <werner.koch@guug.de>
uid                            Werner Koch <wk@gnupg.org>
sig        5B0358A2 2000-10-01  Werner Koch <wk@gnupg.org>
sig        621CC013 2000-11-21  Werner Koch <werner.koch@guug.de>
uid                            Werner Koch <wk@openit.de>
sig        513AEFD9 2000-09-25  Hans-Joerg Hoexer <hshoexer@rommel.stw.uni-=
erlangen.de>
sig        82957B66 2000-07-11  Hideki Saito <hideki@allcity.net>
sig        621CC013 2000-11-21  Werner Koch <werner.koch@guug.de>
sig        90F89A7D 2001-01-25  Ralf Hildebrandt <ralf.hildebrandt@innomina=
te.com>

--=20
Jason Harris          | NIC:  JH329, PGP:  This _is_ PGP-signed, isn't it?
jharris@widomaker.com | web:  http://jharris.cjb.net/

--FL5UXtIhxfXey3p5
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (FreeBSD)

iD8DBQE85UekSypIl9OdoOMRAlGUAJ9owXz90w6Gyif3eh05r4UKYyW9aACfV631
KtD2tVaXe1WTcNKy1ha40xs=
=0YDU
-----END PGP SIGNATURE-----

--FL5UXtIhxfXey3p5--


From Max V. Zinal" <Zlat0@mail.ru  Mon May 20 20:14:01 2002
From: Max V. Zinal" <Zlat0@mail.ru (Max V. Zinal)
Date: Mon May 20 19:14:01 2002
Subject: A modified version of GnuPG
Message-ID: <16924836432.20020518205413@mail.ru>

------------144917F14ED878C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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

Hello everyone, have a nice time of day.

I've  made  some  changes to GnuPG 1.0.7, so now I have a version
built  under  MS  Windows with MS Visual C++ 6.0 compiler, linked
together  with zlib 1.1.4, and having support for *secure memory*
under  Windows.  I  did  my best to ensure that my changes do not
break any existing code under any ever-used platform.

I  think that this changes can be useful for project maintainers,
so they could include all this stuff into the future release.

I  would  like to know, are the project maintainers interested in
getting  my alterations, and if the answer is 'YES', how should I
send these alterations for them.

To show that my modified GPG works, I sign this message with it.
My public key is attached in a file.

- --
Best regards,
 Max                          mailto:zinal0@gibinsoft.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7a (x86-winnt)

iD8DBQE85ocj4scuxnLoWOARAnu0AJsGqiLj/iq6TOKevDG8vXsdI14aXwCfUdvz
ocu0KiQ5mnUBA5KU3ZI9T60=
=f9Ts
-----END PGP SIGNATURE-----
------------144917F14ED878C
Content-Type: application/octet-stream; name="MaxZinal.gpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="MaxZinal.gpg"

LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tDQpWZXJzaW9uOiBHbnVQRyB2MS4w
LjcgKE1pY3Jvc29mdCBXaW5kb3plKQ0KDQptUUdpQkR6amxJMFJCQURlYUdGRk9reUJLVmhZc0I4
ZklDam1OZnpDTFBRVC8xYjRIZ0hiWnFUZURaWXhSamJRDQpUbmJhVnExa2dFQjFNSmJ0MDB6Kys5
aDNPTEdKOGZteDBKRGpNa1hWRlFQaEliejJXSUY4UHNwS1M4aWY4bmc4DQpPRFR0VDIySmJ3Q1BE
WWxKWmRFdVU5RHdPdllQRm1VMXZNRFZiRGRDd0RCZlo2OExUbWt2eXZsYlN3Q2c2U2FpDQpFMVU1
NEFFRzJGQ1VXQUpjbVQveTlBVUQvMWVtQ3d1eFN5TU8xeno2ZkcxR2p3L3BpbkN3cnhmbjVmS3dX
TFBDDQpMbmRjQ3o3MWxoRDdkQjdwV01CUTNSUFpPeWlLQkV4OFlYZkJXdytQSDJvWTE4Z0ZQY2ti
dVdNTmJzSGdlN0N0DQpScnM4UnFBd1lsRmtQdmpzbTQzdElSV1BvTE44eWF1UmdSY1grYWpOVC84
ZzdXRU9WcnhJcGp2b0tTMUt1bzlrDQpOYjE1QS85Y1dXYTM5RDFoc3hjc1VRVENpZUdNNnJyMkpB
MDJBTk1aVC94MVZDeTdoN3VpenJEVDBRWkdrb2VFDQpHYkRUd3pGNU9Kd3A0UzZlOEhKWFRFSmJ0
UnBTQW1kQXI1RisyRUo2R1JMYi9BRmVBQi9sbnRVQWxCdGI3UjA5DQpEZ0Qrek9MM01rQW12eEdt
WWZtZ0ZKdm9wbE83VUVRbVVySzNTZ29CcHAvNmJvOXZaN1FpVFdGNElGWXVJRnBwDQpibUZzSUR4
NmFXNWhiRUJuYVdKcGJuTnZablF1Ym1WMFBvaFpCQk1SQWdBWkJRSTg0NVNOQkFzSEF3SURGUUlE
DQpBeFlDQVFJZUFRSVhnQUFLQ1JEaXh5N0djdWhZNEN4WkFKd0x3bjhuUzNiWUIyN1BQTWtoY3lE
OVF1WVRtQUNnDQpnTE9TcUxXblhoK2U4NTJtTmxOaXd5SFQ2RmE1QVkwRVBPT1ZtQkFHQU1FTm82
T1RYTVhKVDlic1NKNld4bjJkDQo2dHZrNXl6R25wUWMrOFc0MDhtMkg0QjRZcUhMVlY4ZVhoSDF1
UVBReFVpUnJnc3ZxZzhzZ0Ryd0owQjBlZGVXDQoyVmE0MDdMWXR2Q1JnWDlHVHpua24wUWl5VEYr
RlQvbU9iMkExV2JHQWN1MmF3dk9IaXFXWkJIN3gxMTFXbStNDQpLSldNbS9jU1FRNTl3MFJTWUJ4
TzFEb3Z6NzZBQVpYcW1jUjJxODZMQktQb2U1dFFDVmEyUHV3aXE1ZUlVVFlDDQoyV2E4cWVRT1p1
QXNRZUNZaUlNTENrWUMvNEt6d0dtYnNtN2ZrYVlteHdBREJRWUFoM1ArdWkrdnpVSXRDenFpDQpt
WDkyVkIrNUdlazdhY2UyMmRNYTF4cWswRVF3YVQzZlhOYVB3Y3BXTlQwbGN1dTNrTVowMVVXek1C
WFZUUUcxDQpOblFMdERWaGc2RUVmMDZJN3VHU09tR3ZvNjg2UTk1SmsycFlYTVVPSG1Eb1lubnY0
TnpQSkVLaHlLT2liK3lsDQpZMWpHeUZrKzFNN1VVL0x5K3VLbHB6bGgxbFJXV0pwdDhMRTluNXhi
Sml2aWk1Yk5XQW90RVJCbVVYaTRqUWZRDQpqWlB3aFRld01Ic24yMlBMUmRDM3ZJTXc5dHhNSzR0
V0c4ZHBSekszK1hkRFZKYVJpRVlFR0JFQ0FBWUZBanpqDQpsWmdBQ2drUTRzY3V4bkxvV09DS01n
Q1pBVGFoWTRLTXV4dEkrZlZKYk9RNllsYXFOcmdBb0tLaVdQRGxQN1N1DQpZb0E1QWZvQzlqbncx
R0xsDQo9dHh0cA0KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxPQ0stLS0tLQ0K

------------144917F14ED878C--



From 21442@gmx.net  Mon May 20 20:14:04 2002
From: 21442@gmx.net (Jure)
Date: Mon May 20 19:14:04 2002
Subject: Symmetric encription in batch mode
Message-ID: <3CE6C692.F61D9523@gmx.net>

> On Thu Jan 03 2002; 22:00, Bernard wrote:
> 
> IMO, you can send the data with the passphrase at the begin like this:
> "stupid_passphrase\n"
> "raw/text data"
> 
> I used this style in early code of WinPT and it seems to work. It's
> only important that you add a '\n' to the end because gpg expected
> one line for the passphrase.
> 
> 
> There is another way you can choose for sending the passphrase down
> to gpg. With the --command-fd switch you can control all gpg input.
> In the case gpg needs a passphrase the --status-fd output is:
> [GNUPG:] GET_HIDDEN passphrase.enter
> and then you can send the data with the pipe. I know this way is
> more complicated because you need two additional pipes (status,
> command) but it's the tidiest way.

I came across exactly the same problem: how to pass the passphrase to
gnupg when doing symmetric encryption/decryption from a Java program. In
my program, I am trying to do something like this:

encrypt(InputStream plainText, OutputStream cipherText, String password);

(For example, suppose that a stream coming from one network connection has
to be encrypted and send to other network connection). To accomplish this,
I would like gpg.exe to read plainText from stdin and write output to
stdout. Using --passphrase-fd to specify passphrase presents two problems:

1. how to separate passphrase from data (prepending passphrase + '\n' is a
rather inelegant and possibly dangerous approach)

2. it simply doesn't work - although my program pipes the entire stream
(passphrase + '\n' + data) to gpg's input and receives something which
appears to be the gpg's header - that's where gpg hangs. I suppose this is
an issue of file descriptors (either due to a problem in OS, Java process
implementation, or a gpg's way of handling descriptors).

Realizing security issues, I am nevertheless convinced that the ease of
GnuPG reading the passphrase from an environment variable would greatly
outweight many problems that users (including me) who would like to embed
GnuPG in their own solutions, are confronted with, and are now forced to
invent problematic workarounds like the use of batch files.

So, how about supporting an environment variable (e.g. GPG_PASSPHRASE),
just like PGP does? Of course, a warning should be included wherever it
appears throughout documentation.

Forgive me if this has already been discussed - I did not find any trace
of it.

Jure


From emil@la.mine.nu  Mon May 20 20:14:06 2002
From: emil@la.mine.nu (Emil)
Date: Mon May 20 19:14:06 2002
Subject: --no-tty
Message-ID: <20020519095449.GA19764@localhost>

# gpg --version
gpg (GnuPG) 1.0.7

# gpg --no-tty --batch --cipher-algo IDEA -r emil -r emil -ea play.lst
gpg: emil: skipped: public key already present
gpg: this cipher algorithm is deprecated; please use a more standard one!

Isn't --no-tty supposed to mean _NO_ tty whatsoever ?

-- 
								Regards,
								Emil
--
"To be or not to be"	  -Shakespeare
"To do is to be"	  -Socrates
"To be is to do"	  -Sartre
"To be do be do"	  -Sinatra


From kokhong@post1.com  Mon May 20 20:14:07 2002
From: kokhong@post1.com (Soh Kok Hong)
Date: Mon May 20 19:14:07 2002
Subject: GnuPG for Win32
Message-ID: <3CE879E5.4060200@post1.com>

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

Dear all,

I have a 68-line diff file to patch the stock gnupg-1.0.7.tar.gz to
build a mingw32 executable in the standard cygwin environment.  It
mainly patches the configure scripts and one source file (rndw32.c).  I
would like to know if the gnupg maintainers are interested and to whom
can I email the patch to?

Please email to me directly as I am not on the list.


- --
*************************************************
Soh Kok Hong

kokhong@post1.com PGP Signature:
D18B FC65 2202 3E43 A2D3 90D2 7BCC ABD3 77CE CD1C
*************************************************
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE86Hnle8yr03fOzRwRAn8EAKDHTgi8snN8aBTtUGMzb1N92/h78gCg/esk
EWCm1xQ2nO7Nd3VsJ+HRn90=
=c2w+
-----END PGP SIGNATURE-----



From pgut001@cs.auckland.ac.nz  Tue May 21 07:21:01 2002
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
Date: Tue May 21 06:21:01 2002
Subject: A modified version of GnuPG
Message-ID: <200205210421.QAA220469@ruru.cs.auckland.ac.nz>

"Max V. Zinal" <Zlat0@mail.ru> writes:

>I've made some changes to GnuPG 1.0.7, so now I have a version built under MS
>Windows with MS Visual C++ 6.0 compiler, linked together with zlib 1.1.4, and
>having support for *secure memory* under Windows.

Could you explain what you mean by "secure memory"?  There are a variety of
interpretations possible, some erroneous (in general the term "secure memory"
is an oxymoron in an OS which has functions like VirtualProtect() and
ReadProcessMemory(), so a bit more detail would be useful).

Peter.


From wk@gnupg.org  Tue May 21 10:16:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Tue May 21 09:16:01 2002
Subject: --no-tty
In-Reply-To: <20020519095449.GA19764@localhost> (Emil's message of "Sun, 19
 May 2002 05:54:49 -0400")
References: <20020519095449.GA19764@localhost>
Message-ID: <87u1p2rmrh.fsf@alberti.gnupg.de>

On Sun, 19 May 2002 05:54:49 -0400, Emil  said:

> Isn't --no-tty supposed to mean _NO_ tty whatsoever ?

No, it does only make sure never to write to the tty directly (i.e. it
does not open /dev/tty).  The tty may be required to ask for a
passphrase even when stderr has been redirected.  Avoiding all
informational output is done by redirecting stderr to /dev/zero

  Werner



From wk@gnupg.org  Tue May 21 10:22:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Tue May 21 09:22:01 2002
Subject: GnuPG for Win32
In-Reply-To: <3CE879E5.4060200@post1.com> (Soh Kok Hong's message of "Mon,
 20 May 2002 12:21:57 +0800")
References: <3CE879E5.4060200@post1.com>
Message-ID: <87offarmid.fsf@alberti.gnupg.de>

On Mon, 20 May 2002 12:21:57 +0800, Soh Kok Hong said:

> I have a 68-line diff file to patch the stock gnupg-1.0.7.tar.gz to
> build a mingw32 executable in the standard cygwin environment.  It

Thanks but it does not make sense to use this because GnuPG builds
fine as a native Windows program.  The Cygwin32 version may lead not
serious interoperabilty problems when used by other programs expecting
a plain Windows binary.

Yes, I know there is some stuff in GnuPG to allow building under
Cygwin but this already makes the code more complex and error prone,
so it is not really maintained anymore.

  Werner



From dbely@mail.ru  Tue May 21 10:54:01 2002
From: dbely@mail.ru (Dmitry Bely)
Date: Tue May 21 09:54:01 2002
Subject: GnuPG for Win32
In-Reply-To: <87offarmid.fsf@alberti.gnupg.de> (Werner Koch's message of
 "Tue, 21 May 2002 09:24:58 +0200")
References: <3CE879E5.4060200@post1.com> <87offarmid.fsf@alberti.gnupg.de>
Message-ID: <ptzqaqit.fsf@mail.ru>

Werner Koch <wk@gnupg.org> writes:

>> I have a 68-line diff file to patch the stock gnupg-1.0.7.tar.gz to
>> build a mingw32 executable in the standard cygwin environment.  It
>
> Thanks but it does not make sense to use this because GnuPG builds
> fine as a native Windows program.  The Cygwin32 version may lead not
> serious interoperabilty problems when used by other programs expecting
> a plain Windows binary.

Where have you seen a Cygwin32 version? He was talking about the patches
that would let building Mingw32 version with the native Win32 tools
(Mingw32 compiler is included into Cygwin distribution). The fact that
Mingw version of GnuPG cannot be build under Windows out-of-the-box (and so
Windows users cannot participate in its debugging/development) looks
strange to me if not to say more...

Hope to hear from you soon,
Dmitry




From avbidder@fortytwo.ch  Tue May 21 11:24:02 2002
From: avbidder@fortytwo.ch (Adrian 'Dagurashibanipal' von Bidder)
Date: Tue May 21 10:24:02 2002
Subject: secure sign & encrypt
In-Reply-To: <200205171138.51248.rjhansen@inav.net>
References: <1021648640.7790.33.camel@atlas>
 <200205171138.51248.rjhansen@inav.net>
Message-ID: <1021969508.14022.39.camel@atlas>

--=-qlPInynfxfswG9+89RgT
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Fri, 2002-05-17 at 18:38, Robert J. Hansen wrote:

> Davis' `exploit' (in 1.1) basically boils down to this: if you can't trus=
t=20
> the person you're talking to, then the person you're talking to can use=20
> your words in ways you don't like.  Is that a problem?  Sure.  But it's a=
=20
> social problem, not a technological one.  It demands social solutions, no=
t=20
> different cryptographic standards.

Agreed that the exploit is not really technological. The programs do
exactly as told. From the senders point of view I agree fully to what
you say. BUT if somebody receives an encrypted message he will almost
always automatically assume secure end to end communication - which may
not be the case. The open question is basically if the user should be
educated that the software does not work the way they think (hard, I
think), or if the software should be modified to match the users
(reasonable, imho) expectations.

--=20
secure email with gpg                 avbidder@fortytwo.ch: key id
0x92082481
                                      avbidder@acter.ch:    key id
0x5E4B731F


--=-qlPInynfxfswG9+89RgT
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA86gRkwj49sl5Lcx8RApkTAJwKz0M8/q3Mdmdq0ngygNQG9lufTACgkISh
l9dTJC2VTYbGUjjoc4NXVWE=
=oE4v
-----END PGP SIGNATURE-----

--=-qlPInynfxfswG9+89RgT--



From m-lesser@better-com.de  Tue May 21 16:59:02 2002
From: m-lesser@better-com.de (Martin Lesser)
Date: Tue May 21 15:59:02 2002
Subject: Error or feature in g10.c?
Message-ID: <87ptzpsisz.fsf@nb-acer.better-com.de>

After updating from 1.0.6 to 1.0.7 we ran into problems with an app
which uses --run-as-shm-coprocess (gabber, see also
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=146740 )

I know that use of shm-routines in gnupg is deprecated and should be
replaced with --command-fd.

Since rev. 1.129.2.82 of g10.c there's an
  #undef USE_SHM_COPROCESSING
which in the current version is additionally commented with "huh ?"

What's the reason for inserting this #undef (especially at this point)?
In the archives I could not find any hint.

Commenting out this line solved the problem with gabber but I'm not sure
wether this is correct. IMO it is possible that other apps also make use
of the shm-routines. If so they could run into problems too.

Martin


From wk@gnupg.org  Tue May 21 19:50:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Tue May 21 18:50:01 2002
Subject: Error or feature in g10.c?
In-Reply-To: <87ptzpsisz.fsf@nb-acer.better-com.de> (Martin Lesser's message
 of "21 May 2002 15:59:40 +0200")
References: <87ptzpsisz.fsf@nb-acer.better-com.de>
Message-ID: <87d6vpqw67.fsf@alberti.gnupg.de>

On 21 May 2002 15:59:40 +0200, Martin Lesser said:

> What's the reason for inserting this #undef (especially at this point)?
> In the archives I could not find any hint.

Fixed:

  * g10.c (main): Removed the undef of USE_SHM_COPROCESSING which
  was erroneously introduced on 2002-01-09.

> Commenting out this line solved the problem with gabber but I'm not sure
> wether this is correct. IMO it is possible that other apps also make use

It is.

Thanks,

  Werner



From Max V. Zinal" <Zlat0@mail.ru  Tue May 21 20:40:01 2002
From: Max V. Zinal" <Zlat0@mail.ru (Max V. Zinal)
Date: Tue May 21 19:40:01 2002
Subject: Re[2]: A modified version of GnuPG
In-Reply-To: <200205210421.QAA220469@ruru.cs.auckland.ac.nz>
References: <200205210421.QAA220469@ruru.cs.auckland.ac.nz>
Message-ID: <1387186383.20020521213928@mail.ru>

Tuesday, May 21, 2002, 8:21:18 AM, Peter Gutmann wrote:

PG> Could you explain what you mean by "secure memory"?  There are a variety of
PG> interpretations possible, some erroneous (in general the term "secure memory"
PG> is an oxymoron in an OS which has functions like VirtualProtect() and
PG> ReadProcessMemory(), so a bit more detail would be useful).

When I said "secure memory" I was going to say "VirtualLock under
Windows  NT/2000/XP",  which keeps you absolutely safe unless you
have  a  Terminal  Server  with  an  evil-minded admin, or remote
desktop    connection    with    'Debug' privileges.

As  you  know,  most  of  old  and modern OSes have no protection
against  a  person that has administrative rights. Linux, Windows
or  something  else  -  'a  good admin means a long life'. Any OS
which  allows a programmer to use debug facility may be unsecure.
Of  course,  if  we  are  talking about Win9x/ME (which should be
called  'Mustdie  Edition',  I  think), even with VirtualLock you
cannot be absolutely shure.

I have e-mailed my modifications to
        Timo Schulz <twoaday@freakmail.de>
who said he would like to receive them.

Sorry for unexcellent English.

-- 
Best regards,
 Max V. Zinal



From wk@gnupg.org  Wed May 22 10:04:02 2002
From: wk@gnupg.org (Werner Koch)
Date: Wed May 22 09:04:02 2002
Subject: A modified version of GnuPG
In-Reply-To: <1387186383.20020521213928@mail.ru> ("Max V. Zinal"'s message
 of "Tue, 21 May 2002 21:39:28 +0400")
References: <200205210421.QAA220469@ruru.cs.auckland.ac.nz>
 <1387186383.20020521213928@mail.ru>
Message-ID: <878z6cpso2.fsf@alberti.gnupg.de>

On Tue, 21 May 2002 21:39:28 +0400, Max V Zinal said:

> When I said "secure memory" I was going to say "VirtualLock under
> Windows  NT/2000/XP",  which keeps you absolutely safe unless you

I guess you didn't read Peter's papers on this.  VirtualLock is not
suitable for this.  The only way to protect memory from swapping is by
allocating it with the device helper functions:  An ISR may need
memory buffers and these buffers should never be subject to any paging
- the pager may need the service of that ISR - this is the reason why
you are able to allocate non-pageable memory for a device driver.

When GnuPG talks about "secure memory" it actually means "non-pageable
memory".  There can't be any protection against an almighty
admin/root/superuser.

  Werner



From avbidder@fortytwo.ch  Wed May 22 10:50:02 2002
From: avbidder@fortytwo.ch (Adrian 'Dagurashibanipal' von Bidder)
Date: Wed May 22 09:50:02 2002
Subject: secure sign & encrypt
In-Reply-To: <200205211132.09336.rjhansen@inav.net>
References: <1021648640.7790.33.camel@atlas>
 <200205171138.51248.rjhansen@inav.net> <1021969508.14022.39.camel@atlas>
 <200205211132.09336.rjhansen@inav.net>
Message-ID: <1022053889.12048.32.camel@atlas>

--=-Z8G8Y2477TfMVHktYfb7
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Tue, 2002-05-21 at 18:32, Robert J. Hansen wrote:
> > not be the case. The open question is basically if the user should be
> > educated that the software does not work the way they think (hard, I
> > think), or if the software should be modified to match the users
> > (reasonable, imho) expectations.
>=20
> "To every sociological problem there exists a technological solution whic=
h=20
> is cheap, easy, and wrong."
>=20

Why do locks exist, then? The existence of thieves is a purely
sociological problem, after all, and so one should not try to solve it
with technological means.

I agree it'd be breaking (I'd call it extending, but call it what you
want). But I argue that it's just automating a task the user presently
has to do manually.

Currently, to get secure, authenticated end-to-end encryption with gpg,
the sender has to sign/encrypt/sign, which presently requires at least 2
gpg invocations, and the recipient has to manually verify that the inner
and the outer signature match.=20

What I propose does basically just automate this task. It might do so by
literally sign/encrypt/sign, or by encrypt/sign[intended ecryption
keys|msg] (cf my proposal) - it's not the issue which of the two is
happening, though I believe the latter to be more elegant.=20

And I want to stress again that having an end-to-end encrypted channel
is imho a fairly basic requirement of a cryptosystem and is what the
average user is probably expecting to have if he is at the receiving end
of an encrypted channel.

cheers
-- vbi

--=20
secure email with gpg                 avbidder@fortytwo.ch: key id
0x92082481
                                      avbidder@acter.ch:    key id
0x5E4B731F


--=-Z8G8Y2477TfMVHktYfb7
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA8604Bwj49sl5Lcx8RAtmNAJ0fYD5r7s1hlNj5Ve5QMuQHDrCpxgCfetUz
px4yEN6v/VMxgFItAF31nrU=
=q7bS
-----END PGP SIGNATURE-----

--=-Z8G8Y2477TfMVHktYfb7--



From roconnor@Math.Berkeley.EDU  Wed May 22 11:03:01 2002
From: roconnor@Math.Berkeley.EDU (Russell O'Connor)
Date: Wed May 22 10:03:01 2002
Subject: strncasecmp
Message-ID: <Pine.SOL.4.33.0205220100420.17494-100000@blue3.math.berkeley.edu>

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

I was building Gnupg 1.0.7 for OS/2 and I had to manually add strncasecmp
to util/strutil.c

This probably should be added to the source files, along with the
appropriate changes to configure.

- -- 
Russell O'Connor                           roconnor@math.berkeley.edu
           <http://www.math.berkeley.edu/~roconnor/>
``Later generations will regard set theory as a disease from which one
has recovered.'' -- Poincare
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (SunOS)
Comment: For info see http://www.gnupg.org

iD8DBQE861EKuZUa0PWVyWQRAlAwAJ9o5ilHoWGp6xdYXnEZy3CqRRPMpQCfREAn
HWL5wUGr+X+QK4zSe1lucts=
=UqVR
-----END PGP SIGNATURE-----



From apm35@student.open.ac.uk  Wed May 22 11:32:01 2002
From: apm35@student.open.ac.uk (Andrew Marlow)
Date: Wed May 22 10:32:01 2002
Subject: strncasecmp
In-Reply-To: <Pine.SOL.4.33.0205220100420.17494-100000@blue3.math.berkeley.edu>
References: <Pine.SOL.4.33.0205220100420.17494-100000@blue3.math.berkeley.edu>
Message-ID: <fc.004c540101aa85a33b9aca0013090653.1aa85d3@oufcnt2.open.ac.uk>

roconnor@math.berkeley.edu writes:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>I was building Gnupg 1.0.7 for OS/2 and I had to manually add strncasecmp
>to util/strutil.c
>
>This probably should be added to the source files, along with the
>appropriate changes to configure.

I disagree.
Some environments have strncasecmp and others don't. I usually define my
own version of strncasecmp and the implementation differs from environment
to environment. Where I can implement it in terms of strncasecmp I do so,
otherwise I hand-code it. No direct calls to strncasecmp appear in the
code since it is a portability issue.

Regards,

Andrew M.



From sbellon@sbellon.de  Wed May 22 11:33:01 2002
From: sbellon@sbellon.de (Stefan Bellon)
Date: Wed May 22 10:33:01 2002
Subject: strncasecmp
In-Reply-To: <Pine.SOL.4.33.0205220100420.17494-100000@blue3.math.berkeley.edu>
References: <Pine.SOL.4.33.0205220100420.17494-100000@blue3.math.berkeley.edu>
Message-ID: <4b3a87c92bsbellon@sbellon.de>

Russell O'Connor wrote:
> I was building Gnupg 1.0.7 for OS/2 and I had to manually add
> strncasecmp to util/strutil.c

I think I fixed that two days after the 1.0.7 release:

2002-05-10  Stefan Bellon  <sbellon@sbellon.de>

        * g10.c, hkp.c, keyedit.c, keyserver.c: Replaced all occurrances
        of strcasecmp with ascii_strcasecmp and all occurrances of
        strncasecmp with ascii_memcasecmp.

So, neither strcasecmp nor strncasecmp is necessary anymore. Perhaps
you could try with a CVS build again?

Greetings,

Stefan.

-- 
 Stefan Bellon * <mailto:sbellon@sbellon.de> * <http://www.sbellon.de/>
 PGP 2 and OpenPGP keys available from my home page

 We have commited to quickly disseminate high-quality leadership skills
 and collaboratively restore low-risk high-yield meta-services to meet
 our customers needs.


From wk@gnupg.org  Wed May 22 11:36:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Wed May 22 10:36:01 2002
Subject: strncasecmp
In-Reply-To: <Pine.SOL.4.33.0205220100420.17494-100000@blue3.math.berkeley.edu> ("Russell
 O'Connor"'s message of "Wed, 22 May 2002 01:04:22 -0700 (PDT)")
References: <Pine.SOL.4.33.0205220100420.17494-100000@blue3.math.berkeley.edu>
Message-ID: <87znyso9to.fsf@alberti.gnupg.de>

On Wed, 22 May 2002 01:04:22 -0700 (PDT), Russell O'Connor said:

> I was building Gnupg 1.0.7 for OS/2 and I had to manually add strncasecmp
> to util/strutil.c

How did you implement the random number generator?




From wk@gnupg.org  Wed May 22 12:20:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Wed May 22 11:20:01 2002
Subject: strncasecmp
In-Reply-To: <4b3a87c92bsbellon@sbellon.de> (Stefan Bellon's message of
 "Wed, 22 May 2002 10:34:05 +0200")
References: <Pine.SOL.4.33.0205220100420.17494-100000@blue3.math.berkeley.edu>
 <4b3a87c92bsbellon@sbellon.de>
Message-ID: <87n0uso7ug.fsf@alberti.gnupg.de>

On Wed, 22 May 2002 10:34:05 +0200, Stefan Bellon said:

> So, neither strcasecmp nor strncasecmp is necessary anymore. Perhaps
> you could try with a CVS build again?

Well, a check and a replacement for strncasecmp is needed if we use it
and there are some place where strcasecmp should be used instead of
the ascii versions: Those where you actually compare against localized
strings.  I found some places where it was rightfully used but hidden
by stricmp which is just a macro to strcasecmp.  I fixed all of them
and added a strncasecmp repalcement function.

  Werner



From wk@gnupg.org  Wed May 22 12:20:03 2002
From: wk@gnupg.org (Werner Koch)
Date: Wed May 22 11:20:03 2002
Subject: strncasecmp
In-Reply-To: <fc.004c540101aa85a33b9aca0013090653.1aa85d3@oufcnt2.open.ac.uk> (Andrew
 Marlow's message of "Wed, 22 May 2002 09:33:01 +0100")
References: <Pine.SOL.4.33.0205220100420.17494-100000@blue3.math.berkeley.edu>
 <fc.004c540101aa85a33b9aca0013090653.1aa85d3@oufcnt2.open.ac.uk>
Message-ID: <87it5go7sv.fsf@alberti.gnupg.de>

On Wed, 22 May 2002 09:33:01 +0100, Andrew Marlow said:

> Some environments have strncasecmp and others don't. I usually define my
> own version of strncasecmp and the implementation differs from environment

And that is why you should have autoconf test for it and provide a
replacement.  I added the missing tests.
 
  Werner



From rjhansen@inav.net  Wed May 22 16:31:01 2002
From: rjhansen@inav.net (Robert J. Hansen)
Date: Wed May 22 15:31:01 2002
Subject: secure sign & encrypt
In-Reply-To: <1022053889.12048.32.camel@atlas>
References: <1021648640.7790.33.camel@atlas>
 <200205171138.51248.rjhansen@inav.net> <1021969508.14022.39.camel@atlas>
 <200205211132.09336.rjhansen@inav.net>  <1022053889.12048.32.camel@atlas>
Message-ID: <1022074192.9093.11.camel@numbers>

> Why do locks exist, then? The existence of thieves is a purely

Mostly to make homeowners feel safe.  Locks don't exist to keep burglars
out.  My parents lock their front door religiously every single night,
and have a cognitive dissonance in place regarding the large bay window
by the front door.  When I go home to visit, I sometimes like to make a
demonstration of just how silly the front door's lock is by picking
it--lockpicking isn't a hard skill to pick up, incidentally; it just
requires a little devotion.  The reaction I get from Mom and Dad is
always the same: "I wish you wouldn't do that."  Not, "Oh, dear, that
lock's insecure, we need to change it."  My parents are very typical
people in this regard.

You're right; burglary is a sociological problem, and one shouldn't try
to solve it with technological means.  Aggressive law-enforcement, which
is a sociological measure, has a much better track record than locks,
which are purely technological ones.

> I agree it'd be breaking (I'd call it extending, but call it what you
> want). But I argue that it's just automating a task the user presently
> has to do manually.

It's breaking a standard for no effective increase in security.  If the
person you're communicating with is untrustworthy, they can still do all
sorts of things to you which are a thousand times worse than this
(fairly trivial) attack you're worried about.

> Currently, to get secure, authenticated end-to-end encryption with gpg,
> the sender has to sign/encrypt/sign, which presently requires at least 2
> gpg invocations, and the recipient has to manually verify that the inner
> and the outer signature match. 

No: only for people whose threat models include a paranoiac distrust of
their recipients have to worry about this.  My threat model doesn't
incorporate that, and thus, I can get (just to be buzzword-compliant)
"secure, authenticated end-to-end encryption with GPG" just by signing
and encrypting.

Many other people share my threat model, and changing GPG's behavior
would mean GPG would no longer well-represent our threat model.  

> What I propose does basically just automate this task. It might do so by

... and breaks RFC.





From avbidder@fortytwo.ch  Wed May 22 18:44:02 2002
From: avbidder@fortytwo.ch (Adrian 'Dagurashibanipal' von Bidder)
Date: Wed May 22 17:44:02 2002
Subject: secure sign & encrypt
In-Reply-To: <1022074192.9093.11.camel@numbers>
References: <1021648640.7790.33.camel@atlas>
 <200205171138.51248.rjhansen@inav.net> <1021969508.14022.39.camel@atlas>
 <200205211132.09336.rjhansen@inav.net>  <1022053889.12048.32.camel@atlas>
 <1022074192.9093.11.camel@numbers>
Message-ID: <1022082280.17135.125.camel@atlas>

--=-sHn1TXuvzo0FFuYUJyVo
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2002-05-22 at 15:29, Robert J. Hansen wrote:
> > Why do locks exist, then? The existence of thieves is a purely

> > Currently, to get secure, authenticated end-to-end encryption with gpg,
> > the sender has to sign/encrypt/sign, which presently requires at least =
2
> > gpg invocations, and the recipient has to manually verify that the inne=
r
> > and the outer signature match.=20
>=20
> No: only for people whose threat models include a paranoiac distrust of
> their recipients have to worry about this.  My threat model doesn't
> incorporate that, and thus, I can get (just to be buzzword-compliant)
> "secure, authenticated end-to-end encryption with GPG" just by signing
> and encrypting.

signing and encrypting is a secure end-to-end channel from the *senders*
point of view. the problem is that for a potential *recipient* of an
encrypted & signed msg it is impossible to know much about the potential
prior recipient of the message (the one that encrypted and forwarded
it).

In other words, your threat model says that you do not only trust the
sender (signer) of a message, but you trust all people who may get
signed messages from that sender. (Or, alternatively, you as the
receiver of a confidential message do not care to know if it really was
sent encrypted or not.)

cheers
-- vbi


--=20
secure email with gpg            avbidder@fortytwo.ch: key id 0x92082481
                                 avbidder@acter.ch:    key id 0x5E4B731F


--=-sHn1TXuvzo0FFuYUJyVo
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA867zowj49sl5Lcx8RAjSNAJsFMg98jQeZWlG9Fo+/rs4dmB2IBwCdGMaZ
fX7WLJlFukV4EQ+X8n0zWmA=
=Qtjy
-----END PGP SIGNATURE-----

--=-sHn1TXuvzo0FFuYUJyVo--



From rjhansen@inav.net  Wed May 22 19:54:01 2002
From: rjhansen@inav.net (Robert J. Hansen)
Date: Wed May 22 18:54:01 2002
Subject: secure sign & encrypt
In-Reply-To: <1022082280.17135.125.camel@atlas>
Message-ID: <Pine.LNX.4.44L0.0205221140200.31437-100000@soli.inav.net>

> In other words, your threat model says that you do not only trust the
> sender (signer) of a message, but you trust all people who may get
> signed messages from that sender. (Or, alternatively, you as the

<testy>
No.  Please don't make assumptions about my threat model, especially ones 
which are subtly and seriously wrong.
</testy>

The `exploit' you're concerned about isn't an exploit at all, except 
insofar as to say the weakest point of any cryptosystem is in the 
ignorance of its users.  Even in the worst-case scenario, all you can say 
is that it only affects people who don't bother to learn the cryptosystem 
they're using.  And there is absolutely nothing which can protect people 
from their own ignorance.  Trying to do so is a fool's errand.

Although I'm not a core GPG hacker (my work is limited to a C++ binding 
for GPGME) and thus my opinion has just about as much weight as your 
average Slashdot reader's, I would be extremely displeased to see GnuPG 
chase after an ephemeral exploit and, in the process, break RFC.




From Weimer@CERT.Uni-Stuttgart.DE  Wed May 22 21:21:01 2002
From: Weimer@CERT.Uni-Stuttgart.DE (Florian Weimer)
Date: Wed May 22 20:21:01 2002
Subject: A modified version of GnuPG
In-Reply-To: <1387186383.20020521213928@mail.ru> ("Max V. Zinal"'s message
 of "Tue, 21 May 2002 21:39:28 +0400")
References: <200205210421.QAA220469@ruru.cs.auckland.ac.nz>
 <1387186383.20020521213928@mail.ru>
Message-ID: <87adqturzu.fsf@CERT.Uni-Stuttgart.DE>

"Max V. Zinal" <Zlat0@mail.ru> writes:

> When I said "secure memory" I was going to say "VirtualLock under
> Windows  NT/2000/XP",  which keeps you absolutely safe unless you
> have  a  Terminal  Server  with  an  evil-minded admin, or remote
> desktop    connection    with    'Debug' privileges.

Previous information about VirtualLock on Win32 suggests that it does
not prevent memory from being paged to disk, but only from being paged
to disk and then discarded.

In fact, the MSDN documentation available online carefully avoids the
claim that the specified memory region is never written to disk.

-- 
Florian Weimer 	                  Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898


From kokhong@post1.com  Wed May 22 21:21:04 2002
From: kokhong@post1.com (Soh Kok Hong)
Date: Wed May 22 20:21:04 2002
Subject: GnuPG for Win32
References: <3CE879E5.4060200@post1.com>
Message-ID: <3CEB00B2.3090208@post1.com>

Dear all,

The patch that I am suggesting builds a Win32 executable (ie. no cygwin
DLLs needed) using the CYGWIN's mingw32 tools.  I did not use the mingw32-cpd
stuff because it is rather old and does not include winsock2 - winsock2 is
required in building gnupg for Win32.

You need to run autoconf (by running "scripts/missing --run autoconf") to
rebuild the configure script first.

The changes are as follows:

1. acinclude.m4 & aclocal.m4
- patch to set ac_cv_sys_symbol_underscore to yes for mingw32 target

2. configure.ac
- Added AC_PROG_RANLIB - this was missing.  In real unix targets,
this variable is added because of AM_GNU_GETTEXT which performs
lots of tests - one of which is to set AC_PROG_RANLIB.  In mingw32
target, this did not get set because try_gettext set to "no", hence
AC_PROGR_RANLIB never gets set.

- added a check for presence of strcasecmp function.  Again, the reason
this did not get checked is because of the AM_GNU_GETTEXT problem.

3. cipher/rndw32.c
- forced include of winioctl.h.  This is needed to include the
DISK_PERFORMANCE structure definition.


Soh Kok Hong wrote:
> Dear all,
> 
> I have a 68-line diff file to patch the stock gnupg-1.0.7.tar.gz to
> build a mingw32 executable in the standard cygwin environment.  It
> mainly patches the configure scripts and one source file (rndw32.c).  I
> would like to know if the gnupg maintainers are interested and to whom
> can I email the patch to?
> 
> Please email to me directly as I am not on the list.
> 
> 
> --
> *************************************************
> Soh Kok Hong
> 
> kokhong@post1.com PGP Signature:
> D18B FC65 2202 3E43 A2D3 90D2 7BCC ABD3 77CE CD1C
> *************************************************


============ patch starts here =================

diff -Naur gnupg-1.0.7.orig/acinclude.m4 gnupg-1.0.7/acinclude.m4
--- gnupg-1.0.7.orig/acinclude.m4	2001-12-20 01:16:30.000000000 +0800
+++ gnupg-1.0.7/acinclude.m4	2002-05-18 16:03:16.000000000 +0800
@@ -661,7 +661,7 @@
  AC_DEFUN(GNUPG_SYS_SYMBOL_UNDERSCORE,
  [tmp_do_check="no"
  case "${target}" in
-    i386-emx-os2 | i[3456]86-pc-os2*emx | i386-pc-msdosdjgpp | *-*-cygwin)
+    i386-emx-os2 | i[3456]86-pc-os2*emx | i386-pc-msdosdjgpp | *-*-cygwin | *-*-mingw32 )
          ac_cv_sys_symbol_underscore=yes
          ;;
      *)
diff -Naur gnupg-1.0.7.orig/aclocal.m4 gnupg-1.0.7/aclocal.m4
--- gnupg-1.0.7.orig/aclocal.m4	2002-04-29 22:58:48.000000000 +0800
+++ gnupg-1.0.7/aclocal.m4	2002-05-18 16:03:18.000000000 +0800
@@ -665,7 +665,7 @@
  AC_DEFUN(GNUPG_SYS_SYMBOL_UNDERSCORE,
  [tmp_do_check="no"
  case "${target}" in
-    i386-emx-os2 | i[3456]86-pc-os2*emx | i386-pc-msdosdjgpp | *-*-cygwin)
+    i386-emx-os2 | i[3456]86-pc-os2*emx | i386-pc-msdosdjgpp | *-*-cygwin | *-*-mingw32 )
          ac_cv_sys_symbol_underscore=yes
          ;;
      *)
diff -Naur gnupg-1.0.7.orig/cipher/rndw32.c gnupg-1.0.7/cipher/rndw32.c
--- gnupg-1.0.7.orig/cipher/rndw32.c	2001-12-20 02:05:04.000000000 +0800
+++ gnupg-1.0.7/cipher/rndw32.c	2002-05-18 16:03:18.000000000 +0800
@@ -67,9 +67,7 @@
  #include <string.h>

  #include <windows.h>
-#ifdef __CYGWIN32__
-# include <winioctl.h>
-#endif
+#include <winioctl.h>


  #include "types.h"
diff -Naur gnupg-1.0.7.orig/configure.ac gnupg-1.0.7/configure.ac
--- gnupg-1.0.7.orig/configure.ac	2002-04-29 22:56:08.000000000 +0800
+++ gnupg-1.0.7/configure.ac	2002-05-18 16:03:20.000000000 +0800
@@ -184,6 +184,7 @@
  AM_MISSING_PROG(MAKEINFO, makeinfo, $missing_dir)
  AC_PROG_CC
  AC_PROG_CPP
+AC_PROG_RANLIB
  AC_PATH_PROG(PERL,"perl")
  AC_ISC_POSIX
  AC_SYS_LARGEFILE
@@ -482,7 +483,7 @@
  AC_FUNC_FSEEKO
  AC_FUNC_VPRINTF
  AC_FUNC_FORK
-AC_CHECK_FUNCS(strerror stpcpy strsep strlwr stricmp tcgetattr strtoul mmap)
+AC_CHECK_FUNCS(strerror stpcpy strsep strlwr stricmp tcgetattr strtoul strcasecmp mmap)
  AC_CHECK_FUNCS(memmove gettimeofday getrusage setrlimit clock_gettime)
  AC_CHECK_FUNCS(memicmp atexit raise getpagesize strftime nl_langinfo setlocale)
  AC_CHECK_FUNCS(waitpid wait4 sigaction sigprocmask rand pipe stat)
diff -Naur gnupg-1.0.7.orig/scripts/build-mingw32 gnupg-1.0.7/scripts/build-mingw32
--- gnupg-1.0.7.orig/scripts/build-mingw32	1970-01-01 08:00:00.000000000 +0800
+++ gnupg-1.0.7/scripts/build-mingw32	2002-05-18 16:06:06.000000000 +0800
@@ -0,0 +1,6 @@
+#!/bin/sh
+
+export CC="gcc -mno-cygwin -mthreads"
+
+./configure --target=i386-pc-mingw32
+




From disastry@saiknes.lv  Wed May 22 21:21:06 2002
From: disastry@saiknes.lv (disastry@saiknes.lv)
Date: Wed May 22 20:21:06 2002
Subject: RSA sign+encrypt (with subkey) key generation
Message-ID: <3CEB7600.5CAFAF74@saiknes.lv>

This is a multi-part message in MIME format.
--------------1C9E8650BAE0BC0A8A373C79
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

hello

here is the patch that allows to generate RSA sign+encrypt (with subkey) keys
in one step (like DSA/Elgamal keys) - no need to go to --key-edit to add subkey

it also allows to generate RSA/Elgamal and DSA/RSA keys in one step.

this patch is for 1.0.7a (cvs version)

patch also available at
http://disastry.dhs.org/pgp/gpg/gnupg-1.0.7a-keygen.diff

__
Disastry  http://disastry.dhs.org/
-----BEGIN PGP SIGNATURE-----
Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1

iQA/AwUBPOtZkDBaTVEuJQxkEQNPqACeI4JHKHqW2/bz/yhL4Si7t7TQesoAoIn7
sjEvzUyMrauX8ZRvEa6vWfXk
=Y/XQ
-----END PGP SIGNATURE-----
--------------1C9E8650BAE0BC0A8A373C79
Content-Type: text/plain; charset=us-ascii;
 name="gnupg-1.0.7a-keygen.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="gnupg-1.0.7a-keygen.diff"

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

This patch enables gpg version 1.0.7a to generate RSA sign + RSA encrypt keys
and RSA sign + ElGamal encrypt and DSA + RSA encrypt keys.


Copyright 2001 Free Software Foundation, Inc.

This patch is free software; you can use it, redistribute it
and/or modify it under the terms of the GNU General Public
License as published by the Free Software Foundation; either
version 2 of the License, or (at your option) any later version.


--- gnupg/g10/keygen.c	Thu May 16 05:35:54 2002
+++ gnupg107a/g10/keygen.c	Wed May 22 12:19:21 2002
@@ -849,8 +849,14 @@
     tty_printf(    _("   (%d) RSA (sign only)\n"), 5 );
     if (addmode)
         tty_printf(    _("   (%d) RSA (encrypt only)\n"), 6 );
+    if (!addmode)
+      tty_printf(    _("   (%d) RSA (sign and encrypt (with subkey))\n"), 7 );
     if (opt.expert)
-      tty_printf(    _("   (%d) RSA (sign and encrypt)\n"), 7 );
+      tty_printf(    _("   (%d) RSA (sign and encrypt (single key))\n"), 8 );
+    if (!addmode && opt.expert) { /* add odd keys too... */
+      tty_printf(    _("   (%d) RSA (sign) and ElGamal(encrypt)\n"), 9 );
+      tty_printf(    _("   (%d) DSA (sign) and RSA (encrypt)\n"), 10 );
+    }
 
     for(;;) {
 	answer = cpr_get("keygen.algo",_("Your selection? "));
@@ -858,10 +864,20 @@
 	algo = *answer? atoi(answer): 1;
 	m_free(answer);
 	if( algo == 1 && !addmode ) {
-	    algo = 0;	/* create both keys */
+	    algo = PUBKEY_ALGO_DSA | (PUBKEY_ALGO_ELGAMAL_E << 8);	/* create both keys */
+	    break;
+	}
+	else if( algo == 10 && !addmode && opt.expert ) {
+	    algo = PUBKEY_ALGO_DSA | (PUBKEY_ALGO_RSA << 8);	/* create both keys */
+            *r_usage = PUBKEY_USAGE_ENC << 8;
 	    break;
 	}
-	else if( algo == 7 && opt.expert ) {
+	else if( algo == 9 && !addmode && opt.expert ) {
+	    algo = PUBKEY_ALGO_RSA | (PUBKEY_ALGO_ELGAMAL_E << 8);	/* create both keys */
+            *r_usage = PUBKEY_USAGE_SIG;
+	    break;
+	}
+	else if( algo == 8 && opt.expert ) {
 	    if (cpr_get_answer_is_yes ("keygen.algo.rsa_se",_(
 		"The use of this algorithm is deprecated - create anyway? "))){
               algo = PUBKEY_ALGO_RSA;
@@ -869,6 +885,11 @@
               break;
             }
 	}
+	else if( algo == 7 && !addmode ) {
+	    algo = PUBKEY_ALGO_RSA | (PUBKEY_ALGO_RSA << 8);	/* create both keys */
+            *r_usage = PUBKEY_USAGE_SIG | (PUBKEY_USAGE_ENC << 8);
+	    break;
+	}
 	else if( algo == 6 && addmode ) {
 	    algo = PUBKEY_ALGO_RSA;
             *r_usage = PUBKEY_USAGE_ENC;
@@ -1855,7 +1876,7 @@
 void
 generate_keypair( const char *fname )
 {
-    unsigned int nbits;
+    unsigned int nbits = 0;
     char *uid = NULL;
     DEK *dek;
     STRING2KEY *s2k;
@@ -1875,26 +1896,52 @@
     }
 
     algo = ask_algo( 0, &use );
-    if( !algo ) { /* default: DSA with ElG subkey of the specified size */
+    if( algo >> 8 ) { /* default: DSA with ElG subkey of the specified size */
 	both = 1;
 	r = m_alloc_clear( sizeof *r + 20 );
 	r->key = pKEYTYPE;
-	sprintf( r->u.value, "%d", PUBKEY_ALGO_DSA );
+	sprintf( r->u.value, "%d", algo & 0xff );
 	r->next = para;
 	para = r;
-	tty_printf(_("DSA keypair will have 1024 bits.\n"));
 	r = m_alloc_clear( sizeof *r + 20 );
 	r->key = pKEYLENGTH;
-	strcpy( r->u.value, "1024" );
+	if ((algo & 0xff) == PUBKEY_ALGO_DSA) {
+	    tty_printf(_("DSA keypair will have 1024 bits.\n"));
+	    strcpy( r->u.value, "1024" );
+	} else {
+	    nbits = ask_keysize( algo && 0xff );
+	    sprintf( r->u.value, "%u", nbits);
+	}
 	r->next = para;
 	para = r;
 
-	algo = PUBKEY_ALGO_ELGAMAL_E;
+        if (use & 0xff) {
+            r = m_alloc_clear( sizeof *r + 20 );
+            r->key = pKEYUSAGE;
+            sprintf( r->u.value, "%s%s",
+                     (use & PUBKEY_USAGE_SIG)? "sign ":"",
+                     (use & PUBKEY_USAGE_ENC)? "encrypt ":"" );
+            r->next = para;
+            para = r;
+        }
+
+	algo = algo >> 8;
+	use = use >> 8;
 	r = m_alloc_clear( sizeof *r + 20 );
 	r->key = pSUBKEYTYPE;
 	sprintf( r->u.value, "%d", algo );
 	r->next = para;
 	para = r;
+
+        if (use) {
+            r = m_alloc_clear( sizeof *r + 20 );
+            r->key = pSUBKEYUSAGE;
+            sprintf( r->u.value, "%s%s",
+                     (use & PUBKEY_USAGE_SIG)? "sign ":"",
+                     (use & PUBKEY_USAGE_ENC)? "encrypt ":"" );
+            r->next = para;
+            para = r;
+        }
     }
     else {
 	r = m_alloc_clear( sizeof *r + 20 );
@@ -1915,7 +1962,8 @@
 
     }
 
-    nbits = ask_keysize( algo );
+    if ( !nbits )
+	nbits = ask_keysize( algo );
     r = m_alloc_clear( sizeof *r + 20 );
     r->key = both? pSUBKEYLENGTH : pKEYLENGTH;
     sprintf( r->u.value, "%u", nbits);
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (MingW32)

iD8DBQE863N1MFpNUS4lDGQRAgqTAJ9NW005a2n9RneLmYVz61IOVNCeTQCgj3Zy
z8nOyOhhpk+IoUnaMptHeNA=
=k+D4
-----END PGP SIGNATURE-----

--------------1C9E8650BAE0BC0A8A373C79--



From roconnor@Math.Berkeley.EDU  Thu May 23 04:41:01 2002
From: roconnor@Math.Berkeley.EDU (Russell O'Connor)
Date: Thu May 23 03:41:01 2002
Subject: GnuPG 1.0.7 for OS/2
Message-ID: <Pine.SOL.4.33.0205221839420.19679-100000@blue3.math.berkeley.edu>

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

[To: gnupg-users@gnupg.org, gnupg-devel@gnupg.org]

GnuPG 1.0.7 is available for OS/2 at
<http://math.berkeley.edu/~roconnor/gnupg/>

Requires EMX, RexxEGD, and Zlib 1.1.4.

- -- 
Russell O'Connor                           roconnor@math.berkeley.edu
           <http://www.math.berkeley.edu/~roconnor/>
``Later generations will regard set theory as a disease from which one
has recovered.'' -- Poincare
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (SunOS)
Comment: For info see http://www.gnupg.org

iD8DBQE87EjsuZUa0PWVyWQRAu1gAJ41HmicFwddsI3VLkxglYxlPny4TwCfVcmr
1O6c+oRfhocXSceh04OuEWY=
=zvQa
-----END PGP SIGNATURE-----



From pgut001@cs.auckland.ac.nz  Thu May 23 05:17:01 2002
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
Date: Thu May 23 04:17:01 2002
Subject: Re[2]: A modified version of GnuPG
Message-ID: <200205230217.OAA443785@ruru.cs.auckland.ac.nz>

"Max V. Zinal" <Zlat0@mail.ru> writes:

>When I said "secure memory" I was going to say "VirtualLock under Windows
>NT/2000/XP", which keeps you absolutely safe unless you have a Terminal Server
>with an evil-minded admin, or remote desktop connection with 'Debug'
>privileges.

[...]

>if we are talking about Win9x/ME (which should be called 'Mustdie Edition', I
>think), even with VirtualLock you cannot be absolutely shure.

VirtualLock() has anything from a marginal chance of preventing swapping (best-
case) to a chance of greatly increasing swapping (worst-case).  Under Win9x it
does nothing at all (it's a no-op).  It's nothing like "absolutely safe".  See
e.g. http://www.cryptoapps.com/~peter/06_random.pdf, somewhere towards the end.

Peter.



From avbidder@fortytwo.ch  Thu May 23 12:19:01 2002
From: avbidder@fortytwo.ch (Adrian 'Dagurashibanipal' von Bidder)
Date: Thu May 23 11:19:01 2002
Subject: secure sign & encrypt
In-Reply-To: <Pine.LNX.4.44L0.0205221140200.31437-100000@soli.inav.net>
References: <Pine.LNX.4.44L0.0205221140200.31437-100000@soli.inav.net>
Message-ID: <1022145616.5434.17.camel@atlas>

--=-+TYm2zHn2izZGRW4c328
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2002-05-22 at 18:55, Robert J. Hansen wrote:
> > In other words, your threat model says that you do not only trust the
> > sender (signer) of a message, but you trust all people who may get
> > signed messages from that sender. (Or, alternatively, you as the
>=20
> <testy>
> No.  Please don't make assumptions about my threat model, especially ones=
=20
> which are subtly and seriously wrong.
> </testy>

I'm sorry if I misunderstand you here. Let me ask you, then:

You receive an encrypted + signed message. What do you know now?

You trust the signature. Do you trust that nobody has read the message
in passing?

cheers
-- vbi



--=20
secure email with gpg            avbidder@fortytwo.ch: key id 0x92082481
                                 avbidder@acter.ch:    key id 0x5E4B731F


--=-+TYm2zHn2izZGRW4c328
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA87LRQwj49sl5Lcx8RAomUAJwLd+arZwf1fAY2/+IaxgG43CwUhACfcphN
uL9roi4q9vJvLQ3elBRy7Jw=
=XF8q
-----END PGP SIGNATURE-----

--=-+TYm2zHn2izZGRW4c328--



From jukkaho@mail.student.oulu.fi  Thu May 23 12:58:01 2002
From: jukkaho@mail.student.oulu.fi (Jukka Holappa)
Date: Thu May 23 11:58:01 2002
Subject: secure sign & encrypt
References: <Pine.LNX.4.44L0.0205221140200.31437-100000@soli.inav.net> <1022145616.5434.17.camel@atlas>
Message-ID: <3CECBD9E.4090306@mail.student.oulu.fi>

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

Adrian 'Dagurashibanipal' von Bidder wrote:
| On Wed, 2002-05-22 at 18:55, Robert J. Hansen wrote:
|
|>>In other words, your threat model says that you do not only trust the
|>>sender (signer) of a message, but you trust all people who may get
|>>signed messages from that sender. (Or, alternatively, you as the
|>
|><testy>
|>No.  Please don't make assumptions about my threat model, especially ones
|>which are subtly and seriously wrong.
|></testy>
|
|
| I'm sorry if I misunderstand you here. Let me ask you, then:
|
| You receive an encrypted + signed message. What do you know now?
|
| You trust the signature. Do you trust that nobody has read the message
| in passing?
|

I'm sorry to get in the middle of this, but you really can't know that
with all the signatures you put in it.

Maybe someone read the message over the shoulder before it was
signed+encrypted(+signed) or whatever.

You just have to trust a person to encrypt before anyone sees the
message. If he/she fails to do this, there's no secret message in it any
more.

- - Jukka
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE87L2eYYWM2XTSwX0RApfAAKCDKY19S2HR8weZG3iNAs7XqTFtdwCfZ9rA
Pphmzn7kfxPh7WO+7NIc5oI=
=R2SD
-----END PGP SIGNATURE-----



From avbidder@fortytwo.ch  Thu May 23 16:03:02 2002
From: avbidder@fortytwo.ch (Adrian 'Dagurashibanipal' von Bidder)
Date: Thu May 23 15:03:02 2002
Subject: secure sign & encrypt
In-Reply-To: <3CECBD9E.4090306@mail.student.oulu.fi>
References: <Pine.LNX.4.44L0.0205221140200.31437-100000@soli.inav.net>
 <1022145616.5434.17.camel@atlas>  <3CECBD9E.4090306@mail.student.oulu.fi>
Message-ID: <1022159038.5792.90.camel@atlas>

--=-jHO6hpiweAJ41f8F8ugG
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Thu, 2002-05-23 at 11:59, Jukka Holappa wrote:

> | You receive an encrypted + signed message. What do you know now?
> |
> | You trust the signature. Do you trust that nobody has read the message
> | in passing?
> |
>=20
> I'm sorry to get in the middle of this, but you really can't know that
> with all the signatures you put in it.
>=20
> Maybe someone read the message over the shoulder before it was
> signed+encrypted(+signed) or whatever.
>=20
> You just have to trust a person to encrypt before anyone sees the
> message. If he/she fails to do this, there's no secret message in it any
> more.

I trust that if a person is encrypting a message to me, this person will
also be certain that the message is handled confidentially until it is
encrypted.

The problem with the attack I'm arguing about is that the message was
*not* encrypted in the first place, but that the recipient receives it
as an encrypted message and thus might put a meaning to a message that
was not intended by the sender.

With current openPGP encryption, encryption is only useful for the
sender (he knows that the message sent is encrypted and will not be read
by anybody other than the intended recipient. Of course he trusts the
recipient not to do the wrong thing with the information).=20

Encryption is *not* useful for the recipient - he must not put any
special meaning to the fact that a message was encrypted.

BUT encryption COULD be useful for the recipient, if it was made clear
that the message was sent encrypted in the first place. Of course the
recipient still needs to trust the sender/signer of the message to have
handled the contained information confidentially.


In the end it all boils down that people (or, at least I) automatically
put different meanings to a message, depending on the source of the
message. A message in the newspaper is read differently than the same
message in a letter. In the same way, an unencrypted e-mail message may
be interpreted differently from the same message that comes encrypted -
it tells something about the sender's intention.



Concerning RFC compliance:
from rfc2440, section 5.2.3.1:
=3D=3D=3D=3D=3D=3D
     An implementation SHOULD ignore any subpacket of a type that it
     does not recognize.
=3D=3D=3D=3D=3D=3D

So, adding a hashed subpacket with a subpacket type of, say, 110
(explicitely reserved for private use) for the purpose of announcing the
'intended encryption key' on signed+encrypted messages is fully within
the scope of the rfc and SHOULD not break any openPGP compliant
implementations.

Displaying extra warnings on decrypting messages without this special
subpacket should of course not be the default while this is not in
widespread use. Displaying extra warnings in case there is a mismatch
between the intended and the real encryption key can probably safely be
enabled per default.

Also - although I'm in no way involved with writing RFCs - the RFC
documents have been known to be revised and extended from time to time.


Huk
-- vbi



--=20
secure email with gpg            avbidder@fortytwo.ch: key id 0x92082481
                                 avbidder@acter.ch:    key id 0x5E4B731F


--=-jHO6hpiweAJ41f8F8ugG
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA87Oi+wj49sl5Lcx8RAm00AJ43EYWOM0GseSoNnSOVwkVUQ7nE1gCfbUZr
D44M4vLJ1wofXe7YzMrd378=
=n2Q/
-----END PGP SIGNATURE-----

--=-jHO6hpiweAJ41f8F8ugG--



From jukkaho@mail.student.oulu.fi  Thu May 23 16:59:02 2002
From: jukkaho@mail.student.oulu.fi (Jukka Holappa)
Date: Thu May 23 15:59:02 2002
Subject: secure sign & encrypt
References: <Pine.LNX.4.44L0.0205221140200.31437-100000@soli.inav.net>	<1022145616.5434.17.camel@atlas>  <3CECBD9E.4090306@mail.student.oulu.fi> <1022159038.5792.90.camel@atlas>
Message-ID: <3CECF632.50606@mail.student.oulu.fi>

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

Adrian 'Dagurashibanipal' von Bidder wrote:
| BUT encryption COULD be useful for the recipient, if it was made clear
| that the message was sent encrypted in the first place. Of course the
| recipient still needs to trust the sender/signer of the message to have
| handled the contained information confidentially.
|
|
| In the end it all boils down that people (or, at least I) automatically
| put different meanings to a message, depending on the source of the
| message. A message in the newspaper is read differently than the same
| message in a letter. In the same way, an unencrypted e-mail message may
| be interpreted differently from the same message that comes encrypted -
| it tells something about the sender's intention.
|
|
|
| Concerning RFC compliance:
| from rfc2440, section 5.2.3.1:
| ======
|      An implementation SHOULD ignore any subpacket of a type that it
|      does not recognize.
| ======
|
| So, adding a hashed subpacket with a subpacket type of, say, 110
| (explicitely reserved for private use) for the purpose of announcing the
| 'intended encryption key' on signed+encrypted messages is fully within
| the scope of the rfc and SHOULD not break any openPGP compliant
| implementations.
|
| Displaying extra warnings on decrypting messages without this special
| subpacket should of course not be the default while this is not in
| widespread use. Displaying extra warnings in case there is a mismatch
| between the intended and the real encryption key can probably safely be
| enabled per default.

Very true and an excellent idea.

It would protect fairly well from sending someone else's signed messages
~ with perhaps malicuous (unsigned) attachments, only if programs warn
about missing subkey in encrypted message - and this is not going to be
a big warning in real life since there is no support for this key.

If Cecilia gets any Alices messages and is able to decrypt/copy it, he
can re-encrypt it without this subkey and send it to Bob in any other
contexts. It is not safer at all without this paranoid option which
tells that message was not sent to him originally.

Perhaps signatures would work better.. that they contain information to
who that particular message was sent. Perhaps the message itself ;)

Email programs should also warn when receiving unsigned attachments
along with encrypted/signed messages since there is no way knowing these
attachments are really from that person.


|
| Also - although I'm in no way involved with writing RFCs - the RFC
| documents have been known to be revised and extended from time to time.

Someone has to do it (not me either) :)

- - Jukka
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE87PYxYYWM2XTSwX0RAnktAJ4tX+HDuD7wrGBtMSSHK0BTBr/KHwCeLRw2
Y3Vxy/O9BzFffgXl5AoWbEM=
=WB+0
-----END PGP SIGNATURE-----



From rjhansen@inav.net  Thu May 23 17:21:02 2002
From: rjhansen@inav.net (Robert J. Hansen)
Date: Thu May 23 16:21:02 2002
Subject: secure sign & encrypt
In-Reply-To: <1022145616.5434.17.camel@atlas>
Message-ID: <Pine.LNX.4.44L0.0205230853260.11995-100000@soli.inav.net>

> You receive an encrypted + signed message. What do you know now?

I trust that the message really was composed by the original author, and I 
know it was encrypted when the data came out of the pipe.  If the signed 
message contains traffic which was unambiguously meant for me, then the 
message was intended for me.  Encryption and signing just means encryption 
and signing; I don't assume that crypto is some kind of magic fairy dust, 
where you sprinkle a little of it on your traffic and suddenly you're 
"secure".

A signed message doesn't mean the traffic was intended for you, it just 
means the message hasn't been tampered with in transit.  An encrypted 
message doesn't mean nobody's read the message, it just means it's been 
kept safe in transit from the time someone encrypted it to the time you 
decrypted it.




From rjhansen@inav.net  Thu May 23 17:29:01 2002
From: rjhansen@inav.net (Robert J. Hansen)
Date: Thu May 23 16:29:01 2002
Subject: secure sign & encrypt
In-Reply-To: <1022159038.5792.90.camel@atlas>
Message-ID: <Pine.LNX.4.44L0.0205230922350.11995-100000@soli.inav.net>

> In the end it all boils down that people (or, at least I) automatically
> put different meanings to a message, depending on the source of the

If you decide to (foolishly) infer that crypto means something that it 
doesn't, which no reputable source will tell you it does, then that 
reflects more on your own lack of understanding than a flaw in the 
protocol.  Ignorance is the Achilles' heel of every protocol, and your 
proposed fix does not fix the protocol--the protocol's not broken--it just 
makes the protocol come into line with how you think the protocol Ought To 
Be.

> Concerning RFC compliance:
> from rfc2440, section 5.2.3.1:
> ======
>      An implementation SHOULD ignore any subpacket of a type that it
>      does not recognize.
> ======

Note well that sentence.  SHOULD, not MUST.  For every program which 
correctly and properly implements RFCs, there are easily a couple of dozen 
which just barely manage to get the MUSTs implemented.  When I was working 
at McLeodUSA, they had me working on a project to reimplement RFC1991 
(Classic PGP) in-house so they could get around the licensing terms.  
(Never mind that the license fees to RSA and IDEA were prohibitive... 
management at its finest.)  Given the tremendous time constraints I was 
under, I was doing really, really well just to get the MUSTs.

If this extension gets implemented it _will_ break interoperability with 
other OpenPGP implementations (even if I don't know offhand which ones it 
will break), and we'll be the ones who will be responsible.  All for no 
effective increase in security.

> Also - although I'm in no way involved with writing RFCs - the RFC
> documents have been known to be revised and extended from time to time.

Yes, by working groups.  If you want the RFC changed, there's a process in 
place for it; take it to the IETF and make the sales pitch there.  GnuPG 
is not the place to be embracing-and-extending the RFC.

I don't know how much clearer I can make it here, really.



From Max V. Zinal" <Zlat0@mail.ru  Thu May 23 18:12:01 2002
From: Max V. Zinal" <Zlat0@mail.ru (Max V. Zinal)
Date: Thu May 23 17:12:01 2002
Subject: Re[2]: A modified version of GnuPG
In-Reply-To: <87adqturzu.fsf@CERT.Uni-Stuttgart.DE>
References: <200205210421.QAA220469@ruru.cs.auckland.ac.nz>
 <1387186383.20020521213928@mail.ru> <87adqturzu.fsf@CERT.Uni-Stuttgart.DE>
Message-ID: <31929626.20020523190617@mail.ru>

Wednesday, May 22, 2002, 1:10:29 AM, Florian Weimer wrote:

FW> Previous information about VirtualLock on Win32 suggests that it does
FW> not prevent memory from being paged to disk, but only from being paged
FW> to disk and then discarded.

FW> In fact, the MSDN documentation available online carefully avoids the
FW> claim that the specified memory region is never written to disk.

Yes, that's true, and that was my mistake. The only excuse for me
is the following phrase in "VirtualLock" manual:

        "The  VirtualLock  function locks the specified region of
        the process's virtual address space into physical memory,
        ensuring  that  subsequent  access to the region will not
        incur a page fault."

I think that I can write a small dummy device driver for NT-based
system  that  will  allow  a person with administrative rights to
allocate  a non-pageable region of memory. It will take some time,
I  think,  because  I will have to find DDK distribution for that
purposes.  Such task isn't too complex, although it will not work
under 9x-based systems.

I'm sorry for inconvenience.

Best regards,
        Max V. Zinal



From dmitri@users.sourceforge.net  Thu May 23 18:32:01 2002
From: dmitri@users.sourceforge.net (Dmitri)
Date: Thu May 23 17:32:01 2002
Subject: Re[2]: A modified version of GnuPG
In-Reply-To: <31929626.20020523190617@mail.ru>
References: <200205210421.QAA220469@ruru.cs.auckland.ac.nz>
 <1387186383.20020521213928@mail.ru> <87adqturzu.fsf@CERT.Uni-Stuttgart.DE>
 <31929626.20020523190617@mail.ru>
Message-ID: <1022167972.29488.271.camel@usb.networkfab.com>

--=-rHpJX1Lq3gk4cG70YFPF
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Thu, 2002-05-23 at 08:06, Max V. Zinal wrote:

> I think that I can write a small dummy device driver for NT-based
> system  that  will  allow  a person with administrative rights to
> allocate  a non-pageable region of memory.

The driver does not need anyone's permission, it has full access to
everything in the kernel. But only administrator can install a driver.
Then the driver can impose any security restrictions on its use.

> It will take some time,
> I  think,  because  I will have to find DDK distribution for that
> purposes.

void *ExAllocatePool(NonPagedPool, <length>);

> Such task isn't too complex

300 lines of code, maybe. You will need to handle
IRP_MJ_{CREATE,CLOSE,READ,WRITE}. But the architecture of Win2K WDM
drivers is not really straightforward; if you never did it before then
you got some reading to do ;-)

Dmitri


--=-rHpJX1Lq3gk4cG70YFPF
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA87QujXksyLpO6T4IRAvr0AJ0ShJ+szbsW4kN83sn/chR6/MGdNACcCz2g
oAVv49dWTCC0rWm0XQHjjRA=
=Ivru
-----END PGP SIGNATURE-----

--=-rHpJX1Lq3gk4cG70YFPF--



From Pascal@Scheffers.Net  Thu May 23 22:41:01 2002
From: Pascal@Scheffers.Net (Pascal Scheffers)
Date: Thu May 23 21:41:01 2002
Subject: Re[2]: A modified version of GnuPG
In-Reply-To: <31929626.20020523190617@mail.ru>
References: <200205210421.QAA220469@ruru.cs.auckland.ac.nz>
 <1387186383.20020521213928@mail.ru> <87adqturzu.fsf@CERT.Uni-Stuttgart.DE>
 <31929626.20020523190617@mail.ru>
Message-ID: <1022182918.20135.17.camel@moonchild.lcl>

On Thu, 2002-05-23 at 17:06, Max V. Zinal wrote:
> FW> In fact, the MSDN documentation available online carefully avoids the
AFAICT, MSDN-online is/was 100% in sync with the offline available
versions (3 cdrom disk/DVD distribution), the only 'but' is that it is
uptodate, meaning older information isn't there anymore (or much harder
to find). 

This was a pain in the b*tt when I was working with crypto APIs for
win95 in the 2000, it's not always clear which API works with which
version. I have no idea if it's any better for the DDK. 

I seem to have trouble accessing it right now with Galeon, but that is
sort-of to be expected.

> I  think,  because  I will have to find DDK distribution for that
That is part of the MSDN library, too. You can also just download it
from the MS website: http://www.microsoft.com/ddk/W2kDDK.asp

It says there that the DDK has all the info, libraries, manuals and
samples you'll ever need. It's a 67MB download, tho. 

- Pascal.




From pgut001@cs.auckland.ac.nz  Fri May 24 08:06:01 2002
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
Date: Fri May 24 07:06:01 2002
Subject: Re[2]: A modified version of GnuPG
Message-ID: <200205240507.RAA43132@ruru.cs.auckland.ac.nz>

"Max V. Zinal" <Zlat0@mail.ru> writes:

>I think that I can write a small dummy device driver for NT-based system that
>will allow a person with administrative rights to allocate a non-pageable
>region of memory. It will take some time, I think, because I will have to find
>DDK distribution for that purposes.

You don't need to do that, there are already user-level functions which do
this.  To save me having to regurgitate it all again, search sci.crypt or the
archives of Perry Metzger's crypto list for "AllocateUserPhysicalPages" to find
the details.

Peter.



From avbidder@fortytwo.ch  Fri May 24 10:33:02 2002
From: avbidder@fortytwo.ch (Adrian 'Dagurashibanipal' von Bidder)
Date: Fri May 24 09:33:02 2002
Subject: secure sign & encrypt
In-Reply-To: <Pine.LNX.4.44L0.0205230922350.11995-100000@soli.inav.net>
References: <Pine.LNX.4.44L0.0205230922350.11995-100000@soli.inav.net>
Message-ID: <1022225631.24970.43.camel@atlas>

--=-jdknF5oRudFIcEcv2yDr
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Thu, 2002-05-23 at 16:29, Robert J. Hansen wrote:
> > In the end it all boils down that people (or, at least I) automatically
> > put different meanings to a message, depending on the source of the
>=20
[...]

> proposed fix does not fix the protocol--the protocol's not broken--it jus=
t=20
> makes the protocol come into line with how you think the protocol Ought T=
o=20
> Be.

Agree with you here - and I feel that to many users not willing to study
the protocol in dephth 'my' variant of the protocol is closer to what
people expect if they use a crypto solution.

Jukka:
> Perhaps signatures would work better.. that they contain information
> to who that particular message was sent. Perhaps the message itself ;)

I thought about the 'intended recipient' thing, analogous to my
'inteneded encryption key', but for non-encrypted messages. Clearly this
cannot be solved by gpg - how should it know the destination of the
message? However, MUAs could copy the To: header (and Subject:, too?)
into the signed area of the mail (MIME-Headers?), and use these infos
when displaying signed mail. (But as there are many more MUAs than
OpenPGP implementations, this proposal has an even smaller chance of
ever getting implemented)


As all points have probably been made (repeatedly - yes, I'm the guilty
here) it's probably ok if this is EOT here before the discussion becomes
endless (or we could always move over to de.alt.gruppenkasper).


cheers & HAND
-- vbi


--=20
secure email with gpg            avbidder@fortytwo.ch: key id 0x92082481
                                 avbidder@acter.ch:    key id 0x5E4B731F


--=-jdknF5oRudFIcEcv2yDr
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA87ezewj49sl5Lcx8RAk5uAJ9GuA/n9G7N4WA88e+5PFOEQDgOxQCdH1kt
koDk6bA8CU53j+Fe3Fg98CI=
=DnRn
-----END PGP SIGNATURE-----

--=-jdknF5oRudFIcEcv2yDr--



From Max V. Zinal" <Zlat0@mail.ru  Fri May 24 18:06:02 2002
From: Max V. Zinal" <Zlat0@mail.ru (Max V. Zinal)
Date: Fri May 24 17:06:02 2002
Subject: Re[4]: A modified version of GnuPG
In-Reply-To: <200205240507.RAA43132@ruru.cs.auckland.ac.nz>
References: <200205240507.RAA43132@ruru.cs.auckland.ac.nz>
Message-ID: <11716388144.20020524190723@mail.ru>

Friday, May 24, 2002, 9:07:19 AM, Peter Gutmann wrote:

PG> "Max V. Zinal" <Zlat0@mail.ru> writes:

>>I think that I can write a small dummy device driver for NT-based system that
>>will allow a person with administrative rights to allocate a non-pageable
>>region of memory. It will take some time, I think, because I will have to find
>>DDK distribution for that purposes.

PG> You don't need to do that, there are already user-level functions which do
PG> this.  To save me having to regurgitate it all again, search sci.crypt or the
PG> archives of Perry Metzger's crypto list for "AllocateUserPhysicalPages" to find
PG> the details.

I  know about these functions. Please note that they are the part
of  Address  Windowing  Extensions  (AWE), and thus are supported
only  with W2K or higher. We should also remember that Windows NT
4 is still widely used.

Best regards,
        Max V. Zinal



From pgut001@cs.auckland.ac.nz  Mon May 27 10:34:01 2002
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
Date: Mon May 27 09:34:01 2002
Subject: Re[4]: A modified version of GnuPG
Message-ID: <200205270735.TAA74949@ruru.cs.auckland.ac.nz>

"Max V. Zinal" <Zlat0@mail.ru> writes:
>Friday, May 24, 2002, 9:07:19 AM, Peter Gutmann wrote:
>PG> "Max V. Zinal" <Zlat0@mail.ru> writes:
>>>I think that I can write a small dummy device driver for NT-based system that
>>>will allow a person with administrative rights to allocate a non-pageable
>>>region of memory. It will take some time, I think, because I will have to find
>>>DDK distribution for that purposes.
>
>PG> You don't need to do that, there are already user-level functions which do
>PG> this.  To save me having to regurgitate it all again, search sci.crypt or the
>PG> archives of Perry Metzger's crypto list for "AllocateUserPhysicalPages" to find
>PG> the details.
>
>I know about these functions. Please note that they are the part of Address
>Windowing Extensions (AWE), and thus are supported only with W2K or higher. We
>should also remember that Windows NT 4 is still widely used.

You have to make a tradeoff, either be backwards-compatible with NT4 (which I
doubt is still widely used except maybe on a few servers which no-one wants to
touch) and face an incredibly difficult task of writing an NT kernel driver to
do it, or require Win2K and have Microsoft do most of it for you.  Trying to be
NT4-compatible seems to be an unnecesarily painful way to do things.

Peter.


From broonie@sirena.org.uk  Mon May 27 11:47:01 2002
From: broonie@sirena.org.uk (Mark Brown)
Date: Mon May 27 10:47:01 2002
Subject: Re[4]: A modified version of GnuPG
In-Reply-To: <200205270735.TAA74949@ruru.cs.auckland.ac.nz>
References: <200205270735.TAA74949@ruru.cs.auckland.ac.nz>
Message-ID: <20020527084805.GA848@sirena.org.uk>

--6c2NcOVqGQ03X4Wi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, May 27, 2002 at 07:35:21PM +1200, Peter Gutmann wrote:

> You have to make a tradeoff, either be backwards-compatible with NT4 (whi=
ch I
> doubt is still widely used except maybe on a few servers which no-one wan=
ts to
> touch) and face an incredibly difficult task of writing an NT kernel driv=
er to

There's still a reasonable number of deployed NT 4 systems, including
desktops.  Often it's a case of "it's not broken for us" and not/or
wanting to go to the effort of moving off a platform that has been
reliable and stable until the last possible minute.

> do it, or require Win2K and have Microsoft do most of it for you.  Trying=
 to be
> NT4-compatible seems to be an unnecesarily painful way to do things.

I do agree with the conclusion, though.

--=20
"You grabbed my hand and we fell into it, like a daydream - or a fever."

--6c2NcOVqGQ03X4Wi
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE88fLEJ2Vo11xhU60RAnZqAJ9cdalOD86O1R9XHso7ORws3ZkyRwCeLdEh
zefwGwEl3R5XV7OanXhSmZc=
=2+Eo
-----END PGP SIGNATURE-----

--6c2NcOVqGQ03X4Wi--


From disastry@saiknes.lv  Mon May 27 12:18:02 2002
From: disastry@saiknes.lv (disastry@saiknes.lv)
Date: Mon May 27 11:18:02 2002
Subject: Re[4]: A modified version of GnuPG
Message-ID: <3CF1E23A.24C83E24@saiknes.lv>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Max V. Zinal wrote:
> 
> PG> You don't need to do that, there are already user-level functions which do
> PG> this.  To save me having to regurgitate it all again, search sci.crypt or the
> PG> archives of Perry Metzger's crypto list for "AllocateUserPhysicalPages" to find
> PG> the details.
> 
> I  know about these functions. Please note that they are the part
> of  Address  Windowing  Extensions  (AWE), and thus are supported
> only  with W2K or higher. We should also remember that Windows NT
> 4 is still widely used.

so just call GetProcAderss(hKernel32,"AllocateUserPhysicalPages");
to find if the function is available, if yes - use it :)

__
Disastry  http://disastry.dhs.org/
http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon
 ^----PGP 2.6.3ia-multi06 (supports IDEA, CAST5, BLOWFISH, TWOFISH,
      AES, 3DES ciphers and MD5, SHA1, RIPEMD160, SHA2 hashes)
-----BEGIN PGP SIGNATURE-----
Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1

iQA/AwUBPPHFvjBaTVEuJQxkEQNNOQCcCOw75WYyyyORl+IDWPnldvTOHiYAoMn6
nTM1sXjGVJSkewvIIlSY9NyA
=c7hS
-----END PGP SIGNATURE-----


From rjhansen@inav.net  Mon May 27 13:11:01 2002
From: rjhansen@inav.net (Robert J. Hansen)
Date: Mon May 27 12:11:01 2002
Subject: Unpredictable GPGME bug
Message-ID: <Pine.LNX.4.44L0.0205270506070.16314-100000@soli.inav.net>

Looks like there might be a bug in GPGME (I know, pre-1.0 software with 
bugs--what's the world coming to?).  My C++ bindings for GPGME attempt to 
grab all sorts of string data for a given key, and sometimes it will be 
able to grab a string representation of the algorithm type and other times 
it'll segfault.  The offending snippet of code looks like:

GpgmeKey _key;
std::string _algo;

_algo = gpgme_key_get_string_attr(_key, GPGME_ATTR_ALGO, NULL, 0);

... Maybe one time in ten, that line of code will segfault.  
gpgme_key_get_string_attr apparently returns a NULL pointer, and trying to 
make a C++ std::string out of a NULL pointer is an instant segfault.

This has happened for other string quantities, such as usernames, etc.  
For now, my solution is to assign the result of g_k_g_s_a() to a const 
char*, test the const char* against NULL, and then assign either the const 
char* to _algo or else assign "Unassigned" to _algo.  However, this is 
fairly inelegant given that we could just fix the GPGME code.  :)





From rjhansen@inav.net  Mon May 27 14:23:02 2002
From: rjhansen@inav.net (Robert J. Hansen)
Date: Mon May 27 13:23:02 2002
Subject: GPGME wishlist...
Message-ID: <Pine.LNX.4.44L0.0205270600470.7300-100000@soli.inav.net>

*  The terminology in the documentation is a little awkward when it comes 
to signatures (on keys/user IDs).  For instance, there's a section on 
"Trust Items"--well, yeah, signatures tell us if a key/userid is or isn't 
trusted... on the other hand, gpgme_key_get_string_attr says that it's 
used for "attributes of sub keys and user IDs", and a signature is an 
attribute of those, so... etc.  It appears that both interfaces are 
necessary to some degree, but the docs never make it clear to what degree 
each are necessary.

*  How to get key signature information is a little 
awkward/counterintuitive.  For instance, according to my current (limited) 
understanding of the interface, in order to process key signatures I must:

1.  call gpgme_op_trustlist_start, passing in a 16-hex key ID to uniquely 
identify the key I want to iterate over

2.  start pulling trust items off the key

3.  get each item's GPGME_ATTR_USERID

4.  ... and only then can I associate a given trust item with a given user 
ID.

Please note: I haven't written code that works this way yet.  This is just 
the way I understand it to be, from looking at the docs.  If I'm 
misunderstanding, then please take my idiocy as evidence the docs need to 
be written for congenital idiots such as myself (grin).  If I'm not 
misunderstanding the docs, then it seems like we're making the process 
tougher than it needs to be.

Possible solution: add a new function,

gpgme_op_trustlist_uid_start(
	GpgmeCtx ctx,
	const char *hexID,
	int userID,
	int max_level
	)

... which would act just like gpgme_op_trustlist_start, except it would 
restrict the iteration to a given user ID.  This would make things a 
little easier for those of us who aren't geniuses.  :)

It's 6:20am and now I'm going to bed.  Thanks, guys.
	



From Marcus.Brinkmann@ruhr-uni-bochum.de  Mon May 27 14:54:02 2002
From: Marcus.Brinkmann@ruhr-uni-bochum.de (Marcus Brinkmann)
Date: Mon May 27 13:54:02 2002
Subject: Unpredictable GPGME bug
In-Reply-To: <Pine.LNX.4.44L0.0205270506070.16314-100000@soli.inav.net>
References: <Pine.LNX.4.44L0.0205270506070.16314-100000@soli.inav.net>
Message-ID: <20020527115449.GB1180@212.23.136.22>

On Mon, May 27, 2002 at 05:12:24AM -0500, Robert J. Hansen wrote:
> Looks like there might be a bug in GPGME (I know, pre-1.0 software with 
> bugs--what's the world coming to?).  My C++ bindings for GPGME attempt to 
> grab all sorts of string data for a given key, and sometimes it will be 
> able to grab a string representation of the algorithm type and other times 
> it'll segfault.  The offending snippet of code looks like:
> 
> GpgmeKey _key;
> std::string _algo;
> 
> _algo = gpgme_key_get_string_attr(_key, GPGME_ATTR_ALGO, NULL, 0);
> 
> ... Maybe one time in ten, that line of code will segfault.  

What do you mean?  one out of ten times you run this on the same key, or for
one out of ten keys?

Let's look at the code:
    case GPGME_ATTR_ALGO:
      for (k = &key->keys; k && idx; k=k->next, idx--)
        ;
      if (k)
        val = pkalgo_to_string (k->key_algo);
      break;

So, if _key is really a key (and not NULL itself), which contains at least
one subkey (key->keys)), then this can not return NULL, because
pkalgo_to_string doesn't return NULL.

You could let it crash in gdb and check what the key and key->keys look
like in the case it is failing.

> gpgme_key_get_string_attr apparently returns a NULL pointer, and trying to 
> make a C++ std::string out of a NULL pointer is an instant segfault.
> 
> This has happened for other string quantities, such as usernames, etc.  
> For now, my solution is to assign the result of g_k_g_s_a() to a const 
> char*, test the const char* against NULL, and then assign either the const 
> char* to _algo or else assign "Unassigned" to _algo.  However, this is 
> fairly inelegant given that we could just fix the GPGME code.  :)

Most properties are optional and can return NULL, so you must catch the NULL
case anyway.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de


From aphex@nullify.org  Mon May 27 19:54:02 2002
From: aphex@nullify.org (Keith Ray)
Date: Mon May 27 18:54:02 2002
Subject: Photo ID race condition
Message-ID: <1022518490.3cf264daeba39@mail.nullify.org>

There is a (non-security) race condition in the photo ID code under
Windows.  If the user has a slow loading image viewer (ie. Mozilla), GnuPG could
delete the temp file before the viewer finishes initializing.  I can think of a
number of solutions:

1. Wait for the viewer to exit before returning to GnuPG.
2. Insert a delay between exec_read() and exec_finish().  Then again, on a slow
system with little RAM, how much is enough?
3. Delay deleting the temp files until GnuPG exits.

  -- Keith


From dmitri@users.sourceforge.net  Mon May 27 20:19:01 2002
From: dmitri@users.sourceforge.net (Dmitri)
Date: Mon May 27 19:19:01 2002
Subject: Photo ID race condition
In-Reply-To: <1022518490.3cf264daeba39@mail.nullify.org>
References: <1022518490.3cf264daeba39@mail.nullify.org>
Message-ID: <1022520028.3628.40.camel@usb.networkfab.com>

--=-AzaZ68uR4RPMwOrnXu5h
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Mon, 2002-05-27 at 09:54, Keith Ray wrote:

> There is a (non-security) race condition in the photo ID code under
> Windows.  If the user has a slow loading image viewer (ie. Mozilla), GnuP=
G could
> delete the temp file before the viewer finishes initializing.  I can thin=
k of a
> number of solutions:
>=20
> 1. Wait for the viewer to exit before returning to GnuPG.

GnuPG actually won't stop running. But this seems to be the right
solution. See CreateProcess() and OpenProcess() here:

http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/dllproc/=
prothred_9dpv.asp

> 2. Insert a delay between exec_read() and exec_finish().  Then again, on =
a slow
> system with little RAM, how much is enough?

Fudge factor works only in 27% of all cases ;-)

> 3. Delay deleting the temp files until GnuPG exits.

Dmitri


--=-AzaZ68uR4RPMwOrnXu5h
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA88mrcXksyLpO6T4IRArRkAKCZkrFAjDwHkuaFdDrELgC9ztS9PwCfS4pY
ahMRn0RVeY4yLBGuc9XW8us=
=x11+
-----END PGP SIGNATURE-----

--=-AzaZ68uR4RPMwOrnXu5h--



From wk@gnupg.org  Mon May 27 21:03:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Mon May 27 20:03:01 2002
Subject: A modified version of GnuPG
In-Reply-To: <3CF1E23A.24C83E24@saiknes.lv> (disastry@saiknes.lv's message
 of "Mon, 27 May 2002 09:37:30 +0200")
References: <3CF1E23A.24C83E24@saiknes.lv>
Message-ID: <87lma5mpmp.fsf@alberti.gnupg.de>

On Mon, 27 May 2002 09:37:30 +0200, disastry  said:

> so just call GetProcAderss(hKernel32,"AllocateUserPhysicalPages");
> to find if the function is available, if yes - use it :)

I'll see what I can do.  I have to incorporate some RNG enhancements from
Cryptlib anyway.


Salam-Shalom,

   Werner



From wk@gnupg.org  Mon May 27 21:07:02 2002
From: wk@gnupg.org (Werner Koch)
Date: Mon May 27 20:07:02 2002
Subject: GPGME wishlist...
In-Reply-To: <Pine.LNX.4.44L0.0205270600470.7300-100000@soli.inav.net> ("Robert
 J. Hansen"'s message of "Mon, 27 May 2002 06:23:29 -0500 (CDT)")
References: <Pine.LNX.4.44L0.0205270600470.7300-100000@soli.inav.net>
Message-ID: <87hektmper.fsf@alberti.gnupg.de>

On Mon, 27 May 2002 06:23:29 -0500 (CDT), Robert J Hansen said:

> *  How to get key signature information is a little 
> awkward/counterintuitive.  For instance, according to my current (limited) 
> understanding of the interface, in order to process key signatures I must:

Frankly, there is no interface for it.  


> 1.  call gpgme_op_trustlist_start, passing in a 16-hex key ID to

This is an expermimental - I hope the manual says so, but I am not
sure.  


Shalom-Salam,

   Werner



From andrew@mcdonald.org.uk  Mon May 27 21:19:01 2002
From: andrew@mcdonald.org.uk (Andrew McDonald)
Date: Mon May 27 20:19:01 2002
Subject: Photo ID race condition
In-Reply-To: <1022518490.3cf264daeba39@mail.nullify.org>
References: <1022518490.3cf264daeba39@mail.nullify.org>
Message-ID: <20020527181933.GA969@mcdonald.org.uk>

On Mon, May 27, 2002 at 11:54:50AM -0500, Keith Ray wrote:
> There is a (non-security) race condition in the photo ID code under
> Windows.  If the user has a slow loading image viewer (ie. Mozilla),
> GnuPG could delete the temp file before the viewer finishes
> initializing.

This is an issue I have seen mentioned in connection with mutt's
viewing of attachments. Try searching for mutt_bgrun, a script that
provides one way to solve this.

-- 
Andrew McDonald
E-mail: andrew@mcdonald.org.uk
http://www.mcdonald.org.uk/andrew/


From dshaw@jabberwocky.com  Tue May 28 01:51:01 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Tue May 28 00:51:01 2002
Subject: Photo ID race condition
In-Reply-To: <1022518490.3cf264daeba39@mail.nullify.org>
References: <1022518490.3cf264daeba39@mail.nullify.org>
Message-ID: <20020527223655.GB813@akamai.com>

On Mon, May 27, 2002 at 11:54:50AM -0500, Keith Ray wrote:
> There is a (non-security) race condition in the photo ID code under
> Windows.  If the user has a slow loading image viewer (ie. Mozilla), GnuPG could
> delete the temp file before the viewer finishes initializing.  I can think of a
> number of solutions:
> 
> 1. Wait for the viewer to exit before returning to GnuPG.
> 2. Insert a delay between exec_read() and exec_finish().  Then again, on a slow
> system with little RAM, how much is enough?
> 3. Delay deleting the temp files until GnuPG exits.

This is a known problem with 1.0.7 (1.0.7 was never really intended
for widespread Win32 use).  Until 1.0.8 is released with a
non-system()-based implementation of the exec code, you have a few
options:

1) Patch the code based on the CVS
2) Use %I instead of %i in your photo-viewer command line
3) Try a photo-viewer of "start /w %i.jpg"

(#3 should work but I haven't tested it - I'm traveling and have no
access to a windows box at the moment)

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From aphex@nullify.org  Tue May 28 04:40:01 2002
From: aphex@nullify.org (Keith Ray)
Date: Tue May 28 03:40:01 2002
Subject: Photo ID race condition
Message-ID: <1022550030.3cf2e00e4d1e1@mail.nullify.org>

Quoting David Shaw <dshaw@jabberwocky.com>:
> On Mon, May 27, 2002 at 11:54:50AM -0500, Keith Ray wrote:
> > There is a (non-security) race condition in the photo ID code under
> > Windows.  If the user has a slow loading image viewer (ie. Mozilla), GnuPG
> > could delete the temp file before the viewer finishes initializing.  I can
> > think of a number of solutions:
> >
> > 1. Wait for the viewer to exit before returning to GnuPG.
> > 2. Insert a delay between exec_read() and exec_finish().  Then again, on a
> > slow system with little RAM, how much is enough?
> > 3. Delay deleting the temp files until GnuPG exits.
>
> This is a known problem with 1.0.7 (1.0.7 was never really intended
> for widespread Win32 use).  Until 1.0.8 is released with a
> non-system()-based implementation of the exec code, you have a few
> options:
>
> 1) Patch the code based on the CVS
> 2) Use %I instead of %i in your photo-viewer command line
> 3) Try a photo-viewer of "start /w %i.jpg"
>
> (#3 should work but I haven't tested it - I'm traveling and have no
> access to a windows box at the moment)

Hmm, I should have been more explicit on my setup ;)  I was using 1.0.7a-cvs
from May 24.  The photo viewer was the default:

#define DEFAULT_PHOTO_COMMAND "start /w %i"

Mozilla is the default .jpg viewer.   For some reason, execution returns to
GnuPG immediately after launching Mozilla.  Mozilla does not finish loading
itself and then the picture before GnuPG deletes the temporary directory and
file.  Thus, solution #3 isn't working.

Unless there is a way to modify the "start" command to actually wait when
launching an object file instead of an executable, I think the best route would
be to read the registry to find the default viewer and then "start" that.

I will code up a patch against CVS and e-mail it to you when I'm done.

  -- Keith


From dshaw@jabberwocky.com  Tue May 28 05:30:02 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Tue May 28 04:30:02 2002
Subject: Photo ID race condition
In-Reply-To: <1022550030.3cf2e00e4d1e1@mail.nullify.org>
References: <1022550030.3cf2e00e4d1e1@mail.nullify.org>
Message-ID: <20020528023032.GE813@akamai.com>

On Mon, May 27, 2002 at 08:40:30PM -0500, Keith Ray wrote:
> Hmm, I should have been more explicit on my setup ;)  I was using 1.0.7a-cvs
> from May 24.  The photo viewer was the default:
> 
> #define DEFAULT_PHOTO_COMMAND "start /w %i"
> 
> Mozilla is the default .jpg viewer.   For some reason, execution returns to
> GnuPG immediately after launching Mozilla.  Mozilla does not finish loading
> itself and then the picture before GnuPG deletes the temporary directory and
> file.  Thus, solution #3 isn't working.

It looks like Mozilla is being "helpful" here and returning control
before doing the requested command.  If that is the case, then this is
not something that GnuPG can address.  Are you sure that is what is
happening?  What happens when you do "start /w foobar.jpg" from the
command line on some other jpg you may have lying around?

> Unless there is a way to modify the "start" command to actually wait
> when launching an object file instead of an executable, I think the
> best route would be to read the registry to find the default viewer
> and then "start" that.

GnuPG is a crypto program, and reading the registry to figure out
photo viewers is getting too far astray from that core functionality.
This is where bugs come in and bugs in crypto software can be very
dangerous.  I did add generic call-a-program functionality because it
is usable in several places (keyservers as well as photo IDs) but it
must be kept simple and easily verifiable.

In any event, the whole point of "start" itself is to read the
registry and start the appropriate program, so there is no point in
adding code to do this to GnuPG.

> I will code up a patch against CVS and e-mail it to you when I'm done.

The "/w" flag for start means "wait".  Unfortunately, it seems that
Mozilla's start-in-the-background feature defeats this.  If that is
what is happening then there is nothing that can (easily) be done here
with start or even internal to GnuPG since it can only wait for a
program that does not start in the background (some viewers give you a
choice).

If you must use Mozilla as your viewer, then use %I in your
photo-viewer rather than %i (that is, capital "I" rather than
lowercase "i").  This will make GnuPG not delete the temp file at all,
so you will need to delete it yourself when you are done with it.

Like I said before, 1.0.8 has a slightly different implementation (not
yet checked in, so you won't see it in CVS) that allows for better
handling of arguments in the photo-viewer command line, but there is
very little that can be done about the start-in-the-background
problem.  If it makes you feel any better, it's the same way on Unix
when using temp files, but at least the Unix viewers usually aren't
written to background themselves automatically.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From keith@nullify.org  Tue May 28 11:48:01 2002
From: keith@nullify.org (Keith Ray)
Date: Tue May 28 10:48:01 2002
Subject: Photo ID race condition
In-Reply-To: <20020527223655.GB813@akamai.com>
References: <1022518490.3cf264daeba39@mail.nullify.org> <20020527223655.GB813@akamai.com>
Message-ID: <1022550003.3cf2dff3e2115@mail.nullify.org>

Quoting David Shaw <dshaw@jabberwocky.com>:
> On Mon, May 27, 2002 at 11:54:50AM -0500, Keith Ray wrote:
> > There is a (non-security) race condition in the photo ID code under
> > Windows.  If the user has a slow loading image viewer (ie. Mozilla), GnuPG
> > could delete the temp file before the viewer finishes initializing.  I can
> > think of a number of solutions:
> > 
> > 1. Wait for the viewer to exit before returning to GnuPG.
> > 2. Insert a delay between exec_read() and exec_finish().  Then again, on a
> > slow system with little RAM, how much is enough?
> > 3. Delay deleting the temp files until GnuPG exits.
> 
> This is a known problem with 1.0.7 (1.0.7 was never really intended
> for widespread Win32 use).  Until 1.0.8 is released with a
> non-system()-based implementation of the exec code, you have a few
> options:
> 
> 1) Patch the code based on the CVS
> 2) Use %I instead of %i in your photo-viewer command line
> 3) Try a photo-viewer of "start /w %i.jpg"
> 
> (#3 should work but I haven't tested it - I'm traveling and have no
> access to a windows box at the moment)

Hmm, I should have been more explicit on my setup ;)  I was using 1.0.7a-cvs
from May 24.  The photo viewer was the default:

#define DEFAULT_PHOTO_COMMAND "start /w %i"

Mozilla is the default .jpg viewer.   For some reason, execution returns to
GnuPG immediately after launching Mozilla.  Mozilla does not finish loading
itself and then the picture before GnuPG deletes the temporary directory and
file.  Thus, solution #3 isn't working.

Unless there is a way to modify the "start" command to actually wait when
launching an object file instead of an executable, I think the best route would
be to read the registry to find the default viewer and then "start" that.

I will code up a patch against CVS and e-mail it to you when I'm done.

  -- Keith


From wk@gnupg.org  Tue May 28 12:33:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Tue May 28 11:33:01 2002
Subject: Photo ID race condition
In-Reply-To: <1022550003.3cf2dff3e2115@mail.nullify.org> (Keith Ray's
 message of "Mon, 27 May 2002 20:40:03 -0500")
References: <1022518490.3cf264daeba39@mail.nullify.org>
 <20020527223655.GB813@akamai.com>
 <1022550003.3cf2dff3e2115@mail.nullify.org>
Message-ID: <87elfwlim1.fsf@alberti.gnupg.de>

On Mon, 27 May 2002 20:40:03 -0500, Keith Ray said:

> Unless there is a way to modify the "start" command to actually wait when
> launching an object file instead of an executable, I think the best route would
> be to read the registry to find the default viewer and then "start" that.

> I will code up a patch against CVS and e-mail it to you when I'm done.

You better write a wrapper taking care of of starting the default
image viewer and deleting the temporary file.  I don't think it is a
good idea to add this extra code to gpg.


Shalom-Salam,

   Werner



From wagner@tik.ee.ethz.ch  Wed May 29 07:27:01 2002
From: wagner@tik.ee.ethz.ch (wagner@tik.ee.ethz.ch)
Date: Wed May 29 06:27:01 2002
Subject: Mail delivery failed
Message-ID: <200205290427.GAA04870@tik2.ethz.ch>

The mail system has received a message appearently from you
that had the following header fields:

    From:     gnupg-devel-request@gnupg.org
    Subject:  Gnupg-devel digest, Vol 1 #373 - 2 msgs
    To:       gnupg-devel@gnupg.org
    Date:     Wed, 29 May 2002 06:25:43 +0200

The message has been deleted automatically for the following reason:

SPAM detected. Mail dropped.


This message has been generated automatically.


------------------------------------------------------------------------------
Arno Wagner           Dipl. Inform.          wagner@tik.ee.ethz.ch
 A modern US Navy cruiser now requires 26 tons of manuals. This is enough to 
 affect the vessel's performance. -- New Scientist on the paperless office
 
 Spam will get you reported to your ISP. I explicitely forbid you 
 to store my email address for purpose of reselling or spamming. 
 


From aphex@nullify.org  Thu May 30 06:00:03 2002
From: aphex@nullify.org (Keith Ray)
Date: Thu May 30 05:00:03 2002
Subject: Bug in parse_one_sig_subpkt ?
Message-ID: <1022727633.3cf595d1916a9@mail.nullify.org>

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

I think I have found a bug in the latest GnuPG v1.0.7a-cvs
(29-May-2002).  When generating a new keypair, build_sig_subpkt() calls
parse_one_sig_subpkt() with a type of SIGSUBPKT_KS_FLAGS.  Since there
is no 'case' for SIGSUBPKT_KS_FLAGS, parse_one_sig_subpkt() returns -1
and GnuPG fails.

  -- Keith

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7a-nr1 (Windows 2000) - GPGshell v2.30

iD8DBQE89ZWIBxrjkHkmmhIRAhvJAKCJweZVl8dt6muA4GBNZwVagmHd2gCdGQ5G
+MrsxTOmFINxe7ek6/MoVH0=
=FJc2
-----END PGP SIGNATURE-----


From dshaw@jabberwocky.com  Thu May 30 06:32:02 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Thu May 30 05:32:02 2002
Subject: Bug in parse_one_sig_subpkt ?
In-Reply-To: <1022727633.3cf595d1916a9@mail.nullify.org>
References: <1022727633.3cf595d1916a9@mail.nullify.org>
Message-ID: <20020530033209.GC6908@akamai.com>

On Wed, May 29, 2002 at 10:00:33PM -0500, Keith Ray wrote:

> I think I have found a bug in the latest GnuPG v1.0.7a-cvs
> (29-May-2002).  When generating a new keypair, build_sig_subpkt() calls
> parse_one_sig_subpkt() with a type of SIGSUBPKT_KS_FLAGS.  Since there
> is no 'case' for SIGSUBPKT_KS_FLAGS, parse_one_sig_subpkt() returns -1
> and GnuPG fails.

Fixed.  Thank you.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From keith@nullify.org  Thu May 30 12:00:01 2002
From: keith@nullify.org (Keith Ray)
Date: Thu May 30 11:00:01 2002
Subject: Bug in parse_one_sig_subpkt ?
Message-ID: <1022727578.3cf5959a34c68@mail.nullify.org>

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

I think I have found a bug in the latest GnuPG v1.0.7a-cvs
(29-May-2002).  When generating a new keypair, build_sig_subpkt() calls
parse_one_sig_subpkt() with a type of SIGSUBPKT_KS_FLAGS.  Since there
is no 'case' for SIGSUBPKT_KS_FLAGS, parse_one_sig_subpkt() returns -1
and GnuPG fails.

  -- Keith

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7a-nr1 (Windows 2000) - GPGshell v2.30

iD8DBQE89ZWIBxrjkHkmmhIRAhvJAKCJweZVl8dt6muA4GBNZwVagmHd2gCdGQ5G
+MrsxTOmFINxe7ek6/MoVH0=
=FJc2
-----END PGP SIGNATURE-----


From wagner@tik.ee.ethz.ch  Thu May 30 12:01:01 2002
From: wagner@tik.ee.ethz.ch (wagner@tik.ee.ethz.ch)
Date: Thu May 30 11:01:01 2002
Subject: Mail delivery failed
Message-ID: <200205300902.LAA17729@tik2.ethz.ch>

The mail system has received a message appearently from you
that had the following header fields:

    From:     gnupg-devel-request@gnupg.org
    Subject:  Gnupg-devel digest, Vol 1 #374 - 3 msgs
    To:       gnupg-devel@gnupg.org
    Date:     Thu, 30 May 2002 06:25:43 +0200

The message has been deleted automatically for the following reason:

SPAM detected. Mail dropped.


This message has been generated automatically.


------------------------------------------------------------------------------
Arno Wagner           Dipl. Inform.          wagner@tik.ee.ethz.ch
 A modern US Navy cruiser now requires 26 tons of manuals. This is enough to 
 affect the vessel's performance. -- New Scientist on the paperless office
 
 Spam will get you reported to your ISP. I explicitely forbid you 
 to store my email address for purpose of reselling or spamming. 
 


From denis@ripe.net  Thu May 30 12:11:01 2002
From: denis@ripe.net (Denis Walker)
Date: Thu May 30 11:11:01 2002
Subject: dry run
Message-ID: <200205300908.g4U98NA09988@birch.ripe.net>

Hi guys

The man pages and your on line docs both say that dry run is not yet fully 
implemented. What does this mean? Can I safely use dry run to check the 
response before doing the changes?

cheers
denis



From denis@ripe.net  Thu May 30 12:16:01 2002
From: denis@ripe.net (Denis Walker)
Date: Thu May 30 11:16:01 2002
Subject: dry run
Message-ID: <200205300916.g4U9GlA14641@birch.ripe.net>

Hi guys

The man pages and your on line docs both say that dry run is not yet fully 
implemented. What does this mean? Can I safely use dry run to check the 
response before doing the changes?

cheers
denis





From wk@gnupg.org  Thu May 30 12:21:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Thu May 30 11:21:01 2002
Subject: Mail delivery failed
In-Reply-To: <200205300902.LAA17729@tik2.ethz.ch> (wagner@tik.ee.ethz.ch's
 message of "Thu, 30 May 2002 11:02:08 +0200 (MET DST)")
References: <200205300902.LAA17729@tik2.ethz.ch>
Message-ID: <87n0uif0ob.fsf@alberti.gnupg.de>

Hi!

I disapled you account until you get your spam "reporting" tool
right.  I'd suggest to remove it entirely because automated spam
reporting does more harm than real spam.


Shalom-Salam,

   Werner



From chris@netservers.co.uk  Thu May 30 12:44:02 2002
From: chris@netservers.co.uk (Chris Wilson)
Date: Thu May 30 11:44:02 2002
Subject: Mail delivery failed
In-Reply-To: <200205300902.LAA17729@tik2.ethz.ch>
Message-ID: <Pine.LNX.4.44.0205301043500.30283-100000@localhost>

Dear Wagner,

If you are going to treat this list as spam, would you please unsubscribe?

Cheers, Chris.

On Thu, 30 May 2002 wagner@tik.ee.ethz.ch wrote:

> The mail system has received a message appearently from you
> that had the following header fields:
> 
>     From:     gnupg-devel-request@gnupg.org
>     Subject:  Gnupg-devel digest, Vol 1 #374 - 3 msgs
>     To:       gnupg-devel@gnupg.org
>     Date:     Thu, 30 May 2002 06:25:43 +0200
> 
> The message has been deleted automatically for the following reason:
> 
> SPAM detected. Mail dropped.
> 
> 
> This message has been generated automatically.
> 
> 
> ------------------------------------------------------------------------------
> Arno Wagner           Dipl. Inform.          wagner@tik.ee.ethz.ch
>  A modern US Navy cruiser now requires 26 tons of manuals. This is enough to 
>  affect the vessel's performance. -- New Scientist on the paperless office
>  
>  Spam will get you reported to your ISP. I explicitely forbid you 
>  to store my email address for purpose of reselling or spamming. 
>  
> 
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
> 

-- 
   ___ __     _
 / __// / ,__(_)_  | Chris Wilson -- UNIX Firewall Lead Developer |
/ (_ / ,\/ _/ /_ \ | NetServers.co.uk http://www.netservers.co.uk |
\ _//_/_/_//_/___/ | 21 Signet Court, Cambridge, UK. 01223 576516 |



From denis@ripe.net  Thu May 30 14:47:01 2002
From: denis@ripe.net (Denis Walker)
Date: Thu May 30 13:47:01 2002
Subject: deleting a uid from a public key
Message-ID: <200205301148.g4UBmSA28404@birch.ripe.net>

Hi guys

According to your manual you can delete a uid from your local public key. But 
if someone else imports your key it merges the uids from the old and new keys. 
So the deletion does not take effect. The manual says in order to delete a uid 
from someone's public key you must first remove the key and them import the 
new key. Why does import not delete uids? Are there any security implications 
involved here? If I am updating keys should I always remove the key first and 
them import the new one?

cheers
denis



From dshaw@jabberwocky.com  Thu May 30 15:23:01 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Thu May 30 14:23:01 2002
Subject: deleting a uid from a public key
In-Reply-To: <200205301148.g4UBmSA28404@birch.ripe.net>
References: <200205301148.g4UBmSA28404@birch.ripe.net>
Message-ID: <20020530122316.GE6908@akamai.com>

On Thu, May 30, 2002 at 01:48:28PM +0200, Denis Walker wrote:
> Hi guys
> 
> According to your manual you can delete a uid from your local public
> key. But if someone else imports your key it merges the uids from
> the old and new keys.  So the deletion does not take effect. The
> manual says in order to delete a uid from someone's public key you
> must first remove the key and them import the new key. Why does
> import not delete uids? Are there any security implications involved
> here? If I am updating keys should I always remove the key first and
> them import the new one?

As you saw, deleting a uid does not really delete it - it will come
back when the key is merged with an earlier copy of itself.  There are
several reasons for this, the simplest being: how does GnuPG know
which is the "more recent" key?  For example, if I have a key with 3
uids, and I import the same key with 2 uids, does that mean that one
of the uids is to be deleted (the 2 uid version is newer) or should I
do nothing (the 3 uid version is newer).

To resolve this, OpenPGP allows a user to revoke a uid - a revoked uid
is present on the key but is not used.  If you have a uid that you
don't want to use any longer, use "revsig" to revoke the
self-signature on that uid.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From stephane@sente.ch  Thu May 30 19:11:02 2002
From: stephane@sente.ch (=?ISO-8859-1?Q?St=E9phane_Corth=E9sy?=)
Date: Thu May 30 18:11:02 2002
Subject: charset problem
Message-ID: <07E6337B-73E8-11D6-B149-0003936A3BE2@sente.ch>

Hi,

Is the following behavior correct?

The file ~/.gnupg/options contains an option "comment" with value "=E9=20=

eacute"; file has been saved using UTF8 encoding.
The file /tmp/test contains same text "=E9 eacute", but in iso-8859-1.

Performing the command

gpg --charset iso-8859-1 --clearsign /tmp/test

creates a new file /tmp/test.asc which contains invalid text: there is a=20=

mix of iso-8859-1 (for the body) and UTF8 (for the signature) charsets!

It seems that comment is copied as is, i.e. not converted to --charset=20=

(what is furthermore not always possible...), thus result is totally=20
unreadable.


(I'm working with GnuPG 1.0.7 on MacOS X 10.1.4.)

Cheers,

St=E9phane



From stephane@sente.ch  Thu May 30 19:23:02 2002
From: stephane@sente.ch (=?ISO-8859-1?Q?St=E9phane_Corth=E9sy?=)
Date: Thu May 30 18:23:02 2002
Subject: malloc problem
Message-ID: <A5359632-73E9-11D6-B149-0003936A3BE2@sente.ch>

Hi,

Running gpg 1.0.7 on MacOS X 10.1.4, I noticed a malloc problems. I type=20=

the following command:

gpg --debug 511 --charset utf-8 --no-force-v3-sigs --armor=20
--notation-data mycode=3Dmyvalue --clearsign

Then I enter my passphrase, the text to sign ("test") and CTRL-D, and=20
there is a (MacOS X specific) malloc warning. Can anyone reproduce the=20=

problem on another system having a malloc-protection too (guard pages)?
Problem is due to the notation-data presence.

Cheers,

St=E9phane

... [snipped]...
gpg: DBG: iobuf-7.0: underflow: eof
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

test
gpg: DBG: armor-filter: control: 5
gpg: DBG: iobuf-8.1: push `armor_filter'
gpg: DBG: armor-filter: control: 5
gpg: DBG: iobuf chain: 8.1 `armor_filter' filter_eof=3D0 start=3D0 len=3D0=

gpg: DBG: iobuf chain: 8.0 `file_filter(fd)' filter_eof=3D0 start=3D0 =
len=3D0
gpg: DBG: armor-filter: control: 1
*** malloc[4606]: Deallocation of a pointer not malloced: 0x20d2ff; This=20=

could be a double free(), or free() called with the middle of an=20
allocated block; Try setting environment variable MallocHelp to see=20
tools to help debug
gpg: DBG: mpi_alloc(160)
gpg: DBG: mpi_alloc_limb_space(160)
gpg: DBG: pubkey_sign: algo=3D17
...[snipped]...






From dshaw@jabberwocky.com  Thu May 30 20:14:01 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Thu May 30 19:14:01 2002
Subject: malloc problem
In-Reply-To: <A5359632-73E9-11D6-B149-0003936A3BE2@sente.ch>
References: <A5359632-73E9-11D6-B149-0003936A3BE2@sente.ch>
Message-ID: <20020530171410.GG6908@akamai.com>

On Thu, May 30, 2002 at 06:23:59PM +0200, St=E9phane Corth=E9sy wrote:
> Hi,
>=20
> Running gpg 1.0.7 on MacOS X 10.1.4, I noticed a malloc problems. I typ=
e=20
> the following command:
>=20
> gpg --debug 511 --charset utf-8 --no-force-v3-sigs --armor=20
> --notation-data mycode=3Dmyvalue --clearsign
>=20
> Then I enter my passphrase, the text to sign ("test") and CTRL-D, and=20
> there is a (MacOS X specific) malloc warning. Can anyone reproduce the=20
> problem on another system having a malloc-protection too (guard pages)?
> Problem is due to the notation-data presence.

This was already fixed.  Thanks for the report though. :)

David

--=20
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.co=
m/
+------------------------------------------------------------------------=
---+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From Marc.Mutz@uni-bielefeld.de  Fri May 31 01:10:02 2002
From: Marc.Mutz@uni-bielefeld.de (Marc Mutz)
Date: Fri May 31 00:10:02 2002
Subject: charset problem
In-Reply-To: <07E6337B-73E8-11D6-B149-0003936A3BE2@sente.ch>
References: <07E6337B-73E8-11D6-B149-0003936A3BE2@sente.ch>
Message-ID: <200205302342.29857@sendmail.mutz.com>

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 30 May 2002 18:12, St=E9phane Corth=E9sy wrote:
<snip>
> Is the following behavior correct?
>
> The file ~/.gnupg/options contains an option "comment" with value "=E9
> eacute"; file has been saved using UTF8 encoding.
> The file /tmp/test contains same text "=E9 eacute", but in iso-8859-1.
<snip>

The answer is simple: Don't use --comment with anything but US-ASCII=20
characters. Comment: is an _ASCII_ armor header. This name alone should=20
tell you why what you try is a bad idea.

Marc

=2D --=20
Marc Mutz <mutz@kde.org>
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE89pzE3oWD+L2/6DgRAn+HAJ4shlewFxf/3RFi2N69npX00Y/6WgCeJ0Xw
VTtAi1qZpPOMjlW9Fv2cuvg=3D
=3Du6/t
=2D----END PGP SIGNATURE-----



From keith@nullify.org  Fri May 31 07:52:01 2002
From: keith@nullify.org (Keith Ray)
Date: Fri May 31 06:52:01 2002
Subject: Photo ID viewer under Windows NT
Message-ID: <1022820757.3cf701952790a@mail.nullify.org>

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

I just tried the new method of calling the Photo ID viewer under
Windows.  Unfortunately, unlike system(), CreateProcess() does not get
interpretted through the system shell.  This means that only actual
executables can be run in CreateProcess(), not internal commands.  In
Windows 95/98/Me, "start" is actually start.exe.  Under Windows
NT/2k/XP, "start" is integrated into the shell and CreateProcess() fails
with "No such file or directory".  

You can still use CreateProcess() under NT, but you need to call:

cmd /c start /w %i

However, since 95 uses command.com instead of cmd.exe, this would fail
for those versions.

  -- Keith

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7a-nr1 (Windows 2000) - GPGshell v2.30

iD8DBQE89wGIBxrjkHkmmhIRAgckAJ0UrGhnSBGGEDXw12DHnkTKN07sKgCgidHE
Tu6W6+BlfQo4DoWHfV+YZ5I=
=vjL8
-----END PGP SIGNATURE-----


From dshaw@jabberwocky.com  Fri May 31 08:53:01 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Fri May 31 07:53:01 2002
Subject: Photo ID viewer under Windows NT
In-Reply-To: <1022820757.3cf701952790a@mail.nullify.org>
References: <1022820757.3cf701952790a@mail.nullify.org>
Message-ID: <20020531055358.GB2126@akamai.com>

On Thu, May 30, 2002 at 11:52:37PM -0500, Keith Ray wrote:

> I just tried the new method of calling the Photo ID viewer under
> Windows.  Unfortunately, unlike system(), CreateProcess() does not get
> interpretted through the system shell.  This means that only actual
> executables can be run in CreateProcess(), not internal commands.  In
> Windows 95/98/Me, "start" is actually start.exe.  Under Windows
> NT/2k/XP, "start" is integrated into the shell and CreateProcess() fails
> with "No such file or directory".  
> 
> You can still use CreateProcess() under NT, but you need to call:
> 
> cmd /c start /w %i
> 
> However, since 95 uses command.com instead of cmd.exe, this would fail
> for those versions.

So use the longer form?  I'm not sure what you're getting at
here. "start /w" doesn't work on NT, but neither does qiv or
xloadimage or any other other of the sample viewers.  The whole point
of the photo-viewer option is to set what viewer works for YOU and not
hard-code something in that may not work (or may work but not be what
you wanted: using "start" to read the registry doesn't work very well
if your .jpg viewer is photoshop, for example).

It's possible to use some conditional #defines to change the default
viewer at build time, but to what end?  Most people don't compile
their own win32 binary, and this would make the NT/2k/XP binary
different than 95/98/Me.

Remember: "start /w" is only the default.  If you don't like it (or if
it doesn't work on your system), change it.

If you're arguing that the default should be "cmd /c start /w", then
maybe - but it'll break the default for the 95/98/Me people.  I have
no strong feelings on which platform gets the 'better' default.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From avbidder@fortytwo.ch  Fri May 31 11:42:01 2002
From: avbidder@fortytwo.ch (Adrian 'Dagurashibanipal' von Bidder)
Date: Fri May 31 10:42:01 2002
Subject: charset problem
In-Reply-To: <200205302342.29857@sendmail.mutz.com>
References: <07E6337B-73E8-11D6-B149-0003936A3BE2@sente.ch>
 <200205302342.29857@sendmail.mutz.com>
Message-ID: <1022834611.25778.32.camel@atlas>

--=-O8C6NegOgiq8lsGL6BBq
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Thu, 2002-05-30 at 23:42, Marc Mutz wrote:

> The answer is simple: Don't use --comment with anything but US-ASCII=20
> characters. Comment: is an _ASCII_ armor header. This name alone should=20
> tell you why what you try is a bad idea.

Just curious: is there anything said (rfc, developer opinion, ...) about
the =3D?charset?x?encoded string?=3D encoding in armor headers?

cheers
-- vbi


--=20
secure email with gpg            avbidder@fortytwo.ch: key id 0x92082481
                                 avbidder@acter.ch:    key id 0x5E4B731F


--=-O8C6NegOgiq8lsGL6BBq
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA89zezwj49sl5Lcx8RAvYUAKCNXgrMfyRIItVFSOIuC1PKww+fOACfQX7S
wDFoRgb5SEIRFcwhIVXR+I8=
=HUba
-----END PGP SIGNATURE-----

--=-O8C6NegOgiq8lsGL6BBq--



From chris@netservers.co.uk  Fri May 31 12:02:01 2002
From: chris@netservers.co.uk (Chris Wilson)
Date: Fri May 31 11:02:01 2002
Subject: Batch mode
Message-ID: <Pine.LNX.4.44.0205301744240.30657-100000@localhost>

Hi all,

There are a number of operations which are not currently supported in 
batch mode. They include:

- key generation
- key signing
- key deletion

I would be happy to write patches to add this functionality, but my past 
e-mails, suggestions and patches sent to this list have been completely 
ignored. Therefore, I will probably not write the patches unless somebody 
says they are interested. So please tell me if you are.

Cheers, Chris.
-- 
   ___ __     _
 / __// / ,__(_)_  | Chris Wilson -- UNIX Firewall Lead Developer |
/ (_ / ,\/ _/ /_ \ | NetServers.co.uk http://www.netservers.co.uk |
\ _//_/_/_//_/___/ | 21 Signet Court, Cambridge, UK. 01223 576516 |



From wk@gnupg.org  Fri May 31 13:47:02 2002
From: wk@gnupg.org (Werner Koch)
Date: Fri May 31 12:47:02 2002
Subject: charset problem
In-Reply-To: <1022834611.25778.32.camel@atlas> (Adrian 'Dagurashibanipal'
 von Bidder's message of "31 May 2002 10:43:31 +0200")
References: <07E6337B-73E8-11D6-B149-0003936A3BE2@sente.ch>
 <200205302342.29857@sendmail.mutz.com>
 <1022834611.25778.32.camel@atlas>
Message-ID: <87bsawd1yj.fsf@alberti.gnupg.de>

On 31 May 2002 10:43:31 +0200, Adrian 'Dagurashibanipal' von Bidder said:

> Just curious: is there anything said (rfc, developer opinion, ...) about
> the =?charset?x?encoded string?= encoding in armor headers?

No.  Please don't use the comment for any real purpose - this is just
a gadget with no real use.  If you want to encode other information
you should either use notation data (which is included in the
signature) or use MIME headers for that.  As you know, the Comment and
all other armor headers are not protected by the signature.


Salam-Shalom,

   Werner





From wagner@tik.ee.ethz.ch  Fri May 31 13:52:01 2002
From: wagner@tik.ee.ethz.ch (Arno Wagner)
Date: Fri May 31 12:52:01 2002
Subject: Me "spamming" this list...
In-Reply-To: <E17DdzF-0005CF-00@trithemius.gnupg.org>; from gnupg-devel-request@gnupg.org on Fri, May 31, 2002 at 06:25:42AM +0200
References: <E17DdzF-0005CF-00@trithemius.gnupg.org>
Message-ID: <20020531125315.B10807@tik.ee.ethz.ch>

--n8g4imXOkfNTN/H1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Dear gnupg-devel list members,

in the last 48 hours (or so) this list has received messages
from my spam-detector about spam being dropped.=20

I am sorry about this, please accept my apology!

I think I should explain what happened, so maybe others can=20
avoid the mistakes I made: I have a very manual spam filter,
that I maintain by just adding to my .procmailrc. For hard spammers
I just drop the mail, for others I had an auto-reply feature.=20
While I was careful all my receipes are restrictive enough not
to be overly trigger-happy, I did not take into account the
possibility for a different kind of error.=20

What I effectively did in one match-expression whas replace the
leading "*" with a "$". As a result this rule appearently matched for
every Email that came in. As a consequence every email to me got a
notification about it being spam and dropped, which also happened to
all the messages telling me there was something wrong on my side.

To make things worse, we had an announced partial network outage=20
on Wednsday (routing tables cleanup) so I was not suspicous about
not getting any email. I was not at work on Wednsday, so I=20
finally found out about the problem when somebody phoned me
Thursday morning.=20

At that time I had about 30 messages telling me about the problem
and about 400 Messages from a mail-loop, that happened despite=20
my measures to prevent loops.

Lessons learned on my side:

  - Don't send out automatic responses to, if the trigger-
    mechanism has a single point-of-failure!

    For the time being I make that: Don't send out any automated
    responses.=20

  - Doing full logging is a very good idea when automatically=20
    deleting messages! =20

    Because I at least got this right, I did not loose any=20
    messages and was able to identify everybody that I needed to
    apologize to.

  - If you screw up, apologize a.s.a.p. to those affected and
    explain what happened!    =20

  - Look at statistics frequently!=20

    My previous set-up gave me one spam-summary per week. That is=20
    not enough, now I am getting a daily summary. =20

  - Make sure you understand the problem!=20

    My mail-loop detection scheme used a field in the header with=20
    a magic number. That is fine for every loop that keeps the=20
    auto-response somewhere in the replys, but this one list-admin=20
    daemon just send me a completely fresh email about not=20
    understanding my command. Practical loop detection is obviously
    more complicated than I thought ....

Once again, please accept my apologies for this incident!

Regards,
Arno

--=20
Arno Wagner, Communication Systems Group, ETH Zuerich, wagner@tik.ee.ethz.ch
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
For every complex problem there is an answer that is clear, simple,=20
and wrong. -- H L Mencken





--n8g4imXOkfNTN/H1
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iEYEARECAAYFAjz3VhsACgkQeX9rUB4lM48uLQCghU0zkyXRytpzgoX4B0msXvw2
fIgAn1thxK02W4Ge0jlImr5nVYRRjP88
=tPIM
-----END PGP SIGNATURE-----

--n8g4imXOkfNTN/H1--


From wk@gnupg.org  Fri May 31 13:53:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Fri May 31 12:53:01 2002
Subject: Batch mode
In-Reply-To: <Pine.LNX.4.44.0205301744240.30657-100000@localhost> (Chris
 Wilson's message of "Fri, 31 May 2002 10:02:13 +0100 (BST)")
References: <Pine.LNX.4.44.0205301744240.30657-100000@localhost>
Message-ID: <877klkd1qb.fsf@alberti.gnupg.de>

On Fri, 31 May 2002 10:02:13 +0100 (BST), Chris Wilson said:

> Hi all,
> There are a number of operations which are not currently supported in 
> batch mode. They include:

> - key generation

There is batch ke generation - see doc/DETAILS.

> - key signing
> - key deletion

This can't be done easily.  You need to present a lot of information
to the user so that he can decide wehther to sign or not.  Those
information vary from key to key and thus it can't be scripted.

We are working on a GPGME interface to do ease it up.  You may have
noticed problems with GPA when you don't use a standard key or use gpg
1.0.7.  This is due to a too simple approach to handle these
operations.

> I would be happy to write patches to add this functionality, but my past 
> e-mails, suggestions and patches sent to this list have been
> completely 

Sorry, That happens from time to time.  There is also the issue that
we need legal papers to include non-trivial patches.


Shalom-Salam,

   Werner



From chris@netservers.co.uk  Fri May 31 14:17:01 2002
From: chris@netservers.co.uk (Chris Wilson)
Date: Fri May 31 13:17:01 2002
Subject: Batch mode
In-Reply-To: <877klkd1qb.fsf@alberti.gnupg.de>
Message-ID: <Pine.LNX.4.44.0205311209080.30657-100000@localhost>

Hi Werner and the list,

> There is batch ke generation - see doc/DETAILS.

Sorry, my bad. This looks like what I need.

> This can't be done easily.  You need to present a lot of information
> to the user so that he can decide wehther to sign or not.  Those
> information vary from key to key and thus it can't be scripted.

In our environment the key is generated and immediately imported 
into another keyring and signed. There is no need to verify the identity 
of the key, etc. So it would be very useful for us to be able to sign 
automatically.

What objection is there to batch key deletion?

> We are working on a GPGME interface to do ease it up.  You may have
> noticed problems with GPA when you don't use a standard key or use gpg
> 1.0.7.  This is due to a too simple approach to handle these
> operations.

OK, but from what little I know of GPGME right now, it seems to be a 
powerful and complex API to using GPG. I don't need that, and it's not 
helpful for shell scripts. I just need to be able to automate the commands 
which I can give from the command line anyway.

> Sorry, That happens from time to time.  There is also the issue that
> we need legal papers to include non-trivial patches.

I am about to send in my papers to the FSF for some work I've done on Tar, 
but in any case I think these patches will be small enough that they 
shouldn't pose a legal problem for you. But I leave that to your 
discretion.

Ciao, Chris.
-- 
   ___ __     _
 / __// / ,__(_)_  | Chris Wilson -- UNIX Firewall Lead Developer |
/ (_ / ,\/ _/ /_ \ | NetServers.co.uk http://www.netservers.co.uk |
\ _//_/_/_//_/___/ | 21 Signet Court, Cambridge, UK. 01223 576516 |



From win@huh.org  Wed May  1 00:25:01 2002
From: win@huh.org (Winona Brown)
Date: Tue Apr 30 23:25:01 2002
Subject: AIX bug malloc(0)
Message-ID: <20020430212626.GA1048@arghh.huh.org>

make with aix5.1 compiler vac5 (xlc) was failing in checks until I added 
   if (n == 0)
       n = 1;
before calling malloc.

The technical reference for AIX 5L 5.1 says:

If the malloc or valloc subroutine is called with a size of 0, the subroutine
returns a null pointer

The better way to fix this would probably be to allow a NULL being returned
if malloc(0) was called.  

gnupg-1.0.7/util/memory.c

Winona



From redbird@rbisland.cx  Wed May  1 08:38:01 2002
From: redbird@rbisland.cx (Gordon Worley)
Date: Wed May  1 07:38:01 2002
Subject: gnupg 107 compilation on solaris 8
In-Reply-To: <200204301744.KAA00577@fionn.es.net>
Message-ID: <CB457866-5CC5-11D6-BDCA-000A27B4DEFC@rbisland.cx>

On Tuesday, April 30, 2002, at 01:44  PM, Michael Helm wrote:

>> ./configure --enable-static-rnd=unix
>
> Had exactly the same effect -- option apparently doesn't work

Trying throwing --disable-dynload into the mix.

--
Gordon Worley                     `When I use a word,' Humpty Dumpty
http://www.rbisland.cx/            said, `it means just what I choose
redbird@rbisland.cx                it to mean--neither more nor less.'
PGP:  0xBBD3B003                                  --Lewis Carroll



From BigBootyHoe69699@aol.com  Wed May  1 11:02:01 2002
From: BigBootyHoe69699@aol.com (BigBootyHoe69699@aol.com)
Date: Wed May  1 10:02:01 2002
Subject: Free Trail!! NO FEES!
Message-ID: <200204302358.DAA09114@cobi.coqui.net>

Mail from  (BigBootyHoe69699@aol.com) 
     on Wednesday, May 1, 2002 at 03:58:50
---------------------------------------------------------------------------

:: RIGHT NOW!  FREE Membership Available!  Don't know how long this offer will last, get it while you still can! We have BEAUTIFUL girls and they are just one click away from showing you the BEST time of your life! <a href="http://rd.yahoo.com/dir/?http://members.lycos.co.uk/g00dstuff">Click here</a>

---------------------------------------------------------------------------
A Service of Coqui.Net             bug-octave-request@bevo.che.utexas.edu,bug-octave@bevo.che.utexas.edu,help-octave-request@bevo.che.utexas.edu,help-octave@bevo.che.utexas.edu,announce-request@gnupg.org,gnupg-users-request@gnupg.org,gnupg-users@gnupg.org,gnupg-devel-request@gnupg.org,gnupg-devel@gnupg.org,bug-bison-request@gnu.org,


From BigBootyHoe69699@aol.com  Wed May  1 11:11:02 2002
From: BigBootyHoe69699@aol.com (BigBootyHoe69699@aol.com)
Date: Wed May  1 10:11:02 2002
Subject: Free Trail!! NO FEES!
Message-ID: <200205010008.EAA09698@cobi.coqui.net>

Mail from  (BigBootyHoe69699@aol.com) 
     on Wednesday, May 1, 2002 at 04:08:08
---------------------------------------------------------------------------

:: RIGHT NOW!  FREE Membership Available!  Don't know how long this offer will last, get it while you still can! We have BEAUTIFUL girls and they are just one click away from showing you the BEST time of your life! <a href="http://rd.yahoo.com/dir/?http://members.lycos.co.uk/g00dstuff">Click here</a>

---------------------------------------------------------------------------
A Service of Coqui.Net             bug-octave-request@bevo.che.utexas.edu,bug-octave@bevo.che.utexas.edu,help-octave-request@bevo.che.utexas.edu,help-octave@bevo.che.utexas.edu,announce-request@gnupg.org,gnupg-users-request@gnupg.org,gnupg-users@gnupg.org,gnupg-devel-request@gnupg.org,gnupg-devel@gnupg.org,bug-bison-request@gnu.org,


From hideki@allcity.net  Thu May  2 03:26:02 2002
From: hideki@allcity.net (Hideki Saito)
Date: Thu May  2 02:26:02 2002
Subject: 15MB files on photo
Message-ID: <200205020026.g420Qli28732@server-1.visp.net>

I found some problem with photo capability of 1.0.7 on Win32 
compilation.

If you try to display graphics, it is actually a bogus JPG file.

I have tried with the option i_view32 %i as a photo-viewer argument, 
and it returns "unknown header" error.

Then I tried i_view32 %I to see what actual "TEMP.JPG" is like, and it 
turns out be a 12MB - 15MB garbage file.

Is there any workaround to this?

-- 
Hideki Saito mailto:hideki@allcity.net


From dshaw@jabberwocky.com  Thu May  2 03:50:02 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Thu May  2 02:50:02 2002
Subject: 15MB files on photo
In-Reply-To: <200205020026.g420Qli28732@server-1.visp.net>
References: <200205020026.g420Qli28732@server-1.visp.net>
Message-ID: <20020502005106.GA25856@akamai.com>

On Wed, May 01, 2002 at 05:27:42PM -0700, Hideki Saito wrote:
> I found some problem with photo capability of 1.0.7 on Win32 
> compilation.
> 
> If you try to display graphics, it is actually a bogus JPG file.
> 
> I have tried with the option i_view32 %i as a photo-viewer argument, 
> and it returns "unknown header" error.
> 
> Then I tried i_view32 %I to see what actual "TEMP.JPG" is like, and it 
> turns out be a 12MB - 15MB garbage file.

Hmm.  Are you using a Mingw32 or Cygwin build?

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From hideki@allcity.net  Thu May  2 05:04:02 2002
From: hideki@allcity.net (Hideki Saito)
Date: Thu May  2 04:04:02 2002
Subject: 15MB files on photo
In-Reply-To: <20020502005106.GA25856@akamai.com>
References: <200205020026.g420Qli28732@server-1.visp.net>
 <20020502005106.GA25856@akamai.com>
Message-ID: <200205020205.g4225Fi03599@server-1.visp.net>

Mingw32 build it is...

>On Wed, May 01, 2002 at 05:27:42PM -0700, Hideki Saito wrote:
>> I found some problem with photo capability of 1.0.7 on Win32 
>> compilation.
>> 
>> If you try to display graphics, it is actually a bogus JPG file.
>> 
>> I have tried with the option i_view32 %i as a photo-viewer argument, 
>> and it returns "unknown header" error.
>> 
>> Then I tried i_view32 %I to see what actual "TEMP.JPG" is like, and it 
>> turns out be a 12MB - 15MB garbage file.
>
>Hmm.  Are you using a Mingw32 or Cygwin build?
>
>David
>
>-- 
>   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
>+---------------------------------------------------------------------------+
>   "There are two major products that come out of Berkeley: LSD and UNIX.
>      We don't believe this to be a coincidence." - Jeremy S. Anderson
>
>_______________________________________________
>Gnupg-devel mailing list
>Gnupg-devel@gnupg.org
>http://lists.gnupg.org/mailman/listinfo/gnupg-devel

-- 
Hideki Saito mailto:hideki@allcity.net


From mwy-gpg41@the-youngs.org  Thu May  2 06:43:01 2002
From: mwy-gpg41@the-youngs.org (Michael Young)
Date: Thu May  2 05:43:01 2002
Subject: feature request: always-trust [<keyring>]
References: <E172PDG-0002qc-00@trithemius.gnupg.org>
Message-ID: <003d01c1f18b$83100d60$c23fa8c0@transarc.ibm.com>

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

Jeff Breidenbach <jab@debian.org> asked for:
> What: ability to specify that everything in a specific
>       keyring will trusted by default.

This sounds like a reasonable request to me.  As you note, there
is already an "--always-trust" switch -- it's just global.
But I'm not one of the people you need to convince.

> Why:  In Debian, I can have a list of hundreds of developer=20
>       keys stored  in locally in /usr/share/keyrings/debian-keyring.gpg.
>       This file is trusted by me, dynamic, and is maintained by the
>       Debian Project. So I use the file as one of my keyrings.

I know you didn't ask for workarounds, but in case your request
isn't filled in a timely manner...

Could you convince whoever is maintaining the keyring to sign the keys
using some well-known "Debian Project" key?  Then, you could use the
existing trust mechanisms (up to and including the "--trusted-key"
switch).  This would also let you (or others) pick up keys from
keyservers, rather than rely purely on secure delivery of the shared
keyring file.

Failing that, you could automatically generate (local) signatures for
everything on the trusted keyring.  I would use a local key specific
to this purpose.  This requires some trickery: the "--batch" switch
disallows signing; the "--yes" switch has no effect.  It seems that
you need to use the "--command-fd" gadgetry (and in theory use the
"--status-fd" switch to know what to feed it), as in (using csh syntax):

    foreach x (`gpg --with-colons --list-keys | awk -F: '/^pub/{print $5}'`)
 echo YES | \
 gpg -u your_project_key --command-fd 0 --lsign-key $x
    end


While we're asking for features, I'll repeat my plea for one that
would help out on this workaround.  I'd sorely like to be able to use
the "--edit-key" commands (of which "--lsign" is a special case)
without having to deal with all of the questions.  It would be fine to
reuse an existing switch (like "--batch" or "--expert") or grow a new
one ("--just-do-it" or "--really-yes") to carry this meaning.
The same principle could be applied to disable the questions
about key size :-).

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQA/AwUBPNC1xFMkvpTT8vCGEQLqGQCgqMt4mcmi0OZOv543gBEwuY7H/8sAoOBV
0ESwD3C1sgvl99gAShvD9O3m
=tZW3
-----END PGP SIGNATURE-----




From wk@gnupg.org  Thu May  2 09:59:02 2002
From: wk@gnupg.org (Werner Koch)
Date: Thu May  2 08:59:02 2002
Subject: AIX bug malloc(0)
In-Reply-To: <20020430212626.GA1048@arghh.huh.org> (Winona Brown's message
 of "Tue, 30 Apr 2002 16:26:26 -0500")
References: <20020430212626.GA1048@arghh.huh.org>
Message-ID: <87znzjkpa0.fsf@alberti.gnupg.de>

On Tue, 30 Apr 2002 16:26:26 -0500, Winona Brown said:

> The better way to fix this would probably be to allow a NULL being returned
> if malloc(0) was called.  

Well yes, this would be better for debugging.  For now I took the easy
path out.

Thanks,

  Werner



From dbely@mail.ru  Thu May  2 19:04:02 2002
From: dbely@mail.ru (Dmitry Bely)
Date: Thu May  2 18:04:02 2002
Subject: 1.0.7 under Win32
Message-ID: <r8kufslp.fsf@mail.ru>

I have found some minor problems in GnuPG 1.0.7 that prevent it from
compiling out of the box. I have also fixed the bug in write_server() that
existed from the very beginning (Win32 API function WriteFile() doesn't
work with TCP/IP sockets). Due to that all HTTP-related stuff
("--recv-keys" option etc.) was broken under Win32. Are you interested in
the patch?

Hope to hear from you soon,
Dmitry




From tracy_d@xypro.com  Thu May  2 21:22:02 2002
From: tracy_d@xypro.com (Tracy Ding)
Date: Thu May  2 20:22:02 2002
Subject: A question?
Message-ID: <32E0F1DAB878D511826D00A0CCD7949203EE55@xypro.com>

Hello,
Currently I am working on Gnupg 1.0.6 stuff. 
I installed Gnupg 1.0.6 in my pc.
The command "gpg --print-md SHA1 Keypc"
  the putput is "Keypc: 69BB D5CF 491B C3BB F286  143A 4BC9 F8E8 7DCD"

But in OSS system ( I upload the source codes to Tandem OSS, compiled them )
I got different result.
"
 gpg --print-md SHA1 Keypc
gpg: Please note that you don't have secure memory on this system
gpg: WARNING: program may create a core file!
Keypc: 8653 FDF4 2F70 F2E2 E2D9  AFD4 CB7F 2531 9A85 E088
$ "                          

I tested it for MD5, the result is different too. 
I am totally lost, any help is appreciated.


Regards

Tracy Ding

                        


From wk@gnupg.org  Fri May  3 09:25:02 2002
From: wk@gnupg.org (Werner Koch)
Date: Fri May  3 08:25:02 2002
Subject: A question?
In-Reply-To: <32E0F1DAB878D511826D00A0CCD7949203EE55@xypro.com> (Tracy
 Ding's message of "Thu, 2 May 2002 11:22:16 -0700")
References: <32E0F1DAB878D511826D00A0CCD7949203EE55@xypro.com>
Message-ID: <87elgtiw4c.fsf@alberti.gnupg.de>

On Thu, 2 May 2002 11:22:16 -0700, Tracy Ding said:

> But in OSS system ( I upload the source codes to Tandem OSS, compiled them )
> I got different result.

Did you got any compiler diagnostics when building it?

Am I right that most checks fail if you do a "make check"?



From dshaw@jabberwocky.com  Fri May  3 17:40:02 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Fri May  3 16:40:02 2002
Subject: 15MB files on photo
In-Reply-To: <200205020205.g4225Fi03599@server-1.visp.net>
References: <200205020026.g420Qli28732@server-1.visp.net> <20020502005106.GA25856@akamai.com> <200205020205.g4225Fi03599@server-1.visp.net>
Message-ID: <20020503144106.GD6647@akamai.com>

> >On Wed, May 01, 2002 at 05:27:42PM -0700, Hideki Saito wrote:
> >> I found some problem with photo capability of 1.0.7 on Win32 
> >> compilation.
> >> 
> >> If you try to display graphics, it is actually a bogus JPG file.
> >> 
> >> I have tried with the option i_view32 %i as a photo-viewer argument, 
> >> and it returns "unknown header" error.
> >> 
> >> Then I tried i_view32 %I to see what actual "TEMP.JPG" is like, and it 
> >> turns out be a 12MB - 15MB garbage file.
> >
> >Hmm.  Are you using a Mingw32 or Cygwin build?

On Wed, May 01, 2002 at 07:06:11PM -0700, Hideki Saito wrote:
> Mingw32 build it is...

The problem is forward slashes in the photo path.  Before you compile,
you need to change g10defs.h:

Change these:
#define DIRSEP_C '/'
#define DIRSEP_S "/"

To these:
#define DIRSEP_C '\\'
#define DIRSEP_S "\\"

The Win32 internals do allow either / or \, but the photo viewer uses
system(), and that calls command, and command does not allow forward
slashes.

As for the large garbage file in i_view32, I was able to duplicate the
problem here so I see it as well, but I don't know where the garbage
came from.  I suspect that i_view32 gets upset if it gets forward
slashes in a pathname.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From tracy_d@xypro.com  Sat May  4 00:26:01 2002
From: tracy_d@xypro.com (Tracy Ding)
Date: Fri May  3 23:26:01 2002
Subject: Help ...
Message-ID: <32E0F1DAB878D511826D00A0CCD7949203EE5D@xypro.com>

Hello,

I installed gnupg-1.0.7 into a linux machine. 
It is i486 machine. 
I got a probelm when generating a key pair.

"
Not enough random bytes available.  Please do some other work to give
the OS a chance to collect more entropy! (Need 300 more bytes)     
"
The program stuck there waiting for more bytes.
Any help is appreciated.


Thanks

Tracy Ding


From ajs@ajs.com  Sat May  4 00:56:01 2002
From: ajs@ajs.com (Aaron Sherman)
Date: Fri May  3 23:56:01 2002
Subject: Help ...
In-Reply-To: <32E0F1DAB878D511826D00A0CCD7949203EE5D@xypro.com>
References: <32E0F1DAB878D511826D00A0CCD7949203EE5D@xypro.com>
Message-ID: <1020463004.22284.38.camel@pps>

On Fri, 2002-05-03 at 17:26, Tracy Ding wrote:

> I installed gnupg-1.0.7 into a linux machine. 
> It is i486 machine. 
> I got a probelm when generating a key pair.
> 
> "
> Not enough random bytes available.  Please do some other work to give
> the OS a chance to collect more entropy! (Need 300 more bytes)     
> "
> The program stuck there waiting for more bytes.
> Any help is appreciated.

As the message suggests, you should do more work and let the OS collect
more random bytes. Go! Do work! ;-)




From mutz@kde.org  Sat May  4 01:07:02 2002
From: mutz@kde.org (Marc Mutz)
Date: Sat May  4 00:07:02 2002
Subject: Help ...
In-Reply-To: <32E0F1DAB878D511826D00A0CCD7949203EE5D@xypro.com>
References: <32E0F1DAB878D511826D00A0CCD7949203EE5D@xypro.com>
Message-ID: <200205040007.16685@sendmail.mutz.com>

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

[ reordering lines of original post ]

On Friday 03 May 2002 23:26, Tracy Ding wrote:
<snip>
> The program stuck there waiting for more bytes: <snip>
> Not enough random bytes available.  Please do some other work to give
> the OS a chance to collect more entropy! (Need 300 more bytes)
<snip>

Sorry, you _can_ read, can you? :-(
You can: start bonnie in the background, hit the keyboard monkey-style, move 
the mouse wildly (maybe dragging a window around), or all at once... :-o

Marc

- -- 
Marc Mutz <mutz@kde.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE80woT3oWD+L2/6DgRAgu4AKCCKdzJ2nXvolRZm98mjNNwek1VjACff0Uy
pNJ03crlAlHhb412P6omRw4=
=axlJ
-----END PGP SIGNATURE-----



From dmitri@users.sourceforge.net  Sat May  4 01:29:02 2002
From: dmitri@users.sourceforge.net (Dmitri)
Date: Sat May  4 00:29:02 2002
Subject: Help ...
In-Reply-To: <200205040007.16685@sendmail.mutz.com>
References: <32E0F1DAB878D511826D00A0CCD7949203EE5D@xypro.com>
 <200205040007.16685@sendmail.mutz.com>
Message-ID: <1020464977.1668.228.camel@usb.networkfab.com>

--=-rwHiFvOaMeYb2BeHJUTK
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Fri, 2002-05-03 at 15:07, Marc Mutz wrote:

> On Friday 03 May 2002 23:26, Tracy Ding wrote:
> <snip>
> > The program stuck there waiting for more bytes: <snip>
> > Not enough random bytes available.  Please do some other work to give
> > the OS a chance to collect more entropy! (Need 300 more bytes)
> <snip>
>=20
> Sorry, you _can_ read, can you? :-(
> You can: start bonnie in the background, hit the keyboard monkey-style, m=
ove=20
> the mouse wildly (maybe dragging a window around), or all at once... :-o

I believe, the original cry for help was not unfounded. Here is why.

First of all, the message "Not enough random bytes available" may be
perceived by novices as an ERROR. It is phrased this way. Failed. No
luck. Come back in next millennium. Or something like that.

Secondly, the advice "Please do some other work" can be understood as
"give the computer more time, and meanwhile do something different, like
walking the dog..." If the user does that, the dog gets the entropy -
not the computer ;-)

Apparently, in this very case the user left the computer alone for some
time, and then complained that the program does not go anywhere.

This is because only computer geeks would equal "some other work" to
"some other work with this computer". Normal people have other "work" to
do. Naturally, if the computer is just left there then no new entropy
comes in, and nothing ever happens (until updatedb runs at night,
probably).

So messages may need to be softened up to be understood by all the
normal people ;-)

Dmitri


--=-rwHiFvOaMeYb2BeHJUTK
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA80w9RXksyLpO6T4IRAsPsAKCaVlUel2/AiKiLcqjzRgX8iLVSxQCgkZXw
oc6f+yGziDnxLzIz3u0+Ewc=
=kmrA
-----END PGP SIGNATURE-----

--=-rwHiFvOaMeYb2BeHJUTK--



From wk@gnupg.org  Sat May  4 16:31:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Sat May  4 15:31:01 2002
Subject: Help ...
In-Reply-To: <1020464977.1668.228.camel@usb.networkfab.com> (Dmitri's
 message of "03 May 2002 15:29:37 -0700")
References: <32E0F1DAB878D511826D00A0CCD7949203EE5D@xypro.com>
 <200205040007.16685@sendmail.mutz.com>
 <1020464977.1668.228.camel@usb.networkfab.com>
Message-ID: <87n0vgdomh.fsf@alberti.gnupg.de>

On 03 May 2002 15:29:37 -0700, Dmitri  said:

> So messages may need to be softened up to be understood by all the
> normal people ;-)

I agree.  I will reword the messages.

 Werner



From jas@extundo.com  Sat May  4 18:21:02 2002
From: jas@extundo.com (Simon Josefsson)
Date: Sat May  4 17:21:02 2002
Subject: update to gettext 0.11.2?
Message-ID: <iluu1pohr9p.fsf@extundo.com>

What about updating to gettext 0.11.2?  I had difficulties getting the
current gettext in gnupg to work.

I put a patch to do this up at http://josefsson.org/gnupg-gettext.diff
(due to size, ~230KB), altough it seems to remove some comments in
po/*.po so maybe not all of it should be applied.



From wk@gnupg.org  Sat May  4 19:57:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Sat May  4 18:57:01 2002
Subject: update to gettext 0.11.2?
In-Reply-To: <iluu1pohr9p.fsf@extundo.com> (Simon Josefsson's message of
 "Sat, 04 May 2002 17:22:26 +0200")
References: <iluu1pohr9p.fsf@extundo.com>
Message-ID: <871ycrdf4e.fsf@alberti.gnupg.de>

On Sat, 04 May 2002 17:22:26 +0200, Simon Josefsson said:

> What about updating to gettext 0.11.2?  I had difficulties getting the
> current gettext in gnupg to work.

As soon as it appears in Woody.

  Werner



From jgre@tzi.de  Mon May  6 12:12:02 2002
From: jgre@tzi.de (Janico Greifenberg)
Date: Mon May  6 11:12:02 2002
Subject: Importing and using keys with GPGME
Message-ID: <20020506062658.GA478@tzi.de>

Hello,
when I import a public key with gpgme_op_import() the key appears in my keyring
but when I want to use it for encryption (with gpgme_op_encrypt_sign()) I get
a GPGME_No_Data Error. When I use this key with gpg in the command line, I need
to confirm that I want to use this untrusted key. Is to possible to do
something like that with gpgme (I mean overriding the error) or do I have to
sign the key and how can I do this with gpgme?

Thanks in advance
       Janico
-- 
Warning! Taking anyone (especially yourself) too serious will be harmful


From hideki@allcity.net  Mon May  6 14:17:02 2002
From: hideki@allcity.net (Hideki Saito)
Date: Mon May  6 13:17:02 2002
Subject: 15MB files on photo
In-Reply-To: <20020503144106.GD6647@akamai.com>
References: <200205020026.g420Qli28732@server-1.visp.net>
 <20020502005106.GA25856@akamai.com>
 <200205020205.g4225Fi03599@server-1.visp.net>
 <20020503144106.GD6647@akamai.com>
Message-ID: <200205061118.g46BIYg20489@sasami.anime.net>

Yes, this worked.
Thanks.

Here are files, in case anyones are interested.
http://hp.vector.co.jp/authors/VA019487/gnupg-w32-1.0.7-hs.zip
http://hp.vector.co.jp/authors/VA019487/hs-gnupg-w32-1.0.7-hs.zip.sig


>
>On Wed, May 01, 2002 at 07:06:11PM -0700, Hideki Saito wrote:
>> Mingw32 build it is...
>
>The problem is forward slashes in the photo path.  Before you compile,
>you need to change g10defs.h:
>
>Change these:
>#define DIRSEP_C '/'
>#define DIRSEP_S "/"
>
>To these:
>#define DIRSEP_C '\\'
>#define DIRSEP_S "\\"
>
>The Win32 internals do allow either / or \, but the photo viewer uses
>system(), and that calls command, and command does not allow forward
>slashes.
>
>As for the large garbage file in i_view32, I was able to duplicate the
>problem here so I see it as well, but I don't know where the garbage
>came from.  I suspect that i_view32 gets upset if it gets forward
>slashes in a pathname.
>


-- 
Hideki Saito mailto:hideki@allcity.net


From wk@gnupg.org  Mon May  6 14:55:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Mon May  6 13:55:01 2002
Subject: Importing and using keys with GPGME
In-Reply-To: <20020506062658.GA478@tzi.de> (jgre@tzi.de's message of "Mon, 6
 May 2002 08:26:59 +0200")
References: <20020506062658.GA478@tzi.de>
Message-ID: <87lmax1oac.fsf@alberti.gnupg.de>

On Mon, 6 May 2002 08:26:59 +0200, Janico Greifenberg said:

> when I import a public key with gpgme_op_import() the key appears in my keyring
> but when I want to use it for encryption (with gpgme_op_encrypt_sign()) I get
> a GPGME_No_Data Error. When I use this key with gpg in the command line, I need

In general it does not make sense to encrypt something to someone whom
you don't trust.  So the best way is to locally sign the sign.

Using

  gpgme_recipients_add_name_with_validity (rset, name, GPGME_VALIDITY_FULL);

you should be able to overide it.




From Weimer@CERT.Uni-Stuttgart.DE  Tue May  7 10:43:02 2002
From: Weimer@CERT.Uni-Stuttgart.DE (Florian Weimer)
Date: Tue May  7 09:43:02 2002
Subject: Expiration and V3/V4 self signatures
Message-ID: <87helk8ksv.fsf@CERT.Uni-Stuttgart.DE>

* packet.h, parse-packet.c (parse_key), getkey.c (merge_keys_and_selfsig,
merge_selfsigs_main): a v3 key with a v4 self-sig must never let the v4
self-sig express a key expiration time that extends beyond the original v3
expiration time.

* keyedit.c (sign_uids): If --expert it set, allow re-signing a uid to
promote a v3 self-sig to a v4 one.  This essentially deletes the old v3
self-sig and replaces it with a v4 one.

Don't these two features conflict with each other?

-- 
Florian Weimer 	                  Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898


From wk@gnupg.org  Tue May  7 11:07:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Tue May  7 10:07:01 2002
Subject: Expiration and V3/V4 self signatures
In-Reply-To: <87helk8ksv.fsf@CERT.Uni-Stuttgart.DE> (Florian Weimer's
 message of "Tue, 07 May 2002 09:43:44 +0200")
References: <87helk8ksv.fsf@CERT.Uni-Stuttgart.DE>
Message-ID: <877kmgwfb8.fsf@alberti.gnupg.de>

On Tue, 07 May 2002 09:43:44 +0200, Florian Weimer said:

> * packet.h, parse-packet.c (parse_key), getkey.c (merge_keys_and_selfsig,
> merge_selfsigs_main): a v3 key with a v4 self-sig must never let the v4
> self-sig express a key expiration time that extends beyond the original v3
> expiration time.

> * keyedit.c (sign_uids): If --expert it set, allow re-signing a uid to
> promote a v3 self-sig to a v4 one.  This essentially deletes the old v3
> self-sig and replaces it with a v4 one.

> Don't these two features conflict with each other?

No.  Why should they?

As you know the expiration time in a v3 key is stored unchangeable
with the key whereas it is store in a self-signature with a v4 key.
The first change makes sure that the expiration time from a v4
signature on a v3 key can not be used to extend the expiration time
over the one set with the v3 key and the latter change simply promotes
a v3 self-signature to a v4 self-signature with an expiration time
(set to the one from the v3 key).

  Werner



From p_perego@modiano.com  Tue May  7 13:37:02 2002
From: p_perego@modiano.com (Paolo Perego)
Date: Tue May  7 12:37:02 2002
Subject: GPGME: verify signature question
Message-ID: <200205071237.54986.p_perego@modiano.com>

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

Hi ,guys. I'm not subscribed to thie ML so please cc me. I'm using gpg 1.=
07=20
and gpgme 0.3.6 on my suse linux box. I'm developing a tool that parse a=20
mailbox looking for mails and, if thie mails are signed, try to verify th=
e=20
signature ( not detached ). The messages are in rfc2015 form, so the cont=
ent =20
type is "multipart/signed" and the signed data is divided from the signat=
ure=20
by the boundary.

I wrote the code to verify the signature but I think I did not pass the r=
ight=20
body and signature content to gpgme_op_verify. Can you please gave me som=
e=20
links, examples ( not mail usent agent sources, please. ) about how verif=
y a=20
signed message vailidity.

Thanks a lot
Paolo
- --=20
$>cd /pub
$>more beer

(0>
//\  Perego Paolo <p_perego@modiano.com> - www.sikurezza.org/angel
V_/_ 'It's seems the hardest life I've never known'
I'm Linux drow 2.4.17-4GB - SuSE Linux 7.3 (i386) powered.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE8166Ae2SOXFIw7OcRAlFvAJ46Eu6wq4UrsiisYz7WE1xcGIAJYwCgmsWX
r2/3n7ue4jzOlCyISocqUQE=3D
=3DbzUP
-----END PGP SIGNATURE-----



From wk@gnupg.org  Tue May  7 14:13:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Tue May  7 13:13:01 2002
Subject: GPGME: verify signature question
In-Reply-To: <200205071237.54986.p_perego@modiano.com> (Paolo Perego's
 message of "Tue, 7 May 2002 12:37:45 +0200")
References: <200205071237.54986.p_perego@modiano.com>
Message-ID: <87k7qgus5c.fsf@alberti.gnupg.de>

On Tue, 7 May 2002 12:37:45 +0200, Paolo Perego said:

> signature ( not detached ). The messages are in rfc2015 form, so the content  
> type is "multipart/signed" and the signed data is divided from the signature 

BTW, rfc3156 is the successor or 2015, only minor changes but you
should use this as a reference,

> body and signature content to gpgme_op_verify. Can you please gave me some 
> links, examples ( not mail usent agent sources, please. ) about how verify a 

Be sure to include the header lines of the part and don't include the
CR/LF right before the terminating boundary.

What's wrong with looking at other sources?

  Werner



From p_perego@modiano.com  Tue May  7 15:18:02 2002
From: p_perego@modiano.com (Paolo Perego)
Date: Tue May  7 14:18:02 2002
Subject: GPGME: verify signature question
In-Reply-To: <87k7qgus5c.fsf@alberti.gnupg.de>
References: <200205071237.54986.p_perego@modiano.com> <87k7qgus5c.fsf@alberti.gnupg.de>
Message-ID: <200205071418.58964.p_perego@modiano.com>

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

Alle 13:14, marted=EC 7 maggio 2002, Werner Koch ha scritto:

> BTW, rfc3156 is the successor or 2015, only minor changes but you
> should use this as a reference,
Sure. I omissed that I downloaded also the new rfc. :)

> Be sure to include the header lines of the part and don't include the
> CR/LF right before the terminating boundary.
Is the signature calculated from the first "--boundary" or also the mail=20
header are hashed by gpg?

> What's wrong with looking at other sources?
Nothing at all.  I was checking out mutt and sylpheed-claws sources. But =
they=20
parse mime headers in various point of the code and I was not able to gue=
ss=20
what exactly they pass to gpgme_op_verify().

Thank again. I think this afternoon will be plenty of signature checking=20
attempts :)
Paolo
- --=20
$>cd /pub
$>more beer

(0>
//\  Perego Paolo <p_perego@modiano.com> - www.sikurezza.org/angel
V_/_ 'It's seems the hardest life I've never known'
I'm Linux drow 2.4.17-4GB - SuSE Linux 7.3 (i386) powered.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE818Yxe2SOXFIw7OcRAm2fAJ96qivoJ1SUH8JxGDjUkyguwvnK3wCgh96n
4ivWYObqgTQF7ikNsJTAAUs=3D
=3Ddhyt
-----END PGP SIGNATURE-----



From wk@gnupg.org  Tue May  7 15:37:02 2002
From: wk@gnupg.org (Werner Koch)
Date: Tue May  7 14:37:02 2002
Subject: GPGME: verify signature question
In-Reply-To: <200205071418.58964.p_perego@modiano.com> (Paolo Perego's
 message of "Tue, 7 May 2002 14:18:50 +0200")
References: <200205071237.54986.p_perego@modiano.com>
 <87k7qgus5c.fsf@alberti.gnupg.de>
 <200205071418.58964.p_perego@modiano.com>
Message-ID: <87g014uo6m.fsf@alberti.gnupg.de>

On Tue, 7 May 2002 14:18:50 +0200, Paolo Perego said:

> Is the signature calculated from the first "--boundary" or also the mail 
> header are hashed by gpg?

  Subject: a signed message
  
  -=-=-=
  Content-Type: whatever/foo

  This is the content which might be encoded in any way as
  specified by a encoding header.  For signature verification there 
  is nothing we have to care about.

  -=-=-=
  Content-Type: application/pgp-signature

What you hash is this string in C notation:

  "Content-Type: whatever/foo\r\n\r\nThis is the content which might"
  " be encoded in any way as\r\nspecified by a encoding header.  For"
  "  signature verification there\r\nis nothing we have to care about.\r\n"

And you might want to keep in mind that such a PGP/MIEM object may be
embedded in other MIME objects or the whatever/foo conetnt type might
be a multipart/mixed or whatever you can imagine.

gpg --debug 512

is of great help here because it creates files dbgmd*.<somecode> with
the actually hashed content.


  Werner



From p_perego@modiano.com  Tue May  7 15:42:01 2002
From: p_perego@modiano.com (Paolo Perego)
Date: Tue May  7 14:42:01 2002
Subject: GPGME: verify signature question
In-Reply-To: <87g014uo6m.fsf@alberti.gnupg.de>
References: <200205071237.54986.p_perego@modiano.com> <200205071418.58964.p_perego@modiano.com> <87g014uo6m.fsf@alberti.gnupg.de>
Message-ID: <200205071443.13524.p_perego@modiano.com>

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

Alle 14:39, marted=EC 7 maggio 2002, Werner Koch ha scritto:
[snip]

> What you hash is this string in C notation:
>
>   "Content-Type: whatever/foo\r\n\r\nThis is the content which might"
>   " be encoded in any way as\r\nspecified by a encoding header.  For"
>   "  signature verification there\r\nis nothing we have to care about.\=
r\n"
Perfect. At the same time I guess I must pass the string "-----BEGIN PGP=20
SIGNATURE-----.... -----END PGP SIGNATURE-----" as signature in=20
gpgme_op_verify(). Am I right am not I?

> And you might want to keep in mind that such a PGP/MIEM object may be
> embedded in other MIME objects or the whatever/foo conetnt type might
> be a multipart/mixed or whatever you can imagine.
Sure, but my application is really simple and it needs just to validate t=
he=20
sender identity! :)

Thanks for the help guys [ and excuse me for my poor english :P ]
Paolo
- --=20
$>cd /pub
$>more beer

(0>
//\  Perego Paolo <p_perego@modiano.com> - www.sikurezza.org/angel
V_/_ 'It's seems the hardest life I've never known'
I'm Linux drow 2.4.17-4GB - SuSE Linux 7.3 (i386) powered.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE818vge2SOXFIw7OcRAszgAJ9KpVTx0wzW/hFS8H3i//HQBzZJ3ACeImPY
VZM84JDhKchJecuG4yTz/eI=3D
=3DwMhM
-----END PGP SIGNATURE-----



From wk@gnupg.org  Tue May  7 15:57:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Tue May  7 14:57:01 2002
Subject: GPGME: verify signature question
In-Reply-To: <200205071443.13524.p_perego@modiano.com> (Paolo Perego's
 message of "Tue, 7 May 2002 14:43:07 +0200")
References: <200205071237.54986.p_perego@modiano.com>
 <200205071418.58964.p_perego@modiano.com>
 <87g014uo6m.fsf@alberti.gnupg.de>
 <200205071443.13524.p_perego@modiano.com>
Message-ID: <87u1pkt8oc.fsf@alberti.gnupg.de>

On Tue, 7 May 2002 14:43:07 +0200, Paolo Perego said:

> Perfect. At the same time I guess I must pass the string "-----BEGIN PGP 
> SIGNATURE-----.... -----END PGP SIGNATURE-----" as signature in 
> gpgme_op_verify(). Am I right am not I?

Yes.  

  Werner



From redbird@rbisland.cx  Tue May  7 18:58:02 2002
From: redbird@rbisland.cx (Gordon Worley)
Date: Tue May  7 17:58:02 2002
Subject: GnuPG 1.0.7 configure with dynload modules
Message-ID: <4B21FE3D-61D3-11D6-B33A-000A27B4DEFC@rbisland.cx>

Okay, I'm having a bit of trouble here and hopefully someone has some 
insights.

I'm trying to patch GnuPG 1.0.7 to run on Darwin (Mac OS X).  Everything 
is working except for one thing.  I have patched cipher/dynload.c to 
work as we did in 1.0.6 and it compiles fine and looks like it will 
work.  The problem comes when make tries to make the checks.  The 
problem is that tiger has not been compiled earlier.  Yet, when 
configure was run, it said that it would:

                 Configured for: Darwin (powerpc-apple-darwin5.4)
     Dynamically linked modules: rndunix rndegd tiger
      Statically linked modules: rndlinux sha1 rmd160 md5

So, anyone have any ideas on how to get tiger (and rndunix and rndegd; I 
checked and they haven't been compiled either) to compile short of doing 
it by hand?

Thanks.

--
Gordon Worley                     `When I use a word,' Humpty Dumpty
http://www.rbisland.cx/            said, `it means just what I choose
redbird@rbisland.cx                it to mean--neither more nor less.'
PGP:  0xBBD3B003                                  --Lewis Carroll



From bgallia@orion.it.luc.edu  Wed May  8 00:34:03 2002
From: bgallia@orion.it.luc.edu (B. Galliart)
Date: Tue May  7 23:34:03 2002
Subject: AIX malloc(0) is null
Message-ID: <Pine.A41.4.40.0205071551390.12276-100000@orion.it.luc.edu>

How many people believe in testing if their computer is out of memory by
requesting the allocation of *0* bytes?

So, what is wrong with the following picture:
  gpg: out of  memory while allocating 0 bytes

GNUPG v1.07 *REQUIRES* the use of m-guard on AIX to ensure that GPG never
attempts malloc(0) (m-gaurd always allocates at least 5 bytes).  There is
just something brain dead about requesting *nothing* and exiting if you do
not get *something*.  Please update memory.c to skip malloc if 0 bytes are
requested or update the configure script to automatically include m-gaurd
if malloc(0) returns null.

Thanks



From dshaw@jabberwocky.com  Wed May  8 00:46:02 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Tue May  7 23:46:02 2002
Subject: AIX malloc(0) is null
In-Reply-To: <Pine.A41.4.40.0205071551390.12276-100000@orion.it.luc.edu>
References: <Pine.A41.4.40.0205071551390.12276-100000@orion.it.luc.edu>
Message-ID: <20020507214715.GB3487@akamai.com>

On Tue, May 07, 2002 at 04:35:11PM -0500, B. Galliart wrote:
> How many people believe in testing if their computer is out of memory by
> requesting the allocation of *0* bytes?
> 
> So, what is wrong with the following picture:
>   gpg: out of  memory while allocating 0 bytes

Fixed in 1.0.8.  See
  http://lists.gnupg.org/pipermail/gnupg-users/2002-May/013022.html
for temporary patch.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From bgallia@orion.it.luc.edu  Wed May  8 08:34:01 2002
From: bgallia@orion.it.luc.edu (B. Galliart)
Date: Wed May  8 07:34:01 2002
Subject: AIX malloc(0) is null
In-Reply-To: <20020507214715.GB3487@akamai.com>
Message-ID: <Pine.A41.4.40.0205080024590.12276-100000@orion.it.luc.edu>

Wow, fixed 6.5 hours before I post.  That is increditable timing.

You wouldn't have a trick up your sleeve for the problem below.  I can
recreate the issue with both gcc v2.9 and gcc v3.04 but IBM's v3.6.4 C
compiler goes through without a problem.  Is this a GNUPG or GCC issue?

mpih-div.c: In function `mpihelp_mod_1':
mpih-div.c:86: warning: implicit declaration of function `__udiv_w_sdiv'
mpih-div.c:100: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:100: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:106: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:106: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:136: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:136: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c: In function `mpihelp_divrem':
mpih-div.c:290: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:354: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c: In function `mpihelp_divmod_1':
mpih-div.c:447: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:447: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:453: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:453: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:482: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:482: Can't find a register in class `MQ_REGS' while reloading `asm'.




From wk@gnupg.org  Wed May  8 11:31:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Wed May  8 10:31:01 2002
Subject: AIX malloc(0) is null
In-Reply-To: <Pine.A41.4.40.0205080024590.12276-100000@orion.it.luc.edu> ("B.
 Galliart"'s message of "Wed, 8 May 2002 00:35:29 -0500 (CDT)")
References: <Pine.A41.4.40.0205080024590.12276-100000@orion.it.luc.edu>
Message-ID: <87znzbjc8h.fsf@alberti.gnupg.de>

On Wed, 8 May 2002 00:35:29 -0500 (CDT), B Galliart said:

> mpih-div.c:86: warning: implicit declaration of function `__udiv_w_sdiv'
> mpih-div.c:100: Can't find a register in class `MQ_REGS' while reloading `asm'.

This is more a problem of using GCC with the native as(1)  I have
no instant solution for this.  Compiling GMP should yield the same
problems.

   Werner



From order@elite-code-runner.com  Wed May  8 21:14:02 2002
From: order@elite-code-runner.com (Bolder Computer Solutions)
Date: Wed May  8 20:14:02 2002
Subject: Cover Your Tracks
Message-ID: 47494851946830.70799.qmail@elite-code-runner.com

                                             Cover your Tracks

We at Bolder Computer Solutions have been looking for a software developer that has the state of the art software programs, at the right price, which can protect all of us on the Internet. We found Elite Code Runner!!! Elite Code Runner has products designed at blocking Hackers from your computer, software designed to delete all traces of your surfing and also your document and history files, and software to let you know where your children, your employees, your friends, and anyone that uses your computer, have gone when they are using your computer. 

                                                 Trace Breaker

Trace Breaker is a software program that is designed to erase all traces of your travels around the Internet. We have also added the ability to this software programs to clear all your history files from the internet, clear your cookies, delete the typed URL's, Windows Recent files, Office Recent files, and your Document files. These are all user selectable allowing you to keep the files you choose.

Trace Breaker $ 49.95

Name :______________________________________________________________
Address :____________________________________________________________
City State Zip______________________________________  _____   ___________
Amount Enclosed :_$______________

                      We except company checks or Money orders.
***** Add $6.95 shipping and Handling for each package you order. *****
***** Make all checks payable to Bolder Computer Solutions.            *****
Mail to:

Bolder Computer Solutions
27 Shethar Street
P.O. Box 25
Hammondsport, NY 14840-0025

Shipping as soon as checks clear. Immediately with Money orders.

***** Print this ad, circle selections and mail with payment                 *****




From andreas@xss.co.at  Thu May  9 14:34:02 2002
From: andreas@xss.co.at (Andreas Haumer)
Date: Thu May  9 13:34:02 2002
Subject: gnupg-1.0.7: missing dependencies in checks/Makefile
Message-ID: <3CDA5EDF.990C18F8@xss.co.at>

Hi!

I found a small problem in the checks/Makefile for gnupg-1.0.7

Some of the checks there need a script "gpg_dearmor", which
itself is created by make on the fly. But this dependency
is not explicitly listed in the Makefile, so a "make -j2"
(or any build with more than one job running simultaneously) 
fails on our Dual CPU development server.

I'd suggest to add "gpg_dearmor" to the dependency section of
all make targets where this script is used (just like it 
already is for target "./pubring.gpg")

Regards,

- andreas

-- 
Andreas Haumer                     | mailto:andreas@xss.co.at
*x Software + Systeme              | http://www.xss.co.at/
Karmarschgasse 51/2/20             | Tel: +43-1-6060114-0
A-1100 Vienna, Austria             | Fax: +43-1-6060114-71


From mwy-gpg41@the-youngs.org  Thu May  9 21:52:01 2002
From: mwy-gpg41@the-youngs.org (Michael Young)
Date: Thu May  9 20:52:01 2002
Subject: Notation data format: "user" name space rejected
References: <E175fVC-0001KU-00@trithemius.gnupg.org>
Message-ID: <007201c1f78a$9a6d81e0$ebc42609@transarc.ibm.com>

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

The latest draft of RFC2440 describes two name spaces for notation
data, one of which GnuPG rejects as invalid.  Specifically, the
RFC describes the "user" name space:

>    Names in the user name space consist of a UTF-8 string tag followed
>    by "@" followed by a DNS domain name. Note that the tag MUST NOT
>    contain an "@" character. For example, the "sample" tag used by
>    Example Corporation could be "sample@example.com".

When I try to generate such a notation, I get this error:
    log_error(_("a notation name must have only letters, "
  "digits, dots or underscores and end with an '='\n") );

(My test used 1.0.6, but it doesn't appear to have changed in the
latest source.)

At first glance, it would appear that adding the "@" character
to the check on the line before the log_error() would be sufficient.
But neither the "tag" nor the DNS domain name should need to meet
these tight restrictions (alphanumeric/dot/underscore).  So, I
would suggest looking for a "@" first, at which point almost
anything goes.  Does that seem reasonable?

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQA/AwUBPNrFJFMkvpTT8vCGEQKhpgCg2dVswZWsaKwSZGkvQh7Cg3UYDjoAoMCz
tgIKnXkM0nKFPmSe2YWZRWXQ
=U8xW
-----END PGP SIGNATURE-----




From Dr. Carter" <Have_Open_Mind@yahoo.com  Thu May  9 22:02:01 2002
From: Dr. Carter" <Have_Open_Mind@yahoo.com (Dr. Carter)
Date: Thu May  9 21:02:01 2002
Subject: To: g10 as a Good Person - Conduct Education in the 21st Century
Message-ID: <4140-2200254919350630@oemcomputer>

Dear g10:

You may ask yourself
      >    How to make people respect you
      >    How to win friends
      >    How to let your conduct help your health, work, job, career, re=
lationships, spirit,  mind, well-being, =2E=2E=2E
      >    How to make your life smoother and happier=20
      >    How to do whatever you like without being unpleasant to other p=
eople=20
      >    How to develop good conduct in your children or students=20
      >    How to make the world peaceful and better

You can find all the answers to these questions, and much more, in this gr=
eat handbook:
=20
"Complete Conduct Principles for the 21st Century" by Dr=2E John Newton=20=


It is the best educational GIFT idea for children, friends, relatives, cla=
ssmates, students, parents, teachers, other educators, =2E=2E=2E, particul=
arly at this special time=2E=20

BENEFITS to each individual reader: Many! -- such as for health, work, job=
, career, self-improvement, education, relationships, spirit, mind, well-b=
eing, and much more -- almost all the areas that are important to you in t=
he 21st century=2E People around you will benefit, too=2E (Please see the =
PREFACE of the book for details=2E)=20

EVERYONE may find this handbook useful and helpful, regardless of age (fro=
m children to oldsters), occupation, rank, status, gender, religious belie=
fs, nationality, country, or region=2E=20

If you are a parent or a teacher, you can learn how to develop good conduc=
t in your children or students from this handbook=2E Please advise your ch=
ildren or students to read the book=2E It will result in great benefits fo=
r both you and them=2E=20

(Note: If you are interested in the issue of School Violence, Youth Proble=
ms, Violence Prevention, or Conduct Education in the 21st Century, please =
see the APPENDIX below=2E) =20

This book is a must for EVERYONE to be better prepared for personal conduc=
t for the 21st century=2E=20

The book's content is obvious from its title=2E The complete useful conduc=
t principles cover not only what we should do, but also what we should not=
 do -- especially those faults people make often and easily=2E=20

This timely, unique, and very important handbook is designed to suit most =
people, and is self-contained and user-friendly=2E=20

This book is significantly different and better than competitive works=2E

Some of its innovative contents may help solve problems that Western cultu=
re cannot=2E=20

The book's merit and importance have been recognized and praised by many e=
xperts, elected public officials, and world leaders=2E

How to make the world peaceful and better ---
You can find the solution in the book=2E
Let's work together to make the world peaceful and better!=20

The author, John Newton, holds a Ph=2ED=2E from MIT, and does researches a=
t Harvard=2E His long-term research on "The personal conduct in the human =
society of the 21st century" resulted in this book=2E It is published by N=
icer Century World Organization, headquartered beside Harvard University a=
nd MIT, two leading institutes of new knowledge and literature=2E

The book is available in two types of binding: Hardcover (ISBN 0967370574;=
 case bound, Smyth sewn; with dust jacket) and Paperback (ISBN 0967370582;=
 perfect bound)=2E Both editions are unabridged, and are printed on 60 lb,=
 natural, acid-free, excellent and healthful paper=2E You can get the book=
 from many fine on-line bookstores and traditional bookstores=2E For your =
convenience, I herewith provide you with a link directly to the book page =
in the shopping directory of Yahoo!, the world's No=2E 1 Internet director=
y:

http://shopping=2Eyahoo=2Ecom/shop?d=3Db&id=3D3680641&clink=3Ddmpr-hm/rp&c=
f=3Dsetup

Some bookstores there offer great discounts (for a limited time)=2E Note t=
hat some of the bookstores may disappear there if out-of-stock=2E In that =
case, you may want to go to another bookstore=2E Of course, you may freely=
 go to other bookstores at any time, even if they are not listed in Yahoo!=
=2E

Please forward this e-mail to people you know -- children, friends, relati=
ves, classmates, students, parents, teachers, other educators, =2E=2E=2E, =
because they can benefit from it, too=2E This can be a wonderful kindness =
you provide to them!

g10, best wishes to you!


Sincerely yours,

Tom Carter, Ph=2ED=2E
President, Nicer Century World Organization
Massachusetts, USA

(Nicer Century World Organization is an educational, non-profit, non-parti=
san organization; it endeavors to make the 21st century nicer than ever be=
fore=2E To accomplish its mission, Nicer Century World Organization is pro=
ud to introduce this book=2E)=20

-----------------------------------------------------------

APPENDIX: School Violence, Youth Problems, Violence Prevention, and Conduc=
t Education in the 21st Century

In recent years school violence has made many pieces of nation-shaking hig=
hlighted headline news, which have astounded the Americans=2E It may happe=
n at any school, at any time, and by students of any age=2E Some experts b=
elieve this is the most important national crisis the U=2ES=2E is facing=2E=
=20

"In the 21st century the problem will happen not only continuously in the =
U=2ES=2E but also in lots of other countries all over the world, if we do =
not act=2E" said Dr=2E John Newton in the late 20th century=2E Recent trag=
edies have proved this warning prediction=2E

"The most effective and proper way to solve the problem is appropriate con=
duct education=2E" said Dr=2E Newton=2E

"The significance of the problem" is much more important than "the number =
of people killed in schools"=2E=20

In addition to shooting and killing, other kinds of school violence, such =
as rape, sexual assault, aggravated assault, robbery, bullying, mugging, f=
ighting, theft, harassment, =2E=2E=2E, and other youth problems, like suic=
ide, suicide attempt, suicide inclination, pessimism, sense of inferiority=
, lose of  self-control, relationship problems, emotion problems, drug abu=
se, discrimination, =2E=2E=2E, cannot be ignored, either=2E

Some measures may handle a few "symptoms" temporarily and partially but ar=
e not solutions for education, particularly in view of our responsibilitie=
s for the whole society=2E

Now an effective, proper, comprehensive, deep-rooted and permanent solutio=
n is needed!

The book, "Complete Conduct Principles for the 21st Century" by Dr=2E John=
 Newton, is regarded as "the very one that can effectively help solve the =
problem of school violence in a right way" by some experts in education, i=
ncluding Dr=2E Steve White, who pointed out clearly: "If students, teacher=
s and parents can learn the conduct principles in this book well, then tha=
t 'unsolvable' problem will be solved=2E  It is not difficult at all to le=
arn them, because the book is a simple, easy, clear, convenient and self-c=
ontained handbook, well designed to suit most people=2E" The book was also=
 praised as "a compendium of concisely expressed, practical, informative, =
pertinent, workable advice" by Michael J=2E Carson, a professional book re=
viewer=2E

"Unlike most books of this subject, it is NOT a religious book, nor is a c=
ollection of old conduct rules=2E"=20

As analyzed in the Preface of the book, "from now on learning good conduct=
 should be placed as No=2E 1 in education=2E"=20

The book's merit and importance have been recognized and praised by many e=
ducation experts, elected public officials, and world leaders=2E Some educ=
ational units, ranging from the level of nation or state to individual sch=
ool or university, have ordered the book either as textbook/reference book=
 or as an active action to prevent school violence, to improve education a=
nd to benefit students, teachers & parents=2E=20

"The book will also be effective for violence prevention for the whole soc=
iety=2E"

Hence, to prevent school violence and other violence, to improve education=
, and to benefit students, teachers, parents, & the whole society, I earne=
stly request you to inform the students, teachers, parents, school library=
 and other relevant people you know of the availability of the book=2E

A reasonable method you may consider choosing is to simply  forward this l=
etter to them=2E

Although it will be helpful and appreciated, it is NOT necessary that you =
state any endorsement or the like=2E

Your efforts to prevent school violence and other violence, to improve edu=
cation, and to benefit students, teachers, parents, & the whole society wi=
ll be highly appreciated=2E




From dshaw@jabberwocky.com  Thu May  9 22:16:01 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Thu May  9 21:16:01 2002
Subject: Notation data format: "user" name space rejected
In-Reply-To: <007201c1f78a$9a6d81e0$ebc42609@transarc.ibm.com>
References: <E175fVC-0001KU-00@trithemius.gnupg.org> <007201c1f78a$9a6d81e0$ebc42609@transarc.ibm.com>
Message-ID: <20020509191712.GC3323@akamai.com>

On Thu, May 09, 2002 at 02:52:00PM -0400, Michael Young wrote:

> The latest draft of RFC2440 describes two name spaces for notation
> data, one of which GnuPG rejects as invalid.  Specifically, the
> RFC describes the "user" name space:
> 
> >    Names in the user name space consist of a UTF-8 string tag followed
> >    by "@" followed by a DNS domain name. Note that the tag MUST NOT
> >    contain an "@" character. For example, the "sample" tag used by
> >    Example Corporation could be "sample@example.com".
> 
> When I try to generate such a notation, I get this error:
>     log_error(_("a notation name must have only letters, "
>   "digits, dots or underscores and end with an '='\n") );
> 
> (My test used 1.0.6, but it doesn't appear to have changed in the
> latest source.)

It hasn't.  The problem here is that between 2440 and one of the
succeeding 2440bis drafts the spec here changed slightly, so there is
a bit of a 'moving target' effect.  I'll look into it.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From karlsson@hal-pc.org  Thu May  9 22:39:02 2002
From: karlsson@hal-pc.org (Brian M. Carlson)
Date: Thu May  9 21:39:02 2002
Subject: force-v4-certs and digest-algo
Message-ID: <20020509194024.GB6949@stonewall>

--DKU6Jbt7q3WqK7+M
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

I have set force-v4-certs in my options file. I also have digest-algo RIPEM=
D160
set. Yet, my signatures still are made with SHA1, which I deprecate strongl=
y.
If I have a preference on my key, I'd prefer that gpg choose that, unless
I choose a digest-algo option, in which case gpg uses that. gpg has done
neither.

Is that possible without a rewrite of the code?

--=20
Brian M. Carlson
<karlsson@hal-pc.org>
OpenPGP: 0x351336B2DCA1913A

--DKU6Jbt7q3WqK7+M
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Ubi libertas, ibi patria.

iQEVAwUBPNrQqOWR/8lWBVPnAQPyhQf6AwTw3UZm/jq0or8fw45VcIA2BN5czunY
gzKRWn47HW5aRwWNE4x1tOEfhOZbeg7CFxFM4lEKmuCTL8Qu4/+xCk79z9ne58eS
Ke25JxVgpQ6Q046LyBbaPaKtJFaF9U+YqbO4KJZ8E5/LSUCoBmdEgwFgnWyCVizp
yLZEDgA3kdId6BZoZ7OdiM+yKKnIRc1qd9QJ0N2MfpvTwG7f59oNKRTOqWoDR5Am
112UvcYJtYoMjP3/dP3mDUk71qkoExkwbuQbMwQvTYjDNH6jU7U5DKTcikPQSTYR
LlFjeumAVe6janjDnh6vlfy1nAv/Iq6uAADclh7DHVNVGRI1AQshAw==
=ObM8
-----END PGP SIGNATURE-----

--DKU6Jbt7q3WqK7+M--


From dshaw@jabberwocky.com  Thu May  9 22:50:01 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Thu May  9 21:50:01 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <20020509194024.GB6949@stonewall>
References: <20020509194024.GB6949@stonewall>
Message-ID: <20020509195108.GE3323@akamai.com>

On Thu, May 09, 2002 at 07:40:24PM +0000, Brian M. Carlson wrote:

> I have set force-v4-certs in my options file. I also have
> digest-algo RIPEMD160 set. Yet, my signatures still are made with
> SHA1, which I deprecate strongly.  If I have a preference on my key,
> I'd prefer that gpg choose that, unless I choose a digest-algo
> option, in which case gpg uses that. gpg has done neither.

Let me make sure I understand what you are doing.  You want your key
signatures - not data signatures - to use RIPEMD160 and not SHA1?

--digest-algo only applies to data signatures.

Why do you strongly deprecate SHA1?

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From mutz@kde.org  Thu May  9 23:36:05 2002
From: mutz@kde.org (Marc Mutz)
Date: Thu May  9 22:36:05 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <20020509194024.GB6949@stonewall>
References: <20020509194024.GB6949@stonewall>
Message-ID: <200205092236.31196@sendmail.mutz.com>

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 09 May 2002 21:40, Brian M. Carlson wrote:
> I have set force-v4-certs in my options file. I also have digest-algo
> RIPEMD160 set. Yet, my signatures still are made with SHA1,
<snip>

Well, according to the micalg parameter of your mp/signed, your last messag=
e=20
_was_ RIMEMD160.

Marc

=2D --=20
Marc Mutz <mutz@kde.org>
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE82t3N3oWD+L2/6DgRAlcvAJoDRQr+9AIq9J1k4jioo1LiPufPIgCgtFag
/LWfdENWjoE8xSHeFk67tNU=3D
=3DxDxC
=2D----END PGP SIGNATURE-----



From karlsson@hal-pc.org  Thu May  9 23:54:02 2002
From: karlsson@hal-pc.org (Brian M. Carlson)
Date: Thu May  9 22:54:02 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <20020509195108.GE3323@akamai.com>
References: <20020509194024.GB6949@stonewall> <20020509195108.GE3323@akamai.com>
Message-ID: <20020509205512.GC6949@stonewall>

--bKyqfOwhbdpXa4YI
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, May 09, 2002 at 03:51:08PM -0400, David Shaw wrote:
> On Thu, May 09, 2002 at 07:40:24PM +0000, Brian M. Carlson wrote:
>=20
> > I have set force-v4-certs in my options file. I also have
> > digest-algo RIPEMD160 set. Yet, my signatures still are made with
> > SHA1, which I deprecate strongly.  If I have a preference on my key,
> > I'd prefer that gpg choose that, unless I choose a digest-algo
> > option, in which case gpg uses that. gpg has done neither.
>=20
> Let me make sure I understand what you are doing.  You want your key
> signatures - not data signatures - to use RIPEMD160 and not SHA1?
>=20
> --digest-algo only applies to data signatures.
>=20
> Why do you strongly deprecate SHA1?

SHA1 was created by the US government. I feel that the US government does n=
ot
have its citizens best interest at heart in the realm of cryptography, and
sometimes not with privacy in general. I prefer RIPEMD160 as it was created
independently outside of the US. Anyway, whatever my reason, shouldn't it
be my choice?

digest-algo has worked before, with my RSA key and with my ElGamal 20 key (=
see
sig) on key signatures. I might be able to dig them up for you.

--=20
Brian M. Carlson
<karlsson@hal-pc.org>
OpenPGP: 0x351336B2DCA1913A

--bKyqfOwhbdpXa4YI
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Ubi libertas, ibi patria.

iQEVAwUBPNriMOWR/8lWBVPnAQMc1Af/Wm+U4ujICM9ur9JRxWBhRVR5zuiPhxVT
RtpmsROW/0opBSi3e1Y1BUwzO6f6z1M+1lD65xuTsCG57nzIsNNmgVI/CH7SZrBj
RXbp8DuLt0WTGsXvGrJRqGNrrPtLg9FsaGz+rWgylStNyujzg2dpNbDti6YkqoN5
IcFckpX5KxW3kIbFZ/9JR41LzxwiR4reZoiIrXCnkarGvSYlbtnSREkmYhdrSkaH
Dn+BY05stL4mfuKXEpuEAgK9qVIt14xx8QyjevlYkpl80AD5Hw+O1mR1eqb7OLnQ
NL8rBwOd4Dhgejq06WP3+pEujAqxssjRmOddPguvRbvbItwUAHLnaQ==
=SIup
-----END PGP SIGNATURE-----

--bKyqfOwhbdpXa4YI--


From karlsson@hal-pc.org  Thu May  9 23:58:01 2002
From: karlsson@hal-pc.org (Brian M. Carlson)
Date: Thu May  9 22:58:01 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <20020509195108.GE3323@akamai.com>
References: <20020509194024.GB6949@stonewall> <20020509195108.GE3323@akamai.com>
Message-ID: <20020509205912.GD6949@stonewall>

--at6+YcpfzWZg/htY
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, May 09, 2002 at 03:51:08PM -0400, David Shaw wrote:
> On Thu, May 09, 2002 at 07:40:24PM +0000, Brian M. Carlson wrote:
>=20
> > I have set force-v4-certs in my options file. I also have
> > digest-algo RIPEMD160 set. Yet, my signatures still are made with
> > SHA1, which I deprecate strongly.  If I have a preference on my key,
> > I'd prefer that gpg choose that, unless I choose a digest-algo
> > option, in which case gpg uses that. gpg has done neither.
>=20
> Let me make sure I understand what you are doing.  You want your key
> signatures - not data signatures - to use RIPEMD160 and not SHA1?

Yes. I want all my uses of the hash function for signatures to be with
RIPEMD160. I also use s2k-digest-algo RIPEMD160, but that is unrelated.=20

--=20
Brian M. Carlson
<karlsson@hal-pc.org>
OpenPGP: 0x351336B2DCA1913A

--at6+YcpfzWZg/htY
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Ubi libertas, ibi patria.

iQEVAwUBPNrjIOWR/8lWBVPnAQM1gAgAgtNXo8MtYjBW6bhwPPXZtWAQ5Ssl4UXD
Z07RkNGCe8ITiomTbddFWZO7o+gxEF0NX/eLaMTARtGmDqGWypeSpIuIGM1Z2qfG
vZ9wlUV9MZdvk0mmWhRpIlT1DzLpKsAwzOExUCPBZVV1X6ALUhjG7Y16RIzfVZZc
CzO+nyQIjRYO12iShNDQCVJW6R6751Fc6Cx/BViTu5FzAQ877VYrRi/Gls4E2+Al
Ke/M+su62b9jadyGRiiYC41DtEG/NIl8Mi+qGjwZRGt8PIJ45r3Ugg4tLjnfBjjr
vV5kWauq8CxR2O38Ty14EhTOFrUe518Abi36Hbuxgaqvqh/3GPSG4w==
=aAr/
-----END PGP SIGNATURE-----

--at6+YcpfzWZg/htY--


From rjhansen@inav.net  Fri May 10 00:21:01 2002
From: rjhansen@inav.net (Robert J. Hansen)
Date: Thu May  9 23:21:01 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <20020509205512.GC6949@stonewall>
References: <20020509194024.GB6949@stonewall>
 <20020509195108.GE3323@akamai.com>  <20020509205512.GC6949@stonewall>
Message-ID: <1020979199.32490.9.camel@numbers>

> SHA1 was created by the US government. I feel that the US government does not
> have its citizens best interest at heart in the realm of cryptography, and

SHA-1 isn't used for message security; it's used for message
authentication.  The NSA's mandate includes keeping US Gov't traffic
secure, and as such, deliberately creating a faulty hash
algorithm--especially one that's heavily used throughout the USG--would
be counter to the NSA's mandate.

Then there's also the intense peer review, and the fact that it's SHA-1,
not SHA-0... SHA-0 had a nasty, but very subtle, bug.  Who found the
bug, publicized it, and issued a fix?  The NSA.

While I agree there's a lot of room for skepticism on the NSA's motives,
it appears to me that throwing out SHA-1 is tossing the baby out with
the bathwater.  Still--if it floats your boat, use RIPEMD160.

> independently outside of the US. Anyway, whatever my reason, shouldn't it
> be my choice?

Not necessarily.  The axiom which guides GnuPG is "be liberal in what
you accept, but conservative in what you generate".  If I recall,
RIPEMD-160 is a SHOULD, not a MUST.  It would be entirely consistent and
RFC-conformant for GnuPG to accept RIPEMD-160 in traffic, but to only
use SHA-1 for output.

I'm not suggesting we do that, by the by.  I'm just pointing out that
"shouldn't it be my choice?" isn't always something you answer with a
"yes".  There's a time and a place for strict enforcement of policy.




From dshaw@jabberwocky.com  Fri May 10 00:31:01 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Thu May  9 23:31:01 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <20020509205512.GC6949@stonewall>
References: <20020509194024.GB6949@stonewall> <20020509195108.GE3323@akamai.com> <20020509205512.GC6949@stonewall>
Message-ID: <20020509213137.GB6484@akamai.com>

On Thu, May 09, 2002 at 08:55:13PM +0000, Brian M. Carlson wrote:
> On Thu, May 09, 2002 at 03:51:08PM -0400, David Shaw wrote:
> > On Thu, May 09, 2002 at 07:40:24PM +0000, Brian M. Carlson wrote:
> > 
> > > I have set force-v4-certs in my options file. I also have
> > > digest-algo RIPEMD160 set. Yet, my signatures still are made with
> > > SHA1, which I deprecate strongly.  If I have a preference on my key,
> > > I'd prefer that gpg choose that, unless I choose a digest-algo
> > > option, in which case gpg uses that. gpg has done neither.
> > 
> > Let me make sure I understand what you are doing.  You want your key
> > signatures - not data signatures - to use RIPEMD160 and not SHA1?
> > 
> > --digest-algo only applies to data signatures.
> > 
> > Why do you strongly deprecate SHA1?
> 
> SHA1 was created by the US government. I feel that the US government does not
> have its citizens best interest at heart in the realm of cryptography, and
> sometimes not with privacy in general. I prefer RIPEMD160 as it was created
> independently outside of the US. Anyway, whatever my reason, shouldn't it
> be my choice?

Sure, I'm just curious.

There is one "danger" of making RIPEMD160 key signatures, in that it
is not a required algorithm in OpenPGP.  There can be implementations
that do not support it, and so key signatures using it are not
universally usable.  This means that two different implementations may
have two different views of the web of trust, which is not a great
thing.

That said, they're your signatures, and you need to make them in a way
that you are comfortable with.  The two "bigs", PGP and GnuPG both
support RIPEMD160.

> digest-algo has worked before, with my RSA key and with my ElGamal
> 20 key (see sig) on key signatures. I might be able to dig them up
> for you.

ElGamal key signatures use RIPEMD160 by default.  What version of
GnuPG did you do the RSA one with?  It certainly couldn't have been
1.0.6 or 1.0.7.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From rabbi@quickie.net  Fri May 10 00:44:01 2002
From: rabbi@quickie.net (Len Sassaman)
Date: Thu May  9 23:44:01 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <1020979199.32490.9.camel@numbers>
Message-ID: <Pine.LNX.4.30.QNWS.0205091430390.10536-100000@thetis.deor.org>

On 9 May 2002, Robert J. Hansen wrote:

> Not necessarily.  The axiom which guides GnuPG is "be liberal in what
> you accept, but conservative in what you generate".  If I recall,
> RIPEMD-160 is a SHOULD, not a MUST.  It would be entirely consistent and
> RFC-conformant for GnuPG to accept RIPEMD-160 in traffic, but to only
> use SHA-1 for output.

First of all: RIPEMD-160 is neither a MUST or a SHOULD. (It's neither a
required, not suggested, algorithm in OpenPGP. Don't be surprised if
implementations do not support or understand RIPEMD-160 signatures).

Secondly, DSS is defined as requiring SHA-1. Consequently, SHA-1 has
received more attention than other 160-bit hash algorithms by
cryptographers. RIPEMD-160 is considered by many to be just as strong, but
it certainly hasn't received the same level of scrutiny.

Notice, also, that the security of PGP signatures is somewhat dependant
upon all of the hashes that the implementation allows. I draw your
attention to section 13 of RCF 2440bis05:

     * There is a somewhat-related potential security problem in
       signatures. If an attacker can find a message that hashes to the
       same hash with a different algorithm, a bogus signature
       structure can be constructed that evaluates correctly.

       For example, suppose Alice DSA signs message M using hash
       algorithm H. Suppose that Mallet finds a message M' that has the
       same hash value as M with H'. Mallet can then construct a
       signature block that verifies as Alice's signature of M' with
       H'. However, this would also constitute a weakness in either H
       or H' or both. Should this ever occur, a revision will have to
       be made to this document to revise the allowed hash algorithms.


So, if any of the hash algorithms are broken, we could be in quite a bit
of trouble. (This is my argument against adding in SHA-256, etc., until
there is a clear benefit (such as larger DSA keys) to doing so.)


Len



From karlsson@hal-pc.org  Fri May 10 01:25:02 2002
From: karlsson@hal-pc.org (Brian M. Carlson)
Date: Fri May 10 00:25:02 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <Pine.LNX.4.30.QNWS.0205091430390.10536-100000@thetis.deor.org>
References: <1020979199.32490.9.camel@numbers> <Pine.LNX.4.30.QNWS.0205091430390.10536-100000@thetis.deor.org>
Message-ID: <20020509222550.GE6949@stonewall>

--pY3vCvL1qV+PayAL
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, May 09, 2002 at 02:44:43PM -0700, Len Sassaman wrote:
> On 9 May 2002, Robert J. Hansen wrote:
>=20
> > Not necessarily.  The axiom which guides GnuPG is "be liberal in what
> > you accept, but conservative in what you generate".  If I recall,
> > RIPEMD-160 is a SHOULD, not a MUST.  It would be entirely consistent and
> > RFC-conformant for GnuPG to accept RIPEMD-160 in traffic, but to only
> > use SHA-1 for output.
>=20
> First of all: RIPEMD-160 is neither a MUST or a SHOULD. (It's neither a
> required, not suggested, algorithm in OpenPGP. Don't be surprised if
> implementations do not support or understand RIPEMD-160 signatures).

While this may be true, it is a de facto SHOULD, just like IDEA is.
=20
> Secondly, DSS is defined as requiring SHA-1. Consequently, SHA-1 has
> received more attention than other 160-bit hash algorithms by
> cryptographers. RIPEMD-160 is considered by many to be just as strong, but
> it certainly hasn't received the same level of scrutiny.

The last time I used my DSA key, other than to update its expiration date,
was over a year ago. I use my RSA key almost exclusively. When I don't, I
use my ElGamal type 20 key. (I know how you feel about ElGamal 20 keys ;-)
There is no reason that DSA couldn't use any other 160 bit hash. Neverthele=
ss,
I *do* use SHA1 with DSA.

> Notice, also, that the security of PGP signatures is somewhat dependant
> upon all of the hashes that the implementation allows. I draw your
> attention to section 13 of RCF 2440bis05:
<snip>

I am quite aware of the requirements for a collision-resistant hash functio=
n.
I own Applied Cryptography and have read it several times. I have also read
other works on the subject, including the definition of RIPEMD160.

--=20
Brian M. Carlson
<karlsson@hal-pc.org>
OpenPGP: 0x351336B2DCA1913A

--pY3vCvL1qV+PayAL
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Ubi libertas, ibi patria.

iQEVAwUBPNr3buWR/8lWBVPnAQOEHgf/VW62sV76aCca5/02aJxU1XaFrmsmbdKg
wyrngl6Q+AwIp/aS7WdjJrcQtL7B1d71fxh6e8NsNj2t3Nxcn4FJka49EmFzyzFb
189PLjqEEYa5gbYVaMrr6MAhFxa1pJWegpTfuGzba8uLVXdowZku76xwvMArldMC
i7pSnUDmPUh1yUjgmPMnDDHktkXjt9UvbuU96VTu2yxD54oOqhCeArxuaSENjXhA
GJyhJy4u9X3ShCB78M5eVfdl25JdZu2D7TFPuxV4Uh0TOqDKadBvei+pQYsComVc
mn4qxdJ2iwpquYOhGixcmHjgiNeP5UrzJaI7jW/YdM+I70Y6yqzNIw==
=zbnQ
-----END PGP SIGNATURE-----

--pY3vCvL1qV+PayAL--


From rabbi@quickie.net  Fri May 10 01:29:02 2002
From: rabbi@quickie.net (Len Sassaman)
Date: Fri May 10 00:29:02 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <20020509222550.GE6949@stonewall>
Message-ID: <Pine.LNX.4.30.QNWS.0205091526130.14462-100000@thetis.deor.org>

On Thu, 9 May 2002, Brian M. Carlson wrote:

> > First of all: RIPEMD-160 is neither a MUST or a SHOULD. (It's neither a
> > required, not suggested, algorithm in OpenPGP. Don't be surprised if
> > implementations do not support or understand RIPEMD-160 signatures).
>
> While this may be true, it is a de facto SHOULD, just like IDEA is.

Untrue. If it isn't listed as SHOULD in the document, it isn't a SHOULD.
There are no "de facto SHOULDs."

IDEA is a SHOULD in RFC 2440. Its status has since changed, I believe.





From rjhansen@inav.net  Fri May 10 05:47:01 2002
From: rjhansen@inav.net (Robert J. Hansen)
Date: Fri May 10 04:47:01 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <20020509222550.GE6949@stonewall>
References: <1020979199.32490.9.camel@numbers>
 <Pine.LNX.4.30.QNWS.0205091430390.10536-100000@thetis.deor.org>
 <20020509222550.GE6949@stonewall>
Message-ID: <1020998781.524.11.camel@numbers>

> While this may be true, it is a de facto SHOULD, just like IDEA is.

Be careful. Going further down this road will lead us to the World of
Microsoft.  There's a razor's edge between saying "we will support the
spec, including all SHOULDs" and saying "we will support the spec, plus
whatever additional things we feel are de-facto standards".  The one way
is the Free Software/Open Source way.  The other way is the Microsoft
Embrace and Extend way (q.v., their Kerberos implementation).

Unless the spec lists it as a MUST or a SHOULD, I honestly don't think
GnuPG should generate it.  Be liberal in what you accept, but very
conservative in what you generate.  (I know that Len says RIPEMD-160
isn't a SHOULD, and I have no reason to doubt him.  However, I haven't
checked RFC2440/2015/3156 myself yet, so I'll hedge it with an
`unless'.)

> There is no reason that DSA couldn't use any other 160 bit hash. Nevertheless,

Sure there is.  If DSA used any other 160-bit hash, it wouldn't be DSA
anymore because the DSA spec demands SHA.  Insofar as whether or not the
DSA spec could be changed to accept RIPEMD-160, and whether or not the
resulting system would still be secure... who knows?  Cryptosystems are
fragile things; known-strong algorithms can interact with each other to
produce weak systems.





From dshaw@jabberwocky.com  Fri May 10 07:23:01 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Fri May 10 06:23:01 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <1020998781.524.11.camel@numbers>
References: <1020979199.32490.9.camel@numbers> <Pine.LNX.4.30.QNWS.0205091430390.10536-100000@thetis.deor.org> <20020509222550.GE6949@stonewall> <1020998781.524.11.camel@numbers>
Message-ID: <20020510042351.GB662@akamai.com>

On Thu, May 09, 2002 at 09:46:18PM -0500, Robert J. Hansen wrote:

> Unless the spec lists it as a MUST or a SHOULD, I honestly don't think
> GnuPG should generate it.  Be liberal in what you accept, but very
> conservative in what you generate.  (I know that Len says RIPEMD-160
> isn't a SHOULD, and I have no reason to doubt him.  However, I haven't
> checked RFC2440/2015/3156 myself yet, so I'll hedge it with an
> `unless'.)

He's right.  SHA1 is the only MUST hash, and MD5 is the only SHOULD.

Still, the spec is not the beginning and the end of GnuPG.  GnuPG
certainly does things that are contrary to the spec (and documents
them carefully and gives the user the ability to turn them off).  For
example, when generating a clear signature, by default a line
beginning with "From " is escaped, probably in violation of a strict
reading of RFC2440.  The reason it does this is that clearsigned
documents are often emailed and otherwise the mail system would
probably break the signature when it changed "From " to ">From ".  PGP
does the same thing.

Another good example is the v3 sigs problem.  Most versions of PGP
don't handle v4 sigs on data, but the RFC says they are a SHOULD.  If
GnuPG blindly followed the SHOULD it would make itself incompatible
with PGP.

The --openpgp flag in GnuPG turns all of this off and makes it use a
rigid following of RFC2440.  If you use that flag though, you'll have
problems communicating with the rest of the world.

> > There is no reason that DSA couldn't use any other 160 bit hash. Nevertheless,
> 
> Sure there is.  If DSA used any other 160-bit hash, it wouldn't be DSA
> anymore because the DSA spec demands SHA.  Insofar as whether or not the
> DSA spec could be changed to accept RIPEMD-160, and whether or not the
> resulting system would still be secure... who knows?

Not quite correct.  The DSA algorithm can use any 160-bit hash.  The
DSS spec is DSA+SHA1 (plus some other details that don't matter here).
OpenPGP does not specify DSS signatures - it specifies DSA and can
thus use any 160-bit hash.

I agree with Len in general on being very careful with adding new
algorithms to OpenPGP, and in turn to GnuPG.  However, in the specific
case of RIPEMD-160, it's already part of the standard and both PGP and
GnuPG already support it.  There is no question on whether to add it -
it's already added.  There is also no evidence that it is not just as
secure as SHA1 is.

I don't see any particular reason for someone to not use RIPEMD-160
for data signatures - if there is a compatibility problem they're only
hurting themselves.  I do wish people would not use it for key
signatures, as a compatibility problem there affects the web of trust.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From Andreas.Lippek@DePfa.com  Fri May 10 08:59:02 2002
From: Andreas.Lippek@DePfa.com (Lippek, Andreas, IT-TR)
Date: Fri May 10 07:59:02 2002
Subject: unsubscribe
Message-ID: <A04A1C51B715E44C81D53F49C8DD08A70AD9D9@fraexx01.DEPFA-BANK.COM>


-----Original Message-----
From: Robert J. Hansen [mailto:rjhansen@inav.net]
Sent: Freitag, 10. Mai 2002 04:46
To: Brian M. Carlson
Cc: gnupg-devel@gnupg.org; rabbi@quickie.net
Subject: Re: force-v4-certs and digest-algo


> While this may be true, it is a de facto SHOULD, just like IDEA is.

Be careful. Going further down this road will lead us to the World of
Microsoft.  There's a razor's edge between saying "we will support the
spec, including all SHOULDs" and saying "we will support the spec, plus
whatever additional things we feel are de-facto standards".  The one way
is the Free Software/Open Source way.  The other way is the Microsoft
Embrace and Extend way (q.v., their Kerberos implementation).

Unless the spec lists it as a MUST or a SHOULD, I honestly don't think
GnuPG should generate it.  Be liberal in what you accept, but very
conservative in what you generate.  (I know that Len says RIPEMD-160
isn't a SHOULD, and I have no reason to doubt him.  However, I haven't
checked RFC2440/2015/3156 myself yet, so I'll hedge it with an
`unless'.)

> There is no reason that DSA couldn't use any other 160 bit hash.
Nevertheless,

Sure there is.  If DSA used any other 160-bit hash, it wouldn't be DSA
anymore because the DSA spec demands SHA.  Insofar as whether or not the
DSA spec could be changed to accept RIPEMD-160, and whether or not the
resulting system would still be secure... who knows?  Cryptosystems are
fragile things; known-strong algorithms can interact with each other to
produce weak systems.




_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel


From rabbi@quickie.net  Fri May 10 20:11:02 2002
From: rabbi@quickie.net (Len Sassaman)
Date: Fri May 10 19:11:02 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <1020998781.524.11.camel@numbers>
Message-ID: <Pine.LNX.4.30.QNWS.0205101003070.3958-100000@thetis.deor.org>

On 9 May 2002, Robert J. Hansen wrote:

> > While this may be true, it is a de facto SHOULD, just like IDEA is.
>
> Be careful. Going further down this road will lead us to the World of
> Microsoft.  There's a razor's edge between saying "we will support the
> spec, including all SHOULDs" and saying "we will support the spec, plus
> whatever additional things we feel are de-facto standards".  The one way
> is the Free Software/Open Source way.  The other way is the Microsoft
> Embrace and Extend way (q.v., their Kerberos implementation).

To further clarify what I was saying:

The entire point of the IETF, and of the RFC system, is to eliminate the
"de facto standards" mess, and give us actual standards.

> Unless the spec lists it as a MUST or a SHOULD, I honestly don't think
> GnuPG should generate it.  Be liberal in what you accept, but very
> conservative in what you generate.  (I know that Len says RIPEMD-160
> isn't a SHOULD, and I have no reason to doubt him.  However, I haven't
> checked RFC2440/2015/3156 myself yet, so I'll hedge it with an
> `unless'.)

Well, 2015/3156 don't cover this, so that's easy. But if you want to see
for yourself, it's section 9.4 of RFC2440bis5:

http://search.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-05.txt

> > There is no reason that DSA couldn't use any other 160 bit hash.
>
> Sure there is.  If DSA used any other 160-bit hash, it wouldn't be DSA
> anymore because the DSA spec demands SHA.  Insofar as whether or not the
> DSA spec could be changed to accept RIPEMD-160, and whether or not the
> resulting system would still be secure... who knows?  Cryptosystems are
> fragile things; known-strong algorithms can interact with each other to
> produce weak systems.

You are confusing DSA (the algorithm) with DSS (the standard). DSS
mandates DSA and SHA-1. DSA, however, could be used with any strong hash
function that is sufficiently long.

--Len.












From rjhansen@inav.net  Fri May 10 21:51:01 2002
From: rjhansen@inav.net (Robert J. Hansen)
Date: Fri May 10 20:51:01 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <Pine.LNX.4.30.QNWS.0205101003070.3958-100000@thetis.deor.org>
Message-ID: <Pine.LNX.4.44L0.0205101348180.7060-100000@soli.inav.net>

> The entire point of the IETF, and of the RFC system, is to eliminate the
> "de facto standards" mess, and give us actual standards.

... and to further elaborate my point (which follows from that): a 
standard quickly devolves to near-uselessness if people start extending it 
willy-nilly.  Look at the UNIX Wars, or "This Site Best Viewed In".  A 
standard ought be adhered to unless there are clear and compelling reasons 
not to do so.  I don't see any clear and compelling reason to use 
RIPEMD-160, and so I don't.  (Let me say, though, that it's not my 
intention to speak for anyone but me.)

> You are confusing DSA (the algorithm) with DSS (the standard). DSS

D'oh.  My goof.





From dshaw@jabberwocky.com  Fri May 10 22:19:01 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Fri May 10 21:19:01 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <Pine.LNX.4.44L0.0205101348180.7060-100000@soli.inav.net>
References: <Pine.LNX.4.30.QNWS.0205101003070.3958-100000@thetis.deor.org> <Pine.LNX.4.44L0.0205101348180.7060-100000@soli.inav.net>
Message-ID: <20020510192021.GA14633@akamai.com>

On Fri, May 10, 2002 at 01:52:32PM -0500, Robert J. Hansen wrote:
> > The entire point of the IETF, and of the RFC system, is to eliminate the
> > "de facto standards" mess, and give us actual standards.
> 
> ... and to further elaborate my point (which follows from that): a 
> standard quickly devolves to near-uselessness if people start extending it 
> willy-nilly.  Look at the UNIX Wars, or "This Site Best Viewed In".  A 
> standard ought be adhered to unless there are clear and compelling reasons 
> not to do so.  I don't see any clear and compelling reason to use 
> RIPEMD-160, and so I don't.  (Let me say, though, that it's not my 
> intention to speak for anyone but me.)

Just to be clear here, using RIPEMD-160 is completely and totally
adhering to the OpenPGP standard in every possible way.  There are
certainly minor compatibility reasons not to use it, but it is
definitely part of the standard.  To put this in context, other
completely optional parts of the standard are Blowfish, Twofish, and
every AES above 128 bits.

Using "Joe's Random Hash Algorithm 128" would be willy-nilly. ;)

Werner and I discussed it, and I've added the ability to pick the hash
when making a key signature (--cert-digest-algo) to 1.0.8.  I do hope
people will not use this feature (and the manual explains why it isn't
a good idea), but in the end, it is up to them what hash they use.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From dgc@uchicago.edu  Fri May 10 22:29:02 2002
From: dgc@uchicago.edu (David Champion)
Date: Fri May 10 21:29:02 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <20020510192021.GA14633@akamai.com>
References: <Pine.LNX.4.30.QNWS.0205101003070.3958-100000@thetis.deor.org> <Pine.LNX.4.44L0.0205101348180.7060-100000@soli.inav.net> <20020510192021.GA14633@akamai.com>
Message-ID: <20020510192938.GF9707@dust.uchicago.edu>

* On 2002.05.10, in <20020510192021.GA14633@akamai.com>,
*	"David Shaw" <dshaw@jabberwocky.com> wrote:
> 
> Using "Joe's Random Hash Algorithm 128" would be willy-nilly. ;)

But I've tested it thoroughly, and I'm certain it's quite secure -- our
reference code remains uncracked! The source is even available (for a
nominal licensing fee) to anyone who passes our trust audit. Why are you
repressing us?

--
Joe
Joe's Codes, Ltd.
Call for a quote! +1-900-SAF-CODE


From sandeep_sikka@hotmail.com  Sat May 11 01:12:02 2002
From: sandeep_sikka@hotmail.com (Sandeep Sikka)
Date: Sat May 11 00:12:02 2002
Subject: GPG 1.0.6 bug - sign/encrypt/decrypt 0 bytes.
Message-ID: <F1024t5BD8wbVGkJmiW00014762@hotmail.com>

Hi,

If I sign/encrypt & then decrypt 0 bytes, I get junk. I don't get 0 bytes. 
If I use even one byte, I have no problems. If I just encrypt/decrypt 0 
bytes, I get 0 bytes in return. But if I sign, I have problems. Is this a 
known bug with GPG? Or am I not understanding & using GPG properly?

Thanks!

Sandeep.

----
sikka@debian:~$ gpg --version
gpg (GnuPG) 1.0.6
Copyright (C) 2001 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.
----

sikka@debian:~$ gpg --list-keys
/u3/sikka/.gnupg/pubring.gpg
----------------------------
pub  1024D/85DEA7EC 2002-05-10 Sandeep Sikka (test key) 
<sikka@iamtesting.com>
sub  1024g/64B4BEA2 2002-05-10
----

# Encrypt 0 bytes - NO PROBLEM
sikka@debian:~$ echo -n | gpg -ea -r sikka@iamtesting.com -u 
sikka@iamtesting.com | gpg --decrypt
gpg: NOTE: secret key 85DEA7EC is NOT protected.
gpg: NOTE: secret key 85DEA7EC is NOT protected.
gpg: encrypted with 1024-bit ELG-E key, ID 64B4BEA2, created 2002-05-10
      "Sandeep Sikka (test key) <sikka@iamtesting.com>"
----

# Sign/encrypt one byte - NO PROBLEM
sikka@debian:~$ echo X | gpg -sea -r sikka@iamtesting.com -u 
sikka@iamtesting.com | gpg --decrypt
gpg: NOTE: secret key 85DEA7EC is NOT protected.
gpg: NOTE: secret key 85DEA7EC is NOT protected.
gpg: encrypted with 1024-bit ELG-E key, ID 64B4BEA2, created 2002-05-10
      "Sandeep Sikka (test key) <sikka@iamtesting.com>"
X
gpg: Signature made Fri May 10 18:05:33 2002 EDT using DSA key ID 85DEA7EC
gpg: Good signature from "Sandeep Sikka (test key) <sikka@iamtestng.com>"
----

# Sign/Encrypt 0 bytes - PROBLEM CASE
sikka@debian:~$ echo -n | gpg -sea -r sikka@iamtesting.com -u 
sikka@iamtesting.com | gpg --decrypt
gpg: NOTE: secret key 85DEA7EC is NOT protected.
gpg: NOTE: secret key 85DEA7EC is NOT protected.
gpg: encrypted with 1024-bit ELG-E key, ID 64B4BEA2, created 2002-05-10
      "Sandeep Sikka (test key) <sikka@iamtesting.com>"
?b<ÜDfbùú4RÞNbÄÃ ÁF>/èLErå9æCmÜsâ(×t
----











_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com



From dshaw@jabberwocky.com  Sat May 11 01:26:01 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Sat May 11 00:26:01 2002
Subject: GPG 1.0.6 bug - sign/encrypt/decrypt 0 bytes.
In-Reply-To: <F1024t5BD8wbVGkJmiW00014762@hotmail.com>
References: <F1024t5BD8wbVGkJmiW00014762@hotmail.com>
Message-ID: <20020510222724.GE14633@akamai.com>

On Fri, May 10, 2002 at 05:12:17PM -0500, Sandeep Sikka wrote:
> Hi,
> 
> If I sign/encrypt & then decrypt 0 bytes, I get junk. I don't get 0 bytes. 
> If I use even one byte, I have no problems. If I just encrypt/decrypt 0 
> bytes, I get 0 bytes in return. But if I sign, I have problems. Is this a 
> known bug with GPG? Or am I not understanding & using GPG properly?

This was fixed in GnuPG 1.0.7.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From benfell@greybeard95a.com  Sun May 12 08:07:01 2002
From: benfell@greybeard95a.com (David Benfell)
Date: Sun May 12 07:07:01 2002
Subject: configure produces zero length Makefile
In-Reply-To: <040301c1f050$f71bf8e0$ede3c23f@KR6X.ORG>
References: <040301c1f050$f71bf8e0$ede3c23f@KR6X.ORG>
Message-ID: <20020512050748.GF17531@raven.parts-unknown.org>

--FN+gV9K+162wdwwF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello all,

When I ran configure (with --prefix=3D/usr), I observed the following:

configure: creating ./config.status
config.status: creating Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating intl/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating po/Makefile.in
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating util/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating mpi/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating cipher/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating g10/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating keyserver/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating keyserver/gpgkeys_mailto
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating keyserver/gpgkeys_test
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating doc/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating tools/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating zlib/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating checks/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating config.h
config.status: config.h is unchanged
config.status: linking ./mpi/i386/mpih-add1.S to mpi/mpih-add1.S
config.status: linking ./mpi/i386/mpih-mul1.S to mpi/mpih-mul1.S
config.status: linking ./mpi/i386/mpih-mul2.S to mpi/mpih-mul2.S
config.status: linking ./mpi/i386/mpih-mul3.S to mpi/mpih-mul3.S
config.status: linking ./mpi/i386/mpih-lshift.S to mpi/mpih-lshift.S
config.status: linking ./mpi/i386/mpih-rshift.S to mpi/mpih-rshift.S
config.status: linking ./mpi/i386/mpih-sub1.S to mpi/mpih-sub1.S
config.status: linking ./mpi/generic/mpi-asm-defs.h to
mpi/mpi-asm-defs.h
config.status: creating po/POTFILES
config.status: creating po/Makefile
g10defs.h is unchanged

                Configured for: GNU/Linux (i686-pc-linux-gnu)
    Dynamically linked modules: rndunix rndegd tiger
     Statically linked modules: rndlinux sha1 rmd160 md5

make: *** No targets.  Stop.
root@home:/usr/local/src/gnupg-1.0.7 # ls -al Makefile*
-rw-r--r--    1 root     root            0 May  1 22:51 Makefile
-rw-r--r--    1 1000     1000         1800 Dec 21 11:49 Makefile.am
-rw-rw-r--    1 1000     1000        16187 Apr 29 08:06 Makefile.in

I tried attaching the configure log, but this caused the e-mail to
exceed the 40KB limit for posting.

This is on a SuSE 7.1 system which has been heavily upgraded, mostly
from source.


--=20
David Benfell, LCP
benfell@parts-unknown.org
---
Resume available at http://www.parts-unknown.org/resume.html

--FN+gV9K+162wdwwF
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iQEXAwUBPN34pHw5zqzgtjVOFANyiQP+K4WF/Blma96kAoPpp2UcW+5icMc6r4/L
lxC3csAUn5lCKHvuLMEpQoOUYHvS0fbIPQAc2GLdkwdyihPXsO5pMSF65/QennDY
XvEFZcgQVkpgW7RAqMzV3iLVPJLCkjeQqx3uMwFFqpiZm6LPnp+2Ce2xDmyXWGJk
LqyTRC8k0F8D/AwH0OSKeerkovm3pDc4YrrzZ5pLhQlG6pNp8j3sVZ6Wc3jb/YV9
2sLHb/k+o1uw7wPIp3R8v7OEd0smVgr6qb9r4ZMRdyBV2TbzZs2sXIqbkXHYeN94
D+zWJRcH1ZlSveQt0aCuUxKEEiEbvXLx1z0Hyf2CcZxD9qCyqOUiDBkr
=TMp9
-----END PGP SIGNATURE-----

--FN+gV9K+162wdwwF--


From srm_dfr@hotmail.com  Sun May 12 17:16:02 2002
From: srm_dfr@hotmail.com (eloj %20)
Date: Sun May 12 16:16:02 2002
Subject: encrypting to public key crashes gnupg 1.0.6-2 (win32)
Message-ID: <F125KpO2DTSWFSSEfLM00015e40@hotmail.com>

I was helping a friend set up GnuPG 1.0.6-2 Win32 yesterday. When all was 
set up we discovered that no-one seemed able to encrypt to his key.

The crash is reproducably on several installations.

'The instruction at "0x74fad613" referenced memory at "0x024a5000". The 
memory could not be "written".'

I haven't bothered testing on 1.0.7 since there is no officiall win32-port 
yet.

Anyone willing to take a look at the key and see if they can reproduce the 
problem? A developer with a what-will-become win32 build maybe.

I won't post the key here since the secret key doesn't exist any more and 
there is no revocation should it slip into the wild, but if anyone wants it 
contact me at eddy klopper net.


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.



From redbird@rbisland.cx  Sun May 12 19:58:01 2002
From: redbird@rbisland.cx (Gordon Worley)
Date: Sun May 12 18:58:01 2002
Subject: configure produces zero length Makefile
In-Reply-To: <20020512050748.GF17531@raven.parts-unknown.org>
Message-ID: <3057365C-65C9-11D6-A13F-000A27B4DEFC@rbisland.cx>

On Sunday, May 12, 2002, at 01:07  AM, David Benfell wrote:

> make: *** No targets.  Stop.
> root@home:/usr/local/src/gnupg-1.0.7 # ls -al Makefile*
> -rw-r--r--    1 root     root            0 May  1 22:51 Makefile
> -rw-r--r--    1 1000     1000         1800 Dec 21 11:49 Makefile.am
> -rw-rw-r--    1 1000     1000        16187 Apr 29 08:06 Makefile.in

This looks a lot like what happens on Darwin.  While it's not likely the 
same but, it's worth mentioning that if your sh is really zsh, you need 
to go through the configure script and change all instances of 'CDPATH=' 
to 'unset CDPATH'.

--
Gordon Worley                     `When I use a word,' Humpty Dumpty
http://www.rbisland.cx/            said, `it means just what I choose
redbird@rbisland.cx                it to mean--neither more nor less.'
PGP:  0xBBD3B003                                  --Lewis Carroll



From benfell@greybeard95a.com  Mon May 13 01:25:01 2002
From: benfell@greybeard95a.com (David Benfell)
Date: Mon May 13 00:25:01 2002
Subject: configure produces zero length Makefile
In-Reply-To: <3057365C-65C9-11D6-A13F-000A27B4DEFC@rbisland.cx>
References: <20020512050748.GF17531@raven.parts-unknown.org> <3057365C-65C9-11D6-A13F-000A27B4DEFC@rbisland.cx>
Message-ID: <20020512222543.GA803@raven.parts-unknown.org>

--opJtzjQTFsWo+cga
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, 12 May 2002 12:56:22 -0400, Gordon Worley wrote:
>=20
> On Sunday, May 12, 2002, at 01:07  AM, David Benfell wrote:
>=20
> >make: *** No targets.  Stop.
> >root@home:/usr/local/src/gnupg-1.0.7 # ls -al Makefile*
> >-rw-r--r--    1 root     root            0 May  1 22:51 Makefile
> >-rw-r--r--    1 1000     1000         1800 Dec 21 11:49 Makefile.am
> >-rw-rw-r--    1 1000     1000        16187 Apr 29 08:06 Makefile.in
>=20
> This looks a lot like what happens on Darwin.  While it's not likely the=
=20
> same but, it's worth mentioning that if your sh is really zsh,

Yup, I did that.  I hate bash.  I'd had some problems with
initialization scripts as a result but solved those with simpler,
customized language.

> you need=20
> to go through the configure script and change all instances of 'CDPATH=3D=
'=20
> to 'unset CDPATH'.
>=20
Good catch.  Really good catch.  Thank you.

--=20
David Benfell
benfell@parts-unknown.org
---
There's an old proverb that says just about whatever you want it to.
                                [from fortune]

--opJtzjQTFsWo+cga
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iQEXAwUBPN7r53w5zqzgtjVOFAPNjgP/dX6kgpVCSzo+OcVIYjkSD1GxvhG5XJg2
Z+GaPWdIWrX/tqfYW/OjP8KyIHJXKXY+faIlUcLHiAlfAJYBTMzecJxLJZSxbvAk
wvMOt9tki4EFlmGvrvCNs26j4wOWzmV0nEby7s5DJtWY+QKcx2aLFCrgA/k/0gMz
e9Ilf9o1ApYEAIPfaTCDgeR2Ki0xv/1F0W2V37f95yECF6dQdXSgTy8k2ZdCS+3l
pHJiMEHPlSvdPNTuqwIJ+dtjzj02RUbldjt6tsu7vmRatdX7MfL+WbuE0eSULhpy
GqW8SiVszaQ1AH/Ck3mioZ/Qh53jpMPmek95d+LJnqGSeulImmyBa8S9
=xzIa
-----END PGP SIGNATURE-----

--opJtzjQTFsWo+cga--


From request@logos.net  Mon May 13 07:11:02 2002
From: request@logos.net (request@logos.net)
Date: Mon May 13 06:11:02 2002
Subject: Verba Volant
Message-ID: <E1777dv-00057k-00@porta.u64.de>

13-MAY-02
We have been requested to insert the following email address, "gnupg-devel@gnupg.org", in the Verba Volant Newsletter database. Through this daily service you will receive a quotation, selected from amongst the most celebrated philosophers, writers and poets of all time and translated into many languages and dialects by volunteers worldwide.
If you would like to confirm your subscription to Verba Volant, please click on the following link: 
http://www.logos.net/owa-l/press.subscribe?lang=en&email=gnupg-devel@gnupg.org 
If you do not wish to click on the link, your subscription will be cancelled.
Thank you for your time.
Verba Volant



13-MAY-02
Il nous a été demandé d'ajouter l'adresse électronique "gnupg-devel@gnupg.org" dans la liste des destinataires de Verba Volant, un service qui tous les jours vous adressera une citation sélectionnée parmi les œuvres des meilleurs philosophes, écrivains, poètes de tous les temps et traduite en de très nombreuses langues grâce à des volontaires du monde entier.
Pour confirmer l'inscription à Verba Volant, veuillez vous connecter au lien suivant:
http://www.logos.net/owa-l/press.subscribe?lang=fr&email=gnupg-devel@gnupg.org 
Si vous préférez ne pas cliquer sur le lien, vous ne recevrez rien.

Merci dans tous les cas de nous avoir accordé quelques secondes.
Verba Volant



13-MAY-02
Se nos ha solicitado insertar la dirección de correo electrónico "gnupg-devel@gnupg.org" en el listado de envíos de Verba Volant, un servicio que diariamente le enviará citas elegidas entre los mejores filosofos, escritores, poetas, etc., traducidas a varios idiomas y dialectos. Dichas citas están traducidas por voluntarios que se conectan a nuestra web desde todo el mundo.
Si quiere confirmar la suscripción a Verba Volant, le rogamos entre en: 
http://www.logos.net/owa-l/press.subscribe?lang=es&email=gnupg-devel@gnupg.org 
Si no entra en la dirección señalada no recibirá las citas.
Muchas gracias por el tiempo que nos ha dedicado.
Verba Volant



13-MAY-02
Ci è stato chiesto di inserire l'indirizzo di posta elettronica "gnupg-devel@gnupg.org" nell’elenco dei destinatari di Verba Volant, un servizio che ogni giorno ti invierà una citazione scelta tra quelle dei migliori filosofi, scrittori, poeti di tutti i tempi e tradotta in moltissime lingue e dialetti grazie alla collaborazione di volontari da tutto il mondo.
Se desideri confermare l'iscrizione, ti preghiamo di collegarti al seguente link:
http://www.logos.net/owa-l/press.subscribe?lang=it&email=gnupg-devel@gnupg.org 
Nel caso preferissi non cliccare sul link, non riceverai nulla. 

Grazie comunque per i secondi che ci hai dedicato.
Cordiali saluti.






From wk@gnupg.org  Mon May 13 10:17:07 2002
From: wk@gnupg.org (Werner Koch)
Date: Mon May 13 09:17:07 2002
Subject: [Administriva] MLs closed
Message-ID: <87wuu8tt1s.fsf@alberti.gnupg.de>

Hi!

I am getting annoyed of all the spam so I finally closed the mailing
lists.  From now on only subscribers are allowed to post.  Messages
from non-subscribers are held for approval but the chance that I find
time to actual approve a message is not very high.  Hopefully we don't
get too much spam with faked From addresses.

If someone wants to volunteer as a listmaster please drop me a note.

  Werner



From Fabian.Rodriguez@Toxik.com  Tue May 14 00:24:01 2002
From: Fabian.Rodriguez@Toxik.com (Toxik - Fabian Rodriguez)
Date: Mon May 13 23:24:01 2002
Subject: Verifying signatures via WWW interface
In-Reply-To: <F1024t5BD8wbVGkJmiW00014762@hotmail.com>
Message-ID: <MJEDILLCNFHIFGNJHDMGAELHDNAA.Fabian.Rodriguez@Toxik.com>

Hello,

I'd like to know if it's logical to offer to people to verify signatures of
short texts via a web interface. I'm trying to understand some other
applications of OpenPGP/gnupg.

I thought having public keys of the signers on a local keyring would be
enough but GPG sends these warnings after displaying date and author
information:

  Could not find a valid trust path to the key.  Let's see whether we
  can assign some missing owner trust values.

  No path leading to one of our keys found.

  gpg: WARNING: This key is not certified with a trusted signature!
  gpg:          There is no indication that the signature belongs to the
owner.
  gpg: Fingerprint: A6EF 1DF9 39CC 873C 5855  D7BA 93E0 2B96 73AE 57A0

Of course, we don't want to store a private key for this particular
application, what would be required to have a trust path ? The local keyring
only has public keys in this example.

Thanks for any information on this.

Fabián Rodríguez - Toxik Technologies, Inc.
www.toxik.com · (514) 528-6945 @221
OpenPGP: 0x5AF2A4D5




From dmitri@users.sourceforge.net  Tue May 14 00:41:02 2002
From: dmitri@users.sourceforge.net (Dmitri)
Date: Mon May 13 23:41:02 2002
Subject: Verifying signatures via WWW interface
In-Reply-To: <MJEDILLCNFHIFGNJHDMGAELHDNAA.Fabian.Rodriguez@Toxik.com>
References: <MJEDILLCNFHIFGNJHDMGAELHDNAA.Fabian.Rodriguez@Toxik.com>
Message-ID: <1021326141.10775.387.camel@usb.networkfab.com>

--=-gZHvrlblTtvpVcErg0oN
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Mon, 2002-05-13 at 14:22, Toxik - Fabian Rodriguez wrote:

> I'd like to know if it's logical to offer to people to verify signatures =
of
> short texts via a web interface.

As long as you don't mind sending your plaintext over the network, and
telling anyone who cares to sniff the traffic what messages and who
receives, and from who, and when...

> I thought having public keys of the signers on a local keyring would be
> enough but GPG sends these warnings after displaying date and author
> information:
>=20
>   Could not find a valid trust path to the key.  Let's see whether we
>   can assign some missing owner trust values.
>=20
>   No path leading to one of our keys found.
>=20
>   gpg: WARNING: This key is not certified with a trusted signature!
>   gpg:          There is no indication that the signature belongs to the
> owner.

You need to sign the public key of that other person. It will tell GnuPG
that you believe that the key belongs to that person. You should find
more detailed explanations in many places, such as www.gnupg.org ...

Dmitri


--=-gZHvrlblTtvpVcErg0oN
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA84DM9XksyLpO6T4IRAmonAJ4vxm2ezpDKvIxCoQWIbMHdM/gvvgCeIy/K
Wy9CSIJMcJaEZIWAGLcvOqs=
=geGL
-----END PGP SIGNATURE-----

--=-gZHvrlblTtvpVcErg0oN--



From gnupg-devel@gnupg.org  Tue May 14 01:08:02 2002
From: gnupg-devel@gnupg.org (Matthew Byng-Maddick)
Date: Tue May 14 00:08:02 2002
Subject: Verifying signatures via WWW interface
In-Reply-To: <1021326141.10775.387.camel@usb.networkfab.com>; from dmitri@users.sourceforge.net on Mon, May 13, 2002 at 02:42:21PM -0700
References: <MJEDILLCNFHIFGNJHDMGAELHDNAA.Fabian.Rodriguez@Toxik.com> <1021326141.10775.387.camel@usb.networkfab.com>
Message-ID: <20020513230901.A26054@colon.colondot.net>

On Mon, May 13, 2002 at 02:42:21PM -0700, Dmitri wrote:
> On Mon, 2002-05-13 at 14:22, Toxik - Fabian Rodriguez wrote:
> > I'd like to know if it's logical to offer to people to verify signatures of
> > short texts via a web interface.
> As long as you don't mind sending your plaintext over the network, and
> telling anyone who cares to sniff the traffic what messages and who
> receives, and from who, and when...

This is less of an issue (since we're talking about verifying signatures,
it may well have come in in plaintext) than an ability to trust that the
website is not just telling you that a signature is verified, without
having bothered to do the calculation. Or alternatively telling you it
isn't when it might have done.

It's easier to verify that a binary on your disk hasn't been modified.

MBM

-- 
Matthew Byng-Maddick         <mbm@colondot.net>           http://colondot.net/


From lists@lina.inka.de  Tue May 14 01:24:02 2002
From: lists@lina.inka.de (Bernd Eckenfels)
Date: Tue May 14 00:24:02 2002
Subject: Verifying signatures via WWW interface
In-Reply-To: <MJEDILLCNFHIFGNJHDMGAELHDNAA.Fabian.Rodriguez@Toxik.com>
References: <F1024t5BD8wbVGkJmiW00014762@hotmail.com> <MJEDILLCNFHIFGNJHDMGAELHDNAA.Fabian.Rodriguez@Toxik.com>
Message-ID: <20020513222452.GA30503@lina.inka.de>

On Mon, May 13, 2002 at 05:22:01PM -0400, Toxik - Fabian Rodriguez wrote:
> Of course, we don't want to store a private key for this particular
> application, what would be required to have a trust path ? The local keyring
> only has public keys in this example.

You can eighter ignore the message or lsign all your keys in the keying with
a "trusted" key. you do not need to store the trusted key on the system, you
can mark a public key as trusted. this is used like this:

a) user sends you key, you verify it and sign it
b) you store the signed key on a automatic signature checking device. in
order to avoid to have to store your signature generating key on that device
you just place the public key there and mark it trusted. this has the
advantage (over blindly trusting al keys in keyring) that adding keys to the
keyring is not a priveledged application and does not need a trusted channel
to the verifier.

hope this is clear, i use this for a B2Bi Server which is able to check
incoming messages from trading partners and decides if they are known, based
on a "accept" lsign from operating staff. this even works with a keyserver.

Greetings
Bernd


From aphex@nullify.org  Wed May 15 00:45:07 2002
From: aphex@nullify.org (Keith Ray)
Date: Tue May 14 23:45:07 2002
Subject: GnuPG 1.0.7a+ DIRSEP
Message-ID: <1021412756.3ce185948636c@mail.nullify.org>

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

I have noticed that new DIRSEPs have been committed to the GnuPG 1.07a+
tree.  I would like to include them in a future win32 release, but I am
unsure about whether to change certain paths or not.

Currently, I use the following defaults:

[HKEY_CURRENT_USER\Control Panel\Mingw32\NLS]
"MODir"="C:/GnuPG/Locale"

[HKEY_CURRENT_USER\Software\GNU\GnuPG]
"HomeDir"="C:/GnuPG"

load-extension Lib/idea
load-extension Lib/tiger
load-extension Lib/sha2

Should all of these be changed from '/' to '\' in 1.0.7a+ versions?

  -- Keith

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (MingW32) - GPGshell v2.28

iD8DBQE84YQuBxrjkHkmmhIRAnpmAJ9NWRLU6zqvEVM99nfagGOk31xSTwCdEtoA
bt5GQF46qvVrfBhgVBCQCiI=
=xzfO
-----END PGP SIGNATURE-----


From aphex@nullify.org  Fri May 17 01:50:02 2002
From: aphex@nullify.org (Keith Ray)
Date: Fri May 17 00:50:02 2002
Subject: [BUG FIX] Win32 Performance Counters
Message-ID: <1021589460.3ce437d487922@mail.nullify.org>

In cipher/rndw32.c, GnuPG attempts to gather physical disk performance counter
data for random number generation.  However, if the IOCTL_DISK_PERFORMANCE call
fails for any reason, GPG displays:

"NOTE: you should run 'diskperf -y' to enable the disk statistics"

I created a debug version of GnuPG and called GetLastError() and got:

"The data area passed to a system call is too small."

I did some investigating and found that the Win32 header files from Mingw32/CPD
are incorrect.  Both the LARGE_INTEGER and DISK_PERFORMANCE struct are smaller
than required.  Once these changes were made, I was able to produce a working
GnuPG that successfully called IOCTL_DISK_PERFORMANCE.  However, GCC gave the
following warning:

In file included from
/usr/local/lib/mingw32-cpd/lib/gcc-lib/i386--mingw32/2.95.2wk20010117/../../../../i386--mingw32/include/windows.h:48,
                 from rndw32.c:69:
/usr/local/lib/mingw32-cpd/lib/gcc-lib/i386--mingw32/2.95.2wk20010117/../../../../i386--mingw32/include/Windows32/Structures.h:1080:
warning: unnamed struct/union that defines no instances


mingw32-cpd/i386--mingw32/include/Windows32/Structures.h
--------------------------------------------------------

typedef struct _LARGE_INTEGER {
  DWORD LowPart;
  LONG  HighPart;
} LARGE_INTEGER, *PLARGE_INTEGER;

typedef struct _DISK_PERFORMANCE {
  LARGE_INTEGER BytesRead;
  LARGE_INTEGER BytesWritten;
  LARGE_INTEGER ReadTime;
  LARGE_INTEGER WriteTime;
  DWORD ReadCount;
  DWORD WriteCount;
  DWORD QueueDepth;
} DISK_PERFORMANCE ;


Microsoft Platform SDK\Include\WinIoCtl.h
-----------------------------------------

typedef struct _DISK_PERFORMANCE {
        LARGE_INTEGER BytesRead;
        LARGE_INTEGER BytesWritten;
        LARGE_INTEGER ReadTime;
        LARGE_INTEGER WriteTime;
        LARGE_INTEGER IdleTime;
        DWORD ReadCount;
        DWORD WriteCount;
        DWORD QueueDepth;
        DWORD SplitCount;
        LARGE_INTEGER QueryTime;
        DWORD   StorageDeviceNumber;
        WCHAR   StorageManagerName[8];
} DISK_PERFORMANCE, *PDISK_PERFORMANCE;


Microsoft Platform SDK\Include\WinNT.h
--------------------------------------

typedef union _LARGE_INTEGER {
    struct {
        DWORD LowPart;
        LONG HighPart;
    };
    struct {
        DWORD LowPart;
        LONG HighPart;
    } u;
    LONGLONG QuadPart;
} LARGE_INTEGER;


From keith@nullify.org  Fri May 17 11:33:01 2002
From: keith@nullify.org (Keith Ray)
Date: Fri May 17 10:33:01 2002
Subject: GnuPG 1.0.7a+ DIRSEP
Message-ID: <1021412447.3ce1845f9a7bd@mail.nullify.org>

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

I have noticed that new DIRSEPs have been committed to the GnuPG 1.07a+
tree.  I would like to include them in a future win32 release, but I am
unsure about whether to change certain paths or not.

Currently, I use the following defaults:

[HKEY_CURRENT_USER\Control Panel\Mingw32\NLS]
"MODir"="C:/GnuPG/Locale"

[HKEY_CURRENT_USER\Software\GNU\GnuPG]
"HomeDir"="C:/GnuPG"

load-extension Lib/idea
load-extension Lib/tiger
load-extension Lib/sha2

Should all of these be changed from '/' to '\' in 1.0.7a+ versions?

  -- Keith

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (MingW32) - GPGshell v2.28

iD8DBQE84YQuBxrjkHkmmhIRAnpmAJ9NWRLU6zqvEVM99nfagGOk31xSTwCdEtoA
bt5GQF46qvVrfBhgVBCQCiI=
=xzfO
-----END PGP SIGNATURE-----


From chris@netservers.co.uk  Fri May 17 11:33:04 2002
From: chris@netservers.co.uk (Chris Wilson)
Date: Fri May 17 10:33:04 2002
Subject: Operation on read-only filesystem
Message-ID: <Pine.LNX.4.44.0205151157380.11907-200000@localhost>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

--8323328-471549807-1021460765=:11907
Content-Type: TEXT/PLAIN; charset=US-ASCII

Dear GnuPG developers,

I have been trying to get GnuPG working on a read-only filesystem, and I 
think I have hit the same problem as Patrick Higgins 
(http://lists.gnupg.org/pipermail/gnupg-devel/2000-July/005221.html), that 
the trust database is opened read-write. His suggestion of a --read-only 
option seems like a good one. If I wrote a patch to add this option, would 
anyone care to integrate it with GnuPG?

I have also been maintaining my batch-sign patch, and just updated it to 
GPG 1.0.7. This fixes what I believe to be a bug in GnuPG, that for no 
apparent reason, signing keys is disabled in batch-mode. The patch is very 
simple, and I hope you will consider applying it.

Cheers, Chris.
-- 
   ___ __     _
 / __// / ,__(_)_  | Chris Wilson -- UNIX Firewall Lead Developer |
/ (_ / ,\/ _/ /_ \ | NetServers.co.uk http://www.netservers.co.uk |
\ _//_/_/_//_/___/ | 21 Signet Court, Cambridge, UK. 01223 576516 |

--8323328-471549807-1021460765=:11907
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="gpg-batchsign-1.0.7.patch"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.44.0205151206050.11907@localhost>
Content-Description: 
Content-Disposition: attachment; filename="gpg-batchsign-1.0.7.patch"

ZGlmZiAtcnUyIGdudXBnLTEuMC43L2cxMC9rZXllZGl0LmMgZ251cGctMS4w
LjctY2hyaXMvZzEwL2tleWVkaXQuYw0KLS0tIGdudXBnLTEuMC43L2cxMC9r
ZXllZGl0LmMJTW9uIEFwciAyOSAxNTozNDoyMSAyMDAyDQorKysgZ251cGct
MS4wLjctY2hyaXMvZzEwL2tleWVkaXQuYwlXZWQgTWF5IDE1IDExOjUyOjMz
IDIwMDINCkBAIC04NzEsNCArODcxLDEyIEBADQogICAgIGludCBoYXZlX2Nv
bW1hbmRzID0gISFjb21tYW5kczsNCiANCisgICAgaWYoIHNpZ25fbW9kZSAp
IHsNCisgICAgICAgIGNvbW1hbmRzID0gTlVMTDsNCisgICAgICAgIGFwcGVu
ZF90b19zdHJsaXN0KCAmY29tbWFuZHMsIHNpZ25fbW9kZSA9PSAxPyAic2ln
biI6DQorICAgICAgICAgICAgICAgICAgICAgICAgICAgc2lnbl9tb2RlID09
IDI/ImxzaWduIjoNCisgICAgICAgICAgICAgICAgICAgICAgICAgICBzaWdu
X21vZGUgPT0gMz8ibnJzaWduIjoibnJsc2lnbiIpOw0KKyAgICAgICAgaGF2
ZV9jb21tYW5kcyA9IDE7DQorICAgIH0NCisNCiAgICAgaWYgKCBvcHQuY29t
bWFuZF9mZCAhPSAtMSApDQogICAgICAgICA7DQpAQCAtODc2LDEyICs4ODQs
NCBAQA0KIAlsb2dfZXJyb3IoXygiY2FuJ3QgZG8gdGhhdCBpbiBiYXRjaG1v
ZGVcbiIpKTsNCiAJZ290byBsZWF2ZTsNCi0gICAgfQ0KLQ0KLSAgICBpZigg
c2lnbl9tb2RlICkgew0KLQljb21tYW5kcyA9IE5VTEw7DQotCWFwcGVuZF90
b19zdHJsaXN0KCAmY29tbWFuZHMsIHNpZ25fbW9kZSA9PSAxPyAic2lnbiI6
DQotCQkJICAgc2lnbl9tb2RlID09IDI/ImxzaWduIjoNCi0JCQkgICBzaWdu
X21vZGUgPT0gMz8ibnJzaWduIjoibnJsc2lnbiIpOw0KLQloYXZlX2NvbW1h
bmRzID0gMTsNCiAgICAgfQ0KIA0K
--8323328-471549807-1021460765=:11907--


From andy.ozment@cc.gatech.edu  Fri May 17 11:33:06 2002
From: andy.ozment@cc.gatech.edu (Andy Ozment)
Date: Fri May 17 10:33:06 2002
Subject: Wrong signature on idea.c, broken link
Message-ID: <3CE2BF5E.C58AAD75@cc.gatech.edu>

I'm new to gpg, so I apologize if these "bugs" are really my ignorance
rather than a bug.

1. In an attempt to get the idea module, I went to the page
<http://www.gnupg.org/why-not-idea.html>

I downloaded the files idea.c and idea.c.sig. I then tried to check the
sig:
$ gpg --verify idea.c.sig idea.c
gpg: Warning: using insecure memory!
gpg: please see http://www.gnupg.org/faq.html for more information
gpg: Signature made Fri Aug 17 03:34:05 2001 EDT using DSA key ID
621CC013
gpg: Can't check signature: public key not found

$ gpg --list-keys
pub  1024D/57548DCD 1998-07-07 Werner Koch (gnupg sig) <dd9jn@gnu.org>

It appears to me, then, that idea.c was not signed with the key that
signed the entire distribution (57548DCD, Werner Koch). Is this
intentional? I could not find the key that did sign the file anywhere on
the site.



2. On a completely different note, on the page
<http://www.gnupg.org/docs.html>, the link "list of bugs" which points
to <http://bugs.guug.de/Bugs/db/pa/lgnupg.html> is broken.


Please copy any responses to me, as I am not a member of this list.
Again, if this is not really a mistake and is just me being dumb, then I
apologize for being an annoying newbie!
Thanks!
Andy

-- 
  Andy Ozment
  Research Scientist
  Georgia Tech College of Computing


From avbidder@fortytwo.ch  Fri May 17 18:16:01 2002
From: avbidder@fortytwo.ch (Adrian 'Dagurashibanipal' von Bidder)
Date: Fri May 17 17:16:01 2002
Subject: secure sign & encrypt
Message-ID: <1021648640.7790.33.camel@atlas>

--=-ivbC0F0YEu2PvLP9b4+Z
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Yo!

After having read the paper refernced in the ongoing 'signing &
encrypting' thread on gpg-users

http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html

I feel that these flaws are quite serious, as non-experts (like me)
almost automatically assume end-to-end security if they receive
encrypted mail. I'm not on this list very long, so I didn't get previous
discussions of this (are theare *searchable* archives?)

How about this extension of the openPGP standard:

the signature (openpgp-)packet of a signed & encrypted msg includes an
additional (signed!!!) subpacket of the new type 'intended encryption
key'. when gpg is told to verify a message and finds such a subpacket,
it prints an error message if=20
 - the message is not encrypted
 - the message is encrypted, but not with the intended key.
conventional signed & encrypted msgs produce a warning along the lines
of 'it can not be asserted that this message was encrypted by the
original sender. See <URL> for more information'.

(Of course, more than one 'intended encryption key' subpackets must be
allowed)

Yes, this is not rfc - but I got the impression that the gpg people are
not against extending the standard if there are valid reasons (cf.
picture id)


And while I'm at it (though this is tangential here, I know):

extension to the OpenPGP-MIME RFC 3156: Add the To:, From: and Subject:
headers of the mail to the (signed) MIME headers of multipart/signed
msgs and bug the mailreader people to verify the mail headers with
these.



comments?
-- vbi


--=20
secure email with gpg                 avbidder@fortytwo.ch: key id
0x92082481
                                      avbidder@acter.ch:    key id
0x5E4B731F


--=-ivbC0F0YEu2PvLP9b4+Z
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA85R8Awj49sl5Lcx8RAoCrAJ4gCplIzL9U8Y4AAaQ7frEEQ2jCDwCeIwRY
W/I1c7oXs6zxmSt0mlGzGJw=
=TqKC
-----END PGP SIGNATURE-----

--=-ivbC0F0YEu2PvLP9b4+Z--


From jharris@widomaker.com  Fri May 17 21:10:02 2002
From: jharris@widomaker.com (Jason Harris)
Date: Fri May 17 20:10:02 2002
Subject: Wrong signature on idea.c, broken link
In-Reply-To: <3CE2BF5E.C58AAD75@cc.gatech.edu>
References: <3CE2BF5E.C58AAD75@cc.gatech.edu>
Message-ID: <20020517181046.GA317@p5.widomaker.com>

--FL5UXtIhxfXey3p5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, May 15, 2002 at 04:04:46PM -0400, Andy Ozment wrote:

> I'm new to gpg, so I apologize if these "bugs" are really my ignorance
> rather than a bug.

You've been using (commercial) PGP all this time?  :(

> 1. In an attempt to get the idea module, I went to the page
> <http://www.gnupg.org/why-not-idea.html>
>=20
> I downloaded the files idea.c and idea.c.sig. I then tried to check the
> sig:
> $ gpg --verify idea.c.sig idea.c
> gpg: Warning: using insecure memory!
> gpg: please see http://www.gnupg.org/faq.html for more information
> gpg: Signature made Fri Aug 17 03:34:05 2001 EDT using DSA key ID
> 621CC013
> gpg: Can't check signature: public key not found
>=20
> $ gpg --list-keys
> pub  1024D/57548DCD 1998-07-07 Werner Koch (gnupg sig) <dd9jn@gnu.org>
>=20
> It appears to me, then, that idea.c was not signed with the key that
> signed the entire distribution (57548DCD, Werner Koch). Is this
> intentional? I could not find the key that did sign the file anywhere on
> the site.

Use the keyservers, Luke!

(However, it doesn't look like Werner has cross-signed all his keys...)

pub  1024D/621CC013 1998-07-07 Werner Koch <werner.koch@guug.de>
     Key fingerprint =3D ECAF 7590 EB34 43B5 C7CF  3ACB 6C7E E1B8 621C C013
sig?       FF3EAA0B 1998-07-07  [User id not found]
sig        0C9857A5 1998-07-08  Werner Koch <werner.koch@guug.de>
sig        9265FAFB 2001-11-03  Derek Gaston <dgaston@umr.edu>
sig        513AEFD9 2000-09-25  Hans-Joerg Hoexer <hshoexer@rommel.stw.uni-=
erlangen.de>
sig        82957B66 2000-07-11  Hideki Saito <hideki@allcity.net>
sig        C5E88112 2000-02-22  Ruediger Hahn <ruedi007@topmail.de>
sig        5B0358A2 1999-03-15  Werner Koch <wk@gnupg.org>
sig        B1CC03AA 1999-06-21  Javier Kohen <jkohen@tough.com>
sig        621CC013 1999-11-12  Werner Koch <werner.koch@guug.de>
uid                            Werner Koch <wk@gnupg.org>
sig        5B0358A2 2000-10-01  Werner Koch <wk@gnupg.org>
sig        621CC013 2000-11-21  Werner Koch <werner.koch@guug.de>
uid                            Werner Koch <wk@openit.de>
sig        513AEFD9 2000-09-25  Hans-Joerg Hoexer <hshoexer@rommel.stw.uni-=
erlangen.de>
sig        82957B66 2000-07-11  Hideki Saito <hideki@allcity.net>
sig        621CC013 2000-11-21  Werner Koch <werner.koch@guug.de>
sig        90F89A7D 2001-01-25  Ralf Hildebrandt <ralf.hildebrandt@innomina=
te.com>

--=20
Jason Harris          | NIC:  JH329, PGP:  This _is_ PGP-signed, isn't it?
jharris@widomaker.com | web:  http://jharris.cjb.net/

--FL5UXtIhxfXey3p5
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (FreeBSD)

iD8DBQE85UekSypIl9OdoOMRAlGUAJ9owXz90w6Gyif3eh05r4UKYyW9aACfV631
KtD2tVaXe1WTcNKy1ha40xs=
=0YDU
-----END PGP SIGNATURE-----

--FL5UXtIhxfXey3p5--


From Max V. Zinal" <Zlat0@mail.ru  Mon May 20 20:14:01 2002
From: Max V. Zinal" <Zlat0@mail.ru (Max V. Zinal)
Date: Mon May 20 19:14:01 2002
Subject: A modified version of GnuPG
Message-ID: <16924836432.20020518205413@mail.ru>

------------144917F14ED878C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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

Hello everyone, have a nice time of day.

I've  made  some  changes to GnuPG 1.0.7, so now I have a version
built  under  MS  Windows with MS Visual C++ 6.0 compiler, linked
together  with zlib 1.1.4, and having support for *secure memory*
under  Windows.  I  did  my best to ensure that my changes do not
break any existing code under any ever-used platform.

I  think that this changes can be useful for project maintainers,
so they could include all this stuff into the future release.

I  would  like to know, are the project maintainers interested in
getting  my alterations, and if the answer is 'YES', how should I
send these alterations for them.

To show that my modified GPG works, I sign this message with it.
My public key is attached in a file.

- --
Best regards,
 Max                          mailto:zinal0@gibinsoft.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7a (x86-winnt)

iD8DBQE85ocj4scuxnLoWOARAnu0AJsGqiLj/iq6TOKevDG8vXsdI14aXwCfUdvz
ocu0KiQ5mnUBA5KU3ZI9T60=
=f9Ts
-----END PGP SIGNATURE-----
------------144917F14ED878C
Content-Type: application/octet-stream; name="MaxZinal.gpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="MaxZinal.gpg"

LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tDQpWZXJzaW9uOiBHbnVQRyB2MS4w
LjcgKE1pY3Jvc29mdCBXaW5kb3plKQ0KDQptUUdpQkR6amxJMFJCQURlYUdGRk9reUJLVmhZc0I4
ZklDam1OZnpDTFBRVC8xYjRIZ0hiWnFUZURaWXhSamJRDQpUbmJhVnExa2dFQjFNSmJ0MDB6Kys5
aDNPTEdKOGZteDBKRGpNa1hWRlFQaEliejJXSUY4UHNwS1M4aWY4bmc4DQpPRFR0VDIySmJ3Q1BE
WWxKWmRFdVU5RHdPdllQRm1VMXZNRFZiRGRDd0RCZlo2OExUbWt2eXZsYlN3Q2c2U2FpDQpFMVU1
NEFFRzJGQ1VXQUpjbVQveTlBVUQvMWVtQ3d1eFN5TU8xeno2ZkcxR2p3L3BpbkN3cnhmbjVmS3dX
TFBDDQpMbmRjQ3o3MWxoRDdkQjdwV01CUTNSUFpPeWlLQkV4OFlYZkJXdytQSDJvWTE4Z0ZQY2ti
dVdNTmJzSGdlN0N0DQpScnM4UnFBd1lsRmtQdmpzbTQzdElSV1BvTE44eWF1UmdSY1grYWpOVC84
ZzdXRU9WcnhJcGp2b0tTMUt1bzlrDQpOYjE1QS85Y1dXYTM5RDFoc3hjc1VRVENpZUdNNnJyMkpB
MDJBTk1aVC94MVZDeTdoN3VpenJEVDBRWkdrb2VFDQpHYkRUd3pGNU9Kd3A0UzZlOEhKWFRFSmJ0
UnBTQW1kQXI1RisyRUo2R1JMYi9BRmVBQi9sbnRVQWxCdGI3UjA5DQpEZ0Qrek9MM01rQW12eEdt
WWZtZ0ZKdm9wbE83VUVRbVVySzNTZ29CcHAvNmJvOXZaN1FpVFdGNElGWXVJRnBwDQpibUZzSUR4
NmFXNWhiRUJuYVdKcGJuTnZablF1Ym1WMFBvaFpCQk1SQWdBWkJRSTg0NVNOQkFzSEF3SURGUUlE
DQpBeFlDQVFJZUFRSVhnQUFLQ1JEaXh5N0djdWhZNEN4WkFKd0x3bjhuUzNiWUIyN1BQTWtoY3lE
OVF1WVRtQUNnDQpnTE9TcUxXblhoK2U4NTJtTmxOaXd5SFQ2RmE1QVkwRVBPT1ZtQkFHQU1FTm82
T1RYTVhKVDlic1NKNld4bjJkDQo2dHZrNXl6R25wUWMrOFc0MDhtMkg0QjRZcUhMVlY4ZVhoSDF1
UVBReFVpUnJnc3ZxZzhzZ0Ryd0owQjBlZGVXDQoyVmE0MDdMWXR2Q1JnWDlHVHpua24wUWl5VEYr
RlQvbU9iMkExV2JHQWN1MmF3dk9IaXFXWkJIN3gxMTFXbStNDQpLSldNbS9jU1FRNTl3MFJTWUJ4
TzFEb3Z6NzZBQVpYcW1jUjJxODZMQktQb2U1dFFDVmEyUHV3aXE1ZUlVVFlDDQoyV2E4cWVRT1p1
QXNRZUNZaUlNTENrWUMvNEt6d0dtYnNtN2ZrYVlteHdBREJRWUFoM1ArdWkrdnpVSXRDenFpDQpt
WDkyVkIrNUdlazdhY2UyMmRNYTF4cWswRVF3YVQzZlhOYVB3Y3BXTlQwbGN1dTNrTVowMVVXek1C
WFZUUUcxDQpOblFMdERWaGc2RUVmMDZJN3VHU09tR3ZvNjg2UTk1SmsycFlYTVVPSG1Eb1lubnY0
TnpQSkVLaHlLT2liK3lsDQpZMWpHeUZrKzFNN1VVL0x5K3VLbHB6bGgxbFJXV0pwdDhMRTluNXhi
Sml2aWk1Yk5XQW90RVJCbVVYaTRqUWZRDQpqWlB3aFRld01Ic24yMlBMUmRDM3ZJTXc5dHhNSzR0
V0c4ZHBSekszK1hkRFZKYVJpRVlFR0JFQ0FBWUZBanpqDQpsWmdBQ2drUTRzY3V4bkxvV09DS01n
Q1pBVGFoWTRLTXV4dEkrZlZKYk9RNllsYXFOcmdBb0tLaVdQRGxQN1N1DQpZb0E1QWZvQzlqbncx
R0xsDQo9dHh0cA0KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxPQ0stLS0tLQ0K

------------144917F14ED878C--



From 21442@gmx.net  Mon May 20 20:14:04 2002
From: 21442@gmx.net (Jure)
Date: Mon May 20 19:14:04 2002
Subject: Symmetric encription in batch mode
Message-ID: <3CE6C692.F61D9523@gmx.net>

> On Thu Jan 03 2002; 22:00, Bernard wrote:
> 
> IMO, you can send the data with the passphrase at the begin like this:
> "stupid_passphrase\n"
> "raw/text data"
> 
> I used this style in early code of WinPT and it seems to work. It's
> only important that you add a '\n' to the end because gpg expected
> one line for the passphrase.
> 
> 
> There is another way you can choose for sending the passphrase down
> to gpg. With the --command-fd switch you can control all gpg input.
> In the case gpg needs a passphrase the --status-fd output is:
> [GNUPG:] GET_HIDDEN passphrase.enter
> and then you can send the data with the pipe. I know this way is
> more complicated because you need two additional pipes (status,
> command) but it's the tidiest way.

I came across exactly the same problem: how to pass the passphrase to
gnupg when doing symmetric encryption/decryption from a Java program. In
my program, I am trying to do something like this:

encrypt(InputStream plainText, OutputStream cipherText, String password);

(For example, suppose that a stream coming from one network connection has
to be encrypted and send to other network connection). To accomplish this,
I would like gpg.exe to read plainText from stdin and write output to
stdout. Using --passphrase-fd to specify passphrase presents two problems:

1. how to separate passphrase from data (prepending passphrase + '\n' is a
rather inelegant and possibly dangerous approach)

2. it simply doesn't work - although my program pipes the entire stream
(passphrase + '\n' + data) to gpg's input and receives something which
appears to be the gpg's header - that's where gpg hangs. I suppose this is
an issue of file descriptors (either due to a problem in OS, Java process
implementation, or a gpg's way of handling descriptors).

Realizing security issues, I am nevertheless convinced that the ease of
GnuPG reading the passphrase from an environment variable would greatly
outweight many problems that users (including me) who would like to embed
GnuPG in their own solutions, are confronted with, and are now forced to
invent problematic workarounds like the use of batch files.

So, how about supporting an environment variable (e.g. GPG_PASSPHRASE),
just like PGP does? Of course, a warning should be included wherever it
appears throughout documentation.

Forgive me if this has already been discussed - I did not find any trace
of it.

Jure


From emil@la.mine.nu  Mon May 20 20:14:06 2002
From: emil@la.mine.nu (Emil)
Date: Mon May 20 19:14:06 2002
Subject: --no-tty
Message-ID: <20020519095449.GA19764@localhost>

# gpg --version
gpg (GnuPG) 1.0.7

# gpg --no-tty --batch --cipher-algo IDEA -r emil -r emil -ea play.lst
gpg: emil: skipped: public key already present
gpg: this cipher algorithm is deprecated; please use a more standard one!

Isn't --no-tty supposed to mean _NO_ tty whatsoever ?

-- 
								Regards,
								Emil
--
"To be or not to be"	  -Shakespeare
"To do is to be"	  -Socrates
"To be is to do"	  -Sartre
"To be do be do"	  -Sinatra


From kokhong@post1.com  Mon May 20 20:14:07 2002
From: kokhong@post1.com (Soh Kok Hong)
Date: Mon May 20 19:14:07 2002
Subject: GnuPG for Win32
Message-ID: <3CE879E5.4060200@post1.com>

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

Dear all,

I have a 68-line diff file to patch the stock gnupg-1.0.7.tar.gz to
build a mingw32 executable in the standard cygwin environment.  It
mainly patches the configure scripts and one source file (rndw32.c).  I
would like to know if the gnupg maintainers are interested and to whom
can I email the patch to?

Please email to me directly as I am not on the list.


- --
*************************************************
Soh Kok Hong

kokhong@post1.com PGP Signature:
D18B FC65 2202 3E43 A2D3 90D2 7BCC ABD3 77CE CD1C
*************************************************
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE86Hnle8yr03fOzRwRAn8EAKDHTgi8snN8aBTtUGMzb1N92/h78gCg/esk
EWCm1xQ2nO7Nd3VsJ+HRn90=
=c2w+
-----END PGP SIGNATURE-----



From pgut001@cs.auckland.ac.nz  Tue May 21 07:21:01 2002
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
Date: Tue May 21 06:21:01 2002
Subject: A modified version of GnuPG
Message-ID: <200205210421.QAA220469@ruru.cs.auckland.ac.nz>

"Max V. Zinal" <Zlat0@mail.ru> writes:

>I've made some changes to GnuPG 1.0.7, so now I have a version built under MS
>Windows with MS Visual C++ 6.0 compiler, linked together with zlib 1.1.4, and
>having support for *secure memory* under Windows.

Could you explain what you mean by "secure memory"?  There are a variety of
interpretations possible, some erroneous (in general the term "secure memory"
is an oxymoron in an OS which has functions like VirtualProtect() and
ReadProcessMemory(), so a bit more detail would be useful).

Peter.


From wk@gnupg.org  Tue May 21 10:16:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Tue May 21 09:16:01 2002
Subject: --no-tty
In-Reply-To: <20020519095449.GA19764@localhost> (Emil's message of "Sun, 19
 May 2002 05:54:49 -0400")
References: <20020519095449.GA19764@localhost>
Message-ID: <87u1p2rmrh.fsf@alberti.gnupg.de>

On Sun, 19 May 2002 05:54:49 -0400, Emil  said:

> Isn't --no-tty supposed to mean _NO_ tty whatsoever ?

No, it does only make sure never to write to the tty directly (i.e. it
does not open /dev/tty).  The tty may be required to ask for a
passphrase even when stderr has been redirected.  Avoiding all
informational output is done by redirecting stderr to /dev/zero

  Werner



From wk@gnupg.org  Tue May 21 10:22:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Tue May 21 09:22:01 2002
Subject: GnuPG for Win32
In-Reply-To: <3CE879E5.4060200@post1.com> (Soh Kok Hong's message of "Mon,
 20 May 2002 12:21:57 +0800")
References: <3CE879E5.4060200@post1.com>
Message-ID: <87offarmid.fsf@alberti.gnupg.de>

On Mon, 20 May 2002 12:21:57 +0800, Soh Kok Hong said:

> I have a 68-line diff file to patch the stock gnupg-1.0.7.tar.gz to
> build a mingw32 executable in the standard cygwin environment.  It

Thanks but it does not make sense to use this because GnuPG builds
fine as a native Windows program.  The Cygwin32 version may lead not
serious interoperabilty problems when used by other programs expecting
a plain Windows binary.

Yes, I know there is some stuff in GnuPG to allow building under
Cygwin but this already makes the code more complex and error prone,
so it is not really maintained anymore.

  Werner



From dbely@mail.ru  Tue May 21 10:54:01 2002
From: dbely@mail.ru (Dmitry Bely)
Date: Tue May 21 09:54:01 2002
Subject: GnuPG for Win32
In-Reply-To: <87offarmid.fsf@alberti.gnupg.de> (Werner Koch's message of
 "Tue, 21 May 2002 09:24:58 +0200")
References: <3CE879E5.4060200@post1.com> <87offarmid.fsf@alberti.gnupg.de>
Message-ID: <ptzqaqit.fsf@mail.ru>

Werner Koch <wk@gnupg.org> writes:

>> I have a 68-line diff file to patch the stock gnupg-1.0.7.tar.gz to
>> build a mingw32 executable in the standard cygwin environment.  It
>
> Thanks but it does not make sense to use this because GnuPG builds
> fine as a native Windows program.  The Cygwin32 version may lead not
> serious interoperabilty problems when used by other programs expecting
> a plain Windows binary.

Where have you seen a Cygwin32 version? He was talking about the patches
that would let building Mingw32 version with the native Win32 tools
(Mingw32 compiler is included into Cygwin distribution). The fact that
Mingw version of GnuPG cannot be build under Windows out-of-the-box (and so
Windows users cannot participate in its debugging/development) looks
strange to me if not to say more...

Hope to hear from you soon,
Dmitry




From avbidder@fortytwo.ch  Tue May 21 11:24:02 2002
From: avbidder@fortytwo.ch (Adrian 'Dagurashibanipal' von Bidder)
Date: Tue May 21 10:24:02 2002
Subject: secure sign & encrypt
In-Reply-To: <200205171138.51248.rjhansen@inav.net>
References: <1021648640.7790.33.camel@atlas>
 <200205171138.51248.rjhansen@inav.net>
Message-ID: <1021969508.14022.39.camel@atlas>

--=-qlPInynfxfswG9+89RgT
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Fri, 2002-05-17 at 18:38, Robert J. Hansen wrote:

> Davis' `exploit' (in 1.1) basically boils down to this: if you can't trus=
t=20
> the person you're talking to, then the person you're talking to can use=20
> your words in ways you don't like.  Is that a problem?  Sure.  But it's a=
=20
> social problem, not a technological one.  It demands social solutions, no=
t=20
> different cryptographic standards.

Agreed that the exploit is not really technological. The programs do
exactly as told. From the senders point of view I agree fully to what
you say. BUT if somebody receives an encrypted message he will almost
always automatically assume secure end to end communication - which may
not be the case. The open question is basically if the user should be
educated that the software does not work the way they think (hard, I
think), or if the software should be modified to match the users
(reasonable, imho) expectations.

--=20
secure email with gpg                 avbidder@fortytwo.ch: key id
0x92082481
                                      avbidder@acter.ch:    key id
0x5E4B731F


--=-qlPInynfxfswG9+89RgT
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA86gRkwj49sl5Lcx8RApkTAJwKz0M8/q3Mdmdq0ngygNQG9lufTACgkISh
l9dTJC2VTYbGUjjoc4NXVWE=
=oE4v
-----END PGP SIGNATURE-----

--=-qlPInynfxfswG9+89RgT--



From m-lesser@better-com.de  Tue May 21 16:59:02 2002
From: m-lesser@better-com.de (Martin Lesser)
Date: Tue May 21 15:59:02 2002
Subject: Error or feature in g10.c?
Message-ID: <87ptzpsisz.fsf@nb-acer.better-com.de>

After updating from 1.0.6 to 1.0.7 we ran into problems with an app
which uses --run-as-shm-coprocess (gabber, see also
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=146740 )

I know that use of shm-routines in gnupg is deprecated and should be
replaced with --command-fd.

Since rev. 1.129.2.82 of g10.c there's an
  #undef USE_SHM_COPROCESSING
which in the current version is additionally commented with "huh ?"

What's the reason for inserting this #undef (especially at this point)?
In the archives I could not find any hint.

Commenting out this line solved the problem with gabber but I'm not sure
wether this is correct. IMO it is possible that other apps also make use
of the shm-routines. If so they could run into problems too.

Martin


From wk@gnupg.org  Tue May 21 19:50:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Tue May 21 18:50:01 2002
Subject: Error or feature in g10.c?
In-Reply-To: <87ptzpsisz.fsf@nb-acer.better-com.de> (Martin Lesser's message
 of "21 May 2002 15:59:40 +0200")
References: <87ptzpsisz.fsf@nb-acer.better-com.de>
Message-ID: <87d6vpqw67.fsf@alberti.gnupg.de>

On 21 May 2002 15:59:40 +0200, Martin Lesser said:

> What's the reason for inserting this #undef (especially at this point)?
> In the archives I could not find any hint.

Fixed:

  * g10.c (main): Removed the undef of USE_SHM_COPROCESSING which
  was erroneously introduced on 2002-01-09.

> Commenting out this line solved the problem with gabber but I'm not sure
> wether this is correct. IMO it is possible that other apps also make use

It is.

Thanks,

  Werner



From Max V. Zinal" <Zlat0@mail.ru  Tue May 21 20:40:01 2002
From: Max V. Zinal" <Zlat0@mail.ru (Max V. Zinal)
Date: Tue May 21 19:40:01 2002
Subject: Re[2]: A modified version of GnuPG
In-Reply-To: <200205210421.QAA220469@ruru.cs.auckland.ac.nz>
References: <200205210421.QAA220469@ruru.cs.auckland.ac.nz>
Message-ID: <1387186383.20020521213928@mail.ru>

Tuesday, May 21, 2002, 8:21:18 AM, Peter Gutmann wrote:

PG> Could you explain what you mean by "secure memory"?  There are a variety of
PG> interpretations possible, some erroneous (in general the term "secure memory"
PG> is an oxymoron in an OS which has functions like VirtualProtect() and
PG> ReadProcessMemory(), so a bit more detail would be useful).

When I said "secure memory" I was going to say "VirtualLock under
Windows  NT/2000/XP",  which keeps you absolutely safe unless you
have  a  Terminal  Server  with  an  evil-minded admin, or remote
desktop    connection    with    'Debug' privileges.

As  you  know,  most  of  old  and modern OSes have no protection
against  a  person that has administrative rights. Linux, Windows
or  something  else  -  'a  good admin means a long life'. Any OS
which  allows a programmer to use debug facility may be unsecure.
Of  course,  if  we  are  talking about Win9x/ME (which should be
called  'Mustdie  Edition',  I  think), even with VirtualLock you
cannot be absolutely shure.

I have e-mailed my modifications to
        Timo Schulz <twoaday@freakmail.de>
who said he would like to receive them.

Sorry for unexcellent English.

-- 
Best regards,
 Max V. Zinal



From wk@gnupg.org  Wed May 22 10:04:02 2002
From: wk@gnupg.org (Werner Koch)
Date: Wed May 22 09:04:02 2002
Subject: A modified version of GnuPG
In-Reply-To: <1387186383.20020521213928@mail.ru> ("Max V. Zinal"'s message
 of "Tue, 21 May 2002 21:39:28 +0400")
References: <200205210421.QAA220469@ruru.cs.auckland.ac.nz>
 <1387186383.20020521213928@mail.ru>
Message-ID: <878z6cpso2.fsf@alberti.gnupg.de>

On Tue, 21 May 2002 21:39:28 +0400, Max V Zinal said:

> When I said "secure memory" I was going to say "VirtualLock under
> Windows  NT/2000/XP",  which keeps you absolutely safe unless you

I guess you didn't read Peter's papers on this.  VirtualLock is not
suitable for this.  The only way to protect memory from swapping is by
allocating it with the device helper functions:  An ISR may need
memory buffers and these buffers should never be subject to any paging
- the pager may need the service of that ISR - this is the reason why
you are able to allocate non-pageable memory for a device driver.

When GnuPG talks about "secure memory" it actually means "non-pageable
memory".  There can't be any protection against an almighty
admin/root/superuser.

  Werner



From avbidder@fortytwo.ch  Wed May 22 10:50:02 2002
From: avbidder@fortytwo.ch (Adrian 'Dagurashibanipal' von Bidder)
Date: Wed May 22 09:50:02 2002
Subject: secure sign & encrypt
In-Reply-To: <200205211132.09336.rjhansen@inav.net>
References: <1021648640.7790.33.camel@atlas>
 <200205171138.51248.rjhansen@inav.net> <1021969508.14022.39.camel@atlas>
 <200205211132.09336.rjhansen@inav.net>
Message-ID: <1022053889.12048.32.camel@atlas>

--=-Z8G8Y2477TfMVHktYfb7
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Tue, 2002-05-21 at 18:32, Robert J. Hansen wrote:
> > not be the case. The open question is basically if the user should be
> > educated that the software does not work the way they think (hard, I
> > think), or if the software should be modified to match the users
> > (reasonable, imho) expectations.
>=20
> "To every sociological problem there exists a technological solution whic=
h=20
> is cheap, easy, and wrong."
>=20

Why do locks exist, then? The existence of thieves is a purely
sociological problem, after all, and so one should not try to solve it
with technological means.

I agree it'd be breaking (I'd call it extending, but call it what you
want). But I argue that it's just automating a task the user presently
has to do manually.

Currently, to get secure, authenticated end-to-end encryption with gpg,
the sender has to sign/encrypt/sign, which presently requires at least 2
gpg invocations, and the recipient has to manually verify that the inner
and the outer signature match.=20

What I propose does basically just automate this task. It might do so by
literally sign/encrypt/sign, or by encrypt/sign[intended ecryption
keys|msg] (cf my proposal) - it's not the issue which of the two is
happening, though I believe the latter to be more elegant.=20

And I want to stress again that having an end-to-end encrypted channel
is imho a fairly basic requirement of a cryptosystem and is what the
average user is probably expecting to have if he is at the receiving end
of an encrypted channel.

cheers
-- vbi

--=20
secure email with gpg                 avbidder@fortytwo.ch: key id
0x92082481
                                      avbidder@acter.ch:    key id
0x5E4B731F


--=-Z8G8Y2477TfMVHktYfb7
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA8604Bwj49sl5Lcx8RAtmNAJ0fYD5r7s1hlNj5Ve5QMuQHDrCpxgCfetUz
px4yEN6v/VMxgFItAF31nrU=
=q7bS
-----END PGP SIGNATURE-----

--=-Z8G8Y2477TfMVHktYfb7--



From roconnor@Math.Berkeley.EDU  Wed May 22 11:03:01 2002
From: roconnor@Math.Berkeley.EDU (Russell O'Connor)
Date: Wed May 22 10:03:01 2002
Subject: strncasecmp
Message-ID: <Pine.SOL.4.33.0205220100420.17494-100000@blue3.math.berkeley.edu>

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

I was building Gnupg 1.0.7 for OS/2 and I had to manually add strncasecmp
to util/strutil.c

This probably should be added to the source files, along with the
appropriate changes to configure.

- -- 
Russell O'Connor                           roconnor@math.berkeley.edu
           <http://www.math.berkeley.edu/~roconnor/>
``Later generations will regard set theory as a disease from which one
has recovered.'' -- Poincare
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (SunOS)
Comment: For info see http://www.gnupg.org

iD8DBQE861EKuZUa0PWVyWQRAlAwAJ9o5ilHoWGp6xdYXnEZy3CqRRPMpQCfREAn
HWL5wUGr+X+QK4zSe1lucts=
=UqVR
-----END PGP SIGNATURE-----



From apm35@student.open.ac.uk  Wed May 22 11:32:01 2002
From: apm35@student.open.ac.uk (Andrew Marlow)
Date: Wed May 22 10:32:01 2002
Subject: strncasecmp
In-Reply-To: <Pine.SOL.4.33.0205220100420.17494-100000@blue3.math.berkeley.edu>
References: <Pine.SOL.4.33.0205220100420.17494-100000@blue3.math.berkeley.edu>
Message-ID: <fc.004c540101aa85a33b9aca0013090653.1aa85d3@oufcnt2.open.ac.uk>

roconnor@math.berkeley.edu writes:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>I was building Gnupg 1.0.7 for OS/2 and I had to manually add strncasecmp
>to util/strutil.c
>
>This probably should be added to the source files, along with the
>appropriate changes to configure.

I disagree.
Some environments have strncasecmp and others don't. I usually define my
own version of strncasecmp and the implementation differs from environment
to environment. Where I can implement it in terms of strncasecmp I do so,
otherwise I hand-code it. No direct calls to strncasecmp appear in the
code since it is a portability issue.

Regards,

Andrew M.



From sbellon@sbellon.de  Wed May 22 11:33:01 2002
From: sbellon@sbellon.de (Stefan Bellon)
Date: Wed May 22 10:33:01 2002
Subject: strncasecmp
In-Reply-To: <Pine.SOL.4.33.0205220100420.17494-100000@blue3.math.berkeley.edu>
References: <Pine.SOL.4.33.0205220100420.17494-100000@blue3.math.berkeley.edu>
Message-ID: <4b3a87c92bsbellon@sbellon.de>

Russell O'Connor wrote:
> I was building Gnupg 1.0.7 for OS/2 and I had to manually add
> strncasecmp to util/strutil.c

I think I fixed that two days after the 1.0.7 release:

2002-05-10  Stefan Bellon  <sbellon@sbellon.de>

        * g10.c, hkp.c, keyedit.c, keyserver.c: Replaced all occurrances
        of strcasecmp with ascii_strcasecmp and all occurrances of
        strncasecmp with ascii_memcasecmp.

So, neither strcasecmp nor strncasecmp is necessary anymore. Perhaps
you could try with a CVS build again?

Greetings,

Stefan.

-- 
 Stefan Bellon * <mailto:sbellon@sbellon.de> * <http://www.sbellon.de/>
 PGP 2 and OpenPGP keys available from my home page

 We have commited to quickly disseminate high-quality leadership skills
 and collaboratively restore low-risk high-yield meta-services to meet
 our customers needs.


From wk@gnupg.org  Wed May 22 11:36:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Wed May 22 10:36:01 2002
Subject: strncasecmp
In-Reply-To: <Pine.SOL.4.33.0205220100420.17494-100000@blue3.math.berkeley.edu> ("Russell
 O'Connor"'s message of "Wed, 22 May 2002 01:04:22 -0700 (PDT)")
References: <Pine.SOL.4.33.0205220100420.17494-100000@blue3.math.berkeley.edu>
Message-ID: <87znyso9to.fsf@alberti.gnupg.de>

On Wed, 22 May 2002 01:04:22 -0700 (PDT), Russell O'Connor said:

> I was building Gnupg 1.0.7 for OS/2 and I had to manually add strncasecmp
> to util/strutil.c

How did you implement the random number generator?




From wk@gnupg.org  Wed May 22 12:20:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Wed May 22 11:20:01 2002
Subject: strncasecmp
In-Reply-To: <4b3a87c92bsbellon@sbellon.de> (Stefan Bellon's message of
 "Wed, 22 May 2002 10:34:05 +0200")
References: <Pine.SOL.4.33.0205220100420.17494-100000@blue3.math.berkeley.edu>
 <4b3a87c92bsbellon@sbellon.de>
Message-ID: <87n0uso7ug.fsf@alberti.gnupg.de>

On Wed, 22 May 2002 10:34:05 +0200, Stefan Bellon said:

> So, neither strcasecmp nor strncasecmp is necessary anymore. Perhaps
> you could try with a CVS build again?

Well, a check and a replacement for strncasecmp is needed if we use it
and there are some place where strcasecmp should be used instead of
the ascii versions: Those where you actually compare against localized
strings.  I found some places where it was rightfully used but hidden
by stricmp which is just a macro to strcasecmp.  I fixed all of them
and added a strncasecmp repalcement function.

  Werner



From wk@gnupg.org  Wed May 22 12:20:03 2002
From: wk@gnupg.org (Werner Koch)
Date: Wed May 22 11:20:03 2002
Subject: strncasecmp
In-Reply-To: <fc.004c540101aa85a33b9aca0013090653.1aa85d3@oufcnt2.open.ac.uk> (Andrew
 Marlow's message of "Wed, 22 May 2002 09:33:01 +0100")
References: <Pine.SOL.4.33.0205220100420.17494-100000@blue3.math.berkeley.edu>
 <fc.004c540101aa85a33b9aca0013090653.1aa85d3@oufcnt2.open.ac.uk>
Message-ID: <87it5go7sv.fsf@alberti.gnupg.de>

On Wed, 22 May 2002 09:33:01 +0100, Andrew Marlow said:

> Some environments have strncasecmp and others don't. I usually define my
> own version of strncasecmp and the implementation differs from environment

And that is why you should have autoconf test for it and provide a
replacement.  I added the missing tests.
 
  Werner



From rjhansen@inav.net  Wed May 22 16:31:01 2002
From: rjhansen@inav.net (Robert J. Hansen)
Date: Wed May 22 15:31:01 2002
Subject: secure sign & encrypt
In-Reply-To: <1022053889.12048.32.camel@atlas>
References: <1021648640.7790.33.camel@atlas>
 <200205171138.51248.rjhansen@inav.net> <1021969508.14022.39.camel@atlas>
 <200205211132.09336.rjhansen@inav.net>  <1022053889.12048.32.camel@atlas>
Message-ID: <1022074192.9093.11.camel@numbers>

> Why do locks exist, then? The existence of thieves is a purely

Mostly to make homeowners feel safe.  Locks don't exist to keep burglars
out.  My parents lock their front door religiously every single night,
and have a cognitive dissonance in place regarding the large bay window
by the front door.  When I go home to visit, I sometimes like to make a
demonstration of just how silly the front door's lock is by picking
it--lockpicking isn't a hard skill to pick up, incidentally; it just
requires a little devotion.  The reaction I get from Mom and Dad is
always the same: "I wish you wouldn't do that."  Not, "Oh, dear, that
lock's insecure, we need to change it."  My parents are very typical
people in this regard.

You're right; burglary is a sociological problem, and one shouldn't try
to solve it with technological means.  Aggressive law-enforcement, which
is a sociological measure, has a much better track record than locks,
which are purely technological ones.

> I agree it'd be breaking (I'd call it extending, but call it what you
> want). But I argue that it's just automating a task the user presently
> has to do manually.

It's breaking a standard for no effective increase in security.  If the
person you're communicating with is untrustworthy, they can still do all
sorts of things to you which are a thousand times worse than this
(fairly trivial) attack you're worried about.

> Currently, to get secure, authenticated end-to-end encryption with gpg,
> the sender has to sign/encrypt/sign, which presently requires at least 2
> gpg invocations, and the recipient has to manually verify that the inner
> and the outer signature match. 

No: only for people whose threat models include a paranoiac distrust of
their recipients have to worry about this.  My threat model doesn't
incorporate that, and thus, I can get (just to be buzzword-compliant)
"secure, authenticated end-to-end encryption with GPG" just by signing
and encrypting.

Many other people share my threat model, and changing GPG's behavior
would mean GPG would no longer well-represent our threat model.  

> What I propose does basically just automate this task. It might do so by

... and breaks RFC.





From avbidder@fortytwo.ch  Wed May 22 18:44:02 2002
From: avbidder@fortytwo.ch (Adrian 'Dagurashibanipal' von Bidder)
Date: Wed May 22 17:44:02 2002
Subject: secure sign & encrypt
In-Reply-To: <1022074192.9093.11.camel@numbers>
References: <1021648640.7790.33.camel@atlas>
 <200205171138.51248.rjhansen@inav.net> <1021969508.14022.39.camel@atlas>
 <200205211132.09336.rjhansen@inav.net>  <1022053889.12048.32.camel@atlas>
 <1022074192.9093.11.camel@numbers>
Message-ID: <1022082280.17135.125.camel@atlas>

--=-sHn1TXuvzo0FFuYUJyVo
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2002-05-22 at 15:29, Robert J. Hansen wrote:
> > Why do locks exist, then? The existence of thieves is a purely

> > Currently, to get secure, authenticated end-to-end encryption with gpg,
> > the sender has to sign/encrypt/sign, which presently requires at least =
2
> > gpg invocations, and the recipient has to manually verify that the inne=
r
> > and the outer signature match.=20
>=20
> No: only for people whose threat models include a paranoiac distrust of
> their recipients have to worry about this.  My threat model doesn't
> incorporate that, and thus, I can get (just to be buzzword-compliant)
> "secure, authenticated end-to-end encryption with GPG" just by signing
> and encrypting.

signing and encrypting is a secure end-to-end channel from the *senders*
point of view. the problem is that for a potential *recipient* of an
encrypted & signed msg it is impossible to know much about the potential
prior recipient of the message (the one that encrypted and forwarded
it).

In other words, your threat model says that you do not only trust the
sender (signer) of a message, but you trust all people who may get
signed messages from that sender. (Or, alternatively, you as the
receiver of a confidential message do not care to know if it really was
sent encrypted or not.)

cheers
-- vbi


--=20
secure email with gpg            avbidder@fortytwo.ch: key id 0x92082481
                                 avbidder@acter.ch:    key id 0x5E4B731F


--=-sHn1TXuvzo0FFuYUJyVo
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA867zowj49sl5Lcx8RAjSNAJsFMg98jQeZWlG9Fo+/rs4dmB2IBwCdGMaZ
fX7WLJlFukV4EQ+X8n0zWmA=
=Qtjy
-----END PGP SIGNATURE-----

--=-sHn1TXuvzo0FFuYUJyVo--



From rjhansen@inav.net  Wed May 22 19:54:01 2002
From: rjhansen@inav.net (Robert J. Hansen)
Date: Wed May 22 18:54:01 2002
Subject: secure sign & encrypt
In-Reply-To: <1022082280.17135.125.camel@atlas>
Message-ID: <Pine.LNX.4.44L0.0205221140200.31437-100000@soli.inav.net>

> In other words, your threat model says that you do not only trust the
> sender (signer) of a message, but you trust all people who may get
> signed messages from that sender. (Or, alternatively, you as the

<testy>
No.  Please don't make assumptions about my threat model, especially ones 
which are subtly and seriously wrong.
</testy>

The `exploit' you're concerned about isn't an exploit at all, except 
insofar as to say the weakest point of any cryptosystem is in the 
ignorance of its users.  Even in the worst-case scenario, all you can say 
is that it only affects people who don't bother to learn the cryptosystem 
they're using.  And there is absolutely nothing which can protect people 
from their own ignorance.  Trying to do so is a fool's errand.

Although I'm not a core GPG hacker (my work is limited to a C++ binding 
for GPGME) and thus my opinion has just about as much weight as your 
average Slashdot reader's, I would be extremely displeased to see GnuPG 
chase after an ephemeral exploit and, in the process, break RFC.




From Weimer@CERT.Uni-Stuttgart.DE  Wed May 22 21:21:01 2002
From: Weimer@CERT.Uni-Stuttgart.DE (Florian Weimer)
Date: Wed May 22 20:21:01 2002
Subject: A modified version of GnuPG
In-Reply-To: <1387186383.20020521213928@mail.ru> ("Max V. Zinal"'s message
 of "Tue, 21 May 2002 21:39:28 +0400")
References: <200205210421.QAA220469@ruru.cs.auckland.ac.nz>
 <1387186383.20020521213928@mail.ru>
Message-ID: <87adqturzu.fsf@CERT.Uni-Stuttgart.DE>

"Max V. Zinal" <Zlat0@mail.ru> writes:

> When I said "secure memory" I was going to say "VirtualLock under
> Windows  NT/2000/XP",  which keeps you absolutely safe unless you
> have  a  Terminal  Server  with  an  evil-minded admin, or remote
> desktop    connection    with    'Debug' privileges.

Previous information about VirtualLock on Win32 suggests that it does
not prevent memory from being paged to disk, but only from being paged
to disk and then discarded.

In fact, the MSDN documentation available online carefully avoids the
claim that the specified memory region is never written to disk.

-- 
Florian Weimer 	                  Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898


From kokhong@post1.com  Wed May 22 21:21:04 2002
From: kokhong@post1.com (Soh Kok Hong)
Date: Wed May 22 20:21:04 2002
Subject: GnuPG for Win32
References: <3CE879E5.4060200@post1.com>
Message-ID: <3CEB00B2.3090208@post1.com>

Dear all,

The patch that I am suggesting builds a Win32 executable (ie. no cygwin
DLLs needed) using the CYGWIN's mingw32 tools.  I did not use the mingw32-cpd
stuff because it is rather old and does not include winsock2 - winsock2 is
required in building gnupg for Win32.

You need to run autoconf (by running "scripts/missing --run autoconf") to
rebuild the configure script first.

The changes are as follows:

1. acinclude.m4 & aclocal.m4
- patch to set ac_cv_sys_symbol_underscore to yes for mingw32 target

2. configure.ac
- Added AC_PROG_RANLIB - this was missing.  In real unix targets,
this variable is added because of AM_GNU_GETTEXT which performs
lots of tests - one of which is to set AC_PROG_RANLIB.  In mingw32
target, this did not get set because try_gettext set to "no", hence
AC_PROGR_RANLIB never gets set.

- added a check for presence of strcasecmp function.  Again, the reason
this did not get checked is because of the AM_GNU_GETTEXT problem.

3. cipher/rndw32.c
- forced include of winioctl.h.  This is needed to include the
DISK_PERFORMANCE structure definition.


Soh Kok Hong wrote:
> Dear all,
> 
> I have a 68-line diff file to patch the stock gnupg-1.0.7.tar.gz to
> build a mingw32 executable in the standard cygwin environment.  It
> mainly patches the configure scripts and one source file (rndw32.c).  I
> would like to know if the gnupg maintainers are interested and to whom
> can I email the patch to?
> 
> Please email to me directly as I am not on the list.
> 
> 
> --
> *************************************************
> Soh Kok Hong
> 
> kokhong@post1.com PGP Signature:
> D18B FC65 2202 3E43 A2D3 90D2 7BCC ABD3 77CE CD1C
> *************************************************


============ patch starts here =================

diff -Naur gnupg-1.0.7.orig/acinclude.m4 gnupg-1.0.7/acinclude.m4
--- gnupg-1.0.7.orig/acinclude.m4	2001-12-20 01:16:30.000000000 +0800
+++ gnupg-1.0.7/acinclude.m4	2002-05-18 16:03:16.000000000 +0800
@@ -661,7 +661,7 @@
  AC_DEFUN(GNUPG_SYS_SYMBOL_UNDERSCORE,
  [tmp_do_check="no"
  case "${target}" in
-    i386-emx-os2 | i[3456]86-pc-os2*emx | i386-pc-msdosdjgpp | *-*-cygwin)
+    i386-emx-os2 | i[3456]86-pc-os2*emx | i386-pc-msdosdjgpp | *-*-cygwin | *-*-mingw32 )
          ac_cv_sys_symbol_underscore=yes
          ;;
      *)
diff -Naur gnupg-1.0.7.orig/aclocal.m4 gnupg-1.0.7/aclocal.m4
--- gnupg-1.0.7.orig/aclocal.m4	2002-04-29 22:58:48.000000000 +0800
+++ gnupg-1.0.7/aclocal.m4	2002-05-18 16:03:18.000000000 +0800
@@ -665,7 +665,7 @@
  AC_DEFUN(GNUPG_SYS_SYMBOL_UNDERSCORE,
  [tmp_do_check="no"
  case "${target}" in
-    i386-emx-os2 | i[3456]86-pc-os2*emx | i386-pc-msdosdjgpp | *-*-cygwin)
+    i386-emx-os2 | i[3456]86-pc-os2*emx | i386-pc-msdosdjgpp | *-*-cygwin | *-*-mingw32 )
          ac_cv_sys_symbol_underscore=yes
          ;;
      *)
diff -Naur gnupg-1.0.7.orig/cipher/rndw32.c gnupg-1.0.7/cipher/rndw32.c
--- gnupg-1.0.7.orig/cipher/rndw32.c	2001-12-20 02:05:04.000000000 +0800
+++ gnupg-1.0.7/cipher/rndw32.c	2002-05-18 16:03:18.000000000 +0800
@@ -67,9 +67,7 @@
  #include <string.h>

  #include <windows.h>
-#ifdef __CYGWIN32__
-# include <winioctl.h>
-#endif
+#include <winioctl.h>


  #include "types.h"
diff -Naur gnupg-1.0.7.orig/configure.ac gnupg-1.0.7/configure.ac
--- gnupg-1.0.7.orig/configure.ac	2002-04-29 22:56:08.000000000 +0800
+++ gnupg-1.0.7/configure.ac	2002-05-18 16:03:20.000000000 +0800
@@ -184,6 +184,7 @@
  AM_MISSING_PROG(MAKEINFO, makeinfo, $missing_dir)
  AC_PROG_CC
  AC_PROG_CPP
+AC_PROG_RANLIB
  AC_PATH_PROG(PERL,"perl")
  AC_ISC_POSIX
  AC_SYS_LARGEFILE
@@ -482,7 +483,7 @@
  AC_FUNC_FSEEKO
  AC_FUNC_VPRINTF
  AC_FUNC_FORK
-AC_CHECK_FUNCS(strerror stpcpy strsep strlwr stricmp tcgetattr strtoul mmap)
+AC_CHECK_FUNCS(strerror stpcpy strsep strlwr stricmp tcgetattr strtoul strcasecmp mmap)
  AC_CHECK_FUNCS(memmove gettimeofday getrusage setrlimit clock_gettime)
  AC_CHECK_FUNCS(memicmp atexit raise getpagesize strftime nl_langinfo setlocale)
  AC_CHECK_FUNCS(waitpid wait4 sigaction sigprocmask rand pipe stat)
diff -Naur gnupg-1.0.7.orig/scripts/build-mingw32 gnupg-1.0.7/scripts/build-mingw32
--- gnupg-1.0.7.orig/scripts/build-mingw32	1970-01-01 08:00:00.000000000 +0800
+++ gnupg-1.0.7/scripts/build-mingw32	2002-05-18 16:06:06.000000000 +0800
@@ -0,0 +1,6 @@
+#!/bin/sh
+
+export CC="gcc -mno-cygwin -mthreads"
+
+./configure --target=i386-pc-mingw32
+




From disastry@saiknes.lv  Wed May 22 21:21:06 2002
From: disastry@saiknes.lv (disastry@saiknes.lv)
Date: Wed May 22 20:21:06 2002
Subject: RSA sign+encrypt (with subkey) key generation
Message-ID: <3CEB7600.5CAFAF74@saiknes.lv>

This is a multi-part message in MIME format.
--------------1C9E8650BAE0BC0A8A373C79
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

hello

here is the patch that allows to generate RSA sign+encrypt (with subkey) keys
in one step (like DSA/Elgamal keys) - no need to go to --key-edit to add subkey

it also allows to generate RSA/Elgamal and DSA/RSA keys in one step.

this patch is for 1.0.7a (cvs version)

patch also available at
http://disastry.dhs.org/pgp/gpg/gnupg-1.0.7a-keygen.diff

__
Disastry  http://disastry.dhs.org/
-----BEGIN PGP SIGNATURE-----
Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1

iQA/AwUBPOtZkDBaTVEuJQxkEQNPqACeI4JHKHqW2/bz/yhL4Si7t7TQesoAoIn7
sjEvzUyMrauX8ZRvEa6vWfXk
=Y/XQ
-----END PGP SIGNATURE-----
--------------1C9E8650BAE0BC0A8A373C79
Content-Type: text/plain; charset=us-ascii;
 name="gnupg-1.0.7a-keygen.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="gnupg-1.0.7a-keygen.diff"

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

This patch enables gpg version 1.0.7a to generate RSA sign + RSA encrypt keys
and RSA sign + ElGamal encrypt and DSA + RSA encrypt keys.


Copyright 2001 Free Software Foundation, Inc.

This patch is free software; you can use it, redistribute it
and/or modify it under the terms of the GNU General Public
License as published by the Free Software Foundation; either
version 2 of the License, or (at your option) any later version.


--- gnupg/g10/keygen.c	Thu May 16 05:35:54 2002
+++ gnupg107a/g10/keygen.c	Wed May 22 12:19:21 2002
@@ -849,8 +849,14 @@
     tty_printf(    _("   (%d) RSA (sign only)\n"), 5 );
     if (addmode)
         tty_printf(    _("   (%d) RSA (encrypt only)\n"), 6 );
+    if (!addmode)
+      tty_printf(    _("   (%d) RSA (sign and encrypt (with subkey))\n"), 7 );
     if (opt.expert)
-      tty_printf(    _("   (%d) RSA (sign and encrypt)\n"), 7 );
+      tty_printf(    _("   (%d) RSA (sign and encrypt (single key))\n"), 8 );
+    if (!addmode && opt.expert) { /* add odd keys too... */
+      tty_printf(    _("   (%d) RSA (sign) and ElGamal(encrypt)\n"), 9 );
+      tty_printf(    _("   (%d) DSA (sign) and RSA (encrypt)\n"), 10 );
+    }
 
     for(;;) {
 	answer = cpr_get("keygen.algo",_("Your selection? "));
@@ -858,10 +864,20 @@
 	algo = *answer? atoi(answer): 1;
 	m_free(answer);
 	if( algo == 1 && !addmode ) {
-	    algo = 0;	/* create both keys */
+	    algo = PUBKEY_ALGO_DSA | (PUBKEY_ALGO_ELGAMAL_E << 8);	/* create both keys */
+	    break;
+	}
+	else if( algo == 10 && !addmode && opt.expert ) {
+	    algo = PUBKEY_ALGO_DSA | (PUBKEY_ALGO_RSA << 8);	/* create both keys */
+            *r_usage = PUBKEY_USAGE_ENC << 8;
 	    break;
 	}
-	else if( algo == 7 && opt.expert ) {
+	else if( algo == 9 && !addmode && opt.expert ) {
+	    algo = PUBKEY_ALGO_RSA | (PUBKEY_ALGO_ELGAMAL_E << 8);	/* create both keys */
+            *r_usage = PUBKEY_USAGE_SIG;
+	    break;
+	}
+	else if( algo == 8 && opt.expert ) {
 	    if (cpr_get_answer_is_yes ("keygen.algo.rsa_se",_(
 		"The use of this algorithm is deprecated - create anyway? "))){
               algo = PUBKEY_ALGO_RSA;
@@ -869,6 +885,11 @@
               break;
             }
 	}
+	else if( algo == 7 && !addmode ) {
+	    algo = PUBKEY_ALGO_RSA | (PUBKEY_ALGO_RSA << 8);	/* create both keys */
+            *r_usage = PUBKEY_USAGE_SIG | (PUBKEY_USAGE_ENC << 8);
+	    break;
+	}
 	else if( algo == 6 && addmode ) {
 	    algo = PUBKEY_ALGO_RSA;
             *r_usage = PUBKEY_USAGE_ENC;
@@ -1855,7 +1876,7 @@
 void
 generate_keypair( const char *fname )
 {
-    unsigned int nbits;
+    unsigned int nbits = 0;
     char *uid = NULL;
     DEK *dek;
     STRING2KEY *s2k;
@@ -1875,26 +1896,52 @@
     }
 
     algo = ask_algo( 0, &use );
-    if( !algo ) { /* default: DSA with ElG subkey of the specified size */
+    if( algo >> 8 ) { /* default: DSA with ElG subkey of the specified size */
 	both = 1;
 	r = m_alloc_clear( sizeof *r + 20 );
 	r->key = pKEYTYPE;
-	sprintf( r->u.value, "%d", PUBKEY_ALGO_DSA );
+	sprintf( r->u.value, "%d", algo & 0xff );
 	r->next = para;
 	para = r;
-	tty_printf(_("DSA keypair will have 1024 bits.\n"));
 	r = m_alloc_clear( sizeof *r + 20 );
 	r->key = pKEYLENGTH;
-	strcpy( r->u.value, "1024" );
+	if ((algo & 0xff) == PUBKEY_ALGO_DSA) {
+	    tty_printf(_("DSA keypair will have 1024 bits.\n"));
+	    strcpy( r->u.value, "1024" );
+	} else {
+	    nbits = ask_keysize( algo && 0xff );
+	    sprintf( r->u.value, "%u", nbits);
+	}
 	r->next = para;
 	para = r;
 
-	algo = PUBKEY_ALGO_ELGAMAL_E;
+        if (use & 0xff) {
+            r = m_alloc_clear( sizeof *r + 20 );
+            r->key = pKEYUSAGE;
+            sprintf( r->u.value, "%s%s",
+                     (use & PUBKEY_USAGE_SIG)? "sign ":"",
+                     (use & PUBKEY_USAGE_ENC)? "encrypt ":"" );
+            r->next = para;
+            para = r;
+        }
+
+	algo = algo >> 8;
+	use = use >> 8;
 	r = m_alloc_clear( sizeof *r + 20 );
 	r->key = pSUBKEYTYPE;
 	sprintf( r->u.value, "%d", algo );
 	r->next = para;
 	para = r;
+
+        if (use) {
+            r = m_alloc_clear( sizeof *r + 20 );
+            r->key = pSUBKEYUSAGE;
+            sprintf( r->u.value, "%s%s",
+                     (use & PUBKEY_USAGE_SIG)? "sign ":"",
+                     (use & PUBKEY_USAGE_ENC)? "encrypt ":"" );
+            r->next = para;
+            para = r;
+        }
     }
     else {
 	r = m_alloc_clear( sizeof *r + 20 );
@@ -1915,7 +1962,8 @@
 
     }
 
-    nbits = ask_keysize( algo );
+    if ( !nbits )
+	nbits = ask_keysize( algo );
     r = m_alloc_clear( sizeof *r + 20 );
     r->key = both? pSUBKEYLENGTH : pKEYLENGTH;
     sprintf( r->u.value, "%u", nbits);
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (MingW32)

iD8DBQE863N1MFpNUS4lDGQRAgqTAJ9NW005a2n9RneLmYVz61IOVNCeTQCgj3Zy
z8nOyOhhpk+IoUnaMptHeNA=
=k+D4
-----END PGP SIGNATURE-----

--------------1C9E8650BAE0BC0A8A373C79--



From roconnor@Math.Berkeley.EDU  Thu May 23 04:41:01 2002
From: roconnor@Math.Berkeley.EDU (Russell O'Connor)
Date: Thu May 23 03:41:01 2002
Subject: GnuPG 1.0.7 for OS/2
Message-ID: <Pine.SOL.4.33.0205221839420.19679-100000@blue3.math.berkeley.edu>

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

[To: gnupg-users@gnupg.org, gnupg-devel@gnupg.org]

GnuPG 1.0.7 is available for OS/2 at
<http://math.berkeley.edu/~roconnor/gnupg/>

Requires EMX, RexxEGD, and Zlib 1.1.4.

- -- 
Russell O'Connor                           roconnor@math.berkeley.edu
           <http://www.math.berkeley.edu/~roconnor/>
``Later generations will regard set theory as a disease from which one
has recovered.'' -- Poincare
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (SunOS)
Comment: For info see http://www.gnupg.org

iD8DBQE87EjsuZUa0PWVyWQRAu1gAJ41HmicFwddsI3VLkxglYxlPny4TwCfVcmr
1O6c+oRfhocXSceh04OuEWY=
=zvQa
-----END PGP SIGNATURE-----



From pgut001@cs.auckland.ac.nz  Thu May 23 05:17:01 2002
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
Date: Thu May 23 04:17:01 2002
Subject: Re[2]: A modified version of GnuPG
Message-ID: <200205230217.OAA443785@ruru.cs.auckland.ac.nz>

"Max V. Zinal" <Zlat0@mail.ru> writes:

>When I said "secure memory" I was going to say "VirtualLock under Windows
>NT/2000/XP", which keeps you absolutely safe unless you have a Terminal Server
>with an evil-minded admin, or remote desktop connection with 'Debug'
>privileges.

[...]

>if we are talking about Win9x/ME (which should be called 'Mustdie Edition', I
>think), even with VirtualLock you cannot be absolutely shure.

VirtualLock() has anything from a marginal chance of preventing swapping (best-
case) to a chance of greatly increasing swapping (worst-case).  Under Win9x it
does nothing at all (it's a no-op).  It's nothing like "absolutely safe".  See
e.g. http://www.cryptoapps.com/~peter/06_random.pdf, somewhere towards the end.

Peter.



From avbidder@fortytwo.ch  Thu May 23 12:19:01 2002
From: avbidder@fortytwo.ch (Adrian 'Dagurashibanipal' von Bidder)
Date: Thu May 23 11:19:01 2002
Subject: secure sign & encrypt
In-Reply-To: <Pine.LNX.4.44L0.0205221140200.31437-100000@soli.inav.net>
References: <Pine.LNX.4.44L0.0205221140200.31437-100000@soli.inav.net>
Message-ID: <1022145616.5434.17.camel@atlas>

--=-+TYm2zHn2izZGRW4c328
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2002-05-22 at 18:55, Robert J. Hansen wrote:
> > In other words, your threat model says that you do not only trust the
> > sender (signer) of a message, but you trust all people who may get
> > signed messages from that sender. (Or, alternatively, you as the
>=20
> <testy>
> No.  Please don't make assumptions about my threat model, especially ones=
=20
> which are subtly and seriously wrong.
> </testy>

I'm sorry if I misunderstand you here. Let me ask you, then:

You receive an encrypted + signed message. What do you know now?

You trust the signature. Do you trust that nobody has read the message
in passing?

cheers
-- vbi



--=20
secure email with gpg            avbidder@fortytwo.ch: key id 0x92082481
                                 avbidder@acter.ch:    key id 0x5E4B731F


--=-+TYm2zHn2izZGRW4c328
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA87LRQwj49sl5Lcx8RAomUAJwLd+arZwf1fAY2/+IaxgG43CwUhACfcphN
uL9roi4q9vJvLQ3elBRy7Jw=
=XF8q
-----END PGP SIGNATURE-----

--=-+TYm2zHn2izZGRW4c328--



From jukkaho@mail.student.oulu.fi  Thu May 23 12:58:01 2002
From: jukkaho@mail.student.oulu.fi (Jukka Holappa)
Date: Thu May 23 11:58:01 2002
Subject: secure sign & encrypt
References: <Pine.LNX.4.44L0.0205221140200.31437-100000@soli.inav.net> <1022145616.5434.17.camel@atlas>
Message-ID: <3CECBD9E.4090306@mail.student.oulu.fi>

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

Adrian 'Dagurashibanipal' von Bidder wrote:
| On Wed, 2002-05-22 at 18:55, Robert J. Hansen wrote:
|
|>>In other words, your threat model says that you do not only trust the
|>>sender (signer) of a message, but you trust all people who may get
|>>signed messages from that sender. (Or, alternatively, you as the
|>
|><testy>
|>No.  Please don't make assumptions about my threat model, especially ones
|>which are subtly and seriously wrong.
|></testy>
|
|
| I'm sorry if I misunderstand you here. Let me ask you, then:
|
| You receive an encrypted + signed message. What do you know now?
|
| You trust the signature. Do you trust that nobody has read the message
| in passing?
|

I'm sorry to get in the middle of this, but you really can't know that
with all the signatures you put in it.

Maybe someone read the message over the shoulder before it was
signed+encrypted(+signed) or whatever.

You just have to trust a person to encrypt before anyone sees the
message. If he/she fails to do this, there's no secret message in it any
more.

- - Jukka
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE87L2eYYWM2XTSwX0RApfAAKCDKY19S2HR8weZG3iNAs7XqTFtdwCfZ9rA
Pphmzn7kfxPh7WO+7NIc5oI=
=R2SD
-----END PGP SIGNATURE-----



From avbidder@fortytwo.ch  Thu May 23 16:03:02 2002
From: avbidder@fortytwo.ch (Adrian 'Dagurashibanipal' von Bidder)
Date: Thu May 23 15:03:02 2002
Subject: secure sign & encrypt
In-Reply-To: <3CECBD9E.4090306@mail.student.oulu.fi>
References: <Pine.LNX.4.44L0.0205221140200.31437-100000@soli.inav.net>
 <1022145616.5434.17.camel@atlas>  <3CECBD9E.4090306@mail.student.oulu.fi>
Message-ID: <1022159038.5792.90.camel@atlas>

--=-jHO6hpiweAJ41f8F8ugG
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Thu, 2002-05-23 at 11:59, Jukka Holappa wrote:

> | You receive an encrypted + signed message. What do you know now?
> |
> | You trust the signature. Do you trust that nobody has read the message
> | in passing?
> |
>=20
> I'm sorry to get in the middle of this, but you really can't know that
> with all the signatures you put in it.
>=20
> Maybe someone read the message over the shoulder before it was
> signed+encrypted(+signed) or whatever.
>=20
> You just have to trust a person to encrypt before anyone sees the
> message. If he/she fails to do this, there's no secret message in it any
> more.

I trust that if a person is encrypting a message to me, this person will
also be certain that the message is handled confidentially until it is
encrypted.

The problem with the attack I'm arguing about is that the message was
*not* encrypted in the first place, but that the recipient receives it
as an encrypted message and thus might put a meaning to a message that
was not intended by the sender.

With current openPGP encryption, encryption is only useful for the
sender (he knows that the message sent is encrypted and will not be read
by anybody other than the intended recipient. Of course he trusts the
recipient not to do the wrong thing with the information).=20

Encryption is *not* useful for the recipient - he must not put any
special meaning to the fact that a message was encrypted.

BUT encryption COULD be useful for the recipient, if it was made clear
that the message was sent encrypted in the first place. Of course the
recipient still needs to trust the sender/signer of the message to have
handled the contained information confidentially.


In the end it all boils down that people (or, at least I) automatically
put different meanings to a message, depending on the source of the
message. A message in the newspaper is read differently than the same
message in a letter. In the same way, an unencrypted e-mail message may
be interpreted differently from the same message that comes encrypted -
it tells something about the sender's intention.



Concerning RFC compliance:
from rfc2440, section 5.2.3.1:
=3D=3D=3D=3D=3D=3D
     An implementation SHOULD ignore any subpacket of a type that it
     does not recognize.
=3D=3D=3D=3D=3D=3D

So, adding a hashed subpacket with a subpacket type of, say, 110
(explicitely reserved for private use) for the purpose of announcing the
'intended encryption key' on signed+encrypted messages is fully within
the scope of the rfc and SHOULD not break any openPGP compliant
implementations.

Displaying extra warnings on decrypting messages without this special
subpacket should of course not be the default while this is not in
widespread use. Displaying extra warnings in case there is a mismatch
between the intended and the real encryption key can probably safely be
enabled per default.

Also - although I'm in no way involved with writing RFCs - the RFC
documents have been known to be revised and extended from time to time.


Huk
-- vbi



--=20
secure email with gpg            avbidder@fortytwo.ch: key id 0x92082481
                                 avbidder@acter.ch:    key id 0x5E4B731F


--=-jHO6hpiweAJ41f8F8ugG
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA87Oi+wj49sl5Lcx8RAm00AJ43EYWOM0GseSoNnSOVwkVUQ7nE1gCfbUZr
D44M4vLJ1wofXe7YzMrd378=
=n2Q/
-----END PGP SIGNATURE-----

--=-jHO6hpiweAJ41f8F8ugG--



From jukkaho@mail.student.oulu.fi  Thu May 23 16:59:02 2002
From: jukkaho@mail.student.oulu.fi (Jukka Holappa)
Date: Thu May 23 15:59:02 2002
Subject: secure sign & encrypt
References: <Pine.LNX.4.44L0.0205221140200.31437-100000@soli.inav.net>	<1022145616.5434.17.camel@atlas>  <3CECBD9E.4090306@mail.student.oulu.fi> <1022159038.5792.90.camel@atlas>
Message-ID: <3CECF632.50606@mail.student.oulu.fi>

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

Adrian 'Dagurashibanipal' von Bidder wrote:
| BUT encryption COULD be useful for the recipient, if it was made clear
| that the message was sent encrypted in the first place. Of course the
| recipient still needs to trust the sender/signer of the message to have
| handled the contained information confidentially.
|
|
| In the end it all boils down that people (or, at least I) automatically
| put different meanings to a message, depending on the source of the
| message. A message in the newspaper is read differently than the same
| message in a letter. In the same way, an unencrypted e-mail message may
| be interpreted differently from the same message that comes encrypted -
| it tells something about the sender's intention.
|
|
|
| Concerning RFC compliance:
| from rfc2440, section 5.2.3.1:
| ======
|      An implementation SHOULD ignore any subpacket of a type that it
|      does not recognize.
| ======
|
| So, adding a hashed subpacket with a subpacket type of, say, 110
| (explicitely reserved for private use) for the purpose of announcing the
| 'intended encryption key' on signed+encrypted messages is fully within
| the scope of the rfc and SHOULD not break any openPGP compliant
| implementations.
|
| Displaying extra warnings on decrypting messages without this special
| subpacket should of course not be the default while this is not in
| widespread use. Displaying extra warnings in case there is a mismatch
| between the intended and the real encryption key can probably safely be
| enabled per default.

Very true and an excellent idea.

It would protect fairly well from sending someone else's signed messages
~ with perhaps malicuous (unsigned) attachments, only if programs warn
about missing subkey in encrypted message - and this is not going to be
a big warning in real life since there is no support for this key.

If Cecilia gets any Alices messages and is able to decrypt/copy it, he
can re-encrypt it without this subkey and send it to Bob in any other
contexts. It is not safer at all without this paranoid option which
tells that message was not sent to him originally.

Perhaps signatures would work better.. that they contain information to
who that particular message was sent. Perhaps the message itself ;)

Email programs should also warn when receiving unsigned attachments
along with encrypted/signed messages since there is no way knowing these
attachments are really from that person.


|
| Also - although I'm in no way involved with writing RFCs - the RFC
| documents have been known to be revised and extended from time to time.

Someone has to do it (not me either) :)

- - Jukka
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE87PYxYYWM2XTSwX0RAnktAJ4tX+HDuD7wrGBtMSSHK0BTBr/KHwCeLRw2
Y3Vxy/O9BzFffgXl5AoWbEM=
=WB+0
-----END PGP SIGNATURE-----



From rjhansen@inav.net  Thu May 23 17:21:02 2002
From: rjhansen@inav.net (Robert J. Hansen)
Date: Thu May 23 16:21:02 2002
Subject: secure sign & encrypt
In-Reply-To: <1022145616.5434.17.camel@atlas>
Message-ID: <Pine.LNX.4.44L0.0205230853260.11995-100000@soli.inav.net>

> You receive an encrypted + signed message. What do you know now?

I trust that the message really was composed by the original author, and I 
know it was encrypted when the data came out of the pipe.  If the signed 
message contains traffic which was unambiguously meant for me, then the 
message was intended for me.  Encryption and signing just means encryption 
and signing; I don't assume that crypto is some kind of magic fairy dust, 
where you sprinkle a little of it on your traffic and suddenly you're 
"secure".

A signed message doesn't mean the traffic was intended for you, it just 
means the message hasn't been tampered with in transit.  An encrypted 
message doesn't mean nobody's read the message, it just means it's been 
kept safe in transit from the time someone encrypted it to the time you 
decrypted it.




From rjhansen@inav.net  Thu May 23 17:29:01 2002
From: rjhansen@inav.net (Robert J. Hansen)
Date: Thu May 23 16:29:01 2002
Subject: secure sign & encrypt
In-Reply-To: <1022159038.5792.90.camel@atlas>
Message-ID: <Pine.LNX.4.44L0.0205230922350.11995-100000@soli.inav.net>

> In the end it all boils down that people (or, at least I) automatically
> put different meanings to a message, depending on the source of the

If you decide to (foolishly) infer that crypto means something that it 
doesn't, which no reputable source will tell you it does, then that 
reflects more on your own lack of understanding than a flaw in the 
protocol.  Ignorance is the Achilles' heel of every protocol, and your 
proposed fix does not fix the protocol--the protocol's not broken--it just 
makes the protocol come into line with how you think the protocol Ought To 
Be.

> Concerning RFC compliance:
> from rfc2440, section 5.2.3.1:
> ======
>      An implementation SHOULD ignore any subpacket of a type that it
>      does not recognize.
> ======

Note well that sentence.  SHOULD, not MUST.  For every program which 
correctly and properly implements RFCs, there are easily a couple of dozen 
which just barely manage to get the MUSTs implemented.  When I was working 
at McLeodUSA, they had me working on a project to reimplement RFC1991 
(Classic PGP) in-house so they could get around the licensing terms.  
(Never mind that the license fees to RSA and IDEA were prohibitive... 
management at its finest.)  Given the tremendous time constraints I was 
under, I was doing really, really well just to get the MUSTs.

If this extension gets implemented it _will_ break interoperability with 
other OpenPGP implementations (even if I don't know offhand which ones it 
will break), and we'll be the ones who will be responsible.  All for no 
effective increase in security.

> Also - although I'm in no way involved with writing RFCs - the RFC
> documents have been known to be revised and extended from time to time.

Yes, by working groups.  If you want the RFC changed, there's a process in 
place for it; take it to the IETF and make the sales pitch there.  GnuPG 
is not the place to be embracing-and-extending the RFC.

I don't know how much clearer I can make it here, really.



From Max V. Zinal" <Zlat0@mail.ru  Thu May 23 18:12:01 2002
From: Max V. Zinal" <Zlat0@mail.ru (Max V. Zinal)
Date: Thu May 23 17:12:01 2002
Subject: Re[2]: A modified version of GnuPG
In-Reply-To: <87adqturzu.fsf@CERT.Uni-Stuttgart.DE>
References: <200205210421.QAA220469@ruru.cs.auckland.ac.nz>
 <1387186383.20020521213928@mail.ru> <87adqturzu.fsf@CERT.Uni-Stuttgart.DE>
Message-ID: <31929626.20020523190617@mail.ru>

Wednesday, May 22, 2002, 1:10:29 AM, Florian Weimer wrote:

FW> Previous information about VirtualLock on Win32 suggests that it does
FW> not prevent memory from being paged to disk, but only from being paged
FW> to disk and then discarded.

FW> In fact, the MSDN documentation available online carefully avoids the
FW> claim that the specified memory region is never written to disk.

Yes, that's true, and that was my mistake. The only excuse for me
is the following phrase in "VirtualLock" manual:

        "The  VirtualLock  function locks the specified region of
        the process's virtual address space into physical memory,
        ensuring  that  subsequent  access to the region will not
        incur a page fault."

I think that I can write a small dummy device driver for NT-based
system  that  will  allow  a person with administrative rights to
allocate  a non-pageable region of memory. It will take some time,
I  think,  because  I will have to find DDK distribution for that
purposes.  Such task isn't too complex, although it will not work
under 9x-based systems.

I'm sorry for inconvenience.

Best regards,
        Max V. Zinal



From dmitri@users.sourceforge.net  Thu May 23 18:32:01 2002
From: dmitri@users.sourceforge.net (Dmitri)
Date: Thu May 23 17:32:01 2002
Subject: Re[2]: A modified version of GnuPG
In-Reply-To: <31929626.20020523190617@mail.ru>
References: <200205210421.QAA220469@ruru.cs.auckland.ac.nz>
 <1387186383.20020521213928@mail.ru> <87adqturzu.fsf@CERT.Uni-Stuttgart.DE>
 <31929626.20020523190617@mail.ru>
Message-ID: <1022167972.29488.271.camel@usb.networkfab.com>

--=-rHpJX1Lq3gk4cG70YFPF
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Thu, 2002-05-23 at 08:06, Max V. Zinal wrote:

> I think that I can write a small dummy device driver for NT-based
> system  that  will  allow  a person with administrative rights to
> allocate  a non-pageable region of memory.

The driver does not need anyone's permission, it has full access to
everything in the kernel. But only administrator can install a driver.
Then the driver can impose any security restrictions on its use.

> It will take some time,
> I  think,  because  I will have to find DDK distribution for that
> purposes.

void *ExAllocatePool(NonPagedPool, <length>);

> Such task isn't too complex

300 lines of code, maybe. You will need to handle
IRP_MJ_{CREATE,CLOSE,READ,WRITE}. But the architecture of Win2K WDM
drivers is not really straightforward; if you never did it before then
you got some reading to do ;-)

Dmitri


--=-rHpJX1Lq3gk4cG70YFPF
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA87QujXksyLpO6T4IRAvr0AJ0ShJ+szbsW4kN83sn/chR6/MGdNACcCz2g
oAVv49dWTCC0rWm0XQHjjRA=
=Ivru
-----END PGP SIGNATURE-----

--=-rHpJX1Lq3gk4cG70YFPF--



From Pascal@Scheffers.Net  Thu May 23 22:41:01 2002
From: Pascal@Scheffers.Net (Pascal Scheffers)
Date: Thu May 23 21:41:01 2002
Subject: Re[2]: A modified version of GnuPG
In-Reply-To: <31929626.20020523190617@mail.ru>
References: <200205210421.QAA220469@ruru.cs.auckland.ac.nz>
 <1387186383.20020521213928@mail.ru> <87adqturzu.fsf@CERT.Uni-Stuttgart.DE>
 <31929626.20020523190617@mail.ru>
Message-ID: <1022182918.20135.17.camel@moonchild.lcl>

On Thu, 2002-05-23 at 17:06, Max V. Zinal wrote:
> FW> In fact, the MSDN documentation available online carefully avoids the
AFAICT, MSDN-online is/was 100% in sync with the offline available
versions (3 cdrom disk/DVD distribution), the only 'but' is that it is
uptodate, meaning older information isn't there anymore (or much harder
to find). 

This was a pain in the b*tt when I was working with crypto APIs for
win95 in the 2000, it's not always clear which API works with which
version. I have no idea if it's any better for the DDK. 

I seem to have trouble accessing it right now with Galeon, but that is
sort-of to be expected.

> I  think,  because  I will have to find DDK distribution for that
That is part of the MSDN library, too. You can also just download it
from the MS website: http://www.microsoft.com/ddk/W2kDDK.asp

It says there that the DDK has all the info, libraries, manuals and
samples you'll ever need. It's a 67MB download, tho. 

- Pascal.




From pgut001@cs.auckland.ac.nz  Fri May 24 08:06:01 2002
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
Date: Fri May 24 07:06:01 2002
Subject: Re[2]: A modified version of GnuPG
Message-ID: <200205240507.RAA43132@ruru.cs.auckland.ac.nz>

"Max V. Zinal" <Zlat0@mail.ru> writes:

>I think that I can write a small dummy device driver for NT-based system that
>will allow a person with administrative rights to allocate a non-pageable
>region of memory. It will take some time, I think, because I will have to find
>DDK distribution for that purposes.

You don't need to do that, there are already user-level functions which do
this.  To save me having to regurgitate it all again, search sci.crypt or the
archives of Perry Metzger's crypto list for "AllocateUserPhysicalPages" to find
the details.

Peter.



From avbidder@fortytwo.ch  Fri May 24 10:33:02 2002
From: avbidder@fortytwo.ch (Adrian 'Dagurashibanipal' von Bidder)
Date: Fri May 24 09:33:02 2002
Subject: secure sign & encrypt
In-Reply-To: <Pine.LNX.4.44L0.0205230922350.11995-100000@soli.inav.net>
References: <Pine.LNX.4.44L0.0205230922350.11995-100000@soli.inav.net>
Message-ID: <1022225631.24970.43.camel@atlas>

--=-jdknF5oRudFIcEcv2yDr
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Thu, 2002-05-23 at 16:29, Robert J. Hansen wrote:
> > In the end it all boils down that people (or, at least I) automatically
> > put different meanings to a message, depending on the source of the
>=20
[...]

> proposed fix does not fix the protocol--the protocol's not broken--it jus=
t=20
> makes the protocol come into line with how you think the protocol Ought T=
o=20
> Be.

Agree with you here - and I feel that to many users not willing to study
the protocol in dephth 'my' variant of the protocol is closer to what
people expect if they use a crypto solution.

Jukka:
> Perhaps signatures would work better.. that they contain information
> to who that particular message was sent. Perhaps the message itself ;)

I thought about the 'intended recipient' thing, analogous to my
'inteneded encryption key', but for non-encrypted messages. Clearly this
cannot be solved by gpg - how should it know the destination of the
message? However, MUAs could copy the To: header (and Subject:, too?)
into the signed area of the mail (MIME-Headers?), and use these infos
when displaying signed mail. (But as there are many more MUAs than
OpenPGP implementations, this proposal has an even smaller chance of
ever getting implemented)


As all points have probably been made (repeatedly - yes, I'm the guilty
here) it's probably ok if this is EOT here before the discussion becomes
endless (or we could always move over to de.alt.gruppenkasper).


cheers & HAND
-- vbi


--=20
secure email with gpg            avbidder@fortytwo.ch: key id 0x92082481
                                 avbidder@acter.ch:    key id 0x5E4B731F


--=-jdknF5oRudFIcEcv2yDr
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA87ezewj49sl5Lcx8RAk5uAJ9GuA/n9G7N4WA88e+5PFOEQDgOxQCdH1kt
koDk6bA8CU53j+Fe3Fg98CI=
=DnRn
-----END PGP SIGNATURE-----

--=-jdknF5oRudFIcEcv2yDr--



From Max V. Zinal" <Zlat0@mail.ru  Fri May 24 18:06:02 2002
From: Max V. Zinal" <Zlat0@mail.ru (Max V. Zinal)
Date: Fri May 24 17:06:02 2002
Subject: Re[4]: A modified version of GnuPG
In-Reply-To: <200205240507.RAA43132@ruru.cs.auckland.ac.nz>
References: <200205240507.RAA43132@ruru.cs.auckland.ac.nz>
Message-ID: <11716388144.20020524190723@mail.ru>

Friday, May 24, 2002, 9:07:19 AM, Peter Gutmann wrote:

PG> "Max V. Zinal" <Zlat0@mail.ru> writes:

>>I think that I can write a small dummy device driver for NT-based system that
>>will allow a person with administrative rights to allocate a non-pageable
>>region of memory. It will take some time, I think, because I will have to find
>>DDK distribution for that purposes.

PG> You don't need to do that, there are already user-level functions which do
PG> this.  To save me having to regurgitate it all again, search sci.crypt or the
PG> archives of Perry Metzger's crypto list for "AllocateUserPhysicalPages" to find
PG> the details.

I  know about these functions. Please note that they are the part
of  Address  Windowing  Extensions  (AWE), and thus are supported
only  with W2K or higher. We should also remember that Windows NT
4 is still widely used.

Best regards,
        Max V. Zinal



From pgut001@cs.auckland.ac.nz  Mon May 27 10:34:01 2002
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
Date: Mon May 27 09:34:01 2002
Subject: Re[4]: A modified version of GnuPG
Message-ID: <200205270735.TAA74949@ruru.cs.auckland.ac.nz>

"Max V. Zinal" <Zlat0@mail.ru> writes:
>Friday, May 24, 2002, 9:07:19 AM, Peter Gutmann wrote:
>PG> "Max V. Zinal" <Zlat0@mail.ru> writes:
>>>I think that I can write a small dummy device driver for NT-based system that
>>>will allow a person with administrative rights to allocate a non-pageable
>>>region of memory. It will take some time, I think, because I will have to find
>>>DDK distribution for that purposes.
>
>PG> You don't need to do that, there are already user-level functions which do
>PG> this.  To save me having to regurgitate it all again, search sci.crypt or the
>PG> archives of Perry Metzger's crypto list for "AllocateUserPhysicalPages" to find
>PG> the details.
>
>I know about these functions. Please note that they are the part of Address
>Windowing Extensions (AWE), and thus are supported only with W2K or higher. We
>should also remember that Windows NT 4 is still widely used.

You have to make a tradeoff, either be backwards-compatible with NT4 (which I
doubt is still widely used except maybe on a few servers which no-one wants to
touch) and face an incredibly difficult task of writing an NT kernel driver to
do it, or require Win2K and have Microsoft do most of it for you.  Trying to be
NT4-compatible seems to be an unnecesarily painful way to do things.

Peter.


From broonie@sirena.org.uk  Mon May 27 11:47:01 2002
From: broonie@sirena.org.uk (Mark Brown)
Date: Mon May 27 10:47:01 2002
Subject: Re[4]: A modified version of GnuPG
In-Reply-To: <200205270735.TAA74949@ruru.cs.auckland.ac.nz>
References: <200205270735.TAA74949@ruru.cs.auckland.ac.nz>
Message-ID: <20020527084805.GA848@sirena.org.uk>

--6c2NcOVqGQ03X4Wi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, May 27, 2002 at 07:35:21PM +1200, Peter Gutmann wrote:

> You have to make a tradeoff, either be backwards-compatible with NT4 (whi=
ch I
> doubt is still widely used except maybe on a few servers which no-one wan=
ts to
> touch) and face an incredibly difficult task of writing an NT kernel driv=
er to

There's still a reasonable number of deployed NT 4 systems, including
desktops.  Often it's a case of "it's not broken for us" and not/or
wanting to go to the effort of moving off a platform that has been
reliable and stable until the last possible minute.

> do it, or require Win2K and have Microsoft do most of it for you.  Trying=
 to be
> NT4-compatible seems to be an unnecesarily painful way to do things.

I do agree with the conclusion, though.

--=20
"You grabbed my hand and we fell into it, like a daydream - or a fever."

--6c2NcOVqGQ03X4Wi
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE88fLEJ2Vo11xhU60RAnZqAJ9cdalOD86O1R9XHso7ORws3ZkyRwCeLdEh
zefwGwEl3R5XV7OanXhSmZc=
=2+Eo
-----END PGP SIGNATURE-----

--6c2NcOVqGQ03X4Wi--


From disastry@saiknes.lv  Mon May 27 12:18:02 2002
From: disastry@saiknes.lv (disastry@saiknes.lv)
Date: Mon May 27 11:18:02 2002
Subject: Re[4]: A modified version of GnuPG
Message-ID: <3CF1E23A.24C83E24@saiknes.lv>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Max V. Zinal wrote:
> 
> PG> You don't need to do that, there are already user-level functions which do
> PG> this.  To save me having to regurgitate it all again, search sci.crypt or the
> PG> archives of Perry Metzger's crypto list for "AllocateUserPhysicalPages" to find
> PG> the details.
> 
> I  know about these functions. Please note that they are the part
> of  Address  Windowing  Extensions  (AWE), and thus are supported
> only  with W2K or higher. We should also remember that Windows NT
> 4 is still widely used.

so just call GetProcAderss(hKernel32,"AllocateUserPhysicalPages");
to find if the function is available, if yes - use it :)

__
Disastry  http://disastry.dhs.org/
http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon
 ^----PGP 2.6.3ia-multi06 (supports IDEA, CAST5, BLOWFISH, TWOFISH,
      AES, 3DES ciphers and MD5, SHA1, RIPEMD160, SHA2 hashes)
-----BEGIN PGP SIGNATURE-----
Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1

iQA/AwUBPPHFvjBaTVEuJQxkEQNNOQCcCOw75WYyyyORl+IDWPnldvTOHiYAoMn6
nTM1sXjGVJSkewvIIlSY9NyA
=c7hS
-----END PGP SIGNATURE-----


From rjhansen@inav.net  Mon May 27 13:11:01 2002
From: rjhansen@inav.net (Robert J. Hansen)
Date: Mon May 27 12:11:01 2002
Subject: Unpredictable GPGME bug
Message-ID: <Pine.LNX.4.44L0.0205270506070.16314-100000@soli.inav.net>

Looks like there might be a bug in GPGME (I know, pre-1.0 software with 
bugs--what's the world coming to?).  My C++ bindings for GPGME attempt to 
grab all sorts of string data for a given key, and sometimes it will be 
able to grab a string representation of the algorithm type and other times 
it'll segfault.  The offending snippet of code looks like:

GpgmeKey _key;
std::string _algo;

_algo = gpgme_key_get_string_attr(_key, GPGME_ATTR_ALGO, NULL, 0);

... Maybe one time in ten, that line of code will segfault.  
gpgme_key_get_string_attr apparently returns a NULL pointer, and trying to 
make a C++ std::string out of a NULL pointer is an instant segfault.

This has happened for other string quantities, such as usernames, etc.  
For now, my solution is to assign the result of g_k_g_s_a() to a const 
char*, test the const char* against NULL, and then assign either the const 
char* to _algo or else assign "Unassigned" to _algo.  However, this is 
fairly inelegant given that we could just fix the GPGME code.  :)





From rjhansen@inav.net  Mon May 27 14:23:02 2002
From: rjhansen@inav.net (Robert J. Hansen)
Date: Mon May 27 13:23:02 2002
Subject: GPGME wishlist...
Message-ID: <Pine.LNX.4.44L0.0205270600470.7300-100000@soli.inav.net>

*  The terminology in the documentation is a little awkward when it comes 
to signatures (on keys/user IDs).  For instance, there's a section on 
"Trust Items"--well, yeah, signatures tell us if a key/userid is or isn't 
trusted... on the other hand, gpgme_key_get_string_attr says that it's 
used for "attributes of sub keys and user IDs", and a signature is an 
attribute of those, so... etc.  It appears that both interfaces are 
necessary to some degree, but the docs never make it clear to what degree 
each are necessary.

*  How to get key signature information is a little 
awkward/counterintuitive.  For instance, according to my current (limited) 
understanding of the interface, in order to process key signatures I must:

1.  call gpgme_op_trustlist_start, passing in a 16-hex key ID to uniquely 
identify the key I want to iterate over

2.  start pulling trust items off the key

3.  get each item's GPGME_ATTR_USERID

4.  ... and only then can I associate a given trust item with a given user 
ID.

Please note: I haven't written code that works this way yet.  This is just 
the way I understand it to be, from looking at the docs.  If I'm 
misunderstanding, then please take my idiocy as evidence the docs need to 
be written for congenital idiots such as myself (grin).  If I'm not 
misunderstanding the docs, then it seems like we're making the process 
tougher than it needs to be.

Possible solution: add a new function,

gpgme_op_trustlist_uid_start(
	GpgmeCtx ctx,
	const char *hexID,
	int userID,
	int max_level
	)

... which would act just like gpgme_op_trustlist_start, except it would 
restrict the iteration to a given user ID.  This would make things a 
little easier for those of us who aren't geniuses.  :)

It's 6:20am and now I'm going to bed.  Thanks, guys.
	



From Marcus.Brinkmann@ruhr-uni-bochum.de  Mon May 27 14:54:02 2002
From: Marcus.Brinkmann@ruhr-uni-bochum.de (Marcus Brinkmann)
Date: Mon May 27 13:54:02 2002
Subject: Unpredictable GPGME bug
In-Reply-To: <Pine.LNX.4.44L0.0205270506070.16314-100000@soli.inav.net>
References: <Pine.LNX.4.44L0.0205270506070.16314-100000@soli.inav.net>
Message-ID: <20020527115449.GB1180@212.23.136.22>

On Mon, May 27, 2002 at 05:12:24AM -0500, Robert J. Hansen wrote:
> Looks like there might be a bug in GPGME (I know, pre-1.0 software with 
> bugs--what's the world coming to?).  My C++ bindings for GPGME attempt to 
> grab all sorts of string data for a given key, and sometimes it will be 
> able to grab a string representation of the algorithm type and other times 
> it'll segfault.  The offending snippet of code looks like:
> 
> GpgmeKey _key;
> std::string _algo;
> 
> _algo = gpgme_key_get_string_attr(_key, GPGME_ATTR_ALGO, NULL, 0);
> 
> ... Maybe one time in ten, that line of code will segfault.  

What do you mean?  one out of ten times you run this on the same key, or for
one out of ten keys?

Let's look at the code:
    case GPGME_ATTR_ALGO:
      for (k = &key->keys; k && idx; k=k->next, idx--)
        ;
      if (k)
        val = pkalgo_to_string (k->key_algo);
      break;

So, if _key is really a key (and not NULL itself), which contains at least
one subkey (key->keys)), then this can not return NULL, because
pkalgo_to_string doesn't return NULL.

You could let it crash in gdb and check what the key and key->keys look
like in the case it is failing.

> gpgme_key_get_string_attr apparently returns a NULL pointer, and trying to 
> make a C++ std::string out of a NULL pointer is an instant segfault.
> 
> This has happened for other string quantities, such as usernames, etc.  
> For now, my solution is to assign the result of g_k_g_s_a() to a const 
> char*, test the const char* against NULL, and then assign either the const 
> char* to _algo or else assign "Unassigned" to _algo.  However, this is 
> fairly inelegant given that we could just fix the GPGME code.  :)

Most properties are optional and can return NULL, so you must catch the NULL
case anyway.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de


From aphex@nullify.org  Mon May 27 19:54:02 2002
From: aphex@nullify.org (Keith Ray)
Date: Mon May 27 18:54:02 2002
Subject: Photo ID race condition
Message-ID: <1022518490.3cf264daeba39@mail.nullify.org>

There is a (non-security) race condition in the photo ID code under
Windows.  If the user has a slow loading image viewer (ie. Mozilla), GnuPG could
delete the temp file before the viewer finishes initializing.  I can think of a
number of solutions:

1. Wait for the viewer to exit before returning to GnuPG.
2. Insert a delay between exec_read() and exec_finish().  Then again, on a slow
system with little RAM, how much is enough?
3. Delay deleting the temp files until GnuPG exits.

  -- Keith


From dmitri@users.sourceforge.net  Mon May 27 20:19:01 2002
From: dmitri@users.sourceforge.net (Dmitri)
Date: Mon May 27 19:19:01 2002
Subject: Photo ID race condition
In-Reply-To: <1022518490.3cf264daeba39@mail.nullify.org>
References: <1022518490.3cf264daeba39@mail.nullify.org>
Message-ID: <1022520028.3628.40.camel@usb.networkfab.com>

--=-AzaZ68uR4RPMwOrnXu5h
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Mon, 2002-05-27 at 09:54, Keith Ray wrote:

> There is a (non-security) race condition in the photo ID code under
> Windows.  If the user has a slow loading image viewer (ie. Mozilla), GnuP=
G could
> delete the temp file before the viewer finishes initializing.  I can thin=
k of a
> number of solutions:
>=20
> 1. Wait for the viewer to exit before returning to GnuPG.

GnuPG actually won't stop running. But this seems to be the right
solution. See CreateProcess() and OpenProcess() here:

http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/dllproc/=
prothred_9dpv.asp

> 2. Insert a delay between exec_read() and exec_finish().  Then again, on =
a slow
> system with little RAM, how much is enough?

Fudge factor works only in 27% of all cases ;-)

> 3. Delay deleting the temp files until GnuPG exits.

Dmitri


--=-AzaZ68uR4RPMwOrnXu5h
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA88mrcXksyLpO6T4IRArRkAKCZkrFAjDwHkuaFdDrELgC9ztS9PwCfS4pY
ahMRn0RVeY4yLBGuc9XW8us=
=x11+
-----END PGP SIGNATURE-----

--=-AzaZ68uR4RPMwOrnXu5h--



From wk@gnupg.org  Mon May 27 21:03:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Mon May 27 20:03:01 2002
Subject: A modified version of GnuPG
In-Reply-To: <3CF1E23A.24C83E24@saiknes.lv> (disastry@saiknes.lv's message
 of "Mon, 27 May 2002 09:37:30 +0200")
References: <3CF1E23A.24C83E24@saiknes.lv>
Message-ID: <87lma5mpmp.fsf@alberti.gnupg.de>

On Mon, 27 May 2002 09:37:30 +0200, disastry  said:

> so just call GetProcAderss(hKernel32,"AllocateUserPhysicalPages");
> to find if the function is available, if yes - use it :)

I'll see what I can do.  I have to incorporate some RNG enhancements from
Cryptlib anyway.


Salam-Shalom,

   Werner



From wk@gnupg.org  Mon May 27 21:07:02 2002
From: wk@gnupg.org (Werner Koch)
Date: Mon May 27 20:07:02 2002
Subject: GPGME wishlist...
In-Reply-To: <Pine.LNX.4.44L0.0205270600470.7300-100000@soli.inav.net> ("Robert
 J. Hansen"'s message of "Mon, 27 May 2002 06:23:29 -0500 (CDT)")
References: <Pine.LNX.4.44L0.0205270600470.7300-100000@soli.inav.net>
Message-ID: <87hektmper.fsf@alberti.gnupg.de>

On Mon, 27 May 2002 06:23:29 -0500 (CDT), Robert J Hansen said:

> *  How to get key signature information is a little 
> awkward/counterintuitive.  For instance, according to my current (limited) 
> understanding of the interface, in order to process key signatures I must:

Frankly, there is no interface for it.  


> 1.  call gpgme_op_trustlist_start, passing in a 16-hex key ID to

This is an expermimental - I hope the manual says so, but I am not
sure.  


Shalom-Salam,

   Werner



From andrew@mcdonald.org.uk  Mon May 27 21:19:01 2002
From: andrew@mcdonald.org.uk (Andrew McDonald)
Date: Mon May 27 20:19:01 2002
Subject: Photo ID race condition
In-Reply-To: <1022518490.3cf264daeba39@mail.nullify.org>
References: <1022518490.3cf264daeba39@mail.nullify.org>
Message-ID: <20020527181933.GA969@mcdonald.org.uk>

On Mon, May 27, 2002 at 11:54:50AM -0500, Keith Ray wrote:
> There is a (non-security) race condition in the photo ID code under
> Windows.  If the user has a slow loading image viewer (ie. Mozilla),
> GnuPG could delete the temp file before the viewer finishes
> initializing.

This is an issue I have seen mentioned in connection with mutt's
viewing of attachments. Try searching for mutt_bgrun, a script that
provides one way to solve this.

-- 
Andrew McDonald
E-mail: andrew@mcdonald.org.uk
http://www.mcdonald.org.uk/andrew/


From dshaw@jabberwocky.com  Tue May 28 01:51:01 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Tue May 28 00:51:01 2002
Subject: Photo ID race condition
In-Reply-To: <1022518490.3cf264daeba39@mail.nullify.org>
References: <1022518490.3cf264daeba39@mail.nullify.org>
Message-ID: <20020527223655.GB813@akamai.com>

On Mon, May 27, 2002 at 11:54:50AM -0500, Keith Ray wrote:
> There is a (non-security) race condition in the photo ID code under
> Windows.  If the user has a slow loading image viewer (ie. Mozilla), GnuPG could
> delete the temp file before the viewer finishes initializing.  I can think of a
> number of solutions:
> 
> 1. Wait for the viewer to exit before returning to GnuPG.
> 2. Insert a delay between exec_read() and exec_finish().  Then again, on a slow
> system with little RAM, how much is enough?
> 3. Delay deleting the temp files until GnuPG exits.

This is a known problem with 1.0.7 (1.0.7 was never really intended
for widespread Win32 use).  Until 1.0.8 is released with a
non-system()-based implementation of the exec code, you have a few
options:

1) Patch the code based on the CVS
2) Use %I instead of %i in your photo-viewer command line
3) Try a photo-viewer of "start /w %i.jpg"

(#3 should work but I haven't tested it - I'm traveling and have no
access to a windows box at the moment)

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From aphex@nullify.org  Tue May 28 04:40:01 2002
From: aphex@nullify.org (Keith Ray)
Date: Tue May 28 03:40:01 2002
Subject: Photo ID race condition
Message-ID: <1022550030.3cf2e00e4d1e1@mail.nullify.org>

Quoting David Shaw <dshaw@jabberwocky.com>:
> On Mon, May 27, 2002 at 11:54:50AM -0500, Keith Ray wrote:
> > There is a (non-security) race condition in the photo ID code under
> > Windows.  If the user has a slow loading image viewer (ie. Mozilla), GnuPG
> > could delete the temp file before the viewer finishes initializing.  I can
> > think of a number of solutions:
> >
> > 1. Wait for the viewer to exit before returning to GnuPG.
> > 2. Insert a delay between exec_read() and exec_finish().  Then again, on a
> > slow system with little RAM, how much is enough?
> > 3. Delay deleting the temp files until GnuPG exits.
>
> This is a known problem with 1.0.7 (1.0.7 was never really intended
> for widespread Win32 use).  Until 1.0.8 is released with a
> non-system()-based implementation of the exec code, you have a few
> options:
>
> 1) Patch the code based on the CVS
> 2) Use %I instead of %i in your photo-viewer command line
> 3) Try a photo-viewer of "start /w %i.jpg"
>
> (#3 should work but I haven't tested it - I'm traveling and have no
> access to a windows box at the moment)

Hmm, I should have been more explicit on my setup ;)  I was using 1.0.7a-cvs
from May 24.  The photo viewer was the default:

#define DEFAULT_PHOTO_COMMAND "start /w %i"

Mozilla is the default .jpg viewer.   For some reason, execution returns to
GnuPG immediately after launching Mozilla.  Mozilla does not finish loading
itself and then the picture before GnuPG deletes the temporary directory and
file.  Thus, solution #3 isn't working.

Unless there is a way to modify the "start" command to actually wait when
launching an object file instead of an executable, I think the best route would
be to read the registry to find the default viewer and then "start" that.

I will code up a patch against CVS and e-mail it to you when I'm done.

  -- Keith


From dshaw@jabberwocky.com  Tue May 28 05:30:02 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Tue May 28 04:30:02 2002
Subject: Photo ID race condition
In-Reply-To: <1022550030.3cf2e00e4d1e1@mail.nullify.org>
References: <1022550030.3cf2e00e4d1e1@mail.nullify.org>
Message-ID: <20020528023032.GE813@akamai.com>

On Mon, May 27, 2002 at 08:40:30PM -0500, Keith Ray wrote:
> Hmm, I should have been more explicit on my setup ;)  I was using 1.0.7a-cvs
> from May 24.  The photo viewer was the default:
> 
> #define DEFAULT_PHOTO_COMMAND "start /w %i"
> 
> Mozilla is the default .jpg viewer.   For some reason, execution returns to
> GnuPG immediately after launching Mozilla.  Mozilla does not finish loading
> itself and then the picture before GnuPG deletes the temporary directory and
> file.  Thus, solution #3 isn't working.

It looks like Mozilla is being "helpful" here and returning control
before doing the requested command.  If that is the case, then this is
not something that GnuPG can address.  Are you sure that is what is
happening?  What happens when you do "start /w foobar.jpg" from the
command line on some other jpg you may have lying around?

> Unless there is a way to modify the "start" command to actually wait
> when launching an object file instead of an executable, I think the
> best route would be to read the registry to find the default viewer
> and then "start" that.

GnuPG is a crypto program, and reading the registry to figure out
photo viewers is getting too far astray from that core functionality.
This is where bugs come in and bugs in crypto software can be very
dangerous.  I did add generic call-a-program functionality because it
is usable in several places (keyservers as well as photo IDs) but it
must be kept simple and easily verifiable.

In any event, the whole point of "start" itself is to read the
registry and start the appropriate program, so there is no point in
adding code to do this to GnuPG.

> I will code up a patch against CVS and e-mail it to you when I'm done.

The "/w" flag for start means "wait".  Unfortunately, it seems that
Mozilla's start-in-the-background feature defeats this.  If that is
what is happening then there is nothing that can (easily) be done here
with start or even internal to GnuPG since it can only wait for a
program that does not start in the background (some viewers give you a
choice).

If you must use Mozilla as your viewer, then use %I in your
photo-viewer rather than %i (that is, capital "I" rather than
lowercase "i").  This will make GnuPG not delete the temp file at all,
so you will need to delete it yourself when you are done with it.

Like I said before, 1.0.8 has a slightly different implementation (not
yet checked in, so you won't see it in CVS) that allows for better
handling of arguments in the photo-viewer command line, but there is
very little that can be done about the start-in-the-background
problem.  If it makes you feel any better, it's the same way on Unix
when using temp files, but at least the Unix viewers usually aren't
written to background themselves automatically.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From keith@nullify.org  Tue May 28 11:48:01 2002
From: keith@nullify.org (Keith Ray)
Date: Tue May 28 10:48:01 2002
Subject: Photo ID race condition
In-Reply-To: <20020527223655.GB813@akamai.com>
References: <1022518490.3cf264daeba39@mail.nullify.org> <20020527223655.GB813@akamai.com>
Message-ID: <1022550003.3cf2dff3e2115@mail.nullify.org>

Quoting David Shaw <dshaw@jabberwocky.com>:
> On Mon, May 27, 2002 at 11:54:50AM -0500, Keith Ray wrote:
> > There is a (non-security) race condition in the photo ID code under
> > Windows.  If the user has a slow loading image viewer (ie. Mozilla), GnuPG
> > could delete the temp file before the viewer finishes initializing.  I can
> > think of a number of solutions:
> > 
> > 1. Wait for the viewer to exit before returning to GnuPG.
> > 2. Insert a delay between exec_read() and exec_finish().  Then again, on a
> > slow system with little RAM, how much is enough?
> > 3. Delay deleting the temp files until GnuPG exits.
> 
> This is a known problem with 1.0.7 (1.0.7 was never really intended
> for widespread Win32 use).  Until 1.0.8 is released with a
> non-system()-based implementation of the exec code, you have a few
> options:
> 
> 1) Patch the code based on the CVS
> 2) Use %I instead of %i in your photo-viewer command line
> 3) Try a photo-viewer of "start /w %i.jpg"
> 
> (#3 should work but I haven't tested it - I'm traveling and have no
> access to a windows box at the moment)

Hmm, I should have been more explicit on my setup ;)  I was using 1.0.7a-cvs
from May 24.  The photo viewer was the default:

#define DEFAULT_PHOTO_COMMAND "start /w %i"

Mozilla is the default .jpg viewer.   For some reason, execution returns to
GnuPG immediately after launching Mozilla.  Mozilla does not finish loading
itself and then the picture before GnuPG deletes the temporary directory and
file.  Thus, solution #3 isn't working.

Unless there is a way to modify the "start" command to actually wait when
launching an object file instead of an executable, I think the best route would
be to read the registry to find the default viewer and then "start" that.

I will code up a patch against CVS and e-mail it to you when I'm done.

  -- Keith


From wk@gnupg.org  Tue May 28 12:33:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Tue May 28 11:33:01 2002
Subject: Photo ID race condition
In-Reply-To: <1022550003.3cf2dff3e2115@mail.nullify.org> (Keith Ray's
 message of "Mon, 27 May 2002 20:40:03 -0500")
References: <1022518490.3cf264daeba39@mail.nullify.org>
 <20020527223655.GB813@akamai.com>
 <1022550003.3cf2dff3e2115@mail.nullify.org>
Message-ID: <87elfwlim1.fsf@alberti.gnupg.de>

On Mon, 27 May 2002 20:40:03 -0500, Keith Ray said:

> Unless there is a way to modify the "start" command to actually wait when
> launching an object file instead of an executable, I think the best route would
> be to read the registry to find the default viewer and then "start" that.

> I will code up a patch against CVS and e-mail it to you when I'm done.

You better write a wrapper taking care of of starting the default
image viewer and deleting the temporary file.  I don't think it is a
good idea to add this extra code to gpg.


Shalom-Salam,

   Werner



From wagner@tik.ee.ethz.ch  Wed May 29 07:27:01 2002
From: wagner@tik.ee.ethz.ch (wagner@tik.ee.ethz.ch)
Date: Wed May 29 06:27:01 2002
Subject: Mail delivery failed
Message-ID: <200205290427.GAA04870@tik2.ethz.ch>

The mail system has received a message appearently from you
that had the following header fields:

    From:     gnupg-devel-request@gnupg.org
    Subject:  Gnupg-devel digest, Vol 1 #373 - 2 msgs
    To:       gnupg-devel@gnupg.org
    Date:     Wed, 29 May 2002 06:25:43 +0200

The message has been deleted automatically for the following reason:

SPAM detected. Mail dropped.


This message has been generated automatically.


------------------------------------------------------------------------------
Arno Wagner           Dipl. Inform.          wagner@tik.ee.ethz.ch
 A modern US Navy cruiser now requires 26 tons of manuals. This is enough to 
 affect the vessel's performance. -- New Scientist on the paperless office
 
 Spam will get you reported to your ISP. I explicitely forbid you 
 to store my email address for purpose of reselling or spamming. 
 


From aphex@nullify.org  Thu May 30 06:00:03 2002
From: aphex@nullify.org (Keith Ray)
Date: Thu May 30 05:00:03 2002
Subject: Bug in parse_one_sig_subpkt ?
Message-ID: <1022727633.3cf595d1916a9@mail.nullify.org>

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

I think I have found a bug in the latest GnuPG v1.0.7a-cvs
(29-May-2002).  When generating a new keypair, build_sig_subpkt() calls
parse_one_sig_subpkt() with a type of SIGSUBPKT_KS_FLAGS.  Since there
is no 'case' for SIGSUBPKT_KS_FLAGS, parse_one_sig_subpkt() returns -1
and GnuPG fails.

  -- Keith

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7a-nr1 (Windows 2000) - GPGshell v2.30

iD8DBQE89ZWIBxrjkHkmmhIRAhvJAKCJweZVl8dt6muA4GBNZwVagmHd2gCdGQ5G
+MrsxTOmFINxe7ek6/MoVH0=
=FJc2
-----END PGP SIGNATURE-----


From dshaw@jabberwocky.com  Thu May 30 06:32:02 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Thu May 30 05:32:02 2002
Subject: Bug in parse_one_sig_subpkt ?
In-Reply-To: <1022727633.3cf595d1916a9@mail.nullify.org>
References: <1022727633.3cf595d1916a9@mail.nullify.org>
Message-ID: <20020530033209.GC6908@akamai.com>

On Wed, May 29, 2002 at 10:00:33PM -0500, Keith Ray wrote:

> I think I have found a bug in the latest GnuPG v1.0.7a-cvs
> (29-May-2002).  When generating a new keypair, build_sig_subpkt() calls
> parse_one_sig_subpkt() with a type of SIGSUBPKT_KS_FLAGS.  Since there
> is no 'case' for SIGSUBPKT_KS_FLAGS, parse_one_sig_subpkt() returns -1
> and GnuPG fails.

Fixed.  Thank you.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From keith@nullify.org  Thu May 30 12:00:01 2002
From: keith@nullify.org (Keith Ray)
Date: Thu May 30 11:00:01 2002
Subject: Bug in parse_one_sig_subpkt ?
Message-ID: <1022727578.3cf5959a34c68@mail.nullify.org>

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

I think I have found a bug in the latest GnuPG v1.0.7a-cvs
(29-May-2002).  When generating a new keypair, build_sig_subpkt() calls
parse_one_sig_subpkt() with a type of SIGSUBPKT_KS_FLAGS.  Since there
is no 'case' for SIGSUBPKT_KS_FLAGS, parse_one_sig_subpkt() returns -1
and GnuPG fails.

  -- Keith

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7a-nr1 (Windows 2000) - GPGshell v2.30

iD8DBQE89ZWIBxrjkHkmmhIRAhvJAKCJweZVl8dt6muA4GBNZwVagmHd2gCdGQ5G
+MrsxTOmFINxe7ek6/MoVH0=
=FJc2
-----END PGP SIGNATURE-----


From wagner@tik.ee.ethz.ch  Thu May 30 12:01:01 2002
From: wagner@tik.ee.ethz.ch (wagner@tik.ee.ethz.ch)
Date: Thu May 30 11:01:01 2002
Subject: Mail delivery failed
Message-ID: <200205300902.LAA17729@tik2.ethz.ch>

The mail system has received a message appearently from you
that had the following header fields:

    From:     gnupg-devel-request@gnupg.org
    Subject:  Gnupg-devel digest, Vol 1 #374 - 3 msgs
    To:       gnupg-devel@gnupg.org
    Date:     Thu, 30 May 2002 06:25:43 +0200

The message has been deleted automatically for the following reason:

SPAM detected. Mail dropped.


This message has been generated automatically.


------------------------------------------------------------------------------
Arno Wagner           Dipl. Inform.          wagner@tik.ee.ethz.ch
 A modern US Navy cruiser now requires 26 tons of manuals. This is enough to 
 affect the vessel's performance. -- New Scientist on the paperless office
 
 Spam will get you reported to your ISP. I explicitely forbid you 
 to store my email address for purpose of reselling or spamming. 
 


From denis@ripe.net  Thu May 30 12:11:01 2002
From: denis@ripe.net (Denis Walker)
Date: Thu May 30 11:11:01 2002
Subject: dry run
Message-ID: <200205300908.g4U98NA09988@birch.ripe.net>

Hi guys

The man pages and your on line docs both say that dry run is not yet fully 
implemented. What does this mean? Can I safely use dry run to check the 
response before doing the changes?

cheers
denis



From denis@ripe.net  Thu May 30 12:16:01 2002
From: denis@ripe.net (Denis Walker)
Date: Thu May 30 11:16:01 2002
Subject: dry run
Message-ID: <200205300916.g4U9GlA14641@birch.ripe.net>

Hi guys

The man pages and your on line docs both say that dry run is not yet fully 
implemented. What does this mean? Can I safely use dry run to check the 
response before doing the changes?

cheers
denis





From wk@gnupg.org  Thu May 30 12:21:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Thu May 30 11:21:01 2002
Subject: Mail delivery failed
In-Reply-To: <200205300902.LAA17729@tik2.ethz.ch> (wagner@tik.ee.ethz.ch's
 message of "Thu, 30 May 2002 11:02:08 +0200 (MET DST)")
References: <200205300902.LAA17729@tik2.ethz.ch>
Message-ID: <87n0uif0ob.fsf@alberti.gnupg.de>

Hi!

I disapled you account until you get your spam "reporting" tool
right.  I'd suggest to remove it entirely because automated spam
reporting does more harm than real spam.


Shalom-Salam,

   Werner



From chris@netservers.co.uk  Thu May 30 12:44:02 2002
From: chris@netservers.co.uk (Chris Wilson)
Date: Thu May 30 11:44:02 2002
Subject: Mail delivery failed
In-Reply-To: <200205300902.LAA17729@tik2.ethz.ch>
Message-ID: <Pine.LNX.4.44.0205301043500.30283-100000@localhost>

Dear Wagner,

If you are going to treat this list as spam, would you please unsubscribe?

Cheers, Chris.

On Thu, 30 May 2002 wagner@tik.ee.ethz.ch wrote:

> The mail system has received a message appearently from you
> that had the following header fields:
> 
>     From:     gnupg-devel-request@gnupg.org
>     Subject:  Gnupg-devel digest, Vol 1 #374 - 3 msgs
>     To:       gnupg-devel@gnupg.org
>     Date:     Thu, 30 May 2002 06:25:43 +0200
> 
> The message has been deleted automatically for the following reason:
> 
> SPAM detected. Mail dropped.
> 
> 
> This message has been generated automatically.
> 
> 
> ------------------------------------------------------------------------------
> Arno Wagner           Dipl. Inform.          wagner@tik.ee.ethz.ch
>  A modern US Navy cruiser now requires 26 tons of manuals. This is enough to 
>  affect the vessel's performance. -- New Scientist on the paperless office
>  
>  Spam will get you reported to your ISP. I explicitely forbid you 
>  to store my email address for purpose of reselling or spamming. 
>  
> 
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
> 

-- 
   ___ __     _
 / __// / ,__(_)_  | Chris Wilson -- UNIX Firewall Lead Developer |
/ (_ / ,\/ _/ /_ \ | NetServers.co.uk http://www.netservers.co.uk |
\ _//_/_/_//_/___/ | 21 Signet Court, Cambridge, UK. 01223 576516 |



From denis@ripe.net  Thu May 30 14:47:01 2002
From: denis@ripe.net (Denis Walker)
Date: Thu May 30 13:47:01 2002
Subject: deleting a uid from a public key
Message-ID: <200205301148.g4UBmSA28404@birch.ripe.net>

Hi guys

According to your manual you can delete a uid from your local public key. But 
if someone else imports your key it merges the uids from the old and new keys. 
So the deletion does not take effect. The manual says in order to delete a uid 
from someone's public key you must first remove the key and them import the 
new key. Why does import not delete uids? Are there any security implications 
involved here? If I am updating keys should I always remove the key first and 
them import the new one?

cheers
denis



From dshaw@jabberwocky.com  Thu May 30 15:23:01 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Thu May 30 14:23:01 2002
Subject: deleting a uid from a public key
In-Reply-To: <200205301148.g4UBmSA28404@birch.ripe.net>
References: <200205301148.g4UBmSA28404@birch.ripe.net>
Message-ID: <20020530122316.GE6908@akamai.com>

On Thu, May 30, 2002 at 01:48:28PM +0200, Denis Walker wrote:
> Hi guys
> 
> According to your manual you can delete a uid from your local public
> key. But if someone else imports your key it merges the uids from
> the old and new keys.  So the deletion does not take effect. The
> manual says in order to delete a uid from someone's public key you
> must first remove the key and them import the new key. Why does
> import not delete uids? Are there any security implications involved
> here? If I am updating keys should I always remove the key first and
> them import the new one?

As you saw, deleting a uid does not really delete it - it will come
back when the key is merged with an earlier copy of itself.  There are
several reasons for this, the simplest being: how does GnuPG know
which is the "more recent" key?  For example, if I have a key with 3
uids, and I import the same key with 2 uids, does that mean that one
of the uids is to be deleted (the 2 uid version is newer) or should I
do nothing (the 3 uid version is newer).

To resolve this, OpenPGP allows a user to revoke a uid - a revoked uid
is present on the key but is not used.  If you have a uid that you
don't want to use any longer, use "revsig" to revoke the
self-signature on that uid.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From stephane@sente.ch  Thu May 30 19:11:02 2002
From: stephane@sente.ch (=?ISO-8859-1?Q?St=E9phane_Corth=E9sy?=)
Date: Thu May 30 18:11:02 2002
Subject: charset problem
Message-ID: <07E6337B-73E8-11D6-B149-0003936A3BE2@sente.ch>

Hi,

Is the following behavior correct?

The file ~/.gnupg/options contains an option "comment" with value "=E9=20=

eacute"; file has been saved using UTF8 encoding.
The file /tmp/test contains same text "=E9 eacute", but in iso-8859-1.

Performing the command

gpg --charset iso-8859-1 --clearsign /tmp/test

creates a new file /tmp/test.asc which contains invalid text: there is a=20=

mix of iso-8859-1 (for the body) and UTF8 (for the signature) charsets!

It seems that comment is copied as is, i.e. not converted to --charset=20=

(what is furthermore not always possible...), thus result is totally=20
unreadable.


(I'm working with GnuPG 1.0.7 on MacOS X 10.1.4.)

Cheers,

St=E9phane



From stephane@sente.ch  Thu May 30 19:23:02 2002
From: stephane@sente.ch (=?ISO-8859-1?Q?St=E9phane_Corth=E9sy?=)
Date: Thu May 30 18:23:02 2002
Subject: malloc problem
Message-ID: <A5359632-73E9-11D6-B149-0003936A3BE2@sente.ch>

Hi,

Running gpg 1.0.7 on MacOS X 10.1.4, I noticed a malloc problems. I type=20=

the following command:

gpg --debug 511 --charset utf-8 --no-force-v3-sigs --armor=20
--notation-data mycode=3Dmyvalue --clearsign

Then I enter my passphrase, the text to sign ("test") and CTRL-D, and=20
there is a (MacOS X specific) malloc warning. Can anyone reproduce the=20=

problem on another system having a malloc-protection too (guard pages)?
Problem is due to the notation-data presence.

Cheers,

St=E9phane

... [snipped]...
gpg: DBG: iobuf-7.0: underflow: eof
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

test
gpg: DBG: armor-filter: control: 5
gpg: DBG: iobuf-8.1: push `armor_filter'
gpg: DBG: armor-filter: control: 5
gpg: DBG: iobuf chain: 8.1 `armor_filter' filter_eof=3D0 start=3D0 len=3D0=

gpg: DBG: iobuf chain: 8.0 `file_filter(fd)' filter_eof=3D0 start=3D0 =
len=3D0
gpg: DBG: armor-filter: control: 1
*** malloc[4606]: Deallocation of a pointer not malloced: 0x20d2ff; This=20=

could be a double free(), or free() called with the middle of an=20
allocated block; Try setting environment variable MallocHelp to see=20
tools to help debug
gpg: DBG: mpi_alloc(160)
gpg: DBG: mpi_alloc_limb_space(160)
gpg: DBG: pubkey_sign: algo=3D17
...[snipped]...






From dshaw@jabberwocky.com  Thu May 30 20:14:01 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Thu May 30 19:14:01 2002
Subject: malloc problem
In-Reply-To: <A5359632-73E9-11D6-B149-0003936A3BE2@sente.ch>
References: <A5359632-73E9-11D6-B149-0003936A3BE2@sente.ch>
Message-ID: <20020530171410.GG6908@akamai.com>

On Thu, May 30, 2002 at 06:23:59PM +0200, St=E9phane Corth=E9sy wrote:
> Hi,
>=20
> Running gpg 1.0.7 on MacOS X 10.1.4, I noticed a malloc problems. I typ=
e=20
> the following command:
>=20
> gpg --debug 511 --charset utf-8 --no-force-v3-sigs --armor=20
> --notation-data mycode=3Dmyvalue --clearsign
>=20
> Then I enter my passphrase, the text to sign ("test") and CTRL-D, and=20
> there is a (MacOS X specific) malloc warning. Can anyone reproduce the=20
> problem on another system having a malloc-protection too (guard pages)?
> Problem is due to the notation-data presence.

This was already fixed.  Thanks for the report though. :)

David

--=20
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.co=
m/
+------------------------------------------------------------------------=
---+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From Marc.Mutz@uni-bielefeld.de  Fri May 31 01:10:02 2002
From: Marc.Mutz@uni-bielefeld.de (Marc Mutz)
Date: Fri May 31 00:10:02 2002
Subject: charset problem
In-Reply-To: <07E6337B-73E8-11D6-B149-0003936A3BE2@sente.ch>
References: <07E6337B-73E8-11D6-B149-0003936A3BE2@sente.ch>
Message-ID: <200205302342.29857@sendmail.mutz.com>

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 30 May 2002 18:12, St=E9phane Corth=E9sy wrote:
<snip>
> Is the following behavior correct?
>
> The file ~/.gnupg/options contains an option "comment" with value "=E9
> eacute"; file has been saved using UTF8 encoding.
> The file /tmp/test contains same text "=E9 eacute", but in iso-8859-1.
<snip>

The answer is simple: Don't use --comment with anything but US-ASCII=20
characters. Comment: is an _ASCII_ armor header. This name alone should=20
tell you why what you try is a bad idea.

Marc

=2D --=20
Marc Mutz <mutz@kde.org>
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE89pzE3oWD+L2/6DgRAn+HAJ4shlewFxf/3RFi2N69npX00Y/6WgCeJ0Xw
VTtAi1qZpPOMjlW9Fv2cuvg=3D
=3Du6/t
=2D----END PGP SIGNATURE-----



From keith@nullify.org  Fri May 31 07:52:01 2002
From: keith@nullify.org (Keith Ray)
Date: Fri May 31 06:52:01 2002
Subject: Photo ID viewer under Windows NT
Message-ID: <1022820757.3cf701952790a@mail.nullify.org>

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

I just tried the new method of calling the Photo ID viewer under
Windows.  Unfortunately, unlike system(), CreateProcess() does not get
interpretted through the system shell.  This means that only actual
executables can be run in CreateProcess(), not internal commands.  In
Windows 95/98/Me, "start" is actually start.exe.  Under Windows
NT/2k/XP, "start" is integrated into the shell and CreateProcess() fails
with "No such file or directory".  

You can still use CreateProcess() under NT, but you need to call:

cmd /c start /w %i

However, since 95 uses command.com instead of cmd.exe, this would fail
for those versions.

  -- Keith

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7a-nr1 (Windows 2000) - GPGshell v2.30

iD8DBQE89wGIBxrjkHkmmhIRAgckAJ0UrGhnSBGGEDXw12DHnkTKN07sKgCgidHE
Tu6W6+BlfQo4DoWHfV+YZ5I=
=vjL8
-----END PGP SIGNATURE-----


From dshaw@jabberwocky.com  Fri May 31 08:53:01 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Fri May 31 07:53:01 2002
Subject: Photo ID viewer under Windows NT
In-Reply-To: <1022820757.3cf701952790a@mail.nullify.org>
References: <1022820757.3cf701952790a@mail.nullify.org>
Message-ID: <20020531055358.GB2126@akamai.com>

On Thu, May 30, 2002 at 11:52:37PM -0500, Keith Ray wrote:

> I just tried the new method of calling the Photo ID viewer under
> Windows.  Unfortunately, unlike system(), CreateProcess() does not get
> interpretted through the system shell.  This means that only actual
> executables can be run in CreateProcess(), not internal commands.  In
> Windows 95/98/Me, "start" is actually start.exe.  Under Windows
> NT/2k/XP, "start" is integrated into the shell and CreateProcess() fails
> with "No such file or directory".  
> 
> You can still use CreateProcess() under NT, but you need to call:
> 
> cmd /c start /w %i
> 
> However, since 95 uses command.com instead of cmd.exe, this would fail
> for those versions.

So use the longer form?  I'm not sure what you're getting at
here. "start /w" doesn't work on NT, but neither does qiv or
xloadimage or any other other of the sample viewers.  The whole point
of the photo-viewer option is to set what viewer works for YOU and not
hard-code something in that may not work (or may work but not be what
you wanted: using "start" to read the registry doesn't work very well
if your .jpg viewer is photoshop, for example).

It's possible to use some conditional #defines to change the default
viewer at build time, but to what end?  Most people don't compile
their own win32 binary, and this would make the NT/2k/XP binary
different than 95/98/Me.

Remember: "start /w" is only the default.  If you don't like it (or if
it doesn't work on your system), change it.

If you're arguing that the default should be "cmd /c start /w", then
maybe - but it'll break the default for the 95/98/Me people.  I have
no strong feelings on which platform gets the 'better' default.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From avbidder@fortytwo.ch  Fri May 31 11:42:01 2002
From: avbidder@fortytwo.ch (Adrian 'Dagurashibanipal' von Bidder)
Date: Fri May 31 10:42:01 2002
Subject: charset problem
In-Reply-To: <200205302342.29857@sendmail.mutz.com>
References: <07E6337B-73E8-11D6-B149-0003936A3BE2@sente.ch>
 <200205302342.29857@sendmail.mutz.com>
Message-ID: <1022834611.25778.32.camel@atlas>

--=-O8C6NegOgiq8lsGL6BBq
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Thu, 2002-05-30 at 23:42, Marc Mutz wrote:

> The answer is simple: Don't use --comment with anything but US-ASCII=20
> characters. Comment: is an _ASCII_ armor header. This name alone should=20
> tell you why what you try is a bad idea.

Just curious: is there anything said (rfc, developer opinion, ...) about
the =3D?charset?x?encoded string?=3D encoding in armor headers?

cheers
-- vbi


--=20
secure email with gpg            avbidder@fortytwo.ch: key id 0x92082481
                                 avbidder@acter.ch:    key id 0x5E4B731F


--=-O8C6NegOgiq8lsGL6BBq
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA89zezwj49sl5Lcx8RAvYUAKCNXgrMfyRIItVFSOIuC1PKww+fOACfQX7S
wDFoRgb5SEIRFcwhIVXR+I8=
=HUba
-----END PGP SIGNATURE-----

--=-O8C6NegOgiq8lsGL6BBq--



From chris@netservers.co.uk  Fri May 31 12:02:01 2002
From: chris@netservers.co.uk (Chris Wilson)
Date: Fri May 31 11:02:01 2002
Subject: Batch mode
Message-ID: <Pine.LNX.4.44.0205301744240.30657-100000@localhost>

Hi all,

There are a number of operations which are not currently supported in 
batch mode. They include:

- key generation
- key signing
- key deletion

I would be happy to write patches to add this functionality, but my past 
e-mails, suggestions and patches sent to this list have been completely 
ignored. Therefore, I will probably not write the patches unless somebody 
says they are interested. So please tell me if you are.

Cheers, Chris.
-- 
   ___ __     _
 / __// / ,__(_)_  | Chris Wilson -- UNIX Firewall Lead Developer |
/ (_ / ,\/ _/ /_ \ | NetServers.co.uk http://www.netservers.co.uk |
\ _//_/_/_//_/___/ | 21 Signet Court, Cambridge, UK. 01223 576516 |



From wk@gnupg.org  Fri May 31 13:47:02 2002
From: wk@gnupg.org (Werner Koch)
Date: Fri May 31 12:47:02 2002
Subject: charset problem
In-Reply-To: <1022834611.25778.32.camel@atlas> (Adrian 'Dagurashibanipal'
 von Bidder's message of "31 May 2002 10:43:31 +0200")
References: <07E6337B-73E8-11D6-B149-0003936A3BE2@sente.ch>
 <200205302342.29857@sendmail.mutz.com>
 <1022834611.25778.32.camel@atlas>
Message-ID: <87bsawd1yj.fsf@alberti.gnupg.de>

On 31 May 2002 10:43:31 +0200, Adrian 'Dagurashibanipal' von Bidder said:

> Just curious: is there anything said (rfc, developer opinion, ...) about
> the =?charset?x?encoded string?= encoding in armor headers?

No.  Please don't use the comment for any real purpose - this is just
a gadget with no real use.  If you want to encode other information
you should either use notation data (which is included in the
signature) or use MIME headers for that.  As you know, the Comment and
all other armor headers are not protected by the signature.


Salam-Shalom,

   Werner





From wagner@tik.ee.ethz.ch  Fri May 31 13:52:01 2002
From: wagner@tik.ee.ethz.ch (Arno Wagner)
Date: Fri May 31 12:52:01 2002
Subject: Me "spamming" this list...
In-Reply-To: <E17DdzF-0005CF-00@trithemius.gnupg.org>; from gnupg-devel-request@gnupg.org on Fri, May 31, 2002 at 06:25:42AM +0200
References: <E17DdzF-0005CF-00@trithemius.gnupg.org>
Message-ID: <20020531125315.B10807@tik.ee.ethz.ch>

--n8g4imXOkfNTN/H1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Dear gnupg-devel list members,

in the last 48 hours (or so) this list has received messages
from my spam-detector about spam being dropped.=20

I am sorry about this, please accept my apology!

I think I should explain what happened, so maybe others can=20
avoid the mistakes I made: I have a very manual spam filter,
that I maintain by just adding to my .procmailrc. For hard spammers
I just drop the mail, for others I had an auto-reply feature.=20
While I was careful all my receipes are restrictive enough not
to be overly trigger-happy, I did not take into account the
possibility for a different kind of error.=20

What I effectively did in one match-expression whas replace the
leading "*" with a "$". As a result this rule appearently matched for
every Email that came in. As a consequence every email to me got a
notification about it being spam and dropped, which also happened to
all the messages telling me there was something wrong on my side.

To make things worse, we had an announced partial network outage=20
on Wednsday (routing tables cleanup) so I was not suspicous about
not getting any email. I was not at work on Wednsday, so I=20
finally found out about the problem when somebody phoned me
Thursday morning.=20

At that time I had about 30 messages telling me about the problem
and about 400 Messages from a mail-loop, that happened despite=20
my measures to prevent loops.

Lessons learned on my side:

  - Don't send out automatic responses to, if the trigger-
    mechanism has a single point-of-failure!

    For the time being I make that: Don't send out any automated
    responses.=20

  - Doing full logging is a very good idea when automatically=20
    deleting messages! =20

    Because I at least got this right, I did not loose any=20
    messages and was able to identify everybody that I needed to
    apologize to.

  - If you screw up, apologize a.s.a.p. to those affected and
    explain what happened!    =20

  - Look at statistics frequently!=20

    My previous set-up gave me one spam-summary per week. That is=20
    not enough, now I am getting a daily summary. =20

  - Make sure you understand the problem!=20

    My mail-loop detection scheme used a field in the header with=20
    a magic number. That is fine for every loop that keeps the=20
    auto-response somewhere in the replys, but this one list-admin=20
    daemon just send me a completely fresh email about not=20
    understanding my command. Practical loop detection is obviously
    more complicated than I thought ....

Once again, please accept my apologies for this incident!

Regards,
Arno

--=20
Arno Wagner, Communication Systems Group, ETH Zuerich, wagner@tik.ee.ethz.ch
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
For every complex problem there is an answer that is clear, simple,=20
and wrong. -- H L Mencken





--n8g4imXOkfNTN/H1
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iEYEARECAAYFAjz3VhsACgkQeX9rUB4lM48uLQCghU0zkyXRytpzgoX4B0msXvw2
fIgAn1thxK02W4Ge0jlImr5nVYRRjP88
=tPIM
-----END PGP SIGNATURE-----

--n8g4imXOkfNTN/H1--


From wk@gnupg.org  Fri May 31 13:53:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Fri May 31 12:53:01 2002
Subject: Batch mode
In-Reply-To: <Pine.LNX.4.44.0205301744240.30657-100000@localhost> (Chris
 Wilson's message of "Fri, 31 May 2002 10:02:13 +0100 (BST)")
References: <Pine.LNX.4.44.0205301744240.30657-100000@localhost>
Message-ID: <877klkd1qb.fsf@alberti.gnupg.de>

On Fri, 31 May 2002 10:02:13 +0100 (BST), Chris Wilson said:

> Hi all,
> There are a number of operations which are not currently supported in 
> batch mode. They include:

> - key generation

There is batch ke generation - see doc/DETAILS.

> - key signing
> - key deletion

This can't be done easily.  You need to present a lot of information
to the user so that he can decide wehther to sign or not.  Those
information vary from key to key and thus it can't be scripted.

We are working on a GPGME interface to do ease it up.  You may have
noticed problems with GPA when you don't use a standard key or use gpg
1.0.7.  This is due to a too simple approach to handle these
operations.

> I would be happy to write patches to add this functionality, but my past 
> e-mails, suggestions and patches sent to this list have been
> completely 

Sorry, That happens from time to time.  There is also the issue that
we need legal papers to include non-trivial patches.


Shalom-Salam,

   Werner



From chris@netservers.co.uk  Fri May 31 14:17:01 2002
From: chris@netservers.co.uk (Chris Wilson)
Date: Fri May 31 13:17:01 2002
Subject: Batch mode
In-Reply-To: <877klkd1qb.fsf@alberti.gnupg.de>
Message-ID: <Pine.LNX.4.44.0205311209080.30657-100000@localhost>

Hi Werner and the list,

> There is batch ke generation - see doc/DETAILS.

Sorry, my bad. This looks like what I need.

> This can't be done easily.  You need to present a lot of information
> to the user so that he can decide wehther to sign or not.  Those
> information vary from key to key and thus it can't be scripted.

In our environment the key is generated and immediately imported 
into another keyring and signed. There is no need to verify the identity 
of the key, etc. So it would be very useful for us to be able to sign 
automatically.

What objection is there to batch key deletion?

> We are working on a GPGME interface to do ease it up.  You may have
> noticed problems with GPA when you don't use a standard key or use gpg
> 1.0.7.  This is due to a too simple approach to handle these
> operations.

OK, but from what little I know of GPGME right now, it seems to be a 
powerful and complex API to using GPG. I don't need that, and it's not 
helpful for shell scripts. I just need to be able to automate the commands 
which I can give from the command line anyway.

> Sorry, That happens from time to time.  There is also the issue that
> we need legal papers to include non-trivial patches.

I am about to send in my papers to the FSF for some work I've done on Tar, 
but in any case I think these patches will be small enough that they 
shouldn't pose a legal problem for you. But I leave that to your 
discretion.

Ciao, Chris.
-- 
   ___ __     _
 / __// / ,__(_)_  | Chris Wilson -- UNIX Firewall Lead Developer |
/ (_ / ,\/ _/ /_ \ | NetServers.co.uk http://www.netservers.co.uk |
\ _//_/_/_//_/___/ | 21 Signet Court, Cambridge, UK. 01223 576516 |



From win@huh.org  Wed May  1 00:25:01 2002
From: win@huh.org (Winona Brown)
Date: Tue Apr 30 23:25:01 2002
Subject: AIX bug malloc(0)
Message-ID: <20020430212626.GA1048@arghh.huh.org>

make with aix5.1 compiler vac5 (xlc) was failing in checks until I added 
   if (n == 0)
       n = 1;
before calling malloc.

The technical reference for AIX 5L 5.1 says:

If the malloc or valloc subroutine is called with a size of 0, the subroutine
returns a null pointer

The better way to fix this would probably be to allow a NULL being returned
if malloc(0) was called.  

gnupg-1.0.7/util/memory.c

Winona



From redbird@rbisland.cx  Wed May  1 08:38:01 2002
From: redbird@rbisland.cx (Gordon Worley)
Date: Wed May  1 07:38:01 2002
Subject: gnupg 107 compilation on solaris 8
In-Reply-To: <200204301744.KAA00577@fionn.es.net>
Message-ID: <CB457866-5CC5-11D6-BDCA-000A27B4DEFC@rbisland.cx>

On Tuesday, April 30, 2002, at 01:44  PM, Michael Helm wrote:

>> ./configure --enable-static-rnd=unix
>
> Had exactly the same effect -- option apparently doesn't work

Trying throwing --disable-dynload into the mix.

--
Gordon Worley                     `When I use a word,' Humpty Dumpty
http://www.rbisland.cx/            said, `it means just what I choose
redbird@rbisland.cx                it to mean--neither more nor less.'
PGP:  0xBBD3B003                                  --Lewis Carroll



From BigBootyHoe69699@aol.com  Wed May  1 11:02:01 2002
From: BigBootyHoe69699@aol.com (BigBootyHoe69699@aol.com)
Date: Wed May  1 10:02:01 2002
Subject: Free Trail!! NO FEES!
Message-ID: <200204302358.DAA09114@cobi.coqui.net>

Mail from  (BigBootyHoe69699@aol.com) 
     on Wednesday, May 1, 2002 at 03:58:50
---------------------------------------------------------------------------

:: RIGHT NOW!  FREE Membership Available!  Don't know how long this offer will last, get it while you still can! We have BEAUTIFUL girls and they are just one click away from showing you the BEST time of your life! <a href="http://rd.yahoo.com/dir/?http://members.lycos.co.uk/g00dstuff">Click here</a>

---------------------------------------------------------------------------
A Service of Coqui.Net             bug-octave-request@bevo.che.utexas.edu,bug-octave@bevo.che.utexas.edu,help-octave-request@bevo.che.utexas.edu,help-octave@bevo.che.utexas.edu,announce-request@gnupg.org,gnupg-users-request@gnupg.org,gnupg-users@gnupg.org,gnupg-devel-request@gnupg.org,gnupg-devel@gnupg.org,bug-bison-request@gnu.org,


From BigBootyHoe69699@aol.com  Wed May  1 11:11:02 2002
From: BigBootyHoe69699@aol.com (BigBootyHoe69699@aol.com)
Date: Wed May  1 10:11:02 2002
Subject: Free Trail!! NO FEES!
Message-ID: <200205010008.EAA09698@cobi.coqui.net>

Mail from  (BigBootyHoe69699@aol.com) 
     on Wednesday, May 1, 2002 at 04:08:08
---------------------------------------------------------------------------

:: RIGHT NOW!  FREE Membership Available!  Don't know how long this offer will last, get it while you still can! We have BEAUTIFUL girls and they are just one click away from showing you the BEST time of your life! <a href="http://rd.yahoo.com/dir/?http://members.lycos.co.uk/g00dstuff">Click here</a>

---------------------------------------------------------------------------
A Service of Coqui.Net             bug-octave-request@bevo.che.utexas.edu,bug-octave@bevo.che.utexas.edu,help-octave-request@bevo.che.utexas.edu,help-octave@bevo.che.utexas.edu,announce-request@gnupg.org,gnupg-users-request@gnupg.org,gnupg-users@gnupg.org,gnupg-devel-request@gnupg.org,gnupg-devel@gnupg.org,bug-bison-request@gnu.org,


From hideki@allcity.net  Thu May  2 03:26:02 2002
From: hideki@allcity.net (Hideki Saito)
Date: Thu May  2 02:26:02 2002
Subject: 15MB files on photo
Message-ID: <200205020026.g420Qli28732@server-1.visp.net>

I found some problem with photo capability of 1.0.7 on Win32 
compilation.

If you try to display graphics, it is actually a bogus JPG file.

I have tried with the option i_view32 %i as a photo-viewer argument, 
and it returns "unknown header" error.

Then I tried i_view32 %I to see what actual "TEMP.JPG" is like, and it 
turns out be a 12MB - 15MB garbage file.

Is there any workaround to this?

-- 
Hideki Saito mailto:hideki@allcity.net


From dshaw@jabberwocky.com  Thu May  2 03:50:02 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Thu May  2 02:50:02 2002
Subject: 15MB files on photo
In-Reply-To: <200205020026.g420Qli28732@server-1.visp.net>
References: <200205020026.g420Qli28732@server-1.visp.net>
Message-ID: <20020502005106.GA25856@akamai.com>

On Wed, May 01, 2002 at 05:27:42PM -0700, Hideki Saito wrote:
> I found some problem with photo capability of 1.0.7 on Win32 
> compilation.
> 
> If you try to display graphics, it is actually a bogus JPG file.
> 
> I have tried with the option i_view32 %i as a photo-viewer argument, 
> and it returns "unknown header" error.
> 
> Then I tried i_view32 %I to see what actual "TEMP.JPG" is like, and it 
> turns out be a 12MB - 15MB garbage file.

Hmm.  Are you using a Mingw32 or Cygwin build?

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From hideki@allcity.net  Thu May  2 05:04:02 2002
From: hideki@allcity.net (Hideki Saito)
Date: Thu May  2 04:04:02 2002
Subject: 15MB files on photo
In-Reply-To: <20020502005106.GA25856@akamai.com>
References: <200205020026.g420Qli28732@server-1.visp.net>
 <20020502005106.GA25856@akamai.com>
Message-ID: <200205020205.g4225Fi03599@server-1.visp.net>

Mingw32 build it is...

>On Wed, May 01, 2002 at 05:27:42PM -0700, Hideki Saito wrote:
>> I found some problem with photo capability of 1.0.7 on Win32 
>> compilation.
>> 
>> If you try to display graphics, it is actually a bogus JPG file.
>> 
>> I have tried with the option i_view32 %i as a photo-viewer argument, 
>> and it returns "unknown header" error.
>> 
>> Then I tried i_view32 %I to see what actual "TEMP.JPG" is like, and it 
>> turns out be a 12MB - 15MB garbage file.
>
>Hmm.  Are you using a Mingw32 or Cygwin build?
>
>David
>
>-- 
>   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
>+---------------------------------------------------------------------------+
>   "There are two major products that come out of Berkeley: LSD and UNIX.
>      We don't believe this to be a coincidence." - Jeremy S. Anderson
>
>_______________________________________________
>Gnupg-devel mailing list
>Gnupg-devel@gnupg.org
>http://lists.gnupg.org/mailman/listinfo/gnupg-devel

-- 
Hideki Saito mailto:hideki@allcity.net


From mwy-gpg41@the-youngs.org  Thu May  2 06:43:01 2002
From: mwy-gpg41@the-youngs.org (Michael Young)
Date: Thu May  2 05:43:01 2002
Subject: feature request: always-trust [<keyring>]
References: <E172PDG-0002qc-00@trithemius.gnupg.org>
Message-ID: <003d01c1f18b$83100d60$c23fa8c0@transarc.ibm.com>

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

Jeff Breidenbach <jab@debian.org> asked for:
> What: ability to specify that everything in a specific
>       keyring will trusted by default.

This sounds like a reasonable request to me.  As you note, there
is already an "--always-trust" switch -- it's just global.
But I'm not one of the people you need to convince.

> Why:  In Debian, I can have a list of hundreds of developer=20
>       keys stored  in locally in /usr/share/keyrings/debian-keyring.gpg.
>       This file is trusted by me, dynamic, and is maintained by the
>       Debian Project. So I use the file as one of my keyrings.

I know you didn't ask for workarounds, but in case your request
isn't filled in a timely manner...

Could you convince whoever is maintaining the keyring to sign the keys
using some well-known "Debian Project" key?  Then, you could use the
existing trust mechanisms (up to and including the "--trusted-key"
switch).  This would also let you (or others) pick up keys from
keyservers, rather than rely purely on secure delivery of the shared
keyring file.

Failing that, you could automatically generate (local) signatures for
everything on the trusted keyring.  I would use a local key specific
to this purpose.  This requires some trickery: the "--batch" switch
disallows signing; the "--yes" switch has no effect.  It seems that
you need to use the "--command-fd" gadgetry (and in theory use the
"--status-fd" switch to know what to feed it), as in (using csh syntax):

    foreach x (`gpg --with-colons --list-keys | awk -F: '/^pub/{print $5}'`)
 echo YES | \
 gpg -u your_project_key --command-fd 0 --lsign-key $x
    end


While we're asking for features, I'll repeat my plea for one that
would help out on this workaround.  I'd sorely like to be able to use
the "--edit-key" commands (of which "--lsign" is a special case)
without having to deal with all of the questions.  It would be fine to
reuse an existing switch (like "--batch" or "--expert") or grow a new
one ("--just-do-it" or "--really-yes") to carry this meaning.
The same principle could be applied to disable the questions
about key size :-).

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQA/AwUBPNC1xFMkvpTT8vCGEQLqGQCgqMt4mcmi0OZOv543gBEwuY7H/8sAoOBV
0ESwD3C1sgvl99gAShvD9O3m
=tZW3
-----END PGP SIGNATURE-----




From wk@gnupg.org  Thu May  2 09:59:02 2002
From: wk@gnupg.org (Werner Koch)
Date: Thu May  2 08:59:02 2002
Subject: AIX bug malloc(0)
In-Reply-To: <20020430212626.GA1048@arghh.huh.org> (Winona Brown's message
 of "Tue, 30 Apr 2002 16:26:26 -0500")
References: <20020430212626.GA1048@arghh.huh.org>
Message-ID: <87znzjkpa0.fsf@alberti.gnupg.de>

On Tue, 30 Apr 2002 16:26:26 -0500, Winona Brown said:

> The better way to fix this would probably be to allow a NULL being returned
> if malloc(0) was called.  

Well yes, this would be better for debugging.  For now I took the easy
path out.

Thanks,

  Werner



From dbely@mail.ru  Thu May  2 19:04:02 2002
From: dbely@mail.ru (Dmitry Bely)
Date: Thu May  2 18:04:02 2002
Subject: 1.0.7 under Win32
Message-ID: <r8kufslp.fsf@mail.ru>

I have found some minor problems in GnuPG 1.0.7 that prevent it from
compiling out of the box. I have also fixed the bug in write_server() that
existed from the very beginning (Win32 API function WriteFile() doesn't
work with TCP/IP sockets). Due to that all HTTP-related stuff
("--recv-keys" option etc.) was broken under Win32. Are you interested in
the patch?

Hope to hear from you soon,
Dmitry




From tracy_d@xypro.com  Thu May  2 21:22:02 2002
From: tracy_d@xypro.com (Tracy Ding)
Date: Thu May  2 20:22:02 2002
Subject: A question?
Message-ID: <32E0F1DAB878D511826D00A0CCD7949203EE55@xypro.com>

Hello,
Currently I am working on Gnupg 1.0.6 stuff. 
I installed Gnupg 1.0.6 in my pc.
The command "gpg --print-md SHA1 Keypc"
  the putput is "Keypc: 69BB D5CF 491B C3BB F286  143A 4BC9 F8E8 7DCD"

But in OSS system ( I upload the source codes to Tandem OSS, compiled them )
I got different result.
"
 gpg --print-md SHA1 Keypc
gpg: Please note that you don't have secure memory on this system
gpg: WARNING: program may create a core file!
Keypc: 8653 FDF4 2F70 F2E2 E2D9  AFD4 CB7F 2531 9A85 E088
$ "                          

I tested it for MD5, the result is different too. 
I am totally lost, any help is appreciated.


Regards

Tracy Ding

                        


From wk@gnupg.org  Fri May  3 09:25:02 2002
From: wk@gnupg.org (Werner Koch)
Date: Fri May  3 08:25:02 2002
Subject: A question?
In-Reply-To: <32E0F1DAB878D511826D00A0CCD7949203EE55@xypro.com> (Tracy
 Ding's message of "Thu, 2 May 2002 11:22:16 -0700")
References: <32E0F1DAB878D511826D00A0CCD7949203EE55@xypro.com>
Message-ID: <87elgtiw4c.fsf@alberti.gnupg.de>

On Thu, 2 May 2002 11:22:16 -0700, Tracy Ding said:

> But in OSS system ( I upload the source codes to Tandem OSS, compiled them )
> I got different result.

Did you got any compiler diagnostics when building it?

Am I right that most checks fail if you do a "make check"?



From dshaw@jabberwocky.com  Fri May  3 17:40:02 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Fri May  3 16:40:02 2002
Subject: 15MB files on photo
In-Reply-To: <200205020205.g4225Fi03599@server-1.visp.net>
References: <200205020026.g420Qli28732@server-1.visp.net> <20020502005106.GA25856@akamai.com> <200205020205.g4225Fi03599@server-1.visp.net>
Message-ID: <20020503144106.GD6647@akamai.com>

> >On Wed, May 01, 2002 at 05:27:42PM -0700, Hideki Saito wrote:
> >> I found some problem with photo capability of 1.0.7 on Win32 
> >> compilation.
> >> 
> >> If you try to display graphics, it is actually a bogus JPG file.
> >> 
> >> I have tried with the option i_view32 %i as a photo-viewer argument, 
> >> and it returns "unknown header" error.
> >> 
> >> Then I tried i_view32 %I to see what actual "TEMP.JPG" is like, and it 
> >> turns out be a 12MB - 15MB garbage file.
> >
> >Hmm.  Are you using a Mingw32 or Cygwin build?

On Wed, May 01, 2002 at 07:06:11PM -0700, Hideki Saito wrote:
> Mingw32 build it is...

The problem is forward slashes in the photo path.  Before you compile,
you need to change g10defs.h:

Change these:
#define DIRSEP_C '/'
#define DIRSEP_S "/"

To these:
#define DIRSEP_C '\\'
#define DIRSEP_S "\\"

The Win32 internals do allow either / or \, but the photo viewer uses
system(), and that calls command, and command does not allow forward
slashes.

As for the large garbage file in i_view32, I was able to duplicate the
problem here so I see it as well, but I don't know where the garbage
came from.  I suspect that i_view32 gets upset if it gets forward
slashes in a pathname.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From tracy_d@xypro.com  Sat May  4 00:26:01 2002
From: tracy_d@xypro.com (Tracy Ding)
Date: Fri May  3 23:26:01 2002
Subject: Help ...
Message-ID: <32E0F1DAB878D511826D00A0CCD7949203EE5D@xypro.com>

Hello,

I installed gnupg-1.0.7 into a linux machine. 
It is i486 machine. 
I got a probelm when generating a key pair.

"
Not enough random bytes available.  Please do some other work to give
the OS a chance to collect more entropy! (Need 300 more bytes)     
"
The program stuck there waiting for more bytes.
Any help is appreciated.


Thanks

Tracy Ding


From ajs@ajs.com  Sat May  4 00:56:01 2002
From: ajs@ajs.com (Aaron Sherman)
Date: Fri May  3 23:56:01 2002
Subject: Help ...
In-Reply-To: <32E0F1DAB878D511826D00A0CCD7949203EE5D@xypro.com>
References: <32E0F1DAB878D511826D00A0CCD7949203EE5D@xypro.com>
Message-ID: <1020463004.22284.38.camel@pps>

On Fri, 2002-05-03 at 17:26, Tracy Ding wrote:

> I installed gnupg-1.0.7 into a linux machine. 
> It is i486 machine. 
> I got a probelm when generating a key pair.
> 
> "
> Not enough random bytes available.  Please do some other work to give
> the OS a chance to collect more entropy! (Need 300 more bytes)     
> "
> The program stuck there waiting for more bytes.
> Any help is appreciated.

As the message suggests, you should do more work and let the OS collect
more random bytes. Go! Do work! ;-)




From mutz@kde.org  Sat May  4 01:07:02 2002
From: mutz@kde.org (Marc Mutz)
Date: Sat May  4 00:07:02 2002
Subject: Help ...
In-Reply-To: <32E0F1DAB878D511826D00A0CCD7949203EE5D@xypro.com>
References: <32E0F1DAB878D511826D00A0CCD7949203EE5D@xypro.com>
Message-ID: <200205040007.16685@sendmail.mutz.com>

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

[ reordering lines of original post ]

On Friday 03 May 2002 23:26, Tracy Ding wrote:
<snip>
> The program stuck there waiting for more bytes: <snip>
> Not enough random bytes available.  Please do some other work to give
> the OS a chance to collect more entropy! (Need 300 more bytes)
<snip>

Sorry, you _can_ read, can you? :-(
You can: start bonnie in the background, hit the keyboard monkey-style, move 
the mouse wildly (maybe dragging a window around), or all at once... :-o

Marc

- -- 
Marc Mutz <mutz@kde.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE80woT3oWD+L2/6DgRAgu4AKCCKdzJ2nXvolRZm98mjNNwek1VjACff0Uy
pNJ03crlAlHhb412P6omRw4=
=axlJ
-----END PGP SIGNATURE-----



From dmitri@users.sourceforge.net  Sat May  4 01:29:02 2002
From: dmitri@users.sourceforge.net (Dmitri)
Date: Sat May  4 00:29:02 2002
Subject: Help ...
In-Reply-To: <200205040007.16685@sendmail.mutz.com>
References: <32E0F1DAB878D511826D00A0CCD7949203EE5D@xypro.com>
 <200205040007.16685@sendmail.mutz.com>
Message-ID: <1020464977.1668.228.camel@usb.networkfab.com>

--=-rwHiFvOaMeYb2BeHJUTK
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Fri, 2002-05-03 at 15:07, Marc Mutz wrote:

> On Friday 03 May 2002 23:26, Tracy Ding wrote:
> <snip>
> > The program stuck there waiting for more bytes: <snip>
> > Not enough random bytes available.  Please do some other work to give
> > the OS a chance to collect more entropy! (Need 300 more bytes)
> <snip>
>=20
> Sorry, you _can_ read, can you? :-(
> You can: start bonnie in the background, hit the keyboard monkey-style, m=
ove=20
> the mouse wildly (maybe dragging a window around), or all at once... :-o

I believe, the original cry for help was not unfounded. Here is why.

First of all, the message "Not enough random bytes available" may be
perceived by novices as an ERROR. It is phrased this way. Failed. No
luck. Come back in next millennium. Or something like that.

Secondly, the advice "Please do some other work" can be understood as
"give the computer more time, and meanwhile do something different, like
walking the dog..." If the user does that, the dog gets the entropy -
not the computer ;-)

Apparently, in this very case the user left the computer alone for some
time, and then complained that the program does not go anywhere.

This is because only computer geeks would equal "some other work" to
"some other work with this computer". Normal people have other "work" to
do. Naturally, if the computer is just left there then no new entropy
comes in, and nothing ever happens (until updatedb runs at night,
probably).

So messages may need to be softened up to be understood by all the
normal people ;-)

Dmitri


--=-rwHiFvOaMeYb2BeHJUTK
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA80w9RXksyLpO6T4IRAsPsAKCaVlUel2/AiKiLcqjzRgX8iLVSxQCgkZXw
oc6f+yGziDnxLzIz3u0+Ewc=
=kmrA
-----END PGP SIGNATURE-----

--=-rwHiFvOaMeYb2BeHJUTK--



From wk@gnupg.org  Sat May  4 16:31:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Sat May  4 15:31:01 2002
Subject: Help ...
In-Reply-To: <1020464977.1668.228.camel@usb.networkfab.com> (Dmitri's
 message of "03 May 2002 15:29:37 -0700")
References: <32E0F1DAB878D511826D00A0CCD7949203EE5D@xypro.com>
 <200205040007.16685@sendmail.mutz.com>
 <1020464977.1668.228.camel@usb.networkfab.com>
Message-ID: <87n0vgdomh.fsf@alberti.gnupg.de>

On 03 May 2002 15:29:37 -0700, Dmitri  said:

> So messages may need to be softened up to be understood by all the
> normal people ;-)

I agree.  I will reword the messages.

 Werner



From jas@extundo.com  Sat May  4 18:21:02 2002
From: jas@extundo.com (Simon Josefsson)
Date: Sat May  4 17:21:02 2002
Subject: update to gettext 0.11.2?
Message-ID: <iluu1pohr9p.fsf@extundo.com>

What about updating to gettext 0.11.2?  I had difficulties getting the
current gettext in gnupg to work.

I put a patch to do this up at http://josefsson.org/gnupg-gettext.diff
(due to size, ~230KB), altough it seems to remove some comments in
po/*.po so maybe not all of it should be applied.



From wk@gnupg.org  Sat May  4 19:57:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Sat May  4 18:57:01 2002
Subject: update to gettext 0.11.2?
In-Reply-To: <iluu1pohr9p.fsf@extundo.com> (Simon Josefsson's message of
 "Sat, 04 May 2002 17:22:26 +0200")
References: <iluu1pohr9p.fsf@extundo.com>
Message-ID: <871ycrdf4e.fsf@alberti.gnupg.de>

On Sat, 04 May 2002 17:22:26 +0200, Simon Josefsson said:

> What about updating to gettext 0.11.2?  I had difficulties getting the
> current gettext in gnupg to work.

As soon as it appears in Woody.

  Werner



From jgre@tzi.de  Mon May  6 12:12:02 2002
From: jgre@tzi.de (Janico Greifenberg)
Date: Mon May  6 11:12:02 2002
Subject: Importing and using keys with GPGME
Message-ID: <20020506062658.GA478@tzi.de>

Hello,
when I import a public key with gpgme_op_import() the key appears in my keyring
but when I want to use it for encryption (with gpgme_op_encrypt_sign()) I get
a GPGME_No_Data Error. When I use this key with gpg in the command line, I need
to confirm that I want to use this untrusted key. Is to possible to do
something like that with gpgme (I mean overriding the error) or do I have to
sign the key and how can I do this with gpgme?

Thanks in advance
       Janico
-- 
Warning! Taking anyone (especially yourself) too serious will be harmful


From hideki@allcity.net  Mon May  6 14:17:02 2002
From: hideki@allcity.net (Hideki Saito)
Date: Mon May  6 13:17:02 2002
Subject: 15MB files on photo
In-Reply-To: <20020503144106.GD6647@akamai.com>
References: <200205020026.g420Qli28732@server-1.visp.net>
 <20020502005106.GA25856@akamai.com>
 <200205020205.g4225Fi03599@server-1.visp.net>
 <20020503144106.GD6647@akamai.com>
Message-ID: <200205061118.g46BIYg20489@sasami.anime.net>

Yes, this worked.
Thanks.

Here are files, in case anyones are interested.
http://hp.vector.co.jp/authors/VA019487/gnupg-w32-1.0.7-hs.zip
http://hp.vector.co.jp/authors/VA019487/hs-gnupg-w32-1.0.7-hs.zip.sig


>
>On Wed, May 01, 2002 at 07:06:11PM -0700, Hideki Saito wrote:
>> Mingw32 build it is...
>
>The problem is forward slashes in the photo path.  Before you compile,
>you need to change g10defs.h:
>
>Change these:
>#define DIRSEP_C '/'
>#define DIRSEP_S "/"
>
>To these:
>#define DIRSEP_C '\\'
>#define DIRSEP_S "\\"
>
>The Win32 internals do allow either / or \, but the photo viewer uses
>system(), and that calls command, and command does not allow forward
>slashes.
>
>As for the large garbage file in i_view32, I was able to duplicate the
>problem here so I see it as well, but I don't know where the garbage
>came from.  I suspect that i_view32 gets upset if it gets forward
>slashes in a pathname.
>


-- 
Hideki Saito mailto:hideki@allcity.net


From wk@gnupg.org  Mon May  6 14:55:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Mon May  6 13:55:01 2002
Subject: Importing and using keys with GPGME
In-Reply-To: <20020506062658.GA478@tzi.de> (jgre@tzi.de's message of "Mon, 6
 May 2002 08:26:59 +0200")
References: <20020506062658.GA478@tzi.de>
Message-ID: <87lmax1oac.fsf@alberti.gnupg.de>

On Mon, 6 May 2002 08:26:59 +0200, Janico Greifenberg said:

> when I import a public key with gpgme_op_import() the key appears in my keyring
> but when I want to use it for encryption (with gpgme_op_encrypt_sign()) I get
> a GPGME_No_Data Error. When I use this key with gpg in the command line, I need

In general it does not make sense to encrypt something to someone whom
you don't trust.  So the best way is to locally sign the sign.

Using

  gpgme_recipients_add_name_with_validity (rset, name, GPGME_VALIDITY_FULL);

you should be able to overide it.




From Weimer@CERT.Uni-Stuttgart.DE  Tue May  7 10:43:02 2002
From: Weimer@CERT.Uni-Stuttgart.DE (Florian Weimer)
Date: Tue May  7 09:43:02 2002
Subject: Expiration and V3/V4 self signatures
Message-ID: <87helk8ksv.fsf@CERT.Uni-Stuttgart.DE>

* packet.h, parse-packet.c (parse_key), getkey.c (merge_keys_and_selfsig,
merge_selfsigs_main): a v3 key with a v4 self-sig must never let the v4
self-sig express a key expiration time that extends beyond the original v3
expiration time.

* keyedit.c (sign_uids): If --expert it set, allow re-signing a uid to
promote a v3 self-sig to a v4 one.  This essentially deletes the old v3
self-sig and replaces it with a v4 one.

Don't these two features conflict with each other?

-- 
Florian Weimer 	                  Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898


From wk@gnupg.org  Tue May  7 11:07:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Tue May  7 10:07:01 2002
Subject: Expiration and V3/V4 self signatures
In-Reply-To: <87helk8ksv.fsf@CERT.Uni-Stuttgart.DE> (Florian Weimer's
 message of "Tue, 07 May 2002 09:43:44 +0200")
References: <87helk8ksv.fsf@CERT.Uni-Stuttgart.DE>
Message-ID: <877kmgwfb8.fsf@alberti.gnupg.de>

On Tue, 07 May 2002 09:43:44 +0200, Florian Weimer said:

> * packet.h, parse-packet.c (parse_key), getkey.c (merge_keys_and_selfsig,
> merge_selfsigs_main): a v3 key with a v4 self-sig must never let the v4
> self-sig express a key expiration time that extends beyond the original v3
> expiration time.

> * keyedit.c (sign_uids): If --expert it set, allow re-signing a uid to
> promote a v3 self-sig to a v4 one.  This essentially deletes the old v3
> self-sig and replaces it with a v4 one.

> Don't these two features conflict with each other?

No.  Why should they?

As you know the expiration time in a v3 key is stored unchangeable
with the key whereas it is store in a self-signature with a v4 key.
The first change makes sure that the expiration time from a v4
signature on a v3 key can not be used to extend the expiration time
over the one set with the v3 key and the latter change simply promotes
a v3 self-signature to a v4 self-signature with an expiration time
(set to the one from the v3 key).

  Werner



From p_perego@modiano.com  Tue May  7 13:37:02 2002
From: p_perego@modiano.com (Paolo Perego)
Date: Tue May  7 12:37:02 2002
Subject: GPGME: verify signature question
Message-ID: <200205071237.54986.p_perego@modiano.com>

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

Hi ,guys. I'm not subscribed to thie ML so please cc me. I'm using gpg 1.=
07=20
and gpgme 0.3.6 on my suse linux box. I'm developing a tool that parse a=20
mailbox looking for mails and, if thie mails are signed, try to verify th=
e=20
signature ( not detached ). The messages are in rfc2015 form, so the cont=
ent =20
type is "multipart/signed" and the signed data is divided from the signat=
ure=20
by the boundary.

I wrote the code to verify the signature but I think I did not pass the r=
ight=20
body and signature content to gpgme_op_verify. Can you please gave me som=
e=20
links, examples ( not mail usent agent sources, please. ) about how verif=
y a=20
signed message vailidity.

Thanks a lot
Paolo
- --=20
$>cd /pub
$>more beer

(0>
//\  Perego Paolo <p_perego@modiano.com> - www.sikurezza.org/angel
V_/_ 'It's seems the hardest life I've never known'
I'm Linux drow 2.4.17-4GB - SuSE Linux 7.3 (i386) powered.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE8166Ae2SOXFIw7OcRAlFvAJ46Eu6wq4UrsiisYz7WE1xcGIAJYwCgmsWX
r2/3n7ue4jzOlCyISocqUQE=3D
=3DbzUP
-----END PGP SIGNATURE-----



From wk@gnupg.org  Tue May  7 14:13:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Tue May  7 13:13:01 2002
Subject: GPGME: verify signature question
In-Reply-To: <200205071237.54986.p_perego@modiano.com> (Paolo Perego's
 message of "Tue, 7 May 2002 12:37:45 +0200")
References: <200205071237.54986.p_perego@modiano.com>
Message-ID: <87k7qgus5c.fsf@alberti.gnupg.de>

On Tue, 7 May 2002 12:37:45 +0200, Paolo Perego said:

> signature ( not detached ). The messages are in rfc2015 form, so the content  
> type is "multipart/signed" and the signed data is divided from the signature 

BTW, rfc3156 is the successor or 2015, only minor changes but you
should use this as a reference,

> body and signature content to gpgme_op_verify. Can you please gave me some 
> links, examples ( not mail usent agent sources, please. ) about how verify a 

Be sure to include the header lines of the part and don't include the
CR/LF right before the terminating boundary.

What's wrong with looking at other sources?

  Werner



From p_perego@modiano.com  Tue May  7 15:18:02 2002
From: p_perego@modiano.com (Paolo Perego)
Date: Tue May  7 14:18:02 2002
Subject: GPGME: verify signature question
In-Reply-To: <87k7qgus5c.fsf@alberti.gnupg.de>
References: <200205071237.54986.p_perego@modiano.com> <87k7qgus5c.fsf@alberti.gnupg.de>
Message-ID: <200205071418.58964.p_perego@modiano.com>

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

Alle 13:14, marted=EC 7 maggio 2002, Werner Koch ha scritto:

> BTW, rfc3156 is the successor or 2015, only minor changes but you
> should use this as a reference,
Sure. I omissed that I downloaded also the new rfc. :)

> Be sure to include the header lines of the part and don't include the
> CR/LF right before the terminating boundary.
Is the signature calculated from the first "--boundary" or also the mail=20
header are hashed by gpg?

> What's wrong with looking at other sources?
Nothing at all.  I was checking out mutt and sylpheed-claws sources. But =
they=20
parse mime headers in various point of the code and I was not able to gue=
ss=20
what exactly they pass to gpgme_op_verify().

Thank again. I think this afternoon will be plenty of signature checking=20
attempts :)
Paolo
- --=20
$>cd /pub
$>more beer

(0>
//\  Perego Paolo <p_perego@modiano.com> - www.sikurezza.org/angel
V_/_ 'It's seems the hardest life I've never known'
I'm Linux drow 2.4.17-4GB - SuSE Linux 7.3 (i386) powered.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE818Yxe2SOXFIw7OcRAm2fAJ96qivoJ1SUH8JxGDjUkyguwvnK3wCgh96n
4ivWYObqgTQF7ikNsJTAAUs=3D
=3Ddhyt
-----END PGP SIGNATURE-----



From wk@gnupg.org  Tue May  7 15:37:02 2002
From: wk@gnupg.org (Werner Koch)
Date: Tue May  7 14:37:02 2002
Subject: GPGME: verify signature question
In-Reply-To: <200205071418.58964.p_perego@modiano.com> (Paolo Perego's
 message of "Tue, 7 May 2002 14:18:50 +0200")
References: <200205071237.54986.p_perego@modiano.com>
 <87k7qgus5c.fsf@alberti.gnupg.de>
 <200205071418.58964.p_perego@modiano.com>
Message-ID: <87g014uo6m.fsf@alberti.gnupg.de>

On Tue, 7 May 2002 14:18:50 +0200, Paolo Perego said:

> Is the signature calculated from the first "--boundary" or also the mail 
> header are hashed by gpg?

  Subject: a signed message
  
  -=-=-=
  Content-Type: whatever/foo

  This is the content which might be encoded in any way as
  specified by a encoding header.  For signature verification there 
  is nothing we have to care about.

  -=-=-=
  Content-Type: application/pgp-signature

What you hash is this string in C notation:

  "Content-Type: whatever/foo\r\n\r\nThis is the content which might"
  " be encoded in any way as\r\nspecified by a encoding header.  For"
  "  signature verification there\r\nis nothing we have to care about.\r\n"

And you might want to keep in mind that such a PGP/MIEM object may be
embedded in other MIME objects or the whatever/foo conetnt type might
be a multipart/mixed or whatever you can imagine.

gpg --debug 512

is of great help here because it creates files dbgmd*.<somecode> with
the actually hashed content.


  Werner



From p_perego@modiano.com  Tue May  7 15:42:01 2002
From: p_perego@modiano.com (Paolo Perego)
Date: Tue May  7 14:42:01 2002
Subject: GPGME: verify signature question
In-Reply-To: <87g014uo6m.fsf@alberti.gnupg.de>
References: <200205071237.54986.p_perego@modiano.com> <200205071418.58964.p_perego@modiano.com> <87g014uo6m.fsf@alberti.gnupg.de>
Message-ID: <200205071443.13524.p_perego@modiano.com>

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

Alle 14:39, marted=EC 7 maggio 2002, Werner Koch ha scritto:
[snip]

> What you hash is this string in C notation:
>
>   "Content-Type: whatever/foo\r\n\r\nThis is the content which might"
>   " be encoded in any way as\r\nspecified by a encoding header.  For"
>   "  signature verification there\r\nis nothing we have to care about.\=
r\n"
Perfect. At the same time I guess I must pass the string "-----BEGIN PGP=20
SIGNATURE-----.... -----END PGP SIGNATURE-----" as signature in=20
gpgme_op_verify(). Am I right am not I?

> And you might want to keep in mind that such a PGP/MIEM object may be
> embedded in other MIME objects or the whatever/foo conetnt type might
> be a multipart/mixed or whatever you can imagine.
Sure, but my application is really simple and it needs just to validate t=
he=20
sender identity! :)

Thanks for the help guys [ and excuse me for my poor english :P ]
Paolo
- --=20
$>cd /pub
$>more beer

(0>
//\  Perego Paolo <p_perego@modiano.com> - www.sikurezza.org/angel
V_/_ 'It's seems the hardest life I've never known'
I'm Linux drow 2.4.17-4GB - SuSE Linux 7.3 (i386) powered.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE818vge2SOXFIw7OcRAszgAJ9KpVTx0wzW/hFS8H3i//HQBzZJ3ACeImPY
VZM84JDhKchJecuG4yTz/eI=3D
=3DwMhM
-----END PGP SIGNATURE-----



From wk@gnupg.org  Tue May  7 15:57:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Tue May  7 14:57:01 2002
Subject: GPGME: verify signature question
In-Reply-To: <200205071443.13524.p_perego@modiano.com> (Paolo Perego's
 message of "Tue, 7 May 2002 14:43:07 +0200")
References: <200205071237.54986.p_perego@modiano.com>
 <200205071418.58964.p_perego@modiano.com>
 <87g014uo6m.fsf@alberti.gnupg.de>
 <200205071443.13524.p_perego@modiano.com>
Message-ID: <87u1pkt8oc.fsf@alberti.gnupg.de>

On Tue, 7 May 2002 14:43:07 +0200, Paolo Perego said:

> Perfect. At the same time I guess I must pass the string "-----BEGIN PGP 
> SIGNATURE-----.... -----END PGP SIGNATURE-----" as signature in 
> gpgme_op_verify(). Am I right am not I?

Yes.  

  Werner



From redbird@rbisland.cx  Tue May  7 18:58:02 2002
From: redbird@rbisland.cx (Gordon Worley)
Date: Tue May  7 17:58:02 2002
Subject: GnuPG 1.0.7 configure with dynload modules
Message-ID: <4B21FE3D-61D3-11D6-B33A-000A27B4DEFC@rbisland.cx>

Okay, I'm having a bit of trouble here and hopefully someone has some 
insights.

I'm trying to patch GnuPG 1.0.7 to run on Darwin (Mac OS X).  Everything 
is working except for one thing.  I have patched cipher/dynload.c to 
work as we did in 1.0.6 and it compiles fine and looks like it will 
work.  The problem comes when make tries to make the checks.  The 
problem is that tiger has not been compiled earlier.  Yet, when 
configure was run, it said that it would:

                 Configured for: Darwin (powerpc-apple-darwin5.4)
     Dynamically linked modules: rndunix rndegd tiger
      Statically linked modules: rndlinux sha1 rmd160 md5

So, anyone have any ideas on how to get tiger (and rndunix and rndegd; I 
checked and they haven't been compiled either) to compile short of doing 
it by hand?

Thanks.

--
Gordon Worley                     `When I use a word,' Humpty Dumpty
http://www.rbisland.cx/            said, `it means just what I choose
redbird@rbisland.cx                it to mean--neither more nor less.'
PGP:  0xBBD3B003                                  --Lewis Carroll



From bgallia@orion.it.luc.edu  Wed May  8 00:34:03 2002
From: bgallia@orion.it.luc.edu (B. Galliart)
Date: Tue May  7 23:34:03 2002
Subject: AIX malloc(0) is null
Message-ID: <Pine.A41.4.40.0205071551390.12276-100000@orion.it.luc.edu>

How many people believe in testing if their computer is out of memory by
requesting the allocation of *0* bytes?

So, what is wrong with the following picture:
  gpg: out of  memory while allocating 0 bytes

GNUPG v1.07 *REQUIRES* the use of m-guard on AIX to ensure that GPG never
attempts malloc(0) (m-gaurd always allocates at least 5 bytes).  There is
just something brain dead about requesting *nothing* and exiting if you do
not get *something*.  Please update memory.c to skip malloc if 0 bytes are
requested or update the configure script to automatically include m-gaurd
if malloc(0) returns null.

Thanks



From dshaw@jabberwocky.com  Wed May  8 00:46:02 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Tue May  7 23:46:02 2002
Subject: AIX malloc(0) is null
In-Reply-To: <Pine.A41.4.40.0205071551390.12276-100000@orion.it.luc.edu>
References: <Pine.A41.4.40.0205071551390.12276-100000@orion.it.luc.edu>
Message-ID: <20020507214715.GB3487@akamai.com>

On Tue, May 07, 2002 at 04:35:11PM -0500, B. Galliart wrote:
> How many people believe in testing if their computer is out of memory by
> requesting the allocation of *0* bytes?
> 
> So, what is wrong with the following picture:
>   gpg: out of  memory while allocating 0 bytes

Fixed in 1.0.8.  See
  http://lists.gnupg.org/pipermail/gnupg-users/2002-May/013022.html
for temporary patch.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From bgallia@orion.it.luc.edu  Wed May  8 08:34:01 2002
From: bgallia@orion.it.luc.edu (B. Galliart)
Date: Wed May  8 07:34:01 2002
Subject: AIX malloc(0) is null
In-Reply-To: <20020507214715.GB3487@akamai.com>
Message-ID: <Pine.A41.4.40.0205080024590.12276-100000@orion.it.luc.edu>

Wow, fixed 6.5 hours before I post.  That is increditable timing.

You wouldn't have a trick up your sleeve for the problem below.  I can
recreate the issue with both gcc v2.9 and gcc v3.04 but IBM's v3.6.4 C
compiler goes through without a problem.  Is this a GNUPG or GCC issue?

mpih-div.c: In function `mpihelp_mod_1':
mpih-div.c:86: warning: implicit declaration of function `__udiv_w_sdiv'
mpih-div.c:100: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:100: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:106: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:106: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:136: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:136: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c: In function `mpihelp_divrem':
mpih-div.c:290: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:354: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c: In function `mpihelp_divmod_1':
mpih-div.c:447: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:447: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:453: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:453: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:482: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:482: Can't find a register in class `MQ_REGS' while reloading `asm'.




From wk@gnupg.org  Wed May  8 11:31:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Wed May  8 10:31:01 2002
Subject: AIX malloc(0) is null
In-Reply-To: <Pine.A41.4.40.0205080024590.12276-100000@orion.it.luc.edu> ("B.
 Galliart"'s message of "Wed, 8 May 2002 00:35:29 -0500 (CDT)")
References: <Pine.A41.4.40.0205080024590.12276-100000@orion.it.luc.edu>
Message-ID: <87znzbjc8h.fsf@alberti.gnupg.de>

On Wed, 8 May 2002 00:35:29 -0500 (CDT), B Galliart said:

> mpih-div.c:86: warning: implicit declaration of function `__udiv_w_sdiv'
> mpih-div.c:100: Can't find a register in class `MQ_REGS' while reloading `asm'.

This is more a problem of using GCC with the native as(1)  I have
no instant solution for this.  Compiling GMP should yield the same
problems.

   Werner



From order@elite-code-runner.com  Wed May  8 21:14:02 2002
From: order@elite-code-runner.com (Bolder Computer Solutions)
Date: Wed May  8 20:14:02 2002
Subject: Cover Your Tracks
Message-ID: 47494851946830.70799.qmail@elite-code-runner.com

                                             Cover your Tracks

We at Bolder Computer Solutions have been looking for a software developer that has the state of the art software programs, at the right price, which can protect all of us on the Internet. We found Elite Code Runner!!! Elite Code Runner has products designed at blocking Hackers from your computer, software designed to delete all traces of your surfing and also your document and history files, and software to let you know where your children, your employees, your friends, and anyone that uses your computer, have gone when they are using your computer. 

                                                 Trace Breaker

Trace Breaker is a software program that is designed to erase all traces of your travels around the Internet. We have also added the ability to this software programs to clear all your history files from the internet, clear your cookies, delete the typed URL's, Windows Recent files, Office Recent files, and your Document files. These are all user selectable allowing you to keep the files you choose.

Trace Breaker $ 49.95

Name :______________________________________________________________
Address :____________________________________________________________
City State Zip______________________________________  _____   ___________
Amount Enclosed :_$______________

                      We except company checks or Money orders.
***** Add $6.95 shipping and Handling for each package you order. *****
***** Make all checks payable to Bolder Computer Solutions.            *****
Mail to:

Bolder Computer Solutions
27 Shethar Street
P.O. Box 25
Hammondsport, NY 14840-0025

Shipping as soon as checks clear. Immediately with Money orders.

***** Print this ad, circle selections and mail with payment                 *****




From andreas@xss.co.at  Thu May  9 14:34:02 2002
From: andreas@xss.co.at (Andreas Haumer)
Date: Thu May  9 13:34:02 2002
Subject: gnupg-1.0.7: missing dependencies in checks/Makefile
Message-ID: <3CDA5EDF.990C18F8@xss.co.at>

Hi!

I found a small problem in the checks/Makefile for gnupg-1.0.7

Some of the checks there need a script "gpg_dearmor", which
itself is created by make on the fly. But this dependency
is not explicitly listed in the Makefile, so a "make -j2"
(or any build with more than one job running simultaneously) 
fails on our Dual CPU development server.

I'd suggest to add "gpg_dearmor" to the dependency section of
all make targets where this script is used (just like it 
already is for target "./pubring.gpg")

Regards,

- andreas

-- 
Andreas Haumer                     | mailto:andreas@xss.co.at
*x Software + Systeme              | http://www.xss.co.at/
Karmarschgasse 51/2/20             | Tel: +43-1-6060114-0
A-1100 Vienna, Austria             | Fax: +43-1-6060114-71


From mwy-gpg41@the-youngs.org  Thu May  9 21:52:01 2002
From: mwy-gpg41@the-youngs.org (Michael Young)
Date: Thu May  9 20:52:01 2002
Subject: Notation data format: "user" name space rejected
References: <E175fVC-0001KU-00@trithemius.gnupg.org>
Message-ID: <007201c1f78a$9a6d81e0$ebc42609@transarc.ibm.com>

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

The latest draft of RFC2440 describes two name spaces for notation
data, one of which GnuPG rejects as invalid.  Specifically, the
RFC describes the "user" name space:

>    Names in the user name space consist of a UTF-8 string tag followed
>    by "@" followed by a DNS domain name. Note that the tag MUST NOT
>    contain an "@" character. For example, the "sample" tag used by
>    Example Corporation could be "sample@example.com".

When I try to generate such a notation, I get this error:
    log_error(_("a notation name must have only letters, "
  "digits, dots or underscores and end with an '='\n") );

(My test used 1.0.6, but it doesn't appear to have changed in the
latest source.)

At first glance, it would appear that adding the "@" character
to the check on the line before the log_error() would be sufficient.
But neither the "tag" nor the DNS domain name should need to meet
these tight restrictions (alphanumeric/dot/underscore).  So, I
would suggest looking for a "@" first, at which point almost
anything goes.  Does that seem reasonable?

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQA/AwUBPNrFJFMkvpTT8vCGEQKhpgCg2dVswZWsaKwSZGkvQh7Cg3UYDjoAoMCz
tgIKnXkM0nKFPmSe2YWZRWXQ
=U8xW
-----END PGP SIGNATURE-----




From Dr. Carter" <Have_Open_Mind@yahoo.com  Thu May  9 22:02:01 2002
From: Dr. Carter" <Have_Open_Mind@yahoo.com (Dr. Carter)
Date: Thu May  9 21:02:01 2002
Subject: To: g10 as a Good Person - Conduct Education in the 21st Century
Message-ID: <4140-2200254919350630@oemcomputer>

Dear g10:

You may ask yourself
      >    How to make people respect you
      >    How to win friends
      >    How to let your conduct help your health, work, job, career, re=
lationships, spirit,  mind, well-being, =2E=2E=2E
      >    How to make your life smoother and happier=20
      >    How to do whatever you like without being unpleasant to other p=
eople=20
      >    How to develop good conduct in your children or students=20
      >    How to make the world peaceful and better

You can find all the answers to these questions, and much more, in this gr=
eat handbook:
=20
"Complete Conduct Principles for the 21st Century" by Dr=2E John Newton=20=


It is the best educational GIFT idea for children, friends, relatives, cla=
ssmates, students, parents, teachers, other educators, =2E=2E=2E, particul=
arly at this special time=2E=20

BENEFITS to each individual reader: Many! -- such as for health, work, job=
, career, self-improvement, education, relationships, spirit, mind, well-b=
eing, and much more -- almost all the areas that are important to you in t=
he 21st century=2E People around you will benefit, too=2E (Please see the =
PREFACE of the book for details=2E)=20

EVERYONE may find this handbook useful and helpful, regardless of age (fro=
m children to oldsters), occupation, rank, status, gender, religious belie=
fs, nationality, country, or region=2E=20

If you are a parent or a teacher, you can learn how to develop good conduc=
t in your children or students from this handbook=2E Please advise your ch=
ildren or students to read the book=2E It will result in great benefits fo=
r both you and them=2E=20

(Note: If you are interested in the issue of School Violence, Youth Proble=
ms, Violence Prevention, or Conduct Education in the 21st Century, please =
see the APPENDIX below=2E) =20

This book is a must for EVERYONE to be better prepared for personal conduc=
t for the 21st century=2E=20

The book's content is obvious from its title=2E The complete useful conduc=
t principles cover not only what we should do, but also what we should not=
 do -- especially those faults people make often and easily=2E=20

This timely, unique, and very important handbook is designed to suit most =
people, and is self-contained and user-friendly=2E=20

This book is significantly different and better than competitive works=2E

Some of its innovative contents may help solve problems that Western cultu=
re cannot=2E=20

The book's merit and importance have been recognized and praised by many e=
xperts, elected public officials, and world leaders=2E

How to make the world peaceful and better ---
You can find the solution in the book=2E
Let's work together to make the world peaceful and better!=20

The author, John Newton, holds a Ph=2ED=2E from MIT, and does researches a=
t Harvard=2E His long-term research on "The personal conduct in the human =
society of the 21st century" resulted in this book=2E It is published by N=
icer Century World Organization, headquartered beside Harvard University a=
nd MIT, two leading institutes of new knowledge and literature=2E

The book is available in two types of binding: Hardcover (ISBN 0967370574;=
 case bound, Smyth sewn; with dust jacket) and Paperback (ISBN 0967370582;=
 perfect bound)=2E Both editions are unabridged, and are printed on 60 lb,=
 natural, acid-free, excellent and healthful paper=2E You can get the book=
 from many fine on-line bookstores and traditional bookstores=2E For your =
convenience, I herewith provide you with a link directly to the book page =
in the shopping directory of Yahoo!, the world's No=2E 1 Internet director=
y:

http://shopping=2Eyahoo=2Ecom/shop?d=3Db&id=3D3680641&clink=3Ddmpr-hm/rp&c=
f=3Dsetup

Some bookstores there offer great discounts (for a limited time)=2E Note t=
hat some of the bookstores may disappear there if out-of-stock=2E In that =
case, you may want to go to another bookstore=2E Of course, you may freely=
 go to other bookstores at any time, even if they are not listed in Yahoo!=
=2E

Please forward this e-mail to people you know -- children, friends, relati=
ves, classmates, students, parents, teachers, other educators, =2E=2E=2E, =
because they can benefit from it, too=2E This can be a wonderful kindness =
you provide to them!

g10, best wishes to you!


Sincerely yours,

Tom Carter, Ph=2ED=2E
President, Nicer Century World Organization
Massachusetts, USA

(Nicer Century World Organization is an educational, non-profit, non-parti=
san organization; it endeavors to make the 21st century nicer than ever be=
fore=2E To accomplish its mission, Nicer Century World Organization is pro=
ud to introduce this book=2E)=20

-----------------------------------------------------------

APPENDIX: School Violence, Youth Problems, Violence Prevention, and Conduc=
t Education in the 21st Century

In recent years school violence has made many pieces of nation-shaking hig=
hlighted headline news, which have astounded the Americans=2E It may happe=
n at any school, at any time, and by students of any age=2E Some experts b=
elieve this is the most important national crisis the U=2ES=2E is facing=2E=
=20

"In the 21st century the problem will happen not only continuously in the =
U=2ES=2E but also in lots of other countries all over the world, if we do =
not act=2E" said Dr=2E John Newton in the late 20th century=2E Recent trag=
edies have proved this warning prediction=2E

"The most effective and proper way to solve the problem is appropriate con=
duct education=2E" said Dr=2E Newton=2E

"The significance of the problem" is much more important than "the number =
of people killed in schools"=2E=20

In addition to shooting and killing, other kinds of school violence, such =
as rape, sexual assault, aggravated assault, robbery, bullying, mugging, f=
ighting, theft, harassment, =2E=2E=2E, and other youth problems, like suic=
ide, suicide attempt, suicide inclination, pessimism, sense of inferiority=
, lose of  self-control, relationship problems, emotion problems, drug abu=
se, discrimination, =2E=2E=2E, cannot be ignored, either=2E

Some measures may handle a few "symptoms" temporarily and partially but ar=
e not solutions for education, particularly in view of our responsibilitie=
s for the whole society=2E

Now an effective, proper, comprehensive, deep-rooted and permanent solutio=
n is needed!

The book, "Complete Conduct Principles for the 21st Century" by Dr=2E John=
 Newton, is regarded as "the very one that can effectively help solve the =
problem of school violence in a right way" by some experts in education, i=
ncluding Dr=2E Steve White, who pointed out clearly: "If students, teacher=
s and parents can learn the conduct principles in this book well, then tha=
t 'unsolvable' problem will be solved=2E  It is not difficult at all to le=
arn them, because the book is a simple, easy, clear, convenient and self-c=
ontained handbook, well designed to suit most people=2E" The book was also=
 praised as "a compendium of concisely expressed, practical, informative, =
pertinent, workable advice" by Michael J=2E Carson, a professional book re=
viewer=2E

"Unlike most books of this subject, it is NOT a religious book, nor is a c=
ollection of old conduct rules=2E"=20

As analyzed in the Preface of the book, "from now on learning good conduct=
 should be placed as No=2E 1 in education=2E"=20

The book's merit and importance have been recognized and praised by many e=
ducation experts, elected public officials, and world leaders=2E Some educ=
ational units, ranging from the level of nation or state to individual sch=
ool or university, have ordered the book either as textbook/reference book=
 or as an active action to prevent school violence, to improve education a=
nd to benefit students, teachers & parents=2E=20

"The book will also be effective for violence prevention for the whole soc=
iety=2E"

Hence, to prevent school violence and other violence, to improve education=
, and to benefit students, teachers, parents, & the whole society, I earne=
stly request you to inform the students, teachers, parents, school library=
 and other relevant people you know of the availability of the book=2E

A reasonable method you may consider choosing is to simply  forward this l=
etter to them=2E

Although it will be helpful and appreciated, it is NOT necessary that you =
state any endorsement or the like=2E

Your efforts to prevent school violence and other violence, to improve edu=
cation, and to benefit students, teachers, parents, & the whole society wi=
ll be highly appreciated=2E




From dshaw@jabberwocky.com  Thu May  9 22:16:01 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Thu May  9 21:16:01 2002
Subject: Notation data format: "user" name space rejected
In-Reply-To: <007201c1f78a$9a6d81e0$ebc42609@transarc.ibm.com>
References: <E175fVC-0001KU-00@trithemius.gnupg.org> <007201c1f78a$9a6d81e0$ebc42609@transarc.ibm.com>
Message-ID: <20020509191712.GC3323@akamai.com>

On Thu, May 09, 2002 at 02:52:00PM -0400, Michael Young wrote:

> The latest draft of RFC2440 describes two name spaces for notation
> data, one of which GnuPG rejects as invalid.  Specifically, the
> RFC describes the "user" name space:
> 
> >    Names in the user name space consist of a UTF-8 string tag followed
> >    by "@" followed by a DNS domain name. Note that the tag MUST NOT
> >    contain an "@" character. For example, the "sample" tag used by
> >    Example Corporation could be "sample@example.com".
> 
> When I try to generate such a notation, I get this error:
>     log_error(_("a notation name must have only letters, "
>   "digits, dots or underscores and end with an '='\n") );
> 
> (My test used 1.0.6, but it doesn't appear to have changed in the
> latest source.)

It hasn't.  The problem here is that between 2440 and one of the
succeeding 2440bis drafts the spec here changed slightly, so there is
a bit of a 'moving target' effect.  I'll look into it.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From karlsson@hal-pc.org  Thu May  9 22:39:02 2002
From: karlsson@hal-pc.org (Brian M. Carlson)
Date: Thu May  9 21:39:02 2002
Subject: force-v4-certs and digest-algo
Message-ID: <20020509194024.GB6949@stonewall>

--DKU6Jbt7q3WqK7+M
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

I have set force-v4-certs in my options file. I also have digest-algo RIPEM=
D160
set. Yet, my signatures still are made with SHA1, which I deprecate strongl=
y.
If I have a preference on my key, I'd prefer that gpg choose that, unless
I choose a digest-algo option, in which case gpg uses that. gpg has done
neither.

Is that possible without a rewrite of the code?

--=20
Brian M. Carlson
<karlsson@hal-pc.org>
OpenPGP: 0x351336B2DCA1913A

--DKU6Jbt7q3WqK7+M
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Ubi libertas, ibi patria.

iQEVAwUBPNrQqOWR/8lWBVPnAQPyhQf6AwTw3UZm/jq0or8fw45VcIA2BN5czunY
gzKRWn47HW5aRwWNE4x1tOEfhOZbeg7CFxFM4lEKmuCTL8Qu4/+xCk79z9ne58eS
Ke25JxVgpQ6Q046LyBbaPaKtJFaF9U+YqbO4KJZ8E5/LSUCoBmdEgwFgnWyCVizp
yLZEDgA3kdId6BZoZ7OdiM+yKKnIRc1qd9QJ0N2MfpvTwG7f59oNKRTOqWoDR5Am
112UvcYJtYoMjP3/dP3mDUk71qkoExkwbuQbMwQvTYjDNH6jU7U5DKTcikPQSTYR
LlFjeumAVe6janjDnh6vlfy1nAv/Iq6uAADclh7DHVNVGRI1AQshAw==
=ObM8
-----END PGP SIGNATURE-----

--DKU6Jbt7q3WqK7+M--


From dshaw@jabberwocky.com  Thu May  9 22:50:01 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Thu May  9 21:50:01 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <20020509194024.GB6949@stonewall>
References: <20020509194024.GB6949@stonewall>
Message-ID: <20020509195108.GE3323@akamai.com>

On Thu, May 09, 2002 at 07:40:24PM +0000, Brian M. Carlson wrote:

> I have set force-v4-certs in my options file. I also have
> digest-algo RIPEMD160 set. Yet, my signatures still are made with
> SHA1, which I deprecate strongly.  If I have a preference on my key,
> I'd prefer that gpg choose that, unless I choose a digest-algo
> option, in which case gpg uses that. gpg has done neither.

Let me make sure I understand what you are doing.  You want your key
signatures - not data signatures - to use RIPEMD160 and not SHA1?

--digest-algo only applies to data signatures.

Why do you strongly deprecate SHA1?

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From mutz@kde.org  Thu May  9 23:36:05 2002
From: mutz@kde.org (Marc Mutz)
Date: Thu May  9 22:36:05 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <20020509194024.GB6949@stonewall>
References: <20020509194024.GB6949@stonewall>
Message-ID: <200205092236.31196@sendmail.mutz.com>

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 09 May 2002 21:40, Brian M. Carlson wrote:
> I have set force-v4-certs in my options file. I also have digest-algo
> RIPEMD160 set. Yet, my signatures still are made with SHA1,
<snip>

Well, according to the micalg parameter of your mp/signed, your last messag=
e=20
_was_ RIMEMD160.

Marc

=2D --=20
Marc Mutz <mutz@kde.org>
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE82t3N3oWD+L2/6DgRAlcvAJoDRQr+9AIq9J1k4jioo1LiPufPIgCgtFag
/LWfdENWjoE8xSHeFk67tNU=3D
=3DxDxC
=2D----END PGP SIGNATURE-----



From karlsson@hal-pc.org  Thu May  9 23:54:02 2002
From: karlsson@hal-pc.org (Brian M. Carlson)
Date: Thu May  9 22:54:02 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <20020509195108.GE3323@akamai.com>
References: <20020509194024.GB6949@stonewall> <20020509195108.GE3323@akamai.com>
Message-ID: <20020509205512.GC6949@stonewall>

--bKyqfOwhbdpXa4YI
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, May 09, 2002 at 03:51:08PM -0400, David Shaw wrote:
> On Thu, May 09, 2002 at 07:40:24PM +0000, Brian M. Carlson wrote:
>=20
> > I have set force-v4-certs in my options file. I also have
> > digest-algo RIPEMD160 set. Yet, my signatures still are made with
> > SHA1, which I deprecate strongly.  If I have a preference on my key,
> > I'd prefer that gpg choose that, unless I choose a digest-algo
> > option, in which case gpg uses that. gpg has done neither.
>=20
> Let me make sure I understand what you are doing.  You want your key
> signatures - not data signatures - to use RIPEMD160 and not SHA1?
>=20
> --digest-algo only applies to data signatures.
>=20
> Why do you strongly deprecate SHA1?

SHA1 was created by the US government. I feel that the US government does n=
ot
have its citizens best interest at heart in the realm of cryptography, and
sometimes not with privacy in general. I prefer RIPEMD160 as it was created
independently outside of the US. Anyway, whatever my reason, shouldn't it
be my choice?

digest-algo has worked before, with my RSA key and with my ElGamal 20 key (=
see
sig) on key signatures. I might be able to dig them up for you.

--=20
Brian M. Carlson
<karlsson@hal-pc.org>
OpenPGP: 0x351336B2DCA1913A

--bKyqfOwhbdpXa4YI
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Ubi libertas, ibi patria.

iQEVAwUBPNriMOWR/8lWBVPnAQMc1Af/Wm+U4ujICM9ur9JRxWBhRVR5zuiPhxVT
RtpmsROW/0opBSi3e1Y1BUwzO6f6z1M+1lD65xuTsCG57nzIsNNmgVI/CH7SZrBj
RXbp8DuLt0WTGsXvGrJRqGNrrPtLg9FsaGz+rWgylStNyujzg2dpNbDti6YkqoN5
IcFckpX5KxW3kIbFZ/9JR41LzxwiR4reZoiIrXCnkarGvSYlbtnSREkmYhdrSkaH
Dn+BY05stL4mfuKXEpuEAgK9qVIt14xx8QyjevlYkpl80AD5Hw+O1mR1eqb7OLnQ
NL8rBwOd4Dhgejq06WP3+pEujAqxssjRmOddPguvRbvbItwUAHLnaQ==
=SIup
-----END PGP SIGNATURE-----

--bKyqfOwhbdpXa4YI--


From karlsson@hal-pc.org  Thu May  9 23:58:01 2002
From: karlsson@hal-pc.org (Brian M. Carlson)
Date: Thu May  9 22:58:01 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <20020509195108.GE3323@akamai.com>
References: <20020509194024.GB6949@stonewall> <20020509195108.GE3323@akamai.com>
Message-ID: <20020509205912.GD6949@stonewall>

--at6+YcpfzWZg/htY
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, May 09, 2002 at 03:51:08PM -0400, David Shaw wrote:
> On Thu, May 09, 2002 at 07:40:24PM +0000, Brian M. Carlson wrote:
>=20
> > I have set force-v4-certs in my options file. I also have
> > digest-algo RIPEMD160 set. Yet, my signatures still are made with
> > SHA1, which I deprecate strongly.  If I have a preference on my key,
> > I'd prefer that gpg choose that, unless I choose a digest-algo
> > option, in which case gpg uses that. gpg has done neither.
>=20
> Let me make sure I understand what you are doing.  You want your key
> signatures - not data signatures - to use RIPEMD160 and not SHA1?

Yes. I want all my uses of the hash function for signatures to be with
RIPEMD160. I also use s2k-digest-algo RIPEMD160, but that is unrelated.=20

--=20
Brian M. Carlson
<karlsson@hal-pc.org>
OpenPGP: 0x351336B2DCA1913A

--at6+YcpfzWZg/htY
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Ubi libertas, ibi patria.

iQEVAwUBPNrjIOWR/8lWBVPnAQM1gAgAgtNXo8MtYjBW6bhwPPXZtWAQ5Ssl4UXD
Z07RkNGCe8ITiomTbddFWZO7o+gxEF0NX/eLaMTARtGmDqGWypeSpIuIGM1Z2qfG
vZ9wlUV9MZdvk0mmWhRpIlT1DzLpKsAwzOExUCPBZVV1X6ALUhjG7Y16RIzfVZZc
CzO+nyQIjRYO12iShNDQCVJW6R6751Fc6Cx/BViTu5FzAQ877VYrRi/Gls4E2+Al
Ke/M+su62b9jadyGRiiYC41DtEG/NIl8Mi+qGjwZRGt8PIJ45r3Ugg4tLjnfBjjr
vV5kWauq8CxR2O38Ty14EhTOFrUe518Abi36Hbuxgaqvqh/3GPSG4w==
=aAr/
-----END PGP SIGNATURE-----

--at6+YcpfzWZg/htY--


From rjhansen@inav.net  Fri May 10 00:21:01 2002
From: rjhansen@inav.net (Robert J. Hansen)
Date: Thu May  9 23:21:01 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <20020509205512.GC6949@stonewall>
References: <20020509194024.GB6949@stonewall>
 <20020509195108.GE3323@akamai.com>  <20020509205512.GC6949@stonewall>
Message-ID: <1020979199.32490.9.camel@numbers>

> SHA1 was created by the US government. I feel that the US government does not
> have its citizens best interest at heart in the realm of cryptography, and

SHA-1 isn't used for message security; it's used for message
authentication.  The NSA's mandate includes keeping US Gov't traffic
secure, and as such, deliberately creating a faulty hash
algorithm--especially one that's heavily used throughout the USG--would
be counter to the NSA's mandate.

Then there's also the intense peer review, and the fact that it's SHA-1,
not SHA-0... SHA-0 had a nasty, but very subtle, bug.  Who found the
bug, publicized it, and issued a fix?  The NSA.

While I agree there's a lot of room for skepticism on the NSA's motives,
it appears to me that throwing out SHA-1 is tossing the baby out with
the bathwater.  Still--if it floats your boat, use RIPEMD160.

> independently outside of the US. Anyway, whatever my reason, shouldn't it
> be my choice?

Not necessarily.  The axiom which guides GnuPG is "be liberal in what
you accept, but conservative in what you generate".  If I recall,
RIPEMD-160 is a SHOULD, not a MUST.  It would be entirely consistent and
RFC-conformant for GnuPG to accept RIPEMD-160 in traffic, but to only
use SHA-1 for output.

I'm not suggesting we do that, by the by.  I'm just pointing out that
"shouldn't it be my choice?" isn't always something you answer with a
"yes".  There's a time and a place for strict enforcement of policy.




From dshaw@jabberwocky.com  Fri May 10 00:31:01 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Thu May  9 23:31:01 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <20020509205512.GC6949@stonewall>
References: <20020509194024.GB6949@stonewall> <20020509195108.GE3323@akamai.com> <20020509205512.GC6949@stonewall>
Message-ID: <20020509213137.GB6484@akamai.com>

On Thu, May 09, 2002 at 08:55:13PM +0000, Brian M. Carlson wrote:
> On Thu, May 09, 2002 at 03:51:08PM -0400, David Shaw wrote:
> > On Thu, May 09, 2002 at 07:40:24PM +0000, Brian M. Carlson wrote:
> > 
> > > I have set force-v4-certs in my options file. I also have
> > > digest-algo RIPEMD160 set. Yet, my signatures still are made with
> > > SHA1, which I deprecate strongly.  If I have a preference on my key,
> > > I'd prefer that gpg choose that, unless I choose a digest-algo
> > > option, in which case gpg uses that. gpg has done neither.
> > 
> > Let me make sure I understand what you are doing.  You want your key
> > signatures - not data signatures - to use RIPEMD160 and not SHA1?
> > 
> > --digest-algo only applies to data signatures.
> > 
> > Why do you strongly deprecate SHA1?
> 
> SHA1 was created by the US government. I feel that the US government does not
> have its citizens best interest at heart in the realm of cryptography, and
> sometimes not with privacy in general. I prefer RIPEMD160 as it was created
> independently outside of the US. Anyway, whatever my reason, shouldn't it
> be my choice?

Sure, I'm just curious.

There is one "danger" of making RIPEMD160 key signatures, in that it
is not a required algorithm in OpenPGP.  There can be implementations
that do not support it, and so key signatures using it are not
universally usable.  This means that two different implementations may
have two different views of the web of trust, which is not a great
thing.

That said, they're your signatures, and you need to make them in a way
that you are comfortable with.  The two "bigs", PGP and GnuPG both
support RIPEMD160.

> digest-algo has worked before, with my RSA key and with my ElGamal
> 20 key (see sig) on key signatures. I might be able to dig them up
> for you.

ElGamal key signatures use RIPEMD160 by default.  What version of
GnuPG did you do the RSA one with?  It certainly couldn't have been
1.0.6 or 1.0.7.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From rabbi@quickie.net  Fri May 10 00:44:01 2002
From: rabbi@quickie.net (Len Sassaman)
Date: Thu May  9 23:44:01 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <1020979199.32490.9.camel@numbers>
Message-ID: <Pine.LNX.4.30.QNWS.0205091430390.10536-100000@thetis.deor.org>

On 9 May 2002, Robert J. Hansen wrote:

> Not necessarily.  The axiom which guides GnuPG is "be liberal in what
> you accept, but conservative in what you generate".  If I recall,
> RIPEMD-160 is a SHOULD, not a MUST.  It would be entirely consistent and
> RFC-conformant for GnuPG to accept RIPEMD-160 in traffic, but to only
> use SHA-1 for output.

First of all: RIPEMD-160 is neither a MUST or a SHOULD. (It's neither a
required, not suggested, algorithm in OpenPGP. Don't be surprised if
implementations do not support or understand RIPEMD-160 signatures).

Secondly, DSS is defined as requiring SHA-1. Consequently, SHA-1 has
received more attention than other 160-bit hash algorithms by
cryptographers. RIPEMD-160 is considered by many to be just as strong, but
it certainly hasn't received the same level of scrutiny.

Notice, also, that the security of PGP signatures is somewhat dependant
upon all of the hashes that the implementation allows. I draw your
attention to section 13 of RCF 2440bis05:

     * There is a somewhat-related potential security problem in
       signatures. If an attacker can find a message that hashes to the
       same hash with a different algorithm, a bogus signature
       structure can be constructed that evaluates correctly.

       For example, suppose Alice DSA signs message M using hash
       algorithm H. Suppose that Mallet finds a message M' that has the
       same hash value as M with H'. Mallet can then construct a
       signature block that verifies as Alice's signature of M' with
       H'. However, this would also constitute a weakness in either H
       or H' or both. Should this ever occur, a revision will have to
       be made to this document to revise the allowed hash algorithms.


So, if any of the hash algorithms are broken, we could be in quite a bit
of trouble. (This is my argument against adding in SHA-256, etc., until
there is a clear benefit (such as larger DSA keys) to doing so.)


Len



From karlsson@hal-pc.org  Fri May 10 01:25:02 2002
From: karlsson@hal-pc.org (Brian M. Carlson)
Date: Fri May 10 00:25:02 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <Pine.LNX.4.30.QNWS.0205091430390.10536-100000@thetis.deor.org>
References: <1020979199.32490.9.camel@numbers> <Pine.LNX.4.30.QNWS.0205091430390.10536-100000@thetis.deor.org>
Message-ID: <20020509222550.GE6949@stonewall>

--pY3vCvL1qV+PayAL
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, May 09, 2002 at 02:44:43PM -0700, Len Sassaman wrote:
> On 9 May 2002, Robert J. Hansen wrote:
>=20
> > Not necessarily.  The axiom which guides GnuPG is "be liberal in what
> > you accept, but conservative in what you generate".  If I recall,
> > RIPEMD-160 is a SHOULD, not a MUST.  It would be entirely consistent and
> > RFC-conformant for GnuPG to accept RIPEMD-160 in traffic, but to only
> > use SHA-1 for output.
>=20
> First of all: RIPEMD-160 is neither a MUST or a SHOULD. (It's neither a
> required, not suggested, algorithm in OpenPGP. Don't be surprised if
> implementations do not support or understand RIPEMD-160 signatures).

While this may be true, it is a de facto SHOULD, just like IDEA is.
=20
> Secondly, DSS is defined as requiring SHA-1. Consequently, SHA-1 has
> received more attention than other 160-bit hash algorithms by
> cryptographers. RIPEMD-160 is considered by many to be just as strong, but
> it certainly hasn't received the same level of scrutiny.

The last time I used my DSA key, other than to update its expiration date,
was over a year ago. I use my RSA key almost exclusively. When I don't, I
use my ElGamal type 20 key. (I know how you feel about ElGamal 20 keys ;-)
There is no reason that DSA couldn't use any other 160 bit hash. Neverthele=
ss,
I *do* use SHA1 with DSA.

> Notice, also, that the security of PGP signatures is somewhat dependant
> upon all of the hashes that the implementation allows. I draw your
> attention to section 13 of RCF 2440bis05:
<snip>

I am quite aware of the requirements for a collision-resistant hash functio=
n.
I own Applied Cryptography and have read it several times. I have also read
other works on the subject, including the definition of RIPEMD160.

--=20
Brian M. Carlson
<karlsson@hal-pc.org>
OpenPGP: 0x351336B2DCA1913A

--pY3vCvL1qV+PayAL
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Ubi libertas, ibi patria.

iQEVAwUBPNr3buWR/8lWBVPnAQOEHgf/VW62sV76aCca5/02aJxU1XaFrmsmbdKg
wyrngl6Q+AwIp/aS7WdjJrcQtL7B1d71fxh6e8NsNj2t3Nxcn4FJka49EmFzyzFb
189PLjqEEYa5gbYVaMrr6MAhFxa1pJWegpTfuGzba8uLVXdowZku76xwvMArldMC
i7pSnUDmPUh1yUjgmPMnDDHktkXjt9UvbuU96VTu2yxD54oOqhCeArxuaSENjXhA
GJyhJy4u9X3ShCB78M5eVfdl25JdZu2D7TFPuxV4Uh0TOqDKadBvei+pQYsComVc
mn4qxdJ2iwpquYOhGixcmHjgiNeP5UrzJaI7jW/YdM+I70Y6yqzNIw==
=zbnQ
-----END PGP SIGNATURE-----

--pY3vCvL1qV+PayAL--


From rabbi@quickie.net  Fri May 10 01:29:02 2002
From: rabbi@quickie.net (Len Sassaman)
Date: Fri May 10 00:29:02 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <20020509222550.GE6949@stonewall>
Message-ID: <Pine.LNX.4.30.QNWS.0205091526130.14462-100000@thetis.deor.org>

On Thu, 9 May 2002, Brian M. Carlson wrote:

> > First of all: RIPEMD-160 is neither a MUST or a SHOULD. (It's neither a
> > required, not suggested, algorithm in OpenPGP. Don't be surprised if
> > implementations do not support or understand RIPEMD-160 signatures).
>
> While this may be true, it is a de facto SHOULD, just like IDEA is.

Untrue. If it isn't listed as SHOULD in the document, it isn't a SHOULD.
There are no "de facto SHOULDs."

IDEA is a SHOULD in RFC 2440. Its status has since changed, I believe.





From rjhansen@inav.net  Fri May 10 05:47:01 2002
From: rjhansen@inav.net (Robert J. Hansen)
Date: Fri May 10 04:47:01 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <20020509222550.GE6949@stonewall>
References: <1020979199.32490.9.camel@numbers>
 <Pine.LNX.4.30.QNWS.0205091430390.10536-100000@thetis.deor.org>
 <20020509222550.GE6949@stonewall>
Message-ID: <1020998781.524.11.camel@numbers>

> While this may be true, it is a de facto SHOULD, just like IDEA is.

Be careful. Going further down this road will lead us to the World of
Microsoft.  There's a razor's edge between saying "we will support the
spec, including all SHOULDs" and saying "we will support the spec, plus
whatever additional things we feel are de-facto standards".  The one way
is the Free Software/Open Source way.  The other way is the Microsoft
Embrace and Extend way (q.v., their Kerberos implementation).

Unless the spec lists it as a MUST or a SHOULD, I honestly don't think
GnuPG should generate it.  Be liberal in what you accept, but very
conservative in what you generate.  (I know that Len says RIPEMD-160
isn't a SHOULD, and I have no reason to doubt him.  However, I haven't
checked RFC2440/2015/3156 myself yet, so I'll hedge it with an
`unless'.)

> There is no reason that DSA couldn't use any other 160 bit hash. Nevertheless,

Sure there is.  If DSA used any other 160-bit hash, it wouldn't be DSA
anymore because the DSA spec demands SHA.  Insofar as whether or not the
DSA spec could be changed to accept RIPEMD-160, and whether or not the
resulting system would still be secure... who knows?  Cryptosystems are
fragile things; known-strong algorithms can interact with each other to
produce weak systems.





From dshaw@jabberwocky.com  Fri May 10 07:23:01 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Fri May 10 06:23:01 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <1020998781.524.11.camel@numbers>
References: <1020979199.32490.9.camel@numbers> <Pine.LNX.4.30.QNWS.0205091430390.10536-100000@thetis.deor.org> <20020509222550.GE6949@stonewall> <1020998781.524.11.camel@numbers>
Message-ID: <20020510042351.GB662@akamai.com>

On Thu, May 09, 2002 at 09:46:18PM -0500, Robert J. Hansen wrote:

> Unless the spec lists it as a MUST or a SHOULD, I honestly don't think
> GnuPG should generate it.  Be liberal in what you accept, but very
> conservative in what you generate.  (I know that Len says RIPEMD-160
> isn't a SHOULD, and I have no reason to doubt him.  However, I haven't
> checked RFC2440/2015/3156 myself yet, so I'll hedge it with an
> `unless'.)

He's right.  SHA1 is the only MUST hash, and MD5 is the only SHOULD.

Still, the spec is not the beginning and the end of GnuPG.  GnuPG
certainly does things that are contrary to the spec (and documents
them carefully and gives the user the ability to turn them off).  For
example, when generating a clear signature, by default a line
beginning with "From " is escaped, probably in violation of a strict
reading of RFC2440.  The reason it does this is that clearsigned
documents are often emailed and otherwise the mail system would
probably break the signature when it changed "From " to ">From ".  PGP
does the same thing.

Another good example is the v3 sigs problem.  Most versions of PGP
don't handle v4 sigs on data, but the RFC says they are a SHOULD.  If
GnuPG blindly followed the SHOULD it would make itself incompatible
with PGP.

The --openpgp flag in GnuPG turns all of this off and makes it use a
rigid following of RFC2440.  If you use that flag though, you'll have
problems communicating with the rest of the world.

> > There is no reason that DSA couldn't use any other 160 bit hash. Nevertheless,
> 
> Sure there is.  If DSA used any other 160-bit hash, it wouldn't be DSA
> anymore because the DSA spec demands SHA.  Insofar as whether or not the
> DSA spec could be changed to accept RIPEMD-160, and whether or not the
> resulting system would still be secure... who knows?

Not quite correct.  The DSA algorithm can use any 160-bit hash.  The
DSS spec is DSA+SHA1 (plus some other details that don't matter here).
OpenPGP does not specify DSS signatures - it specifies DSA and can
thus use any 160-bit hash.

I agree with Len in general on being very careful with adding new
algorithms to OpenPGP, and in turn to GnuPG.  However, in the specific
case of RIPEMD-160, it's already part of the standard and both PGP and
GnuPG already support it.  There is no question on whether to add it -
it's already added.  There is also no evidence that it is not just as
secure as SHA1 is.

I don't see any particular reason for someone to not use RIPEMD-160
for data signatures - if there is a compatibility problem they're only
hurting themselves.  I do wish people would not use it for key
signatures, as a compatibility problem there affects the web of trust.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From Andreas.Lippek@DePfa.com  Fri May 10 08:59:02 2002
From: Andreas.Lippek@DePfa.com (Lippek, Andreas, IT-TR)
Date: Fri May 10 07:59:02 2002
Subject: unsubscribe
Message-ID: <A04A1C51B715E44C81D53F49C8DD08A70AD9D9@fraexx01.DEPFA-BANK.COM>


-----Original Message-----
From: Robert J. Hansen [mailto:rjhansen@inav.net]
Sent: Freitag, 10. Mai 2002 04:46
To: Brian M. Carlson
Cc: gnupg-devel@gnupg.org; rabbi@quickie.net
Subject: Re: force-v4-certs and digest-algo


> While this may be true, it is a de facto SHOULD, just like IDEA is.

Be careful. Going further down this road will lead us to the World of
Microsoft.  There's a razor's edge between saying "we will support the
spec, including all SHOULDs" and saying "we will support the spec, plus
whatever additional things we feel are de-facto standards".  The one way
is the Free Software/Open Source way.  The other way is the Microsoft
Embrace and Extend way (q.v., their Kerberos implementation).

Unless the spec lists it as a MUST or a SHOULD, I honestly don't think
GnuPG should generate it.  Be liberal in what you accept, but very
conservative in what you generate.  (I know that Len says RIPEMD-160
isn't a SHOULD, and I have no reason to doubt him.  However, I haven't
checked RFC2440/2015/3156 myself yet, so I'll hedge it with an
`unless'.)

> There is no reason that DSA couldn't use any other 160 bit hash.
Nevertheless,

Sure there is.  If DSA used any other 160-bit hash, it wouldn't be DSA
anymore because the DSA spec demands SHA.  Insofar as whether or not the
DSA spec could be changed to accept RIPEMD-160, and whether or not the
resulting system would still be secure... who knows?  Cryptosystems are
fragile things; known-strong algorithms can interact with each other to
produce weak systems.




_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel


From rabbi@quickie.net  Fri May 10 20:11:02 2002
From: rabbi@quickie.net (Len Sassaman)
Date: Fri May 10 19:11:02 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <1020998781.524.11.camel@numbers>
Message-ID: <Pine.LNX.4.30.QNWS.0205101003070.3958-100000@thetis.deor.org>

On 9 May 2002, Robert J. Hansen wrote:

> > While this may be true, it is a de facto SHOULD, just like IDEA is.
>
> Be careful. Going further down this road will lead us to the World of
> Microsoft.  There's a razor's edge between saying "we will support the
> spec, including all SHOULDs" and saying "we will support the spec, plus
> whatever additional things we feel are de-facto standards".  The one way
> is the Free Software/Open Source way.  The other way is the Microsoft
> Embrace and Extend way (q.v., their Kerberos implementation).

To further clarify what I was saying:

The entire point of the IETF, and of the RFC system, is to eliminate the
"de facto standards" mess, and give us actual standards.

> Unless the spec lists it as a MUST or a SHOULD, I honestly don't think
> GnuPG should generate it.  Be liberal in what you accept, but very
> conservative in what you generate.  (I know that Len says RIPEMD-160
> isn't a SHOULD, and I have no reason to doubt him.  However, I haven't
> checked RFC2440/2015/3156 myself yet, so I'll hedge it with an
> `unless'.)

Well, 2015/3156 don't cover this, so that's easy. But if you want to see
for yourself, it's section 9.4 of RFC2440bis5:

http://search.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-05.txt

> > There is no reason that DSA couldn't use any other 160 bit hash.
>
> Sure there is.  If DSA used any other 160-bit hash, it wouldn't be DSA
> anymore because the DSA spec demands SHA.  Insofar as whether or not the
> DSA spec could be changed to accept RIPEMD-160, and whether or not the
> resulting system would still be secure... who knows?  Cryptosystems are
> fragile things; known-strong algorithms can interact with each other to
> produce weak systems.

You are confusing DSA (the algorithm) with DSS (the standard). DSS
mandates DSA and SHA-1. DSA, however, could be used with any strong hash
function that is sufficiently long.

--Len.












From rjhansen@inav.net  Fri May 10 21:51:01 2002
From: rjhansen@inav.net (Robert J. Hansen)
Date: Fri May 10 20:51:01 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <Pine.LNX.4.30.QNWS.0205101003070.3958-100000@thetis.deor.org>
Message-ID: <Pine.LNX.4.44L0.0205101348180.7060-100000@soli.inav.net>

> The entire point of the IETF, and of the RFC system, is to eliminate the
> "de facto standards" mess, and give us actual standards.

... and to further elaborate my point (which follows from that): a 
standard quickly devolves to near-uselessness if people start extending it 
willy-nilly.  Look at the UNIX Wars, or "This Site Best Viewed In".  A 
standard ought be adhered to unless there are clear and compelling reasons 
not to do so.  I don't see any clear and compelling reason to use 
RIPEMD-160, and so I don't.  (Let me say, though, that it's not my 
intention to speak for anyone but me.)

> You are confusing DSA (the algorithm) with DSS (the standard). DSS

D'oh.  My goof.





From dshaw@jabberwocky.com  Fri May 10 22:19:01 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Fri May 10 21:19:01 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <Pine.LNX.4.44L0.0205101348180.7060-100000@soli.inav.net>
References: <Pine.LNX.4.30.QNWS.0205101003070.3958-100000@thetis.deor.org> <Pine.LNX.4.44L0.0205101348180.7060-100000@soli.inav.net>
Message-ID: <20020510192021.GA14633@akamai.com>

On Fri, May 10, 2002 at 01:52:32PM -0500, Robert J. Hansen wrote:
> > The entire point of the IETF, and of the RFC system, is to eliminate the
> > "de facto standards" mess, and give us actual standards.
> 
> ... and to further elaborate my point (which follows from that): a 
> standard quickly devolves to near-uselessness if people start extending it 
> willy-nilly.  Look at the UNIX Wars, or "This Site Best Viewed In".  A 
> standard ought be adhered to unless there are clear and compelling reasons 
> not to do so.  I don't see any clear and compelling reason to use 
> RIPEMD-160, and so I don't.  (Let me say, though, that it's not my 
> intention to speak for anyone but me.)

Just to be clear here, using RIPEMD-160 is completely and totally
adhering to the OpenPGP standard in every possible way.  There are
certainly minor compatibility reasons not to use it, but it is
definitely part of the standard.  To put this in context, other
completely optional parts of the standard are Blowfish, Twofish, and
every AES above 128 bits.

Using "Joe's Random Hash Algorithm 128" would be willy-nilly. ;)

Werner and I discussed it, and I've added the ability to pick the hash
when making a key signature (--cert-digest-algo) to 1.0.8.  I do hope
people will not use this feature (and the manual explains why it isn't
a good idea), but in the end, it is up to them what hash they use.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From dgc@uchicago.edu  Fri May 10 22:29:02 2002
From: dgc@uchicago.edu (David Champion)
Date: Fri May 10 21:29:02 2002
Subject: force-v4-certs and digest-algo
In-Reply-To: <20020510192021.GA14633@akamai.com>
References: <Pine.LNX.4.30.QNWS.0205101003070.3958-100000@thetis.deor.org> <Pine.LNX.4.44L0.0205101348180.7060-100000@soli.inav.net> <20020510192021.GA14633@akamai.com>
Message-ID: <20020510192938.GF9707@dust.uchicago.edu>

* On 2002.05.10, in <20020510192021.GA14633@akamai.com>,
*	"David Shaw" <dshaw@jabberwocky.com> wrote:
> 
> Using "Joe's Random Hash Algorithm 128" would be willy-nilly. ;)

But I've tested it thoroughly, and I'm certain it's quite secure -- our
reference code remains uncracked! The source is even available (for a
nominal licensing fee) to anyone who passes our trust audit. Why are you
repressing us?

--
Joe
Joe's Codes, Ltd.
Call for a quote! +1-900-SAF-CODE


From sandeep_sikka@hotmail.com  Sat May 11 01:12:02 2002
From: sandeep_sikka@hotmail.com (Sandeep Sikka)
Date: Sat May 11 00:12:02 2002
Subject: GPG 1.0.6 bug - sign/encrypt/decrypt 0 bytes.
Message-ID: <F1024t5BD8wbVGkJmiW00014762@hotmail.com>

Hi,

If I sign/encrypt & then decrypt 0 bytes, I get junk. I don't get 0 bytes. 
If I use even one byte, I have no problems. If I just encrypt/decrypt 0 
bytes, I get 0 bytes in return. But if I sign, I have problems. Is this a 
known bug with GPG? Or am I not understanding & using GPG properly?

Thanks!

Sandeep.

----
sikka@debian:~$ gpg --version
gpg (GnuPG) 1.0.6
Copyright (C) 2001 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.
----

sikka@debian:~$ gpg --list-keys
/u3/sikka/.gnupg/pubring.gpg
----------------------------
pub  1024D/85DEA7EC 2002-05-10 Sandeep Sikka (test key) 
<sikka@iamtesting.com>
sub  1024g/64B4BEA2 2002-05-10
----

# Encrypt 0 bytes - NO PROBLEM
sikka@debian:~$ echo -n | gpg -ea -r sikka@iamtesting.com -u 
sikka@iamtesting.com | gpg --decrypt
gpg: NOTE: secret key 85DEA7EC is NOT protected.
gpg: NOTE: secret key 85DEA7EC is NOT protected.
gpg: encrypted with 1024-bit ELG-E key, ID 64B4BEA2, created 2002-05-10
      "Sandeep Sikka (test key) <sikka@iamtesting.com>"
----

# Sign/encrypt one byte - NO PROBLEM
sikka@debian:~$ echo X | gpg -sea -r sikka@iamtesting.com -u 
sikka@iamtesting.com | gpg --decrypt
gpg: NOTE: secret key 85DEA7EC is NOT protected.
gpg: NOTE: secret key 85DEA7EC is NOT protected.
gpg: encrypted with 1024-bit ELG-E key, ID 64B4BEA2, created 2002-05-10
      "Sandeep Sikka (test key) <sikka@iamtesting.com>"
X
gpg: Signature made Fri May 10 18:05:33 2002 EDT using DSA key ID 85DEA7EC
gpg: Good signature from "Sandeep Sikka (test key) <sikka@iamtestng.com>"
----

# Sign/Encrypt 0 bytes - PROBLEM CASE
sikka@debian:~$ echo -n | gpg -sea -r sikka@iamtesting.com -u 
sikka@iamtesting.com | gpg --decrypt
gpg: NOTE: secret key 85DEA7EC is NOT protected.
gpg: NOTE: secret key 85DEA7EC is NOT protected.
gpg: encrypted with 1024-bit ELG-E key, ID 64B4BEA2, created 2002-05-10
      "Sandeep Sikka (test key) <sikka@iamtesting.com>"
?b<ÜDfbùú4RÞNbÄÃ ÁF>/èLErå9æCmÜsâ(×t
----











_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com



From dshaw@jabberwocky.com  Sat May 11 01:26:01 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Sat May 11 00:26:01 2002
Subject: GPG 1.0.6 bug - sign/encrypt/decrypt 0 bytes.
In-Reply-To: <F1024t5BD8wbVGkJmiW00014762@hotmail.com>
References: <F1024t5BD8wbVGkJmiW00014762@hotmail.com>
Message-ID: <20020510222724.GE14633@akamai.com>

On Fri, May 10, 2002 at 05:12:17PM -0500, Sandeep Sikka wrote:
> Hi,
> 
> If I sign/encrypt & then decrypt 0 bytes, I get junk. I don't get 0 bytes. 
> If I use even one byte, I have no problems. If I just encrypt/decrypt 0 
> bytes, I get 0 bytes in return. But if I sign, I have problems. Is this a 
> known bug with GPG? Or am I not understanding & using GPG properly?

This was fixed in GnuPG 1.0.7.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From benfell@greybeard95a.com  Sun May 12 08:07:01 2002
From: benfell@greybeard95a.com (David Benfell)
Date: Sun May 12 07:07:01 2002
Subject: configure produces zero length Makefile
In-Reply-To: <040301c1f050$f71bf8e0$ede3c23f@KR6X.ORG>
References: <040301c1f050$f71bf8e0$ede3c23f@KR6X.ORG>
Message-ID: <20020512050748.GF17531@raven.parts-unknown.org>

--FN+gV9K+162wdwwF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello all,

When I ran configure (with --prefix=3D/usr), I observed the following:

configure: creating ./config.status
config.status: creating Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating intl/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating po/Makefile.in
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating util/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating mpi/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating cipher/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating g10/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating keyserver/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating keyserver/gpgkeys_mailto
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating keyserver/gpgkeys_test
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating doc/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating tools/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating zlib/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating checks/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating config.h
config.status: config.h is unchanged
config.status: linking ./mpi/i386/mpih-add1.S to mpi/mpih-add1.S
config.status: linking ./mpi/i386/mpih-mul1.S to mpi/mpih-mul1.S
config.status: linking ./mpi/i386/mpih-mul2.S to mpi/mpih-mul2.S
config.status: linking ./mpi/i386/mpih-mul3.S to mpi/mpih-mul3.S
config.status: linking ./mpi/i386/mpih-lshift.S to mpi/mpih-lshift.S
config.status: linking ./mpi/i386/mpih-rshift.S to mpi/mpih-rshift.S
config.status: linking ./mpi/i386/mpih-sub1.S to mpi/mpih-sub1.S
config.status: linking ./mpi/generic/mpi-asm-defs.h to
mpi/mpi-asm-defs.h
config.status: creating po/POTFILES
config.status: creating po/Makefile
g10defs.h is unchanged

                Configured for: GNU/Linux (i686-pc-linux-gnu)
    Dynamically linked modules: rndunix rndegd tiger
     Statically linked modules: rndlinux sha1 rmd160 md5

make: *** No targets.  Stop.
root@home:/usr/local/src/gnupg-1.0.7 # ls -al Makefile*
-rw-r--r--    1 root     root            0 May  1 22:51 Makefile
-rw-r--r--    1 1000     1000         1800 Dec 21 11:49 Makefile.am
-rw-rw-r--    1 1000     1000        16187 Apr 29 08:06 Makefile.in

I tried attaching the configure log, but this caused the e-mail to
exceed the 40KB limit for posting.

This is on a SuSE 7.1 system which has been heavily upgraded, mostly
from source.


--=20
David Benfell, LCP
benfell@parts-unknown.org
---
Resume available at http://www.parts-unknown.org/resume.html

--FN+gV9K+162wdwwF
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iQEXAwUBPN34pHw5zqzgtjVOFANyiQP+K4WF/Blma96kAoPpp2UcW+5icMc6r4/L
lxC3csAUn5lCKHvuLMEpQoOUYHvS0fbIPQAc2GLdkwdyihPXsO5pMSF65/QennDY
XvEFZcgQVkpgW7RAqMzV3iLVPJLCkjeQqx3uMwFFqpiZm6LPnp+2Ce2xDmyXWGJk
LqyTRC8k0F8D/AwH0OSKeerkovm3pDc4YrrzZ5pLhQlG6pNp8j3sVZ6Wc3jb/YV9
2sLHb/k+o1uw7wPIp3R8v7OEd0smVgr6qb9r4ZMRdyBV2TbzZs2sXIqbkXHYeN94
D+zWJRcH1ZlSveQt0aCuUxKEEiEbvXLx1z0Hyf2CcZxD9qCyqOUiDBkr
=TMp9
-----END PGP SIGNATURE-----

--FN+gV9K+162wdwwF--


From srm_dfr@hotmail.com  Sun May 12 17:16:02 2002
From: srm_dfr@hotmail.com (eloj %20)
Date: Sun May 12 16:16:02 2002
Subject: encrypting to public key crashes gnupg 1.0.6-2 (win32)
Message-ID: <F125KpO2DTSWFSSEfLM00015e40@hotmail.com>

I was helping a friend set up GnuPG 1.0.6-2 Win32 yesterday. When all was 
set up we discovered that no-one seemed able to encrypt to his key.

The crash is reproducably on several installations.

'The instruction at "0x74fad613" referenced memory at "0x024a5000". The 
memory could not be "written".'

I haven't bothered testing on 1.0.7 since there is no officiall win32-port 
yet.

Anyone willing to take a look at the key and see if they can reproduce the 
problem? A developer with a what-will-become win32 build maybe.

I won't post the key here since the secret key doesn't exist any more and 
there is no revocation should it slip into the wild, but if anyone wants it 
contact me at eddy klopper net.


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.



From redbird@rbisland.cx  Sun May 12 19:58:01 2002
From: redbird@rbisland.cx (Gordon Worley)
Date: Sun May 12 18:58:01 2002
Subject: configure produces zero length Makefile
In-Reply-To: <20020512050748.GF17531@raven.parts-unknown.org>
Message-ID: <3057365C-65C9-11D6-A13F-000A27B4DEFC@rbisland.cx>

On Sunday, May 12, 2002, at 01:07  AM, David Benfell wrote:

> make: *** No targets.  Stop.
> root@home:/usr/local/src/gnupg-1.0.7 # ls -al Makefile*
> -rw-r--r--    1 root     root            0 May  1 22:51 Makefile
> -rw-r--r--    1 1000     1000         1800 Dec 21 11:49 Makefile.am
> -rw-rw-r--    1 1000     1000        16187 Apr 29 08:06 Makefile.in

This looks a lot like what happens on Darwin.  While it's not likely the 
same but, it's worth mentioning that if your sh is really zsh, you need 
to go through the configure script and change all instances of 'CDPATH=' 
to 'unset CDPATH'.

--
Gordon Worley                     `When I use a word,' Humpty Dumpty
http://www.rbisland.cx/            said, `it means just what I choose
redbird@rbisland.cx                it to mean--neither more nor less.'
PGP:  0xBBD3B003                                  --Lewis Carroll



From benfell@greybeard95a.com  Mon May 13 01:25:01 2002
From: benfell@greybeard95a.com (David Benfell)
Date: Mon May 13 00:25:01 2002
Subject: configure produces zero length Makefile
In-Reply-To: <3057365C-65C9-11D6-A13F-000A27B4DEFC@rbisland.cx>
References: <20020512050748.GF17531@raven.parts-unknown.org> <3057365C-65C9-11D6-A13F-000A27B4DEFC@rbisland.cx>
Message-ID: <20020512222543.GA803@raven.parts-unknown.org>

--opJtzjQTFsWo+cga
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, 12 May 2002 12:56:22 -0400, Gordon Worley wrote:
>=20
> On Sunday, May 12, 2002, at 01:07  AM, David Benfell wrote:
>=20
> >make: *** No targets.  Stop.
> >root@home:/usr/local/src/gnupg-1.0.7 # ls -al Makefile*
> >-rw-r--r--    1 root     root            0 May  1 22:51 Makefile
> >-rw-r--r--    1 1000     1000         1800 Dec 21 11:49 Makefile.am
> >-rw-rw-r--    1 1000     1000        16187 Apr 29 08:06 Makefile.in
>=20
> This looks a lot like what happens on Darwin.  While it's not likely the=
=20
> same but, it's worth mentioning that if your sh is really zsh,

Yup, I did that.  I hate bash.  I'd had some problems with
initialization scripts as a result but solved those with simpler,
customized language.

> you need=20
> to go through the configure script and change all instances of 'CDPATH=3D=
'=20
> to 'unset CDPATH'.
>=20
Good catch.  Really good catch.  Thank you.

--=20
David Benfell
benfell@parts-unknown.org
---
There's an old proverb that says just about whatever you want it to.
                                [from fortune]

--opJtzjQTFsWo+cga
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iQEXAwUBPN7r53w5zqzgtjVOFAPNjgP/dX6kgpVCSzo+OcVIYjkSD1GxvhG5XJg2
Z+GaPWdIWrX/tqfYW/OjP8KyIHJXKXY+faIlUcLHiAlfAJYBTMzecJxLJZSxbvAk
wvMOt9tki4EFlmGvrvCNs26j4wOWzmV0nEby7s5DJtWY+QKcx2aLFCrgA/k/0gMz
e9Ilf9o1ApYEAIPfaTCDgeR2Ki0xv/1F0W2V37f95yECF6dQdXSgTy8k2ZdCS+3l
pHJiMEHPlSvdPNTuqwIJ+dtjzj02RUbldjt6tsu7vmRatdX7MfL+WbuE0eSULhpy
GqW8SiVszaQ1AH/Ck3mioZ/Qh53jpMPmek95d+LJnqGSeulImmyBa8S9
=xzIa
-----END PGP SIGNATURE-----

--opJtzjQTFsWo+cga--


From request@logos.net  Mon May 13 07:11:02 2002
From: request@logos.net (request@logos.net)
Date: Mon May 13 06:11:02 2002
Subject: Verba Volant
Message-ID: <E1777dv-00057k-00@porta.u64.de>

13-MAY-02
We have been requested to insert the following email address, "gnupg-devel@gnupg.org", in the Verba Volant Newsletter database. Through this daily service you will receive a quotation, selected from amongst the most celebrated philosophers, writers and poets of all time and translated into many languages and dialects by volunteers worldwide.
If you would like to confirm your subscription to Verba Volant, please click on the following link: 
http://www.logos.net/owa-l/press.subscribe?lang=en&email=gnupg-devel@gnupg.org 
If you do not wish to click on the link, your subscription will be cancelled.
Thank you for your time.
Verba Volant



13-MAY-02
Il nous a été demandé d'ajouter l'adresse électronique "gnupg-devel@gnupg.org" dans la liste des destinataires de Verba Volant, un service qui tous les jours vous adressera une citation sélectionnée parmi les œuvres des meilleurs philosophes, écrivains, poètes de tous les temps et traduite en de très nombreuses langues grâce à des volontaires du monde entier.
Pour confirmer l'inscription à Verba Volant, veuillez vous connecter au lien suivant:
http://www.logos.net/owa-l/press.subscribe?lang=fr&email=gnupg-devel@gnupg.org 
Si vous préférez ne pas cliquer sur le lien, vous ne recevrez rien.

Merci dans tous les cas de nous avoir accordé quelques secondes.
Verba Volant



13-MAY-02
Se nos ha solicitado insertar la dirección de correo electrónico "gnupg-devel@gnupg.org" en el listado de envíos de Verba Volant, un servicio que diariamente le enviará citas elegidas entre los mejores filosofos, escritores, poetas, etc., traducidas a varios idiomas y dialectos. Dichas citas están traducidas por voluntarios que se conectan a nuestra web desde todo el mundo.
Si quiere confirmar la suscripción a Verba Volant, le rogamos entre en: 
http://www.logos.net/owa-l/press.subscribe?lang=es&email=gnupg-devel@gnupg.org 
Si no entra en la dirección señalada no recibirá las citas.
Muchas gracias por el tiempo que nos ha dedicado.
Verba Volant



13-MAY-02
Ci è stato chiesto di inserire l'indirizzo di posta elettronica "gnupg-devel@gnupg.org" nell’elenco dei destinatari di Verba Volant, un servizio che ogni giorno ti invierà una citazione scelta tra quelle dei migliori filosofi, scrittori, poeti di tutti i tempi e tradotta in moltissime lingue e dialetti grazie alla collaborazione di volontari da tutto il mondo.
Se desideri confermare l'iscrizione, ti preghiamo di collegarti al seguente link:
http://www.logos.net/owa-l/press.subscribe?lang=it&email=gnupg-devel@gnupg.org 
Nel caso preferissi non cliccare sul link, non riceverai nulla. 

Grazie comunque per i secondi che ci hai dedicato.
Cordiali saluti.






From wk@gnupg.org  Mon May 13 10:17:07 2002
From: wk@gnupg.org (Werner Koch)
Date: Mon May 13 09:17:07 2002
Subject: [Administriva] MLs closed
Message-ID: <87wuu8tt1s.fsf@alberti.gnupg.de>

Hi!

I am getting annoyed of all the spam so I finally closed the mailing
lists.  From now on only subscribers are allowed to post.  Messages
from non-subscribers are held for approval but the chance that I find
time to actual approve a message is not very high.  Hopefully we don't
get too much spam with faked From addresses.

If someone wants to volunteer as a listmaster please drop me a note.

  Werner



From Fabian.Rodriguez@Toxik.com  Tue May 14 00:24:01 2002
From: Fabian.Rodriguez@Toxik.com (Toxik - Fabian Rodriguez)
Date: Mon May 13 23:24:01 2002
Subject: Verifying signatures via WWW interface
In-Reply-To: <F1024t5BD8wbVGkJmiW00014762@hotmail.com>
Message-ID: <MJEDILLCNFHIFGNJHDMGAELHDNAA.Fabian.Rodriguez@Toxik.com>

Hello,

I'd like to know if it's logical to offer to people to verify signatures of
short texts via a web interface. I'm trying to understand some other
applications of OpenPGP/gnupg.

I thought having public keys of the signers on a local keyring would be
enough but GPG sends these warnings after displaying date and author
information:

  Could not find a valid trust path to the key.  Let's see whether we
  can assign some missing owner trust values.

  No path leading to one of our keys found.

  gpg: WARNING: This key is not certified with a trusted signature!
  gpg:          There is no indication that the signature belongs to the
owner.
  gpg: Fingerprint: A6EF 1DF9 39CC 873C 5855  D7BA 93E0 2B96 73AE 57A0

Of course, we don't want to store a private key for this particular
application, what would be required to have a trust path ? The local keyring
only has public keys in this example.

Thanks for any information on this.

Fabián Rodríguez - Toxik Technologies, Inc.
www.toxik.com · (514) 528-6945 @221
OpenPGP: 0x5AF2A4D5




From dmitri@users.sourceforge.net  Tue May 14 00:41:02 2002
From: dmitri@users.sourceforge.net (Dmitri)
Date: Mon May 13 23:41:02 2002
Subject: Verifying signatures via WWW interface
In-Reply-To: <MJEDILLCNFHIFGNJHDMGAELHDNAA.Fabian.Rodriguez@Toxik.com>
References: <MJEDILLCNFHIFGNJHDMGAELHDNAA.Fabian.Rodriguez@Toxik.com>
Message-ID: <1021326141.10775.387.camel@usb.networkfab.com>

--=-gZHvrlblTtvpVcErg0oN
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Mon, 2002-05-13 at 14:22, Toxik - Fabian Rodriguez wrote:

> I'd like to know if it's logical to offer to people to verify signatures =
of
> short texts via a web interface.

As long as you don't mind sending your plaintext over the network, and
telling anyone who cares to sniff the traffic what messages and who
receives, and from who, and when...

> I thought having public keys of the signers on a local keyring would be
> enough but GPG sends these warnings after displaying date and author
> information:
>=20
>   Could not find a valid trust path to the key.  Let's see whether we
>   can assign some missing owner trust values.
>=20
>   No path leading to one of our keys found.
>=20
>   gpg: WARNING: This key is not certified with a trusted signature!
>   gpg:          There is no indication that the signature belongs to the
> owner.

You need to sign the public key of that other person. It will tell GnuPG
that you believe that the key belongs to that person. You should find
more detailed explanations in many places, such as www.gnupg.org ...

Dmitri


--=-gZHvrlblTtvpVcErg0oN
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA84DM9XksyLpO6T4IRAmonAJ4vxm2ezpDKvIxCoQWIbMHdM/gvvgCeIy/K
Wy9CSIJMcJaEZIWAGLcvOqs=
=geGL
-----END PGP SIGNATURE-----

--=-gZHvrlblTtvpVcErg0oN--



From gnupg-devel@gnupg.org  Tue May 14 01:08:02 2002
From: gnupg-devel@gnupg.org (Matthew Byng-Maddick)
Date: Tue May 14 00:08:02 2002
Subject: Verifying signatures via WWW interface
In-Reply-To: <1021326141.10775.387.camel@usb.networkfab.com>; from dmitri@users.sourceforge.net on Mon, May 13, 2002 at 02:42:21PM -0700
References: <MJEDILLCNFHIFGNJHDMGAELHDNAA.Fabian.Rodriguez@Toxik.com> <1021326141.10775.387.camel@usb.networkfab.com>
Message-ID: <20020513230901.A26054@colon.colondot.net>

On Mon, May 13, 2002 at 02:42:21PM -0700, Dmitri wrote:
> On Mon, 2002-05-13 at 14:22, Toxik - Fabian Rodriguez wrote:
> > I'd like to know if it's logical to offer to people to verify signatures of
> > short texts via a web interface.
> As long as you don't mind sending your plaintext over the network, and
> telling anyone who cares to sniff the traffic what messages and who
> receives, and from who, and when...

This is less of an issue (since we're talking about verifying signatures,
it may well have come in in plaintext) than an ability to trust that the
website is not just telling you that a signature is verified, without
having bothered to do the calculation. Or alternatively telling you it
isn't when it might have done.

It's easier to verify that a binary on your disk hasn't been modified.

MBM

-- 
Matthew Byng-Maddick         <mbm@colondot.net>           http://colondot.net/


From lists@lina.inka.de  Tue May 14 01:24:02 2002
From: lists@lina.inka.de (Bernd Eckenfels)
Date: Tue May 14 00:24:02 2002
Subject: Verifying signatures via WWW interface
In-Reply-To: <MJEDILLCNFHIFGNJHDMGAELHDNAA.Fabian.Rodriguez@Toxik.com>
References: <F1024t5BD8wbVGkJmiW00014762@hotmail.com> <MJEDILLCNFHIFGNJHDMGAELHDNAA.Fabian.Rodriguez@Toxik.com>
Message-ID: <20020513222452.GA30503@lina.inka.de>

On Mon, May 13, 2002 at 05:22:01PM -0400, Toxik - Fabian Rodriguez wrote:
> Of course, we don't want to store a private key for this particular
> application, what would be required to have a trust path ? The local keyring
> only has public keys in this example.

You can eighter ignore the message or lsign all your keys in the keying with
a "trusted" key. you do not need to store the trusted key on the system, you
can mark a public key as trusted. this is used like this:

a) user sends you key, you verify it and sign it
b) you store the signed key on a automatic signature checking device. in
order to avoid to have to store your signature generating key on that device
you just place the public key there and mark it trusted. this has the
advantage (over blindly trusting al keys in keyring) that adding keys to the
keyring is not a priveledged application and does not need a trusted channel
to the verifier.

hope this is clear, i use this for a B2Bi Server which is able to check
incoming messages from trading partners and decides if they are known, based
on a "accept" lsign from operating staff. this even works with a keyserver.

Greetings
Bernd


From aphex@nullify.org  Wed May 15 00:45:07 2002
From: aphex@nullify.org (Keith Ray)
Date: Tue May 14 23:45:07 2002
Subject: GnuPG 1.0.7a+ DIRSEP
Message-ID: <1021412756.3ce185948636c@mail.nullify.org>

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

I have noticed that new DIRSEPs have been committed to the GnuPG 1.07a+
tree.  I would like to include them in a future win32 release, but I am
unsure about whether to change certain paths or not.

Currently, I use the following defaults:

[HKEY_CURRENT_USER\Control Panel\Mingw32\NLS]
"MODir"="C:/GnuPG/Locale"

[HKEY_CURRENT_USER\Software\GNU\GnuPG]
"HomeDir"="C:/GnuPG"

load-extension Lib/idea
load-extension Lib/tiger
load-extension Lib/sha2

Should all of these be changed from '/' to '\' in 1.0.7a+ versions?

  -- Keith

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (MingW32) - GPGshell v2.28

iD8DBQE84YQuBxrjkHkmmhIRAnpmAJ9NWRLU6zqvEVM99nfagGOk31xSTwCdEtoA
bt5GQF46qvVrfBhgVBCQCiI=
=xzfO
-----END PGP SIGNATURE-----


From aphex@nullify.org  Fri May 17 01:50:02 2002
From: aphex@nullify.org (Keith Ray)
Date: Fri May 17 00:50:02 2002
Subject: [BUG FIX] Win32 Performance Counters
Message-ID: <1021589460.3ce437d487922@mail.nullify.org>

In cipher/rndw32.c, GnuPG attempts to gather physical disk performance counter
data for random number generation.  However, if the IOCTL_DISK_PERFORMANCE call
fails for any reason, GPG displays:

"NOTE: you should run 'diskperf -y' to enable the disk statistics"

I created a debug version of GnuPG and called GetLastError() and got:

"The data area passed to a system call is too small."

I did some investigating and found that the Win32 header files from Mingw32/CPD
are incorrect.  Both the LARGE_INTEGER and DISK_PERFORMANCE struct are smaller
than required.  Once these changes were made, I was able to produce a working
GnuPG that successfully called IOCTL_DISK_PERFORMANCE.  However, GCC gave the
following warning:

In file included from
/usr/local/lib/mingw32-cpd/lib/gcc-lib/i386--mingw32/2.95.2wk20010117/../../../../i386--mingw32/include/windows.h:48,
                 from rndw32.c:69:
/usr/local/lib/mingw32-cpd/lib/gcc-lib/i386--mingw32/2.95.2wk20010117/../../../../i386--mingw32/include/Windows32/Structures.h:1080:
warning: unnamed struct/union that defines no instances


mingw32-cpd/i386--mingw32/include/Windows32/Structures.h
--------------------------------------------------------

typedef struct _LARGE_INTEGER {
  DWORD LowPart;
  LONG  HighPart;
} LARGE_INTEGER, *PLARGE_INTEGER;

typedef struct _DISK_PERFORMANCE {
  LARGE_INTEGER BytesRead;
  LARGE_INTEGER BytesWritten;
  LARGE_INTEGER ReadTime;
  LARGE_INTEGER WriteTime;
  DWORD ReadCount;
  DWORD WriteCount;
  DWORD QueueDepth;
} DISK_PERFORMANCE ;


Microsoft Platform SDK\Include\WinIoCtl.h
-----------------------------------------

typedef struct _DISK_PERFORMANCE {
        LARGE_INTEGER BytesRead;
        LARGE_INTEGER BytesWritten;
        LARGE_INTEGER ReadTime;
        LARGE_INTEGER WriteTime;
        LARGE_INTEGER IdleTime;
        DWORD ReadCount;
        DWORD WriteCount;
        DWORD QueueDepth;
        DWORD SplitCount;
        LARGE_INTEGER QueryTime;
        DWORD   StorageDeviceNumber;
        WCHAR   StorageManagerName[8];
} DISK_PERFORMANCE, *PDISK_PERFORMANCE;


Microsoft Platform SDK\Include\WinNT.h
--------------------------------------

typedef union _LARGE_INTEGER {
    struct {
        DWORD LowPart;
        LONG HighPart;
    };
    struct {
        DWORD LowPart;
        LONG HighPart;
    } u;
    LONGLONG QuadPart;
} LARGE_INTEGER;


From keith@nullify.org  Fri May 17 11:33:01 2002
From: keith@nullify.org (Keith Ray)
Date: Fri May 17 10:33:01 2002
Subject: GnuPG 1.0.7a+ DIRSEP
Message-ID: <1021412447.3ce1845f9a7bd@mail.nullify.org>

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

I have noticed that new DIRSEPs have been committed to the GnuPG 1.07a+
tree.  I would like to include them in a future win32 release, but I am
unsure about whether to change certain paths or not.

Currently, I use the following defaults:

[HKEY_CURRENT_USER\Control Panel\Mingw32\NLS]
"MODir"="C:/GnuPG/Locale"

[HKEY_CURRENT_USER\Software\GNU\GnuPG]
"HomeDir"="C:/GnuPG"

load-extension Lib/idea
load-extension Lib/tiger
load-extension Lib/sha2

Should all of these be changed from '/' to '\' in 1.0.7a+ versions?

  -- Keith

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (MingW32) - GPGshell v2.28

iD8DBQE84YQuBxrjkHkmmhIRAnpmAJ9NWRLU6zqvEVM99nfagGOk31xSTwCdEtoA
bt5GQF46qvVrfBhgVBCQCiI=
=xzfO
-----END PGP SIGNATURE-----


From chris@netservers.co.uk  Fri May 17 11:33:04 2002
From: chris@netservers.co.uk (Chris Wilson)
Date: Fri May 17 10:33:04 2002
Subject: Operation on read-only filesystem
Message-ID: <Pine.LNX.4.44.0205151157380.11907-200000@localhost>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

--8323328-471549807-1021460765=:11907
Content-Type: TEXT/PLAIN; charset=US-ASCII

Dear GnuPG developers,

I have been trying to get GnuPG working on a read-only filesystem, and I 
think I have hit the same problem as Patrick Higgins 
(http://lists.gnupg.org/pipermail/gnupg-devel/2000-July/005221.html), that 
the trust database is opened read-write. His suggestion of a --read-only 
option seems like a good one. If I wrote a patch to add this option, would 
anyone care to integrate it with GnuPG?

I have also been maintaining my batch-sign patch, and just updated it to 
GPG 1.0.7. This fixes what I believe to be a bug in GnuPG, that for no 
apparent reason, signing keys is disabled in batch-mode. The patch is very 
simple, and I hope you will consider applying it.

Cheers, Chris.
-- 
   ___ __     _
 / __// / ,__(_)_  | Chris Wilson -- UNIX Firewall Lead Developer |
/ (_ / ,\/ _/ /_ \ | NetServers.co.uk http://www.netservers.co.uk |
\ _//_/_/_//_/___/ | 21 Signet Court, Cambridge, UK. 01223 576516 |

--8323328-471549807-1021460765=:11907
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="gpg-batchsign-1.0.7.patch"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.44.0205151206050.11907@localhost>
Content-Description: 
Content-Disposition: attachment; filename="gpg-batchsign-1.0.7.patch"

ZGlmZiAtcnUyIGdudXBnLTEuMC43L2cxMC9rZXllZGl0LmMgZ251cGctMS4w
LjctY2hyaXMvZzEwL2tleWVkaXQuYw0KLS0tIGdudXBnLTEuMC43L2cxMC9r
ZXllZGl0LmMJTW9uIEFwciAyOSAxNTozNDoyMSAyMDAyDQorKysgZ251cGct
MS4wLjctY2hyaXMvZzEwL2tleWVkaXQuYwlXZWQgTWF5IDE1IDExOjUyOjMz
IDIwMDINCkBAIC04NzEsNCArODcxLDEyIEBADQogICAgIGludCBoYXZlX2Nv
bW1hbmRzID0gISFjb21tYW5kczsNCiANCisgICAgaWYoIHNpZ25fbW9kZSAp
IHsNCisgICAgICAgIGNvbW1hbmRzID0gTlVMTDsNCisgICAgICAgIGFwcGVu
ZF90b19zdHJsaXN0KCAmY29tbWFuZHMsIHNpZ25fbW9kZSA9PSAxPyAic2ln
biI6DQorICAgICAgICAgICAgICAgICAgICAgICAgICAgc2lnbl9tb2RlID09
IDI/ImxzaWduIjoNCisgICAgICAgICAgICAgICAgICAgICAgICAgICBzaWdu
X21vZGUgPT0gMz8ibnJzaWduIjoibnJsc2lnbiIpOw0KKyAgICAgICAgaGF2
ZV9jb21tYW5kcyA9IDE7DQorICAgIH0NCisNCiAgICAgaWYgKCBvcHQuY29t
bWFuZF9mZCAhPSAtMSApDQogICAgICAgICA7DQpAQCAtODc2LDEyICs4ODQs
NCBAQA0KIAlsb2dfZXJyb3IoXygiY2FuJ3QgZG8gdGhhdCBpbiBiYXRjaG1v
ZGVcbiIpKTsNCiAJZ290byBsZWF2ZTsNCi0gICAgfQ0KLQ0KLSAgICBpZigg
c2lnbl9tb2RlICkgew0KLQljb21tYW5kcyA9IE5VTEw7DQotCWFwcGVuZF90
b19zdHJsaXN0KCAmY29tbWFuZHMsIHNpZ25fbW9kZSA9PSAxPyAic2lnbiI6
DQotCQkJICAgc2lnbl9tb2RlID09IDI/ImxzaWduIjoNCi0JCQkgICBzaWdu
X21vZGUgPT0gMz8ibnJzaWduIjoibnJsc2lnbiIpOw0KLQloYXZlX2NvbW1h
bmRzID0gMTsNCiAgICAgfQ0KIA0K
--8323328-471549807-1021460765=:11907--


From andy.ozment@cc.gatech.edu  Fri May 17 11:33:06 2002
From: andy.ozment@cc.gatech.edu (Andy Ozment)
Date: Fri May 17 10:33:06 2002
Subject: Wrong signature on idea.c, broken link
Message-ID: <3CE2BF5E.C58AAD75@cc.gatech.edu>

I'm new to gpg, so I apologize if these "bugs" are really my ignorance
rather than a bug.

1. In an attempt to get the idea module, I went to the page
<http://www.gnupg.org/why-not-idea.html>

I downloaded the files idea.c and idea.c.sig. I then tried to check the
sig:
$ gpg --verify idea.c.sig idea.c
gpg: Warning: using insecure memory!
gpg: please see http://www.gnupg.org/faq.html for more information
gpg: Signature made Fri Aug 17 03:34:05 2001 EDT using DSA key ID
621CC013
gpg: Can't check signature: public key not found

$ gpg --list-keys
pub  1024D/57548DCD 1998-07-07 Werner Koch (gnupg sig) <dd9jn@gnu.org>

It appears to me, then, that idea.c was not signed with the key that
signed the entire distribution (57548DCD, Werner Koch). Is this
intentional? I could not find the key that did sign the file anywhere on
the site.



2. On a completely different note, on the page
<http://www.gnupg.org/docs.html>, the link "list of bugs" which points
to <http://bugs.guug.de/Bugs/db/pa/lgnupg.html> is broken.


Please copy any responses to me, as I am not a member of this list.
Again, if this is not really a mistake and is just me being dumb, then I
apologize for being an annoying newbie!
Thanks!
Andy

-- 
  Andy Ozment
  Research Scientist
  Georgia Tech College of Computing


From avbidder@fortytwo.ch  Fri May 17 18:16:01 2002
From: avbidder@fortytwo.ch (Adrian 'Dagurashibanipal' von Bidder)
Date: Fri May 17 17:16:01 2002
Subject: secure sign & encrypt
Message-ID: <1021648640.7790.33.camel@atlas>

--=-ivbC0F0YEu2PvLP9b4+Z
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Yo!

After having read the paper refernced in the ongoing 'signing &
encrypting' thread on gpg-users

http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html

I feel that these flaws are quite serious, as non-experts (like me)
almost automatically assume end-to-end security if they receive
encrypted mail. I'm not on this list very long, so I didn't get previous
discussions of this (are theare *searchable* archives?)

How about this extension of the openPGP standard:

the signature (openpgp-)packet of a signed & encrypted msg includes an
additional (signed!!!) subpacket of the new type 'intended encryption
key'. when gpg is told to verify a message and finds such a subpacket,
it prints an error message if=20
 - the message is not encrypted
 - the message is encrypted, but not with the intended key.
conventional signed & encrypted msgs produce a warning along the lines
of 'it can not be asserted that this message was encrypted by the
original sender. See <URL> for more information'.

(Of course, more than one 'intended encryption key' subpackets must be
allowed)

Yes, this is not rfc - but I got the impression that the gpg people are
not against extending the standard if there are valid reasons (cf.
picture id)


And while I'm at it (though this is tangential here, I know):

extension to the OpenPGP-MIME RFC 3156: Add the To:, From: and Subject:
headers of the mail to the (signed) MIME headers of multipart/signed
msgs and bug the mailreader people to verify the mail headers with
these.



comments?
-- vbi


--=20
secure email with gpg                 avbidder@fortytwo.ch: key id
0x92082481
                                      avbidder@acter.ch:    key id
0x5E4B731F


--=-ivbC0F0YEu2PvLP9b4+Z
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA85R8Awj49sl5Lcx8RAoCrAJ4gCplIzL9U8Y4AAaQ7frEEQ2jCDwCeIwRY
W/I1c7oXs6zxmSt0mlGzGJw=
=TqKC
-----END PGP SIGNATURE-----

--=-ivbC0F0YEu2PvLP9b4+Z--


From jharris@widomaker.com  Fri May 17 21:10:02 2002
From: jharris@widomaker.com (Jason Harris)
Date: Fri May 17 20:10:02 2002
Subject: Wrong signature on idea.c, broken link
In-Reply-To: <3CE2BF5E.C58AAD75@cc.gatech.edu>
References: <3CE2BF5E.C58AAD75@cc.gatech.edu>
Message-ID: <20020517181046.GA317@p5.widomaker.com>

--FL5UXtIhxfXey3p5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, May 15, 2002 at 04:04:46PM -0400, Andy Ozment wrote:

> I'm new to gpg, so I apologize if these "bugs" are really my ignorance
> rather than a bug.

You've been using (commercial) PGP all this time?  :(

> 1. In an attempt to get the idea module, I went to the page
> <http://www.gnupg.org/why-not-idea.html>
>=20
> I downloaded the files idea.c and idea.c.sig. I then tried to check the
> sig:
> $ gpg --verify idea.c.sig idea.c
> gpg: Warning: using insecure memory!
> gpg: please see http://www.gnupg.org/faq.html for more information
> gpg: Signature made Fri Aug 17 03:34:05 2001 EDT using DSA key ID
> 621CC013
> gpg: Can't check signature: public key not found
>=20
> $ gpg --list-keys
> pub  1024D/57548DCD 1998-07-07 Werner Koch (gnupg sig) <dd9jn@gnu.org>
>=20
> It appears to me, then, that idea.c was not signed with the key that
> signed the entire distribution (57548DCD, Werner Koch). Is this
> intentional? I could not find the key that did sign the file anywhere on
> the site.

Use the keyservers, Luke!

(However, it doesn't look like Werner has cross-signed all his keys...)

pub  1024D/621CC013 1998-07-07 Werner Koch <werner.koch@guug.de>
     Key fingerprint =3D ECAF 7590 EB34 43B5 C7CF  3ACB 6C7E E1B8 621C C013
sig?       FF3EAA0B 1998-07-07  [User id not found]
sig        0C9857A5 1998-07-08  Werner Koch <werner.koch@guug.de>
sig        9265FAFB 2001-11-03  Derek Gaston <dgaston@umr.edu>
sig        513AEFD9 2000-09-25  Hans-Joerg Hoexer <hshoexer@rommel.stw.uni-=
erlangen.de>
sig        82957B66 2000-07-11  Hideki Saito <hideki@allcity.net>
sig        C5E88112 2000-02-22  Ruediger Hahn <ruedi007@topmail.de>
sig        5B0358A2 1999-03-15  Werner Koch <wk@gnupg.org>
sig        B1CC03AA 1999-06-21  Javier Kohen <jkohen@tough.com>
sig        621CC013 1999-11-12  Werner Koch <werner.koch@guug.de>
uid                            Werner Koch <wk@gnupg.org>
sig        5B0358A2 2000-10-01  Werner Koch <wk@gnupg.org>
sig        621CC013 2000-11-21  Werner Koch <werner.koch@guug.de>
uid                            Werner Koch <wk@openit.de>
sig        513AEFD9 2000-09-25  Hans-Joerg Hoexer <hshoexer@rommel.stw.uni-=
erlangen.de>
sig        82957B66 2000-07-11  Hideki Saito <hideki@allcity.net>
sig        621CC013 2000-11-21  Werner Koch <werner.koch@guug.de>
sig        90F89A7D 2001-01-25  Ralf Hildebrandt <ralf.hildebrandt@innomina=
te.com>

--=20
Jason Harris          | NIC:  JH329, PGP:  This _is_ PGP-signed, isn't it?
jharris@widomaker.com | web:  http://jharris.cjb.net/

--FL5UXtIhxfXey3p5
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (FreeBSD)

iD8DBQE85UekSypIl9OdoOMRAlGUAJ9owXz90w6Gyif3eh05r4UKYyW9aACfV631
KtD2tVaXe1WTcNKy1ha40xs=
=0YDU
-----END PGP SIGNATURE-----

--FL5UXtIhxfXey3p5--


From Max V. Zinal" <Zlat0@mail.ru  Mon May 20 20:14:01 2002
From: Max V. Zinal" <Zlat0@mail.ru (Max V. Zinal)
Date: Mon May 20 19:14:01 2002
Subject: A modified version of GnuPG
Message-ID: <16924836432.20020518205413@mail.ru>

------------144917F14ED878C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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

Hello everyone, have a nice time of day.

I've  made  some  changes to GnuPG 1.0.7, so now I have a version
built  under  MS  Windows with MS Visual C++ 6.0 compiler, linked
together  with zlib 1.1.4, and having support for *secure memory*
under  Windows.  I  did  my best to ensure that my changes do not
break any existing code under any ever-used platform.

I  think that this changes can be useful for project maintainers,
so they could include all this stuff into the future release.

I  would  like to know, are the project maintainers interested in
getting  my alterations, and if the answer is 'YES', how should I
send these alterations for them.

To show that my modified GPG works, I sign this message with it.
My public key is attached in a file.

- --
Best regards,
 Max                          mailto:zinal0@gibinsoft.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7a (x86-winnt)

iD8DBQE85ocj4scuxnLoWOARAnu0AJsGqiLj/iq6TOKevDG8vXsdI14aXwCfUdvz
ocu0KiQ5mnUBA5KU3ZI9T60=
=f9Ts
-----END PGP SIGNATURE-----
------------144917F14ED878C
Content-Type: application/octet-stream; name="MaxZinal.gpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="MaxZinal.gpg"

LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tDQpWZXJzaW9uOiBHbnVQRyB2MS4w
LjcgKE1pY3Jvc29mdCBXaW5kb3plKQ0KDQptUUdpQkR6amxJMFJCQURlYUdGRk9reUJLVmhZc0I4
ZklDam1OZnpDTFBRVC8xYjRIZ0hiWnFUZURaWXhSamJRDQpUbmJhVnExa2dFQjFNSmJ0MDB6Kys5
aDNPTEdKOGZteDBKRGpNa1hWRlFQaEliejJXSUY4UHNwS1M4aWY4bmc4DQpPRFR0VDIySmJ3Q1BE
WWxKWmRFdVU5RHdPdllQRm1VMXZNRFZiRGRDd0RCZlo2OExUbWt2eXZsYlN3Q2c2U2FpDQpFMVU1
NEFFRzJGQ1VXQUpjbVQveTlBVUQvMWVtQ3d1eFN5TU8xeno2ZkcxR2p3L3BpbkN3cnhmbjVmS3dX
TFBDDQpMbmRjQ3o3MWxoRDdkQjdwV01CUTNSUFpPeWlLQkV4OFlYZkJXdytQSDJvWTE4Z0ZQY2ti
dVdNTmJzSGdlN0N0DQpScnM4UnFBd1lsRmtQdmpzbTQzdElSV1BvTE44eWF1UmdSY1grYWpOVC84
ZzdXRU9WcnhJcGp2b0tTMUt1bzlrDQpOYjE1QS85Y1dXYTM5RDFoc3hjc1VRVENpZUdNNnJyMkpB
MDJBTk1aVC94MVZDeTdoN3VpenJEVDBRWkdrb2VFDQpHYkRUd3pGNU9Kd3A0UzZlOEhKWFRFSmJ0
UnBTQW1kQXI1RisyRUo2R1JMYi9BRmVBQi9sbnRVQWxCdGI3UjA5DQpEZ0Qrek9MM01rQW12eEdt
WWZtZ0ZKdm9wbE83VUVRbVVySzNTZ29CcHAvNmJvOXZaN1FpVFdGNElGWXVJRnBwDQpibUZzSUR4
NmFXNWhiRUJuYVdKcGJuTnZablF1Ym1WMFBvaFpCQk1SQWdBWkJRSTg0NVNOQkFzSEF3SURGUUlE
DQpBeFlDQVFJZUFRSVhnQUFLQ1JEaXh5N0djdWhZNEN4WkFKd0x3bjhuUzNiWUIyN1BQTWtoY3lE
OVF1WVRtQUNnDQpnTE9TcUxXblhoK2U4NTJtTmxOaXd5SFQ2RmE1QVkwRVBPT1ZtQkFHQU1FTm82
T1RYTVhKVDlic1NKNld4bjJkDQo2dHZrNXl6R25wUWMrOFc0MDhtMkg0QjRZcUhMVlY4ZVhoSDF1
UVBReFVpUnJnc3ZxZzhzZ0Ryd0owQjBlZGVXDQoyVmE0MDdMWXR2Q1JnWDlHVHpua24wUWl5VEYr
RlQvbU9iMkExV2JHQWN1MmF3dk9IaXFXWkJIN3gxMTFXbStNDQpLSldNbS9jU1FRNTl3MFJTWUJ4
TzFEb3Z6NzZBQVpYcW1jUjJxODZMQktQb2U1dFFDVmEyUHV3aXE1ZUlVVFlDDQoyV2E4cWVRT1p1
QXNRZUNZaUlNTENrWUMvNEt6d0dtYnNtN2ZrYVlteHdBREJRWUFoM1ArdWkrdnpVSXRDenFpDQpt
WDkyVkIrNUdlazdhY2UyMmRNYTF4cWswRVF3YVQzZlhOYVB3Y3BXTlQwbGN1dTNrTVowMVVXek1C
WFZUUUcxDQpOblFMdERWaGc2RUVmMDZJN3VHU09tR3ZvNjg2UTk1SmsycFlYTVVPSG1Eb1lubnY0
TnpQSkVLaHlLT2liK3lsDQpZMWpHeUZrKzFNN1VVL0x5K3VLbHB6bGgxbFJXV0pwdDhMRTluNXhi
Sml2aWk1Yk5XQW90RVJCbVVYaTRqUWZRDQpqWlB3aFRld01Ic24yMlBMUmRDM3ZJTXc5dHhNSzR0
V0c4ZHBSekszK1hkRFZKYVJpRVlFR0JFQ0FBWUZBanpqDQpsWmdBQ2drUTRzY3V4bkxvV09DS01n
Q1pBVGFoWTRLTXV4dEkrZlZKYk9RNllsYXFOcmdBb0tLaVdQRGxQN1N1DQpZb0E1QWZvQzlqbncx
R0xsDQo9dHh0cA0KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxPQ0stLS0tLQ0K

------------144917F14ED878C--



From 21442@gmx.net  Mon May 20 20:14:04 2002
From: 21442@gmx.net (Jure)
Date: Mon May 20 19:14:04 2002
Subject: Symmetric encription in batch mode
Message-ID: <3CE6C692.F61D9523@gmx.net>

> On Thu Jan 03 2002; 22:00, Bernard wrote:
> 
> IMO, you can send the data with the passphrase at the begin like this:
> "stupid_passphrase\n"
> "raw/text data"
> 
> I used this style in early code of WinPT and it seems to work. It's
> only important that you add a '\n' to the end because gpg expected
> one line for the passphrase.
> 
> 
> There is another way you can choose for sending the passphrase down
> to gpg. With the --command-fd switch you can control all gpg input.
> In the case gpg needs a passphrase the --status-fd output is:
> [GNUPG:] GET_HIDDEN passphrase.enter
> and then you can send the data with the pipe. I know this way is
> more complicated because you need two additional pipes (status,
> command) but it's the tidiest way.

I came across exactly the same problem: how to pass the passphrase to
gnupg when doing symmetric encryption/decryption from a Java program. In
my program, I am trying to do something like this:

encrypt(InputStream plainText, OutputStream cipherText, String password);

(For example, suppose that a stream coming from one network connection has
to be encrypted and send to other network connection). To accomplish this,
I would like gpg.exe to read plainText from stdin and write output to
stdout. Using --passphrase-fd to specify passphrase presents two problems:

1. how to separate passphrase from data (prepending passphrase + '\n' is a
rather inelegant and possibly dangerous approach)

2. it simply doesn't work - although my program pipes the entire stream
(passphrase + '\n' + data) to gpg's input and receives something which
appears to be the gpg's header - that's where gpg hangs. I suppose this is
an issue of file descriptors (either due to a problem in OS, Java process
implementation, or a gpg's way of handling descriptors).

Realizing security issues, I am nevertheless convinced that the ease of
GnuPG reading the passphrase from an environment variable would greatly
outweight many problems that users (including me) who would like to embed
GnuPG in their own solutions, are confronted with, and are now forced to
invent problematic workarounds like the use of batch files.

So, how about supporting an environment variable (e.g. GPG_PASSPHRASE),
just like PGP does? Of course, a warning should be included wherever it
appears throughout documentation.

Forgive me if this has already been discussed - I did not find any trace
of it.

Jure


From emil@la.mine.nu  Mon May 20 20:14:06 2002
From: emil@la.mine.nu (Emil)
Date: Mon May 20 19:14:06 2002
Subject: --no-tty
Message-ID: <20020519095449.GA19764@localhost>

# gpg --version
gpg (GnuPG) 1.0.7

# gpg --no-tty --batch --cipher-algo IDEA -r emil -r emil -ea play.lst
gpg: emil: skipped: public key already present
gpg: this cipher algorithm is deprecated; please use a more standard one!

Isn't --no-tty supposed to mean _NO_ tty whatsoever ?

-- 
								Regards,
								Emil
--
"To be or not to be"	  -Shakespeare
"To do is to be"	  -Socrates
"To be is to do"	  -Sartre
"To be do be do"	  -Sinatra


From kokhong@post1.com  Mon May 20 20:14:07 2002
From: kokhong@post1.com (Soh Kok Hong)
Date: Mon May 20 19:14:07 2002
Subject: GnuPG for Win32
Message-ID: <3CE879E5.4060200@post1.com>

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

Dear all,

I have a 68-line diff file to patch the stock gnupg-1.0.7.tar.gz to
build a mingw32 executable in the standard cygwin environment.  It
mainly patches the configure scripts and one source file (rndw32.c).  I
would like to know if the gnupg maintainers are interested and to whom
can I email the patch to?

Please email to me directly as I am not on the list.


- --
*************************************************
Soh Kok Hong

kokhong@post1.com PGP Signature:
D18B FC65 2202 3E43 A2D3 90D2 7BCC ABD3 77CE CD1C
*************************************************
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE86Hnle8yr03fOzRwRAn8EAKDHTgi8snN8aBTtUGMzb1N92/h78gCg/esk
EWCm1xQ2nO7Nd3VsJ+HRn90=
=c2w+
-----END PGP SIGNATURE-----



From pgut001@cs.auckland.ac.nz  Tue May 21 07:21:01 2002
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
Date: Tue May 21 06:21:01 2002
Subject: A modified version of GnuPG
Message-ID: <200205210421.QAA220469@ruru.cs.auckland.ac.nz>

"Max V. Zinal" <Zlat0@mail.ru> writes:

>I've made some changes to GnuPG 1.0.7, so now I have a version built under MS
>Windows with MS Visual C++ 6.0 compiler, linked together with zlib 1.1.4, and
>having support for *secure memory* under Windows.

Could you explain what you mean by "secure memory"?  There are a variety of
interpretations possible, some erroneous (in general the term "secure memory"
is an oxymoron in an OS which has functions like VirtualProtect() and
ReadProcessMemory(), so a bit more detail would be useful).

Peter.


From wk@gnupg.org  Tue May 21 10:16:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Tue May 21 09:16:01 2002
Subject: --no-tty
In-Reply-To: <20020519095449.GA19764@localhost> (Emil's message of "Sun, 19
 May 2002 05:54:49 -0400")
References: <20020519095449.GA19764@localhost>
Message-ID: <87u1p2rmrh.fsf@alberti.gnupg.de>

On Sun, 19 May 2002 05:54:49 -0400, Emil  said:

> Isn't --no-tty supposed to mean _NO_ tty whatsoever ?

No, it does only make sure never to write to the tty directly (i.e. it
does not open /dev/tty).  The tty may be required to ask for a
passphrase even when stderr has been redirected.  Avoiding all
informational output is done by redirecting stderr to /dev/zero

  Werner



From wk@gnupg.org  Tue May 21 10:22:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Tue May 21 09:22:01 2002
Subject: GnuPG for Win32
In-Reply-To: <3CE879E5.4060200@post1.com> (Soh Kok Hong's message of "Mon,
 20 May 2002 12:21:57 +0800")
References: <3CE879E5.4060200@post1.com>
Message-ID: <87offarmid.fsf@alberti.gnupg.de>

On Mon, 20 May 2002 12:21:57 +0800, Soh Kok Hong said:

> I have a 68-line diff file to patch the stock gnupg-1.0.7.tar.gz to
> build a mingw32 executable in the standard cygwin environment.  It

Thanks but it does not make sense to use this because GnuPG builds
fine as a native Windows program.  The Cygwin32 version may lead not
serious interoperabilty problems when used by other programs expecting
a plain Windows binary.

Yes, I know there is some stuff in GnuPG to allow building under
Cygwin but this already makes the code more complex and error prone,
so it is not really maintained anymore.

  Werner



From dbely@mail.ru  Tue May 21 10:54:01 2002
From: dbely@mail.ru (Dmitry Bely)
Date: Tue May 21 09:54:01 2002
Subject: GnuPG for Win32
In-Reply-To: <87offarmid.fsf@alberti.gnupg.de> (Werner Koch's message of
 "Tue, 21 May 2002 09:24:58 +0200")
References: <3CE879E5.4060200@post1.com> <87offarmid.fsf@alberti.gnupg.de>
Message-ID: <ptzqaqit.fsf@mail.ru>

Werner Koch <wk@gnupg.org> writes:

>> I have a 68-line diff file to patch the stock gnupg-1.0.7.tar.gz to
>> build a mingw32 executable in the standard cygwin environment.  It
>
> Thanks but it does not make sense to use this because GnuPG builds
> fine as a native Windows program.  The Cygwin32 version may lead not
> serious interoperabilty problems when used by other programs expecting
> a plain Windows binary.

Where have you seen a Cygwin32 version? He was talking about the patches
that would let building Mingw32 version with the native Win32 tools
(Mingw32 compiler is included into Cygwin distribution). The fact that
Mingw version of GnuPG cannot be build under Windows out-of-the-box (and so
Windows users cannot participate in its debugging/development) looks
strange to me if not to say more...

Hope to hear from you soon,
Dmitry




From avbidder@fortytwo.ch  Tue May 21 11:24:02 2002
From: avbidder@fortytwo.ch (Adrian 'Dagurashibanipal' von Bidder)
Date: Tue May 21 10:24:02 2002
Subject: secure sign & encrypt
In-Reply-To: <200205171138.51248.rjhansen@inav.net>
References: <1021648640.7790.33.camel@atlas>
 <200205171138.51248.rjhansen@inav.net>
Message-ID: <1021969508.14022.39.camel@atlas>

--=-qlPInynfxfswG9+89RgT
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Fri, 2002-05-17 at 18:38, Robert J. Hansen wrote:

> Davis' `exploit' (in 1.1) basically boils down to this: if you can't trus=
t=20
> the person you're talking to, then the person you're talking to can use=20
> your words in ways you don't like.  Is that a problem?  Sure.  But it's a=
=20
> social problem, not a technological one.  It demands social solutions, no=
t=20
> different cryptographic standards.

Agreed that the exploit is not really technological. The programs do
exactly as told. From the senders point of view I agree fully to what
you say. BUT if somebody receives an encrypted message he will almost
always automatically assume secure end to end communication - which may
not be the case. The open question is basically if the user should be
educated that the software does not work the way they think (hard, I
think), or if the software should be modified to match the users
(reasonable, imho) expectations.

--=20
secure email with gpg                 avbidder@fortytwo.ch: key id
0x92082481
                                      avbidder@acter.ch:    key id
0x5E4B731F


--=-qlPInynfxfswG9+89RgT
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA86gRkwj49sl5Lcx8RApkTAJwKz0M8/q3Mdmdq0ngygNQG9lufTACgkISh
l9dTJC2VTYbGUjjoc4NXVWE=
=oE4v
-----END PGP SIGNATURE-----

--=-qlPInynfxfswG9+89RgT--



From m-lesser@better-com.de  Tue May 21 16:59:02 2002
From: m-lesser@better-com.de (Martin Lesser)
Date: Tue May 21 15:59:02 2002
Subject: Error or feature in g10.c?
Message-ID: <87ptzpsisz.fsf@nb-acer.better-com.de>

After updating from 1.0.6 to 1.0.7 we ran into problems with an app
which uses --run-as-shm-coprocess (gabber, see also
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=146740 )

I know that use of shm-routines in gnupg is deprecated and should be
replaced with --command-fd.

Since rev. 1.129.2.82 of g10.c there's an
  #undef USE_SHM_COPROCESSING
which in the current version is additionally commented with "huh ?"

What's the reason for inserting this #undef (especially at this point)?
In the archives I could not find any hint.

Commenting out this line solved the problem with gabber but I'm not sure
wether this is correct. IMO it is possible that other apps also make use
of the shm-routines. If so they could run into problems too.

Martin


From wk@gnupg.org  Tue May 21 19:50:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Tue May 21 18:50:01 2002
Subject: Error or feature in g10.c?
In-Reply-To: <87ptzpsisz.fsf@nb-acer.better-com.de> (Martin Lesser's message
 of "21 May 2002 15:59:40 +0200")
References: <87ptzpsisz.fsf@nb-acer.better-com.de>
Message-ID: <87d6vpqw67.fsf@alberti.gnupg.de>

On 21 May 2002 15:59:40 +0200, Martin Lesser said:

> What's the reason for inserting this #undef (especially at this point)?
> In the archives I could not find any hint.

Fixed:

  * g10.c (main): Removed the undef of USE_SHM_COPROCESSING which
  was erroneously introduced on 2002-01-09.

> Commenting out this line solved the problem with gabber but I'm not sure
> wether this is correct. IMO it is possible that other apps also make use

It is.

Thanks,

  Werner



From Max V. Zinal" <Zlat0@mail.ru  Tue May 21 20:40:01 2002
From: Max V. Zinal" <Zlat0@mail.ru (Max V. Zinal)
Date: Tue May 21 19:40:01 2002
Subject: Re[2]: A modified version of GnuPG
In-Reply-To: <200205210421.QAA220469@ruru.cs.auckland.ac.nz>
References: <200205210421.QAA220469@ruru.cs.auckland.ac.nz>
Message-ID: <1387186383.20020521213928@mail.ru>

Tuesday, May 21, 2002, 8:21:18 AM, Peter Gutmann wrote:

PG> Could you explain what you mean by "secure memory"?  There are a variety of
PG> interpretations possible, some erroneous (in general the term "secure memory"
PG> is an oxymoron in an OS which has functions like VirtualProtect() and
PG> ReadProcessMemory(), so a bit more detail would be useful).

When I said "secure memory" I was going to say "VirtualLock under
Windows  NT/2000/XP",  which keeps you absolutely safe unless you
have  a  Terminal  Server  with  an  evil-minded admin, or remote
desktop    connection    with    'Debug' privileges.

As  you  know,  most  of  old  and modern OSes have no protection
against  a  person that has administrative rights. Linux, Windows
or  something  else  -  'a  good admin means a long life'. Any OS
which  allows a programmer to use debug facility may be unsecure.
Of  course,  if  we  are  talking about Win9x/ME (which should be
called  'Mustdie  Edition',  I  think), even with VirtualLock you
cannot be absolutely shure.

I have e-mailed my modifications to
        Timo Schulz <twoaday@freakmail.de>
who said he would like to receive them.

Sorry for unexcellent English.

-- 
Best regards,
 Max V. Zinal



From wk@gnupg.org  Wed May 22 10:04:02 2002
From: wk@gnupg.org (Werner Koch)
Date: Wed May 22 09:04:02 2002
Subject: A modified version of GnuPG
In-Reply-To: <1387186383.20020521213928@mail.ru> ("Max V. Zinal"'s message
 of "Tue, 21 May 2002 21:39:28 +0400")
References: <200205210421.QAA220469@ruru.cs.auckland.ac.nz>
 <1387186383.20020521213928@mail.ru>
Message-ID: <878z6cpso2.fsf@alberti.gnupg.de>

On Tue, 21 May 2002 21:39:28 +0400, Max V Zinal said:

> When I said "secure memory" I was going to say "VirtualLock under
> Windows  NT/2000/XP",  which keeps you absolutely safe unless you

I guess you didn't read Peter's papers on this.  VirtualLock is not
suitable for this.  The only way to protect memory from swapping is by
allocating it with the device helper functions:  An ISR may need
memory buffers and these buffers should never be subject to any paging
- the pager may need the service of that ISR - this is the reason why
you are able to allocate non-pageable memory for a device driver.

When GnuPG talks about "secure memory" it actually means "non-pageable
memory".  There can't be any protection against an almighty
admin/root/superuser.

  Werner



From avbidder@fortytwo.ch  Wed May 22 10:50:02 2002
From: avbidder@fortytwo.ch (Adrian 'Dagurashibanipal' von Bidder)
Date: Wed May 22 09:50:02 2002
Subject: secure sign & encrypt
In-Reply-To: <200205211132.09336.rjhansen@inav.net>
References: <1021648640.7790.33.camel@atlas>
 <200205171138.51248.rjhansen@inav.net> <1021969508.14022.39.camel@atlas>
 <200205211132.09336.rjhansen@inav.net>
Message-ID: <1022053889.12048.32.camel@atlas>

--=-Z8G8Y2477TfMVHktYfb7
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Tue, 2002-05-21 at 18:32, Robert J. Hansen wrote:
> > not be the case. The open question is basically if the user should be
> > educated that the software does not work the way they think (hard, I
> > think), or if the software should be modified to match the users
> > (reasonable, imho) expectations.
>=20
> "To every sociological problem there exists a technological solution whic=
h=20
> is cheap, easy, and wrong."
>=20

Why do locks exist, then? The existence of thieves is a purely
sociological problem, after all, and so one should not try to solve it
with technological means.

I agree it'd be breaking (I'd call it extending, but call it what you
want). But I argue that it's just automating a task the user presently
has to do manually.

Currently, to get secure, authenticated end-to-end encryption with gpg,
the sender has to sign/encrypt/sign, which presently requires at least 2
gpg invocations, and the recipient has to manually verify that the inner
and the outer signature match.=20

What I propose does basically just automate this task. It might do so by
literally sign/encrypt/sign, or by encrypt/sign[intended ecryption
keys|msg] (cf my proposal) - it's not the issue which of the two is
happening, though I believe the latter to be more elegant.=20

And I want to stress again that having an end-to-end encrypted channel
is imho a fairly basic requirement of a cryptosystem and is what the
average user is probably expecting to have if he is at the receiving end
of an encrypted channel.

cheers
-- vbi

--=20
secure email with gpg                 avbidder@fortytwo.ch: key id
0x92082481
                                      avbidder@acter.ch:    key id
0x5E4B731F


--=-Z8G8Y2477TfMVHktYfb7
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA8604Bwj49sl5Lcx8RAtmNAJ0fYD5r7s1hlNj5Ve5QMuQHDrCpxgCfetUz
px4yEN6v/VMxgFItAF31nrU=
=q7bS
-----END PGP SIGNATURE-----

--=-Z8G8Y2477TfMVHktYfb7--



From roconnor@Math.Berkeley.EDU  Wed May 22 11:03:01 2002
From: roconnor@Math.Berkeley.EDU (Russell O'Connor)
Date: Wed May 22 10:03:01 2002
Subject: strncasecmp
Message-ID: <Pine.SOL.4.33.0205220100420.17494-100000@blue3.math.berkeley.edu>

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

I was building Gnupg 1.0.7 for OS/2 and I had to manually add strncasecmp
to util/strutil.c

This probably should be added to the source files, along with the
appropriate changes to configure.

- -- 
Russell O'Connor                           roconnor@math.berkeley.edu
           <http://www.math.berkeley.edu/~roconnor/>
``Later generations will regard set theory as a disease from which one
has recovered.'' -- Poincare
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (SunOS)
Comment: For info see http://www.gnupg.org

iD8DBQE861EKuZUa0PWVyWQRAlAwAJ9o5ilHoWGp6xdYXnEZy3CqRRPMpQCfREAn
HWL5wUGr+X+QK4zSe1lucts=
=UqVR
-----END PGP SIGNATURE-----



From apm35@student.open.ac.uk  Wed May 22 11:32:01 2002
From: apm35@student.open.ac.uk (Andrew Marlow)
Date: Wed May 22 10:32:01 2002
Subject: strncasecmp
In-Reply-To: <Pine.SOL.4.33.0205220100420.17494-100000@blue3.math.berkeley.edu>
References: <Pine.SOL.4.33.0205220100420.17494-100000@blue3.math.berkeley.edu>
Message-ID: <fc.004c540101aa85a33b9aca0013090653.1aa85d3@oufcnt2.open.ac.uk>

roconnor@math.berkeley.edu writes:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>I was building Gnupg 1.0.7 for OS/2 and I had to manually add strncasecmp
>to util/strutil.c
>
>This probably should be added to the source files, along with the
>appropriate changes to configure.

I disagree.
Some environments have strncasecmp and others don't. I usually define my
own version of strncasecmp and the implementation differs from environment
to environment. Where I can implement it in terms of strncasecmp I do so,
otherwise I hand-code it. No direct calls to strncasecmp appear in the
code since it is a portability issue.

Regards,

Andrew M.



From sbellon@sbellon.de  Wed May 22 11:33:01 2002
From: sbellon@sbellon.de (Stefan Bellon)
Date: Wed May 22 10:33:01 2002
Subject: strncasecmp
In-Reply-To: <Pine.SOL.4.33.0205220100420.17494-100000@blue3.math.berkeley.edu>
References: <Pine.SOL.4.33.0205220100420.17494-100000@blue3.math.berkeley.edu>
Message-ID: <4b3a87c92bsbellon@sbellon.de>

Russell O'Connor wrote:
> I was building Gnupg 1.0.7 for OS/2 and I had to manually add
> strncasecmp to util/strutil.c

I think I fixed that two days after the 1.0.7 release:

2002-05-10  Stefan Bellon  <sbellon@sbellon.de>

        * g10.c, hkp.c, keyedit.c, keyserver.c: Replaced all occurrances
        of strcasecmp with ascii_strcasecmp and all occurrances of
        strncasecmp with ascii_memcasecmp.

So, neither strcasecmp nor strncasecmp is necessary anymore. Perhaps
you could try with a CVS build again?

Greetings,

Stefan.

-- 
 Stefan Bellon * <mailto:sbellon@sbellon.de> * <http://www.sbellon.de/>
 PGP 2 and OpenPGP keys available from my home page

 We have commited to quickly disseminate high-quality leadership skills
 and collaboratively restore low-risk high-yield meta-services to meet
 our customers needs.


From wk@gnupg.org  Wed May 22 11:36:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Wed May 22 10:36:01 2002
Subject: strncasecmp
In-Reply-To: <Pine.SOL.4.33.0205220100420.17494-100000@blue3.math.berkeley.edu> ("Russell
 O'Connor"'s message of "Wed, 22 May 2002 01:04:22 -0700 (PDT)")
References: <Pine.SOL.4.33.0205220100420.17494-100000@blue3.math.berkeley.edu>
Message-ID: <87znyso9to.fsf@alberti.gnupg.de>

On Wed, 22 May 2002 01:04:22 -0700 (PDT), Russell O'Connor said:

> I was building Gnupg 1.0.7 for OS/2 and I had to manually add strncasecmp
> to util/strutil.c

How did you implement the random number generator?




From wk@gnupg.org  Wed May 22 12:20:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Wed May 22 11:20:01 2002
Subject: strncasecmp
In-Reply-To: <4b3a87c92bsbellon@sbellon.de> (Stefan Bellon's message of
 "Wed, 22 May 2002 10:34:05 +0200")
References: <Pine.SOL.4.33.0205220100420.17494-100000@blue3.math.berkeley.edu>
 <4b3a87c92bsbellon@sbellon.de>
Message-ID: <87n0uso7ug.fsf@alberti.gnupg.de>

On Wed, 22 May 2002 10:34:05 +0200, Stefan Bellon said:

> So, neither strcasecmp nor strncasecmp is necessary anymore. Perhaps
> you could try with a CVS build again?

Well, a check and a replacement for strncasecmp is needed if we use it
and there are some place where strcasecmp should be used instead of
the ascii versions: Those where you actually compare against localized
strings.  I found some places where it was rightfully used but hidden
by stricmp which is just a macro to strcasecmp.  I fixed all of them
and added a strncasecmp repalcement function.

  Werner



From wk@gnupg.org  Wed May 22 12:20:03 2002
From: wk@gnupg.org (Werner Koch)
Date: Wed May 22 11:20:03 2002
Subject: strncasecmp
In-Reply-To: <fc.004c540101aa85a33b9aca0013090653.1aa85d3@oufcnt2.open.ac.uk> (Andrew
 Marlow's message of "Wed, 22 May 2002 09:33:01 +0100")
References: <Pine.SOL.4.33.0205220100420.17494-100000@blue3.math.berkeley.edu>
 <fc.004c540101aa85a33b9aca0013090653.1aa85d3@oufcnt2.open.ac.uk>
Message-ID: <87it5go7sv.fsf@alberti.gnupg.de>

On Wed, 22 May 2002 09:33:01 +0100, Andrew Marlow said:

> Some environments have strncasecmp and others don't. I usually define my
> own version of strncasecmp and the implementation differs from environment

And that is why you should have autoconf test for it and provide a
replacement.  I added the missing tests.
 
  Werner



From rjhansen@inav.net  Wed May 22 16:31:01 2002
From: rjhansen@inav.net (Robert J. Hansen)
Date: Wed May 22 15:31:01 2002
Subject: secure sign & encrypt
In-Reply-To: <1022053889.12048.32.camel@atlas>
References: <1021648640.7790.33.camel@atlas>
 <200205171138.51248.rjhansen@inav.net> <1021969508.14022.39.camel@atlas>
 <200205211132.09336.rjhansen@inav.net>  <1022053889.12048.32.camel@atlas>
Message-ID: <1022074192.9093.11.camel@numbers>

> Why do locks exist, then? The existence of thieves is a purely

Mostly to make homeowners feel safe.  Locks don't exist to keep burglars
out.  My parents lock their front door religiously every single night,
and have a cognitive dissonance in place regarding the large bay window
by the front door.  When I go home to visit, I sometimes like to make a
demonstration of just how silly the front door's lock is by picking
it--lockpicking isn't a hard skill to pick up, incidentally; it just
requires a little devotion.  The reaction I get from Mom and Dad is
always the same: "I wish you wouldn't do that."  Not, "Oh, dear, that
lock's insecure, we need to change it."  My parents are very typical
people in this regard.

You're right; burglary is a sociological problem, and one shouldn't try
to solve it with technological means.  Aggressive law-enforcement, which
is a sociological measure, has a much better track record than locks,
which are purely technological ones.

> I agree it'd be breaking (I'd call it extending, but call it what you
> want). But I argue that it's just automating a task the user presently
> has to do manually.

It's breaking a standard for no effective increase in security.  If the
person you're communicating with is untrustworthy, they can still do all
sorts of things to you which are a thousand times worse than this
(fairly trivial) attack you're worried about.

> Currently, to get secure, authenticated end-to-end encryption with gpg,
> the sender has to sign/encrypt/sign, which presently requires at least 2
> gpg invocations, and the recipient has to manually verify that the inner
> and the outer signature match. 

No: only for people whose threat models include a paranoiac distrust of
their recipients have to worry about this.  My threat model doesn't
incorporate that, and thus, I can get (just to be buzzword-compliant)
"secure, authenticated end-to-end encryption with GPG" just by signing
and encrypting.

Many other people share my threat model, and changing GPG's behavior
would mean GPG would no longer well-represent our threat model.  

> What I propose does basically just automate this task. It might do so by

... and breaks RFC.





From avbidder@fortytwo.ch  Wed May 22 18:44:02 2002
From: avbidder@fortytwo.ch (Adrian 'Dagurashibanipal' von Bidder)
Date: Wed May 22 17:44:02 2002
Subject: secure sign & encrypt
In-Reply-To: <1022074192.9093.11.camel@numbers>
References: <1021648640.7790.33.camel@atlas>
 <200205171138.51248.rjhansen@inav.net> <1021969508.14022.39.camel@atlas>
 <200205211132.09336.rjhansen@inav.net>  <1022053889.12048.32.camel@atlas>
 <1022074192.9093.11.camel@numbers>
Message-ID: <1022082280.17135.125.camel@atlas>

--=-sHn1TXuvzo0FFuYUJyVo
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2002-05-22 at 15:29, Robert J. Hansen wrote:
> > Why do locks exist, then? The existence of thieves is a purely

> > Currently, to get secure, authenticated end-to-end encryption with gpg,
> > the sender has to sign/encrypt/sign, which presently requires at least =
2
> > gpg invocations, and the recipient has to manually verify that the inne=
r
> > and the outer signature match.=20
>=20
> No: only for people whose threat models include a paranoiac distrust of
> their recipients have to worry about this.  My threat model doesn't
> incorporate that, and thus, I can get (just to be buzzword-compliant)
> "secure, authenticated end-to-end encryption with GPG" just by signing
> and encrypting.

signing and encrypting is a secure end-to-end channel from the *senders*
point of view. the problem is that for a potential *recipient* of an
encrypted & signed msg it is impossible to know much about the potential
prior recipient of the message (the one that encrypted and forwarded
it).

In other words, your threat model says that you do not only trust the
sender (signer) of a message, but you trust all people who may get
signed messages from that sender. (Or, alternatively, you as the
receiver of a confidential message do not care to know if it really was
sent encrypted or not.)

cheers
-- vbi


--=20
secure email with gpg            avbidder@fortytwo.ch: key id 0x92082481
                                 avbidder@acter.ch:    key id 0x5E4B731F


--=-sHn1TXuvzo0FFuYUJyVo
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA867zowj49sl5Lcx8RAjSNAJsFMg98jQeZWlG9Fo+/rs4dmB2IBwCdGMaZ
fX7WLJlFukV4EQ+X8n0zWmA=
=Qtjy
-----END PGP SIGNATURE-----

--=-sHn1TXuvzo0FFuYUJyVo--



From rjhansen@inav.net  Wed May 22 19:54:01 2002
From: rjhansen@inav.net (Robert J. Hansen)
Date: Wed May 22 18:54:01 2002
Subject: secure sign & encrypt
In-Reply-To: <1022082280.17135.125.camel@atlas>
Message-ID: <Pine.LNX.4.44L0.0205221140200.31437-100000@soli.inav.net>

> In other words, your threat model says that you do not only trust the
> sender (signer) of a message, but you trust all people who may get
> signed messages from that sender. (Or, alternatively, you as the

<testy>
No.  Please don't make assumptions about my threat model, especially ones 
which are subtly and seriously wrong.
</testy>

The `exploit' you're concerned about isn't an exploit at all, except 
insofar as to say the weakest point of any cryptosystem is in the 
ignorance of its users.  Even in the worst-case scenario, all you can say 
is that it only affects people who don't bother to learn the cryptosystem 
they're using.  And there is absolutely nothing which can protect people 
from their own ignorance.  Trying to do so is a fool's errand.

Although I'm not a core GPG hacker (my work is limited to a C++ binding 
for GPGME) and thus my opinion has just about as much weight as your 
average Slashdot reader's, I would be extremely displeased to see GnuPG 
chase after an ephemeral exploit and, in the process, break RFC.




From Weimer@CERT.Uni-Stuttgart.DE  Wed May 22 21:21:01 2002
From: Weimer@CERT.Uni-Stuttgart.DE (Florian Weimer)
Date: Wed May 22 20:21:01 2002
Subject: A modified version of GnuPG
In-Reply-To: <1387186383.20020521213928@mail.ru> ("Max V. Zinal"'s message
 of "Tue, 21 May 2002 21:39:28 +0400")
References: <200205210421.QAA220469@ruru.cs.auckland.ac.nz>
 <1387186383.20020521213928@mail.ru>
Message-ID: <87adqturzu.fsf@CERT.Uni-Stuttgart.DE>

"Max V. Zinal" <Zlat0@mail.ru> writes:

> When I said "secure memory" I was going to say "VirtualLock under
> Windows  NT/2000/XP",  which keeps you absolutely safe unless you
> have  a  Terminal  Server  with  an  evil-minded admin, or remote
> desktop    connection    with    'Debug' privileges.

Previous information about VirtualLock on Win32 suggests that it does
not prevent memory from being paged to disk, but only from being paged
to disk and then discarded.

In fact, the MSDN documentation available online carefully avoids the
claim that the specified memory region is never written to disk.

-- 
Florian Weimer 	                  Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898


From kokhong@post1.com  Wed May 22 21:21:04 2002
From: kokhong@post1.com (Soh Kok Hong)
Date: Wed May 22 20:21:04 2002
Subject: GnuPG for Win32
References: <3CE879E5.4060200@post1.com>
Message-ID: <3CEB00B2.3090208@post1.com>

Dear all,

The patch that I am suggesting builds a Win32 executable (ie. no cygwin
DLLs needed) using the CYGWIN's mingw32 tools.  I did not use the mingw32-cpd
stuff because it is rather old and does not include winsock2 - winsock2 is
required in building gnupg for Win32.

You need to run autoconf (by running "scripts/missing --run autoconf") to
rebuild the configure script first.

The changes are as follows:

1. acinclude.m4 & aclocal.m4
- patch to set ac_cv_sys_symbol_underscore to yes for mingw32 target

2. configure.ac
- Added AC_PROG_RANLIB - this was missing.  In real unix targets,
this variable is added because of AM_GNU_GETTEXT which performs
lots of tests - one of which is to set AC_PROG_RANLIB.  In mingw32
target, this did not get set because try_gettext set to "no", hence
AC_PROGR_RANLIB never gets set.

- added a check for presence of strcasecmp function.  Again, the reason
this did not get checked is because of the AM_GNU_GETTEXT problem.

3. cipher/rndw32.c
- forced include of winioctl.h.  This is needed to include the
DISK_PERFORMANCE structure definition.


Soh Kok Hong wrote:
> Dear all,
> 
> I have a 68-line diff file to patch the stock gnupg-1.0.7.tar.gz to
> build a mingw32 executable in the standard cygwin environment.  It
> mainly patches the configure scripts and one source file (rndw32.c).  I
> would like to know if the gnupg maintainers are interested and to whom
> can I email the patch to?
> 
> Please email to me directly as I am not on the list.
> 
> 
> --
> *************************************************
> Soh Kok Hong
> 
> kokhong@post1.com PGP Signature:
> D18B FC65 2202 3E43 A2D3 90D2 7BCC ABD3 77CE CD1C
> *************************************************


============ patch starts here =================

diff -Naur gnupg-1.0.7.orig/acinclude.m4 gnupg-1.0.7/acinclude.m4
--- gnupg-1.0.7.orig/acinclude.m4	2001-12-20 01:16:30.000000000 +0800
+++ gnupg-1.0.7/acinclude.m4	2002-05-18 16:03:16.000000000 +0800
@@ -661,7 +661,7 @@
  AC_DEFUN(GNUPG_SYS_SYMBOL_UNDERSCORE,
  [tmp_do_check="no"
  case "${target}" in
-    i386-emx-os2 | i[3456]86-pc-os2*emx | i386-pc-msdosdjgpp | *-*-cygwin)
+    i386-emx-os2 | i[3456]86-pc-os2*emx | i386-pc-msdosdjgpp | *-*-cygwin | *-*-mingw32 )
          ac_cv_sys_symbol_underscore=yes
          ;;
      *)
diff -Naur gnupg-1.0.7.orig/aclocal.m4 gnupg-1.0.7/aclocal.m4
--- gnupg-1.0.7.orig/aclocal.m4	2002-04-29 22:58:48.000000000 +0800
+++ gnupg-1.0.7/aclocal.m4	2002-05-18 16:03:18.000000000 +0800
@@ -665,7 +665,7 @@
  AC_DEFUN(GNUPG_SYS_SYMBOL_UNDERSCORE,
  [tmp_do_check="no"
  case "${target}" in
-    i386-emx-os2 | i[3456]86-pc-os2*emx | i386-pc-msdosdjgpp | *-*-cygwin)
+    i386-emx-os2 | i[3456]86-pc-os2*emx | i386-pc-msdosdjgpp | *-*-cygwin | *-*-mingw32 )
          ac_cv_sys_symbol_underscore=yes
          ;;
      *)
diff -Naur gnupg-1.0.7.orig/cipher/rndw32.c gnupg-1.0.7/cipher/rndw32.c
--- gnupg-1.0.7.orig/cipher/rndw32.c	2001-12-20 02:05:04.000000000 +0800
+++ gnupg-1.0.7/cipher/rndw32.c	2002-05-18 16:03:18.000000000 +0800
@@ -67,9 +67,7 @@
  #include <string.h>

  #include <windows.h>
-#ifdef __CYGWIN32__
-# include <winioctl.h>
-#endif
+#include <winioctl.h>


  #include "types.h"
diff -Naur gnupg-1.0.7.orig/configure.ac gnupg-1.0.7/configure.ac
--- gnupg-1.0.7.orig/configure.ac	2002-04-29 22:56:08.000000000 +0800
+++ gnupg-1.0.7/configure.ac	2002-05-18 16:03:20.000000000 +0800
@@ -184,6 +184,7 @@
  AM_MISSING_PROG(MAKEINFO, makeinfo, $missing_dir)
  AC_PROG_CC
  AC_PROG_CPP
+AC_PROG_RANLIB
  AC_PATH_PROG(PERL,"perl")
  AC_ISC_POSIX
  AC_SYS_LARGEFILE
@@ -482,7 +483,7 @@
  AC_FUNC_FSEEKO
  AC_FUNC_VPRINTF
  AC_FUNC_FORK
-AC_CHECK_FUNCS(strerror stpcpy strsep strlwr stricmp tcgetattr strtoul mmap)
+AC_CHECK_FUNCS(strerror stpcpy strsep strlwr stricmp tcgetattr strtoul strcasecmp mmap)
  AC_CHECK_FUNCS(memmove gettimeofday getrusage setrlimit clock_gettime)
  AC_CHECK_FUNCS(memicmp atexit raise getpagesize strftime nl_langinfo setlocale)
  AC_CHECK_FUNCS(waitpid wait4 sigaction sigprocmask rand pipe stat)
diff -Naur gnupg-1.0.7.orig/scripts/build-mingw32 gnupg-1.0.7/scripts/build-mingw32
--- gnupg-1.0.7.orig/scripts/build-mingw32	1970-01-01 08:00:00.000000000 +0800
+++ gnupg-1.0.7/scripts/build-mingw32	2002-05-18 16:06:06.000000000 +0800
@@ -0,0 +1,6 @@
+#!/bin/sh
+
+export CC="gcc -mno-cygwin -mthreads"
+
+./configure --target=i386-pc-mingw32
+




From disastry@saiknes.lv  Wed May 22 21:21:06 2002
From: disastry@saiknes.lv (disastry@saiknes.lv)
Date: Wed May 22 20:21:06 2002
Subject: RSA sign+encrypt (with subkey) key generation
Message-ID: <3CEB7600.5CAFAF74@saiknes.lv>

This is a multi-part message in MIME format.
--------------1C9E8650BAE0BC0A8A373C79
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

hello

here is the patch that allows to generate RSA sign+encrypt (with subkey) keys
in one step (like DSA/Elgamal keys) - no need to go to --key-edit to add subkey

it also allows to generate RSA/Elgamal and DSA/RSA keys in one step.

this patch is for 1.0.7a (cvs version)

patch also available at
http://disastry.dhs.org/pgp/gpg/gnupg-1.0.7a-keygen.diff

__
Disastry  http://disastry.dhs.org/
-----BEGIN PGP SIGNATURE-----
Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1

iQA/AwUBPOtZkDBaTVEuJQxkEQNPqACeI4JHKHqW2/bz/yhL4Si7t7TQesoAoIn7
sjEvzUyMrauX8ZRvEa6vWfXk
=Y/XQ
-----END PGP SIGNATURE-----
--------------1C9E8650BAE0BC0A8A373C79
Content-Type: text/plain; charset=us-ascii;
 name="gnupg-1.0.7a-keygen.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="gnupg-1.0.7a-keygen.diff"

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

This patch enables gpg version 1.0.7a to generate RSA sign + RSA encrypt keys
and RSA sign + ElGamal encrypt and DSA + RSA encrypt keys.


Copyright 2001 Free Software Foundation, Inc.

This patch is free software; you can use it, redistribute it
and/or modify it under the terms of the GNU General Public
License as published by the Free Software Foundation; either
version 2 of the License, or (at your option) any later version.


--- gnupg/g10/keygen.c	Thu May 16 05:35:54 2002
+++ gnupg107a/g10/keygen.c	Wed May 22 12:19:21 2002
@@ -849,8 +849,14 @@
     tty_printf(    _("   (%d) RSA (sign only)\n"), 5 );
     if (addmode)
         tty_printf(    _("   (%d) RSA (encrypt only)\n"), 6 );
+    if (!addmode)
+      tty_printf(    _("   (%d) RSA (sign and encrypt (with subkey))\n"), 7 );
     if (opt.expert)
-      tty_printf(    _("   (%d) RSA (sign and encrypt)\n"), 7 );
+      tty_printf(    _("   (%d) RSA (sign and encrypt (single key))\n"), 8 );
+    if (!addmode && opt.expert) { /* add odd keys too... */
+      tty_printf(    _("   (%d) RSA (sign) and ElGamal(encrypt)\n"), 9 );
+      tty_printf(    _("   (%d) DSA (sign) and RSA (encrypt)\n"), 10 );
+    }
 
     for(;;) {
 	answer = cpr_get("keygen.algo",_("Your selection? "));
@@ -858,10 +864,20 @@
 	algo = *answer? atoi(answer): 1;
 	m_free(answer);
 	if( algo == 1 && !addmode ) {
-	    algo = 0;	/* create both keys */
+	    algo = PUBKEY_ALGO_DSA | (PUBKEY_ALGO_ELGAMAL_E << 8);	/* create both keys */
+	    break;
+	}
+	else if( algo == 10 && !addmode && opt.expert ) {
+	    algo = PUBKEY_ALGO_DSA | (PUBKEY_ALGO_RSA << 8);	/* create both keys */
+            *r_usage = PUBKEY_USAGE_ENC << 8;
 	    break;
 	}
-	else if( algo == 7 && opt.expert ) {
+	else if( algo == 9 && !addmode && opt.expert ) {
+	    algo = PUBKEY_ALGO_RSA | (PUBKEY_ALGO_ELGAMAL_E << 8);	/* create both keys */
+            *r_usage = PUBKEY_USAGE_SIG;
+	    break;
+	}
+	else if( algo == 8 && opt.expert ) {
 	    if (cpr_get_answer_is_yes ("keygen.algo.rsa_se",_(
 		"The use of this algorithm is deprecated - create anyway? "))){
               algo = PUBKEY_ALGO_RSA;
@@ -869,6 +885,11 @@
               break;
             }
 	}
+	else if( algo == 7 && !addmode ) {
+	    algo = PUBKEY_ALGO_RSA | (PUBKEY_ALGO_RSA << 8);	/* create both keys */
+            *r_usage = PUBKEY_USAGE_SIG | (PUBKEY_USAGE_ENC << 8);
+	    break;
+	}
 	else if( algo == 6 && addmode ) {
 	    algo = PUBKEY_ALGO_RSA;
             *r_usage = PUBKEY_USAGE_ENC;
@@ -1855,7 +1876,7 @@
 void
 generate_keypair( const char *fname )
 {
-    unsigned int nbits;
+    unsigned int nbits = 0;
     char *uid = NULL;
     DEK *dek;
     STRING2KEY *s2k;
@@ -1875,26 +1896,52 @@
     }
 
     algo = ask_algo( 0, &use );
-    if( !algo ) { /* default: DSA with ElG subkey of the specified size */
+    if( algo >> 8 ) { /* default: DSA with ElG subkey of the specified size */
 	both = 1;
 	r = m_alloc_clear( sizeof *r + 20 );
 	r->key = pKEYTYPE;
-	sprintf( r->u.value, "%d", PUBKEY_ALGO_DSA );
+	sprintf( r->u.value, "%d", algo & 0xff );
 	r->next = para;
 	para = r;
-	tty_printf(_("DSA keypair will have 1024 bits.\n"));
 	r = m_alloc_clear( sizeof *r + 20 );
 	r->key = pKEYLENGTH;
-	strcpy( r->u.value, "1024" );
+	if ((algo & 0xff) == PUBKEY_ALGO_DSA) {
+	    tty_printf(_("DSA keypair will have 1024 bits.\n"));
+	    strcpy( r->u.value, "1024" );
+	} else {
+	    nbits = ask_keysize( algo && 0xff );
+	    sprintf( r->u.value, "%u", nbits);
+	}
 	r->next = para;
 	para = r;
 
-	algo = PUBKEY_ALGO_ELGAMAL_E;
+        if (use & 0xff) {
+            r = m_alloc_clear( sizeof *r + 20 );
+            r->key = pKEYUSAGE;
+            sprintf( r->u.value, "%s%s",
+                     (use & PUBKEY_USAGE_SIG)? "sign ":"",
+                     (use & PUBKEY_USAGE_ENC)? "encrypt ":"" );
+            r->next = para;
+            para = r;
+        }
+
+	algo = algo >> 8;
+	use = use >> 8;
 	r = m_alloc_clear( sizeof *r + 20 );
 	r->key = pSUBKEYTYPE;
 	sprintf( r->u.value, "%d", algo );
 	r->next = para;
 	para = r;
+
+        if (use) {
+            r = m_alloc_clear( sizeof *r + 20 );
+            r->key = pSUBKEYUSAGE;
+            sprintf( r->u.value, "%s%s",
+                     (use & PUBKEY_USAGE_SIG)? "sign ":"",
+                     (use & PUBKEY_USAGE_ENC)? "encrypt ":"" );
+            r->next = para;
+            para = r;
+        }
     }
     else {
 	r = m_alloc_clear( sizeof *r + 20 );
@@ -1915,7 +1962,8 @@
 
     }
 
-    nbits = ask_keysize( algo );
+    if ( !nbits )
+	nbits = ask_keysize( algo );
     r = m_alloc_clear( sizeof *r + 20 );
     r->key = both? pSUBKEYLENGTH : pKEYLENGTH;
     sprintf( r->u.value, "%u", nbits);
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (MingW32)

iD8DBQE863N1MFpNUS4lDGQRAgqTAJ9NW005a2n9RneLmYVz61IOVNCeTQCgj3Zy
z8nOyOhhpk+IoUnaMptHeNA=
=k+D4
-----END PGP SIGNATURE-----

--------------1C9E8650BAE0BC0A8A373C79--



From roconnor@Math.Berkeley.EDU  Thu May 23 04:41:01 2002
From: roconnor@Math.Berkeley.EDU (Russell O'Connor)
Date: Thu May 23 03:41:01 2002
Subject: GnuPG 1.0.7 for OS/2
Message-ID: <Pine.SOL.4.33.0205221839420.19679-100000@blue3.math.berkeley.edu>

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

[To: gnupg-users@gnupg.org, gnupg-devel@gnupg.org]

GnuPG 1.0.7 is available for OS/2 at
<http://math.berkeley.edu/~roconnor/gnupg/>

Requires EMX, RexxEGD, and Zlib 1.1.4.

- -- 
Russell O'Connor                           roconnor@math.berkeley.edu
           <http://www.math.berkeley.edu/~roconnor/>
``Later generations will regard set theory as a disease from which one
has recovered.'' -- Poincare
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (SunOS)
Comment: For info see http://www.gnupg.org

iD8DBQE87EjsuZUa0PWVyWQRAu1gAJ41HmicFwddsI3VLkxglYxlPny4TwCfVcmr
1O6c+oRfhocXSceh04OuEWY=
=zvQa
-----END PGP SIGNATURE-----



From pgut001@cs.auckland.ac.nz  Thu May 23 05:17:01 2002
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
Date: Thu May 23 04:17:01 2002
Subject: Re[2]: A modified version of GnuPG
Message-ID: <200205230217.OAA443785@ruru.cs.auckland.ac.nz>

"Max V. Zinal" <Zlat0@mail.ru> writes:

>When I said "secure memory" I was going to say "VirtualLock under Windows
>NT/2000/XP", which keeps you absolutely safe unless you have a Terminal Server
>with an evil-minded admin, or remote desktop connection with 'Debug'
>privileges.

[...]

>if we are talking about Win9x/ME (which should be called 'Mustdie Edition', I
>think), even with VirtualLock you cannot be absolutely shure.

VirtualLock() has anything from a marginal chance of preventing swapping (best-
case) to a chance of greatly increasing swapping (worst-case).  Under Win9x it
does nothing at all (it's a no-op).  It's nothing like "absolutely safe".  See
e.g. http://www.cryptoapps.com/~peter/06_random.pdf, somewhere towards the end.

Peter.



From avbidder@fortytwo.ch  Thu May 23 12:19:01 2002
From: avbidder@fortytwo.ch (Adrian 'Dagurashibanipal' von Bidder)
Date: Thu May 23 11:19:01 2002
Subject: secure sign & encrypt
In-Reply-To: <Pine.LNX.4.44L0.0205221140200.31437-100000@soli.inav.net>
References: <Pine.LNX.4.44L0.0205221140200.31437-100000@soli.inav.net>
Message-ID: <1022145616.5434.17.camel@atlas>

--=-+TYm2zHn2izZGRW4c328
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2002-05-22 at 18:55, Robert J. Hansen wrote:
> > In other words, your threat model says that you do not only trust the
> > sender (signer) of a message, but you trust all people who may get
> > signed messages from that sender. (Or, alternatively, you as the
>=20
> <testy>
> No.  Please don't make assumptions about my threat model, especially ones=
=20
> which are subtly and seriously wrong.
> </testy>

I'm sorry if I misunderstand you here. Let me ask you, then:

You receive an encrypted + signed message. What do you know now?

You trust the signature. Do you trust that nobody has read the message
in passing?

cheers
-- vbi



--=20
secure email with gpg            avbidder@fortytwo.ch: key id 0x92082481
                                 avbidder@acter.ch:    key id 0x5E4B731F


--=-+TYm2zHn2izZGRW4c328
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA87LRQwj49sl5Lcx8RAomUAJwLd+arZwf1fAY2/+IaxgG43CwUhACfcphN
uL9roi4q9vJvLQ3elBRy7Jw=
=XF8q
-----END PGP SIGNATURE-----

--=-+TYm2zHn2izZGRW4c328--



From jukkaho@mail.student.oulu.fi  Thu May 23 12:58:01 2002
From: jukkaho@mail.student.oulu.fi (Jukka Holappa)
Date: Thu May 23 11:58:01 2002
Subject: secure sign & encrypt
References: <Pine.LNX.4.44L0.0205221140200.31437-100000@soli.inav.net> <1022145616.5434.17.camel@atlas>
Message-ID: <3CECBD9E.4090306@mail.student.oulu.fi>

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

Adrian 'Dagurashibanipal' von Bidder wrote:
| On Wed, 2002-05-22 at 18:55, Robert J. Hansen wrote:
|
|>>In other words, your threat model says that you do not only trust the
|>>sender (signer) of a message, but you trust all people who may get
|>>signed messages from that sender. (Or, alternatively, you as the
|>
|><testy>
|>No.  Please don't make assumptions about my threat model, especially ones
|>which are subtly and seriously wrong.
|></testy>
|
|
| I'm sorry if I misunderstand you here. Let me ask you, then:
|
| You receive an encrypted + signed message. What do you know now?
|
| You trust the signature. Do you trust that nobody has read the message
| in passing?
|

I'm sorry to get in the middle of this, but you really can't know that
with all the signatures you put in it.

Maybe someone read the message over the shoulder before it was
signed+encrypted(+signed) or whatever.

You just have to trust a person to encrypt before anyone sees the
message. If he/she fails to do this, there's no secret message in it any
more.

- - Jukka
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE87L2eYYWM2XTSwX0RApfAAKCDKY19S2HR8weZG3iNAs7XqTFtdwCfZ9rA
Pphmzn7kfxPh7WO+7NIc5oI=
=R2SD
-----END PGP SIGNATURE-----



From avbidder@fortytwo.ch  Thu May 23 16:03:02 2002
From: avbidder@fortytwo.ch (Adrian 'Dagurashibanipal' von Bidder)
Date: Thu May 23 15:03:02 2002
Subject: secure sign & encrypt
In-Reply-To: <3CECBD9E.4090306@mail.student.oulu.fi>
References: <Pine.LNX.4.44L0.0205221140200.31437-100000@soli.inav.net>
 <1022145616.5434.17.camel@atlas>  <3CECBD9E.4090306@mail.student.oulu.fi>
Message-ID: <1022159038.5792.90.camel@atlas>

--=-jHO6hpiweAJ41f8F8ugG
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Thu, 2002-05-23 at 11:59, Jukka Holappa wrote:

> | You receive an encrypted + signed message. What do you know now?
> |
> | You trust the signature. Do you trust that nobody has read the message
> | in passing?
> |
>=20
> I'm sorry to get in the middle of this, but you really can't know that
> with all the signatures you put in it.
>=20
> Maybe someone read the message over the shoulder before it was
> signed+encrypted(+signed) or whatever.
>=20
> You just have to trust a person to encrypt before anyone sees the
> message. If he/she fails to do this, there's no secret message in it any
> more.

I trust that if a person is encrypting a message to me, this person will
also be certain that the message is handled confidentially until it is
encrypted.

The problem with the attack I'm arguing about is that the message was
*not* encrypted in the first place, but that the recipient receives it
as an encrypted message and thus might put a meaning to a message that
was not intended by the sender.

With current openPGP encryption, encryption is only useful for the
sender (he knows that the message sent is encrypted and will not be read
by anybody other than the intended recipient. Of course he trusts the
recipient not to do the wrong thing with the information).=20

Encryption is *not* useful for the recipient - he must not put any
special meaning to the fact that a message was encrypted.

BUT encryption COULD be useful for the recipient, if it was made clear
that the message was sent encrypted in the first place. Of course the
recipient still needs to trust the sender/signer of the message to have
handled the contained information confidentially.


In the end it all boils down that people (or, at least I) automatically
put different meanings to a message, depending on the source of the
message. A message in the newspaper is read differently than the same
message in a letter. In the same way, an unencrypted e-mail message may
be interpreted differently from the same message that comes encrypted -
it tells something about the sender's intention.



Concerning RFC compliance:
from rfc2440, section 5.2.3.1:
=3D=3D=3D=3D=3D=3D
     An implementation SHOULD ignore any subpacket of a type that it
     does not recognize.
=3D=3D=3D=3D=3D=3D

So, adding a hashed subpacket with a subpacket type of, say, 110
(explicitely reserved for private use) for the purpose of announcing the
'intended encryption key' on signed+encrypted messages is fully within
the scope of the rfc and SHOULD not break any openPGP compliant
implementations.

Displaying extra warnings on decrypting messages without this special
subpacket should of course not be the default while this is not in
widespread use. Displaying extra warnings in case there is a mismatch
between the intended and the real encryption key can probably safely be
enabled per default.

Also - although I'm in no way involved with writing RFCs - the RFC
documents have been known to be revised and extended from time to time.


Huk
-- vbi



--=20
secure email with gpg            avbidder@fortytwo.ch: key id 0x92082481
                                 avbidder@acter.ch:    key id 0x5E4B731F


--=-jHO6hpiweAJ41f8F8ugG
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA87Oi+wj49sl5Lcx8RAm00AJ43EYWOM0GseSoNnSOVwkVUQ7nE1gCfbUZr
D44M4vLJ1wofXe7YzMrd378=
=n2Q/
-----END PGP SIGNATURE-----

--=-jHO6hpiweAJ41f8F8ugG--



From jukkaho@mail.student.oulu.fi  Thu May 23 16:59:02 2002
From: jukkaho@mail.student.oulu.fi (Jukka Holappa)
Date: Thu May 23 15:59:02 2002
Subject: secure sign & encrypt
References: <Pine.LNX.4.44L0.0205221140200.31437-100000@soli.inav.net>	<1022145616.5434.17.camel@atlas>  <3CECBD9E.4090306@mail.student.oulu.fi> <1022159038.5792.90.camel@atlas>
Message-ID: <3CECF632.50606@mail.student.oulu.fi>

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

Adrian 'Dagurashibanipal' von Bidder wrote:
| BUT encryption COULD be useful for the recipient, if it was made clear
| that the message was sent encrypted in the first place. Of course the
| recipient still needs to trust the sender/signer of the message to have
| handled the contained information confidentially.
|
|
| In the end it all boils down that people (or, at least I) automatically
| put different meanings to a message, depending on the source of the
| message. A message in the newspaper is read differently than the same
| message in a letter. In the same way, an unencrypted e-mail message may
| be interpreted differently from the same message that comes encrypted -
| it tells something about the sender's intention.
|
|
|
| Concerning RFC compliance:
| from rfc2440, section 5.2.3.1:
| ======
|      An implementation SHOULD ignore any subpacket of a type that it
|      does not recognize.
| ======
|
| So, adding a hashed subpacket with a subpacket type of, say, 110
| (explicitely reserved for private use) for the purpose of announcing the
| 'intended encryption key' on signed+encrypted messages is fully within
| the scope of the rfc and SHOULD not break any openPGP compliant
| implementations.
|
| Displaying extra warnings on decrypting messages without this special
| subpacket should of course not be the default while this is not in
| widespread use. Displaying extra warnings in case there is a mismatch
| between the intended and the real encryption key can probably safely be
| enabled per default.

Very true and an excellent idea.

It would protect fairly well from sending someone else's signed messages
~ with perhaps malicuous (unsigned) attachments, only if programs warn
about missing subkey in encrypted message - and this is not going to be
a big warning in real life since there is no support for this key.

If Cecilia gets any Alices messages and is able to decrypt/copy it, he
can re-encrypt it without this subkey and send it to Bob in any other
contexts. It is not safer at all without this paranoid option which
tells that message was not sent to him originally.

Perhaps signatures would work better.. that they contain information to
who that particular message was sent. Perhaps the message itself ;)

Email programs should also warn when receiving unsigned attachments
along with encrypted/signed messages since there is no way knowing these
attachments are really from that person.


|
| Also - although I'm in no way involved with writing RFCs - the RFC
| documents have been known to be revised and extended from time to time.

Someone has to do it (not me either) :)

- - Jukka
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE87PYxYYWM2XTSwX0RAnktAJ4tX+HDuD7wrGBtMSSHK0BTBr/KHwCeLRw2
Y3Vxy/O9BzFffgXl5AoWbEM=
=WB+0
-----END PGP SIGNATURE-----



From rjhansen@inav.net  Thu May 23 17:21:02 2002
From: rjhansen@inav.net (Robert J. Hansen)
Date: Thu May 23 16:21:02 2002
Subject: secure sign & encrypt
In-Reply-To: <1022145616.5434.17.camel@atlas>
Message-ID: <Pine.LNX.4.44L0.0205230853260.11995-100000@soli.inav.net>

> You receive an encrypted + signed message. What do you know now?

I trust that the message really was composed by the original author, and I 
know it was encrypted when the data came out of the pipe.  If the signed 
message contains traffic which was unambiguously meant for me, then the 
message was intended for me.  Encryption and signing just means encryption 
and signing; I don't assume that crypto is some kind of magic fairy dust, 
where you sprinkle a little of it on your traffic and suddenly you're 
"secure".

A signed message doesn't mean the traffic was intended for you, it just 
means the message hasn't been tampered with in transit.  An encrypted 
message doesn't mean nobody's read the message, it just means it's been 
kept safe in transit from the time someone encrypted it to the time you 
decrypted it.




From rjhansen@inav.net  Thu May 23 17:29:01 2002
From: rjhansen@inav.net (Robert J. Hansen)
Date: Thu May 23 16:29:01 2002
Subject: secure sign & encrypt
In-Reply-To: <1022159038.5792.90.camel@atlas>
Message-ID: <Pine.LNX.4.44L0.0205230922350.11995-100000@soli.inav.net>

> In the end it all boils down that people (or, at least I) automatically
> put different meanings to a message, depending on the source of the

If you decide to (foolishly) infer that crypto means something that it 
doesn't, which no reputable source will tell you it does, then that 
reflects more on your own lack of understanding than a flaw in the 
protocol.  Ignorance is the Achilles' heel of every protocol, and your 
proposed fix does not fix the protocol--the protocol's not broken--it just 
makes the protocol come into line with how you think the protocol Ought To 
Be.

> Concerning RFC compliance:
> from rfc2440, section 5.2.3.1:
> ======
>      An implementation SHOULD ignore any subpacket of a type that it
>      does not recognize.
> ======

Note well that sentence.  SHOULD, not MUST.  For every program which 
correctly and properly implements RFCs, there are easily a couple of dozen 
which just barely manage to get the MUSTs implemented.  When I was working 
at McLeodUSA, they had me working on a project to reimplement RFC1991 
(Classic PGP) in-house so they could get around the licensing terms.  
(Never mind that the license fees to RSA and IDEA were prohibitive... 
management at its finest.)  Given the tremendous time constraints I was 
under, I was doing really, really well just to get the MUSTs.

If this extension gets implemented it _will_ break interoperability with 
other OpenPGP implementations (even if I don't know offhand which ones it 
will break), and we'll be the ones who will be responsible.  All for no 
effective increase in security.

> Also - although I'm in no way involved with writing RFCs - the RFC
> documents have been known to be revised and extended from time to time.

Yes, by working groups.  If you want the RFC changed, there's a process in 
place for it; take it to the IETF and make the sales pitch there.  GnuPG 
is not the place to be embracing-and-extending the RFC.

I don't know how much clearer I can make it here, really.



From Max V. Zinal" <Zlat0@mail.ru  Thu May 23 18:12:01 2002
From: Max V. Zinal" <Zlat0@mail.ru (Max V. Zinal)
Date: Thu May 23 17:12:01 2002
Subject: Re[2]: A modified version of GnuPG
In-Reply-To: <87adqturzu.fsf@CERT.Uni-Stuttgart.DE>
References: <200205210421.QAA220469@ruru.cs.auckland.ac.nz>
 <1387186383.20020521213928@mail.ru> <87adqturzu.fsf@CERT.Uni-Stuttgart.DE>
Message-ID: <31929626.20020523190617@mail.ru>

Wednesday, May 22, 2002, 1:10:29 AM, Florian Weimer wrote:

FW> Previous information about VirtualLock on Win32 suggests that it does
FW> not prevent memory from being paged to disk, but only from being paged
FW> to disk and then discarded.

FW> In fact, the MSDN documentation available online carefully avoids the
FW> claim that the specified memory region is never written to disk.

Yes, that's true, and that was my mistake. The only excuse for me
is the following phrase in "VirtualLock" manual:

        "The  VirtualLock  function locks the specified region of
        the process's virtual address space into physical memory,
        ensuring  that  subsequent  access to the region will not
        incur a page fault."

I think that I can write a small dummy device driver for NT-based
system  that  will  allow  a person with administrative rights to
allocate  a non-pageable region of memory. It will take some time,
I  think,  because  I will have to find DDK distribution for that
purposes.  Such task isn't too complex, although it will not work
under 9x-based systems.

I'm sorry for inconvenience.

Best regards,
        Max V. Zinal



From dmitri@users.sourceforge.net  Thu May 23 18:32:01 2002
From: dmitri@users.sourceforge.net (Dmitri)
Date: Thu May 23 17:32:01 2002
Subject: Re[2]: A modified version of GnuPG
In-Reply-To: <31929626.20020523190617@mail.ru>
References: <200205210421.QAA220469@ruru.cs.auckland.ac.nz>
 <1387186383.20020521213928@mail.ru> <87adqturzu.fsf@CERT.Uni-Stuttgart.DE>
 <31929626.20020523190617@mail.ru>
Message-ID: <1022167972.29488.271.camel@usb.networkfab.com>

--=-rHpJX1Lq3gk4cG70YFPF
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Thu, 2002-05-23 at 08:06, Max V. Zinal wrote:

> I think that I can write a small dummy device driver for NT-based
> system  that  will  allow  a person with administrative rights to
> allocate  a non-pageable region of memory.

The driver does not need anyone's permission, it has full access to
everything in the kernel. But only administrator can install a driver.
Then the driver can impose any security restrictions on its use.

> It will take some time,
> I  think,  because  I will have to find DDK distribution for that
> purposes.

void *ExAllocatePool(NonPagedPool, <length>);

> Such task isn't too complex

300 lines of code, maybe. You will need to handle
IRP_MJ_{CREATE,CLOSE,READ,WRITE}. But the architecture of Win2K WDM
drivers is not really straightforward; if you never did it before then
you got some reading to do ;-)

Dmitri


--=-rHpJX1Lq3gk4cG70YFPF
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA87QujXksyLpO6T4IRAvr0AJ0ShJ+szbsW4kN83sn/chR6/MGdNACcCz2g
oAVv49dWTCC0rWm0XQHjjRA=
=Ivru
-----END PGP SIGNATURE-----

--=-rHpJX1Lq3gk4cG70YFPF--



From Pascal@Scheffers.Net  Thu May 23 22:41:01 2002
From: Pascal@Scheffers.Net (Pascal Scheffers)
Date: Thu May 23 21:41:01 2002
Subject: Re[2]: A modified version of GnuPG
In-Reply-To: <31929626.20020523190617@mail.ru>
References: <200205210421.QAA220469@ruru.cs.auckland.ac.nz>
 <1387186383.20020521213928@mail.ru> <87adqturzu.fsf@CERT.Uni-Stuttgart.DE>
 <31929626.20020523190617@mail.ru>
Message-ID: <1022182918.20135.17.camel@moonchild.lcl>

On Thu, 2002-05-23 at 17:06, Max V. Zinal wrote:
> FW> In fact, the MSDN documentation available online carefully avoids the
AFAICT, MSDN-online is/was 100% in sync with the offline available
versions (3 cdrom disk/DVD distribution), the only 'but' is that it is
uptodate, meaning older information isn't there anymore (or much harder
to find). 

This was a pain in the b*tt when I was working with crypto APIs for
win95 in the 2000, it's not always clear which API works with which
version. I have no idea if it's any better for the DDK. 

I seem to have trouble accessing it right now with Galeon, but that is
sort-of to be expected.

> I  think,  because  I will have to find DDK distribution for that
That is part of the MSDN library, too. You can also just download it
from the MS website: http://www.microsoft.com/ddk/W2kDDK.asp

It says there that the DDK has all the info, libraries, manuals and
samples you'll ever need. It's a 67MB download, tho. 

- Pascal.




From pgut001@cs.auckland.ac.nz  Fri May 24 08:06:01 2002
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
Date: Fri May 24 07:06:01 2002
Subject: Re[2]: A modified version of GnuPG
Message-ID: <200205240507.RAA43132@ruru.cs.auckland.ac.nz>

"Max V. Zinal" <Zlat0@mail.ru> writes:

>I think that I can write a small dummy device driver for NT-based system that
>will allow a person with administrative rights to allocate a non-pageable
>region of memory. It will take some time, I think, because I will have to find
>DDK distribution for that purposes.

You don't need to do that, there are already user-level functions which do
this.  To save me having to regurgitate it all again, search sci.crypt or the
archives of Perry Metzger's crypto list for "AllocateUserPhysicalPages" to find
the details.

Peter.



From avbidder@fortytwo.ch  Fri May 24 10:33:02 2002
From: avbidder@fortytwo.ch (Adrian 'Dagurashibanipal' von Bidder)
Date: Fri May 24 09:33:02 2002
Subject: secure sign & encrypt
In-Reply-To: <Pine.LNX.4.44L0.0205230922350.11995-100000@soli.inav.net>
References: <Pine.LNX.4.44L0.0205230922350.11995-100000@soli.inav.net>
Message-ID: <1022225631.24970.43.camel@atlas>

--=-jdknF5oRudFIcEcv2yDr
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Thu, 2002-05-23 at 16:29, Robert J. Hansen wrote:
> > In the end it all boils down that people (or, at least I) automatically
> > put different meanings to a message, depending on the source of the
>=20
[...]

> proposed fix does not fix the protocol--the protocol's not broken--it jus=
t=20
> makes the protocol come into line with how you think the protocol Ought T=
o=20
> Be.

Agree with you here - and I feel that to many users not willing to study
the protocol in dephth 'my' variant of the protocol is closer to what
people expect if they use a crypto solution.

Jukka:
> Perhaps signatures would work better.. that they contain information
> to who that particular message was sent. Perhaps the message itself ;)

I thought about the 'intended recipient' thing, analogous to my
'inteneded encryption key', but for non-encrypted messages. Clearly this
cannot be solved by gpg - how should it know the destination of the
message? However, MUAs could copy the To: header (and Subject:, too?)
into the signed area of the mail (MIME-Headers?), and use these infos
when displaying signed mail. (But as there are many more MUAs than
OpenPGP implementations, this proposal has an even smaller chance of
ever getting implemented)


As all points have probably been made (repeatedly - yes, I'm the guilty
here) it's probably ok if this is EOT here before the discussion becomes
endless (or we could always move over to de.alt.gruppenkasper).


cheers & HAND
-- vbi


--=20
secure email with gpg            avbidder@fortytwo.ch: key id 0x92082481
                                 avbidder@acter.ch:    key id 0x5E4B731F


--=-jdknF5oRudFIcEcv2yDr
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA87ezewj49sl5Lcx8RAk5uAJ9GuA/n9G7N4WA88e+5PFOEQDgOxQCdH1kt
koDk6bA8CU53j+Fe3Fg98CI=
=DnRn
-----END PGP SIGNATURE-----

--=-jdknF5oRudFIcEcv2yDr--



From Max V. Zinal" <Zlat0@mail.ru  Fri May 24 18:06:02 2002
From: Max V. Zinal" <Zlat0@mail.ru (Max V. Zinal)
Date: Fri May 24 17:06:02 2002
Subject: Re[4]: A modified version of GnuPG
In-Reply-To: <200205240507.RAA43132@ruru.cs.auckland.ac.nz>
References: <200205240507.RAA43132@ruru.cs.auckland.ac.nz>
Message-ID: <11716388144.20020524190723@mail.ru>

Friday, May 24, 2002, 9:07:19 AM, Peter Gutmann wrote:

PG> "Max V. Zinal" <Zlat0@mail.ru> writes:

>>I think that I can write a small dummy device driver for NT-based system that
>>will allow a person with administrative rights to allocate a non-pageable
>>region of memory. It will take some time, I think, because I will have to find
>>DDK distribution for that purposes.

PG> You don't need to do that, there are already user-level functions which do
PG> this.  To save me having to regurgitate it all again, search sci.crypt or the
PG> archives of Perry Metzger's crypto list for "AllocateUserPhysicalPages" to find
PG> the details.

I  know about these functions. Please note that they are the part
of  Address  Windowing  Extensions  (AWE), and thus are supported
only  with W2K or higher. We should also remember that Windows NT
4 is still widely used.

Best regards,
        Max V. Zinal



From pgut001@cs.auckland.ac.nz  Mon May 27 10:34:01 2002
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
Date: Mon May 27 09:34:01 2002
Subject: Re[4]: A modified version of GnuPG
Message-ID: <200205270735.TAA74949@ruru.cs.auckland.ac.nz>

"Max V. Zinal" <Zlat0@mail.ru> writes:
>Friday, May 24, 2002, 9:07:19 AM, Peter Gutmann wrote:
>PG> "Max V. Zinal" <Zlat0@mail.ru> writes:
>>>I think that I can write a small dummy device driver for NT-based system that
>>>will allow a person with administrative rights to allocate a non-pageable
>>>region of memory. It will take some time, I think, because I will have to find
>>>DDK distribution for that purposes.
>
>PG> You don't need to do that, there are already user-level functions which do
>PG> this.  To save me having to regurgitate it all again, search sci.crypt or the
>PG> archives of Perry Metzger's crypto list for "AllocateUserPhysicalPages" to find
>PG> the details.
>
>I know about these functions. Please note that they are the part of Address
>Windowing Extensions (AWE), and thus are supported only with W2K or higher. We
>should also remember that Windows NT 4 is still widely used.

You have to make a tradeoff, either be backwards-compatible with NT4 (which I
doubt is still widely used except maybe on a few servers which no-one wants to
touch) and face an incredibly difficult task of writing an NT kernel driver to
do it, or require Win2K and have Microsoft do most of it for you.  Trying to be
NT4-compatible seems to be an unnecesarily painful way to do things.

Peter.


From broonie@sirena.org.uk  Mon May 27 11:47:01 2002
From: broonie@sirena.org.uk (Mark Brown)
Date: Mon May 27 10:47:01 2002
Subject: Re[4]: A modified version of GnuPG
In-Reply-To: <200205270735.TAA74949@ruru.cs.auckland.ac.nz>
References: <200205270735.TAA74949@ruru.cs.auckland.ac.nz>
Message-ID: <20020527084805.GA848@sirena.org.uk>

--6c2NcOVqGQ03X4Wi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, May 27, 2002 at 07:35:21PM +1200, Peter Gutmann wrote:

> You have to make a tradeoff, either be backwards-compatible with NT4 (whi=
ch I
> doubt is still widely used except maybe on a few servers which no-one wan=
ts to
> touch) and face an incredibly difficult task of writing an NT kernel driv=
er to

There's still a reasonable number of deployed NT 4 systems, including
desktops.  Often it's a case of "it's not broken for us" and not/or
wanting to go to the effort of moving off a platform that has been
reliable and stable until the last possible minute.

> do it, or require Win2K and have Microsoft do most of it for you.  Trying=
 to be
> NT4-compatible seems to be an unnecesarily painful way to do things.

I do agree with the conclusion, though.

--=20
"You grabbed my hand and we fell into it, like a daydream - or a fever."

--6c2NcOVqGQ03X4Wi
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE88fLEJ2Vo11xhU60RAnZqAJ9cdalOD86O1R9XHso7ORws3ZkyRwCeLdEh
zefwGwEl3R5XV7OanXhSmZc=
=2+Eo
-----END PGP SIGNATURE-----

--6c2NcOVqGQ03X4Wi--


From disastry@saiknes.lv  Mon May 27 12:18:02 2002
From: disastry@saiknes.lv (disastry@saiknes.lv)
Date: Mon May 27 11:18:02 2002
Subject: Re[4]: A modified version of GnuPG
Message-ID: <3CF1E23A.24C83E24@saiknes.lv>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Max V. Zinal wrote:
> 
> PG> You don't need to do that, there are already user-level functions which do
> PG> this.  To save me having to regurgitate it all again, search sci.crypt or the
> PG> archives of Perry Metzger's crypto list for "AllocateUserPhysicalPages" to find
> PG> the details.
> 
> I  know about these functions. Please note that they are the part
> of  Address  Windowing  Extensions  (AWE), and thus are supported
> only  with W2K or higher. We should also remember that Windows NT
> 4 is still widely used.

so just call GetProcAderss(hKernel32,"AllocateUserPhysicalPages");
to find if the function is available, if yes - use it :)

__
Disastry  http://disastry.dhs.org/
http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon
 ^----PGP 2.6.3ia-multi06 (supports IDEA, CAST5, BLOWFISH, TWOFISH,
      AES, 3DES ciphers and MD5, SHA1, RIPEMD160, SHA2 hashes)
-----BEGIN PGP SIGNATURE-----
Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1

iQA/AwUBPPHFvjBaTVEuJQxkEQNNOQCcCOw75WYyyyORl+IDWPnldvTOHiYAoMn6
nTM1sXjGVJSkewvIIlSY9NyA
=c7hS
-----END PGP SIGNATURE-----


From rjhansen@inav.net  Mon May 27 13:11:01 2002
From: rjhansen@inav.net (Robert J. Hansen)
Date: Mon May 27 12:11:01 2002
Subject: Unpredictable GPGME bug
Message-ID: <Pine.LNX.4.44L0.0205270506070.16314-100000@soli.inav.net>

Looks like there might be a bug in GPGME (I know, pre-1.0 software with 
bugs--what's the world coming to?).  My C++ bindings for GPGME attempt to 
grab all sorts of string data for a given key, and sometimes it will be 
able to grab a string representation of the algorithm type and other times 
it'll segfault.  The offending snippet of code looks like:

GpgmeKey _key;
std::string _algo;

_algo = gpgme_key_get_string_attr(_key, GPGME_ATTR_ALGO, NULL, 0);

... Maybe one time in ten, that line of code will segfault.  
gpgme_key_get_string_attr apparently returns a NULL pointer, and trying to 
make a C++ std::string out of a NULL pointer is an instant segfault.

This has happened for other string quantities, such as usernames, etc.  
For now, my solution is to assign the result of g_k_g_s_a() to a const 
char*, test the const char* against NULL, and then assign either the const 
char* to _algo or else assign "Unassigned" to _algo.  However, this is 
fairly inelegant given that we could just fix the GPGME code.  :)





From rjhansen@inav.net  Mon May 27 14:23:02 2002
From: rjhansen@inav.net (Robert J. Hansen)
Date: Mon May 27 13:23:02 2002
Subject: GPGME wishlist...
Message-ID: <Pine.LNX.4.44L0.0205270600470.7300-100000@soli.inav.net>

*  The terminology in the documentation is a little awkward when it comes 
to signatures (on keys/user IDs).  For instance, there's a section on 
"Trust Items"--well, yeah, signatures tell us if a key/userid is or isn't 
trusted... on the other hand, gpgme_key_get_string_attr says that it's 
used for "attributes of sub keys and user IDs", and a signature is an 
attribute of those, so... etc.  It appears that both interfaces are 
necessary to some degree, but the docs never make it clear to what degree 
each are necessary.

*  How to get key signature information is a little 
awkward/counterintuitive.  For instance, according to my current (limited) 
understanding of the interface, in order to process key signatures I must:

1.  call gpgme_op_trustlist_start, passing in a 16-hex key ID to uniquely 
identify the key I want to iterate over

2.  start pulling trust items off the key

3.  get each item's GPGME_ATTR_USERID

4.  ... and only then can I associate a given trust item with a given user 
ID.

Please note: I haven't written code that works this way yet.  This is just 
the way I understand it to be, from looking at the docs.  If I'm 
misunderstanding, then please take my idiocy as evidence the docs need to 
be written for congenital idiots such as myself (grin).  If I'm not 
misunderstanding the docs, then it seems like we're making the process 
tougher than it needs to be.

Possible solution: add a new function,

gpgme_op_trustlist_uid_start(
	GpgmeCtx ctx,
	const char *hexID,
	int userID,
	int max_level
	)

... which would act just like gpgme_op_trustlist_start, except it would 
restrict the iteration to a given user ID.  This would make things a 
little easier for those of us who aren't geniuses.  :)

It's 6:20am and now I'm going to bed.  Thanks, guys.
	



From Marcus.Brinkmann@ruhr-uni-bochum.de  Mon May 27 14:54:02 2002
From: Marcus.Brinkmann@ruhr-uni-bochum.de (Marcus Brinkmann)
Date: Mon May 27 13:54:02 2002
Subject: Unpredictable GPGME bug
In-Reply-To: <Pine.LNX.4.44L0.0205270506070.16314-100000@soli.inav.net>
References: <Pine.LNX.4.44L0.0205270506070.16314-100000@soli.inav.net>
Message-ID: <20020527115449.GB1180@212.23.136.22>

On Mon, May 27, 2002 at 05:12:24AM -0500, Robert J. Hansen wrote:
> Looks like there might be a bug in GPGME (I know, pre-1.0 software with 
> bugs--what's the world coming to?).  My C++ bindings for GPGME attempt to 
> grab all sorts of string data for a given key, and sometimes it will be 
> able to grab a string representation of the algorithm type and other times 
> it'll segfault.  The offending snippet of code looks like:
> 
> GpgmeKey _key;
> std::string _algo;
> 
> _algo = gpgme_key_get_string_attr(_key, GPGME_ATTR_ALGO, NULL, 0);
> 
> ... Maybe one time in ten, that line of code will segfault.  

What do you mean?  one out of ten times you run this on the same key, or for
one out of ten keys?

Let's look at the code:
    case GPGME_ATTR_ALGO:
      for (k = &key->keys; k && idx; k=k->next, idx--)
        ;
      if (k)
        val = pkalgo_to_string (k->key_algo);
      break;

So, if _key is really a key (and not NULL itself), which contains at least
one subkey (key->keys)), then this can not return NULL, because
pkalgo_to_string doesn't return NULL.

You could let it crash in gdb and check what the key and key->keys look
like in the case it is failing.

> gpgme_key_get_string_attr apparently returns a NULL pointer, and trying to 
> make a C++ std::string out of a NULL pointer is an instant segfault.
> 
> This has happened for other string quantities, such as usernames, etc.  
> For now, my solution is to assign the result of g_k_g_s_a() to a const 
> char*, test the const char* against NULL, and then assign either the const 
> char* to _algo or else assign "Unassigned" to _algo.  However, this is 
> fairly inelegant given that we could just fix the GPGME code.  :)

Most properties are optional and can return NULL, so you must catch the NULL
case anyway.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de


From aphex@nullify.org  Mon May 27 19:54:02 2002
From: aphex@nullify.org (Keith Ray)
Date: Mon May 27 18:54:02 2002
Subject: Photo ID race condition
Message-ID: <1022518490.3cf264daeba39@mail.nullify.org>

There is a (non-security) race condition in the photo ID code under
Windows.  If the user has a slow loading image viewer (ie. Mozilla), GnuPG could
delete the temp file before the viewer finishes initializing.  I can think of a
number of solutions:

1. Wait for the viewer to exit before returning to GnuPG.
2. Insert a delay between exec_read() and exec_finish().  Then again, on a slow
system with little RAM, how much is enough?
3. Delay deleting the temp files until GnuPG exits.

  -- Keith


From dmitri@users.sourceforge.net  Mon May 27 20:19:01 2002
From: dmitri@users.sourceforge.net (Dmitri)
Date: Mon May 27 19:19:01 2002
Subject: Photo ID race condition
In-Reply-To: <1022518490.3cf264daeba39@mail.nullify.org>
References: <1022518490.3cf264daeba39@mail.nullify.org>
Message-ID: <1022520028.3628.40.camel@usb.networkfab.com>

--=-AzaZ68uR4RPMwOrnXu5h
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Mon, 2002-05-27 at 09:54, Keith Ray wrote:

> There is a (non-security) race condition in the photo ID code under
> Windows.  If the user has a slow loading image viewer (ie. Mozilla), GnuP=
G could
> delete the temp file before the viewer finishes initializing.  I can thin=
k of a
> number of solutions:
>=20
> 1. Wait for the viewer to exit before returning to GnuPG.

GnuPG actually won't stop running. But this seems to be the right
solution. See CreateProcess() and OpenProcess() here:

http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/dllproc/=
prothred_9dpv.asp

> 2. Insert a delay between exec_read() and exec_finish().  Then again, on =
a slow
> system with little RAM, how much is enough?

Fudge factor works only in 27% of all cases ;-)

> 3. Delay deleting the temp files until GnuPG exits.

Dmitri


--=-AzaZ68uR4RPMwOrnXu5h
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA88mrcXksyLpO6T4IRArRkAKCZkrFAjDwHkuaFdDrELgC9ztS9PwCfS4pY
ahMRn0RVeY4yLBGuc9XW8us=
=x11+
-----END PGP SIGNATURE-----

--=-AzaZ68uR4RPMwOrnXu5h--



From wk@gnupg.org  Mon May 27 21:03:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Mon May 27 20:03:01 2002
Subject: A modified version of GnuPG
In-Reply-To: <3CF1E23A.24C83E24@saiknes.lv> (disastry@saiknes.lv's message
 of "Mon, 27 May 2002 09:37:30 +0200")
References: <3CF1E23A.24C83E24@saiknes.lv>
Message-ID: <87lma5mpmp.fsf@alberti.gnupg.de>

On Mon, 27 May 2002 09:37:30 +0200, disastry  said:

> so just call GetProcAderss(hKernel32,"AllocateUserPhysicalPages");
> to find if the function is available, if yes - use it :)

I'll see what I can do.  I have to incorporate some RNG enhancements from
Cryptlib anyway.


Salam-Shalom,

   Werner



From wk@gnupg.org  Mon May 27 21:07:02 2002
From: wk@gnupg.org (Werner Koch)
Date: Mon May 27 20:07:02 2002
Subject: GPGME wishlist...
In-Reply-To: <Pine.LNX.4.44L0.0205270600470.7300-100000@soli.inav.net> ("Robert
 J. Hansen"'s message of "Mon, 27 May 2002 06:23:29 -0500 (CDT)")
References: <Pine.LNX.4.44L0.0205270600470.7300-100000@soli.inav.net>
Message-ID: <87hektmper.fsf@alberti.gnupg.de>

On Mon, 27 May 2002 06:23:29 -0500 (CDT), Robert J Hansen said:

> *  How to get key signature information is a little 
> awkward/counterintuitive.  For instance, according to my current (limited) 
> understanding of the interface, in order to process key signatures I must:

Frankly, there is no interface for it.  


> 1.  call gpgme_op_trustlist_start, passing in a 16-hex key ID to

This is an expermimental - I hope the manual says so, but I am not
sure.  


Shalom-Salam,

   Werner



From andrew@mcdonald.org.uk  Mon May 27 21:19:01 2002
From: andrew@mcdonald.org.uk (Andrew McDonald)
Date: Mon May 27 20:19:01 2002
Subject: Photo ID race condition
In-Reply-To: <1022518490.3cf264daeba39@mail.nullify.org>
References: <1022518490.3cf264daeba39@mail.nullify.org>
Message-ID: <20020527181933.GA969@mcdonald.org.uk>

On Mon, May 27, 2002 at 11:54:50AM -0500, Keith Ray wrote:
> There is a (non-security) race condition in the photo ID code under
> Windows.  If the user has a slow loading image viewer (ie. Mozilla),
> GnuPG could delete the temp file before the viewer finishes
> initializing.

This is an issue I have seen mentioned in connection with mutt's
viewing of attachments. Try searching for mutt_bgrun, a script that
provides one way to solve this.

-- 
Andrew McDonald
E-mail: andrew@mcdonald.org.uk
http://www.mcdonald.org.uk/andrew/


From dshaw@jabberwocky.com  Tue May 28 01:51:01 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Tue May 28 00:51:01 2002
Subject: Photo ID race condition
In-Reply-To: <1022518490.3cf264daeba39@mail.nullify.org>
References: <1022518490.3cf264daeba39@mail.nullify.org>
Message-ID: <20020527223655.GB813@akamai.com>

On Mon, May 27, 2002 at 11:54:50AM -0500, Keith Ray wrote:
> There is a (non-security) race condition in the photo ID code under
> Windows.  If the user has a slow loading image viewer (ie. Mozilla), GnuPG could
> delete the temp file before the viewer finishes initializing.  I can think of a
> number of solutions:
> 
> 1. Wait for the viewer to exit before returning to GnuPG.
> 2. Insert a delay between exec_read() and exec_finish().  Then again, on a slow
> system with little RAM, how much is enough?
> 3. Delay deleting the temp files until GnuPG exits.

This is a known problem with 1.0.7 (1.0.7 was never really intended
for widespread Win32 use).  Until 1.0.8 is released with a
non-system()-based implementation of the exec code, you have a few
options:

1) Patch the code based on the CVS
2) Use %I instead of %i in your photo-viewer command line
3) Try a photo-viewer of "start /w %i.jpg"

(#3 should work but I haven't tested it - I'm traveling and have no
access to a windows box at the moment)

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From aphex@nullify.org  Tue May 28 04:40:01 2002
From: aphex@nullify.org (Keith Ray)
Date: Tue May 28 03:40:01 2002
Subject: Photo ID race condition
Message-ID: <1022550030.3cf2e00e4d1e1@mail.nullify.org>

Quoting David Shaw <dshaw@jabberwocky.com>:
> On Mon, May 27, 2002 at 11:54:50AM -0500, Keith Ray wrote:
> > There is a (non-security) race condition in the photo ID code under
> > Windows.  If the user has a slow loading image viewer (ie. Mozilla), GnuPG
> > could delete the temp file before the viewer finishes initializing.  I can
> > think of a number of solutions:
> >
> > 1. Wait for the viewer to exit before returning to GnuPG.
> > 2. Insert a delay between exec_read() and exec_finish().  Then again, on a
> > slow system with little RAM, how much is enough?
> > 3. Delay deleting the temp files until GnuPG exits.
>
> This is a known problem with 1.0.7 (1.0.7 was never really intended
> for widespread Win32 use).  Until 1.0.8 is released with a
> non-system()-based implementation of the exec code, you have a few
> options:
>
> 1) Patch the code based on the CVS
> 2) Use %I instead of %i in your photo-viewer command line
> 3) Try a photo-viewer of "start /w %i.jpg"
>
> (#3 should work but I haven't tested it - I'm traveling and have no
> access to a windows box at the moment)

Hmm, I should have been more explicit on my setup ;)  I was using 1.0.7a-cvs
from May 24.  The photo viewer was the default:

#define DEFAULT_PHOTO_COMMAND "start /w %i"

Mozilla is the default .jpg viewer.   For some reason, execution returns to
GnuPG immediately after launching Mozilla.  Mozilla does not finish loading
itself and then the picture before GnuPG deletes the temporary directory and
file.  Thus, solution #3 isn't working.

Unless there is a way to modify the "start" command to actually wait when
launching an object file instead of an executable, I think the best route would
be to read the registry to find the default viewer and then "start" that.

I will code up a patch against CVS and e-mail it to you when I'm done.

  -- Keith


From dshaw@jabberwocky.com  Tue May 28 05:30:02 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Tue May 28 04:30:02 2002
Subject: Photo ID race condition
In-Reply-To: <1022550030.3cf2e00e4d1e1@mail.nullify.org>
References: <1022550030.3cf2e00e4d1e1@mail.nullify.org>
Message-ID: <20020528023032.GE813@akamai.com>

On Mon, May 27, 2002 at 08:40:30PM -0500, Keith Ray wrote:
> Hmm, I should have been more explicit on my setup ;)  I was using 1.0.7a-cvs
> from May 24.  The photo viewer was the default:
> 
> #define DEFAULT_PHOTO_COMMAND "start /w %i"
> 
> Mozilla is the default .jpg viewer.   For some reason, execution returns to
> GnuPG immediately after launching Mozilla.  Mozilla does not finish loading
> itself and then the picture before GnuPG deletes the temporary directory and
> file.  Thus, solution #3 isn't working.

It looks like Mozilla is being "helpful" here and returning control
before doing the requested command.  If that is the case, then this is
not something that GnuPG can address.  Are you sure that is what is
happening?  What happens when you do "start /w foobar.jpg" from the
command line on some other jpg you may have lying around?

> Unless there is a way to modify the "start" command to actually wait
> when launching an object file instead of an executable, I think the
> best route would be to read the registry to find the default viewer
> and then "start" that.

GnuPG is a crypto program, and reading the registry to figure out
photo viewers is getting too far astray from that core functionality.
This is where bugs come in and bugs in crypto software can be very
dangerous.  I did add generic call-a-program functionality because it
is usable in several places (keyservers as well as photo IDs) but it
must be kept simple and easily verifiable.

In any event, the whole point of "start" itself is to read the
registry and start the appropriate program, so there is no point in
adding code to do this to GnuPG.

> I will code up a patch against CVS and e-mail it to you when I'm done.

The "/w" flag for start means "wait".  Unfortunately, it seems that
Mozilla's start-in-the-background feature defeats this.  If that is
what is happening then there is nothing that can (easily) be done here
with start or even internal to GnuPG since it can only wait for a
program that does not start in the background (some viewers give you a
choice).

If you must use Mozilla as your viewer, then use %I in your
photo-viewer rather than %i (that is, capital "I" rather than
lowercase "i").  This will make GnuPG not delete the temp file at all,
so you will need to delete it yourself when you are done with it.

Like I said before, 1.0.8 has a slightly different implementation (not
yet checked in, so you won't see it in CVS) that allows for better
handling of arguments in the photo-viewer command line, but there is
very little that can be done about the start-in-the-background
problem.  If it makes you feel any better, it's the same way on Unix
when using temp files, but at least the Unix viewers usually aren't
written to background themselves automatically.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From keith@nullify.org  Tue May 28 11:48:01 2002
From: keith@nullify.org (Keith Ray)
Date: Tue May 28 10:48:01 2002
Subject: Photo ID race condition
In-Reply-To: <20020527223655.GB813@akamai.com>
References: <1022518490.3cf264daeba39@mail.nullify.org> <20020527223655.GB813@akamai.com>
Message-ID: <1022550003.3cf2dff3e2115@mail.nullify.org>

Quoting David Shaw <dshaw@jabberwocky.com>:
> On Mon, May 27, 2002 at 11:54:50AM -0500, Keith Ray wrote:
> > There is a (non-security) race condition in the photo ID code under
> > Windows.  If the user has a slow loading image viewer (ie. Mozilla), GnuPG
> > could delete the temp file before the viewer finishes initializing.  I can
> > think of a number of solutions:
> > 
> > 1. Wait for the viewer to exit before returning to GnuPG.
> > 2. Insert a delay between exec_read() and exec_finish().  Then again, on a
> > slow system with little RAM, how much is enough?
> > 3. Delay deleting the temp files until GnuPG exits.
> 
> This is a known problem with 1.0.7 (1.0.7 was never really intended
> for widespread Win32 use).  Until 1.0.8 is released with a
> non-system()-based implementation of the exec code, you have a few
> options:
> 
> 1) Patch the code based on the CVS
> 2) Use %I instead of %i in your photo-viewer command line
> 3) Try a photo-viewer of "start /w %i.jpg"
> 
> (#3 should work but I haven't tested it - I'm traveling and have no
> access to a windows box at the moment)

Hmm, I should have been more explicit on my setup ;)  I was using 1.0.7a-cvs
from May 24.  The photo viewer was the default:

#define DEFAULT_PHOTO_COMMAND "start /w %i"

Mozilla is the default .jpg viewer.   For some reason, execution returns to
GnuPG immediately after launching Mozilla.  Mozilla does not finish loading
itself and then the picture before GnuPG deletes the temporary directory and
file.  Thus, solution #3 isn't working.

Unless there is a way to modify the "start" command to actually wait when
launching an object file instead of an executable, I think the best route would
be to read the registry to find the default viewer and then "start" that.

I will code up a patch against CVS and e-mail it to you when I'm done.

  -- Keith


From wk@gnupg.org  Tue May 28 12:33:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Tue May 28 11:33:01 2002
Subject: Photo ID race condition
In-Reply-To: <1022550003.3cf2dff3e2115@mail.nullify.org> (Keith Ray's
 message of "Mon, 27 May 2002 20:40:03 -0500")
References: <1022518490.3cf264daeba39@mail.nullify.org>
 <20020527223655.GB813@akamai.com>
 <1022550003.3cf2dff3e2115@mail.nullify.org>
Message-ID: <87elfwlim1.fsf@alberti.gnupg.de>

On Mon, 27 May 2002 20:40:03 -0500, Keith Ray said:

> Unless there is a way to modify the "start" command to actually wait when
> launching an object file instead of an executable, I think the best route would
> be to read the registry to find the default viewer and then "start" that.

> I will code up a patch against CVS and e-mail it to you when I'm done.

You better write a wrapper taking care of of starting the default
image viewer and deleting the temporary file.  I don't think it is a
good idea to add this extra code to gpg.


Shalom-Salam,

   Werner



From wagner@tik.ee.ethz.ch  Wed May 29 07:27:01 2002
From: wagner@tik.ee.ethz.ch (wagner@tik.ee.ethz.ch)
Date: Wed May 29 06:27:01 2002
Subject: Mail delivery failed
Message-ID: <200205290427.GAA04870@tik2.ethz.ch>

The mail system has received a message appearently from you
that had the following header fields:

    From:     gnupg-devel-request@gnupg.org
    Subject:  Gnupg-devel digest, Vol 1 #373 - 2 msgs
    To:       gnupg-devel@gnupg.org
    Date:     Wed, 29 May 2002 06:25:43 +0200

The message has been deleted automatically for the following reason:

SPAM detected. Mail dropped.


This message has been generated automatically.


------------------------------------------------------------------------------
Arno Wagner           Dipl. Inform.          wagner@tik.ee.ethz.ch
 A modern US Navy cruiser now requires 26 tons of manuals. This is enough to 
 affect the vessel's performance. -- New Scientist on the paperless office
 
 Spam will get you reported to your ISP. I explicitely forbid you 
 to store my email address for purpose of reselling or spamming. 
 


From aphex@nullify.org  Thu May 30 06:00:03 2002
From: aphex@nullify.org (Keith Ray)
Date: Thu May 30 05:00:03 2002
Subject: Bug in parse_one_sig_subpkt ?
Message-ID: <1022727633.3cf595d1916a9@mail.nullify.org>

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

I think I have found a bug in the latest GnuPG v1.0.7a-cvs
(29-May-2002).  When generating a new keypair, build_sig_subpkt() calls
parse_one_sig_subpkt() with a type of SIGSUBPKT_KS_FLAGS.  Since there
is no 'case' for SIGSUBPKT_KS_FLAGS, parse_one_sig_subpkt() returns -1
and GnuPG fails.

  -- Keith

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7a-nr1 (Windows 2000) - GPGshell v2.30

iD8DBQE89ZWIBxrjkHkmmhIRAhvJAKCJweZVl8dt6muA4GBNZwVagmHd2gCdGQ5G
+MrsxTOmFINxe7ek6/MoVH0=
=FJc2
-----END PGP SIGNATURE-----


From dshaw@jabberwocky.com  Thu May 30 06:32:02 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Thu May 30 05:32:02 2002
Subject: Bug in parse_one_sig_subpkt ?
In-Reply-To: <1022727633.3cf595d1916a9@mail.nullify.org>
References: <1022727633.3cf595d1916a9@mail.nullify.org>
Message-ID: <20020530033209.GC6908@akamai.com>

On Wed, May 29, 2002 at 10:00:33PM -0500, Keith Ray wrote:

> I think I have found a bug in the latest GnuPG v1.0.7a-cvs
> (29-May-2002).  When generating a new keypair, build_sig_subpkt() calls
> parse_one_sig_subpkt() with a type of SIGSUBPKT_KS_FLAGS.  Since there
> is no 'case' for SIGSUBPKT_KS_FLAGS, parse_one_sig_subpkt() returns -1
> and GnuPG fails.

Fixed.  Thank you.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From keith@nullify.org  Thu May 30 12:00:01 2002
From: keith@nullify.org (Keith Ray)
Date: Thu May 30 11:00:01 2002
Subject: Bug in parse_one_sig_subpkt ?
Message-ID: <1022727578.3cf5959a34c68@mail.nullify.org>

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

I think I have found a bug in the latest GnuPG v1.0.7a-cvs
(29-May-2002).  When generating a new keypair, build_sig_subpkt() calls
parse_one_sig_subpkt() with a type of SIGSUBPKT_KS_FLAGS.  Since there
is no 'case' for SIGSUBPKT_KS_FLAGS, parse_one_sig_subpkt() returns -1
and GnuPG fails.

  -- Keith

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7a-nr1 (Windows 2000) - GPGshell v2.30

iD8DBQE89ZWIBxrjkHkmmhIRAhvJAKCJweZVl8dt6muA4GBNZwVagmHd2gCdGQ5G
+MrsxTOmFINxe7ek6/MoVH0=
=FJc2
-----END PGP SIGNATURE-----


From wagner@tik.ee.ethz.ch  Thu May 30 12:01:01 2002
From: wagner@tik.ee.ethz.ch (wagner@tik.ee.ethz.ch)
Date: Thu May 30 11:01:01 2002
Subject: Mail delivery failed
Message-ID: <200205300902.LAA17729@tik2.ethz.ch>

The mail system has received a message appearently from you
that had the following header fields:

    From:     gnupg-devel-request@gnupg.org
    Subject:  Gnupg-devel digest, Vol 1 #374 - 3 msgs
    To:       gnupg-devel@gnupg.org
    Date:     Thu, 30 May 2002 06:25:43 +0200

The message has been deleted automatically for the following reason:

SPAM detected. Mail dropped.


This message has been generated automatically.


------------------------------------------------------------------------------
Arno Wagner           Dipl. Inform.          wagner@tik.ee.ethz.ch
 A modern US Navy cruiser now requires 26 tons of manuals. This is enough to 
 affect the vessel's performance. -- New Scientist on the paperless office
 
 Spam will get you reported to your ISP. I explicitely forbid you 
 to store my email address for purpose of reselling or spamming. 
 


From denis@ripe.net  Thu May 30 12:11:01 2002
From: denis@ripe.net (Denis Walker)
Date: Thu May 30 11:11:01 2002
Subject: dry run
Message-ID: <200205300908.g4U98NA09988@birch.ripe.net>

Hi guys

The man pages and your on line docs both say that dry run is not yet fully 
implemented. What does this mean? Can I safely use dry run to check the 
response before doing the changes?

cheers
denis



From denis@ripe.net  Thu May 30 12:16:01 2002
From: denis@ripe.net (Denis Walker)
Date: Thu May 30 11:16:01 2002
Subject: dry run
Message-ID: <200205300916.g4U9GlA14641@birch.ripe.net>

Hi guys

The man pages and your on line docs both say that dry run is not yet fully 
implemented. What does this mean? Can I safely use dry run to check the 
response before doing the changes?

cheers
denis





From wk@gnupg.org  Thu May 30 12:21:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Thu May 30 11:21:01 2002
Subject: Mail delivery failed
In-Reply-To: <200205300902.LAA17729@tik2.ethz.ch> (wagner@tik.ee.ethz.ch's
 message of "Thu, 30 May 2002 11:02:08 +0200 (MET DST)")
References: <200205300902.LAA17729@tik2.ethz.ch>
Message-ID: <87n0uif0ob.fsf@alberti.gnupg.de>

Hi!

I disapled you account until you get your spam "reporting" tool
right.  I'd suggest to remove it entirely because automated spam
reporting does more harm than real spam.


Shalom-Salam,

   Werner



From chris@netservers.co.uk  Thu May 30 12:44:02 2002
From: chris@netservers.co.uk (Chris Wilson)
Date: Thu May 30 11:44:02 2002
Subject: Mail delivery failed
In-Reply-To: <200205300902.LAA17729@tik2.ethz.ch>
Message-ID: <Pine.LNX.4.44.0205301043500.30283-100000@localhost>

Dear Wagner,

If you are going to treat this list as spam, would you please unsubscribe?

Cheers, Chris.

On Thu, 30 May 2002 wagner@tik.ee.ethz.ch wrote:

> The mail system has received a message appearently from you
> that had the following header fields:
> 
>     From:     gnupg-devel-request@gnupg.org
>     Subject:  Gnupg-devel digest, Vol 1 #374 - 3 msgs
>     To:       gnupg-devel@gnupg.org
>     Date:     Thu, 30 May 2002 06:25:43 +0200
> 
> The message has been deleted automatically for the following reason:
> 
> SPAM detected. Mail dropped.
> 
> 
> This message has been generated automatically.
> 
> 
> ------------------------------------------------------------------------------
> Arno Wagner           Dipl. Inform.          wagner@tik.ee.ethz.ch
>  A modern US Navy cruiser now requires 26 tons of manuals. This is enough to 
>  affect the vessel's performance. -- New Scientist on the paperless office
>  
>  Spam will get you reported to your ISP. I explicitely forbid you 
>  to store my email address for purpose of reselling or spamming. 
>  
> 
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
> 

-- 
   ___ __     _
 / __// / ,__(_)_  | Chris Wilson -- UNIX Firewall Lead Developer |
/ (_ / ,\/ _/ /_ \ | NetServers.co.uk http://www.netservers.co.uk |
\ _//_/_/_//_/___/ | 21 Signet Court, Cambridge, UK. 01223 576516 |



From denis@ripe.net  Thu May 30 14:47:01 2002
From: denis@ripe.net (Denis Walker)
Date: Thu May 30 13:47:01 2002
Subject: deleting a uid from a public key
Message-ID: <200205301148.g4UBmSA28404@birch.ripe.net>

Hi guys

According to your manual you can delete a uid from your local public key. But 
if someone else imports your key it merges the uids from the old and new keys. 
So the deletion does not take effect. The manual says in order to delete a uid 
from someone's public key you must first remove the key and them import the 
new key. Why does import not delete uids? Are there any security implications 
involved here? If I am updating keys should I always remove the key first and 
them import the new one?

cheers
denis



From dshaw@jabberwocky.com  Thu May 30 15:23:01 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Thu May 30 14:23:01 2002
Subject: deleting a uid from a public key
In-Reply-To: <200205301148.g4UBmSA28404@birch.ripe.net>
References: <200205301148.g4UBmSA28404@birch.ripe.net>
Message-ID: <20020530122316.GE6908@akamai.com>

On Thu, May 30, 2002 at 01:48:28PM +0200, Denis Walker wrote:
> Hi guys
> 
> According to your manual you can delete a uid from your local public
> key. But if someone else imports your key it merges the uids from
> the old and new keys.  So the deletion does not take effect. The
> manual says in order to delete a uid from someone's public key you
> must first remove the key and them import the new key. Why does
> import not delete uids? Are there any security implications involved
> here? If I am updating keys should I always remove the key first and
> them import the new one?

As you saw, deleting a uid does not really delete it - it will come
back when the key is merged with an earlier copy of itself.  There are
several reasons for this, the simplest being: how does GnuPG know
which is the "more recent" key?  For example, if I have a key with 3
uids, and I import the same key with 2 uids, does that mean that one
of the uids is to be deleted (the 2 uid version is newer) or should I
do nothing (the 3 uid version is newer).

To resolve this, OpenPGP allows a user to revoke a uid - a revoked uid
is present on the key but is not used.  If you have a uid that you
don't want to use any longer, use "revsig" to revoke the
self-signature on that uid.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From stephane@sente.ch  Thu May 30 19:11:02 2002
From: stephane@sente.ch (=?ISO-8859-1?Q?St=E9phane_Corth=E9sy?=)
Date: Thu May 30 18:11:02 2002
Subject: charset problem
Message-ID: <07E6337B-73E8-11D6-B149-0003936A3BE2@sente.ch>

Hi,

Is the following behavior correct?

The file ~/.gnupg/options contains an option "comment" with value "=E9=20=

eacute"; file has been saved using UTF8 encoding.
The file /tmp/test contains same text "=E9 eacute", but in iso-8859-1.

Performing the command

gpg --charset iso-8859-1 --clearsign /tmp/test

creates a new file /tmp/test.asc which contains invalid text: there is a=20=

mix of iso-8859-1 (for the body) and UTF8 (for the signature) charsets!

It seems that comment is copied as is, i.e. not converted to --charset=20=

(what is furthermore not always possible...), thus result is totally=20
unreadable.


(I'm working with GnuPG 1.0.7 on MacOS X 10.1.4.)

Cheers,

St=E9phane



From stephane@sente.ch  Thu May 30 19:23:02 2002
From: stephane@sente.ch (=?ISO-8859-1?Q?St=E9phane_Corth=E9sy?=)
Date: Thu May 30 18:23:02 2002
Subject: malloc problem
Message-ID: <A5359632-73E9-11D6-B149-0003936A3BE2@sente.ch>

Hi,

Running gpg 1.0.7 on MacOS X 10.1.4, I noticed a malloc problems. I type=20=

the following command:

gpg --debug 511 --charset utf-8 --no-force-v3-sigs --armor=20
--notation-data mycode=3Dmyvalue --clearsign

Then I enter my passphrase, the text to sign ("test") and CTRL-D, and=20
there is a (MacOS X specific) malloc warning. Can anyone reproduce the=20=

problem on another system having a malloc-protection too (guard pages)?
Problem is due to the notation-data presence.

Cheers,

St=E9phane

... [snipped]...
gpg: DBG: iobuf-7.0: underflow: eof
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

test
gpg: DBG: armor-filter: control: 5
gpg: DBG: iobuf-8.1: push `armor_filter'
gpg: DBG: armor-filter: control: 5
gpg: DBG: iobuf chain: 8.1 `armor_filter' filter_eof=3D0 start=3D0 len=3D0=

gpg: DBG: iobuf chain: 8.0 `file_filter(fd)' filter_eof=3D0 start=3D0 =
len=3D0
gpg: DBG: armor-filter: control: 1
*** malloc[4606]: Deallocation of a pointer not malloced: 0x20d2ff; This=20=

could be a double free(), or free() called with the middle of an=20
allocated block; Try setting environment variable MallocHelp to see=20
tools to help debug
gpg: DBG: mpi_alloc(160)
gpg: DBG: mpi_alloc_limb_space(160)
gpg: DBG: pubkey_sign: algo=3D17
...[snipped]...






From dshaw@jabberwocky.com  Thu May 30 20:14:01 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Thu May 30 19:14:01 2002
Subject: malloc problem
In-Reply-To: <A5359632-73E9-11D6-B149-0003936A3BE2@sente.ch>
References: <A5359632-73E9-11D6-B149-0003936A3BE2@sente.ch>
Message-ID: <20020530171410.GG6908@akamai.com>

On Thu, May 30, 2002 at 06:23:59PM +0200, St=E9phane Corth=E9sy wrote:
> Hi,
>=20
> Running gpg 1.0.7 on MacOS X 10.1.4, I noticed a malloc problems. I typ=
e=20
> the following command:
>=20
> gpg --debug 511 --charset utf-8 --no-force-v3-sigs --armor=20
> --notation-data mycode=3Dmyvalue --clearsign
>=20
> Then I enter my passphrase, the text to sign ("test") and CTRL-D, and=20
> there is a (MacOS X specific) malloc warning. Can anyone reproduce the=20
> problem on another system having a malloc-protection too (guard pages)?
> Problem is due to the notation-data presence.

This was already fixed.  Thanks for the report though. :)

David

--=20
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.co=
m/
+------------------------------------------------------------------------=
---+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From Marc.Mutz@uni-bielefeld.de  Fri May 31 01:10:02 2002
From: Marc.Mutz@uni-bielefeld.de (Marc Mutz)
Date: Fri May 31 00:10:02 2002
Subject: charset problem
In-Reply-To: <07E6337B-73E8-11D6-B149-0003936A3BE2@sente.ch>
References: <07E6337B-73E8-11D6-B149-0003936A3BE2@sente.ch>
Message-ID: <200205302342.29857@sendmail.mutz.com>

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 30 May 2002 18:12, St=E9phane Corth=E9sy wrote:
<snip>
> Is the following behavior correct?
>
> The file ~/.gnupg/options contains an option "comment" with value "=E9
> eacute"; file has been saved using UTF8 encoding.
> The file /tmp/test contains same text "=E9 eacute", but in iso-8859-1.
<snip>

The answer is simple: Don't use --comment with anything but US-ASCII=20
characters. Comment: is an _ASCII_ armor header. This name alone should=20
tell you why what you try is a bad idea.

Marc

=2D --=20
Marc Mutz <mutz@kde.org>
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE89pzE3oWD+L2/6DgRAn+HAJ4shlewFxf/3RFi2N69npX00Y/6WgCeJ0Xw
VTtAi1qZpPOMjlW9Fv2cuvg=3D
=3Du6/t
=2D----END PGP SIGNATURE-----



From keith@nullify.org  Fri May 31 07:52:01 2002
From: keith@nullify.org (Keith Ray)
Date: Fri May 31 06:52:01 2002
Subject: Photo ID viewer under Windows NT
Message-ID: <1022820757.3cf701952790a@mail.nullify.org>

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

I just tried the new method of calling the Photo ID viewer under
Windows.  Unfortunately, unlike system(), CreateProcess() does not get
interpretted through the system shell.  This means that only actual
executables can be run in CreateProcess(), not internal commands.  In
Windows 95/98/Me, "start" is actually start.exe.  Under Windows
NT/2k/XP, "start" is integrated into the shell and CreateProcess() fails
with "No such file or directory".  

You can still use CreateProcess() under NT, but you need to call:

cmd /c start /w %i

However, since 95 uses command.com instead of cmd.exe, this would fail
for those versions.

  -- Keith

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7a-nr1 (Windows 2000) - GPGshell v2.30

iD8DBQE89wGIBxrjkHkmmhIRAgckAJ0UrGhnSBGGEDXw12DHnkTKN07sKgCgidHE
Tu6W6+BlfQo4DoWHfV+YZ5I=
=vjL8
-----END PGP SIGNATURE-----


From dshaw@jabberwocky.com  Fri May 31 08:53:01 2002
From: dshaw@jabberwocky.com (David Shaw)
Date: Fri May 31 07:53:01 2002
Subject: Photo ID viewer under Windows NT
In-Reply-To: <1022820757.3cf701952790a@mail.nullify.org>
References: <1022820757.3cf701952790a@mail.nullify.org>
Message-ID: <20020531055358.GB2126@akamai.com>

On Thu, May 30, 2002 at 11:52:37PM -0500, Keith Ray wrote:

> I just tried the new method of calling the Photo ID viewer under
> Windows.  Unfortunately, unlike system(), CreateProcess() does not get
> interpretted through the system shell.  This means that only actual
> executables can be run in CreateProcess(), not internal commands.  In
> Windows 95/98/Me, "start" is actually start.exe.  Under Windows
> NT/2k/XP, "start" is integrated into the shell and CreateProcess() fails
> with "No such file or directory".  
> 
> You can still use CreateProcess() under NT, but you need to call:
> 
> cmd /c start /w %i
> 
> However, since 95 uses command.com instead of cmd.exe, this would fail
> for those versions.

So use the longer form?  I'm not sure what you're getting at
here. "start /w" doesn't work on NT, but neither does qiv or
xloadimage or any other other of the sample viewers.  The whole point
of the photo-viewer option is to set what viewer works for YOU and not
hard-code something in that may not work (or may work but not be what
you wanted: using "start" to read the registry doesn't work very well
if your .jpg viewer is photoshop, for example).

It's possible to use some conditional #defines to change the default
viewer at build time, but to what end?  Most people don't compile
their own win32 binary, and this would make the NT/2k/XP binary
different than 95/98/Me.

Remember: "start /w" is only the default.  If you don't like it (or if
it doesn't work on your system), change it.

If you're arguing that the default should be "cmd /c start /w", then
maybe - but it'll break the default for the 95/98/Me people.  I have
no strong feelings on which platform gets the 'better' default.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From avbidder@fortytwo.ch  Fri May 31 11:42:01 2002
From: avbidder@fortytwo.ch (Adrian 'Dagurashibanipal' von Bidder)
Date: Fri May 31 10:42:01 2002
Subject: charset problem
In-Reply-To: <200205302342.29857@sendmail.mutz.com>
References: <07E6337B-73E8-11D6-B149-0003936A3BE2@sente.ch>
 <200205302342.29857@sendmail.mutz.com>
Message-ID: <1022834611.25778.32.camel@atlas>

--=-O8C6NegOgiq8lsGL6BBq
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Thu, 2002-05-30 at 23:42, Marc Mutz wrote:

> The answer is simple: Don't use --comment with anything but US-ASCII=20
> characters. Comment: is an _ASCII_ armor header. This name alone should=20
> tell you why what you try is a bad idea.

Just curious: is there anything said (rfc, developer opinion, ...) about
the =3D?charset?x?encoded string?=3D encoding in armor headers?

cheers
-- vbi


--=20
secure email with gpg            avbidder@fortytwo.ch: key id 0x92082481
                                 avbidder@acter.ch:    key id 0x5E4B731F


--=-O8C6NegOgiq8lsGL6BBq
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA89zezwj49sl5Lcx8RAvYUAKCNXgrMfyRIItVFSOIuC1PKww+fOACfQX7S
wDFoRgb5SEIRFcwhIVXR+I8=
=HUba
-----END PGP SIGNATURE-----

--=-O8C6NegOgiq8lsGL6BBq--



From chris@netservers.co.uk  Fri May 31 12:02:01 2002
From: chris@netservers.co.uk (Chris Wilson)
Date: Fri May 31 11:02:01 2002
Subject: Batch mode
Message-ID: <Pine.LNX.4.44.0205301744240.30657-100000@localhost>

Hi all,

There are a number of operations which are not currently supported in 
batch mode. They include:

- key generation
- key signing
- key deletion

I would be happy to write patches to add this functionality, but my past 
e-mails, suggestions and patches sent to this list have been completely 
ignored. Therefore, I will probably not write the patches unless somebody 
says they are interested. So please tell me if you are.

Cheers, Chris.
-- 
   ___ __     _
 / __// / ,__(_)_  | Chris Wilson -- UNIX Firewall Lead Developer |
/ (_ / ,\/ _/ /_ \ | NetServers.co.uk http://www.netservers.co.uk |
\ _//_/_/_//_/___/ | 21 Signet Court, Cambridge, UK. 01223 576516 |



From wk@gnupg.org  Fri May 31 13:47:02 2002
From: wk@gnupg.org (Werner Koch)
Date: Fri May 31 12:47:02 2002
Subject: charset problem
In-Reply-To: <1022834611.25778.32.camel@atlas> (Adrian 'Dagurashibanipal'
 von Bidder's message of "31 May 2002 10:43:31 +0200")
References: <07E6337B-73E8-11D6-B149-0003936A3BE2@sente.ch>
 <200205302342.29857@sendmail.mutz.com>
 <1022834611.25778.32.camel@atlas>
Message-ID: <87bsawd1yj.fsf@alberti.gnupg.de>

On 31 May 2002 10:43:31 +0200, Adrian 'Dagurashibanipal' von Bidder said:

> Just curious: is there anything said (rfc, developer opinion, ...) about
> the =?charset?x?encoded string?= encoding in armor headers?

No.  Please don't use the comment for any real purpose - this is just
a gadget with no real use.  If you want to encode other information
you should either use notation data (which is included in the
signature) or use MIME headers for that.  As you know, the Comment and
all other armor headers are not protected by the signature.


Salam-Shalom,

   Werner





From wagner@tik.ee.ethz.ch  Fri May 31 13:52:01 2002
From: wagner@tik.ee.ethz.ch (Arno Wagner)
Date: Fri May 31 12:52:01 2002
Subject: Me "spamming" this list...
In-Reply-To: <E17DdzF-0005CF-00@trithemius.gnupg.org>; from gnupg-devel-request@gnupg.org on Fri, May 31, 2002 at 06:25:42AM +0200
References: <E17DdzF-0005CF-00@trithemius.gnupg.org>
Message-ID: <20020531125315.B10807@tik.ee.ethz.ch>

--n8g4imXOkfNTN/H1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Dear gnupg-devel list members,

in the last 48 hours (or so) this list has received messages
from my spam-detector about spam being dropped.=20

I am sorry about this, please accept my apology!

I think I should explain what happened, so maybe others can=20
avoid the mistakes I made: I have a very manual spam filter,
that I maintain by just adding to my .procmailrc. For hard spammers
I just drop the mail, for others I had an auto-reply feature.=20
While I was careful all my receipes are restrictive enough not
to be overly trigger-happy, I did not take into account the
possibility for a different kind of error.=20

What I effectively did in one match-expression whas replace the
leading "*" with a "$". As a result this rule appearently matched for
every Email that came in. As a consequence every email to me got a
notification about it being spam and dropped, which also happened to
all the messages telling me there was something wrong on my side.

To make things worse, we had an announced partial network outage=20
on Wednsday (routing tables cleanup) so I was not suspicous about
not getting any email. I was not at work on Wednsday, so I=20
finally found out about the problem when somebody phoned me
Thursday morning.=20

At that time I had about 30 messages telling me about the problem
and about 400 Messages from a mail-loop, that happened despite=20
my measures to prevent loops.

Lessons learned on my side:

  - Don't send out automatic responses to, if the trigger-
    mechanism has a single point-of-failure!

    For the time being I make that: Don't send out any automated
    responses.=20

  - Doing full logging is a very good idea when automatically=20
    deleting messages! =20

    Because I at least got this right, I did not loose any=20
    messages and was able to identify everybody that I needed to
    apologize to.

  - If you screw up, apologize a.s.a.p. to those affected and
    explain what happened!    =20

  - Look at statistics frequently!=20

    My previous set-up gave me one spam-summary per week. That is=20
    not enough, now I am getting a daily summary. =20

  - Make sure you understand the problem!=20

    My mail-loop detection scheme used a field in the header with=20
    a magic number. That is fine for every loop that keeps the=20
    auto-response somewhere in the replys, but this one list-admin=20
    daemon just send me a completely fresh email about not=20
    understanding my command. Practical loop detection is obviously
    more complicated than I thought ....

Once again, please accept my apologies for this incident!

Regards,
Arno

--=20
Arno Wagner, Communication Systems Group, ETH Zuerich, wagner@tik.ee.ethz.ch
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
For every complex problem there is an answer that is clear, simple,=20
and wrong. -- H L Mencken





--n8g4imXOkfNTN/H1
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iEYEARECAAYFAjz3VhsACgkQeX9rUB4lM48uLQCghU0zkyXRytpzgoX4B0msXvw2
fIgAn1thxK02W4Ge0jlImr5nVYRRjP88
=tPIM
-----END PGP SIGNATURE-----

--n8g4imXOkfNTN/H1--


From wk@gnupg.org  Fri May 31 13:53:01 2002
From: wk@gnupg.org (Werner Koch)
Date: Fri May 31 12:53:01 2002
Subject: Batch mode
In-Reply-To: <Pine.LNX.4.44.0205301744240.30657-100000@localhost> (Chris
 Wilson's message of "Fri, 31 May 2002 10:02:13 +0100 (BST)")
References: <Pine.LNX.4.44.0205301744240.30657-100000@localhost>
Message-ID: <877klkd1qb.fsf@alberti.gnupg.de>

On Fri, 31 May 2002 10:02:13 +0100 (BST), Chris Wilson said:

> Hi all,
> There are a number of operations which are not currently supported in 
> batch mode. They include:

> - key generation

There is batch ke generation - see doc/DETAILS.

> - key signing
> - key deletion

This can't be done easily.  You need to present a lot of information
to the user so that he can decide wehther to sign or not.  Those
information vary from key to key and thus it can't be scripted.

We are working on a GPGME interface to do ease it up.  You may have
noticed problems with GPA when you don't use a standard key or use gpg
1.0.7.  This is due to a too simple approach to handle these
operations.

> I would be happy to write patches to add this functionality, but my past 
> e-mails, suggestions and patches sent to this list have been
> completely 

Sorry, That happens from time to time.  There is also the issue that
we need legal papers to include non-trivial patches.


Shalom-Salam,

   Werner



From chris@netservers.co.uk  Fri May 31 14:17:01 2002
From: chris@netservers.co.uk (Chris Wilson)
Date: Fri May 31 13:17:01 2002
Subject: Batch mode
In-Reply-To: <877klkd1qb.fsf@alberti.gnupg.de>
Message-ID: <Pine.LNX.4.44.0205311209080.30657-100000@localhost>

Hi Werner and the list,

> There is batch ke generation - see doc/DETAILS.

Sorry, my bad. This looks like what I need.

> This can't be done easily.  You need to present a lot of information
> to the user so that he can decide wehther to sign or not.  Those
> information vary from key to key and thus it can't be scripted.

In our environment the key is generated and immediately imported 
into another keyring and signed. There is no need to verify the identity 
of the key, etc. So it would be very useful for us to be able to sign 
automatically.

What objection is there to batch key deletion?

> We are working on a GPGME interface to do ease it up.  You may have
> noticed problems with GPA when you don't use a standard key or use gpg
> 1.0.7.  This is due to a too simple approach to handle these
> operations.

OK, but from what little I know of GPGME right now, it seems to be a 
powerful and complex API to using GPG. I don't need that, and it's not 
helpful for shell scripts. I just need to be able to automate the commands 
which I can give from the command line anyway.

> Sorry, That happens from time to time.  There is also the issue that
> we need legal papers to include non-trivial patches.

I am about to send in my papers to the FSF for some work I've done on Tar, 
but in any case I think these patches will be small enough that they 
shouldn't pose a legal problem for you. But I leave that to your 
discretion.

Ciao, Chris.
-- 
   ___ __     _
 / __// / ,__(_)_  | Chris Wilson -- UNIX Firewall Lead Developer |
/ (_ / ,\/ _/ /_ \ | NetServers.co.uk http://www.netservers.co.uk |
\ _//_/_/_//_/___/ | 21 Signet Court, Cambridge, UK. 01223 576516 |



From win at huh.org  Wed May  1 00:25:01 2002
From: win at huh.org (Winona Brown)
Date: Tue Oct  7 21:28:59 2003
Subject: AIX bug malloc(0)
Message-ID: <20020430212626.GA1048@arghh.huh.org>

make with aix5.1 compiler vac5 (xlc) was failing in checks until I added 
   if (n == 0)
       n = 1;
before calling malloc.

The technical reference for AIX 5L 5.1 says:

If the malloc or valloc subroutine is called with a size of 0, the subroutine
returns a null pointer

The better way to fix this would probably be to allow a NULL being returned
if malloc(0) was called.  

gnupg-1.0.7/util/memory.c

Winona



From redbird at rbisland.cx  Wed May  1 08:38:01 2002
From: redbird at rbisland.cx (Gordon Worley)
Date: Tue Oct  7 21:28:59 2003
Subject: gnupg 107 compilation on solaris 8
In-Reply-To: <200204301744.KAA00577@fionn.es.net>
Message-ID: <CB457866-5CC5-11D6-BDCA-000A27B4DEFC@rbisland.cx>

On Tuesday, April 30, 2002, at 01:44  PM, Michael Helm wrote:

>> ./configure --enable-static-rnd=unix
>
> Had exactly the same effect -- option apparently doesn't work

Trying throwing --disable-dynload into the mix.

--
Gordon Worley                     `When I use a word,' Humpty Dumpty
http://www.rbisland.cx/            said, `it means just what I choose
redbird@rbisland.cx                it to mean--neither more nor less.'
PGP:  0xBBD3B003                                  --Lewis Carroll



From BigBootyHoe69699 at aol.com  Wed May  1 11:02:01 2002
From: BigBootyHoe69699 at aol.com (BigBootyHoe69699@aol.com)
Date: Tue Oct  7 21:28:59 2003
Subject: Free Trail!! NO FEES!
Message-ID: <200204302358.DAA09114@cobi.coqui.net>

Mail from  (BigBootyHoe69699@aol.com) 
     on Wednesday, May 1, 2002 at 03:58:50
---------------------------------------------------------------------------

:: RIGHT NOW!  FREE Membership Available!  Don't know how long this offer will last, get it while you still can! We have BEAUTIFUL girls and they are just one click away from showing you the BEST time of your life! <a href="http://rd.yahoo.com/dir/?http://members.lycos.co.uk/g00dstuff">Click here</a>

---------------------------------------------------------------------------
A Service of Coqui.Net             bug-octave-request@bevo.che.utexas.edu,bug-octave@bevo.che.utexas.edu,help-octave-request@bevo.che.utexas.edu,help-octave@bevo.che.utexas.edu,announce-request@gnupg.org,gnupg-users-request@gnupg.org,gnupg-users@gnupg.org,gnupg-devel-request@gnupg.org,gnupg-devel@gnupg.org,bug-bison-request@gnu.org,


From BigBootyHoe69699 at aol.com  Wed May  1 11:11:02 2002
From: BigBootyHoe69699 at aol.com (BigBootyHoe69699@aol.com)
Date: Tue Oct  7 21:28:59 2003
Subject: Free Trail!! NO FEES!
Message-ID: <200205010008.EAA09698@cobi.coqui.net>

Mail from  (BigBootyHoe69699@aol.com) 
     on Wednesday, May 1, 2002 at 04:08:08
---------------------------------------------------------------------------

:: RIGHT NOW!  FREE Membership Available!  Don't know how long this offer will last, get it while you still can! We have BEAUTIFUL girls and they are just one click away from showing you the BEST time of your life! <a href="http://rd.yahoo.com/dir/?http://members.lycos.co.uk/g00dstuff">Click here</a>

---------------------------------------------------------------------------
A Service of Coqui.Net             bug-octave-request@bevo.che.utexas.edu,bug-octave@bevo.che.utexas.edu,help-octave-request@bevo.che.utexas.edu,help-octave@bevo.che.utexas.edu,announce-request@gnupg.org,gnupg-users-request@gnupg.org,gnupg-users@gnupg.org,gnupg-devel-request@gnupg.org,gnupg-devel@gnupg.org,bug-bison-request@gnu.org,


From hideki at allcity.net  Thu May  2 03:26:02 2002
From: hideki at allcity.net (Hideki Saito)
Date: Tue Oct  7 21:28:59 2003
Subject: 15MB files on photo
Message-ID: <200205020026.g420Qli28732@server-1.visp.net>

I found some problem with photo capability of 1.0.7 on Win32 
compilation.

If you try to display graphics, it is actually a bogus JPG file.

I have tried with the option i_view32 %i as a photo-viewer argument, 
and it returns "unknown header" error.

Then I tried i_view32 %I to see what actual "TEMP.JPG" is like, and it 
turns out be a 12MB - 15MB garbage file.

Is there any workaround to this?

-- 
Hideki Saito mailto:hideki@allcity.net


From dshaw at jabberwocky.com  Thu May  2 03:50:02 2002
From: dshaw at jabberwocky.com (David Shaw)
Date: Tue Oct  7 21:28:59 2003
Subject: 15MB files on photo
In-Reply-To: <200205020026.g420Qli28732@server-1.visp.net>
References: <200205020026.g420Qli28732@server-1.visp.net>
Message-ID: <20020502005106.GA25856@akamai.com>

On Wed, May 01, 2002 at 05:27:42PM -0700, Hideki Saito wrote:
> I found some problem with photo capability of 1.0.7 on Win32 
> compilation.
> 
> If you try to display graphics, it is actually a bogus JPG file.
> 
> I have tried with the option i_view32 %i as a photo-viewer argument, 
> and it returns "unknown header" error.
> 
> Then I tried i_view32 %I to see what actual "TEMP.JPG" is like, and it 
> turns out be a 12MB - 15MB garbage file.

Hmm.  Are you using a Mingw32 or Cygwin build?

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From hideki at allcity.net  Thu May  2 05:04:02 2002
From: hideki at allcity.net (Hideki Saito)
Date: Tue Oct  7 21:28:59 2003
Subject: 15MB files on photo
In-Reply-To: <20020502005106.GA25856@akamai.com>
References: <200205020026.g420Qli28732@server-1.visp.net>
	<20020502005106.GA25856@akamai.com>
Message-ID: <200205020205.g4225Fi03599@server-1.visp.net>

Mingw32 build it is...

>On Wed, May 01, 2002 at 05:27:42PM -0700, Hideki Saito wrote:
>> I found some problem with photo capability of 1.0.7 on Win32 
>> compilation.
>> 
>> If you try to display graphics, it is actually a bogus JPG file.
>> 
>> I have tried with the option i_view32 %i as a photo-viewer argument, 
>> and it returns "unknown header" error.
>> 
>> Then I tried i_view32 %I to see what actual "TEMP.JPG" is like, and it 
>> turns out be a 12MB - 15MB garbage file.
>
>Hmm.  Are you using a Mingw32 or Cygwin build?
>
>David
>
>-- 
>   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
>+---------------------------------------------------------------------------+
>   "There are two major products that come out of Berkeley: LSD and UNIX.
>      We don't believe this to be a coincidence." - Jeremy S. Anderson
>
>_______________________________________________
>Gnupg-devel mailing list
>Gnupg-devel@gnupg.org
>http://lists.gnupg.org/mailman/listinfo/gnupg-devel

-- 
Hideki Saito mailto:hideki@allcity.net


From mwy-gpg41 at the-youngs.org  Thu May  2 06:43:01 2002
From: mwy-gpg41 at the-youngs.org (Michael Young)
Date: Tue Oct  7 21:28:59 2003
Subject: feature request: always-trust [<keyring>]
References: <E172PDG-0002qc-00@trithemius.gnupg.org>
Message-ID: <003d01c1f18b$83100d60$c23fa8c0@transarc.ibm.com>

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

Jeff Breidenbach <jab@debian.org> asked for:
> What: ability to specify that everything in a specific
>       keyring will trusted by default.

This sounds like a reasonable request to me.  As you note, there
is already an "--always-trust" switch -- it's just global.
But I'm not one of the people you need to convince.

> Why:  In Debian, I can have a list of hundreds of developer=20
>       keys stored  in locally in /usr/share/keyrings/debian-keyring.gpg.
>       This file is trusted by me, dynamic, and is maintained by the
>       Debian Project. So I use the file as one of my keyrings.

I know you didn't ask for workarounds, but in case your request
isn't filled in a timely manner...

Could you convince whoever is maintaining the keyring to sign the keys
using some well-known "Debian Project" key?  Then, you could use the
existing trust mechanisms (up to and including the "--trusted-key"
switch).  This would also let you (or others) pick up keys from
keyservers, rather than rely purely on secure delivery of the shared
keyring file.

Failing that, you could automatically generate (local) signatures for
everything on the trusted keyring.  I would use a local key specific
to this purpose.  This requires some trickery: the "--batch" switch
disallows signing; the "--yes" switch has no effect.  It seems that
you need to use the "--command-fd" gadgetry (and in theory use the
"--status-fd" switch to know what to feed it), as in (using csh syntax):

    foreach x (`gpg --with-colons --list-keys | awk -F: '/^pub/{print $5}'`)
 echo YES | \
 gpg -u your_project_key --command-fd 0 --lsign-key $x
    end


While we're asking for features, I'll repeat my plea for one that
would help out on this workaround.  I'd sorely like to be able to use
the "--edit-key" commands (of which "--lsign" is a special case)
without having to deal with all of the questions.  It would be fine to
reuse an existing switch (like "--batch" or "--expert") or grow a new
one ("--just-do-it" or "--really-yes") to carry this meaning.
The same principle could be applied to disable the questions
about key size :-).

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQA/AwUBPNC1xFMkvpTT8vCGEQLqGQCgqMt4mcmi0OZOv543gBEwuY7H/8sAoOBV
0ESwD3C1sgvl99gAShvD9O3m
=tZW3
-----END PGP SIGNATURE-----




From wk at gnupg.org  Thu May  2 09:59:02 2002
From: wk at gnupg.org (Werner Koch)
Date: Tue Oct  7 21:28:59 2003
Subject: AIX bug malloc(0)
In-Reply-To: <20020430212626.GA1048@arghh.huh.org> (Winona Brown's message
 of "Tue, 30 Apr 2002 16:26:26 -0500")
References: <20020430212626.GA1048@arghh.huh.org>
Message-ID: <87znzjkpa0.fsf@alberti.gnupg.de>

On Tue, 30 Apr 2002 16:26:26 -0500, Winona Brown said:

> The better way to fix this would probably be to allow a NULL being returned
> if malloc(0) was called.  

Well yes, this would be better for debugging.  For now I took the easy
path out.

Thanks,

  Werner



From dbely at mail.ru  Thu May  2 19:04:02 2002
From: dbely at mail.ru (Dmitry Bely)
Date: Tue Oct  7 21:29:00 2003
Subject: 1.0.7 under Win32 
Message-ID: <r8kufslp.fsf@mail.ru>

I have found some minor problems in GnuPG 1.0.7 that prevent it from
compiling out of the box. I have also fixed the bug in write_server() that
existed from the very beginning (Win32 API function WriteFile() doesn't
work with TCP/IP sockets). Due to that all HTTP-related stuff
("--recv-keys" option etc.) was broken under Win32. Are you interested in
the patch?

Hope to hear from you soon,
Dmitry




From tracy_d at xypro.com  Thu May  2 21:22:02 2002
From: tracy_d at xypro.com (Tracy Ding)
Date: Tue Oct  7 21:29:00 2003
Subject: A question?
Message-ID: <32E0F1DAB878D511826D00A0CCD7949203EE55@xypro.com>

Hello,
Currently I am working on Gnupg 1.0.6 stuff. 
I installed Gnupg 1.0.6 in my pc.
The command "gpg --print-md SHA1 Keypc"
  the putput is "Keypc: 69BB D5CF 491B C3BB F286  143A 4BC9 F8E8 7DCD"

But in OSS system ( I upload the source codes to Tandem OSS, compiled them )
I got different result.
"
 gpg --print-md SHA1 Keypc
gpg: Please note that you don't have secure memory on this system
gpg: WARNING: program may create a core file!
Keypc: 8653 FDF4 2F70 F2E2 E2D9  AFD4 CB7F 2531 9A85 E088
$ "                          

I tested it for MD5, the result is different too. 
I am totally lost, any help is appreciated.


Regards

Tracy Ding

                        


From wk at gnupg.org  Fri May  3 09:25:02 2002
From: wk at gnupg.org (Werner Koch)
Date: Tue Oct  7 21:29:00 2003
Subject: A question?
In-Reply-To: <32E0F1DAB878D511826D00A0CCD7949203EE55@xypro.com> (Tracy
 Ding's message of "Thu, 2 May 2002 11:22:16 -0700")
References: <32E0F1DAB878D511826D00A0CCD7949203EE55@xypro.com>
Message-ID: <87elgtiw4c.fsf@alberti.gnupg.de>

On Thu, 2 May 2002 11:22:16 -0700, Tracy Ding said:

> But in OSS system ( I upload the source codes to Tandem OSS, compiled them )
> I got different result.

Did you got any compiler diagnostics when building it?

Am I right that most checks fail if you do a "make check"?



From dshaw at jabberwocky.com  Fri May  3 17:40:02 2002
From: dshaw at jabberwocky.com (David Shaw)
Date: Tue Oct  7 21:29:00 2003
Subject: 15MB files on photo
In-Reply-To: <200205020205.g4225Fi03599@server-1.visp.net>
References: <200205020026.g420Qli28732@server-1.visp.net> <20020502005106.GA25856@akamai.com> <200205020205.g4225Fi03599@server-1.visp.net>
Message-ID: <20020503144106.GD6647@akamai.com>

> >On Wed, May 01, 2002 at 05:27:42PM -0700, Hideki Saito wrote:
> >> I found some problem with photo capability of 1.0.7 on Win32 
> >> compilation.
> >> 
> >> If you try to display graphics, it is actually a bogus JPG file.
> >> 
> >> I have tried with the option i_view32 %i as a photo-viewer argument, 
> >> and it returns "unknown header" error.
> >> 
> >> Then I tried i_view32 %I to see what actual "TEMP.JPG" is like, and it 
> >> turns out be a 12MB - 15MB garbage file.
> >
> >Hmm.  Are you using a Mingw32 or Cygwin build?

On Wed, May 01, 2002 at 07:06:11PM -0700, Hideki Saito wrote:
> Mingw32 build it is...

The problem is forward slashes in the photo path.  Before you compile,
you need to change g10defs.h:

Change these:
#define DIRSEP_C '/'
#define DIRSEP_S "/"

To these:
#define DIRSEP_C '\\'
#define DIRSEP_S "\\"

The Win32 internals do allow either / or \, but the photo viewer uses
system(), and that calls command, and command does not allow forward
slashes.

As for the large garbage file in i_view32, I was able to duplicate the
problem here so I see it as well, but I don't know where the garbage
came from.  I suspect that i_view32 gets upset if it gets forward
slashes in a pathname.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From tracy_d at xypro.com  Sat May  4 00:26:01 2002
From: tracy_d at xypro.com (Tracy Ding)
Date: Tue Oct  7 21:29:00 2003
Subject: Help ...
Message-ID: <32E0F1DAB878D511826D00A0CCD7949203EE5D@xypro.com>

Hello,

I installed gnupg-1.0.7 into a linux machine. 
It is i486 machine. 
I got a probelm when generating a key pair.

"
Not enough random bytes available.  Please do some other work to give
the OS a chance to collect more entropy! (Need 300 more bytes)     
"
The program stuck there waiting for more bytes.
Any help is appreciated.


Thanks

Tracy Ding


From ajs at ajs.com  Sat May  4 00:56:01 2002
From: ajs at ajs.com (Aaron Sherman)
Date: Tue Oct  7 21:29:00 2003
Subject: Help ...
In-Reply-To: <32E0F1DAB878D511826D00A0CCD7949203EE5D@xypro.com>
References: <32E0F1DAB878D511826D00A0CCD7949203EE5D@xypro.com>
Message-ID: <1020463004.22284.38.camel@pps>

On Fri, 2002-05-03 at 17:26, Tracy Ding wrote:

> I installed gnupg-1.0.7 into a linux machine. 
> It is i486 machine. 
> I got a probelm when generating a key pair.
> 
> "
> Not enough random bytes available.  Please do some other work to give
> the OS a chance to collect more entropy! (Need 300 more bytes)     
> "
> The program stuck there waiting for more bytes.
> Any help is appreciated.

As the message suggests, you should do more work and let the OS collect
more random bytes. Go! Do work! ;-)




From mutz at kde.org  Sat May  4 01:07:02 2002
From: mutz at kde.org (Marc Mutz)
Date: Tue Oct  7 21:29:00 2003
Subject: Help ...
In-Reply-To: <32E0F1DAB878D511826D00A0CCD7949203EE5D@xypro.com>
References: <32E0F1DAB878D511826D00A0CCD7949203EE5D@xypro.com>
Message-ID: <200205040007.16685@sendmail.mutz.com>

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

[ reordering lines of original post ]

On Friday 03 May 2002 23:26, Tracy Ding wrote:
<snip>
> The program stuck there waiting for more bytes: <snip>
> Not enough random bytes available.  Please do some other work to give
> the OS a chance to collect more entropy! (Need 300 more bytes)
<snip>

Sorry, you _can_ read, can you? :-(
You can: start bonnie in the background, hit the keyboard monkey-style, move 
the mouse wildly (maybe dragging a window around), or all at once... :-o

Marc

- -- 
Marc Mutz <mutz@kde.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE80woT3oWD+L2/6DgRAgu4AKCCKdzJ2nXvolRZm98mjNNwek1VjACff0Uy
pNJ03crlAlHhb412P6omRw4=
=axlJ
-----END PGP SIGNATURE-----



From dmitri at users.sourceforge.net  Sat May  4 01:29:02 2002
From: dmitri at users.sourceforge.net (Dmitri)
Date: Tue Oct  7 21:29:00 2003
Subject: Help ...
In-Reply-To: <200205040007.16685@sendmail.mutz.com>
References: <32E0F1DAB878D511826D00A0CCD7949203EE5D@xypro.com> 
	<200205040007.16685@sendmail.mutz.com>
Message-ID: <1020464977.1668.228.camel@usb.networkfab.com>

On Fri, 2002-05-03 at 15:07, Marc Mutz wrote:

> On Friday 03 May 2002 23:26, Tracy Ding wrote:
> <snip>
> > The program stuck there waiting for more bytes: <snip>
> > Not enough random bytes available.  Please do some other work to give
> > the OS a chance to collect more entropy! (Need 300 more bytes)
> <snip>
> 
> Sorry, you _can_ read, can you? :-(
> You can: start bonnie in the background, hit the keyboard monkey-style, move 
> the mouse wildly (maybe dragging a window around), or all at once... :-o

I believe, the original cry for help was not unfounded. Here is why.

First of all, the message "Not enough random bytes available" may be
perceived by novices as an ERROR. It is phrased this way. Failed. No
luck. Come back in next millennium. Or something like that.

Secondly, the advice "Please do some other work" can be understood as
"give the computer more time, and meanwhile do something different, like
walking the dog..." If the user does that, the dog gets the entropy -
not the computer ;-)

Apparently, in this very case the user left the computer alone for some
time, and then complained that the program does not go anywhere.

This is because only computer geeks would equal "some other work" to
"some other work with this computer". Normal people have other "work" to
do. Naturally, if the computer is just left there then no new entropy
comes in, and nothing ever happens (until updatedb runs at night,
probably).

So messages may need to be softened up to be understood by all the
normal people ;-)

Dmitri

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : /pipermail/attachments/20020504/dc6a4e14/attachment.bin
From wk at gnupg.org  Sat May  4 16:31:01 2002
From: wk at gnupg.org (Werner Koch)
Date: Tue Oct  7 21:29:00 2003
Subject: Help ...
In-Reply-To: <1020464977.1668.228.camel@usb.networkfab.com> (Dmitri's
 message of "03 May 2002 15:29:37 -0700")
References: <32E0F1DAB878D511826D00A0CCD7949203EE5D@xypro.com>
	<200205040007.16685@sendmail.mutz.com>
	<1020464977.1668.228.camel@usb.networkfab.com>
Message-ID: <87n0vgdomh.fsf@alberti.gnupg.de>

On 03 May 2002 15:29:37 -0700, Dmitri  said:

> So messages may need to be softened up to be understood by all the
> normal people ;-)

I agree.  I will reword the messages.

 Werner



From jas at extundo.com  Sat May  4 18:21:02 2002
From: jas at extundo.com (Simon Josefsson)
Date: Tue Oct  7 21:29:00 2003
Subject: update to gettext 0.11.2?
Message-ID: <iluu1pohr9p.fsf@extundo.com>

What about updating to gettext 0.11.2?  I had difficulties getting the
current gettext in gnupg to work.

I put a patch to do this up at http://josefsson.org/gnupg-gettext.diff
(due to size, ~230KB), altough it seems to remove some comments in
po/*.po so maybe not all of it should be applied.



From wk at gnupg.org  Sat May  4 19:57:01 2002
From: wk at gnupg.org (Werner Koch)
Date: Tue Oct  7 21:29:00 2003
Subject: update to gettext 0.11.2?
In-Reply-To: <iluu1pohr9p.fsf@extundo.com> (Simon Josefsson's message of
 "Sat, 04 May 2002 17:22:26 +0200")
References: <iluu1pohr9p.fsf@extundo.com>
Message-ID: <871ycrdf4e.fsf@alberti.gnupg.de>

On Sat, 04 May 2002 17:22:26 +0200, Simon Josefsson said:

> What about updating to gettext 0.11.2?  I had difficulties getting the
> current gettext in gnupg to work.

As soon as it appears in Woody.

  Werner



From jgre at tzi.de  Mon May  6 12:12:02 2002
From: jgre at tzi.de (Janico Greifenberg)
Date: Tue Oct  7 21:29:00 2003
Subject: Importing and using keys with GPGME
Message-ID: <20020506062658.GA478@tzi.de>

Hello,
when I import a public key with gpgme_op_import() the key appears in my keyring
but when I want to use it for encryption (with gpgme_op_encrypt_sign()) I get
a GPGME_No_Data Error. When I use this key with gpg in the command line, I need
to confirm that I want to use this untrusted key. Is to possible to do
something like that with gpgme (I mean overriding the error) or do I have to
sign the key and how can I do this with gpgme?

Thanks in advance
       Janico
-- 
Warning! Taking anyone (especially yourself) too serious will be harmful


From hideki at allcity.net  Mon May  6 14:17:02 2002
From: hideki at allcity.net (Hideki Saito)
Date: Tue Oct  7 21:29:00 2003
Subject: 15MB files on photo
In-Reply-To: <20020503144106.GD6647@akamai.com>
References: <200205020026.g420Qli28732@server-1.visp.net>
	<20020502005106.GA25856@akamai.com>
	<200205020205.g4225Fi03599@server-1.visp.net>
	<20020503144106.GD6647@akamai.com>
Message-ID: <200205061118.g46BIYg20489@sasami.anime.net>

Yes, this worked.
Thanks.

Here are files, in case anyones are interested.
http://hp.vector.co.jp/authors/VA019487/gnupg-w32-1.0.7-hs.zip
http://hp.vector.co.jp/authors/VA019487/hs-gnupg-w32-1.0.7-hs.zip.sig


>
>On Wed, May 01, 2002 at 07:06:11PM -0700, Hideki Saito wrote:
>> Mingw32 build it is...
>
>The problem is forward slashes in the photo path.  Before you compile,
>you need to change g10defs.h:
>
>Change these:
>#define DIRSEP_C '/'
>#define DIRSEP_S "/"
>
>To these:
>#define DIRSEP_C '\\'
>#define DIRSEP_S "\\"
>
>The Win32 internals do allow either / or \, but the photo viewer uses
>system(), and that calls command, and command does not allow forward
>slashes.
>
>As for the large garbage file in i_view32, I was able to duplicate the
>problem here so I see it as well, but I don't know where the garbage
>came from.  I suspect that i_view32 gets upset if it gets forward
>slashes in a pathname.
>


-- 
Hideki Saito mailto:hideki@allcity.net


From wk at gnupg.org  Mon May  6 14:55:01 2002
From: wk at gnupg.org (Werner Koch)
Date: Tue Oct  7 21:29:00 2003
Subject: Importing and using keys with GPGME
In-Reply-To: <20020506062658.GA478@tzi.de> (jgre@tzi.de's message of "Mon, 6
 May 2002 08:26:59 +0200")
References: <20020506062658.GA478@tzi.de>
Message-ID: <87lmax1oac.fsf@alberti.gnupg.de>

On Mon, 6 May 2002 08:26:59 +0200, Janico Greifenberg said:

> when I import a public key with gpgme_op_import() the key appears in my keyring
> but when I want to use it for encryption (with gpgme_op_encrypt_sign()) I get
> a GPGME_No_Data Error. When I use this key with gpg in the command line, I need

In general it does not make sense to encrypt something to someone whom
you don't trust.  So the best way is to locally sign the sign.

Using

  gpgme_recipients_add_name_with_validity (rset, name, GPGME_VALIDITY_FULL);

you should be able to overide it.




From Weimer at CERT.Uni-Stuttgart.DE  Tue May  7 10:43:02 2002
From: Weimer at CERT.Uni-Stuttgart.DE (Florian Weimer)
Date: Tue Oct  7 21:29:00 2003
Subject: Expiration and V3/V4 self signatures
Message-ID: <87helk8ksv.fsf@CERT.Uni-Stuttgart.DE>

* packet.h, parse-packet.c (parse_key), getkey.c (merge_keys_and_selfsig,
merge_selfsigs_main): a v3 key with a v4 self-sig must never let the v4
self-sig express a key expiration time that extends beyond the original v3
expiration time.

* keyedit.c (sign_uids): If --expert it set, allow re-signing a uid to
promote a v3 self-sig to a v4 one.  This essentially deletes the old v3
self-sig and replaces it with a v4 one.

Don't these two features conflict with each other?

-- 
Florian Weimer 	                  Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898


From wk at gnupg.org  Tue May  7 11:07:01 2002
From: wk at gnupg.org (Werner Koch)
Date: Tue Oct  7 21:29:00 2003
Subject: Expiration and V3/V4 self signatures
In-Reply-To: <87helk8ksv.fsf@CERT.Uni-Stuttgart.DE> (Florian Weimer's
 message of "Tue, 07 May 2002 09:43:44 +0200")
References: <87helk8ksv.fsf@CERT.Uni-Stuttgart.DE>
Message-ID: <877kmgwfb8.fsf@alberti.gnupg.de>

On Tue, 07 May 2002 09:43:44 +0200, Florian Weimer said:

> * packet.h, parse-packet.c (parse_key), getkey.c (merge_keys_and_selfsig,
> merge_selfsigs_main): a v3 key with a v4 self-sig must never let the v4
> self-sig express a key expiration time that extends beyond the original v3
> expiration time.

> * keyedit.c (sign_uids): If --expert it set, allow re-signing a uid to
> promote a v3 self-sig to a v4 one.  This essentially deletes the old v3
> self-sig and replaces it with a v4 one.

> Don't these two features conflict with each other?

No.  Why should they?

As you know the expiration time in a v3 key is stored unchangeable
with the key whereas it is store in a self-signature with a v4 key.
The first change makes sure that the expiration time from a v4
signature on a v3 key can not be used to extend the expiration time
over the one set with the v3 key and the latter change simply promotes
a v3 self-signature to a v4 self-signature with an expiration time
(set to the one from the v3 key).

  Werner



From p_perego at modiano.com  Tue May  7 13:37:02 2002
From: p_perego at modiano.com (Paolo Perego)
Date: Tue Oct  7 21:29:01 2003
Subject: GPGME: verify signature question
Message-ID: <200205071237.54986.p_perego@modiano.com>

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

Hi ,guys. I'm not subscribed to thie ML so please cc me. I'm using gpg 1.07 
and gpgme 0.3.6 on my suse linux box. I'm developing a tool that parse a 
mailbox looking for mails and, if thie mails are signed, try to verify the 
signature ( not detached ). The messages are in rfc2015 form, so the content  
type is "multipart/signed" and the signed data is divided from the signature 
by the boundary.

I wrote the code to verify the signature but I think I did not pass the right 
body and signature content to gpgme_op_verify. Can you please gave me some 
links, examples ( not mail usent agent sources, please. ) about how verify a 
signed message vailidity.

Thanks a lot
Paolo
- -- 
$>cd /pub
$>more beer

(0>
//\  Perego Paolo <p_perego@modiano.com> - www.sikurezza.org/angel
V_/_ 'It's seems the hardest life I've never known'
I'm Linux drow 2.4.17-4GB - SuSE Linux 7.3 (i386) powered.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE8166Ae2SOXFIw7OcRAlFvAJ46Eu6wq4UrsiisYz7WE1xcGIAJYwCgmsWX
r2/3n7ue4jzOlCyISocqUQE=
=bzUP
-----END PGP SIGNATURE-----



From wk at gnupg.org  Tue May  7 14:13:01 2002
From: wk at gnupg.org (Werner Koch)
Date: Tue Oct  7 21:29:01 2003
Subject: GPGME: verify signature question
In-Reply-To: <200205071237.54986.p_perego@modiano.com> (Paolo Perego's
 message of "Tue, 7 May 2002 12:37:45 +0200")
References: <200205071237.54986.p_perego@modiano.com>
Message-ID: <87k7qgus5c.fsf@alberti.gnupg.de>

On Tue, 7 May 2002 12:37:45 +0200, Paolo Perego said:

> signature ( not detached ). The messages are in rfc2015 form, so the content  
> type is "multipart/signed" and the signed data is divided from the signature 

BTW, rfc3156 is the successor or 2015, only minor changes but you
should use this as a reference,

> body and signature content to gpgme_op_verify. Can you please gave me some 
> links, examples ( not mail usent agent sources, please. ) about how verify a 

Be sure to include the header lines of the part and don't include the
CR/LF right before the terminating boundary.

What's wrong with looking at other sources?

  Werner



From p_perego at modiano.com  Tue May  7 15:18:02 2002
From: p_perego at modiano.com (Paolo Perego)
Date: Tue Oct  7 21:29:01 2003
Subject: GPGME: verify signature question
In-Reply-To: <87k7qgus5c.fsf@alberti.gnupg.de>
References: <200205071237.54986.p_perego@modiano.com> <87k7qgus5c.fsf@alberti.gnupg.de>
Message-ID: <200205071418.58964.p_perego@modiano.com>

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

Alle 13:14, marted? 7 maggio 2002, Werner Koch ha scritto:

> BTW, rfc3156 is the successor or 2015, only minor changes but you
> should use this as a reference,
Sure. I omissed that I downloaded also the new rfc. :)

> Be sure to include the header lines of the part and don't include the
> CR/LF right before the terminating boundary.
Is the signature calculated from the first "--boundary" or also the mail 
header are hashed by gpg?

> What's wrong with looking at other sources?
Nothing at all.  I was checking out mutt and sylpheed-claws sources. But they 
parse mime headers in various point of the code and I was not able to guess 
what exactly they pass to gpgme_op_verify().

Thank again. I think this afternoon will be plenty of signature checking 
attempts :)
Paolo
- -- 
$>cd /pub
$>more beer

(0>
//\  Perego Paolo <p_perego@modiano.com> - www.sikurezza.org/angel
V_/_ 'It's seems the hardest life I've never known'
I'm Linux drow 2.4.17-4GB - SuSE Linux 7.3 (i386) powered.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE818Yxe2SOXFIw7OcRAm2fAJ96qivoJ1SUH8JxGDjUkyguwvnK3wCgh96n
4ivWYObqgTQF7ikNsJTAAUs=
=dhyt
-----END PGP SIGNATURE-----



From wk at gnupg.org  Tue May  7 15:37:02 2002
From: wk at gnupg.org (Werner Koch)
Date: Tue Oct  7 21:29:01 2003
Subject: GPGME: verify signature question
In-Reply-To: <200205071418.58964.p_perego@modiano.com> (Paolo Perego's
 message of "Tue, 7 May 2002 14:18:50 +0200")
References: <200205071237.54986.p_perego@modiano.com>
	<87k7qgus5c.fsf@alberti.gnupg.de>
	<200205071418.58964.p_perego@modiano.com>
Message-ID: <87g014uo6m.fsf@alberti.gnupg.de>

On Tue, 7 May 2002 14:18:50 +0200, Paolo Perego said:

> Is the signature calculated from the first "--boundary" or also the mail 
> header are hashed by gpg?

  Subject: a signed message
  
  -=-=-=
  Content-Type: whatever/foo

  This is the content which might be encoded in any way as
  specified by a encoding header.  For signature verification there 
  is nothing we have to care about.

  -=-=-=
  Content-Type: application/pgp-signature

What you hash is this string in C notation:

  "Content-Type: whatever/foo\r\n\r\nThis is the content which might"
  " be encoded in any way as\r\nspecified by a encoding header.  For"
  "  signature verification there\r\nis nothing we have to care about.\r\n"

And you might want to keep in mind that such a PGP/MIEM object may be
embedded in other MIME objects or the whatever/foo conetnt type might
be a multipart/mixed or whatever you can imagine.

gpg --debug 512

is of great help here because it creates files dbgmd*.<somecode> with
the actually hashed content.


  Werner



From p_perego at modiano.com  Tue May  7 15:42:01 2002
From: p_perego at modiano.com (Paolo Perego)
Date: Tue Oct  7 21:29:01 2003
Subject: GPGME: verify signature question
In-Reply-To: <87g014uo6m.fsf@alberti.gnupg.de>
References: <200205071237.54986.p_perego@modiano.com> <200205071418.58964.p_perego@modiano.com> <87g014uo6m.fsf@alberti.gnupg.de>
Message-ID: <200205071443.13524.p_perego@modiano.com>

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

Alle 14:39, marted? 7 maggio 2002, Werner Koch ha scritto:
[snip]

> What you hash is this string in C notation:
>
>   "Content-Type: whatever/foo\r\n\r\nThis is the content which might"
>   " be encoded in any way as\r\nspecified by a encoding header.  For"
>   "  signature verification there\r\nis nothing we have to care about.\r\n"
Perfect. At the same time I guess I must pass the string "-----BEGIN PGP 
SIGNATURE-----.... -----END PGP SIGNATURE-----" as signature in 
gpgme_op_verify(). Am I right am not I?

> And you might want to keep in mind that such a PGP/MIEM object may be
> embedded in other MIME objects or the whatever/foo conetnt type might
> be a multipart/mixed or whatever you can imagine.
Sure, but my application is really simple and it needs just to validate the 
sender identity! :)

Thanks for the help guys [ and excuse me for my poor english :P ]
Paolo
- -- 
$>cd /pub
$>more beer

(0>
//\  Perego Paolo <p_perego@modiano.com> - www.sikurezza.org/angel
V_/_ 'It's seems the hardest life I've never known'
I'm Linux drow 2.4.17-4GB - SuSE Linux 7.3 (i386) powered.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE818vge2SOXFIw7OcRAszgAJ9KpVTx0wzW/hFS8H3i//HQBzZJ3ACeImPY
VZM84JDhKchJecuG4yTz/eI=
=wMhM
-----END PGP SIGNATURE-----



From wk at gnupg.org  Tue May  7 15:57:01 2002
From: wk at gnupg.org (Werner Koch)
Date: Tue Oct  7 21:29:01 2003
Subject: GPGME: verify signature question
In-Reply-To: <200205071443.13524.p_perego@modiano.com> (Paolo Perego's
 message of "Tue, 7 May 2002 14:43:07 +0200")
References: <200205071237.54986.p_perego@modiano.com>
	<200205071418.58964.p_perego@modiano.com>
	<87g014uo6m.fsf@alberti.gnupg.de>
	<200205071443.13524.p_perego@modiano.com>
Message-ID: <87u1pkt8oc.fsf@alberti.gnupg.de>

On Tue, 7 May 2002 14:43:07 +0200, Paolo Perego said:

> Perfect. At the same time I guess I must pass the string "-----BEGIN PGP 
> SIGNATURE-----.... -----END PGP SIGNATURE-----" as signature in 
> gpgme_op_verify(). Am I right am not I?

Yes.  

  Werner



From redbird at rbisland.cx  Tue May  7 18:58:02 2002
From: redbird at rbisland.cx (Gordon Worley)
Date: Tue Oct  7 21:29:01 2003
Subject: GnuPG 1.0.7 configure with dynload modules
Message-ID: <4B21FE3D-61D3-11D6-B33A-000A27B4DEFC@rbisland.cx>

Okay, I'm having a bit of trouble here and hopefully someone has some 
insights.

I'm trying to patch GnuPG 1.0.7 to run on Darwin (Mac OS X).  Everything 
is working except for one thing.  I have patched cipher/dynload.c to 
work as we did in 1.0.6 and it compiles fine and looks like it will 
work.  The problem comes when make tries to make the checks.  The 
problem is that tiger has not been compiled earlier.  Yet, when 
configure was run, it said that it would:

                 Configured for: Darwin (powerpc-apple-darwin5.4)
     Dynamically linked modules: rndunix rndegd tiger
      Statically linked modules: rndlinux sha1 rmd160 md5

So, anyone have any ideas on how to get tiger (and rndunix and rndegd; I 
checked and they haven't been compiled either) to compile short of doing 
it by hand?

Thanks.

--
Gordon Worley                     `When I use a word,' Humpty Dumpty
http://www.rbisland.cx/            said, `it means just what I choose
redbird@rbisland.cx                it to mean--neither more nor less.'
PGP:  0xBBD3B003                                  --Lewis Carroll



From bgallia at orion.it.luc.edu  Wed May  8 00:34:03 2002
From: bgallia at orion.it.luc.edu (B. Galliart)
Date: Tue Oct  7 21:29:01 2003
Subject: AIX malloc(0) is null
Message-ID: <Pine.A41.4.40.0205071551390.12276-100000@orion.it.luc.edu>

How many people believe in testing if their computer is out of memory by
requesting the allocation of *0* bytes?

So, what is wrong with the following picture:
  gpg: out of  memory while allocating 0 bytes

GNUPG v1.07 *REQUIRES* the use of m-guard on AIX to ensure that GPG never
attempts malloc(0) (m-gaurd always allocates at least 5 bytes).  There is
just something brain dead about requesting *nothing* and exiting if you do
not get *something*.  Please update memory.c to skip malloc if 0 bytes are
requested or update the configure script to automatically include m-gaurd
if malloc(0) returns null.

Thanks



From dshaw at jabberwocky.com  Wed May  8 00:46:02 2002
From: dshaw at jabberwocky.com (David Shaw)
Date: Tue Oct  7 21:29:01 2003
Subject: AIX malloc(0) is null
In-Reply-To: <Pine.A41.4.40.0205071551390.12276-100000@orion.it.luc.edu>
References: <Pine.A41.4.40.0205071551390.12276-100000@orion.it.luc.edu>
Message-ID: <20020507214715.GB3487@akamai.com>

On Tue, May 07, 2002 at 04:35:11PM -0500, B. Galliart wrote:
> How many people believe in testing if their computer is out of memory by
> requesting the allocation of *0* bytes?
> 
> So, what is wrong with the following picture:
>   gpg: out of  memory while allocating 0 bytes

Fixed in 1.0.8.  See
  http://lists.gnupg.org/pipermail/gnupg-users/2002-May/013022.html
for temporary patch.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From bgallia at orion.it.luc.edu  Wed May  8 08:34:01 2002
From: bgallia at orion.it.luc.edu (B. Galliart)
Date: Tue Oct  7 21:29:01 2003
Subject: AIX malloc(0) is null
In-Reply-To: <20020507214715.GB3487@akamai.com>
Message-ID: <Pine.A41.4.40.0205080024590.12276-100000@orion.it.luc.edu>

Wow, fixed 6.5 hours before I post.  That is increditable timing.

You wouldn't have a trick up your sleeve for the problem below.  I can
recreate the issue with both gcc v2.9 and gcc v3.04 but IBM's v3.6.4 C
compiler goes through without a problem.  Is this a GNUPG or GCC issue?

mpih-div.c: In function `mpihelp_mod_1':
mpih-div.c:86: warning: implicit declaration of function `__udiv_w_sdiv'
mpih-div.c:100: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:100: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:106: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:106: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:136: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:136: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c: In function `mpihelp_divrem':
mpih-div.c:290: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:354: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c: In function `mpihelp_divmod_1':
mpih-div.c:447: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:447: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:453: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:453: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:482: Can't find a register in class `MQ_REGS' while reloading `asm'.
mpih-div.c:482: Can't find a register in class `MQ_REGS' while reloading `asm'.




From wk at gnupg.org  Wed May  8 11:31:01 2002
From: wk at gnupg.org (Werner Koch)
Date: Tue Oct  7 21:29:01 2003
Subject: AIX malloc(0) is null
In-Reply-To: <Pine.A41.4.40.0205080024590.12276-100000@orion.it.luc.edu> ("B.
 Galliart"'s message of "Wed, 8 May 2002 00:35:29 -0500 (CDT)")
References: <Pine.A41.4.40.0205080024590.12276-100000@orion.it.luc.edu>
Message-ID: <87znzbjc8h.fsf@alberti.gnupg.de>

On Wed, 8 May 2002 00:35:29 -0500 (CDT), B Galliart said:

> mpih-div.c:86: warning: implicit declaration of function `__udiv_w_sdiv'
> mpih-div.c:100: Can't find a register in class `MQ_REGS' while reloading `asm'.

This is more a problem of using GCC with the native as(1)  I have
no instant solution for this.  Compiling GMP should yield the same
problems.

   Werner



From order at elite-code-runner.com  Wed May  8 21:14:02 2002
From: order at elite-code-runner.com (Bolder Computer Solutions)
Date: Tue Oct  7 21:29:01 2003
Subject: Cover Your Tracks
Message-ID: 47494851946830.70799.qmail@elite-code-runner.com

                                             Cover your Tracks

We at Bolder Computer Solutions have been looking for a software developer that has the state of the art software programs, at the right price, which can protect all of us on the Internet. We found Elite Code Runner!!! Elite Code Runner has products designed at blocking Hackers from your computer, software designed to delete all traces of your surfing and also your document and history files, and software to let you know where your children, your employees, your friends, and anyone that uses your computer, have gone when they are using your computer. 

                                                 Trace Breaker

Trace Breaker is a software program that is designed to erase all traces of your travels around the Internet. We have also added the ability to this software programs to clear all your history files from the internet, clear your cookies, delete the typed URL's, Windows Recent files, Office Recent files, and your Document files. These are all user selectable allowing you to keep the files you choose.

Trace Breaker $ 49.95

Name :______________________________________________________________
Address :____________________________________________________________
City State Zip______________________________________  _____   ___________
Amount Enclosed :_$______________

                      We except company checks or Money orders.
***** Add $6.95 shipping and Handling for each package you order. *****
***** Make all checks payable to Bolder Computer Solutions.            *****
Mail to:

Bolder Computer Solutions
27 Shethar Street
P.O. Box 25
Hammondsport, NY 14840-0025

Shipping as soon as checks clear. Immediately with Money orders.

***** Print this ad, circle selections and mail with payment                 *****




From andreas at xss.co.at  Thu May  9 14:34:02 2002
From: andreas at xss.co.at (Andreas Haumer)
Date: Tue Oct  7 21:29:01 2003
Subject: gnupg-1.0.7: missing dependencies in checks/Makefile
Message-ID: <3CDA5EDF.990C18F8@xss.co.at>

Hi!

I found a small problem in the checks/Makefile for gnupg-1.0.7

Some of the checks there need a script "gpg_dearmor", which
itself is created by make on the fly. But this dependency
is not explicitly listed in the Makefile, so a "make -j2"
(or any build with more than one job running simultaneously) 
fails on our Dual CPU development server.

I'd suggest to add "gpg_dearmor" to the dependency section of
all make targets where this script is used (just like it 
already is for target "./pubring.gpg")

Regards,

- andreas

-- 
Andreas Haumer                     | mailto:andreas@xss.co.at
*x Software + Systeme              | http://www.xss.co.at/
Karmarschgasse 51/2/20             | Tel: +43-1-6060114-0
A-1100 Vienna, Austria             | Fax: +43-1-6060114-71


From mwy-gpg41 at the-youngs.org  Thu May  9 21:52:01 2002
From: mwy-gpg41 at the-youngs.org (Michael Young)
Date: Tue Oct  7 21:29:01 2003
Subject: Notation data format: "user" name space rejected
References: <E175fVC-0001KU-00@trithemius.gnupg.org>
Message-ID: <007201c1f78a$9a6d81e0$ebc42609@transarc.ibm.com>

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

The latest draft of RFC2440 describes two name spaces for notation
data, one of which GnuPG rejects as invalid.  Specifically, the
RFC describes the "user" name space:

>    Names in the user name space consist of a UTF-8 string tag followed
>    by "@" followed by a DNS domain name. Note that the tag MUST NOT
>    contain an "@" character. For example, the "sample" tag used by
>    Example Corporation could be "sample@example.com".

When I try to generate such a notation, I get this error:
    log_error(_("a notation name must have only letters, "
  "digits, dots or underscores and end with an '='\n") );

(My test used 1.0.6, but it doesn't appear to have changed in the
latest source.)

At first glance, it would appear that adding the "@" character
to the check on the line before the log_error() would be sufficient.
But neither the "tag" nor the DNS domain name should need to meet
these tight restrictions (alphanumeric/dot/underscore).  So, I
would suggest looking for a "@" first, at which point almost
anything goes.  Does that seem reasonable?

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQA/AwUBPNrFJFMkvpTT8vCGEQKhpgCg2dVswZWsaKwSZGkvQh7Cg3UYDjoAoMCz
tgIKnXkM0nKFPmSe2YWZRWXQ
=U8xW
-----END PGP SIGNATURE-----




From ImproveEducation at address.com  Thu May  9 22:02:01 2002
From: ImproveEducation at address.com (Dr. Carter)
Date: Tue Oct  7 21:29:02 2003
Subject: To: g10 as a Good Person - Conduct Education in the 21st Century
Message-ID: <4140-2200254919350630@oemcomputer>

Dear g10:

You may ask yourself
      >    How to make people respect you
      >    How to win friends
      >    How to let your conduct help your health, work, job, career, relationships, spirit,  mind, well-being, ...
      >    How to make your life smoother and happier 
      >    How to do whatever you like without being unpleasant to other people 
      >    How to develop good conduct in your children or students 
      >    How to make the world peaceful and better

You can find all the answers to these questions, and much more, in this great handbook:
 
"Complete Conduct Principles for the 21st Century" by Dr. John Newton 

It is the best educational GIFT idea for children, friends, relatives, classmates, students, parents, teachers, other educators, ..., particularly at this special time. 

BENEFITS to each individual reader: Many! -- such as for health, work, job, career, self-improvement, education, relationships, spirit, mind, well-being, and much more -- almost all the areas that are important to you in the 21st century. People around you will benefit, too. (Please see the PREFACE of the book for details.) 

EVERYONE may find this handbook useful and helpful, regardless of age (from children to oldsters), occupation, rank, status, gender, religious beliefs, nationality, country, or region. 

If you are a parent or a teacher, you can learn how to develop good conduct in your children or students from this handbook. Please advise your children or students to read the book. It will result in great benefits for both you and them. 

(Note: If you are interested in the issue of School Violence, Youth Problems, Violence Prevention, or Conduct Education in the 21st Century, please see the APPENDIX below.)  

This book is a must for EVERYONE to be better prepared for personal conduct for the 21st century. 

The book's content is obvious from its title. The complete useful conduct principles cover not only what we should do, but also what we should not do -- especially those faults people make often and easily. 

This timely, unique, and very important handbook is designed to suit most people, and is self-contained and user-friendly. 

This book is significantly different and better than competitive works.

Some of its innovative contents may help solve problems that Western culture cannot. 

The book's merit and importance have been recognized and praised by many experts, elected public officials, and world leaders.

How to make the world peaceful and better ---
You can find the solution in the book.
Let's work together to make the world peaceful and better! 

The author, John Newton, holds a Ph.D. from MIT, and does researches at Harvard. His long-term research on "The personal conduct in the human society of the 21st century" resulted in this book. It is published by Nicer Century World Organization, headquartered beside Harvard University and MIT, two leading institutes of new knowledge and literature.

The book is available in two types of binding: Hardcover (ISBN 0967370574; case bound, Smyth sewn; with dust jacket) and Paperback (ISBN 0967370582; perfect bound). Both editions are unabridged, and are printed on 60 lb, natural, acid-free, excellent and healthful paper. You can get the book from many fine on-line bookstores and traditional bookstores. For your convenience, I herewith provide you with a link directly to the book page in the shopping directory of Yahoo!, the world's No. 1 Internet directory:

http://shopping.yahoo.com/shop?d=b&id=3680641&clink=dmpr-hm/rp&cf=setup

Some bookstores there offer great discounts (for a limited time). Note that some of the bookstores may disappear there if out-of-stock. In that case, you may want to go to another bookstore. Of course, you may freely go to other bookstores at any time, even if they are not listed in Yahoo!.

Please forward this e-mail to people you know -- children, friends, relatives, classmates, students, parents, teachers, other educators, ..., because they can benefit from it, too. This can be a wonderful kindness you provide to them!

g10, best wishes to you!


Sincerely yours,

Tom Carter, Ph.D.
President, Nicer Century World Organization
Massachusetts, USA

(Nicer Century World Organization is an educational, non-profit, non-partisan organization; it endeavors to make the 21st century nicer than ever before. To accomplish its mission, Nicer Century World Organization is proud to introduce this book.) 

-----------------------------------------------------------

APPENDIX: School Violence, Youth Problems, Violence Prevention, and Conduct Education in the 21st Century

In recent years school violence has made many pieces of nation-shaking highlighted headline news, which have astounded the Americans. It may happen at any school, at any time, and by students of any age. Some experts believe this is the most important national crisis the U.S. is facing. 

"In the 21st century the problem will happen not only continuously in the U.S. but also in lots of other countries all over the world, if we do not act." said Dr. John Newton in the late 20th century. Recent tragedies have proved this warning prediction.

"The most effective and proper way to solve the problem is appropriate conduct education." said Dr. Newton.

"The significance of the problem" is much more important than "the number of people killed in schools". 

In addition to shooting and killing, other kinds of school violence, such as rape, sexual assault, aggravated assault, robbery, bullying, mugging, fighting, theft, harassment, ..., and other youth problems, like suicide, suicide attempt, suicide inclination, pessimism, sense of inferiority, lose of  self-control, relationship problems, emotion problems, drug abuse, discrimination, ..., cannot be ignored, either.

Some measures may handle a few "symptoms" temporarily and partially but are not solutions for education, particularly in view of our responsibilities for the whole society.

Now an effective, proper, comprehensive, deep-rooted and permanent solution is needed!

The book, "Complete Conduct Principles for the 21st Century" by Dr. John Newton, is regarded as "the very one that can effectively help solve the problem of school violence in a right way" by some experts in education, including Dr. Steve White, who pointed out clearly: "If students, teachers and parents can learn the conduct principles in this book well, then that 'unsolvable' problem will be solved.  It is not difficult at all to learn them, because the book is a simple, easy, clear, convenient and self-contained handbook, well designed to suit most people." The book was also praised as "a compendium of concisely expressed, practical, informative, pertinent, workable advice" by Michael J. Carson, a professional book reviewer.

"Unlike most books of this subject, it is NOT a religious book, nor is a collection of old conduct rules." 

As analyzed in the Preface of the book, "from now on learning good conduct should be placed as No. 1 in education." 

The book's merit and importance have been recognized and praised by many education experts, elected public officials, and world leaders. Some educational units, ranging from the level of nation or state to individual school or university, have ordered the book either as textbook/reference book or as an active action to prevent school violence, to improve education and to benefit students, teachers & parents. 

"The book will also be effective for violence prevention for the whole society."

Hence, to prevent school violence and other violence, to improve education, and to benefit students, teachers, parents, & the whole society, I earnestly request you to inform the students, teachers, parents, school library and other relevant people you know of the availability of the book.

A reasonable method you may consider choosing is to simply  forward this letter to them.

Although it will be helpful and appreciated, it is NOT necessary that you state any endorsement or the like.

Your efforts to prevent school violence and other violence, to improve education, and to benefit students, teachers, parents, & the whole society will be highly appreciated.




From dshaw at jabberwocky.com  Thu May  9 22:16:01 2002
From: dshaw at jabberwocky.com (David Shaw)
Date: Tue Oct  7 21:29:02 2003
Subject: Notation data format: "user" name space rejected
In-Reply-To: <007201c1f78a$9a6d81e0$ebc42609@transarc.ibm.com>
References: <E175fVC-0001KU-00@trithemius.gnupg.org> <007201c1f78a$9a6d81e0$ebc42609@transarc.ibm.com>
Message-ID: <20020509191712.GC3323@akamai.com>

On Thu, May 09, 2002 at 02:52:00PM -0400, Michael Young wrote:

> The latest draft of RFC2440 describes two name spaces for notation
> data, one of which GnuPG rejects as invalid.  Specifically, the
> RFC describes the "user" name space:
> 
> >    Names in the user name space consist of a UTF-8 string tag followed
> >    by "@" followed by a DNS domain name. Note that the tag MUST NOT
> >    contain an "@" character. For example, the "sample" tag used by
> >    Example Corporation could be "sample@example.com".
> 
> When I try to generate such a notation, I get this error:
>     log_error(_("a notation name must have only letters, "
>   "digits, dots or underscores and end with an '='\n") );
> 
> (My test used 1.0.6, but it doesn't appear to have changed in the
> latest source.)

It hasn't.  The problem here is that between 2440 and one of the
succeeding 2440bis drafts the spec here changed slightly, so there is
a bit of a 'moving target' effect.  I'll look into it.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From karlsson at hal-pc.org  Thu May  9 22:39:02 2002
From: karlsson at hal-pc.org (Brian M. Carlson)
Date: Tue Oct  7 21:29:02 2003
Subject: force-v4-certs and digest-algo
Message-ID: <20020509194024.GB6949@stonewall>

I have set force-v4-certs in my options file. I also have digest-algo RIPEMD160
set. Yet, my signatures still are made with SHA1, which I deprecate strongly.
If I have a preference on my key, I'd prefer that gpg choose that, unless
I choose a digest-algo option, in which case gpg uses that. gpg has done
neither.

Is that possible without a rewrite of the code?

-- 
Brian M. Carlson
<karlsson@hal-pc.org>
OpenPGP: 0x351336B2DCA1913A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 528 bytes
Desc: not available
Url : /pipermail/attachments/20020509/4552b60e/attachment.bin
From dshaw at jabberwocky.com  Thu May  9 22:50:01 2002
From: dshaw at jabberwocky.com (David Shaw)
Date: Tue Oct  7 21:29:02 2003
Subject: force-v4-certs and digest-algo
In-Reply-To: <20020509194024.GB6949@stonewall>
References: <20020509194024.GB6949@stonewall>
Message-ID: <20020509195108.GE3323@akamai.com>

On Thu, May 09, 2002 at 07:40:24PM +0000, Brian M. Carlson wrote:

> I have set force-v4-certs in my options file. I also have
> digest-algo RIPEMD160 set. Yet, my signatures still are made with
> SHA1, which I deprecate strongly.  If I have a preference on my key,
> I'd prefer that gpg choose that, unless I choose a digest-algo
> option, in which case gpg uses that. gpg has done neither.

Let me make sure I understand what you are doing.  You want your key
signatures - not data signatures - to use RIPEMD160 and not SHA1?

--digest-algo only applies to data signatures.

Why do you strongly deprecate SHA1?

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From mutz at kde.org  Thu May  9 23:36:05 2002
From: mutz at kde.org (Marc Mutz)
Date: Tue Oct  7 21:29:02 2003
Subject: force-v4-certs and digest-algo
In-Reply-To: <20020509194024.GB6949@stonewall>
References: <20020509194024.GB6949@stonewall>
Message-ID: <200205092236.31196@sendmail.mutz.com>

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

On Thursday 09 May 2002 21:40, Brian M. Carlson wrote:
> I have set force-v4-certs in my options file. I also have digest-algo
> RIPEMD160 set. Yet, my signatures still are made with SHA1,
<snip>

Well, according to the micalg parameter of your mp/signed, your last message 
_was_ RIMEMD160.

Marc

- -- 
Marc Mutz <mutz@kde.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE82t3N3oWD+L2/6DgRAlcvAJoDRQr+9AIq9J1k4jioo1LiPufPIgCgtFag
/LWfdENWjoE8xSHeFk67tNU=
=xDxC
-----END PGP SIGNATURE-----



From karlsson at hal-pc.org  Thu May  9 23:54:02 2002
From: karlsson at hal-pc.org (Brian M. Carlson)
Date: Tue Oct  7 21:29:02 2003
Subject: force-v4-certs and digest-algo
In-Reply-To: <20020509195108.GE3323@akamai.com>
References: <20020509194024.GB6949@stonewall> <20020509195108.GE3323@akamai.com>
Message-ID: <20020509205512.GC6949@stonewall>

On Thu, May 09, 2002 at 03:51:08PM -0400, David Shaw wrote:
> On Thu, May 09, 2002 at 07:40:24PM +0000, Brian M. Carlson wrote:
> 
> > I have set force-v4-certs in my options file. I also have
> > digest-algo RIPEMD160 set. Yet, my signatures still are made with
> > SHA1, which I deprecate strongly.  If I have a preference on my key,
> > I'd prefer that gpg choose that, unless I choose a digest-algo
> > option, in which case gpg uses that. gpg has done neither.
> 
> Let me make sure I understand what you are doing.  You want your key
> signatures - not data signatures - to use RIPEMD160 and not SHA1?
> 
> --digest-algo only applies to data signatures.
> 
> Why do you strongly deprecate SHA1?

SHA1 was created by the US government. I feel that the US government does not
have its citizens best interest at heart in the realm of cryptography, and
sometimes not with privacy in general. I prefer RIPEMD160 as it was created
independently outside of the US. Anyway, whatever my reason, shouldn't it
be my choice?

digest-algo has worked before, with my RSA key and with my ElGamal 20 key (see
sig) on key signatures. I might be able to dig them up for you.

-- 
Brian M. Carlson
<karlsson@hal-pc.org>
OpenPGP: 0x351336B2DCA1913A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 528 bytes
Desc: not available
Url : /pipermail/attachments/20020509/2d36b4c7/attachment.bin
From karlsson at hal-pc.org  Thu May  9 23:58:01 2002
From: karlsson at hal-pc.org (Brian M. Carlson)
Date: Tue Oct  7 21:29:02 2003
Subject: force-v4-certs and digest-algo
In-Reply-To: <20020509195108.GE3323@akamai.com>
References: <20020509194024.GB6949@stonewall> <20020509195108.GE3323@akamai.com>
Message-ID: <20020509205912.GD6949@stonewall>

On Thu, May 09, 2002 at 03:51:08PM -0400, David Shaw wrote:
> On Thu, May 09, 2002 at 07:40:24PM +0000, Brian M. Carlson wrote:
> 
> > I have set force-v4-certs in my options file. I also have
> > digest-algo RIPEMD160 set. Yet, my signatures still are made with
> > SHA1, which I deprecate strongly.  If I have a preference on my key,
> > I'd prefer that gpg choose that, unless I choose a digest-algo
> > option, in which case gpg uses that. gpg has done neither.
> 
> Let me make sure I understand what you are doing.  You want your key
> signatures - not data signatures - to use RIPEMD160 and not SHA1?

Yes. I want all my uses of the hash function for signatures to be with
RIPEMD160. I also use s2k-digest-algo RIPEMD160, but that is unrelated. 

-- 
Brian M. Carlson
<karlsson@hal-pc.org>
OpenPGP: 0x351336B2DCA1913A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 528 bytes
Desc: not available
Url : /pipermail/attachments/20020509/20fa52fd/attachment.bin
From rjhansen at inav.net  Fri May 10 00:21:01 2002
From: rjhansen at inav.net (Robert J. Hansen)
Date: Tue Oct  7 21:29:02 2003
Subject: force-v4-certs and digest-algo
In-Reply-To: <20020509205512.GC6949@stonewall>
References: <20020509194024.GB6949@stonewall>
	<20020509195108.GE3323@akamai.com>  <20020509205512.GC6949@stonewall>
Message-ID: <1020979199.32490.9.camel@numbers>

> SHA1 was created by the US government. I feel that the US government does not
> have its citizens best interest at heart in the realm of cryptography, and

SHA-1 isn't used for message security; it's used for message
authentication.  The NSA's mandate includes keeping US Gov't traffic
secure, and as such, deliberately creating a faulty hash
algorithm--especially one that's heavily used throughout the USG--would
be counter to the NSA's mandate.

Then there's also the intense peer review, and the fact that it's SHA-1,
not SHA-0... SHA-0 had a nasty, but very subtle, bug.  Who found the
bug, publicized it, and issued a fix?  The NSA.

While I agree there's a lot of room for skepticism on the NSA's motives,
it appears to me that throwing out SHA-1 is tossing the baby out with
the bathwater.  Still--if it floats your boat, use RIPEMD160.

> independently outside of the US. Anyway, whatever my reason, shouldn't it
> be my choice?

Not necessarily.  The axiom which guides GnuPG is "be liberal in what
you accept, but conservative in what you generate".  If I recall,
RIPEMD-160 is a SHOULD, not a MUST.  It would be entirely consistent and
RFC-conformant for GnuPG to accept RIPEMD-160 in traffic, but to only
use SHA-1 for output.

I'm not suggesting we do that, by the by.  I'm just pointing out that
"shouldn't it be my choice?" isn't always something you answer with a
"yes".  There's a time and a place for strict enforcement of policy.




From dshaw at jabberwocky.com  Fri May 10 00:31:01 2002
From: dshaw at jabberwocky.com (David Shaw)
Date: Tue Oct  7 21:29:02 2003
Subject: force-v4-certs and digest-algo
In-Reply-To: <20020509205512.GC6949@stonewall>
References: <20020509194024.GB6949@stonewall> <20020509195108.GE3323@akamai.com> <20020509205512.GC6949@stonewall>
Message-ID: <20020509213137.GB6484@akamai.com>

On Thu, May 09, 2002 at 08:55:13PM +0000, Brian M. Carlson wrote:
> On Thu, May 09, 2002 at 03:51:08PM -0400, David Shaw wrote:
> > On Thu, May 09, 2002 at 07:40:24PM +0000, Brian M. Carlson wrote:
> > 
> > > I have set force-v4-certs in my options file. I also have
> > > digest-algo RIPEMD160 set. Yet, my signatures still are made with
> > > SHA1, which I deprecate strongly.  If I have a preference on my key,
> > > I'd prefer that gpg choose that, unless I choose a digest-algo
> > > option, in which case gpg uses that. gpg has done neither.
> > 
> > Let me make sure I understand what you are doing.  You want your key
> > signatures - not data signatures - to use RIPEMD160 and not SHA1?
> > 
> > --digest-algo only applies to data signatures.
> > 
> > Why do you strongly deprecate SHA1?
> 
> SHA1 was created by the US government. I feel that the US government does not
> have its citizens best interest at heart in the realm of cryptography, and
> sometimes not with privacy in general. I prefer RIPEMD160 as it was created
> independently outside of the US. Anyway, whatever my reason, shouldn't it
> be my choice?

Sure, I'm just curious.

There is one "danger" of making RIPEMD160 key signatures, in that it
is not a required algorithm in OpenPGP.  There can be implementations
that do not support it, and so key signatures using it are not
universally usable.  This means that two different implementations may
have two different views of the web of trust, which is not a great
thing.

That said, they're your signatures, and you need to make them in a way
that you are comfortable with.  The two "bigs", PGP and GnuPG both
support RIPEMD160.

> digest-algo has worked before, with my RSA key and with my ElGamal
> 20 key (see sig) on key signatures. I might be able to dig them up
> for you.

ElGamal key signatures use RIPEMD160 by default.  What version of
GnuPG did you do the RSA one with?  It certainly couldn't have been
1.0.6 or 1.0.7.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From rabbi at quickie.net  Fri May 10 00:44:01 2002
From: rabbi at quickie.net (Len Sassaman)
Date: Tue Oct  7 21:29:02 2003
Subject: force-v4-certs and digest-algo
In-Reply-To: <1020979199.32490.9.camel@numbers>
Message-ID: <Pine.LNX.4.30.QNWS.0205091430390.10536-100000@thetis.deor.org>

On 9 May 2002, Robert J. Hansen wrote:

> Not necessarily.  The axiom which guides GnuPG is "be liberal in what
> you accept, but conservative in what you generate".  If I recall,
> RIPEMD-160 is a SHOULD, not a MUST.  It would be entirely consistent and
> RFC-conformant for GnuPG to accept RIPEMD-160 in traffic, but to only
> use SHA-1 for output.

First of all: RIPEMD-160 is neither a MUST or a SHOULD. (It's neither a
required, not suggested, algorithm in OpenPGP. Don't be surprised if
implementations do not support or understand RIPEMD-160 signatures).

Secondly, DSS is defined as requiring SHA-1. Consequently, SHA-1 has
received more attention than other 160-bit hash algorithms by
cryptographers. RIPEMD-160 is considered by many to be just as strong, but
it certainly hasn't received the same level of scrutiny.

Notice, also, that the security of PGP signatures is somewhat dependant
upon all of the hashes that the implementation allows. I draw your
attention to section 13 of RCF 2440bis05:

     * There is a somewhat-related potential security problem in
       signatures. If an attacker can find a message that hashes to the
       same hash with a different algorithm, a bogus signature
       structure can be constructed that evaluates correctly.

       For example, suppose Alice DSA signs message M using hash
       algorithm H. Suppose that Mallet finds a message M' that has the
       same hash value as M with H'. Mallet can then construct a
       signature block that verifies as Alice's signature of M' with
       H'. However, this would also constitute a weakness in either H
       or H' or both. Should this ever occur, a revision will have to
       be made to this document to revise the allowed hash algorithms.


So, if any of the hash algorithms are broken, we could be in quite a bit
of trouble. (This is my argument against adding in SHA-256, etc., until
there is a clear benefit (such as larger DSA keys) to doing so.)


Len



From karlsson at hal-pc.org  Fri May 10 01:25:02 2002
From: karlsson at hal-pc.org (Brian M. Carlson)
Date: Tue Oct  7 21:29:02 2003
Subject: force-v4-certs and digest-algo
In-Reply-To: <Pine.LNX.4.30.QNWS.0205091430390.10536-100000@thetis.deor.org>
References: <1020979199.32490.9.camel@numbers> <Pine.LNX.4.30.QNWS.0205091430390.10536-100000@thetis.deor.org>
Message-ID: <20020509222550.GE6949@stonewall>

On Thu, May 09, 2002 at 02:44:43PM -0700, Len Sassaman wrote:
> On 9 May 2002, Robert J. Hansen wrote:
> 
> > Not necessarily.  The axiom which guides GnuPG is "be liberal in what
> > you accept, but conservative in what you generate".  If I recall,
> > RIPEMD-160 is a SHOULD, not a MUST.  It would be entirely consistent and
> > RFC-conformant for GnuPG to accept RIPEMD-160 in traffic, but to only
> > use SHA-1 for output.
> 
> First of all: RIPEMD-160 is neither a MUST or a SHOULD. (It's neither a
> required, not suggested, algorithm in OpenPGP. Don't be surprised if
> implementations do not support or understand RIPEMD-160 signatures).

While this may be true, it is a de facto SHOULD, just like IDEA is.
 
> Secondly, DSS is defined as requiring SHA-1. Consequently, SHA-1 has
> received more attention than other 160-bit hash algorithms by
> cryptographers. RIPEMD-160 is considered by many to be just as strong, but
> it certainly hasn't received the same level of scrutiny.

The last time I used my DSA key, other than to update its expiration date,
was over a year ago. I use my RSA key almost exclusively. When I don't, I
use my ElGamal type 20 key. (I know how you feel about ElGamal 20 keys ;-)
There is no reason that DSA couldn't use any other 160 bit hash. Nevertheless,
I *do* use SHA1 with DSA.

> Notice, also, that the security of PGP signatures is somewhat dependant
> upon all of the hashes that the implementation allows. I draw your
> attention to section 13 of RCF 2440bis05:
<snip>

I am quite aware of the requirements for a collision-resistant hash function.
I own Applied Cryptography and have read it several times. I have also read
other works on the subject, including the definition of RIPEMD160.

-- 
Brian M. Carlson
<karlsson@hal-pc.org>
OpenPGP: 0x351336B2DCA1913A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 528 bytes
Desc: not available
Url : /pipermail/attachments/20020510/b59c31f9/attachment.bin
From rabbi at quickie.net  Fri May 10 01:29:02 2002
From: rabbi at quickie.net (Len Sassaman)
Date: Tue Oct  7 21:29:02 2003
Subject: force-v4-certs and digest-algo
In-Reply-To: <20020509222550.GE6949@stonewall>
Message-ID: <Pine.LNX.4.30.QNWS.0205091526130.14462-100000@thetis.deor.org>

On Thu, 9 May 2002, Brian M. Carlson wrote:

> > First of all: RIPEMD-160 is neither a MUST or a SHOULD. (It's neither a
> > required, not suggested, algorithm in OpenPGP. Don't be surprised if
> > implementations do not support or understand RIPEMD-160 signatures).
>
> While this may be true, it is a de facto SHOULD, just like IDEA is.

Untrue. If it isn't listed as SHOULD in the document, it isn't a SHOULD.
There are no "de facto SHOULDs."

IDEA is a SHOULD in RFC 2440. Its status has since changed, I believe.





From rjhansen at inav.net  Fri May 10 05:47:01 2002
From: rjhansen at inav.net (Robert J. Hansen)
Date: Tue Oct  7 21:29:03 2003
Subject: force-v4-certs and digest-algo
In-Reply-To: <20020509222550.GE6949@stonewall>
References: <1020979199.32490.9.camel@numbers>
	<Pine.LNX.4.30.QNWS.0205091430390.10536-100000@thetis.deor.org> 
	<20020509222550.GE6949@stonewall>
Message-ID: <1020998781.524.11.camel@numbers>

> While this may be true, it is a de facto SHOULD, just like IDEA is.

Be careful. Going further down this road will lead us to the World of
Microsoft.  There's a razor's edge between saying "we will support the
spec, including all SHOULDs" and saying "we will support the spec, plus
whatever additional things we feel are de-facto standards".  The one way
is the Free Software/Open Source way.  The other way is the Microsoft
Embrace and Extend way (q.v., their Kerberos implementation).

Unless the spec lists it as a MUST or a SHOULD, I honestly don't think
GnuPG should generate it.  Be liberal in what you accept, but very
conservative in what you generate.  (I know that Len says RIPEMD-160
isn't a SHOULD, and I have no reason to doubt him.  However, I haven't
checked RFC2440/2015/3156 myself yet, so I'll hedge it with an
`unless'.)

> There is no reason that DSA couldn't use any other 160 bit hash. Nevertheless,

Sure there is.  If DSA used any other 160-bit hash, it wouldn't be DSA
anymore because the DSA spec demands SHA.  Insofar as whether or not the
DSA spec could be changed to accept RIPEMD-160, and whether or not the
resulting system would still be secure... who knows?  Cryptosystems are
fragile things; known-strong algorithms can interact with each other to
produce weak systems.





From dshaw at jabberwocky.com  Fri May 10 07:23:01 2002
From: dshaw at jabberwocky.com (David Shaw)
Date: Tue Oct  7 21:29:03 2003
Subject: force-v4-certs and digest-algo
In-Reply-To: <1020998781.524.11.camel@numbers>
References: <1020979199.32490.9.camel@numbers> <Pine.LNX.4.30.QNWS.0205091430390.10536-100000@thetis.deor.org> <20020509222550.GE6949@stonewall> <1020998781.524.11.camel@numbers>
Message-ID: <20020510042351.GB662@akamai.com>

On Thu, May 09, 2002 at 09:46:18PM -0500, Robert J. Hansen wrote:

> Unless the spec lists it as a MUST or a SHOULD, I honestly don't think
> GnuPG should generate it.  Be liberal in what you accept, but very
> conservative in what you generate.  (I know that Len says RIPEMD-160
> isn't a SHOULD, and I have no reason to doubt him.  However, I haven't
> checked RFC2440/2015/3156 myself yet, so I'll hedge it with an
> `unless'.)

He's right.  SHA1 is the only MUST hash, and MD5 is the only SHOULD.

Still, the spec is not the beginning and the end of GnuPG.  GnuPG
certainly does things that are contrary to the spec (and documents
them carefully and gives the user the ability to turn them off).  For
example, when generating a clear signature, by default a line
beginning with "From " is escaped, probably in violation of a strict
reading of RFC2440.  The reason it does this is that clearsigned
documents are often emailed and otherwise the mail system would
probably break the signature when it changed "From " to ">From ".  PGP
does the same thing.

Another good example is the v3 sigs problem.  Most versions of PGP
don't handle v4 sigs on data, but the RFC says they are a SHOULD.  If
GnuPG blindly followed the SHOULD it would make itself incompatible
with PGP.

The --openpgp flag in GnuPG turns all of this off and makes it use a
rigid following of RFC2440.  If you use that flag though, you'll have
problems communicating with the rest of the world.

> > There is no reason that DSA couldn't use any other 160 bit hash. Nevertheless,
> 
> Sure there is.  If DSA used any other 160-bit hash, it wouldn't be DSA
> anymore because the DSA spec demands SHA.  Insofar as whether or not the
> DSA spec could be changed to accept RIPEMD-160, and whether or not the
> resulting system would still be secure... who knows?

Not quite correct.  The DSA algorithm can use any 160-bit hash.  The
DSS spec is DSA+SHA1 (plus some other details that don't matter here).
OpenPGP does not specify DSS signatures - it specifies DSA and can
thus use any 160-bit hash.

I agree with Len in general on being very careful with adding new
algorithms to OpenPGP, and in turn to GnuPG.  However, in the specific
case of RIPEMD-160, it's already part of the standard and both PGP and
GnuPG already support it.  There is no question on whether to add it -
it's already added.  There is also no evidence that it is not just as
secure as SHA1 is.

I don't see any particular reason for someone to not use RIPEMD-160
for data signatures - if there is a compatibility problem they're only
hurting themselves.  I do wish people would not use it for key
signatures, as a compatibility problem there affects the web of trust.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From Andreas.Lippek at DePfa.com  Fri May 10 08:59:02 2002
From: Andreas.Lippek at DePfa.com (Lippek, Andreas, IT-TR)
Date: Tue Oct  7 21:29:03 2003
Subject: unsubscribe
Message-ID: <A04A1C51B715E44C81D53F49C8DD08A70AD9D9@fraexx01.DEPFA-BANK.COM>


-----Original Message-----
From: Robert J. Hansen [mailto:rjhansen@inav.net]
Sent: Freitag, 10. Mai 2002 04:46
To: Brian M. Carlson
Cc: gnupg-devel@gnupg.org; rabbi@quickie.net
Subject: Re: force-v4-certs and digest-algo


> While this may be true, it is a de facto SHOULD, just like IDEA is.

Be careful. Going further down this road will lead us to the World of
Microsoft.  There's a razor's edge between saying "we will support the
spec, including all SHOULDs" and saying "we will support the spec, plus
whatever additional things we feel are de-facto standards".  The one way
is the Free Software/Open Source way.  The other way is the Microsoft
Embrace and Extend way (q.v., their Kerberos implementation).

Unless the spec lists it as a MUST or a SHOULD, I honestly don't think
GnuPG should generate it.  Be liberal in what you accept, but very
conservative in what you generate.  (I know that Len says RIPEMD-160
isn't a SHOULD, and I have no reason to doubt him.  However, I haven't
checked RFC2440/2015/3156 myself yet, so I'll hedge it with an
`unless'.)

> There is no reason that DSA couldn't use any other 160 bit hash.
Nevertheless,

Sure there is.  If DSA used any other 160-bit hash, it wouldn't be DSA
anymore because the DSA spec demands SHA.  Insofar as whether or not the
DSA spec could be changed to accept RIPEMD-160, and whether or not the
resulting system would still be secure... who knows?  Cryptosystems are
fragile things; known-strong algorithms can interact with each other to
produce weak systems.




_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel


From rabbi at quickie.net  Fri May 10 20:11:02 2002
From: rabbi at quickie.net (Len Sassaman)
Date: Tue Oct  7 21:29:03 2003
Subject: force-v4-certs and digest-algo
In-Reply-To: <1020998781.524.11.camel@numbers>
Message-ID: <Pine.LNX.4.30.QNWS.0205101003070.3958-100000@thetis.deor.org>

On 9 May 2002, Robert J. Hansen wrote:

> > While this may be true, it is a de facto SHOULD, just like IDEA is.
>
> Be careful. Going further down this road will lead us to the World of
> Microsoft.  There's a razor's edge between saying "we will support the
> spec, including all SHOULDs" and saying "we will support the spec, plus
> whatever additional things we feel are de-facto standards".  The one way
> is the Free Software/Open Source way.  The other way is the Microsoft
> Embrace and Extend way (q.v., their Kerberos implementation).

To further clarify what I was saying:

The entire point of the IETF, and of the RFC system, is to eliminate the
"de facto standards" mess, and give us actual standards.

> Unless the spec lists it as a MUST or a SHOULD, I honestly don't think
> GnuPG should generate it.  Be liberal in what you accept, but very
> conservative in what you generate.  (I know that Len says RIPEMD-160
> isn't a SHOULD, and I have no reason to doubt him.  However, I haven't
> checked RFC2440/2015/3156 myself yet, so I'll hedge it with an
> `unless'.)

Well, 2015/3156 don't cover this, so that's easy. But if you want to see
for yourself, it's section 9.4 of RFC2440bis5:

http://search.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-05.txt

> > There is no reason that DSA couldn't use any other 160 bit hash.
>
> Sure there is.  If DSA used any other 160-bit hash, it wouldn't be DSA
> anymore because the DSA spec demands SHA.  Insofar as whether or not the
> DSA spec could be changed to accept RIPEMD-160, and whether or not the
> resulting system would still be secure... who knows?  Cryptosystems are
> fragile things; known-strong algorithms can interact with each other to
> produce weak systems.

You are confusing DSA (the algorithm) with DSS (the standard). DSS
mandates DSA and SHA-1. DSA, however, could be used with any strong hash
function that is sufficiently long.

--Len.












From rjhansen at inav.net  Fri May 10 21:51:01 2002
From: rjhansen at inav.net (Robert J. Hansen)
Date: Tue Oct  7 21:29:03 2003
Subject: force-v4-certs and digest-algo
In-Reply-To: <Pine.LNX.4.30.QNWS.0205101003070.3958-100000@thetis.deor.org>
Message-ID: <Pine.LNX.4.44L0.0205101348180.7060-100000@soli.inav.net>

> The entire point of the IETF, and of the RFC system, is to eliminate the
> "de facto standards" mess, and give us actual standards.

... and to further elaborate my point (which follows from that): a 
standard quickly devolves to near-uselessness if people start extending it 
willy-nilly.  Look at the UNIX Wars, or "This Site Best Viewed In".  A 
standard ought be adhered to unless there are clear and compelling reasons 
not to do so.  I don't see any clear and compelling reason to use 
RIPEMD-160, and so I don't.  (Let me say, though, that it's not my 
intention to speak for anyone but me.)

> You are confusing DSA (the algorithm) with DSS (the standard). DSS

D'oh.  My goof.





From dshaw at jabberwocky.com  Fri May 10 22:19:01 2002
From: dshaw at jabberwocky.com (David Shaw)
Date: Tue Oct  7 21:29:03 2003
Subject: force-v4-certs and digest-algo
In-Reply-To: <Pine.LNX.4.44L0.0205101348180.7060-100000@soli.inav.net>
References: <Pine.LNX.4.30.QNWS.0205101003070.3958-100000@thetis.deor.org> <Pine.LNX.4.44L0.0205101348180.7060-100000@soli.inav.net>
Message-ID: <20020510192021.GA14633@akamai.com>

On Fri, May 10, 2002 at 01:52:32PM -0500, Robert J. Hansen wrote:
> > The entire point of the IETF, and of the RFC system, is to eliminate the
> > "de facto standards" mess, and give us actual standards.
> 
> ... and to further elaborate my point (which follows from that): a 
> standard quickly devolves to near-uselessness if people start extending it 
> willy-nilly.  Look at the UNIX Wars, or "This Site Best Viewed In".  A 
> standard ought be adhered to unless there are clear and compelling reasons 
> not to do so.  I don't see any clear and compelling reason to use 
> RIPEMD-160, and so I don't.  (Let me say, though, that it's not my 
> intention to speak for anyone but me.)

Just to be clear here, using RIPEMD-160 is completely and totally
adhering to the OpenPGP standard in every possible way.  There are
certainly minor compatibility reasons not to use it, but it is
definitely part of the standard.  To put this in context, other
completely optional parts of the standard are Blowfish, Twofish, and
every AES above 128 bits.

Using "Joe's Random Hash Algorithm 128" would be willy-nilly. ;)

Werner and I discussed it, and I've added the ability to pick the hash
when making a key signature (--cert-digest-algo) to 1.0.8.  I do hope
people will not use this feature (and the manual explains why it isn't
a good idea), but in the end, it is up to them what hash they use.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From dgc at uchicago.edu  Fri May 10 22:29:02 2002
From: dgc at uchicago.edu (David Champion)
Date: Tue Oct  7 21:29:03 2003
Subject: force-v4-certs and digest-algo
In-Reply-To: <20020510192021.GA14633@akamai.com>
References: <Pine.LNX.4.30.QNWS.0205101003070.3958-100000@thetis.deor.org> <Pine.LNX.4.44L0.0205101348180.7060-100000@soli.inav.net> <20020510192021.GA14633@akamai.com>
Message-ID: <20020510192938.GF9707@dust.uchicago.edu>

* On 2002.05.10, in <20020510192021.GA14633@akamai.com>,
*	"David Shaw" <dshaw@jabberwocky.com> wrote:
> 
> Using "Joe's Random Hash Algorithm 128" would be willy-nilly. ;)

But I've tested it thoroughly, and I'm certain it's quite secure -- our
reference code remains uncracked! The source is even available (for a
nominal licensing fee) to anyone who passes our trust audit. Why are you
repressing us?

--
Joe
Joe's Codes, Ltd.
Call for a quote! +1-900-SAF-CODE


From sandeep_sikka at hotmail.com  Sat May 11 01:12:02 2002
From: sandeep_sikka at hotmail.com (Sandeep Sikka)
Date: Tue Oct  7 21:29:03 2003
Subject: GPG 1.0.6 bug - sign/encrypt/decrypt 0 bytes.
Message-ID: <F1024t5BD8wbVGkJmiW00014762@hotmail.com>

Hi,

If I sign/encrypt & then decrypt 0 bytes, I get junk. I don't get 0 bytes. 
If I use even one byte, I have no problems. If I just encrypt/decrypt 0 
bytes, I get 0 bytes in return. But if I sign, I have problems. Is this a 
known bug with GPG? Or am I not understanding & using GPG properly?

Thanks!

Sandeep.

----
sikka@debian:~$ gpg --version
gpg (GnuPG) 1.0.6
Copyright (C) 2001 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.
----

sikka@debian:~$ gpg --list-keys
/u3/sikka/.gnupg/pubring.gpg
----------------------------
pub  1024D/85DEA7EC 2002-05-10 Sandeep Sikka (test key) 
<sikka@iamtesting.com>
sub  1024g/64B4BEA2 2002-05-10
----

# Encrypt 0 bytes - NO PROBLEM
sikka@debian:~$ echo -n | gpg -ea -r sikka@iamtesting.com -u 
sikka@iamtesting.com | gpg --decrypt
gpg: NOTE: secret key 85DEA7EC is NOT protected.
gpg: NOTE: secret key 85DEA7EC is NOT protected.
gpg: encrypted with 1024-bit ELG-E key, ID 64B4BEA2, created 2002-05-10
      "Sandeep Sikka (test key) <sikka@iamtesting.com>"
----

# Sign/encrypt one byte - NO PROBLEM
sikka@debian:~$ echo X | gpg -sea -r sikka@iamtesting.com -u 
sikka@iamtesting.com | gpg --decrypt
gpg: NOTE: secret key 85DEA7EC is NOT protected.
gpg: NOTE: secret key 85DEA7EC is NOT protected.
gpg: encrypted with 1024-bit ELG-E key, ID 64B4BEA2, created 2002-05-10
      "Sandeep Sikka (test key) <sikka@iamtesting.com>"
X
gpg: Signature made Fri May 10 18:05:33 2002 EDT using DSA key ID 85DEA7EC
gpg: Good signature from "Sandeep Sikka (test key) <sikka@iamtestng.com>"
----

# Sign/Encrypt 0 bytes - PROBLEM CASE
sikka@debian:~$ echo -n | gpg -sea -r sikka@iamtesting.com -u 
sikka@iamtesting.com | gpg --decrypt
gpg: NOTE: secret key 85DEA7EC is NOT protected.
gpg: NOTE: secret key 85DEA7EC is NOT protected.
gpg: encrypted with 1024-bit ELG-E key, ID 64B4BEA2, created 2002-05-10
      "Sandeep Sikka (test key) <sikka@iamtesting.com>"
?b<ÜDfbùú4RÞNbÄÃ ÁF>/èLErå9æCmÜsâ(×t
----











_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com



From dshaw at jabberwocky.com  Sat May 11 01:26:01 2002
From: dshaw at jabberwocky.com (David Shaw)
Date: Tue Oct  7 21:29:03 2003
Subject: GPG 1.0.6 bug - sign/encrypt/decrypt 0 bytes.
In-Reply-To: <F1024t5BD8wbVGkJmiW00014762@hotmail.com>
References: <F1024t5BD8wbVGkJmiW00014762@hotmail.com>
Message-ID: <20020510222724.GE14633@akamai.com>

On Fri, May 10, 2002 at 05:12:17PM -0500, Sandeep Sikka wrote:
> Hi,
> 
> If I sign/encrypt & then decrypt 0 bytes, I get junk. I don't get 0 bytes. 
> If I use even one byte, I have no problems. If I just encrypt/decrypt 0 
> bytes, I get 0 bytes in return. But if I sign, I have problems. Is this a 
> known bug with GPG? Or am I not understanding & using GPG properly?

This was fixed in GnuPG 1.0.7.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From benfell at greybeard95a.com  Sun May 12 08:07:01 2002
From: benfell at greybeard95a.com (David Benfell)
Date: Tue Oct  7 21:29:03 2003
Subject: configure produces zero length Makefile
In-Reply-To: <040301c1f050$f71bf8e0$ede3c23f@KR6X.ORG>
References: <040301c1f050$f71bf8e0$ede3c23f@KR6X.ORG>
Message-ID: <20020512050748.GF17531@raven.parts-unknown.org>

Hello all,

When I ran configure (with --prefix=/usr), I observed the following:

configure: creating ./config.status
config.status: creating Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating intl/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating po/Makefile.in
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating util/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating mpi/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating cipher/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating g10/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating keyserver/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating keyserver/gpgkeys_mailto
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating keyserver/gpgkeys_test
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating doc/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating tools/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating zlib/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating checks/Makefile
sed: file /tmp/csoDopl4/subs-2.sed line 4: Unterminated `s' command
config.status: creating config.h
config.status: config.h is unchanged
config.status: linking ./mpi/i386/mpih-add1.S to mpi/mpih-add1.S
config.status: linking ./mpi/i386/mpih-mul1.S to mpi/mpih-mul1.S
config.status: linking ./mpi/i386/mpih-mul2.S to mpi/mpih-mul2.S
config.status: linking ./mpi/i386/mpih-mul3.S to mpi/mpih-mul3.S
config.status: linking ./mpi/i386/mpih-lshift.S to mpi/mpih-lshift.S
config.status: linking ./mpi/i386/mpih-rshift.S to mpi/mpih-rshift.S
config.status: linking ./mpi/i386/mpih-sub1.S to mpi/mpih-sub1.S
config.status: linking ./mpi/generic/mpi-asm-defs.h to
mpi/mpi-asm-defs.h
config.status: creating po/POTFILES
config.status: creating po/Makefile
g10defs.h is unchanged

                Configured for: GNU/Linux (i686-pc-linux-gnu)
    Dynamically linked modules: rndunix rndegd tiger
     Statically linked modules: rndlinux sha1 rmd160 md5

make: *** No targets.  Stop.
root@home:/usr/local/src/gnupg-1.0.7 # ls -al Makefile*
-rw-r--r--    1 root     root            0 May  1 22:51 Makefile
-rw-r--r--    1 1000     1000         1800 Dec 21 11:49 Makefile.am
-rw-rw-r--    1 1000     1000        16187 Apr 29 08:06 Makefile.in

I tried attaching the configure log, but this caused the e-mail to
exceed the 40KB limit for posting.

This is on a SuSE 7.1 system which has been heavily upgraded, mostly
from source.


-- 
David Benfell, LCP
benfell@parts-unknown.org
---
Resume available at http://www.parts-unknown.org/resume.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 536 bytes
Desc: not available
Url : /pipermail/attachments/20020512/fca12412/attachment.bin
From srm_dfr at hotmail.com  Sun May 12 17:16:02 2002
From: srm_dfr at hotmail.com (eloj %20)
Date: Tue Oct  7 21:29:03 2003
Subject: encrypting to public key crashes gnupg 1.0.6-2 (win32)
Message-ID: <F125KpO2DTSWFSSEfLM00015e40@hotmail.com>

I was helping a friend set up GnuPG 1.0.6-2 Win32 yesterday. When all was 
set up we discovered that no-one seemed able to encrypt to his key.

The crash is reproducably on several installations.

'The instruction at "0x74fad613" referenced memory at "0x024a5000". The 
memory could not be "written".'

I haven't bothered testing on 1.0.7 since there is no officiall win32-port 
yet.

Anyone willing to take a look at the key and see if they can reproduce the 
problem? A developer with a what-will-become win32 build maybe.

I won't post the key here since the secret key doesn't exist any more and 
there is no revocation should it slip into the wild, but if anyone wants it 
contact me at eddy klopper net.


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.



From redbird at rbisland.cx  Sun May 12 19:58:01 2002
From: redbird at rbisland.cx (Gordon Worley)
Date: Tue Oct  7 21:29:03 2003
Subject: configure produces zero length Makefile
In-Reply-To: <20020512050748.GF17531@raven.parts-unknown.org>
Message-ID: <3057365C-65C9-11D6-A13F-000A27B4DEFC@rbisland.cx>

On Sunday, May 12, 2002, at 01:07  AM, David Benfell wrote:

> make: *** No targets.  Stop.
> root@home:/usr/local/src/gnupg-1.0.7 # ls -al Makefile*
> -rw-r--r--    1 root     root            0 May  1 22:51 Makefile
> -rw-r--r--    1 1000     1000         1800 Dec 21 11:49 Makefile.am
> -rw-rw-r--    1 1000     1000        16187 Apr 29 08:06 Makefile.in

This looks a lot like what happens on Darwin.  While it's not likely the 
same but, it's worth mentioning that if your sh is really zsh, you need 
to go through the configure script and change all instances of 'CDPATH=' 
to 'unset CDPATH'.

--
Gordon Worley                     `When I use a word,' Humpty Dumpty
http://www.rbisland.cx/            said, `it means just what I choose
redbird@rbisland.cx                it to mean--neither more nor less.'
PGP:  0xBBD3B003                                  --Lewis Carroll



From benfell at greybeard95a.com  Mon May 13 01:25:01 2002
From: benfell at greybeard95a.com (David Benfell)
Date: Tue Oct  7 21:29:03 2003
Subject: configure produces zero length Makefile
In-Reply-To: <3057365C-65C9-11D6-A13F-000A27B4DEFC@rbisland.cx>
References: <20020512050748.GF17531@raven.parts-unknown.org> <3057365C-65C9-11D6-A13F-000A27B4DEFC@rbisland.cx>
Message-ID: <20020512222543.GA803@raven.parts-unknown.org>

On Sun, 12 May 2002 12:56:22 -0400, Gordon Worley wrote:
> 
> On Sunday, May 12, 2002, at 01:07  AM, David Benfell wrote:
> 
> >make: *** No targets.  Stop.
> >root@home:/usr/local/src/gnupg-1.0.7 # ls -al Makefile*
> >-rw-r--r--    1 root     root            0 May  1 22:51 Makefile
> >-rw-r--r--    1 1000     1000         1800 Dec 21 11:49 Makefile.am
> >-rw-rw-r--    1 1000     1000        16187 Apr 29 08:06 Makefile.in
> 
> This looks a lot like what happens on Darwin.  While it's not likely the 
> same but, it's worth mentioning that if your sh is really zsh,

Yup, I did that.  I hate bash.  I'd had some problems with
initialization scripts as a result but solved those with simpler,
customized language.

> you need 
> to go through the configure script and change all instances of 'CDPATH=' 
> to 'unset CDPATH'.
> 
Good catch.  Really good catch.  Thank you.

-- 
David Benfell
benfell@parts-unknown.org
---
There's an old proverb that says just about whatever you want it to.
                                [from fortune]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 536 bytes
Desc: not available
Url : /pipermail/attachments/20020513/969f4c13/attachment.bin
From request at logos.net  Mon May 13 07:11:02 2002
From: request at logos.net (request@logos.net)
Date: Tue Oct  7 21:29:04 2003
Subject: Verba Volant
Message-ID: <E1777dv-00057k-00@porta.u64.de>

13-MAY-02
We have been requested to insert the following email address, "gnupg-devel@gnupg.org", in the Verba Volant Newsletter database. Through this daily service you will receive a quotation, selected from amongst the most celebrated philosophers, writers and poets of all time and translated into many languages and dialects by volunteers worldwide.
If you would like to confirm your subscription to Verba Volant, please click on the following link: 
http://www.logos.net/owa-l/press.subscribe?lang=en&email=gnupg-devel@gnupg.org 
If you do not wish to click on the link, your subscription will be cancelled.
Thank you for your time.
Verba Volant



13-MAY-02
Il nous a été demandé d'ajouter l'adresse électronique "gnupg-devel@gnupg.org" dans la liste des destinataires de Verba Volant, un service qui tous les jours vous adressera une citation sélectionnée parmi les œuvres des meilleurs philosophes, écrivains, poètes de tous les temps et traduite en de très nombreuses langues grâce à des volontaires du monde entier.
Pour confirmer l'inscription à Verba Volant, veuillez vous connecter au lien suivant:
http://www.logos.net/owa-l/press.subscribe?lang=fr&email=gnupg-devel@gnupg.org 
Si vous préférez ne pas cliquer sur le lien, vous ne recevrez rien.

Merci dans tous les cas de nous avoir accordé quelques secondes.
Verba Volant



13-MAY-02
Se nos ha solicitado insertar la dirección de correo electrónico "gnupg-devel@gnupg.org" en el listado de envíos de Verba Volant, un servicio que diariamente le enviará citas elegidas entre los mejores filosofos, escritores, poetas, etc., traducidas a varios idiomas y dialectos. Dichas citas están traducidas por voluntarios que se conectan a nuestra web desde todo el mundo.
Si quiere confirmar la suscripción a Verba Volant, le rogamos entre en: 
http://www.logos.net/owa-l/press.subscribe?lang=es&email=gnupg-devel@gnupg.org 
Si no entra en la dirección señalada no recibirá las citas.
Muchas gracias por el tiempo que nos ha dedicado.
Verba Volant



13-MAY-02
Ci è stato chiesto di inserire l'indirizzo di posta elettronica "gnupg-devel@gnupg.org" nell’elenco dei destinatari di Verba Volant, un servizio che ogni giorno ti invierà una citazione scelta tra quelle dei migliori filosofi, scrittori, poeti di tutti i tempi e tradotta in moltissime lingue e dialetti grazie alla collaborazione di volontari da tutto il mondo.
Se desideri confermare l'iscrizione, ti preghiamo di collegarti al seguente link:
http://www.logos.net/owa-l/press.subscribe?lang=it&email=gnupg-devel@gnupg.org 
Nel caso preferissi non cliccare sul link, non riceverai nulla. 

Grazie comunque per i secondi che ci hai dedicato.
Cordiali saluti.






From wk at gnupg.org  Mon May 13 10:17:07 2002
From: wk at gnupg.org (Werner Koch)
Date: Tue Oct  7 21:29:04 2003
Subject: [Administriva] MLs closed
Message-ID: <87wuu8tt1s.fsf@alberti.gnupg.de>

Hi!

I am getting annoyed of all the spam so I finally closed the mailing
lists.  From now on only subscribers are allowed to post.  Messages
from non-subscribers are held for approval but the chance that I find
time to actual approve a message is not very high.  Hopefully we don't
get too much spam with faked From addresses.

If someone wants to volunteer as a listmaster please drop me a note.

  Werner



From Fabian.Rodriguez at Toxik.com  Tue May 14 00:24:01 2002
From: Fabian.Rodriguez at Toxik.com (Toxik - Fabian Rodriguez)
Date: Tue Oct  7 21:29:04 2003
Subject: Verifying signatures via WWW interface
In-Reply-To: <F1024t5BD8wbVGkJmiW00014762@hotmail.com>
Message-ID: <MJEDILLCNFHIFGNJHDMGAELHDNAA.Fabian.Rodriguez@Toxik.com>

Hello,

I'd like to know if it's logical to offer to people to verify signatures of
short texts via a web interface. I'm trying to understand some other
applications of OpenPGP/gnupg.

I thought having public keys of the signers on a local keyring would be
enough but GPG sends these warnings after displaying date and author
information:

  Could not find a valid trust path to the key.  Let's see whether we
  can assign some missing owner trust values.

  No path leading to one of our keys found.

  gpg: WARNING: This key is not certified with a trusted signature!
  gpg:          There is no indication that the signature belongs to the
owner.
  gpg: Fingerprint: A6EF 1DF9 39CC 873C 5855  D7BA 93E0 2B96 73AE 57A0

Of course, we don't want to store a private key for this particular
application, what would be required to have a trust path ? The local keyring
only has public keys in this example.

Thanks for any information on this.

Fabi?n Rodr?guez - Toxik Technologies, Inc.
www.toxik.com ? (514) 528-6945 @221
OpenPGP: 0x5AF2A4D5




From dmitri at users.sourceforge.net  Tue May 14 00:41:02 2002
From: dmitri at users.sourceforge.net (Dmitri)
Date: Tue Oct  7 21:29:04 2003
Subject: Verifying signatures via WWW interface
In-Reply-To: <MJEDILLCNFHIFGNJHDMGAELHDNAA.Fabian.Rodriguez@Toxik.com>
References: <MJEDILLCNFHIFGNJHDMGAELHDNAA.Fabian.Rodriguez@Toxik.com>
Message-ID: <1021326141.10775.387.camel@usb.networkfab.com>

On Mon, 2002-05-13 at 14:22, Toxik - Fabian Rodriguez wrote:

> I'd like to know if it's logical to offer to people to verify signatures of
> short texts via a web interface.

As long as you don't mind sending your plaintext over the network, and
telling anyone who cares to sniff the traffic what messages and who
receives, and from who, and when...

> I thought having public keys of the signers on a local keyring would be
> enough but GPG sends these warnings after displaying date and author
> information:
> 
>   Could not find a valid trust path to the key.  Let's see whether we
>   can assign some missing owner trust values.
> 
>   No path leading to one of our keys found.
> 
>   gpg: WARNING: This key is not certified with a trusted signature!
>   gpg:          There is no indication that the signature belongs to the
> owner.

You need to sign the public key of that other person. It will tell GnuPG
that you believe that the key belongs to that person. You should find
more detailed explanations in many places, such as www.gnupg.org ...

Dmitri

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : /pipermail/attachments/20020513/7bd48714/attachment.bin
From gnupg at lists.colondot.net  Tue May 14 01:08:02 2002
From: gnupg at lists.colondot.net (Matthew Byng-Maddick)
Date: Tue Oct  7 21:29:04 2003
Subject: Verifying signatures via WWW interface
In-Reply-To: <1021326141.10775.387.camel@usb.networkfab.com>; from dmitri@users.sourceforge.net on Mon, May 13, 2002 at 02:42:21PM -0700
References: <MJEDILLCNFHIFGNJHDMGAELHDNAA.Fabian.Rodriguez@Toxik.com> <1021326141.10775.387.camel@usb.networkfab.com>
Message-ID: <20020513230901.A26054@colon.colondot.net>

On Mon, May 13, 2002 at 02:42:21PM -0700, Dmitri wrote:
> On Mon, 2002-05-13 at 14:22, Toxik - Fabian Rodriguez wrote:
> > I'd like to know if it's logical to offer to people to verify signatures of
> > short texts via a web interface.
> As long as you don't mind sending your plaintext over the network, and
> telling anyone who cares to sniff the traffic what messages and who
> receives, and from who, and when...

This is less of an issue (since we're talking about verifying signatures,
it may well have come in in plaintext) than an ability to trust that the
website is not just telling you that a signature is verified, without
having bothered to do the calculation. Or alternatively telling you it
isn't when it might have done.

It's easier to verify that a binary on your disk hasn't been modified.

MBM

-- 
Matthew Byng-Maddick         <mbm@colondot.net>           http://colondot.net/


From lists at lina.inka.de  Tue May 14 01:24:02 2002
From: lists at lina.inka.de (Bernd Eckenfels)
Date: Tue Oct  7 21:29:04 2003
Subject: Verifying signatures via WWW interface
In-Reply-To: <MJEDILLCNFHIFGNJHDMGAELHDNAA.Fabian.Rodriguez@Toxik.com>
References: <F1024t5BD8wbVGkJmiW00014762@hotmail.com> <MJEDILLCNFHIFGNJHDMGAELHDNAA.Fabian.Rodriguez@Toxik.com>
Message-ID: <20020513222452.GA30503@lina.inka.de>

On Mon, May 13, 2002 at 05:22:01PM -0400, Toxik - Fabian Rodriguez wrote:
> Of course, we don't want to store a private key for this particular
> application, what would be required to have a trust path ? The local keyring
> only has public keys in this example.

You can eighter ignore the message or lsign all your keys in the keying with
a "trusted" key. you do not need to store the trusted key on the system, you
can mark a public key as trusted. this is used like this:

a) user sends you key, you verify it and sign it
b) you store the signed key on a automatic signature checking device. in
order to avoid to have to store your signature generating key on that device
you just place the public key there and mark it trusted. this has the
advantage (over blindly trusting al keys in keyring) that adding keys to the
keyring is not a priveledged application and does not need a trusted channel
to the verifier.

hope this is clear, i use this for a B2Bi Server which is able to check
incoming messages from trading partners and decides if they are known, based
on a "accept" lsign from operating staff. this even works with a keyserver.

Greetings
Bernd


From aphex at nullify.org  Wed May 15 00:45:07 2002
From: aphex at nullify.org (Keith Ray)
Date: Tue Oct  7 21:29:04 2003
Subject: GnuPG 1.0.7a+ DIRSEP
Message-ID: <1021412756.3ce185948636c@mail.nullify.org>

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

I have noticed that new DIRSEPs have been committed to the GnuPG 1.07a+
tree.  I would like to include them in a future win32 release, but I am
unsure about whether to change certain paths or not.

Currently, I use the following defaults:

[HKEY_CURRENT_USER\Control Panel\Mingw32\NLS]
"MODir"="C:/GnuPG/Locale"

[HKEY_CURRENT_USER\Software\GNU\GnuPG]
"HomeDir"="C:/GnuPG"

load-extension Lib/idea
load-extension Lib/tiger
load-extension Lib/sha2

Should all of these be changed from '/' to '\' in 1.0.7a+ versions?

  -- Keith

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (MingW32) - GPGshell v2.28

iD8DBQE84YQuBxrjkHkmmhIRAnpmAJ9NWRLU6zqvEVM99nfagGOk31xSTwCdEtoA
bt5GQF46qvVrfBhgVBCQCiI=
=xzfO
-----END PGP SIGNATURE-----


From aphex at nullify.org  Fri May 17 01:50:02 2002
From: aphex at nullify.org (Keith Ray)
Date: Tue Oct  7 21:29:04 2003
Subject: [BUG FIX] Win32 Performance Counters
Message-ID: <1021589460.3ce437d487922@mail.nullify.org>

In cipher/rndw32.c, GnuPG attempts to gather physical disk performance counter
data for random number generation.  However, if the IOCTL_DISK_PERFORMANCE call
fails for any reason, GPG displays:

"NOTE: you should run 'diskperf -y' to enable the disk statistics"

I created a debug version of GnuPG and called GetLastError() and got:

"The data area passed to a system call is too small."

I did some investigating and found that the Win32 header files from Mingw32/CPD
are incorrect.  Both the LARGE_INTEGER and DISK_PERFORMANCE struct are smaller
than required.  Once these changes were made, I was able to produce a working
GnuPG that successfully called IOCTL_DISK_PERFORMANCE.  However, GCC gave the
following warning:

In file included from
/usr/local/lib/mingw32-cpd/lib/gcc-lib/i386--mingw32/2.95.2wk20010117/../../../../i386--mingw32/include/windows.h:48,
                 from rndw32.c:69:
/usr/local/lib/mingw32-cpd/lib/gcc-lib/i386--mingw32/2.95.2wk20010117/../../../../i386--mingw32/include/Windows32/Structures.h:1080:
warning: unnamed struct/union that defines no instances


mingw32-cpd/i386--mingw32/include/Windows32/Structures.h
--------------------------------------------------------

typedef struct _LARGE_INTEGER {
  DWORD LowPart;
  LONG  HighPart;
} LARGE_INTEGER, *PLARGE_INTEGER;

typedef struct _DISK_PERFORMANCE {
  LARGE_INTEGER BytesRead;
  LARGE_INTEGER BytesWritten;
  LARGE_INTEGER ReadTime;
  LARGE_INTEGER WriteTime;
  DWORD ReadCount;
  DWORD WriteCount;
  DWORD QueueDepth;
} DISK_PERFORMANCE ;


Microsoft Platform SDK\Include\WinIoCtl.h
-----------------------------------------

typedef struct _DISK_PERFORMANCE {
        LARGE_INTEGER BytesRead;
        LARGE_INTEGER BytesWritten;
        LARGE_INTEGER ReadTime;
        LARGE_INTEGER WriteTime;
        LARGE_INTEGER IdleTime;
        DWORD ReadCount;
        DWORD WriteCount;
        DWORD QueueDepth;
        DWORD SplitCount;
        LARGE_INTEGER QueryTime;
        DWORD   StorageDeviceNumber;
        WCHAR   StorageManagerName[8];
} DISK_PERFORMANCE, *PDISK_PERFORMANCE;


Microsoft Platform SDK\Include\WinNT.h
--------------------------------------

typedef union _LARGE_INTEGER {
    struct {
        DWORD LowPart;
        LONG HighPart;
    };
    struct {
        DWORD LowPart;
        LONG HighPart;
    } u;
    LONGLONG QuadPart;
} LARGE_INTEGER;


From keith at nullify.org  Fri May 17 11:33:01 2002
From: keith at nullify.org (Keith Ray)
Date: Tue Oct  7 21:29:04 2003
Subject: GnuPG 1.0.7a+ DIRSEP
Message-ID: <1021412447.3ce1845f9a7bd@mail.nullify.org>

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

I have noticed that new DIRSEPs have been committed to the GnuPG 1.07a+
tree.  I would like to include them in a future win32 release, but I am
unsure about whether to change certain paths or not.

Currently, I use the following defaults:

[HKEY_CURRENT_USER\Control Panel\Mingw32\NLS]
"MODir"="C:/GnuPG/Locale"

[HKEY_CURRENT_USER\Software\GNU\GnuPG]
"HomeDir"="C:/GnuPG"

load-extension Lib/idea
load-extension Lib/tiger
load-extension Lib/sha2

Should all of these be changed from '/' to '\' in 1.0.7a+ versions?

  -- Keith

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (MingW32) - GPGshell v2.28

iD8DBQE84YQuBxrjkHkmmhIRAnpmAJ9NWRLU6zqvEVM99nfagGOk31xSTwCdEtoA
bt5GQF46qvVrfBhgVBCQCiI=
=xzfO
-----END PGP SIGNATURE-----


From chris at netservers.co.uk  Fri May 17 11:33:04 2002
From: chris at netservers.co.uk (Chris Wilson)
Date: Tue Oct  7 21:29:04 2003
Subject: Operation on read-only filesystem
Message-ID: <Pine.LNX.4.44.0205151157380.11907-200000@localhost>

Dear GnuPG developers,

I have been trying to get GnuPG working on a read-only filesystem, and I 
think I have hit the same problem as Patrick Higgins 
(http://lists.gnupg.org/pipermail/gnupg-devel/2000-July/005221.html), that 
the trust database is opened read-write. His suggestion of a --read-only 
option seems like a good one. If I wrote a patch to add this option, would 
anyone care to integrate it with GnuPG?

I have also been maintaining my batch-sign patch, and just updated it to 
GPG 1.0.7. This fixes what I believe to be a bug in GnuPG, that for no 
apparent reason, signing keys is disabled in batch-mode. The patch is very 
simple, and I hope you will consider applying it.

Cheers, Chris.
-- 
   ___ __     _
 / __// / ,__(_)_  | Chris Wilson -- UNIX Firewall Lead Developer |
/ (_ / ,\/ _/ /_ \ | NetServers.co.uk http://www.netservers.co.uk |
\ _//_/_/_//_/___/ | 21 Signet Court, Cambridge, UK. 01223 576516 |
-------------- next part --------------
diff -ru2 gnupg-1.0.7/g10/keyedit.c gnupg-1.0.7-chris/g10/keyedit.c
--- gnupg-1.0.7/g10/keyedit.c	Mon Apr 29 15:34:21 2002
+++ gnupg-1.0.7-chris/g10/keyedit.c	Wed May 15 11:52:33 2002
@@ -871,4 +871,12 @@
     int have_commands = !!commands;
 
+    if( sign_mode ) {
+        commands = NULL;
+        append_to_strlist( &commands, sign_mode == 1? "sign":
+                           sign_mode == 2?"lsign":
+                           sign_mode == 3?"nrsign":"nrlsign");
+        have_commands = 1;
+    }
+
     if ( opt.command_fd != -1 )
         ;
@@ -876,12 +884,4 @@
 	log_error(_("can't do that in batchmode\n"));
 	goto leave;
-    }
-
-    if( sign_mode ) {
-	commands = NULL;
-	append_to_strlist( &commands, sign_mode == 1? "sign":
-			   sign_mode == 2?"lsign":
-			   sign_mode == 3?"nrsign":"nrlsign");
-	have_commands = 1;
     }
 
From andy.ozment at cc.gatech.edu  Fri May 17 11:33:06 2002
From: andy.ozment at cc.gatech.edu (Andy Ozment)
Date: Tue Oct  7 21:29:04 2003
Subject: Wrong signature on idea.c, broken link
Message-ID: <3CE2BF5E.C58AAD75@cc.gatech.edu>

I'm new to gpg, so I apologize if these "bugs" are really my ignorance
rather than a bug.

1. In an attempt to get the idea module, I went to the page
<http://www.gnupg.org/why-not-idea.html>

I downloaded the files idea.c and idea.c.sig. I then tried to check the
sig:
$ gpg --verify idea.c.sig idea.c
gpg: Warning: using insecure memory!
gpg: please see http://www.gnupg.org/faq.html for more information
gpg: Signature made Fri Aug 17 03:34:05 2001 EDT using DSA key ID
621CC013
gpg: Can't check signature: public key not found

$ gpg --list-keys
pub  1024D/57548DCD 1998-07-07 Werner Koch (gnupg sig) <dd9jn@gnu.org>

It appears to me, then, that idea.c was not signed with the key that
signed the entire distribution (57548DCD, Werner Koch). Is this
intentional? I could not find the key that did sign the file anywhere on
the site.



2. On a completely different note, on the page
<http://www.gnupg.org/docs.html>, the link "list of bugs" which points
to <http://bugs.guug.de/Bugs/db/pa/lgnupg.html> is broken.


Please copy any responses to me, as I am not a member of this list.
Again, if this is not really a mistake and is just me being dumb, then I
apologize for being an annoying newbie!
Thanks!
Andy

-- 
  Andy Ozment
  Research Scientist
  Georgia Tech College of Computing


From avbidder at fortytwo.ch  Fri May 17 18:16:01 2002
From: avbidder at fortytwo.ch (Adrian 'Dagurashibanipal' von Bidder)
Date: Tue Oct  7 21:29:04 2003
Subject: secure sign & encrypt
Message-ID: <1021648640.7790.33.camel@atlas>

Yo!

After having read the paper refernced in the ongoing 'signing &
encrypting' thread on gpg-users

http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html

I feel that these flaws are quite serious, as non-experts (like me)
almost automatically assume end-to-end security if they receive
encrypted mail. I'm not on this list very long, so I didn't get previous
discussions of this (are theare *searchable* archives?)

How about this extension of the openPGP standard:

the signature (openpgp-)packet of a signed & encrypted msg includes an
additional (signed!!!) subpacket of the new type 'intended encryption
key'. when gpg is told to verify a message and finds such a subpacket,
it prints an error message if 
 - the message is not encrypted
 - the message is encrypted, but not with the intended key.
conventional signed & encrypted msgs produce a warning along the lines
of 'it can not be asserted that this message was encrypted by the
original sender. See <URL> for more information'.

(Of course, more than one 'intended encryption key' subpackets must be
allowed)

Yes, this is not rfc - but I got the impression that the gpg people are
not against extending the standard if there are valid reasons (cf.
picture id)


And while I'm at it (though this is tangential here, I know):

extension to the OpenPGP-MIME RFC 3156: Add the To:, From: and Subject:
headers of the mail to the (signed) MIME headers of multipart/signed
msgs and bug the mailreader people to verify the mail headers with
these.



comments?
-- vbi


-- 
secure email with gpg                 avbidder@fortytwo.ch: key id
0x92082481
                                      avbidder@acter.ch:    key id
0x5E4B731F

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : /pipermail/attachments/20020517/657bb840/attachment.bin
From jharris at widomaker.com  Fri May 17 21:10:02 2002
From: jharris at widomaker.com (Jason Harris)
Date: Tue Oct  7 21:29:04 2003
Subject: Wrong signature on idea.c, broken link
In-Reply-To: <3CE2BF5E.C58AAD75@cc.gatech.edu>
References: <3CE2BF5E.C58AAD75@cc.gatech.edu>
Message-ID: <20020517181046.GA317@p5.widomaker.com>

On Wed, May 15, 2002 at 04:04:46PM -0400, Andy Ozment wrote:

> I'm new to gpg, so I apologize if these "bugs" are really my ignorance
> rather than a bug.

You've been using (commercial) PGP all this time?  :(

> 1. In an attempt to get the idea module, I went to the page
> <http://www.gnupg.org/why-not-idea.html>
> 
> I downloaded the files idea.c and idea.c.sig. I then tried to check the
> sig:
> $ gpg --verify idea.c.sig idea.c
> gpg: Warning: using insecure memory!
> gpg: please see http://www.gnupg.org/faq.html for more information
> gpg: Signature made Fri Aug 17 03:34:05 2001 EDT using DSA key ID
> 621CC013
> gpg: Can't check signature: public key not found
> 
> $ gpg --list-keys
> pub  1024D/57548DCD 1998-07-07 Werner Koch (gnupg sig) <dd9jn@gnu.org>
> 
> It appears to me, then, that idea.c was not signed with the key that
> signed the entire distribution (57548DCD, Werner Koch). Is this
> intentional? I could not find the key that did sign the file anywhere on
> the site.

Use the keyservers, Luke!

(However, it doesn't look like Werner has cross-signed all his keys...)

pub  1024D/621CC013 1998-07-07 Werner Koch <werner.koch@guug.de>
     Key fingerprint = ECAF 7590 EB34 43B5 C7CF  3ACB 6C7E E1B8 621C C013
sig?       FF3EAA0B 1998-07-07  [User id not found]
sig        0C9857A5 1998-07-08  Werner Koch <werner.koch@guug.de>
sig        9265FAFB 2001-11-03  Derek Gaston <dgaston@umr.edu>
sig        513AEFD9 2000-09-25  Hans-Joerg Hoexer <hshoexer@rommel.stw.uni-erlangen.de>
sig        82957B66 2000-07-11  Hideki Saito <hideki@allcity.net>
sig        C5E88112 2000-02-22  Ruediger Hahn <ruedi007@topmail.de>
sig        5B0358A2 1999-03-15  Werner Koch <wk@gnupg.org>
sig        B1CC03AA 1999-06-21  Javier Kohen <jkohen@tough.com>
sig        621CC013 1999-11-12  Werner Koch <werner.koch@guug.de>
uid                            Werner Koch <wk@gnupg.org>
sig        5B0358A2 2000-10-01  Werner Koch <wk@gnupg.org>
sig        621CC013 2000-11-21  Werner Koch <werner.koch@guug.de>
uid                            Werner Koch <wk@openit.de>
sig        513AEFD9 2000-09-25  Hans-Joerg Hoexer <hshoexer@rommel.stw.uni-erlangen.de>
sig        82957B66 2000-07-11  Hideki Saito <hideki@allcity.net>
sig        621CC013 2000-11-21  Werner Koch <werner.koch@guug.de>
sig        90F89A7D 2001-01-25  Ralf Hildebrandt <ralf.hildebrandt@innominate.com>

-- 
Jason Harris          | NIC:  JH329, PGP:  This _is_ PGP-signed, isn't it?
jharris@widomaker.com | web:  http://jharris.cjb.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : /pipermail/attachments/20020517/ea55884b/attachment.bin
From Zlat0 at mail.ru  Mon May 20 20:14:01 2002
From: Zlat0 at mail.ru (Max V. Zinal)
Date: Tue Oct  7 21:29:05 2003
Subject: A modified version of GnuPG
Message-ID: <16924836432.20020518205413@mail.ru>

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

Hello everyone, have a nice time of day.

I've  made  some  changes to GnuPG 1.0.7, so now I have a version
built  under  MS  Windows with MS Visual C++ 6.0 compiler, linked
together  with zlib 1.1.4, and having support for *secure memory*
under  Windows.  I  did  my best to ensure that my changes do not
break any existing code under any ever-used platform.

I  think that this changes can be useful for project maintainers,
so they could include all this stuff into the future release.

I  would  like to know, are the project maintainers interested in
getting  my alterations, and if the answer is 'YES', how should I
send these alterations for them.

To show that my modified GPG works, I sign this message with it.
My public key is attached in a file.

- --
Best regards,
 Max                          mailto:zinal0@gibinsoft.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7a (x86-winnt)

iD8DBQE85ocj4scuxnLoWOARAnu0AJsGqiLj/iq6TOKevDG8vXsdI14aXwCfUdvz
ocu0KiQ5mnUBA5KU3ZI9T60=
=f9Ts
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MaxZinal.gpg
Type: application/octet-stream
Size: 1530 bytes
Desc: not available
Url : /pipermail/attachments/20020520/421465f2/MaxZinal.obj
From 21442 at gmx.net  Mon May 20 20:14:04 2002
From: 21442 at gmx.net (Jure)
Date: Tue Oct  7 21:29:05 2003
Subject: Symmetric encription in batch mode
Message-ID: <3CE6C692.F61D9523@gmx.net>

> On Thu Jan 03 2002; 22:00, Bernard wrote:
> 
> IMO, you can send the data with the passphrase at the begin like this:
> "stupid_passphrase\n"
> "raw/text data"
> 
> I used this style in early code of WinPT and it seems to work. It's
> only important that you add a '\n' to the end because gpg expected
> one line for the passphrase.
> 
> 
> There is another way you can choose for sending the passphrase down
> to gpg. With the --command-fd switch you can control all gpg input.
> In the case gpg needs a passphrase the --status-fd output is:
> [GNUPG:] GET_HIDDEN passphrase.enter
> and then you can send the data with the pipe. I know this way is
> more complicated because you need two additional pipes (status,
> command) but it's the tidiest way.

I came across exactly the same problem: how to pass the passphrase to
gnupg when doing symmetric encryption/decryption from a Java program. In
my program, I am trying to do something like this:

encrypt(InputStream plainText, OutputStream cipherText, String password);

(For example, suppose that a stream coming from one network connection has
to be encrypted and send to other network connection). To accomplish this,
I would like gpg.exe to read plainText from stdin and write output to
stdout. Using --passphrase-fd to specify passphrase presents two problems:

1. how to separate passphrase from data (prepending passphrase + '\n' is a
rather inelegant and possibly dangerous approach)

2. it simply doesn't work - although my program pipes the entire stream
(passphrase + '\n' + data) to gpg's input and receives something which
appears to be the gpg's header - that's where gpg hangs. I suppose this is
an issue of file descriptors (either due to a problem in OS, Java process
implementation, or a gpg's way of handling descriptors).

Realizing security issues, I am nevertheless convinced that the ease of
GnuPG reading the passphrase from an environment variable would greatly
outweight many problems that users (including me) who would like to embed
GnuPG in their own solutions, are confronted with, and are now forced to
invent problematic workarounds like the use of batch files.

So, how about supporting an environment variable (e.g. GPG_PASSPHRASE),
just like PGP does? Of course, a warning should be included wherever it
appears throughout documentation.

Forgive me if this has already been discussed - I did not find any trace
of it.

Jure


From emil at la.mine.nu  Mon May 20 20:14:06 2002
From: emil at la.mine.nu (Emil)
Date: Tue Oct  7 21:29:05 2003
Subject: --no-tty
Message-ID: <20020519095449.GA19764@localhost>

# gpg --version
gpg (GnuPG) 1.0.7

# gpg --no-tty --batch --cipher-algo IDEA -r emil -r emil -ea play.lst
gpg: emil: skipped: public key already present
gpg: this cipher algorithm is deprecated; please use a more standard one!

Isn't --no-tty supposed to mean _NO_ tty whatsoever ?

-- 
								Regards,
								Emil
--
"To be or not to be"	  -Shakespeare
"To do is to be"	  -Socrates
"To be is to do"	  -Sartre
"To be do be do"	  -Sinatra


From kokhong at post1.com  Mon May 20 20:14:07 2002
From: kokhong at post1.com (Soh Kok Hong)
Date: Tue Oct  7 21:29:05 2003
Subject: GnuPG for Win32
Message-ID: <3CE879E5.4060200@post1.com>

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

Dear all,

I have a 68-line diff file to patch the stock gnupg-1.0.7.tar.gz to
build a mingw32 executable in the standard cygwin environment.  It
mainly patches the configure scripts and one source file (rndw32.c).  I
would like to know if the gnupg maintainers are interested and to whom
can I email the patch to?

Please email to me directly as I am not on the list.


- --
*************************************************
Soh Kok Hong

kokhong@post1.com PGP Signature:
D18B FC65 2202 3E43 A2D3 90D2 7BCC ABD3 77CE CD1C
*************************************************
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE86Hnle8yr03fOzRwRAn8EAKDHTgi8snN8aBTtUGMzb1N92/h78gCg/esk
EWCm1xQ2nO7Nd3VsJ+HRn90=
=c2w+
-----END PGP SIGNATURE-----



From pgut001 at cs.auckland.ac.nz  Tue May 21 07:21:01 2002
From: pgut001 at cs.auckland.ac.nz (Peter Gutmann)
Date: Tue Oct  7 21:29:05 2003
Subject: A modified version of GnuPG
Message-ID: <200205210421.QAA220469@ruru.cs.auckland.ac.nz>

"Max V. Zinal" <Zlat0@mail.ru> writes:

>I've made some changes to GnuPG 1.0.7, so now I have a version built under MS
>Windows with MS Visual C++ 6.0 compiler, linked together with zlib 1.1.4, and
>having support for *secure memory* under Windows.

Could you explain what you mean by "secure memory"?  There are a variety of
interpretations possible, some erroneous (in general the term "secure memory"
is an oxymoron in an OS which has functions like VirtualProtect() and
ReadProcessMemory(), so a bit more detail would be useful).

Peter.


From wk at gnupg.org  Tue May 21 10:16:01 2002
From: wk at gnupg.org (Werner Koch)
Date: Tue Oct  7 21:29:05 2003
Subject: --no-tty
In-Reply-To: <20020519095449.GA19764@localhost> (Emil's message of "Sun, 19
 May 2002 05:54:49 -0400")
References: <20020519095449.GA19764@localhost>
Message-ID: <87u1p2rmrh.fsf@alberti.gnupg.de>

On Sun, 19 May 2002 05:54:49 -0400, Emil  said:

> Isn't --no-tty supposed to mean _NO_ tty whatsoever ?

No, it does only make sure never to write to the tty directly (i.e. it
does not open /dev/tty).  The tty may be required to ask for a
passphrase even when stderr has been redirected.  Avoiding all
informational output is done by redirecting stderr to /dev/zero

  Werner



From wk at gnupg.org  Tue May 21 10:22:01 2002
From: wk at gnupg.org (Werner Koch)
Date: Tue Oct  7 21:29:05 2003
Subject: GnuPG for Win32
In-Reply-To: <3CE879E5.4060200@post1.com> (Soh Kok Hong's message of "Mon,
 20 May 2002 12:21:57 +0800")
References: <3CE879E5.4060200@post1.com>
Message-ID: <87offarmid.fsf@alberti.gnupg.de>

On Mon, 20 May 2002 12:21:57 +0800, Soh Kok Hong said:

> I have a 68-line diff file to patch the stock gnupg-1.0.7.tar.gz to
> build a mingw32 executable in the standard cygwin environment.  It

Thanks but it does not make sense to use this because GnuPG builds
fine as a native Windows program.  The Cygwin32 version may lead not
serious interoperabilty problems when used by other programs expecting
a plain Windows binary.

Yes, I know there is some stuff in GnuPG to allow building under
Cygwin but this already makes the code more complex and error prone,
so it is not really maintained anymore.

  Werner



From dbely at mail.ru  Tue May 21 10:54:01 2002
From: dbely at mail.ru (Dmitry Bely)
Date: Tue Oct  7 21:29:05 2003
Subject: GnuPG for Win32
In-Reply-To: <87offarmid.fsf@alberti.gnupg.de> (Werner Koch's message of
 "Tue, 21 May 2002 09:24:58 +0200")
References: <3CE879E5.4060200@post1.com> <87offarmid.fsf@alberti.gnupg.de>
Message-ID: <ptzqaqit.fsf@mail.ru>

Werner Koch <wk@gnupg.org> writes:

>> I have a 68-line diff file to patch the stock gnupg-1.0.7.tar.gz to
>> build a mingw32 executable in the standard cygwin environment.  It
>
> Thanks but it does not make sense to use this because GnuPG builds
> fine as a native Windows program.  The Cygwin32 version may lead not
> serious interoperabilty problems when used by other programs expecting
> a plain Windows binary.

Where have you seen a Cygwin32 version? He was talking about the patches
that would let building Mingw32 version with the native Win32 tools
(Mingw32 compiler is included into Cygwin distribution). The fact that
Mingw version of GnuPG cannot be build under Windows out-of-the-box (and so
Windows users cannot participate in its debugging/development) looks
strange to me if not to say more...

Hope to hear from you soon,
Dmitry




From avbidder at fortytwo.ch  Tue May 21 11:24:02 2002
From: avbidder at fortytwo.ch (Adrian 'Dagurashibanipal' von Bidder)
Date: Tue Oct  7 21:29:05 2003
Subject: secure sign & encrypt
In-Reply-To: <200205171138.51248.rjhansen@inav.net>
References: <1021648640.7790.33.camel@atlas> 
	<200205171138.51248.rjhansen@inav.net>
Message-ID: <1021969508.14022.39.camel@atlas>

On Fri, 2002-05-17 at 18:38, Robert J. Hansen wrote:

> Davis' `exploit' (in 1.1) basically boils down to this: if you can't trust 
> the person you're talking to, then the person you're talking to can use 
> your words in ways you don't like.  Is that a problem?  Sure.  But it's a 
> social problem, not a technological one.  It demands social solutions, not 
> different cryptographic standards.

Agreed that the exploit is not really technological. The programs do
exactly as told. From the senders point of view I agree fully to what
you say. BUT if somebody receives an encrypted message he will almost
always automatically assume secure end to end communication - which may
not be the case. The open question is basically if the user should be
educated that the software does not work the way they think (hard, I
think), or if the software should be modified to match the users
(reasonable, imho) expectations.

-- 
secure email with gpg                 avbidder@fortytwo.ch: key id
0x92082481
                                      avbidder@acter.ch:    key id
0x5E4B731F

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : /pipermail/attachments/20020521/ebdca9e8/attachment.bin
From m-lesser at better-com.de  Tue May 21 16:59:02 2002
From: m-lesser at better-com.de (Martin Lesser)
Date: Tue Oct  7 21:29:05 2003
Subject: Error or feature in g10.c?
Message-ID: <87ptzpsisz.fsf@nb-acer.better-com.de>

After updating from 1.0.6 to 1.0.7 we ran into problems with an app
which uses --run-as-shm-coprocess (gabber, see also
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=146740 )

I know that use of shm-routines in gnupg is deprecated and should be
replaced with --command-fd.

Since rev. 1.129.2.82 of g10.c there's an
  #undef USE_SHM_COPROCESSING
which in the current version is additionally commented with "huh ?"

What's the reason for inserting this #undef (especially at this point)?
In the archives I could not find any hint.

Commenting out this line solved the problem with gabber but I'm not sure
wether this is correct. IMO it is possible that other apps also make use
of the shm-routines. If so they could run into problems too.

Martin


From wk at gnupg.org  Tue May 21 19:50:01 2002
From: wk at gnupg.org (Werner Koch)
Date: Tue Oct  7 21:29:05 2003
Subject: Error or feature in g10.c?
In-Reply-To: <87ptzpsisz.fsf@nb-acer.better-com.de> (Martin Lesser's message
 of "21 May 2002 15:59:40 +0200")
References: <87ptzpsisz.fsf@nb-acer.better-com.de>
Message-ID: <87d6vpqw67.fsf@alberti.gnupg.de>

On 21 May 2002 15:59:40 +0200, Martin Lesser said:

> What's the reason for inserting this #undef (especially at this point)?
> In the archives I could not find any hint.

Fixed:

  * g10.c (main): Removed the undef of USE_SHM_COPROCESSING which
  was erroneously introduced on 2002-01-09.

> Commenting out this line solved the problem with gabber but I'm not sure
> wether this is correct. IMO it is possible that other apps also make use

It is.

Thanks,

  Werner



From Zlat0 at mail.ru  Tue May 21 20:40:01 2002
From: Zlat0 at mail.ru (Max V. Zinal)
Date: Tue Oct  7 21:29:05 2003
Subject: A modified version of GnuPG
In-Reply-To: <200205210421.QAA220469@ruru.cs.auckland.ac.nz>
References: <200205210421.QAA220469@ruru.cs.auckland.ac.nz>
Message-ID: <1387186383.20020521213928@mail.ru>

Tuesday, May 21, 2002, 8:21:18 AM, Peter Gutmann wrote:

PG> Could you explain what you mean by "secure memory"?  There are a variety of
PG> interpretations possible, some erroneous (in general the term "secure memory"
PG> is an oxymoron in an OS which has functions like VirtualProtect() and
PG> ReadProcessMemory(), so a bit more detail would be useful).

When I said "secure memory" I was going to say "VirtualLock under
Windows  NT/2000/XP",  which keeps you absolutely safe unless you
have  a  Terminal  Server  with  an  evil-minded admin, or remote
desktop    connection    with    'Debug' privileges.

As  you  know,  most  of  old  and modern OSes have no protection
against  a  person that has administrative rights. Linux, Windows
or  something  else  -  'a  good admin means a long life'. Any OS
which  allows a programmer to use debug facility may be unsecure.
Of  course,  if  we  are  talking about Win9x/ME (which should be
called  'Mustdie  Edition',  I  think), even with VirtualLock you
cannot be absolutely shure.

I have e-mailed my modifications to
        Timo Schulz <twoaday@freakmail.de>
who said he would like to receive them.

Sorry for unexcellent English.

-- 
Best regards,
 Max V. Zinal



From wk at gnupg.org  Wed May 22 10:04:02 2002
From: wk at gnupg.org (Werner Koch)
Date: Tue Oct  7 21:29:05 2003
Subject: A modified version of GnuPG
In-Reply-To: <1387186383.20020521213928@mail.ru> ("Max V. Zinal"'s message
 of "Tue, 21 May 2002 21:39:28 +0400")
References: <200205210421.QAA220469@ruru.cs.auckland.ac.nz>
	<1387186383.20020521213928@mail.ru>
Message-ID: <878z6cpso2.fsf@alberti.gnupg.de>

On Tue, 21 May 2002 21:39:28 +0400, Max V Zinal said:

> When I said "secure memory" I was going to say "VirtualLock under
> Windows  NT/2000/XP",  which keeps you absolutely safe unless you

I guess you didn't read Peter's papers on this.  VirtualLock is not
suitable for this.  The only way to protect memory from swapping is by
allocating it with the device helper functions:  An ISR may need
memory buffers and these buffers should never be subject to any paging
- the pager may need the service of that ISR - this is the reason why
you are able to allocate non-pageable memory for a device driver.

When GnuPG talks about "secure memory" it actually means "non-pageable
memory".  There can't be any protection against an almighty
admin/root/superuser.

  Werner



From avbidder at fortytwo.ch  Wed May 22 10:50:02 2002
From: avbidder at fortytwo.ch (Adrian 'Dagurashibanipal' von Bidder)
Date: Tue Oct  7 21:29:06 2003
Subject: secure sign & encrypt
In-Reply-To: <200205211132.09336.rjhansen@inav.net>
References: <1021648640.7790.33.camel@atlas>
	<200205171138.51248.rjhansen@inav.net> <1021969508.14022.39.camel@atlas> 
	<200205211132.09336.rjhansen@inav.net>
Message-ID: <1022053889.12048.32.camel@atlas>

On Tue, 2002-05-21 at 18:32, Robert J. Hansen wrote:
> > not be the case. The open question is basically if the user should be
> > educated that the software does not work the way they think (hard, I
> > think), or if the software should be modified to match the users
> > (reasonable, imho) expectations.
> 
> "To every sociological problem there exists a technological solution which 
> is cheap, easy, and wrong."
> 

Why do locks exist, then? The existence of thieves is a purely
sociological problem, after all, and so one should not try to solve it
with technological means.

I agree it'd be breaking (I'd call it extending, but call it what you
want). But I argue that it's just automating a task the user presently
has to do manually.

Currently, to get secure, authenticated end-to-end encryption with gpg,
the sender has to sign/encrypt/sign, which presently requires at least 2
gpg invocations, and the recipient has to manually verify that the inner
and the outer signature match. 

What I propose does basically just automate this task. It might do so by
literally sign/encrypt/sign, or by encrypt/sign[intended ecryption
keys|msg] (cf my proposal) - it's not the issue which of the two is
happening, though I believe the latter to be more elegant. 

And I want to stress again that having an end-to-end encrypted channel
is imho a fairly basic requirement of a cryptosystem and is what the
average user is probably expecting to have if he is at the receiving end
of an encrypted channel.

cheers
-- vbi

-- 
secure email with gpg                 avbidder@fortytwo.ch: key id
0x92082481
                                      avbidder@acter.ch:    key id
0x5E4B731F

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : /pipermail/attachments/20020522/777bf6c8/attachment.bin
From roconnor at Math.Berkeley.EDU  Wed May 22 11:03:01 2002
From: roconnor at Math.Berkeley.EDU (Russell O'Connor)
Date: Tue Oct  7 21:29:06 2003
Subject: strncasecmp
Message-ID: <Pine.SOL.4.33.0205220100420.17494-100000@blue3.math.berkeley.edu>

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

I was building Gnupg 1.0.7 for OS/2 and I had to manually add strncasecmp
to util/strutil.c

This probably should be added to the source files, along with the
appropriate changes to configure.

- -- 
Russell O'Connor                           roconnor@math.berkeley.edu
           <http://www.math.berkeley.edu/~roconnor/>
``Later generations will regard set theory as a disease from which one
has recovered.'' -- Poincare
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (SunOS)
Comment: For info see http://www.gnupg.org

iD8DBQE861EKuZUa0PWVyWQRAlAwAJ9o5ilHoWGp6xdYXnEZy3CqRRPMpQCfREAn
HWL5wUGr+X+QK4zSe1lucts=
=UqVR
-----END PGP SIGNATURE-----



From apm35 at student.open.ac.uk  Wed May 22 11:32:01 2002
From: apm35 at student.open.ac.uk (Andrew Marlow)
Date: Tue Oct  7 21:29:06 2003
Subject: strncasecmp
In-Reply-To: <Pine.SOL.4.33.0205220100420.17494-100000@blue3.math.berkeley.edu>
References: <Pine.SOL.4.33.0205220100420.17494-100000@blue3.math.berkeley.edu>
Message-ID: <fc.004c540101aa85a33b9aca0013090653.1aa85d3@oufcnt2.open.ac.uk>

roconnor@math.berkeley.edu writes:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>I was building Gnupg 1.0.7 for OS/2 and I had to manually add strncasecmp
>to util/strutil.c
>
>This probably should be added to the source files, along with the
>appropriate changes to configure.

I disagree.
Some environments have strncasecmp and others don't. I usually define my
own version of strncasecmp and the implementation differs from environment
to environment. Where I can implement it in terms of strncasecmp I do so,
otherwise I hand-code it. No direct calls to strncasecmp appear in the
code since it is a portability issue.

Regards,

Andrew M.



From sbellon at sbellon.de  Wed May 22 11:33:01 2002
From: sbellon at sbellon.de (Stefan Bellon)
Date: Tue Oct  7 21:29:06 2003
Subject: strncasecmp
In-Reply-To: <Pine.SOL.4.33.0205220100420.17494-100000@blue3.math.berkeley.edu>
References: <Pine.SOL.4.33.0205220100420.17494-100000@blue3.math.berkeley.edu>
Message-ID: <4b3a87c92bsbellon@sbellon.de>

Russell O'Connor wrote:
> I was building Gnupg 1.0.7 for OS/2 and I had to manually add
> strncasecmp to util/strutil.c

I think I fixed that two days after the 1.0.7 release:

2002-05-10  Stefan Bellon  <sbellon@sbellon.de>

        * g10.c, hkp.c, keyedit.c, keyserver.c: Replaced all occurrances
        of strcasecmp with ascii_strcasecmp and all occurrances of
        strncasecmp with ascii_memcasecmp.

So, neither strcasecmp nor strncasecmp is necessary anymore. Perhaps
you could try with a CVS build again?

Greetings,

Stefan.

-- 
 Stefan Bellon * <mailto:sbellon@sbellon.de> * <http://www.sbellon.de/>
 PGP 2 and OpenPGP keys available from my home page

 We have commited to quickly disseminate high-quality leadership skills
 and collaboratively restore low-risk high-yield meta-services to meet
 our customers needs.


From wk at gnupg.org  Wed May 22 11:36:01 2002
From: wk at gnupg.org (Werner Koch)
Date: Tue Oct  7 21:29:06 2003
Subject: strncasecmp
In-Reply-To: <Pine.SOL.4.33.0205220100420.17494-100000@blue3.math.berkeley.edu> ("Russell
 O'Connor"'s message of "Wed, 22 May 2002 01:04:22 -0700 (PDT)")
References: <Pine.SOL.4.33.0205220100420.17494-100000@blue3.math.berkeley.edu>
Message-ID: <87znyso9to.fsf@alberti.gnupg.de>

On Wed, 22 May 2002 01:04:22 -0700 (PDT), Russell O'Connor said:

> I was building Gnupg 1.0.7 for OS/2 and I had to manually add strncasecmp
> to util/strutil.c

How did you implement the random number generator?




From wk at gnupg.org  Wed May 22 12:20:01 2002
From: wk at gnupg.org (Werner Koch)
Date: Tue Oct  7 21:29:06 2003
Subject: strncasecmp
In-Reply-To: <4b3a87c92bsbellon@sbellon.de> (Stefan Bellon's message of
 "Wed, 22 May 2002 10:34:05 +0200")
References: <Pine.SOL.4.33.0205220100420.17494-100000@blue3.math.berkeley.edu>
	<4b3a87c92bsbellon@sbellon.de>
Message-ID: <87n0uso7ug.fsf@alberti.gnupg.de>

On Wed, 22 May 2002 10:34:05 +0200, Stefan Bellon said:

> So, neither strcasecmp nor strncasecmp is necessary anymore. Perhaps
> you could try with a CVS build again?

Well, a check and a replacement for strncasecmp is needed if we use it
and there are some place where strcasecmp should be used instead of
the ascii versions: Those where you actually compare against localized
strings.  I found some places where it was rightfully used but hidden
by stricmp which is just a macro to strcasecmp.  I fixed all of them
and added a strncasecmp repalcement function.

  Werner



From wk at gnupg.org  Wed May 22 12:20:03 2002
From: wk at gnupg.org (Werner Koch)
Date: Tue Oct  7 21:29:06 2003
Subject: strncasecmp
In-Reply-To: <fc.004c540101aa85a33b9aca0013090653.1aa85d3@oufcnt2.open.ac.uk> (Andrew
 Marlow's message of "Wed, 22 May 2002 09:33:01 +0100")
References: <Pine.SOL.4.33.0205220100420.17494-100000@blue3.math.berkeley.edu>
	<fc.004c540101aa85a33b9aca0013090653.1aa85d3@oufcnt2.open.ac.uk>
Message-ID: <87it5go7sv.fsf@alberti.gnupg.de>

On Wed, 22 May 2002 09:33:01 +0100, Andrew Marlow said:

> Some environments have strncasecmp and others don't. I usually define my
> own version of strncasecmp and the implementation differs from environment

And that is why you should have autoconf test for it and provide a
replacement.  I added the missing tests.
 
  Werner



From rjhansen at inav.net  Wed May 22 16:31:01 2002
From: rjhansen at inav.net (Robert J. Hansen)
Date: Tue Oct  7 21:29:06 2003
Subject: secure sign & encrypt
In-Reply-To: <1022053889.12048.32.camel@atlas>
References: <1021648640.7790.33.camel@atlas>
	<200205171138.51248.rjhansen@inav.net> <1021969508.14022.39.camel@atlas> 
	<200205211132.09336.rjhansen@inav.net>  <1022053889.12048.32.camel@atlas>
Message-ID: <1022074192.9093.11.camel@numbers>

> Why do locks exist, then? The existence of thieves is a purely

Mostly to make homeowners feel safe.  Locks don't exist to keep burglars
out.  My parents lock their front door religiously every single night,
and have a cognitive dissonance in place regarding the large bay window
by the front door.  When I go home to visit, I sometimes like to make a
demonstration of just how silly the front door's lock is by picking
it--lockpicking isn't a hard skill to pick up, incidentally; it just
requires a little devotion.  The reaction I get from Mom and Dad is
always the same: "I wish you wouldn't do that."  Not, "Oh, dear, that
lock's insecure, we need to change it."  My parents are very typical
people in this regard.

You're right; burglary is a sociological problem, and one shouldn't try
to solve it with technological means.  Aggressive law-enforcement, which
is a sociological measure, has a much better track record than locks,
which are purely technological ones.

> I agree it'd be breaking (I'd call it extending, but call it what you
> want). But I argue that it's just automating a task the user presently
> has to do manually.

It's breaking a standard for no effective increase in security.  If the
person you're communicating with is untrustworthy, they can still do all
sorts of things to you which are a thousand times worse than this
(fairly trivial) attack you're worried about.

> Currently, to get secure, authenticated end-to-end encryption with gpg,
> the sender has to sign/encrypt/sign, which presently requires at least 2
> gpg invocations, and the recipient has to manually verify that the inner
> and the outer signature match. 

No: only for people whose threat models include a paranoiac distrust of
their recipients have to worry about this.  My threat model doesn't
incorporate that, and thus, I can get (just to be buzzword-compliant)
"secure, authenticated end-to-end encryption with GPG" just by signing
and encrypting.

Many other people share my threat model, and changing GPG's behavior
would mean GPG would no longer well-represent our threat model.  

> What I propose does basically just automate this task. It might do so by

... and breaks RFC.





From avbidder at fortytwo.ch  Wed May 22 18:44:02 2002
From: avbidder at fortytwo.ch (Adrian 'Dagurashibanipal' von Bidder)
Date: Tue Oct  7 21:29:06 2003
Subject: secure sign & encrypt
In-Reply-To: <1022074192.9093.11.camel@numbers>
References: <1021648640.7790.33.camel@atlas>
	<200205171138.51248.rjhansen@inav.net> <1021969508.14022.39.camel@atlas> 
	<200205211132.09336.rjhansen@inav.net>  <1022053889.12048.32.camel@atlas> 
	<1022074192.9093.11.camel@numbers>
Message-ID: <1022082280.17135.125.camel@atlas>

On Wed, 2002-05-22 at 15:29, Robert J. Hansen wrote:
> > Why do locks exist, then? The existence of thieves is a purely

> > Currently, to get secure, authenticated end-to-end encryption with gpg,
> > the sender has to sign/encrypt/sign, which presently requires at least 2
> > gpg invocations, and the recipient has to manually verify that the inner
> > and the outer signature match. 
> 
> No: only for people whose threat models include a paranoiac distrust of
> their recipients have to worry about this.  My threat model doesn't
> incorporate that, and thus, I can get (just to be buzzword-compliant)
> "secure, authenticated end-to-end encryption with GPG" just by signing
> and encrypting.

signing and encrypting is a secure end-to-end channel from the *senders*
point of view. the problem is that for a potential *recipient* of an
encrypted & signed msg it is impossible to know much about the potential
prior recipient of the message (the one that encrypted and forwarded
it).

In other words, your threat model says that you do not only trust the
sender (signer) of a message, but you trust all people who may get
signed messages from that sender. (Or, alternatively, you as the
receiver of a confidential message do not care to know if it really was
sent encrypted or not.)

cheers
-- vbi


-- 
secure email with gpg            avbidder@fortytwo.ch: key id 0x92082481
                                 avbidder@acter.ch:    key id 0x5E4B731F

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : /pipermail/attachments/20020522/f900a81f/attachment.bin
From rjhansen at inav.net  Wed May 22 19:54:01 2002
From: rjhansen at inav.net (Robert J. Hansen)
Date: Tue Oct  7 21:29:06 2003
Subject: secure sign & encrypt
In-Reply-To: <1022082280.17135.125.camel@atlas>
Message-ID: <Pine.LNX.4.44L0.0205221140200.31437-100000@soli.inav.net>

> In other words, your threat model says that you do not only trust the
> sender (signer) of a message, but you trust all people who may get
> signed messages from that sender. (Or, alternatively, you as the

<testy>
No.  Please don't make assumptions about my threat model, especially ones 
which are subtly and seriously wrong.
</testy>

The `exploit' you're concerned about isn't an exploit at all, except 
insofar as to say the weakest point of any cryptosystem is in the 
ignorance of its users.  Even in the worst-case scenario, all you can say 
is that it only affects people who don't bother to learn the cryptosystem 
they're using.  And there is absolutely nothing which can protect people 
from their own ignorance.  Trying to do so is a fool's errand.

Although I'm not a core GPG hacker (my work is limited to a C++ binding 
for GPGME) and thus my opinion has just about as much weight as your 
average Slashdot reader's, I would be extremely displeased to see GnuPG 
chase after an ephemeral exploit and, in the process, break RFC.




From Weimer at CERT.Uni-Stuttgart.DE  Wed May 22 21:21:01 2002
From: Weimer at CERT.Uni-Stuttgart.DE (Florian Weimer)
Date: Tue Oct  7 21:29:06 2003
Subject: A modified version of GnuPG
In-Reply-To: <1387186383.20020521213928@mail.ru> ("Max V. Zinal"'s message
 of "Tue, 21 May 2002 21:39:28 +0400")
References: <200205210421.QAA220469@ruru.cs.auckland.ac.nz>
	<1387186383.20020521213928@mail.ru>
Message-ID: <87adqturzu.fsf@CERT.Uni-Stuttgart.DE>

"Max V. Zinal" <Zlat0@mail.ru> writes:

> When I said "secure memory" I was going to say "VirtualLock under
> Windows  NT/2000/XP",  which keeps you absolutely safe unless you
> have  a  Terminal  Server  with  an  evil-minded admin, or remote
> desktop    connection    with    'Debug' privileges.

Previous information about VirtualLock on Win32 suggests that it does
not prevent memory from being paged to disk, but only from being paged
to disk and then discarded.

In fact, the MSDN documentation available online carefully avoids the
claim that the specified memory region is never written to disk.

-- 
Florian Weimer 	                  Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898


From kokhong at post1.com  Wed May 22 21:21:04 2002
From: kokhong at post1.com (Soh Kok Hong)
Date: Tue Oct  7 21:29:06 2003
Subject: GnuPG for Win32
References: <3CE879E5.4060200@post1.com>
Message-ID: <3CEB00B2.3090208@post1.com>

Dear all,

The patch that I am suggesting builds a Win32 executable (ie. no cygwin
DLLs needed) using the CYGWIN's mingw32 tools.  I did not use the mingw32-cpd
stuff because it is rather old and does not include winsock2 - winsock2 is
required in building gnupg for Win32.

You need to run autoconf (by running "scripts/missing --run autoconf") to
rebuild the configure script first.

The changes are as follows:

1. acinclude.m4 & aclocal.m4
- patch to set ac_cv_sys_symbol_underscore to yes for mingw32 target

2. configure.ac
- Added AC_PROG_RANLIB - this was missing.  In real unix targets,
this variable is added because of AM_GNU_GETTEXT which performs
lots of tests - one of which is to set AC_PROG_RANLIB.  In mingw32
target, this did not get set because try_gettext set to "no", hence
AC_PROGR_RANLIB never gets set.

- added a check for presence of strcasecmp function.  Again, the reason
this did not get checked is because of the AM_GNU_GETTEXT problem.

3. cipher/rndw32.c
- forced include of winioctl.h.  This is needed to include the
DISK_PERFORMANCE structure definition.


Soh Kok Hong wrote:
> Dear all,
> 
> I have a 68-line diff file to patch the stock gnupg-1.0.7.tar.gz to
> build a mingw32 executable in the standard cygwin environment.  It
> mainly patches the configure scripts and one source file (rndw32.c).  I
> would like to know if the gnupg maintainers are interested and to whom
> can I email the patch to?
> 
> Please email to me directly as I am not on the list.
> 
> 
> --
> *************************************************
> Soh Kok Hong
> 
> kokhong@post1.com PGP Signature:
> D18B FC65 2202 3E43 A2D3 90D2 7BCC ABD3 77CE CD1C
> *************************************************


============ patch starts here =================

diff -Naur gnupg-1.0.7.orig/acinclude.m4 gnupg-1.0.7/acinclude.m4
--- gnupg-1.0.7.orig/acinclude.m4	2001-12-20 01:16:30.000000000 +0800
+++ gnupg-1.0.7/acinclude.m4	2002-05-18 16:03:16.000000000 +0800
@@ -661,7 +661,7 @@
  AC_DEFUN(GNUPG_SYS_SYMBOL_UNDERSCORE,
  [tmp_do_check="no"
  case "${target}" in
-    i386-emx-os2 | i[3456]86-pc-os2*emx | i386-pc-msdosdjgpp | *-*-cygwin)
+    i386-emx-os2 | i[3456]86-pc-os2*emx | i386-pc-msdosdjgpp | *-*-cygwin | *-*-mingw32 )
          ac_cv_sys_symbol_underscore=yes
          ;;
      *)
diff -Naur gnupg-1.0.7.orig/aclocal.m4 gnupg-1.0.7/aclocal.m4
--- gnupg-1.0.7.orig/aclocal.m4	2002-04-29 22:58:48.000000000 +0800
+++ gnupg-1.0.7/aclocal.m4	2002-05-18 16:03:18.000000000 +0800
@@ -665,7 +665,7 @@
  AC_DEFUN(GNUPG_SYS_SYMBOL_UNDERSCORE,
  [tmp_do_check="no"
  case "${target}" in
-    i386-emx-os2 | i[3456]86-pc-os2*emx | i386-pc-msdosdjgpp | *-*-cygwin)
+    i386-emx-os2 | i[3456]86-pc-os2*emx | i386-pc-msdosdjgpp | *-*-cygwin | *-*-mingw32 )
          ac_cv_sys_symbol_underscore=yes
          ;;
      *)
diff -Naur gnupg-1.0.7.orig/cipher/rndw32.c gnupg-1.0.7/cipher/rndw32.c
--- gnupg-1.0.7.orig/cipher/rndw32.c	2001-12-20 02:05:04.000000000 +0800
+++ gnupg-1.0.7/cipher/rndw32.c	2002-05-18 16:03:18.000000000 +0800
@@ -67,9 +67,7 @@
  #include <string.h>

  #include <windows.h>
-#ifdef __CYGWIN32__
-# include <winioctl.h>
-#endif
+#include <winioctl.h>


  #include "types.h"
diff -Naur gnupg-1.0.7.orig/configure.ac gnupg-1.0.7/configure.ac
--- gnupg-1.0.7.orig/configure.ac	2002-04-29 22:56:08.000000000 +0800
+++ gnupg-1.0.7/configure.ac	2002-05-18 16:03:20.000000000 +0800
@@ -184,6 +184,7 @@
  AM_MISSING_PROG(MAKEINFO, makeinfo, $missing_dir)
  AC_PROG_CC
  AC_PROG_CPP
+AC_PROG_RANLIB
  AC_PATH_PROG(PERL,"perl")
  AC_ISC_POSIX
  AC_SYS_LARGEFILE
@@ -482,7 +483,7 @@
  AC_FUNC_FSEEKO
  AC_FUNC_VPRINTF
  AC_FUNC_FORK
-AC_CHECK_FUNCS(strerror stpcpy strsep strlwr stricmp tcgetattr strtoul mmap)
+AC_CHECK_FUNCS(strerror stpcpy strsep strlwr stricmp tcgetattr strtoul strcasecmp mmap)
  AC_CHECK_FUNCS(memmove gettimeofday getrusage setrlimit clock_gettime)
  AC_CHECK_FUNCS(memicmp atexit raise getpagesize strftime nl_langinfo setlocale)
  AC_CHECK_FUNCS(waitpid wait4 sigaction sigprocmask rand pipe stat)
diff -Naur gnupg-1.0.7.orig/scripts/build-mingw32 gnupg-1.0.7/scripts/build-mingw32
--- gnupg-1.0.7.orig/scripts/build-mingw32	1970-01-01 08:00:00.000000000 +0800
+++ gnupg-1.0.7/scripts/build-mingw32	2002-05-18 16:06:06.000000000 +0800
@@ -0,0 +1,6 @@
+#!/bin/sh
+
+export CC="gcc -mno-cygwin -mthreads"
+
+./configure --target=i386-pc-mingw32
+




From disastry at saiknes.lv  Wed May 22 21:21:06 2002
From: disastry at saiknes.lv (disastry@saiknes.lv)
Date: Tue Oct  7 21:29:06 2003
Subject: RSA sign+encrypt (with subkey) key generation
Message-ID: <3CEB7600.5CAFAF74@saiknes.lv>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

hello

here is the patch that allows to generate RSA sign+encrypt (with subkey) keys
in one step (like DSA/Elgamal keys) - no need to go to --key-edit to add subkey

it also allows to generate RSA/Elgamal and DSA/RSA keys in one step.

this patch is for 1.0.7a (cvs version)

patch also available at
http://disastry.dhs.org/pgp/gpg/gnupg-1.0.7a-keygen.diff

__
Disastry  http://disastry.dhs.org/
-----BEGIN PGP SIGNATURE-----
Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1

iQA/AwUBPOtZkDBaTVEuJQxkEQNPqACeI4JHKHqW2/bz/yhL4Si7t7TQesoAoIn7
sjEvzUyMrauX8ZRvEa6vWfXk
=Y/XQ
-----END PGP SIGNATURE-----
-------------- next part --------------
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

This patch enables gpg version 1.0.7a to generate RSA sign + RSA encrypt keys
and RSA sign + ElGamal encrypt and DSA + RSA encrypt keys.


Copyright 2001 Free Software Foundation, Inc.

This patch is free software; you can use it, redistribute it
and/or modify it under the terms of the GNU General Public
License as published by the Free Software Foundation; either
version 2 of the License, or (at your option) any later version.


--- gnupg/g10/keygen.c	Thu May 16 05:35:54 2002
+++ gnupg107a/g10/keygen.c	Wed May 22 12:19:21 2002
@@ -849,8 +849,14 @@
     tty_printf(    _("   (%d) RSA (sign only)\n"), 5 );
     if (addmode)
         tty_printf(    _("   (%d) RSA (encrypt only)\n"), 6 );
+    if (!addmode)
+      tty_printf(    _("   (%d) RSA (sign and encrypt (with subkey))\n"), 7 );
     if (opt.expert)
-      tty_printf(    _("   (%d) RSA (sign and encrypt)\n"), 7 );
+      tty_printf(    _("   (%d) RSA (sign and encrypt (single key))\n"), 8 );
+    if (!addmode && opt.expert) { /* add odd keys too... */
+      tty_printf(    _("   (%d) RSA (sign) and ElGamal(encrypt)\n"), 9 );
+      tty_printf(    _("   (%d) DSA (sign) and RSA (encrypt)\n"), 10 );
+    }
 
     for(;;) {
 	answer = cpr_get("keygen.algo",_("Your selection? "));
@@ -858,10 +864,20 @@
 	algo = *answer? atoi(answer): 1;
 	m_free(answer);
 	if( algo == 1 && !addmode ) {
-	    algo = 0;	/* create both keys */
+	    algo = PUBKEY_ALGO_DSA | (PUBKEY_ALGO_ELGAMAL_E << 8);	/* create both keys */
+	    break;
+	}
+	else if( algo == 10 && !addmode && opt.expert ) {
+	    algo = PUBKEY_ALGO_DSA | (PUBKEY_ALGO_RSA << 8);	/* create both keys */
+            *r_usage = PUBKEY_USAGE_ENC << 8;
 	    break;
 	}
-	else if( algo == 7 && opt.expert ) {
+	else if( algo == 9 && !addmode && opt.expert ) {
+	    algo = PUBKEY_ALGO_RSA | (PUBKEY_ALGO_ELGAMAL_E << 8);	/* create both keys */
+            *r_usage = PUBKEY_USAGE_SIG;
+	    break;
+	}
+	else if( algo == 8 && opt.expert ) {
 	    if (cpr_get_answer_is_yes ("keygen.algo.rsa_se",_(
 		"The use of this algorithm is deprecated - create anyway? "))){
               algo = PUBKEY_ALGO_RSA;
@@ -869,6 +885,11 @@
               break;
             }
 	}
+	else if( algo == 7 && !addmode ) {
+	    algo = PUBKEY_ALGO_RSA | (PUBKEY_ALGO_RSA << 8);	/* create both keys */
+            *r_usage = PUBKEY_USAGE_SIG | (PUBKEY_USAGE_ENC << 8);
+	    break;
+	}
 	else if( algo == 6 && addmode ) {
 	    algo = PUBKEY_ALGO_RSA;
             *r_usage = PUBKEY_USAGE_ENC;
@@ -1855,7 +1876,7 @@
 void
 generate_keypair( const char *fname )
 {
-    unsigned int nbits;
+    unsigned int nbits = 0;
     char *uid = NULL;
     DEK *dek;
     STRING2KEY *s2k;
@@ -1875,26 +1896,52 @@
     }
 
     algo = ask_algo( 0, &use );
-    if( !algo ) { /* default: DSA with ElG subkey of the specified size */
+    if( algo >> 8 ) { /* default: DSA with ElG subkey of the specified size */
 	both = 1;
 	r = m_alloc_clear( sizeof *r + 20 );
 	r->key = pKEYTYPE;
-	sprintf( r->u.value, "%d", PUBKEY_ALGO_DSA );
+	sprintf( r->u.value, "%d", algo & 0xff );
 	r->next = para;
 	para = r;
-	tty_printf(_("DSA keypair will have 1024 bits.\n"));
 	r = m_alloc_clear( sizeof *r + 20 );
 	r->key = pKEYLENGTH;
-	strcpy( r->u.value, "1024" );
+	if ((algo & 0xff) == PUBKEY_ALGO_DSA) {
+	    tty_printf(_("DSA keypair will have 1024 bits.\n"));
+	    strcpy( r->u.value, "1024" );
+	} else {
+	    nbits = ask_keysize( algo && 0xff );
+	    sprintf( r->u.value, "%u", nbits);
+	}
 	r->next = para;
 	para = r;
 
-	algo = PUBKEY_ALGO_ELGAMAL_E;
+        if (use & 0xff) {
+            r = m_alloc_clear( sizeof *r + 20 );
+            r->key = pKEYUSAGE;
+            sprintf( r->u.value, "%s%s",
+                     (use & PUBKEY_USAGE_SIG)? "sign ":"",
+                     (use & PUBKEY_USAGE_ENC)? "encrypt ":"" );
+            r->next = para;
+            para = r;
+        }
+
+	algo = algo >> 8;
+	use = use >> 8;
 	r = m_alloc_clear( sizeof *r + 20 );
 	r->key = pSUBKEYTYPE;
 	sprintf( r->u.value, "%d", algo );
 	r->next = para;
 	para = r;
+
+        if (use) {
+            r = m_alloc_clear( sizeof *r + 20 );
+            r->key = pSUBKEYUSAGE;
+            sprintf( r->u.value, "%s%s",
+                     (use & PUBKEY_USAGE_SIG)? "sign ":"",
+                     (use & PUBKEY_USAGE_ENC)? "encrypt ":"" );
+            r->next = para;
+            para = r;
+        }
     }
     else {
 	r = m_alloc_clear( sizeof *r + 20 );
@@ -1915,7 +1962,8 @@
 
     }
 
-    nbits = ask_keysize( algo );
+    if ( !nbits )
+	nbits = ask_keysize( algo );
     r = m_alloc_clear( sizeof *r + 20 );
     r->key = both? pSUBKEYLENGTH : pKEYLENGTH;
     sprintf( r->u.value, "%u", nbits);
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (MingW32)

iD8DBQE863N1MFpNUS4lDGQRAgqTAJ9NW005a2n9RneLmYVz61IOVNCeTQCgj3Zy
z8nOyOhhpk+IoUnaMptHeNA=
=k+D4
-----END PGP SIGNATURE-----
From roconnor at Math.Berkeley.EDU  Thu May 23 04:41:01 2002
From: roconnor at Math.Berkeley.EDU (Russell O'Connor)
Date: Tue Oct  7 21:29:07 2003
Subject: GnuPG 1.0.7 for OS/2
Message-ID: <Pine.SOL.4.33.0205221839420.19679-100000@blue3.math.berkeley.edu>

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

[To: gnupg-users@gnupg.org, gnupg-devel@gnupg.org]

GnuPG 1.0.7 is available for OS/2 at
<http://math.berkeley.edu/~roconnor/gnupg/>

Requires EMX, RexxEGD, and Zlib 1.1.4.

- -- 
Russell O'Connor                           roconnor@math.berkeley.edu
           <http://www.math.berkeley.edu/~roconnor/>
``Later generations will regard set theory as a disease from which one
has recovered.'' -- Poincare
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (SunOS)
Comment: For info see http://www.gnupg.org

iD8DBQE87EjsuZUa0PWVyWQRAu1gAJ41HmicFwddsI3VLkxglYxlPny4TwCfVcmr
1O6c+oRfhocXSceh04OuEWY=
=zvQa
-----END PGP SIGNATURE-----



From pgut001 at cs.auckland.ac.nz  Thu May 23 05:17:01 2002
From: pgut001 at cs.auckland.ac.nz (Peter Gutmann)
Date: Tue Oct  7 21:29:07 2003
Subject: A modified version of GnuPG
Message-ID: <200205230217.OAA443785@ruru.cs.auckland.ac.nz>

"Max V. Zinal" <Zlat0@mail.ru> writes:

>When I said "secure memory" I was going to say "VirtualLock under Windows
>NT/2000/XP", which keeps you absolutely safe unless you have a Terminal Server
>with an evil-minded admin, or remote desktop connection with 'Debug'
>privileges.

[...]

>if we are talking about Win9x/ME (which should be called 'Mustdie Edition', I
>think), even with VirtualLock you cannot be absolutely shure.

VirtualLock() has anything from a marginal chance of preventing swapping (best-
case) to a chance of greatly increasing swapping (worst-case).  Under Win9x it
does nothing at all (it's a no-op).  It's nothing like "absolutely safe".  See
e.g. http://www.cryptoapps.com/~peter/06_random.pdf, somewhere towards the end.

Peter.



From avbidder at fortytwo.ch  Thu May 23 12:19:01 2002
From: avbidder at fortytwo.ch (Adrian 'Dagurashibanipal' von Bidder)
Date: Tue Oct  7 21:29:07 2003
Subject: secure sign & encrypt
In-Reply-To: <Pine.LNX.4.44L0.0205221140200.31437-100000@soli.inav.net>
References: <Pine.LNX.4.44L0.0205221140200.31437-100000@soli.inav.net>
Message-ID: <1022145616.5434.17.camel@atlas>

On Wed, 2002-05-22 at 18:55, Robert J. Hansen wrote:
> > In other words, your threat model says that you do not only trust the
> > sender (signer) of a message, but you trust all people who may get
> > signed messages from that sender. (Or, alternatively, you as the
> 
> <testy>
> No.  Please don't make assumptions about my threat model, especially ones 
> which are subtly and seriously wrong.
> </testy>

I'm sorry if I misunderstand you here. Let me ask you, then:

You receive an encrypted + signed message. What do you know now?

You trust the signature. Do you trust that nobody has read the message
in passing?

cheers
-- vbi



-- 
secure email with gpg            avbidder@fortytwo.ch: key id 0x92082481
                                 avbidder@acter.ch:    key id 0x5E4B731F

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : /pipermail/attachments/20020523/d147410d/attachment.bin
From jukkaho at mail.student.oulu.fi  Thu May 23 12:58:01 2002
From: jukkaho at mail.student.oulu.fi (Jukka Holappa)
Date: Tue Oct  7 21:29:07 2003
Subject: secure sign & encrypt
References: <Pine.LNX.4.44L0.0205221140200.31437-100000@soli.inav.net> <1022145616.5434.17.camel@atlas>
Message-ID: <3CECBD9E.4090306@mail.student.oulu.fi>

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

Adrian 'Dagurashibanipal' von Bidder wrote:
| On Wed, 2002-05-22 at 18:55, Robert J. Hansen wrote:
|
|>>In other words, your threat model says that you do not only trust the
|>>sender (signer) of a message, but you trust all people who may get
|>>signed messages from that sender. (Or, alternatively, you as the
|>
|><testy>
|>No.  Please don't make assumptions about my threat model, especially ones
|>which are subtly and seriously wrong.
|></testy>
|
|
| I'm sorry if I misunderstand you here. Let me ask you, then:
|
| You receive an encrypted + signed message. What do you know now?
|
| You trust the signature. Do you trust that nobody has read the message
| in passing?
|

I'm sorry to get in the middle of this, but you really can't know that
with all the signatures you put in it.

Maybe someone read the message over the shoulder before it was
signed+encrypted(+signed) or whatever.

You just have to trust a person to encrypt before anyone sees the
message. If he/she fails to do this, there's no secret message in it any
more.

- - Jukka
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE87L2eYYWM2XTSwX0RApfAAKCDKY19S2HR8weZG3iNAs7XqTFtdwCfZ9rA
Pphmzn7kfxPh7WO+7NIc5oI=
=R2SD
-----END PGP SIGNATURE-----



From avbidder at fortytwo.ch  Thu May 23 16:03:02 2002
From: avbidder at fortytwo.ch (Adrian 'Dagurashibanipal' von Bidder)
Date: Tue Oct  7 21:29:07 2003
Subject: secure sign & encrypt
In-Reply-To: <3CECBD9E.4090306@mail.student.oulu.fi>
References: <Pine.LNX.4.44L0.0205221140200.31437-100000@soli.inav.net>
	<1022145616.5434.17.camel@atlas>  <3CECBD9E.4090306@mail.student.oulu.fi>
Message-ID: <1022159038.5792.90.camel@atlas>

On Thu, 2002-05-23 at 11:59, Jukka Holappa wrote:

> | You receive an encrypted + signed message. What do you know now?
> |
> | You trust the signature. Do you trust that nobody has read the message
> | in passing?
> |
> 
> I'm sorry to get in the middle of this, but you really can't know that
> with all the signatures you put in it.
> 
> Maybe someone read the message over the shoulder before it was
> signed+encrypted(+signed) or whatever.
> 
> You just have to trust a person to encrypt before anyone sees the
> message. If he/she fails to do this, there's no secret message in it any
> more.

I trust that if a person is encrypting a message to me, this person will
also be certain that the message is handled confidentially until it is
encrypted.

The problem with the attack I'm arguing about is that the message was
*not* encrypted in the first place, but that the recipient receives it
as an encrypted message and thus might put a meaning to a message that
was not intended by the sender.

With current openPGP encryption, encryption is only useful for the
sender (he knows that the message sent is encrypted and will not be read
by anybody other than the intended recipient. Of course he trusts the
recipient not to do the wrong thing with the information). 

Encryption is *not* useful for the recipient - he must not put any
special meaning to the fact that a message was encrypted.

BUT encryption COULD be useful for the recipient, if it was made clear
that the message was sent encrypted in the first place. Of course the
recipient still needs to trust the sender/signer of the message to have
handled the contained information confidentially.


In the end it all boils down that people (or, at least I) automatically
put different meanings to a message, depending on the source of the
message. A message in the newspaper is read differently than the same
message in a letter. In the same way, an unencrypted e-mail message may
be interpreted differently from the same message that comes encrypted -
it tells something about the sender's intention.



Concerning RFC compliance:
from rfc2440, section 5.2.3.1:
======
     An implementation SHOULD ignore any subpacket of a type that it
     does not recognize.
======

So, adding a hashed subpacket with a subpacket type of, say, 110
(explicitely reserved for private use) for the purpose of announcing the
'intended encryption key' on signed+encrypted messages is fully within
the scope of the rfc and SHOULD not break any openPGP compliant
implementations.

Displaying extra warnings on decrypting messages without this special
subpacket should of course not be the default while this is not in
widespread use. Displaying extra warnings in case there is a mismatch
between the intended and the real encryption key can probably safely be
enabled per default.

Also - although I'm in no way involved with writing RFCs - the RFC
documents have been known to be revised and extended from time to time.


Huk
-- vbi



-- 
secure email with gpg            avbidder@fortytwo.ch: key id 0x92082481
                                 avbidder@acter.ch:    key id 0x5E4B731F

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : /pipermail/attachments/20020523/e3c9172d/attachment.bin
From jukkaho at mail.student.oulu.fi  Thu May 23 16:59:02 2002
From: jukkaho at mail.student.oulu.fi (Jukka Holappa)
Date: Tue Oct  7 21:29:07 2003
Subject: secure sign & encrypt
References: <Pine.LNX.4.44L0.0205221140200.31437-100000@soli.inav.net>	<1022145616.5434.17.camel@atlas>  <3CECBD9E.4090306@mail.student.oulu.fi> <1022159038.5792.90.camel@atlas>
Message-ID: <3CECF632.50606@mail.student.oulu.fi>

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

Adrian 'Dagurashibanipal' von Bidder wrote:
| BUT encryption COULD be useful for the recipient, if it was made clear
| that the message was sent encrypted in the first place. Of course the
| recipient still needs to trust the sender/signer of the message to have
| handled the contained information confidentially.
|
|
| In the end it all boils down that people (or, at least I) automatically
| put different meanings to a message, depending on the source of the
| message. A message in the newspaper is read differently than the same
| message in a letter. In the same way, an unencrypted e-mail message may
| be interpreted differently from the same message that comes encrypted -
| it tells something about the sender's intention.
|
|
|
| Concerning RFC compliance:
| from rfc2440, section 5.2.3.1:
| ======
|      An implementation SHOULD ignore any subpacket of a type that it
|      does not recognize.
| ======
|
| So, adding a hashed subpacket with a subpacket type of, say, 110
| (explicitely reserved for private use) for the purpose of announcing the
| 'intended encryption key' on signed+encrypted messages is fully within
| the scope of the rfc and SHOULD not break any openPGP compliant
| implementations.
|
| Displaying extra warnings on decrypting messages without this special
| subpacket should of course not be the default while this is not in
| widespread use. Displaying extra warnings in case there is a mismatch
| between the intended and the real encryption key can probably safely be
| enabled per default.

Very true and an excellent idea.

It would protect fairly well from sending someone else's signed messages
~ with perhaps malicuous (unsigned) attachments, only if programs warn
about missing subkey in encrypted message - and this is not going to be
a big warning in real life since there is no support for this key.

If Cecilia gets any Alices messages and is able to decrypt/copy it, he
can re-encrypt it without this subkey and send it to Bob in any other
contexts. It is not safer at all without this paranoid option which
tells that message was not sent to him originally.

Perhaps signatures would work better.. that they contain information to
who that particular message was sent. Perhaps the message itself ;)

Email programs should also warn when receiving unsigned attachments
along with encrypted/signed messages since there is no way knowing these
attachments are really from that person.


|
| Also - although I'm in no way involved with writing RFCs - the RFC
| documents have been known to be revised and extended from time to time.

Someone has to do it (not me either) :)

- - Jukka
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE87PYxYYWM2XTSwX0RAnktAJ4tX+HDuD7wrGBtMSSHK0BTBr/KHwCeLRw2
Y3Vxy/O9BzFffgXl5AoWbEM=
=WB+0
-----END PGP SIGNATURE-----



From rjhansen at inav.net  Thu May 23 17:21:02 2002
From: rjhansen at inav.net (Robert J. Hansen)
Date: Tue Oct  7 21:29:07 2003
Subject: secure sign & encrypt
In-Reply-To: <1022145616.5434.17.camel@atlas>
Message-ID: <Pine.LNX.4.44L0.0205230853260.11995-100000@soli.inav.net>

> You receive an encrypted + signed message. What do you know now?

I trust that the message really was composed by the original author, and I 
know it was encrypted when the data came out of the pipe.  If the signed 
message contains traffic which was unambiguously meant for me, then the 
message was intended for me.  Encryption and signing just means encryption 
and signing; I don't assume that crypto is some kind of magic fairy dust, 
where you sprinkle a little of it on your traffic and suddenly you're 
"secure".

A signed message doesn't mean the traffic was intended for you, it just 
means the message hasn't been tampered with in transit.  An encrypted 
message doesn't mean nobody's read the message, it just means it's been 
kept safe in transit from the time someone encrypted it to the time you 
decrypted it.




From rjhansen at inav.net  Thu May 23 17:29:01 2002
From: rjhansen at inav.net (Robert J. Hansen)
Date: Tue Oct  7 21:29:07 2003
Subject: secure sign & encrypt
In-Reply-To: <1022159038.5792.90.camel@atlas>
Message-ID: <Pine.LNX.4.44L0.0205230922350.11995-100000@soli.inav.net>

> In the end it all boils down that people (or, at least I) automatically
> put different meanings to a message, depending on the source of the

If you decide to (foolishly) infer that crypto means something that it 
doesn't, which no reputable source will tell you it does, then that 
reflects more on your own lack of understanding than a flaw in the 
protocol.  Ignorance is the Achilles' heel of every protocol, and your 
proposed fix does not fix the protocol--the protocol's not broken--it just 
makes the protocol come into line with how you think the protocol Ought To 
Be.

> Concerning RFC compliance:
> from rfc2440, section 5.2.3.1:
> ======
>      An implementation SHOULD ignore any subpacket of a type that it
>      does not recognize.
> ======

Note well that sentence.  SHOULD, not MUST.  For every program which 
correctly and properly implements RFCs, there are easily a couple of dozen 
which just barely manage to get the MUSTs implemented.  When I was working 
at McLeodUSA, they had me working on a project to reimplement RFC1991 
(Classic PGP) in-house so they could get around the licensing terms.  
(Never mind that the license fees to RSA and IDEA were prohibitive... 
management at its finest.)  Given the tremendous time constraints I was 
under, I was doing really, really well just to get the MUSTs.

If this extension gets implemented it _will_ break interoperability with 
other OpenPGP implementations (even if I don't know offhand which ones it 
will break), and we'll be the ones who will be responsible.  All for no 
effective increase in security.

> Also - although I'm in no way involved with writing RFCs - the RFC
> documents have been known to be revised and extended from time to time.

Yes, by working groups.  If you want the RFC changed, there's a process in 
place for it; take it to the IETF and make the sales pitch there.  GnuPG 
is not the place to be embracing-and-extending the RFC.

I don't know how much clearer I can make it here, really.



From Zlat0 at mail.ru  Thu May 23 18:12:01 2002
From: Zlat0 at mail.ru (Max V. Zinal)
Date: Tue Oct  7 21:29:07 2003
Subject: A modified version of GnuPG
In-Reply-To: <87adqturzu.fsf@CERT.Uni-Stuttgart.DE>
References: <200205210421.QAA220469@ruru.cs.auckland.ac.nz>
 <1387186383.20020521213928@mail.ru> <87adqturzu.fsf@CERT.Uni-Stuttgart.DE>
Message-ID: <31929626.20020523190617@mail.ru>

Wednesday, May 22, 2002, 1:10:29 AM, Florian Weimer wrote:

FW> Previous information about VirtualLock on Win32 suggests that it does
FW> not prevent memory from being paged to disk, but only from being paged
FW> to disk and then discarded.

FW> In fact, the MSDN documentation available online carefully avoids the
FW> claim that the specified memory region is never written to disk.

Yes, that's true, and that was my mistake. The only excuse for me
is the following phrase in "VirtualLock" manual:

        "The  VirtualLock  function locks the specified region of
        the process's virtual address space into physical memory,
        ensuring  that  subsequent  access to the region will not
        incur a page fault."

I think that I can write a small dummy device driver for NT-based
system  that  will  allow  a person with administrative rights to
allocate  a non-pageable region of memory. It will take some time,
I  think,  because  I will have to find DDK distribution for that
purposes.  Such task isn't too complex, although it will not work
under 9x-based systems.

I'm sorry for inconvenience.

Best regards,
        Max V. Zinal



From dmitri at users.sourceforge.net  Thu May 23 18:32:01 2002
From: dmitri at users.sourceforge.net (Dmitri)
Date: Tue Oct  7 21:29:07 2003
Subject: A modified version of GnuPG
In-Reply-To: <31929626.20020523190617@mail.ru>
References: <200205210421.QAA220469@ruru.cs.auckland.ac.nz>
	 <1387186383.20020521213928@mail.ru> <87adqturzu.fsf@CERT.Uni-Stuttgart.DE>
	  <31929626.20020523190617@mail.ru>
Message-ID: <1022167972.29488.271.camel@usb.networkfab.com>

On Thu, 2002-05-23 at 08:06, Max V. Zinal wrote:

> I think that I can write a small dummy device driver for NT-based
> system  that  will  allow  a person with administrative rights to
> allocate  a non-pageable region of memory.

The driver does not need anyone's permission, it has full access to
everything in the kernel. But only administrator can install a driver.
Then the driver can impose any security restrictions on its use.

> It will take some time,
> I  think,  because  I will have to find DDK distribution for that
> purposes.

void *ExAllocatePool(NonPagedPool, <length>);

> Such task isn't too complex

300 lines of code, maybe. You will need to handle
IRP_MJ_{CREATE,CLOSE,READ,WRITE}. But the architecture of Win2K WDM
drivers is not really straightforward; if you never did it before then
you got some reading to do ;-)

Dmitri

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : /pipermail/attachments/20020523/56b7434c/attachment.bin
From Pascal at Scheffers.Net  Thu May 23 22:41:01 2002
From: Pascal at Scheffers.Net (Pascal Scheffers)
Date: Tue Oct  7 21:29:07 2003
Subject: A modified version of GnuPG
In-Reply-To: <31929626.20020523190617@mail.ru>
References: <200205210421.QAA220469@ruru.cs.auckland.ac.nz>
	<1387186383.20020521213928@mail.ru> <87adqturzu.fsf@CERT.Uni-Stuttgart.DE> 
	<31929626.20020523190617@mail.ru>
Message-ID: <1022182918.20135.17.camel@moonchild.lcl>

On Thu, 2002-05-23 at 17:06, Max V. Zinal wrote:
> FW> In fact, the MSDN documentation available online carefully avoids the
AFAICT, MSDN-online is/was 100% in sync with the offline available
versions (3 cdrom disk/DVD distribution), the only 'but' is that it is
uptodate, meaning older information isn't there anymore (or much harder
to find). 

This was a pain in the b*tt when I was working with crypto APIs for
win95 in the 2000, it's not always clear which API works with which
version. I have no idea if it's any better for the DDK. 

I seem to have trouble accessing it right now with Galeon, but that is
sort-of to be expected.

> I  think,  because  I will have to find DDK distribution for that
That is part of the MSDN library, too. You can also just download it
from the MS website: http://www.microsoft.com/ddk/W2kDDK.asp

It says there that the DDK has all the info, libraries, manuals and
samples you'll ever need. It's a 67MB download, tho. 

- Pascal.




From pgut001 at cs.auckland.ac.nz  Fri May 24 08:06:01 2002
From: pgut001 at cs.auckland.ac.nz (Peter Gutmann)
Date: Tue Oct  7 21:29:07 2003
Subject: A modified version of GnuPG
Message-ID: <200205240507.RAA43132@ruru.cs.auckland.ac.nz>

"Max V. Zinal" <Zlat0@mail.ru> writes:

>I think that I can write a small dummy device driver for NT-based system that
>will allow a person with administrative rights to allocate a non-pageable
>region of memory. It will take some time, I think, because I will have to find
>DDK distribution for that purposes.

You don't need to do that, there are already user-level functions which do
this.  To save me having to regurgitate it all again, search sci.crypt or the
archives of Perry Metzger's crypto list for "AllocateUserPhysicalPages" to find
the details.

Peter.



From avbidder at fortytwo.ch  Fri May 24 10:33:02 2002
From: avbidder at fortytwo.ch (Adrian 'Dagurashibanipal' von Bidder)
Date: Tue Oct  7 21:29:08 2003
Subject: secure sign & encrypt
In-Reply-To: <Pine.LNX.4.44L0.0205230922350.11995-100000@soli.inav.net>
References: <Pine.LNX.4.44L0.0205230922350.11995-100000@soli.inav.net>
Message-ID: <1022225631.24970.43.camel@atlas>

On Thu, 2002-05-23 at 16:29, Robert J. Hansen wrote:
> > In the end it all boils down that people (or, at least I) automatically
> > put different meanings to a message, depending on the source of the
> 
[...]

> proposed fix does not fix the protocol--the protocol's not broken--it just 
> makes the protocol come into line with how you think the protocol Ought To 
> Be.

Agree with you here - and I feel that to many users not willing to study
the protocol in dephth 'my' variant of the protocol is closer to what
people expect if they use a crypto solution.

Jukka:
> Perhaps signatures would work better.. that they contain information
> to who that particular message was sent. Perhaps the message itself ;)

I thought about the 'intended recipient' thing, analogous to my
'inteneded encryption key', but for non-encrypted messages. Clearly this
cannot be solved by gpg - how should it know the destination of the
message? However, MUAs could copy the To: header (and Subject:, too?)
into the signed area of the mail (MIME-Headers?), and use these infos
when displaying signed mail. (But as there are many more MUAs than
OpenPGP implementations, this proposal has an even smaller chance of
ever getting implemented)


As all points have probably been made (repeatedly - yes, I'm the guilty
here) it's probably ok if this is EOT here before the discussion becomes
endless (or we could always move over to de.alt.gruppenkasper).


cheers & HAND
-- vbi


-- 
secure email with gpg            avbidder@fortytwo.ch: key id 0x92082481
                                 avbidder@acter.ch:    key id 0x5E4B731F

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : /pipermail/attachments/20020524/792409d9/attachment.bin
From Zlat0 at mail.ru  Fri May 24 18:06:02 2002
From: Zlat0 at mail.ru (Max V. Zinal)
Date: Tue Oct  7 21:29:08 2003
Subject: A modified version of GnuPG
In-Reply-To: <200205240507.RAA43132@ruru.cs.auckland.ac.nz>
References: <200205240507.RAA43132@ruru.cs.auckland.ac.nz>
Message-ID: <11716388144.20020524190723@mail.ru>

Friday, May 24, 2002, 9:07:19 AM, Peter Gutmann wrote:

PG> "Max V. Zinal" <Zlat0@mail.ru> writes:

>>I think that I can write a small dummy device driver for NT-based system that
>>will allow a person with administrative rights to allocate a non-pageable
>>region of memory. It will take some time, I think, because I will have to find
>>DDK distribution for that purposes.

PG> You don't need to do that, there are already user-level functions which do
PG> this.  To save me having to regurgitate it all again, search sci.crypt or the
PG> archives of Perry Metzger's crypto list for "AllocateUserPhysicalPages" to find
PG> the details.

I  know about these functions. Please note that they are the part
of  Address  Windowing  Extensions  (AWE), and thus are supported
only  with W2K or higher. We should also remember that Windows NT
4 is still widely used.

Best regards,
        Max V. Zinal



From pgut001 at cs.auckland.ac.nz  Mon May 27 10:34:01 2002
From: pgut001 at cs.auckland.ac.nz (Peter Gutmann)
Date: Tue Oct  7 21:29:08 2003
Subject: A modified version of GnuPG
Message-ID: <200205270735.TAA74949@ruru.cs.auckland.ac.nz>

"Max V. Zinal" <Zlat0@mail.ru> writes:
>Friday, May 24, 2002, 9:07:19 AM, Peter Gutmann wrote:
>PG> "Max V. Zinal" <Zlat0@mail.ru> writes:
>>>I think that I can write a small dummy device driver for NT-based system that
>>>will allow a person with administrative rights to allocate a non-pageable
>>>region of memory. It will take some time, I think, because I will have to find
>>>DDK distribution for that purposes.
>
>PG> You don't need to do that, there are already user-level functions which do
>PG> this.  To save me having to regurgitate it all again, search sci.crypt or the
>PG> archives of Perry Metzger's crypto list for "AllocateUserPhysicalPages" to find
>PG> the details.
>
>I know about these functions. Please note that they are the part of Address
>Windowing Extensions (AWE), and thus are supported only with W2K or higher. We
>should also remember that Windows NT 4 is still widely used.

You have to make a tradeoff, either be backwards-compatible with NT4 (which I
doubt is still widely used except maybe on a few servers which no-one wants to
touch) and face an incredibly difficult task of writing an NT kernel driver to
do it, or require Win2K and have Microsoft do most of it for you.  Trying to be
NT4-compatible seems to be an unnecesarily painful way to do things.

Peter.


From broonie at sirena.org.uk  Mon May 27 11:47:01 2002
From: broonie at sirena.org.uk (Mark Brown)
Date: Tue Oct  7 21:29:08 2003
Subject: A modified version of GnuPG
In-Reply-To: <200205270735.TAA74949@ruru.cs.auckland.ac.nz>
References: <200205270735.TAA74949@ruru.cs.auckland.ac.nz>
Message-ID: <20020527084805.GA848@sirena.org.uk>

On Mon, May 27, 2002 at 07:35:21PM +1200, Peter Gutmann wrote:

> You have to make a tradeoff, either be backwards-compatible with NT4 (which I
> doubt is still widely used except maybe on a few servers which no-one wants to
> touch) and face an incredibly difficult task of writing an NT kernel driver to

There's still a reasonable number of deployed NT 4 systems, including
desktops.  Often it's a case of "it's not broken for us" and not/or
wanting to go to the effort of moving off a platform that has been
reliable and stable until the last possible minute.

> do it, or require Win2K and have Microsoft do most of it for you.  Trying to be
> NT4-compatible seems to be an unnecesarily painful way to do things.

I do agree with the conclusion, though.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : /pipermail/attachments/20020527/7d401113/attachment.bin
From disastry at saiknes.lv  Mon May 27 12:18:02 2002
From: disastry at saiknes.lv (disastry@saiknes.lv)
Date: Tue Oct  7 21:29:08 2003
Subject: A modified version of GnuPG
Message-ID: <3CF1E23A.24C83E24@saiknes.lv>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Max V. Zinal wrote:
> 
> PG> You don't need to do that, there are already user-level functions which do
> PG> this.  To save me having to regurgitate it all again, search sci.crypt or the
> PG> archives of Perry Metzger's crypto list for "AllocateUserPhysicalPages" to find
> PG> the details.
> 
> I  know about these functions. Please note that they are the part
> of  Address  Windowing  Extensions  (AWE), and thus are supported
> only  with W2K or higher. We should also remember that Windows NT
> 4 is still widely used.

so just call GetProcAderss(hKernel32,"AllocateUserPhysicalPages");
to find if the function is available, if yes - use it :)

__
Disastry  http://disastry.dhs.org/
http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon
 ^----PGP 2.6.3ia-multi06 (supports IDEA, CAST5, BLOWFISH, TWOFISH,
      AES, 3DES ciphers and MD5, SHA1, RIPEMD160, SHA2 hashes)
-----BEGIN PGP SIGNATURE-----
Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1

iQA/AwUBPPHFvjBaTVEuJQxkEQNNOQCcCOw75WYyyyORl+IDWPnldvTOHiYAoMn6
nTM1sXjGVJSkewvIIlSY9NyA
=c7hS
-----END PGP SIGNATURE-----


From rjhansen at inav.net  Mon May 27 13:11:01 2002
From: rjhansen at inav.net (Robert J. Hansen)
Date: Tue Oct  7 21:29:08 2003
Subject: Unpredictable GPGME bug
Message-ID: <Pine.LNX.4.44L0.0205270506070.16314-100000@soli.inav.net>

Looks like there might be a bug in GPGME (I know, pre-1.0 software with 
bugs--what's the world coming to?).  My C++ bindings for GPGME attempt to 
grab all sorts of string data for a given key, and sometimes it will be 
able to grab a string representation of the algorithm type and other times 
it'll segfault.  The offending snippet of code looks like:

GpgmeKey _key;
std::string _algo;

_algo = gpgme_key_get_string_attr(_key, GPGME_ATTR_ALGO, NULL, 0);

... Maybe one time in ten, that line of code will segfault.  
gpgme_key_get_string_attr apparently returns a NULL pointer, and trying to 
make a C++ std::string out of a NULL pointer is an instant segfault.

This has happened for other string quantities, such as usernames, etc.  
For now, my solution is to assign the result of g_k_g_s_a() to a const 
char*, test the const char* against NULL, and then assign either the const 
char* to _algo or else assign "Unassigned" to _algo.  However, this is 
fairly inelegant given that we could just fix the GPGME code.  :)





From rjhansen at inav.net  Mon May 27 14:23:02 2002
From: rjhansen at inav.net (Robert J. Hansen)
Date: Tue Oct  7 21:29:08 2003
Subject: GPGME wishlist...
Message-ID: <Pine.LNX.4.44L0.0205270600470.7300-100000@soli.inav.net>

*  The terminology in the documentation is a little awkward when it comes 
to signatures (on keys/user IDs).  For instance, there's a section on 
"Trust Items"--well, yeah, signatures tell us if a key/userid is or isn't 
trusted... on the other hand, gpgme_key_get_string_attr says that it's 
used for "attributes of sub keys and user IDs", and a signature is an 
attribute of those, so... etc.  It appears that both interfaces are 
necessary to some degree, but the docs never make it clear to what degree 
each are necessary.

*  How to get key signature information is a little 
awkward/counterintuitive.  For instance, according to my current (limited) 
understanding of the interface, in order to process key signatures I must:

1.  call gpgme_op_trustlist_start, passing in a 16-hex key ID to uniquely 
identify the key I want to iterate over

2.  start pulling trust items off the key

3.  get each item's GPGME_ATTR_USERID

4.  ... and only then can I associate a given trust item with a given user 
ID.

Please note: I haven't written code that works this way yet.  This is just 
the way I understand it to be, from looking at the docs.  If I'm 
misunderstanding, then please take my idiocy as evidence the docs need to 
be written for congenital idiots such as myself (grin).  If I'm not 
misunderstanding the docs, then it seems like we're making the process 
tougher than it needs to be.

Possible solution: add a new function,

gpgme_op_trustlist_uid_start(
	GpgmeCtx ctx,
	const char *hexID,
	int userID,
	int max_level
	)

... which would act just like gpgme_op_trustlist_start, except it would 
restrict the iteration to a given user ID.  This would make things a 
little easier for those of us who aren't geniuses.  :)

It's 6:20am and now I'm going to bed.  Thanks, guys.
	



From Marcus.Brinkmann at ruhr-uni-bochum.de  Mon May 27 14:54:02 2002
From: Marcus.Brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann)
Date: Tue Oct  7 21:29:08 2003
Subject: Unpredictable GPGME bug
In-Reply-To: <Pine.LNX.4.44L0.0205270506070.16314-100000@soli.inav.net>
References: <Pine.LNX.4.44L0.0205270506070.16314-100000@soli.inav.net>
Message-ID: <20020527115449.GB1180@212.23.136.22>

On Mon, May 27, 2002 at 05:12:24AM -0500, Robert J. Hansen wrote:
> Looks like there might be a bug in GPGME (I know, pre-1.0 software with 
> bugs--what's the world coming to?).  My C++ bindings for GPGME attempt to 
> grab all sorts of string data for a given key, and sometimes it will be 
> able to grab a string representation of the algorithm type and other times 
> it'll segfault.  The offending snippet of code looks like:
> 
> GpgmeKey _key;
> std::string _algo;
> 
> _algo = gpgme_key_get_string_attr(_key, GPGME_ATTR_ALGO, NULL, 0);
> 
> ... Maybe one time in ten, that line of code will segfault.  

What do you mean?  one out of ten times you run this on the same key, or for
one out of ten keys?

Let's look at the code:
    case GPGME_ATTR_ALGO:
      for (k = &key->keys; k && idx; k=k->next, idx--)
        ;
      if (k)
        val = pkalgo_to_string (k->key_algo);
      break;

So, if _key is really a key (and not NULL itself), which contains at least
one subkey (key->keys)), then this can not return NULL, because
pkalgo_to_string doesn't return NULL.

You could let it crash in gdb and check what the key and key->keys look
like in the case it is failing.

> gpgme_key_get_string_attr apparently returns a NULL pointer, and trying to 
> make a C++ std::string out of a NULL pointer is an instant segfault.
> 
> This has happened for other string quantities, such as usernames, etc.  
> For now, my solution is to assign the result of g_k_g_s_a() to a const 
> char*, test the const char* against NULL, and then assign either the const 
> char* to _algo or else assign "Unassigned" to _algo.  However, this is 
> fairly inelegant given that we could just fix the GPGME code.  :)

Most properties are optional and can return NULL, so you must catch the NULL
case anyway.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de


From aphex at nullify.org  Mon May 27 19:54:02 2002
From: aphex at nullify.org (Keith Ray)
Date: Tue Oct  7 21:29:08 2003
Subject: Photo ID race condition
Message-ID: <1022518490.3cf264daeba39@mail.nullify.org>

There is a (non-security) race condition in the photo ID code under
Windows.  If the user has a slow loading image viewer (ie. Mozilla), GnuPG could
delete the temp file before the viewer finishes initializing.  I can think of a
number of solutions:

1. Wait for the viewer to exit before returning to GnuPG.
2. Insert a delay between exec_read() and exec_finish().  Then again, on a slow
system with little RAM, how much is enough?
3. Delay deleting the temp files until GnuPG exits.

  -- Keith


From dmitri at users.sourceforge.net  Mon May 27 20:19:01 2002
From: dmitri at users.sourceforge.net (Dmitri)
Date: Tue Oct  7 21:29:08 2003
Subject: Photo ID race condition
In-Reply-To: <1022518490.3cf264daeba39@mail.nullify.org>
References: <1022518490.3cf264daeba39@mail.nullify.org>
Message-ID: <1022520028.3628.40.camel@usb.networkfab.com>

On Mon, 2002-05-27 at 09:54, Keith Ray wrote:

> There is a (non-security) race condition in the photo ID code under
> Windows.  If the user has a slow loading image viewer (ie. Mozilla), GnuPG could
> delete the temp file before the viewer finishes initializing.  I can think of a
> number of solutions:
> 
> 1. Wait for the viewer to exit before returning to GnuPG.

GnuPG actually won't stop running. But this seems to be the right
solution. See CreateProcess() and OpenProcess() here:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/prothred_9dpv.asp

> 2. Insert a delay between exec_read() and exec_finish().  Then again, on a slow
> system with little RAM, how much is enough?

Fudge factor works only in 27% of all cases ;-)

> 3. Delay deleting the temp files until GnuPG exits.

Dmitri

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : /pipermail/attachments/20020527/f3eecdbb/attachment.bin
From wk at gnupg.org  Mon May 27 21:03:01 2002
From: wk at gnupg.org (Werner Koch)
Date: Tue Oct  7 21:29:08 2003
Subject: A modified version of GnuPG
In-Reply-To: <3CF1E23A.24C83E24@saiknes.lv> (disastry@saiknes.lv's message
 of "Mon, 27 May 2002 09:37:30 +0200")
References: <3CF1E23A.24C83E24@saiknes.lv>
Message-ID: <87lma5mpmp.fsf@alberti.gnupg.de>

On Mon, 27 May 2002 09:37:30 +0200, disastry  said:

> so just call GetProcAderss(hKernel32,"AllocateUserPhysicalPages");
> to find if the function is available, if yes - use it :)

I'll see what I can do.  I have to incorporate some RNG enhancements from
Cryptlib anyway.


Salam-Shalom,

   Werner



From wk at gnupg.org  Mon May 27 21:07:02 2002
From: wk at gnupg.org (Werner Koch)
Date: Tue Oct  7 21:29:08 2003
Subject: GPGME wishlist...
In-Reply-To: <Pine.LNX.4.44L0.0205270600470.7300-100000@soli.inav.net> ("Robert
 J. Hansen"'s message of "Mon, 27 May 2002 06:23:29 -0500 (CDT)")
References: <Pine.LNX.4.44L0.0205270600470.7300-100000@soli.inav.net>
Message-ID: <87hektmper.fsf@alberti.gnupg.de>

On Mon, 27 May 2002 06:23:29 -0500 (CDT), Robert J Hansen said:

> *  How to get key signature information is a little 
> awkward/counterintuitive.  For instance, according to my current (limited) 
> understanding of the interface, in order to process key signatures I must:

Frankly, there is no interface for it.  


> 1.  call gpgme_op_trustlist_start, passing in a 16-hex key ID to

This is an expermimental - I hope the manual says so, but I am not
sure.  


Shalom-Salam,

   Werner



From andrew at mcdonald.org.uk  Mon May 27 21:19:01 2002
From: andrew at mcdonald.org.uk (Andrew McDonald)
Date: Tue Oct  7 21:29:08 2003
Subject: Photo ID race condition
In-Reply-To: <1022518490.3cf264daeba39@mail.nullify.org>
References: <1022518490.3cf264daeba39@mail.nullify.org>
Message-ID: <20020527181933.GA969@mcdonald.org.uk>

On Mon, May 27, 2002 at 11:54:50AM -0500, Keith Ray wrote:
> There is a (non-security) race condition in the photo ID code under
> Windows.  If the user has a slow loading image viewer (ie. Mozilla),
> GnuPG could delete the temp file before the viewer finishes
> initializing.

This is an issue I have seen mentioned in connection with mutt's
viewing of attachments. Try searching for mutt_bgrun, a script that
provides one way to solve this.

-- 
Andrew McDonald
E-mail: andrew@mcdonald.org.uk
http://www.mcdonald.org.uk/andrew/


From dshaw at jabberwocky.com  Tue May 28 01:51:01 2002
From: dshaw at jabberwocky.com (David Shaw)
Date: Tue Oct  7 21:29:09 2003
Subject: Photo ID race condition
In-Reply-To: <1022518490.3cf264daeba39@mail.nullify.org>
References: <1022518490.3cf264daeba39@mail.nullify.org>
Message-ID: <20020527223655.GB813@akamai.com>

On Mon, May 27, 2002 at 11:54:50AM -0500, Keith Ray wrote:
> There is a (non-security) race condition in the photo ID code under
> Windows.  If the user has a slow loading image viewer (ie. Mozilla), GnuPG could
> delete the temp file before the viewer finishes initializing.  I can think of a
> number of solutions:
> 
> 1. Wait for the viewer to exit before returning to GnuPG.
> 2. Insert a delay between exec_read() and exec_finish().  Then again, on a slow
> system with little RAM, how much is enough?
> 3. Delay deleting the temp files until GnuPG exits.

This is a known problem with 1.0.7 (1.0.7 was never really intended
for widespread Win32 use).  Until 1.0.8 is released with a
non-system()-based implementation of the exec code, you have a few
options:

1) Patch the code based on the CVS
2) Use %I instead of %i in your photo-viewer command line
3) Try a photo-viewer of "start /w %i.jpg"

(#3 should work but I haven't tested it - I'm traveling and have no
access to a windows box at the moment)

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From aphex at nullify.org  Tue May 28 04:40:01 2002
From: aphex at nullify.org (Keith Ray)
Date: Tue Oct  7 21:29:09 2003
Subject: Photo ID race condition
Message-ID: <1022550030.3cf2e00e4d1e1@mail.nullify.org>

Quoting David Shaw <dshaw@jabberwocky.com>:
> On Mon, May 27, 2002 at 11:54:50AM -0500, Keith Ray wrote:
> > There is a (non-security) race condition in the photo ID code under
> > Windows.  If the user has a slow loading image viewer (ie. Mozilla), GnuPG
> > could delete the temp file before the viewer finishes initializing.  I can
> > think of a number of solutions:
> >
> > 1. Wait for the viewer to exit before returning to GnuPG.
> > 2. Insert a delay between exec_read() and exec_finish().  Then again, on a
> > slow system with little RAM, how much is enough?
> > 3. Delay deleting the temp files until GnuPG exits.
>
> This is a known problem with 1.0.7 (1.0.7 was never really intended
> for widespread Win32 use).  Until 1.0.8 is released with a
> non-system()-based implementation of the exec code, you have a few
> options:
>
> 1) Patch the code based on the CVS
> 2) Use %I instead of %i in your photo-viewer command line
> 3) Try a photo-viewer of "start /w %i.jpg"
>
> (#3 should work but I haven't tested it - I'm traveling and have no
> access to a windows box at the moment)

Hmm, I should have been more explicit on my setup ;)  I was using 1.0.7a-cvs
from May 24.  The photo viewer was the default:

#define DEFAULT_PHOTO_COMMAND "start /w %i"

Mozilla is the default .jpg viewer.   For some reason, execution returns to
GnuPG immediately after launching Mozilla.  Mozilla does not finish loading
itself and then the picture before GnuPG deletes the temporary directory and
file.  Thus, solution #3 isn't working.

Unless there is a way to modify the "start" command to actually wait when
launching an object file instead of an executable, I think the best route would
be to read the registry to find the default viewer and then "start" that.

I will code up a patch against CVS and e-mail it to you when I'm done.

  -- Keith


From dshaw at jabberwocky.com  Tue May 28 05:30:02 2002
From: dshaw at jabberwocky.com (David Shaw)
Date: Tue Oct  7 21:29:09 2003
Subject: Photo ID race condition
In-Reply-To: <1022550030.3cf2e00e4d1e1@mail.nullify.org>
References: <1022550030.3cf2e00e4d1e1@mail.nullify.org>
Message-ID: <20020528023032.GE813@akamai.com>

On Mon, May 27, 2002 at 08:40:30PM -0500, Keith Ray wrote:
> Hmm, I should have been more explicit on my setup ;)  I was using 1.0.7a-cvs
> from May 24.  The photo viewer was the default:
> 
> #define DEFAULT_PHOTO_COMMAND "start /w %i"
> 
> Mozilla is the default .jpg viewer.   For some reason, execution returns to
> GnuPG immediately after launching Mozilla.  Mozilla does not finish loading
> itself and then the picture before GnuPG deletes the temporary directory and
> file.  Thus, solution #3 isn't working.

It looks like Mozilla is being "helpful" here and returning control
before doing the requested command.  If that is the case, then this is
not something that GnuPG can address.  Are you sure that is what is
happening?  What happens when you do "start /w foobar.jpg" from the
command line on some other jpg you may have lying around?

> Unless there is a way to modify the "start" command to actually wait
> when launching an object file instead of an executable, I think the
> best route would be to read the registry to find the default viewer
> and then "start" that.

GnuPG is a crypto program, and reading the registry to figure out
photo viewers is getting too far astray from that core functionality.
This is where bugs come in and bugs in crypto software can be very
dangerous.  I did add generic call-a-program functionality because it
is usable in several places (keyservers as well as photo IDs) but it
must be kept simple and easily verifiable.

In any event, the whole point of "start" itself is to read the
registry and start the appropriate program, so there is no point in
adding code to do this to GnuPG.

> I will code up a patch against CVS and e-mail it to you when I'm done.

The "/w" flag for start means "wait".  Unfortunately, it seems that
Mozilla's start-in-the-background feature defeats this.  If that is
what is happening then there is nothing that can (easily) be done here
with start or even internal to GnuPG since it can only wait for a
program that does not start in the background (some viewers give you a
choice).

If you must use Mozilla as your viewer, then use %I in your
photo-viewer rather than %i (that is, capital "I" rather than
lowercase "i").  This will make GnuPG not delete the temp file at all,
so you will need to delete it yourself when you are done with it.

Like I said before, 1.0.8 has a slightly different implementation (not
yet checked in, so you won't see it in CVS) that allows for better
handling of arguments in the photo-viewer command line, but there is
very little that can be done about the start-in-the-background
problem.  If it makes you feel any better, it's the same way on Unix
when using temp files, but at least the Unix viewers usually aren't
written to background themselves automatically.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From keith at nullify.org  Tue May 28 11:48:01 2002
From: keith at nullify.org (Keith Ray)
Date: Tue Oct  7 21:29:09 2003
Subject: Photo ID race condition
In-Reply-To: <20020527223655.GB813@akamai.com>
References: <1022518490.3cf264daeba39@mail.nullify.org> <20020527223655.GB813@akamai.com>
Message-ID: <1022550003.3cf2dff3e2115@mail.nullify.org>

Quoting David Shaw <dshaw@jabberwocky.com>:
> On Mon, May 27, 2002 at 11:54:50AM -0500, Keith Ray wrote:
> > There is a (non-security) race condition in the photo ID code under
> > Windows.  If the user has a slow loading image viewer (ie. Mozilla), GnuPG
> > could delete the temp file before the viewer finishes initializing.  I can
> > think of a number of solutions:
> > 
> > 1. Wait for the viewer to exit before returning to GnuPG.
> > 2. Insert a delay between exec_read() and exec_finish().  Then again, on a
> > slow system with little RAM, how much is enough?
> > 3. Delay deleting the temp files until GnuPG exits.
> 
> This is a known problem with 1.0.7 (1.0.7 was never really intended
> for widespread Win32 use).  Until 1.0.8 is released with a
> non-system()-based implementation of the exec code, you have a few
> options:
> 
> 1) Patch the code based on the CVS
> 2) Use %I instead of %i in your photo-viewer command line
> 3) Try a photo-viewer of "start /w %i.jpg"
> 
> (#3 should work but I haven't tested it - I'm traveling and have no
> access to a windows box at the moment)

Hmm, I should have been more explicit on my setup ;)  I was using 1.0.7a-cvs
from May 24.  The photo viewer was the default:

#define DEFAULT_PHOTO_COMMAND "start /w %i"

Mozilla is the default .jpg viewer.   For some reason, execution returns to
GnuPG immediately after launching Mozilla.  Mozilla does not finish loading
itself and then the picture before GnuPG deletes the temporary directory and
file.  Thus, solution #3 isn't working.

Unless there is a way to modify the "start" command to actually wait when
launching an object file instead of an executable, I think the best route would
be to read the registry to find the default viewer and then "start" that.

I will code up a patch against CVS and e-mail it to you when I'm done.

  -- Keith


From wk at gnupg.org  Tue May 28 12:33:01 2002
From: wk at gnupg.org (Werner Koch)
Date: Tue Oct  7 21:29:09 2003
Subject: Photo ID race condition
In-Reply-To: <1022550003.3cf2dff3e2115@mail.nullify.org> (Keith Ray's
 message of "Mon, 27 May 2002 20:40:03 -0500")
References: <1022518490.3cf264daeba39@mail.nullify.org>
	<20020527223655.GB813@akamai.com>
	<1022550003.3cf2dff3e2115@mail.nullify.org>
Message-ID: <87elfwlim1.fsf@alberti.gnupg.de>

On Mon, 27 May 2002 20:40:03 -0500, Keith Ray said:

> Unless there is a way to modify the "start" command to actually wait when
> launching an object file instead of an executable, I think the best route would
> be to read the registry to find the default viewer and then "start" that.

> I will code up a patch against CVS and e-mail it to you when I'm done.

You better write a wrapper taking care of of starting the default
image viewer and deleting the temporary file.  I don't think it is a
good idea to add this extra code to gpg.


Shalom-Salam,

   Werner



From wagner at tik.ee.ethz.ch  Wed May 29 07:27:01 2002
From: wagner at tik.ee.ethz.ch (wagner@tik.ee.ethz.ch)
Date: Tue Oct  7 21:29:09 2003
Subject: Mail delivery failed
Message-ID: <200205290427.GAA04870@tik2.ethz.ch>

The mail system has received a message appearently from you
that had the following header fields:

    From:     gnupg-devel-request@gnupg.org
    Subject:  Gnupg-devel digest, Vol 1 #373 - 2 msgs
    To:       gnupg-devel@gnupg.org
    Date:     Wed, 29 May 2002 06:25:43 +0200

The message has been deleted automatically for the following reason:

SPAM detected. Mail dropped.


This message has been generated automatically.


------------------------------------------------------------------------------
Arno Wagner           Dipl. Inform.          wagner@tik.ee.ethz.ch
 A modern US Navy cruiser now requires 26 tons of manuals. This is enough to 
 affect the vessel's performance. -- New Scientist on the paperless office
 
 Spam will get you reported to your ISP. I explicitely forbid you 
 to store my email address for purpose of reselling or spamming. 
 


From aphex at nullify.org  Thu May 30 06:00:03 2002
From: aphex at nullify.org (Keith Ray)
Date: Tue Oct  7 21:29:09 2003
Subject: Bug in parse_one_sig_subpkt ?
Message-ID: <1022727633.3cf595d1916a9@mail.nullify.org>

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

I think I have found a bug in the latest GnuPG v1.0.7a-cvs
(29-May-2002).  When generating a new keypair, build_sig_subpkt() calls
parse_one_sig_subpkt() with a type of SIGSUBPKT_KS_FLAGS.  Since there
is no 'case' for SIGSUBPKT_KS_FLAGS, parse_one_sig_subpkt() returns -1
and GnuPG fails.

  -- Keith

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7a-nr1 (Windows 2000) - GPGshell v2.30

iD8DBQE89ZWIBxrjkHkmmhIRAhvJAKCJweZVl8dt6muA4GBNZwVagmHd2gCdGQ5G
+MrsxTOmFINxe7ek6/MoVH0=
=FJc2
-----END PGP SIGNATURE-----


From dshaw at jabberwocky.com  Thu May 30 06:32:02 2002
From: dshaw at jabberwocky.com (David Shaw)
Date: Tue Oct  7 21:29:09 2003
Subject: Bug in parse_one_sig_subpkt ?
In-Reply-To: <1022727633.3cf595d1916a9@mail.nullify.org>
References: <1022727633.3cf595d1916a9@mail.nullify.org>
Message-ID: <20020530033209.GC6908@akamai.com>

On Wed, May 29, 2002 at 10:00:33PM -0500, Keith Ray wrote:

> I think I have found a bug in the latest GnuPG v1.0.7a-cvs
> (29-May-2002).  When generating a new keypair, build_sig_subpkt() calls
> parse_one_sig_subpkt() with a type of SIGSUBPKT_KS_FLAGS.  Since there
> is no 'case' for SIGSUBPKT_KS_FLAGS, parse_one_sig_subpkt() returns -1
> and GnuPG fails.

Fixed.  Thank you.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From keith at nullify.org  Thu May 30 12:00:01 2002
From: keith at nullify.org (Keith Ray)
Date: Tue Oct  7 21:29:09 2003
Subject: Bug in parse_one_sig_subpkt ?
Message-ID: <1022727578.3cf5959a34c68@mail.nullify.org>

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

I think I have found a bug in the latest GnuPG v1.0.7a-cvs
(29-May-2002).  When generating a new keypair, build_sig_subpkt() calls
parse_one_sig_subpkt() with a type of SIGSUBPKT_KS_FLAGS.  Since there
is no 'case' for SIGSUBPKT_KS_FLAGS, parse_one_sig_subpkt() returns -1
and GnuPG fails.

  -- Keith

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7a-nr1 (Windows 2000) - GPGshell v2.30

iD8DBQE89ZWIBxrjkHkmmhIRAhvJAKCJweZVl8dt6muA4GBNZwVagmHd2gCdGQ5G
+MrsxTOmFINxe7ek6/MoVH0=
=FJc2
-----END PGP SIGNATURE-----


From wagner at tik.ee.ethz.ch  Thu May 30 12:01:01 2002
From: wagner at tik.ee.ethz.ch (wagner@tik.ee.ethz.ch)
Date: Tue Oct  7 21:29:09 2003
Subject: Mail delivery failed
Message-ID: <200205300902.LAA17729@tik2.ethz.ch>

The mail system has received a message appearently from you
that had the following header fields:

    From:     gnupg-devel-request@gnupg.org
    Subject:  Gnupg-devel digest, Vol 1 #374 - 3 msgs
    To:       gnupg-devel@gnupg.org
    Date:     Thu, 30 May 2002 06:25:43 +0200

The message has been deleted automatically for the following reason:

SPAM detected. Mail dropped.


This message has been generated automatically.


------------------------------------------------------------------------------
Arno Wagner           Dipl. Inform.          wagner@tik.ee.ethz.ch
 A modern US Navy cruiser now requires 26 tons of manuals. This is enough to 
 affect the vessel's performance. -- New Scientist on the paperless office
 
 Spam will get you reported to your ISP. I explicitely forbid you 
 to store my email address for purpose of reselling or spamming. 
 


From denis at ripe.net  Thu May 30 12:11:01 2002
From: denis at ripe.net (Denis Walker)
Date: Tue Oct  7 21:29:09 2003
Subject: dry run
Message-ID: <200205300908.g4U98NA09988@birch.ripe.net>

Hi guys

The man pages and your on line docs both say that dry run is not yet fully 
implemented. What does this mean? Can I safely use dry run to check the 
response before doing the changes?

cheers
denis



From denis at ripe.net  Thu May 30 12:16:01 2002
From: denis at ripe.net (Denis Walker)
Date: Tue Oct  7 21:29:09 2003
Subject: dry run
Message-ID: <200205300916.g4U9GlA14641@birch.ripe.net>

Hi guys

The man pages and your on line docs both say that dry run is not yet fully 
implemented. What does this mean? Can I safely use dry run to check the 
response before doing the changes?

cheers
denis





From wk at gnupg.org  Thu May 30 12:21:01 2002
From: wk at gnupg.org (Werner Koch)
Date: Tue Oct  7 21:29:09 2003
Subject: Mail delivery failed
In-Reply-To: <200205300902.LAA17729@tik2.ethz.ch> (wagner@tik.ee.ethz.ch's
 message of "Thu, 30 May 2002 11:02:08 +0200 (MET DST)")
References: <200205300902.LAA17729@tik2.ethz.ch>
Message-ID: <87n0uif0ob.fsf@alberti.gnupg.de>

Hi!

I disapled you account until you get your spam "reporting" tool
right.  I'd suggest to remove it entirely because automated spam
reporting does more harm than real spam.


Shalom-Salam,

   Werner



From chris at netservers.co.uk  Thu May 30 12:44:02 2002
From: chris at netservers.co.uk (Chris Wilson)
Date: Tue Oct  7 21:29:09 2003
Subject: Mail delivery failed
In-Reply-To: <200205300902.LAA17729@tik2.ethz.ch>
Message-ID: <Pine.LNX.4.44.0205301043500.30283-100000@localhost>

Dear Wagner,

If you are going to treat this list as spam, would you please unsubscribe?

Cheers, Chris.

On Thu, 30 May 2002 wagner@tik.ee.ethz.ch wrote:

> The mail system has received a message appearently from you
> that had the following header fields:
> 
>     From:     gnupg-devel-request@gnupg.org
>     Subject:  Gnupg-devel digest, Vol 1 #374 - 3 msgs
>     To:       gnupg-devel@gnupg.org
>     Date:     Thu, 30 May 2002 06:25:43 +0200
> 
> The message has been deleted automatically for the following reason:
> 
> SPAM detected. Mail dropped.
> 
> 
> This message has been generated automatically.
> 
> 
> ------------------------------------------------------------------------------
> Arno Wagner           Dipl. Inform.          wagner@tik.ee.ethz.ch
>  A modern US Navy cruiser now requires 26 tons of manuals. This is enough to 
>  affect the vessel's performance. -- New Scientist on the paperless office
>  
>  Spam will get you reported to your ISP. I explicitely forbid you 
>  to store my email address for purpose of reselling or spamming. 
>  
> 
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
> 

-- 
   ___ __     _
 / __// / ,__(_)_  | Chris Wilson -- UNIX Firewall Lead Developer |
/ (_ / ,\/ _/ /_ \ | NetServers.co.uk http://www.netservers.co.uk |
\ _//_/_/_//_/___/ | 21 Signet Court, Cambridge, UK. 01223 576516 |



From denis at ripe.net  Thu May 30 14:47:01 2002
From: denis at ripe.net (Denis Walker)
Date: Tue Oct  7 21:29:09 2003
Subject: deleting a uid from a public key
Message-ID: <200205301148.g4UBmSA28404@birch.ripe.net>

Hi guys

According to your manual you can delete a uid from your local public key. But 
if someone else imports your key it merges the uids from the old and new keys. 
So the deletion does not take effect. The manual says in order to delete a uid 
from someone's public key you must first remove the key and them import the 
new key. Why does import not delete uids? Are there any security implications 
involved here? If I am updating keys should I always remove the key first and 
them import the new one?

cheers
denis



From dshaw at jabberwocky.com  Thu May 30 15:23:01 2002
From: dshaw at jabberwocky.com (David Shaw)
Date: Tue Oct  7 21:29:10 2003
Subject: deleting a uid from a public key
In-Reply-To: <200205301148.g4UBmSA28404@birch.ripe.net>
References: <200205301148.g4UBmSA28404@birch.ripe.net>
Message-ID: <20020530122316.GE6908@akamai.com>

On Thu, May 30, 2002 at 01:48:28PM +0200, Denis Walker wrote:
> Hi guys
> 
> According to your manual you can delete a uid from your local public
> key. But if someone else imports your key it merges the uids from
> the old and new keys.  So the deletion does not take effect. The
> manual says in order to delete a uid from someone's public key you
> must first remove the key and them import the new key. Why does
> import not delete uids? Are there any security implications involved
> here? If I am updating keys should I always remove the key first and
> them import the new one?

As you saw, deleting a uid does not really delete it - it will come
back when the key is merged with an earlier copy of itself.  There are
several reasons for this, the simplest being: how does GnuPG know
which is the "more recent" key?  For example, if I have a key with 3
uids, and I import the same key with 2 uids, does that mean that one
of the uids is to be deleted (the 2 uid version is newer) or should I
do nothing (the 3 uid version is newer).

To resolve this, OpenPGP allows a user to revoke a uid - a revoked uid
is present on the key but is not used.  If you have a uid that you
don't want to use any longer, use "revsig" to revoke the
self-signature on that uid.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From stephane at sente.ch  Thu May 30 19:11:02 2002
From: stephane at sente.ch (=?ISO-8859-1?Q?St=E9phane_Corth=E9sy?=)
Date: Tue Oct  7 21:29:10 2003
Subject: charset problem
Message-ID: <07E6337B-73E8-11D6-B149-0003936A3BE2@sente.ch>

Hi,

Is the following behavior correct?

The file ~/.gnupg/options contains an option "comment" with value "? 
eacute"; file has been saved using UTF8 encoding.
The file /tmp/test contains same text "? eacute", but in iso-8859-1.

Performing the command

gpg --charset iso-8859-1 --clearsign /tmp/test

creates a new file /tmp/test.asc which contains invalid text: there is a 
mix of iso-8859-1 (for the body) and UTF8 (for the signature) charsets!

It seems that comment is copied as is, i.e. not converted to --charset 
(what is furthermore not always possible...), thus result is totally 
unreadable.


(I'm working with GnuPG 1.0.7 on MacOS X 10.1.4.)

Cheers,

St?phane



From stephane at sente.ch  Thu May 30 19:23:02 2002
From: stephane at sente.ch (=?ISO-8859-1?Q?St=E9phane_Corth=E9sy?=)
Date: Tue Oct  7 21:29:10 2003
Subject: malloc problem
Message-ID: <A5359632-73E9-11D6-B149-0003936A3BE2@sente.ch>

Hi,

Running gpg 1.0.7 on MacOS X 10.1.4, I noticed a malloc problems. I type 
the following command:

gpg --debug 511 --charset utf-8 --no-force-v3-sigs --armor 
--notation-data mycode=myvalue --clearsign

Then I enter my passphrase, the text to sign ("test") and CTRL-D, and 
there is a (MacOS X specific) malloc warning. Can anyone reproduce the 
problem on another system having a malloc-protection too (guard pages)?
Problem is due to the notation-data presence.

Cheers,

St?phane

... [snipped]...
gpg: DBG: iobuf-7.0: underflow: eof
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

test
gpg: DBG: armor-filter: control: 5
gpg: DBG: iobuf-8.1: push `armor_filter'
gpg: DBG: armor-filter: control: 5
gpg: DBG: iobuf chain: 8.1 `armor_filter' filter_eof=0 start=0 len=0
gpg: DBG: iobuf chain: 8.0 `file_filter(fd)' filter_eof=0 start=0 len=0
gpg: DBG: armor-filter: control: 1
*** malloc[4606]: Deallocation of a pointer not malloced: 0x20d2ff; This 
could be a double free(), or free() called with the middle of an 
allocated block; Try setting environment variable MallocHelp to see 
tools to help debug
gpg: DBG: mpi_alloc(160)
gpg: DBG: mpi_alloc_limb_space(160)
gpg: DBG: pubkey_sign: algo=17
...[snipped]...






From dshaw at jabberwocky.com  Thu May 30 20:14:01 2002
From: dshaw at jabberwocky.com (David Shaw)
Date: Tue Oct  7 21:29:10 2003
Subject: malloc problem
In-Reply-To: <A5359632-73E9-11D6-B149-0003936A3BE2@sente.ch>
References: <A5359632-73E9-11D6-B149-0003936A3BE2@sente.ch>
Message-ID: <20020530171410.GG6908@akamai.com>

On Thu, May 30, 2002 at 06:23:59PM +0200, St?phane Corth?sy wrote:
> Hi,
> 
> Running gpg 1.0.7 on MacOS X 10.1.4, I noticed a malloc problems. I type 
> the following command:
> 
> gpg --debug 511 --charset utf-8 --no-force-v3-sigs --armor 
> --notation-data mycode=myvalue --clearsign
> 
> Then I enter my passphrase, the text to sign ("test") and CTRL-D, and 
> there is a (MacOS X specific) malloc warning. Can anyone reproduce the 
> problem on another system having a malloc-protection too (guard pages)?
> Problem is due to the notation-data presence.

This was already fixed.  Thanks for the report though. :)

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From Marc.Mutz at uni-bielefeld.de  Fri May 31 01:10:02 2002
From: Marc.Mutz at uni-bielefeld.de (Marc Mutz)
Date: Tue Oct  7 21:29:10 2003
Subject: charset problem
In-Reply-To: <07E6337B-73E8-11D6-B149-0003936A3BE2@sente.ch>
References: <07E6337B-73E8-11D6-B149-0003936A3BE2@sente.ch>
Message-ID: <200205302342.29857@sendmail.mutz.com>

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

On Thursday 30 May 2002 18:12, St?phane Corth?sy wrote:
<snip>
> Is the following behavior correct?
>
> The file ~/.gnupg/options contains an option "comment" with value "?
> eacute"; file has been saved using UTF8 encoding.
> The file /tmp/test contains same text "? eacute", but in iso-8859-1.
<snip>

The answer is simple: Don't use --comment with anything but US-ASCII 
characters. Comment: is an _ASCII_ armor header. This name alone should 
tell you why what you try is a bad idea.

Marc

- -- 
Marc Mutz <mutz@kde.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE89pzE3oWD+L2/6DgRAn+HAJ4shlewFxf/3RFi2N69npX00Y/6WgCeJ0Xw
VTtAi1qZpPOMjlW9Fv2cuvg=
=u6/t
-----END PGP SIGNATURE-----



From keith at nullify.org  Fri May 31 07:52:01 2002
From: keith at nullify.org (Keith Ray)
Date: Tue Oct  7 21:29:10 2003
Subject: Photo ID viewer under Windows NT
Message-ID: <1022820757.3cf701952790a@mail.nullify.org>

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

I just tried the new method of calling the Photo ID viewer under
Windows.  Unfortunately, unlike system(), CreateProcess() does not get
interpretted through the system shell.  This means that only actual
executables can be run in CreateProcess(), not internal commands.  In
Windows 95/98/Me, "start" is actually start.exe.  Under Windows
NT/2k/XP, "start" is integrated into the shell and CreateProcess() fails
with "No such file or directory".  

You can still use CreateProcess() under NT, but you need to call:

cmd /c start /w %i

However, since 95 uses command.com instead of cmd.exe, this would fail
for those versions.

  -- Keith

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7a-nr1 (Windows 2000) - GPGshell v2.30

iD8DBQE89wGIBxrjkHkmmhIRAgckAJ0UrGhnSBGGEDXw12DHnkTKN07sKgCgidHE
Tu6W6+BlfQo4DoWHfV+YZ5I=
=vjL8
-----END PGP SIGNATURE-----


From dshaw at jabberwocky.com  Fri May 31 08:53:01 2002
From: dshaw at jabberwocky.com (David Shaw)
Date: Tue Oct  7 21:29:10 2003
Subject: Photo ID viewer under Windows NT
In-Reply-To: <1022820757.3cf701952790a@mail.nullify.org>
References: <1022820757.3cf701952790a@mail.nullify.org>
Message-ID: <20020531055358.GB2126@akamai.com>

On Thu, May 30, 2002 at 11:52:37PM -0500, Keith Ray wrote:

> I just tried the new method of calling the Photo ID viewer under
> Windows.  Unfortunately, unlike system(), CreateProcess() does not get
> interpretted through the system shell.  This means that only actual
> executables can be run in CreateProcess(), not internal commands.  In
> Windows 95/98/Me, "start" is actually start.exe.  Under Windows
> NT/2k/XP, "start" is integrated into the shell and CreateProcess() fails
> with "No such file or directory".  
> 
> You can still use CreateProcess() under NT, but you need to call:
> 
> cmd /c start /w %i
> 
> However, since 95 uses command.com instead of cmd.exe, this would fail
> for those versions.

So use the longer form?  I'm not sure what you're getting at
here. "start /w" doesn't work on NT, but neither does qiv or
xloadimage or any other other of the sample viewers.  The whole point
of the photo-viewer option is to set what viewer works for YOU and not
hard-code something in that may not work (or may work but not be what
you wanted: using "start" to read the registry doesn't work very well
if your .jpg viewer is photoshop, for example).

It's possible to use some conditional #defines to change the default
viewer at build time, but to what end?  Most people don't compile
their own win32 binary, and this would make the NT/2k/XP binary
different than 95/98/Me.

Remember: "start /w" is only the default.  If you don't like it (or if
it doesn't work on your system), change it.

If you're arguing that the default should be "cmd /c start /w", then
maybe - but it'll break the default for the 95/98/Me people.  I have
no strong feelings on which platform gets the 'better' default.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


From avbidder at fortytwo.ch  Fri May 31 11:42:01 2002
From: avbidder at fortytwo.ch (Adrian 'Dagurashibanipal' von Bidder)
Date: Tue Oct  7 21:29:10 2003
Subject: charset problem
In-Reply-To: <200205302342.29857@sendmail.mutz.com>
References: <07E6337B-73E8-11D6-B149-0003936A3BE2@sente.ch> 
	<200205302342.29857@sendmail.mutz.com>
Message-ID: <1022834611.25778.32.camel@atlas>

On Thu, 2002-05-30 at 23:42, Marc Mutz wrote:

> The answer is simple: Don't use --comment with anything but US-ASCII 
> characters. Comment: is an _ASCII_ armor header. This name alone should 
> tell you why what you try is a bad idea.

Just curious: is there anything said (rfc, developer opinion, ...) about
the =?charset?x?encoded string?= encoding in armor headers?

cheers
-- vbi


-- 
secure email with gpg            avbidder@fortytwo.ch: key id 0x92082481
                                 avbidder@acter.ch:    key id 0x5E4B731F

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : /pipermail/attachments/20020531/9020e06f/attachment.bin
From chris at netservers.co.uk  Fri May 31 12:02:01 2002
From: chris at netservers.co.uk (Chris Wilson)
Date: Tue Oct  7 21:29:10 2003
Subject: Batch mode
Message-ID: <Pine.LNX.4.44.0205301744240.30657-100000@localhost>

Hi all,

There are a number of operations which are not currently supported in 
batch mode. They include:

- key generation
- key signing
- key deletion

I would be happy to write patches to add this functionality, but my past 
e-mails, suggestions and patches sent to this list have been completely 
ignored. Therefore, I will probably not write the patches unless somebody 
says they are interested. So please tell me if you are.

Cheers, Chris.
-- 
   ___ __     _
 / __// / ,__(_)_  | Chris Wilson -- UNIX Firewall Lead Developer |
/ (_ / ,\/ _/ /_ \ | NetServers.co.uk http://www.netservers.co.uk |
\ _//_/_/_//_/___/ | 21 Signet Court, Cambridge, UK. 01223 576516 |



From wk at gnupg.org  Fri May 31 13:47:02 2002
From: wk at gnupg.org (Werner Koch)
Date: Tue Oct  7 21:29:10 2003
Subject: charset problem
In-Reply-To: <1022834611.25778.32.camel@atlas> (Adrian 'Dagurashibanipal'
 von Bidder's message of "31 May 2002 10:43:31 +0200")
References: <07E6337B-73E8-11D6-B149-0003936A3BE2@sente.ch>
	<200205302342.29857@sendmail.mutz.com>
	<1022834611.25778.32.camel@atlas>
Message-ID: <87bsawd1yj.fsf@alberti.gnupg.de>

On 31 May 2002 10:43:31 +0200, Adrian 'Dagurashibanipal' von Bidder said:

> Just curious: is there anything said (rfc, developer opinion, ...) about
> the =?charset?x?encoded string?= encoding in armor headers?

No.  Please don't use the comment for any real purpose - this is just
a gadget with no real use.  If you want to encode other information
you should either use notation data (which is included in the
signature) or use MIME headers for that.  As you know, the Comment and
all other armor headers are not protected by the signature.


Salam-Shalom,

   Werner





From wagner at tik.ee.ethz.ch  Fri May 31 13:52:01 2002
From: wagner at tik.ee.ethz.ch (Arno Wagner)
Date: Tue Oct  7 21:29:10 2003
Subject: Me "spamming" this list...
In-Reply-To: <E17DdzF-0005CF-00@trithemius.gnupg.org>; from gnupg-devel-request@gnupg.org on Fri, May 31, 2002 at 06:25:42AM +0200
References: <E17DdzF-0005CF-00@trithemius.gnupg.org>
Message-ID: <20020531125315.B10807@tik.ee.ethz.ch>

Dear gnupg-devel list members,

in the last 48 hours (or so) this list has received messages
from my spam-detector about spam being dropped. 

I am sorry about this, please accept my apology!

I think I should explain what happened, so maybe others can 
avoid the mistakes I made: I have a very manual spam filter,
that I maintain by just adding to my .procmailrc. For hard spammers
I just drop the mail, for others I had an auto-reply feature. 
While I was careful all my receipes are restrictive enough not
to be overly trigger-happy, I did not take into account the
possibility for a different kind of error. 

What I effectively did in one match-expression whas replace the
leading "*" with a "$". As a result this rule appearently matched for
every Email that came in. As a consequence every email to me got a
notification about it being spam and dropped, which also happened to
all the messages telling me there was something wrong on my side.

To make things worse, we had an announced partial network outage 
on Wednsday (routing tables cleanup) so I was not suspicous about
not getting any email. I was not at work on Wednsday, so I 
finally found out about the problem when somebody phoned me
Thursday morning. 

At that time I had about 30 messages telling me about the problem
and about 400 Messages from a mail-loop, that happened despite 
my measures to prevent loops.

Lessons learned on my side:

  - Don't send out automatic responses to, if the trigger-
    mechanism has a single point-of-failure!

    For the time being I make that: Don't send out any automated
    responses. 

  - Doing full logging is a very good idea when automatically 
    deleting messages!  

    Because I at least got this right, I did not loose any 
    messages and was able to identify everybody that I needed to
    apologize to.

  - If you screw up, apologize a.s.a.p. to those affected and
    explain what happened!     

  - Look at statistics frequently! 

    My previous set-up gave me one spam-summary per week. That is 
    not enough, now I am getting a daily summary.  

  - Make sure you understand the problem! 

    My mail-loop detection scheme used a field in the header with 
    a magic number. That is fine for every loop that keeps the 
    auto-response somewhere in the replys, but this one list-admin 
    daemon just send me a completely fresh email about not 
    understanding my command. Practical loop detection is obviously
    more complicated than I thought ....

Once again, please accept my apologies for this incident!

Regards,
Arno

-- 
Arno Wagner, Communication Systems Group, ETH Zuerich, wagner@tik.ee.ethz.ch
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
For every complex problem there is an answer that is clear, simple, 
and wrong. -- H L Mencken




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 248 bytes
Desc: not available
Url : /pipermail/attachments/20020531/3c787654/attachment.bin
From wk at gnupg.org  Fri May 31 13:53:01 2002
From: wk at gnupg.org (Werner Koch)
Date: Tue Oct  7 21:29:10 2003
Subject: Batch mode
In-Reply-To: <Pine.LNX.4.44.0205301744240.30657-100000@localhost> (Chris
 Wilson's message of "Fri, 31 May 2002 10:02:13 +0100 (BST)")
References: <Pine.LNX.4.44.0205301744240.30657-100000@localhost>
Message-ID: <877klkd1qb.fsf@alberti.gnupg.de>

On Fri, 31 May 2002 10:02:13 +0100 (BST), Chris Wilson said:

> Hi all,
> There are a number of operations which are not currently supported in 
> batch mode. They include:

> - key generation

There is batch ke generation - see doc/DETAILS.

> - key signing
> - key deletion

This can't be done easily.  You need to present a lot of information
to the user so that he can decide wehther to sign or not.  Those
information vary from key to key and thus it can't be scripted.

We are working on a GPGME interface to do ease it up.  You may have
noticed problems with GPA when you don't use a standard key or use gpg
1.0.7.  This is due to a too simple approach to handle these
operations.

> I would be happy to write patches to add this functionality, but my past 
> e-mails, suggestions and patches sent to this list have been
> completely 

Sorry, That happens from time to time.  There is also the issue that
we need legal papers to include non-trivial patches.


Shalom-Salam,

   Werner



From chris at netservers.co.uk  Fri May 31 14:17:01 2002
From: chris at netservers.co.uk (Chris Wilson)
Date: Tue Oct  7 21:29:11 2003
Subject: Batch mode
In-Reply-To: <877klkd1qb.fsf@alberti.gnupg.de>
Message-ID: <Pine.LNX.4.44.0205311209080.30657-100000@localhost>

Hi Werner and the list,

> There is batch ke generation - see doc/DETAILS.

Sorry, my bad. This looks like what I need.

> This can't be done easily.  You need to present a lot of information
> to the user so that he can decide wehther to sign or not.  Those
> information vary from key to key and thus it can't be scripted.

In our environment the key is generated and immediately imported 
into another keyring and signed. There is no need to verify the identity 
of the key, etc. So it would be very useful for us to be able to sign 
automatically.

What objection is there to batch key deletion?

> We are working on a GPGME interface to do ease it up.  You may have
> noticed problems with GPA when you don't use a standard key or use gpg
> 1.0.7.  This is due to a too simple approach to handle these
> operations.

OK, but from what little I know of GPGME right now, it seems to be a 
powerful and complex API to using GPG. I don't need that, and it's not 
helpful for shell scripts. I just need to be able to automate the commands 
which I can give from the command line anyway.

> Sorry, That happens from time to time.  There is also the issue that
> we need legal papers to include non-trivial patches.

I am about to send in my papers to the FSF for some work I've done on Tar, 
but in any case I think these patches will be small enough that they 
shouldn't pose a legal problem for you. But I leave that to your 
discretion.

Ciao, Chris.
-- 
   ___ __     _
 / __// / ,__(_)_  | Chris Wilson -- UNIX Firewall Lead Developer |
/ (_ / ,\/ _/ /_ \ | NetServers.co.uk http://www.netservers.co.uk |
\ _//_/_/_//_/___/ | 21 Signet Court, Cambridge, UK. 01223 576516 |