Comments (3)
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 explicithostname
(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. Thisremote 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.
Related Issues (20)
- Support OCI-SIF data-container in --bind & --mount
- Support squashfs->tar in push of an OCI-SIF data container
- Remove CentOS 7 from CI matrix:
- Remove EL7, SLES 11 examples
- Remove Yum CentOS7 bootstrap tests
- Remove CentOS 7 regression test for issue 5250 HOT 1
- Remove CentOS 7 install specifics:
- Remove kernel version as proxy requirement for OCSP test
- Remove EL7 test case / handling of old ld listing HOT 1
- oci: fixed descriptor capacity for OCI-SIF prevents pulling some images
- singularity build --fakeroot fails with free(): invalid pointer while spawning RPC server HOT 3
- Pip install uses too much disk space - error with /tmp as tmpfs HOT 2
- Unknown image format/type in nextflow pipeline HOT 5
- Drop remaining direct containers/common usage
- CNI dhcp plugin does not work - netns bind issues
- oci-sif: inefficent copies of oci (layout) and tarball images
- delete sandbox
- allow user ns in singularity.conf
- allow ipc ns in singularity.conf
- e2e: OCI CustomHomePreservesRootShell failure
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from singularity.