Re: [opensc-devel] Upper limit for file size to upload into 'contrib'
Martin Paljak wrote: Some time ago I made a fileserver (fileser...@opensc-project.org) SSH account where every developer can plug in with a SSH key and upload files [1] which are not really related to releases or anything. Your public key is not on the list. [1] http://www.opensc-project.org/downloads/ Thanks, can the following public key be added to the authorized key lists, please? On Sun, Sep 26, 2010 at 17:24, Andreas Jellinghaus a...@dungeon.inka.de wrote: Am Sonntag 26 September 2010, um 14:52:58 schrieb Viktor TARASOV: Hi, what is the maximal possible size of the file to commit into the 'svn/files/trunk/contrib/' ? My attempt to upload the MSI of the opensc-sm, that weights a little bit more the 2M, was refused with error '413 Request Entity Too Large'. many files in the files svn are 10mb or larger. so 2mb shouldn't be an issue. also there is pletty of disk space left and we have no hook scripts to enforce any limites. so maybe this is a client issue? do you use a web proxy? http or https connection? Regards,Andreas Kind wishes, Viktor. ssh-dss B3NzaC1kc3MAAACBANx6pWMpRk6k5yqEZrtJh6im8BIqPsZRw68K2n29ObPcQUKFfHgkQgLdi9QU6XGX+mQ5zL/poozMCXQSoBFPJbmtMEcZc3UWkWhZKcTlGvhUORCrEcU/U+F9yvcspD59O6eN5ywreRtKXg891DmaJ189Cvv8u4NJD5ERxONp6QfbFQDW39bFLEK3yeBq+chZ0Oq3c2qXIwAAAIEArx+/GbF9WsUpseagWf7dL2ak4lRrMLdTTvjDuBpBBLcjxL7v7sw85uOrl+TausS6tOdNYL8fmzrRzN2TY6FP8zQcZTq3v+jS2lgNvCmYt44eBMT51QE417J88mJfMzxuZgujEZELEsOyJ2CVFZsQZlZLRsCl6hcC3CeQyCVX4n0AAACANr4LjHa9K9WWr0dPC9UwIvr97C1mm8v3zWiRwy/51OXxhsIdzpOWvDd2ypP69JXVn+Asc/jaTbLCe5WMAtByxGWft7R00igW2wZeZ9ivT8jeRNWE4b0EN22zDBEffqH2OezzwfUXh1Bf/T/Hk7OIJyjwnT65RDdy+Xkv/Ctt4+w= vtara...@sapin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Visual Studio Integration
Hello, I can't put my zip file because its size is larger than 2MB. Regards, Guillaume JEAN -Message d'origine- De : Martin Paljak [mailto:mar...@paljak.pri.ee] Envoyé : lundi 27 septembre 2010 00:10 À : JEAN Guillaume Cc : opensc-devel@lists.opensc-project.org Objet : Re: [opensc-devel] Visual Studio Integration Hello, On Sep 26, 2010, at 7:13 PM, JEAN Guillaume wrote: Hello, Patch : Is not patch it's folder group with configuration file for use Visual studio (.vsproject, .sln). ... Where I can deposit my zip file for you to view? You should start by upgrading the longstanding ticket [1] and attach your zip file for review. [1] http://www.opensc-project.org/opensc/ticket/105 -- @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] Visual Studio Integration
Hello, On Sep 27, 2010, at 11:06 AM, JEAN Guillaume wrote: I can't put my zip file because its size is larger than 2MB. What exactly do you put into that zip file then? There are plenty of file hosting services around, but I suspect the content of that ZIP is not correct, build instructions usually are not 2MB, compressed. Please send the zip file for inspection. -- @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] [opensc-commits] svn opensc changed[4776] Don't dump wiki content into distribution package.
On Mon, Sep 27, 2010 at 7:52 AM, Martin Paljak mar...@paljak.pri.ee wrote: But it is working correctly, that patch was incorrect. Leaving the possible changed logic for ChangeLog generation aside, what was incorrect in that patch? The changes in the docs, exactly what you request next. Please explain in some more details what is the problem with current trunk, so I can fix it. I'd like to clean up doc directory, the api directory and the symlinking in doc/Makefile.am are not needed for manpage generation. That was one of the changes in my original patch that actually triggered the distcheck problem, removing wiki dumping was not a problem. If you could also fix my original root cause would be great. I worked very hard to make it work in the past, I do not think there is a simpler shorter way to do this. The problem is that automake assume you seldom provide generated files within the source tarball, as you can always generate the files when you build the package. What we are trying to do is to provide pre-generated document files within the tarball, I don't like it, but this was the requirement. Doing so, when we need to support separate build directory is somewhat complex, as we cannot make the source directory dirty. But... the only dependency we require is xsltproc, so maybe we can rethink this... Provided you agree that building the package with --enable-doc or --enable-man requires xsltproc available on build machine, we can remove all this useless generation and hacks. Alon. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] svn opensc changed[4776] Don't dump wiki content into distribution package.
Hello, On Sep 27, 2010, at 12:06 PM, Alon Bar-Lev wrote: On Mon, Sep 27, 2010 at 7:52 AM, Martin Paljak mar...@paljak.pri.ee wrote: Please explain in some more details what is the problem with current trunk, so I can fix it. I'd like to clean up doc directory, the api directory and the symlinking in doc/Makefile.am are not needed for manpage generation. That was one of the changes in my original patch that actually triggered the distcheck problem, removing wiki dumping was not a problem. If you could also fix my original root cause would be great. I worked very hard to make it work in the past, I do not think there is a simpler shorter way to do this. The problem is that automake assume you seldom provide generated files within the source tarball, as you can always generate the files when you build the package. What we are trying to do is to provide pre-generated document files within the tarball, I don't like it, but this was the requirement. Doing so, when we need to support separate build directory is somewhat complex, as we cannot make the source directory dirty. Does this actually break anything in real life, other than make distcheck? make dist from a svn checkout works, generates the man files and they are present in the distribution targzip. make install from the same targzip also works. What exactly does make distcheck help (I tried reading the explanation in their manual [1] but that did not make anything much clearer) ? As the fail comes from a cp command and not xsltproc command, I assume the comment in doc/Makefile.am [2] is not correct? It seems like an automake issue, not xsltproc, which just requires correct parameters? But... the only dependency we require is xsltproc, so maybe we can rethink this... Provided you agree that building the package with --enable-doc or --enable-man requires xsltproc available on build machine, we can remove all this useless generation and hacks. I think it is not a huge problem to require xsltproc, it is quite common and small. What bothers me more is docbook-xsl. But the target audience of people who run make dist and who run make install is different. But maybe there's more in the autotools philosophy that I don't fully get. As the only documentation other than man pages is tools.html (should that be placed on the website somewhere?) one of --enable-doc or --enable-man is redundant. [1] http://www.gnu.org/software/hello/manual/automake/Checking-the-Distribution.html#Checking-the-Distribution [2] http://www.opensc-project.org/opensc/browser/trunk/doc/Makefile.am#L45 -- @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] [opensc-commits] svn opensc changed[4776] Don't dump wiki content into distribution package.
On Mon, Sep 27, 2010 at 12:34 PM, Martin Paljak mar...@paljak.pri.ee wrote: Does this actually break anything in real life, other than make distcheck? Yes. Whatever broken during distcheck will probably break somewhere. Major check of distcheck is separate build directory, this is used by many builders. But... the only dependency we require is xsltproc, so maybe we can rethink this... Provided you agree that building the package with --enable-doc or --enable-man requires xsltproc available on build machine, we can remove all this useless generation and hacks. I think it is not a huge problem to require xsltproc, it is quite common and small. What bothers me more is docbook-xsl. But the target audience of people who run make dist and who run make install is different. But maybe there's more in the autotools philosophy that I don't fully get. OK I will modify the build so that the file will be generated on builder. Much simpler! As the only documentation other than man pages is tools.html (should that be placed on the website somewhere?) one of --enable-doc or --enable-man is redundant. I do not follow... Do you want to remove the tools.html from build? Or install both man and htmls using one option? I don't think that installing to mandir and htmldir should be enforced as single option. Alon. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Visual Studio Integration
Hello, On Sep 27, 2010, at 11:06 AM, JEAN Guillaume wrote: I can't put my zip file because its size is larger than 2MB. After unpacking the zip file I get: inflating: Install-OpenSC/Install/Install-ENG.bat inflating: Install-OpenSC/Install/Install-FR.bat inflating: Install-OpenSC/Install/Install.bat inflating: Install-OpenSC/Install/opensc-Debug.reg inflating: Install-OpenSC/Install/opensc-Release.reg inflating: Install-OpenSC/Install/Readme-ENG.txt inflating: Install-OpenSC/Install/Readme-FR.txt inflating: Install-OpenSC/OpenSC-VC/Debug/bin/cardmod-westcos.reg inflating: Install-OpenSC/OpenSC-VC/Debug/bin/cardmod.inf inflating: Install-OpenSC/OpenSC-VC/Debug/bin/c_rehash inflating: Install-OpenSC/OpenSC-VC/Debug/bin/iconv.exe inflating: Install-OpenSC/OpenSC-VC/Debug/bin/libcharset-1.dll inflating: Install-OpenSC/OpenSC-VC/Debug/bin/libeay32.dll inflating: Install-OpenSC/OpenSC-VC/Debug/bin/libiconv-2.dll inflating: Install-OpenSC/OpenSC-VC/Debug/bin/libltdl-3.dll inflating: Install-OpenSC/OpenSC-VC/Debug/bin/libltdl3.dll inflating: Install-OpenSC/OpenSC-VC/Debug/bin/libopensc-3.dll inflating: Install-OpenSC/OpenSC-VC/Debug/bin/libp11-1.dll inflating: Install-OpenSC/OpenSC-VC/Debug/bin/libtool inflating: Install-OpenSC/OpenSC-VC/Debug/bin/libtoolize inflating: Install-OpenSC/OpenSC-VC/Debug/bin/opensc-install.bat inflating: Install-OpenSC/OpenSC-VC/Debug/bin/openssl.exe inflating: Install-OpenSC/OpenSC-VC/Debug/bin/piv-tool.exe inflating: Install-OpenSC/OpenSC-VC/Debug/bin/ssleay32.dll inflating: Install-OpenSC/OpenSC-VC/Debug/bin/zlib1.dll inflating: Install-OpenSC/OpenSC-VC/Debug/etc/opensc.conf inflating: Install-OpenSC/OpenSC-VC/Debug/etc/ssl/misc/CA.pl inflating: Install-OpenSC/OpenSC-VC/Debug/etc/ssl/misc/CA.sh inflating: Install-OpenSC/OpenSC-VC/Debug/etc/ssl/misc/c_hash inflating: Install-OpenSC/OpenSC-VC/Debug/etc/ssl/misc/c_info inflating: Install-OpenSC/OpenSC-VC/Debug/etc/ssl/misc/c_issuer inflating: Install-OpenSC/OpenSC-VC/Debug/etc/ssl/misc/c_name inflating: Install-OpenSC/OpenSC-VC/Debug/etc/ssl/misc/tsget inflating: Install-OpenSC/OpenSC-VC/Debug/etc/ssl/openssl.cnf inflating: Install-OpenSC/OpenSC-VC/Debug/include/iconv.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/libcharset.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/libp11.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/localcharset.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/ltdl.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/openssl/aes.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/openssl/asn1.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/openssl/asn1t.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/openssl/asn1_mac.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/openssl/bio.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/openssl/blowfish.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/openssl/bn.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/openssl/buffer.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/openssl/camellia.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/openssl/cast.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/openssl/cms.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/openssl/comp.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/openssl/conf.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/openssl/conf_api.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/openssl/crypto.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/openssl/des.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/openssl/des_old.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/openssl/dh.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/openssl/dsa.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/openssl/dso.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/openssl/dtls1.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/openssl/ebcdic.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/openssl/ec.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/openssl/ecdh.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/openssl/ecdsa.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/openssl/engine.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/openssl/err.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/openssl/evp.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/openssl/e_os2.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/openssl/hmac.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/openssl/idea.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/openssl/krb5_asn.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/openssl/kssl.h inflating: Install-OpenSC/OpenSC-VC/Debug/include/openssl/lhash.h inflating:
Re: [opensc-devel] [opensc-commits] svn opensc changed[4776] Don't dump wiki content into distribution package.
On Sep 27, 2010, at 1:56 PM, Alon Bar-Lev wrote: On Mon, Sep 27, 2010 at 12:34 PM, Martin Paljak mar...@paljak.pri.ee wrote: Does this actually break anything in real life, other than make distcheck? Yes. Whatever broken during distcheck will probably break somewhere. Major check of distcheck is separate build directory, this is used by many builders. OK. But... the only dependency we require is xsltproc, so maybe we can rethink this... Provided you agree that building the package with --enable-doc or --enable-man requires xsltproc available on build machine, we can remove all this useless generation and hacks. I think it is not a huge problem to require xsltproc, it is quite common and small. What bothers me more is docbook-xsl. But the target audience of people who run make dist and who run make install is different. But maybe there's more in the autotools philosophy that I don't fully get. OK I will modify the build so that the file will be generated on builder. Much simpler! Will this get rid of the symlink magic, and allow: make dist: require xsltproc, docbook-xsl, don't require playing with symlinks (assumes/requires running from version control checkout) make, make install: don't require xsltproc and docbook-xsl, use the pre-generated man files. As the only documentation other than man pages is tools.html (should that be placed on the website somewhere?) one of --enable-doc or --enable-man is redundant. I do not follow... Do you want to remove the tools.html from build? Or install both man and htmls using one option? I don't think that installing to mandir and htmldir should be enforced as single option. I did not notice that the tools.html is distributed (dist_html_DATA). But does it make sense to install two competing copies of tool usage options? If you use the tools, you use the command line, thus using man should be a known activity. If using a web browser, wiki has much more detailed information than in the htmlified man pages copy. -- @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] card-max_recv_size problem
Hello, On Sep 26, 2010, at 2:55 PM, Andre Zepezauer wrote: On Sun, 2010-09-26 at 09:22 +0300, Martin Paljak wrote: Hello, On Sun, Sep 26, 2010 at 08:47, Andre Zepezauer andre.zepeza...@student.uni-halle.de wrote: With the current trunk 2048b keys on CardOS are working again. Therefore the max_*_size patches work for me. But I have two suggestions: [1] The intended overriding will not work, if the card has a default value of zero for max_*_size. If this is the case, then limitations imposed by the reader are not honoured. It would be a programming error, which does not make sense. Śetting this to 0 would mean I'm a card and I can't receive or send data, but here is my 1K LOC driver nevertheless. The value of max_*_size actually defaults to zero [3] and will stay so, if not overridden by the card driver. See how it is used in the iso-driver. IMHO zero is a legal value and means that no restrictions are imposed by the card. Same is true for reader drivers. I managed to mis-explain my own idea. Yes, you are right, the values default to zero which means no limitations (not zero bytes) And yes, the overriding check is bogus if card does not impose limitations before the reader does. Will fix. -- @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] [opensc-commits] svn opensc changed[4776] Don't dump wiki content into distribution package.
On Mon, Sep 27, 2010 at 1:07 PM, Martin Paljak mar...@paljak.pri.ee wrote: But... the only dependency we require is xsltproc, so maybe we can rethink this... Provided you agree that building the package with --enable-doc or --enable-man requires xsltproc available on build machine, we can remove all this useless generation and hacks. I think it is not a huge problem to require xsltproc, it is quite common and small. What bothers me more is docbook-xsl. But the target audience of people who run make dist and who run make install is different. But maybe there's more in the autotools philosophy that I don't fully get. OK I will modify the build so that the file will be generated on builder. Much simpler! Will this get rid of the symlink magic, and allow: make dist: require xsltproc, docbook-xsl, don't require playing with symlinks (assumes/requires running from version control checkout) make dist *WILL NOT* require xsltproc, docbook-xsl. It will actually only distribute the sources, no generation of files. make, make install: don't require xsltproc and docbook-xsl, use the pre-generated man files. make *WILL* require xsltproc and docbook-xsl if and only if --enable-man and/or --enable-doc is specified at configure. If you want to avoid xsltproc dependency from make install, we back to square one (current trunk). As the only documentation other than man pages is tools.html (should that be placed on the website somewhere?) one of --enable-doc or --enable-man is redundant. I do not follow... Do you want to remove the tools.html from build? Or install both man and htmls using one option? I don't think that installing to mandir and htmldir should be enforced as single option. I did not notice that the tools.html is distributed (dist_html_DATA). But does it make sense to install two competing copies of tool usage options? If you use the tools, you use the command line, thus using man should be a known activity. If using a web browser, wiki has much more detailed information than in the htmlified man pages copy. Your call... :) ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] card-max_recv_size problem
Hello Martin,
automatically detecting the value of max_recv_size is an option too. The
following snippet of code can manage this. But it depends on the
capabilities of the get_challenge operation. For CardOS it could be
enabled, because it results in a value of 300 for CardOS 4.3b with
Omnikey reader. Please note that extended APDU:s are used. Therefore a
detection of this capability is required too.
Regards
Andre
u8 buf[1024];
sc_apdu_t apdu;
sc_format_apdu(card, apdu, SC_APDU_CASE_2_EXT, 0x84, 0x00, 0x00);
int i = 0;
while (1) {
int j = 0;
apdu.resplen = i + j;
while (apdu.resplen == i + j) {
if (j == 0)
j = 1;
else
j*=2;
apdu.le = i + j;
apdu.resp = buf;
apdu.resplen = sizeof(buf);
sc_transmit_apdu(card, apdu);
}
if (j == 1)
break;
i+=j/2;
}
printf(max_recv_size: %d\n, i);
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [RFC] Proposal For Restructuring 'struct sc_pkcs15_card'
Dear OpenSC developers,
the patch I proposed is mostly complete. The total count of lines is
huge, but individual changes are trivial. An exception to this is the
pkcs15 emulation related to the Oberthur cards. It makes heavy use of
flags before writing the TokenInfo to the card. Since the two different
kinds of flags are now divided, this required more changes than on other
places. Therefore it would be helpful if someone could test the
initialisation of oberthur cards after applying the attached patch.
For now I would like to know, if there are any complains about the patch
and your opinion about renaming the TokenInfo related flags to something
like SC_TOKENINFO_FLAGS.
Kind Regards
Andre Zepezauer
Index: src/tools/pkcs15-crypt.c
===
--- src/tools/pkcs15-crypt.c (revision 4777)
+++ src/tools/pkcs15-crypt.c (working copy)
@@ -583,7 +583,7 @@
goto end;
}
if (verbose)
- fprintf(stderr, Found %s!\n, p15card-label);
+ fprintf(stderr, Found %s!\n, p15card-tokeninfo-label);
if (do_decipher) {
if ((err = get_key(SC_PKCS15_PRKEY_USAGE_DECRYPT, key))
Index: src/tools/pkcs15-init.c
===
--- src/tools/pkcs15-init.c (revision 4777)
+++ src/tools/pkcs15-init.c (working copy)
@@ -462,7 +462,7 @@
* sure we're not messing things up */
if (verbose)
-printf(Found %s\n, p15card-label);
+printf(Found %s\n, p15card-tokeninfo-label);
sc_pkcs15init_set_p15card(profile, p15card);
@@ -627,7 +627,7 @@
p15card = sc_pkcs15_card_new();
p15card-card = in_card;
- p15card-label = strdup(Dummy PKCS#15 object);
+ p15card-tokeninfo-label = strdup(Dummy PKCS#15 object);
ignore_cmdline_pins++;
r = sc_pkcs15init_erase_card(p15card, profile);
Index: src/tools/pkcs15-tool.c
===
--- src/tools/pkcs15-tool.c (revision 4777)
+++ src/tools/pkcs15-tool.c (working copy)
@@ -1105,17 +1105,17 @@
int i, count = 0;
- printf(PKCS#15 Card [%s]:\n, p15card-label);
- printf(\tVersion: %d\n, p15card-version);
- printf(\tSerial number : %s\n, p15card-serial_number);
- printf(\tManufacturer ID: %s\n, p15card-manufacturer_id);
- if (p15card-last_update)
- printf(\tLast update: %s\n, p15card-last_update);
- if (p15card-preferred_language)
- printf(\tLanguage : %s\n, p15card-preferred_language);
+ printf(PKCS#15 Card [%s]:\n, p15card-tokeninfo-label);
+ printf(\tVersion: %d\n, p15card-tokeninfo-version);
+ printf(\tSerial number : %s\n, p15card-tokeninfo-serial_number);
+ printf(\tManufacturer ID: %s\n, p15card-tokeninfo-manufacturer_id);
+ if (p15card-tokeninfo-last_update)
+ printf(\tLast update: %s\n, p15card-tokeninfo-last_update);
+ if (p15card-tokeninfo-preferred_language)
+ printf(\tLanguage : %s\n, p15card-tokeninfo-preferred_language);
printf(\tFlags : );
for (i = 0; i 4; i++) {
- if ((p15card-flags i) 1) {
+ if ((p15card-tokeninfo-flags i) 1) {
if (count)
printf(, );
printf(%s, flags[i]);
@@ -1731,7 +1731,7 @@
if (opt_no_cache)
p15card-opts.use_file_cache = 0;
if (verbose)
- fprintf(stderr, Found %s!\n, p15card-label);
+ fprintf(stderr, Found %s!\n, p15card-tokeninfo-label);
if (do_verify_pin)
if ((err = verify_pin()))
Index: src/pkcs11/framework-pkcs15.c
===
--- src/pkcs11/framework-pkcs15.c (revision 4777)
+++ src/pkcs11/framework-pkcs15.c (working copy)
@@ -192,7 +192,7 @@
static void pkcs15_init_token_info(struct sc_pkcs15_card *p15card, CK_TOKEN_INFO_PTR pToken)
{
- strcpy_bp(pToken-manufacturerID, p15card-manufacturer_id, 32);
+ strcpy_bp(pToken-manufacturerID, p15card-tokeninfo-manufacturer_id, 32);
if (p15card-flags SC_PKCS15_CARD_FLAG_EMULATED)
strcpy_bp(pToken-model, PKCS#15 emulated, 16);
else
@@ -203,13 +203,13 @@
* _Assuming_ that the serial number is a Big Endian counter, this
* will assure that the serial within each type of card will be
* unique in pkcs11 (at least for the first 8^16 cards :-) */
- if (p15card-serial_number != NULL) {
- int sn_start = strlen(p15card-serial_number) - 16;
+ if (p15card-tokeninfo-serial_number != NULL) {
+ int sn_start = strlen(p15card-tokeninfo-serial_number) - 16;
if (sn_start 0)
sn_start = 0;
strcpy_bp(pToken-serialNumber,
- p15card-serial_number + sn_start,
+ p15card-tokeninfo-serial_number + sn_start,
16);
}
@@ -791,13 +791,13 @@
if (auth-label[0]) {
snprintf(tmp, sizeof(tmp), %s (%s),
-p15card-label, auth-label);
+p15card-tokeninfo-label, auth-label);
} else {
- snprintf(tmp, sizeof(tmp), %s, p15card-label);
+ snprintf(tmp, sizeof(tmp), %s, p15card-tokeninfo-label);
}
slot-token_info.flags |= CKF_LOGIN_REQUIRED;
} else
- snprintf(tmp, sizeof(tmp), %s, p15card-label);
+ snprintf(tmp, sizeof(tmp), %s,
[opensc-devel] OpenSC with or without OpenSSL - What is the direction?
There has been a effort to be able to build OpenSC without the use of OpenSSL. Yet there is newer code that keeps creeping in to the trunk that requires OpenSSL. The OpenSSL dependent code can be divided into 3 areas: (1) Code that tries to get some information from a certificate, such as the public key, or the basic constraints. For example sc_pkcs15_pubkey_from_cert in pkcs15-pubkey.c Much of this code appears to have been added because parse_x509_cert in pkcs15-cert.c does not do a good enough job in supporting more then RSA, and does not parse options like basic constraint that one card driver needs. (2) Code that deals with symmetric keys for example in, pkcs15-wrap.c It is not clear if the project wants to add native crypto to OpenSC code or continue to use OpenSSL, or some other package. (The gost code appears to introduce a dependency on the gost external engine, to do its crypto.) Any Secure Messaging or some card initialization that needs to authenticate to the card, needs this. (3) Old code that is not being used. p15card-helper.c for example in not used at all. It was introduced by a third party for use with the PIV card, but is no longer used, and in my option could be removed. I bring this up as I am interested in adding ECC support (with named curves only) to OpenSC for the PIV card. No ECC crypto needs to be done, but support for getting the EC pubkey from a cert and saving a pubkey generated by the card is needed. (As an attempt to not require OpenSSL, last week I committed changes that allowed the PIV driver to be built without OpenSSL. OpenSSL is still needed for card administration, as a 3DES Decrypt is still needed. But the administration code and piv-tool are not used by the ordinary users. This type of code falls into (2)) So what is the direction? (A) Continue to use OpenSSL but only in the most limited cases? (B) Try and stamp it out, but this would then require adding some crypto for symmetric keys and maybe other hash functions? (C) Embrace it, and use its crypto, key and cert structures and simplify OpenSC code? (D) Use some other crypto package? -- 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] [RFC] Proposal For Restructuring 'struct sc_pkcs15_card'
Hello, On Sep 27, 2010, at 9:59 PM, Andre Zepezauer wrote: the patch I proposed is mostly complete. The total count of lines is huge, but individual changes are trivial. An exception to this is the pkcs15 emulation related to the Oberthur cards. It makes heavy use of flags before writing the TokenInfo to the card. Since the two different kinds of flags are now divided, this required more changes than on other places. Therefore it would be helpful if someone could test the initialisation of oberthur cards after applying the attached patch. Great, I think this is a good example of separating sometimes a little bit obscure OpenSC specific data structures and specification related data structures. I have a few recommendations that could be fixed in the same change: - Fix abuse of pkcs15card-(tokeninfo-)version. PKCS#15 v1.1 tells that version == 0 means this version of the PKCS#15 spec which is v1.1. Which means the +1/-1 trickery in pkcs15.c for parsing/decoding tokeninfo-version should be removed, as should be removed emulation driver overloading for version info. Only 0 should be encoded and only 0 should be handled/displayed by internal code. - Change the flag names of PKCS#15 flags and pkcs15_card_t flags (as noted below). SC_TOKENINFO_RNG would be OK, there would be no other SC_TOKENINFO_* constants so the extra _FLAGS_ would just eat up bytes. Or maybe prepend the internal flags with _. Ideally, the verbosity of C should not exceed the verbosity of Java. - Maybe change the granularity of some memory allocations and required matching free()-s by card drivers. Or make set_string use common by more drivers and move it to some internal implementation file instead (currently copied from pkcs15-esteid.c to 5 other files). Maybe DEVELOPER FIX CARD NAME would be better for the default name for a PKCS#15 card, or an assert somewhere? For now I would like to know, if there are any complains about the patch and your opinion about renaming the TokenInfo related flags to something like SC_TOKENINFO_FLAGS. Some more additional improvements will make this a great patch. Cleaning up the internals of OpenSC is a good thing. -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
