[MIR] ccid opensc pcsc-lite

[Seth Arnold]

==> ccid <==
[Availability]
ccid is in universe, and builds on all architectures.

[Rationale]
The desktop team and security team are interested in bringing smartcard
authentication to enterprise desktop environments.

[Security]
No CVEs for ccid are listed in our database.
Doesn't appear to bind to a socket.
No privileged executables, but does have udev rules.
Probably needs a security review.

[Quality assurance]
No test suite.
Does require odd hardware that we'll probably need to buy.
I don't see debconf questions.
ccid is well maintained in Debian by upstream author.
One open wishlist bug in BTS, harmless.

One open bug in launchpad, not security, but looks very frustrating
for the users. The upstream author was engaged but it never reached
resolution. https://bugs.launchpad.net/ubuntu/+source/ccid/+bug/1175465

Has a debian/watch file.
Quilt packaging.

P: ccid source: no-dep5-copyright
P: ccid source: package-uses-experimental-debhelper-compat-version 13

[Dependencies]
Minimal dependencies, in main

[Standards compliance]
Appears to satisfy FHS and Debian policy

[Maintenance]
The desktop team will subscribe to bugs, however it is expected that the
security team will assist with security-relevant questions.

[Background information]
ccid provides drivers to interact with usb-connected smart card readers.

==> libpam-pkcs11 <==
[Availability]
Source package pam-pkcs11 is in universe and builds on all architectures.

[Rationale]
The desktop team and security team are interested in bringing smartcard
authentication to enterprise desktop environments.

[Security]
No CVEs in our database.
Doesn't appear to bind to sockets.
No privileged executables (but is a PAM module).
As a PAM module this will require a security review.

[Quality assurance]
The package does not call pam-auth-update in its postinst #1650366
Does not ask questions during install.
One Ubuntu bug claims very poor behaviour if a card isn't plugged in.
No Debian bugs.
Occasional updates in Debian by long-term maintainer.
Does require odd hardware that we'll probably need to buy.
Does not appear to run tests during build.
Has scary warnings in the build logs.
Has a debian/watch file.

Ancient standards version; other smaller lintian messages, mostly
documentation problems.

Quilt packaging.

[Dependencies]
Depends on libcurl4, libldap-2.4-2, libpam0g, libpcsclite1, libssl1.1
All are in main.

[Standards compliance]
The package does not call pam-auth-update in its postinst #1650366
Otherwise looks to conform to FHS and Debian policies

[Maintenance]
The desktop team will subscribe to bugs, however it is expected that the
security team will assist with security-relevant questions.

[Background information]
This PAM module can use CRLs and full-chain verification of certificates.
It can also do LDAP, AD, and Kerberos username mapping.

==> libpcsc-perl <==
[Availability]
Source package pcsc-perl is in universe, builds for all architectures,
plus i386

[Rationale]
The desktop team and security team are interested in bringing smartcard
authentication to enterprise desktop environments.

[Security]
There are no cves for pcsc-perl in our database.
No privileged executables.
Doesn't appear to bind to sockets.
Probably needs a security review.

[Quality assurance]
Library package not intended to be used directly.
No debconf questions.
No bugs in Debian.
No bugs in Ubuntu.
Does require odd hardware that we'll probably need to buy.
Tests exist, not run during the build; probably can't run during the build.
Includes debian/watch file.
A handful of lintian issues
Quilt packaging.

[Dependencies]
libpcsc-perl depends upon libpcsclite1, libc6, perl, perlapi-5.30.0.
All are in main.

[Standards compliance]
One oddity, Card.pod is stored in /usr/lib/x86_64-linux-gnu/perl5/5.30/Chipcard/PCSC/
Many other perl packages have .pod files in these directory trees so maybe
it's fine, but it seems funny all the same.

Otherwise appears to satisfy FHS and Debian policy.

[Maintenance]
The desktop team will subscribe to bugs, however it is expected that the
security team will assist with security-relevant questions.

[Background information]
Dependency of pcsc-tools; this library provides an API to work with smart
cards and card readers.

==> opensc <==
[Availability]
Both opensc and opensc-pkcs11
In universe, builds for all architectures.

[Rationale]
The desktop team and security team are interested in bringing smartcard
authentication to enterprise desktop environments.

