Correctly handle CK_UNAVAILABLE_INFORMATION

[minego]

The PKCS#11 specification states

The constant CK_UNAVAILABLE_INFORMATION is used in the ulValueLen field to denote an invalid or unavailable value. See C_GetAttributeValue for further details.

This MR exposes the CK_UNAVAILABLE_INFORMATION constant definition (along with CK_EFFECTIVELY_INFINITE which is defined next to it, for completeness sake) and checks for that result after calling C_GetAttributeValue

This corrects a crash when a PKCS#11 module returns this. I believe this will fix the following issues:
#139
#60

Prior to this change the returned value was being interpreted as an actual size, which resulted in attempting to allocate an array of size -1 which causes an overflow:

  File "pkcs11/_pkcs11.pyx", line 726, in pkcs11._pkcs11.Object.__getitem__
  File "pkcs11/_utils.pyx", line 11, in pkcs11._pkcs11.CK_BYTE_buffer
  File "stringsource", line 152, in View.MemoryView.array.__cinit__
OverflowError: Python int too large to convert to C ssize_t

[minego]

On a related note, I ran into this while trying to use this library with the Venafi Code Signing Client PKCS#11 module. I'd love to get that added to the list of supported modules. What is needed to make this happen?

[jrripple]

Nice, I've also been using Venafi and had the same issue. I had a similar solution locally, but I tried out your commits and they fix the issue too.

[minego]

Nice, I've also been using Venafi and had the same issue. I had a similar solution locally, but I tried out your commits and they fix the issue too.

Oh, good! I'm glad to hear that!

I'm one of the developers on the codesigning team at CyberArk (previously Venafi). Thanks for testing the change!

[kislyuk]

Thanks so much for the PR @minego! Could you please rebase as after landing another large PR there is a merge conflict? Thank you.

[minego]

Thanks so much for the PR @minego! Could you please rebase as after landing another large PR there is a merge conflict? Thank you.

Of course. Done.

[MatthiasValvekens]

Hmm, I think the rebase from 8bd26fa to adc6975 prior to merging actually broke this...

The rebased code checks the return value of C_GetAttributeValue against CK_UNAVAILABLE_INFORMATION as opposed to the ulValueLen field in the template. Pre-rebase, it was correct.

I'll try to do something about that, but this will be tricky to regression test. If my reading of the spec is correct, a compliant PKCS#11 module should also return a nonzero return value if it sets CK_UNAVAILABLE_INFORMATION, which should get picked up by assertRV anyway, so unless SoftHSM gets this wrong, it'll be tough to reproduce in CI...

[minego]

Hmm, I think the rebase from 8bd26fa to adc6975 prior to merging actually broke this...

The rebased code checks the return value of C_GetAttributeValue against CK_UNAVAILABLE_INFORMATION as opposed to the ulValueLen field in the template. Pre-rebase, it was correct.

I'll try to do something about that, but this will be tricky to regression test. If my reading of the spec is correct, a compliant PKCS#11 module should also return a nonzero return value if it sets CK_UNAVAILABLE_INFORMATION, which should get picked up by assertRV anyway, so unless SoftHSM gets this wrong, it'll be tough to reproduce in CI...

Thank you for pointing that out! I missed the logic change. I should have paid more attention when rebasing.

I've put up a new pull request here: #207