camallo/dkregistry-rs

A pure-Rust asynchronous library for Docker Registry API v2

dkregistry-rs's Issues

Publish the 0.5.1

Hello,

the version 0.5.0 uses tokio 0.2 which is an issue if you want to use a 1.0 version of tokio in your application, this is fixed in the 0.5.1 version(master) but that has sadly not been published yet.

Will be using git version of this till that gets published

authenticating against index.docker.io

I'm trying to pull a docker manifest from the public registry, but I'm getting a 401. There's a way to get a Bearer Token from auth.docker.io, but I don't know how pass that bearer token into the Client. With the auth module being private, it seems not possible to do this without a username/password.

Does not work with GCR with default settings

get_manifest fails, because GCR returns error 404.
Response body is

{"errors":[{"code":"MANIFEST_UNKNOWN","message":"Manifest with tag 'latest' has media type 'application/vnd.docker.distribution.manifest.v2+json', but client accepts 'application/vnd.docker.distribution.manifest.v2+json; q=0.5,application/vnd.docker.distribution.manifest.v1+prettyjws; charset=utf-8; q=0.4'."}]}

I am not sure if I right, but it seems like incorrect parsing of Accept HTTP header on GCR side.
What do you think?

Clarify dkregistry's License

At current it appears the only available license information for this crate is in the cargo toml. This should be made more prominent (eg. a license file and headers in source files).

Release guide is not compatible with cargo-release-release 0.12.4

Following the release guide doesn't work with the mentioned cargo release, which creates a tag prefixed with v.

Stepping down as a maintainer

@sdodson and @vrutkovs I'll no longer be a maintainer in this project. Please get in touch with @lucab to get someone on your team merge access here since this is crucial for https://github.com/openshift/cincinnati/ at this point. Of course finding a community member who wants to step up would work as well!

Bearer authentication has no tests

This could lead to #66 via #65 because the author 👻 relied on the tests covering this.

Support tagged digested references

dkregistry::reference::Version does not accommodate tagged digested references. Although these are not particularly common, they are valid.

Do a pre-release for the recent async work

Would be nice if I could use a release(-candidate) in aixigo/PREvant#28 but you don't have to hurry.

Originally posted by @schrieveslaach in #140 (comment)

Authenticating against Azure Container Registry (ACR) fails

The current implementation does not work with Azure Container Registry (ACR). As the REST specification outlines, Microsoft returns the access token using the access_token field instead of a field called token.

Ref: https://learn.microsoft.com/en-us/rest/api/containerregistry/access-tokens/get-from-login?view=rest-containerregistry-2019-08-15&tabs=HTTP#get-access-token-with-username-and-password

Allowing deserialization from both fields would allow authentication with Azure Container Registry as well.

v2/client: move to async reqwest

Now that reqwest has an async module, we should use that instead of plain hyper. Unfortunately, this means switching from rustls to native-tls, thus getting a FFI dependency to openssl (or similar).

---

Progress

• src/v2/blobs.rs
• src/v2/tags.rs
• src/v2/manifest/mod.rs
• src/v2/auth.rs #95
• src/v2/catalog.rs #95
• src/v2/mod.rs #95
• src/v2/config.rs #95
• src/lib.rs #95
• src/errors.rs #95

Warning when releasing using `cargo release`

[2020-10-07T15:44:23Z WARN ] In next minor release, `sign-commit` will only be used to control git commit signing. Use option `sign-tag` for tag signing.

No convenient way for accessing image labels for all manifest formats

Image labels can be created within the Dockerfile with the LABEL instruction.

Although not officially documented, we could get these via the already implemented manifests:

• V2 S1 they are stored in the first element of the history array, and
• V2 S2 they are stored in the config array.

On quay.io there's an API endpoint for getting labels, which requires a manifestref that must be fetched via the listRepoTags endpoint first.

---

Implementation state

