Send more emails

[di]

PyPI sends a fairly low volume of event-based emails to users, which results in the occasional spam report causing an abnormally high overall % of complaints.

Some ideas of things we could send emails for, to increase our overall email send, that would be a net positive user benefit and not just considered noise:

• Emails whenever a release gets yanked or unyanked
• New email added (sent to any other emails on the account) - feat: Emails sent to existing email accounts when adding new email #13866
• New primary email (sent to the old primary email) - Email notification when adding/removing email address. #3317
• New releases (sent to all maintainers)
• New files added to old releases (sent to all maintainers)
• Login from new IP addresses (sent to primary email)
• Added/removed API tokens
• List of trusted connections when maintainers leave the project
• New release with no 2fa - feat: add email for 2fa not yet enabled on upload #14444

[dstufft]

Other ideas:

• Emails whenever a release gets yanked or unyanked
• All of the new release/file/yanked/etc emails should be able to be subscribed to by any user for that project.

[aganders3]

I added and deleted a few API tokens today and was surprised to not get any emails about it.

[di]

@aganders3, what's your PyPI username?

[aganders3]

I am also @aganders3 there.

Edit: sorry I meant the comment above as a suggestion for another opportunity to send emails, not as a complaint!

[di]

@aganders3 Sorry, thought we already had that one! Great point, I've added it to the list.

[di]

@webknjaz proposed this addition which relates to OIDC/"Trusted Publishers":

Bonus points: it would be cool to send out a notification to the remaining maintainers with something like "Hey, X left the project but they've configured an OIDC trust with Y repo on GH earlier. Learn how this works and what can publish through this connection."
...
I'd still want to see a list of trusted connections. Or maybe, even, a list of users plus trusted publishers. As in "here's users/$things that can still upload releases to this project".

I've added this to the checklist above.

[woodruffw]

Another email idea: we should periodically notify project owners about stale/unused API tokens, e.g. if a project has had releases in the past N months that don't use a particular token.

As a conditional sequence:

1. If the project has API tokens;
2. and those API tokens haven't been used in the last N months;
3. and a release been has done in the last N months (e.g. with a different API token or trusted publishing);
4. then send an email notifying the owner of the API token + project owners that they have one or more stale tokens still registered.

This will be particularly helpful/useful as more projects roll out trusted publishing, since they may forget to delete the old tokens that trusted publishing replaces.

[di]

#11524 would be related to that as well.

[miketheman]

#997 would help increase volume

[woodruffw]

Triaging: we're doing a couple of these as part of STF-funded work.

I've asked @xBalbinus to start with emails for yanking and unyanking of releases.

[woodruffw]

Emails whenever a release gets yanked or unyanked

Looks like this one was already done ~3 years ago: https://github.com/pypi/warehouse/blame/7c6c4cf16d9f46660f687123a44766fb775dcea7/warehouse/email/__init__.py#L901-L935

I've asked @xBalbinus to work on the "New email added" one for the time being.

[di]

New email added (sent to any other emails on the account)

Done in #13866, thanks @xBalbinus!

New primary email (sent to the old primary email)

This might be a good next one if you're looking for something else to work on!

[xBalbinus]

Sounds great! Thank you so much!

…

On Thu, Jun 8, 2023 at 10:49 AM Dustin Ingram ***@***.***> wrote: New email added (sent to any other emails on the account) Done in #13866 <#13866>, thanks @xBalbinus <https://github.com/xBalbinus>! New primary email (sent to the old primary email) This might be a good next one if you're looking for something else to work on! — Reply to this email directly, view it on GitHub <#13234 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASH4FPS3QZQXPKMA2KUAY53XKHQ5ZANCNFSM6AAAAAAV7B6C6U> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[monperrus]

FTR, NPM sends emails for all new releases and this is very useful to get liveness feedback on CD.

[monperrus]

For the record, about "New releases (sent to all maintainers)", here is the NPM email

