CEP XXXX: Upload timestamp in package record metadata by jezdez · Pull Request #154 · conda/ceps

jezdez · 2026-03-05T09:09:41Z

Checklist for submitter

I am submitting a new CEP: Upload timestamp in package record metadata.
- I am using the CEP template by creating a copy cep-0000.md named cep-XXXX.md in the root level.
I am submitting modifications to CEP XX.
Something else: (add your description here).

Checklist for CEP approvals

The vote period has ended and the vote has passed the necessary quorum and approval thresholds.
A new CEP number has been minted. Usually, this is ${greatest-number-in-main} + 1.
The cep-XXXX.md file has been renamed accordingly.
The # CEP XXXX - header has been edited accordingly.
The CEP status in the table has been changed to approved.
The last modification date in the table has been updated accordingly.
The table in the README has been updated with the new CEP entry.
The pre-commit checks are passing.

Propose adding an optional `upload_timestamp` field to per-record metadata in `repodata.json`. Unlike the existing `timestamp` field (build time, builder-controlled), `upload_timestamp` is set by the channel server when an artifact is indexed, providing a trustworthy publication time for supply chain security features (dependency cooldowns) and reproducible environment resolution. Requires: CEP 36

jaimergp

Thank you for bringing this up, I don't think we've discussed the exploitability of timestamp before, and this CEP brings up a few good points. Let's use this opportunity to also secure the acceptable values for timestamp.

jaimergp · 2026-03-05T12:15:50Z

cep-XXXX.md

+<tr><td> Author(s) </td><td> Jannis Leidel </td></tr>
+<tr><td> Created </td><td> Mar 4, 2026 </td></tr>
+<tr><td> Updated </td><td> Mar 4, 2026 </td></tr>
+<tr><td> Discussion </td><td> NA </td></tr>


Suggested change

<tr><td> Discussion </td><td> NA </td></tr>

<tr><td> Discussion </td><td> https://github.com/conda/ceps/pull/154 </td></tr>

jaimergp · 2026-03-05T12:17:02Z

cep-XXXX.md

+<tr><td> Updated </td><td> Mar 4, 2026 </td></tr>
+<tr><td> Discussion </td><td> NA </td></tr>
+<tr><td> Implementation </td><td> NA </td></tr>
+<tr><td> Requires </td><td> CEP 36 </td></tr>


I need to think what to do about this field. I think it should only be for other PRs that are open at the same time, not necessarily the ones that have been merged already. I know I replaced these URLs for 29-38 but maybe it was not a good idea.

jaimergp · 2026-03-05T12:19:04Z

cep-XXXX.md

+[CEP 36](./cep-0036.md) defines the schema for entries in `packages` and `packages.conda` within `repodata.json`. This CEP adds one optional field to the package record metadata:
+
+- `upload_timestamp: int`. Optional. Unix time in milliseconds when the artifact was added to the channel index. It MUST be set by the channel server or indexing tool, not by the build tool. If absent, clients MAY fall back to `timestamp` for time-based operations.
+


Seeing timestamp with this angle of security, I think we could add more restrictions in this CEP:

Limit timestamp to dates in the past, never in the future.

Rule: timestamp <= upload_timestamp

Force indexing tools to reject packages where timestamp does not obey these rules.

In conda-index we don't know when a package was uploaded. We could keep track of when it was first seen or first indexed. But there are cases where we might lose that information, like if we decide to re-index a channel. A common workflow is to index a package, and then upload everything to the CDN.
What about the last-modified date from HTTP or the filesystem timestamp?

jaimergp · 2026-03-05T12:20:33Z

cep-XXXX.md

+
+### Channel server requirements
+
+Channel servers and indexing tools (such as `conda-index`, `quetz`, or Anaconda's infrastructure) SHOULD set `upload_timestamp` on each package record when the artifact is first indexed into the channel. The value MUST reflect the actual time the artifact became available in the channel, not the build time or any value from the artifact itself.


Given that the timestamp is going to be the time of indexation, maybe we should call it indexed_timestamp or indexed_at.

Alternatively, we could ask the indexers to peek at the file creation time on disk, but that's flaky and filesystem dependent so let's focus on "first time the package appeared on repodata".

jaimergp · 2026-03-05T12:22:43Z

cep-XXXX.md

+
+Channel servers and indexing tools (such as `conda-index`, `quetz`, or Anaconda's infrastructure) SHOULD set `upload_timestamp` on each package record when the artifact is first indexed into the channel. The value MUST reflect the actual time the artifact became available in the channel, not the build time or any value from the artifact itself.
+
+If a channel re-indexes existing artifacts without a prior `upload_timestamp`, it MAY use the file modification time or another server-side signal as a best-effort approximation. It MUST NOT copy the value from the artifact's `timestamp` field.


This is going to be tricky to implement robustly, I fear. Some channels may not have the upload timestamp in their database, and their filesystem metadata may not be reliable (files were copied around, recovered from a backup, etc).

We could be a bit more permissive with using timestamp as long as the value is prior to the approval of this CEP, so we know they are not exploiting that weakness.

Im also not sure about this. I think it makes more sense to initially set the field to the same value as timestamp. This would allow switching existing exclude-newer implementation to the new upload_timestamp without any interruption.

I was also considering leaving it empty for those records but that still poses a security risk when using exclude-newer.

jaimergp · 2026-03-05T12:23:37Z

cep-XXXX.md

+
+Conda clients that implement time-based filtering (e.g., dependency cooldowns, exclude-newer) SHOULD prefer `upload_timestamp` when present. If `upload_timestamp` is absent, clients MAY fall back to `timestamp` with appropriate documentation that the value is builder-controlled.
+
+### Schema


We haven't done this in other CEPs, so I have some reservations about introducing this precedent. I think we can just update the relevant schemas and their versions as required by CEP specifications, as we would do with the aggregated docs in conda.org. So in a way, schemas are "downstream" from the CEP.

jaimergp · 2026-03-05T12:24:45Z

cep-XXXX.md

+}
+```
+
+Note that `patchable` is `false`: unlike `timestamp`, this field SHOULD NOT be modified by repodata patching, since it represents a server-side fact.


Prior CEPs didn't discuss whether a repodata field is patchable or not. I think it can be inferred from whether they are server-side or package-side, but maybe that's a matter for a CEP. I did leave "the door open" saying that modifications are allowed, but without scoping patches in.

pavelzw

cool!

pavelzw · 2026-03-05T12:57:37Z

cep-XXXX.md

+- `uv --exclude-newer` and `pip --exclude-newer` for reproducible resolution
+- Dependency cooldown features that delay installation of recently published packages as a supply chain security measure
+
+The conda ecosystem would benefit from an equivalent signal.


pixi also has this feature: https://pixi.prefix.dev/latest/reference/pixi_manifest/#exclude-newer-optional
i expect this is currently using the timestamp

It currently does, and it's a security risk. If this CEP were implemented, we would immediately change that.

pavelzw · 2026-03-05T12:58:20Z

cep-XXXX.md

+
+### Use cases
+
+1. **Dependency cooldowns**: A configurable time window that excludes packages published too recently from being installed, giving security vendors time to flag malicious packages. See conda/conda#15759 and [William Woodruff's analysis](https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns) of supply chain attack windows.


Suggested change

1. **Dependency cooldowns**: A configurable time window that excludes packages published too recently from being installed, giving security vendors time to flag malicious packages. See conda/conda#15759 and [William Woodruff's analysis](https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns) of supply chain attack windows.

1. **Dependency cooldowns**: A configurable time window that excludes packages published too recently from being installed, giving security vendors time to flag malicious packages. See [conda/conda#15759](https://github.com/conda/conda/issues/15759) and [William Woodruff's analysis](https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns) of supply chain attack windows.

dholth · 2026-03-11T15:03:10Z

cep-XXXX.md

+
+### Why milliseconds
+
+For consistency with the existing `timestamp` field (CEP 34) and `channeldata.json` timestamp (CEP 38), both of which use Unix time in milliseconds.


Good to be all milliseconds all the time now, instead of maybe-seconds and maybe-milliseconds.

baszalmstra · 2026-03-27T12:50:39Z

@jezdez How can we move this forward? Anything I can do to help?

baszalmstra · 2026-04-08T12:22:20Z

@jezdez Gentle ping! I'd like to put this to a vote ASAP but there are still a few open questions.

jezdez · 2026-04-09T11:09:38Z

@baszalmstra Apologies, this dropped off my todo list in the past weeks, I'll take a look!

This was referenced Mar 5, 2026

Add dependency cooldown and conda_repodata_filters plugin hook conda/conda#15761

Draft

Add dependency cooldown support conda/conda#15759

Open

jaimergp reviewed Mar 5, 2026

View reviewed changes

pavelzw reviewed Mar 5, 2026

View reviewed changes

dholth reviewed Mar 11, 2026

View reviewed changes

This was referenced Mar 23, 2026

timestamp based threshold conda-incubator/conda-mirror#150

Open

feat(config): --exclude-newer with relative time scale prefix-dev/pixi#4545

Closed

Copilot AI mentioned this pull request Mar 27, 2026

Add timestamp-based package filtering (exclude-newer / exclude-older) conda-incubator/conda-mirror#151

Draft

JeanChristopheMorinPerso mentioned this pull request Apr 8, 2026

Add cooldown support for Conda git-pkgs/proxy#68

Merged

baszalmstra mentioned this pull request Apr 8, 2026

fix: Allow unknown timestamps in exclude-newer prefix-dev/pixi#5848

Merged

8 tasks

	<tr><td> Discussion </td><td> NA </td></tr>
	<tr><td> Discussion </td><td> https://github.com/conda/ceps/pull/154 </td></tr>

		[CEP 36](./cep-0036.md) defines the schema for entries in `packages` and `packages.conda` within `repodata.json`. This CEP adds one optional field to the package record metadata:

		- `upload_timestamp: int`. Optional. Unix time in milliseconds when the artifact was added to the channel index. It MUST be set by the channel server or indexing tool, not by the build tool. If absent, clients MAY fall back to `timestamp` for time-based operations.


		### Channel server requirements

		Channel servers and indexing tools (such as `conda-index`, `quetz`, or Anaconda's infrastructure) SHOULD set `upload_timestamp` on each package record when the artifact is first indexed into the channel. The value MUST reflect the actual time the artifact became available in the channel, not the build time or any value from the artifact itself.


		Channel servers and indexing tools (such as `conda-index`, `quetz`, or Anaconda's infrastructure) SHOULD set `upload_timestamp` on each package record when the artifact is first indexed into the channel. The value MUST reflect the actual time the artifact became available in the channel, not the build time or any value from the artifact itself.

		If a channel re-indexes existing artifacts without a prior `upload_timestamp`, it MAY use the file modification time or another server-side signal as a best-effort approximation. It MUST NOT copy the value from the artifact's `timestamp` field.


		Conda clients that implement time-based filtering (e.g., dependency cooldowns, exclude-newer) SHOULD prefer `upload_timestamp` when present. If `upload_timestamp` is absent, clients MAY fall back to `timestamp` with appropriate documentation that the value is builder-controlled.

		### Schema


		### Use cases

		1. Dependency cooldowns: A configurable time window that excludes packages published too recently from being installed, giving security vendors time to flag malicious packages. See conda/conda#15759 and [William Woodruff's analysis](https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns) of supply chain attack windows.


		### Why milliseconds

		For consistency with the existing `timestamp` field (CEP 34) and `channeldata.json` timestamp (CEP 38), both of which use Unix time in milliseconds.

Conversation

jezdez commented Mar 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Checklist for submitter

Checklist for CEP approvals

Uh oh!

jaimergp left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dholth Mar 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pavelzw left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

baszalmstra commented Mar 27, 2026

Uh oh!

baszalmstra commented Apr 8, 2026

Uh oh!

jezdez commented Apr 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

jezdez commented Mar 5, 2026 •

edited

Loading

dholth Mar 11, 2026 •

edited

Loading