Re: New port in MacPorts and question about TokenD

On Tue, 2016-09-27 at 20:55 +0200, Leonardo Brondani Schenkel wrote:
> The port as it is now does not build the TokenD, though. This is what
> I want to introduce next and that's the reason why I'm posting. Since
> TokenD needs the OpenSC sources when building, I would like to know
> how exact must be the match between the OpenSC sources that were used
> by TokenD and the sources used to build the version of libopensc that
> is available at runtime. This will determine if TokenD can be a
> separate opensc-tokend port which is installable on its own (but
> dependent on opensc) or it will be a new "+tokend" variant of the
> opensc port (variants in MacPorts are like USE flags in Gentoo that
> can be used to turn on/off features when building packages).
> 
> I strongly suspect that they must be built together or you risk
> running into a world of pain when a libopensc gets upgraded and you
> have a TokenD built against and older version (or vice-versa), but it
> does not harm to ask the list.

Well... the OpenSC project installs a shared library for libopensc, and
a libopensc.pc pkg-config file to let external things build against it.
If the ABI of that library changes in an incompatible way without the
soname being bumped, then we are Doing It Wrong™.

That said, lots of projects Do It Wrong, and I don't blame you for
asking :)


On Wed, 2016-09-28 at 06:34 +0000, Martin Paljak wrote:
> The reason for calling libopensc a "deprecated library" is only to 
> encourage developers to build against "proper interfaces" like 
> PKCS#11 or some platform-specific interface, not to make it 
> impossible to build a component-based OpenSC.

Do we call it a 'deprecated library'? That still doesn't mean we get to
break shared library ABI rules, does it?

And in this case, I believe Tokend *is* the "proper" platform-specific
interface for OSX, just as the minidriver is the proper platform-
specific interface for Windows.

So if we *aren't* painstakingly following shared library ABI rules for
libopensc, and Leonardo's concerns are valid... then maybe
Tokend.OpenSC should be part of the OpenSC repository, like the Windows
minidriver is.

Or a third possibility: what's wrong with just using a Tokend.PKCS#11
such as the one mentioned at
http://ludovicrousseau.blogspot.co.uk/2010/04/free-software-tokend-above-pkcs11-for.html

Then you can use it with *any* PKCS#11 module, including OpenSC's. Why
have a hardware-specific Tokend implementation at all?

-- 
dwmw2

------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensc-devel