On Mon, Apr 4, 2016 at 11:32 AM, David Woodhouse <dw...@infradead.org> wrote: > Do you even have a way for a nickname to be entered in text form, such > that you could "maliciously" be given a PKCS#11 URI instead of the > normal "token:nickname" form? Perhaps a user could edit a config file? > Or is it *all* selected via a GUI, as far as the user is concerned?
David, Let's work back from first principals, because you're being self-contradictory in replies. As you yourself note, this change would mean that any time an application can be introduced a "nickname" from some source (whether an API, a configuration file, a command-line flag) suddenly has a new semantic structure to the nickname over the present NSS. You present this as a positive change - all NSS using applications don't need to change. I've tried, repeatedly, to explain to you how that is an observable API difference. It means that nicknames supplied (again, whatever the API) now have additional structure and form. Your justification seems to be that because you can't imagine my application doing it, I shouldn't be concerned. But just re-read the above and you can see how it affects every application - there's now a new structure and form, and that changes how applications deal with the API (*especially* if they did anything with that configuration flag, which, under present NSS, is perfectly legal) Your change has observable differences. It breaks the API. Thus, it makes sense to introduce a new API. An application cannot safely assume it will 'just work' if your change was integrated - instead, authors would need to audit every API call they interact with nicknames from any source *other* than direct NSS calls, and see if they're affected. That's simply not an appropriate way to handle API changes. If we can't agree on these first principles, there's no point in discussing Chrome's behaviour, because it simply builds upon them. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
