Fix supportsSecureCoding for intercepted classes

[bamx23]

Hi!

For at least a year I've been meeting the same problem: if there is an NSDate stub and test fails, test run fails(crashes) with something like this:

Class 'NSDate' has a superclass that supports secure coding, but 'NSDate' overrides -initWithCoder: and does not override +supportsSecureCoding. The class must implement +supportsSecureCoding and return YES to verify that its implementation of -initWithCoder: is secure coding compliant.

Today I've finally decided to figure out what is the problem. It all ended up with this patch.
Maybe someone has any idea about how to solve the problem more properly?

[bamx23]

@ecaselles Could you look at this pull-request?

[ecaselles]

Seems solid @bamx23 and apologies for the delay in the reply. It would be great if you could add a test to reproduce the original issue and then verify the patch solves it. That way, we make sure is covered for the future :)

[bamx23]

I feel it might be slightly difficult because reproducing the issue means breaking test runs. But I'll try to reproduce it anyway, sure.

[bamx23]

@ecaselles, I've implemented a test that reproduces the problem. Unfortunately, I haven't found any simpler way. There is a - [NSCoder validateClassSupportsSecureCoding:], which will return NO for [NSDate class] without my changes, but it's a private API.

[ecaselles]

Thanks @bamx23! It looks good to me. I agree it is not ideal and a bit stretched, but it works for checking your changes. I am happy to merge it as it is or we can add a comment explaining the rationale for this test if you think it will make it easier for future reference. What do you think?

[ecaselles]

Merging it @bamx23 so it's part of #719. Thanks for you help! 👏

[bamx23]

Thanks for merging! I wanted to add a comment early next week. If the next version will not have been released before that. Or maybe even if it will be released because comments are helpful either way.

[bamx23]

Here it is #721