Comment 6 for bug 1892559

[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 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