On 04/07/2016 05:13 PM, Julien Pierre wrote:
David,
On 4/7/2016 15:49, David Woodhouse wrote:
On Thu, 2016-04-07 at 05:01 -0700, Julien Pierre wrote:
The problem really stems from the design of NSS, specifically the
CERTCertificate*, which maps to a unique DER encoded cert, but not to
a single
On 04/07/2016 03:49 PM, David Woodhouse wrote:
On Thu, 2016-04-07 at 05:01 -0700, Julien Pierre wrote:
The problem really stems from the design of NSS, specifically the
CERTCertificate*, which maps to a unique DER encoded cert, but not to
a single PKCS#11 object in a single token. Since the same
On Thu, 2016-04-07 at 17:13 -0700, Julien Pierre wrote:
> > Hm, I thought PK11_ListCerts tried to eliminate duplicates too, which
> > is why it has that crappy O(n²) behaviour? Does it *really* return more
> > than one of the 'same' certificate? Don't you *still* get a randomly-
> > chosen one with
David,
On 4/7/2016 15:49, David Woodhouse wrote:
On Thu, 2016-04-07 at 05:01 -0700, Julien Pierre wrote:
The problem really stems from the design of NSS, specifically the
CERTCertificate*, which maps to a unique DER encoded cert, but not to
a single PKCS#11 object in a single token. Since the s
On Thu, 2016-04-07 at 05:01 -0700, Julien Pierre wrote:
> The problem really stems from the design of NSS, specifically the
> CERTCertificate*, which maps to a unique DER encoded cert, but not to
> a single PKCS#11 object in a single token. Since the same cert can
> exist in multiple tokens, but th
David,
Responses inline.
- Original Message -
> It certainly makes sense to add a new function which can locate objects
> *purely* by their PKCS#11 URI. And if I can spend a little time trying
> to properly understand the reasons you currently eschew
> PK11_FindCertsFromNickname(), perhap
On Wed, 2016-04-06 at 16:09 -0700, Julien Pierre wrote:
> David,
>
> On 4/6/2016 05:57, David Woodhouse wrote:
> > ... all this is mostly solved. You can use any or all of CKA_CLASS,
> > CKA_ID and CKA_LABEL to identify the objects you want to use.
>
> Except that CKA_ID does not uniquely identify
David,
On 4/6/2016 05:57, David Woodhouse wrote:
I also want to mention that there are some fairly major deficiencies in
NSS when it comes to finding certificates. The nickname only represents
a subject. It does not uniquely identify a certificate. Even
token:nickname - which is really token:su
On Tue, 2016-04-05 at 17:27 -0700, Julien Pierre wrote:
> The API itself may not have been documented, but products using the API
> have documented this token:nickname usage. That is the case for some
> Oracle server products. Now, I can't say that we really envisioned
> anyone entering a URI in
The API itself may not have been documented, but products using the API
have documented this token:nickname usage. That is the case for some
Oracle server products. Now, I can't say that we really envisioned
anyone entering a URI in the nickname field of our server config files.
It would certain
On 04/04/2016 03:19 PM, Ryan Sleevi wrote:
On Mon, Apr 4, 2016 at 12:39 PM, David Woodhouse wrote:
We usually reserve the term "breaks the API" for when something *used*
to work, and now doesn't. Not when a previously-failing call now
actually does something useful.
No, sorry David, that's not
On Tue, 2016-04-05 at 12:49 -0400, John Dennis wrote:
>
> If the API does not have documented behavior constraints then you can't
> be causing a API breakage.
I think that's overstating the case a little.
Even if the behaviour is undocumented, if real applications are
depending on it in anythin
One of the problems I have with the argument Ryan presents concerning
API contracts and breakage is that "API contract" Ryan talks about is to
the best of my knowledge undocumented, it's a API "convention" observed
by a select group of developers "in the know". I don't see anything
about a toke
On Tuesday 05 April 2016 07:26:56 Ryan Sleevi wrote:
> On Tuesday, April 5, 2016, Hubert Kario wrote:
> > On Monday 04 April 2016 12:17:08 Ryan Sleevi wrote:
> > > On Mon, Apr 4, 2016 at 11:32 AM, David Woodhouse
> > > >
> > I'm sorry Ryan, but I also don't see how this would break API.
>
> Doe
On Mon, 2016-04-04 at 16:23 -0700, Ryan Sleevi wrote:
>
> I understand and appreciate that you want the standard to be "Show me
> the code." But that's not the standard we set.
Not at all. I fully appreciate that just because you can't provide any
specific failure mode doesn't mean that no such f
On Tuesday, April 5, 2016, Hubert Kario wrote:
> On Monday 04 April 2016 12:17:08 Ryan Sleevi wrote:
> > On Mon, Apr 4, 2016 at 11:32 AM, David Woodhouse >
> 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
On Monday 04 April 2016 12:17:08 Ryan Sleevi wrote:
> On Mon, Apr 4, 2016 at 11:32 AM, David Woodhouse
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
On Mon, Apr 4, 2016 at 4:09 PM, David Woodhouse wrote:
> I'm perfectly happy to entertain the notion of adding new functions for
> PK11_FindCertsFromURI() (et al.), but I was looking for *real*
> information about whether it was actually necessary. Which you don't
> seem to be able to provide with
On Mon, 2016-04-04 at 16:04 -0700, Ryan Sleevi wrote:
>
> I've already tried to explain this several times to you. I don't feel
> there's anything more useful to contribute.
Very well. From my point of view it seems that you have offered straw
men, and talked about what would happen if NSS starte
On Mon, Apr 4, 2016 at 3:53 PM, David Woodhouse wrote:
> Of course it's an API change. But as noted, it's an API *addition*, in
> that it makes something work that didn't before.
>
> The criterion for such additions should be "if it isn't a *bad* thing
> for that to start working".
>
> What's miss
On Mon, 2016-04-04 at 15:49 -0700, Ryan Sleevi wrote:
> I appreciate your argument "but user provided!", but you seem to be
> missing the core point - you're changing the syntax of an API's
> arguments, in a way that breaks the previously-held pre and post
> conditions. That's an API change.
>
> I
On Mon, Apr 4, 2016 at 3:45 PM, David Woodhouse wrote:
> That won't change. Unless you explicitly use a new function that
> provides a URI instead of a nickname, of course.
>
> You will *only* get a URI from direct user input, in a situation where
> a user could already feed you any kind of nonsen
On Mon, 2016-04-04 at 15:19 -0700, Ryan Sleevi wrote:
> On Mon, Apr 4, 2016 at 12:39 PM, David Woodhouse wrote:
> >
> >
> > We usually reserve the term "breaks the API" for when something *used*
> > to work, and now doesn't. Not when a previously-failing call now
> > actually does something usef
On Mon, Apr 4, 2016 at 12:39 PM, David Woodhouse wrote:
>
> We usually reserve the term "breaks the API" for when something *used*
> to work, and now doesn't. Not when a previously-failing call now
> actually does something useful.
No, sorry David, that's not how we've done stuff in NSS.
When it
On Mon, 2016-04-04 at 12:17 -0700, Ryan Sleevi wrote:
>
> 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 t
On Mon, 2016-04-04 at 12:21 -0700, Ryan Sleevi wrote:
> On Mon, Apr 4, 2016 at 11:32 AM, David Woodhouse wrote:
> >
> > I don't see it. I still don't see *any* way for you to get a PKCS#11
> > URI anywhere in the memory space of your application, unless you
> > specifically ask for one with a new
On Mon, Apr 4, 2016 at 11:32 AM, David Woodhouse wrote:
> I don't see it. I still don't see *any* way for you to get a PKCS#11
> URI anywhere in the memory space of your application, unless you
> specifically ask for one with a new API — or unless you take untrusted
> input from the user or an edi
On Mon, Apr 4, 2016 at 11:32 AM, David Woodhouse 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 v
On Mon, 2016-04-04 at 08:23 -0700, Ryan Sleevi wrote:
> This is, of course, demonstrably false. One can no longer filter the inputs
> to this API if your change is accepted, because the format will have
> changed. For example, colon no longer becomes the separator between the
> token and the nickna
On Monday, April 4, 2016, David Woodhouse wrote:
>
> I didn't call you a liar. I simply said that I can't see how the
> statement you made could be anything but false. There are plenty of
> reasons that could be the case — including my own ignorance — which
> don't involve you telling a deliberat
On Mon, 2016-04-04 at 07:48 -0700, Ryan Sleevi wrote:
>
> On Apr 4, 2016 7:15 AM, "David Woodhouse" wrote:
> >
> > Ryan?
> >
> > Unless you are able to provide an explanation of how this would "break
> > Chrome's use of the API", I shall continue to assume that your
> > statement was false, and d
On Apr 4, 2016 7:15 AM, "David Woodhouse" wrote:
>
> Ryan?
>
> Unless you are able to provide an explanation of how this would "break
> Chrome's use of the API", I shall continue to assume that your
> statement was false, and design accordingly.
>
> I certainly can't see how it could have any basi
On Thu, 2016-03-17 at 15:18 +, David Woodhouse wrote:
>
> > 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
> > (filte
As Varun ramps up for the potential GSoC project on implementing URI
support, I'd really like to get some consensus on the implementation
details — there is at least one choice which needs to be made, which
will affect his development from day one.
As discussed in https://bugzilla.mozilla.org/1162
On 03/17/2016 10:52 AM, Ryan Sleevi wrote:
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.
Could you clarify this statement
On Thursday, March 17, 2016, John Dennis wrote:
> On 03/17/2016 10:52 AM, Ryan Sleevi wrote:
>
>> 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 decisio
On Thursday, March 17, 2016, David Woodhouse 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" pis
> 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,
>
38 matches
Mail list logo
