From lionel at mamane.lu Sat Apr 1 07:58:15 2006 From: lionel at mamane.lu (Lionel Elie Mamane) Date: Sat Apr 1 07:57:37 2006 Subject: poldi bug: SIGSEGV if no reader In-Reply-To: <1143841910.14483.12.camel@localhost.localdomain> References: <20060216212652.GA31891@capsaicin.mamane.lu> <1143841910.14483.12.camel@localhost.localdomain> Message-ID: <20060401055815.GA15353@capsaicin.mamane.lu> On Fri, Mar 31, 2006 at 11:51:50PM +0200, Moritz Schulte wrote: >> Besides the wait-timeout option is not documented (but should really >> be set by default!). > Why is that? For e.g. login, I wouldn't want Poldi to use a timeout > so that login is respawned every few minutes, because of failed > logins. Err... That's not what it does, at least to my understanding and testing. It doesn't make login exit when it is just sitting idly. *But*, if there is a card reader but no card in the reader and the user logging in has a card associated with him, then it makes the whole login process fall back to other authentication methods (such as pam_unix) when there is no card inserted after the said timeout. That's the effect I was presenting as desirable. -- Lionel From mo at g10code.com Sat Apr 1 11:33:58 2006 From: mo at g10code.com (Moritz Schulte) Date: Sat Apr 1 11:33:12 2006 Subject: poldi bug: SIGSEGV if no reader In-Reply-To: <20060217072511.GA1742@capsaicin.mamane.lu> References: <20060216212652.GA31891@capsaicin.mamane.lu> <20060217072511.GA1742@capsaicin.mamane.lu> Message-ID: <1143884038.24278.1.camel@localhost.localdomain> Hi, > Similarly, if another application (such as scdaemon) is holding the > card open from pcscd, pcscd tells poldi "sharing violation" and poldi > aborts the whole process rather than cleanly returning a PAM code for > "couldn't authenticate". Hmm.. I have scdaemon running right now. And trying to use Poldi causes the authentication process to fail with the following messages in my Syslog: Mar 31 19:30:16 localhost su[13220]: [Poldi] pcsc_establish_context failed: no service (0x8010001d) Mar 31 19:30:17 localhost su[13220]: [Poldi] Failure: Card error Mar 31 19:30:17 localhost su[13220]: pam_authenticate: Authentication failure Mar 31 19:30:17 localhost su[13220]: - pts/6 moritz:root I am not sure where exactly Poldi aborts execution for you. > I understand scdaemon is holding the card open to allow PIN caching? Not really. scdaemon is simply an smartcard access middleware for our Gnupg components. It provides a high-level interface for smartcard related operations like e.g. cryptographic operations, retrival of smartcard data, etc. > That's rather problematic, because then it will never be able to > coexist peacefully with poldi. Right now, scdaemon and poldi cannot run simultanously - sad but true. Hopefuly this will be solved one day. Moritz -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : /pipermail/attachments/20060401/5a0d557e/attachment.pgp From mo at g10code.com Sat Apr 1 11:34:20 2006 From: mo at g10code.com (Moritz Schulte) Date: Sat Apr 1 12:33:39 2006 Subject: poldi bug: SIGSEGV if no reader In-Reply-To: <20060216212652.GA31891@capsaicin.mamane.lu> References: <20060216212652.GA31891@capsaicin.mamane.lu> Message-ID: <1143884060.24278.2.camel@localhost.localdomain> Hi, sorry for the late reply. > When pcscd is running, but no reader is connected, poldi makes the > program segfault. Could you please have a look at the current development version, which is contained in our SVN repository accessible through: svn co svn://cvs.gnupg.org/poldi/trunk poldi If you'd prefer to have a tarball, let me know. Thanks for your report, Moritz -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : /pipermail/attachments/20060401/4bb279d7/attachment.pgp From wk at gnupg.org Mon Apr 3 14:13:15 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Apr 3 14:31:46 2006 Subject: [Announce] GnuPG 1.4.3 released Message-ID: <87lkum26xw.fsf@wheatstone.g10code.de> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From jas at extundo.com Mon Apr 3 16:05:34 2006 From: jas at extundo.com (Simon Josefsson) Date: Mon Apr 3 17:56:21 2006 Subject: [Announce] GnuPG 1.4.3 released In-Reply-To: <87lkum26xw.fsf__47209.2294520282$1144067643$gmane$org@wheatstone.g10code.de> (Werner Koch's message of "Mon, 03 Apr 2006 14:13:15 +0200") References: <87lkum26xw.fsf__47209.2294520282$1144067643$gmane$org@wheatstone.g10code.de> Message-ID: <87wte669g1.fsf@latte.josefsson.org> Werner Koch writes: > * Able to retrieve keys using DNS CERT records as per RFC-2538bis > (currently in draft): http://www.josefsson.org/rfc2538bis Very cool! Btw, the document has now been published as RFC 4398: http://www.ietf.org/rfc/rfc4398.txt Regards, Simon From mtaghiloo at gmail.com Tue Apr 4 12:49:46 2006 From: mtaghiloo at gmail.com (majid taghiloo) Date: Tue Apr 4 14:26:11 2006 Subject: add algorithms to GnuPG Message-ID: <3742210.post@talk.nabble.com> dear all i like to add my custom algorithms to GnuPG source code. what canni do? -- View this message in context: http://www.nabble.com/add-algorithms-to-GnuPG-t1392337.html#a3742210 Sent from the GnuPG - Dev forum at Nabble.com. From rjh at sixdemonbag.org Tue Apr 4 15:24:21 2006 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue Apr 4 15:23:27 2006 Subject: add algorithms to GnuPG In-Reply-To: <3742210.post@talk.nabble.com> References: <3742210.post@talk.nabble.com> Message-ID: <44327385.207@sixdemonbag.org> majid taghiloo wrote: > i like to add my custom algorithms to GnuPG source code. what canni do? Looking at the idea.c source code (available on the main www.gnupg.org site) should give you a pretty good trail of breadcrumbs for how to write your own extension module. I would recommend that this is not something for a novice programmer to undertake. Please ignore me if you're an old hand to C, though. :) From jeroen at unfix.org Tue Apr 4 14:24:18 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Tue Apr 4 15:56:18 2006 Subject: Automatic key verification / CERT in DNS / RFC4398 (Was: [Announce] GnuPG 1.4.3 released) In-Reply-To: <87lkum26xw.fsf@wheatstone.g10code.de> References: <87lkum26xw.fsf@wheatstone.g10code.de> Message-ID: <1144153458.10586.54.camel@firenze.zurich.ibm.com> [Cross-post-reply to most-likely interrested parties... strip where needed] On Mon, 2006-04-03 at 14:13 +0200, Werner Koch wrote: > We are pleased to announce the availability of a new stable GnuPG > release: Version 1.4.3 Neat ;) Muchos thanks to all the developers for their work! > * Implemented Public Key Association (PKA) signature verification. [..] > * New auto-key-locate option that takes an ordered list of methods > to locate a key if it is not available at encryption time (-r or > --recipient). Possible methods include "cert" (use DNS CERT as > per RFC2538bis, "pka" (use DNS PKA), "ldap" (consult the LDAP > server for the domain in question), "keyserver" (use the > currently defined keyserver), as well as arbitrary keyserver > URIs that will be contacted for the key. > > * Able to retrieve keys using DNS CERT records as per RFC-2538bis > (currently in draft): http://www.josefsson.org/rfc2538bis These three lead to one big question though: Can we start doing automatic key verification for mail !? It would be really good if there would now come a draft which will propose the standard order of getting a key, when one doesn't have it or wants to get it again. This release of GnuPG allows one to already specify it. It would be really good if this was standardized and also implemented. Especially in combination with a domain policy (which could be incorporated in say SPF). Thus, eg I mail from jeroen@unfix.org, one can lookup _policy.unfix.org, which will say "mail:PGP:required" or something similar. SMTP clients/servers receiving mail signed by me, can then use one, or more, of the key retrieval techniques to fetch the key. PKA + Cert become very good for this and thus allow automatic verification. When the mail is not signed or falsely signed, one can discard the message based on the policy. For ease of deployment SMTP gateways, which receive mails from authenticated (IP or user/pass etc based) can auto-sign unsigned email with a generic 'automatic' key. Existing clients won't thus be affected, unless they don't use the ISP's SMTP gateway. If they want to avoid using the ISP's gateway, they need to have their key in DNS though. This all though leads to a concern on the placing of the CERTS. Having a large user base would mean that one has say 600k records or more in the main zone for a domain, which gets reloaded every now and then when one needs to update it. It would IMHO be better to be able to off load those records to say _cert.example.org. Which has several benefits, one can then run their normal DNS adminstration and delegate the CERT records to a dedicated DNS server set which can handle the updates easier or simply runs out of a DNSBackend. This will also be easier management wise with DNSSEC I expect and remove the strain from the main boxes, which currently might have maybe upto 100 RR's on average in a zone, especially in the case of webhosting farms where one only specifies the www.example.org and nothing else. Of course this will also require a lot of software to make it working, but this is going in the right direction! :) Greets, Jeroen (Who sees this way as one of the better ways of killing of forged mail, bounces etc...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 315 bytes Desc: This is a digitally signed message part Url : /pipermail/attachments/20060404/81ba7c17/attachment-0001.pgp From julian at mehnle.net Tue Apr 4 15:37:35 2006 From: julian at mehnle.net (Julian Mehnle) Date: Tue Apr 4 16:56:28 2006 Subject: Automatic key verification / CERT in DNS / RFC4398 In-Reply-To: <1144153458.10586.54.camel@firenze.zurich.ibm.com> References: <87lkum26xw.fsf@wheatstone.g10code.de> <1144153458.10586.54.camel@firenze.zurich.ibm.com> Message-ID: <200604041337.36747.julian@mehnle.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeroen Massar wrote: > [GnuPG 1.4.3 / Public Key Association (PKA) / CERT in DNS / RFC 4398] > Can we start doing automatic key verification for mail !? > > It would be really good if there would now come a draft which will > propose the standard order of getting a key, when one doesn't have it or > wants to get it again. This release of GnuPG allows one to already > specify it. It would be really good if this was standardized and also > implemented. Especially in combination with a domain policy (which could > be incorporated in say SPF). Indeed the SPF project has plans to introduce another revision of the SPF protocol, now that SPFv1 (v=spf1) will be out as an IETF RFC within the next few weeks. While v=spf1 only supports IP-address-based authenti- cation of the envelope sender, the idea has long been for SPF to be much more than that, i.e. to be a "Sender Policy Framework" allowing domain owners to specify a wide range of policies, covering non-envelope (RFC 2822) identities and authentication methods like DKIM, PGP, and S/MIME. The rough timeline could be for that revision to be released sometime in Q3/2006 to Q1/2007, depending on the feature set chosen (which is still open to debate). > Thus, eg I mail from jeroen@unfix.org, one can lookup _policy.unfix.org, > which will say "mail:PGP:required" or something similar. SMTP > clients/servers receiving mail signed by me, can then use one, or more, > of the key retrieval techniques to fetch the key. PKA + Cert become very > good for this and thus allow automatic verification. When the mail is > not signed or falsely signed, one can discard the message based on the > policy. > [...] > This all though leads to a concern on the placing of the CERTS. Having a > large user base would mean that one has say 600k records or more in the > main zone for a domain, which gets reloaded every now and then when one > needs to update it. It would IMHO be better to be able to off load those > records to say _cert.example.org. [...] While for v=spf1 mostly TXT RRs are used in practice, SPF has been assigned a dedicated "SPF" RR type (code 99), which is already being used (queried) by a few implementations. Also, SPF's macro feature would be useful for specifying custom DNS zone layouts for where to search for key records. (Are there ones besides CERT/RFC2538/RFC4398?) What do folks -- especially the gnupg-devel ones -- think about using SPF for that purpose? Are there any non-obvious fundamental issues that need to be taken into account? Julian. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEMnagwL7PKlBZWjsRAqKmAKDbwBS6mMeL5iTJXs6hruyVg7wHqACeMyVg nP5IOM8KGtZE8+v9P9Jdj+s= =IowF -----END PGP SIGNATURE----- From julian at mehnle.net Tue Apr 4 15:37:35 2006 From: julian at mehnle.net (Julian Mehnle) Date: Tue Apr 4 16:56:38 2006 Subject: Automatic key verification / CERT in DNS / RFC4398 In-Reply-To: <1144153458.10586.54.camel@firenze.zurich.ibm.com> References: <87lkum26xw.fsf@wheatstone.g10code.de> <1144153458.10586.54.camel@firenze.zurich.ibm.com> Message-ID: <200604041337.36747.julian@mehnle.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeroen Massar wrote: > [GnuPG 1.4.3 / Public Key Association (PKA) / CERT in DNS / RFC 4398] > Can we start doing automatic key verification for mail !? > > It would be really good if there would now come a draft which will > propose the standard order of getting a key, when one doesn't have it or > wants to get it again. This release of GnuPG allows one to already > specify it. It would be really good if this was standardized and also > implemented. Especially in combination with a domain policy (which could > be incorporated in say SPF). Indeed the SPF project has plans to introduce another revision of the SPF protocol, now that SPFv1 (v=spf1) will be out as an IETF RFC within the next few weeks. While v=spf1 only supports IP-address-based authenti- cation of the envelope sender, the idea has long been for SPF to be much more than that, i.e. to be a "Sender Policy Framework" allowing domain owners to specify a wide range of policies, covering non-envelope (RFC 2822) identities and authentication methods like DKIM, PGP, and S/MIME. The rough timeline could be for that revision to be released sometime in Q3/2006 to Q1/2007, depending on the feature set chosen (which is still open to debate). > Thus, eg I mail from jeroen@unfix.org, one can lookup _policy.unfix.org, > which will say "mail:PGP:required" or something similar. SMTP > clients/servers receiving mail signed by me, can then use one, or more, > of the key retrieval techniques to fetch the key. PKA + Cert become very > good for this and thus allow automatic verification. When the mail is > not signed or falsely signed, one can discard the message based on the > policy. > [...] > This all though leads to a concern on the placing of the CERTS. Having a > large user base would mean that one has say 600k records or more in the > main zone for a domain, which gets reloaded every now and then when one > needs to update it. It would IMHO be better to be able to off load those > records to say _cert.example.org. [...] While for v=spf1 mostly TXT RRs are used in practice, SPF has been assigned a dedicated "SPF" RR type (code 99), which is already being used (queried) by a few implementations. Also, SPF's macro feature would be useful for specifying custom DNS zone layouts for where to search for key records. (Are there ones besides CERT/RFC2538/RFC4398?) What do folks -- especially the gnupg-devel ones -- think about using SPF for that purpose? Are there any non-obvious fundamental issues that need to be taken into account? Julian. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEMnagwL7PKlBZWjsRAqKmAKDbwBS6mMeL5iTJXs6hruyVg7wHqACeMyVg nP5IOM8KGtZE8+v9P9Jdj+s= =IowF -----END PGP SIGNATURE----- From brad at stop.mail-abuse.org Wed Apr 5 09:17:43 2006 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Wed Apr 5 11:28:01 2006 Subject: Fwd: Automatic key verification / CERT in DNS / RFC4398 (Was: [Announce] GnuPG 1.4.3 released) In-Reply-To: <44332B60.5080006@ntp.isc.org> References: <44332B60.5080006@ntp.isc.org> Message-ID: At 10:28 PM -0400 2006-04-04, Danny Mayer wrote: > These three lead to one big question though: > Can we start doing automatic key verification for mail !? See DKIM. > This all though leads to a concern on the placing of the CERTS. Having a > large user base would mean that one has say 600k records or more in the > main zone for a domain, which gets reloaded every now and then when one > needs to update it. Think about ten million users, or fifty million. Each user having several hundred bytes (or even several KB) of data stored for them. Stored in the DNS. In a single flat zone. Bad idea. Like, really bad idea. Like, one of the worst DNS-related ideas I think I've ever heard of, at least in a very long time. And it shares most of the same problems in this respect with DKIM, if you try to push DKIM to process data at the individual level as opposed to the domain level. Very highly non-scalable. > Of course this will also require a lot of software to make it working, > but this is going in the right direction! :) Possibly, but I'm not convinced. There's lots of scalability issues that need to be given some serious thought before you just leap into the fray and start spraying about large DNS records for each user, regardless of any other factors that are involved. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See . From wk at gnupg.org Wed Apr 5 11:50:27 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Apr 5 11:56:47 2006 Subject: Automatic key verification / CERT in DNS / RFC4398 In-Reply-To: <1144153458.10586.54.camel@firenze.zurich.ibm.com> (Jeroen Massar's message of "Tue, 04 Apr 2006 14:24:18 +0200") References: <87lkum26xw.fsf@wheatstone.g10code.de> <1144153458.10586.54.camel@firenze.zurich.ibm.com> Message-ID: <87d5fwjqqk.fsf@wheatstone.g10code.de> On Tue, 04 Apr 2006 14:24:18 +0200, Jeroen Massar said: > This all though leads to a concern on the placing of the CERTS. Having a That is not really a question. The new DNS based certificate (well, keyblock) capability of gpg is independent of the PKA system. Keys may still be stored on key servers (which are much better now than in the past) or on web pages or whereever one wants. Actually you can starting deploying such a system right now if you do it at the MTA and use just a key per domain. This will allow better verification of mails from potential phishing targets. Shalom-Salam, Werner From wk at gnupg.org Wed Apr 5 12:30:54 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Apr 5 12:36:52 2006 Subject: Fwd: Automatic key verification / CERT in DNS / RFC4398 In-Reply-To: (Brad Knowles's message of "Wed, 5 Apr 2006 02:17:43 -0500") References: <44332B60.5080006@ntp.isc.org> Message-ID: <878xqkjov5.fsf@wheatstone.g10code.de> On Wed, 5 Apr 2006 02:17:43 -0500, Brad Knowles said: >> Can we start doing automatic key verification for mail !? > See DKIM. DKIM just doesn't work - at least not as described in the I-D I am aware of. The canonicalization rules needed for MIME are broken and may be used to inject a faked message within a DKIM signed one. The recipient (or MTA) will see that the mail verified okay but the actual content shown is the faked one. See Thomas Roessler's "noswp considred harmful"[1]. > And it shares most of the same problems in this respect with > DKIM, if you try to push DKIM to process data at the individual level > as opposed to the domain level. > Very highly non-scalable. I doubt that. A PKA record like "v=pka1;fpr=A4D94E92B0986AB5EE9DCD755DE249965B0358A2" can be squeezed into less that 32 bytes with a dedicated RR type. If you don't want to use general keyservers, add the space for an URL. The latter may even be optimized by extending the system to define URL shortcuts like looking up the default key distribution method of the domain (e.g. by using HTTP). And don't forget that an URL in the PKA record has the additional benefit of allowing for opportunistic encryption. Salam-Shalom, Werner [1] http://www.mhonarc.org/archive/cgi-bin/mesg.cgi?a=ietf-mailsig&i=20050720080547.GA8239%40raktajino.does-not-exist.org From jeroen at unfix.org Wed Apr 5 13:57:03 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Wed Apr 5 13:56:31 2006 Subject: Automatic key verification / CERT in DNS / RFC4398 (Was: [Announce] GnuPG 1.4.3 released) In-Reply-To: References: <44332B60.5080006@ntp.isc.org> Message-ID: <1144238223.17442.20.camel@firenze.zurich.ibm.com> On Wed, 2006-04-05 at 02:17 -0500, Brad Knowles wrote: > At 10:28 PM -0400 2006-04-04, Danny Mayer wrote: > > > These three lead to one big question though: > > Can we start doing automatic key verification for mail !? > > See DKIM. Which is not there yet and will take the coming X years to be designed, developed and deployed. While PGP is working already for several years and has been proven to work very reliably. > > This all though leads to a concern on the placing of the CERTS. Having a > > large user base would mean that one has say 600k records or more in the > > main zone for a domain, which gets reloaded every now and then when one > > needs to update it. > > Think about ten million users, or fifty million. Each user > having several hundred bytes (or even several KB) of data stored for > them. Stored in the DNS. In a single flat zone. Bad idea. Like, > really bad idea. Like, one of the worst DNS-related ideas I think > I've ever heard of, at least in a very long time. Checking http://dailychanges.com/ status of domains on 4/4/2006: 49,340,982 .com 7,425,723 .net etc. so what was the issue again of storing a couple of million records in DNS? If you claim it is a 'bad idea' then why does the CERT record exist at all when it has the intentions of allowing PGP keys to be stored? ;) Using for instance nsd (http://www.nlnetlabs.nl/nsd/) should not pose a problem in serving these amounts of contents. It is more a 'separation' question I am asking, so that one has a subzone for these records, which will allow one to have say 3 nameservers, which are registered at the tld servers thus can't easily be changed, for example.org but have 20, which you stuff in example.org, handling the load for _certs.example.org where the CERTS are stored. It's a choice item giving the possility of doing it. > And it shares most of the same problems in this respect with > DKIM, if you try to push DKIM to process data at the individual level > as opposed to the domain level. > > Very highly non-scalable. See below and also in my original message... > > Of course this will also require a lot of software to make it working, > > but this is going in the right direction! :) > > Possibly, but I'm not convinced. There's lots of scalability > issues that need to be given some serious thought before you just > leap into the fray and start spraying about large DNS records for > each user, regardless of any other factors that are involved. Which is why I noted that one could have a single pgp key for a complete domain could cover all the cases where one doesn't have the enduser signing the messages but a central system doing it for them. Which is in effect what DKIM does but allowing the freedom to have per-user keys too. Eg large sites like hotmail/gmail/yahoo/whatever could have a 'websign key' where the outbound webengine signs the message for the user. Presto, 60M users served with one key. This situation is the case for a large percentage of the ISP's around the globe, especially as they should be 'forcing' their clients to send outbound mail over their SMTP gateways (using submit :) instead of using the one which is acting like an open relay. And the good parts: - this can work today - MTA or MUA only have to do a PGP verification of the message - very easy to deploy and setup - no transition needed, just deploy at the ISP and it works. of course many/all sites have to participate otherwise it doesn't have much effect, though one could say "drop/bounce anything not signed" at a certain point. I don't care if we go for PKA or CERT records as long as the silly spoofing of source addresses gets halted. Spam and virusses are easily discarded using things like SpamAsssassin and ClamAV etc, but bounces might be legit so one still gets those and lots of them from all the virusses and spams spoofing your email address toward non-existent addresses or folks with auto-replies etc. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 315 bytes Desc: This is a digitally signed message part Url : /pipermail/attachments/20060405/bc814cbb/attachment.pgp From wk at gnupg.org Wed Apr 5 14:44:28 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Apr 5 14:46:51 2006 Subject: Automatic key verification / CERT in DNS / RFC4398 In-Reply-To: <200604041337.36747.julian@mehnle.net> (Julian Mehnle's message of "Tue, 4 Apr 2006 13:37:35 +0000") References: <87lkum26xw.fsf@wheatstone.g10code.de> <1144153458.10586.54.camel@firenze.zurich.ibm.com> <200604041337.36747.julian@mehnle.net> Message-ID: <87fyksi443.fsf@wheatstone.g10code.de> On Tue, 4 Apr 2006 13:37:35 +0000, Julian Mehnle said: > What do folks -- especially the gnupg-devel ones -- think about using SPF > for that purpose? Are there any non-obvious fundamental issues that need > to be taken into account? I consider SPF far to complex to solve the simple goal of authenticating the source of an email. It does not stop spam , as this requires content filters and the jurisdiction and won't authenmticate the full message. Agreed, neither OpenPGP nor S/MIME will authenticate the header (e.g. the Subject) but there are easy ways to do this within the existing framework: Just wrap the entire message into a message/rfc822 container and sign it. A MUA may then properly indicate what has been signed. The goal of PKA is much simpler: Authenticate the From: header and allow the MUA or MTA to detected spoofed messages this way. The ability to do an opportunistic encryption using the PKA framework is just a very welcome side-effect. Shalom-Salam, Werner From julian at mehnle.net Wed Apr 5 15:26:37 2006 From: julian at mehnle.net (Julian Mehnle) Date: Wed Apr 5 15:25:51 2006 Subject: Automatic key verification / CERT in DNS / RFC4398 In-Reply-To: <87fyksi443.fsf@wheatstone.g10code.de> References: <87lkum26xw.fsf@wheatstone.g10code.de> <200604041337.36747.julian@mehnle.net> <87fyksi443.fsf@wheatstone.g10code.de> Message-ID: <200604051326.38720.julian@mehnle.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Werner Koch wrote: > On Tue, 4 Apr 2006 13:37:35 +0000, Julian Mehnle said: > > What do folks -- especially the gnupg-devel ones -- think about using > > SPF for that purpose? Are there any non-obvious fundamental issues > > that need to be taken into account? > > I consider SPF far to complex to solve the simple goal of > authenticating the source of an email. It does not stop spam, as > this requires content filters and the jurisdiction and won't > authenmticate the full message. Let me say this in advance: I do NOT want to start a lengthy discussion across several mailing lists about that. But I think there are a few misconceptions to be clarified: SPF does not aim to stop spam, it aims to stop forgery -- not necessarily by directly doing the authentication itself (SPFv1 cares about the envelope sender only, the next revision aims to do more than that). In particular, SPF does NOT aim to replace DKIM or PGP, but to complement them by giving domain owners the means to publicly specify their mail sending policies in a standardized way. (BTW, if you think SPF is "too complex", then you should take into account that the SPFv1 spec is over 40 pages long only because it already includes lots of lessons learned, security considerations, and other non-authorita- tive stuff.) > The goal of PKA is much simpler: Authenticate the From: header and > allow the MUA or MTA to detected spoofed messages this way. > > The ability to do an opportunistic encryption using the PKA framework > is just a very welcome side-effect. It is exactly that side-effect of opportunistic encryption that SPF aims to support. Is that support (i.e. the standardized means to publicly specify your sending/signing policy) not something worth to be considered? If you think that PKA already does the part _you_ want, then you may be missing the fact that not every sender may choose PGP+PKA as their authentication method, and that receivers may not want to check _all_ the methods out there for a given message until they find one that actually authenticates the message. SPF could act as an arbitrator for the various existing authentication methods. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEM8WOwL7PKlBZWjsRArGYAJ404uYC5ifZyJCTP6ZvvVHnPP56iQCeNDTr Q1JErdzYRDbDM9I0ya/6cNU= =i1jf -----END PGP SIGNATURE----- From julian at mehnle.net Wed Apr 5 15:38:31 2006 From: julian at mehnle.net (Julian Mehnle) Date: Wed Apr 5 15:37:38 2006 Subject: Automatic key verification / CERT in DNS / RFC4398 In-Reply-To: <200604051326.38720.julian@mehnle.net> References: <87lkum26xw.fsf@wheatstone.g10code.de> <87fyksi443.fsf@wheatstone.g10code.de> <200604051326.38720.julian@mehnle.net> Message-ID: <200604051338.32759.julian@mehnle.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Julian Mehnle wrote: > Werner Koch wrote: > > The goal of PKA is much simpler: Authenticate the From: header and > > allow the MUA or MTA to detected spoofed messages this way. > > > > The ability to do an opportunistic encryption using the PKA framework > > is just a very welcome side-effect. > > It is exactly that side-effect of opportunistic encryption that SPF aims > to support. Oops, please read that as "opportunistic authentication". But that's not all that different. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEM8hYwL7PKlBZWjsRAn9YAKCIsQPyGnlsU9OSh5T4MNpWpMonhQCfeOGx hnjEHXKVpAS8emYIiUvT+4c= =Gkh2 -----END PGP SIGNATURE----- From jeroen at unfix.org Wed Apr 5 19:13:42 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Wed Apr 5 19:13:22 2006 Subject: Automatic key verification / CERT in DNS / RFC4398 (Was: [Announce] GnuPG 1.4.3 released) In-Reply-To: <6.2.5.6.2.20060405105049.03424d70@ogud.com> References: <44332B60.5080006@ntp.isc.org> <1144238223.17442.20.camel@firenze.zurich.ibm.com> <6.2.5.6.2.20060405105049.03424d70@ogud.com> Message-ID: <1144257222.18780.4.camel@firenze.zurich.ibm.com> On Wed, 2006-04-05 at 10:58 -0400, ?lafur Gu?mundsson /DNSEXT co-chair wrote: > At 07:57 05/04/2006, Jeroen Massar wrote: > >On Wed, 2006-04-05 at 02:17 -0500, Brad Knowles wrote: > > > At 10:28 PM -0400 2006-04-04, Danny Mayer wrote: > > Please remove namedroppers from future postings on this tread. > I'm not approving any messages as the discussion is about possible > DNS operational issues, not DNS protocol issues. The discussion which led from it is indeed, but my original question, though at the bottom of the mail was: 8<-------------------------------------------- This all though leads to a concern on the placing of the CERTS. Having a large user base would mean that one has say 600k records or more in the main zone for a domain, which gets reloaded every now and then when one needs to update it. It would IMHO be better to be able to off load those records to say _cert.example.org. Which has several benefits, one can then run their normal DNS adminstration and delegate the CERT records to a dedicated DNS server set which can handle the updates easier or simply runs out of a DNSBackend. This will also be easier management wise with DNSSEC I expect and remove the strain from the main boxes, which currently might have maybe upto 100 RR's on average in a zone, especially in the case of webhosting farms where one only specifies the www.example.org and nothing else. ------------------------------------------->8 Altough this is also more or less an operational question, the question is very related to dnsext as the CERT record has been defined here and RFC4398 defines that person CERT's can be found under .example.org. This was the point I wanted to clear up, that, indeed for ops purposes, one rather have a subzone. This is again a protocol related thing as when one sticks all the CERTs in the main zone, this will grow and you will have to take into account keyrotation for DNSSEC... If I am totally of base, then simply drop the discussion of course. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 315 bytes Desc: This is a digitally signed message part Url : /pipermail/attachments/20060405/de4e2de7/attachment.pgp From brad at stop.mail-abuse.org Thu Apr 6 03:03:36 2006 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Thu Apr 6 03:15:22 2006 Subject: Fwd: Automatic key verification / CERT in DNS / RFC4398 In-Reply-To: <878xqkjov5.fsf@wheatstone.g10code.de> References: <44332B60.5080006@ntp.isc.org> <878xqkjov5.fsf@wheatstone.g10code.de> Message-ID: At 12:30 PM +0200 2006-04-05, Werner Koch wrote: > DKIM just doesn't work - at least not as described in the I-D I am > aware of. The canonicalization rules needed for MIME are broken and > may be used to inject a faked message within a DKIM signed one. The > recipient (or MTA) will see that the mail verified okay but the actual > content shown is the faked one. See Thomas Roessler's "noswp > considred harmful"[1]. I haven't looked that closely into DKIM, but I'll take you at your word with regard to the weaknesses you describe. However, this doesn't mean that these weaknesses can't be fixed. The problems I'm concerned about with DKIM do not appear to be fixable, at least not if you're doing it at an individual level as opposed to the domain. >> Very highly non-scalable. > > I doubt that. A PKA record like > > "v=pka1;fpr=A4D94E92B0986AB5EE9DCD755DE249965B0358A2" > > can be squeezed into less that 32 bytes with a dedicated RR type. Yeah, but that's probably 31.999999999999999999999999999 more bytes than you're storing in the DNS today (per user), and with tens of millions of users in a single flat zone, all that adds up really fast. > If > you don't want to use general keyservers, add the space for an URL. > The latter may even be optimized by extending the system to define URL > shortcuts like looking up the default key distribution method of the > domain (e.g. by using HTTP). If you can take all the keys out of the DNS and put them into something like a customized web server (with maybe one key in the DNS for the entire domain to tell everyone how to access that web server), then we've exchanged DNS server scalability (a subject I have some familiarity with and something I care a great deal about) for web server scalability (something I know less about, and which I care a lot less about). -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See . From brad at stop.mail-abuse.org Thu Apr 6 03:03:46 2006 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Thu Apr 6 04:12:07 2006 Subject: Automatic key verification / CERT in DNS / RFC4398 (Was: [Announce] GnuPG 1.4.3 released) In-Reply-To: <1144238223.17442.20.camel@firenze.zurich.ibm.com> References: <44332B60.5080006@ntp.isc.org> <1144238223.17442.20.camel@firenze.zurich.ibm.com> Message-ID: At 1:57 PM +0200 2006-04-05, Jeroen Massar wrote: >> See DKIM. > > Which is not there yet and will take the coming X years to be designed, > developed and deployed. While PGP is working already for several years > and has been proven to work very reliably. Yeah, but you're talking about inventing new protocol parts to fit into the overall PGP/GPG structure, and which will likewise take years to be designed, developed, and deployed in a standards-compliant manner. Keep in mind that relatively few people use any kind of personal encryption at all, and most that do make use of S/MIME instead of PGP or GPG, because S/MIME is what is provided by default from Microsoft and Netscape/Mozilla. You're an anthill right now, and you've got to become a mountain before your proposal can start having any kind of measurable positive impact on the Internet community. Assuming you get there at all, it's going to take you a while. >> Think about ten million users, or fifty million. Each user >> having several hundred bytes (or even several KB) of data stored for >> them. Stored in the DNS. In a single flat zone. Bad idea. Like, >> really bad idea. Like, one of the worst DNS-related ideas I think >> I've ever heard of, at least in a very long time. > > Checking http://dailychanges.com/ status of domains on 4/4/2006: > 49,340,982 .com > 7,425,723 .net > > etc. so what was the issue again of storing a couple of million records > in DNS? Yeah, but those records don't change frequently, and most of those zones have relatively little information in them, and you're not trying to store a complete copy of all 49 million plus .com zones within the .com gTLD servers themselves. Try loading all 49+ million .com zones onto the same thirteen .com gTLD servers, and see what happens. Now, have each of those .com sub-zones publish DNSSEC crypto records, all of which also has to be contained in the same single flat .com zone. I don't think there's a nameserver farm anywhere in the world that could handle that kind of load or those kinds of memory requirements. > If you claim it is a 'bad idea' then why does the CERT record > exist at all when it has the intentions of allowing PGP keys to be > stored? ;) > > Using for instance nsd (http://www.nlnetlabs.nl/nsd/) should not pose a > problem in serving these amounts of contents. I'm familiar with NSD. It is very fast, but also quite memory intensive. There were some interesting reports at RIPE from the folks responsible for SUNET, which is secondary to some of the largest ccTLD zones in the world, and how they were unable to fit all the necessary data into very large quantities of memory on their server (something like 64GB of RAM?). Do you know of any machines that can have terabytes of RAM available to store that much data? Hundreds of GB of data stored on disk for serving up crypto keys for millions of users is not that much of a problem. Okay, you're going to want some pretty beefy web servers with lots of RAM for caching, but you're never going to attempt to fit all that data into memory. That's not the way that most nameservers work. Most nameservers (NSD especially) store all data in RAM, and when you're talking about relatively large crypto keys for each user in a group of tens of millions of users, that is highly non-scalable. Yes, there are database-backend nameservers, but unless you're going to pay some pretty big bucks for the Nominum software, they're relatively non-standard and relatively unknown. And no one knows how even the best database-backend nameservers are going to handle data on these kinds of scales. > It is more a 'separation' question I am asking, so that one has a > subzone for these records, which will allow one to have say 3 > nameservers, which are registered at the tld servers thus can't easily > be changed, for example.org but have 20, which you stuff in example.org, > handling the load for _certs.example.org where the CERTS are stored. > It's a choice item giving the possility of doing it. Flat databases don't scale. We know this. This is why we no longer use HOSTS.TXT, but instead use the hierarchical DNS. Either find a way to do this kind of work in a hierarchy (so that the load can be spread out amongst many servers), or change the protocol used to store the data so that you're not trying to keep it all in RAM. > Which is why I noted that one could have a single pgp key for a complete > domain could cover all the cases where one doesn't have the enduser > signing the messages but a central system doing it for them. Which is in > effect what DKIM does but allowing the freedom to have per-user keys > too. So long as you stick to just one key for the entire domain, it doesn't matter if it's DKIM or PGP. It still has some greatly increased CPU requirements (because every single message passing through the server will now have to be cryptographically signed, which will increase the CPU server load by many orders of magnitude per message), but at least it has the possibility of being scalable in terms of the amount of key data that has to be stored and accessed on a frequent basis. > Eg large sites like hotmail/gmail/yahoo/whatever could have a 'websign > key' where the outbound webengine signs the message for the user. > Presto, 60M users served with one key. I have yet to be convinced that cryptographically signing each and every message that passes through the server can be scalable in any common sense of the word, but at least that's a different problem which might be addressable through custom hardware. We did try this technique before -- it was called pgpsendmail, and it cryptographically signed every message passing through the system. It didn't work very well, and few people ended up using it. I don't think that using this same concept all over again is likely to work any better this time than it did last time. But if you've got some new magic oil that could be applied to the process and instantly solve the problem, I'd be interested in hearing about it. Doing client-side signing and verification is definitely scalable, but is difficult to get jump-started. > I don't care if we go for PKA or CERT records as long as the silly > spoofing of source addresses gets halted. I don't think that's likely to happen any time soon. The solutions which are easy to implement are non-scalable, and the scalable solutions are much more difficult to implement. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See . From bernhard at intevation.de Wed Apr 5 12:36:21 2006 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu Apr 6 11:38:33 2006 Subject: Revision: 4091, make check failure Message-ID: <20060405103621.GA19938@intevation.de> Debian Sarge Revision: 4091 make[2]: Entering directory `/opt/kolab-client-build/kde3.3+proko2+aegypten2/svn-anon/gnupg19/tests' asschk: read_assuan: received incomplete line on fd 7 FAIL: sm-sign+verify asschk: read_assuan: received incomplete line on fd 5 FAIL: sm-verify ====================================== 2 of 2 tests failed Please report to gnupg-devel@gnupg.org ====================================== make[2]: *** [check-TESTS] Fehler 1 ps.: copy me on relevant replies. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20060405/c4c37207/attachment-0001.pgp From alex at ergens.op.het.net Wed Apr 5 15:15:21 2006 From: alex at ergens.op.het.net (Alex van den Bogaerdt) Date: Thu Apr 6 11:38:36 2006 Subject: [spf-discuss] Re: Automatic key verification / CERT in DNS / RFC4398 In-Reply-To: <87fyksi443.fsf@wheatstone.g10code.de> References: <87lkum26xw.fsf@wheatstone.g10code.de> <1144153458.10586.54.camel@firenze.zurich.ibm.com> <200604041337.36747.julian@mehnle.net> <87fyksi443.fsf@wheatstone.g10code.de> Message-ID: <20060405131521.GN7275@ergens.op.het.net> On Wed, Apr 05, 2006 at 02:44:28PM +0200, Werner Koch wrote: > On Tue, 4 Apr 2006 13:37:35 +0000, Julian Mehnle said: > > > What do folks -- especially the gnupg-devel ones -- think about using SPF > > for that purpose? Are there any non-obvious fundamental issues that need > > to be taken into account? > > I consider SPF far to complex to solve the simple goal of > authenticating the source of an email. It does not stop spam , as > this requires content filters and the jurisdiction and won't > authenmticate the full message. And indeed: spf does not authenticate the source of an email, neither is the intention to stop spam (although that is a nice side effect). SPF authorizes relays of an email, and is intended to stop spoofing. However, SPF could assist other technologies. It could communicate to the receiver that certain mail should be GPG signed, where the key can be fetched, etc. Alex From paul at vix.com Wed Apr 5 19:19:46 2006 From: paul at vix.com (Paul Vixie) Date: Thu Apr 6 11:38:38 2006 Subject: Automatic key verification / CERT in DNS / RFC4398 (Was: [Announce] GnuPG 1.4.3 released) In-Reply-To: Your message of "Wed, 05 Apr 2006 10:58:41 -0400." <6.2.5.6.2.20060405105049.03424d70@ogud.com> References: <44332B60.5080006@ntp.isc.org> <1144238223.17442.20.camel@firenze.zurich.ibm.com> <6.2.5.6.2.20060405105049.03424d70@ogud.com> Message-ID: <42466.1144257586@sa.vix.com> also note that dns operational issues are welcome on dns-operations@lists.oarci.net, which is a mailman-run list whose url is lists.oarci.net/mailman/listinfo/. re: > Please remove namedroppers from future postings on this tread. > I'm not approving any messages as the discussion is about possible > DNS operational issues, not DNS protocol issues. From scott at kitterman.com Thu Apr 6 03:02:24 2006 From: scott at kitterman.com (Scott Kitterman) Date: Thu Apr 6 11:38:40 2006 Subject: Automatic key verification / CERT in DNS / RFC4398 In-Reply-To: <87d5fwjqqk.fsf@wheatstone.g10code.de> References: <87lkum26xw.fsf@wheatstone.g10code.de> <1144153458.10586.54.camel@firenze.zurich.ibm.com> <87d5fwjqqk.fsf@wheatstone.g10code.de> Message-ID: <200604052102.24169.scott@kitterman.com> On 04/05/2006 05:50, Werner Koch wrote: > On Tue, 04 Apr 2006 14:24:18 +0200, Jeroen Massar said: > > This all though leads to a concern on the placing of the CERTS. Having a > > That is not really a question. The new DNS based certificate (well, > keyblock) capability of gpg is independent of the PKA system. Keys > may still be stored on key servers (which are much better now than in > the past) or on web pages or whereever one wants. > > Actually you can starting deploying such a system right now if you do > it at the MTA and use just a key per domain. This will allow better > verification of mails from potential phishing targets. > > That's true. What I think is envisioned for a linkage from SPF is some indication of whether to expect messages to be signed. The idea we are exploring is to, in a new version of SPF, really take on the idea inherent in the name, Sender Policy Framework and offer a method for domains to describe their sending practices. Relative to GPG signing, I can imagine that it might be useful to know that a domain signs all messages so that an unsigned message can automatically be deem to be suspicious, rejected, etc. Scott Kitterman From julian at mehnle.net Thu Apr 6 12:37:56 2006 From: julian at mehnle.net (Julian Mehnle) Date: Thu Apr 6 12:37:22 2006 Subject: Automatic key verification / CERT in DNS / RFC4398 In-Reply-To: References: <44332B60.5080006@ntp.isc.org> <1144238223.17442.20.camel@firenze.zurich.ibm.com> Message-ID: <200604061037.57378.julian@mehnle.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brad Knowles wrote: > Jeroen Massar wrote: > > It is more a 'separation' question I am asking, so that one has a > > subzone for these records, which will allow one to have say 3 > > nameservers, which are registered at the tld servers thus can't > > easily be changed, for example.org but have 20, which you stuff in > > example.org, handling the load for _certs.example.org where the CERTS > > are stored. It's a choice item giving the possility of doing it. > > Flat databases don't scale. We know this. This is why we no > longer use HOSTS.TXT, but instead use the hierarchical DNS. Not really. The real problem with HOSTS.TXT wasn't that it is flat, but that it is decentralized. Rsync'ing it from a central register might have been viable (though not very elegant). Thankfully we ended up with DNS anyway. > I have yet to be convinced that cryptographically signing each > and every message that passes through the server can be scalable in > any common sense of the word, but at least that's a different problem > which might be addressable through custom hardware. Signing each and every message may be slow, but slow doesn't imply unscalable. You can still use n times the MTAs and be n times faster. That scales very well, actually. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFENO+FwL7PKlBZWjsRArm4AJ9ZzTC7s3zKyE2AJoUBocAajAF20QCcCJsb B9jxuiOaIBkBx0AI3XYku7E= =sbK+ -----END PGP SIGNATURE----- From wk at gnupg.org Thu Apr 6 12:44:39 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Apr 6 12:46:55 2006 Subject: Automatic key verification / CERT in DNS / RFC4398 In-Reply-To: (Brad Knowles's message of "Wed, 5 Apr 2006 20:03:46 -0500") References: <44332B60.5080006@ntp.isc.org> <1144238223.17442.20.camel@firenze.zurich.ibm.com> Message-ID: <87lkujf0fc.fsf@wheatstone.g10code.de> On Wed, 5 Apr 2006 20:03:46 -0500, Brad Knowles said: > Keep in mind that relatively few people use any kind of personal > encryption at all, and most that do make use of S/MIME instead of PGP > or GPG, because S/MIME is what is provided by default from Microsoft The problem with S/MIME is that you can't create a usabable certificate for yourself. You have to hand over a lot of money to a more or less trustworthy CA with no real benefit. OpenPGP may be used much easier in that respect. Using PKA you may use self-signed certificates for S/MIME in the same way as you use PGP keys. Yes, the security is limited by the DNS but well, that is a problem another group needs so solve ;-) > So long as you stick to just one key for the entire domain, it > doesn't matter if it's DKIM or PGP. It still has some greatly > increased CPU requirements (because every single message passing > through the server will now have to be cryptographically signed, > which will increase the CPU server load by many orders of magnitude > per message), but at least it has the possibility of being scalable I doubt that signing a message puts more load on a server than all the spam filtering and virus scanning in use today. DKIM and other methods are also quite computing intensive. > We did try this technique before -- it was called pgpsendmail, > and it cryptographically signed every message passing through the > system. It didn't work very well, and few people ended up using it. Because the key distribution and validation of the keys was not solved. > Doing client-side signing and verification is definitely > scalable, but is difficult to get jump-started. Thus start with server-side signing using one key per domain. > I don't think that's likely to happen any time soon. The > solutions which are easy to implement are non-scalable, and the > scalable solutions are much more difficult to implement. DNSSEC does not scale? Okay, then DNS will eventually be useless. DNS-CERT does not scale? The I* types will help to offload the keys. PKA on a per user base does not scale? Well, this might be a problem with millions of users per domain. I don't know for sure but I doubt that, say, 64 extra bytes of user data makes any difference to these providers. Salam-Shalom, Werner From wk at gnupg.org Thu Apr 6 12:59:32 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Apr 6 13:01:52 2006 Subject: Fwd: Automatic key verification / CERT in DNS / RFC4398 In-Reply-To: (Brad Knowles's message of "Wed, 5 Apr 2006 20:03:36 -0500") References: <44332B60.5080006@ntp.isc.org> <878xqkjov5.fsf@wheatstone.g10code.de> Message-ID: <87hd57ezqj.fsf@wheatstone.g10code.de> On Wed, 5 Apr 2006 20:03:36 -0500, Brad Knowles said: > I haven't looked that closely into DKIM, but I'll take you at > your word with regard to the weaknesses you describe. However, this > doesn't mean that these weaknesses can't be fixed. Experience has shown that designing such a protocol is very hard. After about 8 years of OpenPGP the major problem new implementations have are the canonization rules. The are really simple with OpenPGP: trailing white space and line endings are the only things to care about. Still there are a lot of discussions about the edge cases. How checkout the rules for DKIM or, shudder, XMLSIG. They are really really complicate. Getting the protocol right and writing compatible implementations will be major untertaking. You won't see that the next 10 years. > Yeah, but that's probably 31.999999999999999999999999999 more > bytes than you're storing in the DNS today (per user), and with tens > of millions of users in a single flat zone, all that adds up really > fast. Please name another reliable directory service. LDAP is far too heavy and thus I believe DNS can be made workable for such goals much easier. Do you think splitting the zones up in say us.e.r._pka.example.net would be helpful? > for the entire domain to tell everyone how to access that web > server), then we've exchanged DNS server scalability (a subject I > have some familiarity with and something I care a great deal about) > for web server scalability (something I know less about, and which I And here we know that it works. Consider all the people using webmailers or POP3. No problem at all to serve millions of users. Shalom-Salam, Werner From smenzel at gmx-gmbh.de Thu Apr 6 11:58:37 2006 From: smenzel at gmx-gmbh.de (Stephan Menzel) Date: Thu Apr 6 13:26:16 2006 Subject: Problems using gpgsm Message-ID: <200604061158.45239.smenzel@gmx-gmbh.de> Hi there, I'm trying to use gpgme with gpgsm backend to verify signed S/MIME email. Progress is going well thanks to excellent gpgme docs, but I'm stuck now and I would need some help. Here's what I did: I have a S/MIME signed mail with a single signed text/plain part First I took the mail apart, parsing it, separating text and signature, deconding both and saving into seperate files. With the content I made sure all lines end with CRLF. The content in the file looks like this: 00000000 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74 65 |Content-Type: te| 00000010 78 74 2f 70 6c 61 69 6e 3b 20 63 68 61 72 73 65 |xt/plain; charse| 00000020 74 3d 69 73 6f 2d 38 38 35 39 2d 31 35 0d 0a 43 |t=iso-8859-15..C| 00000030 6f 6e 74 65 6e 74 2d 54 72 61 6e 73 66 65 72 2d |ontent-Transfer-| 00000040 45 6e 63 6f 64 69 6e 67 3a 20 37 62 69 74 0d 0a |Encoding: 7bit..| 00000050 0d 0a 74 65 73 74 32 0d 0a 0d 0a |..test2....| Then I did something like this (I removed error handling for better looks): gpgme_data_t gd_txt; gpgme_data_t gd_sig; gpgme_data_t gd_plain; gpgme_error_t err; gpgme_data_encoding_t enc; gpgme_ctx_t ctx; gpgme_signature_t sig; gpgme_verify_result_t res; [.....] gpgme_data_new(&gd_plain); gpgme_data_new_from_file(&gd_txt, "cont.dat", 1); gpgme_data_new_from_file(&gd_sig, "sig.dat", 1); // gpgme_data_set_encoding(gd_sig, GPGME_DATA_ENCODING_BASE64); // I took this out since I base64 decoded the sig myself. If I give the // base 64 encoded sig directly to the lib and enable this, the results are // the same. gpgme_new(&ctx); gpgme_set_protocol(ctx, GPGME_PROTOCOL_CMS); gpgme_op_verify(ctx, gd_sig, gd_txt, gd_plain); res = gpgme_op_verify_result(ctx); while (sig) { switch (gpg_err_code (sig->status)) { case GPG_ERR_NO_ERROR: fprintf(stdout, "no error\n"); break; case GPG_ERR_BAD_SIGNATURE: fprintf(stdout, "bad signature\n"); break; case GPG_ERR_NO_PUBKEY: fprintf(stdout, "no public key\n"); break; case GPG_ERR_NO_DATA: fprintf(stdout, "no data\n"); break; case GPG_ERR_SIG_EXPIRED: fprintf(stdout, "sig expired\n"); break; case GPG_ERR_KEY_EXPIRED: fprintf(stdout, "key expired\n"); break; default: fprintf(stdout, "default\n"); break; } fprintf(stdout, "signature fingerprint: %s\n", sig->fpr); if (sig->wrong_key_usage) { fprintf(stdout, "wrong key usage\n"); } switch (sig->summary) { case GPGME_SIGSUM_VALID: fprintf(stdout, "The signature is fully valid.\n"); break; case GPGME_SIGSUM_GREEN: fprintf(stdout, "The signature is good but one might want to display some exttra formation. Check the other bits\n"); break; case GPGME_SIGSUM_RED: fprintf(stdout, "The signature is bad. It might be useful to check other bits and display more information, i.e. a revoked certificate might not render a signature invalid when the message was received prior to the cause for the revocation.\n"); break; } } sig = sig->next; } gpgme_release(ctx); gpgme_data_release(gd_txt); gpgme_data_release(gd_sig); gpgme_data_release(gd_plain); ---- snip ---- Sorry for being so verbose but I wanna make sure I do everything right. Anyway, what I get is always this: bad signature signature fingerprint: 6609AEADB2A9113136A5AE46AFD596A44EFC8B52 So what I am doing wrong? Can you give me any hint? Thanks a lot and have a nice day... Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available Url : /pipermail/attachments/20060406/2c8acead/attachment.pgp From smenzel at gmx-gmbh.de Thu Apr 6 12:42:11 2006 From: smenzel at gmx-gmbh.de (Stephan Menzel) Date: Thu Apr 6 13:26:29 2006 Subject: Problems with gpgme/gpgsm Message-ID: <200604061242.14632.smenzel@gmx-gmbh.de> Hi there, I'm trying to use gpgme with gpgsm backend to verify signed S/MIME email. Progress is going well thanks to excellent gpgme docs, but I'm stuck now and I would need some help. Here's what I did: I have a S/MIME signed mail with a single signed text/plain part First I took the mail apart, parsing it, separating text and signature, deconding both and saving into seperate files. With the content I made sure all lines end with CRLF. The content in the file looks like this: 00000000 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74 65 |Content-Type: te| 00000010 78 74 2f 70 6c 61 69 6e 3b 20 63 68 61 72 73 65 |xt/plain; charse| 00000020 74 3d 69 73 6f 2d 38 38 35 39 2d 31 35 0d 0a 43 |t=iso-8859-15..C| 00000030 6f 6e 74 65 6e 74 2d 54 72 61 6e 73 66 65 72 2d |ontent-Transfer-| 00000040 45 6e 63 6f 64 69 6e 67 3a 20 37 62 69 74 0d 0a |Encoding: 7bit..| 00000050 0d 0a 74 65 73 74 32 0d 0a 0d 0a |..test2....| Then I did something like this (I removed error handling for better looks): gpgme_data_t gd_txt; gpgme_data_t gd_sig; gpgme_data_t gd_plain; gpgme_error_t err; gpgme_data_encoding_t enc; gpgme_ctx_t ctx; gpgme_signature_t sig; gpgme_verify_result_t res; [.....] gpgme_data_new(&gd_plain); gpgme_data_new_from_file(&gd_txt, "cont.dat", 1); gpgme_data_new_from_file(&gd_sig, "sig.dat", 1); // gpgme_data_set_encoding(gd_sig, GPGME_DATA_ENCODING_BASE64); // I took this out since I base64 decoded the sig myself. If I give the // base 64 encoded sig directly to the lib and enable this, the results are // the same. gpgme_new(&ctx); gpgme_set_protocol(ctx, GPGME_PROTOCOL_CMS); gpgme_op_verify(ctx, gd_sig, gd_txt, gd_plain); res = gpgme_op_verify_result(ctx); while (sig) { switch (gpg_err_code (sig->status)) { case GPG_ERR_NO_ERROR: fprintf(stdout, "no error\n"); break; case GPG_ERR_BAD_SIGNATURE: fprintf(stdout, "bad signature\n"); break; case GPG_ERR_NO_PUBKEY: fprintf(stdout, "no public key\n"); break; case GPG_ERR_NO_DATA: fprintf(stdout, "no data\n"); break; case GPG_ERR_SIG_EXPIRED: fprintf(stdout, "sig expired\n"); break; case GPG_ERR_KEY_EXPIRED: fprintf(stdout, "key expired\n"); break; default: fprintf(stdout, "default\n"); break; } fprintf(stdout, "signature fingerprint: %s\n", sig->fpr); if (sig->wrong_key_usage) { fprintf(stdout, "wrong key usage\n"); } switch (sig->summary) { case GPGME_SIGSUM_VALID: fprintf(stdout, "The signature is fully valid.\n"); break; case GPGME_SIGSUM_GREEN: fprintf(stdout, "The signature is good but one might want to display some exttra formation. Check the other bits\n"); break; case GPGME_SIGSUM_RED: fprintf(stdout, "The signature is bad. It might be useful to check other bits and display more information, i.e. a revoked certificate might not render a signature invalid when the message was received prior to the cause for the revocation.\n"); break; } } sig = sig->next; } gpgme_release(ctx); gpgme_data_release(gd_txt); gpgme_data_release(gd_sig); gpgme_data_release(gd_plain); ---- snip ---- Sorry for being so verbose but I wanna make sure I do everything right. Anyway, what I get is always this: bad signature signature fingerprint: 6609AEADB2A9113136A5AE46AFD596A44EFC8B52 This fingerprint, btw is correct, so I assume, the signature has been loaded by the lib correctly. So what I am doing wrong? Can you give me any hint? Thanks a lot and have a nice day... Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available Url : /pipermail/attachments/20060406/79c9fbf0/attachment.pgp From smenzel at gmx-gmbh.de Thu Apr 6 13:31:46 2006 From: smenzel at gmx-gmbh.de (Stephan Menzel) Date: Thu Apr 6 13:31:21 2006 Subject: Problems with gpgme/gpgsm In-Reply-To: <200604061242.14632.smenzel@gmx-gmbh.de> References: <200604061242.14632.smenzel@gmx-gmbh.de> Message-ID: <200604061331.49491.smenzel@gmx-gmbh.de> Am Donnerstag, 6. April 2006 12:42 schrieb Stephan Menzel: > Hi there, Sorry for the double post. I thought, it doesn't arrive... Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available Url : /pipermail/attachments/20060406/c8f215c5/attachment.pgp From olaf at NLnetLabs.nl Thu Apr 6 11:35:28 2006 From: olaf at NLnetLabs.nl (Olaf M. Kolkman) Date: Thu Apr 6 13:37:26 2006 Subject: [dns-operations] Automatic key verification / CERT in DNS / RFC4398 (Was: [Announce] GnuPG 1.4.3 released) In-Reply-To: References: <44332B60.5080006@ntp.isc.org> <1144238223.17442.20.camel@firenze.zurich.ibm.com> Message-ID: <66E9580D-0985-43A9-9594-48B96592F14E@NLnetLabs.nl> Hi Brad, You wrote: > I'm familiar with NSD. It is very fast, but also quite memory > intensive. There were some interesting reports at RIPE from the > folks responsible for SUNET, which is secondary to some of the > largest ccTLD zones in the world, and how they were unable to fit all > the necessary data into very large quantities of memory on their > server (something like 64GB of RAM?). > > Do you know of any machines that can have terabytes of RAM > available to store that much data? I would like to see the reference to this, as these measurements might be outdated. Besides I would like to refer you and other readers to recent numbers in http://www.ripe.net/ripe/docs/ripe-352.html#sec:memload where memory consumption of NSD and named are measured as part of an investigation of the effect of deploying DNSSEC at the RIPE NCC. In Dutch we say "meten is weten". (To measure is to know). --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 227 bytes Desc: This is a digitally signed message part Url : /pipermail/attachments/20060406/eea63256/PGP-0001.pgp From smenzel at gmx-gmbh.de Thu Apr 6 16:28:53 2006 From: smenzel at gmx-gmbh.de (Stephan Menzel) Date: Thu Apr 6 16:28:31 2006 Subject: Problems using gpgsm In-Reply-To: <200604061158.45239.smenzel@gmx-gmbh.de> References: <200604061158.45239.smenzel@gmx-gmbh.de> Message-ID: <200604061628.57186.smenzel@gmx-gmbh.de> Am Donnerstag, 6. April 2006 11:58 schrieb Stephan Menzel: > With the content I made sure all lines end with CRLF. The content in the > file looks like this: > > 00000000 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74 65 |Content-Type: > te| 00000010 78 74 2f 70 6c 61 69 6e 3b 20 63 68 61 72 73 65 |xt/plain; > charse| 00000020 74 3d 69 73 6f 2d 38 38 35 39 2d 31 35 0d 0a 43 > |t=iso-8859-15..C| 00000030 6f 6e 74 65 6e 74 2d 54 72 61 6e 73 66 65 72 > 2d |ontent-Transfer-| 00000040 45 6e 63 6f 64 69 6e 67 3a 20 37 62 69 74 > 0d 0a |Encoding: 7bit..| 00000050 0d 0a 74 65 73 74 32 0d 0a 0d 0a > |..test2....| And here was the Problem. the last CRLF at the very end was superficial. The signatures are now recognized. However, they seem to be of unknown validity because of validity reason: "Missing certificate". I did import several of Thawtes official certificates using gpgsm --import, but I wonder how to have all the root certificates in /usr/share/ca-certificates/ recognized. Can I ask you this instead? ;-) Greetings... Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available Url : /pipermail/attachments/20060406/44c44461/attachment.pgp From harakiri_23 at yahoo.com Thu Apr 6 17:27:36 2006 From: harakiri_23 at yahoo.com (Harakiri) Date: Thu Apr 6 17:27:13 2006 Subject: Automatic key verification / CERT in DNS / RFC4398 In-Reply-To: <87lkujf0fc.fsf@wheatstone.g10code.de> Message-ID: <20060406152736.26527.qmail@web52203.mail.yahoo.com> > The problem with S/MIME is that you can't create a > usabable > certificate for yourself. You have to hand over a > lot of money to > a more or less trustworthy CA with no real benefit. > OpenPGP may be used > much easier in that respect. This is untrue, actually you get class 1 certificates for free from TC Hamburg, Thawte or even Verisign which are trusted in Outlook, Outlook Express, Mozilla, Lotus Notes - heck almost any mail client ! OpenPGP however, has no defined rank of trust system - its flawed in that way imho - there are some signer keys - yes - but mostly only those made by universities and not for commerical use (those im aware are https://www.globaltrustpoint.com/pgp/pgp_list_public_keys.jsp?keyType=trusted) however openpgp is easy to use if you just want end2end encryption which is good enough for the average pc user and of course is by default not bound to the certificate email address which is a big plus for me > > I doubt that signing a message puts more load on a > server than all the > spam filtering and virus scanning in use today. This is actually true, signing a message (average size) has not much impact of the server - maximum i've seen is for PGP 200% the normal processing and 150% more for openssl (yes, gnupg seems to be slower here =/) - figures based on 50000 mails in a few minutes > > Doing client-side signing and verification is > definitely > > scalable, but is difficult to get jump-started. This is actually not right - because client side you will always have the trouble to get all up to dates CRLS, CAs, OCSP signer certs etc (im talking smime here) and revoked keys for PGP. Do you want to update every client every second to make sure the validation is correct or just have *one* trusted server handle the result which will take care of all CRLs, all CAs, all OCSP Connections ? > > Thus start with server-side signing using one key > per domain. > > > I don't think that's likely to happen any time > soon. The > > solutions which are easy to implement are > non-scalable, and the > > scalable solutions are much more difficult to > implement. > I dont quiet get that point here, there is actually enterprise gateways which use DNS lookups for ceritifcate retrievale (x509) for over 4-5 years...nothing difficult when you only use 1 key (domain/group key) for the domain - even then the DNS entries can be expended for more users and there should be no issue at all __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From brad at stop.mail-abuse.org Thu Apr 6 20:09:52 2006 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Thu Apr 6 20:26:13 2006 Subject: Automatic key verification / CERT in DNS / RFC4398 In-Reply-To: <87lkujf0fc.fsf@wheatstone.g10code.de> References: <44332B60.5080006@ntp.isc.org> <1144238223.17442.20.camel@firenze.zurich.ibm.com> <87lkujf0fc.fsf@wheatstone.g10code.de> Message-ID: At 12:44 PM +0200 2006-04-06, Werner Koch wrote: >> Keep in mind that relatively few people use any kind of personal >> encryption at all, and most that do make use of S/MIME instead of PGP >> or GPG, because S/MIME is what is provided by default from Microsoft > > The problem with S/MIME is that you can't create a usabable > certificate for yourself. You have to hand over a lot of money to > a more or less trustworthy CA with no real benefit. OpenPGP may be used > much easier in that respect. S/MIME certainly has its share of problems. But, it does have the weight of Microsoft and Netscape behind it. All by itself, that sets a high bar to overcome. >> So long as you stick to just one key for the entire domain, it >> doesn't matter if it's DKIM or PGP. It still has some greatly >> increased CPU requirements (because every single message passing >> through the server will now have to be cryptographically signed, >> which will increase the CPU server load by many orders of magnitude >> per message), but at least it has the possibility of being scalable > > I doubt that signing a message puts more load on a server than all the > spam filtering and virus scanning in use today. Most of what is done today is looking up information, both in local databases and remote ones. For remote data lookup, you're basically stalled waiting for response from the remote machine. These process are mostly I/O intensive, and not so much CPU. > DKIM and other methods are also quite computing intensive. Yup. All types of per-message cryptographic signing are going to be very CPU-intensive. If that process is done at the client side, that's going to be scalable because each individual is not going to be sending that many messages, and they probably won't notice if sending a single message takes 1000ms versus the 10ms it used to take (or whatever the difference is). The problem comes when you try to do all that on the centralized servers because that's what is easiest. >> We did try this technique before -- it was called pgpsendmail, >> and it cryptographically signed every message passing through the >> system. It didn't work very well, and few people ended up using it. > > Because the key distribution and validation of the keys was not solved. That was one problem, yes. There were others as well. >> Doing client-side signing and verification is definitely >> scalable, but is difficult to get jump-started. > > Thus start with server-side signing using one key per domain. Which leads you to the scalability problem. >> I don't think that's likely to happen any time soon. The >> solutions which are easy to implement are non-scalable, and the >> scalable solutions are much more difficult to implement. > > DNSSEC does not scale? Okay, then DNS will eventually be useless. Are you doing per-query cryptographic message signing in DNSSEC? I don't think so. IIRC, most expensive cryptographic operations are done when the zone(s) is/are loaded, and do not need to be performed again, which means that they can be cached. No such pre-processing/caching is going to be applicable for per-message cryptographic signing. > DNS-CERT does not scale? The I* types will help to offload the keys. I'll have to read more about this before I can formulate an opinion. > PKA on a per user base does not scale? Well, this might be a problem > with millions of users per domain. I don't know for sure but I doubt > that, say, 64 extra bytes of user data makes any difference to these > providers. Speaking as the former DNS expert for AOL, I can tell you that it will definitely make a difference. And I don't think it's going to be just 64 bytes per user. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See . From brad at stop.mail-abuse.org Thu Apr 6 20:10:05 2006 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Thu Apr 6 20:26:28 2006 Subject: Fwd: Automatic key verification / CERT in DNS / RFC4398 In-Reply-To: <87hd57ezqj.fsf@wheatstone.g10code.de> References: <44332B60.5080006@ntp.isc.org> <878xqkjov5.fsf@wheatstone.g10code.de> <87hd57ezqj.fsf@wheatstone.g10code.de> Message-ID: At 12:59 PM +0200 2006-04-06, Werner Koch wrote: >> Yeah, but that's probably 31.999999999999999999999999999 more >> bytes than you're storing in the DNS today (per user), and with tens >> of millions of users in a single flat zone, all that adds up really >> fast. > > Please name another reliable directory service. LDAP is far too heavy > and thus I believe DNS can be made workable for such goals much > easier. DNS is designed to be distributed, and to handle failures through replication, redundancy, and caching. > Do you think splitting the zones up in say us.e.r._pka.example.net > would be helpful? Putting the zones in a hierarchy will certainly help. That way you don't have to change and reload an entire zone with millions of users, each time that a single modification has to be made. However, I would be careful in choosing a particular hashing scheme that will be set in stone -- what is sustainable for a small site will be totally inappropriate for a large site. > And here we know that it works. Consider all the people using > webmailers or POP3. No problem at all to serve millions of users. Remember what kind of load it added to your web server when you switched everything over to SSL, and didn't allow any non-SSL connections? Or what happened when you switched everyone over to POP3S or IMAPS exclusively, and didn't allow any unencrypted POP3 or IMAP connections? You know those crypto accelerator cards that you had to add to all your webservers to support high levels of SSL usage? This is going to be orders of magnitude worse, since those uses of encryption are on a per-connection basis, and not per-message. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See . From brad at stop.mail-abuse.org Thu Apr 6 20:21:52 2006 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Thu Apr 6 20:27:00 2006 Subject: Automatic key verification / CERT in DNS / RFC4398 In-Reply-To: <20060406152736.26527.qmail@web52203.mail.yahoo.com> References: <20060406152736.26527.qmail@web52203.mail.yahoo.com> Message-ID: At 8:27 AM -0700 2006-04-06, Harakiri wrote: >> I doubt that signing a message puts more load on a >> server than all the >> spam filtering and virus scanning in use today. > > This is actually true, signing a message (average > size) has not much impact of the server - maximum i've > seen is for PGP 200% the normal processing and 150% > more for openssl (yes, gnupg seems to be slower here > =/) - figures based on 50000 mails in a few minutes This is doing a PGP cryptographic signature on each and every message as it passes through the system, as compared to no cryptographic signatures at all? I'd like to see more details of your testing, please. >> > Doing client-side signing and verification is >> definitely >> > scalable, but is difficult to get jump-started. > > This is actually not right - because client side you > will always have the trouble to get all up to dates > CRLS, CAs, OCSP signer certs etc (im talking smime > here) and revoked keys for PGP. Do you want to update > every client every second to make sure the validation > is correct or just have *one* trusted server handle > the result which will take care of all CRLs, all CAs, > all OCSP Connections ? I think the problem of keeping updated CRLs, CAs, etc... is going to have to happen anyway, and I think that can be done in a scalable manner. Teaching the clients to be able to use that system will take some time, but should not be excessively difficult. > I dont quiet get that point here, there is actually > enterprise gateways which use DNS lookups for > ceritifcate retrievale (x509) for over 4-5 > years...nothing difficult when you only use 1 key > (domain/group key) for the domain Looking up a single DNS entry is not going to be particularly difficult. Doing a single signing key for the entire domain is probably not going to put an excessive load on the DNS server which provides that information, although it will greatly increase the amount of traffic that server handles -- instead of just handing out NS, MX and A records which aren't likely to fill an entire 512-byte UDP packet, now you have to add a whole bunch of crypto key data which is likely to greatly expand the amount of information you have to provide as a part of each transaction. The problem comes when you have a key per user. Now you're talking about orders of magnitude more information that has to be handled, even with small numbers of users. And exponential explosion in memory requirements, on both the authoritative and caching servers, which is guaranteed to cause a major meltdown when you start talking about tens of millions or hundreds of millions of users with keys published via the DNS. > - even then the DNS > entries can be expended for more users and there > should be no issue at all I think you need to look at the scalability factors before you make such proclamations. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See . From julian at mehnle.net Fri Apr 7 00:08:13 2006 From: julian at mehnle.net (Julian Mehnle) Date: Fri Apr 7 00:07:26 2006 Subject: Automatic key verification / CERT in DNS / RFC4398 In-Reply-To: References: <44332B60.5080006@ntp.isc.org> <87hd57ezqj.fsf@wheatstone.g10code.de> Message-ID: <200604062208.14359.julian@mehnle.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brad Knowles wrote: > Werner Koch wrote: > > Do you think splitting the zones up in say us.e.r._pka.example.net > > would be helpful? > > Putting the zones in a hierarchy will certainly help. That way > you don't have to change and reload an entire zone with millions of > users, each time that a single modification has to be made. > > However, I would be careful in choosing a particular hashing > scheme that will be set in stone -- what is sustainable for a small > site will be totally inappropriate for a large site. And here's where I think SPF's macro feature (or a similar facility) would be useful. It would enable sites to specify their own custom schemes (within certain limits). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFENZFOwL7PKlBZWjsRAj6WAKCKg2ZYbVt/dyqDJqaJfnLJctNDIwCfXxdT LFrBo/GUVtIN428RRI5y4/s= =668O -----END PGP SIGNATURE----- From wk at gnupg.org Fri Apr 7 13:56:17 2006 From: wk at gnupg.org (Werner Koch) Date: Fri Apr 7 14:13:22 2006 Subject: [Announce] Gpg4win 1.0.0 released Message-ID: <8764lld2fy.fsf@wheatstone.g10code.de> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Fri Apr 7 22:56:02 2006 From: wk at gnupg.org (Werner Koch) Date: Sat Apr 8 02:07:25 2006 Subject: Automatic key verification / CERT in DNS / RFC4398 In-Reply-To: (Brad Knowles's message of "Thu, 6 Apr 2006 13:21:52 -0500") References: <20060406152736.26527.qmail@web52203.mail.yahoo.com> Message-ID: <87y7yh9kbh.fsf@wheatstone.g10code.de> On Thu, 6 Apr 2006 13:21:52 -0500, Brad Knowles said: > that server handles -- instead of just handing out NS, MX and A > records which aren't likely to fill an entire 512-byte UDP packet, > now you have to add a whole bunch of crypto key data which is likely > to greatly expand the amount of information you have to provide as a > part of each transaction. Recall that requesting an actual key needs to be done only once in a while - depends on how often you feel the need to check for revocations. Shalom-Salam, Werner From wk at gnupg.org Sat Apr 8 02:27:09 2006 From: wk at gnupg.org (Werner Koch) Date: Sat Apr 8 02:31:44 2006 Subject: MIME oddities In-Reply-To: <44367136.4070403@tiscali.it> (qed@tiscali.it's message of "Fri, 07 Apr 2006 16:03:34 +0200") References: <8764lld2fy.fsf@wheatstone.g10code.de> <44367136.4070403@tiscali.it> Message-ID: <87ek08ap42.fsf@wheatstone.g10code.de> On Fri, 07 Apr 2006 16:03:34 +0200, Qed said: > I like your MIME boundary :-) That is part of the fun using Emacs: (defun spook-make-boundary (&optional count) (save-excursion (set-buffer (generate-new-buffer " *spook tmp*")) (setq buffer-disable-undo t) (spook) (subst-char-in-region (point-min) (point-max) ?\n ?= t) (subst-char-in-region (point-min) (point-max) ? ?- t) (prog1 (buffer-substring (point-min) (min 70 (point-max))) (kill-buffer (current-buffer))))) (setq mml-boundary-function 'spook-make-boundary) Shalom-Salam, Werner -- Merlin SEAL Team 6 mindwar satellite imagery eavesdropping Aladdin RSA Honduras passwd espionage interception e-cash plutonium Watergate 9705 Samford Road From acarrico at memebeam.org Sat Apr 8 04:33:38 2006 From: acarrico at memebeam.org (Anthony Carrico) Date: Sat Apr 8 04:02:21 2006 Subject: [patch] duration initialization in sign.c Message-ID: <20060408023338.GA4940@memebeam.org> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : /pipermail/attachments/20060407/513d2283/attachment.pgp From acarrico at memebeam.org Sat Apr 8 04:42:09 2006 From: acarrico at memebeam.org (Anthony Carrico) Date: Sat Apr 8 04:10:39 2006 Subject: "char *outfile", why? Message-ID: <20060408024209.GB4940@memebeam.org> Continuing on the sign.c duplicate code removal theme... I noticed that "sign_file" and "clearsign_file" both have "outfile" parameters, but at the call sites the corresponding arguments are always "NULL". Does anyone remember why this exists? If not, can I remove the "outfile" parameters and corresponding code? -- Anthony Carrico http://giftfile.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : /pipermail/attachments/20060407/bf2e1979/attachment.pgp From dshaw at jabberwocky.com Sat Apr 8 04:16:49 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Sat Apr 8 04:16:06 2006 Subject: --raw-sign, --raw-verify In-Reply-To: <20060323021529.GA14889@memebeam.org> References: <20060323021529.GA14889@memebeam.org> Message-ID: <20060408021649.GC27174@jabberwocky.com> On Wed, Mar 22, 2006 at 09:15:29PM -0500, Anthony Carrico wrote: > --raw-sign file [files] > > Make a raw signature of the given message data. The output is a raw > signature, defined by the signature algorithm, and not an OpenPGP > packet. The message digest is also available on the status fd. The main problem I have with raw signatures is nicely stated in this documentation: it's not OpenPGP. GnuPG (1.4, anyway) is an OpenPGP tool. It seems out of scope for it to support something other than OpenPGP. That strikes me as a better task for a tool written to use gcrypt or openssl. David From brad at stop.mail-abuse.org Sat Apr 8 08:50:19 2006 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Sat Apr 8 08:52:42 2006 Subject: Automatic key verification / CERT in DNS / RFC4398 In-Reply-To: <87y7yh9kbh.fsf@wheatstone.g10code.de> References: <20060406152736.26527.qmail@web52203.mail.yahoo.com> <87y7yh9kbh.fsf@wheatstone.g10code.de> Message-ID: At 10:56 PM +0200 2006-04-07, Werner Koch wrote: > Recall that requesting an actual key needs to be done only once in a > while - depends on how often you feel the need to check for > revocations. Recall that there are a whole multitude of horribly broken resolvers and nameservers out there, many of which will re-query for the same information at least once per second, ad infinitum -- regardless of whether or not you have answered their query in the previous second. Recall that there are these things called "TTLs" which are placed on DNS records, and poorly chosen TTLs could, all by themselves, cause a massive increase in load on the server & clients in question. Recall that if you try to cache the entire Internet, you're likely to run out of disk space. Everything about this problem screams for a solution that does *NOT* involve the DNS. At the very least, does not involve the DNS except in some peripheral manner, such as using SRV records to tell people where your crypto key storage server is located and how to access it. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See . From wk at gnupg.org Sat Apr 8 11:43:49 2006 From: wk at gnupg.org (Werner Koch) Date: Sat Apr 8 11:46:46 2006 Subject: [patch] duration initialization in sign.c In-Reply-To: <20060408023338.GA4940@memebeam.org> (Anthony Carrico's message of "Fri, 7 Apr 2006 22:33:38 -0400") References: <20060408023338.GA4940@memebeam.org> Message-ID: <87lkug8kru.fsf@wheatstone.g10code.de> On Fri, 7 Apr 2006 22:33:38 -0400, Anthony Carrico said: > In sign.c there are three sign procedures: sign_file, clearsign_file, > and sign_symencrypt_file, and a comment that reads, "FIXME: Far too > much code is duplicated - revamp the whole file". My "raw-sign" patch > is in danger of increasing the problem, so I want to reduce it. Please note that I have not yet looked at your raw sign thing. Further we can't accept patches without exchanging legal papers for the FSF. Salam-Shalom, Werner From julian at mehnle.net Sat Apr 8 12:31:49 2006 From: julian at mehnle.net (Julian Mehnle) Date: Sat Apr 8 12:31:05 2006 Subject: Automatic key verification / CERT in DNS / RFC4398 In-Reply-To: References: <20060406152736.26527.qmail@web52203.mail.yahoo.com> <87y7yh9kbh.fsf@wheatstone.g10code.de> Message-ID: <200604081031.50008.julian@mehnle.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brad Knowles wrote: > Recall that there are a whole multitude of horribly broken > resolvers and nameservers out there, many of which will re-query for > the same information at least once per second, ad infinitum -- > regardless of whether or not you have answered their query in the > previous second. > > Recall that there are these things called "TTLs" which are placed > on DNS records, and poorly chosen TTLs could, all by themselves, > cause a massive increase in load on the server & clients in question. > > Recall that if you try to cache the entire Internet, you're > likely to run out of disk space. > > Everything about this problem screams for a solution that does > *NOT* involve the DNS. At the very least, does not involve the DNS > except in some peripheral manner, such as using SRV records to tell > people where your crypto key storage server is located and how to > access it. How are any of the above problems specific to DNS? For example: s/DNS/HTTP/, s/record/resource/, s/resolver/HTTP client/, s/nameserver/HTTP proxy/, s/TTL/Expires: header/ -- so what's changed in your above assessment? Maybe I am just missing the obvious, better choice of a non-DNS, non-HTTP protocol for this purpose, but I think the problems you pointed out are of a fundamental nature and can hardly be solved by choosing a "better" protocol. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEN5EVwL7PKlBZWjsRAoeaAJ0UVQmGk+2NrtNT7be8sUSAUrfiDwCg938A MXvtGFOjma2ei117DVzPdsk= =qs8/ -----END PGP SIGNATURE----- From alan at ajsquared.us Sat Apr 8 16:25:57 2006 From: alan at ajsquared.us (Alan Jones) Date: Sat Apr 8 18:26:22 2006 Subject: GPGol Questions and Thoughts Message-ID: <4437C7F5.9050404@ajsquared.us> I hope this is the right place to post this, I think this is where I was previously directed. I have just started using GPGol though the gpg4win project and have version 0.9.8 installed. I found out though trial and error and some lucky reading in the gpg4win lists that you can not use GPGol just by doing in Outlook menu ACTIONS -> New Message -> Plain Text. I generally don't sign every message I write. I also like having Word as my default editor as it underlines words I misspell as I type them. Is there any chance that: 1. An option and associated icons could be added so that using Word as the default editor in Plain Text mode would easily allow for signing and/or encrypting mail? 2. An option that a message could be written with Word as the default editor even in HTML mode. Then have associated warnings and optional conversion to convert the message back to text. I have seen Enigmail for Thunderbird do this. It is very nice. Enigmail also has an option to rewrap signed HTML text before sending. 3. If the above two options are not possible what about an icon on the main Outlook tool bar and associated text that says "Write a new GnuPG message"? This would start the Outlook Editor even if Word was set as the default editor for Outlook? That way those of us that liked Word as the default for most stuff could still easily get to the Outlook editor for GnuPG related items. I was hoping this option could be easy enough that it could be something added in a near release. On an unrelated note what does the check box option "Show HTML version is possible" mean in GnuPG Options dialog? How does that work? Please consider adding a few more options like key singing rules like Enigmail has. Any chance of getting GPGol to work on older versions of Outlook? I know it was stared that anything lower then 2003 with SP2 was to buggy, but sometimes I know new thoughts and ides will come up. Does anyone know of GPGol would work with the new Outlook 12 aka Outlook 2007 or are there plans to test this with the current Microsoft Betas? I know that Office 12 is in beta and still a year out from what I have read the the Outlook Plug-in parts should be fairly stable so that other companies can start making plug-ins for Outlook 12. I know of some people already using MS Office 12 as their main platform. If you all later support multiple versions of Outlook (older or newer) please consider an option to install GPGol on multiple Outlook installations on the same machine. On some machines I end up running multiple versions of MS Office (I know that can be tricky with some MS Office apps). Would it be worth making the g10 Code page for GPGol a little more generic without the version number and just a link to the files listing ftp://ftp.g10code.com/g10code/gpgol/ and a link to the Gpg4win site? Sorry for such a long post. Thanks for all the help and hard work on great products. Alan From acarrico at memebeam.org Sun Apr 9 00:37:39 2006 From: acarrico at memebeam.org (Anthony Carrico) Date: Sun Apr 9 00:06:14 2006 Subject: --raw-sign, --raw-verify In-Reply-To: <20060408021649.GC27174@jabberwocky.com> References: <20060323021529.GA14889@memebeam.org> <20060408021649.GC27174@jabberwocky.com> Message-ID: <20060408223739.GA6648@memebeam.org> On Fri, Apr 07, 2006 at 10:16:49PM -0400, David Shaw wrote: > The main problem I have with raw signatures is nicely stated in this > documentation: it's not OpenPGP. GnuPG (1.4, anyway) is an OpenPGP > tool. It seems out of scope for it to support something other than > OpenPGP. People make an investment when they exchange keys to build an identity with OpenPGP. It makes sense to capitalize on that investment when an application uses same algorithm, but not the same syntax. The alternative is a proliferation of separate key infrastructures--surely a bad thing. From this perspective, the focus of the proposed patch really is on OpenPGP. > That strikes me as a better task for a tool written to use > gcrypt or openssl. That might make sense when using a certificate authority, but for peer-to-peer key exchange, OpenPGP is the premier protocol, and in many (most?) communities, GnuPG is the premier implementation. -- Anthony Carrico http://giftfile.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : /pipermail/attachments/20060408/24c141f7/attachment.pgp From acarrico at memebeam.org Sun Apr 9 22:18:48 2006 From: acarrico at memebeam.org (Anthony Carrico) Date: Sun Apr 9 21:47:06 2006 Subject: [patch] out initialization in sign.c Message-ID: <20060409201847.GA7286@memebeam.org> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : /pipermail/attachments/20060409/8b0ab8ce/attachment.pgp From acarrico at memebeam.org Sun Apr 9 22:25:33 2006 From: acarrico at memebeam.org (Anthony Carrico) Date: Sun Apr 9 21:53:47 2006 Subject: [patch] out initialization in sign.c In-Reply-To: <20060409201847.GA7286@memebeam.org> References: <20060409201847.GA7286@memebeam.org> Message-ID: <20060409202533.GA7549@memebeam.org> On Sun, Apr 09, 2006 at 04:18:48PM -0400, Anthony Carrico wrote: > This patch is based on GnuPG SVN revision 4098 Correction: revision 4098 + duration.patch -- Anthony Carrico http://giftfile.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : /pipermail/attachments/20060409/3b5e745b/attachment.pgp From dshaw at jabberwocky.com Sun Apr 9 23:08:49 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Sun Apr 9 23:08:05 2006 Subject: --raw-sign, --raw-verify In-Reply-To: <20060408223739.GA6648@memebeam.org> References: <20060323021529.GA14889@memebeam.org> <20060408021649.GC27174@jabberwocky.com> <20060408223739.GA6648@memebeam.org> Message-ID: <20060409210849.GG31486@jabberwocky.com> On Sat, Apr 08, 2006 at 06:37:39PM -0400, Anthony Carrico wrote: > On Fri, Apr 07, 2006 at 10:16:49PM -0400, David Shaw wrote: > > The main problem I have with raw signatures is nicely stated in this > > documentation: it's not OpenPGP. GnuPG (1.4, anyway) is an OpenPGP > > tool. It seems out of scope for it to support something other than > > OpenPGP. > > People make an investment when they exchange keys to build an identity > with OpenPGP. It makes sense to capitalize on that investment when an > application uses same algorithm, but not the same syntax. The > alternative is a proliferation of separate key infrastructures--surely > a bad thing. From this perspective, the focus of the proposed patch > really is on OpenPGP. My concern is not about doing this with OpenPGP keys or not. I think that's a fine idea. My concern is doing this in GnuPG, specifically. These signatures would not be OpenPGP signatures. We have seen in the past few months two different signature flaws in GnuPG, in part caused by lenient parsing of signature data. I question whether GnuPG, an OpenPGP tool, should grow the cabability of making and issuing non-OpenPGP signatures in a non-standard way. To be sure, GnuPG is free software. You have the ability to do whatever you like with it, and that's a good thing. My argument is against accepting this feature into the main GnuPG code base where it would need to be maintained for all, but used by very few. David From acarrico at memebeam.org Sun Apr 9 23:57:09 2006 From: acarrico at memebeam.org (Anthony Carrico) Date: Sun Apr 9 23:25:24 2006 Subject: Prefered CC mode setup? Message-ID: <20060409215709.GA7666@memebeam.org> Could one of the GnuPG developers (who uses emacs) please post the recommended CC mode settings? I think I'm in "gnu" mode and it doesn't seem to quite match. Might be a good thing to add to HACKING. Thank you. -- Anthony Carrico http://giftfile.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : /pipermail/attachments/20060409/4c2811cd/attachment.pgp From dshaw at jabberwocky.com Mon Apr 10 00:34:58 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Mon Apr 10 00:34:07 2006 Subject: Prefered CC mode setup? In-Reply-To: <20060409215709.GA7666@memebeam.org> References: <20060409215709.GA7666@memebeam.org> Message-ID: <20060409223458.GC21747@jabberwocky.com> On Sun, Apr 09, 2006 at 05:57:09PM -0400, Anthony Carrico wrote: > Could one of the GnuPG developers (who uses emacs) please post the > recommended CC mode settings? I think I'm in "gnu" mode and it doesn't > seem to quite match. Might be a good thing to add to HACKING. We use the standard GNU defaults, a la 'indent --gnu-style', for new code. However, there is a lot of existing code in there that is K&R. It was decided that reformatting the code in bulk was a bad idea and thus as functions are edited over time, they have been slowly evolving into GNU style. So, short answer is, if you are editing a function and adding a line or two, match whatever style you see there. If you are adding a new function or significantly changing existing code, use GNU style. David -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 250 bytes Desc: not available Url : /pipermail/attachments/20060409/630ce882/attachment.pgp From acarrico at memebeam.org Mon Apr 10 01:14:52 2006 From: acarrico at memebeam.org (Anthony Carrico) Date: Mon Apr 10 01:14:06 2006 Subject: --raw-sign, --raw-verify In-Reply-To: <20060409210849.GG31486@jabberwocky.com> References: <20060323021529.GA14889@memebeam.org> <20060408021649.GC27174@jabberwocky.com> <20060408223739.GA6648@memebeam.org> <20060409210849.GG31486@jabberwocky.com> Message-ID: <20060409231452.GA7782@memebeam.org> On Sun, Apr 09, 2006 at 05:08:49PM -0400, David Shaw wrote: > My concern is not about doing this with OpenPGP keys or not. I think > that's a fine idea. My concern is doing this in GnuPG, specifically. > These signatures would not be OpenPGP signatures. Understood. I'm glad to read that you aren't concerned about the premise of sharing the key infrastructure. I see three options (is there a fourth?): 1. Add raw sign and verify to GnuPG. 2. Maintain applications with parallel key and trust databases. To me, this seems extremely unkind to users, and implies duplicate code. 3. Maintain applications with parallel code accessing the same key and trust databases. Again, duplicate code, and dangerous if the shared interface isn't well known and respected. > We have seen in the past few months two different signature flaws in > GnuPG, in part caused by lenient parsing of signature data. I > question whether GnuPG, an OpenPGP tool, should grow the capability of > making and issuing non-OpenPGP signatures in a non-standard way. > My argument is against accepting this feature into the main GnuPG > code base where it would need to be maintained for all, ... An understandable concern. The GnuPG community doesn't want or deserve an ill-conceived new feature. I will try to make my case a little more solid: I do NOT propose that GnuPG support or maintain non-OpenPGP protocols natively. I am trying to forge a secure, minimal path for third party applications to implement such protocols independently, while sharing a common OpenPGP key infrastructure with GnuPG. I do propose that GnuPG allow access to standard signature algorithms (RSA, DSA) which are already maintained. Please note that there is precedent in GnuPG for raw access to algorithmic building blocks (the random number generators and raw message digest algorithms). > ... but used by very few. My proposal is a pretty small task, and yet it opens the door to share GnuPG's key infrastructure with other protocols. Are you sure that it would only be useful to very few? And finally, there is the possibility to just go ahead and use OpenPGP packet syntax in all applications. Hopefully it is obvious that this isn't always possible. -- Anthony Carrico http://giftfile.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : /pipermail/attachments/20060409/946f9003/attachment.pgp From wk at gnupg.org Mon Apr 10 09:58:54 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Apr 10 10:02:11 2006 Subject: Prefered CC mode setup? In-Reply-To: <20060409215709.GA7666@memebeam.org> (Anthony Carrico's message of "Sun, 9 Apr 2006 17:57:09 -0400") References: <20060409215709.GA7666@memebeam.org> Message-ID: <87u091q2td.fsf@wheatstone.g10code.de> On Sun, 9 Apr 2006 17:57:09 -0400, Anthony Carrico said: > Could one of the GnuPG developers (who uses emacs) please post the > recommended CC mode settings? I think I'm in "gnu" mode and it doesn't Depends. I used to use some kind of K&R but switched to gnu mode years ago. So in general gnu mode is fine and we truy to convert existing code but that nmakes only sense for large changes - otherwise a diff gets pretty meanigless. Shalom-Salam, Werner p.s ; That is what I am using for old code (c-add-style "dd9jn" '((c-basic-offset . 4) (c-comment-only-line-offset . (0 . 0)) (c-hanging-braces-alist . ((brace-list-open) (substatement-open after) (block-close . c-snug-do-while))) (c-offsets-alist . ((statement-block-intro . +) (knr-argdecl-intro . 5) (substatement-open . +) (label . /) (case-label . *) (statement-case-intro . *) (statement-case-open . *) (substatement-open . +) (statement-cont . +) (arglist-intro . c-lineup-arglist-intro-ater-paren) (arglist-close . c-lineup-arglist))) (c-special-indent-hook . c-gnu-impose-minimum) (c-comment-continuation-stars . " * ")) ) From wk at gnupg.org Mon Apr 10 11:56:21 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Apr 10 12:01:40 2006 Subject: --raw-sign, --raw-verify In-Reply-To: <20060409231452.GA7782@memebeam.org> (Anthony Carrico's message of "Sun, 9 Apr 2006 19:14:52 -0400") References: <20060323021529.GA14889@memebeam.org> <20060408021649.GC27174@jabberwocky.com> <20060408223739.GA6648@memebeam.org> <20060409210849.GG31486@jabberwocky.com> <20060409231452.GA7782@memebeam.org> Message-ID: <87r745oit6.fsf@wheatstone.g10code.de> On Sun, 9 Apr 2006 19:14:52 -0400, Anthony Carrico said: > 1. Add raw sign and verify to GnuPG. No. > 2. Maintain applications with parallel key and trust databases. > To me, this seems extremely unkind to users, and implies duplicate > code. No feature crap please. There are already too many features and we try to limit them to OpenPGP relevant ones. This does not include use of OpenPGp beyond the specification. > I do NOT propose that GnuPG support or maintain non-OpenPGP protocols > natively. I am trying to forge a secure, minimal path for third party > applications to implement such protocols independently, while sharing > a common OpenPGP key infrastructure with GnuPG. If you want to connect the WoT with your signature scheme, you just need to include the fingerprint of the certifying OpenPGP key into your signature. > I do propose that GnuPG allow access to standard signature algorithms > (RSA, DSA) which are already maintained. Please note that there is A long time ago we splitted libgcrypt out of GnupG and that is what you should use. Further, forthcoming versions of GnuPG won't come with any crypto algorithm implementation but make use of Libgcrypt. gpg 1.4 will stay as the easy to build OpenPGP implementation but aims not as the Mozilla of crypto tools. > My proposal is a pretty small task, and yet it opens the door to share > GnuPG's key infrastructure with other protocols. Are you sure that it > would only be useful to very few? It is a matter of complexity and maintainability. A dedicated application is for sure better. The actual signing operation in xmldsig is a primitive task compared to all the challenges that protocol has for developers. > And finally, there is the possibility to just go ahead and use OpenPGP > packet syntax in all applications. Hopefully it is obvious that this > isn't always possible. FWIW, There is a file system for Linux which just does this. Regarding xmldsig: Save your time and don't try it. It will never work reliable as it is far too complex and has been defined by people obviously without any real experience in actual signing protocol design and implementation. Shalom-Salam, Werner From mail at joachim-breitner.de Tue Apr 11 09:44:13 2006 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue Apr 11 11:26:20 2006 Subject: chipcard2 and gnupg Message-ID: <1144741453.5893.4.camel@otto.ehbuehl.net> Hi, I'm sucessfully using gnupg with pcscd, but sa I want to use HBCI, too, I need to switch to libchipcard2. HBCI works, but I'd like to use gnupg with libchipcard2, too, but it does not work: $ echo bla|gpg -v --sign --armour --ctapi-driver /usr/lib/libchipcard2_ctapi.so.0 gpg: using classic trust model gpg: der Zweitschl?ssel F64A4797 wird anstelle des Hauptschl?ssels 4743206C verwendet gpg: Schreiben auf die Standardausgabe gpg: ct_activate_card: can't get status of reader 0: ct error gpg: reader slot 0: Memory ICC present gpg: ct_activate_card: can't get status of reader 0: ct error gpg: apdu_send_simple(0) failed: card I/O error The corresponding logs from chipcard2 are: Apr 11 09:43:00 otto chipcardd[6450]: clr_clientready.c: 93: Client "443b5c4c" started (fake-ctapi, Gwen 2.1.1.0stable, ChipCard 2.1.3.0stable) Apr 11 09:43:00 otto chipcardd[6450]: clr_startwait.c: 63: Client 443b5c4c: StartWait [fake-ctapi/nobody] Apr 11 09:43:00 otto chipcardd[6450]: clr_startwait.c: 128: Advertising card "00000006" to client "443b5c4c" [fake-ctapi/nobody] Apr 11 09:43:00 otto chipcardd[6450]: cardmanager.c: 390: Keep time counter restarted Apr 11 09:43:00 otto chipcardd[6450]: cardmanager.c: 405: No longer allowing reader to shut down Apr 11 09:43:00 otto chipcardd[6450]: clr_takecard.c: 76: Client 443b5c4c: TakeCard [fake-ctapi/nobody] Apr 11 09:43:00 otto chipcardd[6450]: clr_takecard.c: 142: Enqueued TakeCard request for card "00000006" and client "443b5c4c" Apr 11 09:43:00 otto chipcardd[6450]: clr_takecard.c: 158: Working on TakeCard request Apr 11 09:43:00 otto chipcardd[6450]: cm_card.c: 183: Lock request granted Apr 11 09:43:00 otto chipcardd[6450]: clr_takecard.c: 158: Working on TakeCard request Apr 11 09:43:00 otto chipcardd[6450]: lockmanager.c: 167: Lock request granted Apr 11 09:43:00 otto chipcardd[6450]: clr_selectcard.c: 76: Client 443b5c4c: SelectCard [fake-ctapi/nobody] Apr 11 09:43:00 otto chipcardd[6450]: lockmanager.c: 284: slot currently locked by "443b5c0c" (wanted: 443b5c0c) Apr 11 09:43:00 otto chipcardd[6450]: commandmanager.c: 1223: Card type "ProcessorCard" selected Any idea what might be the cause? Maybe gnupg is trying to get two locks on the card? Is there another way to get gnupg working with chipcard2? my versions are: $ LANG=C dpkg -l gnupg libchipcard2-0c2 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-==================-==================-==================================================== ii gnupg 1.4.3-1 GNU privacy guard - a free PGP replacement ii libchipcard2-0c2 2.1.3-1 library for accessing smartcards Thanks, Joachim -- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: joachimbreitner@amessage.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org From choeger at pool.math.tu-berlin.de Tue Apr 11 12:49:08 2006 From: choeger at pool.math.tu-berlin.de (=?UTF-8?Q?Christoph_H=F6ger?=) Date: Tue Apr 11 16:22:33 2006 Subject: Compiling gpgme with MinGW32 Message-ID: <20060411104908.GA29275@fb3-s4.math.tu-berlin.de> Hi, i need to compile gpgme under windows xp and tryed mingw32 and msys. ./configure works fine and seems to recognize the compiler, but there is an #include statement in ath.h this will of course not work. Is there a way to compile the library under windows at all? thanks christoph From wk at gnupg.org Tue Apr 11 21:20:50 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Apr 11 21:26:37 2006 Subject: Compiling gpgme with MinGW32 In-Reply-To: <20060411104908.GA29275@fb3-s4.math.tu-berlin.de> (Christoph =?utf-8?Q?H=F6ger's?= message of "Tue, 11 Apr 2006 12:49:08 +0200") References: <20060411104908.GA29275@fb3-s4.math.tu-berlin.de> Message-ID: <87bqv7rka5.fsf@wheatstone.g10code.de> On Tue, 11 Apr 2006 12:49:08 +0200, Christoph H.ger said: > i need to compile gpgme under windows xp and tryed mingw32 and msys. > ./configure works fine and seems to recognize the compiler, but there is an > #include statement in ath.h > this will of course not work. Is there a way to compile the library under windows at all? Don't know. For obvious reasons I stick to a cross-compiler. Shalom-Salam, Werner From jvender at owensboro.net Tue Apr 11 21:16:20 2006 From: jvender at owensboro.net (Joe Vender) Date: Tue Apr 11 22:56:11 2006 Subject: new gnupg-1.4.4 autogen error Message-ID: <200604111416200430.002A48C4@216.135.2.37> Using MinGW/MSYS on Windows to build native windows binaries: I'm getting the following when trying to run scripts/autogen.sh with the latest cvs code for GnuPG 1.4.4 as of today, April 11, 2006. I believe the code I'm using is at revision 4105 on the trunk. $ scripts/autogen.sh Running aclocal -I m4 ... sed: -e expression #2, char 29: Extra characters after command Running autoheader... sed: -e expression #2, char 29: Extra characters after command Running automake --gnu --add-missing... sed: -e expression #2, char 29: Extra characters after command Running autoconf... You may now run "./configure --enable-maintainer-mode && make". Not sure where this was introduced, but it wasn't present in the code for the release version of GnuPG 1.4.3. Probably just a typo error somewhere. Joe Vender From wk at gnupg.org Wed Apr 12 12:06:36 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Apr 12 12:11:45 2006 Subject: new gnupg-1.4.4 autogen error In-Reply-To: <200604111416200430.002A48C4@216.135.2.37> (Joe Vender's message of "Tue, 11 Apr 2006 14:16:20 -0500") References: <200604111416200430.002A48C4@216.135.2.37> Message-ID: <87slojp0pf.fsf@wheatstone.g10code.de> On Tue, 11 Apr 2006 14:16:20 -0500, Joe Vender said: > Running aclocal -I m4 ... > sed: -e expression #2, char 29: Extra characters after command The culprit is this sed invocation: sed -n '/^Revision:/ {s/[^0-9]//gp;q}' It extracts the Revision line (of svn info), deletes all but the digits and quits so that only the first line is considered. Usin the semicolon is permitted by POSIX but implementations are not required to. I guess I need to call head instead. Please change the lines in m4_define([svn_revision], m4_esyscmd([echo -n $((svn info 2>/dev/null \ || echo 'Revision: 0')|sed -n '/^Revision:/ {s/[^0-9]//gp;q}')])) to m4_define([svn_revision], m4_esyscmd([echo -n $((svn info 2>/dev/null \ || echo 'Revision: 0')|sed -n '/^Revision:/ s/[^0-9]//gp'|head -1)])) or svn up > Not sure where this was introduced, but it wasn't present in the code for > the release version of GnuPG 1.4.3. Probably just a typo error somewhere. No, I added a feature to append the SVN revision to the evrsion number. > Joe Vender > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From npcole at yahoo.co.uk Wed Apr 12 14:52:38 2006 From: npcole at yahoo.co.uk (Nicholas Cole) Date: Wed Apr 12 14:52:11 2006 Subject: Status Line Orders Message-ID: <20060412125238.58368.qmail@web26714.mail.ukl.yahoo.com> Hi, doc/DETAILS says that "For each signature only one of the three codes GOODSIG, BADSIG or ERRSIG will be emitted and they may be used as a marker for a new signature. The username is the primary one encoded in UTF-8 and %XX escaped. " But in actual fact, SIG_ID seems to be issued first. Is this not a bug, or should the docs be ammended? Best wishes, N. ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com From wk at gnupg.org Wed Apr 12 18:41:55 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Apr 12 18:47:09 2006 Subject: Status Line Orders In-Reply-To: <20060412125238.58368.qmail@web26714.mail.ukl.yahoo.com> (Nicholas Cole's message of "Wed, 12 Apr 2006 13:52:38 +0100 (BST)") References: <20060412125238.58368.qmail@web26714.mail.ukl.yahoo.com> Message-ID: <87fykioiek.fsf@wheatstone.g10code.de> On Wed, 12 Apr 2006 13:52:38 +0100 (BST), Nicholas Cole said: > Hi, > doc/DETAILS says that > "For each signature only > one of the three codes GOODSIG, BADSIG or > ERRSIG will be > emitted and they may be used as a marker for a > new signature. > The username is the primary one encoded in > UTF-8 and %XX > escaped. > " > But in actual fact, SIG_ID seems to be issued first. Thus the "may be used as a marker". It is not very well defined and we need to implement the NEWSIG status to reliable indicate a new signature. Salam-Shalom, Werner From jvender at owensboro.net Wed Apr 12 22:11:54 2006 From: jvender at owensboro.net (Joe Vender) Date: Wed Apr 12 22:11:43 2006 Subject: new gnupg-1.4.4 autogen error In-Reply-To: <87slojp0pf.fsf@wheatstone.g10code.de> References: <200604111416200430.002A48C4@216.135.2.37> <87slojp0pf.fsf@wheatstone.g10code.de> Message-ID: <200604121511540900.0004A11C@216.135.2.37> Thanks Werner. That fixed it for me. Joe Vender *********** REPLY SEPARATOR *********** On 4/12/06 at 12:06 PM Werner Koch wrote: >On Tue, 11 Apr 2006 14:16:20 -0500, Joe Vender said: > > >> Running aclocal -I m4 ... >> sed: -e expression #2, char 29: Extra characters after command > >The culprit is this sed invocation: > > sed -n '/^Revision:/ {s/[^0-9]//gp;q}' > >It extracts the Revision line (of svn info), deletes all but the >digits and quits so that only the first line is considered. Usin the >semicolon is permitted by POSIX but implementations are not required >to. I guess I need to call head instead. Please change the lines in > >m4_define([svn_revision], m4_esyscmd([echo -n $((svn info 2>/dev/null \ > || echo 'Revision: 0')|sed -n '/^Revision:/ >{s/[^0-9]//gp;q}')])) > >to > >m4_define([svn_revision], m4_esyscmd([echo -n $((svn info 2>/dev/null \ > || echo 'Revision: 0')|sed -n '/^Revision:/ s/[^0-9]//gp'|head >-1)])) > >or svn up From bob at ti.com Wed Apr 12 22:55:48 2006 From: bob at ti.com (Bob Luckin) Date: Thu Apr 13 01:26:15 2006 Subject: new gnupg-1.4.4 autogen error In-Reply-To: <87slojp0pf.fsf@wheatstone.g10code.de> References: <200604111416200430.002A48C4@216.135.2.37> <87slojp0pf.fsf@wheatstone.g10code.de> Message-ID: <20060412205548.GA24284@pavis.dal.design.ti.com> Hi Werner, If you want to save the additional process invocation for head, you could try either of these sed commands, which I _think_ do what you want :- sed -n -e '/^Revision:/ s/[^0-9]//gp' -e 't quit' -e 'b' -e ': quit' -e 'q' sed -n -e '/^Revision:/ h' -e '/^Revision:/ s/[^0-9]//gp' -e 'g' \ -e '/^Revision:/ q' They'd make the code longer, though. My Solaris version of sed does not support the POSIX semicolon, but it does work as long as there is a newline after each command in the set, so something like sed -n '/^Revision:/ { s/[^0-9]//gp q }' should also work. I'm not certain how generic this is, but I think it is more portable than the POSIX semicolon. Cheers, Bob On Wed, Apr 12, 2006 at 12:06:36PM +0200, Werner Koch wrote: > On Tue, 11 Apr 2006 14:16:20 -0500, Joe Vender said: > > > > Running aclocal -I m4 ... > > sed: -e expression #2, char 29: Extra characters after command > > The culprit is this sed invocation: > > sed -n '/^Revision:/ {s/[^0-9]//gp;q}' > > It extracts the Revision line (of svn info), deletes all but the > digits and quits so that only the first line is considered. Usin the > semicolon is permitted by POSIX but implementations are not required > to. I guess I need to call head instead. Please change the lines in > > m4_define([svn_revision], m4_esyscmd([echo -n $((svn info 2>/dev/null \ > || echo 'Revision: 0')|sed -n '/^Revision:/ {s/[^0-9]//gp;q}')])) > > to > > m4_define([svn_revision], m4_esyscmd([echo -n $((svn info 2>/dev/null \ > || echo 'Revision: 0')|sed -n '/^Revision:/ s/[^0-9]//gp'|head -1)])) > > or svn up > > > Not sure where this was introduced, but it wasn't present in the code for > > the release version of GnuPG 1.4.3. Probably just a typo error somewhere. > > No, I added a feature to append the SVN revision to the evrsion > number. > > > > Joe Vender > > > > > _______________________________________________ > > Gnupg-devel mailing list > > Gnupg-devel@gnupg.org > > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From wk at gnupg.org Thu Apr 13 08:58:14 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Apr 13 09:01:46 2006 Subject: new gnupg-1.4.4 autogen error In-Reply-To: <20060412205548.GA24284@pavis.dal.design.ti.com> (Bob Luckin's message of "Wed, 12 Apr 2006 15:55:48 -0500") References: <200604111416200430.002A48C4@216.135.2.37> <87slojp0pf.fsf@wheatstone.g10code.de> <20060412205548.GA24284@pavis.dal.design.ti.com> Message-ID: <87zmiqm06x.fsf@wheatstone.g10code.de> On Wed, 12 Apr 2006 15:55:48 -0500, Bob Luckin said: > sed -n -e '/^Revision:/ h' -e '/^Revision:/ s/[^0-9]//gp' -e 'g' \ > -e '/^Revision:/ q' I thought about this > They'd make the code longer, though. but I don't wanted to get it that long :-) > sed -n '/^Revision:/ { s/[^0-9]//gp > q > }' Makes it also longer, thus I pipe it trhough head. It is not a performance problem because those commands are only run at autoconf time and not at ./configure time. Thanks, Werner From npcole at yahoo.co.uk Thu Apr 13 08:46:26 2006 From: npcole at yahoo.co.uk (Nicholas Cole) Date: Thu Apr 13 09:46:00 2006 Subject: Status Line Orders In-Reply-To: <87fykioiek.fsf@wheatstone.g10code.de> Message-ID: <20060413064626.62282.qmail@web26703.mail.ukl.yahoo.com> --- Werner Koch wrote: > Thus the "may be used as a marker". It is not very > well defined and > we need to implement the NEWSIG status to reliable > indicate a new > signature. Ah. I'd read that as meaning "safe to use as a marker" that a new signature was being processed (and thus that subsequent data would refer to that signature). Best, N. ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com From solinym at gmail.com Thu Apr 13 03:11:18 2006 From: solinym at gmail.com (Travis H.) Date: Thu Apr 13 11:34:10 2006 Subject: any plans to use serpent? Message-ID: From alex at bofh.net.pl Thu Apr 13 12:02:55 2006 From: alex at bofh.net.pl (Janusz A. Urbanowicz) Date: Thu Apr 13 13:26:11 2006 Subject: any plans to use serpent? In-Reply-To: References: Message-ID: <20060413100255.GB7416@hell.pl> On Wed, Apr 12, 2006 at 08:11:18PM -0500, Travis H. wrote: > >From everything I read, serpent is the most conservative of the AES candidates. > > Are there any plans to incorporate it into gpg? If so, why not? ;-) The real question is why yes? if you want to use modern and trendy algorithm, you have AES. If you're cryptographically conservative like me, there is 3DES. If you're old school PGP there is IDEA and CAST. If you're Schneier's follower, there is Blowfish. What qualities do Serpent have that the abovementioned lack? Adding a new option to a widely established protocol like OpenPGP is no light task. It complicates a lot of things. Even with the variety that we have now, it is not trivial to communicate two PGP implementations. New stuff should be added if it is absolutely needed. OTOH, in crypto communication design it is an important factor that compromised protocol could be disabled and another one enabled in place. IMO (note: I'm a not a professional security engineer at the moment) the current variety is enough. If you want to use Serpent, implement it as a module with algorithm ID between 100 and 110 (local/experimental). For example there is such an unofficial module for NSA-designed Skipjack algorithm. Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: Digital signature Url : /pipermail/attachments/20060413/d7162f01/attachment.pgp From wk at gnupg.org Thu Apr 13 14:01:47 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Apr 13 14:06:39 2006 Subject: any plans to use serpent? In-Reply-To: (Travis H.'s message of "Wed, 12 Apr 2006 20:11:18 -0500") References: Message-ID: <87hd4xn0pg.fsf@wheatstone.g10code.de> On Wed, 12 Apr 2006 20:11:18 -0500, Travis H said: >> From everything I read, serpent is the most conservative of the AES candidates. > Are there any plans to incorporate it into gpg? If so, why not? ;-) Serpent is not specified by OpenPGP and thus we can't implement it. Shalom-Salam, Werner From kmagnum at gmail.com Thu Apr 13 16:25:45 2006 From: kmagnum at gmail.com (Karl Magdsick) Date: Thu Apr 13 18:26:15 2006 Subject: any plans to use serpent? In-Reply-To: <20060413100255.GB7416@hell.pl> References: <20060413100255.GB7416@hell.pl> Message-ID: On 4/13/06, Janusz A. Urbanowicz wrote: > On Wed, Apr 12, 2006 at 08:11:18PM -0500, Travis H. wrote: > > >From everything I read, serpent is the most conservative of the AES candidates. > > > > Are there any plans to incorporate it into gpg? If so, why not? ;-) > > The real question is why yes? Especially in the face of the XSL attack. > > if you want to use modern and trendy algorithm, you have AES. If > you're cryptographically conservative like me, there is 3DES. If > you're old school PGP there is IDEA and CAST. If you're Schneier's > follower, there is Blowfish. What qualities do Serpent have that the > abovementioned lack? > Don't forget Twofish ;-) Twofish is also already implemented in GnuPG (S10), was an AES finalist, and (most importantly) has the added advantage over Serpent and AES of appearing resistant to the XSL attack. (I'm aware that at least the application of XSL to AES is in dispute.) From mschoch at gmail.com Tue Apr 18 10:39:43 2006 From: mschoch at gmail.com (Martin Schoch) Date: Tue Apr 18 12:26:16 2006 Subject: Public Key Servers ? Message-ID: <41898051.20060418103943@gmail.com> Hello Where do I find a list of gpg public key servers which is really up do date? It seems to me that a lot of servers are out ouf order... -- Best regards, Martin mailto:mschoch@gmail.com From Holger.Sesterhenn at smgwtest.aachen.utimaco.de Tue Apr 18 15:57:17 2006 From: Holger.Sesterhenn at smgwtest.aachen.utimaco.de (Holger Sesterhenn) Date: Tue Apr 18 17:26:10 2006 Subject: Set preferred keyserver during key generation and on existing keysautomatically Message-ID: <4444F03D.5080409@smgwtest.aachen.utimaco.de> Hi, using --edit and the command "keyserver" it is possible to set a keyserver URL which is used by PGP Universal as a hint to create OpenPGP/MIME messages. Well, I have to set this flag for about 1000 existing keys... and for all keys created in the future! The keys are generated automatically with unattended key generation (explained in doc/DETAILS). I know the notation 'preferred-email-encoding' would be the better way. Using -N and creating new self-sigs is a solution but unfortunately PGP Universal (at least version 2.03) does not know this flag. I have found "sig-keyserver-url" which is for data signatures. Is there a similar flag for cert signatures? Any idea how to set the preferred keyserver during generation? -- Best Regards, Holger Sesterhenn From david.armour at st.com Sun Apr 16 06:37:06 2006 From: david.armour at st.com (David ARMOUR) Date: Thu Apr 20 13:39:14 2006 Subject: GPGME v1.0.3 on Win32 Message-ID: <000a01c6610f$6c925190$e480fb0a@st.com> Hi! I saw a previous thread from 2002 on the subject of compiling GPGME which stated I must use: ./autogen.sh ./configure make I am trying to compile GPGME library 1.0.3 for Win32 using the MinGW compiler and MSYS environment. I noticed that the source does not come with a AUTOGEN.SH so no way to do the things suggested above. What I did do was ./configure which succeeded. Then I typed MAKE but I get a lot of errors and the make aborts: *********************************************************************************************** make all-recursive make[1]: Entering directory `/c/sdk/gpgme-1.0.3' Making all in gpgme make[2]: Entering directory `/c/sdk/gpgme-1.0.3/gpgme' make all-am make[3]: Entering directory `/c/sdk/gpgme-1.0.3/gpgme' if /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/local/include -g -O2 -Wall -Wcast-align -W shadow -Wstrict-prototypes -MT ath-compat.lo -MD -MP -MF ".deps/ath-compat.Tpo" -c -o ath-compat.lo ath-compat.c; \ then mv -f ".deps/ath-compat.Tpo" ".deps/ath-compat.Plo"; else rm -f ".deps/ath-compat.Tpo"; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/local/include -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT ath-compat.lo -MD -MP -MF .deps/ath-compat.Tpo -c ath-compat.c -DDLL_EXPORT -DPIC -o .libs/ath-compat.o In file included from c:/sdk/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/unistd.h:9, from ath-compat.c:25: ./io.h:45: error: syntax error before "size_t" ./io.h:46: error: syntax error before "size_t" ./io.h:61: error: syntax error before "size_t" In file included from ath-compat.c:36: ath.h:30:24: sys/socket.h: No such file or directory In file included from ath-compat.c:36: ath.h:69: error: syntax error before "fd_set" ath.h:70: warning: function declaration isn't a prototype ath.h:72: error: syntax error before "socklen_t" ath.h:72: warning: function declaration isn't a prototype ath.h:73: error: syntax error before "socklen_t" ath.h:73: warning: function declaration isn't a prototype ath.h:74: warning: "struct msghdr" declared inside parameter list ath.h:74: warning: its scope is only this definition or declaration, which is probably not what you want ath.h:75: warning: "struct msghdr" declared inside parameter list ath.h:87: error: syntax error before "fd_set" ath.h:88: warning: function declaration isn't a prototype ath.h:90: error: syntax error before "socklen_t" ath.h:90: warning: function declaration isn't a prototype ath.h:91: error: syntax error before "socklen_t" ath.h:91: warning: function declaration isn't a prototype ath.h:92: warning: "struct msghdr" declared inside parameter list ath.h:93: warning: "struct msghdr" declared inside parameter list ath-compat.c: In function `_gpgme_ath_read': ath-compat.c:113: warning: implicit declaration of function `read' ath-compat.c: In function `_gpgme_ath_write': ath-compat.c:123: warning: implicit declaration of function `write' ath-compat.c: At top level: ath-compat.c:128: error: syntax error before "fd_set" ath-compat.c:130: warning: function declaration isn't a prototype ath-compat.c: In function `_gpgme_ath_select': ath-compat.c:132: error: `nfd' undeclared (first use in this function) ath-compat.c:132: error: (Each undeclared identifier is reported only once ath-compat.c:132: error: for each function it appears in.) ath-compat.c:132: error: `rset' undeclared (first use in this function) ath-compat.c:132: error: `wset' undeclared (first use in this function) ath-compat.c:132: error: `eset' undeclared (first use in this function) ath-compat.c:132: error: `timeout' undeclared (first use in this function) ath-compat.c:134: warning: implicit declaration of function `select' ath-compat.c: In function `_gpgme_ath_waitpid': ath-compat.c:144: warning: implicit declaration of function `waitpid' ath-compat.c: At top level: ath-compat.c:149: error: syntax error before "socklen_t" ath-compat.c:150: warning: function declaration isn't a prototype ath-compat.c: In function `_gpgme_ath_accept': ath-compat.c:152: error: `s' undeclared (first use in this function) ath-compat.c:152: error: `addr' undeclared (first use in this function) ath-compat.c:152: error: `length_ptr' undeclared (first use in this function) ath-compat.c:154: warning: implicit declaration of function `accept' ath-compat.c: At top level: ath-compat.c:159: error: syntax error before "socklen_t" ath-compat.c:160: warning: function declaration isn't a prototype ath-compat.c: In function `_gpgme_ath_connect': ath-compat.c:162: error: `s' undeclared (first use in this function) ath-compat.c:162: error: `addr' undeclared (first use in this function) ath-compat.c:162: error: `length' undeclared (first use in this function) ath-compat.c:164: warning: implicit declaration of function `connect' ath-compat.c: At top level: ath-compat.c:169: warning: "struct msghdr" declared inside parameter list ath-compat.c:170: error: conflicting types for '_gpgme_ath_sendmsg' ath.h:74: error: previous declaration of '_gpgme_ath_sendmsg' was here ath-compat.c:170: error: conflicting types for '_gpgme_ath_sendmsg' ath.h:74: error: previous declaration of '_gpgme_ath_sendmsg' was here ath-compat.c: In function `_gpgme_ath_sendmsg': ath-compat.c:172: warning: passing arg 2 of pointer to function from incompatible pointer type ath-compat.c:174: warning: implicit declaration of function `sendmsg' ath-compat.c: At top level: ath-compat.c:179: warning: "struct msghdr" declared inside parameter list ath-compat.c:180: error: conflicting types for '_gpgme_ath_recvmsg' ath.h:75: error: previous declaration of '_gpgme_ath_recvmsg' was here ath-compat.c:180: error: conflicting types for '_gpgme_ath_recvmsg' ath.h:75: error: previous declaration of '_gpgme_ath_recvmsg' was here ath-compat.c: In function `_gpgme_ath_recvmsg': ath-compat.c:182: warning: passing arg 2 of pointer to function from incompatible pointer type ath-compat.c:184: warning: implicit declaration of function `recvmsg' make[3]: *** [ath-compat.lo] Error 1 make[3]: Leaving directory `/c/sdk/gpgme-1.0.3/gpgme' make[2]: *** [all] Error 2 make[2]: Leaving directory `/c/sdk/gpgme-1.0.3/gpgme' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/c/sdk/gpgme-1.0.3' make: *** [all] Error 2 *********************************************************************************************** Can you please give me some advice on compiling or obtaining a pre-compiled Win32 MinGW compatible version of GPGME. David From eric.collins at slacorp.com Wed Apr 19 22:56:39 2006 From: eric.collins at slacorp.com (Eric Collins) Date: Thu Apr 20 13:39:23 2006 Subject: off_t bug in gpgme Message-ID: <1145480199.5969.128.camel@mocha.sanluisaviation.com> Hi, I compiled gpgme-1.0.3 on a Pentium 3 system running CentOS 4.3. The configure script produced a config.h that enables 64 bit file offset (eg #define _FILE_OFFSET_BITS 64). In sys/types.h this makes off_t a 64-bit value. However, when I compile my user program that uses gpgme it does not define FILE_OFFSET_BITS 64 and so off_t is set to a 32-bit value. In this case, gpgme_data_seek is getting the wrong value for whence and failing. I am not sure what the correct solution is. Should FILE_OFFSET_BITS 64 not be set in config.h on this platform or should my user program be defining it as well? For now I have rebuilt gpgme with --disable-largefile which has fixed the issue. More information availabe as needed. Thanks, --ec From wk at gnupg.org Thu Apr 20 16:19:29 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Apr 20 16:21:32 2006 Subject: off_t bug in gpgme In-Reply-To: <1145480199.5969.128.camel@mocha.sanluisaviation.com> (Eric Collins's message of "Wed, 19 Apr 2006 13:56:39 -0700") References: <1145480199.5969.128.camel@mocha.sanluisaviation.com> Message-ID: <87y7y0nxce.fsf@wheatstone.g10code.de> On Wed, 19 Apr 2006 13:56:39 -0700, Eric Collins said: > I am not sure what the correct solution is. Should FILE_OFFSET_BITS 64 > not be set in config.h on this platform or should my user program be Please read the section on large file support in the gpgme manual. It is discussed there. Salam-Shalom, Werner From gnupg.org at salvisberg.com Fri Apr 21 09:35:46 2006 From: gnupg.org at salvisberg.com (gnupg.org@salvisberg.com) Date: Fri Apr 21 10:56:04 2006 Subject: gpg.exe sometimes hangs solidly under Win2K Message-ID: <200604210735.k3L7Zkrp001807@host.idesigns.net> Email to submit@bugs.guug.de bounces, so I'll try my luck here: Package: gnupg Version: 1.4.3 I've started to use GPG a few weeks ago, and I found that 1.4.2.1 hung about 1 out of 10 times on my Win2K SP4. I just installed 1.4.3, and it hangs again after a few runs. This time I tried to run gpg --list-key and it replied gpg: checking the trustdb and hangs now. When it hangs, then I can't even kill it. A first kill attempt in SysInternals Process Explorer is ignored, and any subsequent attempts result in "Error terminating process: Access is denied." I can't even shut down Windows anymore, because Windows is unable to terminate the process, and I have to use the power switch. When one instance of gpg.exe hangs, then it becomes mostly unusable. Trivial commands like --version still work in another console window, but an attempt to do --list-keys or any other non-trivial command will hang, too. Here's a ProcExp stack trace of such a hanging instance: ntoskrnl.exe+0x68e35 SAVRT.SYS+0xac3d SYMEVENT.SYS+0x8640 ntdll.dll+0x8283 KERNEL32.dll+0x1c225 msvcrt.dll+0x1b8ef msvcrt.dll+0x1b6a1 gpg.exe+0x61f8c gpg.exe+0x6333a gpg.exe+0x622f6 gpg.exe+0x5da7a gpg.exe+0x5e751 gpg.exe+0x2ba5d gpg.exe+0x67c9 gpg.exe+0x11d9 gpg.exe+0x1223 KERNEL32.dll+0x28989 The open handles list shows only one interesting item, a semaphore called \BaseNamedObjects\shell.{210A4BA0-3AEA-1069-A2D9-08002B30309D} Usually, I run gpg.exe from File Commander for Windows (a Norton Commander clone), but FC/W is completely transparent, and this has also happened when running gpg.exe from Enigmail. The stack trace is from an instance in a plain console window and it's identical to one started from FC/W. gpg.conf: ------------------------------ # default-recipient-self # keyserver random.sks.keyserver.penguin.de keyserver wwwkeys.ch.pgp.net default-cert-level 3 keyserver-options auto-key-retrieve include-revoked include-subkeys include-disabled export-options export-clean-sigs export-clean-uids list-options show-sig-expire show-uid-validity no-mangle-dos-filenames no-secmem-warning no-emit-version no-greeting # If you installed idea.dll, uncomment the following line # load-extension Lib\idea ------------------------------ Thanks for looking into it and for providing a great tool! Hans From wk at gnupg.org Fri Apr 21 13:28:33 2006 From: wk at gnupg.org (Werner Koch) Date: Fri Apr 21 13:31:26 2006 Subject: gpg.exe sometimes hangs solidly under Win2K In-Reply-To: <200604210735.k3L7Zkrp001807@host.idesigns.net> (gnupg org's message of "Fri, 21 Apr 2006 03:35:46 -0400") References: <200604210735.k3L7Zkrp001807@host.idesigns.net> Message-ID: <87slo7kw0u.fsf@wheatstone.g10code.de> On Fri, 21 Apr 2006 03:35:46 -0400, Hans Salvisberg said: > Email to submit@bugs.guug.de bounces, so I'll try my luck here: You may use the web interface at http://bugs.gnupg.org (account guest/guest). > When one instance of gpg.exe hangs, then it becomes mostly unusable. > Trivial commands like --version still work in another console window, > but an attempt to do --list-keys or any other non-trivial command will > hang, too. Here's a ProcExp stack trace of such a hanging instance: There seems to be a problem with file locking. Please try using the option --lock-never or use Sysinternals file monitor to checkout the list of open files. Shalom-Salam, Werner From marcus.brinkmann at ruhr-uni-bochum.de Fri Apr 21 21:35:29 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Fri Apr 21 21:39:09 2006 Subject: GPGME v1.0.3 on Win32 In-Reply-To: <000a01c6610f$6c925190$e480fb0a@st.com> References: <000a01c6610f$6c925190$e480fb0a@st.com> Message-ID: <87mzeeiuwu.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Sun, 16 Apr 2006 12:37:06 +0800, David ARMOUR wrote: > > Hi! > > I saw a previous thread from 2002 on the subject of compiling GPGME which stated I must use: > > ./autogen.sh > ./configure > make > > I am trying to compile GPGME library 1.0.3 for Win32 using the MinGW compiler and MSYS environment. If you really want to build it yourself, here are a couple of hints. Otherwise, skip this paragraph and read on below. We currently only support cross compilation. This works just like any other cross compilation (using "--host i586-mingw32msvc" and the other appropriate options). Or you can check out the --build-w32 option to autogen.sh. > Can you please give me some advice on compiling or obtaining a > pre-compiled Win32 MinGW compatible version of GPGME. For your convenience, we have a new project, GPG4Win, which contains GPGME and a lot of other GnuPG related packages. It is available from http://www.gpg4win.org/ The GPG4Win sources also contain all the information about how to cross build all these tools, but of course only indirectly via the automated build rules. Thanks, Marcus From rjh at sixdemonbag.org Fri Apr 21 23:26:17 2006 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri Apr 21 23:25:26 2006 Subject: GnuPG locks when reading keyring in an automated script Message-ID: <44494DF9.5020508@sixdemonbag.org> For a class project in human-computer interaction, I'm writing a key manager interface for GnuPG. We're using Java/SWT (runs just fine in GCJ), and use GnuPG via the command line. One of the beta users has run into a persistent problem where GnuPG blocks indefinitely at some point in giving us the key information. Recently, this problem has been reproducible on my own setup, too. A quick outline of the code, and how we are invoking GnuPG, follows. GnuPG is being invoked with "--fixed-list-mode --with-colons --fingerprint --fingerprint --command-fd 0 --status-fd 1 --list-keys". The loop of Java code which reads in this data looks as such: // rv is an ArrayList // ir is an input reader (really, a BufferedReader) String line = ir.readLine(); while (line != null) { System.out.println(line); if (! line.equals("")) { String[] elems = line.split(":"); ArrayList row = new ArrayList(); for (int x = 0 ; x < elems.length ; x++) row.add(elems[x]); rv.add(row); } System.out.print("Reading... "); line = ir.readLine(); } The output statements here are only for purposes of showing the error, of course. The output which I am getting looks like--trimming the output both for sake of brevity and to protect the privacy of this person's email address-- Reading... uid:-::::1072805884::E63E9873ED6... Reading... uid:-::::1072805999::4E82073DB5D... Reading... uid:-::::1072805979::2B2EEEC3B23... Reading... uid:-::::1072806025::66D07D8ACCD... Reading... uid:-::::1072805917::26D9960CD42... Reading... ... Doing this same thing at the command-line works fine. It's only when trying to read this from Java that it gets wedged. Doing this from the command-line, it appears GnuPG is wedging about 35% of the way through my keyring. The beta user who originally reported this problem had it hit him when he was entirely done with the keyring--GnuPG would block instead of closing the filehandle. This behavior exists with GnuPG 1.4.3. It didn't manifest in 1.4.2.2, but that may not be saying much, given the error appears somewhat nondeterministic. The code works without any error on OS X, several Linux distros and FreeBSD (OS X using Java 5, Linux using both Java 5 and GCJ, FreeBSD using GCJ). Thus, a couple of questions: 1. Can anyone point me towards a solution or workaround? 2. Does anyone know precisely what I'm doing wrong? (Please note that I don't claim to be a brilliant Win32 programmer; I try to avoid Win32 when possible. Thus, it's very possible I'm doing something that makes sense in UNIX which is stupid in Windows.) 3. If this is a GnuPG bug, what additional information can I give to help track this one down? From david.armour at st.com Sat Apr 22 06:30:17 2006 From: david.armour at st.com (David ARMOUR) Date: Sat Apr 22 07:11:14 2006 Subject: GPGME v1.0.3 on Win32 In-Reply-To: <87mzeeiuwu.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <001501c665c5$792f6630$5e05fd0a@st.com> Marcus, In order to build the tools with a cross-compiler, can I do it with CYGWIN on a Win32 platform or must I do it in a true UNIX platform, like LINUX? Thanks for the info about GPG4WIN. Thanks, David -----Original Message----- From: Marcus Brinkmann [mailto:marcus.brinkmann@ruhr-uni-bochum.de] Sent: Saturday, April 22, 2006 03:35 To: David ARMOUR Cc: gnupg-devel@gnupg.org Subject: Re: GPGME v1.0.3 on Win32 At Sun, 16 Apr 2006 12:37:06 +0800, David ARMOUR wrote: > > Hi! > > I saw a previous thread from 2002 on the subject of compiling GPGME which stated I must use: > > ./autogen.sh > ./configure > make > > I am trying to compile GPGME library 1.0.3 for Win32 using the MinGW compiler and MSYS environment. If you really want to build it yourself, here are a couple of hints. Otherwise, skip this paragraph and read on below. We currently only support cross compilation. This works just like any other cross compilation (using "--host i586-mingw32msvc" and the other appropriate options). Or you can check out the --build-w32 option to autogen.sh. > Can you please give me some advice on compiling or obtaining a > pre-compiled Win32 MinGW compatible version of GPGME. For your convenience, we have a new project, GPG4Win, which contains GPGME and a lot of other GnuPG related packages. It is available from http://www.gpg4win.org/ The GPG4Win sources also contain all the information about how to cross build all these tools, but of course only indirectly via the automated build rules. Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Sat Apr 22 09:50:01 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Sat Apr 22 09:51:02 2006 Subject: GPGME v1.0.3 on Win32 In-Reply-To: <001501c665c5$792f6630$5e05fd0a@st.com> References: <87mzeeiuwu.wl%marcus.brinkmann@ruhr-uni-bochum.de> <001501c665c5$792f6630$5e05fd0a@st.com> Message-ID: <87bquuhwwm.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Sat, 22 Apr 2006 12:30:17 +0800, David ARMOUR wrote: > > Marcus, > > In order to build the tools with a cross-compiler, can I do it with CYGWIN > on a Win32 platform or must I do it in a true UNIX platform, like LINUX? I am not sure. We use GNU/Linux, so I don't have any experience compiling on Cygwin. In the worst case, you could run GNU/Linux in an emulated or virtualised environment (Qemu, Xen, ...). From a quick google search, it appears that there is some support in Cygwin to do this, and the MingW installation for Cygwin should enable this support (I am talking about the -mno-cygwin compiler option). However, there also some caveats, and it seems you won't get identical results (but hopefully compatible ones). If you try it out, why not let us know how it went? It certainly sounds like fun and has hack-value. The safe bet, and likely the simpler and less time consuming, however, is to use GNU/Linux. Thanks, Marcus From gnupg.org at salvisberg.com Sun Apr 23 04:01:26 2006 From: gnupg.org at salvisberg.com (gnupg.org@salvisberg.com) Date: Sun Apr 23 04:00:37 2006 Subject: gpg.exe sometimes hangs solidly under Win2K Message-ID: <200604230201.k3N21Q0D011933@host.idesigns.net> Thank you for your reply! Werner Koch wrote: > On Fri, 21 Apr 2006 03:35:46 -0400, Hans Salvisberg said: > >> Email to submit@bugs.guug.de bounces, so I'll try my luck here: > > You may use the web interface at http://bugs.gnupg.org (account > guest/guest). Ok, I will, but since I already have your attention, I'll reply here for now, if I may. >> When one instance of gpg.exe hangs, then it becomes mostly unusable. >> Trivial commands like --version still work in another console window, >> but an attempt to do --list-keys or any other non-trivial command will >> hang, too. Here's a ProcExp stack trace of such a hanging instance: > > There seems to be a problem with file locking. Please try using the > option --lock-never or use Sysinternals file monitor to checkout the > list of open files. I'm scared of disabling file locking, because I have Thunderbird and Enigmail open most of the time and run gpg.exe in a console window. --lock-never Disable locking entirely. This option should be used only in very special environments, where it can be assured that only one process is accessing those files. A bootable floppy with a stand-alone encryption system will probably use this. Improper usage of this option may lead to data and key cor- ruption. This is definitely not the case here and I don't want to risk data or key corruption. I started FileMon and did --edit-keys, selected a uid, did delsig and save, at which point it hung again. FileMon showed the following three interesting lines just before the hang: OPEN ...\pubring.tmp Options:OpenIf Access:All OPEN ...\pubring.tmp FILE NOT FOUND Options:Open Access:All OPEN ...\pubring.tmp FILE NOT FOUND Options:Open Access:All There was one more line (I failed to write that down) and then it hung, more solidly than ever, locking up the desktop so that I couldn't even bring ProcExp to the top anymore. After a hard reset, I find pubring.tmp on the disk, length 0, and I'm able to run the same sequence of commands. FileMon does show some odd records again though: QUERY INFO ...\pubring.tmp SUCCESS Attributes:A OPEN ...\pubring.gpg SUCCESS Options:Open Access:All OPEN ...\pubring.gpg FILE NOT FOUND Options:Open Access:All OPEN ...\pubring.gpg FILE NOT FOUND Options:Open Access:All and right before terminating (19 lines omitted) CLOSE ...\trustdb.gpg SUCCESS OPEN ...\trustdb.gpg ACCESS DENIED HS OPEN ...\trustdb.gpg ACCESS DENIED HS These are the very last lines before terminating, but it does terminate normally. However, trying to run --edit-keys again causes it to hang very quickly, after successful OPEN, QUERY INFO, and CLOSE of ...\trustdb.gpg. This run has not produced any errors in FileMon, and the open handles in ProcExp are Desktop \Default Directory \BaseNamedObjects Directory \Windows Directory \KnownDlls File C:\Program Files\GNU\GnuPG (actually a directory!) Key HKCU Key HKLM Semaphore \BaseNamedObjects\shell.{210A4BA0-3AEA-1069-A2D9-08002B30309D} WindowStation \Windows\WindowStations\WinSta0 WindowStation \Windows\WindowStations\WinSta0 Does this help? Hans P.S. I'll be away from my computer next week and won't be able to reply before the weekend. From ueno at unixuser.org Mon Apr 24 09:30:35 2006 From: ueno at unixuser.org (Daiki Ueno) Date: Mon Apr 24 09:29:55 2006 Subject: [PATCH] libksba bug in building OCSP request Message-ID: Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1890 bytes Desc: S/MIME Digital Signature Url : /pipermail/attachments/20060424/97cdd246/smime.bin From wk at gnupg.org Tue Apr 25 14:24:24 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Apr 25 14:26:21 2006 Subject: Set preferred keyserver during key generation and on existing keysautomatically In-Reply-To: <4444F03D.5080409@smgwtest.aachen.utimaco.de> (Holger Sesterhenn's message of "Tue, 18 Apr 2006 15:57:17 +0200") References: <4444F03D.5080409@smgwtest.aachen.utimaco.de> Message-ID: <874q0hn8qv.fsf@wheatstone.g10code.de> On Tue, 18 Apr 2006 15:57:17 +0200, Holger Sesterhenn said: > Well, I have to set this flag for about 1000 existing keys... and for > all keys created in the future! So just add this feature to GnuPG; it is Free Software. Hmmm, you don't want to maintain your own version? Then why not contract with a company supporting GnuPG? There is currently just one listed http://www.gnupg.org/service.html but it should not be to hard to find other companies doing that for you. I recall that we talked about a support contract in the past but your manager refused that. From what I know the OpenPGP version of Utimaco's crypto gateway sells pretty well... Shalom-Salam, Werner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : /pipermail/attachments/20060425/9fbf5c76/attachment.pgp From wk at gnupg.org Wed Apr 26 13:29:06 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Apr 26 13:47:23 2006 Subject: [Announce] Gpg4win 1.0.1 released In-Reply-To: <8764lld2fy.fsf@wheatstone.g10code.de> (Werner Koch's message of "Fri, 07 Apr 2006 13:56:17 +0200") References: <8764lld2fy.fsf@wheatstone.g10code.de> Message-ID: <871wvkk22l.fsf@wheatstone.g10code.de> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From johnmoore3rd at joimail.com Thu Apr 20 18:26:09 2006 From: johnmoore3rd at joimail.com (John W. Moore III) Date: Tue May 16 11:39:21 2006 Subject: SHA224 Question Message-ID: <4447A454.4040002@joimail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 With the inclusion of SHA224 beginning with svn-4117 I have be unsuccessful in finding and documentation regarding this has in the release. I am assuming that it is *not* backward compatible with any pre-existing Key and am wondering if Keys generated with 4117 will support SHA224. Also, what type of Key is SHA224 designed for use with? I am assuming it has to do with the 'new' DSA Keys; but I am often wrong when I assume. Please NOTE: I am *not* a Member of this mailing list and therefore will not be able to read any Reply posted here. If this list isn't 'Closed' I would appreciate a link for registration. JOHN :) Timestamp: Thursday 20 Apr 2006, 11:09 --400 (Eastern Daylight Time) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4-svn4117: (MingW32) Comment: Public Key at: http://tinyurl.com/8cpho Comment: Gossamer Spider Web of Trust (US26): http://www.gswot.org Comment: Homepage: http://tinyurl.com/9ubue Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBCAAGBQJER6RMAAoJEBCGy9eAtCsPBkIH/3rPZdVXWgqjadbogwc4fcxK 1vCH5Zn8ODRbuqxQtgsfO+qyJwNagBV1I/QiawzN9bCDJUbS7eMvWf8VT5oH+F0u I5jS3+9fXVRtxzARQ/KfzIBOuAiUXIpaZxH5+n4Vekb5uOz9LNRYXl87moJ5gDy+ jZWJSNfXceQAU/IIkLo4VsDbGcSwSwTU4EAayTpEoYd369TIJzLdyT71LSIgK+P9 IE8aK5Fl9ZdAq2FkV7/Gxa/BP0ku5EmhOWo7VNoQe4o/pVdAZnnQf9nnakmVnb0C s3i9dx+tzulTVkVYWQtW0sV0u+un70b9AlR0gN8U5Vj3uXYs3xwj3h19N/p4xPI= =K1gG -----END PGP SIGNATURE----- From Joerg.Honegger at hp.com Thu Apr 27 16:56:01 2006 From: Joerg.Honegger at hp.com (Honegger, Joerg) Date: Tue May 16 11:39:27 2006 Subject: Tru64 cc: Pointer mismatch warnings not suppressed because of an error in the configure script Message-ID: <34BC148854A945478F102E09A1272C1C02C3DB6D@BSWEXC01.emea.cpqcorp.net> Dear all I am just installing GnuPG on some HP Tru64 UNIX Version 5.1B-3 systems. C compiler version: Compaq C V6.5-011 on Compaq Tru64 UNIX V5.1B (Rev. 2650) Compiler Driver V6.5-003 (sys) cc Driver Pointer mismatch warnings during the compilation are not suppressed because there is a tipo (ptrmismatch instead of ptrmismatch1) in the GnuPG configure script. The following code sequence *-dec-osf5*) if test -z "$GCC" ; then # Use the newer compiler `-msg_disable ptrmismatch' to # get rid of the unsigned/signed char mismatch warnings. # Using this may hide other pointer mismatch warnings, but # it at least lets other warning classes through CFLAGS="$CFLAGS -msg_disable ptrmismatch" should be changed to: *-dec-osf5*) if test -z "$GCC" ; then # Use the newer compiler `-msg_disable ptrmismatch1' to # get rid of the unsigned/signed char mismatch warnings. # Using this may hide other pointer mismatch warnings, but # it at least lets other warning classes through CFLAGS="$CFLAGS -msg_disable ptrmismatch1" The compiler option is also misspelled in the GnuPG README file. In section "Specific problems on some machines" the option "-msg-disable" should be changed to "-msg_disable". Furthermore it is not mentioned that the configure script now uses this option by default. Best Regards J?rg Honegger