From dkg at fifthhorseman.net Wed Aug 1 00:53:54 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 31 Jul 2012 18:53:54 -0400 Subject: [Sks-devel] dealing with misplaced signatures In-Reply-To: <50185657.5010107@sumptuouscapital.com> References: <50170AE0.9070601@fifthhorseman.net> <20120731053957.GA2691@sivokote.iziade.m$> <5017F611.4030300@fifthhorseman.net> <9E8D7E34-4A6A-4E21-BE3C-4084BA5F3773@jabberwocky.com> <50185657.5010107@sumptuouscapital.com> Message-ID: <50186202.4030309@fifthhorseman.net> On 07/31/2012 06:04 PM, Kristian Fiskerstrand wrote: > Currently we have a patch[0] ready that allows for these signatures to > be cleaned in the getting (and vindex) of the key, A patch with the stated functionality would be a Good Thing. > However, before creating a Pull Request into the SKS Trunk, we have to > verify that this solution would not actually violating RFC4880. If anything, the current sks implementation is violating RFC 4880, which clearly states that transferable public key certificates contain: - After each Subkey packet, one Signature packet, plus optionally a revocation SKS seems willing to record and produce more than one signature packet in this position. The "one signature packet" is unambiguously intended to refer to a subkey binding signature, fwiw, not any of the other signature types. Note that i think it's probably reasonable for sks to store more than one subkey binding signature packet per subkey (to accomodate subkey expiration revisions, particularly since sks has no cryptographic verification in place, so it can't tell a valid subkey expiration revision from an invalid one); i'm not arguing for blind adherence to the spec, i'm arguing for practical utility here. > Although > there are implications that 0x10-0x13 signatures are for UID/UAT > packages, and as such would not belong to a subkey, would starting to > "hide information" be a violation of SKS's neutral way of storing data, sks should not be so neutral as to store incomprehensible data (we reject malformed packets, for example), and no one has stepped forward with any explanation of why an identity certification signature could make sense following a subkey. Pursuing the patch to sks will fix one part of the problem here; gpg probably also needs fixing to drop these bogus packets, or at least to reassign them to their correct spot in the certificate if such a spot can be found. Note also that the same signature packet might be duplicated; if it fits in one place in the keyring, and a byte-for-byte identical signature packet is found elsewhere, in a place where it is not cryptographically valid, that latter copy of the packet can probably be safely discarded. my $0.02, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Wed Aug 1 00:04:07 2012 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 01 Aug 2012 00:04:07 +0200 Subject: dealing with misplaced signatures In-Reply-To: <9E8D7E34-4A6A-4E21-BE3C-4084BA5F3773@jabberwocky.com> References: <50170AE0.9070601@fifthhorseman.net> <20120731053957.GA2691@sivokote.iziade.m$> <5017F611.4030300@fifthhorseman.net> <9E8D7E34-4A6A-4E21-BE3C-4084BA5F3773@jabberwocky.com> Message-ID: <50185657.5010107@sumptuouscapital.com> On 2012-07-31 23:29, David Shaw wrote: > What's happening here is that the key is mangled on SKS (whether SKS > mangled it or it was imported already mangled doesn't matter). GPG > fetches it, and there is some code to move misplaced packets to the > right place. Unfortunately, as you noticed, that code does not work > if there is more than one user ID. > > This code actually dates to 1998. The comment: "* Note: This > function does not work if there is more than one user ID." > Hi David, Any recommendation about how we should handle this scenario within SKS. Currently we're having a debate about the existence of signatures not 0x18 and 0x28 on the subkey. Currently we have a patch[0] ready that allows for these signatures to be cleaned in the getting (and vindex) of the key, which at least would reduce the problem of re-importing (--recv-key or --refresh) the mangled signatures after they have been moved (resulting in duplication). This is implemented [1] is in the cleaning layer for vindex and get, and not on the data store, so the original data is available at [2] (and respective clean=off for get). This approach means that no change is necessary to the reconciliation process, and as such maintain backwards compatibility. However, before creating a Pull Request into the SKS Trunk, we have to verify that this solution would not actually violating RFC4880. Although there are implications that 0x10-0x13 signatures are for UID/UAT packages, and as such would not belong to a subkey, would starting to "hide information" be a violation of SKS's neutral way of storing data, or is this mitigated by the ability to get the full data using clean=off (which iirc is not officially in the HKP specs, or used by any implementation). What are your reflections around such an addition to SKS? does it make sense for us to include something like this, or should we leave the interpretation up to the OpenPGP implementation and keep the keys as they are in SKS? [0] https://bitbucket.org/kristianf/sks-keyserver/changeset/b436e48dd8e08c247b841c5460786655d3e148bf [1] http://keys2.kfwebs.net:11371/pks/lookup?op=vindex&search=0xED34CEABE27BAABC [2] http://keys2.kfwebs.net:11371/pks/lookup?op=vindex&clean=off&search=0xED34CEABE27BAABC -- ---------------------------- Kristian Fiskerstrand http://www.sumptuouscapital.com Twitter: @krifisk ---------------------------- Corruptissima re publica plurim? leges The greater the degeneration of the republic, the more of its laws ---------------------------- This email was digitally signed using the OpenPGP standard. If you want to read more about this The book: Sending Emails - The Safe Way: An introduction to OpenPGP security is now available in both Amazon Kindle and Paperback format at http://www.amazon.com/dp/B006RSG1S4/ ---------------------------- Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 898 bytes Desc: OpenPGP digital signature URL: From kristian.fiskerstrand at sumptuouscapital.com Wed Aug 1 01:16:18 2012 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 01 Aug 2012 01:16:18 +0200 Subject: [Sks-devel] dealing with misplaced signatures In-Reply-To: <50186202.4030309@fifthhorseman.net> References: <50170AE0.9070601@fifthhorseman.net> <20120731053957.GA2691@sivokote.iziade.m$> <5017F611.4030300@fifthhorseman.net> <9E8D7E34-4A6A-4E21-BE3C-4084BA5F3773@jabberwocky.com> <50185657.5010107@sumptuouscapital.com> <50186202.4030309@fifthhorseman.net> Message-ID: <50186742.3040207@sumptuouscapital.com> On 2012-08-01 00:53, Daniel Kahn Gillmor wrote: > On 07/31/2012 06:04 PM, Kristian Fiskerstrand wrote: ... > > If anything, the current sks implementation is violating RFC 4880, which > clearly states that transferable public key certificates contain: > > - After each Subkey packet, one Signature packet, plus optionally a > revocation > Hi Daniel, What complicate it a bit is that an argument can be made that this, from 11.1 [0], "The essential elements of a transferable public key are as follows:" is a non-exhaustive list, i.e. it is more of a minimum requirement than a full spec (by the use of the word "essential"). [0] http://www.ietf.org/rfc/rfc4880.txt -- ---------------------------- Kristian Fiskerstrand http://www.sumptuouscapital.com Twitter: @krifisk ---------------------------- Corruptissima re publica plurim? leges The greater the degeneration of the republic, the more of its laws ---------------------------- This email was digitally signed using the OpenPGP standard. If you want to read more about this The book: Sending Emails - The Safe Way: An introduction to OpenPGP security is now available in both Amazon Kindle and Paperback format at http://www.amazon.com/dp/B006RSG1S4/ ---------------------------- Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 898 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Wed Aug 1 06:44:48 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 1 Aug 2012 00:44:48 -0400 Subject: dealing with misplaced signatures In-Reply-To: <50185657.5010107@sumptuouscapital.com> References: <50170AE0.9070601@fifthhorseman.net> <20120731053957.GA2691@sivokote.iziade.m$> <5017F611.4030300@fifthhorseman.net> <9E8D7E34-4A6A-4E21-BE3C-4084BA5F3773@jabberwocky.com> <50185657.5010107@sumptuouscapital.com> Message-ID: <2D78BAEB-03E6-4AE7-ACA6-5B2A3B82CB34@jabberwocky.com> On Jul 31, 2012, at 6:04 PM, Kristian Fiskerstrand wrote: > On 2012-07-31 23:29, David Shaw wrote: > >> What's happening here is that the key is mangled on SKS (whether SKS >> mangled it or it was imported already mangled doesn't matter). GPG >> fetches it, and there is some code to move misplaced packets to the >> right place. Unfortunately, as you noticed, that code does not work >> if there is more than one user ID. >> >> This code actually dates to 1998. The comment: "* Note: This >> function does not work if there is more than one user ID." >> > > Hi David, > > Any recommendation about how we should handle this scenario within SKS. > Currently we're having a debate about the existence of signatures not > 0x18 and 0x28 on the subkey. > > Currently we have a patch[0] ready that allows for these signatures to > be cleaned in the getting (and vindex) of the key, which at least would > reduce the problem of re-importing (--recv-key or --refresh) the mangled > signatures after they have been moved (resulting in duplication). This > is implemented [1] is in the cleaning layer for vindex and get, and not > on the data store, so the original data is available at [2] (and > respective clean=off for get). This approach means that no change is > necessary to the reconciliation process, and as such maintain backwards > compatibility. > > However, before creating a Pull Request into the SKS Trunk, we have to > verify that this solution would not actually violating RFC4880. Although > there are implications that 0x10-0x13 signatures are for UID/UAT > packages, and as such would not belong to a subkey, would starting to > "hide information" be a violation of SKS's neutral way of storing data, > or is this mitigated by the ability to get the full data using clean=off > (which iirc is not officially in the HKP specs, or used by any > implementation). I don't feel it violates RFC-4880 for SKS to hide incorrect packets. While SKS can't do a lot of validation as it doesn't have crypto, it certainly can rule out certain packets in certain places without needing the ability to check signatures or the like. That said, I'm not 100% sure it's a good idea: hiding the packets is potentially harmful. If GPG could move the bad signature to the right place (and at the moment it cannot do this for a key with more than one user ID), then hiding the packets from GPG prevents this repair from happening. After all, if GPG doesn't get the packets, it can't move them to the right place. This means the signatures are effectively lost, which can change the interpretation of a key (a user ID can become not self-signed, and thus invalid, or a revoked user ID could become unrevoked, etc). So my thought it that while SKS should be free to do this, I think a better solution to the original problem would be to fix GPG to do a better job repairing things. Possibly a best of both worlds would be to have SKS do its cleaning, and then GPG, after it gained the ability to do a repair, would start requesting keys with "clean=off". This way, clients that could not repair would not get mangled keys, and clients that could repair would get the whole key and be able to repair it. David From wk at gnupg.org Wed Aug 1 06:51:19 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 01 Aug 2012 06:51:19 +0200 Subject: dealing with misplaced signatures In-Reply-To: <9E8D7E34-4A6A-4E21-BE3C-4084BA5F3773@jabberwocky.com> (David Shaw's message of "Tue, 31 Jul 2012 17:29:10 -0400") References: <50170AE0.9070601@fifthhorseman.net> <20120731053957.GA2691@sivokote.iziade.m$> <5017F611.4030300@fifthhorseman.net> <9E8D7E34-4A6A-4E21-BE3C-4084BA5F3773@jabberwocky.com> Message-ID: <87ipd343lk.fsf@vigenere.g10code.de> On Tue, 31 Jul 2012 23:29, dshaw at jabberwocky.com said: > mangled it or it was imported already mangled doesn't matter). GPG > fetches it, and there is some code to move misplaced packets to the > right place. Unfortunately, as you noticed, that code does not work At least in master there is no code to move packet during import; we only delete certain misplaced packets. > This code actually dates to 1998. The comment: "* Note: This function > does not work if there is more than one user ID." That is only used by --edit-key as a fix to a bug in a very early version of GnuPG. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dshaw at jabberwocky.com Wed Aug 1 07:11:19 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 1 Aug 2012 01:11:19 -0400 Subject: dealing with misplaced signatures In-Reply-To: <87ipd343lk.fsf@vigenere.g10code.de> References: <50170AE0.9070601@fifthhorseman.net> <20120731053957.GA2691@sivokote.iziade.m$> <5017F611.4030300@fifthhorseman.net> <9E8D7E34-4A6A-4E21-BE3C-4084BA5F3773@jabberwocky.com> <87ipd343lk.fsf@vigenere.g10code.de> Message-ID: On Aug 1, 2012, at 12:51 AM, Werner Koch wrote: > On Tue, 31 Jul 2012 23:29, dshaw at jabberwocky.com said: > >> mangled it or it was imported already mangled doesn't matter). GPG >> fetches it, and there is some code to move misplaced packets to the >> right place. Unfortunately, as you noticed, that code does not work > > At least in master there is no code to move packet during import; we > only delete certain misplaced packets. > >> This code actually dates to 1998. The comment: "* Note: This function >> does not work if there is more than one user ID." > > That is only used by --edit-key as a fix to a bug in a very early > version of GnuPG. I know this was the original reason for the function, but it's also the code that is fixing the mangled keys on SKS. When you import one of these keys, it is imported as-as (I did not mean to imply the repair happened as part of --import). The next time you run --edit-key, it is repaired. If the key has one user ID, the repair is as good as it can get. If the key has multiple user IDs, it's not a reliable repair as the signatures may end up on the wrong user ID. David From wk at gnupg.org Wed Aug 1 09:54:57 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 01 Aug 2012 09:54:57 +0200 Subject: dealing with misplaced signatures In-Reply-To: (David Shaw's message of "Wed, 1 Aug 2012 01:11:19 -0400") References: <50170AE0.9070601@fifthhorseman.net> <20120731053957.GA2691@sivokote.iziade.m$> <5017F611.4030300@fifthhorseman.net> <9E8D7E34-4A6A-4E21-BE3C-4084BA5F3773@jabberwocky.com> <87ipd343lk.fsf@vigenere.g10code.de> Message-ID: <8762933v3i.fsf@vigenere.g10code.de> On Wed, 1 Aug 2012 07:11, dshaw at jabberwocky.com said: > I know this was the original reason for the function, but it's also > the code that is fixing the mangled keys on SKS. When you import one > of these keys, it is imported as-as (I did not mean to imply the > repair happened as part of --import). The next time you run > --edit-key, it is repaired. If the key has one user ID, the repair is If that problem happens more often now we should indeed try to clean it up right during import (from file or keyserver). Detecting duplicated signatures will be easy. If we need to verify a self-signature, we probably need to add a post processing stage to the import. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Wed Aug 1 18:33:37 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 01 Aug 2012 12:33:37 -0400 Subject: dealing with misplaced signatures In-Reply-To: <2D78BAEB-03E6-4AE7-ACA6-5B2A3B82CB34@jabberwocky.com> References: <50170AE0.9070601@fifthhorseman.net> <20120731053957.GA2691@sivokote.iziade.m$> <5017F611.4030300@fifthhorseman.net> <9E8D7E34-4A6A-4E21-BE3C-4084BA5F3773@jabberwocky.com> <50185657.5010107@sumptuouscapital.com> <2D78BAEB-03E6-4AE7-ACA6-5B2A3B82CB34@jabberwocky.com> Message-ID: <50195A61.8030900@fifthhorseman.net> On 08/01/2012 12:44 AM, David Shaw wrote: > hiding the packets is potentially harmful. [...] > hiding the packets from GPG prevents this repair from happening. > After all, if GPG doesn't get the packets, it can't move them to the right place. > This means the signatures are effectively lost, fwiw, in the cases where i've seen this, the packets in question are *already* in the correct place, they just happen to *also* be in the incorrect place, causing noise. We don't support "fixing" the problem where someone submits a signature packet after the wrong User ID, or attached to the wrong key entirely, and i don't believe we should. Submitting the packets in the correct order for them to be properly interpreted is the job of the key uploader, not the job of the keyservers. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Wed Aug 1 19:12:01 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 1 Aug 2012 13:12:01 -0400 Subject: dealing with misplaced signatures In-Reply-To: <50195A61.8030900@fifthhorseman.net> References: <50170AE0.9070601@fifthhorseman.net> <20120731053957.GA2691@sivokote.iziade.m$> <5017F611.4030300@fifthhorseman.net> <9E8D7E34-4A6A-4E21-BE3C-4084BA5F3773@jabberwocky.com> <50185657.5010107@sumptuouscapital.com> <2D78BAEB-03E6-4AE7-ACA6-5B2A3B82CB34@jabberwocky.com> <50195A61.8030900@fifthhorseman.net> Message-ID: <862572A7-CF93-466F-8F30-CE7258944A08@jabberwocky.com> On Aug 1, 2012, at 12:33 PM, Daniel Kahn Gillmor wrote: > On 08/01/2012 12:44 AM, David Shaw wrote: >> hiding the packets is potentially harmful. [...] >> hiding the packets from GPG prevents this repair from happening. >> After all, if GPG doesn't get the packets, it can't move them to the > right place. > This means the signatures are effectively lost, > > fwiw, in the cases where i've seen this, the packets in question are > *already* in the correct place, they just happen to *also* be in the > incorrect place, causing noise. > > We don't support "fixing" the problem where someone submits a signature > packet after the wrong User ID, or attached to the wrong key entirely, > and i don't believe we should. I don't think anyone here has suggested that the keyservers repair anything. For a start, they're not capable of it. The question is whether the keyservers should hide obviously incorrect things when passing keys back to clients, or pass back complete keys, including the obviously incorrect things. My point is that if you expect GPG to be able to fix a broken key, you need to pass back all the data, or GPG has nothing to work from. If you are stating that in every case of this corruption that the bad packets always exist in at least two places, and at least one of these is in the correct place, then why are we having this discussion? Drop the packets and be done with it. David From dkg at fifthhorseman.net Wed Aug 1 19:29:21 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 01 Aug 2012 13:29:21 -0400 Subject: dealing with misplaced signatures In-Reply-To: <862572A7-CF93-466F-8F30-CE7258944A08@jabberwocky.com> References: <50170AE0.9070601@fifthhorseman.net> <20120731053957.GA2691@sivokote.iziade.m$> <5017F611.4030300@fifthhorseman.net> <9E8D7E34-4A6A-4E21-BE3C-4084BA5F3773@jabberwocky.com> <50185657.5010107@sumptuouscapital.com> <2D78BAEB-03E6-4AE7-ACA6-5B2A3B82CB34@jabberwocky.com> <50195A61.8030900@fifthhorseman.net> <862572A7-CF93-466F-8F30-CE7258944A08@jabberwocky.com> Message-ID: <50196771.6050803@fifthhorseman.net> On 08/01/2012 01:12 PM, David Shaw wrote: > My point is that if you expect GPG to be able to fix a broken key, you need to pass back all the data, or GPG has nothing to work from. well, you could expect the GPG of the original uploader to fix the broken key before uploading it. Then the keyservers wouldn't have to store and return obviously-incorrect data. > If you are stating that in every case of this corruption that the bad packets always exist in at least two places, and at least one of these is in the correct place, every case i've seen, yes. i don't know if that's a true universal, though, or if it will be one going into the future. But i think it's not relevant, if we consider it the job of the uploader to present a well-formed public certificate package to the keyservers. > then why are we having this discussion? Drop the packets and be done with it. my sentiments exactly. :) --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Wed Aug 1 19:42:46 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 1 Aug 2012 13:42:46 -0400 Subject: dealing with misplaced signatures In-Reply-To: <50196771.6050803@fifthhorseman.net> References: <50170AE0.9070601@fifthhorseman.net> <20120731053957.GA2691@sivokote.iziade.m$> <5017F611.4030300@fifthhorseman.net> <9E8D7E34-4A6A-4E21-BE3C-4084BA5F3773@jabberwocky.com> <50185657.5010107@sumptuouscapital.com> <2D78BAEB-03E6-4AE7-ACA6-5B2A3B82CB34@jabberwocky.com> <50195A61.8030900@fifthhorseman.net> <862572A7-CF93-466F-8F30-CE7258944A08@jabberwocky.com> <50196771.6050803@fifthhorseman.net> Message-ID: <92E305C5-2F5B-4180-85CE-AC646563B3FA@jabberwocky.com> On Aug 1, 2012, at 1:29 PM, Daniel Kahn Gillmor wrote: > On 08/01/2012 01:12 PM, David Shaw wrote: >> My point is that if you expect GPG to be able to fix a broken key, you need to pass back all the data, or GPG has nothing to work from. > > well, you could expect the GPG of the original uploader to fix the > broken key before uploading it. Then the keyservers wouldn't have to > store and return obviously-incorrect data. It's an interesting question, as we don't really know how this corruption happened in the first place. We can't presume that the original uploader necessarily uploaded a corrupt key. Especially if the original uploader is the person who generated the key, it's rather hard to imagine the key was corrupt before it was uploaded. David From dkg at fifthhorseman.net Fri Aug 3 06:39:04 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 03 Aug 2012 00:39:04 -0400 Subject: mistaken comment in g10/sign.c refers to --preferred-digest-prefs, should be --personal-digest-prefs Message-ID: <87zk6cwpw7.fsf@pip.fifthhorseman.net> the attached patch corrects a comment describing hash_for() in g10/sign.c. the comment refers to --preferred-digest-prefs, but it appears to mean --personal-digest-prefs. hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: fix-comment-for-hash-choice.patch Type: text/x-diff Size: 904 bytes Desc: fix comment URL: From abel at guardianproject.info Fri Aug 3 18:19:22 2012 From: abel at guardianproject.info (Abel Luck) Date: Fri, 03 Aug 2012 16:19:22 +0000 Subject: [guardian-dev] Format of exported subkeys from gnupg In-Reply-To: References: <50085CAC.3040605@guardianproject.info> Message-ID: <501BFA0A.5090603@guardianproject.info> Tom Ritter: > I think what you're looking for is the OpenPGP specification. That > should allow you to create an ASCII-armored or binary representation > of the data to import into GPG, and tells you the format that GPG > outputs. http://tools.ietf.org/html/rfc4880#section-5.5.3 Fortunetly, > it's much easier than working with S-Expressions (IMO at least.) So, I've dived into parsing OpenPGP packets as per the spec, and all is well, until I get to parsing the actual secret key data (the MPI values). In 99% of cases these secret values are encrypted. As I see it these are my options for getting at the unencrypted values. 1. Implement all possible ciphers in my library, ask the user for their key and decrypt 2. Only support plaintext exported keys, decryption is handled by GnuPG during export. The first will require implementation of the entire pgp cipher suite, which is beyond our calling. The second will leak unprotected secret key data to disk. Remember, the use case for this is exporting secret-subkeys used as OTR keys for interoperability with OTR clients. Most (all?) OTR apps store the private OTR key material unencrypted anyways, so leaking this data to disk is not an issue. (Though, yes later on, I'll be pushing the line over on otr-dev that we need to start encrypting the private keys) Thus the question is: how can I --export-secret-subkeys with unprotected/plaintext secret key values? ~abel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Fri Aug 3 18:34:15 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 03 Aug 2012 12:34:15 -0400 Subject: [guardian-dev] Format of exported subkeys from gnupg In-Reply-To: <501BFA0A.5090603@guardianproject.info> References: <50085CAC.3040605@guardianproject.info> <501BFA0A.5090603@guardianproject.info> Message-ID: <501BFD87.30901@fifthhorseman.net> On 08/03/2012 12:19 PM, Abel Luck wrote: > 1. Implement all possible ciphers in my library, ask the user for their > key and decrypt please don't re-implement the ciphers. there are plenty of libraries that do that for you :) If you're using C, libgcrypt and libnettle are both good options. > 2. Only support plaintext exported keys, decryption is handled by GnuPG > during export. this is simpler, true. :) > Thus the question is: how can I --export-secret-subkeys with > unprotected/plaintext secret key values? i think you want something like: --export-options export-reset-subkey-passwd,export-minimal hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From hans at guardianproject.info Fri Aug 3 19:08:41 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 03 Aug 2012 13:08:41 -0400 Subject: [guardian-dev] Format of exported subkeys from gnupg In-Reply-To: <501BFD87.30901@fifthhorseman.net> References: <50085CAC.3040605@guardianproject.info> <501BFA0A.5090603@guardianproject.info> <501BFD87.30901@fifthhorseman.net> Message-ID: <501C0599.8070703@guardianproject.info> On 08/03/2012 12:34 PM, Daniel Kahn Gillmor wrote: > On 08/03/2012 12:19 PM, Abel Luck wrote: >> 1. Implement all possible ciphers in my library, ask the user for their >> key and decrypt > > please don't re-implement the ciphers. there are plenty of libraries > that do that for you :) If you're using C, libgcrypt and libnettle are > both good options. > >> 2. Only support plaintext exported keys, decryption is handled by GnuPG >> during export. > > this is simpler, true. :) > >> Thus the question is: how can I --export-secret-subkeys with >> unprotected/plaintext secret key values? > > i think you want something like: > > --export-options export-reset-subkey-passwd,export-minimal Since we are talking about just exporting subkeys, I think using the plaintext export should be workable as long as gpg can export to stdout. Then we can just receive the unencrypted private key via stdin and it'll never touch the disk. .hc From dkg at fifthhorseman.net Fri Aug 3 19:12:10 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 03 Aug 2012 13:12:10 -0400 Subject: [guardian-dev] Format of exported subkeys from gnupg In-Reply-To: <501C0599.8070703@guardianproject.info> References: <50085CAC.3040605@guardianproject.info> <501BFA0A.5090603@guardianproject.info> <501BFD87.30901@fifthhorseman.net> <501C0599.8070703@guardianproject.info> Message-ID: <501C066A.3090309@fifthhorseman.net> On 08/03/2012 01:08 PM, Hans-Christoph Steiner wrote: > Since we are talking about just exporting subkeys, I think using the > plaintext export should be workable as long as gpg can export to stdout. > Then we can just receive the unencrypted private key via stdin and > it'll never touch the disk. You might be interested in the jiggery-pokery that monkeysphere subkey-to-ssh-agent does to make sure this happens. it's a pretty similar use case. If you have monkeysphere installed, take a look at /usr/share/monkeysphere/m/subkey_to_ssh_agent hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From abel at guardianproject.info Fri Aug 3 19:28:16 2012 From: abel at guardianproject.info (Abel Luck) Date: Fri, 03 Aug 2012 17:28:16 +0000 Subject: [guardian-dev] Format of exported subkeys from gnupg In-Reply-To: <501BFD87.30901@fifthhorseman.net> References: <50085CAC.3040605@guardianproject.info> <501BFA0A.5090603@guardianproject.info> <501BFD87.30901@fifthhorseman.net> Message-ID: <501C0A30.9070000@guardianproject.info> Daniel Kahn Gillmor: > On 08/03/2012 12:19 PM, Abel Luck wrote: >> 1. Implement all possible ciphers in my library, ask the user for their >> key and decrypt > > please don't re-implement the ciphers. there are plenty of libraries > that do that for you :) If you're using C, libgcrypt and libnettle are > both good options. Of course I didn't mean re-implement the ciphers themselves, sorry I was unclear. I meant "implement them" by pulling in other libraries as you suggested. :D >> 2. Only support plaintext exported keys, decryption is handled by GnuPG >> during export. > > this is simpler, true. :) > >> Thus the question is: how can I --export-secret-subkeys with >> unprotected/plaintext secret key values? > > i think you want something like: > > --export-options export-reset-subkey-passwd,export-minimal Perfect :) Thanks for this dkg. I'm 95% of the way there now. ~abel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: OpenPGP digital signature URL: From reven1280 at gmail.com Sat Aug 4 03:34:48 2012 From: reven1280 at gmail.com (tom m) Date: Sat, 4 Aug 2012 03:34:48 +0200 Subject: No subject Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at tgries.de Sun Aug 5 00:02:32 2012 From: mail at tgries.de (Thomas Gries) Date: Sun, 05 Aug 2012 00:02:32 +0200 Subject: after successful compilation: how to install safely in a test environment parallet to existing production version Message-ID: <501D9BF8.6090900@tgries.de> After having successfully compiled the GPG developer version (configure.., make), I did *not* make install I found gpg2 in the subdirectory /g10/gpg2 of the compiled sources gpg2 -c foo.txt NOTE: THIS IS A DEVELOPMENT VERSION ... /usr/local/bin/gpg-agent: probably not installed Question: ======= Is there a way for a safe installation (and later deinstallation) of the developer version and tools like gpg-agent */ in parallel to the existing gpg installation on that server ? /* If yes, how ? Can please add such information to your documentation or Wiki? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From christian at quelltextlich.at Sun Aug 5 12:54:42 2012 From: christian at quelltextlich.at (Christian Aistleitner) Date: Sun, 5 Aug 2012 12:54:42 +0200 Subject: after successful compilation: how to install safely in a test environment parallet to existing production version In-Reply-To: <501D9BF8.6090900@tgries.de> References: <501D9BF8.6090900@tgries.de> Message-ID: <20120805105442.GA9336@quelltextlich.at> Hi Thomas, On Sun, Aug 05, 2012 at 12:02:32AM +0200, Thomas Gries wrote: > Is there a way for a safe installation (and later deinstallation) > of the developer version and tools like gpg-agent > */ > in parallel to the existing gpg installation on that server ? > /* > If yes, how ? Yes, it's easily possible. Autotools to the rescue :-) As with any autotools package (GnuPG etc are such packages), the --prefix option does what you want. Here's what I did on a GNU/Linux system. I configured the git head of GnuPG using ./configure [...] --prefix=/home/christian/gnupg-prefix [...] Afterwards build GnuPG. Upon "make install" the files get installed into the prefix directory, which resolves to subdirectories of /home/christian/gnupg-prefix in the above example. So for example the gpg2 binary can be found in /home/christian/gnupg-prefix/bin/gpg2. So on my system, I have the distribution provided GnuPG in /usr/bin/gpg2, and the git head's build in /home/christian/gnupg-prefix/bin/gpg2. My email client still uses /usr/bin/gpg2. For experiments with the git head's build, I prepend /home/christian/gnupg-prefix/bin to the path in a shell. Then within this shell, gpg2 refers to the git head's gpg2. Thereby you can use both variants in parallel, choose within the shell which variant you want to use, while the mail client still uses the distribution provided, known good gpg2. But be aware of which gpg-agent etc you are using for which gpg2 :-) As for uninstalling, just issue "make uninstall" in the directory, where you issued "make install" in (Without un- or reconfiguring within this directory). If you used the --prefix option during configuration, "make uninstall" will only remove the files it installed in the prefix directory. Now for the fun part, as the above only treats GnuPG itself and does not yet cover libraries. You probably also want to use git head's libassuan etc. In this case, use the --prefix option for all the packages installed by hand. But be aware that when installing libassuan in a prefix directory, linking gnupg need not pick the prefix version automatically. Therefore, GnuPG comes with additional --with-libassuan-prefix and --with-npth-prefix options. Those options allow you to specify which libassuan, ... you want GnuPG to link against. So you could decouple the prefixes of all used libraries into separate directories, or throw all the libraries related to GnuPG's git head into the same prefix. The latter is what I chose, as it makes setting up the dynamic linker easier. Depending how you choose to link GnuPG, you might end up with a git's head gpg2 trying to (at runtime) use the libassuan provided by your distribution. You can check using the ldd utility. For example: ldd /home/christian/gnupg-prefix/bin/gpg2 [...] libassuan.so.0 => /usr/lib64/libassuan.so.0 [...] [...] Note that libassuan.so.0 would be met by /usr/lib64/libassuan.so.0, which is not the prefixed variant. So let's set LD_LIBRARY_PATH in the shell that should get used for the GnuPG's git head: export LD_LIBRARY_PATH="/home/christian/gnupg-prefix/lib:$LD_LIBRARY_PATH" and check again ldd /home/christian/gnupg-prefix/bin/gpg2 [...] libassuan.so.0 => /home/christian/gnupg-prefix/lib/libassuan.so.0 [...] [...] Now, git's head libassuan get's used as well. So finally you have two parallel, completely decoupled installs of GnuPG: 1. The one coming straight from your GNU/Linux distribution, and 2. Git's head build. Both of them are usable. In a fresh, unmodified environment, you'll just use the distribution provided variant. If you want to use the git's head variant, just set the PATH and LD_LIBRARY_PATH environment (and take care of gpg-agent ;) ) and you're using git's head GnuPG in this shell. Be aware, that there are other options as well that you may want to setup, to get a more hassle free dual GnuPG setup: E.g.: --with-agent-pgm or --with-pinentry-pgm To get a list of available options along with a description, use the "--help" parameter of the ./configure script of each of the packages. All the best, Christian P.S.: As for the problem > I found gpg2 in the subdirectory /g10/gpg2 of the compiled sources > [...] > /usr/local/bin/gpg-agent: probably not installed This hints towards the fact that you did not set a prefix when running configure (Running ./configure by hand without any prefix option typically defaults to a prefix of '/usr/local') and that you did not install your compiled variant, which is fair enough. If you want to avoid to install on your machine (Note however, that the above description works without requiring administrative access on typical distribution settings. So you can work as plain user and install under your home directory, to avoid shooting yourself in the foot), the gpg-agent executable is in the "agent" subdirectory of your git checkout (after compiling GnuPG that is). -- ---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ---- Companies' registry: 360296y in Linz Christian Aistleitner Gruendbergstrasze 65a Email: christian at quelltextlich.at 4040 Linz, Austria Phone: +43 732 / 26 95 63 Fax: +43 732 / 26 95 63 Homepage: http://quelltextlich.at/ --------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From taffit at debian.org Mon Aug 6 19:55:45 2012 From: taffit at debian.org (=?UTF-8?B?RGF2aWQgUHLDqXZvdA==?=) Date: Mon, 06 Aug 2012 13:55:45 -0400 Subject: [STABLE-BRANCH-1-4 PATCHES] translation related helper, and a few typos Message-ID: <50200521.5030302@debian.org> Hi, As agreed with Ga?l Qu?ri, the former translator, I'm updating the French translation of gnupg. I began to review and update the 1.4 branch, and have a few remarks and questions: [PATCH 1/3] In order to help translators to update their files, using the --previous option of msgmerge would be highly welcome. [PATCH 2/3] A few translators notes didn't show up in the PO files. [PATCH 3/3] Three minor typos spotted during the translation update and review. It would be nice to take care of the trivial unfuzzy when updating the PO files after the typo fix (even if the first patch will minimize the headache to translators), I can provide you a patch for that too if you wish. The first patch applies cleanly in the STABLE-BRANCH-2-0, the second one needs some tweaks in scd/app-openpgp.c (I can send you the commit too), and the third one is not needed (strings have disappeared). Is it OK to send you patches attached to this list like I did, or do you prefer a real ?git send-email? stuff, maybe elsewhere? Where should I send the updated PO files ( looks inactive), and what is the preferred form (compressed PO file or git commit)? Ga?l also asked me to make sure that messages can be displayed in an 80 colons terminal, but some have variable length (due to %s that can be as long as user ID), and some strings are displayed after ?gpg:? (by the way, would it be possible to change this string, depending on the localization?), so do you have a test suite or some advice to make sure I didn't go off limits? Regards David -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Keep-previous-msgids-of-translated-messages.patch Type: text/x-diff Size: 802 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Actually-show-translators-comments-in-PO-files.patch Type: text/x-diff Size: 3187 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Fix-typos-spotted-during-translations.patch Type: text/x-diff Size: 1454 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From Jason at zx2c4.com Wed Aug 8 04:17:21 2012 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Wed, 8 Aug 2012 04:17:21 +0200 Subject: ecdsa in ssh agent emulation Message-ID: Hi all, With GPG now supporting ECC, is it possible to add support to the SSH agent emulation in gpg-agent for ecdsa SSH keys? A quick google search reveals a number of folks who would really enjoy having this. Specifically, I'm referring to adding an entry and encoder functions here [1] for ecdsa-sha2-nistp521 and friends. Thanks, Jason Donenfeld [1] http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=agent/command-ssh.c;h=ddf8e2cf65f2b1fea95f4344d4df834bfe1adf37;hb=HEAD#l220 From wk at gnupg.org Wed Aug 8 06:36:51 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 08 Aug 2012 06:36:51 +0200 Subject: [Announce] GPA 0.9.3 released Message-ID: <87obmmuhi4.fsf@vigenere.g10code.de> Hello, We are pleased to announce the release of GPA 0.9.3. GPA is a graphical frontend for the GNU Privacy Guard (GnuPG, http://www.gnupg.org). GPA can be used to encrypt, decrypt, and sign files, to verify signatures and to manage the private and public keys. You can find the release here: ftp://ftp.gnupg.org/gcrypt/gpa/gpa-0.9.3.tar.bz2 (695k) ftp://ftp.gnupg.org/gcrypt/gpa/gpa-0.9.3.tar.bz2.sig and soon on all gnupg.org mirrors. The SHA1 checksum for this release is: 8dc810e465ec49cd8353d93b3ede8e69ad3cf48b gpa-0.9.3.tar.bz2 Noteworthy changes in version 0.9.3 (2012-08-08) ------------------------------------------------ * Allow searching in the keylist. * Collected bug fixes. Noteworthy changes in version 0.9.2 (2012-05-02) ------------------------------------------------ * Adjust server mode to modern Libassuan. * Add options --enable-logging for W32. * Add options --gpg-binary, --gpgsm-binary and --debug-edit-fsm. * Properly process CMS data in the clipboard and with the server's VERIFY_FILES and DECRYPT_FILES commands. * Minor code cleanups. Noteworthy changes in version 0.9.1 (2012-04-18) ------------------------------------------------ * The key selection dialogs for encryption and signing do not anymore list expired, revoked or otherwise invalid keys. * If no recipients are given to the server, a generic key selection dialog is now used. * Now works with Libassuan 2.x. * The card manager now displays the ATR for an unknown card. Shalom-Salam, Werner -- g10 Code GmbH http://g10code.com AmtsGer. Wuppertal HRB 14459 H?ttenstr. 61 Gesch?ftsf?hrung Werner Koch D-40699 Erkrath -=- The GnuPG Experts -=- USt-Id DE215605608 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 203 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 Wed Aug 8 07:18:21 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 08 Aug 2012 07:18:21 +0200 Subject: ecdsa in ssh agent emulation In-Reply-To: (Jason A. Donenfeld's message of "Wed, 8 Aug 2012 04:17:21 +0200") References: Message-ID: <878vdqufky.fsf@vigenere.g10code.de> On Wed, 8 Aug 2012 04:17, Jason at zx2c4.com said: > With GPG now supporting ECC, is it possible to add support to the SSH > agent emulation in gpg-agent for ecdsa SSH keys? A quick google search > reveals a number of folks who would really enjoy having this. I have this in the works. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Aug 8 07:15:05 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 08 Aug 2012 07:15:05 +0200 Subject: [Announce] nPth 0.91 released Message-ID: <87k3xaufqe.fsf@vigenere.g10code.de> Hi! We are pleased to announce the second official release of the New GNU Portable Threads Library: nPth version 0.91. nPth is a non-preemptive threads implementation using an API very similar to the one known from GNU Pth. It has been designed as a replacement of GNU Pth for non-ancient operating systems. In contrast to GNU Pth is is based on the system's standard threads implementation. Thus nPth allows the use of libraries which are not compatible to GNU Pth. What's New in 0.91 ================== * Fixed a flaw in the initialization code. * npth_init does now return an error on failure. * Various fixes for better portability. * Provide a pselect emulation for OpenBSD et al. Getting the Software ==================== The nPth tarball and its signature are available as ftp://ftp.gnupg.org/gcrypt/npth/npth-0.91.tar.bz2 (293k) ftp://ftp.gnupg.org/gcrypt/npth/npth-0.91.tar.bz2.sig and at all GnuPG mirrors. See the included README file and the npth.h header for documentation. Bug reports and requests for help should be send to the gnupg-devel mailing list at gnupg.org. nPth is available under the terms of the LGPLv3+ or the GPLv2+. The GIT repository is at git://git.gnupg.org/npth.git . Background ========== GNU Pth is often used to provide a co-routine based framework. GnuPG-2 makes heavy use of this concept for good audibility, general security concerns, and ease of implementation. However, GNU Pth has the drawback that ugly hacks are required to work with libraries which are not GNU Pth aware. When porting GnuPG-2 to Windows in 2004, we had the need for a replacement of GNU Pth, which is not available for native Windows. We came up with an emulation based on the native Windows thread system. Experience since then showed that such an emulation is a solid way to provide a co-routine based framework. Given that thread implementations (in particular pthreads) are now in common use on all platforms, there is not must justification left for not using them: Without considering the GnuPG packages, Debian has only two packages requiring GNU Pth (zhcon and jabberd14 - the latter even seems not in wide use anymore). Thus we decided to write nPth as a replacement for GNU Pth. The current development version of GnuPG (2.1) has been migrated to nPth and the the next beta release will require it. On common Linux and kFreeBSD based systems and even on Android, nPth should build and work fine. Support ======= Please consult the archive of the gnupg-users mailing list before reporting a bug . As of now we suggest to send bug reports for a nPth to this list in favor of filing a bug at . We also have a dedicated service directory at: http://www.gnupg.org/service.html Maintaining and improving GnuPG and related software is costly. For more than a decade, g10 Code, a German company owned and headed by GnuPG's principal author Werner Koch, is bearing the majority of these costs. To help them carry on this work, we need your support. Please consider to visit the GnuPG donation page at: http://g10code.com/gnupg-donation.html Thanks ====== Many thanks to Ralf S. Engelschall for his excellent GNU PTH library, which served GnuPG very well for many years. Thanks also to Nelson H. F. Beebe would provided useful portability hints for this release. Happy hacking, Marcus and Werner -- g10 Code GmbH http://g10code.com AmtsGer. Wuppertal HRB 14459 H?ttenstr. 61 Gesch?ftsf?hrung Werner Koch D-40699 Erkrath -=- The GnuPG Experts -=- USt-Id DE215605608 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 203 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 gdt at ir.bbn.com Wed Aug 8 13:39:08 2012 From: gdt at ir.bbn.com (Greg Troxel) Date: Wed, 08 Aug 2012 07:39:08 -0400 Subject: [Announce] nPth 0.91 released In-Reply-To: <87k3xaufqe.fsf@vigenere.g10code.de> (Werner Koch's message of "Wed, 08 Aug 2012 07:15:05 +0200") References: <87k3xaufqe.fsf@vigenere.g10code.de> Message-ID: nPth is a non-preemptive threads implementation using an API very similar to the one known from GNU Pth. It has been designed as a replacement of GNU Pth for non-ancient operating systems. In contrast to GNU Pth is is based on the system's standard threads implementation. Thus nPth allows the use of libraries which are not compatible to GNU Pth. Is the rationale for nPth instead of just using posix threads that posix threads are not supported on some operating systems of interest, or that preemptive threads are to hard to understand (I'd agree), and thus nPth is really a non-preemption wrapper around posix threads, or both? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From wk at gnupg.org Wed Aug 8 17:03:32 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 08 Aug 2012 17:03:32 +0200 Subject: [Announce] nPth 0.91 released In-Reply-To: (Greg Troxel's message of "Wed, 08 Aug 2012 07:39:08 -0400") References: <87k3xaufqe.fsf@vigenere.g10code.de> Message-ID: <87pq71s9x7.fsf@vigenere.g10code.de> On Wed, 8 Aug 2012 13:39, gdt at ir.bbn.com said: > Is the rationale for nPth instead of just using posix threads that posix > threads are not supported on some operating systems of interest, or that > preemptive threads are to hard to understand (I'd agree), and thus nPth The latter. They are hard to use correctly and it is even harder to debug them. I consider any deep security audit of multithreaded code impossible. Using a non-preemptive wrapper gives you at least a chance to do an audit. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From fra-87 at teletu.it Fri Aug 10 19:16:15 2012 From: fra-87 at teletu.it (Fra) Date: Fri, 10 Aug 2012 19:16:15 +0200 Subject: Problem with GnuPG 2.1.0 beta 3: Not enough space on Windows 7 Message-ID: <502541DF.2070505@teletu.it> Hi I want to report a strange behaviour. I have a problem running GnuPG 2.1.0 beta 3 on Windows 7. Whenever I try to use a secret key the program says "Not enough space". i tried both the creation and the decryption without success. This, however, happens only on Windows 7. If i try to use the same binary on VirtualBox (on the same machine) running Windows XP everything goes well. I built GnuPG 2.1.0 beta 3 with mingw cross compiler. Since it is my first compilation on Linux i want to show you the bash file i used to compile everything (look at the end of the message). Before compilation i edited two things to the source code downloaded from the internet: 1) copied zlib-1.2.7\win32\Makefile.gcc into zlib-1.2.7\win32\Makefile.mingw and put PREFIX = i586-mingw32msvc- (in order to use mingw cross compiler); 2) edited gnupg dirmngr\ks-engine-hkp.c putting, at the beginning, the line "#define WINVER 0x501" (otherwise the getaddrinfo and getnameinfo are not defined). After the compilation if i generate the keys in Win7 it asks for the pin and then says: gpg: signing failed: Not enough space gpg: make_keysig_packet failed: Not enough space Key generation failed: Not enough space if i generate it in WinXP and then copy the folder %appdata%\gnupg to Win7 then the latter recognizes the keys, but if i try to decrypt something using them i receive gpg: public key decryption failed: Not enough space gpg: decryption failed: No secret key What do you think it can be? Here is the bash script i used to build everything: #!/bin/bash INSTALLDIR=~/w32root/ cd libgpg-error-1.10 ; ./autogen.sh; ./autogen.sh --build-w32; make || exit 1; make install; cd .. cd libassuan-2.0.3 ; ./autogen.sh; ./autogen.sh --build-w32; make || exit 1; make install; cd .. cd libksba-1.2.0 ; ./autogen.sh; ./autogen.sh --build-w32; make || exit 1 ; make install; cd .. cd libgcrypt-1.5.0 ; ./autogen.sh ; ./autogen.sh --build-w32; make || exit 1 ; make install; cd .. cd w32pth-2.0.4 ; ./autogen.sh --build-w32; make || exit 1 ; make install; cd .. cd zlib-1.2.7 ; make -f win32/Makefile.mingw || exit 1; cp -fp zlib1.dll $INSTALLDIR/bin; cp -fp libz.a libz.dll.a $INSTALLDIR/lib; cp -fp zconf.h zlib.h $INSTALLDIR/include; cd .. cd pinentry-0.8.2 ; ./autogen.sh ; ./autogen.sh --build-w32; make || exit 1; make install; mv $INSTALLDIR/bin/pinentry-w32.exe $INSTALLDIR/bin/pinentry.exe; cd .. cd gnupg-2.1.0beta3 ; ./autogen.sh ; ./autogen.sh --build-w32; make || exit 1 ; make install; cd .. From ekleog at gmail.com Mon Aug 13 17:07:05 2012 From: ekleog at gmail.com (Leo Gaspard) Date: Mon, 13 Aug 2012 17:07:05 +0200 Subject: gpgme_data_seek with SEEK_END on memory-based data fails In-Reply-To: <87y5m16wng.fsf@vigenere.g10code.de> References: <501434CA.3090208@gmail.com> <501447BF.1070005@ruhr-uni-bochum.de> <50145736.3040109@gmail.com> <87lii29a5o.fsf@vigenere.g10code.de> <50158011.1080201@gmail.com> <87d33d8vtf.fsf@vigenere.g10code.de> <50166515.4020701@gmail.com> <87y5m16wng.fsf@vigenere.g10code.de> Message-ID: <50291819.30601@gmail.com> First of all, sorry for having been late answering. On 30/07/2012 18:28, Werner Koch wrote: > On Mon, 30 Jul 2012 12:42, ekleog at gmail.com said: > >> So, I suppose the patch I sent on the mailing list yesterday doesn't work ? > > I have not said this ;-). I have two problems with the patch: > > - It is very specific for keyservers and not a general way to describe, > well, what keyservers are. We already have ways to locate keys from > remote resources. See the GPGME_KEYLIST_MODE_* flags. This needs to > be unified with other uses of the keys. And it also needs to be in > line with planned or already done changes in 2.1. Yes, I saw GPGME_KEYLIST_MODE_* flags. But there are no way of selecting the keyserver to use directly from GPGME. So the only way would be to modify gpg.conf before each operation ? That's why I thought a keyserver (i.e. the server with which to interact, maybe another name could be better ? I used OpenPGP name, because I don't know GPGSM enough yet.) setting could be useful. > - You break the ABI and API with your patch - this is not acceptable > for a stable library. I thought quite a bit about this, and didn't find out in which way. Summarizing the changes : * context.h : Added a keyserver variable to struct gpgme_context. As the structure is fully opaque from the library user, I don't think it breaks any API. (except maybe the internal one ?) And, as it is referred from "user" code only through pointers, there is no ABI breakage, right ? * engine-backend.h ; engine-gpg.h ; engine-gpg.c ; engine-gpgsm.c ; engine.c ; engine.h ; export.c ; keylist.c : Some small API change, but it's only on internal functions, it's not an issue, is it ? * gpgme.c : The only externally-visible API change : adding gpgme_set|get_keyserver. The objective of the patch Am I wrong ? Cheers, Leo From hans at guardianproject.info Wed Aug 15 23:38:57 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Wed, 15 Aug 2012 17:38:57 -0400 Subject: building gpgme for Android dies on install Message-ID: <502C16F1.4030900@guardianproject.info> Hey all, I'm back at it, this time trying to get gpgme and gnupg-for-java all working on Android. gpgme is quite close, there seems to be only an error on the install. I'm building 1.3.2 using the Android NDK r8b. The good news is that I no longer need to patch gpgme to build it, nor update config.guess and config.sub. Thanks! :) You can see the ./configure flags used here, and indeed the whole build setup: https://github.com/guardianproject/gnupg-for-android/blob/master/external/Makefile#L557 Now for the install error (I've never heard of a .lai file...). Its trying to install libgpgme.lai as libgpgme.la, but libgpgme.lai doesn't exist. src/libgpgme.la does tho. Here's the full log: $ make -C gpgme DESTDIR=/media/share/code/guardianproject/gnupg-for-android/external/../external prefix=/data/data/info.guardianproject.gpg/app_opt install make: Entering directory `/media/share/code/guardianproject/gnupg-for-android/external/gpgme' Making install in src make[1]: Entering directory `/media/share/code/guardianproject/gnupg-for-android/external/gpgme/src' make[2]: Entering directory `/media/share/code/guardianproject/gnupg-for-android/external/gpgme/src' test -z "/data/data/info.guardianproject.gpg/app_opt/bin" || /bin/mkdir -p "/media/share/code/guardianproject/gnupg-for-android/external/../external/data/data/info.guardianproject.gpg/app_opt/bin" /usr/bin/install -c gpgme-config '/media/share/code/guardianproject/gnupg-for-android/external/../external/data/data/info.guardianproject.gpg/app_opt/bin' test -z "/data/data/info.guardianproject.gpg/app_opt/lib" || /bin/mkdir -p "/media/share/code/guardianproject/gnupg-for-android/external/../external/data/data/info.guardianproject.gpg/app_opt/lib" /bin/bash ../libtool --mode=install /usr/bin/install -c libgpgme.la '/media/share/code/guardianproject/gnupg-for-android/external/../external/data/data/info.guardianproject.gpg/app_opt/lib' libtool: install: /usr/bin/install -c .libs/libgpgme.so.11.8.1 /media/share/code/guardianproject/gnupg-for-android/external/../external/data/data/info.guardianproject.gpg/app_opt/lib/libgpgme.so.11.8.1 libtool: install: (cd /media/share/code/guardianproject/gnupg-for-android/external/../external/data/data/info.guardianproject.gpg/app_opt/lib && { ln -s -f libgpgme.so.11.8.1 libgpgme.so.11 || { rm -f libgpgme.so.11 && ln -s libgpgme.so.11.8.1 libgpgme.so.11; }; }) libtool: install: (cd /media/share/code/guardianproject/gnupg-for-android/external/../external/data/data/info.guardianproject.gpg/app_opt/lib && { ln -s -f libgpgme.so.11.8.1 libgpgme.so || { rm -f libgpgme.so && ln -s libgpgme.so.11.8.1 libgpgme.so; }; }) libtool: install: /usr/bin/install -c .libs/libgpgme.lai /media/share/code/guardianproject/gnupg-for-android/external/../external/data/data/info.guardianproject.gpg/app_opt/lib/libgpgme.la /usr/bin/install: cannot stat `.libs/libgpgme.lai': No such file or directory make[2]: *** [install-libLTLIBRARIES] Error 1 make[2]: Leaving directory `/media/share/code/guardianproject/gnupg-for-android/external/gpgme/src' make[1]: *** [install-am] Error 2 make[1]: Leaving directory `/media/share/code/guardianproject/gnupg-for-android/external/gpgme/src' make: *** [install-recursive] Error 1 make: Leaving directory `/media/share/code/guardianproject/gnupg-for-android/external/gpgme' From hans at guardianproject.info Thu Aug 16 02:48:21 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Wed, 15 Aug 2012 20:48:21 -0400 Subject: building gpgme for Android dies on install In-Reply-To: <502C16F1.4030900@guardianproject.info> References: <502C16F1.4030900@guardianproject.info> Message-ID: <502C4355.9030804@guardianproject.info> I found a clue. It seems that the first time when running the gpgme-install, it fails with a different error, then every time after, it gives the error below. Here's the first time error: /bin/sed: can't read /data/data/info.guardianproject.gpg/app_opt/lib/libgpg-error.la: No such file or directory libtool: link: `/data/data/info.guardianproject.gpg/app_opt/lib/libgpg-error.la' is not a valid libtool archive make[3]: *** [libgpgme.la] Error 1 make[3]: Leaving directory `/media/share/code/guardianproject/gnupg-for-android/external/gpgme/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/media/share/code/guardianproject/gnupg-for-android/external/gpgme' make[1]: *** [all] Error 2 make[1]: Leaving directory `/media/share/code/guardianproject/gnupg-for-android/external/gpgme' And some relevant info: * since this is a cross-compile, the various libs like libgpg-error can't be meaningfully installed before compiling gpgme. So there is a sed hack to change the *-config scripts to point to the right things to get stuff building: sed -i 's|^prefix=$(prefix)|prefix=$(LOCAL)|' $(LOCAL)/bin/*-config * prefix=/data/data/info.guardianproject.gpg/app_opt * libgpg-error.la exists at $(DESTDIR)$(prefix)/lib/libgpg-error.la Still hunting around... I found a new debug trick which is helping: make SHELL="/bin/bash -vx" install .hc On 08/15/2012 05:38 PM, Hans-Christoph Steiner wrote: > > Hey all, > > I'm back at it, this time trying to get gpgme and gnupg-for-java all > working on Android. gpgme is quite close, there seems to be only an > error on the install. I'm building 1.3.2 using the Android NDK r8b. > > The good news is that I no longer need to patch gpgme to build it, nor > update config.guess and config.sub. Thanks! :) You can see the > ./configure flags used here, and indeed the whole build setup: > https://github.com/guardianproject/gnupg-for-android/blob/master/external/Makefile#L557 > > Now for the install error (I've never heard of a .lai file...). Its > trying to install libgpgme.lai as libgpgme.la, but libgpgme.lai doesn't > exist. src/libgpgme.la does tho. > > Here's the full log: > > $ make -C gpgme > DESTDIR=/media/share/code/guardianproject/gnupg-for-android/external/../external > prefix=/data/data/info.guardianproject.gpg/app_opt install > make: Entering directory > `/media/share/code/guardianproject/gnupg-for-android/external/gpgme' > Making install in src > make[1]: Entering directory > `/media/share/code/guardianproject/gnupg-for-android/external/gpgme/src' > make[2]: Entering directory > `/media/share/code/guardianproject/gnupg-for-android/external/gpgme/src' > test -z "/data/data/info.guardianproject.gpg/app_opt/bin" || /bin/mkdir > -p > "/media/share/code/guardianproject/gnupg-for-android/external/../external/data/data/info.guardianproject.gpg/app_opt/bin" > /usr/bin/install -c gpgme-config > '/media/share/code/guardianproject/gnupg-for-android/external/../external/data/data/info.guardianproject.gpg/app_opt/bin' > test -z "/data/data/info.guardianproject.gpg/app_opt/lib" || /bin/mkdir > -p > "/media/share/code/guardianproject/gnupg-for-android/external/../external/data/data/info.guardianproject.gpg/app_opt/lib" > /bin/bash ../libtool --mode=install /usr/bin/install -c libgpgme.la > '/media/share/code/guardianproject/gnupg-for-android/external/../external/data/data/info.guardianproject.gpg/app_opt/lib' > libtool: install: /usr/bin/install -c .libs/libgpgme.so.11.8.1 > /media/share/code/guardianproject/gnupg-for-android/external/../external/data/data/info.guardianproject.gpg/app_opt/lib/libgpgme.so.11.8.1 > libtool: install: (cd > /media/share/code/guardianproject/gnupg-for-android/external/../external/data/data/info.guardianproject.gpg/app_opt/lib > && { ln -s -f libgpgme.so.11.8.1 libgpgme.so.11 || { rm -f > libgpgme.so.11 && ln -s libgpgme.so.11.8.1 libgpgme.so.11; }; }) > libtool: install: (cd > /media/share/code/guardianproject/gnupg-for-android/external/../external/data/data/info.guardianproject.gpg/app_opt/lib > && { ln -s -f libgpgme.so.11.8.1 libgpgme.so || { rm -f libgpgme.so && > ln -s libgpgme.so.11.8.1 libgpgme.so; }; }) > libtool: install: /usr/bin/install -c .libs/libgpgme.lai > /media/share/code/guardianproject/gnupg-for-android/external/../external/data/data/info.guardianproject.gpg/app_opt/lib/libgpgme.la > /usr/bin/install: cannot stat `.libs/libgpgme.lai': No such file or > directory > make[2]: *** [install-libLTLIBRARIES] Error 1 > make[2]: Leaving directory > `/media/share/code/guardianproject/gnupg-for-android/external/gpgme/src' > make[1]: *** [install-am] Error 2 > make[1]: Leaving directory > `/media/share/code/guardianproject/gnupg-for-android/external/gpgme/src' > make: *** [install-recursive] Error 1 > make: Leaving directory > `/media/share/code/guardianproject/gnupg-for-android/external/gpgme' > From hans at guardianproject.info Thu Aug 16 03:35:25 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Wed, 15 Aug 2012 21:35:25 -0400 Subject: building gpgme for Android dies on install In-Reply-To: <502C4355.9030804@guardianproject.info> References: <502C16F1.4030900@guardianproject.info> <502C4355.9030804@guardianproject.info> Message-ID: <502C4E5D.3060402@guardianproject.info> I believe I found the source of the trouble. The various *-config scripts all return values based on the assumption that everything will be installed before being used. Since we're cross-compiling, that's not the case. So now I'm trying to force things by using sed to replace prefix= in the various *-config scripts, but I haven't find a good time in the process to do that, and a good pattern to guarantee the results needed... .hc On 08/15/2012 08:48 PM, Hans-Christoph Steiner wrote: > > I found a clue. It seems that the first time when running the > gpgme-install, it fails with a different error, then every time after, > it gives the error below. Here's the first time error: > > /bin/sed: can't read > /data/data/info.guardianproject.gpg/app_opt/lib/libgpg-error.la: No such > file or directory > libtool: link: > `/data/data/info.guardianproject.gpg/app_opt/lib/libgpg-error.la' is not > a valid libtool archive > make[3]: *** [libgpgme.la] Error 1 > make[3]: Leaving directory > `/media/share/code/guardianproject/gnupg-for-android/external/gpgme/src' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory > `/media/share/code/guardianproject/gnupg-for-android/external/gpgme' > make[1]: *** [all] Error 2 > make[1]: Leaving directory > `/media/share/code/guardianproject/gnupg-for-android/external/gpgme' > > And some relevant info: > > * since this is a cross-compile, the various libs like libgpg-error > can't be meaningfully installed before compiling gpgme. So there is > a sed hack to change the *-config scripts to point to the right > things to get stuff building: > > sed -i 's|^prefix=$(prefix)|prefix=$(LOCAL)|' $(LOCAL)/bin/*-config > > * prefix=/data/data/info.guardianproject.gpg/app_opt > > * libgpg-error.la exists at $(DESTDIR)$(prefix)/lib/libgpg-error.la > > Still hunting around... I found a new debug trick which is helping: > > make SHELL="/bin/bash -vx" install > > .hc > > On 08/15/2012 05:38 PM, Hans-Christoph Steiner wrote: >> >> Hey all, >> >> I'm back at it, this time trying to get gpgme and gnupg-for-java all >> working on Android. gpgme is quite close, there seems to be only an >> error on the install. I'm building 1.3.2 using the Android NDK r8b. >> >> The good news is that I no longer need to patch gpgme to build it, nor >> update config.guess and config.sub. Thanks! :) You can see the >> ./configure flags used here, and indeed the whole build setup: >> https://github.com/guardianproject/gnupg-for-android/blob/master/external/Makefile#L557 >> >> Now for the install error (I've never heard of a .lai file...). Its >> trying to install libgpgme.lai as libgpgme.la, but libgpgme.lai doesn't >> exist. src/libgpgme.la does tho. >> >> Here's the full log: >> >> $ make -C gpgme >> DESTDIR=/media/share/code/guardianproject/gnupg-for-android/external/../external >> prefix=/data/data/info.guardianproject.gpg/app_opt install >> make: Entering directory >> `/media/share/code/guardianproject/gnupg-for-android/external/gpgme' >> Making install in src >> make[1]: Entering directory >> `/media/share/code/guardianproject/gnupg-for-android/external/gpgme/src' >> make[2]: Entering directory >> `/media/share/code/guardianproject/gnupg-for-android/external/gpgme/src' >> test -z "/data/data/info.guardianproject.gpg/app_opt/bin" || /bin/mkdir >> -p >> "/media/share/code/guardianproject/gnupg-for-android/external/../external/data/data/info.guardianproject.gpg/app_opt/bin" >> /usr/bin/install -c gpgme-config >> '/media/share/code/guardianproject/gnupg-for-android/external/../external/data/data/info.guardianproject.gpg/app_opt/bin' >> test -z "/data/data/info.guardianproject.gpg/app_opt/lib" || /bin/mkdir >> -p >> "/media/share/code/guardianproject/gnupg-for-android/external/../external/data/data/info.guardianproject.gpg/app_opt/lib" >> /bin/bash ../libtool --mode=install /usr/bin/install -c libgpgme.la >> '/media/share/code/guardianproject/gnupg-for-android/external/../external/data/data/info.guardianproject.gpg/app_opt/lib' >> libtool: install: /usr/bin/install -c .libs/libgpgme.so.11.8.1 >> /media/share/code/guardianproject/gnupg-for-android/external/../external/data/data/info.guardianproject.gpg/app_opt/lib/libgpgme.so.11.8.1 >> libtool: install: (cd >> /media/share/code/guardianproject/gnupg-for-android/external/../external/data/data/info.guardianproject.gpg/app_opt/lib >> && { ln -s -f libgpgme.so.11.8.1 libgpgme.so.11 || { rm -f >> libgpgme.so.11 && ln -s libgpgme.so.11.8.1 libgpgme.so.11; }; }) >> libtool: install: (cd >> /media/share/code/guardianproject/gnupg-for-android/external/../external/data/data/info.guardianproject.gpg/app_opt/lib >> && { ln -s -f libgpgme.so.11.8.1 libgpgme.so || { rm -f libgpgme.so && >> ln -s libgpgme.so.11.8.1 libgpgme.so; }; }) >> libtool: install: /usr/bin/install -c .libs/libgpgme.lai >> /media/share/code/guardianproject/gnupg-for-android/external/../external/data/data/info.guardianproject.gpg/app_opt/lib/libgpgme.la >> /usr/bin/install: cannot stat `.libs/libgpgme.lai': No such file or >> directory >> make[2]: *** [install-libLTLIBRARIES] Error 1 >> make[2]: Leaving directory >> `/media/share/code/guardianproject/gnupg-for-android/external/gpgme/src' >> make[1]: *** [install-am] Error 2 >> make[1]: Leaving directory >> `/media/share/code/guardianproject/gnupg-for-android/external/gpgme/src' >> make: *** [install-recursive] Error 1 >> make: Leaving directory >> `/media/share/code/guardianproject/gnupg-for-android/external/gpgme' >> From wk at gnupg.org Thu Aug 16 09:16:52 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 16 Aug 2012 09:16:52 +0200 Subject: building gpgme for Android dies on install In-Reply-To: <502C4355.9030804@guardianproject.info> (Hans-Christoph Steiner's message of "Wed, 15 Aug 2012 20:48:21 -0400") References: <502C16F1.4030900@guardianproject.info> <502C4355.9030804@guardianproject.info> Message-ID: <87sjbni9wb.fsf@vigenere.g10code.de> On Thu, 16 Aug 2012 02:48, hans at guardianproject.info said: > * since this is a cross-compile, the various libs like libgpg-error > can't be meaningfully installed before compiling gpgme. So there is > a sed hack to change the *-config scripts to point to the right > things to get stuff building: That is not good. Install them please and provide the --with-foo-prefix options. Check how we do this in autogen.sh for Windows; Given that Android is a common platform, it makes sense to add support for it to autogen.sh. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From marcus.brinkmann at ruhr-uni-bochum.de Thu Aug 16 09:31:46 2012 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 16 Aug 2012 09:31:46 +0200 Subject: building gpgme for Android dies on install In-Reply-To: <502C4E5D.3060402@guardianproject.info> References: <502C16F1.4030900@guardianproject.info> <502C4355.9030804@guardianproject.info> <502C4E5D.3060402@guardianproject.info> Message-ID: <502CA1E2.8050903@ruhr-uni-bochum.de> On 08/16/2012 03:35 AM, Hans-Christoph Steiner wrote: > > I believe I found the source of the trouble. The various *-config > scripts all return values based on the assumption that everything will > be installed before being used. Since we're cross-compiling, that's not > the case. pkgconfig and its imitations (such as our config scripts) share this problem with libtool. > So now I'm trying to force things by using sed to replace prefix= in the > various *-config scripts, but I haven't find a good time in the process > to do that, and a good pattern to guarantee the results needed... Don't forget the .la files :) That's actually the canonical way to do it, I think (and yes, it's a PITA). For GPGME and friends, you can also just build and install for the cross-compilation build paths, and use the --with-gpg and --with-gpgsm etc. options to specify the hard-coded target file names of the crypto engines. The result is relocatable except for the .la and -config files, which need to be fixed up anyway. (So, if you want to develop on build and target, you absolutely need two copies of those files, no matter what you do). Thanks, Marcus From wk at gnupg.org Thu Aug 16 11:02:25 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 16 Aug 2012 11:02:25 +0200 Subject: building gpgme for Android dies on install In-Reply-To: <502CA1E2.8050903@ruhr-uni-bochum.de> (Marcus Brinkmann's message of "16 Aug 2012 09:31:46 +0200") References: <502C16F1.4030900@guardianproject.info> <502C4355.9030804@guardianproject.info> <502C4E5D.3060402@guardianproject.info> <502CA1E2.8050903@ruhr-uni-bochum.de> Message-ID: <87a9xvi50e.fsf@vigenere.g10code.de> On Thu, 16 Aug 2012 09:31, marcus.brinkmann at ruhr-uni-bochum.de said: > pkgconfig and its imitations (such as our config scripts) share this > problem with libtool. FWIW, last week we had a long discussion on it at gnu-prog-dicuss at gnu.org. Unfortunately that list is - for stupid reasons - secret and should only be known to GNU maintainers. Thus I fear any such discussion has to be repeated on a public list. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Thu Aug 16 20:36:39 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Thu, 16 Aug 2012 14:36:39 -0400 Subject: building gpgme for Android dies on install In-Reply-To: <502CA1E2.8050903@ruhr-uni-bochum.de> References: <502C16F1.4030900@guardianproject.info> <502C4355.9030804@guardianproject.info> <502C4E5D.3060402@guardianproject.info> <502CA1E2.8050903@ruhr-uni-bochum.de> Message-ID: <502D3DB7.2050201@guardianproject.info> On 08/16/2012 03:31 AM, Marcus Brinkmann wrote: > On 08/16/2012 03:35 AM, Hans-Christoph Steiner wrote: >> >> I believe I found the source of the trouble. The various *-config >> scripts all return values based on the assumption that everything will >> be installed before being used. Since we're cross-compiling, that's not >> the case. > > pkgconfig and its imitations (such as our config scripts) share this > problem with libtool. > >> So now I'm trying to force things by using sed to replace prefix= in the >> various *-config scripts, but I haven't find a good time in the process >> to do that, and a good pattern to guarantee the results needed... > > Don't forget the .la files :) That's actually the canonical way to do > it, I think (and yes, it's a PITA). For GPGME and friends, you can also > just build and install for the cross-compilation build paths, and > use the --with-gpg and --with-gpgsm etc. options to specify the > hard-coded target file names of the crypto engines. The result is > relocatable except for the .la and -config files, which need to be fixed > up anyway. (So, if you want to develop on build and target, you > absolutely need two copies of those files, no matter what you do). Ah yes! That was the trick to get everything to build. I set --prefix= on all of the libs to what I had been using for $(DESTDIR)$(prefix) and the whole build worked. I'll test it now. The only question I have is that setting --prefix= in gnupg will alter where gpg-agent puts its socket file, no? .hc From nicholas.cole at gmail.com Thu Aug 16 21:42:20 2012 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Thu, 16 Aug 2012 20:42:20 +0100 Subject: SKS Protocol Message-ID: Is the SKS Synconization protocol documented anywhere? I've found the links to the theoretical papers that underpin it, but no documentation of the actual method used. Apologies, of course, if I have missed something obvious.... Best wishes, Nicholas From hans at guardianproject.info Fri Aug 17 01:58:44 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Thu, 16 Aug 2012 19:58:44 -0400 Subject: building gpgme for Android dies on install In-Reply-To: <502D3DB7.2050201@guardianproject.info> References: <502C16F1.4030900@guardianproject.info> <502C4355.9030804@guardianproject.info> <502C4E5D.3060402@guardianproject.info> <502CA1E2.8050903@ruhr-uni-bochum.de> <502D3DB7.2050201@guardianproject.info> Message-ID: <502D8934.8040500@guardianproject.info> On 08/16/2012 02:36 PM, Hans-Christoph Steiner wrote: > > On 08/16/2012 03:31 AM, Marcus Brinkmann wrote: >> On 08/16/2012 03:35 AM, Hans-Christoph Steiner wrote: >>> >>> I believe I found the source of the trouble. The various *-config >>> scripts all return values based on the assumption that everything will >>> be installed before being used. Since we're cross-compiling, that's not >>> the case. >> >> pkgconfig and its imitations (such as our config scripts) share this >> problem with libtool. >> >>> So now I'm trying to force things by using sed to replace prefix= in the >>> various *-config scripts, but I haven't find a good time in the process >>> to do that, and a good pattern to guarantee the results needed... >> >> Don't forget the .la files :) That's actually the canonical way to do >> it, I think (and yes, it's a PITA). For GPGME and friends, you can also >> just build and install for the cross-compilation build paths, and >> use the --with-gpg and --with-gpgsm etc. options to specify the >> hard-coded target file names of the crypto engines. The result is >> relocatable except for the .la and -config files, which need to be fixed >> up anyway. (So, if you want to develop on build and target, you >> absolutely need two copies of those files, no matter what you do). > > Ah yes! That was the trick to get everything to build. I set --prefix= > on all of the libs to what I had been using for $(DESTDIR)$(prefix) and > the whole build worked. I'll test it now. The only question I have is > that setting --prefix= in gnupg will alter where gpg-agent puts its > socket file, no? And changing prefix= to the whole thing on 'gnupg' means it looks in the wrong place for dirmngr and friends. Looks like I'll need a sed hack after all. .hc From hans at guardianproject.info Fri Aug 17 04:28:51 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Thu, 16 Aug 2012 22:28:51 -0400 Subject: gnupg/tools/watchgnupg.c points to non-existent "../jnlib/mischelp.h" Message-ID: <502DAC63.6020809@guardianproject.info> When I removed --disable-tools from the Android GnuPG build, it died with this error: watchgnupg.c:50:31: fatal error: ../jnlib/mischelp.h: No such file or directory This simple patch fixed the build, but I haven't tested the resulting build yet: diff --git a/tools/watchgnupg.c b/tools/watchgnupg.c index 592819b..c7a404e 100644 --- a/tools/watchgnupg.c +++ b/tools/watchgnupg.c @@ -47,7 +47,7 @@ #endif #if !defined(SUN_LEN) || !defined(PF_LOCAL) || !defined(AF_LOCAL) #define JNLIB_NEED_AFLOCAL -#include "../jnlib/mischelp.h" +#include "../common/mischelp.h" #endif It seems that there are some other vestiges of this jnlib folder which seems to have been merged into common: hans at palatschinken gnupg $ find . -type f -name '*.[hc]' |xargs grep 'jnlib/' ./common/pka.c:compile-command: "cc -DUSE_DNS_PKA -DTEST -I.. -I../include -Wall -g -o pka pka.c -lresolv ../tools/no-libgcrypt.o ../jnlib/libjnlib.a" ./common/srv.c:compile-command: "cc -DTEST -I.. -I../include -Wall -g -o srv srv.c -lresolv ../tools/no-libgcrypt.o ../jnlib/libjnlib.a" ./dirmngr/no-libgcrypt.c: ../jnlib/libjnlib.a . ../common/util.h defines macros to map them ./keyserver/no-libgcrypt.c: ../jnlib/libjnlib.a . ../common/util.h defines macros to map them ./tools/no-libgcrypt.c: ../jnlib/libjnlib.a . ../common/util.h defines macros to map them .hc From hans at guardianproject.info Fri Aug 17 04:47:01 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Thu, 16 Aug 2012 22:47:01 -0400 Subject: patch to fix Android build Message-ID: <502DB0A5.4030009@guardianproject.info> Attached is the patch to gnupg master that I've been using since Feb for the Android builds. Its been working fine for me, and it would be good to have it included in the main git. It includes some logic for disabling the tests so when cross-compiling, they can be disabled. .hc -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-fix-build-system-for-Android-by-disabling-tests-sinc.patch Type: text/x-patch Size: 2445 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From John at enigmail.net Fri Aug 17 02:34:48 2012 From: John at enigmail.net (John Clizbe) Date: Thu, 16 Aug 2012 19:34:48 -0500 Subject: SKS Protocol In-Reply-To: References: Message-ID: <502D91A8.7060009@enigmail.net> Nicholas Cole wrote: > Is the SKS Synconization protocol documented anywhere? I've found the > links to the theoretical papers that underpin it, but no documentation > of the actual method used. Other than those two papers, every else is in the Ocaml code. https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Home > Apologies, of course, if I have missed something obvious.... Is there something specific you're looking for? Essentially, a hash is made of each key and stored in the PTree (Prefix tree) database. This is the set used by the reconciliation algorithm described in the papers. You may find asking on the the SKS Development list to be more helpful. mailto://sks-devel at nongnu.org -John -- John P. Clizbe Inet: John (a) Gingerbear DAWT net SKS/Enigmail/PGP-EKP or: John ( @ ) Enigmail DAWT net FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 501 bytes Desc: OpenPGP digital signature URL: From hans at guardianproject.info Fri Aug 17 05:58:31 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Thu, 16 Aug 2012 23:58:31 -0400 Subject: building gpgme for Android dies on install In-Reply-To: <502D8934.8040500@guardianproject.info> References: <502C16F1.4030900@guardianproject.info> <502C4355.9030804@guardianproject.info> <502C4E5D.3060402@guardianproject.info> <502CA1E2.8050903@ruhr-uni-bochum.de> <502D3DB7.2050201@guardianproject.info> <502D8934.8040500@guardianproject.info> Message-ID: <502DC167.3060509@guardianproject.info> On 08/16/2012 07:58 PM, Hans-Christoph Steiner wrote: > > > On 08/16/2012 02:36 PM, Hans-Christoph Steiner wrote: >> >> On 08/16/2012 03:31 AM, Marcus Brinkmann wrote: >>> On 08/16/2012 03:35 AM, Hans-Christoph Steiner wrote: >>>> >>>> I believe I found the source of the trouble. The various *-config >>>> scripts all return values based on the assumption that everything will >>>> be installed before being used. Since we're cross-compiling, that's not >>>> the case. >>> >>> pkgconfig and its imitations (such as our config scripts) share this >>> problem with libtool. >>> >>>> So now I'm trying to force things by using sed to replace prefix= in the >>>> various *-config scripts, but I haven't find a good time in the process >>>> to do that, and a good pattern to guarantee the results needed... >>> >>> Don't forget the .la files :) That's actually the canonical way to do >>> it, I think (and yes, it's a PITA). For GPGME and friends, you can also >>> just build and install for the cross-compilation build paths, and >>> use the --with-gpg and --with-gpgsm etc. options to specify the >>> hard-coded target file names of the crypto engines. The result is >>> relocatable except for the .la and -config files, which need to be fixed >>> up anyway. (So, if you want to develop on build and target, you >>> absolutely need two copies of those files, no matter what you do). >> >> Ah yes! That was the trick to get everything to build. I set --prefix= >> on all of the libs to what I had been using for $(DESTDIR)$(prefix) and >> the whole build worked. I'll test it now. The only question I have is >> that setting --prefix= in gnupg will alter where gpg-agent puts its >> socket file, no? > > And changing prefix= to the whole thing on 'gnupg' means it looks in the > wrong place for dirmngr and friends. Looks like I'll need a sed hack > after all. Ok, I think I got the right combo of prefix and DESTDIR, and then setting the paths to the various tools. Now I'm stuck with an "Invalid crypto engine" exception from gpgme even tho the path to the gpg2 that it has is correct, and gpg2 seems to work in the Android terminal. .hc From nicholas.cole at gmail.com Fri Aug 17 07:58:33 2012 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Fri, 17 Aug 2012 06:58:33 +0100 Subject: SKS Protocol In-Reply-To: <502D91A8.7060009@enigmail.net> References: <502D91A8.7060009@enigmail.net> Message-ID: On Friday, August 17, 2012, John Clizbe wrote: > Nicholas Cole wrote: > > Is the SKS Synconization protocol documented anywhere? I've found the > > links to the theoretical papers that underpin it, but no documentation > > of the actual method used. > > Other than those two papers, every else is in the Ocaml code. > https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Home > > > Apologies, of course, if I have missed something obvious.... > > Is there something specific you're looking for? > > Essentially, a hash is made of each key and stored in the PTree (Prefix > tree) > database. This is the set used by the reconciliation algorithm described in > the papers. > > You may find asking on the the SKS Development list to be more helpful. > mailto://sks-devel at nongnu.org > Dear John, Thank you. Yes, I feared I'd have to learn to read Ocaml! :-) I was mostly interested in exactly how they made the hash of each key, but it's also a really interesting and subtle problem they've fixed in getting such reliable and rapid distribution of the database. Best wishes, Nicholas -------------- next part -------------- An HTML attachment was scrubbed... URL: From nosuchclient at gmail.com Fri Aug 17 17:43:04 2012 From: nosuchclient at gmail.com (No such Client) Date: Fri, 17 Aug 2012 17:43:04 +0200 Subject: Gpg revocation anomaly Message-ID: <502E6688.5040405@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Good day, I have found an anomaly within gpg that I have asked several other individuals running different linux distros (gpg 1.4.10 / 1.4.11) to independently verify and they have come to the same conclusion. After reading the gnupg manual, and the manpages several times for pleasure, I tried ?addrevoker sensitive? , with a testkey that I created. I have read the manpages, and the manual, and my understanding of addrevoker sensitive is that it is a deniable designated revoker that no one else but the revoked party and the revokee should know what it is. As well as B. That said ?sensitive? (deniable) designated revoker can reliably generate and revoke whatever key said individual has been designated as a sensitive revoker for. So, I tested this feature using two test keys on a new keyring I created to simulate a real-world environment. and this raised more questions than answers (addrevoker sensitive - is not well-documented, nor is it covered in any detail) # to create a new keyring (using bash) mkdir new_gpg export GNUPGHOME=newgpg/ # generating testkeys gpg --gen-key (generated testkey 1, and testkey2 , using default settings for sake of example ) gpg --fingerprint new_gpg//pubring.gpg - -------------------- pub 1024R/10CAC705 2012-08-17 [expires: 2012-08-19] Key fingerprint = 9AAE 107E E4F4 80D3 D4A2 633F 61E4 5498 10CA C705 uid testkey1 sub 1024R/33C50E7A 2012-08-17 [expires: 2012-08-19] pub 1024R/FC736AA2 2012-08-17 [expires: 2012-08-19] Key fingerprint = AB08 CD0A E5A1 8DB8 CDBC 3DD2 95C6 26F3 FC73 6AA2 uid testkey2 sub 1024R/3C5A6360 2012-08-17 [expires: 2012-08-19] # designation gpg --edit-key testkey2 addrevoker sensitive -> testkey1 -> (finish the prompt and save) #now we will import the testkey2 pubkey into the ?main keyring? gpg -a --export testkey2 > testkey2.pub # in the primary key-ring (using screen, or opening a new terminal will open a new bash instance with the standard default gpg path set to ~/.gnupg/) gpg --import testkey2.pub (gpg: key FC736AA2: public key "testkey2" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) ) # now back to the test key-ring gpg --desig-revoke testkey2 (pub 1024R/FC736AA2 2012-08-17 testkey2 To be revoked by: sec 1024R/10CAC705 2012-08-17 testkey1 (This is a sensitive revocation key) Create a designated revocation certificate for this key? (y/N)) -> Y - -> 0 (No reason specified) and voila.. Is this okay? (y/N) y ASCII armored output forced. Revocation certificate created. #which is imported ofc... # to show... gpg: key FC736AA2: "testkey2" revocation certificate added gpg: key FC736AA2: "testkey2" 1 new signature gpg: Total number processed: 1 gpg: new signatures: 1 gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 2 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 2u gpg: next trustdb check due at 2012-08-19 and a gpg --edit-key testkey2 shows: gpg --edit-key testkey2 gpg (GnuPG) 1.4.10; Copyright (C) 2008 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Secret key is available. This key was revoked on 2012-08-17 by RSA key 10CAC705 testkey1 This key may be revoked by RSA key 10CAC705 testkey1 (sensitive) pub 1024R/FC736AA2 created: 2012-08-17 revoked: 2012-08-17 usage: SC trust: ultimate validity: revoked This key was revoked on 2012-08-17 by RSA key 10CAC705 testkey1 sub 1024R/3C5A6360 created: 2012-08-17 revoked: 2012-08-17 usage: E [ revoked] (1). testkey2 # Now for the anomaly... we update the exported pubkey gpg -a --export testkey2 testkey2.pub # and just in case you are wondering, here is what it looks like: gpg testkey2.pub pub 1024R/FC736AA2 2012-08-17 [revoked] uid testkey2 sub 1024R/3C5A6360 2012-08-17 [expires: 2012-08-19] # and now, using the primary keyring,.. #before import , gpg --edit-key testkey2 shows: pub 1024R/FC736AA2 created: 2012-08-17 expires: 2012-08-19 usage: SC trust: unknown validity: unknown sub 1024R/3C5A6360 created: 2012-08-17 expires: 2012-08-19 usage: E [ unknown] (1). testkey2 # during import.... : gpg --import testkey2.pub gpg: key FC736AA2: "testkey2" revocation certificate added gpg: key FC736AA2: "testkey2" 1 new signature gpg: Total number processed: 1 gpg: new signatures: 1 gpg: public key 9AD09F2D is 57303581 seconds newer than the signature gpg: public key 0B12861B is 9237 seconds newer than the signature gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 26 signed: 13 trust: 0-, 0q, 0n, 0m, 0f, 26u gpg: depth: 1 valid: 13 signed: 0 trust: 0-, 1q, 8n, 3m, 1f, 0u gpg: next trustdb check due at 2012-09-11 # after gpg --edit-key testkey2 shows: gpg --edit-key testkey2 pub 1024R/FC736AA2 created: 2012-08-17 expires: 2012-08-19 usage: SC trust: unknown validity: unknown sub 1024R/3C5A6360 created: 2012-08-17 expires: 2012-08-19 usage: E [ unknown] (1). testkey2 # Perhaps addrevoker sensitive is not.. supposed to reliably revoke keys on other systems? Or is it a local revoke option? (if that was the case, a revokekey in gpg --edit-key would suffice.. ) #hmm... wierd. and just to illustrate my point... ( on the test keyring ) gpg -ea -r testkey2 gpg: testkey2: skipped: unusable public key gpg: [stdin]: encryption failed: unusable public key ( and on the primary keyringgpg -ea -r testkey2 -o testcipher.txt gpg: 3C5A6360: There is no assurance this key belongs to the named user pub 1024R/3C5A6360 2012-08-17 testkey2 Primary key fingerprint: AB08 CD0A E5A1 8DB8 CDBC 3DD2 95C6 26F3 FC73 6AA2 Subkey fingerprint: 851C BE30 B5B8 3617 2542 C31E 5B5E 5515 3C5A 6360 It is NOT certain that the key belongs to the person named in the user ID. If you *really* know what you are doing, you may answer the next question with yes. Use this key anyway? (y/N) y ....... I have found a few other slight anomalies and results that raise more questions on this matter and on others, my pubkey is attached I have tested this myself now for the fourth time to verify that this behaviour is not me making a mistake, as well as having three other linux and sec folks also independently reproduce my little test, and they all came up with similar results (their testkey2 was not reliably revoked, however there are variations in the text gpg standard output) And to really make sure I wasnt making any mistakes, I have also read the gnupg manual several times, as well as the man page , and this anomaly is believed to be bona-fide. I invite anyone and everyone who is interested to try this yourself with the above commands (or with variations) , and share your results. My pubkey is attached, feel free to email me directly if you have any questions, concerns, or insights to share. Thank you for your time Btw, the checksums for my public key bzip are: no.tar.bz2: MD5 = 92 24 98 62 B9 E7 01 41 F2 9F 92 89 16 19 9F D0 no.tar.bz2: SHA1 = AF34 35A5 0C14 74B2 2B9A 4CA9 D3BC 12C0 9273 F185 no.tar.bz2: RMD160 = 32FC 0DC6 FECF 7E37 D46C B682 3E83 5C1A 44B2 082F no.tar.bz2: SHA224 = 0DB36929 5F8FDF73 5145E35E 3F364504 874F2BA2 C4FA398A D2E88780 no.tar.bz2: SHA256 = D4F3253B D2FCAE6D BF760B35 B6A93F45 35DE83A0 561509D8 766F0DE9 B1C7849D no.tar.bz2: SHA384 = 256FC5DF 7FE3C7A1 19AA38B7 073FE2C5 206C2700 5798B830 F925770A 987CCC89 660A9EB6 976C5623 EE4ADD7C 32E0C216 no.tar.bz2: SHA512 = C53E5E13 A26E2FC0 ED8CB17A 7B8ECEC0 CC00E5ED D0CE4E4A 171F1C9A CC3C14E9 E703691D 1138DB0C 9F41AF75 FFA70976 395740D4 AC829780 B873D56E 85FA9280 -----BEGIN PGP SIGNATURE----- iF4EAREKAAYFAlAuZiYACgkQW09oVTHoH/dYuQEAxdabz5ZxFn7FjDnrtrl+ufGj uZFcix0PoJ6Fq5Ae3pUBAOhWnurb7gQ7hBZZfWCYkVK4YE8ISjwGlk0Z3kF04q+2 =jj6S -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: no.tar.bz2 Type: application/x-bzip Size: 6294 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x31E81FF7.asc Type: application/pgp-keys Size: 2797 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From ekleog at gmail.com Fri Aug 17 18:00:19 2012 From: ekleog at gmail.com (Leo Gaspard) Date: Fri, 17 Aug 2012 18:00:19 +0200 Subject: gpgme_data_seek with SEEK_END on memory-based data fails In-Reply-To: <87txw6k5x0.fsf@vigenere.g10code.de> References: <501434CA.3090208@gmail.com> <501447BF.1070005@ruhr-uni-bochum.de> <50145736.3040109@gmail.com> <87lii29a5o.fsf@vigenere.g10code.de> <50158011.1080201@gmail.com> <87d33d8vtf.fsf@vigenere.g10code.de> <50166515.4020701@gmail.com> <87y5m16wng.fsf@vigenere.g10code.de> <50291819.30601@gmail.com> <87txw6k5x0.fsf@vigenere.g10code.de> Message-ID: <502E6A93.3010702@gmail.com> On 13/08/2012 20:23, Werner Koch wrote: > On Mon, 13 Aug 2012 17:07, ekleog at gmail.com said: > >> Yes, I saw GPGME_KEYLIST_MODE_* flags. But there are no way of >> selecting the keyserver to use directly from GPGME. So the only way >> would be to modify gpg.conf before each operation ? > > Right. Note that the keyservesr sync themselfs anyway. Yes. But concentrating the charge of all "my" users on a single server isn't very good, and at my house round-robin DNS such as keys.gnupg.net have a really long response time, while e.g. pgp.mit.edu is really fast. So I built a list of some 79 keyservers (based on the peers each server says it syncs with), and will have my app choose a random one upon firefox startup. This should speed things up. >> * gpgme.c : The only externally-visible API change : adding >> gpgme_set|get_keyserver. The objective of the patch > > That is an API extension, so in general not a problem. However, if we > add it we need to maintain it virtually forever. Thus I need to see a > very good reason why you need it. Note that I consider keyservers an > implementation detail of GnuPG and thus nothing which should go into an > ?...made easy? API. We already have GPGME_KEYLIST_MODE_EXTERN, which specifies from where to look for the keys. This could also be considered as a GnuPG implementation detail. And, anyway, maintaining them "forever" isn't a really hard issue : GnuPG has it in its "API", meaning the "--keyserver" will always be valid. Which means that, as long as GPGME will use GPG under the hood, it will work. If the dependency is ever reversed, GPGME will have to provide a get|set_keyserver for GPG to use. If both ever depend on a third tool, this third tool will have to provide such functions, an GPGME will use them as easily as GPG will do. Also, you could argue GPGME_KEYLIST_MODE_EXTERN is a useful extension in that it allows to make an offline application, or to optimize keylisting, or such things. But setting the keyserver is almost as useful : it allows to use a local keyserver, or to use some keyserver not synchronizing with the others (keyserver.pgp.net ?), etc. Finally, I understood the "made easy" as meaning "don't parse things you're almost sure to fail parsing correctly, and leave the harness of parsing to people who know GPG's output better than you, because they chose it". As a last statement, I believe (but that's only my humble opinion) that GPGME should offer as much options as GPG does, so that one doesn't have to hesitate between parsing GPG's output (developper-time-consuming, error-prone), and using GPGME (fast-use, secure, error-free). Here's the end of my plea. If others could say their opinion about this patch, maybe could that help choosing whether it should be integrated or not. Cheers, Leo From dshaw at jabberwocky.com Fri Aug 17 19:07:06 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 17 Aug 2012 13:07:06 -0400 Subject: Gpg revocation anomaly In-Reply-To: <502E6688.5040405@gmail.com> References: <502E6688.5040405@gmail.com> Message-ID: On Aug 17, 2012, at 11:43 AM, No such Client wrote: > Good day, I have found an anomaly within gpg that I have asked several > other individuals running different linux distros (gpg 1.4.10 / 1.4.11) > to independently verify and they have come to the same conclusion. > After reading the gnupg manual, and the manpages several times for > pleasure, I tried ?addrevoker sensitive? , with a testkey that I > created. I have read the manpages, and the manual, and my understanding > of addrevoker sensitive is that it is a deniable designated revoker that > no one else but the revoked party and the revokee should know what it > is. As well as B. That said ?sensitive? (deniable) designated revoker > can reliably generate and revoke whatever key said individual has been > designated as a sensitive revoker for. So, I tested this feature using > two test keys on a new keyring I created to simulate a real-world > environment. and this raised more questions than answers (addrevoker > sensitive - is not well-documented, nor is it covered in any detail) A sensitive designated revoker isn't deniable. All it means is that when exporting the key that can be revoked, the designated revoker packet isn't included by default. That's it. Here's a use case: Alice wants Baker to be able to revoke her key, but she doesn't want anyone else to know this (say, she's afraid that Charlie will come after Baker in the real world). She adds Baker to her key via 'addrevoker sensitive'. She then sends a copy of her public key to Baker, but exports it with "--export-options export-sensitive-revkeys". Now that she'd done this, she can safely send her public key to anyone she likes (to the keyserver, or even to Charlie directly), as the designated revoker information on the key will not be included, thus hiding the fact that Baker has the power to revoke Alice's key. If and when Baker needs to revoke Alice's key, he issues the revocation signature, adds it to Alice's public key, and publishes it, including *both his revocation signature (to revoke Alice's key), and the designated revoker packet (to prove he has the right to issue the revocation)*. After revocation, there is no deniability - clearly Baker issued the revocation, and clearly Alice allowed him to do so. David From makrober at gmail.com Fri Aug 17 20:03:24 2012 From: makrober at gmail.com (M.R.) Date: Fri, 17 Aug 2012 18:03:24 +0000 Subject: crypto primitives Message-ID: <502E876C.1000007@gmail.com> Is there any documentation available on the methods to extract only the cryptographic primitives in C language source form from the gpg code base? TIA, Marc Roberts From nosuchclient at gmail.com Sat Aug 18 00:19:48 2012 From: nosuchclient at gmail.com (No such Client) Date: Sat, 18 Aug 2012 00:19:48 +0200 Subject: Gpg revocation anomaly In-Reply-To: <2118436.MBoZ9JCAOA@inno> References: <502E6688.5040405@gmail.com> <2118436.MBoZ9JCAOA@inno> Message-ID: <502EC384.9010108@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 a) This strange time problem. Try --ignore-time-conflict. - -> Did that, reimported, with.. gpg --ignore-time-conflict --import testkey2.pub gpg: key FC736AA2: "testkey2" not changed gpg: Total number processed: 1 gpg: unchanged: 1 b) Have you imported the public key of testkey1 in your normal keyring? If not then the validity of the revocation signature cannot be checked. # Personally, I was under the impression that even you do *not* have the designated revoker key in your k-ring, that a valid revocation signature is still binding to revoke the key. If alice revokes bob?s key, and charlie has alice?s pubkey, but david, eric, and frank all don?t... that doesnt matter.. Bobs key is still revoked by alice. They can just see the keyid that revoked it.. It does not make the signature any less valid.. Otherwise the web of trust, and revocations are... quite useless.. But, I may be mistaken.. for arguments sake.. I did as you asked (as you are being helpful :-) ) gpg --import testkey1.pub gpg: key 10CAC705: public key "testkey1" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) gpg --edit-key testkey2 pub 1024R/FC736AA2 created: 2012-08-17 expires: 2012-08-19 usage: SC trust: unknown validity: unknown sub 1024R/3C5A6360 created: 2012-08-17 expires: 2012-08-19 usage: E [ unknown] (1). testkey2 # no... the revocation has not been reliably applied yet.. even after importing testkey1?s pubkey.. I can change trust levels, but that also does not change anything. The key is not .. reliably revoked. hmm. # revocation key of testkey2 gpg -vv --list-packets testkey2.rev gpg: armor: BEGIN PGP PUBLIC KEY BLOCK gpg: armor header: Version: GnuPG v1.4.10 (GNU/Linux) gpg: armor header: Comment: A designated revocation certificate should follow :public key packet: version 4, algo 1, created 1345216353, expires 0 pkey[0]: [1024 bits] pkey[1]: [17 bits] :signature packet: algo 1, keyid 61E4549810CAC705 version 4, created 1345240934, md5len 0, sigclass 0x20 digest algo 2, begin of digest 5b 07 hashed subpkt 2 len 4 (sig created 2012-08-17) hashed subpkt 29 len 1 (revocation reason 0x00 ()) subpkt 16 len 8 (issuer key ID 61E4549810CAC705) data: [1021 bits] :signature packet: algo 1, keyid 95C626F3FC736AA2 version 4, created 1345216416, md5len 0, sigclass 0x1f digest algo 2, begin of digest a1 e0 hashed subpkt 2 len 4 (sig created 2012-08-17) hashed subpkt 12 len 22 (revocation key: c=c0 a=1 f=9AAE107EE4F480D3D4A2633F61E4549810CAC705) hashed subpkt 7 len 1 (not revocable) subpkt 16 len 8 (issuer key ID 95C626F3FC736AA2) data: [1024 bits] :user ID packet: "testkey2" :signature packet: algo 1, keyid 95C626F3FC736AA2 version 4, created 1345216353, md5len 0, sigclass 0x13 digest algo 2, begin of digest 04 af hashed subpkt 2 len 4 (sig created 2012-08-17) hashed subpkt 27 len 1 (key flags: 03) hashed subpkt 9 len 4 (key expires after 2d0h0m) hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2) hashed subpkt 21 len 5 (pref-hash-algos: 8 2 9 10 11) hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1) hashed subpkt 30 len 1 (features: 01) hashed subpkt 23 len 1 (key server preferences: 80) subpkt 16 len 8 (issuer key ID 95C626F3FC736AA2) data: [1024 bits] # testkey2 public key with revocation signature added gpg -vv --list-packets testkey2.pub gpg: armor: BEGIN PGP PUBLIC KEY BLOCK gpg: armor header: Version: GnuPG v1.4.10 (GNU/Linux) :public key packet: version 4, algo 1, created 1345216353, expires 0 pkey[0]: [1024 bits] pkey[1]: [17 bits] :signature packet: algo 1, keyid 61E4549810CAC705 version 4, created 1345216836, md5len 0, sigclass 0x20 digest algo 2, begin of digest b7 67 hashed subpkt 2 len 4 (sig created 2012-08-17) hashed subpkt 29 len 1 (revocation reason 0x00 ()) subpkt 16 len 8 (issuer key ID 61E4549810CAC705) data: [1024 bits] :user ID packet: "testkey2" :signature packet: algo 1, keyid 95C626F3FC736AA2 version 4, created 1345216353, md5len 0, sigclass 0x13 digest algo 2, begin of digest 04 af hashed subpkt 2 len 4 (sig created 2012-08-17) hashed subpkt 27 len 1 (key flags: 03) hashed subpkt 9 len 4 (key expires after 2d0h0m) hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2) hashed subpkt 21 len 5 (pref-hash-algos: 8 2 9 10 11) hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1) hashed subpkt 30 len 1 (features: 01) hashed subpkt 23 len 1 (key server preferences: 80) subpkt 16 len 8 (issuer key ID 95C626F3FC736AA2) data: [1024 bits] :public sub key packet: version 4, algo 1, created 1345216353, expires 0 pkey[0]: [1024 bits] pkey[1]: [17 bits] :signature packet: algo 1, keyid 95C626F3FC736AA2 version 4, created 1345216353, md5len 0, sigclass 0x18 digest algo 2, begin of digest a8 0b hashed subpkt 2 len 4 (sig created 2012-08-17) hashed subpkt 27 len 1 (key flags: 0C) hashed subpkt 9 len 4 (key expires after 2d0h0m) subpkt 16 len 8 (issuer key ID 95C626F3FC736AA2) data: [1022 bits] -----BEGIN PGP SIGNATURE----- iF4EAREKAAYFAlAuwwcACgkQW09oVTHoH/dHkgD/WCXGNOoFZadKoibUahtHLa/7 7EWB4fJVx+u+E5rfBbEA/03a4cgwBv9r0L9Ktg/lEcKWCXJMihba3DztlJnsUNze =IBxR -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x31E81FF7.asc Type: application/pgp-keys Size: 2797 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From mailinglisten at hauke-laging.de Fri Aug 17 23:40:46 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 17 Aug 2012 23:40:46 +0200 Subject: Gpg revocation anomaly In-Reply-To: <502E6688.5040405@gmail.com> References: <502E6688.5040405@gmail.com> Message-ID: <2118436.MBoZ9JCAOA@inno> Am Fr 17.08.2012, 17:43:04 schrieb No such Client: > # during import.... : > > gpg --import testkey2.pub > gpg: key FC736AA2: "testkey2" revocation certificate added > gpg: key FC736AA2: "testkey2" 1 new signature > gpg: Total number processed: 1 > gpg: new signatures: 1 > gpg: public key 9AD09F2D is 57303581 seconds newer than the signature > gpg: public key 0B12861B is 9237 seconds newer than the signature > gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model > gpg: depth: 0 valid: 26 signed: 13 trust: 0-, 0q, 0n, 0m, 0f, 26u > gpg: depth: 1 valid: 13 signed: 0 trust: 0-, 1q, 8n, 3m, 1f, 0u > gpg: next trustdb check due at 2012-09-11 I think there are two problems: a) This strange time problem. Try --ignore-time-conflict. b) Have you imported the public key of testkey1 in your normal keyring? If not then the validity of the revocation signature cannot be checked. Both reasons should make gpg ignore the revocation signature. What is the output of gpg -vv --list-packets for the revocation signature file? Hauke -- ? PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From dshaw at jabberwocky.com Sat Aug 18 01:27:35 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 17 Aug 2012 19:27:35 -0400 Subject: Gpg revocation anomaly In-Reply-To: <502EC384.9010108@gmail.com> References: <502E6688.5040405@gmail.com> <2118436.MBoZ9JCAOA@inno> <502EC384.9010108@gmail.com> Message-ID: <5F811BD3-08B0-427C-8824-87DD5706E4C7@jabberwocky.com> On Aug 17, 2012, at 6:19 PM, No such Client wrote: > # Personally, I was under the impression that even you do *not* have the > designated revoker key in your k-ring, that a valid revocation signature > is still binding to revoke the key. If alice revokes bob?s key, and > charlie has alice?s pubkey, but david, eric, and frank all don?t... that > doesnt matter.. Bobs key is still revoked by alice. They can just see > the keyid that revoked it.. That is not the case. Like any other signature, the only way to verify a revocation signature is to use the public key of the key that issued the signature. Without Alice's key being present, how would David, Eric, and Frank know that the signature on Bob's key is a real revocation signature and not a forgery? Note that David, Eric, and Frank will be warned about this. If they import Bob's revoked key and not Alice's, they'll get a message like "WARNING: key (Bob's keyid) may be revoked: revocation key (Alice's keyid) not present" David From John at enigmail.net Sat Aug 18 01:56:31 2012 From: John at enigmail.net (John Clizbe) Date: Fri, 17 Aug 2012 18:56:31 -0500 Subject: SKS Protocol In-Reply-To: References: <502D91A8.7060009@enigmail.net> Message-ID: <502EDA2F.4090603@enigmail.net> Nicholas Cole wrote: > > Dear John, > > Thank you. Yes, I feared I'd have to learn to read Ocaml! :-) Reading Ocaml is fairly easy. It's the thinking in a functional manner as opposed to an imperative one that takes the effort. The best place to start is the Ocaml Resources page. [0] It has links to the language manual[1] and the standard library [2]. Version 4.00 of the Ocaml language was just released. We target version 3.11 and greater. There are many more online. Email me off-list at the top address in my sig block and I'll supply names and links. Do not bother with the book 'Practical Ocaml' -- I received that advice too late, but I did not pay full price. For the SKS source, I would suggest the trunk. There have been a LOT of changes since 1.1.3. You may either clone it [3] or download a tarball[4] from the 'get source' link on the project's Source tab (.zip, .gz, & .bz2 are available). > I was mostly interested in exactly how they made the hash of each key, but > it's also a really interesting and subtle problem they've fixed in getting > such reliable and rapid distribution of the database. I need to go check before I answer, but I can tell you hashes are 128 bits. -John [0] http://caml.inria.fr/resources/index.en.html [1] http://caml.inria.fr/pub/docs/manual-ocaml-4.00/index.html [2] http://caml.inria.fr/pub/docs/manual-ocaml-4.00/libref/index.html [3] hg clone https://bitbucket.org/skskeyserver/sks-keyserver [4] https://bitbucket.org/skskeyserver/sks-keyserver/get/ac4a7159ca28.tar.bz2 -- John P. Clizbe Inet: John (a) Gingerbear DAWT net SKS/Enigmail/PGP-EKP or: John ( @ ) Enigmail DAWT net FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From John at enigmail.net Sat Aug 18 02:51:12 2012 From: John at enigmail.net (John Clizbe) Date: Fri, 17 Aug 2012 19:51:12 -0500 Subject: SKS Protocol In-Reply-To: <502EDA2F.4090603@enigmail.net> References: <502D91A8.7060009@enigmail.net> <502EDA2F.4090603@enigmail.net> Message-ID: <502EE700.4060802@enigmail.net> John Clizbe wrote: > Nicholas Cole wrote: > >> I was mostly interested in exactly how they made the hash of each key, but >> it's also a really interesting and subtle problem they've fixed in getting >> such reliable and rapid distribution of the database. > > I need to go check before I answer, but I can tell you hashes are 128 bits. hashes are created calling the Ocaml standard library function Digest.string which is built on MD5. Exact details are in keyHash.ml [0] -John [0] https://bitbucket.org/skskeyserver/sks-keyserver/src/ac4a7159ca28/keyHash.ml -- John P. Clizbe Inet: John (a) Gingerbear DAWT net SKS/Enigmail/PGP-EKP or: John ( @ ) Enigmail DAWT net FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From JPClizbe at tx.rr.com Sat Aug 18 02:24:55 2012 From: JPClizbe at tx.rr.com (John Clizbe) Date: Fri, 17 Aug 2012 19:24:55 -0500 Subject: crypto primitives In-Reply-To: <502E876C.1000007@gmail.com> References: <502E876C.1000007@gmail.com> Message-ID: <502EE0D7.8020102@tx.rr.com> M.R. wrote: > Is there any documentation available on the methods to extract only > the cryptographic primitives in C language source form from the gpg code > base? The cipher directory in the libgcrypt or gnupg-1.4 source? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From makrober at gmail.com Sun Aug 19 03:57:11 2012 From: makrober at gmail.com (M.R.) Date: Sun, 19 Aug 2012 01:57:11 +0000 Subject: crypto primitives In-Reply-To: <502EE0D7.8020102@tx.rr.com> References: <502E876C.1000007@gmail.com> <502EE0D7.8020102@tx.rr.com> Message-ID: <503047F7.3080200@gmail.com> On 18/08/12 00:24, John Clizbe wrote: > > The cipher directory in the libgcrypt or gnupg-1.4 source? Hi John, thanks for responding; my understanding is that since libgcrypt is more recent, it might (or might not) have more algorithms implemented and more recent fixes and improvements; however due to the code structure stuff in gpg 1.4 functions with primitives might be easier to extract and use on their own? Am I essentially correct? Marc From robbat2 at gentoo.org Mon Aug 20 19:47:48 2012 From: robbat2 at gentoo.org (Robin H. Johnson) Date: Mon, 20 Aug 2012 17:47:48 +0000 Subject: Keysigning party methodology: Sassaman-Efficient & centralizing printing Message-ID: <20120820174748.GA27206@orbis-terrarum.net> This is from a thread back in January, I've deliberately split it to ask for a clarification. Original thread: Message-ID: <87vcnt8d3b.fsf at vigenere.g10code.de> From: Werner Koch Subject: Re: [PATCH] Allow printing key digests in key edit On Mon, Jan 30, 2012 at 03:44:08PM +0100, Werner Koch wrote: > On Mon, 30 Jan 2012 14:36, christian at quelltextlich.at said: > > - Is it feasable to ask people to check printouts of SHA2 digests before > > coming to key-signing parties? > [ And you should not use the key checking method you have in mind. > Exchanging paper slips is the only solid way to run a key signing > party. I am really sorry, that we came up with that crypto-cool key > signing scheme back at the Utrecht keyserver admins back in 2000. It > does not work in practice. ] I've seen some prior mentions of problems in crypto-cool parties, but I'd like to know if this means that the Sassaman-Efficient method should NOT be used. http://www.keysigning.org/methods/sassaman-efficient I also have some additional comments & queries about Sassaman-Efficient and running large parties: 1. If anybody is daunted by Before:step#3, there are tools for it: - gpgparticipants in the signing-party package (plain text output) - pius-party-worksheet in PIUS (HTML output) Having sane page-breaks in text file is really useful important as well. 2. Having to deal with a few pages of paper is a vast improvement on N small pieces of paper with key signatures. 3. The original directive is for participants to print their OWN copy. If they are travelling a long way and the list is only ready very close to the event, this is problematic: - they don't want the hassle of carrying the paper - they might forget it - if it's only ready close to the event, there is a scramble for EACH of them to find printing services. As such, I would like to propose the following set of variations, to alleviate this problem (latecomers still give paper slips, but everybody else is on a centrally printed copy). Changes to the "Before The Event": - Organizers submit the list file to a timestamping service. - The participants download & checksum-verify the final list before the party. They can optionally print it, but the important thing is that they have downloaded it. - The organizers print enough copies of the list for everybody PLUS any latecomers. - All latecomers should have their key paper slips! Changes to the "At The Event" - Organizers distribute their printed copies to everybody, including those come late or did not have their keys submitted in time. - Each participant checks that their own key is correct (check #1 against the organizers being honest). - Several participants can (should) also optionally have their own printed copies as check#2 for honest organizers. The human eye is quite good as spotting small differences in comparison (when not distracted by other tasks, so the gorillas are seen), so optically checking their own copies against the organizer copies is useful. - When each participant announces that that their key is correct, take care to include the key ID. - Latecomers should join the very end of the ID line, and give the other person their slip like normal. Changes to the "After The Event" - If a participant did not download the file before the party, they should use the timestamping service results to check that it has not been modified since the party. - In step #2, the participants must also check the final list that they downloaded. It should be identical to the printed copy they were given by the organizer (check #3 that the organizers were honest). -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robbat2 at gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 From ekleog at gmail.com Tue Aug 21 00:36:21 2012 From: ekleog at gmail.com (Leo Gaspard) Date: Tue, 21 Aug 2012 00:36:21 +0200 Subject: [PATCH] Fixed some "bugs" appearing through clang-analyzer Message-ID: <1345502181-21809-1-git-send-email-ekleog@gmail.com> * engine-gpgsm.c : If USE_DESCRIPTOR_PASSING is not set, some useless operations take place : * stack allocation of "int dir" ; * affectation of iocb_data->dir to dir. Fixed these by extending the #if USE_DESCRIPTOR_PASSING. * keylist.c : Same mistake twice : opd is stack-allocated and affected without ever being used, except in a sizeof ; where it may be replaced by op_data_t. * op-support.c : Useless double-assignment of err if LC_CTYPE is defined. Moved "err = 0" to a #else clause to avoid "err = 0; err = [...];". * trustlist.c : Same as keylist.c. * verify.c : * Removed useless assignment of tail to end at the end of the function parse_valid_sig ; * Removed useless assignment of lastp in a loop, while it won't be read from anywhere anylonger, in the function parse_notation. * vfs-mount.c : Same as keylist.c --- Just wanted to say clang-analyser also reports an error in import.c line 247 (err set but not used), but adding a check for "err" makes a test fail. I mean, adding "if (err) return err;" between lines 247 and 248 makes a test fail. I'm not familiar enough yet with this test framework to see where the bug comes from, and wonder whether this non-check is a mistake or not. Anyway, there is an error around these lines, no matter whether it is the missing check or an useless assignment to "err". Hoping that helps, Leo src/engine-gpgsm.c | 4 +++- src/keylist.c | 8 ++------ src/op-support.c | 3 ++- src/trustlist.c | 4 +--- src/verify.c | 4 ---- src/vfs-mount.c | 6 ++---- 6 files changed, 10 insertions(+), 19 deletions(-) diff --git a/src/engine-gpgsm.c b/src/engine-gpgsm.c index 0620458..1703381 100644 --- a/src/engine-gpgsm.c +++ b/src/engine-gpgsm.c @@ -645,7 +645,9 @@ gpgsm_set_fd (engine_gpgsm_t gpgsm, fd_type_t fd_type, const char *opt) char line[COMMANDLINELEN]; char *which; iocb_data_t *iocb_data; +#if USE_DESCRIPTOR_PASSING int dir; +#endif switch (fd_type) { @@ -668,9 +670,9 @@ gpgsm_set_fd (engine_gpgsm_t gpgsm, fd_type_t fd_type, const char *opt) return gpg_error (GPG_ERR_INV_VALUE); } +#if USE_DESCRIPTOR_PASSING dir = iocb_data->dir; -#if USE_DESCRIPTOR_PASSING /* We try to short-cut the communication by giving GPGSM direct access to the file descriptor, rather than using a pipe. */ iocb_data->server_fd = _gpgme_data_get_fd (iocb_data->data); diff --git a/src/keylist.c b/src/keylist.c index 29e30a0..2ddef91 100644 --- a/src/keylist.c +++ b/src/keylist.c @@ -858,7 +858,6 @@ gpgme_op_keylist_start (gpgme_ctx_t ctx, const char *pattern, int secret_only) { gpgme_error_t err; void *hook; - op_data_t opd; TRACE_BEG2 (DEBUG_CTX, "gpgme_op_keylist_start", ctx, "pattern=%s, secret_only=%i", pattern, secret_only); @@ -871,8 +870,7 @@ gpgme_op_keylist_start (gpgme_ctx_t ctx, const char *pattern, int secret_only) return TRACE_ERR (err); err = _gpgme_op_data_lookup (ctx, OPDATA_KEYLIST, &hook, - sizeof (*opd), release_op_data); - opd = hook; + sizeof (* (op_data_t) 0), release_op_data); if (err) return TRACE_ERR (err); @@ -898,7 +896,6 @@ gpgme_op_keylist_ext_start (gpgme_ctx_t ctx, const char *pattern[], { gpgme_error_t err; void *hook; - op_data_t opd; TRACE_BEG2 (DEBUG_CTX, "gpgme_op_keylist_ext_start", ctx, "secret_only=%i, reserved=0x%x", secret_only, reserved); @@ -911,8 +908,7 @@ gpgme_op_keylist_ext_start (gpgme_ctx_t ctx, const char *pattern[], return TRACE_ERR (err); err = _gpgme_op_data_lookup (ctx, OPDATA_KEYLIST, &hook, - sizeof (*opd), release_op_data); - opd = hook; + sizeof (* (op_data_t) 0), release_op_data); if (err) return TRACE_ERR (err); diff --git a/src/op-support.c b/src/op-support.c index 000560b..aa96555 100644 --- a/src/op-support.c +++ b/src/op-support.c @@ -122,9 +122,10 @@ _gpgme_op_reset (gpgme_ctx_t ctx, int type) if (!reuse_engine) { - err = 0; #ifdef LC_CTYPE err = _gpgme_engine_set_locale (ctx->engine, LC_CTYPE, ctx->lc_ctype); +#else + err = 0; #endif #ifdef LC_MESSAGES if (!err) diff --git a/src/trustlist.c b/src/trustlist.c index a96b6c7..30dae1f 100644 --- a/src/trustlist.c +++ b/src/trustlist.c @@ -172,7 +172,6 @@ gpgme_op_trustlist_start (gpgme_ctx_t ctx, const char *pattern, int max_level) { gpgme_error_t err = 0; void *hook; - op_data_t opd; TRACE_BEG2 (DEBUG_CTX, "gpgme_op_trustlist_start", ctx, "pattern=%s, max_level=%i", pattern, max_level); @@ -185,8 +184,7 @@ gpgme_op_trustlist_start (gpgme_ctx_t ctx, const char *pattern, int max_level) return TRACE_ERR (err); err = _gpgme_op_data_lookup (ctx, OPDATA_TRUSTLIST, &hook, - sizeof (*opd), NULL); - opd = hook; + sizeof (* (op_data_t) 0), NULL); if (err) return TRACE_ERR (err); diff --git a/src/verify.c b/src/verify.c index a61cc95..5bb231c 100644 --- a/src/verify.c +++ b/src/verify.c @@ -459,7 +459,6 @@ parse_valid_sig (gpgme_signature_t sig, char *args) sig->hash_algo = strtol (end, &tail, 0); if (errno || end == tail || *tail != ' ') return gpg_error (GPG_ERR_INV_ENGINE); - end = tail; } } } @@ -536,10 +535,7 @@ parse_notation (gpgme_signature_t sig, gpgme_status_code_t code, char *args) /* FIXME: We could keep a pointer to the last notation in the list. */ while (notation && notation->next) - { - lastp = ¬ation->next; notation = notation->next; - } if (!notation || !notation->name) /* There is notation data without a previous notation diff --git a/src/vfs-mount.c b/src/vfs-mount.c index 327e353..4ea5ed7 100644 --- a/src/vfs-mount.c +++ b/src/vfs-mount.c @@ -91,7 +91,6 @@ vfs_start (gpgme_ctx_t ctx, int synchronous, { gpgme_error_t err; void *hook; - op_data_t opd; if (!command || !*command) return gpg_error (GPG_ERR_INV_VALUE); @@ -102,9 +101,8 @@ vfs_start (gpgme_ctx_t ctx, int synchronous, if (err) return err; - err = _gpgme_op_data_lookup (ctx, OPDATA_VFS_MOUNT, &hook, sizeof (*opd), - NULL); - opd = hook; + err = _gpgme_op_data_lookup (ctx, OPDATA_VFS_MOUNT, &hook, + sizeof (* (op_data_t) 0), NULL); if (err) return err; -- 1.7.11.5 From ekleog at gmail.com Tue Aug 21 00:41:22 2012 From: ekleog at gmail.com (Leo Gaspard) Date: Tue, 21 Aug 2012 00:41:22 +0200 Subject: gpgme_data_seek with SEEK_END on memory-based data fails In-Reply-To: <502E6A93.3010702@gmail.com> References: <501434CA.3090208@gmail.com> <501447BF.1070005@ruhr-uni-bochum.de> <50145736.3040109@gmail.com> <87lii29a5o.fsf@vigenere.g10code.de> <50158011.1080201@gmail.com> <87d33d8vtf.fsf@vigenere.g10code.de> <50166515.4020701@gmail.com> <87y5m16wng.fsf@vigenere.g10code.de> <50291819.30601@gmail.com> <87txw6k5x0.fsf@vigenere.g10code.de> <502E6A93.3010702@gmail.com> Message-ID: <5032BD12.4080300@gmail.com> (I already sent this mail, but as it was at a time I had a poor internet connection and I didn't get any answer, I'm going to repost it, to make sure the mail was sent.) On 13/08/2012 20:23, Werner Koch wrote: > On Mon, 13 Aug 2012 17:07, ekleog at gmail.com said: > >> Yes, I saw GPGME_KEYLIST_MODE_* flags. But there are no way of >> selecting the keyserver to use directly from GPGME. So the only way >> would be to modify gpg.conf before each operation ? > > Right. Note that the keyservesr sync themselfs anyway. Yes. But concentrating the charge of all "my" users on a single server isn't very good, and at my house round-robin DNS such as keys.gnupg.net have a really long response time, while e.g. pgp.mit.edu is really fast. So I built a list of some 79 keyservers (based on the peers each server says it syncs with), and will have my app choose a random one upon firefox startup. This should speed things up. >> * gpgme.c : The only externally-visible API change : adding >> gpgme_set|get_keyserver. The objective of the patch > > That is an API extension, so in general not a problem. However, if we > add it we need to maintain it virtually forever. Thus I need to see a > very good reason why you need it. Note that I consider keyservers an > implementation detail of GnuPG and thus nothing which should go into an > ?...made easy? API. We already have GPGME_KEYLIST_MODE_EXTERN, which specifies from where to look for the keys. This could also be considered as a GnuPG implementation detail. And, anyway, maintaining them "forever" isn't a really hard issue : GnuPG has it in its "API", meaning the "--keyserver" will always be valid. Which means that, as long as GPGME will use GPG under the hood, it will work. If the dependency is ever reversed, GPGME will have to provide a get|set_keyserver for GPG to use. If both ever depend on a third tool, this third tool will have to provide such functions, an GPGME will use them as easily as GPG will do. Also, you could argue GPGME_KEYLIST_MODE_EXTERN is a useful extension in that it allows to make an offline application, or to optimize keylisting, or such things. But setting the keyserver is almost as useful : it allows to use a local keyserver, or to use some keyserver not synchronizing with the others (keyserver.pgp.net ?), etc. Finally, I understood the "made easy" as meaning "don't parse things you're almost sure to fail parsing correctly, and leave the harness of parsing to people who know GPG's output better than you, because they chose it". As a last statement, I believe (but that's only my humble opinion) that GPGME should offer as much options as GPG does, so that one doesn't have to hesitate between parsing GPG's output (developper-time-consuming, error-prone), and using GPGME (fast-use, secure, error-free). Here's the end of my plea. If others could say their opinion about this patch, maybe could that help choosing whether it should be integrated or not. Cheers, Leo From ekleog at gmail.com Tue Aug 21 01:01:52 2012 From: ekleog at gmail.com (Leo Gaspard) Date: Tue, 21 Aug 2012 01:01:52 +0200 Subject: [PATCH] Allow to set a context's keyserver Message-ID: <1345503712-6270-1-git-send-email-ekleog@gmail.com> * Added gpgme_get_keyserver and gpgme_set_keyserver to get/set the keyserver of a particular context ; * Modified the context so that it can stock the keyserver ; * Updated functions so that they take into account this new parameter. --- Sorry for spamming the mailing list, but I just noticed there were a few bugs on the patch I sent on 07/29. Now, the repository after applying the patch both compiles and runs flawlessly "make check". HTH, Leo src/context.h | 3 +++ src/engine-backend.h | 8 ++++---- src/engine-gpg.c | 32 ++++++++++++++++++++++---------- src/engine-gpgsm.c | 8 ++++---- src/engine.c | 17 +++++++++-------- src/engine.h | 11 +++++++---- src/export.c | 4 ++-- src/gpgme.c | 39 +++++++++++++++++++++++++++++++++++++++ src/keylist.c | 4 ++-- 9 files changed, 92 insertions(+), 34 deletions(-) diff --git a/src/context.h b/src/context.h index 69d8d9b..bec0af7 100644 --- a/src/context.h +++ b/src/context.h @@ -133,6 +133,9 @@ struct gpgme_context operation. */ struct fd_table fdt; struct gpgme_io_cbs io_cbs; + + /* The keyserver in use for the context. */ + char *keyserver; }; #endif /* CONTEXT_H */ diff --git a/src/engine-backend.h b/src/engine-backend.h index e540acb..bda55ad 100644 --- a/src/engine-backend.h +++ b/src/engine-backend.h @@ -76,19 +76,19 @@ struct engine_ops int use_armor, gpgme_ctx_t ctx /* FIXME */); gpgme_error_t (*export) (void *engine, const char *pattern, gpgme_export_mode_t mode, gpgme_data_t keydata, - int use_armor); + int use_armor, const char *keyserver); gpgme_error_t (*export_ext) (void *engine, const char *pattern[], gpgme_export_mode_t mode, gpgme_data_t keydata, - int use_armor); + int use_armor, const char *keyserver); gpgme_error_t (*genkey) (void *engine, gpgme_data_t help_data, int use_armor, gpgme_data_t pubkey, gpgme_data_t seckey); gpgme_error_t (*import) (void *engine, gpgme_data_t keydata, gpgme_key_t *keyarray); gpgme_error_t (*keylist) (void *engine, const char *pattern, - int secret_only, gpgme_keylist_mode_t mode); + int secret_only, gpgme_keylist_mode_t mode, const char *keyserver); gpgme_error_t (*keylist_ext) (void *engine, const char *pattern[], int secret_only, int reserved, - gpgme_keylist_mode_t mode); + gpgme_keylist_mode_t mode, const char *keyserver); gpgme_error_t (*sign) (void *engine, gpgme_data_t in, gpgme_data_t out, gpgme_sig_mode_t mode, int use_armor, int use_textmode, int include_certs, diff --git a/src/engine-gpg.c b/src/engine-gpg.c index cbb456e..badcaee 100644 --- a/src/engine-gpg.c +++ b/src/engine-gpg.c @@ -1719,7 +1719,7 @@ gpg_encrypt_sign (void *engine, gpgme_key_t recp[], static gpgme_error_t export_common (engine_gpg_t gpg, gpgme_export_mode_t mode, - gpgme_data_t keydata, int use_armor) + gpgme_data_t keydata, int use_armor, const char *keyserver) { gpgme_error_t err = 0; @@ -1741,6 +1741,12 @@ export_common (engine_gpg_t gpg, gpgme_export_mode_t mode, err = add_arg (gpg, "--export"); if (!err && use_armor) err = add_arg (gpg, "--armor"); + if (!err && keyserver) + { + err = add_arg (gpg, "--keyserver"); + if (!err) + err = add_arg (gpg, keyserver); + } if (!err) err = add_data (gpg, keydata, 1, 1); } @@ -1753,12 +1759,12 @@ export_common (engine_gpg_t gpg, gpgme_export_mode_t mode, static gpgme_error_t gpg_export (void *engine, const char *pattern, gpgme_export_mode_t mode, - gpgme_data_t keydata, int use_armor) + gpgme_data_t keydata, int use_armor, const char *keyserver) { engine_gpg_t gpg = engine; gpgme_error_t err; - err = export_common (gpg, mode, keydata, use_armor); + err = export_common (gpg, mode, keydata, use_armor, keyserver); if (!err && pattern && *pattern) err = add_arg (gpg, pattern); @@ -1772,12 +1778,12 @@ gpg_export (void *engine, const char *pattern, gpgme_export_mode_t mode, static gpgme_error_t gpg_export_ext (void *engine, const char *pattern[], gpgme_export_mode_t mode, - gpgme_data_t keydata, int use_armor) + gpgme_data_t keydata, int use_armor, const char *keyserver) { engine_gpg_t gpg = engine; gpgme_error_t err; - err = export_common (gpg, mode, keydata, use_armor); + err = export_common (gpg, mode, keydata, use_armor, keyserver); if (pattern) { @@ -2129,7 +2135,7 @@ gpg_keylist_preprocess (char *line, char **r_line) static gpg_error_t gpg_keylist_build_options (engine_gpg_t gpg, int secret_only, - gpgme_keylist_mode_t mode) + gpgme_keylist_mode_t mode, const char *keyserver) { gpg_error_t err; @@ -2171,6 +2177,12 @@ gpg_keylist_build_options (engine_gpg_t gpg, int secret_only, err = add_arg (gpg, "--search-keys"); gpg->colon.preprocess_fnc = gpg_keylist_preprocess; } + if (!err && keyserver) + { + err = add_arg (gpg, "--keyserver"); + if (!err) + err = add_arg (gpg, keyserver); + } } else { @@ -2188,12 +2200,12 @@ gpg_keylist_build_options (engine_gpg_t gpg, int secret_only, static gpgme_error_t gpg_keylist (void *engine, const char *pattern, int secret_only, - gpgme_keylist_mode_t mode) + gpgme_keylist_mode_t mode, const char *keyserver) { engine_gpg_t gpg = engine; gpgme_error_t err; - err = gpg_keylist_build_options (gpg, secret_only, mode); + err = gpg_keylist_build_options (gpg, secret_only, mode, keyserver); if (!err && pattern && *pattern) err = add_arg (gpg, pattern); @@ -2207,7 +2219,7 @@ gpg_keylist (void *engine, const char *pattern, int secret_only, static gpgme_error_t gpg_keylist_ext (void *engine, const char *pattern[], int secret_only, - int reserved, gpgme_keylist_mode_t mode) + int reserved, gpgme_keylist_mode_t mode, const char *keyserver) { engine_gpg_t gpg = engine; gpgme_error_t err; @@ -2215,7 +2227,7 @@ gpg_keylist_ext (void *engine, const char *pattern[], int secret_only, if (reserved) return gpg_error (GPG_ERR_INV_VALUE); - err = gpg_keylist_build_options (gpg, secret_only, mode); + err = gpg_keylist_build_options (gpg, secret_only, mode, keyserver); if (pattern) { diff --git a/src/engine-gpgsm.c b/src/engine-gpgsm.c index 0620458..0489773 100644 --- a/src/engine-gpgsm.c +++ b/src/engine-gpgsm.c @@ -1264,7 +1264,7 @@ gpgsm_encrypt (void *engine, gpgme_key_t recp[], gpgme_encrypt_flags_t flags, static gpgme_error_t gpgsm_export (void *engine, const char *pattern, gpgme_export_mode_t mode, - gpgme_data_t keydata, int use_armor) + gpgme_data_t keydata, int use_armor, const char *keyserver) { engine_gpgsm_t gpgsm = engine; gpgme_error_t err = 0; @@ -1302,7 +1302,7 @@ gpgsm_export (void *engine, const char *pattern, gpgme_export_mode_t mode, static gpgme_error_t gpgsm_export_ext (void *engine, const char *pattern[], gpgme_export_mode_t mode, - gpgme_data_t keydata, int use_armor) + gpgme_data_t keydata, int use_armor, const char *keyserver) { engine_gpgsm_t gpgsm = engine; gpgme_error_t err = 0; @@ -1526,7 +1526,7 @@ gpgsm_import (void *engine, gpgme_data_t keydata, gpgme_key_t *keyarray) static gpgme_error_t gpgsm_keylist (void *engine, const char *pattern, int secret_only, - gpgme_keylist_mode_t mode) + gpgme_keylist_mode_t mode, const char *keyserver) { engine_gpgsm_t gpgsm = engine; char *line; @@ -1608,7 +1608,7 @@ gpgsm_keylist (void *engine, const char *pattern, int secret_only, static gpgme_error_t gpgsm_keylist_ext (void *engine, const char *pattern[], int secret_only, - int reserved, gpgme_keylist_mode_t mode) + int reserved, gpgme_keylist_mode_t mode, const char *keyserver) { engine_gpgsm_t gpgsm = engine; char *line; diff --git a/src/engine.c b/src/engine.c index 1244dd3..2474b44 100644 --- a/src/engine.c +++ b/src/engine.c @@ -662,7 +662,7 @@ _gpgme_engine_op_encrypt_sign (engine_t engine, gpgme_key_t recp[], gpgme_error_t _gpgme_engine_op_export (engine_t engine, const char *pattern, gpgme_export_mode_t mode, gpgme_data_t keydata, - int use_armor) + int use_armor, const char *keyserver) { if (!engine) return gpg_error (GPG_ERR_INV_VALUE); @@ -671,14 +671,14 @@ _gpgme_engine_op_export (engine_t engine, const char *pattern, return gpg_error (GPG_ERR_NOT_IMPLEMENTED); return (*engine->ops->export) (engine->engine, pattern, mode, - keydata, use_armor); + keydata, use_armor, keyserver); } gpgme_error_t _gpgme_engine_op_export_ext (engine_t engine, const char *pattern[], unsigned int reserved, gpgme_data_t keydata, - int use_armor) + int use_armor, const char *keyserver) { if (!engine) return gpg_error (GPG_ERR_INV_VALUE); @@ -687,7 +687,7 @@ _gpgme_engine_op_export_ext (engine_t engine, const char *pattern[], return gpg_error (GPG_ERR_NOT_IMPLEMENTED); return (*engine->ops->export_ext) (engine->engine, pattern, reserved, - keydata, use_armor); + keydata, use_armor, keyserver); } @@ -723,7 +723,7 @@ _gpgme_engine_op_import (engine_t engine, gpgme_data_t keydata, gpgme_error_t _gpgme_engine_op_keylist (engine_t engine, const char *pattern, - int secret_only, gpgme_keylist_mode_t mode) + int secret_only, gpgme_keylist_mode_t mode, const char *keyserver) { if (!engine) return gpg_error (GPG_ERR_INV_VALUE); @@ -731,14 +731,15 @@ _gpgme_engine_op_keylist (engine_t engine, const char *pattern, if (!engine->ops->keylist) return gpg_error (GPG_ERR_NOT_IMPLEMENTED); - return (*engine->ops->keylist) (engine->engine, pattern, secret_only, mode); + return (*engine->ops->keylist) (engine->engine, pattern, secret_only, mode, + keyserver); } gpgme_error_t _gpgme_engine_op_keylist_ext (engine_t engine, const char *pattern[], int secret_only, int reserved, - gpgme_keylist_mode_t mode) + gpgme_keylist_mode_t mode, const char *keyserver) { if (!engine) return gpg_error (GPG_ERR_INV_VALUE); @@ -747,7 +748,7 @@ _gpgme_engine_op_keylist_ext (engine_t engine, const char *pattern[], return gpg_error (GPG_ERR_NOT_IMPLEMENTED); return (*engine->ops->keylist_ext) (engine->engine, pattern, secret_only, - reserved, mode); + reserved, mode, keyserver); } diff --git a/src/engine.h b/src/engine.h index dfc73ac..2db7fdb 100644 --- a/src/engine.h +++ b/src/engine.h @@ -97,12 +97,13 @@ gpgme_error_t _gpgme_engine_op_encrypt_sign (engine_t engine, gpgme_ctx_t ctx /* FIXME */); gpgme_error_t _gpgme_engine_op_export (engine_t engine, const char *pattern, gpgme_export_mode_t mode, - gpgme_data_t keydata, int use_armor); + gpgme_data_t keydata, int use_armor, const char *keyserver); gpgme_error_t _gpgme_engine_op_export_ext (engine_t engine, const char *pattern[], gpgme_export_mode_t mode, gpgme_data_t keydata, - int use_armor); + int use_armor, + const char *keyserver); gpgme_error_t _gpgme_engine_op_genkey (engine_t engine, gpgme_data_t help_data, int use_armor, gpgme_data_t pubkey, @@ -113,12 +114,14 @@ gpgme_error_t _gpgme_engine_op_import (engine_t engine, gpgme_error_t _gpgme_engine_op_keylist (engine_t engine, const char *pattern, int secret_only, - gpgme_keylist_mode_t mode); + gpgme_keylist_mode_t mode, + const char *keyserver); gpgme_error_t _gpgme_engine_op_keylist_ext (engine_t engine, const char *pattern[], int secret_only, int reserved, - gpgme_keylist_mode_t mode); + gpgme_keylist_mode_t mode, + const char *keyserver); gpgme_error_t _gpgme_engine_op_sign (engine_t engine, gpgme_data_t in, gpgme_data_t out, gpgme_sig_mode_t mode, int use_armor, int use_textmode, diff --git a/src/export.c b/src/export.c index 9c1c79c..4d1dd1c 100644 --- a/src/export.c +++ b/src/export.c @@ -67,7 +67,7 @@ export_start (gpgme_ctx_t ctx, int synchronous, const char *pattern, _gpgme_engine_set_status_handler (ctx->engine, export_status_handler, ctx); return _gpgme_engine_op_export (ctx->engine, pattern, mode, keydata, - ctx->use_armor); + ctx->use_armor, ctx->keyserver); } @@ -137,7 +137,7 @@ export_ext_start (gpgme_ctx_t ctx, int synchronous, const char *pattern[], _gpgme_engine_set_status_handler (ctx->engine, export_status_handler, ctx); return _gpgme_engine_op_export_ext (ctx->engine, pattern, mode, keydata, - ctx->use_armor); + ctx->use_armor, ctx->keyserver); } diff --git a/src/gpgme.c b/src/gpgme.c index 927b2a0..d3210a5 100644 --- a/src/gpgme.c +++ b/src/gpgme.c @@ -210,6 +210,8 @@ gpgme_release (gpgme_ctx_t ctx) if (ctx->lc_messages) free (ctx->lc_messages); _gpgme_engine_info_release (ctx->engine_info); + if (ctx->keyserver) + free (ctx->keyserver); DESTROY_LOCK (ctx->lock); free (ctx); } @@ -406,6 +408,43 @@ gpgme_get_armor (gpgme_ctx_t ctx) } +/* Defines the keyserver for all keyserver-related operations. */ +gpgme_error_t +gpgme_set_keyserver (gpgme_ctx_t ctx, const char *keyserver) +{ + TRACE_BEG1 (DEBUG_CTX, "gpgme_set_keyserver", ctx, "keyserver=\"%s\"", + keyserver); + + if (!ctx) + return gpg_error (GPG_ERR_INV_VALUE); + + char *keyserver_save = ctx->keyserver; + + // FIXME: Add some checks before setting the keyserver ? (e.g. it is a valid + // keyserver, online, pingable... or even a valid url ?) + ctx->keyserver = strdup (keyserver); + + if (!ctx->keyserver) + { + ctx->keyserver = keyserver_save; + return TRACE_ERR (gpg_error_from_errno (errno)); + } + + if (keyserver_save) + free (keyserver_save); + return 0; +} + +/* Return the keyserver in use. Its content should *not* be modified. */ +const char * +gpgme_get_keyserver (gpgme_ctx_t ctx) +{ + TRACE1 (DEBUG_CTX, "gpgme_get_armor", ctx, "ctx->keyserver=\"%s\"", + ctx->keyserver); + return ctx->keyserver; +} + + /* Enable or disable the use of the special textmode. Textmode is for example used for the RFC2015 signatures; note that the updated RFC 3156 mandates that the MUA does some preparations so that textmode diff --git a/src/keylist.c b/src/keylist.c index 29e30a0..2ec5886 100644 --- a/src/keylist.c +++ b/src/keylist.c @@ -884,7 +884,7 @@ gpgme_op_keylist_start (gpgme_ctx_t ctx, const char *pattern, int secret_only) return TRACE_ERR (err); err = _gpgme_engine_op_keylist (ctx->engine, pattern, secret_only, - ctx->keylist_mode); + ctx->keylist_mode, ctx->keyserver); return TRACE_ERR (err); } @@ -923,7 +923,7 @@ gpgme_op_keylist_ext_start (gpgme_ctx_t ctx, const char *pattern[], return TRACE_ERR (err); err = _gpgme_engine_op_keylist_ext (ctx->engine, pattern, secret_only, - reserved, ctx->keylist_mode); + reserved, ctx->keylist_mode, ctx->keyserver); return TRACE_ERR (err); } -- 1.7.11.5 From rjh at sixdemonbag.org Tue Aug 21 01:52:22 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 20 Aug 2012 19:52:22 -0400 Subject: Keysigning party methodology: Sassaman-Efficient & centralizing printing In-Reply-To: <20120820174748.GA27206@orbis-terrarum.net> References: <20120820174748.GA27206@orbis-terrarum.net> Message-ID: <5032CDB6.3030900@sixdemonbag.org> On 08/20/2012 01:47 PM, Robin H. Johnson wrote: > I've seen some prior mentions of problems in crypto-cool parties, but > I'd like to know if this means that the Sassaman-Efficient method should > NOT be used. I would recommend it not be used. Frankly, the administrative overhead is too much. There are too many points of failure, and for not much of a speed improvement anyway. "At the event" step 4 is not going to be much faster than if, instead of just letting people verify ID, you also hand a slip of paper with your name and key fingerprint on it. When it comes to these things, my experience is the simpler the protocol the more likely it is that it will be executed successfully. From taffit at debian.org Wed Aug 22 18:43:55 2012 From: taffit at debian.org (=?UTF-8?B?RGF2aWQgUHLDqXZvdA==?=) Date: Wed, 22 Aug 2012 12:43:55 -0400 Subject: [STABLE-BRANCH-1-4 PATCHES] translation related helper, and a few typos In-Reply-To: <50200521.5030302@debian.org> References: <50200521.5030302@debian.org> Message-ID: <50350C4B.7040604@debian.org> Hi, Le 06/08/2012 13:55, David Pr?vot a ?crit : > As agreed with Ga?l Qu?ri, the former translator, I'm updating the > French translation of gnupg. French translation now up to date for STABLE-BRANCH-1-4, STABLE-BRANCH-2-0, and master branches. I'll send the updated PO files to after this ones and the similar ones I'm about to post to -devel. > [PATCH 3/3] Three minor typos spotted during the translation update and > review. Adding a 4th patch of the same kind, attached, fixing Syntax consistency. > Is it OK to send you patches attached to this list like I did, or do you > prefer a real ?git send-email? stuff, maybe elsewhere? I'll ?git send-email? the similar patches against STABLE-BRANCH-2-0 and master after that message. Regards David -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-typos-spotted-during-translations.patch Type: text/x-diff Size: 833 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From taffit at debian.org Wed Aug 22 18:53:57 2012 From: taffit at debian.org (=?UTF-8?q?David=20Pr=C3=A9vot?=) Date: Wed, 22 Aug 2012 12:53:57 -0400 Subject: [PATCH 3/3] Fix typos spotted during translations In-Reply-To: <1345654437-11564-1-git-send-email-taffit@debian.org> References: <50200521.5030302@debian.org> <1345654437-11564-1-git-send-email-taffit@debian.org> Message-ID: <1345654437-11564-4-git-send-email-taffit@debian.org> agent/genkey.c: s/to to/to/ sm/*.c: s/failed to allocated/failed to allocate/ sm/certlist.c: s/should have not/should not have/ Consistency fix: * g10/gpg.c, kbx/kbxutil.c, sm/gpgsm.c: uppercase after Syntax --- agent/genkey.c | 2 +- g10/gpg.c | 4 ++-- kbx/kbxutil.c | 2 +- sm/certchain.c | 6 +++--- sm/certlist.c | 8 ++++---- sm/decrypt.c | 2 +- sm/encrypt.c | 2 +- sm/gpgsm.c | 4 ++-- sm/sign.c | 2 +- sm/verify.c | 2 +- 10 files changed, 17 insertions(+), 17 deletions(-) diff --git a/agent/genkey.c b/agent/genkey.c index 176e77d..d5af9e0 100644 --- a/agent/genkey.c +++ b/agent/genkey.c @@ -306,7 +306,7 @@ agent_genkey (ctrl_t ctrl, const char *keyparam, size_t keyparamlen, /* Get the passphrase now, cause key generation may take a while. */ { const char *text1 = _("Please enter the passphrase to%0A" - "to protect your new key"); + "protect your new key"); const char *text2 = _("Please re-enter this passphrase"); const char *initial_errtext = NULL; diff --git a/g10/gpg.c b/g10/gpg.c index 7e648fb..6e55b44 100644 --- a/g10/gpg.c +++ b/g10/gpg.c @@ -837,8 +837,8 @@ my_strusage( int level ) break; case 41: p = _("Syntax: gpg [options] [files]\n" - "sign, check, encrypt or decrypt\n" - "default operation depends on the input data\n"); + "Sign, check, encrypt or decrypt\n" + "Default operation depends on the input data\n"); break; case 31: p = "\nHome: "; break; diff --git a/kbx/kbxutil.c b/kbx/kbxutil.c index 4592811..f0921b7 100644 --- a/kbx/kbxutil.c +++ b/kbx/kbxutil.c @@ -118,7 +118,7 @@ my_strusage( int level ) break; case 41: p = _("Syntax: kbxutil [options] [files]\n" - "list, export, import Keybox data\n"); + "List, export, import Keybox data\n"); break; diff --git a/sm/certchain.c b/sm/certchain.c index f4ad214..0023a98 100644 --- a/sm/certchain.c +++ b/sm/certchain.c @@ -756,7 +756,7 @@ gpgsm_walk_cert_chain (ctrl_t ctrl, ksba_cert_t start, ksba_cert_t *r_next) *r_next = NULL; if (!kh) { - log_error (_("failed to allocated keyDB handle\n")); + log_error (_("failed to allocate keyDB handle\n")); rc = gpg_error (GPG_ERR_GENERAL); goto leave; } @@ -1249,7 +1249,7 @@ do_validate_chain (ctrl_t ctrl, ksba_cert_t cert, ksba_isotime_t checktime_arg, kh = keydb_new (0); if (!kh) { - log_error (_("failed to allocated keyDB handle\n")); + log_error (_("failed to allocate keyDB handle\n")); rc = gpg_error (GPG_ERR_GENERAL); goto leave; } @@ -1853,7 +1853,7 @@ gpgsm_basic_cert_check (ctrl_t ctrl, ksba_cert_t cert) kh = keydb_new (0); if (!kh) { - log_error (_("failed to allocated keyDB handle\n")); + log_error (_("failed to allocate keyDB handle\n")); rc = gpg_error (GPG_ERR_GENERAL); goto leave; } diff --git a/sm/certlist.c b/sm/certlist.c index 4137437..bfacaa2 100644 --- a/sm/certlist.c +++ b/sm/certlist.c @@ -139,7 +139,7 @@ cert_usage_p (ksba_cert_t cert, int mode) { if ((use & (KSBA_KEYUSAGE_KEY_CERT_SIGN))) return 0; - log_info (_("certificate should have not " + log_info (_("certificate should not have " "been used for certification\n")); return gpg_error (GPG_ERR_WRONG_KEY_USAGE); } @@ -151,7 +151,7 @@ cert_usage_p (ksba_cert_t cert, int mode) || (use & (KSBA_KEYUSAGE_KEY_CERT_SIGN |KSBA_KEYUSAGE_CRL_SIGN)))) return 0; - log_info (_("certificate should have not " + log_info (_("certificate should not have " "been used for OCSP response signing\n")); return gpg_error (GPG_ERR_WRONG_KEY_USAGE); } @@ -162,8 +162,8 @@ cert_usage_p (ksba_cert_t cert, int mode) ) return 0; - log_info (mode==3? _("certificate should have not been used for encryption\n"): - mode==2? _("certificate should have not been used for signing\n"): + log_info (mode==3? _("certificate should not have been used for encryption\n"): + mode==2? _("certificate should not have been used for signing\n"): mode==1? _("certificate is not usable for encryption\n"): _("certificate is not usable for signing\n")); return gpg_error (GPG_ERR_WRONG_KEY_USAGE); diff --git a/sm/decrypt.c b/sm/decrypt.c index de02551..841fbd6 100644 --- a/sm/decrypt.c +++ b/sm/decrypt.c @@ -258,7 +258,7 @@ gpgsm_decrypt (ctrl_t ctrl, int in_fd, FILE *out_fp) kh = keydb_new (0); if (!kh) { - log_error (_("failed to allocated keyDB handle\n")); + log_error (_("failed to allocate keyDB handle\n")); rc = gpg_error (GPG_ERR_GENERAL); goto leave; } diff --git a/sm/encrypt.c b/sm/encrypt.c index a526a64..42a438a 100644 --- a/sm/encrypt.c +++ b/sm/encrypt.c @@ -332,7 +332,7 @@ gpgsm_encrypt (ctrl_t ctrl, certlist_t recplist, int data_fd, FILE *out_fp) kh = keydb_new (0); if (!kh) { - log_error (_("failed to allocated keyDB handle\n")); + log_error (_("failed to allocate keyDB handle\n")); rc = gpg_error (GPG_ERR_GENERAL); goto leave; } diff --git a/sm/gpgsm.c b/sm/gpgsm.c index 484ce9d..2470df0 100644 --- a/sm/gpgsm.c +++ b/sm/gpgsm.c @@ -523,8 +523,8 @@ my_strusage( int level ) break; case 41: p = _("Syntax: gpgsm [options] [files]\n" - "sign, check, encrypt or decrypt using the S/MIME protocol\n" - "default operation depends on the input data\n"); + "Sign, check, encrypt or decrypt using the S/MIME protocol\n" + "Default operation depends on the input data\n"); break; case 20: diff --git a/sm/sign.c b/sm/sign.c index a9d4990..c173740 100644 --- a/sm/sign.c +++ b/sm/sign.c @@ -332,7 +332,7 @@ gpgsm_sign (ctrl_t ctrl, certlist_t signerlist, kh = keydb_new (0); if (!kh) { - log_error (_("failed to allocated keyDB handle\n")); + log_error (_("failed to allocate keyDB handle\n")); rc = gpg_error (GPG_ERR_GENERAL); goto leave; } diff --git a/sm/verify.c b/sm/verify.c index 6bc44d2..0444dfe 100644 --- a/sm/verify.c +++ b/sm/verify.c @@ -110,7 +110,7 @@ gpgsm_verify (ctrl_t ctrl, int in_fd, int data_fd, FILE *out_fp) kh = keydb_new (0); if (!kh) { - log_error (_("failed to allocated keyDB handle\n")); + log_error (_("failed to allocate keyDB handle\n")); rc = gpg_error (GPG_ERR_GENERAL); goto leave; } -- 1.7.10.4 From taffit at debian.org Wed Aug 22 18:53:55 2012 From: taffit at debian.org (=?UTF-8?q?David=20Pr=C3=A9vot?=) Date: Wed, 22 Aug 2012 12:53:55 -0400 Subject: [PATCH 1/3] Keep previous msgids of translated messages In-Reply-To: <1345654437-11564-1-git-send-email-taffit@debian.org> References: <50200521.5030302@debian.org> <1345654437-11564-1-git-send-email-taffit@debian.org> Message-ID: <1345654437-11564-2-git-send-email-taffit@debian.org> --- po/Makefile.in.in | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/po/Makefile.in.in b/po/Makefile.in.in index fecf500..eb68ea2 100644 --- a/po/Makefile.in.in +++ b/po/Makefile.in.in @@ -56,8 +56,8 @@ XGETTEXT_ = @XGETTEXT@ XGETTEXT_no = @XGETTEXT@ XGETTEXT_yes = @XGETTEXT_015@ XGETTEXT = $(XGETTEXT_$(USE_MSGCTXT)) -MSGMERGE = msgmerge -MSGMERGE_UPDATE = @MSGMERGE@ --update +MSGMERGE = msgmerge --previous +MSGMERGE_UPDATE = @MSGMERGE@ --previous --update MSGINIT = msginit MSGCONV = msgconv MSGFILTER = msgfilter -- 1.7.10.4 From taffit at debian.org Wed Aug 22 18:53:54 2012 From: taffit at debian.org (=?UTF-8?q?David=20Pr=C3=A9vot?=) Date: Wed, 22 Aug 2012 12:53:54 -0400 Subject: [STABLE-BRANCH-2-0 PATCHES] translation related helper, and a few typos In-Reply-To: <50200521.5030302@debian.org> References: <50200521.5030302@debian.org> Message-ID: <1345654437-11564-1-git-send-email-taffit@debian.org> Hi, As previously announced, please find attached some patches against the STABLE-BRANCH-2-0 branch. Regards David From taffit at debian.org Wed Aug 22 18:53:56 2012 From: taffit at debian.org (=?UTF-8?q?David=20Pr=C3=A9vot?=) Date: Wed, 22 Aug 2012 12:53:56 -0400 Subject: [PATCH 2/3] Actually show translators comments in PO files In-Reply-To: <1345654437-11564-1-git-send-email-taffit@debian.org> References: <50200521.5030302@debian.org> <1345654437-11564-1-git-send-email-taffit@debian.org> Message-ID: <1345654437-11564-3-git-send-email-taffit@debian.org> --- agent/call-pinentry.c | 2 +- g10/pkclist.c | 2 +- g10/trustdb.c | 10 +++++----- scd/app-openpgp.c | 3 +-- 4 files changed, 8 insertions(+), 9 deletions(-) diff --git a/agent/call-pinentry.c b/agent/call-pinentry.c index ad1bd03..2483019 100644 --- a/agent/call-pinentry.c +++ b/agent/call-pinentry.c @@ -770,7 +770,7 @@ agent_askpin (ctrl_t ctrl, if (errtext) { - /* TRANLATORS: The string is appended to an error message in + /* TRANSLATORS: The string is appended to an error message in the pinentry. The %s is the actual error message, the two %d give the current and maximum number of tries. */ snprintf (line, DIM(line)-1, _("SETERROR %s (try %d of %d)"), diff --git a/g10/pkclist.c b/g10/pkclist.c index 7ad9755..1368bc2 100644 --- a/g10/pkclist.c +++ b/g10/pkclist.c @@ -191,7 +191,7 @@ do_edit_ownertrust (PKT_public_key *pk, int mode, for(;;) { /* A string with valid answers. - Note to translators: These are the allowed answers in lower and + TRANSLATORS: These are the allowed answers in lower and uppercase. Below you will find the matching strings which should be translated accordingly and the letter changed to match the one in the answer string. diff --git a/g10/trustdb.c b/g10/trustdb.c index fe8b833..dedb18c 100644 --- a/g10/trustdb.c +++ b/g10/trustdb.c @@ -505,7 +505,11 @@ trust_letter (unsigned int value) } } -/* NOTE TO TRANSLATOR: these strings are similar to those in +const char * +uid_trust_string_fixed(PKT_public_key *key,PKT_user_id *uid) +{ + if(!key && !uid) +/* TRANSLATORS: these strings are similar to those in trust_value_to_string(), but are a fixed length. This is needed to make attractive information listings where columns line up properly. The value "10" should be the length of the strings you @@ -513,10 +517,6 @@ trust_letter (unsigned int value) It gets passed to atoi() so everything after the number is essentially a comment and need not be translated. Either key and uid are both NULL, or neither are NULL. */ -const char * -uid_trust_string_fixed(PKT_public_key *key,PKT_user_id *uid) -{ - if(!key && !uid) return _("10 translator see trustdb.c:uid_trust_string_fixed"); else if(uid->is_revoked || (key && key->is_revoked)) return _("[ revoked]"); diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index e50297d..2a85250 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -2081,8 +2081,7 @@ do_change_pin (app_t app, ctrl_t ctrl, const char *chvnostr, /* TRANSLATORS: Do not translate the "|*|" prefixes but keep it at the start of the string. We need this elsewhere to get some infos on the string. */ - rc = pincb (pincb_arg, - set_resetcode? _("|RN|New Reset Code") : + rc = pincb (pincb_arg, set_resetcode? _("|RN|New Reset Code") : chvno == 3? _("|AN|New Admin PIN") : _("|N|New PIN"), &pinvalue); if (rc) -- 1.7.10.4 From taffit at debian.org Wed Aug 22 18:54:35 2012 From: taffit at debian.org (=?UTF-8?q?David=20Pr=C3=A9vot?=) Date: Wed, 22 Aug 2012 12:54:35 -0400 Subject: [master PATCHES] translation related helper, and a few typos In-Reply-To: <50200521.5030302@debian.org> References: <50200521.5030302@debian.org> Message-ID: <1345654478-11634-1-git-send-email-taffit@debian.org> Hi, As previously announced, please find attached some patches against the master branch. Regards David From taffit at debian.org Wed Aug 22 18:54:36 2012 From: taffit at debian.org (=?UTF-8?q?David=20Pr=C3=A9vot?=) Date: Wed, 22 Aug 2012 12:54:36 -0400 Subject: [PATCH 1/3] Keep previous msgids of translated messages In-Reply-To: <1345654478-11634-1-git-send-email-taffit@debian.org> References: <50200521.5030302@debian.org> <1345654478-11634-1-git-send-email-taffit@debian.org> Message-ID: <1345654478-11634-2-git-send-email-taffit@debian.org> --- po/Makefile.in.in | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/po/Makefile.in.in b/po/Makefile.in.in index fecf500..eb68ea2 100644 --- a/po/Makefile.in.in +++ b/po/Makefile.in.in @@ -56,8 +56,8 @@ XGETTEXT_ = @XGETTEXT@ XGETTEXT_no = @XGETTEXT@ XGETTEXT_yes = @XGETTEXT_015@ XGETTEXT = $(XGETTEXT_$(USE_MSGCTXT)) -MSGMERGE = msgmerge -MSGMERGE_UPDATE = @MSGMERGE@ --update +MSGMERGE = msgmerge --previous +MSGMERGE_UPDATE = @MSGMERGE@ --previous --update MSGINIT = msginit MSGCONV = msgconv MSGFILTER = msgfilter -- 1.7.10.4 From taffit at debian.org Wed Aug 22 18:54:38 2012 From: taffit at debian.org (=?UTF-8?q?David=20Pr=C3=A9vot?=) Date: Wed, 22 Aug 2012 12:54:38 -0400 Subject: [PATCH 3/3] Fix typos spotted during translations In-Reply-To: <1345654478-11634-1-git-send-email-taffit@debian.org> References: <50200521.5030302@debian.org> <1345654478-11634-1-git-send-email-taffit@debian.org> Message-ID: <1345654478-11634-4-git-send-email-taffit@debian.org> * agent/genkey.c: s/to to/to/ * sm/*.c: s/failed to allocated/failed to allocate/ * sm/certlist.c, ./dirmngr/validate.c: s/should have not/should not have/ * g10/seskey.c: missing closing parenthesis * dirmngr/crlcache.c: s/may has/may have/ Consistency fix: * g10/gpg.c, kbx/kbxutil.c, sm/gpgsm.c: uppercase after Syntax * dirmngr/dirmngr_ldap: no period in Syntax * dirmngr/dirmngr-client.c: infinitive for option description: s/certificates are expected/expect certificates/ --- agent/genkey.c | 2 +- dirmngr/crlcache.c | 2 +- dirmngr/dirmngr-client.c | 2 +- dirmngr/dirmngr_ldap.c | 4 ++-- dirmngr/validate.c | 10 +++++----- g10/gpg.c | 4 ++-- g10/seskey.c | 2 +- kbx/kbxutil.c | 2 +- sm/certchain.c | 6 +++--- sm/certlist.c | 8 ++++---- sm/decrypt.c | 2 +- sm/encrypt.c | 2 +- sm/gpgsm.c | 4 ++-- sm/sign.c | 2 +- sm/verify.c | 2 +- 15 files changed, 27 insertions(+), 27 deletions(-) diff --git a/agent/genkey.c b/agent/genkey.c index 20b9230..c040f13 100644 --- a/agent/genkey.c +++ b/agent/genkey.c @@ -404,7 +404,7 @@ agent_genkey (ctrl_t ctrl, const char *cache_nonce, else rc = agent_ask_new_passphrase (ctrl, _("Please enter the passphrase to%0A" - "to protect your new key"), + "protect your new key"), &passphrase); if (rc) return rc; diff --git a/dirmngr/crlcache.c b/dirmngr/crlcache.c index a4d8e80..8505f9c 100644 --- a/dirmngr/crlcache.c +++ b/dirmngr/crlcache.c @@ -2301,7 +2301,7 @@ list_one_crl_entry (crl_cache_t cache, crl_cache_entry_t e, estream_t fp) return gpg_error (GPG_ERR_GENERAL); if (!e->dbfile_checked) - es_fprintf (fp, _(" ERROR: This cached CRL may has been tampered with!\n")); + es_fprintf (fp, _(" ERROR: This cached CRL may have been tampered with!\n")); es_putc ('\n', fp); diff --git a/dirmngr/dirmngr-client.c b/dirmngr/dirmngr-client.c index 65d5a84..21f7743 100644 --- a/dirmngr/dirmngr-client.c +++ b/dirmngr/dirmngr-client.c @@ -76,7 +76,7 @@ static ARGPARSE_OPTS opts[] = { { oUrl, "url", 0, N_("expect an URL for --lookup")}, { oLoadCRL, "load-crl", 0, N_("load a CRL into the dirmngr")}, { oSquidMode,"squid-mode",0, N_("special mode for use by Squid")}, - { oPEM, "pem", 0, N_("certificates are expected in PEM format")}, + { oPEM, "pem", 0, N_("expect certificates in PEM format")}, { oForceDefaultResponder, "force-default-responder", 0, N_("force the use of the default OCSP responder")}, { 0, NULL, 0, NULL } diff --git a/dirmngr/dirmngr_ldap.c b/dirmngr/dirmngr_ldap.c index e17d262..1b513ea 100644 --- a/dirmngr/dirmngr_ldap.c +++ b/dirmngr/dirmngr_ldap.c @@ -203,8 +203,8 @@ my_strusage (int level) break; case 41: p = _("Syntax: dirmngr_ldap [options] [URL]\n" - "Internal LDAP helper for Dirmngr.\n" - "Interface and options may change without notice.\n"); + "Internal LDAP helper for Dirmngr\n" + "Interface and options may change without notice\n"); break; default: p = NULL; diff --git a/dirmngr/validate.c b/dirmngr/validate.c index 3ef676a..024708b 100644 --- a/dirmngr/validate.c +++ b/dirmngr/validate.c @@ -1096,7 +1096,7 @@ cert_usage_p (ksba_cert_t cert, int mode) { if ((use & (KSBA_KEYUSAGE_KEY_CERT_SIGN))) return 0; - log_info (_("certificate should have not " + log_info (_("certificate should not have " "been used for certification\n")); return gpg_error (GPG_ERR_WRONG_KEY_USAGE); } @@ -1108,7 +1108,7 @@ cert_usage_p (ksba_cert_t cert, int mode) || (use & (KSBA_KEYUSAGE_KEY_CERT_SIGN |KSBA_KEYUSAGE_CRL_SIGN)))) return 0; - log_info (_("certificate should have not " + log_info (_("certificate should not have " "been used for OCSP response signing\n")); return gpg_error (GPG_ERR_WRONG_KEY_USAGE); } @@ -1117,7 +1117,7 @@ cert_usage_p (ksba_cert_t cert, int mode) { if ((use & (KSBA_KEYUSAGE_CRL_SIGN))) return 0; - log_info (_("certificate should have not " + log_info (_("certificate should not have " "been used for CRL signing\n")); return gpg_error (GPG_ERR_WRONG_KEY_USAGE); } @@ -1128,9 +1128,9 @@ cert_usage_p (ksba_cert_t cert, int mode) ) return 0; - log_info (mode==3? _("certificate should have not been used " + log_info (mode==3? _("certificate should not have been used " "for encryption\n"): - mode==2? _("certificate should have not been used for signing\n"): + mode==2? _("certificate should not have been used for signing\n"): mode==1? _("certificate is not usable for encryption\n"): _("certificate is not usable for signing\n")); return gpg_error (GPG_ERR_WRONG_KEY_USAGE); diff --git a/g10/gpg.c b/g10/gpg.c index c8dbbfe..b614a94 100644 --- a/g10/gpg.c +++ b/g10/gpg.c @@ -845,8 +845,8 @@ my_strusage( int level ) break; case 41: p = _("Syntax: gpg [options] [files]\n" - "sign, check, encrypt or decrypt\n" - "default operation depends on the input data\n"); + "Sign, check, encrypt or decrypt\n" + "Default operation depends on the input data\n"); break; case 31: p = "\nHome: "; break; diff --git a/g10/seskey.c b/g10/seskey.c index 93a809d..ac6e6d6 100644 --- a/g10/seskey.c +++ b/g10/seskey.c @@ -310,7 +310,7 @@ encode_md_value (PKT_public_key *pk, gcry_md_hd_t md, int hash_algo) if (mdlen < qbits/8) { log_error (_("%s key %s requires a %zu bit or larger hash " - "(hash is %s\n"), + "(hash is %s)\n"), gcry_pk_algo_name (pkalgo), keystr_from_pk(pk), qbits, gcry_md_algo_name (hash_algo)); diff --git a/kbx/kbxutil.c b/kbx/kbxutil.c index c9d5681..62e3dbe 100644 --- a/kbx/kbxutil.c +++ b/kbx/kbxutil.c @@ -118,7 +118,7 @@ my_strusage( int level ) break; case 41: p = _("Syntax: kbxutil [options] [files]\n" - "list, export, import Keybox data\n"); + "List, export, import Keybox data\n"); break; diff --git a/sm/certchain.c b/sm/certchain.c index 18744b1..b51291d 100644 --- a/sm/certchain.c +++ b/sm/certchain.c @@ -756,7 +756,7 @@ gpgsm_walk_cert_chain (ctrl_t ctrl, ksba_cert_t start, ksba_cert_t *r_next) *r_next = NULL; if (!kh) { - log_error (_("failed to allocated keyDB handle\n")); + log_error (_("failed to allocate keyDB handle\n")); rc = gpg_error (GPG_ERR_GENERAL); goto leave; } @@ -1250,7 +1250,7 @@ do_validate_chain (ctrl_t ctrl, ksba_cert_t cert, ksba_isotime_t checktime_arg, kh = keydb_new (0); if (!kh) { - log_error (_("failed to allocated keyDB handle\n")); + log_error (_("failed to allocate keyDB handle\n")); rc = gpg_error (GPG_ERR_GENERAL); goto leave; } @@ -1890,7 +1890,7 @@ gpgsm_basic_cert_check (ctrl_t ctrl, ksba_cert_t cert) kh = keydb_new (0); if (!kh) { - log_error (_("failed to allocated keyDB handle\n")); + log_error (_("failed to allocate keyDB handle\n")); rc = gpg_error (GPG_ERR_GENERAL); goto leave; } diff --git a/sm/certlist.c b/sm/certlist.c index 241364a..9adcabf 100644 --- a/sm/certlist.c +++ b/sm/certlist.c @@ -139,7 +139,7 @@ cert_usage_p (ksba_cert_t cert, int mode) { if ((use & (KSBA_KEYUSAGE_KEY_CERT_SIGN))) return 0; - log_info (_("certificate should have not " + log_info (_("certificate should not have " "been used for certification\n")); return gpg_error (GPG_ERR_WRONG_KEY_USAGE); } @@ -151,7 +151,7 @@ cert_usage_p (ksba_cert_t cert, int mode) || (use & (KSBA_KEYUSAGE_KEY_CERT_SIGN |KSBA_KEYUSAGE_CRL_SIGN)))) return 0; - log_info (_("certificate should have not " + log_info (_("certificate should not have " "been used for OCSP response signing\n")); return gpg_error (GPG_ERR_WRONG_KEY_USAGE); } @@ -162,8 +162,8 @@ cert_usage_p (ksba_cert_t cert, int mode) ) return 0; - log_info (mode==3? _("certificate should have not been used for encryption\n"): - mode==2? _("certificate should have not been used for signing\n"): + log_info (mode==3? _("certificate should not have been used for encryption\n"): + mode==2? _("certificate should not have been used for signing\n"): mode==1? _("certificate is not usable for encryption\n"): _("certificate is not usable for signing\n")); return gpg_error (GPG_ERR_WRONG_KEY_USAGE); diff --git a/sm/decrypt.c b/sm/decrypt.c index 6161150..a560272 100644 --- a/sm/decrypt.c +++ b/sm/decrypt.c @@ -259,7 +259,7 @@ gpgsm_decrypt (ctrl_t ctrl, int in_fd, estream_t out_fp) kh = keydb_new (0); if (!kh) { - log_error (_("failed to allocated keyDB handle\n")); + log_error (_("failed to allocate keyDB handle\n")); rc = gpg_error (GPG_ERR_GENERAL); goto leave; } diff --git a/sm/encrypt.c b/sm/encrypt.c index e881333..54a8bd1 100644 --- a/sm/encrypt.c +++ b/sm/encrypt.c @@ -336,7 +336,7 @@ gpgsm_encrypt (ctrl_t ctrl, certlist_t recplist, int data_fd, estream_t out_fp) kh = keydb_new (0); if (!kh) { - log_error (_("failed to allocated keyDB handle\n")); + log_error (_("failed to allocate keyDB handle\n")); rc = gpg_error (GPG_ERR_GENERAL); goto leave; } diff --git a/sm/gpgsm.c b/sm/gpgsm.c index 7263fd0..b001682 100644 --- a/sm/gpgsm.c +++ b/sm/gpgsm.c @@ -535,8 +535,8 @@ my_strusage( int level ) break; case 41: p = _("Syntax: gpgsm [options] [files]\n" - "sign, check, encrypt or decrypt using the S/MIME protocol\n" - "default operation depends on the input data\n"); + "Sign, check, encrypt or decrypt using the S/MIME protocol\n" + "Default operation depends on the input data\n"); break; case 20: diff --git a/sm/sign.c b/sm/sign.c index e102cd0..08eebb7 100644 --- a/sm/sign.c +++ b/sm/sign.c @@ -334,7 +334,7 @@ gpgsm_sign (ctrl_t ctrl, certlist_t signerlist, kh = keydb_new (0); if (!kh) { - log_error (_("failed to allocated keyDB handle\n")); + log_error (_("failed to allocate keyDB handle\n")); rc = gpg_error (GPG_ERR_GENERAL); goto leave; } diff --git a/sm/verify.c b/sm/verify.c index 8cf7ff9..2e91137 100644 --- a/sm/verify.c +++ b/sm/verify.c @@ -111,7 +111,7 @@ gpgsm_verify (ctrl_t ctrl, int in_fd, int data_fd, estream_t out_fp) kh = keydb_new (0); if (!kh) { - log_error (_("failed to allocated keyDB handle\n")); + log_error (_("failed to allocate keyDB handle\n")); rc = gpg_error (GPG_ERR_GENERAL); goto leave; } -- 1.7.10.4 From taffit at debian.org Wed Aug 22 18:54:37 2012 From: taffit at debian.org (=?UTF-8?q?David=20Pr=C3=A9vot?=) Date: Wed, 22 Aug 2012 12:54:37 -0400 Subject: [PATCH 2/3] Actually show translators comments in PO files In-Reply-To: <1345654478-11634-1-git-send-email-taffit@debian.org> References: <50200521.5030302@debian.org> <1345654478-11634-1-git-send-email-taffit@debian.org> Message-ID: <1345654478-11634-3-git-send-email-taffit@debian.org> --- agent/call-pinentry.c | 2 +- g10/pkclist.c | 2 +- g10/trustdb.c | 10 +++++----- scd/app-openpgp.c | 3 +-- 4 files changed, 8 insertions(+), 9 deletions(-) diff --git a/agent/call-pinentry.c b/agent/call-pinentry.c index 381d0f0..c37831a 100644 --- a/agent/call-pinentry.c +++ b/agent/call-pinentry.c @@ -818,7 +818,7 @@ agent_askpin (ctrl_t ctrl, if (errtext) { - /* TRANLATORS: The string is appended to an error message in + /* TRANSLATORS: The string is appended to an error message in the pinentry. The %s is the actual error message, the two %d give the current and maximum number of tries. */ snprintf (line, DIM(line)-1, _("SETERROR %s (try %d of %d)"), diff --git a/g10/pkclist.c b/g10/pkclist.c index c43c74c..f805da8 100644 --- a/g10/pkclist.c +++ b/g10/pkclist.c @@ -202,7 +202,7 @@ do_edit_ownertrust (PKT_public_key *pk, int mode, for(;;) { /* A string with valid answers. - Note to translators: These are the allowed answers in lower and + TRANSLATORS: These are the allowed answers in lower and uppercase. Below you will find the matching strings which should be translated accordingly and the letter changed to match the one in the answer string. diff --git a/g10/trustdb.c b/g10/trustdb.c index 0f13dc1..6b228d2 100644 --- a/g10/trustdb.c +++ b/g10/trustdb.c @@ -507,7 +507,11 @@ trust_letter (unsigned int value) } } -/* NOTE TO TRANSLATOR: these strings are similar to those in +const char * +uid_trust_string_fixed(PKT_public_key *key,PKT_user_id *uid) +{ + if(!key && !uid) +/* TRANSLATORS: these strings are similar to those in trust_value_to_string(), but are a fixed length. This is needed to make attractive information listings where columns line up properly. The value "10" should be the length of the strings you @@ -515,10 +519,6 @@ trust_letter (unsigned int value) It gets passed to atoi() so everything after the number is essentially a comment and need not be translated. Either key and uid are both NULL, or neither are NULL. */ -const char * -uid_trust_string_fixed(PKT_public_key *key,PKT_user_id *uid) -{ - if(!key && !uid) return _("10 translator see trustdb.c:uid_trust_string_fixed"); else if(uid->is_revoked || (key && key->flags.revoked)) return _("[ revoked]"); diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index 0dd20e2..9c8ef59 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -2081,8 +2081,7 @@ do_change_pin (app_t app, ctrl_t ctrl, const char *chvnostr, /* TRANSLATORS: Do not translate the "|*|" prefixes but keep it at the start of the string. We need this elsewhere to get some infos on the string. */ - rc = pincb (pincb_arg, - set_resetcode? _("|RN|New Reset Code") : + rc = pincb (pincb_arg, set_resetcode? _("|RN|New Reset Code") : chvno == 3? _("|AN|New Admin PIN") : _("|N|New PIN"), &pinvalue); if (rc) -- 1.7.10.4 From jeanjacquesbrucker at gmail.com Thu Aug 23 02:36:29 2012 From: jeanjacquesbrucker at gmail.com (jbar) Date: Thu, 23 Aug 2012 02:36:29 +0200 Subject: minimal CGI scripts to make hkp server using GnuPG (and gpgme). Message-ID: <20120823023629.b3987952.jeanjacquesbrucker@gmail.com> Hi, just to share with you such CGI scripts I wrote, which permit to run an hkp server with an HTTP server (I don't have find any hkp server or hkp cgi-scripts which was using gpgme). https://github.com/Open-UDC/open-udc/tree/master/ludd/src/pks They run correctly with GnuPG (I didn't test anything else) and could be usefull. Note: cgi-add.sh is very quick and dirty and inefficient (bash script) ... should rewrite it using gpgme.h one day. But cgi-lookup.c seems clean and efficient : comments are welcome if you see some improvements to do or bugs in :-) -- jbar -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From wk at gnupg.org Fri Aug 24 09:14:48 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 24 Aug 2012 09:14:48 +0200 Subject: [PATCH] Fixed some "bugs" appearing through clang-analyzer In-Reply-To: <1345502181-21809-1-git-send-email-ekleog@gmail.com> (Leo Gaspard's message of "Tue, 21 Aug 2012 00:36:21 +0200") References: <1345502181-21809-1-git-send-email-ekleog@gmail.com> Message-ID: <87txvs7od3.fsf@vigenere.g10code.de> On Tue, 21 Aug 2012 00:36, ekleog at gmail.com said: > Just wanted to say clang-analyser also reports an error in import.c line 247 > (err set but not used), but adding a check for "err" makes a test fail. I checked it and figured that the called function is not robust enough. At least the last PARSE_NEXT macro needs to be modified to accept a number not ending with a space. But needs to be checked against the specs of the status line. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Aug 24 09:39:00 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 24 Aug 2012 09:39:00 +0200 Subject: patch to fix Android build In-Reply-To: <502DB0A5.4030009@guardianproject.info> (Hans-Christoph Steiner's message of "Thu, 16 Aug 2012 22:47:01 -0400") References: <502DB0A5.4030009@guardianproject.info> Message-ID: <87hars7n8r.fsf@vigenere.g10code.de> On Fri, 17 Aug 2012 04:47, hans at guardianproject.info said: > Attached is the patch to gnupg master that I've been using since Feb for > the Android builds. Its been working fine for me, and it would be good > to have it included in the main git. Applied to my local branch. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Aug 24 09:45:42 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 24 Aug 2012 09:45:42 +0200 Subject: [master PATCHES] translation related helper, and a few typos In-Reply-To: <1345654478-11634-1-git-send-email-taffit@debian.org> ("David =?utf-8?Q?Pr=C3=A9vot=22's?= message of "Wed, 22 Aug 2012 12:54:35 -0400") References: <50200521.5030302@debian.org> <1345654478-11634-1-git-send-email-taffit@debian.org> Message-ID: <87d32g7mxl.fsf@vigenere.g10code.de> On Wed, 22 Aug 2012 18:54, taffit at debian.org said: > As previously announced, please find attached some patches against the > master branch. Applied to my work branch. Thanks. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Aug 24 16:46:59 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 24 Aug 2012 16:46:59 +0200 Subject: [STABLE-BRANCH-1-4 PATCHES] translation related helper, and a few typos In-Reply-To: <50200521.5030302@debian.org> ("David =?utf-8?Q?Pr=C3=A9vot?= =?utf-8?Q?=22's?= message of "Mon, 06 Aug 2012 13:55:45 -0400") References: <50200521.5030302@debian.org> Message-ID: <87393c73fg.fsf@vigenere.g10code.de> On Mon, 6 Aug 2012 19:55, taffit at debian.org said: > [PATCH 1/3] In order to help translators to update their files, using > the --previous option of msgmerge would be highly welcome. > > [PATCH 2/3] A few translators notes didn't show up in the PO files. > > [PATCH 3/3] Three minor typos spotted during the translation update and > review. All applied. > It would be nice to take care of the trivial unfuzzy when updating the > PO files after the typo fix (even if the first patch will minimize the Does anyone know a tool for it? I sometimes don't fix types so not to break translations. > Is it OK to send you patches attached to this list like I did, or do you THis is low traffic, thus I think it is okay. > Where should I send the updated PO files ( looks > inactive), and what is the preferred form (compressed PO file or git I think a git commit is easier if there is already a commit messages. > Ga?l also asked me to make sure that messages can be displayed in an 80 > colons terminal, but some have variable length (due to %s that can be as Well, sometimes it is not possible and thus messages will wrap. A logn filename will trigger wrapping in most cases and you can't do anything about it. > long as user ID), and some strings are displayed after ?gpg:? (by the > way, would it be possible to change this string, depending on the I don't think that this is a good idea. "foo:" shall be the name of the program which is running - this name is not subject to translation. GUI frontends may easily strip that prefix. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From taffit at debian.org Fri Aug 24 17:04:13 2012 From: taffit at debian.org (=?UTF-8?B?RGF2aWQgUHLDqXZvdA==?=) Date: Fri, 24 Aug 2012 11:04:13 -0400 Subject: [STABLE-BRANCH-1-4 PATCHES] translation related helper, and a few typos In-Reply-To: <87393c73fg.fsf@vigenere.g10code.de> References: <50200521.5030302@debian.org> <87393c73fg.fsf@vigenere.g10code.de> Message-ID: <503797ED.2010708@debian.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Werner, Thanks for your answers, Le 24/08/2012 10:46, Werner Koch a ?crit : >> It would be nice to take care of the trivial unfuzzy when updating the >> PO files after the typo fix (even if the first patch will minimize the > > Does anyone know a tool for it? I sometimes don't fix types so not to > break translations. I now use msguntypot from po4a, but I used to do that with sed? I can take of it if you wish. >> what is the preferred form (compressed PO file or git > > I think a git commit is easier if there is already a commit messages. Snap, i went the other way around, will send you a commit message ASAP. >> long as user ID), and some strings are displayed after ?gpg:? (by the >> way, would it be possible to change this string, depending on the > > I don't think that this is a good idea. "foo:" shall be the name of the > program which is running - this name is not subject to translation. In French we should use ?gpg :? (with a non-breaking space before the colon), so it would be nice to make the colon translatable. Regards David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQN5ftAAoJELgqIXr9/gny6q8P/0AdI6P/z8YTWJw/jNYhFFFk nIYCEbKP6NAbVeWNuw/KG0TMOIBV1gyx2qfSijvLxF+jRLmK7gnIAf1d8gpVbMcs wtzO78oTq4/5r1mCxBqZFXBhU5ksOVRhQ9a1db4HjoVjzTdPX+Ct06oKhFs8N45J w5Ywk7pqThkFx4cR6aCxbQKhO6LtTAuxGe/eVbRhjo+xjZoD1zP1sTrbCoGBNzSu RPp8pYxDETKKX/H2fIb8wXdRirGhs0QiEQLVHv3ay0w0CWX3CVfkFOODzBrPWQeX +oclNhzNlUhzI7nW7KviSlvYA2GzsSS8DGicu/PU6v7lPnH1QftA2W/pf27U+uSn sVSILYUb9KxOCHL84BHIGGs8fkTY3F8KOMZV8lWO+U/dnxSP7HEsbtqqURvbNAXG oiRXzTzzTTKNnkaGlr7nyKWLQ7c6jRRzXEkzdWDAMSzjck6VCiJBdMKZ3Nqxmhv/ mAesId6gwpalaQCj3jEsDocKeUH/wARjQYd5wtH0ODQUE3DivwO28+y0BsE7aFPl bBuD4pTZ3+yDnMZ8dfWzPybdWq/Z5eohy5UYR/wSQaFct8kAxClq+U+xJ59DaGRK fQDFp/ftUWOfNHKhMk6tRb55lXwDY+6IrXJJGFn/nIHSZLBjx4EPcEbn4R10b8gP 2PKkwCHCYhaQ7Rij616Z =D+8r -----END PGP SIGNATURE----- From wk at gnupg.org Fri Aug 24 17:51:25 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 24 Aug 2012 17:51:25 +0200 Subject: Keysigning party methodology: Sassaman-Efficient & centralizing printing In-Reply-To: <5032CDB6.3030900@sixdemonbag.org> (Robert J. Hansen's message of "Mon, 20 Aug 2012 19:52:22 -0400") References: <20120820174748.GA27206@orbis-terrarum.net> <5032CDB6.3030900@sixdemonbag.org> Message-ID: <87txvs5lvm.fsf@vigenere.g10code.de> On Tue, 21 Aug 2012 01:52, rjh at sixdemonbag.org said: > just letting people verify ID, you also hand a slip of paper with your > name and key fingerprint on it. One problem with the paper slips is that some folks are printing them on tiny pices of paper. It is not easy to stitch them together. I would very much recommend a standard format and font for them. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Aug 24 17:56:12 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 24 Aug 2012 17:56:12 +0200 Subject: [STABLE-BRANCH-1-4 PATCHES] translation related helper, and a few typos In-Reply-To: <503797ED.2010708@debian.org> ("David =?utf-8?Q?Pr=C3=A9vot?= =?utf-8?Q?=22's?= message of "Fri, 24 Aug 2012 11:04:13 -0400") References: <50200521.5030302@debian.org> <87393c73fg.fsf@vigenere.g10code.de> <503797ED.2010708@debian.org> Message-ID: <87pq6g5lnn.fsf@vigenere.g10code.de> On Fri, 24 Aug 2012 17:04, taffit at debian.org said: > Snap, i went the other way around, will send you a commit message ASAP. I already pushed them. Thanks for the offer. > In French we should use ?gpg :? (with a non-breaking space before the > colon), so it would be nice to make the colon translatable. Ah, that is the reason for underscores I noticed. How do other tools handle it? IIRC, the GNU coding standards are quiet on that. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nicholas.cole at gmail.com Fri Aug 24 22:26:01 2012 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Fri, 24 Aug 2012 21:26:01 +0100 Subject: [STABLE-BRANCH-1-4 PATCHES] translation related helper, and a few typos In-Reply-To: <87pq6g5lnn.fsf@vigenere.g10code.de> References: <50200521.5030302@debian.org> <87393c73fg.fsf@vigenere.g10code.de> <503797ED.2010708@debian.org> <87pq6g5lnn.fsf@vigenere.g10code.de> Message-ID: On Fri, Aug 24, 2012 at 4:56 PM, Werner Koch wrote: > On Fri, 24 Aug 2012 17:04, taffit at debian.org said: > >> Snap, i went the other way around, will send you a commit message ASAP. > > I already pushed them. Thanks for the offer. > >> In French we should use ?gpg :? (with a non-breaking space before the >> colon), so it would be nice to make the colon translatable. > > Ah, that is the reason for underscores I noticed. How do other tools > handle it? IIRC, the GNU coding standards are quiet on that. > > > Shalom-Salam, > > Werner Careful about changing that string - scripts may look for "gpg:" as a marker of particular messages. (eg. for messages that might need to be relayed to users) Within error messages themselves, of course it is reasonable to use French conventions about spacing, but I don't think it is a good idea to change the marker at the start of the string. Best wishes, Nicholas From jeanjacquesbrucker at gmail.com Tue Aug 28 17:49:42 2012 From: jeanjacquesbrucker at gmail.com (jbar) Date: Tue, 28 Aug 2012 17:49:42 +0200 Subject: clean or revoke a key with gpme Message-ID: <20120828174942.a2b6c683.jeanjacquesbrucker@gmail.com> First, after previous cgi-lookup.c, I have write a cgi-add.c which permit to compile a cgi script for the "pks/add" of an hkp server : https://github.com/Open-UDC/open-udc/blob/master/ludd/src/pks/cgi-add.c (It may be usefull if u want to add an hkp server to any web server which enables binary cgi scripts). Then, the serious help I'd like to have, is about gpgme_op_edit* ( http://www.gnupg.org/documentation/manuals/gpgme/Advanced-Key-Editing.html) : I'd like to clean and to revoke key(s) with gpgme (and without human interaction), but I didn't understand yet how gpgme_op_edit* works, and I didn't have found a clear example about using this functions (In fact, I didn't understand the one I found in ./tests/gpg/t-edit.c of git.gnupg.org :-/ ). May u please give me, or link me to, working use of gpgme_op_edit* (and especially to clean/revoke a key if possible ;-) ) ? Thanks a lot, -- jbar From hans at guardianproject.info Fri Aug 31 03:52:51 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Thu, 30 Aug 2012 21:52:51 -0400 Subject: ideas for library loading for gpgme on Android Message-ID: <504018F3.20504@guardianproject.info> So Android has a very limited linker, and the _only_ way to specify load paths for shared libraries is with the LD_LIBRARY_PATH env var. By default, LD_LIBRARY_PATH is set to: LD_LIBRARY_PATH=/vendor/lib:/system/lib So that even the most basic programs can find libc. This is easy enough to do in an Android app when calling the various GnuPG command line tools directly (gpg2, gpg-agent, etc). But we want to use gpgme, which as far as I understand it, is a library that then calls the various command line tools. I can think of many hackish ways to set LD_LIBRARY_PATH for gpgme, but I was wondering if anyone has any ideas for how to do it best. Do any other platforms have a similar situation? .hc From marcus.brinkmann at ruhr-uni-bochum.de Fri Aug 31 15:08:16 2012 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 31 Aug 2012 15:08:16 +0200 Subject: ideas for library loading for gpgme on Android In-Reply-To: <504018F3.20504@guardianproject.info> References: <504018F3.20504@guardianproject.info> Message-ID: <5040B740.1080801@ruhr-uni-bochum.de> On 08/31/2012 03:52 AM, Hans-Christoph Steiner wrote: > > So Android has a very limited linker, and the _only_ way to specify load > paths for shared libraries is with the LD_LIBRARY_PATH env var. By > default, LD_LIBRARY_PATH is set to: > > LD_LIBRARY_PATH=/vendor/lib:/system/lib That's the canonical way. Normally, the environment is inherited by child processes, so it will just propagate through GPGME. Or is this different on Android? Marcus From hans at guardianproject.info Fri Aug 31 15:47:24 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 31 Aug 2012 09:47:24 -0400 Subject: ideas for library loading for gpgme on Android In-Reply-To: <5040B740.1080801@ruhr-uni-bochum.de> References: <504018F3.20504@guardianproject.info> <5040B740.1080801@ruhr-uni-bochum.de> Message-ID: <5040C06C.7040109@guardianproject.info> On 08/31/2012 09:08 AM, Marcus Brinkmann wrote: > On 08/31/2012 03:52 AM, Hans-Christoph Steiner wrote: >> >> So Android has a very limited linker, and the _only_ way to specify load >> paths for shared libraries is with the LD_LIBRARY_PATH env var. By >> default, LD_LIBRARY_PATH is set to: >> >> LD_LIBRARY_PATH=/vendor/lib:/system/lib > > That's the canonical way. Normally, the environment is inherited by > child processes, so it will just propagate through GPGME. > > Or is this different on Android? The difference on Android is that there are no built-in paths and rpath is not supported. On all the GNU/Linux systems I've used, I've never seen LD_LIBRARY_PATH set by the system. The environment is inherited in Android as well, but since Android apps are Java, there isn't a way that I know to set LD_LIBRARY_PATH for the current process in Java, only child processes. I think that Android does look in the app-local lib/ folder when loading JNI libs, but that doesn't seem to set LD_LIBRARY_PATH so that's not inherited by the gpg child process. I'll investigate more today... .hc From hans at guardianproject.info Fri Aug 31 18:14:39 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 31 Aug 2012 12:14:39 -0400 Subject: ideas for library loading for gpgme on Android In-Reply-To: <5040D88D.1010308@ruhr-uni-bochum.de> References: <504018F3.20504@guardianproject.info> <5040B740.1080801@ruhr-uni-bochum.de> <5040C06C.7040109@guardianproject.info> <5040D88D.1010308@ruhr-uni-bochum.de> Message-ID: <5040E2EF.9070005@guardianproject.info> On 08/31/2012 11:30 AM, Marcus Brinkmann wrote: > On 08/31/2012 03:47 PM, Hans-Christoph Steiner wrote: >> >> >> On 08/31/2012 09:08 AM, Marcus Brinkmann wrote: >>> On 08/31/2012 03:52 AM, Hans-Christoph Steiner wrote: >>>> >>>> So Android has a very limited linker, and the _only_ way to specify load >>>> paths for shared libraries is with the LD_LIBRARY_PATH env var. By >>>> default, LD_LIBRARY_PATH is set to: >>>> >>>> LD_LIBRARY_PATH=/vendor/lib:/system/lib >>> >>> That's the canonical way. Normally, the environment is inherited by >>> child processes, so it will just propagate through GPGME. >>> >>> Or is this different on Android? >> >> The difference on Android is that there are no built-in paths and rpath >> is not supported. On all the GNU/Linux systems I've used, I've never >> seen LD_LIBRARY_PATH set by the system. >> >> The environment is inherited in Android as well, but since Android apps >> are Java, there isn't a way that I know to set LD_LIBRARY_PATH for the >> current process in Java, only child processes. > > Well, in that case, the quickest way is possibly to set the environment > from within gpgme before spawning child processes. Is there a way to do that cleanly within gpgme? Or are you suggesting that I just patch in a putenv()? >> I think that Android does look in the app-local lib/ folder when loading >> JNI libs, but that doesn't seem to set LD_LIBRARY_PATH so that's not >> inherited by the gpg child process. >> >> I'll investigate more today... I haven't found how Android manages to load the JNI libs for an app from its standard location: /data/data/com.example.app/lib/libmyjni.so. .hc From hans at guardianproject.info Fri Aug 31 22:05:19 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 31 Aug 2012 16:05:19 -0400 Subject: GPGME_DEBUG on Android, which makes env vars hard Message-ID: <504118FF.3080308@guardianproject.info> So this kind of thing would be super helpful for me to debug the GnuPG-for-Android app, but since Android apps are Java, and they are launched from a mysterious non-UNIX process, using environment variables is difficult at best. I would like to do exactly this: GPGME_DEBUG=9:/tmp/gpgme.debug Is there anyway to do this in C code? Like an option to the gpg_engine? .hc