Message-Id: <1080252636.2543.18.camel@simulacron>
Date: Thu, 25 Mar 2004 23:10:37 +0100
From: Andreas Jellinghaus <email address hidden>
To: Colin Watson <email address hidden>, <email address hidden>
Cc: Alessandro Razeto <email address hidden>, <email address hidden>
Subject: Re: Bug#240077: ssh: why not to compile with opensc?

> Wouldn't that produce a binary package that depends on libopensc0,
> thereby requiring everyone with ssh to install that library?

yes, and opensc is compiled to use either openct or pcsc-lite
(has a library package, too) or both. and opensc is usualy linked
against openssl.

so yes, the result might be considered big and fat.

in comparison, microsoft has it's crypto api with the
cryptografic service provider, which is a nice design.
step by step the unix collection of grown libraries
is improved towards a similar architecture.

the whole situation is made worse by the fact, there
are many different projects implementing a similiar
set of functions, for example the many crypto libraries
out there, or openssl, gnutls and other library offering
tls (libnss is there at least, maybe others?).

and there is the plan of every project to support everything,
for example opensc not only supports pcsc-lite so ifdhandler
format drivers can be used, it also has build in support for
ct-api format drivers, it had for a while an internal framework
for usb tokens, which was replaced by the new openct driver
and middleware that opensc supports, too.

also while opensc currently uses openssl (but can be compiled
without at reduced functionality), there are aims to be able
to use gnutls as well, but to my knowledge gnutls has a long
way to go for offering the same features that openssl has.
and opensc not only uses openssl, but also has two libraries,
so called engines, that openssl can use to access smart
cards.

and don't forget nss, which cannot be used by opensc so far,
but nss can use any library implementing the pkcs#11 interface,
and opensc is implementing that.

if all that double and tripple functionality isn't enough,
opensc supports quite a number of smart cards, and is
gaining support for new ones step by step. each smart
card (operating system) is incompatible to each other,
so these (opensc internal) drivers are necesssary.

confused? I'm sorry. Let's go back to openssh.

While it would be utterly cool to have opensc support
in debian, I already expectet that you don't want it,
because of the many libraries.

But could you create a second package with opensc support
and maintain both? the differences are:
 - one configure flage: --with-opensc
 - one build dependency in the control: libopensc-dev
   (which results in several build and runtime library
   dependencies)
 - one patch (for ssh to ask for the pin openssh needs
   a redesign of some part, which markus (openssh developer)
   didn't find time so far to do. out patch is not that ugly,
   but not the clean design they like to have either. it does
   not touch anything outside the smart card related code.)

everything else is the same, not even changes in documentation,
config files, or debconf questions or anything. so three
simple changes, that's why it might be easier for you
to maintain two openssh versions in parallel.

Thanks for your attention.

Regards, Andreas Jellinghaus
(opensc & openct developer :-)