smustgrave → credited greggles → .
benjifisher → credited greggles → .
Thanks aangel. Moving status. And let's give this a few days for review.
Generally + 1.
The flow for last year was advisory published -> CVE added months later. The flow for this year has shifted so that we now add the CVE prior to publishing, but in the last ~30 minutes before publishing. We could try reserving the CVEs even earlier and assigning them ~a day ahead? For contributed projects, we don't always know which are going out until closer to the release window so there will still be some last minute assigning.
greggles → credited greggles → .
yesct helped me work on this.
greggles → credited greggles → .
poker10 → credited greggles → .
poker10 → credited greggles → .
greggles → credited greggles → .
greggles → credited greggles → .
greggles → created an issue.
From comment 44:
Per above one could contend that the Drupal Security Team has granted permission for full disclosure to the Owners and Reporters.
I wrote the sentence in comment #14 you're referring to while considering the process for publishing private issues. I later linked to that process from comment #16. Those comments were about half an hour apart. There was a moment of ambiguity about what kind of copying the reporter and maintainer could do, but it's no longer ambiguous.
Comments here lack work toward crafting a policy. I shared the details in comment #14 as a good faith attempt to help inform a policy. They do not name or cast judgment or expose private information.
People in the Drupal project regularly have to make decisions without policies, especially for infrequent events. We have a governance model for choosing people to make decisions. I don't know if more policies are needed to cover this scenario. Still, if someone does want more policies to cover this case, I believe that spending time writing a draft policy is a more effective way to get one.
It's possible to make a header request that consumes significantly less bandwidth if someone were spidering for Drupal sites at scale. That said, since it's not standard this is not a reliable way to determine Drupal vs other systems.
benjifisher → credited greggles → .
benjifisher → credited 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=&status%5B%5D=Open&issue_tags_op=%3D&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=&assigned=&submitted=&project_issue_followers=&issue_tags_op=%3D&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.