This is at least in part due to bug 915735, you can go and read the bug to
see that I did the best I could there, given the constraints that I had
(not understanding how the magic of the interaction of ICU and our build
system worked, not understanding which parts of ICU we actually
- Original Message -
Is there a way to give the linker a list of functions that you want to have
as public entry points of a dynamically linked library, and have it strip
out everything that can’t be reached from these functions? That’s
essentially what happens when you statically link
(Note: I have not looked into the details of CART/TART and their interaction
with OMTC)
It's entirely possible that (b) is true *now* -- the test may have been good
and proper for the previous environment, but now the environment
characteristics were changed such that the test needs tweaks.
Who's responsible for looking into the test/regression? Bas? Does the
person looking into it need help from the performance or desktop teams?
What bug is tracking that work?
Gavin
On Wed, May 28, 2014 at 12:12 PM, Vladimir Vukicevic
vladi...@mozilla.comwrote:
(Note: I have not looked into
Dear everyone,
After weeks tracking and fixing blockers, we are in the process of
attempting to land bug 976205. If this sticks, it will change the
behavior of xpcshell tests with respect to uncaught asynchronous errors:
uncaught promise rejections using Promise.jsm will cause
Hi dev-platform,
PSA: if you are adding a concrete class with AddRef/Release
implementations (e.g. via NS_INLINE_DECL_REFCOUNTING), please be aware
of the following best-practices:
(a) Your class should have an explicitly-declared non-public
destructor. (should be 'private' or 'protected')
Awesome work!
By the way, I just figured a way that you could static_assert so that at
least on supporting C++11 compilers, we would automatically catch this.
The basic C++11 tool here is std::is_destructible from type_traits, but
it has a problem: it only returns false if the destructor is
Actually that test program contradicts what I said --- my
IsDestructorPrivateOrDeleted produces exactly the same result as
!is_destructible, and is_destructible does return 0 for the class with
private destructor. So you could just use that!
Benoit
2014-05-28 16:51 GMT-04:00 Benoit Jacob
Nice! So it sounds like we could use std::is_destructible to harden our
refcounting-impl macros (like NS_INLINE_DECL_REFCOUNTING), by having
those macros include a static_assert which enforces that they're only
invoked by classes with private/protected destructors.
(I'll bet that this
tl;dr: We need to figure out how to safely allow for invalid
certificates to be used in the Firefox OS Gaia email app. We do want
all users to be able to access their email, but not by compromising the
security of all users. Read on if you work in the security field / care
about certificates
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
Thanks for the overview of a real problem, Andrew.
(I recall having to add an exception for a Mozilla Root CA to
access email at one time.)
Andrew Sutherland writes:
I propose that we use a certificate-observatory-style mechanism to
corroborate any invalid certificates by attempting the
https://bugzilla.mozilla.org/show_bug.cgi?id=1013262 tracks all the Talos
performance adjustments
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Andrew,
Le 29 mai 2014 à 09:13, Andrew Sutherland asutherl...@asutherland.org a écrit
:
My imagined rationale for why someone would use a self-signed certificate
amounts to laziness.
being one of those persons using a self-signed certificate, let's enrich your
use cases list ;)
I use a
On 05/28/2014 07:22 PM, Karl Tomlinson wrote:
(I recall having to add an exception for a Mozilla Root CA to
access email at one time.)
It's fairly common that there exist multiple aliases to access a mail
server but the server does not have certificates available for all of
them. In the
On 5/28/2014 5:30 PM, Andrew Sutherland wrote:
tl;dr: We need to figure out how to safely allow for invalid
certificates to be used in the Firefox OS Gaia email app. We do want
all users to be able to access their email, but not by compromising
the security of all users. Read on if you work
On 05/28/2014 08:37 PM, Karl Dubost wrote:
Le 29 mai 2014 à 09:13, Andrew Sutherland asutherl...@asutherland.org a écrit
:
My imagined rationale for why someone would use a self-signed certificate
amounts to laziness.
being one of those persons using a self-signed certificate, let's enrich
Andrew,
Le 29 mai 2014 à 09:50, Andrew Sutherland asutherl...@asutherland.org 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 trust infrastructure
supported
On 5/28/2014 7:13 PM, Andrew Sutherland wrote:
My imagined rationale for why someone would use a self-signed
certificate amounts to laziness. (We've been unable to determine what
the rationale is for using invalid certificates in these cases as of
yet.) For example, they install dovecot on
On 05/28/2014 06:01 PM, Karl Dubost wrote:
Andrew,
Le 29 mai 2014 à 09:50, Andrew Sutherland asutherl...@asutherland.org 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
On Wed, May 28, 2014 at 5:13 PM, Andrew Sutherland
asutherl...@asutherland.org wrote:
On 05/28/2014 07:16 PM, David Keeler wrote:
* 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
Le 29 mai 2014 à 10:25, David Keeler dkee...@mozilla.com a écrit :
But without verifying that the certificate they received is the
certificate you created, those users are open to attack.
agreed.
My intent in the discussion is NOT Let's not verify the certificate is valid
but to allow the
On Tue, Jan 7, 2014 at 12:53 PM, Robert O'Callahan rob...@ocallahan.org wrote:
We have a lot of places where we write void Method() { ... } all on one
line for trivial setters and getters. I wonder if we should permit that.
The conclusion for this question was no, but I will ask for it to be
On Wed, May 28, 2014 at 9:03 PM, Nicholas Nethercote n.netherc...@gmail.com
wrote:
Furthermore, one-liners like this are actually pretty common, and
paving the cowpaths is often a good thing to do.
Thoughts?
Nick
+1. In a lot of cases, it seems pretty ridiculous to use 4 lines. See
On Wednesday 2014-05-28 21:03 -0700, Nicholas Nethercote wrote:
static T inc(T aPtr) { return IntrinsicAddSubT::add(aPtr, 1); }
static T dec(T aPtr) { return IntrinsicAddSubT::sub(aPtr, 1); }
static T or_( T aPtr, T aVal) { return __sync_fetch_and_or(aPtr, aVal); }
static T xor_(T aPtr,
25 matches
Mail list logo
