Closed (fixed)
Project:
Drupal.org project ownership
Component:
Ownership transfer
Priority:
Normal
Category:
Task
Assigned:
Reporter:
Created:
4 May 2022 at 17:40 UTC
Updated:
21 May 2022 at 11:12 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
mark_fullmerI am the current owner of the four modules listed above, and I approve this transfer of ownership to the
utexasuser.Comment #3
cmlaraThe 4 above projects appear to be covered by the security advisory policy.
It is my understanding that webmasters are prohibited from transferring security advisory policy covered modules to owners who are not vetted.
The utexas account does not appear to be vetted and appears from its profile to be a shared account which can not be vetted.
Leaving as needs review for a webmaster to provide a more authoritative response..
Comment #4
gravelpot commentedHi cmlara, I am the individual who set up the utexas account. Before creating the account, I confirmed that this looked compliant with the D.o terms of service (see https://www.drupal.org/terms#accounts):
Any help you can provide in working through this issue is appreciated. Thanks in advance.
Comment #5
cmlaraHello gravelpot,
The procedure to receive the the vetted role (also known as permission to opt into security advisory coverage) is governed by Apply for permission to opt into security advisory coverage. The process is geared towards individuals. An applicant is required to have code committed under their account which shared accounts are prohibited from doing. (I'm not particularly found of this process however it is the current policy.)
A recent issue where a project owner (with the vetted role) tried to transfer an enrolled project to an non-vetted user is #3103361: Transfer ownership of Browser Detect. I personally don't agree with restricting who a project owner can transfer to, however I believe it has been required by the Security Team so that they have someone who has "proved they know how to write secure code" responsible for the project and (in theory but perhaps not in practice) auditing all code submitted by maintainers/co-maintainers to keep security issues from occurring in releases.
It is my understanding that policy on not transferring to non-vetted accounts applies to organizations as well (otherwise a non-vetted user could just create an organization account to bypass the policy) though there is always a chance I am mistaken.
The policy creates a rather annoying quirk. Anyone can own a project and any vetted maintainer or co-maintainer can opt a project into security coverage (a project could end up with a non-vetted owner which could be an organization) however after that it can only be transferred to vetted accounts which prevents organizations from becoming owners after the project is enrolled in security advisory coverage.
Comment #6
avpadernoI transferred the ownership as requested.
Shared accounts aren't allowed to commit code. It won't make sense to ask shared accounts to have the permission to opt into security coverage, since applications coming from a shared account would be rejected.
Comment #7
avpadernoComment #8
gravelpot commentedHi @apaderno, thanks for taking care of these so quickly.
Quick question -- I always thought that the "owner" of a project was visibly reflected on the project page as the username listed as "Created by," but that didn't change with all of these ownership changes (see screenshot). I recall seeing this change in high-profile cases of contrib module ownership changes in the distant past.
Is this no longer the case? Is there anyway to update the username that appears there?
Comment #9
gisleIt used to be the owner.
However. note that it now says: "Created by". It is not necessarily the owner, but the person that initially created the project. AFAIK, there is no way to figure out who current owner is from the GUI.
It was changed in February this year, see: #3099925: Display original project author instead of current node owner on project page.
Comment #10
avpadernoYou can still see who is the project owner on https://www.drupal.org/node/2975380/maintainers, for example. It's the user on the top of that list, for which the permissions cannot be changed. (That's true for every project for which you have the permission to change co-maintainers/maintainers.)
Comment #11
gisleThat link returns a 403 for most users here (including me). You've some elevated permissions that allow you to inspect that page.
Comment #12
avpaderno@gisle My previous comment was for gravelpot, which asked me a question, to which I answered without repeating what already said in another comment. I apologize for the confusion.