> From: Juan Lang [mailto:juan.l...@gmail.com]
>
> > No, it's not. Return value is TRUE, buf is allocated and contains a
> > PUBKEYSTRUC followed by a RSAPUBKEY with len 56 while size contains 0x1b.
> > So Win7 is capable of decoding the key.
>
> Thanks for checking that. That appears to be a bug
> No, it's not. Return value is TRUE, buf is allocated and contains a
> PUBKEYSTRUC followed by a RSAPUBKEY with len 56 while size contains 0x1b.
> So Win7 is capable of decoding the key.
Thanks for checking that. That appears to be a bug to me, then,
although it could be that it's failing for so
> From: Juan Lang
> > I see 3 test failures related to CertGetPublicKeyLength() on Win7,
> > crypt32/tests/cert.c lines 3146/3160/3165. All 3 failures are the
> > same, CertGetPublicKeyLength() returns 0 with last error 0x80090004
> > (NTE_BAD_LEN). After looking at it for a while, I'm inclined to
Hi Ge,
> I see 3 test failures related to CertGetPublicKeyLength() on Win7,
> crypt32/tests/cert.c lines 3146/3160/3165. All 3 failures are the same,
> CertGetPublicKeyLength() returns 0 with last error 0x80090004 (NTE_BAD_LEN).
> After looking at it for a while, I'm inclined to change the cond
Hi Juan,
I see 3 test failures related to CertGetPublicKeyLength() on Win7,
crypt32/tests/cert.c lines 3146/3160/3165. All 3 failures are the same,
CertGetPublicKeyLength() returns 0 with last error 0x80090004 (NTE_BAD_LEN).
After looking at it for a while, I'm inclined to change the condition
