ebuild für pcsc-lite

[schmidicom]

Im Zuge der Thematik aus dem Thread GnuPG und Smartcard (Nitrokey) habe ich mich mal hingesetzt und versucht für das Package "sys-apps/pcsc-lite" ein aktuelleres ebuild zu erstellen das ich hier, zwecks einer eventuellen Diskussion, verlinken möchte:
https://github.com/schmidicom/schmidico ... /pcsc-lite

Was hier gemacht wurde:

• * Umstellung auf das neue meson basierte buildsystem.
  * Erweiterte Trennung von openrc und systemd.

Hier noch das ChangeLog von der Quelle: https://salsa.debian.org/rousseau/PCSC/ ... /ChangeLog

[firefly]

Ich hab lokal das gleiche gemacht wobei die basis war das aktuelle ebuild nur auf meson umgestellt.
In meinem falle wurde durch ein hardcoded path in der meson konfiguration ein file, das als "documentation" behandelt wird, in /usr/share/doc/pcsc-lite installiert obwohl der pfad eigendlich /usr/share/doc/pcsc-lite-<version> lauten sollte.
Das hat auch portage als QA warnung ausgegeben.

Hierfür hab ich ein patch welcher die meson konfiguration anpasst damit man das docdir via parameter angeben kann ähnlich dem usbdropdir parameter.
Zusätzlich fügt der patch einen parameter hinzu mit der optional die doku gebaut wird (useflag doc im aktuellen ebuild in portage)

[schmidicom]

Ich vermute mal du meinst die Datei "/usr/share/doc/pcsc-lite/setup_spy.sh.bz2"?

Was mich am ebuild im Repo von Gentoo besonders gestört hat war die udev Regel.
Das in der Regel hinterlegte Service-Unit macht einfach keinen Sinn, weder für jene die OpenRC noch für jene die systemd benutzen. Unter OpenRC gibt es kein Service-Unit das an dieser Stelle gestartet werden könnte und unter systemd gibt es das Socket-Unit welches dafür sorgt das der Dienst bei Bedarf gestartet wird und das ausgeführte Shell-Script ist unter systemd auch nutzlos.

Und was ich bei meinem ebuild halt auch gerne noch optional eingebaut hätte wäre der Support für User-Units, aber da hat der Programmierer einen kleinen Fehler gemacht was dem ganzen noch im Weg steht.
Das von pcscd genutzte Unix-Socket ist mit samt Pfad "hardcoded" was dazu führen würde das auf einem System wo sich mehrere Benutzer gleichzeitig anmelden die einzelnen Instanzen von pcscd versuchen würden alle das selbe Unix-Socket zu verwenden, was nicht funktionieren kann. Und die Tatsache das pcscd genau wie scdeamon versucht exklusiv auf die Devices der verfügbaren Smartcards zuzugreifen würde in einem solchen Szenario sicher ebenfalls Probleme verursachen.
Bevor der Entwickler das nicht überarbeitet wäre es fahrlässig im ebuild die User-Units zu Unterstützen.

[firefly]

Ich vermute mal du meinst die Datei "/usr/share/doc/pcsc-lite/setup_spy.sh.bz2"?

ja die meine ich

Was mich am ebuild im Repo von Gentoo besonders gestört hat war die udev Regel.
Das in der Regel hinterlegte Service-Unit macht einfach keinen Sinn, weder für jene die OpenRC noch für jene die systemd benutzen. Unter OpenRC gibt es kein Service-Unit das an dieser Stelle gestartet werden könnte und unter systemd gibt es das Socket-Unit welches dafür sorgt das der Dienst bei Bedarf gestartet wird und das ausgeführte Shell-Script ist unter systemd auch nutzlos.

Das file macht schon so "sinn" da es "generisch" ist. z.b. das shell script hat nen check ob es unter openrc läuft oder nicht und macht gar nichts wenn es nicht unter openrc läuft.
Und der andere part setzt nur eine env variable, das macht dann im kontext von openrc auch nichts da diese ENV variable systemd spezifisch ist.

Dadurch hast du nur eine regel, die im kontext von openrc und von systemd funktioniert.
Wobei man natürlich darüber diskutieren kann, ob das starten des services via udev rule im kontext von systemd noch sinvoll ist da es die socket activation systemd unit gibt.

