[Bug 1946787] Re: [SRU] Fix inconsistent encoding secret encoding

[Corey Bryant]

I've uploaded a new version of barbican with this fix to the bionic unapproved queue:
https://launchpad.net/ubuntu/focal/+queue?queue_state=1&queue_text=barbican

** Changed in: barbican (Ubuntu Focal)
       Status: New => Triaged

** Changed in: cloud-archive/ussuri
       Status: New => Triaged

** Changed in: cloud-archive/ussuri
   Importance: Undecided => High

** Changed in: cloud-archive/victoria
   Importance: Undecided => High

** Changed in: cloud-archive/xena
   Importance: Undecided => High

** Changed in: cloud-archive
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to Ubuntu Cloud Archive.
https://bugs.launchpad.net/bugs/1946787

Title:
  [SRU] Fix inconsistent encoding secret encoding

Status in Ubuntu Cloud Archive:
  Fix Released
Status in Ubuntu Cloud Archive ussuri series:
  Triaged
Status in Ubuntu Cloud Archive victoria series:
  Fix Committed
Status in Ubuntu Cloud Archive wallaby series:
  Fix Released
Status in Ubuntu Cloud Archive xena series:
  Fix Released
Status in barbican package in Ubuntu:
  Fix Released
Status in barbican source package in Focal:
  Triaged
Status in barbican source package in Hirsute:
  Fix Released
Status in barbican source package in Impish:
  Fix Released

Bug description:
  [Impact]
  This SRU corresponds with the following story for upstream barbican
  https://storyboard.openstack.org/#!/story/2008335.

  The problem is some secrets were stored in plaintext and some were
  stored encoded. This resulted in the inability to decode some secrets.

  This is fixed by always storing secrets in plaintext and decoding
  inconsistently stored data as needed when getting secrets.

  [Test Case]
    * deploy Openstack with Barbican using Vault as a backend
    * openstack volume type create --encryption-provider nova.volume.encryptors.luks.LuksEncryptor --encryption-cipher aes-xts-plain64 --encryption-key-size 256 --encryption-control-location front-end LUKS
    * openstack volume create --size 1 --type LUKS luks_vol1
    * ensure volume created successfully
    * openstack volume show luks_vol1
    * create vm and attach volume
    * mkfs and mount then test can read/write

  
  [Where things could go wrong]
  If things were to go wrong it would probably be in the get_secret() method which calls _ensure_legacy_base64(). _ensure_legacy_base64() assumes that anything that is not a key was stored base64 encoded. Presumably this is correct, but there was a path added to catch a UnicodeDecodeError exception to handle unexpected non-base64-encoded secrets.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1946787/+subscriptions