> 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.
Please could you explain the breakage? This should only change behaviour if you provide a "nickname" which happens to be a valid PKCS#11 URI to the PK11_FindCertFromNickname() function. Does Chrome do that, and depend on the failure that it gets? Otherwise, how could anything break? > 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. I can live with that. On platforms without p11-kit, the functions can be absent or stubs which return failure. -- dwmw2 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
