Changes to PKCS#11 definitions

Marcus Brinkmann marcus.brinkmann at ruhr-uni-bochum.de
Thu Oct 20 03:37:09 CEST 2011


On 10/19/2011 06:06 PM, Stef Walter wrote:
> On 2011-10-18 14:07, Marcus Brinkmann wrote:
>> On 10/17/2011 09:01 AM, Stef Walter wrote:
>>> Hey Marcus,
>>>
>>> I've made some minor fixes to the pkcs11.h header that comes from the Scute
>>> project, and wanted to contribute them back as requested.
>>>
>>> The patch makes all the relevant constants in pkcs11.h unsigned longs rather
>>> than integers. This allows use of the constants in places where need the size
>>> to be correct (such as varargs).
>>>
>>> The patch is rather large, bit it just makes that one change. Let me know if I
>>> should prepare it differently.
>>
>> I am unsure.  On the one hand, all these constants are supposed to be used for
>> ULONG datatypes, and thus it could be argued they should be UL.
>>
>> On the other hand, the official pkcs11.h header file doesn't do that.  So, in
>> order to be compatible, you can not rely on it, and have to cast anyway.
> 
> I see. That's a good point.
> 
>> The pkcs11.h file is supposed to be a drop in replacement for the official
>> header file (at least in CRYPTOKI_COMPAT mode).  It is true that adding the UL
>> would be backwards compatible, but you will then write code that can not be
>> backported to the official pkcs11.h without a visible indicator or compiler
>> warning of that.
>>
>> Do we really want that?
>>
>> Do you use the CRYPTOKI_COMPAT mode?
> 
> Yup, plain ol PKCS#11 definitions.
> 
> The bummer is that we have varargs functions in libgck [1], which accept
> these ulongs, so our shipped pkcs11.h header defines everything as UL so
> that the definitions can be easily used with those functions.

I wish I could just say we could add the UL, but what if somebody else already
uses the constants in varargs and relies on the lack of UL?  We would break
their code, and that in an incompatible way to the official pkcs11.h.

Seems to me we are pretty much forced not to do the change.  Or do you see a
way out?  Maybe if we make it dependent on a macro PKCS11_UL_CONSTANTS that
needs to be defined before including pkcs11.h?  I am not sure that would help
your library interface (if the user includes pkcs11.h before your header file,
you'd be hosed).

Thanks,
Marcus





More information about the Gnupg-devel mailing list