https://wiki.mozilla.org/api.php?action=feedcontributions&user=Dkeeler&feedformat=atomMozillaWiki - User contributions [en]2024-03-29T01:05:50ZUser contributionsMediaWiki 1.27.4https://wiki.mozilla.org/index.php?title=CA/Revocation_Checking_in_Firefox&diff=1249913CA/Revocation Checking in Firefox2024-02-05T20:05:36Z<p>Dkeeler: remove reference to intermediates in EV revocation checking</p>
<hr />
<div>== Revocation Is Important ==<br />
Support for revoking certificates is important, because otherwise stolen and misissued certificates can be misused until they expire. History, from DigiNotar (malicious misissuance) to Heartbleed (private key theft vulnerability) shows us that the ability to revoke certificates is important. Mozilla has and will continue to invest in certificate revocation checking.<br />
<br />
Recent changes to the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum Baseline Requirements (BRs)] and [https://www.mozilla.org/projects/security/certs/policy/ Mozilla’s Root Store Policy] have reduced the risks associated with exposure of the private key for each TLS certificate:<br />
* Subscriber Certificates issued on or after 1 September 2020 … MUST NOT have a Validity Period greater than 398 days.<br />
* Effective 2021‐10‐01, for validation of Domain Names and IP Addresses according to Section 3.2.2.4 and 3.2.2.5, any reused data, document, or completed validation MUST be obtained no more than 398 days prior to issuing the Certificate.<br />
<br />
Under these provisions, the maximum validity period and maximum re-use of domain validation for TLS certificates roughly corresponds to the typical minimum period of time for owning a domain name; i.e. one year. Assuming that most website operators correctly protect the private keys for their TLS certificates for the duration of the time that they own the domain name, these provisions reduce the risk of potential exposure of the private key of each TLS certificate that is revoked, replaced, or no longer needed by the original certificate subscriber. <br />
<br />
We still need to take into account situations in which the private key of a TLS certificate is obtained by an attacker or otherwise compromised. This can happen at any time during the certificate’s validity period if the website’s servers become compromised. <br />
<br />
Possession of a compromised private key for a TLS certificate alone does not allow an attacker to do anything. The attacker also needs some control over the victim's network connection. This means that the most likely attacks are either very localized (public WiFi, local network compromise) or very broad (DNS servers, governments). An attacker armed with the private key of a TLS certificate and an ability to control their victim’s network could impersonate the website corresponding to the compromised certificate in a way that would be undetectable to most users. Then even vigilant end users could be deceived into revealing personal information such as usernames and passwords, or downloading malware (containing malicious content or software) because they believe it is coming from a trusted site.<br />
<br />
An attacker armed with a compromised private key for a TLS certificate and an ability to control their victim’s network can:<br />
* Impersonate a valid website -- Present a fake website that looks like a valid website, and make the browser believe it is the real version of the website, because the browser finds that the TLS certificate of the fake site is valid.<br />
* Re-direct users to a fake site -- Users on a compromised network could be directed to a website using a fraudulent certificate and mistake it for the legitimate site.<br />
** In a rogue hotspot, “www.mybank.com” might resolve to an attacker’s server (instead of the real thing). Many users might not notice this and end up logging into an attacker’s website.<br />
<br />
== Challenges ==<br />
When a CA has to declare that a cert that used to be valid is no longer valid, we would like to ensure that this information is propagated to browsers as quickly as possible, but we also need to make sure that revocation mechanisms don't harm the user experience, in particular that they:<br />
<br />
* Don't add latency to TLS connection establishment<br />
* Don't require clients to store large amounts of data<br />
* Don't reveal more private information than necessary<br />
<br />
Revocation should result in “hard fail” to the greatest extent possible. This means that Firefox should assume the certificate is invalid if it cannot determine the revocation status. The opposite is called “soft fail”, in which Firefox assumes the certificate is valid if it cannot determine the status via some supported form of revocation checking.<br />
<br />
The standard approach to revocation checking is to use Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol ([http://tools.ietf.org/html/rfc6960 OCSP]). This has several drawbacks:<br />
<br />
* Revocation checking through CRLs or OCSP requests has high latency, even when it succeeds. CRLs can be an especially big hit to performance because they can grow to multiple megabyte files that must be downloaded before displaying a web page.<br />
* When OCSP fails or is blocked (e.g., by a captive portal), the page load can stall for up 15 seconds while the OCSP request times out.<br />
* The CA learns the IP address, location, a subset of the user's browsing history, and other sensitive information about the user through the OCSP request to its servers.<br />
* Because OCSP requests fail so often, failures result in certificate acceptance ("soft-fail"), which doesn’t actually protect users from an attack. (i.e. [https://www.imperialviolet.org/2012/02/05/crlsets.html "soft-fail revocation checks are like a seat-belt that snaps when you crash"]).<br />
<br />
[http://tools.ietf.org/html/rfc6066 OCSP stapling] addresses some of these problems, removing the latency and privacy harm when a good OCSP response is available. However, it still has the "soft-fail" problem -- an adversary can suppress the OCSP response.<br />
<br />
Our overall goal is to make revocation checking faster and more private, while maximizing the probability that any individual HTTPS connection will get good revocation information. We leverage several approaches here:<br />
<br />
* Centralized collection of revocation information and push to Firefox<br />
* Exemption of short-lived certificates from revocation checking<br />
* OCSP stapling with a must-staple indicator<br />
<br />
== Revocation Processing for Intermediate CA Certificates ==<br />
<br />
The relatively small number and low revocation frequency of CA certificates means that mechanisms that deliver a complete set of revoked certificates to Firefox are practical. However, due to the problems listed above, Firefox never attempts to download CRLs to the client. OCSP is also not used by Firefox to validate CA certificates.<br />
<br />
=== OneCRL ===<br />
In 2015, Mozilla [https://blog.mozilla.org/security/2015/03/03/revoking-intermediate-certificates-introducing-onecrl/ introduced OneCRL]. We gather CA certificate revocation information centrally, then push it out to clients. OneCRL currently contains two types of revocations:<br />
<br />
* All CA certificates that have been revoked by the CA. Mozilla now requires CAs to disclose all unconstrained CA certificates in [https://ccadb.org/ CCADB]. From this master list, Mozilla collects revocation information and periodically (usually on a monthly basis) updates OneCRL.<br />
* Exceptional revocations for both CA and end-entity certificates, including some that are not revoked by the CA. These entries are manually processed by Mozilla, typically as the result of a security incident involving the certificate.<br />
<br />
Revocations in OneCRL are typically based on the serial number and issuer of the revoked certificate. If multiple certificates with the same subject and public key need to be revoked, revocations based on the subject and public key hash are also supported.<br />
<br />
=== Multi-staple ===<br />
[https://tools.ietf.org/html/rfc6961 RFC 6961] defines a mechanism for stapling OCSP responses for CA certificates. Since FIrefox does not rely on OCSP to validate intermediate certificates, we have no plans to implement support for this.<br />
<br />
== Revocation Processing for End-Entity Certificates ==<br />
<br />
Revocation of end-entity certificates is checked in Firefox using the following mechanisms.<br />
<br />
=== Short-Lived Certificates ===<br />
A certificate with a must-staple extension is basically equivalent to a certificate with the same lifetime as the stapled OCSP response. (The only difference is that the OCSP response can be signed by a delegated key pair.) If the CA simply issues certificates with a lifetime on the order of an OCSP response, then there is no security benefit to performing revocation checking on these certificates. (This is basically the same approach taken by DNSSEC, which has short-lived signatures and no revocation.)<br />
<br />
Like OCSP must-staple, short-lived certificates are another fast-path option for websites, since a supporting browser will skip all revocation checks. Using short-lived certificates instead of a must-staple extension also removes the need to send an OCSP response in the handshake.<br />
<br />
Firefox does not perform any form of revocation checking for certificates with a validity period of less than 10 days. That period is configurable via the security.pki.cert_short_lifetime_in_days preference.<br />
<br />
=== OCSP Stapling ===<br />
[https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/ OCSP stapling] is a mechanism by which the web server periodically retrieves a fresh OCSP response from the CA and delivers it to the client in the TLS handshake. This eliminates the separate connection to a CA’s OCSP server that introduces latency and leaks browsing information. However, OCSP stapling is still susceptible to network failures and attacks. When Firefox receives a valid stapled OCSP response, it processes the response and does no other revocation checking. If the security.OCSP.enabled preference is set to ‘0’, stapled OCSP responses are ignored.<br />
<br />
=== OCSP Must-staple ===<br />
OCSP stapling allows good certificates to save the latency of a live OCSP fetch, but they don't provide much security benefit, since an attacker can omit the stapled response, suppress the live OCSP response, and soft-fail their way to victory. The [http://tools.ietf.org/html/rfc7633 TLS Feature Extension] for certificates protects against this attack by allowing the certificate to signal the browser to hard-fail if a stapled OCSP response is not present. When an end-entity certificate with the proper value in this extension is evaluated by Firefox, the stapled OCSP response will always be processed. If the response is not delivered via the TLS handshake or is not valid, Firefox will display an error rather than falling back to regular OCSP. Must-staple may be disabled via the security.ssl.enable_ocsp_must_staple or the security.ssl.enable_ocsp_stapling preferences.<br />
<br />
=== OCSP ===<br />
Firefox currently relies on traditional OCSP when a certificate is delivered without a stapled OCSP response. By default, Firefox ignores the revocation check (i.e. soft-fails) if a valid response is not received from the OCSP server within 2 seconds (10 seconds for an EV certificate). Setting the security.ocsp.require preference to ‘1’ switches to hard fail and triggers a certificate validation error if an OCSP response is not received within 10 seconds.<br />
<br />
If the OCSP server returns a status of “unknown”, Firefox will display the “SEC_ERROR_OCSP_UNKNOWN_CERT” error in a non-overrideable error message, regardless of the security.ocsp.require preference. Similarly, if the OCSP responder returns an error such as “trylater”, Firefox will display an error message.<br />
<br />
Notes: <br />
* Firefox [https://hg.mozilla.org/mozreview/gecko/rev/2249d58c94c867628b83d6c32eb0b5f64812a05c#index_header no longer] performs OCSP fetching using the HTTP GET method; Firefox uses the HTTP POST method.<br />
* Firefox caches OCSP responses until they expire or Firefox is restarted (the cache is not persistent). <br />
* If an OCSP response has no "nextUpdate", it is valid for 24 hours (plus "slop" of another 24 hours to deal with clock skew).<br />
* The maximum lifetime of an OCSP response for an end-entity is 10 days, even if the the "nextUpdate" value is farther in the future.<br />
<br />
=== CRLite ===<br />
Mozilla is [https://bugzilla.mozilla.org/show_bug.cgi?id=1429800 currently] (as of early 2019) preparing to test an out-of-band revocation mechanism based on an [https://mislove.org/publications/CRLite-Oakland.pdf academic paper] titled “CRLite: A Scalable System for Pushing All TLS Revocations to All Browsers”. In this mechanism, Mozilla produces a highly compressed representation of all trusted, non-expired certificates found in Certificate Transparency (CT) logs and their revocation status as asserted by the corresponding CRL. CRLite updates are delivered to the client using the same mechanism as OneCRL. <br />
<br />
Once fully implemented, CRLite is expected to be the primary mechanism used by Firefox to validate end-entity certificates. We expect that revocation checking will fall back to OCSP stapling or OCSP in the following situations:<br />
<br />
* If a CA has opted not to log a certificate, then it will not be delivered to the browser with any SCTs from recognized CT logs. When this happens (even for logged certificates), Firefox will fall back to OCSP stapling or OCSP in a hard-fail mode of operation for revocation checking.<br />
* There will be a small period of time - typically less than a day - after a certificate is first logged when CRLite won’t know about it and thus may not provide the correct revocation status. If the client’s latest update is timestamped after the date of the earliest SCT, then revocation checking will fall back to OCSP stapling or OCSP.<br />
* There may be certain cases in which all certificates signed by a specific CA certificate are not included in CRLite data. For example, if a CA doesn’t supply CRLs Mozilla may choose to exclude it, resulting in the use of OCSP for all certificates issued by that CA.<br />
* An enterprise policy and preference will be available to allow organizations to disable CRLite in certain situations, such as when they choose not to log specific publicly-trusted certificates or install their own private roots.<br />
<br />
== Extended Validation Rules ==<br />
In order to receive the EV UI, end-entity revocation checking must succeed via one of the currently implemented revocation checking mechanisms described above. If the security.OCSP.enabled preference is set to ‘0’ (disabled), OCSP checking is not performed and the EV UI will not appear for otherwise valid EV certificates.<br />
<br />
== Enterprise PKIs ==<br />
The Baseline Requirements forbid publicly-trusted CAs from issuing certificates without revocation pointers. For reasons of compatibility with other PKIs, such as enterprise PKIs, Firefox currently accepts such certificates if they are otherwise valid, and will continue to do so.<br />
<br />
== History of Revocation Checking Improvements in Firefox ==<br />
[[CA/History of Revocation Checking|A partial history of changes made to Firefox as of March 2017 in support of better revocation checking has been preserved.]]</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/Public_Key_Pinning/ReleaseEngineering&diff=1246191SecurityEngineering/Public Key Pinning/ReleaseEngineering2023-04-21T17:05:21Z<p>Dkeeler: remove stale references to Twitter, seceng@mozilla.org</p>
<hr />
<div>== Whom to contact in case of emergency ==<br />
* Mozilla: pinning@mozilla.org or security@mozilla.org (last resort)<br />
* Google: pki-contact@google.com or agl or security@google.com (last resort)<br />
* Dropbox: April King (aprilking@dropbox.com)<br />
* Facebook: Scott Renfro (srenfro@fb.com)<br />
<br />
== Implementation status ==<br />
Pinning is enabled by default in Nightly 32.<br />
<br />
== What critical Mozilla properties are we planning to pin? ==<br />
* AMO<br />
* aus4 is under question. We have a meeting with rstrong to discuss what, if any, benefits pinning provides over verifying the signature on the actual binaries and requiring those come from a known issuer. The drawback of pinning the updater is that we may break ourselves.<br />
<br />
== How to rollback pinning for Firefox ==<br />
Pinning is controlled by a preference, security.cert_pinning.enforcement_level. To disable pinning, set this pref to 0. In case of emergency, we can<br />
# Push a hotfix to disable the pinning pref. In case pinning breaks AMO, this will not be possible.<br />
# Push a chemspill. In case pinning breaks aus4, this will not be possible.<br />
# {{bug|1012875}} Wait 8 or 10 weeks until the pinset expires once it reaches stable, during which time users will not be able to reach sites that are pinned incorrectly.<br />
<br />
== How long do updates take? ==<br />
* Hotfix: almost all users in 2 days<br />
* Chemspill: unknown<br />
* Fennec (Google play): Majority users in 2 days<br />
<br />
== What about other platforms besides desktop? ==<br />
<br />
In {{bug|1012882}}, we decided to not pin on b2g right now, and (maybe) to wait for a couple of cycles to pin on Fennec.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=Modules/Core&diff=1240243Modules/Core2022-01-26T21:57:58Z<p>Dkeeler: add John Schanck to PSM peers, move others to peers emeritus</p>
<hr />
<div><noinclude><br />
'''Only module owners may edit this page.''' <br />
<br />
They may:<br />
<br />
* update any information about their module except the name of the owner<br />
* add or remove sub-modules<br />
* change the owner of a sub-module <br />
* add emeritus owners or peers<br />
<br />
Other changes, including changes of module owner or addition/removal of modules, must be agreed with the Module Ownership Module group, probably via a discussion in [https://www.mozilla.org/about/forums/#governance mozilla.governance].<br />
</noinclude><br />
{{Module<br />
|name=Accessibility<br />
|description=Support for platform accessibility APIs. Accessibility APIs are used by 3rd party software like screen readers, screen magnifiers, and voice dictation software, which need information about document content and UI controls, as well as important events like changes of focus.<br />
|owner=[mailto:jteh@mozilla.com Jamie Teh]<br />
|peers=[mailto:eitan@monotonous.org Eitan Isaacson], [mailto:mzehe@mozilla.com Marco Zehe], [mailto:mreschenberg@mozilla.com Morgan Reschenberg]<br />
|ownersemeritus=[mailto:aaron@moonset.net. Aaron Leventhal], [mailto:surkov.alexander@gmail.com Alexander Surkov]<br />
|peersemeritus=[mailto:dbolter@mozilla.com David Bolter], [mailto:tbsaunde+mozbugs@tbsaunde.org Trevor Saunders], [mailto:ginn.chen@oracle.com Ginn Chen], Evan Yan, [mailto:yzenevich@mozilla.com Yura Zenevich]<br />
|group=dev-accessibility<br />
|source_dirs=accessible/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=Animation<br />
|description=Declarative animations: CSS animations, CSS transitions, Web Animations API, and off-main thread animations.<br />
|owner=[mailto:brian@birchill.co.jp Brian Birtles] (:birtles)<br />
|peers=[mailto:boris@mozilla.com Boris Chiou] (:boris), [mailto:hikezoe.birchill@mozilla.com Hiroyuki Ikezoe] (:hiro), [mailto:mwoodrow@mozilla.com Matt Woodrow] (:mattwoodrow)<br />
|group=dev-platform<br />
|source_dirs=dom/animation; and animation-related and interpolation-related code in layout/style, gfx/layers, servo/components/style and servo/ports/gecko<br />
|components=Core::DOM::Animation, Core::CSS Transitions and Animations<br />
}}<br />
<br />
{{Module<br />
|name=Anti-Tracking<br />
|description=Tracking detection and content-blocking.<br />
|owner=[mailto:tihuang@mozilla.com Tim Huang]<br />
|peers=[mailto:amarchesini@Mozilla.com Andrea Marchesini], [mailto:dlee@mozilla.com Dimi Lee], [mailto:pbz@mozilla.com Paul Zühlcke], [mailto:jhofmann@mozilla.com Johann Hofmann]<br />
|peersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:ewright@mozilla.com Erica Wright], [mailto:xeonchen@gmail.com Gary Chen]<br />
|group=dev-platform<br />
|source_dirs=toolkit/components/antitracking/, several files under browser/ and netwerk/url-classifier/<br />
|components=Core::Privacy: Anti-Tracking<br />
}}<br />
<br />
{{Module<br />
|name=Browser WebAPI<br />
|description=Web API for rendering apps, browser windows and widgets.<br />
|owner=[mailto:Olli.Pettay@helsinki.fi Olli Pettay]<br />
|peers=[mailto:fabrice@mozilla.com Fabrice Desré]<br />
|ownersemeritus=[mailto:kchen@mozilla.com Kan-Ru Chen]<br />
|group=dev-webapi<br />
|source_dirs=dom/browser-element/<br />
|url=<br />
|components=Core::DOM<br />
}}<br />
<br />
{{Module<br />
|name=Build and Release Tools<br />
|description=Tools related to build and release automation and configuration of release builds.<br />
|owner=[mailto:aki@mozilla.com Aki Sasaki]<br />
|peers=<br />
|group=release-engineering<br />
|source_dirs=tools/update-packaging/ tools/update-verify<br />
|url=https://wiki.mozilla.org/ReleaseEngineering<br />
|components=Release Engineering::*<br />
}}<br />
<br />
{{Module<br />
|name=Build Config<br />
|description=The build system for Gecko and several mozilla.org hosted Gecko-based applications.<br />
|owner=[mailto:mh@glandium.org Mike Hommey] (:glandium)<br />
|peers=[mailto:mhentges@mozilla.com Mitchell Hentges], [mailto:bpostelnicu@mozilla.com Andi-Bogdan Postelnicu]<br />
|ownersemeritus=Chris Manchester (2019-2020), Gregory Szorc (2013-2019), Ted Mielczarek (2008-[https://blog.mozilla.org/ted/2013/03/07/gregory-szorc-is-now-the-build-config-module-owner/ 2013]), Benjamin Smedberg (???-[http://benjamin.smedbergs.us/blog/2008-04-30/more-changing-of-the-guard-ted-mielczarek/ 2008]), <br />
|peersemeritus=Ted Mielczarek, Ralph Giles, Gregory Szorc, Chris Manchester, Mike Shal, Nathan Froyd, Ricky Stewart, David Major<br />
|group=dev-builds<br />
|source_dirs=build/, config/, python/mozbuild, tools/cross-commit, tools/cvs2hg-import.py, tools/cvsmgmt/, tools/elf-dynstr-gc/, tools/trees.pl, browser/config/mozconfigs/, mobile/config/mozconfigs/, xulrunner/config/mozconfigs/<br />
|url=http://www.mozilla.org/build/<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=Code Analysis and Debugging Tools<br />
|description=Tools for debugging Mozilla code or for analyzing speed, memory use, and other characteristics of it.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=<br />
|group=dev-performance<br />
|source_dirs=tools/codesighs/, tools/debug/, tools/dreftool/, tools/dumpdeps/, tools/jprof/, tools/leak-gauge/, tools/leaky/, tools/memory/, tools/module-deps/, tools/performance/, tools/post_compile/, tools/preloader/, tools/rb/, tools/reorder/, tools/trace-malloc/, tools/uuiddeps/, <br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Content Security<br />
|description=Native content-based security features enforced in the ContentSecurityManager, including: Content Security Policy (CSP), Mixed Content Blocker (MCB), Referrer Policy, Subresource Integrity (SRI), Cross-Origin Resource Sharing (CORS), X-Frame-Options, X-Content-Type-Options: nosniff, HTTPS-Only-Mode, Sanitizer API, Sec-Fetch Metadata, and top-level data: URI blocking.<br />
|owner=[mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]<br />
|peers=[mailto:tvyas@mozilla.com Tanvi Vyas], [mailto:dveditz@mozilla.com Dan Veditz], [mailto:amarchesini@mozilla.com Andrea Marchesini], [mailto:fbraun@mozilla.com Frederik Braun]<br />
|peersemeritus=[mailto:mozilla@sidstamm.com Sid Stamm], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:jkt@mozilla.com Jonathan Kingston], [mailto:tnguyen@mozilla.com Thomas Nguyen], François Marier<br />
|group=dev-security<br />
|source_dirs=dom/security<br />
|components=Core::DOM: Security<br />
}}<br />
<br />
{{Module<br />
|name=Cookies<br />
|description=<br />
|owner=[mailto:amarchesini@mozilla.com Andrea Marchesini]<br />
|peers=[mailto:honzab.moz@firemni.cz Honza Bambas] <br />
|ownersemeritus=Monica Chew<br />
|peersemeritus=[mailto:josh@joshmatthews.com Josh Matthews], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dwitte@gmail.com Dan Witte], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)], [mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|group=dev-platform<br />
|source_dirs=netwerk/cookie/<br />
|url=<br />
|components=Core::Networking: Cookies<br />
}}<br />
<br />
{{Module<br />
|name=Permissions<br />
|description=<br />
|owner=[mailto:tihuang@mozilla.com Tim Huang]<br />
|peers=[mailto:amarchesini@mozilla.com Andrea Marchesini], [mailto:jhofmann@mozilla.com Johann Hofmann], [mailto:pbz@mozilla.com Paul Zühlcke]<br />
|ownersemeritus=Monica Chew, [mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peersemeritus=[mailto:josh@joshmatthews.com Josh Matthews], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dwitte@gmail.com Dan Witte], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)], [mailto:honzab.moz@firemni.cz Honza Bambas]<br />
|group=dev-platform<br />
|source_dirs=extensions/permissions/<br />
|url=<br />
|components=Core :: Permission Manager<br />
}}<br />
<br />
{{Module<br />
|name=Cycle Collector<br />
|description=Code to break and collect objects within reference cycles<br />
|owner=[https://mozillians.org/en-US/u/mccr8/ Andrew McCreight]<br />
|peers=Peter Van der Beken, Olli Pettay<br />
|peersemeritus=David Baron<br />
|source_dirs=xpcom/base/nsCycleCollector.* and some support headers<br />
|components=Core::XPCOM<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=C++/Rust usage, tools, and style<br />
|description=Aspects of C++ use such as language feature usage, standard library versions/usage, compiler/toolchain versions, formatting and naming style, and aspects of Rust use as needs arise<br />
|owner=[mailto:bholley@mozilla.com Bobby Holley]<br />
|peers=[mailto:bballo@mozilla.com Botond Ballo], [mailto:glandium@mozilla.com Mike Hommey]<br />
|ownersemeritus=[mailto:eakhgari@mozilla.com Ehsan Akhgari]<br />
|peersemeritus=[mailto:jwalden@mozilla.com Jeff Walden], [mailto:sgiesecke@mozilla.com Simon Giesecke]<br />
|source_dirs=non-third-party C++ and Rust code in the tree<br />
|components=Various components<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=docshell<br />
|description=<br />
|owner=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:nika@thelayzells.com Nika Layzell]<br />
|peers=[mailto:peterv@propagandism.org Peter Van der Beken], [mailto:afarre@mozilla.com Andreas Farre]<br />
|ownersemeritus=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|peersemeritus=[mailto:jstenback@gmail.com Johnny Stenback], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:justin.lebar@gmail.com Justin Lebar], [mailto:sawang@mozilla.com Samael Wang], [mailto:kyle@nonpolynomial.com Kyle Machulis]<br />
|group=dev-platform<br />
|source_dirs=docshell/, uriloader/<br />
|url=<br />
|components=Core::Document Navigation<br />
}}<br />
<br />
{{Module<br />
|name=DLL Services<br />
|description=Windows dynamic linker instrumentation and blocking<br />
|owner=[mailto:tkikuchi@mozilla.com Toshihito Kikuchi]<br />
|ownersemeritus=Aaron Klotz<br />
|peers=[mailto:davidp99@gmail.com David Parks] (DLL Interceptor), [mailto:mhowell@mozilla.com Molly Howell] (Backup reviewer)<br />
|source_dirs=toolkit/xre/dllservices/**<br />
|components=Core::DLL Services<br />
}}<br />
<br />
{{Module<br />
|name=Document Object Model<br />
|description=<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:hsivonen@iki.fi Henri Sivonen], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:baku@mozilla.com Andrea Marchesini], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:nika@thelayzells.com Nika Layzell], [mailto:afarre@mozilla.com Andreas Farre], [mailto:emilio@crisal.io Emilio Cobos], [mailto:asuth@mozilla.com Andrew Sutherland], [mailto:echen@mozilla.com Edgar Chen]<br />
|ownersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]<br />
|peersemeritus=[mailto:justin.lebar@gmail.com Justin Lebar], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:bent.mozilla@gmail.com Ben Turner], [mailto:mounir@lamouri.fr Mounir Lamouri], [mailto:me@kylehuey.com Kyle Huey], [mailto:wmccloskey@mozilla.com Bill McCloskey], [mailto:ben@wanderview.com Ben Kelly], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:kyle@nonpolynomial.com Kyle Machulis], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|group=dev-tech-dom<br />
|source_dirs=dom/*, except directories covered by other modules<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM, Core::DOM: CSS Object Model, Core::DOM: Core & HTML<br />
}}<br />
<br />
{{Module<br />
|name=DOM File<br />
|description=DOM Blob, File and FileSystem APIs <br />
|owner=[mailto:amarchesini@Mozilla.com Andrea Marchesini]<br />
|peers=[mailto:olli@pettay.fi Olli Pettay]<br />
|group=dev-platform<br />
|source_dirs=dom/file, dom/filesystem<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM: File<br />
}}<br />
<br />
{{Module<br />
|name=Event Handling<br />
|description=DOM Events and Event Handling <br />
|owner=[mailto:olli@pettay.fi Olli Pettay], [mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:echen@mozilla.com Edgar Chen]<br />
|peersemeritus=[mailto:sshih@mozilla.com Stone Shih]<br />
|group=dev-platform<br />
|source_dirs=dom/events and event handling related code elsewhere <br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM: Events, Core::DOM: UI Events & Focus Handling<br />
}}<br />
<br />
{{Module<br />
|name=Web Workers<br />
|description=<br />
|owner=[mailto:asuth@mozilla.com Andrew Sutherland]<br />
|peers=[mailto:baku@mozilla.com Andrea Marchesini], [mailto:ytausky@mozilla.com Yaron Tausky]<br />
|ownersemeritus=[mailto:bent.mozilla@gmail.com Ben Turner]<br />
|peersemeritus=[mailto:mrbkap@mozilla.com Blake Kaplan], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey], [mailto:bkelly@mozilla.com Ben Kelly]<br />
|group=dev-platform<br />
|source_dirs=dom/workers/<br />
|url=https://developer.mozilla.org/En/Using_web_workers<br />
|components=Core::DOM: Workers<br />
}}<br />
<br />
{{Module<br />
|name=IndexedDB<br />
|description=<br />
|owner=[mailto:jvarga@mozilla.com Jan Varga]<br />
|peers=[mailto:btseng@mozilla.com Bevis Tseng], [mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:baku@mozilla.com Andrea Marchesini]<br />
|ownersemeritus=[mailto:bent.mozilla@gmail.com Ben Turner]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey]<br />
|group=dev-platform<br />
|source_dirs=dom/indexedDB/<br />
|url=https://developer.mozilla.org/en/IndexedDB<br />
|components=Core::DOM: IndexedDB<br />
}}<br />
<br />
{{Module<br />
|name=Editor<br />
|description=<br />
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]<br />
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|group=dev-platform<br />
|source_dirs=editor/<br />
|url=http://www.mozilla.org/editor/<br />
|components=Core::Editor<br />
}}<br />
<br />
{{Module<br />
|name=Gecko Profiler<br />
|description=Gecko's built-in profiler<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|peers=[mailto:gsquelart@mozilla.com Gerald Squelart], [mailto:gtatum@mozilla.com Greg Tatum], [mailto:canaltinova@mozilla.com Nazim Can Altinova], [mailto:jseward@mozilla.com Julian Seward] (LUL), [mailto:kvijayan@mozilla.com Kannan Vijayan] (JS integration), [mailto:brennie@mozilla.com Barret Rennie] (Screenshots).<br />
|ownersemeritus=[mailto:b56girard@gmail.com Benoit Girard]<br />
|peersemeritus=[mailto:shu@mozilla.com Shu-yu Guo] (JS integration), [mailto:tlee@mozilla.com Thinker Lee] (TaskTracer), [mailto:cyu@mozilla.com Cervantes Yu] (TaskTracer), Nicholas Nethercote<br />
|group=dev-platform<br />
|source_dirs=tools/profiler/<br />
|url=https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler<br />
|components=Core::Gecko Profiler<br />
}}<br />
<br />
{{Module<br />
|name=GeckoView<br />
|description=Framework for embedding Gecko into Android applications<br />
|owner=[mailto:asferro@mozilla.com Agi Sferro]<br />
|peers=[mailto:mkato.birchill@mozilla.com Makoto Kato], [mailto:istorozhko@mozilla.com Irene Storozhko]<br />
|ownersemeritus=James Willcox<br />
|peersemeritus=Dylan Roeh, Eugen Sawin, Aaron Klotz, Jim Chen, Randall E. Barker<br />
|source_dirs=mobile/android/, widget/android/, hal/android/<br />
|url=https://wiki.mozilla.org/Mobile/GeckoView<br />
|components=GeckoView::General<br />
}}<br />
<br />
{{Module<br />
|name=Global Key Bindings<br />
|description=Global hot keys in Mozilla for the browser, editor, mail-news and widgets. Does not include underlined menu accelerators and the like, as those are part of i18n.<br />
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|group=dev-accessibility<br />
|source_dirs=dom/events (and platform specific directories under it)<br />
|url=http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html<br />
|components=Core::Keyboard: Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Graphics<br />
|description=Mozilla graphics API<br />
|owner=[mailto:jrmuizel@mozilla.com Jeff Muizelaar](Thebes, QCMS, YCbCr, Cairo/Pixman, Regions, OS X, Other)<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peers=[mailto:bas.schouten@live.nl Bas Schouten](Layers, Windows), [mailto:kelsey.gilbert@mozilla.com Kelsey Gilbert](WebGL, ANGLE), [mailto:mwoodrow@mozilla.com Matt Woodrow](Layers API), [mailto:jfkthame@googlemail.com Jonathan Kew](text/fonts), [mailto:nsilva@mozilla.com Nicolas Silva](MozSurface), [mailto:ncameron@mozilla.com Nick Cameron], [mailto:sikeda@mozilla.com Sotaro Ikeda](B2G), [mailto:jnicol@mozilla.com Jamie Nicol](Android), [mailto:mstange@themasta.com Markus Stange](OS X), [mailto:lsalzman@mozilla.com Lee Salzman](Skia, Canvas2D), [mailto:rhunt@mozilla.com Ryan Hunt](OMTP), [mailto:gwatson@mozilla.com Glenn Watson ](WebRender), [mailto:dmalyshau@mozilla.com Dzmitry Malyshau](WebRender)<br />
|peersemeritus=[mailto:bgirard@mozilla.com Benoit Girard](Compositor, Performance), [mailto:ajuma.bugzilla@alijuma.com Ali Juma], [mailto:george@mozilla.com George Wright](Canvas2D), [mailto:mchang@mozilla.com Mason Chang], [mailto:dvander@mozilla.com David Anderson], [mailto:clord@mozilla.com Christopher Lord], [mailto:jdaggett@mozilla.com John Daggett](text/fonts), [mailto:bjacob@mozilla.com Benoit Jacob](gfx/gl), [mailto:jdrew@mozilla.com Joe Drew], [mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:snorp@mozilla.com James Willcox](Android),<br />
|group=dev-platform<br />
|source_dirs=gfx/, dom/canvas/<br />
|url=https://wiki.mozilla.org/Platform/GFX https://wiki.mozilla.org/Gecko:Layers https://wiki.mozilla.org/Gecko:2DGraphicsSketch<br />
|components=Core::Graphics, Core::Graphics: Layers, Core::Graphics: Text, Core::Graphics: WebRender, Core::GFX: Color Management, Core::Canvas: 2D, Core::Canvas: WebGL<br />
}}<br />
<br />
{{Module<br />
|name=WebGPU (Graphics submodule)<br />
|description=WebGPU implementation<br />
|owner=[mailto:dmalyshau@mozilla.com Dzmitry Malyshau]<br />
|peers=[mailto:josh@joshgroves.com Joshua Groves], [mailto:kelsey.gilbert@mozilla.com Kelsey Gilbert],<br />
|group=dev-platform<br />
|source_dirs=dom/webgpu<br />
|url=https://wiki.mozilla.org/Platform/GFX/WebGPU<br />
|components=Core::Graphics::WebGPU<br />
}}<br />
<br />
{{Module<br />
|name=APZ (Graphics submodule)<br />
|description=Asynchronous panning and zooming<br />
|owner=[mailto:bballo@mozilla.com Botond Ballo]<br />
|ownersemeritus=[mailto:kgupta@mozilla.staktrace.com Kartikaya Gupta]<br />
|peers=[mailto:kgupta@mozilla.staktrace.com Kartikaya Gupta], [mailto:tnikkel@mozilla.com Timothy Nikkel], [mailto:rhunt@mozilla.com Ryan Hunt], [mailto:mstange@mozilla.com Markus Stange]<br />
|group=dev-platform<br />
|source_dirs=gfx/layers/apz<br />
|url=https://wiki.mozilla.org/Platform/GFX/APZ<br />
|components=Core::Panning and Zooming<br />
}}<br />
<br />
{{Module<br />
|name=Moz2D (Graphics submodule)<br />
|description=Platform independent 2D graphics API<br />
|owner=[mailto:bschouten@mozilla.com Bas Schouten]<br />
|peers=[mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:jwatt@jwatt.org Jonathan Watt]<br />
|group=dev-platform<br />
|source=gfx/2d<br />
|url=https://wiki.mozilla.org/Platform/GFX/Moz2D<br />
|components=Core::Graphics<br />
}}<br />
<br />
{{Module<br />
|name=Legacy HTML Parser<br />
|description=<br />
|owner=[mailto:mrbkap@gmail.com Blake Kaplan]<br />
|peers=[mailto:dbaron@dbaron.org David Baron], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:rbs@maths.uq.edu.au rbs@maths.uq.edu.au]<br />
|peersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]<br />
|source_dirs=parser/htmlparser<br />
|url=http://www.mozilla.org/newlayout/doc/parser.html<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=HAL<br />
|description=Hardware Abstraction Layer<br />
|owner=[mailto:gsvelto@mozilla.com Gabriele Svelto]<br />
|peers=<br />
|group=dev-platform<br />
|source_dirs=hal/<br />
|components=Core::Hardware Abstraction Layer (HAL)<br />
}}<br />
<br />
{{Module<br />
|name=HTML Parser<br />
|description=The HTML Parser transforms HTML source code into a DOM. It conforms to the HTML specification, and is mostly translated automatically from Java to C++.<br />
|owner=[mailto:hsivonen@iki.fi Henri Sivonen]<br />
|peers=[mailto:wchen@mozilla.com William Chen]<br />
|group=dev-platform<br />
|source_dirs=parser/html<br />
|url=http://about.validator.nu/<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=I18N Library<br />
|description=<br />
|owner=[mailto:hsivonen@hsivonen.fi Henri Sivonen (encoding)], [mailto:jfkthame@gmail.com Jonathan Kew (except to encoding)]<br />
|peers=[mailto:VYV03354@nifty.ne.jp Masatoshi Kimura], [mailto:gandalf@aviary.pl Zibi Braniecki], [mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]<br />
|ownersemeritus=[mailto:jshin1987@gmail.com Jungshik Shin], [mailto:smontagu@smontagu.org Simon Montagu]<br />
|group=dev-i18n<br />
|source_dirs=intl/<br />
|url=http://mozilla.org/projects/intl/index.html<br />
|components=Core::Internationalization<br />
}}<br />
<br />
{{Module<br />
|name=ImageLib<br />
|description=<br />
|owner=[mailto:tnikkel@gmail.com Timothy Nikkel]<br />
|peers=[mailto:aosmond@mozilla.com Andrew Osmond], [mailto:jmuizelaar@mozilla.com Jeff Muizelaar]<br />
|peersemeritus=[mailto:seth.bugzilla@blackhail.net Seth Fowler], [mailto:netzen@gmail.com Brian Bondy], [mailto:justin.lebar@gmail.com Justin Lebar]<br />
|group=dev-platform<br />
|source_dirs=media/libjpeg/, media/libpng/, image/, modules/zlib/<br />
|url=<br />
|components=Core::ImageLib<br />
}}<br />
<br />
{{Module<br />
|name=IPC<br />
|description=Native message-passing between threads and processes<br />
|owner=[mailto:jld@mozilla.com Jed Davis]<br />
|ownersemeritus=Chris Jones, Bill McCloskey<br />
|peers=[mailto:nika@thelayzells.com Nika Layzell], [mailto:jmathies@mozilla.com Jim Mathies], [mailto:amccreight@mozilla.com Andrew McCreight]<br />
|peersemeritus=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:bent.mozilla@gmail.com Ben Turner], David Anderson, Kan-Ru Chen, Bevis Tseng, Ben Kelly<br />
|group=dev-platform<br />
|source_dirs=ipc/glue/, ipc/ipdl/, ipc/chromium/<br />
|url=<br />
|components=Core::IPC}}<br />
<br />
{{Module<br />
|name=JavaScript<br />
|description=JavaScript engine (SpiderMonkey)<br />
|owner=[mailto:jdemooij@mozilla.com Jan de Mooij]<br />
|peers=André Bargull, [mailto:tcampbell@mozilla.com Ted Campbell], [mailto:jcoppeard@mozilla.com Jon Coppeard], [mailto:sphink@gmail.com Steve Fink], [mailto:arai.unmht@gmail.com Tooru Fujisawa], [mailto:evilpies@gmail.com Tom Schuster], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:jwalden@mit.edu Jeff Walden], [mailto:ystartsev@mozilla.com Yulia Startsev], [mailto:mgaudet@mozilla.com Matthew Gaudet], [mailto:iireland@mozilla.com Iain Ireland], [mailto:nicolas.b.pierron@mozilla.com Nicolas Pierron], [mailto:ccullen@mozilla.com Caroline Cullen], [mailto:nfitzgerald@mozilla.com Nick Fitzgerald], [mailto:luke@mozilla.com Luke Wagner], [mailto:sunfish@mozilla.com Dan Gohman], [mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peersemeritus=[mailto:brendan@mozilla.org Brendan Eich], [mailto:hv1989@gmail.com Hannes Verschore], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:wmccloskey@mozilla.com Bill McCloskey], Shu-yu Guo, Niko Matsakis, Eddy Bruel, [mailto:danderson@mozilla.com David Anderson], [mailto:igor@mir2.org Igor Bukanov], Andreas Gal, Eric Faust, Ashley Hauck, [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:till@tillschneidereit.net Till Schneidereit], Nicholas Nethercote, Jason Orendorff<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src<br />
|url=http://www.mozilla.org/js/spidermonkey,<br />
http://developer.mozilla.org/en/docs/About_JavaScript<br />
|components=Core::JavaScript Engine<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript JIT<br />
|description=JavaScript engine's JIT compilers (IonMonkey, Baseline)<br />
|owner=[mailto:jdemooij@mozilla.com Jan de Mooij]<br />
|peers=André Bargull, [mailto:bbouvier@mozilla.com Benjamin Bouvier], [mailto:tcampbell@mozilla.com Ted Campbell], [mailto:ccullen@mozilla.com Caroline Cullen], [mailto:mgaudet@mozilla.com Matthew Gaudet], [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:iireland@mozilla.com Iain Ireland], [mailto:nicolas.b.pierron@mozilla.com Nicolas Pierron], [mailto:evilpies@gmail.com Tom Schuster], [mailto:sstangl@mozilla.com Sean Stangl], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:luke@mozilla.com Luke Wagner]<br />
|peersemeritus=[mailto:danderson@mozilla.com David Anderson], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:hv1989@gmail.com Hannes Verschore]<br />
|group=dev-tech-js-engine-internals<br />
|source_dirs=js/src/jit<br />
|url=http://www.mozilla.org/js/spidermonkey<br />
|components=Core::JavaScript Engine: JIT<br />
}}<br />
<br />
{{Module<br />
|name=jsat<br />
|description=Javascript screen reader that is used in Android and B2G<br />
|owner=[mailto:eitan@monotonous.org Eitan Isaacson]<br />
|peers=[mailto:yzenevich@mozilla.com Yura Zenevich]<br />
|group=dev-accessibility<br />
|source_dirs=accessible/jsat/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=js-tests<br />
|description=JavaScript test suite<br />
|owner=[mailto:bclary@bclary.com Bob Clary]<br />
|peers=<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tests/<br />
|url=http://www.mozilla.org/js/tests/library.html<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Layout Engine<br />
|description=rendering tree construction, layout (reflow), etc.<br />
|owner=[mailto:dholbert@mozilla.com Daniel Holbert]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:jfkthame@gmail.com Jonathan Kew], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:matt.woodrow@gmail.com Matt Woodrow], [mailto:xidorn+moz@upsuper.org Xidorn Quan], [mailto:emilio@crisal.io Emilio Cobos Álvarez], [mailto:mats@mozilla.com Mats Palmgren], [mailto:tlin@mozilla.com Ting-Yu Lin]<br />
|ownersemeritus=[mailto:dbaron@dbaron.org David Baron]<br />
|peersemeritus=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|group=dev-platform<br />
|source_dirs=layout/%, layout/base/, layout/build/, layout/doc/, layout/forms/, layout/generic/, layout/html/, layout/printing/, layout/tables/, layout/tools/<br />
|url=https://wiki.mozilla.org/Gecko:Overview#Layout<br />
|components=Core::Layout, Core::Layout: Block and Inline, Core::Layout: Columns, Core::Layout: Flexbox, Core::Layout: Floats, Core::Layout: Form Controls, Core::Layout: Generated Content, Lists, and Counters, Core::Layout: Grid, Core::Layout: Images, Video, and HTML Frames, Core::Layout: Positioned, Core::Layout: Ruby, Core::Layout: Scrolling and Overflow, Core::Layout: Tables, Core::Layout: Text and Fonts, Core::Print Preview, Core::Printing: Output<br />
}}<br />
<br />
{{Module<br />
|name=libjar<br />
|description=The JAR handling code (protocol handler, stream implementation, and zipreader/zipwriter).<br />
|owner=[mailto:vgosu@mozilla.com Valentin Gosu]<br />
|ownersemeritus=Taras Glek, Michael Wu, Aaron Klotz<br />
|peers=[mailto:kershaw@mozilla.com Kershaw Chang]<br />
|peersemeritus=Michal Novotny<br />
|group=dev-platform<br />
|source_dirs=modules/libjar<br />
|url=<br />
|components=Core::Networking: JAR<br />
}}<br />
<br />
{{Module<br />
|name=MathML<br />
|description=MathML is a low-level specification for describing mathematics which provides a foundation for the inclusion of mathematical expressions in Web pages.<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|group=dev-tech-mathml<br />
|source_dirs=layout/mathml/<br />
|url=http://www.mozilla.org/projects/mathml/<br />
|components=Core::MathML<br />
}}<br />
<br />
{{Module<br />
|name=Media Playback<br />
|description=HTML Media APIs, including Media Source Extensions and non-MSE video/audio element playback, and Encrypted Media Extensions. (WebRTC and WebAudio not included).<br />
|owner=[mailto:jyavenard@mozilla.com Jean-Yves Avenard]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:cpearce@mozilla.com Chris Pearce]<br />
|peers=[mailto:kinetik@flim.org Matthew Gregan], [mailto:bvandyk@mozilla.com Bryce Van Dyk], [mailto:jolin@mozilla.com John Lin], [mailto:alwu@mozilla.com Alastor Wu], [mailto:jwwang@mozilla.com JW Wang]<br />
|group=dev-media<br />
|source_dirs=dom/media, media/gmp-clearkey/, media/libcubeb/, media/libnestegg/, media/libogg/, media/libopus/, media/libstagefright/, media/libtheora/, media/libtremor/, media/libvorbis/, media/libvpx/, media/omx-plugin/, media/rlz/<br />
|url=<br />
|components=Core::Audio/Video<br />
}}<br />
<br />
{{Module<br />
|name=Media Transport<br />
|description=Pluggable transport for real-time media<br />
|owner=[mailto:ekr@rtfm.com Eric Rescorla]<br />
|peers=[mailto:bcampen@mozilla.com Byron Campen], [mailto:abr@mozilla.com Adam Roach], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]<br />
|group=dev-media<br />
|source_dirs=media/mtransport<br />
|url=<br />
|components=Core::WebRTC::Networking<br />
}}<br />
<br />
{{Module<br />
|name=Memory Allocator<br />
|description=Most things related to memory allocation in Gecko, including jemalloc, replace-malloc, DMD (dark matter detector), logalloc, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|peers=<br />
|peersemeritus=Eric Rahm, Nicholas Nethercote<br />
|group=dev-platform<br />
|source_dirs=memory/<br />
|components=Core::DMD, Core::jemalloc<br />
}}<br />
<br />
{{Module<br />
|name=mfbt<br />
|description=mfbt is a collection of headers, macros, data structures, methods, and other functionality available for use and reuse throughout all Mozilla code (including SpiderMonkey and Gecko more broadly).<br />
|owner=[mailto:jwalden@mit.edu Jeff Walden]<br />
|peers=[mailto:Ms2ger@gmail.com Ms2ger], [mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|group=dev-platform<br />
|source_dirs=mfbt/<br />
|url=<br />
|components=Core::MFBT<br />
}}<br />
<br />
{{Module<br />
|name=Mozglue<br />
|description=Glue library containing various low-level functionality, including a dynamic linker for Android, a DLL block list for Windows, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|peers=[mailto:kgupta@mozilla.com Kartikaya Gupta] (mozglue/android), [mailto:nchen@mozilla.com Jim Chen] (mozglue/android)<br />
|group=dev-platform<br />
|source_dirs=mozglue/<br />
|components=Core::mozglue<br />
}}<br />
<br />
{{Module<br />
|name=mozilla-toplevel<br />
|description=The top level directory for the mozilla tree.<br />
|owner=[[Modules/Firefox_Technical_Leadership|Firefox Technical Leadership module]]<br />
|ownersemeritus=[mailto:brendan@mozilla.org Brendan Eich]<br />
|peers=<br />
|group=<br />
|source_dirs=tools/README<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=MSCOM<br />
|description=Integration with Microsoft Distributed COM<br />
|owner=[mailto:jteh@mozilla.com Jamie Teh]<br />
|ownersemeritus=Aaron Klotz<br />
|peers=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|group=dev-platform<br />
|source_dirs=ipc/mscom/%<br />
|url=<br />
|components=Core::IPC: MSCOM}}<br />
<br />
{{Module<br />
|name=Necko<br />
|description=The Mozilla Networking Library<br />
|owner=[mailto:dd.mozilla@gmail.com Dragana Damjanovic]<br />
|peers= [mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:mnovotny@mozilla.com Michal Novotny], [mailto:valentin.gosu@gmail.com Valentin Gosu], [mailto:kershaw@mozilla.com Kershaw Chang], [mailto:juhsu@mozilla.com Junior Hsu]<br />
|ownersemeritus=[mailto:mcmanus@ducksong.com Patrick McManus], [mailto:cbiesinger@gmail.com Christian Biesinger] |peersemeritus= Shih-Chiang Chien, [mailto:bzbarsky@mit.edu Boris Zbarsky], Steve Workman, Nick Hurley, [mailto:daniel@haxx.se Daniel Stenberg ], [mailto:jduell.mcbugs@gmail.com Jason Duell]<br />
|group=dev-tech-network<br />
|source_dirs=netwerk/%, netwerk/base/, netwerk/build/, netwerk/cache/, netwerk/dns/, netwerk/locales/, netwerk/mime/, netwerk/protocol/, netwerk/resources/, netwerk/socket/, netwerk/streamconv/, netwerk/system/, netwerk/test/, netwerk/testserver/<br />
|url=http://www.mozilla.org/projects/netlib/, https://developer.mozilla.org/en/Necko<br />
|components=Core::Networking, Core::Networking: Cache, Core::Networking: Cookies, Core::Networking: FTP, Core::Networking: File, Core::Networking: HTTP, Core::Networking: JAR, Core::Networking: Websockets<br />
}}<br />
<br />
{{Module<br />
|name=NodeJS usage, tools, and style<br />
|description=Advises on the use of NodeJS and npm packages at build and runtime. Reviews additions/upgrades/removals of vendored npm packages. Works with appropriate teams to maintain automated license and security audits of npm packages. Works with the security team and relevant developers to respond to vulnerabilities in NodeJS and vendored npm packages.<br />
|owner=[mailto:dmosedale@mozilla.com Dan Mosedale]<br />
|peers=[mailto:mbanner@mozilla.com Mark Banner], [mailto:dcoates@mozilla.com Danny Coates], [mailto:khudson@mozilla.com Kate Hudson], [mailto:elee@mozilla.com Ed Lee], [mailto:dtownsend@mozilla.com Dave Townsend]<br />
|source_dirs=package.json, package-lock.json, node_modules and others as appropriate<br />
|components=Various components<br />
|forum=[https://wiki.mozilla.org/Firefox/firefox-dev firefox-dev], #nodejs on slack<br />
}}<br />
<br />
{{Module<br />
|name=NSPR<br />
|description=Netscape Portable Runtime<br />
|owner=[mailto:kaie@kuix.de Kai Engert]<br />
|peers=[mailto:mh@glandium.org Mike Hommey]<br />
|ownersemeritus=[mailto:wtc@google.com Wan-Teh Chang]<br />
|group=dev-tech-nspr<br />
|source_dirs=nsprpub/<br />
|url=http://www.mozilla.org/projects/nspr/<br />
http://www.mozilla.org/projects/nspr/reference/html/<br />
http://www.mozilla.org/projects/nspr/release-notes/<br />
|components=NSPR<br />
}}<br />
<br />
{{Module<br />
|name=PDF<br />
|description=Rendering code to display documents encoded in the ISO 32000-1 `PDF' format.<br />
|owner=[mailto:bdahl@mozilla.com Brendan Dahl]<br />
|peers=[mailto:cdenizet@mozilla.com Calixte Denizet]<br />
|peersemeritus=[mailto:aadib@mozilla.com Artur Adib], [mailto:vnicolas@mozilla.com Vivien Nicolas]<br />
|group=dev-platform<br />
|source_dirs=toolkit/components/pdfjs<br />
|url=https://github.com/mozilla/pdf.js<br />
|components=Core::PDF<br />
}}<br />
<br />
{{Module<br />
|name=Plugins<br />
|description= NPAPI Plugin support.<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:davidp99@gmail.com David Parks]<br />
|peersemeritus=[mailto:joshmoz@gmail.com Josh Aas], [mailto:john@pointysoftware.net John Schoenick], [mailto:robert@ocallahan.org Robert O'Callahan], [mailto:jstenback@gmail.com Johnny Stenback], Benjamin Smedberg<br />
|group=<br />
|source_dirs=dom/plugins/, modules/plugin/<br />
|url=https://wiki.mozilla.org/Plugins<br />
|components=Core::Plug-ins<br />
}}<br />
<br />
{{Module<br />
|name=Preferences<br />
|description=Preference library<br />
|owner=[mailto:kwright@mozilla.com Kris Wright]<br />
|peers=[mailto:glandium@mozilla.com Mike Hommey], [mailto:kwright@mozilla.com Kris Wright]<br />
|ownersemeritus=Nicholas Nethercote<br />
|peersemeritus=Felipe Gomes, Eric Rahm<br />
|group=dev-platform<br />
|source_dirs=modules/libpref/<br />
|url=<br />
|components=Core::Preferences: Backend<br />
}}<br />
<br />
{{Module<br />
|name=Private Browsing<br />
|description=Implementation of the Private Browsing mode, and the integration of other modules with Private Browsing APIs.<br />
|owner=[mailto:tihuang@mozilla.com Tim Huang]<br />
|peers=<br />
|ownersemeritus=[mailto:eakhgari@mozilla.com Ehsan Akhgari], [mailto:jhofmann@mozilla.com Johann Hofmann]<br />
|peersemeritus=[mailto:josh@joshmatthews.net Josh Matthews]<br />
|group=dev-platform<br />
|source_dirs=Implementation and consumers of Private Browsing APIs in nsILoadContext, nsIPrivateBrowsingChannel, PrivateBrowsingUtils.jsm and the related glue code. <br />
|url=https://wiki.mozilla.org/Private_Browsing<br />
|components=Firefox::Private Browsing<br />
}}<br />
<br />
{{Module<br />
|name=Privilege Manager<br />
|description="caps"<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]<br />
|peersemeritus=[mailto:brendan@mozilla.org Brendan Eich], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:dveditz@mozilla.com Dan Veditz]<br />
|group=dev-tech-dom<br />
|source_dirs=caps/<br />
|url=http://www.mozilla.org/projects/security/components/index.html<br />
|components=Core::Security: CAPS<br />
}}<br />
<br />
{{Module<br />
|name=Push Notifications<br />
|description=Push is a way for application developers to send messages to their web applications.<br />
|owners=[mailto:lina@mozilla.com Lina Cambridge]<br />
|ownersemeritus=[mailto:doug.turner@gmail.com Doug Turner]<br />
|peers=[mailto:mt@lowentropy.net Martin Thomson], [mailto:ddamjanovic@mozilla.com Dragana Damjanovic]<br />
|peersemeritus=[mailto:nsm.nikhil@gmail.com Nikhil Marathe]<br />
|group=<br />
|source_dirs=dom/push<br />
|url=<br />
|components=Core::DOM: Push Notifications<br />
}}<br />
<br />
{{Module<br />
|name=security<br />
|description=Crypto/PKI code, including NSS (Network Security Services) and JSS (NSS for Java)<br />
|owner=[mailto:beurdouche@mozilla.com Benjamin Beurdouche], [mailto:rrelyea@redhat.com Bob Relyea], [mailto:mt@lowentropy.net Martin Thomson]<br />
|ownersemeritus=[mailto:wtc@google.com Wan-Teh Chang], [mailto:ttaubert@mozilla.com Tim Taubert], [mailto:jcj@mozilla.com J.C. Jones]<br />
|peers=[mailto:nkulatova@mozilla.com Natalia Kulatova], [mailto:djackson@mozilla.com Dennis Jackson], [mailto:jschanck@mozilla.com John Schanck], [mailto:kaie@kuix.de Kai Engert], [mailto:ryan.sleevi@gmail.com Ryan Sleevi], [mailto:ekr@rtfm.com Eric Rescorla], [mailto:dueno@redhat.com Daiki Ueno]<br />
|peersemeritus=[mailto:emaldona@redhat.com Elio Maldonado],[mailto:franziskuskiefer@gmail.com Franziskus Kiefer], [mailto:kjacobs@mozilla.com Kevin Jacobs]<br />
|group=dev-tech-crypto<br />
|source_dirs=dbm/, security/coreconf/, security/dbm/, security/jss/, security/nss/, security/tinderbox/, security/tinderlight/<br />
|url=http://mozilla.org/projects/security/pki/<br />
|components=NSS, JSS, Core::Security, Core::Security: S/MIME<br />
}}<br />
<br />
{{Module<br />
|name=Security - Mozilla PSM Glue<br />
|description=Personal Security Manager<br />
|owner=[mailto:dkeeler@mozilla.com Dana Keeler]<br />
|ownersemeritus=[mailto:kaie@kuix.de Kai Engert (2001-2012)]<br />
|peers=[mailto:jschanck@mozilla.com John Schanck]<br />
|peersemeritus=[mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:cykesiopka.bmo@gmail.com Cykesiopka], [mailto:jc@mozilla.com J.C. Jones], [mailto:fkiefer@mozilla.com Franziskus Kiefer]<br />
|group=dev-tech-crypto<br />
|source_dirs=security/manager/<br />
|url=<br />
|components=Core::Security: PSM<br />
}}<br />
<br />
{{Module<br />
|name=Security - RLBox<br />
|description=Sandboxing using WASM/RLBox libraries<br />
|owner=[mailto:shravanrn@gmail.com Shravan Narayan]<br />
|peers=[mailto:deian@cs.ucsd.edu Deian Stefan], [mailto:mh+mozilla@glandium.org Mike Hommey], [mailto:tom@mozilla.com Tom Ritter]<br />
|group=dev-platform<br />
|source_dirs=security/rlbox, third_party/rlbox, third_party/rlbox_wasm2c_sandbox<br />
|url=<br />
|components=Core::Security: RLBox<br />
}}<br />
<br />
{{Module<br />
|name=Static analysis & rewriting for C++<br />
|description=Tools for checking C++ code looking for problems at compile time, plus tools for automated rewriting of C++ code.<br />
|owner=[mailto:andi@mozilla.com Andi-Bogdan Postelnicu]<br />
|peers=[mailto:nika@thelayzells.com Nika Layzell], [mailto:sfink@mozilla.com Steve Fink], [mailto:jrmuizel@mozilla.com Jeff Muizelaar]<br />
|peersemeritus=[mailto:birunthan@mohanathas.com Birunthan Mohanathas], [mailto:eakhgari@mozilla.com Ehsan Akhgari]<br />
|group=dev-platform<br />
|source_dirs=build/clang-plugin, tools/rewriting among other out of tree tools<br />
|url=<br />
|components=Core::Rewriting & Analysis<br />
}}<br />
{{Module<br />
|name=storage<br />
|description=Storage APIs with a SQLite backend<br />
|owner=[mailto:mak77@bonardo.net Marco Bonardo]<br />
|peers=[mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:jvarga@mozilla.com Jan Varga]<br />
|group=dev-platform<br />
|source_dirs=db/sqlite3/, storage/<br />
|url=http://developer.mozilla.org/en/docs/Storage<br />
|components=Toolkit::Storage, Core::SQL<br />
}}<br />
<br />
{{Module<br />
|name=String<br />
|description=<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[mailto:erahm@mozilla.com Eric Rahm]<br />
|group=dev-tech-xpcom<br />
|source_dirs=string/, xpcom/string/<br />
|url=https://developer.mozilla.org/En/Mozilla_internal_string_guide<br />
|components=Core::String<br />
}}<br />
<br />
{{Module<br />
|name=Style System<br />
|description=CSS style sheet handling; style data computation<br />
|owner=[mailto:emilio@crisal.io Emilio Cobos Álvarez]<br />
|ownersemeritus=[mailto:dbaron@dbaron.org David Baron], [mailto:cam@mcc.id.au Cameron McCormack]<br />
|peers=[mailto:bobbyholley@gmail.com Bobby Holley], [mailto:xidorn+moz@upsuper.org Xidorn Quan]<br />
|peersemeritus=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|group=dev-platform<br />
|source_dirs=layout/style/, servo/<br />
|url=https://wiki.mozilla.org/Gecko:Overview#Style_System<br />
|components=Core::CSS Parsing and Computation<br />
}}<br />
<br />
{{Module<br />
|name=SVG<br />
|description=Scalable Vector Graphics<br />
|owner=[mailto:jwatt@jwatt.org Jonathan Watt]<br />
|peers=[mailto:longsonr@gmail.com Robert Longson], [mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:birtles@gmail.com Brian Birtles]<br />
|group=dev-tech-svg<br />
|source_dirs=dom/svg/, layout/svg/, dom/smil/<br />
|url=https://developer.mozilla.org/en-US/docs/Web/SVG<br />
|components=Core::SVG<br />
}}<br />
<br />
{{Module<br />
|name=UA String<br />
|description=User Agent String<br />
|owner=[mailto:tantek@mozilla.com Tantek Çelik]<br />
|peers=[mailto:kdubost@mozilla.com Karl Dubost], [mailto:cpeterson@mozilla.com Chris Peterson], [mailto:hsivonen@mozilla.com Henri Sivonen] <br />
|group=dev-platform<br />
|source_dirs=netwerk/protocol/http/<br />
|url=https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox<br />
|components=Core::Networking: HTTP<br />
}}<br />
<br />
<br />
{{Module<br />
|name=View System<br />
|description=The View Manager is responsible for handling "heavyweight" rendering (some clipping, compositing) and event handling tasks.<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron]<br />
|group=dev-platform<br />
|source_dirs=view/<br />
|url=<br />
|components=Core::Layout: View Rendering<br />
}}<br />
<br />
{{Module<br />
|name=Web Audio<br />
|description=Support for the W3C Web Audio API specification.<br />
|owner=[mailto:padenot@mozilla.com Paul Adenot]<br />
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:karlt+@karlt.net Karl Tomlinson]<br />
|group=dev-platform<br />
|source_dirs=dom/media/webaudio<br />
|url=https://wiki.mozilla.org/Web_Audio_API<br />
|components=Core::Web Audio<br />
}}<br />
<br />
{{Module<br />
|name=Web Painting<br />
|description=painting, display lists, and layer construction<br />
|owner=[mailto:matt.woodrow@gmail.com Matt Woodrow]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dbaron@dbaron.org David Baron], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:mstange@themasta.com Markus Stange], [mailto:mmynttinen@mozilla.com Miko Mynttinen], [mailto:jnicol@mozilla.com Jamie Nicol]<br />
|group=dev-platform<br />
|source_dirs= layout/painting, the display list and layer related methods on nsIFrame and its subclasses<br />
|url=http://mozilla.org/newlayout/doc/ ,<br />
http://lxr.mozilla.org/mozilla/source/layout/doc/<br />
|components=Core::Layout: Web Painting<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC<br />
|description=WebRTC is responsible for realtime audio and video communication, as well as related issues like low-level camera and microphone access<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:bcampen@mozilla.com Byron Campen] [mailto:abr@mozilla.com Adam Roach]<br />
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=netwerk/sctp (also see submodules "WebRTC Media" and "WebRTC Signaling")<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC, Core::WebRTC Networking<br />
}}<br />
<br />
{{Module<br />
|name=WebVR<br />
|description=Gecko's implementation of WebVR (Virtual Reality) functionality, including API, devices, graphics and integration<br />
|owner=[mailto:kgilbert@mozilla.com Kearwood (Kip) Gilbert]<br />
|peers=[mailto:dmu@mozilla.com Daosheng Mu], [mailto:igorostizaga@mozilla.com Imanol Fernández]<br />
|peersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|group=dev-platform<br />
|source_dirs=dom/vr, gfx/vr<br />
|url=https://mozvr.com/<br />
|components=Core::WebVR<br />
}}<br />
<br />
{{Module<br />
|name=Widget<br />
|description=Top level Widget<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|ownersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peersemeritus=[mailto:pavlov@pavlov.net Stuart Parmenter], <br />
|group=dev-platform<br />
|source_dirs=widget/, widget/xpwidgets/<br />
|url=<br />
|components=Core::Drag and Drop, Core::Widget, Core::Printing: Setup<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Android<br />
|description=This is part of the [https://wiki.mozilla.org/Modules/Core#GeckoView GeckoView] module.<br />
|owner=[mailto:asferro@mozilla.com Agi Sferro]<br />
}}<br />
<br />
{{Module<br />
|name=Widget - GTK<br />
|description=GTK widget support<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|peers=[mailto:stransky@redhat.com Martin Stránský]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|group=dev-platform<br />
|source_dirs=widget/gtk/, widget/gtk2/, widget/gtksuperwin/, widget/gtkxtbin/<br />
|url=http://www.mozilla.org/unix/, http://www.gtk.org, http://www.mozilla.org/ports/gtk/<br />
|components=Core::Widget: Gtk<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Headless<br />
|description=Headless widget support<br />
|owner=[mailto:bdahl@mozilla.com Brendan Dahl]<br />
|peers=<br />
|ownersemeritus=<br />
|group=dev-platform<br />
|source_dirs=widget/headless/<br />
|url=<br />
|components=Firefox::Headless<br />
}}<br />
<br />
{{Module<br />
|name=Widget - macOS<br />
|description= macOS widget support<br />
|owner=[mailto:spohl@mozilla.com Stephen A Pohl]<br />
|peers=[mailto:mstange@themasta.com Markus Stange], [mailto:haftandilian@mozilla.com Haik Aftandilian]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:mstange@themasta.com Markus Stange]<br />
|peersemeritus=[mailto:joshmoz@gmail.com Josh Aas], [mailto:b56girard@gmail.com Benoit Girard], [mailto:smichaud@pobox.com Steven Michaud]<br />
|group=dev-platform<br />
|source_dirs=widget/cocoa/<br />
|url=<br />
|components=Core::Widget: Cocoa<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Windows<br />
|description=Windows widget support<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:cmartin@mozilla.com Chris Martin], [mailto:tkikuchi@mozilla.com Toshihito Kikuchi], [mailto:mhowell@mozilla.com Molly Howell], [mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|peersemeritus=[mailto:robert.strong.bugs@gmail.com Rob Strong], [mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:blassey@mozilla.com Brad Lassey], [mailto:netzen@gmail.com Brian Bondy], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:doug.turner@gmail.com Doug Turner], [mailto:timeless@mozdev.org Josh 'timeless' Soref], [mailto:robarnold@cmu.edu Rob Arnold], Aaron Klotz<br />
|group=dev-platform<br />
|source_dirs=widget/windows/<br />
|url=<br />
|components=Core::Widget: Win32<br />
}}<br />
<br />
{{Module<br />
|name=XML<br />
|description=XML in Mozilla, including XML, XHTML, Namespaces in XML, Associating Style Sheets with XML Documents, XML Linking and XML Extras. XML-related things that are not covered by more specific projects.<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:erahm@mozilla.com Eric Rahm]<br />
|group=dev-tech-xml<br />
|source_dirs=dom/xml/, extensions/xmlextras/, parser/expat/<br />
|url=http://www.mozilla.org/newlayout/xml/<br />
|components=Core::XML<br />
}}<br />
<br />
{{Module<br />
|name=XPApps<br />
|description=Cross-Platform Applications, mostly Navigator front end and application shell.<br />
|owner=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|peers=[mailto:dean_tessman@hotmail.com Dean Tessman], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-apps-seamonkey<br />
|source_dirs=xpfe/<br />
|url=http://www.mozilla.org/xpapps/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPCOM<br />
|description=The cross-platform object model and core data structures.<br />
|owner=[mailto:nika@thelayzells.com Nika Layzell]<br />
|peers=[mailto:kmaglione@mozilla.com Kris Maglione], [mailto:sgiesecke@mozilla.com Simon Giesecke], [mailto:amccreight@mozilla.com Andrew McCreight]<br />
|ownersemeritus=Benjamin Smedberg<br />
|peersemeritus=[https://mozillians.org/en-US/u/dougt/ Doug Turner], [mailto:erahm@mozilla.com Eric Rahm], <br />
|group=dev-platform<br />
|source_dirs=startupcache/, xpcom/%, xpcom/base/, xpcom/build/, xpcom/components/, xpcom/ds/, xpcom/glue/, xpcom/proxy/, xpcom/sample/, xpcom/stub/, xpcom/tests/, xpcom/threads/, xpcom/tools/, xpcom/windbgdlg/<br />
|url=http://developer.mozilla.org/en/XPCOM<br />
|components=Core::XPCOM<br />
}}<br />
<br />
{{Module<br />
|name=XPConnect<br />
|description=Deep Magic<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:kmaglione@mozilla.com Kris Maglione], [mailto:nika@thelayzells.com Nika Layzell]<br />
|peersemeritus=[mailto:gal@uci.edu Andreas Gal], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:gkrizsanits@mozilla.com Gabor Krizsanits]<br />
|group=<br />
|source_dirs=js/xpconnect/<br />
|url=<br />
|components=Core::XPConnect<br />
}}<br />
<br />
{{Module<br />
|name=XPIDL<br />
|description=Cross-platform IDL compiler; produces .h C++ header files and .xpt runtime type description files from .idl interface description files.<br />
|owner=[mailto:nika@thelayzells.com Nika Layzell]<br />
|peers=[mailto:amccreight@mozilla.com Andrew McCreight]<br />
|ownersemeritus=[mailto:me@kylehuey.com Kyle Huey]<br />
|peersemeritus=[mailto:shaver@mozilla.org Mike Shaver], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-tech-xpcom<br />
|source_dirs=xpcom/typelib/<br />
|url=http://www.mozilla.org/scriptable/xpidl<br />
http://www.mozilla.org/scriptable<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XSLT Processor<br />
|description=XSLT transformations processor<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:axel@pike.org Axel Hecht], [mailto:erahm@mozilla.com Eric Rahm]<br />
|group=dev-tech-xslt<br />
|source_dirs=dom/xslt/<br />
|url=http://www.mozilla.org/projects/xslt/, http://www.w3.org/TR/xslt.html<br />
|components=Core::XSLT<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Windows <br />
|description=Sandboxing for the Windows platform <br />
|owner=[mailto:bobowencode@gmail.com Bob Owen] (:bobowen)<br />
|peers=[mailto:davidp99@gmail.com David Parks] (:handyman), [mailto:jimm@mozilla.com Jim Mathies] (:jimm), [mailto:tkikuchi@mozilla.com Toshihito Kikuchi] (:toshi)<br />
|ownersemeritus=[https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes]<br />
|peersemeritus=[mailto:netzen@gmail.com Brian Bondy], Aaron Klotz<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/win <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - OSX <br />
|description=Sandboxing for the OSX platform <br />
|owner=[mailto:haftandilian@mozilla.com Haik Aftandilian]<br />
|peers=<br />
|group=dev-platform <br />
|source_dirs=security/sandbox/mac <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Linux<br />
|description=Sandboxing for the Linux platform<br />
|owner=[mailto:jld@mozilla.com Jed Davis]<br />
|peers=[mailto:gcp@mozilla.com Gian-Carlo Pascutto]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/linux<br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Crash reporting<br />
|description=Infrastructure and tools used to generate, submit and process crash reports. This includes the in-tree google-breakpad fork, the crash report generation machinery as well as the host tools used to dump symbols, analyse minidumps and generate stack traces.<br />
|owner=[mailto:gsvelto@mozilla.com Gabriele Svelto]<br />
|peers=[mailto:kwright@mozilla.com Kris Wright], [mailto:cdenizet@mozilla.com Calixte Denizet], [mailto:a.beingessner@gmail.com Alexis Beingessner]<br />
|group=dev-platform<br />
|source_dirs=toolkit/crashreporter, toolkit/components/crashes, tools/crashreporter, ipc/glue/CrashReporter*, mobile/android/geckoview/src/main/java/org/mozilla/geckoview/CrashReporter.java<br />
|url=https://firefox-source-docs.mozilla.org/toolkit/crashreporter/crashreporter/index.html<br />
|components=Toolkit::Crash Reporting<br />
}}<br />
<br />
===Submodules===<br />
{{Module<br />
|name=Build Config - Fennec<br />
|description=Submodule of the build config covering Fennec's build system in mobile/android.<br />
|owner=[mailto:nalexander@mozilla.com Nicholas Alexander]<br />
|peers=Same as Build Config<br />
|group=dev-builds<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=Build Config - Taskgraph<br />
|description=Support for task-graph generation in decision, action, and cron tasks, including configuration of all tasks including those for CI, nightlies, and releases; as well as Docker and VM images used to execute those tasks.<br />
|owner=[mailto:mozilla@hocat.ca Tom Prince]<br />
|peers=[mailto:ahal@mozilla.com Andrew Halberstadt], [mailto:aki@mozilla.com Aki Sasaki], [mailto:bstack@mozilla.com Brian Stack], [mailto:mh@glandium.org Mike Hommey], [mailto:gps@mozilla.com Gregory Szorc], [mailto:jmaher@mozilla.com Joel Maher], [mailto:callek@mozilla.com Justin Wood], [mailto:dustin@mozilla.com Dustin Mitchell]<br />
|components=Firefox Build System::Task Configuration<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC Media<br />
|description=Submodule of WebRTC responsible for access to media input devices (microphones, cameras, screen capture), as well as realtime audiovisual codecs and packetization.<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:jib@mozilla.com Jan-Ivar Bruaroey], [mailto:dminor@mozilla.com Dan Minor], [mailto:apehrson@mozilla.com Andreas Pehrson], <br />
|peersemeritus=[mailto:pkerr@mozilla.com Paul Kerr], [mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=/media/webrtc, /dom/media/webrtc, /dom/media/systemservices<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC (Audio/Video)<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC Signaling<br />
|description=Submodule of WebRTC responsible for implementation of PeerConnection API, WebRTC identity, and SDP/JSEP handling<br />
|owner=[mailto:bcampen@mozilla.com Byron Campen]<br />
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:abr@mozilla.com Adam Roach], [mailto:rjesup@mozilla.com Randell Jesup], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]<br />
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=/media/webrtc/signaling/<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC (Signaling)<br />
}}<br />
<br />
<noinclude><br />
<br />
===Unassigned Bugzilla Components===<br />
<br />
The following Bugzilla components in the Core project have not been assigned to a module (this list is not exhaustive):<br />
<br />
<pre><br />
Core::Find Backend<br />
Core::General<br />
Core::History: Global<br />
Core::Image Blocking<br />
Core::Localization<br />
Core::Networking: Domain Lists<br />
Core::Selection<br />
Core::Serializers<br />
Core::Spelling checker<br />
Core::X-remote<br />
Core::XUL<br />
</pre><br />
</noinclude></div>Dkeelerhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/Certificate_Verification&diff=1220252SecurityEngineering/Certificate Verification2019-11-13T22:03:50Z<p>Dkeeler: specify where Firefox gets the EV policy OID to validate for</p>
<hr />
<div>== Background ==<br />
<br />
[https://www.guru99.com/gecko-marionette-driver-selenium.html Gecko] (and therefore Firefox) relies on [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS] to implement various cryptographic functions. NSS consists of a collection of [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_API_Guidelines loosely-coupled libraries]. libssl, for example, is the TLS implementation. NSS is a Mozilla project, but its development differs significantly from the rest of the tree. In fact, it has its own tree that is periodically imported wholesale into [https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/mozilla-central mozilla-central]. The component that uses the NSS libraries in Firefox is a layer called [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/PSM PSM] ("Personal Security Manager" or "Privacy and Security Module").<br />
<br />
To enable secure TLS connections to the best of our ability, PSM implements a certificate verification callback. It performs a number of checks, but ultimately it must determine if it trusts a certificate presented by a peer. The approach PSM takes is to repeatedly build a potential path to a [https://en.wikipedia.org/wiki/Trust_anchor trust anchor], validate the potential path, and either return that path if it validates correctly or find another potential path. [https://blog.mozilla.org/security/2014/04/24/exciting-updates-to-certificate-verification-in-gecko/ mozilla::pkix] is a C++ library that provides a framework to implement this approach.<br />
<br />
== mozilla::pkix ==<br />
<br />
mozilla::pkix was originally implemented as part of mozilla-central (i.e. gecko) but has since been moved into NSS. However, it is not part of NSS' stable C API. As a library, mozilla::pkix uses the notion of a "trust domain" provided by the application to build a trusted chain from an end-entity certificate to a root. The trust domain is responsible for saying what trust level a certificate has, finding potential issuers of a certificate, and checking the revocation for a certificate. A certificate can be a trust anchor, it can inherit its trust, or it can be [[CA/Maintenance_and_Enforcement#Actively_Distrusting_a_Certificate|actively distrusted]]. Given an end-entity certificate and a trust domain, the library will perform issuer-independent checks on that certificate (e.g. expiration, appropriate key usages), get a list of potential issuers, and perform a [https://en.wikipedia.org/wiki/Depth-first_search depth-first traversal]. If it encounters a distrusted certificate, it abandons searching that path. If it finds a trust anchor, it queries the trust domain again to see if that path is acceptable (this is where gecko implements checks that are specific to the platform and not the abstract problem of building a trusted certificate chain). If so, the end-entity certificate has successfully been verified.<br />
<br />
Because mozilla::pkix uses a depth-first strategy rather than a [https://en.wikipedia.org/wiki/Breadth-first_search breadth-first] one, it is not guaranteed to find the shortest path from an end-entity certificate to a trust anchor. However, as a heuristic, the trust domain implemented by the platform prefers trust anchors at each step. That is, when mozilla::pkix asks for an issuer certificate, the trust domain will first try any available trust anchors before trying non-trust anchors.<br />
<br />
For example, suppose an end-entity certificate E were signed by intermediate I that was signed by root R. Further suppose that R were cross-signed by another root T, producing intermediate certificate R'. Two valid paths are E -> I -> R and E -> I -> R' -> T. At the step where mozilla::pkix is trying to find an issuer for I, the trust domain finds both R and R' as potential issuers. However, only R is a trust anchor - R' is not. So, the trust domain has mozilla::pkix try that one first. It successfully verifies, so the library returns the result E -> I -> R. If at some later point R were distrusted, that chain would not verify successfully. mozilla::pkix would then ask the trust domain for another potential issuer of I, and the trust domain would provide R'. R' is not a trust anchor either, so mozilla::pkix asks for potential issuers of that certificate. The trust domain provides T, and mozilla::pkix verifies the chain, resulting in E -> I -> R' -> T.<br />
<br />
Extended Validation changes the situation somewhat in that when mozilla::pkix is verifying an EV certificate, it must do so for a particular policy OID, and only certain roots are trusted for particular policy OIDs. This policy OID will be the first policy OID that is recognized by Firefox as a supported EV policy OID from the end-entity's certificatePolicies extension. Other than that, path building proceeds as before. So, using the example from before, suppose R were a trust anchor but not for a particular EV OID. Further suppose that T is also a trust anchor but is trusted for a particular EV OID. When evaluating the potential chain E -> I -> R, the trust domain determines that R is not a trust anchor for the policy being verified for, so mozilla::pkix keeps searching. It finds potential chain E -> I -> R' -> T, where T is trusted for that EV OID, and thus it verifies and returns that chain.<br />
<br />
Unlike the other NSS libraries, mozilla::pkix is written in C++ and can take advantage of more modern language features.<br />
<br />
=== Trust Anchors ===<br />
<br />
The platform looks for trust anchors in a few locations. First, Mozilla ships a list of trust anchors with the platform corresponding to the [[CA/Included_Certificates|root Certificate Authorities (CAs) in the Mozilla Root CA Program]]. Additionally, the user may [[PSM:Changing_Trust_Settings|import their own trust anchors]]. These are stored in the profile's [[NSS_Shared_DB|cert9.db file]]. The user may also import third-party PKCS#11 modules that provide trust anchors. The [https://support.mozilla.org/en-US/kb/setting-certificate-authorities-firefox enterprise roots feature], if enabled, may collect trust anchors provided by the operating system.<br />
<br />
=== Intermediate Certificates ===<br />
<br />
Similarly, the platform gathers [[CA/Intermediate_Certificates|intermediate certificates]] from a few locations. The TLS specification mandates that the peer include in the handshake any necessary intermediate certificates to verify the [https://en.wikipedia.org/wiki/Public_key_certificate#End-entity_or_leaf_certificate end-entity]. In practice this may not be the case, but the platform uses these if they are available. The user may manually add intermediate certificates. Again these are stored in the profile's cert9.db file. The enterprise roots feature also looks for intermediates provided by the operating system.<br />
<br />
When the platform successfully verifies an end-entity certificate, it caches the intermediates from that verified chain in the profile (cert9.db) in case they will be useful in the future (for example, when connecting to a different peer that uses a certificate issued by the same CA but neglects to include intermediate certificates in the handshake).<br />
<br />
Note that Firefox does not do AIA chasing. That is, it does not use information embedded in certificates to remotely fetch potential issuer certificates. So, if a server does not include the appropriate intermediate certificates in the TLS handshake, Firefox may not be able to verify its certificate.<br />
<br />
=== Extended Validation ===<br />
<br />
As part of [[CA|Mozilla's Root CA Program]], there is a list of root certificates that are trusted to issue [[CA/EV_Processing_for_CAs|Extended Validation (EV) certificates]]. This list is available in code form at https://hg.mozilla.org/mozilla-central/annotate/tip/security/certverifier/ExtendedValidation.cpp.<br />
<br />
== Other Verification Routines in NSS ==<br />
<br />
NSS exposes other certificate verification functions that are not yet implemented using mozilla::pkix. The following is informational and has little bearing on the behavior of Firefox.<br />
<br />
=== "classic" verification ===<br />
<br />
The so-called "classic" certificate verification algorithm performs issuer-independent checks on the given certificate, finds a potential issuer, verifies that the signature matches, and recurses. If multiple issuers are found, it attempts to use the "best" one. However, this is a heuristic, and as it does not perform backtracking, it can fail to verify a valid certificate. This is spectacularly apparent in the case of key-pinning if the algorithm chooses to not traverse a certificate path that contains a necessary key.<br />
<br />
The code is here: https://hg.mozilla.org/projects/nss/file/tip/lib/certhigh<br />
<br />
=== libpkix ===<br />
libpkix was auto-translated from Java to C. It attempts to implement Java's exception semantics in C. It makes liberal use of unclear macros (e.g. https://hg.mozilla.org/projects/nss/annotate/5d9f8b809e6f7020529ba1345b64e36f61994c8d/lib/libpkix/pkix/util/pkix_tools.h#l67 ). A source-line-counting tool clocks it in at 45,000 lines of code (the code is here: https://hg.mozilla.org/projects/nss/file/tip/lib/libpkix ). There are known bugs in the implementation.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=CA/EV_Processing_for_CAs&diff=1220251CA/EV Processing for CAs2019-11-13T21:58:59Z<p>Dkeeler: make the relationship between certificate path building and policy checking more clear</p>
<hr />
<div>= Firefox EV Processing Logic =<br />
<br />
Firefox determines whether or not to display the Extended Validation SSL UI for a given website by performing policy validation during certificate path building and verification. Firefox ships with a list of trust anchors (root certificates), some of which are each trusted for a specific EV policy OID. If Firefox can build a trusted path from the end entity certificate to a root certificate that is trusted for a particular OID and where each certificate in the chain has that policy OID in the certificatePolicies extension (or, for intermediate and root certificates, the anyPolicy OID), then that certificate is considered an EV certificate. Additional details are as follows.<br />
<br />
=== First OID ===<br />
Firefox is sensitive to the position of OIDs in the certificatePolicies extension of the end-entity certificate. Firefox “recognizes” a set EV policy OIDs associated with some roots from some CAs in the Mozilla Root CA Program, plus the CAB Forum EV OID (2.23.140.1.1). Firefox only attempts to build a trusted path using the first recognized EV policy OID found in the certificatePolicies extension of the end-entity certificate. Later OIDs, even if recognized by Firefox, are ignored. Thus, if path building does not succeed using that first EV OID, the certificate will not be considered EV.<br />
<br />
=== CA-Specific OIDs ===<br />
Firefox matches the EV OID found in the end-entity certificate with one or more EV OIDs associated with the root in the ExtendedValidation.cpp file. In the process of running the [[SecurityEngineering/Certificate_Verification|path building algorithm]], when a potential root certificate has been identified, the first recognized EV policy OID found in the end-entity certificate is compared to the EV policy OID(s) associated with the root. If they match, the candidate is a valid trust anchor, and the end-entity will be considered EV if all other checks pass. In addition, if the CAB Forum EV policy OID is the first recognized OID in the certificatePolicies extension of the end-entity certificate, EV status is granted if the root is EV-enabled for any OID.<br />
<br />
=== Policy Constraints ===<br />
Any Intermediate certificates in the chain must assert a policy that includes the first recognized EV policy OID found in the end-entity certificate. This means that one of the following must be true for each intermediate CA certificate in the chain:<br />
* The certificatePolicies extensions includes the anyPolicy OID (2.5.29.32.0) (Note that if the inhibitAnyPolicy extension is present, Firefox will reject the anyPolicy OID regardless of the value set for inhibitAnyPolicy)<br />
* The certificatePolicies extension includes the same “recognized” policy OID as Firefox chose from the end-entity certificate (either a CA-specific OID or the CAB Forum OID)<br />
<br />
=== Cross-Certification ===<br />
EV certificates that chain to multiple roots via cross-certification follow the rules listed above. Special care should be taken in using CA-specific EV identifiers in this situation because it is possible for there to be a mismatch between the policy Firefox chooses from the end-entity certificate and the policy associated with the root chosen by the [[SecurityEngineering/Certificate_Verification|path building algorithm]]. Best practice is to rely on the CAB Forum EV policy OID by placing it in the first position of all end-entity EV certificates.<br />
<br />
=== Revocation Checking ===<br />
An additional consideration for receiving the EV UI is that revocation checking must succeed via OCSP (or some future revocation checking mechanism) for the end-entity and intermediate CA certificate(s). If the security.OCSP.enabled preference is set to ‘0’, OCSP checking is not performed and the EV UI will not appear for otherwise valid EV certificates.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/Certificate_Verification&diff=1219970SecurityEngineering/Certificate Verification2019-11-07T23:28:36Z<p>Dkeeler: /* mozilla::pkix */ move AIA chasing note to the right section</p>
<hr />
<div>== Background ==<br />
<br />
[https://www.guru99.com/gecko-marionette-driver-selenium.html Gecko] (and therefore Firefox) relies on [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS] to implement various cryptographic functions. NSS consists of a collection of [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_API_Guidelines loosely-coupled libraries]. libssl, for example, is the TLS implementation. NSS is a Mozilla project, but its development differs significantly from the rest of the tree. In fact, it has its own tree that is periodically imported wholesale into [https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/mozilla-central mozilla-central]. The component that uses the NSS libraries in Firefox is a layer called [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/PSM PSM] ("Personal Security Manager" or "Privacy and Security Module").<br />
<br />
To enable secure TLS connections to the best of our ability, PSM implements a certificate verification callback. It performs a number of checks, but ultimately it must determine if it trusts a certificate presented by a peer. The approach PSM takes is to repeatedly build a potential path to a [https://en.wikipedia.org/wiki/Trust_anchor trust anchor], validate the potential path, and either return that path if it validates correctly or find another potential path. [https://blog.mozilla.org/security/2014/04/24/exciting-updates-to-certificate-verification-in-gecko/ mozilla::pkix] is a C++ library that provides a framework to implement this approach.<br />
<br />
== mozilla::pkix ==<br />
<br />
mozilla::pkix was originally implemented as part of mozilla-central (i.e. gecko) but has since been moved into NSS. However, it is not part of NSS' stable C API. As a library, mozilla::pkix uses the notion of a "trust domain" provided by the application to build a trusted chain from an end-entity certificate to a root. The trust domain is responsible for saying what trust level a certificate has, finding potential issuers of a certificate, and checking the revocation for a certificate. A certificate can be a trust anchor, it can inherit its trust, or it can be [[CA/Maintenance_and_Enforcement#Actively_Distrusting_a_Certificate|actively distrusted]]. Given an end-entity certificate and a trust domain, the library will perform issuer-independent checks on that certificate (e.g. expiration, appropriate key usages), get a list of potential issuers, and perform a [https://en.wikipedia.org/wiki/Depth-first_search depth-first traversal]. If it encounters a distrusted certificate, it abandons searching that path. If it finds a trust anchor, it queries the trust domain again to see if that path is acceptable (this is where gecko implements checks that are specific to the platform and not the abstract problem of building a trusted certificate chain). If so, the end-entity certificate has successfully been verified.<br />
<br />
Because mozilla::pkix uses a depth-first strategy rather than a [https://en.wikipedia.org/wiki/Breadth-first_search breadth-first] one, it is not guaranteed to find the shortest path from an end-entity certificate to a trust anchor. However, as a heuristic, the trust domain implemented by the platform prefers trust anchors at each step. That is, when mozilla::pkix asks for an issuer certificate, the trust domain will first try any available trust anchors before trying non-trust anchors.<br />
<br />
For example, suppose an end-entity certificate E were signed by intermediate I that was signed by root R. Further suppose that R were cross-signed by another root T, producing intermediate certificate R'. Two valid paths are E -> I -> R and E -> I -> R' -> T. At the step where mozilla::pkix is trying to find an issuer for I, the trust domain finds both R and R' as potential issuers. However, only R is a trust anchor - R' is not. So, the trust domain has mozilla::pkix try that one first. It successfully verifies, so the library returns the result E -> I -> R. If at some later point R were distrusted, that chain would not verify successfully. mozilla::pkix would then ask the trust domain for another potential issuer of I, and the trust domain would provide R'. R' is not a trust anchor either, so mozilla::pkix asks for potential issuers of that certificate. The trust domain provides T, and mozilla::pkix verifies the chain, resulting in E -> I -> R' -> T.<br />
<br />
Extended Validation changes the situation somewhat in that when mozilla::pkix is verifying an EV certificate, it must do so for a particular policy OID, and only certain roots are trusted for particular policy OIDs. Other than that, path building proceeds as before. So, using the example from before, suppose R were a trust anchor but not for a particular EV OID. Further suppose that T is also a trust anchor but is trusted for a particular EV OID. When evaluating the potential chain E -> I -> R, the trust domain determines that R is not a trust anchor for the policy being verified for, so mozilla::pkix keeps searching. It finds potential chain E -> I -> R' -> T, where T is trusted for that EV OID, and thus it verifies and returns that chain.<br />
<br />
Unlike the other NSS libraries, mozilla::pkix is written in C++ and can take advantage of more modern language features.<br />
<br />
=== Trust Anchors ===<br />
<br />
The platform looks for trust anchors in a few locations. First, Mozilla ships a list of trust anchors with the platform corresponding to the [[CA/Included_Certificates|root Certificate Authorities (CAs) in the Mozilla Root CA Program]]. Additionally, the user may [[PSM:Changing_Trust_Settings|import their own trust anchors]]. These are stored in the profile's [[NSS_Shared_DB|cert9.db file]]. The user may also import third-party PKCS#11 modules that provide trust anchors. The [https://support.mozilla.org/en-US/kb/setting-certificate-authorities-firefox enterprise roots feature], if enabled, may collect trust anchors provided by the operating system.<br />
<br />
=== Intermediate Certificates ===<br />
<br />
Similarly, the platform gathers [[CA/Intermediate_Certificates|intermediate certificates]] from a few locations. The TLS specification mandates that the peer include in the handshake any necessary intermediate certificates to verify the [https://en.wikipedia.org/wiki/Public_key_certificate#End-entity_or_leaf_certificate end-entity]. In practice this may not be the case, but the platform uses these if they are available. The user may manually add intermediate certificates. Again these are stored in the profile's cert9.db file. The enterprise roots feature also looks for intermediates provided by the operating system.<br />
<br />
When the platform successfully verifies an end-entity certificate, it caches the intermediates from that verified chain in the profile (cert9.db) in case they will be useful in the future (for example, when connecting to a different peer that uses a certificate issued by the same CA but neglects to include intermediate certificates in the handshake).<br />
<br />
Note that Firefox does not do AIA chasing. That is, it does not use information embedded in certificates to remotely fetch potential issuer certificates. So, if a server does not include the appropriate intermediate certificates in the TLS handshake, Firefox may not be able to verify its certificate.<br />
<br />
=== Extended Validation ===<br />
<br />
As part of [[CA|Mozilla's Root CA Program]], there is a list of root certificates that are trusted to issue [[CA/EV_Processing_for_CAs|Extended Validation (EV) certificates]]. This list is available in code form at https://hg.mozilla.org/mozilla-central/annotate/tip/security/certverifier/ExtendedValidation.cpp.<br />
<br />
== Other Verification Routines in NSS ==<br />
<br />
NSS exposes other certificate verification functions that are not yet implemented using mozilla::pkix. The following is informational and has little bearing on the behavior of Firefox.<br />
<br />
=== "classic" verification ===<br />
<br />
The so-called "classic" certificate verification algorithm performs issuer-independent checks on the given certificate, finds a potential issuer, verifies that the signature matches, and recurses. If multiple issuers are found, it attempts to use the "best" one. However, this is a heuristic, and as it does not perform backtracking, it can fail to verify a valid certificate. This is spectacularly apparent in the case of key-pinning if the algorithm chooses to not traverse a certificate path that contains a necessary key.<br />
<br />
The code is here: https://hg.mozilla.org/projects/nss/file/tip/lib/certhigh<br />
<br />
=== libpkix ===<br />
libpkix was auto-translated from Java to C. It attempts to implement Java's exception semantics in C. It makes liberal use of unclear macros (e.g. https://hg.mozilla.org/projects/nss/annotate/5d9f8b809e6f7020529ba1345b64e36f61994c8d/lib/libpkix/pkix/util/pkix_tools.h#l67 ). A source-line-counting tool clocks it in at 45,000 lines of code (the code is here: https://hg.mozilla.org/projects/nss/file/tip/lib/libpkix ). There are known bugs in the implementation.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/Certificate_Verification&diff=1219969SecurityEngineering/Certificate Verification2019-11-07T23:27:36Z<p>Dkeeler: /* mozilla::pkix */ more details about path building - examples, EV, note that Firefox doesn't do AIA chasing</p>
<hr />
<div>== Background ==<br />
<br />
[https://www.guru99.com/gecko-marionette-driver-selenium.html Gecko] (and therefore Firefox) relies on [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS] to implement various cryptographic functions. NSS consists of a collection of [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_API_Guidelines loosely-coupled libraries]. libssl, for example, is the TLS implementation. NSS is a Mozilla project, but its development differs significantly from the rest of the tree. In fact, it has its own tree that is periodically imported wholesale into [https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/mozilla-central mozilla-central]. The component that uses the NSS libraries in Firefox is a layer called [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/PSM PSM] ("Personal Security Manager" or "Privacy and Security Module").<br />
<br />
To enable secure TLS connections to the best of our ability, PSM implements a certificate verification callback. It performs a number of checks, but ultimately it must determine if it trusts a certificate presented by a peer. The approach PSM takes is to repeatedly build a potential path to a [https://en.wikipedia.org/wiki/Trust_anchor trust anchor], validate the potential path, and either return that path if it validates correctly or find another potential path. [https://blog.mozilla.org/security/2014/04/24/exciting-updates-to-certificate-verification-in-gecko/ mozilla::pkix] is a C++ library that provides a framework to implement this approach.<br />
<br />
== mozilla::pkix ==<br />
<br />
mozilla::pkix was originally implemented as part of mozilla-central (i.e. gecko) but has since been moved into NSS. However, it is not part of NSS' stable C API. As a library, mozilla::pkix uses the notion of a "trust domain" provided by the application to build a trusted chain from an end-entity certificate to a root. The trust domain is responsible for saying what trust level a certificate has, finding potential issuers of a certificate, and checking the revocation for a certificate. A certificate can be a trust anchor, it can inherit its trust, or it can be [[CA/Maintenance_and_Enforcement#Actively_Distrusting_a_Certificate|actively distrusted]]. Given an end-entity certificate and a trust domain, the library will perform issuer-independent checks on that certificate (e.g. expiration, appropriate key usages), get a list of potential issuers, and perform a [https://en.wikipedia.org/wiki/Depth-first_search depth-first traversal]. If it encounters a distrusted certificate, it abandons searching that path. If it finds a trust anchor, it queries the trust domain again to see if that path is acceptable (this is where gecko implements checks that are specific to the platform and not the abstract problem of building a trusted certificate chain). If so, the end-entity certificate has successfully been verified.<br />
<br />
Because mozilla::pkix uses a depth-first strategy rather than a [https://en.wikipedia.org/wiki/Breadth-first_search breadth-first] one, it is not guaranteed to find the shortest path from an end-entity certificate to a trust anchor. However, as a heuristic, the trust domain implemented by the platform prefers trust anchors at each step. That is, when mozilla::pkix asks for an issuer certificate, the trust domain will first try any available trust anchors before trying non-trust anchors.<br />
<br />
For example, suppose an end-entity certificate E were signed by intermediate I that was signed by root R. Further suppose that R were cross-signed by another root T, producing intermediate certificate R'. Two valid paths are E -> I -> R and E -> I -> R' -> T. At the step where mozilla::pkix is trying to find an issuer for I, the trust domain finds both R and R' as potential issuers. However, only R is a trust anchor - R' is not. So, the trust domain has mozilla::pkix try that one first. It successfully verifies, so the library returns the result E -> I -> R. If at some later point R were distrusted, that chain would not verify successfully. mozilla::pkix would then ask the trust domain for another potential issuer of I, and the trust domain would provide R'. R' is not a trust anchor either, so mozilla::pkix asks for potential issuers of that certificate. The trust domain provides T, and mozilla::pkix verifies the chain, resulting in E -> I -> R' -> T.<br />
<br />
Extended Validation changes the situation somewhat in that when mozilla::pkix is verifying an EV certificate, it must do so for a particular policy OID, and only certain roots are trusted for particular policy OIDs. Other than that, path building proceeds as before. So, using the example from before, suppose R were a trust anchor but not for a particular EV OID. Further suppose that T is also a trust anchor but is trusted for a particular EV OID. When evaluating the potential chain E -> I -> R, the trust domain determines that R is not a trust anchor for the policy being verified for, so mozilla::pkix keeps searching. It finds potential chain E -> I -> R' -> T, where T is trusted for that EV OID, and thus it verifies and returns that chain.<br />
<br />
Note that Firefox does not do AIA chasing. That is, it does not use information embedded in certificates to remotely fetch potential issuer certificates. So, if a server does not include the appropriate intermediate certificates in the TLS handshake, Firefox may not be able to verify its certificate. Firefox does currently cache intermediates from previous successful verifications, however, so if a necessary intermediate is available in the cache, then the verification may succeed.<br />
<br />
Unlike the other NSS libraries, mozilla::pkix is written in C++ and can take advantage of more modern language features.<br />
<br />
=== Trust Anchors ===<br />
<br />
The platform looks for trust anchors in a few locations. First, Mozilla ships a list of trust anchors with the platform corresponding to the [[CA/Included_Certificates|root Certificate Authorities (CAs) in the Mozilla Root CA Program]]. Additionally, the user may [[PSM:Changing_Trust_Settings|import their own trust anchors]]. These are stored in the profile's [[NSS_Shared_DB|cert9.db file]]. The user may also import third-party PKCS#11 modules that provide trust anchors. The [https://support.mozilla.org/en-US/kb/setting-certificate-authorities-firefox enterprise roots feature], if enabled, may collect trust anchors provided by the operating system.<br />
<br />
=== Intermediate Certificates ===<br />
<br />
Similarly, the platform gathers [[CA/Intermediate_Certificates|intermediate certificates]] from a few locations. The TLS specification mandates that the peer include in the handshake any necessary intermediate certificates to verify the [https://en.wikipedia.org/wiki/Public_key_certificate#End-entity_or_leaf_certificate end-entity]. In practice this may not be the case, but the platform uses these if they are available. The user may manually add intermediate certificates. Again these are stored in the profile's cert9.db file. The enterprise roots feature also looks for intermediates provided by the operating system.<br />
<br />
When the platform successfully verifies an end-entity certificate, it caches the intermediates from that verified chain in the profile (cert9.db) in case they will be useful in the future (for example, when connecting to a different peer that uses a certificate issued by the same CA but neglects to include intermediate certificates in the handshake).<br />
<br />
=== Extended Validation ===<br />
<br />
As part of [[CA|Mozilla's Root CA Program]], there is a list of root certificates that are trusted to issue [[CA/EV_Processing_for_CAs|Extended Validation (EV) certificates]]. This list is available in code form at https://hg.mozilla.org/mozilla-central/annotate/tip/security/certverifier/ExtendedValidation.cpp.<br />
<br />
== Other Verification Routines in NSS ==<br />
<br />
NSS exposes other certificate verification functions that are not yet implemented using mozilla::pkix. The following is informational and has little bearing on the behavior of Firefox.<br />
<br />
=== "classic" verification ===<br />
<br />
The so-called "classic" certificate verification algorithm performs issuer-independent checks on the given certificate, finds a potential issuer, verifies that the signature matches, and recurses. If multiple issuers are found, it attempts to use the "best" one. However, this is a heuristic, and as it does not perform backtracking, it can fail to verify a valid certificate. This is spectacularly apparent in the case of key-pinning if the algorithm chooses to not traverse a certificate path that contains a necessary key.<br />
<br />
The code is here: https://hg.mozilla.org/projects/nss/file/tip/lib/certhigh<br />
<br />
=== libpkix ===<br />
libpkix was auto-translated from Java to C. It attempts to implement Java's exception semantics in C. It makes liberal use of unclear macros (e.g. https://hg.mozilla.org/projects/nss/annotate/5d9f8b809e6f7020529ba1345b64e36f61994c8d/lib/libpkix/pkix/util/pkix_tools.h#l67 ). A source-line-counting tool clocks it in at 45,000 lines of code (the code is here: https://hg.mozilla.org/projects/nss/file/tip/lib/libpkix ). There are known bugs in the implementation.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/Certificate_Verification&diff=1219266SecurityEngineering/Certificate Verification2019-10-17T23:42:47Z<p>Dkeeler: add note that the NSS-specific libraries don't affect Firefox</p>
<hr />
<div>== Background ==<br />
<br />
Gecko (and therefore Firefox) relies on NSS to implement various cryptographic functions. NSS consists of a collection of loosely-coupled libraries. libssl, for example, is the TLS implementation. NSS is a Mozilla project, but its development differs significantly from the rest of the tree. In fact, it has its own tree that is periodically imported wholesale into mozilla-central. The component that uses the NSS libraries in Firefox is a layer called PSM ("Personal Security Manager" or "Privacy and Security Module").<br />
<br />
To enable secure TLS connections to the best of our ability, PSM implements a certificate verification callback. It performs a number of checks, but ultimately it must determine if it trusts a certificate presented by a peer. The approach PSM takes is to repeatedly build a potential path to a trust anchor, validate the potential path, and either return that path if it validates correctly or find another potential path. mozilla::pkix is a C++ library that provides a framework to implement this approach.<br />
<br />
== mozilla::pkix ==<br />
<br />
mozilla::pkix was originally implemented as part of mozilla-central (i.e. gecko) but has since been moved into NSS. However, it is not part of NSS' stable C API. As a library, mozilla::pkix uses the notion of a "trust domain" provided by the application to build a trusted chain from an end-entity certificate to a root. The trust domain is responsible for saying what trust level a certificate has, finding potential issuers of a certificate, and checking the revocation for a certificate. A certificate can be a trust anchor, it can inherit its trust, or it can be actively distrusted. Given an end-entity certificate and a trust domain, the library will perform issuer-independent checks on that certificate (e.g. expiration, appropriate key usages), get a list of potential issuers, and perform a depth-first traversal. If it encounters a distrusted certificate, it abandons searching that path. If it finds a trust anchor, it queries the trust domain again to see if that path is acceptable (this is where gecko implements checks that are specific to the platform and not the abstract problem of building a trusted certificate chain). If so, the end-entity certificate has successfully been verified.<br />
<br />
Unlike the other NSS libraries, mozilla::pkix is written in C++ and can take advantage of more modern language features.<br />
<br />
=== Trust Anchors ===<br />
<br />
The platform looks for trust anchors in a few locations. First, Mozilla ships a list of trust anchors with the platform corresponding to the root Certificate Authorities (CAs) in the Mozilla Root CA Program. Additionally, the user may import their own trust anchors. These are stored in the profile's cert9.db file. The user may also import third-party PKCS#11 modules that provide trust anchors. The enterprise roots feature, if enabled, may collect trust anchors provided by the operating system.<br />
<br />
=== Intermediate Certificates ===<br />
<br />
Similarly, the platform gathers intermediate certificates from a few locations. The TLS specification mandates that the peer include in the handshake any necessary intermediate certificates to verify the end-entity. In practice this may not be the case, but the platform uses these if they are available. The user may manually add intermediate certificates. Again these are stored in the profile's cert9.db file. The enterprise roots feature also looks for intermediates provided by the operating system.<br />
<br />
When the platform successfully verifies an end-entity certificate, it caches the intermediates from that verified chain in the profile (cert9.db) in case they will be useful in the future (for example, when connecting to a different peer that uses a certificate issued by the same CA but neglects to include intermediate certificates in the handshake).<br />
<br />
=== Extended Validation ===<br />
<br />
As part of Mozilla's Root CA Program, there is a list of root certificates that are trusted to issue Extended Validation (EV) certificates. This list is available in code form at https://hg.mozilla.org/mozilla-central/annotate/tip/security/certverifier/ExtendedValidation.cpp.<br />
<br />
== Other Verification Routines in NSS ==<br />
<br />
NSS exposes other certificate verification functions that are not yet implemented using mozilla::pkix. The following is informational and has little bearing on the behavior of Firefox.<br />
<br />
=== "classic" verification ===<br />
<br />
The so-called "classic" certificate verification algorithm performs issuer-independent checks on the given certificate, finds a potential issuer, verifies that the signature matches, and recurses. If multiple issuers are found, it attempts to use the "best" one. However, this is a heuristic, and as it does not perform backtracking, it can fail to verify a valid certificate. This is spectacularly apparent in the case of key-pinning if the algorithm chooses to not traverse a certificate path that contains a necessary key.<br />
<br />
The code is here: https://hg.mozilla.org/projects/nss/file/tip/lib/certhigh<br />
<br />
=== libpkix ===<br />
libpkix was auto-translated from Java to C. It attempts to implement Java's exception semantics in C. It makes liberal use of unclear macros (e.g. https://hg.mozilla.org/projects/nss/annotate/5d9f8b809e6f7020529ba1345b64e36f61994c8d/lib/libpkix/pkix/util/pkix_tools.h#l67 ). A source-line-counting tool clocks it in at 45,000 lines of code (the code is here: https://hg.mozilla.org/projects/nss/file/tip/lib/libpkix ). There are known bugs in the implementation. No one who works on it wants to continue working on it.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/Certificate_Verification&diff=1219265SecurityEngineering/Certificate Verification2019-10-17T23:41:15Z<p>Dkeeler: update link to EV information</p>
<hr />
<div>== Background ==<br />
<br />
Gecko (and therefore Firefox) relies on NSS to implement various cryptographic functions. NSS consists of a collection of loosely-coupled libraries. libssl, for example, is the TLS implementation. NSS is a Mozilla project, but its development differs significantly from the rest of the tree. In fact, it has its own tree that is periodically imported wholesale into mozilla-central. The component that uses the NSS libraries in Firefox is a layer called PSM ("Personal Security Manager" or "Privacy and Security Module").<br />
<br />
To enable secure TLS connections to the best of our ability, PSM implements a certificate verification callback. It performs a number of checks, but ultimately it must determine if it trusts a certificate presented by a peer. The approach PSM takes is to repeatedly build a potential path to a trust anchor, validate the potential path, and either return that path if it validates correctly or find another potential path. mozilla::pkix is a C++ library that provides a framework to implement this approach.<br />
<br />
== mozilla::pkix ==<br />
<br />
mozilla::pkix was originally implemented as part of mozilla-central (i.e. gecko) but has since been moved into NSS. However, it is not part of NSS' stable C API. As a library, mozilla::pkix uses the notion of a "trust domain" provided by the application to build a trusted chain from an end-entity certificate to a root. The trust domain is responsible for saying what trust level a certificate has, finding potential issuers of a certificate, and checking the revocation for a certificate. A certificate can be a trust anchor, it can inherit its trust, or it can be actively distrusted. Given an end-entity certificate and a trust domain, the library will perform issuer-independent checks on that certificate (e.g. expiration, appropriate key usages), get a list of potential issuers, and perform a depth-first traversal. If it encounters a distrusted certificate, it abandons searching that path. If it finds a trust anchor, it queries the trust domain again to see if that path is acceptable (this is where gecko implements checks that are specific to the platform and not the abstract problem of building a trusted certificate chain). If so, the end-entity certificate has successfully been verified.<br />
<br />
Unlike the other NSS libraries, mozilla::pkix is written in C++ and can take advantage of more modern language features.<br />
<br />
=== Trust Anchors ===<br />
<br />
The platform looks for trust anchors in a few locations. First, Mozilla ships a list of trust anchors with the platform corresponding to the root Certificate Authorities (CAs) in the Mozilla Root CA Program. Additionally, the user may import their own trust anchors. These are stored in the profile's cert9.db file. The user may also import third-party PKCS#11 modules that provide trust anchors. The enterprise roots feature, if enabled, may collect trust anchors provided by the operating system.<br />
<br />
=== Intermediate Certificates ===<br />
<br />
Similarly, the platform gathers intermediate certificates from a few locations. The TLS specification mandates that the peer include in the handshake any necessary intermediate certificates to verify the end-entity. In practice this may not be the case, but the platform uses these if they are available. The user may manually add intermediate certificates. Again these are stored in the profile's cert9.db file. The enterprise roots feature also looks for intermediates provided by the operating system.<br />
<br />
When the platform successfully verifies an end-entity certificate, it caches the intermediates from that verified chain in the profile (cert9.db) in case they will be useful in the future (for example, when connecting to a different peer that uses a certificate issued by the same CA but neglects to include intermediate certificates in the handshake).<br />
<br />
=== Extended Validation ===<br />
<br />
As part of Mozilla's Root CA Program, there is a list of root certificates that are trusted to issue Extended Validation (EV) certificates. This list is available in code form at https://hg.mozilla.org/mozilla-central/annotate/tip/security/certverifier/ExtendedValidation.cpp.<br />
<br />
== Other Verification Routines in NSS ==<br />
<br />
NSS exposes other certificate verification functions that are not yet implemented using mozilla::pkix.<br />
<br />
=== "classic" verification ===<br />
<br />
The so-called "classic" certificate verification algorithm performs issuer-independent checks on the given certificate, finds a potential issuer, verifies that the signature matches, and recurses. If multiple issuers are found, it attempts to use the "best" one. However, this is a heuristic, and as it does not perform backtracking, it can fail to verify a valid certificate. This is spectacularly apparent in the case of key-pinning if the algorithm chooses to not traverse a certificate path that contains a necessary key.<br />
<br />
The code is here: https://hg.mozilla.org/projects/nss/file/tip/lib/certhigh<br />
<br />
=== libpkix ===<br />
libpkix was auto-translated from Java to C. It attempts to implement Java's exception semantics in C. It makes liberal use of unclear macros (e.g. https://hg.mozilla.org/projects/nss/annotate/5d9f8b809e6f7020529ba1345b64e36f61994c8d/lib/libpkix/pkix/util/pkix_tools.h#l67 ). A source-line-counting tool clocks it in at 45,000 lines of code (the code is here: https://hg.mozilla.org/projects/nss/file/tip/lib/libpkix ). There are known bugs in the implementation. No one who works on it wants to continue working on it.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/Certificate_Verification&diff=1219264SecurityEngineering/Certificate Verification2019-10-17T23:39:22Z<p>Dkeeler: add intermediate certificate section</p>
<hr />
<div>== Background ==<br />
<br />
Gecko (and therefore Firefox) relies on NSS to implement various cryptographic functions. NSS consists of a collection of loosely-coupled libraries. libssl, for example, is the TLS implementation. NSS is a Mozilla project, but its development differs significantly from the rest of the tree. In fact, it has its own tree that is periodically imported wholesale into mozilla-central. The component that uses the NSS libraries in Firefox is a layer called PSM ("Personal Security Manager" or "Privacy and Security Module").<br />
<br />
To enable secure TLS connections to the best of our ability, PSM implements a certificate verification callback. It performs a number of checks, but ultimately it must determine if it trusts a certificate presented by a peer. The approach PSM takes is to repeatedly build a potential path to a trust anchor, validate the potential path, and either return that path if it validates correctly or find another potential path. mozilla::pkix is a C++ library that provides a framework to implement this approach.<br />
<br />
== mozilla::pkix ==<br />
<br />
mozilla::pkix was originally implemented as part of mozilla-central (i.e. gecko) but has since been moved into NSS. However, it is not part of NSS' stable C API. As a library, mozilla::pkix uses the notion of a "trust domain" provided by the application to build a trusted chain from an end-entity certificate to a root. The trust domain is responsible for saying what trust level a certificate has, finding potential issuers of a certificate, and checking the revocation for a certificate. A certificate can be a trust anchor, it can inherit its trust, or it can be actively distrusted. Given an end-entity certificate and a trust domain, the library will perform issuer-independent checks on that certificate (e.g. expiration, appropriate key usages), get a list of potential issuers, and perform a depth-first traversal. If it encounters a distrusted certificate, it abandons searching that path. If it finds a trust anchor, it queries the trust domain again to see if that path is acceptable (this is where gecko implements checks that are specific to the platform and not the abstract problem of building a trusted certificate chain). If so, the end-entity certificate has successfully been verified.<br />
<br />
Unlike the other NSS libraries, mozilla::pkix is written in C++ and can take advantage of more modern language features.<br />
<br />
=== Trust Anchors ===<br />
<br />
The platform looks for trust anchors in a few locations. First, Mozilla ships a list of trust anchors with the platform corresponding to the root Certificate Authorities (CAs) in the Mozilla Root CA Program. Additionally, the user may import their own trust anchors. These are stored in the profile's cert9.db file. The user may also import third-party PKCS#11 modules that provide trust anchors. The enterprise roots feature, if enabled, may collect trust anchors provided by the operating system.<br />
<br />
=== Intermediate Certificates ===<br />
<br />
Similarly, the platform gathers intermediate certificates from a few locations. The TLS specification mandates that the peer include in the handshake any necessary intermediate certificates to verify the end-entity. In practice this may not be the case, but the platform uses these if they are available. The user may manually add intermediate certificates. Again these are stored in the profile's cert9.db file. The enterprise roots feature also looks for intermediates provided by the operating system.<br />
<br />
When the platform successfully verifies an end-entity certificate, it caches the intermediates from that verified chain in the profile (cert9.db) in case they will be useful in the future (for example, when connecting to a different peer that uses a certificate issued by the same CA but neglects to include intermediate certificates in the handshake).<br />
<br />
=== Extended Validation ===<br />
<br />
As part of Mozilla's Root CA Program, there is a list of root certificates that are trusted to issue Extended Validation (EV) certificates. This list is available in code form at https://hg.mozilla.org/mozilla-central/annotate/80374044414da9f5b3634c91345d07612754fcda/security/certverifier/ExtendedValidation.cpp#l90<br />
<br />
== Other Verification Routines in NSS ==<br />
<br />
NSS exposes other certificate verification functions that are not yet implemented using mozilla::pkix.<br />
<br />
=== "classic" verification ===<br />
<br />
The so-called "classic" certificate verification algorithm performs issuer-independent checks on the given certificate, finds a potential issuer, verifies that the signature matches, and recurses. If multiple issuers are found, it attempts to use the "best" one. However, this is a heuristic, and as it does not perform backtracking, it can fail to verify a valid certificate. This is spectacularly apparent in the case of key-pinning if the algorithm chooses to not traverse a certificate path that contains a necessary key.<br />
<br />
The code is here: https://hg.mozilla.org/projects/nss/file/tip/lib/certhigh<br />
<br />
=== libpkix ===<br />
libpkix was auto-translated from Java to C. It attempts to implement Java's exception semantics in C. It makes liberal use of unclear macros (e.g. https://hg.mozilla.org/projects/nss/annotate/5d9f8b809e6f7020529ba1345b64e36f61994c8d/lib/libpkix/pkix/util/pkix_tools.h#l67 ). A source-line-counting tool clocks it in at 45,000 lines of code (the code is here: https://hg.mozilla.org/projects/nss/file/tip/lib/libpkix ). There are known bugs in the implementation. No one who works on it wants to continue working on it.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/Certificate_Verification&diff=1219263SecurityEngineering/Certificate Verification2019-10-17T23:30:12Z<p>Dkeeler: fix typo</p>
<hr />
<div>== Background ==<br />
<br />
Gecko (and therefore Firefox) relies on NSS to implement various cryptographic functions. NSS consists of a collection of loosely-coupled libraries. libssl, for example, is the TLS implementation. NSS is a Mozilla project, but its development differs significantly from the rest of the tree. In fact, it has its own tree that is periodically imported wholesale into mozilla-central. The component that uses the NSS libraries in Firefox is a layer called PSM ("Personal Security Manager" or "Privacy and Security Module").<br />
<br />
To enable secure TLS connections to the best of our ability, PSM implements a certificate verification callback. It performs a number of checks, but ultimately it must determine if it trusts a certificate presented by a peer. The approach PSM takes is to repeatedly build a potential path to a trust anchor, validate the potential path, and either return that path if it validates correctly or find another potential path. mozilla::pkix is a C++ library that provides a framework to implement this approach.<br />
<br />
== mozilla::pkix ==<br />
<br />
mozilla::pkix was originally implemented as part of mozilla-central (i.e. gecko) but has since been moved into NSS. However, it is not part of NSS' stable C API. As a library, mozilla::pkix uses the notion of a "trust domain" provided by the application to build a trusted chain from an end-entity certificate to a root. The trust domain is responsible for saying what trust level a certificate has, finding potential issuers of a certificate, and checking the revocation for a certificate. A certificate can be a trust anchor, it can inherit its trust, or it can be actively distrusted. Given an end-entity certificate and a trust domain, the library will perform issuer-independent checks on that certificate (e.g. expiration, appropriate key usages), get a list of potential issuers, and perform a depth-first traversal. If it encounters a distrusted certificate, it abandons searching that path. If it finds a trust anchor, it queries the trust domain again to see if that path is acceptable (this is where gecko implements checks that are specific to the platform and not the abstract problem of building a trusted certificate chain). If so, the end-entity certificate has successfully been verified.<br />
<br />
Unlike the other NSS libraries, mozilla::pkix is written in C++ and can take advantage of more modern language features.<br />
<br />
=== Trust Anchors ===<br />
<br />
The platform looks for trust anchors in a few locations. First, Mozilla ships a list of trust anchors with the platform corresponding to the root Certificate Authorities (CAs) in the Mozilla Root CA Program. Additionally, the user may import their own trust anchors. These are stored in the profile's cert9.db file. The user may also import third-party PKCS#11 modules that provide trust anchors. The enterprise roots feature, if enabled, may collect trust anchors provided by the operating system.<br />
<br />
=== Extended Validation ===<br />
<br />
As part of Mozilla's Root CA Program, there is a list of root certificates that are trusted to issue Extended Validation (EV) certificates. This list is available in code form at https://hg.mozilla.org/mozilla-central/annotate/80374044414da9f5b3634c91345d07612754fcda/security/certverifier/ExtendedValidation.cpp#l90<br />
<br />
== Other Verification Routines in NSS ==<br />
<br />
NSS exposes other certificate verification functions that are not yet implemented using mozilla::pkix.<br />
<br />
=== "classic" verification ===<br />
<br />
The so-called "classic" certificate verification algorithm performs issuer-independent checks on the given certificate, finds a potential issuer, verifies that the signature matches, and recurses. If multiple issuers are found, it attempts to use the "best" one. However, this is a heuristic, and as it does not perform backtracking, it can fail to verify a valid certificate. This is spectacularly apparent in the case of key-pinning if the algorithm chooses to not traverse a certificate path that contains a necessary key.<br />
<br />
The code is here: https://hg.mozilla.org/projects/nss/file/tip/lib/certhigh<br />
<br />
=== libpkix ===<br />
libpkix was auto-translated from Java to C. It attempts to implement Java's exception semantics in C. It makes liberal use of unclear macros (e.g. https://hg.mozilla.org/projects/nss/annotate/5d9f8b809e6f7020529ba1345b64e36f61994c8d/lib/libpkix/pkix/util/pkix_tools.h#l67 ). A source-line-counting tool clocks it in at 45,000 lines of code (the code is here: https://hg.mozilla.org/projects/nss/file/tip/lib/libpkix ). There are known bugs in the implementation. No one who works on it wants to continue working on it.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/Certificate_Verification&diff=1218703SecurityEngineering/Certificate Verification2019-10-08T00:07:10Z<p>Dkeeler: beginning of updates to certificate verification documentation</p>
<hr />
<div>== Background ==<br />
<br />
Gecko (and therefore Firefox) relies on NSS to implement various cryptographic functions. NSS consists of a collection of loosely-coupled libraries. libssl, for example, is the TLS implementation. NSS is a Mozilla project, but its development differs significantly from the rest of the tree. In fact, it has its own tree that is periodically imported wholesale into mozilla-central. The component that uses the NSS libraries in Firefox is a layer called PSM ("Personal Security Manager" or "Privacy and Security Module").<br />
<br />
To enable secure TLS connections to the best of our ability, PSM implements a certificate verification callback. It performs a number of checks, but ultimately it must determine if it trusts a certificate presented by a peer. The approach PSM takes is to repeatedly build a potential path to a trust anchor, validate the potential path, and either return that path if it validates correctly or find another potential path. mozilla::pkix is a C++ library that provides a framework to implement this approach.<br />
<br />
== mozilla::pkix ==<br />
<br />
mozilla::pkix was originally implemented as part of mozilla-central (i.e. gecko) but has since been moved into NSS. However, it is not part of NSS' stable C API. As a library, mozilla::pkix uses the notion of a "trust domain" provided by the application to build a trusted chain from an end-entity certificate to a root. The trust domain is responsible for saying what trust level a certificate has, finding potential issuers of a certificate, and checking the revocation for a certificate. A certificate can be a trust anchor, it can inherit its trust, or it can be actively distrusted. Given an end-entity certificate and a trust domain, the library will perform issuer-independent checks on that certificate (e.g. expiration, appropriate key usages), get a list of potential issuers, and perform a depth-first traversal. If it encounters a distrusted certificate, it abandons searching that path. If it finds a trust anchor, it queries the trust domain again to see if that path is acceptable (this is where gecko implements checks that are specific to the platform at not the abstract problem of building a trusted certificate chain). If so, the end-entity certificate has successfully been verified.<br />
<br />
Unlike the other NSS libraries, mozilla::pkix is written in C++ and can take advantage of more modern language features.<br />
<br />
=== Trust Anchors ===<br />
<br />
The platform looks for trust anchors in a few locations. First, Mozilla ships a list of trust anchors with the platform corresponding to the root Certificate Authorities (CAs) in the Mozilla Root CA Program. Additionally, the user may import their own trust anchors. These are stored in the profile's cert9.db file. The user may also import third-party PKCS#11 modules that provide trust anchors. The enterprise roots feature, if enabled, may collect trust anchors provided by the operating system.<br />
<br />
=== Extended Validation ===<br />
<br />
As part of Mozilla's Root CA Program, there is a list of root certificates that are trusted to issue Extended Validation (EV) certificates. This list is available in code form at https://hg.mozilla.org/mozilla-central/annotate/80374044414da9f5b3634c91345d07612754fcda/security/certverifier/ExtendedValidation.cpp#l90<br />
<br />
== Other Verification Routines in NSS ==<br />
<br />
NSS exposes other certificate verification functions that are not yet implemented using mozilla::pkix.<br />
<br />
=== "classic" verification ===<br />
<br />
The so-called "classic" certificate verification algorithm performs issuer-independent checks on the given certificate, finds a potential issuer, verifies that the signature matches, and recurses. If multiple issuers are found, it attempts to use the "best" one. However, this is a heuristic, and as it does not perform backtracking, it can fail to verify a valid certificate. This is spectacularly apparent in the case of key-pinning if the algorithm chooses to not traverse a certificate path that contains a necessary key.<br />
<br />
The code is here: https://hg.mozilla.org/projects/nss/file/tip/lib/certhigh<br />
<br />
=== libpkix ===<br />
libpkix was auto-translated from Java to C. It attempts to implement Java's exception semantics in C. It makes liberal use of unclear macros (e.g. https://hg.mozilla.org/projects/nss/annotate/5d9f8b809e6f7020529ba1345b64e36f61994c8d/lib/libpkix/pkix/util/pkix_tools.h#l67 ). A source-line-counting tool clocks it in at 45,000 lines of code (the code is here: https://hg.mozilla.org/projects/nss/file/tip/lib/libpkix ). There are known bugs in the implementation. No one who works on it wants to continue working on it.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/HTTP_Strict_Transport_Security_(HSTS)_Preload_List&diff=1214182SecurityEngineering/HTTP Strict Transport Security (HSTS) Preload List2019-06-25T18:13:15Z<p>Dkeeler: update search string for treeherder links</p>
<hr />
<div>Firefox ships with a list of hosts that are considered HTTP Strict Transport Security (HSTS - [https://tools.ietf.org/html/rfc6797 see RFC 6797]) by default. This list is based on [https://www.chromium.org/hsts/ a list Chromium maintains]. The versions of the list as it exists in the various channels of Firefox are available here: [https://hg.mozilla.org/mozilla-central/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-central] [https://hg.mozilla.org/releases/mozilla-beta/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-beta] [https://hg.mozilla.org/releases/mozilla-release/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-release] [https://hg.mozilla.org/releases/mozilla-esr60/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-esr60].<br />
<br />
Every day, an automated job attempts to update the preload list in mozilla-central and mozilla-esr. This involves running an xpcshell script that makes an https request to each candidate host on the list. If xpcshell can connect successfully to a host and receives a "Strict-Transport-Security" header with a max-age value of at least 10886400 (18 weeks in seconds), that host is included in the list (the "preload" directive is ignored). If xpcshell cannot connect successfully to a host or does not receive an appropriate header, that host is not included in the preload list.<br />
<br />
The xpcshell script is [https://hg.mozilla.org/mozilla-central/file/tip/taskcluster/docker/periodic-updates/scripts/getHSTSPreloadList.js here]. Output from the automated job as run on each branch is available here: [https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&searchStr=pfu mozilla-central] [https://treeherder.mozilla.org/#/jobs?repo=mozilla-esr60&searchStr=pfu esr60] (scroll down until there's a line containing "pfu", click on that, then click on "live.log" in the pane that pops up).<br />
<br />
To guard against accidentally dropping a host from the list due to intermittent network issues or an active attacker, if a host is already on the preload list in Firefox but cannot be reached, the script keeps it on the preload list. For a host to be removed from Firefox's preload list, it must be accessible when the update script runs and it must either not send a Strict-Transport-Security header or it must send the header with a max-age less than 10886400.<br />
<br />
The preload list has a built-in expiration time that is 18 weeks from when the list was most recently updated.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/HTTP_Strict_Transport_Security_(HSTS)_Preload_List&diff=1213810SecurityEngineering/HTTP Strict Transport Security (HSTS) Preload List2019-06-14T18:03:01Z<p>Dkeeler: update esr52 -> esr60, fix some links with move to taskcluster/treeherder</p>
<hr />
<div>Firefox ships with a list of hosts that are considered HTTP Strict Transport Security (HSTS - [https://tools.ietf.org/html/rfc6797 see RFC 6797]) by default. This list is based on [https://www.chromium.org/hsts/ a list Chromium maintains]. The versions of the list as it exists in the various channels of Firefox are available here: [https://hg.mozilla.org/mozilla-central/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-central] [https://hg.mozilla.org/releases/mozilla-beta/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-beta] [https://hg.mozilla.org/releases/mozilla-release/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-release] [https://hg.mozilla.org/releases/mozilla-esr60/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-esr60].<br />
<br />
Every day, an automated job attempts to update the preload list in mozilla-central and mozilla-esr. This involves running an xpcshell script that makes an https request to each candidate host on the list. If xpcshell can connect successfully to a host and receives a "Strict-Transport-Security" header with a max-age value of at least 10886400 (18 weeks in seconds), that host is included in the list (the "preload" directive is ignored). If xpcshell cannot connect successfully to a host or does not receive an appropriate header, that host is not included in the preload list.<br />
<br />
The xpcshell script is [https://hg.mozilla.org/mozilla-central/file/tip/taskcluster/docker/periodic-updates/scripts/getHSTSPreloadList.js here]. Output from the automated job as run on each branch is available here: [https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&searchStr=repo-update mozilla-central] [https://treeherder.mozilla.org/#/jobs?repo=mozilla-esr60&searchStr=repo-update esr60] (scroll down until there's a line containing "pfu", click on that, then click on "live.log" in the pane that pops up).<br />
<br />
To guard against accidentally dropping a host from the list due to intermittent network issues or an active attacker, if a host is already on the preload list in Firefox but cannot be reached, the script keeps it on the preload list. For a host to be removed from Firefox's preload list, it must be accessible when the update script runs and it must either not send a Strict-Transport-Security header or it must send the header with a max-age less than 10886400.<br />
<br />
The preload list has a built-in expiration time that is 18 weeks from when the list was most recently updated.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=Security/CryptoEngineering/Intermediate_Preloading&diff=1208999Security/CryptoEngineering/Intermediate Preloading2019-03-15T16:24:48Z<p>Dkeeler: add link to tracking bug</p>
<hr />
<div>= Intermediate CA Preloading =<br />
<br />
In [https://bugzilla.mozilla.org/show_bug.cgi?id=1404934 Bug 1404934] we've added support to download the Intermediate Certificate Authorities that have been disclosed to the [[CA|Mozilla CA Root Program]] from [https://www.kinto-storage.org/ Kinto] in the background during normal Firefox operation. <br />
<br />
This is currently only enabled for Nightly users on desktop platforms. (March 2019)<br />
<br />
Remaining work is being tracked by [https://bugzilla.mozilla.org/show_bug.cgi?id=1535662 Bug 1535662].<br />
<br />
== What it does ==<br />
<br />
Websites using encryption should provide two digital PKI certificates [1] 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.<br />
<br />
When other browsers encounter this case, they use a mechanism where the user's browser then, in the background, connects to the CA and downloads the certificate just-in-time.<br />
<br />
=== Performance ===<br />
<br />
Preloading the intermediate CA data avoids the just-in-time network fetch, which delays the connection.<br />
<br />
=== Privacy ===<br />
<br />
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.<br />
<br />
It's also helpful because it's [https://shiftordie.de/blog/2017/02/21/fingerprinting-firefox-users-with-cached-intermediate-ca-certificates-fiprinca/ 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]. Preloading ensures that all users have "seen" all the same intermediate CAs.<br />
<br />
=== Protection ===<br />
<br />
The Mozilla CA program requires all members to disclose intermediate CAs before using them, as a safety measure. However, there is not currently a way to technically enforce that. Intermediate Preloading can eventually 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 a secret intermediate CA, which is then used to attack people on the Internet. <br />
<br />
== How it works ==<br />
<br />
Intermediate Preloading fetches ~100 intermediate certificate authorities' certificates once a day during the Kinto main update [2], 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 [3]. We will likely increase the rate after the initial experiments.<br />
<br />
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 [https://bugzilla.mozilla.org/show_bug.cgi?id=1530545 Bug 1530545].<br />
<br />
Currently preloading is only enabled for desktop users on Nightly. We will want to restrict the download to be only over WiFi before enabling on mobile. <br />
<br />
== Expected Results ==<br />
<br />
Intermediate Preloading should reduce the number of SEC_ERROR_UNKNOWN_ISSUER errors seen by Firefox users over time, which is our most common error. <br />
<br />
Telemetry for Intermediate Preloading is available in the histograms:<br />
* "INTERMEDIATE_PRELOADING_ERRORS"<br />
* "INTERMEDIATE_PRELOADING_UPDATE_TIME_MS"<br />
<br />
and the scalars:<br />
<br />
* "security.intermediate_preloading_num_pending"<br />
* "security.intermediate_preloading_num_preloaded"<br />
<br />
===== Footnotes =====<br />
[1] The WebPKI generally has one root CA certificate, one intermediate CA certificate, and then one end-entity (specific website) certificate. Sometimes there can be more than one intermediate CA certificate, potentially much more than one. (https://tls-observatory.services.mozilla.com/static/certsplainer.html?id=188088012) <br />
<br />
[2] 100/day is configurable by a pref, it is likely to change. See https://searchfox.org/mozilla-central/source/security/manager/ssl/security-prefs.js#166 .<br />
<br />
[3] The data is loaded from Kinto here:<br />
https://settings.prod.mozaws.net/v1/buckets/security-state/collections/intermediates/records . This data is exported from the [https://ccadb.org/ Common CA Database] maintained by the Mozilla root program.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=Security/DNSSEC-TLS-details&diff=1206399Security/DNSSEC-TLS-details2019-01-18T18:25:36Z<p>Dkeeler: add historical content notice</p>
<hr />
<div><p style="border: 2px solid red;"><b>This is historical content and has not been revised since it was written about Firefox Desktop in 2011.</b></p><br />
<br />
Tracking bug: [https://bugzilla.mozilla.org/show_bug.cgi?id=672239 672239]<br />
<br />
== Background ==<br />
<br />
For more background information on TLS and DNSSEC, click [[Security/DNSSEC-TLS/Background|here]].<br />
<br />
=== Embedding Certificate Information in DNS ===<br />
[http://tools.ietf.org/html/draft-ietf-dane-protocol-10 DANE], [http://tools.ietf.org/html/draft-hallambaker-donotissue-04 Certification Authority Authorization (CAA)], and [http://tools.ietf.org/html/rfc2538 CERT] records are all methods of embedding certificate information in DNS records. With DANE, either the public key or entire certificate (or the hash thereof) may be put in a TLSA record that specifies, for example, the certificate or public key to be used for connecting to example.com tcp port 443 (in the record _443._tcp.example.com). CAA uses the hash of the certificate and can specify that any certificate issued for (for example) example.com must be rooted by the hashed certificate. CAA uses TYPE257 records. CAA has other policy options, as well. CERT simply embeds a certificate in a DNS record. For the time being, while CAA is powerful, it has been determined to be too complicated for this use case. Furthermore, CERT can only specify whole certificates, not just public keys, and is thus too restrictive. Thus, DANE alone will initially be supported.<br />
<br />
=== Domain Validation ===<br />
To use DNSSEC to perform domain validation, a key or certificate must be put in a DANE record corresponding to the server to validate. Then, during the TLS handshake, the chain of DNSSEC records from that record to an agreed-upon root must be sent along with the server certificate. The client can walk this chain of records to a trusted root to validate the material. If this succeeds, the client then uses either the embedded key material or the key material in the server certificate (that has just been validated by the DNSSEC chain) as the public key for a key exchange. Note that if the DANE record consists of an entire certificate and that certificate will always be sent in the TLS handshake, the DANE record itself may be omitted. In this case, the RRSIG record for the DANE record will have to be used to validate the certificate sent in TLS.<br />
<br />
Obviously this mechanism could work out of band. That is, instead of embedding the DNSSEC chain in the TLS handshake, the client could perform simultaneous DNSSEC lookups to verify the material in the server certificate. However, this would be significantly slower as it would involve multiple round-trip communications with another server.<br />
<br />
=== How this is Different from Certificates ===<br />
<br />
This mechanism does not require the involvement of a certificate authority. A server can issue a self-signed certificate and bind that certificate to a DANE record (either by key, whole certificate, or hash of either). Then, provided there exists a valid DNSSEC chain back to the root of trust, the self-signed certificate will be authenticated by that chain in the TLS handshake.<br />
<br />
Alternatively, a server can use a certificate issued by a CA. In this case both the certificate chain and the DNSSEC chain must be valid.<br />
<br />
This mechanism prevents CAs mis-issuing certificates. If a CA issues a certificate it was not supposed to, and that certificate gets used, it will not match the contents of the DANE/CAA record. Of course, the server with the bad certificate could simply omit the DNSSEC chain, so if none is sent, perhaps we should perform the out of band DNSSEC chain verification ourselves.<br />
<br />
== DNSSEC Chains ==<br />
<br />
The process of verifying a DNSSEC chain is discussed in general [[Security/DNSSEC-TLS/Background#Verifying a DNSSEC Chain|here]].<br />
<br />
The format of a serialized DNSSEC chain sent in this protocol consists first of a series of the following:<br />
<br />
* The DNSKEY (and corresponding RRSIG) records for a zone, in wire format. There must be a key signing key present.<br />
* A DS (and corresponding RRSIG) record for the key signing key in the previous record, in wire format. This DS must be from a zone outer to that of the keys. The following set of keys must be from the same zone as this DS record.<br />
<br />
The root zone may be omitted, because it is assumed that the client already has the DNSSEC keys for the root. The TLSA (and corresponding RRSIG) record is prefixed to the chain and must be from the same zone as the first key set.<br />
<br />
So, for example, the DNSSEC chain sent for clients connecting to foo.bar.com could be:<br />
<br />
* The TLSA (+RRSIG) for foo.bar.com<br />
* The DNSKEYS (+RRSIGs) for bar.com<br />
* The DS (+RRSIG) for bar.com (from .com)<br />
* The DNSKEYS (+RRSIGs) for .com<br />
* The DS (+RRSIG) for .com (from .)<br />
<br />
It is possible to optimize away some fields of these records, but at the moment this is not being done. Another optimization would be for the client to indicate a root of trust deeper down the tree so that the server can omit some zones. For example, a client may already have (and have validated) all of the keys for .com. In the above example, if the client has already validated keys for .com, the server need only send the TLSA record, the keys for bar.com, and the DS record entering bar.com (as well as the signatures, of course).<br />
<br />
Note that once a chain has been serialized, it will only be valid for as long as every signature in it is valid. That is, it will become invalid when any signature it contains expires.<br />
<br />
For reference, another proposal for the serialization of a DNSSEC chain is [http://tools.ietf.org/html/draft-agl-dane-serializechain-01 here]. Note that this proposal does not follow exactly the wire format of DNS records. Additionally, it reverses the order of records. Consequently, preexisting code cannot be used to serialize, parse, or validate the chain. Additionally, more flexibility means more opportunities for insecure verifier behavior. This proposal is not currently being used in this project.<br />
<br />
== Google Chrome ==<br />
<br />
According to [http://www.imperialviolet.org/2011/06/16/dnssecchrome.html Adam Langley's Weblog], DNSSEC validation of TLS (specifically HTTPS) sessions is enabled by default in the canary and dev channels of Chrome. It is achieved through the server sending a self-signed certificate that contains as an X509 extension a blob of data corresponding to the DNSSEC chain. The leaf of the chain is a CAA record. The root of the chain is implicitly the root zone key signing key (the key itself is not included).<br />
<br />
== Security Considerations ==<br />
<br />
Using this mechanism, the ability to produce material that authenticates a domain is tied to the doman name hierarchy. That is, an arbitrary organization cannot masquerade as another party unless they control a level of the domain system closer to the root and on the same path as their target. This prevents the current situation where certificate authorities can issue certificates for domains they should not be allowed to. However, this still means that the organization in charge of the root zone can masquerade as any domain, and the organizations in charge of top level domains can masquerade as any domain below theirs, and so on.<br />
<br />
If a certificate is sent that includes a certificate chain, the certificate chain must validate up to a trusted root. This root is either the certificate identified by the TLSA record in the DNSSEC chain or a trusted root CA certificate.<br />
<br />
Similarly, if the certificate can be checked against OCSP or a CRL, it should be. If the certificate has been revoked, the TLS session should not continue.<br />
<br />
Currently there is no revocation mechanism for DNS keys or signatures. Most signatures are valid for 1 month, however, so if a key has been compromised, the window of opportunity for evildoers is short. One survey did come up with this, though: [http://secspider.cs.ucla.edu/images/key-lifetimes.png key signature lifetimes]<br />
<br />
Configuration of DNSSEC is not significantly more difficult than configuring DNS. As long as private keys are not exposed, it would be difficult to configure DNSSEC in a way that is operable yet insecure.<br />
<br />
TLS intercepting proxies essentially man-in-the-middle connections made to them. With certificate-based domain validation, users simply install an exception corresponding to the certificate of the proxy, allowing it to be a root of trust. The same idea could be used here, but it would be cumbersome. The proxy would have a root DNSKEY trusted by users. Upon any connection, the proxy could create a chain of DNS records rooted by that key. The users would then verify that chain. This obviously does not work if the DNSSEC chain lookup is done out of band. Another option is to simply fall back on certificate-based validation (with an exception installed by users). Hopefully the proxy itself would verify the DNSSEC chain in its connection to the actual server.<br />
<br />
If there is a mechanism for the client to say what keys have already been validated (thus decreasing the length of the chain a server must send), there may be privacy implications. For instance, if a only small number of sites have their DS records signed by a specific key from .com and the client indicates they have already validated that specific key, another server knows the client has visited one of those sites. There may be a way for a client to instead indicate they have all of the keys for a zone as of a certain time (i.e. "now"), thus eliminating a privacy leak.<br />
<br />
== Policies ==<br />
<br />
=== Self-signed Certificates ===<br />
<br />
For self-signed certificates, the policy is "The certificate chain must contain one self-signed certificate and the DNSSEC chain must be valid and correspond to data in the certificate." A TLSA certificate type of CA must not be used in this case.<br />
<br />
=== Untrusted Roots ===<br />
<br />
For certificates with a root of trust unknown to the client, a policy could be "The certificate chain must be valid up to the untrusted root and the DNSSEC chain must be valid and correspond to data in the untrusted root." A TLSA certificate type of CA or Public Key must be used in this case. In theory, this policy could be combined with that of self-signed certificates. It may be desirable to separate them for the sake of fine-grained policy control, however.<br />
<br />
=== Trusted Roots and DNSSEC ===<br />
<br />
For certificates with a known root of trust, the policy is "The certificate chain must be valid and (the DNSSEC chain must be valid or the domain does not require such additional validation)". Currently there is no mechanism to specify whether or not a domain requires DNSSEC validation. In This case any TLSA certificate type may be used.<br />
<br />
== CNAME issues ==<br />
<br />
The use of CNAME records introduces complexities into this system that have yet to be ironed out. First, if a CNAME record is present at a node, there are supposed to be no other records for that node. So, if foo.bar.com is CNAMEd to foo.bar.org, there should be no other records for foo.bar.com, and in particular there will be no TLSA record. Thus, when a client connects to foo.bar.com, no DNSSEC chain appropriate for this system can be created. (Note that it may be the case that the prefix mechanism can be used to circumvent this issue. That is, there could be a TLSA record for _443._tcp.foo.bar.com. This however does not solve all of the issues.)<br />
<br />
One way to deal with CNAMEs is to essentially build one chain per CNAME. That is, if foo.bar.com is CNAMEd to foo.bar.org, then a chain for foo.bar.com will be constructed using the CNAME record, and then a chain for foo.bar.org will be constructed using the TLSA record for foo.bar.org. If and only if both of these chains verify correctly and the hostname matches that of the first chain will the information in the TLSA record be used in the TLS connection. This could even be extended to multiple CNAMEs. If foo.bar.com is CNAMEd to foo.bar.org is CNAMEd to foo.bar.cn, then three chains will be present.<br />
<br />
This introduces a trust issue, however. If foo.bar.com is CNAMEd to foo.bar.cn, anyone in those two hierarchies can masquerade as foo.bar.com. As before, the owners of bar.com, .com, and . can create valid DNSSEC chains that appear to come from foo.bar.com. However, unlike before, now the owners of bar.cn and .cn can do the same. More importantly, just by looking at the domain name "foo.bar.com", it is not apparent that anyone outside that hierarchy has this power, when in fact they do. The issue is that while the owner of foo.bar.com may be fine with this, visitors to that site may not be, and yet they have no indication that such a thing may be taking place. Thus, it is not clear that allowing this form of delegation is desirable for the end user.<br />
<br />
== DNSSEC Libraries ==<br />
<br />
[http://www.nlnetlabs.nl/projects/ldns/ ldns], [https://www.dnssec-tools.org/ DNSSEC-Tools], and [http://unbound.net/download.html Unbound] all use BSD licenses. [http://vantage-points.org/libvdns.html libvdns] is a C++ DNS library. Thus far, I've had the most success using ldns. Unbound uses ldns.<br />
<br />
Most likely, any DNSSEC library will use openssl. So, if that library is included in Firefox, either openssl will have to be included as well or the library will have to be modified to use nss.<br />
<br />
== Creating a TLSA Record ==<br />
<br />
Material embedded in a TLSA record must follow the [http://tools.ietf.org/html/draft-ietf-dane-protocol-10 specification]. This involves making the decision of what to embed. The embedded material may be a certificate identifying an end entity (i.e. the server clients will connect to), a certification authority's certificate (where that certificate is a trust anchor for a certificate on the server), or a public key (which may correspond to either of the two situations). Then, the actual data embedded may be the full representation, a sha256 hash, or a sha512 hash. Different decisions may be appropriate for different situations. (This information is currently undergoing change - refer to the latest draft of the specification.)<br />
<br />
Once the certificate type and reference type are determined, the appropriate values can be used to construct an entry that goes into the zone file for the DNS server that is authoritative for the domain name in question. For instance, if the sha256 hash of a public key were to be used, the entry might look like this:<br />
<br />
WWW.EXAMPLE.COM. 60 IN TYPE65468 \# 34 0301731050b68ae9bb14f894a0fd3c2dbe4210336942cdd69036235593ca582e787d<br />
<br />
(Where the entry is intended to be a single contiguous line.) This specifies a record of type 65468 (experimental number for TLSA) that is 34 bytes long. The "03" at the beginning indicates a public key, and the "01" indicates sha256. The rest is the hash. (The actual data embedded in the record is represented as a series of in-order two-digit hexadecimal values that each correspond to a byte of data.)<br />
<br />
== Transmitting the DNSSEC Chain ==<br />
<br />
There are essentially two reasonable options for transmitting the DNSSEC chain in the TLS handshake. The first option is to include it as an X509 extension in the server certificate, as Google Chrome does (see above). The second option would be to define a TLS extension wherein the server sends the chain in addition to, but outside of, its certificate. In either case, the client would receive the chain, verify it, and if successful, continue the session. Note that the material provided in the chain does not replace the material from the certificate - it merely verifies it.<br />
<br />
The first option (X509 extension) is easy to deploy, as it only requires making a special certificate and minimal modifications to server software. It works well with self-signed certificates (where the TLSA record provides the chain of trust), but not with preexisting certificates signed by a third party. Furthermore, in order to use the optimization of sending a chain with a deeper root of trust (i.e. sending a shorter chain), the certificate would have to either be created on the fly or a certificate for every possible chain would have to be created (admittedly, this is a small number). This still doesn't solve the problem, however, because there must be a mechanism for the client to tell the server what root is appropriate. This optimization would require some small server modifications.<br />
<br />
The second option (TLS extension) is more difficult to deploy, because it requires more significant server modification to implement the extension. This is particularly problematic on Windows, due to Microsoft apparently only shipping new versions of SSL/TLS with new versions of Windows. However, it will work with both self-signed and preexisting certificates. Additionally, the short chain optimization would work as expected: the client specifies a trusted root and the server responds with a chain from that root.<br />
<br />
Currently the second option (TLS extension) is considered ultimately more flexible and usable.<br />
<br />
== Format of TLS Extension ==<br />
<br />
The "extension_data" field of the client hello extension currently consists of no data (i.e. it is empty and of zero length) and serves only as an indication that a DNSSEC chain has been requested. In the future this may be changed to allow for an optimization whereby the server can send less data.<br />
<br />
The "extension_data" field of the server hello extension contains "DNSSECChain" where:<br />
<br />
<nowiki><br />
struct {<br />
RR resource_record_chain<1..2^16-1><br />
} DNSSECChain;<br />
</nowiki><br />
<br />
Each resource record ("RR") in the chain is in wire format as described by the appropriate RFC (see for example [http://www.ietf.org/rfc/rfc1035.txt rfc 1035]). The contents of this chain are described [[Security/DNSSEC-TLS-details#DNSSEC Chains | above]].<br />
<br />
== Test Plans ==<br />
<br />
Current test plans include fuzzing the added attack surface (i.e. throwing data blobs at the validator) as well as deliberately crafted DNSSEC chains (e.g. ones with expired signatures, missing links, invalid links, etc.) Additionally, the library is being run through [http://klee.llvm.org/ KLEE] to check for memory safety errors.<br />
<br />
== nginx and openssl ==<br />
<br />
The webserver 'nginx' has been modified to send DNSSEC chains as a TLS extension. The details of how to set up such a modified server are [[Security/DNSSEC-TLS-nginx|here]].<br />
<br />
== Code ==<br />
<br />
Support code for this project can be found [http://hg.mozilla.org/users/dkeeler_mozilla.com/dnssec-tls/ here]. Files of interest might be [http://hg.mozilla.org/users/dkeeler_mozilla.com/dnssec-tls/file/tip/nss-dnssec-tls.patch nss-dnssec-tls.patch] (adds the dnssec tls handhake extension to nss), [http://hg.mozilla.org/users/dkeeler_mozilla.com/dnssec-tls/file/tip/dnssec.patch dnssec.patch] (ldns with some additions and modifications), and [http://hg.mozilla.org/users/dkeeler_mozilla.com/dnssec-tls/file/tip/authcertdnssec.patch authcertdnssec.patch] (calls the dnssec library to do verification). These patches are also necessary: [http://hg.mozilla.org/users/dkeeler_mozilla.com/dnssec-tls/file/tip/CERT_PKIXVerifyCert-selfsigned.patch CERT_PKIXVerifyCert-selfsigned.patch] [http://hg.mozilla.org/users/dkeeler_mozilla.com/dnssec-tls/file/tip/rsa-key-from-bytes.patch rsa-key-from-bytes.patch]</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=User:Dkeeler&diff=1206398User:Dkeeler2019-01-18T18:23:11Z<p>Dkeeler: Blanked the page</p>
<hr />
<div></div>Dkeelerhttps://wiki.mozilla.org/index.php?title=User:Dkeeler&diff=1206397User:Dkeeler2019-01-18T18:23:01Z<p>Dkeeler: </p>
<hr />
<div>*email: d[irc name]@mozilla.com</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=Modules/Core&diff=1200556Modules/Core2018-09-05T00:30:16Z<p>Dkeeler: update PSM module owner name</p>
<hr />
<div><noinclude><br />
'''Only module owners may edit this page.''' <br />
<br />
They may:<br />
<br />
* update any information about their module except the name of the owner<br />
* add or remove sub-modules<br />
* change the owner of a sub-module <br />
* add emeritus owners or peers<br />
<br />
Other changes, including changes of module owner or addition/removal of modules, must be agreed with the Module Ownership Module group, probably via a discussion in [https://www.mozilla.org/about/forums/#governance mozilla.governance].<br />
</noinclude><br />
{{Module<br />
|name=Accessibility<br />
|description=Support for platform accessibility APIs. Accessibility APIs are used by 3rd party software like screen readers, screen magnifiers, and voice dictation software, which need information about document content and UI controls, as well as important events like changes of focus.<br />
|owner=[mailto:surkov.alexander@gmail.com Alexander Surkov]<br />
|peers=[mailto:dbolter@mozilla.com David Bolter], [mailto:eitan@monotonous.org Eitan Isaacson], [mailto:jteh@mozilla.com James Teh], [mailto:mzehe@mozilla.com Marco Zehe], [mailto:yzenevich@mozilla.com Yura Zenevich]<br />
|ownersemeritus=[mailto:aaron@moonset.net. Aaron Leventhal]<br />
|peersemeritus=[mailto:tbsaunde+mozbugs@tbsaunde.org Trevor Saunders], [mailto:ginn.chen@oracle.com Ginn Chen], Evan Yan<br />
|group=dev-accessibility<br />
|source_dirs=accessible/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=Animation<br />
|description=Declarative animations: CSS animations, CSS transitions, Web Animations API, and off-main thread animations.<br />
|owner=[mailto:bbirtles@mozilla.com Brian Birtles] (:birtles)<br />
|peers=[mailto:hiro@mozilla.com Hiroyuki Ikezoe] (:hiro), [mailto:mwoodrow@mozilla.com Matt Woodrow] (:mattwoodrow)<br />
|group=dev-tech-layout<br />
|source_dirs=dom/animation; and animation-related and interpolation-related code in layout/style, gfx/layers, servo/components/style and servo/ports/gecko<br />
|components=Core::DOM::Animation, Core::CSS Parsing and Computation (for CSS animations/transitions related bugs)<br />
}}<br />
<br />
{{Module<br />
|name=Browser WebAPI<br />
|description=Web API for rendering apps, browser windows and widgets.<br />
|owner=[mailto:kchen@mozilla.com Kan-Ru Chen]<br />
|peers=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:fabrice@mozilla.com Fabrice Desré]<br />
|group=dev-webapi<br />
|source_dirs=dom/browser-element/<br />
|url=<br />
|components=Core::DOM<br />
}}<br />
<br />
{{Module<br />
|name=Build and Release Tools<br />
|description=Tools related to build and release automation and configuration of release builds.<br />
|owner=[mailto:nthomas@mozilla.com Nick Thomas]<br />
|peers=[mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:coop@mozilla.com Chris Cooper]<br />
|group=release-engineering<br />
|source_dirs=browser/config/mozconfigs/, mobile/android/config/mozconfigs/, xulrunner/config/mozconfigs/, b2g/config/, tools/update-packaging/<br />
|url=https://wiki.mozilla.org/ReleaseEngineering<br />
|components=Release Engineering::*<br />
}}<br />
<br />
{{Module<br />
|name=Build Config<br />
|description=The build system for Gecko and several mozilla.org hosted Gecko-based applications.<br />
|owner=[mailto:gps@mozilla.com Gregory Szorc] (:gps)<br />
|peers=[mailto:mh@glandium.org Mike Hommey] (:glandium), [mailto:mshal@mozilla.com Mike Shal] (:mshal), [mailto:ted@mielczarek.org Ted Mielczarek] (:ted), [mailto:cmanchester@mozilla.com Chris Manchester](:chmanchester), [mailto:nfroyd@mozilla.com Nathan Froyd] (:froydnj), [mailto:dmajor@mozilla.com David Major] (:dmajor), [mailto:rgiles@mozilla.com Ralph Giles] (:rillian)<br />
|ownersemeritus=Ted Mielczarek (2008-[https://blog.mozilla.org/ted/2013/03/07/gregory-szorc-is-now-the-build-config-module-owner/ 2013]), Benjamin Smedberg (???-[http://benjamin.smedbergs.us/blog/2008-04-30/more-changing-of-the-guard-ted-mielczarek/ 2008]), <br />
|group=dev-builds<br />
|source_dirs=build/, config/, python/mozbuild, tools/cross-commit, tools/cvs2hg-import.py, tools/cvsmgmt/, tools/elf-dynstr-gc/, tools/trees.pl, browser/config/mozconfigs/, mobile/config/mozconfigs/, xulrunner/config/mozconfigs/<br />
|url=http://www.mozilla.org/build/<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=Code Analysis and Debugging Tools<br />
|description=Tools for debugging Mozilla code or for analyzing speed, memory use, and other characteristics of it.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=<br />
|group=dev-performance<br />
|source_dirs=tools/codesighs/, tools/debug/, tools/dreftool/, tools/dumpdeps/, tools/footprint/, tools/jprof/, tools/leaky/, tools/memory/, tools/module-deps/, tools/performance/, tools/post_compile/, tools/preloader/, tools/rb/, tools/reorder/, tools/trace-malloc/, tools/uuiddeps/, <br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Content HTTP Headers<br />
|description=HTTP headers related to content, e.g. User-Agent, Content-Type, Accept. (Transport-related headers are the responsibility of the Necko module owner.)<br />
|owner=[mailto:gerv@mozilla.org Gervase Markham]<br />
|peers=[mailto:lmandel@mozilla.com Lawrence Mandel]<br />
|group=dev-platform<br />
|source_dirs= <br />
|url=https://developer.mozilla.org/en/Gecko_user_agent_string_reference<br />
|components=Core::Networking: HTTP<br />
}}<br />
<br />
{{Module<br />
|name=Content Security<br />
|description=Native content-based security features, including: Content Security Policy (CSP), Mixed Content Blocker (MCB), Subresource Integrity (SRI) and CORS.<br />
|owner=[mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]<br />
|peers=[mailto:francois@mozilla.com François Marier], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:tvyas@mozilla.com Tanvi Vyas], [mailto:dveditz@mozilla.com Dan Veditz], [mailto:mozilla@sidstamm.com Sid Stamm] <br />
|group=dev-security<br />
|source_dirs=dom/security<br />
|components=Core::DOM: Security<br />
}}<br />
<br />
{{Module<br />
|name=Cookies and Permissions<br />
|description=<br />
|owner=Monica Chew<br />
|peers=[mailto:josh@joshmatthews.com Josh Matthews], [mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dwitte@gmail.com Dan Witte], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)]<br />
|group=dev-tech-network<br />
|source_dirs=extensions/cookie/, netwerk/cookie/<br />
|url=<br />
|components=Core::Networking: Cookies<br />
}}<br />
{{Module<br />
|name=Cycle Collector<br />
|description=Code to break and collect objects within reference cycles<br />
|owner=[https://mozillians.org/en-US/u/mccr8/ Andrew McCreight]<br />
|peers=Peter Van der Beken, Olli Pettay, David Baron<br />
|source_dirs=xpcom/base/nsCycleCollector.* and some support headers<br />
|components=Core::XPCOM<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=C++/Rust usage, tools, and style<br />
|description=Aspects of C++ use such as language feature usage, standard library versions/usage, compiler/toolchain versions, formatting and naming style, and aspects of Rust use as needs arise<br />
|owner=[mailto:nfroyd@mozilla.com Nathan Froyd] (while Ehsan is away)<br />
|peers=[mailto:bballo@mozilla.com Botond Ballo], [mailto:glandium@mozilla.com Mike Hommey], [mailto:jwalden@mozilla.com Jeff Walden], [mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|source_dirs=non-third-party C++ and Rust code in the tree<br />
|components=Various components<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=docshell<br />
|description=<br />
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|peers=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:sawang@mozilla.com Samael Wang]<br />
|peersemeritus=[mailto:jstenback@gmail.com Johnny Stenback],[mailto:cbiesinger@gmail.com Christian Biesinger],[mailto:justin.lebar@gmail.com Justin Lebar]<br />
|group=dev-platform<br />
|source_dirs=docshell/, uriloader/<br />
|url=<br />
|components=Core::Document Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Document Object Model<br />
|description=<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:hsivonen@iki.fi Henri Sivonen], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:baku@mozilla.com Andrea Marchesini],<br />
[mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:bkelly@mozilla.com Ben Kelly], [mailto:kyle@nonpolynomial.com Kyle Machulis], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:nika@thelayzells.com Nika Layzell]<br />
|ownersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]<br />
|peersemeritus=[mailto:justin.lebar@gmail.com Justin Lebar], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:bent.mozilla@gmail.com Ben Turner], [mailto:mounir@lamouri.fr Mounir Lamouri (still active, but slower to respond than previously)], [mailto:me@kylehuey.com Kyle Huey], [mailto:wmccloskey@mozilla.com Bill McCloskey]<br />
|group=dev-tech-dom<br />
|source_dirs=dom/*, except directories covered by other modules<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM, Core::DOM: CSS Object Model, Core::DOM: Core & HTML<br />
}}<br />
<br />
{{Module<br />
|name=DOM File<br />
|description=DOM Blob, File and FileSystem APIs <br />
|owner=[mailto:amarchesini@Mozilla.com Andrea Marchesini]<br />
|peers=[mailto:olli@pettay.fi Olli Pettay]<br />
|group=dev-platform<br />
|source_dirs=dom/file, dom/filesystem<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM: File<br />
}}<br />
<br />
{{Module<br />
|name=Event Handling<br />
|description=DOM Events and Event Handling <br />
|owner=[mailto:olli@pettay.fi Olli Pettay], [mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:sshih@mozilla.com Stone Shih]<br />
|group=dev-platform<br />
|source_dirs=dom/events and event handling related code elsewhere <br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM: Events, Core::Event Handling<br />
}}<br />
<br />
{{Module<br />
|name=Web Workers<br />
|description=<br />
|owner=[mailto:baku@mozilla.com Andrea Marchesini]<br />
|peers=[mailto:mrbkap@mozilla.com Blake Kaplan], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey], [mailto:bkelly@mozilla.com Ben Kelly], [mailto:asuth@mozilla.com Andrew Sutherland]<br />
|ownersemeritus=[mailto:bent.mozilla@gmail.com Ben Turner]<br />
|group=dev-platform<br />
|source_dirs=dom/workers/<br />
|url=https://developer.mozilla.org/En/Using_web_workers<br />
|components=Core::DOM: Workers<br />
}}<br />
<br />
{{Module<br />
|name=IndexedDB<br />
|description=<br />
|owner=[mailto:jvarga@mozilla.com Jan Varga]<br />
|peers=[mailto:btseng@mozilla.com Bevis Tseng], [mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:baku@mozilla.com Andrea Marchesini]<br />
|ownersemeritus=[mailto:bent.mozilla@gmail.com Ben Turner]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey]<br />
|group=dev-platform<br />
|source_dirs=dom/indexedDB/<br />
|url=https://developer.mozilla.org/en/IndexedDB<br />
|components=Core::DOM: IndexedDB<br />
}}<br />
<br />
{{Module<br />
|name=Editor<br />
|description=<br />
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]<br />
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|group=dev-platform<br />
|source_dirs=editor/<br />
|url=http://www.mozilla.org/editor/<br />
|components=Core::Editor<br />
}}<br />
<br />
{{Module<br />
|name=Embedding<br />
|description=Gecko embedding APIs and frameworks<br />
|owner=[mailto:myk@mykzilla.org Myk Melez]<br />
|ownersemeritus=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:doug.turner@gmail.com Doug Turner]<br />
|peers=[mailto:bdahl@mozilla.com Brendan Dahl], [mailto:tbsaunde@tbsaunde.org Trevor Saunders]<br />
|peersemeritus=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jstenback@gmail.com Johnny Stenback]<br />
|group=dev-platform<br />
|source_dirs=embedding/<br />
|url=<br />
|components=Core::Embedding: APIs<br />
}}<br />
<br />
{{Module<br />
|name=Find As You Type<br />
|description=Find As You Type (formerly called Type Ahead Find) is a feature that allows quick web page navigation when you type a succession of characters in the body of the displayed page (not in an edit box of or drop down list). Currently seeks new owner.<br />
|owner=<br />
|peers=<br />
|group=dev-accessibility<br />
|source_dirs=extensions/typeaheadfind/<br />
|url=http://www.mozilla.org/access/type-ahead/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Gecko Profiler<br />
|description=Gecko's built-in profiler<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|peers=[mailto:nnethercote@mozilla.com Nicholas Nethercote], [mailto:jseward@mozilla.com Julian Seward] (LUL), [mailto:kvijayan@mozilla.com Kannan Vijayan] (JS integration), [mailto:shu@mozilla.com Shu-yu Guo] (JS integration), [mailto:tlee@mozilla.com Thinker Lee] (TaskTracer), [mailto:cyu@mozilla.com Cervantes Yu] (TaskTracer), [mailto:b56girard@gmail.com Benoit Girard].<br />
|group=dev-platform<br />
|source_dirs=tools/profiler/<br />
|url=https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler<br />
|components=Core::Gecko Profiler<br />
}}<br />
<br />
{{Module<br />
|name=Geolocation<br />
|description=Implementation of the Geolocation W3C Spec, location provider apis, and wifi scanning code.<br />
|owner=[mailto:josh@joshmatthews.net Josh Matthews], [mailto:kchen@mozilla.com Kan-Ru Chen]<br />
|ownersemeritus=[mailto:doug.turner@gmail.com Doug Turner], Garvan Keeley<br />
|peers=<br />
|group=dev-tech-dom<br />
|source_dirs=dom/geolocation, dom/system/, netwerk/wifi<br />
|url=https://developer.mozilla.org/En/Using_geolocation<br />
|components=Core::Geolocation<br />
}}<br />
<br />
{{Module<br />
|name=Global Key Bindings<br />
|description=Global hot keys in Mozilla for the browser, editor, mail-news and widgets. Does not include underlined menu accelerators and the like, as those are part of i18n.<br />
|owner=Aaron Leventhal<br />
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|group=dev-accessibility<br />
|source_dirs=dom/xbl/builtin/<br />
|url=http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html<br />
|components=Core::Keyboard: Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Graphics<br />
|description=Mozilla graphics API<br />
|owner=[mailto:jrmuizel@mozilla.com Jeff Muizelaar](Thebes, QCMS, YCbCr, Cairo/Pixman, Regions, OS X, Other)<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peers=[mailto:jdrew@mozilla.com Joe Drew], [mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:bas.schouten@live.nl Bas Schouten](Layers, Windows), [mailto:bjacob@mozilla.com Benoit Jacob](gfx/gl), [mailto:bgirard@mozilla.com Benoit Girard](Compositor, Performance), [mailto:ajuma.bugzilla@alijuma.com Ali Juma], [mailto:jgilbert@mozilla.com Jeff Gilbert](WebGL, ANGLE), [mailto:george@mozilla.com George Wright](Canvas2D), [mailto:mwoodrow@mozilla.com Matt Woodrow](Layers API), [mailto:jdaggett@mozilla.com John Daggett](text/fonts), [mailto:jfkthame@googlemail.com Jonathan Kew](text/fonts), [mailto:nsilva@mozilla.com Nicolas Silva](MozSurface), [mailto:ncameron@mozilla.com Nick Cameron], [mailto:sikeda@mozilla.com Sotaro Ikeda](B2G), [mailto:snorp@mozilla.com James Willcox](Android), [mailto:clord@mozilla.com Christopher Lord], [mailto:mstange@themasta.com Markus Stange](OS X), [mailto:lsalzman@mozilla.com Lee Salzman](Skia), [mailto:mchang@mozilla.com Mason Chang], [mailto:dvander@mozilla.com David Anderson], [mailto:rhunt@mozilla.com Ryan Hunt]<br />
|group=dev-platform<br />
|source_dirs=gfx/, dom/canvas/<br />
|url=https://wiki.mozilla.org/Platform/GFX https://wiki.mozilla.org/Gecko:Layers https://wiki.mozilla.org/Gecko:2DGraphicsSketch<br />
|components=Core::Graphics, Core::Graphics: Layers, Core::Graphics: Text, Core::GFX: Color Management, Core::Canvas: 2D, Core::Canvas: WebGL<br />
}}<br />
<br />
{{Module<br />
|name=APZ (Graphics submodule)<br />
|description=Asynchronous panning and zooming<br />
|owner=[mailto:kgupta@mozilla.com Kartikaya Gupta]<br />
|peers=[mailto:bballo@mozilla.com Botond Ballo], [mailto:tnikkel@mozilla.com Timothy Nikkel], [mailto:dvander@mozilla.com David Anderson], [mailto:mstange@mozilla.com Markus Stange]<br />
|group=dev-platform<br />
|source=gfx/layers/apz<br />
|url=https://wiki.mozilla.org/Platform/GFX/APZ<br />
|components=Core::Panning and Zooming<br />
}}<br />
<br />
{{Module<br />
|name=Moz2D (Graphics submodule)<br />
|description=Platform independent 2D graphics API<br />
|owner=[mailto:bschouten@mozilla.com Bas Schouten]<br />
|peers=[mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:gwright@mozilla.com George Wright], [mailto:jwatt@jwatt.org Jonathan Watt]<br />
|group=dev-platform<br />
|source=gfx/2d<br />
|url=https://wiki.mozilla.org/Platform/GFX/Moz2D<br />
|components=Core::Graphics<br />
}}<br />
<br />
{{Module<br />
|name=Legacy HTML Parser<br />
|description=<br />
|owner=[mailto:mrbkap@gmail.com Blake Kaplan]<br />
|peers=[mailto:dbaron@dbaron.org David Baron], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:rbs@maths.uq.edu.au rbs@maths.uq.edu.au]<br />
|peersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]<br />
|source_dirs=parser/htmlparser<br />
|url=http://www.mozilla.org/newlayout/doc/parser.html<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=HAL<br />
|description=Hardware Abstraction Layer<br />
|owner=[https://mozillians.org/u/dhylands/ Dave Hylands]<br />
|peers=[mailto:gsvelto@mozilla.com Gabriele Svelto]<br />
|group=dev-platform<br />
|source_dirs=hal/<br />
|components=Core::Hardware Abstraction Layer (HAL)<br />
}}<br />
<br />
{{Module<br />
|name=HTML Parser<br />
|description=The HTML Parser transforms HTML source code into a DOM. It conforms to the HTML specification, and is mostly translated automatically from Java to C++.<br />
|owner=[mailto:hsivonen@iki.fi Henri Sivonen]<br />
|peers=[mailto:wchen@mozilla.com William Chen]<br />
|group=dev-platform<br />
|source_dirs=parser/html<br />
|url=http://about.validator.nu/<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=I18N Library<br />
|description=<br />
|owner=[mailto:hsivonen@hsivonen.fi Henri Sivonen (encoding)], [mailto:jfkthame@gmail.com Jonathan Kew (except to encoding)]<br />
|peers=[mailto:VYV03354@nifty.ne.jp Masatoshi Kimura], [mailto:gandalf@aviary.pl Zibi Braniecki], [mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]<br />
|ownersemeritus=[mailto:jshin1987@gmail.com Jungshik Shin], [mailto:smontagu@smontagu.org Simon Montagu]<br />
|group=dev-i18n<br />
|source_dirs=intl/<br />
|url=http://mozilla.org/projects/intl/index.html<br />
|components=Core::Internationalization<br />
}}<br />
<br />
{{Module<br />
|name=ImageLib<br />
|description=<br />
|owner=[mailto:tnikkel@gmail.com Timothy Nikkel]<br />
|peers=[mailto:aosmond@mozilla.com Andrew Osmond], [mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:seth.bugzilla@blackhail.net Seth Fowler]<br />
|peersemeritus=[mailto:netzen@gmail.com Brian Bondy], [mailto:justin.lebar@gmail.com Justin Lebar]<br />
|group=dev-platform<br />
|source_dirs=media/libjpeg/, media/libpng/, image/, modules/zlib/<br />
|url=<br />
|components=Core::ImageLib<br />
}}<br />
<br />
{{Module<br />
|name=IPC<br />
|description=Native message-passing between threads and processes<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:jld@mozilla.com Jed Davis], [mailto:nfroyd@mozilla.com Nathan Froyd], [mailto:bkelly@mozilla.com Ben Kelly], [mailto:amccreight@mozilla.com Andrew McCreight]<br />
|peersemeritus=[mailto:wmccloskey@mozilla.com Bill McCloskey], [mailto:danderson@mozilla.com David Anderson], [mailto:kchen@mozilla.com Kan-Ru Chen], [mailto:btseng@mozilla.com Bevis Tseng]<br />
|group=dev-platform<br />
|source_dirs=ipc/glue/, ipc/ipdl/, ipc/chromium/<br />
|url=<br />
|components=Core::IPC}}<br />
<br />
{{Module<br />
|name=JavaScript<br />
|description=JavaScript engine (SpiderMonkey)<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:jdemooij@mozilla.com Jan de Mooij], [mailto:nnethercote@mozilla.com Nick Nethercote], [mailto:jwalden@mit.edu Jeff Walden], [mailto:hv1989@gmail.com Hannes Verschore], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:evilpies@gmail.com Tom Schuster], [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:till@tillschneidereit.net Till Schneidereit], [mailto:efaust@mozilla.com Eric Faust], [mailto:nfitzgerald@mozilla.com Nick Fitzgerald], [mailto:luke@mozilla.com Luke Wagner], [mailto:arai.unmht@gmail.com Tooru Fujisawa], [mailto:sunfish@mozilla.com Dan Gohman], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:nmatsakis@mozilla.com Niko Matsakis], [mailto:ejpbruel@mozilla.com Eddy Bruel], [mailto:danderson@mozilla.com David Anderson], [mailto:igor@mir2.org Igor Bukanov], [mailto:brendan@mozilla.org Brendan Eich], Andreas Gal<br />
|peersemeritus=[mailto:wmccloskey@mozilla.com Bill McCloskey]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src<br />
|url=http://www.mozilla.org/js/spidermonkey,<br />
http://developer.mozilla.org/en/docs/About_JavaScript<br />
|components=Core::JavaScript Engine<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript JIT<br />
|description=JavaScript engine's JIT compilers (IonMonkey, Baseline)<br />
|owner=[mailto:jdemooij@mozilla.com Jan de Mooij]<br />
|peers=[mailto:danderson@mozilla.com David Anderson], [mailto:bbouvier@mozilla.com Benjamin Bouvier], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:nicolas.b.pierron@mozilla.com Nicolas Pierron], [mailto:evilpies@gmail.com Tom Schuster], [mailto:sstangl@mozilla.com Sean Stangl], [mailto:hv1989@gmail.com Hannes Verschore], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:luke@mozilla.com Luke Wagner]<br />
|group=dev-tech-js-engine-internals<br />
|source_dirs=js/src/jit<br />
|url=http://www.mozilla.org/js/spidermonkey<br />
|components=Core::JavaScript Engine: JIT<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript Debugger Backend<br />
|description=JavaScript debugging hooks<br />
|owner=[mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:rginda@hacksrus.com Rob Ginda]<br />
|group=dev-apps-js-debugger<br />
|source_dirs=js/jsd/<br />
|url=http://www.mozilla.org/js/jsd<br />
|components=Other Applications::Venkman JS Debugger<br />
}}<br />
<br />
{{Module<br />
|name=jsat<br />
|description=Javascript screen reader that is used in Android and B2G<br />
|owner=[mailto:eitan@monotonous.org Eitan Isaacson]<br />
|peers=[mailto:yzenevich@mozilla.com Yura Zenevich]<br />
|group=dev-accessibility<br />
|source_dirs=accessible/jsat/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=js-ctypes<br />
|description=A foreign function interface which allows privileged JS code to interact with binary code without using XPCOM/XPConnect.<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src/ctypes/<br />
|url=https://wiki.mozilla.org/JSctypes<br />
|components=Core::js-ctypes<br />
}}<br />
<br />
{{Module<br />
|name=js-tests<br />
|description=JavaScript test suite<br />
|owner=[mailto:bclary@bclary.com Bob Clary]<br />
|peers=<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tests/<br />
|url=http://www.mozilla.org/js/tests/library.html<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Layout Engine<br />
|description=rendering tree construction, layout (reflow), etc.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:jfkthame@gmail.com Jonathan Kew], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:matt.woodrow@gmail.com Matt Woodrow], [mailto:xidorn+moz@upsuper.org Xidorn Quan]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/%, layout/base/, layout/build/, layout/doc/, layout/forms/, layout/generic/, layout/html/, layout/printing/, layout/tables/, layout/tools/<br />
|url=http://mozilla.org/newlayout/doc/ ,<br />
http://lxr.mozilla.org/mozilla/source/layout/doc/<br />
|components=Core::Layout, Core::Layout: Block and Inline, Core::Layout: Floats, Core::Layout: Form Controls, Core::Layout: HTML Frames, Core::Layout: Images, Core::Layout: Misc Code, Core::Layout: R & A Pos, Core::Layout: Tables, Core::Layout: Text, Core::Print Preview, Core::Printing: Output<br />
}}<br />
<br />
{{Module<br />
|name=libjar<br />
|description=The JAR handling code (protocol handler, stream implementation, and zipreader/zipwriter).<br />
|owner=[mailto:mwu@mozilla.com Michael Wu]<br />
|peers=[mailto:aklotz@mozilla.com Aaron Klotz]<br />
|group=dev-platform<br />
|source_dirs=modules/libjar<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=MathML<br />
|description=MathML is a low-level specification for describing mathematics which provides a foundation for the inclusion of mathematical expressions in Web pages.<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|group=dev-tech-mathml<br />
|source_dirs=layout/mathml/<br />
|url=http://www.mozilla.org/projects/mathml/<br />
|components=Core::MathML<br />
}}<br />
<br />
{{Module<br />
|name=Media Playback<br />
|description=HTML Media APIs, including Media Source Extensions and non-MSE video/audio element playback, and Encrypted Media Extensions. (WebRTC and WebAudio not included).<br />
|owner=[mailto:jyavenard@mozilla.com Jean-Yves Avenard]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:cpearce@mozilla.com Chris Pearce]<br />
|peers=[mailto:kinetik@flim.org Matthew Gregan], [mailto:bvandyk@mozilla.com Bryce Van Dyk], [mailto:jolin@mozilla.com John Lin], [mailto:alwu@mozilla.com Alastor Wu], [mailto:jwwang@mozilla.com JW Wang]<br />
|group=dev-media<br />
|source_dirs=dom/media, media/gmp-clearkey/, media/libcubeb/, media/libnestegg/, media/libogg/, media/libopus/, media/libstagefright/, media/libtheora/, media/libtremor/, media/libvorbis/, media/libvpx/, media/omx-plugin/, media/rlz/<br />
|url=<br />
|components=Core::Audio/Video<br />
}}<br />
<br />
{{Module<br />
|name=Media Transport<br />
|description=Pluggable transport for real-time media<br />
|owner=[mailto:ekr@rtfm.com Eric Rescorla]<br />
|peers=[mailto:bcampen@mozilla.com Byron Campen], [mailto:abr@mozilla.com Adam Roach], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]<br />
|group=dev-media<br />
|source_dirs=media/mtransport<br />
|url=<br />
|components=Core::WebRTC::Networking<br />
}}<br />
<br />
{{Module<br />
|name=Memory Allocator<br />
|description=Most things related to memory allocation in Gecko, including jemalloc, replace-malloc, DMD (dark matter detector), logalloc, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|peers=[mailto:n.nethercote@gmail.com Nicholas Nethercote], [mailto:erahm@mozilla.com Eric Rahm]<br />
|group=dev-platform<br />
|source_dirs=memory/<br />
|components=Core::DMD, Core::jemalloc<br />
}}<br />
<br />
{{Module<br />
|name=mfbt<br />
|description=mfbt is a collection of headers, macros, data structures, methods, and other functionality available for use and reuse throughout all Mozilla code (including SpiderMonkey and Gecko more broadly).<br />
|owner=[mailto:jwalden@mit.edu Jeff Walden]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd], [mailto:Ms2ger@gmail.com Ms2ger], [mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|group=dev-platform<br />
|source_dirs=mfbt/<br />
|url=<br />
|components=Core::MFBT<br />
}}<br />
<br />
{{Module<br />
|name=Mozglue<br />
|description=Glue library containing various low-level functionality, including a dynamic linker for Android, a DLL block list for Windows, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd] (mozglue/linker), [mailto:kgupta@mozilla.com Kartikaya Gupta] (mozglue/android), [mailto:nchen@mozilla.com Jim Chen] (mozglue/android), [mailto:aklotz@mozilla.com Aaron Klotz] (Windows Dll Blocklist/Interceptor)<br />
|group=dev-platform<br />
|source_dirs=mozglue/<br />
|components=Core::mozglue<br />
}}<br />
<br />
{{Module<br />
|name=mozilla-toplevel<br />
|description=The top level directory for the mozilla tree.<br />
|owner=[mailto:brendan@mozilla.org Brendan Eich]<br />
|peers=<br />
|group=<br />
|source_dirs=tools/README<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=MSCOM<br />
|description=Integration with Microsoft Distributed COM<br />
|owner=[mailto:aklotz@mozilla.com Aaron Klotz]<br />
|peers=[mailto:jteh@mozilla.com James Teh], [mailto:jmathies@mozilla.com Jim Mathies]<br />
|group=dev-platform<br />
|source_dirs=ipc/mscom/%<br />
|url=<br />
|components=Core::IPC: MSCOM}}<br />
<br />
{{Module<br />
|name=Necko<br />
|description=The Mozilla Networking Library<br />
|owner=[mailto:dd.mozilla@gmail.com Dragana Damjanovic]<br />
|peers= [mailto:jduell.mcbugs@gmail.com Jason Duell], [mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:mnovotny@mozilla.com Michal Novotny], [mailto:hurley@mozilla.com Nick Hurley], [mailto:dd.mozilla@gmail.com Dragana Damjanovic ],[mailto:valentin.gosu@gmail.com Valentin Gosu],[mailto:daniel@haxx.se Daniel Stenberg ]<br />
|ownsersemeritus=[mailto:mcmanus@ducksong.com Patrick McManus] |peersemeritus= [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sworkman@mozilla.com Steve Workman], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:schien@mozilla.com ShihChiang Chien]<br />
|group=dev-tech-network<br />
|source_dirs=netwerk/%, netwerk/base/, netwerk/build/, netwerk/cache/, netwerk/dns/, netwerk/locales/, netwerk/mime/, netwerk/protocol/, netwerk/resources/, netwerk/socket/, netwerk/streamconv/, netwerk/system/, netwerk/test/, netwerk/testserver/<br />
|url=http://www.mozilla.org/projects/netlib/, https://developer.mozilla.org/en/Necko<br />
|components=Core::Networking, Core::Networking: Cache, Core::Networking: Cookies, Core::Networking: FTP, Core::Networking: File, Core::Networking: HTTP, Core::Networking: JAR, Core::Networking: Websockets<br />
}}<br />
<br />
{{Module<br />
|name=NSPR<br />
|description=Netscape Portable Runtime<br />
|owner=[mailto:kaie@kuix.de Kai Engert]<br />
|peers=[mailto:wtc@google.com Wan-Teh Chang], [mailto:mh@glandium.org Mike Hommey]<br />
|group=dev-tech-nspr<br />
|source_dirs=nsprpub/<br />
|url=http://www.mozilla.org/projects/nspr/<br />
http://www.mozilla.org/projects/nspr/reference/html/<br />
http://www.mozilla.org/projects/nspr/release-notes/<br />
|components=NSPR<br />
}}<br />
<br />
{{Module<br />
|name=PDF<br />
|description=Rendering code to display documents encoded in the ISO 32000-1 `PDF' format.<br />
|owner=Chris Jones, Andreas Gal<br />
|peers=[mailto:aadib@mozilla.com Artur Adib], [mailto:bdahl@mozilla.com Brendan Dahl], [mailto:vnicolas@mozilla.com Vivien Nicolas]<br />
|group=dev-platform<br />
|source_dirs=media/pdf/<br />
|url=https://github.com/mozilla/pdf.js<br />
|components=Core::PDF<br />
}}<br />
<br />
{{Module<br />
|name=Plugins<br />
|description= NPAPI Plugin support.<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:joshmoz@gmail.com Josh Aas]<br />
|peersemeritus=[mailto:john@pointysoftware.net John Schoenick], [mailto:robert@ocallahan.org Robert O'Callahan], [mailto:jstenback@gmail.com Johnny Stenback], Benjamin Smedberg<br />
|group=<br />
|source_dirs=dom/plugins/, modules/plugin/<br />
|url=https://wiki.mozilla.org/Plugins<br />
|components=Core::Plug-ins<br />
}}<br />
<br />
{{Module<br />
|name=Preferences<br />
|description=Preference library<br />
|owner=[mailto:nnethercote@mozilla.com Nicholas Nethercote]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd], [mailto:felipe@mozilla.com Felipe Gomes], [mailto:glandium@mozilla.com Mike Hommey], [mailto:erahm@mozilla.com Eric Rahm]<br />
|group=dev-platform<br />
|source_dirs=modules/libpref/<br />
|url=<br />
|components=Core::Preferences: Backend<br />
}}<br />
<br />
{{Module<br />
|name=Private Browsing<br />
|description=Implementation of the Private Browsing mode, and the integration of other modules with Private Browsing APIs.<br />
|owner=[mailto:josh@joshmatthews.net Josh Matthews] (while Ehsan is away)<br />
|peers=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|group=dev-platform<br />
|source_dirs=Implementation and consumers of Private Browsing APIs in nsILoadContext, nsIPrivateBrowsingChannel, PrivateBrowsingUtils.jsm and the related glue code. <br />
|url=https://wiki.mozilla.org/Private_Browsing<br />
|components=Firefox::Private Browsing<br />
}}<br />
<br />
{{Module<br />
|name=Privilege Manager<br />
|description="caps"<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|peersemeritus=[mailto:brendan@mozilla.org Brendan Eich], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:dveditz@mozilla.com Dan Veditz]<br />
|group=dev-tech-dom<br />
|source_dirs=caps/<br />
|url=http://www.mozilla.org/projects/security/components/index.html<br />
|components=Core::Security: CAPS<br />
}}<br />
<br />
{{Module<br />
|name=Push Notifications<br />
|description=Push is a way for application developers to send messages to their web applications.<br />
|owners=<br />
|ownersemeritus=[mailto:doug.turner@gmail.com Doug Turner]<br />
|peers=[mailto:lina@mozilla.com Lina Cambridge], [mailto:martin.thomson@gmail.com Martin Thomson], [mailto:ddamjanovic@mozilla.com Dragana Damjanovic]<br />
|peersemeritus=[mailto:nsm.nikhil@gmail.com Nikhil Marathe]<br />
|group=<br />
|source_dirs=dom/push<br />
|url=<br />
|components=Core::DOM: Push Notifications<br />
}}<br />
<br />
{{Module<br />
|name=PyXPCOM<br />
|description=The Python to XPCOM bridge.<br />
|owner=Todd Whiteman<br />
|peers=[mailto:mhammond@skippinet.com.au Mark Hammond]<br />
|group=<br />
|source_dirs=extension/python<br />
|url=https://developer.mozilla.org/en/PyXPCOM<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=RDF<br />
|description=<br />
|owner=[mailto:axel@pike.org Axel Hecht]<br />
|peers=<br />
|group=dev-tech-rdf<br />
|source_dirs=rdf/<br />
|url=http://www.mozilla.org/rdf/doc/<br />
|components=Core::RDF<br />
}}<br />
<br />
{{Module<br />
|name=security<br />
|description=Crypto/PKI code, including NSS (Network Security Services) and JSS (NSS for Java)<br />
|owner=[mailto:rrelyea@redhat.com Bob Relyea], [mailto:martin.thomson@gmail.com Martin Thomson]<br />
|ownersemeritus=[mailto:ttaubert@mozilla.com Tim Taubert]<br />
|peers=[mailto:kaie@kuix.de Kai Engert], [mailto:ryan.sleevi@gmail.com Ryan Sleevi], [mailto:ekr@rtfm.com Eric Rescorla], [mailto:franziskuskiefer@gmail.com Franziskus Kiefer], [mailto:wtc@google.com Wan-Teh Chang], [mailto:dueno@redhat.com Daiki Ueno]<br />
|peersemeritus=[mailto:emaldona@redhat.com Elio Maldonado]<br />
|group=dev-tech-crypto<br />
|source_dirs=dbm/, security/coreconf/, security/dbm/, security/jss/, security/nss/, security/tinderbox/, security/tinderlight/<br />
|url=http://mozilla.org/projects/security/pki/<br />
|components=NSS, JSS, Core::Security, Core::Security: S/MIME<br />
}}<br />
<br />
{{Module<br />
|name=Security - Mozilla PSM Glue<br />
|description=Personal Security Manager<br />
|owner=[mailto:dkeeler@mozilla.com Dana Keeler]<br />
|ownersemeritus=[mailto:kaie@kuix.de Kai Engert (2001-2012)]<br />
|peers=[mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:cykesiopka.bmo@gmail.com Cykesiopka], [mailto:jc@mozilla.com J.C. Jones], [mailto:fkiefer@mozilla.com Franziskus Kiefer]<br />
|group=dev-tech-crypto<br />
|source_dirs=security/manager/<br />
|url=<br />
|components=Core::Security: PSM<br />
}}<br />
<br />
{{Module<br />
|name=Static analysis & rewriting for C++<br />
|description=Tools for checking C++ code looking for problems at compile time, plus tools for automated rewriting of C++ code.<br />
|owner=[mailto:nika@thelayzells.com Nika Layzell] (while Ehsan is away)<br />
|peers=[mailto:sfink@mozilla.com Steve Fink], [mailto:jrmuizel@mozilla.com Jeff Muizelaar], [mailto:birunthan@mohanathas.com Birunthan Mohanathas], [mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|group=dev-platform<br />
|source_dirs=build/clang-plugin, tools/rewriting among other out of tree tools<br />
|url=<br />
|components=Core::Rewriting & Analysis<br />
}}<br />
{{Module<br />
|name=storage<br />
|description=Storage APIs with a SQLite backend<br />
|owner=[mailto:mak77@bonardo.net Marco Bonardo]<br />
|peers=[mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:jvarga@mozilla.com Jan Varga]<br />
|group=dev-platform<br />
|source_dirs=db/sqlite3/, storage/<br />
|url=http://developer.mozilla.org/en/docs/Storage<br />
|components=Toolkit::Storage, Core::SQL<br />
}}<br />
<br />
{{Module<br />
|name=String<br />
|description=<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd], [mailto:erahm@mozilla.com Eric Rahm]<br />
|group=dev-tech-xpcom<br />
|source_dirs=string/, xpcom/string/<br />
|url=https://developer.mozilla.org/En/Mozilla_internal_string_guide<br />
|components=Core::String<br />
}}<br />
<br />
{{Module<br />
|name=Style System<br />
|description=CSS style sheet handling; style data computation<br />
|owner= [mailto:cam@mcc.id.au Cameron McCormack]<br />
|peers=[mailto:dbaron@dbaron.org David Baron], [mailto:emilio@crisal.io Emilio Cobos Álvarez], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:xidorn+moz@upsuper.org Xidorn Quan], [mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/style/<br />
|url=https://wiki.mozilla.org/Gecko:Overview#Style_System<br />
|components=Core::CSS Parsing and Computation<br />
}}<br />
<br />
{{Module<br />
|name=SVG<br />
|description=Scalable Vector Graphics<br />
|owner=[mailto:jwatt@jwatt.org Jonathan Watt]<br />
|peers=[mailto:longsonr@gmail.com Robert Longson], [mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:birtles@gmail.com Brian Birtles]<br />
|group=dev-tech-svg<br />
|source_dirs=dom/svg/, layout/svg/, dom/smil/<br />
|url=https://developer.mozilla.org/en-US/docs/Web/SVG<br />
|components=Core::SVG<br />
}}<br />
<br />
{{Module<br />
|name=Tamarin<br />
|description=VM for ActionScript and JavaScript<br />
|owner=Edwin Smith, [mailto:jodyer@adobe.com Jeff Dyer]<br />
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:stejohns@adobe.com Steven Johnson], [mailto:tierney@adobe.com Erik Tierney], [mailto:treilly@adobe.com Tom Reilly]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tamarin<br />
|url=http://www.mozilla.org/projects/tamarin/<br />
http://wiki.mozilla.org/tamarin/<br />
http://hg.mozilla.org/tamarin-central/<br />
http://hg.mozilla.org/tamarin-tracing/<br />
|components=Tamarin<br />
}}<br />
<br />
{{Module<br />
|name=Test Harness<br />
|description=In-tree test infrastructure and tools. Harnesses include, XPCShell, Mochitest (& Chrome), Reftest, JsREftest, Compiled Code Tests, Robocop, Mozmill, Marionette, Firefox UI Tests. Requests for new harnesses should go to Testing::General.<br />
|owner=[mailto:ted@mielczarek.org Ted Mielczarek]<br />
|peers=[mailto:dbaron@dbaron.org David Baron] (reftest), [mailto:jwalden@mit.edu Jeff Walden] (httpd.js, jsreftest), Rob Campbell (mochitest, mochitest chrome, marionette), [mailto:jmaher@mozilla.com Joel Maher] (reftest, mochitest, jsreftest), [mailto:ctalbert@mozilla.com Clint Talbert] (reftest, compiled code, mozmill), [mailto:geoffbrown@mozilla.com Geoff Brown] (robocop), [mailto:hskupin@mozilla.com Henrik Skupin] (Marionette, Firefox UI tests), [mailto:ato@mozilla.com Andreas Tolfsen] (marionette), [mailto:jgriffin Jonathan Griffin] (marionette), [mailto:dburns@mozilla.com David Burns] (marionette), [mailto:dminor@mozilla.com Dan Minor], [mailto:mjzffr@gmail.com Maja Frydrychowicz] (Marionette, Firefox UI tests), <br />
<br />
|group=dev-quality<br />
|source_dirs=/testing<br />
|url=http://wiki.mozilla.org/SoftwareTesting<br />
|components=Testing::General, Testing::Mochitest, Testing::Mochitest Chrome, Testing::Marionette, Testing::Mozmill, Testing::Reftest, Testing::XPCShell Harness, Testing::httpd.js<br />
}}<br />
<br />
{{Module<br />
|name=Testing Infrastructure<br />
|description=Testing tools and infrastructure for Mozilla projects, harnesses for automated tests, stand-alone test tools. Talos, Graph Server, Mozbase, Pulse, WOO, Bughunter, SUTAgent, Eideticker<br />
|owner=[mailto:jmaher@mozilla.com Joel Maher]<br />
|peers=[mailto:bclary@bclary.com Bob Clary], [mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:ccooper@deadsquid.com Chris Cooper], [mailto:ctalbert@mozilla.com Clint Talbert], [mailto:robert@roberthelmer.com Robert Helmer], [mailto:jmaher@mozilla.com Joel Maher], Rob Campbell, [mailto:wlach@mozilla.com William Lachance], [mailto:jeads@mozilla.com Jonathan Eads], [mailto:jgriffin Jonathan Griffin], [mailto:bmoss@mozilla.com Bob Moss], [mailto:mcote@mozilla.com Mark Côté]<br />
|group=dev-quality<br />
|source_dirs=testing/, tools/httptester/, tools/page-loader/, tools/test-harness/, tools/tests/, tools/testserver/, tools/testy/<br />
|url=http://wiki.mozilla.org/SoftwareTesting<br />
|components=Testing::Infrastructure<br />
}}<br />
<br />
{{Module<br />
|name=JS Marionette<br />
|description=NodeJS test harness, marionette client, and other utilities for running marionette tests (submodule of Test Infrastructure)<br />
|owner=[mailto:jlal@mozilla.com James Lal] <lightsofapollo>, [mailto:gaye@mozilla.com Gareth Aye] <gaye><br />
|peers=[mailto:aus@mozilla.com Ghislain "Aus" Lacroix] <auswerk><br />
|source_dirs=gaia/tests/jsmarionette<br />
|components=Testing::JSMarionette<br />
|group=dev-gaia<br />
}}<br />
<br />
{{Module<br />
|name=XPCShell Test Harness<br />
|description=The XPCShell Harness<br />
|owner=[mailto:ted@mielczarek.org Ted Mielczarek]<br />
|peers=[mailto:jmaher@mozilla.com Joel Maher]<br />
|source_dirs=testing/xpcshell<br />
|components=Testing::XPCShell Harness<br />
}}<br />
<br />
{{Module<br />
|name=Update Service<br />
|description=server code for Mozilla Update services (aus, addons, pfs)<br />
|owner=Mike Morgan<br />
|peers=[mailto:jscott@mozilla.com Justin Scott], [mailto:shaver@mozilla.org Mike Shaver], [mailto:wclouser@mozilla.com Will Clouser]<br />
|group=dev-amo<br />
|source_dirs=webtools/addons/, webtools/aus/, webtools/update/<br />
|url=http://wiki.mozilla.org/wiki/AMO<br />
|components=AUS::Administration, AUS::Systems<br />
}}<br />
<br />
{{Module<br />
|name=View System<br />
|description=The View Manager is responsible for handling "heavyweight" rendering (some clipping, compositing) and event handling tasks.<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron]<br />
|group=dev-tech-layout<br />
|source_dirs=view/<br />
|url=<br />
|components=Core::Layout: View Rendering<br />
}}<br />
<br />
{{Module<br />
|name=Web Audio<br />
|description=Support for the W3C Web Audio API specification.<br />
|owner=[mailto:padenot@mozilla.com Paul Adenot]<br />
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:karlt+@karlt.net Karl Tomlinson]<br />
|group=dev-platform<br />
|source_dirs=dom/media/webaudio<br />
|url=https://wiki.mozilla.org/Web_Audio_API<br />
|components=Core::Web Audio<br />
}}<br />
<br />
{{Module<br />
|name=Web Painting<br />
|description=painting, display lists, and layer construction<br />
|owner=[mailto:matt.woodrow@gmail.com Matt Woodrow]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dbaron@dbaron.org David Baron], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:mstange@themasta.com Markus Stange], [mailto:mmynttinen@mozilla.com Miko Mynttinen], [mailto:jnicol@mozilla.com Jamie Nicol]<br />
|group=dev-tech-layout<br />
|source_dirs= layout/painting, the display list and layer related methods on nsIFrame and its subclasses<br />
|url=http://mozilla.org/newlayout/doc/ ,<br />
http://lxr.mozilla.org/mozilla/source/layout/doc/<br />
|components=Core::Layout: Web Painting<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC<br />
|description=WebRTC is responsible for realtime audio and video communication, as well as related issues like low-level camera and microphone access<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:bcampen@mozilla.com Byron Campen] [mailto:abr@mozilla.com Adam Roach]<br />
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=netwerk/sctp (also see submodules "WebRTC Media" and "WebRTC Signaling")<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC, Core::WebRTC Networking<br />
}}<br />
<br />
{{Module<br />
|name=WebVR<br />
|description=Gecko's implementation of WebVR (Virtual Reality) functionality, including API, devices, graphics and integration<br />
|owner=[mailto:kgilbert@mozilla.com Kip Gilbert]<br />
|peers=[mailto:dmu@mozilla.com Daosheng Mu]<br />
|peersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|group=dev-platform<br />
|source_dirs=dom/vr, gfx/vr<br />
|url=https://mozvr.com/<br />
|components=Core::WebVR<br />
}}<br />
<br />
{{Module<br />
|name=Widget<br />
|description=<br />
|owner=[mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peersemeritus=[mailto:pavlov@pavlov.net Stuart Parmenter], <br />
|group=dev-platform<br />
|source_dirs=widget/, widget/xpwidgets/<br />
|url=<br />
|components=Core::Drag and Drop, Core::Widget, Core::Printing: Setup<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Android<br />
|description=The Android Port<br />
|owner=[mailto:blassey.bugs@lassey.us Brad Lassey]<br />
|peers=[mailto:jwillcox@mozilla.com James Willcox]<br />
|group=dev-platforms-mobile<br />
|source_dirs=widget/android/, embedding/android<br />
|url=<br />
|components=Core::Widget: Android<br />
}}<br />
<br />
{{Module<br />
|name=Widget - GTK<br />
|description=supported X widgetry and gfx<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|group=dev-platform<br />
|source_dirs=widget/gtk/, widget/gtk2/, widget/gtksuperwin/, widget/gtkxtbin/<br />
|url=http://www.mozilla.org/unix/, http://www.gtk.org, http://www.mozilla.org/ports/gtk/<br />
|components=Core::Widget: Gtk<br />
}}<br />
<br />
{{Module<br />
|name=Widget - OS X<br />
|description= Gecko's OS X compatibility layer.<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|peers=[mailto:joshmoz@gmail.com Josh Aas], [mailto:bgirard@mozilla.com Benoit Girard], [mailto:spohl@mozilla.com Stephen Pohl], [mailto:smichaud@pobox.com Steven Michaud]<br />
|group=dev-platform<br />
|source_dirs=widget/cocoa/<br />
|url=<br />
|components=Core::Widget: Cocoa<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Windows<br />
|description=Windows widgets and desktop integration<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook], [mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:jmathies@mozilla.com Jim Mathies]<br />
|peersemeritus=[mailto:blassey@mozilla.com Brad Lassey], [mailto:netzen@gmail.com Brian Bondy], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:doug.turner@gmail.com Doug Turner], [mailto:timeless@mozdev.org Josh 'timeless' Soref], [mailto:robarnold@cmu.edu Rob Arnold]<br />
|group=dev-platform<br />
|source_dirs=widget/windows/<br />
|url=<br />
|components=Core::Widget: Win32<br />
}}<br />
<br />
{{Module<br />
|name=XBL<br />
|description=eXtensible Binding Language<br />
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|peers=[mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:jonas@sicking.cc Jonas Sicking]<br />
|ownersemeritus=[mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-tech-xbl<br />
|source_dirs=dom/xbl/<br />
|url=http://www.mozilla.org/projects/xbl/<br />
|components=Core::XBL<br />
}}<br />
<br />
{{Module<br />
|name=XML<br />
|description=XML in Mozilla, including XML, XHTML, Namespaces in XML, Associating Style Sheets with XML Documents, XML Linking and XML Extras. XML-related things that are not covered by more specific projects.<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:erahm@mozilla.com Eric Rahm]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:jstenback@gmail.com Johnny Stenback]<br />
|group=dev-tech-xml<br />
|source_dirs=dom/xml/, extensions/xmlextras/, parser/expat/<br />
|url=http://www.mozilla.org/newlayout/xml/<br />
|components=Core::XML<br />
}}<br />
<br />
{{Module<br />
|name=XPApps<br />
|description=Cross-Platform Applications, mostly Navigator front end and application shell.<br />
|owner=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|peers=[mailto:dean_tessman@hotmail.com Dean Tessman], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-apps-seamonkey<br />
|source_dirs=xpfe/<br />
|url=http://www.mozilla.org/xpapps/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPCOM<br />
|description=The cross-platform object model and core data structures.<br />
|owner=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd]<br />
|peers=[mailto:erahm@mozilla.com Eric Rahm]<br />
|ownersemeritus=Benjamin Smedberg<br />
|peersemeritus=[https://mozillians.org/en-US/u/dougt/ Doug Turner]<br />
|group=dev-platform<br />
|source_dirs=startupcache/, xpcom/%, xpcom/base/, xpcom/build/, xpcom/components/, xpcom/ds/, xpcom/glue/, xpcom/proxy/, xpcom/sample/, xpcom/stub/, xpcom/tests/, xpcom/threads/, xpcom/tools/, xpcom/windbgdlg/<br />
|url=http://developer.mozilla.org/en/XPCOM<br />
|components=Core::XPCOM<br />
}}<br />
<br />
{{Module<br />
|name=XPConnect<br />
|description=Deep Magic<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:kmaglione@mozilla.com Kris Maglione], [mailto:nika@thelayzells.com Nika Layzell]<br />
|peersemeritus=[mailto:gal@uci.edu Andreas Gal], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:gkrizsanits@mozilla.com Gabor Krizsanits]<br />
|group=<br />
|source_dirs=js/xpconnect/<br />
|url=<br />
|components=Core::XPConnect<br />
}}<br />
<br />
{{Module<br />
|name=XPIDL<br />
|description=Cross-platform IDL compiler; produces .h C++ header files and .xpt runtime type description files from .idl interface description files.<br />
|owner=[mailto:me@kylehuey.com Kyle Huey]<br />
|peersemeritus=[mailto:shaver@mozilla.org Mike Shaver], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-tech-xpcom<br />
|source_dirs=xpcom/typelib/<br />
|url=http://www.mozilla.org/scriptable/xpidl<br />
http://www.mozilla.org/scriptable<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPInstall<br />
|description=<br />
|owner=[mailto:dveditz@mozilla.com Dan Veditz]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|group=dev-tech-xpinstall<br />
|source_dirs=xpinstall/<br />
|url=<br />
|components=Core::Installer: XPInstall Engine<br />
}}<br />
<br />
{{Module<br />
|name=XPToolkit<br />
|description=Cross-platform user interface toolkit<br />
|owner=<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:Jan.Varga@gmail.com Jan Varga]<br />
|group=dev-tech-xul<br />
|source_dirs=dom/xul/, layout/xul/<br />
|url=http://www.mozilla.org/xpfe/<br />
|components=Core::XP Toolkit/Widgets: Menus, Core::XP Toolkit/Widgets: XUL<br />
}}<br />
<br />
{{Module<br />
|name=XSLT Processor<br />
|description=XSLT transformations processor<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:axel@pike.org Axel Hecht], [mailto:erahm@mozilla.com Eric Rahm]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-tech-xslt<br />
|source_dirs=dom/xslt/<br />
|url=http://www.mozilla.org/projects/xslt/, http://www.w3.org/TR/xslt.html<br />
|components=Core::XSLT<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Windows <br />
|description=Sandboxing for the Windows platform <br />
|owner=[mailto:bobowencode@gmail.com Bob Owen] (:bobowen)<br />
|peers=[mailto:aklotz@mozilla.com Aaron Klotz] (:aklotz), [mailto:jimm@mozilla.com Jim Mathies] (:jimm), [mailto:davidp99@gmail.com David Parks] (:handyman)<br />
|ownersemeritus=[https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes]<br />
|peersemeritus=[mailto:netzen@gmail.com Brian Bondy]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/win <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - OSX <br />
|description=Sandboxing for the OSX platform <br />
|owner=[mailto:haftandilian@mozilla.com Haik Aftandilian]<br />
|peers=<br />
|group=dev-platform <br />
|source_dirs=security/sandbox/mac <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Linux<br />
|description=Sandboxing for the Linux platform<br />
|owner=[mailto:jld@mozilla.com Jed Davis]<br />
|peers=[mailto:gcp@mozilla.com Gian-Carlo Pascutto]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/linux<br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
===Submodules===<br />
{{Module<br />
|name=Build Config - Fennec<br />
|description=Submodule of the build config covering Fennec's build system in mobile/android.<br />
|owner=[mailto:nalexander@mozilla.com Nicholas Alexander]<br />
|peers=Same as Build Config<br />
|group=dev-builds<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=Build Config - Taskgraph<br />
|description=Support for task-graph generation in decision, action, and cron tasks, including configuration of all tasks including those for CI, nightlies, and releases; as well as Docker and VM images used to execute those tasks.<br />
|owner=[mailto:dustin@mozilla.com Dustin Mitchell]<br />
|peers=[mailto:ahal@mozilla.com Andrew Halberstadt], [mailto:aki@mozilla.com Aki Sasaki], [mailto:bstack@mozilla.com Brian Stack], [mailto:mh@glandium.org Mike Hommey], [mailto:gps@mozilla.com Gregory Szorc], [mailto:jmaher@mozilla.com Joel Maher], [mailto:callek@mozilla.com Justin Wood], [mailto:mozilla@hocat.ca Tom Prince]<br />
|components=Firefox Build System::Task Configuration<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC Media<br />
|description=Submodule of WebRTC responsible for access to media input devices (microphones, cameras, screen capture), as well as realtime audiovisual codecs and packetization.<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:jib@mozilla.com Jan-Ivar Bruaroey], [mailto:dminor@mozilla.com Dan Minor], [mailto:apehrson@mozilla.com Andreas Pehrson], <br />
|peersemeritus=[mailto:pkerr@mozilla.com Paul Kerr], [mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=/media/webrtc, /dom/media/webrtc, /dom/media/systemservices<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC (Audio/Video)<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC Signaling<br />
|description=Submodule of WebRTC responsible for implementation of PeerConnection API, WebRTC identity, and SDP/JSEP handling<br />
|owner=[mailto:bcampen@mozilla.com Byron Campen]<br />
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:abr@mozilla.com Adam Roach], [mailto:rjesup@mozilla.com Randell Jesup], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]<br />
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=/media/webrtc/signaling/<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC (Signaling)<br />
}}<br />
<br />
<br />
<noinclude><br />
<br />
===Unassigned Bugzilla Components===<br />
<br />
The following Bugzilla components in the Core project have not been assigned to a module (this list is not exhaustive):<br />
<br />
<pre><br />
Core::Find Backend<br />
Core::General<br />
Core::HTML: Form Submission<br />
Core::History: Global<br />
Core::Image Blocking<br />
Core::Localization<br />
Core::Networking: Domain Lists<br />
Core::Selection<br />
Core::Serializers<br />
Core::Spelling checker<br />
Core::X-remote<br />
Core::XUL<br />
</pre><br />
</noinclude></div>Dkeelerhttps://wiki.mozilla.org/index.php?title=Modules/Core&diff=1195945Modules/Core2018-06-21T23:34:54Z<p>Dkeeler: add J.C. and Franziskus to PSM peer list</p>
<hr />
<div><noinclude><br />
'''Only module owners may edit this page.''' <br />
<br />
They may:<br />
<br />
* update any information about their module except the name of the owner<br />
* add or remove sub-modules<br />
* change the owner of a sub-module <br />
* add emeritus owners or peers<br />
<br />
Other changes, including changes of module owner or addition/removal of modules, must be agreed with the Module Ownership Module group, probably via a discussion in [https://www.mozilla.org/about/forums/#governance mozilla.governance].<br />
</noinclude><br />
{{Module<br />
|name=Accessibility<br />
|description=Support for platform accessibility APIs. Accessibility APIs are used by 3rd party software like screen readers, screen magnifiers, and voice dictation software, which need information about document content and UI controls, as well as important events like changes of focus.<br />
|owner=[mailto:surkov.alexander@gmail.com Alexander Surkov]<br />
|peers=[mailto:dbolter@mozilla.com David Bolter], [mailto:eitan@monotonous.org Eitan Isaacson], [mailto:jteh@mozilla.com James Teh], [mailto:mzehe@mozilla.com Marco Zehe], [mailto:yzenevich@mozilla.com Yura Zenevich]<br />
|ownersemeritus=[mailto:aaron@moonset.net. Aaron Leventhal]<br />
|peersemeritus=[mailto:tbsaunde+mozbugs@tbsaunde.org Trevor Saunders], [mailto:ginn.chen@oracle.com Ginn Chen], Evan Yan<br />
|group=dev-accessibility<br />
|source_dirs=accessible/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=Animation<br />
|description=Declarative animations: CSS animations, CSS transitions, Web Animations API, and off-main thread animations.<br />
|owner=[mailto:bbirtles@mozilla.com Brian Birtles] (:birtles)<br />
|peers=[mailto:hiro@mozilla.com Hiroyuki Ikezoe] (:hiro), [mailto:mwoodrow@mozilla.com Matt Woodrow] (:mattwoodrow)<br />
|group=dev-tech-layout<br />
|source_dirs=dom/animation; and animation-related and interpolation-related code in layout/style, gfx/layers, servo/components/style and servo/ports/gecko<br />
|components=Core::DOM::Animation, Core::CSS Parsing and Computation (for CSS animations/transitions related bugs)<br />
}}<br />
<br />
{{Module<br />
|name=Browser WebAPI<br />
|description=Web API for rendering apps, browser windows and widgets.<br />
|owner=[mailto:kchen@mozilla.com Kan-Ru Chen]<br />
|peers=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:fabrice@mozilla.com Fabrice Desré]<br />
|group=dev-webapi<br />
|source_dirs=dom/browser-element/<br />
|url=<br />
|components=Core::DOM<br />
}}<br />
<br />
{{Module<br />
|name=Build and Release Tools<br />
|description=Tools related to build and release automation and configuration of release builds.<br />
|owner=[mailto:nthomas@mozilla.com Nick Thomas]<br />
|peers=[mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:coop@mozilla.com Chris Cooper]<br />
|group=release-engineering<br />
|source_dirs=browser/config/mozconfigs/, mobile/android/config/mozconfigs/, xulrunner/config/mozconfigs/, b2g/config/, tools/update-packaging/<br />
|url=https://wiki.mozilla.org/ReleaseEngineering<br />
|components=Release Engineering::*<br />
}}<br />
<br />
{{Module<br />
|name=Build Config<br />
|description=The build system for Gecko and several mozilla.org hosted Gecko-based applications.<br />
|owner=[mailto:gps@mozilla.com Gregory Szorc] (:gps)<br />
|peers=[mailto:mh@glandium.org Mike Hommey] (:glandium), [mailto:mshal@mozilla.com Mike Shal] (:mshal), [mailto:ted@mielczarek.org Ted Mielczarek] (:ted), [mailto:cmanchester@mozilla.com Chris Manchester](:chmanchester), [mailto:nfroyd@mozilla.com Nathan Froyd] (:froydnj), [mailto:dmajor@mozilla.com David Major] (:dmajor), [mailto:rgiles@mozilla.com Ralph Giles] (:rillian)<br />
|ownersemeritus=Ted Mielczarek (2008-[https://blog.mozilla.org/ted/2013/03/07/gregory-szorc-is-now-the-build-config-module-owner/ 2013]), Benjamin Smedberg (???-[http://benjamin.smedbergs.us/blog/2008-04-30/more-changing-of-the-guard-ted-mielczarek/ 2008]), <br />
|group=dev-builds<br />
|source_dirs=build/, config/, python/mozbuild, tools/cross-commit, tools/cvs2hg-import.py, tools/cvsmgmt/, tools/elf-dynstr-gc/, tools/trees.pl, browser/config/mozconfigs/, mobile/config/mozconfigs/, xulrunner/config/mozconfigs/<br />
|url=http://www.mozilla.org/build/<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=Code Analysis and Debugging Tools<br />
|description=Tools for debugging Mozilla code or for analyzing speed, memory use, and other characteristics of it.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=<br />
|group=dev-performance<br />
|source_dirs=tools/codesighs/, tools/debug/, tools/dreftool/, tools/dumpdeps/, tools/footprint/, tools/jprof/, tools/leaky/, tools/memory/, tools/module-deps/, tools/performance/, tools/post_compile/, tools/preloader/, tools/rb/, tools/reorder/, tools/trace-malloc/, tools/uuiddeps/, <br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Content HTTP Headers<br />
|description=HTTP headers related to content, e.g. User-Agent, Content-Type, Accept. (Transport-related headers are the responsibility of the Necko module owner.)<br />
|owner=[mailto:gerv@mozilla.org Gervase Markham]<br />
|peers=[mailto:lmandel@mozilla.com Lawrence Mandel]<br />
|group=dev-platform<br />
|source_dirs= <br />
|url=https://developer.mozilla.org/en/Gecko_user_agent_string_reference<br />
|components=Core::Networking: HTTP<br />
}}<br />
<br />
{{Module<br />
|name=Content Security<br />
|description=Native content-based security features, including: Content Security Policy (CSP), Mixed Content Blocker (MCB), Subresource Integrity (SRI) and CORS.<br />
|owner=[mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]<br />
|peers=[mailto:francois@mozilla.com François Marier], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:tvyas@mozilla.com Tanvi Vyas], [mailto:dveditz@mozilla.com Dan Veditz], [mailto:mozilla@sidstamm.com Sid Stamm] <br />
|group=dev-security<br />
|source_dirs=dom/security<br />
|components=Core::DOM: Security<br />
}}<br />
<br />
{{Module<br />
|name=Cookies and Permissions<br />
|description=<br />
|owner=Monica Chew<br />
|peers=[mailto:josh@joshmatthews.com Josh Matthews], [mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dwitte@gmail.com Dan Witte], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)]<br />
|group=dev-tech-network<br />
|source_dirs=extensions/cookie/, netwerk/cookie/<br />
|url=<br />
|components=Core::Networking: Cookies<br />
}}<br />
{{Module<br />
|name=Cycle Collector<br />
|description=Code to break and collect objects within reference cycles<br />
|owner=[https://mozillians.org/en-US/u/mccr8/ Andrew McCreight]<br />
|peers=Peter Van der Beken, Olli Pettay, David Baron<br />
|source_dirs=xpcom/base/nsCycleCollector.* and some support headers<br />
|components=Core::XPCOM<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=C++/Rust usage, tools, and style<br />
|description=Aspects of C++ use such as language feature usage, standard library versions/usage, compiler/toolchain versions, formatting and naming style, and aspects of Rust use as needs arise<br />
|owner=[mailto:nfroyd@mozilla.com Nathan Froyd] (while Ehsan is away)<br />
|peers=[mailto:bballo@mozilla.com Botond Ballo], [mailto:glandium@mozilla.com Mike Hommey], [mailto:jwalden@mozilla.com Jeff Walden], [mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|source_dirs=non-third-party C++ and Rust code in the tree<br />
|components=Various components<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=docshell<br />
|description=<br />
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|peers=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:sawang@mozilla.com Samael Wang]<br />
|peersemeritus=[mailto:jstenback@gmail.com Johnny Stenback],[mailto:cbiesinger@gmail.com Christian Biesinger],[mailto:justin.lebar@gmail.com Justin Lebar]<br />
|group=dev-platform<br />
|source_dirs=docshell/, uriloader/<br />
|url=<br />
|components=Core::Document Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Document Object Model<br />
|description=<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:hsivonen@iki.fi Henri Sivonen], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:baku@mozilla.com Andrea Marchesini],<br />
[mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:bkelly@mozilla.com Ben Kelly], [mailto:kyle@nonpolynomial.com Kyle Machulis], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:nika@thelayzells.com Nika Layzell]<br />
|ownersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]<br />
|peersemeritus=[mailto:justin.lebar@gmail.com Justin Lebar], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:bent.mozilla@gmail.com Ben Turner], [mailto:mounir@lamouri.fr Mounir Lamouri (still active, but slower to respond than previously)], [mailto:me@kylehuey.com Kyle Huey], [mailto:wmccloskey@mozilla.com Bill McCloskey]<br />
|group=dev-tech-dom<br />
|source_dirs=dom/*, except directories covered by other modules<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM, Core::DOM: CSS Object Model, Core::DOM: Core & HTML<br />
}}<br />
<br />
{{Module<br />
|name=DOM File<br />
|description=DOM Blob, File and FileSystem APIs <br />
|owner=[mailto:amarchesini@Mozilla.com Andrea Marchesini]<br />
|peers=[mailto:olli@pettay.fi Olli Pettay]<br />
|group=dev-platform<br />
|source_dirs=dom/file, dom/filesystem<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM: File<br />
}}<br />
<br />
{{Module<br />
|name=Event Handling<br />
|description=DOM Events and Event Handling <br />
|owner=[mailto:olli@pettay.fi Olli Pettay], [mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:sshih@mozilla.com Stone Shih]<br />
|group=dev-platform<br />
|source_dirs=dom/events and event handling related code elsewhere <br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM: Events, Core::Event Handling<br />
}}<br />
<br />
{{Module<br />
|name=Web Workers<br />
|description=<br />
|owner=[mailto:baku@mozilla.com Andrea Marchesini]<br />
|peers=[mailto:mrbkap@mozilla.com Blake Kaplan], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey], [mailto:bkelly@mozilla.com Ben Kelly]<br />
|ownersemeritus=[mailto:bent.mozilla@gmail.com Ben Turner]<br />
|group=dev-platform<br />
|source_dirs=dom/workers/<br />
|url=https://developer.mozilla.org/En/Using_web_workers<br />
|components=Core::DOM: Workers<br />
}}<br />
<br />
{{Module<br />
|name=IndexedDB<br />
|description=<br />
|owner=[mailto:jvarga@mozilla.com Jan Varga]<br />
|peers=[mailto:btseng@mozilla.com Bevis Tseng], [mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:baku@mozilla.com Andrea Marchesini]<br />
|ownersemeritus=[mailto:bent.mozilla@gmail.com Ben Turner]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey]<br />
|group=dev-platform<br />
|source_dirs=dom/indexedDB/<br />
|url=https://developer.mozilla.org/en/IndexedDB<br />
|components=Core::DOM: IndexedDB<br />
}}<br />
<br />
{{Module<br />
|name=Editor<br />
|description=<br />
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]<br />
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|group=dev-platform<br />
|source_dirs=editor/<br />
|url=http://www.mozilla.org/editor/<br />
|components=Core::Editor<br />
}}<br />
<br />
{{Module<br />
|name=Embedding<br />
|description=Gecko embedding APIs and frameworks<br />
|owner=[mailto:myk@mykzilla.org Myk Melez]<br />
|ownersemeritus=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:doug.turner@gmail.com Doug Turner]<br />
|peers=[mailto:bdahl@mozilla.com Brendan Dahl], [mailto:tbsaunde@tbsaunde.org Trevor Saunders]<br />
|peersemeritus=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jstenback@gmail.com Johnny Stenback]<br />
|group=dev-platform<br />
|source_dirs=embedding/<br />
|url=<br />
|components=Core::Embedding: APIs<br />
}}<br />
<br />
{{Module<br />
|name=Find As You Type<br />
|description=Find As You Type (formerly called Type Ahead Find) is a feature that allows quick web page navigation when you type a succession of characters in the body of the displayed page (not in an edit box of or drop down list). Currently seeks new owner.<br />
|owner=<br />
|peers=<br />
|group=dev-accessibility<br />
|source_dirs=extensions/typeaheadfind/<br />
|url=http://www.mozilla.org/access/type-ahead/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Gecko Profiler<br />
|description=Gecko's built-in profiler<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|peers=[mailto:nnethercote@mozilla.com Nicholas Nethercote], [mailto:jseward@mozilla.com Julian Seward] (LUL), [mailto:kvijayan@mozilla.com Kannan Vijayan] (JS integration), [mailto:shu@mozilla.com Shu-yu Guo] (JS integration), [mailto:tlee@mozilla.com Thinker Lee] (TaskTracer), [mailto:cyu@mozilla.com Cervantes Yu] (TaskTracer), [mailto:b56girard@gmail.com Benoit Girard].<br />
|group=dev-platform<br />
|source_dirs=tools/profiler/<br />
|url=https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler<br />
|components=Core::Gecko Profiler<br />
}}<br />
<br />
{{Module<br />
|name=Geolocation<br />
|description=Implementation of the Geolocation W3C Spec, location provider apis, and wifi scanning code.<br />
|owner=[mailto:josh@joshmatthews.net Josh Matthews], [mailto:kchen@mozilla.com Kan-Ru Chen]<br />
|ownersemeritus=[mailto:doug.turner@gmail.com Doug Turner], Garvan Keeley<br />
|peers=<br />
|group=dev-tech-dom<br />
|source_dirs=dom/geolocation, dom/system/, netwerk/wifi<br />
|url=https://developer.mozilla.org/En/Using_geolocation<br />
|components=Core::Geolocation<br />
}}<br />
<br />
{{Module<br />
|name=Global Key Bindings<br />
|description=Global hot keys in Mozilla for the browser, editor, mail-news and widgets. Does not include underlined menu accelerators and the like, as those are part of i18n.<br />
|owner=Aaron Leventhal<br />
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|group=dev-accessibility<br />
|source_dirs=dom/xbl/builtin/<br />
|url=http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html<br />
|components=Core::Keyboard: Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Graphics<br />
|description=Mozilla graphics API<br />
|owner=[mailto:jrmuizel@mozilla.com Jeff Muizelaar](Thebes, QCMS, YCbCr, Cairo/Pixman, Regions, OS X, Other)<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peers=[mailto:jdrew@mozilla.com Joe Drew], [mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:bas.schouten@live.nl Bas Schouten](Layers, Windows), [mailto:bjacob@mozilla.com Benoit Jacob](gfx/gl), [mailto:bgirard@mozilla.com Benoit Girard](Compositor, Performance), [mailto:ajuma.bugzilla@alijuma.com Ali Juma], [mailto:jgilbert@mozilla.com Jeff Gilbert](WebGL, ANGLE), [mailto:george@mozilla.com George Wright](Canvas2D), [mailto:mwoodrow@mozilla.com Matt Woodrow](Layers API), [mailto:jdaggett@mozilla.com John Daggett](text/fonts), [mailto:jfkthame@googlemail.com Jonathan Kew](text/fonts), [mailto:nsilva@mozilla.com Nicolas Silva](MozSurface), [mailto:ncameron@mozilla.com Nick Cameron], [mailto:sikeda@mozilla.com Sotaro Ikeda](B2G), [mailto:snorp@mozilla.com James Willcox](Android), [mailto:clord@mozilla.com Christopher Lord], [mailto:mstange@themasta.com Markus Stange](OS X), [mailto:lsalzman@mozilla.com Lee Salzman](Skia), [mailto:mchang@mozilla.com Mason Chang], [mailto:dvander@mozilla.com David Anderson]<br />
|group=dev-platform<br />
|source_dirs=gfx/, dom/canvas/<br />
|url=https://wiki.mozilla.org/Platform/GFX https://wiki.mozilla.org/Gecko:Layers https://wiki.mozilla.org/Gecko:2DGraphicsSketch<br />
|components=Core::Graphics, Core::Graphics: Layers, Core::Graphics: Text, Core::GFX: Color Management, Core::Canvas: 2D, Core::Canvas: WebGL<br />
}}<br />
<br />
{{Module<br />
|name=APZ (Graphics submodule)<br />
|description=Asynchronous panning and zooming<br />
|owner=[mailto:kgupta@mozilla.com Kartikaya Gupta]<br />
|peers=[mailto:bballo@mozilla.com Botond Ballo], [mailto:tnikkel@mozilla.com Timothy Nikkel], [mailto:dvander@mozilla.com David Anderson], [mailto:mstange@mozilla.com Markus Stange]<br />
|group=dev-platform<br />
|source=gfx/layers/apz<br />
|url=https://wiki.mozilla.org/Platform/GFX/APZ<br />
|components=Core::Panning and Zooming<br />
}}<br />
<br />
{{Module<br />
|name=Moz2D (Graphics submodule)<br />
|description=Platform independent 2D graphics API<br />
|owner=[mailto:bschouten@mozilla.com Bas Schouten]<br />
|peers=[mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:gwright@mozilla.com George Wright], [mailto:jwatt@jwatt.org Jonathan Watt]<br />
|group=dev-platform<br />
|source=gfx/2d<br />
|url=https://wiki.mozilla.org/Platform/GFX/Moz2D<br />
|components=Core::Graphics<br />
}}<br />
<br />
{{Module<br />
|name=Legacy HTML Parser<br />
|description=<br />
|owner=[mailto:mrbkap@gmail.com Blake Kaplan]<br />
|peers=[mailto:dbaron@dbaron.org David Baron], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:rbs@maths.uq.edu.au rbs@maths.uq.edu.au]<br />
|peersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]<br />
|source_dirs=parser/htmlparser<br />
|url=http://www.mozilla.org/newlayout/doc/parser.html<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=HAL<br />
|description=Hardware Abstraction Layer<br />
|owner=[https://mozillians.org/u/dhylands/ Dave Hylands]<br />
|peers=[mailto:gsvelto@mozilla.com Gabriele Svelto]<br />
|group=dev-platform<br />
|source_dirs=hal/<br />
|components=Core::Hardware Abstraction Layer (HAL)<br />
}}<br />
<br />
{{Module<br />
|name=HTML Parser<br />
|description=The HTML Parser transforms HTML source code into a DOM. It conforms to the HTML specification, and is mostly translated automatically from Java to C++.<br />
|owner=[mailto:hsivonen@iki.fi Henri Sivonen]<br />
|peers=[mailto:wchen@mozilla.com William Chen]<br />
|group=dev-platform<br />
|source_dirs=parser/html<br />
|url=http://about.validator.nu/<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=I18N Library<br />
|description=<br />
|owner=[mailto:hsivonen@hsivonen.fi Henri Sivonen (encoding)], [mailto:jfkthame@gmail.com Jonathan Kew (except to encoding)]<br />
|peers=[mailto:VYV03354@nifty.ne.jp Masatoshi Kimura], [mailto:gandalf@aviary.pl Zibi Braniecki], [mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]<br />
|ownersemeritus=[mailto:jshin1987@gmail.com Jungshik Shin], [mailto:smontagu@smontagu.org Simon Montagu]<br />
|group=dev-i18n<br />
|source_dirs=intl/<br />
|url=http://mozilla.org/projects/intl/index.html<br />
|components=Core::Internationalization<br />
}}<br />
<br />
{{Module<br />
|name=ImageLib<br />
|description=<br />
|owner=[mailto:tnikkel@gmail.com Timothy Nikkel]<br />
|peers=[mailto:aosmond@mozilla.com Andrew Osmond], [mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:seth.bugzilla@blackhail.net Seth Fowler]<br />
|peersemeritus=[mailto:netzen@gmail.com Brian Bondy], [mailto:justin.lebar@gmail.com Justin Lebar]<br />
|group=dev-platform<br />
|source_dirs=media/libjpeg/, media/libpng/, image/, modules/zlib/<br />
|url=<br />
|components=Core::ImageLib<br />
}}<br />
<br />
{{Module<br />
|name=IPC<br />
|description=Native message-passing between threads and processes<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:jld@mozilla.com Jed Davis], [mailto:nfroyd@mozilla.com Nathan Froyd], [mailto:bkelly@mozilla.com Ben Kelly], [mailto:amccreight@mozilla.com Andrew McCreight]<br />
|peersemeritus=[mailto:wmccloskey@mozilla.com Bill McCloskey], [mailto:danderson@mozilla.com David Anderson], [mailto:kchen@mozilla.com Kan-Ru Chen], [mailto:btseng@mozilla.com Bevis Tseng]<br />
|group=dev-platform<br />
|source_dirs=ipc/glue/, ipc/ipdl/, ipc/chromium/<br />
|url=<br />
|components=Core::IPC}}<br />
<br />
{{Module<br />
|name=JavaScript<br />
|description=JavaScript engine (SpiderMonkey)<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:jdemooij@mozilla.com Jan de Mooij], [mailto:nnethercote@mozilla.com Nick Nethercote], [mailto:jwalden@mit.edu Jeff Walden], [mailto:hv1989@gmail.com Hannes Verschore], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:evilpies@gmail.com Tom Schuster], [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:till@tillschneidereit.net Till Schneidereit], [mailto:efaust@mozilla.com Eric Faust], [mailto:nfitzgerald@mozilla.com Nick Fitzgerald], [mailto:luke@mozilla.com Luke Wagner], [mailto:arai.unmht@gmail.com Tooru Fujisawa], [mailto:sunfish@mozilla.com Dan Gohman], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:nmatsakis@mozilla.com Niko Matsakis], [mailto:ejpbruel@mozilla.com Eddy Bruel], [mailto:danderson@mozilla.com David Anderson], [mailto:igor@mir2.org Igor Bukanov], [mailto:brendan@mozilla.org Brendan Eich], Andreas Gal<br />
|peersemeritus=[mailto:wmccloskey@mozilla.com Bill McCloskey]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src<br />
|url=http://www.mozilla.org/js/spidermonkey,<br />
http://developer.mozilla.org/en/docs/About_JavaScript<br />
|components=Core::JavaScript Engine<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript JIT<br />
|description=JavaScript engine's JIT compilers (IonMonkey, Baseline)<br />
|owner=[mailto:jdemooij@mozilla.com Jan de Mooij]<br />
|peers=[mailto:danderson@mozilla.com David Anderson], [mailto:bbouvier@mozilla.com Benjamin Bouvier], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:nicolas.b.pierron@mozilla.com Nicolas Pierron], [mailto:evilpies@gmail.com Tom Schuster], [mailto:sstangl@mozilla.com Sean Stangl], [mailto:hv1989@gmail.com Hannes Verschore], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:luke@mozilla.com Luke Wagner]<br />
|group=dev-tech-js-engine-internals<br />
|source_dirs=js/src/jit<br />
|url=http://www.mozilla.org/js/spidermonkey<br />
|components=Core::JavaScript Engine: JIT<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript Debugger Backend<br />
|description=JavaScript debugging hooks<br />
|owner=[mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:rginda@hacksrus.com Rob Ginda]<br />
|group=dev-apps-js-debugger<br />
|source_dirs=js/jsd/<br />
|url=http://www.mozilla.org/js/jsd<br />
|components=Other Applications::Venkman JS Debugger<br />
}}<br />
<br />
{{Module<br />
|name=jsat<br />
|description=Javascript screen reader that is used in Android and B2G<br />
|owner=[mailto:eitan@monotonous.org Eitan Isaacson]<br />
|peers=[mailto:yzenevich@mozilla.com Yura Zenevich]<br />
|group=dev-accessibility<br />
|source_dirs=accessible/jsat/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=js-ctypes<br />
|description=A foreign function interface which allows privileged JS code to interact with binary code without using XPCOM/XPConnect.<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src/ctypes/<br />
|url=https://wiki.mozilla.org/JSctypes<br />
|components=Core::js-ctypes<br />
}}<br />
<br />
{{Module<br />
|name=js-tests<br />
|description=JavaScript test suite<br />
|owner=[mailto:bclary@bclary.com Bob Clary]<br />
|peers=<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tests/<br />
|url=http://www.mozilla.org/js/tests/library.html<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Layout Engine<br />
|description=rendering tree construction, layout (reflow), etc.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:jfkthame@gmail.com Jonathan Kew], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:matt.woodrow@gmail.com Matt Woodrow], [mailto:xidorn+moz@upsuper.org Xidorn Quan]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/%, layout/base/, layout/build/, layout/doc/, layout/forms/, layout/generic/, layout/html/, layout/printing/, layout/tables/, layout/tools/<br />
|url=http://mozilla.org/newlayout/doc/ ,<br />
http://lxr.mozilla.org/mozilla/source/layout/doc/<br />
|components=Core::Layout, Core::Layout: Block and Inline, Core::Layout: Floats, Core::Layout: Form Controls, Core::Layout: HTML Frames, Core::Layout: Images, Core::Layout: Misc Code, Core::Layout: R & A Pos, Core::Layout: Tables, Core::Layout: Text, Core::Print Preview, Core::Printing: Output<br />
}}<br />
<br />
{{Module<br />
|name=libjar<br />
|description=The JAR handling code (protocol handler, stream implementation, and zipreader/zipwriter).<br />
|owner=[mailto:mwu@mozilla.com Michael Wu]<br />
|peers=[mailto:aklotz@mozilla.com Aaron Klotz]<br />
|group=dev-platform<br />
|source_dirs=modules/libjar<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=MathML<br />
|description=MathML is a low-level specification for describing mathematics which provides a foundation for the inclusion of mathematical expressions in Web pages.<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|group=dev-tech-mathml<br />
|source_dirs=layout/mathml/<br />
|url=http://www.mozilla.org/projects/mathml/<br />
|components=Core::MathML<br />
}}<br />
<br />
{{Module<br />
|name=Media Playback<br />
|description=HTML Media APIs, including Media Source Extensions and non-MSE video/audio element playback, and Encrypted Media Extensions. (WebRTC and WebAudio not included).<br />
|owner=[mailto:jyavenard@mozilla.com Jean-Yves Avenard]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:cpearce@mozilla.com Chris Pearce]<br />
|peers=[mailto:ajones@mozilla.com Anthony Jones], [mailto:kinetik@flim.org Matthew Gregan], [mailto:eflores@mozilla.com Edwin Flores], [mailto:gsquelart@mozilla.com Gerald Squelart], [mailto:rgiles@mozilla.com Ralph Giles], [mailto:jwwang@mozilla.com JW Wang]<br />
|group=dev-media<br />
|source_dirs=dom/media, media/gmp-clearkey/, media/libcubeb/, media/libnestegg/, media/libogg/, media/libopus/, media/libstagefright/, media/libtheora/, media/libtremor/, media/libvorbis/, media/libvpx/, media/omx-plugin/, media/rlz/<br />
|url=<br />
|components=Core::Audio/Video<br />
}}<br />
<br />
{{Module<br />
|name=Media Transport<br />
|description=Pluggable transport for real-time media<br />
|owner=[mailto:ekr@rtfm.com Eric Rescorla]<br />
|peers=[mailto:bcampen@mozilla.com Byron Campen], [mailto:abr@mozilla.com Adam Roach], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]<br />
|group=dev-media<br />
|source_dirs=media/mtransport<br />
|url=<br />
|components=Core::WebRTC::Networking<br />
}}<br />
<br />
{{Module<br />
|name=Memory Allocator<br />
|description=Most things related to memory allocation in Gecko, including jemalloc, replace-malloc, DMD (dark matter detector), logalloc, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|peers=[mailto:n.nethercote@gmail.com Nicholas Nethercote], [mailto:erahm@mozilla.com Eric Rahm]<br />
|group=dev-platform<br />
|source_dirs=memory/<br />
|components=Core::DMD, Core::jemalloc<br />
}}<br />
<br />
{{Module<br />
|name=mfbt<br />
|description=mfbt is a collection of headers, macros, data structures, methods, and other functionality available for use and reuse throughout all Mozilla code (including SpiderMonkey and Gecko more broadly).<br />
|owner=[mailto:jwalden@mit.edu Jeff Walden]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd], [mailto:Ms2ger@gmail.com Ms2ger], [mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|group=dev-platform<br />
|source_dirs=mfbt/<br />
|url=<br />
|components=Core::MFBT<br />
}}<br />
<br />
{{Module<br />
|name=Mozglue<br />
|description=Glue library containing various low-level functionality, including a dynamic linker for Android, a DLL block list for Windows, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd] (mozglue/linker), [mailto:kgupta@mozilla.com Kartikaya Gupta] (mozglue/android), [mailto:nchen@mozilla.com Jim Chen] (mozglue/android)<br />
|group=dev-platform<br />
|source_dirs=mozglue/<br />
|components=Core::mozglue<br />
}}<br />
<br />
{{Module<br />
|name=mozilla-toplevel<br />
|description=The top level directory for the mozilla tree.<br />
|owner=[mailto:brendan@mozilla.org Brendan Eich]<br />
|peers=<br />
|group=<br />
|source_dirs=tools/README<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=MSCOM<br />
|description=Integration with Microsoft Distributed COM<br />
|owner=[mailto:aklotz@mozilla.com Aaron Klotz]<br />
|peers=[mailto:jteh@mozilla.com James Teh], [mailto:jmathies@mozilla.com Jim Mathies]<br />
|group=dev-platform<br />
|source_dirs=ipc/mscom/%<br />
|url=<br />
|components=Core::IPC: MSCOM}}<br />
<br />
{{Module<br />
|name=Necko<br />
|description=The Mozilla Networking Library<br />
|owner=[mailto:mcmanus@ducksong.com Patrick McManus]<br />
|peers= [mailto:jduell.mcbugs@gmail.com Jason Duell], [mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:mnovotny@mozilla.com Michal Novotny], [mailto:hurley@mozilla.com Nick Hurley], [mailto:dd.mozilla@gmail.com Dragana Damjanovic ],[mailto:valentin.gosu@gmail.com Valentin Gosu],[mailto:daniel@haxx.se Daniel Stenberg ], [mailto:schien@mozilla.com ShihChiang Chien]<br />
|peersemeritus= [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sworkman@mozilla.com Steve Workman], [mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|group=dev-tech-network<br />
|source_dirs=netwerk/%, netwerk/base/, netwerk/build/, netwerk/cache/, netwerk/dns/, netwerk/locales/, netwerk/mime/, netwerk/protocol/, netwerk/resources/, netwerk/socket/, netwerk/streamconv/, netwerk/system/, netwerk/test/, netwerk/testserver/<br />
|url=http://www.mozilla.org/projects/netlib/, https://developer.mozilla.org/en/Necko<br />
|components=Core::Networking, Core::Networking: Cache, Core::Networking: Cookies, Core::Networking: FTP, Core::Networking: File, Core::Networking: HTTP, Core::Networking: JAR, Core::Networking: Websockets<br />
}}<br />
<br />
{{Module<br />
|name=NSPR<br />
|description=Netscape Portable Runtime<br />
|owner=[mailto:kaie@kuix.de Kai Engert]<br />
|peers=[mailto:wtc@google.com Wan-Teh Chang], [mailto:mh@glandium.org Mike Hommey]<br />
|group=dev-tech-nspr<br />
|source_dirs=nsprpub/<br />
|url=http://www.mozilla.org/projects/nspr/<br />
http://www.mozilla.org/projects/nspr/reference/html/<br />
http://www.mozilla.org/projects/nspr/release-notes/<br />
|components=NSPR<br />
}}<br />
<br />
{{Module<br />
|name=PDF<br />
|description=Rendering code to display documents encoded in the ISO 32000-1 `PDF' format.<br />
|owner=Chris Jones, Andreas Gal<br />
|peers=[mailto:aadib@mozilla.com Artur Adib], [mailto:bdahl@mozilla.com Brendan Dahl], [mailto:vnicolas@mozilla.com Vivien Nicolas]<br />
|group=dev-platform<br />
|source_dirs=media/pdf/<br />
|url=https://github.com/mozilla/pdf.js<br />
|components=Core::PDF<br />
}}<br />
<br />
{{Module<br />
|name=Plugins<br />
|description= NPAPI Plugin support.<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:joshmoz@gmail.com Josh Aas]<br />
|peersemeritus=[mailto:john@pointysoftware.net John Schoenick], [mailto:robert@ocallahan.org Robert O'Callahan], [mailto:jstenback@gmail.com Johnny Stenback], Benjamin Smedberg<br />
|group=<br />
|source_dirs=dom/plugins/, modules/plugin/<br />
|url=https://wiki.mozilla.org/Plugins<br />
|components=Core::Plug-ins<br />
}}<br />
<br />
{{Module<br />
|name=Preferences<br />
|description=Preference library<br />
|owner=[mailto:nnethercote@mozilla.com Nicholas Nethercote]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd], [mailto:felipe@mozilla.com Felipe Gomes], [mailto:glandium@mozilla.com Mike Hommey], [mailto:erahm@mozilla.com Eric Rahm]<br />
|group=dev-platform<br />
|source_dirs=modules/libpref/<br />
|url=<br />
|components=Core::Preferences: Backend<br />
}}<br />
<br />
{{Module<br />
|name=Private Browsing<br />
|description=Implementation of the Private Browsing mode, and the integration of other modules with Private Browsing APIs.<br />
|owner=[mailto:josh@joshmatthews.net Josh Matthews] (while Ehsan is away)<br />
|peers=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|group=dev-platform<br />
|source_dirs=Implementation and consumers of Private Browsing APIs in nsILoadContext, nsIPrivateBrowsingChannel, PrivateBrowsingUtils.jsm and the related glue code. <br />
|url=https://wiki.mozilla.org/Private_Browsing<br />
|components=Firefox::Private Browsing<br />
}}<br />
<br />
{{Module<br />
|name=Privilege Manager<br />
|description="caps"<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|peersemeritus=[mailto:brendan@mozilla.org Brendan Eich], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:dveditz@mozilla.com Dan Veditz]<br />
|group=dev-tech-dom<br />
|source_dirs=caps/<br />
|url=http://www.mozilla.org/projects/security/components/index.html<br />
|components=Core::Security: CAPS<br />
}}<br />
<br />
{{Module<br />
|name=Push Notifications<br />
|description=Push is a way for application developers to send messages to their web applications.<br />
|owners=<br />
|ownersemeritus=[mailto:doug.turner@gmail.com Doug Turner]<br />
|peers=[mailto:nsm.nikhil@gmail.com Nikhil Marathe], [mailto:kcambridge@mozilla.com Kit Cambridge], [mailto:martin.thomson@gmail.com Martin Thomson], [mailto:ddamjanovic@mozilla.com Dragana Damjanovic]<br />
|group=<br />
|source_dirs=dom/push, dom/simplepush<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=PyXPCOM<br />
|description=The Python to XPCOM bridge.<br />
|owner=Todd Whiteman<br />
|peers=[mailto:mhammond@skippinet.com.au Mark Hammond]<br />
|group=<br />
|source_dirs=extension/python<br />
|url=https://developer.mozilla.org/en/PyXPCOM<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=RDF<br />
|description=<br />
|owner=[mailto:axel@pike.org Axel Hecht]<br />
|peers=<br />
|group=dev-tech-rdf<br />
|source_dirs=rdf/<br />
|url=http://www.mozilla.org/rdf/doc/<br />
|components=Core::RDF<br />
}}<br />
<br />
{{Module<br />
|name=security<br />
|description=Crypto/PKI code, including NSS (Network Security Services) and JSS (NSS for Java)<br />
|owner=[mailto:rrelyea@redhat.com Bob Relyea]<br />
|ownersemeritus=[mailto:ttaubert@mozilla.com Tim Taubert]<br />
|peers=[mailto:kaie@kuix.de Kai Engert], [mailto:ryan.sleevi@gmail.com Ryan Sleevi], [mailto:ekr@rtfm.com Eric Rescorla], [mailto:franziskuskiefer@gmail.com Franziskus Kiefer], [mailto:martin.thomson@gmail.com Martin Thomson], [mailto:wtc@google.com Wan-Teh Chang], [mailto:dueno@redhat.com Daiki Ueno]<br />
|peersemeritus=[mailto:emaldona@redhat.com Elio Maldonado]<br />
|group=dev-tech-crypto<br />
|source_dirs=dbm/, security/coreconf/, security/dbm/, security/jss/, security/nss/, security/tinderbox/, security/tinderlight/<br />
|url=http://mozilla.org/projects/security/pki/<br />
|components=NSS, JSS, Core::Security, Core::Security: S/MIME<br />
}}<br />
<br />
{{Module<br />
|name=Security - Mozilla PSM Glue<br />
|description=Personal Security Manager<br />
|owner=[mailto:dkeeler@mozilla.com David Keeler]<br />
|ownersemeritus=[mailto:kaie@kuix.de Kai Engert (2001-2012)]<br />
|peers=[mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:cykesiopka.bmo@gmail.com Cykesiopka], [mailto:jc@mozilla.com J.C. Jones], [mailto:fkiefer@mozilla.com Franziskus Kiefer]<br />
|group=dev-tech-crypto<br />
|source_dirs=security/manager/<br />
|url=<br />
|components=Core::Security: PSM<br />
}}<br />
<br />
{{Module<br />
|name=Static analysis & rewriting for C++<br />
|description=Tools for checking C++ code looking for problems at compile time, plus tools for automated rewriting of C++ code.<br />
|owner=[mailto:nika@thelayzells.com Nika Layzell] (while Ehsan is away)<br />
|peers=[mailto:sfink@mozilla.com Steve Fink], [mailto:jrmuizel@mozilla.com Jeff Muizelaar], [mailto:birunthan@mohanathas.com Birunthan Mohanathas], [mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|group=dev-platform<br />
|source_dirs=build/clang-plugin, tools/rewriting among other out of tree tools<br />
|url=<br />
|components=Core::Rewriting & Analysis<br />
}}<br />
{{Module<br />
|name=storage<br />
|description=Storage APIs with a SQLite backend<br />
|owner=[mailto:mak77@bonardo.net Marco Bonardo]<br />
|peers=[mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:jvarga@mozilla.com Jan Varga]<br />
|group=dev-platform<br />
|source_dirs=db/sqlite3/, storage/<br />
|url=http://developer.mozilla.org/en/docs/Storage<br />
|components=Toolkit::Storage, Core::SQL<br />
}}<br />
<br />
{{Module<br />
|name=String<br />
|description=<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd], [mailto:erahm@mozilla.com Eric Rahm]<br />
|group=dev-tech-xpcom<br />
|source_dirs=string/, xpcom/string/<br />
|url=https://developer.mozilla.org/En/Mozilla_internal_string_guide<br />
|components=Core::String<br />
}}<br />
<br />
{{Module<br />
|name=Style System<br />
|description=CSS style sheet handling; style data computation<br />
|owner= [mailto:cam@mcc.id.au Cameron McCormack]<br />
|peers=[mailto:dbaron@dbaron.org David Baron], [mailto:emilio@crisal.io Emilio Cobos Álvarez], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:xidorn+moz@upsuper.org Xidorn Quan], [mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/style/<br />
|url=https://wiki.mozilla.org/Gecko:Overview#Style_System<br />
|components=Core::CSS Parsing and Computation<br />
}}<br />
<br />
{{Module<br />
|name=SVG<br />
|description=Scalable Vector Graphics<br />
|owner=[mailto:jwatt@jwatt.org Jonathan Watt]<br />
|peers=[mailto:longsonr@gmail.com Robert Longson], [mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:birtles@gmail.com Brian Birtles]<br />
|group=dev-tech-svg<br />
|source_dirs=dom/svg/, layout/svg/, dom/smil/<br />
|url=https://developer.mozilla.org/en-US/docs/Web/SVG<br />
|components=Core::SVG<br />
}}<br />
<br />
{{Module<br />
|name=Tamarin<br />
|description=VM for ActionScript and JavaScript<br />
|owner=Edwin Smith, [mailto:jodyer@adobe.com Jeff Dyer]<br />
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:stejohns@adobe.com Steven Johnson], [mailto:tierney@adobe.com Erik Tierney], [mailto:treilly@adobe.com Tom Reilly]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tamarin<br />
|url=http://www.mozilla.org/projects/tamarin/<br />
http://wiki.mozilla.org/tamarin/<br />
http://hg.mozilla.org/tamarin-central/<br />
http://hg.mozilla.org/tamarin-tracing/<br />
|components=Tamarin<br />
}}<br />
<br />
{{Module<br />
|name=Test Harness<br />
|description=In-tree test infrastructure and tools. Harnesses include, XPCShell, Mochitest (& Chrome), Reftest, JsREftest, Compiled Code Tests, Robocop, Mozmill, Marionette, Firefox UI Tests. Requests for new harnesses should go to Testing::General.<br />
|owner=[mailto:ted@mielczarek.org Ted Mielczarek]<br />
|peers=[mailto:dbaron@dbaron.org David Baron] (reftest), [mailto:jwalden@mit.edu Jeff Walden] (httpd.js, jsreftest), Rob Campbell (mochitest, mochitest chrome, marionette), [mailto:jmaher@mozilla.com Joel Maher] (reftest, mochitest, jsreftest), [mailto:ctalbert@mozilla.com Clint Talbert] (reftest, compiled code, mozmill), [mailto:geoffbrown@mozilla.com Geoff Brown] (robocop), [mailto:hskupin@mozilla.com Henrik Skupin] (Marionette, Firefox UI tests), [mailto:ato@mozilla.com Andreas Tolfsen] (marionette), [mailto:jgriffin Jonathan Griffin] (marionette), [mailto:dburns@mozilla.com David Burns] (marionette), [mailto:dminor@mozilla.com Dan Minor], [mailto:mjzffr@gmail.com Maja Frydrychowicz] (Marionette, Firefox UI tests), <br />
<br />
|group=dev-quality<br />
|source_dirs=/testing<br />
|url=http://wiki.mozilla.org/SoftwareTesting<br />
|components=Testing::General, Testing::Mochitest, Testing::Mochitest Chrome, Testing::Marionette, Testing::Mozmill, Testing::Reftest, Testing::XPCShell Harness, Testing::httpd.js<br />
}}<br />
<br />
{{Module<br />
|name=Testing Infrastructure<br />
|description=Testing tools and infrastructure for Mozilla projects, harnesses for automated tests, stand-alone test tools. Talos, Graph Server, Mozbase, Pulse, WOO, Bughunter, SUTAgent, Eideticker<br />
|owner=[mailto:jmaher@mozilla.com Joel Maher]<br />
|peers=[mailto:bclary@bclary.com Bob Clary], [mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:ccooper@deadsquid.com Chris Cooper], [mailto:ctalbert@mozilla.com Clint Talbert], [mailto:robert@roberthelmer.com Robert Helmer], [mailto:jmaher@mozilla.com Joel Maher], Rob Campbell, [mailto:wlach@mozilla.com William Lachance], [mailto:jeads@mozilla.com Jonathan Eads], [mailto:jgriffin Jonathan Griffin], [mailto:bmoss@mozilla.com Bob Moss], [mailto:mcote@mozilla.com Mark Côté]<br />
|group=dev-quality<br />
|source_dirs=testing/, tools/httptester/, tools/page-loader/, tools/test-harness/, tools/tests/, tools/testserver/, tools/testy/<br />
|url=http://wiki.mozilla.org/SoftwareTesting<br />
|components=Testing::Infrastructure<br />
}}<br />
<br />
{{Module<br />
|name=JS Marionette<br />
|description=NodeJS test harness, marionette client, and other utilities for running marionette tests (submodule of Test Infrastructure)<br />
|owner=[mailto:jlal@mozilla.com James Lal] <lightsofapollo>, [mailto:gaye@mozilla.com Gareth Aye] <gaye><br />
|peers=[mailto:aus@mozilla.com Ghislain "Aus" Lacroix] <auswerk><br />
|source_dirs=gaia/tests/jsmarionette<br />
|components=Testing::JSMarionette<br />
|group=dev-gaia<br />
}}<br />
<br />
{{Module<br />
|name=XPCShell Test Harness<br />
|description=The XPCShell Harness<br />
|owner=[mailto:ted@mielczarek.org Ted Mielczarek]<br />
|peers=[mailto:jmaher@mozilla.com Joel Maher]<br />
|source_dirs=testing/xpcshell<br />
|components=Testing::XPCShell Harness<br />
}}<br />
<br />
{{Module<br />
|name=Update Service<br />
|description=server code for Mozilla Update services (aus, addons, pfs)<br />
|owner=Mike Morgan<br />
|peers=[mailto:jscott@mozilla.com Justin Scott], [mailto:shaver@mozilla.org Mike Shaver], [mailto:wclouser@mozilla.com Will Clouser]<br />
|group=dev-amo<br />
|source_dirs=webtools/addons/, webtools/aus/, webtools/update/<br />
|url=http://wiki.mozilla.org/wiki/AMO<br />
|components=AUS::Administration, AUS::Systems<br />
}}<br />
<br />
{{Module<br />
|name=View System<br />
|description=The View Manager is responsible for handling "heavyweight" rendering (some clipping, compositing) and event handling tasks.<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron]<br />
|group=dev-tech-layout<br />
|source_dirs=view/<br />
|url=<br />
|components=Core::Layout: View Rendering<br />
}}<br />
<br />
{{Module<br />
|name=Web Audio<br />
|description=Support for the W3C Web Audio API specification.<br />
|owner=[mailto:padenot@mozilla.com Paul Adenot]<br />
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:karlt+@karlt.net Karl Tomlinson]<br />
|group=dev-platform<br />
|source_dirs=dom/media/webaudio<br />
|url=https://wiki.mozilla.org/Web_Audio_API<br />
|components=Core::Web Audio<br />
}}<br />
<br />
{{Module<br />
|name=Web Painting<br />
|description=painting, display lists, and layer construction<br />
|owner=[mailto:matt.woodrow@gmail.com Matt Woodrow]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dbaron@dbaron.org David Baron], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:mstange@themasta.com Markus Stange], [mailto:mmynttinen@mozilla.com Miko Mynttinen], [mailto:jnicol@mozilla.com Jamie Nicol]<br />
|group=dev-tech-layout<br />
|source_dirs= layout/painting, the display list and layer related methods on nsIFrame and its subclasses<br />
|url=http://mozilla.org/newlayout/doc/ ,<br />
http://lxr.mozilla.org/mozilla/source/layout/doc/<br />
|components=Core::Layout: Web Painting<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC<br />
|description=WebRTC is responsible for realtime audio and video communication, as well as related issues like low-level camera and microphone access<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:bcampen@mozilla.com Byron Campen] [mailto:abr@mozilla.com Adam Roach]<br />
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=netwerk/sctp (also see submodules "WebRTC Media" and "WebRTC Signaling")<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC, Core::WebRTC Networking<br />
}}<br />
<br />
{{Module<br />
|name=WebVR<br />
|description=Gecko's implementation of WebVR (Virtual Reality) functionality, including API, devices, graphics and integration<br />
|owner=[mailto:kgilbert@mozilla.com Kip Gilbert]<br />
|peers=[mailto:dmu@mozilla.com Daosheng Mu]<br />
|peersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|group=dev-platform<br />
|source_dirs=dom/vr, gfx/vr<br />
|url=https://mozvr.com/<br />
|components=Core::WebVR<br />
}}<br />
<br />
{{Module<br />
|name=Widget<br />
|description=<br />
|owner=[mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peersemeritus=[mailto:pavlov@pavlov.net Stuart Parmenter], <br />
|group=dev-platform<br />
|source_dirs=widget/, widget/xpwidgets/<br />
|url=<br />
|components=Core::Drag and Drop, Core::Widget, Core::Printing: Setup<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Android<br />
|description=The Android Port<br />
|owner=[mailto:blassey.bugs@lassey.us Brad Lassey]<br />
|peers=[mailto:jwillcox@mozilla.com James Willcox]<br />
|group=dev-platforms-mobile<br />
|source_dirs=widget/android/, embedding/android<br />
|url=<br />
|components=Core::Widget: Android<br />
}}<br />
<br />
{{Module<br />
|name=Widget - GTK<br />
|description=supported X widgetry and gfx<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|group=dev-platform<br />
|source_dirs=widget/gtk/, widget/gtk2/, widget/gtksuperwin/, widget/gtkxtbin/<br />
|url=http://www.mozilla.org/unix/, http://www.gtk.org, http://www.mozilla.org/ports/gtk/<br />
|components=Core::Widget: Gtk<br />
}}<br />
<br />
{{Module<br />
|name=Widget - OS X<br />
|description= Gecko's OS X compatibility layer.<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|peers=[mailto:joshmoz@gmail.com Josh Aas], [mailto:bgirard@mozilla.com Benoit Girard], [mailto:spohl@mozilla.com Stephen Pohl], [mailto:smichaud@pobox.com Steven Michaud]<br />
|group=dev-platform<br />
|source_dirs=widget/cocoa/<br />
|url=<br />
|components=Core::Widget: Cocoa<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Windows<br />
|description=Windows widgets and desktop integration<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook], [mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:jmathies@mozilla.com Jim Mathies]<br />
|peersemeritus=[mailto:blassey@mozilla.com Brad Lassey], [mailto:netzen@gmail.com Brian Bondy], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:doug.turner@gmail.com Doug Turner], [mailto:timeless@mozdev.org Josh 'timeless' Soref], [mailto:robarnold@cmu.edu Rob Arnold]<br />
|group=dev-platform<br />
|source_dirs=widget/windows/<br />
|url=<br />
|components=Core::Widget: Win32<br />
}}<br />
<br />
{{Module<br />
|name=XBL<br />
|description=eXtensible Binding Language<br />
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|peers=[mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:jonas@sicking.cc Jonas Sicking]<br />
|ownersemeritus=[mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-tech-xbl<br />
|source_dirs=dom/xbl/<br />
|url=http://www.mozilla.org/projects/xbl/<br />
|components=Core::XBL<br />
}}<br />
<br />
{{Module<br />
|name=XML<br />
|description=XML in Mozilla, including XML, XHTML, Namespaces in XML, Associating Style Sheets with XML Documents, XML Linking and XML Extras. XML-related things that are not covered by more specific projects.<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:erahm@mozilla.com Eric Rahm]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:jstenback@gmail.com Johnny Stenback]<br />
|group=dev-tech-xml<br />
|source_dirs=dom/xml/, extensions/xmlextras/, parser/expat/<br />
|url=http://www.mozilla.org/newlayout/xml/<br />
|components=Core::XML<br />
}}<br />
<br />
{{Module<br />
|name=XPApps<br />
|description=Cross-Platform Applications, mostly Navigator front end and application shell.<br />
|owner=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|peers=[mailto:dean_tessman@hotmail.com Dean Tessman], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-apps-seamonkey<br />
|source_dirs=xpfe/<br />
|url=http://www.mozilla.org/xpapps/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPCOM<br />
|description=The cross-platform object model and core data structures.<br />
|owner=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd]<br />
|peers=[mailto:erahm@mozilla.com Eric Rahm]<br />
|ownersemeritus=Benjamin Smedberg<br />
|peersemeritus=[https://mozillians.org/en-US/u/dougt/ Doug Turner]<br />
|group=dev-platform<br />
|source_dirs=startupcache/, xpcom/%, xpcom/base/, xpcom/build/, xpcom/components/, xpcom/ds/, xpcom/glue/, xpcom/proxy/, xpcom/sample/, xpcom/stub/, xpcom/tests/, xpcom/threads/, xpcom/tools/, xpcom/windbgdlg/<br />
|url=http://developer.mozilla.org/en/XPCOM<br />
|components=Core::XPCOM<br />
}}<br />
<br />
{{Module<br />
|name=XPConnect<br />
|description=Deep Magic<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:kmaglione@mozilla.com Kris Maglione], [mailto:nika@thelayzells.com Nika Layzell]<br />
|peersemeritus=[mailto:gal@uci.edu Andreas Gal], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:gkrizsanits@mozilla.com Gabor Krizsanits]<br />
|group=<br />
|source_dirs=js/xpconnect/<br />
|url=<br />
|components=Core::XPConnect<br />
}}<br />
<br />
{{Module<br />
|name=XPIDL<br />
|description=Cross-platform IDL compiler; produces .h C++ header files and .xpt runtime type description files from .idl interface description files.<br />
|owner=[mailto:me@kylehuey.com Kyle Huey]<br />
|peersemeritus=[mailto:shaver@mozilla.org Mike Shaver], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-tech-xpcom<br />
|source_dirs=xpcom/typelib/<br />
|url=http://www.mozilla.org/scriptable/xpidl<br />
http://www.mozilla.org/scriptable<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPInstall<br />
|description=<br />
|owner=[mailto:dveditz@mozilla.com Dan Veditz]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|group=dev-tech-xpinstall<br />
|source_dirs=xpinstall/<br />
|url=<br />
|components=Core::Installer: XPInstall Engine<br />
}}<br />
<br />
{{Module<br />
|name=XPToolkit<br />
|description=Cross-platform user interface toolkit<br />
|owner=<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:Jan.Varga@gmail.com Jan Varga]<br />
|group=dev-tech-xul<br />
|source_dirs=dom/xul/, layout/xul/<br />
|url=http://www.mozilla.org/xpfe/<br />
|components=Core::XP Toolkit/Widgets: Menus, Core::XP Toolkit/Widgets: XUL<br />
}}<br />
<br />
{{Module<br />
|name=XSLT Processor<br />
|description=XSLT transformations processor<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:axel@pike.org Axel Hecht], [mailto:erahm@mozilla.com Eric Rahm]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-tech-xslt<br />
|source_dirs=dom/xslt/<br />
|url=http://www.mozilla.org/projects/xslt/, http://www.w3.org/TR/xslt.html<br />
|components=Core::XSLT<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Windows <br />
|description=Sandboxing for the Windows platform <br />
|owner=[mailto:bobowencode@gmail.com Bob Owen] (:bobowen)<br />
|peers=[mailto:aklotz@mozilla.com Aaron Klotz] (:aklotz), [mailto:jimm@mozilla.com Jim Mathies] (:jimm), [mailto:davidp99@gmail.com David Parks] (:handyman)<br />
|ownersemeritus=[https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes]<br />
|peersemeritus=[mailto:netzen@gmail.com Brian Bondy]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/win <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - OSX <br />
|description=Sandboxing for the OSX platform <br />
|owner=[mailto:haftandilian@mozilla.com Haik Aftandilian]<br />
|peers=<br />
|group=dev-platform <br />
|source_dirs=security/sandbox/mac <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Linux<br />
|description=Sandboxing for the Linux platform<br />
|owner=[mailto:jld@mozilla.com Jed Davis]<br />
|peers=[mailto:gcp@mozilla.com Gian-Carlo Pascutto]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/linux<br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
===Submodules===<br />
{{Module<br />
|name=Build Config - Fennec<br />
|description=Submodule of the build config covering Fennec's build system in mobile/android.<br />
|owner=[mailto:nalexander@mozilla.com Nicholas Alexander]<br />
|peers=Same as Build Config<br />
|group=dev-builds<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=Build Config - Taskgraph<br />
|description=Support for task-graph generation in decision, action, and cron tasks, including configuration of all tasks including those for CI, nightlies, and releases; as well as Docker and VM images used to execute those tasks.<br />
|owner=[mailto:dustin@mozilla.com Dustin Mitchell]<br />
|peers=[mailto:ahal@mozilla.com Andrew Halberstadt], [mailto:aki@mozilla.com Aki Sasaki], [mailto:bstack@mozilla.com Brian Stack], [mailto:mh@glandium.org Mike Hommey], [mailto:gps@mozilla.com Gregory Szorc], [mailto:jmaher@mozilla.com Joel Maher], [mailto:callek@mozilla.com Justin Wood]<br />
|components=Firefox Build System::Task Configuration<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC Media<br />
|description=Submodule of WebRTC responsible for access to media input devices (microphones, cameras, screen capture), as well as realtime audiovisual codecs and packetization.<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:jib@mozilla.com Jan-Ivar Bruaroey], [mailto:dminor@mozilla.com Dan Minor], [mailto:apehrson@mozilla.com Andreas Pehrson], <br />
|peersemeritus=[mailto:pkerr@mozilla.com Paul Kerr], [mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=/media/webrtc, /dom/media/webrtc, /dom/media/systemservices<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC (Audio/Video)<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC Signaling<br />
|description=Submodule of WebRTC responsible for implementation of PeerConnection API, WebRTC identity, and SDP/JSEP handling<br />
|owner=[mailto:bcampen@mozilla.com Byron Campen]<br />
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:abr@mozilla.com Adam Roach], [mailto:rjesup@mozilla.com Randell Jesup], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]<br />
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=/media/webrtc/signaling/<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC (Signaling)<br />
}}<br />
<br />
<br />
<noinclude><br />
<br />
===Unassigned Bugzilla Components===<br />
<br />
The following Bugzilla components in the Core project have not been assigned to a module (this list is not exhaustive):<br />
<br />
<pre><br />
Core::Find Backend<br />
Core::General<br />
Core::HTML: Form Submission<br />
Core::History: Global<br />
Core::Image Blocking<br />
Core::Localization<br />
Core::Networking: Domain Lists<br />
Core::Selection<br />
Core::Serializers<br />
Core::Spelling checker<br />
Core::X-remote<br />
Core::XUL<br />
</pre><br />
</noinclude></div>Dkeelerhttps://wiki.mozilla.org/index.php?title=Modules/Core&diff=1192491Modules/Core2018-04-17T23:39:54Z<p>Dkeeler: update PSM bugzilla components</p>
<hr />
<div><noinclude><br />
'''Only module owners may edit this page.''' <br />
<br />
They may:<br />
<br />
* update any information about their module except the name of the owner<br />
* add or remove sub-modules<br />
* change the owner of a sub-module <br />
* add emeritus owners or peers<br />
<br />
Other changes, including changes of module owner or addition/removal of modules, must be agreed with the Module Ownership Module group, probably via a discussion in [https://www.mozilla.org/about/forums/#governance mozilla.governance].<br />
</noinclude><br />
{{Module<br />
|name=Accessibility<br />
|description=Support for platform accessibility APIs. Accessibility APIs are used by 3rd party software like screen readers, screen magnifiers, and voice dictation software, which need information about document content and UI controls, as well as important events like changes of focus.<br />
|owner=[mailto:surkov.alexander@gmail.com Alexander Surkov]<br />
|peers=[mailto:dbolter@mozilla.com David Bolter], [mailto:eitan@monotonous.org Eitan Isaacson], [mailto:jteh@mozilla.com James Teh], [mailto:mzehe@mozilla.com Marco Zehe], [mailto:yzenevich@mozilla.com Yura Zenevich]<br />
|ownersemeritus=[mailto:aaron@moonset.net. Aaron Leventhal]<br />
|peersemeritus=[mailto:tbsaunde+mozbugs@tbsaunde.org Trevor Saunders], [mailto:ginn.chen@oracle.com Ginn Chen], Evan Yan<br />
|group=dev-accessibility<br />
|source_dirs=accessible/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=Animation<br />
|description=Declarative animations: CSS animations, CSS transitions, Web Animations API, and off-main thread animations.<br />
|owner=[mailto:bbirtles@mozilla.com Brian Birtles] (:birtles)<br />
|peers=[mailto:hiro@mozilla.com Hiroyuki Ikezoe] (:hiro), [mailto:mwoodrow@mozilla.com Matt Woodrow] (:mattwoodrow)<br />
|group=dev-tech-layout<br />
|source_dirs=dom/animation; and animation-related and interpolation-related code in layout/style, gfx/layers, servo/components/style and servo/ports/gecko<br />
|components=Core::DOM::Animation, Core::CSS Parsing and Computation (for CSS animations/transitions related bugs)<br />
}}<br />
<br />
{{Module<br />
|name=Browser WebAPI<br />
|description=Web API for rendering apps, browser windows and widgets.<br />
|owner=[mailto:kchen@mozilla.com Kan-Ru Chen]<br />
|peers=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:fabrice@mozilla.com Fabrice Desré]<br />
|group=dev-webapi<br />
|source_dirs=dom/browser-element/<br />
|url=<br />
|components=Core::DOM<br />
}}<br />
<br />
{{Module<br />
|name=Build and Release Tools<br />
|description=Tools related to build and release automation and configuration of release builds.<br />
|owner=[mailto:nthomas@mozilla.com Nick Thomas]<br />
|peers=[mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:coop@mozilla.com Chris Cooper]<br />
|group=release-engineering<br />
|source_dirs=browser/config/mozconfigs/, mobile/android/config/mozconfigs/, xulrunner/config/mozconfigs/, b2g/config/, tools/update-packaging/<br />
|url=https://wiki.mozilla.org/ReleaseEngineering<br />
|components=Release Engineering::*<br />
}}<br />
<br />
{{Module<br />
|name=Build Config<br />
|description=The build system for Gecko and several mozilla.org hosted Gecko-based applications.<br />
|owner=[mailto:gps@mozilla.com Gregory Szorc] (:gps)<br />
|peers=[mailto:mh@glandium.org Mike Hommey] (:glandium), [mailto:mshal@mozilla.com Mike Shal] (:mshal), [mailto:ted@mielczarek.org Ted Mielczarek] (:ted), [mailto:cmanchester@mozilla.com Chris Manchester](:chmanchester), [mailto:nfroyd@mozilla.com Nathan Froyd] (:froydnj), [mailto:rgiles@mozilla.com Ralph Giles] (:rillian)<br />
|ownersemeritus=Ted Mielczarek (2008-[https://blog.mozilla.org/ted/2013/03/07/gregory-szorc-is-now-the-build-config-module-owner/ 2013]), Benjamin Smedberg (???-[http://benjamin.smedbergs.us/blog/2008-04-30/more-changing-of-the-guard-ted-mielczarek/ 2008]), <br />
|group=dev-builds<br />
|source_dirs=build/, config/, python/mozbuild, tools/cross-commit, tools/cvs2hg-import.py, tools/cvsmgmt/, tools/elf-dynstr-gc/, tools/trees.pl, browser/config/mozconfigs/, mobile/config/mozconfigs/, xulrunner/config/mozconfigs/<br />
|url=http://www.mozilla.org/build/<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=Code Analysis and Debugging Tools<br />
|description=Tools for debugging Mozilla code or for analyzing speed, memory use, and other characteristics of it.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=<br />
|group=dev-performance<br />
|source_dirs=tools/codesighs/, tools/debug/, tools/dreftool/, tools/dumpdeps/, tools/footprint/, tools/jprof/, tools/leaky/, tools/memory/, tools/module-deps/, tools/performance/, tools/post_compile/, tools/preloader/, tools/rb/, tools/reorder/, tools/trace-malloc/, tools/uuiddeps/, <br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Content HTTP Headers<br />
|description=HTTP headers related to content, e.g. User-Agent, Content-Type, Accept. (Transport-related headers are the responsibility of the Necko module owner.)<br />
|owner=[mailto:gerv@mozilla.org Gervase Markham]<br />
|peers=[mailto:lmandel@mozilla.com Lawrence Mandel]<br />
|group=dev-platform<br />
|source_dirs= <br />
|url=https://developer.mozilla.org/en/Gecko_user_agent_string_reference<br />
|components=Core::Networking: HTTP<br />
}}<br />
<br />
{{Module<br />
|name=Content Security<br />
|description=Native content-based security features, including: Content Security Policy (CSP), Mixed Content Blocker (MCB), Subresource Integrity (SRI) and CORS.<br />
|owner=[mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]<br />
|peers=[mailto:francois@mozilla.com François Marier], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:tvyas@mozilla.com Tanvi Vyas], [mailto:dveditz@mozilla.com Dan Veditz], [mailto:mozilla@sidstamm.com Sid Stamm] <br />
|group=dev-security<br />
|source_dirs=dom/security<br />
|components=Core::DOM: Security<br />
}}<br />
<br />
{{Module<br />
|name=Cookies and Permissions<br />
|description=<br />
|owner=Monica Chew<br />
|peers=[mailto:josh@joshmatthews.com Josh Matthews], [mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dwitte@gmail.com Dan Witte], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)]<br />
|group=dev-tech-network<br />
|source_dirs=extensions/cookie/, netwerk/cookie/<br />
|url=<br />
|components=Core::Networking: Cookies<br />
}}<br />
{{Module<br />
|name=Cycle Collector<br />
|description=Code to break and collect objects within reference cycles<br />
|owner=[https://mozillians.org/en-US/u/mccr8/ Andrew McCreight]<br />
|peers=Peter Van der Beken, Olli Pettay, David Baron<br />
|source_dirs=xpcom/base/nsCycleCollector.* and some support headers<br />
|components=Core::XPCOM<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=C++/Rust usage, tools, and style<br />
|description=Aspects of C++ use such as language feature usage, standard library versions/usage, compiler/toolchain versions, formatting and naming style, and aspects of Rust use as needs arise<br />
|owner=[mailto:nfroyd@mozilla.com Nathan Froyd] (while Ehsan is away)<br />
|peers=[mailto:bballo@mozilla.com Botond Ballo], [mailto:glandium@mozilla.com Mike Hommey], [mailto:jwalden@mozilla.com Jeff Walden], [mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|source_dirs=non-third-party C++ and Rust code in the tree<br />
|components=Various components<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=docshell<br />
|description=<br />
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|peers=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:sawang@mozilla.com Samael Wang]<br />
|peersemeritus=[mailto:jstenback@gmail.com Johnny Stenback],[mailto:cbiesinger@gmail.com Christian Biesinger],[mailto:justin.lebar@gmail.com Justin Lebar]<br />
|group=dev-platform<br />
|source_dirs=docshell/, uriloader/<br />
|url=<br />
|components=Core::Document Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Document Object Model<br />
|description=<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:hsivonen@iki.fi Henri Sivonen], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:baku@mozilla.com Andrea Marchesini],<br />
[mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:bkelly@mozilla.com Ben Kelly], [mailto:kyle@nonpolynomial.com Kyle Machulis], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:nika@thelayzells.com Nika Layzell]<br />
|ownersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]<br />
|peersemeritus=[mailto:justin.lebar@gmail.com Justin Lebar], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:bent.mozilla@gmail.com Ben Turner], [mailto:mounir@lamouri.fr Mounir Lamouri (still active, but slower to respond than previously)], [mailto:me@kylehuey.com Kyle Huey], [mailto:wmccloskey@mozilla.com Bill McCloskey]<br />
|group=dev-tech-dom<br />
|source_dirs=dom/*, except directories covered by other modules<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM, Core::DOM: CSS Object Model, Core::DOM: Core & HTML<br />
}}<br />
<br />
{{Module<br />
|name=DOM File<br />
|description=DOM Blob, File and FileSystem APIs <br />
|owner=[mailto:amarchesini@Mozilla.com Andrea Marchesini]<br />
|peers=[mailto:olli@pettay.fi Olli Pettay]<br />
|group=dev-platform<br />
|source_dirs=dom/file, dom/filesystem<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM: File<br />
}}<br />
<br />
{{Module<br />
|name=Event Handling<br />
|description=DOM Events and Event Handling <br />
|owner=[mailto:olli@pettay.fi Olli Pettay], [mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:sshih@mozilla.com Stone Shih]<br />
|group=dev-platform<br />
|source_dirs=dom/events and event handling related code elsewhere <br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM: Events, Core::Event Handling<br />
}}<br />
<br />
{{Module<br />
|name=Web Workers<br />
|description=<br />
|owner=[mailto:baku@mozilla.com Andrea Marchesini]<br />
|peers=[mailto:mrbkap@mozilla.com Blake Kaplan], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey], [mailto:bkelly@mozilla.com Ben Kelly]<br />
|ownersemeritus=[mailto:bent.mozilla@gmail.com Ben Turner]<br />
|group=dev-platform<br />
|source_dirs=dom/workers/<br />
|url=https://developer.mozilla.org/En/Using_web_workers<br />
|components=Core::DOM: Workers<br />
}}<br />
<br />
{{Module<br />
|name=IndexedDB<br />
|description=<br />
|owner=[mailto:jvarga@mozilla.com Jan Varga]<br />
|peers=[mailto:btseng@mozilla.com Bevis Tseng], [mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:baku@mozilla.com Andrea Marchesini]<br />
|ownersemeritus=[mailto:bent.mozilla@gmail.com Ben Turner]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey]<br />
|group=dev-platform<br />
|source_dirs=dom/indexedDB/<br />
|url=https://developer.mozilla.org/en/IndexedDB<br />
|components=Core::DOM: IndexedDB<br />
}}<br />
<br />
{{Module<br />
|name=Editor<br />
|description=<br />
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]<br />
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|group=dev-platform<br />
|source_dirs=editor/<br />
|url=http://www.mozilla.org/editor/<br />
|components=Core::Editor<br />
}}<br />
<br />
{{Module<br />
|name=Embedding<br />
|description=Gecko embedding APIs and frameworks<br />
|owner=[mailto:myk@mykzilla.org Myk Melez]<br />
|ownersemeritus=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:doug.turner@gmail.com Doug Turner]<br />
|peers=[mailto:bdahl@mozilla.com Brendan Dahl], [mailto:tbsaunde@tbsaunde.org Trevor Saunders]<br />
|peersemeritus=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jstenback@gmail.com Johnny Stenback]<br />
|group=dev-platform<br />
|source_dirs=embedding/<br />
|url=<br />
|components=Core::Embedding: APIs<br />
}}<br />
<br />
{{Module<br />
|name=Find As You Type<br />
|description=Find As You Type (formerly called Type Ahead Find) is a feature that allows quick web page navigation when you type a succession of characters in the body of the displayed page (not in an edit box of or drop down list). Currently seeks new owner.<br />
|owner=<br />
|peers=<br />
|group=dev-accessibility<br />
|source_dirs=extensions/typeaheadfind/<br />
|url=http://www.mozilla.org/access/type-ahead/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Gecko Profiler<br />
|description=Gecko's built-in profiler<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|peers=[mailto:nnethercote@mozilla.com Nicholas Nethercote], [mailto:jseward@mozilla.com Julian Seward] (LUL), [mailto:kvijayan@mozilla.com Kannan Vijayan] (JS integration), [mailto:shu@mozilla.com Shu-yu Guo] (JS integration), [mailto:tlee@mozilla.com Thinker Lee] (TaskTracer), [mailto:cyu@mozilla.com Cervantes Yu] (TaskTracer), [mailto:b56girard@gmail.com Benoit Girard].<br />
|group=dev-platform<br />
|source_dirs=tools/profiler/<br />
|url=https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler<br />
|components=Core::Gecko Profiler<br />
}}<br />
<br />
{{Module<br />
|name=Geolocation<br />
|description=Implementation of the Geolocation W3C Spec, location provider apis, and wifi scanning code.<br />
|owner=[mailto:josh@joshmatthews.net Josh Matthews], [mailto:kchen@mozilla.com Kan-Ru Chen]<br />
|ownersemeritus=[mailto:doug.turner@gmail.com Doug Turner], Garvan Keeley<br />
|peers=<br />
|group=dev-tech-dom<br />
|source_dirs=dom/geolocation, dom/system/, netwerk/wifi<br />
|url=https://developer.mozilla.org/En/Using_geolocation<br />
|components=Core::Geolocation<br />
}}<br />
<br />
{{Module<br />
|name=Global Key Bindings<br />
|description=Global hot keys in Mozilla for the browser, editor, mail-news and widgets. Does not include underlined menu accelerators and the like, as those are part of i18n.<br />
|owner=Aaron Leventhal<br />
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|group=dev-accessibility<br />
|source_dirs=dom/xbl/builtin/<br />
|url=http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html<br />
|components=Core::Keyboard: Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Graphics<br />
|description=Mozilla graphics API<br />
|owner=[mailto:jrmuizel@mozilla.com Jeff Muizelaar](Thebes, QCMS, YCbCr, Cairo/Pixman, Regions, OS X, Other)<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peers=[mailto:jdrew@mozilla.com Joe Drew], [mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:bas.schouten@live.nl Bas Schouten](Layers, Windows), [mailto:bjacob@mozilla.com Benoit Jacob](gfx/gl), [mailto:bgirard@mozilla.com Benoit Girard](Compositor, Performance), [mailto:ajuma.bugzilla@alijuma.com Ali Juma], [mailto:jgilbert@mozilla.com Jeff Gilbert](WebGL, ANGLE), [mailto:george@mozilla.com George Wright](Canvas2D), [mailto:mwoodrow@mozilla.com Matt Woodrow](Layers API), [mailto:jdaggett@mozilla.com John Daggett](text/fonts), [mailto:jfkthame@googlemail.com Jonathan Kew](text/fonts), [mailto:nsilva@mozilla.com Nicolas Silva](MozSurface), [mailto:ncameron@mozilla.com Nick Cameron], [mailto:sikeda@mozilla.com Sotaro Ikeda](B2G), [mailto:snorp@mozilla.com James Willcox](Android), [mailto:clord@mozilla.com Christopher Lord], [mailto:mstange@themasta.com Markus Stange](OS X), [mailto:lsalzman@mozilla.com Lee Salzman](Skia), [mailto:mchang@mozilla.com Mason Chang], [mailto:dvander@mozilla.com David Anderson]<br />
|group=dev-platform<br />
|source_dirs=gfx/, dom/canvas/<br />
|url=https://wiki.mozilla.org/Platform/GFX https://wiki.mozilla.org/Gecko:Layers https://wiki.mozilla.org/Gecko:2DGraphicsSketch<br />
|components=Core::Graphics, Core::Graphics: Layers, Core::Graphics: Text, Core::GFX: Color Management, Core::Canvas: 2D, Core::Canvas: WebGL<br />
}}<br />
<br />
{{Module<br />
|name=APZ (Graphics submodule)<br />
|description=Asynchronous panning and zooming<br />
|owner=[mailto:kgupta@mozilla.com Kartikaya Gupta]<br />
|peers=[mailto:bballo@mozilla.com Botond Ballo], [mailto:tnikkel@mozilla.com Timothy Nikkel], [mailto:dvander@mozilla.com David Anderson], [mailto:mstange@mozilla.com Markus Stange]<br />
|group=dev-platform<br />
|source=gfx/layers/apz<br />
|url=https://wiki.mozilla.org/Platform/GFX/APZ<br />
|components=Core::Panning and Zooming<br />
}}<br />
<br />
{{Module<br />
|name=Moz2D (Graphics submodule)<br />
|description=Platform independent 2D graphics API<br />
|owner=[mailto:bschouten@mozilla.com Bas Schouten]<br />
|peers=[mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:gwright@mozilla.com George Wright], [mailto:jwatt@jwatt.org Jonathan Watt]<br />
|group=dev-platform<br />
|source=gfx/2d<br />
|url=https://wiki.mozilla.org/Platform/GFX/Moz2D<br />
|components=Core::Graphics<br />
}}<br />
<br />
{{Module<br />
|name=Legacy HTML Parser<br />
|description=<br />
|owner=[mailto:mrbkap@gmail.com Blake Kaplan]<br />
|peers=[mailto:dbaron@dbaron.org David Baron], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:rbs@maths.uq.edu.au rbs@maths.uq.edu.au]<br />
|peersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]<br />
|source_dirs=parser/htmlparser<br />
|url=http://www.mozilla.org/newlayout/doc/parser.html<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=HAL<br />
|description=Hardware Abstraction Layer<br />
|owner=[https://mozillians.org/u/dhylands/ Dave Hylands]<br />
|peers=[mailto:gsvelto@mozilla.com Gabriele Svelto]<br />
|group=dev-platform<br />
|source_dirs=hal/<br />
|components=Core::Hardware Abstraction Layer (HAL)<br />
}}<br />
<br />
{{Module<br />
|name=HTML Parser<br />
|description=The HTML Parser transforms HTML source code into a DOM. It conforms to the HTML specification, and is mostly translated automatically from Java to C++.<br />
|owner=[mailto:hsivonen@iki.fi Henri Sivonen]<br />
|peers=[mailto:wchen@mozilla.com William Chen]<br />
|group=dev-platform<br />
|source_dirs=parser/html<br />
|url=http://about.validator.nu/<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=I18N Library<br />
|description=<br />
|owner=[mailto:hsivonen@hsivonen.fi Henri Sivonen (encoding)], [mailto:jfkthame@gmail.com Jonathan Kew (except to encoding)]<br />
|peers=[mailto:VYV03354@nifty.ne.jp Masatoshi Kimura], [mailto:gandalf@aviary.pl Zibi Braniecki], [mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]<br />
|ownersemeritus=[mailto:jshin1987@gmail.com Jungshik Shin], [mailto:smontagu@smontagu.org Simon Montagu]<br />
|group=dev-i18n<br />
|source_dirs=intl/<br />
|url=http://mozilla.org/projects/intl/index.html<br />
|components=Core::Internationalization<br />
}}<br />
<br />
{{Module<br />
|name=ImageLib<br />
|description=<br />
|owner=[mailto:tnikkel@gmail.com Timothy Nikkel]<br />
|peers=[mailto:aosmond@mozilla.com Andrew Osmond], [mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:seth.bugzilla@blackhail.net Seth Fowler]<br />
|peersemeritus=[mailto:netzen@gmail.com Brian Bondy], [mailto:justin.lebar@gmail.com Justin Lebar]<br />
|group=dev-platform<br />
|source_dirs=media/libjpeg/, media/libpng/, image/, modules/zlib/<br />
|url=<br />
|components=Core::ImageLib<br />
}}<br />
<br />
{{Module<br />
|name=IPC<br />
|description=Message-passing between threads and processes<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:danderson@mozilla.com David Anderson], [mailto:kchen@mozilla.com Kan-Ru Chen], [mailto:jld@mozilla.com Jed Davis], [mailto:nfroyd@mozilla.com Nathan Froyd], [mailto:bkelly@mozilla.com Ben Kelly], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:btseng@mozilla.com Bevis Tseng]<br />
|peersemeritus=[mailto:wmccloskey@mozilla.com Bill McCloskey]<br />
|group=dev-platform<br />
|source_dirs=ipc/glue/, ipc/ipdl/, ipc/chromium/<br />
|url=<br />
|components=Core::IPC}}<br />
<br />
{{Module<br />
|name=JavaScript<br />
|description=JavaScript engine (SpiderMonkey)<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:jdemooij@mozilla.com Jan de Mooij], [mailto:nnethercote@mozilla.com Nick Nethercote], [mailto:jwalden@mit.edu Jeff Walden], [mailto:hv1989@gmail.com Hannes Verschore], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:evilpies@gmail.com Tom Schuster], [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:till@tillschneidereit.net Till Schneidereit], [mailto:efaust@mozilla.com Eric Faust], [mailto:nfitzgerald@mozilla.com Nick Fitzgerald], [mailto:luke@mozilla.com Luke Wagner], [mailto:arai.unmht@gmail.com Tooru Fujisawa], [mailto:sunfish@mozilla.com Dan Gohman], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:nmatsakis@mozilla.com Niko Matsakis], [mailto:ejpbruel@mozilla.com Eddy Bruel], [mailto:danderson@mozilla.com David Anderson], [mailto:igor@mir2.org Igor Bukanov], [mailto:brendan@mozilla.org Brendan Eich], Andreas Gal<br />
|peersemeritus=[mailto:wmccloskey@mozilla.com Bill McCloskey]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src<br />
|url=http://www.mozilla.org/js/spidermonkey,<br />
http://developer.mozilla.org/en/docs/About_JavaScript<br />
|components=Core::JavaScript Engine<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript JIT<br />
|description=JavaScript engine's JIT compilers (IonMonkey, Baseline)<br />
|owner=[mailto:jdemooij@mozilla.com Jan de Mooij]<br />
|peers=[mailto:danderson@mozilla.com David Anderson], [mailto:bbouvier@mozilla.com Benjamin Bouvier], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:nicolas.b.pierron@mozilla.com Nicolas Pierron], [mailto:evilpies@gmail.com Tom Schuster], [mailto:sstangl@mozilla.com Sean Stangl], [mailto:hv1989@gmail.com Hannes Verschore], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:luke@mozilla.com Luke Wagner]<br />
|group=dev-tech-js-engine-internals<br />
|source_dirs=js/src/jit<br />
|url=http://www.mozilla.org/js/spidermonkey<br />
|components=Core::JavaScript Engine: JIT<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript Debugger Backend<br />
|description=JavaScript debugging hooks<br />
|owner=[mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:rginda@hacksrus.com Rob Ginda]<br />
|group=dev-apps-js-debugger<br />
|source_dirs=js/jsd/<br />
|url=http://www.mozilla.org/js/jsd<br />
|components=Other Applications::Venkman JS Debugger<br />
}}<br />
<br />
{{Module<br />
|name=jsat<br />
|description=Javascript screen reader that is used in Android and B2G<br />
|owner=[mailto:eitan@monotonous.org Eitan Isaacson]<br />
|peers=[mailto:yzenevich@mozilla.com Yura Zenevich]<br />
|group=dev-accessibility<br />
|source_dirs=accessible/jsat/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=js-ctypes<br />
|description=A foreign function interface which allows privileged JS code to interact with binary code without using XPCOM/XPConnect.<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src/ctypes/<br />
|url=https://wiki.mozilla.org/JSctypes<br />
|components=Core::js-ctypes<br />
}}<br />
<br />
{{Module<br />
|name=js-tests<br />
|description=JavaScript test suite<br />
|owner=[mailto:bclary@bclary.com Bob Clary]<br />
|peers=<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tests/<br />
|url=http://www.mozilla.org/js/tests/library.html<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Layout Engine<br />
|description=rendering tree construction, layout (reflow), etc.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:jfkthame@gmail.com Jonathan Kew], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:matt.woodrow@gmail.com Matt Woodrow], [mailto:xidorn+moz@upsuper.org Xidorn Quan]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/%, layout/base/, layout/build/, layout/doc/, layout/forms/, layout/generic/, layout/html/, layout/printing/, layout/tables/, layout/tools/<br />
|url=http://mozilla.org/newlayout/doc/ ,<br />
http://lxr.mozilla.org/mozilla/source/layout/doc/<br />
|components=Core::Layout, Core::Layout: Block and Inline, Core::Layout: Floats, Core::Layout: Form Controls, Core::Layout: HTML Frames, Core::Layout: Images, Core::Layout: Misc Code, Core::Layout: R & A Pos, Core::Layout: Tables, Core::Layout: Text, Core::Print Preview, Core::Printing: Output<br />
}}<br />
<br />
{{Module<br />
|name=libjar<br />
|description=The JAR handling code (protocol handler, stream implementation, and zipreader/zipwriter).<br />
|owner=[mailto:mwu@mozilla.com Michael Wu]<br />
|peers=[mailto:aklotz@mozilla.com Aaron Klotz]<br />
|group=dev-platform<br />
|source_dirs=modules/libjar<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=MathML<br />
|description=MathML is a low-level specification for describing mathematics which provides a foundation for the inclusion of mathematical expressions in Web pages.<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|group=dev-tech-mathml<br />
|source_dirs=layout/mathml/<br />
|url=http://www.mozilla.org/projects/mathml/<br />
|components=Core::MathML<br />
}}<br />
<br />
{{Module<br />
|name=Media Playback<br />
|description=HTML Media APIs, including Media Source Extensions and non-MSE video/audio element playback, and Encrypted Media Extensions. (WebRTC and WebAudio not included).<br />
|owner=[mailto:jyavenard@mozilla.com Jean-Yves Avenard]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:cpearce@mozilla.com Chris Pearce]<br />
|peers=[mailto:ajones@mozilla.com Anthony Jones], [mailto:kinetik@flim.org Matthew Gregan], [mailto:eflores@mozilla.com Edwin Flores], [mailto:gsquelart@mozilla.com Gerald Squelart], [mailto:rgiles@mozilla.com Ralph Giles], [mailto:jwwang@mozilla.com JW Wang]<br />
|group=dev-media<br />
|source_dirs=dom/media, media/gmp-clearkey/, media/libcubeb/, media/libnestegg/, media/libogg/, media/libopus/, media/libstagefright/, media/libtheora/, media/libtremor/, media/libvorbis/, media/libvpx/, media/omx-plugin/, media/rlz/<br />
|url=<br />
|components=Core::Audio/Video<br />
}}<br />
<br />
{{Module<br />
|name=Media Transport<br />
|description=Pluggable transport for real-time media<br />
|owner=[mailto:ekr@rtfm.com Eric Rescorla]<br />
|peers=[mailto:bcampen@mozilla.com Byron Campen], [mailto:abr@mozilla.com Adam Roach], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]<br />
|group=dev-media<br />
|source_dirs=media/mtransport<br />
|url=<br />
|components=Core::WebRTC::Networking<br />
}}<br />
<br />
{{Module<br />
|name=Memory Allocator<br />
|description=Most things related to memory allocation in Gecko, including jemalloc, replace-malloc, DMD (dark matter detector), logalloc, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|peers=[mailto:n.nethercote@gmail.com Nicholas Nethercote], [mailto:erahm@mozilla.com Eric Rahm]<br />
|group=dev-platform<br />
|source_dirs=memory/<br />
|components=Core::DMD, Core::jemalloc<br />
}}<br />
<br />
{{Module<br />
|name=mfbt<br />
|description=mfbt is a collection of headers, macros, data structures, methods, and other functionality available for use and reuse throughout all Mozilla code (including SpiderMonkey and Gecko more broadly).<br />
|owner=[mailto:jwalden@mit.edu Jeff Walden]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd], [mailto:Ms2ger@gmail.com Ms2ger], [mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|group=dev-platform<br />
|source_dirs=mfbt/<br />
|url=<br />
|components=Core::MFBT<br />
}}<br />
<br />
{{Module<br />
|name=Mozglue<br />
|description=Glue library containing various low-level functionality, including a dynamic linker for Android, a DLL block list for Windows, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd] (mozglue/linker), [mailto:kgupta@mozilla.com Kartikaya Gupta] (mozglue/android), [mailto:nchen@mozilla.com Jim Chen] (mozglue/android)<br />
|group=dev-platform<br />
|source_dirs=mozglue/<br />
|components=Core::mozglue<br />
}}<br />
<br />
{{Module<br />
|name=mozilla-toplevel<br />
|description=The top level directory for the mozilla tree.<br />
|owner=[mailto:brendan@mozilla.org Brendan Eich]<br />
|peers=<br />
|group=<br />
|source_dirs=tools/README<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=MSCOM<br />
|description=Integration with Microsoft Distributed COM<br />
|owner=[mailto:aklotz@mozilla.com Aaron Klotz]<br />
|peers=[mailto:jteh@mozilla.com James Teh], [mailto:jmathies@mozilla.com Jim Mathies]<br />
|group=dev-platform<br />
|source_dirs=ipc/mscom/%<br />
|url=<br />
|components=Core::IPC: MSCOM}}<br />
<br />
{{Module<br />
|name=Necko<br />
|description=The Mozilla Networking Library<br />
|owner=[mailto:mcmanus@ducksong.com Patrick McManus]<br />
|peers= [mailto:jduell.mcbugs@gmail.com Jason Duell], [mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:mnovotny@mozilla.com Michal Novotny], [mailto:hurley@mozilla.com Nick Hurley], [mailto:dd.mozilla@gmail.com Dragana Damjanovic ],[mailto:valentin.gosu@gmail.com Valentin Gosu],[mailto:daniel@haxx.se Daniel Stenberg ], [mailto:schien@mozilla.com ShihChiang Chien]<br />
|peersemeritus= [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sworkman@mozilla.com Steve Workman], [mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|group=dev-tech-network<br />
|source_dirs=netwerk/%, netwerk/base/, netwerk/build/, netwerk/cache/, netwerk/dns/, netwerk/locales/, netwerk/mime/, netwerk/protocol/, netwerk/resources/, netwerk/socket/, netwerk/streamconv/, netwerk/system/, netwerk/test/, netwerk/testserver/<br />
|url=http://www.mozilla.org/projects/netlib/, https://developer.mozilla.org/en/Necko<br />
|components=Core::Networking, Core::Networking: Cache, Core::Networking: Cookies, Core::Networking: FTP, Core::Networking: File, Core::Networking: HTTP, Core::Networking: JAR, Core::Networking: Websockets<br />
}}<br />
<br />
{{Module<br />
|name=NSPR<br />
|description=Netscape Portable Runtime<br />
|owner=[mailto:kaie@kuix.de Kai Engert]<br />
|peers=[mailto:wtc@google.com Wan-Teh Chang], [mailto:mh@glandium.org Mike Hommey]<br />
|group=dev-tech-nspr<br />
|source_dirs=nsprpub/<br />
|url=http://www.mozilla.org/projects/nspr/<br />
http://www.mozilla.org/projects/nspr/reference/html/<br />
http://www.mozilla.org/projects/nspr/release-notes/<br />
|components=NSPR<br />
}}<br />
<br />
{{Module<br />
|name=PDF<br />
|description=Rendering code to display documents encoded in the ISO 32000-1 `PDF' format.<br />
|owner=Chris Jones, Andreas Gal<br />
|peers=[mailto:aadib@mozilla.com Artur Adib], [mailto:bdahl@mozilla.com Brendan Dahl], [mailto:vnicolas@mozilla.com Vivien Nicolas]<br />
|group=dev-platform<br />
|source_dirs=media/pdf/<br />
|url=https://github.com/mozilla/pdf.js<br />
|components=Core::PDF<br />
}}<br />
<br />
{{Module<br />
|name=Plugins<br />
|description= NPAPI Plugin support.<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:joshmoz@gmail.com Josh Aas]<br />
|peersemeritus=[mailto:john@pointysoftware.net John Schoenick], [mailto:robert@ocallahan.org Robert O'Callahan], [mailto:jstenback@gmail.com Johnny Stenback], Benjamin Smedberg<br />
|group=<br />
|source_dirs=dom/plugins/, modules/plugin/<br />
|url=https://wiki.mozilla.org/Plugins<br />
|components=Core::Plug-ins<br />
}}<br />
<br />
{{Module<br />
|name=Preferences<br />
|description=Preference library<br />
|owner=[mailto:nnethercote@mozilla.com Nicholas Nethercote]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd], [mailto:felipe@mozilla.com Felipe Gomes], [mailto:glandium@mozilla.com Mike Hommey], [mailto:erahm@mozilla.com Eric Rahm]<br />
|group=dev-platform<br />
|source_dirs=modules/libpref/<br />
|url=<br />
|components=Core::Preferences: Backend<br />
}}<br />
<br />
{{Module<br />
|name=Private Browsing<br />
|description=Implementation of the Private Browsing mode, and the integration of other modules with Private Browsing APIs.<br />
|owner=[mailto:josh@joshmatthews.net Josh Matthews] (while Ehsan is away)<br />
|peers=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|group=dev-platform<br />
|source_dirs=Implementation and consumers of Private Browsing APIs in nsILoadContext, nsIPrivateBrowsingChannel, PrivateBrowsingUtils.jsm and the related glue code. <br />
|url=https://wiki.mozilla.org/Private_Browsing<br />
|components=Firefox::Private Browsing<br />
}}<br />
<br />
{{Module<br />
|name=Privilege Manager<br />
|description="caps"<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|peersemeritus=[mailto:brendan@mozilla.org Brendan Eich], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:dveditz@mozilla.com Dan Veditz]<br />
|group=dev-tech-dom<br />
|source_dirs=caps/<br />
|url=http://www.mozilla.org/projects/security/components/index.html<br />
|components=Core::Security: CAPS<br />
}}<br />
<br />
{{Module<br />
|name=Push Notifications<br />
|description=Push is a way for application developers to send messages to their web applications.<br />
|owners=<br />
|ownersemeritus=[mailto:doug.turner@gmail.com Doug Turner]<br />
|peers=[mailto:nsm.nikhil@gmail.com Nikhil Marathe], [mailto:kcambridge@mozilla.com Kit Cambridge], [mailto:martin.thomson@gmail.com Martin Thomson], [mailto:ddamjanovic@mozilla.com Dragana Damjanovic]<br />
|group=<br />
|source_dirs=dom/push, dom/simplepush<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=PyXPCOM<br />
|description=The Python to XPCOM bridge.<br />
|owner=Todd Whiteman<br />
|peers=[mailto:mhammond@skippinet.com.au Mark Hammond]<br />
|group=<br />
|source_dirs=extension/python<br />
|url=https://developer.mozilla.org/en/PyXPCOM<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=RDF<br />
|description=<br />
|owner=[mailto:axel@pike.org Axel Hecht]<br />
|peers=<br />
|group=dev-tech-rdf<br />
|source_dirs=rdf/<br />
|url=http://www.mozilla.org/rdf/doc/<br />
|components=Core::RDF<br />
}}<br />
<br />
{{Module<br />
|name=security<br />
|description=Crypto/PKI code, including NSS (Network Security Services) and JSS (NSS for Java)<br />
|owner=[mailto:rrelyea@redhat.com Bob Relyea], [mailto:ttaubert@mozilla.com Tim Taubert]<br />
|peers=[mailto:kaie@kuix.de Kai Engert], [mailto:ryan.sleevi@gmail.com Ryan Sleevi], [mailto:ekr@rtfm.com Eric Rescorla], [mailto:franziskuskiefer@gmail.com Franziskus Kiefer], [mailto:martin.thomson@gmail.com Martin Thomson], [mailto:wtc@google.com Wan-Teh Chang], [mailto:dueno@redhat.com Daiki Ueno]<br />
|peersemeritus=[mailto:emaldona@redhat.com Elio Maldonado]<br />
|group=dev-tech-crypto<br />
|source_dirs=dbm/, security/coreconf/, security/dbm/, security/jss/, security/nss/, security/tinderbox/, security/tinderlight/<br />
|url=http://mozilla.org/projects/security/pki/<br />
|components=NSS, JSS, Core::Security, Core::Security: S/MIME<br />
}}<br />
<br />
{{Module<br />
|name=Security - Mozilla PSM Glue<br />
|description=Personal Security Manager<br />
|owner=[mailto:dkeeler@mozilla.com David Keeler]<br />
|ownersemeritus=[mailto:kaie@kuix.de Kai Engert (2001-2012)]<br />
|peers=[mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:cykesiopka.bmo@gmail.com Cykesiopka]<br />
|group=dev-tech-crypto<br />
|source_dirs=security/manager/<br />
|url=<br />
|components=Core::Security: PSM<br />
}}<br />
<br />
{{Module<br />
|name=Static analysis & rewriting for C++<br />
|description=Tools for checking C++ code looking for problems at compile time, plus tools for automated rewriting of C++ code.<br />
|owner=[mailto:nika@thelayzells.com Nika Layzell] (while Ehsan is away)<br />
|peers=[mailto:sfink@mozilla.com Steve Fink], [mailto:jrmuizel@mozilla.com Jeff Muizelaar], [mailto:birunthan@mohanathas.com Birunthan Mohanathas], [mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|group=dev-platform<br />
|source_dirs=build/clang-plugin, tools/rewriting among other out of tree tools<br />
|url=<br />
|components=Core::Rewriting & Analysis<br />
}}<br />
{{Module<br />
|name=storage<br />
|description=Storage APIs with a SQLite backend<br />
|owner=[mailto:mak77@bonardo.net Marco Bonardo]<br />
|peers=[mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:jvarga@mozilla.com Jan Varga]<br />
|group=dev-platform<br />
|source_dirs=db/sqlite3/, storage/<br />
|url=http://developer.mozilla.org/en/docs/Storage<br />
|components=Toolkit::Storage, Core::SQL<br />
}}<br />
<br />
{{Module<br />
|name=String<br />
|description=<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd], [mailto:erahm@mozilla.com Eric Rahm]<br />
|group=dev-tech-xpcom<br />
|source_dirs=string/, xpcom/string/<br />
|url=https://developer.mozilla.org/En/Mozilla_internal_string_guide<br />
|components=Core::String<br />
}}<br />
<br />
{{Module<br />
|name=Style System<br />
|description=CSS style sheet handling; style data computation<br />
|owner= [mailto:cam@mcc.id.au Cameron McCormack]<br />
|peers=[mailto:dbaron@dbaron.org David Baron], [mailto:emilio@crisal.io Emilio Cobos Álvarez], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:xidorn+moz@upsuper.org Xidorn Quan], [mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/style/<br />
|url=https://wiki.mozilla.org/Gecko:Overview#Style_System<br />
|components=Core::CSS Parsing and Computation<br />
}}<br />
<br />
{{Module<br />
|name=SVG<br />
|description=Scalable Vector Graphics<br />
|owner=[mailto:jwatt@jwatt.org Jonathan Watt]<br />
|peers=[mailto:longsonr@gmail.com Robert Longson], [mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:birtles@gmail.com Brian Birtles]<br />
|group=dev-tech-svg<br />
|source_dirs=dom/svg/, layout/svg/, dom/smil/<br />
|url=https://developer.mozilla.org/en-US/docs/Web/SVG<br />
|components=Core::SVG<br />
}}<br />
<br />
{{Module<br />
|name=Tamarin<br />
|description=VM for ActionScript and JavaScript<br />
|owner=Edwin Smith, [mailto:jodyer@adobe.com Jeff Dyer]<br />
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:stejohns@adobe.com Steven Johnson], [mailto:tierney@adobe.com Erik Tierney], [mailto:treilly@adobe.com Tom Reilly]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tamarin<br />
|url=http://www.mozilla.org/projects/tamarin/<br />
http://wiki.mozilla.org/tamarin/<br />
http://hg.mozilla.org/tamarin-central/<br />
http://hg.mozilla.org/tamarin-tracing/<br />
|components=Tamarin<br />
}}<br />
<br />
{{Module<br />
|name=Test Harness<br />
|description=In-tree test infrastructure and tools. Harnesses include, XPCShell, Mochitest (& Chrome), Reftest, JsREftest, Compiled Code Tests, Robocop, Mozmill, Marionette, Firefox UI Tests. Requests for new harnesses should go to Testing::General.<br />
|owner=[mailto:ted@mielczarek.org Ted Mielczarek]<br />
|peers=[mailto:dbaron@dbaron.org David Baron] (reftest), [mailto:jwalden@mit.edu Jeff Walden] (httpd.js, jsreftest), Rob Campbell (mochitest, mochitest chrome, marionette), [mailto:jmaher@mozilla.com Joel Maher] (reftest, mochitest, jsreftest), [mailto:ctalbert@mozilla.com Clint Talbert] (reftest, compiled code, mozmill), [mailto:geoffbrown@mozilla.com Geoff Brown] (robocop), [mailto:hskupin@mozilla.com Henrik Skupin] (Marionette, Firefox UI tests), [mailto:ato@mozilla.com Andreas Tolfsen] (marionette), [mailto:jgriffin Jonathan Griffin] (marionette), [mailto:dburns@mozilla.com David Burns] (marionette), [mailto:dminor@mozilla.com Dan Minor], [mailto:mjzffr@gmail.com Maja Frydrychowicz] (Marionette, Firefox UI tests), <br />
<br />
|group=dev-quality<br />
|source_dirs=/testing<br />
|url=http://wiki.mozilla.org/SoftwareTesting<br />
|components=Testing::General, Testing::Mochitest, Testing::Mochitest Chrome, Testing::Marionette, Testing::Mozmill, Testing::Reftest, Testing::XPCShell Harness, Testing::httpd.js<br />
}}<br />
<br />
{{Module<br />
|name=Testing Infrastructure<br />
|description=Testing tools and infrastructure for Mozilla projects, harnesses for automated tests, stand-alone test tools. Talos, Graph Server, Mozbase, Pulse, WOO, Bughunter, SUTAgent, Eideticker<br />
|owner=[mailto:jmaher@mozilla.com Joel Maher]<br />
|peers=[mailto:bclary@bclary.com Bob Clary], [mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:ccooper@deadsquid.com Chris Cooper], [mailto:ctalbert@mozilla.com Clint Talbert], [mailto:robert@roberthelmer.com Robert Helmer], [mailto:jmaher@mozilla.com Joel Maher], Rob Campbell, [mailto:wlach@mozilla.com William Lachance], [mailto:jeads@mozilla.com Jonathan Eads], [mailto:jgriffin Jonathan Griffin], [mailto:bmoss@mozilla.com Bob Moss], [mailto:mcote@mozilla.com Mark Côté]<br />
|group=dev-quality<br />
|source_dirs=testing/, tools/httptester/, tools/page-loader/, tools/test-harness/, tools/tests/, tools/testserver/, tools/testy/<br />
|url=http://wiki.mozilla.org/SoftwareTesting<br />
|components=Testing::Infrastructure<br />
}}<br />
<br />
{{Module<br />
|name=JS Marionette<br />
|description=NodeJS test harness, marionette client, and other utilities for running marionette tests (submodule of Test Infrastructure)<br />
|owner=[mailto:jlal@mozilla.com James Lal] <lightsofapollo>, [mailto:gaye@mozilla.com Gareth Aye] <gaye><br />
|peers=[mailto:aus@mozilla.com Ghislain "Aus" Lacroix] <auswerk><br />
|source_dirs=gaia/tests/jsmarionette<br />
|components=Testing::JSMarionette<br />
|group=dev-gaia<br />
}}<br />
<br />
{{Module<br />
|name=XPCShell Test Harness<br />
|description=The XPCShell Harness<br />
|owner=[mailto:ted@mielczarek.org Ted Mielczarek]<br />
|peers=[mailto:jmaher@mozilla.com Joel Maher]<br />
|source_dirs=testing/xpcshell<br />
|components=Testing::XPCShell Harness<br />
}}<br />
<br />
{{Module<br />
|name=Update Service<br />
|description=server code for Mozilla Update services (aus, addons, pfs)<br />
|owner=Mike Morgan<br />
|peers=[mailto:jscott@mozilla.com Justin Scott], [mailto:shaver@mozilla.org Mike Shaver], [mailto:wclouser@mozilla.com Will Clouser]<br />
|group=dev-amo<br />
|source_dirs=webtools/addons/, webtools/aus/, webtools/update/<br />
|url=http://wiki.mozilla.org/wiki/AMO<br />
|components=AUS::Administration, AUS::Systems<br />
}}<br />
<br />
{{Module<br />
|name=View System<br />
|description=The View Manager is responsible for handling "heavyweight" rendering (some clipping, compositing) and event handling tasks.<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron]<br />
|group=dev-tech-layout<br />
|source_dirs=view/<br />
|url=<br />
|components=Core::Layout: View Rendering<br />
}}<br />
<br />
{{Module<br />
|name=Web Audio<br />
|description=Support for the W3C Web Audio API specification.<br />
|owner=[mailto:padenot@mozilla.com Paul Adenot]<br />
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:karlt+@karlt.net Karl Tomlinson]<br />
|group=dev-platform<br />
|source_dirs=dom/media/webaudio<br />
|url=https://wiki.mozilla.org/Web_Audio_API<br />
|components=Core::Web Audio<br />
}}<br />
<br />
{{Module<br />
|name=Web Painting<br />
|description=painting, display lists, and layer construction<br />
|owner=[mailto:matt.woodrow@gmail.com Matt Woodrow]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dbaron@dbaron.org David Baron], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:mstange@themasta.com Markus Stange]<br />
|group=dev-tech-layout<br />
|source_dirs= layout/painting, the display list and layer related methods on nsIFrame and its subclasses<br />
|url=http://mozilla.org/newlayout/doc/ ,<br />
http://lxr.mozilla.org/mozilla/source/layout/doc/<br />
|components=Core::Layout: Web Painting<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC<br />
|description=WebRTC is responsible for realtime audio and video communication, as well as related issues like low-level camera and microphone access<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:bcampen@mozilla.com Byron Campen] [mailto:abr@mozilla.com Adam Roach]<br />
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=netwerk/sctp (also see submodules "WebRTC Media" and "WebRTC Signaling")<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC, Core::WebRTC Networking<br />
}}<br />
<br />
{{Module<br />
|name=WebVR<br />
|description=Gecko's implementation of WebVR (Virtual Reality) functionality, including API, devices, graphics and integration<br />
|owner=[mailto:kgilbert@mozilla.com Kip Gilbert]<br />
|peers=[mailto:dmu@mozilla.com Daosheng Mu]<br />
|peersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|group=dev-platform<br />
|source_dirs=dom/vr, gfx/vr<br />
|url=https://mozvr.com/<br />
|components=Core::WebVR<br />
}}<br />
<br />
{{Module<br />
|name=Widget<br />
|description=<br />
|owner=[mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peersemeritus=[mailto:pavlov@pavlov.net Stuart Parmenter], <br />
|group=dev-platform<br />
|source_dirs=widget/, widget/xpwidgets/<br />
|url=<br />
|components=Core::Drag and Drop, Core::Widget, Core::Printing: Setup<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Android<br />
|description=The Android Port<br />
|owner=[mailto:blassey.bugs@lassey.us Brad Lassey]<br />
|peers=[mailto:jwillcox@mozilla.com James Willcox]<br />
|group=dev-platforms-mobile<br />
|source_dirs=widget/android/, embedding/android<br />
|url=<br />
|components=Core::Widget: Android<br />
}}<br />
<br />
{{Module<br />
|name=Widget - GTK<br />
|description=supported X widgetry and gfx<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|group=dev-platform<br />
|source_dirs=widget/gtk/, widget/gtk2/, widget/gtksuperwin/, widget/gtkxtbin/<br />
|url=http://www.mozilla.org/unix/, http://www.gtk.org, http://www.mozilla.org/ports/gtk/<br />
|components=Core::Widget: Gtk<br />
}}<br />
<br />
{{Module<br />
|name=Widget - OS X<br />
|description= Gecko's OS X compatibility layer.<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|peers=[mailto:joshmoz@gmail.com Josh Aas], [mailto:bgirard@mozilla.com Benoit Girard], [mailto:spohl@mozilla.com Stephen Pohl], [mailto:smichaud@pobox.com Steven Michaud]<br />
|group=dev-platform<br />
|source_dirs=widget/cocoa/<br />
|url=<br />
|components=Core::Widget: Cocoa<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Windows<br />
|description=Windows widgets and desktop integration<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook], [mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:jmathies@mozilla.com Jim Mathies]<br />
|peersemeritus=[mailto:blassey@mozilla.com Brad Lassey], [mailto:netzen@gmail.com Brian Bondy], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:doug.turner@gmail.com Doug Turner], [mailto:timeless@mozdev.org Josh 'timeless' Soref], [mailto:robarnold@cmu.edu Rob Arnold]<br />
|group=dev-platform<br />
|source_dirs=widget/windows/<br />
|url=<br />
|components=Core::Widget: Win32<br />
}}<br />
<br />
{{Module<br />
|name=XBL<br />
|description=eXtensible Binding Language<br />
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|peers=[mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:jonas@sicking.cc Jonas Sicking]<br />
|ownersemeritus=[mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-tech-xbl<br />
|source_dirs=dom/xbl/<br />
|url=http://www.mozilla.org/projects/xbl/<br />
|components=Core::XBL<br />
}}<br />
<br />
{{Module<br />
|name=XML<br />
|description=XML in Mozilla, including XML, XHTML, Namespaces in XML, Associating Style Sheets with XML Documents, XML Linking and XML Extras. XML-related things that are not covered by more specific projects.<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:erahm@mozilla.com Eric Rahm]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:jstenback@gmail.com Johnny Stenback]<br />
|group=dev-tech-xml<br />
|source_dirs=dom/xml/, extensions/xmlextras/, parser/expat/<br />
|url=http://www.mozilla.org/newlayout/xml/<br />
|components=Core::XML<br />
}}<br />
<br />
{{Module<br />
|name=XPApps<br />
|description=Cross-Platform Applications, mostly Navigator front end and application shell.<br />
|owner=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|peers=[mailto:dean_tessman@hotmail.com Dean Tessman], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-apps-seamonkey<br />
|source_dirs=xpfe/<br />
|url=http://www.mozilla.org/xpapps/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPCOM<br />
|description=The cross-platform object model and core data structures.<br />
|owner=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd]<br />
|peers=[mailto:erahm@mozilla.com Eric Rahm]<br />
|ownersemeritus=Benjamin Smedberg<br />
|peersemeritus=[https://mozillians.org/en-US/u/dougt/ Doug Turner]<br />
|group=dev-platform<br />
|source_dirs=startupcache/, xpcom/%, xpcom/base/, xpcom/build/, xpcom/components/, xpcom/ds/, xpcom/glue/, xpcom/proxy/, xpcom/sample/, xpcom/stub/, xpcom/tests/, xpcom/threads/, xpcom/tools/, xpcom/windbgdlg/<br />
|url=http://developer.mozilla.org/en/XPCOM<br />
|components=Core::XPCOM<br />
}}<br />
<br />
{{Module<br />
|name=XPConnect<br />
|description=Deep Magic<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:gkrizsanits@mozilla.com Gabor Krizsanits], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:kmaglione@mozilla.com Kris Maglione]<br />
|peersemeritus=[mailto:gal@uci.edu Andreas Gal], [mailto:jstenback@gmail.com Johnny Stenback]<br />
|group=<br />
|source_dirs=js/xpconnect/<br />
|url=<br />
|components=Core::XPConnect<br />
}}<br />
<br />
{{Module<br />
|name=XPIDL<br />
|description=Cross-platform IDL compiler; produces .h C++ header files and .xpt runtime type description files from .idl interface description files.<br />
|owner=[mailto:me@kylehuey.com Kyle Huey]<br />
|peersemeritus=[mailto:shaver@mozilla.org Mike Shaver], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-tech-xpcom<br />
|source_dirs=xpcom/typelib/<br />
|url=http://www.mozilla.org/scriptable/xpidl<br />
http://www.mozilla.org/scriptable<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPInstall<br />
|description=<br />
|owner=[mailto:dveditz@mozilla.com Dan Veditz]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|group=dev-tech-xpinstall<br />
|source_dirs=xpinstall/<br />
|url=<br />
|components=Core::Installer: XPInstall Engine<br />
}}<br />
<br />
{{Module<br />
|name=XPToolkit<br />
|description=Cross-platform user interface toolkit<br />
|owner=<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:Jan.Varga@gmail.com Jan Varga]<br />
|group=dev-tech-xul<br />
|source_dirs=dom/xul/, layout/xul/<br />
|url=http://www.mozilla.org/xpfe/<br />
|components=Core::XP Toolkit/Widgets: Menus, Core::XP Toolkit/Widgets: XUL<br />
}}<br />
<br />
{{Module<br />
|name=XSLT Processor<br />
|description=XSLT transformations processor<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:axel@pike.org Axel Hecht], [mailto:erahm@mozilla.com Eric Rahm]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-tech-xslt<br />
|source_dirs=dom/xslt/<br />
|url=http://www.mozilla.org/projects/xslt/, http://www.w3.org/TR/xslt.html<br />
|components=Core::XSLT<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Windows <br />
|description=Sandboxing for the Windows platform <br />
|owner=[mailto:bobowencode@gmail.com Bob Owen] (:bobowen)<br />
|peers=[mailto:aklotz@mozilla.com Aaron Klotz] (:aklotz), [mailto:jimm@mozilla.com Jim Mathies] (:jimm), [mailto:davidp99@gmail.com David Parks] (:handyman)<br />
|ownersemeritus=[https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes]<br />
|peersemeritus=[mailto:netzen@gmail.com Brian Bondy]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/win <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - OSX <br />
|description=Sandboxing for the OSX platform <br />
|owner=[mailto:haftandilian@mozilla.com Haik Aftandilian]<br />
|peers=<br />
|group=dev-platform <br />
|source_dirs=security/sandbox/mac <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Linux<br />
|description=Sandboxing for the Linux platform<br />
|owner=[mailto:jld@mozilla.com Jed Davis]<br />
|peers=[mailto:gcp@mozilla.com Gian-Carlo Pascutto]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/linux<br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
===Submodules===<br />
{{Module<br />
|name=Build Config - Fennec<br />
|description=Submodule of the build config covering Fennec's build system in mobile/android.<br />
|owner=[mailto:nalexander@mozilla.com Nicholas Alexander]<br />
|peers=Same as Build Config<br />
|group=dev-builds<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=Build Config - Taskgraph<br />
|description=Support for task-graph generation in decision, action, and cron tasks, including configuration of all tasks including those for CI, nightlies, and releases; as well as Docker and VM images used to execute those tasks.<br />
|owner=[mailto:dustin@mozilla.com Dustin Mitchell]<br />
|peers=[mailto:ahal@mozilla.com Andrew Halberstadt], [mailto:aki@mozilla.com Aki Sasaki], [mailto:bstack@mozilla.com Brian Stack], [mailto:mh@glandium.org Mike Hommey], [mailto:gps@mozilla.com Gregory Szorc], [mailto:jmaher@mozilla.com Joel Maher], [mailto:callek@mozilla.com Justin Wood]<br />
|components=Taskcluster::Task Configuration<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC Media<br />
|description=Submodule of WebRTC responsible for access to media input devices (microphones, cameras, screen capture), as well as realtime audiovisual codecs and packetization.<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:jib@mozilla.com Jan-Ivar Bruaroey], [mailto:dminor@mozilla.com Dan Minor], [mailto:apehrson@mozilla.com Andreas Pehrson], <br />
|peersemeritus=[mailto:pkerr@mozilla.com Paul Kerr], [mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=/media/webrtc, /dom/media/webrtc, /dom/media/systemservices<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC (Audio/Video)<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC Signaling<br />
|description=Submodule of WebRTC responsible for implementation of PeerConnection API, WebRTC identity, and SDP/JSEP handling<br />
|owner=[mailto:bcampen@mozilla.com Byron Campen]<br />
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:abr@mozilla.com Adam Roach], [mailto:rjesup@mozilla.com Randell Jesup], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]<br />
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=/media/webrtc/signaling/<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC (Signaling)<br />
}}<br />
<br />
<br />
<noinclude><br />
<br />
===Unassigned Bugzilla Components===<br />
<br />
The following Bugzilla components in the Core project have not been assigned to a module (this list is not exhaustive):<br />
<br />
<pre><br />
Core::Find Backend<br />
Core::General<br />
Core::HTML: Form Submission<br />
Core::History: Global<br />
Core::Image Blocking<br />
Core::Localization<br />
Core::Networking: Domain Lists<br />
Core::Selection<br />
Core::Serializers<br />
Core::Spelling checker<br />
Core::X-remote<br />
Core::XUL<br />
</pre><br />
</noinclude></div>Dkeelerhttps://wiki.mozilla.org/index.php?title=Modules/Core&diff=1192490Modules/Core2018-04-17T23:39:02Z<p>Dkeeler: add Kai Engert to PSM owners emeritus section</p>
<hr />
<div><noinclude><br />
'''Only module owners may edit this page.''' <br />
<br />
They may:<br />
<br />
* update any information about their module except the name of the owner<br />
* add or remove sub-modules<br />
* change the owner of a sub-module <br />
* add emeritus owners or peers<br />
<br />
Other changes, including changes of module owner or addition/removal of modules, must be agreed with the Module Ownership Module group, probably via a discussion in [https://www.mozilla.org/about/forums/#governance mozilla.governance].<br />
</noinclude><br />
{{Module<br />
|name=Accessibility<br />
|description=Support for platform accessibility APIs. Accessibility APIs are used by 3rd party software like screen readers, screen magnifiers, and voice dictation software, which need information about document content and UI controls, as well as important events like changes of focus.<br />
|owner=[mailto:surkov.alexander@gmail.com Alexander Surkov]<br />
|peers=[mailto:dbolter@mozilla.com David Bolter], [mailto:eitan@monotonous.org Eitan Isaacson], [mailto:jteh@mozilla.com James Teh], [mailto:mzehe@mozilla.com Marco Zehe], [mailto:yzenevich@mozilla.com Yura Zenevich]<br />
|ownersemeritus=[mailto:aaron@moonset.net. Aaron Leventhal]<br />
|peersemeritus=[mailto:tbsaunde+mozbugs@tbsaunde.org Trevor Saunders], [mailto:ginn.chen@oracle.com Ginn Chen], Evan Yan<br />
|group=dev-accessibility<br />
|source_dirs=accessible/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=Animation<br />
|description=Declarative animations: CSS animations, CSS transitions, Web Animations API, and off-main thread animations.<br />
|owner=[mailto:bbirtles@mozilla.com Brian Birtles] (:birtles)<br />
|peers=[mailto:hiro@mozilla.com Hiroyuki Ikezoe] (:hiro), [mailto:mwoodrow@mozilla.com Matt Woodrow] (:mattwoodrow)<br />
|group=dev-tech-layout<br />
|source_dirs=dom/animation; and animation-related and interpolation-related code in layout/style, gfx/layers, servo/components/style and servo/ports/gecko<br />
|components=Core::DOM::Animation, Core::CSS Parsing and Computation (for CSS animations/transitions related bugs)<br />
}}<br />
<br />
{{Module<br />
|name=Browser WebAPI<br />
|description=Web API for rendering apps, browser windows and widgets.<br />
|owner=[mailto:kchen@mozilla.com Kan-Ru Chen]<br />
|peers=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:fabrice@mozilla.com Fabrice Desré]<br />
|group=dev-webapi<br />
|source_dirs=dom/browser-element/<br />
|url=<br />
|components=Core::DOM<br />
}}<br />
<br />
{{Module<br />
|name=Build and Release Tools<br />
|description=Tools related to build and release automation and configuration of release builds.<br />
|owner=[mailto:nthomas@mozilla.com Nick Thomas]<br />
|peers=[mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:coop@mozilla.com Chris Cooper]<br />
|group=release-engineering<br />
|source_dirs=browser/config/mozconfigs/, mobile/android/config/mozconfigs/, xulrunner/config/mozconfigs/, b2g/config/, tools/update-packaging/<br />
|url=https://wiki.mozilla.org/ReleaseEngineering<br />
|components=Release Engineering::*<br />
}}<br />
<br />
{{Module<br />
|name=Build Config<br />
|description=The build system for Gecko and several mozilla.org hosted Gecko-based applications.<br />
|owner=[mailto:gps@mozilla.com Gregory Szorc] (:gps)<br />
|peers=[mailto:mh@glandium.org Mike Hommey] (:glandium), [mailto:mshal@mozilla.com Mike Shal] (:mshal), [mailto:ted@mielczarek.org Ted Mielczarek] (:ted), [mailto:cmanchester@mozilla.com Chris Manchester](:chmanchester), [mailto:nfroyd@mozilla.com Nathan Froyd] (:froydnj), [mailto:rgiles@mozilla.com Ralph Giles] (:rillian)<br />
|ownersemeritus=Ted Mielczarek (2008-[https://blog.mozilla.org/ted/2013/03/07/gregory-szorc-is-now-the-build-config-module-owner/ 2013]), Benjamin Smedberg (???-[http://benjamin.smedbergs.us/blog/2008-04-30/more-changing-of-the-guard-ted-mielczarek/ 2008]), <br />
|group=dev-builds<br />
|source_dirs=build/, config/, python/mozbuild, tools/cross-commit, tools/cvs2hg-import.py, tools/cvsmgmt/, tools/elf-dynstr-gc/, tools/trees.pl, browser/config/mozconfigs/, mobile/config/mozconfigs/, xulrunner/config/mozconfigs/<br />
|url=http://www.mozilla.org/build/<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=Code Analysis and Debugging Tools<br />
|description=Tools for debugging Mozilla code or for analyzing speed, memory use, and other characteristics of it.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=<br />
|group=dev-performance<br />
|source_dirs=tools/codesighs/, tools/debug/, tools/dreftool/, tools/dumpdeps/, tools/footprint/, tools/jprof/, tools/leaky/, tools/memory/, tools/module-deps/, tools/performance/, tools/post_compile/, tools/preloader/, tools/rb/, tools/reorder/, tools/trace-malloc/, tools/uuiddeps/, <br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Content HTTP Headers<br />
|description=HTTP headers related to content, e.g. User-Agent, Content-Type, Accept. (Transport-related headers are the responsibility of the Necko module owner.)<br />
|owner=[mailto:gerv@mozilla.org Gervase Markham]<br />
|peers=[mailto:lmandel@mozilla.com Lawrence Mandel]<br />
|group=dev-platform<br />
|source_dirs= <br />
|url=https://developer.mozilla.org/en/Gecko_user_agent_string_reference<br />
|components=Core::Networking: HTTP<br />
}}<br />
<br />
{{Module<br />
|name=Content Security<br />
|description=Native content-based security features, including: Content Security Policy (CSP), Mixed Content Blocker (MCB), Subresource Integrity (SRI) and CORS.<br />
|owner=[mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]<br />
|peers=[mailto:francois@mozilla.com François Marier], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:tvyas@mozilla.com Tanvi Vyas], [mailto:dveditz@mozilla.com Dan Veditz], [mailto:mozilla@sidstamm.com Sid Stamm] <br />
|group=dev-security<br />
|source_dirs=dom/security<br />
|components=Core::DOM: Security<br />
}}<br />
<br />
{{Module<br />
|name=Cookies and Permissions<br />
|description=<br />
|owner=Monica Chew<br />
|peers=[mailto:josh@joshmatthews.com Josh Matthews], [mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dwitte@gmail.com Dan Witte], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)]<br />
|group=dev-tech-network<br />
|source_dirs=extensions/cookie/, netwerk/cookie/<br />
|url=<br />
|components=Core::Networking: Cookies<br />
}}<br />
{{Module<br />
|name=Cycle Collector<br />
|description=Code to break and collect objects within reference cycles<br />
|owner=[https://mozillians.org/en-US/u/mccr8/ Andrew McCreight]<br />
|peers=Peter Van der Beken, Olli Pettay, David Baron<br />
|source_dirs=xpcom/base/nsCycleCollector.* and some support headers<br />
|components=Core::XPCOM<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=C++/Rust usage, tools, and style<br />
|description=Aspects of C++ use such as language feature usage, standard library versions/usage, compiler/toolchain versions, formatting and naming style, and aspects of Rust use as needs arise<br />
|owner=[mailto:nfroyd@mozilla.com Nathan Froyd] (while Ehsan is away)<br />
|peers=[mailto:bballo@mozilla.com Botond Ballo], [mailto:glandium@mozilla.com Mike Hommey], [mailto:jwalden@mozilla.com Jeff Walden], [mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|source_dirs=non-third-party C++ and Rust code in the tree<br />
|components=Various components<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=docshell<br />
|description=<br />
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|peers=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:sawang@mozilla.com Samael Wang]<br />
|peersemeritus=[mailto:jstenback@gmail.com Johnny Stenback],[mailto:cbiesinger@gmail.com Christian Biesinger],[mailto:justin.lebar@gmail.com Justin Lebar]<br />
|group=dev-platform<br />
|source_dirs=docshell/, uriloader/<br />
|url=<br />
|components=Core::Document Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Document Object Model<br />
|description=<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:hsivonen@iki.fi Henri Sivonen], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:baku@mozilla.com Andrea Marchesini],<br />
[mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:bkelly@mozilla.com Ben Kelly], [mailto:kyle@nonpolynomial.com Kyle Machulis], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:nika@thelayzells.com Nika Layzell]<br />
|ownersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]<br />
|peersemeritus=[mailto:justin.lebar@gmail.com Justin Lebar], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:bent.mozilla@gmail.com Ben Turner], [mailto:mounir@lamouri.fr Mounir Lamouri (still active, but slower to respond than previously)], [mailto:me@kylehuey.com Kyle Huey], [mailto:wmccloskey@mozilla.com Bill McCloskey]<br />
|group=dev-tech-dom<br />
|source_dirs=dom/*, except directories covered by other modules<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM, Core::DOM: CSS Object Model, Core::DOM: Core & HTML<br />
}}<br />
<br />
{{Module<br />
|name=DOM File<br />
|description=DOM Blob, File and FileSystem APIs <br />
|owner=[mailto:amarchesini@Mozilla.com Andrea Marchesini]<br />
|peers=[mailto:olli@pettay.fi Olli Pettay]<br />
|group=dev-platform<br />
|source_dirs=dom/file, dom/filesystem<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM: File<br />
}}<br />
<br />
{{Module<br />
|name=Event Handling<br />
|description=DOM Events and Event Handling <br />
|owner=[mailto:olli@pettay.fi Olli Pettay], [mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:sshih@mozilla.com Stone Shih]<br />
|group=dev-platform<br />
|source_dirs=dom/events and event handling related code elsewhere <br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM: Events, Core::Event Handling<br />
}}<br />
<br />
{{Module<br />
|name=Web Workers<br />
|description=<br />
|owner=[mailto:baku@mozilla.com Andrea Marchesini]<br />
|peers=[mailto:mrbkap@mozilla.com Blake Kaplan], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey], [mailto:bkelly@mozilla.com Ben Kelly]<br />
|ownersemeritus=[mailto:bent.mozilla@gmail.com Ben Turner]<br />
|group=dev-platform<br />
|source_dirs=dom/workers/<br />
|url=https://developer.mozilla.org/En/Using_web_workers<br />
|components=Core::DOM: Workers<br />
}}<br />
<br />
{{Module<br />
|name=IndexedDB<br />
|description=<br />
|owner=[mailto:jvarga@mozilla.com Jan Varga]<br />
|peers=[mailto:btseng@mozilla.com Bevis Tseng], [mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:baku@mozilla.com Andrea Marchesini]<br />
|ownersemeritus=[mailto:bent.mozilla@gmail.com Ben Turner]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey]<br />
|group=dev-platform<br />
|source_dirs=dom/indexedDB/<br />
|url=https://developer.mozilla.org/en/IndexedDB<br />
|components=Core::DOM: IndexedDB<br />
}}<br />
<br />
{{Module<br />
|name=Editor<br />
|description=<br />
|owner=[mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|peers=[mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]<br />
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|group=dev-platform<br />
|source_dirs=editor/<br />
|url=http://www.mozilla.org/editor/<br />
|components=Core::Editor<br />
}}<br />
<br />
{{Module<br />
|name=Embedding<br />
|description=Gecko embedding APIs and frameworks<br />
|owner=[mailto:myk@mykzilla.org Myk Melez]<br />
|ownersemeritus=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:doug.turner@gmail.com Doug Turner]<br />
|peers=[mailto:bdahl@mozilla.com Brendan Dahl], [mailto:tbsaunde@tbsaunde.org Trevor Saunders]<br />
|peersemeritus=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jstenback@gmail.com Johnny Stenback]<br />
|group=dev-platform<br />
|source_dirs=embedding/<br />
|url=<br />
|components=Core::Embedding: APIs<br />
}}<br />
<br />
{{Module<br />
|name=Find As You Type<br />
|description=Find As You Type (formerly called Type Ahead Find) is a feature that allows quick web page navigation when you type a succession of characters in the body of the displayed page (not in an edit box of or drop down list). Currently seeks new owner.<br />
|owner=<br />
|peers=<br />
|group=dev-accessibility<br />
|source_dirs=extensions/typeaheadfind/<br />
|url=http://www.mozilla.org/access/type-ahead/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Gecko Profiler<br />
|description=Gecko's built-in profiler<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|peers=[mailto:nnethercote@mozilla.com Nicholas Nethercote], [mailto:jseward@mozilla.com Julian Seward] (LUL), [mailto:kvijayan@mozilla.com Kannan Vijayan] (JS integration), [mailto:shu@mozilla.com Shu-yu Guo] (JS integration), [mailto:tlee@mozilla.com Thinker Lee] (TaskTracer), [mailto:cyu@mozilla.com Cervantes Yu] (TaskTracer), [mailto:b56girard@gmail.com Benoit Girard].<br />
|group=dev-platform<br />
|source_dirs=tools/profiler/<br />
|url=https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler<br />
|components=Core::Gecko Profiler<br />
}}<br />
<br />
{{Module<br />
|name=Geolocation<br />
|description=Implementation of the Geolocation W3C Spec, location provider apis, and wifi scanning code.<br />
|owner=[mailto:josh@joshmatthews.net Josh Matthews], [mailto:kchen@mozilla.com Kan-Ru Chen]<br />
|ownersemeritus=[mailto:doug.turner@gmail.com Doug Turner], Garvan Keeley<br />
|peers=<br />
|group=dev-tech-dom<br />
|source_dirs=dom/geolocation, dom/system/, netwerk/wifi<br />
|url=https://developer.mozilla.org/En/Using_geolocation<br />
|components=Core::Geolocation<br />
}}<br />
<br />
{{Module<br />
|name=Global Key Bindings<br />
|description=Global hot keys in Mozilla for the browser, editor, mail-news and widgets. Does not include underlined menu accelerators and the like, as those are part of i18n.<br />
|owner=Aaron Leventhal<br />
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|group=dev-accessibility<br />
|source_dirs=dom/xbl/builtin/<br />
|url=http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html<br />
|components=Core::Keyboard: Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Graphics<br />
|description=Mozilla graphics API<br />
|owner=[mailto:jrmuizel@mozilla.com Jeff Muizelaar](Thebes, QCMS, YCbCr, Cairo/Pixman, Regions, OS X, Other)<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peers=[mailto:jdrew@mozilla.com Joe Drew], [mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:bas.schouten@live.nl Bas Schouten](Layers, Windows), [mailto:bjacob@mozilla.com Benoit Jacob](gfx/gl), [mailto:bgirard@mozilla.com Benoit Girard](Compositor, Performance), [mailto:ajuma.bugzilla@alijuma.com Ali Juma], [mailto:jgilbert@mozilla.com Jeff Gilbert](WebGL, ANGLE), [mailto:george@mozilla.com George Wright](Canvas2D), [mailto:mwoodrow@mozilla.com Matt Woodrow](Layers API), [mailto:jdaggett@mozilla.com John Daggett](text/fonts), [mailto:jfkthame@googlemail.com Jonathan Kew](text/fonts), [mailto:nsilva@mozilla.com Nicolas Silva](MozSurface), [mailto:ncameron@mozilla.com Nick Cameron], [mailto:sikeda@mozilla.com Sotaro Ikeda](B2G), [mailto:snorp@mozilla.com James Willcox](Android), [mailto:clord@mozilla.com Christopher Lord], [mailto:mstange@themasta.com Markus Stange](OS X), [mailto:lsalzman@mozilla.com Lee Salzman](Skia), [mailto:mchang@mozilla.com Mason Chang], [mailto:dvander@mozilla.com David Anderson]<br />
|group=dev-platform<br />
|source_dirs=gfx/, dom/canvas/<br />
|url=https://wiki.mozilla.org/Platform/GFX https://wiki.mozilla.org/Gecko:Layers https://wiki.mozilla.org/Gecko:2DGraphicsSketch<br />
|components=Core::Graphics, Core::Graphics: Layers, Core::Graphics: Text, Core::GFX: Color Management, Core::Canvas: 2D, Core::Canvas: WebGL<br />
}}<br />
<br />
{{Module<br />
|name=APZ (Graphics submodule)<br />
|description=Asynchronous panning and zooming<br />
|owner=[mailto:kgupta@mozilla.com Kartikaya Gupta]<br />
|peers=[mailto:bballo@mozilla.com Botond Ballo], [mailto:tnikkel@mozilla.com Timothy Nikkel], [mailto:dvander@mozilla.com David Anderson], [mailto:mstange@mozilla.com Markus Stange]<br />
|group=dev-platform<br />
|source=gfx/layers/apz<br />
|url=https://wiki.mozilla.org/Platform/GFX/APZ<br />
|components=Core::Panning and Zooming<br />
}}<br />
<br />
{{Module<br />
|name=Moz2D (Graphics submodule)<br />
|description=Platform independent 2D graphics API<br />
|owner=[mailto:bschouten@mozilla.com Bas Schouten]<br />
|peers=[mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:gwright@mozilla.com George Wright], [mailto:jwatt@jwatt.org Jonathan Watt]<br />
|group=dev-platform<br />
|source=gfx/2d<br />
|url=https://wiki.mozilla.org/Platform/GFX/Moz2D<br />
|components=Core::Graphics<br />
}}<br />
<br />
{{Module<br />
|name=Legacy HTML Parser<br />
|description=<br />
|owner=[mailto:mrbkap@gmail.com Blake Kaplan]<br />
|peers=[mailto:dbaron@dbaron.org David Baron], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:rbs@maths.uq.edu.au rbs@maths.uq.edu.au]<br />
|peersemeritus=[mailto:jstenback@gmail.com Johnny Stenback]<br />
|source_dirs=parser/htmlparser<br />
|url=http://www.mozilla.org/newlayout/doc/parser.html<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=HAL<br />
|description=Hardware Abstraction Layer<br />
|owner=[https://mozillians.org/u/dhylands/ Dave Hylands]<br />
|peers=[mailto:gsvelto@mozilla.com Gabriele Svelto]<br />
|group=dev-platform<br />
|source_dirs=hal/<br />
|components=Core::Hardware Abstraction Layer (HAL)<br />
}}<br />
<br />
{{Module<br />
|name=HTML Parser<br />
|description=The HTML Parser transforms HTML source code into a DOM. It conforms to the HTML specification, and is mostly translated automatically from Java to C++.<br />
|owner=[mailto:hsivonen@iki.fi Henri Sivonen]<br />
|peers=[mailto:wchen@mozilla.com William Chen]<br />
|group=dev-platform<br />
|source_dirs=parser/html<br />
|url=http://about.validator.nu/<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=I18N Library<br />
|description=<br />
|owner=[mailto:hsivonen@hsivonen.fi Henri Sivonen (encoding)], [mailto:jfkthame@gmail.com Jonathan Kew (except to encoding)]<br />
|peers=[mailto:VYV03354@nifty.ne.jp Masatoshi Kimura], [mailto:gandalf@aviary.pl Zibi Braniecki], [mailto:m_kato@ga2.so-net.ne.jp Makoto Kato]<br />
|ownersemeritus=[mailto:jshin1987@gmail.com Jungshik Shin], [mailto:smontagu@smontagu.org Simon Montagu]<br />
|group=dev-i18n<br />
|source_dirs=intl/<br />
|url=http://mozilla.org/projects/intl/index.html<br />
|components=Core::Internationalization<br />
}}<br />
<br />
{{Module<br />
|name=ImageLib<br />
|description=<br />
|owner=[mailto:tnikkel@gmail.com Timothy Nikkel]<br />
|peers=[mailto:aosmond@mozilla.com Andrew Osmond], [mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:seth.bugzilla@blackhail.net Seth Fowler]<br />
|peersemeritus=[mailto:netzen@gmail.com Brian Bondy], [mailto:justin.lebar@gmail.com Justin Lebar]<br />
|group=dev-platform<br />
|source_dirs=media/libjpeg/, media/libpng/, image/, modules/zlib/<br />
|url=<br />
|components=Core::ImageLib<br />
}}<br />
<br />
{{Module<br />
|name=IPC<br />
|description=Message-passing between threads and processes<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:danderson@mozilla.com David Anderson], [mailto:kchen@mozilla.com Kan-Ru Chen], [mailto:jld@mozilla.com Jed Davis], [mailto:nfroyd@mozilla.com Nathan Froyd], [mailto:bkelly@mozilla.com Ben Kelly], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:btseng@mozilla.com Bevis Tseng]<br />
|peersemeritus=[mailto:wmccloskey@mozilla.com Bill McCloskey]<br />
|group=dev-platform<br />
|source_dirs=ipc/glue/, ipc/ipdl/, ipc/chromium/<br />
|url=<br />
|components=Core::IPC}}<br />
<br />
{{Module<br />
|name=JavaScript<br />
|description=JavaScript engine (SpiderMonkey)<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:jdemooij@mozilla.com Jan de Mooij], [mailto:nnethercote@mozilla.com Nick Nethercote], [mailto:jwalden@mit.edu Jeff Walden], [mailto:hv1989@gmail.com Hannes Verschore], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:evilpies@gmail.com Tom Schuster], [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:till@tillschneidereit.net Till Schneidereit], [mailto:efaust@mozilla.com Eric Faust], [mailto:nfitzgerald@mozilla.com Nick Fitzgerald], [mailto:luke@mozilla.com Luke Wagner], [mailto:arai.unmht@gmail.com Tooru Fujisawa], [mailto:sunfish@mozilla.com Dan Gohman], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:nmatsakis@mozilla.com Niko Matsakis], [mailto:ejpbruel@mozilla.com Eddy Bruel], [mailto:danderson@mozilla.com David Anderson], [mailto:igor@mir2.org Igor Bukanov], [mailto:brendan@mozilla.org Brendan Eich], Andreas Gal<br />
|peersemeritus=[mailto:wmccloskey@mozilla.com Bill McCloskey]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src<br />
|url=http://www.mozilla.org/js/spidermonkey,<br />
http://developer.mozilla.org/en/docs/About_JavaScript<br />
|components=Core::JavaScript Engine<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript JIT<br />
|description=JavaScript engine's JIT compilers (IonMonkey, Baseline)<br />
|owner=[mailto:jdemooij@mozilla.com Jan de Mooij]<br />
|peers=[mailto:danderson@mozilla.com David Anderson], [mailto:bbouvier@mozilla.com Benjamin Bouvier], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:nicolas.b.pierron@mozilla.com Nicolas Pierron], [mailto:evilpies@gmail.com Tom Schuster], [mailto:sstangl@mozilla.com Sean Stangl], [mailto:hv1989@gmail.com Hannes Verschore], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:luke@mozilla.com Luke Wagner]<br />
|group=dev-tech-js-engine-internals<br />
|source_dirs=js/src/jit<br />
|url=http://www.mozilla.org/js/spidermonkey<br />
|components=Core::JavaScript Engine: JIT<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript Debugger Backend<br />
|description=JavaScript debugging hooks<br />
|owner=[mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:rginda@hacksrus.com Rob Ginda]<br />
|group=dev-apps-js-debugger<br />
|source_dirs=js/jsd/<br />
|url=http://www.mozilla.org/js/jsd<br />
|components=Other Applications::Venkman JS Debugger<br />
}}<br />
<br />
{{Module<br />
|name=jsat<br />
|description=Javascript screen reader that is used in Android and B2G<br />
|owner=[mailto:eitan@monotonous.org Eitan Isaacson]<br />
|peers=[mailto:yzenevich@mozilla.com Yura Zenevich]<br />
|group=dev-accessibility<br />
|source_dirs=accessible/jsat/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=js-ctypes<br />
|description=A foreign function interface which allows privileged JS code to interact with binary code without using XPCOM/XPConnect.<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src/ctypes/<br />
|url=https://wiki.mozilla.org/JSctypes<br />
|components=Core::js-ctypes<br />
}}<br />
<br />
{{Module<br />
|name=js-tests<br />
|description=JavaScript test suite<br />
|owner=[mailto:bclary@bclary.com Bob Clary]<br />
|peers=<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tests/<br />
|url=http://www.mozilla.org/js/tests/library.html<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Layout Engine<br />
|description=rendering tree construction, layout (reflow), etc.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:jfkthame@gmail.com Jonathan Kew], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:matt.woodrow@gmail.com Matt Woodrow], [mailto:xidorn+moz@upsuper.org Xidorn Quan]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/%, layout/base/, layout/build/, layout/doc/, layout/forms/, layout/generic/, layout/html/, layout/printing/, layout/tables/, layout/tools/<br />
|url=http://mozilla.org/newlayout/doc/ ,<br />
http://lxr.mozilla.org/mozilla/source/layout/doc/<br />
|components=Core::Layout, Core::Layout: Block and Inline, Core::Layout: Floats, Core::Layout: Form Controls, Core::Layout: HTML Frames, Core::Layout: Images, Core::Layout: Misc Code, Core::Layout: R & A Pos, Core::Layout: Tables, Core::Layout: Text, Core::Print Preview, Core::Printing: Output<br />
}}<br />
<br />
{{Module<br />
|name=libjar<br />
|description=The JAR handling code (protocol handler, stream implementation, and zipreader/zipwriter).<br />
|owner=[mailto:mwu@mozilla.com Michael Wu]<br />
|peers=[mailto:aklotz@mozilla.com Aaron Klotz]<br />
|group=dev-platform<br />
|source_dirs=modules/libjar<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=MathML<br />
|description=MathML is a low-level specification for describing mathematics which provides a foundation for the inclusion of mathematical expressions in Web pages.<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|group=dev-tech-mathml<br />
|source_dirs=layout/mathml/<br />
|url=http://www.mozilla.org/projects/mathml/<br />
|components=Core::MathML<br />
}}<br />
<br />
{{Module<br />
|name=Media Playback<br />
|description=HTML Media APIs, including Media Source Extensions and non-MSE video/audio element playback, and Encrypted Media Extensions. (WebRTC and WebAudio not included).<br />
|owner=[mailto:jyavenard@mozilla.com Jean-Yves Avenard]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:cpearce@mozilla.com Chris Pearce]<br />
|peers=[mailto:ajones@mozilla.com Anthony Jones], [mailto:kinetik@flim.org Matthew Gregan], [mailto:eflores@mozilla.com Edwin Flores], [mailto:gsquelart@mozilla.com Gerald Squelart], [mailto:rgiles@mozilla.com Ralph Giles], [mailto:jwwang@mozilla.com JW Wang]<br />
|group=dev-media<br />
|source_dirs=dom/media, media/gmp-clearkey/, media/libcubeb/, media/libnestegg/, media/libogg/, media/libopus/, media/libstagefright/, media/libtheora/, media/libtremor/, media/libvorbis/, media/libvpx/, media/omx-plugin/, media/rlz/<br />
|url=<br />
|components=Core::Audio/Video<br />
}}<br />
<br />
{{Module<br />
|name=Media Transport<br />
|description=Pluggable transport for real-time media<br />
|owner=[mailto:ekr@rtfm.com Eric Rescorla]<br />
|peers=[mailto:bcampen@mozilla.com Byron Campen], [mailto:abr@mozilla.com Adam Roach], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]<br />
|group=dev-media<br />
|source_dirs=media/mtransport<br />
|url=<br />
|components=Core::WebRTC::Networking<br />
}}<br />
<br />
{{Module<br />
|name=Memory Allocator<br />
|description=Most things related to memory allocation in Gecko, including jemalloc, replace-malloc, DMD (dark matter detector), logalloc, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|peers=[mailto:n.nethercote@gmail.com Nicholas Nethercote], [mailto:erahm@mozilla.com Eric Rahm]<br />
|group=dev-platform<br />
|source_dirs=memory/<br />
|components=Core::DMD, Core::jemalloc<br />
}}<br />
<br />
{{Module<br />
|name=mfbt<br />
|description=mfbt is a collection of headers, macros, data structures, methods, and other functionality available for use and reuse throughout all Mozilla code (including SpiderMonkey and Gecko more broadly).<br />
|owner=[mailto:jwalden@mit.edu Jeff Walden]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd], [mailto:Ms2ger@gmail.com Ms2ger], [mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|group=dev-platform<br />
|source_dirs=mfbt/<br />
|url=<br />
|components=Core::MFBT<br />
}}<br />
<br />
{{Module<br />
|name=Mozglue<br />
|description=Glue library containing various low-level functionality, including a dynamic linker for Android, a DLL block list for Windows, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd] (mozglue/linker), [mailto:kgupta@mozilla.com Kartikaya Gupta] (mozglue/android), [mailto:nchen@mozilla.com Jim Chen] (mozglue/android)<br />
|group=dev-platform<br />
|source_dirs=mozglue/<br />
|components=Core::mozglue<br />
}}<br />
<br />
{{Module<br />
|name=mozilla-toplevel<br />
|description=The top level directory for the mozilla tree.<br />
|owner=[mailto:brendan@mozilla.org Brendan Eich]<br />
|peers=<br />
|group=<br />
|source_dirs=tools/README<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=MSCOM<br />
|description=Integration with Microsoft Distributed COM<br />
|owner=[mailto:aklotz@mozilla.com Aaron Klotz]<br />
|peers=[mailto:jteh@mozilla.com James Teh], [mailto:jmathies@mozilla.com Jim Mathies]<br />
|group=dev-platform<br />
|source_dirs=ipc/mscom/%<br />
|url=<br />
|components=Core::IPC: MSCOM}}<br />
<br />
{{Module<br />
|name=Necko<br />
|description=The Mozilla Networking Library<br />
|owner=[mailto:mcmanus@ducksong.com Patrick McManus]<br />
|peers= [mailto:jduell.mcbugs@gmail.com Jason Duell], [mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:mnovotny@mozilla.com Michal Novotny], [mailto:hurley@mozilla.com Nick Hurley], [mailto:dd.mozilla@gmail.com Dragana Damjanovic ],[mailto:valentin.gosu@gmail.com Valentin Gosu],[mailto:daniel@haxx.se Daniel Stenberg ], [mailto:schien@mozilla.com ShihChiang Chien]<br />
|peersemeritus= [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sworkman@mozilla.com Steve Workman], [mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|group=dev-tech-network<br />
|source_dirs=netwerk/%, netwerk/base/, netwerk/build/, netwerk/cache/, netwerk/dns/, netwerk/locales/, netwerk/mime/, netwerk/protocol/, netwerk/resources/, netwerk/socket/, netwerk/streamconv/, netwerk/system/, netwerk/test/, netwerk/testserver/<br />
|url=http://www.mozilla.org/projects/netlib/, https://developer.mozilla.org/en/Necko<br />
|components=Core::Networking, Core::Networking: Cache, Core::Networking: Cookies, Core::Networking: FTP, Core::Networking: File, Core::Networking: HTTP, Core::Networking: JAR, Core::Networking: Websockets<br />
}}<br />
<br />
{{Module<br />
|name=NSPR<br />
|description=Netscape Portable Runtime<br />
|owner=[mailto:kaie@kuix.de Kai Engert]<br />
|peers=[mailto:wtc@google.com Wan-Teh Chang], [mailto:mh@glandium.org Mike Hommey]<br />
|group=dev-tech-nspr<br />
|source_dirs=nsprpub/<br />
|url=http://www.mozilla.org/projects/nspr/<br />
http://www.mozilla.org/projects/nspr/reference/html/<br />
http://www.mozilla.org/projects/nspr/release-notes/<br />
|components=NSPR<br />
}}<br />
<br />
{{Module<br />
|name=PDF<br />
|description=Rendering code to display documents encoded in the ISO 32000-1 `PDF' format.<br />
|owner=Chris Jones, Andreas Gal<br />
|peers=[mailto:aadib@mozilla.com Artur Adib], [mailto:bdahl@mozilla.com Brendan Dahl], [mailto:vnicolas@mozilla.com Vivien Nicolas]<br />
|group=dev-platform<br />
|source_dirs=media/pdf/<br />
|url=https://github.com/mozilla/pdf.js<br />
|components=Core::PDF<br />
}}<br />
<br />
{{Module<br />
|name=Plugins<br />
|description= NPAPI Plugin support.<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:joshmoz@gmail.com Josh Aas]<br />
|peersemeritus=[mailto:john@pointysoftware.net John Schoenick], [mailto:robert@ocallahan.org Robert O'Callahan], [mailto:jstenback@gmail.com Johnny Stenback], Benjamin Smedberg<br />
|group=<br />
|source_dirs=dom/plugins/, modules/plugin/<br />
|url=https://wiki.mozilla.org/Plugins<br />
|components=Core::Plug-ins<br />
}}<br />
<br />
{{Module<br />
|name=Preferences<br />
|description=Preference library<br />
|owner=[mailto:nnethercote@mozilla.com Nicholas Nethercote]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd], [mailto:felipe@mozilla.com Felipe Gomes], [mailto:glandium@mozilla.com Mike Hommey], [mailto:erahm@mozilla.com Eric Rahm]<br />
|group=dev-platform<br />
|source_dirs=modules/libpref/<br />
|url=<br />
|components=Core::Preferences: Backend<br />
}}<br />
<br />
{{Module<br />
|name=Private Browsing<br />
|description=Implementation of the Private Browsing mode, and the integration of other modules with Private Browsing APIs.<br />
|owner=[mailto:josh@joshmatthews.net Josh Matthews] (while Ehsan is away)<br />
|peers=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|group=dev-platform<br />
|source_dirs=Implementation and consumers of Private Browsing APIs in nsILoadContext, nsIPrivateBrowsingChannel, PrivateBrowsingUtils.jsm and the related glue code. <br />
|url=https://wiki.mozilla.org/Private_Browsing<br />
|components=Firefox::Private Browsing<br />
}}<br />
<br />
{{Module<br />
|name=Privilege Manager<br />
|description="caps"<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|peersemeritus=[mailto:brendan@mozilla.org Brendan Eich], [mailto:jstenback@gmail.com Johnny Stenback], [mailto:dveditz@mozilla.com Dan Veditz]<br />
|group=dev-tech-dom<br />
|source_dirs=caps/<br />
|url=http://www.mozilla.org/projects/security/components/index.html<br />
|components=Core::Security: CAPS<br />
}}<br />
<br />
{{Module<br />
|name=Push Notifications<br />
|description=Push is a way for application developers to send messages to their web applications.<br />
|owners=<br />
|ownersemeritus=[mailto:doug.turner@gmail.com Doug Turner]<br />
|peers=[mailto:nsm.nikhil@gmail.com Nikhil Marathe], [mailto:kcambridge@mozilla.com Kit Cambridge], [mailto:martin.thomson@gmail.com Martin Thomson], [mailto:ddamjanovic@mozilla.com Dragana Damjanovic]<br />
|group=<br />
|source_dirs=dom/push, dom/simplepush<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=PyXPCOM<br />
|description=The Python to XPCOM bridge.<br />
|owner=Todd Whiteman<br />
|peers=[mailto:mhammond@skippinet.com.au Mark Hammond]<br />
|group=<br />
|source_dirs=extension/python<br />
|url=https://developer.mozilla.org/en/PyXPCOM<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=RDF<br />
|description=<br />
|owner=[mailto:axel@pike.org Axel Hecht]<br />
|peers=<br />
|group=dev-tech-rdf<br />
|source_dirs=rdf/<br />
|url=http://www.mozilla.org/rdf/doc/<br />
|components=Core::RDF<br />
}}<br />
<br />
{{Module<br />
|name=security<br />
|description=Crypto/PKI code, including NSS (Network Security Services) and JSS (NSS for Java)<br />
|owner=[mailto:rrelyea@redhat.com Bob Relyea], [mailto:ttaubert@mozilla.com Tim Taubert]<br />
|peers=[mailto:kaie@kuix.de Kai Engert], [mailto:ryan.sleevi@gmail.com Ryan Sleevi], [mailto:ekr@rtfm.com Eric Rescorla], [mailto:franziskuskiefer@gmail.com Franziskus Kiefer], [mailto:martin.thomson@gmail.com Martin Thomson], [mailto:wtc@google.com Wan-Teh Chang], [mailto:dueno@redhat.com Daiki Ueno]<br />
|peersemeritus=[mailto:emaldona@redhat.com Elio Maldonado]<br />
|group=dev-tech-crypto<br />
|source_dirs=dbm/, security/coreconf/, security/dbm/, security/jss/, security/nss/, security/tinderbox/, security/tinderlight/<br />
|url=http://mozilla.org/projects/security/pki/<br />
|components=NSS, JSS, Core::Security, Core::Security: S/MIME<br />
}}<br />
<br />
{{Module<br />
|name=Security - Mozilla PSM Glue<br />
|description=Personal Security Manager<br />
|owner=[mailto:dkeeler@mozilla.com David Keeler]<br />
|ownersemeritus=[mailto:kaie@kuix.de Kai Engert (2001-2012)]<br />
|peers=[mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:cykesiopka.bmo@gmail.com Cykesiopka]<br />
|group=dev-tech-crypto<br />
|source_dirs=security/manager/<br />
|url=<br />
|components=Core::Security: PSM, Core::Security: UI<br />
}}<br />
<br />
{{Module<br />
|name=Static analysis & rewriting for C++<br />
|description=Tools for checking C++ code looking for problems at compile time, plus tools for automated rewriting of C++ code.<br />
|owner=[mailto:nika@thelayzells.com Nika Layzell] (while Ehsan is away)<br />
|peers=[mailto:sfink@mozilla.com Steve Fink], [mailto:jrmuizel@mozilla.com Jeff Muizelaar], [mailto:birunthan@mohanathas.com Birunthan Mohanathas], [mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|group=dev-platform<br />
|source_dirs=build/clang-plugin, tools/rewriting among other out of tree tools<br />
|url=<br />
|components=Core::Rewriting & Analysis<br />
}}<br />
{{Module<br />
|name=storage<br />
|description=Storage APIs with a SQLite backend<br />
|owner=[mailto:mak77@bonardo.net Marco Bonardo]<br />
|peers=[mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:jvarga@mozilla.com Jan Varga]<br />
|group=dev-platform<br />
|source_dirs=db/sqlite3/, storage/<br />
|url=http://developer.mozilla.org/en/docs/Storage<br />
|components=Toolkit::Storage, Core::SQL<br />
}}<br />
<br />
{{Module<br />
|name=String<br />
|description=<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd], [mailto:erahm@mozilla.com Eric Rahm]<br />
|group=dev-tech-xpcom<br />
|source_dirs=string/, xpcom/string/<br />
|url=https://developer.mozilla.org/En/Mozilla_internal_string_guide<br />
|components=Core::String<br />
}}<br />
<br />
{{Module<br />
|name=Style System<br />
|description=CSS style sheet handling; style data computation<br />
|owner= [mailto:cam@mcc.id.au Cameron McCormack]<br />
|peers=[mailto:dbaron@dbaron.org David Baron], [mailto:emilio@crisal.io Emilio Cobos Álvarez], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:xidorn+moz@upsuper.org Xidorn Quan], [mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/style/<br />
|url=https://wiki.mozilla.org/Gecko:Overview#Style_System<br />
|components=Core::CSS Parsing and Computation<br />
}}<br />
<br />
{{Module<br />
|name=SVG<br />
|description=Scalable Vector Graphics<br />
|owner=[mailto:jwatt@jwatt.org Jonathan Watt]<br />
|peers=[mailto:longsonr@gmail.com Robert Longson], [mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:birtles@gmail.com Brian Birtles]<br />
|group=dev-tech-svg<br />
|source_dirs=dom/svg/, layout/svg/, dom/smil/<br />
|url=https://developer.mozilla.org/en-US/docs/Web/SVG<br />
|components=Core::SVG<br />
}}<br />
<br />
{{Module<br />
|name=Tamarin<br />
|description=VM for ActionScript and JavaScript<br />
|owner=Edwin Smith, [mailto:jodyer@adobe.com Jeff Dyer]<br />
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:stejohns@adobe.com Steven Johnson], [mailto:tierney@adobe.com Erik Tierney], [mailto:treilly@adobe.com Tom Reilly]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tamarin<br />
|url=http://www.mozilla.org/projects/tamarin/<br />
http://wiki.mozilla.org/tamarin/<br />
http://hg.mozilla.org/tamarin-central/<br />
http://hg.mozilla.org/tamarin-tracing/<br />
|components=Tamarin<br />
}}<br />
<br />
{{Module<br />
|name=Test Harness<br />
|description=In-tree test infrastructure and tools. Harnesses include, XPCShell, Mochitest (& Chrome), Reftest, JsREftest, Compiled Code Tests, Robocop, Mozmill, Marionette, Firefox UI Tests. Requests for new harnesses should go to Testing::General.<br />
|owner=[mailto:ted@mielczarek.org Ted Mielczarek]<br />
|peers=[mailto:dbaron@dbaron.org David Baron] (reftest), [mailto:jwalden@mit.edu Jeff Walden] (httpd.js, jsreftest), Rob Campbell (mochitest, mochitest chrome, marionette), [mailto:jmaher@mozilla.com Joel Maher] (reftest, mochitest, jsreftest), [mailto:ctalbert@mozilla.com Clint Talbert] (reftest, compiled code, mozmill), [mailto:geoffbrown@mozilla.com Geoff Brown] (robocop), [mailto:hskupin@mozilla.com Henrik Skupin] (Marionette, Firefox UI tests), [mailto:ato@mozilla.com Andreas Tolfsen] (marionette), [mailto:jgriffin Jonathan Griffin] (marionette), [mailto:dburns@mozilla.com David Burns] (marionette), [mailto:dminor@mozilla.com Dan Minor], [mailto:mjzffr@gmail.com Maja Frydrychowicz] (Marionette, Firefox UI tests), <br />
<br />
|group=dev-quality<br />
|source_dirs=/testing<br />
|url=http://wiki.mozilla.org/SoftwareTesting<br />
|components=Testing::General, Testing::Mochitest, Testing::Mochitest Chrome, Testing::Marionette, Testing::Mozmill, Testing::Reftest, Testing::XPCShell Harness, Testing::httpd.js<br />
}}<br />
<br />
{{Module<br />
|name=Testing Infrastructure<br />
|description=Testing tools and infrastructure for Mozilla projects, harnesses for automated tests, stand-alone test tools. Talos, Graph Server, Mozbase, Pulse, WOO, Bughunter, SUTAgent, Eideticker<br />
|owner=[mailto:jmaher@mozilla.com Joel Maher]<br />
|peers=[mailto:bclary@bclary.com Bob Clary], [mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:ccooper@deadsquid.com Chris Cooper], [mailto:ctalbert@mozilla.com Clint Talbert], [mailto:robert@roberthelmer.com Robert Helmer], [mailto:jmaher@mozilla.com Joel Maher], Rob Campbell, [mailto:wlach@mozilla.com William Lachance], [mailto:jeads@mozilla.com Jonathan Eads], [mailto:jgriffin Jonathan Griffin], [mailto:bmoss@mozilla.com Bob Moss], [mailto:mcote@mozilla.com Mark Côté]<br />
|group=dev-quality<br />
|source_dirs=testing/, tools/httptester/, tools/page-loader/, tools/test-harness/, tools/tests/, tools/testserver/, tools/testy/<br />
|url=http://wiki.mozilla.org/SoftwareTesting<br />
|components=Testing::Infrastructure<br />
}}<br />
<br />
{{Module<br />
|name=JS Marionette<br />
|description=NodeJS test harness, marionette client, and other utilities for running marionette tests (submodule of Test Infrastructure)<br />
|owner=[mailto:jlal@mozilla.com James Lal] <lightsofapollo>, [mailto:gaye@mozilla.com Gareth Aye] <gaye><br />
|peers=[mailto:aus@mozilla.com Ghislain "Aus" Lacroix] <auswerk><br />
|source_dirs=gaia/tests/jsmarionette<br />
|components=Testing::JSMarionette<br />
|group=dev-gaia<br />
}}<br />
<br />
{{Module<br />
|name=XPCShell Test Harness<br />
|description=The XPCShell Harness<br />
|owner=[mailto:ted@mielczarek.org Ted Mielczarek]<br />
|peers=[mailto:jmaher@mozilla.com Joel Maher]<br />
|source_dirs=testing/xpcshell<br />
|components=Testing::XPCShell Harness<br />
}}<br />
<br />
{{Module<br />
|name=Update Service<br />
|description=server code for Mozilla Update services (aus, addons, pfs)<br />
|owner=Mike Morgan<br />
|peers=[mailto:jscott@mozilla.com Justin Scott], [mailto:shaver@mozilla.org Mike Shaver], [mailto:wclouser@mozilla.com Will Clouser]<br />
|group=dev-amo<br />
|source_dirs=webtools/addons/, webtools/aus/, webtools/update/<br />
|url=http://wiki.mozilla.org/wiki/AMO<br />
|components=AUS::Administration, AUS::Systems<br />
}}<br />
<br />
{{Module<br />
|name=View System<br />
|description=The View Manager is responsible for handling "heavyweight" rendering (some clipping, compositing) and event handling tasks.<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron]<br />
|group=dev-tech-layout<br />
|source_dirs=view/<br />
|url=<br />
|components=Core::Layout: View Rendering<br />
}}<br />
<br />
{{Module<br />
|name=Web Audio<br />
|description=Support for the W3C Web Audio API specification.<br />
|owner=[mailto:padenot@mozilla.com Paul Adenot]<br />
|ownersemeritus=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:karlt+@karlt.net Karl Tomlinson]<br />
|group=dev-platform<br />
|source_dirs=dom/media/webaudio<br />
|url=https://wiki.mozilla.org/Web_Audio_API<br />
|components=Core::Web Audio<br />
}}<br />
<br />
{{Module<br />
|name=Web Painting<br />
|description=painting, display lists, and layer construction<br />
|owner=[mailto:matt.woodrow@gmail.com Matt Woodrow]<br />
|peers=[mailto:robert@ocallahan.org Robert O'Callahan], [mailto:dbaron@dbaron.org David Baron], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:mstange@themasta.com Markus Stange]<br />
|group=dev-tech-layout<br />
|source_dirs= layout/painting, the display list and layer related methods on nsIFrame and its subclasses<br />
|url=http://mozilla.org/newlayout/doc/ ,<br />
http://lxr.mozilla.org/mozilla/source/layout/doc/<br />
|components=Core::Layout: Web Painting<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC<br />
|description=WebRTC is responsible for realtime audio and video communication, as well as related issues like low-level camera and microphone access<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:bcampen@mozilla.com Byron Campen] [mailto:abr@mozilla.com Adam Roach]<br />
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=netwerk/sctp (also see submodules "WebRTC Media" and "WebRTC Signaling")<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC, Core::WebRTC Networking<br />
}}<br />
<br />
{{Module<br />
|name=WebVR<br />
|description=Gecko's implementation of WebVR (Virtual Reality) functionality, including API, devices, graphics and integration<br />
|owner=[mailto:kgilbert@mozilla.com Kip Gilbert]<br />
|peers=[mailto:dmu@mozilla.com Daosheng Mu]<br />
|peersemeritus=[mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|group=dev-platform<br />
|source_dirs=dom/vr, gfx/vr<br />
|url=https://mozvr.com/<br />
|components=Core::WebVR<br />
}}<br />
<br />
{{Module<br />
|name=Widget<br />
|description=<br />
|owner=[mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|peersemeritus=[mailto:pavlov@pavlov.net Stuart Parmenter], <br />
|group=dev-platform<br />
|source_dirs=widget/, widget/xpwidgets/<br />
|url=<br />
|components=Core::Drag and Drop, Core::Widget, Core::Printing: Setup<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Android<br />
|description=The Android Port<br />
|owner=[mailto:blassey.bugs@lassey.us Brad Lassey]<br />
|peers=[mailto:jwillcox@mozilla.com James Willcox]<br />
|group=dev-platforms-mobile<br />
|source_dirs=widget/android/, embedding/android<br />
|url=<br />
|components=Core::Widget: Android<br />
}}<br />
<br />
{{Module<br />
|name=Widget - GTK<br />
|description=supported X widgetry and gfx<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|ownersemeritus=[mailto:robert@ocallahan.org Robert O'Callahan]<br />
|group=dev-platform<br />
|source_dirs=widget/gtk/, widget/gtk2/, widget/gtksuperwin/, widget/gtkxtbin/<br />
|url=http://www.mozilla.org/unix/, http://www.gtk.org, http://www.mozilla.org/ports/gtk/<br />
|components=Core::Widget: Gtk<br />
}}<br />
<br />
{{Module<br />
|name=Widget - OS X<br />
|description= Gecko's OS X compatibility layer.<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|peers=[mailto:joshmoz@gmail.com Josh Aas], [mailto:bgirard@mozilla.com Benoit Girard], [mailto:spohl@mozilla.com Stephen Pohl], [mailto:smichaud@pobox.com Steven Michaud]<br />
|group=dev-platform<br />
|source_dirs=widget/cocoa/<br />
|url=<br />
|components=Core::Widget: Cocoa<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Windows<br />
|description=Windows widgets and desktop integration<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook], [mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:jmathies@mozilla.com Jim Mathies]<br />
|peersemeritus=[mailto:blassey@mozilla.com Brad Lassey], [mailto:netzen@gmail.com Brian Bondy], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:doug.turner@gmail.com Doug Turner], [mailto:timeless@mozdev.org Josh 'timeless' Soref], [mailto:robarnold@cmu.edu Rob Arnold]<br />
|group=dev-platform<br />
|source_dirs=widget/windows/<br />
|url=<br />
|components=Core::Widget: Win32<br />
}}<br />
<br />
{{Module<br />
|name=XBL<br />
|description=eXtensible Binding Language<br />
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|peers=[mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:jonas@sicking.cc Jonas Sicking]<br />
|ownersemeritus=[mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-tech-xbl<br />
|source_dirs=dom/xbl/<br />
|url=http://www.mozilla.org/projects/xbl/<br />
|components=Core::XBL<br />
}}<br />
<br />
{{Module<br />
|name=XML<br />
|description=XML in Mozilla, including XML, XHTML, Namespaces in XML, Associating Style Sheets with XML Documents, XML Linking and XML Extras. XML-related things that are not covered by more specific projects.<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:erahm@mozilla.com Eric Rahm]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:jstenback@gmail.com Johnny Stenback]<br />
|group=dev-tech-xml<br />
|source_dirs=dom/xml/, extensions/xmlextras/, parser/expat/<br />
|url=http://www.mozilla.org/newlayout/xml/<br />
|components=Core::XML<br />
}}<br />
<br />
{{Module<br />
|name=XPApps<br />
|description=Cross-Platform Applications, mostly Navigator front end and application shell.<br />
|owner=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|peers=[mailto:dean_tessman@hotmail.com Dean Tessman], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-apps-seamonkey<br />
|source_dirs=xpfe/<br />
|url=http://www.mozilla.org/xpapps/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPCOM<br />
|description=The cross-platform object model and core data structures.<br />
|owner=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd]<br />
|peers=[mailto:erahm@mozilla.com Eric Rahm]<br />
|ownersemeritus=Benjamin Smedberg<br />
|peersemeritus=[https://mozillians.org/en-US/u/dougt/ Doug Turner]<br />
|group=dev-platform<br />
|source_dirs=startupcache/, xpcom/%, xpcom/base/, xpcom/build/, xpcom/components/, xpcom/ds/, xpcom/glue/, xpcom/proxy/, xpcom/sample/, xpcom/stub/, xpcom/tests/, xpcom/threads/, xpcom/tools/, xpcom/windbgdlg/<br />
|url=http://developer.mozilla.org/en/XPCOM<br />
|components=Core::XPCOM<br />
}}<br />
<br />
{{Module<br />
|name=XPConnect<br />
|description=Deep Magic<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:gkrizsanits@mozilla.com Gabor Krizsanits], [mailto:amccreight@mozilla.com Andrew McCreight], [mailto:kmaglione@mozilla.com Kris Maglione]<br />
|peersemeritus=[mailto:gal@uci.edu Andreas Gal], [mailto:jstenback@gmail.com Johnny Stenback]<br />
|group=<br />
|source_dirs=js/xpconnect/<br />
|url=<br />
|components=Core::XPConnect<br />
}}<br />
<br />
{{Module<br />
|name=XPIDL<br />
|description=Cross-platform IDL compiler; produces .h C++ header files and .xpt runtime type description files from .idl interface description files.<br />
|owner=[mailto:me@kylehuey.com Kyle Huey]<br />
|peersemeritus=[mailto:shaver@mozilla.org Mike Shaver], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-tech-xpcom<br />
|source_dirs=xpcom/typelib/<br />
|url=http://www.mozilla.org/scriptable/xpidl<br />
http://www.mozilla.org/scriptable<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPInstall<br />
|description=<br />
|owner=[mailto:dveditz@mozilla.com Dan Veditz]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|group=dev-tech-xpinstall<br />
|source_dirs=xpinstall/<br />
|url=<br />
|components=Core::Installer: XPInstall Engine<br />
}}<br />
<br />
{{Module<br />
|name=XPToolkit<br />
|description=Cross-platform user interface toolkit<br />
|owner=<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:Jan.Varga@gmail.com Jan Varga]<br />
|group=dev-tech-xul<br />
|source_dirs=dom/xul/, layout/xul/<br />
|url=http://www.mozilla.org/xpfe/<br />
|components=Core::XP Toolkit/Widgets: Menus, Core::XP Toolkit/Widgets: XUL<br />
}}<br />
<br />
{{Module<br />
|name=XSLT Processor<br />
|description=XSLT transformations processor<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:axel@pike.org Axel Hecht], [mailto:erahm@mozilla.com Eric Rahm]<br />
|peersemeritus=[mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-tech-xslt<br />
|source_dirs=dom/xslt/<br />
|url=http://www.mozilla.org/projects/xslt/, http://www.w3.org/TR/xslt.html<br />
|components=Core::XSLT<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Windows <br />
|description=Sandboxing for the Windows platform <br />
|owner=[mailto:bobowencode@gmail.com Bob Owen] (:bobowen)<br />
|peers=[mailto:aklotz@mozilla.com Aaron Klotz] (:aklotz), [mailto:jimm@mozilla.com Jim Mathies] (:jimm), [mailto:davidp99@gmail.com David Parks] (:handyman)<br />
|ownersemeritus=[https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes]<br />
|peersemeritus=[mailto:netzen@gmail.com Brian Bondy]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/win <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - OSX <br />
|description=Sandboxing for the OSX platform <br />
|owner=[mailto:haftandilian@mozilla.com Haik Aftandilian]<br />
|peers=<br />
|group=dev-platform <br />
|source_dirs=security/sandbox/mac <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Linux<br />
|description=Sandboxing for the Linux platform<br />
|owner=[mailto:jld@mozilla.com Jed Davis]<br />
|peers=[mailto:gcp@mozilla.com Gian-Carlo Pascutto]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/linux<br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
===Submodules===<br />
{{Module<br />
|name=Build Config - Fennec<br />
|description=Submodule of the build config covering Fennec's build system in mobile/android.<br />
|owner=[mailto:nalexander@mozilla.com Nicholas Alexander]<br />
|peers=Same as Build Config<br />
|group=dev-builds<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=Build Config - Taskgraph<br />
|description=Support for task-graph generation in decision, action, and cron tasks, including configuration of all tasks including those for CI, nightlies, and releases; as well as Docker and VM images used to execute those tasks.<br />
|owner=[mailto:dustin@mozilla.com Dustin Mitchell]<br />
|peers=[mailto:ahal@mozilla.com Andrew Halberstadt], [mailto:aki@mozilla.com Aki Sasaki], [mailto:bstack@mozilla.com Brian Stack], [mailto:mh@glandium.org Mike Hommey], [mailto:gps@mozilla.com Gregory Szorc], [mailto:jmaher@mozilla.com Joel Maher], [mailto:callek@mozilla.com Justin Wood]<br />
|components=Taskcluster::Task Configuration<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC Media<br />
|description=Submodule of WebRTC responsible for access to media input devices (microphones, cameras, screen capture), as well as realtime audiovisual codecs and packetization.<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:jib@mozilla.com Jan-Ivar Bruaroey], [mailto:dminor@mozilla.com Dan Minor], [mailto:apehrson@mozilla.com Andreas Pehrson], <br />
|peersemeritus=[mailto:pkerr@mozilla.com Paul Kerr], [mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=/media/webrtc, /dom/media/webrtc, /dom/media/systemservices<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC (Audio/Video)<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC Signaling<br />
|description=Submodule of WebRTC responsible for implementation of PeerConnection API, WebRTC identity, and SDP/JSEP handling<br />
|owner=[mailto:bcampen@mozilla.com Byron Campen]<br />
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:abr@mozilla.com Adam Roach], [mailto:rjesup@mozilla.com Randell Jesup], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]<br />
|peersemeritus=[mailto:ehugg@cisco.com Ethan Hugg]<br />
|group=dev-media<br />
|source_dirs=/media/webrtc/signaling/<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC (Signaling)<br />
}}<br />
<br />
<br />
<noinclude><br />
<br />
===Unassigned Bugzilla Components===<br />
<br />
The following Bugzilla components in the Core project have not been assigned to a module (this list is not exhaustive):<br />
<br />
<pre><br />
Core::Find Backend<br />
Core::General<br />
Core::HTML: Form Submission<br />
Core::History: Global<br />
Core::Image Blocking<br />
Core::Localization<br />
Core::Networking: Domain Lists<br />
Core::Selection<br />
Core::Serializers<br />
Core::Spelling checker<br />
Core::X-remote<br />
Core::XUL<br />
</pre><br />
</noinclude></div>Dkeelerhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/HTTP_Strict_Transport_Security_(HSTS)_Preload_List&diff=1186914SecurityEngineering/HTTP Strict Transport Security (HSTS) Preload List2018-01-16T23:54:34Z<p>Dkeeler: aurora doesn't exist any more</p>
<hr />
<div>Firefox ships with a list of hosts that are considered HTTP Strict Transport Security (HSTS - [https://tools.ietf.org/html/rfc6797 see RFC 6797]) by default. This list is based on [https://www.chromium.org/hsts/ a list Chromium maintains]. The versions of the list as it exists in the various channels of Firefox are available here: [https://hg.mozilla.org/mozilla-central/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-central] [https://hg.mozilla.org/releases/mozilla-beta/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-beta] [https://hg.mozilla.org/releases/mozilla-release/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-release] [https://hg.mozilla.org/releases/mozilla-esr52/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-esr52].<br />
<br />
Every day, an automated job attempts to update the preload list in mozilla-central and mozilla-esr. This involves running an xpcshell script that makes an https request to each candidate host on the list. If xpcshell can connect successfully to a host and receives a "Strict-Transport-Security" header with a max-age value of at least 10886400 (18 weeks in seconds), that host is included in the list (the "preload" directive is ignored). If xpcshell cannot connect successfully to a host or does not receive an appropriate header, that host is not included in the preload list. A corresponding entry in [https://hg.mozilla.org/mozilla-central/file/tip/security/manager/ssl/nsSTSPreloadList.errors this file] may help in determining the underlying error.<br />
<br />
The xpcshell script is [https://hg.mozilla.org/mozilla-central/file/tip/security/manager/tools/getHSTSPreloadList.js here]. Output from the automated job as run on each branch is available here: [https://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-central-linux64/ mozilla-central] [https://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-esr52-linux64/ mozilla-esr52] (search for "periodicupdate").<br />
<br />
To guard against accidentally dropping a host from the list due to intermittent network issues or an active attacker, if a host is already on the preload list in Firefox but cannot be reached, the script keeps it on the preload list. For a host to be removed from Firefox's preload list, it must be accessible when the update script runs and it must either not send a Strict-Transport-Security header or it must send the header with a max-age less than 10886400.<br />
<br />
The preload list has a built-in expiration time that is 18 weeks from when the list was most recently updated.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/HTTP_Strict_Transport_Security_(HSTS)_Preload_List&diff=1186911SecurityEngineering/HTTP Strict Transport Security (HSTS) Preload List2018-01-16T23:49:06Z<p>Dkeeler: s/esr45/esr52/</p>
<hr />
<div>Firefox ships with a list of hosts that are considered HTTP Strict Transport Security (HSTS - [https://tools.ietf.org/html/rfc6797 see RFC 6797]) by default. This list is based on [https://www.chromium.org/hsts/ a list Chromium maintains]. The versions of the list as it exists in the various channels of Firefox are available here: [https://hg.mozilla.org/mozilla-central/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-central] [https://hg.mozilla.org/releases/mozilla-aurora/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-aurora] [https://hg.mozilla.org/releases/mozilla-beta/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-beta] [https://hg.mozilla.org/releases/mozilla-release/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-release] [https://hg.mozilla.org/releases/mozilla-esr52/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-esr52].<br />
<br />
Every day, an automated job attempts to update the preload list in mozilla-central, mozilla-aurora, and mozilla-esr. This involves running an xpcshell script that makes an https request to each candidate host on the list. If xpcshell can connect successfully to a host and receives a "Strict-Transport-Security" header with a max-age value of at least 10886400 (18 weeks in seconds), that host is included in the list (the "preload" directive is ignored). If xpcshell cannot connect successfully to a host or does not receive an appropriate header, that host is not included in the preload list. A corresponding entry in [https://hg.mozilla.org/mozilla-central/file/tip/security/manager/ssl/nsSTSPreloadList.errors this file] may help in determining the underlying error.<br />
<br />
The xpcshell script is [https://hg.mozilla.org/mozilla-central/file/tip/security/manager/tools/getHSTSPreloadList.js here]. Output from the automated job as run on each branch is available here: [https://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-central-linux64/ mozilla-central] [https://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-aurora-linux64/ mozilla-aurora] [https://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-esr52-linux64/ mozilla-esr52] (search for "periodicupdate").<br />
<br />
To guard against accidentally dropping a host from the list due to intermittent network issues or an active attacker, if a host is already on the preload list in Firefox but cannot be reached, the script keeps it on the preload list. For a host to be removed from Firefox's preload list, it must be accessible when the update script runs and it must either not send a Strict-Transport-Security header or it must send the header with a max-age less than 10886400.<br />
<br />
The preload list has a built-in expiration time that is 18 weeks from when the list was most recently updated.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/NSS_Startup_and_Shutdown_in_Gecko&diff=1185544SecurityEngineering/NSS Startup and Shutdown in Gecko2017-12-07T20:38:32Z<p>Dkeeler: remove "not shutting down nss section" because we can't not</p>
<hr />
<div>This is an informational document outlining the modernization and simplification of NSS startup and shutdown in Gecko. It is organized in three parts: the current setup, the desired setup, and a roadmap for achieving the desired setup. If the current date is later than 1 November 2016, this document is likely out of date.<br />
<br />
=== The Current Setup ===<br />
Classes in PSM (and other parts of Gecko) implement a number of interfaces that require NSS functionality. Instantiating any of these classes causes the PSM component to be initialized. This initialization starts a few services needed by certificate verification. It also performs the initialization of NSS. This involves calling the overall NSS_Initialize function as well as some configuration options like only enabling specific cipher suites and loading the trust anchors for certificate verification.<br />
<br />
The PSM component observes a number of events, including notification of profile changes, preference changes, and XPCOM shutdown. Upon receiving the "profile-before-change" notification, the PSM component releases all NSS resources held by PSM objects and calls NSS_Shutdown. Consequently, whenever a PSM object attempts to use an NSS resource or call an NSS function, it first must check if NSS has been shut down. This is coordinated by having such classes inherit from nsNSSShutDownObject. At each point NSS resources are used, these classes first acquire an nsNSSShutDownPreventionLock and check isAlreadyShutDown() (see nsNSSShutDown.h).<br />
<br />
As a consequence of this design, when implementing new functionality that uses NSS, it is easy to do the wrong thing. For instance, code that merely calls NSS functions but do not hold NSS resources may forget to check and prevent NSS from shutting down during the use of that function. Another common mistake is to acquire the nsNSSShutDownPreventionLock but not actually check if NSS has been shut down. These have often led to shutdown crashes (see for example [https://bugzilla.mozilla.org/show_bug.cgi?id=1114741 bug 1114741], [https://bugzilla.mozilla.org/show_bug.cgi?id=1046221 bug 1046221], [https://bugzilla.mozilla.org/show_bug.cgi?id=1029173 bug 1029173], and [https://bugzilla.mozilla.org/show_bug.cgi?id=911336 bug 911336]).<br />
<br />
=== The Desired Setup ===<br />
NSS should be initialized exactly once and shut down exactly once. Code that uses it should only be able to run after NSS is guaranteed to be initialized. While such code is running, it should prevent NSS from being shut down out from under it. When NSS is about to be shut down, all NSS resources held by the platform should be released. Any NSS resource leaks as detected by NSS_Shutdown should be fatal in debug builds. Once NSS has been shut down (upon notification that the entire process is shutting down), all methods that would use NSS must first check for this and return an error.<br />
<br />
Writing new code that correctly deals with these restrictions should be easy.<br />
<br />
=== How to Get There ===<br />
* Remove unused and/or unnecessary cruft from PSM/NSS initialization ([https://bugzilla.mozilla.org/show_bug.cgi?id=1215267 bug 1215267])<br />
** nsPSMUITracker has already been removed: [https://bugzilla.mozilla.org/show_bug.cgi?id=1215690 bug 1215690])<br />
** Profile change event handling: [https://bugzilla.mozilla.org/show_bug.cgi?id=1222179 bug 1222179]<br />
** (etc.)<br />
* Fix all NSS shutdown leaks: [https://bugzilla.mozilla.org/show_bug.cgi?id=1230312 bug 1230312]<br />
* Make NSS shutdown leaks fatal<br />
* Handle the case where an object that needs to be tracked to free resources on NSS shutdown is created before NSS is initialized (this should and can be made to work - [https://bugzilla.mozilla.org/show_bug.cgi?id=1235634 bug 1235634])<br />
* Separate NSS-only initialization from PSM component initialization<br />
* Ensure NSS is initialized before execution reaches any code that requires it<br />
* Provide a better mechanism for preventing NSS from shutting down (and checking if it has already shut down)<br />
** Currently the only way to do this that (mostly) works is for a class to implement the nsNSSShutDownObject mechanism, acquire an nsNSSShutDownPreventionLock and check isAlreadyShutDown. It should be possible to perform the same steps without implementing nsNSSShutDownObject (indeed, this would be better, since that interface has more to do with releasing long-lived NSS resources at shutdown). Furthermore, this mechanism doesn't entirely work, because if an object that implements nsNSSShutDownObject is instantiated after NSS has been shut down, isAlreadyShutDown will actually return false.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/NSS_Startup_and_Shutdown_in_Gecko&diff=1185447SecurityEngineering/NSS Startup and Shutdown in Gecko2017-12-06T21:03:11Z<p>Dkeeler: update with plan to not shut down NSS</p>
<hr />
<div>This is an informational document outlining the modernization and simplification of NSS startup and shutdown in Gecko. It is organized in three parts: the current setup, the desired setup, and a roadmap for achieving the desired setup. If the current date is later than 1 November 2016, this document is likely out of date.<br />
<br />
=== The Current Setup ===<br />
Classes in PSM (and other parts of Gecko) implement a number of interfaces that require NSS functionality. Instantiating any of these classes causes the PSM component to be initialized. This initialization starts a few services needed by certificate verification. It also performs the initialization of NSS. This involves calling the overall NSS_Initialize function as well as some configuration options like only enabling specific cipher suites and loading the trust anchors for certificate verification.<br />
<br />
The PSM component observes a number of events, including notification of profile changes, preference changes, and XPCOM shutdown. Upon receiving the "profile-before-change" notification, the PSM component releases all NSS resources held by PSM objects and calls NSS_Shutdown. Consequently, whenever a PSM object attempts to use an NSS resource or call an NSS function, it first must check if NSS has been shut down. This is coordinated by having such classes inherit from nsNSSShutDownObject. At each point NSS resources are used, these classes first acquire an nsNSSShutDownPreventionLock and check isAlreadyShutDown() (see nsNSSShutDown.h).<br />
<br />
As a consequence of this design, when implementing new functionality that uses NSS, it is easy to do the wrong thing. For instance, code that merely calls NSS functions but do not hold NSS resources may forget to check and prevent NSS from shutting down during the use of that function. Another common mistake is to acquire the nsNSSShutDownPreventionLock but not actually check if NSS has been shut down. These have often led to shutdown crashes (see for example [https://bugzilla.mozilla.org/show_bug.cgi?id=1114741 bug 1114741], [https://bugzilla.mozilla.org/show_bug.cgi?id=1046221 bug 1046221], [https://bugzilla.mozilla.org/show_bug.cgi?id=1029173 bug 1029173], and [https://bugzilla.mozilla.org/show_bug.cgi?id=911336 bug 911336]).<br />
<br />
=== The Desired Setup ===<br />
NSS should be initialized exactly once and shut down exactly once. Code that uses it should only be able to run after NSS is guaranteed to be initialized. While such code is running, it should prevent NSS from being shut down out from under it. When NSS is about to be shut down, all NSS resources held by the platform should be released. Any NSS resource leaks as detected by NSS_Shutdown should be fatal in debug builds. Once NSS has been shut down (upon notification that the entire process is shutting down), all methods that would use NSS must first check for this and return an error.<br />
<br />
Writing new code that correctly deals with these restrictions should be easy.<br />
<br />
=== How to Get There ===<br />
* Remove unused and/or unnecessary cruft from PSM/NSS initialization ([https://bugzilla.mozilla.org/show_bug.cgi?id=1215267 bug 1215267])<br />
** nsPSMUITracker has already been removed: [https://bugzilla.mozilla.org/show_bug.cgi?id=1215690 bug 1215690])<br />
** Profile change event handling: [https://bugzilla.mozilla.org/show_bug.cgi?id=1222179 bug 1222179]<br />
** (etc.)<br />
* Fix all NSS shutdown leaks: [https://bugzilla.mozilla.org/show_bug.cgi?id=1230312 bug 1230312]<br />
* Make NSS shutdown leaks fatal<br />
* Handle the case where an object that needs to be tracked to free resources on NSS shutdown is created before NSS is initialized (this should and can be made to work - [https://bugzilla.mozilla.org/show_bug.cgi?id=1235634 bug 1235634])<br />
* Separate NSS-only initialization from PSM component initialization<br />
* Ensure NSS is initialized before execution reaches any code that requires it<br />
* Provide a better mechanism for preventing NSS from shutting down (and checking if it has already shut down)<br />
** Currently the only way to do this that (mostly) works is for a class to implement the nsNSSShutDownObject mechanism, acquire an nsNSSShutDownPreventionLock and check isAlreadyShutDown. It should be possible to perform the same steps without implementing nsNSSShutDownObject (indeed, this would be better, since that interface has more to do with releasing long-lived NSS resources at shutdown). Furthermore, this mechanism doesn't entirely work, because if an object that implements nsNSSShutDownObject is instantiated after NSS has been shut down, isAlreadyShutDown will actually return false.<br />
<br />
==== Potentially Not Shutting Down NSS ====<br />
Properly implementing the coordinated shutdown of NSS has, to date, proved intractable. For architectural reasons and due to the significant complexity involved, attempting to shut down NSS in the way described in this document has been an ongoing source of crashes and hangs in Firefox. To that end, we have been exploring the possibility of not shutting down NSS at all. For this to work, we have had to address a number of potential concerns.<br />
<br />
Certificate and key database corruption: In theory, if Firefox were to exit without coordinating with NSS, data stored in the certificate and key databases (backed by BerkeleyDB) could be lost. To mitigate this, we have migrated to using the sqlite-backed implementation. The databases are now journaled, and short of a bug in sqlite, we do not anticipate data loss due to database corruption.<br />
<br />
PKCS#11 devices: In theory, if Firefox were to exit without coordinating with NSS and thus any attached PKCS#11 devices, data could be lost on these devices. However, it is our understanding that these devices must be robust against unexpected physical removal. Uncoordinated shutdown should present no worse a risk to user data.<br />
<br />
FIPS 140-2 mode: While Mozilla does not ship a version of Firefox that supports FIPS mode out of the box, Red Hat does. It is our understanding that clearing key material is a requirement of FIPS and that not shutting down NSS may pose a problem for this requirement. [https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp3070.pdf Red Hat's FIPS 140-2 Security Policy] specifies that the application (i.e. Firefox) using the module (i.e. NSS) is responsible for zeroization of key material. More specifically, it says "All plaintext secret and private keys must be zeroized when the Module is shut down (with a FC_Finalize call), reinitialized (with a FC_InitToken call), or when the session is closed (with a FC_CloseSession or FC_CloseAllSessions call)." Thus, if Firefox never shuts down NSS, this requirement is trivially met.<br />
<br />
Leak detection: By not shutting down NSS, technically we leak some allocated memory until shutdown. This could cause problems if our test infrastructure detected and reported these leaks. However, it appears not to (which itself is somewhat concerning). In any case, we will have to deal with this if and when we can detect these leaks.<br />
<br />
Given that these concerns all have at least a preliminary answer, we will move forward with attempting to not shut down NSS in Firefox. This may expose unexpected issues that may lead to a reassessment of the situation, so this will be on a trial basis only in Nightly.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=User:Dkeeler&diff=1185444User:Dkeeler2017-12-06T20:32:43Z<p>Dkeeler: update irc channels</p>
<hr />
<div>*irc: keeler (#security)<br />
*email: d[irc name]@mozilla.com</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/PSM_Bug_Triage&diff=1184283SecurityEngineering/PSM Bug Triage2017-11-16T00:52:15Z<p>Dkeeler: add a note to indicate that P1 really means we're actively working on this</p>
<hr />
<div>== Bug Triage in PSM ==<br />
PSM essentially consists of Gecko code in [https://dxr.mozilla.org/mozilla-central/source/security security/] that is not in any of the subdirectories [https://dxr.mozilla.org/mozilla-central/source/security/nss nss/], [https://dxr.mozilla.org/mozilla-central/source/security/patches patches/], or [https://dxr.mozilla.org/mozilla-central/source/security/sandbox sandbox/]. The Bugzilla product/component for PSM is [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&component=Security%3A%20PSM&product=Core Core :: Security: PSM].<br />
<br />
For team interoperability, PSM follows the new standardized [[Bugmasters/Process/Triage|Triage]] process. In short, every new bug should either be prioritized as P1, P2, P3, or P5, moved to a different component, or needinfo should be requested from someone. P1 means the bug should be fixed before the current Nightly branches to Beta (and even uplifted as appropriate). P2 means the bug will be worked on "next" (basically, after P1s are taken care of). P3 means the bug is in the "should be fixed" backlog. Tracking or meta bugs are also P3. P5 is for bugs where patches would be reviewed and taken from contributors if appropriate, but otherwise won't be worked on. If a bug has had an unanswered needinfo flag for more than 2 weeks, it should be reevaluated (closing as incomplete, needinfo-ing another person, etc.). Similarly, if a P1 bug has no activity for 2 weeks, its priority should be revisited.<br />
<br />
After branching, bug priorities should be revisited. If a P1 is still open, it either needs to be deprioritized (maybe it isn't really a P1) or whatever is blocking its completion needs to be identified and dealt with. P2s and P3s should be considered for promotion to a higher priority. Assignees should be found for any bugs promoted to P1.<br />
<br />
This is the list of [https://bugzilla.mozilla.org/buglist.cgi?product=Core&component=Security%3A%20PSM&priority=--&n1=1&f1=flagtypes.name&o1=substring&v1=needinfo&resolution=---&chfield=&#91;Bug%20creation&#93;&chfieldto=Now&query_format=advanced&chfieldfrom=2016-06-01 untriaged bugs] according to the new process.<br />
<br />
This is the list of [https://bugzilla.mozilla.org/buglist.cgi?product=Core&component=Security%3A%20PSM&f1=flagtypes.name&o1=substring&v1=needinfo&f2=delta_ts&o2=lessthan&v2=14d&resolution=---&query_format=advanced bugs waiting on needinfo for more than 2 weeks] according to the new process.<br />
<br />
Internally, PSM makes use of a number of whiteboard tags for organizational and prioritization purposes. They are as follows:<br />
<br />
* [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=&#91;psm-assigned&#93; &#91;psm-assigned&#93;] are bugs that currently have an assignee. These should all be P1. Ideally there will always be consistent progress on these bugs until they are resolved. If this is not the case, their priority should be reconsidered or any blocking issues should be addressed.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=&#91;psm-backlog&#93; &#91;psm-backlog&#93;] consists of the backlog of bugs we should fix in PSM. These should all be P2 or P3. If they are P1, they should have an assignee and the tag should be &#91;psm-assigned&#93;.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=&#91;psm-cleanup&#93; &#91;psm-cleanup&#93;] consists of code maintenance bugs that would make development easier, but don't directly impact functionality. These are probably mostly P3 or P5.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=&#91;psm-tracking&#93; &#91;psm-tracking&#93;] are meta bugs that track larger work. These should all be P3.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=&#91;psm-deprecation&#93; &#91;psm-deprecation&#93;] are bugs that involve deprecating weak cryptography<br />
* [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=&#91;psm-clientauth&#93; &#91;psm-clientauth&#93;] consists of bugs involved with TLS client authentication<br />
* [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=&#91;psm-smartcard&#93; &#91;psm-smartcard&#93;] are bugs involving PKCS#11 devices<br />
* [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=&#91;psm-documentation&#93; &#91;psm-documentation&#93;] are bugs on writing or improving PSM documentation<br />
* [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=&#91;psm-waiting&#93; &#91;psm-waiting&#93;] are bugs that are waiting on some external input<br />
* [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=&#91;psm-blocked&#93; &#91;psm-blocked&#93;] are bugs that are blocked on other work<br />
* [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=&#91;psm-intermittent&#93; &#91;psm-intermittent&#93;] are bugs filed for intermittently failing tests in PSM<br />
* [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=&#91;psm-would-take&#93; &#91;psm-would-take&#93;] are bugs where we would review patches from contributors, but otherwise we won't be working on them. These should be P5.<br />
<br />
These are the [https://bugzilla.mozilla.org/buglist.cgi?cmdtype=runnamed&namedcmd=psm-untriaged remaining untriaged bugs] with respect to internal bug management.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/PSM_Bug_Triage&diff=1184278SecurityEngineering/PSM Bug Triage2017-11-15T22:26:40Z<p>Dkeeler: remove outdated information, add note about P1 inactivity</p>
<hr />
<div>== Bug Triage in PSM ==<br />
PSM essentially consists of Gecko code in [https://dxr.mozilla.org/mozilla-central/source/security security/] that is not in any of the subdirectories [https://dxr.mozilla.org/mozilla-central/source/security/nss nss/], [https://dxr.mozilla.org/mozilla-central/source/security/patches patches/], or [https://dxr.mozilla.org/mozilla-central/source/security/sandbox sandbox/]. The Bugzilla product/component for PSM is [https://bugzilla.mozilla.org/buglist.cgi?resolution=---&query_format=advanced&component=Security%3A%20PSM&product=Core Core :: Security: PSM].<br />
<br />
For team interoperability, PSM follows the new standardized [[Bugmasters/Process/Triage|Triage]] process. In short, every new bug should either be prioritized as P1, P2, P3, or P5, moved to a different component, or needinfo should be requested from someone. P1 means the bug should be fixed before the current Nightly branches to Beta (and even uplifted as appropriate). P2 means the bug will be worked on "next" (basically, after P1s are taken care of). P3 means the bug is in the "should be fixed" backlog. Tracking or meta bugs are also P3. P5 is for bugs where patches would be reviewed and taken from contributors if appropriate, but otherwise won't be worked on. If a bug has had an unanswered needinfo flag for more than 2 weeks, it should be reevaluated (closing as incomplete, needinfo-ing another person, etc.). Similarly, if a P1 bug has no activity for 2 weeks, its priority should be revisited.<br />
<br />
After branching, bug priorities should be revisited. If a P1 is still open, it either needs to be deprioritized (maybe it isn't really a P1) or whatever is blocking its completion needs to be identified and dealt with. P2s and P3s should be considered for promotion to a higher priority. Assignees should be found for any bugs promoted to P1.<br />
<br />
This is the list of [https://bugzilla.mozilla.org/buglist.cgi?product=Core&component=Security%3A%20PSM&priority=--&n1=1&f1=flagtypes.name&o1=substring&v1=needinfo&resolution=---&chfield=&#91;Bug%20creation&#93;&chfieldto=Now&query_format=advanced&chfieldfrom=2016-06-01 untriaged bugs] according to the new process.<br />
<br />
This is the list of [https://bugzilla.mozilla.org/buglist.cgi?product=Core&component=Security%3A%20PSM&f1=flagtypes.name&o1=substring&v1=needinfo&f2=delta_ts&o2=lessthan&v2=14d&resolution=---&query_format=advanced bugs waiting on needinfo for more than 2 weeks] according to the new process.<br />
<br />
Internally, PSM makes use of a number of whiteboard tags for organizational and prioritization purposes. They are as follows:<br />
<br />
* [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=&#91;psm-assigned&#93; &#91;psm-assigned&#93;] are bugs that currently have an assignee. These should all be P1.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=&#91;psm-backlog&#93; &#91;psm-backlog&#93;] consists of the backlog of bugs we should fix in PSM. These should all be P2 or P3. If they are P1, they should have an assignee and the tag should be &#91;psm-assigned&#93;.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=&#91;psm-cleanup&#93; &#91;psm-cleanup&#93;] consists of code maintenance bugs that would make development easier, but don't directly impact functionality. These are probably mostly P3 or P5.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=&#91;psm-tracking&#93; &#91;psm-tracking&#93;] are meta bugs that track larger work. These should all be P3.<br />
* [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=&#91;psm-deprecation&#93; &#91;psm-deprecation&#93;] are bugs that involve deprecating weak cryptography<br />
* [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=&#91;psm-clientauth&#93; &#91;psm-clientauth&#93;] consists of bugs involved with TLS client authentication<br />
* [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=&#91;psm-smartcard&#93; &#91;psm-smartcard&#93;] are bugs involving PKCS#11 devices<br />
* [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=&#91;psm-documentation&#93; &#91;psm-documentation&#93;] are bugs on writing or improving PSM documentation<br />
* [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=&#91;psm-waiting&#93; &#91;psm-waiting&#93;] are bugs that are waiting on some external input<br />
* [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=&#91;psm-blocked&#93; &#91;psm-blocked&#93;] are bugs that are blocked on other work<br />
* [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=&#91;psm-intermittent&#93; &#91;psm-intermittent&#93;] are bugs filed for intermittently failing tests in PSM<br />
* [https://bugzilla.mozilla.org/buglist.cgi?quicksearch=&#91;psm-would-take&#93; &#91;psm-would-take&#93;] are bugs where we would review patches from contributors, but otherwise we won't be working on them. These should be P5.<br />
<br />
These are the [https://bugzilla.mozilla.org/buglist.cgi?cmdtype=runnamed&namedcmd=psm-untriaged remaining untriaged bugs] with respect to internal bug management.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/Public_Key_Pinning&diff=1180397SecurityEngineering/Public Key Pinning2017-09-13T17:29:58Z<p>Dkeeler: remove dead link to dashboard</p>
<hr />
<div>== Background ==<br />
<br />
Public Key Pinning is a mechanism for sites to specify which certificate authorities have issued valid certs for that site, and for user-agents to reject TLS connections to those sites if the certificate is not issued by a known-good CA. Public key pinning prevents man-in-the-middle attacks due to rogue CAs not on the site's list (see the Diginotar attack which Chrome detected and we did not: https://blog.mozilla.org/security/2011/08/29/fraudulent-google-com-certificate/). <br />
<br />
The feature binds a set of hashes public keys to a domain name such that when connecting to a site using TLS the browser ensures that there is an intersection between the public keys in the computed trust chain and the set of fingerprints associated with that domain. This check is done during the certificate verification phase of the connection, before any data is sent or processed by the browser. In particular we are pinning the sha256 digest of the der encoded subject public key info. In order to reduce rejections, Firefox computes all potential trust chains before deciding that are no valid pins.<br />
<br />
== Implementation status ==<br />
Firefox 32 on desktop and later has the ability to enforce built-in pinsets, or mappings of public key information to domains ({{bug|744204}}).<br />
<br />
Pinning is supported in Firefox 34 and later on Android.<br />
<br />
We will:<br />
# Pin all of the sites that Chrome already does (Google, Twitter) by importing chromium's pinset.<br />
# Pin our own sites after auditing them and cleaning them up.<br />
# Pin other popular sites like Facebook that are in good shape already (with their cooperation, of course)<br />
<br />
=== New sites pinned in Firefox 32 ===<br />
* Twitter: twitter.com, api.twitter.com, business.twitter.com, dev.twitter.com, mobile.twitter.com, oauth.twitter.com, platform.twitter.com, twimg.com, www.twitter.com<br />
* AMO: *.addons.mozilla.org, *.addons.mozilla.net<br />
* Mozilla CDN: *.cdn.mozilla.{org,net}, *.media.mozilla.com<br />
<br />
=== New sites pinned in Firefox 33 ===<br />
* Twitter: *.twitter.com (expanded coverage from 32)<br />
* Google: too many to list (see everything from https://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json with the "google" pinset)<br />
<br />
=== New sites pinned in Firefox 34 ===<br />
* Firefox accounts: *.accounts.firefox.com<br />
* TOR<br />
* Dropbox: www.dropbox.com, dropbox.com<br />
<br />
Tracking bug for pinning all the things: {{bug|1004350}}<br />
<br />
== How to use pinning ==<br />
Starting with FF 32, it's on by default, so you don't have to do anything. The pinning level is enforced by a pref, security.cert_pinning.enforcement_level<br />
<br />
* 0. Pinning disabled<br />
* 1. Allow User MITM (pinning not enforced if the trust anchor is a user inserted CA, default)<br />
* 2. Strict. Pinning is always enforced.<br />
* 3. Enforce test mode.<br />
<br />
== More information ==<br />
* [[SecurityEngineering/Public_Key_Pinning/SiteOperators]]<br />
* [[SecurityEngineering/Public_Key_Pinning/ReleaseEngineering]]<br />
* [[SecurityEngineering/Public_Key_Pinning/Implementation_Details]]<br />
<br />
== Public Key Pinning Extension for HTTP ==<br />
<br />
In the future, we would like to support dynamic pinsets rather than relying on built-in ones. HTTP Public Key Pinning (HPKP) [http://tools.ietf.org/html/draft-ietf-websec-key-pinning-12] is an HTTP header that allows sites to announce their pinset. It relies on "clean load" in order to provide a similar level of assurance as built-in pins.<br />
<br />
Tracking bug: {{bug|787133}}</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/Public_Key_Pinning/SiteOperators&diff=1180396SecurityEngineering/Public Key Pinning/SiteOperators2017-09-13T17:28:54Z<p>Dkeeler: update with most recent information</p>
<hr />
<div>== Help, I need to change my pinset! ==<br />
File a bug under the Core::Security:PSM component with changes to your pinset:<br />
https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Security%3A%20PSM&short_desc=%28pinset%20change%20request%29<br />
<br />
In case of emergency, email pinning@mozilla.org or security@mozilla.org if that fails. Please file a bug in any case.<br />
<br />
== How much notice do I need to give for pinset changes? ==<br />
To determine how long it will take for a change in Nightly to be released, see the release calendar: [[RapidRelease/Calendar]]. We prefer not to make pinset changes once Firefox is in Beta.<br />
<br />
== I have an emergency! ==<br />
In emergency circumstances, we can release an emergency update to the stable channel to change your pinset in 24 hours. No one wants to do this. We will consider removing you from the pinning program altogether in this event.<br />
<br />
== How can you test your pins? ==<br />
# Install desktop Firefox 32 or later.<br />
# Go to about:config and make sure that security.cert_pinning.enforcement_level = 1 (allow user-specified trust anchors to override pinning checks) or 2 (strict mode). There is an additional enforcement level, 3, for enforcing test pins if you'd like to enable that instead. Normally test pins are used only for counting pin violations, but not actually enforcing them. You will have to coordinate with the pinning team in order to verify which of your pins are in test mode, and which are in production mode.<br />
# Visit https://pinning-test.badssl.com/ to make sure you see a warning.<br />
# Visit all your sites!<br />
<br />
== What platforms does this affect? ==<br />
Pinning has been enabled on Firefox for Desktop and Firefox for Android. By default, pinning checks are skipped for user-specified trust anchors.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=CA:AddRootToFirefox&diff=1169713CA:AddRootToFirefox2017-04-28T17:34:36Z<p>Dkeeler: /* AutoConfig via JavaScript */ update code snippet and comment about nickname parameter</p>
<hr />
<div>= Installing Certificates Into Firefox =<br />
<br />
There are lots of organizations that use their own certificate authorities (CAs) to issue certificates for their internal servers. Since Firefox does not use the operating system's certificate store by default, these have to be manually added into Firefox. This page will cover how to get those CAs into Firefox.<br />
<br />
== Experimental Built-in Windows Support ==<br />
As of version 49, Firefox can be experimentally configured to automatically search for and import CAs that have been added to the Windows certificate store by a user or administrator. To do so, set the preference "security.enterprise_roots.enabled" to true. In this mode, Firefox will inspect the HKLM\SOFTWARE\Microsoft\SystemCertificates registry location (corresponding to the API flag CERT_SYSTEM_STORE_LOCAL_MACHINE) for CAs that are trusted to issue certificates for TLS web server authentication. Any such CAs will be imported and trusted by Firefox, although note that they may not appear in the Firefox's certificate manager. It is expected that administration of these CAs (e.g. trust configuration) will occur via built-in Windows tools or other 3rd party utilities. Note also that for such changes to take effect in Firefox either the preference will have to be toggled off and on again or Firefox will have to be restarted. As this feature evolves, this may be handled automatically for ease of use.<br />
<br />
As of version 52, Firefox will also search the registry locations HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\Root\Certificates and HKLM\SOFTWARE\Microsoft\EnterpriseCertificates\Root\Certificates (corresponding to the API flags CERT_SYSTEM_STORE_LOCAL_MACHINE_GROUP_POLICY and CERT_SYSTEM_STORE_LOCAL_MACHINE_ENTERPRISE, respectively).<br />
<br />
=== Credits ===<br />
The original content in this wiki page was copied (with permission) from [http://mike.kaply.com/2015/02/10/installing-certificates-into-firefox/ Mike Kaply's Blog].<br />
<br />
== CCK2 ==<br />
<br />
The easiest way to get your CAs into Firefox is to use [http://mike.kaply.com/cck2/ CCK2]. [http://mike.kaply.com/cck2/ CCK2] allows certificate authorities and server certificates to be installed into the browser. It supports PEM, DER and text. It also allows you to designate certificate overrides (sites where certificate errors are ignored). Just go to the certificate page and point to either a URL or a local file where the certificate is contained.<br />
<br />
* CCK2 is a [https://addons.mozilla.org/en-US/firefox/addon/cck2wizard/?src=kaply.com Firefox Add-On]<br />
* [http://mike.kaply.com/addons/cck2/cck2-support/ CCK2 Support]<br />
<br />
== AutoConfig via JavaScript ==<br />
<br />
If you're using AutoConfig without CCK2, you can still use [https://dxr.mozilla.org/mozilla-central/rev/e17cbb839dd225a2da7e5d5bec43cf94e11749d8/security/manager/ssl/nsIX509CertDB.idl#353 the API] that the CCK2 uses to install certificate authorities.<br />
<br />
This is based on knowledge from here:<br />
https://developer.mozilla.org/en-US/Firefox/Enterprise_deployment<br />
<br />
Place the [https://bug1359127.bmoattachments.org/attachment.cgi?id=8862864 autoconfig.js] file in one of these directories:<br />
* on Windows defaults\pref<br />
* on Mac Firefox.app/Contents/Resources/defaults/pref<br />
* on Linux defaults/pref<br />
<br />
Place the mozilla.cfg file (the autoconfig.js file makes reference to it) besides the Firefox executable:<br />
<pre><br />
var Cc = Components.classes;<br />
var Ci = Components.interfaces;<br />
var certdb = Cc["@mozilla.org/security/x509certdb;1"].getService(Ci.nsIX509CertDB);<br />
<br />
cert = "MIIHPT...zTMVD"; // This should be the certificate content with no line breaks at all.<br />
certdb.addCertFromBase64(cert, "C,C,C", "");<br />
</pre><br />
<br />
The three Cs mean to trust the certficate for servers, email and objects. The third parameter is the name, but it is ignored (as of Firefox 53, the third parameter has been removed from the API and should not be included). If you want to install binary certificates, things get more complicated. In that case, I'd definitely recommend the [http://mike.kaply.com/cck2/ CCK2].<br />
<br />
== PolicyPak ==<br />
<br />
[http://www.policypak.com/products/manage-firefox-with-group-policy.html PolicyPak] supports adding certificate authorites to Firefox via Group Policy.<br />
<br />
== Preload the certificate databases ==<br />
<br />
Some people create a new profile in Firefox, install the certificates they need, and then distribute the various db files (cert8.db, key3.db and secmod.db) into new profiles using [http://mike.kaply.com/2012/03/30/customizing-firefox-default-profiles/ this method]. This is not the recommended approach, and this method only works for new profiles.<br />
<br />
== certutil ==<br />
<br />
If you're a real diehard, you can use [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Tools/certutil certutil] to update the Firefox certificate databases from the command line.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=CA:AddRootToFirefox&diff=1169178CA:AddRootToFirefox2017-04-24T17:32:02Z<p>Dkeeler: /* AutoConfig via JavaScript */ update link to addCertFromBase64 API</p>
<hr />
<div>= Installing Certificates Into Firefox =<br />
<br />
There are lots of organizations that use their own certificate authorities (CAs) to issue certificates for their internal servers. Since Firefox does not use the operating system's certificate store by default, these have to be manually added into Firefox. This page will cover how to get those CAs into Firefox.<br />
<br />
== Experimental Built-in Windows Support ==<br />
As of version 49, Firefox can be experimentally configured to automatically search for and import CAs that have been added to the Windows certificate store by a user or administrator. To do so, set the preference "security.enterprise_roots.enabled" to true. In this mode, Firefox will inspect the HKLM\SOFTWARE\Microsoft\SystemCertificates registry location (corresponding to the API flag CERT_SYSTEM_STORE_LOCAL_MACHINE) for CAs that are trusted to issue certificates for TLS web server authentication. Any such CAs will be imported and trusted by Firefox, although note that they may not appear in the Firefox's certificate manager. It is expected that administration of these CAs (e.g. trust configuration) will occur via built-in Windows tools or other 3rd party utilities. Note also that for such changes to take effect in Firefox either the preference will have to be toggled off and on again or Firefox will have to be restarted. As this feature evolves, this may be handled automatically for ease of use.<br />
<br />
As of version 52, Firefox will also search the registry locations HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\Root\Certificates and HKLM\SOFTWARE\Microsoft\EnterpriseCertificates\Root\Certificates (corresponding to the API flags CERT_SYSTEM_STORE_LOCAL_MACHINE_GROUP_POLICY and CERT_SYSTEM_STORE_LOCAL_MACHINE_ENTERPRISE, respectively).<br />
<br />
=== Credits ===<br />
The original content in this wiki page was copied (with permission) from [http://mike.kaply.com/2015/02/10/installing-certificates-into-firefox/ Mike Kaply's Blog].<br />
<br />
== CCK2 ==<br />
<br />
The easiest way to get your CAs into Firefox is to use [http://mike.kaply.com/cck2/ CCK2]. [http://mike.kaply.com/cck2/ CCK2] allows certificate authorities and server certificates to be installed into the browser. It supports PEM, DER and text. It also allows you to designate certificate overrides (sites where certificate errors are ignored). Just go to the certificate page and point to either a URL or a local file where the certificate is contained.<br />
<br />
* CCK2 is a [https://addons.mozilla.org/en-US/firefox/addon/cck2wizard/?src=kaply.com Firefox Add-On]<br />
* [http://mike.kaply.com/addons/cck2/cck2-support/ CCK2 Support]<br />
<br />
== AutoConfig via JavaScript ==<br />
<br />
If you're using AutoConfig without CCK2, you can still use [https://dxr.mozilla.org/mozilla-central/rev/e17cbb839dd225a2da7e5d5bec43cf94e11749d8/security/manager/ssl/nsIX509CertDB.idl#353 the API] that the CCK2 uses to install certificate authorities. Here's what it looks like to install the [http://www.cacert.org/index.php?id=3 cacert.org root certificate]:<br />
<br />
# var certdb = Cc["@mozilla.org/security/x509certdb;1"].getService(Ci.nsIX509CertDB);<br />
# var certdb2 = certdb;<br />
# try {<br />
# certdb2 = Cc["@mozilla.org/security/x509certdb;1"].getService(Ci.nsIX509CertDB2);<br />
# } catch (e) {}<br />
# cert = "MIIHPT...zTMVD"; // This should be the certificate content with no line breaks at all.<br />
# certdb2.addCertFromBase64(cert, "C,C,C", "");<br />
<br />
The three Cs mean to trust the certficate for servers, email and objects. The third parameter is the name, but it is ignored. If you want to install binary certificates, things get more complicated. In that case, I'd definitely recommend the [http://mike.kaply.com/cck2/ CCK2].<br />
<br />
== PolicyPak ==<br />
<br />
[http://www.policypak.com/products/manage-firefox-with-group-policy.html PolicyPak] supports adding certificate authorites to Firefox via Group Policy.<br />
<br />
== Preload the certificate databases ==<br />
<br />
Some people create a new profile in Firefox, install the certificates they need, and then distribute the various db files (cert8.db, key3.db and secmod.db) into new profiles using [http://mike.kaply.com/2012/03/30/customizing-firefox-default-profiles/ this method]. This is not the recommended approach, and this method only works for new profiles.<br />
<br />
== certutil ==<br />
<br />
If you're a real diehard, you can use [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Tools/certutil certutil] to update the Firefox certificate databases from the command line.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/HTTP_Strict_Transport_Security_(HSTS)_Preload_List&diff=1166765SecurityEngineering/HTTP Strict Transport Security (HSTS) Preload List2017-03-27T19:27:22Z<p>Dkeeler: the automated job now runs every day</p>
<hr />
<div>Firefox ships with a list of hosts that are considered HTTP Strict Transport Security (HSTS - [https://tools.ietf.org/html/rfc6797 see RFC 6797]) by default. This list is based on [https://www.chromium.org/hsts/ a list Chromium maintains]. The versions of the list as it exists in the various channels of Firefox are available here: [https://hg.mozilla.org/mozilla-central/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-central] [https://hg.mozilla.org/releases/mozilla-aurora/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-aurora] [https://hg.mozilla.org/releases/mozilla-beta/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-beta] [https://hg.mozilla.org/releases/mozilla-release/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-release] [https://hg.mozilla.org/releases/mozilla-esr45/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-esr45].<br />
<br />
Every day, an automated job attempts to update the preload list in mozilla-central, mozilla-aurora, and mozilla-esr. This involves running an xpcshell script that makes an https request to each candidate host on the list. If xpcshell can connect successfully to a host and receives a "Strict-Transport-Security" header with a max-age value of at least 10886400 (18 weeks in seconds), that host is included in the list (the "preload" directive is ignored). If xpcshell cannot connect successfully to a host or does not receive an appropriate header, that host is not included in the preload list. A corresponding entry in [https://hg.mozilla.org/mozilla-central/file/tip/security/manager/ssl/nsSTSPreloadList.errors this file] may help in determining the underlying error.<br />
<br />
The xpcshell script is [https://hg.mozilla.org/mozilla-central/file/tip/security/manager/tools/getHSTSPreloadList.js here]. Output from the automated job as run on each branch is available here: [https://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-central-linux64/ mozilla-central] [https://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-aurora-linux64/ mozilla-aurora] [https://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-esr45-linux64/ mozilla-esr45] (search for "periodicupdate").<br />
<br />
To guard against accidentally dropping a host from the list due to intermittent network issues or an active attacker, if a host is already on the preload list in Firefox but cannot be reached, the script keeps it on the preload list. For a host to be removed from Firefox's preload list, it must be accessible when the update script runs and it must either not send a Strict-Transport-Security header or it must send the header with a max-age less than 10886400.<br />
<br />
The preload list has a built-in expiration time that is 18 weeks from when the list was most recently updated.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=Security/CryptoEngineering/Platform_Use_of_NSS&diff=1160846Security/CryptoEngineering/Platform Use of NSS2017-01-24T22:56:00Z<p>Dkeeler: /* Loading PKCS#11 Modules */ remove readOnly flag from moduleSpec</p>
<hr />
<div>=== The Current Setup ===<br />
The collection of libraries known as NSS provides various cryptographic and security-related functionality to the platform (Gecko). In most cases, NSS must be initialized before the platform makes use of any function it exposes. Currently this requires initializing PSM, which takes care of finding the profile directory, initializing NSS using the certificate, key, and PKCS#11 module databases in that directory, and other configuration tasks such as enabling approved cipher suites. At that point, the platform is free to use NSS functionality. However, because NSS in theory could be shut down at any point (by the process of shutting down the browser as a whole), code must first acquire a 'nsNSSShutDownPreventionLock' and check if NSS has indeed already been shut down. Similarly, code that holds NSS resources must be aware of the possibility of NSS shutting down and be ready to release those resources by implementing the 'nsNSSShutDownObject' interface. Unfortunately, this scheme is difficult to work with from a development perspective and currently doesn't even cover all eventualities (for instance, if NSS has shut down, for objects created after that point, the "has NSS shut down" check will return the wrong answer).<br />
<br />
=== The Desired Setup ===<br />
The obvious solution would be to make NSS always be available (for some value of "always"). Given that the code using NSS is bound by the lifetime of XPCOM, guaranteeing that NSS be available for any XPCOM service/component seems like a good fit. The first hurdle here is that the profile directory is only available after XPCOM has been initialized (or sometimes not at all, in the case of xpcshell tests that never use a profile directory). Thus, the first significant difference in the new scheme is to initialize NSS early in XPCOM initialization in a memory-only mode where it doesn't open any persistent databases. It can be shut down again late in XPCOM teardown, when any XPCOM code that would use it has been terminated.<br />
<br />
At this point, platform code that relies on NSS can safely run. Moreover, as long as that code doesn't run after XPCOM shutdown (and as long as it properly releases its NSS resources when it's done running), the nsNSSShutDownObject/nsNSSShutDownPreventionLock framework can be removed. This constitutes a major simplification in existing code and any future platform development using NSS.<br />
<br />
The catch, of course, is that the user's persistent certificate, key, and PKCS#11 module databases won't be available when NSS is in this memory-only mode. To address this, PSM can call SECMOD_OpenUserDB with the user's profile directory. This will make these data and modules usable by the platform.<br />
<br />
=== Remaining Issues ===<br />
<br />
==== Use of PK11_GetInternalKeySlot() ====<br />
PK11_GetInternalKeySlot is used to get a handle on the software token that backs the user's persistent certificate and key database. When NSS is initialized in memory-only mode, operations that expect to modify persistent data on this token will fail. Consequently, any platform code that calls PK11_GetInternalKeySlot must instead get a handle on the software slot/token as loaded by the call to SECMOD_OpenUserDB (see above). Similarly, any NSS code that calls PK11_GetInternalKeySlot must be avoided or worked around, as it will not work correctly. For example, CERT_AddTempCertToPerm (which is used to take an existing temporary certificate and save it in the persistent database) is hard-coded to use PK11_GetInternalKeySlot. However, PK11_ImportCert can be used in combination with CERT_ChangeCertTrust in place of CERT_AddTempCertToPerm to save the certificate on a specific slot (in this case, the real persistent database as loaded by SECMOD_OpenUserDB).<br />
<br />
PK11SDR_Encrypt and PK11SDR_Decrypt have no equivalent functions that take a caller-provided slot. Either new functions will have to be added to NSS (e.g. as PK11SDR_EncryptOnSlot and PK11SDR_DecryptOnSlot) or they will have to be reimplemented in PSM. Luckily, these two functions do not call internal NSS APIs and can be easily duplicated in terms of functionality. Doing so might be desirable as it would enable a step towards towards using more modern cryptography to protect the information in the user's key database.<br />
<br />
==== Loading PKCS#11 Modules ====<br />
Currently when a new PKCS#11 module is loaded, its presence is persisted in the user's module database, meaning that it will automatically be loaded the next time the platform runs. When NSS is initialized in memory-only mode, no such database is available and this will not automatically work as before. However, NSS has the ability to load a PKCS#11 module database (and the modules referenced therein) after it has already been initialized. Thus, when the user's profile is available, we merely have to load up the module database and everything should behave as before (NB: we need to check that adding new modules will also work as expected when NSS starts in read-only mode).<br />
<br />
The following code snippet is an example of how this could work (given that the module database is in the directory 'other'):<br />
<br />
#include <stdio.h> <br />
<br />
#include "nss.h" <br />
#include "pk11pub.h" <br />
#include "prerror.h" <br />
#include "secerr.h" <br />
#include "secmod.h" <br />
<br />
void printPRError(const char* message) { <br />
fprintf(stderr, "%s: %s\n", message, PR_ErrorToString(PR_GetError(), 0)); <br />
} <br />
<br />
int main(int argc, char* argv[]) { <br />
if (NSS_NoDB_Init(".") != SECSuccess) { <br />
printPRError("NSS_NoDB_Init failed"); <br />
return 1; <br />
} <br />
<br />
// To load the PKCS#11 modules saved in another NSS secmod.db (in the <br />
// directory 'other'): <br />
char* moduleSpec = "name=\"NSS Internal Module\" parameters=\"configdir='other/' certPrefix='' keyPrefix='' secmod='secmod.db' flags=optimizeSpace updatedir='' updateCertPrefix='' updateKeyPrefix='' updateid='' updateTokenDescription='' \" NSS=\"flags=internal,moduleDB,moduleDBOnly,critical,defaultModDB,internalKeySlot\"";<br />
SECMODModule* module = SECMOD_LoadModule(moduleSpec, NULL, 1); <br />
if (!module) { <br />
printPRError("SECMOD_LoadUserModule failed"); <br />
return 1; <br />
} <br />
<br />
SECMODModuleList* list = SECMOD_GetDefaultModuleList(); <br />
while (list) { <br />
printf("%s\n", list->module->dllName); <br />
list = list->next; <br />
} <br />
<br />
SECMOD_DestroyModule(module); <br />
<br />
if (NSS_Shutdown() != SECSuccess) { <br />
printPRError("NSS_Shutdown failed"); <br />
return 1; <br />
} <br />
return 0; <br />
}<br />
<br />
==== PKCS#11 XPCOM APIs ====<br />
Currently the platform exposes some PKCS#11 module APIs that include such functionality as getting a handle on the internal module, listing known modules, and searching for modules, tokens, and/or slots. Because the user's software token is now not the same as that returned by PK11_GetInternalKeySlot, these APIs must be special-cased to continue to behave as expected. (The issue regarding the undocumented feature of searching for a blank token name returning the internal module has been addressed by [https://bugzilla.mozilla.org/show_bug.cgi?id=1324071 bug 1324071]).<br />
<br />
==== FIPS ====<br />
Continuing to support FIPS with these changes appears to be problematic in two ways. First, since from NSS' perspective the "internal" database is loaded in memory-only mode, that the user put the database in FIPS mode isn't persisted across restarts. This can be addressed by a mechanism similar to or along side that which persists new PKCS#11 modules (see above). Second, turning on FIPS mode appears to unload the real persistent certificate and key database. It may be that this can simply be reloaded as part of the process of enabling FIPS. Further investigation in required here.<br />
<br />
=== Resolved Issues ===<br />
<br />
==== The NSS Certificate Nickname API ====<br />
NSS exposes APIs whereby certificates can be referred to by nickname. Certificates on tokens other than that returned by PK11_GetInternalKeySlot prefix their nickname with the name of the token. Because platform code now must operate on a token that isn't the internal one, this behavior must be worked around by special-casing unprefixed nicknames when using these and related APIs.<br />
<br />
Alternatively, we could remove and/or rework XPCOM interfaces that expose the NSS nickname API and replace them with an equivalent mechanism that doesn't have this and other drawbacks (see the discussion in [https://bugzilla.mozilla.org/show_bug.cgi?id=857627 bug 857627]).<br />
<br />
Update: As of the landing of bug 857627, this shouldn't be an issue any longer.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=Security/CryptoEngineering/Platform_Use_of_NSS&diff=1160675Security/CryptoEngineering/Platform Use of NSS2017-01-23T23:46:49Z<p>Dkeeler: /* Loading New PKCS#11 Modules */ add code snippet for how to implement this</p>
<hr />
<div>=== The Current Setup ===<br />
The collection of libraries known as NSS provides various cryptographic and security-related functionality to the platform (Gecko). In most cases, NSS must be initialized before the platform makes use of any function it exposes. Currently this requires initializing PSM, which takes care of finding the profile directory, initializing NSS using the certificate, key, and PKCS#11 module databases in that directory, and other configuration tasks such as enabling approved cipher suites. At that point, the platform is free to use NSS functionality. However, because NSS in theory could be shut down at any point (by the process of shutting down the browser as a whole), code must first acquire a 'nsNSSShutDownPreventionLock' and check if NSS has indeed already been shut down. Similarly, code that holds NSS resources must be aware of the possibility of NSS shutting down and be ready to release those resources by implementing the 'nsNSSShutDownObject' interface. Unfortunately, this scheme is difficult to work with from a development perspective and currently doesn't even cover all eventualities (for instance, if NSS has shut down, for objects created after that point, the "has NSS shut down" check will return the wrong answer).<br />
<br />
=== The Desired Setup ===<br />
The obvious solution would be to make NSS always be available (for some value of "always"). Given that the code using NSS is bound by the lifetime of XPCOM, guaranteeing that NSS be available for any XPCOM service/component seems like a good fit. The first hurdle here is that the profile directory is only available after XPCOM has been initialized (or sometimes not at all, in the case of xpcshell tests that never use a profile directory). Thus, the first significant difference in the new scheme is to initialize NSS early in XPCOM initialization in a memory-only mode where it doesn't open any persistent databases. It can be shut down again late in XPCOM teardown, when any XPCOM code that would use it has been terminated.<br />
<br />
At this point, platform code that relies on NSS can safely run. Moreover, as long as that code doesn't run after XPCOM shutdown (and as long as it properly releases its NSS resources when it's done running), the nsNSSShutDownObject/nsNSSShutDownPreventionLock framework can be removed. This constitutes a major simplification in existing code and any future platform development using NSS.<br />
<br />
The catch, of course, is that the user's persistent certificate, key, and PKCS#11 module databases won't be available when NSS is in this memory-only mode. To address this, PSM can call SECMOD_OpenUserDB with the user's profile directory. This will make these data and modules usable by the platform.<br />
<br />
=== Remaining Issues ===<br />
<br />
==== Use of PK11_GetInternalKeySlot() ====<br />
PK11_GetInternalKeySlot is used to get a handle on the software token that backs the user's persistent certificate and key database. When NSS is initialized in memory-only mode, operations that expect to modify persistent data on this token will fail. Consequently, any platform code that calls PK11_GetInternalKeySlot must instead get a handle on the software slot/token as loaded by the call to SECMOD_OpenUserDB (see above). Similarly, any NSS code that calls PK11_GetInternalKeySlot must be avoided or worked around, as it will not work correctly. For example, CERT_AddTempCertToPerm (which is used to take an existing temporary certificate and save it in the persistent database) is hard-coded to use PK11_GetInternalKeySlot. However, PK11_ImportCert can be used in combination with CERT_ChangeCertTrust in place of CERT_AddTempCertToPerm to save the certificate on a specific slot (in this case, the real persistent database as loaded by SECMOD_OpenUserDB).<br />
<br />
PK11SDR_Encrypt and PK11SDR_Decrypt have no equivalent functions that take a caller-provided slot. Either new functions will have to be added to NSS (e.g. as PK11SDR_EncryptOnSlot and PK11SDR_DecryptOnSlot) or they will have to be reimplemented in PSM. Luckily, these two functions do not call internal NSS APIs and can be easily duplicated in terms of functionality. Doing so might be desirable as it would enable a step towards towards using more modern cryptography to protect the information in the user's key database.<br />
<br />
==== Loading PKCS#11 Modules ====<br />
Currently when a new PKCS#11 module is loaded, its presence is persisted in the user's module database, meaning that it will automatically be loaded the next time the platform runs. When NSS is initialized in memory-only mode, no such database is available and this will not automatically work as before. However, NSS has the ability to load a PKCS#11 module database (and the modules referenced therein) after it has already been initialized. Thus, when the user's profile is available, we merely have to load up the module database and everything should behave as before (NB: we need to check that adding new modules will also work as expected when NSS starts in read-only mode).<br />
<br />
The following code snippet is an example of how this could work (given that the module database is in the directory 'other'):<br />
<br />
#include <stdio.h> <br />
<br />
#include "nss.h" <br />
#include "pk11pub.h" <br />
#include "prerror.h" <br />
#include "secerr.h" <br />
#include "secmod.h" <br />
<br />
void printPRError(const char* message) { <br />
fprintf(stderr, "%s: %s\n", message, PR_ErrorToString(PR_GetError(), 0)); <br />
} <br />
<br />
int main(int argc, char* argv[]) { <br />
if (NSS_NoDB_Init(".") != SECSuccess) { <br />
printPRError("NSS_NoDB_Init failed"); <br />
return 1; <br />
} <br />
<br />
// To load the PKCS#11 modules saved in another NSS secmod.db (in the <br />
// directory 'other'): <br />
char* moduleSpec = "name=\"NSS Internal Module\" parameters=\"configdir='other/' certPrefix='' keyPrefix='' secmod='secmod.db' flags=readOnly,optimizeSpace updatedir='' updateCertPrefix='' updateKeyPrefix='' updateid='' updateTokenDescription='' \" NSS=\"flags=internal,moduleDB,moduleDBOnly,critical,defaultModDB,internalKeySlot\"";<br />
SECMODModule* module = SECMOD_LoadModule(moduleSpec, NULL, 1); <br />
if (!module) { <br />
printPRError("SECMOD_LoadUserModule failed"); <br />
return 1; <br />
} <br />
<br />
SECMODModuleList* list = SECMOD_GetDefaultModuleList(); <br />
while (list) { <br />
printf("%s\n", list->module->dllName); <br />
list = list->next; <br />
} <br />
<br />
SECMOD_DestroyModule(module); <br />
<br />
if (NSS_Shutdown() != SECSuccess) { <br />
printPRError("NSS_Shutdown failed"); <br />
return 1; <br />
} <br />
return 0; <br />
}<br />
<br />
==== PKCS#11 XPCOM APIs ====<br />
Currently the platform exposes some PKCS#11 module APIs that include such functionality as getting a handle on the internal module, listing known modules, and searching for modules, tokens, and/or slots. Because the user's software token is now not the same as that returned by PK11_GetInternalKeySlot, these APIs must be special-cased to continue to behave as expected. (The issue regarding the undocumented feature of searching for a blank token name returning the internal module has been addressed by [https://bugzilla.mozilla.org/show_bug.cgi?id=1324071 bug 1324071]).<br />
<br />
==== FIPS ====<br />
Continuing to support FIPS with these changes appears to be problematic in two ways. First, since from NSS' perspective the "internal" database is loaded in memory-only mode, that the user put the database in FIPS mode isn't persisted across restarts. This can be addressed by a mechanism similar to or along side that which persists new PKCS#11 modules (see above). Second, turning on FIPS mode appears to unload the real persistent certificate and key database. It may be that this can simply be reloaded as part of the process of enabling FIPS. Further investigation in required here.<br />
<br />
=== Resolved Issues ===<br />
<br />
==== The NSS Certificate Nickname API ====<br />
NSS exposes APIs whereby certificates can be referred to by nickname. Certificates on tokens other than that returned by PK11_GetInternalKeySlot prefix their nickname with the name of the token. Because platform code now must operate on a token that isn't the internal one, this behavior must be worked around by special-casing unprefixed nicknames when using these and related APIs.<br />
<br />
Alternatively, we could remove and/or rework XPCOM interfaces that expose the NSS nickname API and replace them with an equivalent mechanism that doesn't have this and other drawbacks (see the discussion in [https://bugzilla.mozilla.org/show_bug.cgi?id=857627 bug 857627]).<br />
<br />
Update: As of the landing of bug 857627, this shouldn't be an issue any longer.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=Security/CryptoEngineering/SHA-1&diff=1159533Security/CryptoEngineering/SHA-12017-01-13T19:12:55Z<p>Dkeeler: minor edits for clarity/brevity</p>
<hr />
<div>Continuing the plan from the [https://blog.mozilla.org/security/2016/10/18/phasing-out-sha-1-on-the-public-web/ Phasing Out SHA-1 On The Public Web blog post]:<br />
<br />
== MITM Appliances Using SHA-1 ==<br />
One of the challenges involved with disabling SHA-1 is that some of our users are affected by network appliances that man-in-the-middle (MITM) all of Firefox's connections. If their MITM appliance uses SHA-1 from a publicly-trusted root, any action we take on SHA-1 will affect all of their browsing. Note that such a setup would be a considerable violation of the Baseline Requirements.<br />
<br />
== Telemetry Experiment (Dec 2016) ==<br />
This [https://blog.mozilla.org/security/2016/01/06/man-in-the-middle-interfering-with-increased-security/ bit us in January 2016], and seems to necessitate a careful approach. Previously we had no information about how common this might be, so we conducted a Telemetry Experiment where we wrote a simple add-on that connects to a Mozilla HTTPS site and evaluates whether the certificate received is A) the one we expect to be there, and if not B) whether the MITM certificate is using SHA-1 from a publicly-trusted root, and thus would cause user-breakage.<br />
<br />
=== Results ===<br />
Posted in [https://bugzilla.mozilla.org/show_bug.cgi?id=1323851 Bug 1323851]:<br />
<br />
On this dataset, we've confirmed that we can disable SHA-1 for non-built-in-roots <br />
without breaking updates. One analysis dataset is here: [https://gist.github.com/jcjones/098c9ee81213e6816cf372194f45e918]<br />
The final dataset was:<br />
{'isAccum': True,<br />
'rooterrors': Counter({'0f993c8aef97baaf5687140ed59ad1821bb4afacf0aa9a58b5d57a338a3afbcb -12276': 1,<br />
'4348a0e9444c78cb265e058d5e8944b4d84f9662bd26db257f8934a443c70161 0': 2822178,<br />
'687fa451382278fff0c8b11f8d43d576671c6eb2bceab413fb83d965d06d2ff2 -12276': 22,<br />
'73c176434f1bc6d5adf45b0e76e727287c8de57616c1e6e6141a2b2cbc7d8e4c -12276': 1,<br />
'c3846bf24b9e93ca64274c0ec67c1ecc5e024ffcacd2d74019350e81fe546ae4 -12276': 1,<br />
'ff856a2d251dcd88d36656f450126798cfabaade40799c722de4d2b5db36a73a -12276': 1}),<br />
'total_errors': Counter({-16381: 1,<br />
-16379: 11,<br />
-16378: 1,<br />
-12276: 53,<br />
-12173: 1,<br />
-8191: 1,<br />
-8179: 299,<br />
-8162: 14,<br />
-8061: 351,<br />
-8016: 28}),<br />
'total_roots': Counter({u'0f993c8aef97baaf5687140ed59ad1821bb4afacf0aa9a58b5d57a338a3afbcb': 1,<br />
u'4348a0e9444c78cb265e058d5e8944b4d84f9662bd26db257f8934a443c70161': 2822178,<br />
u'687fa451382278fff0c8b11f8d43d576671c6eb2bceab413fb83d965d06d2ff2': 22,<br />
u'73c176434f1bc6d5adf45b0e76e727287c8de57616c1e6e6141a2b2cbc7d8e4c': 1,<br />
u'c3846bf24b9e93ca64274c0ec67c1ecc5e024ffcacd2d74019350e81fe546ae4': 1,<br />
u'ff856a2d251dcd88d36656f450126798cfabaade40799c722de4d2b5db36a73a': 1})}<br />
This means the only instances of having an errorCode=0 (successful connection) are for the <br />
legitimate root. The MITM-esque situations are all combined with SSL_ERROR_BAD_CERT_DOMAIN (code -12276). <br />
Other errors are small and normal-seeming, too:<br />
-16381: (1) MOZILLA_PKIX_ERROR_V1_CERT_USED_AS_CA<br />
-16379: (11) MOZILLA_PKIX_ERROR_NOT_YET_VALID_CERTIFICATE<br />
-16378: (1) MOZILLA_PKIX_ERROR_NOT_YET_VALID_ISSUER_CERTIFICATE<br />
-12276: (53) SSL_ERROR_BAD_CERT_DOMAIN<br />
-12173: (1) SSL_ERROR_WEAK_SERVER_EPHEMERAL_DH_KEY<br />
-8191: (1) SEC_ERROR_LIBRARY_FAILURE<br />
-8179: (299) SEC_ERROR_UNKNOWN_ISSUER<br />
-8162: (14) SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE<br />
-8061: (351) SEC_ERROR_OCSP_FUTURE_RESPONSE<br />
-8016: (28) SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED<br />
<br />
== Sampled Rollout of the Deprecation Policy (Q1 2017) ==<br />
<br />
We've announced in our blog post that we will be disabling SHA-1 for built-in roots over a period of time, starting with Beta users, and finishing up sometime in early 2017 with Release users.<br />
<br />
The Sampled Rollout will be implemented via a restartless system add-on. We'll plan to update and re-ship that add-on several times, targeting a growing percentage of Beta and then Release users to evaluate SHA-1 breakage. This work is being done in [https://bugzilla.mozilla.org/show_bug.cgi?id=1321114 Bug 1321114] (and the initial code is in [https://bugzilla.mozilla.org/show_bug.cgi?id=1328718 Bug 1328718]).<br />
<br />
We can see how often site breakage occurs from TLS Error Reporting statistics, and monitor progress on the rollout via the same telemetry result data format as the prior experiment.<br />
<br />
=== Tentative Sampled Rollout Timeline ===<br />
<br />
(Week 4: Release of 51)<br />
* Week 4: 10% of Beta 52 users<br />
* Week 5: 50% of Beta 52 users<br />
* Week 6: 100% of Beta 52 users<br />
* Week 7: 100% of Beta 52 users + 5% of Release 51 users<br />
* Week 8: 100% of Beta 52 users + 10% of Release 51 users<br />
* Week 8: 100% of Beta 52 users + 25% of Release 51 users<br />
* Week 9: 100% of Beta 52 users + 50% of Release 51 users<br />
(Week 10: Release of 52)<br />
* Week 10: On by preference in Beta + 100% of Release 51 users<br />
<br />
(Week 16: Release of 53)<br />
* Week 16: On by preference in Release<br />
<br />
=== Identified Risks ===<br />
<br />
This change isn't like that of [https://blog.mozilla.org/security/2016/01/06/man-in-the-middle-interfering-with-increased-security/ January 2016] - it only enforces the SHA-1 ban on publicly trusted (e.g., 'built-in') roots. It doesn't affect imported roots from AV software or enterprise deployments.<br />
<br />
There are two risk categories we’ve identified:<br />
<br />
# Publicly-trusted certificate authorities [mis-]issuing Man-In-The-Middle certificates using a SHA-1 signature algorithm.<br />
# Older than 2014 but still-valid publicly-trusted certificates using a SHA-1 signature algorithm that haven’t been replaced.<br />
<br />
==== Publicly-Trusted Man-In-The Middle of Mozilla Properties ====<br />
<br />
If a publicly-trusted CA issues or has issued a SHA-1 man-in-the-middle certificate for Mozilla's update servers, we could be broken without recourse. Note that our December experiment didn't find any rogue CAs. Also, we are not using SHA-1 certificates for our update or telemetry servers, so this would require a CA to cooperate in the attack.<br />
<br />
To mitigate this risk, before changing the preference, the add-on performs the same probe test as our earlier experiment: ensuring that connections to telemetry.mozilla.org succeed without a publicly-trusted man-in-the-middle using SHA1 interfering. (Of course, if we identified such a man-in-the-middle, we would almost certainly revoke the issuing CA using OneCRL, as it would be a critical danger to the web!)<br />
<br />
==== Pre-SHA-1 Ban Certificates Still In Use ====<br />
<br />
[https://telemetry.mozilla.org/new-pipeline/evo.html#!aggregates=bucket-1!bucket-2!bucket-3!bucket-4!bucket-5&cumulative=0&end_date=null&keys=&max_channel_version=release%252F50&measure=CERT_CHAIN_SHA1_POLICY_STATUS&min_channel_version=release%252F46&product=Firefox&sanitize=1&sort_keys=submissions&start_date=null&trim=1&use_submission_date=0 Telemetry indicates that 0.09%] of Release 50 connections still occur to sites with certificates signed with SHA-1. [https://censys.io/ipv4?q=443.https.tls.certificate.parsed.signature_algorithm.name%3A%22SHA1WithRSA%22+AND+443.https.tls.certificate.parsed.validity.end%3A++%5B2016-01-10+TO+*%5D+AND+443.https.tls.validation.browser_trusted%3A+true Censys.io queries based on scans of IPv4] show that ~300,000 hosts are still using SHA-1 certificates signed by a publicly-trusted root. That said, 11% of those are revoked certificates for "securelogin.arubanetworks.com", and upon manual inspection, many are for back-end payment processor systems that are not a part of the web.<br />
<br />
Mitigating this risk has mostly been policy and advocacy work on the part of the CA/Browser Forum since the ban effort began in 2014. The other side of mitigating this risk is this sampled rollout.<br />
<br />
(Note that Chrome is in the middle of a similar sampled rollout in December '16-January '17, with their total ban coming into effect before our sampled rollout begins, so that will also help encourage site owners to upgrade.)</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=Security/CryptoEngineering/Platform_Use_of_NSS&diff=1157824Security/CryptoEngineering/Platform Use of NSS2016-12-23T19:29:49Z<p>Dkeeler: /* PKCS#11 XPCOM APIs */ add note regarding searching for blank token names</p>
<hr />
<div>=== The Current Setup ===<br />
The collection of libraries known as NSS provides various cryptographic and security-related functionality to the platform (Gecko). In most cases, NSS must be initialized before the platform makes use of any function it exposes. Currently this requires initializing PSM, which takes care of finding the profile directory, initializing NSS using the certificate, key, and PKCS#11 module databases in that directory, and other configuration tasks such as enabling approved cipher suites. At that point, the platform is free to use NSS functionality. However, because NSS in theory could be shut down at any point (by the process of shutting down the browser as a whole), code must first acquire a 'nsNSSShutDownPreventionLock' and check if NSS has indeed already been shut down. Similarly, code that holds NSS resources must be aware of the possibility of NSS shutting down and be ready to release those resources by implementing the 'nsNSSShutDownObject' interface. Unfortunately, this scheme is difficult to work with from a development perspective and currently doesn't even cover all eventualities (for instance, if NSS has shut down, for objects created after that point, the "has NSS shut down" check will return the wrong answer).<br />
<br />
=== The Desired Setup ===<br />
The obvious solution would be to make NSS always be available (for some value of "always"). Given that the code using NSS is bound by the lifetime of XPCOM, guaranteeing that NSS be available for any XPCOM service/component seems like a good fit. The first hurdle here is that the profile directory is only available after XPCOM has been initialized (or sometimes not at all, in the case of xpcshell tests that never use a profile directory). Thus, the first significant difference in the new scheme is to initialize NSS early in XPCOM initialization in a memory-only mode where it doesn't open any persistent databases. It can be shut down again late in XPCOM teardown, when any XPCOM code that would use it has been terminated.<br />
<br />
At this point, platform code that relies on NSS can safely run. Moreover, as long as that code doesn't run after XPCOM shutdown (and as long as it properly releases its NSS resources when it's done running), the nsNSSShutDownObject/nsNSSShutDownPreventionLock framework can be removed. This constitutes a major simplification in existing code and any future platform development using NSS.<br />
<br />
The catch, of course, is that the user's persistent certificate, key, and PKCS#11 module databases won't be available when NSS is in this memory-only mode. To address this, PSM can call SECMOD_OpenUserDB with the user's profile directory. This will make these data and modules usable by the platform.<br />
<br />
=== Remaining Issues ===<br />
<br />
==== Use of PK11_GetInternalKeySlot() ====<br />
PK11_GetInternalKeySlot is used to get a handle on the software token that backs the user's persistent certificate and key database. When NSS is initialized in memory-only mode, operations that expect to modify persistent data on this token will fail. Consequently, any platform code that calls PK11_GetInternalKeySlot must instead get a handle on the software slot/token as loaded by the call to SECMOD_OpenUserDB (see above). Similarly, any NSS code that calls PK11_GetInternalKeySlot must be avoided or worked around, as it will not work correctly. For example, CERT_AddTempCertToPerm (which is used to take an existing temporary certificate and save it in the persistent database) is hard-coded to use PK11_GetInternalKeySlot. However, PK11_ImportCert can be used in combination with CERT_ChangeCertTrust in place of CERT_AddTempCertToPerm to save the certificate on a specific slot (in this case, the real persistent database as loaded by SECMOD_OpenUserDB).<br />
<br />
PK11SDR_Encrypt and PK11SDR_Decrypt have no equivalent functions that take a caller-provided slot. Either new functions will have to be added to NSS (e.g. as PK11SDR_EncryptOnSlot and PK11SDR_DecryptOnSlot) or they will have to be reimplemented in PSM. Luckily, these two functions do not call internal NSS APIs and can be easily duplicated in terms of functionality. Doing so might be desirable as it would enable a step towards towards using more modern cryptography to protect the information in the user's key database.<br />
<br />
==== Loading New PKCS#11 Modules ====<br />
Currently when a new PKCS#11 module is loaded, its presence is persisted in the user's module database, meaning that it will automatically be loaded the next time the platform runs. When NSS is initialized in memory-only mode, this will not work. Consequently, we must come up with some way of persisting the PKCS#11 modules the user wants the platform to load when it starts. Upon PSM initialization, the known modules can be loaded for the duration of the session.<br />
<br />
==== PKCS#11 XPCOM APIs ====<br />
Currently the platform exposes some PKCS#11 module APIs that include such functionality as getting a handle on the internal module, listing known modules, and searching for modules, tokens, and/or slots. Because the user's software token is now not the same as that returned by PK11_GetInternalKeySlot, these APIs must be special-cased to continue to behave as expected. (The issue regarding the undocumented feature of searching for a blank token name returning the internal module has been addressed by [https://bugzilla.mozilla.org/show_bug.cgi?id=1324071 bug 1324071]).<br />
<br />
==== FIPS ====<br />
Continuing to support FIPS with these changes appears to be problematic in two ways. First, since from NSS' perspective the "internal" database is loaded in memory-only mode, that the user put the database in FIPS mode isn't persisted across restarts. This can be addressed by a mechanism similar to or along side that which persists new PKCS#11 modules (see above). Second, turning on FIPS mode appears to unload the real persistent certificate and key database. It may be that this can simply be reloaded as part of the process of enabling FIPS. Further investigation in required here.<br />
<br />
=== Resolved Issues ===<br />
<br />
==== The NSS Certificate Nickname API ====<br />
NSS exposes APIs whereby certificates can be referred to by nickname. Certificates on tokens other than that returned by PK11_GetInternalKeySlot prefix their nickname with the name of the token. Because platform code now must operate on a token that isn't the internal one, this behavior must be worked around by special-casing unprefixed nicknames when using these and related APIs.<br />
<br />
Alternatively, we could remove and/or rework XPCOM interfaces that expose the NSS nickname API and replace them with an equivalent mechanism that doesn't have this and other drawbacks (see the discussion in [https://bugzilla.mozilla.org/show_bug.cgi?id=857627 bug 857627]).<br />
<br />
Update: As of the landing of bug 857627, this shouldn't be an issue any longer.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=Security/CryptoEngineering/Platform_Use_of_NSS&diff=1156408Security/CryptoEngineering/Platform Use of NSS2016-12-02T18:06:38Z<p>Dkeeler: /* Remaining Issues */ add resolved issues section</p>
<hr />
<div>=== The Current Setup ===<br />
The collection of libraries known as NSS provides various cryptographic and security-related functionality to the platform (Gecko). In most cases, NSS must be initialized before the platform makes use of any function it exposes. Currently this requires initializing PSM, which takes care of finding the profile directory, initializing NSS using the certificate, key, and PKCS#11 module databases in that directory, and other configuration tasks such as enabling approved cipher suites. At that point, the platform is free to use NSS functionality. However, because NSS in theory could be shut down at any point (by the process of shutting down the browser as a whole), code must first acquire a 'nsNSSShutDownPreventionLock' and check if NSS has indeed already been shut down. Similarly, code that holds NSS resources must be aware of the possibility of NSS shutting down and be ready to release those resources by implementing the 'nsNSSShutDownObject' interface. Unfortunately, this scheme is difficult to work with from a development perspective and currently doesn't even cover all eventualities (for instance, if NSS has shut down, for objects created after that point, the "has NSS shut down" check will return the wrong answer).<br />
<br />
=== The Desired Setup ===<br />
The obvious solution would be to make NSS always be available (for some value of "always"). Given that the code using NSS is bound by the lifetime of XPCOM, guaranteeing that NSS be available for any XPCOM service/component seems like a good fit. The first hurdle here is that the profile directory is only available after XPCOM has been initialized (or sometimes not at all, in the case of xpcshell tests that never use a profile directory). Thus, the first significant difference in the new scheme is to initialize NSS early in XPCOM initialization in a memory-only mode where it doesn't open any persistent databases. It can be shut down again late in XPCOM teardown, when any XPCOM code that would use it has been terminated.<br />
<br />
At this point, platform code that relies on NSS can safely run. Moreover, as long as that code doesn't run after XPCOM shutdown (and as long as it properly releases its NSS resources when it's done running), the nsNSSShutDownObject/nsNSSShutDownPreventionLock framework can be removed. This constitutes a major simplification in existing code and any future platform development using NSS.<br />
<br />
The catch, of course, is that the user's persistent certificate, key, and PKCS#11 module databases won't be available when NSS is in this memory-only mode. To address this, PSM can call SECMOD_OpenUserDB with the user's profile directory. This will make these data and modules usable by the platform.<br />
<br />
=== Remaining Issues ===<br />
<br />
==== Use of PK11_GetInternalKeySlot() ====<br />
PK11_GetInternalKeySlot is used to get a handle on the software token that backs the user's persistent certificate and key database. When NSS is initialized in memory-only mode, operations that expect to modify persistent data on this token will fail. Consequently, any platform code that calls PK11_GetInternalKeySlot must instead get a handle on the software slot/token as loaded by the call to SECMOD_OpenUserDB (see above). Similarly, any NSS code that calls PK11_GetInternalKeySlot must be avoided or worked around, as it will not work correctly. For example, CERT_AddTempCertToPerm (which is used to take an existing temporary certificate and save it in the persistent database) is hard-coded to use PK11_GetInternalKeySlot. However, PK11_ImportCert can be used in combination with CERT_ChangeCertTrust in place of CERT_AddTempCertToPerm to save the certificate on a specific slot (in this case, the real persistent database as loaded by SECMOD_OpenUserDB).<br />
<br />
PK11SDR_Encrypt and PK11SDR_Decrypt have no equivalent functions that take a caller-provided slot. Either new functions will have to be added to NSS (e.g. as PK11SDR_EncryptOnSlot and PK11SDR_DecryptOnSlot) or they will have to be reimplemented in PSM. Luckily, these two functions do not call internal NSS APIs and can be easily duplicated in terms of functionality. Doing so might be desirable as it would enable a step towards towards using more modern cryptography to protect the information in the user's key database.<br />
<br />
==== Loading New PKCS#11 Modules ====<br />
Currently when a new PKCS#11 module is loaded, its presence is persisted in the user's module database, meaning that it will automatically be loaded the next time the platform runs. When NSS is initialized in memory-only mode, this will not work. Consequently, we must come up with some way of persisting the PKCS#11 modules the user wants the platform to load when it starts. Upon PSM initialization, the known modules can be loaded for the duration of the session.<br />
<br />
==== PKCS#11 XPCOM APIs ====<br />
Currently the platform exposes some PKCS#11 module APIs that include such functionality as getting a handle on the internal module, listing known modules, and searching for modules, tokens, and/or slots. Because the user's software token is now not the same as that returned by PK11_GetInternalKeySlot, these APIs must be special-cased to continue to behave as expected. For example, if the user searches for a module with a blank name, the internal module (as loaded by SECMOD_OpenUserDB) must be returned.<br />
<br />
==== FIPS ====<br />
Continuing to support FIPS with these changes appears to be problematic in two ways. First, since from NSS' perspective the "internal" database is loaded in memory-only mode, that the user put the database in FIPS mode isn't persisted across restarts. This can be addressed by a mechanism similar to or along side that which persists new PKCS#11 modules (see above). Second, turning on FIPS mode appears to unload the real persistent certificate and key database. It may be that this can simply be reloaded as part of the process of enabling FIPS. Further investigation in required here.<br />
<br />
=== Resolved Issues ===<br />
<br />
==== The NSS Certificate Nickname API ====<br />
NSS exposes APIs whereby certificates can be referred to by nickname. Certificates on tokens other than that returned by PK11_GetInternalKeySlot prefix their nickname with the name of the token. Because platform code now must operate on a token that isn't the internal one, this behavior must be worked around by special-casing unprefixed nicknames when using these and related APIs.<br />
<br />
Alternatively, we could remove and/or rework XPCOM interfaces that expose the NSS nickname API and replace them with an equivalent mechanism that doesn't have this and other drawbacks (see the discussion in [https://bugzilla.mozilla.org/show_bug.cgi?id=857627 bug 857627]).<br />
<br />
Update: As of the landing of bug 857627, this shouldn't be an issue any longer.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=Security/CryptoEngineering/Platform_Use_of_NSS&diff=1156407Security/CryptoEngineering/Platform Use of NSS2016-12-02T18:05:29Z<p>Dkeeler: /* The NSS Certificate Nickname API */ update to note that this has been resolved</p>
<hr />
<div>=== The Current Setup ===<br />
The collection of libraries known as NSS provides various cryptographic and security-related functionality to the platform (Gecko). In most cases, NSS must be initialized before the platform makes use of any function it exposes. Currently this requires initializing PSM, which takes care of finding the profile directory, initializing NSS using the certificate, key, and PKCS#11 module databases in that directory, and other configuration tasks such as enabling approved cipher suites. At that point, the platform is free to use NSS functionality. However, because NSS in theory could be shut down at any point (by the process of shutting down the browser as a whole), code must first acquire a 'nsNSSShutDownPreventionLock' and check if NSS has indeed already been shut down. Similarly, code that holds NSS resources must be aware of the possibility of NSS shutting down and be ready to release those resources by implementing the 'nsNSSShutDownObject' interface. Unfortunately, this scheme is difficult to work with from a development perspective and currently doesn't even cover all eventualities (for instance, if NSS has shut down, for objects created after that point, the "has NSS shut down" check will return the wrong answer).<br />
<br />
=== The Desired Setup ===<br />
The obvious solution would be to make NSS always be available (for some value of "always"). Given that the code using NSS is bound by the lifetime of XPCOM, guaranteeing that NSS be available for any XPCOM service/component seems like a good fit. The first hurdle here is that the profile directory is only available after XPCOM has been initialized (or sometimes not at all, in the case of xpcshell tests that never use a profile directory). Thus, the first significant difference in the new scheme is to initialize NSS early in XPCOM initialization in a memory-only mode where it doesn't open any persistent databases. It can be shut down again late in XPCOM teardown, when any XPCOM code that would use it has been terminated.<br />
<br />
At this point, platform code that relies on NSS can safely run. Moreover, as long as that code doesn't run after XPCOM shutdown (and as long as it properly releases its NSS resources when it's done running), the nsNSSShutDownObject/nsNSSShutDownPreventionLock framework can be removed. This constitutes a major simplification in existing code and any future platform development using NSS.<br />
<br />
The catch, of course, is that the user's persistent certificate, key, and PKCS#11 module databases won't be available when NSS is in this memory-only mode. To address this, PSM can call SECMOD_OpenUserDB with the user's profile directory. This will make these data and modules usable by the platform.<br />
<br />
=== Remaining Issues ===<br />
<br />
==== Use of PK11_GetInternalKeySlot() ====<br />
PK11_GetInternalKeySlot is used to get a handle on the software token that backs the user's persistent certificate and key database. When NSS is initialized in memory-only mode, operations that expect to modify persistent data on this token will fail. Consequently, any platform code that calls PK11_GetInternalKeySlot must instead get a handle on the software slot/token as loaded by the call to SECMOD_OpenUserDB (see above). Similarly, any NSS code that calls PK11_GetInternalKeySlot must be avoided or worked around, as it will not work correctly. For example, CERT_AddTempCertToPerm (which is used to take an existing temporary certificate and save it in the persistent database) is hard-coded to use PK11_GetInternalKeySlot. However, PK11_ImportCert can be used in combination with CERT_ChangeCertTrust in place of CERT_AddTempCertToPerm to save the certificate on a specific slot (in this case, the real persistent database as loaded by SECMOD_OpenUserDB).<br />
<br />
PK11SDR_Encrypt and PK11SDR_Decrypt have no equivalent functions that take a caller-provided slot. Either new functions will have to be added to NSS (e.g. as PK11SDR_EncryptOnSlot and PK11SDR_DecryptOnSlot) or they will have to be reimplemented in PSM. Luckily, these two functions do not call internal NSS APIs and can be easily duplicated in terms of functionality. Doing so might be desirable as it would enable a step towards towards using more modern cryptography to protect the information in the user's key database.<br />
<br />
==== The NSS Certificate Nickname API (Resolved) ====<br />
NSS exposes APIs whereby certificates can be referred to by nickname. Certificates on tokens other than that returned by PK11_GetInternalKeySlot prefix their nickname with the name of the token. Because platform code now must operate on a token that isn't the internal one, this behavior must be worked around by special-casing unprefixed nicknames when using these and related APIs.<br />
<br />
Alternatively, we could remove and/or rework XPCOM interfaces that expose the NSS nickname API and replace them with an equivalent mechanism that doesn't have this and other drawbacks (see the discussion in [https://bugzilla.mozilla.org/show_bug.cgi?id=857627 bug 857627]).<br />
<br />
Update: As of the landing of bug 857627, this shouldn't be an issue any longer.<br />
<br />
==== Loading New PKCS#11 Modules ====<br />
Currently when a new PKCS#11 module is loaded, its presence is persisted in the user's module database, meaning that it will automatically be loaded the next time the platform runs. When NSS is initialized in memory-only mode, this will not work. Consequently, we must come up with some way of persisting the PKCS#11 modules the user wants the platform to load when it starts. Upon PSM initialization, the known modules can be loaded for the duration of the session.<br />
<br />
==== PKCS#11 XPCOM APIs ====<br />
Currently the platform exposes some PKCS#11 module APIs that include such functionality as getting a handle on the internal module, listing known modules, and searching for modules, tokens, and/or slots. Because the user's software token is now not the same as that returned by PK11_GetInternalKeySlot, these APIs must be special-cased to continue to behave as expected. For example, if the user searches for a module with a blank name, the internal module (as loaded by SECMOD_OpenUserDB) must be returned.<br />
<br />
==== FIPS ====<br />
Continuing to support FIPS with these changes appears to be problematic in two ways. First, since from NSS' perspective the "internal" database is loaded in memory-only mode, that the user put the database in FIPS mode isn't persisted across restarts. This can be addressed by a mechanism similar to or along side that which persists new PKCS#11 modules (see above). Second, turning on FIPS mode appears to unload the real persistent certificate and key database. It may be that this can simply be reloaded as part of the process of enabling FIPS. Further investigation in required here.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=Security/CryptoEngineering/Platform_Use_of_NSS&diff=1155173Security/CryptoEngineering/Platform Use of NSS2016-11-17T23:57:21Z<p>Dkeeler: add FIPS section</p>
<hr />
<div>=== The Current Setup ===<br />
The collection of libraries known as NSS provides various cryptographic and security-related functionality to the platform (Gecko). In most cases, NSS must be initialized before the platform makes use of any function it exposes. Currently this requires initializing PSM, which takes care of finding the profile directory, initializing NSS using the certificate, key, and PKCS#11 module databases in that directory, and other configuration tasks such as enabling approved cipher suites. At that point, the platform is free to use NSS functionality. However, because NSS in theory could be shut down at any point (by the process of shutting down the browser as a whole), code must first acquire a 'nsNSSShutDownPreventionLock' and check if NSS has indeed already been shut down. Similarly, code that holds NSS resources must be aware of the possibility of NSS shutting down and be ready to release those resources by implementing the 'nsNSSShutDownObject' interface. Unfortunately, this scheme is difficult to work with from a development perspective and currently doesn't even cover all eventualities (for instance, if NSS has shut down, for objects created after that point, the "has NSS shut down" check will return the wrong answer).<br />
<br />
=== The Desired Setup ===<br />
The obvious solution would be to make NSS always be available (for some value of "always"). Given that the code using NSS is bound by the lifetime of XPCOM, guaranteeing that NSS be available for any XPCOM service/component seems like a good fit. The first hurdle here is that the profile directory is only available after XPCOM has been initialized (or sometimes not at all, in the case of xpcshell tests that never use a profile directory). Thus, the first significant difference in the new scheme is to initialize NSS early in XPCOM initialization in a memory-only mode where it doesn't open any persistent databases. It can be shut down again late in XPCOM teardown, when any XPCOM code that would use it has been terminated.<br />
<br />
At this point, platform code that relies on NSS can safely run. Moreover, as long as that code doesn't run after XPCOM shutdown (and as long as it properly releases its NSS resources when it's done running), the nsNSSShutDownObject/nsNSSShutDownPreventionLock framework can be removed. This constitutes a major simplification in existing code and any future platform development using NSS.<br />
<br />
The catch, of course, is that the user's persistent certificate, key, and PKCS#11 module databases won't be available when NSS is in this memory-only mode. To address this, PSM can call SECMOD_OpenUserDB with the user's profile directory. This will make these data and modules usable by the platform.<br />
<br />
=== Remaining Issues ===<br />
<br />
==== Use of PK11_GetInternalKeySlot() ====<br />
PK11_GetInternalKeySlot is used to get a handle on the software token that backs the user's persistent certificate and key database. When NSS is initialized in memory-only mode, operations that expect to modify persistent data on this token will fail. Consequently, any platform code that calls PK11_GetInternalKeySlot must instead get a handle on the software slot/token as loaded by the call to SECMOD_OpenUserDB (see above). Similarly, any NSS code that calls PK11_GetInternalKeySlot must be avoided or worked around, as it will not work correctly. For example, CERT_AddTempCertToPerm (which is used to take an existing temporary certificate and save it in the persistent database) is hard-coded to use PK11_GetInternalKeySlot. However, PK11_ImportCert can be used in combination with CERT_ChangeCertTrust in place of CERT_AddTempCertToPerm to save the certificate on a specific slot (in this case, the real persistent database as loaded by SECMOD_OpenUserDB).<br />
<br />
PK11SDR_Encrypt and PK11SDR_Decrypt have no equivalent functions that take a caller-provided slot. Either new functions will have to be added to NSS (e.g. as PK11SDR_EncryptOnSlot and PK11SDR_DecryptOnSlot) or they will have to be reimplemented in PSM. Luckily, these two functions do not call internal NSS APIs and can be easily duplicated in terms of functionality. Doing so might be desirable as it would enable a step towards towards using more modern cryptography to protect the information in the user's key database.<br />
<br />
==== The NSS Certificate Nickname API ====<br />
NSS exposes APIs whereby certificates can be referred to by nickname. Certificates on tokens other than that returned by PK11_GetInternalKeySlot prefix their nickname with the name of the token. Because platform code now must operate on a token that isn't the internal one, this behavior must be worked around by special-casing unprefixed nicknames when using these and related APIs.<br />
<br />
Alternatively, we could remove and/or rework XPCOM interfaces that expose the NSS nickname API and replace them with an equivalent mechanism that doesn't have this and other drawbacks (see the discussion in [https://bugzilla.mozilla.org/show_bug.cgi?id=857627 bug 857627]).<br />
<br />
==== Loading New PKCS#11 Modules ====<br />
Currently when a new PKCS#11 module is loaded, its presence is persisted in the user's module database, meaning that it will automatically be loaded the next time the platform runs. When NSS is initialized in memory-only mode, this will not work. Consequently, we must come up with some way of persisting the PKCS#11 modules the user wants the platform to load when it starts. Upon PSM initialization, the known modules can be loaded for the duration of the session.<br />
<br />
==== PKCS#11 XPCOM APIs ====<br />
Currently the platform exposes some PKCS#11 module APIs that include such functionality as getting a handle on the internal module, listing known modules, and searching for modules, tokens, and/or slots. Because the user's software token is now not the same as that returned by PK11_GetInternalKeySlot, these APIs must be special-cased to continue to behave as expected. For example, if the user searches for a module with a blank name, the internal module (as loaded by SECMOD_OpenUserDB) must be returned.<br />
<br />
==== FIPS ====<br />
Continuing to support FIPS with these changes appears to be problematic in two ways. First, since from NSS' perspective the "internal" database is loaded in memory-only mode, that the user put the database in FIPS mode isn't persisted across restarts. This can be addressed by a mechanism similar to or along side that which persists new PKCS#11 modules (see above). Second, turning on FIPS mode appears to unload the real persistent certificate and key database. It may be that this can simply be reloaded as part of the process of enabling FIPS. Further investigation in required here.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=Security/CryptoEngineering/Platform_Use_of_NSS&diff=1155172Security/CryptoEngineering/Platform Use of NSS2016-11-17T23:50:59Z<p>Dkeeler: /* The NSS Certificate Nickname API */ mention option of removing nickname APIs</p>
<hr />
<div>=== The Current Setup ===<br />
The collection of libraries known as NSS provides various cryptographic and security-related functionality to the platform (Gecko). In most cases, NSS must be initialized before the platform makes use of any function it exposes. Currently this requires initializing PSM, which takes care of finding the profile directory, initializing NSS using the certificate, key, and PKCS#11 module databases in that directory, and other configuration tasks such as enabling approved cipher suites. At that point, the platform is free to use NSS functionality. However, because NSS in theory could be shut down at any point (by the process of shutting down the browser as a whole), code must first acquire a 'nsNSSShutDownPreventionLock' and check if NSS has indeed already been shut down. Similarly, code that holds NSS resources must be aware of the possibility of NSS shutting down and be ready to release those resources by implementing the 'nsNSSShutDownObject' interface. Unfortunately, this scheme is difficult to work with from a development perspective and currently doesn't even cover all eventualities (for instance, if NSS has shut down, for objects created after that point, the "has NSS shut down" check will return the wrong answer).<br />
<br />
=== The Desired Setup ===<br />
The obvious solution would be to make NSS always be available (for some value of "always"). Given that the code using NSS is bound by the lifetime of XPCOM, guaranteeing that NSS be available for any XPCOM service/component seems like a good fit. The first hurdle here is that the profile directory is only available after XPCOM has been initialized (or sometimes not at all, in the case of xpcshell tests that never use a profile directory). Thus, the first significant difference in the new scheme is to initialize NSS early in XPCOM initialization in a memory-only mode where it doesn't open any persistent databases. It can be shut down again late in XPCOM teardown, when any XPCOM code that would use it has been terminated.<br />
<br />
At this point, platform code that relies on NSS can safely run. Moreover, as long as that code doesn't run after XPCOM shutdown (and as long as it properly releases its NSS resources when it's done running), the nsNSSShutDownObject/nsNSSShutDownPreventionLock framework can be removed. This constitutes a major simplification in existing code and any future platform development using NSS.<br />
<br />
The catch, of course, is that the user's persistent certificate, key, and PKCS#11 module databases won't be available when NSS is in this memory-only mode. To address this, PSM can call SECMOD_OpenUserDB with the user's profile directory. This will make these data and modules usable by the platform.<br />
<br />
=== Remaining Issues ===<br />
<br />
==== Use of PK11_GetInternalKeySlot() ====<br />
PK11_GetInternalKeySlot is used to get a handle on the software token that backs the user's persistent certificate and key database. When NSS is initialized in memory-only mode, operations that expect to modify persistent data on this token will fail. Consequently, any platform code that calls PK11_GetInternalKeySlot must instead get a handle on the software slot/token as loaded by the call to SECMOD_OpenUserDB (see above). Similarly, any NSS code that calls PK11_GetInternalKeySlot must be avoided or worked around, as it will not work correctly. For example, CERT_AddTempCertToPerm (which is used to take an existing temporary certificate and save it in the persistent database) is hard-coded to use PK11_GetInternalKeySlot. However, PK11_ImportCert can be used in combination with CERT_ChangeCertTrust in place of CERT_AddTempCertToPerm to save the certificate on a specific slot (in this case, the real persistent database as loaded by SECMOD_OpenUserDB).<br />
<br />
PK11SDR_Encrypt and PK11SDR_Decrypt have no equivalent functions that take a caller-provided slot. Either new functions will have to be added to NSS (e.g. as PK11SDR_EncryptOnSlot and PK11SDR_DecryptOnSlot) or they will have to be reimplemented in PSM. Luckily, these two functions do not call internal NSS APIs and can be easily duplicated in terms of functionality. Doing so might be desirable as it would enable a step towards towards using more modern cryptography to protect the information in the user's key database.<br />
<br />
==== The NSS Certificate Nickname API ====<br />
NSS exposes APIs whereby certificates can be referred to by nickname. Certificates on tokens other than that returned by PK11_GetInternalKeySlot prefix their nickname with the name of the token. Because platform code now must operate on a token that isn't the internal one, this behavior must be worked around by special-casing unprefixed nicknames when using these and related APIs.<br />
<br />
Alternatively, we could remove and/or rework XPCOM interfaces that expose the NSS nickname API and replace them with an equivalent mechanism that doesn't have this and other drawbacks (see the discussion in [https://bugzilla.mozilla.org/show_bug.cgi?id=857627 bug 857627]).<br />
<br />
==== Loading New PKCS#11 Modules ====<br />
Currently when a new PKCS#11 module is loaded, its presence is persisted in the user's module database, meaning that it will automatically be loaded the next time the platform runs. When NSS is initialized in memory-only mode, this will not work. Consequently, we must come up with some way of persisting the PKCS#11 modules the user wants the platform to load when it starts. Upon PSM initialization, the known modules can be loaded for the duration of the session.<br />
<br />
==== PKCS#11 XPCOM APIs ====<br />
Currently the platform exposes some PKCS#11 module APIs that include such functionality as getting a handle on the internal module, listing known modules, and searching for modules, tokens, and/or slots. Because the user's software token is now not the same as that returned by PK11_GetInternalKeySlot, these APIs must be special-cased to continue to behave as expected. For example, if the user searches for a module with a blank name, the internal module (as loaded by SECMOD_OpenUserDB) must be returned.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=Security/CryptoEngineering/Platform_Use_of_NSS&diff=1154865Security/CryptoEngineering/Platform Use of NSS2016-11-15T21:35:12Z<p>Dkeeler: /* Use of PK11_GetInternalKeySlot() */ add note on PK11SDR_*</p>
<hr />
<div>=== The Current Setup ===<br />
The collection of libraries known as NSS provides various cryptographic and security-related functionality to the platform (Gecko). In most cases, NSS must be initialized before the platform makes use of any function it exposes. Currently this requires initializing PSM, which takes care of finding the profile directory, initializing NSS using the certificate, key, and PKCS#11 module databases in that directory, and other configuration tasks such as enabling approved cipher suites. At that point, the platform is free to use NSS functionality. However, because NSS in theory could be shut down at any point (by the process of shutting down the browser as a whole), code must first acquire a 'nsNSSShutDownPreventionLock' and check if NSS has indeed already been shut down. Similarly, code that holds NSS resources must be aware of the possibility of NSS shutting down and be ready to release those resources by implementing the 'nsNSSShutDownObject' interface. Unfortunately, this scheme is difficult to work with from a development perspective and currently doesn't even cover all eventualities (for instance, if NSS has shut down, for objects created after that point, the "has NSS shut down" check will return the wrong answer).<br />
<br />
=== The Desired Setup ===<br />
The obvious solution would be to make NSS always be available (for some value of "always"). Given that the code using NSS is bound by the lifetime of XPCOM, guaranteeing that NSS be available for any XPCOM service/component seems like a good fit. The first hurdle here is that the profile directory is only available after XPCOM has been initialized (or sometimes not at all, in the case of xpcshell tests that never use a profile directory). Thus, the first significant difference in the new scheme is to initialize NSS early in XPCOM initialization in a memory-only mode where it doesn't open any persistent databases. It can be shut down again late in XPCOM teardown, when any XPCOM code that would use it has been terminated.<br />
<br />
At this point, platform code that relies on NSS can safely run. Moreover, as long as that code doesn't run after XPCOM shutdown (and as long as it properly releases its NSS resources when it's done running), the nsNSSShutDownObject/nsNSSShutDownPreventionLock framework can be removed. This constitutes a major simplification in existing code and any future platform development using NSS.<br />
<br />
The catch, of course, is that the user's persistent certificate, key, and PKCS#11 module databases won't be available when NSS is in this memory-only mode. To address this, PSM can call SECMOD_OpenUserDB with the user's profile directory. This will make these data and modules usable by the platform.<br />
<br />
=== Remaining Issues ===<br />
<br />
==== Use of PK11_GetInternalKeySlot() ====<br />
PK11_GetInternalKeySlot is used to get a handle on the software token that backs the user's persistent certificate and key database. When NSS is initialized in memory-only mode, operations that expect to modify persistent data on this token will fail. Consequently, any platform code that calls PK11_GetInternalKeySlot must instead get a handle on the software slot/token as loaded by the call to SECMOD_OpenUserDB (see above). Similarly, any NSS code that calls PK11_GetInternalKeySlot must be avoided or worked around, as it will not work correctly. For example, CERT_AddTempCertToPerm (which is used to take an existing temporary certificate and save it in the persistent database) is hard-coded to use PK11_GetInternalKeySlot. However, PK11_ImportCert can be used in combination with CERT_ChangeCertTrust in place of CERT_AddTempCertToPerm to save the certificate on a specific slot (in this case, the real persistent database as loaded by SECMOD_OpenUserDB).<br />
<br />
PK11SDR_Encrypt and PK11SDR_Decrypt have no equivalent functions that take a caller-provided slot. Either new functions will have to be added to NSS (e.g. as PK11SDR_EncryptOnSlot and PK11SDR_DecryptOnSlot) or they will have to be reimplemented in PSM. Luckily, these two functions do not call internal NSS APIs and can be easily duplicated in terms of functionality. Doing so might be desirable as it would enable a step towards towards using more modern cryptography to protect the information in the user's key database.<br />
<br />
==== The NSS Certificate Nickname API ====<br />
NSS exposes APIs whereby certificates can be referred to by nickname. Certificates on tokens other than that returned by PK11_GetInternalKeySlot prefix their nickname with the name of the token. Because platform code now must operate on a token that isn't the internal one, this behavior must be worked around by special-casing unprefixed nicknames when using these and related APIs.<br />
<br />
==== Loading New PKCS#11 Modules ====<br />
Currently when a new PKCS#11 module is loaded, its presence is persisted in the user's module database, meaning that it will automatically be loaded the next time the platform runs. When NSS is initialized in memory-only mode, this will not work. Consequently, we must come up with some way of persisting the PKCS#11 modules the user wants the platform to load when it starts. Upon PSM initialization, the known modules can be loaded for the duration of the session.<br />
<br />
==== PKCS#11 XPCOM APIs ====<br />
Currently the platform exposes some PKCS#11 module APIs that include such functionality as getting a handle on the internal module, listing known modules, and searching for modules, tokens, and/or slots. Because the user's software token is now not the same as that returned by PK11_GetInternalKeySlot, these APIs must be special-cased to continue to behave as expected. For example, if the user searches for a module with a blank name, the internal module (as loaded by SECMOD_OpenUserDB) must be returned.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=Security/CryptoEngineering&diff=1154846Security/CryptoEngineering2016-11-15T20:12:42Z<p>Dkeeler: add link to platform use of NSS improvements project</p>
<hr />
<div>''Last Updated: 3 Nov 2016''<br />
<br />
= Crypto Engineering Projects =<br />
<br />
Our team's major projects are broken down by module:<br />
<br />
== [[NSS]] ==<br />
NSS is the cryptography and transport security library that powers Firefox.<br />
<br />
In 2016Q4 and 2017Q1 we're working on three aspects of NSS.<br />
<br />
=== Improve Developer Ergonomics ===<br />
NSS [http://www-archive.mozilla.org/projects/security/pki/nss/history.html dates back to Netscape Navigator], and much of the infrastructure for working inside the codebase dated back nearly that far, making an artificially-high barrier to entry for new community contributors.<br />
<br />
* 2016 Q4: [[NSS/Build_System|Change build systems to Gyp]] for dramatically faster builds, with an easier-to-maintain set of build scripts.<br />
* 2016 Q4: Move reviews to Phabricator. <br />
** MozReview's lack of a security-restricted mode makes it unacceptable<br />
* 2016 Q4: Semi-Automatic Branch Uplifts to Mozilla-Central, so that changes can be tested in Nightly.<br />
* 2016 Q4: [[NSS/Demos|[MWOS] Add new NSS demonstration code]] to show how to use NSS in a modern way. <br />
<br />
=== Cleanup ===<br />
Many things in NSS are old without being a barrier to community contribution. <br />
<br />
* 2016 Q4: Support ARM and ARM64 testing in TaskCluster.<br />
** While NSS is security-critical on all our platforms, historically we only found out about breakage in ARM platforms after the fact, so we're now treating ARM and ARM64 as first-class testing environments.<br />
* 2016 Q4: Support fuzzing the internal interfaces.<br />
** If you build security-critical code today, you plan to fuzz it from the start. NSS wasn't built that way, so it needs some adjustments to make it fuzzy on the inside.<br />
* 2016 Q4: Port the AES-NI speedup Linux-x86 assembly code to NASM and cross-assemble it for Windows and OSX.<br />
<br />
=== New Functions ===<br />
We're thought leaders in producing a more secure Internet; our software needs to keep up with our ideas.<br />
<br />
* 2016 Q4: Support TLS v1.3.<br />
** This is a major revision to the transport security specification, and a large boon for protecting our users from adversaries and surveillance. <br />
* 2016 Q4: [[NSS/BoGo_Tests|Integrate BoGo's integration tests into NSS builds]].<br />
** The automated tests for NSS are mostly unit tests. Integration testing was historically assumed to happen at Firefox, but that's limited. BoGo is a rich set of integration tests that can diagnose protocol issues during automated testing.<br />
* 2016 Q4: [[NSS/ARGON2|[MWOS] Implement Argon2]] to provide a basis to modernize the Master Password in Firefox.<br />
* 2017 Q1: Post-Quantum Research and Development.<br />
** Mozilla is intending to join the efforts in developing cryptography that will remain secure once quantum computers come online. This is expected to be a long-duration R&D effort.<br />
<br />
== PSM ==<br />
PSM performs the business logic of deciding whether a given secure network connection is actually trustworthy. It applies logic from the user's choices, the Mozilla Root Program, and the platform in order to make a trust determination. E.g., whether to show a connection as secure.<br />
<br />
* 2016 Q4 / 2017 Q1: Re-architect PSM/NSS interaction to eliminate shutdown crashes.<br />
** The interaction between PSM and NSS is extremely old, and doesn't follow the modern methods Gecko uses to initialize and shutdown modules. As such, NSS sometimes crashes when shutting down; this is a leading crash on Android. Fixing this is a substantial architectural change.<br />
** Details here: [[Security/CryptoEngineering/Platform Use of NSS|Platform Use of NSS]]<br />
<br />
* 2016 Q4 / 2017 Q1: Implement the [[Security/CryptoEngineering/SHA-1|SHA-1 Shutoff Plan]].<br />
** The WebPKI is halting use of SHA-1 for publicly-trusted certificates. PSM will be enforcing that halt starting in early 2017.<br />
<br />
== Web Authentication ==<br />
Password authentication is known to be a security liability on the Web. The [https://www.w3.org/TR/webauthn/ W3C Web Authentication Working Group is developing a specification] for using Scoped Credentials to supplement or replace passwords. Mozilla intends to implement Web Authentication (WebAuthn) specification.<br />
<br />
* 2016 Q2: FIDO U2F v1.1 JS API landed, hidden behind preferences.<br />
** You can test a "Soft Token" using any recent version of Firefox using the instructions at https://u2f.bin.coffee/ <br />
* 2016 Q4: Support USB HID U2F devices on Linux.<br />
* 2016 Q4: Draft WebAuthn JS API available, hidden behind a pref, using the Soft Token from U2F.<br />
* 2017 Q1: Support USB HID U2F devices on Windows / Mac OS X.<br />
* 2017 Q1: Integrate USB HID U2F devices with the WebAuthn JS API.<br />
* 2017 Q1-2: Update to the final implementation WebAuthn JS API.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=Security/CryptoEngineering/Platform_Use_of_NSS&diff=1154845Security/CryptoEngineering/Platform Use of NSS2016-11-15T20:10:43Z<p>Dkeeler: initial writeup</p>
<hr />
<div>=== The Current Setup ===<br />
The collection of libraries known as NSS provides various cryptographic and security-related functionality to the platform (Gecko). In most cases, NSS must be initialized before the platform makes use of any function it exposes. Currently this requires initializing PSM, which takes care of finding the profile directory, initializing NSS using the certificate, key, and PKCS#11 module databases in that directory, and other configuration tasks such as enabling approved cipher suites. At that point, the platform is free to use NSS functionality. However, because NSS in theory could be shut down at any point (by the process of shutting down the browser as a whole), code must first acquire a 'nsNSSShutDownPreventionLock' and check if NSS has indeed already been shut down. Similarly, code that holds NSS resources must be aware of the possibility of NSS shutting down and be ready to release those resources by implementing the 'nsNSSShutDownObject' interface. Unfortunately, this scheme is difficult to work with from a development perspective and currently doesn't even cover all eventualities (for instance, if NSS has shut down, for objects created after that point, the "has NSS shut down" check will return the wrong answer).<br />
<br />
=== The Desired Setup ===<br />
The obvious solution would be to make NSS always be available (for some value of "always"). Given that the code using NSS is bound by the lifetime of XPCOM, guaranteeing that NSS be available for any XPCOM service/component seems like a good fit. The first hurdle here is that the profile directory is only available after XPCOM has been initialized (or sometimes not at all, in the case of xpcshell tests that never use a profile directory). Thus, the first significant difference in the new scheme is to initialize NSS early in XPCOM initialization in a memory-only mode where it doesn't open any persistent databases. It can be shut down again late in XPCOM teardown, when any XPCOM code that would use it has been terminated.<br />
<br />
At this point, platform code that relies on NSS can safely run. Moreover, as long as that code doesn't run after XPCOM shutdown (and as long as it properly releases its NSS resources when it's done running), the nsNSSShutDownObject/nsNSSShutDownPreventionLock framework can be removed. This constitutes a major simplification in existing code and any future platform development using NSS.<br />
<br />
The catch, of course, is that the user's persistent certificate, key, and PKCS#11 module databases won't be available when NSS is in this memory-only mode. To address this, PSM can call SECMOD_OpenUserDB with the user's profile directory. This will make these data and modules usable by the platform.<br />
<br />
=== Remaining Issues ===<br />
<br />
==== Use of PK11_GetInternalKeySlot() ====<br />
PK11_GetInternalKeySlot is used to get a handle on the software token that backs the user's persistent certificate and key database. When NSS is initialized in memory-only mode, operations that expect to modify persistent data on this token will fail. Consequently, any platform code that calls PK11_GetInternalKeySlot must instead get a handle on the software slot/token as loaded by the call to SECMOD_OpenUserDB (see above). Similarly, any NSS code that calls PK11_GetInternalKeySlot must be avoided or worked around, as it will not work correctly. For example, CERT_AddTempCertToPerm (which is used to take an existing temporary certificate and save it in the persistent database) is hard-coded to use PK11_GetInternalKeySlot. However, PK11_ImportCert can be used in combination with CERT_ChangeCertTrust in place of CERT_AddTempCertToPerm to save the certificate on a specific slot (in this case, the real persistent database as loaded by SECMOD_OpenUserDB).<br />
<br />
==== The NSS Certificate Nickname API ====<br />
NSS exposes APIs whereby certificates can be referred to by nickname. Certificates on tokens other than that returned by PK11_GetInternalKeySlot prefix their nickname with the name of the token. Because platform code now must operate on a token that isn't the internal one, this behavior must be worked around by special-casing unprefixed nicknames when using these and related APIs.<br />
<br />
==== Loading New PKCS#11 Modules ====<br />
Currently when a new PKCS#11 module is loaded, its presence is persisted in the user's module database, meaning that it will automatically be loaded the next time the platform runs. When NSS is initialized in memory-only mode, this will not work. Consequently, we must come up with some way of persisting the PKCS#11 modules the user wants the platform to load when it starts. Upon PSM initialization, the known modules can be loaded for the duration of the session.<br />
<br />
==== PKCS#11 XPCOM APIs ====<br />
Currently the platform exposes some PKCS#11 module APIs that include such functionality as getting a handle on the internal module, listing known modules, and searching for modules, tokens, and/or slots. Because the user's software token is now not the same as that returned by PK11_GetInternalKeySlot, these APIs must be special-cased to continue to behave as expected. For example, if the user searches for a module with a blank name, the internal module (as loaded by SECMOD_OpenUserDB) must be returned.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=CA:AddRootToFirefox&diff=1154073CA:AddRootToFirefox2016-11-08T22:26:11Z<p>Dkeeler: /* Experimental Built-in Windows Support */ update additional registry locations searched as of Firefox 52</p>
<hr />
<div>= Installing Certificates Into Firefox =<br />
<br />
There are lots of organizations that use their own certificate authorities (CAs) to issue certificates for their internal servers. Since Firefox does not use the operating system's certificate store by default, these have to be manually added into Firefox. This page will cover how to get those CAs into Firefox.<br />
<br />
== Experimental Built-in Windows Support ==<br />
As of version 49, Firefox can be experimentally configured to automatically search for and import CAs that have been added to the Windows certificate store by a user or administrator. To do so, set the preference "security.enterprise_roots.enabled" to true. In this mode, Firefox will inspect the HKLM\SOFTWARE\Microsoft\SystemCertificates registry location (corresponding to the API flag CERT_SYSTEM_STORE_LOCAL_MACHINE) for CAs that are trusted to issue certificates for TLS web server authentication. Any such CAs will be imported and trusted by Firefox, although note that they may not appear in the Firefox's certificate manager. It is expected that administration of these CAs (e.g. trust configuration) will occur via built-in Windows tools or other 3rd party utilities. Note also that for such changes to take effect in Firefox either the preference will have to be toggled off and on again or Firefox will have to be restarted. As this feature evolves, this may be handled automatically for ease of use.<br />
<br />
As of version 52, Firefox will also search the registry locations HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\Root\Certificates and HKLM\SOFTWARE\Microsoft\EnterpriseCertificates\Root\Certificates (corresponding to the API flags CERT_SYSTEM_STORE_LOCAL_MACHINE_GROUP_POLICY and CERT_SYSTEM_STORE_LOCAL_MACHINE_ENTERPRISE, respectively).<br />
<br />
=== Credits ===<br />
The original content in this wiki page was copied (with permission) from [http://mike.kaply.com/2015/02/10/installing-certificates-into-firefox/ Mike Kaply's Blog].<br />
<br />
== CCK2 ==<br />
<br />
The easiest way to get your CAs into Firefox is to use [http://mike.kaply.com/cck2/ CCK2]. [http://mike.kaply.com/cck2/ CCK2] allows certificate authorities and server certificates to be installed into the browser. It supports PEM, DER and text. It also allows you to designate certificate overrides (sites where certificate errors are ignored). Just go to the certificate page and point to either a URL or a local file where the certificate is contained.<br />
<br />
* CCK2 is a [https://addons.mozilla.org/en-US/firefox/addon/cck2wizard/?src=kaply.com Firefox Add-On]<br />
* [http://mike.kaply.com/addons/cck2/cck2-support/ CCK2 Support]<br />
<br />
== AutoConfig via JavaScript ==<br />
<br />
If you're using AutoConfig without CCK2, you can still use [http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/public/nsIX509CertDB.idl#389 the API] that the CCK2 uses to install certificate authorities. Here's what it looks like to install the [http://www.cacert.org/index.php?id=3 cacert.org root certificate]:<br />
<br />
# var certdb = Cc["@mozilla.org/security/x509certdb;1"].getService(Ci.nsIX509CertDB);<br />
# var certdb2 = certdb;<br />
# try {<br />
# certdb2 = Cc["@mozilla.org/security/x509certdb;1"].getService(Ci.nsIX509CertDB2);<br />
# } catch (e) {}<br />
# cert = "MIIHPT...zTMVD"; // This should be the certificate content with no line breaks at all.<br />
# certdb2.addCertFromBase64(cert, "C,C,C", "");<br />
<br />
The three Cs mean to trust the certficate for servers, email and objects. The third parameter is the name, but it is ignored. If you want to install binary certificates, things get more complicated. In that case, I'd definitely recommend the [http://mike.kaply.com/cck2/ CCK2].<br />
<br />
== PolicyPak ==<br />
<br />
[http://www.policypak.com/products/manage-firefox-with-group-policy.html PolicyPak] supports adding certificate authorites to Firefox via Group Policy.<br />
<br />
== Preload the certificate databases ==<br />
<br />
Some people create a new profile in Firefox, install the certificates they need, and then distribute the various db files (cert8.db, key3.db and secmod.db) into new profiles using [http://mike.kaply.com/2012/03/30/customizing-firefox-default-profiles/ this method]. This is not the recommended approach, and this method only works for new profiles.<br />
<br />
== certutil ==<br />
<br />
If you're a real diehard, you can use [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Tools/certutil certutil] to update the Firefox certificate databases from the command line.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/HTTP_Strict_Transport_Security_(HSTS)_Preload_List&diff=1149809SecurityEngineering/HTTP Strict Transport Security (HSTS) Preload List2016-09-30T20:08:55Z<p>Dkeeler: some reorganization, add update output for other branches</p>
<hr />
<div>Firefox ships with a list of hosts that are considered HTTP Strict Transport Security (HSTS - [https://tools.ietf.org/html/rfc6797 see RFC 6797]) by default. This list is based on [https://www.chromium.org/hsts/ a list Chromium maintains]. The versions of the list as it exists in the various channels of Firefox are available here: [https://hg.mozilla.org/mozilla-central/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-central] [https://hg.mozilla.org/releases/mozilla-aurora/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-aurora] [https://hg.mozilla.org/releases/mozilla-beta/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-beta] [https://hg.mozilla.org/releases/mozilla-release/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-release] [https://hg.mozilla.org/releases/mozilla-esr45/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-esr45].<br />
<br />
Each Saturday, an automated job attempts to update the preload list in mozilla-central, mozilla-aurora, and mozilla-esr. This involves running an xpcshell script that makes an https request to each candidate host on the list. If xpcshell can connect successfully to a host and receives a "Strict-Transport-Security" header with a max-age value of at least 10886400 (18 weeks in seconds), that host is included in the list (the "preload" directive is ignored). If xpcshell cannot connect successfully to a host or does not receive an appropriate header, that host is not included in the preload list. A corresponding entry in [https://hg.mozilla.org/mozilla-central/file/tip/security/manager/ssl/nsSTSPreloadList.errors this file] may help in determining the underlying error.<br />
<br />
The xpcshell script is [https://hg.mozilla.org/mozilla-central/file/tip/security/manager/tools/getHSTSPreloadList.js here]. Output from the automated job as run on each branch is available here: [https://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-central-linux64/ mozilla-central] [https://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-aurora-linux64/ mozilla-aurora] [https://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-esr45-linux64/ mozilla-esr45] (search for "periodicupdate").<br />
<br />
To guard against accidentally dropping a host from the list due to intermittent network issues or an active attacker, if a host is already on the preload list in Firefox but cannot be reached, the script keeps it on the preload list. For a host to be removed from Firefox's preload list, it must be accessible when the update script runs and it must either not send a Strict-Transport-Security header or it must send the header with a max-age less than 10886400.<br />
<br />
The preload list has a built-in expiration time that is 18 weeks from when the list was most recently updated.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/HTTP_Strict_Transport_Security_(HSTS)_Preload_List&diff=1149808SecurityEngineering/HTTP Strict Transport Security (HSTS) Preload List2016-09-30T20:01:37Z<p>Dkeeler: remove unnecessary header, add note that preload directive is ignored</p>
<hr />
<div>Firefox ships with a list of hosts that are considered HTTP Strict Transport Security (HSTS - [https://tools.ietf.org/html/rfc6797 see RFC 6797]) by default. This list is based on [https://www.chromium.org/hsts/ a list Chromium maintains]. The versions of the list as it exists in the various channels of Firefox are available here: [https://hg.mozilla.org/mozilla-central/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-central] [https://hg.mozilla.org/releases/mozilla-aurora/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-aurora] [https://hg.mozilla.org/releases/mozilla-beta/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-beta] [https://hg.mozilla.org/releases/mozilla-release/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-release] [https://hg.mozilla.org/releases/mozilla-esr45/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-esr45].<br />
<br />
Each Saturday, an automated job attempts to update the preload list in mozilla-central, mozilla-aurora, and mozilla-esr. This involves running an xpcshell script that makes an https request to each candidate host on the list. If xpcshell can connect successfully to a host and receives a "Strict-Transport-Security" header with a max-age value of at least 10886400 (18 weeks in seconds), that host is included in the list (the "preload" directive is ignored). The xpcshell script is [https://hg.mozilla.org/mozilla-central/file/tip/security/manager/tools/getHSTSPreloadList.js here]. Output from the automated job is [https://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-central-linux64/ here] (search for "periodicupdate"). If xpcshell cannot connect successfully to a host or does not receive an appropriate header, that host is not included in the preload list. A corresponding entry in [https://hg.mozilla.org/mozilla-central/file/tip/security/manager/ssl/nsSTSPreloadList.errors this file] may help in determining the underlying error.<br />
<br />
To guard against accidentally dropping a host from the list due to intermittent network issues or an active attacker, if a host is already on the preload list in Firefox but cannot be reached, the script keeps it on the preload list. For a host to be removed from Firefox's preload list, it must be accessible when the update script runs and it must either not send a Strict-Transport-Security header or it must send the header with a max-age less than 10886400.<br />
<br />
The preload list has a built-in expiration time that is 18 weeks from when the list was most recently updated.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/HTTP_Strict_Transport_Security_(HSTS)_Preload_List&diff=1149807SecurityEngineering/HTTP Strict Transport Security (HSTS) Preload List2016-09-30T19:49:30Z<p>Dkeeler: initial description of the preload list, how it gets updated, etc.</p>
<hr />
<div>=HTTP Strict Transport Security (HSTS) Preload List=<br />
<br />
Firefox ships with a list of hosts that are considered HTTP Strict Transport Security (HSTS - [https://tools.ietf.org/html/rfc6797 see RFC 6797]) by default. This list is based on [https://www.chromium.org/hsts/ a list Chromium maintains]. The versions of the list as it exists in the various channels of Firefox are available here: [https://hg.mozilla.org/mozilla-central/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-central] [https://hg.mozilla.org/releases/mozilla-aurora/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-aurora] [https://hg.mozilla.org/releases/mozilla-beta/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-beta] [https://hg.mozilla.org/releases/mozilla-release/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-release] [https://hg.mozilla.org/releases/mozilla-esr45/file/tip/security/manager/ssl/nsSTSPreloadList.inc mozilla-esr45].<br />
<br />
Each Saturday, an automated job attempts to update the preload list in mozilla-central, mozilla-aurora, and mozilla-esr. This involves running an xpcshell script that makes an https request to each candidate host on the list. If xpcshell can connect successfully to a host and receives a "Strict-Transport-Security" header with a max-age value of at least 10886400 (18 weeks in seconds), that host is included in the list. The xpcshell script is [https://hg.mozilla.org/mozilla-central/file/tip/security/manager/tools/getHSTSPreloadList.js here]. Output from the automated job is [https://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-central-linux64/ here] (search for "periodicupdate"). If xpcshell cannot connect successfully to a host or does not receive an appropriate header, that host is not included in the preload list. A corresponding entry in [https://hg.mozilla.org/mozilla-central/file/tip/security/manager/ssl/nsSTSPreloadList.errors this file] may help in determining the underlying error.<br />
<br />
To guard against accidentally dropping a host from the list due to intermittent network issues or an active attacker, if a host is already on the preload list in Firefox but cannot be reached, the script keeps it on the preload list. For a host to be removed from Firefox's preload list, it must be accessible when the update script runs and it must either not send a Strict-Transport-Security header or it must send the header with a max-age less than 10886400.<br />
<br />
The preload list has a built-in expiration time that is 18 weeks from when the list was most recently updated.</div>Dkeelerhttps://wiki.mozilla.org/index.php?title=CA:AddRootToFirefox&diff=1143505CA:AddRootToFirefox2016-08-10T17:45:42Z<p>Dkeeler: add section on upcoming Windows support</p>
<hr />
<div>= Installing Certificates Into Firefox =<br />
<br />
There are lots of organizations that use their own certificate authorities (CAs) to issue certificates for their internal servers. Since Firefox does not use the operating system's certificate store by default, these have to be manually added into Firefox. This page will cover how to get those CAs into Firefox.<br />
<br />
== Experimental Built-in Windows Support ==<br />
As of version 49, Firefox can be experimentally configured to automatically search for and import CAs that have been added to the Windows certificate store by a user or administrator. To do so, set the preference "security.enterprise_roots.enabled" to true. In this mode, Firefox will inspect the CERT_SYSTEM_STORE_LOCAL_MACHINE registry location for CAs that are trusted to issue certificates for TLS web server authentication. Any such CAs will be imported and trusted by Firefox, although note that they may not appear in the Firefox's certificate manager. It is expected that administration of these CAs (e.g. trust configuration) will occur via built-in Windows tools or other 3rd party utilities. Note also that for such changes to take effect in Firefox either the preference will have to be toggled off and on again or Firefox will have to be restarted. As this feature evolves, this may be handled automatically for ease of use. In the future, other registry locations may also be inspected for CAs. See for example [https://bugzilla.mozilla.org/show_bug.cgi?id=1289865 Bug 1289865] for including CERT_SYSTEM_STORE_LOCAL_MACHINE_GROUP_POLICY.<br />
<br />
=== Credits ===<br />
The original content in this wiki page was copied (with permission) from [http://mike.kaply.com/2015/02/10/installing-certificates-into-firefox/ Mike Kaply's Blog].<br />
<br />
== CCK2 ==<br />
<br />
The easiest way to get your CAs into Firefox is to use [http://mike.kaply.com/cck2/ CCK2]. [http://mike.kaply.com/cck2/ CCK2] allows certificate authorities and server certificates to be installed into the browser. It supports PEM, DER and text. It also allows you to designate certificate overrides (sites where certificate errors are ignored). Just go to the certificate page and point to either a URL or a local file where the certificate is contained.<br />
<br />
* CCK2 is a [https://addons.mozilla.org/en-US/firefox/addon/cck2wizard/?src=kaply.com Firefox Add-On]<br />
* [http://mike.kaply.com/addons/cck2/cck2-support/ CCK2 Support]<br />
<br />
== AutoConfig via JavaScript ==<br />
<br />
If you're using AutoConfig without CCK2, you can still use [http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/public/nsIX509CertDB.idl#389 the API] that the CCK2 uses to install certificate authorities. Here's what it looks like to install the [http://www.cacert.org/index.php?id=3 cacert.org root certificate]:<br />
<br />
# var certdb = Cc["@mozilla.org/security/x509certdb;1"].getService(Ci.nsIX509CertDB);<br />
# var certdb2 = certdb;<br />
# try {<br />
# certdb2 = Cc["@mozilla.org/security/x509certdb;1"].getService(Ci.nsIX509CertDB2);<br />
# } catch (e) {}<br />
# cert = "MIIHPT...zTMVD"; // This should be the certificate content with no line breaks at all.<br />
# certdb2.addCertFromBase64(cert, "C,C,C", "");<br />
<br />
The three Cs mean to trust the certficate for servers, email and objects. The third parameter is the name, but it is ignored. If you want to install binary certificates, things get more complicated. In that case, I'd definitely recommend the [http://mike.kaply.com/cck2/ CCK2].<br />
<br />
== PolicyPak ==<br />
<br />
[http://www.policypak.com/products/manage-firefox-with-group-policy.html PolicyPak] supports adding certificate authorites to Firefox via Group Policy.<br />
<br />
== Preload the certificate databases ==<br />
<br />
Some people create a new profile in Firefox, install the certificates they need, and then distribute the various db files (cert8.db, key3.db and secmod.db) into new profiles using [http://mike.kaply.com/2012/03/30/customizing-firefox-default-profiles/ this method]. This is not the recommended approach, and this method only works for new profiles.<br />
<br />
== certutil ==<br />
<br />
If you're a real diehard, you can use [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Tools/certutil certutil] to update the Firefox certificate databases from the command line.</div>Dkeeler