[Security]
26 CVEs in our database. None open in groovy.
No privileged executables.
Does not appear to bind to sockets.
Probably needs a security review.

[Quality assurance]
Unknown configuration effort.
No debconf questions.
Several recent Ubuntu bugs ask for updates to newer versions for bugfixes.
A recent Debian bug reports a FTBFS, includes a fix, and has been ignored
for months.
Does require odd hardware that we'll probably need to buy.
Includes a test suite, most of which is skipped; unknown quality, looks
like a bit more than usual smoke testing.
Includes a debian/watch file.
Handful of small lintian warnings.
Quilt packaging.

[Dependencies]
Recommends: pcscd from universe

[Standards compliance]
Appears to follow FHS, Debian policy.

[Maintenance]
The desktop team will subscribe to bugs, however it is expected that the
security team will assist with security-relevant questions.

[Background information]
Provides a pkcs#11 library for interacting with many models of smartcards.

==> pcsc-tools <==
[Availability]
Built in groovy for all architectures

[Rationale]
The desktop team and security team are interested in bringing smartcard
authentication to enterprise desktop environments.

[Security]
No CVEs in our database for pcsc-tools.
Doesn't appear to bind to sockets.
No privileged executables.
Probably needs a security review.

[Quality assurance]
It looks like it works out of the box.
No debconf questions.
One bug in Ubuntu, it doesn't make much sense.
No bugs in Debian.
Looks to be regularly updated in Debian.
Does require odd hardware that we'll probably need to buy.
Doesn't look like it includes a test suite.
Includes a debian/watch file.
Very short lintian --pedantic output.
Quilt packaging.

[Dependencies]
Depends upon libpcsclite1, libpcsc-perl, libgtk3-perl.
libpcsc-perl is in universe.

[Standards compliance]
Appears to adhere to FHS, Debian policy.

[Maintenance]
The desktop team will subscribe to bugs, however it is expected that the
security team will assist with security-relevant questions.

[Background information]
This package provides general utilities for smartcards; it's possible that
we do not strictly need this package for our use case.

==> libpcsclite1 <==
[Availability]
pcsc-lite is in universe, and builds on all architectures.

[Rationale]
The desktop team and security team are interested in bringing smartcard
authentication to enterprise desktop environments.

[Security]
Five CVEs for pcsc-lite are listed in our database.
Doesn't appear to bind to a socket.
No executables, only a library.
Probably needs a security review.

[Quality assurance]
There is a testpcsc.c file that is compiled but I don't know how to use it
for tests.
Does require odd hardware that we'll probably need to buy.
I don't see debconf questions.
pcsc-lite is well maintained in Debian by upstream author.
There are a handful of open bugs in Debian, the author was very repsonsive
on the hndful I inspected, it looks like some cases of misunderstood
capabilities, cases of conflicting requirements, etc. Nothing looked
concerning:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=pcsc-lite

The most recent Ubuntu bugs are due to (a) 14.04 systemd problems (b)
errors from drivers assigned to the wrong package (c) probably due to use
of insserv rather than plain systemd:
https://bugs.launchpad.net/ubuntu/+source/pcsc-lite/+bugs?orderby=-id&start=0
Nothing looked concerning.

Has a debian/watch file.
Quilt packaging.

P: pcsc-lite source: no-dep5-copyright
P: pcsc-lite source: package-uses-experimental-debhelper-compat-version 13

[Dependencies]
libpcsclite1 depends upon libc6.

[Standards compliance]
Appears to satisfy FHS and Debian policy

[Maintenance]
The desktop team will subscribe to bugs, however it is expected that the
security team will assist with security-relevant questions.

[Background information]
libpcsclite1 provides windows smart-card API to interact with smart card
readers.

[Ludovic Rousseau (ludovic-rousseau-gmail)]

I am happy to see interest in smart cards from Ubuntu. if you need help you can contact me.

I like your comment: "Does require odd hardware that we'll probably need to buy."
If you want to support smart cards then, yes, you will have to buy some smart cards and smart card readers :-)

[Christian Ehrhardt  (paelzer)]

The MIR bug 250245 for libpcsclite1 was a bit trivial back then, I think since this now requires also pcscd for the recommends from opensc we should add it to this overall MIR to re-process it under todays terms.

