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 am willing to do a rebase for the ECDH code. Great! > 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'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. 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 - building *without* a software crypto back-end should also be possible, but this should not be accomplished by huge code blocks being made inaccessible. 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. - 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 -- @MartinPaljak +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
