Problem/Motivation

Drupal 7 does not set the samesite attribute for PHP session cookies, unless on PHP 7.3 or higher. Up until recently, all major browsers treated cookies without this attribute as if it were samesite=None. Recently (July 2020), Google Chrome has changed this with the release of Chrome 84, and cookies are treated as "Lax" if there is no samesite attribute set. The Drupal contrib module ecosystem has by and large been developed with the implicit assumption that browsers treat cookies as samesite=None. Additionally, some sites/modules aren't yet ready to upgrade to higher versions of PHP.

Drupal 7's documentation presently indicates that PHP 7.0 and higher is supported.

Steps to reproduce

I and other users have seen consequences of this for Drupal Commerce off-site payment redirects. This is where the user submits a form that POSTs to another domain (payment processor), and the payment processor sends the user back to the site with another POST (containing the verified payment data). Such an arrangement is a way of attaining PCI compliance (by the Drupal website never seeing a credit card number or other sensitive account information).

Contrib modules don't seem to be an appropriate/feasible place to change this in.

Proposed resolution

Modify drupal_session_start() so that it sets this attribute for PHP session cookies.

Since Drupal 7's contrib modules have been developed with the implicit assumption of samesite=None (and this is how web browsers have acted), explicitly set this cookie attribute. On PHP 7.3 and higher, this attribute can be based off of the php ini option: session.cookie_samesite="None". There is currently a related issue for Drupal 9.1.x, but it is for setting samesite=Lax.

Lower versions of PHP do not have built-in support for the samesite attribute. However, users on StackExchange and elsewhere have pointed out a workaround for PHP < 7.3 session cookies. The workaround involves modifying the cookie's path to append the string "; samesite=None" (or Lax, or Strict).

Detect incompatible browsers (which reject cookies having this attribute) via their User-Agent string, and avoid setting this attribute for them. Known incompatible clients are documented here: https://www.chromium.org/updates/same-site/incompatible-clients

Remaining tasks

Discuss and patch.

User interface changes

None

API changes

None. Possibly support a config variable that can be used as a substitute for the ini option (for PHP versions lower than 7.3).

Data model changes

None

Release notes snippet

Explicitly set the samesite cookie attribute (default: None).

Problem/Motivation

format_size() is still a procedural function. Convert it to a object oriented code.

Proposed resolution

• Add a ::formatByteSize() method to TranslationInterface and its TranslationManager implementation
• Add a ::formatByteSize() method to StringTranslationTrait as a helper to access TranslationManager::formatByteSize.
• Deprecate and remove usages of format_size().
• Add related PHP unit tests.

This way any object implementing StringTranslationTrait (forms, plugins, controllers etc.) can simply replace format_size with $this->formatByteSize, while other code (procedural functions, hook implementations, etc) can replace with \Drupal::translation()->formatByteSize.

Remaining tasks

review/commit

User interface changes

none

API changes

See proposed resolution.

Problem/Motivation

In node forms there is considerable space between the primary form and the meta on the right. In several issues and discussions, this presentation is considered aesthetically less than ideal, and it's also punishing to users with compromised motor function due to it requiring the pointer to travel unnecessarily long distances to access all relevant parts of the form.

Here's how it looks currently

In the not-yet-committed issue #3092296: Limit width of form elements (max-width), the solution will likely be limiting the width of form elements, which makes this chasm even more apparent.

Proposed resolution

Limit width of the main column to 768px. Fix width of the meta column to 360px. Align the meta column to right and center the main column within the area that is left.

Remaining tasks

Agree on approach
Design
Implement

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Currently Drupal core does not display any information about upcoming security releases. This means that site admins must check outside of Drupal to know whether a security release will be released soon.

Very rarely there are highly critical security releases that have the potential to affect so many sites that it would be good to notify site admins from inside Drupal.

