From d.paleino at gmail.com Tue Jan 6 10:58:26 2009 From: d.paleino at gmail.com (David Paleino) Date: Tue, 6 Jan 2009 10:58:26 +0100 Subject: Keyrings file format Message-ID: <20090106105826.2b34ebca@gmail.com> Hello [0], I'm writing a CLI library (in C# -- to be used with all CLRs, i.e. Mono, .NET and DotGNU Portable .NET) to give GnuPG's functionalities to "end-developers". My library currently parses the output of `gpg --with-colons`, but I'd like to give its users the ability to directly act on the keyrings in ~/.gnupg/. Is the format documented anywhere? Kindly, David Paleino [0] I did a quick search in the list archives to check whether the topic had already been discussed, but didn't find anything relevant. Please excuse me and be so kind to point me at the right direction if this is not the case. -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 ----|---- http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From d.paleino at gmail.com Tue Jan 6 11:05:40 2009 From: d.paleino at gmail.com (David Paleino) Date: Tue, 6 Jan 2009 11:05:40 +0100 Subject: Keyrings file format References: <20090106105826.2b34ebca@gmail.com> Message-ID: <20090106110540.772a8789@gmail.com> On Tue, 6 Jan 2009 10:58:26 +0100, David Paleino wrote: > [0] I did a quick search in the list archives to check whether the topic had > already been discussed, but didn't find anything relevant. Please excuse me > and be so kind to point me at the right direction if this is not the case. Funny enough, right after sending the mail I found: Any suggestion is very welcome though. Kindly, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 ----|---- http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From dshaw at jabberwocky.com Tue Jan 6 14:27:23 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 6 Jan 2009 08:27:23 -0500 Subject: Keyrings file format In-Reply-To: <20090106105826.2b34ebca@gmail.com> References: <20090106105826.2b34ebca@gmail.com> Message-ID: On Jan 6, 2009, at 4:58 AM, David Paleino wrote: > Hello [0], > I'm writing a CLI library (in C# -- to be used with all CLRs, i.e. > Mono, .NET > and DotGNU Portable .NET) to give GnuPG's functionalities to "end- > developers". > > My library currently parses the output of `gpg --with-colons`, but > I'd like to > give its users the ability to directly act on the keyrings in > ~/.gnupg/. > > Is the format documented anywhere? A GnuPG keyring is defined in RFC-4880 (http://tools.ietf.org/html/rfc4880 ). Basically the pubring is a series of "Transferable Public Keys" (section 11.1) concatenated together. The secring is a series of "Transferable Secret Keys" (section 12.1) concatenated together. Note, though, section 3.6 of the RFC: 3.6. Keyrings A keyring is a collection of one or more keys in a file or database. Traditionally, a keyring is simply a sequential list of keys, but may be any suitable database. It is beyond the scope of this standard to discuss the details of keyrings or other databases. It is perfectly legal for a program to use some internal method for storing keys that isn't the traditional "file with a lot of key packets" method. The only thing that is required is that the transferable (i.e. exported) format conforms to the spec. If you really want to really future-proof yourself against potential storage format changes, avoid reading pubring.gpg or secring.gpg yourself, and instead have your library parse the output of "gpg --export" or "gpg -- export-secret-keys". Today, these are identical, but in the future, they might not be. All that said, what are you trying to do, exactly? What information do you need to get from the keys that isn't available now? David From wk at gnupg.org Tue Jan 6 15:40:05 2009 From: wk at gnupg.org (Werner Koch) Date: Tue, 06 Jan 2009 15:40:05 +0100 Subject: Keyrings file format In-Reply-To: (David Shaw's message of "Tue, 6 Jan 2009 08:27:23 -0500") References: <20090106105826.2b34ebca@gmail.com> Message-ID: <877i58ebwa.fsf@wheatstone.g10code.de> On Tue, 6 Jan 2009 14:27, dshaw at jabberwocky.com said: > transferable (i.e. exported) format conforms to the spec. If you > really want to really future-proof yourself against potential storage > format changes, avoid reading pubring.gpg or secring.gpg yourself, and And actually this future is not that far away. For various reasons (e.g. meta data) we will for sure see a different format used this year. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From rjh at sixdemonbag.org Tue Jan 6 16:18:56 2009 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 06 Jan 2009 10:18:56 -0500 Subject: Keyrings file format In-Reply-To: <877i58ebwa.fsf@wheatstone.g10code.de> References: <20090106105826.2b34ebca@gmail.com> <877i58ebwa.fsf@wheatstone.g10code.de> Message-ID: <49637660.6090308@sixdemonbag.org> Werner Koch wrote: > And actually this future is not that far away. For various reasons > (e.g. meta data) we will for sure see a different format used this year. Is there any possibility of the new GnuPG keyring format being something easier to parse? Not necessarily XML (although I think that would be a good idea), but something less opaque than it currently is? From d.paleino at gmail.com Tue Jan 6 17:12:20 2009 From: d.paleino at gmail.com (David Paleino) Date: Tue, 6 Jan 2009 17:12:20 +0100 Subject: Keyrings file format References: <20090106105826.2b34ebca@gmail.com> Message-ID: <20090106171220.7973c468@gmail.com> Thank you for your reply. No need to CC me, though :) On Tue, 6 Jan 2009 08:27:23 -0500, David Shaw wrote: > On Jan 6, 2009, at 4:58 AM, David Paleino wrote: > > > Is the format documented anywhere? > > A GnuPG keyring is defined in RFC-4880 (http://tools.ietf.org/html/rfc4880 > ). ACK. I was already trying to understand the format of the files resulting from "gpgsplit", but the RFC is a bit obscure in some points, at least to me ;) > Basically the pubring is a series of "Transferable Public > Keys" (section 11.1) concatenated together. The secring is a series > of "Transferable Secret Keys" (section 12.1) concatenated together. This is a really useful bit of information, thank you. > Note, though, section 3.6 of the RFC: > > 3.6. Keyrings > > A keyring is a collection of one or more keys in a file or database. > Traditionally, a keyring is simply a sequential list of keys, but may > be any suitable database. It is beyond the scope of this standard to > discuss the details of keyrings or other databases. Agreed. > It is perfectly legal for a program to use some internal method for > storing keys that isn't the traditional "file with a lot of key > packets" method. The only thing that is required is that the > transferable (i.e. exported) format conforms to the spec. If you > really want to really future-proof yourself against potential storage > format changes, avoid reading pubring.gpg or secring.gpg yourself, and > instead have your library parse the output of "gpg --export" or "gpg -- > export-secret-keys". Today, these are identical, but in the future, > they might not be. Thank you for clarifying this. > All that said, what are you trying to do, exactly? What information > do you need to get from the keys that isn't available now? Nothing, probably I wasn't that much clear in my original post. Let me do an example, with some pseudo-code. A CLI (i.e. C#, VB.Net, IronPython, Nemerle, Boo, and other languages) developer wanting to provide signing/crypting/decrypting/... functionalities, would *currently* do (again, pseudo-code): --- raw_output = system("gpg --my arguments"); uid = do_some_magic(raw_output); --- What I want other developers to do is: --- using OpenPGP-Sharp; // that's the name of my library id = GetPrimaryID("0xAABBCCDD"); --- That is, I'm creating [0] a library with an easy-to-use API for other developers to use. [0] it basically works, because I'm providing an API, and do some "magic" mangling of the output of "gpg --with-colons --[..]" -- for "reading procedures". I haven't yet implemented any of the crypting/decrypting/signing things. So long, where's the problem in parsing --with-colons? -- you might ask. As there is no certainty on the format of the keyring itself, surely there isn't on the format of the output of --with-colons either. Also, I could've written a binding to libgpgme -- but that too reads gpg's output, so I preferred doing that myself to avoid one more layer of complexity / bugs / whatever. So, being both --with-colons and the keyring format uncertain, why adding one more layer (i.e. forking the gpg process from my current code, read its output, act consequently) to the code, if I can directly read the keyrings? The conclusion is: if it's too difficult, or does not give concrete advantages over the method I'm using now, then all the argumentation above is moot. But, if it gives concrete advantages (in terms of speed, for example), it might be worth a try, at least. Or, an option could be giving developers the chance to use whichever implementation they prefer/trust. Kindly, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 ----|---- http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From wk at gnupg.org Tue Jan 6 18:14:08 2009 From: wk at gnupg.org (Werner Koch) Date: Tue, 06 Jan 2009 18:14:08 +0100 Subject: Keyrings file format In-Reply-To: <49637660.6090308@sixdemonbag.org> (Robert J. Hansen's message of "Tue, 06 Jan 2009 10:18:56 -0500") References: <20090106105826.2b34ebca@gmail.com> <877i58ebwa.fsf@wheatstone.g10code.de> <49637660.6090308@sixdemonbag.org> Message-ID: <87sknwcq73.fsf@wheatstone.g10code.de> On Tue, 6 Jan 2009 16:18, rjh at sixdemonbag.org said: > Is there any possibility of the new GnuPG keyring format being something > easier to parse? Not necessarily XML (although I think that would be a That depends on your needs. It will be easier to parse than OpenPGP but still be an opaque format. However it uses length headers to describe a keyblock and thus skipping over a keyblock does not need intimate knowledge of OpenPGP. In fact it is the same format as used by gpgsm and already defined for years (gnupg/kbx/keybox-blob.c): The KeyBox uses an augmented OpenPGP/X.509 key format. This makes random access to a keyblock/certificate easier and also gives the opportunity to store additional information (e.g. the fingerprint) along with the key. All integers are stored in network byte order, offsets are counted from the beginning of the Blob. The first record of a plain KBX file has a special format: u32 length of the first record byte Blob type (1) byte version number (1) byte reserved byte reserved u32 magic 'KBXf' u32 reserved u32 file_created_at u32 last_maintenance_run u32 reserved u32 reserved The OpenPGP and X.509 blob are very similiar, things which are X.509 specific are noted like [X.509: xxx] u32 length of this blob (including these 4 bytes) byte Blob type (2) [X509: 3] byte version number of this blob type (1) u16 Blob flags bit 0 = contains secret key material bit 1 = ephemeral blob (e.g. used while quering external resources) u32 offset to the OpenPGP keyblock or X509 DER encoded certificate u32 and its length u16 number of keys (at least 1!) [X509: always 1] u16 size of additional key information n times: b20 The keys fingerprint (fingerprints are always 20 bytes, MD5 left padded with zeroes) u32 offset to the n-th key's keyID (a keyID is always 8 byte) or 0 if not known which is the case only for X509. u16 special key flags bit 0 = qualified signature (not yet implemented} u16 reserved u16 size of serialnumber(may be zero) n u16 (see above) bytes of serial number u16 number of user IDs u16 size of additional user ID information n times: u32 offset to the n-th user ID u32 length of this user ID. u16 special user ID flags. bit 0 = byte validity byte reserved [For X509, the first user ID is the Issuer, the second the Subject and the others are subjectAltNames] u16 number of signatures u16 size of signature information (4) u32 expiration time of signature with some special values: 0x00000000 = not checked 0x00000001 = missing key 0x00000002 = bad signature 0x10000000 = valid and expires at some date in 1978. 0xffffffff = valid and does not expire u8 assigned ownertrust [X509: not used] u8 all_validity OpenPGP: see ../g10/trustdb/TRUST_* [not yet used] X509: Bit 4 set := key has been revoked. Note that this value matches TRUST_FLAG_REVOKED u16 reserved u32 recheck_after u32 Newest timestamp in the keyblock (useful for KS syncronsiation?) u32 Blob created at u32 size of reserved space (not including this field) reserved space Here we might want to put other data Here comes the keyblock maybe we put a signature here later. b16 MD5 checksum (useful for KS syncronisation), we might also want to use a mac here. b4 reserved Not exactly what you desire but very helpful implementation wise. There is also the idea of an internal key listing daemon to get rid of file locking. There is a utility kbxdump which can be used to dump such a keybox file in a human readable format. The main advantage of this format is that there is no more need to parse an OpenPGP keyring all the way down to the desired key which for example includes the computation of fingerprints for all keys before the one we want. It also allows to get rid of sequential scans by having index entries, but experiments have shown that this is not the major performance hurdle. The OpenPGP parsing with the fingerprint computation is what makes operations on large keyrings very slow. The primary reason why the format is not yet used is that it will take some effort to automagically migrate to the new format without introducing too many hassles. -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dshaw at jabberwocky.com Wed Jan 7 05:52:17 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 6 Jan 2009 23:52:17 -0500 Subject: Keyrings file format In-Reply-To: <20090106171220.7973c468@gmail.com> References: <20090106105826.2b34ebca@gmail.com> <20090106171220.7973c468@gmail.com> Message-ID: <20090107045216.GA19991@jabberwocky.com> On Tue, Jan 06, 2009 at 05:12:20PM +0100, David Paleino wrote: > So long, where's the problem in parsing --with-colons? -- you might > ask. As there is no certainty on the format of the keyring itself, > surely there isn't on the format of the output of --with-colons > either. That is not correct. The whole point of --with-colons is that it is a stable interface. It exists for exactly what you are doing: being used from another program. David From rjh at sixdemonbag.org Wed Jan 7 06:04:06 2009 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 07 Jan 2009 00:04:06 -0500 Subject: Keyrings file format In-Reply-To: <20090107045216.GA19991@jabberwocky.com> References: <20090106105826.2b34ebca@gmail.com> <20090106171220.7973c468@gmail.com> <20090107045216.GA19991@jabberwocky.com> Message-ID: <496437C6.5030101@sixdemonbag.org> David Shaw wrote: > That is not correct. The whole point of --with-colons is that it is a > stable interface. It exists for exactly what you are doing: being > used from another program. I've written code to parse --with-colons a few times, and while I haven't found it very hard to get it working to the 90% point, strange or peculiar keys will often cause code to break or behave weirdly. A lot of this is due to the lack of a BNF for a key entry. E.g., my first time writing a parser for --with-colons, I assumed that every key possessed at least one UID. This assumption is not sound, as it's apparently possible to craft keys with no UIDs. It would be nice if in the HACKING document there was a concise BNF for the key format, to spare other people the headaches of discovering the sharp edges the hard way. From dshaw at jabberwocky.com Wed Jan 7 06:09:06 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 7 Jan 2009 00:09:06 -0500 Subject: Keyrings file format In-Reply-To: <496437C6.5030101@sixdemonbag.org> References: <20090106105826.2b34ebca@gmail.com> <20090106171220.7973c468@gmail.com> <20090107045216.GA19991@jabberwocky.com> <496437C6.5030101@sixdemonbag.org> Message-ID: On Jan 7, 2009, at 12:04 AM, Robert J. Hansen wrote: > David Shaw wrote: >> That is not correct. The whole point of --with-colons is that it >> is a >> stable interface. It exists for exactly what you are doing: being >> used from another program. > > I've written code to parse --with-colons a few times, and while I > haven't found it very hard to get it working to the 90% point, strange > or peculiar keys will often cause code to break or behave weirdly. A > lot of this is due to the lack of a BNF for a key entry. E.g., my > first > time writing a parser for --with-colons, I assumed that every key > possessed at least one UID. This assumption is not sound, as it's > apparently possible to craft keys with no UIDs. Yes and no. It's not just UIDs - you can mangle a key in dozens of different ways. GPG will then do its best to handle it, but fundamentally, that's a broken key. There isn't much that can be done with it. Speaking about UIDs specifically, there is no legal "front door" way to create such a key in GPG, as that key violates the spec. > It would be nice if in the HACKING document there was a concise BNF > for > the key format, to spare other people the headaches of discovering the > sharp edges the hard way. Do I hear a volunteer? ;) David From dshaw at jabberwocky.com Wed Jan 7 06:12:45 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 7 Jan 2009 00:12:45 -0500 Subject: Keyrings file format In-Reply-To: <49637660.6090308@sixdemonbag.org> References: <20090106105826.2b34ebca@gmail.com> <877i58ebwa.fsf@wheatstone.g10code.de> <49637660.6090308@sixdemonbag.org> Message-ID: <20090107051245.GB19991@jabberwocky.com> On Tue, Jan 06, 2009 at 10:18:56AM -0500, Robert J. Hansen wrote: > Werner Koch wrote: > > And actually this future is not that far away. For various reasons > > (e.g. meta data) we will for sure see a different format used this year. > > Is there any possibility of the new GnuPG keyring format being something > easier to parse? Not necessarily XML (although I think that would be a > good idea), but something less opaque than it currently is? I would hope that people don't use the new keyring format outside of GPG. It is opaque, and that is a feature, not a bug, as if it was used by other programs, then GnuPG could not change the format when and if it needs to. The OpenPGP spec guarantees that the *interchange* format is specified, and intentionally does not get involved in private storage questions for this very reason. If people want an XML (or whatever) format, that should be a project that stands on its own. Not arguing for or against it - just that I think it should be distinct from private internal formats. If I was designing a new keyring format, I don't think I'd use either XML or a concatenated format. Rather, I'd likely take a page from the Maildir format, and use a keyring directory full of files. It makes locking dead easy (see the Maildir algorithm over NFS, for example) but keeps the keys themselves in RFC-4880 "transferable" format, which can be handy. David From rjh at sixdemonbag.org Wed Jan 7 14:27:17 2009 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 07 Jan 2009 08:27:17 -0500 Subject: Keyrings file format In-Reply-To: References: <20090106105826.2b34ebca@gmail.com> <20090106171220.7973c468@gmail.com> <20090107045216.GA19991@jabberwocky.com> <496437C6.5030101@sixdemonbag.org> Message-ID: <4964ADB5.90707@sixdemonbag.org> David Shaw wrote: > Do I hear a volunteer? ;) If you guys are willing to field a lot of silly and asinine questions from me about all the various ways in which an OpenPGP key can be malformed but still recognizable to GnuPG -- well, then, sure. :) From d.paleino at gmail.com Wed Jan 7 14:41:02 2009 From: d.paleino at gmail.com (David Paleino) Date: Wed, 7 Jan 2009 14:41:02 +0100 Subject: Keyrings file format References: <20090106105826.2b34ebca@gmail.com> <20090106171220.7973c468@gmail.com> <20090107045216.GA19991@jabberwocky.com> Message-ID: <20090107144102.386dd8a3@gmail.com> On Tue, 6 Jan 2009 23:52:17 -0500, David Shaw wrote: > On Tue, Jan 06, 2009 at 05:12:20PM +0100, David Paleino wrote: > > > So long, where's the problem in parsing --with-colons? -- you might > > ask. As there is no certainty on the format of the keyring itself, > > surely there isn't on the format of the output of --with-colons > > either. > > That is not correct. The whole point of --with-colons is that it is a > stable interface. It exists for exactly what you are doing: being > used from another program. Well, I just hoped that, really. :) I will continue using --with-colons, but would be interested in trying to parse the keyring file -- it's a personal challenge now ;) David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 ----|---- http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From dshaw at jabberwocky.com Thu Jan 8 05:57:35 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 7 Jan 2009 23:57:35 -0500 Subject: Keyrings file format In-Reply-To: <4964ADB5.90707@sixdemonbag.org> References: <20090106105826.2b34ebca@gmail.com> <20090106171220.7973c468@gmail.com> <20090107045216.GA19991@jabberwocky.com> <496437C6.5030101@sixdemonbag.org> <4964ADB5.90707@sixdemonbag.org> Message-ID: <20090108045735.GA29107@jabberwocky.com> On Wed, Jan 07, 2009 at 08:27:17AM -0500, Robert J. Hansen wrote: > David Shaw wrote: > > Do I hear a volunteer? ;) > > If you guys are willing to field a lot of silly and asinine questions > from me about all the various ways in which an OpenPGP key can be > malformed but still recognizable to GnuPG -- well, then, sure. :) Excellent, go for it. David From wk at gnupg.org Fri Jan 9 13:12:55 2009 From: wk at gnupg.org (Werner Koch) Date: Fri, 09 Jan 2009 13:12:55 +0100 Subject: [Announce] Signing key updated Message-ID: <87zli0ada0.fsf@wheatstone.g10code.de> Hi! The key used to sign GnuPG releases expired at the end of last year. The original plan was to create a new key using a 2048 bit RSA capable smartcard. However those smartcards will become generally available only in a few months months and I need to crank out new releases earlier. Thus I decided to keep on using the existing key for another years. The OpenPGP protocol allows to change the expiration date of a key and that is what I did. Please update the copy of your key, either from a keyserver or using the one below. Shalom-Salam, Werner pub 1024R/1CE0C630 2006-01-01 [expires: 2009-12-31] Key fingerprint = 7B96 D396 E647 1601 754B E4DB 53B6 20D0 1CE0 C630 uid Werner Koch (dist sig) -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.9 (GNU/Linux) mI4EQ7f6xwEEANCZGXorXMkDKpNsRnf+ZhqHOPmDcEKPDkplcCL2PFACN7QaK4Re oWvZ4mqmVOL3ZXU51zFNI9aD3JAIToET2jr2hGYWFExdBf9eaYgBeXZGUOnbJl1V JDzWDGU6ZHNpwPiAAgYjpsoBgZCxbl7x0VtYukjc9vIkR/1GXGC4v9ohACCBVlCZ tCZXZXJuZXIgS29jaCAoZGlzdCBzaWcpIDxkZDlqbkBnbnUub3JnPoi8BBMBAgAm BQJDt/rIAhsDBQkFo5qABgsJCAcDAgQVAggDBBYCAwECHgECF4AACgkQU7Yg0Bzg xjB5owQAh0MO0kuQ7hM6AKj8YK4bRGapHBmeIniaer9Y6vwXgErfDUci7BUQTxXo FFTgKHHzBz39bzeStyQgTm5plGaOEJcJayIr07DaeBtcC/dMoVUJswybKMFtP7fU z05PRKjChvxrWzhe/Yn6BAmPF+6YxQo2W98rzq0THS5wKJjXmHyIRgQQEQIABgUC Q7gRQwAKCRBd4kmWWwNYopHmAJ92KI2MZ2P3+YxquJThye5KZo9AiQCeP7Nb1/1n YzQrav6CV0QLYTDbJOWIvAQTAQIAJgIbAwYLCQgHAwIEFQIIAwQWAgMBAh4BAheA BQJJZzlfBQkHhTItAAoJEFO2INAc4MYw66QEAKUlnH7ceUG3/8j83/9BRON0L7Jf OFwPx9UkcgxfiUEpN5dDpu+0BkLzX/F2FBt7vqeRbwxUBJIznGHEZ+MSVMoH56gA nepcmDVOab554LApgi6IMLz0niz1ASrWqZOow7QF6Wgn5ZVuQ/BzlH6xPmywEtQ7 38ugOh5IaH3ts/M5 =pSi0 -----END PGP PUBLIC KEY BLOCK----- Other locations of my keys are: gpg --fetch-key finger:wk at g10code.com gpg --fetch-key http://werner.eifelkommune.de/mykey.asc -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 205 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Fri Jan 9 13:16:06 2009 From: wk at gnupg.org (Werner Koch) Date: Fri, 09 Jan 2009 13:16:06 +0100 Subject: [Announce] Libksba 1.0.5 released Message-ID: <87tz88ad4p.fsf@wheatstone.g10code.de> Hello! We are pleased to announce version 1.0.5 of Libksba. Libksba is an X.509 and CMS (PKCS#7) library. It is for example required to build the S/MIME part of GnuPG-2 (gpgsm). The only build requirement for Libksba itself is the libgpg-error package. There are no other dependencies; actual cryptographic operations need to be done by the user. Libksba is distributed under the GPLv3+. There are no user tools accompanying this software, thus it is mostly relevant to developers. This is a maintenance release. You may download the library and its OpenPGP signature from: ftp://ftp.gnupg.org/gcrypt/libksba/libksba-1.0.5.tar.bz2 (555k) ftp://ftp.gnupg.org/gcrypt/libksba/libksba-1.0.5.tar.bz2.sig As an alternative you may use a patch file to upgrade the previous version of the library: ftp://ftp.gnupg.org/gcrypt/libksba/libksba-1.0.4-1.0.5.diff.bz2 (7k) or from any mirror of that server (http://www.gnupg.org/mirrors.html). SHA-1 checksums are: 2d5939d21f02142197158cd252b2725414a64b33 libksba-1.0.5.tar.bz2 46e4be795a04777be98e1f265773da845d6a28f8 libksba-1.0.4-1.0.5.diff.bz2 Noteworthy changes in version 1.0.5 (2009-01-09) ------------------------------------------------ * Minor bug fixes. Commercial support contracts for Libksba are available, and they help finance continued maintenance. g10 Code, a Duesseldorf based company owned and headed by Libksba's principal author, is currently funding its development. We are always looking for interesting development projects. See also http://www.gnupg.org/service.html . Happy hacking, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 205 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From ulrich.windl at rz.uni-regensburg.de Fri Jan 9 14:10:53 2009 From: ulrich.windl at rz.uni-regensburg.de (Ulrich Windl) Date: Fri, 09 Jan 2009 14:10:53 +0100 Subject: Problem with key directory on Linux "vfat" Message-ID: <49675AF0.29721.546DAF8@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de> Hello, I just found this problem in openSUSE 11.0: When the GnuPG key directory is on a fvat filesystem (e.g. a memory stick), there are some warnings (German locale) in Linux: gpg: WARNUNG: Unsicheres Besitzverh?ltnis des Home-Verzeichnis `.gnupg' gpg: lock not made: link() failed: Die Operation ist nicht erlaubt gpg: can't lock `.gnupg/pubring.gpg' gpg: DBG: oops, `.gnupg/pubring.gpg.lock' is not locked gpg: Schl?sselblockhilfsmittel`.gnupg/pubring.gpg': Allgemeiner Fehler gpg: Unterschrift vom Do 08 Jan 2009 18:23:55 CET mittels RSA-Schl?ssel ID 3DBDC284 So it seems GnuPG does locking by linking. AFAIK links are not available on vfat filesystems. I don't know a good solution, but I thought I'd let you know. Maybe open(..., O_CREAT|O_EXCL|...) could be used for an atomic (from the local OS) lock. Maybe simple advisory locks would also do. I don't know. Regards, Ulrich From wk at gnupg.org Mon Jan 12 10:55:53 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 12 Jan 2009 10:55:53 +0100 Subject: [Announce] GnuPG 2.0.10 released Message-ID: <87eiz897bq.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG-2 release: Version 2.0.10. The GNU Privacy Guard (GnuPG) is GNU's tool for secure communication and data storage. It can be used to encrypt data, create digital signatures, help authenticating using Secure Shell and to provide a framework for public key cryptography. It includes an advanced key management facility and is compliant with the OpenPGP and S/MIME standards. GnuPG-2 has a different architecture than GnuPG-1 (e.g. 1.4.9) in that it splits up functionality into several modules. However, both versions may be installed alongside without any conflict. In fact, the gpg version from GnuPG-1 is able to make use of the gpg-agent as included in GnuPG-2 and allows for seamless passphrase caching. The advantage of GnuPG-1 is its smaller size and the lack of dependency on other modules at run and build time. We will keep maintaining GnuPG-1 versions because they are very useful for small systems and for server based applications requiring only OpenPGP support. GnuPG is distributed under the terms of the GNU General Public License (GPL version 3). GnuPG-2 works best on GNU/Linux or *BSD systems. What's New =========== * [gpg] New keyserver helper gpg2keys_kdns as generic DNS CERT lookup. Run with --help for a short description. Requires the ADNS library. * [gpg] New mechanisms "local" and "nodefault" for --auto-key-locate. Fixed a few problems with this option. * [gpg] New command --locate-keys. * [gpg] New options --with-sig-list and --with-sig-check. * [gpg] The option "-sat" is no longer an alias for --clearsign. * [gpg] The option --fixed-list-mode is now implicitly used and obsolete. * [gpg] New control statement %ask-passphrase for the unattended key generation. * [gpg] The algorithm to compute the SIG_ID status has been changed. * [gpgsm] Now uses AES by default. * [gpgsm] Made --output option work with --export-secret-key-p12. * [gpg-agent] Terminate process if the own listening socket is not anymore served by ourself. * [scdaemon] Made it more robust on W32. * [gpg-connect-agent] Accept commands given as command line arguments. * [w32] Initialized the socket subsystem for all keyserver helpers. * [w32] The sysconf directory has been moved from a subdirectory of the installation directory to %CSIDL_COMMON_APPDATA%/GNU/etc/gnupg. * [w32] The gnupg2.nls directory is not anymore used. The standard locale directory is now used. * [w32] Fixed a race condition between gpg and gpgsm in the use of temporary file names. * The gpg-preset-passphrase mechanism works again. An arbitrary string may now be used for a custom cache ID. * Admin PINs are cached again (bug in 2.0.9). * Support for version 2 OpenPGP cards. * Libgcrypt 1.4 is now required. Getting the Software ==================== Please follow the instructions found at http://www.gnupg.org/download/ or read on: GnuPG 2.0.10 may be downloaded from one of the GnuPG mirror sites or direct from ftp://ftp.gnupg.org/gcrypt/gnupg/ . The list of mirrors can be found at http://www.gnupg.org/mirrors.html . Note, that GnuPG is not available at ftp.gnu.org. On the FTP server and its mirrors you should find the following files in the gnupg/ directory: gnupg-2.0.10.tar.bz2 (3736k) gnupg-2.0.10.tar.bz2.sig GnuPG source compressed using BZIP2 and OpenPGP signature. gnupg-2.0.9-2.0.10.diff.bz2 (264k) A patch file to upgrade a 2.0.9 GnuPG source tree. This patch does not include updates of the language files. Note, that we don't distribute gzip compressed tarballs for GnuPG-2. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a trusted version of GnuPG installed, you can simply check the supplied signature. For example to check the signature of the file gnupg-2.0.10.tar.bz2 you would use this command: gpg --verify gnupg-2.0.10.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. Note, that you can retrieve the signing key using the command finger wk ,at' g10code.com or using a keyserver like gpg --recv-key 1CE0C630 The distribution key 1CE0C630 is signed by the well known key 5B0358A2. If you get an key expired message, you should retrieve a fresh copy as the expiration date might have been prolonged. NEVER USE A GNUPG VERSION YOU JUST DOWNLOADED TO CHECK THE INTEGRITY OF THE SOURCE - USE AN EXISTING GNUPG INSTALLATION! * If you are not able to use an old version of GnuPG, you have to verify the SHA-1 checksum. Assuming you downloaded the file gnupg-2.0.10.tar.bz2, you would run the sha1sum command like this: sha1sum gnupg-2.0.10.tar.bz2 and check that the output matches the first line from the following list: d25e41a8cc607334b707d13af819ceaa217800b5 gnupg-2.0.10.tar.bz2 2a375f4d6cb171f3358bce2b6b3a26ba208ab3ac gnupg-2.0.9-2.0.10.diff.bz2 Internationalization ==================== GnuPG comes with support for 27 languages. Due to a lot of new and changed strings many translations are not entirely complete. Jedi, Maxim Britov, Jaime Su?rez and Nilg?n Belma Bug?ner have been kind enough to go over their translations and thus the Chinese, German, Russian, Spanish, and Turkish translations are pretty much complete. Documentation ============= We are currently working on an installation guide to explain in more detail how to configure the new features. As of now the chapters on gpg-agent and gpgsm include brief information on how to set up the whole thing. Please watch the GnuPG website for updates of the documentation. In the meantime you may search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. KDE's KMail is the most prominent user of GnuPG-2. In fact it has been developed along with the KMail folks. Mutt users might want to use the configure option "--enable-gpgme" and "set use_crypt_gpgme" in ~/.muttrc to make use of GnuPG-2 to enable S/MIME in addition to a reworked OpenPGP support. The manual is also available online in HTML format at http://www.gnupg.org/documentation/manuals/gnupg/ and in Portable Document Format at http://www.gnupg.org/documentation/manuals/gnupg.pdf . Support ======= Improving GnuPG is costly, but you can help! We are looking for organizations that find GnuPG useful and wish to contribute back. You can contribute by reporting bugs, improve the software, order extensions or support or more general by donating money to the Free Software movement (e.g. http://www.fsfeurope.org/help/donate.en.html). Commercial support contracts for GnuPG are available, and they help finance continued maintenance. g10 Code GmbH, a Duesseldorf based company owned and headed by GnuPG's principal author, is currently funding GnuPG development. We are always looking for interesting development projects. The GnuPG service directory is available at: http://www.gnupg.org/service.html Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word or answering questions on the mailing lists. Happy Hacking, The GnuPG Team (David, Marcus, Werner and all other contributors) -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 205 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From bernhard at intevation.de Tue Jan 13 15:04:24 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 13 Jan 2009 15:04:24 +0100 Subject: Keyrings file format In-Reply-To: <20090106171220.7973c468@gmail.com> References: <20090106105826.2b34ebca@gmail.com> <20090106171220.7973c468@gmail.com> Message-ID: <200901131504.27546.bernhard@intevation.de> On Dienstag, 6. Januar 2009, David Paleino wrote: > Also, I could've written a binding to libgpgme -- but that too reads gpg's > output, so I preferred doing that myself to avoid one more layer of > complexity / bugs / whatever. Actually I would prefer using libgpgme as this should wrap a few interface issues which otherwise you will need to solve. -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 206 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Tue Jan 13 17:37:39 2009 From: wk at gnupg.org (Werner Koch) Date: Tue, 13 Jan 2009 17:37:39 +0100 Subject: Problem with key directory on Linux "vfat" In-Reply-To: <49675AF0.29721.546DAF8@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de> (Ulrich Windl's message of "Fri, 09 Jan 2009 14:10:53 +0100") References: <49675AF0.29721.546DAF8@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de> Message-ID: <87iqoj40x8.fsf@wheatstone.g10code.de> On Fri, 9 Jan 2009 14:10, ulrich.windl at rz.uni-regensburg.de said: > So it seems GnuPG does locking by linking. AFAIK links are not available on vfat > filesystems. I don't know a good solution, but I thought I'd let you know. As a POSIX program gpg requires POSIX semantics and thus you can't use it with a file system not providing that. As a workaround you can use the option --lock-never but take care that you are only running one instance. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From stefanxe at gmx.net Tue Jan 13 20:07:54 2009 From: stefanxe at gmx.net (Stefan X) Date: Tue, 13 Jan 2009 20:07:54 +0100 Subject: Differences: OpenPGP vs. X.509 Message-ID: <496CE68A.7010804@gmx.net> Hi! You can read in the Wikipedia article to X.509: "[X.509] assumes a strict hierarchical system of certificate authorities (CAs) for issuing the certificates. This contrasts with web of trust models, like PGP, where anyone (not just special CAs) may sign and thus attest to the validity of others' key certificates. Version 3 of X.509 includes the flexibility to support other topologies like bridges and meshes (RFC 4158). It can be used in a peer-to-peer, OpenPGP-like web of trust, but was rarely used that way as of 2004." If a web-of-trust is also possible with X.509 I am wondering, what are the remaining differences between both formats? AFAIK file encryption and signing seems not be possible with X.509 which can be used for e-mail only. Which differences, benefits, and drawbacks exist for both formats? From rjh at sixdemonbag.org Wed Jan 14 00:24:26 2009 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 13 Jan 2009 18:24:26 -0500 Subject: Differences: OpenPGP vs. X.509 In-Reply-To: <496CE68A.7010804@gmx.net> References: <496CE68A.7010804@gmx.net> Message-ID: <496D22AA.2020509@sixdemonbag.org> Stefan X wrote: > If a web-of-trust is also possible with X.509 I am wondering, what are > the remaining differences between both formats? >From a capability perspective? Not very much, really. >From a technical perspective? The differences are large enough that your best bet is to read the respective RFCs. > AFAIK file encryption and signing seems not be possible with X.509 which > can be used for e-mail only. Sure it is. As a simple case, what happens if you send a file to yourself and pull it down with POP3? It gets stored on your hard drive in ciphertext. You can certainly use X.509 for file encryption. Very few people do, but that's a much different thing from there being mathematical or engineering obstacles to doing it. From beebe at math.utah.edu Wed Jan 14 00:55:43 2009 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Tue, 13 Jan 2009 16:55:43 -0700 (MST) Subject: libksba-1.0.5: SCM_RIGHTS undeclared on SGI IRIX Message-ID: A build attempt for libksba-1.0.5 on SGI IRIX fails to find a definition of SCM_RIGHTS: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -I/usr/local/include -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wpointer-arith -MT assuan-uds.o -MD -MP -MF .deps/assuan-uds.Tpo -c -o assuan-uds.o assuan-uds.c assuan-uds.c: In function `uds_reader': assuan-uds.c:119: warning: cast increases required alignment of target type assuan-uds.c:123: error: `SCM_RIGHTS' undeclared (first use in this function) assuan-uds.c:123: error: (Each undeclared identifier is reported only once assuan-uds.c:123: error: for each function it appears in.) assuan-uds.c:127: warning: cast increases required alignment of target type assuan-uds.c: In function `uds_sendfd': assuan-uds.c:225: warning: cast increases required alignment of target type assuan-uds.c:228: error: `SCM_RIGHTS' undeclared (first use in this function) assuan-uds.c:229: warning: cast increases required alignment of target type On GNU/Linux, SCM_RIGHTS is defined in /usr/include/bits/socket.h, and on OSF/1 and Solaris, it is defined in /usr/include/sys/socket.h. IRIX is admittedly old and unmaintained, so you may simply wish to declare it unsupported. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From beebe at math.utah.edu Tue Jan 13 23:55:46 2009 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Tue, 13 Jan 2009 15:55:46 -0700 (MST) Subject: libksba-1.0.5 build issues Message-ID: Build attempts of libksba-1.0.5 failed on several platforms in my test lab with these errors: "visibility.c", line 322: void function cannot return value "visibility.c", line 444: void function cannot return value "visibility.c", line 558: void function cannot return value "visibility.c", line 575: void function cannot return value "visibility.c", line 665: void function cannot return value "visibility.c", line 832: void function cannot return value "visibility.c", line 848: void function cannot return value "visibility.c", line 906: void function cannot return value "visibility.c", line 992: void function cannot return value "visibility.c", line 1095: void function cannot return value "visibility.c", line 1103: void function cannot return value "visibility.c", line 1179: void function cannot return value "visibility.c", line 1186: void function cannot return value Here is one example: void ksba_ocsp_release (ksba_ocsp_t ocsp) { return _ksba_ocsp_release (ocsp); } ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From beebe at math.utah.edu Wed Jan 14 00:25:31 2009 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Tue, 13 Jan 2009 16:25:31 -0700 (MST) Subject: libksba-1.0.5: nanosleep() unresolved Message-ID: Builds of libksba-1.0.5 on Sun Solaris systems failed to resolve the POSIX nanosleep() function at link time. According to "man nanosleep" on those systems, -lrt (real-time library) is needed. Unfortunately, you cannot just supply -lrt by default, since some systems (e.g., Mac OS X, FreeBSD, NetBSD, OpenBSD) do not have it: a configure-time test for the library is needed. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From beebe at math.utah.edu Wed Jan 14 01:20:27 2009 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Tue, 13 Jan 2009 17:20:27 -0700 (MST) Subject: libksba-1.0.5 and OSF/1 Alpha: how to make the build succeed Message-ID: A build attempt for libksba-1.0.5 on OSF/1 Alpha failed with compilation errors in assuan-uds.c: cc -std -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -ieee -I/usr/local/include -c assuan-uds.c cc: Error: assuan-uds.c, line 105: In this statement, "msg_control" is not a member of "msg". (needmember) msg.msg_control = control_u.control; ------^ cc: Error: assuan-uds.c, line 106: In this statement, "msg_controllen" is not a member of "msg". (needmember) msg.msg_controllen = sizeof (control_u.control); ------^ cc: Error: assuan-uds.c, line 119: In this statement, "msg_control" is not a member of "(&msg)". (needmember) cmptr = CMSG_FIRSTHDR (&msg); --------------^ cc: Error: assuan-uds.c, line 223: In this statement, "msg_control" is not a member of "msg". (needmember) msg.msg_control = control_u.control; --^ cc: Error: assuan-uds.c, line 224: In this statement, "msg_controllen" is not a member of "msg". (needmember) msg.msg_controllen = sizeof (control_u.control); --^ cc: Error: assuan-uds.c, line 225: In this statement, "msg_control" is not a member of "(&msg)". (needmember) cmptr = CMSG_FIRSTHDR (&msg); ----------^ Examination of the header file shows that these struct members DO exist, but only if _XOPEN_SOURCE_EXTENDED is defined at compile time. I restarted the build with make CC='cc -std -D_XOPEN_SOURCE_EXTENDED' This time, it got further, but died at cc -std -D_XOPEN_SOURCE_EXTENDED -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -ieee -I/usr/local/include -c assuan-io.c cc: Error: assuan-io.c, line 225: In this declaration, "req" has no linkage and is of an incomplete type. (incompnolink) struct timespec req; ------------------^ cc: Error: assuan-io.c, line 226: In this declaration, "rem" has no linkage and is of an incomplete type. (incompnolink) struct timespec rem; ------------------^ A search of showed that struct timespec is exposed if _POSIX_C_SOURCE >= 199309L, so another restart with make CC='cc -std -D_XOPEN_SOURCE_EXTENDED -D_POSIX_C_SOURCE=199309L' got the build further, where it failed with a missing nanosleep(). Yet another restart with make CC='cc -std -D_XOPEN_SOURCE_EXTENDED -D_POSIX_C_SOURCE=199309L' LIBS='-lsnprintf -lrt' produced a successful link, and when I added the check target, I got this felicitous report: PASS: fdpassing ================== All 1 tests passed ================== Since I had never got a successful build of previous releases of libassuan, I've happily installed the libksba-1.0.5 library on this system, and will now see if other packages that depend on libassuan can be built. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From beebe at math.utah.edu Wed Jan 14 01:38:13 2009 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Tue, 13 Jan 2009 17:38:13 -0700 (MST) Subject: libksba-1.0.5 and FreeBSD 5.0 IA32: how to make the build succeed Message-ID: A build of libksba-1.0.5 on FreeBSD 5.0 IA32 failed with gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -I/usr/local/include \ -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wpointer-arith \ -MT putc_unlocked.o -MD -MP -MF .deps/putc_unlocked.Tpo -c -o \ putc_unlocked.o putc_unlocked.c putc_unlocked.c:28: error: redefinition of '__sputc' /usr/local/lib/gcc/i386-unknown-freebsd5.0/3.4.3/include/stdio.h:405: error: previous definition of '__sputc' was here Examination of turned up these blocks: #if __POSIX_VISIBLE >= 199506 int ftrylockfile(FILE *); void flockfile(FILE *); void funlockfile(FILE *); /* * These are normally used through macros as defined below, but POSIX * requires functions as well. */ int getc_unlocked(FILE *); int getchar_unlocked(void); int putc_unlocked(int, FILE *); int putchar_unlocked(int); #endif #if __POSIX_VISIBLE >= 199506 #define getc_unlocked(fp) __sgetc(fp) #define putc_unlocked(x, fp) __sputc(x, fp) #define getchar_unlocked() getc_unlocked(stdin) #define putchar_unlocked(x) putc_unlocked(x, stdout) #endif I therefore made the following change to the source code of libassuan-1.0.5: % diff -c ./src/putc_unlocked.c.org ./src/putc_unlocked.c *** ./src/putc_unlocked.c.org Thu Aug 23 23:29:48 2007 --- ./src/putc_unlocked.c Tue Jan 13 17:29:01 2009 *************** *** 23,30 **** --- 23,32 ---- #include + #if !defined(putc_unlocked) int putc_unlocked (int c, FILE *stream) { return putc (c, stream); } + #endif I restarted the build, which was successful, and all tests passed, so I installed the library. I suspect the correct way to fix this is not to supply a private definition of putc_unlocked() if there is already a working definition in , which is likely to be the case on pretty much all Unix platforms, because they support POSIX specs. A configure-time test can likely do this nicely. The function in src/putc_unlocked.c could then be bracketed with #if !defined(HAVE_PUTC_UNLOCKED) ... #endif I note this requirement in the POSIX Standard (IEEE Std 1003.1-2001): 15969 Versions of the functions getc( ), getchar( ), putc( ), and putchar( ) respectively named 15970 getc_unlocked ( ), getchar_unlocked( ), putc_unlocked( ), and putchar_unlocked( ) shall be provided 15971 which are functionally equivalent to the original versions, with the exception that they are not 15972 required to be implemented in a thread-safe manner. They may only safely be used within a 15973 scope protected by flockfile ( ) (or ftrylockfile ( )) and funlockfile ( ). These functions may safely be 15974 used in a multi-threaded program if and only if they are called while the invoking thread owns 15975 the (FILE *) object, as is the case after a successful call to the flockfile ( ) or ftrylockfile ( ) functions. Thus, any change in this area needs to think carefully about thread ramifications. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From beebe at math.utah.edu Wed Jan 14 02:06:16 2009 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Tue, 13 Jan 2009 18:06:16 -0700 (MST) Subject: libksba-1.0.5: nanosleep() unresolved Message-ID: As a followup to my earlier posting about the unresolved nanosleep() function on Sun Solaris platforms, I tried restarting the build with make LIBS=-lrt all check That simple change produced a successful build, validation, and subsequent installation. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From umq.461 at gmail.com Wed Jan 14 07:59:34 2009 From: umq.461 at gmail.com (Hirohisa Yamaguchi) Date: Wed, 14 Jan 2009 15:59:34 +0900 Subject: libksba-1.0.5 and FreeBSD 5.0 IA32: how to make the build succeed In-Reply-To: References: Message-ID: <738528cb0901132259t24fbe5b0yaa91631fe11f3e18@mail.gmail.com> Hi, On Wed, Jan 14, 2009 at 9:38 AM, Nelson H. F. Beebe wrote: > A build of libksba-1.0.5 on FreeBSD 5.0 IA32 failed with > > gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -I/usr/local/include \ > -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wpointer-arith \ > -MT putc_unlocked.o -MD -MP -MF .deps/putc_unlocked.Tpo -c -o \ > putc_unlocked.o putc_unlocked.c > putc_unlocked.c:28: error: redefinition of '__sputc' > /usr/local/lib/gcc/i386-unknown-freebsd5.0/3.4.3/include/stdio.h:405: error: > previous definition of '__sputc' was here I tried to reproduce the error under FreeBSD/i386 5.5-RELEASE, which was the last FreeBSD 5.x release (and ended its life ages ago). And built successfully without any error. FreeeBSD 5.0 is way too old and known to be pretty unstable, I do not think it is libassuan's problem (nor libksba). # A web search engine tought me that the problem was discussed some years ago, btw. # http://lists.gnupg.org/pipermail/gpa-dev/2004-April/001878.html Regards, -- Hirohisa Yamaguchi umq.461 at gmail.com From stefanxe at gmx.net Wed Jan 14 09:01:24 2009 From: stefanxe at gmx.net (Stefan X) Date: Wed, 14 Jan 2009 09:01:24 +0100 Subject: Differences: OpenPGP vs. X.509 In-Reply-To: <496D22AA.2020509@sixdemonbag.org> References: <496CE68A.7010804@gmx.net> <496D22AA.2020509@sixdemonbag.org> Message-ID: <496D9BD4.4090607@gmx.net> Robert J. Hansen schrieb: > Stefan X wrote: >> If a web-of-trust is also possible with X.509 I am wondering, what are >> the remaining differences between both formats? > >>From a capability perspective? Not very much, really. > >>From a technical perspective? The differences are large enough that > your best bet is to read the respective RFCs. Does it mean theoretically it would possible to convert a) keys/certificates and b) encrypted or signed messages between OpenPGP and X.509 without serious problems (e.g. loss of information)? If so, would the following scenario be possible? A user gets her X.509 certificate signed/approved by - lets say - CAcert or Verisign, convert it to OpenPGP afterwards and get it signed additionally by her friends (with OpenPGP). If she is required to use X.509 for email encryption (instead of OpenPGP) - e.g. because her recipient can not use OpenPGP in his corporate environment - she could convert the OpenPGP key back to X.509 and use it while the additionally signatures of her friends don't get lost. >> AFAIK file encryption and signing seems not be possible with X.509 which >> can be used for e-mail only. > > Sure it is. As a simple case, what happens if you send a file to > yourself and pull it down with POP3? It gets stored on your hard drive > in ciphertext. > > You can certainly use X.509 for file encryption. Very few people do, > but that's a much different thing from there being mathematical or > engineering obstacles to doing it. > > From wk at gnupg.org Wed Jan 14 11:18:32 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 14 Jan 2009 11:18:32 +0100 Subject: Differences: OpenPGP vs. X.509 In-Reply-To: <496D9BD4.4090607@gmx.net> (Stefan X.'s message of "Wed, 14 Jan 2009 09:01:24 +0100") References: <496CE68A.7010804@gmx.net> <496D22AA.2020509@sixdemonbag.org> <496D9BD4.4090607@gmx.net> Message-ID: <874p0242dj.fsf@wheatstone.g10code.de> On Wed, 14 Jan 2009 09:01, stefanxe at gmx.net said: > Does it mean theoretically it would possible to convert a) > keys/certificates and b) encrypted or signed messages between OpenPGP > and X.509 without serious problems (e.g. loss of information)? No, that is not possible. You can use the same key parameters with OpenPGP and X.509 (I do this sometimes with smartcards). However it gives you nothing because the value of a certificate (keyblock in OpenPGP parlance) is that other information is associated with the key and that information is bound to the key by a digital signature. This signature is either X.509 or OpenPGP. You can't convert one signature into another one. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Wed Jan 14 12:54:43 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 14 Jan 2009 12:54:43 +0100 Subject: libksba-1.0.5 build issues In-Reply-To: (Nelson H. F. Beebe's message of "Tue, 13 Jan 2009 15:55:46 -0700 (MST)") References: Message-ID: <87vdsi2jcs.fsf@wheatstone.g10code.de> On Tue, 13 Jan 2009 23:55, beebe at math.utah.edu said: > "visibility.c", line 322: void function cannot return value All fixed in SVN. Thanks, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From stefanxe at gmx.net Wed Jan 14 13:36:42 2009 From: stefanxe at gmx.net (Stefan X) Date: Wed, 14 Jan 2009 13:36:42 +0100 Subject: Differences: OpenPGP vs. X.509 In-Reply-To: <874p0242dj.fsf@wheatstone.g10code.de> References: <496CE68A.7010804@gmx.net> <496D22AA.2020509@sixdemonbag.org> <496D9BD4.4090607@gmx.net> <874p0242dj.fsf@wheatstone.g10code.de> Message-ID: <496DDC5A.7060308@gmx.net> I see, a conversation would unfortunately result in the loss of signatures. Also I came to this question by having a X.509 smart card which I would like to use with OpenPGP/gnupg. Is there any practical tool to convert the key parameters in such case? If both formats have very similar sets of features, it really does not make sense for me to have both formats available. Instead interoperability between different systems would be better with a single format. Better and easier interoperability could also result in a wider distribution of encryption-usage overall. Thus I am wondering if there are any efforts to synchronize or unite both formats? If not, which strategies/options may be appropriate to go in this way (e.g. embed one format into the other, using the same key parameters etc.)? Also I saw that GnuPG 2 is able to use X.509 but to which extend and does it allow any interoperability between both formats? Werner Koch schrieb: > On Wed, 14 Jan 2009 09:01, stefanxe at gmx.net said: > >> Does it mean theoretically it would possible to convert a) >> keys/certificates and b) encrypted or signed messages between OpenPGP >> and X.509 without serious problems (e.g. loss of information)? > > No, that is not possible. You can use the same key parameters with > OpenPGP and X.509 (I do this sometimes with smartcards). However it > gives you nothing because the value of a certificate (keyblock in > OpenPGP parlance) is that other information is associated with the key > and that information is bound to the key by a digital signature. This > signature is either X.509 or OpenPGP. You can't convert one signature > into another one. > > > Shalom-Salam, > > Werner > From wk at gnupg.org Wed Jan 14 15:30:24 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 14 Jan 2009 15:30:24 +0100 Subject: Differences: OpenPGP vs. X.509 In-Reply-To: <496DDC5A.7060308@gmx.net> (Stefan X.'s message of "Wed, 14 Jan 2009 13:36:42 +0100") References: <496CE68A.7010804@gmx.net> <496D22AA.2020509@sixdemonbag.org> <496D9BD4.4090607@gmx.net> <874p0242dj.fsf@wheatstone.g10code.de> <496DDC5A.7060308@gmx.net> Message-ID: <87priq2c5b.fsf@wheatstone.g10code.de> On Wed, 14 Jan 2009 13:36, stefanxe at gmx.net said: > Also I came to this question by having a X.509 smart card which I would > like to use with OpenPGP/gnupg. Is there any practical tool to convert > the key parameters in such case? That uis not possible. gpg does only support the OpenPGP card - adding support for arbitrary cards is a too complicated and does not make much sense to me. The other way around it works nicely: You can use an OpenPGP card for X.509; in particular for an TLS user certificate. see www.scute.org. > Also I saw that GnuPG 2 is able to use X.509 but to which extend and > does it allow any interoperability between both formats? For Secure Shell (OpenPGP, Belpic, some other pkcs#15 cards and soon Netkey 3.). Also of course for S/MIME. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Wed Jan 14 15:55:02 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 14 Jan 2009 15:55:02 +0100 Subject: Re libassuan nanonsleep() unresolved (was: libksba-1.0.5: nanosleep() unresolved) In-Reply-To: (Nelson H. F. Beebe's message of "Tue, 13 Jan 2009 18:06:16 -0700 (MST)") References: Message-ID: <87fxjm2b09.fsf@wheatstone.g10code.de> Hi, I think we should change the subject of all these mails becuase they are about libassuan and not about libksba. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From stefanxe at gmx.net Thu Jan 15 17:54:20 2009 From: stefanxe at gmx.net (Stefan X) Date: Thu, 15 Jan 2009 17:54:20 +0100 Subject: Differences: OpenPGP vs. X.509 In-Reply-To: <87priq2c5b.fsf@wheatstone.g10code.de> References: <496CE68A.7010804@gmx.net> <496D22AA.2020509@sixdemonbag.org> <496D9BD4.4090607@gmx.net> <874p0242dj.fsf@wheatstone.g10code.de> <496DDC5A.7060308@gmx.net> <87priq2c5b.fsf@wheatstone.g10code.de> Message-ID: <496F6A3C.50004@gmx.net> Thanks for the explanation. Are there any thoughts on my questions in my previous mail, which is: If both formats have very similar sets of features, it really does not make sense for me to have both formats available. Instead interoperability between different systems would be better with a single format. Better and easier interoperability could also result in a wider distribution of encryption-usage overall. Thus I am wondering if there are any efforts to synchronize or unite both formats? If not, which strategies/options may be appropriate to go in this way (e.g. embed one format into the other, using the same key parameters etc.)? Werner Koch schrieb: > On Wed, 14 Jan 2009 13:36, stefanxe at gmx.net said: > >> Also I came to this question by having a X.509 smart card which I would >> like to use with OpenPGP/gnupg. Is there any practical tool to convert >> the key parameters in such case? > > That uis not possible. gpg does only support the OpenPGP card - adding > support for arbitrary cards is a too complicated and does not make much > sense to me. The other way around it works nicely: You can use an > OpenPGP card for X.509; in particular for an TLS user certificate. see > www.scute.org. > >> Also I saw that GnuPG 2 is able to use X.509 but to which extend and >> does it allow any interoperability between both formats? > > For Secure Shell (OpenPGP, Belpic, some other pkcs#15 cards and soon > Netkey 3.). Also of course for S/MIME. > > > Salam-Shalom, > > Werner > From rjh at sixdemonbag.org Thu Jan 15 17:58:09 2009 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 15 Jan 2009 11:58:09 -0500 Subject: Differences: OpenPGP vs. X.509 In-Reply-To: <496F6A3C.50004@gmx.net> References: <496CE68A.7010804@gmx.net> <496D22AA.2020509@sixdemonbag.org> <496D9BD4.4090607@gmx.net> <874p0242dj.fsf@wheatstone.g10code.de> <496DDC5A.7060308@gmx.net> <87priq2c5b.fsf@wheatstone.g10code.de> <496F6A3C.50004@gmx.net> Message-ID: <496F6B21.7040503@sixdemonbag.org> Stefan X wrote: > Thus I am wondering if there are any efforts to synchronize or unite > both formats? Not that I've heard of from either WG. PGP Corporation will allow you to import an X.509 certificate into the WoT, but this strikes many people as a futile exercise. > If not, which strategies/options may be appropriate to go in this way > (e.g. embed one format into the other, using the same key parameters > etc.)? The best strategy right now, apparently, is "don't." From wk at gnupg.org Thu Jan 15 19:18:53 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 15 Jan 2009 19:18:53 +0100 Subject: Differences: OpenPGP vs. X.509 In-Reply-To: <496F6A3C.50004@gmx.net> (Stefan X.'s message of "Thu, 15 Jan 2009 17:54:20 +0100") References: <496CE68A.7010804@gmx.net> <496D22AA.2020509@sixdemonbag.org> <496D9BD4.4090607@gmx.net> <874p0242dj.fsf@wheatstone.g10code.de> <496DDC5A.7060308@gmx.net> <87priq2c5b.fsf@wheatstone.g10code.de> <496F6A3C.50004@gmx.net> Message-ID: <87ljtczb3m.fsf@wheatstone.g10code.de> On Thu, 15 Jan 2009 17:54, stefanxe at gmx.net said: > distribution of encryption-usage overall. Thus I am wondering if there > are any efforts to synchronize or unite both formats? If not, which No, it does not make any sense. > strategies/options may be appropriate to go in this way (e.g. embed one > format into the other, using the same key parameters etc.)? This problem needs to be solved at the MUA level. That is, if you are going to send a message to someone or to a group of people, it should be send out using the protocol for which you have keys for most of the recipients and the MUA may then send out the same message encrypted for the other set of recipients, using the other protocol. (This resembles BCC processing). Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From rdieter at math.unl.edu Fri Jan 16 17:26:50 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 16 Jan 2009 10:26:50 -0600 Subject: gpg2 display charset detection broken? Message-ID: using gnupg2-2.0.9, Cliff's notes version: Unless charset is specified in config file or with --display-charset argument, gpg2 output incorrect (and different from the gpg output) for utf-8 encoded strings. See downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=471559 -- Rex From wk at gnupg.org Fri Jan 16 18:32:38 2009 From: wk at gnupg.org (Werner Koch) Date: Fri, 16 Jan 2009 18:32:38 +0100 Subject: gpg2 display charset detection broken? In-Reply-To: (Rex Dieter's message of "Fri, 16 Jan 2009 10:26:50 -0600") References: Message-ID: <87bpu7w409.fsf@wheatstone.g10code.de> On Fri, 16 Jan 2009 17:26, rdieter at math.unl.edu said: > See downstream bug: > https://bugzilla.redhat.com/show_bug.cgi?id=471559 The reason seems to be that gpg.c calls init_common_subsystems() before initializing the locale via i18n_init() or a setlocale() call. Therefore detects as ANSI_X3.4-1968 (i.e us-ascii) and uses iso-8859-1 as fallback. This should be fixed in 2.0.10: 2008-12-09 Werner Koch * gpg.c (main): Call i18n_init before init_common_subsystems. Same also fixed for the other tools. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From rdieter at math.unl.edu Fri Jan 16 19:05:07 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 16 Jan 2009 12:05:07 -0600 Subject: gpg2 display charset detection broken? References: <87bpu7w409.fsf@wheatstone.g10code.de> Message-ID: Werner Koch wrote: > On Fri, 16 Jan 2009 17:26, rdieter at math.unl.edu said: > >> See downstream bug: >> https://bugzilla.redhat.com/show_bug.cgi?id=471559 > > The reason seems to be that gpg.c calls init_common_subsystems() > before initializing the locale via i18n_init() or a setlocale() > call. Therefore detects as ANSI_X3.4-1968 (i.e us-ascii) and uses > iso-8859-1 as fallback. > > This should be fixed in 2.0.10: > 2008-12-09 Werner Koch > * gpg.c (main): Call i18n_init before init_common_subsystems. Dang, sorry, my casual perusal of the 2.0.10 changelog was clearly insufficient. -- Rex From bernhard at intevation.de Tue Jan 20 12:58:37 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 20 Jan 2009 12:58:37 +0100 Subject: Differences: OpenPGP vs. X.509 In-Reply-To: <87ljtczb3m.fsf@wheatstone.g10code.de> References: <496CE68A.7010804@gmx.net> <496F6A3C.50004@gmx.net> <87ljtczb3m.fsf@wheatstone.g10code.de> Message-ID: <200901201258.39961.bernhard@intevation.de> On Donnerstag, 15. Januar 2009, Werner Koch wrote: > > strategies/options may be appropriate to go in this way (e.g. embed one > > format into the other, using the same key parameters etc.)? > > This problem needs to be solved at the MUA level. ? I agree here, this is an application level problem. There is another difference to me, though. Even if X509 might be able to work with Bridges, usually this is not done. Only a small subset of root certificates will be trusted in a considered environment. Most important from the user view is that the user is able to understand which trust he or she can assume for the email that is being send right now (or that particular signature under verification). The following approach only works if the possible difference in trust is adequetely communicated to the users: > That is, if you are > going to send a message to someone or to a group of people, it should be > send out using the protocol for which you have keys for most of the > recipients and the MUA may then send out the same message encrypted for > the other set of recipients, using the other protocol. ?(This resembles > BCC processing). Also you would lose the information to whom this was encryted. Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1603 bytes Desc: not available URL: From wk at gnupg.org Tue Jan 20 13:07:43 2009 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Jan 2009 13:07:43 +0100 Subject: Differences: OpenPGP vs. X.509 In-Reply-To: <200901201258.39961.bernhard@intevation.de> (Bernhard Reiter's message of "Tue, 20 Jan 2009 12:58:37 +0100") References: <496CE68A.7010804@gmx.net> <496F6A3C.50004@gmx.net> <87ljtczb3m.fsf@wheatstone.g10code.de> <200901201258.39961.bernhard@intevation.de> Message-ID: <87k58qqiy8.fsf@wheatstone.g10code.de> On Tue, 20 Jan 2009 12:58, bernhard at intevation.de said: > Also you would lose the information to whom this was encryted. That depends on how you encrypt your private copy for the sent-mail folder. Looking at BCC, the BCC line is included there. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From bernhard at intevation.de Tue Jan 20 14:38:04 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 20 Jan 2009 14:38:04 +0100 Subject: Differences: OpenPGP vs. X.509 In-Reply-To: <87k58qqiy8.fsf@wheatstone.g10code.de> References: <496CE68A.7010804@gmx.net> <200901201258.39961.bernhard@intevation.de> <87k58qqiy8.fsf@wheatstone.g10code.de> Message-ID: <200901201438.07274.bernhard@intevation.de> On Dienstag, 20. Januar 2009, Werner Koch wrote: > On Tue, 20 Jan 2009 12:58, bernhard at intevation.de said: > > Also you would lose the information to whom this was encryted. > > That depends on how you encrypt your private copy for the sent-mail > folder. ?Looking at BCC, the BCC line is included there. Mainly I've meant for the recipients of the email. This slightly changes the email semantics and needs careful consideration. There are different emails send out. -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1603 bytes Desc: not available URL: From stefanxe at gmx.net Tue Jan 20 14:50:05 2009 From: stefanxe at gmx.net (Stefan X) Date: Tue, 20 Jan 2009 14:50:05 +0100 Subject: Differences: OpenPGP vs. X.509 In-Reply-To: <87k58qqiy8.fsf@wheatstone.g10code.de> References: <496CE68A.7010804@gmx.net> <496F6A3C.50004@gmx.net> <87ljtczb3m.fsf@wheatstone.g10code.de> <200901201258.39961.bernhard@intevation.de> <87k58qqiy8.fsf@wheatstone.g10code.de> Message-ID: <4975D68D.5080907@gmx.net> I found a description (see below) from PGP Corporation, how they import and use X.509 certificates in OpenPGP format resp. key ring. As discussed here before this should be possible for the key parameters. Also these guys managed to use the signatures further on. To achieve this 1) the imported key which is then available in OpenPGP format is temporary converted back to X.509 which allows 2) to check the signatures successfully. Afterwards the temporary X.509 certificate is removed. At least this is my understanding of the paper. I assume this procedure would also work the other way around. http://archive.cert.uni-stuttgart.de/openpgp/2005/04/msg00033.html I see increasing importance for such interoperability, let me explain: Currently X.509 is the dominating format for corporations while OpenPGP is for private Internet users. As long as both "worlds" are mostly separated an interoperability is not too important. But I expect this separation will soften in the future. For instance in Germany (but also in other countries) are big governmental backed projects going on such as a new public health insurance card (elektronische Gesundheitskarte) or a new ID card for example. There may be privacy issues implicated (which I will not discuss here) but newertheless you should not forget that it is large scale PKI deployment to the people. This opens the chance to bring the distribution of email and data encryption to a next level. Image that every (in this example German) citizen may have a X.509 compatible smart card in her pocket. But to be able to use it also for private email encryption, such discussed interoperability with OpenPGP and also with Open Source applications will be important. From bernhard at intevation.de Wed Jan 21 09:43:12 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 21 Jan 2009 09:43:12 +0100 Subject: Differences: OpenPGP vs. X.509 In-Reply-To: <4975D68D.5080907@gmx.net> References: <496CE68A.7010804@gmx.net> <87k58qqiy8.fsf@wheatstone.g10code.de> <4975D68D.5080907@gmx.net> Message-ID: <200901210943.14653.bernhard@intevation.de> On Dienstag, 20. Januar 2009, Stefan X wrote: > But to be able to use it also > for private email encryption, such discussed interoperability with > OpenPGP and also with Open Source applications will be important. But note that Free Software can do S/MIME with the cards just fine. (E.g. KMail/Kontact via gpgme and thus GnuPG2's gpgsm.) So Free Software is technically compatible to S/MIME already. The biggest obstacles are good configuration and administration. Of course distributors could help a lot with good configuration. As I explained before, it is important for people to understand what a specific signature means. Currently the differences for S/MIME and OpenPGP are wide on the average. So when building a user interface, I personally suggest to keep S/MIME and OpenPGP usage visible and distinct. This caters much better to the internal and practical limits that each of the methods currently have. Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1603 bytes Desc: not available URL: From dam at opencsw.org Wed Jan 21 21:43:41 2009 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 21 Jan 2009 21:43:41 +0100 Subject: Issues with compiling gnupg 2.0.10 on Solaris with Sun Studio 11 Message-ID: <3A3A2503-F678-4304-8560-3849385DBC85@opencsw.org> Hi, I am trying to compile the current version of gnupg 2.0.10 on Solaris with the Sun Studio 11 compiler and I am having some issues here: - Altough a current libgpg-error is found the library is not used for binding: ... configure:5746: checking for cc for build configure:5753: result: /opt/studio/SOS11/SUNWspro/bin/cc configure:5914: checking for libraries configure:5938: checking for gpg-error-config configure:5956: found /opt/csw/bin/gpg-error-config configure:5969: result: /opt/csw/bin/gpg-error-config configure:5978: checking for GPG Error - version >= 1.4 configure:6004: result: yes (1.7) configure:6038: checking for libgcrypt-config ... GPG_ERROR_CFLAGS='-I/opt/csw/include' GPG_ERROR_CONFIG='/opt/csw/bin/gpg-error-config' GPG_ERROR_LIBS='-L/opt/csw/lib -lgpg-error' GREP='/opt/csw/bin/ggrep' ... source='t-stringhelp.c' object='t-stringhelp.o' libtool=no \ DEPDIR=.deps depmode=none /bin/bash ../scripts/depcomp \ /opt/studio/SOS11/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I.. - I../intl -I/opt/csw/include -DJNLIB_IN_JNLIB -I/opt/csw/include -xO3 - xarch=v8 -I/opt/csw/include -c t-stringhelp.c source='t-support.c' object='t-support.o' libtool=no \ DEPDIR=.deps depmode=none /bin/bash ../scripts/depcomp \ /opt/studio/SOS11/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I.. - I../intl -I/opt/csw/include -DJNLIB_IN_JNLIB -I/opt/csw/include -xO3 - xarch=v8 -I/opt/csw/include -c t-support.c /opt/studio/SOS11/SUNWspro/bin/cc -DJNLIB_IN_JNLIB -I/opt/csw/include - xO3 -xarch=v8 -I/opt/csw/include -xarch=v8 -L/opt/csw/lib -R/opt/csw/ lib/\\\$ISALIST -R/opt/csw/lib -o t-stringhelp t-stringhelp.o t- support.o libjnlib.a /opt/csw/lib/libintl.so /opt/csw/lib/libiconv.so - lc -R/opt/csw/lib /opt/csw/lib/libiconv.so -R/opt/csw/lib ld: warning: file /opt/csw/lib/libiconv.so: attempted multiple inclusion of file Undefined first referenced symbol in file gpg_err_code_from_errno libjnlib.a(stringhelp.o) gpg_err_code_from_syserror libjnlib.a(stringhelp.o) ld: fatal: Symbol referencing errors. No output written to t-stringhelp gmake[4]: *** [t-stringhelp] Error 1 gmake[4]: Leaving directory `/home/dam/mgar/pkg/gnupg/trunk/work/build- isa-sparcv8/gnupg-2.0.10/jnlib' gmake[3]: *** [all-recursive] Error 1 Explicitly adding -lgpg-error temporarily fixes this problem and leads to another one: DEPDIR=.deps depmode=none /bin/bash ../scripts/depcomp \ /opt/studio/SOS11/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I.. - I../gl -I../common -I../include -I../intl -DLOCALEDIR=\"/opt/csw/share/ locale\" -DGNUPG_BINDIR="\"/opt/csw/bin\"" -DGNUPG_LIBEXECDIR="\"/opt/ csw/libexec\"" -DGNUPG_LIBDIR="\"/opt/csw/lib/gnupg\"" - DGNUPG_DATADIR="\"/opt/csw/share/gnupg\"" -DGNUPG_SYSCONFDIR="\"/opt/ csw/etc/gnupg\"" -I/opt/csw/include -I/opt/csw/include -I/opt/csw/ include -I/opt/csw/include -xO3 -xarch=v8 -I/opt/csw/include -c exec.c /opt/studio/SOS11/SUNWspro/bin/cc -I/opt/csw/include -I/opt/csw/ include -I/opt/csw/include -xO3 -xarch=v8 -I/opt/csw/include - xarch=v8 -L/opt/csw/lib -R/opt/csw/lib/\\\$ISALIST -R/opt/csw/lib - lgpg-error -o gpg2 gpg.o server.o build-packet.o compress.o compress- bz2.o free-packet.o getkey.o keydb.o keyring.o seskey.o kbnode.o mainproc.o armor.o mdfilter.o textfilter.o progress.o misc.o rmd160.o openfile.o keyid.o parse-packet.o cpr.o plaintext.o sig-check.o keylist.o pkglue.o pkclist.o skclist.o pubkey-enc.o passphrase.o seckey-cert.o encr-data.o cipher.o encode.o sign.o verify.o revoke.o decrypt.o keyedit.o dearmor.o import.o export.o trustdb.o tdbdump.o tdbio.o delkey.o keygen.o helptext.o keyserver.o photoid.o call- agent.o card-util.o exec.o ../common/libcommon.a ../jnlib/ libjnlib.a ../gl/libgnu.a ../common/libgpgrl.a -lz -lbz2 -lresolv - lreadline -ltermcap /opt/csw/lib/libintl.so /opt/csw/lib/libiconv.so - lc -R/opt/csw/lib -lsocket -lnsl -L/opt/csw/lib -lgcrypt -lgpg-error -L/opt/csw/lib -lassuan -L/opt/csw/lib -lgpg-error /opt/csw/lib/ libiconv.so -R/opt/csw/lib ld: warning: file /opt/csw/lib/libiconv.so: attempted multiple inclusion of file Undefined first referenced symbol in file nanosleep /opt/csw/lib/libassuan.a(assuan- io.o) ld: fatal: Symbol referencing errors. No output written to gpg2 This function is located in -lrt on Solaris. Then there were more errors like the first one where necessary libraries weren't linked against like DEPDIR=.deps depmode=none /bin/bash ../scripts/depcomp \ /opt/studio/SOS11/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I.. - I/opt/csw/include -I../gl -I../common -I../intl -DLOCALEDIR=\"/opt/csw/ share/locale\" -DGNUPG_BINDIR="\"/opt/csw/bin\"" - DGNUPG_LIBEXECDIR="\"/opt/csw/libexec\"" -DGNUPG_LIBDIR="\"/opt/csw/ lib/gnupg\"" -DGNUPG_DATADIR="\"/opt/csw/share/gnupg\"" - DGNUPG_SYSCONFDIR="\"/opt/csw/etc/gnupg\"" -I/opt/csw/include -I/ opt/csw/include -I/opt/csw/include -xO3 -xarch=v8 -I/opt/csw/include - c -o gpg2keys_hkp-no-libgcrypt.o `test -f 'no-libgcrypt.c' || echo './'`no-libgcrypt.c /opt/studio/SOS11/SUNWspro/bin/cc -I/opt/csw/include -I/opt/csw/ include -xO3 -xarch=v8 -I/opt/csw/include -xarch=v8 -L/opt/csw/lib -R/ opt/csw/lib/\\\$ISALIST -R/opt/csw/lib -lgpg-error -lrt -o gpg2keys_hkp gpg2keys_hkp-gpgkeys_hkp.o gpg2keys_hkp-ksutil.o gpg2keys_hkp-no-libgcrypt.o -L/opt/csw/lib -lcurl -L/opt/csw/lib -L/ opt/csw/lib -lidn -lssl -lcrypto -llber -lldap -lsocket -lnsl -lssl - lcrypto -lsocket -lnsl -ldl -lz Undefined first referenced symbol in file bug_at gpg2keys_hkp-no-libgcrypt.o ld: fatal: Symbol referencing errors. No output written to gpg2keys_hkp gmake[4]: *** [gpg2keys_hkp] Error 1 Is here something wrong with my compile environment or is there something missing with the autoconf-stuff? Best regards -- Dago From benjamin at py-soft.co.uk Wed Jan 21 21:57:49 2009 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Wed, 21 Jan 2009 20:57:49 +0000 Subject: Mac stuff! In-Reply-To: <732076a80901211052o324d219dy685df4a1900d48b6@mail.gmail.com> References: <732076a80901211052o324d219dy685df4a1900d48b6@mail.gmail.com> Message-ID: <732076a80901211257s740c80dere3cf138ace59082b@mail.gmail.com> 2009/1/21 Benjamin Donnachie : > The other thing is one of my users is having problems with the native > Mac pinentry program. One theory I have is that it's not dealing with > character encoding properly - am I right in thinking that everything > should be passed to it in UTF-8? The source code is on my devel box > at home - I'll have a look when I get in... Red herring: char * pin = (char *) [[pinentry getPINField] UTF8String]; Back to the drawing board! Ben From benjamin at py-soft.co.uk Wed Jan 21 19:52:36 2009 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Wed, 21 Jan 2009 18:52:36 +0000 Subject: Mac stuff! Message-ID: <732076a80901211052o324d219dy685df4a1900d48b6@mail.gmail.com> I currently maintain the binary Mac distribution of GnuPG v2, MacGPG2. Firstly, would there be any problems changing the identifying string for GnuPG as follows: Instead of: $ gpg2 --version gpg (GnuPG) 2.0.10 libgcrypt 1.4.3 Copyright (C) 2009 Free Software Foundation, Inc. [...] It would be: $ gpg2 --version gpg (MacGPG2) 2.0.10 libgcrypt 1.4.3 Copyright (C) 2009 Free Software Foundation, Inc. [...] or even: $ gpg2 --version gpg (GnuPG by MacGPG2) 2.0.10 libgcrypt 1.4.3 Copyright (C) 2009 Free Software Foundation, Inc. [...] Many of our support enquiries arise from non-MacGPG2 installs and this would make my life so much easier! The other thing is one of my users is having problems with the native Mac pinentry program. One theory I have is that it's not dealing with character encoding properly - am I right in thinking that everything should be passed to it in UTF-8? The source code is on my devel box at home - I'll have a look when I get in... However, he's also reporting problems with the curses pinentry program and I'm almost completely stumped. Ben From benjamin at py-soft.co.uk Wed Jan 21 23:16:19 2009 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Wed, 21 Jan 2009 22:16:19 +0000 Subject: Mac stuff! In-Reply-To: <732076a80901211257s740c80dere3cf138ace59082b@mail.gmail.com> References: <732076a80901211052o324d219dy685df4a1900d48b6@mail.gmail.com> <732076a80901211257s740c80dere3cf138ace59082b@mail.gmail.com> Message-ID: <732076a80901211416n20fcac7evd144b14212d0c615@mail.gmail.com> 2009/1/21 Benjamin Donnachie : > Red herring: Then again: getpin D ????????????(c)??(c)??(c)?(c) OK bye OK closing connection That doesn't look like UTF-8 to me! Think I might have found the problem... :) Ben From petersonmaxx at googlemail.com Thu Jan 22 06:34:14 2009 From: petersonmaxx at googlemail.com (M. Peterson) Date: Thu, 22 Jan 2009 06:34:14 +0100 Subject: Qt Email with PGP Message-ID: Hello we released new Qt Webkit dooble browser 004a at http://dooble.sf.net and want to implement a Qt Email client soon, which is already reelased as well, but the feature should be in, that this email client sends PGP encrypted emails only, Is someone able to support the implementation of PGP into this? Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Thu Jan 22 10:58:18 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 22 Jan 2009 10:58:18 +0100 Subject: Mac stuff! In-Reply-To: <732076a80901211257s740c80dere3cf138ace59082b@mail.gmail.com> (Benjamin Donnachie's message of "Wed, 21 Jan 2009 20:57:49 +0000") References: <732076a80901211052o324d219dy685df4a1900d48b6@mail.gmail.com> <732076a80901211257s740c80dere3cf138ace59082b@mail.gmail.com> Message-ID: <873afbu0g5.fsf@wheatstone.g10code.de> On Wed, 21 Jan 2009 21:57, benjamin at py-soft.co.uk said: > char * pin = (char *) [[pinentry getPINField] UTF8String]; The Qt version does the same: char *pin = (char *) pinentry.text().utf8(); I have not checked what the curses version does. In general everything should be utf8 but for historical reasons we have never enforced that so that you may end up with a mismatch between using the command line version and Pinentry or another GUI to enter the passphrase. I would advice to use the too initially used to set the passphrase and change the passphrase to a plain ascii one. Later it can then be changed using the GUI. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Thu Jan 22 11:00:29 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 22 Jan 2009 11:00:29 +0100 Subject: Mac stuff! In-Reply-To: <732076a80901211052o324d219dy685df4a1900d48b6@mail.gmail.com> (Benjamin Donnachie's message of "Wed, 21 Jan 2009 18:52:36 +0000") References: <732076a80901211052o324d219dy685df4a1900d48b6@mail.gmail.com> Message-ID: <87y6x3sls2.fsf@wheatstone.g10code.de> On Wed, 21 Jan 2009 19:52, benjamin at py-soft.co.uk said: > It would be: > $ gpg2 --version > gpg (MacGPG2) 2.0.10 I see no problem with that. You merely should stick to that format of version strings because gpgme and other tools know about that GNU format. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From rjh at sixdemonbag.org Thu Jan 22 12:33:20 2009 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 22 Jan 2009 06:33:20 -0500 Subject: Qt Email with PGP In-Reply-To: References: Message-ID: <49785980.4040007@sixdemonbag.org> M. Peterson wrote: > Is someone able to support the implementation of PGP > into this? Max I'm not volunteering, sorry -- I'm only pointing out that this is the GnuPG users list. It's not a PGP list. From wk at gnupg.org Thu Jan 22 14:23:47 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 22 Jan 2009 14:23:47 +0100 Subject: Issues with compiling gnupg 2.0.10 on Solaris with Sun Studio 11 In-Reply-To: <3A3A2503-F678-4304-8560-3849385DBC85@opencsw.org> (Dagobert Michelsen's message of "Wed, 21 Jan 2009 21:43:41 +0100") References: <3A3A2503-F678-4304-8560-3849385DBC85@opencsw.org> Message-ID: <874ozrscd8.fsf@wheatstone.g10code.de> On Wed, 21 Jan 2009 21:43, dam at opencsw.org said: > - Altough a current libgpg-error is found the library is not used for > binding: > Undefined first referenced > symbol in file > gpg_err_code_from_errno libjnlib.a(stringhelp.o) > gpg_err_code_from_syserror libjnlib.a(stringhelp.o) We had the same problem in tools/. Over there we fixed it by linking to libgpg-error: # jnlib/common sucks in gpg-error, will they, nil they (some compilers # do not eliminate the supposed-to-be-unused-inline-functions). I do not like to add libgpg-error to jnlib/ so I will add stub fucntions for it. > Undefined first referenced > symbol in file > nanosleep /opt/csw/lib/libassuan.a(assuan- Tha list a libassuan problem and we need to solve this tehre. Nelson H. F. Beebe already reported that problem. > Undefined first referenced > symbol in file > bug_at gpg2keys_hkp-no-libgcrypt.o I will look at it too. > Is here something wrong with my compile environment or is there > something No. It is just that we selectivly add required libraries and catching errors is hard on systems where these libraries alrady exist as system libraries. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Thu Jan 22 15:15:41 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 22 Jan 2009 15:15:41 +0100 Subject: libksba-1.0.5: nanosleep() unresolved In-Reply-To: (Nelson H. F. Beebe's message of "Tue, 13 Jan 2009 18:06:16 -0700 (MST)") References: Message-ID: <87zlhjqvea.fsf@wheatstone.g10code.de> On Wed, 14 Jan 2009 02:06, beebe at math.utah.edu said: > As a followup to my earlier posting about the unresolved > nanosleep() function on Sun Solaris platforms, I tried > restarting the build with Fixed in libassuan SVN 293. We use nanosleep only if it is available in a standard lib and fallback to select based waiting otherwise. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Thu Jan 22 19:57:08 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 22 Jan 2009 19:57:08 +0100 Subject: [Announce] Libgcrypt 1.4.4 released Message-ID: <87ab9jp3sr.fsf@wheatstone.g10code.de> Hello! The GNU project is pleased to announce the availability of Libgcrypt version 1.4.4. Libgcrypt is a general purpose library of cryptographic building blocks. It is originally based on code used by GnuPG. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required to use Libgcrypt. Noteworthy changes in version 1.4.4: * Publish GCRY_MODULE_ID_USER and GCRY_MODULE_ID_USER_LAST constants. This functionality has been in Libgcrypt since 1.3.0. * MD5 may now be used in non-enforced fips mode. * Fixed HMAC for SHA-384 and SHA-512 with keys longer than 64 bytes. * In fips mode, RSA keys are now generated using the X9.31 algorithm and DSA keys using the FIPS 186-2 algorithm. * The transient-key flag is now also supported for DSA key generation. DSA domain parameters may be given as well. Source code is hosted at the GnuPG FTP server and its mirrors as listed at http://www.gnupg.org/download/mirrors.html . On the primary server the source file and its digital signatures is: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.4.tar.bz2 (1116k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.4.tar.bz2.sig This file is bzip2 compressed. A gzip compressed version is also available: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.4.tar.gz (1387k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.4.tar.gz.sig Alternativley you may upgrade version 1.4.3 using this patch file: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.3-1.4.4.diff.bz2 (90k) The SHA-1 checksums are: 6f156593ce0833856b59580a7d430d0a5153b324 libgcrypt-1.4.4.tar.gz 3987f0efcbb7048c136d5c859e88eee1763a14f6 libgcrypt-1.4.4.tar.bz2 51947f0753ac61af96e075fcb5a1d4a6305c284b libgcrypt-1.4.3-1.4.4.diff.bz2 For help on developing with Libgcrypt you should read the included manual and optional ask on the gcrypt-devel mailing list [1]. Improving Libgcrypt is costly, but you can help! We are looking for organizations that find Libgcrypt useful and wish to contribute back. You can contribute by reporting bugs, improve the software [2], order extensions or support or more general by donating money to the Free Software movement [3]. Commercial support contracts for Libgcrypt are available [4], and they help finance continued maintenance. g10 Code GmbH, a Duesseldorf based company, is currently funding Libgcrypt development. We are always looking for interesting development projects. Many thanks to all who contributed to Libgcrypt development, be it bug fixes, code, documentation, testing or helping users. Happy hacking, Werner [1] See http://www.gnupg.org/documentation/mailing-lists.html . [2] Note that copyright assignments to the FSF are required. [3] For example see http://donate.fsf.org . [4] See the service directory at http://www.gnupg.org/service.html . -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 205 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From stefanxe at gmx.net Sat Jan 24 18:03:23 2009 From: stefanxe at gmx.net (Stefan X) Date: Sat, 24 Jan 2009 18:03:23 +0100 Subject: Differences: OpenPGP vs. X.509 In-Reply-To: <200901210943.14653.bernhard@intevation.de> References: <496CE68A.7010804@gmx.net> <87k58qqiy8.fsf@wheatstone.g10code.de> <4975D68D.5080907@gmx.net> <200901210943.14653.bernhard@intevation.de> Message-ID: <497B49DB.7070705@gmx.net> I agree with you that the methods typically used with X.509 and OpenPGP differ and also you are right that X.509 is supported by several Open Source applications. So I understand we agree that both formats itself are not differing in its features. Instead the implementations and the practiced methodes differ a lot. As explained before I see huge benefits in case one format would be used instead of two. But it seems that there is few awareness about it and no kind of declared goal or even roadmap to achieve it. For my understanding the best starting point would be to have applications and libraries which provide same functionality with/for both types of formats. I know that gnupg is able to handle X.509 to some extend and I guess it is not full featured. Will gnupg be able to use X.509 in all features somewhere in the future? Bernhard Reiter schrieb: > On Dienstag, 20. Januar 2009, Stefan X wrote: >> But to be able to use it also >> for private email encryption, such discussed interoperability with >> OpenPGP and also with Open Source applications will be important. > > But note that Free Software can do S/MIME with the cards just fine. > (E.g. KMail/Kontact via gpgme and thus GnuPG2's gpgsm.) > So Free Software is technically compatible to S/MIME already. > > The biggest obstacles are good configuration and administration. > Of course distributors could help a lot with good configuration. > > As I explained before, it is important for people to understand what a > specific signature means. Currently the differences for S/MIME and OpenPGP > are wide on the average. So when building a user interface, I personally > suggest to keep S/MIME and OpenPGP usage visible and distinct. > This caters much better to the internal and practical limits that each of the > methods currently have. > > Bernhard > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From rjh at sixdemonbag.org Sat Jan 24 18:11:01 2009 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 24 Jan 2009 12:11:01 -0500 Subject: Differences: OpenPGP vs. X.509 In-Reply-To: <497B49DB.7070705@gmx.net> References: <496CE68A.7010804@gmx.net> <87k58qqiy8.fsf@wheatstone.g10code.de> <4975D68D.5080907@gmx.net> <200901210943.14653.bernhard@intevation.de> <497B49DB.7070705@gmx.net> Message-ID: <497B4BA5.4010709@sixdemonbag.org> Stefan X wrote: > As explained before I see huge benefits in case one format > would be used instead of two. X.509 is effectively dead. The protocol has a lot of hardwired dependencies on MD5, and the ongoing attacks against MD5 are below-the-waterline holes on X.509. X.509 may be overhauled to repair the damage, or it may be discarded. We don't know at this point. This makes it very premature to talk about any kind of merging of standards. From stefanxe at gmx.net Sat Jan 24 21:27:31 2009 From: stefanxe at gmx.net (Stefan X) Date: Sat, 24 Jan 2009 21:27:31 +0100 Subject: Differences: OpenPGP vs. X.509 In-Reply-To: <497B4BA5.4010709@sixdemonbag.org> References: <496CE68A.7010804@gmx.net> <87k58qqiy8.fsf@wheatstone.g10code.de> <4975D68D.5080907@gmx.net> <200901210943.14653.bernhard@intevation.de> <497B49DB.7070705@gmx.net> <497B4BA5.4010709@sixdemonbag.org> Message-ID: <497B79B3.9030803@gmx.net> Are you sure about the hardwired dependencies to MD5? I know real world examples where no MD5 is used at all with X.509 and I am quite sure they are standard conform. Robert J. Hansen schrieb: > Stefan X wrote: >> As explained before I see huge benefits in case one format >> would be used instead of two. > > X.509 is effectively dead. The protocol has a lot of hardwired > dependencies on MD5, and the ongoing attacks against MD5 are > below-the-waterline holes on X.509. > > X.509 may be overhauled to repair the damage, or it may be discarded. > We don't know at this point. This makes it very premature to talk about > any kind of merging of standards. > > From rjh at sixdemonbag.org Sat Jan 24 22:15:28 2009 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 24 Jan 2009 16:15:28 -0500 Subject: Differences: OpenPGP vs. X.509 In-Reply-To: <497B79B3.9030803@gmx.net> References: <496CE68A.7010804@gmx.net> <87k58qqiy8.fsf@wheatstone.g10code.de> <4975D68D.5080907@gmx.net> <200901210943.14653.bernhard@intevation.de> <497B49DB.7070705@gmx.net> <497B4BA5.4010709@sixdemonbag.org> <497B79B3.9030803@gmx.net> Message-ID: <497B84F0.1050408@sixdemonbag.org> Stefan X wrote: > Are you sure about the hardwired dependencies to MD5? I know real world > examples where no MD5 is used at all with X.509 and I am quite sure they > are standard conform. Daniel Nagy said it better than I could -- "As far as I can judge, X.509 PKI is still in the state of catastrophic failure with no obvious way out. Right now, if my browser (or yours, or anybody else's) tells me that the site I am browsing presented a certificate issued to it by a legitimate CA, I cannot be sure that this assertion is true. Rejecting all certificates with MD5 in their signatures is not a solution (there are too many out there and replacing them requires non-trivial cooperation between different parties; no-one can do it acting alone). Not issuing any more MD5-based certificates is not a solution (who knows how many rogue CAs are already out there?). In fact, I do not see an easy and cheap solution out of this mess." From jmoore3rd at bellsouth.net Sat Jan 24 22:35:03 2009 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Sat, 24 Jan 2009 16:35:03 -0500 Subject: Differences: OpenPGP vs. X.509 In-Reply-To: <497B84F0.1050408@sixdemonbag.org> References: <496CE68A.7010804@gmx.net> <87k58qqiy8.fsf@wheatstone.g10code.de> <4975D68D.5080907@gmx.net> <200901210943.14653.bernhard@intevation.de> <497B49DB.7070705@gmx.net> <497B4BA5.4010709@sixdemonbag.org> <497B79B3.9030803@gmx.net> <497B84F0.1050408@sixdemonbag.org> Message-ID: <497B8987.3070400@bellsouth.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Robert J. Hansen wrote: > Not issuing > any more MD5-based certificates is not a solution (who knows how many > rogue CAs are already out there?). In fact, I do not see an easy and > cheap solution out of this mess." Interestingly, even MyOpenID uses an MD5 based Certificate to secure Login on their Site. :-D JOHN ;) Timestamp: Saturday 24 Jan 2009, 16:32 --500 (Eastern Standard Time) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10-svn4907: (MingW32) Comment: Public Key at: http://tinyurl.com/8cpho Comment: Gossamer Spider Web of Trust: https://www.gswot.org Comment: Homepage: http://tinyurl.com/yzhbhx iQEcBAEBCgAGBQJJe4mEAAoJEBCGy9eAtCsPuWUH/2sNog3+V8mzAj35pXre+rx9 7AnEOM0mmMzt9OFEEhYOTbNIE1yD3DXi95XWIwuF5Zh/lMPyUpT5mDgbqHsWitr+ FAOmm1BGQE7Ppru2iFmSka6hxVkQ6HEEQbmYEIRZ2biyLoTSEmDvns3QkpeWC722 PKWlgve9Wgz1y18UDjylWUeYeeFOGCT3KhknVtXjIIV62SBFkFHMSVbDw6vu9XaR Vf/M6DDkjxD/q4llTuluLonZOhJKXTAtAgqwSs6fFfRglLxCqLuoLVXPeLW5n0f+ mivW6uxKPnV8HAJxr8I2iL5ShtCZFshuI9fCJDBJCmYWvjZhtkuJuqZ9J8vaaeo= =OACn -----END PGP SIGNATURE----- From stefanxe at gmx.net Sat Jan 24 22:50:40 2009 From: stefanxe at gmx.net (Stefan X) Date: Sat, 24 Jan 2009 22:50:40 +0100 Subject: Differences: OpenPGP vs. X.509 In-Reply-To: <497B84F0.1050408@sixdemonbag.org> References: <496CE68A.7010804@gmx.net> <87k58qqiy8.fsf@wheatstone.g10code.de> <4975D68D.5080907@gmx.net> <200901210943.14653.bernhard@intevation.de> <497B49DB.7070705@gmx.net> <497B4BA5.4010709@sixdemonbag.org> <497B79B3.9030803@gmx.net> <497B84F0.1050408@sixdemonbag.org> Message-ID: <497B8D30.50606@gmx.net> I see you didn't mean that MD5 is REQUIRED but mean that the problem is MD5 is ALLOWED. I agree that this is really a problem. OpenPGP declared MD5 possible for legacy reasons only so that MD5 is practically not used in the OpenPGP world anymore. This is different in the X.509 world where MD5 is used widely. I am not sure if X.509 defines valid algorithms at all or if it is just a kind of container. At least a quick look in RFC4158 supports this assumption. I appreciate if somebody could tell me whether this is correct or wrong. Robert J. Hansen schrieb: > Stefan X wrote: >> Are you sure about the hardwired dependencies to MD5? I know real world >> examples where no MD5 is used at all with X.509 and I am quite sure they >> are standard conform. > > Daniel Nagy said it better than I could -- > > "As far as I can judge, X.509 PKI is still in the state of catastrophic > failure with no obvious way out. > > Right now, if my browser (or yours, or anybody else's) tells me that the > site I am browsing presented a certificate issued to it by a legitimate > CA, I cannot be sure that this assertion is true. Rejecting all > certificates with MD5 in their signatures is not a solution (there are > too many out there and replacing them requires non-trivial cooperation > between different parties; no-one can do it acting alone). Not issuing > any more MD5-based certificates is not a solution (who knows how many > rogue CAs are already out there?). In fact, I do not see an easy and > cheap solution out of this mess." > > From rjh at sixdemonbag.org Sat Jan 24 23:06:45 2009 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 24 Jan 2009 17:06:45 -0500 Subject: Differences: OpenPGP vs. X.509 In-Reply-To: <497B8D30.50606@gmx.net> References: <496CE68A.7010804@gmx.net> <87k58qqiy8.fsf@wheatstone.g10code.de> <4975D68D.5080907@gmx.net> <200901210943.14653.bernhard@intevation.de> <497B49DB.7070705@gmx.net> <497B4BA5.4010709@sixdemonbag.org> <497B79B3.9030803@gmx.net> <497B84F0.1050408@sixdemonbag.org> <497B8D30.50606@gmx.net> Message-ID: <497B90F5.8080304@sixdemonbag.org> Stefan X wrote: > I see you didn't mean that MD5 is REQUIRED but mean that the problem is > MD5 is ALLOWED. I agree that this is really a problem. More like, "support for MD5 is required." Sure, you can create X.509 certs that use SHA-1, but the amount of MD5 certs in the X.509 ecosystem, and the incredible problems involved in moving these certs to better hashes, mean that I think it's pretty premature to talk about merging X.509 and OpenPGP. I'd like to see X.509 get their house in order. Once that's taken care of, then we can start discussing bringing the two standards closer together. From wk at gnupg.org Sun Jan 25 16:26:58 2009 From: wk at gnupg.org (Werner Koch) Date: Sun, 25 Jan 2009 16:26:58 +0100 Subject: Differences: OpenPGP vs. X.509 In-Reply-To: <497B90F5.8080304@sixdemonbag.org> (Robert J. Hansen's message of "Sat, 24 Jan 2009 17:06:45 -0500") References: <496CE68A.7010804@gmx.net> <87k58qqiy8.fsf@wheatstone.g10code.de> <4975D68D.5080907@gmx.net> <200901210943.14653.bernhard@intevation.de> <497B49DB.7070705@gmx.net> <497B4BA5.4010709@sixdemonbag.org> <497B79B3.9030803@gmx.net> <497B84F0.1050408@sixdemonbag.org> <497B8D30.50606@gmx.net> <497B90F5.8080304@sixdemonbag.org> Message-ID: <87skn7z9rx.fsf@wheatstone.g10code.de> On Sat, 24 Jan 2009 23:06, rjh at sixdemonbag.org said: > More like, "support for MD5 is required." Sure, you can create X.509 > certs that use SHA-1, but the amount of MD5 certs in the X.509 > ecosystem, and the incredible problems involved in moving these certs to >From my experience that is not true. MD5 is definitely not hardwired into X.509. In fact SHA-1 is for quite some years the predominant hash algorithm. The only semi-hardwired algorithm is RSA which is not a problem. Of course you can use DSA but it is too hard to use because it is not supported by any mass market application. The troubles we are currently in with X.509 is similar to OpenPGP: Most fielded applications do not support SHA-256 and thus we can't yet use SHA-256. It will takes about 5 years before SHA-256 is practically usable with X.509. For OpenPGP it is far easier because PGP and GnuPG support SHA-256 for quite some time. Back to MD5 and X.509 used with SSL (TLS): I know that there are quite some CAs who still issue MD5 signed certificates. However we also all know the problems of web security - MD5 is for sure not the weakest link. For example the bunch of pre-installed root certificates is an easier target to attack. And we won't be able to change the pre-installed root certificates in consumer applications until the hardware goes out of fashion and new hardware with a newer OS will be used. Too bad. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From bernhard at intevation.de Mon Jan 26 11:13:26 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 26 Jan 2009 11:13:26 +0100 Subject: Differences: OpenPGP vs. X.509 In-Reply-To: <497B49DB.7070705@gmx.net> References: <496CE68A.7010804@gmx.net> <200901210943.14653.bernhard@intevation.de> <497B49DB.7070705@gmx.net> Message-ID: <200901261113.26432.bernhard@intevation.de> On Samstag, 24. Januar 2009, Stefan X wrote: > I know that gnupg is able to handle X.509 to some extend and I guess it > is not full featured. For email the gnupg family is pretty full featured. It can do several methods of validation, CRLs, OCSP, several lookup types (LDAP, HTTP) and so on. For TLS (SSL) I've heard gnutls still misses a few things. I appreciate statements from more knowledgeable people. > Will gnupg be able to use X.509 in all features > somewhere in the future? "All feature" and "an implementation" seem to outrule each other in X.509 space. Why? To get an idea, read: X.509 Style Guide, Peter Gutmann http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 206 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Mon Jan 26 12:14:44 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 26 Jan 2009 12:14:44 +0100 Subject: assuan interface for gpgme Message-ID: <87bptu9v4r.fsf@wheatstone.g10code.de> Hi! As you probably know GnuPG uses a simple protocol named Assuan for interprocess communication between the components. Sometimes it is necessary to issue commands to gpg-agent which are not available trough any other tool. For this gpg-connect-agent is a convenient and scriptable tool. Sometimes it is required to access for example gpg-agent directly from an application. To avoid the overhead of running gpg-connect-agent and prepare an appropriate script is now also possible to use the gpgme library for this task. Gpgme already uses the Assuan protocol to access gpgsm and thus all code is already available. The latest SVN version of gpgme now features a wrapped Assuan_transact call to directly access any Assuan protocol server. This is still an experimental interface but I only expect minor API changes before it gets frozen. The small test program tests/opassuan/tcommand.c can be used to issue arbitrary command to gpg-agent. For example: $ ./t-command 'GET_PASSPHRASE --data X X X X' DATA_CB: datalen=3 assuan command `GET_PASSPHRASE --data X X X X' succeeded Let's have a look at t-command.c. First we need a couple of callback functions which are similar to the those used with assuan_transact. However, a little bit pre-processing has already been done. static gpg_error_t data_cb (void *opaque, const void *data, size_t datalen) { printf ("DATA_CB: datalen=%d\n", (int)datalen); return 0; } This one is called for all 'D ' lines. DATA,DATLEN is the de-escaped data line. for large data's you may get a lot of data lines and usually you want to concatenate them all. OPAQUE is the pointer value you gave to gpgme_op_assuan_transact for this callback. static gpg_error_t inq_cb (void *opaque, const char *name, const char *args, gpgme_assuan_sendfnc_t sendfnc, gpgme_assuan_sendfnc_ctx_t sendfnc_value) { printf ("INQ_CB: name=`%s' args=`%s'\n", name, args); return 0; } This callback is used for 'INQUIRE ' lines. NAME is the name of the inquiry and ARGS gives the rest of the line. An inquiry is used by a server to retrieve additional data from the client. If the client has this data available it needs to use the SENDFNC to send the data back to the server like this: err = sendfnc (sendfnc_value, my_data, my_datalen); If the server returns an error this error should be the return value of the inquiry. This send function may be called as often as required. static gpg_error_t status_cb (void *opaque, const char *status, const char *args) { printf ("STATUS_CB: status=`%s' args=`%s'\n", status, args); return 0; } This is the status callback with the STATUS being the name of the STATUS and ARGS the rest of the status line. int main (int argc, char **argv) { gpgme_error_t err; (Note that gpgme_error_t is the same as gpg_error_t). gpgme_ctx_t ctx; const char *command; Initialize GPGME and get the command. gpgme_check_version (NULL); if (argc) { argc--; argv++; } command = argc? *argv : "NOP"; Create a new context: err = gpgme_new (&ctx); fail_if_err (err); and set change the protocol from the default to the new ASSUAN protocol. err = gpgme_set_protocol (ctx, GPGME_PROTOCOL_ASSUAN); fail_if_err (err); At this point the context CTX is initialized to access the currently running gpg-agent. Accessing gpg-agent is the default, to access a different Assuan server see below. err = gpgme_op_assuan_transact (ctx, command, data_cb, NULL, inq_cb, NULL, status_cb, NULL); fail_if_err (err); The above function closely resembles the assuan_transact function: You give a context, an Assuan command line and the 3 callback functions. As usual in gpgme you may instead gpgme_op_assuan_transact_start which is the asynchronous version of the function. To make the synchronous and asynchronous versions similar, the error code from gpgme_op_assuan_transact does only return errors pertaining to the use Assuan connection and gpgme itself; it does not return the result of the actual Assuan command (OK or ERR). To get that result you use: err = gpgme_op_assuan_result (ctx); which returns 0 for the 'OK' line and an gpg-error code for the 'ERR ' line. The connection is kept open regardless of this return value. Now lets print something: if (err) fprintf (stderr, "assuan command `%s' failed: %s <%s> (%d)\n", command, gpg_strerror (err), gpg_strsource (err), err); else fprintf (stderr, "assuan command `%s' succeeded\n", command); and because we do not want to send another command, we close the connection by releasing the context: gpgme_release (ctx); return 0; } The remaining question is how to use a different socket than the default one sued for gpg-agent. We use the engine set_info function to accomplish this: Right after creating the context you may call err = gpgme_ctx_set_engine_info (ctx, GPGME_PROTOCOL_ASSUAN, "/tmp/foo/socket", ""); to connect to an Assuan server listening on socket /tmp/foo/socket. Note that the last parameter is an empty string. If you would use NULL, here the gpgme default value would be used which is an option to run the initial Assuan commands used for gpg-agent. Right, we are re-using HOME_DIR parameter to pass flags to the engine. If you want to test for this feature in configure.ac (but recall that the API is not yet fixed), you may use this code: AM_PATH_GPGME("$NEED_GPGME_API:$NEED_GPGME_VERSION", have_gpgme=yes,have_gpgme=no) _save_libs=$LIBS LIBS="$LIBS $GPGME_LIBS" AC_CHECK_FUNCS([gpgme_op_assuan_transact]) LIBS=$_save_libs If you want to try this all out, you also need to install the latest GnuPG from SVN because gpgconf has been changed to return the socket used by gpg-agent. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From bernhard at intevation.de Thu Jan 29 10:03:30 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 29 Jan 2009 10:03:30 +0100 Subject: Fix pinentry.tex lc-type command line option type Message-ID: <200901291003.33423.bernhard@intevation.de> -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: pinentry-r189-lc-ctype-fix.texi.patch Type: text/x-diff Size: 674 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1603 bytes Desc: not available URL: From bernhard at intevation.de Thu Jan 29 10:52:39 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 29 Jan 2009 10:52:39 +0100 Subject: pinentry-curses defect Message-ID: <200901291052.41791.bernhard@intevation.de> typing "?" bernhard at erato:/home/mobilehome/bernhard/tmp$ echo getpin | pinentry-curses --ttyname "/dev/pts/8" --lc-ctype "de_DE at euro" | od -tx1c 0000000 4f 4b 20 59 6f 75 72 20 6f 72 64 65 72 73 20 70 O K Y o u r o r d e r s p 0000020 6c 65 61 73 65 0a 44 20 c3 0a 4f 4b 0a l e a s e \n D ? \n O K \n 0000035 typing "?" - works bernhard at erato:/home/mobilehome/bernhard/tmp$ echo getpin | pinentry-qt --ttyname "/dev/pts/8" --lc-ctype "de_DE at euro" | od -tx1c 0000000 4f 4b 20 59 6f 75 72 20 6f 72 64 65 72 73 20 70 O K Y o u r o r d e r s p 0000020 6c 65 61 73 65 0a 44 20 c3 a4 0a 4f 4b 0a l e a s e \n D ? ? \n O K \n 0000036 typing "?g" bernhard at erato:/home/mobilehome/bernhard/tmp$ echo getpin | pinentry-curses --ttyname "/dev/pts/8" --lc-ctype "de_DE at euro" | od -tx1c 0000000 4f 4b 20 59 6f 75 72 20 6f 72 64 65 72 73 20 70 O K Y o u r o r d e r s p 0000020 6c 65 61 73 65 0a 44 20 c3 a4 0a 4f 4b 0a l e a s e \n D ? ? \n O K \n 0000036 typing "foo" echo getpin | pinentry-curses --ttyname "/dev/pts/8" --lc-ctype "de_DE at euro" | od -tx1c 0000000 4f 4b 20 59 6f 75 72 20 6f 72 64 65 72 73 20 70 O K Y o u r o r d e r s p 0000020 6c 65 61 73 65 0a 44 20 66 6f 6f 0a 4f 4b 0a l e a s e \n D f o o \n O K \n 0000037 -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1601 bytes Desc: not available URL: From rw at rlworkman.net Tue Jan 13 06:02:30 2009 From: rw at rlworkman.net (Robby Workman) Date: Tue, 13 Jan 2009 05:02:30 -0000 Subject: scim and pinentry-gtk2 In-Reply-To: <87iqyrw476.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <47BDF11A.8010500@rlworkman.net> <87hcfvg8wu.wl%marcus.brinkmann@ruhr-uni-bochum.de> <47E09E50.8040106@rlworkman.net> <87myo5wkg3.wl%marcus.brinkmann@ruhr-uni-bochum.de> <47FBB637.9070103@rlworkman.net> <87iqyrw476.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <20090112230121.63ce9bca@liberty.rlwhome.lan> On Wed, 09 Apr 2008 15:25:17 +0200 Marcus Brinkmann wrote: > At Tue, 08 Apr 2008 13:15:19 -0500, > Robby Workman wrote: > > I suppose the command line option to pinentry might be acceptable, > > but there would need to be some way to specify in gpg-agent that > > pinentry should be called with the --scim (or whatever) option. > > Perhaps it could check for the presence of the XIM_PROGRAM or > > GTK_IM_MODULE environment variables and automatically do the right > > thing. > > In response to this and Werner's concern, it could also be done by > means of a wrapper script. But this is basically the same as a new > binary, really. > > > Alternatively, a pinentry-scim binary (which could then be specified > > in gpg-agent with --pinentry-program) would be acceptable, I > > suppose. > > Right. I would haggle about the name, because there is nothing > special about scim (maybe the current gtk pinentry should be renamed > instead), but the idea is the same. Just a gentle "poke" on this... :) I noticed the new pinentry release, but nothing about this issue... In case the context has been forgotten, see here: http://lists.gnupg.org/pipermail/gnupg-devel/2008-April/024326.html -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: