greggles → created an issue.
greggles → credited greggles → .
greggles → credited greggles → .
Now filed and merged into the repository.
If these are inaccurate the issue can be reopened or a new issue can be created to fix them.
For purposes of this discussion I suggest we focus on 2024 and newer CVEs. If folks want to fix up old CVEs we can certainly do that, but it would be solved in different ways. CVEs created for years prior to 2024 were created completely manually. Those for 2024 and later used a script and manual submission.
That's great news about Dependency Track! The expanded issue summary talks about the subject more generically, so I think we're good.
I added some changes to the issue summary based on a recent slack thread.
@dmundra is Dependency Track picking up contribs and core CVEs? I believe that osvscanner isn't. So it seems we need to reopen this issue.
It's been 2 weeks since that was posted. Is there a timeline before the next action? What is the appropriate next action?
@aangel can you help answer these questions?
What is the interpretation of hosted? Is it being the official development platform, or is redistributing also hosting?
How integrated is the code in the Drupal module (is it line for line, or is it a fork that deviated some time in the past and could legitimately called its own project)?
Is there another CNA with better scope?
For the TFA advisory, I think:
* CWE https://cwe.mitre.org/data/definitions/267.html CWE-267: Privilege Defined With Unsafe Actions
* CAPEC https://capec.mitre.org/data/definitions/180.html CAPEC-180: Exploiting Incorrectly Configured Access Control Security Levels
This "Needs work" for the missing TFA categories which I believe can happen in a day or two.
greggles → created an issue.
greggles → credited greggles → .
@paolomainardi thanks for the update. I'm not a user of the module at this point, so probably shouldn't help with maintenance, but I'll let you know if that changes.
I posted the CVEs and have merged these additions.
I think for these CVE issues, we may merge without public review/faster than normal so the information can be published in a timely manner. We can always update the CVE content if there's feedback that requires a change.
I think these are good to go, but would appreciate any reviews.
greggles → created an issue.
There were no security releases this day so no CVEs.
greggles → credited greggles → .
greggles → credited greggles → .
greggles → credited greggles → .
poker10 → credited greggles → .
greggles → credited greggles → .
greggles → credited greggles → .
greggles → credited greggles → .
greggles → credited greggles → .
OK. I posted https://github.com/fyneworks/multifile/issues/113
Leaving this at "needs review" for feedback on the CVE content although probably "postponed" would be appropriate since we're waiting here on action in that Github project before taking action here.
greggles → created an issue.
Thanks, fen. Drupal is now using gitlab CI so if you have ideas on configuring gitlab to do that scan that would be great.
Updating the issue summary for the new URL and to list out the items we haven't yet answered as "meets" or "N/A"
I'm at Open Source Software North America conference and will try to connect with some folks who work on OpenSSF to get advice on these.
Yes, that's a great point in favor of continuing with the commit.
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.
It seems like this might be fixed by 📌 Always rename dot files like Drupal 7 Needs work .
Thanks, yesct! This is a nice improvement in addition to filing the CVEs.
Since there were no advisories we don't need to issue any CVEs this day.
Thanks for this work and for documenting your process.
The CWE and CAPEC assignments look good to me. I reviewed the code changes as well and they look good to me. Moving to RTBC.
Let's coordinate to get these filed.
@cmlara thanks for that question and pasting the documentation. Are you interested in contacting the upstream maintainer there?
Or is anyone else interested in doing that? Since the forked code was/is distributed from drupal.org it seems we could issue a CVE if the upstream maintainer is not interested in doing that.
benjifisher → credited greggles → .
Actually marking it fixed after #12.
I spot checked these and they look good to me. Thanks, yesct and pwolanin!
Clarify that we will also issue CVEs for modules with fewer than 10,000 installs on a reasonable effort basis.
catch → credited greggles → .
The drupalsecurity handle consistently links to pages on d.o and we can see this problem going back for a few months there https://bsky.app/profile/drupalsecurity.bsky.social
I believe this is right.
smustgrave → credited greggles → .
benjifisher → credited greggles → .
yesct → credited greggles → .
poker10 → credited greggles → .
yesct → 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?