ACCESS-NRI / accessdev-Trac-archive

Archive accessdev Trac contents as issues
Apache License 2.0
0 stars 0 forks source link

Problem with gpg-agent caching MOSRS password #259

Open penguian opened 8 years ago

penguian commented 8 years ago

| by mrd599@nci.org.au


On Friday 18th December Ilia reported that caching the MOSRS password with gpg-agent on accessdev was failing.

% . bin/mosrs-setup-gpg-agent
Please enter your Met Office Science Repository Service Password:
Subversion: password has been cached
Subversion: checking access ...
svn: E215004: Authentication failed and interactive prompting is disabled; see the --force-interactive option
svn: E215004: Unable to connect to a repository at URL 'https://code.metoffice.gov.uk/svn/test'
svn: E215004: No more credentials or we tried too many times.
Authentication failed

Also failed in the same way for me.


Issue migrated from trac:259 at 2024-01-31 18:22:43 +1100

penguian commented 8 years ago

@martin.dix@anu.edu.au commented


Modified mosrs-setup-gpg-agent script to add options --debug-level guru --log-file $HOME/glog to the gpg-agent command.

Looking at the glog file suggests that the caching seems to have worked and that the agent is responding

gpg-agent[8376.7] DBG: <- PRESET_PASSPHRASE 2be6a67d04b1c8c6d879daafa52fd762 -1 6537474F3162637E4467516D256B664B
2015-12-21 09:58:50 gpg-agent[8376] DBG: agent_put_cache `2be6a67d04b1c8c6d879daafa52fd762' requested ttl=-1 mode=1
gpg-agent[8376.7] DBG: -> OK
...
gpg-agent[8376.7] DBG: <- GET_PASSPHRASE --data --no-ask 2be6a67d04b1c8c6d879daafa52fd762 X Password+for+'martindix':+ Enter+your+Subversion+password+for+<https://code.metoffice.gov.uk:443>+Met+Office+Code
2015-12-21 09:58:53 gpg-agent[8376] DBG: agent_get_cache `2be6a67d04b1c8c6d879daafa52fd762'...
2015-12-21 09:58:53 gpg-agent[8376] DBG: ... hit
gpg-agent[8376.7] DBG: -> [Confidential data not shown]
gpg-agent[8376.7] DBG: -> [Confidential data not shown]
gpg-agent[8376.7] DBG: <- BYE
gpg-agent[8376.7] DBG: -> OK closing connection

Now running

% svn ls  https://code.metoffice.gov.uk/svn/test

the log file suggests it's not in the cache at all

gpg-agent[8376.7] DBG: <- GET_PASSPHRASE --data 2be6a67d04b1c8c6d879daafa52fd762 X Password+for+'martindix':+ Enter+your+Subversion+password+for+<https://code.metoffice.gov.uk:443>+Met+Office+Code
2015-12-21 10:02:19 gpg-agent[8376] DBG: agent_get_cache `2be6a67d04b1c8c6d879daafa52fd762'...
2015-12-21 10:02:19 gpg-agent[8376] DBG: ... miss
2015-12-21 10:02:19 gpg-agent[8376] command get_passphrase failed: Bad passphrase
gpg-agent[8376.7] DBG: -> ERR 67108875 Bad passphrase <GPG Agent>
penguian commented 8 years ago

@martin.dix@anu.edu.au edited the issue description

penguian commented 8 years ago

@martin.dix@anu.edu.au changed status from new to assigned

penguian commented 8 years ago

@martin.dix@anu.edu.au changed owner from ` tomrd599`

penguian commented 8 years ago

@martin.dix@anu.edu.au commented


http://unix.stackexchange.com/questions/71135/how-can-i-find-out-what-keys-gpg-agent-has-cached-like-how-ssh-add-l-shows-yo explains how to use the gpg-connect-agent command to check just what's cached. Following this,

% CACHEID="ThisIsTheTrickyPart"
% ERRSTR="Error+string+goes+here"
% PMTSTR="Prompt"
% DESSTR="Description+string+goes+here"
% echo 1234 | /usr/libexec/gpg-preset-passphrase -c $CACHEID
% echo "GET_PASSPHRASE --data $CACHEID $ERRSTR $PMTSTR $DESSTR" | gpg-connect-agent
D 1234
OK

shows that the agent is working ok. However my (recently changed) MOSRS password contains a % character and gpg-agent seems to be treating this as some sort of special character.

% echo 12%4 | /usr/libexec/gpg-preset-passphrase -c $CACHEID
% echo "GET_PASSPHRASE --data $CACHEID $ERRSTR $PMTSTR $DESSTR" | gpg-connect-agent
D 12%254
OK

Changing to password without a % worked ok.

My desktop machine cached the password with gnome-keyring and didn't have this problem.

penguian commented 8 years ago

@scott.wales@bom.gov.au commented


Hi Martin,

The GPG agent client that the setup script is using requires special characters to be percent encoded, in a similar manner to URLs - e.g. %20 for a space.

I've got a prototype Python client that should handle this, will give it a test to see if it properly handles special characters

https://en.wikipedia.org/wiki/Percent-encoding