Fork me on GitHub

Hi, I know it's not tools.deps per-se


but related, I discovered pulling private repositories with gitlibs was not possible with HTTP auth


when using github tokens for automation tooling this can be an issue for finer grained repo access control


I have the following patch if you think this is worth considering:


We don't want any credentials to show up in deps.edn - with this you'd have plaintext passwords in git urls wouldn't you?


we've had a lot of discussion about https auth (, and I think the main question to resolve is whether we keep doing jgit or whether we start shelling out to git and I've been trying to get that decision up to the top of my stack (and even briefly did so a couple months ago before I was interrupted).


If we're using git auth, you have a few different choices - I don't think anyone wants to manually type in passwords every time (or any time) and that ruins pretty much any automation workflow, but you can use "store" mode (stored in cleartext file), or "oskeychain" mode on mac, or the "Git Credential Manager for Windows" mode on windows which uses Windows Credential Store, or I think there may be other more generic password oracle options for Git.


If we're using jgit, then it's a matter of where we can read pws from - again you talk to os-dependent things like the keychain, credentials store, etc but we're probably building that ourselves (or maybe something exists, don't know)


But my main constraint is, don't put it in deps.edn.


@alexmiller OK understood. A possible alternative is to go with the NetRCCredentialsProvider. Shelling out to git would solve these issues


I'm using tools.gitlibs here from outside of tdeps which is why having the tokens in the config makes sense to me in this case but I get that for tdeps not necessarily.


I'll drop my commit for now, thanks for the clarification


Looking at the issue, it's indeed shell-out to git or a custom CredentialsProvider implementation which looks for credentials.edn