🇺🇸United States @greggles

I want to say this is technically valid to a single term, and that have seen other modules do similar on my own reports and other cases where the DST has admitted a module owner failed to adhere to policies.

I don't want to get into the specifics. I will say, it was not a single action or single violation of one term in the terms and conditions that resulted in removing this user's ability to opt projects into security coverage. Mistakes happen and we certainly wouldn't take this drastic of an action for a person who makes one mistake.

#21 is right that we can change the policy. 2 areas that seem most up for discussion in my mind:

* if folks feel a CVE should be issued for each separate issue we can do that. Submit proposed cve json to the securitydrupalorg queue and we can do that.
* I think it's reasonable to issue a PSA for modules getting opted out (the help text on the radios says it may happen). Should it happen even for modules with zero users? Or 10? 50?

greggles → created an issue.

The documentation on making an issue public → includes advice to remove significant amounts of information. I do not think it would benefit you, nor the general public interest, to publish all the content in the issues.

There's now a situation where this has happened. It was not a fast or easy decision to make. Several members of the security team expressed concern that this individual was not following the process. Ultimately Michael Hess and I made this decision as the 2 members of the Security Working Group, taking into perspective the feedback from members of the Security Team.

The modules affected do not have many users - it's possible (even likely) that all the users are development or test sites of the author.

There is a template of an email to send to the maintainer https://www.drupal.org/drupal-security-team/security-team-procedures/sec... →

Their access to opt future projects into Security Coverage was revoked.

Their projects that were opted into Security Coverage were all changed to "Not covered."

An advisory was issued for the one module where there is a reported security vulnerability https://www.drupal.org/sa-contrib-2025-057 →

The other projects did not get an advisory.

The private issues were closed as "can be public" and the reporter and maintainer have the option to copy them to the public.

A big area I'm not sure about is if we should issue a CVE for any privately reported issues while the project was covered. I think it could be appropriate to issue a CVE.

I hope we never have to do this again. If we do, this provides a starting point for what the process should look like.

we decided the process should be based on an email

I've added all the CWE/CAPEC for May 7th and published the associated CVEs. The script is now in the repo and we can iterate from there.

Marking this issue as fixed :tada:

greggles → credited greggles → .

greggles → credited greggles → .

greggles → credited greggles → .

greggles → credited greggles → .

greggles → credited greggles → .

Thanks for the issue and patch.

What are the conditions that cause this error to happen? Is it on every page load, every page with a comment form, on the settings form?

This module has some automated tests that will run if changes are provided as merge requests instead of patches. Can you provide this as a merge request as well?

better title

greggles → created an issue.

greggles → credited greggles → .

greggles → credited greggles → .

greggles → credited greggles → .

greggles → credited greggles → .

greggles → credited greggles → .

greggles → credited greggles → .

poker10 → credited greggles → .

greggles → credited greggles → .

benjifisher → credited greggles → .

I had this same question. Retitling to be about improvement to the project page (and README, which seems to be missing). I added some more information to the issue summary that could potentially be added to the project page.

greggles → credited greggles → .

greggles → credited greggles → .

greggles → credited greggles → .

poker10 → credited greggles → .

+1 on the concept.

#3 makes a ton of sense to me. That would let sites do TFA codes as well if appropriate.

poker10 → credited greggles → .

Adding the 3 new provisional members to the team.

updating for new google doc and adding a list of steps of what to do after sending the mail

poker10 → credited greggles → .

poker10 → credited greggles → .

Maybe like this?

I agree this is an improvement to the description. I think that was made many years ago and never revisited.

Committed and pushed. Cheers, all!

greggles → credited greggles → .

poker10 → credited greggles → .

greggles → credited greggles → .

poker10 → credited greggles → .

Thanks for the thorough report! I fixed the link just now.

Removing outdated beta phase copy and making it clear in the issue summary which issue is making this postponed.

greggles → credited greggles → .

greggles → credited greggles → .

greggles → credited greggles → .

I see! I think I got confused by the title and then not reading enough of the issue summary to understand it. Sorry about that.

It seems the first one was already fixed. The second one I think is valuable showing both closed and open - closed might help people find things they've done while open can help them do more. So I added a sentence and linked to just open as well.

The third already had a link to open right before and then was giving advice about using tags as the link with the issue count. So, I think that makes sense to stay as is.

Seem good? Fixed?

Thanks for that research and advice. I'll have to read it and consider and encourage others to as well.

Sorry if my update was confusing.

The title is currently:

