Unable to access to Yubikey after recent GPG changes
Hi, I can no more use my Yubikey with GPG aftre recent changes. I followed https://wiki.debian.org/Smartcards/OpenPGP instructions but nothing succeeded. I'm running a Debian testing. Did someone find a solution ? $ pcsc_scan PC/SC device scanner V 1.7.3 (c) 2001-2024, Ludovic Rousseau Using reader plug'n play mechanism Scanning present readers... 0: Yubico YubiKey OTP+FIDO+CCID 00 00 Sat May 10 22:33:51 2025 Reader 0: Yubico YubiKey OTP+FIDO+CCID 00 00 Event number: 0 Card state: Card inserted, Shared Mode, ATR: 3B F8 13 00 00 81 31 FE 15 59 75 62 69 6B 65 79 34 D4 ATR: 3B F8 13 00 00 81 31 FE 15 59 75 62 69 6B 65 79 34 D4 + TS = 3B --> Direct Convention + T0 = F8, Y(1): , K: 8 (historical bytes) TA(1) = 13 --> Fi=372, Di=4, 93 cycles/ETU 43010 bits/s at 4 MHz, fMax for Fi = 5 MHz => 53763 bits/s TB(1) = 00 --> VPP is not electrically connected TC(1) = 00 --> Extra guard time: 0 TD(1) = 81 --> Y(i+1) = 1000, Protocol T = 1 - TD(2) = 31 --> Y(i+1) = 0011, Protocol T = 1 - TA(3) = FE --> IFSC: 254 TB(3) = 15 --> Block Waiting Integer: 1 - Character Waiting Integer: 5 + Historical bytes: 59 75 62 69 6B 65 79 34 Category indicator byte: 59 (proprietary format) + TCK = D4 (correct checksum) Possibly identified card (using /usr/share/pcsc/smartcard_list.txt): 3B F8 13 00 00 81 31 FE 15 59 75 62 69 6B 65 79 34 D4 Yubico Yubikey 4 OTP+CCID [then process is blocked, waiting a long time] SCardGetStatusChange: RPC transport error. $ sudo killall scdaemon; sudo killall gnome-keyring-daemon $ gpg --card-edit gpg: selecting card failed: No such device gpg: OpenPGP card not available: No such device gpg/card>
Re: ITN procedure?
On 2025-05-08 10:00 +0200, Andreas Tille wrote: Am Wed, May 07, 2025 at 10:27:03PM +0200 schrieb Jonas Smedegaard: Can we please stop calling it an intent to NMU when it is invasive? You're right--"Intent To NMU" is a misleading name for this. I'd gladly adopt a better term, and I appreciate any honest suggestion. Naming is hard, so thanks for helping. ITM Modernise ITU Update ITR Revamp move-to-collective-maintainership (failing to think a good short name here - maybe:) ITC Collectivise ? ITPM Publically Maintain I think the underlying tension here is that this is really about moving the package from a strong-maintainer model to a collective-maintainship model, and that is still somewhat controversial. Like Jonas I really don't think re-use of 'NMU' is appropriate here. I wouldn't put it quite as strongly as he did (that seemed rather too aggressive, when we know Andreas is a decent chap, trying to help), but I agree with his points. The move from archive to git+salsa is significant and whilst it _is_ reversible that would be work (and I think 'going backwards' like this would be disapproved-of by quite a chunk of DMs/DDs) so it's quite a one-way thing in practice, which is why 'NMU' (under existing rules) is definitely the wrong name. So long as the maintainer really is long-gone/disinterested this process makes sense, but if there _is_ still a willing maintainer then Jonas' reaction is quite right - it's a big imposition/change and definitely not just an 'NMU'. Giving it a name that makes clear the status-change of the package should avoid confusion and argument. Of the various names I think 'Revamp' might actually be the best, as it avoids the value-judgement implicit in 'Update' and 'Modernise'. And in 10 years time it could be re-used for some other significant packaging change when we have moved on to new debates. 'Collectivise' perhaps gets to the underlying issue better, but is perhaps too specific to this _particular_ revamping, and would look silly in a decade or two when we have other issues. So yeah, please pick a better name, and be mindful that 'collectivising' packages is a big change, even if it feels like a simple 'updating' to those already in that world. Wookey -- Principal hats: Debian, Wookware http://wookware.org/ signature.asc Description: PGP signature
Re: RFC for changes regarding NMU in developers reference (Was: ITN procedure?)
Hi, Holger Levsen ezt írta (időpont: 2025. máj. 9., P, 12:56): > > On Fri, May 09, 2025 at 12:43:54PM +0200, Lucas Nussbaum wrote: > > On 09/05/25 at 10:27 +0200, Andreas Tille wrote: > > > > However, I have doubts about (4), since there's still so many different > > > > workflows to use Git+Salsa. > > same here. I have no doubt that migrating a package to Git is an improvement in long term maintenance efficiency and it is not just my personal preference. According to https://trends.debian.net/#version-control-system >90% of packages are maintained in git already. I'd also enable CI by default as well ensuring that it passes thus the original maintainer does not have to deal with broken tests should the NMU go through. In addition to fine grained history and CI, having a Git repository on Salsa allows Debian Janitor to offer automated updates to the package which is the cheapest way of keeping a package in good shape. Eventually we could implement importing new upstream releases and uploads from Salsa tags and maintaining a package could be as simple as accepting MR-s and tagging a release. > > > Which brings us back to DEP-14 as a baseline recommendation that can > > > help reduce friction. While individual workflows vary, having some > > > repository is a precondition for any collaboration--and DEP-14 provides a > > > neutral, widely accepted starting point. > > Err, the current state of things is that DEP-14 is still in CANDIDATE > > state, and I read the last thread on this topic as unconclusive[0]. > > that, both, plus the fact that DEP-14 does not recommend one specific > workflow, but several. It is sad enough that the project could not converge on a recommended git workflow, please don't use that as an argument to hold back improving the state of neglected packages. DEP-14 not being officially accepted poses no practical issue for those who really want to migrate a package to git anyway. I typically just used gbp's default layout and lived with it or migrated to a newer format later. A potential NMU-er should also be able to make a good judgment call on the proposed repository format. Migrating a neglected package to Git should be allowed for bigger NMUs, which are offered with uploads with very long delay. Cheers, Balint
Re: Unable to access to Yubikey after recent GPG changes
On Sat, May 10, 2025 at 10:47:51PM +0200, Yadd wrote: > Found: echo 'disable-ccid' >> ~/.gnupg/scdaemon.conf > > An entry in /usr/share/doc/gnupg/README.Debian could help here There's an entry in /usr/share/doc/gnupg/NEWS.Debian.gz documenting this, which should show up on upgrades: gnupg2 (2.4.7-15) unstable; urgency=medium GnuPG 2.4 will not automatically fallback to the PC/SC driver for smartcard access if direct access fails. Users using pcscd for hardware access will need to explicitly disable the gnupg CCID driver. See --disable-ccid in scdaemon.1 and #1102717 -- Andreas Metzler Sun, 13 Apr 2025 13:50:29 +0200
Re: Unable to access to Yubikey after recent GPG changes
Found: echo 'disable-ccid' >> ~/.gnupg/scdaemon.conf An entry in /usr/share/doc/gnupg/README.Debian could help here On 5/10/25 22:39, Yadd wrote: Hi, I can no more use my Yubikey with GPG aftre recent changes. I followed https://wiki.debian.org/Smartcards/OpenPGP instructions but nothing succeeded. I'm running a Debian testing. Did someone find a solution ? $ pcsc_scan PC/SC device scanner V 1.7.3 (c) 2001-2024, Ludovic Rousseau Using reader plug'n play mechanism Scanning present readers... 0: Yubico YubiKey OTP+FIDO+CCID 00 00 Sat May 10 22:33:51 2025 Reader 0: Yubico YubiKey OTP+FIDO+CCID 00 00 Event number: 0 Card state: Card inserted, Shared Mode, ATR: 3B F8 13 00 00 81 31 FE 15 59 75 62 69 6B 65 79 34 D4 ATR: 3B F8 13 00 00 81 31 FE 15 59 75 62 69 6B 65 79 34 D4 + TS = 3B --> Direct Convention + T0 = F8, Y(1): , K: 8 (historical bytes) TA(1) = 13 --> Fi=372, Di=4, 93 cycles/ETU 43010 bits/s at 4 MHz, fMax for Fi = 5 MHz => 53763 bits/s TB(1) = 00 --> VPP is not electrically connected TC(1) = 00 --> Extra guard time: 0 TD(1) = 81 --> Y(i+1) = 1000, Protocol T = 1 - TD(2) = 31 --> Y(i+1) = 0011, Protocol T = 1 - TA(3) = FE --> IFSC: 254 TB(3) = 15 --> Block Waiting Integer: 1 - Character Waiting Integer: 5 + Historical bytes: 59 75 62 69 6B 65 79 34 Category indicator byte: 59 (proprietary format) + TCK = D4 (correct checksum) Possibly identified card (using /usr/share/pcsc/smartcard_list.txt): 3B F8 13 00 00 81 31 FE 15 59 75 62 69 6B 65 79 34 D4 Yubico Yubikey 4 OTP+CCID [then process is blocked, waiting a long time] SCardGetStatusChange: RPC transport error. $ sudo killall scdaemon; sudo killall gnome-keyring-daemon $ gpg --card-edit gpg: selecting card failed: No such device gpg: OpenPGP card not available: No such device gpg/card>
Re: Unable to access to Yubikey after recent GPG changes
* Yadd [250510 22:39]: I can no more use my Yubikey with GPG aftre recent changes. I followed https://wiki.debian.org/Smartcards/OpenPGP instructions but nothing succeeded. I'm running a Debian testing. Did someone find a solution ? People on IRC said this yubikey support article helped them: https://support.yubico.com/hc/en-us/articles/4819584884124-Resolving-GPG-s-CCID-conflicts Chris
