[Sts-sponsors] [Bug 1867676] Re: Fetching by secret container doesn't raises 404 exception

2020-04-13 Thread Dan Streetman 
since this is in the Bionic unapproved upload queue already, i'm
removing ubuntu-sponsors.  I'm leaving sts-sponsors subscribed to help
nudge the upload through until it reaches bionic-updates.

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1867676

Title:
  Fetching by secret container doesn't raises 404 exception

Status in Ubuntu Cloud Archive:
  Invalid
Status in Ubuntu Cloud Archive queens series:
  Triaged
Status in python-barbicanclient package in Ubuntu:
  Fix Released
Status in python-barbicanclient source package in Bionic:
  Triaged
Status in python-barbicanclient source package in Disco:
  Fix Released
Status in python-barbicanclient source package in Eoan:
  Fix Released
Status in python-barbicanclient source package in Focal:
  Fix Released

Bug description:
  [Impact]

  Users of Ubuntu bionic running openstack clouds >= rocky
  can't create octavia load balancers listeners anymore since the backport of 
the following patch:

  
https://opendev.org/openstack/octavia/commit/a501714a76e04b33dfb24c4ead9956ed4696d1df

  This change was introduced as part of the following backports and
  their posterior syncs into the current Bionic version.

  This fix being SRUed here is contained in 4.8.1-0ubuntu1 (disco onwards)
  but not on the Bionic version 4.6.0-0ubuntu1.

  The issue gets exposed with the following octavia
  packages from UCA + python-barbicanclient 4.6.0ubuntu1.

  Please note that likely this python-barbicanclient dependency should
  be part of UCA and not of main/universe.

   octavia-api | 3.0.0-0ubuntu3~cloud0   | rocky  | all
   octavia-api | 4.0.0-0ubuntu1.1~cloud0 | stein  | all
   octavia-api | 4.0.0-0ubuntu1~cloud0   | train  | all

  This change added a new exception handler in the code
  that manages the decoding of the given PCKS12 certicate bundle when the 
listener is created, this handler now captures the PCKS12 decoding error and 
then raises it preventing
  the listener creation to happen (when its invoked with i.e.: 
--default-tls-container="https://10.5.0.4:9312/v1/containers/68154f38-fccf-4990-b88c-86eb3cc7fe1a;
 ) , this was originally being hidden
  under the legacy code handler as can be seen here:

  
https://opendev.org/openstack/octavia/commit/a501714a76e04b33dfb24c4ead9956ed4696d1df

  This exception is raised because the barbicanclient doesn't know how to 
distinguish between a given secret and a container, therefore, when the
  user specifies a container UUID the client tries to fetch a secret with that 
uuid (including the /containers/UUID path) and a error 400 (not the expected 
404 http error) is returned.

  The change proposed on the SRU makes the client aware of container and
  secret UUID(s) and is able to split the path to distinguish a non-
  secret (such as a container), in that way if a container is passed, it
  fails to pass the parsing validation and the right return code (404)
  is returned by the client.

  If a error 404 gets returned, then the except Exception block gets
  executed and the legacy driver code for decoding the pcks12 certicate in 
octavia is invoked, this legacy
  driver is able to decode the container payloads and the decoding of the 
