Not working on CentOS 7

[JoeMcMahon87]

Expected Behavior

I'm developing on a CentOS virtual machine and I expect gimme-aws-creds to work in order to get access to multiple AWS accounts protected by Okta MFA.

Current Behavior

I get the following error:

Traceback (most recent call last): File "/home/jmcmahon/.local/bin/gimme-aws-creds", line 17, in GimmeAWSCreds().run() File "/home/jmcmahon/.local/lib/python3.6/site-packages/gimme_aws_creds/main.py", line 469, in run self._run() File "/home/jmcmahon/.local/lib/python3.6/site-packages/gimme_aws_creds/main.py", line 802, in _run for data in self.iter_selected_aws_credentials(): File "/home/jmcmahon/.local/lib/python3.6/site-packages/gimme_aws_creds/main.py", line 773, in iter_selected_aws_credentials for role in self.aws_selected_roles: File "/home/jmcmahon/.local/lib/python3.6/site-packages/gimme_aws_creds/main.py", line 672, in aws_selected_roles selected_roles = self._get_selected_roles(self.requested_roles, self.aws_roles) File "/home/jmcmahon/.local/lib/python3.6/site-packages/gimme_aws_creds/main.py", line 663, in aws_roles self.saml_data['SAMLResponse'], File "/home/jmcmahon/.local/lib/python3.6/site-packages/gimme_aws_creds/main.py", line 654, in saml_data self._cache['saml_data'] = saml_data = self.okta.get_saml_response(self.aws_app['links']['appLink']) File "/home/jmcmahon/.local/lib/python3.6/site-packages/gimme_aws_creds/main.py", line 647, in aws_app self._cache['aws_app'] = aws_app = self._get_selected_app(self.conf_dict.get('aws_appname'), self.aws_results) File "/home/jmcmahon/.local/lib/python3.6/site-packages/gimme_aws_creds/main.py", line 600, in aws_results self.auth_session File "/home/jmcmahon/.local/lib/python3.6/site-packages/gimme_aws_creds/main.py", line 582, in auth_session auth_result = self.okta.auth_session(redirect_uri=self.conf_dict.get('app_url')) File "/home/jmcmahon/.local/lib/python3.6/site-packages/gimme_aws_creds/okta.py", line 160, in auth_session login_response = self.auth() File "/home/jmcmahon/.local/lib/python3.6/site-packages/gimme_aws_creds/okta.py", line 149, in auth flow_state = self._login_username_password(None, self._okta_org_url + '/api/v1/authn') File "/home/jmcmahon/.local/lib/python3.6/site-packages/gimme_aws_creds/okta.py", line 327, in _login_username_password creds = self._get_username_password_creds() File "/home/jmcmahon/.local/lib/python3.6/site-packages/gimme_aws_creds/okta.py", line 872, in _get_username_password_creds password = keyring.get_password(self.KEYRING_SERVICE, username) File "/home/jmcmahon/.local/lib/python3.6/site-packages/keyring/core.py", line 55, in get_password return get_keyring().get_password(service_name, username) File "/home/jmcmahon/.local/lib/python3.6/site-packages/keyring/backends/chainer.py", line 51, in get_password password = keyring.get_password(service, username) File "/home/jmcmahon/.local/lib/python3.6/site-packages/keyring/backends/libsecret.py", line 62, in get_password items = Secret.password_search_sync( File "/usr/lib64/python3.6/site-packages/gi/module.py", line 139, in getattr self.name, name)) AttributeError: 'gi.repository.Secret' object has no attribute 'password_search_sync'

Context

Happens when I run gimme-aws-creds with no parameters

Your Environment

• App Version used: 2.4.3
• Operating System and version: CentOS 7

[jmtscaff]

Had the same issue and seems that keyring lib is picking up libsecret backend. You can check which backend by running python... here is my output:

$ python3
Python 3.6.8 (default, Mar 18 2021, 08:58:41)
[GCC 8.4.1 20200928 (Red Hat 8.4.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import keyring
>>> keyring.get_keyring()
<keyring.backends.libsecret.Keyring object at 0x7fcdb126dda0>

As a workaround I disabled keyring by using the Fail key ring backend:

export KEYRING_CONFIG_PATH=$(python3 -c "import keyring.util.platform_; print(keyring.util.platform_.config_root())") &&
mkdir -p ${KEYRING_CONFIG_PATH} && {
cat >${KEYRING_CONFIG_PATH}/keyringrc.cfg <<EOF
[backend]
default-keyring=keyring.backends.fail.Keyring
EOF
} && unset KEYRING_CONFIG_PATH

Hope this helps

[tculp]

I have someone reporting similar behavior on Ubuntu 18.04, and the result of the backend check is

>>> import keyring
>>> keyring.get_keyring()
<keyring.backends.chainer.ChainerBackend object at 0x7fd1cc8816d8>

Disabling the keyring with export PYTHON_KEYRING_BACKEND="keyring.backends.null.Keyring" as a workaround worked for them.