@sarnold - would you mind doing the initial checks for pcsc-lite as well and add them to the description?

[Seth Arnold (seth-arnold)]

Done, thanks Christian!

[Christian Ehrhardt  (paelzer)]

[Summary]
From the MIR POV the package is mostly ok. The overall topic of smartcard
usage will need some QA testing to be supportable. Only a bit can be done
in autopkgtest due to the special HW requirements but it would be worth to
try that as well as setting up a test lab with the most common respective HW.

This does need a security review, so I'll assign ubuntu-security

Binaries to promote: libccid

TODOs:

Recommended:
- Tests:
  - Special HW - In general and I guess this is true for all packages here.
    Canonical should get a set of the common (=the want to be supported) devices
    and document those somewhere to make it clear what is regularly tested /
    supported vs what is on "hopefully it works" level.
  - Also please try at least if with vsmartcard-vpicc + vsmartcard-vpcd some
    autopkgtest time testing could be added to some of these packages.
    (I'm not going to repeat this request on all reviews, but overall it is
    important for QA on such a new topic.)
- Add symbols tracking (this is a bit vice versa, it is a lib providing a driver
  to be used in ps/sc, but still auto-detect if things change is good)

Required:
- Please subscribe to the package (usually good to be done now already)

[Duplication]
libccid is used to communicate though PC/SC (also on this MIR) with smart cards.
https://wiki.debian.org/Smartcards holds a nice overview, there are a bunch
of special drivers in other packages (not part of this MIR), but ccid covers
the majority of devices listed.

[Dependencies]
OK:
- no other Dependencies to MIR due to this (libc6, libusb-1.0-0)
- no -dev/-debug/-doc packages that need exclusion

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking

[Security]
OK:
- history of CVEs does not look concerning
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not open a port
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop

Problems:
- does parse data formats
  The ccid protocol - if ever exploited - would be a very great angle of attack
- does deal with system authentication (eg, pam), etc)
  Smartcards can and commonly are used to do auth
- This will need a security review on top of the MIR review

[Common blockers]
OK:
- does not FTBFS currently
- no translation present, but none needed for this case (user visible)?
- not a python/go package, no extra constraints to consider int hat regard

Problems:
- does have a test suite that runs at build time
  - test suite fails will fail the build upon error.
- does have a test suite that runs as autopkgtest
=> Tests of special HW are hard at build time anyway, but a bit more than
nothing would be great. I suggested an overall test with a set of
meant to be supported cards exercising all the components of this MIR.

- The package has a team bug subscriber
This needs a Team subscriber still, Desktop was mentioned to be that, but it
isn't yet. From experience this is easy to be forgotten later. Also subscribing
now will help to see the influx of bugs on the topic and therefore help to be
sure if you want t...

[Christian Ehrhardt  (paelzer)]

[Summary]
This package needs some cleanup for better tests, symbols tracking and things
like lintian/dh_missing. No show stoppers thou, MIR Team kind-of-Ack under the
condition to try to improve these weak spots before promotion.
Please report here what has been done for that and summarize the new and
improved state of warnings and bugs to reduce concerns to get the final MIR Ack.

While the above isn't a full Ack yet it isn't too bad either. We don't have to
wait and block on it atm, this does needs a security review, so I'll assign
ubuntu-security now already.
Secuity manages MIR reviews via the subscription, to reflect that work is needed
in any case I'll set the state to incomplete also.

To be promoted to main: opensc + opensc-pkcs11

Required TODOs:
- some testing for the overall topic of smartcard usage as outlined in
  the ccid review
- subscribe a team to the bug (better now than later)
- plenty of libs, some seem internal, but still - please add symbols tracking
  where applicable to detect incompatibilities early
- check and resolve dh_missing
- too many crash bugs left, please do a bug squash and help to improve quality.
  Also see the suggestions below of "splitting the package" and "defined set
  of supported cards" to make this more manageable
Recommended TODOs:
- The tests at build time skip 3/4 subtests. Please evaluate if that can be
  improved.
- This package consists of many small tools, supporting (and thereby testing,
  recreating issues, ...) all of them can be hard. For supportability and
  install footprint it could be useful to check all these binaries and split
  some of them into an -extra package that will not be promoted.

