It was probably ill-advised to couple manifest signing and verification to
their respective types. This changeset simply changes them from methods to
functions. These might not even be in this package in the future.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
Because manifests and their signatures are a discrete component of the
registry, we are moving the definitions into a separate package. This causes us
to lose some test coverage, but we can fill this in shortly. No changes have
been made to the external interfaces, but they are likely to come.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
Many details have been updated in route descriptors. This commit regenerates
the specification from the latest changes and template.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
This changeset fills in details for many RouteDescriptors, ensuring that
responses and their variation are fully covered. At this point, all endpoints
are described in full. Tweaks for consistency and to avoid repetition may still
need to be done.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
If `--insecure-registry mydomain.com` was specified, it would match a registry at mydomain.com on any port.
This was accidentally added in #9735 and is now being reverted.
Signed-off-by: Tibor Vass <teabee89@gmail.com>
This requires some discussion of how we will handle errors due to network problems
and after further changes in that direction some more stress testing. There is also an
upcomming commit implementing zero fill on WriteStream when offset is greater than
the current size of the file.
This changeset provides data structures and definitions describing the routes
available in the V2 registry API. These route descriptors are structured to
provide automated registration, for creating routers, in addition to complete
documentation duty. It's also a possibility that this could be used to
enumerate test coverage for server implementation.
Using this functionality, we've also developed a template to automatically
generate and API specification for submission into docker core.
If Context.Name is not set, the acceess controller may allow an unintended
request through. By only allowing a request to proceed without a name on the
base route, we provide some protection if future bugs forget to set the context
properly.
As a baseline for the new registry API specification, we are checking in the
proposal as currently covered in docker/docker#9015. This will allow us to
trace the process of transforming the proposal into a specification. The goal
is to use api descriptors to generate templated documentation into SPEC.md. The
resulting product will be submitted into docker core as part of the client PR.
