On 9/21/2011 6:28 PM, Martin Paljak wrote: > Hello, > > On 9/21/11 6:52 , Douglas E. Engert wrote: >> Back to the master plan. > Yes. I was off for 5 days in Brussels for BruCON (which was great!), so > back to things and plans. > >> Would it help to for a developer to rebase their changes as you add >> other changes? > Yes. > >> Viktor said on 8/11/2011: >>> I guess that we should have some intermediate branch with a more or >>> less common commit access, >>> that can be fed by more then one person and that could be used as a >>> fresh code base for the patch/merge proposals. >>> This branch could be considered as 'almost sure' and normally could be >>> merged into the individual experimental branches without apprehension. >>> This branch should be the only one to be checked for the conflicts by >>> proposals authors. >>> >>> I was thinking about something like 'proposal' branch of the OpenSC >>> github. >> >> A developer could rebase their changes against this 'proposal' branch >> so making it easier to pull in the developers changes. > Yes.
I was assuming that your https://github.com/martinpaljak/OpenSC.git 'proposed' branch was meant to be this 'proposal' branch, and so have been g=based of of it. If there will be a new branch,what and were would it be? > > >> I am willing to do a rebase for the ECDH code. > Great! Just tell me the repository and branch. > >> There is one area that still needs to be addressed. The ecdh/derive >> depends on much of the code that was introduced by the USE_PKCS15_INIT. >> >> But USE_PKCS15_INIT is only defined if ENABLE_OPENSSL is defined, >> and USE_PKCS_15_INIT ifdef's out much of the code that is needed by >> derive even though the derive code does not use OpenSSL. >> >> So I/we need a mode to change the #ifdefs for USE_PKCS15_INIT. >> This could be done against the 'proposed' branch, and then >> the ecdh code could be rebased on top of that. >> >> What do you suggest? > This should be addressed. I agree. > > I've separated OpenSSL usage in src/libopensc to a "softcrypto" > minimodule and am half way through with making sure that the interface > would be sufficient by re-implementing used functionality with > alternative libgcrypt backend as well. I have not looked at all the drivers, but it appears that the policy for OpenSC has been no crypto would be done in software. This include random number generation, hashes or encrypt/decrypt or verification. Most of the OpenSSL code I have seen in OpenSC was to use the BIO and ASN1 routines. But most of the ASN1 can now be done by internal OpenSC routines. Hashes and maybe GOST appear to be the issues. On the other hand, if a softcrypto back end is added, this opens up the possibility for OpenSC to use it to do actual crypto, for example using the OpenSSL FIPS version. Is this the intent? For ECC this would also open up the possibility to create ephemeral keys as PKCS#11 session objects. (Its not clear if this is needed, as when OpenSC is used from NSS, the NSS softoken creates the ephemeral keys and OpenSC does not need to.) In src/pkcs11 the use of OpenSSL > is even more interwoven, so fixing this is more complicated. As soon as > I am be done with the code in src/libopensc I'll push it out for review > and additional help to get this into src/pkcs11 as well. > > Decoupling ENABLE_OPENSSL and USE_PKCS15_INIT beforehand would > nevertheless make it even more straightforward. > > IMHO the following assumptions should be applied: > - USE_PKCS15_INIT should disappear altogether > - building with a "softcrypto" library (OpenSSL or libgcrypt or > CrytpoAPI or maybe even something entirely different) shall be assumed I agree. > - building *without* a software crypto back-end should also be > possible, but this should not be accomplished by huge code blocks being > made inaccessible. That is in effect what we have been doing with the current code, although I don't know a distro that builds without OpenSSL. I have done everything possible to make sure OpenSSL is not required for ordinary client usage of the card I am interested in, and test without it. (Thats how I found this USE_PKCS15_INIT issue.) > In fact, there should be no #ifdef-s checking for > OpenSSL or similar in common code, only in > src/libopensc/softcrypto(-*.c|.h). sc_softcrypto_features() kind of > machinery can be used to test for the presence of certain algorithms or > ciphers if needed for advertising features. Sounds reasonable. > - building without a software crypto back-end shall possibly result in > undefined behavior and probably several SC_ERROR_NOT_SUPPORTED errors, > if hit. Just need to make sure that they get reported appropriately. > > Best,ƒ´ƒ > Mar tin -- 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
