#Security

I'm uploading a new patch, this is compatible with drupal 11.2.0-rc2

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Yes, that's a great point in favor of continuing with the commit.

In fact, an attacker could look at the code of security_review on drupal.org for ideas of things to check even if the module is not installed.

I think it is true for most of the checks, but some checks could reveal information that would not be available (or hard to acquire) without this module.
For example TemporaryFiles provides a list of sensitive files that could be downloaded. Without this information it could be possible to brute force the file name but if the file name is unusual it would be much harder.

It seems security_review has a similar check: https://git.drupalcode.org/project/security_review/-/blob/3.1.x/src/Plug...
Based on a list of unsafe tags: https://git.drupalcode.org/project/security_review/-/blob/87d5f3ea84b0be...

I will add my take: this doesn't feel exactly right to me from the perspective of Drupal's philosophy of restrict access. An attacker with access to a site that has a vulnerable configuration can already exploit it, regardless of the security_review report access. In fact, an attacker could look at the code of security_review on drupal.org for ideas of things to check even if the module is not installed. Restricting this access does make it less likely an attacker will find vulnerabilities and there are enough people who think this makes sense that I'm OK with the idea.

LGTM. Thanks.

I merged some changes from other tickets and went back trying that and I finally got it to generate styles. Not sure why it started working (also updated local to 10.5). I do see it generate a smaller image that is not encrypted.

Following up again if this should be re-open. If no reason to in D11 then will close in 3 months.

I think this is the best approach - a user can remove the permission from any roles they don't want after update and the permission does not affect whether user get's access to edit an entity so nothing is changed for existing sites.

We need to address this prior to any stable release so raising this to critical.

Note that other authentication methods (basic auth for example) could also be vulnerable but it might be impossible to support every authentication provider.
The module could display a warning when a method it does not support is enabled. Something similar to this: https://git.drupalcode.org/project/one_time_password/-/blob/37a3c61bc1ab...

Retitling because I keep forgetting what this is.

Amending attribution.