pcks12 certificate succeeds.

  This differentiation was implemented here:

  https://github.com/openstack/python-
  barbicanclient/commit/6651c8ffce48ce7ff08f5563a8e6212677ea0468

  As an example (this worked before the latest bionic version was
  pushed)

  openstack loadbalancer listener create --protocol-port 443 --protocol
  "TERMINATED_HTTPS" --name "test-listener" --default-tls-
  container="https://10.5.0.4:9312/v1/containers/68154f38-fccf-4990
  -b88c-86eb3cc7fe1a" -- lb1

  With the newest package upgrade this creation will fail with the
  following exception:

  The PKCS12 bundle is unreadable. Please check the PKCS12 bundle
  validity. In addition, make sure it does not require a pass phrase.
  Error: [('asn1 encoding routines', 'asn1_d2i_read_bio', 'not enough
  data')] (HTTP 400) (Request-ID: req-8e48d0b5-3f5b-
  4d26-9920-72b03343596a)

  Further rationale on this can be found on
  https://storyboard.openstack.org/#!/story/2007371

  [Test Case]

  1) Deploy this bundle or similar
  (http://paste.ubuntu.com/p/cgbwKNZHbW/)

  2) Create self-signed certificate, key and ca
  (http://paste.ubuntu.com/p/xyyxHZGDFR/)

  3) Create the 3 certs at barbican

  $ openstack secret store --name "test-pk-1" --secret-type "private"
  --payload-content-type "text/plain" --payload="$(cat
  ./keys/controller_key.pem)"

  $ openstack secret store --name "test-ca-1" --secret-type
  "certificate" --payload-content-type "text/plain" --payload="$(cat
  ./keys/controller_ca.pem)"

  $ openstack secret store --name "test-pub-1" --secret-type
  "certificate" --payload-content-type "text/plain" --payload="$(cat
  ./keys/controller_cert.pem)"

  4) Create a loadbalancer
  $

[Sts-sponsors] [Bug 1867676] [NEW] Fetching by secret container doesn't raises 404 exception

2020-04-13 Thread Launchpad Bug Tracker 
You have been subscribed to a public bug by Dan Streetman (ddstreet):

[Impact]

Users of Ubuntu bionic running openstack clouds >= rocky
can't create octavia load balancers listeners anymore since the backport of the 
following patch:

https://opendev.org/openstack/octavia/commit/a501714a76e04b33dfb24c4ead9956ed4696d1df

This change was introduced as part of the following backports and
their posterior syncs into the current Bionic version.

This fix being SRUed here is contained in 4.8.1-0ubuntu1 (disco onwards)
but not on the Bionic version 4.6.0-0ubuntu1.

The issue gets exposed with the following octavia
packages from UCA + python-barbicanclient 4.6.0ubuntu1.

Please note that likely this python-barbicanclient dependency should
be part of UCA and not of main/universe.

 octavia-api | 3.0.0-0ubuntu3~cloud0   | rocky  | all
 octavia-api | 4.0.0-0ubuntu1.1~cloud0 | stein  | all
 octavia-api | 4.0.0-0ubuntu1~cloud0   | train  | all

This change added a new exception handler in the code
that manages the decoding of the given PCKS12 certicate bundle when the 
listener is created, this handler now captures the PCKS12 decoding error and 
then raises it preventing
the listener creation to happen (when its invoked with i.e.: 
--default-tls-container="https://10.5.0.4:9312/v1/containers/68154f38-fccf-4990-b88c-86eb3cc7fe1a;
 ) , this was originally being hidden
under the legacy code handler as can be seen here:

https://opendev.org/openstack/octavia/commit/a501714a76e04b33dfb24c4ead9956ed4696d1df

This exception is raised because the barbicanclient doesn't know how to 
distinguish between a given secret and a container, therefore, when the
user specifies a container UUID the client tries to fetch a secret with that 
uuid (including the /containers/UUID path) and a error 400 (not the expected 
404 http error) is returned.

The change proposed on the SRU makes the client aware of container and
secret UUID(s) and is able to split the path to distinguish a non-secret
(such as a container), in that way if a container is passed, it fails to
pass the parsing validation and the right return code (404) is returned
by the client.

If a error 404 gets returned, then the except Exception block gets
executed and the legacy driver code for decoding the pcks12 certicate in 
octavia is invoked, this legacy
driver is able to decode the container payloads and the decoding of the pcks12 
certificate succeeds.

This differentiation was implemented here:

https://github.com/openstack/python-
barbicanclient/commit/6651c8ffce48ce7ff08f5563a8e6212677ea0468

As an example (this worked before the latest bionic version was pushed)

openstack loadbalancer listener create --protocol-port 443 --protocol
"TERMINATED_HTTPS" --name "test-listener" --default-tls-
container="https://10.5.0.4:9312/v1/containers/68154f38-fccf-4990-b88c-
86eb3cc7fe1a" -- lb1

With the newest package upgrade this creation will fail with the
following exception:

