On Tuesday, April 5, 2016, Hubert Kario <hka...@redhat.com> wrote: > On Monday 04 April 2016 12:17:08 Ryan Sleevi wrote: > > On Mon, Apr 4, 2016 at 11:32 AM, David Woodhouse <dw...@infradead.org > <javascript:;>> > 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. > > I'm sorry Ryan, but I also don't see how this would break API.
Does that mean you don't understand the use cases and situations outlined? Or that you don't believe they are valid use cases? Because those are all very different statements. > Stuff that didn't work previously and now will work is not something I > would consider API or ABI break. We have considered such changes multiple times in the past as breaks - most typically on Red Hat's request! This is why multiple extensions and behaviours are disabled by default in the TLS stack right now, even though they are strictly additive. How would you see this as any different? > I see David argumentation as completely valid and correct - this is > acceptable change. I still do not believe this is the case. We can certainly bring it up on the next NSS call. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
