I've just created an issue in the queue for Noggin (#3118555: Offering to maintain Noggin) to offer to take over maintaining the module.
Normally, the procedure is to give the existing owner 2 weeks to respond, and then to create an issue here as well.
In this case, the module is marked unsupported for security reasons, so there is no current owner to wait for.
Clearly, this will need to wait for the Security Team to approve the patch I've supplied at #3098700: XSS Flaw. Once that's done, there's no sense in waiting 2 weeks for the module owner. So I'm opening this now, ready for when the module is to come back into security coverage.
Comments
Comment #2
avpadernoComment #3
gisleFYI: Not if the project has been declared unsupported for security reasons. There is a separate procedure for that, please see: https://www.drupal.org/node/251466#procedure---own-project---unsupported
But you're otherwise right: This will need to wait for the Security Team to approve the patch you've supplied. Normally the security team also re-assigns ownership when they're satisfied, put if required, we can do that. Postponing for now.
Comment #4
gisleAlso changing component, as the project has no real owner at present.
Comment #5
jamesoakleyThat doc page suggested that the specific procedures only applied if the security flaw was recent enough not to be in the public domain. Once it's been disclosed, the page suggests it's then treated more like a normal unsupported project.
Here's the bit that gave me that impression:
If I've misunderstood, perhaps that bit of the page needs rephrasing. Either way, this particular project now has a plan.
Comment #6
gisleI'm sorry. I didn't intend to criticize, but to clarify that the two weeks waiting period you mentioned is off the table in this case and that ownership transfer will happen ASAP after thumbs up from the security team.
I also agree that since greggles is on the ball in the issue queue, an email may not be required.
As for the "the module will follow the normal unsupported module policies". This is wrong, as there isn't a real owner to contact (the "normal" unsupported procedure assumes there is). Thank you for pointing out that it can be improved. I am replacing it with:
Comment #7
jshimota01 commentedSo let the guy become maintainer already - 2 weeks? 3 months?
Comment #8
gislejshimota01, thank you for the reminder.
There is a patch for the security flaw: #3098700: XSS Flaw that is still waiting for review and approval from the security team. It was created on March 9, so it has been sitting with a "Needs review" status nearly three months. I agree that this is excessive.
This security issue is handled in the open. It would probably help to speed up the process if the users of the project reviewed the patch and provided feedback about whether it resolves the issue or not. It is installed on more than 1500 sites according to the project page.
However, I'll try to contact the security team directly to find out what the situation is and what it is that is blocking this ownership transfer from moving forwards.
Comment #9
gisleI've sent the following email to security@drupal.org:
Comment #10
jamesoakleyThanks, @gisle
Comment #11
jshimota01 commentedbless you! with the test requirements of 8.9 ^ - I'm hopeful James rips this 'back to the future'.
Comment #12
rdellis87 commentedCan we get the status changed from Postponed back to active and get some movement on this?
Comment #13
jamesoakleyIt's only postponed because the related issue needs fixing first.
If you want to get his moving, why not head over to #3098700: XSS Flaw and review the patch to confirm it solves the security issue. Full instructions as to what to test are provided in my last post in that issue thread.
Comment #14
gisleLooks like that this was fixed back in January 2021 - see related issue: #3098700: XSS Flaw