Note: there are still over 5500 installs of this module. Not insignificant user base. I require this module for my own corporate needs and took the time to review its current state.
This module was abandoned and no one stepped up to the plate to take ownership of it. For this reason I am asking that you wave the normal 2 week waiting period.
My plan is to release a fixed version of this module with the following patches:
Here are the patches ready to commit:
- https://www.drupal.org/files/issues/0001-Fixes-book_access_default_role-issue_0.patch
- https://www.drupal.org/project/book_access/issues/2355963
- https://www.drupal.org/files/issues/book_access-limit-anon-author-grants-2440385-7.patch
- https://www.drupal.org/files/issues/empty_entry_for_roles_without_grant.patch
- https://www.drupal.org/project/book_access/issues/2402491
- https://www.drupal.org/files/issues/book_access-limit-unpub-node-access--2123165-5.patch
Note, for one of those I had to use the -p0 flag instead of the -p1 flag (if you use the patch utility, patch might apply with git as well)
either way, the patches applied cleanly for me.
extensive tests I ran showed that the issues are resolved.
Thanks.
Transfer of ownership needs to follow: https://www.drupal.org/node/251466#procedure---own-project---unsupported
Checklist
- Link to project: Book access
- Abandoned: Yes.
- Link to original request: https://www.drupal.org/project/book_access/issues/3081324
- Engagement: https://www.drupal.org/project/book_access/issues/2869160
- Permission to opt into security coverage: Yes
- Access to issue on Drupal security team subsite: Yes
- RTBC from a member of the the security team: Yes
Comments
Comment #2
joseph.olstadComment #3
joseph.olstadComment #4
gisleThe project is marked as abandoned and owned by "Unsupported Projects", so there will be no two week waiting period.
However, to transfer this, we need to follow: https://www.drupal.org/node/251466#procedure---own-project---unsupported
There are some outstanding questions:
Also, before we can transfer ownership, a member of the the security team must confirm that the proposed patches fixes the security issue.
Setting to postponed until those things are sorted out.
Comment #5
joseph.olstadYes I already have permission to opt into security coverage.
The security issue was made public afaik. The problem was the maintainer was nowhere to be seen and no one stepped up to take ownership.
All that needs to happen is to create a security advisory for the upgrade and push a release with the fixes that have been ready for quite some timenow.
Comment #6
gisleCan you point me to the public disclosure of the security issue by the security team. The issue summary of #2869160: Security fix? says:
Comment #7
apadernoComment #8
apadernoComment #9
gisleNot that the "Component" matter that much, but for the record; "Abandoned/unsupported projects" is to be used to indicate that the goal it to get something where the Maintenance status suggest that it is maintained changed into "Unsupported" without becoming the maintainer - please see https://www.drupal.org/node/251466#procedure---report-without-owner
In this case the project is already marked as "Unsupported", and the goal is "Ownership transfer" - so that should be the component.
Comment #10
apadernoAbandoned/unsupported projects should be used for projects that are effectively marked as unsupported or abandoned, not for projects I think unsupported or abandoned.
Its purpose is making clear there isn't a project owner to contact, or that the project owner doesn't intend to continue the development of the project. In those case, I could assume that getting the ownership of the project should be quicker.
Comment #11
gisleAFAIK, this is not documented anywhere. And, as already noted, it is contradicted by the official documentation. But if you think this is how it "should" be - at least update the documentation to match your thoughts.
The official documentation in practice says that the "Component" metatag is used to identify the goal of task and not the current status. That not only goes for this component, but for all of them. I don't think it is a good idea to keep flipping the "Component" metadata as status changes.
As for current status of the project (including making clear there isn't a project owner to contact), that usually goes into the issue summary, that already clearly says:
Duplicating this information in the "Component" metatag is redundant.
When working on issues, it is customary to update the issue summary with the latest status as the task makes progress. I don't why this particular community project should diverge from that standard.
We are several people working to resolve these issues together. If each and every one makes up his or her mind about the use of metadata, misunderstandings will occur.
PS: And given your thinking about this, what is correct component to use when requesting a project being marked as "Unsupported" because the current owner is no longer around, and one just want to alert other community members about that particular situation without becoming the new owner?
Comment #12
joseph.olstadDue to the public nature of the vulnerability, it is widely known already, there is no need to delay creating a release with the fixes.
so as soon as I get access I will publish a release with the fixes shortly afterwards.
Comment #13
gislePlease understand that I will give you access only after someone from the security team shows up and moves this issue to RTBC.
As far as I am concerned, not having the security team in the loop is blocking this from moving forwards.
Comment #14
joseph.olstadOk I will report a new issue with the security team.
Comment #15
joseph.olstadI have written to the security team.
Comment #16
joseph.olstadIt would be best if I was granted access now, this will facilitate coordination with the security team.
Comment #17
gisleThank you.
I am not sure if it is necessary to co-ordinate a full release with the security team.
I just wanted a second opinion from a member of the security team whether #2869160: Security fix? really fixes all vulnerabilities before giving you access that will let you remove the project's security warning.
Comment #18
mlhess CreditAttribution: mlhess commentedThe security team is working with joseph.olstad on this release. I have made him a maintainer of the module.
Comment #19
gisleUpdated summary.
Comment #20
apadernoThe documentation doesn't give a definition of unsupported nor abandoned and it was written when the projects didn't have any Maintenance status (which incluses Unsupported) nor Development status field.
In this case, it's clear the project was unsupported because security issues, and that should be evident in the issue; that is the reason the Component field has the value used for this issue. Differently, we would have just values for users who want to become maintainers, users who wants to become co-maintainers, project owners who are looking for a new maintainer, and project owners who are looking for new co-maintainers.