As part of the Automatic Update initiative in #3039120: Create initial feature to display relevant PSA data in Drupal the Automatic Updates contrib module displayed PSA and SA messages from a feed from drupal.org inside Drupal itself. This feed was created in #3068539: Add psa.json API endpoint to support automatic updates and was intended also to be used by Drupal core. The documentation of this feed can be seen here:https://www.drupal.org/docs/8/update/automatic-updates#s-public-service-...

Proposed resolution

Notify site admins of PSA and other security advisory items that appear in the json feed at https://updates.drupal.org/psa.json
This feed is used by the security team for only critical security announcements

The sites admins will be notified in 3 ways.

1. On the status report page at admin/reports/status.
2. On administration pages for users who have the 'administer site configuration' permission.
3. Via email for the email addresses that set to receive emails for available updates.

Items in the feed will be determined to be relevant to a site if:

1. is_psa === 1 and the project is either drupal or an extension that is present on the site. The extension does not need to be installed
2. is_psa === 0 and the project is either drupal or an extension that is present on the site and the sites version of the project is in insecure

   If the site is using a dev version of an extension or drupal then:

   If the dev version only specifies a major version like 6.x-dev for branch using semantic versioning or 8.x-6.x for a branch using the legacy versions then
   Show the item if it matches the major version for any of the versions in insecure

   If the dev version specifies a major and minor version like 9.1.x-dev, for contrib or 9.1.0-dev, for core. then
   Show the item if it matches both the major and minor versions for any of the versions in insecure

Remaining Questions\tasks

Completed

1. Do we need the setting "Show Public service announcements on administrative pages." which the contrib module has? NO

   There is not a setting for turning off the existing feature for showing available updates. Since these new messages would be much more rare do we need a setting not to show them?

   Also because they are so rare 95%(percentage guessed 🤷🏼‍♂️) of the time if they unchecked this setting they would see no change to there site so it may not be clear why they would want to leave it on or what it actually does. If they leave it off by mistake the consequences could be very bad if they miss a critical security update.

2. Do we really need a separate psa.notify setting to control if we send emails?
   NO emails will be sent to email addresses in the current setting in the Update module. No extra setting will be provided.

   Could we just send emails to the email addresses in the existing notification.emails setting?

   This setting is described in the UI now as
   "Whenever your site checks for available updates and finds new releases, it can notify a list of users via email."

   Would sending emails now for PSAs also to these same emails be a good idea?

   If we have a separate check box for "Send email notifications for Public service announcements." then you could set up to send emails for new Updates but not send for PSA's but you could not set up your site to send emails for PSA's but not Updates.

   Because the PSA feed is currently being used for only highly critical items it's hard to imagine that you would want emails for Updates and not highly critical PSAs.

3. Determine if core should follow the same logic as the contrib module.
   Answer: We will show all is_psa === true items if the project is present on the local site it does not have to be installed because the admin should be aware of the risk of installing and certain risk don't require the module to be installed. For is_psa === FALSE then the item must match exactly a version in the insecure
   The contrib module currently displays all items in the feed where is_psa === true and the project is core or project is installed currently on the site. In addition for feed items where is_psa === false and the project is core or installed AND the currently installed version is in insecure

   If we only want to display highly critical PSA's then we may want to not show any feed item that is not is_psa === true.

   on #3068539: Add psa.json API endpoint to support automatic updates @drumm said

   The planned use of this API is only for highly critical updates which we hope as many Drupal sites as possible set to automatically update. It does not include all PSAs.

   We should get clarity if the json feed could change later to include anything other than highly critical updates. If it could then versions of core that were still in use before core changed it's logic to handle this would start to show other updates.

   Currently there is nothing in the feed that specifies security risk level. We could ask for this to be added to the feed properties. Then we could filter for it now even though no other updates should be in the feed. This way if they were added later they would still be filtered out.

4. Should we show PSA's for projects that are not installed? The contrib module does not but there are reasons we might want to:
   1. Certain remote code execution vulnerabilities might not require the module to be installed.
   2. A module could be installed at any point. A site admin should probably know that a critical security release is forthcoming in the next week so they can make an informed decision if they want to install a module or maybe wait until the release

