Activity log for bug #1504646

Date Who What changed Old value New value Message
2015-10-09 18:59:13 Christopher Solis bug added bug
2015-10-12 21:25:09 Christopher Solis description When doing a curl request for retrieving a secret with the content-type 'application/octet-stream'. No problem arises. (Barbican)christopher@christopher-VirtualBox:~/openrcs$ curl -H 'X-Auth-Token:fa43522258df4aa0896fb8cf71e26a4d' -H 'Accept:application/octet-stream' http://localhost:9311/v1/secrets/871b6f51-4198-40e1-ab1e-5c226af7d3e4 �m��m��m�(Barbican)christopher@christopher-VirtualBox:~/openrcs$ With the barbicanclient however, an error arises. (Barbican)christopher@christopher-VirtualBox:~/openrcs$ barbican secret get -p -t 'application/octet-stream' http://localhost:9311/v1/secrets/871b6f51-4198-40e1-ab1e-5c226af7d3e4 Starting new HTTP connection (1): localhost Starting new HTTP connection (1): localhost 'utf8' codec can't decode byte 0xd7 in position 0: invalid continuation byte The barbican server doesn't show an error when retrieving the secret so it looks like a client-side error. It looks like even thought encoding is in 'application/octet-stream' it is trying to use the utf-8 character set. Storing a secret using base64 seems to work fine: barbican secret store -p '1111222233334444' --payload-content-type 'application/octet-stream' --payload-content-encoding 'base64' However, retrieving the secret payload fails. barbican secret get -p http://localhost:9311/v1/secrets/aef819bf-5997-4b02-a8c4-543fe0c735e5 --payload_content_type 'application/octet-stream' Starting new HTTP connection (1): localhost Starting new HTTP connection (1): localhost 'utf8' codec can't decode byte 0xd7 in position 0: invalid continuation byte It looks like the client is trying to use the utf8 character set even though
2015-10-12 21:25:53 Christopher Solis description Storing a secret using base64 seems to work fine: barbican secret store -p '1111222233334444' --payload-content-type 'application/octet-stream' --payload-content-encoding 'base64' However, retrieving the secret payload fails. barbican secret get -p http://localhost:9311/v1/secrets/aef819bf-5997-4b02-a8c4-543fe0c735e5 --payload_content_type 'application/octet-stream' Starting new HTTP connection (1): localhost Starting new HTTP connection (1): localhost 'utf8' codec can't decode byte 0xd7 in position 0: invalid continuation byte It looks like the client is trying to use the utf8 character set even though Storing a secret using base64 seems to work fine: barbican secret store -p '1111222233334444' --payload-content-type 'application/octet-stream' --payload-content-encoding 'base64' However, retrieving the secret payload fails. barbican secret get -p http://localhost:9311/v1/secrets/aef819bf-5997-4b02-a8c4-543fe0c735e5 --payload_content_type 'application/octet-stream' Starting new HTTP connection (1): localhost Starting new HTTP connection (1): localhost 'utf8' codec can't decode byte 0xd7 in position 0: invalid continuation byte It looks like the client is trying to use the utf8 character set even though it was not stored in as text/plain content.
2015-10-26 13:27:46 Laurent Luce python-barbicanclient: assignee Laurent Luce (laurentluce49)
2015-11-07 00:27:39 Laurent Luce python-barbicanclient: assignee Laurent Luce (laurentluce49)
2015-11-09 15:27:24 Christopher Solis python-barbicanclient: assignee Christopher Solis (cnsolis)
2015-11-19 16:35:11 Christopher Solis python-barbicanclient: status New In Progress
2015-12-03 15:42:03 Dave McCowan summary Unable to return secret payload with content type application/octet-stream Get secret for symmetric secrets returns decode error
2015-12-03 15:44:43 Dave McCowan description Storing a secret using base64 seems to work fine: barbican secret store -p '1111222233334444' --payload-content-type 'application/octet-stream' --payload-content-encoding 'base64' However, retrieving the secret payload fails. barbican secret get -p http://localhost:9311/v1/secrets/aef819bf-5997-4b02-a8c4-543fe0c735e5 --payload_content_type 'application/octet-stream' Starting new HTTP connection (1): localhost Starting new HTTP connection (1): localhost 'utf8' codec can't decode byte 0xd7 in position 0: invalid continuation byte It looks like the client is trying to use the utf8 character set even though it was not stored in as text/plain content. In addition to original description (below), the same decode error can occur for built-in secret types, like symmetric keys. openstack secret get -p --payload_content_type 'application/octet-stream' http://10.30.118.79:9311/v1/secrets/bc924dfb-1bae-4657-a91e-49f451809976 'utf8' codec can't decode byte 0x9f in position 0: invalid start byte The client should have enough information that the secret payload (in this case) is a 256 bit binary value, and not try to utf-8 decode it. <original description below> Storing a secret using base64 seems to work fine: barbican secret store -p '1111222233334444' --payload-content-type 'application/octet-stream' --payload-content-encoding 'base64' However, retrieving the secret payload fails. barbican secret get -p http://localhost:9311/v1/secrets/aef819bf-5997-4b02-a8c4-543fe0c735e5 --payload_content_type 'application/octet-stream' Starting new HTTP connection (1): localhost Starting new HTTP connection (1): localhost 'utf8' codec can't decode byte 0xd7 in position 0: invalid continuation byte It looks like the client is trying to use the utf8 character set even though it was not stored in as text/plain content.
2016-02-22 16:53:55 Christopher Solis python-barbicanclient: status In Progress New
2016-02-22 16:55:36 Christopher Solis python-barbicanclient: status New In Progress
2016-02-23 16:15:46 Christopher Solis summary Get secret for symmetric secrets returns decode error Client returns a decode error when secret cannot be formatted correctly