From wolf at wolfsden.cz Fri Jul 1 01:58:20 2016 From: wolf at wolfsden.cz (Wolf) Date: Fri, 1 Jul 2016 01:58:20 +0200 Subject: Change agent-socket path Message-ID: <20160630235820.fozic2jt4jrykdlx@wolfsden.cz> Greetings, I'm in need of changing the path to the agent socket, but I cannot find a way to do so. My problem: gpg-agent normally runs in /run/user/1000/gnupg/S.gnu-agent , which is completely fine. However, when building packages (archlinux, makepkg), the building/signing is done in fakeroot environment. Therefore the socket path default to ~/.gnupg/S.gnu-agent. Because (at least it seems to me) in fakeroot I am root (0) and therefore don't own /run/user/1000 (1000). What would be a good way to solve this issue? Thanks for any help, W. -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From eric.pruitt at gmail.com Fri Jul 1 03:23:32 2016 From: eric.pruitt at gmail.com (Eric Pruitt) Date: Thu, 30 Jun 2016 18:23:32 -0700 Subject: Change agent-socket path In-Reply-To: <20160630235820.fozic2jt4jrykdlx@wolfsden.cz> References: <20160630235820.fozic2jt4jrykdlx@wolfsden.cz> Message-ID: <20160701012332.GA13970@sinister.codevat.com> On Fri, Jul 01, 2016 at 01:58:20AM +0200, Wolf wrote: > I'm in need of changing the path to the agent socket, but I cannot find > a way to do so. For GPG 1.x, you can change this by setting the GPG_AGENT_INFO environment variable or by using the --gpg-agent-info flag. Both of these are documented in further detail in "man gpg." In GPG 2.x, --gpg-agent-info is no longer used, but I think GPG_AGENT_INFO still works; see "man gpg2" for more info. Eric From wk at gnupg.org Fri Jul 1 12:25:59 2016 From: wk at gnupg.org (Werner Koch) Date: Fri, 01 Jul 2016 12:25:59 +0200 Subject: Change agent-socket path In-Reply-To: <20160630235820.fozic2jt4jrykdlx@wolfsden.cz> (wolf@wolfsden.cz's message of "Fri, 1 Jul 2016 01:58:20 +0200") References: <20160630235820.fozic2jt4jrykdlx@wolfsden.cz> Message-ID: <87twg9slhk.fsf@wheatstone.g10code.de> On Fri, 1 Jul 2016 01:58, wolf at wolfsden.cz said: > the building/signing is done in fakeroot environment. Therefore the > socket path default to ~/.gnupg/S.gnu-agent. Because (at least it seems > to me) in fakeroot I am root (0) and therefore don't own /run/user/1000 That is a very special case I would like to avoid an exception for this (ie. relaxing the ownwed-by-user check). > What would be a good way to solve this issue? You can set the envvar GNUPGHOME to a different directory and this will then be used for the socket and all other files - assuming that you did not create a dedicated directory below /var/user/1000/gnupg for example with "gpgconf --create-socketdir". Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From cannon at cannon-ciota.info Fri Jul 1 18:45:42 2016 From: cannon at cannon-ciota.info (Cannon) Date: Fri, 1 Jul 2016 16:45:42 +0000 Subject: Accidentally used SHA1 Message-ID: I accidentally messed up. Used the wrong gpg.conf when generating a signature on a message. The incorrect config was used causing my message to be signed using SHA1 instead of SHA512. I did not realize this until after message was already irreversibly published. Does using SHA1 in past make my key less secure or does this only make the signed message more prone to collision instead of key leak? From rjh at sixdemonbag.org Fri Jul 1 20:33:32 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 1 Jul 2016 14:33:32 -0400 Subject: Accidentally used SHA1 In-Reply-To: References: Message-ID: <9050db23-297e-ab5d-f3a7-788936dc89ed@sixdemonbag.org> > Does using SHA1 in past make my key less secure or does this only make > the signed message more prone to collision instead of key leak? Definitely no to the first, and probably not to the second. SHA-1 is weak in a theoretical sense, but we're nowhere near seeing preimage attacks on it, which is what would have to happen for your message to be susceptible to forgery. We advise against SHA-1 out of an abundance of caution, not because it's broken. The current attacks against SHA-1 are troubling but not applicable to OpenPGP... *yet*. It's that "yet" which causes us to advise using better hash algorithms. :) From andrewg at andrewg.com Fri Jul 1 20:40:48 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 1 Jul 2016 19:40:48 +0100 Subject: Accidentally used SHA1 In-Reply-To: References: Message-ID: > On 1 Jul 2016, at 17:45, Cannon wrote: > > I accidentally messed up. Used the wrong gpg.conf when generating a > signature on a message. The incorrect config was used causing my message > to be signed using SHA1 instead of SHA512. I did not realize this until > after message was already irreversibly published. > > Does using SHA1 in past make my key less secure or does this only make > the signed message more prone to collision instead of key leak? If someone were able to generate a message which collided with the sha1 hash of this particular message then they could impersonate you to anyone who still regarded sha1 signatures as valid (this last point is an important caveat). We must be careful to distinguish this from a collision attack though. A hash collision is where you generate lots of hashes and find any two that match. Sha1 is known to be vulnerable to this. But to fake your signature requires a preimage attack, which needs the fake hash to match *this particular* hash. That is a good deal more difficult, and sha1 is believed to be preimage-resistant for the moment. At some point in the future of course, sha1 will fall. However, all is not lost. Your primary key is not compromised, just this particular signature packet made by this particular signing subkey. If you are sufficiently worried, you can revoke the subkey (thus revoking this signature) and generate a new one. All your previous signatures will be invalidated also, but you can regenerate them with your new subkey if that is an issue. A From andrewg at andrewg.com Fri Jul 1 20:47:32 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Fri, 1 Jul 2016 19:47:32 +0100 Subject: Accidentally used SHA1 In-Reply-To: References: Message-ID: > On 1 Jul 2016, at 19:40, Andrew Gallagher wrote: > If you are sufficiently worried, you can revoke the subkey (thus revoking this signature) and generate a new one. s/worried/paranoid/ A From muri+gnupg-users at immerda.ch Mon Jul 4 10:10:40 2016 From: muri+gnupg-users at immerda.ch (Muri Nicanor) Date: Mon, 4 Jul 2016 10:10:40 +0200 Subject: gpg-agent and ~/.ssh/config IdentityFile Message-ID: <999987a0-6456-4683-072e-a801ce62e3e2@immerda.ch> Hi, this is actually more a ssh question, but i guess that the likelihood for someone having the same problem is higher on gnupg-users: if i use gpg-agent with ssh-support, is there a way to use the IdentityFile option in ~/.ssh/config? When using ssh-agent i can point IdentityFile to the corresponding private key, but i don't know how i could do that using gpg-agent (esp. if the key is on card ;)) cheers, muri From yuriping at sohu.com Mon Jul 4 13:13:46 2016 From: yuriping at sohu.com (yuriping at sohu.com) Date: Mon, 04 Jul 2016 19:13:46 +0800 Subject: invoke gpg with popen but cannot get output from the pipe Message-ID: <1467630826.2c63378dd9134765a69d2089c98b42ed.yuriping@sohu.com> Hi all:    I'm using gpg 1.4.10.    Now I want to operate it in my program, and I want to get the output info of gpg from popen, in order that I can process them. Codes like the following:----------------------------------------------------------------#include <stdio.h>#include <sys/wait.h>#include <string.h>#include <stdlib.h>int main(void){    FILE *fpout = popen("gpg --verify yrp.sig yrp", "r");    char buf[1024];    bzero(buf, 1024);    int len = fread(buf, 1024, 1, fpout);    printf("The return of fread = %d, The length of the buf = %d\n", len, strlen(buf));    printf("%s\n", buf);    pclose(fpout);    exit (0);}----------------------------------------------------------------The result didn't appear normal:gpg: Signature made Mon 04 Jul 2016 06:14:44 PM CST using RSA key ID 5FEC9A32gpg: Good signature from "yuriping (3) <yuriping at sohu.com>"The return of fread = 0, The length of the buf = 0But when I popen "ls" as following, ----------------------------------------------------------------#include <stdio.h>#include <sys/wait.h>#include <string.h>#include <stdlib.h>int main(void){    FILE *fpout = popen("ls", "r");    char buf[1024];    bzero(buf, 1024);    int len = fread(buf, 1024, 1, fpout);    printf("The return of fread = %d, The length of the buf = %d\n", len, strlen(buf));    printf("%s\n", buf);    pclose(fpout);    exit (0);}----------------------------------------------------------------It worked properly:The return of fread = 0, The length of the buf = 60popen_lspopen_ls.csignsign.cverifyverify.cyrpyrp.sigIt seems that the output of gpg does not be redirected to the popen command buffer, it still output to the stdout.I want to know what causes the difference, and how to fix it. By the way, this issue appears when "popen("gpg --detach-sign yrp", "w")"Best Regards! ------------------------------------------ ???????????????????~ -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at digitalbrains.com Mon Jul 4 13:36:13 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 4 Jul 2016 13:36:13 +0200 Subject: gpg-agent and ~/.ssh/config IdentityFile In-Reply-To: <999987a0-6456-4683-072e-a801ce62e3e2@immerda.ch> References: <999987a0-6456-4683-072e-a801ce62e3e2@immerda.ch> Message-ID: <23324381-bcac-12db-c19e-4b665c9bebc0@digitalbrains.com> On 04/07/16 10:10, Muri Nicanor wrote: > if i use gpg-agent with ssh-support, is there a way to use the > IdentityFile option in ~/.ssh/config? When using ssh-agent i can point > IdentityFile to the corresponding private key, but i don't know how i > could do that using gpg-agent (esp. if the key is on card ;)) Are you talking about restricting the keys available for authentication? Because just using IdentityFile does not do that, as can be concluded from this part of the man page: > IdentityFile > Specifies a file from which the user's DSA, ECDSA, ED25519 or RSA > authentication identity is read. The default is ~/.ssh/identity > for protocol version 1, and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, > ~/.ssh/id_ed25519 and ~/.ssh/id_rsa for protocol version 2. Addi? > tionally, any identities represented by the authentication agent > will be used for authentication unless IdentitiesOnly is set. > [...] Note that last sentence. This documented behaviour is indeed working for me, as you can see in this example session: > $ ssh mscrabtree > Permission denied (publickey). Correct: my agent does not have the necessary key. > $ ssh butters > Linux butters [...] > [...] > peter at butters:~$ logout > Connection to butters closed. Correct: my agent does have the key for that host. > $ echo 'IdentityFile /home/peter/.ssh/test_id' | cat - ~/.ssh/config >~/.ssh/config.tmp; mv ~/.ssh/config.tmp ~/.ssh/config Adding the necessary config option you are asking about. Since it needs to go before any Host-specific config in there, I'm prepending it so it is the first line in the file. > $ ssh mscrabtree > Enter passphrase for key '/home/peter/.ssh/test_id': > > The programs included with the Debian GNU/Linux system are free software; > [...] > peter at mscrabtree:~$ logout > Connection to mscrabtree closed. Ah, I can log in, but not through the agent. It's the ssh program which is prompting me for the password. Since the agent doesn't have this key, only the ssh program knows about it. All as I would expect. > $ ssh butters > Linux butters [...] > [...] > peter at butters:~$ logout > Connection to butters closed. And again as expected. Per the documentation, the keys from the agent are also still available, even with added identities through "IdentityFile". So at least for me, it's functioning as I would expect it would after reading the documentation. I get the sense you're interested in a different configuration, one with IdentitiesOnly as well. Another possibility is that you are using a different OpenSSH version with different configuration options. I'm using: > $ ssh -V > OpenSSH_6.7p1 Debian-5+deb8u2, OpenSSL 1.0.1t 3 May 2016 My GnuPG is the Debian package 2.1.11-7. So can you clarify what it is you want to accomplish? HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From muri+gnupg-users at immerda.ch Mon Jul 4 15:15:07 2016 From: muri+gnupg-users at immerda.ch (Muri Nicanor) Date: Mon, 4 Jul 2016 15:15:07 +0200 Subject: gpg-agent and ~/.ssh/config IdentityFile In-Reply-To: <23324381-bcac-12db-c19e-4b665c9bebc0@digitalbrains.com> References: <999987a0-6456-4683-072e-a801ce62e3e2@immerda.ch> <23324381-bcac-12db-c19e-4b665c9bebc0@digitalbrains.com> Message-ID: Hello, On 07/04/2016 01:36 PM, Peter Lebbing wrote: > On 04/07/16 10:10, Muri Nicanor wrote: >> if i use gpg-agent with ssh-support, is there a way to use the >> IdentityFile option in ~/.ssh/config? When using ssh-agent i can point >> IdentityFile to the corresponding private key, but i don't know how i >> could do that using gpg-agent (esp. if the key is on card ;)) > > Are you talking about restricting the keys available for > authentication? [...] > > So at least for me, it's functioning as I would expect it would after > reading the documentation. I get the sense you're interested in a > different configuration, one with IdentitiesOnly as well. [...] > So can you clarify what it is you want to accomplish? yes, you're totally right. sorry for not being clear about this. i've Host * IdentitiesOnly yes at the beginning of my ~/.ssh/config. when authenticating to a host i only want to use the one identity/key i've created for that host instead of sending all of them to the server... cheers, muri From wolf at wolfsden.cz Mon Jul 4 21:43:10 2016 From: wolf at wolfsden.cz (Wolf) Date: Mon, 4 Jul 2016 21:43:10 +0200 Subject: Change agent-socket path In-Reply-To: <87twg9slhk.fsf@wheatstone.g10code.de> References: <20160630235820.fozic2jt4jrykdlx@wolfsden.cz> <87twg9slhk.fsf@wheatstone.g10code.de> Message-ID: <20160704194309.wvtghelzlmno6wxy@wolfsden.cz> On , Werner Koch wrote: > On Fri, 1 Jul 2016 01:58, wolf at wolfsden.cz said: > > > the building/signing is done in fakeroot environment. Therefore the > > socket path default to ~/.gnupg/S.gnu-agent. Because (at least it seems > > to me) in fakeroot I am root (0) and therefore don't own /run/user/1000 > > That is a very special case I would like to avoid an exception for this > (ie. relaxing the ownwed-by-user check). I did some thinking about this and I must admit that I don't see why the check is needing at all. In what situation relaxing the check would case security issues? > > What would be a good way to solve this issue? > > You can set the envvar GNUPGHOME to a different directory and this will > then be used for the socket and all other files - assuming that you did > not create a dedicated directory below /var/user/1000/gnupg for example > with "gpgconf --create-socketdir". So basically the "correct" solution are these two lines: cp -r ~/.gnupg /run/user/1000/gnupg gpg --homedir /run/user/1000/gnupg ? Since there is no way to provide the socket manually? That seems.. weird. W. PS: Apparently GPA is not working with 2.1.13 either ( https://bugs.archlinux.org/task/49930 ), but dunno if it's the same root cause. -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From wk at gnupg.org Mon Jul 4 23:37:57 2016 From: wk at gnupg.org (Werner Koch) Date: Mon, 04 Jul 2016 23:37:57 +0200 Subject: Change agent-socket path In-Reply-To: <20160704194309.wvtghelzlmno6wxy@wolfsden.cz> (wolf@wolfsden.cz's message of "Mon, 4 Jul 2016 21:43:10 +0200") References: <20160630235820.fozic2jt4jrykdlx@wolfsden.cz> <87twg9slhk.fsf@wheatstone.g10code.de> <20160704194309.wvtghelzlmno6wxy@wolfsden.cz> Message-ID: <87oa6d6q4q.fsf@wheatstone.g10code.de> On Mon, 4 Jul 2016 21:43, wolf at wolfsden.cz said: > I did some thinking about this and I must admit that I don't see why the > check is needing at all. In what situation relaxing the check would case Such a directory may already exist with sufficient permission for any user to create a socket. A local attacker may have created a server listening on a socket in this directory. Now gpg connects to that socket and a faked Pinentry catches the passphrase for the attacker. Sure, allowing root to bypass the check is in the Unix model not a problem. I only wonder whether this is really needed. > So basically the "correct" solution are these two lines: > > cp -r ~/.gnupg /run/user/1000/gnupg > gpg --homedir /run/user/1000/gnupg > > ? Since there is no way to provide the socket manually? That seems.. No. If you use a GNUPGHOME different from ~/.gnupg gpg will not connect to /run/user/1000/gnupg but to /run/user/1000/gnupg/SOMEDIR/. That dir is not created on the fly but requires that the user creates it in advance. SOMEDIR is the hash of GNUPGHOME and gpgconf has a command to compute that hash and create the directory. > PS: Apparently GPA is not working with 2.1.13 either ( > https://bugs.archlinux.org/task/49930 ), but dunno if it's the same root That is likley the bug fixed with GPA commit b9efe75ab7addb2eecd8e2274ed8907b9f6a3712 . Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From yuriping at sohu.com Tue Jul 5 13:38:53 2016 From: yuriping at sohu.com (yuriping at sohu.com) Date: Tue, 05 Jul 2016 19:38:53 +0800 Subject: How to invoke gpg command in C-program Message-ID: <1467718733.f31489efb71d492db9a022660df6ffae.yuriping@sohu.com> Hi ALL:    I'm using gpg 1.4.10 to perform sign-verify processing.    In general, two gpg commands will be used as following:    0. gpg --detach-sign file    1. gpg --verify file.sig file    I notice that in the executing process of command 0, a passphrase will be required to be typed manually;    and the return value in shell($?) of command 1 have the meanings : 0-verify successfully, 1-verify failed, 2-file opening failed;    Now I want to invoke these 2 commands in C-program in order that the process can be excuted automatically, but I do not know how to implement.    -- How can I input the passphrase for command 0 automatically? One way I know is to use gpg-agent, is it all right? And does gpg-agent 2.1.9 match with gpg 1.4.10?    -- How can I get the return value of command 1? I have tried using "popen", it does not worked and seemed that the output of gpg does not be redirected to the pipe.    Expect any suggestion.    Best Regards! ------------------------------------------ ???????????????????~ -------------- next part -------------- An HTML attachment was scrubbed... URL: From karol at babioch.de Tue Jul 5 17:55:47 2016 From: karol at babioch.de (Karol Babioch) Date: Tue, 5 Jul 2016 17:55:47 +0200 Subject: Migrating key to smartcard Message-ID: Hi, I've recently bought an OpenPGP smartcard and am now looking into ways to migrate my existing key onto this smartcard. I've created my key a couple of years back and have gathered some signatures, so I don't want to start over. Right now I have a master key with the "SC" key usage flags and a subkey for encryption ("E" key usage flag). Both of them are RSA 4096 keys. The smartcard expects three different keys, though: One for signing, encrypting and authenticating. What is the recommended way to migrate to the smartcard? I've read some threads about hacking the source code to be able to change the key usage for keys, and I'm fine with that. However, I'm not exactly sure what the end result should look like. Right now I'm thinking of creating two new subkeys (one for signatures, one for authentication) and signing them with the _old_ master key. I would also re-use the old sub-key for encryption (since it already has the "E" flag set and is well known). Then I would remove the master key from the computer (storing it only offline). I would then move the identity (including subkeys) onto the smartcard and remove the private keys from my keyring. Is this a good approach? Are there other and/or better ways? I'm also not sure what I would need the master key from this point onward. Since I would have a subkey with the "S" flag, couldn't I use this for signing other keys? Or would I still need to sign other keys with my master key? I'm grateful for any clarification and some hints. Thanks in advance. Best regards, Karol Babioch -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From dgouttegattat at incenp.org Tue Jul 5 20:07:02 2016 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Tue, 5 Jul 2016 20:07:02 +0200 Subject: Migrating key to smartcard In-Reply-To: References: Message-ID: <7d7c3f78-2f23-d49a-0dba-57fa7588c25b@incenp.org> On 07/05/2016 05:55 PM, Karol Babioch wrote: > The smartcard expects three different keys, though: One for signing, > encrypting and authenticating. What is the recommended way to migrate > to the smartcard? In your case, the simplest way would be to migrate your master key into the signing slot and the encryption subkey into the encryption slot. You may leave the authentication slot empty if you do not plan to use your smartcard for authentication purposes (e.g. authentication to a SSH server). > Right now I'm thinking of creating two new subkeys (one for > signatures, one for authentication) and signing them with the _old_ > master key. I would indeed recommend to generate a new signing subkey. You would then send it to the signing slot of the smartcard, and not put your master key on the smartcard at all. Regarding the authentication subkey, you have to do that only if you actually have a need for it (you seem to believe that you MUST fill all three slots of the OpenPGP card; it's not the case). > I would also re-use the old sub-key for encryption (since it already > has the "E" flag set and is well known). The fact that your encryption subkey is "well-known" is irrelevant. The master key is the only one which needs to be "known". It's one of the benefits of using subkeys: you can change the subkeys anytime without having to re-introduce the new subkeys into the web-of-trust. That being said, I agree with reusing your existing encryption subkey. Unless you believe it may have been compromised, there is no reason to generate a new one. > I would then move the identity (including subkeys) onto the > smartcard Not sure of what you mean by "moving the identity". The card can only contain the private keys. Your UIDs (and the associated signatures) would still be stored in your *public* keyring. > and remove the private keys from my keyring. GnuPG will automatically remove the private subkeys from your keyring when you migrate them to the smartcard, you do not have to that explicitly yourself. > I'm also not sure what I would need the master key from this point > onward. Since I would have a subkey with the "S" flag, couldn't I use > this for signing other keys? No, only the master key can sign other keys. But since signing keys is normally something that you don't do everyday, that should not discourage you from storing your private master key offline. You would bring it back online only on those (presumably rare) occurences when you need to sign a key. Hope that helps, Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From karol at babioch.de Tue Jul 5 21:27:57 2016 From: karol at babioch.de (Karol Babioch) Date: Tue, 5 Jul 2016 21:27:57 +0200 Subject: Migrating key to smartcard In-Reply-To: <7d7c3f78-2f23-d49a-0dba-57fa7588c25b@incenp.org> References: <7d7c3f78-2f23-d49a-0dba-57fa7588c25b@incenp.org> Message-ID: Hi, Am 05.07.2016 um 20:07 schrieb Damien Goutte-Gattat: > In your case, the simplest way would be to migrate your master key into > the signing slot and the encryption subkey into the encryption slot. Ok, although I quite don't like the idea and prefer option #2. > I would indeed recommend to generate a new signing subkey. You would > then send it to the signing slot of the smartcard, and not put your master key on the smartcard at all. That sounds more reasonable to me, since my master key would be completely offline and only be used on the rare occasions when signing other keys. I could even use an offline computer for that purpose. > Regarding the authentication subkey, you have to do that only if you > actually have a need for it Yes, I want to use for SSH authentication. > (you seem to believe that you MUST fill all three slots of the OpenPGP card; it's not the case). I know that, but thanks for the reminder. > Not sure of what you mean by "moving the identity". The card can only > contain the private keys. I knew this as well. I was referring to putting a set of keys into the smartcard when talking about "moving my identity". > No, only the master key can sign other keys. But since signing keys is > normally something that you don't do everyday, that should not > discourage you from storing your private master key offline. Is this a limitation of GPG and my premises or is this something inherent to the OpenPGP standard? With other public-key infrastructures (e.g. X509) it is perfectly fine to use signed (sub)keys to sign other keys and building chains in this very way. This would allow me to use the GPG smartcard for basically everything (including signing other keys). Storing the master key offline and having to import it whenever I want to sign other keys might actually decrease security, since it offers enough of a possiblity to mess things up (e.g. forget to remove it again or for malware to get ahold of it, since its only bits in memory (and/or on the storage device). Thanks for your input so far, its very much appreciated! Best regards, Karol Babioch -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Tue Jul 5 23:23:55 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 05 Jul 2016 17:23:55 -0400 Subject: gpg-agent and ~/.ssh/config IdentityFile In-Reply-To: References: <999987a0-6456-4683-072e-a801ce62e3e2@immerda.ch> <23324381-bcac-12db-c19e-4b665c9bebc0@digitalbrains.com> Message-ID: <87zipvu6c4.fsf@alice.fifthhorseman.net> You're right, this really is a better question for OpenSSH users. On Mon 2016-07-04 09:15:07 -0400, Muri Nicanor wrote: > at the beginning of my ~/.ssh/config. when authenticating to a host i > only want to use the one identity/key i've created for that host instead > of sending all of them to the server... Do you have a .pub file of the public part of your identity? try pointing Identities to that file. if you don't have such a file, you should be able to do: ssh-add -L filter the output to the line you want, save the filtered output to a file named "foo.pub" and then try with "ssh -i foo.pub remotehost" hth, --dkg From malsburg at posteo.de Tue Jul 5 23:57:48 2016 From: malsburg at posteo.de (Titus von der Malsburg) Date: Tue, 05 Jul 2016 14:57:48 -0700 Subject: Pinentry UI bug Message-ID: <871t37d9yb.fsf@posteo.de> I encrypted a file using symmetric encryption (gpg2 -c file.txt). Then I tried to decrypt it (in Emacs) which opened a pinentry window. I accidentally clicked on the check mark labeled ?save in password manager? and clicked ?Ok? without having entered the password. Opening the file obviously failed, but when I tried to open the file again, GPG apparently reused the empty password and didn?t give me the chance to enter the correct password. The error message was: gpg: AES encrypted data gpg: gcry_kdf_derive failed: Invalid data gpg: encrypted with 1 passphrase gpg: decryption failed: No secret key Now I?m stuck with an encrypted file that I can?t decrypt although I have the password. Question: How can I remove the incorrect password and restore the password prompt? I already tried a couple of things: - Kill gpg-agent. - Kill gnome-keyring-daemon. - Remove the stored key using Seahorse (failed because the key wasn?t listed in Seahorse). - Reboot the machine. None of it helped. Feature requests / bug reports: - Pinentry shouldn?t store the password when it?s wrong. - When decryption with a stored key fails, gpg should prompt the user for the correct password. - It should be transparent to the user where keys are stored. Specifically, the label in the pinentry window should be more information, e.g: ?Store password in Gnome keyring. Use seahorse to edit or remove.? Titus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From rjh at sixdemonbag.org Wed Jul 6 00:54:03 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 5 Jul 2016 18:54:03 -0400 Subject: How to invoke gpg command in C-program In-Reply-To: <1467718733.f31489efb71d492db9a022660df6ffae.yuriping@sohu.com> References: <1467718733.f31489efb71d492db9a022660df6ffae.yuriping@sohu.com> Message-ID: <2d9360a3-db43-8863-8435-f57294d0cb81@sixdemonbag.org> > Now I want to invoke these 2 commands in C-program in order that the > process can be excuted automatically, but I do not know how to implement. GPGME. From dkg at fifthhorseman.net Wed Jul 6 05:17:09 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 05 Jul 2016 23:17:09 -0400 Subject: Pinentry UI bug In-Reply-To: <871t37d9yb.fsf@posteo.de> References: <871t37d9yb.fsf@posteo.de> Message-ID: <87d1mrtpze.fsf@alice.fifthhorseman.net> Hi Titus-- On Tue 2016-07-05 17:57:48 -0400, Titus von der Malsburg wrote: > I encrypted a file using symmetric encryption (gpg2 -c file.txt). Then > I tried to decrypt it (in Emacs) which opened a pinentry window. I > accidentally clicked on the check mark labeled ?save in password > manager? and clicked ?Ok? without having entered the password. Opening > the file obviously failed, but when I tried to open the file again, GPG > apparently reused the empty password and didn?t give me the chance to > enter the correct password. The error message was: > > gpg: AES encrypted data > gpg: gcry_kdf_derive failed: Invalid data > gpg: encrypted with 1 passphrase > gpg: decryption failed: No secret key > > Now I?m stuck with an encrypted file that I can?t decrypt although I > have the password. > > Question: How can I remove the incorrect password and restore the > password prompt? pinentry most likely cached the password with your system's SecretService using libsecret, which can be implemented in different ways (though the common mechanism i've seen has been one implemented by the GNOME desktop, and which is accessible via gnome-keyring). https://developer.gnome.org/libsecret/unstable/SecretService.html on debian, there should be a libsecret-tools package that allows you to query the SecretService, though i don't have enough experience with it to help you beyond that pointer. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From dgouttegattat at incenp.org Wed Jul 6 10:25:58 2016 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Wed, 6 Jul 2016 10:25:58 +0200 Subject: Migrating key to smartcard In-Reply-To: References: <7d7c3f78-2f23-d49a-0dba-57fa7588c25b@incenp.org> Message-ID: On 07/05/2016 09:27 PM, Karol Babioch wrote: >> No, only the master key can sign other keys. > > Is this a limitation of GPG and my premises or is this something > inherent to the OpenPGP standard? According to the standard, any key with the "Certify" flag set can be used to sign other keys. And unless I'm mistaken, the standard does not explicitly restrict this flag to master keys only. So, I guess it should be possible (at least in theory) to have a subkey with this flag, and to use it to sign other keys. But I don't think GnuPG allows to do that (or any other OpenPGP implementation). > Storing the master key offline and having to import it whenever I want > to sign other keys might actually decrease security, since it offers > enough of a possiblity to mess things up True enough. In my case, I try to minimize the risk of human error by using a script which automatically brings the key online (from its offline USB storage), executes a single GnuPG command, then remove the key again. If you are interested, I've written a blog post [1] in which I give an example of such a script. Regards, Damien [1] https://incenp.org/notes/2015/using-an-offline-gnupg-master-key.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Wed Jul 6 11:37:14 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 6 Jul 2016 11:37:14 +0200 Subject: gpg-agent and ~/.ssh/config IdentityFile In-Reply-To: <87zipvu6c4.fsf@alice.fifthhorseman.net> References: <999987a0-6456-4683-072e-a801ce62e3e2@immerda.ch> <23324381-bcac-12db-c19e-4b665c9bebc0@digitalbrains.com> <87zipvu6c4.fsf@alice.fifthhorseman.net> Message-ID: On 05/07/16 23:23, Daniel Kahn Gillmor wrote: > You're right, this really is a better question for OpenSSH users. Well, I'm stubborn, and I'm still going to answer here :-). > Do you have a .pub file of the public part of your identity? try > pointing Identities to that file. Yes, that occured to me as well as a possibility to try. It turned out to be the correct idea. With default config, no restrictions: > $ ssh-add -l > 2048 27:f1:31:87:c8:05:5e:30:32:04:61:83:af:f5:8d:a1 cardno:000500000241 (RSA) > 2048 69:22:fd:08:4e:a5:77:c5:2c:1c:c5:e4:e3:e0:96:96 /home/peter/.ssh/id_rsa (RSA) > 256 03:92:b4:ff:0b:8c:dc:39:63:d0:18:c1:1e:78:12:ff test_id (ED25519) > $ ssh -vvv mscrabtree > OpenSSH_6.7p1 Debian-5+deb8u2, OpenSSL 1.0.1t 3 May 2016 > debug1: Reading configuration data /home/peter/.ssh/config > [...] > debug1: Offering RSA public key: /home/peter/.ssh/id_rsa > debug3: send_pubkey_test > debug2: we sent a publickey packet, wait for reply > debug1: Server accepts key: pkalg ssh-rsa blen 277 > debug2: input_userauth_pk_ok: fp 69:22:fd:08:4e:a5:77:c5:2c:1c:c5:e4:e3:e0:96:96 > debug3: sign_and_send_pubkey: RSA 69:22:fd:08:4e:a5:77:c5:2c:1c:c5:e4:e3:e0:96:96 > Agent admitted failure to sign using the key. > debug1: Offering RSA public key: cardno:000500000241 > debug3: send_pubkey_test > debug2: we sent a publickey packet, wait for reply > debug1: Server accepts key: pkalg ssh-rsa blen 279 > debug2: input_userauth_pk_ok: fp 27:f1:31:87:c8:05:5e:30:32:04:61:83:af:f5:8d:a1 > debug3: sign_and_send_pubkey: RSA 27:f1:31:87:c8:05:5e:30:32:04:61:83:af:f5:8d:a1 > Agent admitted failure to sign using the key. > debug1: Offering ED25519 public key: test_id > debug3: send_pubkey_test > debug2: we sent a publickey packet, wait for reply > debug1: Server accepts key: pkalg ssh-ed25519 blen 51 > debug2: input_userauth_pk_ok: fp 03:92:b4:ff:0b:8c:dc:39:63:d0:18:c1:1e:78:12:ff > debug3: sign_and_send_pubkey: ED25519 03:92:b4:ff:0b:8c:dc:39:63:d0:18:c1:1e:78:12:ff > Agent admitted failure to sign using the key. I'm not entering any password on purpose, so it will try more keys. And it offered all it had (since I configured the server to accept them all). Now with: > $ cat .ssh/config > [...] > IdentitiesOnly yes > > [...] > Host mscrabtree > IdentityFile /home/peter/.ssh/id_card.pub > $ ssh -vvv mscrabtree > [...] > debug1: Offering RSA public key: /home/peter/.ssh/id_card.pub > debug3: send_pubkey_test > debug2: we sent a publickey packet, wait for reply > debug1: Server accepts key: pkalg ssh-rsa blen 279 > debug2: input_userauth_pk_ok: fp 27:f1:31:87:c8:05:5e:30:32:04:61:83:af:f5:8d:a1 > debug3: sign_and_send_pubkey: RSA 27:f1:31:87:c8:05:5e:30:32:04:61:83:af:f5:8d:a1 > Agent admitted failure to sign using the key. > debug2: we did not send a packet, disable method > debug1: No more authentication methods to try. > Permission denied (publickey). It only offers my smartcard. Change it to > IdentityFile /home/peter/.ssh/test_id.pub > $ ssh -vvv mscrabtree > [...] > debug1: Offering ED25519 public key: /home/peter/.ssh/test_id.pub > debug3: send_pubkey_test > debug2: we sent a publickey packet, wait for reply > debug1: Server accepts key: pkalg ssh-ed25519 blen 51 > debug2: input_userauth_pk_ok: fp 03:92:b4:ff:0b:8c:dc:39:63:d0:18:c1:1e:78:12:ff > debug3: sign_and_send_pubkey: ED25519 03:92:b4:ff:0b:8c:dc:39:63:d0:18:c1:1e:78:12:ff > Agent admitted failure to sign using the key. > debug2: we did not send a packet, disable method > debug1: No more authentication methods to try. > Permission denied (publickey). It only offers the key test_id. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From muri+gnupg-users at immerda.ch Wed Jul 6 14:06:52 2016 From: muri+gnupg-users at immerda.ch (Muri Nicanor) Date: Wed, 6 Jul 2016 14:06:52 +0200 Subject: gpg-agent and ~/.ssh/config IdentityFile In-Reply-To: <87zipvu6c4.fsf@alice.fifthhorseman.net> References: <999987a0-6456-4683-072e-a801ce62e3e2@immerda.ch> <23324381-bcac-12db-c19e-4b665c9bebc0@digitalbrains.com> <87zipvu6c4.fsf@alice.fifthhorseman.net> Message-ID: Hi, On 07/05/2016 11:23 PM, Daniel Kahn Gillmor wrote: > You're right, this really is a better question for OpenSSH users. > > On Mon 2016-07-04 09:15:07 -0400, Muri Nicanor wrote: >> at the beginning of my ~/.ssh/config. when authenticating to a host i >> only want to use the one identity/key i've created for that host instead >> of sending all of them to the server... > > Do you have a .pub file of the public part of your identity? try > pointing Identities to that file. > > if you don't have such a file, you should be able to do: > > ssh-add -L > > filter the output to the line you want, save the filtered output to a > file named "foo.pub" and then try with "ssh -i foo.pub remotehost" Thanks a lot! I didn't know that i can use the public key for the IdentityFile. As Peter already wrote, that works, and i can now use my openpgp card for ssh auth without disclosing all my other keys to the server ;) thanks, muri From daniel at hillsdalecorp.com Wed Jul 6 16:45:16 2016 From: daniel at hillsdalecorp.com (Daniel Werner) Date: Wed, 6 Jul 2016 07:45:16 -0700 Subject: Unsubscribe Message-ID: <4B16E6C9-1D66-4748-9688-F988DC8D2C68@hillsdalecorp.com> Please remove me from this list. ***************************** Daniel H. Werner Hillsdale Corporation 9 Oregon Yacht Club Portland, Oregon 97202 USA Cell: +1-503-709-0950 www.hillsdalecorp.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dashohoxha at gmail.com Wed Jul 6 19:41:22 2016 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Wed, 6 Jul 2016 19:41:22 +0200 Subject: Migrating key to smartcard In-Reply-To: References: <7d7c3f78-2f23-d49a-0dba-57fa7588c25b@incenp.org> Message-ID: On Wed, Jul 6, 2016 at 10:25 AM, Damien Goutte-Gattat < dgouttegattat at incenp.org> wrote: > > Storing the master key offline and having to import it whenever I want >> to sign other keys might actually decrease security, since it offers >> enough of a possiblity to mess things up >> > > True enough. In my case, I try to minimize the risk of human error by > using a script which automatically brings the key online (from its offline > USB storage), executes a single GnuPG command, then remove the key again. > > If you are interested, I've written a blog post [1] in which I give an > example of such a script. > I would suggest the script key2dongle which is part of egpg: - https://github.com/dashohoxha/egpg/wiki/gnupg-2.1-key2dongle - https://github.com/dashohoxha/egpg/blob/gnupg-2.1/src/ext/cmd_key2dongle.sh It implements the symlink solution described at the end of the Damien's blog post. Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From dashohoxha at gmail.com Wed Jul 6 19:47:34 2016 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Wed, 6 Jul 2016 19:47:34 +0200 Subject: Migrating key to smartcard In-Reply-To: References: <7d7c3f78-2f23-d49a-0dba-57fa7588c25b@incenp.org> Message-ID: On Wed, Jul 6, 2016 at 7:41 PM, Dashamir Hoxha wrote: > > I would suggest the script key2dongle which is part of egpg: > - https://github.com/dashohoxha/egpg/wiki/gnupg-2.1-key2dongle > - > https://github.com/dashohoxha/egpg/blob/gnupg-2.1/src/ext/cmd_key2dongle.sh > By the way, do you think that `egpg` should be added somewhere on the list of GPG related software? - https://www.gnupg.org/related_software/frontends.html - https://www.gnupg.org/related_software/tools.html Or maybe I should fill a "Problem Report" form for this? Dashamir -------------- next part -------------- An HTML attachment was scrubbed... URL: From juanmi.3000 at gmail.com Wed Jul 6 20:02:04 2016 From: juanmi.3000 at gmail.com (=?UTF-8?Q?Juan_Miguel_Navarro_Mart=c3=adnez?=) Date: Wed, 6 Jul 2016 20:02:04 +0200 Subject: Unsubscribe In-Reply-To: <4B16E6C9-1D66-4748-9688-F988DC8D2C68@hillsdalecorp.com> References: <4B16E6C9-1D66-4748-9688-F988DC8D2C68@hillsdalecorp.com> Message-ID: <9db1aa09-4b57-f604-ebb1-8fe1f32b72e0@gmail.com> If you follow the link in the footer of all emails in this list, you'll get into the mail list, web page. On there, you can unsubscribe yourself by inputing your mail address in the bottommost text box and clicking on "Unsubscribe or edit options". On 2016-07-06 at 16:45, Daniel Werner wrote: > > Please remove me from this list. > > > > ***************************** > Daniel H. Werner > Hillsdale Corporation > 9 Oregon Yacht Club > Portland, Oregon 97202 USA > Cell: +1-503-709-0950 > www.hillsdalecorp.com > > > > > > > > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- Juan Miguel Navarro Mart?nez GPG Keyfingerprint: 5A91 90D4 CF27 9D52 D62A BC58 88E2 947F 9BC6 B3CF From peter at digitalbrains.com Wed Jul 6 20:23:21 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 6 Jul 2016 20:23:21 +0200 Subject: Migrating key to smartcard In-Reply-To: References: <7d7c3f78-2f23-d49a-0dba-57fa7588c25b@incenp.org> Message-ID: <303ed2e0-64dd-19ee-f8e5-f2c09b8b88a2@digitalbrains.com> On 06/07/16 10:25, Damien Goutte-Gattat wrote: > True enough. In my case, I try to minimize the risk of human error by > using a script which automatically brings the key online (from its > offline USB storage), executes a single GnuPG command, then remove the > key again. What is the threat model that this procedure thwarts? I don't think this is what is usually meant by an "offline primary key". The idea is that you have a separate computer for your primary key, not that you import it now and then. Unless I misinterpreted it myself. What's the practical difference between only typing in the password for the primary key when you need it and only storing it on local disk when you need it? I think usually a compromised PC doesn't spontaneously become uncompromised later on, it stays compromised. As soon as you use the primary key, it is compromised as well. And as long as you don't type your high quality passphrase, good luck to an attacker with just your encrypted key, they shouldn't be able to use it. I myself have my primary key on a different smart card than the subkeys. With GnuPG versions before 2.1, this required some "packet surgery", it's not really well supported. I think 2.1 will happily do this out of the box. By the way, I'm implying that you use a different passphrase for your primary key than for your subkeys. Again, with 2.1, easy, before that, packet surgery, I think. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From peter at digitalbrains.com Wed Jul 6 20:33:48 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 6 Jul 2016 20:33:48 +0200 Subject: That blog post, factual error or not? In-Reply-To: References: <7d7c3f78-2f23-d49a-0dba-57fa7588c25b@incenp.org> Message-ID: Hi Damien, I scanned through your blog post[1] before I wrote my reply. Now as I was about to close the webpage, my eye caught this remark in a smaller font at the bottom: > GnuPG Agent only caches the passphrase protecting the key, never the > key itself?it reads the key from file everytime the key is required, > which means that as soon as the key file is removed from the agent?s > directory, the key is no longer available; Is this actually the case though? Have you checked the source or did an strace? Before v2.1, gpg-agent only cached passphrases for OpenPGP usage, and the gpg/gpg2-binary did the actual decrypting and using of the private key material. However, in v2.1, the agent itself is responsible for using the private key. I haven't looked at the internal design, perhaps only the passphrase is cached and the key is decrypted from disk each time. But that seems like a rather indirect method to solve it, why not cache the decrypted key instead of the passphrase? In fact, when you export a key, it will always prompt for a passphrase, because it needs it to construct an OpenPGP private key packet. Why would it need to do that if it had the passphrase cached? I think it keeps the key cached, and discards knowledge of the passphrase as no longer relevant. Of course, there are more steps between passphrase and key file, perhaps it only stores one of those intermediate steps, which could explain it as well. I think the behaviour you are seeing might be that the agent notices you removed the key, and it will forget about it. But it deliberately forgets, it's not that it actually needs the file you removed. Of course, if you checked the source, you know more than I. I just found the comment surprising, so I thought I'd ask. Cheers, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From dgouttegattat at incenp.org Wed Jul 6 21:03:11 2016 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Wed, 6 Jul 2016 21:03:11 +0200 Subject: That blog post, factual error or not? In-Reply-To: References: <7d7c3f78-2f23-d49a-0dba-57fa7588c25b@incenp.org> Message-ID: Hi Peter, On 07/06/2016 08:33 PM, Peter Lebbing wrote: >> GnuPG Agent only caches the passphrase protecting the key, never the >> key itself?it reads the key from file everytime the key is required, >> which means that as soon as the key file is removed from the agent?s >> directory, the key is no longer available; > > Is this actually the case though? Have you checked the source Yes I did. That's how I found out this behavior actually. If you want to check by yourself, have a look for example at the function agent_pkdecrypt (in the agent/pkdecrypt.c file), which implements the agent's PKDECRYPT command. One of the first thing this function does is to call agent_key_from_file (defined in agent/findkey.c), which *inconditionnally* reads the key from its file storage. The key is freed at the end of the agent_pkdecrypt function, without having been cached anywhere (only the passphrase is cached, in the function unprotect.c in agent/findkey.c). The agent_pksign function, which implements the PKSIGN command and needs the signing (sub)key, behaves similarly. Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Wed Jul 6 21:51:39 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 6 Jul 2016 21:51:39 +0200 Subject: That blog post, factual error or not? In-Reply-To: References: <7d7c3f78-2f23-d49a-0dba-57fa7588c25b@incenp.org> Message-ID: <2dfd1ec9-d3bb-f7ad-db72-4802e0e196b3@digitalbrains.com> On 06/07/16 21:03, Damien Goutte-Gattat wrote: > Yes I did. That's how I found out this behavior actually. Ah, okay, thanks for the extensive info! I wouldn't have expected that. There's probably a good reason :-). Cheers, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From Roman.Fiedler at ait.ac.at Thu Jul 7 11:32:30 2016 From: Roman.Fiedler at ait.ac.at (Fiedler Roman) Date: Thu, 7 Jul 2016 09:32:30 +0000 Subject: Decrypting multiple encrypted blocks on one stream using GPG Message-ID: <2ECE9D9EEF1F524185270138AE23265954FAAABE@S0MSMAIL112.arc.local> Hello List, I'm trying to use gnupg to solve a usecase similar to the one depicted in [1], but the workaround from [1] is not suitable, because: * Each file I have is larger than the machine holding the keys * The keys cannot be moved * The streams will take hours/days to decrypt so no interruption is possible. I would use following scheme to solve it: * Have wrapper passing stdin (fd=0) unmodified to newly forked gnupg instance * Read passwords from tty not stdin If I understand correctly, gnupg will not overread on stdin, so no packet headers will be consumed on error by previous gnupg process on error after finishing the payload packet. A problem that remains: I have to make gnupg ask for each key password indefinitely long. As gnupg needs to read the header to find the correct private key, termination after the 3rd password would break the stream. Is there any way to make gpg repeat the password question over and over? Not yet applicable, but perhaps for next level: Same for keyring with multiple keys, but where encrypted content was created with "--throw-key-ids". Roman [1] http://superuser.com/questions/621315/gpg-decrypting-multiple-files-in-one-s tream DI Roman Fiedler Scientist Digital Safety & Security Department Assistive Healthcare Information Technology AIT Austrian Institute of Technology GmbH Reininghausstra?e 13/1 | 8020 Graz | Austria T +43(0) 50550 2957 | M +43(0) 664 8561599 | F +43(0) 50550 2950 roman.fiedler at ait.ac.at | http://www.ait.ac.at/ FN: 115980 i HG Wien? |? UID: ATU14703506 http://www.ait.ac.at/Email-Disclaimer -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6344 bytes Desc: not available URL: From neal at walfield.org Fri Jul 8 14:24:34 2016 From: neal at walfield.org (Neal H. Walfield) Date: Fri, 08 Jul 2016 14:24:34 +0200 Subject: Decrypting multiple encrypted blocks on one stream using GPG In-Reply-To: <2ECE9D9EEF1F524185270138AE23265954FAAABE@S0MSMAIL112.arc.local> References: <2ECE9D9EEF1F524185270138AE23265954FAAABE@S0MSMAIL112.arc.local> Message-ID: <87furknwql.wl-neal@walfield.org> On Thu, 07 Jul 2016 11:32:30 +0200, Fiedler Roman wrote: > I'm trying to use gnupg to solve a usecase similar to the one depicted in > [1], but the workaround from [1] is not suitable, because: > > * Each file I have is larger than the machine holding the keys > * The keys cannot be moved > * The streams will take hours/days to decrypt so no interruption is > possible. You might be able to use gpg's --extra-socket feature to solve your problem. Using this feature, gpg could do the asymmetric crypto on your small box (this just costs some KB of network traffic) and the symmetric on some other box. :) Neal From gcircuit at hotmail.com Sun Jul 10 02:57:51 2016 From: gcircuit at hotmail.com (Kob S) Date: Sun, 10 Jul 2016 00:57:51 +0000 Subject: Side-By-Side Installation: Gpg4win and gnuPG Message-ID: Hello, I am using gpg4win V. 2.3.2 on a WIN7 machine, but I want to test the gnuPG 2.1.13 on the same machine, using the CLI, without interfering with the existing gpg4win installation. I downloaded and expanded the gnuPG 2.1.13 Windows CLI archive into a new directory, and made sure to fully exit gpg4win. Running C:\gnupg2.1.13\gpg --expert --full-gen-key I got the following message: "gpg: starting migration from earlier GnuPG versions" and an attempt to connect by an agent using IPC to a socket on the local machine - which I blocked by my firewall to avoid messing up my existing gpg4win installation. I suspect that gnuPG is looking at the same \AppData\Roaming\gnupg directory that is being used by gpg4win. If that is the case, is there a way to force gnuPG to use a different directory? I could not find any config file that would let me do that. Thanks for any help, Rimma From wk at gnupg.org Mon Jul 11 12:11:17 2016 From: wk at gnupg.org (Werner Koch) Date: Mon, 11 Jul 2016 12:11:17 +0200 Subject: [Announce] OpenPGP.conf program published Message-ID: <87eg704h8a.fsf@wheatstone.g10code.de> Hello! Seven week ago the GUUG published a call for presentations for the first public conference on the OpenPGP protocol, taking place in Cologne on September 8+9. Meanwhile the program committee selected the talks and published the schedule at https://www.openpgp-conf.org/program.html I'd be pleased to see many of you there to discuss topics around OpenPGP. Registration recently opened; see https://www.openpgp-conf.org/registration.html Here is a brief overview on the program; see the web page for more: Thursday, September 8th: 09:30 A Simple Solution to Key Discovery / Werner Koch 10:15 Transparent Key Management at LEAP / meskio 11:00 Coffee break 11:30 The Mathematical Mesh: Management of Keys / Phillip Hallam-Baker 12:15 OpenPGP.js and the Mailvelope Key Server / Tankred Hase 13:00 Lunch 14:30 Building a Vision for GnuPG / Bernhard Reiter 15:15 NEXTLEAP and Automatic E2E emails / Holger Krekel 16:00 Coffee break 16:30 A few concerns regarding PGP, new directions / Stefan 'stf' Marsiske 17:15 History of OpenPGP / Lutz Donnerhacke 18:00 Key signing 18:30 Social event Friday, September 9th: 09:30 Automated use of GnuPG through GPGME / Andre Heinecke 10:15 Gnuk 1.2 / Niibe Yutaka 11:00 Coffee break 11:30 OpenKeychain UX Decisions / Dominik S. and Vincent B. 12:15 Bypass Pinentry for good via ... / Seiya Kawashima 13:00 Lunch 14:30 An analysis of OpenPGP key usage / Sven Braun 15:15 GnuPG in Debian / Daniel Kahn Gillmor 16:00 Coffee break 16:30 Closing Event Thanks to all who submitted their talk proposals. Salam-Shalom, Werner p.s. https://openpgp-conf.org is mirrored at https://gnupg.org/conf -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 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 gcircuit at hotmail.com Mon Jul 11 12:48:06 2016 From: gcircuit at hotmail.com (Kob S) Date: Mon, 11 Jul 2016 10:48:06 +0000 Subject: Side-By-Side Installation: Gpg4win and gnuPG In-Reply-To: <3412204.nRTW5TOBGT@esus> References: , <3412204.nRTW5TOBGT@esus> Message-ID: >To avoid that you should specify --homedir c:\testhome or something on the >commandline to 2.1 calls. Then it will use that as a different homedir. >e.g.: gpg --homedir c:\testhome --expert --full-gen-key This works now like a charm. Thanks, Rimma From aheinecke at intevation.de Mon Jul 11 11:36:28 2016 From: aheinecke at intevation.de (Andre Heinecke) Date: Mon, 11 Jul 2016 11:36:28 +0200 Subject: Side-By-Side Installation: Gpg4win and gnuPG In-Reply-To: References: Message-ID: <3412204.nRTW5TOBGT@esus> Hi, On Sunday 10 July 2016 00:57:51 Kob S wrote: > Running C:\gnupg2.1.13\gpg --expert --full-gen-key > ... > I suspect that gnuPG is looking at the same \AppData\Roaming\gnupg > directory that is being used by gpg4win. If that is the case, is there a > way to force gnuPG to use a different directory? I could not find any > config file that would let me do that. > > Thanks for any help, Although using the same homedir should not hurt much, gnupg-2.1 will migrate your secret keys to a new format but leave the files in a way that gnupg-2.0 can still read them. But there will be problems with the gnupg-agent as gnupg needs the same version of the agent that the program belongs to. To avoid that you should specify --homedir c:\testhome or something on the commandline to 2.1 calls. Then it will use that as a different homedir. e.g.: gpg --homedir c:\testhome --expert --full-gen-key would generate you a key in c:\testhome Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: This is a digitally signed message part. URL: From davidmatthewslb at gmail.com Tue Jul 12 16:46:53 2016 From: davidmatthewslb at gmail.com (David Matthews) Date: Tue, 12 Jul 2016 15:46:53 +0100 Subject: gpg-preset-passphrase not working with 2.1 Message-ID: I can't get gpg-preset-passphrase to work with GnuPG 2.1.7. The command appears to work successfully but the passphase is not found by GET_PASSPHRASE. I've included details of my simple test below plus the output from running it on Centos 7.2 (where it works using 2.0.22) and Fedora 23 (where it fails using 2.1.7). Searching through the issue tracker I found https://bugs.gnupg.org/gnupg/issue2015. The title of this issue is "GET_PASSPHRASE with --no-ask always return error in gnupg 2.1.5" but, based on the discussion in the issue, I think the title should really be "gpg-preset-passphrase does not work". Have I understood that correctly? If so I assume I will see the same issue with the latest release? Any advice much appreciated. My setup relies on using gpg-preset-passphrase so I'll need to install 2.0 for the moment unless I can get this working. Thanks, David ## Test script #!/bin/bash set -x eval "$(gpg-agent -vv --daemon --allow-preset-passphrase --debug-level 9)" /usr/libexec/gpg-preset-passphrase -vv --preset -P test myid echo "GET_PASSPHRASE --no-ask myid Err Pmt Des" | gpg-connect-agent -vv ## Centos 7.2 output ++ gpg-agent -vv --daemon --allow-preset-passphrase --debug-level 9 gpg-agent[3239]: enabled debug flags: command mpi crypto memory cache memstat assuan gpg-agent[3239]: listening on socket `/home/vagrant/.gnupg/S.gpg-agent' gpg-agent[3240]: gpg-agent (GnuPG) 2.0.22 started + eval 'GPG_AGENT_INFO=/home/vagrant/.gnupg/S.gpg-agent:3240:1; export GPG_AGENT_INFO;' ++ GPG_AGENT_INFO=/home/vagrant/.gnupg/S.gpg-agent:3240:1 ++ export GPG_AGENT_INFO + /usr/libexec/gpg-preset-passphrase -vv --preset -P test myid gpg-agent[3240]: handler 0xcfcb70 for fd 7 started gpg-agent[3240]: chan_7 -> OK Pleased to meet you, process 3241 gpg-agent[3240]: chan_7 <- OPTION display=localhost:10.0 gpg-agent[3240]: chan_7 -> OK gpg-agent[3240]: chan_7 <- OPTION ttyname=/dev/pts/1 gpg-agent[3240]: chan_7 -> OK gpg-agent[3240]: chan_7 <- OPTION ttytype=dumb gpg-agent[3240]: chan_7 -> OK gpg-agent[3240]: chan_7 <- OPTION lc-ctype=en_US.UTF-8 gpg-agent[3240]: chan_7 -> OK gpg-agent[3240]: chan_7 <- OPTION lc-messages=en_US.UTF-8 gpg-agent[3240]: chan_7 -> OK gpg-agent[3240]: chan_7 <- PRESET_PASSPHRASE myid -1 74657374 gpg-agent[3240]: DBG: agent_put_cache `myid' requested ttl=-1 mode=1 gpg-agent[3240]: chan_7 -> OK gpg-agent[3240]: chan_7 <- [eof] gpg-agent[3240]: handler 0xcfcb70 for fd 7 terminated + echo 'GET_PASSPHRASE --no-ask myid Err Pmt Des' + gpg-connect-agent -vv gpg-agent[3240]: handler 0xcfe550 for fd 7 started gpg-agent[3240]: chan_7 -> OK Pleased to meet you, process 3243 gpg-connect-agent: connection to agent established gpg-agent[3240]: chan_7 <- RESET gpg-agent[3240]: chan_7 -> OK gpg-agent[3240]: chan_7 <- OPTION ttytype=dumb gpg-agent[3240]: chan_7 -> OK gpg-agent[3240]: chan_7 <- OPTION display=localhost:10.0 gpg-agent[3240]: chan_7 -> OK gpg-agent[3240]: chan_7 <- GET_PASSPHRASE --no-ask myid Err Pmt Des gpg-agent[3240]: DBG: agent_get_cache `myid'... gpg-agent[3240]: DBG: ... hit gpg-agent[3240]: chan_7 -> [[Confidential data not shown]] OK 74657374 gpg-connect-agent: closing connection to agent ## Fedora 23 output ++ gpg-agent -vv --daemon --allow-preset-passphrase --debug-level 9 gpg-agent[1420]: enabled debug flags: command mpi crypto memory cache memstat ipc gpg-agent[1420]: listening on socket '/home/vagrant/.gnupg/S.gpg-agent' gpg-agent[1421]: gpg-agent (GnuPG) 2.1.7 started + eval '' + /usr/libexec/gpg-preset-passphrase -vv --preset -P test myid gpg-agent[1421]: handler 0x7f8092ffc700 for fd 4 started gpg-agent[1421]: DBG: chan_4 -> OK Pleased to meet you, process 1422 gpg-agent[1421]: DBG: chan_4 <- OPTION ttyname=/dev/pts/1 gpg-agent[1421]: DBG: chan_4 -> OK gpg-agent[1421]: DBG: chan_4 <- OPTION ttytype=dumb gpg-agent[1421]: DBG: chan_4 -> OK gpg-agent[1421]: DBG: chan_4 <- OPTION lc-ctype=en_US.UTF-8 gpg-agent[1421]: DBG: chan_4 -> OK gpg-agent[1421]: DBG: chan_4 <- OPTION lc-messages=en_US.UTF-8 gpg-agent[1421]: DBG: chan_4 -> OK gpg-agent[1421]: DBG: chan_4 <- PRESET_PASSPHRASE myid -1 74657374 gpg-agent[1421]: DBG: agent_put_cache 'myid' (mode 1) requested ttl=-1 gpg-agent[1421]: DBG: chan_4 -> OK gpg-agent[1421]: DBG: chan_4 <- [eof] gpg-agent[1421]: handler 0x7f8092ffc700 for fd 4 terminated + echo 'GET_PASSPHRASE --no-ask myid Err Pmt Des' + gpg-connect-agent -vv gpg-agent[1421]: handler 0x7f8092ffc700 for fd 4 started gpg-agent[1421]: DBG: chan_4 -> OK Pleased to meet you, process 1425 gpg-agent[1421]: DBG: chan_4 <- RESET gpg-agent[1421]: DBG: chan_4 -> OK gpg-agent[1421]: DBG: chan_4 <- OPTION ttytype=dumb gpg-agent[1421]: DBG: chan_4 -> OK gpg-agent[1421]: DBG: chan_4 <- OPTION putenv=INSIDE_EMACS=24.5.1,comint gpg-agent[1421]: DBG: chan_4 -> OK gpg-agent[1421]: DBG: chan_4 <- GET_PASSPHRASE --no-ask myid Err Pmt Des gpg-agent[1421]: DBG: agent_get_cache 'myid' (mode 3) ... gpg-agent[1421]: DBG: ... miss gpg-agent[1421]: command 'GET_PASSPHRASE' failed: No data gpg-agent[1421]: DBG: chan_4 -> ERR 67108922 No data ERR 67108922 No data gpg-connect-agent: closing connection to agent gpg-agent[1421]: DBG: chan_4 <- [eof] gpg-agent[1421]: handler 0x7f8092ffc700 for fd 4 terminated From Alexander.Strobel at giepa.de Tue Jul 12 17:38:10 2016 From: Alexander.Strobel at giepa.de (Alexander Strobel) Date: Tue, 12 Jul 2016 17:38:10 +0200 Subject: Gpg 2.1.13 Import from keyserver ip not working Message-ID: <63097f31-72ba-bc85-dac3-4e84da32360f@giepa.de> I'm not sur eif this has been reported here recently, but I am not able to import keys from ip addresses. gpg --keyserver hkp://127.0.0.1 --search-key test gpg: Kein Schl?sselserver bekannt (Option --keyserver verwenden) gpg: Suche auf dem Schl?sselserver fehlgeschlagen: Kein Schl?sselserver verf?gbar When I use the keyservers name (hkp://keys.example.com) everything works fine. Is this a known bug? Best regards Alex Strobel www.gpg4o.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Wed Jul 13 14:13:02 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 13 Jul 2016 14:13:02 +0200 Subject: gpg-preset-passphrase not working with 2.1 In-Reply-To: References: Message-ID: <87shvdohwx.fsf@alice.fifthhorseman.net> Hi David-- On Tue 2016-07-12 16:46:53 +0200, David Matthews wrote: > I can't get gpg-preset-passphrase to work with GnuPG 2.1.7. there have been significant changes to GnuPG between 2.1.7 and 2.1.13. can you try upgrading to 2.1.13? --dkg From xlbaron at li.ru Fri Jul 1 12:02:34 2016 From: xlbaron at li.ru (=?KOI8-R?Q?=EB=CF=D2=C5=CE=D8_=FA=CC=C1?=) Date: Fri, 1 Jul 2016 13:02:34 +0300 Subject: Solid Crypting for GNUPG Message-ID: <20160701130234.9dad83b9c96228d7045ef5aa@li.ru> -For developers of GNUPG- Can u get policy for adding a new open-non-patent algorythms for crypting in new versions of GNUPG without modules to it?I still aint get any new module and dunno how to add it at Linux. Collect any open algorytms and release it in new GNUPG versions.Also give algorythms developers any contact for adding it code to GNUPG. Thanks,Victor.A,GNUPG user from Russia. From riber at calico-jack.dk Mon Jul 4 07:07:05 2016 From: riber at calico-jack.dk (Mikkel Riber) Date: Mon, 4 Jul 2016 07:07:05 +0200 Subject: SV: Unable to batch decrypt messages on Windows In-Reply-To: <331517645.20160624191738@riseup.net> References: <000001d1cd30$6f1a1680$4d4e4380$@calico-jack.dk> <331517645.20160624191738@riseup.net> Message-ID: <000601d1d5b1$ea25ab80$be710280$@calico-jack.dk> Thank you very much for you input - much appreciated. Yes, it worked with empty password. Then it is possible to decrypt passwords without interaction. I would however prefer to have password - any suggestions to get this to work with password? -----Oprindelig meddelelse----- Fra: MFPA [mailto:2014-667rhzu3dc-lists-groups at riseup.net] Sendt: 24. juni 2016 20:18 Til: Mikkel Riber on GnuPG-Users Cc: Mikkel Riber Emne: Re: Unable to batch decrypt messages on Windows -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thursday 23 June 2016 at 10:20:06 AM, in , Mikkel Riber wrote: > Any input is welcome, thank you. Does it work if you simply use a key for which you have set an empty password? - -- Best regards MFPA You can't build a reputation on what you are going to do -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJXbXlLXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2 QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwbNkH/19khCFnXCmwDW0NX4bnfaPe QTW78fKxCNdSWoknzVpQOa496LZwVUIt5PwPACm8a1+6/MPNB5XUwgjUazX797Wd n+6mM+G74iLawjQrPiXjjwDbEy4cGIkzjz5+To/jptNTNFSDWYKfVhWAe9TOw0Md tMWoqnmFfsd3UrbaCEryBgaNyu7EUhAzm6RU5hPwTrmLzQFgrI3pFR30GNWNQmcb QDqMJ7rihM7nrk4F+XgdwgKk/Hs61CQB3ZTgd4KAr90VNn+hbeoqQ7CUTZCiJs1M I6IdcuwX4i/Q9qKHGHbce/jsqk6Xsj+hkkcnvmQ/dTNLupmnch2TXy8Kmv7kPP6I vgQBFgoAZgUCV215WV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45OJFAQCiBzXyZOAjdZ14iaH97UOCppwy pbg6E/sBZK32d1BC+QEAvL0ofIhKrZcHtcBPb36Nlqs2Qij18F6dpY0VY8rYygg= =GJPe -----END PGP SIGNATURE----- From davidmatthewslb at gmail.com Wed Jul 6 08:25:00 2016 From: davidmatthewslb at gmail.com (David Matthews) Date: Wed, 6 Jul 2016 07:25:00 +0100 Subject: gpg-preset-passphrase not working with 2.1 Message-ID: I can't get gpg-preset-passphrase to work with GnuPG 2.1.7. The command appears to work successfully but the passphase is not found by GET_PASSPHRASE. I've included details of my simple test below plus the output from running it on Centos 7.2 (where it works using 2.0.22) and Fedora 23 (where it fails using 2.1.7). Searching through the issue tracker I found https://bugs.gnupg.org/gnupg/issue2015. The title of this issue is "GET_PASSPHRASE with --no-ask always return error in gnupg 2.1.5" but, based on the discussion in the issue, I think the title is now wrong and should really be "gpg-preset-passphrase does not work". Have I understood that correctly? If so I assume I will see the same issue with the latest release? Any advice much appreciated. Thanks ## Test script #!/bin/bash set -x eval "$(gpg-agent -vv --daemon --allow-preset-passphrase --debug-level 9)" /usr/libexec/gpg-preset-passphrase -vv --preset -P test myid echo "GET_PASSPHRASE --no-ask myid Err Pmt Des" | gpg-connect-agent -vv ## Centos 7.2 output ++ gpg-agent -vv --daemon --allow-preset-passphrase --debug-level 9 gpg-agent[3239]: enabled debug flags: command mpi crypto memory cache memstat assuan gpg-agent[3239]: listening on socket `/home/vagrant/.gnupg/S.gpg-agent' gpg-agent[3240]: gpg-agent (GnuPG) 2.0.22 started + eval 'GPG_AGENT_INFO=/home/vagrant/.gnupg/S.gpg-agent:3240:1; export GPG_AGENT_INFO;' ++ GPG_AGENT_INFO=/home/vagrant/.gnupg/S.gpg-agent:3240:1 ++ export GPG_AGENT_INFO + /usr/libexec/gpg-preset-passphrase -vv --preset -P test myid gpg-agent[3240]: handler 0xcfcb70 for fd 7 started gpg-agent[3240]: chan_7 -> OK Pleased to meet you, process 3241 gpg-agent[3240]: chan_7 <- OPTION display=localhost:10.0 gpg-agent[3240]: chan_7 -> OK gpg-agent[3240]: chan_7 <- OPTION ttyname=/dev/pts/1 gpg-agent[3240]: chan_7 -> OK gpg-agent[3240]: chan_7 <- OPTION ttytype=dumb gpg-agent[3240]: chan_7 -> OK gpg-agent[3240]: chan_7 <- OPTION lc-ctype=en_US.UTF-8 gpg-agent[3240]: chan_7 -> OK gpg-agent[3240]: chan_7 <- OPTION lc-messages=en_US.UTF-8 gpg-agent[3240]: chan_7 -> OK gpg-agent[3240]: chan_7 <- PRESET_PASSPHRASE myid -1 74657374 gpg-agent[3240]: DBG: agent_put_cache `myid' requested ttl=-1 mode=1 gpg-agent[3240]: chan_7 -> OK gpg-agent[3240]: chan_7 <- [eof] gpg-agent[3240]: handler 0xcfcb70 for fd 7 terminated + echo 'GET_PASSPHRASE --no-ask myid Err Pmt Des' + gpg-connect-agent -vv gpg-agent[3240]: handler 0xcfe550 for fd 7 started gpg-agent[3240]: chan_7 -> OK Pleased to meet you, process 3243 gpg-connect-agent: connection to agent established gpg-agent[3240]: chan_7 <- RESET gpg-agent[3240]: chan_7 -> OK gpg-agent[3240]: chan_7 <- OPTION ttytype=dumb gpg-agent[3240]: chan_7 -> OK gpg-agent[3240]: chan_7 <- OPTION display=localhost:10.0 gpg-agent[3240]: chan_7 -> OK gpg-agent[3240]: chan_7 <- GET_PASSPHRASE --no-ask myid Err Pmt Des gpg-agent[3240]: DBG: agent_get_cache `myid'... gpg-agent[3240]: DBG: ... hit gpg-agent[3240]: chan_7 -> [[Confidential data not shown]] OK 74657374 gpg-connect-agent: closing connection to agent ## Fedora 23 output ++ gpg-agent -vv --daemon --allow-preset-passphrase --debug-level 9 gpg-agent[1420]: enabled debug flags: command mpi crypto memory cache memstat ipc gpg-agent[1420]: listening on socket '/home/vagrant/.gnupg/S.gpg-agent' gpg-agent[1421]: gpg-agent (GnuPG) 2.1.7 started + eval '' + /usr/libexec/gpg-preset-passphrase -vv --preset -P test myid gpg-agent[1421]: handler 0x7f8092ffc700 for fd 4 started gpg-agent[1421]: DBG: chan_4 -> OK Pleased to meet you, process 1422 gpg-agent[1421]: DBG: chan_4 <- OPTION ttyname=/dev/pts/1 gpg-agent[1421]: DBG: chan_4 -> OK gpg-agent[1421]: DBG: chan_4 <- OPTION ttytype=dumb gpg-agent[1421]: DBG: chan_4 -> OK gpg-agent[1421]: DBG: chan_4 <- OPTION lc-ctype=en_US.UTF-8 gpg-agent[1421]: DBG: chan_4 -> OK gpg-agent[1421]: DBG: chan_4 <- OPTION lc-messages=en_US.UTF-8 gpg-agent[1421]: DBG: chan_4 -> OK gpg-agent[1421]: DBG: chan_4 <- PRESET_PASSPHRASE myid -1 74657374 gpg-agent[1421]: DBG: agent_put_cache 'myid' (mode 1) requested ttl=-1 gpg-agent[1421]: DBG: chan_4 -> OK gpg-agent[1421]: DBG: chan_4 <- [eof] gpg-agent[1421]: handler 0x7f8092ffc700 for fd 4 terminated + echo 'GET_PASSPHRASE --no-ask myid Err Pmt Des' + gpg-connect-agent -vv gpg-agent[1421]: handler 0x7f8092ffc700 for fd 4 started gpg-agent[1421]: DBG: chan_4 -> OK Pleased to meet you, process 1425 gpg-agent[1421]: DBG: chan_4 <- RESET gpg-agent[1421]: DBG: chan_4 -> OK gpg-agent[1421]: DBG: chan_4 <- OPTION ttytype=dumb gpg-agent[1421]: DBG: chan_4 -> OK gpg-agent[1421]: DBG: chan_4 <- OPTION putenv=INSIDE_EMACS=24.5.1,comint gpg-agent[1421]: DBG: chan_4 -> OK gpg-agent[1421]: DBG: chan_4 <- GET_PASSPHRASE --no-ask myid Err Pmt Des gpg-agent[1421]: DBG: agent_get_cache 'myid' (mode 3) ... gpg-agent[1421]: DBG: ... miss gpg-agent[1421]: command 'GET_PASSPHRASE' failed: No data gpg-agent[1421]: DBG: chan_4 -> ERR 67108922 No data ERR 67108922 No data gpg-connect-agent: closing connection to agent gpg-agent[1421]: DBG: chan_4 <- [eof] gpg-agent[1421]: handler 0x7f8092ffc700 for fd 4 terminated From jonetsu at teksavvy.com Tue Jul 12 22:21:11 2016 From: jonetsu at teksavvy.com (jonetsu) Date: Tue, 12 Jul 2016 13:21:11 -0700 (MST) Subject: 186-4 (RSA) support Message-ID: <1468354871788-47978.post@n7.nabble.com> Hello, Does the current stable GnuPG release have the 186-4 support mentioned in Issue1736 'FIPS 186-4 compliance patches' ? Thanks. -- View this message in context: http://gnupg.10057.n7.nabble.com/186-4-RSA-support-tp47978.html Sent from the GnuPG - User mailing list archive at Nabble.com. From davidmatthewslb at gmail.com Thu Jul 14 08:29:57 2016 From: davidmatthewslb at gmail.com (David Matthews) Date: Thu, 14 Jul 2016 07:29:57 +0100 Subject: gpg-preset-passphrase not working with 2.1 In-Reply-To: <87shvdohwx.fsf@alice.fifthhorseman.net> References: <87shvdohwx.fsf@alice.fifthhorseman.net> Message-ID: On 13 July 2016 at 13:13, Daniel Kahn Gillmor wrote: > Hi David-- > > On Tue 2016-07-12 16:46:53 +0200, David Matthews wrote: >> I can't get gpg-preset-passphrase to work with GnuPG 2.1.7. > > there have been significant changes to GnuPG between 2.1.7 and 2.1.13. > > can you try upgrading to 2.1.13? I've compiled 2.1.13 on Fedora 23 and get the same result (test output below). According to issue 2015 this was caused by a change that went into release 2.1.5. Thanks, David ++ gpg-agent -vv --daemon --allow-preset-passphrase --debug-level 9 gpg-agent[12163]: enabled debug flags: command mpi crypto memory cache memstat ipc gpg-agent[12163]: listening on socket '/run/user/1000/gnupg/S.gpg-agent' gpg-agent[12164]: gpg-agent (GnuPG) 2.1.13 started + eval '' + /usr/local/libexec/gpg-preset-passphrase -vv --preset -P test myid gpg-agent[12164]: handler 0x7fc9c028a700 for fd 4 started gpg-agent[12164]: DBG: chan_4 -> OK Pleased to meet you, process 12165 gpg-agent[12164]: DBG: chan_4 <- OPTION ttyname=/dev/pts/0 gpg-agent[12164]: DBG: chan_4 -> OK gpg-agent[12164]: DBG: chan_4 <- OPTION ttytype=xterm gpg-agent[12164]: DBG: chan_4 -> OK gpg-agent[12164]: DBG: chan_4 <- OPTION lc-ctype=en_US.UTF-8 gpg-agent[12164]: DBG: chan_4 -> OK gpg-agent[12164]: DBG: chan_4 <- OPTION lc-messages=en_US.UTF-8 gpg-agent[12164]: DBG: chan_4 -> OK gpg-agent[12164]: DBG: chan_4 <- PRESET_PASSPHRASE myid -1 74657374 gpg-agent[12164]: DBG: agent_put_cache 'myid' (mode 1) requested ttl=-1 gpg-agent[12164]: DBG: chan_4 -> S PROGRESS need_entropy X 60 120 gpg-agent[12164]: DBG: chan_4 -> S PROGRESS need_entropy X 120 120 Removed lots of repeated lines gpg-agent[12164]: DBG: chan_4 -> S PROGRESS need_entropy X 60 120 gpg-agent[12164]: DBG: chan_4 -> S PROGRESS need_entropy X 120 120 gpg-agent[12164]: DBG: chan_4 -> OK gpg-agent[12164]: DBG: chan_4 <- [eof] gpg-agent[12164]: handler 0x7fc9c028a700 for fd 4 terminated + echo 'GET_PASSPHRASE --no-ask myid Err Pmt Des' + gpg-connect-agent -vv gpg-agent[12164]: handler 0x7fc9c028a700 for fd 4 started gpg-agent[12164]: DBG: chan_4 -> OK Pleased to meet you, process 12168 gpg-agent[12164]: DBG: chan_4 <- RESET gpg-agent[12164]: DBG: chan_4 -> OK gpg-agent[12164]: DBG: chan_4 <- OPTION ttytype=xterm gpg-agent[12164]: DBG: chan_4 -> OK gpg-agent[12164]: DBG: chan_4 <- GET_PASSPHRASE --no-ask myid Err Pmt Des gpg-agent[12164]: DBG: agent_get_cache 'myid' (mode 3) ... gpg-agent[12164]: DBG: ... miss gpg-agent[12164]: command 'GET_PASSPHRASE' failed: No data gpg-agent[12164]: DBG: chan_4 -> ERR 67108922 No data gpg-connect-agent: closing connection to agent ERR 67108922 No data gpg-agent[12164]: DBG: chan_4 <- [eof] gpg-agent[12164]: handler 0x7fc9c028a700 for fd 4 terminated From wk at gnupg.org Thu Jul 14 09:38:35 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 14 Jul 2016 09:38:35 +0200 Subject: Solid Crypting for GNUPG In-Reply-To: <20160701130234.9dad83b9c96228d7045ef5aa@li.ru> (=?utf-8?B?ItCa0L7RgNC10L3RjCDQl9C70LAiJ3M=?= message of "Fri, 1 Jul 2016 13:02:34 +0300") References: <20160701130234.9dad83b9c96228d7045ef5aa@li.ru> Message-ID: <87zipkr7no.fsf@wheatstone.g10code.de> On Fri, 1 Jul 2016 12:02, xlbaron at li.ru said: > Can u get policy for adding a new open-non-patent algorythms for > crypting in new versions of GNUPG without modules to it?I still aint You are asking on how to add new algorithms to GnuPG. I assume you mean the OpenPGP part (gpg). To add a new algorithm, you first need to get it into the OpenPGP standard (RFC-4880), then make sure that Libgcrypt supports the algorithm, and finally add it to GnuPG. If you do not want to wait until an RFC for your algorithm has been published, you may use the experimental range of algorithm ids from OpenPGP. However, we won't accept it in the upstream version of GnuPG, because those experimental algorithm ids have practical problems and are only useful for, well, experiments. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From wk at gnupg.org Thu Jul 14 17:59:58 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 14 Jul 2016 17:59:58 +0200 Subject: [Announce] Libgcrypt 1.7.2 released Message-ID: <87r3awnrb5.fsf@wheatstone.g10code.de> Hello! The GnuPG Project is pleased to announce the availability of Libgcrypt version 1.7.2. This is a maintenace release. Libgcrypt is a general purpose library of cryptographic building blocks. It is originally based on code used by GnuPG. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required to use Libgcrypt. Noteworthy changes in version 1.7.2 =================================== * Bug fixes: - Fix setting of the ECC cofactor if parameters are specified. - Fix memory leak in the ECC code. - Remove debug message about unsupported getrandom syscall. - Fix build problems related to AVX use. - Fix bus errors on ARM for Poly1305, ChaCha20, AES, and SHA-512. * Internal changes: - Improved fatal error message for wrong use of gcry_md_read. - Disallow symmetric encryption/decryption if key is not set. Download ======== Source code is hosted at the GnuPG FTP server and its mirrors as listed at https://gnupg.org/download/mirrors.html . On the primary server the source tarball and its digital signature are: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.2.tar.bz2 (2778k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.2.tar.bz2.sig That file is bzip2 compressed. A gzip compressed version is here: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.2.tar.gz (3318k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.7.2.tar.gz.sig The same files are also available via HTTP: https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.2.tar.bz2 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.2.tar.bz2.sig https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.2.tar.gz https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.7.2.tar.gz.sig In order to check that the version of Libgcrypt you downloaded is an original and unmodified file please follow the instructions found at . In short, you may use one of the following methods: - Check the supplied OpenPGP signature. For example to check the signature of the file libgcrypt-1.7.2.tar.bz2 you would use this command: gpg --verify libgcrypt-1.7.2.tar.bz2.sig libgcrypt-1.7.2.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. - If you are not able to use GnuPG, you have to verify the SHA-1 checksum: sha1sum libgcrypt-1.7.2.tar.bz2 and check that the output matches the first line from the this list: 85a6a936bcab4c3c05f5efbf6ce847f23d35c0c4 libgcrypt-1.7.2.tar.bz2 8e34352e21744fe3fb0558f9d6af6b69e18cb563 libgcrypt-1.7.2.tar.gz You should also verify that the checksums above are authentic by matching them with copies of this announcement. Those copies can be found at other mailing lists, web sites, and search engines. Copying ======= Libgcrypt is distributed under the terms of the GNU Lesser General Public License (LGPLv2.1+). The helper programs as well as the documentation are distributed under the terms of the GNU General Public License (GPLv2+). The file LICENSES has notices about contributions that require that these additional notices are distributed. Support ======= For help on developing with Libgcrypt you should read the included manual and optional ask on the gcrypt-devel mailing list [1]. A listing with commercial support offers for Libgcrypt and related software is available at the GnuPG web site [2]. If you are a developer and you may need a certain feature for your project, please do not hesitate to bring it to the gcrypt-devel mailing list for discussion. Maintenance and development of Libgcrypt is mostly financed by donations; see . We currently employ 3 full-time developers, one part-timer, and one contractor to work on GnuPG and closely related software like Libgcrypt. Thanks ====== We like to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Also many thanks to all our donors [3]. For the GnuPG hackers, Werner p.s. This is an announcement only mailing list. Please send replies only to the gcrypt-devel 'at' gnupg.org mailing list. [1] https://lists.gnupg.org/mailman/listinfo/gcrypt-devel [2] https://www.gnupg.org/service.html [3] https://gnupg.org/donate/kudos.html -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 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 Thu Jul 14 17:55:34 2016 From: wk at gnupg.org (Werner Koch) Date: Thu, 14 Jul 2016 17:55:34 +0200 Subject: [Announce] GnuPG 2.1.14 released Message-ID: <87vb08nrih.fsf@wheatstone.g10code.de> Hello! The GnuPG team is pleased to announce the availability of a new release of GnuPG modern: Version 2.1.14. See below for a list of new features and bug fixes. About GnuPG ============= The GNU Privacy Guard (GnuPG) is a complete and free implementation of the OpenPGP standard which is commonly abbreviated as PGP. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries making use of GnuPG are available. Since version 2 GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Three different branches of GnuPG are actively maintained: - GnuPG "modern" (2.1) is the latest development with a lot of new features. This announcement is about this branch. - GnuPG "stable" (2.0) is the current stable version for general use. This is what most users are still using. - GnuPG "classic" (1.4) is the old standalone version which is most suitable for older or embedded platforms. You may not install "modern" (2.1) and "stable" (2.0) at the same time. However, it is possible to install "classic" (1.4) along with any of the other versions. Noteworthy changes in version 2.1.14 ==================================== * gpg: Removed options --print-dane-records and --print-pka-records. The new export options "export-pka" and "export-dane" can instead be used with the export command. * gpg: New options --import-filter and --export-filter. * gpg: New import options "import-show" and "import-export". * gpg: New option --no-keyring. * gpg: New command --quick-revuid. * gpg: New options -f/--recipient-file and -F/--hidden-recipient-file to directly specify encryption keys. * gpg: New option --mimemode to indicate that the content is a MIME part. Does only enable --textmode right now. * gpg: New option --rfc4880bis to allow experiments with proposed changes to the current OpenPGP specs. * gpg: Fix regression in the "fetch" sub-command of --card-edit. * gpg: Fix regression since 2.1 in option --try-all-secrets. * gpgv: Change default options for extra security. * gpgsm: No more root certificates are installed by default. * agent: "updatestartuptty" does now affect more environment variables. * scd: The option --homedir does now work with scdaemon. * scd: Support some more GEMPlus card readers. * gpgtar: Fix handling of '-' as file name. * gpgtar: New commands --create and --extract. * gpgconf: Tweak for --list-dirs to better support shell scripts. * tools: Add programs gpg-wks-client and gpg-wks-server to implement a Web Key Service. The configure option --enable-wks-tools is required to build them; they should be considered Beta software. * tests: Complete rework of the openpgp part of the test suite. The test scripts have been changed from Bourne shell scripts to Scheme programs. A customized scheme interpreter (gpgscm) is included. This change was triggered by the need to run the test suite on non-Unix platforms. * The rendering of the man pages has been improved. A detailed description of the changes found in the 2.1 branch can be found at . Please be aware that there are still known bugs which we are working on. Check https://bugs.gnupg.org, https://wiki.gnupg.org, and the mailing list archives for known problems and workarounds. Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.1.14 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.14.tar.bz2 (5572k) ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.14.tar.bz2.sig or here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.14.tar.bz2 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.1.14.tar.bz2.sig An installer for Windows without any graphical frontend except for a minimal Pinentry tool is available here: ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.14_20160714.exe (3576k) ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.14_20160714.exe.sig or here https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.14_20160714.exe https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.14_20160714.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. This Windows installer comes with Tofu support, translations, and support for Tor and the Tor browser. It is still missing HKPS support, though. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.1.14.tar.bz2 you would use this command: gpg --verify gnupg-2.1.14.tar.bz2.sig gnupg-2.1.14.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See below for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.1.14.tar.bz2, you run the command like this: sha1sum gnupg-2.1.14.tar.bz2 and check that the output matches the next line: bc7609a3a0daf0ed0efb22f77b43e82f28e20e34 gnupg-2.1.14.tar.bz2 8871e1b596a208403c7240498fa3d83c33ced4b2 gnupg-w32-2.1.14_20160714.exe 0d7f8831966dac737a15feae44ac78f6cce54fee gnupg-w32-2.1.14_20160714.tar.xz Release Signing Keys ==================== To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: 2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31] Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 Werner Koch (Release Signing Key) You may retrieve these keys from a keyserver using this command gpg --keyserver hkp://keys.gnupg.net --recv-keys \ 249B39D24F25E3B6 04376F3EE0856959 \ 2071B08A33BD3F06 8A861B1C7EFD60D9 The keys are also available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese, Czech, French, German, Japanese, Norwegian, Russian, and Ukrainian being almost completely translated (2174 different strings). Documentation ============= If you used GnuPG in the past you should read the description of changes and new features at doc/whats-new-in-2.1.txt or online at https://gnupg.org/faq/whats-new-in-2.1.html The file gnupg.info has the complete user manual of the system. Separate man pages are included as well but they have not all the details available as are the manual. It is also possible to read the complete manual online in HTML format at https://gnupg.org/documentation/manuals/gnupg/ or in Portable Document Format at https://gnupg.org/documentation/manuals/gnupg.pdf . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. You may also want search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. You may also want to follow our postings at and . Support ======== Please consult the archive of the gnupg-users mailing list before reporting a bug . We suggest to send bug reports for a new release to this list in favor of filing a bug at . If you need commercial support check out . If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Maintenance and development of GnuPG is mostly financed by donations. The GnuPG project employs 3 full-time developers, one part-timer, and one contractor. They all work on GnuPG and closely related software like Libgcrypt and GPA. Please consider to donate via: https://gnupg.org/donate/ Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, answering questions on the mailing lists, and donating money. See you at OpenPGP.conf . For the GnuPG hackers, Werner p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users'at'gnupg.org mailing list. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 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 foxdeltasigma at gmail.com Fri Jul 15 13:04:41 2016 From: foxdeltasigma at gmail.com (Fox DeltaSigma) Date: Fri, 15 Jul 2016 13:04:41 +0200 Subject: Threefish cipher in GnuPG? Message-ID: Hello everyone, I've been sort of a long-term user (everything is relative, I guess) of GnuPG, mainly sticking to the 1.14.x versions, using them as standalone inside encrypted volumes, since I usually only do pretty simple stuff, like messages or files. I think the Blowfish cipher is included for backward compatibility (mainly),and I occasionally use Twofish instead of AES256, for symmetric encryption myself. Anyway, just out of curiosity, are there plans on including Threefish in GnuPG? Or reasons why it hasn't been nor will be? Best regards, S Trenton From rjh at sixdemonbag.org Fri Jul 15 22:52:57 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 15 Jul 2016 16:52:57 -0400 Subject: Threefish cipher in GnuPG? In-Reply-To: References: Message-ID: > Anyway, just out of curiosity, are there plans on including Threefish in > GnuPG? Or reasons why it hasn't been nor will be? RFC4880 has identifiers for the following symmetric ciphers: Unencrypted, IDEA, 3DES, CAST5-128, Blowfish-128, AES in three key sizes, and Twofish-256. Supplemental RFCs (5581) have added identifiers for Camellia in three key sizes. If you can get the IETF to release an RFC for Threefish in OpenPGP, it's very likely GnuPG will include Threefish support. But without that, it's very unlikely. From yuriping at sohu.com Sat Jul 16 04:39:50 2016 From: yuriping at sohu.com (yuriping at sohu.com) Date: Sat, 16 Jul 2016 10:39:50 +0800 Subject: Where Can I get sign and verify demo for GPGME Message-ID: <1468636790.543f370fc40f49e592f5947c312340a1.yuriping@sohu.com> Hi, all,    We're using GPGME now and are going to perform signing and verifying process.    Could you tell me where can I get demos of GPGME for signing and verifying using C program.    Best Regards! ------------------------------------------ ???????????????????~ -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Sat Jul 16 18:37:55 2016 From: wk at gnupg.org (Werner Koch) Date: Sat, 16 Jul 2016 18:37:55 +0200 Subject: Where Can I get sign and verify demo for GPGME In-Reply-To: <1468636790.543f370fc40f49e592f5947c312340a1.yuriping@sohu.com> (yuriping@sohu.com's message of "Sat, 16 Jul 2016 10:39:50 +0800") References: <1468636790.543f370fc40f49e592f5947c312340a1.yuriping@sohu.com> Message-ID: <8760s5ilng.fsf@wheatstone.g10code.de> On Sat, 16 Jul 2016 04:39, yuriping at sohu.com said: > Hi, all,    We're using GPGME now and are going to > perform signing and verifying process.    Could you > tell me where can I get demos of GPGME for signing and verifying using > C program.    Best Regards! have a look into the gpgme source package: gpgme/tests/run-sign.c gpgme/tests/run-verify.c Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* Join us at OpenPGP.conf */ From ben at skyportsystems.com Sat Jul 16 02:27:16 2016 From: ben at skyportsystems.com (Ben Warren) Date: Fri, 15 Jul 2016 17:27:16 -0700 Subject: SSH hangs when using GPG2 + Yubikey on OS-X Message-ID: Hi, I?ve found similar issues on the mailing list, but wasn?t able to find a resolution. I?m using a Yubikey 4 hardware token on OS-X ?Yosemite?. I?m connecting to a remote Linux VM and am using GPG agent-forwarding in order to sign git commits using the Yubikey. I also forward SSH through GPG, but find that with one or two SSH sessions open, they hang after a couple of hours. This time frame is sometimes shorter, but rarely longer. In order to recover, I need to kill scdaemon on the Mac using SIGKILL. I?ve tried SIGHUP, but that doesn?t help. I?m able to tolerate this, but colleagues who have more open SSH connections open see it hang much more often to the point where this is unusable. =============== Software versions: ben ~ $ gpg2 --version gpg (GnuPG) 2.1.12 libgcrypt 1.7.0 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 ben ~ $ ssh -V OpenSSH_6.8p1, OpenSSL 1.0.2a 19 Mar 2015 ================ GPG configurations: ben ~/.gnupg $ cat gpg-agent.conf default-cache-ttl 1 ignore-cache-for-signing no-allow-external-cache max-cache-ttl 1 extra-socket /Users/ben/.gnupg/S.gpg-extra-agent debug-all log-file /Users/ben/.gnupg/mygpglogfile.log enable-ssh-support ben ~/.gnupg $ cat scdaemon.conf log-file /Users/ben/.gnupg/scdaemon.log verbose debug-level guru #jdebug-all debug ipc,cardio I?ve appended parts of the scdaemon log file, with Yubikey passphrase reset to the default. Hopefully there?s no sensitive info here, but please let me know if there is so I can reset. ======== Timeline: 2016-07-13 16:20:58 : started SSH connection 2016-07-13 16:30 : I noticed the SSH connection was hung and killed scdaemon Here?s an interesting snippet: 2016-07-13 16:28:00 scdaemon[32523] DBG: leave: apdu_get_status => sw=0x0 status=7 changecnt=3 2016-07-13 16:28:01 scdaemon[32523] DBG: enter: apdu_get_status: slot=0 hang=0 2016-07-13 16:28:01 scdaemon[32523] DBG: leave: apdu_get_status => sw=0x0 status=7 changecnt=3 2016-07-13 16:28:01 scdaemon[32523] DBG: chan_6 <- RESTART 2016-07-13 16:28:01 scdaemon[32523] Ohhhh jeeee: trying to release an already released context 2016-07-13 16:30:40 scdaemon[32745] listening on socket '/Users/ben/.gnupg/S.scdaemon' 2016-07-13 16:30:40 scdaemon[32745] handler for fd -1 started 2016-07-13 16:30:40 scdaemon[32745] DBG: enter: apdu_open_reader: portstr=(null) ================ I?m happy to experiment in any way to get to the bottom of this. thanks, Ben +++++++++++ 2016-07-13 16:20:58 scdaemon[32511] handler for fd 9 started 2016-07-13 16:20:58 scdaemon[32511] DBG: chan_9 -> OK GNU Privacy Guard's Smartcard server ready 2016-07-13 16:20:58 scdaemon[32511] DBG: chan_9 <- GETATTR $AUTHKEYID 2016-07-13 16:20:58 scdaemon[32511] DBG: enter: apdu_connect: slot=0 2016-07-13 16:20:58 scdaemon[32511] DBG: leave: apdu_connect => sw=0x1000f 2016-07-13 16:20:58 scdaemon[32511] DBG: chan_9 -> S $AUTHKEYID OPENPGP.3 2016-07-13 16:20:58 scdaemon[32511] DBG: chan_9 -> OK 2016-07-13 16:20:58 scdaemon[32511] DBG: chan_9 <- GETATTR SERIALNO 2016-07-13 16:20:58 scdaemon[32511] DBG: chan_9 -> S SERIALNO D2760001240102010006041744320000 2016-07-13 16:20:58 scdaemon[32511] DBG: chan_9 -> OK 2016-07-13 16:20:58 scdaemon[32511] DBG: chan_9 <- READKEY OPENPGP.3 2016-07-13 16:20:58 scdaemon[32511] DBG: chan_9 -> [ 44 20 28 31 30 3a 70 75 62 6c 69 63 2d 6b 65 79 ...(546 byte(s) skipped) ] 2016-07-13 16:20:58 scdaemon[32511] DBG: chan_9 -> OK 2016-07-13 16:20:58 scdaemon[32511] DBG: chan_9 <- GETATTR $DISPSERIALNO 2016-07-13 16:20:58 scdaemon[32511] DBG: chan_9 -> S $DISPSERIALNO 000604174432 2016-07-13 16:20:58 scdaemon[32511] DBG: chan_9 -> OK 2016-07-13 16:20:58 scdaemon[32511] DBG: chan_9 <- SERIALNO 2016-07-13 16:20:58 scdaemon[32511] DBG: chan_9 -> S SERIALNO D2760001240102010006041744320000 0 2016-07-13 16:20:58 scdaemon[32511] DBG: chan_9 -> OK 2016-07-13 16:20:58 scdaemon[32511] DBG: chan_9 <- SETDATA 3021300906052B0E03021A05000414CE04A6A5E7067AD8F27FFDE3937FE93C503EDEAC 2016-07-13 16:20:58 scdaemon[32511] DBG: chan_9 -> OK 2016-07-13 16:20:58 scdaemon[32511] DBG: chan_9 <- PKAUTH OPENPGP.3 2016-07-13 16:20:58 scdaemon[32511] DBG: send apdu: c=00 i=88 p1=00 p2=00 lc=35 le=256 em=0 2016-07-13 16:20:58 scdaemon[32511] DBG: PCSC_data: 00 88 00 00 23 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14 CE 04 A6 A5 E7 06 7A D8 F2 7F FD E3 93 7F E9 3C 50 3E DE AC 00 2016-07-13 16:20:58 scdaemon[32511] DBG: response: sw=61FF datalen=254 2016-07-13 16:20:58 scdaemon[32511] DBG: apdu_send_simple(0): 255 more bytes available 2016-07-13 16:20:58 scdaemon[32511] DBG: PCSC_data: 00 C0 00 00 FF 2016-07-13 16:20:58 scdaemon[32511] DBG: more: sw=6103 datalen=255 2016-07-13 16:20:58 scdaemon[32511] DBG: apdu_send_simple(0): 3 more bytes available 2016-07-13 16:20:58 scdaemon[32511] DBG: PCSC_data: 00 C0 00 00 03 2016-07-13 16:20:58 scdaemon[32511] DBG: more: sw=9000 datalen=3 2016-07-13 16:20:58 scdaemon[32511] DBG: dump: 0F FC 8B 9D 00 A5 BC C1 EE 63 A1 52 56 57 E3 32 1E 29 B5 2B DD AE 74 83 FD 3E 77 86 96 00 ED 18 72 07 7C CE 42 2D 1E 95 C5 FD DE BE 19 20 48 EC 16 F5 8F B0 49 65 68 9B 17 18 E1 1C F2 B6 B2 59 56 64 34 09 AD A3 C0 30 3F B5 F0 C8 1C C1 67 12 1F A1 75 78 B0 A8 3C 2A CE 3E 51 9A C5 E2 57 19 CF DF A9 0B 12 22 F8 48 B0 8B ED 6A 35 D4 5C 0B 79 E1 F1 F2 ED 9F A7 60 97 A9 EE B7 52 AD FF CF 52 30 72 02 0F 04 FF 66 DC 62 AE DC 00 DA 27 1B B0 4D B5 8F 6D 9D 39 D3 0D 8D 9B F5 FC B3 3F 62 8D 8A FB D1 7F 33 AF 84 F3 71 7A E2 A8 E9 FA 55 05 AE D4 6B 2A CC 74 B4 DB 39 D0 61 4A 7A 13 EB 1D C9 21 45 EA A8 94 7D 60 B3 4E A1 97 2D AA AC 4B 7D 04 29 B8 A1 6E E4 FE 93 89 A6 5D 3B 9C CC 18 F2 94 41 D9 7E F9 9F 53 3A AC 00 58 D9 CB C8 E4 84 D8 BD 69 D0 35 F9 8C 09 C3 52 47 7B 54 8D C3 47 98 7C 33 34 67 A0 00 7D 1B E9 D9 53 BC 8E 88 C4 5B 30 F3 0E 13 BB 98 D8 CB 94 E5 C1 1B 0A 39 17 25 6D F8 E3 91 58 C7 EC 55 89 28 09 78 62 A1 C7 A5 BE C7 F4 D0 4A 2E 0F DB E5 5E 2F 67 C1 CF 57 CC 05 3B EF 20 74 A7 88 E9 72 F1 AF 7F CA 99 FC F0 A4 B8 14 99 CF 58 F6 9D 28 2F 75 2C 0D 90 D9 F7 18 77 5C 8A 65 94 8E A5 01 2A FD C9 B9 8B 2B 5A D2 C8 A7 E4 9F F2 3F 31 14 17 B1 5D 4F 0B 21 B7 BE D7 6F DB 15 78 16 ED 74 B6 8E 3C 40 6B 56 FA 7D 57 7E 2A 46 F3 82 1F 6E 2B FA 96 85 5A 63 A5 50 7B 62 5A B8 BF 74 50 C7 A1 2D 12 CA B2 2E B4 0A B6 21 0F 0E 22 97 AC B4 4A 7F 09 E7 96 E2 91 26 53 12 4E FD 42 C6 E9 42 43 A5 BF 6F 23 6D E8 63 56 D1 FE 11 C9 A9 1A 9F 4D 07 A1 BD BA 04 47 F3 AC 87 0F 38 F4 E9 C9 15 3A 99 40 BD C0 91 B9 75 CE 3D FA 9F 5B 28 2D 3A B6 02 0F 20 2016-07-13 16:20:58 scdaemon[32511] operation auth result: Success 2016-07-13 16:20:58 scdaemon[32511] DBG: chan_9 -> [ 44 20 0f fc 8b 9d 00 a5 bc c1 ee 63 a1 52 56 57 ...(508 byte(s) skipped) ] 2016-07-13 16:20:58 scdaemon[32511] DBG: enter: apdu_get_status: slot=0 hang=0 2016-07-13 16:20:58 scdaemon[32511] DBG: leave: apdu_get_status => sw=0x0 status=7 changecnt=1 2016-07-13 16:20:58 scdaemon[32511] DBG: chan_9 -> OK 2016-07-13 16:20:59 scdaemon[32511] DBG: chan_9 <- BYE 2016-07-13 16:20:59 scdaemon[32511] DBG: chan_9 -> OK closing connection 2016-07-13 16:20:59 scdaemon[32511] DBG: enter: apdu_get_status: slot=0 hang=0 2016-07-13 16:20:59 scdaemon[32511] DBG: leave: apdu_get_status => sw=0x0 status=7 changecnt=1 2016-07-13 16:20:59 scdaemon[32511] handler for fd 9 terminated 2016-07-13 16:20:59 scdaemon[32511] DBG: enter: apdu_get_status: slot=0 hang=0 2016-07-13 16:20:59 scdaemon[32511] DBG: leave: apdu_get_status => sw=0x0 status=7 changecnt=1 ... 2016-07-13 16:21:01 scdaemon[32511] DBG: enter: apdu_get_status: slot=0 hang=0 2016-07-13 16:21:01 scdaemon[32511] DBG: leave: apdu_get_status => sw=0x0 status=7 changecnt=1 2016-07-13 16:21:02 scdaemon[32511] DBG: chan_6 <- RESTART 2016-07-13 16:21:02 scdaemon[32511] DBG: chan_6 -> OK 2016-07-13 16:21:02 scdaemon[32511] DBG: enter: apdu_get_status: slot=0 hang=0 2016-07-13 16:21:02 scdaemon[32511] DBG: leave: apdu_get_status => sw=0x0 status=7 changecnt=1 2016-07-13 16:21:02 scdaemon[32511] DBG: enter: apdu_get_status: slot=0 hang=0 ... 2016-07-13 16:21:09 scdaemon[32511] DBG: leave: apdu_get_status => sw=0x0 status=7 changecnt=1 2016-07-13 16:21:14 scdaemon[32523] listening on socket '/Users/ben/.gnupg/S.scdaemon' 2016-07-13 16:21:14 scdaemon[32523] handler for fd -1 started 2016-07-13 16:21:14 scdaemon[32523] DBG: enter: apdu_open_reader: portstr=(null) 2016-07-13 16:21:14 scdaemon[32523] detected reader 'Yubico Yubikey 4 OTP+U2F+CCID' 2016-07-13 16:21:14 scdaemon[32523] reader slot 0: not connected 2016-07-13 16:21:14 scdaemon[32523] DBG: leave: apdu_open_reader => slot=0 [pc/sc] 2016-07-13 16:21:14 scdaemon[32523] DBG: chan_6 -> OK GNU Privacy Guard's Smartcard server ready 2016-07-13 16:21:14 scdaemon[32523] DBG: chan_6 <- GETINFO socket_name 2016-07-13 16:21:14 scdaemon[32523] DBG: chan_6 -> D /Users/ben/.gnupg/S.scdaemon 2016-07-13 16:21:14 scdaemon[32523] DBG: chan_6 -> OK 2016-07-13 16:21:14 scdaemon[32523] DBG: chan_6 <- OPTION event-signal=31 2016-07-13 16:21:14 scdaemon[32523] DBG: chan_6 -> OK 2016-07-13 16:21:14 scdaemon[32523] DBG: chan_6 <- GETINFO version 2016-07-13 16:21:14 scdaemon[32523] DBG: chan_6 -> D 2.1.12 2016-07-13 16:21:14 scdaemon[32523] DBG: chan_6 -> OK 2016-07-13 16:21:14 scdaemon[32523] DBG: chan_6 <- SERIALNO openpgp 2016-07-13 16:21:14 scdaemon[32523] DBG: enter: apdu_connect: slot=0 2016-07-13 16:21:14 scdaemon[32523] pcsc_control failed: not transacted (0x80100016) 2016-07-13 16:21:14 scdaemon[32523] pcsc_vendor_specific_init: GET_FEATURE_REQUEST failed: 65547 2016-07-13 16:21:14 scdaemon[32523] reader slot 0: active protocol: T1 2016-07-13 16:21:14 scdaemon[32523] slot 0: ATR=3B F8 13 00 00 81 31 FE 15 59 75 62 69 6B 65 79 34 D4 2016-07-13 16:21:14 scdaemon[32523] DBG: leave: apdu_connect => sw=0x0 2016-07-13 16:21:14 scdaemon[32523] DBG: send apdu: c=00 i=A4 p1=00 p2=0C lc=2 le=-1 em=0 2016-07-13 16:21:14 scdaemon[32523] DBG: PCSC_data: 00 A4 00 0C 02 3F 00 2016-07-13 16:21:14 scdaemon[32523] DBG: response: sw=6D00 datalen=0 2016-07-13 16:21:14 scdaemon[32523] DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=6 le=-1 em=0 2016-07-13 16:21:14 scdaemon[32523] DBG: PCSC_data: 00 A4 04 00 06 D2 76 00 01 24 01 2016-07-13 16:21:14 scdaemon[32523] DBG: response: sw=9000 datalen=0 2016-07-13 16:21:14 scdaemon[32523] DBG: dump: 2016-07-13 16:21:14 scdaemon[32523] DBG: send apdu: c=00 i=CA p1=00 p2=4F lc=-1 le=256 em=0 2016-07-13 16:21:14 scdaemon[32523] DBG: PCSC_data: 00 CA 00 4F 00 2016-07-13 16:21:14 scdaemon[32523] DBG: response: sw=9000 datalen=16 2016-07-13 16:21:14 scdaemon[32523] DBG: dump: D2 76 00 01 24 01 02 01 00 06 04 17 44 32 00 00 2016-07-13 16:21:14 scdaemon[32523] AID: D2 76 00 01 24 01 02 01 00 06 04 17 44 32 00 00 2016-07-13 16:21:14 scdaemon[32523] DBG: send apdu: c=00 i=CA p1=5F p2=52 lc=-1 le=256 em=0 2016-07-13 16:21:14 scdaemon[32523] DBG: PCSC_data: 00 CA 5F 52 00 2016-07-13 16:21:14 scdaemon[32523] DBG: response: sw=9000 datalen=8 2016-07-13 16:21:14 scdaemon[32523] DBG: dump: 00 73 00 00 80 05 90 00 2016-07-13 16:21:14 scdaemon[32523] Historical Bytes: 00 73 00 00 80 05 90 00 2016-07-13 16:21:14 scdaemon[32523] DBG: send apdu: c=00 i=CA p1=00 p2=C4 lc=-1 le=256 em=0 2016-07-13 16:21:14 scdaemon[32523] DBG: PCSC_data: 00 CA 00 C4 00 2016-07-13 16:21:14 scdaemon[32523] DBG: response: sw=9000 datalen=7 2016-07-13 16:21:14 scdaemon[32523] DBG: dump: 00 7F 7F 7F 03 00 03 2016-07-13 16:21:14 scdaemon[32523] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2016-07-13 16:21:14 scdaemon[32523] DBG: PCSC_data: 00 CA 00 6E 00 2016-07-13 16:21:14 scdaemon[32523] DBG: response: sw=9000 datalen=224 2016-07-13 16:21:14 scdaemon[32523] DBG: dump: 6E 81 DD 4F 10 D2 76 00 01 24 01 02 01 00 06 04 17 44 32 00 00 5F 52 08 00 73 00 00 80 05 90 00 7F 74 03 81 01 20 73 81 B7 C0 0A 3C 00 00 00 04 C0 00 FF 00 FF C1 06 01 10 00 00 11 00 C2 06 01 10 00 00 11 00 C3 06 01 10 00 00 11 00 C4 07 00 7F 7F 7F 03 00 03 C5 3C D4 7E CF B6 9D A9 CC 0D B8 29 C1 34 0C FF 78 B7 1B 30 BC 88 3B 48 EC 91 DC 3C FA FE 99 41 E8 BC 90 4C 1E 1E F5 D4 61 95 41 E4 25 E5 2E B0 7A 65 C4 87 AC DD 7E 6C 44 E9 8E C0 D4 60 C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 57 46 2E 08 57 46 2E 08 57 46 2E 08 2016-07-13 16:21:14 scdaemon[32523] DBG: send apdu: c=00 i=CA p1=7F p2=74 lc=-1 le=256 em=0 2016-07-13 16:21:14 scdaemon[32523] DBG: PCSC_data: 00 CA 7F 74 00 2016-07-13 16:21:14 scdaemon[32523] DBG: response: sw=9000 datalen=3 2016-07-13 16:21:14 scdaemon[32523] DBG: dump: 81 01 20 2016-07-13 16:21:14 scdaemon[32523] DBG: send apdu: c=00 i=CA p1=00 p2=5E lc=-1 le=256 em=0 2016-07-13 16:21:14 scdaemon[32523] DBG: PCSC_data: 00 CA 00 5E 00 2016-07-13 16:21:14 scdaemon[32523] DBG: response: sw=9000 datalen=0 2016-07-13 16:21:14 scdaemon[32523] DBG: dump: 2016-07-13 16:21:14 scdaemon[32523] Version-2 ......: yes 2016-07-13 16:21:14 scdaemon[32523] Get-Challenge ..: no 2016-07-13 16:21:14 scdaemon[32523] Key-Import .....: yes 2016-07-13 16:21:14 scdaemon[32523] Change-Force-PW1: yes 2016-07-13 16:21:14 scdaemon[32523] Private-DOs ....: yes 2016-07-13 16:21:14 scdaemon[32523] Algo-Attr-Change: yes 2016-07-13 16:21:14 scdaemon[32523] SM-Support .....: no 2016-07-13 16:21:14 scdaemon[32523] Max-Cert3-Len ..: 1216 2016-07-13 16:21:14 scdaemon[32523] Max-Cmd-Data ...: 255 2016-07-13 16:21:14 scdaemon[32523] Max-Rsp-Data ...: 255 2016-07-13 16:21:14 scdaemon[32523] Cmd-Chaining ...: yes 2016-07-13 16:21:14 scdaemon[32523] Ext-Lc-Le ......: no 2016-07-13 16:21:14 scdaemon[32523] Status Indicator: 05 2016-07-13 16:21:14 scdaemon[32523] Symmetric crypto: no 2016-07-13 16:21:14 scdaemon[32523] Button..........: yes 2016-07-13 16:21:14 scdaemon[32523] GnuPG-No-Sync ..: no 2016-07-13 16:21:14 scdaemon[32523] GnuPG-Def-PW2 ..: no 2016-07-13 16:21:14 scdaemon[32523] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2016-07-13 16:21:14 scdaemon[32523] DBG: PCSC_data: 00 CA 00 6E 00 2016-07-13 16:21:14 scdaemon[32523] DBG: response: sw=9000 datalen=224 2016-07-13 16:21:14 scdaemon[32523] DBG: dump: 6E 81 DD 4F 10 D2 76 00 01 24 01 02 01 00 06 04 17 44 32 00 00 5F 52 08 00 73 00 00 80 05 90 00 7F 74 03 81 01 20 73 81 B7 C0 0A 3C 00 00 00 04 C0 00 FF 00 FF C1 06 01 10 00 00 11 00 C2 06 01 10 00 00 11 00 C3 06 01 10 00 00 11 00 C4 07 00 7F 7F 7F 03 00 03 C5 3C D4 7E CF B6 9D A9 CC 0D B8 29 C1 34 0C FF 78 B7 1B 30 BC 88 3B 48 EC 91 DC 3C FA FE 99 41 E8 BC 90 4C 1E 1E F5 D4 61 95 41 E4 25 E5 2E B0 7A 65 C4 87 AC DD 7E 6C 44 E9 8E C0 D4 60 C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 57 46 2E 08 57 46 2E 08 57 46 2E 08 2016-07-13 16:21:14 scdaemon[32523] Key-Attr-sign ..: RSA, n=4096, e=17, fmt=std 2016-07-13 16:21:14 scdaemon[32523] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2016-07-13 16:21:14 scdaemon[32523] DBG: PCSC_data: 00 CA 00 6E 00 2016-07-13 16:21:15 scdaemon[32523] DBG: response: sw=9000 datalen=224 2016-07-13 16:21:15 scdaemon[32523] DBG: dump: 6E 81 DD 4F 10 D2 76 00 01 24 01 02 01 00 06 04 17 44 32 00 00 5F 52 08 00 73 00 00 80 05 90 00 7F 74 03 81 01 20 73 81 B7 C0 0A 3C 00 00 00 04 C0 00 FF 00 FF C1 06 01 10 00 00 11 00 C2 06 01 10 00 00 11 00 C3 06 01 10 00 00 11 00 C4 07 00 7F 7F 7F 03 00 03 C5 3C D4 7E CF B6 9D A9 CC 0D B8 29 C1 34 0C FF 78 B7 1B 30 BC 88 3B 48 EC 91 DC 3C FA FE 99 41 E8 BC 90 4C 1E 1E F5 D4 61 95 41 E4 25 E5 2E B0 7A 65 C4 87 AC DD 7E 6C 44 E9 8E C0 D4 60 C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 57 46 2E 08 57 46 2E 08 57 46 2E 08 2016-07-13 16:21:15 scdaemon[32523] Key-Attr-encr ..: RSA, n=4096, e=17, fmt=std 2016-07-13 16:21:15 scdaemon[32523] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2016-07-13 16:21:15 scdaemon[32523] DBG: PCSC_data: 00 CA 00 6E 00 2016-07-13 16:21:15 scdaemon[32523] DBG: response: sw=9000 datalen=224 2016-07-13 16:21:15 scdaemon[32523] DBG: dump: 6E 81 DD 4F 10 D2 76 00 01 24 01 02 01 00 06 04 17 44 32 00 00 5F 52 08 00 73 00 00 80 05 90 00 7F 74 03 81 01 20 73 81 B7 C0 0A 3C 00 00 00 04 C0 00 FF 00 FF C1 06 01 10 00 00 11 00 C2 06 01 10 00 00 11 00 C3 06 01 10 00 00 11 00 C4 07 00 7F 7F 7F 03 00 03 C5 3C D4 7E CF B6 9D A9 CC 0D B8 29 C1 34 0C FF 78 B7 1B 30 BC 88 3B 48 EC 91 DC 3C FA FE 99 41 E8 BC 90 4C 1E 1E F5 D4 61 95 41 E4 25 E5 2E B0 7A 65 C4 87 AC DD 7E 6C 44 E9 8E C0 D4 60 C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 57 46 2E 08 57 46 2E 08 57 46 2E 08 2016-07-13 16:21:15 scdaemon[32523] Key-Attr-auth ..: RSA, n=4096, e=17, fmt=std 2016-07-13 16:21:15 scdaemon[32523] DBG: chan_6 -> S SERIALNO D2760001240102010006041744320000 0 2016-07-13 16:21:15 scdaemon[32523] DBG: chan_6 -> OK 2016-07-13 16:21:15 scdaemon[32523] DBG: chan_6 <- SERIALNO openpgp 2016-07-13 16:21:15 scdaemon[32523] DBG: chan_6 -> S SERIALNO D2760001240102010006041744320000 0 2016-07-13 16:21:15 scdaemon[32523] DBG: chan_6 -> OK 2016-07-13 16:21:15 scdaemon[32523] DBG: chan_6 <- SERIALNO 2016-07-13 16:21:15 scdaemon[32523] DBG: chan_6 -> S SERIALNO D2760001240102010006041744320000 0 2016-07-13 16:21:15 scdaemon[32523] DBG: chan_6 -> OK 2016-07-13 16:21:15 scdaemon[32523] DBG: chan_6 <- LEARN --force 2016-07-13 16:21:15 scdaemon[32523] DBG: chan_6 -> S READER Yubico Yubikey 4 OTP+U2F+CCID 2016-07-13 16:21:15 scdaemon[32523] DBG: chan_6 -> S SERIALNO D2760001240102010006041744320000 0 2016-07-13 16:21:15 scdaemon[32523] DBG: chan_6 -> S APPTYPE OPENPGP 2016-07-13 16:21:15 scdaemon[32523] DBG: chan_6 -> S EXTCAP gc=0+ki=1+fc=1+pd=1+mcl3=1216+aac=1+sm=0+si=5+dec=0+bt=1 2016-07-13 16:21:15 scdaemon[32523] DBG: send apdu: c=00 i=CA p1=00 p2=65 lc=-1 le=256 em=0 2016-07-13 16:21:15 scdaemon[32523] DBG: PCSC_data: 00 CA 00 65 00 2016-07-13 16:21:15 scdaemon[32523] DBG: response: sw=9000 datalen=22 2016-07-13 16:21:15 scdaemon[32523] DBG: dump: 65 14 5B 0B 57 61 72 72 65 6E 3C 3C 42 65 6E 5F 2D 00 5F 35 01 39 2016-07-13 16:21:15 scdaemon[32523] DBG: chan_6 -> S DISP-NAME Warren< S DISP-LANG 2016-07-13 16:21:15 scdaemon[32523] DBG: chan_6 -> S DISP-SEX 9 2016-07-13 16:21:15 scdaemon[32523] DBG: send apdu: c=00 i=CA p1=5F p2=50 lc=-1 le=256 em=0 2016-07-13 16:21:15 scdaemon[32523] DBG: PCSC_data: 00 CA 5F 50 00 2016-07-13 16:21:15 scdaemon[32523] DBG: response: sw=9000 datalen=0 2016-07-13 16:21:15 scdaemon[32523] DBG: dump: 2016-07-13 16:21:15 scdaemon[32523] DBG: chan_6 -> S PUBKEY-URL 2016-07-13 16:21:15 scdaemon[32523] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2016-07-13 16:21:15 scdaemon[32523] DBG: PCSC_data: 00 CA 00 6E 00 2016-07-13 16:21:15 scdaemon[32523] DBG: response: sw=9000 datalen=224 2016-07-13 16:21:15 scdaemon[32523] DBG: dump: 6E 81 DD 4F 10 D2 76 00 01 24 01 02 01 00 06 04 17 44 32 00 00 5F 52 08 00 73 00 00 80 05 90 00 7F 74 03 81 01 20 73 81 B7 C0 0A 3C 00 00 00 04 C0 00 FF 00 FF C1 06 01 10 00 00 11 00 C2 06 01 10 00 00 11 00 C3 06 01 10 00 00 11 00 C4 07 00 7F 7F 7F 03 00 03 C5 3C D4 7E CF B6 9D A9 CC 0D B8 29 C1 34 0C FF 78 B7 1B 30 BC 88 3B 48 EC 91 DC 3C FA FE 99 41 E8 BC 90 4C 1E 1E F5 D4 61 95 41 E4 25 E5 2E B0 7A 65 C4 87 AC DD 7E 6C 44 E9 8E C0 D4 60 C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 57 46 2E 08 57 46 2E 08 57 46 2E 08 2016-07-13 16:21:15 scdaemon[32523] DBG: chan_6 -> S KEY-FPR 1 D47ECFB69DA9CC0DB829C1340CFF78B71B30BC88 2016-07-13 16:21:15 scdaemon[32523] DBG: chan_6 -> S KEY-FPR 2 3B48EC91DC3CFAFE9941E8BC904C1E1EF5D46195 2016-07-13 16:21:15 scdaemon[32523] DBG: chan_6 -> S KEY-FPR 3 41E425E52EB07A65C487ACDD7E6C44E98EC0D460 2016-07-13 16:21:15 scdaemon[32523] DBG: chan_6 -> S KEY-TIME 1 1464217096 2016-07-13 16:21:15 scdaemon[32523] DBG: chan_6 -> S KEY-TIME 2 1464217096 2016-07-13 16:21:15 scdaemon[32523] DBG: chan_6 -> S KEY-TIME 3 1464217096 2016-07-13 16:21:15 scdaemon[32523] DBG: send apdu: c=00 i=CA p1=00 p2=C4 lc=-1 le=256 em=0 2016-07-13 16:21:15 scdaemon[32523] DBG: PCSC_data: 00 CA 00 C4 00 2016-07-13 16:21:15 scdaemon[32523] DBG: response: sw=9000 datalen=7 2016-07-13 16:21:15 scdaemon[32523] DBG: dump: 00 7F 7F 7F 03 00 03 2016-07-13 16:21:15 scdaemon[32523] DBG: chan_6 -> S CHV-STATUS +0+127+127+127+3+0+3 2016-07-13 16:21:15 scdaemon[32523] DBG: send apdu: c=00 i=CA p1=00 p2=7A lc=-1 le=256 em=0 2016-07-13 16:21:15 scdaemon[32523] DBG: PCSC_data: 00 CA 00 7A 00 2016-07-13 16:21:15 scdaemon[32523] DBG: response: sw=9000 datalen=7 2016-07-13 16:21:15 scdaemon[32523] DBG: dump: 7A 05 93 03 00 00 50 2016-07-13 16:21:15 scdaemon[32523] DBG: chan_6 -> S SIG-COUNTER 80 2016-07-13 16:21:15 scdaemon[32523] DBG: send apdu: c=00 i=CA p1=01 p2=01 lc=-1 le=256 em=0 2016-07-13 16:21:15 scdaemon[32523] DBG: PCSC_data: 00 CA 01 01 00 2016-07-13 16:21:15 scdaemon[32523] DBG: response: sw=9000 datalen=0 2016-07-13 16:21:15 scdaemon[32523] DBG: dump: 2016-07-13 16:21:15 scdaemon[32523] DBG: chan_6 -> S PRIVATE-DO-1 2016-07-13 16:21:15 scdaemon[32523] DBG: send apdu: c=00 i=CA p1=01 p2=02 lc=-1 le=256 em=0 2016-07-13 16:21:15 scdaemon[32523] DBG: PCSC_data: 00 CA 01 02 00 2016-07-13 16:21:15 scdaemon[32523] DBG: response: sw=9000 datalen=0 2016-07-13 16:21:15 scdaemon[32523] DBG: dump: 2016-07-13 16:21:15 scdaemon[32523] DBG: chan_6 -> S PRIVATE-DO-2 2016-07-13 16:21:15 scdaemon[32523] DBG: send apdu: c=00 i=47 p1=81 p2=00 lc=2 le=256 em=0 2016-07-13 16:21:15 scdaemon[32523] DBG: PCSC_data: 00 47 81 00 02 B6 00 00 2016-07-13 16:21:15 scdaemon[32523] DBG: response: sw=61FF datalen=254 2016-07-13 16:21:15 scdaemon[32523] DBG: apdu_send_simple(0): 255 more bytes available 2016-07-13 16:21:15 scdaemon[32523] DBG: PCSC_data: 00 C0 00 00 FF 2016-07-13 16:21:15 scdaemon[32523] DBG: more: sw=6111 datalen=255 2016-07-13 16:21:15 scdaemon[32523] DBG: apdu_send_simple(0): 17 more bytes available 2016-07-13 16:21:15 scdaemon[32523] DBG: PCSC_data: 00 C0 00 00 11 2016-07-13 16:21:15 scdaemon[32523] DBG: more: sw=9000 datalen=17 2016-07-13 16:21:15 scdaemon[32523] DBG: dump: 7F 49 82 02 09 81 82 02 00 98 01 F7 DD 31 99 C9 6F 8F 2C 4E 9B 05 94 9A 8D FE 82 38 61 94 CC 3C 2C 41 68 8F C8 00 90 B3 4E 36 99 F5 65 2E 72 15 03 86 BE 72 C6 D6 09 7F 2E 46 54 C6 A1 9F B9 03 0D B9 53 38 A3 1A CC 97 22 22 80 E4 D7 5D 89 2C AD 6A AE A9 D2 03 C1 A8 EC 5A 77 9E 74 9A BE AB 9F 22 CE BB DE E3 C9 03 78 F7 F0 0D CC 49 6F C9 94 F4 54 6B 8B 30 5D 6D 80 6C D8 81 B5 C7 54 74 F4 51 E6 42 D9 43 9B 0D D6 EA 50 06 50 9C 65 AC C0 DF 9F 55 D1 51 13 B5 1D AF F0 AF 8A 5C C8 F6 9B 44 30 70 1C 75 EE 58 14 6B 99 92 BB 60 56 1A BB CC E4 6D 09 46 F3 31 80 DF CA A5 AD EF DB 5D 16 AA 9C 1B CE 2A 4F FB B6 1B 47 42 FE 1F 59 93 4E 39 AF 25 B6 BA C0 5E 10 9D 34 04 2F 1F DA B1 7A 9F 1A 7E D2 98 66 EF 32 6E 3D F5 75 EB D7 CE 09 88 02 16 FA B9 3E 68 FA A7 6D BB BC B1 CA 6C 6D 9A C8 4C 04 43 DB ED D3 6A EF F5 D5 9A C1 30 30 1F F4 0F 15 03 C4 2F F8 DA 49 E2 1B 39 F8 DA A8 4A 2C A5 B0 07 87 A3 79 9C FE C1 7A F0 49 58 8F D8 87 50 7B B6 D6 41 37 D3 03 96 E6 57 A5 DC 31 80 51 72 28 B6 7D 89 80 5F 18 48 B1 24 6C F7 BE 00 38 8E A3 6B AE 02 C7 06 F9 90 4A E5 53 87 6E 1F CE 66 CC F6 80 CD 5A D9 1B 11 0A 83 0F C2 AF D5 AF 49 F7 05 3A CD 62 81 60 3C D4 09 8B 55 D4 D1 1A 1D 2B AA 0C C9 87 05 4C 99 87 39 A0 6D B2 28 48 56 30 61 27 07 34 49 F4 60 B5 19 49 73 42 BA 6D ED B7 D4 66 4F D3 FE A9 63 0A 7E DA 17 45 61 A5 AC C0 6F 11 97 41 2E 44 17 F6 5F F1 0D 2D BD 12 A6 75 E2 B5 BF F9 81 56 D4 6F DE A4 2D 1D 54 A3 63 CC CE DF 13 C8 17 91 62 89 B4 DD FF 5C 5B 2C 1B 63 07 E1 75 4F DD B0 06 EC 80 8E BA AF 6F 94 1B 98 89 89 BE F6 45 83 20 72 FC 35 BB 77 96 0E 3E 5B 51 2A A9 2D 82 03 01 00 01 2016-07-13 16:21:15 scdaemon[32523] DBG: chan_6 -> S KEYPAIRINFO 29A464B126439B03BD82EB509C962FF3989F5667 OPENPGP.1 2016-07-13 16:21:15 scdaemon[32523] DBG: send apdu: c=00 i=47 p1=81 p2=00 lc=2 le=256 em=0 2016-07-13 16:21:15 scdaemon[32523] DBG: PCSC_data: 00 47 81 00 02 B8 00 00 2016-07-13 16:21:15 scdaemon[32523] DBG: response: sw=61FF datalen=254 2016-07-13 16:21:15 scdaemon[32523] DBG: apdu_send_simple(0): 255 more bytes available 2016-07-13 16:21:15 scdaemon[32523] DBG: PCSC_data: 00 C0 00 00 FF 2016-07-13 16:21:15 scdaemon[32523] DBG: more: sw=6111 datalen=255 2016-07-13 16:21:15 scdaemon[32523] DBG: apdu_send_simple(0): 17 more bytes available 2016-07-13 16:21:15 scdaemon[32523] DBG: PCSC_data: 00 C0 00 00 11 2016-07-13 16:21:15 scdaemon[32523] DBG: more: sw=9000 datalen=17 2016-07-13 16:21:15 scdaemon[32523] DBG: dump: 7F 49 82 02 09 81 82 02 00 91 80 DF 8B 40 EA 34 89 63 CB 67 76 C2 35 35 4E 1F 95 3F 86 BF 15 2B 81 24 F5 6F DE 5A 3E 4D D4 C3 26 7E 66 20 9A 67 2B E5 69 F2 AE 34 F3 B1 EB 36 F4 9F B5 EE FC 5F 89 FA 27 AF D8 21 D9 E8 8A 6B 7D 9A 17 AA 1A 4E 03 DC F4 FA 81 6F D1 A4 EA C9 98 43 7C FA 95 42 AC 0D 12 B8 73 63 C2 98 97 1E 07 C5 AE 54 30 87 96 B9 0B 20 4B 91 73 42 54 5C 27 53 FB 0A CE 10 07 08 FC BE FB FD B5 4C 83 08 9F F2 7C A3 7A 22 A4 6B D4 8F 7F 3E 9A 98 E6 31 F0 15 84 68 D5 46 4A C4 2F A5 27 69 53 63 CD 47 EA 1C FA A1 5C C8 DE 6A 35 85 23 6A 35 95 94 20 36 7C 8F F5 4A 63 C3 07 35 78 EA 04 6D 22 8F 32 31 5E E4 F9 1E B9 94 AF 60 DF 5A B8 62 D5 21 96 91 51 47 AA E7 05 22 D8 73 BB 3F A9 92 0B 93 D6 86 D4 E5 47 67 4F 1A B6 BD A6 9F 39 01 CB DA F1 33 24 BA 92 8E 72 DB AA D0 DE 14 96 8E 06 DA 5D 71 41 13 65 A9 C7 55 6D 55 54 6A FC A4 07 EE 40 03 A9 60 A7 74 53 29 F0 DE 98 08 66 B8 5A 83 A2 BC 00 F2 0E 25 02 C1 A0 F6 E7 00 A1 93 6F 97 26 47 59 30 D4 27 D6 C0 86 B1 0F 60 79 EC 51 63 75 30 71 B8 26 0F 68 E2 07 BB D0 B2 01 53 8C A4 E6 99 5F 57 FF 45 8F 0D 62 53 0E 88 8B B7 1B 2A 0E A8 F1 A5 7F A0 C1 99 B3 80 E3 5C 25 5A CC 87 60 82 D5 84 88 C4 79 53 5C AD CC BB A4 3E 9C 4B 8E 7D 52 9C 63 36 FF 68 87 D7 24 A3 CA 6D 26 77 C4 82 4C 2B 08 94 1B 6C 8B 4B 53 BA A7 F5 69 70 0E E9 0B 95 2E 09 AB 35 3A 7D 64 37 AF E7 47 FB 3E 00 A2 35 EE 51 40 27 D7 A2 12 72 6A 89 61 8D CF 0F A7 AE D8 01 08 85 EF A7 D7 94 7C F7 CE C7 EC 37 D1 8A B8 C2 A4 68 D6 10 95 0D D3 AE 48 C2 D3 02 51 C7 24 55 56 D9 8B 8F C2 50 FF C8 79 53 92 F6 7F 28 8D 7A 49 EC C2 BE 21 64 FF 2B 87 8B 82 03 01 00 01 2016-07-13 16:21:15 scdaemon[32523] DBG: chan_6 -> S KEYPAIRINFO 511EF9D699657CEF5540CEF47EA29D6A6240BD88 OPENPGP.2 2016-07-13 16:21:15 scdaemon[32523] DBG: send apdu: c=00 i=47 p1=81 p2=00 lc=2 le=256 em=0 2016-07-13 16:21:15 scdaemon[32523] DBG: PCSC_data: 00 47 81 00 02 A4 00 00 2016-07-13 16:21:15 scdaemon[32523] DBG: response: sw=61FF datalen=254 2016-07-13 16:21:15 scdaemon[32523] DBG: apdu_send_simple(0): 255 more bytes available 2016-07-13 16:21:15 scdaemon[32523] DBG: PCSC_data: 00 C0 00 00 FF 2016-07-13 16:21:15 scdaemon[32523] DBG: more: sw=6111 datalen=255 2016-07-13 16:21:15 scdaemon[32523] DBG: apdu_send_simple(0): 17 more bytes available 2016-07-13 16:21:15 scdaemon[32523] DBG: PCSC_data: 00 C0 00 00 11 2016-07-13 16:21:15 scdaemon[32523] DBG: more: sw=9000 datalen=17 2016-07-13 16:21:15 scdaemon[32523] DBG: dump: 7F 49 82 02 09 81 82 02 00 9C EA 38 6E C5 2C 6F FA 93 D7 22 1A 0A 78 75 7A 54 EE 6D 19 A2 FE 19 8C 15 A0 92 35 91 A4 A0 46 CA 05 EE 6A 21 F7 5B C7 D5 FE 54 A3 7F 92 C1 BE E8 69 C0 59 25 18 DD 4F C5 2E 07 68 EC EE 67 74 35 C3 DF A6 57 01 F3 18 F5 79 2C 34 11 2C 4B FA EA E9 5C A8 B7 19 59 A7 5D 82 2D 98 C8 87 E8 6D 7C 5F CC E2 BA 3F 64 17 A8 EA 69 13 6D 9E FA 77 74 97 B6 64 6C C9 BF 3C 6E F7 4E 51 EA 49 16 9E 20 7D 42 8E 2F 22 5D 16 7B 53 62 DE 16 72 D4 6F 4E 35 A5 C0 4C 40 D0 7C A5 5C 0C 72 49 69 E0 8F B6 1E 72 94 A9 27 2E 5C AC 4C 18 60 D3 04 57 51 0B D3 BF D6 5E 8F 9D EF 72 82 B7 68 5F 73 4F 04 EF FD 06 8B 2E 54 BA 1D BC 22 4E 4A 6B 06 3D EE FE 70 D5 0C 7C AE 83 19 5B 01 D4 1D DA B3 CF 40 C7 C6 5D AA 7B D0 1E C9 D6 73 07 D0 72 BC 04 70 E0 68 18 74 1F 8F 69 3E F7 3B BB 7C 88 B9 59 60 27 86 D9 D5 3D 06 EC 3B D3 A6 83 06 09 6C 57 41 FE 26 F8 3D 02 D5 03 02 A8 D0 A2 FE 29 0D C1 B0 77 E6 10 39 C9 6E DF 84 99 58 A2 2F 24 CA 71 9C 98 90 DB 36 56 7B EA 4D 94 C8 2D 2D 6A CD 44 52 A8 C3 B8 F4 52 59 4B 56 FD 6D CD FF C3 06 7C 87 E2 21 E6 34 3C 57 8A D6 49 A1 76 BF CD 12 33 74 D5 03 00 76 73 4C 2A 3C 63 C9 B2 4C 71 3E E5 5F 6A 5B D5 AD 89 83 D6 9A 49 A8 30 E3 F2 69 B8 A7 D9 E0 3B A0 68 23 34 DF A8 43 1B 9C 11 86 F1 C7 6F 36 80 0F 06 00 A5 88 83 24 5E 7F 86 7F C0 F8 F2 6C A1 44 6D A4 27 70 7E B2 D4 48 B5 54 5E 6D 33 E2 0C 65 9F FC 48 D7 52 7C 55 73 19 94 C5 F9 74 B2 1E D0 64 F8 4C A9 26 BA FA CF ED 8B 01 3D F6 2B F9 8C F6 D4 F2 CC 1A A0 C8 76 70 8F E0 E9 79 87 ED 19 8E 6A DA FB 3E 6B 80 75 AA 0C 6D B7 C6 34 A1 93 CC D2 DE 86 00 C3 A8 07 9A BD D3 F5 82 03 01 00 01 2016-07-13 16:21:15 scdaemon[32523] DBG: chan_6 -> S KEYPAIRINFO DC0DAB6999A2747AB9CDB22FDB67ABBEDE9FF4DB OPENPGP.3 2016-07-13 16:21:15 scdaemon[32523] DBG: chan_6 -> OK 2016-07-13 16:21:15 scdaemon[32523] DBG: chan_6 <- GETATTR KEY-ATTR 2016-07-13 16:21:15 scdaemon[32523] DBG: chan_6 -> S KEY-ATTR 1 1 rsa4096 17 1 2016-07-13 16:21:15 scdaemon[32523] DBG: chan_6 -> S KEY-ATTR 2 1 rsa4096 17 1 2016-07-13 16:21:15 scdaemon[32523] DBG: chan_6 -> S KEY-ATTR 3 1 rsa4096 17 1 2016-07-13 16:21:15 scdaemon[32523] DBG: chan_6 -> OK 2016-07-13 16:21:15 scdaemon[32523] DBG: enter: apdu_get_status: slot=0 hang=0 2016-07-13 16:21:15 scdaemon[32523] DBG: leave: apdu_get_status => sw=0x0 status=7 changecnt=1 2016-07-13 16:21:15 scdaemon[32523] updating reader 0 (0) status: 0x0000->0x0007 (0->1) 2016-07-13 16:21:15 scdaemon[32523] sending signal 31 to client 1133 2016-07-13 16:21:15 scdaemon[32523] DBG: enter: apdu_get_status: slot=0 hang=0 2016-07-13 16:21:15 scdaemon[32523] DBG: leave: apdu_get_status => sw=0x0 status=7 changecnt=1 ... 2016-07-13 16:21:18 scdaemon[32523] DBG: enter: apdu_get_status: slot=0 hang=0 2016-07-13 16:21:18 scdaemon[32523] DBG: leave: apdu_get_status => sw=0x0 status=7 changecnt=1 2016-07-13 16:21:19 scdaemon[32523] DBG: chan_6 <- SERIALNO openpgp 2016-07-13 16:21:19 scdaemon[32523] DBG: chan_6 -> S SERIALNO D2760001240102010006041744320000 0 2016-07-13 16:21:19 scdaemon[32523] DBG: chan_6 -> OK 2016-07-13 16:21:19 scdaemon[32523] DBG: chan_6 <- SERIALNO 2016-07-13 16:21:19 scdaemon[32523] DBG: chan_6 -> S SERIALNO D2760001240102010006041744320000 0 2016-07-13 16:21:19 scdaemon[32523] DBG: chan_6 -> OK 2016-07-13 16:21:19 scdaemon[32523] DBG: chan_6 <- LEARN --force 2016-07-13 16:21:19 scdaemon[32523] DBG: chan_6 -> S READER Yubico Yubikey 4 OTP+U2F+CCID 2016-07-13 16:21:19 scdaemon[32523] DBG: chan_6 -> S SERIALNO D2760001240102010006041744320000 0 2016-07-13 16:21:19 scdaemon[32523] DBG: chan_6 -> S APPTYPE OPENPGP 2016-07-13 16:21:19 scdaemon[32523] DBG: chan_6 -> S EXTCAP gc=0+ki=1+fc=1+pd=1+mcl3=1216+aac=1+sm=0+si=5+dec=0+bt=1 2016-07-13 16:21:19 scdaemon[32523] DBG: chan_6 -> S DISP-NAME Warren< S DISP-LANG 2016-07-13 16:21:19 scdaemon[32523] DBG: chan_6 -> S DISP-SEX 9 2016-07-13 16:21:19 scdaemon[32523] DBG: chan_6 -> S KEY-FPR 1 D47ECFB69DA9CC0DB829C1340CFF78B71B30BC88 2016-07-13 16:21:19 scdaemon[32523] DBG: chan_6 -> S KEY-FPR 2 3B48EC91DC3CFAFE9941E8BC904C1E1EF5D46195 2016-07-13 16:21:19 scdaemon[32523] DBG: chan_6 -> S KEY-FPR 3 41E425E52EB07A65C487ACDD7E6C44E98EC0D460 2016-07-13 16:21:19 scdaemon[32523] DBG: chan_6 -> S KEY-TIME 1 1464217096 2016-07-13 16:21:19 scdaemon[32523] DBG: chan_6 -> S KEY-TIME 2 1464217096 2016-07-13 16:21:19 scdaemon[32523] DBG: chan_6 -> S KEY-TIME 3 1464217096 2016-07-13 16:21:19 scdaemon[32523] DBG: send apdu: c=00 i=CA p1=00 p2=C4 lc=-1 le=256 em=0 2016-07-13 16:21:19 scdaemon[32523] DBG: PCSC_data: 00 CA 00 C4 00 2016-07-13 16:21:19 scdaemon[32523] DBG: response: sw=9000 datalen=7 2016-07-13 16:21:19 scdaemon[32523] DBG: dump: 00 7F 7F 7F 03 00 03 2016-07-13 16:21:19 scdaemon[32523] DBG: chan_6 -> S CHV-STATUS +0+127+127+127+3+0+3 2016-07-13 16:21:19 scdaemon[32523] DBG: send apdu: c=00 i=CA p1=00 p2=7A lc=-1 le=256 em=0 2016-07-13 16:21:19 scdaemon[32523] DBG: PCSC_data: 00 CA 00 7A 00 2016-07-13 16:21:19 scdaemon[32523] DBG: response: sw=9000 datalen=7 2016-07-13 16:21:19 scdaemon[32523] DBG: dump: 7A 05 93 03 00 00 50 2016-07-13 16:21:19 scdaemon[32523] DBG: chan_6 -> S SIG-COUNTER 80 2016-07-13 16:21:19 scdaemon[32523] DBG: chan_6 -> S KEYPAIRINFO 29A464B126439B03BD82EB509C962FF3989F5667 OPENPGP.1 2016-07-13 16:21:19 scdaemon[32523] DBG: chan_6 -> S KEYPAIRINFO 511EF9D699657CEF5540CEF47EA29D6A6240BD88 OPENPGP.2 2016-07-13 16:21:19 scdaemon[32523] DBG: chan_6 -> S KEYPAIRINFO DC0DAB6999A2747AB9CDB22FDB67ABBEDE9FF4DB OPENPGP.3 2016-07-13 16:21:19 scdaemon[32523] DBG: chan_6 -> OK 2016-07-13 16:21:19 scdaemon[32523] DBG: chan_6 <- GETATTR KEY-ATTR 2016-07-13 16:21:19 scdaemon[32523] DBG: chan_6 -> S KEY-ATTR 1 1 rsa4096 17 1 2016-07-13 16:21:19 scdaemon[32523] DBG: chan_6 -> S KEY-ATTR 2 1 rsa4096 17 1 2016-07-13 16:21:19 scdaemon[32523] DBG: chan_6 -> S KEY-ATTR 3 1 rsa4096 17 1 2016-07-13 16:21:19 scdaemon[32523] DBG: chan_6 -> OK 2016-07-13 16:21:19 scdaemon[32523] DBG: enter: apdu_get_status: slot=0 hang=0 2016-07-13 16:21:19 scdaemon[32523] DBG: leave: apdu_get_status => sw=0x0 status=7 changecnt=1 ... 2016-07-13 16:21:21 scdaemon[32523] DBG: enter: apdu_get_status: slot=0 hang=0 2016-07-13 16:21:21 scdaemon[32523] DBG: leave: apdu_get_status => sw=0x0 status=7 changecnt=1 2016-07-13 16:21:21 scdaemon[32523] DBG: chan_6 <- PASSWD 1 2016-07-13 16:21:21 scdaemon[32523] DBG: check_pcsc_pinpad: command=24, r=27265 2016-07-13 16:21:21 scdaemon[32523] DBG: asking for PIN '||Please enter the PIN' 2016-07-13 16:21:21 scdaemon[32523] DBG: chan_6 -> INQUIRE NEEDPIN ||Please enter the PIN 2016-07-13 16:21:22 scdaemon[32523] DBG: enter: apdu_get_status: slot=0 hang=0 2016-07-13 16:21:22 scdaemon[32523] DBG: leave: apdu_get_status => sw=0x0 status=7 changecnt=1 2016-07-13 16:21:22 scdaemon[32523] DBG: enter: apdu_get_status: slot=0 hang=0 ... 2016-07-13 16:21:24 scdaemon[32523] DBG: leave: apdu_get_status => sw=0x0 status=7 changecnt=1 2016-07-13 16:21:24 scdaemon[32523] DBG: chan_6 <- [ 44 20 54 69 67 67 65 72 32 73 21 00 00 00 00 00 ...(76 byte(s) skipped) ] 2016-07-13 16:21:24 scdaemon[32523] DBG: chan_6 <- END 2016-07-13 16:21:24 scdaemon[32523] DBG: asking for PIN '|N|New PIN' 2016-07-13 16:21:24 scdaemon[32523] DBG: chan_6 -> INQUIRE NEEDPIN |N|New PIN 2016-07-13 16:21:25 scdaemon[32523] DBG: enter: apdu_get_status: slot=0 hang=0 2016-07-13 16:21:25 scdaemon[32523] DBG: leave: apdu_get_status => sw=0x0 status=7 changecnt=1 2016-07-13 16:21:25 scdaemon[32523] DBG: enter: apdu_get_status: slot=0 hang=0 ... 2016-07-13 16:21:29 scdaemon[32523] DBG: leave: apdu_get_status => sw=0x0 status=7 changecnt=1 2016-07-13 16:21:29 scdaemon[32523] DBG: chan_6 <- [ 44 20 31 32 33 34 35 36 00 00 00 00 00 00 00 00 ...(76 byte(s) skipped) ] 2016-07-13 16:21:29 scdaemon[32523] DBG: chan_6 <- END 2016-07-13 16:21:29 scdaemon[32523] DBG: send apdu: c=00 i=24 p1=00 p2=81 lc=15 le=-1 em=0 2016-07-13 16:21:29 scdaemon[32523] DBG: PCSC_data: 00 24 00 81 0F 54 69 67 67 65 72 32 73 21 31 32 33 34 35 36 2016-07-13 16:21:29 scdaemon[32523] DBG: response: sw=9000 datalen=0 2016-07-13 16:21:29 scdaemon[32523] DBG: dump: 2016-07-13 16:21:29 scdaemon[32523] operation change_pin result: Success 2016-07-13 16:21:29 scdaemon[32523] DBG: chan_6 -> OK 2016-07-13 16:21:29 scdaemon[32523] DBG: enter: apdu_get_status: slot=0 hang=0 ... 2016-07-13 16:21:32 scdaemon[32523] DBG: leave: apdu_get_status => sw=0x0 status=7 changecnt=1 2016-07-13 16:21:32 scdaemon[32523] DBG: chan_6 <- RESTART 2016-07-13 16:21:32 scdaemon[32523] DBG: chan_6 -> OK 2016-07-13 16:21:33 scdaemon[32523] DBG: enter: apdu_get_status: slot=0 hang=0 2016-07-13 16:21:33 scdaemon[32523] DBG: leave: apdu_get_status => sw=0x0 status=7 changecnt=1 ... 2016-07-13 16:21:36 scdaemon[32523] DBG: enter: apdu_get_status: slot=0 hang=0 2016-07-13 16:21:36 scdaemon[32523] DBG: leave: apdu_get_status => sw=0x0 status=7 changecnt=1 2016-07-13 16:21:36 scdaemon[32523] DBG: chan_6 <- GETATTR $AUTHKEYID 2016-07-13 16:21:36 scdaemon[32523] DBG: enter: apdu_connect: slot=0 2016-07-13 16:21:36 scdaemon[32523] DBG: leave: apdu_connect => sw=0x1000f 2016-07-13 16:21:36 scdaemon[32523] DBG: chan_6 -> S $AUTHKEYID OPENPGP.3 2016-07-13 16:21:36 scdaemon[32523] DBG: chan_6 -> OK 2016-07-13 16:21:36 scdaemon[32523] DBG: chan_6 <- GETATTR SERIALNO 2016-07-13 16:21:36 scdaemon[32523] DBG: chan_6 -> S SERIALNO D2760001240102010006041744320000 2016-07-13 16:21:36 scdaemon[32523] DBG: chan_6 -> OK 2016-07-13 16:21:36 scdaemon[32523] DBG: chan_6 <- READKEY OPENPGP.3 2016-07-13 16:21:36 scdaemon[32523] DBG: chan_6 -> [ 44 20 28 31 30 3a 70 75 62 6c 69 63 2d 6b 65 79 ...(546 byte(s) skipped) ] 2016-07-13 16:21:36 scdaemon[32523] DBG: chan_6 -> OK 2016-07-13 16:21:36 scdaemon[32523] DBG: chan_6 <- GETATTR $DISPSERIALNO 2016-07-13 16:21:36 scdaemon[32523] DBG: chan_6 -> S $DISPSERIALNO 000604174432 2016-07-13 16:21:36 scdaemon[32523] DBG: chan_6 -> OK 2016-07-13 16:21:36 scdaemon[32523] DBG: chan_6 <- SERIALNO 2016-07-13 16:21:36 scdaemon[32523] DBG: chan_6 -> S SERIALNO D2760001240102010006041744320000 0 2016-07-13 16:21:36 scdaemon[32523] DBG: chan_6 -> OK 2016-07-13 16:21:36 scdaemon[32523] DBG: chan_6 <- SETDATA 3021300906052B0E03021A050004148AF192FCBE17500BAA9751007A5CC0E2185909F1 2016-07-13 16:21:36 scdaemon[32523] DBG: chan_6 -> OK 2016-07-13 16:21:36 scdaemon[32523] DBG: chan_6 <- PKAUTH OPENPGP.3 2016-07-13 16:21:36 scdaemon[32523] DBG: check_pcsc_pinpad: command=20, r=27265 2016-07-13 16:21:36 scdaemon[32523] DBG: asking for PIN '||Please enter the PIN' 2016-07-13 16:21:36 scdaemon[32523] DBG: chan_6 -> INQUIRE NEEDPIN ||Please enter the PIN 2016-07-13 16:21:37 scdaemon[32523] DBG: enter: apdu_get_status: slot=0 hang=0 2016-07-13 16:21:37 scdaemon[32523] DBG: leave: apdu_get_status => sw=0x0 status=7 changecnt=1 ... 2016-07-13 16:21:39 scdaemon[32523] DBG: enter: apdu_get_status: slot=0 hang=0 2016-07-13 16:21:39 scdaemon[32523] DBG: leave: apdu_get_status => sw=0x0 status=7 changecnt=1 2016-07-13 16:21:39 scdaemon[32523] DBG: chan_6 <- [ 44 20 31 32 33 34 35 36 00 00 00 00 00 00 00 00 ...(76 byte(s) skipped) ] 2016-07-13 16:21:39 scdaemon[32523] DBG: chan_6 <- END 2016-07-13 16:21:39 scdaemon[32523] DBG: send apdu: c=00 i=20 p1=00 p2=82 lc=6 le=-1 em=0 2016-07-13 16:21:39 scdaemon[32523] DBG: PCSC_data: 00 20 00 82 06 31 32 33 34 35 36 2016-07-13 16:21:39 scdaemon[32523] DBG: response: sw=9000 datalen=0 2016-07-13 16:21:39 scdaemon[32523] DBG: dump: 2016-07-13 16:21:39 scdaemon[32523] DBG: send apdu: c=00 i=88 p1=00 p2=00 lc=35 le=256 em=0 2016-07-13 16:21:39 scdaemon[32523] DBG: PCSC_data: 00 88 00 00 23 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14 8A F1 92 FC BE 17 50 0B AA 97 51 00 7A 5C C0 E2 18 59 09 F1 00 2016-07-13 16:21:40 scdaemon[32523] DBG: response: sw=61FF datalen=254 2016-07-13 16:21:40 scdaemon[32523] DBG: apdu_send_simple(0): 255 more bytes available 2016-07-13 16:21:40 scdaemon[32523] DBG: PCSC_data: 00 C0 00 00 FF 2016-07-13 16:21:40 scdaemon[32523] DBG: more: sw=6103 datalen=255 2016-07-13 16:21:40 scdaemon[32523] DBG: apdu_send_simple(0): 3 more bytes available 2016-07-13 16:21:40 scdaemon[32523] DBG: PCSC_data: 00 C0 00 00 03 2016-07-13 16:21:40 scdaemon[32523] DBG: more: sw=9000 datalen=3 2016-07-13 16:21:40 scdaemon[32523] DBG: dump: 37 55 88 22 41 2D 48 39 1A 69 66 1B 96 F2 C4 45 51 EC 7C FC 64 18 8B 0F CF 4B E9 CF DA 41 BF 8C 10 88 89 48 8C 6C A8 07 A4 CD BA D3 F9 30 C6 C7 51 5F 7C 80 E9 15 1F 30 23 84 82 C9 1C 09 5A 22 D5 74 A8 1C 27 54 82 5D C4 DB CC DA CD 24 83 4A B5 60 38 BD 9D 4E 40 36 AB CB 21 10 26 74 1D 53 29 CD 77 77 D4 40 D5 50 E9 03 94 46 24 69 AE 9F 5E 29 FD 5D A2 42 F8 B5 CF 91 E6 8F 55 B7 3B F5 93 71 90 DB BA C5 57 26 00 A7 3D 13 85 5F 6F B5 BE AD 28 50 F0 6E 8A 82 58 04 15 3D BE B5 F9 8E 38 F3 78 B2 01 35 55 0D 4F 2F 74 65 7F 89 1E AF 0D 16 84 89 AE 8C 60 F4 2E 4A 7C 88 36 37 EE 3F D9 83 F6 62 1C 44 08 64 15 AD F3 C1 EB 2D 09 58 A8 29 55 21 74 D3 40 CD CB C8 6F 81 28 CB 1C FB 7D 31 24 ED 68 7E FD 6C 48 6B 33 B1 15 64 0B 69 39 A4 F4 45 AD 69 24 DD 5B FF 10 E2 1A F1 E2 3E 8D DA A1 8A 77 91 D0 61 EA EF 02 71 46 87 6F 18 DC 96 67 EB 6E 69 36 79 16 42 D6 76 40 F7 60 41 77 9E D7 5C 0B 9F 81 7C C0 C8 65 2A 75 04 75 FF 30 36 ED D9 EE F0 B7 9D 3B FA 0D 1E B2 BC 1A DA 32 5F 04 FF 63 68 CE E7 31 61 E9 29 66 AF 73 50 D1 C0 5E F1 0A C4 C0 E6 CF 9F 25 7E 6E EE A0 39 54 95 F6 BF AA D5 50 3B C9 84 46 C4 A1 81 68 76 C1 E5 A8 C1 1A 77 21 8B C4 D0 D2 6B 20 14 FB CD 66 6F 63 28 AA 83 22 14 B6 C4 28 56 49 1B 39 04 2A C5 13 AA B6 69 27 7C 50 F6 58 69 9E E8 30 28 EC 9C 63 3E A6 6E 3A EF 52 B6 7D E6 49 6E F5 D1 E7 B9 2F 51 FC 54 49 FA AF 8A 24 11 9D 33 04 4E 62 03 73 A4 FC 10 14 A9 34 32 20 A6 E9 E5 AB 82 1A 3D 0C 7B 25 EB 3E 87 01 A7 A3 FB D3 50 AD 7F 96 FC 92 D5 ED EB FE C8 E3 AB 60 5F 86 53 4F 73 C5 47 17 56 08 BA 51 61 47 CB 6D CD 15 45 AB B8 2016-07-13 16:21:40 scdaemon[32523] operation auth result: Success 2016-07-13 16:21:40 scdaemon[32523] DBG: chan_6 -> [ 44 20 37 55 88 22 41 2d 48 39 1a 69 66 1b 96 f2 ...(510 byte(s) skipped) ] 2016-07-13 16:21:40 scdaemon[32523] DBG: enter: apdu_get_status: slot=0 hang=0 2016-07-13 16:21:40 scdaemon[32523] DBG: leave: apdu_get_status => sw=0x0 status=7 changecnt=1 2016-07-13 16:21:40 scdaemon[32523] DBG: chan_6 -> OK 2016-07-13 16:21:41 scdaemon[32523] DBG: enter: apdu_get_status: slot=0 hang=0 2016-07-13 16:21:41 scdaemon[32523] DBG: leave: apdu_get_status => sw=0x0 status=7 changecnt=1 ? 2016-07-13 16:26:04 scdaemon[32523] DBG: enter: apdu_get_status: slot=0 hang=0 2016-07-13 16:26:04 scdaemon[32523] DBG: leave: apdu_get_status => sw=0x0 status=7 changecnt=1 2016-07-13 16:26:04 scdaemon[32523] DBG: enter: apdu_get_status: slot=0 hang=0 2016-07-13 16:26:04 scdaemon[32523] DBG: leave: apdu_get_status => sw=0x0 status=0 changecnt=2 2016-07-13 16:26:04 scdaemon[32523] updating reader 0 (0) status: 0x0007->0x0000 (1->2) 2016-07-13 16:26:04 scdaemon[32523] sending signal 31 to client 1133 2016-07-13 16:26:05 scdaemon[32523] DBG: enter: apdu_get_status: slot=0 hang=0 2016-07-13 16:26:05 scdaemon[32523] DBG: leave: apdu_get_status => sw=0x0 status=0 changecnt=2 2016-07-13 16:26:05 scdaemon[32523] DBG: enter: apdu_get_status: slot=0 hang=0 ? 2016-07-13 16:27:44 scdaemon[32523] DBG: leave: apdu_get_status => sw=0x0 status=0 changecnt=2 2016-07-13 16:27:44 scdaemon[32523] DBG: enter: apdu_get_status: slot=0 hang=0 2016-07-13 16:27:44 scdaemon[32523] DBG: leave: apdu_get_status => sw=0x0 status=7 changecnt=3 2016-07-13 16:27:44 scdaemon[32523] updating reader 0 (0) status: 0x0000->0x0007 (2->3) 2016-07-13 16:27:44 scdaemon[32523] sending signal 31 to client 1133 2016-07-13 16:27:45 scdaemon[32523] DBG: enter: apdu_get_status: slot=0 hang=0 2016-07-13 16:27:45 scdaemon[32523] DBG: leave: apdu_get_status => sw=0x0 status=7 changecnt=3 ? 2016-07-13 16:28:00 scdaemon[32523] DBG: leave: apdu_get_status => sw=0x0 status=7 changecnt=3 2016-07-13 16:28:01 scdaemon[32523] DBG: enter: apdu_get_status: slot=0 hang=0 2016-07-13 16:28:01 scdaemon[32523] DBG: leave: apdu_get_status => sw=0x0 status=7 changecnt=3 2016-07-13 16:28:01 scdaemon[32523] DBG: chan_6 <- RESTART 2016-07-13 16:28:01 scdaemon[32523] Ohhhh jeeee: trying to release an already released context 2016-07-13 16:30:40 scdaemon[32745] listening on socket '/Users/ben/.gnupg/S.scdaemon' 2016-07-13 16:30:40 scdaemon[32745] handler for fd -1 started 2016-07-13 16:30:40 scdaemon[32745] DBG: enter: apdu_open_reader: portstr=(null) 2016-07-13 16:30:40 scdaemon[32745] detected reader 'Yubico Yubikey 4 OTP+U2F+CCID' 2016-07-13 16:30:40 scdaemon[32745] reader slot 0: not connected 2016-07-13 16:30:40 scdaemon[32745] DBG: leave: apdu_open_reader => slot=0 [pc/sc] 2016-07-13 16:30:40 scdaemon[32745] DBG: chan_6 -> OK GNU Privacy Guard's Smartcard server ready 2016-07-13 16:30:40 scdaemon[32745] DBG: chan_6 <- GETINFO socket_name 2016-07-13 16:30:40 scdaemon[32745] DBG: chan_6 -> D /Users/ben/.gnupg/S.scdaemon 2016-07-13 16:30:40 scdaemon[32745] DBG: chan_6 -> OK 2016-07-13 16:30:40 scdaemon[32745] DBG: chan_6 <- OPTION event-signal=31 2016-07-13 16:30:40 scdaemon[32745] DBG: chan_6 -> OK 2016-07-13 16:30:40 scdaemon[32745] DBG: chan_6 <- GETATTR $AUTHKEYID 2016-07-13 16:30:40 scdaemon[32745] DBG: enter: apdu_connect: slot=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3583 bytes Desc: not available URL: From mk at erfrakon.de Sat Jul 16 16:38:27 2016 From: mk at erfrakon.de (Martin Konold) Date: Sat, 16 Jul 2016 16:38:27 +0200 Subject: GPG and Mailinglists using IBCPRE Message-ID: <4913701.NByz4kV0ia@sony-01.tue.hq.erfrakon.de> Hi, what is currently the recommended setup for running encrypted mailing lists. I am thinking about some IBCPRE mechanism. see also https://en.wikipedia.org/ wiki/Identity-based_conditional_proxy_re-encryption I think this would allow the mailing list software act as a proxy reencrypting without directly having the private key of the mailing list on the mailing list server. What do you think about IBCPRE. Regards --martin Mit freundlichen Gr??en --martin konold -- Dipl.-Physiker Martin Konold e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Registergericht: Amtsgericht Stuttgart PR 126 Firmensitz: Adolfstra?e 23, 70469 Stuttgart fon: 0711 67400963 fax: 0711 67400959 email: martin.konold at erfrakon.de http://www.erfrakon.de From yuriping at sohu.com Sun Jul 17 05:59:02 2016 From: yuriping at sohu.com (yuriping at sohu.com) Date: Sun, 17 Jul 2016 11:59:02 +0800 Subject: GPGME signing failed: Bad passphrase Message-ID: <1468727942.0248a1d3a6214127a4c3e46827056b4e.yuriping@sohu.com> Hi, all,    We're using GPGME now.    Follow is my key-list:root at YRP-ES-QD:/opt/TestCell# gpg --list-key/root/.gnupg/pubring.gpg------------------------pub   2048R/6F9DDC7B 2016-06-12uid                  yuriping (No) <yuriping at sohu.com>sub   2048R/1FFB24D9 2016-06-12pub   2048R/5FEC9A32 2016-06-12uid                  yuriping (3) <yuriping at sohu.com>sub   2048R/DD422577 2016-06-12pub   2048R/843ECE40 2016-06-12uid                  yuriping (0000) <yuriping at sohu.com>sub   2048R/3A19E9FD 2016-06-12pub   2048R/86111D4F 2016-06-15uid                  yuriping (0002) <yuriping at sohu.com>sub   2048R/DC783135 2016-06-15    I encountered one problem When running ./run-sign demo, as following:root at YRP-ES-QD:/opt/TestCell# ./run-sign --key 5FEC9A32 gpgme_test.c run-sign: signing failed: Bad passphrase    Does this mean I should use gpg-agent, or I should assign the passphrase somewhere?    Thanks for any reply!    Best Regards! ------------------------------------------ ???????????????????~ -------------- next part -------------- An HTML attachment was scrubbed... URL: From neal at walfield.org Sun Jul 17 15:19:37 2016 From: neal at walfield.org (Neal H. Walfield) Date: Sun, 17 Jul 2016 15:19:37 +0200 Subject: GPG and Mailinglists using IBCPRE In-Reply-To: <4913701.NByz4kV0ia@sony-01.tue.hq.erfrakon.de> References: <4913701.NByz4kV0ia@sony-01.tue.hq.erfrakon.de> Message-ID: <87vb04l7va.wl-neal@walfield.org> Hi, On Sat, 16 Jul 2016 16:38:27 +0200, Martin Konold wrote: > what is currently the recommended setup for running encrypted mailing lists. > > I am thinking about some IBCPRE mechanism. see also https://en.wikipedia.org/ > wiki/Identity-based_conditional_proxy_re-encryption > > I think this would allow the mailing list software act as a proxy reencrypting > without directly having the private key of the mailing list on the mailing > list server. > > What do you think about IBCPRE. There is some highly experimental support in a GnuPG branch for mailing list support that doesn't require that the server access the plain text. You can read about it here: http://hssl.cs.jhu.edu/~neal/encrypted-mailing-lists.pdf Thanks, :) Neal From ng0 at we.make.ritual.n0.is Sun Jul 17 15:53:55 2016 From: ng0 at we.make.ritual.n0.is (ng0) Date: Sun, 17 Jul 2016 13:53:55 +0000 Subject: gpgscm Message-ID: <87fur8v098.fsf@we.make.ritual.n0.is> Hi, I'm one of the developers involved in Guix. While doing the update of gnupg from 2.1.13 to 2.1.14 I found out that you now include a modified version of tinyscheme for running your tests/opengpg/ tests. Are the changes you apply to tinyscheme generic enough to contribute to upstream, so that we can just include a modified tinyscheme software to run tests/opengpg/ tests during the check phase of GnuPG? If they aren't, could you move the gpgscm binary outside of the source of gnupg to not include bundled dependencies, or in some more convinient way for you? As there seems to be no general developer list for GnuPG I'll use this list, we can move the discussion elsewhere if it does not fit in here. -- ?? ng0 For non-prism friendly talk find me on http://www.psyced.org SecuShare ? http://secushare.org From richard.hoechenberger at gmail.com Sun Jul 17 15:53:47 2016 From: richard.hoechenberger at gmail.com (=?UTF-8?Q?Richard_H=C3=B6chenberger?=) Date: Sun, 17 Jul 2016 15:53:47 +0200 Subject: GPG and Mailinglists using IBCPRE In-Reply-To: <87vb04l7va.wl-neal@walfield.org> References: <4913701.NByz4kV0ia@sony-01.tue.hq.erfrakon.de> <87vb04l7va.wl-neal@walfield.org> Message-ID: Hi, we've been using Schleuder2 for many years now, and it has always worked flawlessly on a medium-traffic mailing list as long as everyone used OpenPGP/MIME. Inline PGP will cause trouble from time to time. Richard From neal at walfield.org Sun Jul 17 19:32:28 2016 From: neal at walfield.org (Neal H. Walfield) Date: Sun, 17 Jul 2016 19:32:28 +0200 Subject: GPG and Mailinglists using IBCPRE In-Reply-To: References: <4913701.NByz4kV0ia@sony-01.tue.hq.erfrakon.de> <87vb04l7va.wl-neal@walfield.org> Message-ID: <87twfokw5v.wl-neal@walfield.org> On Sun, 17 Jul 2016 15:53:47 +0200, Richard H?chenberger wrote: > we've been using Schleuder2 for many years now, and it has always > worked flawlessly on a medium-traffic mailing list as long as everyone > used OpenPGP/MIME. Inline PGP will cause trouble from time to time. Scleuder requires that the mail server decrypt the messages. My solution doesn't, which is what I think the OP was looking for. Of course, Schleuder is straightforward to deploy whereas mine is still a prototype. :) Neal From ben at skyportsystems.com Mon Jul 18 00:44:24 2016 From: ben at skyportsystems.com (Ben Warren) Date: Sun, 17 Jul 2016 15:44:24 -0700 Subject: SSH hangs when using GPG2 + Yubikey on OS-X Message-ID: Hello, I?ve found similar issues on the mailing list, but wasn?t able to find a resolution. I?m using a Yubikey 4 hardware token on OS-X ?Yosemite?. I?m connecting to a remote Linux VM and am using GPG agent-forwarding in order to sign git commits using the Yubikey. I also forward SSH through GPG, but find that with one or two SSH sessions open, they hang after a couple of hours. This time frame is sometimes shorter, but rarely longer. In order to recover, I need to kill scdaemon on the Mac using SIGKILL. I?ve tried SIGHUP, but that doesn?t help. I?m able to tolerate this, but colleagues who have more open SSH connections open see it hang much more often to the point where this is unusable. =============== Software versions: ben ~ $ gpg2 --version gpg (GnuPG) 2.1.12 libgcrypt 1.7.0 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 ben ~ $ ssh -V OpenSSH_6.8p1, OpenSSL 1.0.2a 19 Mar 2015 ================ GPG configurations: ben ~/.gnupg $ cat gpg-agent.conf default-cache-ttl 1 ignore-cache-for-signing no-allow-external-cache max-cache-ttl 1 extra-socket /Users/ben/.gnupg/S.gpg-extra-agent debug-all log-file /Users/ben/.gnupg/mygpglogfile.log enable-ssh-support ben ~/.gnupg $ cat scdaemon.conf log-file /Users/ben/.gnupg/scdaemon.log verbose debug-level guru #jdebug-all debug ipc,cardio I have the full scdaemon log file saved, but can?t post it to this mailing list because of size limitations. If there?s anything in it you need, I?ll be happy to provide. ======== Timeline: 2016-07-13 16:20:58 : started SSH connection 2016-07-13 16:30 : I noticed the SSH connection was hung and killed scdaemon Here?s an interesting snippet from the log file: 2016-07-13 16:28:00 scdaemon[32523] DBG: leave: apdu_get_status => sw=0x0 status=7 changecnt=3 2016-07-13 16:28:01 scdaemon[32523] DBG: enter: apdu_get_status: slot=0 hang=0 2016-07-13 16:28:01 scdaemon[32523] DBG: leave: apdu_get_status => sw=0x0 status=7 changecnt=3 2016-07-13 16:28:01 scdaemon[32523] DBG: chan_6 <- RESTART 2016-07-13 16:28:01 scdaemon[32523] Ohhhh jeeee: trying to release an already released context 2016-07-13 16:30:40 scdaemon[32745] listening on socket '/Users/ben/.gnupg/S.scdaemon' 2016-07-13 16:30:40 scdaemon[32745] handler for fd -1 started 2016-07-13 16:30:40 scdaemon[32745] DBG: enter: apdu_open_reader: portstr=(null) ================ thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3583 bytes Desc: not available URL: From foxdeltasigma at gmail.com Mon Jul 18 08:36:01 2016 From: foxdeltasigma at gmail.com (=?UTF-8?B?Rm94zpTOow==?=) Date: Mon, 18 Jul 2016 08:36:01 +0200 Subject: Gnupg-users Digest, Vol 154, Issue 8 In-Reply-To: References: Message-ID: > > Message: 3 > Date: Fri, 15 Jul 2016 16:52:57 -0400 > From: "Robert J. Hansen" > To: gnupg-users at gnupg.org > Subject: Re: Threefish cipher in GnuPG? > Message-ID: > Content-Type: text/plain; charset=windows-1252 > > > Anyway, just out of curiosity, are there plans on including Threefish in > > GnuPG? Or reasons why it hasn't been nor will be? > > RFC4880 has identifiers for the following symmetric ciphers: > Unencrypted, IDEA, 3DES, CAST5-128, Blowfish-128, AES in three key > sizes, and Twofish-256. Supplemental RFCs (5581) have added identifiers > for Camellia in three key sizes. > > If you can get the IETF to release an RFC for Threefish in OpenPGP, it's > very likely GnuPG will include Threefish support. But without that, > it's very unlikely. > That was a straight and simple answer. Thanks! From davidmatthewslb at gmail.com Mon Jul 18 09:10:55 2016 From: davidmatthewslb at gmail.com (David Matthews) Date: Mon, 18 Jul 2016 08:10:55 +0100 Subject: gpg-preset-passphrase not working with 2.1 In-Reply-To: References: <87shvdohwx.fsf@alice.fifthhorseman.net> Message-ID: On 14 July 2016 at 07:29, David Matthews wrote: > On 13 July 2016 at 13:13, Daniel Kahn Gillmor wrote: >> Hi David-- >> >> On Tue 2016-07-12 16:46:53 +0200, David Matthews wrote: >>> I can't get gpg-preset-passphrase to work with GnuPG 2.1.7. >> >> there have been significant changes to GnuPG between 2.1.7 and 2.1.13. >> >> can you try upgrading to 2.1.13? > > I've compiled 2.1.13 on Fedora 23 and get the same result (test output below). > > According to issue 2015 this was caused by a change that went into > release 2.1.5. Could someone with the necessary permissions please add a comment to https://bugs.gnupg.org/gnupg/issue2015 to indicate that this bug still exists at 2.1.13 and also update the title? I only have permission to create a new bug and I don't want to create a duplicate. Thanks, David From justus at g10code.com Mon Jul 18 11:32:02 2016 From: justus at g10code.com (Justus Winter) Date: Mon, 18 Jul 2016 11:32:02 +0200 Subject: gpg-preset-passphrase not working with 2.1 In-Reply-To: References: Message-ID: <87r3arcmwd.fsf@europa.jade-hamburg.de> Hello :) David Matthews writes: > I can't get gpg-preset-passphrase to work with GnuPG 2.1.7. The > command appears to work successfully but the passphase is not found by > GET_PASSPHRASE. I've included details of my simple test below plus the > output from running it on Centos 7.2 (where it works using 2.0.22) and > Fedora 23 (where it fails using 2.1.7). Thanks for the report. > Searching through the issue tracker I found > https://bugs.gnupg.org/gnupg/issue2015. The title of this issue is > "GET_PASSPHRASE with --no-ask always return error in gnupg 2.1.5" but, > based on the discussion in the issue, I think the title should really be > "gpg-preset-passphrase does not work". Have I understood that > correctly? I haven't looked deeply into the issue, but gpg-preset-passphrase does work, we use it in our test suite. Feel free to add relevant information, but please don't retitle the bug. I have approved your bug tracker account. > If so I assume I will see the same issue with the latest release? Yes. The issue is not closed, so it should be still present. Cheers, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From justus at g10code.com Mon Jul 18 11:13:38 2016 From: justus at g10code.com (Justus Winter) Date: Mon, 18 Jul 2016 11:13:38 +0200 Subject: gpgscm In-Reply-To: <87fur8v098.fsf@we.make.ritual.n0.is> References: <87fur8v098.fsf@we.make.ritual.n0.is> Message-ID: <87twfncnr1.fsf@europa.jade-hamburg.de> Hello :) ng0 writes: > While doing the update of gnupg from 2.1.13 to 2.1.14 I found out > that you now include a modified version of tinyscheme for running > your tests/opengpg/ tests. > > Are the changes you apply to tinyscheme generic enough to > contribute to upstream, so that we can just include a modified > tinyscheme software to run tests/opengpg/ tests during the check > phase of GnuPG? Yes they are, and I tried to push my changes upstream well before we merged the new test suite into our master branch. Sadly, my efforts were not successful. You can find the details in TinySCHEMEs mailing list archive. > If they aren't, could you move the gpgscm binary outside of the > source of gnupg to not include bundled dependencies, or in some > more convinient way for you? I consider bundling of gpgscm no worse than bundling scdaemon, or say gpgtar. The plan is to let it mature within the GnuPG repository, and once we are confident that it fits all our needs, we will move it to libgpg-error, and use it for other test suites too. > As there seems to be no general developer list for GnuPG I'll use > this list, we can move the discussion elsewhere if it does not > fit in here. There is gnupg-devel, see https://www.gnupg.org/documentation/mailing-lists.html. Cheers, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From dom at mielko.com Mon Jul 18 21:40:00 2016 From: dom at mielko.com (dom at mielko.com) Date: Mon, 18 Jul 2016 13:40:00 -0600 Subject: How to encrypt and sign with different keys Message-ID: I am struggling with GPG command line that will encrypt file with key A and sign it with key B. Any help would be appreciated. Also, is there a way to provide the password for the signing key in the command line? I am trying to automate encrypting files. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From dashohoxha at gmail.com Mon Jul 18 22:49:17 2016 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Mon, 18 Jul 2016 22:49:17 +0200 Subject: How to encrypt and sign with different keys In-Reply-To: References: Message-ID: On Mon, Jul 18, 2016 at 9:40 PM, dom at mielko.com wrote: > I am struggling with GPG command line that will encrypt file with key A > and sign it with key B. > Usually it does it automatically, if you have subkeys for signing and encryption. > Also, is there a way to provide the password for the signing key in the > command line? > Try appending this to the command: `--passphrase-fd=0 <<< thepassphrase` > I am trying to automate encrypting files. > Consider also using and customizing `egpg`: - http://dashohoxha.github.io/egpg/gnupg-2.0/man/#CUSTOMIZATION - https://github.com/dashohoxha/egpg/wiki/gnupg-2.0-Customization -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Mon Jul 18 23:02:32 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 18 Jul 2016 17:02:32 -0400 Subject: How to encrypt and sign with different keys In-Reply-To: References: Message-ID: > I am struggling with GPG command line that will encrypt file with key A > and sign it with key B. Any help would be appreciated. Also, is there a ID-A is the certificate ID for A, ID-B is the certificate ID for B. gpg --recipient ID-A --local-user B --encrypt --sign filename.txt > way to provide the password for the signing key in the command line? Please don't. Doing things this way sort of destroys the purpose of a passphrase. Remove the passphrase from the certificate instead. From daniele at grinta.net Mon Jul 18 23:03:52 2016 From: daniele at grinta.net (Daniele Nicolodi) Date: Mon, 18 Jul 2016 15:03:52 -0600 Subject: How to encrypt and sign with different keys In-Reply-To: References: Message-ID: On 7/18/16 2:49 PM, Dashamir Hoxha wrote: > On Mon, Jul 18, 2016 at 9:40 PM, dom at mielko.com > > wrote: > > I am struggling with GPG command line that will encrypt file with > key A and sign it with key B. You can select the key for signing with the --local-user option and the key for encrypting with the recipient option. > Also, is there a way to provide the password for the signing key in > the command line? > > > Try appending this to the command: `--passphrase-fd=0 <<< thepassphrase` That's most definitely the wrong syntax. > I am trying to automate encrypting files. If you want to automate signing consider exporting a signing subkey without a passphrase. The passphrase would have to be stored along with the key anyhow. > Consider also using and customizing `egpg`: > - http://dashohoxha.github.io/egpg/gnupg-2.0/man/#CUSTOMIZATION > - https://github.com/dashohoxha/egpg/wiki/gnupg-2.0-Customization Or better not. Cheers, Daniele From rjh at sixdemonbag.org Tue Jul 19 01:08:42 2016 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 18 Jul 2016 19:08:42 -0400 Subject: How to encrypt and sign with different keys In-Reply-To: References: Message-ID: > gpg --recipient ID-A --local-user B --encrypt --sign filename.txt Grr. Typoed it. gpg --recipient ID-A --local-user ID-B --encrypt --sign filename.txt From gniibe at fsij.org Tue Jul 19 04:18:44 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 19 Jul 2016 11:18:44 +0900 Subject: SSH hangs when using GPG2 + Yubikey on OS-X In-Reply-To: References: Message-ID: <3ba4e8c5-16dc-217f-b801-fac619360b6f@fsij.org> On 07/18/2016 07:44 AM, Ben Warren wrote: > I?m using a Yubikey 4 hardware token on OS-X ?Yosemite?. I?m connecting > to a remote Linux VM and am using GPG agent-forwarding in order to sign > git commits using the Yubikey. I also forward SSH through GPG, but find > that with one or two SSH sessions open, they hang after a couple of > hours. This time frame is sometimes shorter, but rarely longer. In > order to recover, I need to kill scdaemon on the Mac using SIGKILL. > I?ve tried SIGHUP, but that doesn?t help. > > I?m able to tolerate this, but colleagues who have more open SSH > connections open see it hang much more often to the point where this is > unusable. I'm not sure the symptom; which is the result and which is the cause? I mean, scdaemon hangs because of SSH hung sessions? Well, SIGHUP doesn't work for scdaemon. scdaemon can be killed by: $ gpgconf --reload scdaemon > gpg (GnuPG) 2.1.12 > libgcrypt 1.7.0 OK. > ======== > Timeline: > 2016-07-13 16:20:58 : started SSH connection > 2016-07-13 16:30 : I noticed the SSH connection was hung and killed > scdaemon > > Here?s an interesting snippet from the log file: > > 2016-07-13 16:28:00 scdaemon[32523] DBG: leave: apdu_get_status => > sw=0x0 status=7 changecnt=3 > 2016-07-13 16:28:01 scdaemon[32523] DBG: enter: apdu_get_status: slot=0 > hang=0 > 2016-07-13 16:28:01 scdaemon[32523] DBG: leave: apdu_get_status => > sw=0x0 status=7 changecnt=3 > 2016-07-13 16:28:01 scdaemon[32523] DBG: chan_6 <- RESTART > 2016-07-13 16:28:01 scdaemon[32523] Ohhhh jeeee: trying to release an > already released context This is a bug of scdaemon. I just fixed this. This is due to the race conditions where release_application could be called multiple times. commit: 0c1fd4e9884ed7c1edd1819762b9e8a77f606ed3 But, I think that this "Ohhh jeeee" results the process of scdaemon (PID=32523) aborted. Do you mean, you needed to kill the another scdaemon of PID=32745 in this case or the one of PID=32523? -- From ben at skyportsystems.com Tue Jul 19 07:22:12 2016 From: ben at skyportsystems.com (Ben Warren) Date: Mon, 18 Jul 2016 22:22:12 -0700 Subject: SSH hangs when using GPG2 + Yubikey on OS-X In-Reply-To: <3ba4e8c5-16dc-217f-b801-fac619360b6f@fsij.org> References: <3ba4e8c5-16dc-217f-b801-fac619360b6f@fsij.org> Message-ID: <2055D831-4693-4E5D-9A09-7634185B6300@skyportsystems.com> Hi, > On Jul 18, 2016, at 7:18 PM, NIIBE Yutaka wrote: > > On 07/18/2016 07:44 AM, Ben Warren wrote: >> I?m using a Yubikey 4 hardware token on OS-X ?Yosemite?. I?m connecting >> to a remote Linux VM and am using GPG agent-forwarding in order to sign >> git commits using the Yubikey. I also forward SSH through GPG, but find >> that with one or two SSH sessions open, they hang after a couple of >> hours. This time frame is sometimes shorter, but rarely longer. In >> order to recover, I need to kill scdaemon on the Mac using SIGKILL. >> I?ve tried SIGHUP, but that doesn?t help. >> >> I?m able to tolerate this, but colleagues who have more open SSH >> connections open see it hang much more often to the point where this is >> unusable. > > I'm not sure the symptom; which is the result and which is the cause? > I mean, scdaemon hangs because of SSH hung sessions? > We don?t see this issue when using a file-based key for SSH, although in that case we?re using ssh-agent, not gpg-agent. I?ll try using a file-based GPG key, which will be closer to the failing configuration. > Well, SIGHUP doesn't work for scdaemon. scdaemon can be killed by: > > $ gpgconf --reload scdaemon > Thanks for the tip! >> gpg (GnuPG) 2.1.12 >> libgcrypt 1.7.0 > > OK. > >> ======== >> Timeline: >> 2016-07-13 16:20:58 : started SSH connection >> 2016-07-13 16:30 : I noticed the SSH connection was hung and killed >> scdaemon >> >> Here?s an interesting snippet from the log file: >> >> 2016-07-13 16:28:00 scdaemon[32523] DBG: leave: apdu_get_status => >> sw=0x0 status=7 changecnt=3 >> 2016-07-13 16:28:01 scdaemon[32523] DBG: enter: apdu_get_status: slot=0 >> hang=0 >> 2016-07-13 16:28:01 scdaemon[32523] DBG: leave: apdu_get_status => >> sw=0x0 status=7 changecnt=3 >> 2016-07-13 16:28:01 scdaemon[32523] DBG: chan_6 <- RESTART >> 2016-07-13 16:28:01 scdaemon[32523] Ohhhh jeeee: trying to release an >> already released context > > This is a bug of scdaemon. I just fixed this. This is due to the > race conditions where release_application could be called multiple > times. > > commit: 0c1fd4e9884ed7c1edd1819762b9e8a77f606ed3 > Thanks, I?ll try this out, but will have to figure out how to build for OS-X (I?ve been using binaries from Patrick Brunschwig) > But, I think that this "Ohhh jeeee" results the process of scdaemon > (PID=32523) aborted. Do you mean, you needed to kill the another > scdaemon of PID=32745 in this case or the one of PID=32523? > -- That?s a good question. I?ve been using ?killall? so haven?t been tracking PIDs. regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3583 bytes Desc: not available URL: From yuriping at sohu.com Tue Jul 19 09:03:17 2016 From: yuriping at sohu.com (yuriping at sohu.com) Date: Tue, 19 Jul 2016 15:03:17 +0800 Subject: GPGME signing failed: Bad passphrase In-Reply-To: <1468727942.0248a1d3a6214127a4c3e46827056b4e.yuriping@sohu.com> Message-ID: <1468911797.7c6c9b5b10fd4af0bf980fe554b640fb.yuriping@sohu.com> Hi, all,    We're using GPGME now.I encountered one problem When running ./gpgme-1.6.0/tests/run-sign demo, as following:root at YRP-ES-QD:/opt/TestCell# ./run-sign --key 5FEC9A32 filerun-sign: signing failed: Bad passphrase    Does this mean I should use gpg-agent, or I should assign the passphrase somewhere?    By the way, if there is no "gpg" in my system, does the program invoking GPGME work properly?    Thanks for any reply!    Best Regards! ------------------------------------------ ???????????????????~ -------------- next part -------------- An HTML attachment was scrubbed... URL: From justus at g10code.com Tue Jul 19 10:24:31 2016 From: justus at g10code.com (Justus Winter) Date: Tue, 19 Jul 2016 10:24:31 +0200 Subject: GPGME signing failed: Bad passphrase In-Reply-To: <1468911797.7c6c9b5b10fd4af0bf980fe554b640fb.yuriping@sohu.com> References: <1468911797.7c6c9b5b10fd4af0bf980fe554b640fb.yuriping@sohu.com> Message-ID: <87twfmqbls.fsf@europa.jade-hamburg.de> Hello :) First of all, your mails are really hard to read because your mua is inserting   into the plain/text part, and there are no newlines. This is how it looks to me: yuriping at sohu.com writes: > Hi, all,    We're using GPGME now.I encountered one problem When running ./gpgme-1.6.0/tests/run-sign demo, as following:root at YRP-ES-QD:/opt/TestCell# ./run-sign --key 5FEC9A32 filerun-sign: signing failed: Bad passphrase    Does this mean I should use gpg-agent, or I should assign the passphrase somewhere?    By the way, if there is no "gpg" in my system, does the program invoking GPGME work properly?    Thanks for any reply!    Best Regards! If your key requires a passphrase to be used, then you need to supply it somehow. In an interactive setting you may use a pinentry program. In fact, that should be the default, and if no pinentry pops up asking you for the passphrase, it might be that none is installed on your system. Have you tried gpg --sign --local-user 5FEC9A32 file ? You mention that gpg is not installed. Is gpg2 available? In an non-interactive setting, you need to supply the passphrase. This can be done using an passphrase callback. See e.g. tests/gpg/t-sign.c, and https://www.gnupg.org/documentation/manuals/gpgme/Passphrase-Callback.html#Passphrase-Callback Hope that helps :) Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From gniibe at fsij.org Tue Jul 19 10:54:55 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 19 Jul 2016 17:54:55 +0900 Subject: SSH hangs when using GPG2 + Yubikey on OS-X In-Reply-To: <2055D831-4693-4E5D-9A09-7634185B6300@skyportsystems.com> References: <3ba4e8c5-16dc-217f-b801-fac619360b6f@fsij.org> <2055D831-4693-4E5D-9A09-7634185B6300@skyportsystems.com> Message-ID: <83250957-75e0-dd26-b673-0c53f9622aea@fsij.org> On 07/19/2016 02:22 PM, Ben Warren wrote: > We don?t see this issue when using a file-based key for SSH, > although in that case we?re using ssh-agent, not gpg-agent. I?ll > try using a file-based GPG key, which will be closer to the failing > configuration. Are you using some other tools for Yubikey? People sometimes do or write a script with gpg-connect-agent "SCD RESET" /bye (to reset PIN auth state) but this only works well if we have a single connection from gpg-agent to scdaemon. Having ssh-sessions (with forwarding), we have multiple connections from gpg-agent to scdaemon. This could be a cause of troubles. -- From zhaolinghui at cn.panasonic.com Tue Jul 19 05:45:13 2016 From: zhaolinghui at cn.panasonic.com (zhaolinghui) Date: Tue, 19 Jul 2016 11:45:13 +0800 Subject: install problem Message-ID: <005201d1e16f$f80b88e0$e8229aa0$@cn.panasonic.com> Sorry to disturb you I am Zhaolh of Panasonic in china, now I have a problem about installing of gnupg-2.1.14 When I finished installing this software according to the README, and run gpgconf -list-dirs the log as below is appeared "gpgconf: error while loading shared libraries: libgcrypt.so.20: cannot open shared object file: No such file or directory." How can I do to solve this problem? Thank you very much! Sincerely -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas at glanzmann.de Tue Jul 19 12:26:10 2016 From: thomas at glanzmann.de (Thomas Glanzmann) Date: Tue, 19 Jul 2016 12:26:10 +0200 Subject: Yubikey 4 gpg 2.1.14 forget passphrase for RSA key Message-ID: <20160719102610.GA11283@glanzmann.de> Hello, I have a yubikey 4 where I store a 4K RSA for authentication, ecryption and signature on. I'm using it for ssh and gpg agent forwarding to a remote machine. So far I'm unable to tell gpg-agent to forget the passphrase. The only thing that works is replug the yubikey. When I goggeled for the same, the following hints came up: killall -s HUP gpg-agent echo RELOADAGENT | gpg-connect-agent Both have no effect for me, any hints? Cheers, Thomas From justus at g10code.com Tue Jul 19 13:42:08 2016 From: justus at g10code.com (Justus Winter) Date: Tue, 19 Jul 2016 13:42:08 +0200 Subject: GPGME signing failed: Bad passphrase In-Reply-To: <1468918222.a6fa4203a1344b76a803a58f6057e4d1.yuriping@sohu.com> References: <1468918222.a6fa4203a1344b76a803a58f6057e4d1.yuriping@sohu.com> Message-ID: <87inw1rh0v.fsf@europa.jade-hamburg.de> Hello, please don't drop the mailinglist from your replies. It may be that your questions may be relevant to others as well. And by only replying to me you prevent others from answering it, in turn forcing me to reply. yuriping at sohu.com writes: > Hi, SirThanks for your timely reply!I'm really sorry for my e-mail > style, but I really don't know how it looks like that.I have installed > gpg on my Ubuntu, and I want to invoke GPGME in my C-program. What I > want to know is if gpg is necessary when I invoke GPGME in a > C-program, or my program can run independently with "gpg".Expect your > futher support!Best Regards! Yes, gpg is required. Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From justus at g10code.com Tue Jul 19 13:54:59 2016 From: justus at g10code.com (Justus Winter) Date: Tue, 19 Jul 2016 13:54:59 +0200 Subject: GPGME signing failed: Bad passphrase In-Reply-To: <1468920720.7925a5292cdd46bcb070cb6a364ee04d.yuriping@sohu.com> References: <1468920720.7925a5292cdd46bcb070cb6a364ee04d.yuriping@sohu.com> Message-ID: <87fur5rgfg.fsf@europa.jade-hamburg.de> yuriping at sohu.com writes: > Hi, SirI have test "tests/gpg/t-sign.c" and done some necessary > modification as following:0. file "t-support.h", function > "passphrase_cb"    char *pass = "057128"; // altered > with the passphrase of my key1. file "t-sign.c", function "main"#if 1 > // be 0 originally, now enable this section  {    > gpgme_key_t akey;//    err = gpgme_get_key (ctx, > "0x68697734", &akey, 0);    err = gpgme_get_key > (ctx, "0x5FEC9A32", &akey, 1);    // ID of my key > 0x5FEC9A32    fail_if_err (err);    err > = gpgme_signers_add (ctx, akey);    fail_if_err > (err);    gpgme_key_unref (akey);  }#endifRun > ./t-sign, the program stoped at   /* First a normal > signature.  */  err = gpgme_data_new (&out);  > fail_if_err (err);  err = gpgme_op_sign (ctx, in, out, > GPGME_SIG_MODE_NORMAL);// stop infinitely here  fail_if_err > (err);  result = gpgme_op_sign_result (ctx);  check_result > (result, GPGME_SIG_MODE_NORMAL);  print_data (out);  > gpgme_data_release (out);I don't know how to solve this issue.I just > want to invoke GPGME, to sign a file with passphrase delivery > automatically...Thank a lot for any reply! You may or may not need to configure gpgme to use the loopback pinentry mode, and may or may not (depending on your specific version of gnupg) allow the loopback pinentry mode in the first place. See https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=commitdiff;h=329ab93f7ed862d7f4c0501fca5355936a74ac52 Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From guanx.bac at gmail.com Tue Jul 19 12:59:44 2016 From: guanx.bac at gmail.com (Guan Xin) Date: Tue, 19 Jul 2016 12:59:44 +0200 Subject: install problem In-Reply-To: <005201d1e16f$f80b88e0$e8229aa0$@cn.panasonic.com> References: <005201d1e16f$f80b88e0$e8229aa0$@cn.panasonic.com> Message-ID: On Tue, Jul 19, 2016 at 5:45 AM, zhaolinghui wrote: > ... > > > > the log as below is appeared > > ?gpgconf: error while loading shared libraries: libgcrypt.so.20: cannot > open shared object file: No such file or directory.? > > > Have you run ldconfig after installation? Guan -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at digitalbrains.com Tue Jul 19 14:12:34 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 19 Jul 2016 14:12:34 +0200 Subject: Yubikey 4 gpg 2.1.14 forget passphrase for RSA key In-Reply-To: <20160719102610.GA11283@glanzmann.de> References: <20160719102610.GA11283@glanzmann.de> Message-ID: <0ccd33b0-dc9a-0ce0-9b39-7bf6383b2027@digitalbrains.com> On 19/07/16 12:26, Thomas Glanzmann wrote: > So far I'm unable to tell gpg-agent to forget the > passphrase. I think you're looking for this command: gpg-connect-agent 'SCD RESET' /bye HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From dom at mielko.com Tue Jul 19 14:16:49 2016 From: dom at mielko.com (dom at mielko.com) Date: Tue, 19 Jul 2016 06:16:49 -0600 Subject: How to encrypt and sign with different keys In-Reply-To: References: Message-ID: <5ad912c8016448279b8cf3329cfefe6e@mielko.com> Thank you to all who replied. The command line listed below works like a charm. I guess, I just have to remove the password from the signing key. One more question, is there a way to force GPG to produce output with PGP extension? ---------------------------------------- From: "Robert J. Hansen" Sent: Monday, July 18, 2016 7:09 PM To: gnupg-users at gnupg.org Subject: Re: How to encrypt and sign with different keys > gpg --recipient ID-A --local-user B --encrypt --sign filename.txt Grr. Typoed it. gpg --recipient ID-A --local-user ID-B --encrypt --sign filename.txt _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From dashohoxha at gmail.com Tue Jul 19 14:50:05 2016 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Tue, 19 Jul 2016 14:50:05 +0200 Subject: How to encrypt and sign with different keys In-Reply-To: <5ad912c8016448279b8cf3329cfefe6e@mielko.com> References: <5ad912c8016448279b8cf3329cfefe6e@mielko.com> Message-ID: On Tue, Jul 19, 2016 at 2:16 PM, dom at mielko.com wrote: > > is there a way to force GPG to produce output with PGP extension? > Try the option: `--output filename.pgp` -------------- next part -------------- An HTML attachment was scrubbed... URL: From reinhard.irmer at kabelmail.de Tue Jul 19 17:58:33 2016 From: reinhard.irmer at kabelmail.de (Reinhard Irmer) Date: Tue, 19 Jul 2016 17:58:33 +0200 Subject: =?utf-8?Q?Online-Entschl=C3=BCsselung?= Message-ID: <000101d1e1d6$677de590$3679b0b0$@irmer@kabelmail.de> Hi, gibt es eine M?glichkeit gnupg-verschl?sselte Texte online zu entschl?sseln um sie lesbar zu machen? Keys sind bekannt. -- Viele Gr??e Reinhard Irmer --- on Outlook 2007 (Win10-prof.) --- From youcanlinux at gmail.com Tue Jul 19 20:25:58 2016 From: youcanlinux at gmail.com (Daniel Villarreal) Date: Tue, 19 Jul 2016 14:25:58 -0400 Subject: =?UTF-8?Q?Re:_Online-Entschl=c3=bcsselung?= In-Reply-To: <578e607d.81d61c0a.7b8be.0ab3SMTPIN_ADDED_BROKEN@mx.google.com> References: <578e607d.81d61c0a.7b8be.0ab3SMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: <745ef689-52c2-58f9-be58-85f313489309@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 19/07/16 11:58 AM, Reinhard Irmer wrote: > Hi, gibt es eine M?glichkeit gnupg-verschl?sselte Texte online zu > entschl?sseln um sie lesbar zu machen? Keys sind bekannt. > > Viele Gr??e Reinhard Irmer --- on Outlook 2007 (Win10-prof.) --- ich w?rde das nicht tun, aber vielleicht https://www.webpg.org/ ? - -- Daniel Villarreal http://www.youcanlinux.org youcanlinux at gmail.com PGP key 2F6E 0DC3 85E2 5EC0 DA03 3F5B F251 8938 A83E 7B49 https://pgp.mit.edu/pks/lookup?op=get&search=0xF2518938A83E7B49 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXjnCyAAoJEPJRiTioPntJivQH/0F1EXR3lmu1aiIt3e1I7UVg xWa9GjAAFpNOWI9R5ydMzxgBwxGREDPFub+KS4WoqknJ1vVjFkldNlzO63FbDqMX hH1PrlqWQ7vap31Xo4iGL7ftSpetv5KmK9P/R59W8oAJYdw+xnuBpSbY7ApiVC0Q mYtjc+2OMTvZpsqPeKn5jbPukWurvdFechYVv1jZQj8yKuWJscaArcgPGX1kD2J/ XoCEJg9YWBUGwq1J/EbLIJ5KWfcFq8Fz0LWcsRCeKPE1H9mh1F0QzDMTDauhrgg1 u9Iv8Df4yBJOjcJ4ZA4qMRZhTlRS1p9jzWAys288bfYLSCp4hM8S+pxN5AM/vTo= =dS3h -----END PGP SIGNATURE----- From kloecker at kde.org Tue Jul 19 22:35:08 2016 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Tue, 19 Jul 2016 22:35:08 +0200 Subject: =?UTF-8?B?T25saW5lLUVudHNjaGzDvHNzZWx1bmc=?= Message-ID: <2204904.VIbIHup0Hv@thufir> This is the English GnuPG user mailing list. The German GnuPG mailing list is https://lists.gnupg.org/mailman/listinfo/gnupg-de On Tuesday 19 July 2016 17:58:33 Reinhard Irmer wrote: > Hi, > gibt es eine M?glichkeit gnupg-verschl?sselte Texte online zu > entschl?sseln um sie lesbar zu machen? Keys sind bekannt. Your question is very unspecific. Also you didn't tell us why you are looking for a possibility to decrypt GnuPG-encrypted texts online. Yes, you say that you want to make the texts readable, but why do you want to do the decryption online? There are ways to decrypt GnuPG-encrypted emails online, e.g. the browser extension Mailvelope [1], that's available for Chrome and Firefox. If you want to decrypt encrypted text instead of encrypted emails then one possible solution would be putting the text (ASCII armored) into an email and then use Mailvelope. Maybe Mailvelope even supports decrypting text without putting it first in an email. Alternatively, if you know how to write JavaScript then you could use OpenPGP.js [2] (which Mailvelope is based on) directly. Regards, Ingo [1] https://www.mailvelope.com/ [2] https://openpgpjs.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From gniibe at fsij.org Wed Jul 20 04:57:06 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 20 Jul 2016 11:57:06 +0900 Subject: SSH hangs when using GPG2 + Yubikey on OS-X In-Reply-To: <83250957-75e0-dd26-b673-0c53f9622aea@fsij.org> References: <3ba4e8c5-16dc-217f-b801-fac619360b6f@fsij.org> <2055D831-4693-4E5D-9A09-7634185B6300@skyportsystems.com> <83250957-75e0-dd26-b673-0c53f9622aea@fsij.org> Message-ID: On 07/19/2016 05:54 PM, NIIBE Yutaka wrote: > On 07/19/2016 02:22 PM, Ben Warren wrote: >> We don?t see this issue when using a file-based key for SSH, >> although in that case we?re using ssh-agent, not gpg-agent. I?ll >> try using a file-based GPG key, which will be closer to the failing >> configuration. > > Are you using some other tools for Yubikey? > > People sometimes do or write a script with > > gpg-connect-agent "SCD RESET" /bye > > (to reset PIN auth state) but this only works well if we have a single > connection from gpg-agent to scdaemon. Having ssh-sessions (with > forwarding), we have multiple connections from gpg-agent to scdaemon. > This could be a cause of troubles. I think that the problem occurs when we do "SCD RESET" above or removal/insertion of token during the use of SSH. It seems for me that OpenSSH client (7.2p2, in my case) keeps the connection to ssh-agent even if it doesn't use forwarding. So, it is likely that we encounter this problem. Today, I fixed this issue by: commit 1598a4476466822e7e9c757ac471089d3db4b545 Please try it out. -- From thomas at glanzmann.de Wed Jul 20 07:04:20 2016 From: thomas at glanzmann.de (Thomas Glanzmann) Date: Wed, 20 Jul 2016 07:04:20 +0200 Subject: Yubikey 4 gpg 2.1.14 forget passphrase for RSA key In-Reply-To: <0ccd33b0-dc9a-0ce0-9b39-7bf6383b2027@digitalbrains.com> References: <20160719102610.GA11283@glanzmann.de> <0ccd33b0-dc9a-0ce0-9b39-7bf6383b2027@digitalbrains.com> Message-ID: <20160720050420.GA12598@glanzmann.de> Hello Peter, > On 19/07/16 12:26, Thomas Glanzmann wrote: > > So far I'm unable to tell gpg-agent to forget the > > passphrase for a yubikey. * Peter Lebbing [2016-07-19 14:12]: > gpg-connect-agent 'SCD RESET' /bye thank you. That works for me. Cheers, Thomas From yuriping at sohu.com Wed Jul 20 07:25:59 2016 From: yuriping at sohu.com (yuriping at sohu.com) Date: Wed, 20 Jul 2016 13:25:59 +0800 Subject: GPGME-if gpg is necessary Message-ID: <1468992359.14b61532c6e74734a69f30a058bbe9c3.yuriping@sohu.com> Hi, SirI'm using GPGME now to perform singnature and verifying.I have installed gpg on my Ubuntu, and I want to invoke GPGME in my C-program. What I want to know is if gpg is necessary when I invoke GPGME in a C-program, or my program can run independently with "gpg".Best Regards! ------------------------------------------ ???????????????????~ -------------- next part -------------- An HTML attachment was scrubbed... URL: From antony at blazrsoft.com Wed Jul 20 07:38:25 2016 From: antony at blazrsoft.com (Antony Prince) Date: Wed, 20 Jul 2016 01:38:25 -0400 Subject: GPGME-if gpg is necessary In-Reply-To: <1468992359.14b61532c6e74734a69f30a058bbe9c3.yuriping@sohu.com> References: <1468992359.14b61532c6e74734a69f30a058bbe9c3.yuriping@sohu.com> Message-ID: <3614ee90-3bec-3621-fb2c-9cb069d9c72e@blazrsoft.com> On 7/20/2016 1:25 AM, yuriping at sohu.com wrote: > Hi, Sir > > What I want to know is if gpg is necessary when I invoke > GPGME in a C-program, or my program can run independently with "gpg". > As far as I understand it, yes. If you use GPGME, gpg is also necessary since GPGME is an interface to access the functions of gpg. You can do this directly with your program and gpg without GPGME, but it would likely be fairly cumbersome which is why GPGME came about. That's merely my understanding of it and I could be wrong. -- Antony Prince Key ID: 0xAF3D4087301B1B19 Fingerprint: 591F F17F 7A4A A8D0 F659 C482 AF3D 4087 301B 1B19 URL: http://pool.sks-keyservers.net/pks/lookup?op=get&search=0xAF3D4087301B1B19 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 884 bytes Desc: OpenPGP digital signature URL: From thomas at glanzmann.de Wed Jul 20 10:06:05 2016 From: thomas at glanzmann.de (Thomas Glanzmann) Date: Wed, 20 Jul 2016 10:06:05 +0200 Subject: Yubikey + GNUPG 2.1.14 + GPG Agent Forwarding + Mutt 1.6.0 (gpgme 1.6.0): Not asking for PIN for smartcard on first use of an encryption key Message-ID: <20160720080605.GA18738@glanzmann.de> Hello, I have yubikey 4 plugged into my Laptop, than I use ssh to forward my gpg agent socket to a remote machine, On the remote machine I start mutt and would like to read an encrypted email using the RSA encryption key stored on my yubikey. It works if I use gpg2 to enter the pin by opening an encrypted file using the same encryption key. Mutt does _not_ prompt me to enter the pin for the smartcard. I assume that code is missing in mutt to prompt for the key. Is there any documentation or another possible simple example how to obtain that so that I can write a patch for mutt? My mutt config: set crypt_use_gpgme=yes The mutt error messages are: Could not decrypt PGP message Could not copy message When I prepopulate using the remote machine: PGP message successfully decrypted. I guess it is not that big of a deal, because when I use any other RSA on the card the PIN is already prepopulated unlocking all of my RSA keys on the card, but I would like to know anyway. Also if somemone could point me to a document how the interaction works, that would be nice. Something else I'm wandering about. When I do 'gpg -d test.gpg' on the remote machine, I was not prompted for a PIN when the key was not prepopulated, than I added 'pinentry-mode loopback' and it asked me on the remote machine. But when I do the same thing on my local machine I get a graphical prompt using pinentry. So my question is, if a remote gpg needs my pin, is possible that my local agent prompts me for the pin? If so, how do I configure that? Cheers, Thomas From antony at blazrsoft.com Wed Jul 20 10:37:57 2016 From: antony at blazrsoft.com (Antony Prince) Date: Wed, 20 Jul 2016 04:37:57 -0400 Subject: Yubikey + GNUPG 2.1.14 + GPG Agent Forwarding + Mutt 1.6.0 (gpgme 1.6.0): Not asking for PIN for smartcard on first use of an encryption key In-Reply-To: <20160720080605.GA18738@glanzmann.de> References: <20160720080605.GA18738@glanzmann.de> Message-ID: On 7/20/2016 4:06 AM, Thomas Glanzmann wrote: > Mutt does _not_ prompt me to enter the pin for the smartcard. I assume > that code is missing in mutt to prompt for the key. My assumption would be that the callback for the prompt is issued to the local machine rather than passing back through SSH and Mutt doesn't know what to do with it. I don't have any experience with SSH tunneling though, so I can't say for sure. In that case, it shouldn't work since the key can't obtain its passphrase. ... > Something else I'm wandering about. When I do 'gpg -d test.gpg' on the > remote machine, I was not prompted for a PIN when the key was not > prepopulated, than I added 'pinentry-mode loopback' and it asked me on > the remote machine. But when I do the same thing on my local machine I > get a graphical prompt using pinentry. So my question is, if a remote > gpg needs my pin, is possible that my local agent prompts me for the > pin? If so, how do I configure that? Like the previous case, there has to be a call for the pinentry. Even though it is tunneled through SSH, the call on the remote machine routes to the remote machine so you get a curses pinentry or some such. To get it to perform a call to pinentry on your local machine would require the call to be routed back through the tunnel. Neither response is much help, I know, but just my thoughts on what the issue is. Hopefully, one of the gurus on the list can help you through it. -- Antony Prince Key ID: 0xAF3D4087301B1B19 Fingerprint: 591F F17F 7A4A A8D0 F659 C482 AF3D 4087 301B 1B19 URL: http://pool.sks-keyservers.net/pks/lookup?op=get&search=0xAF3D4087301B1B19 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 884 bytes Desc: OpenPGP digital signature URL: From thomas at glanzmann.de Wed Jul 20 10:58:52 2016 From: thomas at glanzmann.de (Thomas Glanzmann) Date: Wed, 20 Jul 2016 10:58:52 +0200 Subject: gpg-agent forwarding from Windows to a Linux machine Message-ID: <20160720085852.GA22940@glanzmann.de> Hello, I would like to use gpg-agent on Windows with a yubikey and use ssh to forward my gpg agent to a remote machine. Is that already possible, if so how? I assume I can't use putty. So probably I have to use cygwin openssh, but what about the unix socket on windows? Can a named pipe be used? Related: http://stackoverflow.com/questions/9029174/af-unix-equivalent-for-windows SSH Agent Forwarding with putty and gpg4win already works perfectly. Cheers, Thomas From thomas at glanzmann.de Wed Jul 20 11:22:13 2016 From: thomas at glanzmann.de (Thomas Glanzmann) Date: Wed, 20 Jul 2016 11:22:13 +0200 Subject: Yubikey + GNUPG 2.1.14 + GPG Agent Forwarding + Mutt 1.6.0 (gpgme 1.6.0): Not asking for PIN for smartcard on first use of an encryption key In-Reply-To: <20160720080605.GA18738@glanzmann.de> References: <20160720080605.GA18738@glanzmann.de> Message-ID: <20160720092213.GA24939@glanzmann.de> Hello, to answer my own question partly: * Thomas Glanzmann [2016-07-20 10:06]: > Something else I'm wandering about. When I do 'gpg -d test.gpg' on the > remote machine, I was not prompted for a PIN when the key was not > prepopulated, than I added 'pinentry-mode loopback' and it asked me on > the remote machine. But when I do the same thing on my local machine I > get a graphical prompt using pinentry. So my question is, if a remote > gpg needs my pin, is possible that my local agent prompts me for the > pin? If so, how do I configure that? yes, that is possible, by putting on the remote machine the following in ~/.gnupg/gpg.conf: pinentry-mode default However my problem with mutt persists. But now that the above works, I assume it is a oneline in mutt that is missing. Cheers, Thomas From gnupg at soondae.co.uk Tue Jul 19 14:28:21 2016 From: gnupg at soondae.co.uk (keith) Date: Tue, 19 Jul 2016 13:28:21 +0100 Subject: install problem In-Reply-To: References: <005201d1e16f$f80b88e0$e8229aa0$@cn.panasonic.com> Message-ID: <1468931301.2779.66.camel@keith> On Tue, 2016-07-19 at 12:59 +0200, Guan Xin wrote: > On Tue, Jul 19, 2016 at 5:45 AM, zhaolinghui > wrote: > > ... > > > > > the log as below is appeared > > ?gpgconf: error while loading shared libraries: > libgcrypt.so.20: cannot open shared object file: No such file > or directory.? > > > > > > Have you run ldconfig after installation? > > > Guan I will probably be wrong but when Linux moans at me about missing a ??.so.XX it is usually the case that the require file is called ??.so.YY and there is a missing Symbolic Link Symbolic link to shared library and the library itself. I'm sure my computer is not up to date... Keith -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot-Search for "libgcrypt.so".png Type: image/png Size: 78357 bytes Desc: not available URL: From gniibe at fsij.org Thu Jul 21 04:21:49 2016 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 21 Jul 2016 11:21:49 +0900 Subject: Yubikey + GNUPG 2.1.14 + GPG Agent Forwarding + Mutt 1.6.0 (gpgme 1.6.0): Not asking for PIN for smartcard on first use of an encryption key In-Reply-To: <20160720080605.GA18738@glanzmann.de> References: <20160720080605.GA18738@glanzmann.de> Message-ID: <6c85e874-1572-5f2c-3701-6ac34a6dc4e1@fsij.org> On 07/20/2016 05:06 PM, Thomas Glanzmann wrote: > I have yubikey 4 plugged into my Laptop, than I use ssh to forward my > gpg agent socket to a remote machine, On the remote machine I start mutt > and would like to read an encrypted email using the RSA encryption key > stored on my yubikey. It works if I use gpg2 to enter the pin by opening > an encrypted file using the same encryption key. Mutt does _not_ prompt > me to enter the pin for the smartcard. I assume that code is missing in > mutt to prompt for the key. Is there any documentation or another > possible simple example how to obtain that so that I can write a patch > for mutt? > > My mutt config: > > set crypt_use_gpgme=yes > > The mutt error messages are: > Could not decrypt PGP message > Could not copy message > > When I prepopulate using the remote machine: > PGP message successfully decrypted. What do you mean by the term "prepopulate"? Do you invoke "gpg --card-edit" command line, to invoke the subcommand "verify"? In this message, I explain standard pinentry (not loopback mode). It is gpg-agent which invokes pinentry. It is not the client program of gpgme. Here are steps and the interaction. (1) here are the processes [gpgme]----[gpg]====[gpg-agent]----[scdaemon] ^--- possibly by forwarded socket (2) A client program (Mutt, in your case) asks decryption through gpgme decrypt [gpgme]--->[gpg]----[gpg-agent]----[scdaemon] (3) it goes to scdaemon decrypt [gpgme]----[gpg]--->[gpg-agent]----[scdaemon] decrypt [gpgme]----[gpg]----[gpg-agent]--->[scdaemon] (4) if the token is not authenticated yet, scdaemon asks a user PIN back through gpg-agent "PIN please" [gpgme]----[gpg]----[gpg-agent]<---[scdaemon] (5) Then, gpg-agent invokes pinentry. [gpgme]----[gpg]----[gpg-agent]----[scdaemon] | [pinentry]<---/ (6) pinentry pops up GUI dialog window to user. [gpgme]----[gpg]----[gpg-agent]----[scdaemon] | User <----[pinentry]----/ (7) User inputs PIN by the dialog. [gpgme]----[gpg]----[gpg-agent]----[scdaemon] | User ---->[pinentry]----/ PIN [gpgme]----[gpg]----[gpg-agent]----[scdaemon] ^ [pinentry]----/ PIN PIN [gpgme]----[gpg]----[gpg-agent]--->[scdaemon] (8) scdaemon sends the pin to the token to authenticate. PIN [gpgme]----[gpg]----[gpg-agent]----[scdaemon]-->[token] (9) Token is ready to decrypt, now. scdaemon sends encrypted message to the token. decrypt [gpgme]----[gpg]----[gpg-agent]----[scdaemon]-->[token] (10) token replies back by decrypted message.... to gpgme. decrypted [gpgme]----[gpg]----[gpg-agent]----[scdaemon]<--[token] decrypted [gpgme]----[gpg]----[gpg-agent]<---[scdaemon] decrypted [gpgme]----[gpg]<---[gpg-agent]----[scdaemon] decrypted [gpgme]<---[gpg]----[gpg-agent]----[scdaemon] You can configure gpg-agent to emit debug message to file. Here is an example configuration ======================== .gnupg/gpg-agent.conf debug-level guru debug-all log-file /tmp/gpg-agent.log (or /run/user//gpg-agent.log ) ======================== Prepare the file, and type following command line: $ gpg-connect-agent RELOADAGENT /bye Then, try to decrypt. You can figure out the place where thing's going wrong. It sounds for me that gpg-agent fails in the step (5) in the figure above, for some reason. I have an experience pinentry-gnome3 fails soon after it is execed, while pinentry-gtk works well. In some cases, we need to update environment variable of gpg-agent (like DBUS_SESSION_BUS_ADDRESS and DISPLAY) to notify change of terminal/desktop, so that gpg-agent will be able to spawn pinentry on the particular terminal/desktop. The command line to update the envvars is: $ gpg-connect-agent UPDATESTARTUPTTY /bye Well, I fixed a bug of UPDATESTARTUPTTY, and it is in 2.1.14. -- From thomas at glanzmann.de Thu Jul 21 08:00:36 2016 From: thomas at glanzmann.de (Thomas Glanzmann) Date: Thu, 21 Jul 2016 08:00:36 +0200 Subject: Yubikey + GNUPG 2.1.14 + GPG Agent Forwarding + Mutt 1.6.0 (gpgme 1.6.0): Not asking for PIN for smartcard on first use of an encryption key In-Reply-To: <6c85e874-1572-5f2c-3701-6ac34a6dc4e1@fsij.org> References: <20160720080605.GA18738@glanzmann.de> <6c85e874-1572-5f2c-3701-6ac34a6dc4e1@fsij.org> Message-ID: <20160721060036.GA6167@glanzmann.de> Hello Niibe, * NIIBE Yutaka [2016-07-21 04:24]: > What do you mean by the term "prepopulate"? Use they GPG key once on the workstation, so that the private key is unlocked in memory of the GPG agent or at least the PIN/transport key is available. > In this message, I explain standard pinentry (not loopback mode). Thank you for the explanation, it helped me understanding and debug gpg-agent. > ======================== .gnupg/gpg-agent.conf > debug-level guru > debug-all > log-file /tmp/gpg-agent.log > Prepare the file, and type following command line: > $ gpg-connect-agent RELOADAGENT /bye Okay, thanks to that I got to the bottom of it, so now comes the crazy part: I use gpg-agent forwarding, like the following: gpg-agent is running on workstation and uses a graphical pinentry. (workstation) [~] ssh -R /home/sithglan/.gnupg/S.gpg-agent:/home/sithglan/.gnupg/S.gpg-agent remote The remote machine sends the DISPLAY location over gnupg agent forwarding. Than my local machine appears to try to start pinentry with the display location of the remote machine, which of course fails because on the remote machine my DISPLAY=localhost:10, on the local machine it is DISPLAY=:0 and there is no DISPLAY=localhost:10. The pinentry locally fails and I'm never asked for a PIN. To fight the symptoms, I can unset DISPLAY before invoking gpg2 or mutt/gpgme. Btw. now works for everything, 'gpg2 -d' and mutt/gpgme as long as I unset DISPLAY. From my point of view gpg-agent should ignore any DISPLAY settings coming over the unix socket, because it already knows the DISPLAY location. And after reading the gpg-agent documenation there is a 'keep-display' and 'keep-tty' option. This option only works with completely restarting the gpg-agent, 'RELOADAGENT' is not sufficient. But anyway that solves my problem. So thanks a lot to help me to get to the bottom of it and better understand how gpgme, gpg2, and gpg-agent works. TLDR: Remote machine sent local DISPLAY over forwarded gpg agent, local gpg-agent tried to use the remote DISPLAY location locally which failed, as a result pinentry could not ask me for the PIN. To correct the configuration problem, I did: echo 'keep-display' >> ~/.gnupg/gpg-agent.conf echo 'keep-tty' >> ~/.gnupg/gpg-agent.conf And had to restart gpg-agent. RELOADAGENT is insufficient. Afterwards the DISPLAY location from the remote machine is ignored. And the correct local DISPLAY location is used. Cheers, Thomas From peter at digitalbrains.com Thu Jul 21 11:26:03 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 21 Jul 2016 11:26:03 +0200 Subject: Yubikey + GNUPG 2.1.14 + GPG Agent Forwarding + Mutt 1.6.0 (gpgme 1.6.0): Not asking for PIN for smartcard on first use of an encryption key In-Reply-To: <20160721060036.GA6167@glanzmann.de> References: <20160720080605.GA18738@glanzmann.de> <6c85e874-1572-5f2c-3701-6ac34a6dc4e1@fsij.org> <20160721060036.GA6167@glanzmann.de> Message-ID: <64965510-6a58-6a67-a843-b3d68f5edf5b@digitalbrains.com> On 21/07/16 08:00, Thomas Glanzmann wrote: > From my point of view gpg-agent should ignore any DISPLAY > settings coming over the unix socket, because it already knows the > DISPLAY location. GnuPG doesn't expect that you forward the normal gpg-agent socket. For forwarding to a remote machine, there is the gpg-agent.conf option extra-socket [socket file] which creates an extra socket for forwarding. You can then forward this socket the way you do now. One gpg-agent can serve multiple local DISPLAYs. It is exactly intended behaviour that gpg-agent listens to changes of DISPLAY; it tries to adapt to the client inquiring the agent. >From the gpg-agent man page: > --extra-socket name > Also listen on native gpg-agent connections on the given socket. > The intended use for this extra socket is to setup a Unix domain > socket forwarding from a remote machine to this socket on the > local machine. A gpg running on the remote machine may then con? > nect to the local gpg-agent and use its private keys. This > allows to decrypt or sign data on a remote machine without expos? > ing the private keys to the remote machine. I'm a bit surprised you still get a graphical pinentry on your original display when you unset DISPLAY on the remote side. I would expect it to try a textual pinentry on the TTY indicated by the remote side, which probably should fail as well since it is the name of a TTY on the remote side. I'm probably missing a detail somewhere. The keep-{display,tty} sounds like it indeed should work correctly, but it is quite restrictive. HTH, Peter. PS: Wow, what an extensive and detailed answer from NIIBE! Cool :-) -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From thomas at glanzmann.de Thu Jul 21 16:20:17 2016 From: thomas at glanzmann.de (Thomas Glanzmann) Date: Thu, 21 Jul 2016 16:20:17 +0200 Subject: Yubikey + GNUPG 2.1.14 + GPG Agent Forwarding + Mutt 1.6.0 (gpgme 1.6.0): Not asking for PIN for smartcard on first use of an encryption key In-Reply-To: <64965510-6a58-6a67-a843-b3d68f5edf5b@digitalbrains.com> References: <20160720080605.GA18738@glanzmann.de> <6c85e874-1572-5f2c-3701-6ac34a6dc4e1@fsij.org> <20160721060036.GA6167@glanzmann.de> <64965510-6a58-6a67-a843-b3d68f5edf5b@digitalbrains.com> Message-ID: <20160721142017.GA22768@glanzmann.de> Hello Peter, > GnuPG doesn't expect that you forward the normal gpg-agent socket. For > forwarding to a remote machine, there is the gpg-agent.conf option > extra-socket [socket file] I see, I read a lot of tutorials on the web, nobody seems to really understand what they're doing. In one of these tutorials someone mentions that the extra socket is obsolete, so I did not use it. But with your answer, I'll definetly use it from now on. > I'm a bit surprised you still get a graphical pinentry on your original > display when you unset DISPLAY on the remote side. I would expect it to > try a textual pinentry on the TTY indicated by the remote side, which > probably should fail as well since it is the name of a TTY on the remote > side. >From what I learned so far, the behaviour depends on the entry 'pinentry-mode' if you set it to 'default' it asks the remote agent. If you put it to loopback it asks by itseld. If don't have it set at all, it did not work, but this might be also related to my display issue. However thanks to your feedback my setup is now much saner as it used to be. > I'm probably missing a detail somewhere. The keep-{display,tty} sounds > like it indeed should work correctly, but it is quite restrictive. It does, and will keep it but change my usage to use the extra socket. Cheers, Thomas From thomas at glanzmann.de Thu Jul 21 18:25:11 2016 From: thomas at glanzmann.de (Thomas Glanzmann) Date: Thu, 21 Jul 2016 18:25:11 +0200 Subject: Yubikey + GNUPG 2.1.14 + GPG Agent Forwarding + Mutt 1.6.0 (gpgme 1.6.0): Not asking for PIN for smartcard on first use of an encryption key In-Reply-To: <64965510-6a58-6a67-a843-b3d68f5edf5b@digitalbrains.com> References: <20160720080605.GA18738@glanzmann.de> <6c85e874-1572-5f2c-3701-6ac34a6dc4e1@fsij.org> <20160721060036.GA6167@glanzmann.de> <64965510-6a58-6a67-a843-b3d68f5edf5b@digitalbrains.com> Message-ID: <20160721162511.GE22768@glanzmann.de> Hello Peter, * Peter Lebbing [2016-07-21 11:27]: > extra-socket [socket file] quick follow up. With this option it works like a charm without the need for keep-display or keep-tty. Thanks again for bringing this up. Also you made my private key which is on disk probably much more secure. (remote) [~] gpg --export-secret-key -a 0x03BF970657E19B02 > /tmp/testexport.key gpg: error getting the KEK: Forbidden gpg: WARNING: nothing exported Thank you for that. Cheers, Thomas From thomas at glanzmann.de Thu Jul 21 18:31:28 2016 From: thomas at glanzmann.de (Thomas Glanzmann) Date: Thu, 21 Jul 2016 18:31:28 +0200 Subject: Yubikey + GNUPG 2.1.14 + GPG Agent Forwarding + Mutt 1.6.0 (gpgme 1.6.0): Not asking for PIN for smartcard on first use of an encryption key In-Reply-To: <20160721142017.GA22768@glanzmann.de> References: <20160720080605.GA18738@glanzmann.de> <6c85e874-1572-5f2c-3701-6ac34a6dc4e1@fsij.org> <20160721060036.GA6167@glanzmann.de> <64965510-6a58-6a67-a843-b3d68f5edf5b@digitalbrains.com> <20160721142017.GA22768@glanzmann.de> Message-ID: <20160721163128.GF22768@glanzmann.de> Hello Peter, * Thomas Glanzmann [2016-07-21 16:22]: > From what I learned so far, the behaviour depends on the entry > 'pinentry-mode' if you set it to 'default' it asks the remote agent. in order to not spread misinformation myself. 'pinentry-mode default' and no pinentry-mode does the same for me. So for me it did not work before, because I had the DISPLAY issue and the wrong forwading socket. Cheers, Thomas From thomas at glanzmann.de Thu Jul 21 19:07:49 2016 From: thomas at glanzmann.de (Thomas Glanzmann) Date: Thu, 21 Jul 2016 19:07:49 +0200 Subject: gpg4win: gpg agent forwarding from a Windows Workstation with a yubikey to a Linux machine Message-ID: <20160721170749.GA29328@glanzmann.de> Hello, I would like to use gpg-agent on Windows with a yubikey and use ssh to forward my gpg agent to a remote machine. Is that already possible, if so how? I assume I can't use putty. So probably I have to use cygwin openssh, but what about the unix socket on windows? Can a named pipe be used? SSH Agent Forwarding with putty and gpg4win already works perfectly. Under Linux I use the following: (workstation) [~] grep extra .gnupg/gpg-agent.conf extra-socket /home/sithglan/.gnupg/S.gpg-agent-extra (workstation) [~] ssh -R /home/sithglan/.gnupg/S.gpg-agent:/home/sithglan/.gnupg/S.gpg-agent-extra remote Cheers, Thomas From dom at mielko.com Thu Jul 21 20:27:20 2016 From: dom at mielko.com (dom at mielko.com) Date: Thu, 21 Jul 2016 12:27:20 -0600 Subject: How to encrypt and sign with different keys In-Reply-To: References: Message-ID: <2d415aaa09354935a552669075f0867a@mielko.com> Still need your help guys. The syntax listed below works (or I think it does) but how do I verify that the file was encrypted with key ID-A and signed with key ID-B? When I type "gpg filename.pgp" I get the information about encryption key but nothing mentions ID-B signing key. I am asking because recipient of the file claims that the signing key was used to encrypt the file and that he can't decrypt it. Thanks. ---------------------------------------- From: "Robert J. Hansen" Sent: Monday, July 18, 2016 7:09 PM To: gnupg-users at gnupg.org Subject: Re: How to encrypt and sign with different keys > gpg --recipient ID-A --local-user B --encrypt --sign filename.txt Grr. Typoed it. gpg --recipient ID-A --local-user ID-B --encrypt --sign filename.txt _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From kloecker at kde.org Thu Jul 21 22:02:50 2016 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Thu, 21 Jul 2016 22:02:50 +0200 Subject: How to encrypt and sign with different keys In-Reply-To: <2d415aaa09354935a552669075f0867a@mielko.com> References: <2d415aaa09354935a552669075f0867a@mielko.com> Message-ID: <1559482.O2Iet0gYDh@thufir> On Thursday 21 July 2016 12:27:20 dom at mielko.com wrote: > From: "Robert J. Hansen" >> gpg --recipient ID-A --local-user ID-B --encrypt --sign filename.txt > > Still need your help guys. The syntax listed below works (or I think > it does) but how do I verify that the file was encrypted with key > ID-A and signed with key ID-B? When I type "gpg filename.pgp" I get > the information about encryption key but nothing mentions ID-B > signing key. The file is first signed and then encrypted. gpg can only give you information about the signing key if you decrypt the file. > I am asking because recipient of the file claims that > the signing key was used to encrypt the file and that he can't > decrypt it. To prove/disprove this claim all you need to check is the encryption key(s) (which you already did with "gpg filename.pgp"). The output of "gpg filename.pgp" should contain gpg: encrypted with key, ID , created where is ID-A or the ID of an encryption subkey of the key with ID ID-A. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From marcoshalano at gmail.com Sun Jul 24 03:50:23 2016 From: marcoshalano at gmail.com (Marcos Alano) Date: Sun, 24 Jul 2016 01:50:23 +0000 Subject: can't export SSH key under certain conditions Message-ID: Hello everybody, I'm had a problem which I cn fix but all this seems an unexpected behavior. I had this public key (created just for tests): marcos at marcos-laptop:~$ gpg2 --list-keys D27D8884 pub rsa2048/D27D8884 2016-07-23 [CA] uid [ultimate] Marcos (teste do ssh) As you can see this key is present, trusted and have authentication capability. The problem occurs when I tried to export the SSH key: marcos at marcos-laptop:~$ gpg2 --export-ssh-key D27D8884 gpg: key "D27D8884" not found: Unusable public key gpg: export as ssh key failed: Unusable public key After some research I could solve the problem: To export the SSH key correctly I needed a *subkey* with authentication capability enabled. The question is: Shouldn't the main key with authentication capability work well? This is a expected behavior or should I report this as a bug? Best regards. -- Marcos H. Alano Sent from my Android -------------- next part -------------- An HTML attachment was scrubbed... URL: From liukaizheng at huawei.com Mon Jul 25 03:47:00 2016 From: liukaizheng at huawei.com (Liukaizheng (Luke)) Date: Mon, 25 Jul 2016 01:47:00 +0000 Subject: =?utf-8?B?UkU6IOOAkEdudVBHIHVwZ3JhZGXjgJFVcGdyYWRlIHNlc3Npb24gZnJvbSAy?= =?utf-8?Q?.0.9_to_2.0.30?= Message-ID: Hi Team, Please kindly looking on this, how to make upgrade session successfully ? Kind Regards! Luke Mobile: (@China-008618565820624) From: Liukaizheng (Luke) Sent: Thursday, July 21, 2016 4:03 PM To: 'gnupg-users-request at gnupg.org' Subject: ?GnuPG upgrade?Upgrade session from 2.0.9 to 2.0.30 Importance: High Hi Team, I`m service engineer from Huawei, and working on upgrade GnuPG version from 2.0.9 to 2.0.30, but faced the version not changed after executed ?make install?. n What I did: ? Install required lib package found in the README libgpg-error (ftp://ftp.gnupg.org/gcrypt/libgpg-error/) libgpg-error-1.24.tar.gz libgcrypt (ftp://ftp.gnupg.org/gcrypt/libgcrypt/) libgcrypt-1.7.2.tar.gz libksba (ftp://ftp.gnupg.org/gcrypt/libksba/) libksba-1.3.4.tar.bz2 libassuan >= 2.0 (ftp://ftp.gnupg.org/gcrypt/libassuan/) libassuan-2.4.3.tar.bz2 zlib (http://zlib.net/) zlib-1.2.8.tar.gz ? But I found the version or patch didn`t upgrade on these packages. ? Executed ./configure under /home/luke/gnupg-2.0.30 seeing logs as attached gnupg_configure.log ? Executed make and logs as attached gnupg_make.log ? Executed make install and logs as attached make_install.log n Current version There is still 2.0.9 of GnuPG software cpsDSV1:/home/luke/gnupg-2.0.30 # gpg --version gpg (GnuPG) 2.0.9 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Please help checking on this, how can I do next on version upgrade as I didn`t find any upgrade guide from website. Thank you! ________________________________ Liu Kaizheng (Luke) ???????? Huawei Technologies Co., Ltd. [Company_logo] Mobile: (@China- 008618565820624) Email: liukaizheng at huawei.com Mobile Money TMO Group http://3ms.huawei.com/hi/group/2861049 ________________________________ This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 6737 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg_configure.log Type: application/octet-stream Size: 15272 bytes Desc: gnupg_configure.log URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: make_install.log Type: application/octet-stream Size: 11772 bytes Desc: make_install.log URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg_make.log Type: application/octet-stream Size: 92910 bytes Desc: gnupg_make.log URL: From thomas at glanzmann.de Mon Jul 25 12:51:17 2016 From: thomas at glanzmann.de (Thomas Glanzmann) Date: Mon, 25 Jul 2016 12:51:17 +0200 Subject: Upgrade GPG from 2.0.9 to 2.0.30 In-Reply-To: References: Message-ID: <20160725105117.GC11186@glanzmann.de> Hello Luke, > Please kindly looking on this, how to make upgrade session successfully? you configured gnupg with the default installation which is /usr/local. You're previous gpg was probably installed in /usr. In order to use the new gpg version, you either needs to change your path or use the full qualified path. I would not recommend to install gpg over your old path because it might break your system in ways you do not expect it to break. For example the package manager. Example using bash system shell: # As you can see I have two gpg2 versions installed. One from my # distribution, another manually similar to what you did. (infra) [~] type -a gpg2 gpg2 is /local/gnupg/bin/gpg2 gpg2 is /usr/bin/gpg2 # I modified my path so that my own compiled gpg2 version is before the # system path: (infra) [~] echo $PATH /local/gnupg/bin:/usr/lib/ccache:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/games # I can use the full qualified path for either of the versions (infra) [~] /local/gnupg/bin/gpg2 --version gpg (GnuPG) 2.1.14 libgcrypt 1.7.2 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: /home/sithglan/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 (infra) [~] /usr/bin/gpg2 --version gpg (GnuPG) 2.0.26 libgcrypt 1.6.3 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, RSA, RSA, ELG, DSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 Cheers, Thomas From felix at audiofair.de Mon Jul 25 12:08:30 2016 From: felix at audiofair.de (Felix Winterhalter) Date: Mon, 25 Jul 2016 12:08:30 +0200 Subject: Creating key stubs from smartcard without public key Message-ID: So I've recently started experimenting with a Yubikey. I started off by creating an encryption subkey from my master key and moving that to the Yubikey. This worked fine until I moved to a different computer and tried using it there. It didn't automatically recognize the key on the card until I imported my publickey as well. As far as I understand public key encryption regenerating the public key should always be possible using the private key (which should be stored on the card). My expected result would have been that gpg --card-status reads the card and then imports all keys on the card generating the public key associated on the fly for local use. The situation gets even more complicated if I want to have an authentication subkey on my Yubikey and not have it bound to any specific master key (and certainly not publish it on any keyservers). How can I export the ssh key (using gpg --export-ssh-key) when trying to do so using the key id yields: gpg2 --export-ssh-key 0x5FECDB8C8311CB07! gpg: key "0x5FECDB8C8311CB07!" not found: No public key gpg: export as ssh key failed: No public key Is there any way those public keys or key stubs can be created from the keys stored on the Yubikey or any smartcard itself? Best regards, Felix From thomas at glanzmann.de Mon Jul 25 12:59:21 2016 From: thomas at glanzmann.de (Thomas Glanzmann) Date: Mon, 25 Jul 2016 12:59:21 +0200 Subject: Creating key stubs from smartcard without public key In-Reply-To: References: Message-ID: <20160725105921.GA18620@glanzmann.de> Hello Felix, > Is there any way those public keys or key stubs can be created from > the keys stored on the Yubikey or any smartcard itself? the easiest way is: (infra) [~] ssh-add -L ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDhYUVGvoVX7jE40Tb/iI45EsyuPv6dbe7wH66OqSYoakImnuDbitQWjAb4rbHiOAtnE6hkbHjyDg6GZum+adG4lUEIhuSEj6pXYrWuToPa3wWUCVrBFH5zYbtHiz8sOGtTrGJk9HAcKKMo1cjYiZ/HMwRsXkG6DS5hMpleMh8vBURWhEaAyOFhupcfrvPIhjJ1JrQhA5EdARZnX0qNFYbo0LoJCpDCF+YShsp1HalRJbG+1LXaXf3EEcw73AeKLjpigVA5nXklzFSrFR+pQ1SQjrgqmwHnu0lkqKKptlWJ0r3lq1adLdKLS09QIuONOFxk9QBon0VwltNK0a6OeYVrsktPdsDJnEq2wgV+eD8Y2FJ2vQdG+BMowAHUEw/f3vilGvxbR5GW7/nJ+AAodfwLrdxXnPQU/ruHAJU96bqEzxR4V7gXmvV3r4o/73fcY0LYQhbGDIp1H0d0fhGb/YOAOk8I1m4NjqqL3uvynMWiBiE7K+pj4/koYdEphEeHgoi7ya/cac7pWX7YPHOV2JQ7DF6CqymdR4PRVCsRWJnZBk3WsvMkVE3uUtNar7SpwVz9bb6r2cL43HK6x7GXJkFgtvilB6pFNWEtvJ7j/o0dvJru3Ic3eUjiNvrXyG9e84tlCL1Vx64yadR8WUAYJ56Old6Vi8bsRLyJH7YvRnkR5Q== cardno:000604936887 Cheers, Thomas From fgunbin at fastmail.fm Mon Jul 25 16:44:46 2016 From: fgunbin at fastmail.fm (Filipp Gunbin) Date: Mon, 25 Jul 2016 17:44:46 +0300 Subject: improvements for "Git Access" page Message-ID: Hi, Some things which can be fixed: - page url is https://www.gnupg.org/download/cvs_access.html , while it's certainly not "cvs" now. Or was "vcs" meant? - A little typo: "You must run ./autogen.sh before running the ./configure in the way suggested by the putput of autogen.sh." ^^^^^^ - libgpg-error seems to be hosted at git://git.gnupg.org/libgpg-error.git, but it's not mentioned in "Other Hosted Projects" Thanks, Filipp From thomas at glanzmann.de Mon Jul 25 18:06:43 2016 From: thomas at glanzmann.de (Thomas Glanzmann) Date: Mon, 25 Jul 2016 18:06:43 +0200 Subject: improvements for "Git Access" page In-Reply-To: References: Message-ID: <20160725160642.GC19279@glanzmann.de> Hello everyone, > https://www.gnupg.org/download/cvs_access.html I also recently build gnupg myself, I was missing some dependencies mentioned on this site. I guessed their names and git repositories, namely: git://git.gnupg.org/libksba.git git://git.gnupg.org/libassuan.git git://git.gnupg.org/libgpg-error.git git://git.gnupg.org/npth.git git://git.gnupg.org/gpgme.git Maybe they should be added to this site as well. Cheers, Thomas From ck+gnupgusers at bl4ckb0x.de Tue Jul 26 09:59:33 2016 From: ck+gnupgusers at bl4ckb0x.de (Conrad Kostecki) Date: Tue, 26 Jul 2016 09:59:33 +0200 (CEST) Subject: OpenGPG Smart Card v2.1 - unable to create key - card error In-Reply-To: <57672B34.5000307@fsij.org> References: <87y46180jg.fsf@wheatstone.g10code.de> <57672B34.5000307@fsij.org> Message-ID: <2038034075.1369.1469519973620@office.mailbox.org> Hi! I am sorry for my late delay. > NIIBE Yutaka hat am 20. Juni 2016 um 01:31 geschrieben: > > As a test try to create a 1024 bit key. > > I think that it should work with RSA-1024 and RSA-2048. I'm afraid > the reader doesn't work for RSA-4096. Yep. Creating RSA-1024 or RSA-2048 directly on this card works fine. I don't know, if this is correct, but when I do create an RSA-4096 key with GPG directly on my Gentoo notebook and move this one to the card with "keytocard", it works and a RSA-4096 is shown on my card. Seems to work somehow, that RSA-4096 is possible? > I suggest try using with PC/SC service. It's pcscd and libccid on > GNU/Linux. There is a little possibility it works fine. If it works, > please let us know. I will give a try. > Let me explain the situation. Thanks for the explenation. Cheers Conrad From justus at g10code.com Tue Jul 26 10:56:16 2016 From: justus at g10code.com (Justus Winter) Date: Tue, 26 Jul 2016 10:56:16 +0200 Subject: improvements for "Git Access" page In-Reply-To: References: Message-ID: <87d1m0rd5b.fsf@europa.jade-hamburg.de> Hello :) -------------- next part -------------- Filipp Gunbin writes: > - page url is https://www.gnupg.org/download/cvs_access.html , while > it's certainly not "cvs" now. Or was "vcs" meant? Agreed, looks odd. > - A little typo: "You must run ./autogen.sh before running the > ./configure in the way suggested by the putput of autogen.sh." > ^^^^^^ Fixed, thanks. > - libgpg-error seems to be hosted at > git://git.gnupg.org/libgpg-error.git, but it's not mentioned in "Other > Hosted Projects" Yes, the list is rather incomplete. I replaced it with a link to the repository browser. My fixes are in git only, the website will be updated soonish(tm). Thanks, Justus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From felix.klee at inka.de Tue Jul 26 12:05:28 2016 From: felix.klee at inka.de (Felix E. Klee) Date: Tue, 26 Jul 2016 12:05:28 +0200 Subject: gpg: KEYTOCARD failed: Unusable secret key Message-ID: Successfully moved a key to an [OpenPGP-Card][1]. Now, as backup, I want to install the key to a second card, but that failed: # gpg --edit-key $KEY [...] gpg> toggle [...] ggp> keytocard Really move the primary key? (y/N) y [...] Please select where to store the key: (1) Signature key (3) Authentication key Your selection? 1 gpg: WARNING: such a key has already been stored on the card! Replace existing key? (y/N) y gpg: KEYTOCARD failed: Unusable secret key Why did it work for the first card but not for the second one? I assume, although `keytocard` is documented as *moving* the key to the card, it actually copies it. [1]: https://g10code.com/p-card.html From andrewg at andrewg.com Tue Jul 26 13:22:08 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 26 Jul 2016 12:22:08 +0100 Subject: gpg: KEYTOCARD failed: Unusable secret key In-Reply-To: References: Message-ID: <1eefd51d-4332-f3f9-edb5-38b6500cfd9d@andrewg.com> On 26/07/16 11:05, Felix E. Klee wrote: > Successfully moved a key to an [OpenPGP-Card][1]. Now, as backup, I > want to install the key to a second card, but that failed: > > # gpg --edit-key $KEY > [...] > gpg> toggle > [...] > ggp> keytocard > Really move the primary key? (y/N) y > [...] > Please select where to store the key: > (1) Signature key > (3) Authentication key > Your selection? 1 > > gpg: WARNING: such a key has already been stored on the card! > > Replace existing key? (y/N) y > gpg: KEYTOCARD failed: Unusable secret key > > Why did it work for the first card but not for the second one? > > I assume, although `keytocard` is documented as *moving* the key to the > card, it actually copies it. It copies, but if you then save the changes to your local disk, the original copy on local disk is deleted - so calling it a "move" operation is correct. If you want to keep a backup copy on local disk, you need to quit *without saving* immediately after running 'keytocard'. This behaviour is a well-known gotcha. What does it say when you run "gpg --list-secret-keys" on your local machine now? A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From felix.klee at inka.de Tue Jul 26 14:11:06 2016 From: felix.klee at inka.de (Felix E. Klee) Date: Tue, 26 Jul 2016 14:11:06 +0200 Subject: gpg: KEYTOCARD failed: Unusable secret key In-Reply-To: <1eefd51d-4332-f3f9-edb5-38b6500cfd9d@andrewg.com> References: <1eefd51d-4332-f3f9-edb5-38b6500cfd9d@andrewg.com> Message-ID: On Tue, Jul 26, 2016 at 1:22 PM, Andrew Gallagher wrote: > What does it say when you run "gpg --list-secret-keys" on your local > machine now? *Without* the smart card reader connected, it says: # gpg ?list-secret-keys /ramdisk/pubring.kbx -------------------- sec> rsa4096 2016-07-26 [SC] [expires: ?] AFADB5A? Card serial no. = ? uid [ultimate] Felix ? ssb> rsa4096 2016-07-26 [E] [expires: ?] Also I can export the private key: # gpg --armor --export-secret-keys | wc -l 53 So it seems to be still there, no? From felix.klee at inka.de Tue Jul 26 15:17:07 2016 From: felix.klee at inka.de (Felix E. Klee) Date: Tue, 26 Jul 2016 15:17:07 +0200 Subject: gpg: KEYTOCARD failed: Unusable secret key In-Reply-To: <1eefd51d-4332-f3f9-edb5-38b6500cfd9d@andrewg.com> References: <1eefd51d-4332-f3f9-edb5-38b6500cfd9d@andrewg.com> Message-ID: On Tue, Jul 26, 2016 at 1:22 PM, Andrew Gallagher wrote: > If you want to keep a backup copy on local disk, you need to quit > *without saving* immediately after running 'keytocard'. Hitting to quit did the trick. Now I could copy the key ? a new one ? to two cards. Thanks for the suggestion! Before that I tried re-importing the private key from the `.asc` file, but it still was not possible to write it to another card. The error message was the same as before. I don?t understand this: The key is around, but somehow I cannot use it. From andrewg at andrewg.com Tue Jul 26 15:54:04 2016 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 26 Jul 2016 14:54:04 +0100 Subject: gpg: KEYTOCARD failed: Unusable secret key In-Reply-To: References: <1eefd51d-4332-f3f9-edb5-38b6500cfd9d@andrewg.com> Message-ID: On 26/07/16 13:11, Felix E. Klee wrote: > On Tue, Jul 26, 2016 at 1:22 PM, Andrew Gallagher > wrote: >> What does it say when you run "gpg --list-secret-keys" on your local >> machine now? > > *Without* the smart card reader connected, it says: It shouldn't matter whether you have the card reader connected or not. To get the state of your card, use "gpg --card-status". > # gpg ?list-secret-keys > /ramdisk/pubring.kbx > -------------------- > sec> rsa4096 2016-07-26 [SC] [expires: ?] > AFADB5A? > Card serial no. = ? > uid [ultimate] Felix ? > ssb> rsa4096 2016-07-26 [E] [expires: ?] The ">" means that the substance of the secret key has been moved to a card; a stub remains to indicate where it went. > Also I can export the private key: > > # gpg --armor --export-secret-keys | wc -l > 53 > > So it seems to be still there, no? That is probably just the stub that you've exported, not the actual key. That would also explain why re-importing it doesn't help. A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From samir at samirnassar.com Wed Jul 27 13:17:43 2016 From: samir at samirnassar.com (Samir Nassar) Date: Wed, 27 Jul 2016 13:17:43 +0200 Subject: Disambiguating GnuPG Modern, Stable, and Classic Message-ID: <1469618263.23053.16.camel@samirnassar.com> Hello, The GnuPG project describes the three branches of GnuPG as?Modern (2.1.x), Stable (2.0.x), and Classic (1.4.x). Should it be understood that GnuPG Modern is similar to a development branch? --? Samir Nassar web:????samirnassar.com email:??samir at samirnassar.com PGP:????pgp.samirnassar.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From marcoshalano at gmail.com Wed Jul 27 13:40:58 2016 From: marcoshalano at gmail.com (Marcos Alano) Date: Wed, 27 Jul 2016 11:40:58 +0000 Subject: Disambiguating GnuPG Modern, Stable, and Classic In-Reply-To: <1469618263.23053.16.camel@samirnassar.com> References: <1469618263.23053.16.camel@samirnassar.com> Message-ID: Hi Samir, IMHO, I don't think so. A dev branch is very unstable and modern branch is considerably stable but receive a lot of new features. Stable is very stable for people who wants a long term stable version. On Wed, Jul 27, 2016, 08:23 Samir Nassar wrote: > Hello, > > The GnuPG project describes the three branches of GnuPG as Modern > (2.1.x), Stable (2.0.x), and Classic (1.4.x). > > Should it be understood that GnuPG Modern is similar to a development > branch? > > -- > Samir Nassar > web: samirnassar.com > email: samir at samirnassar.com > PGP: pgp.samirnassar.com_______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- Marcos H. Alano Sent from my Android -------------- next part -------------- An HTML attachment was scrubbed... URL: From dashohoxha at gmail.com Wed Jul 27 14:39:43 2016 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Wed, 27 Jul 2016 14:39:43 +0200 Subject: Disambiguating GnuPG Modern, Stable, and Classic In-Reply-To: References: <1469618263.23053.16.camel@samirnassar.com> Message-ID: On Wed, Jul 27, 2016 at 1:40 PM, Marcos Alano wrote: > IMHO, I don't think so. A dev branch is very unstable and modern branch is > considerably stable but receive a lot of new features. Stable is very > stable for people who wants a long term stable version. > IMHO, a branch that gets new features is not stable. Stable is a branch that gets only bug fixes. So the "modern" version can be very nice and lovely etc. but not stable. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at digitalbrains.com Wed Jul 27 16:19:32 2016 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 27 Jul 2016 16:19:32 +0200 Subject: Disambiguating GnuPG Modern, Stable, and Classic In-Reply-To: References: <1469618263.23053.16.camel@samirnassar.com> Message-ID: Disclaimer: this is how I understand it. I'm just a bystander looking on, I might have misunderstood. On 27/07/16 14:39, Dashamir Hoxha wrote: > IMHO, a branch that gets new features is not stable. Stable is a branch > that gets only bug fixes. Precisely, I think this is where the questions arise from: a misunderstanding about the context of the word stable here. That there is a branch named Stable does not mean the branch Modern is "unstable"! If I wanted to hang something heavy, I might ascertain that the wall is stable before I do so. Even more so, a wall that is not stable is generally a thing you'd like to avoid or fix. Even with nothing hanging from it, it can give you an eery feeling to be very close to it. You'd better not lean against it! But that is not the sense of the word here: here that interpretation is out of context. So here it means: - Modern is where new stuff happens - Stable will not undergo major changes such as architectural changes - Classic is what it was long ago (albeit without known serious bugs) Modern is perfectly suitable for serious use, and not a security risk or anything like that. It just might undergo rather large changes, which means it's less suitable to some deployments where such a thing would cost a lot of effort to follow along with those changes. My 2 cents, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at From john at zuri.ch Wed Jul 27 15:46:19 2016 From: john at zuri.ch (John Buehrer) Date: Wed, 27 Jul 2016 15:46:19 +0200 Subject: Please, fix batch mode for gpg --edit-key-trust Message-ID: Using gpg 2.1.1 with Ubuntu 16.04, this fails: $ printf "5\n" | gpg2 --batch --edit-key 67A92459607354C7 trust quit ... Please decide how far you trust this user to correctly verify other users' keys (by looking at passports, checking fingerprints from different sources, etc.) 1 = I don't know or won't say 2 = I do NOT trust 3 = I trust marginally 4 = I trust fully 5 = I trust ultimately m = back to the main menu *gpg: Sorry, we are in batchmode - can't get input* Why doesn't this work? Or rather, can this be made to work? I'm surprised anything GNU doesn't automatically read input from a redirected STDIN, that's Unix 101. Searching the archives, I see a number of complicated scripting work-arounds. Maybe I missed the insight somewhere why this simply doesn't "just work" ? Thanks John From lachlan at twopif.net Wed Jul 27 15:47:54 2016 From: lachlan at twopif.net (Lachlan Gunn) Date: Wed, 27 Jul 2016 23:17:54 +0930 Subject: Disambiguating GnuPG Modern, Stable, and Classic In-Reply-To: <1469618263.23053.16.camel@samirnassar.com> References: <1469618263.23053.16.camel@samirnassar.com> Message-ID: <8684b32a-5fcf-f7ad-f781-66b596bd2891@twopif.net> Le 2016-07-27 ? 20:47, Samir Nassar a ?crit : > Should it be understood that GnuPG Modern is similar to a development > branch? It's more stable than that, WK's words from a few months ago were "it is not just stable, but modern! Go and use it." If it's any indication, gnupg2 in Debian testing is now 2.1.11. Thanks, Lachlan From dashohoxha at gmail.com Wed Jul 27 18:32:22 2016 From: dashohoxha at gmail.com (Dashamir Hoxha) Date: Wed, 27 Jul 2016 18:32:22 +0200 Subject: Please, fix batch mode for gpg --edit-key-trust In-Reply-To: References: Message-ID: On Wed, Jul 27, 2016 at 3:46 PM, John Buehrer wrote: > > $ printf "5\n" | gpg2 --batch --edit-key 67A92459607354C7 trust quit > I think that it should work with the option `--command-fd=0`, which tells gpg2 to get the commands from stdin. See this example: https://github.com/dashohoxha/egpg/blob/gnupg-2.1/src/cmd/contact/trust.sh#L39 > I'm surprised anything GNU doesn't automatically read input from a > redirected STDIN, > that's Unix 101. > I totally agree with you on this. This was my reaction too, and beleive it is the same for every unix guy that comes across gnupg. Searching the archives, I see a number of complicated scripting > work-arounds. > Maybe I missed the insight somewhere why this simply doesn't "just work" ? > If I am allowed to speculate, this happens because gnupg is a very ancient program, since the time of dinosaurs. However it is trying to become more modern lately. Another reason may be that it has tried to immitate closely OpenPGP. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thecissou98 at hotmail.fr Sat Jul 30 11:11:00 2016 From: thecissou98 at hotmail.fr (Le Roy Francis) Date: Sat, 30 Jul 2016 09:11:00 +0000 Subject: GPGME & Smartcard Message-ID: Hello, I got several questions on how to use the gpgme lib (C++) along with a Open PGP Smart Card. First, I saw in the documentation a function called gpgme_op_card_edit. I don't fully understand how that's work, would you mind providing me an example ? Secondly, I haven't received my Smart Card yet for testing, but are gpgme_op_keylist_start and gpgme_op_export working with a Smart Card ? How can I change the secret key inside my Smart Card ? Thirdly, is there a way to override the default pin-entry function to replace it with a callback function of my own ? Best Regards. F.L.R. From goncc123rr at gmail.com Sun Jul 31 18:03:37 2016 From: goncc123rr at gmail.com (Dylan Wang) Date: Sun, 31 Jul 2016 16:03:37 +0000 Subject: Suddenly unable to use gpg-agent with putty Message-ID: Putty gives me disconnected no supported authentication methods error, and not asking me for pinentry pin, but I could do git sign without problem. I didn't change server settings all my server can't ssh with putty now, and I double check sshcontrol file, it doesn't change and correctly configured, also enable-putty-support is in my gpg-agent.conf. I tried everything I could do, re-plug my keys, reboot, reinstall & configure gnupg, restart gpg-agent...my settings always works well on the past few months. Right now I completely can't figure out what's happened here, I'm running gpg 2.1.14 on windows 10, below are the detailed log for gpg-agent: ? gpg-agent --daemon --verbose --debug-level guru --enable-putty-support gpg-agent[12792]: enabled debug flags: command mpi crypto memory cache memstat hashing ipc gpg-agent[12792]: listening on socket 'C:\Users\goncc\AppData\Roaming\gnupg\S.gpg-agent' gpg-agent[12792]: gpg-agent (GnuPG) 2.1.14 started gpg-agent[12792]: putty message loop thread started gpg-agent[12792]: handler 0x4 for fd 496 started gpg-agent[12792]: DBG: chan_0x000001f0 -> OK Pleased to meet you gpg-agent[12792]: DBG: chan_0x00000270 <- OK Pleased to meet you gpg-agent[12792]: DBG: chan_0x00000270 -> GETINFO pid gpg-agent[12792]: DBG: chan_0x000001f0 <- GETINFO pid gpg-agent[12792]: DBG: chan_0x000001f0 -> D 12792 gpg-agent[12792]: DBG: chan_0x00000270 <- D 12792 gpg-agent[12792]: DBG: chan_0x000001f0 -> OK gpg-agent[12792]: DBG: chan_0x00000270 <- OK gpg-agent[12792]: DBG: chan_0x00000270 -> BYE gpg-agent[12792]: DBG: chan_0x000001f0 <- BYE gpg-agent[12792]: DBG: chan_0x000001f0 -> OK closing connection gpg-agent[12792]: handler 0x4 for fd 496 terminated Much appreciate if someone could help me or give me some advice on how to debug this. Thanks, Dylan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jerry at seibercom.net Sun Jul 31 21:20:14 2016 From: jerry at seibercom.net (Jerry) Date: Sun, 31 Jul 2016 15:20:14 -0400 Subject: Suddenly unable to use gpg-agent with putty In-Reply-To: References: Message-ID: <20160731152014.000033e4@seibercom.net> On Sun, 31 Jul 2016 16:03:37 +0000, Dylan Wang stated: >Putty gives me disconnected no supported authentication methods error, >and not asking me for pinentry pin, but I could do git sign without >problem. I didn't change server settings all my server can't ssh with >putty now, and I double check sshcontrol file, it doesn't change and >correctly configured, also enable-putty-support is in my >gpg-agent.conf. I tried everything I could do, re-plug my keys, >reboot, reinstall & configure gnupg, restart gpg-agent...my settings >always works well on the past few months. Right now I completely can't >figure out what's happened here, I'm running gpg 2.1.14 on windows 10, >below are the detailed log for gpg-agent: > >? gpg-agent --daemon --verbose --debug-level guru >--enable-putty-support gpg-agent[12792]: enabled debug flags: command >mpi crypto memory cache memstat hashing ipc >gpg-agent[12792]: listening on socket >'C:\Users\goncc\AppData\Roaming\gnupg\S.gpg-agent' >gpg-agent[12792]: gpg-agent (GnuPG) 2.1.14 started >gpg-agent[12792]: putty message loop thread started >gpg-agent[12792]: handler 0x4 for fd 496 started >gpg-agent[12792]: DBG: chan_0x000001f0 -> OK Pleased to meet you >gpg-agent[12792]: DBG: chan_0x00000270 <- OK Pleased to meet you >gpg-agent[12792]: DBG: chan_0x00000270 -> GETINFO pid >gpg-agent[12792]: DBG: chan_0x000001f0 <- GETINFO pid >gpg-agent[12792]: DBG: chan_0x000001f0 -> D 12792 >gpg-agent[12792]: DBG: chan_0x00000270 <- D 12792 >gpg-agent[12792]: DBG: chan_0x000001f0 -> OK >gpg-agent[12792]: DBG: chan_0x00000270 <- OK >gpg-agent[12792]: DBG: chan_0x00000270 -> BYE >gpg-agent[12792]: DBG: chan_0x000001f0 <- BYE >gpg-agent[12792]: DBG: chan_0x000001f0 -> OK closing connection >gpg-agent[12792]: handler 0x4 for fd 496 terminated > >Much appreciate if someone could help me or give me some advice on how >to debug this. > >Thanks, >Dylan > What version of PUTTY are you using? -- Jerry