Hi Gavin,
I initially responded to Gijs' e-mail a while ago, before it got through
dev-platform moderation. Since then I've discovered one bug which I believe is
related. This one is tracked in bug 1017298. In particular this occurs when a
user first has more tabs open than the window can fit,
On Wednesday 2014-05-28 21:03 -0700, Nicholas Nethercote wrote:
> > static T inc(T& aPtr) { return IntrinsicAddSub::add(aPtr, 1); }
> > static T dec(T& aPtr) { return IntrinsicAddSub::sub(aPtr, 1); }
>
> > static T or_( T& aPtr, T aVal) { return __sync_fetch_and_or(&aPtr, aVal); }
> > static T xor
On Wed, May 28, 2014 at 9:03 PM, Nicholas Nethercote 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
things like the Owning
On Tue, Jan 7, 2014 at 12:53 PM, Robert O'Callahan 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
reconsidered.
Le 29 mai 2014 à 10:25, David Keeler 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 scenario "This sel
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 wo
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
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 De
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 trust infrastructure
> supported by Firefox and Thunderb
On 05/28/2014 08:37 PM, Karl Dubost wrote:
Le 29 mai 2014 à 09:13, Andrew Sutherland 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
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 in
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 sp
Andrew,
Le 29 mai 2014 à 09:13, Andrew Sutherland 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 self-signed certificate becaus
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
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 difficult to change
exceptions to per-principal-per-app rather than just per-principal.
It's
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 con
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
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
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 static_asse
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 :
> A
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 , but
it has a problem: it only returns false if the destructor is deleted, it
does
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')
(b)
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
TEST-UNEXP
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
wrote:
> (Note: I have not looked into the details of CART/TA
(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. Em
- 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 l
> > 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 actua
27 matches
Mail list logo
