From abel at guardianproject.info Wed Jan 2 17:25:31 2013 From: abel at guardianproject.info (Abel Luck) Date: Wed, 02 Jan 2013 16:25:31 +0000 Subject: [guardian-dev] GPG+Android pinentry status In-Reply-To: <50E2351F.2070901@guardianproject.info> References: <50DF3B8F.9070403@guardianproject.info> <50E2351F.2070901@guardianproject.info> Message-ID: <50E45F7B.90707@guardianproject.info> Hans-Christoph Steiner: > > Its all building on the build server, that's good news :) > > I am pretty sure that gpg2 <---> gpg-agent was working because I was able to > verify and encrypt files. As far as I understand it, in GnuPG 2.1, the gpg2 > does no work on its own, but only serves as an interface to gpg-agent, which > now does all the work. I'm also able to download a key from the keyserver, > but maybe that skips gpg-agent and just uses dirmngr. > I haven't tried encrypting, but decrypting is definitely failing because gpg2 can't communicate with gpg-agent (I'll post some logs soonish). > Now, I just tried the "List Keys" test option from the menu, which definitely > uses gpg-agent and definitely worked before. That caused gpg-agent to crash. > Could the new pinentry stuff be causing this? > I very much doubt it... but you never know. I recall not being able to list keys before many of my changes. Possibly some recent commits or android build patches are the cause? > .hc > > On 12/29/2012 01:50 PM, Abel Luck wrote: >> __ Where is my android pinentry? __ >> >> We're so close to a working pinentry. All the pieces have fallen into >> place, though they fell haphazardly and it's all quite a mess. >> >> This is all somewhat convoluted so I thought I'd do a bit of >> documentation real quick. Eventually this will go into actual docs in >> the source tree, but I need to brain dump first. >> >> __ Show me the Beasty __ >> >> So you want to decrypt that email you say? Here's how that'll work: >> >> Component interaction in my hastily spewed ascii chart format: >> >> ("<--->" is IPC) >> >> [ User action e.g., decrypt ] >> | >> 1. gpg2 --decrypt secret_msg >> | >> 2. gpg2 <---> gpg-agent >> | >> 3. gpg-agent <---> pinentry-android (p-a) >> | >> 4. p-a invokes PINEntry Activity (P-A) >> | >> 5. (P-A) <---> p-a >> | >> [ User types PIN ] >> >> gpg2 is what you think it is >> gpg-agent is GPG's daemon that manages secret keys >> pinentry-android is the C command line utility >> PINEntry Activity is the Java/Android GUI for inputing the PIN >> >> As you can see we're nomming hard on that yummy unixy IPC. >> >> __But Does It Work?__ >> >> 1. works, but doesn't decrypt as it can't talk to gpg-agent (see 2) >> 2. not working >> 3. unknown (blocking on 2) >> 4. works >> 5. works, but no useful data is passed yet >> >> __ So nothing really works? __ >> >> Basically. >> >> __ And then? __ >> >> The next step is to sit down with gpg-agent and gpg2 and have a little >> relationship counseling. >> >> Then, assuming 3 works (hah!), we need to teach PIN Entry Activity >> gpg-agent's language (known as Assuan) or translate it into something >> simpler (I'm betting on the latter). >> >> __Where is all this crap?__ >> >> I simplified things down to two repos. >> >> pinentry-android lives in the actual gnupg pinentry source tree, but >> since we haven't submitted anything upstream yet, it lives in my >> personal repo. Hopefully this will go back upstream to the good GnuPG >> guardians. >> https://github.com/abeluck/pinentry/tree/android >> >> PINEntry Activity lives in gnupg-for-android along with the cross >> compiled gpg2, gpg-agent and pinentry >> https://github.com/guardianproject/gnupg-for-android >> >> __ So I came here, read this, and get nothing? __ >> >> False! You'll be leaving with a warm fuzzy feeling secure in the fact >> that pinentry on Android is not too far off. >> >> _______________________________________________ >> Guardian-dev mailing list >> >> Post: Guardian-dev at lists.mayfirst.org >> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev >> >> To Unsubscribe >> Send email to: Guardian-dev-unsubscribe at lists.mayfirst.org >> Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/hans%40guardianproject.info >> >> You are subscribed as: hans at guardianproject.info >> > _______________________________________________ > Guardian-dev mailing list > > Post: Guardian-dev at lists.mayfirst.org > List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev > > To Unsubscribe > Send email to: Guardian-dev-unsubscribe at lists.mayfirst.org > Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/abel%40guardianproject.info > > You are subscribed as: abel at guardianproject.info > From hans at guardianproject.info Wed Jan 2 17:47:14 2013 From: hans at guardianproject.info (Hans of Guardian) Date: Wed, 2 Jan 2013 11:47:14 -0500 Subject: [guardian-dev] GPG+Android pinentry status In-Reply-To: <50E45F7B.90707@guardianproject.info> References: <50DF3B8F.9070403@guardianproject.info> <50E2351F.2070901@guardianproject.info> <50E45F7B.90707@guardianproject.info> Message-ID: <588C2233-CEFB-4930-B63A-33161FAB471A@guardianproject.info> On Jan 2, 2013, at 11:25 AM, Abel Luck wrote: > Hans-Christoph Steiner: >> >> Its all building on the build server, that's good news :) >> >> I am pretty sure that gpg2 <---> gpg-agent was working because I was able to >> verify and encrypt files. As far as I understand it, in GnuPG 2.1, the gpg2 >> does no work on its own, but only serves as an interface to gpg-agent, which >> now does all the work. I'm also able to download a key from the keyserver, >> but maybe that skips gpg-agent and just uses dirmngr. >> > > I haven't tried encrypting, but decrypting is definitely failing because > gpg2 can't communicate with gpg-agent (I'll post some logs soonish). > > >> Now, I just tried the "List Keys" test option from the menu, which definitely >> uses gpg-agent and definitely worked before. That caused gpg-agent to crash. >> Could the new pinentry stuff be causing this? >> > I very much doubt it... but you never know. I recall not being able to > list keys before many of my changes. Possibly some recent commits or > android build patches are the cause? Its possible the new changes in gnupg are the culprit. I definitely was using list keys as a test case before, but I haven't tried it in a while. .hc >> .hc >> >> On 12/29/2012 01:50 PM, Abel Luck wrote: >>> __ Where is my android pinentry? __ >>> >>> We're so close to a working pinentry. All the pieces have fallen into >>> place, though they fell haphazardly and it's all quite a mess. >>> >>> This is all somewhat convoluted so I thought I'd do a bit of >>> documentation real quick. Eventually this will go into actual docs in >>> the source tree, but I need to brain dump first. >>> >>> __ Show me the Beasty __ >>> >>> So you want to decrypt that email you say? Here's how that'll work: >>> >>> Component interaction in my hastily spewed ascii chart format: >>> >>> ("<--->" is IPC) >>> >>> [ User action e.g., decrypt ] >>> | >>> 1. gpg2 --decrypt secret_msg >>> | >>> 2. gpg2 <---> gpg-agent >>> | >>> 3. gpg-agent <---> pinentry-android (p-a) >>> | >>> 4. p-a invokes PINEntry Activity (P-A) >>> | >>> 5. (P-A) <---> p-a >>> | >>> [ User types PIN ] >>> >>> gpg2 is what you think it is >>> gpg-agent is GPG's daemon that manages secret keys >>> pinentry-android is the C command line utility >>> PINEntry Activity is the Java/Android GUI for inputing the PIN >>> >>> As you can see we're nomming hard on that yummy unixy IPC. >>> >>> __But Does It Work?__ >>> >>> 1. works, but doesn't decrypt as it can't talk to gpg-agent (see 2) >>> 2. not working >>> 3. unknown (blocking on 2) >>> 4. works >>> 5. works, but no useful data is passed yet >>> >>> __ So nothing really works? __ >>> >>> Basically. >>> >>> __ And then? __ >>> >>> The next step is to sit down with gpg-agent and gpg2 and have a little >>> relationship counseling. >>> >>> Then, assuming 3 works (hah!), we need to teach PIN Entry Activity >>> gpg-agent's language (known as Assuan) or translate it into something >>> simpler (I'm betting on the latter). >>> >>> __Where is all this crap?__ >>> >>> I simplified things down to two repos. >>> >>> pinentry-android lives in the actual gnupg pinentry source tree, but >>> since we haven't submitted anything upstream yet, it lives in my >>> personal repo. Hopefully this will go back upstream to the good GnuPG >>> guardians. >>> https://github.com/abeluck/pinentry/tree/android >>> >>> PINEntry Activity lives in gnupg-for-android along with the cross >>> compiled gpg2, gpg-agent and pinentry >>> https://github.com/guardianproject/gnupg-for-android >>> >>> __ So I came here, read this, and get nothing? __ >>> >>> False! You'll be leaving with a warm fuzzy feeling secure in the fact >>> that pinentry on Android is not too far off. >>> >>> _______________________________________________ >>> Guardian-dev mailing list >>> >>> Post: Guardian-dev at lists.mayfirst.org >>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev >>> >>> To Unsubscribe >>> Send email to: Guardian-dev-unsubscribe at lists.mayfirst.org >>> Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/hans%40guardianproject.info >>> >>> You are subscribed as: hans at guardianproject.info >>> >> _______________________________________________ >> Guardian-dev mailing list >> >> Post: Guardian-dev at lists.mayfirst.org >> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev >> >> To Unsubscribe >> Send email to: Guardian-dev-unsubscribe at lists.mayfirst.org >> Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/abel%40guardianproject.info >> >> You are subscribed as: abel at guardianproject.info >> > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From bernhard at intevation.de Fri Jan 4 20:35:12 2013 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 04 Jan 2013 20:35:12 +0100 Subject: A wiki for GnuPG and related topics? In-Reply-To: <201212211230.48404.bernhard@intevation.de> References: <201212211230.48404.bernhard@intevation.de> Message-ID: <1410301.Jr8Au3VWDv@kymo.gruen> Am Freitag, 21. Dezember 2012, 12:30:43 schrieb Bernhard Reiter: > Hi friends of Free Software crypto, > > we do need a better plattform to document how > this all works together in a central place. Non one? > GnuPG has a wonderful technical documentation > and being involved with www.gpg4win.org and > www.gpg4kde.org I have contributed my part of making > the necessary knowledge more accessible. > > Still I have seen numerous installations where setup > or basic administration issues were faulty, resulting > in bad user experiences. And they are even unfortunate > because the technology of GnuPG would have allowed > to configure and use it in a better way. It mainly is > lack of knowledge. > > To give one example I recently saw Kontact on OpenSuse 12.2 > where they stil are unable to start a gnupg-agent by default. > Simple thing that worsens the experience a lot. > Where do I document the solution for all packagers of GNU systems, > like Debian, Redhat, Ubuntu? > > Now I also want to plan for interesting features and development > topics for Gpg4win, together with the community. The mailing is good, > but often not canonical. > > So my idea to solve is would be a wiki. > It takes a bit to maintain, spam fighting and keeping things together, > but we could do it. What do you think? > > Best Regards, > Bernhard > ps.: I offline for days to come until January. > pps.: If everybody agrees that running a Wiki is cool and we get some > people willing to help, maybe I am offering to host one from Intevaion. -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From buanzo at buanzo.com.ar Fri Jan 4 22:29:30 2013 From: buanzo at buanzo.com.ar (Arturo 'Buanzo' Busleiman) Date: Fri, 4 Jan 2013 18:29:30 -0300 Subject: A wiki for GnuPG and related topics? In-Reply-To: <1410301.Jr8Au3VWDv@kymo.gruen> References: <201212211230.48404.bernhard@intevation.de> <1410301.Jr8Au3VWDv@kymo.gruen> Message-ID: I can provide resources to host it and maintain it. From the heart! On Jan 4, 2013 4:38 PM, "Bernhard Reiter" wrote: > Am Freitag, 21. Dezember 2012, 12:30:43 schrieb Bernhard Reiter: > > Hi friends of Free Software crypto, > > > > we do need a better plattform to document how > > this all works together in a central place. > > Non one? > > > GnuPG has a wonderful technical documentation > > and being involved with www.gpg4win.org and > > www.gpg4kde.org I have contributed my part of making > > the necessary knowledge more accessible. > > > > Still I have seen numerous installations where setup > > or basic administration issues were faulty, resulting > > in bad user experiences. And they are even unfortunate > > because the technology of GnuPG would have allowed > > to configure and use it in a better way. It mainly is > > lack of knowledge. > > > > To give one example I recently saw Kontact on OpenSuse 12.2 > > where they stil are unable to start a gnupg-agent by default. > > Simple thing that worsens the experience a lot. > > Where do I document the solution for all packagers of GNU systems, > > like Debian, Redhat, Ubuntu? > > > > Now I also want to plan for interesting features and development > > topics for Gpg4win, together with the community. The mailing is good, > > but often not canonical. > > > > So my idea to solve is would be a wiki. > > It takes a bit to maintain, spam fighting and keeping things together, > > but we could do it. What do you think? > > > > Best Regards, > > Bernhard > > ps.: I offline for days to come until January. > > pps.: If everybody agrees that running a Wiki is cool and we get some > > people willing to help, maybe I am offering to host one from Intevaion. > -- > www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) > Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 > Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglisten at hauke-laging.de Sat Jan 5 12:58:18 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sat, 05 Jan 2013 12:58:18 +0100 Subject: A wiki for GnuPG and related topics? In-Reply-To: <201212211230.48404.bernhard@intevation.de> References: <201212211230.48404.bernhard@intevation.de> Message-ID: <3001055.jh2tdqlSQ6@inno> Hello, Am Fr 21.12.2012, 12:30:43 schrieb Bernhard Reiter: > Still I have seen numerous installations where setup > or basic administration issues were faulty, resulting > in bad user experiences. And they are even unfortunate > because the technology of GnuPG would have allowed > to configure and use it in a better way. It mainly is > lack of knowledge. as you may know from the users mailing list I am working on something by the idea "increase the use of OpenPGP by increasing knowledge about it", too: http://www.openpgp-schulungen.de/ This had a focus different from yours and will be limited to Germany / German at least for a while but I am willing to help towards your project. > To give one example I recently saw Kontact on OpenSuse 12.2 > where they stil are unable to start a gnupg-agent by default. > Simple thing that worsens the experience a lot. Really? In which way? I am annoyed because it seems not to be possible to configure openSUSE to start gpg-agent with SSH. Instead ssh-agent is started as a seperate process. IIRC this was different in earlier versions. I admit I have not complained about that in the bugtracking system yet. > It takes a bit to maintain, spam fighting Really? If editing requires an OpenPGP key? ;-) Hauke -- ? PGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 (seit 2012-11-04) http://www.openpgp-schulungen.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From buanzo at buanzo.com.ar Sat Jan 5 13:59:12 2013 From: buanzo at buanzo.com.ar (Arturo 'Buanzo' Busleiman) Date: Sat, 5 Jan 2013 09:59:12 -0300 Subject: A wiki for GnuPG and related topics? In-Reply-To: <3001055.jh2tdqlSQ6@inno> References: <201212211230.48404.bernhard@intevation.de> <3001055.jh2tdqlSQ6@inno> Message-ID: I created a small fun project about openpgp authentication for http called enigform. I'm using it on my blog http://blogs.buanzo.com.ar - any software that supports basic http auth can use it with minimal modifications. Check out http://wiki.buanzo.org for more details. On Jan 5, 2013 9:04 AM, "Hauke Laging" wrote: > Hello, > > Am Fr 21.12.2012, 12:30:43 schrieb Bernhard Reiter: > > > Still I have seen numerous installations where setup > > or basic administration issues were faulty, resulting > > in bad user experiences. And they are even unfortunate > > because the technology of GnuPG would have allowed > > to configure and use it in a better way. It mainly is > > lack of knowledge. > > as you may know from the users mailing list I am working on something by > the > idea "increase the use of OpenPGP by increasing knowledge about it", too: > > http://www.openpgp-schulungen.de/ > > This had a focus different from yours and will be limited to Germany / > German > at least for a while but I am willing to help towards your project. > > > > To give one example I recently saw Kontact on OpenSuse 12.2 > > where they stil are unable to start a gnupg-agent by default. > > Simple thing that worsens the experience a lot. > > Really? In which way? I am annoyed because it seems not to be possible to > configure openSUSE to start gpg-agent with SSH. Instead ssh-agent is > started > as a seperate process. IIRC this was different in earlier versions. I > admit I > have not complained about that in the bugtracking system yet. > > > > It takes a bit to maintain, spam fighting > > Really? If editing requires an OpenPGP key? ;-) > > > > Hauke > -- > ? > PGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 (seit 2012-11-04) > http://www.openpgp-schulungen.de/ > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at tgries.de Sun Jan 6 09:20:17 2013 From: mail at tgries.de (Thomas Gries) Date: Sun, 06 Jan 2013 09:20:17 +0100 Subject: A wiki for GnuPG and related topics? In-Reply-To: <201212211230.48404.bernhard@intevation.de> References: <201212211230.48404.bernhard@intevation.de> Message-ID: <50E933C1.6020501@tgries.de> Am 21.12.2012 12:30, schrieb Bernhard Reiter: > So my idea to solve is would be a wiki. +1 -- if you use latest MediaWiki software, which I know by heart. It requires a typical LAMP server installation and https://www.mediawiki.org/wiki/Download. I recommend to run the latest git version, because upgrading becomes very easy then. > It takes a bit to maintain, spam fighting and keeping things together, > but we could do it. What do you think? I offer my help to set up, and to maintain such a MediaWiki-based Wiki. Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From bernhard at intevation.de Sun Jan 6 20:02:56 2013 From: bernhard at intevation.de (Bernhard Reiter) Date: Sun, 06 Jan 2013 20:02:56 +0100 Subject: A wiki for GnuPG and related topics? In-Reply-To: <50E933C1.6020501@tgries.de> References: <201212211230.48404.bernhard@intevation.de> <50E933C1.6020501@tgries.de> Message-ID: <4424100.ys11hUaI1H@kymo.gruen> Arturo, Hauke, Thomas, thanks for responding and your willingness to help, that makes four of us so far! Am Sonntag, 6. Januar 2013, 09:20:17 schrieb Thomas Gries: > m 21.12.2012 12:30, schrieb Bernhard Reiter: > > So my idea to solve is would be a wiki. > > +1 -- if you use latest MediaWiki software, which I know by heart. Let us take the choice of technology when we have enough people to be able to maintain it for a while. And then we should also ask Werner, who will be the fallback, if we all drop out. My personal choice would be MoinMoin with Creole because this is something I would be able to adminstrate in the case of emergency. My goal in this endeavour is to contribute as much contents as I can and not do the administration, because I had to deal with some GnuPG OpenPGP and S/MIME configuration issues for a number of days in my professional life and there are a lot more people that can administrate a wiki. So how many people do we need? I guess we should also ask on the users list. Can anyone send an email there? Werner: What are you preferances for place of hosting, wiki software and such? Best Regards, Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Sun Jan 6 20:06:29 2013 From: bernhard at intevation.de (Bernhard Reiter) Date: Sun, 06 Jan 2013 20:06:29 +0100 Subject: A wiki for GnuPG and related topics? In-Reply-To: <3001055.jh2tdqlSQ6@inno> References: <201212211230.48404.bernhard@intevation.de> <3001055.jh2tdqlSQ6@inno> Message-ID: <3622277.e5Z3V1arpr@kymo.gruen> Am Samstag, 5. Januar 2013, 12:58:18 schrieb Hauke Laging: > Am Fr 21.12.2012, 12:30:43 schrieb Bernhard Reiter: > as you may know from the users mailing list I am working on something by > the idea "increase the use of OpenPGP by increasing knowledge about > it", too: > > http://www.openpgp-schulungen.de/ No, I haven't seen it yet, because I don't read the users list very often. > This had a focus different from yours and will be limited to Germany / > German at least for a while but I am willing to help towards your > project. Having a place where we all can add information is helping all places, I believe. And if we find enough maintainers we could do pages in other languages as well. > > It takes a bit to maintain, spam fighting > Really? If editing requires an OpenPGP key? ;-) If this can be done in a way that it is not posing a high burden for contributors, why not? :) Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From mailinglisten at hauke-laging.de Sun Jan 6 21:07:50 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sun, 06 Jan 2013 21:07:50 +0100 Subject: A wiki for GnuPG and related topics? In-Reply-To: <3622277.e5Z3V1arpr@kymo.gruen> References: <201212211230.48404.bernhard@intevation.de> <3001055.jh2tdqlSQ6@inno> <3622277.e5Z3V1arpr@kymo.gruen> Message-ID: <3576991.nG9qStartq@inno> Am So 06.01.2013, 20:06:29 schrieb Bernhard Reiter: > > > It takes a bit to maintain, spam fighting > > > > Really? If editing requires an OpenPGP key? ;-) > > If this can be done in a way that it is not posing a high burden for > contributors, why not? :) I don't know anything about wiki administration but I would be very surprised if it was not possible to configure a wiki so that account registration requires manual approval. What are we talking about, one additional user per week? Hard to believe that anyone would NOT edit an OpenPGP / GnuPG wiki just because he has so send a signed email. This would even be a privacy advantage as it would not be necessary to register an email address if you can register a key (one or more) instead (sending the required data via some web contact form). I would offer to make the translation into German. This would make it more convenient to link pages relevant to beginners from my page. :-) BTW: I haven't understood why this is supposed to be an issue for the devel list and not the users list. I guess there are a lot more people on the users list. Werner, still reading? ;-) , is that correct? Hauke -- ? PGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 (seit 2012-11-04) http://www.openpgp-schulungen.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Sun Jan 6 23:47:49 2013 From: wk at gnupg.org (Werner Koch) Date: Sun, 06 Jan 2013 23:47:49 +0100 Subject: A wiki for GnuPG and related topics? In-Reply-To: <4424100.ys11hUaI1H@kymo.gruen> (Bernhard Reiter's message of "Sun, 06 Jan 2013 20:02:56 +0100") References: <201212211230.48404.bernhard@intevation.de> <50E933C1.6020501@tgries.de> <4424100.ys11hUaI1H@kymo.gruen> Message-ID: <877gnq9be2.fsf@vigenere.g10code.de> On Sun, 6 Jan 2013 20:02, bernhard at intevation.de said: > Werner: What are you preferances for place of hosting, wiki software and > such? A wiki should use org-mode markup - everything else is just an annoyance (to me) ;-). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Sun Jan 6 23:52:07 2013 From: wk at gnupg.org (Werner Koch) Date: Sun, 06 Jan 2013 23:52:07 +0100 Subject: A wiki for GnuPG and related topics? In-Reply-To: <3576991.nG9qStartq@inno> (Hauke Laging's message of "Sun, 06 Jan 2013 21:07:50 +0100") References: <201212211230.48404.bernhard@intevation.de> <3001055.jh2tdqlSQ6@inno> <3622277.e5Z3V1arpr@kymo.gruen> <3576991.nG9qStartq@inno> Message-ID: <8738ydaprc.fsf@vigenere.g10code.de> On Sun, 6 Jan 2013 21:07, mailinglisten at hauke-laging.de said: > BTW: I haven't understood why this is supposed to be an issue for the devel > list and not the users list. I guess there are a lot more people on the users > list. Werner, still reading? ;-) , is that correct? 850 / 2185 users plus those reading via gmane. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernhard at intevation.de Mon Jan 7 20:54:11 2013 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 07 Jan 2013 20:54:11 +0100 Subject: A wiki for GnuPG and related topics? In-Reply-To: <877gnq9be2.fsf@vigenere.g10code.de> References: <201212211230.48404.bernhard@intevation.de> <4424100.ys11hUaI1H@kymo.gruen> <877gnq9be2.fsf@vigenere.g10code.de> Message-ID: <3612905.kJEGx59AME@kymo.gruen> Am Sonntag, 6. Januar 2013, 23:47:49 schrieb Werner Koch: > On Sun, 6 Jan 2013 20:02, bernhard at intevation.de said: > > Werner: What are you preferances for place of hosting, wiki software > > and such? > > A wiki should use org-mode markup - everything else is just an annoyance > (to me) ;-). Okay, no preferance on hosting. :) A brief search showed that there does not seem to be input plugins of org-mode to MoinMoin or MediaWiki. There are emacs mode for editing for both: http://www.moinmo.in/EmacsForMoinMoin http://www.emacswiki.org/emacs/MediaWikiMode Btw emacswiki runs a perl script called Oddmuse it is hosted on thinkmo.de which runs their wikis on MoinMoin. -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Mon Jan 7 20:55:43 2013 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 07 Jan 2013 20:55:43 +0100 Subject: A wiki for GnuPG and related topics? In-Reply-To: <3576991.nG9qStartq@inno> References: <201212211230.48404.bernhard@intevation.de> <3622277.e5Z3V1arpr@kymo.gruen> <3576991.nG9qStartq@inno> Message-ID: <2830607.MsVxempSnH@kymo.gruen> Am Sonntag, 6. Januar 2013, 21:07:50 schrieb Hauke Laging: > Am So 06.01.2013, 20:06:29 schrieb Bernhard Reiter: > > > > It takes a bit to maintain, spam fighting > > > Really? If editing requires an OpenPGP key? > > If this can be done in a way that it is not posing a high burden for > > contributors, why not? > > I don't know anything about wiki administration but I would be very > surprised if it was not possible to configure a wiki so that account > registration requires manual approval. What are we talking about, one > additional user per week? I believe manual approval is a significant burden. If I wante to start hacking on a wiki, I want to do it right away, as fast as possible. For us small group a manual approval would mean a delay of several hours at least on the average. Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Mon Jan 7 20:57:46 2013 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 07 Jan 2013 20:57:46 +0100 Subject: A wiki for GnuPG and related topics? In-Reply-To: <3576991.nG9qStartq@inno> References: <201212211230.48404.bernhard@intevation.de> <3622277.e5Z3V1arpr@kymo.gruen> <3576991.nG9qStartq@inno> Message-ID: <2422242.x1ElMk8xmP@kymo.gruen> Am Sonntag, 6. Januar 2013, 21:07:50 schrieb Hauke Laging: > BTW: I haven't understood why this is supposed to be an issue for the > devel list and not the users list. I guess there are a lot more people > on the users list. Werner, still reading? Without support from the people that actively contribute to the GnuPG initiative, the wiki would have a hard time. And one aim would be to educate the packagers and administrators to some of the questions that only people looking in the code can answer. That is why I've started the discussion here. -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From bernhard at intevation.de Mon Jan 7 21:02:40 2013 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 07 Jan 2013 21:02:40 +0100 Subject: GnuPG default in OpenSuse (Re: A wiki for GnuPG and related topics?) In-Reply-To: <3001055.jh2tdqlSQ6@inno> References: <201212211230.48404.bernhard@intevation.de> <3001055.jh2tdqlSQ6@inno> Message-ID: <3066832.J9FgMGXO27@kymo.gruen> Am Samstag, 5. Januar 2013, 12:58:18 schrieb Hauke Laging: > > To give one example I recently saw Kontact on OpenSuse 12.2 Actually it may be OpenSuse 12.1, I'm not sure about the update status. > > where they stil are unable to start a gnupg-agent by default. > > Simple thing that worsens the experience a lot. > > Really? In which way? When using GnuPG2, which all applications should do, with a few minor exceptions, I believe a gnupg-agent should be started early in a user session, so that all applications and terminal will inherit the parameters. It leads to: passphrase caching throughout the session. And S/MIME working correctly at all. Of either does not work, the user will have a hard time to improve the situation. First: It is hard to diagnose the issue, especially on badly working S/MIME and then it is hard to start an agent early in the user session, because it is different for all GNU distributions and even harder on windows or mac. > I am annoyed because it seems not to be possible > to configure openSUSE to start gpg-agent with SSH. Instead ssh-agent > is started as a seperate process. IIRC this was different in earlier > versions. I admit I have not complained about that in the bugtracking > system yet. -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From dkg at fifthhorseman.net Mon Jan 7 22:18:26 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 07 Jan 2013 16:18:26 -0500 Subject: A wiki for GnuPG and related topics? In-Reply-To: <2422242.x1ElMk8xmP@kymo.gruen> References: <201212211230.48404.bernhard@intevation.de> <3622277.e5Z3V1arpr@kymo.gruen> <3576991.nG9qStartq@inno> <2422242.x1ElMk8xmP@kymo.gruen> Message-ID: <50EB3BA2.6040109@fifthhorseman.net> I've refrained from commenting because i don't want to be a wet blanket, and i certainly wouldn't block anyone from setting up something like this. However, most people are busy people, and each new community that they're asked to join and contribute to requires a time commitment. Perhaps there is an existing community that people could contribute to? For example: https://we.riseup.net/debian/openpgp-best-practices is a wiki page that several folks (including myself) have contributed to. Create an account on https://we.riseup.net/ and join the "Debian Grimoire" group if you want to contribute as well. it doesn't offer org mode, sorry! It does offer a decent size set of pre-existing users already interested in the topic at some level, though :) Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Tue Jan 8 07:59:02 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 08 Jan 2013 15:59:02 +0900 Subject: Supporting not-so-smart card readers Message-ID: <1357628342.10080.1.camel@cfw2.gniibe.org> Hello, Last year, I bought a card reader with pinpad. It's: http://pcsclite.alioth.debian.org/ccid/supported.html#0x08E60x3478 lsusb says: 08e6:3478 Gemplus PinPad Smart Card Reader Unfortunately, this reader is not yet supported by the internal driver of GnuPG. PC/SC is needed for this card reader to use GnuPG. The internal driver requires CCID to have the feature of 'Auto configuration based on ATR', which is not available for the card reader. I am currently testing the patch below (against master branch), so that I can use the card reader with the internal driver of GnuPG. Basically, it is to add setting parameters based on ATR string. It works for me. No, pinpad is not yet supported, and some more work is required to support fixed length keypad input. I think that many card readers will work with this change (with no PC/SC service). Your comments, testing are welcome. Some notes: * The card reader claims that it supports the feature of nonnull NAD, but it doesn't work when NAD != 0. * It is needed to specify power voltage. Auto (=0) doesn't work. The patch: * scd/ccid-driver.c (struct ccid_driver_s): Add auto_voltage, auto_param, and auto_pps. (parse_ccid_descriptor): Set auto_voltage, auto_param, and auto_pps. Support non-autoconf readers. (update_param_by_atr): New. (ccid_get_atr): Use 5V for PowerOn when auto_voltage is not supported. Use 0x10 when nonnull_nad for SetParameters. Call update_param_by_atr for parsing ATR, and use param for SetParameters. Send PPS if reader requires it and card is negotiable. When bNadValue in the return values of SetParameters == 0, clear handle->nonnull_nad flag. -- This change is to support more card readers by the internal driver. Tested with 08e6:3478 Gemplus PinPad Smart Card Reader. --- scd/ccid-driver.c | 290 ++++++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 253 insertions(+), 37 deletions(-) diff --git a/scd/ccid-driver.c b/scd/ccid-driver.c index 3fe932c..5b3bcaf 100644 --- a/scd/ccid-driver.c +++ b/scd/ccid-driver.c @@ -264,6 +264,9 @@ struct ccid_driver_s unsigned char apdu_level:2; /* Reader supports short APDU level exchange. With a value of 2 short and extended level is supported.*/ + unsigned int auto_voltage:1; + unsigned int auto_param:1; + unsigned int auto_pps:1; unsigned int auto_ifsd:1; unsigned int powered_off:1; unsigned int has_pinpad:2; @@ -758,7 +761,7 @@ parse_ccid_descriptor (ccid_driver_t handle, { unsigned int i; unsigned int us; - int have_t1 = 0, have_tpdu=0, have_auto_conf = 0; + int have_t1 = 0, have_tpdu=0; handle->nonnull_nad = 0; @@ -767,6 +770,9 @@ parse_ccid_descriptor (ccid_driver_t handle, handle->ifsd = 0; handle->has_pinpad = 0; handle->apdu_level = 0; + handle->auto_voltage = 0; + handle->auto_param = 0; + handle->auto_pps = 0; DEBUGOUT_3 ("idVendor: %04X idProduct: %04X bcdDevice: %04X\n", handle->id_vendor, handle->id_product, handle->bcd_device); if (buflen < 54 || buf[0] < 54) @@ -842,22 +848,31 @@ parse_ccid_descriptor (ccid_driver_t handle, DEBUGOUT_1 (" dwFeatures %08X\n", us); if ((us & 0x0002)) { - DEBUGOUT (" Auto configuration based on ATR\n"); - have_auto_conf = 1; + DEBUGOUT (" Auto configuration based on ATR (assumes auto voltage)\n"); + handle->auto_voltage = 1; } if ((us & 0x0004)) DEBUGOUT (" Auto activation on insert\n"); if ((us & 0x0008)) - DEBUGOUT (" Auto voltage selection\n"); + { + DEBUGOUT (" Auto voltage selection\n"); + handle->auto_voltage = 1; + } if ((us & 0x0010)) DEBUGOUT (" Auto clock change\n"); if ((us & 0x0020)) DEBUGOUT (" Auto baud rate change\n"); if ((us & 0x0040)) - DEBUGOUT (" Auto parameter negotiation made by CCID\n"); + { + DEBUGOUT (" Auto parameter negotiation made by CCID\n"); + handle->auto_param = 1; + } else if ((us & 0x0080)) - DEBUGOUT (" Auto PPS made by CCID\n"); - else if ((us & (0x0040 | 0x0080))) + { + DEBUGOUT (" Auto PPS made by CCID\n"); + handle->auto_pps = 1; + } + if ((us & (0x0040 | 0x0080)) == (0x0040 | 0x0080)) DEBUGOUT (" WARNING: conflicting negotiation features\n"); if ((us & 0x0100)) @@ -935,11 +950,10 @@ parse_ccid_descriptor (ccid_driver_t handle, DEBUGOUT_LF (); } - if (!have_t1 || !(have_tpdu || handle->apdu_level) || !have_auto_conf) + if (!have_t1 || !(have_tpdu || handle->apdu_level)) { DEBUGOUT ("this drivers requires that the reader supports T=1, " - "TPDU or APDU level exchange and auto configuration - " - "this is not available\n"); + "TPDU or APDU level exchange - this is not available\n"); return -1; } @@ -2338,6 +2352,151 @@ ccid_slot_status (ccid_driver_t handle, int *statusbits) } +/* Parse ATR string (of ATRLEN) and update parameters at PARAM. + Calling this routine, it should prepare default values at PARAM + beforehand. This routine assumes that card is accessed by T=1 + protocol. It doesn't analyze historical bytes at all. + + Returns < 0 value on error: + -1 for parse error or integrity check error + -2 for card doesn't support T=1 protocol + -3 for parameters are nod explicitly defined by ATR + -4 for this driver doesn't support CRC + + Returns >= 0 on success: + 0 for card is negotiable mode + 1 for card is specific mode (and not negotiable) + */ +static int +update_param_by_atr (unsigned char *param, unsigned char *atr, size_t atrlen) +{ + int i = -1; + int t, y, chk; + int historical_bytes_num, negotiable = 1; + +#define NEXTBYTE() do { i++; if (atrlen <= i) return -1; } while (0) + + NEXTBYTE (); + + if (atr[i] == 0x3F) + param[1] |= 0x02; /* Convention is inverse. */ + NEXTBYTE (); + + y = (atr[i] >> 4); + historical_bytes_num = atr[i] & 0x0f; + NEXTBYTE (); + + if ((y & 1)) + { + param[0] = atr[i]; /* TA1 - Fi & Di */ + NEXTBYTE (); + } + + if ((y & 2)) + NEXTBYTE (); /* TB1 - ignore */ + + if ((y & 4)) + { + param[2] = atr[i]; /* TC1 - Guard Time */ + NEXTBYTE (); + } + + if ((y & 8)) + { + y = (atr[i] >> 4); /* TD1 */ + t = atr[i] & 0x0f; + NEXTBYTE (); + + if ((y & 1)) + { /* TA2 - PPS mode */ + if ((atr[i] & 0x0f) != 1) + return -2; /* Wrong card protocol (!= 1). */ + + if ((atr[i] & 0x10) != 0x10) + return -3; /* Transmission parameters are implicitly defined. */ + + negotiable = 0; /* TA2 means specific mode. */ + NEXTBYTE (); + } + + if ((y & 2)) + NEXTBYTE (); /* TB2 - ignore */ + + if ((y & 4)) + NEXTBYTE (); /* TC2 - ignore */ + + if ((y & 8)) + { + y = (atr[i] >> 4); /* TD2 */ + t = atr[i] & 0x0f; + NEXTBYTE (); + } + else + y = 0; + + while (y) + { + if ((y & 1)) + { /* TAx */ + if (t == 1) + param[5] = atr[i]; /* IFSC */ + else if (t == 15) + /* XXX: check voltage? */ + param[4] = (atr[i] >> 6); /* ClockStop */ + + NEXTBYTE (); + } + + if ((y & 2)) + { + if (t == 1) + param[3] = atr[i]; /* TBx - BWI & CWI */ + NEXTBYTE (); + } + + if ((y & 4)) + { + if (t == 1) + param[1] |= (atr[i] & 0x01); /* TCx - LRC/CRC */ + NEXTBYTE (); + + if (param[1] & 0x01) + return -4; /* CRC not supported yet. */ + } + + if ((y & 8)) + { + y = (atr[i] >> 4); /* TDx */ + t = atr[i] & 0x0f; + NEXTBYTE (); + } + else + y = 0; + } + } + + i += historical_bytes_num - 1; + NEXTBYTE (); + if (atrlen != i+1) + return -1; + +#undef NEXTBYTE + + chk = 0; + do + { + chk ^= atr[i]; + i--; + } + while (i > 0); + + if (chk != 0) + return -1; + + return negotiable; +} + + /* Return the ATR of the card. This is not a cached value and thus an actual reset is done. */ int @@ -2354,6 +2513,15 @@ ccid_get_atr (ccid_driver_t handle, unsigned int edc; int tried_iso = 0; int got_param; + unsigned char param[7] = { /* For Protocol T=1 */ + 0x11, /* bmFindexDindex */ + 0x10, /* bmTCCKST1 */ + 0x00, /* bGuardTimeT1 */ + 0x4d, /* bmWaitingIntegersT1 */ + 0x00, /* bClockStop */ + 0x20, /* bIFSC */ + 0x00 /* bNadValue */ + }; /* First check whether a card is available. */ rc = ccid_slot_status (handle, &statusbits); @@ -2368,7 +2536,8 @@ ccid_get_atr (ccid_driver_t handle, msg[0] = PC_to_RDR_IccPowerOn; msg[5] = 0; /* slot */ msg[6] = seqno = handle->seqno++; - msg[7] = 0; /* power select (0=auto, 1=5V, 2=3V, 3=1.8V) */ + /* power select (0=auto, 1=5V, 2=3V, 3=1.8V) */ + msg[7] = handle->auto_voltage ? 0 : 1; msg[8] = 0; /* RFU */ msg[9] = 0; /* RFU */ set_msg_len (msg, 0); @@ -2410,23 +2579,73 @@ ccid_get_atr (ccid_driver_t handle, *atrlen = n; } + param[6] = handle->nonnull_nad? ((1 << 4) | 0): 0; + rc = update_param_by_atr (param, msg+10, msglen - 10); + if (rc < 0) + { + DEBUGOUT_1 ("update_param_by_atr failed: %d\n", rc); + return CCID_DRIVER_ERR_CARD_IO_ERROR; + } + got_param = 0; - msg[0] = PC_to_RDR_GetParameters; - msg[5] = 0; /* slot */ - msg[6] = seqno = handle->seqno++; - msg[7] = 0; /* RFU */ - msg[8] = 0; /* RFU */ - msg[9] = 0; /* RFU */ - set_msg_len (msg, 0); - msglen = 10; - rc = bulk_out (handle, msg, msglen, 0); - if (!rc) - rc = bulk_in (handle, msg, sizeof msg, &msglen, RDR_to_PC_Parameters, - seqno, 2000, 0); - if (rc) - DEBUGOUT ("GetParameters failed\n"); - else if (msglen == 17 && msg[9] == 1) - got_param = 1; + + if (handle->auto_param) + { + msg[0] = PC_to_RDR_GetParameters; + msg[5] = 0; /* slot */ + msg[6] = seqno = handle->seqno++; + msg[7] = 0; /* RFU */ + msg[8] = 0; /* RFU */ + msg[9] = 0; /* RFU */ + set_msg_len (msg, 0); + msglen = 10; + rc = bulk_out (handle, msg, msglen, 0); + if (!rc) + rc = bulk_in (handle, msg, sizeof msg, &msglen, RDR_to_PC_Parameters, + seqno, 2000, 0); + if (rc) + DEBUGOUT ("GetParameters failed\n"); + else if (msglen == 17 && msg[9] == 1) + got_param = 1; + } + else if (handle->auto_pps) + ; + else if (rc == 1) /* It's negotiable, send PPS. */ + { + msg[0] = PC_to_RDR_XfrBlock; + msg[5] = 0; /* slot */ + msg[6] = seqno = handle->seqno++; + msg[7] = 0; + msg[8] = 0; + msg[9] = 0; + msg[10] = 0xff; /* PPSS */ + msg[11] = 0x11; /* PPS0: PPS1, Protocol T=1 */ + msg[12] = param[0]; /* PPS1: Fi / Di */ + msg[13] = 0xff ^ 0x11 ^ param[0]; /* PCK */ + set_msg_len (msg, 4); + msglen = 10 + 4; + + rc = bulk_out (handle, msg, msglen, 0); + if (rc) + return rc; + + rc = bulk_in (handle, msg, sizeof msg, &msglen, RDR_to_PC_DataBlock, + seqno, 5000, 0); + if (rc) + return rc; + + if (msglen != 10 + 4) + { + DEBUGOUT_1 ("Setting PPS failed: %d\n", msglen); + return CCID_DRIVER_ERR_CARD_IO_ERROR; + } + + if (msg[10] != 0xff || msg[11] != 0x11 || msg[12] != param[0]) + { + DEBUGOUT_1 ("Setting PPS failed: 0x%02x\n", param[0]); + return CCID_DRIVER_ERR_CARD_IO_ERROR; + } + } /* Setup parameters to select T=1. */ msg[0] = PC_to_RDR_SetParameters; @@ -2437,16 +2656,7 @@ ccid_get_atr (ccid_driver_t handle, msg[9] = 0; /* RFU */ if (!got_param) - { - /* FIXME: Get those values from the ATR. */ - msg[10]= 0x01; /* Fi/Di */ - msg[11]= 0x10; /* LRC, direct convention. */ - msg[12]= 0; /* Extra guardtime. */ - msg[13]= 0x41; /* BWI/CWI */ - msg[14]= 0; /* No clock stoppping. */ - msg[15]= 254; /* IFSC */ - msg[16]= 0; /* Does not support non default NAD values. */ - } + memcpy (&msg[10], param, 7); set_msg_len (msg, 7); msglen = 10 + 7; @@ -2463,6 +2673,12 @@ ccid_get_atr (ccid_driver_t handle, else handle->ifsc = 128; /* Something went wrong, assume 128 bytes. */ + if (handle->nonnull_nad && msglen > 16 && msg[16] == 0) + { + DEBUGOUT ("Use Null-NAD, clearing handle->nonnull_nad.\n"); + handle->nonnull_nad = 0; + } + handle->t1_ns = 0; handle->t1_nr = 0; -- 1.7.10.4 From wk at gnupg.org Tue Jan 8 09:03:40 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 08 Jan 2013 09:03:40 +0100 Subject: Supporting not-so-smart card readers In-Reply-To: <1357628342.10080.1.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Tue, 08 Jan 2013 15:59:02 +0900") References: <1357628342.10080.1.camel@cfw2.gniibe.org> Message-ID: <8762386qzn.fsf@vigenere.g10code.de> On Tue, 8 Jan 2013 07:59, gniibe at fsij.org said: > (ccid_get_atr): Use 5V for PowerOn when auto_voltage is not supported. How should one known which volatge is required? Is there a chance that this change may brick an, say, 1.8V reader? > This change is to support more card readers by the internal driver. > Tested with 08e6:3478 Gemplus PinPad Smart Card Reader. Feel free to push this change to master. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Tue Jan 8 09:31:18 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 08 Jan 2013 17:31:18 +0900 Subject: Supporting fixed length keypad input Message-ID: <1357633878.10080.3.camel@cfw2.gniibe.org> Hello, In the OpenPGP card specification, the password (PIN) is variable length. But not all card readers with pinpad support variable length input, but support fixed-length input only. I'd like to enhance GnuPG so that pinpad input will be possible with such a reader. I am considering the following. (1) Add a option to SCDaemon. Say, "opt.keypad_fixed_length" or something. This is to enable handling of fixed length keypad input for SCDaemon. Instead, this could be a list of readers which should be used with fixed length configuration, but maintaining such a list would be difficult. (2) Add protocol between SCDaemon and GPG-Agent. SCDaemon inquires length of PIN to GPG-Agent, when needed. (3) Upon inquiry by SCDaemon for the length of PIN, GPG-Agent will answer if it has the information at hand. Or else, GPG-Agent will invoke pinentry to ask the length to the user, and reply back to SCDaemon. (4) GPG-Agent could store the length of PIN with secret key information. I'm not sure if it would be useful for user to have GnuPG's command line option to specify the length of PIN. Any comments? -- From gniibe at fsij.org Tue Jan 8 09:48:20 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 08 Jan 2013 17:48:20 +0900 Subject: Supporting not-so-smart card readers In-Reply-To: <8762386qzn.fsf@vigenere.g10code.de> References: <1357628342.10080.1.camel@cfw2.gniibe.org> <8762386qzn.fsf@vigenere.g10code.de> Message-ID: <1357634900.10080.4.camel@cfw2.gniibe.org> On 2013-01-08 at 09:03 +0100, Werner Koch wrote: > On Tue, 8 Jan 2013 07:59, gniibe at fsij.org said: > > > (ccid_get_atr): Use 5V for PowerOn when auto_voltage is not supported. > > How should one known which volatge is required? Is there a chance that > this change may brick an, say, 1.8V reader? As far as I know, existing cards and card readers support 5V voltage. But it will be possible, in future, this code will break some hardware for some combinations of some card and some reader. To be conservative, we could take a strategy trying different voltages from lower to higher. If card reader supports all voltages (but not auto), it goes like this until it will success: 1.8V -> 3.3V -> 5V -> auto Then, after getting ATR string (and there is preference information in the ATR), change the voltage again if needed. But I'm not sure if this is worth implementing, given the situation GnuPG internal driver is for use of OpenPGP card (mainly). > > This change is to support more card readers by the internal driver. > > Tested with 08e6:3478 Gemplus PinPad Smart Card Reader. > > Feel free to push this change to master. Thanks. I will. -- From avi.wiki at gmail.com Tue Jan 8 10:00:52 2013 From: avi.wiki at gmail.com (Avi) Date: Tue, 8 Jan 2013 04:00:52 -0500 Subject: A wiki for GnuPG and related topics? Message-ID: As someone who spends a lot of time on the largest wiki in the world (see my sig) I can tell you that if the wiki is open the administration is going to be a significant time burden. Handling vandalism, ensuring well-meant mistakes aren't added accidentally, etc. If you would like to use a wiki, and I think that is a good idea, I would strongly recommend it being manual approval. I'm not a wiki developer, but perhaps the initial registration could be made easier by the admins sending "invitations" to a list of the e-mails of users who are well known on this mailing list for starters. Just my opinion. --Avi ---- User:Avraham pub 3072D/F80E29F9 1/30/2009 Avi (Wikimedia-related key) Primary key fingerprint: 167C 063F 7981 A1F6 71EC ABAA 0D62 B019 F80E 29F9 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Tue Jan 8 15:53:49 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 08 Jan 2013 15:53:49 +0100 Subject: A wiki for GnuPG and related topics? In-Reply-To: (Avi's message of "Tue, 8 Jan 2013 04:00:52 -0500") References: Message-ID: <87k3rn6802.fsf@vigenere.g10code.de> On Tue, 8 Jan 2013 10:00, avi.wiki at gmail.com said: > could be made easier by the admins sending "invitations" to a list of the > e-mails of users who are well known on this mailing list for starters. Or re-use the accounts from the bug tracker. Either by allowing the mail confirmed /Provisional User/ roles or the admin granted /User/ roles. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Jan 8 15:50:48 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 08 Jan 2013 15:50:48 +0100 Subject: Supporting fixed length keypad input In-Reply-To: <1357633878.10080.3.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Tue, 08 Jan 2013 17:31:18 +0900") References: <1357633878.10080.3.camel@cfw2.gniibe.org> Message-ID: <87obgz6853.fsf@vigenere.g10code.de> On Tue, 8 Jan 2013 09:31, gniibe at fsij.org said: > (1) Add a option to SCDaemon. Say, "opt.keypad_fixed_length" or > something. This is to enable handling of fixed length keypad > input for SCDaemon. The problem here is that you may not know the length of the PIN. The card may have been used before with a different reader. Depending on the implementation of the reader the wrong PIN counter may soon go down to zero. An explicit agreement from the user will be better. Or wait: We could extend the login data flags (app-openpgp.c:parse_login_data) to declare that the length of the pin is 6/8. Only if that flag has been set the fixed length feature may be used. > (2) Add protocol between SCDaemon and GPG-Agent. SCDaemon inquires > length of PIN to GPG-Agent, when needed. gpg-agent should not know about such card or reader details. > (3) Upon inquiry by SCDaemon for the length of PIN, GPG-Agent will > answer if it has the information at hand. Or else, GPG-Agent will > invoke pinentry to ask the length to the user, and reply back to > SCDaemon. It would be okay to use gpg-agent as a proxy to pop up a pinentry. IIRC, we already do that in some cases. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Wed Jan 9 03:22:44 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 09 Jan 2013 11:22:44 +0900 Subject: Supporting fixed length keypad input In-Reply-To: <87obgz6853.fsf@vigenere.g10code.de> References: <1357633878.10080.3.camel@cfw2.gniibe.org> <87obgz6853.fsf@vigenere.g10code.de> Message-ID: <1357698164.2912.1.camel@cfw2.gniibe.org> Thanks for your comment. I reconsidered. On 2013-01-08 at 15:50 +0100, Werner Koch wrote: > On Tue, 8 Jan 2013 09:31, gniibe at fsij.org said: > > > (1) Add a option to SCDaemon. Say, "opt.keypad_fixed_length" or > > something. This is to enable handling of fixed length keypad > > input for SCDaemon. > > The problem here is that you may not know the length of the PIN. The > card may have been used before with a different reader. Depending on > the implementation of the reader the wrong PIN counter may soon go down > to zero. An explicit agreement from the user will be better. I see. Yes, the PIN can be changed with a different environment. > Or wait: We could extend the login data flags > (app-openpgp.c:parse_login_data) to declare that the length of the pin > is 6/8. Only if that flag has been set the fixed length feature may be > used. This would be a place to save the information, but this information is available to everyone who can accesses the card, that would not be good. > (2) Add protocol between SCDaemon and GPG-Agent. SCDaemon inquires > > length of PIN to GPG-Agent, when needed. > > gpg-agent should not know about such card or reader details. I meant two things. It seems that it's only through GPG-Agent which SCDaemon could get such information from user. And, GPG-Agent could cache information of user interaction to stop asking user every time. Now, I understand the risk of caching wrong information to cause decreasing PIN counter to zero. > > (3) Upon inquiry by SCDaemon for the length of PIN, GPG-Agent will > > answer if it has the information at hand. Or else, GPG-Agent will > > invoke pinentry to ask the length to the user, and reply back to > > SCDaemon. > > It would be okay to use gpg-agent as a proxy to pop up a pinentry. > IIRC, we already do that in some cases. Yes. Perhaps, I was wrong that I began this discussion by implementation detail. Let's consider possible user interaction for keypad input. I think that the default interaction will be two steps. (1) When authentication is required for the card and the card reader has a feature of keypad input, GnuPG asks a user about use of keypad. If the card reader is not known to support variable length input, GnuPG asks length of PIN, too. If GnuPG knows the card reader supports variable length input (by an option or white list), it can omit asking length of PIN. NOTE: There are cases when user doesn't want to use the card reader's keypad. For example, his PIN includes characters not available by the reader's keypad. GUI would be like this: +-----------------------------+ | Do you use reader's keypad? | | | | Length of User PIN: [N ] | <-- This field is enabled for | | fixed-length input | [Yes] [No] | +-----------------------------+ (2) GnuPG sends command to the card reader for authentication with keypad and shows a dialog box to prompt user. +-------------------------------------+ | Please enter the PIN | | | | Use the reader's keypad for input. | | | | [OK] | +-------------------------------------+ And a user inputs PIN with the card reader's keypad. I'd like to propose adding the interaction of step (1) above, as a default. Next, we will consider how user can skip the step (1). Thinking about the condition GnuPG can skip the step (1).... Suppose we define three subconditions: (A) User specifies to force keypad input for the card. (B) GnuPG knows the card reader supports variable length input. (C) GnuPG knows the length of PIN. Then GnuPG can skip the step (1) when (A && (B || C)) is true. -- From gniibe at fsij.org Wed Jan 9 09:04:23 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 09 Jan 2013 17:04:23 +0900 Subject: Supporting not-so-smart card readers In-Reply-To: <1357634900.10080.4.camel@cfw2.gniibe.org> References: <1357628342.10080.1.camel@cfw2.gniibe.org> <8762386qzn.fsf@vigenere.g10code.de> <1357634900.10080.4.camel@cfw2.gniibe.org> Message-ID: <1357718663.5356.3.camel@cfw2.gniibe.org> On 2013-01-08 at 17:48 +0900, NIIBE Yutaka wrote: > I will. I pushed the change onto master. Besides, I did changes for drivers (both of internal ccid-driver and PC/SC driver) to support fixed length PIN input by keypad. And I pushed this work to "scd-work" branch. I tested internal ccid-driver (with debug code which hardcodes fixedlen = 6) with GemPC Pinpad reader (just lightly), and it works for me for verification and modification of User PIN. Drivers are somehow ready. We need to implement user interaction so that user can inform SCDaemon the length of PIN for fixed length. -- From wk at gnupg.org Wed Jan 9 10:23:21 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 09 Jan 2013 10:23:21 +0100 Subject: Supporting fixed length keypad input In-Reply-To: <1357698164.2912.1.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Wed, 09 Jan 2013 11:22:44 +0900") References: <1357633878.10080.3.camel@cfw2.gniibe.org> <87obgz6853.fsf@vigenere.g10code.de> <1357698164.2912.1.camel@cfw2.gniibe.org> Message-ID: <87wqvm4smu.fsf@vigenere.g10code.de> On Wed, 9 Jan 2013 03:22, gniibe at fsij.org said: > This would be a place to save the information, but this information is > available to everyone who can accesses the card, that would not be > good. I don't consider this a real problem. The minimum length is anyway 6 and thus there is not much of an advantage to notice that a larger PIN length. We have at max 6 tries. > I meant two things. It seems that it's only through GPG-Agent which > SCDaemon could get such information from user. And, GPG-Agent could > cache information of user interaction to stop asking user every time. Hmmm, that might be possible but I still don't like it. > NOTE: There are cases when user doesn't want to use the card > reader's keypad. For example, his PIN includes characters not > available by the reader's keypad. --disable-pinpad comes hadny in this case. The case to too rare to annoy a user with a prompt on whether to use the pinpad. However, we can put an URL into the "please enter your pin at pinpad" pop up messages so that the user will be able to find out what to do in cases he has not only digits in his PIN. I consider a URL better than a fixed text due to getext issues and an easier way to update this information. > (A) User specifies to force keypad input for the card. > > (B) GnuPG knows the card reader supports variable length input. > > (C) GnuPG knows the length of PIN. > > Then GnuPG can skip the step (1) when (A && (B || C)) is true. Right. We already have a similar switch statement in scd for (B) (when using the internal CCI driver). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From tanguy.herrmann at gmail.com Wed Jan 9 12:07:48 2013 From: tanguy.herrmann at gmail.com (Tanguy Herrmann) Date: Wed, 9 Jan 2013 12:07:48 +0100 Subject: A wiki for GnuPG and related topics? In-Reply-To: <877gnq9be2.fsf@vigenere.g10code.de> References: <201212211230.48404.bernhard@intevation.de> <50E933C1.6020501@tgries.de> <4424100.ys11hUaI1H@kymo.gruen> <877gnq9be2.fsf@vigenere.g10code.de> Message-ID: How about a git based wiki ? Like gollum who can use different markups. https://github.com/mojombo/gollum-demo/blob/master/orgmode.org With some interface to write to it for the non-techie people like http://prose.io/about.html it could be nice but require a little work. On Sun, Jan 6, 2013 at 11:47 PM, Werner Koch wrote: > On Sun, 6 Jan 2013 20:02, bernhard at intevation.de said: > > > Werner: What are you preferances for place of hosting, wiki software and > > such? > > A wiki should use org-mode markup - everything else is just an annoyance > (to me) ;-). > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian at quelltextlich.at Wed Jan 9 14:09:24 2013 From: christian at quelltextlich.at (Christian Aistleitner) Date: Wed, 9 Jan 2013 14:09:24 +0100 Subject: Supporting fixed length keypad input In-Reply-To: <87wqvm4smu.fsf@vigenere.g10code.de> References: <1357633878.10080.3.camel@cfw2.gniibe.org> <87obgz6853.fsf@vigenere.g10code.de> <1357698164.2912.1.camel@cfw2.gniibe.org> <87wqvm4smu.fsf@vigenere.g10code.de> Message-ID: <20130109130924.GA32142@quelltextlich.at> Hello, On Wed, Jan 09, 2013 at 10:23:21AM +0100, Werner Koch wrote: > However, we > can put an URL into the "please enter your pin at pinpad" pop up > messages so that the user will be able to find out what to do in cases > he has not only digits in his PIN. I consider a URL better than a fixed > text due to getext issues and an easier way to update this information. gettext comes with problems. Yes. But from a usability perspective, I do not like URLs too much. Consider using GnuPG in places where there simply is no internet available. Additionally, whether it does or does not make sense in their scenario, some people are instructing others to unplug their computers from the internet when doing OpenPGP stuff or to use a separate unconnected computer. Presenting those users with an URL is somewhat suboptimal. So even if you choose provide an URL, please also provide a short textual description of the hint for offline users. So for example what about unconditionally attaching a hint like If your PIN contains characters that are not present on your Keypad, pass the --disable-keypad option to scdaemon to enter the PIN using your computer's keyboard. . This should give users enough clues on how to proceed and to find relevant information in man-pages, help files (or even using their preferred search engine). Best regards, Christian -- ---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ---- Companies' registry: 360296y in Linz Christian Aistleitner Gruendbergstrasze 65a Email: christian at quelltextlich.at 4040 Linz, Austria Phone: +43 732 / 26 95 63 Fax: +43 732 / 26 95 63 Homepage: http://quelltextlich.at/ --------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From wk at gnupg.org Wed Jan 9 16:23:16 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 09 Jan 2013 16:23:16 +0100 Subject: Supporting fixed length keypad input In-Reply-To: <20130109130924.GA32142@quelltextlich.at> (Christian Aistleitner's message of "Wed, 9 Jan 2013 14:09:24 +0100") References: <1357633878.10080.3.camel@cfw2.gniibe.org> <87obgz6853.fsf@vigenere.g10code.de> <1357698164.2912.1.camel@cfw2.gniibe.org> <87wqvm4smu.fsf@vigenere.g10code.de> <20130109130924.GA32142@quelltextlich.at> Message-ID: <87hamq4byz.fsf@vigenere.g10code.de> On Wed, 9 Jan 2013 14:09, christian at quelltextlich.at said: > So even if you choose provide an URL, please also provide a short > textual description of the hint for offline users. So for example what Sure, a brief hint is required in addition to an URL. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Thu Jan 10 02:03:27 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 10 Jan 2013 10:03:27 +0900 Subject: Supporting fixed length keypad input In-Reply-To: <87wqvm4smu.fsf@vigenere.g10code.de> References: <1357633878.10080.3.camel@cfw2.gniibe.org> <87obgz6853.fsf@vigenere.g10code.de> <1357698164.2912.1.camel@cfw2.gniibe.org> <87wqvm4smu.fsf@vigenere.g10code.de> Message-ID: <1357779807.2924.1.camel@cfw2.gniibe.org> On 2013-01-09 at 10:23 +0100, Werner Koch wrote: > I don't consider this a real problem. The minimum length is anyway 6 > and thus there is not much of an advantage to notice that a larger PIN > length. We have at max 6 tries. OK. I will consider to support getting/putting user's preference from the login-data DO. > > I meant two things. It seems that it's only through GPG-Agent which > > SCDaemon could get such information from user. And, GPG-Agent could > > cache information of user interaction to stop asking user every time. > > Hmmm, that might be possible but I still don't like it. Perhaps, I had thought over-engineered thing, which would be unnecessary. This particular idea of mine came when I looked your commit of the following: commit b817ae7df947093384a25797999a9aa187e20f9c Author: Werner Koch Date: Tue Feb 7 14:17:33 2012 +0100 agent: Add pin length field to the shadowed private key format. I thought that you had intended to cache PIN length information together with card S/N in user's shadowed secret key, under control of GPG-Agent. Yes, simpler is better. I won't implement the caching by GPG-Agent. I will just implement proxy things by GPG-Agent from SCDaemon to pinentry/gpg, only when needed. > > NOTE: There are cases when user doesn't want to use the card > > reader's keypad. For example, his PIN includes characters not > > available by the reader's keypad. > > --disable-pinpad comes hadny in this case. The case to too rare to > annoy a user with a prompt on whether to use the pinpad. However, we > can put an URL into the "please enter your pin at pinpad" pop up > messages so that the user will be able to find out what to do in cases > he has not only digits in his PIN. I consider a URL better than a fixed > text due to getext issues and an easier way to update this information. Currently, it is SCDaemon which has "--disable-keypad" option. I think that it is an option for a card reader, not for particular card usage. When user knows his card reader doesn't support pinpad input well, he will use this option to stop the card reader's feature. Once it is disabled, a user needs to restart SCDaemon to enable use of keypad. I think that we need an option for gpg to enable/disable use of keypad for particular card usage. SCDaemon would inquire this option to gpg through GPG-Agent. Or, gpg would inform SCDaemon through GPG-Agent. BTW, we need to decide wording for "keypad" or "pinpad". I don't have any preference. I tend to use "keypad" because there are functions implemented with _keypad suffix, but "pinpad" would be better as it looks more common word. -- From gniibe at fsij.org Thu Jan 10 05:55:01 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 10 Jan 2013 13:55:01 +0900 Subject: Supporting fixed length keypad input In-Reply-To: <1357779807.2924.1.camel@cfw2.gniibe.org> References: <1357633878.10080.3.camel@cfw2.gniibe.org> <87obgz6853.fsf@vigenere.g10code.de> <1357698164.2912.1.camel@cfw2.gniibe.org> <87wqvm4smu.fsf@vigenere.g10code.de> <1357779807.2924.1.camel@cfw2.gniibe.org> Message-ID: <1357793701.2924.3.camel@cfw2.gniibe.org> I reconsider again. Asking user by pinentry (if using keypad and length of PIN) is good in theory. But, such a pop-up dialog would be not only annoying but also not-easy-to-use. On 2013-01-10 at 10:03 +0900, NIIBE Yutaka wrote: > I think that we need an option for gpg to enable/disable use of keypad > for particular card usage. SCDaemon would inquire this option to gpg > through GPG-Agent. Or, gpg would inform SCDaemon through GPG-Agent. No, this is not a solution for all cases. Only it works for gpg. There is a important case of SSH authentication through GPG-Agent, which cannot be solved by the solution above. Scute is another case. Thus, I think that getting user's preference from card (the login-data DO) would be only a way to handle this. The flag would be: None: Don't use keypad 0: Use variable length input, if keypad is available by reader, and the feature is supported N,M: Use fixed length input, if keypad is available by reader N for user PIN, M for admin PIN. -- From gniibe at fsij.org Thu Jan 10 09:00:13 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 10 Jan 2013 17:00:13 +0900 Subject: Supporting fixed length keypad input In-Reply-To: <1357793701.2924.3.camel@cfw2.gniibe.org> References: <1357633878.10080.3.camel@cfw2.gniibe.org> <87obgz6853.fsf@vigenere.g10code.de> <1357698164.2912.1.camel@cfw2.gniibe.org> <87wqvm4smu.fsf@vigenere.g10code.de> <1357779807.2924.1.camel@cfw2.gniibe.org> <1357793701.2924.3.camel@cfw2.gniibe.org> Message-ID: <1357804813.2924.4.camel@cfw2.gniibe.org> On 2013-01-10 at 13:55 +0900, NIIBE Yutaka wrote: > Thus, I think that getting user's preference from card (the login-data DO) > would be only a way to handle this. > > The flag would be: > > None: Don't use keypad > 0: Use variable length input, > if keypad is available by reader, and the feature is supported > N,M: Use fixed length input, if keypad is available by reader > N for user PIN, M for admin PIN. I am testing the following modification in scd-work branch. It works for me with GemPC Pinpad reader. After I put DO like this: Login data .......: gniibe\n\x14P=6,8\n Pinpad input works fine, both of user and admin PIN. diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index dcc3120..1188770 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -191,6 +191,15 @@ struct app_local_s { unsigned int def_chv2:1; /* Use 123456 for CHV2. */ } flags; + /* Keypad request specified on card. */ + struct + { + unsigned int specified:1; + unsigned int varlen:1; + int fixedlen_user; + int fixedlen_admin; + } keypad; + struct { unsigned int n_bits; /* Size of the modulus in bits. The rest @@ -581,17 +590,23 @@ count_bits (const unsigned char *a, size_t len) Everything up to a LF is considered a mailbox or account name. If the first LF is followed by DC4 (0x14) control sequence are expected up to the next LF. Control sequences are separated by FS - (0x18) and consist of key=value pairs. There is one key defined: + (0x18) and consist of key=value pairs. There are two keys defined: F= - Were FLAGS is a plain hexadecimal number representing flag values. + Where FLAGS is a plain hexadecimal number representing flag values. The lsb is here the rightmost bit. Defined flags bits are: Bit 0 = CHV1 and CHV2 are not syncronized Bit 1 = CHV2 has been been set to the default PIN of "123456" (this implies that bit 0 is also set). + P= + + Where KEYPAD_REQUEST is 0 or a pair of two integers: ,. + 0 means use keypad with variable length input. , means use + keypad with fixed length input. N for user PIN, M for admin PIN. + */ static void parse_login_data (app_t app) @@ -603,6 +618,10 @@ parse_login_data (app_t app) /* Set defaults. */ app->app_local->flags.no_sync = 0; app->app_local->flags.def_chv2 = 0; + app->app_local->keypad.specified = 0; + app->app_local->keypad.varlen = 0; + app->app_local->keypad.fixedlen_user = 6; + app->app_local->keypad.fixedlen_admin = 8; /* Read the DO. */ relptr = get_one_do (app, 0x005E, &buffer, &buflen, NULL); @@ -628,11 +647,56 @@ parse_login_data (app_t app) any leading digits but bail out on invalid characters. */ for (p=buffer+2, len = buflen-2; len && hexdigitp (p); p++, len--) lastdig = xtoi_1 (p); + buffer = p; + buflen = len; if (len && !(*p == '\n' || *p == '\x18')) goto next; /* Invalid characters in field. */ app->app_local->flags.no_sync = !!(lastdig & 1); app->app_local->flags.def_chv2 = (lastdig & 3) == 3; } + else if (buflen > 1 && *buffer == 'P' && buffer[1] == '=') + { + /* Keypad request control sequence found. */ + buffer += 2; + buflen -= 2; + + if (buflen) + { + if (*buffer == '0') + { + buffer++; + buflen--; + if (buflen && !(*buffer == '\n' || *buffer == '\x18')) + goto next; + app->app_local->keypad.specified = 1; + app->app_local->keypad.varlen = 1; + } + else if (digitp (buffer)) + { + char *q; + int n, m; + + n = strtol (buffer, &q, 10); + if (*q++ != ',' || !digitp (q)) + goto next; + m = strtol (q, &q, 10); + buffer = q; + if (buflen < ((unsigned char *)q - buffer)) + { + buflen = 0; + break; + } + else + buflen -= ((unsigned char *)q - buffer); + + if (buflen && !(*buffer == '\n' || *buffer == '\x18')) + goto next; + app->app_local->keypad.specified = 1; + app->app_local->keypad.fixedlen_user = n; + app->app_local->keypad.fixedlen_admin = m; + } + } + } next: for (; buflen && *buffer != '\x18'; buflen--, buffer++) if (*buffer == '\n') @@ -1470,6 +1534,37 @@ do_readcert (app_t app, const char *certid, } +/* Decide if we use keypad of reader for PIN input according to the + user preference on the card. Returns 0 if we use keypad, 1 otherwise. */ +static int +check_keypad_request (app_t app, pininfo_t *pininfo, int admin_pin) +{ + /* User specifies no preference on card, then, use pinentry. */ + if (app->app_local->keypad.specified == 0) + return 1; + + if (app->app_local->keypad.varlen) + if (pininfo->fixedlen == 0) + return 0; + else + /* On card, user specifies varlen but reader doesn't have the feature. */ + return 1; + else + { + if (admin_pin) + pininfo->fixedlen = app->app_local->keypad.fixedlen_admin; + else + pininfo->fixedlen = app->app_local->keypad.fixedlen_user; + + if (pininfo->fixedlen < pininfo->minlen + || pininfo->fixedlen > pininfo->maxlen) + return 1; + + return 0; + } +} + + /* Verify a CHV either using using the pinentry or if possibile by using a keypad. PINCB and PINCB_ARG describe the usual callback for the pinentry. CHVNO must be either 1 or 2. SIGCOUNT is only @@ -1537,7 +1632,8 @@ verify_a_chv (app_t app, if (!opt.disable_keypad - && !iso7816_check_keypad (app->slot, ISO7816_VERIFY, &pininfo) ) + && !iso7816_check_keypad (app->slot, ISO7816_VERIFY, &pininfo) + && !check_keypad_request (app, &pininfo, 0)) { /* The reader supports the verify command through the keypad. Note that the pincb appends a text to the prompt telling the @@ -1720,7 +1816,8 @@ verify_chv3 (app_t app, return rc; if (!opt.disable_keypad - && !iso7816_check_keypad (app->slot, ISO7816_VERIFY, &pininfo) ) + && !iso7816_check_keypad (app->slot, ISO7816_VERIFY, &pininfo) + && !check_keypad_request (app, &pininfo, 1)) { /* The reader supports the verify command through the keypad. */ rc = pincb (pincb_arg, prompt, NULL); @@ -1970,7 +2067,8 @@ do_change_pin (app_t app, ctrl_t ctrl, const char *chvnostr, if (!opt.disable_keypad && !iso7816_check_keypad (app->slot, - ISO7816_CHANGE_REFERENCE_DATA, &pininfo)) + ISO7816_CHANGE_REFERENCE_DATA, &pininfo) + && !check_keypad_request (app, &pininfo, chvno == 3)) use_keypad = 1; if (reset_mode) -- From gniibe at fsij.org Thu Jan 10 09:15:22 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 10 Jan 2013 17:15:22 +0900 Subject: Pinpad input problem for GemPC Pinpad reader Message-ID: <1357805722.2924.6.camel@cfw2.gniibe.org> It seems that GemPC Pinpad reader is single threaded. I need to configure SCDaemon with debug-disable-ticker option to use the reader reliably (or I need to input quickly). Here is a log when I don't configure debug-disable-ticker option. When we were in use of pinpad, apdu_get_status got timeout (after 5 seconds, the timeout value of bulk_out). See usb_bulk_write failed: -110. 2013-01-10 16:23:20 scdaemon[31605] DBG: ccid-driver: PC_to_RDR_Secure: 2013-01-10 16:23:20 scdaemon[31605] DBG: ccid-driver: dwLength ..........: 28 2013-01-10 16:23:20 scdaemon[31605] DBG: ccid-driver: bSlot .............: 0 2013-01-10 16:23:20 scdaemon[31605] DBG: ccid-driver: bSeq ..............: 178 2013-01-10 16:23:20 scdaemon[31605] DBG: ccid-driver: bBMI ..............: 0x00 2013-01-10 16:23:20 scdaemon[31605] DBG: ccid-driver: wLevelParameter ...: 0x0000 2013-01-10 16:23:20 scdaemon[31605] DBG: ccid-driver: [0010] 00 00 82 08 00 08 2013-01-10 16:23:20 scdaemon[31605] DBG: ccid-driver: [0016] 04 02 01 09 04 00 00 00 0D 00 20 00 83 08 FF FF 2013-01-10 16:23:20 scdaemon[31605] DBG: ccid-driver: [0032] FF FF FF FF FF FF 2013-01-10 16:23:21 scdaemon[31605] DBG: enter: apdu_get_status: slot=0 hang=0 2013-01-10 16:23:24 scdaemon[31605] DBG: ccid-driver: time extension requested (80,2B) 2013-01-10 16:23:24 scdaemon[31605] DBG: ccid-driver: time extension requested (80,2B) 2013-01-10 16:23:25 scdaemon[31605] DBG: ccid-driver: time extension requested (80,2B) 2013-01-10 16:23:26 scdaemon[31605] DBG: ccid-driver: usb_bulk_write failed: -110 2013-01-10 16:23:26 scdaemon[31605] DBG: leave: apdu_get_status => sw=0x1000a status=7 changecnt=5 2013-01-10 16:23:26 scdaemon[31605] DBG: chan_8 <- SERIALNO 2013-01-10 16:23:26 scdaemon[31605] DBG: chan_8 -> S SERIALNO D2760001240102000005000010AF0000 0 2013-01-10 16:23:26 scdaemon[31605] DBG: chan_8 -> OK 2013-01-10 16:23:26 scdaemon[31605] DBG: chan_8 <- LEARN --force 2013-01-10 16:23:26 scdaemon[31605] DBG: chan_8 -> S SERIALNO D2760001240102000005000010AF0000 0 2013-01-10 16:23:26 scdaemon[31605] DBG: chan_8 -> S APPTYPE OPENPGP 2013-01-10 16:23:26 scdaemon[31605] DBG: ccid-driver: time extension requested (80,2B) 2013-01-10 16:23:26 scdaemon[31605] DBG: enter: apdu_get_status: slot=0 hang=0 2013-01-10 16:23:26 scdaemon[31605] DBG: ccid-driver: time extension requested (80,2B) 2013-01-10 16:23:27 scdaemon[31605] DBG: ccid-driver: time extension requested (80,2B) 2013-01-10 16:23:27 scdaemon[31605] DBG: ccid-driver: time extension requested (80,2B) 2013-01-10 16:23:29 scdaemon[31605] DBG: ccid-driver: time extension requested (80,2B) 2013-01-10 16:23:31 scdaemon[31605] DBG: ccid-driver: time extension requested (80,0D) 2013-01-10 16:23:31 scdaemon[31605] DBG: ccid-driver: RDR_to_PC_DataBlock: 2013-01-10 16:23:31 scdaemon[31605] DBG: ccid-driver: dwLength ..........: 6 2013-01-10 16:23:31 scdaemon[31605] DBG: ccid-driver: bSlot .............: 0 2013-01-10 16:23:31 scdaemon[31605] DBG: ccid-driver: bSeq ..............: 178 2013-01-10 16:23:31 scdaemon[31605] DBG: ccid-driver: bStatus ...........: 0 2013-01-10 16:23:31 scdaemon[31605] DBG: ccid-driver: [0010] 00 00 02 90 00 92 2013-01-10 16:23:31 scdaemon[31605] DBG: leave: apdu_get_status => sw=0x0 status=7 changecnt=6 2013-01-10 16:23:31 scdaemon[31605] updating reader 0 (0) status: 0x0007->0x0007 (5->6) -- From wk at gnupg.org Thu Jan 10 09:31:14 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 10 Jan 2013 09:31:14 +0100 Subject: Supporting fixed length keypad input In-Reply-To: <1357779807.2924.1.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Thu, 10 Jan 2013 10:03:27 +0900") References: <1357633878.10080.3.camel@cfw2.gniibe.org> <87obgz6853.fsf@vigenere.g10code.de> <1357698164.2912.1.camel@cfw2.gniibe.org> <87wqvm4smu.fsf@vigenere.g10code.de> <1357779807.2924.1.camel@cfw2.gniibe.org> Message-ID: <87lic130dp.fsf@vigenere.g10code.de> On Thu, 10 Jan 2013 02:03, gniibe at fsij.org said: > agent: Add pin length field to the shadowed private key format. > > I thought that you had intended to cache PIN length information > together with card S/N in user's shadowed secret key, under control > of GPG-Agent. Sorry, I can't remember why I implemented that. > I think that we need an option for gpg to enable/disable use of keypad > for particular card usage. SCDaemon would inquire this option to gpg Note that we use smartcards also with gpgsm. > have any preference. I tend to use "keypad" because there are > functions implemented with _keypad suffix, but "pinpad" would > be better as it looks more common word. I think pinpad is better. Let's rename the fucntions. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Jan 10 09:36:18 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 10 Jan 2013 09:36:18 +0100 Subject: Supporting fixed length keypad input In-Reply-To: <1357793701.2924.3.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Thu, 10 Jan 2013 13:55:01 +0900") References: <1357633878.10080.3.camel@cfw2.gniibe.org> <87obgz6853.fsf@vigenere.g10code.de> <1357698164.2912.1.camel@cfw2.gniibe.org> <87wqvm4smu.fsf@vigenere.g10code.de> <1357779807.2924.1.camel@cfw2.gniibe.org> <1357793701.2924.3.camel@cfw2.gniibe.org> Message-ID: <87hamp3059.fsf@vigenere.g10code.de> On Thu, 10 Jan 2013 05:55, gniibe at fsij.org said: > Thus, I think that getting user's preference from card (the login-data DO) > would be only a way to handle this. Which works only with the OpenPGP card. But I think this is acceptable. > The flag would be: > > None: Don't use keypad What about: Use keypad if possible. This way it is backward compatible to the readers we already support. > 0: Use variable length input, > if keypad is available by reader, and the feature is > supported If we do it as I sugeste above, we may want to use 't' for this and '0' to disable the keypad (or use ("disable")). > N,M: Use fixed length input, if keypad is available by reader > N for user PIN, M for admin PIN. Makes sense. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From christian at quelltextlich.at Thu Jan 10 09:46:02 2013 From: christian at quelltextlich.at (Christian Aistleitner) Date: Thu, 10 Jan 2013 09:46:02 +0100 Subject: Supporting fixed length keypad input In-Reply-To: <1357779807.2924.1.camel@cfw2.gniibe.org> References: <1357633878.10080.3.camel@cfw2.gniibe.org> <87obgz6853.fsf@vigenere.g10code.de> <1357698164.2912.1.camel@cfw2.gniibe.org> <87wqvm4smu.fsf@vigenere.g10code.de> <1357779807.2924.1.camel@cfw2.gniibe.org> Message-ID: <20130110084602.GA18602@quelltextlich.at> Hello, On Thu, Jan 10, 2013 at 10:03:27AM +0900, NIIBE Yutaka wrote: > BTW, we need to decide wording for "keypad" or "pinpad". :-) > I don't > have any preference. I tend to use "keypad" because there are > functions implemented with _keypad suffix, but "pinpad" would > be better as it looks more common word. In the X11 world, "keypad" is typically used to refer to the right-most part of common European keyboards [1]. Hence, the use of "keypad" in the GnuPG world has always been confusing for me, eventhough user visible messages typically use ?reader's keypad? which somewhat helps to disambiguate. To me ?pinpad? is more natural. After all it's used to enter the pin. Best regards, Christian P.S.: For whatever that is worth, but when comparing http://en.wikipedia.org/wiki/Keypad to http://en.wikipedia.org/wiki/Pinpad it also seems, we'd rather want to convey the meaning of the ?pinpad? article. [1] http://en.wikipedia.org/wiki/File:Numpad.svg -- ---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ---- Companies' registry: 360296y in Linz Christian Aistleitner Gruendbergstrasze 65a Email: christian at quelltextlich.at 4040 Linz, Austria Phone: +43 732 / 26 95 63 Fax: +43 732 / 26 95 63 Homepage: http://quelltextlich.at/ --------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From achim at pietig.com Thu Jan 10 09:03:01 2013 From: achim at pietig.com (Achim Pietig) Date: Thu, 10 Jan 2013 09:03:01 +0100 Subject: Supporting fixed length keypad input In-Reply-To: <1357779807.2924.1.camel@cfw2.gniibe.org> References: <1357633878.10080.3.camel@cfw2.gniibe.org> <87obgz6853.fsf@vigenere.g10code.de> <1357698164.2912.1.camel@cfw2.gniibe.org> <87wqvm4smu.fsf@vigenere.g10code.de> <1357779807.2924.1.camel@cfw2.gniibe.org> Message-ID: <50EE75B5.3090009@pietig.com> Hi, some remarks in the text below: Am 10.01.2013 02:03, schrieb NIIBE Yutaka: > On 2013-01-09 at 10:23 +0100, Werner Koch wrote: >> I don't consider this a real problem. The minimum length is anyway 6 >> and thus there is not much of an advantage to notice that a larger PIN >> length. We have at max 6 tries. > You have only 3 tries for each PIN/password. > OK. I will consider to support getting/putting user's preference from > the login-data DO. > Login-Data is an ISO definied data object (7816-6). It should not contain other information than defined by ISO, so first check if this information is possible there. >>> I meant two things. It seems that it's only through GPG-Agent which >>> SCDaemon could get such information from user. And, GPG-Agent could >>> cache information of user interaction to stop asking user every time. >> >> Hmmm, that might be possible but I still don't like it. > > Perhaps, I had thought over-engineered thing, which would be > unnecessary. This particular idea of mine came when I looked your > commit of the following: > > commit b817ae7df947093384a25797999a9aa187e20f9c > Author: Werner Koch > Date: Tue Feb 7 14:17:33 2012 +0100 > > agent: Add pin length field to the shadowed private key format. > > I thought that you had intended to cache PIN length information > together with card S/N in user's shadowed secret key, under control > of GPG-Agent. > > Yes, simpler is better. I won't implement the caching by GPG-Agent. > I will just implement proxy things by GPG-Agent from SCDaemon to > pinentry/gpg, only when needed. > >>> NOTE: There are cases when user doesn't want to use the card >>> reader's keypad. For example, his PIN includes characters not >>> available by the reader's keypad. >> >> --disable-pinpad comes hadny in this case. The case to too rare to >> annoy a user with a prompt on whether to use the pinpad. However, we >> can put an URL into the "please enter your pin at pinpad" pop up >> messages so that the user will be able to find out what to do in cases >> he has not only digits in his PIN. I consider a URL better than a fixed >> text due to getext issues and an easier way to update this information. > > Currently, it is SCDaemon which has "--disable-keypad" option. I > think that it is an option for a card reader, not for particular card > usage. When user knows his card reader doesn't support pinpad input > well, he will use this option to stop the card reader's feature. Once > it is disabled, a user needs to restart SCDaemon to enable use of > keypad. > > I think that we need an option for gpg to enable/disable use of keypad > for particular card usage. SCDaemon would inquire this option to gpg > through GPG-Agent. Or, gpg would inform SCDaemon through GPG-Agent. > > BTW, we need to decide wording for "keypad" or "pinpad". I don't > have any preference. I tend to use "keypad" because there are > functions implemented with _keypad suffix, but "pinpad" would > be better as it looks more common word. > "pinpad" is the most common word in standards. Generell: If support for "old" readers with fixed length input is requirerd, I prefere a local var (e. g. gpgconf) with the fixed length preferred by the user. If the var is 0 or not defined, the min-max length should be taken from the card. The var may be evaluated by pinentry. If the password is defined by a keyboard, --disable-pinpad may be useful. All this affects the local environment only. Actual there are 3 standards for readers with PIN-pad, all support var-lenth-pins, so older readers will be obsolet soon. If you want to support this old items anyway, then keep it simple... It makes no sence to me to find a solution with new information in card or servers etc. to make this run at any pin-pad - standard compliant pinpads will run with min-max values! Regards, Achim From bernhard at intevation.de Thu Jan 10 14:48:02 2013 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 10 Jan 2013 14:48:02 +0100 Subject: A wiki for GnuPG and related topics? In-Reply-To: <50EB3BA2.6040109@fifthhorseman.net> References: <201212211230.48404.bernhard@intevation.de> <2422242.x1ElMk8xmP@kymo.gruen> <50EB3BA2.6040109@fifthhorseman.net> Message-ID: <201301101448.03750.bernhard@intevation.de> Am Montag, 7. Januar 2013 22:18:26 schrieb Daniel Kahn Gillmor: > However, most people are busy people, and each new community that > they're asked to join and contribute to requires a time commitment. We already are a part of the GnuPG community. The question is: How to we maintain and deliver our documentation. And how do we coordinate development topics that need writeups over a longer period? > Perhaps there is an existing community that people could contribute to? > For example: > https://we.riseup.net/debian/openpgp-best-practices This is one of the questions I would like to have answered. In my experience, the communities that are more local to a special distribution are not large enough to cover the complicated topic of using GnuPG correctly. So I believe we need to have a central place close to the core of GnuPG development. This also covers the use case to pre-dicuss development ideas. Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From gniibe at fsij.org Fri Jan 11 03:43:08 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 11 Jan 2013 11:43:08 +0900 Subject: Pinpad input problem for GemPC Pinpad reader In-Reply-To: <1357805722.2924.6.camel@cfw2.gniibe.org> References: <1357805722.2924.6.camel@cfw2.gniibe.org> Message-ID: <1357872188.2659.6.camel@cfw2.gniibe.org> On 2013-01-10 at 17:15 +0900, NIIBE Yutaka wrote: > It seems that GemPC Pinpad reader is single threaded. > > I need to configure SCDaemon with debug-disable-ticker option to > use the reader reliably (or I need to input quickly). > > Here is a log when I don't configure debug-disable-ticker option. > > When we were in use of pinpad, apdu_get_status got timeout (after 5 > seconds, the timeout value of bulk_out). See usb_bulk_write > failed: -110. This is due to a bug which doesn't hold lock for _keypad functions. Here is a patch to fix this (against master). Same should be applied to 2.0. OK to commit? diff --git a/scd/apdu.c b/scd/apdu.c index 68d4e99..278e08a 100644 --- a/scd/apdu.c +++ b/scd/apdu.c @@ -3429,9 +3429,18 @@ apdu_check_keypad (int slot, int command, int pin_mode, return SW_HOST_NO_DRIVER; if (reader_table[slot].check_keypad) - return reader_table[slot].check_keypad (slot, command, + { + int sw; + + if ((sw = lock_slot (slot))) + return sw; + + sw = reader_table[slot].check_keypad (slot, command, pin_mode, pinlen_min, pinlen_max, pin_padlen); + unlock_slot (slot); + return sw; + } else return SW_HOST_NOT_SUPPORTED; } @@ -3452,8 +3461,17 @@ apdu_keypad_verify (int slot, int class, int ins, int p0, int p1, int pin_mode, return SW_HOST_NO_DRIVER; if (reader_table[slot].keypad_verify) - return reader_table[slot].keypad_verify (slot, class, ins, p0, p1, + { + int sw; + + if ((sw = lock_slot (slot))) + return sw; + + sw = reader_table[slot].keypad_verify (slot, class, ins, p0, p1, &pininfo); + unlock_slot (slot); + return sw; + } else return SW_HOST_NOT_SUPPORTED; } @@ -3474,8 +3492,17 @@ apdu_keypad_modify (int slot, int class, int ins, int p0, int p1, int pin_mode, return SW_HOST_NO_DRIVER; if (reader_table[slot].keypad_modify) - return reader_table[slot].keypad_modify (slot, class, ins, p0, p1, + { + int sw; + + if ((sw = lock_slot (slot))) + return sw; + + sw = reader_table[slot].keypad_modify (slot, class, ins, p0, p1, &pininfo); + unlock_slot (slot); + return sw; + } else return SW_HOST_NOT_SUPPORTED; } -- From gniibe at fsij.org Fri Jan 11 06:19:36 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 11 Jan 2013 14:19:36 +0900 Subject: A wiki for GnuPG and related topics? In-Reply-To: <201301101448.03750.bernhard@intevation.de> References: <201212211230.48404.bernhard@intevation.de> <2422242.x1ElMk8xmP@kymo.gruen> <50EB3BA2.6040109@fifthhorseman.net> <201301101448.03750.bernhard@intevation.de> Message-ID: <1357881576.2659.10.camel@cfw2.gniibe.org> On 2013-01-10 at 14:48 +0100, Bernhard Reiter wrote: > So I believe we need to have a central place close to the core of > GnuPG development. This also covers the use case to pre-dicuss > development ideas. +1 I maintain a page at wiki.debian.org: http://wiki.debian.org/GnuPG/CCID_Driver That's because I want to use OpenPGP card, "out of the box" for my machines. Clearly, it is not Debian specific information, and the information is useful for other distributions. If I could express my own preference, I don't want to register more passwords for network services. It would be good, if the wiki will support OpenID or OAuth. -- From gniibe at fsij.org Fri Jan 11 06:32:49 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 11 Jan 2013 14:32:49 +0900 Subject: Pinpad input problem for GemPC Pinpad reader In-Reply-To: <1357872188.2659.6.camel@cfw2.gniibe.org> References: <1357805722.2924.6.camel@cfw2.gniibe.org> <1357872188.2659.6.camel@cfw2.gniibe.org> Message-ID: <1357882369.2659.11.camel@cfw2.gniibe.org> On 2013-01-11 at 11:43 +0900, NIIBE Yutaka wrote: > This is due to a bug which doesn't hold lock for _keypad functions. > > Here is a patch to fix this (against master). Same should be applied > to 2.0. > > OK to commit? Sorry, I accidentally pushed this change to master branch without confirmation, when I pushed scd-work branch. If this change is not good I will revert. If not, I'd like to apply this to 2.0, too. -- From wk at gnupg.org Fri Jan 11 14:12:44 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 11 Jan 2013 14:12:44 +0100 Subject: A wiki for GnuPG and related topics? In-Reply-To: <1357881576.2659.10.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Fri, 11 Jan 2013 14:19:36 +0900") References: <201212211230.48404.bernhard@intevation.de> <2422242.x1ElMk8xmP@kymo.gruen> <50EB3BA2.6040109@fifthhorseman.net> <201301101448.03750.bernhard@intevation.de> <1357881576.2659.10.camel@cfw2.gniibe.org> Message-ID: <87bocvx3qr.fsf@vigenere.g10code.de> On Fri, 11 Jan 2013 06:19, gniibe at fsij.org said: > machines. Clearly, it is not Debian specific information, and the > information is useful for other distributions. Why not keep using that wiki instead of adding just another one? Debian is anyway my primary platform. Another advantage is that I won't get complains from the FSF towers about _mentioning_ non-free software (e.g. PGP). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Jan 11 17:49:08 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 11 Jan 2013 17:49:08 +0100 Subject: Are we ready for 1.4.14? Message-ID: <87k3rjvf5n.fsf@vigenere.g10code.de> Hi! Due to 2 bugs (IDEA on big-endian boxes and keysigs indicating the wrong hash algorithm), we need to do 1.4.14 soon. Is there anything important missing from 1.4.13? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dshaw at jabberwocky.com Fri Jan 11 22:51:57 2013 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 11 Jan 2013 16:51:57 -0500 Subject: Are we ready for 1.4.14? In-Reply-To: <87k3rjvf5n.fsf@vigenere.g10code.de> References: <87k3rjvf5n.fsf@vigenere.g10code.de> Message-ID: On Jan 11, 2013, at 11:49 AM, Werner Koch wrote: > Hi! > > Due to 2 bugs (IDEA on big-endian boxes and keysigs indicating the wrong > hash algorithm), we need to do 1.4.14 soon. Is there anything important > missing from 1.4.13? Has anyone tried the fixed SRV + https + SNI code? It worked for me, but it would be better to have more than one person test it out. David From bernhard at intevation.de Sat Jan 12 21:43:27 2013 From: bernhard at intevation.de (Bernhard Reiter) Date: Sat, 12 Jan 2013 21:43:27 +0100 Subject: A wiki for GnuPG and related topics? In-Reply-To: <87bocvx3qr.fsf@vigenere.g10code.de> References: <201212211230.48404.bernhard@intevation.de> <1357881576.2659.10.camel@cfw2.gniibe.org> <87bocvx3qr.fsf@vigenere.g10code.de> Message-ID: <1835181.0EAeyjm3X2@kymo.gruen> Am Freitag, 11. Januar 2013, 14:12:44 schrieb Werner Koch: > Why not keep using that wiki instead of adding just another one? Debian > is anyway my primary platform. It is debian specific and we should really try to get GnuPG configured correctly for other platforms as well. As the purpose of GnuPG is to community with others, we have to mention other software solutions as well, including proprietary ones. -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From dkg at fifthhorseman.net Sun Jan 13 05:39:44 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 12 Jan 2013 23:39:44 -0500 Subject: checking multiple signatures of different types (or different digests) Message-ID: <50F23A90.8090002@fifthhorseman.net> Thanks to Russ Allbery, i just learned that gpg can't verify multiple signatures unless all signatures use the same digest algorithm and signature scheme. http://www.eyrie.org/~eagle/journal/2013-01/011.html I have filed this as a bug on the tracker: https://bugs.g10code.com/gnupg/issue1462 --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From JPClizbe at tx.rr.com Sun Jan 13 08:16:17 2013 From: JPClizbe at tx.rr.com (John Clizbe) Date: Sun, 13 Jan 2013 01:16:17 -0600 Subject: checking multiple signatures of different types (or different digests) In-Reply-To: <50F23A90.8090002@fifthhorseman.net> References: <50F23A90.8090002@fifthhorseman.net> Message-ID: <50F25F41.9020607@tx.rr.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1,SHA256 Daniel Kahn Gillmor wrote: Funny... as in odd. I do that very thing ALL the time. And it verifies just fine. See http://tech.groups.yahoo.com/group/PGP-Basics/message/34730 for an example. > -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1,SHA256 Verifies with: gpg: Signature made 11/24/2012 19:08:39 using RSA key ID 435BD034 gpg: please do a --check-trustdb gpg: Good signature from "John P. (FurrBear) Clizbe (FSFE Fellowship card) " gpg: Signature made 11/24/2012 19:08:39 using DSA key ID D6569825 gpg: Good signature from "John P. Clizbe (replaces 0x608D2A10) " SHA1/RSA & SHA256/DSA -- both are 2048 bit keys, but that's it for similarity. - -John I can post the source of the PGP-Basics message on gingerbear.net if the link doesn't work for you. - -- John P. Clizbe Inet: John (a) Gingerbear DAWT net SKS/Enigmail/PGP-EKP or: John ( @ ) Enigmail DAWT net FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (MingW32) Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl! Comment: Be part of the ?337 ECHELON -- Use Strong Encryption. Comment: It's YOUR right - for the time being. Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/ iQEcBAEBAgAGBQJQ8l8/AAoJECMTMVxDW9A09moH/j0P5iy3jKSansDCUaPVfhNO eHcXN1TF7/1m7yl4WThqYSjODiKsP8N9y1XjUYBF6fsubpMFmsrtcu/WA2QL2jGl kbLyFXVUsvEfriCsAsDIBEcIxUR/JQJ4DFfawk4ZBppxzua7SVe39Jg09cc6Rimj BDZOkxgD+wWR3k6KYLqmiFtKRC/NnlAGN22hDaRlIC5VGd6mRHZ1GbcgiWr45OVy NB+UOSIU6alXgzUdmsmNoHyQihGMpmH8TDSRStiNSbMxfcOkfziHIaZOYbiWA30m FLa9afif0vHIRDiTy8SIq/aWv4M5tecX8sS8V2iQNyU7WQANA/cfJFF3+Uy8wiKI XgQBEQgABgUCUPJfPwAKCRDrXhnz1laYJe2dAP9ecFuTDkA5rrJFTlinf3+0lWtY Q8fVUe0qggKODxNwEwD/SbYiML+oR5Txh70nTius0xj8TSaSW7tI9AXSApf9bPY= =a6nj -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Sun Jan 13 18:10:46 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 13 Jan 2013 12:10:46 -0500 Subject: checking multiple signatures of different types (or different digests) In-Reply-To: <50F25F41.9020607@tx.rr.com> References: <50F23A90.8090002@fifthhorseman.net> <50F25F41.9020607@tx.rr.com> Message-ID: <50F2EA96.5070209@fifthhorseman.net> Hi John-- On 01/13/2013 02:16 AM, John Clizbe wrote: > Funny... as in odd. I do that very thing ALL the time. And it verifies just > fine. See > http://tech.groups.yahoo.com/group/PGP-Basics/message/34730 for an example. thanks for the prompt followup! that link appears to require a login to view it. could you post the source elsewhere so i can try it myself? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Mon Jan 14 02:37:08 2013 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 13 Jan 2013 20:37:08 -0500 Subject: checking multiple signatures of different types (or different digests) In-Reply-To: <50F25F41.9020607@tx.rr.com> References: <50F23A90.8090002@fifthhorseman.net> <50F25F41.9020607@tx.rr.com> Message-ID: <6D16BB97-494D-4362-986F-AD23B3878335@jabberwocky.com> On Jan 13, 2013, at 2:16 AM, John Clizbe wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1,SHA256 > > Daniel Kahn Gillmor wrote: > > > Funny... as in odd. I do that very thing ALL the time. And it verifies just > fine. See > http://tech.groups.yahoo.com/group/PGP-Basics/message/34730 for an example. > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1,SHA256 This is why it works for you. You have a clearsigned message with multiple hashes and multiple signatures, which is a defined part of the spec. I'm not completely sure what Russ Allbery's code is doing, but I suspect it's multiple detached sigs in a single file. i.e.: cat thefile | gpg -u key1 --armor --detach-sign > my-sigs.asc cat thefile | gpg -u key2 --armor --detach-sign >> my-sigs.asc (Where key1 and key2 use different hashes) There is history to this, but the brief version is that this was never supported, and in fact GPG tells you it isn't supported ("gpg: WARNING: multiple signatures detected. Only the first will be checked."). I added the warning message way back in 2002/2003. It only allows this if both sigs are of the same class (i.e. both binary or both textmode) and the same hash. Now, none of this means it couldn't be added. We'd need to run multiple hash contexts, with one for each signature, and given how the file-of-sigs is currently processed that's not exactly trivial. Given that until now, nobody noticed the lack since 2003, I'm not sure that it's a common problem. David From bernhard at intevation.de Mon Jan 14 10:29:45 2013 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 14 Jan 2013 10:29:45 +0100 Subject: A wiki for GnuPG and related topics? In-Reply-To: <87k3rn6802.fsf@vigenere.g10code.de> References: <87k3rn6802.fsf@vigenere.g10code.de> Message-ID: <201301141029.46970.bernhard@intevation.de> Am Dienstag, 8. Januar 2013 15:53:49 schrieb Werner Koch: > On Tue, ?8 Jan 2013 10:00, avi.wiki at gmail.com said: > > could be made easier by the admins sending "invitations" to a list of the > > e-mails of users who are well known on this mailing list for starters. > > Or re-use the accounts from the bug tracker. ?Either by allowing the > mail confirmed /Provisional User/ roles or the admin granted /User/ > roles. I wonder if we should use the same accounts for issue tracker and wiki, sounds useful to me. So the wiki would need to authenticate against the roundup db. I guess with MoiMoin it should be possible to hack a low key solution. Volunteers? -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From folkert at vanheusden.com Mon Jan 14 11:18:24 2013 From: folkert at vanheusden.com (folkert) Date: Mon, 14 Jan 2013 11:18:24 +0100 Subject: gpgme & key signing Message-ID: <20130114101823.GK11271@belle.intranet.vanheusden.com> Hi, Any chance for key-signing functionality in GPGME? GPGME is really great: I succeeded in implementing code to sign a file in only half an hour! Works like a charm! Folkert van Heusden -- Curious about the inner workings of your car? Then check O2OO: it'll tell you all that there is to know about your car's engine! http://www.vanheusden.com/O2OO/ ---------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com From avi.wiki at gmail.com Mon Jan 14 13:16:58 2013 From: avi.wiki at gmail.com (Avi) Date: Mon, 14 Jan 2013 07:16:58 -0500 Subject: Are we ready for 1.4.14? Message-ID: > From: Werner Koch > To: gnupg-devel at gnupg.org > Cc: > Date: Fri, 11 Jan 2013 17:49:08 +0100 > Subject: Are we ready for 1.4.14? > Hi! > > Due to 2 bugs (IDEA on big-endian boxes and keysigs indicating the wrong > hash algorithm), we need to do 1.4.14 soon. Is there anything important > missing from 1.4.13? > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. Well, if you are /asking/...perhaps ECC? /ducks head :) ---- User:Avraham pub 3072D/F80E29F9 1/30/2009 Avi (Wikimedia-related key) Primary key fingerprint: 167C 063F 7981 A1F6 71EC ABAA 0D62 B019 F80E 29F9 From wk at gnupg.org Mon Jan 14 14:36:30 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 14 Jan 2013 14:36:30 +0100 Subject: gpgme & key signing In-Reply-To: <20130114101823.GK11271@belle.intranet.vanheusden.com> (folkert@vanheusden.com's message of "Mon, 14 Jan 2013 11:18:24 +0100") References: <20130114101823.GK11271@belle.intranet.vanheusden.com> Message-ID: <87zk0bubs1.fsf@vigenere.g10code.de> On Mon, 14 Jan 2013 11:18, folkert at vanheusden.com said: > Any chance for key-signing functionality in GPGME? Given that it is quite a common task for OpenPGP, we should consider to implement it. Would you mind to enter a feature request into the BTS so that we don't forget about it? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Jan 14 14:42:50 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 14 Jan 2013 14:42:50 +0100 Subject: Are we ready for 1.4.14? In-Reply-To: (Avi's message of "Mon, 14 Jan 2013 07:16:58 -0500") References: Message-ID: <87vcazubhh.fsf@vigenere.g10code.de> On Mon, 14 Jan 2013 13:16, avi.wiki at gmail.com said: > Well, if you are /asking/...perhaps ECC? > > /ducks head My ducks outside in the garden just started to cackle while frightening away such requests. Seriously we need to get 2.1 out before we can even think about adding ECC to 1.4. Maybe in a few years after ECC use has really taken off. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Tue Jan 15 03:36:53 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 15 Jan 2013 11:36:53 +0900 Subject: Supporting fixed length keypad input In-Reply-To: <50EE75B5.3090009@pietig.com> References: <1357633878.10080.3.camel@cfw2.gniibe.org> <87obgz6853.fsf@vigenere.g10code.de> <1357698164.2912.1.camel@cfw2.gniibe.org> <87wqvm4smu.fsf@vigenere.g10code.de> <1357779807.2924.1.camel@cfw2.gniibe.org> <50EE75B5.3090009@pietig.com> Message-ID: <1358217413.2667.6.camel@cfw2.gniibe.org> Thanks for your comments. My replies are by different order. On 2013-01-10 at 09:03 +0100, Achim Pietig wrote: > "pinpad" is the most common word in standards. I see. > If support for "old" readers with fixed length input is requirerd, I > prefere a local var (e. g. gpgconf) with the fixed length preferred > by the user. If the var is 0 or not defined, the min-max length > should be taken from the card. The var may be evaluated by pinentry. > If the password is defined by a keyboard, --disable-pinpad may be > useful. All this affects the local environment only. I understand the need for configuration on host PC (for card specific configuration). The issue is: how to implement this. IIUC, SCDaemon is the lower level driver which handles smartcard/token communication (perhaps, this understanding of mine would be wrong), and how to get card specific information is under discussion. > Actual there are 3 standards for readers with PIN-pad, all support > var-lenth-pins, so older readers will be obsolet soon. If you want > to support this old items anyway, then keep it simple... It makes > no sence to me to find a solution with new information in card or > servers etc. to make this run at any pin-pad - standard compliant > pinpads will run with min-max values! Could you please let me know the references for the standards? A vendor which I contacted last year claimed that the reader is standard compliant (even if it doesn't support variable length input). Well, I understand that fixed length input support should be special case. To summarize discussion, I'd like to propose the following for pinpad input. * Default is variable length pinpad input when reader supports the feature. * Use pinentry by keyboard on host PC, when reader doesn't supports the feature (including reader supports pinpad input but requires fixed length input). * Only when a user wants to do special thing, he needs to specify this. Special cases are: (1) Use pinentry by keyboard even with pinpad reader. (for cases when PIN has characters other than digits.) (2) Use fixed length input. > Login-Data is an ISO definied data object (7816-6). > It should not contain other information than defined by ISO, so > first check if this information is possible there. It says: Proprietary login data Referenced by tag '5E', this interindustry data element consists of login data with proprietary structures not specified in ISO/IEC 7816. -- From gniibe at fsij.org Tue Jan 15 04:06:22 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 15 Jan 2013 12:06:22 +0900 Subject: Popup_message_stop Message-ID: <1358219182.2667.8.camel@cfw2.gniibe.org> I am bitten by my own change of: commit f6251c0d0af92331388f5e9bcd1750cbadcaca8f Author: NIIBE Yutaka Date: Fri Dec 16 09:07:56 2011 +0900 Don't kill pinentry by SIGKILL but let it quit by SIGINT. * agent/call-pinentry.c (agent_popup_message_stop): To pinentry, send SIGINT (was: SIGKILL). The window of pinentry doesn't pop down, now. This change was done because of pinentry-curses. With pinentry-curses, when it is killed by SIGINT, terminal gets confused. I figured out that the problem here is signal mask. To handle signals, GPG-Agent has signal mask for SIGHUP, SIGUSR1, SIGUSR2, SIGINT and SIGTERM. Then, pinentry will be fork/exec-ed with this signal mask, and SIGINT will not be delivered because of this mask. We need to call pthread_atfork to unmask signals for child processes of GPG-Agent. I'm not sure where to implement unmasking signals. It should be GnuPG which calls pthread_atfork for 2.0 branch. But it's common things among applications, it would be npth_sigev_fini which calls pthread_atfork for master branch. -- From gniibe at fsij.org Mon Jan 21 04:56:12 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 21 Jan 2013 12:56:12 +0900 Subject: Pageant proxy to gpg-agent Message-ID: <1358740572.2679.2.camel@cfw2.gniibe.org> Hello, I am not a Windows user, but some people ask me using Gnuk Token on Windows for SSH access. Thus, I wrote a Python script which works as Pageant (Putty's agent). With this script, we can use authentication key on Gnuk Token for Putty. You can find it at: http://gitorious.org/gnuk/gnuk/blobs/master/tool/pageant_proxy_to_gpg.py To run, you need gpg_agent.py and sexp.py (at the same place). The script assumes GPG-Agent 2.0.18 or later (which supports "KEYINFO --list --data"), and RSA keysize of 2048-bit. This is a tentative solution. I think it is good for GPG-Agent to support this kind of native Windows IPC of Pageant. -- From gniibe at fsij.org Mon Jan 21 08:20:39 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 21 Jan 2013 16:20:39 +0900 Subject: Pageant proxy to gpg-agent In-Reply-To: <1358740572.2679.2.camel@cfw2.gniibe.org> References: <1358740572.2679.2.camel@cfw2.gniibe.org> Message-ID: <1358752839.30621.3.camel@cfw2.gniibe.org> On 2013-01-21 at 12:56 +0900, NIIBE Yutaka wrote: > With this script, we can use authentication key on Gnuk Token for > Putty. The script didn't use the channel of SSH-agent for GPG-Agent, since it doesn't work for me. Currently, it connect the original channel of GPG-Agent, and communicates with "KEYINFO", "READKEY", "SIGKEY", "SETHASH", and "PKSIGN" commands. This is a bug report SSH-agent channel doesn't work on Windows. (1) fopen with "wx" seems not to be supported on Windows At first, I didn't have the file "sshcontrol". It failed at agent/command-ssh.c:open_control_file. Then, I created an empty file. (2) When I sent a request of SSH2 REQUEST IDENTITIES, it failed. The output of log of GPG-Agent is like this: 2013-01-18 14:56:55 gpg-agent[3440] ssh request handler for request_identities (11) ready 2013-01-18 14:56:55 gpg-agent[3440] sending ssh response of length 311 2013-01-18 14:56:55 gpg-agent[3440] sending ssh error response I don't know what's happened here. Perhaps, nobody uses SSH-agent feature. * * * IIUC, OpenSSH on Windows uses Unix Socket Emulation on Cygwin. I looked through the code of Cygwin, and I realized that the way to implement Unix Socket Emulation is mostly same as GnuPG, but differs a bit. I think that it is good to run GnuPG's SSH-agent feature as compatible as OpenSSH on Windows (plus Pageant IPC). -- From wk at gnupg.org Mon Jan 21 10:06:18 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 21 Jan 2013 10:06:18 +0100 Subject: Pageant proxy to gpg-agent In-Reply-To: <1358752839.30621.3.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Mon, 21 Jan 2013 16:20:39 +0900") References: <1358740572.2679.2.camel@cfw2.gniibe.org> <1358752839.30621.3.camel@cfw2.gniibe.org> Message-ID: <87622qrjlh.fsf@vigenere.g10code.de> On Mon, 21 Jan 2013 08:20, gniibe at fsij.org said: > (1) fopen with "wx" seems not to be supported on Windows Yes, it is a GNU extension. IIRC, I replaced fopen by es_fopen while working on the Windows CE port. Thus 2.1 should have solved this portability problem. Shall we backport it? > (2) When I sent a request of SSH2 REQUEST IDENTITIES, it failed. The > output of log of GPG-Agent is like this: Are we talkig about 2.0 or 2.1? While supporting ECC in 2.1, I fixed a couple of flaws. > looked through the code of Cygwin, and I realized that the way to > implement Unix Socket Emulation is mostly same as GnuPG, but differs a > bit. I think that it is good to run GnuPG's SSH-agent feature as Cygwin is very different from native Windows. I don't know what Cygwin does (I have not looked at it for more than a decade) but GnuPG uses local TCP sockets along with a random nonce; thus there are a few extra bytes at the start of a connection. The reason to use TCP+random is that it allows to restrict connections to the localhost. All other Windows IPC mechanisms don't allow this or only with a lot of complex code. TCP is also mostly compatible to Unix domain sockets. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Tue Jan 22 07:33:04 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 22 Jan 2013 15:33:04 +0900 Subject: Pageant proxy to gpg-agent In-Reply-To: <87622qrjlh.fsf@vigenere.g10code.de> References: <1358740572.2679.2.camel@cfw2.gniibe.org> <1358752839.30621.3.camel@cfw2.gniibe.org> <87622qrjlh.fsf@vigenere.g10code.de> Message-ID: <1358836384.2678.2.camel@cfw2.gniibe.org> On 2013-01-21 at 10:06 +0100, Werner Koch wrote: > On Mon, 21 Jan 2013 08:20, gniibe at fsij.org said: > > > (1) fopen with "wx" seems not to be supported on Windows > > Yes, it is a GNU extension. IIRC, I replaced fopen by es_fopen while > working on the Windows CE port. Thus 2.1 should have solved this > portability problem. Shall we backport it? > > > (2) When I sent a request of SSH2 REQUEST IDENTITIES, it failed. The > > output of log of GPG-Agent is like this: > > Are we talkig about 2.0 or 2.1? While supporting ECC in 2.1, I fixed a > couple of flaws. I was talking about GnuPG 2.0.17 on Windows. I am using GPG4Win (2.1.1 beta). I think that it's good to backport the changes from 2.1 to 2.0. > > looked through the code of Cygwin, and I realized that the way to > > implement Unix Socket Emulation is mostly same as GnuPG, but differs a > > bit. I think that it is good to run GnuPG's SSH-agent feature as > > Cygwin is very different from native Windows. I don't know what Cygwin > does (I have not looked at it for more than a decade) but GnuPG uses > local TCP sockets along with a random nonce; thus there are a few extra > bytes at the start of a connection. The reason to use TCP+random is > that it allows to restrict connections to the localhost. Today, I did an experiment for SSH-agent-proxy (against Cygwin OpenSSH), and it worked for me. Cygwin's emulation is like this: (1) For AF_LOCAL socket, it creates a file with FILE_ATTRIBUTE_SYSTEM. The content format is: "!%d %c %08x-%08x-%08x-%08x\x00" %d for port number, %c for kind of socket (s for STREAM), and we have 16-byte random bytes for nonce. (2) It uses TCP, after connection of TCP sockets, client sends a nonce, server receives the nonce and check it. Server sends back to the nonce, and client receives it (I don't know the reason for this). Then, client sends credential information (pid, uid, gid) to server. Server receives it, and sends back its credential information to client. (3) After this initial transaction, communication goes as normal. I think that the support of Cygwin Unix Domain socket can be implemented as an enhancement of libassuan. Perhaps, it's just adding a flag (or functions) to support Cygwin compatible AF_LOCAL socket. -- From gniibe at fsij.org Thu Jan 24 05:22:29 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 24 Jan 2013 13:22:29 +0900 Subject: Popup_message_stop In-Reply-To: <1358219182.2667.8.camel@cfw2.gniibe.org> References: <1358219182.2667.8.camel@cfw2.gniibe.org> Message-ID: <1359001349.5224.4.camel@cfw2.gniibe.org> On 2013-01-15 at 12:06 +0900, NIIBE Yutaka wrote: > I am bitten by my own change of: > > commit f6251c0d0af92331388f5e9bcd1750cbadcaca8f > Author: NIIBE Yutaka > Date: Fri Dec 16 09:07:56 2011 +0900 > > Don't kill pinentry by SIGKILL but let it quit by SIGINT. > > * agent/call-pinentry.c (agent_popup_message_stop): To pinentry, send > SIGINT (was: SIGKILL). > > The window of pinentry doesn't pop down, now. > > This change was done because of pinentry-curses. With > pinentry-curses, when it is killed by SIGINT, terminal gets confused. > > I figured out that the problem here is signal mask. To handle > signals, GPG-Agent has signal mask for SIGHUP, SIGUSR1, SIGUSR2, > SIGINT and SIGTERM. Then, pinentry will be fork/exec-ed with this > signal mask, and SIGINT will not be delivered because of this mask. > > We need to call pthread_atfork to unmask signals for child processes > of GPG-Agent. > > I'm not sure where to implement unmasking signals. > > It should be GnuPG which calls pthread_atfork for 2.0 branch. But > it's common things among applications, it would be npth_sigev_fini > which calls pthread_atfork for master branch. Something like this. It works for me. diff --git a/src/npth-sigev.c b/src/npth-sigev.c index f1271d1..aab977e 100644 --- a/src/npth-sigev.c +++ b/src/npth-sigev.c @@ -126,6 +126,13 @@ npth_sigev_add (int signum) } +static void +restore_sigmask_for_child_process (void) +{ + pthread_sigmask (SIG_SETMASK, &sigev_unblock, NULL); +} + + /* Finish the list of watched signals. This starts to block them, too. */ void @@ -133,6 +140,7 @@ npth_sigev_fini (void) { /* Block the interesting signals. */ pthread_sigmask (SIG_SETMASK, &sigev_block, NULL); + pthread_atfork (NULL, NULL, restore_sigmask_for_child_process); } -- From gniibe at fsij.org Fri Jan 25 06:25:02 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 25 Jan 2013 14:25:02 +0900 Subject: Fix agent/call-pinentry.c (master) Message-ID: <1359091502.2940.10.camel@cfw2.gniibe.org> Hello, I found a minor bug in agent/call-pinentry.c (master branch). pth_join returns TRUE (1) on success. But npth_join (and pthread_join) returns 0 on success, and error number on error. I grep through the source code of GnuPG for npth_join, and this is the only part where fix is needed. I will commit&push to master. diff --git a/agent/call-pinentry.c b/agent/call-pinentry.c index c37831a..c6b6b52 100644 --- a/agent/call-pinentry.c +++ b/agent/call-pinentry.c @@ -1266,9 +1266,9 @@ agent_popup_message_stop (ctrl_t ctrl) /* Now wait for the thread to terminate. */ rc = npth_join (popup_tid, NULL); - if (!rc) + if (rc) log_debug ("agent_popup_message_stop: pth_join failed: %s\n", - strerror (errno)); + strerror (rc)); /* Thread IDs are opaque, but we try our best here by resetting it to the same content that a static global variable has. */ memset (&popup_tid, '\0', sizeof (popup_tid)); -- From lrn1986 at gmail.com Sat Jan 26 04:47:18 2013 From: lrn1986 at gmail.com (LRN) Date: Sat, 26 Jan 2013 07:47:18 +0400 Subject: W32 build fixes for gnupg-2.0.19 Message-ID: <510351C6.7050608@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Subj is attached. If you need patches against git master HEAD, just ask. 0001-fix-regex-test-on.mingw32.all.patch: NULL is defined in stddef.h by gcc. Include stddef.h. (regex.h here is provided by libgnurx. That might explain why it does not include stddef.h itself, while GNU Libc regex.h does (presumably, otherwise this test would have been failing for you too)). 0002-fix-stringhelp-on.mingw32.patch: First, it moves home_buffer assignment outside of the #ifdef, since the use of xstrdup() has nothing to do with PWD. Second, it adds W32-only code that will use USERPROFILE instead of HOME if HOME is not defined (not really necessary in MSys, but you can never be too careful). 0003-fix-tmpfile-on.mingw32.patch: OK, this one is _big_. Kind of. I don't know why (the original code looked sound enough), but previously gnupg_tmpfile() failed during `make check' (i.e. it tried to create a file 10 times, failed 10 times and returned ENOENT). I decided to replace it with a sane implementation that generates template randomly. Then i discovered that i can't link to libgcrypt, and that gnupg's minimal target W32 platform is W2000 (0x500), which means that CryptoAPI is not available at compile time. So i added runtime detection. Which is why things got so big. With these patches gnupg-2.0.19 compiled with MinGW/MSys, AND `make check' passes all tests successfully (i did test all 3 versions of the random generator). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRA1HFAAoJEOs4Jb6SI2Cwt/wH/R+OMnklEUYfdBoHiSorcft8 uddfKKhnV9gEnoG1gvdQBr8UX2zLSofvIGIvHy0Ah7MFRSTPnDrtn8KpmsaZN7Yd 2R9JpgxUbGlXLvpAAG9emoWgr0jrHGlwuJfPe3zUOAJNdN/H9xXMkalikCcnSW/Y sszKQXLwJ+pMXRATcgLdb0QqU79I3GlYy/VLU3doqVWdFZXnUrb+ELeq5aDx9Ty4 pHn2mvOOMzLwwav0J9YONeT2UfTNW8cNvvcLwKxTiqnOdO0KM/OWUs10Wq7aIHzi V1Kc6wo2AGtnk+4BcHegZd2adEhD3UH3/2x90xwXF0qrhE7DlQCfbX9RfthYXT4= =Ecxy -----END PGP SIGNATURE----- -------------- next part -------------- --- gnupg-2.0.19/configure.ac.orig 2013-01-26 04:55:46 +0400 +++ gnupg-2.0.19/configure.ac 2013-01-26 04:56:07 +0400 @@ -1173,6 +1173,7 @@ AC_TRY_RUN([ #include #include +#include main() { regex_t blah ; regmatch_t p; p.rm_eo = p.rm_eo; return regcomp(&blah, "foo.*bar", REG_NOSUB) || regexec (&blah, "foobar", 0, NULL, 0); }], gnupg_cv_regex_broken=no, gnupg_cv_regex_broken=yes, gnupg_cv_regex_broken=yes)) -------------- next part -------------- --- gnupg-2.0.19/jnlib/t-stringhelp.c.orig 2013-01-26 04:57:13 +0400 +++ gnupg-2.0.19/jnlib/t-stringhelp.c 2013-01-26 05:01:15 +0400 @@ -43,9 +43,9 @@ { char *home = getenv("HOME"); -#if defined(HAVE_GETPWUID) && defined(HAVE_PWD_H) if(home) home_buffer = xstrdup (home); +#if defined(HAVE_GETPWUID) && defined(HAVE_PWD_H) else { struct passwd *pwd; --- gnupg-2.0.19/jnlib/t-stringhelp.c.orig 2013-01-26 05:01:15 +0400 +++ gnupg-2.0.19/jnlib/t-stringhelp.c 2013-01-26 05:01:26 +0400 @@ -43,6 +43,10 @@ { char *home = getenv("HOME"); +#if defined(_WIN32) + if (NULL == home) + home = getenv ("USERPROFILE"); +#endif if(home) home_buffer = xstrdup (home); #if defined(HAVE_GETPWUID) && defined(HAVE_PWD_H) -------------- next part -------------- --- gnupg-2.0.19/common/sysutils.c.orig 2013-01-26 04:57:13 +0400 +++ gnupg-2.0.19/common/sysutils.c 2013-01-26 06:51:57 +0400 @@ -45,6 +45,7 @@ #ifdef HAVE_W32_SYSTEM # define WINVER 0x0500 /* Required for AllowSetForegroundWindow. */ # include +# include #endif #ifdef HAVE_PTH # include @@ -320,7 +321,131 @@ #endif } +#if defined(HAVE_W32_SYSTEM) +typedef ULONG HCRYPTPROV; +#define PROV_RSA_FULL 1 +#define CRYPT_VERIFYCONTEXT 0xF0000000 + +/* W32 version of gcry_randomize (). + If you ever decide to link libgommon to libgcrypt, use gcry_randomize() + instead. + + This function is not exactly thread-safe, as two threads calling + it simultaneously for the first time will both try to initialize random, + and things will get messy. + */ +void +w32_randomize (unsigned char *buffer, size_t length) +{ + static int initialized_random = 0; + static int use_nt_random = 0; + static int use_xp_random = 0; + /* This LoadLibrary madness is, basically, to be able to compile + * code for W2000 only (WINVER==0x500), but be able to use + * XP-and-newer API at runtime. + * If you ever bump minimally supported version to XP, + * then just use CryptoAPI directly (don't forget to #include ). + * In that case it is also possible to make it thread-safe - + * just obtain and release crypto provider context in every call. + */ + static HMODULE advapi32_dll = NULL; + static BOOL __stdcall (*Loaded_CryptGenRandom)(HCRYPTPROV hProv, DWORD dwLen, + BYTE *pbBuffer); + static BYTE __stdcall (*Loaded_RtlGenRandom)(PVOID RandomBuffer, + ULONG RandomBufferLength); + + BOOL b; + static HCRYPTPROV cryptoprov; + + int i; + if (!initialized_random) + { + OSVERSIONINFOEXA w32_ver; + w32_ver.dwOSVersionInfoSize = sizeof (w32_ver); + b = GetVersionExA ((LPOSVERSIONINFOA) &w32_ver); + if (b) + { + advapi32_dll = LoadLibrary ("Advapi32.dll"); + if (advapi32_dll) + { + char just_checking_that_it_works; + if (w32_ver.dwMajorVersion >= 5 && w32_ver.dwMinorVersion >= 1) + { + /* XP/2003 or newer */ + BOOL WINAPI (*Loaded_CryptAcquireContext) (HCRYPTPROV *phProv, + LPCTSTR pszContainer, LPCTSTR pszProvider, DWORD dwProvType, + DWORD dwFlags); + BOOL WINAPI (*Loaded_CryptReleaseContext) (HCRYPTPROV hProv, + DWORD dwFlags); + Loaded_CryptAcquireContext = GetProcAddress (advapi32_dll, + "CryptAcquireContextA"); + Loaded_CryptGenRandom = GetProcAddress (advapi32_dll, + "CryptGenRandom"); + Loaded_CryptReleaseContext = GetProcAddress (advapi32_dll, + "CryptReleaseContext"); + if (Loaded_CryptAcquireContext && Loaded_CryptGenRandom && + Loaded_CryptReleaseContext) + { + b = Loaded_CryptAcquireContext (&cryptoprov, NULL, NULL, + PROV_RSA_FULL, CRYPT_VERIFYCONTEXT); + if (b) + { + b = Loaded_CryptGenRandom (cryptoprov, 1, &just_checking_that_it_works); + if (b) + use_xp_random = 1; + /* And just as we can't free the library, we can't release the + * context. + */ + else + Loaded_CryptReleaseContext (cryptoprov, 0); + } + } + } + if (!(w32_ver.dwMajorVersion >= 5 && w32_ver.dwMinorVersion >= 1) || + !use_xp_random) + { + Loaded_RtlGenRandom = (BYTE __stdcall (*)(PVOID RandomBuffer, + ULONG RandomBufferLength)) GetProcAddress (advapi32_dll, + "SystemFunction036"); + if (Loaded_RtlGenRandom) + { + if (Loaded_RtlGenRandom (&just_checking_that_it_works, 1)) + use_nt_random = 1; + } + } + /* Since we don't have any cleanup hooks, we can't FreeLibrary(). + * OS will unload it for us on exit, so it's probably ok. + * The only case when we can cleanup is when we failed to get + * functions out of the library. + */ + if (!use_nt_random && !use_xp_random) + FreeLibrary (advapi32_dll); + } + } + /* Since we fall back to CRT random, initialize it now unconditionally */ + srand (time (NULL)); + initialized_random = 1; + } + if (use_xp_random) + { + if (Loaded_CryptGenRandom (cryptoprov, length, buffer)) + return; + use_xp_random = 0; + } + else if (use_nt_random) + { + if (Loaded_RtlGenRandom (buffer, length)) + return; + use_nt_random = 0; + } + if (!use_xp_random && !use_nt_random); + { + for (i = 0; i < length; i++) + buffer[i] = rand () % 256; + } +} +#endif /* Replacement for tmpfile(). This is required because the tmpfile function of Windows' runtime library is broken, insecure, ignores @@ -330,14 +454,13 @@ gnupg_tmpfile (void) { #ifdef HAVE_W32_SYSTEM - int attempts, n; + int n; char buffer[MAX_PATH+7+12+1]; char *name, *p; HANDLE file; - int pid = GetCurrentProcessId (); - unsigned int value; int i; SECURITY_ATTRIBUTES sec_attr; + DWORD w32_error; memset (&sec_attr, 0, sizeof sec_attr ); sec_attr.nLength = sizeof sec_attr; @@ -357,15 +480,31 @@ CreateDirectory (buffer, NULL); *p++ = '\\'; name = p; - for (attempts=0; attempts < 10; attempts++) + /* This might have problems: + 1) Lots of processes are calling tmpfile() with the same template, + thus exausting the namespace (this function will get slower and slower, + until finally there will be no free names). It will become unstuck once + a new name is available (i.e. some files are deleted). + Possible fix: add exponential Sleep() to prevent it from busylooping. Or + just go back to the old try-10-times-then-fail logic. Depends on + what the caller wants. Waiting indefinitely for a resource (filename) + to become available might be a valid strategy after all... + 2) Some malicious process reads this process' memory, learns the filename + and creates files before this process does (then removes them, once this + process fails to create existing file). Effect is like an extreme case of (1). + Can't be fixed (other than just failing after N attempts). + This code will NOT fail due to exausting available names if it is the only + process creating temporary files with this template, because it will run + out of fds (_open_osfhandle() will fail) long before it runs out of names. + */ + do { + char allowed_chars[] = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz_-+=[](){}`~!@#%^&;'"; + unsigned char name_random[8]; p = name; - value = (GetTickCount () ^ ((pid<<16) & 0xffff0000)); - for (i=0; i < 8; i++) - { - *p++ = tohex (((value >> 28) & 0x0f)); - value <<= 4; - } + w32_randomize (name_random, 8); + for (i = 0; i < 8; i++) + *p++ = allowed_chars[name_random[i] % sizeof (allowed_chars)]; strcpy (p, ".tmp"); file = CreateFile (buffer, GENERIC_READ | GENERIC_WRITE, @@ -374,6 +513,7 @@ CREATE_NEW, FILE_ATTRIBUTE_TEMPORARY | FILE_FLAG_DELETE_ON_CLOSE, NULL); + w32_error = GetLastError (); if (file != INVALID_HANDLE_VALUE) { FILE *fp; @@ -393,8 +533,7 @@ } return fp; } - Sleep (1); /* One ms as this is the granularity of GetTickCount. */ - } + } while (w32_error == ERROR_FILE_EXISTS); errno = ENOENT; return NULL; #else /*!HAVE_W32_SYSTEM*/ From lrn1986 at gmail.com Sat Jan 26 04:12:33 2013 From: lrn1986 at gmail.com (LRN) Date: Sat, 26 Jan 2013 07:12:33 +0400 Subject: W32 build fixes for libgpg-error-1.10 Message-ID: <510349A1.10405@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Subj is attached. If you need patches against git master HEAD, just ask. 01-mingw32-fix-potomo.mingw32.patch: iconv.exe provided by mingw32-libiconv package from mingw.org hangs up when --silent is given, but works with -s just fine. Yes, i know that this should be fixed by mingw.org. No, i doubt that i can make them fix this within a year. 02-fix-symbollist-on.mingw32.patch: - -export-symbols libtool option takes a _symbol list_. What you are giving it is not a symbol list, it's a MS .def file. If you truly need a .def file (why would you?), then add a separate .symbols file and use it for -export-symbols. This patch assumes that you don't really need a .def file, and fixes it to be libtool-compatible symbols list. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRA0mgAAoJEOs4Jb6SI2CwOTIH/11+fMsLVfXMHInFbGcz/7FF ArhIuA6UzeW7zuXJAolDP/W8wCvdQTMPIrfvsbu9yEmWkzqOpzhpsloH5LA9mjX+ +cBW3tYcyS9wWqWWUBOdeYXZHxJf0FXD0puHVksOqN2AJT28agmiNVbBgThHO4Gr Mjf9Z/r03zEchVIqzdZW7zJ7EGAgtIpfrh/kWpdLw86Uo2u+yE30TAFNaV8cnVTY U6sYyJsiqqLyMSYH1aFEtgPGZwHRe9+WRpbGBmopNU//OtrMx5g9sk7VmXOGi3Sd THsBe8frpV1KZJoGxi5UjHQrrdI1blJBHmWacUubhpvvQrdsAacng1eJO5rig6s= =pVH0 -----END PGP SIGNATURE----- -------------- next part -------------- --- libgpg-error-1.10/potomo 2010-10-20 18:27:58 +0400 +++ libgpg-error-1.10/potomo 2011-04-03 15:05:06 +0400 @@ -57,7 +57,7 @@ ;; *) echo "potomo: '$infile' converting from $fromset to utf-8" >&2 - iconv --silent --from-code=$fromset --to-code=utf-8 < "$infile" |\ + iconv -s --from-code=$fromset --to-code=utf-8 < "$infile" |\ sed "/^\"Content-Type:/ s/charset=[a-zA-Z0-9_-]*/charset=utf-8/"|\ msgfmt --output-file="$outfile" - ;; -------------- next part -------------- --- libgpg-error-1.10/src/gpg-error.def.in.orig 2012-12-21 13:48:57 +0400 +++ libgpg-error-1.10/src/gpg-error.def.in 2012-12-21 15:37:31 +0400 @@ -4,7 +4,6 @@ #include -EXPORTS gpg_strerror @1 gpg_strerror_r @2 gpg_strsource @3 From lrn1986 at gmail.com Sat Jan 26 04:18:45 2013 From: lrn1986 at gmail.com (LRN) Date: Sat, 26 Jan 2013 07:18:45 +0400 Subject: W32 build fixes for libgcrypt-1.5.0 Message-ID: <51034B15.60401@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Subj is attached. If you need patches against git master HEAD, just ask. 001-libtool-tag-for-RC.mingw32.patch: When compiling resource files, use do not use a tag (don't ask me why it doesn't work with --tag - i don't know). 002-create-libdir-first.mingw32.patch: I'm not sure why $(DESTDIR)$(libdir) is not created by $(INSTALL), but it isn't. This creates it. Maybe it's better to use $(INSTALL) -d $(DESTDIR)$(libdir) I don't know. This becomes most obvious when you install into (empty) staging directory. 003-no-unconditional-fig2dev.mingw32.patch: This is a hack, not a valid patch. It prevents `make' from trying to run fig2dev (which is not available on W32, and likely will never be). I don't know what is the right way to fix this. 004-fix-nondef-symbol-list-on.mingw32.patch: Same problem as in libgpg-error - -export-symbols takes a symbol list, not a MS .def file. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRA0sUAAoJEOs4Jb6SI2Cw5BUH/iBaGLZTgzKBEtCTQLOELH7D t2tSDHq0vVG2shArfzKLMFQePmRd4tTM2SODZNOxxH0KIVjmqhCj9HL0JFYjK8va /JYCnEnUvq0+cX0QgmZGws63Y6HkszfViaPLT/mo7z2oRuqCBIYSu9b3WMRxFe2N ya0ulxN0Un6Mx6na+Q76yZ6wIuZL1QolqqtlYQi/g+qbEZWXzIf7GSbAfvJiUbBZ Op6d04rqpjb4m1nGH8Agx5cdCu+tZNoU7ipJxGCYLRkgKg0PpnSXKzhdG3mGhG/v tRpQ70CJ1hYjz7qYHGIjFGMAelG7iTvL4Axv1WpQFdORyrYZhEu3Bf96I1h96g4= =aQcX -----END PGP SIGNATURE----- -------------- next part -------------- --- libgcrypt-1.5.0/src/Makefile.am.orig 2011-05-23 12:07:51 +0400 +++ libgcrypt-1.5.0/src/Makefile.am 2012-03-27 21:23:31 +0400 @@ -64,7 +64,7 @@ RCCOMPILE = $(RC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \ $(libgcrypt_la_CPPFLAGS) $(AM_CPPFLAGS) $(CPPFLAGS) -LTRCCOMPILE = $(LIBTOOL) --mode=compile --tag=RC $(RCCOMPILE) +LTRCCOMPILE = $(LIBTOOL) --mode=compile $(RCCOMPILE) SUFFIXES = .rc .lo -------------- next part -------------- --- libgcrypt-1.5.0/src/Makefile.am.orig 2012-09-12 02:57:53 +0400 +++ libgcrypt-1.5.0/src/Makefile.am 2012-09-12 03:21:55 +0400 @@ -76,6 +76,7 @@ export_symbols = -export-symbols $(srcdir)/libgcrypt.def install-def-file: + $(INSTALL) -d $(DESTDIR)$(libdir) $(INSTALL) $(srcdir)/libgcrypt.def $(DESTDIR)$(libdir)/libgcrypt.def uninstall-def-file: -------------- next part -------------- --- libgcrypt-1.5.0/doc/Makefile.am.orig 2012-09-12 03:23:56 +0400 +++ libgcrypt-1.5.0/doc/Makefile.am 2012-09-12 03:31:21 +0400 @@ -33,16 +33,16 @@ .fig.png: - fig2dev -L png `test -f '$<' || echo '$(srcdir)/'`$< $@ + touch $@ .fig.jpg: - fig2dev -L jpg `test -f '$<' || echo '$(srcdir)/'`$< $@ + touch $@ .fig.eps: - fig2dev -L eps `test -f '$<' || echo '$(srcdir)/'`$< $@ + touch $@ .fig.pdf: - fig2dev -L pdf `test -f '$<' || echo '$(srcdir)/'`$< $@ + touch $@ # Make sure that gcrypt.texi is touched if any other source file has -------------- next part -------------- --- libgcrypt-1.5.0/src/libgcrypt.def.orig 2012-12-21 19:16:19 +0400 +++ libgcrypt-1.5.0/src/libgcrypt.def 2012-12-21 19:19:43 +0400 @@ -22,7 +22,6 @@ ;; never be changed. Also check libgcrypt.vers and visibility.h. -EXPORTS gcry_check_version @1 gcry_control @2 From wk at gnupg.org Sat Jan 26 20:37:00 2013 From: wk at gnupg.org (Werner Koch) Date: Sat, 26 Jan 2013 20:37:00 +0100 Subject: W32 build fixes for gnupg-2.0.19 In-Reply-To: <510351C6.7050608@gmail.com> (LRN's message of "Sat, 26 Jan 2013 07:47:18 +0400") References: <510351C6.7050608@gmail.com> Message-ID: <87622jloqi.fsf@vigenere.g10code.de> On Sat, 26 Jan 2013 04:47, lrn1986 at gmail.com said: > Subj is attached. Please explain the problems you are trying to fix. Note that we still need copyright assignments for GnuPG and that building requires a full fledged POSIX host; i.e. building on a Windows host does not work. If you need that I suggest to run a decent Debian version in a VM. > minimal target W32 platform is W2000 (0x500), which means that I can't guarantee that GnuPG-2 will run on W2000. I have no test system anymore and in any case W2000 reached EOL a long time ago. > check' passes all tests successfully (i did test all 3 versions of the > random generator). Those tests don't test the quality of the RNG! To make sure that it works as expected you need to do quite some research. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jeanjacquesbrucker at gmail.com Sun Jan 27 11:33:40 2013 From: jeanjacquesbrucker at gmail.com (jbar) Date: Sun, 27 Jan 2013 11:33:40 +0100 Subject: [Feature request] send an user agent in hkp request Message-ID: <20130127113340.d1de6902.jeanjacquesbrucker@gmail.com> It should not be a big job, but is could be great to send an HTTP user-agent within hkp request (to search, receive and send keys from/to a key keyserver). When I checked the log*, I noticed that none are send when using "gpg --send-keys" or "gpg --recv-keys". But that could be usefull to have stat about used GnuPG versions (or... I don't know if PGP did send the user-agent), and why not O.S. too, like we already use to stat with regular Web servers. Tanks a lot. * Of my own HTTP/HKP server: https://github.com/Open-UDC/thttpgpd -- jbar -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From gnupg-devel at spodhuis.org Mon Jan 28 04:08:04 2013 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Sun, 27 Jan 2013 22:08:04 -0500 Subject: HKP keyserver: implementations Message-ID: <20130128030803.GA88538@redoubt.spodhuis.org> I've put together what I know of the available HKP-speaking PGP keyservers into a web-page with a brief summary of what I'm talking about, followed by a list of the implementations I know of, with some details, at: http://people.spodhuis.org/phil.pennock/pgp-keyservers Corrections, additions, updates, flames, welcome. gnupg-devel seems the best current place to find "authors of generic keyservers"; if there's something actively used in place of the old pgp-keyserver-folk mailing-list, please point me at it and accept my apologies for this being more off-topic than I realised. Thanks, -Phil From abel at guardianproject.info Mon Jan 28 13:11:12 2013 From: abel at guardianproject.info (Abel Luck) Date: Mon, 28 Jan 2013 12:11:12 +0000 Subject: --log-file ignored in gnupg master? Message-ID: <51066AE0.7000701@guardianproject.info> The following command doesn't do what I expect it to do: gpg2 --debug-level expert --log-file ./debug.log --homedir . --list-keys I expect gpg2 to spit all the data I'm getting on stdout into ./debug.log, but gpg2 isn't even creating the file, let alone writing to it. Are my expectations misplaced or is something broken? Using: gpg (GnuPG) 2.1.0-beta129 libgcrypt 1.6.0-git2c54c4d built from gnupg 19994466449a93704d38d429ca1ea36f63da0bf0 ~abel From wk at gnupg.org Mon Jan 28 15:27:03 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 28 Jan 2013 15:27:03 +0100 Subject: --log-file ignored in gnupg master? In-Reply-To: <51066AE0.7000701@guardianproject.info> (Abel Luck's message of "Mon, 28 Jan 2013 12:11:12 +0000") References: <51066AE0.7000701@guardianproject.info> Message-ID: <87d2wpjsco.fsf@vigenere.g10code.de> On Mon, 28 Jan 2013 13:11, abel at guardianproject.info said: > Are my expectations misplaced or is something broken? Looks like a regression. I'll check. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Jan 28 15:35:28 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 28 Jan 2013 15:35:28 +0100 Subject: --log-file ignored in gnupg master? In-Reply-To: <51066AE0.7000701@guardianproject.info> (Abel Luck's message of "Mon, 28 Jan 2013 12:11:12 +0000") References: <51066AE0.7000701@guardianproject.info> Message-ID: <878v7djryn.fsf@vigenere.g10code.de> On Mon, 28 Jan 2013 13:11, abel at guardianproject.info said: > The following command doesn't do what I expect it to do: > > gpg2 --debug-level expert --log-file ./debug.log --homedir . --list-keys > > I expect gpg2 to spit all the data I'm getting on stdout into > ./debug.log, but gpg2 isn't even creating the file, let alone writing to it. Well, the default debug output is stderr and not stdout. To enable --log-file you have to use --batch as well. Back then when I added --log-file it was done to be compatible to gpgsm's --log-file, which is only used in --server mode. Now, the server mode for gpg2 is not implemented in a useful way and thus I tried to emulate that behaviour by requiring --batch. From gpg2.c: /* FIXME: We should use logging to a file only in server mode; however we have not yet implemented that. Thus we try to get away with --batch as indication for logging to file required. */ Does that help? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dshaw at jabberwocky.com Wed Jan 30 05:12:56 2013 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 29 Jan 2013 23:12:56 -0500 Subject: [Feature request] send an user agent in hkp request In-Reply-To: <20130127113340.d1de6902.jeanjacquesbrucker@gmail.com> References: <20130127113340.d1de6902.jeanjacquesbrucker@gmail.com> Message-ID: On Jan 27, 2013, at 5:33 AM, jbar wrote: > > It should not be a big job, but is could be great to send an HTTP user-agent within hkp request (to search, receive and send keys from/to a key keyserver). > > When I checked the log*, I noticed that none are send when using "gpg --send-keys" or "gpg --recv-keys". But that could be usefull to have stat about used GnuPG versions (or... I don't know if PGP did send the user-agent), and why not O.S. too, like we already use to stat with regular Web servers. Not passing a user-agent is actually intentional behavior. Unlike some sites which may want to behave differently for different user-agents, you get the same key blob no matter who (or what) is making the request. Given this, there is no real reason beyond tracking and statistics gathering to send a user-agent string, so we don't, as it is really nobody's business what client you are using. In fact, there is a TODO in the code to not pass the ASCII armor "Version" field either when sending keys to a keyserver. I should implement that... David From gniibe at fsij.org Wed Jan 30 09:23:34 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 30 Jan 2013 17:23:34 +0900 Subject: scd: Reader specific initialization code (scd-work branch) Message-ID: <1359534214.2662.5.camel@cfw2.gniibe.org> Hello, I pushed the following changes to scd-work branch. This is to add vendor specific custom initialization. This kind of scheme is needed for a reader named Vega Alpha. Vega Alpha has a feature that the reader examines retry counter by itself and shows the number to the display when authentication is requested by pinpad. This would be great feature, but it doesn't work for OpenPGP card, as OpenPGP card doesn't support assumed command sequence (of VERIFY command with empty data). We need to disable this feature at initialization time, to reliably use pinpad authentication. diff --git a/scd/ccid-driver.c b/scd/ccid-driver.c index e9f39f4..6d6c3db 100644 --- a/scd/ccid-driver.c +++ b/scd/ccid-driver.c @@ -303,6 +303,9 @@ static int bulk_in (ccid_driver_t handle, unsigned char *buffer, size_t length, size_t *nread, int expected_type, int seqno, int timeout, int no_debug); static int abort_cmd (ccid_driver_t handle, int seqno); +static int send_escape_cmd (ccid_driver_t handle, const unsigned char *data, + size_t datalen, unsigned char *result, + size_t resultmax, size_t *resultlen); /* Convert a little endian stored 4 byte value into an unsigned integer. */ @@ -1525,6 +1528,29 @@ ccid_get_reader_list (void) } +/* Vendor specific custom initialization. */ +static int +ccid_vendor_specific_init (ccid_driver_t handle) +{ + if (handle->id_vendor == VENDOR_VEGA && handle->id_product == VEGA_ALPHA) + { + /* + * Vega alpha has a feature to show retry counter on the pinpad + * display. But it assumes that the card returns the value of + * retry counter by VERIFY with empty data (return code of + * 63Cx). Unfortunately, existing OpenPGP cards don't support + * VERIFY command with empty data. This vendor specific command + * sequence is to disable the feature. + */ + const unsigned char cmd[] = "\xb5\x01\x00\x03\x00"; + + return send_escape_cmd (handle, cmd, sizeof (cmd), NULL, 0, NULL); + } + + return 0; +} + + /* Open the reader with the internal number READERNO and return a pointer to be used as handle in HANDLE. Returns 0 on success. */ int @@ -1633,6 +1659,8 @@ ccid_open_reader (ccid_driver_t *handle, const char *readerid) } } + rc = ccid_vendor_specific_init (*handle); + leave: free (ifcdesc_extra); if (rc) -- From wk at gnupg.org Wed Jan 30 10:05:22 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 30 Jan 2013 10:05:22 +0100 Subject: [Feature request] send an user agent in hkp request In-Reply-To: (David Shaw's message of "Tue, 29 Jan 2013 23:12:56 -0500") References: <20130127113340.d1de6902.jeanjacquesbrucker@gmail.com> Message-ID: <87ehh3ghwt.fsf@vigenere.g10code.de> On Wed, 30 Jan 2013 05:12, dshaw at jabberwocky.com said: > In fact, there is a TODO in the code to not pass the ASCII armor "Version" field either when sending keys to a keyserver. I should implement that... Actually we should remove this anywhere or strip it down to just "GnuPG" without version and OS. Everywhere else we take care not to release unnecessary private data but not in the armored format. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From achim at pietig.com Wed Jan 30 10:41:11 2013 From: achim at pietig.com (Achim Pietig) Date: Wed, 30 Jan 2013 10:41:11 +0100 Subject: scd: Reader specific initialization code (scd-work branch) In-Reply-To: <1359534214.2662.5.camel@cfw2.gniibe.org> References: <1359534214.2662.5.camel@cfw2.gniibe.org> Message-ID: <5108EAB7.1070207@pietig.com> Hi, if the extention of the VERIFY command (APDU with no command data, SW1SW2 = 63Cx, where x encodes the number of further allowed retries) is useful for several readers, there is no problem to provide this in the next OpenPGP card specification. Regards, Achim Am 30.01.2013 09:23, schrieb NIIBE Yutaka: > Hello, > > I pushed the following changes to scd-work branch. > > This is to add vendor specific custom initialization. > > This kind of scheme is needed for a reader named Vega Alpha. > > Vega Alpha has a feature that the reader examines retry counter by > itself and shows the number to the display when authentication is > requested by pinpad. This would be great feature, but it doesn't work > for OpenPGP card, as OpenPGP card doesn't support assumed command > sequence (of VERIFY command with empty data). > > We need to disable this feature at initialization time, to reliably > use pinpad authentication. > > diff --git a/scd/ccid-driver.c b/scd/ccid-driver.c > index e9f39f4..6d6c3db 100644 > --- a/scd/ccid-driver.c > +++ b/scd/ccid-driver.c > @@ -303,6 +303,9 @@ static int bulk_in (ccid_driver_t handle, unsigned char *buffer, size_t length, > size_t *nread, int expected_type, int seqno, int timeout, > int no_debug); > static int abort_cmd (ccid_driver_t handle, int seqno); > +static int send_escape_cmd (ccid_driver_t handle, const unsigned char *data, > + size_t datalen, unsigned char *result, > + size_t resultmax, size_t *resultlen); > > /* Convert a little endian stored 4 byte value into an unsigned > integer. */ > @@ -1525,6 +1528,29 @@ ccid_get_reader_list (void) > } > > > +/* Vendor specific custom initialization. */ > +static int > +ccid_vendor_specific_init (ccid_driver_t handle) > +{ > + if (handle->id_vendor == VENDOR_VEGA && handle->id_product == VEGA_ALPHA) > + { > + /* > + * Vega alpha has a feature to show retry counter on the pinpad > + * display. But it assumes that the card returns the value of > + * retry counter by VERIFY with empty data (return code of > + * 63Cx). Unfortunately, existing OpenPGP cards don't support > + * VERIFY command with empty data. This vendor specific command > + * sequence is to disable the feature. > + */ > + const unsigned char cmd[] = "\xb5\x01\x00\x03\x00"; > + > + return send_escape_cmd (handle, cmd, sizeof (cmd), NULL, 0, NULL); > + } > + > + return 0; > +} > + > + > /* Open the reader with the internal number READERNO and return a > pointer to be used as handle in HANDLE. Returns 0 on success. */ > int > @@ -1633,6 +1659,8 @@ ccid_open_reader (ccid_driver_t *handle, const char *readerid) > } > } > > + rc = ccid_vendor_specific_init (*handle); > + > leave: > free (ifcdesc_extra); > if (rc) > From martin at martinpaljak.net Wed Jan 30 11:32:29 2013 From: martin at martinpaljak.net (Martin Paljak) Date: Wed, 30 Jan 2013 12:32:29 +0200 Subject: scd: Reader specific initialization code (scd-work branch) In-Reply-To: <5108EAB7.1070207@pietig.com> References: <1359534214.2662.5.camel@cfw2.gniibe.org> <5108EAB7.1070207@pietig.com> Message-ID: Hello, On Wed, Jan 30, 2013 at 11:41 AM, Achim Pietig wrote: > Hi, > > if the extention of the VERIFY command (APDU with no command data, SW1SW2 = 63Cx, where x encodes the number of further allowed retries) is useful for several readers, > there is no problem to provide this in the next OpenPGP card specification. Yes, please, adding support for this should be considered. But readers that send "arbitrary" commands to readers makes me feel weird. Martin From freebsd-listen at fabiankeil.de Wed Jan 30 12:29:37 2013 From: freebsd-listen at fabiankeil.de (Fabian Keil) Date: Wed, 30 Jan 2013 12:29:37 +0100 Subject: [Feature request] send an user agent in hkp request In-Reply-To: References: <20130127113340.d1de6902.jeanjacquesbrucker@gmail.com> Message-ID: <20130130122937.2eec10a9@fabiankeil.de> David Shaw wrote: > On Jan 27, 2013, at 5:33 AM, jbar wrote: > > > > > It should not be a big job, but is could be great to send an HTTP user-agent within hkp request (to search, receive and send keys from/to a key keyserver). > > > > When I checked the log*, I noticed that none are send when using "gpg --send-keys" or "gpg --recv-keys". But that could be usefull to have stat about used GnuPG versions (or... I don't know if PGP did send the user-agent), and why not O.S. too, like we already use to stat with regular Web servers. > > Not passing a user-agent is actually intentional behavior. Unlike some sites which may want to behave differently for different user-agents, you get the same key blob no matter who (or what) is making the request. Given this, there is no real reason beyond tracking and statistics gathering to send a user-agent string, so we don't, as it is really nobody's business what client you are using. An advantage of sending a User-Agent is that it allows the proxy to easily differentiate gpg from other clients to route the requests differently. For example I do not want my gpg requests to share a Tor circuit with my feed reader or web browser and a "User-Agent: GnuPG" header would make this easier, IMHO without disclosing too much information. "Detecting" gpg by looking for requests without a User-Agent header only works as long as no other client sends no User-Agent header either. Fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: not available URL: From dshaw at jabberwocky.com Wed Jan 30 16:10:59 2013 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 30 Jan 2013 10:10:59 -0500 Subject: [Feature request] send an user agent in hkp request In-Reply-To: <87ehh3ghwt.fsf@vigenere.g10code.de> References: <20130127113340.d1de6902.jeanjacquesbrucker@gmail.com> <87ehh3ghwt.fsf@vigenere.g10code.de> Message-ID: On Jan 30, 2013, at 4:05 AM, Werner Koch wrote: > On Wed, 30 Jan 2013 05:12, dshaw at jabberwocky.com said: > >> In fact, there is a TODO in the code to not pass the ASCII armor "Version" field either when sending keys to a keyserver. I should implement that... > > Actually we should remove this anywhere or strip it down to just "GnuPG" > without version and OS. Everywhere else we take care not to release > unnecessary private data but not in the armored format. Hmm. Are you suggesting removing the Version header completely, or would simply changing the default to --no-emit-version handle this? David From wk at gnupg.org Wed Jan 30 17:04:27 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 30 Jan 2013 17:04:27 +0100 Subject: [Feature request] send an user agent in hkp request In-Reply-To: (David Shaw's message of "Wed, 30 Jan 2013 10:10:59 -0500") References: <20130127113340.d1de6902.jeanjacquesbrucker@gmail.com> <87ehh3ghwt.fsf@vigenere.g10code.de> Message-ID: <87d2wmfyic.fsf@vigenere.g10code.de> On Wed, 30 Jan 2013 16:10, dshaw at jabberwocky.com said: > Hmm. Are you suggesting removing the Version header completely, or would simply changing the default to --no-emit-version handle this? I fear that there are applications which expect the Version header or at least a header and thus I suggest to change it from Version: GnuPG v1.4.13 (GNU/Linux) to Version: GnuPG (maybe to "GnuPG v1" and "GnuPG v2" to see how often both branches are used). And before someone asks, we could of course add a --emit-full-version ;-) Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From folkert at vanheusden.com Wed Jan 30 20:16:36 2013 From: folkert at vanheusden.com (folkert) Date: Wed, 30 Jan 2013 20:16:36 +0100 Subject: multi process safety Message-ID: <20130130191635.GE2302@belle.intranet.vanheusden.com> Hi, I was wondering: if 2 processes (not threads, processes that are invoked from e.g. the command line) do a gpg --recv-key so that they both want to fiddle with ~/.gnupg/pubring.gpg, will that break things? Or does gnupg do locking? Folkert van Heusden -- www.TrustedTimestamping.com is a service that enables you to show that at a certain point in time, you had access to a hash-value reflecting the contents of a file (this file can be a word document, a jpeg image, everything). ---------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com From jeanjacquesbrucker at gmail.com Wed Jan 30 22:56:43 2013 From: jeanjacquesbrucker at gmail.com (jbar) Date: Wed, 30 Jan 2013 22:56:43 +0100 Subject: [Feature request] send an user agent in hkp request In-Reply-To: <87d2wmfyic.fsf@vigenere.g10code.de> References: <20130127113340.d1de6902.jeanjacquesbrucker@gmail.com> <87ehh3ghwt.fsf@vigenere.g10code.de> <87d2wmfyic.fsf@vigenere.g10code.de> Message-ID: <20130130225643.96594dc5.jeanjacquesbrucker@gmail.com> On Wed, 30 Jan 2013 17:04:27 +0100 Werner Koch wrote: > > And before someone asks, we could of course add a --emit-full-version ;-) I don't consider softwares and versions as "private", but I agree with not sending such information, at least not needed, by default. And yes that could be great to have such option to enable such information in Armored data AND in the HTTP user agent. (i.e. with --armor AND with --recv-keys and --send-keys). Note: I don't want absolutely to have the GnuPG versions in HTTP user agent, I could also being satistfied to have only the default libcurl user-agent. The matter is that when you are a web admin, who checks the logs to detect eventual unexpected behaviours, empty HTTP user agent are always suspicious, and I prefer personnaly false, liar, or little wordy user-agents, than empty ones. We could also maybe mind having an option --http-user-agent which take an argument to specifie the sended user-agent, like curl have. -- jbar -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From gniibe at fsij.org Thu Jan 31 01:32:34 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 31 Jan 2013 09:32:34 +0900 Subject: scd: Reader specific initialization code (scd-work branch) In-Reply-To: <5108EAB7.1070207@pietig.com> References: <1359534214.2662.5.camel@cfw2.gniibe.org> <5108EAB7.1070207@pietig.com> Message-ID: <1359592354.2933.1.camel@cfw2.gniibe.org> Thanks for your response. On 2013-01-30 at 10:41 +0100, Achim Pietig wrote: > if the extention of the VERIFY command (APDU with no command data, > SW1SW2 = 63Cx, where x encodes the number of further allowed > retries) is useful for several readers, there is no problem to > provide this in the next OpenPGP card specification. Yes, it is useful. Please add this. You know, using a card is not only with a card, but also with a reader. In some situations, such as in the error recovery (from an error of the reader, not the card), the status of the card may be not well-defined. This causes "out-of-sync" for the card status between the one in an application and the actual one in the card. If it is possible for an application (SCDaemon) to use VERIFY command to confirm the authentication status, it will be possible to sync back the status easily. Then, user won't see weird errors (again and again) after an error by reader which causes out-of-sync, and won't need to manually reset the reader and the SCDaemon. -- From gniibe at fsij.org Thu Jan 31 08:57:54 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 31 Jan 2013 16:57:54 +0900 Subject: Popup_message_stop In-Reply-To: <1359001349.5224.4.camel@cfw2.gniibe.org> References: <1358219182.2667.8.camel@cfw2.gniibe.org> <1359001349.5224.4.camel@cfw2.gniibe.org> Message-ID: <1359619074.22168.1.camel@cfw2.gniibe.org> On 2013-01-24 at 13:22 +0900, NIIBE Yutaka wrote: > On 2013-01-15 at 12:06 +0900, NIIBE Yutaka wrote: > > I am bitten by my own change of: > > > > commit f6251c0d0af92331388f5e9bcd1750cbadcaca8f > > Author: NIIBE Yutaka > > Date: Fri Dec 16 09:07:56 2011 +0900 > > > > Don't kill pinentry by SIGKILL but let it quit by SIGINT. > > > > * agent/call-pinentry.c (agent_popup_message_stop): To pinentry, send > > SIGINT (was: SIGKILL). > > > > The window of pinentry doesn't pop down, now. > > > > This change was done because of pinentry-curses. With > > pinentry-curses, when it is killed by SIGINT, terminal gets confused. For 2.0 branch, it is signal mask and signal handler setting. Here is a patch to fix the original issue in 2.0. Built and tested (with VASCO reader). diff --git a/agent/call-pinentry.c b/agent/call-pinentry.c index 2483019..c945c13 100644 --- a/agent/call-pinentry.c +++ b/agent/call-pinentry.c @@ -170,6 +170,16 @@ static void atfork_cb (void *opaque, int where) { ctrl_t ctrl = opaque; +#ifndef HAVE_W32_SYSTEM + struct sigaction sa; + + /* Pop up message should be able to be killed by SIGINT. */ + sigemptyset (&sa.sa_mask); + sa.sa_handler = SIG_DFL; + sa.sa_flags = 0; + sigaction (SIGINT, &sa, NULL); + sigprocmask (SIG_SETMASK, &sa.sa_mask, NULL); /* Unblock all signals. */ +#endif if (!where) { @@ -1159,8 +1169,7 @@ agent_popup_message_stop (ctrl_t ctrl) assuan_set_flag (entry_ctx, ASSUAN_NO_WAITPID, 1); } else if (pid > 0) - kill (pid, SIGKILL); /* Need to use SIGKILL due to bad - interaction of SIGINT with Pth. */ + kill (pid, SIGINT); #endif /* Now wait for the thread to terminate. */ --