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 턻i�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 턻i�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 턻i�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 턻i�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 턻i�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 턻i�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>