Open lisael opened 3 years ago
Currently using BUPSTASH_REPOSITORY_COMMAND is a form of pluggable transport that is only restricted by what you can implement or proxy a generic command runner over.
That being said, I am definitely open to making an https based tunnel of some sort that is integrated with bupstash, either directly or via a scheme plugin system
I think the easiest way given the way that bupstash is designed, is to have a protocol that is essentially just a remote command runner, forwarding stderr/stdout/stdin and the exit code much like ssh currently does and then use this to forward the execution of 'bupstash serve' over https.
I also think in the meantime, a guide on how to proxy bupstash via the BUPSTASH_REPOSITORY_COMMAND might also be helpful to people.
I think 'HTTP CONNECT', websocket or webRTC data channels are other ways we may tunnel over https, depending on if this meets the end user requirements (I don't have too much experience bypassing restrictive network environments).
To elaborate further, currently BUPSTASH_REPOSITORY='ssh://bupstash.io/my/repo'
is equivalent to the following:
BUPSTASH_REPOSITORY_COMMAND='ssh bupstash.io bupstash serve /my/repo'
I propose we make BUPSTASH_REPOSITORY=https://bupstash.io/my/repo
equivalent to BUPSTASH_REPOSITORY_COMMAND='bupstash https-connect https://bupstash.io/my/repo'
.
Then the https-connect sub command is capable of doing the equivalent of what ssh is doing for 'bupstash serve', that is forward stdout/stderr signals and exit codes via the http server.
This generalizes so a websocket based connection might be BUPSTASH_REPOSITORY_COMMAND='bupstash wss-connect wss://bupstash.io/my/repo'
.
I think this command forwarding protocol would be a generally useful tool and is not necessarily totally bupstash specific.
This is another interesting reference - https://github.com/google/huproxy. I am not totally satisfied with requiring the user to configure 2 different auth methods (https AND ssh), or requiring that they install too much third party stuff other than an http server.
https://github.com/andrewchambers/srcp This repository is a draft protocol for dealing with forwarding a command over websockets such that it would work similarly to ssh.
In some environments (enterprise network, wifi hostspots, poor "internet" mobile plans...), ssh is blocked. HTTPS is almost always open. Allow
https://
scheme in repository URL.This could be generalized with a plugin framework that chooses the concrete transport layer based on the scheme.
Well, after digging into the code, it seems that https support would require to write the server first and then to add a
bupstash serve
mode that proxifies fifo IPC to/from this server.Another option would be a
bupstash serve
mode that works on a temporary local repo and write the changes on a very simple GET/PUT/DELETE HTTP-REST sever with authentication. At this point webdav is an option too.