ARTIFACTORY: Why Conda packages may bypass Artifactory remote repository (repodata v3 / absolute url)

Applies to:

JFrog Artifactory (Conda remote repositories)

conda-pypi or clients using conda-pypi wheel channels.

Clarification - Pixi does not use the url field in repodata v3 and is not affected

Customers using Conda 26.1.0+, or any client with the conda-pypi wheel channels



Overview

Modern Conda clients can install some packages, especially Python wheels indexed under repodata v3 (packages.whl / v3.whl), by following an absolute URL in repodata that points directly to an external CDN (for example, files.pythonhosted.org / files.pypihosted.com). Those downloads do not go through your Artifactory Conda remote; as a result, caching, traffic logs, quotas, and security scanning for that remote may therefore miss affected wheels even though the channel URL is your Artifactory host.

Note -

This is expected client behavior under the emerging Conda repodata v3 / CEP design. It is not a defect in Artifactory’s remote proxy for classic Conda packages.



Who is affected?

This applies to your workflow if you use:

Component

Notes

Conda 26.1.0 or later

Repodata v3 wheel handling is most relevant from this release onward

conda-pypi or channels with wheel subdirs(v3.whl, packages.whl)

Often publish records with CDN URL fields

Traditional Conda installs that use the classic solver, standard Conda channels, and classic package types (.tar.bz2, .conda) typically continue to download through your Artifactory remote as before.



Why This Happens

Repodata v3 wheel records and absolute URLs

Wheel subdirs in repodata v3 (for example, v3.whl / packages.whl) can include package records with:

A channel-relative identity (fn, channel metadata)

An absolute URL field pointing at the real artifact on an external host (PyPI CDN, etc.)

Clients that understand repodata v3, such as Conda 26.1.0+, and tooling built on conda-pypi → are designed to prefer the download URL when present. Conda 26.1.0 explicitly fixed filename handling for v3 wheels by deriving the install target from the URL, not only from fn (conda 26.1.0 release, #15626).



Conda Ecosystem direction (CEP #151)

Draft CEP #151 – URL field for package records (RFC; not formally approved at time of writing) generalizes absolute URL beyond wheels. Combined with CEP #146 – repodata v3 rollout strategy, the ecosystem is moving toward repodata v3 as the default path for PyPI-integrated channels. JFrog is engaged with the Conda community on proxy and security implications.



WHAT YOU MIGHT OBSERVE

Python wheels do not appear in the Artifactory remote-cache or remote repository traffic for a Conda remote you expect to use exclusively.

Xray or Curation does not report scans for some wheel packages.

Usage or egress reporting does not reflect downloads you believe go through Artifactory.

404 on install if repodata or proxy paths don’t match what the v3 client expects



Recommended Actions:

Review your Conda client setup

Check:

$conda --version #26.1.0+ is the threshold)
$conda config --show solver
$conda config --show channels
$conda list | grep -E 'conda-pypi'

If you require all package traffic through Artifactory:

Prefer the classic Conda solver for those environments.

Avoid conda-pypi / v3.whl wheel channels until you have an explicit design for CDN-backed wheels.

If using conda-pypi wheel channels (experimental), be aware that absolute URL fields may bypass Artifactory.

If wheels are required → Route CDN traffic through Artifactory

If you must use wheel channels, configure an Artifactory remote repository for the upstream CDN (often a PyPI remote for files.pythonhosted.org or your index's CDN). That way, when the Conda client follows an absolute URL, the host is still a repository you manage and can scan.

Align security and network policy

Include any PyPI or generic remotes you add for CDN catch-up in Xray and Curation scope.

Update egress allow-lists if they assume only your Artifactory hostname is used for Conda installs.



Summary:

Conda 26.1.0+, and conda-pypi wheel channels may download Python wheels directly from external CDNs via repodata v3 url fields, bypassing Artifactory Conda remotes. Make sure to review solver, channels, and add PyPI/CDN remotes if policy requires all traffic through JFrog.

This is not an Artifactory outage - the remote repository can be healthy while wheels bypass it by design of the client + repodata.

Action is primarily on the Conda client and channel configuration, plus optional extra remotes for CDN hosts.



Related links

```
Conda 26.1.0 release
```

CEP #146 – Repodata v3 update strategy (PR)

CEP #151 – URL field for package records (PR)

```
conda-pypi (wheel repodata indexing)
```