Re: Why do we use a different key to sign than to encrypt
On Tue, 1 Mar 2011 14:30:37 +, Guy Halford-Thompson wrote: > But doesnt GPG generate 2 private keys (as well as public keys) when > you create a new keypair? > > Please select what kind of key you want: >(1) RSA and RSA (default) >(2) DSA and Elgamal >(3) DSA (sign only) >(4) RSA (sign only > > I can understand if you use DSA and Elgamal (DSA can only sign) but > what about RSA and RSA? Hi, Guy. This prompt is definitely confusing, but yes, options (1) and (2) create two key pairs, one primary key used for signing and certifying, and a second subkey used for encryption. Options (3) and (4) only create a single primary key used for signing and certifying. You can create an arbitrary number of subkeys if you'd like. It's common to create one for authentication, for instance. jamie. pgpAYAxSnEMJ0.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: PGP/MIME considered harmful for mobile
On Sat, 26 Feb 2011 21:02:08 -0500, Avi wrote: > Why? Inline is simple and effective. I'm curious as to why you > feel MIME is so much better. http://josefsson.org/inline-openpgp-considered-harmful.html jamie. pgpha2dSJArgJ.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: PGP/MIME considered harmful for mobile
On Thu, 24 Feb 2011 20:22:03 -0500, "Robert J. Hansen" wrote: > Just as an FYI to the list -- > > On Android's mail application, PGP/MIME attachments are nigh-unusable. > It won't render even the plaintext portions: it has to be downloaded and > opened with a text reader. If you're concerned about your mail being > readable on a mobile device (which is increasingly important nowadays), > you might want to consider switching to inline signatures. Yikes! I thought we were almost done killing inline signatures! Don't revive it now! If PGP/MIME is broken on android, we need to get them to fix it, not go backwards to inline pgp. jamie. pgpW6t3hiuiob.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: moving user ID Comments to --expert mode
On Fri, 4 Feb 2011 20:08:08 +, MFPA wrote: > IMHO, the comment field is firmly in the "you don't need this at all" > category. If Heinrich Heine really wants his UID to be > "Heinrich Heine (Der Dichter) " he can > type "Heinrich Heine (Der Dichter)" in the name field and > "heinri...@duesseldorf.de" in the email address field. I *very* strongly agree with this sentiment. jamie. pgpncVJu4zsmt.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: moving user ID Comments to --expert mode
On Thu, 03 Feb 2011 17:54:39 -0500, "Robert J. Hansen" wrote: > > But i suspect he would not want to certify this User ID: > > > > Daniel Kahn Gillmor (I am really Robert Hansen) > > Correct. Because the presence of my signature means something. The > *absence* means *nothing at all*, and you're smart enough to know that. Just out of curiosity, can you explain why you wouldn't sign dkg's hypothetical user ID? jamie. pgpkFAKu20oug.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: moving user ID Comments to --expert mode
On Thu, 03 Feb 2011 17:10:58 -0500, "Robert J. Hansen" wrote: > On 2/3/11 4:30 PM, Daniel Kahn Gillmor wrote: > > my "user survey" is from several years of trying to personally help > > dozens of people of all skill levels learn how to use OpenPGP for secure > > messaging. Regardless of the intelligence or technical savvy of the > > people i've personally helped get more comfortable with OpenPGP, i > > believe all of them have been baffled by the Comment: prompt. > > I'm in a similar position to you, except this is my twentieth year of > helping people with PGP. (I started way back in 1991, when PGP first > came out and was distributed friend-to-friend on floppy disks... five > and a quarter floppy disks.) > > I have never seen anyone be baffled by the 'Comment:' prompt. Some > people have asked, "What should I type here?", and I usually explain, > "nothing, just hit return," and they do. Those who ask what the > "Comment" field means generally understand it very quickly. I have to agree with Daniel that I have in fact honestly never spoken to anyone who was *not* confused by that field. I can't ever remember seeing a comment field used in any way that made sense to me. > > I invite you to look through the User IDs in your own keyring, from the > > perspective of a potential certifier, and ask yourself "what does it > > mean for me to certify these comments?" > > Zero. Comments don't get certified. All my signature means is I have > met this person face to face, have seen two forms of government > identification, have confirmed a fingerprint and exchanged an email at > that address. There's nothing in my signature policy that addresses > comments, nothing at all. I'm not sure I understand this comment. Certifications are over user IDs. The comments are in the user IDs. By certifying the full user ID you are also certifying the comment. > > Omitting the baffling prompt entirely would be the most terse, which is > > what i propose. Do you object to that? > > Without a good basis, yes, I do. If you change this prompt you will > also break a ton of scripts that expect this prompt. Not only that, but > since key generation is a rare occurrence the breakage may occur months > or years after the change is made. This isn't something to be done lightly. I think this is why his original suggestion was to move it instead to --expert. Moving it to --expert makes a lot of sense to me. jamie. pgptusULBZJoU.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to handle user passphrase input from python script
On Mon, 31 Jan 2011 03:41:51 +0100, orionbe...@gmail.com wrote: > I use a python script to (a) open a file encrypted with a symmetric > cipher using a passphrase, (b) do some operations on it, and (c) > re-encrypt it. You might try using one of the many python gpg interface libraries that exist out there. With a cursory look I see three such packages in Debian: python-gpgme python-pyme python-gnupginterface hth. jamie. pgpvTIdjWsJiL.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: What does the "sub" entry of a key mean?
On Sat, 15 Jan 2011 19:17:27 +0100, Bo Berglund wrote: > THanks, indeed the --with-colons gave a completely different output... > I was just about to ask of the date format (if it changes between > operating systems or such) but now I have a different problem in > understanding the machine readable format. > > Very hard to understand. Is there a parsing guide somewhere? Hi, Bo. There should be a file called DETAILS (in doc/DETAILS in the gnupg source, or maybe included with your local installation) that describes in detail the meaning of the --with-colons output. It's exactly the reference you're looking for when writing a program to parse the --with-colons output. Good luck! jamie. $ head gnupg2-2.0.14/doc/DETAILS -*- text -*- Format of colon listings First an example: $ gpg --fixed-list-mode --with-colons --list-keys \ --with-fingerprint --with-fingerprint w...@gnupg.org pub:f:1024:17:6C7EE1B8621CC013:899817715:1055898235::m:::scESC: fpr:ECAF7590EB3443B5C7CF3ACB6C7EE1B8621CC013: $ pgp9kMTpPnBla.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgkey2ssh
On Thu, 21 Oct 2010 19:58:31 -0600, Aaron Toponce wrote: > So, help? Hi, Aaron. You might be interested in some of the tools that come with the Monkeysphere [0] package, which deals with a lot of OpenPGP for SSH stuff. It comes with the utility openpgp2ssh, which translates OpenPGP keys to SSH keys (and is well documented). From openpgp2ssh(1): SYNOPSIS openpgp2ssh < mykey.gpg gpg --export $KEYID | openpgp2ssh $KEYID gpg --export-secret-key $KEYID | openpgp2ssh $KEYID Monkeysphere also has a command to import an authentication-capable OpengPGP subkey directly into an ssh-agent: $ monkeysphere subkey-to-ssh-agent It's available in Debian, Ubuntu, and some other distros [1]. hth. jamie. [0] http://web.monkeysphere.info/ [1] http://web.monkeysphere.info/download/ pgplGCTY4Rc9p.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
On Fri, 15 Oct 2010 19:12:21 -0400, "Robert J. Hansen" wrote: > > Do you use ssh-agent? Do you think their implementation of the same > > thing is not good? If so, have you complained to them about it, or > > asked why the implemented it? > > This seems to be an argument from implication of hypocrisy: as if, > were I a user of ssh-agent, my opinion regarding gpg-agent could be > safely dismissed on the grounds of my hypocrisy by not bringing the > same issues up to the ssh-agent authors. No, I was just curious why, if you were an ssh-agent user, you would be ok with the implementation there but not for gpg-agent. If you're not an ssh-agent user then you have nothing to get defensive about. jamie. pgpP9szUlw4zT.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
On Sat, 16 Oct 2010 01:05:11 +0200, Hauke Laging wrote: > I just don't like the idea that access to the agent is "not noticed by > design". I strongly agree with this point. Let's think about it another way: what if the user is themselves doing something that is unintentionally accessing the key? They might prefer to know about it rather than have it accessed without their knowledge. I would say that's good enough reason to have confirmation right there. jamie. pgpnVgCOCUNn9.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
On Fri, 15 Oct 2010 18:23:04 -0400, "Robert J. Hansen" wrote: > I'm not. This idea isn't good. Do you use ssh-agent? Do you think their implementation of the same thing is not good? If so, have you complained to them about it, or asked why the implemented it? jamie. pgph0M2eECPqg.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
On Fri, 15 Oct 2010 15:36:51 -0400, "Robert J. Hansen" wrote: > On 10/15/10 2:49 PM, Jameson Rollins wrote: > > Without use confirmation in the agent, a malicious program running under > > your account could access your secret key without you knowing it. > > This can still happen with a confirmation prompt. Confirmation cannot > protect against malware running under your account. If the agent pops > up a dialog box, then all I have to do is intercept the dialog box and > answer 'yes.' Ok, then this protects against malicious programs that are not intercepting the dialog box. Just because a fix for one problem doesn't solve all possible problems does not mean that it should be ignored. Don't let the perfect be the enemy of the good. jamie. pgpsjIEJQ1fNU.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Confirmation for cached passphrases useful?
On Fri, 15 Oct 2010 13:42:05 -0400, "Robert J. Hansen" wrote: > On 10/15/10 1:31 PM, Doug Barton wrote: > > The other problem with the confirmation proposal is that ... the > > intersection between plausible attack vectors and vulnerabilities > > that [this proposal] would actually fix seems [very] small. > > I seem to recall saying something similar to this a few days ago. :) > > I'll go one step further: so far I haven't seen anyone present a > plausible intersection. I've seen some hypothetical intersections, but > none that I think are plausible. Without use confirmation in the agent, a malicious program running under your account could access your secret key without you knowing it. That is clear and indisputable. If there was no worry of this happening, then there would also be no need to passphrase-protect your secret key. Since everyone seems to agree that one should passphrase-protect your secret key, then there are obviously plausible attack vectors here. I am also strongly in favor of use confirmation in the agent, and I'm having a hard time understanding the opposition to it. FWIW, ssh-agent implements use confirmation, so they clearly thought there were plausible attack vectors as well. jamie. pgp4TqraALkxZ.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: how slow are 4Kbit RSA keys? [was: Re: multiple keys vs multiple identities]
On Mon, 27 Sep 2010 21:25:21 +0200, Ludwig Hügelschäfer wrote: > Ack. 1.5 seconds is about the limit where a good GUI should issue a > reaction. This is where the human mind is starting to think there's > something wrong. We should be careful not to overstate the impatience of users too much. I've seen plenty of people wait many seconds for google maps to load on phones without giving up on the whole process. I also have an extremely slow machine were I routinely have to wait a long time (many seconds) for certain operations to complete. It's certainly not ideal, but I don't give up on those operations just because they take a little longer. I get used to it and figure out ways to deal. I'm not saying we shouldn't care about operations taking a noticeable amount of time, but I wouldn't state out-right that users will revolt and refuse to do something just because it takes more than a second. jamie. pgpGIWnJefD7B.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: how slow are 4Kbit RSA keys? [was: Re: multiple keys vs multiple identities]
On Mon, 27 Sep 2010 16:28:07 +0200, Vjaceslavs Klimovs wrote: > 2048 bit keys are suitable - it's "user+sys" what matters in this case, > but not "real" by all means, as that includes waiting for passphrase > input too. I think this is really a UI issue, in which case "real" is what you really care about. An operation that takes >1s is annoying if it needs to be done frequently, but I'm not sure the operations we're talking about here really ones that are done that frequently. jamie. pgpvmHkukpkG5.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: how slow are 4Kbit RSA keys? [was: Re: multiple keys vs multiple identities]
On Mon, 27 Sep 2010 15:56:52 +0200, Vjaceslavs Klimovs wrote: > I did some quick tests on Nokia N900 (600 MHz ARM CPU), with gnupg > 1.4.6, here is what I got: > > Encrypting and signing, 2048 bit RSA keys: > > real0m 2.50s > user 0m 0.50s > sys 0m 0.02s > > Decrypting and verifying, 2048 bit RSA keys: > > real 0m 1.74s > user 0m 0.41s > sys 0m 0.04s > > Encrypting and signing, 4096 bit RSA keys: > > real0m 3.58s > user 0m 1.92s > sys 0m 0.06s > > Decrypting and veryfying, 4096 bit RSA keys: > > real 0m 3.80s > user 0m 1.89s > sys 0m 0.03s > > Is one second considered a rule of thumb limit? That would mean that > 4096 keys are not suitable for widespread use yet. Then by that logic neither are 2048 bit keys. jamie. pgpmmvzoiybHA.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How to sign a remote repository, i.e. forward agent
On Tue, 29 Jun 2010 21:40:37 +0200, Carsten Aulbert wrote: > My problem is relatively simple. We provide a (Debian) repository for our > colleagues as well as ourselves and would like to sign it (for the experts: > reprepro's export option). Of course one could either copy around the secret > keyring and start the agent remotely or type the passphrase many times, but > straight from the FAQ this is not a good idea(TM). > > Now the notorious question: Does anyone know how to forward the agent's > socket > to the remote machine? I've briefly tried socat (remote unix socket to tcp > port, ssh tunnel of this port and then socat again to link the forwarded port > to the existing socket) but so far to no avail. Hey, Carsten. It just occurred to me that maybe you could use sshfs to accomplish this. You could mount the needed reprepro directory locally with sshfs, and then sign the needed files locally without having to actually move the files around or forward the gnupg agent. I just tried signing something over an sshfs mount and it seemed to work fine. sshfs is fabulous. hth. jamie. pgpCI7FfiFYni.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: local signatures: should they be importable by default in some cases?
On Tue, 22 Jun 2010 09:51:58 -0400, Jameson Rollins wrote: > I think the situation Daniel points out is one of the better usages for > local signatures, and probably the main reason for having them in the > first place. Actually, looking at the RFC 4880 now, I see that the original definition definitely was that local signatures were intended to *only* be used by the issuer. From section 5.2.3.11 [0]: Non-exportable, or "local", certifications are signatures made by a user to mark a key as valid within that user's implementation only. Thus, when an implementation prepares a user's copy of a key for transport to another user (this is the process of "exporting" the key), any local certification signatures are deleted from the key. The receiver of a transported key "imports" it, and likewise trims any local certifications. jamie. [0] http://tools.ietf.org/html/rfc4880#section-5.2.3.11 pgpi0fadBGzqy.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: local signatures: should they be importable by default in some cases?
On Tue, 22 Jun 2010 09:27:46 -0400, David Shaw wrote: > On Jun 22, 2010, at 2:36 AM, Daniel Kahn Gillmor wrote: > >> Can you elaborate on the usage you're describing? > > > > I'm thinking of a situation involving three people: Alice, Bob, and Charlie. > > > > Alice has met Bob in person and has verified his key. Alice does not > > want this information to be publicly available (e.g., she has concerns > > about exposing a transparent social graph via the keyservers). However, > > Alice knows and trusts Charlie and wants to put Bob in touch with > > Charlie, even though Charlie and Bob have never spoken before, and > > certainly have not verified each others' keys. > > > > Alice makes a non-exportable certification over Bob's key+userID, and > > mails it to Charlie (in an encrypted message, of course). Charlie > > imports the certification. Now even if Charlie does something like "gpg > > --send $BobsKeyID", the fact that Alice has met Bob will not be publicly > > exposed. > > I'm not sure this is good behavior for Alice. If she is concerned > about whether her linkage to Bob is publicly known, why would she risk > that by giving Charlie a signature (local or otherwise)? Now she has > not only to worry about keeping her linkage secret herself, but she > also has to worry about Charlie keeping her linkage secret. I think that is a red herring. Charlie could also make a myspace page that talks about what great friends Alice and Bob are. No one can forcibly guarantee that all their linkages are kept secret. Alice has to ultimately trust Charlie on some level that he won't maliciously make those linkages public. I think the situation Daniel points out is one of the better usages for local signatures, and probably the main reason for having them in the first place. > In the above scenario, it seems more reasonable for Charlie to locally > sign Bob's key himself on Alice's say-so. But that creates a different trust path than the one Daniel describes. Just as with exportable signatures, Alice's certification of Bob is different in Charlie's eyes that Charlie's own certification. Charlie wouldn't (or shouldn't) make an exportable signature of someone whose identity he hasn't verified, so why should he make even a local one? According to your logic, everyone should just sign the keys of everyone they wish to have trust paths too, whether they've actually met them or not, just based on the fact that others they know have signed their keys, rather than relying on the calculated validity through known trust paths. The point of the scenario that Daniel is pointing out is that Alice and Charlie can use OpenPGP to *cryptographically* verify Bob's identity, without Charlie having to make certifications he otherwise wouldn't make. jamie. pgpK8OfVlzGCc.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
keyserver queries over TLS [was: Re: auto refresh-keys]
On Sun, 20 Jun 2010 02:50:41 +0100, MFPA wrote: > > So in order to be safe you need additional CPU load > > either for TLS or for signing. Signing is superior IMHO > > because it allows reuse of the data (one crypto action > > (covering less data) for several users vs. one for each > > user with TLS) and makes more sense because you don't > > need a second crypto system (X.509) to protect the > > first (OpenPGP). > > Starting from where we are now, as far as I know there are no > keyservers that sign their output, but there are keyservers that use > TLS. > > And TLS does not have to be x.590. There is a draft spec for using > openpgp keys with TLS http://tools.ietf.org/search/rfc5081 which is > implemented in the GnuTLS library > http://www.gnu.org/software/gnutls/gnutls.html This is turning into a separate thread, but while we're on it, I just wanted to point out that the Monkeysphere Project [0] currently provides a means for doing OpenPGP-based site authentication/encryption over TLS, and has discussed building a gpg plugin that can do OpenPGP validation of hkps keyserver queries: https://labs.riseup.net/code/issues/2016 jamie. [0] http://web.monkeysphere.info/ pgpTvvbTmjB9S.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Test mail to gnupg.u...@seibercom.net
On Fri, 11 Jun 2010 06:27:12 -0400, Jerry wrote: > I am assuming that you wanted me to reply to this message. Its intended > purpose was not overly clear. At least not to me, but then again I have > not had my second cup of coffee this morning. I think if he had wanted you to respond to it he would have asked you to respond to it. jamie. pgpzBRIvtD0Pu.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Keyserver spam example
Speaking of spam, I'm getting more spam from some sort of automated ticketing system that seems to be subscribed to this list that I ever have from a keyserver. The mail seems to come from: secure.mpcustomer.com and it often sets the From: to be from someone else. This is totally uncool. Is there a list moderator that can permanently ban anything From this address from the list? jamie. pgpEw3WpEL7zu.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Keyserver spam example
On Thu, 10 Jun 2010 11:32:05 -0400, Daniel Kahn Gillmor wrote: > And i should probably add that it is indeed an infinitesimal drop in the > bucket compared to the other spam i receive; i'm not concerned about it. Not to mention that the bother of a couple of extra spams is completely dwarfed by the benefit of having the public keyserver network. jamie. pgprdXT59QKSN.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Crypto Stick released!
On Thu, 03 Jun 2010 16:43:19 +0200, Crypto Stick wrote: > Each of the three keys can be up to 3072 bit. In fact they can even be > 4096 bit long; but GnuPG does currently not support such key length in > cooperation with the Crypto Stick (but GnuPG can handle 4096 bit > soft-keys without the Crypto Stick). That's strange. What is the limitation with the bit length and GnuPG in regards to the Crypto Stick? Is that something that can be patched, or is it a limitation of the communication protocol? jamie. pgpZtUEt1mW7D.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
RE: Migrating from PGP to GPG question
On Wed, 24 Feb 2010 20:33:14 -0800, "Smith, Cathy" wrote: > We are migrating from OpenPGP which is a freeware version of PGP. Sorry for > the confusion. I'm not familiar with OpenPGP, the software. I'm familiar with the PGP Corporation's implementation (which I think is just called "PGP"), but not an implementation called "OpenPGP". Having trouble finding any references to anything other than OpenPGP the spec as well. Would you mind passing on a link? Thanks. jamie. pgpTfz0XfXl9y.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Migrating from PGP to GPG question
On Wed, 24 Feb 2010 18:46:33 -0800, "Smith, Cathy" wrote: > We are starting to migrate from OpenPGP to GnuPG. Just for clarification, GnuPG is software tool that is actually an implementation of the OpenPGP specification [0]. OpenPGP is not actually a piece of software itself, nor is GnuPG a specification. jamie. [0] http://tools.ietf.org/html/rfc4880 pgpj2xA8mtpQF.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
fragility of --edit-key interface [was: Re: Changing trust in GPGME]
On Wed, Jan 13, 2010 at 10:39:28AM +0100, Werner Koch wrote:
> On Tue, 12 Jan 2010 23:41:52 +0100, Piotr Bratkowski wrote:
>
> > I have this code. And when I see output owner_trust = 4, but in gpg
> > from system I get 0. Do I need to somehow save this changes??
>
> This is not directly supported by GPGME. You need to write an edit
> interactor to control the gpg --edit-key command. GPA has code which
> shows how to do it.
Hello Werner et. al. My understanding is that one of the main
advantages of GPGME is that it provides a stable API to gnupg
functionality. I understand that GPGME doesn't yet provide all the
functionality that a user might need, but I think that suggesting
developers use "gpg --edit-key" to achieve their desired functionality
should include a strong warning that the interface to "gpg --edit-key"
is fragile and may change unexpectedly and without warning.
For instance, as of v1.4.10 (and v2.0.13), the edit-key interface to
generate a subkey on an existing key ('addkey') in expert mode changed
such that the "RSA (set your own capabilities)" selection in the key
type chooser moved from entry 7 to entry 8. As far as I can tell,
this change was not documented, at least not in the any of the
changelogs associated with recent gnupg releases. The Monkeysphere
project [0] is using this capability and this undocumented change
recently caused problems.
Developers looking for the stable interface that GPGME is supposed to
provide should be duly warned that the "gpg --edit-key" interface is
not as stable, and that they should be on the look out for changes to
that interface in the future.
jamie.
[0] http://web.monkeysphere.info/
signature.asc
Description: Digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
