Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using git credential store seems unnecessarily insecure #5

Open
xet7 opened this issue Jul 31, 2018 · 4 comments
Open

Using git credential store seems unnecessarily insecure #5

xet7 opened this issue Jul 31, 2018 · 4 comments

Comments

@xet7
Copy link
Member

xet7 commented Jul 31, 2018

From @astraw on September 13, 2015 9:41

Hi, like the others reporting issues: first off, many thanks! This package of gitlab for sandstorm is awesome.

When creating a new repo with gitlab-sandstorm, the copy-paste commands use git credential store, which stores the passwords unencrypted on disk. I have just verified that removing the string -c credential.helper=store from the commands uses the git default credential helper. In my case, I used the osxkeychain helper and confirmed that my password was saved to the OS X keychain and not in plaintext into ~/.git-credentials. I therefore think that gitlab-sandstorm should not suggest to use -c credential.helper=store.

(Interestingly, shortened -- and therefore probably corrupted -- passwords saved to the git credential store also make it into the OS X keychain. But that seems to be unrelated to both gitlab and sandstorm.)

Copied from original issue: dwrensha/gitlab-sandstorm#8

@xet7
Copy link
Member Author

xet7 commented Jul 31, 2018

From @dwrensha on September 13, 2015 14:29

Hi!
The tricky part about the keychain helpers is that they are platform-dependent, and most people probably don't actually have a default helper configured. So I think we would need to detect the OS of the browser before choosing the text to display, and we would probably want to provide a way for the user to select a platform for when our detection gets it wrong.
Alternatively, we could somehow display some supplementary help text that teaches the user about more secure options.

@paulproteus might have more to say about this.

@xet7
Copy link
Member Author

xet7 commented Jul 31, 2018

From @paulproteus on September 13, 2015 17:10

There is absolutely a trade-off between "giving the user advice that will definitely work on all computers" and "giving the user advice that will work best for them knowing how their computer is set up." I struggle with this, because I would prefer we can do the latter for everyone, but I also don't want to create obstacles that make our software hard to use through complicated configuration.

BTW, hi @astraw ! I've very much appreciated your work related to Debian, like stdeb.

What I would prefer would be if there were a way we could write:

git -c credential.helper=use-system-default-but-use-store-if-unconfigured credential approve

without having to install something on the user's system. I'd love to see git change to support something like that. Is that something you'd be willing to bring up with the git team? If so I'd be super grateful.

And/or maybe we could support a Sandstorm-wide preference to choose what credential helper the user wants to use. (Note that a Sandstorm-wide preference is not something that the platform really supports yet! But maybe it could.)

Hope that rambling helps. Thanks @astraw for filing this bug.

@xet7
Copy link
Member Author

xet7 commented Jul 31, 2018

From @pjz on November 19, 2015 13:58

is there no way to give gitlab a pubkey so ssh becomes an option?

@xet7
Copy link
Member Author

xet7 commented Jul 31, 2018

From @dwrensha on November 19, 2015 14:5

Hi @pjz. Sandstorm doesn't yet have a good way to allow GitLab to expose an ssh server. That might be changing soonish as we work on the Powerbox, but for now the main way that apps can export services to the outside world is through HTTP APIs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant