Phabricator - ReviewBot supports Coverity Analysis as an analyzer for C/C++

[Andi-Bogdan Postelnicu]

TL;DR -- ReviewBot supports Coverity Analysis as an analyzer for C/C++

Two years ago we have gradually introduced static-analysis during review phase, 
at first in MozReview and moving on in Phabricator. We have started with 
clang-tidy for C/C++, clang-format for C/C++/Objective{C,C++} coding style, 
Mozlint (Python, JavaScript, etc) and as time passed by we’ve added Infer for 
Java.

In parallel, Mozilla has been using Coverity for more than a decade. It found 
an impressive number of defects (at least 1017, see meta bug 1230156). Coverity 
is an accurate and comprehensive static analysis and static application 
security testing (SAST) solution that finds critical defects and security 
vulnerabilities.
In comparison with the previous tools that we have implemented in the review 
pipeline, Coverity provides advanced checkers which are able to detect more 
complex issues (with the cost of having false positives). 
We are excited to announce that we now have Coverity at review phase for C/C++ 
on Firefox.

An example of such analysis can be found at: 
https://phabricator.services.mozilla.com/D23099#inline-134606 
 
Unlike the other checkers, please be aware that Coverity checkers have false 
positives, some checkers are usually correct, some others aren’t.

We await for your feedback, and we are eager to learn from you what checkers 
will prove to be useful and what are ignored.
We already have a few next steps in mind:
Annotate results produced by checkers to detail the false positive ratio;
Enable Coverity support for Java and potentially JavaScript;
Add static analysis at review phase for other projects, like NSS.

If you encounter any issues with this new analyzer please report bugs at 
https://mzl.la/2EbaYho .

I also take this opportunity to thank our colleagues who made this possible, 
Sylvestre, Bastien, Marco and all of whom contributed to this.

Thanks,
ANdi

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intermediate CA Preloading is enabled for desktop Nightly users

[Tom Ritter]

How does kinto know which certificates you yet need to download?

On Fri, Mar 8, 2019, 3:29 PM J.C. Jones  wrote:

