On Sat, 2016-11-05 at 13:16 +0100, Matthias B. wrote:
>
>
> int rc = 0;
>
> PKCS11_CTX *pkcs11_ctx;
>
> pkcs11_ctx = PKCS11_CTX_new();
>
> PKCS11_CTX_init_args(pkcs11_ctx,
> "configdir='C:/Users/Username/AppData/Roaming/Mozilla/Firefox/Profiles/5wzkdcjx.default'
> certPrefix='' key
On Thu, 2016-11-03 at 13:41 +0100, Matthias B. wrote:
> Thanks ro reply and thanks for the information, but is there a way to
> access the NSS (shared) Database with OpenSSL in C++? The Code you
> told me is using the binary files. So first i want a solution for
> accessing it in C++-Code. Is it po
On Wed, 2016-11-02 at 16:57 -0700, Opa114 wrote:
> Is it possible to access (read & write) the NSS (shared) Database
> (cert8.db & cert9.db) with OpenSSL? I mainly use OpenSSL, but now i
> need access to the NSS Databases and i don't want to use both
> libraries - NSS and OpenSSL - at the same time
e same code,
duplicated in PK11_FindCertsFromNickname() and
PK11_FindCertFromNickname() with the occasional bug fix applied to one
but not the other. I fixed that already in my tree and will submit that
cleanup separately. Again, I didn't want Varun doing the same thing
with the equivalent Fr
From: David Woodhouse
This is based very heavily on p11-kit/uri.c as of commit e49fba714
(which was 2 years ago in 2014, but it hasn't actually changed since
then. And even then it was only being tweaked to accommodate minor
changes between the I-D and the final release of RFC7512).
Sinc
From: David Woodhouse
Is this really worth the complexity? It's a *lot* of complexity on
the providing side, to remove a *small* amount of complexity (having
to free the string) on the calling side. And it loses the flexibility
of being able to specify the URI type too.
---
cmd/cer
From: David Woodhouse
The result must be freed by calling P11URI_FreeString()
---
cmd/certutil/certutil.c | 3 +++
lib/nss/nss.def | 1 +
lib/pk11wrap/pk11pub.h | 2 ++
lib/pk11wrap/pk11slot.c | 18 ++
4 files changed, 24 insertions(+)
diff --git a/cmd/certutil
On Mon, 2016-08-15 at 15:23 +0100, David Woodhouse wrote:
>
> Obviously I've added nothing that *uses* this yet; Varun is currently
> working on tidying that up for submission as part of his GSoC project.
Here's the first use of it, and a request for opinions...
The
urce);
+PORT_Free(uri->pin_value);
+PORT_Free(uri);
+}
diff --git a/lib/p11uri/p11uri.h b/lib/p11uri/p11uri.h
new file mode 100644
index 000..986724b
--- /dev/null
+++ b/lib/p11uri/p11uri.h
@@ -0,0 +1,119 @@
+/*
+ * Copyright (c) 2011 Collabora Ltd.
+ *
+ * Redistribution and us
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
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
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 th
g. Just
like it's trivial with GnuTLS and relatively easy with OpenSSL (now
that I've mostly fixed OpenSSL's ENGINE_PKCS11).
> Anyway, I have digressed quite a bit from the PKCS#11 URI subject at
> this point, so I will stop.
I don't think you really have — it cut
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
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 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, 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, 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-fa
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
>
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 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 sh
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
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
> 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,
>
e. But I still find myself wondering why
the PK11_FindCertsFrom*() functions even *noticed* this issue. We
should apply the filter *before* building up the results in a
collection, surely?
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com
On Tue, 2016-03-01 at 17:09 +, David Woodhouse wrote:
> I have a promising GSoC candidate who is interested in working on bug
> 1162897 (RFC7512 URI support¹), and potentially also on bug 248722
> (honour the system-wide configuration for PKCs#11 modules, when it
> exists²).
&g
NSS.
This is obviously not the ideal solution; let's make NSS play nicely
too :)
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
¹ https://bugzilla.mozilla.org/show_bug.cgi?id=1162897
²
ite* what the OP had in mind. Although the OP
didn't say that they were using Fedora. And other Linux distributions
have been slow to catch up with fixing the one-CA-database-per-library
insanity. (Debian has had update-ca-certificates for ages but it's
never actually
a PKCS#11 URI into their config
files. But as things stand, I think we'd actually have to patch *each*
application to use a different lookup function. They'll almost
certainly do precisely the same thing that was apparently undesirable
for NSS to do for itself — if it's a valid PKCS#11 UR
On Mon, 2015-07-27 at 18:34 +0200, Trick, Daniel wrote:
> Thanks for your reply, Bob!
>
> You said:
> > When you need fine grain control, the application should use
> > issuer/serial number to identify the cert (I think all the mozilla
> > apps have gone to this now)
>
> Well, I agree that it /
On Tue, 2015-05-12 at 10:17 -0700, Ryan Sleevi wrote:
> On Tue, May 12, 2015 9:44 am, Peter Bowen wrote:
> > How about an even simpler solution? Don't have p11-kit load the
> > PKCS#11 modules, just provide a list of paths and let the application
> > pass those to NSS. That way the applicatio
On Mon, 2015-05-11 at 11:21 -0700, Ryan Sleevi wrote:
> It's not simply sufficient to load module X into Chrome or not. p11-kit's
> security model is *broken* for applications like Chrome, at least with
> respect to how you propose to implement.
I've proposed at least four different options and as
On Mon, 2015-05-11 at 11:24 -1000, Brian Smith wrote:
>
> Said differently, there is nothing special about Linux. Just as Firefox
> intentionally doesn't use Windows's central certificate trust database on
> Windows, and just as it doesn't use Mac OS X's central certificate trust
> database on Mac
On Sun, 2015-05-10 at 12:47 -0700, Ryan Sleevi wrote:
>
> - Don't load a module unless the user has explicitly asked or configured
> that module to be loaded.
> - Do not patch NSS to load modules outside of the explicitly requested
> modules.
Quite right; that's absolutely how we should behave.
On Sun, 2015-05-10 at 13:50 -0700, Ryan Sleevi wrote:
> On Sun, May 10, 2015 12:57 pm, David Woodhouse wrote:
> > On Sun, 2015-05-10 at 12:47 -0700, Ryan Sleevi wrote:
> > > If the user requests NSS to load a module. It should load that module.
> > > And that module
On Sun, 2015-05-10 at 12:47 -0700, Ryan Sleevi wrote:
> If the user requests NSS to load a module. It should load that module.
> And that module only. Period.
The canonical per-user way to request an application to load a module is
for me to create a file in ~/.config/pkcs11/modules/*.module which
On Sun, 2015-05-10 at 12:11 -0700, Ryan Sleevi wrote:
> On Sat, May 9, 2015 3:30 pm, David Woodhouse wrote:
> > > No, you should be able to do it w/o patching NSS.
> >
> > OK... how?
> >
> > If the Shared System Database wasn't such an utter failure, n
On Sun, 2015-05-10 at 12:07 -0700, Ryan Sleevi wrote:
> On Sat, May 9, 2015 3:30 pm, David Woodhouse wrote:
> > On Fri, 2015-05-08 at 15:07 -0700, Ryan Sleevi wrote:
> > > Yes, it should. You'll introduce your users to a host of security issues
> > > if you ignore
On Fri, 2015-05-08 at 15:00 -0700, Ryan Sleevi wrote:
> On Fri, May 8, 2015 6:09 am, David Woodhouse wrote:
> > On Linux distributions it *is* the platform's
> > mechanism of choice for configuring PKCS#11 tokens. NSS needs to
> > support it if it wants to integrate
On Fri, 2015-05-08 at 15:07 -0700, Ryan Sleevi wrote:
> On Fri, May 8, 2015 5:38 am, David Woodhouse wrote:
> > These days it does. Modern systems ship with p11-kit², which exists
> > precisely to fill that gap and provide "a standard discoverable
> > configura
On Fri, 2015-05-08 at 15:23 +0200, Wouter Verhelst wrote:
> On 08-05-15 15:09, David Woodhouse wrote:
> > On Fri, 2015-05-08 at 14:58 +0200, Wouter Verhelst wrote:
> > > In light of that, it would be great if firefox/libnss were to
> > > allow
> > > configu
On Fri, 2015-05-08 at 14:58 +0200, Wouter Verhelst wrote:
> In light of that, it would be great if firefox/libnss were to allow
> configuration of PKCS#11 modules externally -- not just on Linux,
> but on OSX and Windows too.
Well, p11-kit does build on OSX and Windows too but it doesn't have
th
le in all applications.
We may wish to give some consideration to how that would work when it
is being loaded into an NSS application which might have its own
database in another directory (some broken applications like Firefox
still don't use ~/.pki/nssdb ☹) or indeed in the *same* dir
On Tue, 2015-05-05 at 09:47 -0700, Ryan Sleevi wrote:
> On Tue, May 5, 2015 8:55 am, David Woodhouse wrote:
> > I'm talking about the serial numbers of the certs issued *by* the two
> > "My CA"s.
>
> Good to have that clarification :)
>
> Differen
On Tue, 2015-05-05 at 12:29 +0100, Alan Braggins wrote:
> On 04/05/15 21:53, David Woodhouse wrote:
> > > On Mon, May 4, 2015 1:25 pm, David Woodhouse wrote:
> > > > Surely that's not unique? Using the above example, surely the first
> > > > certific
> On Mon, May 4, 2015 1:25 pm, David Woodhouse wrote:
>> Surely that's not unique? Using the above example, surely the first
>> certificate issued by the 2010 instance of 'My CA', and the first
>> certificate issued by the 2015 instance, are both going
On Mon, 2015-05-04 at 09:21 -0700, Robert Relyea wrote:
> So in NSS, CKA_LABEL is simply a short cut to CKA_SUBJECT. That is NSS
> looks up a cert from the nickname and picks all the certs that match
> that cert's subject.
Hm... so if I have two certificates; one with:
CKA_SUBJECT: "My CA"
C
On Sat, 2015-05-02 at 18:33 -0700, Jan Pechanec wrote:
> On Fri, 1 May 2015, David Woodhouse wrote:
>
> >On Fri, 2015-05-01 at 11:35 +0100, Alan Braggins wrote:
> >> On 30/04/15 17:56, David Woodhouse wrote:
> >> > Has anyone looked at implementing RFC7512 support
On Fri, 2015-05-01 at 11:35 +0100, Alan Braggins wrote:
> On 30/04/15 17:56, David Woodhouse wrote:
> > Has anyone looked at implementing RFC7512 support, allowing an object
> > to be specified by a PKCS#11 URI?
> I don't suppose you know why RFC 7512 uses CKA_ID but not C
Has anyone looked at implementing RFC7512 support, allowing an object
to be specified by a PKCS#11 URI?
I can now do this with both GnuTLS and OpenSSL, and it would be good
to get NSS fixed too.
I'd also very much like NSS to be able to load the default PKCS#11
tokens listed in the system's p11-k
On Tue, 2015-01-13 at 12:25 -0500, John Dennis wrote:
> On 01/13/2015 09:58 AM, Robert Daniels wrote:
> > I also need to serialize private keys in the same fashion. Any hints
> greatly appreciated.
>
> By design NSS prohibits access to private keys therefore you cannot
> serialize private keys.
On Tue, 2014-12-09 at 14:18 +, Martinsson Patrik wrote:
>
> > It's cute that GNOME keyring can provide PKCS#11 functionality and you
> > can store certificates and keys in there. But you aren't *using* that
> > functionality. So just unregister the module entirely by deleting its
> > file from
On Tue, 2014-12-09 at 14:18 +, Martinsson Patrik wrote:
> On Tue, 2014-12-09 at 13:54 +0000, David Woodhouse wrote:
> > On Tue, 2014-12-09 at 13:15 +, Martinsson Patrik wrote:
> > > So, If I don't have opensc-module, one way or another in
> > > (sql)
On Tue, 2014-12-09 at 13:15 +, Martinsson Patrik wrote:
> So, If I don't have opensc-module, one way or another in
> (sql):/etc/pki/nssdb I will loose all functionality that gsd brings me,
> for example "lock screen at card removal".
Not sql:/etc/pki/nssdb; this is another one that that uses
On Mon, 2014-12-08 at 13:56 -0800, Robert Relyea wrote:
> On 12/08/2014 08:59 AM, David Woodhouse wrote:
> > I still maintain that the path to sanity involves killing
> > /etc/pki/nssdb entirely, and then you can look at applying *correct*
> > fixes to whatever's st
On Mon, 2014-12-08 at 13:53 -0800, Robert Relyea wrote:
> Nothing in the above paragraph is true.
>
> openning
> 1)sql:/etc/pki/nssdb is *STILL* the recommended action for applications
> (whether or not nssysinit is installed), and
"Recommended" in the sense of "do as I say, not as I do", of cou
On Mon, 2014-12-08 at 16:44 +, Martinsson Patrik wrote:
> Well,not really, it turns out that the gnome-settings-daemon loads the
> opensc-module directly from /etc/pki/nssdb. So if I don't import the
> opensc-module in there, gnome-settings-daemon wont recognize
> inserts/removals. I choosed to
On Mon, 2014-12-08 at 13:05 +, David Woodhouse wrote:
> If you fix the unlock-at-login issue then you shouldn't have to disable
> this in any application for which there isn't already a "Does not
> support Protected Authentication Path" bug filed. I.e. evolution.
On Mon, 2014-12-08 at 10:15 +, Martinsson Patrik wrote:
> So, to summarize,
> $> sudo update-alternatives --install /usr/lib64/libnssckbi.so
> libnssckbi.so.x86_64 /usr/lib64/p11-kit-proxy.so 1000
>
> $> cat /etc/pki/nssdb/pkcs11.txt
> library=/usr/lib64/p11-kit-proxy.so
> name=p11-kit-proxy
On Thu, 2014-12-04 at 22:25 +, Martinsson Patrik wrote:
>
> Maybe I should have been clearer from the beginning, it was actually
> just pam_pkcs11 that didn't automatically picked up my CA, sorry if it
> got confusing.
OK, and I suppose that makes sense. Because pam_pkcs11 doesn't *want* to
b
On Thu, 2014-12-04 at 10:33 -0800, Robert Relyea wrote:
>
> > That one. libnssckbi.so is what provides the default trust roots. It's
> > *always* supposed to be loaded in an NSS system. You shouldn't need to
> > add it manually. I don't.
> Huh? that is not true. libnssckbi.so is loaded by nssysini
On Thu, 2014-12-04 at 11:31 +, David Woodhouse wrote:
>
> That one. libnssckbi.so is what provides the default trust roots. It's
> *always* supposed to be loaded in an NSS system. You shouldn't need to
> add it manually. I don't.
... except in the specific case whe
h a thing is even possible.
Further discussion of that might be more appropriately targeted to the
OpenSC mailing list, since pam_pkcs11 is theirs too.
In the meantime, given the bug that libnssckbi.so doesn't seem to show
up for you unless explicitly requested, a potential workaround might
On Tue, 2014-12-02 at 20:30 +, David Woodhouse wrote:
> On Tue, 2014-12-02 at 19:59 +0000, David Woodhouse wrote:
> >
> > That doesn't happen here on F21, FWIW.
> >
> > Firefox only asks me to log into my p11-kit-provided hardware tokens
> > when I go t
On Tue, 2014-12-02 at 19:59 +, David Woodhouse wrote:
>
> That doesn't happen here on F21, FWIW.
>
> Firefox only asks me to log into my p11-kit-provided hardware tokens
> when I go to a web site which wants a certificate, which is fair
> enough.
>
> And I have
On Tue, 2014-12-02 at 18:24 +, Martinsson Patrik wrote:
>
> I quickly tried to import libp11-proxy.so in the users nssdb (and
> in .mozillas) and it worked as expected. However, since all my
> "keyrings" (?) now are in the slots, evolution (and chrome/ff etc) now
> asks me for passwords to
On Tue, 2014-12-02 at 18:24 +, Martinsson Patrik wrote:
> So here's a round of new questions,
>
> - There are different ways of loading pkcs11-modules into an application
> where nss is one and p11-kit is another. And where p11-kit is a library
> that an application can link to, and where ns
On Tue, 2014-12-02 at 12:00 -0500, Miloslav Trmač wrote:
> > Great. So that should solve Patrik's CA issues without needing to do
> > anything special. All that remains is to get the smartcards working by
> > loading p11-kit-proxy.so (or preferably the individual modules) too.
> >
> > Is that some
On Tue, 2014-12-02 at 11:16 -0500, Miloslav Trmač wrote:
> Hello,
> > It has largely been superseded by p11-kit-trust, which in the NSS case
> > provides a replacement for libnssckbi.so and gives us consistency across
> > the entire system regardless of the crypto libraries in use. (This
> > wasn't
On Mon, 2014-12-01 at 17:22 -0800, Robert Relyea wrote:
>
> This is still the issue with nsssysinit. It currently only works if the
> the application open sql:/etc/pki/nssdb. Currently firefox doesn't even
> use the sql database.
Which has always been a bit of a facepalm realisation: "Hey... we
On Mon, 2014-02-03 at 12:13 +, Alan Braggins wrote:
>
> Having support for PKCS#11 tokens at all is a pro, even if one
> irrelevant to the vast majority of users.
That gets less true as we start to use PKCS#11 a little more. It isn't
*just* about hardware tokens — things like gnome-keyring of
On Mon, 2013-06-17 at 10:58 -0700, Chris Newman wrote:
> I'll mention one other usability issue. I am getting pressure from my
> employer to stop using NSS due to the MPL 2 license. I got less
> pressure when I could use NSS under the LGPL 2.1 branch of the
> tri-license. Switching to OpenSSL has
On Tue, 2013-02-26 at 17:05 -0500, Robert Relyea wrote:
> Whether or not ECC works is a function of the version of NSS you have.
> If built by Mozilla, ECC works for signature verification and client
> auth out of the box. The NSS built by red hat will not do any ECC
> unless you supply your own EC
On Wed, 2012-08-01 at 11:58 +0200, Anders Rundgren wrote:
> http://www.finextra.com/news/announcement.aspx?pressreleaseid=45624
>
> Current platforms are useless for banking so what else could they do?
The big problem with the VbV insanity wasn't the current platforms. It
was largely the user exp
On Fri, 2012-07-27 at 12:07 -0700, Robert Relyea wrote:
> The news to me is that applications care, which means I need to
> figure out an api to give the application that information.
The applications actively don't *want* to care, but the existing
interface by which they use the shared system d
On Fri, 2012-07-27 at 10:08 -0700, Robert Relyea wrote:
> Oh, so you switch between sql:/etc/pki/nssdb and sql:$HOME/.pki/nssdb=20
> depending on whether libnsssysinit.so exists.
It's worse than that. It's not just whether libnsssysinit.so *exists*,
but whether it's actually loaded by a line in /e
On Fri, 2012-07-27 at 10:53 +0200, Anders Rundgren wrote:
> I think you need to take a step back and consider which
> market and user-base you are targeting.
No, I believe that's been clear from the beginning. Apologies if I
didn't make it explicit enough.
> Linux on the desktop? Why bother with
On Thu, 2012-07-26 at 14:13 -0700, Robert Relyea wrote:
> Error verifying signature
> parse error
> --ms050908010406000106010405
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: quoted-printable
(Want to investigate that off-list, or is it expe
On Thu, 2012-07-26 at 14:00 +0200, Anders Rundgren wrote:
> On 2012-07-26 12:24, David Woodhouse wrote:
>
> >
> >> My same concerns would apply to private keys.
> >
> > An application-specific 'third slot' would certainly address that
> >
On Wed, 2012-07-25 at 18:03 -0700, Julien Pierre wrote:
> It is questionable to me that the trust should actually be shared for
> all applications running under the same user.
It's *not* "applications". It's *purposes".
So let me rephrase that: it's questionable (in fact, it's definitely
*not* t
On Wed, 2012-07-25 at 22:05 +0200, Anders Rundgren wrote:
> Apple will embed security HW directly in the CPU and there will be
> no need for any third-party middleware. It will just work.
I believe the first Intel Apple laptops had a TPM. It was dropped fairly
quickly, and current models don't ha
On Wed, 2012-07-25 at 08:59 +0200, helpcrypto helpcrypto wrote:
>
> You are asking for: (paths are just for example purposes)
> a) To set up a $HOME/nss to store user certs + trusted by the user
> (actually more/less what already have). Doesnt Chrome use something
> like that already?
> b) To se
On Wed, 2012-07-25 at 08:33 +0200, Anders Rundgren wrote:
> I think the lack of progress [*] here has a lot to do with the fact that
> there's really nothing to gather around. Making security solutions
> for security-conscious people is probably quite fun but since this
> only addresses a tiny fra
On Tue, 2012-07-24 at 16:12 +0200, Anders Rundgren wrote:
> IMO, this is not an NSS issue, it is rather a *NIX issue. All other
> operating systems (that I'm aware of NB...) including *NIX-derivates
> like Android, already have a system-wide cryptographic architecture.
Yes. It's an issue I'm acti
lots available. Is that possible?
Again, if we switch things around so that you just load
sql:/$HOME/.pki/nssdb and the additional slot is automatically loaded
from /etc/pki/nssdb *if* a database exists there, this may all "just
work"... is that something we can consider?
--
Dav
86 matches
Mail list logo
