Re: [pkcs11] fwd: CKM_PKCS5_PBKD2_PARAMS struct: password length

[Robert Relyea <rrelyea@redhat.com>]

On 04/12/2013 10:07 PM, Tim Hudson wrote:
> On 13/04/2013 11:20 AM, Michael StJohns wrote:
> > Fix attached.
> That isn't a "fix" - that's a way to keep the problem repeating itself
> again and again.
>
> The existing structure should be renamed and the mechanism value changed
> so that new users of the 2.40 header files get the right usage.
> To use a deprecated mechanism should require code changes in the
> consumers of the interface.
>
> We do not want any usage of the broken (non-interoperable) interface to
> occur for users who recompile existing consumers of the API against the
> v2.40 header file.

I'm OK with the rename, because I can make that work.  On some of my 
shipping platforms, I may have to hide the rename under an ifdef 
(ENABLE_CORRECT_PKCS_11_2_40), but I would certainly make using the old 
structure noisy at compile time (In NSS we do windows and GCC features 
to tell the compiler to warn the user that they are using deprecated 
symbols. In GCC 4.5 or later you can actually tell the compiler what the 
issue is:

typedef CK_MECHANISM_TYPE _CKM_MY_BAD_MECH __attribute__ ((deprecated
 ("CKM_MY_BAD_MECH is not safe use CKM_MY_GOOD_MECH instead, or turn on ENABLE_CORRECT_PKCS_11_2_40"));
#define CKM_MY_BAD_MECH  ((_CKM_MY_BAD_MECH)0x01D)


Though our actual code handles several cases:

#if defined(__GNUC__) && (__GNUC__ > 3)
#if defined(__GNUC__ == 4) && (__GNUC_MINOR__ < 5)

typedef CK_MECHANISM_TYPE _CKM_MY_BAD_MECH __attribute__ ((deprecated
 ("CKM_MY_BAD_MECH is not safe use CKM_MY_GOOD_MECH instead, or turn on ENABLE_CORRECT_PKCS_11_2_40"));

# else

typedef CK_MECHANISM_TYPE _CKM_MY_BAD_MECH __attribute__ ((deprecated));

#endif

#define CKM_MY_BAD_MECH  ((_CKM_MY_BAD_MECH)0x01D)

#else
#ifdef _WIN32

#pragma deprecated(CKM_MY_BAD_MECH)

#endif

#define CKM_MY_BAD_MECH  0x01D

#endif


> This isn't a gentle deprecation content - anyone using the interface
> that isn't completely sure that both the producer and consumer of the
> interface have exactly the same interpretation is non-interoperable -
> this interface is simply broken.
>
> Changing the mechanism value to a new one so that previous binary users
> of the interface can continue to hope that it works with the same level
> of non-guarantee as currently will be supported. So a producer of the
> API can support both old and new interfaces (accepting
> non-interoperability) but v2.40 and beyond get sorted out.
It's obviously not just a recompile to get the correct behavior, some 
implementations, like mine, would also have to change they way it deals 
with the parameter, but the compiler would be nice and tell the 
implementer what is wrong in these cases, so even then they get sorted.

Anyway I'm OK with this proposal.

bob
> Tim.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature