There’s a lot going on here.
1) The discussion about /etc/pki/tls/cert.pem and ca-certificates belongs
with your distro
2) Assuming your distro ships the Mozilla Root Store, which few do
correctly and successfully, the discussion about root certificates belongs
with mozilla.dev.security.policy ins
On Sat, May 25, 2019 at 2:03 AM Nisar Hassan wrote:
> Dear Team,
>
>
>
> Is there any way we can digitally sign the transaction in a web app by
> using
> the certificate stored at Firefox's key store.
>
> Best Regards,
>
> Nisar Hassan
>
> Professional Service Engineer (PKI Department)
>
> Nation
On Sat, May 25, 2019 at 2:03 AM wrote:
> Hello,
>
> we are using Firefox. But we want to deactivate the API "Web Cryptography
> API". We are using an addon for this case -> "WEB API MANAGER". Our target
> is to deactivate this setting without using an addon.
>
> Is there any possibility for our U
Hi Hubert,
Did you mean this for
https://groups.google.com/forum/#!forum/mozilla.dev.security.policy ?
On Tue, Nov 21, 2017 at 9:26 AM, Hubert Kario wrote:
> In response to comment made by Gervase Markham[1], pointing out that
> Mozilla
> doesn't have an official RSA-PSS usage policy.
>
> This
On Monday, May 22, 2017 at 3:58:21 AM UTC-4, Gervase Markham wrote:
> On 19/05/17 17:02, Ryan Sleevi wrote:
> > I support both of those requirements, so that we can avoid it on a
> > 'problematic practices' side :)
>
> But you think this should be a policy
I support both of those requirements, so that we can avoid it on a
'problematic practices' side :)
There's a webcompat aspect for deprecation - but requiring RFC-compliant
encoding (PKCS#1 v1.5) or 'not stupid' encoding (PSS) is a good thing for
the Web :)
On Fri, May 19, 2017 at 9:57 AM, Gervase
Apologies, autocompleted to the wrong list :)
On Thu, Apr 27, 2017 at 10:51 AM, Ryan Sleevi wrote:
> (Wearing a Google Hat, if only to share what has transpired)
>
> Symantec has recently shared in https://www.symantec.com/
> connect/blogs/symantec-ca-proposal , as wel
(Wearing a Google Hat, if only to share what has transpired)
Symantec has recently shared in
https://www.symantec.com/connect/blogs/symantec-ca-proposal , as well as
https://groups.google.com/d/msg/mozilla.dev.security.policy/LRvzF2ZPyeM/OpvBXviOAQAJ
, a plan for what they believe is an appropriat
On Tue, Mar 7, 2017 at 3:28 PM, Rob Crittenden wrote:
> SSL_BYPASS_PKCS11 is marked as deprecated in ssl.h. What are the plans
> on removing it?
>
>
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.28_release_notes
https://bugzilla.mozilla.org/show_bug.cgi?id=1303224
--
dev-te
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
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, 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, 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, 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, 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 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 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 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 - tha
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
On Tue, January 19, 2016 2:56 pm, s...@gmx.ch wrote:
> Hi
>
> We're already having some discussions about SHA-1, but I'll split this
> up into a new thread.
>
> The initial goal of bug 942515 was to mark certs as insecure, that are
> valid 'notBefore >= 2016-01-01' (means issued to use in 2016
The NSS Development Team announces the release of NSS 3.19.2
Network Security Services (NSS) is a patch release for NSS 3.19.
No new functionality is introduced in this release. This release addresses
a backwards compatibility issue with the NSS 3.19.1 release.
Notable Changes:
* In NSS 3.19.1,
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 application can choose to
> transparently load modules without user int
On Mon, May 11, 2015 4:09 am, David Woodhouse wrote:
> I completely agree that Chrome should only ever load the modules which
> are configured to be loaded into Chrome. I'm surprised you feel the
> need to mention that.
Because you still don't understand, despite how many ways I'm trying to
say
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 only. Period.
>
> The canonical per-user way to request an applicatio
On Sun, May 10, 2015 12:31 pm, David Woodhouse wrote:
> > You don't need to expose it to the sandbox to use PKCS#11 in the web
> > browser. That's not how modern sandboxed browsers work.
>
> That sounds like a bit of a failure of the sandboxing to me. Just so I
> understand what you're saying...
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, not even
> being used by Firefox itself, then just installing it there would have
> been a nice idea. But *not
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 them (especially for situations like Chrome). For example,
> > if y
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
> configuration for installed PKCS#11 modules."
Your citation ( http://p11-glue.freedesktop.org/p11-kit.ht
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 with the platform properly.
I'm sorry to continually push back on this, but you continue t
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 :)
Different CAs (in as much as different public keys), but with the same
DER-encoded subject name (not necessarily the same DE
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 to have
> identical CKA_ISSUER and CKA_SERIAL_N
On Mon, March 16, 2015 1:06 pm, Erwann Abalea wrote:
>
> Phase RSA1024 out? I vote for it. Where's the ballot? :)
This is a browser-side change. No ballot required (the only issue *should*
be non-BR compliant certificates issued before the BR effective date)
https://code.google.com/p/chromium/is
On Mon, March 16, 2015 10:24 am, Erwann Abalea wrote:
> Le lundi 16 mars 2015 10:29:08 UTC+1, Kurt Roeckx a écrit :
> > On 2015-03-14 01:23, kim@safe-mail.net wrote:
> > > Is there an agreed timeline for deprecation of the technologies listed
> > in the initial posting? We should be proactive
On Sat, March 7, 2015 12:20 pm, kim.da...@safe-mail.net wrote:
> Looking for comments about feasibility of breaking-up Firefox
> TLS/SSL-handling code into easily-removable sections.
>
> I want to fully separate NSS code from code that handles:
>
> 1) MD5 signature handling
>
> 2) SHA1 signatu
On Sun, February 15, 2015 3:07 pm, Hanno Böck wrote:
> Unfortunately the code never got fully merged. Right now the state is
> that code for the basic functions exists in freebl, but all upper layer
> code is not merged. I think if I remember correctly the code currently
> in freebl will also
On Tue, November 11, 2014 10:26 am, Nicholas Nethercote wrote:
> On Mon, Nov 10, 2014 at 7:06 PM, Ryan Sleevi
> wrote:
> >
> > Not to be a pain and discourage someone from hacking on NSS
>
> My patches are in the following bugs:
>
> https://bugzilla.mozil
On Mon, November 10, 2014 6:51 pm, Nicholas Nethercote wrote:
> Hi,
>
> I've been doing some heap allocation profiling and found that during
> basic usage NSS accounts for 1/3 of all of Firefox's cumulative (*not*
> live) heap allocations. We're talking gigabytes of allocations in
> short brow
On Fri, August 29, 2014 8:43 am, Gervase Markham wrote:
> On 28/08/14 17:20, Camilo Viecco wrote:
> > 1. The PKP-RO header is not really useful, it might help on initial
> > deployment of PKP but it cannot really be tested when it really matters
> > most when you are actually changing certificates
On Wed, July 16, 2014 11:42 pm, Falcon Darkstar Momot wrote:
> When it comes to key material, it's an outstanding idea to err on the
> side of caution.
>
> Does anyone actually require this feature in a non-debug build? If not,
> then it's completely unreasonable to leave it in such builds, ev
On Tue, July 15, 2014 1:11 pm, Tom Ritter wrote:
> Is having it in by default useful enough to outweigh the risk?
>
> When the Dual_EC_DRBG news stories were blowing it, it was revealed
> that you could switch to it by just changing the Windows Registry.
> It's a Windows-supported backdoor - no
On Tue, July 15, 2014 1:11 pm, Tom Ritter wrote:
> Is having it in by default useful enough to outweigh the risk?
>
> When the Dual_EC_DRBG news stories were blowing it, it was revealed
> that you could switch to it by just changing the Windows Registry.
> It's a Windows-supported backdoor - no
On Wed, July 2, 2014 6:09 am, Bernhard Thalmayr wrote:
> Hi experts, is there a specification which NSS follows when performing
> certificate check during the SSL handshake (especially with regards to
> handling SubjectAltName extensions)?
>
> TIA,
> Bernhard
>
> P.S. Unfortunately my search
On Mon, February 3, 2014 4:30 am, David Woodhouse wrote:
> 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.
On Fri, January 31, 2014 9:18 am, Alan Braggins wrote:
> On 31/01/14 10:24, Julien Pierre wrote:
> >
> > On 1/27/2014 10:28, Kathleen Wilson wrote:
> >> Draft Design Doc posted by Ryan Sleevi regarding Chrome migrating from
> >> NSS to OpenSSL:
> >&g
On Thu, January 2, 2014 1:25 pm, Julien Vehent wrote:
> Hi Aaron,
>
> On 2014-01-02 16:10, Aaron Zauner wrote:
> > Hi Kurt,
> >
> > On 02 Jan 2014, at 21:51, Kurt Roeckx wrote:
> >
> >> On Thu, Jan 02, 2014 at 09:33:24PM +0100, Aaron Zauner wrote:
> I *think* they want to prefer CAMELLIA to
On Mon, November 25, 2013 12:06 am, ianG wrote:
> For some reason, news.google.com has been captured by *.opendns.com and
> turned into a site warning. OK, so I imagine there is a story about
> this somewhere, maybe it's just my ISP...
>
>
>
> But, imagine my surprise when I tried it on chrome
On Fri, November 1, 2013 5:30 pm, Wan-Teh Chang wrote:
> On Fri, Nov 1, 2013 at 1:28 AM, Jeff Hodges
> wrote:
> >
> > I dug through the NSS codebase and found where it was defined in
> > lib/ssl/sslproto.h as:
> >
> > /* New non-experimental openly spec'ed versions of those cipher
> > suites.
On Mon, October 7, 2013 11:07 am, Robert Relyea wrote:
> On 10/04/2013 06:52 PM, Ludovic Hirlimann wrote:
> > Hi,
> >
> > AFAIK NSS still contains code for SSL2 , but no product uses it. SSL2
> > has been turned off at least 2 years ago. By removing SSL2 code we get :
> >
> > Smaller librarie
On Fri, September 27, 2013 5:51 pm, Robert Relyea wrote:
>
>
> On 09/27/2013 05:01 PM, Ryan Sleevi wrote:
> > On Fri, September 27, 2013 4:09 pm, Eddy Nigg wrote:
> >> On 09/28/2013 01:59 AM, From Ryan Sleevi:
> >>> If your site requires a client cer
On Fri, September 27, 2013 4:09 pm, Eddy Nigg wrote:
> On 09/28/2013 01:59 AM, From Ryan Sleevi:
> > If your site requires a client certificate, and you know that a client
> > certificate is stored in a smart card, then you also know that when
> > using
> > Firefox, an
On Fri, September 27, 2013 4:09 pm, Eddy Nigg wrote:
> On 09/28/2013 01:59 AM, From Ryan Sleevi:
> > If your site requires a client certificate, and you know that a client
> > certificate is stored in a smart card, then you also know that when
> > using
> > Firefox, an
On Fri, September 27, 2013 3:46 pm, Eddy Nigg wrote:
> On 09/28/2013 12:45 AM, From Ryan Sleevi:
> > NSS already performs checking that the given smart card used to
> > authenticate is present whenever encrypting or decrypting data. This
> > includes cached session resumpt
On Fri, September 27, 2013 2:22 pm, Eddy Nigg wrote:
> On 09/27/2013 11:52 PM, From Ryan Sleevi:
> > Let me try it differently: What actions do you take on this information?
>
> Terminating a current session or triggering authentication to a new
> session.
When you define se
On Fri, September 27, 2013 1:35 pm, Eddy Nigg wrote:
> On 09/27/2013 08:52 PM, From Ryan Sleevi:
> >
> > How do you deal with this in other browsers?
>
> Well, I don't...so far :-)
>
> However I'm aware of similar capabilities with IE.
>
> >
On Fri, September 27, 2013 10:29 am, Eddy Nigg wrote:
> On 09/27/2013 08:12 PM, From Brian Smith:
> > My question is not so much "Is anybody using this functionality" but
> > rather "What really terrible things, if any, would happen if we
> > removed them?"
>
> We might have to look for alternati
The NSS team has released Network Security Services (NSS) 3.15.2, which is
a minor release.
The HG tag is NSS_3_15_2_RTM. NSS 3.15.2 requires NSPR 4.10 or newer.
Detailed release notes are available at
https://developer.mozilla.org/en-US/docs/NSS/NSS_3.15.2_release_notes and
reproduced below.
Th
On Fri, August 16, 2013 6:36 am, Rob Stradling wrote:
> On 15/08/13 18:15, Chris Richardson wrote:
> > I believe this plan would have poor side effects. For example, if Apple
> > ships clients with a broken ECDSA implementation [0], a server cannot
> > detect detect if a connecting client is an A
On Mon, July 8, 2013 12:00 pm, Rick Andrews wrote:
> I need to remove some 1024-bit roots from Firefoxs trust store, but I
> realize that these trusted roots are part of the NSS library, and that the
> NSS library is used by lots of other software, not just Firefox. Removing
> these roots may
On Wed, May 29, 2013 9:11 pm, Yoshi Huang wrote:
> On 05/28/2013 05:20 PM, Yoshi Huang wrote:
> > Hi,
> > Given that my PKCS 12 file doesn't contain any 'friendlyName'
> > attribute in it,
> > nor my certificate DB doesn't have any certificate which has the same
> > subject name with my PKCS12.
>
The NSS Development Team is pleased to announce the release of NSS 3.14.3.
The official release notes are available at
https://developer.mozilla.org/en-US/docs/NSS/NSS_3.14.3_release_notes ,
and are reproduced at the end of this message.
This release includes mitigations for recently discussed "L
On Thu, February 14, 2013 11:55 am, John Dennis wrote:
> On 02/14/2013 02:34 PM, Ryan Sleevi wrote:
> > On Thu, February 14, 2013 10:43 am, Robert Relyea wrote:
> >> On 02/14/2013 07:54 AM, David Dahl wrote:
> >>> - Original Message -
> >>>&g
On Thu, February 14, 2013 10:43 am, Robert Relyea wrote:
> On 02/14/2013 07:54 AM, David Dahl wrote:
> > - Original Message -
> >> From: "Gervase Markham"
> >> To: mozilla-dev-tech-cry...@lists.mozilla.org
> >> Cc: "Eric Rescorla", "Brian
> >> Smith", "Brendan Eich", "Ben
> >> Adida", "Bri
On Mon, December 31, 2012 10:23 am, Kai Engert wrote:
> On Mon, 2012-12-31 at 16:26 +0100, Kai Engert wrote:
> > I propose to more actively involve users into the process of accepting
> > certificates for domains.
>
> I propose the following in addition:
>
> Each CA certificate shall have a sing
The NSS Team is pleased to announce the NSS 3.14.1 release.
Please read the NSS 3.14.1 release notes at:
https://developer.mozilla.org/en-US/docs/NSS/NSS_3.14.1_release_notes
Cheers,
Ryan
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-te
On Mon, November 5, 2012 10:12 am, Peter Djalaliev wrote:
> Hello,
>
> There seems to be a possible problem with the SSL implementation used in
> Google Drive on MacOS 10.8.2. I seems that this SSL implementation is NSS
> - please let me know if you know that Google Drive uses a different SSL
oup for the release notifications, 3.13.2
was paired with an NSPR 4.9 release.
Which version of NSPR are you using?
>
>
> Am 10/29/12 4:45 PM, schrieb Ryan Sleevi:
> > On Mon, October 29, 2012 8:32 am, Bernhard Thalmayr wrote:
> >> Hi all,
> >>
> >>
On Mon, October 29, 2012 8:32 am, Bernhard Thalmayr wrote:
> Hi all,
>
> sorry for this post, but I was not able to find the releasenotes for NSS
> version 3.13.x neither using Google nor querying the archive
>
>
> http://www.mozilla.org/projects/security/pki/nss/release_notes.html
>
> does no
On Mon, October 1, 2012 3:08 pm, Michael Demeter wrote:
> Hello,
>
> I work in the Open Source Technology group at Intel in the security group.
>
> I have been tasked with contacting the maintainer of libnss to start
> discussions about the possibility of Intel submitting patches to enable
> t
On Tue, July 10, 2012 12:32 pm, Robert Relyea wrote:
> On 07/09/2012 02:03 PM, Anders Rundgren wrote:
> > Ian,
> > Pardon me if I was a bit terse in my response.
> >
> > What I meant was simple that Operating Systems manage
> > critical resources but only occasionally keys. That is,
> > access to
Sean,
The "Path Building" logic/requirements/concerned you described is best
described within RFC 4158, which has been mentioned previously.
As Brian mentioned in the past, this was 'lumped in' with the description
of RFC 5280, but it's really its own thing.
libpkix reflects the union of RFC 415
> On 13/01/12 00:01, Brian Smith wrote:
> > Ryan seems to be a great addition to the team. Welcome, Ryan!
>
> Ryan - could you take a moment to introduce yourself? (Apologies if I
> missed an earlier introduction.)
Sure Gerv. Don't worry, there were no missed introductions, though I have
been l
> On 01/04/2012 03:51 PM, Brian Smith wrote:
> > Ryan Sleevi wrote:
> >> IIRC, libpkix is an RFC 3280 and RFC 4158 conforming implementation,
> >> while non-libpkix is not. That isn't to say the primitives don't exist
> >> -
> >> they do
(resending from the correct address)
> On 01/04/2012 03:51 PM, Brian Smith wrote:
> > Ryan Sleevi wrote:
> >> IIRC, libpkix is an RFC 3280 and RFC 4158 conforming implementation,
> >> while non-libpkix is not. That isn't to say the primitives don't exist
> Brian Smith a écrit :
> > 3. libpkix can enforce certificate policies (e.g. requiring EV policy
> > OIDs). Can the non-libpkix validation?
>
> EV policy have been defined in a way that means they could be supported
> by a code that handles an extremely tiny part of all what's possible
> with
> Are there any other benefits?
IIRC, libpkix is an RFC 3280 and RFC 4158 conforming implementation, while
non-libpkix is not. That isn't to say the primitives don't exist - they
do, and libpkix uses them - but that the non-libpkix path doesn't use them
presently, and some may be non-trivial wor
My reading of RFC 3280/5280 and from implementation experience with NSS,
CryptoAPI, OpenSSL, and other implementations is that no, that is not
correct.
CA:TRUE with a pathlen:0 is conformant to RFCs 3280/5280. The most common
cause for this would be for a CA certifying an intermediate, but that
in
>
> On 09/18/2011 03:15 AM, Ralph Holz (TUM) wrote:
> > Hi,
> >
> > does NSS check the pathlength extension in an issuing certificate?
> yes.
> > I am particularly wondering if pathlen:0 is honoured.
> According to the spec, which means no limit. NSS limits the size of the
> total chain to preve
> -Original Message-
> From: dev-tech-crypto-bounces+ryan-
> mozdevtechcrypto=sleevi@lists.mozilla.org [mailto:dev-tech-crypto-
> bounces+ryan-mozdevtechcrypto=sleevi@lists.mozilla.org] On Behalf
> Of Matej Kurpel
> Sent: Sunday, November 28, 2010 11:24 AM
> To: mozilla's crypto cod
> On 2010-11-26 13:20 PDT, ryan-mozdevtechcry...@sleevi.com wrote:
> [snip]
> > And to save you a bit of trouble/pain: for CryptoAPI, you cannot
> > simply sign raw data - you can only sign previously hashed data. I
> > understand this to mean that you cannot write a pure PKCS#11 ->
> > CryptoAPI m
> -Original Message-
> From: dev-tech-crypto-bounces+ryan-
> mozdevtechcrypto=sleevi@lists.mozilla.org [mailto:dev-tech-crypto-
> bounces+ryan-mozdevtechcrypto=sleevi@lists.mozilla.org] On Behalf
> Of Gervase Markham
> Sent: Wednesday, July 21, 2010 1:22 PM
> To: dev-tech-crypto@lis
> That's great news! Is there a corresponding bug number or other way I
> can track the progress to see which version of NSS it gets into?
https://bugzilla.mozilla.org/show_bug.cgi?id=394919
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-
82 matches
Mail list logo
