diff options
Diffstat (limited to 'chromium/net/docs')
| -rw-r--r-- | chromium/net/docs/bug-triage-labels.md | 11 | ||||
| -rw-r--r-- | chromium/net/docs/bug-triage-suggested-workflow.md | 112 | ||||
| -rw-r--r-- | chromium/net/docs/bug-triage.md | 191 | ||||
| -rw-r--r-- | chromium/net/docs/certificate_lifetimes.md | 78 | ||||
| -rw-r--r-- | chromium/net/docs/net-log.md | 7 |
5 files changed, 167 insertions, 232 deletions
diff --git a/chromium/net/docs/bug-triage-labels.md b/chromium/net/docs/bug-triage-labels.md index d32cde11826..1a9724e9221 100644 --- a/chromium/net/docs/bug-triage-labels.md +++ b/chromium/net/docs/bug-triage-labels.md @@ -10,22 +10,11 @@ that die in the SSL negotiation phase, in particular, this is often the correct component. -* **Internals>Network>DataProxy** - - Flywheel / the Data Reduction Proxy. Issues require "Reduce Data Usage" be - turned on. Proxy URL is [https://proxy.googlezip.net:443](#), with - [http://compress.googlezip.net:80](#) as a fallback. Currently Android and - iOS only. - * **Internals>Network>Cache** The cache is the layer that handles most range request logic (Though range requests may also be issued by the PDF plugin, XHRs, or other components). -* **Internals>Network>SPDY** - - Covers HTTP2 as well. - * **Internals>Network>HTTP** Typically not used. Unclear what it covers, and there's no specific HTTP diff --git a/chromium/net/docs/bug-triage-suggested-workflow.md b/chromium/net/docs/bug-triage-suggested-workflow.md deleted file mode 100644 index 4807c72b95a..00000000000 --- a/chromium/net/docs/bug-triage-suggested-workflow.md +++ /dev/null @@ -1,112 +0,0 @@ -# Chrome Network Bug Triage : Suggested Workflow - -[TOC] - -## Identifying unlabeled network bugs on the tracker - -* Look at new unconfirmed bugs since noon PST on the last triager's rotation. - [Use this issue tracker - query](https://bugs.chromium.org/p/chromium/issues/list?q=status%3Aunconfirmed&sort=-id&num=1000). - -* Read the title of the bug. - -* If a bug looks like it might be network related, middle click (or - command-click on OSX) to open it in a new tab. - -* If a user provides a crash ID for a crasher for a bug that could be - net-related, see the [internal instructions on dealing with a crash ID](https://goto.google.com/network_triage_internal#dealing-with-a-crash-id) - -* If network causes are possible, ask for a net-export log (If it's not a - browser crash) and attach the most specific internals-network label that's - applicable. If there isn't an applicable narrower component, a clear owner - for the issue, or there are multiple possibilities, attach the - Internals>Network component and proceed with further investigation. - -* If non-network causes also seem possible, attach those components as well. - -## Investigating component=Internals>Network bugs - -* Note that you may want to investigate Needs-Feedback bugs first, as - that may result in some bugs being added to this list. - -* It's recommended that while on triage duty, you subscribe to the - Internals>Network component (but not its subcomponents). To do this, go - to the issue tracker and then click "Saved Queries". - Add a query with these settings: - * Saved query name: Network Bug Triage - * Project: chromium - * Query: component=Internals>Network - * Subscription options: Notify Immediately - -* Look through unconfirmed and untriaged component=Internals>Network bugs, - prioritizing those updated within the last week. [Use this issue tracker - query](https://bugs.chromium.org/p/chromium/issues/list?can=2&q=component%3DInternals%3ENetwork+status%3AUnconfirmed,Untriaged+-label:Needs-Feedback&sort=-modified). - -* If more information is needed from the reporter, ask for it and add the - Needs-Feedback label. - -* While investigating a new issue, change the status to Untriaged. - -* If a bug is a potential security issue (Allows for code execution from remote - site, allows crossing security boundaries, unchecked array bounds, etc) mark - it Type-Bug-Security. If it has privacy implication (History, cookies - discoverable by an entity that shouldn't be able to do so, incognito state - being saved in memory or on disk beyond the lifetime of incognito tabs, etc), - mark it with component Privacy. - -* For bugs that already have a more specific network component, go ahead and - remove the Internals>Network component to get them off the next triager's - radar and move on. - -* Try to figure out if it's really a network bug. See common non-network - components section for description of common components for issues incorrectly - tagged as Internals>Network. - -* If it's not, attach appropriate labels/components and go no further. - -* If it may be a network bug, attach additional possibly relevant component if - any, and continue investigating. Once you either determine it's a - non-network bug, or figure out accurate more specific network components, your - job is done, though you should still ask for a net-export dump if it seems - likely to be useful. - -* Note that Chrome-OS-specific network-related code (Captive portal detection, - connectivity detection, login, etc) may not all have appropriate more - specific subcomponents, but are not in areas handled by the network stack - team. Just make sure those have the OS-Chrome label, and any more specific - labels if applicable, and then move on. - -* Gather data and investigate. - * Remember to add the Needs-Feedback label whenever waiting for the user to - respond with more information, and remove it when not waiting on the - user. - * Try to reproduce locally. If you can, and it's a regression, use - src/tools/bisect-builds.py to figure out when it regressed. - * Ask more data from the user as needed (net-export dumps, repro case, - crash ID from chrome://crashes, run tests, etc). - * If asking for a chrome://net-export dump, provide this link: - https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details. - -* Try to figure out what's going on, and which more specific network component - is most appropriate. - -* If it's a regression, browse through the git history of relevant files to try - and figure out when it regressed. CC authors / primary reviewers of any - strongly suspect CLs. - -* If you are having trouble with an issue, particularly for help understanding - net-export logs, email the public net-dev@chromium.org list for help - debugging. If it's a crasher, or for some other reason discussion needs to - be done in private, see [internal documentation for details](https://goto.google.com/network_triage_internal#getting-help-with-a-bug) - -* If it appears to be a bug in the unowned core of the network stack (i.e. no - subcomponent applies, or only the Internals>Network>HTTP subcomponent - applies, and there's no clear owner), try to figure out the exact cause. - -## Crashes - -For guidance on crashes see the internal documentation: - -* [Dealing with a crash ID](https://goto.google.com/network_triage_internal#dealing-with-a-crash-id) -* [Looking for new crashers](https://goto.google.com/network_triage_internal#looking-for-new-crashers) -* [Investigating crashers](https://goto.google.com/network_triage_internal#investigating-crashers) diff --git a/chromium/net/docs/bug-triage.md b/chromium/net/docs/bug-triage.md index 25348795d97..ab02bbe8ff8 100644 --- a/chromium/net/docs/bug-triage.md +++ b/chromium/net/docs/bug-triage.md @@ -1,115 +1,96 @@ # Chrome Network Bug Triage -The Chrome network team uses a two day bug triage rotation. The main goals are -to identify and label new network bugs, and investigate network bugs when no -label seems suitable. +The Chrome network team uses a two day bug triage rotation. The goal is to +review outstanding issues and keep things moving forward. The rotation is time +based rather than objective based. Sheriffs are expected to spend the majority +of their two days working on bug triage/investigation. + +## 1. Review untriaged bugs + +Look through [this list of untriaged +bugs](https://bugs.chromium.org/p/chromium/issues/list?sort=pri%20-stars%20-opened&q=component%3AInternals%3ENetwork%20status%3Aunconfirmed%2Cuntriaged%20-component%3AInternals%3ENetwork%3ECookies%20-component%3AInternals%3ENetwork%3EDNS%20-component%3AInternals%3ENetwork%3ECookies%20-component%3AInternals%3ENetwork%3ECertificate%20-component%3AInternals%3ENetwork%3EReportingAndNEL%20-component%3AInternals%3ENetwork%3EDataUse%20-component%3AInternals%3ENetwork%3EEV%20-component%3AInternals%3ENetwork%3EDataProxy%20-component%3AInternals%3ENetwork%3ECertTrans%20-component%3AInternals%3ENetwork%3ENetworkQuality%20-component%3AInternals%3ENetwork%3EDoH%20-component%3AInternals%3ENetwork%3ENetInfo%20-component%3AInternals%3ENetwork%3EVPN%20-Needs%3DFeedback). + +* Go through them in the given order (top to bottom). + The link sorts them by priority and then recency. +* The goal is to move them out of the untriaged bug queue and give them a priority. + +For each bug try to: + +* Remove the `Internals>Network` component if it belongs elsewhere +* Dupe it against an existing bug +* Close it `WontFix` if appropriate +* Give the bug a priority. Refer to [this (internal) document for guidelines](https://goto.google.com/xnzwn) +* If the bug is a potential security issue (Allows for code execution from remote + site, allows crossing security boundaries, unchecked array bounds, etc) mark + it `Type-Bug-Security`. +* If the bug has privacy implications mark it with component `Privacy`. +* Mark it as a feature request or task if appropriate +* Ask the reporter to narrow down regressions, possibly by using + [bisect-builds-py](https://www.chromium.org/developers/bisect-builds-py). To + view suspicious changelists in a regression window, you can use the Change Log + form on [OmahaProxy](https://omahaproxy.appspot.com/) +* CC others who may be able to help +* Mark it as `Needs-Feedback` and request more information if needed. +* Request a NetLog that captures the problem. You can paste this on the bug: + ``` + Please collect and attach a chrome://net-export log. + Instructions can be found here: + https://chromium.org/for-testers/providing-network-details + ``` +* If a NetLog was provided, try to spend a bit of time reviewing it. See + [crash-course-in-net-internals.md](crash-course-in-net-internals.md) for an + introduction. +* Move to a subcomponent of `Internals>Network` if appropriate. See + [bug-triage-labels.md](bug-triage-labels.md) for an overview of the components. +* If the bug is a crash, see [internal: Dealing with a crash + ID](https://goto.google.com/network_triage_internal#dealing-with-a-crash-id) +and [internal: Investigating +crashers](https://goto.google.com/network_triage_internal#investigating-crashers) + +## 2. Follow-up on issues with the Needs-Feedback label + +Look through [this list of Needs=Feedback +bugs](https://bugs.chromium.org/p/chromium/issues/list?sort=pri%20-modified&q=component%3AInternals%3ENetwork%20Needs%3DFeedback%20-component%3AInternals%3ENetwork%3ECookies%20-component%3AInternals%3ENetwork%3EDNS%20-component%3AInternals%3ENetwork%3ECookies%20-component%3AInternals%3ENetwork%3ECertificate%20-component%3AInternals%3ENetwork%3EReportingAndNEL%20-component%3AInternals%3ENetwork%3EDataUse%20-component%3AInternals%3ENetwork%3EEV%20-component%3AInternals%3ENetwork%3EDataProxy%20-component%3AInternals%3ENetwork%3ECertTrans%20-component%3AInternals%3ENetwork%3ENetworkQuality%20-component%3AInternals%3ENetwork%3EDoH%20-component%3AInternals%3ENetwork%3ENetInfo%20-component%3AInternals%3ENetwork%3EVPN). + +* Go through them in the given order (top to bottom). + The link sorts them by priority and then recency. +* If the requested feedback was provided, review the new information and repeat + the same steps as (1) to re-triage based on the new information. +* If the bug had the `Needs-Feedback` label for over a week and the + feedback needed to make progress was not yet provided, archive the bug. + +## 3. (Optional) Look through crash reports + +Top crashes will already be entered into the bug system by a different process, +so will be handled by the triage steps above. + +However if you have time to look through lower threshold crashes, see +[internal: Looking for new crashers](https://goto.google.com/network_triage_internal#looking-for-new-crashers) + +## 4. Send out a sheriff report + +On the final day of your rotation, send a brief summary to net-dev@chromium.org +detailing any interesting or concerning trends. Do not discuss any restricted +bugs on the public mailing list. ## Management -Owners for the network bug triage rotation can find instructions on -generating and modifying shifts -[here (internal-only)](https://goto.google.com/pflvb). - -## Responsibilities - -### Required, in rough order of priority: -* Identify new network bugs on the tracker. -* Investigate recent `Internals>Network` issues with no subcomponent. -* Follow up on `Needs-Feedback` issues for all network components. -* Identify and file bugs for significant new crashers. - -### Best effort, also in rough priority order: -* Investigate unowned and owned-but-forgotten net/ crashers. -* Investigate old bugs. -* Close obsolete bugs. - -All of the above is to be done on each rotation. These responsibilities should -be tracked, and anything left undone at the end of a rotation should be handed -off to the next triager. The downside to passing along bug investigations like -this is each new triager has to get back up to speed on bugs the previous -triager was investigating. The upside is that triagers don't get stuck -investigating issues after their time after their rotation, and it results in a -uniform, predictable two day commitment for all triagers. - -## Details - -### Required: - -* Identify new network bugs on the bug tracker, looking at [this issue tracker - query](https://bugs.chromium.org/p/chromium/issues/list?q=status%3Aunconfirmed+-commentby=425761728072-pa1bs18esuhp2cp2qfa1u9vb6p1v6kfu@developer.gserviceaccount.com&sort=-id&num=1000). - - * All Unconfirmed issues filed during your triage rotation should be scanned - for suspected network bugs, a network component assigned and a - chrome://net-export/ log requested. Suggested text: "Please collect and - attach a chrome://net-export log. Instructions can be found here: - https://chromium.org/for-testers/providing-network-details". - A link to the instructions appears on net-export, for easy reference. - When asking for a log or more details, attach the Needs-Feedback label. - - * A triager is responsible for looking at bugs reported from noon PST / - 3:00 pm EST of the last day of the previous triager's rotation until the - same time on the last day of their rotation. - -* Investigate [Unconfirmed / Untriaged Internals>Network issues that don't belong to a more specific network component](https://bugs.chromium.org/p/chromium/issues/list?can=2&q=component%3DInternals%3ENetwork+status%3AUnconfirmed,Untriaged+-label:Needs-Feedback&sort=-modified), - prioritizing the most recent issues, ones with the most responsive reporters, - and major crashers. This will generally take up the majority of your time as - triager. Continue digging until you can do one of the following: - - * Mark it as `WontFix` (working as intended, obsolete issue) or a - duplicate. - - * Mark it as a feature request. +* Your rotation will appear in Google Calendar as two days. You are expected to + work on it full-time (as best you can) during those calendar days, during your + ordinary working hours. - * Mark it as `Needs-Feedback`. +* Google Calendar [google.com_52n2p39ad82hah9v7j26vek830@group.calendar.google.com](https://calendar.google.com/calendar/embed?src=google.com_52n2p39ad82hah9v7j26vek830%40group.calendar.google.com&ctz=America%2FLos_Angeles) - * Remove the `Internals>Network` component, replacing it with at least one - more specific network component or non-network component. Replacing the - `Internals>Network` component gets it off the next triager's radar, and - in front of someone more familiar with the relevant code. Note that - due to the way the bug report wizard works, a lot of bugs incorrectly end - up with the network component. - - * The issue is assigned to an appropriate owner. Make sure to mark it as - "assigned" so the next triager doesn't run into it. - - * If there is no more specific component for a bug, it should be - investigated by the triager until we have a good understanding of the - cause of the problem, and some idea how it should be fixed, at which point - its status should be set to Available. Future triagers should ignore bugs - with this status, unless investigating stale bugs. - -* Follow up on [Needs-Feedback issues for all components owned by the network stack team](https://bugs.chromium.org/p/chromium/issues/list?q=component%3AInternals%3ENetwork+-component%3AInternals%3ENetwork%3EDataProxy+-component%3AInternals%3ENetwork%3EDataUse+-component%3AInternals%3ENetwork%3EVPN+Needs%3DFeedback&sort=-modified). - - * Remove label once feedback is provided. Continue to investigate, if - the previous section applies. - - * If the `Needs-Feedback` label has been present for one week, ping the - reporter. - - * Archive after two weeks with no feedback, telling users to file a new - bug if they still have the issue, with the requested information, unless - the reporter indicates they'll provide data when they can. In that case, - use your own judgment for further pings or archiving. - -* Identify significant new crashes. See [internal documentation](https://goto.google.com/network_triage_internal#looking-for-new-crashers). - -### Best Effort (As you have time): - -* Investigate old bugs, and bugs associated with `Internals>Network` - subcomponents. - -* Investigate unowned and owned but forgotten net/ crashers that are still - occurring (As indicated by - [go/chromenetcrash](https://goto.google.com/chromenetcrash)), prioritizing - frequent and long standing crashers. - -* Close obsolete bugs. +* Owners for the network bug triage rotation can find instructions on +generating and modifying shifts +[here (internal-only)](https://goto.google.com/pflvb). -See [bug-triage-suggested-workflow.md](bug-triage-suggested-workflow.md) for -suggested workflows. +* An overview of bug trends can be seen on [Chromium + Dashboard](https://chromiumdash.appspot.com/components/Internals/Network?project=Chromium) -See [bug-triage-labels.md](bug-triage-labels.md) for labeling tips for network -and non-network bugs. +* There is also an [internal dashboard with bug trends for Web + Platform](https://goto.google.com/vufyq) that includes network issues. -See [crash-course-in-net-internals.md](crash-course-in-net-internals.md) for -some help on getting started with chrome://net-internals debugging. +* The issue tracker doesn't track any official mappings between components and + OWNERS. This [internal document](https://goto.google.com/kojfj) enumerates + the known owners for subcomponents. diff --git a/chromium/net/docs/certificate_lifetimes.md b/chromium/net/docs/certificate_lifetimes.md new file mode 100644 index 00000000000..ee413ef9157 --- /dev/null +++ b/chromium/net/docs/certificate_lifetimes.md @@ -0,0 +1,78 @@ +# Certificate Lifetimes + +As part of our ongoing commitment to ensuring users’ security, Google is +reducing the maximum allowed lifetimes of TLS certificates. + +## Upcoming Changes + +Beginning with Chrome 85, TLS server certificates issued on or after +2020-09-01 00:00:00 UTC will be required to have a validity period of 398 days +or less. This will only apply to TLS server certificates from CAs that are +trusted in a default installation of Google Chrome, commonly known as +"publicly trusted CAs", and will not apply to locally-operated CAs that have +been manually configured. + +Certificates that do not comply with this requirement will not work, and may +cause webpages to fail to load or to render incorrectly. + +If a certificate that does not comply with this requirement is issued by a CA +trusted in a default installation of Google Chrome, this will be treated as a +failure to comply with the security policies necessary to being a trusted CA, +and may result in the removal of trust of that CA’s certificates. + +## Technical Details + +* A certificate will be impacted by this restriction if either the notBefore + of the certificate is on or after 2020-09-01 00:00:00 UTC, or if the first + precertificate logged by the CA to a Certificate Transparency Log that is + qualified at time of issuance is on or after this date. +* The validity period of a certificate is defined within RFC 5280, Section + 4.1.2.5, as "the period of time from notBefore through notAfter, inclusive." +* 398 days is measured with a day being equal to 86,400 seconds. Any time + greater than this indicates an additional day of validity. +* To avoid the risk of misissuance, such as due to leap seconds or + CA-configured randomization, CAs SHOULD issue such server certificates with + validity periods of 397 days or less. + +## Frequently Asked Questions + +* Does this apply to locally-operated CAs, such as those used within + enterprises that use enterprise-configured configured CAs? + * No. This only applies to the set of CAs that are trusted by default by + Google Chrome, and not CAs that are operated by an enterprise and that + have no certification paths to CAs that are trusted by default. +* Is there an enterprise policy to disable this enforcement? + * No. These changes are transparent and do not offer an enterprise control + to override, as they only apply to so-called "publicly trusted" CAs. + Enterprises that wish to have certificates with validity periods longer + than 398 days may do so by using a locally-operated CA that does not have + any certification paths up to a publicly trusted CA. +* Does this mean I have to replace my existing certificates? + * No. This requirement only applies to new certificate issuance on or after + 2020-09-01 00:00:00 UTC. Existing certificates whose validity period + exceeds 398 days will continue to work, while new certificates must comply + with these new requirements, such as when they are renewed or replaced. +* Will this make certificates more expensive? + * As with past changes to the maximum certificate lifetimes, many CAs have + committed to providing additional certificates, as needed by the shortened + maximum lifetime, at no additional cost. +* What will happen if a certificate is issued that does not meet these + requirements? + * Google Chrome will reject such certificates as having too long a validity + period, consistent with existing validity-period based enforcement. + Additionally, such certificates will be treated as a critical security + failure by the CA, and may result in further action taken on the CA that + may affect how current or future certificates from that CA function. + Chromium-based browsers will have this enforcement enabled by default, and + will need to modify the source to disable this. +* What are other browsers doing? + * Apple previously announced this change for versions of iOS, iPadOS, macOS, + tvOS, and watchOS, as documented at + https://support.apple.com/en-us/HT211025, which will apply to all + applications, and not just those of Safari. This certificate lifetime + requirement is fully interoperable with Apple’s requirements. + + Microsoft, Mozilla, Opera, and 360 have previously indicated their support + for these requirements, although have not yet made announcements at the + time of this post (2020-06-22). Other browsers, including those browsers + based on Chromium, may provide additional guidance or clarification. diff --git a/chromium/net/docs/net-log.md b/chromium/net/docs/net-log.md index 4097bc87a1d..ebf7ceee681 100644 --- a/chromium/net/docs/net-log.md +++ b/chromium/net/docs/net-log.md @@ -69,10 +69,9 @@ That said, changing core events may have consequences for external consumers of NetLogs, which rely on the structure and parameters to events for pretty printing and log analysis. -The [NetLog -viewer](https://chromium.googlesource.com/catapult/+/master/netlog_viewer/) for -instance pretty prints certain parameters based on their names, and the event -name that added them. +The [NetLog viewer](https://netlog-viewer.appspot.com/) for instance pretty +prints certain parameters based on their names, and the event name that added +them. ### Example 1 |