Re: Will gpg 1.x remain supported for the foreseeable future?

2018-01-20 Thread Dan Kegel
On Sat, Jan 20, 2018 at 4:08 PM, Todd Zullinger  wrote:
> I think that's https://dev.gnupg.org/T2290

Thanks.

Say, anyone know how to get bug tracker problems resolved?
Somehow my email address there lacks a dot before .com,
so I can't get confirmation emails.
- Dan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Will gpg 1.x remain supported for the foreseeable future?

2018-01-20 Thread Todd Zullinger
Dan Kegel wrote:
> - might save time and anguish if apt-key (and thus gpg[v]?) accepted
> armored keyrings even if filename ends in .gpg

I think that's https://dev.gnupg.org/T2290, in case you want
to follow it or submit a patch to implement it.  Werner did
provide some details about how it would ideally be done.

If I was more capable with C, I'd give it a try since I'd
like to see gpgv work with armored keyrings too.

-- 
Todd
~~
Progress isn't made by early risers. It's made by lazy men trying to
find easier ways to do something.
-- Robert Heinlein



signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Will gpg 1.x remain supported for the foreseeable future?

2018-01-20 Thread Dan Kegel
On Thu, Jan 18, 2018 at 7:58 PM, Dan Kegel  wrote:
>> The keys referred to via signed-by are the only acceptable keys for the
>> associated apt repo.
>>
>> does that make sense?
>
> That'd be great if it worked.  Since it's hard to explain what's broken
> without a simple script showing exactly what I'm doing, let's just
> hold that thought until I post one.

I spent a little while cleaning up my script and found the problem, whew!

Here's part of the log:

+ gpg2 -q --pinentry-mode loopback --passphrase
--personal-digest-preferences SHA256 --gen-key gpg.in.tmp
+ gpg2 --armor --export temp-r...@example.com
...
+ sudo GNUPGHOME=/tmp/obs_localbuild_gpghome_dank.tmp
APT_CONFIG=/home/dank/src/obs/foo.tmp/etc/apt.conf apt-get  update
...
Preparing to exec:  /usr/bin/apt-key --quiet --readonly --keyring
/tmp/obs_localbuild_keyrings_dank.tmp/keyrings/localhost.gpg verify
--status-fd 3 /tmp/apt.sig.nD3tum /tmp/apt.data.OVJLiX
Read: [GNUPG:] ERRSIG 505A301EE37484C6 1 8 01 1516484740 9
Got ERRSIG
Read: [GNUPG:] NO_PUBKEY 505A301EE37484C6

Even with apt debug logging on, that wasn't enough to make the problem
obvious.  I had to add

exec 2> /tmp/apt-key.log.$$
set -x

to the top of /usr/bin/apt-key.  Grepping for that key in /tmp/apt-key*, I found

+ gpgv --homedir /tmp/tmp.oM7RZ707db --keyring
/tmp/obs_localbuild_keyrings_dank.tmp/keyrings/localhost.gpg
--ignore-time-conflict --status-fd 3 /tmp/apt.sig.nD3tum
/tmp/apt.data.OVJLiX
gpgv: Signature made Sat Jan 20 13:45:40 2018 PST using RSA key ID E37484C6
gpgv: [don't know]: invalid packet (ctb=2d)
gpgv: keydb_search failed: invalid packet
gpgv: Can't check signature: public key not found

Well, well.  That 'invalid packet' appears to be a telltale sign of
using --armor where one shouldn't, and looking at my first log, you
can see a --armor.  Removing it made everything happy.
So this was a case of a) dumb user and b) poor diagnostics from apt.

Also, now that I've ripped out all gpg1 support from my script, I
realize that gpg-agent is nearly well behaved.
Only possible rough spots I ran into were:
- having to enable pinentry (ubuntu 16.04's gpg is old)
- not knowing a clean way to tidy up an old gnupghome and its agent
without hanging if the agent is missing
- the gpg man page says --dearmor isn't very useful.  I beg to differ :-)
- might save time and anguish if apt-key (and thus gpg[v]?) accepted
armored keyrings even if filename ends in .gpg

Thanks for the encouragement.
All's well that ends well.
I'm sure I'll trip over my shoelaces again soon enough!
- Dan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: SCM SPR332 PIN entry doesn't work

2018-01-20 Thread Maciej S. Szmigiero
On 14.01.2018 01:01, Maciej S. Szmigiero wrote:
> Hi all,
> 
> I've just received a SCM SPR332 from FLOSS-Shop (marked as "SPR332 V2"
> on its bottom side) and while its basic reader functionality seems to work
> just fine I can't get the secure PIN entry mode to work at all.
> 
> I've tried two different OpenPGP cards, tried both GnuPG built-in CCID
> driver and the pcsc-lite one to no avail.
> 
> I've even tried the latest vendor Windows driver (with OpenSC and a constant
> length PIN verify operation), but the behavior in each of these setups was
> always the same:
> Upon typing and accepting a PIN the "key" LED on the reader continues to
> blink for a few seconds, then the reader responds with "64 00" result at
> the USB interface level (which is probably the code for
> "SPE [Secure PIN Entry] operation timed out" error) and then it doesn't
> want to communicate with the card anymore.
> 
> A relevant log snippet from GnuPG built-in CCID driver:
> DBG: prompting for pinpad entry '||Please unlock the card%0A%0ANumber: 0005 
> 5B0E%0AHolder: '
> DBG: ccid-driver: sending escape sequence to switch to a case 1 APDU
> DBG: ccid-driver: PC_to_RDR_Escape:
> DBG: ccid-driver:   dwLength ..: 3
> DBG: ccid-driver:   bSlot .: 0
> DBG: ccid-driver:   bSeq ..: 56
> DBG: ccid-driver:   [0007]  00 00 00 80 02 00
> DBG: ccid-driver: RDR_to_PC_Escape:
> DBG: ccid-driver:   dwLength ..: 0
> DBG: ccid-driver:   bSlot .: 0
> DBG: ccid-driver:   bSeq ..: 56
> DBG: ccid-driver:   bStatus ...: 0
> DBG: ccid-driver:   buffer[9] .: 00
> DBG: ccid-driver: PC_to_RDR_Secure:
> DBG: ccid-driver:   dwLength ..: 19
> DBG: ccid-driver:   bSlot .: 0
> DBG: ccid-driver:   bSeq ..: 57
> DBG: ccid-driver:   bBMI ..: 0x00
> DBG: ccid-driver:   wLevelParameter ...: 0x
> DBG: ccid-driver:   [0010]  00 00 82 00 00 19
> DBG: ccid-driver:   [0016]  06 02 01 09 04 00 00 00 00 00 20 00 82
> DBG: ccid-driver: RDR_to_PC_DataBlock:
> DBG: ccid-driver:   dwLength ..: 2
> DBG: ccid-driver:   bSlot .: 0
> DBG: ccid-driver:   bSeq ..: 57
> DBG: ccid-driver:   bStatus ...: 0
> DBG: ccid-driver:   [0010]  64 00
> DBG: dismiss pinpad entry prompt
> verify CHV2 failed: Operation cancelled
> app_check_pin failed: Operation cancelled
> DBG: ccid-driver: PC_to_RDR_XfrBlock:
> DBG: ccid-driver:   dwLength ..: 9
> DBG: ccid-driver:   bSlot .: 0
> DBG: ccid-driver:   bSeq ..: 58
> DBG: ccid-driver:   bBWI ..: 0x04
> DBG: ccid-driver:   wLevelParameter ...: 0x
> DBG: ccid-driver:   [0010]  00 00 05 00 CA 00
> DBG: ccid-driver:   [0016]  6E 00 A1
> DBG: ccid-driver: usb_bulk_read error: LIBUSB_ERROR_TIMEOUT
> ccid_transceive failed: (0x1000a)
> apdu_send_simple(0) failed: card I/O error
> DBG: ccid-driver: PC_to_RDR_XfrBlock:
> DBG: ccid-driver:   dwLength ..: 9
> DBG: ccid-driver:   bSlot .: 0
> DBG: ccid-driver:   bSeq ..: 59
> DBG: ccid-driver:   bBWI ..: 0x04
> DBG: ccid-driver:   wLevelParameter ...: 0x
> DBG: ccid-driver:   [0010]  00 00 05 00 CA 00
> DBG: ccid-driver:   [0016]  C5 00 0A
> DBG: ccid-driver: usb_bulk_read error: LIBUSB_ERROR_TIMEOUT
> ccid_transceive failed: (0x1000a)
> apdu_send_simple(0) failed: card I/O error
> 
> I've tried also an EMV card with this reader, the behavior
> is slightly different in this case: the typed PIN is accepted
> immediately, but "00 82 00 82" T=1 protocol error is returned
> at the USB interface level.
> And the card communication still works after this.
> 
> The same cards (two OpenPGP ones and one EMV) accept PIN input without
> problems using exactly the same software setup when driven by a
> different PIN pad reader (a HP smart card keyboard).
> 
> What's interesting is that the reader reports firmware version 7.0
> while all the references I could find talk about firmware version 6.01.
> 
> The vendor Windows driver also has a firmware version check utility
> that explicitly checks for firmware version 6.01 (unfortunately,
> it is just a checking tool without up- or down-grade capability).
> 
> Now, I wonder: did anybody earlier spotted a similar behavior with this
> or other SCM/Identiv readers?
> Or is it possible that this reader is loaded with some non-standard
> firmware?
> It reports as "SPRx32 USB Smart Card Reader", which suggests the firmware
> should be common with a well-tested SPR532 model.

Has anybody used this reader as a PIN pad successfully or had similar
issues? 

Thanks,
Maciej

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: gnupg-2.2.4: how to deal with failed tests

2018-01-20 Thread MFPA
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On Friday 19 January 2018 at 3:50:22 PM, in
, Shannon Mess
via Gnupg-users wrote:-


> REMOVE my email address from this thread!

You are subscribed to the mailing list or not subscribed to it. There
is no feature to be removed from an individual discussion thread.

In the event you wish to unsubscribe from the list, you can do this at
the bottom of the page linked below.
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Or by sending an email to  with the
single word "unsubscribe" (without quotes) as the message subject.


- --
Best regards

MFPA  

Confusion is always the most honest response
-BEGIN PGP SIGNATURE-

iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCWmNeVl8UgAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw
Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju
+g8jAPoC6PCVQoqrx1gRu594ArZhnzd76l+7LbOQTlhGcUjHJgD9FidVLnA2bKur
CES7AV/7RburSe5CU/sNl8eAHzIoawWJApMEAQEKAH0WIQRSX6konxd5jbM7JygT
DfUWES/A/wUCWmNeVl8UgAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw
REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/0nvD/94it3CD7AuoJXFwzt8pIAdqGkN
LiPQhXhrzodc3KMKB8m2WDVuGPA6yzYa7fMRdFIhnlADbm39jlFNYl3bHk+L1xnp
Lz5n+moj9tf7/+/Yn+K7SaBdRTtvk9QO0YZe3pfsfBOiLxgSXg5Ub5JNknF3gTMB
pa1OziTSN5TYelsNtVVrvOrYvXEqKs/GeRnexdJMUi42oGDxlbLZtLjDQ+KxbLbk
JiBTFdTrritRQ4QTOPqp4NGFGumLtu81tiJPRZFELKUTRfHPDMV8QblqTFXUwSU3
TjWBNmOfWkdPu9wY/dofH9aEcbMj0qbFAMppGyK83MwFo47zrdhGXbVhzjceZtPI
g/zGnGSvvIarU7GcK/GA/icZiRdXyR3jLpGmVg1BBka8KfHfIEWT6SB+8Y/AR3oc
/rmduYkUUfmJggDRzpFXsHgOY68j/f8GOIeBRl1yidg52tBuoXWLQbVn4L/bz/KF
yD9CQPDt7pcOo5AmutkxIT+qj3D4KDdQwWwiFwXdh/vUKxdlM/FZHO0XkoaIRPQn
SZLeAnfAUOVw4B20EfY1Cmnv1mxG4jqKegNEFgtaywP9ywYeXfYbYKtpircYReY6
h99vHlXt9M6YAAZoO+Xr4wB8h1M8UvA3ZEVdRgtXIWe/1MMAc9/i3vc209VjHQvA
bt7S/gLIPiGBpfadMQ==
=47as
-END PGP SIGNATURE-


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users