Allow creation and unlock of SecretService keyring on headless systems.

[matthewdva]

This pull request will enable osc to unlock a gnome-keyring when running on a headless system/session.

This problem is the supporting python modules for SecretStorage and dependencies do not have method for unlocking a gnome-keyring when not run from a GUI. As a result osc fails with python trace-back messages when attempting to use a gnome-keyring on an headless session.

This request alone is not completely self contained. To be successful both a keyring daemon and dbus will need to be running. Starting these are outside the scope. This request will allow for a graceful error/exit in this situation.

I am open to suggestions on rewording the the error messages if needed.

[pep8speaks]

Hello @matthewdva! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

There are currently no PEP 8 issues detected in this Pull Request. Cheers! 🍻

Comment last updated at 2022-03-12 00:17:24 UTC

[lgtm-com]

This pull request introduces 5 alerts when merging 78c0adc into fe6a50f - view on LGTM.com

new alerts:

• 3 for Unused local variable
• 1 for Testing equality to None
• 1 for Except block handles 'BaseException'

[marcus-h]

First of all, sorry for the delay!

On 2022-02-21 15:49:14 -0800, matthewdva wrote: This pull request will enable osc to unlock a gnome-keyring when running on a headless system/session. This problem is the supporting python modules for SecretStorage and dependencies do not have method for unlocking a gnome-keyring when not run from a GUI. As a result osc fails with python trace-back messages when attempting to use a gnome-keyring on an headless session. This request alone is not completely self contained. To be successful both a keyring daemon and dbus will need to be running. Starting these are outside the scope. This request will allow for a graceful error/exit in this situation. I am open to suggestions on rewording the the error messages if needed.

Hmm I'm not sure if this is something we should fix in osc. I would rather suggest that you either fix this in python-keyring itself or that you provide your own "class HeadlessSecretServiceKeyring(keyring.backends.SecretService.Keyring)" backend that provides the desired functionality. Then, users can simply install your additional keyring backend and select it when configuring osc. What do you think?

[matthewdva]

Marcus,     I agree with you.  The overall best place for this functionality is likely in the python-keyring or dependent packages.  To be embarrassingly transparent I explored that option but could not figure out a good patch to add this functionality.  I am not confident in my skill to suggest a patch there.  I also acknowledge my lack of skill is not a strong justification for this approach.     My initial thought for this feature was to write a plug-in for osc.  I may be using the incorrect terminology but I think that would be similar to your second suggestion.  As with my previous explanation, I was unsure how to do that.  I come more from an ops/administration background.  My strongest language is perl. Python is very much WIP for me.     I don't mind taking the separate class approach but would need some guidance on how to actually implement it.  I am hesitant to ask for this level of help as I did not want to be a burden on you all. If you can point me at some examples I am happy to explore this approach further.    Would you like for me to close this PR? ------------------------------------------------------------------------ */Matthew Davis/*

…

On 3/22/2022 9:48 AM, Marcus Hüwe wrote: First of all, sorry for the delay! On 2022-02-21 15:49:14 -0800, matthewdva wrote: > This pull request will enable osc to unlock a gnome-keyring when running on a headless system/session. > > This problem is the supporting python modules for SecretStorage and dependencies do not have method for unlocking a gnome-keyring when not run from a GUI. As a result osc fails with python trace-back messages when attempting to use a gnome-keyring on an headless session. > > This request alone is not completely self contained. To be successful both a keyring daemon and dbus will need to be running. Starting these are outside the scope. This request will allow for a graceful error/exit in this situation. > > I am open to suggestions on rewording the the error messages if needed. Hmm I'm not sure if this is something we should fix in osc. I would rather suggest that you either fix this in python-keyring itself or that you provide your own "class HeadlessSecretServiceKeyring(keyring.backends.SecretService.Keyring)" backend that provides the desired functionality. Then, users can simply install your additional keyring backend and select it when configuring osc. What do you think? — Reply to this email directly, view it on GitHub <#1005 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADXRYDVWTZ4UB5DIV7UOPZ3VBHFRNANCNFSM5O7262JA>. You are receiving this because you were mentioned.Web Bug from https://github.com/notifications/beacon/ADXRYDXNLLN3V66YGNXCA4LVBHFRNA5CNFSM5O7262JKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOIALEV2Y.gifMessage ID: ***@***.***> [ { ***@***.***": "http://schema.org", ***@***.***": "EmailMessage", "potentialAction": { ***@***.***": "ViewAction", "target": "#1005 (comment)", "url": "#1005 (comment)", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { ***@***.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[marcus-h]

On 2022-03-23 06:29:34 -0700, matthewdva wrote:     I agree with you.  The overall best place for this functionality is likely in the python-keyring or dependent packages.  To be embarrassingly transparent I explored that option but could not figure out a good patch to add this functionality.  I am not confident in my skill to suggest a patch there.

Well, if you have something that works for you and you think others could benefit from it, then just submit a patch. In the worst case, it is rejected and people will/should tell you why. In the best case, it is accepted and others benefit fromt it:) <SNIP>

    I don't mind taking the separate class approach but would need some guidance on how to actually implement it.  I am hesitant to ask for this level of help as I did not want to be a burden on you all. If you can point me at some examples I am happy to explore this approach further.

Writing an external keyring plugin is not really difficult. For instance, you could use [1] as a template. Basically, what you need is something like this (untested!): $> cat headless/SecretService.py keyring.backends.SecretService import Keyring class HeadlessSecretServiceBackend(Keyring) def _start_keyring(self): <your implementation goes here> def get_password(self, *args, **kwargs): self._start_keyring() return super().get_password(*args, **kwargs) def set_password(self, *args, **kwargs): self._start_keyring() super().set_password(*args, **kwargs) def delete_password(self, *args, **kwargs): self._start_keyring() super().delete_password(*args, **kwargs) $> (of course, you could use a decorator to make it more pythonic) $> cat setup.py ... setup( ... entry_points={ 'keyring.backends': [ 'Headless/HeadlessSecretServiceKeyring = headless/SecretService:HeadlessSecretServiceBackend', ] } ... ) ... $> (just to "register" your new backend.) In order to test your stuff with osc, you could do something like $> export PYTHONPATH=out $> mkdir out $> python3 setup.py develop -d out $> osc -c my_test_oscrc ls When osc asks for a credentials manager, you could select your new backend. Hope this helps a bit. [1] https://github.com/marcus-h/python-keyring-keyutils