decode('base64') add a carriage return

[rgarrigue]

Hi guys

I spent half of the morning trying to get a slurp / authorized_key to work. I'm now 99% sure it's about a carriage return added by decode('base64')

This works for me
key="{{sillage_key.content.decode('base64').rstrip('\r\n')}}"

This doesn't
key="{{sillage_key.content.decode('base64')}}"

Here is the -vvvv output

<192.168.111.222> ESTABLISH CONNECTION FOR USER: root on PORT 22 TO 192.168.111.222
<192.168.111.222> EXEC /bin/sh -c 'mkdir -p $HOME/.ansible/tmp/ansible-1386845066.63-60882265649411 && echo $HOME/.ansible/tmp/ansible-1386845066.63-60882265649411'
<192.168.111.222> REMOTE_MODULE authorized_key user=genois key="ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA05QAur3vsVo0Ta9Vy6eebuoxPsCAiRh/6C6jmRHIhFgCcoBqS8Dwxm243HY0Sy0kiiLHxamUaK3HHYlFO4+3aHDOXHAhuhT/ELM6+atFIk+3GtZjaxgEjEldBsfcPJIlMWvw+ktJanWEac+tKnNSjj3+Fj6sm0TaLA5x6HObRMroYl+rg9U5aIIyKJyz1PzVKbVKX4n/wCIP1KE2sCWwA4oLgm1VU2nHlcBk937EYt9MU/BxkuxbPbTAaQgxPWW4QNFIYwnSPQy3V4pHTUUz+zvjPJelTp6BDzpNy/dU9wB4hP2PqdbqrYdx3nNiZBfpU+hNJe3IER6URG/bMR9ivw== sillage@localhost
" manage_dir=no
<192.168.111.222> PUT /tmp/tmplKh4XM TO /root/.ansible/tmp/ansible-1386845066.63-60882265649411/authorized_key
<192.168.111.222> EXEC /bin/sh -c '/usr/bin/python /root/.ansible/tmp/ansible-1386845066.63-60882265649411/authorized_key; rm -rf /root/.ansible/tmp/ansible-1386845066.63-60882265649411/ >/dev/null 2>&1'
failed: [lyr] => (item=genois) => {"failed": true, "item": "genois"}
msg: invalid key specified:

Note the new line between lines 3 and 4 that shouldn't be.

I got the issue with both devel and 1.4.1. Found the rstrip fix on 1.4.1, didn' t tried it on devel.

[rgarrigue]

And Zart on irc gave me {{ sillage_key.content|b64decode|trim }} which is working too.

[jctanner]

@rgarrigue how is sillage_key.content populated in your case?

[rgarrigue]

@jctanner : with the key's hash, without ssh-rsa header and comment.

You've the debug on this gist, comment 3: https://gist.github.com/rgarrigue/7925446. Don't pay attention on hash difference between comments, I was testing on 2 differents VMs.

[azaghal]

Well, figured I could start looking through the issue history to see if I can fix something, sorry if I am reviving an old issue or similar. From what I can tell, this issue is not reproducible since v1.5.0.

I also think that the decode call was not actually appending anything. This was tested via copy module combined with content parameter. The behaviour of authorized_key module probably got a bit smarter afterwards, so now it trims the key itself (only based on experimentation, not from reading the code).

Perhaps the issue should be closed?

[bcoca]

closing as per above