Eine system user unit ergibt nur sinn, wenn man pcscd dann nur auf ein spezifisches gerät fest pinnt (Was AFAIK sogar geht via filter?). Denn nur so können mehrere user, welcher unterschiedliche devices nutzen, ihre eigene instanz haben.
Aber dann müsste man dem system irgendwie mitteilen können welche devices zu welchen user "gehören".
Was aber wieder zu Problemen führen kann, falls Benutzer A dann doch mal sein device im kontext des Benutzers B nutzen muss/möchte.

[schmidicom]

Ich vermute mal du meinst die Datei "/usr/share/doc/pcsc-lite/setup_spy.sh.bz2"?

ja die meine ich

Kannst du da mal dein Repo verlinken? Würde mir den Patch, so aus neugier, gerne mal ansehen.

Was mich am ebuild im Repo von Gentoo besonders gestört hat war die udev Regel.
Das in der Regel hinterlegte Service-Unit macht einfach keinen Sinn, weder für jene die OpenRC noch für jene die systemd benutzen. Unter OpenRC gibt es kein Service-Unit das an dieser Stelle gestartet werden könnte und unter systemd gibt es das Socket-Unit welches dafür sorgt das der Dienst bei Bedarf gestartet wird und das ausgeführte Shell-Script ist unter systemd auch nutzlos.

Das file macht schon so "sinn" da es "generisch" ist. z.b. das shell script hat nen check ob es unter openrc läuft oder nicht und macht gar nichts wenn es nicht unter openrc läuft.
Und der andere part setzt nur eine env variable, das macht dann im kontext von openrc auch nichts da diese ENV variable systemd spezifisch ist.

Dadurch hast du nur eine regel, die im kontext von openrc und von systemd funktioniert.
Wobei man natürlich darüber diskutieren kann, ob das starten des services via udev rule im kontext von systemd noch sinvoll ist da es die socket activation systemd unit gibt.

Das Script führt zwar einen Check durch, aber trotzdem wird es bei jedem Start des Systems und jedesmal wenn eine Smartcard angeschlossen wird zusammen mit seinem Interpreter (was in den meisten fällen die Bash sein dürfte) ausgeführt und das ist über das ebuild (in Fällen wo es das nicht braucht) mit wenig Aufwand vermeidbar. Das ganze Ding ist auf Installationen mit systemd auch eine unnötige Fehlerquelle die vermieden werden kann und auch vermieden werden sollte.
Hier mal eine Liste an möglichen Szenarien die mir dazu so spontan einfällt:

• * Was passiert wenn das Verzeichnis "/run/openrc" auf einem Gentoo mit systemd, aus welchen Gründen auch immer, doch vorhanden ist?
  * Was ist wenn das Shebang "/bin/sh" nicht mehr funktioniert weil durch merged-usr eventuell der Pfad nicht mehr gültig ist?
  * Was ist wenn "sh" auf eine andere Shell verlinkt wurde die eventuell mit der Syntax nicht klar kommt?

Ich sehe hier keinen Grund warum nicht zwei verschiedene, auf den jeweiligen Fall optimierte, udev-Regeln bereit stellen sollte. Und das könnte auch auch von den Gentoo-Devs noch einfacher gemacht werden wenn die eclass udev eine Funktion bekommen würde mit der man solche Regeln nicht nur installieren sondern auch direkt aus dem ebuild heraus erstellen könnte (ähnlich wie die Funktion "make_desktop_entry" aus der eclass desktop).

Und ja das starten von "pcscd.service", über eine udev-Regel, unter einem Gentoo mit systemd ist halt wirklich komplett sinn frei weil das Service-Unit mit dem Socket-Unit verknüpft ist. Bedeutet folgendes: Wenn das Service-Unit auf diese Weise gestartet wird wird auch das Socket-Unit gestartet und wenn der Dienst dann von niemanden verwendet wird wird das Service-Unit wieder automatisch beendet. Ein potenzieller Leerlauf...
Das einzige was an dieser Stelle eventuell Sinn machen würde wäre das Socket-Unit über die udev-Regel zu starten, aber auch das sollte eigentlich der Entscheidung desjenigen überlassen werden der/die für das jeweilige System verantwortlich ist. Bei anderen Packages wird das auch so gemacht und dann im Wiki erwähnt das man nach der Installation eventuell mit "systemctl" noch das Socket-Unit aktivieren sollte.

