On 11/03/2017 03:34 PM, Robert Helmer wrote:
> On Fri, Nov 3, 2017 at 3:25 PM, David Keeler wrote:
>> [firefox-dev, dev-addons, and the enterprise mailing list cc'd - please
>> direct follow-up discussion to dev-platform]
>>
>> Hello All,
>>
>> As
[firefox-dev, dev-addons, and the enterprise mailing list cc'd - please
direct follow-up discussion to dev-platform]
Hello All,
As you're no doubt aware, from 57 onwards, only signed WebExtensions
will be available as add-ons for the general release population. My
understanding is these are all p
Hi Onno,
The work was done in bug 1382749. The first post in this thread outlined
what would be removed as a result of doing this - namely the upper right
corner of the label in the add-on installation dialog as you mentioned.
Note that as of bug 1366243 (shipping in 56), by default Gecko-based
pr
Hello Folks,
Bug 1372656 landed this morning, which means that Nightly now loads the
root certificate authority trust database asynchronously and shouldn't
block the main thread*. This should make startup faster, but it's a bit
experimental and improving PSM/NSS startup time is a work in progress
[dev-apps-thunderbird and dev-apps-seamonkey cc'd, but please discuss on
dev-platform]
Hello Everyone,
You may or may not be surprised to learn that Gecko contains two
different ways to verify that an add-on has been signed. The primary
method is nsIX509CertDB.openSignedAppFileAsync. This is what
(Everyone, start your bikesheds.)
The style guidelines at
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style
indicate that #includes are to be sorted. It does not say whether or not
to consider case when doing so (and if so, which case goes first?). That
is, should it be
> { "aus5.mozilla.org", true, true, true, 7, &kPinset_mozilla },
Just for clarification and future reference, the second "true" means this
entry is in test mode, so it's not actually enforced by default.
On Mon, Jan 4, 2016 at 1:08 PM, Dave Townsend wrote:
> aus5 (the server the app updater che
[cc'd to dev-security for visibility. This discussion is intended to
happen on dev-platform; please reply to that list.]
Ryan Sleevi recently announced the pre-intention to deprecate and
eventually remove support for the element and special-case
handling of the application/x-x509-*-cert MIME type
The functionality provided by nsINSSCertCache has been redundant for a
while now. To prevent potential confusion, it has been removed[0][1]. If
you ever needed to do something like this (to get a list of all known
certificates, for example) :
let certcache = Cc["@mozilla.org/security/nsscertcache;
As part of the Great PSM Modernization, the nsISSLErrorListener
interface will be removed in bug 844351 [0]. All implementations in
comm-central and chatzilla have already been removed [1][2] (they were
functionally no-ops anyway). All implementations in the addons indexed
by mxr are either incompa
Thanks for doing this!
On 10/27/2014 03:18 PM, Nicholas Nethercote wrote:
> ./security/manager/ssl/tests/unit/test_certificate_usages/generate.pl
> - mentioned in comments in
> security/manager/ssl/tests/unit/test_certificate_usages.js
We probably still need this until bug 969985[0] is fixed (in
[dev.platform cc'd for visibility - please follow-up to dev.tech.crypto]
Summary:
We intend to remove the proprietary window.crypto functions and
properties. See
https://developer.mozilla.org/en-US/docs/JavaScript_crypto for what will
be affected by this change.
Our reasoning is as follows: These
On 05/28/2014 06:01 PM, Karl Dubost wrote:
> Andrew,
>
> Le 29 mai 2014 à 09:50, Andrew Sutherland a
> écrit :
>> Trusting you as a human doesn't translate into protecting the users of your
>> server from man-in-the-middle attacks.
>> How do you translate the human trust into the technical tru
Regarding the current certificate exception mechanism:
> * there is only a single certificate store on the device and therefore
> that all exceptions are device-wide
This is an implementation detail - it would not be difficult to change
exceptions to per-principal-per-app rather than just per-pri
On 02/07/14 10:31, ISHIKAWA, Chiaki wrote:
> Message:
> [10549] WARNING: Security network blocking I/O on Main Thread: file
> /REF-COMM-CENTRAL/comm-central/mozilla/security/manager/ssl/src/nsNSSCallbacks.cpp,
> line 422
This generally happens when javascript calls a function on an
nsIX509Cert tha
Recently bug 539710 landed[0] to fix an unnecessary and apparently
unsafe operation:
const PRUnichar *comma = NS_LITERAL_STRING(",").get();
Curious, I did a quick search for other examples of NS_LITERAL_STRING
combined with .get() and found that this appears to be common[1].
So, I have a few ques
[bcc'd to many lists for wide visibility - discussion should probably be
on mobile.firefox.dev
(https://mail.mozilla.org/listinfo/mobile-firefox-dev )]
TL;DR: Now is a good time to remove plugin support from Firefox for Android.
Consider:
* We do not support plugins for Firefox OS and do not plan
On 04/23/13 02:17, Ed Morley wrote:
> On 23 April 2013 09:58:41, Neil wrote:
>> Hopefully a push never burns all platforms because the developer tried
>> it locally first, but stranger things have happened!
>
> This actually happens quite often. On occasion it's due to warnings as
> errors (switch
On 03/29/13 22:10, Kyle Huey wrote:
> On Fri, Mar 29, 2013 at 9:47 PM, Philip Chee wrote:
>
>> I'm running Windows7 and the mozilla-build system. We *have* to use
>> relative paths because some parts of mozilla-build (I can't remember
>> which) would choke on absolute paths.
>>
>
> Unless there'
19 matches
Mail list logo
