git-credential doesn't work with host have colon ":"

sgn commented 3 years ago

Summary

I'm testing for gopasspw/gopass#1670 My usual workflow involve git-sendemail and I'm using pass to store my password. When git-sendemail invoked, it will invoke a git-credential helper to get my password. Usually, I use this script https://raw.githubusercontent.com/sgn/dotfiles/414ac02ae383b52b4713b2870244afeebdcdbe0d/bin/git-credential-pass

I tried gopass but it doesn't work because the host sent by git has a colon

Steps To Reproduce

gopass-git-credentials get <<_EOF
protocol=smtp
host=smtp.gmail.com:465
username=email@gmail.com
<_EOF

Expected behavior

credential filled

Environment

OS: Linux 5.10.3
OS version: [uname -a]
gopass Version: e3d38c3c81a7e62778b2f78244aecf58df6799df
Installation method: source

Additional context

AnomalRoil commented 3 years ago

This is strange.

Did you try with the mime setting set to false in your config?

It might be a clash with the mime type or with the KV type.

sgn commented 3 years ago

Did you try with the mime setting set to false in your config?

I don't know. I clone a fresh gopass repository to try. Today is my first contact with gopass.

It might be a clash with the mime type or with the KV type.

With this debug line:

diff --git a/cmd/git-credential-gopass/git-credential.go b/cmd/git-credential-gopass/git-credential.go
index 03d0e00f..85e7101f 100644
--- a/cmd/git-credential-gopass/git-credential.go
+++ b/cmd/git-credential-gopass/git-credential.go
@@ -141,6 +141,7 @@ func (s *gc) Get(c *cli.Context) error {
    }
    // try git/host/username... If username is empty, simply try git/host
    path := "git/" + fsutil.CleanFilename(cred.Host) + "/" + fsutil.CleanFilename(cred.Username)
+   fmt.Fprintln(os.Stderr, path)
    if _, err := s.gp.Get(ctx, path, "latest"); err != nil {
        // if the looked up path is a directory with only one entry (e.g. one user per host), take the subentry instead
        ls, err := s.gp.List(ctx)

I see this log:

git/smtp.gmail.com_465/email@gmail.com

So, at least I can have a workaround (actually, I prefer pass :-p, since I have better control over what I can do with git :-p).

AnomalRoil commented 3 years ago

Just to make sure, please try setting: gopass config mime false

sgn commented 3 years ago

$ gopass config mime && cat /tmp/log  && ./cmd/git-credential-gopass/git-credential-gopass get </tmp/log
mime: false
protocol=smtp
host=smtp.gmail.com:465
username=username@gmail.com
git/smtp.gmail.com_465/username@gmail.com

sgn commented 3 years ago

I think this line is what causes my problem:

path := "git/" + fsutil.CleanFilename(cred.Host) + "/" + fsutil.CleanFilename(cred.Username)

I think we ~need to~ should document this limitation, i.e. if there is a colon (for port) in host, replaces it with _, and move on.

dominikschulz commented 3 years ago

Yes, we should document that we can not allow arbitrary characters in the name of the secrets as the are mapped to filesystem paths.

Feel free to send a PR documenting it in the place you'd expect to find this information.

jensklose commented 3 years ago

Imo this is still an error.

PASS way:

$ pass insert git/host.com:2299
Enter password for git/host.com:2299:
Retype password for git/host.com:2299:
$ pass list
Password Store
└── git
    └── host.com:2299

Plain Gopass:

$ gopass insert git/githost.org:3444
Enter password for git/githost.org:3444:
Retype password for git/githost.org:3444:
Warning: Password is too short
/projects/gopass-fork$ gopass list
gopass
├── git/
│   └── githost.org:3444

Credential Store:

$ git-credential-gopass store <<_EOF
> protocol=smtp
> host=smtp.gmail.com:465
> username=email@gmail.com
> _EOF
$ gopass list
gopass
├── git/
│   └── smtp.gmail.com_465/
│       └── email@gmail.com

The hostname part is from a trustworthy source -> Git. So we could fix it quickly. But it would force a new major version.

dominikschulz commented 3 years ago

@jensklose Maybe it's just the fsutil.CleanFilename method that needs some improvements. Is filtering out : really necessary / appropriate?

AnomalRoil commented 3 years ago

I'm guessing that's a limitation where we need to ask ourselves how much cross platform we wanna be. Colons are legal in Unix filenames, but illegal on Windows.

Should we clean them away only on Windows?

Pass being meant as a Unix tools doesn't have the same problem I guess. On my side I'd be fine with it being a documented exception for Windows only, but we might want to test how it works with git repo that have files that contain colons on different platforms first?

jensklose commented 3 years ago

I guess this is a gopass problem too. Windows version: Error: failed to write secret "test/github.berlin:4242": failed to add "test/github.berlin:4242.gpg" to git: exit status 128: fatal: pathspec 'test/github.berlin:4242.gpg' did not match any files

... but it is storable in nonWin Version, hmm.

dominikschulz commented 3 years ago

I have to admit I'm at a loss how the git credential helper protocol works.

Why can't we look up a secret if we consistently replace a colon by an underscore? When git presents host=smtp.gmail.com:467 we'd translate it to git/smtp.gmail.com_467, look up the secret value and return that, correct?

If not: Could someone provide me a more complete example of how that works?

jensklose commented 3 years ago

Why can't we look up a secret if we consistently replace a colon by an underscore?

Because, we don't consistently replace. For example:

you start with pass on linux (laptop) [colons are colons] - time...
you decide to switch to gopass (linux laptop) [colons are colons], all fine - time...
you decide to use git-gredential-helper (linux laptop) BUMM -> [colons are underscore -> not found] interactive mode new entries are generated
you decide to use your windows desktop BUMM -> untested you can't import the git repo

jensklose commented 3 years ago

Although these should be rare exceptions, inconsistent behavior is a problem. imo

dominikschulz commented 3 years ago

So we could try a fallback location to work around this issue (i.e. one where colons are not replaced, unless we're on Windows). But then we'd add a special case just for this ... sigh

apprehensions commented 7 months ago

I'm still experiencing whatever this problem is, alongside the problem of that there is no documentation of how this works, so when i set it up and use git send-email, nothing works and no directions are given.

DKdunlop commented 6 months ago

github becomes worst

apprehensions commented 6 months ago

My problem is solved with #74

gopasspw / git-credential-gopass