Re: [opensc-devel] llibopensc.pc is not installed
Hello, On Thu, Dec 9, 2010 at 13:47, Kalev Lember ka...@smartlink.ee wrote: On 12/07/2010 05:21 PM, Frank Morgner wrote: You're not supposed to link against libopensc via the sc_* API but use PKCS#11. It is possible but not encouraged, thus the .pc file is removed. Why is it not encouraged? The effort that would be required to have a well designed and documented public API and maintain required backwards-compatibility is not comparable to the benefits it would bring. OpenSC does not really have a public API, there's a bunch of sc_* prefixed functions that help to achieve stuff with smart cards, but it is not really consistent. OpenSC is for PKCS#15 cryptographic smart cards. So the API OpenSC should expose should only be the sc_pkcs15_* bunch of functions it actually exports? Compare it to OpenCT. OpenCT has an API (I'd say better one than libopensc) but it is not an API. I would not encourage anyone to build anything new against OpenCT unless they know what they are doing. Yet it can't be forbidden, and people DO build new things against OpenCT (embedded mostly) even if PC/SC is the preferred API because a) it is accepted as an API by many developers, on many platform b) it is designed, to some extent c) it is documented. Thus it is useful to a greater audience. Exposing a kitchen sink API is not a good idea. Building against one is not a good idea either. Code re-use (using code from OpenSC) is a different thing than claiming libopensc to be a public library, with a public API. Developers should know how to re-use code without the public library. Distributing a -dev library with a .pc file would be comparable to _asking_ people to link against libopensc, and I guess 9 times out of 10 that would not be a good choice. PKCS#11 has the same characteristics as PC/SC. While not the best or most flexible, it is the best we have. I think GnomeKeyring is one of the best examples why interoperability matters and how it can help get things done in real life. For what it's worth, we were also considering using libopensc for smart card abstraction, but in the end chose another library because the public interface to libopensc was removed in svn. Knowing the details of what you're talking about, I don't think this was a good decision for you either. The library in question (smartcardpp/smartcard++) has also no real design internally and by building your applications against it, you lock your applications out from all other devices that already have a cryptographic provides via a common cryptographic API (PKCS#11, CryptoAPI, CDSA). Switching from a C codebase to a C++ one only gives the extensibility of OOP and a C++ based clone of OpenSC, with the same problems that OpenSC has. All in all, this is an interesting discussion, and spot on with the theme of the security / hardware crypto devroom at FOSDEM, I ask you to join if possible and discuss the options with a broad community of developers. Cheers, Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] llibopensc.pc is not installed
Hi! You're not supposed to link against libopensc via the sc_* API but use PKCS#11. It is possible but not encouraged, thus the .pc file is removed. Why is it not encouraged? The effort that would be required to have a well designed and documented public API and maintain required backwards-compatibility is not comparable to the benefits it would bring. OpenSC does not really have a public API, there's a bunch of sc_* prefixed functions that help to achieve stuff with smart cards, but it is not really consistent. OpenSC is for PKCS#15 cryptographic smart cards. So the API OpenSC should expose should only be the sc_pkcs15_* bunch of functions it actually exports? Compare it to OpenCT. OpenCT has an API (I'd say better one than libopensc) but it is not an API. I would not encourage anyone to build anything new against OpenCT unless they know what they are doing. Yet it can't be forbidden, and people DO build new things against OpenCT (embedded mostly) even if PC/SC is the preferred API because a) it is accepted as an API by many developers, on many platform b) it is designed, to some extent c) it is documented. Thus it is useful to a greater audience. A good API should be the aim of good Software. If libopensc's API is broken, go fix it! API changes are no problem as long as there are not too many changes. For example, it was only this year when OpenSSL decided to provide compatibility with future releases (although the project is already 12 years old). Maybe it takes some time, but only if someone uses your software, you can discover problems. If some things are undocumented, read the source! No problem with that, too. Exposing a kitchen sink API is not a good idea. Building against one is not a good idea either. Code re-use (using code from OpenSC) is a different thing than claiming libopensc to be a public library, with a public API. Developers should know how to re-use code without the public library. Distributing a -dev library with a .pc file would be comparable to _asking_ people to link against libopensc, and I guess 9 times out of 10 that would not be a good choice. So I have three possibilities: 1. Do some magic to use libopensc nevertheless. But why should I do this if you're essentially telling me go away? I can't really expect from you to include new functionality or to adjust things, since you are only interested if it concerns OpenSC's internals. 2. Stay entirely in OpenSC and submit a patch. For me this is not an option. What I want to do is too much to be included in OpenSC. For example, I wrote a library based on libopensc to access the new German identity card (nPA). So far so good, this could be integrated into libopensc (which I once intended to do). But I need to access this functionality with standard smart card operations from a smart card reader emulator, which would pretty much require to access libopensc. 3. Use an own implementation probably duplicating code from OpenSC One job, one program! Duplicating code duplicates problems. That's why I avoided this so far. But seems like this is the only viable option. I think this makes OpenSC less usable. Less usable means less participation. I have committed several patches to OpenSC, _because_ I was using it. I cannot speak for anybody else, but with the current development you are at least loosing me. PKCS#11 has the same characteristics as PC/SC. While not the best or most flexible, it is the best we have. I think GnomeKeyring is one of the best examples why interoperability matters and how it can help get things done in real life. I don't think I understand this. What does hiding functionality have to do with interoperability? Greets, Frank. pgpzQlyahKWi8.pgp Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] llibopensc.pc is not installed
Frank Morgner wrote: You're not supposed to link against libopensc via the sc_* API but use PKCS#11. It is possible but not encouraged, Why is it not encouraged? The effort that would be required to have a well designed and documented public API and maintain required backwards-compatibility is not comparable to the benefits it would bring. OpenSC does not really have a public API, there's a bunch of sc_* prefixed functions that help to achieve stuff with smart cards, but it is not really consistent. .. A good API should be the aim of good Software. If libopensc's API is broken, go fix it! Sounds like you might be volunteering? :) Maybe it takes some time, but only if someone uses your software, you can discover problems. I guess it's a matter of optimizing for the common case; OpenSC was mostly used as a p11 so that's what is being optimized for.. So I have three possibilities: 1. Do some magic to use libopensc nevertheless. But why should I do this if you're essentially telling me go away? I don't think anyone is telling you to go away. I think the intended message is more like think twice. I can't really expect from you to include new functionality or to adjust things, since you are only interested if it concerns OpenSC's internals. Or you can explain the benefits and change the direction. You are a contributor like others, and if you want to work on some aspects of OpenSC then I think the community should welcome that, and certainly consider if it would be an improvement. PKCS#11 has the same characteristics as PC/SC. While not the best or most flexible, it is the best we have. I think GnomeKeyring is one of the best examples why interoperability matters and how it can help get things done in real life. I don't think I understand this. What does hiding functionality have to do with interoperability? p11 is the dominating (crap) standard for crypto smart cards. I've hated it pretty much since I first started looking into this area. But p11 is what the entire world insists on using; it is *the* standard for interop. Focusing on that means that OpenSC might need to evolve more quickly internally than authors would like to be the case for a generic smart card library. On the other hand, that is a workable policy too, I think. It can still be useful as a library even if it evolves rapidly. If you're interested in working on that I don't think that's a waste. //Peter pgp3hRmue9JBX.pgp Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] llibopensc.pc is not installed
On 12/07/2010 05:21 PM, Frank Morgner wrote: Hi! You're not supposed to link against libopensc via the sc_* API but use PKCS#11. It is possible but not encouraged, thus the .pc file is removed. Why is it not encouraged? Why do you need libopensc.pc (or what is linking agains libopensc)? I am using smart card abstraction offered by libopensc. For what it's worth, we were also considering using libopensc for smart card abstraction, but in the end chose another library because the public interface to libopensc was removed in svn. Also, Martin's opensc tokend uses libopensc directly, which makes it very painful to build. Instead of building against the public headers, the tokend needs whole opensc source tree for building. Regards, Kalev ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] llibopensc.pc is not installed
Hi! You're not supposed to link against libopensc via the sc_* API but use PKCS#11. It is possible but not encouraged, thus the .pc file is removed. Why is it not encouraged? Why do you need libopensc.pc (or what is linking agains libopensc)? I am using smart card abstraction offered by libopensc. Greets, Frank. pgpw3Px4mzkN5.pgp Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] llibopensc.pc is not installed
Is there any reason with libopensc.pc is not installed? It looks like r4081 deleted the line: pkgconfig_DATA = libopensc.pc Was this on purpose? -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] llibopensc.pc is not installed
On Dec 6, 2010, at 7:18 PM, Douglas E. Engert wrote: Is there any reason with libopensc.pc is not installed? It looks like r4081 deleted the line: pkgconfig_DATA = libopensc.pc Was this on purpose? You're not supposed to link against libopensc via the sc_* API but use PKCS#11. It is possible but not encouraged, thus the .pc file is removed. Why do you need libopensc.pc (or what is linking agains libopensc)? -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