[Duplication]
PKCS#15 card support providing PKCS#11 to the upper layers is the core piece
of opensc, this is the only SW doing that in the archive - no duplication.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
- no -dev/-debug/-doc packages that need exclusion

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking

[Security]
OK:
- history of CVEs does not look concerning (many CVEs), but under control
  (all closed)
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not open a port
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop

Problems:
- does parse data formats (from/to cards pkcs#15 and from/to higher layers
  pkcs#11)
- does deal with system authentication (eg, pam), etc)
  pam-pkcs#11 is directly involved with auth
=> It will need a security review

[Common blockers]
OK:
- does not FTBFS currently
- does have a test suite that runs at build time
  - test suite fails will fail the build upon error.
- no translation present, but none needed for this case (user visible)?
- not a python/go package, no extra constraints to consider in that regard
- no new python2 dependency

Problems:
- the self tests it has at build time are mostly skipped
- does have a test suite that runs as autopkgtest
  (as discussed in ccid)
- The package has a team bug subscriber
  Do it early please!

[Packaging red flags]
OK...

[Christian Ehrhardt  (paelzer)]

[Summary]
This looks mostly ok from a MIR POV, I've listed remaining that would
help to get this improved below. Those are rather minor, MIR Ack under the
condition to have them handled. Please update the bug once you have done so.

Specific binary packages to be promoted to main: libpam-pkcs11

Required TODOs:
- some testing for the overall context of smartcard usage as outlined in
  the ccid review
- please look into the odd file path of the pam .so file if that is ok
- please subscribe the team to the bug right away (too easy to be missed
  later and gives a preview about the bug influx)
Recommended TODOs:
- n/a

[Duplication]
In addition to opensc-pkcs11 this seems like "the same". But while opensc-pkcs11
is about providing pkcs#11 for pkcs#15 cards this lib here libpam-pkcs11 is a
subproject to opensc - there are pam_p11 (simpler) and pam-pkcs#11 (this one).
This lib here is about integrating pkcs#11 into pam with extended features
like name mapping and cert chain verification.
See
- https://github.com/OpenSC/OpenSC/wiki#sub-projects
- https://github.com/OpenSC/pam_pkcs11
=> Despite the name similarity duplication isn't an issue here

[Dependencies]
OK:
- no other Dependencies to MIR due to this
- no -dev/-debug/-doc packages that need exclusion

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking

[Security]
OK:
- history of CVEs does not look concerning
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not parse data formats
- does not open a port
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop

Problems:
- does deal with system authentication (eg, pam), etc)
=> This needs an security evaluation

[Common blockers]
OK:
- does not FTBFS currently
- no translation present, but none needed for this case (user visible)?
- not a python/go package, no extra constraints to consider int hat regard

