fix(34): WR-03 refuse user info in https git URLs
validateGitURL refused only a password, but GitHub, GitLab and Gitea take a token as the user part of an https URL. Such a URL was printed and written to .gitmodules by git submodule add, and so committed with the application. An https URL with any user info is now refused with a hint to use a credential helper; the user of an ssh URL stays allowed.
This commit is contained in:
@@ -152,7 +152,7 @@ The repository is cloned with your own git setup (credential helpers, SSH keys,
|
||||
|
||||
The plugin's required plugins are looked up in the registry by ID and installed as submodules too. With `--offline` no registry call is made, so every required plugin must already be in `summer.yaml`; a missing one stops the install and is named.
|
||||
|
||||
Only `https://`, `ssh://` and scp-like `user@host:path` addresses are accepted. Git runs with `GIT_ALLOW_PROTOCOL=https:ssh`, so `ext::` and `file::` transports, `file://` and plain `http://` are refused, as is an address that starts with `-` or carries a password (use a credential helper instead).
|
||||
Only `https://`, `ssh://` and scp-like `user@host:path` addresses are accepted. Git runs with `GIT_ALLOW_PROTOCOL=https:ssh`, so `ext::` and `file::` transports, `file://` and plain `http://` are refused, as is an address that starts with `-` or carries a password, and an `https://` address with any user part, since a token there (`https://<token>@github.com/...`) would be written to `.gitmodules` and committed. Use a credential helper instead; the user of an `ssh://` or `user@host:path` address is fine.
|
||||
|
||||
### Updating plugins
|
||||
|
||||
|
||||
Reference in New Issue
Block a user