search

hpi-swa / Squot

Squeak Object Tracker - Version control for arbitrary objects, currently with Git storage
Other
58 stars 29 forks source link

Reusing credentials #239

Open LinqLover opened 5 years ago

LinqLover commented 5 years ago

Hi,

I find myself frequently doing the following workflow: When I need to push to a new project which is missing credentials yet, I explore the working copy of an older repo and copy the credentials from there (I have a quite long GitHub authentication key). Does Squot already support a way to store credentials globally so I do need to reenter every time again?

If not, I would consider such an option a great help.

Best, Christoph

j4yk commented 5 years ago

I understand your concern, but I don't think Squot should roll its own full-fledged credentials management solution. Rather, something like this should be added to Squeak, or a maintained third-party package should be used for it. If you can point me to a good one, I will look into attaching Squot, or rather the Git credentials, to it.

Personally I would love if Squot could access the Git credentials from the Windows credential store, put there by https://github.com/Microsoft/Git-Credential-Manager-for-Windows. I played around with the Windows API via FFI already, but didn't have enough time to design a nice and general API.

LinqLover commented 5 years ago

Sounds like good ideas that will scale well at large! 👍

However, I believe a large audience will only have one or few git accounts. Why don't you - aside from any convenient credentials manager - simply store something like SquitRepository mostRecentCredentials as an initial answer for the credential dialog?

j4yk commented 4 years ago

Coming back to reply to this after a few months (sorry): I don't really want to do this either, since the class would still store credentials. But its instances already do that anyway because we needed any solution at all to make it bearable to work with authentication. So I guess it is reasonable to extend that ugly, unsafe solution a little...

LinqLover commented 4 years ago

Great to here!

FYI, in the meantime I created a little utility for personal use that helped me a lot:

image :-)

j4yk commented 4 years ago

You can always send me a pull request for the credentials reuse... ;-)

LinqLover commented 4 years ago

I don't believe this utility method is suitable for Squot, do you? :)

I'd love to contribute, it's just that my current list of ideas for Squeak consists of a few screen pages, so the waiting time would be really high ...

j4yk commented 4 years ago

No not the utility, but your proposal:

SquitRepository mostRecentCredentials as an initial answer for the credential dialog.

You won't be too late until I might eventually start working on this. Since my Squeak time is limited, your odds are not too small. If you do start working on this, please assign yourself. I will do the same (if I don't forget, since this won't be soon...).

LinqLover commented 4 years ago

Alright, but it really might take me a few months :)

LinqLover commented 2 years ago

Would it be possible to read the credentials from a file named squot.env or something like this which is looked up in FileDirectory default? This would also save me the time from re-entering the credentials every time I clone a repo from a new image.

j4yk commented 2 years ago

Possible, sure. Secure, not so much. That's why I would not like to code it. ;-) You could add some sight protection by applying some symmetric encryption with a key generated and stored once under %APPDATA%.

By the way, your long list of Squeak to dos, do you keep it around publicly, or do you keep it to yourself if the points are not in the form of GitHub issues? ;-) If you published it, some interested soul might be able to do some work for you, although you could not rely on it, of course.

LinqLover commented 2 years ago

Possible, sure. Secure, not so much. That's why I would not like to code it. ;-) You could add some sight protection by applying some symmetric encryption with a key generated and stored once under %APPDATA%.

This sounds fair, provided that the encryption part is not too complex to implement. :-)

By the way, your long list of Squeak to dos, do you keep it around publicly, or do you keep it to yourself if the points are not in the form of GitHub issues? ;-) If you published it, some interested soul might be able to do some work for you, although you could not rely on it, of course.

Ah, this is mainly a collection of pages-long loose Markdown notes which I have trouble enough understanding myself. :-) For some slightly more elaborated notes, we have https://github.com/hpi-swa-lab/squeak/issues, which is private because we mostly use it to collect notes but not to discuss them before they actually addressed. But surely you could get access.

Apart from that, do you really think there would be any interested soul? I suppose that from all Squeak contributors out there, which are unfortunately not that many, almost everyone will have their own agenda but most likely not be bored about "what to do with Squeak". However, I wish the opposite was true, so if you have any reason to believe that there are unused community research, we should probably bring the topic of a public "good first issue" list up on squeak-dev. :-)

LinqLover commented 2 years ago

Some idea: TIL about the ExternalSettings mechanism in Squeak which already provides easy access to arbitrary configurations files in a folder named prefs next to your image file. In theory, Squot could also offer to save your credentials there ... This would be an OS-independent solution.

j4yk commented 2 years ago

Yep, so you would use this instead of %APPDATA%. The security concern is unchanged.