• V2S1 #59
• V2S2
• Quay API (calling out to this directly shouldn't go into this crate)

Support for application/vnd.oci.image.index.v1+json

I have noticed an increasing number of Docker Hub repositories are returning 404 when retrieving manifests. An example of such repositories is koenkk/zigbee2mqtt:latest.

Any idea what might be happening?

Www-Authenticate header content is handled case-sensitively

Hi, I stumbled upon an issue in your library while using it with our private image registry based on Sonatype Nexus (via OpenShift's cincinnati).

When trying to connect and authenticate to our registry, the request fails with following error:

[2021-11-19T12:33:31Z ERROR graph_builder::graph] failed to fetch all release metadata
[2021-11-19T12:33:31Z ERROR graph_builder::graph] www-authenticate header parse error
[2021-11-19T12:33:31Z ERROR graph_builder::graph] 'method' field missing

...where the last two lines originate from your library.

Taking a deeper look at this error, I found out that our registry returns the Www-Authenticate header with the method in uppercase letters: BASIC realm="Sonatype Nexus Repository Manager", but your regex in src/v2/auth.rs expects the method to have its first letter uppercase with the rest in lower case. Because of this, the parsing of our registries' header fails, resulting in the above error message.

Looking at RFC7235 Section 2.1, it is noted that method and keys should be handled as case-insensitive tokens:

It uses a case-insensitive token as a means to identify the authentication scheme [...]. Authentication parameters are name=value pairs, where the name token is matched case-insensitively [...].

I suggest changing the Www-Authentication header parsing to be case-insensitive to better conform to the HTTP specification.

I have already created a fix for this issue and will open a new pull request shortly that I kindly ask you to review.

Thanks!

v2/client: trim content-type parameters

This is a followup to #82 (comment).

Current docker-registry specification and implementation have some quirks related to content-type headers, returning charset parameters even for media-types that don't allow any.

As a minor compatibility fix, we should revert #82 and instead introduce a mime_trim_params that expunges all parameters from a media type.

v2/client: friction around insecure registries and the `is_v2_supported` method

IMHO the result of the is_v2_supported() method isn't correct as it is.
In case of querying a v2-supported registry via plain http, the 301 status code (MOVED) will cause the method to return false to indicate that v2 is not supported here.
The correct behavior would be look at the new URL and if the scheme changed to https, instead of returning false, throw an error which reports that the requested scheme is not supported.

I'll go ahead and call this a bug, but I'd like to know the original motivation behind this in case I'm missing something.

tests/net/quay: insecure test times out

This blocks CI and thus all PRs will fail until resolved, e.g. https://travis-ci.org/camallo/dkregistry-rs/jobs/628065374.

Yanked dependencies

warning: package `bumpalo v3.1.2` in Cargo.lock is yanked in registry `crates.io`, consider updating to a version that is not yanked
warning: package `quote v1.0.2` in Cargo.lock is yanked in registry `crates.io`, consider updating to a version that is not yanked

render::unpack fails for some images.

Hi, thanks for your awesome library! I think I found a little bug, described below. Aside from that -- great overall experience, thanks!

Description
Alpine-based images make a heavy use of symlinks.
As it stands now, tar-rs overwrites files and not symlinks. (alexcrichton/tar-rs/pull/217)
If layers create a symlink in the same location, render::unpack will fail.

Steps to reproduce:

1. Run cargo run --example image registry-1.docker.io nginxdemos/hello

Expected result:

1. Layers are downloaded and unpacked

Actual result:

1. The command fails with

[registry-1.docker.io] failed to unpack `/usr/home/akhramov/dkregistry-rs/nginxdemos_hello:latest/usr/bin/strings`

Known workaround:

None yet, shall tar-rs be fixed?

Dependents of this crate and `actix-web` are broken

Unfortunately #84 broke dependents which also depend on actix-web:

error: failed to select a version for `ring`.
    ... required by package `rustls v0.15.0`
    ... which is depended on by `hyper-rustls v0.16.0`
    ... which is depended on by `dkregistry v0.2.2-alpha.0 (https://github.com/camallo/dkregistry-rs.git?rev=a60d804b697c67b7439522231ccd9179f8334537#a60d804b)`
    ... which is depended on by `graph-builder v0.1.0 (/home/steveej/src/job-redhat/cincinnati/graph-builder)`
versions that meet the requirements `^0.14` are: 0.14.3, 0.14.2, 0.14.1, 0.14.0

the package `ring` links to the native library `ring-asm`, but it conflicts with a previous package which links to `ring-asm` as well:
package `ring v0.13.5`
    ... which is depended on by `cookie v0.11.0`
    ... which is depended on by `actix-web v0.7.18`
    ... which is depended on by `graph-builder v0.1.0 (/home/steveej/src/job-redhat/cincinnati/graph-builder)`

I suggest we revert #84 and actively pursue #44.

blobs: authentication is broken

Since the token is appended to the request headers of the hyper client, which is not considered reqwest, #65 broke authenticated calls for blobs.