🇺🇸United States @greggles

greggles → credited greggles → .

I think this is a duplicate of https://www.drupal.org/project/drupalorg/issues/3540656 🐛 "My dashboard" and "Projects by [username]" show as updated posts where the last comment was added by me Active

I see it as well.

I believe this is in place today (the specifics might be slightly different, but the concept is done) so moving to fixed.

Thanks for the idea!

greggles → created an issue.

greggles → created an issue.

greggles → created an issue.

greggles → created an issue.

Drumm pointed out it would be nice to only have one kind of data in the field.

Can we automatically migrate old Drupal scores to CVSS in some way? Anyone interested in this feature could work on that and it would be very helpful.

greggles → credited greggles → .

poker10 → credited greggles → .

mcdruid → credited greggles → .

One nice thing about broader standards is there's plenty of docs we don't have to write, e.g. https://www.first.org/cvss/v4-0/user-guide

The administer views permission definition includes restrict access: true. Our documented expectation is that people who have that are trusted with making potentially risky choices.

I can see how:

• this would be a useful feature
• this should be safe in most cases
• this could lead to XSS in some cases

What permission is allowed to set the "Allow any HTML" checkbox?

I agree it should have a warning on it as you point out in #5.

@berdir - Thanks for your thoughts. I think I agree, but I want to clarify your first sentence:

I'd even argue this case should preferably not be logged as an error at all and only use the same consistent logging as the UI.

Do I understand you right as saying:

The invalid login to the JSON endpoint should not log the error from #4 and should instead log the same message(s) as happens from a login failure on the traditional /user login form.

Your explanation matches my experience as well.

I do think it's valuable for a blue team to have a consistent message for authentication failures to more accurately diagnose a brute force or similar attacks.

Now posted as CVEs and the MR merged.

There was a lot of whitespace to cleanup. Hopefully that's done now, and future MRs will not have as many whitespace changes.

Reviews welcome. 096 is a big deal for the relatively small number of sites running that module, so I'd like to publish these soonish.

greggles → credited greggles → .

yesct → credited greggles → .

greggles → credited greggles → .

+1 from me on the proposal. Reviewing a few of these they look like oversights/mistakes.

I think there's 2 things to do here:

1. Fix the advisories
2. Add some validation in the code related to advisory content types to prevent use of >

This is all amazing, thanks so much for your help!

I think the governance topic might best be resolved as a conversation where we can have high-bandwidth explanations/questions/answers. I'll reach out on that now.

ted bow has resigned from the process due to other commitments

dstol is now a former member

xjm → credited greggles → .

greggles → created an issue.

mandclu
katannshaw
and I

worked on a few things at the same table :)

greggles → created an issue.

greggles → credited greggles → .

greggles → credited greggles → .

Thanks for this research, @g-rath and @tenguiz.

Abbreviations can be handy sometimes, but it feels like DRUPAL is a fine value to use for the id (that's what you meant, I think tnenguiz?).

And the proposal for the ecosystem to be Drupal or Drupal:7 feels very straightforward and short enough.

I don't see any drawbacks to these. Anyone else?

Now filed and merged.

Thanks for that research, cmlara!

I've read the CVE rules a bit more.

I think Drupal could issue a CVE since the code owner has not responded on the issue I created in #8 and since this code is also distributed from drupal.org (putting it in our scope as a CNA).

I also think @aangel could go to a CNA-LR to get a CVE for this.

I don't have a strong feeling of which one is the right action.

As one of a very small number of volunteers handling a lot of CVE topics, I rely on feedback from a variety of sources to help.

I see the Drupal module shipped with what seems to be the 1.4.7 version of the multifile code. I can't find the reference copy of that file online in Google Code repositories. Is anyone able to find a reference copy so we can compare it?

closing open tags. adding reference back to a private issue that reported this.

greggles → created an issue.

xjm → credited greggles → .

damienmckenna → credited greggles → .

greggles → credited greggles → .

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.

xjm → credited greggles → .

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.

more specific advice

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 → .