The PKCS12 bundle is unreadable. Please check the PKCS12 bundle
validity. In addition, make sure it does not require a pass phrase.
Error: [('asn1 encoding routines', 'asn1_d2i_read_bio', 'not enough
data')] (HTTP 400) (Request-ID: req-8e48d0b5-3f5b-
4d26-9920-72b03343596a)

Further rationale on this can be found on
https://storyboard.openstack.org/#!/story/2007371

[Test Case]

1) Deploy this bundle or similar (http://paste.ubuntu.com/p/cgbwKNZHbW/)

2) Create self-signed certificate, key and ca
(http://paste.ubuntu.com/p/xyyxHZGDFR/)

3) Create the 3 certs at barbican

$ openstack secret store --name "test-pk-1" --secret-type "private"
--payload-content-type "text/plain" --payload="$(cat
./keys/controller_key.pem)"

$ openstack secret store --name "test-ca-1" --secret-type "certificate"
--payload-content-type "text/plain" --payload="$(cat
./keys/controller_ca.pem)"

$ openstack secret store --name "test-pub-1" --secret-type "certificate"
--payload-content-type "text/plain" --payload="$(cat
./keys/controller_cert.pem)"

4) Create a loadbalancer
$ openstack loadbalancer create --name lb1 --vip-subnet-id private_subnet

5) Create a secrets container

$ openstack secret container create --type='certificate' --name "test-
tls-1"
--secret="certificate=https://10.5.0.4:9312/v1/secrets/3c9109d9-05e0-45fe-9661-087c50061c00;
--secret="private_key=https://10.5.0.4:9312/v1/secrets/378e8f8c-81f5
-4b5a-bffd-c0c43a41b4a8"
--secret="intermediates=https://10.5.0.4:9312/v1/secrets/07a7564d-
b5c6-4433-a0a9-a195e2d54c57"

6) Try to create the listener

openstack loadbalancer listener create --protocol-port 443 --protocol
"TERMINATED_HTTPS" --name "test-listener" --default-tls-
container="https://10.5.0.4:9312/v1/containers/68154f38-fccf-4990-b88c-
86eb3cc7fe1a" -- lb1

With the newest package upgrade this creation will fail with the
following exception:

The PKCS12 bundle is unreadable. Please check the PKCS12 bundle
validity. In addition, make sure it does not require a pass phrase.
Error: [('asn1

[Sts-sponsors] sts-sponsors joined ubuntu-support-team

2020-04-13 Thread Ubuntu Support Team 
Hello STS Sponsors,

Dan Streetman (ddstreet) added STS Sponsors (sts-sponsors) (which you
are a member of) as a member of Ubuntu Support Team (ubuntu-support-
team).
  

If you would like to subscribe to the team list, use the link below
to update your Mailing List Subscription preferences.
  

-- 
You received this email because your team STS Sponsors is the new member.

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] sts-sponsors made admin by ddstreet

2020-04-13 Thread Ubuntu Support Team 
Hello STS Sponsors,

The membership status of STS Sponsors (sts-sponsors) in the team Ubuntu
Support Team (ubuntu-support-team) was changed by Dan Streetman
(ddstreet) from Approved to Administrator.


-- 
You received this email because your team STS Sponsors is the affected member.

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] dgadomski joined ubuntu-support-team

2020-04-13 Thread Ubuntu Support Team 
Hello STS Sponsors,

Dariusz Gadomski (dgadomski) has been added as a member of Ubuntu
Support Team (ubuntu-support-team) by Dan Streetman (ddstreet). Follow
the link below for more details.

https://launchpad.net/~ubuntu-support-team/+member/dgadomski

-- 
You received this email because your team STS Sponsors is an admin of the 
Ubuntu Support Team team.

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] mfo joined ubuntu-support-team

2020-04-13 Thread Ubuntu Support Team 
Hello STS Sponsors,

Mauricio Faria de Oliveira (mfo) has been added as a member of Ubuntu
Support Team (ubuntu-support-team) by Dan Streetman (ddstreet). Follow
the link below for more details.

https://launchpad.net/~ubuntu-support-team/+member/mfo

-- 
You received this email because your team STS Sponsors is an admin of the 
Ubuntu Support Team team.

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp