Offering to maintain Instagram Without API (IWA)

To be able to edit the project page is sufficient to be maintainer, which means having all the permissions on the project: Write to VCS, Edit project, Administer maintainers, Maintain issues, and Administer releases. A co-maintainer has at least one of these permissions, but less than five.

You currently have only the Write to VCS, Maintain issues, and Administer releases permissions. That is why you cannot edit the project page.

Is there anything you need to do for which is necessary to be project owner?

@ipwa:
There are also security concerns in leaving an inactive maintainer present, should their account become compromised it could cause damage to the project page, remove existing maintainers, commit malicious code and create malicious releases.

Not only would this damage the reputation of the project it could additionally damage the reputation of any developer who assisted, either by action or inaction, in allowing it to occur/continue.

Inactive in a project does not mean the used account is more compromisable than other accounts. Even an account inactive on a site is not necessarily more compromisable than other accounts, as long as the software running the site is kept secure.

Responding to the points raised in comment 7 (I have previously informed @avpaderno of this logic, I am posting it here solely to fill in the gaps knowingly left in their response):

The concept falls to Least Privilege Access and Inactive Account Management.

The breakdown is essentially: Give a user only permissions they actively require, ensure accounts that are no longer active do not have active access, and admin level accounts should be subjected to extra scrutiny.

An individual who is no longer actively participating does not require the ability to commit to the repository (a more active maintainer can do so on their behalf)
An individual who is no longer actively participating does not require the ability to edit the maintainers (an active maintainer can make decisions on evaluating the threat risk of new and existing maintainers)
An individual who is no longer actively participating does not require the ability to edit the project page (A non active user will not understand the current status of the project to provide proper updates)
A non-responsive inactive maintainer is by definition not active on the project
Inactive accounts should be disabled (on D.O. this means remove from the user from the project)

Normally in the open source world we would solve inactive owners by by forking to new project as one can not usually takeover an existing project (this also solves revoking permissions to existing maintainers), however D.O. tends to suggest taking over a namespace (or what some of us call "a successful supply chain attack via social engineering attack").

as long as the software running the site is kept secure.

It is not just the site one needs to worry about, user:password lists are available for cheap or even free, keyloggers, credential stealers, etc. One needs to be concerned that the entire chain from server to every individual maintainer is secure. A non-responsive maintainer has by definition not informed you of their current security posture or recent security incidents.

The key is no longer active, which does not seem true in this case. Furthermore, the security of an account does not depend on how often an account is used. In fact, in some cases, the system to gain access to an account works when the account is used more often.

The XZ Utils backdoor has been added by a new maintainer, not through the account used by a no longer active maintainer. That probably means that No longer active maintainer means unsecure account. cannot be assumed.

This is the message I sent.

Hello Thirsty,

I am contacting you because Nicolas (https://www.drupal.org/u/ipwa), who already is co-maintainer, offered to become maintainer for Instagram Without API (IWA) (https://www.drupal.org/project/instagram_without_api), a project you created for which you are project owner and maintainer.

May you post a comment on _issue about accepting or declining the offer? Please do not reply via email; we need a reply on the offer issue.
Without a comment posted on that issue in the next 14 days, Nicolas will be probably made maintainer.

I am contacting all the project maintainers, and the project co-maintainers with the "Administer maintainers" permission, who logged in at least once in the past 12 months. In this case, that is just you.

Project moderators will not remove the existing maintainers/co-maintainers; the project owner will not be replaced either. Maintainers cannot change the project owner; co-maintainers/maintainers can only be removed/added by people who have the permission to administer co-maintainers/maintainers.

As last note: This offer is about being maintainer, which is different from being co-maintainer. A maintainer is a person who has all the drupal.org permissions on a project: Write to VCS, Edit project, Administer maintainers, Maintain issues, Administer releases. A person who does not have all those permissions is a co-maintainer.
If there is any reason for not giving all those permissions, please explain that on the offer issue. We need this to know it was intentional and not a misunderstanding on what the offer required.

Best regards,
Alberto Paderno
-- Drupal.org project moderator
-- Drupal.org site moderator

The status is Postponed because we are waiting for a reply.

Please post a comment after 14 days, if your offer has not been declined. It will show you are still interested in maintaining this project and it will serve as reminder that a project moderator's action is required.

ipwa is now maintainer of the project (which means he now has also the Edit project and the Administer maintainers permissions).