Eine system user unit ergibt nur sinn, wenn man pcscd dann nur auf ein spezifisches gerät fest pinnt (Was AFAIK sogar geht via filter?). Denn nur so können mehrere user, welcher unterschiedliche devices nutzen, ihre eigene instanz haben.
Aber dann müsste man dem system irgendwie mitteilen können welche devices zu welchen user "gehören".
Was aber wieder zu Problemen führen kann, falls Benutzer A dann doch mal sein device im kontext des Benutzers B nutzen muss/möchte.

Das verwenden von pcscd als User-Server ist aktuell halt einfach keine gute Idee aber auch nichts was ich jetzt unbedingt haben müsste. Es ist halt nur so das bei einem Blick in die "meson.options"-Datei zu vermuten ist das der Entwickler diese Variante bevorzugt. Nur bin ich halt der Meinung das die Software dafür noch nicht bereit ist.

[firefly]

Ich vermute mal du meinst die Datei "/usr/share/doc/pcsc-lite/setup_spy.sh.bz2"?

ja die meine ich

Kannst du da mal dein Repo verlinken? Würde mir den Patch, so aus neugier, gerne mal ansehen.

Kann ich nicht da ich das nur komplett lokal habe. Kann es aber hier rein posten (ist nicht viel)

diff -ur pcsc-lite-2.2.3.orig/meson.build pcsc-lite-2.2.3/meson.build
--- pcsc-lite-2.2.3.orig/meson.build 2024-05-26 17:08:15.000000000 +0200
+++ pcsc-lite-2.2.3/meson.build 2024-06-16 17:43:05.599867439 +0200
@@ -29,6 +29,7 @@
'sbindir_exp' : sbindir,
'PCSCLITE_CONFIG_DIR' : get_option('serialconfdir'),
'usbdropdir' : get_option('usbdropdir'),
+ 'docdir' : get_option('docdir'),
})

# tests for functions
@@ -201,7 +202,7 @@
install_dir : get_option('bindir'))

install_data('src/spy/setup_spy.sh',
- install_dir : 'share/doc/pcsc-lite')
+ install_dir : get_option('docdir'))

run_command('pod2man',
['--date=2024-01-01', 'src/spy/pcsc-spy.pod', 'pcsc-spy.1'],
@@ -286,6 +287,7 @@
description : 'PC/SC smart card interface')

# generate documentation
+if get_option('documentation')
configure_file(output : 'doxygen.conf',
input : 'doc/doxygen.conf.in',
configuration : confgen_data)
@@ -296,3 +298,4 @@
else
warning('Documentation disabled without doxygen')
endif
+endif
diff -ur pcsc-lite-2.2.3.orig/meson.options pcsc-lite-2.2.3/meson.options
--- pcsc-lite-2.2.3.orig/meson.options 2024-05-26 17:08:15.000000000 +0200
+++ pcsc-lite-2.2.3/meson.options 2024-06-16 17:37:32.479542112 +0200
@@ -53,3 +53,13 @@
type : 'boolean',
value : 'true',
description : 'reader filtering using PCSCLITE_FILTER_IGNORE_READER_NAMES and PCSCLITE_FILTER_EXTEND_READER_NAMES')
+
+option('documentation',
+ type : 'boolean',
+ value : 'true',
+ description : 'build documentation or not')
+
+option('docdir',
+ type : 'string',
+ value : 'share/doc/pcsc-lite',
+ description : 'Direcrory for documentation')

Und ja das starten von "pcscd.service", über eine udev-Regel, unter einem Gentoo mit systemd ist halt wirklich komplett sinn frei weil das Service-Unit mit dem Socket-Unit verknüpft ist.

Das stimmt wobei bei default beide units nicht aktiv sind nach der installation.
Eventuell war das der grund wieso der Ersteller des ebuilds diese udev regel so erstellt hat.
Oder es gab zu dem zeitpunkt wo das erste ebuild erstellt wurde, die socket activation unit noch nicht. Und man hat diese Änderung später nicht genutzt um die udev regel anzupassen
Denn der systemd support kam erst mit der version 1.8.0 hinzu. (2011)

[schmidicom]

ja die meine ich

Kannst du da mal dein Repo verlinken? Würde mir den Patch, so aus neugier, gerne mal ansehen.

Kann ich nicht da ich das nur komplett lokal habe. Kann es aber hier rein posten (ist nicht viel)

