Bug#928910: feature request: support odroid-hc1
Package: flash-kernel Version: 3.98 Would it be possible to support odroid-hc1 single board computers with flash-kernel? Here is how I configure the board manually: https://wiki.debian.org/InstallingDebianOn/OdroidHC1 flash-kernel wouldn't need to deal with samsung firmware blobs, as those get installed once and are never touched again. To update u-boot on an sd-card it only needs to: dd iflag=dsync oflag=dsync if=$uboot of=$device seek=63 Is any other info required for this? Thanks, Andreas
Bug#880494: D-I fails on odroid-hc1 devices: kernel doesn't find usb connected SATA and network card
Package: debian-installer Version: 20171008 To install Debian on Odroid-hc1 single board computer I managed to combine firmware.none and the armhf images and modify the result with the latest u-boot and network-console kernels and inject the vendor firmware blobs. But the network card is not found, it seems an issue with the kernel. Bypassing D-I with gparted/mkfs/multistrap/... the result is a fine booting debian system, the only extra binaries are the firmware blobs around u-boot, i.e. no modified debian packages were required. How can I analyze the system and provide the necessary info to get all required modules into the typical D-I powered install images? I'm told the list of modules in D-I might be manually configured, thus here is lsmod as a start: What other information would be useful? root@debian-odroid-h1:~# dpkg -l |grep linux-image ii linux-image-4.13.0-1-armmp-lpae 4.13.4-2 armhf Linux 4.13 for ARMv7 multiplatform compatible SoCs supporting LPAE ii linux-image-armmp-lpae 4.13+86armhf Linux for ARMv7 multiplatform compatible SoCs supporting LPAE (meta-package) root@debian-odroid-h1:~# lsmod Module Size Used by cdc_ether 16384 0 usbnet 32768 1 cdc_ether r8152 57344 0 mii16384 2 usbnet,r8152 exynosdrm 86016 0 analogix_dp36864 1 exynosdrm drm_kms_helper139264 2 exynosdrm,analogix_dp drm 299008 4 exynosdrm,analogix_dp,drm_kms_helper exynos_adc 24576 0 pwm_samsung16384 2 industrialio 57344 1 exynos_adc s3c2410_wdt16384 0 leds_pwm 16384 0 cpufreq_dt 16384 0 pwm_fan16384 0 ip_tables 24576 0 x_tables 24576 1 ip_tables autofs440960 2 ext4 589824 2 crc16 16384 1 ext4 mbcache16384 1 ext4 jbd2 102400 1 ext4 crc32c_generic 16384 4 fscrypto 24576 1 ext4 ecb16384 0 xhci_plat_hcd 16384 0 xhci_hcd 176128 1 xhci_plat_hcd dwc3 102400 0 udc_core 36864 1 dwc3 phy_generic16384 0 s2mps1157344 19 clk_s2mps1116384 0 dwc3_exynos16384 0 phy_exynos_mipi_video16384 0 phy_exynos_dp_video16384 0 i2c_exynos516384 0 ohci_exynos16384 0 ohci_hcd 45056 1 ohci_exynos ehci_exynos16384 0 ehci_hcd 77824 1 ehci_exynos usbcore 204800 9 ehci_exynos,usbnet,ehci_hcd,cdc_ether,xhci_plat_hcd,ohci_hcd,ohci_exynos,r8152,xhci_hcd dw_mmc_exynos 16384 0 dw_mmc_pltfm 16384 1 dw_mmc_exynos dw_mmc 36864 2 dw_mmc_pltfm,dw_mmc_exynos usb_common 16384 3 udc_core,usbcore,dwc3 phy_exynos_usb220480 2 phy_exynos5_usbdrd 16384 4 Some details frm the boot log: root@debian-odroid-h1:~# dmesg |grep -i -E "usb|hci|exynos|815|hub" [0.010515] Exynos MCPM support installed [0.109738] EXYNOS5420 PMU initialized [5.478185] exynos5_usb3drd_phy 1210.phy: 1210.phy supply vbus not found, using dummy regulator [5.492258] exynos5_usb3drd_phy 1210.phy: 1210.phy supply vbus-boost not found, using dummy regulator [5.492315] usbcore: registered new interface driver usbfs [5.492459] usbcore: registered new interface driver hub [5.492769] usbcore: registered new device driver usb [5.496834] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [5.498256] ehci-exynos: EHCI EXYNOS driver [5.499238] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [5.500351] ohci-exynos: OHCI EXYNOS driver [5.540049] dwmmc_exynos 1220.mmc: IDMAC supports 32-bit address mode. [5.546324] dwmmc_exynos 1220.mmc: Using internal DMA controller. [5.552121] dwmmc_exynos 1220.mmc: Version ID is 250a [5.557500] dwmmc_exynos 1220.mmc: DW MMC controller at irq 73,64 bit host data width,64 deep fifo [5.567483] dwmmc_exynos 1222.mmc: IDMAC supports 32-bit address mode. [5.573999] dwmmc_exynos 1222.mmc: Using internal DMA controller. [5.579904] dwmmc_exynos 1222.mmc: Version ID is 250a [5.585305] dwmmc_exynos 1222.mmc: DW MMC controller at irq 74,64 bit host data width,64 deep fifo [5.594932] samsung-usb2-phy 1213.phy: 1213.phy supply vbus not found, using dummy regulator [5.604806] exynos-ehci 1211.usb: EHCI Host Controller [5.608962] dwmmc_exynos 1220.mmc: IDMAC supports 32-bit address mode. [5.612294] dwmmc_exynos 1220.mmc: Using internal DMA controller. [5.612310] dwmmc_exynos 1220.mmc: Version ID is 250a [5.612344] dwmmc_exynos 1220.mmc: DW MMC controller at irq 73,64 bit host data width,64 deep fifo [
Bug#615230: Uses deprecated HAL
Hi Michael, the last packaging of openct that I tried is here: http://www.opensc-project.org/ubuntu/ at least that packaging has Recommends: udev instead of hal, so the bug you are reporting was fixed back then a year ago - but it seems those fixes never made it into ubuntu or debian. can you diff this with the current packaging and see if there are other fixes that somehow got lost too? sorry, right now I don't have the time to check these things myself. thanks and best regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564652: new patch for kfreebsd
this patch is untested, but it fixes:
* use --enable-usb on kfreebsd in configure flags.
* add Build-Depends: libusb-dev for the two freebsd architectures.
* add Build-Conflicts: libubsb-dev for all other architectures.
* Recommends: udev (openct no longer uses hal, control wasn't updated)
* merge improved README.debian from ubuntu
* merge patches/doc_Makefile.patch from ubuntu
* merge patches/init-script.patch from ubuntu
* update patches/series
sorry, not even compile tested so far :(
in the meantime drazzib on #debian-kbsd has written and tested a patch
for kfreebsd too, and will post it here later. maybe you can merge both
patches into a new package? or I will try to do so, and post again with
an updated patch later.
Thanks, Andreas
diff -udrNPp debian/openct-0.6.20/debian/control openct-0.6.20/debian/control
--- debian/openct-0.6.20/debian/control 2010-02-28 10:49:23.0 +0100
+++ openct-0.6.20/debian/control 2010-04-07 22:38:39.0 +0200
@@ -2,7 +2,8 @@ Source: openct
Section: utils
Priority: extra
Maintainer: Eric Dorland e...@debian.org
-Build-Depends: cdbs (= 0.4.38), debhelper (= 5.0.45), libpcsclite-dev (= 1.4.0), pkg-config, libltdl3-dev
+Build-Depends: cdbs (= 0.4.38), debhelper (= 5.0.45), libpcsclite-dev (= 1.4.0), pkg-config, libltdl3-dev, libusb2-dev [kfreebsd-i386 kfreebsd-amd64]
+Build-Conflicts: libusb-dev [alpha amd64 armel hppa hurd-i386 i386 ia64 mips mipsel powerpc s390 sparc]
Standards-Version: 3.8.3
Homepage: http://www.opensc-project.org/
Vcs-Git: git://git.debian.org/git/pkg-opensc/openct.git
@@ -53,7 +54,7 @@ Package: openct
Architecture: any
Provides: pcsc-ifd-handler
Depends: ${shlibs:Depends}, dpkg (= 1.7.0), adduser, ${misc:Depends}
-Recommends: hal
+Recommends: udev
Description: middleware framework for smart card terminals
OpenCT is an open source implementation providing card terminal
drivers. It provides a native OpenCT, CT-API and PC/SC Lite IFD
diff -udrNPp debian/openct-0.6.20/debian/openct.README.Debian openct-0.6.20/debian/openct.README.Debian
--- debian/openct-0.6.20/debian/openct.README.Debian 2010-02-28 10:49:23.0 +0100
+++ openct-0.6.20/debian/openct.README.Debian 2010-02-11 17:16:45.0 +0100
@@ -5,19 +5,19 @@ This package adds an scard group to your
give access to the card readers must be added to that group. Note that
root always has access to any card readers in the system.
-OpenCT was migrated to use hal for configuration. Linux Hotplug developers
-suggested this move and currently only support hald setup (while udev
-setup might work or not).
+If a new USB smart card reader or crypto token is plugged in,
+openct has to notice this somehow. This package is configured to
+rely on the linux kernel and udev to do that with these files:
+ /lib/udev/rules.d/60-openct.rules
+ /lib/udev/openct_pcmcia
+ /lib/udev/openct_usb
+ /lib/udev/openct_serial
-If you want to disable hald setup, this package includes an fdi file
-as example, all you have to do is copy it to /etc/hal/fdi/policy.
- cp /usr/share/doc/examples/openct-disable.fdi /etc/hal/fdi/policy/
-will do that for you.
+If you install OpenCT and PCSC-Lite with CCID driver at the same
+time, you end up with two drivers for one device. OpenCT is configured
+with a one second delay, so CCID driver for PCSC-Lite will win this
+conflict.
-Usualy you want to run pcsc-lite with libccid, or openct, but please don't
-install all three packages unless you exactly know what you are doing.
-People doing that had problems with openct and libccid fighting over CCID
-usb smart card readers. Latest OpenCT has now a small delay build in, so
-usualy pcscd with libccid will win in such situations.
+ -- Eric Dorland e...@debian.org, Thu, 11 Feb 2010 11:03:15 +0100
- -- Eric Dorland e...@debian.org, Mon, 15 Jun 2009 00:56:57 -0400
+
diff -udrNPp debian/openct-0.6.20/debian/patches/doc_Makefile.patch openct-0.6.20/debian/patches/doc_Makefile.patch
--- debian/openct-0.6.20/debian/patches/doc_Makefile.patch 1970-01-01 01:00:00.0 +0100
+++ openct-0.6.20/debian/patches/doc_Makefile.patch 2010-02-11 17:14:47.0 +0100
@@ -0,0 +1,26 @@
+Index: openct-0.6.19/doc/Makefile.am
+===
+--- openct-0.6.19.orig/doc/Makefile.am 2010-02-11 16:12:55.433842105 +
openct-0.6.19/doc/Makefile.am 2010-02-11 16:13:23.393545800 +
+@@ -18,7 +18,7 @@
+ api.out: $(top_srcdir)/src/include/openct/*.h \
+ $(srcdir)/*.gif \
+ doxygen.conf
+- -rm -fr api.out
++ -rm -f api.out
+ $(DOXYGEN) doxygen.conf
+ cp $(srcdir)/*.gif api.out/html
+ else
+Index: openct-0.6.19/doc/Makefile.in
+===
+--- openct-0.6.19.orig/doc/Makefile.in 2010-02-11 16:14:16.363830226 +
openct-0.6.19/doc/Makefile.in 2010-02-11 16:14:43.413830403 +
+@@ -669,7 +669,7 @@
+ @svn_checkout_t...@api.out: $(top_srcdir)/src/include/openct/*.h \
+ @SVN_CHECKOUT_TRUE@
Bug#564652: fix build for freebsd
Am Sonntag 28 Februar 2010 10:35:05 schrieb Eric Dorland: * Andreas Jellinghaus (a...@dungeon.inka.de) wrote: Build-Conflicts: should handle this, right? patch attached. Andreas I'm confused now. The freebsd patch earlier in this thread seems to add a dependency on libusb2 for freebsd. Your patch adds a build conflict on libusb-dev. Are both necessary? well, if someone really knows freebsd well and can take care of porting openct to it, I'd be happy about it. so far my knowledge is: the generic libusb code doesn't work well on linux, so the native driver is needed. libusb-dev should not be installed (else it could be autodetected). if freebsd needs libusb port (as the native bsd code maybe is even worse than the libusb driver): can you specify different conflicts/depends for each architecture? also I wonder how/if *bsd has hotplugging or coldplugging, and how exactly that is implemented, and how openct can mix with that. openct now uses udev again, after hal is beeing removed by most distributions. *bsd has no udev I guess, but is there any alternative? note: I'm not aware of any active bsd user on the mailing list - we maybe get one bsd mail every few months if at all. so maybe it is best to exclude openct from kfreebsd unless someone is found who can make sure it actually works and can test it? Regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570105: openct - new version available
Package: openct Version: 0.6.19-1 Severity: normal OpenCT 0.6.20 is now available. It would be best to package this based on the ubuntu package available at: https://launchpad.net/ubuntu/+source/openct/0.6.19-1ubuntu3 As that package fixes many issues still found in debian package 0.6.19-1. The patch for the doc/Makefile.* files can be dropped with 0.6.20, as this was fixed upstream. All other changes are build-related and are still needed. OpenCT 0.6.20 mostly fixes the new Rutoken S driver. Regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201002161529.26119...@dungeon.inka.de
Bug#570107: opensc 0.11.13 available
Package: opensc Version: 0.11.12-1 Severity: normal OpenSC 0.11.13 is now available, with small bugfixes and an update of the Rutoken S driver. Regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201002161535.02705...@dungeon.inka.de
Bug#563755: please sync with ubuntu
ubuntu has a working openct package at https://launchpad.net/ubuntu/+source/openct/0.6.19-1ubuntu2 and if you add the patch in https://bugs.launchpad.net/ubuntu/+source/openct/+bug/520378 on top of that ubuntu source package, all bugs concerning openct are fixed (udev, build issues, recommendation, README.debian, Recommends:, Build-Conflicts: for the freeBSD port). Regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563755: new ubuntu packag with all fixes
https://launchpad.net/ubuntu/+source/openct/0.6.19-1ubuntu3 has the latest ubuntu package, with all patches included. if you pull in these changes, all debian bugs should be fixed too (including the build issue with kfreebsd). Regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#505404: what about --update-certificate
I haven't tried, but --update-certificate should be what you want. if you store a certificate twice, then of course it is stored twice. but if you store it once, and update it later, there should be only one. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#505396: patched
Sendingtools/pkcs15-init.xml Transmitting file data . Committed revision 4012. removed -P from documentation as a quick fix. will be part of 0.12 release. Regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#451155: please send a patch
can you edit doc/tools/pkcs15-init.xml file? also available via svn: svn co http://www.opensc-project.org/svn/opensc/trunk/doc/tools/ Regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#487159: each card comes with paper showing the transport key
sorry, but everytime I bought cryptoflex cards, the manufacturer / redistributor sendit with some piece of paper with the transport key on it. the docbook documentation for the tools is in doc/tools/*.xml. but maybe the card documentation is a better place? see our wiki, if you change it there, we will pull in the latest version into the source when building tar.gz files. Regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#409948: signer about to be removed
we haven't heard from any user of the signer on opensc-devel mailing list in years. if you use it / want to use it, please subscribe to opensc-devel and discuss it with us, so we can see what we can do to help you. currently the signer will be removed from opensc with 0.12 release line. Regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#407542: disable openct simply
if you use pcsc, why don't you disable openct? from the faq: http://www.opensc-project.org/faq.html --cut-- /var/run/openct/status: No such file or directory OpenSC has support for three driver types below it: PCSC, OpenCT and CT-API. If you want to use OpenSC with PC/SC-Lite only, please edit opensc.conf, look for reader_drivers like and remove the openct driver. If you get this message, but want to use OpenSC with OpenCT, then you have not properly installed OpenCT. Please have a look at the QuickStart docucument in OpenCT, most likely you didn't start the init script or it was not properly installed or something like that. --cut-- also if you use the binary only software from Aladdin, you might want to talk to them - if it is a bug in their software, what can we do about it? pkcs11-tool is a robust tool that works well with opensc and many other vendors pkcs#11 modules, so if it hangs for whatever reason, we need details to find out why. for example run it in a debugger and see in whose code it hangs (my guess: the vendors library). also you could use pkcs11-spy.so to debug the issue (see the documentation for details how to use that one). Regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#410025: bug in firefox, not opensc.
opensc makes all pins available as virtual slots, so you can decice what pin to use for login and then access the objects associated with that pin. the problem is firefox: it wants to login into all slots, even if the pin is marked as nonrepudiation pin. that is not a good idea from my point of view. so I think firefox needs to be improved, not an opensc bug. Regards, Andreas (see recent discussion on opensc-devel on 2010-02-10) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564652: fix build for freebsd
Build-Conflicts: should handle this, right? patch attached. Andreas For freebsd: don't compile with libusb! make sure libusb-dev is not installed diff -udrNPp openct-0.6.19-1/debian/control openct-0.6.19-0/debian/control --- openct-0.6.19-1/debian/control 2010-01-10 06:21:37.0 +0100 +++ openct-0.6.19-0/debian/control 2010-02-10 09:50:31.0 +0100 @@ -3,7 +3,8 @@ Section: utils Priority: extra Maintainer: Eric Dorland e...@debian.org Build-Depends: cdbs (= 0.4.38), debhelper (= 5.0.45), libpcsclite-dev (= 1.4.0), pkg-config, libltdl3-dev -Standards-Version: 3.8.3 +Build-Conflicts: libusb-dev +Standards-Version: 3.8.3 Homepage: http://www.opensc-project.org/ Vcs-Git: git://git.debian.org/git/pkg-opensc/openct.git Vcs-Browser: http://git.debian.org/?p=pkg-opensc/openct.git
Bug#563755: please update to udev
here is the patch to move openct to udev with latest rules. (same as posted to the other bug). please apply and close both. Regards, Andreas * Migrate to udev based setup as distributions deprecate of hal. * New udev rules no longer generate warnings. (Closes: #563755) * Now compiled --with-bundle= for pcsc support. (Closes: 528123) diff -udrNPp openct-0.6.19-1/debian/openct.install openct-0.6.19-0/debian/openct.install --- openct-0.6.19-1/debian/openct.install 2010-01-10 06:21:37.0 +0100 +++ openct-0.6.19-0/debian/openct.install 2010-02-10 09:41:21.0 +0100 @@ -6,17 +6,12 @@ debian/tmp/usr/lib/libopenctapi.a debian/tmp/usr/lib/openct-ifd.so debian/tmp/usr/lib/openct-ifd.la debian/tmp/usr/lib/openct-ifd.a - -debian/10-usb-openct.fdi usr/share/hal/fdi/information/10freedesktop -debian/10-usb-openct-policy.fdi usr/share/hal/fdi/policy/10osvendor -debian/hald-addon-openct usr/lib/hal - +debian/tmp/usr/lib/pcsc/drivers/* etc/openct.conf etc/ - debian/openct.reader.conf etc/reader.conf.d - debian/tmp/usr/share/man -etc/openct-disable.fdi usr/share/doc/examples doc/nonpersistent/wiki.out/*.html usr/share/doc/openct/html doc/nonpersistent/wiki.out/*.css usr/share/doc/openct/html doc/api.out/html/* usr/share/doc/openct/html/api +debian/60-openct.rules lib/udev/rules.d +debian/tmp/lib/udev/* diff -udrNPp openct-0.6.19-1/debian/patches/series openct-0.6.19-0/debian/patches/series --- openct-0.6.19-1/debian/patches/series 2010-01-10 06:26:03.0 +0100 +++ openct-0.6.19-0/debian/patches/series 1970-01-01 01:00:00.0 +0100 @@ -1 +0,0 @@ -debian-changes diff -udrNPp openct-0.6.19-1/debian/rules openct-0.6.19-0/debian/rules --- openct-0.6.19-1/debian/rules 2010-01-10 06:21:37.0 +0100 +++ openct-0.6.19-0/debian/rules 2010-02-10 09:41:21.0 +0100 @@ -3,16 +3,14 @@ include /usr/share/cdbs/1/class/autotools.mk include /usr/share/cdbs/1/rules/debhelper.mk -DEB_CONFIGURE_EXTRA_FLAGS = --enable-pcsc +DEB_CONFIGURE_EXTRA_FLAGS = --enable-pcsc --with-udev=/lib/udev \ + --with-bundle=/usr/lib/pcsc/drivers DEB_INSTALL_DOCS_ALL := NEWS TODO install/openct:: cp -f etc/init-script debian/openct.init - cp -f etc/openct.fdi debian/10-usb-openct.fdi - cp -f etc/openct-policy.fdi debian/10-usb-openct-policy.fdi - cp -f etc/openct.hald debian/hald-addon-openct - chmod 0755 debian/hald-addon-openct + cp -f etc/openct.udev debian/60-openct.rules binary-post-install/openct:: # Rename some stuff @@ -20,5 +18,4 @@ binary-post-install/openct:: $(CURDIR)/debian/openct/etc/reader.conf.d/openct clean:: - rm -f debian/openct.init debian/10-usb-openct.fdi \ - debian/10-usb-openct-policy.fdi debian/hald-addon-openct + rm -f debian/openct.init debian/60-openct.rules
Bug#569132: openct makefile bug
Package: openct Version: 0.6.19-1 Severity: normal Tag: patch the doc/Makefile* has a bug, it removes doc/api.out directory. that way you always need to rebuild from a fresh source, which is annoying. here is a patch to fix that. Regards, Andreas This is a bug in the build process that will remove real content, and thus not allow re-building openct correctly (api doc will be missing). diff -udrNPp openct-0.6.19-1/doc/Makefile.am openct-0.6.19-0/doc/Makefile.am --- openct-0.6.19-1/doc/Makefile.am 2009-07-29 09:04:32.0 +0200 +++ openct-0.6.19-0/doc/Makefile.am 2010-02-10 09:41:21.0 +0100 @@ -28,4 +28,4 @@ $(abs_builddir)/api.out: endif clean-local: - -rm -fr api.out + -rm -f api.out diff -udrNPp openct-0.6.19-1/doc/Makefile.in openct-0.6.19-0/doc/Makefile.in --- openct-0.6.19-1/doc/Makefile.in 2010-01-07 10:54:48.0 +0100 +++ openct-0.6.19-0/doc/Makefile.in 2010-02-10 09:41:21.0 +0100 @@ -677,7 +677,7 @@ uninstall-am: uninstall-dist_apidocDATA @SVN_CHECKOUT_FALSE@ $(LN_S) $(srcdir)/api.out api.out clean-local: - -rm -fr api.out + -rm -f api.out # Tell versions [3.59,3.63) of GNU make to not export all variables. # Otherwise a system limit (for SysV at least) may be exceeded.
Bug#337317: pleae move to udev
hal is out, udev is the new (and old) player for hotlplugging devices, and with proper rules there should be no problem. patch with everything attached. Regards, Andreas * Migrate to udev based setup as distributions deprecate of hal. * New udev rules no longer generate warnings. (Closes: #563755) * Now compiled --with-bundle= for pcsc support. (Closes: 528123) diff -udrNPp openct-0.6.19-1/debian/openct.install openct-0.6.19-0/debian/openct.install --- openct-0.6.19-1/debian/openct.install 2010-01-10 06:21:37.0 +0100 +++ openct-0.6.19-0/debian/openct.install 2010-02-10 09:41:21.0 +0100 @@ -6,17 +6,12 @@ debian/tmp/usr/lib/libopenctapi.a debian/tmp/usr/lib/openct-ifd.so debian/tmp/usr/lib/openct-ifd.la debian/tmp/usr/lib/openct-ifd.a - -debian/10-usb-openct.fdi usr/share/hal/fdi/information/10freedesktop -debian/10-usb-openct-policy.fdi usr/share/hal/fdi/policy/10osvendor -debian/hald-addon-openct usr/lib/hal - +debian/tmp/usr/lib/pcsc/drivers/* etc/openct.conf etc/ - debian/openct.reader.conf etc/reader.conf.d - debian/tmp/usr/share/man -etc/openct-disable.fdi usr/share/doc/examples doc/nonpersistent/wiki.out/*.html usr/share/doc/openct/html doc/nonpersistent/wiki.out/*.css usr/share/doc/openct/html doc/api.out/html/* usr/share/doc/openct/html/api +debian/60-openct.rules lib/udev/rules.d +debian/tmp/lib/udev/* diff -udrNPp openct-0.6.19-1/debian/patches/series openct-0.6.19-0/debian/patches/series --- openct-0.6.19-1/debian/patches/series 2010-01-10 06:26:03.0 +0100 +++ openct-0.6.19-0/debian/patches/series 1970-01-01 01:00:00.0 +0100 @@ -1 +0,0 @@ -debian-changes diff -udrNPp openct-0.6.19-1/debian/rules openct-0.6.19-0/debian/rules --- openct-0.6.19-1/debian/rules 2010-01-10 06:21:37.0 +0100 +++ openct-0.6.19-0/debian/rules 2010-02-10 09:41:21.0 +0100 @@ -3,16 +3,14 @@ include /usr/share/cdbs/1/class/autotools.mk include /usr/share/cdbs/1/rules/debhelper.mk -DEB_CONFIGURE_EXTRA_FLAGS = --enable-pcsc +DEB_CONFIGURE_EXTRA_FLAGS = --enable-pcsc --with-udev=/lib/udev \ + --with-bundle=/usr/lib/pcsc/drivers DEB_INSTALL_DOCS_ALL := NEWS TODO install/openct:: cp -f etc/init-script debian/openct.init - cp -f etc/openct.fdi debian/10-usb-openct.fdi - cp -f etc/openct-policy.fdi debian/10-usb-openct-policy.fdi - cp -f etc/openct.hald debian/hald-addon-openct - chmod 0755 debian/hald-addon-openct + cp -f etc/openct.udev debian/60-openct.rules binary-post-install/openct:: # Rename some stuff @@ -20,5 +18,4 @@ binary-post-install/openct:: $(CURDIR)/debian/openct/etc/reader.conf.d/openct clean:: - rm -f debian/openct.init debian/10-usb-openct.fdi \ - debian/10-usb-openct-policy.fdi debian/hald-addon-openct + rm -f debian/openct.init debian/60-openct.rules
Bug#528123: here is a patch
tag patch the migrate to udev patch fixes that issues too. or look at this patch, and extract the pcsc lines only. Regards, Andreas * Migrate to udev based setup as distributions deprecate of hal. * New udev rules no longer generate warnings. (Closes: #563755) * Now compiled --with-bundle= for pcsc support. (Closes: 528123) diff -udrNPp openct-0.6.19-1/debian/openct.install openct-0.6.19-0/debian/openct.install --- openct-0.6.19-1/debian/openct.install 2010-01-10 06:21:37.0 +0100 +++ openct-0.6.19-0/debian/openct.install 2010-02-10 09:41:21.0 +0100 @@ -6,17 +6,12 @@ debian/tmp/usr/lib/libopenctapi.a debian/tmp/usr/lib/openct-ifd.so debian/tmp/usr/lib/openct-ifd.la debian/tmp/usr/lib/openct-ifd.a - -debian/10-usb-openct.fdi usr/share/hal/fdi/information/10freedesktop -debian/10-usb-openct-policy.fdi usr/share/hal/fdi/policy/10osvendor -debian/hald-addon-openct usr/lib/hal - +debian/tmp/usr/lib/pcsc/drivers/* etc/openct.conf etc/ - debian/openct.reader.conf etc/reader.conf.d - debian/tmp/usr/share/man -etc/openct-disable.fdi usr/share/doc/examples doc/nonpersistent/wiki.out/*.html usr/share/doc/openct/html doc/nonpersistent/wiki.out/*.css usr/share/doc/openct/html doc/api.out/html/* usr/share/doc/openct/html/api +debian/60-openct.rules lib/udev/rules.d +debian/tmp/lib/udev/* diff -udrNPp openct-0.6.19-1/debian/patches/series openct-0.6.19-0/debian/patches/series --- openct-0.6.19-1/debian/patches/series 2010-01-10 06:26:03.0 +0100 +++ openct-0.6.19-0/debian/patches/series 1970-01-01 01:00:00.0 +0100 @@ -1 +0,0 @@ -debian-changes diff -udrNPp openct-0.6.19-1/debian/rules openct-0.6.19-0/debian/rules --- openct-0.6.19-1/debian/rules 2010-01-10 06:21:37.0 +0100 +++ openct-0.6.19-0/debian/rules 2010-02-10 09:41:21.0 +0100 @@ -3,16 +3,14 @@ include /usr/share/cdbs/1/class/autotools.mk include /usr/share/cdbs/1/rules/debhelper.mk -DEB_CONFIGURE_EXTRA_FLAGS = --enable-pcsc +DEB_CONFIGURE_EXTRA_FLAGS = --enable-pcsc --with-udev=/lib/udev \ + --with-bundle=/usr/lib/pcsc/drivers DEB_INSTALL_DOCS_ALL := NEWS TODO install/openct:: cp -f etc/init-script debian/openct.init - cp -f etc/openct.fdi debian/10-usb-openct.fdi - cp -f etc/openct-policy.fdi debian/10-usb-openct-policy.fdi - cp -f etc/openct.hald debian/hald-addon-openct - chmod 0755 debian/hald-addon-openct + cp -f etc/openct.udev debian/60-openct.rules binary-post-install/openct:: # Rename some stuff @@ -20,5 +18,4 @@ binary-post-install/openct:: $(CURDIR)/debian/openct/etc/reader.conf.d/openct clean:: - rm -f debian/openct.init debian/10-usb-openct.fdi \ - debian/10-usb-openct-policy.fdi debian/hald-addon-openct + rm -f debian/openct.init debian/60-openct.rules
Bug#509412: closed by Andreas Jellinghaus a...@dungeon.inka.de (user misunderstanding?)
ok, let me phrase it that way: a typical card has certificates - non-authoritative belong to the user, authoritatives are part of the chain to the root ca. normal cards don't have rsa public keys. normal cards have a private rsa keys for each user certificate. normal cards need a pin before the private rsa key is visible. so what pam_p11 does is match the certificates or rsa public key in whatever file against the certificates (or rsa public key inside the certificate). only if it finds a match, it will ask for the pin, and then make sure there is a private key that can sign some random data, and verifiy that signature. if there is no matching certificate the card is refused without ever asking for a pin. switching from looking to certificate to _INSTEAD_ look for public rsa keys only would be a grave mistake, as many cards have no public rsa keys (well, with some cards opensc emulates those, but other pkcs#11 libs don't do that). so with typical cards it will no longer work. you could extend the code, to look also for public keys. but that will only work with some cards, and only with the _openssl module. while it might be a nice solution cards with a public rsa key, but without certificates (opensc can create those), I don't think many cards like that are around. patches are welcome. To be clear, these X.509 certificates consist of: A) Some metadata specifying the certificate holder, the issuer, the timing/validity of the certificate,X.509 extensions indicating its acceptable usage, etc. and B) and RSA public key. pam_p11 currently appears to ignore everything in A (e.g. it doesn't care about the expiration date on the cert, the extensions, the issuer, etc), and cares only about B. IIRC only for the _openssh module, but not 100% sure. It asks: can the plugged-in-device, in conjunction with the user-supplied PIN, produce a successful RSA response from the associated private key? no, it first tries to guess, if there is a matching private key on the card. and the way to do that is to look for a matching certificate with the public rsa key part in it. public rsa key objects only exist with some cards. (i'm not sure what you mean by the exception for authoritative certs -- can you explain?) if the authoritive flag is set, we assume that this is a CA cert (e.g. root CA cert, or a middle cert in the chain between root CA and the users certificate), and assume that no private rsa key for that cert is present. If the card does not publish certificates, but *does* publish raw public keys, it could just match against the public keys directly. you are the first user I remember who wants to use such a feature. using pkcs#11 API without also using x.509 certificates is completely uncommon. and those that have certificates don't need such code. so having a debian bug about this possibility is kind of pointless. if you send a clean and nice patch to add such functionality, I can apply it and release a new version. but since you are the first user in ages to ask for such an uncommon feature, it is unlikely anyone else will implement it, unless you do it yourself. In fact, that would be a bad idea on my particular device, because i have two keys on it. It's important that the authorized public key be matched against a particular authentication slot (PIN) on the card and be able to test that the supplied PIN enables the card to produce a successful RSA response from the expected private key. We don't want to blindly try all authentication slots. well, the code should only ask for a pin and use it, if the slot contains a matching ceritificate. so I don't see any blindly try all authentication slots. yes, we could add an option to limit the pam module to some slot. haven't had a request for it so far, patches welcome. also for alternative locations for those files (the file names implemented are simply the old file names that had been implemented by old modules preceeding pam_p11)... But that's not an argument for disallowing raw public keys in the authorization file. the current code is simple, allowing more is adding complexity. if people need more features, they can be added, but so far the code was small and simple and worked without much work. also there is a much bigger and more complex alternative to pam_p11: pam_pkcs11. it has modules, does CA chain certificateion, can check if certiifcates are expired or revoked, can lookup ldap etc. so I'm not sure how much complexity added to pam_p11 would still be good, or when users would be better off with using pam_pkcs11. the whole point of pam_p11 is: it is dead simple. so what do you think is best to do? Regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509412: closed by Andreas Jellinghaus a...@dungeon.inka.de (user misunderstanding?)
Am Mittwoch 10 Februar 2010 17:59:18 schrieb Daniel Kahn Gillmor: What is the _openssl module? do you mean pam_p11_openssh ? oops, yes. The amount of storage space on my eGate appears to be such that if it contains two 2048-bit RSA secret keys, it can only fit one certificate. since public keys are smaller than certificates, it turns out that it can store two public keys. hu? how much memory has your card? maybe the profile isn't optimized for your needs, then simply erase the card, edit the sizes in the profile, and re-initialized till it fits your needs. AFAIK cryptoflex is hierarchical - you need to allocate for each directory enough memory so it can contain all containers placed in it. so having a debian bug about this possibility is kind of pointless. if you send a clean and nice patch to add such functionality, I can apply it and release a new version. but since you are the first user in ages to ask for such an uncommon feature, it is unlikely anyone else will implement it, unless you do it yourself. that's fair enough -- and it's actually been on my list of things to look into doing for a while (though my plate is pretty full at the moment). Would you prefer i file a bug with some upstream bugtracker as well to keep it on a list we could both refer to? no, bugs in bug trackers rot - mailing list is best for us. if noone handles some report, putting it in some bug tracker won't change that situation anyway. and with the limited manpower we have, it shouldn't be spend on managing outdated information. All spelled out, my proposal is: * the filesystem can supply certificates, certificate requests, or raw public keys in ~/.eid/authorized_certificates * pam_p11 extracts the RSA public key from these, to create a set of public keys. * the card produces a set of public keys bound to authentication slots, either embedded in X.509 certificates or as raw public keys. * the system finds the first public key which is in both sets, and asks the user to authenticate to the corresponding slot on the card * the system grants the authentication based on whether the card can properly compute the response to the RSA challenge using the user-supplied PIN. Does that make it clearer? I probably should have written it up like that earlier. ok, sounds nice. not sure how many users want to use CSR or pubkeys instead of certs, but if these formats can be detected easily, then it is propably not too much code to read them and extract the public rsa key, no matter which format was used. but I have little clue about openssl API, so I can't tell. I'd like to leave this bug open (possibly forwarding it to an upstream tracker if you like) until we have a chance to get it sorted out. I understand that might mean me doing the work, and i don't mind that. ok, fine with me. Thanks for having this discussion, and thanks for pam_p11! I hope it's understood that my suggestions and contributions here are meant constructively, not just whining. no issue at all. hope you don't mind me closing it maybe a bit too fast. Thanks! Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#470637: applied to svn trunk
Sendinglibopensc/card-belpic.c Transmitting file data . Committed revision 4010. will be part of 0.12 release. Regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#487191: changes the man page for 0.12 release
I think you are right, so I edited the man page in svn trunk. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564652: openct: FTBFS on kfreebsd-*: sys-bsd.c:579: error: 'struct usb_device_info' has no member named 'udi_devnames'
Am Montag 11 Januar 2010 11:23:54 schrieb Petr Salinger: The rules for api.out are different after checkout from SVN and otherwise. This part should not be GNU/kFreeBSD specific problem. edit doc/Makefile.* and replace rm -fr api.out with rm -f api.out and you should be fine. long term fix planned for next release. btw: have you tested compiling with libusb support? I thought it was broken, at least for linux. and not sure if you need to disable usb with --disable-usb if you have libusb-dev installed. Rgards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564055: new openct release available
Package: openct A new release 0.6.19 is available! The important part is new udev rules, as distributions migrate from hal to udev. Experimental debian packageing with all necessary changes and all open bugs fixed is available at http://www.opensc-project.org/debian/ Regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564056: new engine_pkcs11 0.1.8 avaibale
Package: libengine-pkcs11-openssl A new version 0.1.8 of Engine_PKCS11 is available. I made experimental debian packages available at http://www.opensc-project.org/debian/ This moves the engine_pkcs11.so from /usr/lib/engines/ to /usr/lib/ssl/engines/ as suggested in some bug. Thus it could break systems, maybe add some symlink for compatibility? Regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#506772: bad analysis
yes, you are right: openssl places it engines in /usr/lib/ssl/engines. but your analysis is wrong: engine_pkcs11 can never be loaded without a config file, since it needs to know which PKCS#11 module it should load. thus moving the engine will be a nice cleanup on one hand, but break existing systems unless you add a symlink on the other hand, and not bring the suggested benefit of using it without a config file. not sure if it should be done or how. I placed an experimental debian packaging for 0.1.8 at http://www.opensc-project.org/debian/ which moves the engine, but provides no symlink. maybe not a good idea? Regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563755: udev rules need touchup for recent udev
Am Mittwoch 06 Januar 2010 05:30:29 schrieb Daniel Kahn Gillmor: Package: openct Severity: normal ok, the system reboot worked fine. the only remaining issue is that i've got this line a few times in my syslog: udevd[15501]: unknown key 'WAIT_FOR_ATTR' in /lib/udev/rules.d/70-openct.rules:21 ok, so udev syntax changed again. no big supprise here. that line can be deleted. however that line was once added to protect against race conditions. I can only hope that latest kernel and udev no longer have race conditions (or the sleep we have in the rules files is enough to avoid them). Regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563755: openct udev rules need touchup for recent udev
Hi Daniel, could you test this: http://www.opensc-project.org/svn/openct/trunk/etc/openct.udev.in contains all the changes the ubuntu developers suggested to me. could you check if it works for you too? the script for it is http://www.opensc-project.org/svn/openct/trunk/etc/openct_usb.in only one or two @...@ with the path of some file, so you can easily test them on an existing system without building a new package. I can create a new openct release with these updated rules, if that helps, but I would be real happy if someone can test the latest changes. does debian drop hal in support for udev too? (ubuntu did and I guess everyone does...) Also, /usr/share/doc/udev/NEWS.Debian.gz contains the following: udev (0.140-1) unstable; urgency=low Starting from this release the last applicable NAME directive will be used instead of the first one: check any custom udev rules. The default rules files have been moved to /lib/udev/rules.d/ and /etc/udev/rules.d/ is supposed to contain only generated files or custom directives. -- Marco d'Itri m...@linux.it Wed, 18 Mar 2009 02:34:13 +0100 So i suspect that the file itself should be moved to /lib/udev/rules.d/ to follow this change. ok. any idea if extra work is needed (e.g. a symlink to /etc/udev/rules.d/)? and will this work on ubuntu too, or will we need seperate ubuntu and debian packages? (ok, maybe wrong forum, I'm asking on launchpad.net too...) Thanks for your help! Regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563755: openct udev rules need touchup for recent udev
Am Dienstag 05 Januar 2010 05:46:24 schrieb Daniel Kahn Gillmor: mv /etc/udev/rules.d/z60_openct.rules /root/backup.udev.z60_openct.rules and openct still seems to work for me, but i haven't done a full system restart, which makes me a bit nervous. i'll report back when i've done a system reboot if it's clean for me. Any thoughts on a clean way to drop (or suggest dropping) an unused, out-dated conffile like this? yuck. oops, no idea what is necessary to migrate from udev based setup to hal based setup (and get rid of the udev rules files). so I guess you have a hal based setup and because of that everything still works. but as distributions are getting rid of hal, some already did, openct now needs to migrate back to udev. if you have some time for testing, could you throw out your hal/openct files, and see if the latest udev rules in openct svn work for you? Thanks, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563755: openct udev rules need touchup for recent udev
Hi Daniel, openct package contains these files for hal: /usr/lib/hal/hald-addon-openct /usr/share/hal/fdi/information/10freedesktop/10-usb-openct.fdi /usr/share/hal/fdi/policy/10osvendor/10-usb-openct-policy.fdi delete them. for udev you need these files instead: /etc/udev/rules.d/50-openct.rules /lib/udev/openct_usb the source for the rules file is: http://www.opensc-project.org/svn/openct/trunk/etc/openct.udev.in and run on that file: sed -e s...@udevdir@#/lib/udev/#g openct.udev.in openct.udev cp openct.udev /etc/udev/rules.d/50-openct.rules chown root.root /etc/udev/rules.d/50-openct.rules chmod 0644 /etc/udev/rules.d/50-openct.rules and for the script you need this file: http://www.opensc-project.org/svn/openct/trunk/etc/openct_usb.in and run on that file: sed -e s...@openct_socket_path@#/var/run/openct# \ -e s...@sbindir@/usr/sbin#g openct_usb.in openct_usb cp openct_usb /lib/udev/openct_usb chown root:root /lib/udev/openct_usb chmod 0755 /lib/udev/openct_usb and you should be setup fine. I don't know if hal and udev need restarts for the new configuration, and udev at some point in time had a problem if the init script was restarted. so a reboot might be the safest choice if you want to make sure this new config is active. then after boot run openct-tool list. it should show no smart card reader / usb crypto token. run that as root (or user in group scard), or you won't see anything. then plugin an usb crypto token or smart card reader supported by openct, and run openct-tool list again - openct should now list a reader. Regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552516: New OpenSC Version available -- please change package description
Package: OpenSC Version: 0.11.9-2 A new version of OpenSC is available: 0.11.11. Please update. Also please update the package description: Supported cards include Gemplus GPK, Schlumberger Cryptoflex, Finnish FINEID, Swedish eID, MioCOS and TCOS cards. That list is outdated by far. Also most of those names reflect card families, and users need to check the documentation which card families and which exact model is supported. Here is what suse has in the spec: OpenSC provides a set of libraries and utilities to access smart cards. It mainly focuses on cards that support cryptographic operations. It facilitates their use in security applications such as mail encryption, authentication, and digital signature. OpenSC implements the PKCS#11 API. Applications supporting this API, such as Mozilla Firefox and Thunderbird, can use it. OpenSC implements the PKCS#15 standard and aims to be compatible with every software that does so, too. Before purchasing any cards, please read carefully documentation in /usr/share/doc/packages/opensc/wiki/index.html - only some cards are supported. Not only card type matters, but also card version, card OS version and preloaded applet. Only subset of possible operations may be supported for your card. Card initialization may require third party proprietary software. --cut-- If you change the directory and refer to opensc-doc package, this should be a good text. Thanks, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528482: openct package need several fixes
Hi Eric, thanks for updating the openct package. Enhanced pcscd should be dropped, since 99% of the users do something wrong if they install openct and pcscd at the same time. Usualy it is best to use either opensc with openct. or opensc (or other apps) with pcscd and a reader driver (e.g. libccid) other than openct. Does this mean we should disable it at configure time? no need for that. with pcsc option enabled we build the pcsc driver in ifdhandler format. it is an extra binary and only uses a few bytes of disk space, so no harm for the normal users. and those who want to use it can configure pcscd to do so. Thanks, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528482: openct package need several fixes
Package: openct Version: 0.6.16-1 Severity: normal Author in openct.doc-base.manual is wrong, I didn't write all of that, please change to OpenCT Developers. doc-base file for the api documentation is missing. openct is still configured with udev, this is not supported by udev developers, please switch to hal setup. documentation is still disabled, even though 0.6.16 fixed those issues. README.debian should show how to disable openct if people want that, e.g. with the disable policy file. copyright file is wrong, while Olaf was the original author, lots of other people added code. please change to OpenCT Developers and/or point to the documentation and/or source for a proper list. OpenCT does not need to be configure'd with usb support, it now has a complete native linux usb implementation with some benefits towards power savings. Source dependency on libusb-dev can be dropped. Recommends udev should be replaced by depends/recommends on hal. Enhanced pcscd should be dropped, since 99% of the users do something wrong if they install openct and pcscd at the same time. Usualy it is best to use either opensc with openct. or opensc (or other apps) with pcscd and a reader driver (e.g. libccid) other than openct. For testing I build an openct package with all these changes already applied, as I wrote in the new version available bug, and it is still available here: --cut-- also I took the time to look at the open bugs for debians openct package and the new release should solve all of them. you can find my packaging here, based on the latest 0.6.15-1 package: http://www.opensc-project.org/debian/openct/ --cut-- If my work is ignored without any comment, that doesn't send a good message. Regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526912: new openct release available
package: openct version: 0.6.15 severity: medium a new openct release 0.6.16 is available: http://www.opensc-project.org/files/openct/openct-0.6.16.tar.gz also I took the time to look at the open bugs for debians openct package and the new release should solve all of them. you can find my packaging here, based on the latest 0.6.15-1 package: http://www.opensc-project.org/debian/openct/ Regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#498920: [openct] udev's rule doesn't work for Aladdin eToken PRO 32
Am Montag 06 April 2009 02:46:27 schrieb Eric Dorland:
* Jaros?aw Misztal (pe...@perio6.at) wrote:
Package: openct
Version: 0.6.14-3
Severity: minor
--- Please enter the report below this line. ---
Hi,
'*' is missing in the udev's rule.
--- z60_openct.rules.original 2008-08-11 03:37:00.0 +0100
+++ z60_openct.rules2008-09-14 14:54:58.0 +0100
@@ -24,7 +24,7 @@
ENV{MODALIAS}==usb:v0973p0001*, RUN+=/lib/udev/openct_usb
# eToken
ENV{MODALIAS}==usb:v0529p050C*, RUN+=/lib/udev/openct_usb
-ENV{MODALIAS}==usb:v0529p0514, RUN+=/lib/udev/openct_usb
+ENV{MODALIAS}==usb:v0529p0514*, RUN+=/lib/udev/openct_usb
# eToken 64
ENV{MODALIAS}==usb:v0529p0600*, RUN+=/lib/udev/openct_usb
ENV{MODALIAS}==usb:v0529p0700*, RUN+=/lib/udev/openct_usb
The new openct changed this file substantial. Is it fixed?
at least svn trunk looks fine.
Andreas
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#498920: fix for lenny
in both cases maybe take the latest from openct svn? I think we fixed more entries recently. Regards, Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464124: openct: openct-control init fails
Am Dienstag, 5. Februar 2008 10:33:34 schrieb Daniel Baumann: ... I think it doesn't like new pcscd 1.4.99? hu? pcscd has a process ifdhandler? then we have a problem. ifdhandler is the name of the openct backend process. noone except openct itself needs to know the name, but of course if some other application like pcscd has a binary with the same name, that is asking for trouble. can you check the details i.e. where ifdhandler comes from and how e.g. PATH is used to start the right one? Regards, Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442300: pam-p11 authentication fails with version 0.6.14-1 of openct with egate
Hi Daniel? 1.) which kernel are you running? 2.6.22 before 2.6.22.6 is buggy for example. 2.) do you have usbfs at /proc/bus/usbfs or not? 3.) if you run /etc/init.d/openct restart while the token is plugged in, will openct find it (openct-tool list)? if so, it is a hotplug problem. if your kernel is fine and we agree it is a hotplug problem, them udevmonitor --kernel --environment might help as well as editing /lib/udev/openct_usb, adding ( date; echo $0: $*; export; set -x ... ) /root/openct_debug.log 21 and then plugging in a token, so we see what events the kernel emits and if udev calls openct and what happends in the openct script. also it is important to specify if your kernel is compiled with usb device class support or not. 0.6.14 should now work in both cases, but knowing what kernel we have is still good. also 0.6.14 should work without /proc/bus/usbfs, but testing with and without could help track down a possible bug. I do not have /proc/bus/usb mounted, because i'm under the impression that it is deprecated in favor of sysfs. Dunno if that matters in this case. the situation is much more complex than that. 0.6.14 is the first openct version I can support without /proc/bus/usb but maybe we didn't catch all bugs. Regards, Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439309: new openct version 0.6.14
please update, rebuild, done. nothing special necessary to do as far as I know. Regards, Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337317: still an issue
can anyone test with recent kernels if this still is an issue? udev/kernel/sysfs changed so often, I gave up on tracking it. on my systems current openct and kernel is fine. note: there is a new openct 0.6.14, but the latest 0.6.12-1 package might work as well. (if not edit /etc/udev/rules.d/*openct* and add the missing * in several places. - or update :-) if noone has an issue with current testing, this issue can be closed. Regards, Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439309: openct 0.6.12 openct.udev.modalias problems
Package: openct Version: 0.6.12-1 Hi Eric, oops, I found out I had errors in the new openct.udev.modalias file. They are now fixed and new openct 0.6.13 is released. Also I found out. kernel 2.6.22 has an incompatibility, will be fixed in 2.6.22.6 I hope (gregkh has the patch in his queue). new openct will work even without /proc/bus/usb and CONFIG_USB_DEVICEFS. it can also be used via hald instead of udev, if that is preferred (opensuse / udev / sysfs developers do that and recommend it - but might not be practical for small servers with minimal software). if you find time, please update to openct 0.6.13. if you prefer to stick with udev for now, you shouldn't need to change anything. Thanks! Regards, Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433341: openct: new upstream release
openct 0.6.12 was released a few days ago, it would be nice if you could update the package. svn was frozen a few days ago, tar.gz only released this monday. special note: you might want to try the new openct.udev.modalias alternativ udev rules file, it should work as well, and avoid a number of kernel/sysfs regressions. also opensc, libp11, engine_pkcs11 and pam_p11 was updated. sorry to cause so much work. :) Regards, Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414715: openct: FTBFS: Parse errors in ifdhandler.h
ok, thanks everyone. I opened a bug in the openct bug tracker to track the issue too, it is bug #25. Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337317: seeing this problem (or something very similar) with 0.6.11-1
Daniel Kahn Gillmor wrote: hrm. /dev/bus/usb appears to be created/managed by udev entirely, but /proc/bus/usb is exported (as an empty directory) by the kernel, and then usbfs is mounted on top of that. mounting usbfs should no longer be necessary. since debian added udev with /dev/bus/usb they should have checked and modified all usb applications to use that instead of /proc/bus/usb. [0 [EMAIL PROTECTED] ~]# rmdir /proc/bus/usb rmdir: /proc/bus/usb: Operation not permitted thats ok, you can't remove it. udev will start two processes, one tries the /dev/bus/usb device, one tries the /proc/bus/usb device, and the one who can claim the interface wins. i can see why that would be a problem. i'm just not sure what to do about it. Maybe this bug should be reassigned to udev or initscripts? check if the policy has something about usb devices. if not it could be best to start discussing that - like agreeing on a migration path away from /proc/bus/usb (which is called obsolete by greg kh IIRC), and maybe also touching the topic of the duplicate events and how to suppress them - that can be done either central in udev or individually in each package. with /proc/bus/usb unmounted, i'm still getting two ifdhandlers, but with slightly different messages than before: Dec 13 16:37:56 squeak ifdhandler[14736]: Unable to open USB device /proc/bus/usb/002/032: No such file or directory Dec 13 16:37:56 squeak ifdhandler[14736]: usb:/proc/bus/usb/002/032: initialization failed (driver egate) Dec 13 16:37:56 squeak ifdhandler[14736]: unable to open reader egate usb /proc/bus/usb/002/032 this is ok. since /proc/bus/usb does not exist, the kernel or udev shouldn't throw an event for it. whether this is a bug or not should be discussed with kernel and udev teams. was there still a reader running after this? I'm asking because I'm quite confused. if there was one running then this: Dec 13 16:37:56 squeak ifdhandler[14728]: Unable to open USB device /dev/usbdev2.32_ep00: No such device or address Dec 13 16:37:56 squeak ifdhandler[14728]: usb:/dev/usbdev2.32_ep00: initialization failed (driver egate) Dec 13 16:37:56 squeak ifdhandler[14728]: unable to open reader egate usb /dev/usbdev2.32_ep00 indicates a third event and a third ifdhandler was launched. end point devices? when did they get added? are we breaking compatibility once more? I was nice all year, why is santa claus bringing compatibility issues / api change / new problems for xmas? I haven't fiddled with /lib/udev/openct_usb yet. might be necessary. if you want to hack it, that would be the fastest way to get towards a solution. but the clean way is to get some statement from udev and kernel folks and agree on a policy, and get everyone agree on a best practice. udev adding changes without telling everyone involved is not really a nice way. (and it would have be easy for anyone to have a look which packages contain udev rules files and let those maintainers know.) hrm. i still don't know why udev should be spawning two ifdhandler processes if /proc/bus/usb is unmounted. in my opinion a udev or kernel bug. but the openct_usb script could do a test -e $DEVICE before running openct-control. still I think that is a work around and it is better to fix udev or kernel, but others might disagree. If that's not OK, maybe this should be reassigned to udev. But if that is deemed acceptable, maybe the bug should be with the initscripts package, for including an /etc/init.d/mountkernfs.sh which mounts /proc/bus/usb even on systems which have /dev/bus/usb already? udev added /dev/bus/usb at least half a year ago. I wonder why noone triggered a policy process and came up with a migration plan. IMO /proc/bus/usb is obsolete, and distributions should simply drop it (and fix all packages to use /dev/bus/usb instead). but I guess noone stepped forward to coordinate the process, and thus nothing happened? no idea, after all I don't know what the udev and kernel folks are up to. best is to have a chat with them about what their plans are and how they see it. would be sad if they put the burdon of handling everything on the applications. you could add checks to openct_usb to ignore events if the file does not exist, and to filter out those end point events. but still if the default etch installation has both /dev/bus/usb and /proc/bus/usb you will get two events and two ifdhandler and which one succeeds will be random. except if you filter one out hard again (e.g. ignore all /proc events). but that is somehow a hack I think, not a clean solution. if test -n $DEVICE then if ! test -e $DEVICE then exit 0 fi if echo $DEVICE |grep -q _ep then exit 0 fi if echo $DEVICE |grep -q /proc then exit 0 fi fi if test -n $DEVNAME then if ! test -e $DEVNAME then exit 0 fi if
Bug#337317: seeing this problem (or something very similar) with 0.6.11-1
If you have both /dev/bus/usb and /proc/bus/usb that is a bug in your system config and can trigger this. udev will start two processes, one tries the /dev/bus/usb device, one tries the /proc/bus/usb device, and the one who can claim the interface wins. remove either /dev/bus/usb or /proc/bus/usb or edit the openct udev script in /lib/udev to ignore requests for one of those two. but for most users it is not important at all which reader has their smart card (e.g. if you use opensc-pkcs#11 and the application simply looks at all slots), so this is a minor problem from my point of view. still for low level tools like openct-tool, opensc-took, pkcs15-init etc. you need to enter the reader number, so it might be annoying. This is an annoyance because my ssh-agent gets confused across unplug/replugs when the card changes identifiers, and i have to reload the keys for it. If i can help in debugging this at all, please let me know. true. for some reason this never happends on my machines. maybe ubuntu does something different? if you only have /dev/bus or /proc/bus but not both, and the problem still happends, then there is a big problem and we need to debug it. but for the time being I guess it is the dual /dev/bus and /proc/bus that is causing the problems. Regards, Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399682: openct: cm4000 driver fails with cm4000: setting parameters failed
please try attached patch instead.
Thanks, Andreas
diff -udrNPp --exclude=.svn openct.orig/src/ifd/pcmcia-block.c
openct/src/ifd/pcmcia-block.c
--- openct.orig/src/ifd/pcmcia-block.c 2006-04-21 08:38:04.0 +0200
+++ openct/src/ifd/pcmcia-block.c 2006-11-22 10:30:05.0 +0100
@@ -81,6 +81,17 @@ ifd_pcmcia_block_recv(ifd_device_t * dev
}
/*
+ * Set pcmcia params
+ */
+static int ifd_pcmcia_block_set_params(ifd_device_t * dev,
+ const ifd_device_params_t * params)
+{
+/* nothing to do so far */
+dev-settings = *params;
+return 0;
+}
+
+/*
* Close the device
*/
static void ifd_pcmcia_block_close(ifd_device_t * dev)
@@ -107,6 +118,7 @@ ifd_device_t *ifd_open_pcmcia_block(cons
ifd_pcmcia_block_ops.send = ifd_pcmcia_block_send;
ifd_pcmcia_block_ops.recv = ifd_pcmcia_block_recv;
+ ifd_pcmcia_block_ops.set_params = ifd_pcmcia_block_set_params;
ifd_pcmcia_block_ops.close = ifd_pcmcia_block_close;
dev = ifd_device_new(name, ifd_pcmcia_block_ops, sizeof(*dev));
diff -udrNPp --exclude=.svn openct.orig/src/ifd/pcmcia.c openct/src/ifd/pcmcia.c
--- openct.orig/src/ifd/pcmcia.c2006-04-21 08:38:04.0 +0200
+++ openct/src/ifd/pcmcia.c 2006-11-22 10:29:55.0 +0100
@@ -89,6 +89,17 @@ static int ifd_pcmcia_recv(ifd_device_t
}
/*
+ * Set pcmcia params
+ */
+static int ifd_pcmcia_set_params(ifd_device_t * dev,
+ const ifd_device_params_t * params)
+{
+ /* nothing to do so far */
+dev-settings = *params;
+ return 0;
+}
+
+/*
* Close the device
*/
static void ifd_pcmcia_close(ifd_device_t * dev)
@@ -115,6 +126,7 @@ ifd_device_t *ifd_open_pcmcia(const char
ifd_pcmcia_ops.send = ifd_pcmcia_send;
ifd_pcmcia_ops.recv = ifd_pcmcia_recv;
+ ifd_pcmcia_ops.set_params = ifd_pcmcia_set_params;
ifd_pcmcia_ops.close = ifd_pcmcia_close;
dev = ifd_device_new(name, ifd_pcmcia_ops, sizeof(*dev));
Bug#399838: documentation not include in opensc packages
Package: opensc Version: 0.11.1-2 Severity: normal please include doc/ files (html, css) in some package, so users have a documentation how to use opensc. maybe even mention QuickStart.html in the README.Debian or a proper place :) Thanks, Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399682: openct: cm4000 driver fails with cm4000: setting parameters failed
Eric Dorland wrote: Has this been discussed upstream at all? the fix is correct, but mine is nicer I think. when /proc/bus/usb got duplicated into /dev/bus/usb udev also spawned openct twice, and two ifdhanlders could try to talk to the same device, which didn't work. a glogal usb_claim_interface code did also not work fine with combo devices such as keyboard+smart card reader combo devices. so we moved the usb_claim_interface code to the usb set_param function and made sure all ifd handler set the parameter. but when I changed that, I didn't think of the cm40x0 devices, and forgot to test them, thus I broke them. one way to fix it is to undo this change, a bit nice might be to implement set_params and get_params with dummy functions that can be extended later. my proposed patch already implements set_params, will commit it for 0.6.12 with set_params, too. Regards, Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393554: Intent to NMU
Hi Eric and Dann, I released openct 0.6.10-pre1 with that patch and if noone complains it will be 0.6.10 by mid next week. this release also includes very minor fixes for bsd and patches I gathered elsewhere. it might be better to test the new version than create a nmu. if you give the new version a try, please remember to edit etc/init-script.in and uncomment the chown/chgrp lines, as those would help debian and ubuntu to make sure the permissions on /var/run/openct are always correct. Thanks, Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394610: confirming
If you replace BUS=pcmcia with BUS==pcmcia does this fix the warning? (but that might be an unrelated bug as well) i think it's actually referring to line 46 in that file (the previous line with an actual rule, which is the only SUBSYSTEM declaration in the whole file): i'm not sure why udev's line counting is off-by-one there. if it is that line, I wonder what would be wrong with it. hmm, maybe I should post the file on hotplug-devel ML asking for advise. Regards, Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337317: issue closed
I think all issues are handled in openct 0.6.9, so please test, report any problem. unless there are new confirmations of the bug, I think it can be closed. Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337317: openct: ifdhandler unable to use the egate device
maybe you have /proc/bus/usb AND /dev/bus/usb? then two ifdhandler would be spawned, and of course only one can claim the interface. or do you have pcscd installed and an egate driver? then two drivers would be trying to use the same resource. please insert the token again and run pidof / ps to see what else is running, and use lsof to see if anything is using the device already. thanks, Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#357536: please install openct.reader.conf
please don't. or only install a file that is commented out and needs to be changed. there are two problems: a) two reader for the same hardware. for example if someone installs openct and libccid and the same time, both will try to use the same usb ccid reader, and that would cause problems. b) two ways to opensc. opensc supports both openct directly as well as pcsc and ct-api interfaces, and thus also pcsc with openct as ifdhandler. however if opensc sees the same card/reader once directly and once via pcsc, it might get confused as well. in theory proper locking should prevent issues, in practice I'm not sure. I think I already saw bug reports from confused users. (and seeing the same hardware twice in opensc-tool -l is confusing). so I'd be very careful about enabling everything by default. Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337317: Processed: Re: Processed: Reassign #337317 to libusb
Am Montag, 9. Januar 2006 23:38 schrieb Aurelien Jarno: but has to use it? I think that is wrong. noone forces you. sure, using the different directories would allow people to use acl, which is not possible on usbfs. Has to use it, because /proc/bus/usb is not usable anymore if the permissions are wrong. I already received dozen of mails when udev stopped to changes the permissions of /proc/bus/usb in favor of /dev/bus/usb. wouldn't it be better to fix it and set permissions on both, if both exist? forcing people to upgrade is a very bad idea, and often not possible at all. Note that you can use ACL on /dev/bus/usb, not on /proc/bus/usb. I know. openct runs as root, so neither matters to us. also I wonder: are all ioctl available, if you have write access to the device? I thought ioctl's might be sometimes limited to root, but I'm not sure about that. As said in my previous mail, %03d is now used with newer versions of udev. good. thanks. It's not my fault if openct uses some fields incorrectly. Note also that the problem has been fixed. well, libusb exposes the field, so users are allowed to use it. chageing the content from one version to another is hardly the users fault. That would be a good idea, but I don't want to diverge from other distributions with an incompatible library. Please note that upstream is currently writting libusb version 1.0.0, which will be ABI and API incompatible, but will have a lot of new features. Maybe you can ask upstream about that. ok, will try once more. since when did /proc/bus/usb did have permissions? For a long time they were handled via hotplug. ah. hmm, I didn't know you could chown or chmod that files at all. maybe that was added later? IIRC the first usbdevfs couldn't do that, but I might be wrong. It's not because your application don't need to handle permissions that you should ignore them. Most of the applications that use libusb are using the permissions. well, I use the device. all I need is to open() and ioctl() and poll(). So I can ignore the permissions very well, as I don't touch the devices in any other way. and the services offered by my apps (ifdhandler) are restricted by the scard group already, so I think that is fine. libusb uses /dev/bus/usb as first, and /proc/bus/usb as fallback. This is necessary because contrary to you, the vast majority of users do care about permissions of their usb devices. Therefore dirname and filename are using the name in /dev/bus/usb, which are now the same as /proc/bus/usb, so that openct is now *working correctly*. ok, thanks. Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337317: Processed: Re: Processed: Reassign #337317 to libusb
Am Montag, 9. Januar 2006 09:02 schrieb Eric Dorland: Aurelian, Could you comment as to whether this is libusb breakage or not? the bug was closed. I still think it was in libusb, but can't find anything in the source. as an alternative the kernel might have been patched with some crap and thus malfunctioned. but as noone can reproduce the problem, and I didn't get any new bug reports either, we can keep it closed. if you can reproduce the problem however (run strace openct-control init, if ifdhandler is run with /proc/bus/usb/X/Y instead of /proc/bus/usb/XXX/YYY you found the problem), please let me know. the claim that it was the kernel fault is not true, in as far as the vanilla kernel has been working or me and many other people very well and doesn't cause any problem. the claim that we need to handle two namespaces is wrong: openct uses and depends on usbfs mounted on /proc/bus/usb and I haven't heard that anyone will obsolete that interface. till today kernel-user space api has been very stable, so I hope usb will be no exception, so I hope we can count on the /proc/bus/usb/XXX/YYY namespace for a several more years, i.e. wait till the new namespace has been settled down (I guess they changed it at least once times in the meantime), and has been deployed to all current systems, so we can realy count on it being available. the claim that we could use usb_open() is simply not true: libusb has no select() / poll() interface as far as I know. neither does it understand the strings given to us by the linux kernel, hotplug, udev, hald, freebsd usbd or devd or the similar mechanisms on other operating systems, I'd be happy to use libusb and dump our native code. but so far it looks like it would be a lot easier to dump libusb and write everything ourself, than to use libusb. requests to add the features we need to libusb have been unsuccessful. as far as I know the design principle is to only offer what all plattforms offer, and that is a very limited subset, mostly because of apple mac os X and its very, very different api. Regards, Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337317: Processed: Re: Processed: Reassign #337317 to libusb
Am Montag, 9. Januar 2006 14:15 schrieb Aurelien Jarno: Well you're right, it's not the kernel, but rather one of the kernel tools (udev) that uses the new functionalities of the recent kernels, and that is now using /dev/bus/usb as default instead of /proc/bus/usb. Therefore libusb has to use it if it exists. my udev 079 doesn't create that tree. (ok, ububtu dapper, not debian). but has to use it? I think that is wrong. noone forces you. sure, using the different directories would allow people to use acl, which is not possible on usbfs. so, I think there are these options: a) create a flag so you can ask which system is to be used. i.e. api modification. apps not using that special flag or function will use /proc/bus/usb/ and thus be compatible. b) use either socket, but keep dirname and filename in the usbfs format, i.e. %03d. that would keep those fields in the same format that has been there all the time, and create compatibility, even if the new directories are used. c) increase the major library number, create a new api where the fields can have different names and/or different content. but make that incompatible change visible by bumping the libraries major version number, as applications like openct will break. whishlist and of course while you are at it anyway, create a function so I can get a device string for a usb device, and can get an usb device for a device string, and implement it in a way, so whatever the linux kernel, udev, hotplug or hald or freebsd usbd or devd passes to some application will be understood. on linux it should be an open() able device path, as that is what kernel / hotplug / ... passes as DEVICE argument in events. on freebsd it might be the path to the ugen0.0 device or similar, (i.e. device to the control device, as they have one device per endpoint for some strange reason), and on mac os X it might be some string in whatever format you choose, as there are no devices for usb as far as I know and thus you don't be compatible with anything. or has apple some hotplug system, too? /whishlist well, that would help a lot, and would be a good reason to encourage users to switch to a new library vesion. and with the changed library major number, we could easily detect if the old lib is presend, and use the current code, or if the new lib is present and use new, different code. but changeing the library in a way it breaks applications without any chance to detect that at compile time, that is wrong. please don't do that. The obsoleting has started. Please look at udev (which now replaces and removes the hotplug package), it only handle the permissions of /dev/bus/usb and not the one of /proc/bus/usb anymore. since when did /proc/bus/usb did have permissions? anyway, I don't need them as openct runs as root. (at least for a long time, only root could do those ioctl()s we used, so there was no point in using a different user. and we have a nice security system by splitting in a server/client part anyway, and could even enhance that with chroot() or whatever, if people want that). I see, I didn't know that openct needs such things. However the problem is that openct assumes that dirname and filename correspond to the string to put after /proc/bus/usb/ to get the usb device, which is false. They correspond to the real directory and to the real filename used. well, the documentation doesn't exactly tell anything about that detail, and it has been that way for ever. so if you change it know, you are breaking a de facto standard, even if the documenation was unclear about it so far. if you do so, please upgrade the library major revision, so people will at least see your new version is no longer compatible with the old one. different values in the same field is a no no in compatiblity. Please note however that udev (= 0.0.76-3) now behaves like the old /proc/bus/usb and use 3 digits to represent the dirname and the filename. So openct should work correctly now, maybe you should just add a conflict with udev ( 0.0.76-3). I still don't understand how whatever udev does has an effect on libusb. as far as I can see the code looked at /proc/bus/usb first, so how do you get those wrong values into the dirname and filename fields anyway? maybe I misread the code, but I couldn't see how that happends at all. as longs as /proc/bus/usb exists like it currently does, there should be no issue, right? Regards, Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337317: openct: ifdhandler doesn't find USB device
Am Freitag 04 November 2005 09:22 schrieb Jochen Schulz: execve(/etc/init.d/openct, [/etc/init.d/openct, restart], [/* 39 vars */]) = 0 [pid 14599] execve(/usr/sbin/openct-control, [/usr/sbin/openct-control, shutdown], [/* 37 vars */]) = 0 [pid 14600] execve(/bin/sleep, [sleep, 1], [/* 37 vars */]) = 0 [pid 14603] execve(/usr/sbin/openct-control, [/usr/sbin/openct-control, init], [/* 37 vars */]) = 0 [pid 14604] execve(/usr/sbin/ifdhandler, [/usr/sbin/ifdhandler, -H, egate, /proc/bus/usb/1/5], [/* 37 vars */]) = 0 thanks, that clearly shows openct-control hands the wrong parameter to ifdhandler. ~# dpkg -l | grep libusb ii libusb-0.1-4 0.1.10a-22 userspace USB programming library that must be unstable or testing, on my debian sarge server I have an older version. the linux code in openct uses: snprintf(device, sizeof(device), /proc/bus/usb/%s/%s, bus-dirname, dev-filename); to set the file name. so most likely your libusb is broken. if you can confirm that, please report it to libusb, but keep me cc:'ed. Hm, don't know. Please prod me in the right direction. :) we need to reassign this bug: old versions of libusb return as filename and dirname the filename and dirname in /proc/bus/usb/ so that is fine. the new version returns a string with the same integer, but not with the proper formatting, so it is a libusb API breakage, and I think it was not intended to break openct and other applications. Regards, Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337317: openct: ifdhandler doesn't find USB device
could you please run strace -f /etc/init.d/openct restart 21 |grep execve and let me know of the result? I installed debian openct 0.6.6-1 packages a minute ago, did that and the result is: execve(/etc/init.d/openct, [/etc/init.d/openct, restart], [/* 32 vars */]) = 0 [pid 23576] execve(/usr/sbin/openct-control, [/usr/sbin/openct-control, shutdown], [/* 31 vars */]) = 0 [pid 23577] execve(/bin/sleep, [sleep, 1], [/* 31 vars */]) = 0 [pid 23578] execve(/usr/sbin/openct-control, [/usr/sbin/openct-control, init], [/* 31 vars */]) = 0 [pid 23579] execve(/usr/sbin/ifdhandler, [/usr/sbin/ifdhandler, -H, egate, /proc/bus/usb/001/002], [/* 31 vars */]) = 0 i.e. everything is fine. please also show me ldd /usr/sbin/openct-control, and dpkg -l |grep libusb (maybe you have a strange libusb version). the linux code in openct uses: snprintf(device, sizeof(device), /proc/bus/usb/%s/%s, bus-dirname, dev-filename); to set the file name. so most likely your libusb is broken. if you can confirm that, please report it to libusb, but keep me cc:'ed. Regards, Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334870: More info needed
Am Mittwoch 26 Oktober 2005 08:51 schrieb Christian Perrier: I'm afraid I'm missing the point in your bug report. it is quite simple: you are violating the GPL. it clearly states: appropriately publish on each copy an appropriate copyright notice copyright notice is that line with the (C). take a look at the source, you will find it (idealy) in every single file. there is a name in that line. that person is the author/copyright holder. you need to copypaste that line to the copyright file. you need three parts in the copyright file: - copyright notice - you failed to provide that one. - disclaimer of warranties - not needed per se, but the GPL requires you to include it (publish on each copy ... and disclaimer of warranty). - license only the last part can be replaced by linking to the license as you did. you missed the first two parts and thus violated GPL. for goods sake: they wrote the code. the least you can do is make sure the documentation has their names in it. that is the basic human respect for other peoples work. ...which is common practice for all GPL licensed Debian packages so that copyright files do not reproduce the GPL everywhere and, worse, do not keep outdated versions of the GPL license text. so please duplicate this bug for every single one of them. you can link to the license, but you MUST reproduce the copyright notice and the disclaimer of warranties, if you don't you violate the GPL. In the above file, everything you request is mentioned. no, it does not have the copyright notice, and the disclaimer of warranties is not something optional you can link to /refer to. it must be published in every copy. every copy. not only that package with the GPL license, but every copy, and that includes every package with GPL software. hey, it is only four lines: This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. and you can remove the first half of the first sentence and the last sentence but the rest needs to stay, or you are violating the GPL. So, I actually really wonder what you want us to do. If this is please include the full text of the GPL in /usr/share/odc/login/copyright, then the answer is *no*. copy all lines with (C) in them (remove duplicates) and copy the disclaimer of warranties. take a look at the GPL file, they have an example of what to do: ... To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the copyright line and a pointer to where the full notice is found. one line to give the program's name and a brief idea of what it does. Copyright (C) year name of author This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA so if you copy the descriptions and (C) lines and then once the second and third paragraph (make sure they are all the same, some people remove the or any later part, for example the linux kernel!). the last paragraph can be replaced by pointing to the /usr/share/common-licensed/GPL file. the first three need to stay, and the program name and copyright holder name and year etc. form the copyright notice, so the GPL requires you to reproduce them in the binary package, too. Regards, Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334870: copyright file lacks author
Package: login Version: 1:4.0.3-31sarge5 Severity: normal from the copyright file: Source file src/su.c contains a chunk of code cribbed from the GNU su.c, which is covered by the GNU General Public License: On Debian GNU/Linux systems, the complete text of the GNU General Public License can be found in '/usr/share/common-licenses/GPL' The GPL states: 1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program. an appropriate copyright notice includes the name of the copyright holder. So pleae add it. usualy you can simply cutpaste all those (C) or (c) or copyright line. disclaimer of warranty is also needed, usualy you need to copy this block: This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA only the last paragraph can be replaced, the rest is required. IT IS important to check whether the source uses or omites the , or ... any later version. part, so please quote that. Thank you for respecting copyrighted work and the license terms of the GPL. Regards, Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327269: still problems
On Sunday 25 September 2005 15:26, Adam Conrad wrote: Can you test the packages at http://people.debian.org/~adconrad/apache2-security/ for me? They should fix /a/ bug with SSLVerifyClient and PROPFIND, but I can't be positive if they'll fix YOUR bug without testing. Hi Adam, thanks for your work, those packages work fine, bug fixed. Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327269: still problems
btw, I tried --no-auth-cache and it does not help at all. any other idea? Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327269: apache2 security update breaks ssl+svn
Hi Adam, Could you try, for curiosity's sake, setting SSLVerifyClient none in the main VirtualHost, and keeping the rest the same, and seeing if that makes a difference for you at all? Done, no change at all. Thanks for looking into this issue. Regards, Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327269: apache2 security update breaks ssl+svn
On Friday 09 September 2005 10:58, R. Mattes wrote: After reading the initial bug report I checked with my upgraded SVN servers (no client certs involved). Fresh checkouts seem to work flawless but checkouts from user accounts that had allready checked out from the server hang. Doing a 'svn co --no-auth-cache' from these accounts seems to have fixed the problem (i.e. afterwards checkouts work even without the '--no-auth-cache' option). Maybe there's a problem with SVNs cert cache? I had tried something similar: I had deleted the .subversion/auth/ directory, but it didn't help. I can try that option tomorrow, but I guess it won't help either. Regards, Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327269: apache2 security update breaks ssl+svn
Package: apache2 Version: 2.0.54-5 Severity: critical After upgrading 2.0.54-4 to 2.0.54-5 svn+ssl is broken: subversion client (e.g. checkout): svn: PROPFIND request failed on '/svn/test' svn: PROPFIND of '/svn/test': Could not read status line: SSL error: sslv3 alert unexpected message (https://www.opensc.org) apache error log: [Thu Sep 08 20:47:39 2005] [error] Re-negotiation handshake failed: Not accepted by client!? downgrade to 2.0.54-4 and everything is fine again. debian gnu linux / sarge / kernel 2.6.11.11 vanilla, i386, apache2 on 80 and 443, ssl with self signed certificate, accepting a list of self signed certificates, svn repository needs those for write access only. more configuration and any detail you need available on request. Regards, Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#258626: bug in openct, closed in 0.6.3/4
Hi, that should be an openct bug :-) anway, openct = 0.6.3 should have fixed this, please confirm and then close the bug Thanks, Andreas -- -[ Ciphire Signature ]-- From: [EMAIL PROTECTED] signed email body (113 characters) Date: on 29 April 2005 at 16:31:31 UTC To: [EMAIL PROTECTED] : Ciphire has secured this email against identity theft. : Free download at www.ciphire.com. The garbled lines : below are the sender's verifiable digital signature. 00fAEAAABjYXJCcQAAAGYCAAIAAgACACCFlIVZ9h6KxvOWMDarP70UatGMqs u0GuBSJ7VpCrEAhwEAXFjiekCd8DXx05lJ0kX8quFhoCB61nfVM/+P+sXKh70LMm 3SdKbK3hOuHhK3+VtlHsLmVewgpmUpFOqxO/ffzw== --[ End Ciphire Signed Message ] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295244: bacula looks for wrong pid file
Package: bacula-fd,bacula-sd,bacula-director-common Version: 1.36.1-1 Severity: normal here is a suggestion to make bacula init scripts more flexible. bacula allows the location of the pid file to be configured, so the init script should be able to cope with it. all init scripts have something like: PIDFILE=/var/run/bacula/$NAME.$PORT.pid as far as I know pid files should be in /var/run/ without a subdir. but to be flexible, you could grep the config file for Pid.*Directory (ignore case) and use that directory instead of the hard coded /var/run/bacula/ Thanks, Andreas -- -[ Ciphire Signature ]-- From: [EMAIL PROTECTED] signed email body (491 characters) Date: on 14 February 2005 at 17:24:02 UTC To: [EMAIL PROTECTED] : Ciphire has secured this email against identity theft. : Free download at www.ciphire.com. The garbled lines : below are the sender's verifiable digital signature. 00fAEAAACy3hBC6wEAAEsDAAIAAgACACCFlK4A+54we7zwPJsjFBflkYBMj+ KIfUWI8cEb4zJitwEAjuLZDHPnOxRgKfQyXaVwrQqQB78iLphbN7mW+8mUnEFYp8 OOX8KGmL9Xf5C4eeTU11bBDGuvJo6nyJZWxL1Hjg== --[ End Ciphire Signed Message ] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
