Re: [opensc-devel] Static link for opensc-pkcs11.dll
Le 08/06/2011 18:40, Viktor Tarasov a écrit : Le 08/06/2011 15:10, Viktor Tarasov a écrit : Le 08/06/2011 14:31, Martin Paljak a écrit : Hello, On Jun 7, 2011, at 19:15 , Viktor Tarasov wrote: Seems reasonable. Will see how it affects the size of the installer. The difference in size will be around 1M (both pkcs#11 and minidriver are static) . Hmm... Given that the current installer weights around 1.8M, adding another megabyte would be a lot (is this the raw file size or an compressed installer?). Ok, in you previous mail you've suggested the variant 'C' as a possible solution. In this case the difference in the MSI size will be around 0.5M . Can this one be adopted ? Maybe this helps: variant 'C' compiled with 'Minimize Size' optimization has the same size as the actual OpenSC-0.12.1-win32.msi . Any objections to use size optimization and static opensc-pkcs11.dll? What is, according to you, the upper limit for the size of installer ? Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Static link for opensc-pkcs11.dll
Le 08/06/2011 14:31, Martin Paljak a écrit : On Jun 7, 2011, at 19:15 , Viktor Tarasov wrote: What's happened with the Spanish card? It went something like this: - Some company/organization in Spain takes OpenSC, hack their driver, publish the result (no source) - Juan Antonio notices the problem, creates the loadable card driver support (correct me if I remember it wrong), so that they could have their private blob but still use OpenSC as the license dictates. - doesn't matter, the private blob still consists heaps of OpenSC code - another similar card in Spain follows the same road - the police issued eID, DNIe gets a legal driver (LGPL-wise), this is the OpenDNIe and what needs to be merged in the nearest future. Thus the conclusion, that cooperative attitude with commercial (or government) entities and commercial interests is essential for the success of the project BUT the process should be bi-directional, the other parties should also take into account the bigger community. Personally I see nothing that contradicts the general friendly attitude of the OpenSC in a regards to the card producers or other entities. In my comprehension OpenSC was always attentive to the little problems of the humble cards -- there are card specific codes in the common parts, there are the extensions of the internal/external API to satisfy particular needs, there are the rapid temporary solutions, that where implemented for the immediate needs of some card, and that stay temporary for a long time . For me this is rather an advantage of OpenSC . If specific 'innovation' do not spoils work of the other card, do not contradicts the internal and other conventions for the usage of internal or external API, and if it make wider the OpenSC use cases -- why not ? If it is an internal installation then what about an internal alternative installer? Just trying to figure out the different available options to fulfill as many different requirements as possible. Cheers, Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Static link for opensc-pkcs11.dll
Hello, On Jun 7, 2011, at 19:15 , Viktor Tarasov wrote: Seems reasonable. Will see how it affects the size of the installer. The difference in size will be around 1M (both pkcs#11 and minidriver are static) . Hmm... Given that the current installer weights around 1.8M, adding another megabyte would be a lot (is this the raw file size or an compressed installer?). I would still suggest trying to make sure that the internal application is isolated from the public OpenSC installer. I still believe that OpenSC installer should try to follow what is the most optimal solution for the normal user of OpenSC and any internal developments adjust to that. Taking the Spanish example, the opposite has caused more problems in the long run than solve them... What's happened with the Spanish card? It went something like this: - Some company/organization in Spain takes OpenSC, hack their driver, publish the result (no source) - Juan Antonio notices the problem, creates the loadable card driver support (correct me if I remember it wrong), so that they could have their private blob but still use OpenSC as the license dictates. - doesn't matter, the private blob still consists heaps of OpenSC code - another similar card in Spain follows the same road - the police issued eID, DNIe gets a legal driver (LGPL-wise), this is the OpenDNIe and what needs to be merged in the nearest future. Thus the conclusion, that cooperative attitude with commercial (or government) entities and commercial interests is essential for the success of the project BUT the process should be bi-directional, the other parties should also take into account the bigger community. If it is an internal installation then what about an internal alternative installer? Just trying to figure out the different available options to fulfill as many different requirements as possible. Cheers, Martin -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Static link for opensc-pkcs11.dll
Le 08/06/2011 14:31, Martin Paljak a écrit : Hello, On Jun 7, 2011, at 19:15 , Viktor Tarasov wrote: Seems reasonable. Will see how it affects the size of the installer. The difference in size will be around 1M (both pkcs#11 and minidriver are static) . Hmm... Given that the current installer weights around 1.8M, adding another megabyte would be a lot (is this the raw file size or an compressed installer?). Ok, in you previous mail you've suggested the variant 'C' as a possible solution. In this case the difference in the MSI size will be around 0.5M . Can this one be adopted ? What is, according to you, the upper limit for the size of installer ? I would still suggest trying to make sure that the internal application is isolated from the public OpenSC installer. It's not possible in my use case. Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Static link for opensc-pkcs11.dll
Le 08/06/2011 15:10, Viktor Tarasov a écrit : Le 08/06/2011 14:31, Martin Paljak a écrit : Hello, On Jun 7, 2011, at 19:15 , Viktor Tarasov wrote: Seems reasonable. Will see how it affects the size of the installer. The difference in size will be around 1M (both pkcs#11 and minidriver are static) . Hmm... Given that the current installer weights around 1.8M, adding another megabyte would be a lot (is this the raw file size or an compressed installer?). Ok, in you previous mail you've suggested the variant 'C' as a possible solution. In this case the difference in the MSI size will be around 0.5M . Can this one be adopted ? Maybe this helps: variant 'C' compiled with 'Minimize Size' optimization has the same size as the actual OpenSC-0.12.1-win32.msi . What is, according to you, the upper limit for the size of installer ? Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Static link for opensc-pkcs11.dll
Hello, On Jun 6, 2011, at 18:53 , Viktor Tarasov wrote: Le 06/06/2011 15:31, Martin Paljak a écrit : Hello, On May 29, 2011, at 10:05 , Viktor Tarasov wrote: I have a xulrunner application that uses the old modified version of opensc.dll and that needs to be used with the actual OpenSC PKCS#11 module . Static linking will allow the peaceful cohabitation. I would suggest statically compiling the custom version and using it however you find necessary or combining It's not actually possible. Why not? What is the custom xulrunner application anyway? Given it is custom, any set of customizations should be possible? The reasons are mostly 'internals'. The build application procedure is quite complicated, subject of the intense QA testing, and finally is not easy to change. ... Changing the installer is also possible, but it should follow some reasonable and consistent style. Just bundling more files does not seem like one. Possible options could be: A: current situation B: blend between static and dynamic linking inside OpenSC package - static PKCS#11 - static Minidriver - opensc.dll for tools only, in tools folder This would be perfect for me. Can this scheme be adopted as a general and replace the current one ? Seems reasonable. Will see how it affects the size of the installer. I still believe that OpenSC installer should try to follow what is the most optimal solution for the normal user of OpenSC and any internal developments adjust to that. Taking the Spanish example, the opposite has caused more problems in the long run than solve them... Best, Martin -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Static link for opensc-pkcs11.dll
Le 07/06/2011 16:30, Martin Paljak a écrit : Hello, On Jun 6, 2011, at 18:53 , Viktor Tarasov wrote: Le 06/06/2011 15:31, Martin Paljak a écrit : Hello, On May 29, 2011, at 10:05 , Viktor Tarasov wrote: I have a xulrunner application that uses the old modified version of opensc.dll and that needs to be used with the actual OpenSC PKCS#11 module . Static linking will allow the peaceful cohabitation. I would suggest statically compiling the custom version and using it however you find necessary or combining It's not actually possible. Why not? What is the custom xulrunner application anyway? Given it is custom, any set of customizations should be possible? The reasons are mostly 'internals'. The build application procedure is quite complicated, subject of the intense QA testing, and finally is not easy to change. ... Changing the installer is also possible, but it should follow some reasonable and consistent style. Just bundling more files does not seem like one. Possible options could be: A: current situation B: blend between static and dynamic linking inside OpenSC package - static PKCS#11 - static Minidriver - opensc.dll for tools only, in tools folder This would be perfect for me. Can this scheme be adopted as a general and replace the current one ? Seems reasonable. Will see how it affects the size of the installer. The difference in size will be around 1M (both pkcs#11 and minidriver are static) . I still believe that OpenSC installer should try to follow what is the most optimal solution for the normal user of OpenSC and any internal developments adjust to that. Taking the Spanish example, the opposite has caused more problems in the long run than solve them... What's happened with the Spanish card? Best, Martin Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Static link for opensc-pkcs11.dll
Hello, On May 29, 2011, at 10:05 , Viktor Tarasov wrote: I have a xulrunner application that uses the old modified version of opensc.dll and that needs to be used with the actual OpenSC PKCS#11 module . Static linking will allow the peaceful cohabitation. I would suggest statically compiling the custom version and using it however you find necessary or combining It's not actually possible. Why not? What is the custom xulrunner application anyway? Given it is custom, any set of customizations should be possible? Adding a separate build step to the default makefiles for *building* static binaries in parallel with current ones would be nice and OK. Ok. But the MSI script of the installer should be tailored for most appropriate delivery method for 80% use cases/users where the current dependency on a central libopensc.dll seems justified to me at least. Afaiu, for the customer of PKCS#11 module there is no (beside the size) difference if this module is static or not . The other dependent libraries are actually statically linked -- OpenSSL, zlib, ... Correct. Because for several reasons (like users of minidriver, mostly), it is good to install relevant DLL-s into System folder. Having OpenSSL (or zlib) DLL-s in System folder is a Very Bad Idea to my knowledge, but having a single OpenSC DLL should be manageable and a reasonable choice. Thus the current model of separate DLL-s for interfaces (minidriver, pkcs11), a central DLL for The Core (opensc.dll) and utilities using the core. Having a slim installer is IMHO desirable, as is having a minimal set of installed files (I really wish the onepin PKCS#11 module could be removed, hopefully Firefox/NSS folks will realize what's going on one day, I gave up explaining or trying to come up with a patch, it also requires GUI changes to be effective). Changing the installer is also possible, but it should follow some reasonable and consistent style. Just bundling more files does not seem like one. Possible options could be: A: current situation B: blend between static and dynamic linking inside OpenSC package - static PKCS#11 - static Minidriver - opensc.dll for tools only, in tools folder C: another blend between static and dynamic linking: - static PKCS#11 - opensc.dll used by everything else D: fully static compilation (not reasonable) E: other options? But it's not so important -- the second static version of PKCS#11 module included into MSI will be sufficient. Into OpenSC.msi? I don't think that's a good idea. Changing the setup plan for OpenSC would be reasonable though. Best, Martin -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Static link for opensc-pkcs11.dll
Le 06/06/2011 15:31, Martin Paljak a écrit : Hello, On May 29, 2011, at 10:05 , Viktor Tarasov wrote: I have a xulrunner application that uses the old modified version of opensc.dll and that needs to be used with the actual OpenSC PKCS#11 module . Static linking will allow the peaceful cohabitation. I would suggest statically compiling the custom version and using it however you find necessary or combining It's not actually possible. Why not? What is the custom xulrunner application anyway? Given it is custom, any set of customizations should be possible? The reasons are mostly 'internals'. The build application procedure is quite complicated, subject of the intense QA testing, and finally is not easy to change. Adding a separate build step to the default makefiles for *building* static binaries in parallel with current ones would be nice and OK. Ok. But the MSI script of the installer should be tailored for most appropriate delivery method for 80% use cases/users where the current dependency on a central libopensc.dll seems justified to me at least. Afaiu, for the customer of PKCS#11 module there is no (beside the size) difference if this module is static or not . The other dependent libraries are actually statically linked -- OpenSSL, zlib, ... Correct. Because for several reasons (like users of minidriver, mostly), it is good to install relevant DLL-s into System folder. Having OpenSSL (or zlib) DLL-s in System folder is a Very Bad Idea to my knowledge, but having a single OpenSC DLL should be manageable and a reasonable choice. Thus the current model of separate DLL-s for interfaces (minidriver, pkcs11), a central DLL for The Core (opensc.dll) and utilities using the core. Having a slim installer is IMHO desirable, as is having a minimal set of installed files (I really wish the onepin PKCS#11 module could be removed, hopefully Firefox/NSS folks will realize what's going on one day, I gave up explaining or trying to come up with a patch, it also requires GUI changes to be effective). Changing the installer is also possible, but it should follow some reasonable and consistent style. Just bundling more files does not seem like one. Possible options could be: A: current situation B: blend between static and dynamic linking inside OpenSC package - static PKCS#11 - static Minidriver - opensc.dll for tools only, in tools folder This would be perfect for me. Can this scheme be adopted as a general and replace the current one ? C: another blend between static and dynamic linking: - static PKCS#11 - opensc.dll used by everything else D: fully static compilation (not reasonable) E: other options? But it's not so important -- the second static version of PKCS#11 module included into MSI will be sufficient. Into OpenSC.msi? I don't think that's a good idea. Changing the setup plan for OpenSC would be reasonable though. Best, Martin Kind wishes, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Static link for opensc-pkcs11.dll
Le 29/05/2011 01:13, Martin Paljak a écrit : Hello, On May 28, 2011, at 22:47 , Viktor Tarasov wrote: Le 28/05/2011 22:26, Martin Paljak a écrit : Hello, On May 28, 2011, at 22:07 , Viktor Tarasov wrote: I would like to link statically the PKCS#11 module for Windows, or at least to include the static version of this module into the MSI . Why? It's a question of using of the different versions of opensc on the same platform. For standard distribution (AKA the OpenSC WindowsInstaller) there should not be such option. It is the same on Linux or OS X: only one instance (version) of a package can be installed. I have a xulrunner application that uses the old modified version of opensc.dll and that needs to be used with the actual OpenSC PKCS#11 module . Static linking will allow the peaceful cohabitation. I would suggest statically compiling the custom version and using it however you find necessary or combining It's not actually possible. Adding a separate build step to the default makefiles for *building* static binaries in parallel with current ones would be nice and OK. Ok. But the MSI script of the installer should be tailored for most appropriate delivery method for 80% use cases/users where the current dependency on a central libopensc.dll seems justified to me at least. Afaiu, for the customer of PKCS#11 module there is no (beside the size) difference if this module is static or not . The other dependent libraries are actually statically linked -- OpenSSL, zlib, ... But it's not so important -- the second static version of PKCS#11 module included into MSI will be sufficient. Cheers, Martin Kind wishes, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Static link for opensc-pkcs11.dll
Hello, I would like to link statically the PKCS#11 module for Windows, or at least to include the static version of this module into the MSI . Here in attachment there in the diff for the build procedure (it presumes the change of link mode for the actual PKCS#11 module dll). Have you any objections, please? Kind wishes, Viktor. Index: src/libopensc/Makefile.mak === --- src/libopensc/Makefile.mak (révision 5507) +++ src/libopensc/Makefile.mak (copie de travail) @@ -44,4 +44,4 @@ if EXIST opensc.dll.manifest mt -manifest opensc.dll.manifest -outputresource:opensc.dll;2 opensc_a.lib: $(OBJECTS) ..\scconf\scconf.lib ..\common\common.lib ..\pkcs15init\pkcs15init.lib - lib $(LIBFLAGS) /out:opensc_a.lib $(OBJECTS) ..\scconf\scconf.lib ..\common\common.lib ..\pkcs15init\pkcs15init.lib user32.lib + lib $(LIBFLAGS) /out:opensc_a.lib $(OBJECTS) ..\scconf\scconf.lib ..\common\common.lib ..\common\libscdl.lib ..\pkcs15init\pkcs15init.lib $(ZLIB_LIB) user32.lib ws2_32.lib Index: src/pkcs11/Makefile.mak === --- src/pkcs11/Makefile.mak (révision 5507) +++ src/pkcs11/Makefile.mak (copie de travail) @@ -22,11 +22,11 @@ link $(LINKFLAGS) /dll /def:$*.def /implib:$*.lib /out:$(TARGET0) $(OBJECTS) hack-enabled.obj ..\libopensc\opensc.lib ..\scconf\scconf.lib ..\pkcs15init\pkcs15init.lib ..\common\common.lib $(OPENSSL_LIB) gdi32.lib if EXIST $(TARGET0).manifest mt -manifest $(TARGET0).manifest -outputresource:$(TARGET0);2 -$(TARGET): $(OBJECTS) hack-disabled.obj ..\libopensc\opensc.lib ..\scconf\scconf.lib ..\pkcs15init\pkcs15init.lib ..\common\common.lib +$(TARGET): $(OBJECTS) hack-disabled.obj ..\libopensc\opensc_a.lib ..\pkcs15init\pkcs15init.lib echo LIBRARY $* $*.def echo EXPORTS $*.def type $*.exports $*.def - link $(LINKFLAGS) /dll /def:$*.def /implib:$*.lib /out:$(TARGET) $(OBJECTS) hack-disabled.obj ..\libopensc\opensc.lib ..\scconf\scconf.lib ..\pkcs15init\pkcs15init.lib ..\common\common.lib $(OPENSSL_LIB) gdi32.lib + link $(LINKFLAGS) /dll /def:$*.def /implib:$*.lib /out:$(TARGET) $(OBJECTS) hack-disabled.obj ..\libopensc\opensc_a.lib ..\pkcs15init\pkcs15init.lib $(OPENSSL_LIB) gdi32.lib if EXIST $(TARGET).manifest mt -manifest $(TARGET).manifest -outputresource:$(TARGET);2 $(TARGET3): $(OBJECTS3) ..\libopensc\opensc.lib ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Static link for opensc-pkcs11.dll
This is only for MSC build, not for mingw. But as this project is going to MSC release anyway... On Sat, May 28, 2011 at 11:07 PM, Viktor Tarasov viktor.tara...@gmail.com wrote: Hello, I would like to link statically the PKCS#11 module for Windows, or at least to include the static version of this module into the MSI . Here in attachment there in the diff for the build procedure (it presumes the change of link mode for the actual PKCS#11 module dll). Have you any objections, please? Kind wishes, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Static link for opensc-pkcs11.dll
Hello, On May 28, 2011, at 22:07 , Viktor Tarasov wrote: I would like to link statically the PKCS#11 module for Windows, or at least to include the static version of this module into the MSI . Why? -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Static link for opensc-pkcs11.dll
Le 28/05/2011 22:26, Martin Paljak a écrit : Hello, On May 28, 2011, at 22:07 , Viktor Tarasov wrote: I would like to link statically the PKCS#11 module for Windows, or at least to include the static version of this module into the MSI . Why? It's a question of using of the different versions of opensc on the same platform. I have a xulrunner application that uses the old modified version of opensc.dll and that needs to be used with the actual OpenSC PKCS#11 module . Static linking will allow the peaceful cohabitation. Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