Problems:
- does have a test suite that runs at build time
- does have a test suite that runs as autopkgtest
  (I have mentioned the overall testing before, applies here as well.
- The package has a team bug subscriber

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking is not in place (but this is only a pam plugin)
- d/watch is present and looks ok
- Upstream update history is slow (but gladly seems only to be
  stable updates)
- Debian/Ubuntu update history is sporadic (e.g. 2 year gap)
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package
- no massive Lintian warnings
- d/rules is rather clean
- Does not have Built-Using

Problems:
- the shared objects have odd pathing
  /lib/pam_pkcs11/ldap_mapper.so
  /lib/pam_pkcs11/opensc_mapper.so
  /lib/pam_pkcs11/openssh_mapper.so
  /lib/security/pam_pkcs11.so
  While everything else pam'y is in /lib/x86_64-linux-gnu/security/
  Does this have x86 only limitations (or a multiarch violation) we need
  to solve?

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (as far as I can check...

[Christian Ehrhardt  (paelzer)]

I asked about it in comment #2 already.
pcsc-lite was MIRed in bug 250245 but pcscd explcitly excluded.
One either needs to:
1. step up and say "yes we want to own it" (in that case please add a request to the description)
2. say this isn't needed for what you want to achieve (Essentially providing a Windows(R) SCard interfce - which chances are you won't need).

In the case of #2 please modify "opensc" in Ubuntu to reduce the "Recommends" dependency on pcscd to just a "Suggests".
Marking the task as incomplete and not doing a full review on pcscd until really requested.

[Christian Ehrhardt  (paelzer)]

While looking at pcsc-tools and pcscs-perl (only needed for the dependency from pcscs-tools) I have found that these are not really depended on by anything important.

This matches the statement in the request that says:
"This package provides general utilities for smartcards; it's possible that we do not strictly need this package for our use case."

Use case wise it contains:
- /usr/bin/ATR_analysis
  Tool to analyze the raw ATR answer from a smart card - debugging tool at best and
  no common use case
- /usr/bin/scriptor + /usr/bin/gscriptor
  Send scripts to a smartcard, that might be a developer or debugging feature but doesn't sound
  an end user thing for the enterprise desktop you have in mind.
- /usr/bin/pcsc_scan
  This is the one end-user useful tool in this toolset showing the available cards that are
  inserted. But honestly you want to integrate things in an enterprise desktop and there I'd
  expect a UI-thing for it and not this cmdline tool. At the same time nothing in gnome or
  anywhere else related depends on it.

IMHO we should not promote packages to main we have no real use and integration of.

If there is a good case how this plays a role in the envisioned "Enterprise Desktop smartcard integration" then I'm more than happy to review and process this (in that case also say why/why-not pcscd is important - see above).

MIR Team Nack to pcsc-tools and pcscs-perl for the (currently) given dependencies and reasoning.

[Christian Ehrhardt  (paelzer)]

assigning pcsc-lite back to sarnold for the decision if you really need/want it for "pcscd" or not.

[Joy Latten (j-latten)]

Hi Seth and Christian,

I did a smartcard setup and confirmed I did not have to use anything from pcsc-tools. And pcsc-tools seem to depend on libpcsc-perl, so won't need pcsc-perl either.

My "sudo apt install opensc" pulled in libccid, libpcslite1, opensc-pkcs11 and pcscd binary packages. I only needed one additional install of "libpam-pkcs11".

Next, I am looking into the pcscd requirement. Will comment shortly.

[Joy Latten (j-latten)]

pcscd is required. When removed, I am not able to get any info from the driver about the reader or the smartcard. pcscd loads the smartcard driver and coordinates communications.

[Joy Latten (j-latten)]

pcsc-lite source package provides pcscd and libpcsclite1 and thus is needed for smartcard deployment.

[Christian Ehrhardt  (paelzer)]

## pcsc-lite ##

[Summary]
Mir Team ACK under the condition that the required TODOs are resolved.
While the owning Team should look at that security can already start
a review.

This does need a security review, so I'll assign ubuntu-security

list specific binary packages to be promoted to main: pcscd, libpcsclite1

Clarifications:
- @Seth - the filing is done as if one would only need libpcsclite1 but Joy
  said in comment #12 that pcscd is also needed.
  Could you clarify which is true as the security risk increases if we add
  the daemon as well.
  For now I'll go on as if the daemon would be part of it.

Required TODOs:
- The package has no team bug subscriber - please fix
- Please look into open bugs and crashes before we promote.
  Do a bug-scrub and ensure we know what is outdated and no more true
  and what else is still an issue. This can be seen as preview to the
  latter maintenance - so don't skip all of them due to "don't have
  the HW" :-)

[Duplication]
There is no other package in main providing the same functionality.
Note: Joy checked if the other bits can do it without but it is required.
See comment #12.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
- one -dev package that will be auto-promoted but no bad deps from there

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking

[Security]
OK:
- history of CVEs does not look too concerning
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop

Problems:
- does parse data formats
- does open a port
- does deal with system authentication (eg, pam), etc)

This needs a security review, before doing so please clarify if the daemon
pcscsd is part of the scope.

[Common blockers]
OK:
- does not FTBFS currently
- no translation present, but none needed for this case (user visible)?
- not a python/go package, no extra constraints to consider int hat regard

Problems:
- does not have a test suite that runs at build time
- does not have a test suite that runs as autopkgtest
  We have talked about tests before, no reason to re-iterate
- The package has no team bug subscriber - please fix

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking is in place
- d/watch is present and looks ok
- Upstream update history is good
- Debian/Ubuntu update history is good
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package
- no massive Lintian warnings
- d/rules is rather clean
- Does not have Built-Using

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (as far as I can check it)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no use of user nobody
- no use of setuid
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-*
- no embedded source copies
- not part of the UI for extra checks

