Kamil Dudka wrote:
> On Friday, June 27, 2014 16:22:21 Kai Engert wrote:
>> On Tue, 2014-03-18 at 13:40 +0100, Kamil Dudka wrote:
>>>> - in CreateObject with CKO_PRIVATE_KEY, don't reset
>>>> the nickname back to filename contents, seems wrong
>>> As already discussed off-list, the above line was added on purpose to
>>> (or work around?) a real bug:
>>> It might be no longer necessary with up2date versions of packages using
>>> NSS, but we should be careful when removing the line. In particular, we
>>> should double-check that the patch in question does not reintroduce the
>>> above bug.
>> Ok, thanks, I've added it back:
>> If I understand correctly, all nicknames in PEM must be unique. But the
>> code doesn't attempt to enforce them to be unique. Instead, the code
>> simply hopes that using the full path of a nickname will be unique.
>> It would be better to have code that looks at the list of existing
>> nicknames, and if a duplicate exists, modifies the nickname (e.g. by
>> appending a number, and increasing the number), until a unique nickname
>> is found.
>> Do you agree?
> I do not know whether nss itself requires the nicknames to be unique but
> up2date libcurl has no assumptions about the nicknames assigned by
What does it mean to have the same cert/key in different tokens? If the
paths are the same, then shouldn't the existing token just be used? I
think that was on my mind, if not actually implemented.
I think it was implemented to use base names of files as nicknames, which
caused nickname collisions in libcurl-based applications. As a workaround,
we changed it to use full paths (because we could not change the API on an
already released product).
The problem was that subsequent accesses to a file with the same name can
give us different content each time anyway. Hence, libcurl code was later
changed to select client certificates from files by DER, instead of using