HTTP Support for Library about singularity HOT 3 CLOSED

It makes sense that with the recent addition of accepting hostnames in library URIs via library://hostname/user/collection/container, the existing --nohttps should apply to permit http connections to the explicit hostname (it doesn't currently).

Agreed.

I was thinking more along the lines of being able to remote add --insecure an endpoint URI, that will then use http instead of https to do the service discovery. This remote add --insecure actually already exists for the standalone keyserver stuff that was added by Cedric sometime ago.

This sounds like a good, explicit option to solve the problem.

We could also add a rule that only an insecure endpoint is allowed to redirect to http:// services. This would stop someone having a endpoint config hosted over https:// that redirects to an insecure http:// library/builder/token service etc.

I'm not sure this is necessary. If the list of endpoints is retrieved with TLS, I think it's reasonable for us to trust its contents. An admin might have some valid reason for wanting a specific endpoint to be HTTP in their environment?

from singularity.

I've been looking at this a bit, and have the following thoughts.....

We can already specify to pull/push from an http library URI on the pull/push command via --library http://library.example.com.

It makes sense that with the recent addition of accepting hostnames in library URIs via library://hostname/user/collection/container, the existing --nohttps should apply to permit http connections to the explicit hostname (it doesn't currently).

The situation that the Hinkskalle patch is trying to address is more complex - it's where the remote endpoint configuration (JSON pointing out to individual service URLs), is hosted on an http endpoint. The JSON config there could actually return an http:// URL for a library service, but we would never get that if the JSON is served over http:// as that retrieval is forced to https://.

Grabbing the endpoint JSON is something that doesn't happen at the individual command level, so grafting on http:// handling for this to the --nohttps flag isn't very appealing.

I was thinking more along the lines of being able to remote add --insecure an endpoint URI, that will then use http instead of https to do the service discovery. This remote add --insecure actually already exists for the standalone keyserver stuff that was added by Cedric sometime ago.

We could also add a rule that only an insecure endpoint is allowed to redirect to http:// services. This would stop someone having a endpoint config hosted over https:// that redirects to an insecure http:// library/builder/token service etc.

Thoughts @tri-adam ?

from singularity.

Broken into #236 and #237 as these are two somewhat independent units of work for this.

from singularity.