Unsuported Modules: Establish timeline for publishing of vulnerability info to allow for possible CVE creation

But I think it should be:

Unsuported Modules: Establish timeline for publishing of vulnerability info

The motivation to release the information should be separated from publishing CVEs. Then the issue summary needs a pretty significant rewrite to explain the value and motivation for publishing the information.

Alternately, this could be closed as "won't fix" or maybe "outdated" since the information is not required for CVEs.

@bigbabert The documentation I removed referred to a process that was followed infrequently for a few years in 2010. Since probably 2013 we have not followed that process. The term still exists and will get used (as far as I know, the mechanism may change with the ongoing maintenance and upgrades of drupal.org. The advisories will still be used and get published following all the policies explained elsewhere on the page. That section of explanation was important before as context for the idea that the term might be used without advisories. Since that hasn't happened in many years it seems important to update the documentation to match practice and current policy. Happy to talk more e.g. in slack if this is not clear. Some real-time communication may be better suited to the ideas than comments on a discussion node. We could summarize any results of the conversation here for posterity.

Removing an idea that was added in 2010, but has not been the practice of the team for at least a decade.

I was mistaken. On further research, it's possible to create CVEs without specifying the CWE/CAPEC/risk score, so the title and some of the description could be updated to reflect that. It may be desirable for some to know that information.

After gathering opinions from a few places, I think this could be marked as "won't fix."

This is no longer relevant.

No longer relevant.

I think this is outdated given the new gitlab flow, so marking closed.

I think we've documented this and haven't had to use it as far as I remember.

It seems this is likely out of date now. I'm not sure if anything similar is still needed. If so, hoping someone following this can help explain.

The node body for https://www.drupal.org/drupal-security-team/general-information → looks like this:

	<li>Help out in the <a href="https://www.drupal.org/project/issues/search/drupal?project_issue_followers=&amp;status%5B%5D=Open&amp;issue_tags_op=%3D&amp;issue_tags=Security+improvements">public issue queue.</a></li>

There must be a text format filter that is doing the count?

On https://www.drupal.org/drupal-security-team/how-to-join-the-drupal-secur... → the node body for a similar example includes:

	<li>Any relevant experience you have working on security issues. This should include at least 5 issues you have worked on that are <a href="https://www.drupal.org/project/issues/search/drupal?text=&amp;assigned=&amp;submitted=&amp;project_issue_followers=&amp;issue_tags_op=%3D&amp;issue_tags=Security+improvements">public security improvements</a> in core.</li>

So, yeah, I think this is a bug in some custom code on drupalorg and not in the docs pages.

greggles → created an issue.

It seems this was done on the old list and the new list is already unordered.

It seems there was some good research into the idea so making the title about that and marking as "fixed".

This issue seems no longer relevant with the site upgrade.

No longer relevant with the site upgrade.

With the migration to gitlab we won't be able to have blocks.

It seems like some work was done here that made things better so I will mark this as fixed.

Thanks for double checking those values. Digging into that issue again I see you had suggested

CWE-288: Authentication Bypass Using an Alternate Path or Channel
CAPEC-115: Authentication Bypass

I've now fixed the CVE to point to those.

I think many of these things are fixed with the current prototype gitlab workflow.

That list is gone.

Is this still relevant?

I think most folks get this information from composer now.

If it is relevant, the public API for advisories means that anyone could work on this without any special access to d.o.

That list is gone.

This is outdated with the move to gitlab.

The text here was updated to explain:

Write an advisory using the link at the top of this sidebar

With the move to gitlab this will not be as important/possible.

People seem to be handling this pretty OK without an email going out so I propose we consider this as no longer relevant.

I think some good improvements were made and we can consider this fixed.

This will no longer be needed with the new gitlab workflow.

I feel like the initial motivation for this concept has fallen away.

The most sustainable thing at this point is that maintainers of distributions (or recipes) that are successful should become co-maintainer of the modules in their distribution/recipe.

This is either a duplicate of #1034856: Request accounts when referenced → or outdated given the move to other infrastructure.

This now works via private merge requests on gitlab.

Now fixed.

I updated the one.

There are many advisories from the past that are missing a CVE, but that feels beyond the scope of this issue, so adjusting the issue summary and marking as fixed.

OK. Now filed and I've updated the advisories to include the CVE. I acknowledge I may have made misclassifications or mistakes in this process and welcome comments or new issues alerting me to where those might be so I can address them.

Here's the pairing of CVE and advisory id:

CVE-2025-3057 https://www.drupal.org/SA-CORE-2025-001 →
CVE-2025-31673 https://www.drupal.org/SA-CORE-2025-002 →
CVE-2025-31674 https://www.drupal.org/SA-CORE-2025-003 →
CVE-2025-31675 https://www.drupal.org/SA-CORE-2025-004 →
CVE-2025-31676 https://www.drupal.org/SA-CONTRIB-2025-001 →
CVE-2025-31677 https://www.drupal.org/SA-CONTRIB-2025-003 →
CVE-2025-31678 https://www.drupal.org/SA-CONTRIB-2025-004 →
CVE-2025-31679 https://www.drupal.org/SA-CONTRIB-2025-007 →
CVE-2025-31680 https://www.drupal.org/SA-CONTRIB-2025-008 →
CVE-2025-31681 https://www.drupal.org/SA-CONTRIB-2025-009 →
CVE-2025-31682 https://www.drupal.org/SA-CONTRIB-2025-011 →
CVE-2025-31683 https://www.drupal.org/SA-CONTRIB-2025-012 →
CVE-2025-31684 https://www.drupal.org/SA-CONTRIB-2025-013 →
CVE-2025-31685 https://www.drupal.org/SA-CONTRIB-2025-014 →
CVE-2025-31686 https://www.drupal.org/SA-CONTRIB-2025-015 →
CVE-2025-31687 https://www.drupal.org/SA-CONTRIB-2025-016 →
CVE-2025-31688 https://www.drupal.org/SA-CONTRIB-2025-017 →
CVE-2025-31689 https://www.drupal.org/SA-CONTRIB-2025-018 →
CVE-2025-31690 https://www.drupal.org/SA-CONTRIB-2025-019 →
CVE-2025-31691 https://www.drupal.org/SA-CONTRIB-2025-020 →
CVE-2025-31692 https://www.drupal.org/SA-CONTRIB-2025-021 →
CVE-2025-31693 https://www.drupal.org/SA-CONTRIB-2025-022 →
CVE-2025-31694 https://www.drupal.org/SA-CONTRIB-2025-023 →
CVE-2025-31695 https://www.drupal.org/SA-CONTRIB-2025-024 →
CVE-2025-31696 https://www.drupal.org/SA-CONTRIB-2025-025 →
CVE-2025-31697 https://www.drupal.org/SA-CONTRIB-2025-026 →
CVE-2025-3059 https://www.drupal.org/SA-CONTRIB-2025-002 →
CVE-2025-3060 https://www.drupal.org/SA-CONTRIB-2025-005 →
CVE-2025-3061 https://www.drupal.org/SA-CONTRIB-2025-006 →
CVE-2025-3062 https://www.drupal.org/SA-CONTRIB-2025-010 →

fix typo in 021

re #5 I agree that capec makes sense. Thanks!

making progress on categorizing more of them

There is now a version of the upstream library that fixes this, so core should be adjusted to rely on that

https://github.com/asm89/stack-cors/releases/tag/v2.3.0

I fixed it on https://www.drupal.org/node/28984 →

@avpaderno I think documenting in multiple places is fine, so you could open another issue for the change you're proposing.

Fixing https://www.drupal.org/project/documentation/issues/2450101 📌 Document that filter_xss() must never be used in an attribute context Postponed: needs info

Unfortunately web.archive.org doesn't have that page indexed :sob:

I tried to rewrite the issue summary based on what I *think* that article said.

My copy is probably close to what needs to be added to the pages, so...needs review?

there are no known problems in this page

greggles → created an issue.

Thanks, everyone, for your help.

greggles → created an issue. See original summary → .

I tested the color contrast and it seems to pass WCAG AA at least, if not more.

FWIW, I feel like the grey is a decent color choice for the new brand. We can try this for a while and see how it goes, if there is confusion about it. The old yellow relies on cultural connotations that are broad, but not universal. The icon is the key element people should focus on for security and I think it works well here.

@nanaoye - I guess there's a way to extend the feeds importer in this User Expire module to provide support for that scenario. I suggest opening a new issue in this queue about that topic. Personally I likely won't have time to do that work, however a new issue is where a merge request could go to help add the functionality.

Seems good to add the "why" - it's about extra security through defense in depth

Agreed with #87. All of the concept was committed to 8.x. Some of it was fixed in 7.x (in #58).

So marking this as fixed with a version of 8.4.x.

removing twitter which no longer gets an active feed and adding bluesky and mastodon which do get active feeds.