From jshayward@pobox.com Mon Oct 1 20:47:08 2001 From: jshayward@pobox.com (Jonathan Hayward -- http://JonathansCorner.com) Date: Mon Oct 1 19:47:08 2001 Subject: gpg initialization Message-ID: <3BB84CCE.6CCBA5C1@pobox.com> --------------E38B76217F7A0792CE6D3082 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Is there any documentation (besides the comments/code) to how gpg initializes? -- Jonathan Hayward jshayward@pobox.com http://JonathansCorner.com (A four dimensional maze, stories, essays, artwork, and other things...) --------------E38B76217F7A0792CE6D3082 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Is there any documentation (besides the comments/code) to how gpg initializes?
-- 
Jonathan Hayward
jshayward@pobox.com
http://JonathansCorner.com
(A four dimensional maze, stories, essays, artwork, and other things...)
  --------------E38B76217F7A0792CE6D3082-- From mbp2@Lehigh.EDU Mon Oct 1 23:15:01 2001 From: mbp2@Lehigh.EDU (mbp2@Lehigh.EDU) Date: Mon Oct 1 22:15:01 2001 Subject: Adding recipients to an encrypted message? Message-ID: <1001967174.3bb8ce46744b5@IMP.Lehigh.EDU> A suggestion for a new feature... the ability to add recipients to an encrypted message. If I have a file or message that's encrypted to me, and I want to give it securely to someone else, it's awkward to have to decrypt the whole thing and then re-encrypt it again to the new person, especially if the file is large. It'd be very useful if I could tell GPG to decrypt the session key using my private key and immediately encrypt it (just the session key) with the new person's public key, and then add a new recipient packet to the message without touching the encrypted message body. This is not only more secure (it's easier to wipe a small decrypted session key from memory than a whole decrypted message), but also faster and more convenient. -- Mike Paul mbp2@lehigh.edu http://www.lehigh.edu/~mbp2/ From wk@gnupg.org Tue Oct 2 00:36:01 2001 From: wk@gnupg.org (Werner Koch) Date: Mon Oct 1 23:36:01 2001 Subject: Adding recipients to an encrypted message? In-Reply-To: <1001967174.3bb8ce46744b5@IMP.Lehigh.EDU> (mbp2@Lehigh.EDU's message of "Mon, 01 Oct 2001 16:12:54 -0400 (EDT)") References: <1001967174.3bb8ce46744b5@IMP.Lehigh.EDU> Message-ID: <878zev3v0j.fsf@alberti.gnupg.de> On Mon, 01 Oct 2001 16:12:54 -0400 (EDT), mbp2 said: > then re-encrypt it again to the new person, especially if the file is large. > It'd be very useful if I could tell GPG to decrypt the session key using my > private key and immediately encrypt it (just the session key) with the new have a look at the options $ gpg --dump-options |grep session --show-session-key --override-session-key The simplest way would be something like this: $ gpg --show-session-key -o foo.txt foo.gpg 2>&1 \ | gpg -e -r key-escrow@privacy.gov | mail solo@u.n.c.l.e And on the u.n.c.l.e site Napoleon could do this: $ gpg --override-session-key extracted_from_mail msg_from_echelon Well you can also use the session key to create a public key encrypted packet and prepend it to the message - however there is no direct support for it in GnuPG. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From mbp2@Lehigh.EDU Tue Oct 2 04:36:01 2001 From: mbp2@Lehigh.EDU (mbp2@Lehigh.EDU) Date: Tue Oct 2 03:36:01 2001 Subject: Adding recipients to an encrypted message? Message-ID: <1001986429.3bb9197d660f9@IMP.Lehigh.EDU> I was thinking of something that would produce an ordinary OpenPGP message that can be decrypted normally to the new recipient... maybe the recipient isn't convinced of the usefulness of cryptography in the first place, or is using commercial PGP so they can't use --override-session-key, or both. In both the GPG documentation and your example, the --show-session key option is described as being meant for key-escrow purposes. I'm talking about the more casual act of forwarding a message to someone. It shouldn't be too hard to add an option... something like "gpg --add-recipient ciphertext.gpg newrecipient@foo.com" which would extract the session key and add a new recipient packet to the message. (I'm submitting to the list without being subscribed so hopefully the threading will work correctly...) -- Mike Paul mbp2@lehigh.edu http://www.lehigh.edu/~mbp2/ From wk@gnupg.org Tue Oct 2 10:54:01 2001 From: wk@gnupg.org (Werner Koch) Date: Tue Oct 2 09:54:01 2001 Subject: Adding recipients to an encrypted message? In-Reply-To: <1001986429.3bb9197d660f9@IMP.Lehigh.EDU> (mbp2@Lehigh.EDU's message of "Mon, 01 Oct 2001 21:33:49 -0400 (EDT)") References: <1001986429.3bb9197d660f9@IMP.Lehigh.EDU> Message-ID: <87vghy32fg.fsf@alberti.gnupg.de> On Mon, 01 Oct 2001 21:33:49 -0400 (EDT), mbp2 said: > described as being meant for key-escrow purposes. I'm talking about the more > casual act of forwarding a message to someone. It shouldn't be too hard to add I can't think of a situation where you want to forward an encrypted message to another recipient without reading the message first. -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From Florian.Weimer@RUS.Uni-Stuttgart.DE Tue Oct 2 16:26:01 2001 From: Florian.Weimer@RUS.Uni-Stuttgart.DE (Florian Weimer) Date: Tue Oct 2 15:26:01 2001 Subject: Adding recipients to an encrypted message? In-Reply-To: <87vghy32fg.fsf@alberti.gnupg.de> (Werner Koch's message of "Tue, 02 Oct 2001 09:51:15 +0200") References: <1001986429.3bb9197d660f9@IMP.Lehigh.EDU> <87vghy32fg.fsf@alberti.gnupg.de> Message-ID: Werner Koch writes: > On Mon, 01 Oct 2001 21:33:49 -0400 (EDT), mbp2 said: > I can't think of a situation where you want to forward an encrypted > message to another recipient without reading the message first. Encrypted mailing lists could be implemented more efficiently if the main message part would not have to be encrypted over and over again. (Because of padding, the reused session key should not be a problem even with RSA, but I'm not sure about that.) -- Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 From pgut001@cs.auckland.ac.nz Tue Oct 2 17:15:01 2001 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) Date: Tue Oct 2 16:15:01 2001 Subject: Adding recipients to an encrypted message? Message-ID: <200110021412.CAA135615@ruru.cs.auckland.ac.nz> Florian Weimer writes: >Werner Koch writes: >>On Mon, 01 Oct 2001 21:33:49 -0400 (EDT), mbp2 said: >>I can't think of a situation where you want to forward an encrypted >>message to another recipient without reading the message first. >Encrypted mailing lists could be implemented more efficiently if the main >message part would not have to be encrypted over and over again. (Because of >padding, the reused session key should not be a problem even with RSA, but I'm >not sure about that.) The S/MIME folks have looked at this problem in some detail over quite some time, there are RFCs/RFC drafts available from the S/MIME WG home page http://www.imc.org/ietf-smime/index.html. (They also have a second home page at http://www.ietf.org/html.charters/smime-charter.html which has a non- overlapping set of drafts, you may need to check there. Try and ignore the fact that the page is shared with drafts on how to do X.400 with S/MIME). Peter. From sosa1004kr@yahoo.co.kr Thu Oct 4 22:43:03 2001 From: sosa1004kr@yahoo.co.kr (ÃÊû°­¿¬) Date: Thu Oct 4 21:43:03 2001 Subject: [ÃÊû°­¿¬ È«º¸] ±× ´©°¡ °¨È÷ Çй®Àº ¾ø¾ú´Ù°í ¿ÜÃÆ´ø°¡? Message-ID: <200110041940.f94Jeard020040@mail.openit.de> PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPGh0 bWw+DQo8aGVhZD4NCjx0aXRsZT6iwCC9xcH2vcTAziDDysO7ILCtv6zIuCCiwDwvdGl0bGU+ DQoNCjxtZXRhIG5hbWU9IkdFTkVSQVRPUiIgY29udGVudD0iTmFtbyBXZWJFZGl0b3IgdjQu MCI+DQo8L2hlYWQ+DQo8Qk9EWT4NCjxQIGFsaWduPWxlZnQ+PEZPTlQgc2l6ZT0yPjxTUEFO IA0Kc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IGZ1Y2hzaWEiPjwvU1BBTj48L0ZPTlQ+PEZP TlQgc2l6ZT0yPjxTUEFOIA0Kc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IGZ1Y2hzaWEiPjxT UEFOIHN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiB3aGl0ZSI+PEZPTlQgDQpzaXplPTE+vsiz 58fPvLy/5C4guru43sDPwLogsK2/rMi4IMiruri4piDAp8fPv6kmbmJzcDsxyLi8uiC43sDP wMy45yC43sDPIMioxuTAzMH2v80gsNS9w8bHv6G8rSANCrz2wf21yLDNwNS0z7TZPC9GT05U PjwvU1BBTj48L1NQQU4+PC9GT05UPjwvUD4NCjxQIGFsaWduPWNlbnRlcj48Rk9OVCBzaXpl PTU+PFNQQU4gc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IGZ1Y2hzaWEiPqLAIL3Fwfa9xMDO IMPKw7sgDQqwrb+syLggosA8L1NQQU4+PC9GT05UPjxGT05UIGNvbG9yPWJsYWNrPjxTUEFO IA0Kc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IHdoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L1NQQU4+PC9GT05UPjwvUD4NCjxQIGFsaWduPWxl ZnQ+PEZPTlQgY29sb3I9YmxhY2s+PFNQQU4gc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IHdo aXRlIj7BpLq4yK0gvcO067+hIMH2wPsgDQrIo7HivcnAzCC4ucC6ILTnvcUgISE8QlI+PEJS PjwvU1BBTj48L0ZPTlQ+PFNQQU4gc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IHdoaXRlIj69 xcH2vcTAziDDysO7IA0Kuau34SCwrb+syLi/oSC01MC7IMPKtOvHz7DtwNogx9W0z7TZLjwv U1BBTj48Rk9OVCBjb2xvcj1uYXZ5PjxTUEFOIA0Kc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6 IHdoaXRlIj48QlI+Jm5ic3A7PC9TUEFOPjwvRk9OVD48L1A+DQo8UCBhbGlnbj1sZWZ0PjxG T05UIGNvbG9yPWJsYWNrPjxTUEFOIHN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiB3aGl0ZSI+ wfax3bHuwfYgsdcgtKmwoSANCrCoyPcgPC9TUEFOPjwvRk9OVD48Rk9OVCBjb2xvcj0jNDAw MDQwPjxTUEFOIA0Kc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IHdoaXRlIj48U1RST05HPsfQ ua7AuiC++L76tNk8L1NUUk9ORz48L1NQQU4+PC9GT05UPjxTUEFOIA0Kc3R5bGU9IkJBQ0tH Uk9VTkQtQ09MT1I6IHdoaXRlIj48Rk9OVCBjb2xvcj1ibGFjaz6w7SANCr/cw8a0+LChPzxC Uj4mbmJzcDs8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9TUEFOPjwvRk9OVD48Rk9O VCBjb2xvcj1ibHVlPjxTUEFOIA0Kc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IHdoaXRlIj7H 0LmuPC9TUEFOPjwvRk9OVD48Rk9OVCBjb2xvcj1ibGFjaz48U1BBTiANCnN0eWxlPSJCQUNL R1JPVU5ELUNPTE9SOiB3aGl0ZSI+wMy29T8gLSA8U1BBTiANCnN0eWxlPSJCQUNLR1JPVU5E LUNPTE9SOiB3aGl0ZSI+PC9TUEFOPjxGT05UIGNvbG9yPWJsYWNrIHNpemU9Mj48U1BBTiAN CnN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiB3aGl0ZSI+u+e5sMDHIMDMxKG/zSC6u8H6wLsg sdS47cfPtMIgDQqwzcDMtNkuPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyANCrmwwfrAxyDD1rzStNzAp8DOIL/4wNouLiAmbmJzcDu/+MDa ILzTwMcgwPzA2rTCILmrvbwgv6GzysH2t84gtbm+xrChsO0gwNa0wrChPzwvU1BBTj48L1NQ QU4+PC9GT05UPjwvUD4NCjxQIGFsaWduPWxlZnQ+PEZPTlQgY29sb3I9Ymx1ZT48U1BBTiAN CnN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiB3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7vcXH0DwvU1BBTj48L0ZPTlQ+PEZPTlQgDQpjb2xvcj1ibGFjaz48U1BBTiBzdHlsZT0i QkFDS0dST1VORC1DT0xPUjogd2hpdGUiPsDMtvU/IC0gPFNQQU4gDQpzdHlsZT0iQkFDS0dS T1VORC1DT0xPUjogd2hpdGUiPjwvU1BBTj48Rk9OVCBjb2xvcj1ibGFjayBzaXplPTI+PFNQ QU4gDQpzdHlsZT0iQkFDS0dST1VORC1DT0xPUjogd2hpdGUiPr3Fv6EgtOvH2CCz7cfPtMIg DQrH0LmuPz8/Pz88QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7sde3syANCr3FwMcgurvB+sC6IA0Kuau++cDOsKE/PEJSPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxTUEFOIA0Kc3R5bGU9IkJBQ0tHUk9VTkQtQ09M T1I6IHdoaXRlIj48L1NQQU4+PC9GT05UPjxGT05UIHNpemU9Mj48U1BBTiANCnN0eWxlPSJC QUNLR1JPVU5ELUNPTE9SOiB3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7vcXAuyC+y8H2IA0KuPjHz7TCtaUgvu62u7DUIL3Fv6EgtOvH2CCz7cfS ILz2IMDWtMKwoT88L1NQQU4+PC9TUEFOPjwvRk9OVD48L1A+DQo8UCBhbGlnbj1sZWZ0PjxG T05UIGNvbG9yPWJsYWNrPjxTUEFOIHN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiB3aGl0ZSI+ x9C5rrD6IL3FwLsgDQrD37G4x8+0wiA8L1NQQU4+PC9GT05UPjxGT05UIGNvbG9yPWJsdWU+ PFNQQU4gc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IHdoaXRlIj7AzrCjwLogsPq/rCANCr7u trIgwbjA5zwvU1BBTj48L0ZPTlQ+PEZPTlQgY29sb3I9YmxhY2s+PFNQQU4gDQpzdHlsZT0i QkFDS0dST1VORC1DT0xPUjogd2hpdGUiPsDOsKE/PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO7bHIA0KPC9TUEFOPjwvRk9OVD48Rk9OVCBjb2xvcj1i bHVlPjxTUEFOIHN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiB3aGl0ZSI+wM6wo8DHILq7wfqw +iANCrzTvLo8L1NQQU4+PC9GT05UPjxGT05UIGNvbG9yPWJsYWNrPjxTUEFOIHN0eWxlPSJC QUNLR1JPVU5ELUNPTE9SOiB3aGl0ZSI+wLogsPq/rCANCr7utrDH0bChPzxCUj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDvAzrCjwMcgDQq757DtwMcgxse0 3CCx4sHYwLogsPq/rCDBpMiux9EgsM3AzrChPyA8QlI+Jm5ic3A7PC9TUEFOPjwvRk9OVD48 L1A+DQo8UCBhbGlnbj1sZWZ0PjxGT05UIGNvbG9yPWJsYWNrPjxTUEFOIHN0eWxlPSJCQUNL R1JPVU5ELUNPTE9SOiB3aGl0ZSI+wfax3bHuwfYgwfi4rrbzsO0gDQq5z77uv9S0+CChwaHB ocEgJm5ic3A7PC9TUEFOPjwvRk9OVD48Rk9OVCBjb2xvcj1yZWQ+PFNQQU4gDQpzdHlsZT0i QkFDS0dST1VORC1DT0xPUjogd2hpdGUiPrv9ISDA2iEgx8ohILjqITwvU1BBTj48L0ZPTlQ+ PC9QPg0KPFAgYWxpZ249bGVmdD48Rk9OVCBjb2xvcj1ibGFjaz48U1BBTiBzdHlsZT0iQkFD S0dST1VORC1DT0xPUjogd2hpdGUiPjIxvLyx4iC8vLDowMcgDQrD1sO3tNwgudnAzL/AILD6 x9DA2rXpv6EgwMfH2CCx17DNwMwgsMXB/sDTwMwgueDH9MH2sO0sIDxCUj48QlI+PFNQQU4g DQpzdHlsZT0iQkFDS0dST1VORC1DT0xPUjogd2hpdGUiPjwvU1BBTj48Rk9OVCBjb2xvcj1i bGFjayBzaXplPTI+PFNQQU4gDQpzdHlsZT0iQkFDS0dST1VORC1DT0xPUjogd2hpdGUiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0gDQrAr8D8 x9DA2rXpIDogMjCz4rO7IMDOsKMgvPa47SA0MLvsIL3DtOu/wrTZIC0gvbrG98P3IMG2vLEg MTk5Mi4gOS4gDQoxOS48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7wdfAvcC6IA0KwNq/rL+hIL+qx+DHz7TC IA0KsM3AzLTZLjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDvAzrCjwLogDQq4u8fPwNq46SCx1yDA2sO8sKEg wNq1vyC6uLz2IA0KwNrEocDMtNkuPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyiz67qnIA0KyK3H0LvzILz2u/PA2sDOILnMsbnAxyC288DMs8q9uiDG+ri1ILna u+cpPC9TUEFOPjwvU1BBTj48L0ZPTlQ+PC9QPg0KPFAgYWxpZ249bGVmdD48Rk9OVCBjb2xv cj1ibGFjayBzaXplPTI+PFNQQU4gDQpzdHlsZT0iQkFDS0dST1VORC1DT0xPUjogd2hpdGUi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0gDQq6 0rfOutK75yDAr8D8wNogud+w3yC538elIDogucyxuSC3zr26ILGzvPYgJm5ic3A7MTk5ObPi IDe/+SA1wM88L1NQQU4+PC9GT05UPjwvUD4NCjxQIGFsaWduPWxlZnQ+PEZPTlQgY29sb3I9 YmxhY2sgc2l6ZT0yPjxTUEFOIA0Kc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IHdoaXRlIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstIA0Kv+y4 riC49iC807+hIL+1u/3AuyCx4r7vx8+0wiC8vMb3tenAzCANCsDWtNk8QlI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0OyANCjE5OTGz4iA4v/kgucyxuSBBQkMg VFYguea828DHILrSu+e/oSCw/MfRIFRWIMXkt9AmZ3Q7PEJSPjxTUEFOIA0Kc3R5bGU9IkJB Q0tHUk9VTkQtQ09MT1I6IHdoaXRlIj48L1NQQU4+PEZPTlQgY29sb3I9YmxhY2s+PFNQQU4g DQpzdHlsZT0iQkFDS0dST1VORC1DT0xPUjogd2hpdGUiPjxCUj48L1NQQU4+PC9GT05UPjxG T05UIGNvbG9yPXJlZD48U1BBTiANCnN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiB3aGl0ZSI+ PC9TUEFOPjwvRk9OVD48U1RST05HPjxGT05UIHNpemU9Mz48U1BBTiANCnN0eWxlPSJCQUNL R1JPVU5ELUNPTE9SOiB3aGl0ZSI+vLHB+CDDt7TcIMfQua7AuiC/z8D8IMH4uK64piDD37G4 IMXrx9ggutK3zrrSu+co3dXW1d3V3t0puKYguPHHpbfOIA0Kud/A/DwvU1BBTj48Rk9OVCBj b2xvcj1ibGFjaz48U1BBTiBzdHlsZT0iQkFDS0dST1VORC1DT0xPUjogd2hpdGUiPrXHsO0g DQrA1r3AtM+02S48L1NQQU4+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9TVFJPTkc+PC9QPg0K PFAgYWxpZ249bGVmdD48Rk9OVCBzaXplPTM+PFNUUk9ORz48U1BBTiBzdHlsZT0iQkFDS0dS T1VORC1DT0xPUjogd2hpdGUiPrq7ILCtv6zIuLTCIA0KutK3zrrSu+cgsdcgwaS787+hvK0g udm287q7PC9TUEFOPjxGT05UIGNvbG9yPXJlZD48U1BBTiBzdHlsZT0iQkFDS0dST1VORC1D T0xPUjogd2hpdGUiPiANCjwvU1BBTj48L0ZPTlQ+PC9TVFJPTkc+PC9GT05UPjxTUEFOIHN0 eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiB3aGl0ZSI+PEZPTlQgDQpzaXplPTM+PFNUUk9ORz6/ z8D8x9Egx9C5riwgwb6xsywgsPrH0C4uLi7AuyAmbmJzcDu/qbevutC16b+hsNQgwPzH2CC1 5biusO3A2iDH1bTPtNkuPC9TVFJPTkc+PC9GT05UPiANCjwvU1BBTj48L1A+DQo8UCBhbGln bj1sZWZ0PjxGT05UIGNvbG9yPXJlZD48U1BBTiBzdHlsZT0iQkFDS0dST1VORC1DT0xPUjog d2hpdGUiPjxGT05UIA0KY29sb3I9IzAwMDAwMD7B+MPrwPvAzLjnIL+tuLAguLbAvcC4t84g wfa9xMC7ILClsbjHz7TCIMDMtenAxyC4uLOywMcgvcOwo8DMILXHvcOx5iANCrnZtvi0z7TZ LjwvRk9OVD48QlI+PC9QPjwvU1BBTj48L0ZPTlQ+DQo8UCBhbGlnbj1sZWZ0PjxGT05UIGNv bG9yPWJsYWNrPjxTUEFOIHN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiBhcXVhIj7AzyANCiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO73DIDogMjAwMbPiIDEwv/kgNsDPIL/AyMQg M73DPC9TUEFOPjwvRk9OVD48L1A+DQo8UCBhbGlnbj1sZWZ0PjxGT05UIGNvbG9yPWJsYWNr PjxTUEFOIHN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiBhcXVhIj7A5SANCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO7zSIDogus7DtSC9w7nOIMi4sPwgvNKwrbTnPC9TUEFOPjwv Rk9OVD48L1A+DQo8UCBhbGlnbj1sZWZ0PjxGT05UIGNvbG9yPWJsYWNrPjxTUEFOIA0Kc3R5 bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IHdoaXRlIj48L1NQQU4+PC9GT05UPiZuYnNwOzwvUD48 L0ZPTlQ+PC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9GT05UPg0KPC9CT0RZPg0KPC9odG1sPg0K From jan@intevation.de Fri Oct 5 15:07:01 2001 From: jan@intevation.de (Jan-Oliver Wagner) Date: Fri Oct 5 14:07:01 2001 Subject: ANN: Sphinx (S/MIME, X.509) project for MUAs (KMail, mutt) Message-ID: <20011005140441.B14526@intevation.de> Dear list, we are happy to announce that the German "Bundesamt für Sicherheit in der Informationstechnik" (Federal Agency for IT Security, BSI) contracted us (Intevation, Klarälvdalens Datakonsult and g10 Code) to make sure that Free Software for their email security standard Sphinx will be created. Sphinx basically consists of S/MIME, a PKIX compatible X.509 profile, together with certificate revocation lists (CRLs) based on LDAP. The code developed will be modular allowing inclusion in several MUAs released under the GNU GPL. Part of the contract with the BSI is the inclusion in mutt and KMail. The initial project pages can be reached from the URL below. We wanted to get the good news out to you as fast as possible. Expect more information to get released on the website or on the corresponding mailing lists. We plan to do the development in an open manner suitable for Free Software projects. We want to handle the project in a way that it will leverage and add to the work of other developers and ask for your collaboration. The BSI pays us to ensure that their specs are followed precisely and the result passes strict tests. This is the first time the BSI contracts for Free Software development and the experiences they make will be important. We will demonstrate the power of commercial Free Software. www.gnupg.org/aegypten -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From bre@klaki.net Fri Oct 5 18:50:02 2001 From: bre@klaki.net (Bjarni R. Einarsson) Date: Fri Oct 5 17:50:02 2001 Subject: Strange problem with GnuPG 1.0.4 encrypted data Message-ID: <20011005154830.F15179@klaki.net> Hello, I have a system which GPG encrypts and signs files and mails them from one machine to another, where they are automatically decrypted and the signatures verified using a perl program. Last night a file was transferred which appeared to have a valid signature, but then couldn't be decrypted. Gnupg sent the following message to stderr: gpg: Warning: using insecure memory! gpg: encrypted with 1024-bit ELG-E key, ID FAFF94B3, created 2001-09-20 [snip] gpg: Signature made Thu Oct 4 20:45:46 2001 GMT using DSA key ID 327144DC gpg: Good signature from "[snip]" 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: B083 585B 8675 0058 5113 0F98 FA17 F199 3271 44DC gpg: [don't know]: invalid packet (ctb=14) The file was encrypted on a dual PIII 800Mhz machine using GnuPG 1.0.4 as distributed with RedHat Linux 7.1. I tried decrypting it both with GnuPG 1.0.4 and 1.0.6 (RH 7.1 update package), with the same results. I haven't been able to reproduce this problem yet, but since I'm creating and sending dozens of messages like this every day (usually without any problems) I rather expect it to manifest itself again sooner or later. My question is whether any bugs were found in GnuPG 1.0.4 which could cause this kind of bizarre failure, or whether I should start worrying about hardware problems. Also, am I correct in assuming that since the signature was OK, that I can rule out any transmission errors as the cause of this and focus on the creation of the encrypted file? If you developers feel this is a bug and that it would help to examine the file in question I have no problems sharing it and the necessary keys with you - I'm currently just testing this setup and regenerating my keys would be no big deal. Please CC: any replies directly to me, as I'm not subscribe to this list - and please forgive me if I overlooked a more appropriate venue for this message. Thanks! -- Bjarni R. Einarsson PGP: 02764305, B7A3AB89 bre@klaki.net -><- http://bre.klaki.net/ Check out my open-source email sanitizer: http://mailtools.anomy.net/ From jpg@rcom.com.ar Fri Oct 12 21:48:01 2001 From: jpg@rcom.com.ar (Juan Pablo =?ISO-8859-1?Q?Gim=E9nez?=) Date: Fri Oct 12 20:48:01 2001 Subject: gnupg Message-ID: <1002912389.10546.9.camel@kang.oficina.rcom.com.ar> --=-pTgFCmnR2fd7e/Nxvb5l Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi! I have a problem with the option "--with-colons" and --list-keys or --fingerprint, if i don't use it, gpg print my last name "Gim=E9nez" with the "=E9", but if I put with-colons insted of "=E9" gpg prints "=C3=A9"... = So here is the patch to fix it... ------------------------------------------------------------------------ ________________________________________________________________________ --- gnupg-1.0.6/g10/keylist.c Sun May 27 11:31:07 2001 +++ gnupg-1.0.6_rcom/g10/keylist.c Fri Oct 12 11:42:15 2001 @@ -482,8 +482,8 @@ printf("uid:%c::::::::", trustletter); } } - print_string( stdout, node->pkt->pkt.user_id->name, - node->pkt->pkt.user_id->len, ':' ); + print_utf8_string( stdout, node->pkt->pkt.user_id->name, + node->pkt->pkt.user_id->len); putchar(':'); if (any) putchar('\n'); ________________________________________________________________________ ------------------------------------------------------------------------- Chausesssssssssss Juan Pablo.... --=-pTgFCmnR2fd7e/Nxvb5l Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA7xzqFChXsK9PY/SsRAnkSAKCYjyqImAW+y7bs/AO79kIIQhs8oACePYXD lNsurU8tCaAj8V+uVZZkpoE= =9+Yx -----END PGP SIGNATURE----- --=-pTgFCmnR2fd7e/Nxvb5l-- From redbird@rbisland.cx Sun Oct 14 08:24:02 2001 From: redbird@rbisland.cx (Gordon Worley) Date: Sun Oct 14 07:24:02 2001 Subject: Goodbye 4th Amendment Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 http://arstechnica.com/wankerdesk/01q4/usa-act/usa-act.html Well, as some of you may already know, I and some of my fellow developers no longer have our 4th Amendment rights (protection from search and seizure for those of you who live outside the US). I don't know what the immediate effects will be for the project, other than that I may have to make sure binary releases are done all in one sitting use a fresh download of the source (may seem a little silly, but I'd rather be silly than release binaries with bad stuff in them). If you read the story on how this got passed, similar procedures could see anti-crypto laws passed through, though I think after this it will be some time before the House will stand for this. - -- 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 -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use Comment: keyserver http://pgpkeys.mit.edu:11371 iQA/AwUBO8kg627zd/e707ADEQKEZgCg4ouaFNX6ssrkDwLZzPJcdfRVQ2UAoJJL +v6iHEybHuLI+UkBKAlc/VhG =tpGT -----END PGP SIGNATURE----- From redbird@rbisland.cx Sun Oct 14 08:33:01 2001 From: redbird@rbisland.cx (Gordon Worley) Date: Sun Oct 14 07:33:01 2001 Subject: Goodbye 4th Amendment In-Reply-To: References: Message-ID: At 1:20 AM -0400 10/14/01, Gordon Worley wrote: Sorry, folks, that was supposed to go to the Mac GPG developer's list. -- 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 dshaw@jabberwocky.com Sun Oct 14 20:28:02 2001 From: dshaw@jabberwocky.com (David Shaw) Date: Sun Oct 14 19:28:02 2001 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <20011014131040.B8616@akamai.com>; from dshaw@jabberwocky.com on Sun, Oct 14, 2001 at 01:10:40PM -0400 References: <01101218054502.01491@mexicali.sito.saic.com> <20011014131040.B8616@akamai.com> Message-ID: <20011014132552.C8616@akamai.com> --bCsyhTFzCvuiizWE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 14, 2001 at 01:10:40PM -0400, David Shaw wrote: > At the moment, GnuPG (and PGP too) mark all signatures[1] as "I'm not > going to say". I think I feel a patch coming on.. Patch: http://www.jabberwocky.com/crypto/gnupg/patch.gnupg-1.0.6.dms.sigclass.1 Before you sign, GnuPG will prompt you for which level of certification you want to use. Answer "?" for an explanation of the different levels. This also changes key listings (in --edit-key and --list-sigs) to show which certification level was used in making the signature. No claim made as to how well it was checked: sig 3CB3B415 2001-10-14 David M. Shaw Key was not checked at all: sig 1 3CB3B415 2001-10-14 David M. Shaw Key was checked casually: sig 2 3CB3B415 2001-10-14 David M. Shaw Key was checked extensively: sig 3 3CB3B415 2001-10-14 David M. Shaw Comments welcome. David --=20 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 --bCsyhTFzCvuiizWE 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 iQEVAwUBO8nKoIccwqs8s7QVAQGcYgf/RL8fuO32MEUzi1sgVpOeayp915CCYOBo 7IrjMIerNXzNSmrDhoBTvEUxCMBSILxlbrdgY+aWDBwRhO5BS3W2wkhz/Ioovubo LV8O52aK3jlDjhZX2Q/RGPcLD9mCrgsgbBbFBcrF435Iz+WtoPCtcTJiThLLyja6 XlfTqdMO4ClqDQEoOMJX82Ihneb2j8bgdCRfMiRR5LX8DPQkn9rZUMf8vCufKaPB 8eRJPuBxV1aHXiva0TGzBXUxbPe/IG15gqmKFZiLsiV0Oarh/bvzs6ouTDZxJYIr dax0FCp+QjC+qC6Fox+nyiq+Lhoxb7wvSXyFm3YU0IKe++9Knb+C+g== =9F+1 -----END PGP SIGNATURE----- --bCsyhTFzCvuiizWE-- From broonie@sirena.org.uk Mon Oct 15 01:14:01 2001 From: broonie@sirena.org.uk (Mark Brown) Date: Mon Oct 15 00:14:01 2001 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <20011014132552.C8616@akamai.com> References: <01101218054502.01491@mexicali.sito.saic.com> <20011014131040.B8616@akamai.com> <20011014132552.C8616@akamai.com> Message-ID: <20011014231203.B1666@tardis.ed.ac.uk> On Sun, Oct 14, 2001 at 01:25:52PM -0400, David Shaw wrote: > sig 1 3CB3B415 2001-10-14 David M. Shaw > sig 2 3CB3B415 2001-10-14 David M. Shaw > sig 3 3CB3B415 2001-10-14 David M. Shaw It would be nice if these could be presented more clearly. I can't actually suggest a clearer way off-hand, mind you. Also, it would be nice if there were no space between the "sig" and the digit as in current output. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." From dshaw@jabberwocky.com Mon Oct 15 02:04:01 2001 From: dshaw@jabberwocky.com (David Shaw) Date: Mon Oct 15 01:04:01 2001 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <20011014231203.B1666@tardis.ed.ac.uk>; from broonie@sirena.org.uk on Sun, Oct 14, 2001 at 11:12:04PM +0100 References: <01101218054502.01491@mexicali.sito.saic.com> <20011014131040.B8616@akamai.com> <20011014132552.C8616@akamai.com> <20011014231203.B1666@tardis.ed.ac.uk> Message-ID: <20011014190116.F8616@akamai.com> --ylS2wUBXLOxYXZFQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 14, 2001 at 11:12:04PM +0100, Mark Brown wrote: > On Sun, Oct 14, 2001 at 01:25:52PM -0400, David Shaw wrote: >=20 > > sig 1 3CB3B415 2001-10-14 David M. Shaw > > sig 2 3CB3B415 2001-10-14 David M. Shaw > > sig 3 3CB3B415 2001-10-14 David M. Shaw >=20 > It would be nice if these could be presented more clearly. I can't > actually suggest a clearer way off-hand, mind you. Heh. I had the same thought. I thought about using letters, but it was even worse. At least numbers have the advantage of making a "3" clearly higher than a "2". > Also, it would be > nice if there were no space between the "sig" and the digit as in > current output. Try a --check-sigs. That space is taken for the sig status character. David --=20 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 --ylS2wUBXLOxYXZFQ 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 iQEVAwUBO8oZPIccwqs8s7QVAQF7VQf6A9OtLvAa0biDYsvsE+AEzKRid3epOOue P+4RbAkxHEAByrTY1c2j3zwMDQ2YrAchBaNGYhMQx5EHZf9vy+2A9IR1nCbmtrUP ezC5DiMZwzTGhg//dyoJRz8MPZvvARhPMHG1139V7ru4c0m0RoPft7qLYSXd0w90 yXZA6+jj8vCCZ+ags0nf2ucdIw+/uqasBGiY+8Jwrnt5H1QrglWFZmV4rKzUPoHu xl7xzTCOnY33e2nMWdZbKMoyh+D07eys/K24cT25pxGOql96WVwifL42pEocrKNx 4296EtUhxaV0uKMIHJYe9rGGES0Hs19EN1tEFbZ6bI2M+FwRp6YthQ== =2Y6T -----END PGP SIGNATURE----- --ylS2wUBXLOxYXZFQ-- From broonie@sirena.org.uk Mon Oct 15 02:26:01 2001 From: broonie@sirena.org.uk (Mark Brown) Date: Mon Oct 15 01:26:01 2001 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <20011014190116.F8616@akamai.com> References: <01101218054502.01491@mexicali.sito.saic.com> <20011014131040.B8616@akamai.com> <20011014132552.C8616@akamai.com> <20011014231203.B1666@tardis.ed.ac.uk> <20011014190116.F8616@akamai.com> Message-ID: <20011015002427.E1666@tardis.ed.ac.uk> --EY/WZ/HvNxOox07X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 14, 2001 at 07:01:16PM -0400, David Shaw wrote: > > Also, it would be > > nice if there were no space between the "sig" and the digit as in > > current output. > Try a --check-sigs. That space is taken for the sig status character. That's what I was thinking of :-) . At present there's no space before any extra data on the type of entity being listed. With your patch this would change. Not that one ought to be attempting machine parsing of the output of anything not --with-colons, but anyway. --=20 "You grabbed my hand and we fell into it, like a daydream - or a fever." --EY/WZ/HvNxOox07X 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 iD8DBQE7yh6qJ2Vo11xhU60RAnblAJ47gylietHVnZJvJvRWrqEkxWM/0ACfer1b 4fesK9hetflxR/+4vt72qEg= =1nxN -----END PGP SIGNATURE----- --EY/WZ/HvNxOox07X-- From dshaw@jabberwocky.com Mon Oct 15 05:48:01 2001 From: dshaw@jabberwocky.com (David Shaw) Date: Mon Oct 15 04:48:01 2001 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <20011015002427.E1666@tardis.ed.ac.uk>; from broonie@sirena.org.uk on Mon, Oct 15, 2001 at 12:24:27AM +0100 References: <01101218054502.01491@mexicali.sito.saic.com> <20011014131040.B8616@akamai.com> <20011014132552.C8616@akamai.com> <20011014231203.B1666@tardis.ed.ac.uk> <20011014190116.F8616@akamai.com> <20011015002427.E1666@tardis.ed.ac.uk> Message-ID: <20011014224503.B21134@akamai.com> --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 15, 2001 at 12:24:27AM +0100, Mark Brown wrote: > On Sun, Oct 14, 2001 at 07:01:16PM -0400, David Shaw wrote: >=20 > > > Also, it would be > > > nice if there were no space between the "sig" and the digit as in > > > current output. >=20 > > Try a --check-sigs. That space is taken for the sig status character. >=20 > That's what I was thinking of :-) . At present there's no space before > any extra data on the type of entity being listed. With your patch this > would change. Not that one ought to be attempting machine parsing of > the output of anything not --with-colons, but anyway. Ah, I understand now. Hmm. It's easy enough to move it over by one if there is no sig status, but don't you think that would make it harder to read rather than easier? The eye wouldn't be able to just look in the same place each time. I'm also toying with a patch to show various informative flags in that area (an "L" for a local signature, a "P" for a policy URL, "N" for a notation, etc). David --=20 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 --2oS5YaxWCcQjTEyO 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 iQEVAwUBO8pNr4ccwqs8s7QVAQHwuwgAiS1fuvi71XuSZclvvkL/tKbZtZyGpW0t yAvzNk4+AmXdeXKqFmz/sIsZe49bix2g7w/WXvKyRWflGobJd1Qk+z3CMP1yBRJy hAS41PTFuRYmixB8tjpWVdT0e75qP9x2bLBFgpsJH1uXlBzk54FkBEF8w6u/krHv s2OwOIJpmHpyPcz+08bjEzU0yd7J5OKo1PSAfehN7QxTZBle0xh4kEWIG8hR37ms mzFqyF93INdJjWXTfwdfLD65L+z+h3a/2ZNv3Ha0MHVVbJWVIUi0j9aXTr8gqPkz mjZKMUD4FyYCu5HfmTIleI9vAbBuvoF7+BojBGr1y9qRQz8nldogww== =DbG4 -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO-- From dshaw@jabberwocky.com Tue Oct 16 00:38:02 2001 From: dshaw@jabberwocky.com (David Shaw) Date: Mon Oct 15 23:38:02 2001 Subject: Sig classification, version 2 Message-ID: <20011015173637.B4515@akamai.com> Here's version 2 of the sig classification patch I sent in yesterday (thanks for the comments, everyone). It contains everything that was in version 1, with some better help text, and it also shows a few other pieces of information about the signature: 1-3 == amount of verification in the signature (just like before) L == local signature (e.g. made by "--lsign-key"). R == signature is non-revocable. P == a policy URL is attached to this signature. N == a notation is attached to this signature. You can use the --show-policy-url and --show-notation options to display the policy or notation (in a --list-sigs or --edit/check). There is also a --no-show-policy-url and --no-show-notation for the folks who like to override their config file on occasion. --fast-list-mode disables everything except the 1-3 levels of verification (which don't cost anything to retrieve). http://www.jabberwocky.com/crypto/gnupg/patch.gnupg-1.0.6.dms.sigclass.2 Comments welcome. 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 redbird@rbisland.cx Tue Oct 16 06:03:01 2001 From: redbird@rbisland.cx (Gordon Worley) Date: Tue Oct 16 05:03:01 2001 Subject: GPGME.framework Beta 0.2.3 Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Okay, now this message is supposed to show up on this list. ;-) At the Mac GPG project we've released GPGME.framework Beta 0.2.3. This should work on any OpenStepish environment, like GNUStep and Mac OS X. This beta is not a final release and is still missing a few features (use the source, I'll compile release notes when I have time), but there's enough there to get some stuff done. Feel free to beat it around and find any bugs. You can get Beta 0.2.3 here: http://sourceforge.net/project/showfiles.php?group_id=20789&release_id=57202 or just grab the latest out of the Mac GPG CVS tree. For more info on that and the project in general, visit: http://macgpg.sourceforge.net/ - -- 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 -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use Comment: keyserver http://pgpkeys.mit.edu:11371 iQA/AwUBO8ui3m7zd/e707ADEQL6ZQCgymipUUkThn1e+NFvJm+2bEc1Yh4AnRt4 J19AWLt+ZoLqJFAT6uYTGir6 =uniR -----END PGP SIGNATURE----- From mwy-gpg41@the-youngs.org Tue Oct 16 18:09:02 2001 From: mwy-gpg41@the-youngs.org (Michael Young) Date: Tue Oct 16 17:09:02 2001 Subject: Re; Sig classification (was Re: discussion on increasing amount of gpg signatures...) References: Message-ID: <003301c15654$23c8fa60$dfc32609@transarc.ibm.com> -----BEGIN PGP SIGNED MESSAGE----- > Before you sign, GnuPG will prompt you for which level of > certification you want to use. Answer "?" for an explanation of the > different levels. Excellent! A couple of months ago, I built a command-line switch to do this, but didn't get around to posting it. (When I looked back through the mailing list archives, it appeared that signature types were an unpopular idea at some past OpenPGP meetings.) How would you feel about adding a command-line option? As it stands, batch operations get a "generic" signature. I used "--sig-type" in my patch. I could recreate it against yours if you're interested. To make good use of these additional validity levels, the trust model really should understand them. For example, I might fully trust type-3 signatures from "John Smith", partially trust his type-2 signatures, and not trust any type-1. But that's for another day... I'm glad to see the first step. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQEVAwUBO8xM32NDnIII+QUHAQH52gf9Gmd7v524TaY+qJo9UhX8aG4naq69dn/b M+79JQj68xLpeWOVDtKFqSWVSOWcVBA2tiW6+JvZaJ9a5AAmfsk4yie3lQpS2Srp 9wmye2hm/y9CNfHD58PLiUYUlzWDhAj2V3+OZntkC7w9FWMRX3hz+9YCQ5XqpApj 59V5OjWV9XNgB4TkCvCEfGiY8dhJ9BMFBnQzYKvQoffsxVZdgoDK3x9Em+8OFLIw IeiIea6b3+AizaYQxUhAywxE6fdw0gX+gHP7I9Gxb0mZwLD//PY+jVGAW6QVvLAi l2lonJ6e1V5KuZpgNKzT1XK95w8/jzNZhstaEjOd+To4rnRYsYirRw== =i6n2 -----END PGP SIGNATURE----- From gnupg@lists.colondot.net Tue Oct 16 18:51:01 2001 From: gnupg@lists.colondot.net (Matthew Byng-Maddick) Date: Tue Oct 16 17:51:01 2001 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <003301c15654$23c8fa60$dfc32609@transarc.ibm.com>; from mwy-gpg41@the-youngs.org on Tue, Oct 16, 2001 at 11:06:30AM -0400 References: <003301c15654$23c8fa60$dfc32609@transarc.ibm.com> Message-ID: <20011016164931.A98387@colon.colondot.net> On Tue, Oct 16, 2001 at 11:06:30AM -0400, Michael Young wrote: > To make good use of these additional validity levels, the trust > model really should understand them. For example, I might > fully trust type-3 signatures from "John Smith", partially > trust his type-2 signatures, and not trust any type-1. > But that's for another day... I'm glad to see the first step. If you do this, you have to trust that he will choose the correct type of signature to sign with. MBM -- Matthew Byng-Maddick http://colondot.net/ From broonie@sirena.org.uk Tue Oct 16 19:37:02 2001 From: broonie@sirena.org.uk (Mark Brown) Date: Tue Oct 16 18:37:02 2001 Subject: Re; Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <003301c15654$23c8fa60$dfc32609@transarc.ibm.com> References: <003301c15654$23c8fa60$dfc32609@transarc.ibm.com> Message-ID: <20011016173439.G10896@tardis.ed.ac.uk> On Tue, Oct 16, 2001 at 11:06:30AM -0400, Michael Young wrote: > To make good use of these additional validity levels, the trust > model really should understand them. For example, I might > fully trust type-3 signatures from "John Smith", partially > trust his type-2 signatures, and not trust any type-1. > But that's for another day... I'm glad to see the first step. There are also trusted introducer signatures (which are implemented by NAI PGP). -- "You grabbed my hand and we fell into it, like a daydream - or a fever." From dshaw@jabberwocky.com Wed Oct 17 00:15:01 2001 From: dshaw@jabberwocky.com (David Shaw) Date: Tue Oct 16 23:15:01 2001 Subject: Re; Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <003301c15654$23c8fa60$dfc32609@transarc.ibm.com>; from mwy-gpg41@the-youngs.org on Tue, Oct 16, 2001 at 11:06:30AM -0400 References: <003301c15654$23c8fa60$dfc32609@transarc.ibm.com> Message-ID: <20011016171254.I667@akamai.com> --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 16, 2001 at 11:06:30AM -0400, Michael Young wrote: > > Before you sign, GnuPG will prompt you for which level of > > certification you want to use. Answer "?" for an explanation of the > > different levels. >=20 > Excellent! A couple of months ago, I built a command-line switch > to do this, but didn't get around to posting it. (When I looked > back through the mailing list archives, it appeared that signature > types were an unpopular idea at some past OpenPGP meetings.) >=20 > How would you feel about adding a command-line option? As it > stands, batch operations get a "generic" signature. I used > "--sig-type" in my patch. I could recreate it against yours > if you're interested. Good idea. I've added it to v3 of the patch. The command is --default-sig-class, and it takes a number from 0-3. If you set a default sig class in your options file, you can use --no-default-sig-class to override it back to 0. The menu that pops up when key signing will reflect the new default. Also added: * 'If you don't know what the right answer is, answer "0"' message * minor fix to notations - they should be printed as UTF8. http://www.jabberwocky.com/crypto/gnupg/patch.gnupg-1.0.6.dms.sigclass.3 David --=20 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 --ibTvN161/egqYuK8 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 iQEVAwUBO8yi1occwqs8s7QVAQE8XQf+JNjMSZiKbYP4YGVONoOAJLALIoym8AwN 9khnCVE//UOItw8uczxmQLE/FH/qvE3oXASyNPc9THTK0hCAkkAp3OkJ8tWprc6w TNNkLNP2GJyWNHwrTuHnbaN6KmCQ3KkQ3pLMHzTqml0qYn7LPeewAVc+qny14Q7a iiViBUr152SGiIeVTgCLOM82FVE92aPVoHPQGcqqgDBzwB+whMITsFlIWXyj5Yz1 TNiU1TQuFQvnnvPq+B4nSLia+oScqcnVxxI0h+YLLh4s1e3Fvs13ZazW+tNci9so or0YNuNRrkAJvrhrlr9+kSWL01flYh1vpvkd2SEUfym+7Tl1Zzgekw== =fxIw -----END PGP SIGNATURE----- --ibTvN161/egqYuK8-- From dshaw@jabberwocky.com Wed Oct 17 02:04:01 2001 From: dshaw@jabberwocky.com (David Shaw) Date: Wed Oct 17 01:04:01 2001 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <20011016164931.A98387@colon.colondot.net>; from gnupg@lists.colondot.net on Tue, Oct 16, 2001 at 04:49:31PM +0100 References: <003301c15654$23c8fa60$dfc32609@transarc.ibm.com> <20011016164931.A98387@colon.colondot.net> Message-ID: <20011016190152.K667@akamai.com> --w7PDEPdKQumQfZlR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 16, 2001 at 04:49:31PM +0100, Matthew Byng-Maddick wrote: > On Tue, Oct 16, 2001 at 11:06:30AM -0400, Michael Young wrote: > > To make good use of these additional validity levels, the trust > > model really should understand them. For example, I might > > fully trust type-3 signatures from "John Smith", partially > > trust his type-2 signatures, and not trust any type-1. > > But that's for another day... I'm glad to see the first step. >=20 > If you do this, you have to trust that he will choose the correct type of > signature to sign with. Yes, and also that he can choose his signature type in the first place. All versions of PGP create the generic "I'm not going to say how much checking I did" form of the signature. Incidentally, I did confirm that PGP (at least version 6.5.8 and later) does understand all 4 signature types, even though it can't generate them. David --=20 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 --w7PDEPdKQumQfZlR 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 iQEVAwUBO8y8YIccwqs8s7QVAQFljwgAgsxVckn5PpFTRrmTRiUpvxUWc5IHwqK2 pdV56GepfHGcy8v8J5Evp9VjAfXB5576WNuoNpAiMwg5RSoR+zlXp4IgJowo15rS g+dA83VUGpeJWLuxRyX1GlR32eWS3amVlnka21fJ66kOuzHxOpEn0nu7kZbxwGAt +4nnCRL/cmzBGDnL/ToPbfvzHsuhG2blUIPClirT7ffLysbDWd9pwgVQ2QIbhQg+ 2MyvCnFeyDANloGFPigtR+5fWskidWJbvTmvrwLStwwlNfhiUidfTbCQ3fFIlsGY gC2bY9/wLEeJIx4qBxtfNKW0K5aRuKOaIwsuAP4+pHdflip2deQT1g== =EKJ1 -----END PGP SIGNATURE----- --w7PDEPdKQumQfZlR-- From wk@gnupg.org Thu Oct 18 15:00:02 2001 From: wk@gnupg.org (Werner Koch) Date: Thu Oct 18 14:00:02 2001 Subject: Should I release a new snapshot? Message-ID: <87adypupjb.fsf@alberti.gnupg.de> Hi! Those of you who are using the CVS version have noticed a couple of major changes in GnuPG. There is still a long list of minor bugs but nevertheless I'd like to make a new snapshot available, so that the new code can be tested. Are there any grave bugs in the CVS versions? Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From ts@winpt.org Thu Oct 18 17:00:01 2001 From: ts@winpt.org (Timo Schulz) Date: Thu Oct 18 16:00:01 2001 Subject: Should I release a new snapshot? In-Reply-To: <87adypupjb.fsf@alberti.gnupg.de> References: <87adypupjb.fsf@alberti.gnupg.de> Message-ID: <20011018155031.E412@daredevil.joesixpack.net> On Thu Oct 18 2001; 13:59, Werner Koch wrote: > Are there any grave bugs in the CVS versions? I'm not sure if this is only my problem. But with the new --refresh-key command it happens from time to time that one key exists twice in the keyring. Timo -- "Das wahre Vaterland ist das Land, wo man die meisten Menschen trifft, die einem gleichen." -- Henri Stendhal From wk@gnupg.org Thu Oct 18 20:30:02 2001 From: wk@gnupg.org (Werner Koch) Date: Thu Oct 18 19:30:02 2001 Subject: Should I release a new snapshot? In-Reply-To: <20011018155031.E412@daredevil.joesixpack.net> (Timo Schulz's message of "Thu, 18 Oct 2001 15:50:31 +0200") References: <87adypupjb.fsf@alberti.gnupg.de> <20011018155031.E412@daredevil.joesixpack.net> Message-ID: <87u1wwsvqp.fsf@alberti.gnupg.de> On Thu, 18 Oct 2001 15:50:31 +0200, Timo Schulz said: > I'm not sure if this is only my problem. But with the > new --refresh-key command it happens from time to time > that one key exists twice in the keyring. Yeah, if a snapshot helps to track this bug down, I should do it. There are also a few other problems mainly for Windows and RISC OS but those are not the primary target. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From jpg@rcom.com.ar Fri Oct 19 21:20:01 2001 From: jpg@rcom.com.ar (Juan Pablo =?ISO-8859-1?Q?Gim=E9nez?=) Date: Fri Oct 19 20:20:01 2001 Subject: with-colons bug Message-ID: <1003515471.19982.26.camel@kang.oficina.rcom.com.ar> --=-bKhvA6y9GzcgLNBsvy1d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi! I already send this mail with other subject, but nobody answer because it = was too simple... I have a problem with the option "--with-colons" and --list-keys or --fingerprint, if i don't use it, gpg print my last name "Gim=E9nez" with the "=E9", but if I put with-colons insted of "=E9" gpg prints "=C3=A9"... = So here is the patch to fix it... ________________________________________________________________________ --- gnupg-1.0.6/g10/keylist.c Sun May 27 11:31:07 2001 +++ gnupg-1.0.6_rcom/g10/keylist.c Fri Oct 12 11:42:15 2001 @@ -482,8 +482,8 @@ printf("uid:%c::::::::", trustletter); } } - print_string( stdout, node->pkt->pkt.user_id->name, - node->pkt->pkt.user_id->len, ':' ); + print_utf8_string( stdout, node->pkt->pkt.user_id->name, + node->pkt->pkt.user_id->len); putchar(':'); if (any) putchar('\n'); ________________________________________________________________________ Chausesssssssssss Juan Pablo.... --=-bKhvA6y9GzcgLNBsvy1d Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA70G5PChXsK9PY/SsRAt+EAJ9/2GlaUB9PLLyxLdskRhlgdKohzACeIM3L QGqTot3XLmgbtuUowz3Hi+M= =A8v6 -----END PGP SIGNATURE----- --=-bKhvA6y9GzcgLNBsvy1d-- From fw@deneb.enyo.de Sat Oct 20 00:38:01 2001 From: fw@deneb.enyo.de (Florian Weimer) Date: Fri Oct 19 23:38:01 2001 Subject: with-colons bug In-Reply-To: <1003515471.19982.26.camel@kang.oficina.rcom.com.ar> (Juan Pablo =?iso-8859-1?q?Gim=E9nez's?= message of "19 Oct 2001 15:17:51 -0300") References: <1003515471.19982.26.camel@kang.oficina.rcom.com.ar> Message-ID: <87d73j5oli.fsf@deneb.enyo.de> Juan Pablo Gim=E9nez writes: > I have a problem with the option "--with-colons" and --list-keys or > --fingerprint, if i don't use it, gpg print my last name "Gim=E9nez" with > the "=E9", but if I put with-colons insted of "=E9" gpg prints "=C3=A9"..= . So > here is the patch to fix it... I think this behavior is mostly correct. In "--with-colons" mode, GnuPG is expected to dump the user ID as is, without further processing. From jpg@rcom.com.ar Sat Oct 20 01:33:01 2001 From: jpg@rcom.com.ar (Juan Pablo =?ISO-8859-1?Q?Gim=E9nez?=) Date: Sat Oct 20 00:33:01 2001 Subject: with-colons bug In-Reply-To: <87d73j5oli.fsf@deneb.enyo.de> References: <1003515471.19982.26.camel@kang.oficina.rcom.com.ar> <87d73j5oli.fsf@deneb.enyo.de> Message-ID: <1003530662.4450.21.camel@kang.oficina.rcom.com.ar> --=-hWbCwDyvomJTh1VF5wK1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable En vie, 2001-10-19 a 18:03, Florian Weimer escribi=F3: Juan Pablo Gim=E9nez writes: =20 > I have a problem with the option "--with-colons" and --list-keys or > --fingerprint, if i don't use it, gpg print my last name "Gim=E9nez" = with > the "=E9", but if I put with-colons insted of "=E9" gpg prints "=C3= =A9"... So > here is the patch to fix it... =20 I think this behavior is mostly correct. In "--with-colons" mode, GnuPG is expected to dump the user ID as is, without further processing. Ok, but thats break some programs, for example Gabber (Gnome Jabber client), who print the strings as is so it print it wrong... So, what do you think, the problem is gnupg or for example Gabber?!?! =20 --=-hWbCwDyvomJTh1VF5wK1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA70KmmChXsK9PY/SsRAlmrAKCNCj2pMM4cTrjmS83Co3vINSwpzQCfQqX0 G42CD1zWZlng0+Hcoz87MdY= =IWZ3 -----END PGP SIGNATURE----- --=-hWbCwDyvomJTh1VF5wK1-- From wk@gnupg.org Sat Oct 20 13:56:01 2001 From: wk@gnupg.org (Werner Koch) Date: Sat Oct 20 12:56:01 2001 Subject: with-colons bug In-Reply-To: <1003530662.4450.21.camel@kang.oficina.rcom.com.ar> (Juan Pablo =?iso-8859-1?q?Gim=E9nez's?= message of "19 Oct 2001 19:31:02 -0300") References: <1003515471.19982.26.camel@kang.oficina.rcom.com.ar> <87d73j5oli.fsf@deneb.enyo.de> <1003530662.4450.21.camel@kang.oficina.rcom.com.ar> Message-ID: <873d4eoa2v.fsf@alberti.gnupg.de> On 19 Oct 2001 19:31:02 -0300, Juan Pablo Giménez said: > Ok, but thats break some programs, for example Gabber (Gnome Jabber > client), who print the strings as is so it print it wrong... So, what do > you think, the problem is gnupg or for example Gabber?!?! Gabber does not do a conversion from utf-8 to the used character set. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From mwy-gpg41@the-youngs.org Mon Oct 22 18:39:01 2001 From: mwy-gpg41@the-youngs.org (Michael Young) Date: Mon Oct 22 17:39:01 2001 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) References: Message-ID: <009501c15b0f$4977a760$b399183f@transarc.ibm.com> -----BEGIN PGP SIGNED MESSAGE----- > From: David Shaw > Incidentally, I did confirm that PGP (at least version 6.5.8 and > later) does understand all 4 signature types, even though it can't > generate them. I also did some confirmation. PGP2.6 should accept them. The keyservers I tested had no problem with them. Note that GnuPG had already been using class 3 for self-signatures. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQEVAwUBO9Q8omNDnIII+QUHAQHBkAgAif8tXnmcxiMMVBE4dwSDcweQxayqD1DK u9pEvD75W6dxbgdl9rlB2dd70sXVI9VhTZWo6mo/heR0Kda6gwxvRLzN0sUiP7u+ 6g9tx8wGx5POAxxJVBclL7O/kTZffjztdIm3iZKLLXh3VJ1UEVdTfIe30A/F69+X fMLAItAOe7qcPvteL40wBXZcPvK2ioE4Qtt8hc2Db7iDZLn0f+eFO6Myv2sdfHc4 KAqxb7StOpjyPJ1LELsRQ9czAU0r+O7eu05OUk1AZFyJCgzTxPBTloBVnoDs2Rmp dL9XXsHNYZM3ROTwJWfjuaflmM+4in2qe1ABh+7088EczdDS9wxqbQ== =AyYk -----END PGP SIGNATURE----- From dshaw@jabberwocky.com Mon Oct 22 22:23:01 2001 From: dshaw@jabberwocky.com (David Shaw) Date: Mon Oct 22 21:23:01 2001 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <009501c15b0f$4977a760$b399183f@transarc.ibm.com>; from mwy-gpg41@the-youngs.org on Mon, Oct 22, 2001 at 11:35:52AM -0400 References: <009501c15b0f$4977a760$b399183f@transarc.ibm.com> Message-ID: <20011022152058.A666@akamai.com> --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 22, 2001 at 11:35:52AM -0400, Michael Young wrote: > > From: David Shaw > > Incidentally, I did confirm that PGP (at least version 6.5.8 and > > later) does understand all 4 signature types, even though it can't > > generate them. >=20 > I also did some confirmation. PGP2.6 should accept them. > The keyservers I tested had no problem with them. Excellent. Thanks for checking. > Note that GnuPG had already been using class 3 for self-signatures. Yes, I noticed that. That in itself gives me more confidence there won't be problems with multiple sig classes. If there was a PGP version out there that didn't accept multiple sig classes, it would have broken with GnuPG-generated keys and we'd have heard about it by now. David --=20 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 --Kj7319i9nmIyA2yE 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 iQEVAwUBO9Rxmoccwqs8s7QVAQGJlAgAmdhTFgRXIGRh4yjeNBpFIXGT/F5t45ug Q0EfYEOKc6j+2ccCY2B0mdwuQjgr3ZPAJXl/pH0lFsC2s5TXNnkuStFT01VpMu98 JYiK20fTLuGPSBN2+e7VGSWCk0GtAiMXMb/QhqbYb5h37RP6CnDLeDHTgCpjH8br VVSXK7eroaHRJunccJ4G1WSMQ0zYBTnCrxuY/uk3pies4xs+w/eD1r5czLeMtty1 YPnZgJR+B1hgrecI75Z9IBWCBO38TrgzbGsnKy5vSUdHCmvNzhf/Dm845+E4TvE6 GbRSIq4p0D8QYlUWlQM87LjoQtiw9i2MMSS7vBuK5zhlIWG5V6x88w== =pK1e -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE-- From wk@gnupg.org Tue Oct 23 10:46:01 2001 From: wk@gnupg.org (Werner Koch) Date: Tue Oct 23 09:46:01 2001 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <20011022152058.A666@akamai.com> (David Shaw's message of "Mon, 22 Oct 2001 15:20:58 -0400") References: <009501c15b0f$4977a760$b399183f@transarc.ibm.com> <20011022152058.A666@akamai.com> Message-ID: <87y9m2vlzu.fsf@alberti.gnupg.de> On Mon, 22 Oct 2001 15:20:58 -0400, David Shaw said: > Yes, I noticed that. That in itself gives me more confidence there > won't be problems with multiple sig classes. If there was a PGP I use 0x13 for self-signatures and 0x10 for standard signatures, mainly because this may be helpful in debugging. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From wk@gnupg.org Tue Oct 23 22:28:07 2001 From: wk@gnupg.org (Werner Koch) Date: Tue Oct 23 21:28:07 2001 Subject: [Announce] A new GnuPG snapshot (unstable) Message-ID: <877ktmtgkl.fsf@alberti.gnupg.de> Hi, after messing around with autoconf 1.5 for quite some time, I finally was able to release a new DEVELOPMENT snapshot of GnuPG: *PLEASE READ THIS ENTIRE ANNOUNCEMENT BEFORE YOU START TO PLAY* ftp://ftp.gnupg.org/gcrypt/devel/gnupg-1.0.6b.tar.gz (1.9M) ftp://ftp.gnupg.org/gcrypt/devel/gnupg-1.0.6b.tar.gz.sig Please find a list of mirrors at http://www.gnupg.org/mirrors.html Again I changed quite a lot of things. Using this version with a current keyring renders the keyring unreadable for any previous GnuPG versions. So I did WARN YOU ABOUT THESE INCOMPATIBLE CHANGES - please don't complain that it destroyed all your keys. Actually this incompatibility is due to a bug in the older versions which are not able to cope with trust packet larger than one byte. You can use --export as an escape hatch because trust packets are never exported. There are 2 major changes in this release: * The caching of the signature verification status changed from using special signature subpackets to the use of the trust packets. You can (and should) rebuild this key cache using the new command "gpg --rebuild-keydb-caches" * The format of the TrustDB and the way it works has entirely be rewritten. gpg tries to migrate to the new format but this code is obviously not very well tested, so you might want to make a backup of our ownertrust values first. The validity of the key is now checked every time you insert a new key or signature and when a key or a signature expires. This automatic check can be disabled and replaced by a cron job which does an "gpg --check-trustdb" every night or so. To assign an ownertrust, you can either do this in the edit menu or use the command "gpg --update-trustdb" which does the maintenance pass in a similar manner you probably know from PGP 2. Both changes should speed up the operation on large keyrings quite a lot so that "gpg --list-keys --with-colons" is actually usable. Also a couple of bug fixes and some other code cleanups are in this release. There is still a long list of open bugs but I think it is important to get the new code tested first. The Windows and Acorn ports won't work yet due to file sharing issues. Changes since 1.0.6a: * The way signature stati are store has changed, so that v3 signatures can be supported. To increase the speed of many operations for existing keys you can use the new --rebuild-keydb-caches command. * The entire key validation process (trustdb) has been revamped. See the man page entries for --update-trustdb, --check-trustdb and --no-auto-check-trustdb. * --trusted-keys is again obsolete, --edit can be used to set the ownertrust of any key to ultimately trusted. * A subkey is never used to sign keys. * Read only keyrings are now handled as expected. Changes since 1.0.6: * New tool gpgsplit to split OpenPGP data formats into packets. * New option --preserve-permissions. * Subkeys created in the future are not used for encryption or signing unless the new option --ignore-valid-from is used. * Revoked user-IDs are not listed unless signatures are listed too or we are in verbose mode. * There is no default comment string with ascii armors anymore except for revocation certificates and --enarmor mode. * The command "primary" in the edit menu can be used to change the primary UID, "setpref" and "updpref" can be used to change the preferences. * Fixed the preference handling; since 1.0.5 they were erroneously matched against against the latest user ID and not the given one. * RSA key generation. * Merged Stefan's patches for RISC OS in. See comments in scripts/build-riscos. * It is now possible to sign and conventional encrypt a message (-cs). * The MDC feature flag is supported and can be set by using the "updpref" edit command. * The status messages GOODSIG and BADSIG are now returning the primary UID, encoded using %XX escaping (but with spaces left as spaces, so that it should not break too much) * Support for GDBM based keyrings has been removed. * The entire keyring management has been revamped. * The way signature stati are store has changed, so that v3 signatures can be supported. To increase the speed of many operations for existing keys you can use the new --rebuild-keydb-caches command. * The entire key validation process (trustdb) has been revamped. See the man page entries for --update-trustdb, --check-trustdb and --no-auto-check-trustdb. * --trusted-keys is again obsolete, --edit can be used to set the ownertrust of any key to ultimately trusted. * A subkey is never used to sign keys. Take care, Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From dshaw@jabberwocky.com Wed Oct 24 23:12:01 2001 From: dshaw@jabberwocky.com (David Shaw) Date: Wed Oct 24 22:12:01 2001 Subject: 1.0.6b comments Message-ID: <20011024161016.A2155@akamai.com> --1sNVjLsmu1MXqwQ/ Content-Type: multipart/mixed; boundary="2JFBq9zoW8cOFH7v" Content-Disposition: inline --2JFBq9zoW8cOFH7v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hiya, I've been playing with 1.0.6b, and have a few comments. Some of these are not necessarily bugs, and some of them exist in 1.0.6 as well. Aside from this, 1.0.6b is really great. I love --update-trustdb. 1) Merely having the secret key present is not enough to make a key ultimately trusted. You have to do it by hand in --edit. If a new key is generated, however, it is ultimately trusted. 2) The --edit menu does not detect if you have v3 secret keys (i.e. you can't "toggle"). V4 secret keys do work. 3) If you try to make a 4096-bit RSA key, gpg seems to make a 4095-bit key. 4) Sign a key, so that it's trust goes to "full". Now, delete or revoke the signature. The trust level stays at "full" until you export, delete, and then re-import the trustdb. 5) When you delete a key with ownertrust set it does not disappear from the trustdb. 6) You can revoke the same key signature multiple times (unclear whether this is really a problem or not). 7) When revoking a key signature, the reason for revocation prompt doesn't allow for the "no reason specified" option allowed in the RFC. A patch for that is attached. 8) RSA key signatures are always made with MD5 as the hash. This makes sense for v3 key sigs, but v4 RSA key sigs are probably safe to use something else. 9) Revoking a key or signature prompts for a revocation reason. This doesn't work properly with v3 keys in that it prompts, accepts the user's input, but does not actually include the reason in the revocation signature. This is the same problem that 1.0.6 had with making non-exportable sigs with v3 keys (i.e. v3 keys make v3 sigs, so no v4 features). Note the same thing happens with set-policy-url or notation-data with v3 keys. As I see it, if you are making a signature on a v4 key using your v3 key, it doesn't make sense to generate a v3 sig. After all, the point of using a v3 sig is to be backwards compatible, but no v3-only PGP implementation could understand the v4 key the sig is on in the first place. I've added a feature (patch attached) to always make v4 key sigs unless it is a v3 key making a key sig on a v3 key, in which case it makes a v3 key sig. I also added a "force-v4-certs" flag to force v4 key sigs (certs) if the user wants v4 key signatures all the time. This only affects key certification signatures. Regular document signatures are unchanged. This doesn't really solve the stated issue that gpg prompts the user even if it is not going to use the revocation reason but it does help the underlying problem. 10) Key flags don't seem to work properly in that if a key is flagged certify-only (0x01), or signature-only (0x02), it still can do the other (certify-only keys can sign, and signature-only keys can certify). David --=20 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 --2JFBq9zoW8cOFH7v Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch.gnupg-1.0.6b.dms.revokereason.1" Content-Transfer-Encoding: quoted-printable Index: revoke.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/gnupg/gnupg/g10/revoke.c,v retrieving revision 1.20.2.9 diff -u -r1.20.2.9 revoke.c --- revoke.c 2001/09/07 07:57:51 1.20.2.9 +++ revoke.c 2001/10/24 19:13:11 @@ -240,9 +240,10 @@ struct revocation_reason_info * ask_revocation_reason( int key_rev, int cert_rev, int hint ) { - int code; + int code=3D-1; char *description =3D NULL; struct revocation_reason_info *reason; + const char *text_0 =3D _("No reason specified"); const char *text_1 =3D _("Key has been compromised"); const char *text_2 =3D _("Key is superseded"); const char *text_3 =3D _("Key is no longer used"); @@ -254,6 +255,7 @@ description =3D NULL; =20 tty_printf(_("Please select the reason for the revocation:\n")); + tty_printf( " 0 =3D %s\n", text_0 ); if( key_rev ) tty_printf(" 1 =3D %s\n", text_1 ); if( key_rev ) @@ -262,29 +264,31 @@ tty_printf(" 3 =3D %s\n", text_3 ); if( cert_rev ) tty_printf(" 4 =3D %s\n", text_4 ); - tty_printf( " 0 =3D %s\n", _("Cancel") ); + tty_printf( " Q =3D %s\n", _("Cancel") ); if( hint ) tty_printf(_("(Probably you want to select %d here)\n"), hint ); =20 - for(code =3D 0; !code;) { + while(code=3D=3D-1) { int n; char *answer =3D cpr_get("ask_revocation_reason.code", _("Your decision? ")); trim_spaces( answer ); cpr_kill_prompt(); - if( *answer =3D=3D 'q' || *answer =3D=3D 'Q' ) - n =3D 0; - else if( !isdigit( *answer ) ) - n =3D -1; - else if( hint && !*answer ) + if( *answer =3D=3D 'q' || *answer =3D=3D 'Q') + return NULL; /* cancel */ + if( hint && !*answer ) n =3D hint; + else if(!isdigit( *answer ) ) + n =3D -1; else n =3D atoi(answer); m_free(answer); - if( !n ) - return NULL; /* cancel */ + if( n =3D=3D 0 ) { + code =3D 0x00; /* no particular reason */ + code_text =3D text_0; + } else if( key_rev && n =3D=3D 1 ) { - code =3D 0x02; /* key has been compromised */ + code =3D 0x02; /* key has been compromised */ code_text =3D text_1; } else if( key_rev && n =3D=3D 2 ) { --2JFBq9zoW8cOFH7v Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch.gnupg-1.0.6b.dms.sigversion.1" Content-Transfer-Encoding: quoted-printable ? Makefile.in ? Makefile ? .deps ? gpg ? gpgv Index: g10.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/gnupg/gnupg/g10/Attic/g10.c,v retrieving revision 1.129.2.57 diff -u -r1.129.2.57 g10.c --- g10.c 2001/10/06 07:31:28 1.129.2.57 +++ g10.c 2001/10/24 19:36:04 @@ -180,6 +180,8 @@ oThrowKeyid, oForceV3Sigs, oNoForceV3Sigs, + oForceV4Certs, + oNoForceV4Certs, oForceMDC, oS2KMode, oS2KDigest, @@ -311,6 +313,8 @@ { oNoTTY, "no-tty", 0, N_("don't use the terminal at all") }, { oForceV3Sigs, "force-v3-sigs", 0, N_("force v3 signatures") }, { oNoForceV3Sigs, "no-force-v3-sigs", 0, N_("do not force v3 signature= s") }, + { oForceV4Certs, "force-v4-certs", 0, N_("force v4 key signatures") }, + { oNoForceV4Certs, "no-force-v4-certs", 0, N_("do not force v4 key sig= natures") }, { oForceMDC, "force-mdc", 0, N_("always use a MDC for encryption") }, { oDryRun, "dry-run", 0, N_("do not make any changes") }, /*{ oInteractive, "interactive", 0, N_("prompt before overwriting") }, */ @@ -956,6 +960,7 @@ case oRFC1991: opt.rfc1991 =3D 1; opt.rfc2440 =3D 0; + opt.force_v4_certs =3D 0; opt.no_comment =3D 1; opt.escape_from =3D 1; break; @@ -998,6 +1003,8 @@ case oThrowKeyid: opt.throw_keyid =3D 1; break; case oForceV3Sigs: opt.force_v3_sigs =3D 1; break; case oNoForceV3Sigs: opt.force_v3_sigs =3D 0; break; + case oForceV4Certs: opt.force_v4_certs =3D 1; break; + case oNoForceV4Certs: opt.force_v4_certs =3D 0; break; case oForceMDC: opt.force_mdc =3D 1; break; case oS2KMode: opt.s2k_mode =3D pargs.r.ret_int; break; case oS2KDigest: s2k_digest_string =3D m_strdup(pargs.r.ret_str); break; Index: options.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/gnupg/gnupg/g10/options.h,v retrieving revision 1.51.2.30 diff -u -r1.51.2.30 options.h --- options.h 2001/09/25 15:20:59 1.51.2.30 +++ options.h 2001/10/24 19:36:04 @@ -57,6 +57,7 @@ int list_packets; /* list-packets mode: 1=3Dnormal, 2=3Dinvoked by com= mand*/ int def_cipher_algo; int force_v3_sigs; + int force_v4_certs; int force_mdc; int def_digest_algo; int def_compress_algo; Index: sign.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/gnupg/gnupg/g10/sign.c,v retrieving revision 1.75.2.23 diff -u -r1.75.2.23 sign.c --- sign.c 2001/09/09 16:09:19 1.75.2.23 +++ sign.c 2001/10/24 19:36:04 @@ -982,8 +982,18 @@ || sigclass =3D=3D 0x20 || sigclass =3D=3D 0x18 || sigclass =3D=3D 0x30 || sigclass =3D=3D 0x28 ); =20 + if (opt.force_v4_certs) + sigversion =3D 4; + if (sigversion < sk->version) sigversion =3D sk->version; + + /* If you are making a signature on a v4 key using your v3 key, it + doesn't make sense to generate a v3 sig. After all, no v3-only + PGP implementation could understand the v4 key in the first + place. */ + if (sigversion < pk->version) + sigversion =3D pk->version; =20 if( !digest_algo ) { switch( sk->pubkey_algo ) { --2JFBq9zoW8cOFH7v-- --1sNVjLsmu1MXqwQ/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6b (GNU/Linux) iQEVAwUBO9cgKIccwqs8s7QVAQHJhwf8C806sdn+1ZvXbweOu92OyH4bgXMjurkn UUAHKx45eMa/oq/0Sn11wwucntr4CHQhGlc7b1IJ6/aVPp3tvtaWQ2OfAMRSCGgW i/rLAPeoQVdd1ULuI5ZPtyXKAqCSR8bB+HzpWHduobGXeCE/N7vNgMPa+VpelEnI ToPdgsR2CRCIsAEaflEiSar6C8LFWSL1QXqFD/VDPxHGlG+rOHP2lR21OO0/l1Ue 0Yk7fm+aUeIK8f22KAeE3+x6sPsDmGXDKptndZLf3mgAXWdWI4/3TNpcmIJ7WYxN Lf/TUW3dJimuBg9IhPZLL+qC6tp4RJJcYa1BKysNWmBC9N7JMpOp8A== =Vx5N -----END PGP SIGNATURE----- --1sNVjLsmu1MXqwQ/-- From rabbi@quickie.net Wed Oct 24 23:27:02 2001 From: rabbi@quickie.net (Len Sassaman) Date: Wed Oct 24 22:27:02 2001 Subject: 1.0.6b comments In-Reply-To: <20011024161016.A2155@akamai.com> Message-ID: On Wed, 24 Oct 2001, David Shaw wrote: > Hiya, > > I've been playing with 1.0.6b, and have a few comments. Some of these > are not necessarily bugs, and some of them exist in 1.0.6 as well. > > Aside from this, 1.0.6b is really great. I love --update-trustdb. > > 1) Merely having the secret key present is not enough to make a key > ultimately trusted. You have to do it by hand in --edit. If a new > key is generated, however, it is ultimately trusted. That is correct behavior. (There's a possible attack on systems that automatically import keys received in email that doing it this way protects against. I can describe it in more detail if you like.) > 8) RSA key signatures are always made with MD5 as the hash. This > makes sense for v3 key sigs, but v4 RSA key sigs are probably safe > to use something else. Yes. In PGP 7.0, we used SHA-1. No reason to stick with MD5. Also, RSA v4 keys bind their subkeys to the primary key using SHA-1 in PGP 7.x as well. > As I see it, if you are making a signature on a v4 key using your > v3 key, it doesn't make sense to generate a v3 sig. After all, the > point of using a v3 sig is to be backwards compatible, but no > v3-only PGP implementation could understand the v4 key the sig is > on in the first place. PGP versions prior to 5.x could not do v4 at all. PGP 5.x and 6.x understood v4 sigs on keys, but not on non-key material. (There's a nit about this in the RFC for 5.x; it should say 6.x as well.) (Just reiterating what you are saying here -- if an implementation can handle a v4 key, it can handle v4 sigs on a v4 key, even if it can't handle v4 sigs on other files. -- Len Sassaman Security Architect | "Now it's all change -- Technology Consultant | It's got to change more." | http://sion.quickie.net | --Joe Jackson From JanuszA.Urbanowicz Thu Oct 25 01:40:01 2001 From: JanuszA.Urbanowicz (JanuszA.Urbanowicz) Date: Thu Oct 25 00:40:01 2001 Subject: 1.0.6b comments (fwd) Message-ID: --ELM711998029-25058-0_ Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit -- Janusz A. Urbanowicz | ALEX3-RIPE | SF-Framling | Thawte Web Of Trust Notary Gdy dajê biednym chleb, nazywaj± mnie ¶wiêtym. Gdy pytam, dlaczego biedni nie maj± chleba, nazywaj± mnie komunist±. - abp. Helder Camara --ELM711998029-25058-0_ Content-Type: message/rfc822 Content-Disposition: inline Content-Description: Forwarded message from Janusz A . Urbanowicz Content-Transfer-Encoding: 8bit Subject: Re: 1.0.6b comments In-Reply-To: <20011024161016.A2155@akamai.com> from David Shaw at "Oct 24, 2001 04:10:16 pm" To: David Shaw Date: Thu, 25 Oct 2001 00:14:05 +0200 (CEST) From: Janusz A. Urbanowicz X-Latin-Date: Hodie VIII Kal. Nov. MMDCCLIV AUC est X-Mayan-Date: 12.19.08.12.03 X-Erisian-Date: Pungenday, The Aftermath 6, 3167 YOLD X-Operating-System: Linux sword 2.2.16 i586 X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit Content-Length: 1884 David Shaw wrote/napisa³[a]/schrieb: -- Start of PGP signed section. > Hiya, > > I've been playing with 1.0.6b, and have a few comments. Some of these > are not necessarily bugs, and some of them exist in 1.0.6 as well. > > Aside from this, 1.0.6b is really great. I love --update-trustdb. Aside that trust checking during signature verification in 1.0.6b is waay slower thanit was in 1.0.6a. And this is after setting ultimate trust on keys and rerunning update-trustdb a few times. Daaing my remark: 11) I have a (local signature) on a key using signing subkey of my key (since this is lsig it is not very important). This sig is not taken into account when calculating trust: :alex@sword:[~]:223:> gpg --edit-key RSA gpg (GnuPG) 1.0.6b; 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. gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! pub 1024R/DE46F54F created: 1999-09-16 expires: never trust: f/- ~~~ (1). Personal Freemail RSA 1999.9.16 Command> check uid Personal Freemail RSA 1999.9.16 sig! DE46F54F 1999-09-16 [self-signature] sig! 7E2E803D 2001-10-17 Janusz A. Urbanowicz (notebook) ; from alex@bofh.torun.pl on Thu, Oct 25, 2001 at 12:49:33AM +0200 References: Message-ID: <20011024190939.A13100@akamai.com> --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 25, 2001 at 12:49:33AM +0200, Janusz A. Urbanowicz wrote: > 11) I have a (local signature) on a key using signing subkey of my key > (since this is lsig it is not very important). This sig is not taken into > account when calculating trust: I can confirm this. It seems to apply to any key signature (local or not local) made by a signing subkey. 1.0.6b won't let signing subkeys make key signatures any longer, but there are some sigs there from older versions. David --=20 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 --pWyiEgJYm5f9v55/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6b (GNU/Linux) iQEVAwUBO9dKM4ccwqs8s7QVAQE++ggAohTk952P3iAfv9jRTWb8qHUW7F7T+7cY VCPH9D2OLIXTZOhlnhnHEcA4tCHAYEA3IMzxChTdTE4ocbX86FKomMpoDREW6Pz0 9qr0zqLXVNv+3ZOPYOnY9iB8x3IjIopF2cNhQEJeqBDRuZ0Dx2wmXq4v4jyKM+iw O5mIkdBvcsfDNbMROeOemDHSqc4UEPaEyaO5KE8KAtDwkyOga0kIwzLlNiJwSHLH Xph8HFhryN30ktEDuUhrfCAFteZW0VZTW0rG7Bzei8lBGN1+MH+9DPEBWVyEM9et BEisFDlW4GYsx2kK9z6ngLrKSgCKD0BldexjRc12O+oBrujMDVMm4w== =xz+f -----END PGP SIGNATURE----- --pWyiEgJYm5f9v55/-- From JanuszA.Urbanowicz Thu Oct 25 11:53:01 2001 From: JanuszA.Urbanowicz (JanuszA.Urbanowicz) Date: Thu Oct 25 10:53:01 2001 Subject: 1.0.6b comments In-Reply-To: <20011024161016.A2155@akamai.com> from David Shaw at "Oct 24, 2001 04:10:16 pm" Message-ID: David Shaw wrote/napisa³[a]/schrieb: -- Start of PGP signed section. > Hiya, > > I've been playing with 1.0.6b, and have a few comments. Some of these > are not necessarily bugs, and some of them exist in 1.0.6 as well. > > Aside from this, 1.0.6b is really great. I love --update-trustdb. Aside that trust checking during signature verification in 1.0.6b is waay slower thanit was in 1.0.6a. And this is after setting ultimate trust on keys and rerunning update-trustdb a few times. Daaing my remark: 11) I have a (local signature) on a key using signing subkey of my key (since this is lsig it is not very important). This sig is not taken into account when calculating trust: :alex@sword:[~]:223:> gpg --edit-key RSA gpg (GnuPG) 1.0.6b; 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. gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! pub 1024R/DE46F54F created: 1999-09-16 expires: never trust: f/- ~~~ (1). Personal Freemail RSA 1999.9.16 Command> check uid Personal Freemail RSA 1999.9.16 sig! DE46F54F 1999-09-16 [self-signature] sig! 7E2E803D 2001-10-17 Janusz A. Urbanowicz (notebook) Geachte heer/mevrouw Nog 1 dag en dan is het zover: de releasedatum van WINDOWS XP !! Windows XP, het allernieuwste besturingssysteem van Microsoft, kunt u nu bij ons bestellen !! U bestelt via deze e-mail Windows XP? Profiteer dan tevens van een fikse korting op KILOMETERDECLARATIE 2001 ! U kunt Kilometerdeclaratie 2001 aanschaffen van: fl. 99,- (44,92 Euro) voor: fl. 69,- (31,31 Euro) Onderaan deze e-mailing vindt u onze speciale aanbiedingen met kortingen die oplopen tot bijna 40%. Voor een totaaloverzicht van ons assortiment: www.teledirekt.nl Wilt u extra productinformatie of een goed advies? Bel GRATIS de Teledirekt Verkoopadvieslijn: 0800-237 66 44 Als u direct wilt bestellen: http://63.105.9.58/em/em47pt.htm ============================================================== # WINDOWS XP BRENGT UW PC NAAR ONGEKENDE HOOGTE - DE NIEUWE STANDAARD VOOR EFFICIËNT EN BETROUWBAAR COMPUTERGEBRUIK - Windows XP heeft een totaal nieuwe look en is ook inhoudelijk aanzienlijk veranderd. Het besturingssysteem haakt direct in op de vooruitgang van internet en de digitale media. Microsoft introduceert een aantal edities van Windows XP die zijn afgestemd op uw computerbehoeften zowel thuis als op kantoor. * WINDOWS XP HOME EDITION * De Windows XP Home Edition is het nieuwe besturingssysteem voor de PC thuis en biedt u alles wat u nodig hebt om eenvoudig computers en een thuisnetwerk te delen. Met de digitale fotofuncties kunt u foto's ophalen, organiseren en delen met de alles-in-één muziekfunctie kunt u kwalitatief hoogstaande muziek ontdekken, downloaden, opslaan en afspelen. - Één plaats voor het afspelen van DVD's, ordenen van muziek, branden van CD's, etc. - Films opnemen, bewerken, ordenen en delen op uw computer. - Afbeeldingen ordenen en bekijken of afdrukken van uw foto's bestellen via een webservice. - Eenvoudiger dan ooit om uw eigen thuisnetwerk te installeren. Prijs: fl. 615,- (279,07 Euro) Win 98/2000/ME Art.nr: 303070 Bestellen: http://63.105.9.58/em/em47pt.htm * WINDOWS XP HOME EDITION UPGRADE Prijs: fl. 285,- (129,33 Euro) Win 98/2000/ME Art.nr: 303071 Bestellen: http://63.105.9.58/em/em47pt.htm * WINDOWS XP PROFESSIONAL EDITION Biedt alle voordelen van Windows XP plus o.a. een hogere veiligheid en eersteklas mobiele ondersteuning om off-line te kunnen werken of om op afstand toegang te krijgen tot uw computer. Prijs: fl. 924,- (419,29 Euro) Win 98/2000/ME Art.nr: 303068 Bestellen: http://63.105.9.58/em/em47pt.htm * WINDOWS XP PROFESSIONAL EDITION UPGRADE Prijs: fl. 571,- (259,11 Euro) Win 98/2000/ME Art.nr: 303069 Bestellen: http://63.105.9.58/em/em47pt.htm U bestelt Windows XP via deze e-mailing?? Dan kunt u Kilometerdeclaratie 2001 aanschaffen van: fl. 99,- (44,92 Euro) voor: fl. 69,- (31,31 Euro) Dit kunt u aangeven op het bestelformulier: http://63.105.9.58/em/em47pt.htm ============================================================== # CD'S WISSELEN IS NIET MEER NODIG Kopieer uw favoriete CD-Rom's naar uw harde schijf. CD's tot 20 x sneller toegankelijk. Prijs: fl. 129,- (58,54 Euro) Win 95/98/NT/2000 Art.nr: 303042 Bestellen: http://63.105.9.58/em/em47pt.htm ============================================================== # CD-FOONGIDS 2001 + ADRESBESTAND COMPACT Meer dan 7.000.000 adressen met telefoon-, fax- en mobiele nummers. Prijs: fl. 69,- (31,31 Euro) Win 95/98/NT/2000/ME Art.nr: 302779 Bestellen: http://63.105.9.58/em/em47pt.htm ============================================================== # CURSUS INTERNET, WINDOWS 98, WORD, EXCEL EN POWERPOINT Bundelprijs: fl. 79,- (35,85 Euro) Win 95/98 Art.nr: 302918 Bestellen: http://63.105.9.58/em/em47pt.htm ============================================================== # ONTWERP ZELF UW EIGEN INTERNETSITE Prijs: fl. 85,- (38,57 Euro) Win 95/98/NT/2000/ME Art.nr: 303034 Bestellen: http://63.105.9.58/em/em47pt.htm ============================================================== ** Teledirekt aanraders ** 1. Nedsoft EuroOffice pro, fl. 149,- (67,61 Euro) Microsoft Office-documenten omzetten in de Euro (art.nr: 303009) 2. CardIris, fl. 699,- (317,19 Euro) Met één klik al uw visitekaartjes in uw PC (art.nr: 302759) 3. Easy Travel Plus, fl. 79,- (35,85 Euro) Alle straten van de Benelux op één CD-Rom (art.nr: 301590) 4. 333.000 Professionele afbeeldingen, fl. 169,- (76,69 Euro) Cliparts, bitmapafbeeldingen, internetanimaties, foto's, afbeeldingen (art.nr: 301025) 5. NL-Sat, fl. 42,50 (19,29 Euro) Satellietatlas van Nederland (art.nr: 301445) Bestellen: http://63.105.9.58/em/em47pt.htm ============================================================== ** Aanbiedingen OP = OP ** # VISUAL VOORRAAD, voor een eenvoudig en overzichtelijk voorraadbeheer. Dit pakket biedt u onder andere het volgende: - Voorraden beheren. - Klant-/leveranciersafspraken bijhouden. - Automatisch bestellingen genereren. - Deelleveringen bij goederen ontvangen. - Historie van bestel- en verkoopgegevens vastleggen en opvragen. - Beheer van meerdere magazijnen (van eenvoudig tot zeer geavanceerd). - Uitgebreide opvraag van omzetgegevens per periode, artikel/artikelgroep of klant. - Ondersteuning vreemde valuta en talen. van: fl. 995,- voor: fl. 695,- (30% korting) van: 451,51 Euro voor: 315,38 Euro Art.nr: 301038 Bestellen: http://63.105.9.58/em/em47pt.htm ============================================================== # RECRUITMENT ASSISTENT, sollicitaties snel en efficiënt afhandelen. Recruitment Assistent helpt u bij het vinden van de beste kandidaat voor een vacature. Het systeem bespaart u tijd bij het maken van brieven, houdt de administratie van uw correspondentie bij en assisteert u bij de verwerking van de gegevens. Zodat u zich kunt concentreren op de mensen zelf.... van: fl. 799,- voor: fl. 499,- (38% korting) van: 362,57 Euro voor: 226,44 Euro Art.nr: 301308 Bestellen: http://63.105.9.58/em/em47pt.htm ============================================================== Als u gebruik wilt maken van deze aanbiedingen, dan kunt u bestellen via internet: http://63.105.9.58/em/em47pt.htm U hebt de producten (indien op voorraad) binnen 2 dagen op uw bureau. Met vriendelijke groet, Teledirekt Nederland De genoemde prijzen zijn exclusief BTW. Administratiekosten: fl. 15,- (6,81 Euro). ************************************************************** Wanneer u SoftwareNieuws niet meer wilt ontvangen, kunt u: 1. dit aangeven op http://www.teledirektnederland.nl/maillijst2.htm; 2. ons telefonisch op de hoogte stellen dat u van de maillijst verwijderd wilt worden; 3. een e-mailtje sturen naar softwarenieuws@teledirekt.nl U kunt zich ook algemeen afmelden voor commerciële e-mail berichten via www.e-mps.org/nl Deze e-mailing is verzonden geheel volgens de gedragscode van de DMSA. ************************************************************** Teledirekt Nederland B.V. Kelvinring 58 2952 BG Alblasserdam GRATIS Verkoopadvieslijn: 0800 - 237 66 44 Helpdesk (1 gpm): 0900 - 237 66 48 Fax: 078 - 691 98 29 E-mail adressen: Klantenservice: mailto:klantenservice@teledirekt.nl Helpdesk: mailto:helpdesk@teledirekt.nl Bestelcode: EM47p From vogtm@skunk.physik.uni-erlangen.de Thu Oct 25 14:27:01 2001 From: vogtm@skunk.physik.uni-erlangen.de (Marco Vogt) Date: Thu Oct 25 13:27:01 2001 Subject: Windows XP: al vanaf fl. 285,- In-Reply-To: <57472001104251111160@teledirekt.nl> Message-ID: On Thu, 25 Oct 2001, Teledirekt Nederland wrote: > > Geachte heer/mevrouw > Nog 1 dag en dan is het zover: de releasedatum van WINDOWS XP !! > > Windows XP, het allernieuwste besturingssysteem van Microsoft, kunt u nu > bij ons > bestellen !! LOL, I think this firm don't really know to whom they send their spam... Long lives Linux... From subscriber@locustcreek.com Thu Oct 25 16:30:02 2001 From: subscriber@locustcreek.com (Oblio) Date: Thu Oct 25 15:30:02 2001 Subject: Windoze question Message-ID: <5.1.0.14.2.20011025091250.038d1600@mail.locustcreek.com> Hi, I'm new to this list, so please bear with me. I've been poking around the Net looking for the C++ libraries for PGP to write my own program. I'd like to get open source libraries as I will be creating software for commercial endeavors. The other issue is I'd like them for Windows, preferably Win2K. If anyone can help, I'd appreciate it. Oblio From apm35@student.open.ac.uk Thu Oct 25 18:37:01 2001 From: apm35@student.open.ac.uk (Andrew Marlow) Date: Thu Oct 25 17:37:01 2001 Subject: Windoze question Message-ID: I think this has hightlighted an important point about the GPG web site. It is not immediately obvious (to me, anyway) from the web site that GPG is covered by the GPL. Those in the know will presume it is, since it is a GNU project. But here we have someone asking about open source. IMO GNU projects make an important distinction between open source and free software. I believe that GPG is in the latter category. This means that GPG is software that has freedom and the license says that in order for you to enjoy this freedom you must not take it away from others. Some GPL'd source comes with libraries that are LGPL'd. The LGPL allows the library to be used in the development of closed-source proprietary software. Whether you use PGP or GPG you need to check these things out. Just having the source code available is not enough. License permitting, I would recommend GPG over PGP since I think GPG has a closer eye on the RFC and other issues, such as crypto-law and patent law. GPG has also taken some decisions which have made it less vunerable to certain problems (e.g the ADK issue). -apm From dshaw@jabberwocky.com Thu Oct 25 18:43:01 2001 From: dshaw@jabberwocky.com (David Shaw) Date: Thu Oct 25 17:43:01 2001 Subject: More 1.0.6b comments Message-ID: <20011025114043.D7040@akamai.com> --/NkBOFFp2J2Af1nK Content-Type: multipart/mixed; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Here's a few more comments: 12) If you set a key to ultimate trust, and it's the only ultimately trusted key, gpg gets confused if you unset its ultimate trust. The key will still be shown as "u", but --check-trustdb warns "no ultimately trusted keys found" and schedules the next update for "????-??-??". 13) Once --update-trustdb starts, there is no way to exit it ("q" just skips to the next key). 14) Little bug: in 1.0.6, if you changed trust via the --edit menu, gpg would display the new trust after you changed it. 1.0.6b does not do this. Attached is a fix for #13 and #14. It also adds a "s" for skip, which skips to the next key since "q" now actually quits. The existing "s" (for the not yet implemented more information) is now "i". David --=20 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 --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch.gnupg-1.0.6b.dms.trustupdate.1" Content-Transfer-Encoding: quoted-printable Index: pkclist.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/gnupg/gnupg/g10/pkclist.c,v retrieving revision 1.58.2.24 diff -u -r1.58.2.24 pkclist.c --- pkclist.c 2001/10/23 08:03:45 1.58.2.24 +++ pkclist.c 2001/10/25 03:40:23 @@ -241,7 +241,7 @@ keyid_from_pk (pk, keyid); for(;;) { /* a string with valid answers */ - const char *ans =3D _("sSmMqQ"); + const char *ans =3D _("iImMqQsS"); =20 if( !did_help )=20 { @@ -268,15 +268,18 @@ tty_printf (_(" %d =3D I trust fully\n"), 4); if (mode) tty_printf (_(" %d =3D I trust ultimately\n"), 5); - tty_printf (_(" s =3D please show me more information\n") ); + tty_printf (_(" i =3D please show me more information\n") ); if( mode ) tty_printf(_(" m =3D back to the main menu\n")); else - tty_printf(_(" q =3D quit\n")); + { + tty_printf(_(" s =3D skip this key\n")); + tty_printf(_(" q =3D quit\n")); + } tty_printf("\n"); did_help =3D 1; } - if( strlen(ans) !=3D 6 ) + if( strlen(ans) !=3D 8 ) BUG(); p =3D cpr_get("edit_ownertrust.value",_("Your decision? ")); trim_spaces(p); @@ -319,6 +322,10 @@ { break ; /* back to the menu */ } + else if( !mode && (*p =3D=3D ans[6] || *p =3D=3D ans[7] ) ) + { + break; /* skip */ + } else if( !mode && (*p =3D=3D ans[4] || *p =3D=3D ans[5] ) ) { quit =3D 1; @@ -346,7 +353,7 @@ switch ( do_edit_ownertrust (pk, mode, &trust, no_help ) ) { case -1: /* quit */ - return 0; + return -1; case -2: /* show info */ show_paths(pk, 1); no_help =3D 1; @@ -355,7 +362,7 @@ trust &=3D ~TRUST_FLAG_DISABLED; trust |=3D get_ownertrust (pk) & TRUST_FLAG_DISABLED; update_ownertrust (pk, trust ); - return 0; + return 1; default: return 0; } Index: trustdb.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/gnupg/gnupg/g10/trustdb.c,v retrieving revision 1.81.2.25 diff -u -r1.81.2.25 trustdb.c --- trustdb.c 2001/09/28 16:59:47 1.81.2.25 +++ trustdb.c 2001/10/25 03:40:27 @@ -846,12 +846,12 @@ *********** NEW NEW NEW **************** ****************************************/ =20 -static unsigned int +static int ask_ownertrust (u32 *kid) { PKT_public_key *pk; int rc; - unsigned int ot; + int ot; =20 pk =3D m_alloc_clear (sizeof *pk); rc =3D get_pubkey (pk, kid); @@ -862,10 +862,13 @@ return TRUST_UNKNOWN; } =20 - if (edit_ownertrust (pk, 0)) + ot=3Dedit_ownertrust(pk,0); + if(ot>0) ot =3D get_ownertrust (pk); - else + else if(ot=3D=3D0) ot =3D TRUST_UNDEFINED; + else + ot =3D -1; /* quit */ free_public_key( pk ); return ot; } @@ -1303,6 +1306,7 @@ validate_keys (int interactive) { int rc =3D 0; + int quit=3D0; struct key_item *klist =3D NULL; struct key_item *k; struct key_array *keys =3D NULL; @@ -1377,7 +1381,12 @@ { if (interactive && k->ownertrust =3D=3D TRUST_UNKNOWN) k->ownertrust =3D ask_ownertrust (k->kid); - if (k->ownertrust =3D=3D TRUST_UNKNOWN) + if (k->ownertrust =3D=3D -1) + { + quit=3D1; + goto leave; + } + else if (k->ownertrust =3D=3D TRUST_UNKNOWN) ot_unknown++; else if (k->ownertrust =3D=3D TRUST_UNDEFINED) ot_undefined++; @@ -1448,7 +1457,7 @@ release_key_array (keys); release_key_items (klist); release_key_hash_table (visited); - if (!rc) /* mark trustDB as checked */ + if (!rc && !quit) /* mark trustDB as checked */ { if (next_expire =3D=3D 0xffffffff) tdbio_write_nextcheck (0);=20 --qMm9M+Fa2AknHoGS-- --/NkBOFFp2J2Af1nK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6b (GNU/Linux) iQEVAwUBO9gye4ccwqs8s7QVAQFYewf+NQUjzjA68VOfESBVMyTG9N1FNlo+MO4R BwF9CczWutXUzC0zE1QxBI1U6gq5nkR8rqf9liFLgH0rzegNaP2ab9FkXoPW3jWE rJGdpZP4G01+87vcN1wBo8LMcVE1HCh/1a1HGHR0XAuLWWJ44Cgd6sWQDlekLGW0 BUPUsxBAF1VPBXsBjdNYdynxiYDoPLd+srfXc44N3yyJPNOuNFIU7JRZo6zDLhQR o61pq7ueSpmsjkSpbgsk1+Av56bBPj2ovwCBwZdNhHpnidVZhZveFkZTy7uK6WUU yfpQhOE5os4oNcr9Lsj287r0GzcM8EfGx6m+DQBZWKA+25EUXQR54w== =OL52 -----END PGP SIGNATURE----- --/NkBOFFp2J2Af1nK-- From Fabian.Rodriguez@Toxik.com Thu Oct 25 21:37:02 2001 From: Fabian.Rodriguez@Toxik.com (Toxik - Fabian Rodriguez) Date: Thu Oct 25 20:37:02 2001 Subject: Verisign / Network Solutions PGP guardian method does not support GnuPG In-Reply-To: <5.1.0.14.2.20011025091250.038d1600@mail.locustcreek.com> Message-ID: Hello, >From time to time I verify different scenarios in which our customers may use GnuPG as a complete replacement to PGP. It is interesting to note that Network Solutions' PGP guardian method does not work with GnuPG generated signatures. I am enclosing the original response (less my message), as reference. Please note that I used GnuPG v1.0.6 (MingW32) and WinPT 0.4.0a. Then with PGP 7.03 it was completed fine, with the exact same text, using the same key, same software (Outlook), etc. Only the encryption software was different. BTW, on their site they mention: "Our PGP keyserver will accept PGP Version 2.6 to 6.5.2.", however I sent my key generated with GnuPG/WinPT by email and their server accepted it. And the message I sent after that (resulting in the error reply), was signed with PGP 7.03. Also note it took 18 days for the key to be added (instead of 24h). I thought it would be more appropiate to send it here than to risk it being lost in their support system. Thank you, Fabian Rodriguez - Toxik Technologies Inc. www.Toxik.com - Open PGP ID: 0x5AF2A4D5 > -----Original Message----- > From: Domain Registration Role Account [mailto:domreg@networksolutions.com] > Sent: October 24, 2001 16:42 > To: dnsadmin@toxik.com > Subject: Re: [NIC-XXXXXX.XXXX] DOMAIN NAME (request id modified for privacy purposes) > > > Thank you for contacting VeriSign. > > We have received your message, but are unable to process it at this > time. The most likely reasons why this may have happened are listed > below. Please review this list and compare the possible errors with > your message. If possible, correct the error and re-send your e-mail > to VeriSign at hostmaster@networksolutions.com. > > 1. Your PGP signed message was MIME-encapsulated. Most Windows based > e-mail applications will perform this conversion. Currently, we cannot > support PGP signed messages that have been MIME-encapsulated. > > 2. There are extra characters in your message, which distort your PGP > signature and make it impossible for us to confirm that your signature > is correct. These extra characters are inserted when a PGP plugin for > Outlook or Eudora are used to sign a message, and the message is then > sent to a system using a UNIX platform, which we use. Currently, we > cannot support PGP signed messages sent from a computer using any > platform other than UNIX. > > 3. Although PGP is your Guardian method, you did not sign your message > with your PGP private key. Please sign your message with your PGP > private key and return it by e-mail to VeriSign at > hostmaster@networksolutions.com. > > 4. It appears that you have more than one PGP private key. Although you > signed this message with a PGP key, you didn't use the PGP private key > that is associated with the contact handle on this record. Please make > sure that you are using the right PGP private key to sign your message > and return the message by e-mail to VeriSign at > hostmaster@networksolutions.com. > > Best regards, > VeriSign, Inc. > http://www.netsol.com From jam@jamux.com Fri Oct 26 15:52:01 2001 From: jam@jamux.com (John A. Martin) Date: Fri Oct 26 14:52:01 2001 Subject: Verisign / Network Solutions PGP guardian method does not support GnuPG In-Reply-To: ("Toxik - Fabian Rodriguez"; Thu, 25 Oct 2001 14:34:39 -0400) Message-ID: <20011026124944.CF9263B891@athene.jamux.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "FR" == Fabian Rodriguez >>>>> "Verisign / Network Solutions PGP guardian method does not support GnuPG" >>>>> Thu, 25 Oct 2001 14:34:39 -0400 FR> Hello, From time to time I verify different scenarios in which FR> our customers may use GnuPG as a complete replacement to FR> PGP. It is interesting to note that Network Solutions' PGP FR> guardian method does not work with GnuPG generated signatures. Compare: http://lists.gnupg.org/pipermail/gnupg-users/2001-September/010016.html http://lists.gnupg.org/pipermail/gnupg-users/2001-September/010019.html http://lists.gnupg.org/pipermail/gnupg-users/2001-September/010027.html http://lists.gnupg.org/pipermail/gnupg-users/2001-September/010035.html Especially the last. jam -----BEGIN PGP SIGNATURE----- Comment: OpenPGP encrypted mail preferred. See iEYEARECAAYFAjvZW5YACgkQUEvv1b/iXy+bnQCfTL++f7dy0y1AA733oYWiK61O llwAn2p51JVa1Q5lOhhepLv4Nbb91IMZ =d0wo -----END PGP SIGNATURE----- From roconnor@math.berkeley.edu Mon Oct 29 00:56:01 2001 From: roconnor@math.berkeley.edu (roconnor@math.berkeley.edu) Date: Mon Oct 29 00:56:01 2001 Subject: GnuPG for OS/2 Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I thought I'd let the list know of a port to OS/2. - -- Russell O'Connor roconnor@math.berkeley.edu ``This is not a time, as it is never a time, to seek vengeance, but a time to seek the courage to forgive'' -- George W. Bush -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (SunOS) Comment: For info see http://www.gnupg.org iD8DBQE73JqXZG3em5NXM14RAk3WAKDyhgsQkW4dbqfXYvbigW8RD4tT7gCdEFGi 5YvNZNgq0ozTd37+HYqf9og= =bo4q -----END PGP SIGNATURE----- From wk@gnupg.org Mon Oct 29 08:56:01 2001 From: wk@gnupg.org (Werner Koch) Date: Mon Oct 29 08:56:01 2001 Subject: GnuPG for OS/2 In-Reply-To: (roconnor@math.berkeley.edu's message of "Sun, 28 Oct 2001 15:53:52 -0800 (PST)") References: Message-ID: <87u1wianis.fsf@alberti.gnupg.de> On Sun, 28 Oct 2001 15:53:52 -0800 (PST), roconnor said: > I thought I'd let the list know of a port to OS/2. > How to you handle the RNG issue? Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From roconnor@math.berkeley.edu Mon Oct 29 09:03:01 2001 From: roconnor@math.berkeley.edu (roconnor@math.berkeley.edu) Date: Mon Oct 29 09:03:01 2001 Subject: GnuPG for OS/2 In-Reply-To: <87u1wianis.fsf@alberti.gnupg.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 29 Oct 2001, Werner Koch wrote: > How to you handle the RNG issue? I wrote a Rexx Entropy Gathering Daemon based on the Perl EGD. It's not as good as a driver to gather interupt infromation, but should be about as good as the Perl EGD. - -- Russell O'Connor roconnor@alumni.uwaterloo.ca ``This is not a time, as it is never a time, to seek vengeance, but a time to seek the courage to forgive'' -- George W. Bush -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (SunOS) Comment: For info see http://www.gnupg.org iD8DBQE73QzYZG3em5NXM14RAuVHAJ9LrKvHGV04O6nd3fONkCMUorky/QCg1bx1 HSSmex1FEoWjb2cZbQfRZoQ= =a7/l -----END PGP SIGNATURE----- From wk@gnupg.org Mon Oct 29 09:50:02 2001 From: wk@gnupg.org (Werner Koch) Date: Mon Oct 29 09:50:02 2001 Subject: GnuPG for OS/2 In-Reply-To: (roconnor@math.berkeley.edu's message of "Mon, 29 Oct 2001 00:01:22 -0800 (PST)") References: Message-ID: <874roial19.fsf@alberti.gnupg.de> On Mon, 29 Oct 2001 00:01:22 -0800 (PST), roconnor said: > I wrote a Rexx Entropy Gathering Daemon > based on the Perl EGD. > It's not as good as a driver to gather interupt infromation, but should be > about as good as the Perl EGD. But what do you use as source for the entropy? It may have changed in recent version of OS/2 but I am not aware of any system services which can be used. The only way I can think to do it is by writing Device drivers becuase this way you can get in closer touch with the kernel. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From rabbi@quickie.net Mon Oct 29 10:03:01 2001 From: rabbi@quickie.net (Len Sassaman) Date: Mon Oct 29 10:03:01 2001 Subject: Windoze question In-Reply-To: Message-ID: On Thu, 25 Oct 2001, Andrew Marlow wrote: > License permitting, I would recommend GPG over PGP since I think GPG has a > closer eye on the RFC and other issues, such as crypto-law and patent law. > GPG has also taken some decisions which have made it less vunerable to > certain problems (e.g the ADK issue). Just about all of the above statements are not based on fact. -- Len Sassaman Security Architect | "Now it's all change -- Technology Consultant | It's got to change more." | http://sion.quickie.net | --Joe Jackson From roconnor@math.berkeley.edu Mon Oct 29 16:45:02 2001 From: roconnor@math.berkeley.edu (roconnor@math.berkeley.edu) Date: Mon Oct 29 16:45:02 2001 Subject: GnuPG for OS/2 In-Reply-To: <874roial19.fsf@alberti.gnupg.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 29 Oct 2001, Werner Koch wrote: > But what do you use as source for the entropy? It may have changed in > recent version of OS/2 but I am not aware of any system services which > can be used. The only way I can think to do it is by writing Device > drivers becuase this way you can get in closer touch with the kernel. Well, I use system and network statistics like the Perl EGD does. I use - -list of processes running - -how long they have been running - -how long the computer has been up - -the time - -list of running threads and their state - -list of semaphores - -list of loaded modules - -free memory available - -network mbufs - -udp stats - -ip stats - -current socket stats - -current routing table (and use stats) - -general interface stats - -arp table - -- Russell O'Connor roconnor@alumni.uwaterloo.ca ``This is not a time, as it is never a time, to seek vengeance, but a time to seek the courage to forgive'' -- George W. Bush -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (SunOS) Comment: For info see http://www.gnupg.org iD8DBQE73XjuZG3em5NXM14RAlMZAJwIEzXcq3IijE05UWvMBti2bmMXmACdHLSf qO0c+l/dcIErAYxoQN+qRgk= =ONUi -----END PGP SIGNATURE----- From JanuszA.Urbanowicz Wed Oct 31 22:04:01 2001 From: JanuszA.Urbanowicz (JanuszA.Urbanowicz) Date: Wed Oct 31 22:04:01 2001 Subject: trust problem in the b snapshot Message-ID: Problems with trust calculation - again: The environment is: :alex@sword:[~]:11:> gpg --version gpg (GnuPG) 1.0.6b [..] I signed and set trust for following keys: pub 1024D/826BAA66 created: 2001-07-14 expires: never trust: f/f pub 1024D/FC494FC4 created: 2000-12-06 expires: never trust: f/f pub 1024D/F9289982 created: 1997-10-13 expires: never trust: f/f pub 2048R/2C67FD2D created: 1999-05-18 expires: never trust: f/f Now I import 7AA3260A from certserver.pgp.com which is signed by the keys I trust: pub 1024D/7AA3260A 2000-05-13 Artur Stepien sig 7AA3260A 2000-11-21 Artur Stepien sig 826BAA66 2001-07-16 Robert R. Wal (Gadzinka) sig FC494FC4 2001-07-19 Miros/law Baran (Jubal) uid Artur Stepien (Muczachan) sig 7AA3260A 2000-11-21 Artur Stepien sig 826BAA66 2001-07-16 Robert R. Wal (Gadzinka) sig FC494FC4 2001-07-19 Miros/law Baran (Jubal) uid Artur St\xc3\xaapie\xc3\xb1 (Muczachan) sig 7AA3260A 2000-05-13 Artur Stepien sig 826BAA66 2001-07-14 Robert R. Wal (Gadzinka) sig 2C67FD2D 2001-07-14 Robert R. Wal (PGP2 RSA key) sig 0CA7686C 2000-11-21 [User id not found] sig F9289982 2000-09-12 Szymon Sokol sig FC494FC4 2001-07-19 Miros/law Baran (Jubal) sub 2048g/04706BBF 2000-05-13 sig 7AA3260A 2000-05-13 Artur Stepien but I got no trust for the key?! pub 1024D/7AA3260A created: 2000-05-13 expires: never trust: -/- Alex -- Janusz A. Urbanowicz | ALEX3-RIPE | SF-Framling | Thawte Web Of Trust Notary Gdy dajê biednym chleb, nazywaj± mnie ¶wiêtym. Gdy pytam, dlaczego biedni nie maj± chleba, nazywaj± mnie komunist±. - abp. Helder Camara From halpin@qwpage.com Wed Oct 31 23:42:01 2001 From: halpin@qwpage.com (halpin@qwpage.com) Date: Wed Oct 31 23:42:01 2001 Subject: Making GnuPg w/Cygwin Message-ID: <3BE03802.16183.AA96018@localhost> Hello all, this is my first post. Right off the bat you'll have to forgive me - I work on a Windoze box. So, speak slowly and use simple words. :-) I've used Cygwin successfully in the past to make Win32 Tcl/Tk binaries that run on this box, so I think my my environment is fairly sound. The versions are: Cygwin B20 gcc version egcs-2.91.57 19980901 (egcs-1.1 release) GNU assembler version 2.9.4 (i586-cygwin32) using BFD version 2.9.4 GNU Make version 3.75 I'm trying to make GnuPg 1.0.6 Problem 1 ---------------- bash-2.02$ cd //d/gnupg-1.0.6 bash-2.02$ cd zlib bash-2.02$ make clean test -z "libzlib.a" || rm -f libzlib.a test -z "foo.gz" || rm -f foo.gz rm -f *.o core *.core bash-2.02$ make gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -c adler32.c gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -c compress.c gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -c inffast.c rm -f libzlib.a ar cru libzlib.a adler32.o compress.o crc32.o uncompr.o libzlib.a libzlib.a: 1: Syntax error: redirection unexpected make: *** [libzlib.a] Error 2 bash-2.02$ In the MAKEFILE I see: RANLIB = libzlib.a: $(libzlib_a_OBJECTS) $(libzlib_a_DEPENDENCIES) -rm -f libzlib.a $(AR) cru libzlib.a $(libzlib_a_OBJECTS) $(libzlib_a_LIBADD) $(RANLIB) libzlib.a If I remove the last line ($(RANLIB) libzlib.a, I can get all the way through. Is this the correct thing to do? (There is a ranlib in my cygwin bin directory.) Problem 2 -------------- Having removed the RANLIB statements in several of the MAKEFILEs, I now get this: `echo gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../intl -g -O2 -Wall -D IS_MODULE -shared -fPIC -o tiger ./tiger.c | \ sed -e 's/-O[2-9s]*/-O/g' ` gcc: unrecognized option `-shared' In file included from ./tiger.c:26: ..\include\util.h:207: warning: `stricmp' redefined C:\cygnus\CYGWIN~1\H-I586~1\bin\..\lib\gcc-lib\i586-cygwin32\egcs- 2.91.57\..\..\ ..\..\i586-cygwin32\include\string.h:76: warning: this is the location of the previous definition /cygnus/CYGWIN~1/H-I586~1/i586-cygwin32/bin/as.exe: bfd assertion fail /home/noer/src/b20/comp-tools/devo/bfd/coff-i386.c:479 C:\Temp\ccz8EiPb.s: Assembler messages: C:\Temp\ccz8EiPb.s:2261: Error: Cannot represent relocation type BFD_RELOC_386_GOTPC /cygnus/CYGWIN~1/H-I586~1/i586-cygwin32/bin/as.exe: bfd assertion fail /home/noer/src/b20/comp-tools/devo/bfd/coff-i386.c:479 C:\Temp\ccz8EiPb.s:2357: Error: Cannot represent relocation type BFD_RELOC_386_GOTPC /cygnus/CYGWIN~1/H-I586~1/i586-cygwin32/bin/as.exe: bfd assertion fail /home/noer/src/b20/comp-tools/devo/bfd/coff-i386.c:479 C:\Temp\ccz8EiPb.s:2565: Error: Cannot represent relocation type BFD_RELOC_386_GOTPC /cygnus/CYGWIN~1/H-I586~1/i586-cygwin32/bin/as.exe: bfd assertion fail /home/noer/src/b20/comp-tools/devo/bfd/coff-i386.c:479 C:\Temp\ccz8EiPb.s:2931: Error: Cannot represent relocation type BFD_RELOC_386_GOTPC /cygnus/CYGWIN~1/H-I586~1/i586-cygwin32/bin/as.exe: bfd assertion fail /home/noer/src/b20/comp-tools/devo/bfd/coff-i386.c:479 C:\Temp\ccz8EiPb.s:3200: Error: Cannot represent relocation type BFD_RELOC_386_GOTPC /cygnus/CYGWIN~1/H-I586~1/i586-cygwin32/bin/as.exe: bfd assertion fail /home/noer/src/b20/comp-tools/devo/bfd/coff-i386.c:479 C:\Temp\ccz8EiPb.s:3356: Error: Cannot represent relocation type BFD_RELOC_386_GOTPC /cygnus/CYGWIN~1/H-I586~1/i586-cygwin32/bin/as.exe: bfd assertion fail /home/noer/src/b20/comp-tools/devo/bfd/coff-i386.c:479 C:\Temp\ccz8EiPb.s:3761: Error: Cannot represent relocation type BFD_RELOC_386_GOTPC /cygnus/CYGWIN~1/H-I586~1/i586-cygwin32/bin/as.exe: bfd assertion fail /home/noer/src/b20/comp-tools/devo/bfd/coff-i386.c:479 C:\Temp\ccz8EiPb.s:3875: Error: Cannot represent relocation type BFD_RELOC_386_GOTPC make[2]: *** [tiger] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive-am] Error 2 :-( Asserts, eh? Who the heck do 'ya call on this? -------------------------------------------- Any tips appreciated - and if this is posted to the wrong list please accept my apologies. Regards Bob Halpin (I may be crazy, but I'm not (too) stupid.) P.S. - Anybody got a MAKEFILE for Borland? From jshayward@pobox.com Mon Oct 1 20:47:08 2001 From: jshayward@pobox.com (Jonathan Hayward -- http://JonathansCorner.com) Date: Mon Oct 1 19:47:08 2001 Subject: gpg initialization Message-ID: <3BB84CCE.6CCBA5C1@pobox.com> --------------E38B76217F7A0792CE6D3082 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Is there any documentation (besides the comments/code) to how gpg initializes? -- Jonathan Hayward jshayward@pobox.com http://JonathansCorner.com (A four dimensional maze, stories, essays, artwork, and other things...) --------------E38B76217F7A0792CE6D3082 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Is there any documentation (besides the comments/code) to how gpg initializes?
-- 
Jonathan Hayward
jshayward@pobox.com
http://JonathansCorner.com
(A four dimensional maze, stories, essays, artwork, and other things...)
  --------------E38B76217F7A0792CE6D3082-- From mbp2@Lehigh.EDU Mon Oct 1 23:15:01 2001 From: mbp2@Lehigh.EDU (mbp2@Lehigh.EDU) Date: Mon Oct 1 22:15:01 2001 Subject: Adding recipients to an encrypted message? Message-ID: <1001967174.3bb8ce46744b5@IMP.Lehigh.EDU> A suggestion for a new feature... the ability to add recipients to an encrypted message. If I have a file or message that's encrypted to me, and I want to give it securely to someone else, it's awkward to have to decrypt the whole thing and then re-encrypt it again to the new person, especially if the file is large. It'd be very useful if I could tell GPG to decrypt the session key using my private key and immediately encrypt it (just the session key) with the new person's public key, and then add a new recipient packet to the message without touching the encrypted message body. This is not only more secure (it's easier to wipe a small decrypted session key from memory than a whole decrypted message), but also faster and more convenient. -- Mike Paul mbp2@lehigh.edu http://www.lehigh.edu/~mbp2/ From wk@gnupg.org Tue Oct 2 00:36:01 2001 From: wk@gnupg.org (Werner Koch) Date: Mon Oct 1 23:36:01 2001 Subject: Adding recipients to an encrypted message? In-Reply-To: <1001967174.3bb8ce46744b5@IMP.Lehigh.EDU> (mbp2@Lehigh.EDU's message of "Mon, 01 Oct 2001 16:12:54 -0400 (EDT)") References: <1001967174.3bb8ce46744b5@IMP.Lehigh.EDU> Message-ID: <878zev3v0j.fsf@alberti.gnupg.de> On Mon, 01 Oct 2001 16:12:54 -0400 (EDT), mbp2 said: > then re-encrypt it again to the new person, especially if the file is large. > It'd be very useful if I could tell GPG to decrypt the session key using my > private key and immediately encrypt it (just the session key) with the new have a look at the options $ gpg --dump-options |grep session --show-session-key --override-session-key The simplest way would be something like this: $ gpg --show-session-key -o foo.txt foo.gpg 2>&1 \ | gpg -e -r key-escrow@privacy.gov | mail solo@u.n.c.l.e And on the u.n.c.l.e site Napoleon could do this: $ gpg --override-session-key extracted_from_mail msg_from_echelon Well you can also use the session key to create a public key encrypted packet and prepend it to the message - however there is no direct support for it in GnuPG. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From mbp2@Lehigh.EDU Tue Oct 2 04:36:01 2001 From: mbp2@Lehigh.EDU (mbp2@Lehigh.EDU) Date: Tue Oct 2 03:36:01 2001 Subject: Adding recipients to an encrypted message? Message-ID: <1001986429.3bb9197d660f9@IMP.Lehigh.EDU> I was thinking of something that would produce an ordinary OpenPGP message that can be decrypted normally to the new recipient... maybe the recipient isn't convinced of the usefulness of cryptography in the first place, or is using commercial PGP so they can't use --override-session-key, or both. In both the GPG documentation and your example, the --show-session key option is described as being meant for key-escrow purposes. I'm talking about the more casual act of forwarding a message to someone. It shouldn't be too hard to add an option... something like "gpg --add-recipient ciphertext.gpg newrecipient@foo.com" which would extract the session key and add a new recipient packet to the message. (I'm submitting to the list without being subscribed so hopefully the threading will work correctly...) -- Mike Paul mbp2@lehigh.edu http://www.lehigh.edu/~mbp2/ From wk@gnupg.org Tue Oct 2 10:54:01 2001 From: wk@gnupg.org (Werner Koch) Date: Tue Oct 2 09:54:01 2001 Subject: Adding recipients to an encrypted message? In-Reply-To: <1001986429.3bb9197d660f9@IMP.Lehigh.EDU> (mbp2@Lehigh.EDU's message of "Mon, 01 Oct 2001 21:33:49 -0400 (EDT)") References: <1001986429.3bb9197d660f9@IMP.Lehigh.EDU> Message-ID: <87vghy32fg.fsf@alberti.gnupg.de> On Mon, 01 Oct 2001 21:33:49 -0400 (EDT), mbp2 said: > described as being meant for key-escrow purposes. I'm talking about the more > casual act of forwarding a message to someone. It shouldn't be too hard to add I can't think of a situation where you want to forward an encrypted message to another recipient without reading the message first. -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From Florian.Weimer@RUS.Uni-Stuttgart.DE Tue Oct 2 16:26:01 2001 From: Florian.Weimer@RUS.Uni-Stuttgart.DE (Florian Weimer) Date: Tue Oct 2 15:26:01 2001 Subject: Adding recipients to an encrypted message? In-Reply-To: <87vghy32fg.fsf@alberti.gnupg.de> (Werner Koch's message of "Tue, 02 Oct 2001 09:51:15 +0200") References: <1001986429.3bb9197d660f9@IMP.Lehigh.EDU> <87vghy32fg.fsf@alberti.gnupg.de> Message-ID: Werner Koch writes: > On Mon, 01 Oct 2001 21:33:49 -0400 (EDT), mbp2 said: > I can't think of a situation where you want to forward an encrypted > message to another recipient without reading the message first. Encrypted mailing lists could be implemented more efficiently if the main message part would not have to be encrypted over and over again. (Because of padding, the reused session key should not be a problem even with RSA, but I'm not sure about that.) -- Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 From pgut001@cs.auckland.ac.nz Tue Oct 2 17:15:01 2001 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) Date: Tue Oct 2 16:15:01 2001 Subject: Adding recipients to an encrypted message? Message-ID: <200110021412.CAA135615@ruru.cs.auckland.ac.nz> Florian Weimer writes: >Werner Koch writes: >>On Mon, 01 Oct 2001 21:33:49 -0400 (EDT), mbp2 said: >>I can't think of a situation where you want to forward an encrypted >>message to another recipient without reading the message first. >Encrypted mailing lists could be implemented more efficiently if the main >message part would not have to be encrypted over and over again. (Because of >padding, the reused session key should not be a problem even with RSA, but I'm >not sure about that.) The S/MIME folks have looked at this problem in some detail over quite some time, there are RFCs/RFC drafts available from the S/MIME WG home page http://www.imc.org/ietf-smime/index.html. (They also have a second home page at http://www.ietf.org/html.charters/smime-charter.html which has a non- overlapping set of drafts, you may need to check there. Try and ignore the fact that the page is shared with drafts on how to do X.400 with S/MIME). Peter. From sosa1004kr@yahoo.co.kr Thu Oct 4 22:43:03 2001 From: sosa1004kr@yahoo.co.kr (ÃÊû°­¿¬) Date: Thu Oct 4 21:43:03 2001 Subject: [ÃÊû°­¿¬ È«º¸] ±× ´©°¡ °¨È÷ Çй®Àº ¾ø¾ú´Ù°í ¿ÜÃÆ´ø°¡? Message-ID: <200110041940.f94Jeard020040@mail.openit.de> PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPGh0 bWw+DQo8aGVhZD4NCjx0aXRsZT6iwCC9xcH2vcTAziDDysO7ILCtv6zIuCCiwDwvdGl0bGU+ DQoNCjxtZXRhIG5hbWU9IkdFTkVSQVRPUiIgY29udGVudD0iTmFtbyBXZWJFZGl0b3IgdjQu MCI+DQo8L2hlYWQ+DQo8Qk9EWT4NCjxQIGFsaWduPWxlZnQ+PEZPTlQgc2l6ZT0yPjxTUEFO IA0Kc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IGZ1Y2hzaWEiPjwvU1BBTj48L0ZPTlQ+PEZP TlQgc2l6ZT0yPjxTUEFOIA0Kc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IGZ1Y2hzaWEiPjxT UEFOIHN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiB3aGl0ZSI+PEZPTlQgDQpzaXplPTE+vsiz 58fPvLy/5C4guru43sDPwLogsK2/rMi4IMiruri4piDAp8fPv6kmbmJzcDsxyLi8uiC43sDP wMy45yC43sDPIMioxuTAzMH2v80gsNS9w8bHv6G8rSANCrz2wf21yLDNwNS0z7TZPC9GT05U PjwvU1BBTj48L1NQQU4+PC9GT05UPjwvUD4NCjxQIGFsaWduPWNlbnRlcj48Rk9OVCBzaXpl PTU+PFNQQU4gc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IGZ1Y2hzaWEiPqLAIL3Fwfa9xMDO IMPKw7sgDQqwrb+syLggosA8L1NQQU4+PC9GT05UPjxGT05UIGNvbG9yPWJsYWNrPjxTUEFO IA0Kc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IHdoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L1NQQU4+PC9GT05UPjwvUD4NCjxQIGFsaWduPWxl ZnQ+PEZPTlQgY29sb3I9YmxhY2s+PFNQQU4gc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IHdo aXRlIj7BpLq4yK0gvcO067+hIMH2wPsgDQrIo7HivcnAzCC4ucC6ILTnvcUgISE8QlI+PEJS PjwvU1BBTj48L0ZPTlQ+PFNQQU4gc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IHdoaXRlIj69 xcH2vcTAziDDysO7IA0Kuau34SCwrb+syLi/oSC01MC7IMPKtOvHz7DtwNogx9W0z7TZLjwv U1BBTj48Rk9OVCBjb2xvcj1uYXZ5PjxTUEFOIA0Kc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6 IHdoaXRlIj48QlI+Jm5ic3A7PC9TUEFOPjwvRk9OVD48L1A+DQo8UCBhbGlnbj1sZWZ0PjxG T05UIGNvbG9yPWJsYWNrPjxTUEFOIHN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiB3aGl0ZSI+ wfax3bHuwfYgsdcgtKmwoSANCrCoyPcgPC9TUEFOPjwvRk9OVD48Rk9OVCBjb2xvcj0jNDAw MDQwPjxTUEFOIA0Kc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IHdoaXRlIj48U1RST05HPsfQ ua7AuiC++L76tNk8L1NUUk9ORz48L1NQQU4+PC9GT05UPjxTUEFOIA0Kc3R5bGU9IkJBQ0tH Uk9VTkQtQ09MT1I6IHdoaXRlIj48Rk9OVCBjb2xvcj1ibGFjaz6w7SANCr/cw8a0+LChPzxC Uj4mbmJzcDs8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9TUEFOPjwvRk9OVD48Rk9O VCBjb2xvcj1ibHVlPjxTUEFOIA0Kc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IHdoaXRlIj7H 0LmuPC9TUEFOPjwvRk9OVD48Rk9OVCBjb2xvcj1ibGFjaz48U1BBTiANCnN0eWxlPSJCQUNL R1JPVU5ELUNPTE9SOiB3aGl0ZSI+wMy29T8gLSA8U1BBTiANCnN0eWxlPSJCQUNLR1JPVU5E LUNPTE9SOiB3aGl0ZSI+PC9TUEFOPjxGT05UIGNvbG9yPWJsYWNrIHNpemU9Mj48U1BBTiAN CnN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiB3aGl0ZSI+u+e5sMDHIMDMxKG/zSC6u8H6wLsg sdS47cfPtMIgDQqwzcDMtNkuPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyANCrmwwfrAxyDD1rzStNzAp8DOIL/4wNouLiAmbmJzcDu/+MDa ILzTwMcgwPzA2rTCILmrvbwgv6GzysH2t84gtbm+xrChsO0gwNa0wrChPzwvU1BBTj48L1NQ QU4+PC9GT05UPjwvUD4NCjxQIGFsaWduPWxlZnQ+PEZPTlQgY29sb3I9Ymx1ZT48U1BBTiAN CnN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiB3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7vcXH0DwvU1BBTj48L0ZPTlQ+PEZPTlQgDQpjb2xvcj1ibGFjaz48U1BBTiBzdHlsZT0i QkFDS0dST1VORC1DT0xPUjogd2hpdGUiPsDMtvU/IC0gPFNQQU4gDQpzdHlsZT0iQkFDS0dS T1VORC1DT0xPUjogd2hpdGUiPjwvU1BBTj48Rk9OVCBjb2xvcj1ibGFjayBzaXplPTI+PFNQ QU4gDQpzdHlsZT0iQkFDS0dST1VORC1DT0xPUjogd2hpdGUiPr3Fv6EgtOvH2CCz7cfPtMIg DQrH0LmuPz8/Pz88QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7sde3syANCr3FwMcgurvB+sC6IA0Kuau++cDOsKE/PEJSPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxTUEFOIA0Kc3R5bGU9IkJBQ0tHUk9VTkQtQ09M T1I6IHdoaXRlIj48L1NQQU4+PC9GT05UPjxGT05UIHNpemU9Mj48U1BBTiANCnN0eWxlPSJC QUNLR1JPVU5ELUNPTE9SOiB3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7vcXAuyC+y8H2IA0KuPjHz7TCtaUgvu62u7DUIL3Fv6EgtOvH2CCz7cfS ILz2IMDWtMKwoT88L1NQQU4+PC9TUEFOPjwvRk9OVD48L1A+DQo8UCBhbGlnbj1sZWZ0PjxG T05UIGNvbG9yPWJsYWNrPjxTUEFOIHN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiB3aGl0ZSI+ x9C5rrD6IL3FwLsgDQrD37G4x8+0wiA8L1NQQU4+PC9GT05UPjxGT05UIGNvbG9yPWJsdWU+ PFNQQU4gc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IHdoaXRlIj7AzrCjwLogsPq/rCANCr7u trIgwbjA5zwvU1BBTj48L0ZPTlQ+PEZPTlQgY29sb3I9YmxhY2s+PFNQQU4gDQpzdHlsZT0i QkFDS0dST1VORC1DT0xPUjogd2hpdGUiPsDOsKE/PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO7bHIA0KPC9TUEFOPjwvRk9OVD48Rk9OVCBjb2xvcj1i bHVlPjxTUEFOIHN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiB3aGl0ZSI+wM6wo8DHILq7wfqw +iANCrzTvLo8L1NQQU4+PC9GT05UPjxGT05UIGNvbG9yPWJsYWNrPjxTUEFOIHN0eWxlPSJC QUNLR1JPVU5ELUNPTE9SOiB3aGl0ZSI+wLogsPq/rCANCr7utrDH0bChPzxCUj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDvAzrCjwMcgDQq757DtwMcgxse0 3CCx4sHYwLogsPq/rCDBpMiux9EgsM3AzrChPyA8QlI+Jm5ic3A7PC9TUEFOPjwvRk9OVD48 L1A+DQo8UCBhbGlnbj1sZWZ0PjxGT05UIGNvbG9yPWJsYWNrPjxTUEFOIHN0eWxlPSJCQUNL R1JPVU5ELUNPTE9SOiB3aGl0ZSI+wfax3bHuwfYgwfi4rrbzsO0gDQq5z77uv9S0+CChwaHB ocEgJm5ic3A7PC9TUEFOPjwvRk9OVD48Rk9OVCBjb2xvcj1yZWQ+PFNQQU4gDQpzdHlsZT0i QkFDS0dST1VORC1DT0xPUjogd2hpdGUiPrv9ISDA2iEgx8ohILjqITwvU1BBTj48L0ZPTlQ+ PC9QPg0KPFAgYWxpZ249bGVmdD48Rk9OVCBjb2xvcj1ibGFjaz48U1BBTiBzdHlsZT0iQkFD S0dST1VORC1DT0xPUjogd2hpdGUiPjIxvLyx4iC8vLDowMcgDQrD1sO3tNwgudnAzL/AILD6 x9DA2rXpv6EgwMfH2CCx17DNwMwgsMXB/sDTwMwgueDH9MH2sO0sIDxCUj48QlI+PFNQQU4g DQpzdHlsZT0iQkFDS0dST1VORC1DT0xPUjogd2hpdGUiPjwvU1BBTj48Rk9OVCBjb2xvcj1i bGFjayBzaXplPTI+PFNQQU4gDQpzdHlsZT0iQkFDS0dST1VORC1DT0xPUjogd2hpdGUiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0gDQrAr8D8 x9DA2rXpIDogMjCz4rO7IMDOsKMgvPa47SA0MLvsIL3DtOu/wrTZIC0gvbrG98P3IMG2vLEg MTk5Mi4gOS4gDQoxOS48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7wdfAvcC6IA0KwNq/rL+hIL+qx+DHz7TC IA0KsM3AzLTZLjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDvAzrCjwLogDQq4u8fPwNq46SCx1yDA2sO8sKEg wNq1vyC6uLz2IA0KwNrEocDMtNkuPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyiz67qnIA0KyK3H0LvzILz2u/PA2sDOILnMsbnAxyC288DMs8q9uiDG+ri1ILna u+cpPC9TUEFOPjwvU1BBTj48L0ZPTlQ+PC9QPg0KPFAgYWxpZ249bGVmdD48Rk9OVCBjb2xv cj1ibGFjayBzaXplPTI+PFNQQU4gDQpzdHlsZT0iQkFDS0dST1VORC1DT0xPUjogd2hpdGUi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0gDQq6 0rfOutK75yDAr8D8wNogud+w3yC538elIDogucyxuSC3zr26ILGzvPYgJm5ic3A7MTk5ObPi IDe/+SA1wM88L1NQQU4+PC9GT05UPjwvUD4NCjxQIGFsaWduPWxlZnQ+PEZPTlQgY29sb3I9 YmxhY2sgc2l6ZT0yPjxTUEFOIA0Kc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IHdoaXRlIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstIA0Kv+y4 riC49iC807+hIL+1u/3AuyCx4r7vx8+0wiC8vMb3tenAzCANCsDWtNk8QlI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0OyANCjE5OTGz4iA4v/kgucyxuSBBQkMg VFYguea828DHILrSu+e/oSCw/MfRIFRWIMXkt9AmZ3Q7PEJSPjxTUEFOIA0Kc3R5bGU9IkJB Q0tHUk9VTkQtQ09MT1I6IHdoaXRlIj48L1NQQU4+PEZPTlQgY29sb3I9YmxhY2s+PFNQQU4g DQpzdHlsZT0iQkFDS0dST1VORC1DT0xPUjogd2hpdGUiPjxCUj48L1NQQU4+PC9GT05UPjxG T05UIGNvbG9yPXJlZD48U1BBTiANCnN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiB3aGl0ZSI+ PC9TUEFOPjwvRk9OVD48U1RST05HPjxGT05UIHNpemU9Mz48U1BBTiANCnN0eWxlPSJCQUNL R1JPVU5ELUNPTE9SOiB3aGl0ZSI+vLHB+CDDt7TcIMfQua7AuiC/z8D8IMH4uK64piDD37G4 IMXrx9ggutK3zrrSu+co3dXW1d3V3t0puKYguPHHpbfOIA0Kud/A/DwvU1BBTj48Rk9OVCBj b2xvcj1ibGFjaz48U1BBTiBzdHlsZT0iQkFDS0dST1VORC1DT0xPUjogd2hpdGUiPrXHsO0g DQrA1r3AtM+02S48L1NQQU4+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9TVFJPTkc+PC9QPg0K PFAgYWxpZ249bGVmdD48Rk9OVCBzaXplPTM+PFNUUk9ORz48U1BBTiBzdHlsZT0iQkFDS0dS T1VORC1DT0xPUjogd2hpdGUiPrq7ILCtv6zIuLTCIA0KutK3zrrSu+cgsdcgwaS787+hvK0g udm287q7PC9TUEFOPjxGT05UIGNvbG9yPXJlZD48U1BBTiBzdHlsZT0iQkFDS0dST1VORC1D T0xPUjogd2hpdGUiPiANCjwvU1BBTj48L0ZPTlQ+PC9TVFJPTkc+PC9GT05UPjxTUEFOIHN0 eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiB3aGl0ZSI+PEZPTlQgDQpzaXplPTM+PFNUUk9ORz6/ z8D8x9Egx9C5riwgwb6xsywgsPrH0C4uLi7AuyAmbmJzcDu/qbevutC16b+hsNQgwPzH2CC1 5biusO3A2iDH1bTPtNkuPC9TVFJPTkc+PC9GT05UPiANCjwvU1BBTj48L1A+DQo8UCBhbGln bj1sZWZ0PjxGT05UIGNvbG9yPXJlZD48U1BBTiBzdHlsZT0iQkFDS0dST1VORC1DT0xPUjog d2hpdGUiPjxGT05UIA0KY29sb3I9IzAwMDAwMD7B+MPrwPvAzLjnIL+tuLAguLbAvcC4t84g wfa9xMC7ILClsbjHz7TCIMDMtenAxyC4uLOywMcgvcOwo8DMILXHvcOx5iANCrnZtvi0z7TZ LjwvRk9OVD48QlI+PC9QPjwvU1BBTj48L0ZPTlQ+DQo8UCBhbGlnbj1sZWZ0PjxGT05UIGNv bG9yPWJsYWNrPjxTUEFOIHN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiBhcXVhIj7AzyANCiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO73DIDogMjAwMbPiIDEwv/kgNsDPIL/AyMQg M73DPC9TUEFOPjwvRk9OVD48L1A+DQo8UCBhbGlnbj1sZWZ0PjxGT05UIGNvbG9yPWJsYWNr PjxTUEFOIHN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiBhcXVhIj7A5SANCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO7zSIDogus7DtSC9w7nOIMi4sPwgvNKwrbTnPC9TUEFOPjwv Rk9OVD48L1A+DQo8UCBhbGlnbj1sZWZ0PjxGT05UIGNvbG9yPWJsYWNrPjxTUEFOIA0Kc3R5 bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IHdoaXRlIj48L1NQQU4+PC9GT05UPiZuYnNwOzwvUD48 L0ZPTlQ+PC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9GT05UPg0KPC9CT0RZPg0KPC9odG1sPg0K From jan@intevation.de Fri Oct 5 15:07:01 2001 From: jan@intevation.de (Jan-Oliver Wagner) Date: Fri Oct 5 14:07:01 2001 Subject: ANN: Sphinx (S/MIME, X.509) project for MUAs (KMail, mutt) Message-ID: <20011005140441.B14526@intevation.de> Dear list, we are happy to announce that the German "Bundesamt für Sicherheit in der Informationstechnik" (Federal Agency for IT Security, BSI) contracted us (Intevation, Klarälvdalens Datakonsult and g10 Code) to make sure that Free Software for their email security standard Sphinx will be created. Sphinx basically consists of S/MIME, a PKIX compatible X.509 profile, together with certificate revocation lists (CRLs) based on LDAP. The code developed will be modular allowing inclusion in several MUAs released under the GNU GPL. Part of the contract with the BSI is the inclusion in mutt and KMail. The initial project pages can be reached from the URL below. We wanted to get the good news out to you as fast as possible. Expect more information to get released on the website or on the corresponding mailing lists. We plan to do the development in an open manner suitable for Free Software projects. We want to handle the project in a way that it will leverage and add to the work of other developers and ask for your collaboration. The BSI pays us to ensure that their specs are followed precisely and the result passes strict tests. This is the first time the BSI contracts for Free Software development and the experiences they make will be important. We will demonstrate the power of commercial Free Software. www.gnupg.org/aegypten -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From bre@klaki.net Fri Oct 5 18:50:02 2001 From: bre@klaki.net (Bjarni R. Einarsson) Date: Fri Oct 5 17:50:02 2001 Subject: Strange problem with GnuPG 1.0.4 encrypted data Message-ID: <20011005154830.F15179@klaki.net> Hello, I have a system which GPG encrypts and signs files and mails them from one machine to another, where they are automatically decrypted and the signatures verified using a perl program. Last night a file was transferred which appeared to have a valid signature, but then couldn't be decrypted. Gnupg sent the following message to stderr: gpg: Warning: using insecure memory! gpg: encrypted with 1024-bit ELG-E key, ID FAFF94B3, created 2001-09-20 [snip] gpg: Signature made Thu Oct 4 20:45:46 2001 GMT using DSA key ID 327144DC gpg: Good signature from "[snip]" 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: B083 585B 8675 0058 5113 0F98 FA17 F199 3271 44DC gpg: [don't know]: invalid packet (ctb=14) The file was encrypted on a dual PIII 800Mhz machine using GnuPG 1.0.4 as distributed with RedHat Linux 7.1. I tried decrypting it both with GnuPG 1.0.4 and 1.0.6 (RH 7.1 update package), with the same results. I haven't been able to reproduce this problem yet, but since I'm creating and sending dozens of messages like this every day (usually without any problems) I rather expect it to manifest itself again sooner or later. My question is whether any bugs were found in GnuPG 1.0.4 which could cause this kind of bizarre failure, or whether I should start worrying about hardware problems. Also, am I correct in assuming that since the signature was OK, that I can rule out any transmission errors as the cause of this and focus on the creation of the encrypted file? If you developers feel this is a bug and that it would help to examine the file in question I have no problems sharing it and the necessary keys with you - I'm currently just testing this setup and regenerating my keys would be no big deal. Please CC: any replies directly to me, as I'm not subscribe to this list - and please forgive me if I overlooked a more appropriate venue for this message. Thanks! -- Bjarni R. Einarsson PGP: 02764305, B7A3AB89 bre@klaki.net -><- http://bre.klaki.net/ Check out my open-source email sanitizer: http://mailtools.anomy.net/ From jpg@rcom.com.ar Fri Oct 12 21:48:01 2001 From: jpg@rcom.com.ar (Juan Pablo =?ISO-8859-1?Q?Gim=E9nez?=) Date: Fri Oct 12 20:48:01 2001 Subject: gnupg Message-ID: <1002912389.10546.9.camel@kang.oficina.rcom.com.ar> --=-pTgFCmnR2fd7e/Nxvb5l Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi! I have a problem with the option "--with-colons" and --list-keys or --fingerprint, if i don't use it, gpg print my last name "Gim=E9nez" with the "=E9", but if I put with-colons insted of "=E9" gpg prints "=C3=A9"... = So here is the patch to fix it... ------------------------------------------------------------------------ ________________________________________________________________________ --- gnupg-1.0.6/g10/keylist.c Sun May 27 11:31:07 2001 +++ gnupg-1.0.6_rcom/g10/keylist.c Fri Oct 12 11:42:15 2001 @@ -482,8 +482,8 @@ printf("uid:%c::::::::", trustletter); } } - print_string( stdout, node->pkt->pkt.user_id->name, - node->pkt->pkt.user_id->len, ':' ); + print_utf8_string( stdout, node->pkt->pkt.user_id->name, + node->pkt->pkt.user_id->len); putchar(':'); if (any) putchar('\n'); ________________________________________________________________________ ------------------------------------------------------------------------- Chausesssssssssss Juan Pablo.... --=-pTgFCmnR2fd7e/Nxvb5l Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA7xzqFChXsK9PY/SsRAnkSAKCYjyqImAW+y7bs/AO79kIIQhs8oACePYXD lNsurU8tCaAj8V+uVZZkpoE= =9+Yx -----END PGP SIGNATURE----- --=-pTgFCmnR2fd7e/Nxvb5l-- From redbird@rbisland.cx Sun Oct 14 08:24:02 2001 From: redbird@rbisland.cx (Gordon Worley) Date: Sun Oct 14 07:24:02 2001 Subject: Goodbye 4th Amendment Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 http://arstechnica.com/wankerdesk/01q4/usa-act/usa-act.html Well, as some of you may already know, I and some of my fellow developers no longer have our 4th Amendment rights (protection from search and seizure for those of you who live outside the US). I don't know what the immediate effects will be for the project, other than that I may have to make sure binary releases are done all in one sitting use a fresh download of the source (may seem a little silly, but I'd rather be silly than release binaries with bad stuff in them). If you read the story on how this got passed, similar procedures could see anti-crypto laws passed through, though I think after this it will be some time before the House will stand for this. - -- 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 -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use Comment: keyserver http://pgpkeys.mit.edu:11371 iQA/AwUBO8kg627zd/e707ADEQKEZgCg4ouaFNX6ssrkDwLZzPJcdfRVQ2UAoJJL +v6iHEybHuLI+UkBKAlc/VhG =tpGT -----END PGP SIGNATURE----- From redbird@rbisland.cx Sun Oct 14 08:33:01 2001 From: redbird@rbisland.cx (Gordon Worley) Date: Sun Oct 14 07:33:01 2001 Subject: Goodbye 4th Amendment In-Reply-To: References: Message-ID: At 1:20 AM -0400 10/14/01, Gordon Worley wrote: Sorry, folks, that was supposed to go to the Mac GPG developer's list. -- 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 dshaw@jabberwocky.com Sun Oct 14 20:28:02 2001 From: dshaw@jabberwocky.com (David Shaw) Date: Sun Oct 14 19:28:02 2001 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <20011014131040.B8616@akamai.com>; from dshaw@jabberwocky.com on Sun, Oct 14, 2001 at 01:10:40PM -0400 References: <01101218054502.01491@mexicali.sito.saic.com> <20011014131040.B8616@akamai.com> Message-ID: <20011014132552.C8616@akamai.com> --bCsyhTFzCvuiizWE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 14, 2001 at 01:10:40PM -0400, David Shaw wrote: > At the moment, GnuPG (and PGP too) mark all signatures[1] as "I'm not > going to say". I think I feel a patch coming on.. Patch: http://www.jabberwocky.com/crypto/gnupg/patch.gnupg-1.0.6.dms.sigclass.1 Before you sign, GnuPG will prompt you for which level of certification you want to use. Answer "?" for an explanation of the different levels. This also changes key listings (in --edit-key and --list-sigs) to show which certification level was used in making the signature. No claim made as to how well it was checked: sig 3CB3B415 2001-10-14 David M. Shaw Key was not checked at all: sig 1 3CB3B415 2001-10-14 David M. Shaw Key was checked casually: sig 2 3CB3B415 2001-10-14 David M. Shaw Key was checked extensively: sig 3 3CB3B415 2001-10-14 David M. Shaw Comments welcome. David --=20 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 --bCsyhTFzCvuiizWE 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 iQEVAwUBO8nKoIccwqs8s7QVAQGcYgf/RL8fuO32MEUzi1sgVpOeayp915CCYOBo 7IrjMIerNXzNSmrDhoBTvEUxCMBSILxlbrdgY+aWDBwRhO5BS3W2wkhz/Ioovubo LV8O52aK3jlDjhZX2Q/RGPcLD9mCrgsgbBbFBcrF435Iz+WtoPCtcTJiThLLyja6 XlfTqdMO4ClqDQEoOMJX82Ihneb2j8bgdCRfMiRR5LX8DPQkn9rZUMf8vCufKaPB 8eRJPuBxV1aHXiva0TGzBXUxbPe/IG15gqmKFZiLsiV0Oarh/bvzs6ouTDZxJYIr dax0FCp+QjC+qC6Fox+nyiq+Lhoxb7wvSXyFm3YU0IKe++9Knb+C+g== =9F+1 -----END PGP SIGNATURE----- --bCsyhTFzCvuiizWE-- From broonie@sirena.org.uk Mon Oct 15 01:14:01 2001 From: broonie@sirena.org.uk (Mark Brown) Date: Mon Oct 15 00:14:01 2001 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <20011014132552.C8616@akamai.com> References: <01101218054502.01491@mexicali.sito.saic.com> <20011014131040.B8616@akamai.com> <20011014132552.C8616@akamai.com> Message-ID: <20011014231203.B1666@tardis.ed.ac.uk> On Sun, Oct 14, 2001 at 01:25:52PM -0400, David Shaw wrote: > sig 1 3CB3B415 2001-10-14 David M. Shaw > sig 2 3CB3B415 2001-10-14 David M. Shaw > sig 3 3CB3B415 2001-10-14 David M. Shaw It would be nice if these could be presented more clearly. I can't actually suggest a clearer way off-hand, mind you. Also, it would be nice if there were no space between the "sig" and the digit as in current output. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." From dshaw@jabberwocky.com Mon Oct 15 02:04:01 2001 From: dshaw@jabberwocky.com (David Shaw) Date: Mon Oct 15 01:04:01 2001 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <20011014231203.B1666@tardis.ed.ac.uk>; from broonie@sirena.org.uk on Sun, Oct 14, 2001 at 11:12:04PM +0100 References: <01101218054502.01491@mexicali.sito.saic.com> <20011014131040.B8616@akamai.com> <20011014132552.C8616@akamai.com> <20011014231203.B1666@tardis.ed.ac.uk> Message-ID: <20011014190116.F8616@akamai.com> --ylS2wUBXLOxYXZFQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 14, 2001 at 11:12:04PM +0100, Mark Brown wrote: > On Sun, Oct 14, 2001 at 01:25:52PM -0400, David Shaw wrote: >=20 > > sig 1 3CB3B415 2001-10-14 David M. Shaw > > sig 2 3CB3B415 2001-10-14 David M. Shaw > > sig 3 3CB3B415 2001-10-14 David M. Shaw >=20 > It would be nice if these could be presented more clearly. I can't > actually suggest a clearer way off-hand, mind you. Heh. I had the same thought. I thought about using letters, but it was even worse. At least numbers have the advantage of making a "3" clearly higher than a "2". > Also, it would be > nice if there were no space between the "sig" and the digit as in > current output. Try a --check-sigs. That space is taken for the sig status character. David --=20 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 --ylS2wUBXLOxYXZFQ 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 iQEVAwUBO8oZPIccwqs8s7QVAQF7VQf6A9OtLvAa0biDYsvsE+AEzKRid3epOOue P+4RbAkxHEAByrTY1c2j3zwMDQ2YrAchBaNGYhMQx5EHZf9vy+2A9IR1nCbmtrUP ezC5DiMZwzTGhg//dyoJRz8MPZvvARhPMHG1139V7ru4c0m0RoPft7qLYSXd0w90 yXZA6+jj8vCCZ+ags0nf2ucdIw+/uqasBGiY+8Jwrnt5H1QrglWFZmV4rKzUPoHu xl7xzTCOnY33e2nMWdZbKMoyh+D07eys/K24cT25pxGOql96WVwifL42pEocrKNx 4296EtUhxaV0uKMIHJYe9rGGES0Hs19EN1tEFbZ6bI2M+FwRp6YthQ== =2Y6T -----END PGP SIGNATURE----- --ylS2wUBXLOxYXZFQ-- From broonie@sirena.org.uk Mon Oct 15 02:26:01 2001 From: broonie@sirena.org.uk (Mark Brown) Date: Mon Oct 15 01:26:01 2001 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <20011014190116.F8616@akamai.com> References: <01101218054502.01491@mexicali.sito.saic.com> <20011014131040.B8616@akamai.com> <20011014132552.C8616@akamai.com> <20011014231203.B1666@tardis.ed.ac.uk> <20011014190116.F8616@akamai.com> Message-ID: <20011015002427.E1666@tardis.ed.ac.uk> --EY/WZ/HvNxOox07X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 14, 2001 at 07:01:16PM -0400, David Shaw wrote: > > Also, it would be > > nice if there were no space between the "sig" and the digit as in > > current output. > Try a --check-sigs. That space is taken for the sig status character. That's what I was thinking of :-) . At present there's no space before any extra data on the type of entity being listed. With your patch this would change. Not that one ought to be attempting machine parsing of the output of anything not --with-colons, but anyway. --=20 "You grabbed my hand and we fell into it, like a daydream - or a fever." --EY/WZ/HvNxOox07X 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 iD8DBQE7yh6qJ2Vo11xhU60RAnblAJ47gylietHVnZJvJvRWrqEkxWM/0ACfer1b 4fesK9hetflxR/+4vt72qEg= =1nxN -----END PGP SIGNATURE----- --EY/WZ/HvNxOox07X-- From dshaw@jabberwocky.com Mon Oct 15 05:48:01 2001 From: dshaw@jabberwocky.com (David Shaw) Date: Mon Oct 15 04:48:01 2001 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <20011015002427.E1666@tardis.ed.ac.uk>; from broonie@sirena.org.uk on Mon, Oct 15, 2001 at 12:24:27AM +0100 References: <01101218054502.01491@mexicali.sito.saic.com> <20011014131040.B8616@akamai.com> <20011014132552.C8616@akamai.com> <20011014231203.B1666@tardis.ed.ac.uk> <20011014190116.F8616@akamai.com> <20011015002427.E1666@tardis.ed.ac.uk> Message-ID: <20011014224503.B21134@akamai.com> --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 15, 2001 at 12:24:27AM +0100, Mark Brown wrote: > On Sun, Oct 14, 2001 at 07:01:16PM -0400, David Shaw wrote: >=20 > > > Also, it would be > > > nice if there were no space between the "sig" and the digit as in > > > current output. >=20 > > Try a --check-sigs. That space is taken for the sig status character. >=20 > That's what I was thinking of :-) . At present there's no space before > any extra data on the type of entity being listed. With your patch this > would change. Not that one ought to be attempting machine parsing of > the output of anything not --with-colons, but anyway. Ah, I understand now. Hmm. It's easy enough to move it over by one if there is no sig status, but don't you think that would make it harder to read rather than easier? The eye wouldn't be able to just look in the same place each time. I'm also toying with a patch to show various informative flags in that area (an "L" for a local signature, a "P" for a policy URL, "N" for a notation, etc). David --=20 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 --2oS5YaxWCcQjTEyO 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 iQEVAwUBO8pNr4ccwqs8s7QVAQHwuwgAiS1fuvi71XuSZclvvkL/tKbZtZyGpW0t yAvzNk4+AmXdeXKqFmz/sIsZe49bix2g7w/WXvKyRWflGobJd1Qk+z3CMP1yBRJy hAS41PTFuRYmixB8tjpWVdT0e75qP9x2bLBFgpsJH1uXlBzk54FkBEF8w6u/krHv s2OwOIJpmHpyPcz+08bjEzU0yd7J5OKo1PSAfehN7QxTZBle0xh4kEWIG8hR37ms mzFqyF93INdJjWXTfwdfLD65L+z+h3a/2ZNv3Ha0MHVVbJWVIUi0j9aXTr8gqPkz mjZKMUD4FyYCu5HfmTIleI9vAbBuvoF7+BojBGr1y9qRQz8nldogww== =DbG4 -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO-- From dshaw@jabberwocky.com Tue Oct 16 00:38:02 2001 From: dshaw@jabberwocky.com (David Shaw) Date: Mon Oct 15 23:38:02 2001 Subject: Sig classification, version 2 Message-ID: <20011015173637.B4515@akamai.com> Here's version 2 of the sig classification patch I sent in yesterday (thanks for the comments, everyone). It contains everything that was in version 1, with some better help text, and it also shows a few other pieces of information about the signature: 1-3 == amount of verification in the signature (just like before) L == local signature (e.g. made by "--lsign-key"). R == signature is non-revocable. P == a policy URL is attached to this signature. N == a notation is attached to this signature. You can use the --show-policy-url and --show-notation options to display the policy or notation (in a --list-sigs or --edit/check). There is also a --no-show-policy-url and --no-show-notation for the folks who like to override their config file on occasion. --fast-list-mode disables everything except the 1-3 levels of verification (which don't cost anything to retrieve). http://www.jabberwocky.com/crypto/gnupg/patch.gnupg-1.0.6.dms.sigclass.2 Comments welcome. 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 redbird@rbisland.cx Tue Oct 16 06:03:01 2001 From: redbird@rbisland.cx (Gordon Worley) Date: Tue Oct 16 05:03:01 2001 Subject: GPGME.framework Beta 0.2.3 Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Okay, now this message is supposed to show up on this list. ;-) At the Mac GPG project we've released GPGME.framework Beta 0.2.3. This should work on any OpenStepish environment, like GNUStep and Mac OS X. This beta is not a final release and is still missing a few features (use the source, I'll compile release notes when I have time), but there's enough there to get some stuff done. Feel free to beat it around and find any bugs. You can get Beta 0.2.3 here: http://sourceforge.net/project/showfiles.php?group_id=20789&release_id=57202 or just grab the latest out of the Mac GPG CVS tree. For more info on that and the project in general, visit: http://macgpg.sourceforge.net/ - -- 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 -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use Comment: keyserver http://pgpkeys.mit.edu:11371 iQA/AwUBO8ui3m7zd/e707ADEQL6ZQCgymipUUkThn1e+NFvJm+2bEc1Yh4AnRt4 J19AWLt+ZoLqJFAT6uYTGir6 =uniR -----END PGP SIGNATURE----- From mwy-gpg41@the-youngs.org Tue Oct 16 18:09:02 2001 From: mwy-gpg41@the-youngs.org (Michael Young) Date: Tue Oct 16 17:09:02 2001 Subject: Re; Sig classification (was Re: discussion on increasing amount of gpg signatures...) References: Message-ID: <003301c15654$23c8fa60$dfc32609@transarc.ibm.com> -----BEGIN PGP SIGNED MESSAGE----- > Before you sign, GnuPG will prompt you for which level of > certification you want to use. Answer "?" for an explanation of the > different levels. Excellent! A couple of months ago, I built a command-line switch to do this, but didn't get around to posting it. (When I looked back through the mailing list archives, it appeared that signature types were an unpopular idea at some past OpenPGP meetings.) How would you feel about adding a command-line option? As it stands, batch operations get a "generic" signature. I used "--sig-type" in my patch. I could recreate it against yours if you're interested. To make good use of these additional validity levels, the trust model really should understand them. For example, I might fully trust type-3 signatures from "John Smith", partially trust his type-2 signatures, and not trust any type-1. But that's for another day... I'm glad to see the first step. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQEVAwUBO8xM32NDnIII+QUHAQH52gf9Gmd7v524TaY+qJo9UhX8aG4naq69dn/b M+79JQj68xLpeWOVDtKFqSWVSOWcVBA2tiW6+JvZaJ9a5AAmfsk4yie3lQpS2Srp 9wmye2hm/y9CNfHD58PLiUYUlzWDhAj2V3+OZntkC7w9FWMRX3hz+9YCQ5XqpApj 59V5OjWV9XNgB4TkCvCEfGiY8dhJ9BMFBnQzYKvQoffsxVZdgoDK3x9Em+8OFLIw IeiIea6b3+AizaYQxUhAywxE6fdw0gX+gHP7I9Gxb0mZwLD//PY+jVGAW6QVvLAi l2lonJ6e1V5KuZpgNKzT1XK95w8/jzNZhstaEjOd+To4rnRYsYirRw== =i6n2 -----END PGP SIGNATURE----- From gnupg@lists.colondot.net Tue Oct 16 18:51:01 2001 From: gnupg@lists.colondot.net (Matthew Byng-Maddick) Date: Tue Oct 16 17:51:01 2001 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <003301c15654$23c8fa60$dfc32609@transarc.ibm.com>; from mwy-gpg41@the-youngs.org on Tue, Oct 16, 2001 at 11:06:30AM -0400 References: <003301c15654$23c8fa60$dfc32609@transarc.ibm.com> Message-ID: <20011016164931.A98387@colon.colondot.net> On Tue, Oct 16, 2001 at 11:06:30AM -0400, Michael Young wrote: > To make good use of these additional validity levels, the trust > model really should understand them. For example, I might > fully trust type-3 signatures from "John Smith", partially > trust his type-2 signatures, and not trust any type-1. > But that's for another day... I'm glad to see the first step. If you do this, you have to trust that he will choose the correct type of signature to sign with. MBM -- Matthew Byng-Maddick http://colondot.net/ From broonie@sirena.org.uk Tue Oct 16 19:37:02 2001 From: broonie@sirena.org.uk (Mark Brown) Date: Tue Oct 16 18:37:02 2001 Subject: Re; Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <003301c15654$23c8fa60$dfc32609@transarc.ibm.com> References: <003301c15654$23c8fa60$dfc32609@transarc.ibm.com> Message-ID: <20011016173439.G10896@tardis.ed.ac.uk> On Tue, Oct 16, 2001 at 11:06:30AM -0400, Michael Young wrote: > To make good use of these additional validity levels, the trust > model really should understand them. For example, I might > fully trust type-3 signatures from "John Smith", partially > trust his type-2 signatures, and not trust any type-1. > But that's for another day... I'm glad to see the first step. There are also trusted introducer signatures (which are implemented by NAI PGP). -- "You grabbed my hand and we fell into it, like a daydream - or a fever." From dshaw@jabberwocky.com Wed Oct 17 00:15:01 2001 From: dshaw@jabberwocky.com (David Shaw) Date: Tue Oct 16 23:15:01 2001 Subject: Re; Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <003301c15654$23c8fa60$dfc32609@transarc.ibm.com>; from mwy-gpg41@the-youngs.org on Tue, Oct 16, 2001 at 11:06:30AM -0400 References: <003301c15654$23c8fa60$dfc32609@transarc.ibm.com> Message-ID: <20011016171254.I667@akamai.com> --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 16, 2001 at 11:06:30AM -0400, Michael Young wrote: > > Before you sign, GnuPG will prompt you for which level of > > certification you want to use. Answer "?" for an explanation of the > > different levels. >=20 > Excellent! A couple of months ago, I built a command-line switch > to do this, but didn't get around to posting it. (When I looked > back through the mailing list archives, it appeared that signature > types were an unpopular idea at some past OpenPGP meetings.) >=20 > How would you feel about adding a command-line option? As it > stands, batch operations get a "generic" signature. I used > "--sig-type" in my patch. I could recreate it against yours > if you're interested. Good idea. I've added it to v3 of the patch. The command is --default-sig-class, and it takes a number from 0-3. If you set a default sig class in your options file, you can use --no-default-sig-class to override it back to 0. The menu that pops up when key signing will reflect the new default. Also added: * 'If you don't know what the right answer is, answer "0"' message * minor fix to notations - they should be printed as UTF8. http://www.jabberwocky.com/crypto/gnupg/patch.gnupg-1.0.6.dms.sigclass.3 David --=20 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 --ibTvN161/egqYuK8 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 iQEVAwUBO8yi1occwqs8s7QVAQE8XQf+JNjMSZiKbYP4YGVONoOAJLALIoym8AwN 9khnCVE//UOItw8uczxmQLE/FH/qvE3oXASyNPc9THTK0hCAkkAp3OkJ8tWprc6w TNNkLNP2GJyWNHwrTuHnbaN6KmCQ3KkQ3pLMHzTqml0qYn7LPeewAVc+qny14Q7a iiViBUr152SGiIeVTgCLOM82FVE92aPVoHPQGcqqgDBzwB+whMITsFlIWXyj5Yz1 TNiU1TQuFQvnnvPq+B4nSLia+oScqcnVxxI0h+YLLh4s1e3Fvs13ZazW+tNci9so or0YNuNRrkAJvrhrlr9+kSWL01flYh1vpvkd2SEUfym+7Tl1Zzgekw== =fxIw -----END PGP SIGNATURE----- --ibTvN161/egqYuK8-- From dshaw@jabberwocky.com Wed Oct 17 02:04:01 2001 From: dshaw@jabberwocky.com (David Shaw) Date: Wed Oct 17 01:04:01 2001 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <20011016164931.A98387@colon.colondot.net>; from gnupg@lists.colondot.net on Tue, Oct 16, 2001 at 04:49:31PM +0100 References: <003301c15654$23c8fa60$dfc32609@transarc.ibm.com> <20011016164931.A98387@colon.colondot.net> Message-ID: <20011016190152.K667@akamai.com> --w7PDEPdKQumQfZlR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 16, 2001 at 04:49:31PM +0100, Matthew Byng-Maddick wrote: > On Tue, Oct 16, 2001 at 11:06:30AM -0400, Michael Young wrote: > > To make good use of these additional validity levels, the trust > > model really should understand them. For example, I might > > fully trust type-3 signatures from "John Smith", partially > > trust his type-2 signatures, and not trust any type-1. > > But that's for another day... I'm glad to see the first step. >=20 > If you do this, you have to trust that he will choose the correct type of > signature to sign with. Yes, and also that he can choose his signature type in the first place. All versions of PGP create the generic "I'm not going to say how much checking I did" form of the signature. Incidentally, I did confirm that PGP (at least version 6.5.8 and later) does understand all 4 signature types, even though it can't generate them. David --=20 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 --w7PDEPdKQumQfZlR 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 iQEVAwUBO8y8YIccwqs8s7QVAQFljwgAgsxVckn5PpFTRrmTRiUpvxUWc5IHwqK2 pdV56GepfHGcy8v8J5Evp9VjAfXB5576WNuoNpAiMwg5RSoR+zlXp4IgJowo15rS g+dA83VUGpeJWLuxRyX1GlR32eWS3amVlnka21fJ66kOuzHxOpEn0nu7kZbxwGAt +4nnCRL/cmzBGDnL/ToPbfvzHsuhG2blUIPClirT7ffLysbDWd9pwgVQ2QIbhQg+ 2MyvCnFeyDANloGFPigtR+5fWskidWJbvTmvrwLStwwlNfhiUidfTbCQ3fFIlsGY gC2bY9/wLEeJIx4qBxtfNKW0K5aRuKOaIwsuAP4+pHdflip2deQT1g== =EKJ1 -----END PGP SIGNATURE----- --w7PDEPdKQumQfZlR-- From wk@gnupg.org Thu Oct 18 15:00:02 2001 From: wk@gnupg.org (Werner Koch) Date: Thu Oct 18 14:00:02 2001 Subject: Should I release a new snapshot? Message-ID: <87adypupjb.fsf@alberti.gnupg.de> Hi! Those of you who are using the CVS version have noticed a couple of major changes in GnuPG. There is still a long list of minor bugs but nevertheless I'd like to make a new snapshot available, so that the new code can be tested. Are there any grave bugs in the CVS versions? Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From ts@winpt.org Thu Oct 18 17:00:01 2001 From: ts@winpt.org (Timo Schulz) Date: Thu Oct 18 16:00:01 2001 Subject: Should I release a new snapshot? In-Reply-To: <87adypupjb.fsf@alberti.gnupg.de> References: <87adypupjb.fsf@alberti.gnupg.de> Message-ID: <20011018155031.E412@daredevil.joesixpack.net> On Thu Oct 18 2001; 13:59, Werner Koch wrote: > Are there any grave bugs in the CVS versions? I'm not sure if this is only my problem. But with the new --refresh-key command it happens from time to time that one key exists twice in the keyring. Timo -- "Das wahre Vaterland ist das Land, wo man die meisten Menschen trifft, die einem gleichen." -- Henri Stendhal From wk@gnupg.org Thu Oct 18 20:30:02 2001 From: wk@gnupg.org (Werner Koch) Date: Thu Oct 18 19:30:02 2001 Subject: Should I release a new snapshot? In-Reply-To: <20011018155031.E412@daredevil.joesixpack.net> (Timo Schulz's message of "Thu, 18 Oct 2001 15:50:31 +0200") References: <87adypupjb.fsf@alberti.gnupg.de> <20011018155031.E412@daredevil.joesixpack.net> Message-ID: <87u1wwsvqp.fsf@alberti.gnupg.de> On Thu, 18 Oct 2001 15:50:31 +0200, Timo Schulz said: > I'm not sure if this is only my problem. But with the > new --refresh-key command it happens from time to time > that one key exists twice in the keyring. Yeah, if a snapshot helps to track this bug down, I should do it. There are also a few other problems mainly for Windows and RISC OS but those are not the primary target. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From jpg@rcom.com.ar Fri Oct 19 21:20:01 2001 From: jpg@rcom.com.ar (Juan Pablo =?ISO-8859-1?Q?Gim=E9nez?=) Date: Fri Oct 19 20:20:01 2001 Subject: with-colons bug Message-ID: <1003515471.19982.26.camel@kang.oficina.rcom.com.ar> --=-bKhvA6y9GzcgLNBsvy1d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi! I already send this mail with other subject, but nobody answer because it = was too simple... I have a problem with the option "--with-colons" and --list-keys or --fingerprint, if i don't use it, gpg print my last name "Gim=E9nez" with the "=E9", but if I put with-colons insted of "=E9" gpg prints "=C3=A9"... = So here is the patch to fix it... ________________________________________________________________________ --- gnupg-1.0.6/g10/keylist.c Sun May 27 11:31:07 2001 +++ gnupg-1.0.6_rcom/g10/keylist.c Fri Oct 12 11:42:15 2001 @@ -482,8 +482,8 @@ printf("uid:%c::::::::", trustletter); } } - print_string( stdout, node->pkt->pkt.user_id->name, - node->pkt->pkt.user_id->len, ':' ); + print_utf8_string( stdout, node->pkt->pkt.user_id->name, + node->pkt->pkt.user_id->len); putchar(':'); if (any) putchar('\n'); ________________________________________________________________________ Chausesssssssssss Juan Pablo.... --=-bKhvA6y9GzcgLNBsvy1d Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA70G5PChXsK9PY/SsRAt+EAJ9/2GlaUB9PLLyxLdskRhlgdKohzACeIM3L QGqTot3XLmgbtuUowz3Hi+M= =A8v6 -----END PGP SIGNATURE----- --=-bKhvA6y9GzcgLNBsvy1d-- From fw@deneb.enyo.de Sat Oct 20 00:38:01 2001 From: fw@deneb.enyo.de (Florian Weimer) Date: Fri Oct 19 23:38:01 2001 Subject: with-colons bug In-Reply-To: <1003515471.19982.26.camel@kang.oficina.rcom.com.ar> (Juan Pablo =?iso-8859-1?q?Gim=E9nez's?= message of "19 Oct 2001 15:17:51 -0300") References: <1003515471.19982.26.camel@kang.oficina.rcom.com.ar> Message-ID: <87d73j5oli.fsf@deneb.enyo.de> Juan Pablo Gim=E9nez writes: > I have a problem with the option "--with-colons" and --list-keys or > --fingerprint, if i don't use it, gpg print my last name "Gim=E9nez" with > the "=E9", but if I put with-colons insted of "=E9" gpg prints "=C3=A9"..= . So > here is the patch to fix it... I think this behavior is mostly correct. In "--with-colons" mode, GnuPG is expected to dump the user ID as is, without further processing. From jpg@rcom.com.ar Sat Oct 20 01:33:01 2001 From: jpg@rcom.com.ar (Juan Pablo =?ISO-8859-1?Q?Gim=E9nez?=) Date: Sat Oct 20 00:33:01 2001 Subject: with-colons bug In-Reply-To: <87d73j5oli.fsf@deneb.enyo.de> References: <1003515471.19982.26.camel@kang.oficina.rcom.com.ar> <87d73j5oli.fsf@deneb.enyo.de> Message-ID: <1003530662.4450.21.camel@kang.oficina.rcom.com.ar> --=-hWbCwDyvomJTh1VF5wK1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable En vie, 2001-10-19 a 18:03, Florian Weimer escribi=F3: Juan Pablo Gim=E9nez writes: =20 > I have a problem with the option "--with-colons" and --list-keys or > --fingerprint, if i don't use it, gpg print my last name "Gim=E9nez" = with > the "=E9", but if I put with-colons insted of "=E9" gpg prints "=C3= =A9"... So > here is the patch to fix it... =20 I think this behavior is mostly correct. In "--with-colons" mode, GnuPG is expected to dump the user ID as is, without further processing. Ok, but thats break some programs, for example Gabber (Gnome Jabber client), who print the strings as is so it print it wrong... So, what do you think, the problem is gnupg or for example Gabber?!?! =20 --=-hWbCwDyvomJTh1VF5wK1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA70KmmChXsK9PY/SsRAlmrAKCNCj2pMM4cTrjmS83Co3vINSwpzQCfQqX0 G42CD1zWZlng0+Hcoz87MdY= =IWZ3 -----END PGP SIGNATURE----- --=-hWbCwDyvomJTh1VF5wK1-- From wk@gnupg.org Sat Oct 20 13:56:01 2001 From: wk@gnupg.org (Werner Koch) Date: Sat Oct 20 12:56:01 2001 Subject: with-colons bug In-Reply-To: <1003530662.4450.21.camel@kang.oficina.rcom.com.ar> (Juan Pablo =?iso-8859-1?q?Gim=E9nez's?= message of "19 Oct 2001 19:31:02 -0300") References: <1003515471.19982.26.camel@kang.oficina.rcom.com.ar> <87d73j5oli.fsf@deneb.enyo.de> <1003530662.4450.21.camel@kang.oficina.rcom.com.ar> Message-ID: <873d4eoa2v.fsf@alberti.gnupg.de> On 19 Oct 2001 19:31:02 -0300, Juan Pablo Giménez said: > Ok, but thats break some programs, for example Gabber (Gnome Jabber > client), who print the strings as is so it print it wrong... So, what do > you think, the problem is gnupg or for example Gabber?!?! Gabber does not do a conversion from utf-8 to the used character set. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From mwy-gpg41@the-youngs.org Mon Oct 22 18:39:01 2001 From: mwy-gpg41@the-youngs.org (Michael Young) Date: Mon Oct 22 17:39:01 2001 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) References: Message-ID: <009501c15b0f$4977a760$b399183f@transarc.ibm.com> -----BEGIN PGP SIGNED MESSAGE----- > From: David Shaw > Incidentally, I did confirm that PGP (at least version 6.5.8 and > later) does understand all 4 signature types, even though it can't > generate them. I also did some confirmation. PGP2.6 should accept them. The keyservers I tested had no problem with them. Note that GnuPG had already been using class 3 for self-signatures. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQEVAwUBO9Q8omNDnIII+QUHAQHBkAgAif8tXnmcxiMMVBE4dwSDcweQxayqD1DK u9pEvD75W6dxbgdl9rlB2dd70sXVI9VhTZWo6mo/heR0Kda6gwxvRLzN0sUiP7u+ 6g9tx8wGx5POAxxJVBclL7O/kTZffjztdIm3iZKLLXh3VJ1UEVdTfIe30A/F69+X fMLAItAOe7qcPvteL40wBXZcPvK2ioE4Qtt8hc2Db7iDZLn0f+eFO6Myv2sdfHc4 KAqxb7StOpjyPJ1LELsRQ9czAU0r+O7eu05OUk1AZFyJCgzTxPBTloBVnoDs2Rmp dL9XXsHNYZM3ROTwJWfjuaflmM+4in2qe1ABh+7088EczdDS9wxqbQ== =AyYk -----END PGP SIGNATURE----- From dshaw@jabberwocky.com Mon Oct 22 22:23:01 2001 From: dshaw@jabberwocky.com (David Shaw) Date: Mon Oct 22 21:23:01 2001 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <009501c15b0f$4977a760$b399183f@transarc.ibm.com>; from mwy-gpg41@the-youngs.org on Mon, Oct 22, 2001 at 11:35:52AM -0400 References: <009501c15b0f$4977a760$b399183f@transarc.ibm.com> Message-ID: <20011022152058.A666@akamai.com> --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 22, 2001 at 11:35:52AM -0400, Michael Young wrote: > > From: David Shaw > > Incidentally, I did confirm that PGP (at least version 6.5.8 and > > later) does understand all 4 signature types, even though it can't > > generate them. >=20 > I also did some confirmation. PGP2.6 should accept them. > The keyservers I tested had no problem with them. Excellent. Thanks for checking. > Note that GnuPG had already been using class 3 for self-signatures. Yes, I noticed that. That in itself gives me more confidence there won't be problems with multiple sig classes. If there was a PGP version out there that didn't accept multiple sig classes, it would have broken with GnuPG-generated keys and we'd have heard about it by now. David --=20 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 --Kj7319i9nmIyA2yE 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 iQEVAwUBO9Rxmoccwqs8s7QVAQGJlAgAmdhTFgRXIGRh4yjeNBpFIXGT/F5t45ug Q0EfYEOKc6j+2ccCY2B0mdwuQjgr3ZPAJXl/pH0lFsC2s5TXNnkuStFT01VpMu98 JYiK20fTLuGPSBN2+e7VGSWCk0GtAiMXMb/QhqbYb5h37RP6CnDLeDHTgCpjH8br VVSXK7eroaHRJunccJ4G1WSMQ0zYBTnCrxuY/uk3pies4xs+w/eD1r5czLeMtty1 YPnZgJR+B1hgrecI75Z9IBWCBO38TrgzbGsnKy5vSUdHCmvNzhf/Dm845+E4TvE6 GbRSIq4p0D8QYlUWlQM87LjoQtiw9i2MMSS7vBuK5zhlIWG5V6x88w== =pK1e -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE-- From wk@gnupg.org Tue Oct 23 10:46:01 2001 From: wk@gnupg.org (Werner Koch) Date: Tue Oct 23 09:46:01 2001 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <20011022152058.A666@akamai.com> (David Shaw's message of "Mon, 22 Oct 2001 15:20:58 -0400") References: <009501c15b0f$4977a760$b399183f@transarc.ibm.com> <20011022152058.A666@akamai.com> Message-ID: <87y9m2vlzu.fsf@alberti.gnupg.de> On Mon, 22 Oct 2001 15:20:58 -0400, David Shaw said: > Yes, I noticed that. That in itself gives me more confidence there > won't be problems with multiple sig classes. If there was a PGP I use 0x13 for self-signatures and 0x10 for standard signatures, mainly because this may be helpful in debugging. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From wk@gnupg.org Tue Oct 23 22:28:07 2001 From: wk@gnupg.org (Werner Koch) Date: Tue Oct 23 21:28:07 2001 Subject: [Announce] A new GnuPG snapshot (unstable) Message-ID: <877ktmtgkl.fsf@alberti.gnupg.de> Hi, after messing around with autoconf 1.5 for quite some time, I finally was able to release a new DEVELOPMENT snapshot of GnuPG: *PLEASE READ THIS ENTIRE ANNOUNCEMENT BEFORE YOU START TO PLAY* ftp://ftp.gnupg.org/gcrypt/devel/gnupg-1.0.6b.tar.gz (1.9M) ftp://ftp.gnupg.org/gcrypt/devel/gnupg-1.0.6b.tar.gz.sig Please find a list of mirrors at http://www.gnupg.org/mirrors.html Again I changed quite a lot of things. Using this version with a current keyring renders the keyring unreadable for any previous GnuPG versions. So I did WARN YOU ABOUT THESE INCOMPATIBLE CHANGES - please don't complain that it destroyed all your keys. Actually this incompatibility is due to a bug in the older versions which are not able to cope with trust packet larger than one byte. You can use --export as an escape hatch because trust packets are never exported. There are 2 major changes in this release: * The caching of the signature verification status changed from using special signature subpackets to the use of the trust packets. You can (and should) rebuild this key cache using the new command "gpg --rebuild-keydb-caches" * The format of the TrustDB and the way it works has entirely be rewritten. gpg tries to migrate to the new format but this code is obviously not very well tested, so you might want to make a backup of our ownertrust values first. The validity of the key is now checked every time you insert a new key or signature and when a key or a signature expires. This automatic check can be disabled and replaced by a cron job which does an "gpg --check-trustdb" every night or so. To assign an ownertrust, you can either do this in the edit menu or use the command "gpg --update-trustdb" which does the maintenance pass in a similar manner you probably know from PGP 2. Both changes should speed up the operation on large keyrings quite a lot so that "gpg --list-keys --with-colons" is actually usable. Also a couple of bug fixes and some other code cleanups are in this release. There is still a long list of open bugs but I think it is important to get the new code tested first. The Windows and Acorn ports won't work yet due to file sharing issues. Changes since 1.0.6a: * The way signature stati are store has changed, so that v3 signatures can be supported. To increase the speed of many operations for existing keys you can use the new --rebuild-keydb-caches command. * The entire key validation process (trustdb) has been revamped. See the man page entries for --update-trustdb, --check-trustdb and --no-auto-check-trustdb. * --trusted-keys is again obsolete, --edit can be used to set the ownertrust of any key to ultimately trusted. * A subkey is never used to sign keys. * Read only keyrings are now handled as expected. Changes since 1.0.6: * New tool gpgsplit to split OpenPGP data formats into packets. * New option --preserve-permissions. * Subkeys created in the future are not used for encryption or signing unless the new option --ignore-valid-from is used. * Revoked user-IDs are not listed unless signatures are listed too or we are in verbose mode. * There is no default comment string with ascii armors anymore except for revocation certificates and --enarmor mode. * The command "primary" in the edit menu can be used to change the primary UID, "setpref" and "updpref" can be used to change the preferences. * Fixed the preference handling; since 1.0.5 they were erroneously matched against against the latest user ID and not the given one. * RSA key generation. * Merged Stefan's patches for RISC OS in. See comments in scripts/build-riscos. * It is now possible to sign and conventional encrypt a message (-cs). * The MDC feature flag is supported and can be set by using the "updpref" edit command. * The status messages GOODSIG and BADSIG are now returning the primary UID, encoded using %XX escaping (but with spaces left as spaces, so that it should not break too much) * Support for GDBM based keyrings has been removed. * The entire keyring management has been revamped. * The way signature stati are store has changed, so that v3 signatures can be supported. To increase the speed of many operations for existing keys you can use the new --rebuild-keydb-caches command. * The entire key validation process (trustdb) has been revamped. See the man page entries for --update-trustdb, --check-trustdb and --no-auto-check-trustdb. * --trusted-keys is again obsolete, --edit can be used to set the ownertrust of any key to ultimately trusted. * A subkey is never used to sign keys. Take care, Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From dshaw@jabberwocky.com Wed Oct 24 23:12:01 2001 From: dshaw@jabberwocky.com (David Shaw) Date: Wed Oct 24 22:12:01 2001 Subject: 1.0.6b comments Message-ID: <20011024161016.A2155@akamai.com> --1sNVjLsmu1MXqwQ/ Content-Type: multipart/mixed; boundary="2JFBq9zoW8cOFH7v" Content-Disposition: inline --2JFBq9zoW8cOFH7v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hiya, I've been playing with 1.0.6b, and have a few comments. Some of these are not necessarily bugs, and some of them exist in 1.0.6 as well. Aside from this, 1.0.6b is really great. I love --update-trustdb. 1) Merely having the secret key present is not enough to make a key ultimately trusted. You have to do it by hand in --edit. If a new key is generated, however, it is ultimately trusted. 2) The --edit menu does not detect if you have v3 secret keys (i.e. you can't "toggle"). V4 secret keys do work. 3) If you try to make a 4096-bit RSA key, gpg seems to make a 4095-bit key. 4) Sign a key, so that it's trust goes to "full". Now, delete or revoke the signature. The trust level stays at "full" until you export, delete, and then re-import the trustdb. 5) When you delete a key with ownertrust set it does not disappear from the trustdb. 6) You can revoke the same key signature multiple times (unclear whether this is really a problem or not). 7) When revoking a key signature, the reason for revocation prompt doesn't allow for the "no reason specified" option allowed in the RFC. A patch for that is attached. 8) RSA key signatures are always made with MD5 as the hash. This makes sense for v3 key sigs, but v4 RSA key sigs are probably safe to use something else. 9) Revoking a key or signature prompts for a revocation reason. This doesn't work properly with v3 keys in that it prompts, accepts the user's input, but does not actually include the reason in the revocation signature. This is the same problem that 1.0.6 had with making non-exportable sigs with v3 keys (i.e. v3 keys make v3 sigs, so no v4 features). Note the same thing happens with set-policy-url or notation-data with v3 keys. As I see it, if you are making a signature on a v4 key using your v3 key, it doesn't make sense to generate a v3 sig. After all, the point of using a v3 sig is to be backwards compatible, but no v3-only PGP implementation could understand the v4 key the sig is on in the first place. I've added a feature (patch attached) to always make v4 key sigs unless it is a v3 key making a key sig on a v3 key, in which case it makes a v3 key sig. I also added a "force-v4-certs" flag to force v4 key sigs (certs) if the user wants v4 key signatures all the time. This only affects key certification signatures. Regular document signatures are unchanged. This doesn't really solve the stated issue that gpg prompts the user even if it is not going to use the revocation reason but it does help the underlying problem. 10) Key flags don't seem to work properly in that if a key is flagged certify-only (0x01), or signature-only (0x02), it still can do the other (certify-only keys can sign, and signature-only keys can certify). David --=20 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 --2JFBq9zoW8cOFH7v Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch.gnupg-1.0.6b.dms.revokereason.1" Content-Transfer-Encoding: quoted-printable Index: revoke.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/gnupg/gnupg/g10/revoke.c,v retrieving revision 1.20.2.9 diff -u -r1.20.2.9 revoke.c --- revoke.c 2001/09/07 07:57:51 1.20.2.9 +++ revoke.c 2001/10/24 19:13:11 @@ -240,9 +240,10 @@ struct revocation_reason_info * ask_revocation_reason( int key_rev, int cert_rev, int hint ) { - int code; + int code=3D-1; char *description =3D NULL; struct revocation_reason_info *reason; + const char *text_0 =3D _("No reason specified"); const char *text_1 =3D _("Key has been compromised"); const char *text_2 =3D _("Key is superseded"); const char *text_3 =3D _("Key is no longer used"); @@ -254,6 +255,7 @@ description =3D NULL; =20 tty_printf(_("Please select the reason for the revocation:\n")); + tty_printf( " 0 =3D %s\n", text_0 ); if( key_rev ) tty_printf(" 1 =3D %s\n", text_1 ); if( key_rev ) @@ -262,29 +264,31 @@ tty_printf(" 3 =3D %s\n", text_3 ); if( cert_rev ) tty_printf(" 4 =3D %s\n", text_4 ); - tty_printf( " 0 =3D %s\n", _("Cancel") ); + tty_printf( " Q =3D %s\n", _("Cancel") ); if( hint ) tty_printf(_("(Probably you want to select %d here)\n"), hint ); =20 - for(code =3D 0; !code;) { + while(code=3D=3D-1) { int n; char *answer =3D cpr_get("ask_revocation_reason.code", _("Your decision? ")); trim_spaces( answer ); cpr_kill_prompt(); - if( *answer =3D=3D 'q' || *answer =3D=3D 'Q' ) - n =3D 0; - else if( !isdigit( *answer ) ) - n =3D -1; - else if( hint && !*answer ) + if( *answer =3D=3D 'q' || *answer =3D=3D 'Q') + return NULL; /* cancel */ + if( hint && !*answer ) n =3D hint; + else if(!isdigit( *answer ) ) + n =3D -1; else n =3D atoi(answer); m_free(answer); - if( !n ) - return NULL; /* cancel */ + if( n =3D=3D 0 ) { + code =3D 0x00; /* no particular reason */ + code_text =3D text_0; + } else if( key_rev && n =3D=3D 1 ) { - code =3D 0x02; /* key has been compromised */ + code =3D 0x02; /* key has been compromised */ code_text =3D text_1; } else if( key_rev && n =3D=3D 2 ) { --2JFBq9zoW8cOFH7v Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch.gnupg-1.0.6b.dms.sigversion.1" Content-Transfer-Encoding: quoted-printable ? Makefile.in ? Makefile ? .deps ? gpg ? gpgv Index: g10.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/gnupg/gnupg/g10/Attic/g10.c,v retrieving revision 1.129.2.57 diff -u -r1.129.2.57 g10.c --- g10.c 2001/10/06 07:31:28 1.129.2.57 +++ g10.c 2001/10/24 19:36:04 @@ -180,6 +180,8 @@ oThrowKeyid, oForceV3Sigs, oNoForceV3Sigs, + oForceV4Certs, + oNoForceV4Certs, oForceMDC, oS2KMode, oS2KDigest, @@ -311,6 +313,8 @@ { oNoTTY, "no-tty", 0, N_("don't use the terminal at all") }, { oForceV3Sigs, "force-v3-sigs", 0, N_("force v3 signatures") }, { oNoForceV3Sigs, "no-force-v3-sigs", 0, N_("do not force v3 signature= s") }, + { oForceV4Certs, "force-v4-certs", 0, N_("force v4 key signatures") }, + { oNoForceV4Certs, "no-force-v4-certs", 0, N_("do not force v4 key sig= natures") }, { oForceMDC, "force-mdc", 0, N_("always use a MDC for encryption") }, { oDryRun, "dry-run", 0, N_("do not make any changes") }, /*{ oInteractive, "interactive", 0, N_("prompt before overwriting") }, */ @@ -956,6 +960,7 @@ case oRFC1991: opt.rfc1991 =3D 1; opt.rfc2440 =3D 0; + opt.force_v4_certs =3D 0; opt.no_comment =3D 1; opt.escape_from =3D 1; break; @@ -998,6 +1003,8 @@ case oThrowKeyid: opt.throw_keyid =3D 1; break; case oForceV3Sigs: opt.force_v3_sigs =3D 1; break; case oNoForceV3Sigs: opt.force_v3_sigs =3D 0; break; + case oForceV4Certs: opt.force_v4_certs =3D 1; break; + case oNoForceV4Certs: opt.force_v4_certs =3D 0; break; case oForceMDC: opt.force_mdc =3D 1; break; case oS2KMode: opt.s2k_mode =3D pargs.r.ret_int; break; case oS2KDigest: s2k_digest_string =3D m_strdup(pargs.r.ret_str); break; Index: options.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/gnupg/gnupg/g10/options.h,v retrieving revision 1.51.2.30 diff -u -r1.51.2.30 options.h --- options.h 2001/09/25 15:20:59 1.51.2.30 +++ options.h 2001/10/24 19:36:04 @@ -57,6 +57,7 @@ int list_packets; /* list-packets mode: 1=3Dnormal, 2=3Dinvoked by com= mand*/ int def_cipher_algo; int force_v3_sigs; + int force_v4_certs; int force_mdc; int def_digest_algo; int def_compress_algo; Index: sign.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/gnupg/gnupg/g10/sign.c,v retrieving revision 1.75.2.23 diff -u -r1.75.2.23 sign.c --- sign.c 2001/09/09 16:09:19 1.75.2.23 +++ sign.c 2001/10/24 19:36:04 @@ -982,8 +982,18 @@ || sigclass =3D=3D 0x20 || sigclass =3D=3D 0x18 || sigclass =3D=3D 0x30 || sigclass =3D=3D 0x28 ); =20 + if (opt.force_v4_certs) + sigversion =3D 4; + if (sigversion < sk->version) sigversion =3D sk->version; + + /* If you are making a signature on a v4 key using your v3 key, it + doesn't make sense to generate a v3 sig. After all, no v3-only + PGP implementation could understand the v4 key in the first + place. */ + if (sigversion < pk->version) + sigversion =3D pk->version; =20 if( !digest_algo ) { switch( sk->pubkey_algo ) { --2JFBq9zoW8cOFH7v-- --1sNVjLsmu1MXqwQ/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6b (GNU/Linux) iQEVAwUBO9cgKIccwqs8s7QVAQHJhwf8C806sdn+1ZvXbweOu92OyH4bgXMjurkn UUAHKx45eMa/oq/0Sn11wwucntr4CHQhGlc7b1IJ6/aVPp3tvtaWQ2OfAMRSCGgW i/rLAPeoQVdd1ULuI5ZPtyXKAqCSR8bB+HzpWHduobGXeCE/N7vNgMPa+VpelEnI ToPdgsR2CRCIsAEaflEiSar6C8LFWSL1QXqFD/VDPxHGlG+rOHP2lR21OO0/l1Ue 0Yk7fm+aUeIK8f22KAeE3+x6sPsDmGXDKptndZLf3mgAXWdWI4/3TNpcmIJ7WYxN Lf/TUW3dJimuBg9IhPZLL+qC6tp4RJJcYa1BKysNWmBC9N7JMpOp8A== =Vx5N -----END PGP SIGNATURE----- --1sNVjLsmu1MXqwQ/-- From rabbi@quickie.net Wed Oct 24 23:27:02 2001 From: rabbi@quickie.net (Len Sassaman) Date: Wed Oct 24 22:27:02 2001 Subject: 1.0.6b comments In-Reply-To: <20011024161016.A2155@akamai.com> Message-ID: On Wed, 24 Oct 2001, David Shaw wrote: > Hiya, > > I've been playing with 1.0.6b, and have a few comments. Some of these > are not necessarily bugs, and some of them exist in 1.0.6 as well. > > Aside from this, 1.0.6b is really great. I love --update-trustdb. > > 1) Merely having the secret key present is not enough to make a key > ultimately trusted. You have to do it by hand in --edit. If a new > key is generated, however, it is ultimately trusted. That is correct behavior. (There's a possible attack on systems that automatically import keys received in email that doing it this way protects against. I can describe it in more detail if you like.) > 8) RSA key signatures are always made with MD5 as the hash. This > makes sense for v3 key sigs, but v4 RSA key sigs are probably safe > to use something else. Yes. In PGP 7.0, we used SHA-1. No reason to stick with MD5. Also, RSA v4 keys bind their subkeys to the primary key using SHA-1 in PGP 7.x as well. > As I see it, if you are making a signature on a v4 key using your > v3 key, it doesn't make sense to generate a v3 sig. After all, the > point of using a v3 sig is to be backwards compatible, but no > v3-only PGP implementation could understand the v4 key the sig is > on in the first place. PGP versions prior to 5.x could not do v4 at all. PGP 5.x and 6.x understood v4 sigs on keys, but not on non-key material. (There's a nit about this in the RFC for 5.x; it should say 6.x as well.) (Just reiterating what you are saying here -- if an implementation can handle a v4 key, it can handle v4 sigs on a v4 key, even if it can't handle v4 sigs on other files. -- Len Sassaman Security Architect | "Now it's all change -- Technology Consultant | It's got to change more." | http://sion.quickie.net | --Joe Jackson From JanuszA.Urbanowicz Thu Oct 25 01:40:01 2001 From: JanuszA.Urbanowicz (JanuszA.Urbanowicz) Date: Thu Oct 25 00:40:01 2001 Subject: 1.0.6b comments (fwd) Message-ID: --ELM711998029-25058-0_ Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit -- Janusz A. Urbanowicz | ALEX3-RIPE | SF-Framling | Thawte Web Of Trust Notary Gdy dajê biednym chleb, nazywaj± mnie ¶wiêtym. Gdy pytam, dlaczego biedni nie maj± chleba, nazywaj± mnie komunist±. - abp. Helder Camara --ELM711998029-25058-0_ Content-Type: message/rfc822 Content-Disposition: inline Content-Description: Forwarded message from Janusz A . Urbanowicz Content-Transfer-Encoding: 8bit Subject: Re: 1.0.6b comments In-Reply-To: <20011024161016.A2155@akamai.com> from David Shaw at "Oct 24, 2001 04:10:16 pm" To: David Shaw Date: Thu, 25 Oct 2001 00:14:05 +0200 (CEST) From: Janusz A. Urbanowicz X-Latin-Date: Hodie VIII Kal. Nov. MMDCCLIV AUC est X-Mayan-Date: 12.19.08.12.03 X-Erisian-Date: Pungenday, The Aftermath 6, 3167 YOLD X-Operating-System: Linux sword 2.2.16 i586 X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit Content-Length: 1884 David Shaw wrote/napisa³[a]/schrieb: -- Start of PGP signed section. > Hiya, > > I've been playing with 1.0.6b, and have a few comments. Some of these > are not necessarily bugs, and some of them exist in 1.0.6 as well. > > Aside from this, 1.0.6b is really great. I love --update-trustdb. Aside that trust checking during signature verification in 1.0.6b is waay slower thanit was in 1.0.6a. And this is after setting ultimate trust on keys and rerunning update-trustdb a few times. Daaing my remark: 11) I have a (local signature) on a key using signing subkey of my key (since this is lsig it is not very important). This sig is not taken into account when calculating trust: :alex@sword:[~]:223:> gpg --edit-key RSA gpg (GnuPG) 1.0.6b; 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. gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! pub 1024R/DE46F54F created: 1999-09-16 expires: never trust: f/- ~~~ (1). Personal Freemail RSA 1999.9.16 Command> check uid Personal Freemail RSA 1999.9.16 sig! DE46F54F 1999-09-16 [self-signature] sig! 7E2E803D 2001-10-17 Janusz A. Urbanowicz (notebook) ; from alex@bofh.torun.pl on Thu, Oct 25, 2001 at 12:49:33AM +0200 References: Message-ID: <20011024190939.A13100@akamai.com> --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 25, 2001 at 12:49:33AM +0200, Janusz A. Urbanowicz wrote: > 11) I have a (local signature) on a key using signing subkey of my key > (since this is lsig it is not very important). This sig is not taken into > account when calculating trust: I can confirm this. It seems to apply to any key signature (local or not local) made by a signing subkey. 1.0.6b won't let signing subkeys make key signatures any longer, but there are some sigs there from older versions. David --=20 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 --pWyiEgJYm5f9v55/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6b (GNU/Linux) iQEVAwUBO9dKM4ccwqs8s7QVAQE++ggAohTk952P3iAfv9jRTWb8qHUW7F7T+7cY VCPH9D2OLIXTZOhlnhnHEcA4tCHAYEA3IMzxChTdTE4ocbX86FKomMpoDREW6Pz0 9qr0zqLXVNv+3ZOPYOnY9iB8x3IjIopF2cNhQEJeqBDRuZ0Dx2wmXq4v4jyKM+iw O5mIkdBvcsfDNbMROeOemDHSqc4UEPaEyaO5KE8KAtDwkyOga0kIwzLlNiJwSHLH Xph8HFhryN30ktEDuUhrfCAFteZW0VZTW0rG7Bzei8lBGN1+MH+9DPEBWVyEM9et BEisFDlW4GYsx2kK9z6ngLrKSgCKD0BldexjRc12O+oBrujMDVMm4w== =xz+f -----END PGP SIGNATURE----- --pWyiEgJYm5f9v55/-- From JanuszA.Urbanowicz Thu Oct 25 11:53:01 2001 From: JanuszA.Urbanowicz (JanuszA.Urbanowicz) Date: Thu Oct 25 10:53:01 2001 Subject: 1.0.6b comments In-Reply-To: <20011024161016.A2155@akamai.com> from David Shaw at "Oct 24, 2001 04:10:16 pm" Message-ID: David Shaw wrote/napisa³[a]/schrieb: -- Start of PGP signed section. > Hiya, > > I've been playing with 1.0.6b, and have a few comments. Some of these > are not necessarily bugs, and some of them exist in 1.0.6 as well. > > Aside from this, 1.0.6b is really great. I love --update-trustdb. Aside that trust checking during signature verification in 1.0.6b is waay slower thanit was in 1.0.6a. And this is after setting ultimate trust on keys and rerunning update-trustdb a few times. Daaing my remark: 11) I have a (local signature) on a key using signing subkey of my key (since this is lsig it is not very important). This sig is not taken into account when calculating trust: :alex@sword:[~]:223:> gpg --edit-key RSA gpg (GnuPG) 1.0.6b; 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. gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! pub 1024R/DE46F54F created: 1999-09-16 expires: never trust: f/- ~~~ (1). Personal Freemail RSA 1999.9.16 Command> check uid Personal Freemail RSA 1999.9.16 sig! DE46F54F 1999-09-16 [self-signature] sig! 7E2E803D 2001-10-17 Janusz A. Urbanowicz (notebook) Geachte heer/mevrouw Nog 1 dag en dan is het zover: de releasedatum van WINDOWS XP !! Windows XP, het allernieuwste besturingssysteem van Microsoft, kunt u nu bij ons bestellen !! U bestelt via deze e-mail Windows XP? Profiteer dan tevens van een fikse korting op KILOMETERDECLARATIE 2001 ! U kunt Kilometerdeclaratie 2001 aanschaffen van: fl. 99,- (44,92 Euro) voor: fl. 69,- (31,31 Euro) Onderaan deze e-mailing vindt u onze speciale aanbiedingen met kortingen die oplopen tot bijna 40%. Voor een totaaloverzicht van ons assortiment: www.teledirekt.nl Wilt u extra productinformatie of een goed advies? Bel GRATIS de Teledirekt Verkoopadvieslijn: 0800-237 66 44 Als u direct wilt bestellen: http://63.105.9.58/em/em47pt.htm ============================================================== # WINDOWS XP BRENGT UW PC NAAR ONGEKENDE HOOGTE - DE NIEUWE STANDAARD VOOR EFFICIËNT EN BETROUWBAAR COMPUTERGEBRUIK - Windows XP heeft een totaal nieuwe look en is ook inhoudelijk aanzienlijk veranderd. Het besturingssysteem haakt direct in op de vooruitgang van internet en de digitale media. Microsoft introduceert een aantal edities van Windows XP die zijn afgestemd op uw computerbehoeften zowel thuis als op kantoor. * WINDOWS XP HOME EDITION * De Windows XP Home Edition is het nieuwe besturingssysteem voor de PC thuis en biedt u alles wat u nodig hebt om eenvoudig computers en een thuisnetwerk te delen. Met de digitale fotofuncties kunt u foto's ophalen, organiseren en delen met de alles-in-één muziekfunctie kunt u kwalitatief hoogstaande muziek ontdekken, downloaden, opslaan en afspelen. - Één plaats voor het afspelen van DVD's, ordenen van muziek, branden van CD's, etc. - Films opnemen, bewerken, ordenen en delen op uw computer. - Afbeeldingen ordenen en bekijken of afdrukken van uw foto's bestellen via een webservice. - Eenvoudiger dan ooit om uw eigen thuisnetwerk te installeren. Prijs: fl. 615,- (279,07 Euro) Win 98/2000/ME Art.nr: 303070 Bestellen: http://63.105.9.58/em/em47pt.htm * WINDOWS XP HOME EDITION UPGRADE Prijs: fl. 285,- (129,33 Euro) Win 98/2000/ME Art.nr: 303071 Bestellen: http://63.105.9.58/em/em47pt.htm * WINDOWS XP PROFESSIONAL EDITION Biedt alle voordelen van Windows XP plus o.a. een hogere veiligheid en eersteklas mobiele ondersteuning om off-line te kunnen werken of om op afstand toegang te krijgen tot uw computer. Prijs: fl. 924,- (419,29 Euro) Win 98/2000/ME Art.nr: 303068 Bestellen: http://63.105.9.58/em/em47pt.htm * WINDOWS XP PROFESSIONAL EDITION UPGRADE Prijs: fl. 571,- (259,11 Euro) Win 98/2000/ME Art.nr: 303069 Bestellen: http://63.105.9.58/em/em47pt.htm U bestelt Windows XP via deze e-mailing?? Dan kunt u Kilometerdeclaratie 2001 aanschaffen van: fl. 99,- (44,92 Euro) voor: fl. 69,- (31,31 Euro) Dit kunt u aangeven op het bestelformulier: http://63.105.9.58/em/em47pt.htm ============================================================== # CD'S WISSELEN IS NIET MEER NODIG Kopieer uw favoriete CD-Rom's naar uw harde schijf. CD's tot 20 x sneller toegankelijk. Prijs: fl. 129,- (58,54 Euro) Win 95/98/NT/2000 Art.nr: 303042 Bestellen: http://63.105.9.58/em/em47pt.htm ============================================================== # CD-FOONGIDS 2001 + ADRESBESTAND COMPACT Meer dan 7.000.000 adressen met telefoon-, fax- en mobiele nummers. Prijs: fl. 69,- (31,31 Euro) Win 95/98/NT/2000/ME Art.nr: 302779 Bestellen: http://63.105.9.58/em/em47pt.htm ============================================================== # CURSUS INTERNET, WINDOWS 98, WORD, EXCEL EN POWERPOINT Bundelprijs: fl. 79,- (35,85 Euro) Win 95/98 Art.nr: 302918 Bestellen: http://63.105.9.58/em/em47pt.htm ============================================================== # ONTWERP ZELF UW EIGEN INTERNETSITE Prijs: fl. 85,- (38,57 Euro) Win 95/98/NT/2000/ME Art.nr: 303034 Bestellen: http://63.105.9.58/em/em47pt.htm ============================================================== ** Teledirekt aanraders ** 1. Nedsoft EuroOffice pro, fl. 149,- (67,61 Euro) Microsoft Office-documenten omzetten in de Euro (art.nr: 303009) 2. CardIris, fl. 699,- (317,19 Euro) Met één klik al uw visitekaartjes in uw PC (art.nr: 302759) 3. Easy Travel Plus, fl. 79,- (35,85 Euro) Alle straten van de Benelux op één CD-Rom (art.nr: 301590) 4. 333.000 Professionele afbeeldingen, fl. 169,- (76,69 Euro) Cliparts, bitmapafbeeldingen, internetanimaties, foto's, afbeeldingen (art.nr: 301025) 5. NL-Sat, fl. 42,50 (19,29 Euro) Satellietatlas van Nederland (art.nr: 301445) Bestellen: http://63.105.9.58/em/em47pt.htm ============================================================== ** Aanbiedingen OP = OP ** # VISUAL VOORRAAD, voor een eenvoudig en overzichtelijk voorraadbeheer. Dit pakket biedt u onder andere het volgende: - Voorraden beheren. - Klant-/leveranciersafspraken bijhouden. - Automatisch bestellingen genereren. - Deelleveringen bij goederen ontvangen. - Historie van bestel- en verkoopgegevens vastleggen en opvragen. - Beheer van meerdere magazijnen (van eenvoudig tot zeer geavanceerd). - Uitgebreide opvraag van omzetgegevens per periode, artikel/artikelgroep of klant. - Ondersteuning vreemde valuta en talen. van: fl. 995,- voor: fl. 695,- (30% korting) van: 451,51 Euro voor: 315,38 Euro Art.nr: 301038 Bestellen: http://63.105.9.58/em/em47pt.htm ============================================================== # RECRUITMENT ASSISTENT, sollicitaties snel en efficiënt afhandelen. Recruitment Assistent helpt u bij het vinden van de beste kandidaat voor een vacature. Het systeem bespaart u tijd bij het maken van brieven, houdt de administratie van uw correspondentie bij en assisteert u bij de verwerking van de gegevens. Zodat u zich kunt concentreren op de mensen zelf.... van: fl. 799,- voor: fl. 499,- (38% korting) van: 362,57 Euro voor: 226,44 Euro Art.nr: 301308 Bestellen: http://63.105.9.58/em/em47pt.htm ============================================================== Als u gebruik wilt maken van deze aanbiedingen, dan kunt u bestellen via internet: http://63.105.9.58/em/em47pt.htm U hebt de producten (indien op voorraad) binnen 2 dagen op uw bureau. Met vriendelijke groet, Teledirekt Nederland De genoemde prijzen zijn exclusief BTW. Administratiekosten: fl. 15,- (6,81 Euro). ************************************************************** Wanneer u SoftwareNieuws niet meer wilt ontvangen, kunt u: 1. dit aangeven op http://www.teledirektnederland.nl/maillijst2.htm; 2. ons telefonisch op de hoogte stellen dat u van de maillijst verwijderd wilt worden; 3. een e-mailtje sturen naar softwarenieuws@teledirekt.nl U kunt zich ook algemeen afmelden voor commerciële e-mail berichten via www.e-mps.org/nl Deze e-mailing is verzonden geheel volgens de gedragscode van de DMSA. ************************************************************** Teledirekt Nederland B.V. Kelvinring 58 2952 BG Alblasserdam GRATIS Verkoopadvieslijn: 0800 - 237 66 44 Helpdesk (1 gpm): 0900 - 237 66 48 Fax: 078 - 691 98 29 E-mail adressen: Klantenservice: mailto:klantenservice@teledirekt.nl Helpdesk: mailto:helpdesk@teledirekt.nl Bestelcode: EM47p From vogtm@skunk.physik.uni-erlangen.de Thu Oct 25 14:27:01 2001 From: vogtm@skunk.physik.uni-erlangen.de (Marco Vogt) Date: Thu Oct 25 13:27:01 2001 Subject: Windows XP: al vanaf fl. 285,- In-Reply-To: <57472001104251111160@teledirekt.nl> Message-ID: On Thu, 25 Oct 2001, Teledirekt Nederland wrote: > > Geachte heer/mevrouw > Nog 1 dag en dan is het zover: de releasedatum van WINDOWS XP !! > > Windows XP, het allernieuwste besturingssysteem van Microsoft, kunt u nu > bij ons > bestellen !! LOL, I think this firm don't really know to whom they send their spam... Long lives Linux... From subscriber@locustcreek.com Thu Oct 25 16:30:02 2001 From: subscriber@locustcreek.com (Oblio) Date: Thu Oct 25 15:30:02 2001 Subject: Windoze question Message-ID: <5.1.0.14.2.20011025091250.038d1600@mail.locustcreek.com> Hi, I'm new to this list, so please bear with me. I've been poking around the Net looking for the C++ libraries for PGP to write my own program. I'd like to get open source libraries as I will be creating software for commercial endeavors. The other issue is I'd like them for Windows, preferably Win2K. If anyone can help, I'd appreciate it. Oblio From apm35@student.open.ac.uk Thu Oct 25 18:37:01 2001 From: apm35@student.open.ac.uk (Andrew Marlow) Date: Thu Oct 25 17:37:01 2001 Subject: Windoze question Message-ID: I think this has hightlighted an important point about the GPG web site. It is not immediately obvious (to me, anyway) from the web site that GPG is covered by the GPL. Those in the know will presume it is, since it is a GNU project. But here we have someone asking about open source. IMO GNU projects make an important distinction between open source and free software. I believe that GPG is in the latter category. This means that GPG is software that has freedom and the license says that in order for you to enjoy this freedom you must not take it away from others. Some GPL'd source comes with libraries that are LGPL'd. The LGPL allows the library to be used in the development of closed-source proprietary software. Whether you use PGP or GPG you need to check these things out. Just having the source code available is not enough. License permitting, I would recommend GPG over PGP since I think GPG has a closer eye on the RFC and other issues, such as crypto-law and patent law. GPG has also taken some decisions which have made it less vunerable to certain problems (e.g the ADK issue). -apm From dshaw@jabberwocky.com Thu Oct 25 18:43:01 2001 From: dshaw@jabberwocky.com (David Shaw) Date: Thu Oct 25 17:43:01 2001 Subject: More 1.0.6b comments Message-ID: <20011025114043.D7040@akamai.com> --/NkBOFFp2J2Af1nK Content-Type: multipart/mixed; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Here's a few more comments: 12) If you set a key to ultimate trust, and it's the only ultimately trusted key, gpg gets confused if you unset its ultimate trust. The key will still be shown as "u", but --check-trustdb warns "no ultimately trusted keys found" and schedules the next update for "????-??-??". 13) Once --update-trustdb starts, there is no way to exit it ("q" just skips to the next key). 14) Little bug: in 1.0.6, if you changed trust via the --edit menu, gpg would display the new trust after you changed it. 1.0.6b does not do this. Attached is a fix for #13 and #14. It also adds a "s" for skip, which skips to the next key since "q" now actually quits. The existing "s" (for the not yet implemented more information) is now "i". David --=20 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 --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch.gnupg-1.0.6b.dms.trustupdate.1" Content-Transfer-Encoding: quoted-printable Index: pkclist.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/gnupg/gnupg/g10/pkclist.c,v retrieving revision 1.58.2.24 diff -u -r1.58.2.24 pkclist.c --- pkclist.c 2001/10/23 08:03:45 1.58.2.24 +++ pkclist.c 2001/10/25 03:40:23 @@ -241,7 +241,7 @@ keyid_from_pk (pk, keyid); for(;;) { /* a string with valid answers */ - const char *ans =3D _("sSmMqQ"); + const char *ans =3D _("iImMqQsS"); =20 if( !did_help )=20 { @@ -268,15 +268,18 @@ tty_printf (_(" %d =3D I trust fully\n"), 4); if (mode) tty_printf (_(" %d =3D I trust ultimately\n"), 5); - tty_printf (_(" s =3D please show me more information\n") ); + tty_printf (_(" i =3D please show me more information\n") ); if( mode ) tty_printf(_(" m =3D back to the main menu\n")); else - tty_printf(_(" q =3D quit\n")); + { + tty_printf(_(" s =3D skip this key\n")); + tty_printf(_(" q =3D quit\n")); + } tty_printf("\n"); did_help =3D 1; } - if( strlen(ans) !=3D 6 ) + if( strlen(ans) !=3D 8 ) BUG(); p =3D cpr_get("edit_ownertrust.value",_("Your decision? ")); trim_spaces(p); @@ -319,6 +322,10 @@ { break ; /* back to the menu */ } + else if( !mode && (*p =3D=3D ans[6] || *p =3D=3D ans[7] ) ) + { + break; /* skip */ + } else if( !mode && (*p =3D=3D ans[4] || *p =3D=3D ans[5] ) ) { quit =3D 1; @@ -346,7 +353,7 @@ switch ( do_edit_ownertrust (pk, mode, &trust, no_help ) ) { case -1: /* quit */ - return 0; + return -1; case -2: /* show info */ show_paths(pk, 1); no_help =3D 1; @@ -355,7 +362,7 @@ trust &=3D ~TRUST_FLAG_DISABLED; trust |=3D get_ownertrust (pk) & TRUST_FLAG_DISABLED; update_ownertrust (pk, trust ); - return 0; + return 1; default: return 0; } Index: trustdb.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/gnupg/gnupg/g10/trustdb.c,v retrieving revision 1.81.2.25 diff -u -r1.81.2.25 trustdb.c --- trustdb.c 2001/09/28 16:59:47 1.81.2.25 +++ trustdb.c 2001/10/25 03:40:27 @@ -846,12 +846,12 @@ *********** NEW NEW NEW **************** ****************************************/ =20 -static unsigned int +static int ask_ownertrust (u32 *kid) { PKT_public_key *pk; int rc; - unsigned int ot; + int ot; =20 pk =3D m_alloc_clear (sizeof *pk); rc =3D get_pubkey (pk, kid); @@ -862,10 +862,13 @@ return TRUST_UNKNOWN; } =20 - if (edit_ownertrust (pk, 0)) + ot=3Dedit_ownertrust(pk,0); + if(ot>0) ot =3D get_ownertrust (pk); - else + else if(ot=3D=3D0) ot =3D TRUST_UNDEFINED; + else + ot =3D -1; /* quit */ free_public_key( pk ); return ot; } @@ -1303,6 +1306,7 @@ validate_keys (int interactive) { int rc =3D 0; + int quit=3D0; struct key_item *klist =3D NULL; struct key_item *k; struct key_array *keys =3D NULL; @@ -1377,7 +1381,12 @@ { if (interactive && k->ownertrust =3D=3D TRUST_UNKNOWN) k->ownertrust =3D ask_ownertrust (k->kid); - if (k->ownertrust =3D=3D TRUST_UNKNOWN) + if (k->ownertrust =3D=3D -1) + { + quit=3D1; + goto leave; + } + else if (k->ownertrust =3D=3D TRUST_UNKNOWN) ot_unknown++; else if (k->ownertrust =3D=3D TRUST_UNDEFINED) ot_undefined++; @@ -1448,7 +1457,7 @@ release_key_array (keys); release_key_items (klist); release_key_hash_table (visited); - if (!rc) /* mark trustDB as checked */ + if (!rc && !quit) /* mark trustDB as checked */ { if (next_expire =3D=3D 0xffffffff) tdbio_write_nextcheck (0);=20 --qMm9M+Fa2AknHoGS-- --/NkBOFFp2J2Af1nK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6b (GNU/Linux) iQEVAwUBO9gye4ccwqs8s7QVAQFYewf+NQUjzjA68VOfESBVMyTG9N1FNlo+MO4R BwF9CczWutXUzC0zE1QxBI1U6gq5nkR8rqf9liFLgH0rzegNaP2ab9FkXoPW3jWE rJGdpZP4G01+87vcN1wBo8LMcVE1HCh/1a1HGHR0XAuLWWJ44Cgd6sWQDlekLGW0 BUPUsxBAF1VPBXsBjdNYdynxiYDoPLd+srfXc44N3yyJPNOuNFIU7JRZo6zDLhQR o61pq7ueSpmsjkSpbgsk1+Av56bBPj2ovwCBwZdNhHpnidVZhZveFkZTy7uK6WUU yfpQhOE5os4oNcr9Lsj287r0GzcM8EfGx6m+DQBZWKA+25EUXQR54w== =OL52 -----END PGP SIGNATURE----- --/NkBOFFp2J2Af1nK-- From Fabian.Rodriguez@Toxik.com Thu Oct 25 21:37:02 2001 From: Fabian.Rodriguez@Toxik.com (Toxik - Fabian Rodriguez) Date: Thu Oct 25 20:37:02 2001 Subject: Verisign / Network Solutions PGP guardian method does not support GnuPG In-Reply-To: <5.1.0.14.2.20011025091250.038d1600@mail.locustcreek.com> Message-ID: Hello, From time to time I verify different scenarios in which our customers may use GnuPG as a complete replacement to PGP. It is interesting to note that Network Solutions' PGP guardian method does not work with GnuPG generated signatures. I am enclosing the original response (less my message), as reference. Please note that I used GnuPG v1.0.6 (MingW32) and WinPT 0.4.0a. Then with PGP 7.03 it was completed fine, with the exact same text, using the same key, same software (Outlook), etc. Only the encryption software was different. BTW, on their site they mention: "Our PGP keyserver will accept PGP Version 2.6 to 6.5.2.", however I sent my key generated with GnuPG/WinPT by email and their server accepted it. And the message I sent after that (resulting in the error reply), was signed with PGP 7.03. Also note it took 18 days for the key to be added (instead of 24h). I thought it would be more appropiate to send it here than to risk it being lost in their support system. Thank you, Fabian Rodriguez - Toxik Technologies Inc. www.Toxik.com - Open PGP ID: 0x5AF2A4D5 > -----Original Message----- > From: Domain Registration Role Account [mailto:domreg@networksolutions.com] > Sent: October 24, 2001 16:42 > To: dnsadmin@toxik.com > Subject: Re: [NIC-XXXXXX.XXXX] DOMAIN NAME (request id modified for privacy purposes) > > > Thank you for contacting VeriSign. > > We have received your message, but are unable to process it at this > time. The most likely reasons why this may have happened are listed > below. Please review this list and compare the possible errors with > your message. If possible, correct the error and re-send your e-mail > to VeriSign at hostmaster@networksolutions.com. > > 1. Your PGP signed message was MIME-encapsulated. Most Windows based > e-mail applications will perform this conversion. Currently, we cannot > support PGP signed messages that have been MIME-encapsulated. > > 2. There are extra characters in your message, which distort your PGP > signature and make it impossible for us to confirm that your signature > is correct. These extra characters are inserted when a PGP plugin for > Outlook or Eudora are used to sign a message, and the message is then > sent to a system using a UNIX platform, which we use. Currently, we > cannot support PGP signed messages sent from a computer using any > platform other than UNIX. > > 3. Although PGP is your Guardian method, you did not sign your message > with your PGP private key. Please sign your message with your PGP > private key and return it by e-mail to VeriSign at > hostmaster@networksolutions.com. > > 4. It appears that you have more than one PGP private key. Although you > signed this message with a PGP key, you didn't use the PGP private key > that is associated with the contact handle on this record. Please make > sure that you are using the right PGP private key to sign your message > and return the message by e-mail to VeriSign at > hostmaster@networksolutions.com. > > Best regards, > VeriSign, Inc. > http://www.netsol.com From jam@jamux.com Fri Oct 26 15:52:01 2001 From: jam@jamux.com (John A. Martin) Date: Fri Oct 26 14:52:01 2001 Subject: Verisign / Network Solutions PGP guardian method does not support GnuPG In-Reply-To: ("Toxik - Fabian Rodriguez"; Thu, 25 Oct 2001 14:34:39 -0400) Message-ID: <20011026124944.CF9263B891@athene.jamux.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "FR" == Fabian Rodriguez >>>>> "Verisign / Network Solutions PGP guardian method does not support GnuPG" >>>>> Thu, 25 Oct 2001 14:34:39 -0400 FR> Hello, From time to time I verify different scenarios in which FR> our customers may use GnuPG as a complete replacement to FR> PGP. It is interesting to note that Network Solutions' PGP FR> guardian method does not work with GnuPG generated signatures. Compare: http://lists.gnupg.org/pipermail/gnupg-users/2001-September/010016.html http://lists.gnupg.org/pipermail/gnupg-users/2001-September/010019.html http://lists.gnupg.org/pipermail/gnupg-users/2001-September/010027.html http://lists.gnupg.org/pipermail/gnupg-users/2001-September/010035.html Especially the last. jam -----BEGIN PGP SIGNATURE----- Comment: OpenPGP encrypted mail preferred. See iEYEARECAAYFAjvZW5YACgkQUEvv1b/iXy+bnQCfTL++f7dy0y1AA733oYWiK61O llwAn2p51JVa1Q5lOhhepLv4Nbb91IMZ =d0wo -----END PGP SIGNATURE----- From roconnor@math.berkeley.edu Mon Oct 29 00:56:01 2001 From: roconnor@math.berkeley.edu (roconnor@math.berkeley.edu) Date: Mon Oct 29 00:56:01 2001 Subject: GnuPG for OS/2 Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I thought I'd let the list know of a port to OS/2. - -- Russell O'Connor roconnor@math.berkeley.edu ``This is not a time, as it is never a time, to seek vengeance, but a time to seek the courage to forgive'' -- George W. Bush -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (SunOS) Comment: For info see http://www.gnupg.org iD8DBQE73JqXZG3em5NXM14RAk3WAKDyhgsQkW4dbqfXYvbigW8RD4tT7gCdEFGi 5YvNZNgq0ozTd37+HYqf9og= =bo4q -----END PGP SIGNATURE----- From wk@gnupg.org Mon Oct 29 08:56:01 2001 From: wk@gnupg.org (Werner Koch) Date: Mon Oct 29 08:56:01 2001 Subject: GnuPG for OS/2 In-Reply-To: (roconnor@math.berkeley.edu's message of "Sun, 28 Oct 2001 15:53:52 -0800 (PST)") References: Message-ID: <87u1wianis.fsf@alberti.gnupg.de> On Sun, 28 Oct 2001 15:53:52 -0800 (PST), roconnor said: > I thought I'd let the list know of a port to OS/2. > How to you handle the RNG issue? Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From roconnor@math.berkeley.edu Mon Oct 29 09:03:01 2001 From: roconnor@math.berkeley.edu (roconnor@math.berkeley.edu) Date: Mon Oct 29 09:03:01 2001 Subject: GnuPG for OS/2 In-Reply-To: <87u1wianis.fsf@alberti.gnupg.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 29 Oct 2001, Werner Koch wrote: > How to you handle the RNG issue? I wrote a Rexx Entropy Gathering Daemon based on the Perl EGD. It's not as good as a driver to gather interupt infromation, but should be about as good as the Perl EGD. - -- Russell O'Connor roconnor@alumni.uwaterloo.ca ``This is not a time, as it is never a time, to seek vengeance, but a time to seek the courage to forgive'' -- George W. Bush -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (SunOS) Comment: For info see http://www.gnupg.org iD8DBQE73QzYZG3em5NXM14RAuVHAJ9LrKvHGV04O6nd3fONkCMUorky/QCg1bx1 HSSmex1FEoWjb2cZbQfRZoQ= =a7/l -----END PGP SIGNATURE----- From wk@gnupg.org Mon Oct 29 09:50:02 2001 From: wk@gnupg.org (Werner Koch) Date: Mon Oct 29 09:50:02 2001 Subject: GnuPG for OS/2 In-Reply-To: (roconnor@math.berkeley.edu's message of "Mon, 29 Oct 2001 00:01:22 -0800 (PST)") References: Message-ID: <874roial19.fsf@alberti.gnupg.de> On Mon, 29 Oct 2001 00:01:22 -0800 (PST), roconnor said: > I wrote a Rexx Entropy Gathering Daemon > based on the Perl EGD. > It's not as good as a driver to gather interupt infromation, but should be > about as good as the Perl EGD. But what do you use as source for the entropy? It may have changed in recent version of OS/2 but I am not aware of any system services which can be used. The only way I can think to do it is by writing Device drivers becuase this way you can get in closer touch with the kernel. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From rabbi@quickie.net Mon Oct 29 10:03:01 2001 From: rabbi@quickie.net (Len Sassaman) Date: Mon Oct 29 10:03:01 2001 Subject: Windoze question In-Reply-To: Message-ID: On Thu, 25 Oct 2001, Andrew Marlow wrote: > License permitting, I would recommend GPG over PGP since I think GPG has a > closer eye on the RFC and other issues, such as crypto-law and patent law. > GPG has also taken some decisions which have made it less vunerable to > certain problems (e.g the ADK issue). Just about all of the above statements are not based on fact. -- Len Sassaman Security Architect | "Now it's all change -- Technology Consultant | It's got to change more." | http://sion.quickie.net | --Joe Jackson From roconnor@math.berkeley.edu Mon Oct 29 16:45:02 2001 From: roconnor@math.berkeley.edu (roconnor@math.berkeley.edu) Date: Mon Oct 29 16:45:02 2001 Subject: GnuPG for OS/2 In-Reply-To: <874roial19.fsf@alberti.gnupg.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 29 Oct 2001, Werner Koch wrote: > But what do you use as source for the entropy? It may have changed in > recent version of OS/2 but I am not aware of any system services which > can be used. The only way I can think to do it is by writing Device > drivers becuase this way you can get in closer touch with the kernel. Well, I use system and network statistics like the Perl EGD does. I use - -list of processes running - -how long they have been running - -how long the computer has been up - -the time - -list of running threads and their state - -list of semaphores - -list of loaded modules - -free memory available - -network mbufs - -udp stats - -ip stats - -current socket stats - -current routing table (and use stats) - -general interface stats - -arp table - -- Russell O'Connor roconnor@alumni.uwaterloo.ca ``This is not a time, as it is never a time, to seek vengeance, but a time to seek the courage to forgive'' -- George W. Bush -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (SunOS) Comment: For info see http://www.gnupg.org iD8DBQE73XjuZG3em5NXM14RAlMZAJwIEzXcq3IijE05UWvMBti2bmMXmACdHLSf qO0c+l/dcIErAYxoQN+qRgk= =ONUi -----END PGP SIGNATURE----- From JanuszA.Urbanowicz Wed Oct 31 22:04:01 2001 From: JanuszA.Urbanowicz (JanuszA.Urbanowicz) Date: Wed Oct 31 22:04:01 2001 Subject: trust problem in the b snapshot Message-ID: Problems with trust calculation - again: The environment is: :alex@sword:[~]:11:> gpg --version gpg (GnuPG) 1.0.6b [..] I signed and set trust for following keys: pub 1024D/826BAA66 created: 2001-07-14 expires: never trust: f/f pub 1024D/FC494FC4 created: 2000-12-06 expires: never trust: f/f pub 1024D/F9289982 created: 1997-10-13 expires: never trust: f/f pub 2048R/2C67FD2D created: 1999-05-18 expires: never trust: f/f Now I import 7AA3260A from certserver.pgp.com which is signed by the keys I trust: pub 1024D/7AA3260A 2000-05-13 Artur Stepien sig 7AA3260A 2000-11-21 Artur Stepien sig 826BAA66 2001-07-16 Robert R. Wal (Gadzinka) sig FC494FC4 2001-07-19 Miros/law Baran (Jubal) uid Artur Stepien (Muczachan) sig 7AA3260A 2000-11-21 Artur Stepien sig 826BAA66 2001-07-16 Robert R. Wal (Gadzinka) sig FC494FC4 2001-07-19 Miros/law Baran (Jubal) uid Artur St\xc3\xaapie\xc3\xb1 (Muczachan) sig 7AA3260A 2000-05-13 Artur Stepien sig 826BAA66 2001-07-14 Robert R. Wal (Gadzinka) sig 2C67FD2D 2001-07-14 Robert R. Wal (PGP2 RSA key) sig 0CA7686C 2000-11-21 [User id not found] sig F9289982 2000-09-12 Szymon Sokol sig FC494FC4 2001-07-19 Miros/law Baran (Jubal) sub 2048g/04706BBF 2000-05-13 sig 7AA3260A 2000-05-13 Artur Stepien but I got no trust for the key?! pub 1024D/7AA3260A created: 2000-05-13 expires: never trust: -/- Alex -- Janusz A. Urbanowicz | ALEX3-RIPE | SF-Framling | Thawte Web Of Trust Notary Gdy dajê biednym chleb, nazywaj± mnie ¶wiêtym. Gdy pytam, dlaczego biedni nie maj± chleba, nazywaj± mnie komunist±. - abp. Helder Camara From halpin@qwpage.com Wed Oct 31 23:42:01 2001 From: halpin@qwpage.com (halpin@qwpage.com) Date: Wed Oct 31 23:42:01 2001 Subject: Making GnuPg w/Cygwin Message-ID: <3BE03802.16183.AA96018@localhost> Hello all, this is my first post. Right off the bat you'll have to forgive me - I work on a Windoze box. So, speak slowly and use simple words. :-) I've used Cygwin successfully in the past to make Win32 Tcl/Tk binaries that run on this box, so I think my my environment is fairly sound. The versions are: Cygwin B20 gcc version egcs-2.91.57 19980901 (egcs-1.1 release) GNU assembler version 2.9.4 (i586-cygwin32) using BFD version 2.9.4 GNU Make version 3.75 I'm trying to make GnuPg 1.0.6 Problem 1 ---------------- bash-2.02$ cd //d/gnupg-1.0.6 bash-2.02$ cd zlib bash-2.02$ make clean test -z "libzlib.a" || rm -f libzlib.a test -z "foo.gz" || rm -f foo.gz rm -f *.o core *.core bash-2.02$ make gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -c adler32.c gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -c compress.c gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -c inffast.c rm -f libzlib.a ar cru libzlib.a adler32.o compress.o crc32.o uncompr.o libzlib.a libzlib.a: 1: Syntax error: redirection unexpected make: *** [libzlib.a] Error 2 bash-2.02$ In the MAKEFILE I see: RANLIB = libzlib.a: $(libzlib_a_OBJECTS) $(libzlib_a_DEPENDENCIES) -rm -f libzlib.a $(AR) cru libzlib.a $(libzlib_a_OBJECTS) $(libzlib_a_LIBADD) $(RANLIB) libzlib.a If I remove the last line ($(RANLIB) libzlib.a, I can get all the way through. Is this the correct thing to do? (There is a ranlib in my cygwin bin directory.) Problem 2 -------------- Having removed the RANLIB statements in several of the MAKEFILEs, I now get this: `echo gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../intl -g -O2 -Wall -D IS_MODULE -shared -fPIC -o tiger ./tiger.c | \ sed -e 's/-O[2-9s]*/-O/g' ` gcc: unrecognized option `-shared' In file included from ./tiger.c:26: ..\include\util.h:207: warning: `stricmp' redefined C:\cygnus\CYGWIN~1\H-I586~1\bin\..\lib\gcc-lib\i586-cygwin32\egcs- 2.91.57\..\..\ ..\..\i586-cygwin32\include\string.h:76: warning: this is the location of the previous definition /cygnus/CYGWIN~1/H-I586~1/i586-cygwin32/bin/as.exe: bfd assertion fail /home/noer/src/b20/comp-tools/devo/bfd/coff-i386.c:479 C:\Temp\ccz8EiPb.s: Assembler messages: C:\Temp\ccz8EiPb.s:2261: Error: Cannot represent relocation type BFD_RELOC_386_GOTPC /cygnus/CYGWIN~1/H-I586~1/i586-cygwin32/bin/as.exe: bfd assertion fail /home/noer/src/b20/comp-tools/devo/bfd/coff-i386.c:479 C:\Temp\ccz8EiPb.s:2357: Error: Cannot represent relocation type BFD_RELOC_386_GOTPC /cygnus/CYGWIN~1/H-I586~1/i586-cygwin32/bin/as.exe: bfd assertion fail /home/noer/src/b20/comp-tools/devo/bfd/coff-i386.c:479 C:\Temp\ccz8EiPb.s:2565: Error: Cannot represent relocation type BFD_RELOC_386_GOTPC /cygnus/CYGWIN~1/H-I586~1/i586-cygwin32/bin/as.exe: bfd assertion fail /home/noer/src/b20/comp-tools/devo/bfd/coff-i386.c:479 C:\Temp\ccz8EiPb.s:2931: Error: Cannot represent relocation type BFD_RELOC_386_GOTPC /cygnus/CYGWIN~1/H-I586~1/i586-cygwin32/bin/as.exe: bfd assertion fail /home/noer/src/b20/comp-tools/devo/bfd/coff-i386.c:479 C:\Temp\ccz8EiPb.s:3200: Error: Cannot represent relocation type BFD_RELOC_386_GOTPC /cygnus/CYGWIN~1/H-I586~1/i586-cygwin32/bin/as.exe: bfd assertion fail /home/noer/src/b20/comp-tools/devo/bfd/coff-i386.c:479 C:\Temp\ccz8EiPb.s:3356: Error: Cannot represent relocation type BFD_RELOC_386_GOTPC /cygnus/CYGWIN~1/H-I586~1/i586-cygwin32/bin/as.exe: bfd assertion fail /home/noer/src/b20/comp-tools/devo/bfd/coff-i386.c:479 C:\Temp\ccz8EiPb.s:3761: Error: Cannot represent relocation type BFD_RELOC_386_GOTPC /cygnus/CYGWIN~1/H-I586~1/i586-cygwin32/bin/as.exe: bfd assertion fail /home/noer/src/b20/comp-tools/devo/bfd/coff-i386.c:479 C:\Temp\ccz8EiPb.s:3875: Error: Cannot represent relocation type BFD_RELOC_386_GOTPC make[2]: *** [tiger] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive-am] Error 2 :-( Asserts, eh? Who the heck do 'ya call on this? -------------------------------------------- Any tips appreciated - and if this is posted to the wrong list please accept my apologies. Regards Bob Halpin (I may be crazy, but I'm not (too) stupid.) P.S. - Anybody got a MAKEFILE for Borland? From jshayward@pobox.com Mon Oct 1 20:47:08 2001 From: jshayward@pobox.com (Jonathan Hayward -- http://JonathansCorner.com) Date: Mon Oct 1 19:47:08 2001 Subject: gpg initialization Message-ID: <3BB84CCE.6CCBA5C1@pobox.com> --------------E38B76217F7A0792CE6D3082 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Is there any documentation (besides the comments/code) to how gpg initializes? -- Jonathan Hayward jshayward@pobox.com http://JonathansCorner.com (A four dimensional maze, stories, essays, artwork, and other things...) --------------E38B76217F7A0792CE6D3082 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Is there any documentation (besides the comments/code) to how gpg initializes?
-- 
Jonathan Hayward
jshayward@pobox.com
http://JonathansCorner.com
(A four dimensional maze, stories, essays, artwork, and other things...)
  --------------E38B76217F7A0792CE6D3082-- From mbp2@Lehigh.EDU Mon Oct 1 23:15:01 2001 From: mbp2@Lehigh.EDU (mbp2@Lehigh.EDU) Date: Mon Oct 1 22:15:01 2001 Subject: Adding recipients to an encrypted message? Message-ID: <1001967174.3bb8ce46744b5@IMP.Lehigh.EDU> A suggestion for a new feature... the ability to add recipients to an encrypted message. If I have a file or message that's encrypted to me, and I want to give it securely to someone else, it's awkward to have to decrypt the whole thing and then re-encrypt it again to the new person, especially if the file is large. It'd be very useful if I could tell GPG to decrypt the session key using my private key and immediately encrypt it (just the session key) with the new person's public key, and then add a new recipient packet to the message without touching the encrypted message body. This is not only more secure (it's easier to wipe a small decrypted session key from memory than a whole decrypted message), but also faster and more convenient. -- Mike Paul mbp2@lehigh.edu http://www.lehigh.edu/~mbp2/ From wk@gnupg.org Tue Oct 2 00:36:01 2001 From: wk@gnupg.org (Werner Koch) Date: Mon Oct 1 23:36:01 2001 Subject: Adding recipients to an encrypted message? In-Reply-To: <1001967174.3bb8ce46744b5@IMP.Lehigh.EDU> (mbp2@Lehigh.EDU's message of "Mon, 01 Oct 2001 16:12:54 -0400 (EDT)") References: <1001967174.3bb8ce46744b5@IMP.Lehigh.EDU> Message-ID: <878zev3v0j.fsf@alberti.gnupg.de> On Mon, 01 Oct 2001 16:12:54 -0400 (EDT), mbp2 said: > then re-encrypt it again to the new person, especially if the file is large. > It'd be very useful if I could tell GPG to decrypt the session key using my > private key and immediately encrypt it (just the session key) with the new have a look at the options $ gpg --dump-options |grep session --show-session-key --override-session-key The simplest way would be something like this: $ gpg --show-session-key -o foo.txt foo.gpg 2>&1 \ | gpg -e -r key-escrow@privacy.gov | mail solo@u.n.c.l.e And on the u.n.c.l.e site Napoleon could do this: $ gpg --override-session-key extracted_from_mail msg_from_echelon Well you can also use the session key to create a public key encrypted packet and prepend it to the message - however there is no direct support for it in GnuPG. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From mbp2@Lehigh.EDU Tue Oct 2 04:36:01 2001 From: mbp2@Lehigh.EDU (mbp2@Lehigh.EDU) Date: Tue Oct 2 03:36:01 2001 Subject: Adding recipients to an encrypted message? Message-ID: <1001986429.3bb9197d660f9@IMP.Lehigh.EDU> I was thinking of something that would produce an ordinary OpenPGP message that can be decrypted normally to the new recipient... maybe the recipient isn't convinced of the usefulness of cryptography in the first place, or is using commercial PGP so they can't use --override-session-key, or both. In both the GPG documentation and your example, the --show-session key option is described as being meant for key-escrow purposes. I'm talking about the more casual act of forwarding a message to someone. It shouldn't be too hard to add an option... something like "gpg --add-recipient ciphertext.gpg newrecipient@foo.com" which would extract the session key and add a new recipient packet to the message. (I'm submitting to the list without being subscribed so hopefully the threading will work correctly...) -- Mike Paul mbp2@lehigh.edu http://www.lehigh.edu/~mbp2/ From wk@gnupg.org Tue Oct 2 10:54:01 2001 From: wk@gnupg.org (Werner Koch) Date: Tue Oct 2 09:54:01 2001 Subject: Adding recipients to an encrypted message? In-Reply-To: <1001986429.3bb9197d660f9@IMP.Lehigh.EDU> (mbp2@Lehigh.EDU's message of "Mon, 01 Oct 2001 21:33:49 -0400 (EDT)") References: <1001986429.3bb9197d660f9@IMP.Lehigh.EDU> Message-ID: <87vghy32fg.fsf@alberti.gnupg.de> On Mon, 01 Oct 2001 21:33:49 -0400 (EDT), mbp2 said: > described as being meant for key-escrow purposes. I'm talking about the more > casual act of forwarding a message to someone. It shouldn't be too hard to add I can't think of a situation where you want to forward an encrypted message to another recipient without reading the message first. -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From Florian.Weimer@RUS.Uni-Stuttgart.DE Tue Oct 2 16:26:01 2001 From: Florian.Weimer@RUS.Uni-Stuttgart.DE (Florian Weimer) Date: Tue Oct 2 15:26:01 2001 Subject: Adding recipients to an encrypted message? In-Reply-To: <87vghy32fg.fsf@alberti.gnupg.de> (Werner Koch's message of "Tue, 02 Oct 2001 09:51:15 +0200") References: <1001986429.3bb9197d660f9@IMP.Lehigh.EDU> <87vghy32fg.fsf@alberti.gnupg.de> Message-ID: Werner Koch writes: > On Mon, 01 Oct 2001 21:33:49 -0400 (EDT), mbp2 said: > I can't think of a situation where you want to forward an encrypted > message to another recipient without reading the message first. Encrypted mailing lists could be implemented more efficiently if the main message part would not have to be encrypted over and over again. (Because of padding, the reused session key should not be a problem even with RSA, but I'm not sure about that.) -- Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 From pgut001@cs.auckland.ac.nz Tue Oct 2 17:15:01 2001 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) Date: Tue Oct 2 16:15:01 2001 Subject: Adding recipients to an encrypted message? Message-ID: <200110021412.CAA135615@ruru.cs.auckland.ac.nz> Florian Weimer writes: >Werner Koch writes: >>On Mon, 01 Oct 2001 21:33:49 -0400 (EDT), mbp2 said: >>I can't think of a situation where you want to forward an encrypted >>message to another recipient without reading the message first. >Encrypted mailing lists could be implemented more efficiently if the main >message part would not have to be encrypted over and over again. (Because of >padding, the reused session key should not be a problem even with RSA, but I'm >not sure about that.) The S/MIME folks have looked at this problem in some detail over quite some time, there are RFCs/RFC drafts available from the S/MIME WG home page http://www.imc.org/ietf-smime/index.html. (They also have a second home page at http://www.ietf.org/html.charters/smime-charter.html which has a non- overlapping set of drafts, you may need to check there. Try and ignore the fact that the page is shared with drafts on how to do X.400 with S/MIME). Peter. From sosa1004kr@yahoo.co.kr Thu Oct 4 22:43:03 2001 From: sosa1004kr@yahoo.co.kr (ÃÊû°­¿¬) Date: Thu Oct 4 21:43:03 2001 Subject: [ÃÊû°­¿¬ È«º¸] ±× ´©°¡ °¨È÷ Çй®Àº ¾ø¾ú´Ù°í ¿ÜÃÆ´ø°¡? Message-ID: <200110041940.f94Jeard020040@mail.openit.de> PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPGh0 bWw+DQo8aGVhZD4NCjx0aXRsZT6iwCC9xcH2vcTAziDDysO7ILCtv6zIuCCiwDwvdGl0bGU+ DQoNCjxtZXRhIG5hbWU9IkdFTkVSQVRPUiIgY29udGVudD0iTmFtbyBXZWJFZGl0b3IgdjQu MCI+DQo8L2hlYWQ+DQo8Qk9EWT4NCjxQIGFsaWduPWxlZnQ+PEZPTlQgc2l6ZT0yPjxTUEFO IA0Kc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IGZ1Y2hzaWEiPjwvU1BBTj48L0ZPTlQ+PEZP TlQgc2l6ZT0yPjxTUEFOIA0Kc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IGZ1Y2hzaWEiPjxT UEFOIHN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiB3aGl0ZSI+PEZPTlQgDQpzaXplPTE+vsiz 58fPvLy/5C4guru43sDPwLogsK2/rMi4IMiruri4piDAp8fPv6kmbmJzcDsxyLi8uiC43sDP wMy45yC43sDPIMioxuTAzMH2v80gsNS9w8bHv6G8rSANCrz2wf21yLDNwNS0z7TZPC9GT05U PjwvU1BBTj48L1NQQU4+PC9GT05UPjwvUD4NCjxQIGFsaWduPWNlbnRlcj48Rk9OVCBzaXpl PTU+PFNQQU4gc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IGZ1Y2hzaWEiPqLAIL3Fwfa9xMDO IMPKw7sgDQqwrb+syLggosA8L1NQQU4+PC9GT05UPjxGT05UIGNvbG9yPWJsYWNrPjxTUEFO IA0Kc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IHdoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L1NQQU4+PC9GT05UPjwvUD4NCjxQIGFsaWduPWxl ZnQ+PEZPTlQgY29sb3I9YmxhY2s+PFNQQU4gc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IHdo aXRlIj7BpLq4yK0gvcO067+hIMH2wPsgDQrIo7HivcnAzCC4ucC6ILTnvcUgISE8QlI+PEJS PjwvU1BBTj48L0ZPTlQ+PFNQQU4gc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IHdoaXRlIj69 xcH2vcTAziDDysO7IA0Kuau34SCwrb+syLi/oSC01MC7IMPKtOvHz7DtwNogx9W0z7TZLjwv U1BBTj48Rk9OVCBjb2xvcj1uYXZ5PjxTUEFOIA0Kc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6 IHdoaXRlIj48QlI+Jm5ic3A7PC9TUEFOPjwvRk9OVD48L1A+DQo8UCBhbGlnbj1sZWZ0PjxG T05UIGNvbG9yPWJsYWNrPjxTUEFOIHN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiB3aGl0ZSI+ wfax3bHuwfYgsdcgtKmwoSANCrCoyPcgPC9TUEFOPjwvRk9OVD48Rk9OVCBjb2xvcj0jNDAw MDQwPjxTUEFOIA0Kc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IHdoaXRlIj48U1RST05HPsfQ ua7AuiC++L76tNk8L1NUUk9ORz48L1NQQU4+PC9GT05UPjxTUEFOIA0Kc3R5bGU9IkJBQ0tH Uk9VTkQtQ09MT1I6IHdoaXRlIj48Rk9OVCBjb2xvcj1ibGFjaz6w7SANCr/cw8a0+LChPzxC Uj4mbmJzcDs8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9TUEFOPjwvRk9OVD48Rk9O VCBjb2xvcj1ibHVlPjxTUEFOIA0Kc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IHdoaXRlIj7H 0LmuPC9TUEFOPjwvRk9OVD48Rk9OVCBjb2xvcj1ibGFjaz48U1BBTiANCnN0eWxlPSJCQUNL R1JPVU5ELUNPTE9SOiB3aGl0ZSI+wMy29T8gLSA8U1BBTiANCnN0eWxlPSJCQUNLR1JPVU5E LUNPTE9SOiB3aGl0ZSI+PC9TUEFOPjxGT05UIGNvbG9yPWJsYWNrIHNpemU9Mj48U1BBTiAN CnN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiB3aGl0ZSI+u+e5sMDHIMDMxKG/zSC6u8H6wLsg sdS47cfPtMIgDQqwzcDMtNkuPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyANCrmwwfrAxyDD1rzStNzAp8DOIL/4wNouLiAmbmJzcDu/+MDa ILzTwMcgwPzA2rTCILmrvbwgv6GzysH2t84gtbm+xrChsO0gwNa0wrChPzwvU1BBTj48L1NQ QU4+PC9GT05UPjwvUD4NCjxQIGFsaWduPWxlZnQ+PEZPTlQgY29sb3I9Ymx1ZT48U1BBTiAN CnN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiB3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7vcXH0DwvU1BBTj48L0ZPTlQ+PEZPTlQgDQpjb2xvcj1ibGFjaz48U1BBTiBzdHlsZT0i QkFDS0dST1VORC1DT0xPUjogd2hpdGUiPsDMtvU/IC0gPFNQQU4gDQpzdHlsZT0iQkFDS0dS T1VORC1DT0xPUjogd2hpdGUiPjwvU1BBTj48Rk9OVCBjb2xvcj1ibGFjayBzaXplPTI+PFNQ QU4gDQpzdHlsZT0iQkFDS0dST1VORC1DT0xPUjogd2hpdGUiPr3Fv6EgtOvH2CCz7cfPtMIg DQrH0LmuPz8/Pz88QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7sde3syANCr3FwMcgurvB+sC6IA0Kuau++cDOsKE/PEJSPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxTUEFOIA0Kc3R5bGU9IkJBQ0tHUk9VTkQtQ09M T1I6IHdoaXRlIj48L1NQQU4+PC9GT05UPjxGT05UIHNpemU9Mj48U1BBTiANCnN0eWxlPSJC QUNLR1JPVU5ELUNPTE9SOiB3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7vcXAuyC+y8H2IA0KuPjHz7TCtaUgvu62u7DUIL3Fv6EgtOvH2CCz7cfS ILz2IMDWtMKwoT88L1NQQU4+PC9TUEFOPjwvRk9OVD48L1A+DQo8UCBhbGlnbj1sZWZ0PjxG T05UIGNvbG9yPWJsYWNrPjxTUEFOIHN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiB3aGl0ZSI+ x9C5rrD6IL3FwLsgDQrD37G4x8+0wiA8L1NQQU4+PC9GT05UPjxGT05UIGNvbG9yPWJsdWU+ PFNQQU4gc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IHdoaXRlIj7AzrCjwLogsPq/rCANCr7u trIgwbjA5zwvU1BBTj48L0ZPTlQ+PEZPTlQgY29sb3I9YmxhY2s+PFNQQU4gDQpzdHlsZT0i QkFDS0dST1VORC1DT0xPUjogd2hpdGUiPsDOsKE/PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO7bHIA0KPC9TUEFOPjwvRk9OVD48Rk9OVCBjb2xvcj1i bHVlPjxTUEFOIHN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiB3aGl0ZSI+wM6wo8DHILq7wfqw +iANCrzTvLo8L1NQQU4+PC9GT05UPjxGT05UIGNvbG9yPWJsYWNrPjxTUEFOIHN0eWxlPSJC QUNLR1JPVU5ELUNPTE9SOiB3aGl0ZSI+wLogsPq/rCANCr7utrDH0bChPzxCUj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDvAzrCjwMcgDQq757DtwMcgxse0 3CCx4sHYwLogsPq/rCDBpMiux9EgsM3AzrChPyA8QlI+Jm5ic3A7PC9TUEFOPjwvRk9OVD48 L1A+DQo8UCBhbGlnbj1sZWZ0PjxGT05UIGNvbG9yPWJsYWNrPjxTUEFOIHN0eWxlPSJCQUNL R1JPVU5ELUNPTE9SOiB3aGl0ZSI+wfax3bHuwfYgwfi4rrbzsO0gDQq5z77uv9S0+CChwaHB ocEgJm5ic3A7PC9TUEFOPjwvRk9OVD48Rk9OVCBjb2xvcj1yZWQ+PFNQQU4gDQpzdHlsZT0i QkFDS0dST1VORC1DT0xPUjogd2hpdGUiPrv9ISDA2iEgx8ohILjqITwvU1BBTj48L0ZPTlQ+ PC9QPg0KPFAgYWxpZ249bGVmdD48Rk9OVCBjb2xvcj1ibGFjaz48U1BBTiBzdHlsZT0iQkFD S0dST1VORC1DT0xPUjogd2hpdGUiPjIxvLyx4iC8vLDowMcgDQrD1sO3tNwgudnAzL/AILD6 x9DA2rXpv6EgwMfH2CCx17DNwMwgsMXB/sDTwMwgueDH9MH2sO0sIDxCUj48QlI+PFNQQU4g DQpzdHlsZT0iQkFDS0dST1VORC1DT0xPUjogd2hpdGUiPjwvU1BBTj48Rk9OVCBjb2xvcj1i bGFjayBzaXplPTI+PFNQQU4gDQpzdHlsZT0iQkFDS0dST1VORC1DT0xPUjogd2hpdGUiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0gDQrAr8D8 x9DA2rXpIDogMjCz4rO7IMDOsKMgvPa47SA0MLvsIL3DtOu/wrTZIC0gvbrG98P3IMG2vLEg MTk5Mi4gOS4gDQoxOS48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7wdfAvcC6IA0KwNq/rL+hIL+qx+DHz7TC IA0KsM3AzLTZLjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDvAzrCjwLogDQq4u8fPwNq46SCx1yDA2sO8sKEg wNq1vyC6uLz2IA0KwNrEocDMtNkuPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyiz67qnIA0KyK3H0LvzILz2u/PA2sDOILnMsbnAxyC288DMs8q9uiDG+ri1ILna u+cpPC9TUEFOPjwvU1BBTj48L0ZPTlQ+PC9QPg0KPFAgYWxpZ249bGVmdD48Rk9OVCBjb2xv cj1ibGFjayBzaXplPTI+PFNQQU4gDQpzdHlsZT0iQkFDS0dST1VORC1DT0xPUjogd2hpdGUi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0gDQq6 0rfOutK75yDAr8D8wNogud+w3yC538elIDogucyxuSC3zr26ILGzvPYgJm5ic3A7MTk5ObPi IDe/+SA1wM88L1NQQU4+PC9GT05UPjwvUD4NCjxQIGFsaWduPWxlZnQ+PEZPTlQgY29sb3I9 YmxhY2sgc2l6ZT0yPjxTUEFOIA0Kc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IHdoaXRlIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstIA0Kv+y4 riC49iC807+hIL+1u/3AuyCx4r7vx8+0wiC8vMb3tenAzCANCsDWtNk8QlI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0OyANCjE5OTGz4iA4v/kgucyxuSBBQkMg VFYguea828DHILrSu+e/oSCw/MfRIFRWIMXkt9AmZ3Q7PEJSPjxTUEFOIA0Kc3R5bGU9IkJB Q0tHUk9VTkQtQ09MT1I6IHdoaXRlIj48L1NQQU4+PEZPTlQgY29sb3I9YmxhY2s+PFNQQU4g DQpzdHlsZT0iQkFDS0dST1VORC1DT0xPUjogd2hpdGUiPjxCUj48L1NQQU4+PC9GT05UPjxG T05UIGNvbG9yPXJlZD48U1BBTiANCnN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiB3aGl0ZSI+ PC9TUEFOPjwvRk9OVD48U1RST05HPjxGT05UIHNpemU9Mz48U1BBTiANCnN0eWxlPSJCQUNL R1JPVU5ELUNPTE9SOiB3aGl0ZSI+vLHB+CDDt7TcIMfQua7AuiC/z8D8IMH4uK64piDD37G4 IMXrx9ggutK3zrrSu+co3dXW1d3V3t0puKYguPHHpbfOIA0Kud/A/DwvU1BBTj48Rk9OVCBj b2xvcj1ibGFjaz48U1BBTiBzdHlsZT0iQkFDS0dST1VORC1DT0xPUjogd2hpdGUiPrXHsO0g DQrA1r3AtM+02S48L1NQQU4+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9TVFJPTkc+PC9QPg0K PFAgYWxpZ249bGVmdD48Rk9OVCBzaXplPTM+PFNUUk9ORz48U1BBTiBzdHlsZT0iQkFDS0dS T1VORC1DT0xPUjogd2hpdGUiPrq7ILCtv6zIuLTCIA0KutK3zrrSu+cgsdcgwaS787+hvK0g udm287q7PC9TUEFOPjxGT05UIGNvbG9yPXJlZD48U1BBTiBzdHlsZT0iQkFDS0dST1VORC1D T0xPUjogd2hpdGUiPiANCjwvU1BBTj48L0ZPTlQ+PC9TVFJPTkc+PC9GT05UPjxTUEFOIHN0 eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiB3aGl0ZSI+PEZPTlQgDQpzaXplPTM+PFNUUk9ORz6/ z8D8x9Egx9C5riwgwb6xsywgsPrH0C4uLi7AuyAmbmJzcDu/qbevutC16b+hsNQgwPzH2CC1 5biusO3A2iDH1bTPtNkuPC9TVFJPTkc+PC9GT05UPiANCjwvU1BBTj48L1A+DQo8UCBhbGln bj1sZWZ0PjxGT05UIGNvbG9yPXJlZD48U1BBTiBzdHlsZT0iQkFDS0dST1VORC1DT0xPUjog d2hpdGUiPjxGT05UIA0KY29sb3I9IzAwMDAwMD7B+MPrwPvAzLjnIL+tuLAguLbAvcC4t84g wfa9xMC7ILClsbjHz7TCIMDMtenAxyC4uLOywMcgvcOwo8DMILXHvcOx5iANCrnZtvi0z7TZ LjwvRk9OVD48QlI+PC9QPjwvU1BBTj48L0ZPTlQ+DQo8UCBhbGlnbj1sZWZ0PjxGT05UIGNv bG9yPWJsYWNrPjxTUEFOIHN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiBhcXVhIj7AzyANCiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO73DIDogMjAwMbPiIDEwv/kgNsDPIL/AyMQg M73DPC9TUEFOPjwvRk9OVD48L1A+DQo8UCBhbGlnbj1sZWZ0PjxGT05UIGNvbG9yPWJsYWNr PjxTUEFOIHN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiBhcXVhIj7A5SANCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO7zSIDogus7DtSC9w7nOIMi4sPwgvNKwrbTnPC9TUEFOPjwv Rk9OVD48L1A+DQo8UCBhbGlnbj1sZWZ0PjxGT05UIGNvbG9yPWJsYWNrPjxTUEFOIA0Kc3R5 bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IHdoaXRlIj48L1NQQU4+PC9GT05UPiZuYnNwOzwvUD48 L0ZPTlQ+PC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9GT05UPg0KPC9CT0RZPg0KPC9odG1sPg0K From jan@intevation.de Fri Oct 5 15:07:01 2001 From: jan@intevation.de (Jan-Oliver Wagner) Date: Fri Oct 5 14:07:01 2001 Subject: ANN: Sphinx (S/MIME, X.509) project for MUAs (KMail, mutt) Message-ID: <20011005140441.B14526@intevation.de> Dear list, we are happy to announce that the German "Bundesamt für Sicherheit in der Informationstechnik" (Federal Agency for IT Security, BSI) contracted us (Intevation, Klarälvdalens Datakonsult and g10 Code) to make sure that Free Software for their email security standard Sphinx will be created. Sphinx basically consists of S/MIME, a PKIX compatible X.509 profile, together with certificate revocation lists (CRLs) based on LDAP. The code developed will be modular allowing inclusion in several MUAs released under the GNU GPL. Part of the contract with the BSI is the inclusion in mutt and KMail. The initial project pages can be reached from the URL below. We wanted to get the good news out to you as fast as possible. Expect more information to get released on the website or on the corresponding mailing lists. We plan to do the development in an open manner suitable for Free Software projects. We want to handle the project in a way that it will leverage and add to the work of other developers and ask for your collaboration. The BSI pays us to ensure that their specs are followed precisely and the result passes strict tests. This is the first time the BSI contracts for Free Software development and the experiences they make will be important. We will demonstrate the power of commercial Free Software. www.gnupg.org/aegypten -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From bre@klaki.net Fri Oct 5 18:50:02 2001 From: bre@klaki.net (Bjarni R. Einarsson) Date: Fri Oct 5 17:50:02 2001 Subject: Strange problem with GnuPG 1.0.4 encrypted data Message-ID: <20011005154830.F15179@klaki.net> Hello, I have a system which GPG encrypts and signs files and mails them from one machine to another, where they are automatically decrypted and the signatures verified using a perl program. Last night a file was transferred which appeared to have a valid signature, but then couldn't be decrypted. Gnupg sent the following message to stderr: gpg: Warning: using insecure memory! gpg: encrypted with 1024-bit ELG-E key, ID FAFF94B3, created 2001-09-20 [snip] gpg: Signature made Thu Oct 4 20:45:46 2001 GMT using DSA key ID 327144DC gpg: Good signature from "[snip]" 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: B083 585B 8675 0058 5113 0F98 FA17 F199 3271 44DC gpg: [don't know]: invalid packet (ctb=14) The file was encrypted on a dual PIII 800Mhz machine using GnuPG 1.0.4 as distributed with RedHat Linux 7.1. I tried decrypting it both with GnuPG 1.0.4 and 1.0.6 (RH 7.1 update package), with the same results. I haven't been able to reproduce this problem yet, but since I'm creating and sending dozens of messages like this every day (usually without any problems) I rather expect it to manifest itself again sooner or later. My question is whether any bugs were found in GnuPG 1.0.4 which could cause this kind of bizarre failure, or whether I should start worrying about hardware problems. Also, am I correct in assuming that since the signature was OK, that I can rule out any transmission errors as the cause of this and focus on the creation of the encrypted file? If you developers feel this is a bug and that it would help to examine the file in question I have no problems sharing it and the necessary keys with you - I'm currently just testing this setup and regenerating my keys would be no big deal. Please CC: any replies directly to me, as I'm not subscribe to this list - and please forgive me if I overlooked a more appropriate venue for this message. Thanks! -- Bjarni R. Einarsson PGP: 02764305, B7A3AB89 bre@klaki.net -><- http://bre.klaki.net/ Check out my open-source email sanitizer: http://mailtools.anomy.net/ From jpg@rcom.com.ar Fri Oct 12 21:48:01 2001 From: jpg@rcom.com.ar (Juan Pablo =?ISO-8859-1?Q?Gim=E9nez?=) Date: Fri Oct 12 20:48:01 2001 Subject: gnupg Message-ID: <1002912389.10546.9.camel@kang.oficina.rcom.com.ar> --=-pTgFCmnR2fd7e/Nxvb5l Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi! I have a problem with the option "--with-colons" and --list-keys or --fingerprint, if i don't use it, gpg print my last name "Gim=E9nez" with the "=E9", but if I put with-colons insted of "=E9" gpg prints "=C3=A9"... = So here is the patch to fix it... ------------------------------------------------------------------------ ________________________________________________________________________ --- gnupg-1.0.6/g10/keylist.c Sun May 27 11:31:07 2001 +++ gnupg-1.0.6_rcom/g10/keylist.c Fri Oct 12 11:42:15 2001 @@ -482,8 +482,8 @@ printf("uid:%c::::::::", trustletter); } } - print_string( stdout, node->pkt->pkt.user_id->name, - node->pkt->pkt.user_id->len, ':' ); + print_utf8_string( stdout, node->pkt->pkt.user_id->name, + node->pkt->pkt.user_id->len); putchar(':'); if (any) putchar('\n'); ________________________________________________________________________ ------------------------------------------------------------------------- Chausesssssssssss Juan Pablo.... --=-pTgFCmnR2fd7e/Nxvb5l Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA7xzqFChXsK9PY/SsRAnkSAKCYjyqImAW+y7bs/AO79kIIQhs8oACePYXD lNsurU8tCaAj8V+uVZZkpoE= =9+Yx -----END PGP SIGNATURE----- --=-pTgFCmnR2fd7e/Nxvb5l-- From redbird@rbisland.cx Sun Oct 14 08:24:02 2001 From: redbird@rbisland.cx (Gordon Worley) Date: Sun Oct 14 07:24:02 2001 Subject: Goodbye 4th Amendment Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 http://arstechnica.com/wankerdesk/01q4/usa-act/usa-act.html Well, as some of you may already know, I and some of my fellow developers no longer have our 4th Amendment rights (protection from search and seizure for those of you who live outside the US). I don't know what the immediate effects will be for the project, other than that I may have to make sure binary releases are done all in one sitting use a fresh download of the source (may seem a little silly, but I'd rather be silly than release binaries with bad stuff in them). If you read the story on how this got passed, similar procedures could see anti-crypto laws passed through, though I think after this it will be some time before the House will stand for this. - -- 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 -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use Comment: keyserver http://pgpkeys.mit.edu:11371 iQA/AwUBO8kg627zd/e707ADEQKEZgCg4ouaFNX6ssrkDwLZzPJcdfRVQ2UAoJJL +v6iHEybHuLI+UkBKAlc/VhG =tpGT -----END PGP SIGNATURE----- From redbird@rbisland.cx Sun Oct 14 08:33:01 2001 From: redbird@rbisland.cx (Gordon Worley) Date: Sun Oct 14 07:33:01 2001 Subject: Goodbye 4th Amendment In-Reply-To: References: Message-ID: At 1:20 AM -0400 10/14/01, Gordon Worley wrote: Sorry, folks, that was supposed to go to the Mac GPG developer's list. -- 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 dshaw@jabberwocky.com Sun Oct 14 20:28:02 2001 From: dshaw@jabberwocky.com (David Shaw) Date: Sun Oct 14 19:28:02 2001 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <20011014131040.B8616@akamai.com>; from dshaw@jabberwocky.com on Sun, Oct 14, 2001 at 01:10:40PM -0400 References: <01101218054502.01491@mexicali.sito.saic.com> <20011014131040.B8616@akamai.com> Message-ID: <20011014132552.C8616@akamai.com> --bCsyhTFzCvuiizWE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 14, 2001 at 01:10:40PM -0400, David Shaw wrote: > At the moment, GnuPG (and PGP too) mark all signatures[1] as "I'm not > going to say". I think I feel a patch coming on.. Patch: http://www.jabberwocky.com/crypto/gnupg/patch.gnupg-1.0.6.dms.sigclass.1 Before you sign, GnuPG will prompt you for which level of certification you want to use. Answer "?" for an explanation of the different levels. This also changes key listings (in --edit-key and --list-sigs) to show which certification level was used in making the signature. No claim made as to how well it was checked: sig 3CB3B415 2001-10-14 David M. Shaw Key was not checked at all: sig 1 3CB3B415 2001-10-14 David M. Shaw Key was checked casually: sig 2 3CB3B415 2001-10-14 David M. Shaw Key was checked extensively: sig 3 3CB3B415 2001-10-14 David M. Shaw Comments welcome. David --=20 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 --bCsyhTFzCvuiizWE 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 iQEVAwUBO8nKoIccwqs8s7QVAQGcYgf/RL8fuO32MEUzi1sgVpOeayp915CCYOBo 7IrjMIerNXzNSmrDhoBTvEUxCMBSILxlbrdgY+aWDBwRhO5BS3W2wkhz/Ioovubo LV8O52aK3jlDjhZX2Q/RGPcLD9mCrgsgbBbFBcrF435Iz+WtoPCtcTJiThLLyja6 XlfTqdMO4ClqDQEoOMJX82Ihneb2j8bgdCRfMiRR5LX8DPQkn9rZUMf8vCufKaPB 8eRJPuBxV1aHXiva0TGzBXUxbPe/IG15gqmKFZiLsiV0Oarh/bvzs6ouTDZxJYIr dax0FCp+QjC+qC6Fox+nyiq+Lhoxb7wvSXyFm3YU0IKe++9Knb+C+g== =9F+1 -----END PGP SIGNATURE----- --bCsyhTFzCvuiizWE-- From broonie@sirena.org.uk Mon Oct 15 01:14:01 2001 From: broonie@sirena.org.uk (Mark Brown) Date: Mon Oct 15 00:14:01 2001 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <20011014132552.C8616@akamai.com> References: <01101218054502.01491@mexicali.sito.saic.com> <20011014131040.B8616@akamai.com> <20011014132552.C8616@akamai.com> Message-ID: <20011014231203.B1666@tardis.ed.ac.uk> On Sun, Oct 14, 2001 at 01:25:52PM -0400, David Shaw wrote: > sig 1 3CB3B415 2001-10-14 David M. Shaw > sig 2 3CB3B415 2001-10-14 David M. Shaw > sig 3 3CB3B415 2001-10-14 David M. Shaw It would be nice if these could be presented more clearly. I can't actually suggest a clearer way off-hand, mind you. Also, it would be nice if there were no space between the "sig" and the digit as in current output. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." From dshaw@jabberwocky.com Mon Oct 15 02:04:01 2001 From: dshaw@jabberwocky.com (David Shaw) Date: Mon Oct 15 01:04:01 2001 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <20011014231203.B1666@tardis.ed.ac.uk>; from broonie@sirena.org.uk on Sun, Oct 14, 2001 at 11:12:04PM +0100 References: <01101218054502.01491@mexicali.sito.saic.com> <20011014131040.B8616@akamai.com> <20011014132552.C8616@akamai.com> <20011014231203.B1666@tardis.ed.ac.uk> Message-ID: <20011014190116.F8616@akamai.com> --ylS2wUBXLOxYXZFQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 14, 2001 at 11:12:04PM +0100, Mark Brown wrote: > On Sun, Oct 14, 2001 at 01:25:52PM -0400, David Shaw wrote: >=20 > > sig 1 3CB3B415 2001-10-14 David M. Shaw > > sig 2 3CB3B415 2001-10-14 David M. Shaw > > sig 3 3CB3B415 2001-10-14 David M. Shaw >=20 > It would be nice if these could be presented more clearly. I can't > actually suggest a clearer way off-hand, mind you. Heh. I had the same thought. I thought about using letters, but it was even worse. At least numbers have the advantage of making a "3" clearly higher than a "2". > Also, it would be > nice if there were no space between the "sig" and the digit as in > current output. Try a --check-sigs. That space is taken for the sig status character. David --=20 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 --ylS2wUBXLOxYXZFQ 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 iQEVAwUBO8oZPIccwqs8s7QVAQF7VQf6A9OtLvAa0biDYsvsE+AEzKRid3epOOue P+4RbAkxHEAByrTY1c2j3zwMDQ2YrAchBaNGYhMQx5EHZf9vy+2A9IR1nCbmtrUP ezC5DiMZwzTGhg//dyoJRz8MPZvvARhPMHG1139V7ru4c0m0RoPft7qLYSXd0w90 yXZA6+jj8vCCZ+ags0nf2ucdIw+/uqasBGiY+8Jwrnt5H1QrglWFZmV4rKzUPoHu xl7xzTCOnY33e2nMWdZbKMoyh+D07eys/K24cT25pxGOql96WVwifL42pEocrKNx 4296EtUhxaV0uKMIHJYe9rGGES0Hs19EN1tEFbZ6bI2M+FwRp6YthQ== =2Y6T -----END PGP SIGNATURE----- --ylS2wUBXLOxYXZFQ-- From broonie@sirena.org.uk Mon Oct 15 02:26:01 2001 From: broonie@sirena.org.uk (Mark Brown) Date: Mon Oct 15 01:26:01 2001 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <20011014190116.F8616@akamai.com> References: <01101218054502.01491@mexicali.sito.saic.com> <20011014131040.B8616@akamai.com> <20011014132552.C8616@akamai.com> <20011014231203.B1666@tardis.ed.ac.uk> <20011014190116.F8616@akamai.com> Message-ID: <20011015002427.E1666@tardis.ed.ac.uk> --EY/WZ/HvNxOox07X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 14, 2001 at 07:01:16PM -0400, David Shaw wrote: > > Also, it would be > > nice if there were no space between the "sig" and the digit as in > > current output. > Try a --check-sigs. That space is taken for the sig status character. That's what I was thinking of :-) . At present there's no space before any extra data on the type of entity being listed. With your patch this would change. Not that one ought to be attempting machine parsing of the output of anything not --with-colons, but anyway. --=20 "You grabbed my hand and we fell into it, like a daydream - or a fever." --EY/WZ/HvNxOox07X 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 iD8DBQE7yh6qJ2Vo11xhU60RAnblAJ47gylietHVnZJvJvRWrqEkxWM/0ACfer1b 4fesK9hetflxR/+4vt72qEg= =1nxN -----END PGP SIGNATURE----- --EY/WZ/HvNxOox07X-- From dshaw@jabberwocky.com Mon Oct 15 05:48:01 2001 From: dshaw@jabberwocky.com (David Shaw) Date: Mon Oct 15 04:48:01 2001 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <20011015002427.E1666@tardis.ed.ac.uk>; from broonie@sirena.org.uk on Mon, Oct 15, 2001 at 12:24:27AM +0100 References: <01101218054502.01491@mexicali.sito.saic.com> <20011014131040.B8616@akamai.com> <20011014132552.C8616@akamai.com> <20011014231203.B1666@tardis.ed.ac.uk> <20011014190116.F8616@akamai.com> <20011015002427.E1666@tardis.ed.ac.uk> Message-ID: <20011014224503.B21134@akamai.com> --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 15, 2001 at 12:24:27AM +0100, Mark Brown wrote: > On Sun, Oct 14, 2001 at 07:01:16PM -0400, David Shaw wrote: >=20 > > > Also, it would be > > > nice if there were no space between the "sig" and the digit as in > > > current output. >=20 > > Try a --check-sigs. That space is taken for the sig status character. >=20 > That's what I was thinking of :-) . At present there's no space before > any extra data on the type of entity being listed. With your patch this > would change. Not that one ought to be attempting machine parsing of > the output of anything not --with-colons, but anyway. Ah, I understand now. Hmm. It's easy enough to move it over by one if there is no sig status, but don't you think that would make it harder to read rather than easier? The eye wouldn't be able to just look in the same place each time. I'm also toying with a patch to show various informative flags in that area (an "L" for a local signature, a "P" for a policy URL, "N" for a notation, etc). David --=20 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 --2oS5YaxWCcQjTEyO 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 iQEVAwUBO8pNr4ccwqs8s7QVAQHwuwgAiS1fuvi71XuSZclvvkL/tKbZtZyGpW0t yAvzNk4+AmXdeXKqFmz/sIsZe49bix2g7w/WXvKyRWflGobJd1Qk+z3CMP1yBRJy hAS41PTFuRYmixB8tjpWVdT0e75qP9x2bLBFgpsJH1uXlBzk54FkBEF8w6u/krHv s2OwOIJpmHpyPcz+08bjEzU0yd7J5OKo1PSAfehN7QxTZBle0xh4kEWIG8hR37ms mzFqyF93INdJjWXTfwdfLD65L+z+h3a/2ZNv3Ha0MHVVbJWVIUi0j9aXTr8gqPkz mjZKMUD4FyYCu5HfmTIleI9vAbBuvoF7+BojBGr1y9qRQz8nldogww== =DbG4 -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO-- From dshaw@jabberwocky.com Tue Oct 16 00:38:02 2001 From: dshaw@jabberwocky.com (David Shaw) Date: Mon Oct 15 23:38:02 2001 Subject: Sig classification, version 2 Message-ID: <20011015173637.B4515@akamai.com> Here's version 2 of the sig classification patch I sent in yesterday (thanks for the comments, everyone). It contains everything that was in version 1, with some better help text, and it also shows a few other pieces of information about the signature: 1-3 == amount of verification in the signature (just like before) L == local signature (e.g. made by "--lsign-key"). R == signature is non-revocable. P == a policy URL is attached to this signature. N == a notation is attached to this signature. You can use the --show-policy-url and --show-notation options to display the policy or notation (in a --list-sigs or --edit/check). There is also a --no-show-policy-url and --no-show-notation for the folks who like to override their config file on occasion. --fast-list-mode disables everything except the 1-3 levels of verification (which don't cost anything to retrieve). http://www.jabberwocky.com/crypto/gnupg/patch.gnupg-1.0.6.dms.sigclass.2 Comments welcome. 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 redbird@rbisland.cx Tue Oct 16 06:03:01 2001 From: redbird@rbisland.cx (Gordon Worley) Date: Tue Oct 16 05:03:01 2001 Subject: GPGME.framework Beta 0.2.3 Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Okay, now this message is supposed to show up on this list. ;-) At the Mac GPG project we've released GPGME.framework Beta 0.2.3. This should work on any OpenStepish environment, like GNUStep and Mac OS X. This beta is not a final release and is still missing a few features (use the source, I'll compile release notes when I have time), but there's enough there to get some stuff done. Feel free to beat it around and find any bugs. You can get Beta 0.2.3 here: http://sourceforge.net/project/showfiles.php?group_id=20789&release_id=57202 or just grab the latest out of the Mac GPG CVS tree. For more info on that and the project in general, visit: http://macgpg.sourceforge.net/ - -- 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 -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use Comment: keyserver http://pgpkeys.mit.edu:11371 iQA/AwUBO8ui3m7zd/e707ADEQL6ZQCgymipUUkThn1e+NFvJm+2bEc1Yh4AnRt4 J19AWLt+ZoLqJFAT6uYTGir6 =uniR -----END PGP SIGNATURE----- From mwy-gpg41@the-youngs.org Tue Oct 16 18:09:02 2001 From: mwy-gpg41@the-youngs.org (Michael Young) Date: Tue Oct 16 17:09:02 2001 Subject: Re; Sig classification (was Re: discussion on increasing amount of gpg signatures...) References: Message-ID: <003301c15654$23c8fa60$dfc32609@transarc.ibm.com> -----BEGIN PGP SIGNED MESSAGE----- > Before you sign, GnuPG will prompt you for which level of > certification you want to use. Answer "?" for an explanation of the > different levels. Excellent! A couple of months ago, I built a command-line switch to do this, but didn't get around to posting it. (When I looked back through the mailing list archives, it appeared that signature types were an unpopular idea at some past OpenPGP meetings.) How would you feel about adding a command-line option? As it stands, batch operations get a "generic" signature. I used "--sig-type" in my patch. I could recreate it against yours if you're interested. To make good use of these additional validity levels, the trust model really should understand them. For example, I might fully trust type-3 signatures from "John Smith", partially trust his type-2 signatures, and not trust any type-1. But that's for another day... I'm glad to see the first step. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQEVAwUBO8xM32NDnIII+QUHAQH52gf9Gmd7v524TaY+qJo9UhX8aG4naq69dn/b M+79JQj68xLpeWOVDtKFqSWVSOWcVBA2tiW6+JvZaJ9a5AAmfsk4yie3lQpS2Srp 9wmye2hm/y9CNfHD58PLiUYUlzWDhAj2V3+OZntkC7w9FWMRX3hz+9YCQ5XqpApj 59V5OjWV9XNgB4TkCvCEfGiY8dhJ9BMFBnQzYKvQoffsxVZdgoDK3x9Em+8OFLIw IeiIea6b3+AizaYQxUhAywxE6fdw0gX+gHP7I9Gxb0mZwLD//PY+jVGAW6QVvLAi l2lonJ6e1V5KuZpgNKzT1XK95w8/jzNZhstaEjOd+To4rnRYsYirRw== =i6n2 -----END PGP SIGNATURE----- From gnupg@lists.colondot.net Tue Oct 16 18:51:01 2001 From: gnupg@lists.colondot.net (Matthew Byng-Maddick) Date: Tue Oct 16 17:51:01 2001 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <003301c15654$23c8fa60$dfc32609@transarc.ibm.com>; from mwy-gpg41@the-youngs.org on Tue, Oct 16, 2001 at 11:06:30AM -0400 References: <003301c15654$23c8fa60$dfc32609@transarc.ibm.com> Message-ID: <20011016164931.A98387@colon.colondot.net> On Tue, Oct 16, 2001 at 11:06:30AM -0400, Michael Young wrote: > To make good use of these additional validity levels, the trust > model really should understand them. For example, I might > fully trust type-3 signatures from "John Smith", partially > trust his type-2 signatures, and not trust any type-1. > But that's for another day... I'm glad to see the first step. If you do this, you have to trust that he will choose the correct type of signature to sign with. MBM -- Matthew Byng-Maddick http://colondot.net/ From broonie@sirena.org.uk Tue Oct 16 19:37:02 2001 From: broonie@sirena.org.uk (Mark Brown) Date: Tue Oct 16 18:37:02 2001 Subject: Re; Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <003301c15654$23c8fa60$dfc32609@transarc.ibm.com> References: <003301c15654$23c8fa60$dfc32609@transarc.ibm.com> Message-ID: <20011016173439.G10896@tardis.ed.ac.uk> On Tue, Oct 16, 2001 at 11:06:30AM -0400, Michael Young wrote: > To make good use of these additional validity levels, the trust > model really should understand them. For example, I might > fully trust type-3 signatures from "John Smith", partially > trust his type-2 signatures, and not trust any type-1. > But that's for another day... I'm glad to see the first step. There are also trusted introducer signatures (which are implemented by NAI PGP). -- "You grabbed my hand and we fell into it, like a daydream - or a fever." From dshaw@jabberwocky.com Wed Oct 17 00:15:01 2001 From: dshaw@jabberwocky.com (David Shaw) Date: Tue Oct 16 23:15:01 2001 Subject: Re; Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <003301c15654$23c8fa60$dfc32609@transarc.ibm.com>; from mwy-gpg41@the-youngs.org on Tue, Oct 16, 2001 at 11:06:30AM -0400 References: <003301c15654$23c8fa60$dfc32609@transarc.ibm.com> Message-ID: <20011016171254.I667@akamai.com> --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 16, 2001 at 11:06:30AM -0400, Michael Young wrote: > > Before you sign, GnuPG will prompt you for which level of > > certification you want to use. Answer "?" for an explanation of the > > different levels. >=20 > Excellent! A couple of months ago, I built a command-line switch > to do this, but didn't get around to posting it. (When I looked > back through the mailing list archives, it appeared that signature > types were an unpopular idea at some past OpenPGP meetings.) >=20 > How would you feel about adding a command-line option? As it > stands, batch operations get a "generic" signature. I used > "--sig-type" in my patch. I could recreate it against yours > if you're interested. Good idea. I've added it to v3 of the patch. The command is --default-sig-class, and it takes a number from 0-3. If you set a default sig class in your options file, you can use --no-default-sig-class to override it back to 0. The menu that pops up when key signing will reflect the new default. Also added: * 'If you don't know what the right answer is, answer "0"' message * minor fix to notations - they should be printed as UTF8. http://www.jabberwocky.com/crypto/gnupg/patch.gnupg-1.0.6.dms.sigclass.3 David --=20 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 --ibTvN161/egqYuK8 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 iQEVAwUBO8yi1occwqs8s7QVAQE8XQf+JNjMSZiKbYP4YGVONoOAJLALIoym8AwN 9khnCVE//UOItw8uczxmQLE/FH/qvE3oXASyNPc9THTK0hCAkkAp3OkJ8tWprc6w TNNkLNP2GJyWNHwrTuHnbaN6KmCQ3KkQ3pLMHzTqml0qYn7LPeewAVc+qny14Q7a iiViBUr152SGiIeVTgCLOM82FVE92aPVoHPQGcqqgDBzwB+whMITsFlIWXyj5Yz1 TNiU1TQuFQvnnvPq+B4nSLia+oScqcnVxxI0h+YLLh4s1e3Fvs13ZazW+tNci9so or0YNuNRrkAJvrhrlr9+kSWL01flYh1vpvkd2SEUfym+7Tl1Zzgekw== =fxIw -----END PGP SIGNATURE----- --ibTvN161/egqYuK8-- From dshaw@jabberwocky.com Wed Oct 17 02:04:01 2001 From: dshaw@jabberwocky.com (David Shaw) Date: Wed Oct 17 01:04:01 2001 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <20011016164931.A98387@colon.colondot.net>; from gnupg@lists.colondot.net on Tue, Oct 16, 2001 at 04:49:31PM +0100 References: <003301c15654$23c8fa60$dfc32609@transarc.ibm.com> <20011016164931.A98387@colon.colondot.net> Message-ID: <20011016190152.K667@akamai.com> --w7PDEPdKQumQfZlR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 16, 2001 at 04:49:31PM +0100, Matthew Byng-Maddick wrote: > On Tue, Oct 16, 2001 at 11:06:30AM -0400, Michael Young wrote: > > To make good use of these additional validity levels, the trust > > model really should understand them. For example, I might > > fully trust type-3 signatures from "John Smith", partially > > trust his type-2 signatures, and not trust any type-1. > > But that's for another day... I'm glad to see the first step. >=20 > If you do this, you have to trust that he will choose the correct type of > signature to sign with. Yes, and also that he can choose his signature type in the first place. All versions of PGP create the generic "I'm not going to say how much checking I did" form of the signature. Incidentally, I did confirm that PGP (at least version 6.5.8 and later) does understand all 4 signature types, even though it can't generate them. David --=20 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 --w7PDEPdKQumQfZlR 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 iQEVAwUBO8y8YIccwqs8s7QVAQFljwgAgsxVckn5PpFTRrmTRiUpvxUWc5IHwqK2 pdV56GepfHGcy8v8J5Evp9VjAfXB5576WNuoNpAiMwg5RSoR+zlXp4IgJowo15rS g+dA83VUGpeJWLuxRyX1GlR32eWS3amVlnka21fJ66kOuzHxOpEn0nu7kZbxwGAt +4nnCRL/cmzBGDnL/ToPbfvzHsuhG2blUIPClirT7ffLysbDWd9pwgVQ2QIbhQg+ 2MyvCnFeyDANloGFPigtR+5fWskidWJbvTmvrwLStwwlNfhiUidfTbCQ3fFIlsGY gC2bY9/wLEeJIx4qBxtfNKW0K5aRuKOaIwsuAP4+pHdflip2deQT1g== =EKJ1 -----END PGP SIGNATURE----- --w7PDEPdKQumQfZlR-- From wk@gnupg.org Thu Oct 18 15:00:02 2001 From: wk@gnupg.org (Werner Koch) Date: Thu Oct 18 14:00:02 2001 Subject: Should I release a new snapshot? Message-ID: <87adypupjb.fsf@alberti.gnupg.de> Hi! Those of you who are using the CVS version have noticed a couple of major changes in GnuPG. There is still a long list of minor bugs but nevertheless I'd like to make a new snapshot available, so that the new code can be tested. Are there any grave bugs in the CVS versions? Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From ts@winpt.org Thu Oct 18 17:00:01 2001 From: ts@winpt.org (Timo Schulz) Date: Thu Oct 18 16:00:01 2001 Subject: Should I release a new snapshot? In-Reply-To: <87adypupjb.fsf@alberti.gnupg.de> References: <87adypupjb.fsf@alberti.gnupg.de> Message-ID: <20011018155031.E412@daredevil.joesixpack.net> On Thu Oct 18 2001; 13:59, Werner Koch wrote: > Are there any grave bugs in the CVS versions? I'm not sure if this is only my problem. But with the new --refresh-key command it happens from time to time that one key exists twice in the keyring. Timo -- "Das wahre Vaterland ist das Land, wo man die meisten Menschen trifft, die einem gleichen." -- Henri Stendhal From wk@gnupg.org Thu Oct 18 20:30:02 2001 From: wk@gnupg.org (Werner Koch) Date: Thu Oct 18 19:30:02 2001 Subject: Should I release a new snapshot? In-Reply-To: <20011018155031.E412@daredevil.joesixpack.net> (Timo Schulz's message of "Thu, 18 Oct 2001 15:50:31 +0200") References: <87adypupjb.fsf@alberti.gnupg.de> <20011018155031.E412@daredevil.joesixpack.net> Message-ID: <87u1wwsvqp.fsf@alberti.gnupg.de> On Thu, 18 Oct 2001 15:50:31 +0200, Timo Schulz said: > I'm not sure if this is only my problem. But with the > new --refresh-key command it happens from time to time > that one key exists twice in the keyring. Yeah, if a snapshot helps to track this bug down, I should do it. There are also a few other problems mainly for Windows and RISC OS but those are not the primary target. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From jpg@rcom.com.ar Fri Oct 19 21:20:01 2001 From: jpg@rcom.com.ar (Juan Pablo =?ISO-8859-1?Q?Gim=E9nez?=) Date: Fri Oct 19 20:20:01 2001 Subject: with-colons bug Message-ID: <1003515471.19982.26.camel@kang.oficina.rcom.com.ar> --=-bKhvA6y9GzcgLNBsvy1d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi! I already send this mail with other subject, but nobody answer because it = was too simple... I have a problem with the option "--with-colons" and --list-keys or --fingerprint, if i don't use it, gpg print my last name "Gim=E9nez" with the "=E9", but if I put with-colons insted of "=E9" gpg prints "=C3=A9"... = So here is the patch to fix it... ________________________________________________________________________ --- gnupg-1.0.6/g10/keylist.c Sun May 27 11:31:07 2001 +++ gnupg-1.0.6_rcom/g10/keylist.c Fri Oct 12 11:42:15 2001 @@ -482,8 +482,8 @@ printf("uid:%c::::::::", trustletter); } } - print_string( stdout, node->pkt->pkt.user_id->name, - node->pkt->pkt.user_id->len, ':' ); + print_utf8_string( stdout, node->pkt->pkt.user_id->name, + node->pkt->pkt.user_id->len); putchar(':'); if (any) putchar('\n'); ________________________________________________________________________ Chausesssssssssss Juan Pablo.... --=-bKhvA6y9GzcgLNBsvy1d Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA70G5PChXsK9PY/SsRAt+EAJ9/2GlaUB9PLLyxLdskRhlgdKohzACeIM3L QGqTot3XLmgbtuUowz3Hi+M= =A8v6 -----END PGP SIGNATURE----- --=-bKhvA6y9GzcgLNBsvy1d-- From fw@deneb.enyo.de Sat Oct 20 00:38:01 2001 From: fw@deneb.enyo.de (Florian Weimer) Date: Fri Oct 19 23:38:01 2001 Subject: with-colons bug In-Reply-To: <1003515471.19982.26.camel@kang.oficina.rcom.com.ar> (Juan Pablo =?iso-8859-1?q?Gim=E9nez's?= message of "19 Oct 2001 15:17:51 -0300") References: <1003515471.19982.26.camel@kang.oficina.rcom.com.ar> Message-ID: <87d73j5oli.fsf@deneb.enyo.de> Juan Pablo Gim=E9nez writes: > I have a problem with the option "--with-colons" and --list-keys or > --fingerprint, if i don't use it, gpg print my last name "Gim=E9nez" with > the "=E9", but if I put with-colons insted of "=E9" gpg prints "=C3=A9"..= . So > here is the patch to fix it... I think this behavior is mostly correct. In "--with-colons" mode, GnuPG is expected to dump the user ID as is, without further processing. From jpg@rcom.com.ar Sat Oct 20 01:33:01 2001 From: jpg@rcom.com.ar (Juan Pablo =?ISO-8859-1?Q?Gim=E9nez?=) Date: Sat Oct 20 00:33:01 2001 Subject: with-colons bug In-Reply-To: <87d73j5oli.fsf@deneb.enyo.de> References: <1003515471.19982.26.camel@kang.oficina.rcom.com.ar> <87d73j5oli.fsf@deneb.enyo.de> Message-ID: <1003530662.4450.21.camel@kang.oficina.rcom.com.ar> --=-hWbCwDyvomJTh1VF5wK1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable En vie, 2001-10-19 a 18:03, Florian Weimer escribi=F3: Juan Pablo Gim=E9nez writes: =20 > I have a problem with the option "--with-colons" and --list-keys or > --fingerprint, if i don't use it, gpg print my last name "Gim=E9nez" = with > the "=E9", but if I put with-colons insted of "=E9" gpg prints "=C3= =A9"... So > here is the patch to fix it... =20 I think this behavior is mostly correct. In "--with-colons" mode, GnuPG is expected to dump the user ID as is, without further processing. Ok, but thats break some programs, for example Gabber (Gnome Jabber client), who print the strings as is so it print it wrong... So, what do you think, the problem is gnupg or for example Gabber?!?! =20 --=-hWbCwDyvomJTh1VF5wK1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA70KmmChXsK9PY/SsRAlmrAKCNCj2pMM4cTrjmS83Co3vINSwpzQCfQqX0 G42CD1zWZlng0+Hcoz87MdY= =IWZ3 -----END PGP SIGNATURE----- --=-hWbCwDyvomJTh1VF5wK1-- From wk@gnupg.org Sat Oct 20 13:56:01 2001 From: wk@gnupg.org (Werner Koch) Date: Sat Oct 20 12:56:01 2001 Subject: with-colons bug In-Reply-To: <1003530662.4450.21.camel@kang.oficina.rcom.com.ar> (Juan Pablo =?iso-8859-1?q?Gim=E9nez's?= message of "19 Oct 2001 19:31:02 -0300") References: <1003515471.19982.26.camel@kang.oficina.rcom.com.ar> <87d73j5oli.fsf@deneb.enyo.de> <1003530662.4450.21.camel@kang.oficina.rcom.com.ar> Message-ID: <873d4eoa2v.fsf@alberti.gnupg.de> On 19 Oct 2001 19:31:02 -0300, Juan Pablo Giménez said: > Ok, but thats break some programs, for example Gabber (Gnome Jabber > client), who print the strings as is so it print it wrong... So, what do > you think, the problem is gnupg or for example Gabber?!?! Gabber does not do a conversion from utf-8 to the used character set. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From mwy-gpg41@the-youngs.org Mon Oct 22 18:39:01 2001 From: mwy-gpg41@the-youngs.org (Michael Young) Date: Mon Oct 22 17:39:01 2001 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) References: Message-ID: <009501c15b0f$4977a760$b399183f@transarc.ibm.com> -----BEGIN PGP SIGNED MESSAGE----- > From: David Shaw > Incidentally, I did confirm that PGP (at least version 6.5.8 and > later) does understand all 4 signature types, even though it can't > generate them. I also did some confirmation. PGP2.6 should accept them. The keyservers I tested had no problem with them. Note that GnuPG had already been using class 3 for self-signatures. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQEVAwUBO9Q8omNDnIII+QUHAQHBkAgAif8tXnmcxiMMVBE4dwSDcweQxayqD1DK u9pEvD75W6dxbgdl9rlB2dd70sXVI9VhTZWo6mo/heR0Kda6gwxvRLzN0sUiP7u+ 6g9tx8wGx5POAxxJVBclL7O/kTZffjztdIm3iZKLLXh3VJ1UEVdTfIe30A/F69+X fMLAItAOe7qcPvteL40wBXZcPvK2ioE4Qtt8hc2Db7iDZLn0f+eFO6Myv2sdfHc4 KAqxb7StOpjyPJ1LELsRQ9czAU0r+O7eu05OUk1AZFyJCgzTxPBTloBVnoDs2Rmp dL9XXsHNYZM3ROTwJWfjuaflmM+4in2qe1ABh+7088EczdDS9wxqbQ== =AyYk -----END PGP SIGNATURE----- From dshaw@jabberwocky.com Mon Oct 22 22:23:01 2001 From: dshaw@jabberwocky.com (David Shaw) Date: Mon Oct 22 21:23:01 2001 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <009501c15b0f$4977a760$b399183f@transarc.ibm.com>; from mwy-gpg41@the-youngs.org on Mon, Oct 22, 2001 at 11:35:52AM -0400 References: <009501c15b0f$4977a760$b399183f@transarc.ibm.com> Message-ID: <20011022152058.A666@akamai.com> --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 22, 2001 at 11:35:52AM -0400, Michael Young wrote: > > From: David Shaw > > Incidentally, I did confirm that PGP (at least version 6.5.8 and > > later) does understand all 4 signature types, even though it can't > > generate them. >=20 > I also did some confirmation. PGP2.6 should accept them. > The keyservers I tested had no problem with them. Excellent. Thanks for checking. > Note that GnuPG had already been using class 3 for self-signatures. Yes, I noticed that. That in itself gives me more confidence there won't be problems with multiple sig classes. If there was a PGP version out there that didn't accept multiple sig classes, it would have broken with GnuPG-generated keys and we'd have heard about it by now. David --=20 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 --Kj7319i9nmIyA2yE 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 iQEVAwUBO9Rxmoccwqs8s7QVAQGJlAgAmdhTFgRXIGRh4yjeNBpFIXGT/F5t45ug Q0EfYEOKc6j+2ccCY2B0mdwuQjgr3ZPAJXl/pH0lFsC2s5TXNnkuStFT01VpMu98 JYiK20fTLuGPSBN2+e7VGSWCk0GtAiMXMb/QhqbYb5h37RP6CnDLeDHTgCpjH8br VVSXK7eroaHRJunccJ4G1WSMQ0zYBTnCrxuY/uk3pies4xs+w/eD1r5czLeMtty1 YPnZgJR+B1hgrecI75Z9IBWCBO38TrgzbGsnKy5vSUdHCmvNzhf/Dm845+E4TvE6 GbRSIq4p0D8QYlUWlQM87LjoQtiw9i2MMSS7vBuK5zhlIWG5V6x88w== =pK1e -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE-- From wk@gnupg.org Tue Oct 23 10:46:01 2001 From: wk@gnupg.org (Werner Koch) Date: Tue Oct 23 09:46:01 2001 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <20011022152058.A666@akamai.com> (David Shaw's message of "Mon, 22 Oct 2001 15:20:58 -0400") References: <009501c15b0f$4977a760$b399183f@transarc.ibm.com> <20011022152058.A666@akamai.com> Message-ID: <87y9m2vlzu.fsf@alberti.gnupg.de> On Mon, 22 Oct 2001 15:20:58 -0400, David Shaw said: > Yes, I noticed that. That in itself gives me more confidence there > won't be problems with multiple sig classes. If there was a PGP I use 0x13 for self-signatures and 0x10 for standard signatures, mainly because this may be helpful in debugging. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From wk@gnupg.org Tue Oct 23 22:28:07 2001 From: wk@gnupg.org (Werner Koch) Date: Tue Oct 23 21:28:07 2001 Subject: [Announce] A new GnuPG snapshot (unstable) Message-ID: <877ktmtgkl.fsf@alberti.gnupg.de> Hi, after messing around with autoconf 1.5 for quite some time, I finally was able to release a new DEVELOPMENT snapshot of GnuPG: *PLEASE READ THIS ENTIRE ANNOUNCEMENT BEFORE YOU START TO PLAY* ftp://ftp.gnupg.org/gcrypt/devel/gnupg-1.0.6b.tar.gz (1.9M) ftp://ftp.gnupg.org/gcrypt/devel/gnupg-1.0.6b.tar.gz.sig Please find a list of mirrors at http://www.gnupg.org/mirrors.html Again I changed quite a lot of things. Using this version with a current keyring renders the keyring unreadable for any previous GnuPG versions. So I did WARN YOU ABOUT THESE INCOMPATIBLE CHANGES - please don't complain that it destroyed all your keys. Actually this incompatibility is due to a bug in the older versions which are not able to cope with trust packet larger than one byte. You can use --export as an escape hatch because trust packets are never exported. There are 2 major changes in this release: * The caching of the signature verification status changed from using special signature subpackets to the use of the trust packets. You can (and should) rebuild this key cache using the new command "gpg --rebuild-keydb-caches" * The format of the TrustDB and the way it works has entirely be rewritten. gpg tries to migrate to the new format but this code is obviously not very well tested, so you might want to make a backup of our ownertrust values first. The validity of the key is now checked every time you insert a new key or signature and when a key or a signature expires. This automatic check can be disabled and replaced by a cron job which does an "gpg --check-trustdb" every night or so. To assign an ownertrust, you can either do this in the edit menu or use the command "gpg --update-trustdb" which does the maintenance pass in a similar manner you probably know from PGP 2. Both changes should speed up the operation on large keyrings quite a lot so that "gpg --list-keys --with-colons" is actually usable. Also a couple of bug fixes and some other code cleanups are in this release. There is still a long list of open bugs but I think it is important to get the new code tested first. The Windows and Acorn ports won't work yet due to file sharing issues. Changes since 1.0.6a: * The way signature stati are store has changed, so that v3 signatures can be supported. To increase the speed of many operations for existing keys you can use the new --rebuild-keydb-caches command. * The entire key validation process (trustdb) has been revamped. See the man page entries for --update-trustdb, --check-trustdb and --no-auto-check-trustdb. * --trusted-keys is again obsolete, --edit can be used to set the ownertrust of any key to ultimately trusted. * A subkey is never used to sign keys. * Read only keyrings are now handled as expected. Changes since 1.0.6: * New tool gpgsplit to split OpenPGP data formats into packets. * New option --preserve-permissions. * Subkeys created in the future are not used for encryption or signing unless the new option --ignore-valid-from is used. * Revoked user-IDs are not listed unless signatures are listed too or we are in verbose mode. * There is no default comment string with ascii armors anymore except for revocation certificates and --enarmor mode. * The command "primary" in the edit menu can be used to change the primary UID, "setpref" and "updpref" can be used to change the preferences. * Fixed the preference handling; since 1.0.5 they were erroneously matched against against the latest user ID and not the given one. * RSA key generation. * Merged Stefan's patches for RISC OS in. See comments in scripts/build-riscos. * It is now possible to sign and conventional encrypt a message (-cs). * The MDC feature flag is supported and can be set by using the "updpref" edit command. * The status messages GOODSIG and BADSIG are now returning the primary UID, encoded using %XX escaping (but with spaces left as spaces, so that it should not break too much) * Support for GDBM based keyrings has been removed. * The entire keyring management has been revamped. * The way signature stati are store has changed, so that v3 signatures can be supported. To increase the speed of many operations for existing keys you can use the new --rebuild-keydb-caches command. * The entire key validation process (trustdb) has been revamped. See the man page entries for --update-trustdb, --check-trustdb and --no-auto-check-trustdb. * --trusted-keys is again obsolete, --edit can be used to set the ownertrust of any key to ultimately trusted. * A subkey is never used to sign keys. Take care, Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From dshaw@jabberwocky.com Wed Oct 24 23:12:01 2001 From: dshaw@jabberwocky.com (David Shaw) Date: Wed Oct 24 22:12:01 2001 Subject: 1.0.6b comments Message-ID: <20011024161016.A2155@akamai.com> --1sNVjLsmu1MXqwQ/ Content-Type: multipart/mixed; boundary="2JFBq9zoW8cOFH7v" Content-Disposition: inline --2JFBq9zoW8cOFH7v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hiya, I've been playing with 1.0.6b, and have a few comments. Some of these are not necessarily bugs, and some of them exist in 1.0.6 as well. Aside from this, 1.0.6b is really great. I love --update-trustdb. 1) Merely having the secret key present is not enough to make a key ultimately trusted. You have to do it by hand in --edit. If a new key is generated, however, it is ultimately trusted. 2) The --edit menu does not detect if you have v3 secret keys (i.e. you can't "toggle"). V4 secret keys do work. 3) If you try to make a 4096-bit RSA key, gpg seems to make a 4095-bit key. 4) Sign a key, so that it's trust goes to "full". Now, delete or revoke the signature. The trust level stays at "full" until you export, delete, and then re-import the trustdb. 5) When you delete a key with ownertrust set it does not disappear from the trustdb. 6) You can revoke the same key signature multiple times (unclear whether this is really a problem or not). 7) When revoking a key signature, the reason for revocation prompt doesn't allow for the "no reason specified" option allowed in the RFC. A patch for that is attached. 8) RSA key signatures are always made with MD5 as the hash. This makes sense for v3 key sigs, but v4 RSA key sigs are probably safe to use something else. 9) Revoking a key or signature prompts for a revocation reason. This doesn't work properly with v3 keys in that it prompts, accepts the user's input, but does not actually include the reason in the revocation signature. This is the same problem that 1.0.6 had with making non-exportable sigs with v3 keys (i.e. v3 keys make v3 sigs, so no v4 features). Note the same thing happens with set-policy-url or notation-data with v3 keys. As I see it, if you are making a signature on a v4 key using your v3 key, it doesn't make sense to generate a v3 sig. After all, the point of using a v3 sig is to be backwards compatible, but no v3-only PGP implementation could understand the v4 key the sig is on in the first place. I've added a feature (patch attached) to always make v4 key sigs unless it is a v3 key making a key sig on a v3 key, in which case it makes a v3 key sig. I also added a "force-v4-certs" flag to force v4 key sigs (certs) if the user wants v4 key signatures all the time. This only affects key certification signatures. Regular document signatures are unchanged. This doesn't really solve the stated issue that gpg prompts the user even if it is not going to use the revocation reason but it does help the underlying problem. 10) Key flags don't seem to work properly in that if a key is flagged certify-only (0x01), or signature-only (0x02), it still can do the other (certify-only keys can sign, and signature-only keys can certify). David --=20 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 --2JFBq9zoW8cOFH7v Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch.gnupg-1.0.6b.dms.revokereason.1" Content-Transfer-Encoding: quoted-printable Index: revoke.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/gnupg/gnupg/g10/revoke.c,v retrieving revision 1.20.2.9 diff -u -r1.20.2.9 revoke.c --- revoke.c 2001/09/07 07:57:51 1.20.2.9 +++ revoke.c 2001/10/24 19:13:11 @@ -240,9 +240,10 @@ struct revocation_reason_info * ask_revocation_reason( int key_rev, int cert_rev, int hint ) { - int code; + int code=3D-1; char *description =3D NULL; struct revocation_reason_info *reason; + const char *text_0 =3D _("No reason specified"); const char *text_1 =3D _("Key has been compromised"); const char *text_2 =3D _("Key is superseded"); const char *text_3 =3D _("Key is no longer used"); @@ -254,6 +255,7 @@ description =3D NULL; =20 tty_printf(_("Please select the reason for the revocation:\n")); + tty_printf( " 0 =3D %s\n", text_0 ); if( key_rev ) tty_printf(" 1 =3D %s\n", text_1 ); if( key_rev ) @@ -262,29 +264,31 @@ tty_printf(" 3 =3D %s\n", text_3 ); if( cert_rev ) tty_printf(" 4 =3D %s\n", text_4 ); - tty_printf( " 0 =3D %s\n", _("Cancel") ); + tty_printf( " Q =3D %s\n", _("Cancel") ); if( hint ) tty_printf(_("(Probably you want to select %d here)\n"), hint ); =20 - for(code =3D 0; !code;) { + while(code=3D=3D-1) { int n; char *answer =3D cpr_get("ask_revocation_reason.code", _("Your decision? ")); trim_spaces( answer ); cpr_kill_prompt(); - if( *answer =3D=3D 'q' || *answer =3D=3D 'Q' ) - n =3D 0; - else if( !isdigit( *answer ) ) - n =3D -1; - else if( hint && !*answer ) + if( *answer =3D=3D 'q' || *answer =3D=3D 'Q') + return NULL; /* cancel */ + if( hint && !*answer ) n =3D hint; + else if(!isdigit( *answer ) ) + n =3D -1; else n =3D atoi(answer); m_free(answer); - if( !n ) - return NULL; /* cancel */ + if( n =3D=3D 0 ) { + code =3D 0x00; /* no particular reason */ + code_text =3D text_0; + } else if( key_rev && n =3D=3D 1 ) { - code =3D 0x02; /* key has been compromised */ + code =3D 0x02; /* key has been compromised */ code_text =3D text_1; } else if( key_rev && n =3D=3D 2 ) { --2JFBq9zoW8cOFH7v Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch.gnupg-1.0.6b.dms.sigversion.1" Content-Transfer-Encoding: quoted-printable ? Makefile.in ? Makefile ? .deps ? gpg ? gpgv Index: g10.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/gnupg/gnupg/g10/Attic/g10.c,v retrieving revision 1.129.2.57 diff -u -r1.129.2.57 g10.c --- g10.c 2001/10/06 07:31:28 1.129.2.57 +++ g10.c 2001/10/24 19:36:04 @@ -180,6 +180,8 @@ oThrowKeyid, oForceV3Sigs, oNoForceV3Sigs, + oForceV4Certs, + oNoForceV4Certs, oForceMDC, oS2KMode, oS2KDigest, @@ -311,6 +313,8 @@ { oNoTTY, "no-tty", 0, N_("don't use the terminal at all") }, { oForceV3Sigs, "force-v3-sigs", 0, N_("force v3 signatures") }, { oNoForceV3Sigs, "no-force-v3-sigs", 0, N_("do not force v3 signature= s") }, + { oForceV4Certs, "force-v4-certs", 0, N_("force v4 key signatures") }, + { oNoForceV4Certs, "no-force-v4-certs", 0, N_("do not force v4 key sig= natures") }, { oForceMDC, "force-mdc", 0, N_("always use a MDC for encryption") }, { oDryRun, "dry-run", 0, N_("do not make any changes") }, /*{ oInteractive, "interactive", 0, N_("prompt before overwriting") }, */ @@ -956,6 +960,7 @@ case oRFC1991: opt.rfc1991 =3D 1; opt.rfc2440 =3D 0; + opt.force_v4_certs =3D 0; opt.no_comment =3D 1; opt.escape_from =3D 1; break; @@ -998,6 +1003,8 @@ case oThrowKeyid: opt.throw_keyid =3D 1; break; case oForceV3Sigs: opt.force_v3_sigs =3D 1; break; case oNoForceV3Sigs: opt.force_v3_sigs =3D 0; break; + case oForceV4Certs: opt.force_v4_certs =3D 1; break; + case oNoForceV4Certs: opt.force_v4_certs =3D 0; break; case oForceMDC: opt.force_mdc =3D 1; break; case oS2KMode: opt.s2k_mode =3D pargs.r.ret_int; break; case oS2KDigest: s2k_digest_string =3D m_strdup(pargs.r.ret_str); break; Index: options.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/gnupg/gnupg/g10/options.h,v retrieving revision 1.51.2.30 diff -u -r1.51.2.30 options.h --- options.h 2001/09/25 15:20:59 1.51.2.30 +++ options.h 2001/10/24 19:36:04 @@ -57,6 +57,7 @@ int list_packets; /* list-packets mode: 1=3Dnormal, 2=3Dinvoked by com= mand*/ int def_cipher_algo; int force_v3_sigs; + int force_v4_certs; int force_mdc; int def_digest_algo; int def_compress_algo; Index: sign.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/gnupg/gnupg/g10/sign.c,v retrieving revision 1.75.2.23 diff -u -r1.75.2.23 sign.c --- sign.c 2001/09/09 16:09:19 1.75.2.23 +++ sign.c 2001/10/24 19:36:04 @@ -982,8 +982,18 @@ || sigclass =3D=3D 0x20 || sigclass =3D=3D 0x18 || sigclass =3D=3D 0x30 || sigclass =3D=3D 0x28 ); =20 + if (opt.force_v4_certs) + sigversion =3D 4; + if (sigversion < sk->version) sigversion =3D sk->version; + + /* If you are making a signature on a v4 key using your v3 key, it + doesn't make sense to generate a v3 sig. After all, no v3-only + PGP implementation could understand the v4 key in the first + place. */ + if (sigversion < pk->version) + sigversion =3D pk->version; =20 if( !digest_algo ) { switch( sk->pubkey_algo ) { --2JFBq9zoW8cOFH7v-- --1sNVjLsmu1MXqwQ/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6b (GNU/Linux) iQEVAwUBO9cgKIccwqs8s7QVAQHJhwf8C806sdn+1ZvXbweOu92OyH4bgXMjurkn UUAHKx45eMa/oq/0Sn11wwucntr4CHQhGlc7b1IJ6/aVPp3tvtaWQ2OfAMRSCGgW i/rLAPeoQVdd1ULuI5ZPtyXKAqCSR8bB+HzpWHduobGXeCE/N7vNgMPa+VpelEnI ToPdgsR2CRCIsAEaflEiSar6C8LFWSL1QXqFD/VDPxHGlG+rOHP2lR21OO0/l1Ue 0Yk7fm+aUeIK8f22KAeE3+x6sPsDmGXDKptndZLf3mgAXWdWI4/3TNpcmIJ7WYxN Lf/TUW3dJimuBg9IhPZLL+qC6tp4RJJcYa1BKysNWmBC9N7JMpOp8A== =Vx5N -----END PGP SIGNATURE----- --1sNVjLsmu1MXqwQ/-- From rabbi@quickie.net Wed Oct 24 23:27:02 2001 From: rabbi@quickie.net (Len Sassaman) Date: Wed Oct 24 22:27:02 2001 Subject: 1.0.6b comments In-Reply-To: <20011024161016.A2155@akamai.com> Message-ID: On Wed, 24 Oct 2001, David Shaw wrote: > Hiya, > > I've been playing with 1.0.6b, and have a few comments. Some of these > are not necessarily bugs, and some of them exist in 1.0.6 as well. > > Aside from this, 1.0.6b is really great. I love --update-trustdb. > > 1) Merely having the secret key present is not enough to make a key > ultimately trusted. You have to do it by hand in --edit. If a new > key is generated, however, it is ultimately trusted. That is correct behavior. (There's a possible attack on systems that automatically import keys received in email that doing it this way protects against. I can describe it in more detail if you like.) > 8) RSA key signatures are always made with MD5 as the hash. This > makes sense for v3 key sigs, but v4 RSA key sigs are probably safe > to use something else. Yes. In PGP 7.0, we used SHA-1. No reason to stick with MD5. Also, RSA v4 keys bind their subkeys to the primary key using SHA-1 in PGP 7.x as well. > As I see it, if you are making a signature on a v4 key using your > v3 key, it doesn't make sense to generate a v3 sig. After all, the > point of using a v3 sig is to be backwards compatible, but no > v3-only PGP implementation could understand the v4 key the sig is > on in the first place. PGP versions prior to 5.x could not do v4 at all. PGP 5.x and 6.x understood v4 sigs on keys, but not on non-key material. (There's a nit about this in the RFC for 5.x; it should say 6.x as well.) (Just reiterating what you are saying here -- if an implementation can handle a v4 key, it can handle v4 sigs on a v4 key, even if it can't handle v4 sigs on other files. -- Len Sassaman Security Architect | "Now it's all change -- Technology Consultant | It's got to change more." | http://sion.quickie.net | --Joe Jackson From JanuszA.Urbanowicz Thu Oct 25 01:40:01 2001 From: JanuszA.Urbanowicz (JanuszA.Urbanowicz) Date: Thu Oct 25 00:40:01 2001 Subject: 1.0.6b comments (fwd) Message-ID: --ELM711998029-25058-0_ Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit -- Janusz A. Urbanowicz | ALEX3-RIPE | SF-Framling | Thawte Web Of Trust Notary Gdy dajê biednym chleb, nazywaj± mnie ¶wiêtym. Gdy pytam, dlaczego biedni nie maj± chleba, nazywaj± mnie komunist±. - abp. Helder Camara --ELM711998029-25058-0_ Content-Type: message/rfc822 Content-Disposition: inline Content-Description: Forwarded message from Janusz A . Urbanowicz Content-Transfer-Encoding: 8bit Subject: Re: 1.0.6b comments In-Reply-To: <20011024161016.A2155@akamai.com> from David Shaw at "Oct 24, 2001 04:10:16 pm" To: David Shaw Date: Thu, 25 Oct 2001 00:14:05 +0200 (CEST) From: Janusz A. Urbanowicz X-Latin-Date: Hodie VIII Kal. Nov. MMDCCLIV AUC est X-Mayan-Date: 12.19.08.12.03 X-Erisian-Date: Pungenday, The Aftermath 6, 3167 YOLD X-Operating-System: Linux sword 2.2.16 i586 X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit Content-Length: 1884 David Shaw wrote/napisa³[a]/schrieb: -- Start of PGP signed section. > Hiya, > > I've been playing with 1.0.6b, and have a few comments. Some of these > are not necessarily bugs, and some of them exist in 1.0.6 as well. > > Aside from this, 1.0.6b is really great. I love --update-trustdb. Aside that trust checking during signature verification in 1.0.6b is waay slower thanit was in 1.0.6a. And this is after setting ultimate trust on keys and rerunning update-trustdb a few times. Daaing my remark: 11) I have a (local signature) on a key using signing subkey of my key (since this is lsig it is not very important). This sig is not taken into account when calculating trust: :alex@sword:[~]:223:> gpg --edit-key RSA gpg (GnuPG) 1.0.6b; 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. gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! pub 1024R/DE46F54F created: 1999-09-16 expires: never trust: f/- ~~~ (1). Personal Freemail RSA 1999.9.16 Command> check uid Personal Freemail RSA 1999.9.16 sig! DE46F54F 1999-09-16 [self-signature] sig! 7E2E803D 2001-10-17 Janusz A. Urbanowicz (notebook) ; from alex@bofh.torun.pl on Thu, Oct 25, 2001 at 12:49:33AM +0200 References: Message-ID: <20011024190939.A13100@akamai.com> --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 25, 2001 at 12:49:33AM +0200, Janusz A. Urbanowicz wrote: > 11) I have a (local signature) on a key using signing subkey of my key > (since this is lsig it is not very important). This sig is not taken into > account when calculating trust: I can confirm this. It seems to apply to any key signature (local or not local) made by a signing subkey. 1.0.6b won't let signing subkeys make key signatures any longer, but there are some sigs there from older versions. David --=20 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 --pWyiEgJYm5f9v55/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6b (GNU/Linux) iQEVAwUBO9dKM4ccwqs8s7QVAQE++ggAohTk952P3iAfv9jRTWb8qHUW7F7T+7cY VCPH9D2OLIXTZOhlnhnHEcA4tCHAYEA3IMzxChTdTE4ocbX86FKomMpoDREW6Pz0 9qr0zqLXVNv+3ZOPYOnY9iB8x3IjIopF2cNhQEJeqBDRuZ0Dx2wmXq4v4jyKM+iw O5mIkdBvcsfDNbMROeOemDHSqc4UEPaEyaO5KE8KAtDwkyOga0kIwzLlNiJwSHLH Xph8HFhryN30ktEDuUhrfCAFteZW0VZTW0rG7Bzei8lBGN1+MH+9DPEBWVyEM9et BEisFDlW4GYsx2kK9z6ngLrKSgCKD0BldexjRc12O+oBrujMDVMm4w== =xz+f -----END PGP SIGNATURE----- --pWyiEgJYm5f9v55/-- From JanuszA.Urbanowicz Thu Oct 25 11:53:01 2001 From: JanuszA.Urbanowicz (JanuszA.Urbanowicz) Date: Thu Oct 25 10:53:01 2001 Subject: 1.0.6b comments In-Reply-To: <20011024161016.A2155@akamai.com> from David Shaw at "Oct 24, 2001 04:10:16 pm" Message-ID: David Shaw wrote/napisa³[a]/schrieb: -- Start of PGP signed section. > Hiya, > > I've been playing with 1.0.6b, and have a few comments. Some of these > are not necessarily bugs, and some of them exist in 1.0.6 as well. > > Aside from this, 1.0.6b is really great. I love --update-trustdb. Aside that trust checking during signature verification in 1.0.6b is waay slower thanit was in 1.0.6a. And this is after setting ultimate trust on keys and rerunning update-trustdb a few times. Daaing my remark: 11) I have a (local signature) on a key using signing subkey of my key (since this is lsig it is not very important). This sig is not taken into account when calculating trust: :alex@sword:[~]:223:> gpg --edit-key RSA gpg (GnuPG) 1.0.6b; 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. gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! pub 1024R/DE46F54F created: 1999-09-16 expires: never trust: f/- ~~~ (1). Personal Freemail RSA 1999.9.16 Command> check uid Personal Freemail RSA 1999.9.16 sig! DE46F54F 1999-09-16 [self-signature] sig! 7E2E803D 2001-10-17 Janusz A. Urbanowicz (notebook) Geachte heer/mevrouw Nog 1 dag en dan is het zover: de releasedatum van WINDOWS XP !! Windows XP, het allernieuwste besturingssysteem van Microsoft, kunt u nu bij ons bestellen !! U bestelt via deze e-mail Windows XP? Profiteer dan tevens van een fikse korting op KILOMETERDECLARATIE 2001 ! U kunt Kilometerdeclaratie 2001 aanschaffen van: fl. 99,- (44,92 Euro) voor: fl. 69,- (31,31 Euro) Onderaan deze e-mailing vindt u onze speciale aanbiedingen met kortingen die oplopen tot bijna 40%. Voor een totaaloverzicht van ons assortiment: www.teledirekt.nl Wilt u extra productinformatie of een goed advies? Bel GRATIS de Teledirekt Verkoopadvieslijn: 0800-237 66 44 Als u direct wilt bestellen: http://63.105.9.58/em/em47pt.htm ============================================================== # WINDOWS XP BRENGT UW PC NAAR ONGEKENDE HOOGTE - DE NIEUWE STANDAARD VOOR EFFICIËNT EN BETROUWBAAR COMPUTERGEBRUIK - Windows XP heeft een totaal nieuwe look en is ook inhoudelijk aanzienlijk veranderd. Het besturingssysteem haakt direct in op de vooruitgang van internet en de digitale media. Microsoft introduceert een aantal edities van Windows XP die zijn afgestemd op uw computerbehoeften zowel thuis als op kantoor. * WINDOWS XP HOME EDITION * De Windows XP Home Edition is het nieuwe besturingssysteem voor de PC thuis en biedt u alles wat u nodig hebt om eenvoudig computers en een thuisnetwerk te delen. Met de digitale fotofuncties kunt u foto's ophalen, organiseren en delen met de alles-in-één muziekfunctie kunt u kwalitatief hoogstaande muziek ontdekken, downloaden, opslaan en afspelen. - Één plaats voor het afspelen van DVD's, ordenen van muziek, branden van CD's, etc. - Films opnemen, bewerken, ordenen en delen op uw computer. - Afbeeldingen ordenen en bekijken of afdrukken van uw foto's bestellen via een webservice. - Eenvoudiger dan ooit om uw eigen thuisnetwerk te installeren. Prijs: fl. 615,- (279,07 Euro) Win 98/2000/ME Art.nr: 303070 Bestellen: http://63.105.9.58/em/em47pt.htm * WINDOWS XP HOME EDITION UPGRADE Prijs: fl. 285,- (129,33 Euro) Win 98/2000/ME Art.nr: 303071 Bestellen: http://63.105.9.58/em/em47pt.htm * WINDOWS XP PROFESSIONAL EDITION Biedt alle voordelen van Windows XP plus o.a. een hogere veiligheid en eersteklas mobiele ondersteuning om off-line te kunnen werken of om op afstand toegang te krijgen tot uw computer. Prijs: fl. 924,- (419,29 Euro) Win 98/2000/ME Art.nr: 303068 Bestellen: http://63.105.9.58/em/em47pt.htm * WINDOWS XP PROFESSIONAL EDITION UPGRADE Prijs: fl. 571,- (259,11 Euro) Win 98/2000/ME Art.nr: 303069 Bestellen: http://63.105.9.58/em/em47pt.htm U bestelt Windows XP via deze e-mailing?? Dan kunt u Kilometerdeclaratie 2001 aanschaffen van: fl. 99,- (44,92 Euro) voor: fl. 69,- (31,31 Euro) Dit kunt u aangeven op het bestelformulier: http://63.105.9.58/em/em47pt.htm ============================================================== # CD'S WISSELEN IS NIET MEER NODIG Kopieer uw favoriete CD-Rom's naar uw harde schijf. CD's tot 20 x sneller toegankelijk. Prijs: fl. 129,- (58,54 Euro) Win 95/98/NT/2000 Art.nr: 303042 Bestellen: http://63.105.9.58/em/em47pt.htm ============================================================== # CD-FOONGIDS 2001 + ADRESBESTAND COMPACT Meer dan 7.000.000 adressen met telefoon-, fax- en mobiele nummers. Prijs: fl. 69,- (31,31 Euro) Win 95/98/NT/2000/ME Art.nr: 302779 Bestellen: http://63.105.9.58/em/em47pt.htm ============================================================== # CURSUS INTERNET, WINDOWS 98, WORD, EXCEL EN POWERPOINT Bundelprijs: fl. 79,- (35,85 Euro) Win 95/98 Art.nr: 302918 Bestellen: http://63.105.9.58/em/em47pt.htm ============================================================== # ONTWERP ZELF UW EIGEN INTERNETSITE Prijs: fl. 85,- (38,57 Euro) Win 95/98/NT/2000/ME Art.nr: 303034 Bestellen: http://63.105.9.58/em/em47pt.htm ============================================================== ** Teledirekt aanraders ** 1. Nedsoft EuroOffice pro, fl. 149,- (67,61 Euro) Microsoft Office-documenten omzetten in de Euro (art.nr: 303009) 2. CardIris, fl. 699,- (317,19 Euro) Met één klik al uw visitekaartjes in uw PC (art.nr: 302759) 3. Easy Travel Plus, fl. 79,- (35,85 Euro) Alle straten van de Benelux op één CD-Rom (art.nr: 301590) 4. 333.000 Professionele afbeeldingen, fl. 169,- (76,69 Euro) Cliparts, bitmapafbeeldingen, internetanimaties, foto's, afbeeldingen (art.nr: 301025) 5. NL-Sat, fl. 42,50 (19,29 Euro) Satellietatlas van Nederland (art.nr: 301445) Bestellen: http://63.105.9.58/em/em47pt.htm ============================================================== ** Aanbiedingen OP = OP ** # VISUAL VOORRAAD, voor een eenvoudig en overzichtelijk voorraadbeheer. Dit pakket biedt u onder andere het volgende: - Voorraden beheren. - Klant-/leveranciersafspraken bijhouden. - Automatisch bestellingen genereren. - Deelleveringen bij goederen ontvangen. - Historie van bestel- en verkoopgegevens vastleggen en opvragen. - Beheer van meerdere magazijnen (van eenvoudig tot zeer geavanceerd). - Uitgebreide opvraag van omzetgegevens per periode, artikel/artikelgroep of klant. - Ondersteuning vreemde valuta en talen. van: fl. 995,- voor: fl. 695,- (30% korting) van: 451,51 Euro voor: 315,38 Euro Art.nr: 301038 Bestellen: http://63.105.9.58/em/em47pt.htm ============================================================== # RECRUITMENT ASSISTENT, sollicitaties snel en efficiënt afhandelen. Recruitment Assistent helpt u bij het vinden van de beste kandidaat voor een vacature. Het systeem bespaart u tijd bij het maken van brieven, houdt de administratie van uw correspondentie bij en assisteert u bij de verwerking van de gegevens. Zodat u zich kunt concentreren op de mensen zelf.... van: fl. 799,- voor: fl. 499,- (38% korting) van: 362,57 Euro voor: 226,44 Euro Art.nr: 301308 Bestellen: http://63.105.9.58/em/em47pt.htm ============================================================== Als u gebruik wilt maken van deze aanbiedingen, dan kunt u bestellen via internet: http://63.105.9.58/em/em47pt.htm U hebt de producten (indien op voorraad) binnen 2 dagen op uw bureau. Met vriendelijke groet, Teledirekt Nederland De genoemde prijzen zijn exclusief BTW. Administratiekosten: fl. 15,- (6,81 Euro). ************************************************************** Wanneer u SoftwareNieuws niet meer wilt ontvangen, kunt u: 1. dit aangeven op http://www.teledirektnederland.nl/maillijst2.htm; 2. ons telefonisch op de hoogte stellen dat u van de maillijst verwijderd wilt worden; 3. een e-mailtje sturen naar softwarenieuws@teledirekt.nl U kunt zich ook algemeen afmelden voor commerciële e-mail berichten via www.e-mps.org/nl Deze e-mailing is verzonden geheel volgens de gedragscode van de DMSA. ************************************************************** Teledirekt Nederland B.V. Kelvinring 58 2952 BG Alblasserdam GRATIS Verkoopadvieslijn: 0800 - 237 66 44 Helpdesk (1 gpm): 0900 - 237 66 48 Fax: 078 - 691 98 29 E-mail adressen: Klantenservice: mailto:klantenservice@teledirekt.nl Helpdesk: mailto:helpdesk@teledirekt.nl Bestelcode: EM47p From vogtm@skunk.physik.uni-erlangen.de Thu Oct 25 14:27:01 2001 From: vogtm@skunk.physik.uni-erlangen.de (Marco Vogt) Date: Thu Oct 25 13:27:01 2001 Subject: Windows XP: al vanaf fl. 285,- In-Reply-To: <57472001104251111160@teledirekt.nl> Message-ID: On Thu, 25 Oct 2001, Teledirekt Nederland wrote: > > Geachte heer/mevrouw > Nog 1 dag en dan is het zover: de releasedatum van WINDOWS XP !! > > Windows XP, het allernieuwste besturingssysteem van Microsoft, kunt u nu > bij ons > bestellen !! LOL, I think this firm don't really know to whom they send their spam... Long lives Linux... From subscriber@locustcreek.com Thu Oct 25 16:30:02 2001 From: subscriber@locustcreek.com (Oblio) Date: Thu Oct 25 15:30:02 2001 Subject: Windoze question Message-ID: <5.1.0.14.2.20011025091250.038d1600@mail.locustcreek.com> Hi, I'm new to this list, so please bear with me. I've been poking around the Net looking for the C++ libraries for PGP to write my own program. I'd like to get open source libraries as I will be creating software for commercial endeavors. The other issue is I'd like them for Windows, preferably Win2K. If anyone can help, I'd appreciate it. Oblio From apm35@student.open.ac.uk Thu Oct 25 18:37:01 2001 From: apm35@student.open.ac.uk (Andrew Marlow) Date: Thu Oct 25 17:37:01 2001 Subject: Windoze question Message-ID: I think this has hightlighted an important point about the GPG web site. It is not immediately obvious (to me, anyway) from the web site that GPG is covered by the GPL. Those in the know will presume it is, since it is a GNU project. But here we have someone asking about open source. IMO GNU projects make an important distinction between open source and free software. I believe that GPG is in the latter category. This means that GPG is software that has freedom and the license says that in order for you to enjoy this freedom you must not take it away from others. Some GPL'd source comes with libraries that are LGPL'd. The LGPL allows the library to be used in the development of closed-source proprietary software. Whether you use PGP or GPG you need to check these things out. Just having the source code available is not enough. License permitting, I would recommend GPG over PGP since I think GPG has a closer eye on the RFC and other issues, such as crypto-law and patent law. GPG has also taken some decisions which have made it less vunerable to certain problems (e.g the ADK issue). -apm From dshaw@jabberwocky.com Thu Oct 25 18:43:01 2001 From: dshaw@jabberwocky.com (David Shaw) Date: Thu Oct 25 17:43:01 2001 Subject: More 1.0.6b comments Message-ID: <20011025114043.D7040@akamai.com> --/NkBOFFp2J2Af1nK Content-Type: multipart/mixed; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Here's a few more comments: 12) If you set a key to ultimate trust, and it's the only ultimately trusted key, gpg gets confused if you unset its ultimate trust. The key will still be shown as "u", but --check-trustdb warns "no ultimately trusted keys found" and schedules the next update for "????-??-??". 13) Once --update-trustdb starts, there is no way to exit it ("q" just skips to the next key). 14) Little bug: in 1.0.6, if you changed trust via the --edit menu, gpg would display the new trust after you changed it. 1.0.6b does not do this. Attached is a fix for #13 and #14. It also adds a "s" for skip, which skips to the next key since "q" now actually quits. The existing "s" (for the not yet implemented more information) is now "i". David --=20 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 --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch.gnupg-1.0.6b.dms.trustupdate.1" Content-Transfer-Encoding: quoted-printable Index: pkclist.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/gnupg/gnupg/g10/pkclist.c,v retrieving revision 1.58.2.24 diff -u -r1.58.2.24 pkclist.c --- pkclist.c 2001/10/23 08:03:45 1.58.2.24 +++ pkclist.c 2001/10/25 03:40:23 @@ -241,7 +241,7 @@ keyid_from_pk (pk, keyid); for(;;) { /* a string with valid answers */ - const char *ans =3D _("sSmMqQ"); + const char *ans =3D _("iImMqQsS"); =20 if( !did_help )=20 { @@ -268,15 +268,18 @@ tty_printf (_(" %d =3D I trust fully\n"), 4); if (mode) tty_printf (_(" %d =3D I trust ultimately\n"), 5); - tty_printf (_(" s =3D please show me more information\n") ); + tty_printf (_(" i =3D please show me more information\n") ); if( mode ) tty_printf(_(" m =3D back to the main menu\n")); else - tty_printf(_(" q =3D quit\n")); + { + tty_printf(_(" s =3D skip this key\n")); + tty_printf(_(" q =3D quit\n")); + } tty_printf("\n"); did_help =3D 1; } - if( strlen(ans) !=3D 6 ) + if( strlen(ans) !=3D 8 ) BUG(); p =3D cpr_get("edit_ownertrust.value",_("Your decision? ")); trim_spaces(p); @@ -319,6 +322,10 @@ { break ; /* back to the menu */ } + else if( !mode && (*p =3D=3D ans[6] || *p =3D=3D ans[7] ) ) + { + break; /* skip */ + } else if( !mode && (*p =3D=3D ans[4] || *p =3D=3D ans[5] ) ) { quit =3D 1; @@ -346,7 +353,7 @@ switch ( do_edit_ownertrust (pk, mode, &trust, no_help ) ) { case -1: /* quit */ - return 0; + return -1; case -2: /* show info */ show_paths(pk, 1); no_help =3D 1; @@ -355,7 +362,7 @@ trust &=3D ~TRUST_FLAG_DISABLED; trust |=3D get_ownertrust (pk) & TRUST_FLAG_DISABLED; update_ownertrust (pk, trust ); - return 0; + return 1; default: return 0; } Index: trustdb.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/gnupg/gnupg/g10/trustdb.c,v retrieving revision 1.81.2.25 diff -u -r1.81.2.25 trustdb.c --- trustdb.c 2001/09/28 16:59:47 1.81.2.25 +++ trustdb.c 2001/10/25 03:40:27 @@ -846,12 +846,12 @@ *********** NEW NEW NEW **************** ****************************************/ =20 -static unsigned int +static int ask_ownertrust (u32 *kid) { PKT_public_key *pk; int rc; - unsigned int ot; + int ot; =20 pk =3D m_alloc_clear (sizeof *pk); rc =3D get_pubkey (pk, kid); @@ -862,10 +862,13 @@ return TRUST_UNKNOWN; } =20 - if (edit_ownertrust (pk, 0)) + ot=3Dedit_ownertrust(pk,0); + if(ot>0) ot =3D get_ownertrust (pk); - else + else if(ot=3D=3D0) ot =3D TRUST_UNDEFINED; + else + ot =3D -1; /* quit */ free_public_key( pk ); return ot; } @@ -1303,6 +1306,7 @@ validate_keys (int interactive) { int rc =3D 0; + int quit=3D0; struct key_item *klist =3D NULL; struct key_item *k; struct key_array *keys =3D NULL; @@ -1377,7 +1381,12 @@ { if (interactive && k->ownertrust =3D=3D TRUST_UNKNOWN) k->ownertrust =3D ask_ownertrust (k->kid); - if (k->ownertrust =3D=3D TRUST_UNKNOWN) + if (k->ownertrust =3D=3D -1) + { + quit=3D1; + goto leave; + } + else if (k->ownertrust =3D=3D TRUST_UNKNOWN) ot_unknown++; else if (k->ownertrust =3D=3D TRUST_UNDEFINED) ot_undefined++; @@ -1448,7 +1457,7 @@ release_key_array (keys); release_key_items (klist); release_key_hash_table (visited); - if (!rc) /* mark trustDB as checked */ + if (!rc && !quit) /* mark trustDB as checked */ { if (next_expire =3D=3D 0xffffffff) tdbio_write_nextcheck (0);=20 --qMm9M+Fa2AknHoGS-- --/NkBOFFp2J2Af1nK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6b (GNU/Linux) iQEVAwUBO9gye4ccwqs8s7QVAQFYewf+NQUjzjA68VOfESBVMyTG9N1FNlo+MO4R BwF9CczWutXUzC0zE1QxBI1U6gq5nkR8rqf9liFLgH0rzegNaP2ab9FkXoPW3jWE rJGdpZP4G01+87vcN1wBo8LMcVE1HCh/1a1HGHR0XAuLWWJ44Cgd6sWQDlekLGW0 BUPUsxBAF1VPBXsBjdNYdynxiYDoPLd+srfXc44N3yyJPNOuNFIU7JRZo6zDLhQR o61pq7ueSpmsjkSpbgsk1+Av56bBPj2ovwCBwZdNhHpnidVZhZveFkZTy7uK6WUU yfpQhOE5os4oNcr9Lsj287r0GzcM8EfGx6m+DQBZWKA+25EUXQR54w== =OL52 -----END PGP SIGNATURE----- --/NkBOFFp2J2Af1nK-- From Fabian.Rodriguez@Toxik.com Thu Oct 25 21:37:02 2001 From: Fabian.Rodriguez@Toxik.com (Toxik - Fabian Rodriguez) Date: Thu Oct 25 20:37:02 2001 Subject: Verisign / Network Solutions PGP guardian method does not support GnuPG In-Reply-To: <5.1.0.14.2.20011025091250.038d1600@mail.locustcreek.com> Message-ID: Hello, From time to time I verify different scenarios in which our customers may use GnuPG as a complete replacement to PGP. It is interesting to note that Network Solutions' PGP guardian method does not work with GnuPG generated signatures. I am enclosing the original response (less my message), as reference. Please note that I used GnuPG v1.0.6 (MingW32) and WinPT 0.4.0a. Then with PGP 7.03 it was completed fine, with the exact same text, using the same key, same software (Outlook), etc. Only the encryption software was different. BTW, on their site they mention: "Our PGP keyserver will accept PGP Version 2.6 to 6.5.2.", however I sent my key generated with GnuPG/WinPT by email and their server accepted it. And the message I sent after that (resulting in the error reply), was signed with PGP 7.03. Also note it took 18 days for the key to be added (instead of 24h). I thought it would be more appropiate to send it here than to risk it being lost in their support system. Thank you, Fabian Rodriguez - Toxik Technologies Inc. www.Toxik.com - Open PGP ID: 0x5AF2A4D5 > -----Original Message----- > From: Domain Registration Role Account [mailto:domreg@networksolutions.com] > Sent: October 24, 2001 16:42 > To: dnsadmin@toxik.com > Subject: Re: [NIC-XXXXXX.XXXX] DOMAIN NAME (request id modified for privacy purposes) > > > Thank you for contacting VeriSign. > > We have received your message, but are unable to process it at this > time. The most likely reasons why this may have happened are listed > below. Please review this list and compare the possible errors with > your message. If possible, correct the error and re-send your e-mail > to VeriSign at hostmaster@networksolutions.com. > > 1. Your PGP signed message was MIME-encapsulated. Most Windows based > e-mail applications will perform this conversion. Currently, we cannot > support PGP signed messages that have been MIME-encapsulated. > > 2. There are extra characters in your message, which distort your PGP > signature and make it impossible for us to confirm that your signature > is correct. These extra characters are inserted when a PGP plugin for > Outlook or Eudora are used to sign a message, and the message is then > sent to a system using a UNIX platform, which we use. Currently, we > cannot support PGP signed messages sent from a computer using any > platform other than UNIX. > > 3. Although PGP is your Guardian method, you did not sign your message > with your PGP private key. Please sign your message with your PGP > private key and return it by e-mail to VeriSign at > hostmaster@networksolutions.com. > > 4. It appears that you have more than one PGP private key. Although you > signed this message with a PGP key, you didn't use the PGP private key > that is associated with the contact handle on this record. Please make > sure that you are using the right PGP private key to sign your message > and return the message by e-mail to VeriSign at > hostmaster@networksolutions.com. > > Best regards, > VeriSign, Inc. > http://www.netsol.com From jam@jamux.com Fri Oct 26 15:52:01 2001 From: jam@jamux.com (John A. Martin) Date: Fri Oct 26 14:52:01 2001 Subject: Verisign / Network Solutions PGP guardian method does not support GnuPG In-Reply-To: ("Toxik - Fabian Rodriguez"; Thu, 25 Oct 2001 14:34:39 -0400) Message-ID: <20011026124944.CF9263B891@athene.jamux.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "FR" == Fabian Rodriguez >>>>> "Verisign / Network Solutions PGP guardian method does not support GnuPG" >>>>> Thu, 25 Oct 2001 14:34:39 -0400 FR> Hello, From time to time I verify different scenarios in which FR> our customers may use GnuPG as a complete replacement to FR> PGP. It is interesting to note that Network Solutions' PGP FR> guardian method does not work with GnuPG generated signatures. Compare: http://lists.gnupg.org/pipermail/gnupg-users/2001-September/010016.html http://lists.gnupg.org/pipermail/gnupg-users/2001-September/010019.html http://lists.gnupg.org/pipermail/gnupg-users/2001-September/010027.html http://lists.gnupg.org/pipermail/gnupg-users/2001-September/010035.html Especially the last. jam -----BEGIN PGP SIGNATURE----- Comment: OpenPGP encrypted mail preferred. See iEYEARECAAYFAjvZW5YACgkQUEvv1b/iXy+bnQCfTL++f7dy0y1AA733oYWiK61O llwAn2p51JVa1Q5lOhhepLv4Nbb91IMZ =d0wo -----END PGP SIGNATURE----- From roconnor@math.berkeley.edu Mon Oct 29 00:56:01 2001 From: roconnor@math.berkeley.edu (roconnor@math.berkeley.edu) Date: Mon Oct 29 00:56:01 2001 Subject: GnuPG for OS/2 Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I thought I'd let the list know of a port to OS/2. - -- Russell O'Connor roconnor@math.berkeley.edu ``This is not a time, as it is never a time, to seek vengeance, but a time to seek the courage to forgive'' -- George W. Bush -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (SunOS) Comment: For info see http://www.gnupg.org iD8DBQE73JqXZG3em5NXM14RAk3WAKDyhgsQkW4dbqfXYvbigW8RD4tT7gCdEFGi 5YvNZNgq0ozTd37+HYqf9og= =bo4q -----END PGP SIGNATURE----- From wk@gnupg.org Mon Oct 29 08:56:01 2001 From: wk@gnupg.org (Werner Koch) Date: Mon Oct 29 08:56:01 2001 Subject: GnuPG for OS/2 In-Reply-To: (roconnor@math.berkeley.edu's message of "Sun, 28 Oct 2001 15:53:52 -0800 (PST)") References: Message-ID: <87u1wianis.fsf@alberti.gnupg.de> On Sun, 28 Oct 2001 15:53:52 -0800 (PST), roconnor said: > I thought I'd let the list know of a port to OS/2. > How to you handle the RNG issue? Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From roconnor@math.berkeley.edu Mon Oct 29 09:03:01 2001 From: roconnor@math.berkeley.edu (roconnor@math.berkeley.edu) Date: Mon Oct 29 09:03:01 2001 Subject: GnuPG for OS/2 In-Reply-To: <87u1wianis.fsf@alberti.gnupg.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 29 Oct 2001, Werner Koch wrote: > How to you handle the RNG issue? I wrote a Rexx Entropy Gathering Daemon based on the Perl EGD. It's not as good as a driver to gather interupt infromation, but should be about as good as the Perl EGD. - -- Russell O'Connor roconnor@alumni.uwaterloo.ca ``This is not a time, as it is never a time, to seek vengeance, but a time to seek the courage to forgive'' -- George W. Bush -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (SunOS) Comment: For info see http://www.gnupg.org iD8DBQE73QzYZG3em5NXM14RAuVHAJ9LrKvHGV04O6nd3fONkCMUorky/QCg1bx1 HSSmex1FEoWjb2cZbQfRZoQ= =a7/l -----END PGP SIGNATURE----- From wk@gnupg.org Mon Oct 29 09:50:02 2001 From: wk@gnupg.org (Werner Koch) Date: Mon Oct 29 09:50:02 2001 Subject: GnuPG for OS/2 In-Reply-To: (roconnor@math.berkeley.edu's message of "Mon, 29 Oct 2001 00:01:22 -0800 (PST)") References: Message-ID: <874roial19.fsf@alberti.gnupg.de> On Mon, 29 Oct 2001 00:01:22 -0800 (PST), roconnor said: > I wrote a Rexx Entropy Gathering Daemon > based on the Perl EGD. > It's not as good as a driver to gather interupt infromation, but should be > about as good as the Perl EGD. But what do you use as source for the entropy? It may have changed in recent version of OS/2 but I am not aware of any system services which can be used. The only way I can think to do it is by writing Device drivers becuase this way you can get in closer touch with the kernel. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From rabbi@quickie.net Mon Oct 29 10:03:01 2001 From: rabbi@quickie.net (Len Sassaman) Date: Mon Oct 29 10:03:01 2001 Subject: Windoze question In-Reply-To: Message-ID: On Thu, 25 Oct 2001, Andrew Marlow wrote: > License permitting, I would recommend GPG over PGP since I think GPG has a > closer eye on the RFC and other issues, such as crypto-law and patent law. > GPG has also taken some decisions which have made it less vunerable to > certain problems (e.g the ADK issue). Just about all of the above statements are not based on fact. -- Len Sassaman Security Architect | "Now it's all change -- Technology Consultant | It's got to change more." | http://sion.quickie.net | --Joe Jackson From roconnor@math.berkeley.edu Mon Oct 29 16:45:02 2001 From: roconnor@math.berkeley.edu (roconnor@math.berkeley.edu) Date: Mon Oct 29 16:45:02 2001 Subject: GnuPG for OS/2 In-Reply-To: <874roial19.fsf@alberti.gnupg.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 29 Oct 2001, Werner Koch wrote: > But what do you use as source for the entropy? It may have changed in > recent version of OS/2 but I am not aware of any system services which > can be used. The only way I can think to do it is by writing Device > drivers becuase this way you can get in closer touch with the kernel. Well, I use system and network statistics like the Perl EGD does. I use - -list of processes running - -how long they have been running - -how long the computer has been up - -the time - -list of running threads and their state - -list of semaphores - -list of loaded modules - -free memory available - -network mbufs - -udp stats - -ip stats - -current socket stats - -current routing table (and use stats) - -general interface stats - -arp table - -- Russell O'Connor roconnor@alumni.uwaterloo.ca ``This is not a time, as it is never a time, to seek vengeance, but a time to seek the courage to forgive'' -- George W. Bush -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (SunOS) Comment: For info see http://www.gnupg.org iD8DBQE73XjuZG3em5NXM14RAlMZAJwIEzXcq3IijE05UWvMBti2bmMXmACdHLSf qO0c+l/dcIErAYxoQN+qRgk= =ONUi -----END PGP SIGNATURE----- From JanuszA.Urbanowicz Wed Oct 31 22:04:01 2001 From: JanuszA.Urbanowicz (JanuszA.Urbanowicz) Date: Wed Oct 31 22:04:01 2001 Subject: trust problem in the b snapshot Message-ID: Problems with trust calculation - again: The environment is: :alex@sword:[~]:11:> gpg --version gpg (GnuPG) 1.0.6b [..] I signed and set trust for following keys: pub 1024D/826BAA66 created: 2001-07-14 expires: never trust: f/f pub 1024D/FC494FC4 created: 2000-12-06 expires: never trust: f/f pub 1024D/F9289982 created: 1997-10-13 expires: never trust: f/f pub 2048R/2C67FD2D created: 1999-05-18 expires: never trust: f/f Now I import 7AA3260A from certserver.pgp.com which is signed by the keys I trust: pub 1024D/7AA3260A 2000-05-13 Artur Stepien sig 7AA3260A 2000-11-21 Artur Stepien sig 826BAA66 2001-07-16 Robert R. Wal (Gadzinka) sig FC494FC4 2001-07-19 Miros/law Baran (Jubal) uid Artur Stepien (Muczachan) sig 7AA3260A 2000-11-21 Artur Stepien sig 826BAA66 2001-07-16 Robert R. Wal (Gadzinka) sig FC494FC4 2001-07-19 Miros/law Baran (Jubal) uid Artur St\xc3\xaapie\xc3\xb1 (Muczachan) sig 7AA3260A 2000-05-13 Artur Stepien sig 826BAA66 2001-07-14 Robert R. Wal (Gadzinka) sig 2C67FD2D 2001-07-14 Robert R. Wal (PGP2 RSA key) sig 0CA7686C 2000-11-21 [User id not found] sig F9289982 2000-09-12 Szymon Sokol sig FC494FC4 2001-07-19 Miros/law Baran (Jubal) sub 2048g/04706BBF 2000-05-13 sig 7AA3260A 2000-05-13 Artur Stepien but I got no trust for the key?! pub 1024D/7AA3260A created: 2000-05-13 expires: never trust: -/- Alex -- Janusz A. Urbanowicz | ALEX3-RIPE | SF-Framling | Thawte Web Of Trust Notary Gdy dajê biednym chleb, nazywaj± mnie ¶wiêtym. Gdy pytam, dlaczego biedni nie maj± chleba, nazywaj± mnie komunist±. - abp. Helder Camara From halpin@qwpage.com Wed Oct 31 23:42:01 2001 From: halpin@qwpage.com (halpin@qwpage.com) Date: Wed Oct 31 23:42:01 2001 Subject: Making GnuPg w/Cygwin Message-ID: <3BE03802.16183.AA96018@localhost> Hello all, this is my first post. Right off the bat you'll have to forgive me - I work on a Windoze box. So, speak slowly and use simple words. :-) I've used Cygwin successfully in the past to make Win32 Tcl/Tk binaries that run on this box, so I think my my environment is fairly sound. The versions are: Cygwin B20 gcc version egcs-2.91.57 19980901 (egcs-1.1 release) GNU assembler version 2.9.4 (i586-cygwin32) using BFD version 2.9.4 GNU Make version 3.75 I'm trying to make GnuPg 1.0.6 Problem 1 ---------------- bash-2.02$ cd //d/gnupg-1.0.6 bash-2.02$ cd zlib bash-2.02$ make clean test -z "libzlib.a" || rm -f libzlib.a test -z "foo.gz" || rm -f foo.gz rm -f *.o core *.core bash-2.02$ make gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -c adler32.c gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -c compress.c gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -c inffast.c rm -f libzlib.a ar cru libzlib.a adler32.o compress.o crc32.o uncompr.o libzlib.a libzlib.a: 1: Syntax error: redirection unexpected make: *** [libzlib.a] Error 2 bash-2.02$ In the MAKEFILE I see: RANLIB = libzlib.a: $(libzlib_a_OBJECTS) $(libzlib_a_DEPENDENCIES) -rm -f libzlib.a $(AR) cru libzlib.a $(libzlib_a_OBJECTS) $(libzlib_a_LIBADD) $(RANLIB) libzlib.a If I remove the last line ($(RANLIB) libzlib.a, I can get all the way through. Is this the correct thing to do? (There is a ranlib in my cygwin bin directory.) Problem 2 -------------- Having removed the RANLIB statements in several of the MAKEFILEs, I now get this: `echo gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../intl -g -O2 -Wall -D IS_MODULE -shared -fPIC -o tiger ./tiger.c | \ sed -e 's/-O[2-9s]*/-O/g' ` gcc: unrecognized option `-shared' In file included from ./tiger.c:26: ..\include\util.h:207: warning: `stricmp' redefined C:\cygnus\CYGWIN~1\H-I586~1\bin\..\lib\gcc-lib\i586-cygwin32\egcs- 2.91.57\..\..\ ..\..\i586-cygwin32\include\string.h:76: warning: this is the location of the previous definition /cygnus/CYGWIN~1/H-I586~1/i586-cygwin32/bin/as.exe: bfd assertion fail /home/noer/src/b20/comp-tools/devo/bfd/coff-i386.c:479 C:\Temp\ccz8EiPb.s: Assembler messages: C:\Temp\ccz8EiPb.s:2261: Error: Cannot represent relocation type BFD_RELOC_386_GOTPC /cygnus/CYGWIN~1/H-I586~1/i586-cygwin32/bin/as.exe: bfd assertion fail /home/noer/src/b20/comp-tools/devo/bfd/coff-i386.c:479 C:\Temp\ccz8EiPb.s:2357: Error: Cannot represent relocation type BFD_RELOC_386_GOTPC /cygnus/CYGWIN~1/H-I586~1/i586-cygwin32/bin/as.exe: bfd assertion fail /home/noer/src/b20/comp-tools/devo/bfd/coff-i386.c:479 C:\Temp\ccz8EiPb.s:2565: Error: Cannot represent relocation type BFD_RELOC_386_GOTPC /cygnus/CYGWIN~1/H-I586~1/i586-cygwin32/bin/as.exe: bfd assertion fail /home/noer/src/b20/comp-tools/devo/bfd/coff-i386.c:479 C:\Temp\ccz8EiPb.s:2931: Error: Cannot represent relocation type BFD_RELOC_386_GOTPC /cygnus/CYGWIN~1/H-I586~1/i586-cygwin32/bin/as.exe: bfd assertion fail /home/noer/src/b20/comp-tools/devo/bfd/coff-i386.c:479 C:\Temp\ccz8EiPb.s:3200: Error: Cannot represent relocation type BFD_RELOC_386_GOTPC /cygnus/CYGWIN~1/H-I586~1/i586-cygwin32/bin/as.exe: bfd assertion fail /home/noer/src/b20/comp-tools/devo/bfd/coff-i386.c:479 C:\Temp\ccz8EiPb.s:3356: Error: Cannot represent relocation type BFD_RELOC_386_GOTPC /cygnus/CYGWIN~1/H-I586~1/i586-cygwin32/bin/as.exe: bfd assertion fail /home/noer/src/b20/comp-tools/devo/bfd/coff-i386.c:479 C:\Temp\ccz8EiPb.s:3761: Error: Cannot represent relocation type BFD_RELOC_386_GOTPC /cygnus/CYGWIN~1/H-I586~1/i586-cygwin32/bin/as.exe: bfd assertion fail /home/noer/src/b20/comp-tools/devo/bfd/coff-i386.c:479 C:\Temp\ccz8EiPb.s:3875: Error: Cannot represent relocation type BFD_RELOC_386_GOTPC make[2]: *** [tiger] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive-am] Error 2 :-( Asserts, eh? Who the heck do 'ya call on this? -------------------------------------------- Any tips appreciated - and if this is posted to the wrong list please accept my apologies. Regards Bob Halpin (I may be crazy, but I'm not (too) stupid.) P.S. - Anybody got a MAKEFILE for Borland? From jshayward at pobox.com Mon Oct 1 20:47:08 2001 From: jshayward at pobox.com (Jonathan Hayward -- http://JonathansCorner.com) Date: Tue Oct 7 21:28:06 2003 Subject: gpg initialization Message-ID: <3BB84CCE.6CCBA5C1@pobox.com> Is there any documentation (besides the comments/code) to how gpg initializes? -- Jonathan Hayward jshayward@pobox.com http://JonathansCorner.com (A four dimensional maze, stories, essays, artwork, and other things...) -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20011001/c1cdf4c5/attachment.htm From mbp2 at Lehigh.EDU Mon Oct 1 23:15:01 2001 From: mbp2 at Lehigh.EDU (mbp2@Lehigh.EDU) Date: Tue Oct 7 21:28:06 2003 Subject: Adding recipients to an encrypted message? Message-ID: <1001967174.3bb8ce46744b5@IMP.Lehigh.EDU> A suggestion for a new feature... the ability to add recipients to an encrypted message. If I have a file or message that's encrypted to me, and I want to give it securely to someone else, it's awkward to have to decrypt the whole thing and then re-encrypt it again to the new person, especially if the file is large. It'd be very useful if I could tell GPG to decrypt the session key using my private key and immediately encrypt it (just the session key) with the new person's public key, and then add a new recipient packet to the message without touching the encrypted message body. This is not only more secure (it's easier to wipe a small decrypted session key from memory than a whole decrypted message), but also faster and more convenient. -- Mike Paul mbp2@lehigh.edu http://www.lehigh.edu/~mbp2/ From wk at gnupg.org Tue Oct 2 00:36:01 2001 From: wk at gnupg.org (Werner Koch) Date: Tue Oct 7 21:28:06 2003 Subject: Adding recipients to an encrypted message? In-Reply-To: <1001967174.3bb8ce46744b5@IMP.Lehigh.EDU> (mbp2@Lehigh.EDU's message of "Mon, 01 Oct 2001 16:12:54 -0400 (EDT)") References: <1001967174.3bb8ce46744b5@IMP.Lehigh.EDU> Message-ID: <878zev3v0j.fsf@alberti.gnupg.de> On Mon, 01 Oct 2001 16:12:54 -0400 (EDT), mbp2 said: > then re-encrypt it again to the new person, especially if the file is large. > It'd be very useful if I could tell GPG to decrypt the session key using my > private key and immediately encrypt it (just the session key) with the new have a look at the options $ gpg --dump-options |grep session --show-session-key --override-session-key The simplest way would be something like this: $ gpg --show-session-key -o foo.txt foo.gpg 2>&1 \ | gpg -e -r key-escrow@privacy.gov | mail solo@u.n.c.l.e And on the u.n.c.l.e site Napoleon could do this: $ gpg --override-session-key extracted_from_mail msg_from_echelon Well you can also use the session key to create a public key encrypted packet and prepend it to the message - however there is no direct support for it in GnuPG. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From mbp2 at Lehigh.EDU Tue Oct 2 04:36:01 2001 From: mbp2 at Lehigh.EDU (mbp2@Lehigh.EDU) Date: Tue Oct 7 21:28:06 2003 Subject: Adding recipients to an encrypted message? Message-ID: <1001986429.3bb9197d660f9@IMP.Lehigh.EDU> I was thinking of something that would produce an ordinary OpenPGP message that can be decrypted normally to the new recipient... maybe the recipient isn't convinced of the usefulness of cryptography in the first place, or is using commercial PGP so they can't use --override-session-key, or both. In both the GPG documentation and your example, the --show-session key option is described as being meant for key-escrow purposes. I'm talking about the more casual act of forwarding a message to someone. It shouldn't be too hard to add an option... something like "gpg --add-recipient ciphertext.gpg newrecipient@foo.com" which would extract the session key and add a new recipient packet to the message. (I'm submitting to the list without being subscribed so hopefully the threading will work correctly...) -- Mike Paul mbp2@lehigh.edu http://www.lehigh.edu/~mbp2/ From wk at gnupg.org Tue Oct 2 10:54:01 2001 From: wk at gnupg.org (Werner Koch) Date: Tue Oct 7 21:28:06 2003 Subject: Adding recipients to an encrypted message? In-Reply-To: <1001986429.3bb9197d660f9@IMP.Lehigh.EDU> (mbp2@Lehigh.EDU's message of "Mon, 01 Oct 2001 21:33:49 -0400 (EDT)") References: <1001986429.3bb9197d660f9@IMP.Lehigh.EDU> Message-ID: <87vghy32fg.fsf@alberti.gnupg.de> On Mon, 01 Oct 2001 21:33:49 -0400 (EDT), mbp2 said: > described as being meant for key-escrow purposes. I'm talking about the more > casual act of forwarding a message to someone. It shouldn't be too hard to add I can't think of a situation where you want to forward an encrypted message to another recipient without reading the message first. -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From Florian.Weimer at RUS.Uni-Stuttgart.DE Tue Oct 2 16:26:01 2001 From: Florian.Weimer at RUS.Uni-Stuttgart.DE (Florian Weimer) Date: Tue Oct 7 21:28:06 2003 Subject: Adding recipients to an encrypted message? In-Reply-To: <87vghy32fg.fsf@alberti.gnupg.de> (Werner Koch's message of "Tue, 02 Oct 2001 09:51:15 +0200") References: <1001986429.3bb9197d660f9@IMP.Lehigh.EDU> <87vghy32fg.fsf@alberti.gnupg.de> Message-ID: Werner Koch writes: > On Mon, 01 Oct 2001 21:33:49 -0400 (EDT), mbp2 said: > I can't think of a situation where you want to forward an encrypted > message to another recipient without reading the message first. Encrypted mailing lists could be implemented more efficiently if the main message part would not have to be encrypted over and over again. (Because of padding, the reused session key should not be a problem even with RSA, but I'm not sure about that.) -- Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 From pgut001 at cs.auckland.ac.nz Tue Oct 2 17:15:01 2001 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Tue Oct 7 21:28:06 2003 Subject: Adding recipients to an encrypted message? Message-ID: <200110021412.CAA135615@ruru.cs.auckland.ac.nz> Florian Weimer writes: >Werner Koch writes: >>On Mon, 01 Oct 2001 21:33:49 -0400 (EDT), mbp2 said: >>I can't think of a situation where you want to forward an encrypted >>message to another recipient without reading the message first. >Encrypted mailing lists could be implemented more efficiently if the main >message part would not have to be encrypted over and over again. (Because of >padding, the reused session key should not be a problem even with RSA, but I'm >not sure about that.) The S/MIME folks have looked at this problem in some detail over quite some time, there are RFCs/RFC drafts available from the S/MIME WG home page http://www.imc.org/ietf-smime/index.html. (They also have a second home page at http://www.ietf.org/html.charters/smime-charter.html which has a non- overlapping set of drafts, you may need to check there. Try and ignore the fact that the page is shared with drafts on how to do X.400 with S/MIME). Peter. From sosa1004kr at yahoo.co.kr Thu Oct 4 22:43:03 2001 From: sosa1004kr at yahoo.co.kr (ÃÊû°­¿¬) Date: Tue Oct 7 21:28:06 2003 Subject: [ÃÊû°­¿¬ È«º¸] ±× ´©°¡ °¨È÷ Çй®Àº ¾ø¾ú´Ù°í ¿ÜÃÆ´ø°¡? Message-ID: <200110041940.f94Jeard020040@mail.openit.de> An HTML attachment was scrubbed... URL: /pipermail/attachments/20011004/3939c492/attachment.htm From jan at intevation.de Fri Oct 5 15:07:01 2001 From: jan at intevation.de (Jan-Oliver Wagner) Date: Tue Oct 7 21:28:06 2003 Subject: ANN: Sphinx (S/MIME, X.509) project for MUAs (KMail, mutt) Message-ID: <20011005140441.B14526@intevation.de> Dear list, we are happy to announce that the German "Bundesamt f?r Sicherheit in der Informationstechnik" (Federal Agency for IT Security, BSI) contracted us (Intevation, Klar?lvdalens Datakonsult and g10 Code) to make sure that Free Software for their email security standard Sphinx will be created. Sphinx basically consists of S/MIME, a PKIX compatible X.509 profile, together with certificate revocation lists (CRLs) based on LDAP. The code developed will be modular allowing inclusion in several MUAs released under the GNU GPL. Part of the contract with the BSI is the inclusion in mutt and KMail. The initial project pages can be reached from the URL below. We wanted to get the good news out to you as fast as possible. Expect more information to get released on the website or on the corresponding mailing lists. We plan to do the development in an open manner suitable for Free Software projects. We want to handle the project in a way that it will leverage and add to the work of other developers and ask for your collaboration. The BSI pays us to ensure that their specs are followed precisely and the result passes strict tests. This is the first time the BSI contracts for Free Software development and the experiences they make will be important. We will demonstrate the power of commercial Free Software. www.gnupg.org/aegypten -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From bre at klaki.net Fri Oct 5 18:50:02 2001 From: bre at klaki.net (Bjarni R. Einarsson) Date: Tue Oct 7 21:28:07 2003 Subject: Strange problem with GnuPG 1.0.4 encrypted data Message-ID: <20011005154830.F15179@klaki.net> Hello, I have a system which GPG encrypts and signs files and mails them from one machine to another, where they are automatically decrypted and the signatures verified using a perl program. Last night a file was transferred which appeared to have a valid signature, but then couldn't be decrypted. Gnupg sent the following message to stderr: gpg: Warning: using insecure memory! gpg: encrypted with 1024-bit ELG-E key, ID FAFF94B3, created 2001-09-20 [snip] gpg: Signature made Thu Oct 4 20:45:46 2001 GMT using DSA key ID 327144DC gpg: Good signature from "[snip]" 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: B083 585B 8675 0058 5113 0F98 FA17 F199 3271 44DC gpg: [don't know]: invalid packet (ctb=14) The file was encrypted on a dual PIII 800Mhz machine using GnuPG 1.0.4 as distributed with RedHat Linux 7.1. I tried decrypting it both with GnuPG 1.0.4 and 1.0.6 (RH 7.1 update package), with the same results. I haven't been able to reproduce this problem yet, but since I'm creating and sending dozens of messages like this every day (usually without any problems) I rather expect it to manifest itself again sooner or later. My question is whether any bugs were found in GnuPG 1.0.4 which could cause this kind of bizarre failure, or whether I should start worrying about hardware problems. Also, am I correct in assuming that since the signature was OK, that I can rule out any transmission errors as the cause of this and focus on the creation of the encrypted file? If you developers feel this is a bug and that it would help to examine the file in question I have no problems sharing it and the necessary keys with you - I'm currently just testing this setup and regenerating my keys would be no big deal. Please CC: any replies directly to me, as I'm not subscribe to this list - and please forgive me if I overlooked a more appropriate venue for this message. Thanks! -- Bjarni R. Einarsson PGP: 02764305, B7A3AB89 bre@klaki.net -><- http://bre.klaki.net/ Check out my open-source email sanitizer: http://mailtools.anomy.net/ From jpg at rcom.com.ar Fri Oct 12 21:48:01 2001 From: jpg at rcom.com.ar (Juan Pablo =?ISO-8859-1?Q?Gim=E9nez?=) Date: Tue Oct 7 21:28:07 2003 Subject: gnupg Message-ID: <1002912389.10546.9.camel@kang.oficina.rcom.com.ar> Hi! I have a problem with the option "--with-colons" and --list-keys or --fingerprint, if i don't use it, gpg print my last name "Gim?nez" with the "?", but if I put with-colons insted of "?" gpg prints "??"... So here is the patch to fix it... ------------------------------------------------------------------------ ________________________________________________________________________ --- gnupg-1.0.6/g10/keylist.c Sun May 27 11:31:07 2001 +++ gnupg-1.0.6_rcom/g10/keylist.c Fri Oct 12 11:42:15 2001 @@ -482,8 +482,8 @@ printf("uid:%c::::::::", trustletter); } } - print_string( stdout, node->pkt->pkt.user_id->name, - node->pkt->pkt.user_id->len, ':' ); + print_utf8_string( stdout, node->pkt->pkt.user_id->name, + node->pkt->pkt.user_id->len); putchar(':'); if (any) putchar('\n'); ________________________________________________________________________ ------------------------------------------------------------------------- Chausesssssssssss Juan Pablo.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 240 bytes Desc: not available Url : /pipermail/attachments/20011012/060dc207/attachment.bin From redbird at rbisland.cx Sun Oct 14 08:24:02 2001 From: redbird at rbisland.cx (Gordon Worley) Date: Tue Oct 7 21:28:07 2003 Subject: Goodbye 4th Amendment Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 http://arstechnica.com/wankerdesk/01q4/usa-act/usa-act.html Well, as some of you may already know, I and some of my fellow developers no longer have our 4th Amendment rights (protection from search and seizure for those of you who live outside the US). I don't know what the immediate effects will be for the project, other than that I may have to make sure binary releases are done all in one sitting use a fresh download of the source (may seem a little silly, but I'd rather be silly than release binaries with bad stuff in them). If you read the story on how this got passed, similar procedures could see anti-crypto laws passed through, though I think after this it will be some time before the House will stand for this. - -- 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 -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use Comment: keyserver http://pgpkeys.mit.edu:11371 iQA/AwUBO8kg627zd/e707ADEQKEZgCg4ouaFNX6ssrkDwLZzPJcdfRVQ2UAoJJL +v6iHEybHuLI+UkBKAlc/VhG =tpGT -----END PGP SIGNATURE----- From redbird at rbisland.cx Sun Oct 14 08:33:01 2001 From: redbird at rbisland.cx (Gordon Worley) Date: Tue Oct 7 21:28:07 2003 Subject: Goodbye 4th Amendment In-Reply-To: References: Message-ID: At 1:20 AM -0400 10/14/01, Gordon Worley wrote: Sorry, folks, that was supposed to go to the Mac GPG developer's list. -- 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 dshaw at jabberwocky.com Sun Oct 14 20:28:02 2001 From: dshaw at jabberwocky.com (David Shaw) Date: Tue Oct 7 21:28:07 2003 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <20011014131040.B8616@akamai.com>; from dshaw@jabberwocky.com on Sun, Oct 14, 2001 at 01:10:40PM -0400 References: <01101218054502.01491@mexicali.sito.saic.com> <20011014131040.B8616@akamai.com> Message-ID: <20011014132552.C8616@akamai.com> On Sun, Oct 14, 2001 at 01:10:40PM -0400, David Shaw wrote: > At the moment, GnuPG (and PGP too) mark all signatures[1] as "I'm not > going to say". I think I feel a patch coming on.. Patch: http://www.jabberwocky.com/crypto/gnupg/patch.gnupg-1.0.6.dms.sigclass.1 Before you sign, GnuPG will prompt you for which level of certification you want to use. Answer "?" for an explanation of the different levels. This also changes key listings (in --edit-key and --list-sigs) to show which certification level was used in making the signature. No claim made as to how well it was checked: sig 3CB3B415 2001-10-14 David M. Shaw Key was not checked at all: sig 1 3CB3B415 2001-10-14 David M. Shaw Key was checked casually: sig 2 3CB3B415 2001-10-14 David M. Shaw Key was checked extensively: sig 3 3CB3B415 2001-10-14 David M. Shaw Comments welcome. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 536 bytes Desc: not available Url : /pipermail/attachments/20011014/2b276148/attachment.bin From broonie at sirena.org.uk Mon Oct 15 01:14:01 2001 From: broonie at sirena.org.uk (Mark Brown) Date: Tue Oct 7 21:28:07 2003 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <20011014132552.C8616@akamai.com> References: <01101218054502.01491@mexicali.sito.saic.com> <20011014131040.B8616@akamai.com> <20011014132552.C8616@akamai.com> Message-ID: <20011014231203.B1666@tardis.ed.ac.uk> On Sun, Oct 14, 2001 at 01:25:52PM -0400, David Shaw wrote: > sig 1 3CB3B415 2001-10-14 David M. Shaw > sig 2 3CB3B415 2001-10-14 David M. Shaw > sig 3 3CB3B415 2001-10-14 David M. Shaw It would be nice if these could be presented more clearly. I can't actually suggest a clearer way off-hand, mind you. Also, it would be nice if there were no space between the "sig" and the digit as in current output. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." From dshaw at jabberwocky.com Mon Oct 15 02:04:01 2001 From: dshaw at jabberwocky.com (David Shaw) Date: Tue Oct 7 21:28:07 2003 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <20011014231203.B1666@tardis.ed.ac.uk>; from broonie@sirena.org.uk on Sun, Oct 14, 2001 at 11:12:04PM +0100 References: <01101218054502.01491@mexicali.sito.saic.com> <20011014131040.B8616@akamai.com> <20011014132552.C8616@akamai.com> <20011014231203.B1666@tardis.ed.ac.uk> Message-ID: <20011014190116.F8616@akamai.com> On Sun, Oct 14, 2001 at 11:12:04PM +0100, Mark Brown wrote: > On Sun, Oct 14, 2001 at 01:25:52PM -0400, David Shaw wrote: > > > sig 1 3CB3B415 2001-10-14 David M. Shaw > > sig 2 3CB3B415 2001-10-14 David M. Shaw > > sig 3 3CB3B415 2001-10-14 David M. Shaw > > It would be nice if these could be presented more clearly. I can't > actually suggest a clearer way off-hand, mind you. Heh. I had the same thought. I thought about using letters, but it was even worse. At least numbers have the advantage of making a "3" clearly higher than a "2". > Also, it would be > nice if there were no space between the "sig" and the digit as in > current output. Try a --check-sigs. That space is taken for the sig status character. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 536 bytes Desc: not available Url : /pipermail/attachments/20011015/091af6fc/attachment.bin From broonie at sirena.org.uk Mon Oct 15 02:26:01 2001 From: broonie at sirena.org.uk (Mark Brown) Date: Tue Oct 7 21:28:07 2003 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <20011014190116.F8616@akamai.com> References: <01101218054502.01491@mexicali.sito.saic.com> <20011014131040.B8616@akamai.com> <20011014132552.C8616@akamai.com> <20011014231203.B1666@tardis.ed.ac.uk> <20011014190116.F8616@akamai.com> Message-ID: <20011015002427.E1666@tardis.ed.ac.uk> On Sun, Oct 14, 2001 at 07:01:16PM -0400, David Shaw wrote: > > Also, it would be > > nice if there were no space between the "sig" and the digit as in > > current output. > Try a --check-sigs. That space is taken for the sig status character. That's what I was thinking of :-) . At present there's no space before any extra data on the type of entity being listed. With your patch this would change. Not that one ought to be attempting machine parsing of the output of anything not --with-colons, but anyway. -- "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: 240 bytes Desc: not available Url : /pipermail/attachments/20011015/7962ff72/attachment.bin From dshaw at jabberwocky.com Mon Oct 15 05:48:01 2001 From: dshaw at jabberwocky.com (David Shaw) Date: Tue Oct 7 21:28:07 2003 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <20011015002427.E1666@tardis.ed.ac.uk>; from broonie@sirena.org.uk on Mon, Oct 15, 2001 at 12:24:27AM +0100 References: <01101218054502.01491@mexicali.sito.saic.com> <20011014131040.B8616@akamai.com> <20011014132552.C8616@akamai.com> <20011014231203.B1666@tardis.ed.ac.uk> <20011014190116.F8616@akamai.com> <20011015002427.E1666@tardis.ed.ac.uk> Message-ID: <20011014224503.B21134@akamai.com> On Mon, Oct 15, 2001 at 12:24:27AM +0100, Mark Brown wrote: > On Sun, Oct 14, 2001 at 07:01:16PM -0400, David Shaw wrote: > > > > Also, it would be > > > nice if there were no space between the "sig" and the digit as in > > > current output. > > > Try a --check-sigs. That space is taken for the sig status character. > > That's what I was thinking of :-) . At present there's no space before > any extra data on the type of entity being listed. With your patch this > would change. Not that one ought to be attempting machine parsing of > the output of anything not --with-colons, but anyway. Ah, I understand now. Hmm. It's easy enough to move it over by one if there is no sig status, but don't you think that would make it harder to read rather than easier? The eye wouldn't be able to just look in the same place each time. I'm also toying with a patch to show various informative flags in that area (an "L" for a local signature, a "P" for a policy URL, "N" for a notation, etc). 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 536 bytes Desc: not available Url : /pipermail/attachments/20011015/68e9f325/attachment.bin From dshaw at jabberwocky.com Tue Oct 16 00:38:02 2001 From: dshaw at jabberwocky.com (David Shaw) Date: Tue Oct 7 21:28:07 2003 Subject: Sig classification, version 2 Message-ID: <20011015173637.B4515@akamai.com> Here's version 2 of the sig classification patch I sent in yesterday (thanks for the comments, everyone). It contains everything that was in version 1, with some better help text, and it also shows a few other pieces of information about the signature: 1-3 == amount of verification in the signature (just like before) L == local signature (e.g. made by "--lsign-key"). R == signature is non-revocable. P == a policy URL is attached to this signature. N == a notation is attached to this signature. You can use the --show-policy-url and --show-notation options to display the policy or notation (in a --list-sigs or --edit/check). There is also a --no-show-policy-url and --no-show-notation for the folks who like to override their config file on occasion. --fast-list-mode disables everything except the 1-3 levels of verification (which don't cost anything to retrieve). http://www.jabberwocky.com/crypto/gnupg/patch.gnupg-1.0.6.dms.sigclass.2 Comments welcome. 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 redbird at rbisland.cx Tue Oct 16 06:03:01 2001 From: redbird at rbisland.cx (Gordon Worley) Date: Tue Oct 7 21:28:08 2003 Subject: GPGME.framework Beta 0.2.3 Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Okay, now this message is supposed to show up on this list. ;-) At the Mac GPG project we've released GPGME.framework Beta 0.2.3. This should work on any OpenStepish environment, like GNUStep and Mac OS X. This beta is not a final release and is still missing a few features (use the source, I'll compile release notes when I have time), but there's enough there to get some stuff done. Feel free to beat it around and find any bugs. You can get Beta 0.2.3 here: http://sourceforge.net/project/showfiles.php?group_id=20789&release_id=57202 or just grab the latest out of the Mac GPG CVS tree. For more info on that and the project in general, visit: http://macgpg.sourceforge.net/ - -- 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 -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use Comment: keyserver http://pgpkeys.mit.edu:11371 iQA/AwUBO8ui3m7zd/e707ADEQL6ZQCgymipUUkThn1e+NFvJm+2bEc1Yh4AnRt4 J19AWLt+ZoLqJFAT6uYTGir6 =uniR -----END PGP SIGNATURE----- From mwy-gpg41 at the-youngs.org Tue Oct 16 18:09:02 2001 From: mwy-gpg41 at the-youngs.org (Michael Young) Date: Tue Oct 7 21:28:08 2003 Subject: Re; Sig classification (was Re: discussion on increasing amount of gpg signatures...) References: Message-ID: <003301c15654$23c8fa60$dfc32609@transarc.ibm.com> -----BEGIN PGP SIGNED MESSAGE----- > Before you sign, GnuPG will prompt you for which level of > certification you want to use. Answer "?" for an explanation of the > different levels. Excellent! A couple of months ago, I built a command-line switch to do this, but didn't get around to posting it. (When I looked back through the mailing list archives, it appeared that signature types were an unpopular idea at some past OpenPGP meetings.) How would you feel about adding a command-line option? As it stands, batch operations get a "generic" signature. I used "--sig-type" in my patch. I could recreate it against yours if you're interested. To make good use of these additional validity levels, the trust model really should understand them. For example, I might fully trust type-3 signatures from "John Smith", partially trust his type-2 signatures, and not trust any type-1. But that's for another day... I'm glad to see the first step. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQEVAwUBO8xM32NDnIII+QUHAQH52gf9Gmd7v524TaY+qJo9UhX8aG4naq69dn/b M+79JQj68xLpeWOVDtKFqSWVSOWcVBA2tiW6+JvZaJ9a5AAmfsk4yie3lQpS2Srp 9wmye2hm/y9CNfHD58PLiUYUlzWDhAj2V3+OZntkC7w9FWMRX3hz+9YCQ5XqpApj 59V5OjWV9XNgB4TkCvCEfGiY8dhJ9BMFBnQzYKvQoffsxVZdgoDK3x9Em+8OFLIw IeiIea6b3+AizaYQxUhAywxE6fdw0gX+gHP7I9Gxb0mZwLD//PY+jVGAW6QVvLAi l2lonJ6e1V5KuZpgNKzT1XK95w8/jzNZhstaEjOd+To4rnRYsYirRw== =i6n2 -----END PGP SIGNATURE----- From gnupg at lists.colondot.net Tue Oct 16 18:51:01 2001 From: gnupg at lists.colondot.net (Matthew Byng-Maddick) Date: Tue Oct 7 21:28:08 2003 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <003301c15654$23c8fa60$dfc32609@transarc.ibm.com>; from mwy-gpg41@the-youngs.org on Tue, Oct 16, 2001 at 11:06:30AM -0400 References: <003301c15654$23c8fa60$dfc32609@transarc.ibm.com> Message-ID: <20011016164931.A98387@colon.colondot.net> On Tue, Oct 16, 2001 at 11:06:30AM -0400, Michael Young wrote: > To make good use of these additional validity levels, the trust > model really should understand them. For example, I might > fully trust type-3 signatures from "John Smith", partially > trust his type-2 signatures, and not trust any type-1. > But that's for another day... I'm glad to see the first step. If you do this, you have to trust that he will choose the correct type of signature to sign with. MBM -- Matthew Byng-Maddick http://colondot.net/ From broonie at sirena.org.uk Tue Oct 16 19:37:02 2001 From: broonie at sirena.org.uk (Mark Brown) Date: Tue Oct 7 21:28:08 2003 Subject: Re; Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <003301c15654$23c8fa60$dfc32609@transarc.ibm.com> References: <003301c15654$23c8fa60$dfc32609@transarc.ibm.com> Message-ID: <20011016173439.G10896@tardis.ed.ac.uk> On Tue, Oct 16, 2001 at 11:06:30AM -0400, Michael Young wrote: > To make good use of these additional validity levels, the trust > model really should understand them. For example, I might > fully trust type-3 signatures from "John Smith", partially > trust his type-2 signatures, and not trust any type-1. > But that's for another day... I'm glad to see the first step. There are also trusted introducer signatures (which are implemented by NAI PGP). -- "You grabbed my hand and we fell into it, like a daydream - or a fever." From dshaw at jabberwocky.com Wed Oct 17 00:15:01 2001 From: dshaw at jabberwocky.com (David Shaw) Date: Tue Oct 7 21:28:08 2003 Subject: Re; Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <003301c15654$23c8fa60$dfc32609@transarc.ibm.com>; from mwy-gpg41@the-youngs.org on Tue, Oct 16, 2001 at 11:06:30AM -0400 References: <003301c15654$23c8fa60$dfc32609@transarc.ibm.com> Message-ID: <20011016171254.I667@akamai.com> On Tue, Oct 16, 2001 at 11:06:30AM -0400, Michael Young wrote: > > Before you sign, GnuPG will prompt you for which level of > > certification you want to use. Answer "?" for an explanation of the > > different levels. > > Excellent! A couple of months ago, I built a command-line switch > to do this, but didn't get around to posting it. (When I looked > back through the mailing list archives, it appeared that signature > types were an unpopular idea at some past OpenPGP meetings.) > > How would you feel about adding a command-line option? As it > stands, batch operations get a "generic" signature. I used > "--sig-type" in my patch. I could recreate it against yours > if you're interested. Good idea. I've added it to v3 of the patch. The command is --default-sig-class, and it takes a number from 0-3. If you set a default sig class in your options file, you can use --no-default-sig-class to override it back to 0. The menu that pops up when key signing will reflect the new default. Also added: * 'If you don't know what the right answer is, answer "0"' message * minor fix to notations - they should be printed as UTF8. http://www.jabberwocky.com/crypto/gnupg/patch.gnupg-1.0.6.dms.sigclass.3 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 536 bytes Desc: not available Url : /pipermail/attachments/20011016/31d65ae3/attachment.bin From dshaw at jabberwocky.com Wed Oct 17 02:04:01 2001 From: dshaw at jabberwocky.com (David Shaw) Date: Tue Oct 7 21:28:08 2003 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <20011016164931.A98387@colon.colondot.net>; from gnupg@lists.colondot.net on Tue, Oct 16, 2001 at 04:49:31PM +0100 References: <003301c15654$23c8fa60$dfc32609@transarc.ibm.com> <20011016164931.A98387@colon.colondot.net> Message-ID: <20011016190152.K667@akamai.com> On Tue, Oct 16, 2001 at 04:49:31PM +0100, Matthew Byng-Maddick wrote: > On Tue, Oct 16, 2001 at 11:06:30AM -0400, Michael Young wrote: > > To make good use of these additional validity levels, the trust > > model really should understand them. For example, I might > > fully trust type-3 signatures from "John Smith", partially > > trust his type-2 signatures, and not trust any type-1. > > But that's for another day... I'm glad to see the first step. > > If you do this, you have to trust that he will choose the correct type of > signature to sign with. Yes, and also that he can choose his signature type in the first place. All versions of PGP create the generic "I'm not going to say how much checking I did" form of the signature. Incidentally, I did confirm that PGP (at least version 6.5.8 and later) does understand all 4 signature types, even though it can't generate them. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 536 bytes Desc: not available Url : /pipermail/attachments/20011017/23c7e3b4/attachment.bin From wk at gnupg.org Thu Oct 18 15:00:02 2001 From: wk at gnupg.org (Werner Koch) Date: Tue Oct 7 21:28:08 2003 Subject: Should I release a new snapshot? Message-ID: <87adypupjb.fsf@alberti.gnupg.de> Hi! Those of you who are using the CVS version have noticed a couple of major changes in GnuPG. There is still a long list of minor bugs but nevertheless I'd like to make a new snapshot available, so that the new code can be tested. Are there any grave bugs in the CVS versions? Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From ts at winpt.org Thu Oct 18 17:00:01 2001 From: ts at winpt.org (Timo Schulz) Date: Tue Oct 7 21:28:08 2003 Subject: Should I release a new snapshot? In-Reply-To: <87adypupjb.fsf@alberti.gnupg.de> References: <87adypupjb.fsf@alberti.gnupg.de> Message-ID: <20011018155031.E412@daredevil.joesixpack.net> On Thu Oct 18 2001; 13:59, Werner Koch wrote: > Are there any grave bugs in the CVS versions? I'm not sure if this is only my problem. But with the new --refresh-key command it happens from time to time that one key exists twice in the keyring. Timo -- "Das wahre Vaterland ist das Land, wo man die meisten Menschen trifft, die einem gleichen." -- Henri Stendhal From wk at gnupg.org Thu Oct 18 20:30:02 2001 From: wk at gnupg.org (Werner Koch) Date: Tue Oct 7 21:28:08 2003 Subject: Should I release a new snapshot? In-Reply-To: <20011018155031.E412@daredevil.joesixpack.net> (Timo Schulz's message of "Thu, 18 Oct 2001 15:50:31 +0200") References: <87adypupjb.fsf@alberti.gnupg.de> <20011018155031.E412@daredevil.joesixpack.net> Message-ID: <87u1wwsvqp.fsf@alberti.gnupg.de> On Thu, 18 Oct 2001 15:50:31 +0200, Timo Schulz said: > I'm not sure if this is only my problem. But with the > new --refresh-key command it happens from time to time > that one key exists twice in the keyring. Yeah, if a snapshot helps to track this bug down, I should do it. There are also a few other problems mainly for Windows and RISC OS but those are not the primary target. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From jpg at rcom.com.ar Fri Oct 19 21:20:01 2001 From: jpg at rcom.com.ar (Juan Pablo =?ISO-8859-1?Q?Gim=E9nez?=) Date: Tue Oct 7 21:28:08 2003 Subject: with-colons bug Message-ID: <1003515471.19982.26.camel@kang.oficina.rcom.com.ar> Hi! I already send this mail with other subject, but nobody answer because it was too simple... I have a problem with the option "--with-colons" and --list-keys or --fingerprint, if i don't use it, gpg print my last name "Gim?nez" with the "?", but if I put with-colons insted of "?" gpg prints "??"... So here is the patch to fix it... ________________________________________________________________________ --- gnupg-1.0.6/g10/keylist.c Sun May 27 11:31:07 2001 +++ gnupg-1.0.6_rcom/g10/keylist.c Fri Oct 12 11:42:15 2001 @@ -482,8 +482,8 @@ printf("uid:%c::::::::", trustletter); } } - print_string( stdout, node->pkt->pkt.user_id->name, - node->pkt->pkt.user_id->len, ':' ); + print_utf8_string( stdout, node->pkt->pkt.user_id->name, + node->pkt->pkt.user_id->len); putchar(':'); if (any) putchar('\n'); ________________________________________________________________________ Chausesssssssssss Juan Pablo.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 240 bytes Desc: not available Url : /pipermail/attachments/20011019/90cdd3d3/attachment.bin From fw at deneb.enyo.de Sat Oct 20 00:38:01 2001 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue Oct 7 21:28:08 2003 Subject: with-colons bug In-Reply-To: <1003515471.19982.26.camel@kang.oficina.rcom.com.ar> (Juan Pablo =?iso-8859-1?q?Gim=E9nez's?= message of "19 Oct 2001 15:17:51 -0300") References: <1003515471.19982.26.camel@kang.oficina.rcom.com.ar> Message-ID: <87d73j5oli.fsf@deneb.enyo.de> Juan Pablo Gim?nez writes: > I have a problem with the option "--with-colons" and --list-keys or > --fingerprint, if i don't use it, gpg print my last name "Gim?nez" with > the "?", but if I put with-colons insted of "?" gpg prints "??"... So > here is the patch to fix it... I think this behavior is mostly correct. In "--with-colons" mode, GnuPG is expected to dump the user ID as is, without further processing. From jpg at rcom.com.ar Sat Oct 20 01:33:01 2001 From: jpg at rcom.com.ar (Juan Pablo =?ISO-8859-1?Q?Gim=E9nez?=) Date: Tue Oct 7 21:28:08 2003 Subject: with-colons bug In-Reply-To: <87d73j5oli.fsf@deneb.enyo.de> References: <1003515471.19982.26.camel@kang.oficina.rcom.com.ar> <87d73j5oli.fsf@deneb.enyo.de> Message-ID: <1003530662.4450.21.camel@kang.oficina.rcom.com.ar> En vie, 2001-10-19 a 18:03, Florian Weimer escribi?: Juan Pablo Gim?nez writes: > I have a problem with the option "--with-colons" and --list-keys or > --fingerprint, if i don't use it, gpg print my last name "Gim?nez" with > the "?", but if I put with-colons insted of "?" gpg prints "??"... So > here is the patch to fix it... I think this behavior is mostly correct. In "--with-colons" mode, GnuPG is expected to dump the user ID as is, without further processing. Ok, but thats break some programs, for example Gabber (Gnome Jabber client), who print the strings as is so it print it wrong... So, what do you think, the problem is gnupg or for example Gabber?!?! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 240 bytes Desc: not available Url : /pipermail/attachments/20011020/cd0942d4/attachment.bin From wk at gnupg.org Sat Oct 20 13:56:01 2001 From: wk at gnupg.org (Werner Koch) Date: Tue Oct 7 21:28:08 2003 Subject: with-colons bug In-Reply-To: <1003530662.4450.21.camel@kang.oficina.rcom.com.ar> (Juan Pablo =?iso-8859-1?q?Gim=E9nez's?= message of "19 Oct 2001 19:31:02 -0300") References: <1003515471.19982.26.camel@kang.oficina.rcom.com.ar> <87d73j5oli.fsf@deneb.enyo.de> <1003530662.4450.21.camel@kang.oficina.rcom.com.ar> Message-ID: <873d4eoa2v.fsf@alberti.gnupg.de> On 19 Oct 2001 19:31:02 -0300, Juan Pablo Gim?nez said: > Ok, but thats break some programs, for example Gabber (Gnome Jabber > client), who print the strings as is so it print it wrong... So, what do > you think, the problem is gnupg or for example Gabber?!?! Gabber does not do a conversion from utf-8 to the used character set. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From mwy-gpg41 at the-youngs.org Mon Oct 22 18:39:01 2001 From: mwy-gpg41 at the-youngs.org (Michael Young) Date: Tue Oct 7 21:28:09 2003 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) References: Message-ID: <009501c15b0f$4977a760$b399183f@transarc.ibm.com> -----BEGIN PGP SIGNED MESSAGE----- > From: David Shaw > Incidentally, I did confirm that PGP (at least version 6.5.8 and > later) does understand all 4 signature types, even though it can't > generate them. I also did some confirmation. PGP2.6 should accept them. The keyservers I tested had no problem with them. Note that GnuPG had already been using class 3 for self-signatures. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQEVAwUBO9Q8omNDnIII+QUHAQHBkAgAif8tXnmcxiMMVBE4dwSDcweQxayqD1DK u9pEvD75W6dxbgdl9rlB2dd70sXVI9VhTZWo6mo/heR0Kda6gwxvRLzN0sUiP7u+ 6g9tx8wGx5POAxxJVBclL7O/kTZffjztdIm3iZKLLXh3VJ1UEVdTfIe30A/F69+X fMLAItAOe7qcPvteL40wBXZcPvK2ioE4Qtt8hc2Db7iDZLn0f+eFO6Myv2sdfHc4 KAqxb7StOpjyPJ1LELsRQ9czAU0r+O7eu05OUk1AZFyJCgzTxPBTloBVnoDs2Rmp dL9XXsHNYZM3ROTwJWfjuaflmM+4in2qe1ABh+7088EczdDS9wxqbQ== =AyYk -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Mon Oct 22 22:23:01 2001 From: dshaw at jabberwocky.com (David Shaw) Date: Tue Oct 7 21:28:09 2003 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <009501c15b0f$4977a760$b399183f@transarc.ibm.com>; from mwy-gpg41@the-youngs.org on Mon, Oct 22, 2001 at 11:35:52AM -0400 References: <009501c15b0f$4977a760$b399183f@transarc.ibm.com> Message-ID: <20011022152058.A666@akamai.com> On Mon, Oct 22, 2001 at 11:35:52AM -0400, Michael Young wrote: > > From: David Shaw > > Incidentally, I did confirm that PGP (at least version 6.5.8 and > > later) does understand all 4 signature types, even though it can't > > generate them. > > I also did some confirmation. PGP2.6 should accept them. > The keyservers I tested had no problem with them. Excellent. Thanks for checking. > Note that GnuPG had already been using class 3 for self-signatures. Yes, I noticed that. That in itself gives me more confidence there won't be problems with multiple sig classes. If there was a PGP version out there that didn't accept multiple sig classes, it would have broken with GnuPG-generated keys and we'd have heard about it by now. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 536 bytes Desc: not available Url : /pipermail/attachments/20011022/32df0111/attachment.bin From wk at gnupg.org Tue Oct 23 10:46:01 2001 From: wk at gnupg.org (Werner Koch) Date: Tue Oct 7 21:28:09 2003 Subject: Sig classification (was Re: discussion on increasing amount of gpg signatures...) In-Reply-To: <20011022152058.A666@akamai.com> (David Shaw's message of "Mon, 22 Oct 2001 15:20:58 -0400") References: <009501c15b0f$4977a760$b399183f@transarc.ibm.com> <20011022152058.A666@akamai.com> Message-ID: <87y9m2vlzu.fsf@alberti.gnupg.de> On Mon, 22 Oct 2001 15:20:58 -0400, David Shaw said: > Yes, I noticed that. That in itself gives me more confidence there > won't be problems with multiple sig classes. If there was a PGP I use 0x13 for self-signatures and 0x10 for standard signatures, mainly because this may be helpful in debugging. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From wk at gnupg.org Tue Oct 23 22:28:07 2001 From: wk at gnupg.org (Werner Koch) Date: Tue Oct 7 21:28:09 2003 Subject: [Announce] A new GnuPG snapshot (unstable) Message-ID: <877ktmtgkl.fsf@alberti.gnupg.de> Hi, after messing around with autoconf 1.5 for quite some time, I finally was able to release a new DEVELOPMENT snapshot of GnuPG: *PLEASE READ THIS ENTIRE ANNOUNCEMENT BEFORE YOU START TO PLAY* ftp://ftp.gnupg.org/gcrypt/devel/gnupg-1.0.6b.tar.gz (1.9M) ftp://ftp.gnupg.org/gcrypt/devel/gnupg-1.0.6b.tar.gz.sig Please find a list of mirrors at http://www.gnupg.org/mirrors.html Again I changed quite a lot of things. Using this version with a current keyring renders the keyring unreadable for any previous GnuPG versions. So I did WARN YOU ABOUT THESE INCOMPATIBLE CHANGES - please don't complain that it destroyed all your keys. Actually this incompatibility is due to a bug in the older versions which are not able to cope with trust packet larger than one byte. You can use --export as an escape hatch because trust packets are never exported. There are 2 major changes in this release: * The caching of the signature verification status changed from using special signature subpackets to the use of the trust packets. You can (and should) rebuild this key cache using the new command "gpg --rebuild-keydb-caches" * The format of the TrustDB and the way it works has entirely be rewritten. gpg tries to migrate to the new format but this code is obviously not very well tested, so you might want to make a backup of our ownertrust values first. The validity of the key is now checked every time you insert a new key or signature and when a key or a signature expires. This automatic check can be disabled and replaced by a cron job which does an "gpg --check-trustdb" every night or so. To assign an ownertrust, you can either do this in the edit menu or use the command "gpg --update-trustdb" which does the maintenance pass in a similar manner you probably know from PGP 2. Both changes should speed up the operation on large keyrings quite a lot so that "gpg --list-keys --with-colons" is actually usable. Also a couple of bug fixes and some other code cleanups are in this release. There is still a long list of open bugs but I think it is important to get the new code tested first. The Windows and Acorn ports won't work yet due to file sharing issues. Changes since 1.0.6a: * The way signature stati are store has changed, so that v3 signatures can be supported. To increase the speed of many operations for existing keys you can use the new --rebuild-keydb-caches command. * The entire key validation process (trustdb) has been revamped. See the man page entries for --update-trustdb, --check-trustdb and --no-auto-check-trustdb. * --trusted-keys is again obsolete, --edit can be used to set the ownertrust of any key to ultimately trusted. * A subkey is never used to sign keys. * Read only keyrings are now handled as expected. Changes since 1.0.6: * New tool gpgsplit to split OpenPGP data formats into packets. * New option --preserve-permissions. * Subkeys created in the future are not used for encryption or signing unless the new option --ignore-valid-from is used. * Revoked user-IDs are not listed unless signatures are listed too or we are in verbose mode. * There is no default comment string with ascii armors anymore except for revocation certificates and --enarmor mode. * The command "primary" in the edit menu can be used to change the primary UID, "setpref" and "updpref" can be used to change the preferences. * Fixed the preference handling; since 1.0.5 they were erroneously matched against against the latest user ID and not the given one. * RSA key generation. * Merged Stefan's patches for RISC OS in. See comments in scripts/build-riscos. * It is now possible to sign and conventional encrypt a message (-cs). * The MDC feature flag is supported and can be set by using the "updpref" edit command. * The status messages GOODSIG and BADSIG are now returning the primary UID, encoded using %XX escaping (but with spaces left as spaces, so that it should not break too much) * Support for GDBM based keyrings has been removed. * The entire keyring management has been revamped. * The way signature stati are store has changed, so that v3 signatures can be supported. To increase the speed of many operations for existing keys you can use the new --rebuild-keydb-caches command. * The entire key validation process (trustdb) has been revamped. See the man page entries for --update-trustdb, --check-trustdb and --no-auto-check-trustdb. * --trusted-keys is again obsolete, --edit can be used to set the ownertrust of any key to ultimately trusted. * A subkey is never used to sign keys. Take care, Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From dshaw at jabberwocky.com Wed Oct 24 23:12:01 2001 From: dshaw at jabberwocky.com (David Shaw) Date: Tue Oct 7 21:28:09 2003 Subject: 1.0.6b comments Message-ID: <20011024161016.A2155@akamai.com> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 493 bytes Desc: not available Url : /pipermail/attachments/20011024/6012177e/attachment.bin From rabbi at quickie.net Wed Oct 24 23:27:02 2001 From: rabbi at quickie.net (Len Sassaman) Date: Tue Oct 7 21:28:09 2003 Subject: 1.0.6b comments In-Reply-To: <20011024161016.A2155@akamai.com> Message-ID: On Wed, 24 Oct 2001, David Shaw wrote: > Hiya, > > I've been playing with 1.0.6b, and have a few comments. Some of these > are not necessarily bugs, and some of them exist in 1.0.6 as well. > > Aside from this, 1.0.6b is really great. I love --update-trustdb. > > 1) Merely having the secret key present is not enough to make a key > ultimately trusted. You have to do it by hand in --edit. If a new > key is generated, however, it is ultimately trusted. That is correct behavior. (There's a possible attack on systems that automatically import keys received in email that doing it this way protects against. I can describe it in more detail if you like.) > 8) RSA key signatures are always made with MD5 as the hash. This > makes sense for v3 key sigs, but v4 RSA key sigs are probably safe > to use something else. Yes. In PGP 7.0, we used SHA-1. No reason to stick with MD5. Also, RSA v4 keys bind their subkeys to the primary key using SHA-1 in PGP 7.x as well. > As I see it, if you are making a signature on a v4 key using your > v3 key, it doesn't make sense to generate a v3 sig. After all, the > point of using a v3 sig is to be backwards compatible, but no > v3-only PGP implementation could understand the v4 key the sig is > on in the first place. PGP versions prior to 5.x could not do v4 at all. PGP 5.x and 6.x understood v4 sigs on keys, but not on non-key material. (There's a nit about this in the RFC for 5.x; it should say 6.x as well.) (Just reiterating what you are saying here -- if an implementation can handle a v4 key, it can handle v4 sigs on a v4 key, even if it can't handle v4 sigs on other files. -- Len Sassaman Security Architect | "Now it's all change -- Technology Consultant | It's got to change more." | http://sion.quickie.net | --Joe Jackson From alex at bofh.torun.pl Thu Oct 25 01:40:01 2001 From: alex at bofh.torun.pl (Janusz A. Urbanowicz) Date: Tue Oct 7 21:28:09 2003 Subject: 1.0.6b comments (fwd) Message-ID: -- Janusz A. Urbanowicz | ALEX3-RIPE | SF-Framling | Thawte Web Of Trust Notary Gdy daj? biednym chleb, nazywaj? mnie ?wi?tym. Gdy pytam, dlaczego biedni nie maj? chleba, nazywaj? mnie komunist?. - abp. Helder Camara -------------- next part -------------- An embedded message was scrubbed... From: Janusz A. Urbanowicz Subject: Re: 1.0.6b comments Date: Thu, 25 Oct 2001 00:14:05 +0200 (CEST) Size: 2564 Url: /pipermail/attachments/20011025/e36eca53/attachment.eml From dshaw at jabberwocky.com Thu Oct 25 02:12:01 2001 From: dshaw at jabberwocky.com (David Shaw) Date: Tue Oct 7 21:28:09 2003 Subject: 1.0.6b comments (fwd) In-Reply-To: ; from alex@bofh.torun.pl on Thu, Oct 25, 2001 at 12:49:33AM +0200 References: Message-ID: <20011024190939.A13100@akamai.com> On Thu, Oct 25, 2001 at 12:49:33AM +0200, Janusz A. Urbanowicz wrote: > 11) I have a (local signature) on a key using signing subkey of my key > (since this is lsig it is not very important). This sig is not taken into > account when calculating trust: I can confirm this. It seems to apply to any key signature (local or not local) made by a signing subkey. 1.0.6b won't let signing subkeys make key signatures any longer, but there are some sigs there from older versions. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 493 bytes Desc: not available Url : /pipermail/attachments/20011025/d812983f/attachment.bin From alex at bofh.torun.pl Thu Oct 25 11:53:01 2001 From: alex at bofh.torun.pl (Janusz A. Urbanowicz) Date: Tue Oct 7 21:28:09 2003 Subject: 1.0.6b comments In-Reply-To: <20011024161016.A2155@akamai.com> from David Shaw at "Oct 24, 2001 04:10:16 pm" Message-ID: David Shaw wrote/napisa?[a]/schrieb: -- Start of PGP signed section. > Hiya, > > I've been playing with 1.0.6b, and have a few comments. Some of these > are not necessarily bugs, and some of them exist in 1.0.6 as well. > > Aside from this, 1.0.6b is really great. I love --update-trustdb. Aside that trust checking during signature verification in 1.0.6b is waay slower thanit was in 1.0.6a. And this is after setting ultimate trust on keys and rerunning update-trustdb a few times. Daaing my remark: 11) I have a (local signature) on a key using signing subkey of my key (since this is lsig it is not very important). This sig is not taken into account when calculating trust: :alex@sword:[~]:223:> gpg --edit-key RSA gpg (GnuPG) 1.0.6b; 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. gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! pub 1024R/DE46F54F created: 1999-09-16 expires: never trust: f/- ~~~ (1). Personal Freemail RSA 1999.9.16 Command> check uid Personal Freemail RSA 1999.9.16 sig! DE46F54F 1999-09-16 [self-signature] sig! 7E2E803D 2001-10-17 Janusz A. Urbanowicz (notebook) Geachte heer/mevrouw Nog 1 dag en dan is het zover: de releasedatum van WINDOWS XP !! Windows XP, het allernieuwste besturingssysteem van Microsoft, kunt u nu bij ons bestellen !! U bestelt via deze e-mail Windows XP? Profiteer dan tevens van een fikse korting op KILOMETERDECLARATIE 2001 ! U kunt Kilometerdeclaratie 2001 aanschaffen van: fl. 99,- (44,92 Euro) voor: fl. 69,- (31,31 Euro) Onderaan deze e-mailing vindt u onze speciale aanbiedingen met kortingen die oplopen tot bijna 40%. Voor een totaaloverzicht van ons assortiment: www.teledirekt.nl Wilt u extra productinformatie of een goed advies? Bel GRATIS de Teledirekt Verkoopadvieslijn: 0800-237 66 44 Als u direct wilt bestellen: http://63.105.9.58/em/em47pt.htm ============================================================== # WINDOWS XP BRENGT UW PC NAAR ONGEKENDE HOOGTE - DE NIEUWE STANDAARD VOOR EFFICI?NT EN BETROUWBAAR COMPUTERGEBRUIK - Windows XP heeft een totaal nieuwe look en is ook inhoudelijk aanzienlijk veranderd. Het besturingssysteem haakt direct in op de vooruitgang van internet en de digitale media. Microsoft introduceert een aantal edities van Windows XP die zijn afgestemd op uw computerbehoeften zowel thuis als op kantoor. * WINDOWS XP HOME EDITION * De Windows XP Home Edition is het nieuwe besturingssysteem voor de PC thuis en biedt u alles wat u nodig hebt om eenvoudig computers en een thuisnetwerk te delen. Met de digitale fotofuncties kunt u foto's ophalen, organiseren en delen met de alles-in-??n muziekfunctie kunt u kwalitatief hoogstaande muziek ontdekken, downloaden, opslaan en afspelen. - ??n plaats voor het afspelen van DVD's, ordenen van muziek, branden van CD's, etc. - Films opnemen, bewerken, ordenen en delen op uw computer. - Afbeeldingen ordenen en bekijken of afdrukken van uw foto's bestellen via een webservice. - Eenvoudiger dan ooit om uw eigen thuisnetwerk te installeren. Prijs: fl. 615,- (279,07 Euro) Win 98/2000/ME Art.nr: 303070 Bestellen: http://63.105.9.58/em/em47pt.htm * WINDOWS XP HOME EDITION UPGRADE Prijs: fl. 285,- (129,33 Euro) Win 98/2000/ME Art.nr: 303071 Bestellen: http://63.105.9.58/em/em47pt.htm * WINDOWS XP PROFESSIONAL EDITION Biedt alle voordelen van Windows XP plus o.a. een hogere veiligheid en eersteklas mobiele ondersteuning om off-line te kunnen werken of om op afstand toegang te krijgen tot uw computer. Prijs: fl. 924,- (419,29 Euro) Win 98/2000/ME Art.nr: 303068 Bestellen: http://63.105.9.58/em/em47pt.htm * WINDOWS XP PROFESSIONAL EDITION UPGRADE Prijs: fl. 571,- (259,11 Euro) Win 98/2000/ME Art.nr: 303069 Bestellen: http://63.105.9.58/em/em47pt.htm U bestelt Windows XP via deze e-mailing?? Dan kunt u Kilometerdeclaratie 2001 aanschaffen van: fl. 99,- (44,92 Euro) voor: fl. 69,- (31,31 Euro) Dit kunt u aangeven op het bestelformulier: http://63.105.9.58/em/em47pt.htm ============================================================== # CD'S WISSELEN IS NIET MEER NODIG Kopieer uw favoriete CD-Rom's naar uw harde schijf. CD's tot 20 x sneller toegankelijk. Prijs: fl. 129,- (58,54 Euro) Win 95/98/NT/2000 Art.nr: 303042 Bestellen: http://63.105.9.58/em/em47pt.htm ============================================================== # CD-FOONGIDS 2001 + ADRESBESTAND COMPACT Meer dan 7.000.000 adressen met telefoon-, fax- en mobiele nummers. Prijs: fl. 69,- (31,31 Euro) Win 95/98/NT/2000/ME Art.nr: 302779 Bestellen: http://63.105.9.58/em/em47pt.htm ============================================================== # CURSUS INTERNET, WINDOWS 98, WORD, EXCEL EN POWERPOINT Bundelprijs: fl. 79,- (35,85 Euro) Win 95/98 Art.nr: 302918 Bestellen: http://63.105.9.58/em/em47pt.htm ============================================================== # ONTWERP ZELF UW EIGEN INTERNETSITE Prijs: fl. 85,- (38,57 Euro) Win 95/98/NT/2000/ME Art.nr: 303034 Bestellen: http://63.105.9.58/em/em47pt.htm ============================================================== ** Teledirekt aanraders ** 1. Nedsoft EuroOffice pro, fl. 149,- (67,61 Euro) Microsoft Office-documenten omzetten in de Euro (art.nr: 303009) 2. CardIris, fl. 699,- (317,19 Euro) Met ??n klik al uw visitekaartjes in uw PC (art.nr: 302759) 3. Easy Travel Plus, fl. 79,- (35,85 Euro) Alle straten van de Benelux op ??n CD-Rom (art.nr: 301590) 4. 333.000 Professionele afbeeldingen, fl. 169,- (76,69 Euro) Cliparts, bitmapafbeeldingen, internetanimaties, foto's, afbeeldingen (art.nr: 301025) 5. NL-Sat, fl. 42,50 (19,29 Euro) Satellietatlas van Nederland (art.nr: 301445) Bestellen: http://63.105.9.58/em/em47pt.htm ============================================================== ** Aanbiedingen OP = OP ** # VISUAL VOORRAAD, voor een eenvoudig en overzichtelijk voorraadbeheer. Dit pakket biedt u onder andere het volgende: - Voorraden beheren. - Klant-/leveranciersafspraken bijhouden. - Automatisch bestellingen genereren. - Deelleveringen bij goederen ontvangen. - Historie van bestel- en verkoopgegevens vastleggen en opvragen. - Beheer van meerdere magazijnen (van eenvoudig tot zeer geavanceerd). - Uitgebreide opvraag van omzetgegevens per periode, artikel/artikelgroep of klant. - Ondersteuning vreemde valuta en talen. van: fl. 995,- voor: fl. 695,- (30% korting) van: 451,51 Euro voor: 315,38 Euro Art.nr: 301038 Bestellen: http://63.105.9.58/em/em47pt.htm ============================================================== # RECRUITMENT ASSISTENT, sollicitaties snel en effici?nt afhandelen. Recruitment Assistent helpt u bij het vinden van de beste kandidaat voor een vacature. Het systeem bespaart u tijd bij het maken van brieven, houdt de administratie van uw correspondentie bij en assisteert u bij de verwerking van de gegevens. Zodat u zich kunt concentreren op de mensen zelf.... van: fl. 799,- voor: fl. 499,- (38% korting) van: 362,57 Euro voor: 226,44 Euro Art.nr: 301308 Bestellen: http://63.105.9.58/em/em47pt.htm ============================================================== Als u gebruik wilt maken van deze aanbiedingen, dan kunt u bestellen via internet: http://63.105.9.58/em/em47pt.htm U hebt de producten (indien op voorraad) binnen 2 dagen op uw bureau. Met vriendelijke groet, Teledirekt Nederland De genoemde prijzen zijn exclusief BTW. Administratiekosten: fl. 15,- (6,81 Euro). ************************************************************** Wanneer u SoftwareNieuws niet meer wilt ontvangen, kunt u: 1. dit aangeven op http://www.teledirektnederland.nl/maillijst2.htm; 2. ons telefonisch op de hoogte stellen dat u van de maillijst verwijderd wilt worden; 3. een e-mailtje sturen naar softwarenieuws@teledirekt.nl U kunt zich ook algemeen afmelden voor commerci?le e-mail berichten via www.e-mps.org/nl Deze e-mailing is verzonden geheel volgens de gedragscode van de DMSA. ************************************************************** Teledirekt Nederland B.V. Kelvinring 58 2952 BG Alblasserdam GRATIS Verkoopadvieslijn: 0800 - 237 66 44 Helpdesk (1 gpm): 0900 - 237 66 48 Fax: 078 - 691 98 29 E-mail adressen: Klantenservice: mailto:klantenservice@teledirekt.nl Helpdesk: mailto:helpdesk@teledirekt.nl Bestelcode: EM47p From vogtm at skunk.physik.uni-erlangen.de Thu Oct 25 14:27:01 2001 From: vogtm at skunk.physik.uni-erlangen.de (Marco Vogt) Date: Tue Oct 7 21:28:10 2003 Subject: Windows XP: al vanaf fl. 285,- In-Reply-To: <57472001104251111160@teledirekt.nl> Message-ID: On Thu, 25 Oct 2001, Teledirekt Nederland wrote: > > Geachte heer/mevrouw > Nog 1 dag en dan is het zover: de releasedatum van WINDOWS XP !! > > Windows XP, het allernieuwste besturingssysteem van Microsoft, kunt u nu > bij ons > bestellen !! LOL, I think this firm don't really know to whom they send their spam... Long lives Linux... From subscriber at locustcreek.com Thu Oct 25 16:30:02 2001 From: subscriber at locustcreek.com (Oblio) Date: Tue Oct 7 21:28:10 2003 Subject: Windoze question Message-ID: <5.1.0.14.2.20011025091250.038d1600@mail.locustcreek.com> Hi, I'm new to this list, so please bear with me. I've been poking around the Net looking for the C++ libraries for PGP to write my own program. I'd like to get open source libraries as I will be creating software for commercial endeavors. The other issue is I'd like them for Windows, preferably Win2K. If anyone can help, I'd appreciate it. Oblio From apm35 at student.open.ac.uk Thu Oct 25 18:37:01 2001 From: apm35 at student.open.ac.uk (Andrew Marlow) Date: Tue Oct 7 21:28:10 2003 Subject: Windoze question Message-ID: I think this has hightlighted an important point about the GPG web site. It is not immediately obvious (to me, anyway) from the web site that GPG is covered by the GPL. Those in the know will presume it is, since it is a GNU project. But here we have someone asking about open source. IMO GNU projects make an important distinction between open source and free software. I believe that GPG is in the latter category. This means that GPG is software that has freedom and the license says that in order for you to enjoy this freedom you must not take it away from others. Some GPL'd source comes with libraries that are LGPL'd. The LGPL allows the library to be used in the development of closed-source proprietary software. Whether you use PGP or GPG you need to check these things out. Just having the source code available is not enough. License permitting, I would recommend GPG over PGP since I think GPG has a closer eye on the RFC and other issues, such as crypto-law and patent law. GPG has also taken some decisions which have made it less vunerable to certain problems (e.g the ADK issue). -apm From dshaw at jabberwocky.com Thu Oct 25 18:43:01 2001 From: dshaw at jabberwocky.com (David Shaw) Date: Tue Oct 7 21:28:10 2003 Subject: More 1.0.6b comments Message-ID: <20011025114043.D7040@akamai.com> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 493 bytes Desc: not available Url : /pipermail/attachments/20011025/f14bc883/attachment.bin From Fabian.Rodriguez at Toxik.com Thu Oct 25 21:37:02 2001 From: Fabian.Rodriguez at Toxik.com (Toxik - Fabian Rodriguez) Date: Tue Oct 7 21:28:10 2003 Subject: Verisign / Network Solutions PGP guardian method does not support GnuPG In-Reply-To: <5.1.0.14.2.20011025091250.038d1600@mail.locustcreek.com> Message-ID: Hello, From jam at jamux.com Fri Oct 26 15:52:01 2001 From: jam at jamux.com (John A. Martin) Date: Tue Oct 7 21:28:10 2003 Subject: Verisign / Network Solutions PGP guardian method does not support GnuPG In-Reply-To: ("Toxik - Fabian Rodriguez"; Thu, 25 Oct 2001 14:34:39 -0400) Message-ID: <20011026124944.CF9263B891@athene.jamux.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "FR" == Fabian Rodriguez >>>>> "Verisign / Network Solutions PGP guardian method does not support GnuPG" >>>>> Thu, 25 Oct 2001 14:34:39 -0400 FR> Hello, From time to time I verify different scenarios in which FR> our customers may use GnuPG as a complete replacement to FR> PGP. It is interesting to note that Network Solutions' PGP FR> guardian method does not work with GnuPG generated signatures. Compare: http://lists.gnupg.org/pipermail/gnupg-users/2001-September/010016.html http://lists.gnupg.org/pipermail/gnupg-users/2001-September/010019.html http://lists.gnupg.org/pipermail/gnupg-users/2001-September/010027.html http://lists.gnupg.org/pipermail/gnupg-users/2001-September/010035.html Especially the last. jam -----BEGIN PGP SIGNATURE----- Comment: OpenPGP encrypted mail preferred. See iEYEARECAAYFAjvZW5YACgkQUEvv1b/iXy+bnQCfTL++f7dy0y1AA733oYWiK61O llwAn2p51JVa1Q5lOhhepLv4Nbb91IMZ =d0wo -----END PGP SIGNATURE----- From roconnor at math.berkeley.edu Mon Oct 29 00:56:01 2001 From: roconnor at math.berkeley.edu (roconnor@math.berkeley.edu) Date: Tue Oct 7 21:28:10 2003 Subject: GnuPG for OS/2 Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I thought I'd let the list know of a port to OS/2. - -- Russell O'Connor roconnor@math.berkeley.edu ``This is not a time, as it is never a time, to seek vengeance, but a time to seek the courage to forgive'' -- George W. Bush -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (SunOS) Comment: For info see http://www.gnupg.org iD8DBQE73JqXZG3em5NXM14RAk3WAKDyhgsQkW4dbqfXYvbigW8RD4tT7gCdEFGi 5YvNZNgq0ozTd37+HYqf9og= =bo4q -----END PGP SIGNATURE----- From wk at gnupg.org Mon Oct 29 08:56:01 2001 From: wk at gnupg.org (Werner Koch) Date: Tue Oct 7 21:28:10 2003 Subject: GnuPG for OS/2 In-Reply-To: (roconnor@math.berkeley.edu's message of "Sun, 28 Oct 2001 15:53:52 -0800 (PST)") References: Message-ID: <87u1wianis.fsf@alberti.gnupg.de> On Sun, 28 Oct 2001 15:53:52 -0800 (PST), roconnor said: > I thought I'd let the list know of a port to OS/2. > How to you handle the RNG issue? Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From roconnor at math.berkeley.edu Mon Oct 29 09:03:01 2001 From: roconnor at math.berkeley.edu (roconnor@math.berkeley.edu) Date: Tue Oct 7 21:28:10 2003 Subject: GnuPG for OS/2 In-Reply-To: <87u1wianis.fsf@alberti.gnupg.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 29 Oct 2001, Werner Koch wrote: > How to you handle the RNG issue? I wrote a Rexx Entropy Gathering Daemon based on the Perl EGD. It's not as good as a driver to gather interupt infromation, but should be about as good as the Perl EGD. - -- Russell O'Connor roconnor@alumni.uwaterloo.ca ``This is not a time, as it is never a time, to seek vengeance, but a time to seek the courage to forgive'' -- George W. Bush -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (SunOS) Comment: For info see http://www.gnupg.org iD8DBQE73QzYZG3em5NXM14RAuVHAJ9LrKvHGV04O6nd3fONkCMUorky/QCg1bx1 HSSmex1FEoWjb2cZbQfRZoQ= =a7/l -----END PGP SIGNATURE----- From wk at gnupg.org Mon Oct 29 09:50:02 2001 From: wk at gnupg.org (Werner Koch) Date: Tue Oct 7 21:28:10 2003 Subject: GnuPG for OS/2 In-Reply-To: (roconnor@math.berkeley.edu's message of "Mon, 29 Oct 2001 00:01:22 -0800 (PST)") References: Message-ID: <874roial19.fsf@alberti.gnupg.de> On Mon, 29 Oct 2001 00:01:22 -0800 (PST), roconnor said: > I wrote a Rexx Entropy Gathering Daemon > based on the Perl EGD. > It's not as good as a driver to gather interupt infromation, but should be > about as good as the Perl EGD. But what do you use as source for the entropy? It may have changed in recent version of OS/2 but I am not aware of any system services which can be used. The only way I can think to do it is by writing Device drivers becuase this way you can get in closer touch with the kernel. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From rabbi at quickie.net Mon Oct 29 10:03:01 2001 From: rabbi at quickie.net (Len Sassaman) Date: Tue Oct 7 21:28:10 2003 Subject: Windoze question In-Reply-To: Message-ID: On Thu, 25 Oct 2001, Andrew Marlow wrote: > License permitting, I would recommend GPG over PGP since I think GPG has a > closer eye on the RFC and other issues, such as crypto-law and patent law. > GPG has also taken some decisions which have made it less vunerable to > certain problems (e.g the ADK issue). Just about all of the above statements are not based on fact. -- Len Sassaman Security Architect | "Now it's all change -- Technology Consultant | It's got to change more." | http://sion.quickie.net | --Joe Jackson From roconnor at math.berkeley.edu Mon Oct 29 16:45:02 2001 From: roconnor at math.berkeley.edu (roconnor@math.berkeley.edu) Date: Tue Oct 7 21:28:11 2003 Subject: GnuPG for OS/2 In-Reply-To: <874roial19.fsf@alberti.gnupg.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 29 Oct 2001, Werner Koch wrote: > But what do you use as source for the entropy? It may have changed in > recent version of OS/2 but I am not aware of any system services which > can be used. The only way I can think to do it is by writing Device > drivers becuase this way you can get in closer touch with the kernel. Well, I use system and network statistics like the Perl EGD does. I use - -list of processes running - -how long they have been running - -how long the computer has been up - -the time - -list of running threads and their state - -list of semaphores - -list of loaded modules - -free memory available - -network mbufs - -udp stats - -ip stats - -current socket stats - -current routing table (and use stats) - -general interface stats - -arp table - -- Russell O'Connor roconnor@alumni.uwaterloo.ca ``This is not a time, as it is never a time, to seek vengeance, but a time to seek the courage to forgive'' -- George W. Bush -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (SunOS) Comment: For info see http://www.gnupg.org iD8DBQE73XjuZG3em5NXM14RAlMZAJwIEzXcq3IijE05UWvMBti2bmMXmACdHLSf qO0c+l/dcIErAYxoQN+qRgk= =ONUi -----END PGP SIGNATURE----- From alex at bofh.torun.pl Wed Oct 31 22:04:01 2001 From: alex at bofh.torun.pl (Janusz A. Urbanowicz) Date: Tue Oct 7 21:28:11 2003 Subject: trust problem in the b snapshot Message-ID: Problems with trust calculation - again: The environment is: :alex@sword:[~]:11:> gpg --version gpg (GnuPG) 1.0.6b [..] I signed and set trust for following keys: pub 1024D/826BAA66 created: 2001-07-14 expires: never trust: f/f pub 1024D/FC494FC4 created: 2000-12-06 expires: never trust: f/f pub 1024D/F9289982 created: 1997-10-13 expires: never trust: f/f pub 2048R/2C67FD2D created: 1999-05-18 expires: never trust: f/f Now I import 7AA3260A from certserver.pgp.com which is signed by the keys I trust: pub 1024D/7AA3260A 2000-05-13 Artur Stepien sig 7AA3260A 2000-11-21 Artur Stepien sig 826BAA66 2001-07-16 Robert R. Wal (Gadzinka) sig FC494FC4 2001-07-19 Miros/law Baran (Jubal) uid Artur Stepien (Muczachan) sig 7AA3260A 2000-11-21 Artur Stepien sig 826BAA66 2001-07-16 Robert R. Wal (Gadzinka) sig FC494FC4 2001-07-19 Miros/law Baran (Jubal) uid Artur St\xc3\xaapie\xc3\xb1 (Muczachan) sig 7AA3260A 2000-05-13 Artur Stepien sig 826BAA66 2001-07-14 Robert R. Wal (Gadzinka) sig 2C67FD2D 2001-07-14 Robert R. Wal (PGP2 RSA key) sig 0CA7686C 2000-11-21 [User id not found] sig F9289982 2000-09-12 Szymon Sokol sig FC494FC4 2001-07-19 Miros/law Baran (Jubal) sub 2048g/04706BBF 2000-05-13 sig 7AA3260A 2000-05-13 Artur Stepien but I got no trust for the key?! pub 1024D/7AA3260A created: 2000-05-13 expires: never trust: -/- Alex -- Janusz A. Urbanowicz | ALEX3-RIPE | SF-Framling | Thawte Web Of Trust Notary Gdy daj? biednym chleb, nazywaj? mnie ?wi?tym. Gdy pytam, dlaczego biedni nie maj? chleba, nazywaj? mnie komunist?. - abp. Helder Camara From halpin at qwpage.com Wed Oct 31 23:42:01 2001 From: halpin at qwpage.com (halpin@qwpage.com) Date: Tue Oct 7 21:28:11 2003 Subject: Making GnuPg w/Cygwin Message-ID: <3BE03802.16183.AA96018@localhost> Hello all, this is my first post. Right off the bat you'll have to forgive me - I work on a Windoze box. So, speak slowly and use simple words. :-) I've used Cygwin successfully in the past to make Win32 Tcl/Tk binaries that run on this box, so I think my my environment is fairly sound. The versions are: Cygwin B20 gcc version egcs-2.91.57 19980901 (egcs-1.1 release) GNU assembler version 2.9.4 (i586-cygwin32) using BFD version 2.9.4 GNU Make version 3.75 I'm trying to make GnuPg 1.0.6 Problem 1 ---------------- bash-2.02$ cd //d/gnupg-1.0.6 bash-2.02$ cd zlib bash-2.02$ make clean test -z "libzlib.a" || rm -f libzlib.a test -z "foo.gz" || rm -f foo.gz rm -f *.o core *.core bash-2.02$ make gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -c adler32.c gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -c compress.c gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -c inffast.c rm -f libzlib.a ar cru libzlib.a adler32.o compress.o crc32.o uncompr.o libzlib.a libzlib.a: 1: Syntax error: redirection unexpected make: *** [libzlib.a] Error 2 bash-2.02$ In the MAKEFILE I see: RANLIB = libzlib.a: $(libzlib_a_OBJECTS) $(libzlib_a_DEPENDENCIES) -rm -f libzlib.a $(AR) cru libzlib.a $(libzlib_a_OBJECTS) $(libzlib_a_LIBADD) $(RANLIB) libzlib.a If I remove the last line ($(RANLIB) libzlib.a, I can get all the way through. Is this the correct thing to do? (There is a ranlib in my cygwin bin directory.) Problem 2 -------------- Having removed the RANLIB statements in several of the MAKEFILEs, I now get this: `echo gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../intl -g -O2 -Wall -D IS_MODULE -shared -fPIC -o tiger ./tiger.c | \ sed -e 's/-O[2-9s]*/-O/g' ` gcc: unrecognized option `-shared' In file included from ./tiger.c:26: ..\include\util.h:207: warning: `stricmp' redefined C:\cygnus\CYGWIN~1\H-I586~1\bin\..\lib\gcc-lib\i586-cygwin32\egcs- 2.91.57\..\..\ ..\..\i586-cygwin32\include\string.h:76: warning: this is the location of the previous definition /cygnus/CYGWIN~1/H-I586~1/i586-cygwin32/bin/as.exe: bfd assertion fail /home/noer/src/b20/comp-tools/devo/bfd/coff-i386.c:479 C:\Temp\ccz8EiPb.s: Assembler messages: C:\Temp\ccz8EiPb.s:2261: Error: Cannot represent relocation type BFD_RELOC_386_GOTPC /cygnus/CYGWIN~1/H-I586~1/i586-cygwin32/bin/as.exe: bfd assertion fail /home/noer/src/b20/comp-tools/devo/bfd/coff-i386.c:479 C:\Temp\ccz8EiPb.s:2357: Error: Cannot represent relocation type BFD_RELOC_386_GOTPC /cygnus/CYGWIN~1/H-I586~1/i586-cygwin32/bin/as.exe: bfd assertion fail /home/noer/src/b20/comp-tools/devo/bfd/coff-i386.c:479 C:\Temp\ccz8EiPb.s:2565: Error: Cannot represent relocation type BFD_RELOC_386_GOTPC /cygnus/CYGWIN~1/H-I586~1/i586-cygwin32/bin/as.exe: bfd assertion fail /home/noer/src/b20/comp-tools/devo/bfd/coff-i386.c:479 C:\Temp\ccz8EiPb.s:2931: Error: Cannot represent relocation type BFD_RELOC_386_GOTPC /cygnus/CYGWIN~1/H-I586~1/i586-cygwin32/bin/as.exe: bfd assertion fail /home/noer/src/b20/comp-tools/devo/bfd/coff-i386.c:479 C:\Temp\ccz8EiPb.s:3200: Error: Cannot represent relocation type BFD_RELOC_386_GOTPC /cygnus/CYGWIN~1/H-I586~1/i586-cygwin32/bin/as.exe: bfd assertion fail /home/noer/src/b20/comp-tools/devo/bfd/coff-i386.c:479 C:\Temp\ccz8EiPb.s:3356: Error: Cannot represent relocation type BFD_RELOC_386_GOTPC /cygnus/CYGWIN~1/H-I586~1/i586-cygwin32/bin/as.exe: bfd assertion fail /home/noer/src/b20/comp-tools/devo/bfd/coff-i386.c:479 C:\Temp\ccz8EiPb.s:3761: Error: Cannot represent relocation type BFD_RELOC_386_GOTPC /cygnus/CYGWIN~1/H-I586~1/i586-cygwin32/bin/as.exe: bfd assertion fail /home/noer/src/b20/comp-tools/devo/bfd/coff-i386.c:479 C:\Temp\ccz8EiPb.s:3875: Error: Cannot represent relocation type BFD_RELOC_386_GOTPC make[2]: *** [tiger] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive-am] Error 2 :-( Asserts, eh? Who the heck do 'ya call on this? -------------------------------------------- Any tips appreciated - and if this is posted to the wrong list please accept my apologies. Regards Bob Halpin (I may be crazy, but I'm not (too) stupid.) P.S. - Anybody got a MAKEFILE for Borland?