> # tl;dr #
>
> At the end of February I enabled Intermediate CA Preloading for all
> desktop Nightly users to begin gathering telemetry. This means all
> intermediate CAs disclosed to Mozilla will be pre-loaded into
> profiles, so the common secure website misconfiguration of forgetting
> this certificate won’t stop Firefox users. It has other benefits, too,
> but for those read on.
>
>
>
>
> In Bug 1404934 we've added support to download the Intermediate
> Certificate Authorities that have been disclosed to the Mozilla CA
> Root Program from Kinto in the background during normal Firefox
> operation. I turned this on for all desktop nightly users a bit more
> than a week ago, prompting Nightly users to download 100 intermediate
> CA certs into their profile each day. I do not have a timeline at
> present for this to ride the trains.
>
>
> # What it does #
>
> Websites using encryption should provide two digital PKI certificates
> [0] when connecting to clients: One for the website itself, and one
> for the intermediate CA that produced the website's digital
> certificate. Sometimes, websites are set up incorrectly.
>
>
> When other browsers encounter this case, they use AIA-chasing, a
> mechanism where the user's browser then, in the background, connects
> to the CA and downloads the certificate during the TLS handshake.
>
> ## Performance benefit ##
>
> Preloading the intermediate CA data avoids the just-in-time network
> fetch, which delays the connection.
>
> ## Privacy ##
>
> Avoiding the network fetch is also a privacy improvement, as it
> doesn't disclose your browsing pattern to the certificate authority
> that issued the misconfigured website's certificate.
>
> It's also helpful because it's possible to "fingerprint" a user by a
> website carefully analyzing what other websites load or do not load
> due to which intermediate CAs have been "seen" by a user [1].
> Preloading ensures that all users have "seen" all the same
> intermediate CAs.
>
> ## Protection ##
>
> The Mozilla CA program requires all members to disclose unconstrained
> intermediate CAs before using them, as a safety measure. However,
> there is not currently a way to technically enforce that. Intermediate
> Preloading could eventually be used to perform that enforcement, by
> only trusting intermediate CAs which were disclosed already. This
> protects against a scenario where a compromised CA is coerced into
> producing an undisclosed secret intermediate CA, which is then used to
> attack people on the Internet.
>
>
> ## Future usefulness ##
>
> The experimental CRLite concept [2] (aiming to replace OCSP) requires
> a mapping of Intermediate CAs to an “enrollment status” flag. Since we
> need to enumerate the Intermediate CAs for that future functionality,
> actually preloading their data is a rational extension.
>
>
> # How it works #
>
> Intermediate Preloading fetches ~100 intermediate certificate
> authorities' certificates once a day during the Kinto main update [3],
> and loads them into your profile, as if you had visited a site that
> used that intermediate. At 100 per day, summing to between 300-500 kB,
> it will take approximately three weeks for a Firefox profile to
> preload all intermediates [4]. We will likely increase the rate after
> the initial experiments.
>
> The certificate data is loaded into the NSS Certificate Database, as
> is done for normal web browsing. In the future, we will use the faster
> Rust "rkv" database, in Bug 1530545.
>
> Currently preloading is only enabled for desktop users on Nightly. We
> will want to (A) restrict the download to be only over WiFi and maybe
> plugged in, and (B) switch to the faster database before enabling on
> mobile. (Bug 1520297)
>
>
> # What we expect #
>
> Intermediate Preloading should reduce the number of
> SEC_ERROR_UNKNOWN_ISSUER errors seen by Firefox users over time, which
> is our most common secure connection error. It will also remove the
> tracking vector (above, Privacy), and give us a path to enforce CA
> disclosure.
>
>
> # Things to keep in mind #
>
> Right now, these certificates go into the NSS Certificate Database,
> and are visible in / totally overcrowding the Certificate Manager (Go
> To about:preferences#privacy , View Certificates.., Authorities tab).
> That’ll change when this moves to rkv.
>
> This is potentially a bunch of data, approximately 3 megabytes of
> binary, but it’s data that changes only very slowly.
>
>
> # Telemetry #
>
> Telemetry for Intermediate Preloading is available in the histograms:
>
>   "INTERMEDIATE_PRELOADING_ERRORS"
>   "INTERMEDIATE_PRELOADING_UPDATE_TIME_MS"
>
> and the scalars:
>
>   "security.intermediate_preloading_num_pending"
>   "security.intermediate_preloading_num_preloaded"
>
> ... which show how many of the ~2300 intermediates have been loaded,
> per profile.
>
> # More info #
>
> Well, 

Re: Intent to Ship: Ignore custom cursors over 32 pixels intersecting UI

[Emilio Cobos Álvarez]

On 13/03/2019 01:46, flor...@rivoal.net wrote:
> On Wednesday, March 13, 2019 at 8:36:17 AM UTC+9, Emilio Cobos Álvarez wrote:
>> On 13/03/2019 00:22, Florian Rivoal wrote:
>>> Given that this is not merely setting a limit because you find that 
>>> implementation more convenient, but actually a case of considering it 
>>> desirable to ignore large cursors in certain cases (and for security 
>>> reasons even), I wonder if this is something that we should consider 
>>> including in the specification. What do you tink?
>>
>> I think a note or such in the spec would be nice, yeah. FWIW some
>> platforms already had pre-existing cursor limits for similar reasons[1]
>> since forever.
>>
>> I probably wouldn't bother specifying a concrete limit, though not sure
>> how you feel about that. Seems like depending how big the browser's UI
>> is, a browser could make different tradeoffs without compromising security.
> 
> Could you raise it to the CSSWG, and we can see there what's appropriate, 
> taking into account what others browsers do?

Filed https://github.com/w3c/csswg-drafts/issues/3728. Thanks!

 -- Emilio

> Thanks,
> —Florian
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Running different instances of Firefox side-by-side

[Dave Townsend]

A quick update here. After hearing some feedback from folks I've filed the
following bugs that I should have a patch up for in the next day:

https://bugzilla.mozilla.org/show_bug.cgi?id=1535021 Don't show the profile
manager when the default profile was selected and an existing instance is
running.
https://bugzilla.mozilla.org/show_bug.cgi?id=1535144 Return -new-instance
to its previous behaviour.

On Mon, Mar 11, 2019 at 11:35 AM Dave Townsend 
wrote:

> Woah this email got long. How Firefox considers whether to pass off to an
> existing instance of Firefox or continue launching a new one turns out to
> be more complex than you might expect. I'm mostly interested in making
> folks aware of and giving feedback on how this works after I've changed
> some things so feel free to jump down there. But I figured some folks might
> find some context in how things work currently. For that, read on!
>
> One of the goals of pushing to a profile-per-install model for Firefox is
> allowing users to run different versions of Firefox side-by-side without
> the additional hassle of editing shortcut files or running from the command
> line. This has meant changing the "remoting" code, which searches for
> existing instances of Firefox and passes command line arguments to them
> instead of starting up normally. I landed the changes to this a couple of
> days ago and I thought it was worthwhile explaining what has changed since
> it might not be exactly what you expect. And if that is the case figure out
> whether it makes sense to make any changes.
>
> *So first, a quick recap of what remoting has done in the past, because it
> varies from platform to platform...*
>
> OSX is the easy case. Firefox doesn't handle remoting at all. OSX does it
> all, assuming you are running Firefox by running an app bundle or a dock
> icon. OSX sees that an existing Firefox is running and just sends it a
> message, a new Firefox instance doesn't even start. I've made no changes
> here.
>
> Windows is the slightly more complex case. When run Firefox attempts to
> find an already running Firefox. If one exists it passes its command line
> off to it and quits. The -no-remote command line argument is a way to
> bypass this behaviour, running with it will stop the new Firefox from
> attempting to find an existing instance or becoming and instance that can
> be found by other instances. Basically there can only be one Firefox open
> that can be found by future invocations. The -new-instance command line
> argument is parsed on Windows ... and then ignored.
>
> Finally there is Linux. The more exciting case. Unless -no-remote or
> -new-instance are passed on startup linux will search for an existing
> version of Firefox based on a few criteria .. which varies a little
> depending on whether we're using dbus remoting or X remoting. We use X
> remoting if we are using X11 windows, and dbus if not (and dbus is
> supported). In both cases on startup Firefox attempts to find an existing
> instance of Firefox with the same remoting name (or you can provide a
> different remoting name with -a on the command line). dev-edition has one
> remoting name, all other versions of firefox have a different one. If there
> is more than one .. which one wins seems undefined. You can additionally
> pass "-P " in which case Firefox will only select an existing
> instance running the named profile. On X remoting there are a few extras.
> Passing "-a any" on the command line will find any running Firefox
> regardless of remoting name. Passing "-u " will consider
> Firefoxen run by the given user (otherwise it only looks at those run by
> the current user). -no-remote means FIrefox doesn't register itself to be
> found by future instances. -no-remote or -new-instance means we don't look
> for existing instances on startup.
>
> So that's all rather complicated. To make matters more fun the linux and
> windows implementations are handled by totally separate code running at
> different times during startup. The two key problems here were that windows
> completely didn't support more than one instance running, unless all but
> one were -no-remote, and linux was horribly complex and again unless you
> ran with command line arguments didn't support more than one Firefox at a
> time. We wanted something that allowed running Firefox release and Firefox
> beta and Firefox nightly with no special arguments at the same time.
>
> So I have done three things. Removed support for some of the things Linux
> supported. Made the code a lot more shared between windows and linux so
> things happen at the same time regardless of platform and both platform
> have what should be identical behaviours. Changed the order of when some
> things happen.
>
> What did I remove? Support for remoting to a different remoting name and a
> different user. Both seem unlikely to be useful for normal use cases, the
> latter frankly feels like a security risk.
>
> *How does it all work now?*
>
> OSX hasn't 

Re: Intermediate CA Preloading is enabled for desktop Nightly users

[J.C. Jones]

Tom,

Kinto provides the whole list of metadata to clients as soon as it syncs
[1].  The metadata uses the Kinto attachment
 mechanism to store the
DER-encoded certificate for separate download.

Firefox maintains a "local field" boolean in the dataset to of whether a
given metadata entry's certificate attachment has been downloaded or not,
toggling as each one is pulled. Currently we don't deduplicate with the
local NSS Cert DB, the inserts that are already there will fail and emit
telemetry -- the amount of data saved didn't seem worth it for the
experimental phase.

Thanks!

[1]
https://settings.prod.mozaws.net/v1/buckets/security-state/collections/intermediates/records

On Wed, Mar 13, 2019 at 10:22 AM Tom Ritter  wrote:

> How does kinto know which certificates you yet need to download?
>
> On Fri, Mar 8, 2019, 3:29 PM J.C. Jones  wrote:
>
>> # tl;dr #
>>
>> At the end of February I enabled Intermediate CA Preloading for all
>> desktop Nightly users to begin gathering telemetry. This means all
>> intermediate CAs disclosed to Mozilla will be pre-loaded into
>> profiles, so the common secure website misconfiguration of forgetting
>> this certificate won’t stop Firefox users. It has other benefits, too,
>> but for those read on.
>>
>>
>>
>>
>> In Bug 1404934 we've added support to download the Intermediate
>> Certificate Authorities that have been disclosed to the Mozilla CA
>> Root Program from Kinto in the background during normal Firefox
>> operation. I turned this on for all desktop nightly users a bit more
>> than a week ago, prompting Nightly users to download 100 intermediate
>> CA certs into their profile each day. I do not have a timeline at
>> present for this to ride the trains.
>>
>>
>> # What it does #
>>
>> Websites using encryption should provide two digital PKI certificates
>> [0] when connecting to clients: One for the website itself, and one
>> for the intermediate CA that produced the website's digital
>> certificate. Sometimes, websites are set up incorrectly.
>>
>>
>> When other browsers encounter this case, they use AIA-chasing, a
>> mechanism where the user's browser then, in the background, connects
>> to the CA and downloads the certificate during the TLS handshake.
>>
>> ## Performance benefit ##
>>
>> Preloading the intermediate CA data avoids the just-in-time network
>> fetch, which delays the connection.
>>
>> ## Privacy ##
>>
>> Avoiding the network fetch is also a privacy improvement, as it
>> doesn't disclose your browsing pattern to the certificate authority
>> that issued the misconfigured website's certificate.
>>
>> It's also helpful because it's possible to "fingerprint" a user by a
>> website carefully analyzing what other websites load or do not load
>> due to which intermediate CAs have been "seen" by a user [1].
>> Preloading ensures that all users have "seen" all the same
>> intermediate CAs.
>>
>> ## Protection ##
>>
>> The Mozilla CA program requires all members to disclose unconstrained
>> intermediate CAs before using them, as a safety measure. However,
>> there is not currently a way to technically enforce that. Intermediate
>> Preloading could eventually be used to perform that enforcement, by
>> only trusting intermediate CAs which were disclosed already. This
>> protects against a scenario where a compromised CA is coerced into
>> producing an undisclosed secret intermediate CA, which is then used to
>> attack people on the Internet.
>>
>>
>> ## Future usefulness ##
>>
>> The experimental CRLite concept [2] (aiming to replace OCSP) requires
>> a mapping of Intermediate CAs to an “enrollment status” flag. Since we
>> need to enumerate the Intermediate CAs for that future functionality,
>> actually preloading their data is a rational extension.
>>
>>
>> # How it works #
>>
>> Intermediate Preloading fetches ~100 intermediate certificate
>> authorities' certificates once a day during the Kinto main update [3],
>> and loads them into your profile, as if you had visited a site that
>> used that intermediate. At 100 per day, summing to between 300-500 kB,
>> it will take approximately three weeks for a Firefox profile to
>> preload all intermediates [4]. We will likely increase the rate after
>> the initial experiments.
>>
>> The certificate data is loaded into the NSS Certificate Database, as
>> is done for normal web browsing. In the future, we will use the faster
>> Rust "rkv" database, in Bug 1530545.
>>
>> Currently preloading is only enabled for desktop users on Nightly. We
>> will want to (A) restrict the download to be only over WiFi and maybe
>> plugged in, and (B) switch to the faster database before enabling on
>> mobile. (Bug 1520297)
>>
>>
>> # What we expect #
>>
>> Intermediate Preloading should reduce the number of
>> SEC_ERROR_UNKNOWN_ISSUER errors seen by Firefox users over time, which
>> is our most common secure connection error. It will also remove the
>> tracking vector (above, Privacy), and