> From: Brandon Perry [mailto:bperry.volat...@gmail.com] > Sent: Sunday, February 16, 2014 11:55 AM > > If this is the case, that sounds like a bug. Behaviour shouldn't deviate > across implementations like that AFAIK.
Ideally, yeah, but realistically, behavior will deviate. (See my other question, about the non-existence of ECDiffieHellman. Existence vs Non-existence is a pretty big deviation.) ;-) The important thing is that the API remain functionally equivalent. Not long ago, I discovered that PKCS12.GetBytes() in MS behaves fine with a blank password, while mono fails on blank password. And the hash algorithm is basically restricted to SHA1, as deviation from SHA1 causes mono to fail a lot. Which is fine, but the point is, deviations do exist. Some more dramatic than others. This particular difference, generating key in constructor versus only when necessary, as far as I'm concerned, is not a bug, and not an issue. Because the API remains the same. On the other hand, the non-existent ECDiffieHellman is a significant missing feature, and the non-acceptance of blank password is a legitimate bug that nobody cares about. ;-) (Not even me) In RSACryptoServiceProvider.cs constructor, there is this comment: // Here it's not clear if we need to generate a keypair // (note: MS implementation generates a keypair in this case). // However we: // (a) often use this constructor to import an existing keypair. // (b) take a LOT of time to generate the RSA keypair // So we'll generate the keypair only when (and if) it's being // used (or exported). This should save us a lot of time (at // least in the unit tests). _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
