git-remote-annex: Support urls like annex::https://example.com/foo-repo
Using the usual url download machinery even allows these urls to need http basic auth, which is prompted for with git-credential. Which opens the possibility for urls that contain a secret to be used, eg the cipher for encryption=shared. Although the user is currently on their own constructing such an url, I do think it would work. Limited to httpalso for now, for security reasons. Since both httpalso (and retrieving this very url) is limited by the usual annex.security.allowed-ip-addresses configs, it's not possible for an attacker to make one of these urls that sets up a httpalso url that opens the garage door. Which is one class of attacks to keep in mind with this thing. It seems that there could be either a git-config that allows other types of special remotes to be set up this way, or special remotes could indicate when they are safe. I do worry that the git-config would encourage users to set it without thinking through the security implications. One remote config might be safe to access this way, but another config, for one with the same type, might not be. This will need further thought, and real-world examples to decide what to do.
This commit is contained in:
parent
3f33616068
commit
0155abfba4
3 changed files with 103 additions and 33 deletions
|
@ -17,3 +17,8 @@ shortener can be used. --[[Joey]]
|
|||
> Perhaps it could be limited to safe special remotes. httpalso is surely
|
||||
> safe in this context. Would anything else be? Any external special
|
||||
> remotes? --[[Joey]]
|
||||
|
||||
>> Implemented this, but it was being a bit hard to handle a redirect to an
|
||||
>> annex:: url, and in any case with httpalso, the user has a web server
|
||||
>> they can host files on. So made the url be downloaded as a file, and
|
||||
>> the first line contains the complete annex:: url. [[done]]
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue