support for insecure registries

[tdhooks]

Currently, when attempting to pull from an insecure registry, the pull fails like so:

tdhooks@pop-os:~$ sarus pull localhost:5000/sarus/alpine:latest
# image            : localhost:5000/sarus/alpine:latest
# cache directory  : "/home/tdhooks/.sarus/cache"
# temp directory   : "/tmp"
# images directory : "/home/tdhooks/.sarus/images"
[1674.682032881] [pop-os-30306] [main] [ERROR] Error trace (most nested error last):
#0   retrieveImageManifest at "Puller.cpp":324 Error while sending request for manifest to remote registry
#1   "unknown function" at "unknown file":-1 Error in SSL handshake

Having skimmed through Puller.cpp, it looks like sarus is hard-coded to only support pulls from registries with valid https (see Puller.cpp:549).

Docker allows use of insecure registries mainly through the insecure-registry config field in /etc/docker/daemon.json, and this is very useful for those that want to use LAN secured registries without certs or simply for testing. Could/Should this be a new feature, configurable through a similar field in sarus.json or a sarus pull --insecure flag?

Note: I tested this with un-certed localhost and non-localhost repositories to the same result. I haven't tested with a self-signed certificate, however I suspect that will fail as well if not with the same error.

[taliaga]

Hi, that's right, the puller is just supporting pulls with https and validated certificates. And that should remain as the default behavior IMHO.

As you say, this could be a new feature useful for testing. Probably also the puller would have to include a client_config object in the client construction lines and use it to disable certificate validation only for those particular registries.

I would discourage the idea of the --insecure flag to the CLI because this could open significant security risks for the most common workflows. I think having an insecure-registries array in the sarus.json a-la-docker (or podman) that the puller can use as an "exceptional list or registries to retry without certificate validation" would be more interesting. This way, the security risks are a bit more under control of the system administrator (the only capable of touching sarus.json).

[tdhooks]

Totally agree that secure should be the default, and also that keeping the feature at the config/machine/admin level is the right implementation.

See #24

[Madeeks]

Fixed by #24