Zoogtfyz wrote:
> This is my recommendation for changes to the supported ciphersuits in
> Mozilla Firefox. I performed rigorous compatibility testing and everything
> works as advertized. I used Firefox telemetry data, SSL Pulse data, and my
> own tests to verify that *not a single* publicly acce
Julien Vehent wrote:
> > The discussion above was biased in favor of what was best for FirefoxOS
> and
> > FxAndroid.
>
> AES-NI has also removed mosts concerns around bad implementations of
> AES, so it seems that the attacks we were concerned about two years ago
> do not apply anymore.
>
I thi
Julien Vehent wrote:
> The original thread [1] had a long discussion on this topic. The DJB batch
> attack redefines the landscape, but does not address the original concerns
> around AES-256 resistance. To me, the main question is to verify whether
> AES-256 implementations are at least as resis
David Woodhouse wrote:
> The sysadmin should be able to configure things for *all* users
> according to the desired policy, rather than forcing each user to set
> things up for themselves.
>
> And in turn the *developers* of the operating system distribution
> should be able to set a default poli
On Fri, May 1, 2015 at 9:11 AM, Tanvi Vyas wrote:
> > On Apr 27, 2015, at 2:03 PM, Michael Peterson <
> michaelpeterson...@gmail.com> wrote:
> > Now, in the album I posted above (https://imgur.com/a/dmMdG), the last
> two screenshots show a packet capture from Wireshark. It appears that
> Firefox
Gervase Markham wrote:
> On 07/04/15 17:32, Hanno Böck wrote:
>> Are you using DSA? Firefox removed DSA recently (which is good - almost
>> nobody uses it and it's a quite fragile algorithm when it comes to
>> random numbers).
>
> Hanno's probably hit the nail on the head here.
> https://bugzilla.
Rob Stradling wrote:
> The README [1] says:
> "If multiple certificate chains are found, the shortest one is used."
>
> That's a good strategy for a browser to employ when deciding which chain to
> show in its certificate viewer, but it's unlikely to be the best strategy
> when configuring a serve
Ryan Sleevi wrote:
> 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
Hanno Böck wrote:
> Brian Smith wrote:
> Having new oids with sane pre-defined parameters would vastly simplify
> things. Back when I wrote that code I thought changing the standard is
> harder than implementing the non-optimal spec, but I might've been
> wrong.
To clarify:
Ryan Sleevi wrote:
> - It assumes all the parameters can be expressed via a SECOidTag. That
> is, it's missing hash alg, mgf alg, salt length (e.g. the
> RSASSA-PSS-params construction)
I believe there are only a small number of (hashAlgorithm, mgf alg,
salt length) combinations that need to be
[+antoine]
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.
There are multiple "upper layers" and, depending on your goals, some
should be prioritized higher t
On Mon, Nov 10, 2014 at 9:04 PM, Nicholas Nethercote
wrote:
>> In your analysis, it would be better to use a call stack trace depth
>> larger than 5 that allows us to see what non-NSS function is calling
>> into NSS.
>
> I've attached to the bug a profile that uses a stack trace depth of 10.
Unfo
On Mon, Nov 10, 2014 at 6:51 PM, Nicholas Nethercote
wrote:
> 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 browsing sessions.
On Sun, Jun 29, 2014 at 11:18 AM, Hubert Kario wrote:
> The number of sites that prefer RC4 while still supporting other ciphers
> are
> very high (18.6% in June[1], effectively 21.3% for Firefox[6]) and not
> changing much. The percent of servers that support only RC4 is steadily
> dropping (1.7
On Thu, Oct 2, 2014 at 9:03 AM, wrote:
> Maybe there is something that can be done to hep this situation? Maybe these
> old "private" certificates need to be cleaned out on upgrade? Or maybe
> something in the code that is going nuts trying to validate these "private"
> certificates needs to b
On Tue, Aug 5, 2014 at 9:51 AM, wrote:
> Since updating to 31, I have not been able to log into a self signed web page:
>
> Secure Connection Failed
>
> An error occurred during a connection to taiserver:444. Certificate key usage
> inadequate for attempted operation. (Error code:
> sec_error_i
Hi,
Amogst other things, PSM is the part of Gecko (Firefox) that connects
Gecko to NSS and other crypto bits.
David Keeler has taken on most of the responsibility for keeping
things in PSM running smoothly and so it makes sense to have him be
the module owner. After asking the other PSM module pe
On Thu, Jul 10, 2014 at 5:00 AM, Hubert Kario wrote:
> - Original Message -
>> From: "Brian Smith"
>> However, it is likely that crypto libraries that make the two changes above
>> will also have support for TLS_ECDHE_*_WITH_AES_*_GCM cipher suites to
On Thu, Jul 10, 2014 at 5:33 AM, Kurt Roeckx wrote:
>
> [snip]
> An other alternative is using curve25519. It's also not standardized yet,
> but at this time it seems more likely to be standardized first.
Thanks for bringing up curve25519. I'd like to share a recent paper
written by Daniel J. B
On Thu, Jul 10, 2014 at 4:53 AM, Henri Sivonen wrote:
> On Tue, Jul 1, 2014 at 11:58 PM, Brian Smith wrote:
> > I am interested in discussing what we can do to help more server side
> > products get better cipher suites by default, and on deciding whether we
> > add support
On Wed, Jul 2, 2014 at 5:08 AM, Hubert Kario wrote:
> Also, see Gavin's email here about adding such prefs in general. He
> > basically says, "Don't do it." Note that Gavin is the Firefox module
> owner:
> >
> https://groups.google.com/d/msg/mozilla.dev.platform/PL1tecuO0KA/e9BbmUAcRrwJ
>
> "As B
On Wed, Jul 2, 2014 at 5:28 AM, Hubert Kario wrote:
> > On 7/1/2014 14:05, Brian Smith wrote:
> > > I think, in parallel with that, we can figure out why so many sites
> > > are still using TLS_ECDHE_*_WITH_RC4_* instead of
> > > TLS_ECDHE_*_WITH_AES* and start
On Tue, Jul 1, 2014 at 7:15 PM, Julien Pierre
wrote:
> On 7/1/2014 14:05, Brian Smith wrote:
>
>> I think, in parallel with that, we can figure out why so many sites are
>> still using TLS_ECDHE_*_WITH_RC4_* instead of TLS_ECDHE_*_WITH_AES* and
>> start the technical ev
On Mon, Jun 30, 2014 at 1:56 AM, Kurt Roeckx wrote:
> On 2014-06-30 02:35, Hubert Kario wrote:
>
>> The benefits of ECDHE outweigh the risks of using RC4,
>>>
>>
>> I have to disagree here. Even 1024 bit DHE requires a targeted attack at
>> ~80 bit
>> complexity. Currently we see RC4 at around 56
On Sun, Jun 29, 2014 at 5:35 PM, Hubert Kario wrote:
>
> > As I noted in my bug comment [1], I think that the rhetoric of us not
> > adding any more RSA-key-exchange-based cipher suites, even the AES-GCM
> > ones, is significant. Software engineers at multiple companies referenced
> > our positio
On Sun, Jun 29, 2014 at 11:18 AM, Hubert Kario wrote:
> Because of that, disabling RC4 should be possible for many users. The big
> exception for that was YouTube video servers[4] which only recently gained
> support for TLS_RSA_WITH_AES_128_GCM_SHA256.
>
Hi,
I read your blog post at
http://sec
On Fri, Jun 27, 2014 at 9:19 AM, David Keeler wrote:
> On 06/27/2014 07:37 AM, Nathan Kinder wrote:
> > On 06/27/2014 12:13 AM, Frederik Braun wrote:
> >> To be frank, I have only ever seen the non-standard crypto functions
> >> used in attacks, rather than in purposeful use.
> >
> > That doesn't
On Mon, Apr 28, 2014 at 4:45 PM, Erwann Abalea wrote:
> The chain builder can test all possible issuers until it finds a valid one
> (that's what OpenSSL does, for example). The AKI is only here to say
> "pssst, this is most probably the certificate you should try first".
>
Right. We need to mea
On Mon, Apr 28, 2014 at 4:29 PM, Erwann Abalea wrote:
> I know DER tools is only a decoder, and from
> https://mxr.mozilla.org/mozilla-central/source/security/pkix/lib/pkixocsp.cpp#921the
> construction of the request makes heavy use of hex magic to build a
> request.
>
Right. OCSP requests are
[+dev-tech-crypto; Please discuss technical details of mozilla::pkix on
dev-tech-crypto and save dev-security-policy for discussion about Mozilla's
CA inclusion policies. There has been and will be a lot of technical
discussion on the behavior differences and rationale for those
differences--e.g. w
On Tue, Mar 11, 2014 at 3:20 AM, Hanno Böck wrote:
> I wanted to bring up an issue regarding OCSP stapling.
> I filled this bug shortly after Firefox 27 came out:
> https://bugzilla.mozilla.org/show_bug.cgi?id=972304
>
> Short conclusion: If you have enabled OCSP stapling on your server this
> wi
On Thu, Feb 13, 2014 at 9:57 AM, WebDoctor wrote:
>> > Should I write my own XPCOM object, or is there any other reasonable
>> > solution for that?. And can any one collaborate with me create this
>> > solution ?
> Thank you, i'll try to test the verifyCertNow in my extension and see what
>
On Wed, Feb 5, 2014 at 9:54 PM, Rasj wrote:
> Where are others? For example:
> TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d)
See https://briansmith.org/browser-ciphersuites-01.html. Also, please
look at the archives of this mailing list. There have been several
DOZEN of emails about the cipher suite sel
On Wed, Feb 5, 2014 at 5:39 PM, wrote:
> Is the retry logic in nss or in mozilla-central? And if the latter,
> can anyone help narrow the search? I didn't find anything relevant
> in comm-central.
It is in mozilla-central, in
security/manager/ssl/src/nsNSSIOLayer.cpp. See these bugs:
https://b
On Wed, Jan 29, 2014 at 2:57 PM, wrote:
> I retried with a new ff profile and now it works, but only if I go
> directly to https://wayfarer.timewarnercable.com/; I cannot convince
> the new profile to let me in to the authenticated site for some reason
> I haven't diagnosed. That is probably why
On Mon, Jan 27, 2014 at 2:22 PM, wrote:
> In case anyone is keeping a list, while helping a relative I determined
> that timewarnercable.com's login server (wayfarer.timewarnercable.com)
> will not work with tls 1.1 or 1.2. The connection fails after the client
> right after the client hello.
>
On Mon, Jan 27, 2014 at 10:49 AM, wrote:
> On Monday, January 27, 2014 10:52:44 AM UTC-7, Brian Smith wrote:
>> On Mon, Jan 27, 2014 at 9:26 AM, wrote:
>
> I can't speak for FF - and I've certainly read enough standards to say
> that there are too many standards. I
On Mon, Jan 27, 2014 at 9:26 AM, wrote:
> On Monday, January 27, 2014 6:19:42 AM UTC-7, Kurt Roeckx wrote:
> 2) NIST is a US government standards board that drives a lot of compliance
> regulation. There are companies what will want to be able show that they
> are NIST compliant. The
On Sun, Dec 15, 2013 at 8:46 AM, Kurt Roeckx wrote:
> But some people are also considering disabling it by default,
> as I think all other where talking in this thread, not just
> reduce the preference.
>
> > For the same reason, the server ciphersuite that we recommend at
> > https://wiki.mozill
Kurt,
Thanks for your suggestions.
On Sat, Dec 14, 2013 at 12:46 PM, Kurt Roeckx wrote:
> I think we need to come up with a plan to improve security in the
> long run. I think what we would like to see in general is:
> - Only SHA256 or better (and so TLS 1.2)
>
This is gated almost purely on
On Sat, Dec 14, 2013 at 4:47 PM, Kosuke Kaizuka wrote:
> > little supported, never negotiated cipher
>
> One of the largest websites which support Camellia is Yahoo!.
> Firefox 26 or lower use TLS_RSA_WITH_CAMELLIA_256_CBC_SHA with Yahoo!.
>
In Firefox 27 or later, Yahoo! will choose TLS_RSA_WIT
On Sat, Dec 14, 2013 at 3:51 PM, Kurt Roeckx wrote:
> On Sat, Dec 14, 2013 at 03:36:44PM -0800, Brian Smith wrote:
> >
> > Note that the cipher suites above were not agreed to in the previous
> > discussion and were not part of my proposal linked to above. They have
> bee
On Sat, Dec 14, 2013 at 2:13 PM, falcon wrote:
> I believe startssl (even) will sign ecdsa certs if you send a csr for one,
> but this is of little utility without an ecdsa trust anchor.
>
> Original message
> From: cl...@jhcloos.com
>
> Brian Smith wri
On Fri, Dec 13, 2013 at 10:48 PM, wrote:
> I present a proposal to remove some vulnerable/deprecated/legacy TLS
> ciphersuits from Firefox. I am not proposing addition of any new
> ciphersuits, changing of priority order, protocol removal, or any other
> changes in functionality.
>
> I have read
On Fri, Dec 13, 2013 at 11:51 PM, Brian Smith wrote:
> I will comment on your proposal again later. However, I want to share with
> you some usage data from Firefox 28 Beta, that I think we will find helpful
> in understanding what servers do. These numbers represent the cipher suite
&g
On Fri, Dec 13, 2013 at 10:48 PM, wrote:
> I present a proposal to remove some vulnerable/deprecated/legacy TLS
> ciphersuits from Firefox. I am not proposing addition of any new
> ciphersuits, changing of priority order, protocol removal, or any other
> changes in functionality.
Hi,
Thank you
Hi all,
Please join me in welcoming David Keeler as a PSM peer! Amongst many
other things, David implemented the HSTS preload list, integrated OCSP
stapling into Firefox, and is current implementing the OCSP
Must-Staple feature, which is a key part of our goal of making
certificate status checking
On Tue, Nov 19, 2013 at 9:14 AM, Kurt Roeckx wrote:
> On Mon, Nov 18, 2013 at 06:47:08PM -0800, Wan-Teh Chang wrote:
>> On Mon, Nov 18, 2013 at 4:57 PM, Brian Smith wrote:
>> >
>> > Also, AES implementations are highly optimized, well-audited,
>> > well-te
On Sun, Nov 10, 2013 at 4:39 AM, Kurt Roeckx wrote:
> On Sat, Nov 09, 2013 at 02:57:48PM -0800, Brian Smith wrote:
>> Last week, I also learned that ENISA, a European standards group,
>> recommends Camellia alongside AES as a future-proof symmetric cipher
>> algorithm; see [4
On Fri, Nov 1, 2013 at 2:22 AM, Kurt Roeckx wrote:
> On Mon, Oct 07, 2013 at 09:06:54PM +0200, Kurt Roeckx wrote:
>> On Fri, Aug 30, 2013 at 01:10:08AM +0200, Kurt Roeckx wrote:
>> > So what needs to happen so that we can move on with this?
>>
>> I still have the same question. Nothing seems to b
Kai just tagged NSS_3_15_4_BETA1 yesterday but mozilla-central
urgently needs the fix for bug 934378 which is fixed by the patch for
NSS bug 935847, so I created the BETA2 tag which contains that fix.
Cheers,
Brian
--
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
--
dev-tech-crypto mailing
On Fri, Nov 1, 2013 at 1:28 AM, Jeff Hodges wrote:
> /* New non-experimental openly spec'ed versions of those cipher suites. */
> #define SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA 0xfeff
> #define SSL_RSA_FIPS_WITH_DES_CBC_SHA 0xfefe
>
> Does anyone know what spec this cipher suite came from?
On Mon, Oct 7, 2013 at 6:05 PM, Mountie Lee wrote:
> SHA2 hash required in e-commerce transaction by the korean regulation.
> and which is also used in TLSv1.1+.
Hi,
First, we will be enabling TLS 1.2 in Firefox very soon.
But, I think you may be referring to SHA-2-based cipher suites
proposed
On Thu, Sep 12, 2013 at 7:06 AM, Julien Vehent wrote:
> It seems that AES-256 is always 25% to 30% slower than AES-128, regardless of
> AES-NI, or the CPU family.
> The slowest implementation of AES-256 has a bandwidth of 21MBytes/s, which is
> probably fast enough for any browser
> If perform
On Mon, Oct 7, 2013 at 3:20 PM, Robert Relyea wrote:
> On 10/07/2013 12:44 PM, Wan-Teh Chang wrote:
>> On Mon, Oct 7, 2013 at 11:17 AM, Brian Smith wrote:
>>> I think it is likely that some vendors of NSS-based products with very
>>> conservative backward-compatibil
On Wed, Oct 2, 2013 at 2:28 AM, Mountie Lee wrote:
> Hi.
> currently SHA2 hash algorithm is used in TLS1.1 and 1.2
> mozilla firefox is supporting it now.
Hi,
Are you referring to the TLS_*_SHA256 cipher suites, or something
else? I believe that we support SHA256-based signatures everywhere
alre
Mountie Lee wrote:
> SEED was adopted to encourage escaping ActiveX dependency in Korea
> e-commerce environment.
Many people at Mozilla, including us platform engineers, want this
too. Our goal is to get rid of plugins on the internet completely.
And, also, personally I think it is a great idea
On Fri, Oct 4, 2013 at 6: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
> faster compile time + test time
>
> What do you
sst...@mozilla.com wrote:
> Do we have telemetry on how frequently these APIs are used?
I expect that, of the small percentage of people that are using these APIs,
they are using them (except signText) very infrequently--like once a year. When
I talked to Ehsan and Andrew Overholt about this, we
On Sat, Sep 28, 2013 at 7:52 AM, Sean Leonard wrote:
> On 9/27/2013 5:51 PM, Robert Relyea wrote:
>>
>> I don't have a problem with going for an industry standard way of doing
>> all of these things, but it's certainly pretty presumptuous to remove these
>> features without supplying the industry
On Fri, Sep 27, 2013 at 2:31 AM, Eddy Nigg wrote:
> On 09/27/2013 02:29 AM, From Brian Smith:
>
>> I have met with several members of our DOM and web API teams and we've
>> tentatively agreed that we should remove these functions if at all
>> possible--as soon as 201
On Mon, Apr 8, 2013 at 2:52 AM, helpcrypto helpcrypto
wrote:
>
> While awaiting to http://www.w3.org/TR/WebCryptoAPI/ Java applets for
> client signning, signText and are needed.
> Also things like Handling smart card events or Loading PKCS #11
> modules is being use by many.
> So, you _CANT_ rem
On Mon, Aug 26, 2013 at 2:24 PM, Brian Smith wrote:
> Something to note is that MSIE has always put AES-128 cipher suites ahead
> of AES-128 cipher suites. They also put RSA cipher suites ahead of PFS
> cipher suites, though.
>
>
I meant: MSIE has always put AES-128 cipher suites
On Thu, Aug 22, 2013 at 11:21 AM, Robert Relyea wrote:
> So looking at this list, I think we have a major inconsistency.
>
> We put Ephemeral over non-ephemeral, but we put 128 over 256.
>
> While I'm OK with Ephemeral (PFS) over non-ephermal (non-pfs), I think
> in doing so we are taking a much
On Mon, Aug 12, 2013 at 6:52 AM, Gervase Markham wrote:
> On 09/08/13 18:12, Brian Smith wrote:
> > No, each combination is hard-coded into its own distinct code point that
> is
> > registered with IANA:
> >
> https://www.iana.org/assignments/tls-parameters/tls-parame
On Fri, Aug 16, 2013 at 5:58 PM, Wan-Teh Chang wrote:
> On Fri, Aug 16, 2013 at 3:36 PM, Rob Stradling
> wrote:
> >
> > Wan-Teh, why do you think Firefox should specify a preference for ECDSA
> over
> > RSA?
>
> Because ECDSA is more secure than RSA, and ECC implementations will
> become faster
On Fri, Aug 16, 2013 at 11:13 AM, Camilo Viecco wrote:
> Hello Brian
>
> I think this proposal has 3 sections.
> 1. Unifing SSL behavior on browsers.
> 2. Altering the criteria for cipher suite selection in Firefox (actually
> NSS)
> 3. removing certain cipher suites from the default firefox ciph
On Thu, Aug 15, 2013 at 10:15 AM, 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 Apple product and avoid the use
> of ECDSA in th
On Fri, Aug 9, 2013 at 3:27 AM, Gervase Markham wrote:
> * Can you provide some background or references on exactly how
> ciphersuite construction and choice works? Can I invent e.g.
> TLS_DHE_ECDSA_WITH_AES_128_MD5 or some other random combination of
> elements? Can any combination be encoded in
Please see https://briansmith.org/browser-ciphersuites-01.html
First, this is a proposal to change the set of sequence of ciphersuites
that Firefox offers. Secondly, this is an invitation for other browser
makers to adopt the same sequence of ciphersuites to maximize
interoperability, to minimize
On Wed, Jul 31, 2013 at 1:58 AM, Robert Relyea wrote:
> On 07/30/2013 04:27 PM, Brian Smith wrote:
>
>> See
>> https://mxr.mozilla.org/**mozilla-central/source/**
>> services/crypto/modules/**WeaveCrypto.js#123<https://mxr.mozilla.org/mozilla-central/source/services/cr
See
https://mxr.mozilla.org/mozilla-central/source/services/crypto/modules/WeaveCrypto.js#123
and https://bugzilla.mozilla.org/show_bug.cgi?id=583209
and https://bugzilla.mozilla.org/show_bug.cgi?id=648407
On Tue, Jul 30, 2013 at 11:58 PM, hv wrote:
> Hi,
>
> I was not able to open NSS on FF
Julien Pierre wrote:
> If this is about removing the feature from NSS altogether on the
> other hand, I would like to state that we have several several
> products at Oracle that use NSS and rely on the ability to have
> CRLs stored in the database, and processed during certificate
> validation.
I
Robert Relyea wrote:
> On 05/02/2013 02:02 PM, Brian Smith wrote:
> So are you actually going to ship a different version of NSS with the
> default Firefox, or are you going to create a switch that changes the
> behavior of NSS with respect to stored CRLs (and what about cached
> C
Robert Relyea wrote:
> Oh, in that case I can say we have customers that definately need to
> use CRLs that have been loaded and stored in the database.
> > To be clear, I don't know of any reason to consider the processing
> > of already-loaded CRLs as a requirement for Firefox.
> Oh, then I'd s
Robert Relyea wrote:
> Brian, I was under the impression you wanted to remove the CRL
> autofetching feature (where you enter a URL and a fetching time and
> the CRL will automatically be fetched). When I looked at the UI, it
> looked like it had both the URL fetching feature as well as the
> abili
Sean Leonard wrote:
> Brian Smith wrote:
> > The "Revocation Lists" feature allows a user to configure Firefox
> > to poll the CAs server on a regular interval. As far as I know,
> > Firefox is the only browser to have such a feature. Other browser
> > eith
Hi all,
I propose we remove the "Revocation Lists" feature (Options -> Advanced ->
Revocation Lists). Are there any objections? If so, please explain your
objection.
A certificate revocation list (CRL) is a list of revoked certificates,
published by the certificate authority that issued the ce
Rob Stradling wrote:
> > I presume that Firefox OS trusts NSS's "Built-in" Root Certificates
> > [1], but what (if anything) does Firefox OS do for EV SSL?
As you found, Firefox OS doesn't have an EV UI, and in fact I just disabled the
EV validation logic in B2G for performance reasons, given tha
Rick Andrews wrote:
> I know that FF allows you to choose a CRL and it will check status
> against that CRL when it finds a cert issued by the CRL issuer. Does
> anyone know if FF uses the CDP in the cert or the cert's issuer name
> as a key to find the CRL?
I assume you are talking about the "Rev
> What does this mean for building Firefox?
>
> If you want to build a development snapshot of Firefox against a
> systemwide installed NSS, and you want to build Firefox 22 aurora at
> this time, you have the following choices:
>
> - don't build Firefox 22 aurora until Mozilla cleaned up the
>
See https://bugzilla.mozilla.org/show_bug.cgi?id=524664 (bug 524664) and
See
https://developer.mozilla.org/en-US/docs/JavaScript_crypto/generateCRMFRequest
My understanding is that is supposed to replace
window.crypto.generateCRMFRequest.
I have no idea how common window.crypto.generateCRMFReq
passf...@googlemail.com
> I use SSL_ConfigSecureServer with a certificate which was created in
> memory (no db). The certificate was created with the
> CERT_CreateCertificate passing the CA's issuer. The same cert was
> also signed with the CA's key. The CA cert was also created on the
> fly, i.e.
James Burton wrote:
> I want to create a selfsign certificate in c++ but i don't know were
> to start and i would like some help if you could make a example
> application to show me how to create a selfsign certificate or show
> me some documentation to create a selfsign certificates in c++.
Thank
Hi all,
I tagged NSS 3.14.2 BETA 3 and pushed it to mozilla-inbound to fix build
breakage of ASAN and dxr builds.
Also, now mozilla-central contains a patch for bug 834091. That patch adds a
new public function to libsmime, SEC_PKCS7VerifyDetachedSignatureAtTime, which
fulfills a last-minute B
Today I tagged the CVS HEAD with the NSS_3_14_2_BETA1 tag and imported it into
Gecko (pushed to inbound).
We expect to finalize the NSS 3.14.2 release in late January, 2013. In the
interim, you can pull and build NSS betas from CVS:
After mozilla-inbound is merged into mozilla-central, NSS 3.14
Brian Smith wrote:
> Brian Smith"
> > https://bugzilla.mozilla.org/show_bug.cgi?id=816392
>
> This change was backed-out before it reached mozilla-central from
> mozilla-inbound because NSS crashes during startup on Android (and
> probably B2G). See bug 817233.
A
Brian Smith"
> I tagged the CVS HEAD as NSS_3_14_1_BETA1 and pushed it to
> mozilla-inbound.
>
> If you are building Firefox or a Gecko-based application using
> --use-system-nss, you need to use the NSS 3.14.1 beta release, as
> that is now the minimum required
I tagged the CVS HEAD as NSS_3_14_1_BETA1 and pushed it to mozilla-inbound.
If you are building Firefox or a Gecko-based application using
--use-system-nss, you need to use the NSS 3.14.1 beta release, as that is now
the minimum required version to build Gecko.
Thanks for the help from everybod
Julien Pierre wrote:
> I know what code changes are necessary. I'm only a developer on a
> couple of NSS applications at this point, not an NSS maintainer.
> If this was only about those couple of apps, it wouldn't be an issue.
> But there are other apps in Oracle that could be affected.
> I can sa
julien.pie...@oracle.com> wrote:
> Oracle still ships NSS with many products even though we are no
> longer actively involved with its development.
It is important to have somebody at least monitoring the bugs filed/fixed in
the NSS component in bugzilla. See
https://bugzilla.mozilla.org/userpre
Vishal wrote:
> On Saturday, October 20, 2012 10:33:58 PM UTC+5, Brian Smith wrote:
> > Anders Rundgren wrote: > Anyway, I guess that Firefox OS uses NSS?
> > > Is it still is based on the idea that key access is done in the
> > > application context rather than t
Anders Rundgren wrote:
> Anyway, I guess that Firefox OS uses NSS?
> Is it still is based on the idea that key access is done in the
> application context rather than through a service?
B2G (Firefox OS) does use NSS. Nothing has changed regarding the process
separation between Gecko and the priva
Brian Teh wrote:
> Currently, my extension uses the NSS library which is coded in C++.
> But due to 6-week release cycle for Thunderbird, I am wondering
> whether are there examples on how to use Mozilla NSS for
> JavaScript-XPCOM, to avoid the need for re-compiling the binary
> components?
Curren
weizhong qiang wrote:
> Thanks for the instruction. I tried the build of nss on with
> mozillabuild tool (with MS VC and MS SDK, using MS compiler for
> compilation) on Win7. And the build did pass.
> But the build with MinGW/MSYS (using gcc for compilation) still
> failed.
> I hope the build (wit
Kai Engert wrote:
> The domain owner
> could configure their server to include this OCSP response in all TLS
> handshakes, even though this OCSP response is unrelated to the server
> certificate actually being used.
For complete protection, the real domain holder would have to staple all the
OCSP
Robert Relyea wrote:
> Why are they linking with Freebl anyway? It's intended to be a
> private interface for softoken. It's a very good way to find
> yourself backed into a corner.
Right. This was a long time ago. You helped me add the J-PAKE implementation to
Softoken after we discovered this p
Robert Relyea wrote:
> On 03/24/2012 03:05 PM, VJ wrote:
> > I'm trying to use RSA_HashCheckSign() function to verify the
> > message.
> How are you even Linking with RSA_HashCheckSign()?
I don't know what platform JV is on, but I know on Mac OS X, all the internal
symbols in FreeBL and maybe oth
helpcrypto helpcrypto wrote:
> IMHO, this is some that needs some clarification, as Mozilla *IS*
> supporting it developing JSS but at the same time saying "we do not
> support it",
Some people who are part of the Mozilla project maintain JSS. I will help
review patches to JSS if/when the member
> Today, a buggy old/legacy modutil.exe binary we are using, made me
> try building NSS using mingw. Once again.
The only way I recommend building NSS on Windows is with Microsoft Visual C++
and the mozilla-build package located at
https://developer.mozilla.org/en/Windows_Build_Prerequisites#Moz
1 - 100 of 178 matches
Mail list logo