Follow ups

1. Make a list of improvements and bugs found here that should be backported to the contrib module.
   1. After this is released in core update the contrib module to not display PSA's if the core version install will display the PSAs. This may just meaning checking for the existence of the services added in this patch
   2. 🔥🔥🔥 Critical Assumes extension name and project name are the same. See #42.1
   3. change getPublicServiceMessages() to throw exceptions rather return error messages as PSA messages are returned. change the callers to react to the exception and change what is displayed for an error.
   4. Added tests for invalid json
   5. Change to handle invalid versions of installed modules see #37.7(edge case)
   6. SecurityAnnouncement class with extra validation and getters
   7. Edge case: handle individual insecure versions that don't parse #37.6
   8. Throw validation error if notifications are set for PSA and no email is provided for the update module(contrib module doesn't have email setting of it's own), @see #43.2
   9. Don't send the same PSA email multiple times @see #43.3
   10. enable_psa setting in the UI is described in contrib module as
       

       Show Public service announcements on administrative pages.

       but it unchecked it will also stop emails and the status report.

API changes

Interfaces \Drupal\update\Psa\NotifyInterface and \Drupal\update\Psa\UpdatesPsaInterface

We may consider adding these interfaces later as the functionality is basically just reading a json feed and displaying info. Instead of providing an API via the interfaces we could simply check the for existence of our services in hook_cron and other places before proceeding. If a contrib module wanted to react to the PSA json in a different way it could just unset our services.

User interface changes

Critical security advisories and public service announcements will be displayed on the status report page and most admin pages to users who have 'administer site configuration' permission.

Status report page:

Messages on admin pages

Changing to Update settings form. Change is highlighted

Email text

SUBJECT: An urgent security announcement requires your attention for Drupal

An important security announcement is available for your Drupal site. You should 
read the announcement immediately and follow its instructions.

Public service announcements:

  * Critical Release - SA-2019-02-19 [1]

To see all public service announcements, visit
https://www.drupal.org/security/psa [2].


[1] https://www.drupal.org/sa-2019-02-19
[2] https://www.drupal.org/security/psa

Data model changes

Release notes snippet

For sites running the core Update manager, critical security advisories (SAs) and public service announcements (PSAs) will be displayed on the status report page and most admin pages to users who have the 'administer site configuration' permission.

Problem/Motivation

Make sure Drupal keeps being compatible with PHP 8. Work with dependencies as needed. See #3086374: Make Drupal 8 & 9 compatible with PHP 7.4 for how we did it with PHP 7.4. PHP 8.0 is feature frozen and beta4 is out, see https://www.php.net/archive/2020.php#2020-09-17-1

Proposed resolution

The following task list has been determined by testing on #3156595: Make Drupal 9 installable on PHP8.

1. Dependency updates to support PHP 8

To produce a list of dependencies that are blocking PHP 8 support, you can do the following. Make sure you use PHP 7.4+ to run it.

$ git clone --branch 9.1.x https://git.drupalcode.org/project/drupal.git whynotphp8
$ cd whynotphp8/
$ composer install
$ composer update
$ composer why-not php:8

Additionally to the composer reported dependencies above:

• behat/mink-selenium2-driver - https://github.com/minkphp/MinkSelenium2Driver/pull/320

2. Drupal issues that can be addressed in Drupal 8 & 9 today

These issues can proceed without worrying about the how and if vendor support works for PHP 8 since the changes are all PHP 7 compatible. We can keep the changes PHP 7.0 compatible to make things easy for Drupal 8.

• #3156542: \ReflectionParamter::getClass() is deprecated in PHP 8.0
• #3174662: Encapsulate \PDOStatement instead of extending from it or #3156881: Various methods of \Drupal\Core\Database\StatementInterface have changed their signature for PHP 8

