On Fri 2016-01-08 13:36:46 -0500, Aurelien Jarno wrote: > [gnupg1] has a build-depends on libusb-dev. A few years ago upstream > has released a new major version libusb 1.0 with a different API which > aims to fix design deficiencies with USB 2.0 and 3.0 in mind. > > The old libusb 0.1 package is not supported upstream anymore and should > be considered deprecated. > > If gnupg supports the new libusb 1.0 library, please consider > switching the build-depends from libusb-dev to libusb-1.0-0-dev. If not > please inform upstream that porting the software to the new API is > recommended.
I've had some discussion with Werner Kock (GnuPG upstream) over on https://bugs.debian.org/568375 about removing the ability for gpg1 to use smartcards at all. Werner says: >> --disable-card-support removes all support for smartcards. I would >> not mind if you use that option. i brought up the worry that this might strand people if they have a smartcard-enabled OpenPGPv3 (aka "PGP-2") key (which is not supported by the modern GnuPG suite, since that format is known broken in several ways), and he said: >> I doubt that you can put a PGP-2 key on an OpenPGP smartcard. We >> require a SHA-1 fingerprint. So i'm inclined to address this by just doing --disable-smartcard-support for gnupg1 for debian. I think this would adequately reflect upstream's preferred maintenance posture for GnuPG smartcard access (that scdaemon is preferred), and it would remove the dependency on the old libusb 1.0 in debian, thereby resolving https://bugs.debian.org/810417. It would also mean fewer processes would be likely to be in contention for direct access to the smartcard, since gpg1 wouldn't try to grab it when scdaemon is using it, or vice versa, which should reduce the maintenance load for scdaemon. i'm cc'ing gniibe here in case he has any suggestions for a better approach, but i'm likely to go ahead with this change unless i hear objections. --dkg
signature.asc
Description: PGP signature