[Christian Ehrhardt  (paelzer)]

Sorry, I forgot to update one section for pcsc-lite on packaging:

- important open bugs (crashers, etc) in Debian or Ubuntu

There are quite some:
https://bugs.launchpad.net/ubuntu/+source/pcsc-lite/+bugs?field.searchtext=crash&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=&orderby=-date_last_updated&start=0

Also this one should be fixed or at least checked
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930530

I have already had that in my overall summary, just the details were missing.

[Seth Arnold (seth-arnold)]

ubuntu-security is now subscribed to pcsc-lite bugs.

Thanks

[Seth Arnold (seth-arnold)]

Christian, Joy has gone through the bugs and either closed old ones or made some progress on still-relevant ones. How does it look to you now? Thanks Joy!

Thanks

[Christian Ehrhardt  (paelzer)]

Hi Seth and Joy,
I see you cleared the list a lot - awesome!
You have subscribed and pinged the remaining ones which is a reasonable approach as most might be no more real issues as of today.

I'm ok for the Ubuntu side of the pcsc-lite bugs now, what still needs to be addressed is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930530

[Marco Trevisan (Treviño) (3v1n0)]

Hi,

Related to the desktop team specific needs, I wanted to mention that at the current state we don't expect to need or support pam-pkcs11 given that we want to rely only on pam-sss (that should be at this time more than enough for any need), other than being already in main.

So, while in debian [1] (and ubuntu) I've added both profiles for pam-sss and pam-pkcs11 the latter is mainly untested and not default (can be seleceted with update-alternatives in case).

Said this, if there are not other requirements for it, I'd consider it safe to be dropped from the MIR list from our POV.

Regarding pcscd, however... I think we need it.
I've done my testing with limited hardware here (mostly my national healthcare card) but that's only supported by opensc-pkcs11 IF pcscd is installed.

So I've the feeling we can't downgrade pcscd to a simple suggestion in most of the cases.

[1] https://salsa.debian.org/gnome-team/gdm/-/tree/debian/master/debian

[Seth Arnold (seth-arnold)]

Thanks Marco, I'll take pam-pkcs11 off our todo list. (This can be reversed, of course. If it turns out to be necessary for something, someone shout. :)

Thanks

[Sebastien Bacher (seb128)]

Updating the title, hopefully it reflects correctly what needs to be promoted.

@Marco, the binaries we want installed are those 'libpam-sss opensc-pkcs11 pcscd' right?

libpam-sss is already in main and pcscd depends on libccid which also needs promotion as a result

[Sebastien Bacher (seb128)]

@opensc

* the dh_missing has been reported to Debian now, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987817

* the launchpad buglist has been triaged a bit and fixed issues closed

* the libraries are private (no .so provided, other softwares can't really build with it), ideally they would move it to a subdir but do we really need .symbols added in such cases?

[Christian Ehrhardt  (paelzer)]

Thank you Marco and Sebastien,

> * the launchpad buglist has been triaged a bit and fixed issues closed

Thanks!
From your bug cleanup did you spot any kind of setup/HW that you want to restrict/exclude?
Was there any common pattern that makes up most of the formerly seen bad reports?

> * the dh_missing has been reported to Debian now, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987817

Yeah, I think that is enough for now.

> the libraries are private (no .so provided, other softwares can't really build with it), ideally they would move it to a subdir but do we really need .symbols added in such cases?

I agree this is a case where it is a tough decision if it is strictly required due to them being "meant" private.
But I'd not agree that there are no .so files provided.

root@h:~# dpkg -L opensc opensc-pkcs11 | grep '\.so'
/usr/lib/x86_64-linux-gnu/libopensc.so.7.0.0
/usr/lib/x86_64-linux-gnu/libsmm-local.so.7.0.0
/usr/lib/x86_64-linux-gnu/onepin-opensc-pkcs11.so
/usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
/usr/lib/x86_64-linux-gnu/pkcs11-spy.so
/usr/lib/x86_64-linux-gnu/libopensc.so.7
/usr/lib/x86_64-linux-gnu/libsmm-local.so.7
/usr/lib/x86_64-linux-gnu/pkcs11/onepin-opensc-pkcs11.so
/usr/lib/x86_64-linux-gnu/pkcs11/opensc-pkcs11.so
/usr/lib/x86_64-linux-gnu/pkcs11/pkcs11-spy.so

$ nm --dynamic $(dpkg -L opensc-pkcs11 | grep '\.so' | xargs) | pastebinit
https://paste.ubuntu.com/p/7SpfQ5gW26/

So there are in theory symbols, but I agree it still is not really usable (or meant to be used).
As there are for example no headers for it :-)

And OTOH adding symbols files is a rather trivial task that protects against some bad breakage.
So is it strictly mandatory: hmm, debatable ... I guess no.
I'd say as prereq add symbols OR move to subdir - of which the latter is the much more useful and correct thing to do. And as there are no other users you won't have to touch any other package for that change.

[Ludovic Rousseau (ludovic-rousseau-gmail)]

opensc-pkcs11.so is a PKCS#11 lib so the its API conforms to the standard defined in https://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/pkcs11-base-v2.40-os.html

If you are looking for .h header files you can use:
https://www.oasis-open.org/committees/document.php?document_id=55655&wg_abbrev=pkcs11
https://www.oasis-open.org/committees/document.php?document_id=55656&wg_abbrev=pkcs11
https://www.oasis-open.org/committees/document.php?document_id=55657&wg_abbrev=pkcs11

pkcs11-spy.so is a spy/debug library. It uses the same API.

A PKCS#11 library is, in general, dynamically loaded using dlopen(3). So the dependency is not visible from an application using the library (for example Firefox).

If you really need to move opensc-pkcs11.so & pkcs11-spy.so in a subdir I would recommand to use /usr/lib/*/pkcs11/ as it is already the case.

[Christian Ehrhardt  (paelzer)]

On Mon, May 3, 2021 at 10:20 AM Ludovic Rousseau
<email address hidden> wrote:
>
> opensc-pkcs11.so is a PKCS#11 lib so the its API conforms to the
> standard defined in https://docs.oasis-
> open.org/pkcs11/pkcs11-base/v2.40/os/pkcs11-base-v2.40-os.html

Thanks Ludovic for adding the expert details!
And that makes me re-consider this to "yes we should add .symbols".

> If you really need to move opensc-pkcs11.so & pkcs11-spy.so in a subdir
> I would recommand to use /usr/lib/*/pkcs11/ as it is already the case.

Well, since there are external users it will be much harder to move things.
As they all need to be compatible (or adapted) to the new place.
Still worth having a look to move them, but more complex and more
potential impact than what I expected before your explanation.

[Seth Arnold (seth-arnold)]

Now that the security team has some new hires, we're looking at reviving this series of tasks. Looking through the bug I have come up with the following outstanding items:

- Add a .symbols file to opensc
- try to add vsmartcard-vpicc + vsmartcard-vpcd autopkgtests
- a formal list of 'supported cards' that we will test with and expect to work
- try to address the awkward path of libraries, /lib/pam_pkcs11/
- make pcscd not run as root https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930530

Did I overlook anything?

Thanks

[Marco Trevisan (Treviño) (3v1n0)]

The plan seems quite solid, and I do agree that having some more testing would be nice (also using libsofthsm2 can help here I think).

I'm not sure if all this can be achieved by the next LTS though, which I think we're targetting.

[Sebastien Bacher (seb128)]

I've reported the lack of symbols to Debian on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997932 with a patch now

[Sebastien Bacher (seb128)]

Triaging to Medium, we would still like to see that stack installed by default but it's not going to be for the coming LTS at this point.

[Mark Esler (eslerm)]

Desktop no longer has engineering goals to support smart cards. Foundations team might.

Security Team is blocked until there is a mandate, an owning team, hardware funding, and possibly engineering support to resolve https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930530

Unassigning Security Team.

[Lukas Märdian (slyon)]

Foundations doesn't have any aspirations of driving this forward currently. So we'll let it sit here for now.

[Christian Ehrhardt  (paelzer)]

There has been not further update for too long, for now we consider it invalid.
Feel free to re-open if there is effort backing it up and motivation to bring it to main.