3. Drupal issues that need a largely working PHP 8 build to test

• #3156887: \Drupal\system\Plugin\ImageToolkit\GDToolkit needs to support \GdImage objects for PHP 8 compatibility
  
  Should be okay for PHP 7.0 because it's really only loosening what we expect in \Drupal\system\Plugin\ImageToolkit\GDToolkit::$resource but testing this will be harder without all the above fixes and the fixes to vendor.

DONE

• In/with dependencies:
  • symfony/*, twig/twig, composer/* #3156558: Upgrade dependencies prior to 9.1.0 and #3157296: Upgrade dependencies prior to 9.1.0
  • Update symfony contract php requirement - https://github.com/symfony/symfony/pull/37494
  • phpspec/prophecy - https://github.com/phpspec/prophecy/pull/470
  • phpdocumentor/reflection-docblock - https://github.com/phpDocumentor/ReflectionDocBlock/pull/240
  • Symfony CMF #3176576: Update to Symfony CMF 2.3.3
  • #3127141: Use PHPUnit 9 for PHP 7.4+, while keeping support for PHPUnit 8.4 in PHP 7.3
• Within Drupal itself:
  • #3156944: Support nullable typehints and return types in ProxyBuilder and as a result support PHP 8
  • #3156878: \Drupal\Component\Datetime\DateTimePlus should pass correct parameter types to checkdate()
  • #3156885: Change \Drupal\error_test\Controller\ErrorTestController::generateWarnings() to throw E_NOTICE error compatible with PHP 8
  • #3156879: \Drupal\Component\Utility\Bytes::toInt() - ensure $size is a number type
  • #3156882: \Drupal\Core\Render\Element\StatusReport::preRenderGroupRequirements() and \Drupal\user\PermissionHandler::sortPermissions() sorts return bools
  • #3156883: \Drupal\Core\Url ensure fragment is not an empty string
  • #3170648: CKEditorPluginManager::getEnabledButtons throws warnings on PHP 8.0.0 beta3
  • #3173958: PHP 8 error: method_exists(): Argument #1 ($object_or_class) must be of type object|string, null given
  • #3173888: Error handler signature changed in PHP 8
  • #3174038: ZipArchive::open(): Using empty file as ZipArchive is deprecated in PHP 8
  • #3173991: Incorrect passby reference use in anonymous functions
  • #3174158: Division by zero is not warning since PHP 8.0 beta4
  • #3174022: call_user_func_array() and named arguments in PHP 8

Remaining tasks

See above.

User interface changes

None.

API changes

Data model changes

None.

Release notes snippet

Problem/Motivation

PHP has deprecated \ReflectionParamter::getClass(). We should replace our usages of it:

We use it in:

• ArgumentsResolver
• EntityResolverManager
• ProxyBuilder
• TaggedHandlersPass

Proposed resolution

Add helper to core/lib/Drupal/Component/Utility to handle this. Hopefully this approach will make it easier to backport to Drupal 8 and supporting PHP7 means that we need to still use getClass() there. It's not necessary at all in Drupal 9 since the reflection classes and methods we should use exist since PHP 7.2.

Remaining tasks

None

User interface changes

None

API changes

Calls to \ReflectionParameter::getClass() should be replaced with \Drupal\Component\Utility\Reflection::getParameterClassName($parameter);. Note that Reflection::getParameterClassName() returns the class name as a string and not a \ReflectionClass object.

Data model changes

None

Release notes snippet

In order to be PHP 8 compatible code that uses \ReflectionParameter::getClass() should use the new utility \Drupal\Component\Utility\Reflection::getParameterClassName() instead. See

What are the steps required to reproduce the bug?
1. Create or edit a node (I am using Basic Page type for this)
2. Insert an image using the CKEditor media widget. Select "center" as the alignment. The image appears centered in the Editor pane.
3. Preview the node - the image is now left aligned.
4. Save the node.
5. View the node. The image still appears as left aligned.

What behavior were you expecting?
* Expecting the the image will be centered when align = center is selected.

What happened instead?
* The image is left-aligned.

Additional info:
* Left and Right alignment options work. Only center does not.

Problem/Motivation

t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead

Fix classes:
core/modules/config/src/Form/ConfigSync.php
core/modules/field_ui/src/Form/EntityFormDisplayEditForm.php
core/modules/field_ui/src/Form/EntityViewDisplayEditForm.php
core/modules/image/src/Form/ImageStyleEditForm.php
core/modules/menu_ui/src/Form/MenuDeleteForm.php
core/modules/node/src/Form/NodeRevisionDeleteForm.php
core/modules/node/src/Form/NodeRevisionRevertForm.php
core/modules/node/src/Form/NodeRevisionRevertTranslationForm.php
core/modules/node/src/Form/RebuildPermissionsForm.php
core/modules/quickedit/src/Form/QuickEditFieldForm.php
core/modules/shortcut/src/Form/SetCustomize.php
core/modules/shortcut/src/Form/ShortcutSetDeleteForm.php
core/modules/system/src/Form/CronForm.php
core/modules/system/src/Form/DateFormatAddForm.php
core/modules/system/src/Form/DateFormatDeleteForm.php
core/modules/system/src/Form/DateFormatEditForm.php
core/modules/system/src/Form/DateFormatFormBase.php
core/modules/system/src/Form/FileSystemForm.php
core/modules/system/src/Form/LoggingForm.php
core/modules/system/src/Form/PerformanceForm.php
core/modules/system/src/Form/RegionalForm.php
core/modules/system/src/Form/RssFeedsForm.php
core/modules/system/src/Form/SiteInformationForm.php
core/modules/system/src/Form/SiteMaintenanceModeForm.php
core/modules/system/src/Form/SystemBrandingOffCanvasForm.php
core/modules/system/src/Form/ThemeSettingsForm.php
core/modules/views/src/Form/ViewsFormMainForm.php
core/modules/views_ui/src/Form/Ajax/EditDetails.php
core/modules/views_ui/src/Form/Ajax/Rearrange.php
core/modules/views_ui/src/Form/Ajax/RearrangeFilter.php
core/modules/views_ui/src/Form/BasicSettingsForm.php

Problem/Motivation

Subtask for #3167880: [meta] Convert assertions involving use of xpath to WebAssert, where possible, limited to a single module to be reviewable.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Subtask for #3167880: [meta] Convert assertions involving use of xpath to WebAssert, where possible, limited to a single module to be reviewable.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Subtask for #3167880: [meta] Convert assertions involving use of xpath to WebAssert, where possible, limited to a single module to be reviewable.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Subtask for #3167880: [meta] Convert assertions involving use of xpath to WebAssert, where possible, limited to a single module to be reviewable.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Subtask for #3167880: [meta] Convert assertions involving use of xpath to WebAssert, where possible, limited to a single module to be reviewable.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Subtask for #3167880: [meta] Convert assertions involving use of xpath to WebAssert, where possible, limited to a single module to be reviewable.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Subtask for #3167880: [meta] Convert assertions involving use of xpath to WebAssert, where possible, limited to a single module to be reviewable.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Subtask for #3167880: [meta] Convert assertions involving use of xpath to WebAssert, where possible, limited to a single module to be reviewable.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Subtask for #3167880: [meta] Convert assertions involving use of xpath to WebAssert, where possible, limited to a single module to be reviewable.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Subtask for #3167880: [meta] Convert assertions involving use of xpath to WebAssert, where possible, limited to a single module to be reviewable.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Subtask for #3167880: [meta] Convert assertions involving use of xpath to WebAssert, where possible, limited to two modules to be reviewable.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Subtask for #3167880: [meta] Convert assertions involving use of xpath to WebAssert, where possible, limited to a single module to be reviewable.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet