Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Offering to maintain pubdlcnt. The attached patch should fix SA-CONTRIB-2015-036 (https://www.drupal.org/node/2420119) and silences warnings from PHP7 about deprecated PCRE extensions. The patch also clarifies that all files in the pubdlcnt module are licensed under the GPL. This was confirmed via private email with Hideki Ito on 22 Aug 2016.
| Comment | File | Size | Author |
|---|---|---|---|
| pubdlcnt.patch | 5.06 KB | chalpin |
Comments
Comment #2
chalpin CreditAttribution: chalpin as a volunteer commentedComment #3
dddave CreditAttribution: dddave commentedI've added you as co-maintainer so that you can commit the patch. However before full transferal (which would also remove the ugly warning on the project page) this patch needs to be signed of by the security team.
Comment #4
dddave CreditAttribution: dddave commentedhttps://www.drupal.org/project/pubdlcnt
Comment #5
gregglesThe patch fixes the security issue, but not in a typical "Drupal" way. From the private security issue a suggestion was "Use l() function instead of concatenating
<a>tags. Or use check_plain()."Looking more broadly, these changes are not appropriate http://cgit.drupalcode.org/pubdlcnt/commit/?id=04b8ea7 The license of the code is specified in a LICENSE.txt that is added by the drupal.org packaging script and specifies 2.0 or later.
I suggest going through the project application process (perhaps with a round of fixups of the module to match Drupal code standards). One item to be aware of through that process is to use commit messages that reference an issue number in the module queue.
Comment #6
chalpin CreditAttribution: chalpin as a volunteer commentedThank you for your feedback!
I've removed the problematic lines mentioned the GPL-2. I had put those in because I didn't see any explicit licensing info in the git repo, and found "All rights reserved" to be quite offputting and likely inaccurate given the Drupal policy for how modules should be licensed. I was not aware of how the LICENCE.txt procedure works, thank you for explaining it to me.
I've also replaced the concatenation of tags with use of the l() function as you suggest.
And I created a Project Application for pubdlcnt here: https://www.drupal.org/node/2806727
Comment #7
th_tushar CreditAttribution: th_tushar as a volunteer commentedClosing this issue as it is inactive since long. Please feel free to reopen if required.
Comment #8
chalpin CreditAttribution: chalpin as a volunteer commentedIt seems that the 'Project Application' process has stalled at https://www.drupal.org/project/projectapplications/issues/2806727. But, it also seems that the whole procedure for new project applications has been revamped since I started it.
Is what I have currently good enough that the full ownership transfer could be performed so that I could remove the ugly warning on the project page? While it would be ideal if pubdlcnt could be covered by Drupal's security advisory policy, I recognize that people have limited time and that this is a fairly niche module that isn't widely used.
But at this point, even if it's not covered by security advisories, it's no longer an unmaintained / unsupported project. So it would be nice for the project page to reflect that.
Comment #9
apadernoCorrect me if I am wrong, but doesn't the user who offers to maintain a module/theme that opted in to security advisory coverage need to have the vetted role before applying to be a maintainer? In the case the user doesn't have the vetted role, isn't true that the project with security issues cannot be used to apply for getting the vetted role?
Comment #10
apadernoAs for the project not being covered by the security advisory policy, any project with a security issue that has not been fixed is marked as not being covered by the security advisory policy. I guess that is done so sites using that module receive a warning from the Drupal core code that checks for updates.
As for the current procedure to handle projects with security issues that have not been fixed, the permission to write in the repository and to add new maintainers is removed from the maintainers. Users who want to become maintainers of a project with security issue need to submit a patch fixing the security issues to the Drupal Security Team (by email, I take).
Comment #11
gisleI see from #2806727: [D7] pubdlcnt - Public Download Count that @chalpin has been granted permission to opt into security advisory coverage.
Let me just say that I applaud that decision!
While it is not said up-front on the application page, if you look at the page that give instructions to reviewers, you'll find that it tells reviewers how to review Abandoned Project Applications, so it is clear that this route to getting permission to opt into security advisory coverage is recognized as a valid one.
Also, if you look at the minimum requirements for code, the current best practice says:
This means that you probably will be granted permission to opt into security advisory coverage by creating a toy project with about 130 lines of code and 6 functions (e.g. something with a handful standard hooks pulled from the examples project).
IMHO, identifying and solving (with some feedback from the security team and the community) a security issue in an existing modules tells us a lot more about the person's ability to write secure code than some of the toy modules that routinely gets approved in the security advisory coverage application queue.
Comment #12
apadernoI am setting the status to Postponed, since we are waiting for a reply from the Security Team.
Comment #13
dstolI have added chalpin to the internal security issue. We will work with him to get the issue resolved and released to the community.
Comment #14
chalpin CreditAttribution: chalpin as a volunteer commentedOn the internal security issue, the security team said "Given that the security processes was not followed here, we would need to add at least one more maintainer. This can happen in the public queue." I've reached out to potential co-maintainers.
Comment #15
emerham CreditAttribution: emerham as a volunteer commentedI'm offering to co-maintain pubdlcnt with chalpin
Comment #16
dstol@kiamlaluno Can you please set up maintainer-ship of pubdlcnt to chalpin and add ermerham added as an additional maintainer?
David Stoline, on behalf of the Drupal Security team
Comment #17
gregglesYep, RTBC what dstol said.
Comment #18
apadernoI changed ownership as requested and added ermerham as co-maintainer.
Comment #19
chalpin CreditAttribution: chalpin as a volunteer commentedThanks to everyone who has helped me with this!
I can see that I appear as a full maintainer along with as co-maintainer ermerham on the 'Maintainers' tab of the pubdlcnt project page.
However, I can't seem to edit the project or add full releases. When I go to "Add new release" and select the appropriate git tag, it tells me "Your project has not opted into security advisory coverage. Full releases are best with security advisory coverage. You may opt in by editing your project." When I click "editing your project", I get a 403.
Comment #20
chalpin CreditAttribution: chalpin as a volunteer commentedComment #21
apadernoThe access denied error was caused from the input format used for the node body. Since you cannot use it, Drupal doesn't allow you to edit the node.
I opted into security coverage, and changed the input format from full HTML to filtered HTML.
I apologize: I didn't notice the input format set for the project when I changed ownership.
Comment #22
chalpin CreditAttribution: chalpin as a volunteer commentedEverything seems to be working now, thank you.