Re: [opensc-devel] Fork of Debian's openSC repo at Github with ideas for 0.12.2 DEB
Hi, On Monday, 22. August 2011, Andreas Jellinghaus wrote: Hi Daniel, Am Sonntag 21 August 2011, 23:23:36 schrieb Daniel Kahn Gillmor: On 08/21/2011 12:36 PM, Peter Marschall wrote: * renable zlib readline support [...] what about a new, official Debian package, with my changes as the starting point as starting point? i don't think these are compatible with the DFSG, alas. GNU readline (at least) is GPL-licensed, and opensc links against OpenSSL. So building a package that links to both of them creates a non-redistributable work :( http://people.gnome.org/~markmc/openssl-and-the-gpl.html I agree with this. No problem with me. I am more interested in getting an updated opensc package in Debian than to have libreadline included in the official package. I can keep these patches locally. That's why I wrote starting point in my original mail: - take the things from the repo you consider appropriate, - leave others out that you do not consider appropriate, - add additional things, ... and build an updated official Debian package ;-) On the other hand: what part of opensc benefits from using readline? I guess the only place it might be used is the opensc-explorer, and it works fine for me without readline - so I say lets remove the readline code to avoid this. Please do not remove the code from upstream. Having it had helped me a lot with the update of the openpgp driver. It is in a configure option and can be en-/ or disabled as required. An alternative is to replace libreadline by another editline library with a different license, e.g. libedit (also in Debian). Best regards Peter -- Peter Marschall pe...@adpm.de ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Fork of Debian's openSC repo at Github with ideas for 0.12.2 DEB
Hi, On Tuesday, 23. August 2011, Jean-Michel Pouré - GOOZE wrote: Do you also plan to build daily packages as well? No, publishing the repo was meant as a hint help for the Debian maintainers to update the official Debian opensc package. Best Peter -- Peter Marschall pe...@adpm.de ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Fork of Debian's openSC repo at Github with ideas for 0.12.2 DEB
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hello,
On 8/23/11 8:44 , Peter Marschall wrote:
On Sunday, 21. August 2011, you wrote:
On 08/21/2011 12:36 PM, Peter Marschall wrote:
* renable zlib readline support
i don't think these are compatible with the DFSG, alas.
GNU readline (at least) is GPL-licensed, and opensc links
against OpenSSL. So building a package that links to both of
them creates a non-redistributable work :(
http://people.gnome.org/~markmc/openssl-and-the-gpl.html
The linked page on OpenSSL and GPL also gives some additional hints:
1. Usual disclaimers apply, I've no legal background whatsoever,
don't trust a word I say ... I'm quite probably completely wrong.
2. One recommended way around this GPL incompatibility is to add an
OpenSSL exemption when you license your code under the GPL.
3. Remember that OpenSC is LGPL, not GPL (even though it is legal to
upgrade LGPL to GPL as has been proven by Spanish government)
4. iAnal as well. Consulting FSFE (for a second opinion on what can
and what can not be done) would be beneficial.
5. I consider Debian's position as a die-hard free software
precaution, I don't know that the OpenSSL vs (L)GPL issue has ever
been tested in courts, nor that it would actually represent the
interests of any involved party (be it OpenSC code contributors or
OpenSSL developers).
It is just something that is advised by lawyers as a precaution.
6. Creating unofficial, more complete but maybe more reckless packages
would still be beneficial, given that the distributor takes the
associated risks (I personally still believe that common sense and
good intents beats the lawyer-centric world we live in)
7. IMHO OpenSSL is something that comes with the operating system in
Debian (and other Linux distros)
Is there any way to have OpenSC build against some crypto
libraries other than OpenSSL (preferably licensed in
GPL-compatible ways) so we could link it to readline without
violating one license or the other?
Two options:
- decide to move to some other soft-crypto implementation and reap
out OpenSSL (would be lovely)
- create a small softcrypto mega-interface and allow to plug in
different softcrypto implementations (something like cURL did)
gradually. This would allow to build without OpenSSL in Debian and such
and provide a way to still make use of drivers which might not have a
developer or somebody to test any changes.
OK, let's leave out libreadline (simple changes in
debian/{rules,control}).
My interest is less in libreadline - although it makes
opensc-explorer a lot more comfortable - but in an update to opensc
in Debian.
What about that? PS: if zlib has similar issues, then maybe leave
it away too.
I don't know of such limitations.
- --
@MartinPaljak
+3725156495
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (Darwin)
iQIcBAEBCAAGBQJOU0bXAAoJEHSCZV4wfjRSfroP/1IeDmFPOPWO2ZosXglsYFmM
kYYzvah8l6G8F5KyHbo93vc3BeOe4zQN1ir3zMTpkBsSNDWdPtjd9g3j1uAF72/W
yNXvVgqihoAZ9HquRFqV1LMqR+4KpW/Wjm0eZm6y8TsgF7rPSVKSSZqwCdvye0up
uFZSBWQ4XOjQpFCdlrXJvCidzQ4a2f/RTdkqr0T0W5ntAGgks2WlbUn+bDSQnQVf
EmpU8SK0SOMzDxicXkVUjUmaVusxkLE1KFW3VPH0jEp1zjvtSidbFw6iNk2Vs98a
8KViwk/09BmHJ7vRv57KwFnOa9mCmVyX2gJyHSwbB7kflA7a2fxep8BdOdWQ9S7q
jKP0KJZmMuabFDJIvAlL0h1xIozikHCldhB46f/7lgZNssfy+AkaI1taA75uBJuy
AD5w+6YfkFTAriihbg0L+xshFiQSxKbSMzq0128/8vS59LZsq/O9JZ/xgaHiM2Lh
bot9M2Tj5efii4mdM0SWQx32O8jm8mmSrQLwIrdNqe4YavvpE0bPcI4Vz3ZGYnyz
2h6J7xm/I5KddIUb+jwVoB1OBudZ2KboUvwkQZaC8HYcf/Mzsk6wkGplyuTv0gjg
1Fc+bpG4kIRHsI4HKDB2FYcP+uYo4lMj0rCA0JcITckMpiVtgw9+E4Ucu7thPYFF
CED/e/n3jp8nUfugnYLg
=U75N
-END PGP SIGNATURE-
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Fork of Debian's openSC repo at Github with ideas for 0.12.2 DEB
2011/8/23 Martin Paljak mar...@martinpaljak.net: Is there any way to have OpenSC build against some crypto libraries other than OpenSSL (preferably licensed in GPL-compatible ways) so we could link it to readline without violating one license or the other? Two options: - decide to move to some other soft-crypto implementation and reap out OpenSSL (would be lovely) - create a small softcrypto mega-interface and allow to plug in different softcrypto implementations (something like cURL did) gradually. This would allow to build without OpenSSL in Debian and such and provide a way to still make use of drivers which might not have a developer or somebody to test any changes. Apple has deprecated OpenSSL in Lion. OpenSSL is still available but will be removed in a later version. See http://ludovicrousseau.blogspot.com/2011/08/mac-os-x-lion-and-openssl.html I think the correct option for OpenSC (if we stay with OpenSSL) is to statically link with OpenSSL (as I imagine is also done on Windows). Bye, -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Fork of Debian's openSC repo at Github with ideas for 0.12.2 DEB
On 8/23/11 11:46 , Ludovic Rousseau wrote: 2011/8/23 Martin Paljak mar...@martinpaljak.net: Is there any way to have OpenSC build against some crypto libraries other than OpenSSL (preferably licensed in GPL-compatible ways) so we could link it to readline without violating one license or the other? Two options: - decide to move to some other soft-crypto implementation and reap out OpenSSL (would be lovely) - create a small softcrypto mega-interface and allow to plug in different softcrypto implementations (something like cURL did) gradually. This would allow to build without OpenSSL in Debian and such and provide a way to still make use of drivers which might not have a developer or somebody to test any changes. Apple has deprecated OpenSSL in Lion. OpenSSL is still available but will be removed in a later version. See http://ludovicrousseau.blogspot.com/2011/08/mac-os-x-lion-and-openssl.html I think the correct option for OpenSC (if we stay with OpenSSL) is to statically link with OpenSSL (as I imagine is also done on Windows). From what I learned from the WWDC slides [1] (need to be signed in to ADC before opening the link) the reason for deprecating OpenSSL as an API from platform was troubles with guaranteeing ABI-compatibility (kitchen-sink API?) and the need to have an up to date FIPS compatible platform (OpenSSL is undergoing a new FIPS validation at the moment, AFAIK, but still only for x86). OpenSSL is in that matter a defacto industry standard, but far from being perfect for many use cases. But this only affects OpenSC on Mac OS X (which, in theory, should have the same problem with OpenSSL and license incompatibility as on Linux). Static linking is not the problem nor the solution on Linux (package dependencies should remove the ABI problem) For OS X, the main question is not what/how to use instead of OpenSSL, but what needs to be implemented instead of Tokend/CDSA to provide support for native applications. FYI: Safari 5.1 on 10.6 crashes with OpenSC.tokend. Or any tokend in that matter. Studying alternatives for OpenSSL would be a good idea nevertheless, creating a 15th API [2] for software crypto would also be sweet, why not having gateways to CommonCrypto/Transform on Mac (or whatever else they figure out next) and/or CNG/CryptoAPI on Windows in addition to a new chosen LGPL-compatible default platform as well as existing OpenSSL. Learning from cURL experience [3] would be useful as well. Best, Martin [1] http://adcdownload.apple.com/wwdc_2011/adc_on_itunes__wwdc11_sessions__pdf/212_nextgeneration_cryptographic_services.pdf [2] http://xkcd.com/927/ [3] http://curl.haxx.se/docs/ssl-compared.html -- @MartinPaljak +3725156495 signature.asc Description: OpenPGP digital signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Fork of Debian's openSC repo at Github with ideas for 0.12.2 DEB
On 8/23/2011 12:44 AM, Peter Marschall wrote: PS: if zlib has similar issues, then maybe leave it away too. The PIV card require zlib, or a replacement. Cards are being issued with compressed certificates. If you drop it, OpenSC will be useless for these cards. The PIV only uses OpenSSL for the PIV-tool, which is only used by a developer, to that is not an issue for the PIV card at least. -- 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] Fork of Debian's openSC repo at Github with ideas for 0.12.2 DEB
Hi,
On Sunday, 21. August 2011, you wrote:
On 08/21/2011 12:36 PM, Peter Marschall wrote:
* renable zlib readline support
[...]
what about a new, official Debian package, with my changes as the
starting point as starting point?
i don't think these are compatible with the DFSG, alas.
GNU readline (at least) is GPL-licensed, and opensc links against
OpenSSL. So building a package that links to both of them creates a
non-redistributable work :(
http://people.gnome.org/~markmc/openssl-and-the-gpl.html
Is there any way to have OpenSC build against some crypto libraries
other than OpenSSL (preferably licensed in GPL-compatible ways) so we
could link it to readline without violating one license or the other?
OK, let's leave out libreadline (simple changes in debian/{rules,control}).
My interest is less in libreadline - although it makes opensc-explorer
a lot more comfortable - but in an update to opensc in Debian.
What about that?
Best
Peter
PS: if zlib has similar issues, then maybe leave it away too.
--
Peter Marschall
pe...@adpm.de
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Fork of Debian's openSC repo at Github with ideas for 0.12.2 DEB
Hi, I have put an unofficial fork of the official OpenSC repo for the Debian packages ( git://git.debian.org/git/pkg-opensc/opensc.git ) onto github. It is available at git://github.com/marschap/pkg-opensc.git The branches erics-upsream erics-master are the upstream master branches from Eric's repo at git.debian.org The branches upstream master are my going at 0.12.2 packaging. Rough overview of the changes: * get rid of unecessary Build-Depends: libxt-dev * renable zlib readline support * add westcos-tool its man page: new with 0.12.2 * explicitely nable building of man pages * add *.profile files * don't use dh_autoconfigure in override_dh_autoconfigure, but call bootstrap (see below) configure directly * simplify opensc.install - get rid of debian/tmp - new file opensc.manpages - extend opensc.docs * empty 'dependency_libs' in .la files (please lintian) Are those .la files necessary at all (for dlopen, ...)? Details can be found in the commit messages. Using the changes I was able to successfully build private opensc 0.12.2-0pm1 (please forgive my private release numbering scheme ;-) packages for i386 and amd64. A few things I have not yet done/solved: * not 100% lintian clean: 3 or 4 warnings left I was too lazy. * In debian testing, trying to build the package using git-buildpackage with the autotools provided in the upstream tar ball failed. (Funnily it worked when doing a simple buildpackage) For this reason I am calling the ./bootstrap script at the beginning the configure phase which makes the package build, but creates a rather large debian diff. Feel free to play with it. Eric, what about a new, official Debian package, with my changes as the starting point as starting point? Best regards Peter -- Peter Marschall pe...@adpm.de ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Fork of Debian's openSC repo at Github with ideas for 0.12.2 DEB
On 08/21/2011 12:36 PM, Peter Marschall wrote: * renable zlib readline support [...] what about a new, official Debian package, with my changes as the starting point as starting point? i don't think these are compatible with the DFSG, alas. GNU readline (at least) is GPL-licensed, and opensc links against OpenSSL. So building a package that links to both of them creates a non-redistributable work :( http://people.gnome.org/~markmc/openssl-and-the-gpl.html Is there any way to have OpenSC build against some crypto libraries other than OpenSSL (preferably licensed in GPL-compatible ways) so we could link it to readline without violating one license or the other? --dkg signature.asc Description: OpenPGP digital signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Fork of Debian's openSC repo at Github with ideas for 0.12.2 DEB
Hi Daniel, Am Sonntag 21 August 2011, 23:23:36 schrieb Daniel Kahn Gillmor: On 08/21/2011 12:36 PM, Peter Marschall wrote: * renable zlib readline support [...] what about a new, official Debian package, with my changes as the starting point as starting point? i don't think these are compatible with the DFSG, alas. GNU readline (at least) is GPL-licensed, and opensc links against OpenSSL. So building a package that links to both of them creates a non-redistributable work :( http://people.gnome.org/~markmc/openssl-and-the-gpl.html I agree with this. Is there any way to have OpenSC build against some crypto libraries other than OpenSSL (preferably licensed in GPL-compatible ways) so we could link it to readline without violating one license or the other? On the other hand: what part of opensc benefits from using readline? I guess the only place it might be used is the opensc-explorer, and it works fine for me without readline - so I say lets remove the readline code to avoid this. It might be nice to have opensc link with libgcrypt instead of openssl too. libgcrypt has a very nice interface and is much easier to use than openssl in my opinion. but if we work on such a change, we will have some fun with the new stacking: will applications (that use openssl or libgnutls) still work if that library or a helper to that lib uses a plugin interface (pkcs#12) to load opensc pkcs#12 plugin which is linked to (libcrypto or libgcrypt). we had problems even with app - openssl - opensc - libcrypto setup in the past, and I would expect problems here - or this should at least require a lot of testing to make sure the resulting setup works correctly. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
