On Thursday, March 17, 2016, David Woodhouse <dw...@infradead.org> wrote:
> > It is a fundamental part of all the major Linux desktop distributions, > and thus fairly much ubiquitous there. This is a loaded statement, but I still believe this is overstated. But I don't want to get into a "whose distro is better" pissing match. > For fun I tried removing it > recently on OpenSuSE, Fedora and Ubuntu — in all cases it basically > wanted to remove most of the distro. Running 'dnf remove p11-kit' won't > even play any more on Fedora. It just tells me that would require > removing systemd and dnf itself, and tells me 'no'. > > So my proposal that on platforms where p11-kit exists, NSS should just > link to it. But also, to avoid having to build and ship a separate > library on platforms which didn't already have it, I think we should > *import* the URI handling code from libp11-kit. That is mostly isolated > to one file, of 1305 lines which compiles to roughly 10KiB of code > under Linux/x86_64. > > Does that seem like the correct approach? I disagree that this seems like a wise or balanced tradeoff to fork this file. The lessons of SQLite show this just increases maintenance costs and leads to divergence. I respond to this more below. > The other open question, although it doesn't block the work at the > start of the project, is whether we should be extending > PK11_FindCertFromNickname() to accept RFC7512 URIs or whether we should > *only* accept URIs in a new function. I am still strongly opposed to introducing this behaviour to the existing functions. The nickname functions already have significant magic attached to them, both in parsing from NSS APIs and in providing to NSS APIs (filtering or setting the token via parsing or adding to the token name, respectively). This would definitely break Chrome's use of the API, and for that, I think it should be an unacceptable change as it is not backwards compatible. On the topic itself, of support PKCS#11 URIs, I remain opposed, and I would appreciate Richard's take on it. For Chrome, such a feature would have been useless for our Windows and Mac ports, and *is* useless for our iOS and ChromeOS ports. Further, we would not expose this functionality for our Linux port even if it existed, due to cross-platform considerations. On a technical front, Chrome and Firefox, as browsers, have been removing support for the notion of generic URIs, and investing in aligning on the URL spec - that is, making a conscious decision NOT to use URIs as URIs. Anne on the Mozilla side has been working that effort, and can probably speak more to that effort. I would much rather that if this is introduced, it is done so behind a compile time flag, and it's interactions with NSS as a whole kept as a minimum. I understand and appreciate why Fedora/RHEL distros are interested in this, but I don't believe it's something that Chrome would want, and I don't believe it's likely something Firefox would want to ship when it packages NSS, especially on non-Linux platforms. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