diff -ur pcsc-lite-2.2.3.orig/meson.build pcsc-lite-2.2.3/meson.build
--- pcsc-lite-2.2.3.orig/meson.build 2024-05-26 17:08:15.000000000 +0200
+++ pcsc-lite-2.2.3/meson.build 2024-06-16 17:43:05.599867439 +0200
@@ -29,6 +29,7 @@
'sbindir_exp' : sbindir,
'PCSCLITE_CONFIG_DIR' : get_option('serialconfdir'),
'usbdropdir' : get_option('usbdropdir'),
+ 'docdir' : get_option('docdir'),
})

# tests for functions
@@ -201,7 +202,7 @@
install_dir : get_option('bindir'))

install_data('src/spy/setup_spy.sh',
- install_dir : 'share/doc/pcsc-lite')
+ install_dir : get_option('docdir'))

run_command('pod2man',
['--date=2024-01-01', 'src/spy/pcsc-spy.pod', 'pcsc-spy.1'],
@@ -286,6 +287,7 @@
description : 'PC/SC smart card interface')

# generate documentation
+if get_option('documentation')
configure_file(output : 'doxygen.conf',
input : 'doc/doxygen.conf.in',
configuration : confgen_data)
@@ -296,3 +298,4 @@
else
warning('Documentation disabled without doxygen')
endif
+endif
diff -ur pcsc-lite-2.2.3.orig/meson.options pcsc-lite-2.2.3/meson.options
--- pcsc-lite-2.2.3.orig/meson.options 2024-05-26 17:08:15.000000000 +0200
+++ pcsc-lite-2.2.3/meson.options 2024-06-16 17:37:32.479542112 +0200
@@ -53,3 +53,13 @@
type : 'boolean',
value : 'true',
description : 'reader filtering using PCSCLITE_FILTER_IGNORE_READER_NAMES and PCSCLITE_FILTER_EXTEND_READER_NAMES')
+
+option('documentation',
+ type : 'boolean',
+ value : 'true',
+ description : 'build documentation or not')
+
+option('docdir',
+ type : 'string',
+ value : 'share/doc/pcsc-lite',
+ description : 'Direcrory for documentation')

Schöner Patch.
Hast du schon mit dem Gedanken gespielt den Upstream einzureichen?

Und ja das starten von "pcscd.service", über eine udev-Regel, unter einem Gentoo mit systemd ist halt wirklich komplett sinn frei weil das Service-Unit mit dem Socket-Unit verknüpft ist.

Das stimmt wobei bei default beide units nicht aktiv sind nach der installation.
Eventuell war das der grund wieso der Ersteller des ebuilds diese udev regel so erstellt hat.
Oder es gab zu dem zeitpunkt wo das erste ebuild erstellt wurde, die socket activation unit noch nicht. Und man hat diese Änderung später nicht genutzt um die udev regel anzupassen
Denn der systemd support kam erst mit der version 1.8.0 hinzu. (2011)

Kann schon sein, habe nicht versucht zurückzuverfolgen wann das rein kam.
Ich finde es halt einfach grundsätzlich daneben so etwas in einer udev-Regel zu verstecken, und ja das ist versteckt weil dieser Autostart weder mit "systemctl" (systemd) noch mit "rc-service" (OpenRC) angezeigt wird.

Hinzu kommt das es irgendwo auch ein bisschen heuchlerisch ist.
Einerseits bekomme ich in diversen Foren immer wieder zu lesen wie systemd für seinen "automagischen Scheiss" (nicht meine Wortwahl, das wird stellenweise genau so geschrieben) kritisiert wird und man deshalb die Finger von diesem angeblichen "Teufelszeug" lassen sollte und anderseits geht man dann hin und bastelt sich über eine udev-Regel (was ja selbst aus dem systemd-Projekt kommt) einen versteckten Autostart zusammen.

Ehrlicher wäre es wenn die udev-Regel in beiden Fällen so aussehen würde:

Code: Select all

ENV{ID_SMARTCARD_READER}=="1", GROUP="pcscd"

Und es dann entweder im Wiki oder über emerge den Hinweis gäbe, das man sich unter OpenRC wegen der fehlenden HOTPLUG-Funktionalität halt selber darum kümmern muss das der Dienst aktiviert ist wenn man diesen benutzen möchte.