On Mon, Apr 4, 2016 at 12:39 PM, David Woodhouse <dw...@infradead.org> wrote: > > We usually reserve the term "breaks the API" for when something *used* > to work, and now doesn't. Not when a previously-failing call now > actually does something useful.
No, sorry David, that's not how we've done stuff in NSS. When it has an observable difference, when it breaks the contract previously provided, we prefer not to do so. The contract that NSS has lived by is that applications have had to know about the token:nickname vs nickname rule in the APIs. When you get a nickname for a cert, depending on the function used, you may or may not have to add the token. If you don't, you get bad results. So we've had an API contract that the nicknames input to this function have a syntax and format, because applications have to be aware of how to construct it. Because applications have to be aware of how to construct it, applications also have to be aware of how to deconstruct it. For example, it's required when importing certs that you don't duplicate a nickname. So code that imports certs (such as from PFX files) needs to be able to handle nickname collisions, so it needs to be able to construct them. Introducing an overloading syntax of PKCS#11 URIs could also lead to issues there (there's the CERT_MakeCANickname function, but that doesn't handle the token:nickname construct). A public API example is SEC_PKCS12DecoderValidateBags. This is why I'm arguing that "nickname" is not 'opaque' - you have to know about the construction to get proper API behaviour - especially because two public APIs, CERT_FindCertByNickname and PK11_FindCertFromNickname, will return different results depending on the construction. PK11_FindCertFromNickname will *only* search that token, and only return *that* cert, while CERT_FindCertByNickname will potentially return temporary/in-memory certs if you don't include the token qualifier. > > And the latter is what we're talking about here. If you provide a > PKCS#11 URI as the 'nickname', that will *fail* right now. And the > proposal is that such a call will no longer fail. I'm aware. And in doing so, you're breaking the API contract as to what the format is to this function. If this was meant to be an opaque format, and applications were "doing the wrong thing" by reaching into it, you could make an argument that they were doing it wrong, it was always opaque, and that it's fine to break them. However, you can't just go change the format. API compatibility is more than just ABI compatibility - it's about whether the preconditions and postconditions hold. And allowing the input to be different breaks the API preconditions as to what format the nickname will be in, and those preconditions have indeed propagated into NSS-using applications. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
