ENH: Add month cooldown window for new package uploads

[matthewfeickert]

• To weakly guard against security issues that are introduced in new uploads to conda-forge, add a 30 day exclusion window for Pixi's resolver.
  • SP Discord thread that got me thinking about this
• This feature was introduced in Pixi v0.67.0, so require at least that for use.
• Update anaconda-client to v1.14.1.

This PR is coming from the main project and not my fork so that the CI actually runs, which is important on anaconda-client updates.

[matthewfeickert]

@scientific-python/nightly-wheels-developers this is ready for review.

[hugovk]

• To weakly guard against security issues that are introduced in new uploads to conda-forge, add a 30 day exclusion window for Pixi's resolver.

On the contrary, this can be very effective.

For example, of the 10 attacks in the chart at https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns, seven were taken down in under 24 hours. The others were 3 and 10 days, and 5 weeks.

[lucascolley]

thanks Matthew!

[matthewfeickert]

Thanks for the fast review, all!

On the contrary, this can be very effective.

I agree @hugovk. My thoughts are more along this section from the blog

Cooldowns are, obviously, not a panacea: some attackers will evade detection, and delaying the inclusion of potentially malicious dependencies by a week (or two) does not fundamentally alter the fact that supply chain security is a social trust problem, not a purely technical one. Still, an 80-90% reduction in exposure through a technique that is free and easy seems hard to beat.

My main concern and motivating reason for "weakly" is that we're relying on both detection to have happened and for this to be reported and properly dealt with by conda-forge. I have no doubt that conda-forge/core takes security seriously (they obviously do), but they do emphasize

conda-forge packages are built by strangers on the internet (our wonderful feedstock maintainers!) and are not suitable for use cases that require secure software provenance.

and we currently have no way of performing automated security audits of software environments if conda packages are installed (c.f. #general > ✔ Recommendations for security audits on conda packages? @ 💬). I think that until we can overcome this last issue that we can't really say more than "weakly", even if we're doing our best.

[henryiii]

Why a month? Generally 3 or 7 days is what I've seen projects adopt. At a month, that's quite a bit of time to also be isolated from security updates.

[hugovk]

We use 14 days for CPython.

How and when do you update pixi.lock?

I know Renovate supports pixi.lock, does Dependabot? If you use those, they ignore the schedule and cooldown for security updates.

[matthewfeickert]

Why a month?

@henryiii Not all conda-forge feedstocks are as responsive as their upstream PyPI or source components. A month gives sufficient time for things to work their way through the system. I'm not against changing this though.

How and when do you update pixi.lock?

@hugovk We've been manually updating it as needed, generally motivated by updates to https://github.com/anaconda/anaconda-client

upload-nightly-action/pixi.toml

Line 15 in 7c719ad

anaconda-client = "==1.14.1"

which are pretty infrequent.

We recommend that users are locked to a particular commit hash instead of targeting the workflow repository HEAD.

upload-nightly-action/README.md

Lines 10 to 23 in 7c719ad

	```yml
	jobs:
	steps:
	...
	- name: Upload wheel
	uses: scientific-python/upload-nightly-action@e76cfec8a4611fd02808a801b0ff5a7d7c1b2d99 # 0.6.4
	with:
	artifacts_path: dist
	anaconda_nightly_upload_token: ${{secrets.UPLOAD_TOKEN}}
	```
	Note that we recommend pinning the action against a specific SHA
	(rather than a tag), to guard against the unlikely event of upstream
	being compromised.