- Issue created by @fathershawn
- 🇺🇸United States cmlara
I will note that to my knowledge D.O. does not logs these changes to prove the details of this request.
✨ Add log of mainatiner level changes to project pages and provide notice when the Project Ownership queue adds/promotes a user Active is open regarding creating an audit log.
- 🇺🇸United States fathershawn New York
A log is a good idea. In this case I'm sure I've edited the project node in the last 7 years. I know that I've created release nodes, and I'm the only user to commit to this project in that time. It was definitely thoughtless to lock myself out, and I can wait for the timer to expire or perhaps we will hear from the owner on my request to transfer.
I don't have personal urgency but a user has asked for the D11 release now that Commerce has a D11 release.
- 🇮🇹Italy apaderno Brescia, 🇮🇹
Apparently, not even the Recent log messages page shows when somebody has been appointed/removed as co-maintainer or maintainer.
The only person who could decide to re-add you as maintainer is the project owner. I would suggest contacting him for this (and point him to your request to be the new project owner).
Since you are offering to be the new project owner, I take you think he is no longer active on drupal.org or no longer interested in maintaining the project. In that case, you should wait to be made the new project owner. - 🇮🇹Italy apaderno Brescia, 🇮🇹
As a side note, on https://git.drupalcode.org/project/commerce_purchase_order/-/project_mem..., you are still listed as maintainer, which means that, effectively, you had all the permissions on the project, on the drupal.org side. (On git.drupalcode.org, none of the project maintainers is listed as owner, not even the project owner.) You can still do what a maintainer can do, on git.drupalcode.org side.
- 🇺🇸United States fathershawn New York
Yes, I created the D8 version of this project and have maintained it by myself since July 2017. I created it for a client that I no longer have but maintain it for the community. The owner last posted a few weeks ago so we will hear from him I'm sure.
- 🇮🇹Italy apaderno Brescia, 🇮🇹
@fathershawn Given what reported on How project moderators handle requests to be project owner, maintainer, or co-maintainer → by Drupal Association staff (under Requests to become maintainer from a co-maintainer), I gave you back your maintainer's permissions.
- 🇺🇸United States greggles Denver, Colorado, USA
We can look at commits (as recently as a week ago and as early as years ago) https://git.drupalcode.org/project/commerce_purchase_order/-/commits/2.1.x
and at releases, again as recently as this month https://www.drupal.org/project/commerce_purchase_order/releases/2.1.0 → and as early as years ago https://www.drupal.org/project/commerce_purchase_order/releases/8.x-1.0 →
and see that fathershawn had the access described in the issue summary.
Thanks for your work on this module, fathershawn.
- 🇺🇸United States cmlara
Note for context: I suspect @fathershawn did have the rights requested, however as a security engineer concerned about the overall safety of the Drupal ecosystem, and the lack of logs that can prove otherwise I do wish to raise the following points in regards to #12
We can look at commits... and at releases... and see that fathershawn had the access described in the issue summary<,
Neither of those would confirm that fathershawn had:
- Access to modify maintainers
- Access to edit the project page
again as recently as this month
That was after @avpaderno granted them permission. Those need to be ignored.
We can look at the history of the project page and see the previous edit was 5 Apr 2024, that leaves around 10 months where a maintainer, or another user with enhanced powers on D.O. could have revoked the access to edit the project page. I do not have access to confirm the maintainer has not actually logged in, however in 💬 Request to become project owner Active mentions an admin reaching out which makes me wonder if their last login was <1 year ago ?
Even assuming ability to edit the project page that would not prove the user had the ability to modify users.
We can look at https://git.drupalcode.org/project/commerce_purchase_order/-/project_mem... and notice there is a disconnect that some of the maintainers are still listed as full maintainers while their D.O. permission is no commit privileges, however that does not confirm that those changes to the user were not done sometime in the past (2020 when @guillaumev had their last activity?)
@fathershawn shawn being listed as 'maintainer' does imply at some time they were elevated to have the ability to modify users, however does not confirm they still had the D.O. permission at the time of the request (changes on D.O. downgrading permissions are not populated to GitLab and maintainers have been known to miss downgrading users in GitLab, which if @fathershawn is to be taken at their word may have proven himself by the other users still having maintainer level access)
Without an aduit log I would suggest that is not a reasonable level of proof when it comes to supply chain integrity to prove @fathershawn had all the permissions listed at the time of the incident.
Note: I'm not saying undo this as the permissions needed up being granted under a different policy rule allowing changes, I am just indicating that #12 has some flaws in the assertions the external data proves the user had the permissions claimed on the day of the incident.
- 🇺🇸United States fathershawn New York
@greggles Absolutely happy to continue the basic maintenance.
@cmlara is also correct and change logs on maintainer permissions would definitely have made this issue trivial to fix and false claims easy to verify.
- 🇺🇸United States greggles Denver, Colorado, USA
Thanks for those observations, cmlara.
I didn't realize the age of this issue vs. some of the releases/commits. I think the conclusion from #12 is still reasonable :)
@cmlara have you reviewed what's auditing logs are gitlab's codebase for events like this? That seems like a useful area of research.
- 🇮🇹Italy apaderno Brescia, 🇮🇹
(As side note, I do not have the administrator role, which would mean having all the permissions on drupal.org.)
- 🇺🇸United States cmlara
@cmlara have you reviewed what's auditing logs are gitlab's codebase for events like this? That seems like a useful area of research.
The basics are the project activity event log (sample: https://git.drupalcode.org/project/commerce_purchase_order/activity) which is also available via the API.
It is not an indefinite log (removed after 3 years for performance). It was mentioned in ✨ Add log of mainatiner level changes to project pages and provide notice when the Project Ownership queue adds/promotes a user Active there are some limitations in the activity feed as compared to D.O. permissions mapping where (based on how we use GitLab) not everything on D.O. side will register a change on GitLab such as change of owners.
There are webooks for pushing data into an external system, however I have not investigated the specific data it could push in relation to permission changes at the project level.
Automatically closed - issue fixed for 2 weeks with no activity.