Menu
▾
▴
opensc-devel
|
From: Leonardo B. S. <leo...@gm...> - 2016-09-27 18:56:39
|
Hello all, I have recently submitted a port for OpenSC in MacPorts: https://trac.macports.org/ticket/52372 The port has been accepted and I volunteered to be the maintainer. I'm a long time user of both OpenSC and MacPorts, so I hope that this port will be useful for other Mac smartcard users — maybe some of them members of this very list. 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. I already have a successful build of TokenD built via MacPorts on my machine, so the outcome of this discussion will determine how I'm going to submit this work to MacPorts. Any suggestions on the matter are greatly appreciated. Thank you, Leonardo. |
|
From: Martin P. <ma...@ma...> - 2016-09-28 06:34:37
|
Hello, It better be +tokend in this wording. Think of OpenSC.tokend like out-of-tree PKCS#11 or Minidriver interface of OpenSC. It could also be bundled inside OpenSC code tree as well (but is not, for historical reasons). For some reason (IMHO) it feels like MacPorts is more about things that don't integrate with OSX that deeply (unlike the standard .pkg/.dmg interface) and thus only to provide PKCS#11 and command line tools by default. But it could also be a separate package. 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. Best, Martin On Tue, 27 Sep 2016 at 21:57 Leonardo Brondani Schenkel < leo...@gm...> wrote: > Hello all, > > I have recently submitted a port for OpenSC in MacPorts: > https://trac.macports.org/ticket/52372 > > The port has been accepted and I volunteered to be the maintainer. I'm > a long time user of both OpenSC and MacPorts, so I hope that this port > will be useful for other Mac smartcard users — maybe some of them > members of this very list. > > 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. > > I already have a successful build of TokenD built via MacPorts on my > machine, so the outcome of this discussion will determine how I'm > going to submit this work to MacPorts. Any suggestions on the matter > are greatly appreciated. > > Thank you, > Leonardo. > > > ------------------------------------------------------------------------------ > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > |
|
From: David W. <dw...@in...> - 2016-09-28 08:56:48
Attachments:
smime.p7s
|
Replying to this separately as it's a bit of a digression, but still related... On Wed, 2016-09-28 at 06:34 +0000, Martin Paljak wrote: > For some reason (IMHO) it feels like MacPorts is more about things > that don't integrate with OSX that deeply (unlike the standard > .pkg/.dmg interface) and thus only to provide PKCS#11 and command > line tools by default. OK, so how *should* this work. Let's take the specific example of OpenConnect, my VPN client. I try to make sure it works for everyone — on Linux platforms it Just Works™ if you provide a RFC7512 PKCS#11 URI in place of a filename for a certificate/key, and on Windows there's a similar string format to identify certificates in the Windows certificate store (and the GUIs make that work nicely). OSX is... problematic. I'd love to be able to use certificates from the Keychain, but I don't know how. I was trying to help a user only last week who had a key in the Keychain and was trying to make OpenConnect work. So you're right. It doesn't integrate with OSX that deeply, and it only provides PKCS#11. That much I already knew. But how do I *fix* it? I'm aware of https://github.com/slushpupie/KeychainToken which exposes the Keychain via PKCS#11, and I could attempt to work with that, but it's basically a dead project and I understand it's not likely to work with recent versions of OSX. Although Jay has kindly said he's¹ willing to relicense if we need to import parts of that code into some other project in some form, which might be useful. Should there be an OpenSSL ENGINE and/or GnuTLS support for talking directly to the OSX Keychain? GnuTLS has that support for Windows system keys and I believe there's an OpenSSL CAPI engine somewhere. I *want* to make your statement above untrue, at least for OpenConnect. But I have *no* idea how. If KeychainToken can be made to work, perhaps that's the way forward. MacPorts can basically work like other *nix platforms and do it based on PKCS#11. On Linux we load p11-kit-proxy.so as the default PKCS#11 provider (or directly use libp11-kit to load all the right tokens). So if we configure p11-kit to indicate that KeychainToken should be loaded, then well-behaved applications would mostly Just Work. -- dwmw2 ¹ I made an assumption there because the language forced me to choose a pronoun, and I went with the most likely one. Sincere apologies if I got it wrong. |
|
From: David W. <dw...@in...> - 2016-09-28 08:34:40
Attachments:
smime.p7s
|
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 |
|
From: Leonardo B. S. <leo...@gm...> - 2016-09-28 09:29:15
|
On 2016-09-28 10:34, David Woodhouse wrote: > 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 :) Yes, I understand how shared libraries are supposed to maintain ABI/API compatibility however my question was more or less the current state of affairs and not the desirable one. :-) I suspect that even if OpenSC intends to maintain a stable ABI/API for libopensc (as expected of a shared library), inadvertent breakages won't be detected in practice due to the fact that OpenSC builds everything together and nobody tests different libopensc/TokenD version combinations. I'm also not aware of any other project that uses libopensc. The fact that the libopensc headers are declared as non-installable in the Makefile also gives a strong indication that nobody is really expecting libopensc to be used by third-parties. I just don't want to gamble and have ports that build combinations that were never really build or tested by anyone. As the maintainer in MacPorts, I'm not comfortable with making MacPorts users the guinea pigs of such combinations. > 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. Just to clarify that I'm not claiming that the API/ABI are being broken, just that I'm skeptical that any breakage would be detected since (almost) nobody uses libopensc besides TokenD and they are always built together. Honestly, maintaining a stable API/ABI can be a pain and it could be much better for everybody if TokenD was integrated into the OpenSC sources and then you don't need to care about libopensc and you're free to refactor it at will. I don't see the point of paying the price of maintaining compatibility of a library if that library has no other users. However, my intent was not to start a big discussion or make any requests or suggest changes in OpenSC — all I want to do is to have a well-behaving and stable MacPorts port. :-) > 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? I agree that the TokenD you mentioned would be a much better option than the custom OpenSC one. It could work in the same way and have the same purpose as p11-kit does in Linux. But according to Apple TokenD modules are a deprecated technology and who knows until when they are going to work. It becomes hard to justify the time investment on building something that could simply stop working on the very next OS release. // Leonardo. |
|
From: Martin P. <ma...@ma...> - 2016-09-28 08:41:48
|
On 28/09/16 11:34, David Woodhouse wrote: > Then you can use it with *any* PKCS#11 module, including OpenSC's. Why > have a hardware-specific Tokend implementation at all? In theory - yes. In practice - there is a shitload of weirdly buggy PKCS#11 modules out there and when you need to provide reliability, such wishful layering often fails to deliver. And you need to configure them and resolve conflicts and ... The other sad part about tokend is - it will be phased out. https://developer.apple.com/reference/cryptotokenkit Anyway, it seems that such "long layering" is something that is actively being worked against, with things like WebUSB being preferred by some implementers instead of going through whatever would provide access to hardware tokens (think: pkcs11-pcsc-ccid) Regards, Martin -- @martinpaljak +3725156495 |
|
From: David W. <dw...@in...> - 2016-09-28 09:12:12
Attachments:
smime.p7s
|
On Wed, 2016-09-28 at 11:41 +0300, Martin Paljak wrote: > On 28/09/16 11:34, David Woodhouse wrote: > > Then you can use it with *any* PKCS#11 module, including OpenSC's. Why > > have a hardware-specific Tokend implementation at all? > > > In theory - yes. In practice - there is a shitload of weirdly buggy > PKCS#11 modules out there and when you need to provide reliability, such > wishful layering often fails to deliver. And you need to configure them > and resolve conflicts and ... True. But for the OpenSC case we don't have to care about those other buggy PKCS#11 providers. For us to deprecate Tokend.OpenSC in favour of Tokend.PKCS#11 we *only* need the OpenSC PKCS#11 module to be working right. All those other crappy third-party modules can still be weirdly buggy, and we aren't any worse off. Those vendors are going to need to fix *their* PKCS#11 provider before *they* stop shipping their Tokend.XXXX and say "hey, do it through Tokend.PKCS#11". But that's their business. > The other sad part about tokend is - it will be phased out. > > https://developer.apple.com/reference/cryptotokenkit > > Anyway, it seems that such "long layering" is something that is actively > being worked against, with things like WebUSB being preferred by some > implementers instead of going through whatever would provide access to > hardware tokens (think: pkcs11-pcsc-ccid) Yeah, that definitely makes it more fun :) So is PCSC going to go away completely? For the Yubikey OATH support, talking directly to the YubiOATH applet on the card, I currently do it through PCSC identically (modulo Windows Unicode stupidity) on *all* platforms: http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/yubikey.c This is separate from the *crypto* key support which I only do via PKCS#11 right now (qv). Is even this going to break? -- dwmw2 |
|
From: David W. <dw...@in...> - 2016-09-28 15:08:59
Attachments:
smime.p7s
|
On Wed, 2016-09-28 at 08:28 -0600, Nathan Toone wrote: > This is completely beyond my experience and knowledge - but does > CommonCrypto (the apple-sanctioned crypto API to use instead of > OpenSSL, for example) provide what is needed? Maybe that's one option. But in addition to the "normal" TLS connection with client certificates that CommonCrypto could provide, we *also* need to support DTLS (TLS over UDP) with a pre-1.0 version of the DTLS protocol Cisco are still using. The only libraries which support *that* are OpenSSL and GnuTLS. And then only because I fixed them both to do so :) So we'd end up having to have a horrible hybrid of one crypto library for the TLS connection, and another one for DTLS. Which actually we *have* had for years but I'd *just* abolished it :) And it's also been a horribly painful experience trying to get OpenSSL and GnuTLS to Just Work™ with all the random certificates you're going to encounter in the wild. Doing it all again for CommonCrypto doesn't strike me as being a recipe for happiness, especially as I don't even have an OSX test box to hand. If somebody *really* wanted to step forward and promise to maintain a CommonCrypto back end with feature parity, I might be inclined to allow them. But I doubt it's something I'm going to embark upon myself. I think we'd be much better off adding Keychain support to GnuTLS under its "system keys" support, much as it has CAPI/CNG support on Windows. Hell, you could basically cobble this together by hacking up my existing TPM support in OpenConnect¹ and making it use the Keychain functions like SecKeyRawSign()² instead of the Trousers TSS functions. Forget the whole #ifndef HAVE_GNUTLS_CERTIFICATE_SET_KEY code block from line 40-96. Nobody cares about versions that old any more. So the tpm_sign_fn() function ends up basically just being a call to SecKeyRawSign(), and the load_tpm_key() function just needs to find the appropriate SecKey object in the (appropriate) Keychain, so it can be used later in tpm_sign_fn(). How hard can *that* be? :) cf. http://stackoverflow.com/questions/5767957/get-certificates-in-keychain But now I look into it, it looks like these Keychain APIs are the *same* as Jay's KeychainToken is using; I'm not sure it's so obsolete after all. Perhaps homebrew/MacPorts/etc. should just be shipping KeychainToken by default, enabled via a p11-kit module file, and then keys in the token would just automatically be visible to well-behaved *nix applications. -- dwmw2 ¹ http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/gnutls_tpm.c ² https://developer.apple.com/reference/security/1618025-seckeyrawsign |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X