A new version of the package crawler-user-agents (1.0.152) was published at 2024-10-19T06:39:58.891Z from GitHub Actions: https://github.com/monperrus/crawler-user-agents/actions/runs/11415392939/attempts/1 (triggered via a "workflow_run" event on git ref "refs/heads/master").
The shasum of this package is 3279ecc6499581f409f6aa4643d25847a6f5b5c0.

If you have questions or security concerns, you can contact us at https://www.npmjs.com/support.

Thanks,

The npm team

It contains lots of interesting information.

[woodruffw]

Hmm, how does NPM get that context? I don't think they support Trusted Publishing yet, although perhaps they get it directly from their --provenance feature?

Regardless, agreed on that being useful/interesting information to include 🙂

[monperrus]

Yes this is from --provenance

[woodruffw]

Another email idea, from @pitrou on DPO:

Perhaps some other action PyPI could take is gather all projects with some activity in the last N years and a maintainer with 2FA disabled, and e-mail all their maintainers to inform them of the risk? Most maintainers will not think about checking this otherwise (this only occurred to me by chance).

Source: https://discuss.python.org/t/announcement-2fa-now-required-for-pypi/42251/26

Or laid out:

1. Every year (quarter? month?) PyPI could gather projects with upload activity in the last year (quarter? month?);
2. For each project, if there are any maintainers/owners without 2FA enabled, all owners who do have 2FA enabled get an email telling them that they have dormant, less-secure peers on their projects.

(I think emailing owner roles only probably makes sense to start, since only owners can administrate the project's user roles anyways.)

[di]

It's currently not possible to upload without having 2FA enabled:

warehouse/warehouse/forklift/legacy.py

Lines 524 to 537 in a685531

	# Ensure user has enabled 2FA before they can upload a file.
	if not request.user.has_two_factor:
	request.metrics.increment("warehouse.upload.failed", tags=["reason:no-2fa"])
	raise _exc_with_message(
	HTTPBadRequest,
	(
	"User {!r} does not have two-factor authentication enabled. "
	"Please enable two-factor authentication before attempting to "
	"upload to PyPI. See {project_help} for more information."
	).format(
	request.user.username,
	project_help=request.help_url(_anchor="two-factor-authentication"),
	),
	) from None

So I'm not sure there's value in nagging these users. Instead, maybe we would want to email the maintainers that do have 2FA enabled, and tell them that they have 'stale' collaborators without 2FA enabled? But again, I don't think these users represent a huge risk because they can't do anything on the project in question.

[woodruffw]

Instead, maybe we would want to email the maintainers that do have 2FA enabled, and tell them that they have 'stale' collaborators without 2FA enabled? But again, I don't think these users represent a huge risk because they can't do anything on the project in question.

Sorry, I might have worded this badly: I meant emailing the maintainers that do have 2FA enabled, not the ones that don't, per your point about non-2FA maintainers not being able to upload 🙂

And yeah, I think the "stale" case is what @pitrou was interested in -- he can motivate it further but IIUC the concern was that older projects don't always pay attention to who is still trusted as an owner/maintainer, and so having a bunch of old non-2FA accounts still authorized presents a good takeover opportunity for an attacker.

[pitrou]

And yeah, I think the "stale" case is what @pitrou was interested in -- he can motivate it further but IIUC the concern was that older projects don't always pay attention to who is still trusted as an owner/maintainer, and so having a bunch of old non-2FA accounts still authorized presents a good takeover opportunity for an attacker.

Yes, that was exactly the context for me.

[di]

Note that we've also marked the emails of all non-2FA users as unverified: #11850 (comment). This means that a successful account takeover would require the user's password and access to one of the email addresses present on the account prior to takeover. Still possible, but less likely.

I think instead of sending emails, we should probably just explore changing these user's roles to something that would require re-invitation to the project by an active maintainers in the future. That said, I think this is a bit off-topic for the original issue, which is about increasing our general volume of emails and not about one-off email campaigns, so we should probably move the discussion to a new issue.