🇺🇸United States @greggles

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.

Looks like this is fixed. Thanks.

poker10 → credited greggles → .

poker10 → credited greggles → .

poker10 → credited greggles → .

greggles → created an issue.

Those seem good to me - done.

Yes, that's right.

i.e. no special treatment other than highlighting to a Drupal CMS site that they need to do an update ( in addition to whatever other notifications they might see).

If there's no change, then this might also need to be documented - e.g. security support is unchanged regardless of how the module gets installed.

I guess we've gone that route. Which I think is OK.

There was some special treatment for the AI (Artificial Intelligence) security releases → to say:

The AI module is included in Drupal CMS.

As I'm reading that now, I guess we could link that to Drupal CMS to explain what it is?

Look at that :)

Can you file an issue for it? I'm not a maintainer so can't grant it. I just happened across this issue.

Are you interested in becoming a maintainer? There are a few issues in the queue that are not resolved in months. I think it would be good to get an active maintainer prior to opting in to the security advisory policy.

Help in slack pointed me to the Settings > Confirmation > Confirmation type which then has a message letting me know that only certain confirmation types are supported by Ajax.

adding the tag

We missed this tag.

Oops, missing a tag

greggles → created an issue.

greggles → created an issue.

greggles → credited greggles → .

For actively developed projects, periodic releases make sense to me. They encourage testing and help with the QA process, as they allow for a named version to be tested.

I agree it's ideal to coordinate releases in the queue at least a few days prior to doing them so that any maintainer watching the queue can help discuss.

Thanks for the ideas on what the message should say. I've updated the project page to be more accurate about the current situation and include a link to that roadmap. Feel free to edit further, of course.

adding david rothstein who resigned

small cleanups

updating link to new home

The project page says "Warning: Releases 2.0.0-alpha2 and before have known vulnerabilities and should not be installed, use only latest development builds." but it seems like this vulnerability is still present in 2.x, right?

If fixing this will take a while then I guess the project page should be updated and maybe link here.

Thanks for those observations, cmlara.

I didn't realize the age of this issue vs. some of the releases/commits. I think the conclusion from #12 is still reasonable :)

@cmlara have you reviewed what's auditing logs are gitlab's codebase for events like this? That seems like a useful area of research.

We can look at commits (as recently as a week ago and as early as years ago) https://git.drupalcode.org/project/commerce_purchase_order/-/commits/2.1.x

and at releases, again as recently as this month https://www.drupal.org/project/commerce_purchase_order/releases/2.1.0 → and as early as years ago https://www.drupal.org/project/commerce_purchase_order/releases/8.x-1.0 →

and see that fathershawn had the access described in the issue summary.

Thanks for your work on this module, fathershawn.

greggles → credited greggles → .

greggles → credited greggles → .

greggles → credited greggles → .

This help message is not helpful. It's just copy paste from the project page, which people will already know.

Marking wont' fix.

Thanks for reporting this issue and suggesting a workaround.

I assume it still affects the latest version of 8.x-1.x so updating the version to that. If it's been fixed since please leave a comment about that.

Seems like a simple enough change. I turned the patch into an MR, but credit to mattjones86.

I confirmed that --preserve-perms is a valid option.

greggles → made their first commit to this issue’s fork.

It seems ideal to fix #2992359: Use the symfony process component → before working on any more binaries. Additional binaries should ideally be written using the symfony process compontent. Marking this as postponed on that.

That sounds like not all of the files were present on the site.

Can you try replicating this issue on a brand new "test" site and see if the issue is present there?

It seems ideal to fix #2992359: Use the symfony process component → before working on any more binaries. Additional binaries should ideally be written using the symfony process compontent. Marking this as postponed on that.

I read on the project page

libjpeg-turbo implements both the traditional libjpeg API as well as the less powerful but more straightforward TurboJPEG API.

(emphasis mine)

I think the advice from the earlier comment to point this library at the libjepg-turbo binary should work, so marking this as "fixed."

I'm +1 to enabling phpcs in GitLab as the MR does. The code sniff identified many adjustments, so it might not be practical to fix them all in this issue. I've sometimes used the practice of merging the enabling the codesniffer with known problems and then fixing them slowly over time.

I imagine by now that you have an answer to the question. Without trying it myself and relying on some outdated memories - As I understand it, the default 75% only affects a pipeline if you have a step that will resample the file before sending it to resmushit. I guess it does not affect a typical pipeline that just sends to resmushit.

As a support request I guess this is "fixed".

Updating version to a supported branch. I think the "Needs work" status is still accurate.