On 04/04/2016 03:19 PM, Ryan Sleevi wrote:
I think I would push back on this a bit. David change is very close to other changes we've made in the NSS API, in fact this very API. This API originally only took a nickname. The token: was an extension added in such a way that existing applications that knew nothing about token: could still function.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.
It was purposefully done so that applications that simply passed through the nickname from the command line or from the user would get access to the new functionality.
When it has an observable difference, when it breaks the contract previously provided, we prefer not to do so.
I would disagree it breaks the contract.I'm presuming the issue here is that you are screening nicknames to prevent certain nicknames from being accessed. That presumably means you are restricting nicknames to certain tokens? since pkcs11 is not a valid token, it would not be in our allow list.
In general I wouldn't recommend using a nickname filter to restrict access to certain certs, I'm pretty sure I can break out of any such filter you set up with the existing code.
This code wouldn't affect filters on nicknames for object creation.I think rather than arguing from first principles (because you aren't getting any agreement that the priniciples you are starting from are the same ones the rest of us are seeing, let's just have an concrete example of a broken case in your existing filtering code where would be fooled into allowing something it didn't want to allow once this change is made.
bob
smime.p7s
Description: S/MIME Cryptographic Signature
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
