Bug#927824: Grisbi 1.2.1-1 always crashes when creating a new transaction
Le 24/04/2019 à 15:51, Ludovic Rousseau a écrit : debian-release will not accept to migrate 1.2.2 into testing. Maybe they will. Grisbi version 1.2.2 is just a bug fix of version 1.2.1. I created https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927881 asking for an unblock. Bye -- Dr. Ludovic Rousseau
Bug#927824: Grisbi 1.2.1-1 always crashes when creating a new transaction
Le 23/04/2019 à 22:05, Jérôme de Bretagne a écrit : Package: grisbi Version: 1.2.1-1 Dear Ludovic, Hello, I've just recently switched from stable to testing. Since this transition Grisbi 1.2.1-1 now crashes every time when trying to create a new transaction on my existing accounting file, preventing from making any modifications. This regression is making Grisbi totally unusable, whereas it has been rock solid for many years until now. Hopefully, this is an already known issue that has been fixed upstream it seems: https://github.com/grisbi/grisbi/commit/8545c825d8b9e36ae1eee5bccf93af15b12c7024 and this fix is available in version 1.2.2-1 already uploaded into unstable. Switching to this slightly newer version has fixed the above issue in my case. I don't want to define a severity level by myself as I'm not familiar enough with the Debian rules, but it would seem to match a "grave" level upon a quick reading, at least for users impacted by this issue. Due to the current freeze though, version 1.2.2-1 is not migrating into testing while version 1.2.1-1 could introduce this same issue to many more users, if the problem is widespread. Could you contact debian-release to ask for the version currently in unstable to reach testing as it is fixing this issue? debian-release will not accept to migrate 1.2.2 into testing. I prepared a version with just the fix added and checked it solved the issue. I will try to make this version acceptable for debian-release. Thanks a lot for your hard work on Grisbi, this is a great software! Thanks for the notice. Bye -- Dr. Ludovic Rousseau
Bug#925312: pcscd: Does not work if "used" in wrong order
Le 24/03/2019 à 22:05, Ludovic Rousseau a écrit : Le 24/03/2019 à 21:19, Joerg Jaspert a écrit : On 15351 March 1977, Ludovic Rousseau wrote: I think I found the problem. I think my system disagrees. :) In my case "gpg --card-status" works only if pcscd is NOT running. GnuPG has its own way to access the smart card readers (here a yubikey) Its a yubikey here too. I propose two possible solutions: 1. remove pcscd from your system but that is a drastic change. No PC/SC application will work any more. Not a good thing, it's there for a reason. And I know it worked in stretch. 2. configure scdaemon to NOT use its internal CCID driver but use the PC/SC interface instead To make option 2 just edit/create the scdaemon configuration file as bellow: $ cat ~/.gnupg/scdaemon.conf disable-ccid Done that. Doesn't do anything. Logged out. Killed gpg agent (just in case). Rebooted (damn system, maybe). Nope, nothing. Same behaviour as before. :-( Before you restart pcscd, can you see your YubiKey listed by the pcsc_scan command (from the pcsc-tools package)? Does "gpg --card-status" works as expected? Once you have restarted pcscd, can you see your YubiKey listed by the pcsc_scan command? Does "gpg --card-status" works as expected? What are the USB VendorID & ProductID of your YukiKey token? You can just attach the output of lsusb. Thanks -- Dr. Ludovic Rousseau
Bug#925312: pcscd: Does not work if "used" in wrong order
Le 24/03/2019 à 21:19, Joerg Jaspert a écrit : On 15351 March 1977, Ludovic Rousseau wrote: I think I found the problem. I think my system disagrees. :) In my case "gpg --card-status" works only if pcscd is NOT running. GnuPG has its own way to access the smart card readers (here a yubikey) Its a yubikey here too. I propose two possible solutions: 1. remove pcscd from your system but that is a drastic change. No PC/SC application will work any more. Not a good thing, it's there for a reason. And I know it worked in stretch. 2. configure scdaemon to NOT use its internal CCID driver but use the PC/SC interface instead To make option 2 just edit/create the scdaemon configuration file as bellow: $ cat ~/.gnupg/scdaemon.conf disable-ccid Done that. Doesn't do anything. Logged out. Killed gpg agent (just in case). Rebooted (damn system, maybe). Nope, nothing. Same behaviour as before. :-( Before you restart pcscd, can you see your YubiKey listed by the pcsc_scan command (from the pcsc-tools package)? Does "gpg --card-status" works as expected? Once you have restarted pcscd, can you see your YubiKey listed by the pcsc_scan command? Does "gpg --card-status" works as expected? Bye -- Dr. Ludovic Rousseau
Bug#924914: pcscd: socket activation masks socket
Le 24/03/2019 à 20:33, Mathias Behrle a écrit : * Ludovic Rousseau: " Re: Bug#924914: pcscd: socket activation masks socket" (Sun, 24 Mar 2019 14:58:07 +0100): Hello, I fixed the problem upstream in https://salsa.debian.org/rousseau/PCSC/commit/d627aee864c3e9ce40e375fcc0e34a7855b6f0f1 Please confirm the fix works for you. It if is OK then I will make a new upstream release and then a new Debian package. Yes, that's exactliy the fix I am running and that works for me. OK. Thanks for the confirmation. -- Dr. Ludovic Rousseau
Bug#924914: pcscd: socket activation masks socket
Le 18/03/2019 à 20:47, Mathias Behrle a écrit : * Ludovic Rousseau: " Re: Bug#924914: pcscd: socket activation masks socket" (Mon, 18 Mar 2019 18:42:21 +0100): Hello Ludovic, Hello, Sorry for the delay. Your email was in the gmail spam folder :-( Le 18/03/2019 à 11:40, Mathias Behrle a écrit : Package: pcscd Version: 1.8.24-1 Severity: important Tags: patch Dear Maintainer, Hello, pcscd.socket masks the socket of pcscd, which is then not available for programs needing it (e.g. can easily reproduced by running pcsc_scan). What are the steps to reproduce the problem? I am running pcscd inside an LXC container (container is buster, host is jessie). There is no problem when starting pcscd from command line: it creates the socket. The problem appears when started by systemd. As already said it is easy to reproduce: pcsc_scan doesn't work. The additional line SocketMode=0666 in pcscd.socket re-instates the usual socket as usually created by pcscd. the socket is now created by systemd, not pcscd. Unless you have a special configuration. The socket is only created when SocketMode=0666 is set, otherwise there is no socket in /var/run/pcscd. May be it is a special behavior of systemd in LXC containers. I fixed the problem upstream in https://salsa.debian.org/rousseau/PCSC/commit/d627aee864c3e9ce40e375fcc0e34a7855b6f0f1 Please confirm the fix works for you. It if is OK then I will make a new upstream release and then a new Debian package. Thanks -- Dr. Ludovic Rousseau
Bug#925312: pcscd: Does not work if "used" in wrong order
Le 22/03/2019 à 23:02, Joerg Jaspert a écrit : Package: pcscd Version: 1.8.24-1 Severity: important Dear Maintainer, Hello, I know the title is confusing, so here: I have a yubikey that got a gpg key on it. Worked perfectly fine in stretch. Now it does not work half the time. Thing is: If I plug the yubikey *BEFORE* anything that tries to get data from it - it works perfectly. If I do NOT plug the yubikey and start such an action (gpg sign for example) - it does NOT work until I issue a sudo /etc/init.d/pcscd restart. So using a gpg decryption example: If I insert the yubikey first, then start a gpg decryption, a dialog box opens for me to enter the pin. I do, press enter, then press yubikey, all fine. If I do NOT insert the yubikey and start the gpg decryption, a dialog box with ok/cancel buttons opens saying "Please insert card ". I can insert the yubikey and press OK, it doesnt care, it asks again. And continues asking until I cancel *OR* sudo restart pcscd. After the sudo restart it happily talks to the yubikey and lets me enter pin, press yubikey and done. I think I found the problem. In my case "gpg --card-status" works only if pcscd is NOT running. GnuPG has its own way to access the smart card readers (here a yubikey) I propose two possible solutions: 1. remove pcscd from your system but that is a drastic change. No PC/SC application will work any more. 2. configure scdaemon to NOT use its internal CCID driver but use the PC/SC interface instead To make option 2 just edit/create the scdaemon configuration file as bellow: $ cat ~/.gnupg/scdaemon.conf disable-ccid I think the problem could be reassigned to scdaemon package. Maybe scdaemon could use PC/SC by default. And switch to its internal CCID driver only if PC/SC is not available? Bye -- Dr. Ludovic Rousseau
Bug#924914: pcscd: socket activation masks socket
Le 18/03/2019 à 11:40, Mathias Behrle a écrit : Package: pcscd Version: 1.8.24-1 Severity: important Tags: patch Dear Maintainer, Hello, pcscd.socket masks the socket of pcscd, which is then not available for programs needing it (e.g. can easily reproduced by running pcsc_scan). What are the steps to reproduce the problem? The additional line SocketMode=0666 in pcscd.socket re-instates the usual socket as usually created by pcscd. the socket is now created by systemd, not pcscd. Unless you have a special configuration. I don't understand what problem you have. Please describe it. Bye -- Dr. Ludovic Rousseau
Bug#845223: 0ad: Crashes on startup with cache.cpp(43): Assertion failed: "cache.Validate()"
Hello Cacatoes, I just uploaded 0ad version 0.0.23.1 to unstable. Can you check your problem is still present in this version? if the problem is still present I suggest you to add a comment on your upstream bug http://trac.wildfiregames.com/ticket/4360 to let them know the problem is not yet fixed. Bye Le 01/12/2016 à 16:58, cacat...@tuxfamily.org a écrit : Posted there (a week ago): http://trac.wildfiregames.com/ticket/4360 Waiting for their feedback. Le lundi 21 novembre 2016 à 10:34:14, Vincent Cheng a écrit : Control: tag -1 + moreinfo unreproducible Hi, On Mon, Nov 21, 2016 at 8:35 AM, wrote: Package: 0ad Version: 0.0.21-2 Hiya, I just installed 0ad on my system. It crashes as soon as I start the game. See attachment for crash log. If I say "go on", it manages to play the music. note: I thought there was a -dbg package, but not in my repos. 0ad has now migrated to using auto-generated dbgsym packages (like many other packages in Debian sid). You'll have to add an additional line to your sources.list to pick up the dbgsym repository [1]. Please file a bug report upstream after obtaining a backtrace at [2]. Regards, Vincent [1] https://lists.debian.org/debian-devel/2015/12/msg00262.html [2] http://trac.wildfiregames.com/newticket -- Dr. Ludovic Rousseau
Bug#912891: pcsc-tools: Depends on libgtk2-perl, that won't be part of Bullseye
Le 05/11/2018 à 19:11, Ludovic Rousseau a écrit : Hello, Le 04/11/2018 à 19:25, intrig...@debian.org a écrit : Source: pcsc-tools Severity: normal X-Debbugs-Cc: lionel.vic...@unforgettable.com User: debian-p...@lists.debian.org Usertags: gtk2-removal Hi! This package depends on libgtk2-perl, that I intend to remove from testing soon after the Buster release, and then from sid at some later point during the Bullseye development cycle: https://bugs.debian.org/912860 Please get in touch with the upstream project and suggest they port this application to libgtk3-perl. I've personally ported a couple Perl GTK+ apps from 2.x to 3.x and it's rather straightforward. Upstream for the GTK+ 3 and GObject Introspection Perl bindings is responsive and happy to add missing bits to the bindings. I am the Debian maintainer and also the only upsteam maintainer. Boilerplate put aside, apparently the only GTK+ 2 program shipped in this package is the gscriptor GUI. I'm therefore directly Cc'ing Lionel Victor, who's the upstream author according to the homepage :) I would be surprised if we get support from Lionel. I will try to port gscriptor to Gtk+3. If it is too dificult I may remove it from the Debian package. gscriptor uses Gtk2::SimpleMenu. I could not find an equivalent for Gtk3 :-( I do not use gscriptor any more and do not use the PCSC Perl wrapper much these days. So I do not plan to invest time in porting gscriptor to libgtk3-perl. My plan is to remove gscriptor from the pcsc-tools package after the release of Buster. Unless someone provides a patch in the meantime. Regards, -- Dr. Ludovic Rousseau
Bug#912891: pcsc-tools: Depends on libgtk2-perl, that won't be part of Bullseye
Hello, Le 04/11/2018 à 19:25, intrig...@debian.org a écrit : Source: pcsc-tools Severity: normal X-Debbugs-Cc: lionel.vic...@unforgettable.com User: debian-p...@lists.debian.org Usertags: gtk2-removal Hi! This package depends on libgtk2-perl, that I intend to remove from testing soon after the Buster release, and then from sid at some later point during the Bullseye development cycle: https://bugs.debian.org/912860 Please get in touch with the upstream project and suggest they port this application to libgtk3-perl. I've personally ported a couple Perl GTK+ apps from 2.x to 3.x and it's rather straightforward. Upstream for the GTK+ 3 and GObject Introspection Perl bindings is responsive and happy to add missing bits to the bindings. I am the Debian maintainer and also the only upsteam maintainer. Boilerplate put aside, apparently the only GTK+ 2 program shipped in this package is the gscriptor GUI. I'm therefore directly Cc'ing Lionel Victor, who's the upstream author according to the homepage :) I would be surprised if we get support from Lionel. I will try to port gscriptor to Gtk+3. If it is too dificult I may remove it from the Debian package. Bye -- Dr. Ludovic Rousseau
Bug#912760: black: Fails to install with SyntaxError: invalid syntax
Package: black
Version: 18.9b0-1-4
Severity: normal
Dear Maintainer,
If I install black I get:
$ sudo LANG=C apt install black
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
python-black-doc
The following NEW packages will be installed:
black
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/75.3 kB of archives.
After this operation, 334 kB of additional disk space will be used.
Selecting previously unselected package black.
(Reading database ... 224706 files and directories currently installed.)
Preparing to unpack .../black_18.9b0-1-4_all.deb ...
Unpacking black (18.9b0-1-4) ...
Setting up black (18.9b0-1-4) ...
File "/usr/lib/python3/dist-packages/black.py", line 128
) -> "FileMode":
^
SyntaxError: invalid syntax
File "/usr/lib/python3/dist-packages/blackd.py", line 31
black.out(f"blackd version {ver} listening on {bind_host} port {bind_port}")
^
SyntaxError: invalid syntax
File "/usr/lib/python3/dist-packages/blib2to3/pgen2/tokenize.py", line 123
**{f"{prefix}'''": single3prog for prefix in _strprefixes},
^
SyntaxError: invalid syntax
dpkg: error processing package black (--configure):
subprocess installed post-installation script returned error exit status 1
Processing triggers for man-db (2.7.6.1-2) ...
Errors were encountered while processing:
black
E: Sub-process /usr/bin/dpkg returned an error code (1)
I also get the error if I run black alone:
$ black
Traceback (most recent call last):
File "/usr/bin/black", line 11, in
load_entry_point('black==18.9b0', 'console_scripts', 'black')()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 561, in
load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2631,
in load_entry_point
return ep.load()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2291,
in load
return self.resolve()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2297,
in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
File "/usr/lib/python3/dist-packages/black.py", line 128
) -> "FileMode":
^
SyntaxError: invalid syntax
Maybe black depends on a newer version of Python3 than 3.5.3?
I have not tried to upgrade python3.
>From https://pypi.org/project/black/ I read:
" Black can be installed by running pip install black. It requires
Python 3.6.0+ to run but you can reformat Python 2 code with it, too. "
I suggest to update the package dependency on python3.
Bye
-- System Information:
Debian Release: 9.5
APT prefers stable
APT policy: (990, 'stable'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages black depends on:
ii python33.5.3-1
ii python3-appdirs1.4.0-3
ii python3-attr 16.3.0-1
ii python3-click 6.6-1
ii python3-pkg-resources 33.1.1-1
ii python3-toml 0.9.1-1
black recommends no packages.
Versions of packages black suggests:
pn python-black-doc
-- no debconf information
Bug#911220: stretch-pu: package jhead/1:3.00-4
Le 21/10/2018 à 12:49, Adam D. Barratt a écrit : Control: tags -1 + confirmed On Wed, 2018-10-17 at 22:21 +0200, Ludovic Rousseau wrote: Le 17/10/2018 à 11:15, Salvatore Bonaccorso a écrit : Hi [Disclaimer: not a SRM but looking at the proposed update] On Wed, Oct 17, 2018 at 10:28:15AM +0200, Ludovic Rousseau wrote: +jhead (1:3.00-4.1) stable; urgency=high Please use 1:3.00-4+deb9u1 as version. Using the codename instead of 'stable' would be prefered, but both work. Thanks a lot for preparing the update! New patch version with the package version fixed. Please go ahead. Just uploaded. Bye -- Dr. Ludovic Rousseau
Bug#911220: stretch-pu: package jhead/1:3.00-4
Le 17/10/2018 à 11:15, Salvatore Bonaccorso a écrit :
Hi
[Disclaimer: not a SRM but looking at the proposed update]
On Wed, Oct 17, 2018 at 10:28:15AM +0200, Ludovic Rousseau wrote:
+jhead (1:3.00-4.1) stable; urgency=high
Please use 1:3.00-4+deb9u1 as version. Using the codename instead of
'stable' would be prefered, but both work.
Thanks a lot for preparing the update!
New patch version with the package version fixed.
Bye
--
Dr. Ludovic Rousseau
diff -Nru jhead-3.00/debian/changelog jhead-3.00/debian/changelog
--- jhead-3.00/debian/changelog 2017-03-20 20:26:16.0 +0100
+++ jhead-3.00/debian/changelog 2018-10-16 10:38:19.0 +0200
@@ -1,3 +1,11 @@
+jhead (1:3.00-4+deb9u1) stretch; urgency=high
+
+ * d/p/32_crash_in_gpsinfo: Fix CVE-2018-17088
+ * d/p/33_fix_908176: Fix CVE-2018-16554
+ * d/p/34_buffer_overflow: Fix heap buffer overflow
+
+ -- Ludovic Rousseau Tue, 16 Oct 2018 10:38:19 +0200
+
jhead (1:3.00-4) unstable; urgency=medium
* Fix "CVE-2016-3822" Apply patch from Google (Closes: #858213)
diff -Nru jhead-3.00/debian/patches/32_crash_in_gpsinfo
jhead-3.00/debian/patches/32_crash_in_gpsinfo
--- jhead-3.00/debian/patches/32_crash_in_gpsinfo 1970-01-01
01:00:00.0 +0100
+++ jhead-3.00/debian/patches/32_crash_in_gpsinfo 2018-10-16
10:33:06.0 +0200
@@ -0,0 +1,26 @@
+From: Ludovic Rousseau
+Date: Wed Sep 5 15:32:00 CEST 2018
+Subject: Fix heap buffer overflow
+
+Bug-Debian: http://bugs.debian.org/907925
+Description: Fix CVE-2018-17088
+
+--- a/gpsinfo.c
b/gpsinfo.c
+@@ -4,6 +4,7 @@
+ // Matthias Wandel, Dec 1999 - Dec 2002
+ //--
+ #include "jhead.h"
++#include
+
+ #define MAX_GPS_TAG 0x1e
+
+@@ -101,7 +102,7 @@
+ unsigned OffsetVal;
+ OffsetVal = Get32u(DirEntry+8);
+ // If its bigger than 4 bytes, the dir entry contains an offset.
+-if (OffsetVal+ByteCount > ExifLength){
++if (OffsetVal > UINT32_MAX - ByteCount || OffsetVal+ByteCount >
ExifLength){
+ // Bogus pointer offset and / or bytecount value
+ ErrNonfatal("Illegal value pointer for Exif gps tag %04x",
Tag,0);
+ continue;
diff -Nru jhead-3.00/debian/patches/33_fix_908176
jhead-3.00/debian/patches/33_fix_908176
--- jhead-3.00/debian/patches/33_fix_908176 1970-01-01 01:00:00.0
+0100
+++ jhead-3.00/debian/patches/33_fix_908176 2018-10-16 10:35:19.00000
+0200
@@ -0,0 +1,19 @@
+From: Ludovic Rousseau
+Date: Sat Sep 8 16:19:07 CEST 2018
+Subject: fix heap buffer overflow
+
+Bug-Debian: https://bugs.debian.org/908176
+Description: Fix CVE-2018-16554
+
+--- a/gpsinfo.c
b/gpsinfo.c
+@@ -162,7 +162,8 @@
+ break;
+
+ case TAG_GPS_ALT:
+-sprintf(ImageInfo.GpsAlt + 1, "%.2fm",
++snprintf(ImageInfo.GpsAlt + 1, sizeof(ImageInfo.GpsAlt) -1,
++"%.2fm",
+ ConvertAnyFormat(ValuePtr, Format));
+ break;
+ }
diff -Nru jhead-3.00/debian/patches/34_buffer_overflow
jhead-3.00/debian/patches/34_buffer_overflow
--- jhead-3.00/debian/patches/34_buffer_overflow1970-01-01
01:00:00.0 +0100
+++ jhead-3.00/debian/patches/34_buffer_overflow2018-10-16
10:36:45.0 +0200
@@ -0,0 +1,15 @@
+From: Ludovic Rousseau
+Date: Sat Sep 8 16:02:23 CEST 2018
+Subject: Fix heap buffer overflow
+
+--- a/jhead.c
b/jhead.c
+@@ -670,7 +670,7 @@
+ NameExtra[0] = 0;
+ }
+
+-sprintf(NewName, "%s%s.jpg", NewBaseName, NameExtra);
++snprintf(NewName, sizeof(NewName), "%s%s.jpg", NewBaseName,
NameExtra);
+
+ if (!strcmp(FileName, NewName)) break; // Skip if its already this
name.
+
diff -Nru jhead-3.00/debian/patches/series jhead-3.00/debian/patches/series
--- jhead-3.00/debian/patches/series2017-03-20 20:26:16.0 +0100
+++ jhead-3.00/debian/patches/series2018-10-16 10:37:07.0 +0200
@@ -5,3 +5,6 @@
25_makefile
27_documentation
31_CVE-2016-3822
+32_crash_in_gpsinfo
+33_fix_908176
+34_buffer_overflow
Bug#911220: stretch-pu: package jhead/1:3.00-4
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Hello,
Some CVE were reported for jhead. I talked to Debian security team.
The security issues are not critical and Salvatore Bonaccorso proposed
to update the package in stable using stretch-pu instead of the security
team.
The issues are already fixed in Debian unstable. I just reused the
patches (from debian/patches/) for stretch-pu.
changes:
* d/p/32_crash_in_gpsinfo: Fix CVE-2018-17088
* d/p/33_fix_908176: Fix CVE-2018-16554
* d/p/34_buffer_overflow: Fix heap buffer overflow
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8),
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru jhead-3.00/debian/changelog jhead-3.00/debian/changelog
--- jhead-3.00/debian/changelog 2017-03-20 19:26:16.0 +
+++ jhead-3.00/debian/changelog 2018-10-16 08:38:19.0 +
@@ -1,3 +1,11 @@
+jhead (1:3.00-4.1) stable; urgency=high
+
+ * d/p/32_crash_in_gpsinfo: Fix CVE-2018-17088
+ * d/p/33_fix_908176: Fix CVE-2018-16554
+ * d/p/34_buffer_overflow: Fix heap buffer overflow
+
+ -- Ludovic Rousseau Tue, 16 Oct 2018 10:38:19 +0200
+
jhead (1:3.00-4) unstable; urgency=medium
* Fix "CVE-2016-3822" Apply patch from Google (Closes: #858213)
diff -Nru jhead-3.00/debian/patches/32_crash_in_gpsinfo
jhead-3.00/debian/patches/32_crash_in_gpsinfo
--- jhead-3.00/debian/patches/32_crash_in_gpsinfo 1970-01-01
00:00:00.0 +
+++ jhead-3.00/debian/patches/32_crash_in_gpsinfo 2018-10-16
08:33:06.0 +
@@ -0,0 +1,26 @@
+From: Ludovic Rousseau
+Date: Wed Sep 5 15:32:00 CEST 2018
+Subject: Fix heap buffer overflow
+
+Bug-Debian: http://bugs.debian.org/907925
+Description: Fix CVE-2018-17088
+
+--- a/gpsinfo.c
b/gpsinfo.c
+@@ -4,6 +4,7 @@
+ // Matthias Wandel, Dec 1999 - Dec 2002
+ //--
+ #include "jhead.h"
++#include
+
+ #define MAX_GPS_TAG 0x1e
+
+@@ -101,7 +102,7 @@
+ unsigned OffsetVal;
+ OffsetVal = Get32u(DirEntry+8);
+ // If its bigger than 4 bytes, the dir entry contains an offset.
+-if (OffsetVal+ByteCount > ExifLength){
++if (OffsetVal > UINT32_MAX - ByteCount || OffsetVal+ByteCount >
ExifLength){
+ // Bogus pointer offset and / or bytecount value
+ ErrNonfatal("Illegal value pointer for Exif gps tag %04x",
Tag,0);
+ continue;
diff -Nru jhead-3.00/debian/patches/33_fix_908176
jhead-3.00/debian/patches/33_fix_908176
--- jhead-3.00/debian/patches/33_fix_908176 1970-01-01 00:00:00.0
+
+++ jhead-3.00/debian/patches/33_fix_908176 2018-10-16 08:35:19.00000
+
@@ -0,0 +1,19 @@
+From: Ludovic Rousseau
+Date: Sat Sep 8 16:19:07 CEST 2018
+Subject: fix heap buffer overflow
+
+Bug-Debian: https://bugs.debian.org/908176
+Description: Fix CVE-2018-16554
+
+--- a/gpsinfo.c
b/gpsinfo.c
+@@ -162,7 +162,8 @@
+ break;
+
+ case TAG_GPS_ALT:
+-sprintf(ImageInfo.GpsAlt + 1, "%.2fm",
++snprintf(ImageInfo.GpsAlt + 1, sizeof(ImageInfo.GpsAlt) -1,
++"%.2fm",
+ ConvertAnyFormat(ValuePtr, Format));
+ break;
+ }
diff -Nru jhead-3.00/debian/patches/34_buffer_overflow
jhead-3.00/debian/patches/34_buffer_overflow
--- jhead-3.00/debian/patches/34_buffer_overflow1970-01-01
00:00:00.0 +
+++ jhead-3.00/debian/patches/34_buffer_overflow2018-10-16
08:36:45.0 +
@@ -0,0 +1,15 @@
+From: Ludovic Rousseau
+Date: Sat Sep 8 16:02:23 CEST 2018
+Subject: Fix heap buffer overflow
+
+--- a/jhead.c
b/jhead.c
+@@ -670,7 +670,7 @@
+ NameExtra[0] = 0;
+ }
+
+-sprintf(NewName, "%s%s.jpg", NewBaseName, NameExtra);
++snprintf(NewName, sizeof(NewName), "%s%s.jpg", NewBaseName,
NameExtra);
+
+ if (!strcmp(FileName, NewName)) break; // Skip if its already this
name.
+
diff -Nru jhead-3.00/debian/patches/series jhead-3.00/debian/patches/series
--- jhead-3.00/debian/patches/series2017-03-20 19:26:16.0 +
+++ jhead-3.00/debian/patches/series2018-10-16 08:37:07.0 +
@@ -5,3 +5,6 @@
25_makefile
27_documentation
31_CVE-2016-3822
+32_crash_in_gpsinfo
+33_fix_908176
+34_buffer_overflow
Bug#908176: jhead: Buffer Overflow while running jhead
Hello,
Have you requested a CVE number for this issue?
Have you received the CVE number value ?
Bye
Le 10/09/2018 à 11:06, Hanfang Zhang a écrit :
Sorry, I don't have it. Once I receive the CVE ID number, I will give it to you
as soon as possible.
Ludovic Rousseau mailto:ludovic.rouss...@gmail.com>> 于2018年9月8日周六 下午11:01写道：
Le 08/09/2018 à 03:05, Hanfang Zhang a écrit :
> Hello,
>
> Done. Thanks a lot.
Do you have the CVE ID number?
Can you give it to us please?
Thanks
--
Dr. Ludovic Rousseau
--
Dr. Ludovic Rousseau
Bug#908523: libcppunit-dev: cppunit.m4 is no more provided
Package: libcppunit-dev Version: 1.14.0-3 Severity: important Hello, The file /usr/share/aclocal/cppunit.m4 is not (no more) provided by this package. From /usr/share/doc/libcppunit-dev/changelog.gz I found: 2016-10-15 Markus Mohrhard [fcc84eec40acf8506f2a5fcc3fe0399663d1ce18] cppunit.m4 is gone But /usr/share/doc/libcppunit-dev/README.Debian contains a documentation of the M4 macro AM_PATH_CPPUNIT() Another strange thing is that /usr/share/aclocal/cppunit.m4 is listed as provided by libcppunit-dev from unstable by https://packages.debian.org/search?searchon=contents=cppunit.m4=filename=unstable=any The version 1.13.2-2.1 from stable provides the cppunit.m4 I guess the file disappeared with version 1.14. I could not find a replacement for cppunit.m4 in https://www.gnu.org/software/autoconf-archive/The-Macros.html#The-Macros If upstream decided to remove cppunit.m4, which looks to be the case, then maybe you should remove the file /usr/share/doc/libcppunit-dev/README.Debian I also note that cppunit-config was also removed. Using cppunit.m4 from the Debian stable does not work without cppunit-config. I suggest to: - remove README.Debian or, at least, change its content. - add a line in changelog that cppunit-config and cppunit.m4 have been removed upstream and are no more provided Regards, -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-7-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages libcppunit-dev depends on: ii libcppunit-1.14-0 1.14.0-3 libcppunit-dev recommends no packages. Versions of packages libcppunit-dev suggests: pn libcppunit-doc -- no debconf information
Bug#908054: pcscd fails to communicate with smartcard after resuming from suspend-to-RAM
Le 05/09/2018 à 16:34, Nicolas Braud-Santoni a écrit : Package: pcscd Version: 1.8.23-3 Severity: normal Hi, pcscd fails to detect my Yubikey 4 Nano when resuming from suspend-to-disk, resulting in GnuPG prompting me to insert the device; the problem persists even if I unplug and replug the device, and until I restart pcscd. I tried to reproduce the problem but without success. Can you generate a pcscd trace as described in https://pcsclite.apdu.fr/#support Thanks -- Dr. Ludovic Rousseau
Bug#908176: jhead: Buffer Overflow while running jhead
Le 08/09/2018 à 03:05, Hanfang Zhang a écrit : Hello, Done. Thanks a lot. Do you have the CVE ID number? Can you give it to us please? Thanks -- Dr. Ludovic Rousseau
Bug#908176: jhead: Buffer Overflow while running jhead
Hello, Please request a new CVE ID. As Salvatore Bonaccorso wrote in http://bugs.debian.org/907925 " Can you please request a CVE via the webform at https://cveform.mitre.org/ and once the CVE assigned loop it back here?" Thanks Le 07/09/2018 à 05:54, Hanfang Zhang a écrit : Package: jhead Version: 1:3.00-7 Vulerability type: Buffer Overflow An buffer overflow bug was found in jhead, which allows attackers to casue a denial of service via a crafted JPEG file. Components: gpsinfo.c -> ProcessGpsInfo() ->line 164 ``` case TAG_GPS_ALT://BUG sprintf(ImageInfo.GpsAlt + 1, "%.2fm", ConvertAnyFormat(ValuePtr, Format)); break; ``` Output: ``` gdb-peda$ bt #0 0x77739428 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:54 #1 0x7773b02a in __GI_abort () at abort.c:89 #2 0x7777b7ea in __libc_message (do_abort=do_abort@entry=0x2, fmt=fmt@entry=0x7789349f "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:175 #3 0x7781d15c in __GI___fortify_fail (msg=, msg@entry=0x77893430 "buffer overflow detected") at fortify_fail.c:37 #4 0x7781b160 in __GI___chk_fail () at chk_fail.c:28 #5 0x7781a6c9 in _IO_str_chk_overflow (fp=, c=) at vsprintf_chk.c:31 #6 0x7777f6b0 in __GI__IO_default_xsputn (f=0x7fff79b0, data=, n=0x19) at genops.c:455 #7 0x7775625a in __GI___printf_fp_l (fp=fp@entry=0x7fff79b0, loc=, info=info@entry=0x7fff7530, args=args@entry=0x7fff7510) at printf_fp.c:1236 #8 0x77756bd9 in ___printf_fp (fp=fp@entry=0x7fff79b0, info=info@entry=0x7fff7530, args=args@entry=0x7fff7510) at printf_fp.c:1257 #9 0x777530b9 in _IO_vfprintf_internal (s=s@entry=0x7fff79b0, format=, format@entry=0x40f640 "%.2fm", ap=ap@entry=0x7fff7ae8) at vfprintf.c:1631 #10 0x7781a754 in ___vsprintf_chk (s=0x61659f "944473296573929042", flags=0x1, slen=0x13, format=0x40f640 "%.2fm", args=args@entry=0x7fff7ae8) at vsprintf_chk.c:82 #11 0x7781a6ad in ___sprintf_chk (s=, flags=flags@entry=0x1, slen=slen@entry=0x13, format=format@entry=0x40f640 "%.2fm") at sprintf_chk.c:31 #12 0x00409649 in sprintf (__fmt=0x40f640 "%.2fm", __s=) at /usr/include/x86_64-linux-gnu/bits/stdio2.h:33 #13 ProcessGpsInfo (DirStart=, OffsetBase=OffsetBase@entry=0x6182d8 "MM", ExifLength=ExifLength@entry=0x13e) at gpsinfo.c:164 #14 0x00407980 in ProcessExifDir (DirStart=DirStart@entry=0x6182e0 "", OffsetBase=OffsetBase@entry=0x6182d8 "MM", ExifLength=ExifLength@entry=0x13e, NestingLevel=NestingLevel@entry=0x0) at exif.c:867 #15 0x00407b86 in process_EXIF (ExifSection=ExifSection@entry=0x6182d0 "\001FExif", length=length@entry=0x146) at exif.c:1035 #16 0x00404ab3 in ReadJpegSections (infile=infile@entry=0x617070, ReadMode=ReadMode@entry=READ_METADATA) at jpgfile.c:287 #17 0x00404dce in ReadJpegSections (ReadMode=READ_METADATA, infile=0x617070) at jpgfile.c:126 #18 ReadJpegFile (FileName=FileName@entry=0x7fffe376 "poc", ReadMode=READ_METADATA) at jpgfile.c:375 #19 0x00402ac1 in ProcessFile (FileName=0x7fffe376 "poc") at jhead.c:896 #20 0x0040183c in main (argc=argc@entry=0x2, argv=argv@entry=0x7fffdff8) at jhead.c:1729 #21 0x77724830 in __libc_start_main (main=0x4016b0 , argc=0x2, argv=0x7fffdff8, init=, fini=, rtld_fini=, stack_end=0x7fffdfe8) at ../csu/libc-start.c:291 #22 0x00402219 in _start () ``` ConvertAnyFormat function converts ValuePtr to another data type by using Format value. When Format value equals to 11, the ValuePtr should be convert to double type. There is no type checking in the parameters in sprintf function. In this case, “%.2fm” corresponds to the float type data, ConvertAnyFormat() corresponds to the double type data. So it causes undesirable behavior including buffer overflow. Replacing sprintf with snprintf may fix this bug. -- Dr. Ludovic Rousseau
Bug#907925: jhead: Interger overflow while running jhead
Le 05/09/2018 à 12:42, Hanfang Zhang a écrit : I'm sorry, I did not run jhead with Debian patches before. I patched it just now. But I did not see the patch file for gpsinfo.c. So this vulnerability stiil exists in gpsinfo.c(line 104). I am not sure if I missed the patch file. The poc is in the attachment. Exact. With the poc file I can reproduce the crash. I reopened the bug and will provide a fix. Thanks -- Dr. Ludovic Rousseau
Bug#905630: SCardConnect sometimes hangs
Le 07/08/2018 à 13:24, Wouter Verhelst a écrit : I'm not sure where this is coming from, but would be happy to perform any required debugging steps. Thanks Wouter for the bug report. I have some questions: - do you also have the problem if you use only 1 reader instead of 3 (so if you do _not_ use vsmartcard) - do you start the second instance of the program immediately after the first run? or you can run the second instance 1 second after the first and still get the problem? I can reproduce the behaviour you get by removing/commenting the line 288 at https://salsa.debian.org/rousseau/PCSC/blob/master/src/winscard.c#L288 I am suspecting a race condition issue somewhere. But I have no idea how to reproduce it. What could help is to get pcscd logs when the problem occurs. But I understand it is not easy if you don't know how to reproduce the problem. https://pcsclite.apdu.fr/#support Thanks -- Dr. Ludovic Rousseau
Bug#896746: ACR38: No smart card readers found
Hello, 2018-04-24 9:01 GMT+02:00 Christophe Siraut <d...@tobald.eu.org>: > Package: libccid > Version: 1.4.29-2 > Severity: normal > > Dear Maintainer, > > I am trying to use my eid ACR38 eid reader without success, eid-viewer and > opensc-tool give "No smart card readers found." > > I am running debian stable, and tried installing libccid and pcsd from buster > with no better result. Here is information I noticed: > > $ lsusb | grep -i smart > Bus 001 Device 007: ID 072f:9000 Advanced Card Systems, Ltd ACR38 > AC1038-based Smart Card Reader I do not yet have this device in my list. Please follow https://ccid.apdu.fr/#CCID_compliant Thanks -- Dr. Ludovic Rousseau
Bug#895703: Continuous LIBUSB_ERROR_NO_DEVICE in journal after removing a Yubikey 4 (USB-C)
Le 17/04/2018 à 21:09, Ludovic Rousseau a écrit : I should receive a Yubikey 4 (USB-C) in the next few days. It will be much simpler for me to debug. I may ask you to test some patches. Good news: I received the Yubikey 4 (USB-C). But I can't reproduce your problem. Removing the reader does generate just the expected logs. I am also using Linux 4.15.0-2-amd64 and libudev 238. But I note that inserting and removing the device does not generate errors by the kernel. All I have is: [ 407.243325] usb 1-6: new full-speed USB device number 9 using xhci_hcd [ 407.396507] usb 1-6: New USB device found, idVendor=1050, idProduct=0407 [ 407.396508] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 407.396509] usb 1-6: Product: Yubikey 4 OTP+U2F+CCID [ 407.396510] usb 1-6: Manufacturer: Yubico [ 407.397328] input: Yubico Yubikey 4 OTP+U2F+CCID as /devices/pci:00/:00:14.0/usb1/1-6/1-6:1.0/0003:1050:0407.0004/input/input21 [ 407.455471] hid-generic 0003:1050:0407.0004: input,hidraw3: USB HID v1.10 Keyboard [Yubico Yubikey 4 OTP+U2F+CCID] on usb-:00:14.0-6/input0 [ 407.455908] hid-generic 0003:1050:0407.0005: hiddev1,hidraw4: USB HID v1.10 Device [Yubico Yubikey 4 OTP+U2F+CCID] on usb-:00:14.0-6/input1 [ 1518.978726] usb 1-6: USB disconnect, device number 9 [ 1872.091734] usb 1-6: new full-speed USB device number 11 using xhci_hcd [ 1872.245239] usb 1-6: New USB device found, idVendor=1050, idProduct=0407 [ 1872.245245] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 1872.245249] usb 1-6: Product: Yubikey 4 OTP+U2F+CCID [ 1872.245252] usb 1-6: Manufacturer: Yubico [ 1872.246890] input: Yubico Yubikey 4 OTP+U2F+CCID as /devices/pci:00/:00:14.0/usb1/1-6/1-6:1.0/0003:1050:0407.0006/input/input22 [ 1872.304327] hid-generic 0003:1050:0407.0006: input,hidraw3: USB HID v1.10 Keyboard [Yubico Yubikey 4 OTP+U2F+CCID] on usb-:00:14.0-6/input0 [ 1872.305317] hid-generic 0003:1050:0407.0007: hiddev1,hidraw4: USB HID v1.10 Device [Yubico Yubikey 4 OTP+U2F+CCID] on usb-:00:14.0-6/input1 [ 1950.659554] usb 1-6: USB disconnect, device number 11 [ 1984.360782] usb 1-6: new full-speed USB device number 12 using xhci_hcd [ 1984.510271] usb 1-6: New USB device found, idVendor=1050, idProduct=0407 [ 1984.510277] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 1984.510281] usb 1-6: Product: Yubikey 4 OTP+U2F+CCID [ 1984.510284] usb 1-6: Manufacturer: Yubico [ 1984.511996] input: Yubico Yubikey 4 OTP+U2F+CCID as /devices/pci:00/:00:14.0/usb1/1-6/1-6:1.0/0003:1050:0407.0008/input/input23 [ 1984.569220] hid-generic 0003:1050:0407.0008: input,hidraw3: USB HID v1.10 Keyboard [Yubico Yubikey 4 OTP+U2F+CCID] on usb-:00:14.0-6/input0 [ 1984.570153] hid-generic 0003:1050:0407.0009: hiddev1,hidraw4: USB HID v1.10 Device [Yubico Yubikey 4 OTP+U2F+CCID] on usb-:00:14.0-6/input1 [ 1993.440429] usb 1-6: USB disconnect, device number 12 [ 2036.725274] usb 1-6: new full-speed USB device number 13 using xhci_hcd [ 2036.874688] usb 1-6: New USB device found, idVendor=1050, idProduct=0407 [ 2036.874694] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 2036.874698] usb 1-6: Product: Yubikey 4 OTP+U2F+CCID [ 2036.874702] usb 1-6: Manufacturer: Yubico [ 2036.876363] input: Yubico Yubikey 4 OTP+U2F+CCID as /devices/pci:00/:00:14.0/usb1/1-6/1-6:1.0/0003:1050:0407.000A/input/input24 [ 2036.933888] hid-generic 0003:1050:0407.000A: input,hidraw3: USB HID v1.10 Keyboard [Yubico Yubikey 4 OTP+U2F+CCID] on usb-:00:14.0-6/input0 [ 2036.934970] hid-generic 0003:1050:0407.000B: hiddev1,hidraw4: USB HID v1.10 Device [Yubico Yubikey 4 OTP+U2F+CCID] on usb-:00:14.0-6/input1 [ 2043.621652] usb 1-6: USB disconnect, device number 13 [ 2167.939041] usb 1-6: new full-speed USB device number 14 using xhci_hcd [ 2168.088491] usb 1-6: New USB device found, idVendor=1050, idProduct=0407 [ 2168.088497] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 2168.088501] usb 1-6: Product: Yubikey 4 OTP+U2F+CCID [ 2168.088505] usb 1-6: Manufacturer: Yubico [ 2168.090123] input: Yubico Yubikey 4 OTP+U2F+CCID as /devices/pci:00/:00:14.0/usb1/1-6/1-6:1.0/0003:1050:0407.000C/input/input25 [ 2168.147825] hid-generic 0003:1050:0407.000C: input,hidraw3: USB HID v1.10 Keyboard [Yubico Yubikey 4 OTP+U2F+CCID] on usb-:00:14.0-6/input0 [ 2168.148955] hid-generic 0003:1050:0407.000D: hiddev1,hidraw4: USB HID v1.10 Device [Yubico Yubikey 4 OTP+U2F+CCID] on usb-:00:14.0-6/input1 [ 2170.605150] usb 1-6: USB disconnect, device number 14 [ 2188.483322] usb 1-6: new full-speed USB device number 15 using xhci_hcd [ 2188.632824] usb 1-6: New USB device found, idVendor=1050, idProduct=0407 [ 2188.632830] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 2188.632834] usb 1-6: Product: Yubikey 4 OTP+U2F+CCID [ 2188.632837] usb 1-6: Manufacturer: Yubico [ 2188.634641] input: Yubico
Bug#895703: Continuous LIBUSB_ERROR_NO_DEVICE in journal after removing a Yubikey 4 (USB-C)
Le 16/04/2018 à 01:45, Luke Faraone a écrit : On Sun, Apr 15, 2018 at 7:39 PM, Ludovic Rousseau <ludovic.rouss...@free.fr> wrote: The problem is with the call to udev_device_get_parent_with_subsystem_devtype() https://salsa.debian.org/rousseau/PCSC/blob/master/src/hotplug_libudev.c#L338 Maybe USB-C ports are different than "normal" USB. Yeah, attaching USB-C devices always generates xhci / pcieport spew in dmesg. (enclosed for curiosity) Also please generate a "udevadm monitor" log. Start "udevadm monitor --property" (no need to be root) Plug the reader Unplug the reader and send me the output. Attached. Thanks. I was not expecting so much events just for one device. I should receive a Yubikey 4 (USB-C) in the next few days. It will be much simpler for me to debug. I may ask you to test some patches. Bye -- Dr. Ludovic Rousseau
Bug#895703: Continuous LIBUSB_ERROR_NO_DEVICE in journal after removing a Yubikey 4 (USB-C)
Le 15/04/2018 à 21:09, Luke Faraone a écrit :
On Sun, Apr 15, 2018 at 6:01 PM, Ludovic Rousseau
<ludovic.rouss...@free.fr> wrote:
Exact.
Try with this new patch.
You will have to remove the previous patch, or start from the clean sources
first.
Aha, now we have something.
The problem is with the call to udev_device_get_parent_with_subsystem_devtype()
https://salsa.debian.org/rousseau/PCSC/blob/master/src/hotplug_libudev.c#L338
Maybe USB-C ports are different than "normal" USB.
Also please generate a "udevadm monitor" log.
Start "udevadm monitor --property" (no need to be root)
Plug the reader
Unplug the reader
and send me the output.
Thanks
--
Dr. Ludovic Rousseau
diff --git a/src/hotplug_libudev.c b/src/hotplug_libudev.c
index 184b6b3..1601a95 100644
--- a/src/hotplug_libudev.c
+++ b/src/hotplug_libudev.c
@@ -330,15 +330,25 @@ static void HPRemoveDevice(struct udev_device *dev)
struct udev_device *parent;
const char *sysname;
+ sysname = udev_device_get_sysname(dev);
+ if (!sysname)
+ {
+ Log1(PCSC_LOG_ERROR, "udev_device_get_sysname() failed");
+ return;
+ }
+ Log2(PCSC_LOG_DEBUG, "removing sysname: %s", sysname);
+
/* The device pointed to by dev contains information about
the interface. In order to get information about the USB
device, get the parent device with the subsystem/devtype pair
of "usb"/"usb_device". This will be several levels up the
tree, but the function will find it.*/
- parent = udev_device_get_parent_with_subsystem_devtype(dev, "usb",
- "usb_device");
+ parent = udev_device_get_parent_with_subsystem_devtype(dev, "usb",
NULL);
if (!parent)
+ {
+ Log0(PCSC_LOG_DEBUG);
return;
+ }
devpath = udev_device_get_devnode(parent);
if (!devpath)
@@ -348,13 +358,6 @@ static void HPRemoveDevice(struct udev_device *dev)
return;
}
- sysname = udev_device_get_sysname(dev);
- if (!sysname)
- {
- Log1(PCSC_LOG_ERROR, "udev_device_get_sysname() failed");
- return;
- }
-
for (i=0; i<PCSCLITE_MAX_READERS_CONTEXTS; i++)
{
if (readerTracker[i].fullName && !strcmp(sysname,
readerTracker[i].sysname))
Bug#895703: Continuous LIBUSB_ERROR_NO_DEVICE in journal after removing a Yubikey 4 (USB-C)
Le 15/04/2018 à 17:59, Luke Faraone a écrit :
Enclosed. Doesn't appear to have changed the output.
Exact.
Try with this new patch.
You will have to remove the previous patch, or start from the clean sources
first.
Thanks
--
Dr. Ludovic Rousseau
diff --git a/src/hotplug_libudev.c b/src/hotplug_libudev.c
index 184b6b3..534aae3 100644
--- a/src/hotplug_libudev.c
+++ b/src/hotplug_libudev.c
@@ -330,6 +330,14 @@ static void HPRemoveDevice(struct udev_device *dev)
struct udev_device *parent;
const char *sysname;
+ sysname = udev_device_get_sysname(dev);
+ if (!sysname)
+ {
+ Log1(PCSC_LOG_ERROR, "udev_device_get_sysname() failed");
+ return;
+ }
+ Log2(PCSC_LOG_DEBUG, "removing sysname: %s", sysname);
+
/* The device pointed to by dev contains information about
the interface. In order to get information about the USB
device, get the parent device with the subsystem/devtype pair
@@ -338,7 +346,10 @@ static void HPRemoveDevice(struct udev_device *dev)
parent = udev_device_get_parent_with_subsystem_devtype(dev, "usb",
"usb_device");
if (!parent)
+ {
+ Log0(PCSC_LOG_DEBUG);
return;
+ }
devpath = udev_device_get_devnode(parent);
if (!devpath)
@@ -348,13 +359,6 @@ static void HPRemoveDevice(struct udev_device *dev)
return;
}
- sysname = udev_device_get_sysname(dev);
- if (!sysname)
- {
- Log1(PCSC_LOG_ERROR, "udev_device_get_sysname() failed");
- return;
- }
-
for (i=0; i<PCSCLITE_MAX_READERS_CONTEXTS; i++)
{
if (readerTracker[i].fullName && !strcmp(sysname,
readerTracker[i].sysname))
Bug#895703: Continuous LIBUSB_ERROR_NO_DEVICE in journal after removing a Yubikey 4 (USB-C)
Le 15/04/2018 à 17:07, Luke W Faraone a écrit :
On 15/04/18 12:05, Ludovic Rousseau wrote:
- kill any already running pcscd process
- run the newly compiler pcscd
$ sudo src/pcscd --foreground --debug --color | tee log.txt
- connect the Yubikey 4 (USB-C)
- disconnect the device
- stop pcscd by Ctrl-C after the problem occurred
Send me the generated log.txt file.
Attached, thanks!
Please apply the attached patch to pcsc-lite and generate a new log.
Thanks
--
Dr. Ludovic Rousseau
diff --git a/src/hotplug_libudev.c b/src/hotplug_libudev.c
index 184b6b3..c28cba9 100644
--- a/src/hotplug_libudev.c
+++ b/src/hotplug_libudev.c
@@ -354,6 +354,7 @@ static void HPRemoveDevice(struct udev_device *dev)
Log1(PCSC_LOG_ERROR, "udev_device_get_sysname() failed");
return;
}
+ Log3(PCSC_LOG_DEBUG, "removing sysname: %s at %s", sysname, devpath);
for (i=0; i<PCSCLITE_MAX_READERS_CONTEXTS; i++)
{
Bug#895703: Continuous LIBUSB_ERROR_NO_DEVICE in journal after removing a Yubikey 4 (USB-C)
Hello, Le 06/04/2018 à 21:50, Luke W Faraone a écrit : Package: pcscd Version: 1.8.23-2 Severity: normal Dear maintainer, This appears to be similar symptoms to bug #459827, but reporting separately, as this has nothing to do with PCMCIA. After removing a Yubikey 4 (USB-C) from my XPS 13 9360, syslog is filled with errors like this about once a second: ``` Apr 04 11:04:56 zinc pcscd[4147]: ccid_usb.c:849:WriteUSB() write failed (3/2): -4 LIBUSB_ERROR_NO_DEVICE Apr 04 11:04:56 zinc pcscd[4147]: 0056 ifdwrapper.c:364:IFDStatusICC() Card not transacted: 617 Apr 04 11:04:57 zinc pcscd[4147]: 01000882 eventhandler.c:334:EHStatusHandlerThread() Error communicating to: Yubico Yubikey 4 OTP+U2F+CCID 00 00 Apr 04 11:04:57 zinc pcscd[4147]: 0029 ccid_usb.c:1312:InterruptRead() libusb_submit_transfer failed: LIBUSB_ERROR_NO_DEVICE Apr 04 11:04:57 zinc pcscd[4147]: 00400296 ccid_usb.c:849:WriteUSB() write failed (3/2): -4 LIBUSB_ERROR_NO_DEVICE Apr 04 11:04:57 zinc pcscd[4147]: 0017 ifdwrapper.c:364:IFDStatusICC() Card not transacted: 617 ``` This specific issue happened after a resume-from-suspend when the device was removed between suspend and resume, but in general it happens any time I remove the USB-C device. This does not occur with a Yubikey Neo (USB 2.0). I was also able to replicate it on a fellow developer's XPS 13 9350. Please let me know if there is any other debugging information I can provide. Yes, you can help me. - Get the pcsc-lite source code. - Edit src/hotplug_libudev.c and change line 66 to: #define DEBUG_HOTPLUG - rebuild pcsc-lite You do not need to install it. - kill any already running pcscd process - run the newly compiler pcscd $ sudo src/pcscd --foreground --debug --color | tee log.txt - connect the Yubikey 4 (USB-C) - disconnect the device - stop pcscd by Ctrl-C after the problem occurred Send me the generated log.txt file. Thanks -- Dr. Ludovic Rousseau
Bug#890126: libccid: C3PO LTC32 v2 doesn't work well when the PIN number of a card is required
Le 11/02/2018 à 13:06, robert a écrit : Package: libccid Version: 1.4.28-2 Severity: important Dear Maintainer, Hello, 1) What led up to the situation? Trying to use the card reader with the Belgium ID card to access the Belgium online services for the citizens. (http://www.ibz.rrn.fgov.be/fr/registre-national/mon-dossier/). 2) What exactly did you do (or not do) that was effective (or ineffective)? The reader works with the Spanish ID card but no PIN is required (at least in the web sites I used it before such as https://www.sedecatastro.gob.es/). The BeID card is recognised by pcsd_scan. When trying to access the Belgium online services, a window pops up showing the information of the card. 3) What was the outcome of this action? Agreeing with the showed identifiying device (BeID card) yields an "secure connection failed" error. 4) What outcome did you expect instead? Access to the Belgium citizen online services. 5) Additional info The discussion with the Belgium help desk service (serviced...@fedict.be) and the logs (generated by the software supporting their card -- attached file) suggest that there is a problem with the the firmware. Specifically: "It would appear there is a firmware problem with this cardreader. The reader is shown as having a pin pad, even though it doesn't. Therefore it is sent instructions it can't handle." Belgium help desk service is right. I fixed the problem 3 weeks ago in the upstream source code. https://salsa.debian.org/rousseau/CCID/commit/a27a11711a9861acea3a9b43bba56ba157c670af It may be time to make a new libccid release to fix this problem. Thanks -- Dr. Ludovic Rousseau
Bug#879071: 0ad FTBFS with on armhf with gcc 7: error: call of overloaded 'abs(unsigned int)' is ambiguous
2017-11-21 1:25 GMT+01:00 peter green <plugw...@p10link.net>: > On 19/11/17 14:38, Ludovic Rousseau wrote: > > Peter, > > Please go with the NMU. > > Done, final debdiff attatched. > Thanks. I pushed your changes in https://anonscm.debian.org/ viewvc/pkg-games/packages/trunk/0ad/debian/ > You may also want to fix the arm64 build failure at the same time. > See https://buildd.debian.org/status/fetch.php?pkg=0ad=arm6 > 4=0.0.22-1=1508351579=0 > > That looks like it is failing in buliding an embedded copy of mozjs. > > Is there some reason 0ad has to use an embedded copy of mozjs rather than > one of the versions packaged in Debian. > No idea. 0ad has its own list of patches above mozjs 38.2.1. See http://sources.debian.net/src/0ad/0.0.21-2/libraries/source/spidermonkey/ I have no idea if the official mozjs packaged in Debian can be used instead. That is something that could be experimented. I just maintain the 0ad package since 2 months. Bye, -- Dr. Ludovic Rousseau
Bug#758300: Please reconsider providing the python2 version
Hello,
python-pykcs11 is no more present in Debian since wheezy released in 2013.
https://packages.debian.org/search?keywords=python-pykcs11
Package python-pykcs11
* wheezy (oldoldstable) (python): PKCS#11 wrapper for Python
1.2.4-1: amd64 armel armhf i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel
powerpc s390 s390x sparc
Since then, only the python3-pykcs11 package is provided
https://packages.debian.org/search?keywords=python3-pykcs11
Package python3-pykcs11
* jessie (oldstable) (python): PKCS#11 wrapper for Python
1.3.0-1+b1: s390x
1.3.0-1: amd64 arm64 armel armhf i386 mips mipsel powerpc ppc64el
* stretch (stable) (python): PKCS#11 wrapper for Python
1.3.3-1: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el s390x
* buster (testing) (python): PKCS#11 wrapper for Python
1.4.4-1: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el s390x
* sid (unstable) (python): PKCS#11 wrapper for Python
1.4.4-1: alpha amd64 arm64 armel armhf hppa hurd-i386 i386 kfreebsd-amd64
kfreebsd-i386 m68k mips mips64el mipsel powerpc powerpcspe ppc64 ppc64el s390x
sh4 sparc64 x32
The Debian Python Policy says to package libraries for Python 3.
And for Python 2 only if an application does not yet support Python 3.
https://www.debian.org/doc/packaging-manuals/python-policy/python3.html
Debian does not provide an application that depends on python-pykcs11.
For all these reasons I do not plan to re-introduce python-pykcs11 in Debian.
A possible patch to build python-pykcs11 (for Python 2) is attached (untested
by me).
Bye
--
Dr. Ludovic Rousseau
diff --git a/debian/control b/debian/control
index aa0fc26..307f6f7 100644
--- a/debian/control
+++ b/debian/control
@@ -2,12 +2,29 @@ Source: pykcs11
Priority: optional
Maintainer: Ludovic Rousseau <rouss...@debian.org>
Uploaders: Debian Python Modules Team
<python-modules-t...@lists.alioth.debian.org>
-Build-Depends: debhelper (>= 9), swig, python3-all-dev
+Build-Depends: debhelper (>= 9), swig, python-all-dev, python3-all-dev
Standards-Version: 3.9.8
Section: python
Vcs-Git: https://anonscm.debian.org/git/python-modules/packages/pykcs11.git
Vcs-Browser:
https://anonscm.debian.org/cgit/python-modules/packages/pykcs11.git
Homepage: http://sourceforge.net/projects/pkcs11wrap/
+X-Python-Version: >= 2.7
+X-Python3-Version: >= 3.0
+
+Package: python-pykcs11
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}, ${python:Depends}
+Description: PKCS#11 wrapper for Python
+ PyKCS11 let you access to almost all PKCS#11 functions and data types using
+ any PKCS#11 library, such as the various modules supplied by smartcard
+ vendors.
+ .
+ The wrapper comes with 2 interfaces: a low level and very thin interface over
+ the original PKCS#11 API, generated using the SWIG compiler (designed for
+ library tests); and an high level interface that offers a simpler access (with
+ few limits) to the PKCS#11 APIs.
+ .
+ Keywords: pkcs11
Package: python3-pykcs11
Architecture: any
diff --git a/debian/rules b/debian/rules
index 2b7cf4e..f984c01 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,21 +1,27 @@
#!/usr/bin/make -f
+build2vers := $(shell pyversions -sv)
build3vers := $(shell py3versions -sv)
%:
- dh $@ --with python3
+ dh $@ --with python2,python3
override_dh_auto_build:
- set -e && for i in $(build3vers); do \
+ set -e && for i in $(build2vers) $(build3vers); do \
cd src ; swig -c++ -python pykcs11.i ; cp pykcs11_wrap.cxx
pykcs11_wrap.cpp ; cp LowLevel.py ../PyKCS11 ; \
cd .. ; python$$i setup.py build; \
done
override_dh_auto_install:
+ set -e && for i in $(build2vers); do \
+ python$$i setup.py install --install-layout=deb --root
$(CURDIR)/debian/python-pykcs11; \
+ done; \
set -e && for i in $(build3vers); do \
python$$i setup.py install --install-layout=deb --root
$(CURDIR)/debian/python3-pykcs11; \
done
override_dh_auto_clean:
- python3 setup.py clean
+ set -e && for i in $(build2vers) $(build3vers); do \
+ python$(echo $$i | cut -c -1) setup.py clean; \
+ done
Bug#879071: 0ad FTBFS with on armhf with gcc 7: error: call of overloaded 'abs(unsigned int)' is ambiguous
Peter, Please go with the NMU. You may also want to fix the arm64 build failure at the same time. See https://buildd.debian.org/status/fetch.php?pkg=0ad=arm64=0.0.22-1=1508351579=0 Thanks 2017-11-19 13:38 GMT+01:00 peter green <plugw...@p10link.net>: > Jumping straight to removing an architecture from the architecture list > and filing a removal request over a build failure with no evidence of an > attempt at a fix and no attempt to bring it up with the porters is not in > line with "Packages must be supported on as many architectures as is > reasonably possible". > > I decided to take a look at actually fixing this bug. > > It seems that the cause is the signedness of wchar_t. It appears that on > arm linux wchar_t is unsigned whereas on x86 linux wchar_t is signed. > > The result is that on arm linux the subtraction produces an unsigned > result. The standard libary has no abs functions for unsigned types and so > you get the ambiguous call error. > > Casting both arguments of the subtraction to int fixes the error. > > Debdiff attatched, no immediate intent to NMU. > > ___ > Pkg-games-devel mailing list > pkg-games-de...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-games-devel > -- Dr. Ludovic Rousseau
Bug#838055: 0ad: Embedded libsquish library now available in debian
Le 18/11/2017 à 17:38, Markus Koschany a écrit : Am 18.11.2017 um 17:32 schrieb Ludovic Rousseau: Hello Markus, You re-opened this 0ad bug. According to what Vincent Cheng wrote: 0ad do NOT use the embedded libsquish library. How to you expect this bug to be fixed? Hello Vincent, I reopened the bug because it was closed without further comment by someone who is not a member of this team. To me it looked liked a random spam e-mail. I thought that Vincent Cheng wanted to keep this bug report open until #838056 is fixed but if you want to close it or triage it in some other way, please go ahead. OK. I will keep it open until #838056 "nvidia-texture-tools: Embedded libsquish library now available in debian" is fixed. Note for myself: nvidia-texture-tools package used by 0ad is "libnvtt-dev" in Build-Depends:. Thanks -- Dr. Ludovic Rousseau
Bug#879071: fixed in 0ad 0.0.22-2
2017-11-18 17:28 GMT+01:00 James Cowgill <jcowg...@debian.org>: > Hi, > > On 18/11/17 16:21, Ludovic Rousseau wrote: > > Hello, > > > > 2017-11-18 6:21 GMT+01:00 Petter Reinholdtsen <p...@hungry.com>: > > > >> [Ludovic Rousseau] > >>> 0ad (0.0.22-2) unstable; urgency=medium > >>> . > >>>* Fix "0ad FTBFS with on armhf with gcc 7: error: call of overloaded > >>> 'abs(unsigned int)' is ambiguous" by removing support of armhf > >>> (Closes: #879071) > >> > >> Note, this "fix" did not work, as there are armhf binaries in the > archive > >> and the new version is not allowed to propagate into testing until the > >> armhf binaries are updated to the latest version or removed. Did you > >> file a request for removal? > >> > > > > Adrian Bunk filed bug #880058 "RM: 0ad [armhf] -- NBS; no longer built on > > armhf" > > > > I am not sure it will be enough since the versions for arm64, > > kfreebsd-amd64 and kfreebsd-i386 must also be removed. > > Should I create 3 new bugs for the other 3 architectures? > > You can just retitle the original bug, with a message explaining the > situation (assuming it isn't closed before then). > > Currently we have: > 0ad | 0.0.21-2 | stretch | source, amd64, armhf, i386 > 0ad | 0.0.21-2 | sid | source, armhf, kfreebsd-amd64, kfreebsd-i386 > 0ad | 0.0.22-3 | sid | source, amd64, i386 > > So I think only armhf and kfreebsd-* need removing (not arm64). kfreebsd > doesn't affect testing migration in any case. > So bug #880058, as it is, will remove the armhf version and 0ad should then be able to migrate to testing. I should _not_ file new bugs. Exact? Thanks -- Dr. Ludovic Rousseau
Bug#838055: 0ad: Embedded libsquish library now available in debian
Hello Markus, You re-opened this 0ad bug. According to what Vincent Cheng wrote: 0ad do NOT use the embedded libsquish library. How to you expect this bug to be fixed? Thanks On Sat, 17 Sep 2016 01:51:15 -0700 Vincent Cheng <vch...@debian.org> wrote: Control: block -1 by 838056 Hi Wookey, On Fri, Sep 16, 2016 at 5:46 PM, Wookey <woo...@debian.org> wrote: >- nvidia-texture-tools 1.7 (src/nvtt/squish) >- 0ad 1.7 (libraries/source/nvtt/src/src/nvtt/squish/) 0ad actually embeds a copy of nvidia-texture-tools, which in turn embeds a copy of libsquish. Since we build 0ad with Debian's nvidia-texture-tools packages and not with the embedded copy, there's nothing that needs to be done in 0ad; once nvidia-texture-tools switches over to using libsquish as packaged in Debian, 0ad will also be using the system version as well. Thanks for the bug report anyhow! Regards, Vincent -- Dr. Ludovic Rousseau
Bug#879071: fixed in 0ad 0.0.22-2
Hello, 2017-11-18 6:21 GMT+01:00 Petter Reinholdtsen <p...@hungry.com>: > [Ludovic Rousseau] > > 0ad (0.0.22-2) unstable; urgency=medium > > . > >* Fix "0ad FTBFS with on armhf with gcc 7: error: call of overloaded > > 'abs(unsigned int)' is ambiguous" by removing support of armhf > > (Closes: #879071) > > Note, this "fix" did not work, as there are armhf binaries in the archive > and the new version is not allowed to propagate into testing until the > armhf binaries are updated to the latest version or removed. Did you > file a request for removal? > Adrian Bunk filed bug #880058 "RM: 0ad [armhf] -- NBS; no longer built on armhf" I am not sure it will be enough since the versions for arm64, kfreebsd-amd64 and kfreebsd-i386 must also be removed. Should I create 3 new bugs for the other 3 architectures? This bug just caused 0ad to be removed from testing. > Yes. I saw that. Thanks -- Dr. Ludovic Rousseau
Bug#881532: Please keep out of buster
2017-11-12 20:38 GMT+01:00 Laurent Bigonville <bi...@debian.org>: > Source: goffice-0.8 > Version: 0.8.17-8 > Severity: serious > Tags: sid buster > > Hi, > > goffice-0.8 is only used by gnucash and grisbi in the archive. > > Both gnucash and grisbi have already switched to goffice 0.10 in an > unstable version or in their git repository. > > At the time of the buster release, they'll hopefully have migrated to > that new major version of goffice, so it's probably a good idea to get > rid of goffice-0.8 for buster. > > I guess this can be revised when we are getting closer from the release. > I am the Debian Maintainer of grisbi. I have no idea when grisbi 1.1 (with support of goffice 0.10) will be released. The progress is very slow. At worst it is possible to build grisbi 1.0 without support of goffice-0.8. So goffice-0.8 can be removed. Bye -- Dr. Ludovic Rousseau
Bug#856194: 0ad crash at start
On Sun, 26 Feb 2017 12:53:13 +0100 =?utf-8?q?J=C3=B6rg_Frings-F=C3=BCrst?= <deb...@jff-webhosting.net> wrote: Package: 0ad Version: 0.0.21-2 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello, 0ad crash at start with the attatched messages. If you need more informations please please ask me. Hello Jörg, Can you check if the bug is still present in 0ad version 0.0.22-2? Thanks -- Dr. Ludovic Rousseau
Bug#874689: libccid: please add Reiner SCT cyberjack RFID standard card reader
Le 08/09/2017 à 20:47, Carsten Schoenert a écrit : On Fri, Sep 08, 2017 at 08:08:35PM +0200, Ludovic Rousseau wrote: Le 08/09/2017 à 19:36, Carsten Schoenert a écrit : Package: libccid Version: 1.4.27-1 Severity: wishlist Hi, Hello, I own a smartcard reader from REINER SCT called 'cyberJack RFID standard'. Feel free to ask for more information. Please follow https://pcsclite.alioth.debian.org/ccid.html#CCID_compliant Thanks for pointing. I added the output of the parsing binary. The homepage of the vendor is unfortunately only supporting a German webpage. https://www.chipkartenleser-shop.de/rsct/chipkartenleser-fuer-die-sicherheitsklasse-3/cyberjack-rfid-standard-usb-271860 There you can find a link to PDF file with some technical data that which obviously is understandable for some technical experienced person. https://www.reiner-sct.com/ccsdata/documentDownload.pdf?documentId=77305081 If still something is missing please point me. I added the reader in the "Should work but untested by me" list https://pcsclite.alioth.debian.org/ccid/shouldwork.html#0x0C4B0x0500 The reader will be supported by the next (upstream and Debian) release of the CCID driver. Thanks -- Dr. Ludovic Rousseau
Bug#874689: libccid: please add Reiner SCT cyberjack RFID standard card reader
Le 08/09/2017 à 19:36, Carsten Schoenert a écrit : Package: libccid Version: 1.4.27-1 Severity: wishlist Hi, Hello, I own a smartcard reader from REINER SCT called 'cyberJack RFID standard'. Feel free to ask for more information. Please follow https://pcsclite.alioth.debian.org/ccid.html#CCID_compliant Thanks -- Dr. Ludovic Rousseau
Bug#874678: spice-vdagent: Fix typos in package description
Package: spice-vdagent
Version: 0.17.0-1
Severity: minor
Tags: patch
Hello,
The attached patch fixes 2 typos in the package Debian description:
- spice-compitable => spice-compAtIble
- includs => includEs
I also changed the way the feature list is managed by using 2 space
characters at the beginning of the lines to display them verbatim.
See https://www.debian.org/doc/debian-policy/index.html#s-f-description
The description rendering should then look like
https://packages.debian.org/sid/a2ps
instead of the somewhat ugly https://packages.debian.org/stretch/spice-vdagent
-- System Information:
Debian Release: 9.1
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages spice-vdagent depends on:
ii init-system-helpers 1.48
ii libasound2 1.1.3-5
ii libc62.24-11+deb9u1
ii libdbus-1-3 1.10.18-1
ii libglib2.0-0 2.50.3-2
ii libpciaccess00.13.4-1+b2
ii libsystemd0 232-25+deb9u1
ii libx11-6 2:1.6.4-3
ii libxfixes3 1:5.0.3-1
ii libxinerama1 2:1.1.3-1+b3
ii libxrandr2 2:1.5.1-1
spice-vdagent recommends no packages.
spice-vdagent suggests no packages.
--- debian/control.old 2017-09-08 10:48:22.210089263 +0200
+++ debian/control 2017-09-08 10:58:57.307473374 +0200
@@ -29,11 +29,11 @@
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Spice agent for Linux
spice-vdagent is the spice agent for Linux, it is used in conjunction with
- spice-compitable hypervisor, its feature includs:
- \* Client mouse mode (no need to grab mouse by client, no mouse lag)
- this is handled by the daemon by feeding mouse events into the kernel
- via uinput. This will only work if the active X-session is running a
- spice-vdagent process so that its resolution can be determined.
- \* Automatic adjustment of the X-session resolution to the client resolution
- \* Support of copy and paste (text and images) between the active X-session
- and the client
+ spice-compatible hypervisor, its feature includes:
+ - Client mouse mode (no need to grab mouse by client, no mouse lag)
+this is handled by the daemon by feeding mouse events into the kernel
+via uinput. This will only work if the active X-session is running a
+spice-vdagent process so that its resolution can be determined.
+ - Automatic adjustment of the X-session resolution to the client resolution
+ - Support of copy and paste (text and images) between the active X-session
+and the client
Bug#862949: Grisbi Autobackup use wrong date and time
On Fri, 19 May 2017 09:57:46 +0200 "p@orange.fr" <p@orange.fr> wrote: Package: Grisbi Version : 1.0.1 Severity: normal Dear Maintainer, Hello When I use the autobackup fonction, the file is created with the name " Mes comptes_20161013T112518_20170401T122623.gsb". The first part is the name of grisbi file, but the second part is a wrong (always the same) date and time. The third part is the correct date and time of backup. I do not reproduce the problem using grisbi 1.0.2. $ ls ~/.local/share/grisbi/ Mes comptes_20161023T222059.gsb Mes comptes_20161023T222141.gsb Mes comptes_20161023T222114.gsb Mes comptes_20161122T175829.gsb Mes comptes_20161023T222124.gsb Mes comptes_20170624T182532.gsb Mes comptes_20161023T222138.gsb I guess the file you opened was "Mes comptes_20161013T112518.gsb" and not "Mes comptes". So the backup reuses the name "Mes comptes_20161013T112518" to create the backup file name. Please double check the name of the file you use in Grisbi. Bye -- Dr. Ludovic Rousseau
Bug#864845: failed: Access denied for user 'debian-sys-maint'@'localhost' (using password: NO)
Package: munin-plugins-core
Version: 2.0.33-1
Severity: normal
Tags: patch
Dear Maintainer,
On a freshly installed Debian 9/Stretch system I get:
$ sudo munin-run mysql_commands
DBI
connect('mysql;mysql_read_default_file=/etc/mysql/debian.cnf;mysql_connect_timeout=5','debian-sys-maint',...)
failed: Access denied for user 'debian-sys-maint'@'localhost' (using password:
NO) at /etc/munin/plugins/mysql_commands line 903.
I note that this system is using mariadb-server-10.1 and I have:
# cat debian.cnf
# Automatically generated for Debian scripts. DO NOT TOUCH!
[client]
host = localhost
user = root
password =
socket = /var/run/mysqld/mysqld.sock
[mysql_upgrade]
host = localhost
user = root
password =
socket = /var/run/mysqld/mysqld.sock
basedir = /usr
On another Debian system using 8/Jessie I use mysql-server-5.5 and I
have:
$ sudo cat /etc/mysql/debian.cnf
# Automatically generated for Debian scripts. DO NOT TOUCH!
[client]
host = localhost
user = debian-sys-maint
password =
socket = /var/run/mysqld/mysqld.sock
[mysql_upgrade]
host = localhost
user = debian-sys-maint
password =
socket = /var/run/mysqld/mysqld.sock
basedir = /usr
On this system the mysql_* munin plugins are working fine.
>From /usr/share/doc/mariadb-server-10.1/README.Debian.gz
* ROOT USER AUTHENTICATION VIA UNIX SOCKET
==
On new installs no root password is set and no debian-sys-maint user is
created anymore. Instead the MariaDB root account is set to be authenticated
using the unix socket, e.g. any mysqld invocation by root or via sudo will
let the user see the mysqld prompt.
You may never ever delete the mysql user "root". Although it has no password
is set, the unix_auth plugin ensure that it can only be run locally as the root
user.
The credentials in /etc/mysql/debian.cnf specify the user which is used by the
init scripts to stop the server and perform logrotation. This used to be the
debian-sys-maint user which is no longer used as root can run directly.
If you have start/stop problems make sure that the /etc/mysql/debian.cnf file
specifies the root user and no password.
Proposed patch:
--- /home/rousseau/munin-node 2017-06-15 23:12:53.880266037 +0200
+++ /etc/munin/plugin-conf.d/munin-node 2017-06-15 23:04:19.285684484 +0200
@@ -73,7 +73,7 @@
[mysql*]
user root
env.mysqlopts --defaults-file=/etc/mysql/debian.cnf
-env.mysqluser debian-sys-maint
+env.mysqluser root
env.mysqlconnection
DBI:mysql:mysql;mysql_read_default_file=/etc/mysql/debian.cnf
[postfix_mailqueue]
This change works for me.
-- System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-3-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages munin-plugins-core depends on:
ii munin-common 2.0.33-1
ii perl 5.24.1-3
Versions of packages munin-plugins-core recommends:
ii libnet-snmp-perl 6.0.1-2
Versions of packages munin-plugins-core suggests:
pn conntrack
ii libcache-cache-perl 1.08-2
ii libdbd-mysql-perl4.041-2
ii libnet-dns-perl 1.07-1
pn libnet-netmask-perl
pn libnet-telnet-perl
ii libxml-parser-perl 2.44-2+b1
ii python 2.7.13-2
pn ruby | ruby-interpreter
-- no debconf information
Bug#864656: usability: do a try-restart of pcscd on fresh install
Le 12/06/2017 à 16:03, Alexandre Detiste a écrit : Package: libccid Version: 1.4.27-1 Severity: wishlist Hi, Hello, I switched from a libacsccid1 to a libccid card reader and lost some time trying to make it work, manually editing the XML with USB id's and such. Then I realized all I needed was to restart pcscd. Would it be ok to try-restart pcscd (if it's installed) from postinst, only on a new install of libccid ? I could restart pcscd. But that would have bad side effect. Imagine you are using your smart card using driver A when you install driver B. If pcscd is restarted automatically then your current connection using driver A would be interrupted. pcscd should be be stopped when no application is using the PC/SC API and started automatically when needed. https://ludovicrousseau.blogspot.fr/2011/11/pcscd-auto-start-using-systemd.html That should be enough to rescan the driver directory. I do not plan to implement a pcscd restart as suggested, unless you have a better argument. Regards, -- Dr. Ludovic Rousseau
Bug#836886: softhsm: Migrating to softhsm2 and purgin softhsm removes softhsm group
On Tue, 6 Sep 2016 22:30:37 +0200 Simon Ruderich <si...@ruderich.org> wrote: Package: softhsm Severity: normal Hello, After migrating from softhsm to softhsm2 I purged softhsm. The problem is with softhsm-common. softhsm2-common also has the same piece of code, so the same problem. However this removed the softhsm group which is still in use by softhsm2 thus breaking opendnssec which is now no longer in this group and can't access the hsm. Maybe the option --only-if-empty of delgroup(8) could be used to remove the group only if no user is using it any more? Btw. why is a static gid (999) used instead of a dynamic system's group id? Good question. It looks like is is not compliant with the Debian Policy https://www.debian.org/doc/debian-policy/ch-opersys.html#s9.2.2 Bye -- Dr. Ludovic Rousseau
Bug#863989: softhsm2 does not create the directory "tokens" in "/var/lib/softhsm"
Package: softhsm2 Version: 2.2.0-3~bpo8+1 Severity: normal Tags: patch Dear Maintainer, The package softhsm2 does not create the directory "tokens" in "/var/lib/softhsm". Soi, just after the installation, I get: $ softhsm2-util --init-token ERROR: Could not initialize the library. and: $ strace softhsm2-util --init-token [...] openat(AT_FDCWD, "/var/lib/softhsm/tokens/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [...] $ dpkg -L softhsm2 /. /var /var/lib /var/lib/softhsm /usr [...] A simple: $ mkdir /var/lib/softhsm/tokens solved the problem. Please include an empty directory "/var/lib/softhsm/tokens" in the package. Bye -- System Information: Debian Release: 8.8 APT prefers stable APT policy: (990, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages softhsm2 depends on: ii libc62.19-18+deb8u9 ii libgcc1 1:4.9.2-10 ii libsofthsm2 2.2.0-3~bpo8+1 ii libsqlite3-0 3.8.7.1-1+deb8u2 ii libssl1.0.0 1.0.1t-1+deb8u6 ii libstdc++6 4.9.2-10 ii softhsm2-common 2.2.0-3~bpo8+1 softhsm2 recommends no packages. softhsm2 suggests no packages. -- no debconf information
Bug#854703: disappears and never returns?
On Sat, 11 Feb 2017 15:07:58 + "Iain R. Learmonth" <i...@debian.org> wrote: Hi, On Fri, 10 Feb 2017 18:41:46 +0100 Ludovic Rousseau <ludovic.rouss...@free.fr> wrote: > You are the first one to report such a problem. > I set the severity to normal. I am also experiencing this problem with a Yubikey. I had the same issue as in #854616 at first, and implemented the udev rule workaround. It worked until the Yubikey was unplugged. I believe this bug should be of severity grave (but will leave this to the maintainer). You are having a problem with scdaemon but you want to have a "grave" bug on pcsc-lite? :-) The problem is not on the pcsc-lite side (I think). > sudo systemctl stop pcscd.socket > sudo systemctl start pcscd.socket These commands did bring it back to life until the next time it was unplugged, at which point the socket needed to be restarted again. Removing the device should not have an impact on the /var/run/pcscd/pcscd.comm socket. Or are you talking about another socket? Please let me know if there are any log files that would be useful, this is a massive pain for me so I'm very willing to help. Do you have "disable-ccid" in your scdaemon.conf? Do you see your reader using pcsc_scan? See https://ludovicrousseau.blogspot.fr/2014/03/level-1-smart-card-support-on-gnulinux.html Bye -- Dr. Ludovic Rousseau
Bug#854005: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works
On Tue, 07 Feb 2017 15:17:04 +0900 NIIBE Yutaka <gni...@fsij.org> wrote: Hello, Hello, On GNU/Linux, use of PC/SC service is not recommended for OpenPGP card Why is that exactly? (installing PC/SC is OK) and the use of different smartcards with PC/SC (OpenPGP card together with other cards) requires struggle anyway, so, I think that asking such users would be an option. My proposal: - if "disable-ccid" is present then use PC/SC - if "disable-ccid" is not present then use the internal CCID only and do not use PC/SC The default value would be to use "disable-ccid". People that _really_ know what they do could remove the "disable-ccid" (and break PC/SC). The situation is complicated becase only some limited card readers works for OpenPGP card. Since most users prefer longer key size of RSA these days, the use of OpenPGP card requires tough condition to card reader. Some workaround in the lower level of USB communcation for specific card readers are implemented in the internal CCID driver, so, if the use if for OpenPGP card, internal CCID driver is better option. Use of long RSA keys require extended APDU. Not all smart card readers support extended APDU. See https://pcsclite.alioth.debian.org/ccid_extended_apdu.html and https://ludovicrousseau.blogspot.fr/2011/05/extended-apdu-status-per-reader.html Bye -- Dr. Ludovic Rousseau
Bug#854703: disappears and never returns?
severity 854703 normal thank On Thu, 09 Feb 2017 11:49:56 -0500 Antoine Beaupre <anar...@debian.org> wrote: Package: pcscd Version: 1.8.20-1 Severity: grave Since I upgraded from 1.8.19-1 to 1.8.20-1 (or maybe it is because of scdaemon 2.1.18, unclear), I cannot reliably use pcscd for multiple days. After a while, the pcscd daemon just disappears, and then scdaemon cannot talk to it anymore: fév 09 11:37:57 curie gpg-agent[23116]: scdaemon[32496] pcsc_establish_context failed: no service (0x8010001d) This was partly documented in #854005 (GnuPG bug) and #854616 (scdaemon bug) which both have workarounds, and I was able to finally use my yubikey *without* pcscd. But I believe there is a pcscd-specific bug here that makes it basically unusable (hence the grave severity). Thanks for the 2 other bug numbers. You are the first one to report such a problem. I set the severity to normal. $ systemctl --system status pcscd â pcscd.service - PC/SC Smart Card Daemon Loaded: loaded (/etc/systemd/system/pcscd.service; indirect; vendor preset: enabled) Active: inactive (dead) since Wed 2017-02-08 21:37:16 EST; 14h ago Process: 15485 ExecStart=/usr/sbin/pcscd --foreground --auto-exit --debug (code=exited, status=0/SUCCESS) Main PID: 15485 (code=exited, status=0/SUCCESS) As you may have noticed, I have modified the .service file to enable debugging: [Unit] Description=PC/SC Smart Card Daemon Requires=pcscd.socket [Service] ExecStart=/usr/sbin/pcscd --foreground --auto-exit --debug ExecReload=/usr/sbin/pcscd --hotplug [Install] Also=pcscd.socket After that, I have noticed that pcscd gladly commits suicide: fév 08 21:37:15 curie pcscd[15485]: 0023 pcscdaemon.c:225:signal_thread() Preparing for suicide This is expected. pcscd is started automatically by systemd when needed. See "pcscd auto start using systemd" https://ludovicrousseau.blogspot.fr/2011/11/pcscd-auto-start-using-systemd.html That time is about the time I stopped working last night. I unplugged my Yubikey and went to bed. The workaround is, obviously, to restart pcscd: sudo systemctl restart pcscd I guess you broke/disabled the socket activation. Use: sudo systemctl stop pcscd.socket sudo systemctl start pcscd.socket It is unclear to me why this regression happened. The systemd files haven't changed since 2011, so presumably the use of --auto-exit is normal. Maybe something changed in the --auto-exit algorithm? Looking upstream, I can't find anything specific. Maybe scdaemon doesn't talk to the right socket anymore, or that socket activation is failing somehow? I don't know or use scdaemon. Trying to access the same device (a smart card reader) from 2 processes is not a good idea. I don't know why the GnuPG people have reinvented the wheel instead of using PC/SC. I think they thought it was safer to do it their way. And now we have problems... The safest default configuration for scdaemon should be "disable-ccid" so it "Just works ™". For users that _really_ know what they do they can use the scdaemon internal ccid driver. Am I the only one seeing this behavior? Yes, AFAIK. It is not a pcsc-lite bug. So unless you prove otherwise I will just close it "soon". Bye -- Dr. Ludovic Rousseau
Bug#847786: solid-pop3d: Does not work with systemd. Is inetd mandatory?
Package: solid-pop3d Version: 0.15-27 Severity: important Dear Maintainer, I just installed solid-pop3d in my Debian stable (jessie 8.6) system. It looks like the pop3 server is NOT started when systemd is used. I use the default package configuration so "inetd". I have not tried with the "daemon" configuration. It is possible to use this package on a systemd system (default init system on Debian now)? If yes can you provide the systemd configuration files? Thanks -- System Information: Debian Release: 8.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.6.0-0.bpo.1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages solid-pop3d depends on: ii adduser3.113+nmu3 ii debconf [debconf-2.0] 1.5.56 ii libc6 2.19-18+deb8u6 ii liblockfile1 1.09-6 ii libpam-runtime 1.1.8-3.1+deb8u1 ii libpam0g 1.1.8-3.1+deb8u1+b1 ii lsb-base 4.1+Debian13+nmu1 ii netbase5.3 ii update-inetd 4.43 Versions of packages solid-pop3d recommends: ii exim4 4.84.2-2+deb8u1 ii exim4-daemon-light [mail-transport-agent] 4.84.2-2+deb8u1 Versions of packages solid-pop3d suggests: pn openbsd-inetd | inet-superserver -- debconf information: * solid-pop3d/run_mode: inetd
Bug#725910: colormake: man page refers to non-existent configuration file
Le 29/11/2016 à 21:36, Reuben Thomas a écrit : On 29 November 2016 at 20:04, Ludovic Rousseau <ludovic.rouss...@free.fr <mailto:ludovic.rouss...@free.fr>> wrote: On Wed, 09 Oct 2013 23:54:23 +0100 Reuben Thomas <r...@sc3d.org <mailto:r...@sc3d.org>> wrote: Package: colormake Version: 0.9-1 Severity: minor colormake(1) refers to /usr/share/colormake/colormake.rc, which does not exist. Exact. This file is not installed by the Debian package. The file also does not exist in the upstream tarball. The idea is that the admin can _create_ this file so the same configuration will be used, by default, for all the system users. The syntax is the same as for ~/.colormakerc How do you propose to solve this bug? I hadn't read the man page closely enough to realise that this is a configuration file, thanks! A system-wide configuration file should surely be under /etc, not under /usr/share. So I would propose to solve the bug by moving the file. I guess this is an upstream bug? You are completely right. /etc is a better place. Yes, it is an upstream bug already available at https://github.com/pagekite/Colormake/issues/14 Thanks -- Dr. Ludovic Rousseau
Bug#725910: colormake: man page refers to non-existent configuration file
On Wed, 09 Oct 2013 23:54:23 +0100 Reuben Thomas <r...@sc3d.org> wrote: Package: colormake Version: 0.9-1 Severity: minor colormake(1) refers to /usr/share/colormake/colormake.rc, which does not exist. Exact. This file is not installed by the Debian package. The file also does not exist in the upstream tarball. The idea is that the admin can _create_ this file so the same configuration will be used, by default, for all the system users. The syntax is the same as for ~/.colormakerc How do you propose to solve this bug? Sorry for the delay. -- Dr. Ludovic Rousseau
Bug#842384: grisbi: new upstream release 1.0.1
Le 15/11/2016 à 13:17, Roberto C. Sánchez a écrit : On Mon, Nov 14, 2016 at 09:11:00PM +0100, Ludovic Rousseau wrote: Hello, The good news is that grisbi packaging is already available at https://anonscm.debian.org/cgit/collab-maint/grisbi.git/ so it should be easy to co-maintain it. Sorry Roberto, I do not use IRC :-( No worries. If you would like some help next week, I am happy to lend a hand. In any event, than you for helping out. I prepared the packaging for version 1.0.1. https://anonscm.debian.org/cgit/collab-maint/grisbi.git/ With no remarks from you I do plan to upload the package this week-end (26th November 2016). Bye -- Dr. Ludovic Rousseau
Bug#842384: grisbi: new upstream release 1.0.1
Hello, The good news is that grisbi packaging is already available at https://anonscm.debian.org/cgit/collab-maint/grisbi.git/ so it should be easy to co-maintain it. Sorry Roberto, I do not use IRC :-( Bye, Le 14/11/2016 à 21:02, Roberto C. Sánchez a écrit : Hi Ludovic, I still use Grisbi, though its maintenance has not been as high a priority for me as it ought to be. As Stéphane is the primary maintainer, the decision is his whether to accept additional co-maintainers. However, as far as it concerns me, I welcome the additional help. I have actually set aside time next week to address some outstanding issues in my Debian packages. If you would like, we can meet up on IRC and try to get Grisbi in better shape for the Stretch release. Regards, -Roberto On Mon, Nov 14, 2016 at 08:27:03PM +0100, Ludovic Rousseau wrote: Hello Stéphane, Roberto, Do you need help maintaining grisbi for Debian? I ask because: - I use grisbi - I am also a Debian Developer - I am part of grisbi upstream developers Debian will be frozen soon (5 January 2017) [1] so it is time to upload a new version of grisbi with bug fixes. With no answer I may consider doing a NMU (Non Maintainer Upload). Regards, [1] https://lists.debian.org/debian-devel-announce/2016/11/msg2.html On Fri, 28 Oct 2016 18:31:44 +0200 Ludwin Janvier <lud.janv...@gmail.com> wrote: Package: grisbi Version: 1.0.0-2ubuntu3 Severity: normal Dear Maintainer, A new upstream release 1.0.1 https://sourceforge.net/projects/grisbi/files/grisbi%20stable/1.0.x/grisbi-1.0.1.tar.bz2/download This fixes crashes bugs with gtk-2.24.30 -- Dr. Ludovic Rousseau -- Dr. Ludovic Rousseau
Bug#842384: grisbi: new upstream release 1.0.1
Hello Stéphane, Roberto, Do you need help maintaining grisbi for Debian? I ask because: - I use grisbi - I am also a Debian Developer - I am part of grisbi upstream developers Debian will be frozen soon (5 January 2017) [1] so it is time to upload a new version of grisbi with bug fixes. With no answer I may consider doing a NMU (Non Maintainer Upload). Regards, [1] https://lists.debian.org/debian-devel-announce/2016/11/msg2.html On Fri, 28 Oct 2016 18:31:44 +0200 Ludwin Janvier <lud.janv...@gmail.com> wrote: Package: grisbi Version: 1.0.0-2ubuntu3 Severity: normal Dear Maintainer, A new upstream release 1.0.1 https://sourceforge.net/projects/grisbi/files/grisbi%20stable/1.0.x/grisbi-1.0.1.tar.bz2/download This fixes crashes bugs with gtk-2.24.30 -- Dr. Ludovic Rousseau
Bug#758300: Please reconsider providing the python2 version
On Fri, 23 Oct 2015 14:21:48 + Marga Manterola <ma...@google.com> wrote: Hi! Hello Marga, For a unknown reason I have not received your email (from 1 year ago). Sorry for that. Reasons: 1) There are still a lot of programs out there that are written in python2 and migrating all of them to python3 is quite a lot of work. 2) Debian's default python is still python2. 3) Most modules are still provided for both python2 and python3. You had said that you would accept a patch, but then closed the bug as wontfix. Will you still accept a patch? The bug is not closed. I just added the tag "wontfix". Yes, I would review a patch. Regards, -- Dr. Ludovic Rousseau
Bug#814822: libpam-pkcs11: pam_pkcs11.so exit with error if on of multiple certificates
On Mon, 15 Feb 2016 18:14:26 +0100 Gabriel Sailer <gabriel.sai...@gmx.net> wrote: Package: libpam-pkcs11 Version: 0.6.8-4 Severity: normal On my PKI Card are six certificates: DEBUG:pkcs11_lib.c:1383: login as user CKU_USER DEBUG:pkcs11_lib.c:1577: Saving Certificate #1: DEBUG:pkcs11_lib.c:1579: - type: 00 DEBUG:pkcs11_lib.c:1580: - id: be DEBUG:pkcs11_lib.c:1577: Saving Certificate #2: DEBUG:pkcs11_lib.c:1579: - type: 00 DEBUG:pkcs11_lib.c:1580: - id: df DEBUG:pkcs11_lib.c:1577: Saving Certificate #3: DEBUG:pkcs11_lib.c:1579: - type: 00 DEBUG:pkcs11_lib.c:1580: - id: 3b DEBUG:pkcs11_lib.c:1577: Saving Certificate #4: DEBUG:pkcs11_lib.c:1579: - type: 00 DEBUG:pkcs11_lib.c:1580: - id: 39 DEBUG:pkcs11_lib.c:1577: Saving Certificate #5: DEBUG:pkcs11_lib.c:1579: - type: 00 DEBUG:pkcs11_lib.c:1580: - id: 7b DEBUG:pkcs11_lib.c:1577: Saving Certificate #6: DEBUG:pkcs11_lib.c:1579: - type: 00 DEBUG:pkcs11_lib.c:1580: - id: 62 DEBUG:pkcs11_lib.c:1612: Found 6 certificates in token Some of them are for email en-/decryption and one is for authenticaten (see below). The some certificates are expired, but are needed to read older encrypted emails. The Problem is now, that pam_pkcs11.c returned an error after validating then first certificate with 'certificate has expired': DEBUG:pam_pkcs11.c:551: verifying the certificate #1 verifying certificate DEBUG:cert_vfy.c:338: Adding hashdir lookup to x509_store DEBUG:cert_vfy.c:350: Adding hash dir '/etc/pam_pkcs11/cacerts' to CACERT checks DEBUG:cert_vfy.c:357: Adding hash dir '/etc/pam_pkcs11/crls' to CRL checks ERROR:pam_pkcs11.c:559: verify_certificate() failed: certificate is invalid: certificate has expired Error 2324: Certificate has expired DEBUG:mapper_mgr.c:213: unloading mapper module list DEBUG:mapper_mgr.c:137: calling mapper_module_end() mail DEBUG:mapper_mgr.c:148: Module mail is static: don't remove DEBUG:mapper_mgr.c:137: calling mapper_module_end() subject DEBUG:mapper_mgr.c:148: Module subject is static: don't remove DEBUG:mapper_mgr.c:137: calling mapper_module_end() digest DEBUG:mapper_mgr.c:148: Module digest is static: don't remove DEBUG:mapper_mgr.c:137: calling mapper_module_end() cn DEBUG:mapper_mgr.c:148: Module cn is static: don't remove DEBUG:pkcs11_lib.c:1443: logout user DEBUG:pkcs11_lib.c:1450: closing the PKCS #11 session DEBUG:pkcs11_lib.c:1456: releasing keys and certificates Password: I think this is an error. Invalid certificates should be removed from the certificate array and the validation process should check the next certificate. I hink this problem is solved with the latest version 0.6.9-1 of the package. Please try this version and confirm if this bug is fixed or not. Thanks -- Dr. Ludovic Rousseau
Bug#838588: Out of date
Le 22/09/2016 à 18:57, Timothy Pearson a écrit : Package: libpam-pkcs11 Version: 0.6.8-4 Severity: important This package is out of date by at least a year; since the last udate there have been numerous fixes that allow this module to integrate properly into modern card based environments. Please update this package to the latest upstream GIT head. You are right. This package is outdated. The problem is that the upstream maintainer (me) has stopped working on it. See https://github.com/OpenSC/pam_pkcs11 And nobody proposed to maintain it. Another problem is that pam-pkcs#11 does not build with OpenSSL 1.1.0 See Debian bug #828487 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828487 A patch is proposed but OpenSSL removed i2c_ASN1_INTEGER() used by pam-pkcs#11. So the build fails. See https://github.com/OpenSC/pam_pkcs11/pull/21 I can make a new release of pam-pkcs#11 for OpenSSL 1.0.0. But OpenSSL 1.1.0 will enter Debian unstable "soon" and pam-pkcs#11 will be broken (removed). If you want to see an upgraded version of pam-pkcs#11 you can work on OpenSSL 1.1.0 support. Bye -- Dr. Ludovic Rousseau
Bug#827716: Non-maintainer upload to fix RC bugs
Le 29/06/2016 à 17:04, Daniel James a écrit : Hi Ondřej, Daniel James already closed some of the bugs in https://anonscm.debian.org/cgit/collab-maint/tidy.git/ I'd be happy to merge other fixes I have made since version 1:5.2.0-1 into http://anonscm.debian.org/cgit/collab-maint/tidy-html5.git/ if that's OK with you. After that, we could take down the original collab-maint repo to avoid confusion, perhaps. My idea was to merge changes from (new repository) tidy-html5.git into (old repository) tidy.git. And then delete tidy-html5.git since it would be a duplicate. But I let the Debian maintainer(s) (Daniel and Jason) decide. Bye -- Dr. Ludovic Rousseau
Bug#827716: Non-maintainer upload to fix RC bugs
Le 28/06/2016 à 20:55, Ondřej Surý a écrit : It was not in the d/control, so I pushed imported package to collab-maint/tidy-html5. I'll import my and LoB patches on top of tidy.git and push it tomorrow. OK. Daniel James already closed some of the bugs in https://anonscm.debian.org/cgit/collab-maint/tidy.git/ Your merge may not be easy. I already asked [1] Daniel to do the merge. Since there is no urgency now I propose to let Daniel integrate your changes. Bye [1] https://github.com/htacg/tidy-html5/issues/354#issuecomment-229114742 -- Dr. Ludovic Rousseau
Bug#827716: Non-maintainer upload to fix RC bugs
Le 28/06/2016 à 15:49, Ondřej Surý a écrit : JFTR I took your patch and did a direct upload to sid to finally fix these two RC bugs. Also Ludovic, could you please take more care next time you sponsor an upload? Unplanned transitions and FTBFS on r-deps are not something we are very happy about. Yes. Sorry about that. I was not aware that the library was used by other packages. It looks like you have not pushed your changes to the project at collab-maint https://anonscm.debian.org/cgit/collab-maint/tidy.git/ Is it intentional? I guess you just was not aware that the package was maintained in collab-maint. This information is not (yet) present in debian/control. Thanks -- Dr. Ludovic Rousseau
Bug#825672: [pcscd] crashes because "stack smashing detected" after "gpg2 --card-status"
reassign 825672 libacr38u thank On Sat, 28 May 2016 19:03:21 +0200 Giovanni Mascellani <mascell...@poisson.phc.unipi.it> wrote: Package: pcscd Version: 1.8.16-1 Severity: important Hi. Hello, Trying to use pcsc-lite with a cheap USB smartcard reader and a GnuPG smart card, I obtain a crash because of "stack smashing detected". More precisely I: * Launch in a root shell "pcscd --foreground --auto-exit -d"; * Execute in a normal user shell "gpg2 --card-status"; * gpg2 executes correctly and prints the output, but pcscd crashes immediately after. Attached is another attempt made while running pcscd under gdb. Please let me know which other information can be useful. When using more complex commands like "gpg2 --card-edit", the gpg2 process loses continuously connection with the pcscd process and no actual work can be done with the smard card. Probing the card with pcsc_scan works and produces no crash. The crash happens inside the /usr/lib/pcsc/drivers/ACR38UDriver.bundle/Contents/Linux/ACR38UDriver.so driver. It is a problem with the libacr38u package. I re-assign the bug to libacr38u. Maybe you should use another smart card reader (and another driver). Bye -- Dr. Ludovic Rousseau
Bug#823426: asedriveiiie: FTBFS: install: cannot stat 'libASEDriveIIIe-USB.so': No such file or directory
Hello, I can't reproduce the problem on a freshly upgraded sid system. Your log contains a strange error: /usr/bin/ld: cannot find /lib/ /usr/bin/ld: cannot find s/libusb-0.1.so.4.4.4 collect2: error: ld returned 1 exit status Maybe the problem is on your build system? Do you have the package libusb-dev correctly installed? Bye Le 04/05/2016 à 18:16, Chris Lamb a écrit : Source: asedriveiiie Version: 3.7-5 Severity: serious Justification: fails to build from source User: reproducible-bui...@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Dear Maintainer, asedriveiiie fails to build from source in unstable/amd64: [..] dh_testdir dh_testroot dh_prep dh_testdir dh_testroot dh_install dh_installdocs dh_installchangelogs dh_compress dh_fixperms dh_installdeb dh_gencontrol dh_md5sums dh_builddeb dpkg-deb: building package 'asedriveiiie-build-deps' in '../asedriveiiie-build-deps_3.7-5_all.deb'. The package has been created. Attention, the package has been created in the current directory, not in ".." as indicated by the message above! Selecting previously unselected package asedriveiiie-build-deps. (Reading database ... 23072 files and directories currently installed.) Preparing to unpack asedriveiiie-build-deps_3.7-5_all.deb ... Unpacking asedriveiiie-build-deps (3.7-5) ... Reading package lists... Building dependency tree... Reading state information... Correcting dependencies... Done The following additional packages will be installed: libpcsclite-dev libpcsclite1 libusb-dev pkg-config Suggested packages: pcscd The following NEW packages will be installed: libpcsclite-dev libpcsclite1 libusb-dev pkg-config 0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded. 1 not fully installed or removed. Need to get 229 kB of archives. After this operation, 717 kB of additional disk space will be used. Get:1 http://httpredir.debian.org/debian sid/main amd64 libusb-dev amd64 2:0.1.12-29 [36.9 kB] Get:2 http://httpredir.debian.org/debian sid/main amd64 libpcsclite1 amd64 1.8.16-1 [56.2 kB] Get:3 http://httpredir.debian.org/debian sid/main amd64 libpcsclite-dev amd64 1.8.16-1 [73.1 kB] Get:4 http://httpredir.debian.org/debian sid/main amd64 pkg-config amd64 0.29-4 [62.5 kB] Fetched 229 kB in 0s (19.4 MB/s) Selecting previously unselected package libusb-dev. (Reading database ... (Reading database ... 5% (Reading database ... 10% (Reading database ... 15% (Reading database ... 20% (Reading database ... 25% (Reading database ... 30% (Reading database ... 35% (Reading database ... 40% (Reading database ... 45% (Reading database ... 50% (Reading database ... 55% (Reading database ... 60% (Reading database ... 65% (Reading database ... 70% (Reading database ... 75% (Reading database ... 80% (Reading database ... 85% (Reading database ... 90% (Reading database ... 95% (Reading database ... 100% (Reading database ... 23076 files and directories currently installed.) Preparing to unpack .../libusb-dev_2%3a0.1.12-29_amd64.deb ... Unpacking libusb-dev (2:0.1.12-29) ... Selecting previously unselected package libpcsclite1:amd64. Preparing to unpack .../libpcsclite1_1.8.16-1_amd64.deb ... Unpacking libpcsclite1:amd64 (1.8.16-1) ... Selecting previously unselected package libpcsclite-dev. Preparing to unpack .../libpcsclite-dev_1.8.16-1_amd64.deb ... Unpacking libpcsclite-dev (1.8.16-1) ... Selecting previously unselected package pkg-config. Preparing to unpack .../pkg-config_0.29-4_amd64.deb ... Unpacking pkg-config (0.29-4) ... Processing triggers for man-db (2.7.5-1) ... Processing triggers for libc-bin (2.22-7) ... Setting up libusb-dev (2:0.1.12-29) ... Setting up libpcsclite1:amd64 (1.8.16-1) ... Setting up libpcsclite-dev (1.8.16-1) ... Setting up pkg-config (0.29-4) ... Setting up asedriveiiie-build-deps (3.7-5) ... Processing triggers for libc-bin (2.22-7) ... dpkg-buildpackage -rfakeroot -D -us -uc -b dpkg-buildpackage: info: source package asedriveiiie dpkg-buildpackage: info: source version 3.7-5 dpkg-buildpackage: info: source distribution unstable dpkg-buildpackage: info: source changed by Ludovic Rousseau <rouss...@debian.org> dpkg-source --before-build asedriveiiie-3.7 dpkg-buildpackage: info: host architecture amd64 fakeroot debian/rules clean dh_testdir dh_testroot rm -f build-stamp configure-stamp touch asedriveiiie-usb/Makefile.inc /usr/bin/make -C asedriveiiie-usb clean make[1]: Entering directory '/home/lamby/temp/cdt.20160504171441.1bydKUjNYo.asedriveiiie/asedriveiiie-3.7/asedriveiiie-usb' rm -f *~ *.o *.so || true make[1]: Leaving directory '/home/lamby/temp/cdt.20160504171441.1bydKUjNYo.asedriveiiie/asedriveiiie-3.7/asedriveiiie-usb' touch asedriveiiie-serial/Makefile.inc /usr/bin/make -C asedriveiiie-serial clean make[1]: Entering directo
Bug#821787: cleanup libusb when open fails
Le 19/04/2016 11:52, Stefan Bühler a écrit :
Package: libccid
Version: 1.4.22-1
Tags: patch
Severity: important
Hi,
after suspend/resume pcscd burns a core:
---
[pid 23458] poll([{fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 2, 4294967295)
= 1 ([{fd=5, revents=POLLIN}])
[pid 23458] recvmsg(11, 0x7f0332553d80, 0) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 23458] poll([{fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 2, 4294967295)
= 1 ([{fd=5, revents=POLLIN}])
[pid 23458] recvmsg(11, 0x7f0332553d80, 0) = -1 EAGAIN (Resource temporarily
unavailable)
---
Some rounds of debugging and reading source lead me to a bug in ccid:
after initializing a certain reader failed pcscd unloads ccid, which
unloads libusb without proper cleanup.
This leads to various race conditions if libusb gets loaded again
later, and might crash pcscd in other cases.
---
Apr 19 10:08:13 $hostname systemd[1]: Started PC/SC Smart Card Daemon.
Apr 19 10:08:13 $hostname pcscd[10047]:
ifdhandler.c:144:CreateChannelByNameOrChannel() failed
Apr 19 10:08:13 $hostname pcscd[10047]: 0036
readerfactory.c:1097:RFInitializeReader() Open Port 0x20 Failed
(usb:0a5c/5800:libudev:0:/dev/bus/usb/004/003)
Apr 19 10:08:13 $hostname pcscd[10047]: 0004
readerfactory.c:372:RFAddReader() Broadcom Corp 5880 [Broadcom USH]
(0123456789ABCD) init failed.
---
See attached patch for a fix.
Wonderful.
You patch fixes a problem I (wrongly) thought was in libudev.
I committed your patch upstream in
https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=pcsclite/CCID.git;a=commit;h=3c21f452543983f3625a1965ce234074cbda6865
"Fix a busy loop consuming 100% of CPU
If opening a reader fails then we must call close_libusb_if_needed() to
free any libusb resources and stop the libusb hotplug thread.
The problem as been detected with the Yubico Yubikey NEO U2F+CCID and
the 2 Boardcom devices. These devices are composite USB devices so
loading the CCID driver for a non-CCID interface was calling
libusb_init() but not libusb_exit(). The libusb hotplug thread and other
libusb allocated resources were not stopped and unallocated. On the next
USB plug (even if not CCID) then an endless busy loop is started inside
libusb hotplug.
Fixes:
- Debian bug #812087
"pcscd takes 100 % cpu each time I insert a mass storage USB key"
- Debian bug #821787
"cleanup libusb when open fails"
- Ubuntu bug #1572004
"pcscd consumes 100% CPU"
- Ubuntu bug #1551897
"Excessive CPU utilization"
Thanks a lot to Stefan Bühler for the analysis and patch
https://bugs.debian.org/821787;
Thanks again!
--
Dr. Ludovic Rousseau
Bug#812087: [pcscd] takes 100 % cpu
On Sat, 2 Apr 2016 10:52:25 +0200 Ludovic Rousseau <ludovic.rouss...@free.fr> wrote: > I will open a bug at libudev. Bug report created upstream https://github.com/systemd/systemd/issues/2946 I don't know if I will try to fix the bug myself. I have no experience with libudev. Bye -- Dr. Ludovic Rousseau
Bug#812087: [pcscd] takes 100 % cpu
On Mon, 28 Mar 2016 17:22:31 +0200 Philippe Teuwen <p...@teuwen.org> wrote: > Some more tests: > > log_pcscd_yubikey_then_scl3711_then_100cpu.txt: > the initial 100% CPU case. > I've a Yubikey Neo-n plugged-in before launching pcscd. > When I plug a SCL3711 (or anything else or when unplugging sth on usb), > then one thread goes to 100% CPU, while pcscd is still operating as normal. > > log_hotplugtest_yubikey_then_scl3711: > Same scenario but monitoring libusb/examples/hotplugtest: > no CPU problem here. I also tried running libusb/examples/hotplugtest (from current git repository) but I always get the CPU at 100%. Using hotplugtest does not change anything in my case. > So everything seems to be linked to usage of that yubikey. I tried with another composite device Feitian R502 [1] (3 CCID interfaces on the same device) and I do not have the problem. I don't know what the problem is with the Yubikey and Broadcom devices. I will open a bug at libudev. Bye [1] http://pcsclite.alioth.debian.org/ccid/shouldwork.html#0x096E0x060D -- Dr. Ludovic Rousseau
Bug#812087: [pcscd] takes 100 % cpu
Le 28/03/2016 18:11, Ludovic Rousseau a écrit : On Mon, 28 Mar 2016 17:22:31 +0200 Philippe Teuwen <p...@teuwen.org> wrote: So everything seems to be linked to usage of that yubikey. I asked my contact at Yubico to get a "Yubico Yubikey NEO U2F+CCID" device so I can work on the problem myself. If I can't get a device I will continue to bother you Philippe :-( I now have a Yubikey NEO and can reproduce the problem myself. I also note that pcscd crashes when I remove the Yubikey token. I hope to be able to identify the problem soon. Bye -- Dr. Ludovic Rousseau
Bug#812087: [pcscd] takes 100 % cpu
Le 30/03/2016 18:39, Eric Valette a écrit : On 30/03/2016 17:51, Ludovic Rousseau wrote: Le 29/03/2016 10:38, Eric Valette a écrit : You are also using the Broadcom Corp 5880 reader. For now people with the issue are using: - Broadcom Corp 5880 0a5c/5800 (Eric) & (Johnny Ubuntu bug 1551897) - Broadcom BCM5880 0a5c/5804 (Gustavo) - Yubico Yubikey NEO U2F+CCID 1050/0115 (Philippe) & (Casey Ubuntu bug 1551897) The Broadcom Corp 5880 0a5c/5800 and the Yubico Yubikey NEO U2F+CCID 1050/0115 both have only 1 CCID interface. So the problem may not be related to a composite device. What is the problem with the Broadcom and Yubico devices? I should receive a Yubikey NEO device soon so I should be able to reproduce the problem and work on it. I'm affraid I'm lost. There is a BCM 5880 on my PC yes, that I never use. As my normal key is on a USB stick. And the problem occurs when I'm plugin a regular USB mass storage key that is not by any mean a crypto keys. So I do not catch why the BCM 5880 could be the problem. Could you explain a bit more. I can't explain. I just note what is common in the different cases. I have no idea what is wrong. Bye -- Dr. Ludovic Rousseau
Bug#819573: libacr38u: specified group 'pcscd' unknown
Package: libacr38u Version: 1.7.11-1 Severity: normal Tags: patch Hello, The libacr38u package provides the file /lib/udev/rules.d/92-libacr38u.rules to change the group of the device file to "pcscd". This is no more needed since pcsc-lite 1.8.8 released in January 2013. The use of the non-existing pcscd group will even generate an error in the logs: Reading rules file: /lib/udev/rules.d/92-libacr38u.rules specified group 'pcscd' unknown Please remove the file debian/libacr38u.udev and upload a new version of the libacr38u package. I note that the Debian package has not been updated since August 2011 so I do not expect a fix of this bug "soon" :-( Thanks -- System Information: Debian Release: 8.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.1.0-0.bpo.2-686-pae (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#812087: [pcscd] takes 100 % cpu
Le 29/03/2016 10:38, Eric Valette a écrit : On 03/26/2016 02:01 PM, Ludovic Rousseau wrote: In pcsc-lite 1.8.16 (that should arrive in Debian testing on Monday 28th March 2016) I fixed a bug related to SCardCancel() and SCardGetStatusChange(). Maybe that would fix the problem you have. No it does not fix it Please upgrade to pcsc-lite 1.8.16 and tell me if you still have the problem or not? Do you know what application is using pcscd? To list all the applications using libpcsclite you can use: $ sudo lsof /usr/lib/x86_64-linux-gnu/libpcsclite.so.1 lsof /usr/lib/x86_64-linux-gnu/libpcsclite.so.1 COMMAND PID USER FD TYPE DEVICE SIZE/OFFNODE NAME SACSrv 1359 root memREG8,342848 1046702 /usr/lib/x86_64-linux-gnu/libpcsclite.so.1.0.0 firefox-e 20538 ceva6380 memREG8,342848 1046702 /usr/lib/x86_64-linux-gnu/libpcsclite.so.1.0.0 In addition here is the new log Thanks You are also using the Broadcom Corp 5880 reader. For now people with the issue are using: - Broadcom Corp 5880 0a5c/5800 (Eric) & (Johnny Ubuntu bug 1551897) - Broadcom BCM5880 0a5c/5804 (Gustavo) - Yubico Yubikey NEO U2F+CCID 1050/0115 (Philippe) & (Casey Ubuntu bug 1551897) The Broadcom Corp 5880 0a5c/5800 and the Yubico Yubikey NEO U2F+CCID 1050/0115 both have only 1 CCID interface. So the problem may not be related to a composite device. What is the problem with the Broadcom and Yubico devices? I should receive a Yubikey NEO device soon so I should be able to reproduce the problem and work on it. Bye -- Dr. Ludovic Rousseau
Bug#812087: [pcscd] takes 100 % cpu
Le 29/03/2016 04:30, gustavo panizzo a écrit : I've attached the requested info regarding the question you asked to Eric, wpa is not using the smartcard. COMMANDPID USER FD TYPE DEVICE SIZE/OFF NODE NAME wpa_suppl 1078 root memREG 252,443384 653905 /usr/lib/x86_64-linux-gnu/libpcsclite.so.1.0.0 scdaemon 2718 gust9547 memREG 252,443384 653905 /usr/lib/x86_64-linux-gnu/libpcsclite.so.1.0.0 You are using a Broadcom device with 2 CCID interfaces (contact and contactless). scdaemon is part of OpenPGP and you are using a "GnuPG card V2" card. Maybe the problem is with composite devices. I will try to explore this idea. Thanks -- Dr. Ludovic Rousseau
Bug#819555: pcscd: cyberJack pp_a2 init failed with pcscd_1.8.16-1
On Wed, 30 Mar 2016 15:42:01 +0200 Juergen Rehnen <vec...@t-online.de> wrote: Package: pcscd Version: 1.8.16-1 Followup-For: Bug #819555 Hi this is the output of the log debuglog.c:289:DebugLogSetLevel() debug level=debug 0009 debuglog.c:310:DebugLogSetCategory() Debug options: APDU 0011 utils.c:82:GetDaemonPid() Can't open /var/run/pcscd/pcscd.pid: No such file or directory 0040 configfile.l:281:DBGetReaderListDir() Parsing conf directory: /etc/reader.conf.d 0007 configfile.l:315:DBGetReaderListDir() Skipping non regular file: . 0002 configfile.l:315:DBGetReaderListDir() Skipping non regular file: .. 0001 configfile.l:353:DBGetReaderList() Parsing conf file: /etc/reader.conf.d/libccidtwin 0022 pcscdaemon.c:567:main() pcsc-lite 1.8.16 daemon ready. 1832 hotplug_libudev.c:294:get_driver() Looking for a driver for VID: 0x1D6B, PID: 0x0002, path: /dev/bus/usb/003/001 0056 hotplug_libudev.c:294:get_driver() Looking for a driver for VID: 0x1D6B, PID: 0x0002, path: /dev/bus/usb/003/001 0054 hotplug_libudev.c:294:get_driver() Looking for a driver for VID: 0x0C4B, PID: 0x0401, path: /dev/bus/usb/003/008 0004 hotplug_libudev.c:433:HPAddDevice() Adding USB device: REINER SCT cyberJack pp_a2 0029 readerfactory.c:1066:RFInitializeReader() Attempting startup of REINER SCT cyberJack pp_a2 (0047339731) 00 00 using /usr/lib/pcsc/drivers/libifd- cyberjack.bundle/Contents/Linux/libifd-cyberjack.so 0795 readerfactory.c:951:RFBindFunctions() Loading IFD Handler 3.0 8709 readerfactory.c:1097:RFInitializeReader() Open Port 0x20 Failed (usb:0c4b/0401:libudev:0:/dev/bus/usb/003/008) 0007 readerfactory.c:372:RFAddReader() REINER SCT cyberJack pp_a2 (0047339731) init failed. This is a problem in the REINER SCT driver. If this driver comes from the libifd-cyberjack6 Debian package [1] as it looks like then the bug should be reassigned to this package. Just tell me and I will do the reassignement. Bye [1] https://packages.debian.org/sid/libifd-cyberjack6 -- Dr. Ludovic Rousseau
Bug#819555: pcscd: cyberJack pp_a2 init failed with pcscd_1.8.16-1
On Wed, 30 Mar 2016 14:34:05 +0200 Juergen Rehnen <vec...@t-online.de> wrote: Package: pcscd Version: 1.8.16-1 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** The template is here to help file the bug report. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.0-towo.1-siduction-amd64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pcscd depends on: ii init-system-helpers 1.29 ii libc6 2.22-5 ii libccid [pcsc-ifd-handler]1.4.22-1 ii libifd-cyberjack6 [pcsc-ifd-handler] 3.99.5final.sp09-1 ii libpcsclite1 1.8.16-1 ii libudev1 229-3 ii lsb-base 9.20160110 pcscd recommends no packages. Versions of packages pcscd suggests: ii systemd 229-3 -- no debconf information Hallo after upgrading pcscd_1.8.15-1 to 1.8.16-1 my cardreader REINER SCT cyberJack does not work anymore. I can see this error journalctl -f Mär 30 14:29:43 siductionbox kernel: usb 3-2: new full-speed USB device number 8 using xhci_hcd Mär 30 14:29:44 siductionbox kernel: usb 3-2: New USB device found, idVendor=0c4b, idProduct=0401 Mär 30 14:29:44 siductionbox kernel: usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Mär 30 14:29:44 siductionbox kernel: usb 3-2: Product: cyberJack e-com(f) Mär 30 14:29:44 siductionbox kernel: usb 3-2: Manufacturer: Reiner-SCT Mär 30 14:29:44 siductionbox kernel: usb 3-2: SerialNumber: 0047339731 Mär 30 14:29:44 siductionbox mtp-probe[13616]: checking bus 3, device 8: "/sys/devices/pci:00/:00:14.0/usb3/3-2" Please generate a pcscd log as described in https://pcsclite.alioth.debian.org/pcsclite.html#support Bye -- Dr. Ludovic Rousseau
Bug#812087: [pcscd] takes 100 % cpu
On Mon, 28 Mar 2016 17:22:31 +0200 Philippe Teuwen <p...@teuwen.org> wrote:
Some more tests:
To recap previous debug info, I'm using currently:
--- libusb-1.0-1.0.20.orig/libusb/os/linux_udev.c
+++ libusb-1.0-1.0.20/libusb/os/linux_udev.c
@@ -173,6 +173,7 @@ static void *linux_udev_event_thread_mai
usbi_dbg("udev event thread entering.");
while (poll(fds, 2, -1) >= 0) {
+ usbi_warn(NULL, "poll fds[0].revents=0x%X fds[1].revents=0x%X ",
fds[0].revents, fds[1].revents);
if (fds[0].revents & POLLIN) {
/* activity on control pipe, read the byte and exit */
r = usbi_read(udev_control_pipe[0], ,
sizeof(dummy));
@@ -184,8 +185,11 @@ static void *linux_udev_event_thread_mai
if (fds[1].revents & POLLIN) {
usbi_mutex_static_lock(_hotplug_lock);
udev_dev = udev_monitor_receive_device(udev_monitor);
+ usbi_warn(NULL, "udev_dev=0x%X", udev_dev);
if (udev_dev)
udev_hotplug_event(udev_dev);
+ else
+ usbi_err(NULL, "udev_monitor_receive_device
failed");
usbi_mutex_static_unlock(_hotplug_lock);
}
}
log_pcscd_yubikey_then_scl3711_then_100cpu.txt:
the initial 100% CPU case.
I've a Yubikey Neo-n plugged-in before launching pcscd.
When I plug a SCL3711 (or anything else or when unplugging sth on usb),
then one thread goes to 100% CPU, while pcscd is still operating as normal.
log_hotplugtest_yubikey_then_scl3711:
Same scenario but monitoring libusb/examples/hotplugtest:
no CPU problem here.
Interesting.
Do you give arguments to libusb/examples/hotplugtest or just execute the
command with no argument?
log_pcscd_nothing_then_scl3711:
If the yubikey is not present, no problem, libusb seems not being used
at all.
The scl3711 is not supported by my CCID driver (at least I can't find the
device VID: 0x04E6, PID: 0x5591 in my list)
I guess you use the SCM driver with this device.
log_pcscd_ACR38_then_scl3711:
To be closer to yubikey scenario, trying to replace yubikey by another
USB reader: an ACR38.
No CPU problem.
log_pcscd_ACR38withcard_then_scl3711:
To be closer to yubikey scenario, trying to replace yubikey by another
USB reader with a card inserted.
No CPU problem.
log_pcscd_nothing_then_yubikey_then_nothing_then_segfault:
If I (insert, then) remove the yubikey, pcscd segfaults and, before
that, we see the busy loop problem too in the logs.
So everything seems to be linked to usage of that yubikey.
I asked my contact at Yubico to get a "Yubico Yubikey NEO U2F+CCID" device so I
can work on the problem myself.
If I can't get a device I will continue to bother you Philippe :-(
Thanks for your tests and logs.
Bye
--
Dr. Ludovic Rousseau
Bug#812087: pcscd takes 100 % cpu each time I insert a mass storage USB key
On Wed, 09 Mar 2016 10:20:27 +0800 gustavo panizzo <g...@zumbi.com.ar> wrote: Hello Hi Gustavo, I just want to provide more information about the issue, I have an SmartCard reader (ok, it is usb internally) and a g10 smartcard. I can reproduce the issue plugging my phone as MTP device. If I had my phone connected while I started pcscd when I unplug it, pcscd takes 100% of the CPU too. What is your smartcard reader exactly? Can you send me the result of the lsusb command? Thanks -- Dr. Ludovic Rousseau
Bug#812087: [pcscd] takes 100 % cpu
Le 27/03/2016 16:10, Philippe Teuwen a écrit : Hi Ludovic, Hello, Version 1.8.16-1 Same problem. See log.txt Thanks Phil. Unfortunately I don't see any strange libusb log in your trace :-( Can you modify libusb again with: --- /tmp/XWDR6X_linux_udev.c2016-03-27 20:48:26.715640742 +0200 +++ libusb/os/linux_udev.c 2016-03-27 20:47:07.223641500 +0200 @@ -186,6 +186,8 @@ static void *linux_udev_event_thread_mai udev_dev = udev_monitor_receive_device(udev_monitor); if (udev_dev) udev_hotplug_event(udev_dev); + else + usbi_err(NULL, "udev_monitor_receive_device failed"); usbi_mutex_static_unlock(_hotplug_lock); } } So I can see when libusb goes wrong? Does the problem occurs when you connect the USB device VID: 0x2A70, PID: 0x9011? This is your phone? What is strange from your log are the lines: 03894669 hotplug_libudev.c:648:HPEstablishUSBNotifications() USB Device add 0231 hotplug_libudev.c:294:get_driver() Looking for a driver for VID: 0x2A70, PID: 0x9011, path: /dev/bus/usb/001/019 0369 hotplug_libudev.c:648:HPEstablishUSBNotifications() USB Device add 0187 hotplug_libudev.c:294:get_driver() Looking for a driver for VID: 0x2A70, PID: 0x9011, path: /dev/bus/usb/001/019 01010014 hotplug_libudev.c:648:HPEstablishUSBNotifications() USB Device add 0097 hotplug_libudev.c:294:get_driver() Looking for a driver for VID: 0x2A70, PID: 0x9011, path: /dev/bus/usb/001/019 05139524 hotplug_libudev.c:642:HPEstablishUSBNotifications() USB Device removed 00143995 hotplug_libudev.c:642:HPEstablishUSBNotifications() USB Device removed 00133774 hotplug_libudev.c:642:HPEstablishUSBNotifications() USB Device removed The first "USB Device add" is correct. You connect the USB device. But why a second "USB Device add" for the same device? And a third "USB Device add" 1 second after for again the same device? Is libudev confused? After 5 seconds you get a first "USB Device removed". OK. Then a second one 143 ms later. And a third one 133 ms later. Is you USB device a composite device with more than 1 interface? Do you have the same problem if you connect a simple CCID device instead? Thanks -- Dr. Ludovic Rousseau
Bug#812087: [pcscd] takes 100 % cpu
Le 25/03/2016 12:52, Eric Valette a écrit : On 03/24/2016 06:56 PM, Ludovic Rousseau wrote: LIBUSB_DEBUG=99 pcscd -dfaT | tee log.txt Here it is. NB: the process was actually at 106% after inerting the key before I stooped. Eric, From the pcscd trace you sent I see that an application (or maybe 2 because I see 2 clients) is continuously calling SCardGetStatusChange() with a 200 ms timeout. In pcsc-lite 1.8.16 (that should arrive in Debian testing on Monday 28th March 2016) I fixed a bug related to SCardCancel() and SCardGetStatusChange(). Maybe that would fix the problem you have. Please upgrade to pcsc-lite 1.8.16 and tell me if you still have the problem or not? Do you know what application is using pcscd? To list all the applications using libpcsclite you can use: $ sudo lsof /usr/lib/x86_64-linux-gnu/libpcsclite.so.1 Have you configured wpa_supplicant (Wifi password) to use the smart card? Thanks -- Dr. Ludovic Rousseau
Bug#812087: [pcscd] takes 100 % cpu
Le 24/03/2016 18:56, Ludovic Rousseau a écrit : Le 15/03/2016 19:14, Ludovic Rousseau a écrit : Maybe enabling libusb debug would help. I will try to document how to do that easily. Philippe, Gustavo, Eric, can you do: $ sudo LIBUSB_DEBUG=99 pcscd -dfaT | tee log.txt generate the problem and send me the created log.txt file? Sorry, the correct command is: $ sudo LIBUSB_DEBUG=99 pcscd -dfaT 2>&1 | tee log.txt libusb sends the debug messages to stderr and this was not redirected in log.txt :-( Eric, can you do it again ? Thanks -- Dr. Ludovic Rousseau
Bug#812087: [pcscd] takes 100 % cpu
Le 15/03/2016 19:14, Ludovic Rousseau a écrit : Maybe enabling libusb debug would help. I will try to document how to do that easily. Philippe, Gustavo, Eric, can you do: $ sudo LIBUSB_DEBUG=99 pcscd -dfaT | tee log.txt generate the problem and send me the created log.txt file? Thanks -- Dr. Ludovic Rousseau
Bug#812087: [pcscd] takes 100 % cpu
Hello,
For an unknown reason this email is not visible on
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812087
Sending it again.
Le 15/03/2016 19:14, Ludovic Rousseau a écrit :
On Mon, 7 Mar 2016 21:14:48 +0100 Philippe Teuwen <p...@teuwen.org>
wrote:
>
>
> On 03/07/2016 07:34 PM, Ludovic Rousseau wrote:
> > printf("fds: %d %d\n", fds[0].revents, fds[1].revents);
>
> fds: 0 1
> always
>
> I also printed udev_dev from udev_monitor_receive_device()
> it's always null
>
> So we get fds[1].revents but don't get anything from
> udev_monitor_receive_device() so it's looping forever.
>
>
> You may try to trigger the bug from your side:
> It probably requires the same versions as me.
> kernel 4.3.0-1-amd64
> libusb-1.0-0 2:1.0.20-1
> libudev1 229-2
> I've a Yubikey neo-n plugged in.
> I start pcscd.
> I plug a usb hub (or anything else)
> => CPU at 100%
I am using:
$ uname -a
Linux debian 4.3.0-1-amd64 #1 SMP Debian 4.3.5-1 (2016-02-06) x86_64
GNU/Linux
$ apt-cache policy libusb-1.0-0
libusb-1.0-0:
Installé : 2:1.0.20-1
Candidat : 2:1.0.20-1
Table de version :
*** 2:1.0.20-1 500
500 http://httpredir.debian.org/debian stretch/main amd64
Packages
100 /var/lib/dpkg/status
$ apt-cache policy libudev1
libudev1:
Installé : 229-2
Candidat : 229-2
Table de version :
*** 229-2 500
500 http://httpredir.debian.org/debian stretch/main amd64
Packages
100 /var/lib/dpkg/status
$ apt-cache policy pcscd
pcscd:
Installé : 1.8.15-1
Candidat : 1.8.15-1
Table de version :
*** 1.8.15-1 500
500 http://httpredir.debian.org/debian stretch/main amd64
Packages
100 /var/lib/dpkg/status
$ apt-cache policy libccid
libccid:
Installé : 1.4.22-1
Candidat : 1.4.22-1
Table de version :
*** 1.4.22-1 500
500 http://httpredir.debian.org/debian stretch/main amd64
Packages
100 /var/lib/dpkg/status
And I can't reproduce the problem :-(
I tried connecting a USB memory, my Android phone, a USB hub but it
all worked as expected.
That bug is even more strange now.
Maybe enabling libusb debug would help. I will try to document how to
do that easily.
Bye
--
Dr. Ludovic Rousseau
Bug#812087: [pcscd] takes 100 % cpu
On Mon, 7 Mar 2016 21:14:48 +0100 Philippe Teuwen <p...@teuwen.org> wrote:
>
>
> On 03/07/2016 07:34 PM, Ludovic Rousseau wrote:
> > printf("fds: %d %d\n", fds[0].revents, fds[1].revents);
>
> fds: 0 1
> always
>
> I also printed udev_dev from udev_monitor_receive_device()
> it's always null
>
> So we get fds[1].revents but don't get anything from
> udev_monitor_receive_device() so it's looping forever.
>
>
> You may try to trigger the bug from your side:
> It probably requires the same versions as me.
> kernel 4.3.0-1-amd64
> libusb-1.0-0 2:1.0.20-1
> libudev1 229-2
> I've a Yubikey neo-n plugged in.
> I start pcscd.
> I plug a usb hub (or anything else)
> => CPU at 100%
I am using:
$ uname -a
Linux debian 4.3.0-1-amd64 #1 SMP Debian 4.3.5-1 (2016-02-06) x86_64
GNU/Linux
$ apt-cache policy libusb-1.0-0
libusb-1.0-0:
Installé : 2:1.0.20-1
Candidat : 2:1.0.20-1
Table de version :
*** 2:1.0.20-1 500
500 http://httpredir.debian.org/debian stretch/main amd64 Packages
100 /var/lib/dpkg/status
$ apt-cache policy libudev1
libudev1:
Installé : 229-2
Candidat : 229-2
Table de version :
*** 229-2 500
500 http://httpredir.debian.org/debian stretch/main amd64 Packages
100 /var/lib/dpkg/status
$ apt-cache policy pcscd
pcscd:
Installé : 1.8.15-1
Candidat : 1.8.15-1
Table de version :
*** 1.8.15-1 500
500 http://httpredir.debian.org/debian stretch/main amd64 Packages
100 /var/lib/dpkg/status
$ apt-cache policy libccid
libccid:
Installé : 1.4.22-1
Candidat : 1.4.22-1
Table de version :
*** 1.4.22-1 500
500 http://httpredir.debian.org/debian stretch/main amd64 Packages
100 /var/lib/dpkg/status
And I can't reproduce the problem :-(
I tried connecting a USB memory, my Android phone, a USB hub but it all
worked as expected.
That bug is even more strange now.
Maybe enabling libusb debug would help. I will try to document how to do
that easily.
Bye
--
Dr. Ludovic Rousseau
Bug#812087: [pcscd]
Le 07/03/2016 10:21, Philippe Teuwen a écrit :
I recompiled libusb with debug symbols:
Normal CPU:
Thread 5 (Thread 0x7f0238fcb700 (LWP 24364)):
#0 0x7f02394dfb6d in poll () at ../sysdeps/unix/syscall-template.S:81
#1 0x7f0238fdbafc in poll (__timeout=-1, __nfds=2,
__fds=0x7f0238fcaee0)
at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
#2 linux_udev_event_thread_main (arg=)
at ../../libusb/os/linux_udev.c:175
#3 0x7f02397ab284 in start_thread (arg=0x7f0238fcb700)
at pthread_create.c:333
#4 0x7f02394e8a4d in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
100% CPU:
Thread 5 (Thread 0x7fbeac2a4700 (LWP 24181)):
#0 0x7fbeaca8cbdd in recvmsg () at ../sysdeps/unix/syscall-template.S:81
#1 0x7fbead2806ec in udev_monitor_receive_device ()
from /lib/x86_64-linux-gnu/libudev.so.1
#2 0x7fbeac2b4b8b in linux_udev_event_thread_main (arg=)
at ../../libusb/os/linux_udev.c:186
#3 0x7fbeaca84284 in start_thread (arg=0x7fbeac2a4700)
at pthread_create.c:333
#4 0x7fbeac7c1a4d in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
So the diff happens in that code from libusb/os/linux_udev.c:
usbi_dbg("udev event thread entering.");
while (poll(fds, 2, -1) >= 0) {
if (fds[0].revents & POLLIN) {
r = usbi_read(udev_control_pipe[0], , sizeof(dummy));
if (r <= 0) {
usbi_warn(NULL, "udev control pipe read failed");
}
break;
}
if (fds[1].revents & POLLIN) {
usbi_mutex_static_lock(_hotplug_lock);
udev_dev = udev_monitor_receive_device(udev_monitor);
if (udev_dev)
udev_hotplug_event(udev_dev);
usbi_mutex_static_unlock(_hotplug_lock);
}
}
usbi_dbg("udev event thread exiting");
I added error msgs in the loop.
When 100% CPU, the poll() is non-blocking and the loop becomes a busy loop.
Great.
I reported the problem on the libusb mailing list
https://sourceforge.net/p/libusb/mailman/message/34914342/
Do you know a sequence of manipulations that triggers the bug?
I would like to reproduce the bug on my side.
Can you change the code of libusb to display the values fds[0].revents and
fds[1].revents
Something like:
--- /tmp/XP5vZa_linux_udev.c2016-03-07 19:32:06.353701710 +0100
+++ libusb/os/linux_udev.c 2016-03-07 19:31:56.613374793 +0100
@@ -173,6 +173,7 @@ static void *linux_udev_event_thread_mai
usbi_dbg("udev event thread entering.");
while (poll(fds, 2, -1) >= 0) {
+ printf("fds: %d %d\n", fds[0].revents, fds[1].revents);
if (fds[0].revents & POLLIN) {
/* activity on control pipe, read the byte and exit */
r = usbi_read(udev_control_pipe[0], , sizeof(dummy));
What is the result when the problem occurs?
Bye
--
Dr. Ludovic Rousseau
Bug#812087: [pcscd]
On Sun, 6 Mar 2016 23:10:07 +0100 Philippe Teuwen <p...@teuwen.org> wrote:
Mmm activating libudev debug didn't bring much I think.
I attached one log with LIBUSB_DEBUG=99 and one with recompiled pcscd
with udev debug support.
For both I just ran pcscd with the yubikey plugged in then plugged a USB
hub that triggered the CPU to 100%
libccid1.4.22-1
libusb-1.0-0 2:1.0.20-1
udev 228-6
I'll see if I can get more from gdb...
Cheers
Phil
Thanks Philippe for the libudev trace.
hotplug_libudev.c contains an infinite for() loop.
But for each loop execution a line is logged:
0022 hotplug_libudev.c:619:HPEstablishUSBNotifications()
Since you do not get a infinite of these logs I guess the infinite loop occurs
inside a function called in the for() loop.
I have an idea. Can you test with the proposed patch:
--- /var/folders/sg/t7kts8_n6j13n11r6_tgr36rgn/T//3ql5ya_hotplug_libudev.c
2016-03-07 00:38:32.0 +0100
+++ src/hotplug_libudev.c 2016-03-07 00:38:08.0 +0100
@@ -621,7 +621,7 @@ static void HPEstablishUSBNotifications(
pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL);
/* wait for a udev event */
- r = TEMP_FAILURE_RETRY(poll(, 1, -1));
+ r = poll(, 1, -1);
if (r < 0)
{
Log2(PCSC_LOG_ERROR, "select(): %s", strerror(errno));
--
Dr. Ludovic Rousseau
Bug#812087: [pcscd]
On Thu, 3 Mar 2016 09:30:36 +0100 Philippe Teuwen <p...@teuwen.org> wrote: Hi Ludovic, Hello Philippe, I'm getting the same problem with my Debian Testing. I'll try to generate more logs related to libusb as explained in the bug thread but here are some things I noticed: I also suspect a bug in libudev, not just libusb. Can you rebuild pcscd as explained in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812087#75 to enable libudev logs? I've a Yubikey Neo-n plugged constantly. When the 100% problem arises, nothing special in pcscd logs, even with -f -a -d cf attached log. And pcscd and Yubikey remain fully functional despite the 100%. Now the interesting bits: Without the yubikey inserted the problem never occurs. With the yubikey inserted there are two cases: 1) works as normal, the problem never arises 2) sometimes when yubikey gets inserted or when pcscd service is restarted I get the following error in syslog: pcscd[26168]: ifdhandler.c:144:CreateChannelByNameOrChannel() failed pcscd[26168]: 0012 readerfactory.c:1097:RFInitializeReader() Open Port 0x20 Failed (usb:1050/0115:libudev:0:/dev/bus/usb/001/025) pcscd[26168]: 0002 readerfactory.c:372:RFAddReader() Yubico Yubikey NEO U2F+CCID init failed. What version of libccid do you use? What was the pcscd log line just before CreateChannelByNameOrChannel() failed? At this point besides those lines in syslog, yubikey is functional and CPU is ok *but* starting from this situation, whenever there will be a change on another usb port, no matter what (inserting or removing anything, even a simple USB hub) => CPU goes to 100% Restarting pcscd brings CPU back to normal till another USB insert/remove event. That is really interesting. You can reproduce the problem even after a complete restart of pcscd. So the problem may not be in libusb or pcscd but in libudev or another "system" component used by pcscd. Another idea is to attach a debugger to pcscd and get a backtrace of all the threads when the CPU goes 100%. That could help identify the function or library causing the issue. Thanks -- Dr. Ludovic Rousseau
Bug#812087: pcscd takes 100 % cpu each time I insert a mass storage USB key
Hello, I got no news from my latest email. Do you still have the 100% CPU load for pcscd? Can you help me fix the problem? Thanks Le 25/01/2016 17:33, Ludovic Rousseau a écrit : Hello Alexander and Eric, Le 25/01/2016 01:13, Alexander Mikhailian a écrit : Package: pcscd Version: 1.8.15-1 Followup-For: Bug #812087 Dear Maintainer, I have the same problem with pcscd, and I did not even have to insert a USB mass storage device, when I plug my notebook into the dock station, fans go off like mad and pcscd takes on CPU cycles. This bug is quiet strange. Alexander, have you tried to generate libusb debug using: $ sudo LIBUSB_DEBUG=99 /usr/sbin/pcscd -dfa You may have to downgrade libusb-1.0-0 to version 1.0.19 from stable. Another idea is to rebuild pcscd with hotplug debug enabled. No need to install pcscd so you can't break your installation. 1. Get the source code of pcsc-lite, for example from https://alioth.debian.org/frs/?group_id=30105_id=2019#pcsclite-_1.8.15-title-content 2. install the build dependencies using: $ sudo apt-get build-dep pcscd 3. edit the file PCSC/src/hotplug_libudev.c and change the line 66 from #undef DEBUG_HOTPLUG to #define DEBUG_HOTPLUG 4. configure pcsc-lite using "./configure" 5. run pcscd using: $ sudo ./src/pcscd -dfa 6. try to reproduce the 100% CPU consumption problem This may generate a lot of logs if the problem is with libudev. Bye -- Dr. Ludovic Rousseau
Bug#814822: libpam-pkcs11: pam_pkcs11.so exit with error if on of multiple certificates
On Thu, 18 Feb 2016 18:11:40 +0100 Gabriel Sailer <gabriel.sai...@gmx.net> wrote: Hello, at the moment i patched the pkcs11_lib.c for the first problem. But i must look about side effects for this patch. For the other problems i must go deeper into the source code and do some more debuging. I will take a look at it in the next weeks. I hope i find a solution until march .. Thanks. Please create different and independent Pull Requests on https://github.com/OpenSC/pam_pkcs11 for the different problems. Also feel free to propose what you have now so other people can test and comment on your patches. If you do not want to use github you can post your patches here. Bye, -- Dr. Ludovic Rousseau
Bug#814805: pyscard: Dropped python-pyscard without explanation
On Mon, 15 Feb 2016 16:12:00 +0100 =?utf-8?q?Rapha=C3=ABl_Hertzog?= <hert...@debian.org> wrote: Source: pyscard Version: 1.9.2-1 Severity: serious User: de...@kali.org Usertags: origin-kali This version of pyscard dropped the Python 2 version without any explanation on why this was needed. In the process, you made yubioath-desktop uninstallable (as well as another package which is only available in Kali). The move to Python 3 was not really needed. But since the upstream code is now working with Python 3 it was a good idea to provide python3-pyscard. Please restore the Python 2 version of the module. OK. I will try to work on it. A patch for https://anonscm.debian.org/cgit/python-modules/packages/pyscard.git/ would greatly help. Thanks -- Dr. Ludovic Rousseau
Bug#814822: libpam-pkcs11: pam_pkcs11.so exit with error if on of multiple certificates
risk*. Could you propose patches for these problems? That would really speed up the resolution. The best would be to provide a Pull Request for https://github.com/OpenSC/pam_pkcs11 Thanks -- Dr. Ludovic Rousseau
Bug#814594: yubioauth-desktop depends on cruft package python-pyscard.
On Sat, 13 Feb 2016 14:02:23 + Peter Green <plugw...@debian.org> wrote: Package: yubioauth-desktop Severity: serious x-debbugs-cc: pysc...@packages.debian.org yubioauth-desktop depends on python-pyscard which is no longer built by pyscard. pyscard dropped the binary package in it's most recent upload with no explanation given in the changelog. The PyScard wrapper moved to Python 3. I forget to make it explicit in the debian/changelog. The package is now called python3-pyscard https://packages.debian.org/sid/python3-pyscard yubioath-desktop should be moved to Python 3 as well. Bye -- Dr. Ludovic Rousseau
Bug#812087: pcscd takes 100 % cpu each time I insert a mass storage USB key
Hello Alexander and Eric, Le 25/01/2016 01:13, Alexander Mikhailian a écrit : Package: pcscd Version: 1.8.15-1 Followup-For: Bug #812087 Dear Maintainer, I have the same problem with pcscd, and I did not even have to insert a USB mass storage device, when I plug my notebook into the dock station, fans go off like mad and pcscd takes on CPU cycles. This bug is quiet strange. Alexander, have you tried to generate libusb debug using: $ sudo LIBUSB_DEBUG=99 /usr/sbin/pcscd -dfa You may have to downgrade libusb-1.0-0 to version 1.0.19 from stable. Another idea is to rebuild pcscd with hotplug debug enabled. No need to install pcscd so you can't break your installation. 1. Get the source code of pcsc-lite, for example from https://alioth.debian.org/frs/?group_id=30105_id=2019#pcsclite-_1.8.15-title-content 2. install the build dependencies using: $ sudo apt-get build-dep pcscd 3. edit the file PCSC/src/hotplug_libudev.c and change the line 66 from #undef DEBUG_HOTPLUG to #define DEBUG_HOTPLUG 4. configure pcsc-lite using "./configure" 5. run pcscd using: $ sudo ./src/pcscd -dfa 6. try to reproduce the 100% CPU consumption problem This may generate a lot of logs if the problem is with libudev. Bye -- Dr. Ludovic Rousseau
Bug#812087: pcscd takes 100 % cpu each time I insert a mass storage USB key
Le 22/01/2016 13:11, eric2.vale...@orange.com a écrit :
On 01/20/2016 03:07 PM, Ludovic Rousseau wrote:
It does not look like the problem is the Broadcom reader.
Can you generate a log as documented in
https://pcsclite.alioth.debian.org/pcsclite.html#support ?
Start the log and then connect your problematic mass-storage USB key.
Thanks
Here is the requested log file. Note that I'm not sure the trace will help:
1) As soon as I launch it, I have continuous traces but process does not
even appaers in the top first twenty line,
You have 1 (or 2) application that is continuously (every 200 ms) asking PC/SC
for card status. That is a very bad PC/SC behaviour.
You should try to identify the bogus application and fix it.
2) As soon as I plug the USB key, it reaches 100% CPU and top first place
but do not show anything diffrent in the log.
will try a strace...
[pid 18790] poll([{fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 2, -1) = 1
([{fd=5, revents=POLLIN}])
[pid 18790] recvmsg(11, 0x7ff128ae9dd0, 0) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 18790] poll([{fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 2, -1) = 1
([{fd=5, revents=POLLIN}])
[pid 18790] recvmsg(11, 0x7ff128ae9dd0, 0) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 18790] poll([{fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 2, -1) = 1
([{fd=5, revents=POLLIN}])
[pid 18790] recvmsg(11, 0x7ff128ae9dd0, 0) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 18790] poll([{fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 2, -1) = 1
([{fd=5, revents=POLLIN}])
[pid 18790] recvmsg(11, 0x7ff128ae9dd0, 0) = -1 EAGAIN (Resource temporarily
unavailable)
Maybe a problem in libusb.
Do you have kernel errors in dmesg output?
What is the output of "lsusb -v" with the USB key plugged in?
Bye
--
Dr. Ludovic Rousseau
Bug#812087: pcscd takes 100 % cpu each time I insert a mass storage USB key
Le 22/01/2016 15:18, eric2.vale...@orange.com a écrit : On 01/22/2016 03:06 PM, Ludovic Rousseau wrote: Le 22/01/2016 13:11, eric2.vale...@orange.com a écrit : On 01/20/2016 03:07 PM, Ludovic Rousseau wrote: It does not look like the problem is the Broadcom reader. Can you generate a log as documented in https://pcsclite.alioth.debian.org/pcsclite.html#support ? Start the log and then connect your problematic mass-storage USB key. Thanks Here is the requested log file. Note that I'm not sure the trace will help: 1) As soon as I launch it, I have continuous traces but process does not even appaers in the top first twenty line, You have 1 (or 2) application that is continuously (every 200 ms) asking PC/SC for card status. That is a very bad PC/SC behaviour. You should try to identify the bogus application and fix it. I guess I have installed a binary blob packages given my a key manufacturer :-( SACSrv il you kinow wht it is... Will kill it and retry You can identify a process using PC/SC using: $ sudo fuser /usr/lib/x86_64-linux-gnu/libpcsclite.so.1 Maybe a problem in libusb. What version of libusb are you using? Run pcscd as: $ sudo LIBUSB_DEBUG=99 /usr/sbin/pcscd -dfa Bye -- Dr. Ludovic Rousseau
Bug#812087: pcscd takes 100 % cpu each time I insert a mass storage USB key
Le 22/01/2016 16:05, eric2.vale...@orange.com a écrit : On 01/22/2016 03:52 PM, Ludovic Rousseau wrote: Le 22/01/2016 15:18, eric2.vale...@orange.com a écrit : On 01/22/2016 03:06 PM, Ludovic Rousseau wrote: Le 22/01/2016 13:11, eric2.vale...@orange.com a écrit : On 01/20/2016 03:07 PM, Ludovic Rousseau wrote: It does not look like the problem is the Broadcom reader. Can you generate a log as documented in https://pcsclite.alioth.debian.org/pcsclite.html#support ? Start the log and then connect your problematic mass-storage USB key. Thanks Here is the requested log file. Note that I'm not sure the trace will help: 1) As soon as I launch it, I have continuous traces but process does not even appaers in the top first twenty line, You have 1 (or 2) application that is continuously (every 200 ms) asking PC/SC for card status. That is a very bad PC/SC behaviour. You should try to identify the bogus application and fix it. I guess I have installed a binary blob packages given my a key manufacturer :-( SACSrv il you kinow wht it is... Will kill it and retry You can identify a process using PC/SC using: $ sudo fuser /usr/lib/x86_64-linux-gnu/libpcsclite.so.1 sudo fuser /usr/lib/x86_64-linux-gnu/libpcsclite.so.1 [sudo] password for ceva6380: /usr/lib/x86_64-linux-gnu/libpcsclite.so.1.0.0: 14662m 19 r-x-ceva6380:~->ps ax | grep 14662 14662 ?Sl11:53 /usr/bin/iceweasel 22156 pts/5S+ 0:00 grep 14662 Quite strange!!! Not really. You (or an installation script) has configured a PKCS#11 token in iceveasel. See https://github.com/OpenSC/OpenSC/wiki/Installing-OpenSC-PKCS%2311-Module-in-Firefox,-Step-by-Step Maybe a problem in libusb. What version of libusb are you using? dpkg -l libusb* Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-=-=-=- ii libusb-0.1-4:amd642:0.1.12-28 amd64 userspace USB programming library ii libusb-1.0-0:amd642:1.0.20-1 amd64 userspace USB programming library ii libusb-1.0-0-dev:amd642:1.0.20-1 amd64 userspace USB programming library development files ii libusb-1.0-doc2:1.0.20-1 all documentation for userspace USB programming ii libusb-dev2:0.1.12-28 amd64 userspace USB programming library development files ii libusbmuxd-dev:amd64 1.0.10-2 amd64 USB multiplexor daemon for iPhone and iPod Touch devices - devel ii libusbmuxd-tools 1.0.10-2 amd64 USB multiplexor daemon for iPhone and iPod Touch devices - tools ii libusbmuxd4:amd64 1.0.10-2 amd64 USB multiplexor daemon for iPhone and iPod Touch devices - library 2 r-x-ceva6380:~->su Run pcscd as: $ sudo LIBUSB_DEBUG=99 /usr/sbin/pcscd -dfa Bye attached log : no specific usb trace while pcscd is at 100% cpu. Strange. I also have the Debian package for libusb (1.0.19 from stable) and I get libusb logs. Can you downgrade libusb to version 1.0.19 and test again? bye -- Dr. Ludovic Rousseau
Bug#812087: pcscd takes 100 % cpu each time I insert a mass storage USB key
Le 20/01/2016 13:03, Eric Valette a écrit : Package: pcscd Version: 1.8.15-1 Severity: critical Justification: breaks unrelated software Twice in two days, I noticed my laptop fan was going carsy allthough I was only doing many mail activity. Twice I found that pcscd was eating a complete CPU and remembered that each time I had inserted a regular mass storage USB key (two different keys) not my crypto key. - top - 12:56:25 up 3:14, 5 users, load average: 2.03, 1.56, 1.31 Tasks: 242 total, 2 running, 239 sleeping, 0 stopped, 1 zombie %Cpu(s): 34.1 us, 21.1 sy, 0.0 ni, 44.8 id, 0.0 wa, 0.0 hi, 0.1 si, 0.0 st KiB Mem : 8219052 total, 3472188 free, 2336828 used, 2410036 buff/cache KiB Swap: 16383996 total, 16383996 free,0 used. 5812264 avail Mem PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 1687 root 20 0 394560 2916 2120 S 100.3 0.0 147:37.75 pcscd 14477 ceva6380 20 0 424288 57364 37792 R 99.7 0.7 2:59.83 konsole 2921 ceva6380 20 0 1410776 448992 87860 S 15.9 5.5 6:48.46 icedove 4463 ceva6380 20 0 1435116 363080 97112 S 1.7 4.4 4:12.69 iceweasel Do you have some pcscd related logs in /var/log/* ? Bye -- Dr. Ludovic Rousseau
Bug#812087: pcscd takes 100 % cpu each time I insert a mass storage USB key
Le 20/01/2016 14:02, eric2.vale...@orange.com a écrit : Note that in the laptop there is a build in broadcom credit card format crypto key reader (that you see in the log), but I do not use it although for testing purpose I have enabled the driver. But the bug is only if I insert a USB key. daemon.log:Jan 18 15:17:11 r-x-ceva6380 pcscd[11283]: ifdhandler.c:144:CreateChannelByNameOrChannel() failed daemon.log:Jan 18 15:17:11 r-x-ceva6380 pcscd[11283]: 0032 readerfactory.c:1097:RFInitializeReader() Open Port 0x20 Failed (usb:0a5c/5800:libudev:0:/dev/bus/usb/002/004) daemon.log:Jan 18 15:17:11 r-x-ceva6380 pcscd[11283]: 0004 readerfactory.c:372:RFAddReader() Broadcom Corp 5880 [Broadcom USH] (0123456789ABCD) init failed. daemon.log:Jan 19 13:52:56 r-x-ceva6380 pcscd[1604]: ifdhandler.c:144:CreateChannelByNameOrChannel() failed daemon.log:Jan 19 13:52:56 r-x-ceva6380 pcscd[1604]: 0027 readerfactory.c:1097:RFInitializeReader() Open Port 0x20 Failed (usb:0a5c/5800:libudev:0:/dev/bus/usb/002/004) daemon.log:Jan 19 13:52:56 r-x-ceva6380 pcscd[1604]: 0005 readerfactory.c:372:RFAddReader() Broadcom Corp 5880 [Broadcom USH] (0123456789ABCD) init failed. daemon.log:Jan 20 09:42:05 r-x-ceva6380 pcscd[1687]: ifdhandler.c:144:CreateChannelByNameOrChannel() failed daemon.log:Jan 20 09:42:05 r-x-ceva6380 pcscd[1687]: 0026 readerfactory.c:1097:RFInitializeReader() Open Port 0x20 Failed (usb:0a5c/5800:libudev:0:/dev/bus/usb/002/004) daemon.log:Jan 20 09:42:05 r-x-ceva6380 pcscd[1687]: 0004 readerfactory.c:372:RFAddReader() Broadcom Corp 5880 [Broadcom USH] (0123456789ABCD) init failed. daemon.log:Jan 20 12:56:47 r-x-ceva6380 systemd[1]: pcscd.service: Main process exited, code=killed, status=9/KILL daemon.log:Jan 20 12:56:47 r-x-ceva6380 systemd[1]: pcscd.service: Unit entered failed state. daemon.log:Jan 20 12:56:47 r-x-ceva6380 systemd[1]: pcscd.service: Failed with result 'signal'. < killed it by kill -9 to get CPU back daemon.log:Jan 20 12:56:47 r-x-ceva6380 pcscd[14663]: ifdhandler.c:144:CreateChannelByNameOrChannel() failed daemon.log:Jan 20 12:56:47 r-x-ceva6380 pcscd[14663]: 0022 readerfactory.c:1097:RFInitializeReader() Open Port 0x20 Failed (usb:0a5c/5800:libudev:0:/dev/bus/usb/002/004) daemon.log:Jan 20 12:56:47 r-x-ceva6380 pcscd[14663]: 0003 readerfactory.c:372:RFAddReader() Broadcom Corp 5880 [Broadcom USH] (0123456789ABCD) init failed. It does not look like the problem is the Broadcom reader. Can you generate a log as documented in https://pcsclite.alioth.debian.org/pcsclite.html#support ? Start the log and then connect your problematic mass-storage USB key. Thanks -- Dr. Ludovic Rousseau
Bug#809734: pcscd segfaults accessing the smart card
Le 14/01/2016 19:31, Alessio Gaeta a écrit : Il giorno dom, 03/01/2016 alle 20.33 +0100, Ludovic Rousseau ha scritto: I guess your problem comes from the ACS driver. Try to run pcscd inside gdb to generate a backtrace. Do something like: $ sudo gdb /usr/sbin/pcscd (gdb) set args -dfa (gdb) run then start opensc-tool pcscd should crash in gdb use: (gdb) backtrace Yes, you are right: the crash is in the IFD handler. For the records, here the backtrace: #0 __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:36 #1 0x7720c3ad in T1_ExchangeData () from /usr/lib/pcsc/drivers/acsAcr30.bundle/Contents/Linux/acsAcr30 #2 0x7720c78d in IFDHTransmitToICC () from /usr/lib/pcsc/drivers/acsAcr30.bundle/Contents/Linux/acsAcr30 #3 0x004073d5 in IFDTransmit (rContext=0x61f010, pioTxPci=..., pucTxBuffer=pucTxBuffer@entry=0x75f9aeb0 "", dwTxLength=dwTxLength@entry=20, pucRxBuffer=pucRxBuffer@entry=0x75faaec0 "", pdwRxLength=0x75f9aca8, pioRxPci=0x75f9acb0) at ifdwrapper.c:530 #4 0x00411563 in SCardTransmit (hCard=, pioSendPci=pioSendPci@entry=0x75f9ad50, pbSendBuffer=pbSendBuffer@entry=0x75f9aeb0 "", cbSendLength=20, pioRecvPci=pioRecvPci@entry=0x75f9ad60, pbRecvBuffer=pbRecvBuffer@entry=0x75faaec0 "", pcbRecvLength=0x75f9ad38) at winscard.c:1617 #5 0x00412de1 in ContextThread (newContext=0x62fea0) at winscard_svc.c:641 #6 0x777b9284 in start_thread (arg=0x75fbb700) at pthread_create.c:333 #7 0x774f674d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 I cannot fix it, regrettably I do not have enough time to learn everything needed... :) It is a pity, though, because the driver has been written by David Corcoran, a name I read often in pcsc-lite source: it could have been a device more, just like ACR38U. I can't find a Debian package providing this driver. Do you confirm the acsAcr30 driver is NOT packaged by Debian? So, sorry for the noise, feel free to close the (non-)bug. Thanks for your support and your work. You are welcome. Bye -- Dr. Ludovic Rousseau
Bug#809734: pcscd segfaults accessing the smart card
Le 03/01/2016 15:38, Alessio Gaeta a écrit : Package: pcscd Version: 1.8.15-1 Severity: normal Hello, I'm trying to use my smart card reader, but pcscd segfaults while accessing the smart card. I'm not raising the importance of this bug because the problem could be the smart card reader IFD-handler and/or the SC driver. My card reader is an ACS ACR30U and I had to compile the handler from obsolete source code found on internet (ACR30U_PCSC_LINUX_1_0.zip). The handler seems to work. In attachment there is the 'pcscd -f -a -d' log with the following operations: 1. Connect the reader 2. Insert the card (Italian CNS from Actalis, IDProtect software) 3. Executing 'opensc-tool -n -v' The output of 3 is: Using reader with a card: ACS ACR 30u 00 00 Connecting to card in reader ACS ACR 30u 00 00... Using card driver Italian CNS. Failed to lock card: No readers found In system journal I found the line kernel: traps: pcscd[25750] general protection ip:7f391f84576e sp:7f391e58c7f8 error:0 in libc-2.21.so[7f391f7b5000+19a000] I also tried to install the IDProtect software supplied [1], but with no luck. I could not configure OpenSC to use the custom SC driver either (I don't know where I'm wrong). I guess your problem comes from the ACS driver. Try to run pcscd inside gdb to generate a backtrace. Do something like: $ sudo gdb /usr/sbin/pcscd (gdb) set args -dfa (gdb) run then start opensc-tool pcscd should crash in gdb use: (gdb) backtrace Thanks -- Dr. Ludovic Rousseau
Bug#748754: Fwd: Bug#748754: pcscd: card reader no longer recognized
Le 26/12/2015 17:37, Martin-Éric Racine a écrit : 1.4.7-1 worked: 'pkcs15-tool --list-keys' correctly shows both of the RSA certificates. I visited the snapshot host ( http://snapshot.debian.org/package/ccid/ ) and gradually upgraded until I found the culprit: Setting up libccid (1.4.15-1) ... Installing new version of config file /etc/libccid_Info.plist ... Installing new version of config file /etc/reader.conf.d/libccidtwin ... This version installs a new version of libccidtwin and that is what seemingly breaks it. The log under 1.4.14-1 (last known good version) is attached. Actions performed during this trace: 1. launch the pcsd daemon in debug mode. 2. insert card. 3. execute 'pkcs15-tool --list-keys' on another terminal. 4. remove card. 5. terminate the pcsd daemon. I hope this helps. Yes, it greatly helped. Your problem should be already solved in CCID version 1.4.20. Just for info, the upstream commit is https://anonscm.debian.org/cgit/pcsclite/CCID.git/commit/?id=205e4657b87aa9367af755f28461436ab43696d5 Debian testing has the CCID driver version 1.4.21. Can you try with this version and confirm the bug is fixed? Bye -- Dr. Ludovic Rousseau
Bug#748754: Fwd: Bug#748754: pcscd: card reader no longer recognized
Le 26/12/2015 18:29, Martin-Éric Racine a écrit : 2015-12-26 19:04 GMT+02:00 Ludovic Rousseau <ludovic.rouss...@gmail.com>: Your problem should be already solved in CCID version 1.4.20. Just for info, the upstream commit is https://anonscm.debian.org/cgit/pcsclite/CCID.git/commit/?id=205e4657b87aa9367af755f28461436ab43696d5 Visited snaphost again: 1.4.19-1 fails, 1.4.20-1 works. Good. Debian testing has the CCID driver version 1.4.21. Can you try with this version and confirm the bug is fixed? 1.4.21-1 works too. Could the fix please be pushed into STABLE as 1.4.18-1+deb8u1 too? It is not a security issue. I am not sure I can push this fix into stable. Bye -- Dr. Ludovic Rousseau
