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> 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. Stuff that didn't work previously and now will work is not something I would consider API or ABI break. I see David argumentation as completely valid and correct - this is acceptable change. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
