Improper handling of ScaleIO backend credentials

Bug #1823200 reported by Eric Harney
26
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Cinder
Fix Released
High
Sean McGinnis
Queens
Fix Released
High
Ivan Pchelintsev
Rocky
Fix Released
High
Ivan Pchelintsev
Stein
Fix Committed
High
Ivan Pchelintsev
Train
Fix Committed
High
Ivan Pchelintsev
Ussuri
Fix Committed
High
Ivan Pchelintsev
Victoria
Fix Released
High
Sean McGinnis
OpenStack Security Advisory
Won't Fix
Undecided
Unassigned
OpenStack Security Guide Documentation
Fix Released
Undecided
Unassigned
OpenStack Security Notes
In Progress
Undecided
Brian Rosmaita
Ubuntu Cloud Archive
Fix Released
High
Unassigned
Queens
Fix Released
High
Unassigned
Rocky
Fix Released
High
Unassigned
Stein
Fix Released
High
Unassigned
Train
Fix Released
High
Unassigned
Ussuri
Fix Released
High
Unassigned
Victoria
Fix Released
High
Unassigned
os-brick
Fix Released
High
Ivan Pchelintsev
cinder (Ubuntu)
Fix Released
High
Unassigned
Bionic
Fix Released
High
Unassigned
Eoan
Won't Fix
High
Unassigned
Focal
Fix Released
High
Unassigned
Groovy
Fix Released
High
Unassigned
python-os-brick (Ubuntu)
Fix Released
High
Unassigned
Bionic
Fix Released
High
Unassigned
Eoan
Won't Fix
High
Unassigned
Focal
Fix Released
High
Unassigned
Groovy
Fix Released
High
Unassigned

Bug Description

The ScaleIO driver uses the backend storage login and password for authentication for connections to the volume as well as the management API.

https://git.openstack.org/cgit/openstack/cinder/tree/cinder/volume/drivers/dell_emc/scaleio/driver.py?h=13.0.4#n176

https://git.openstack.org/cgit/openstack/cinder/tree/cinder/volume/drivers/dell_emc/scaleio/driver.py?h=13.0.4#n229

This has a few serious implications:
a) A user can create a volume, retrieve the username/password from that volume, and use it to connect to a different tenant's volume. Most drivers create per-volume credentials.

b) A user can create a volume, retrieve the username/password from that volume, and use it to connect to the ScaleIO management API and presumably do lots of things they shouldn't be allowed to. Most drivers create credentials for volumes that are independent of the management credentials.

c) If the password is changed on the backend ScaleIO volumes that are currently being used stop working, because Nova stores the old password in its block_device_mapping table. (Not a security problem other than the fact that it prevents rotation of passwords, but definitely a bug.)

Parts of these issues are separately being looked at in bug 1736773, (which generally advises that in some clouds, only Nova should be able to see connection info, not end users) but the situation there is worse for the ScaleIO driver because most drivers only put usernames/passwords in connection_info that are usable for a single volume, not for the storage backend itself.

CVE References

Revision history for this message
Jeremy Stanley (fungi) wrote :

Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions.

description: updated
Changed in ossa:
status: New → Incomplete
Revision history for this message
Jeremy Stanley (fungi) wrote :

In keeping with recent OpenStack vulnerability management policy changes, no report should remain under private embargo for more than 90 days. Because this report predates the change in policy, the deadline for public disclosure is being set to 90 days from today. If the report is not resolved within the next 90 days, it will revert to our public workflow as of 2020-05-27. Please see http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012721.html for further details.

description: updated
Revision history for this message
Jeremy Stanley (fungi) wrote :

It doesn't look like this report has seen any activity since my update two months ago, so consider this a friendly reminder:

The embargo for this report is due to expire one month from today, on May 27, and will be switched public on or shortly after that day if it is not already resolved sooner.

Thanks!

Changed in cinder:
assignee: nobody → Ivan Pchelintsev (pcheli)
Revision history for this message
Sean McGinnis (sean-mcginnis) wrote :

Checking with the team, it sounds like this may be a limitation with how this storage works. Whether the product can be changed to address this has yet to be determined. The "fix" for this may end up needing to be a documentation update alerting operators that this is a concern they need to be aware of.

Revision history for this message
Jeremy Stanley (fungi) wrote :

It sounds like this could wind up being a class B1 report (can only be fixed in master) like related bug 1736773, or B2 (vulnerability without a complete fix yet, security note for all versions):

https://security.openstack.org/vmt-process.html#incident-report-taxonomy

If we can get some confirmation that there's unlikely to be any backportable fix on the way, then we may as well switch this to public ahead of the embargo expiration rather than delaying further. Thanks for checking!

Revision history for this message
Ivan Pchelintsev (pcheli) wrote :

VxFlex OS does not support multi-tenancy or per-volume authentication yet. We suggest to eliminate passing credentials from Cinder to Nova and storing them in “block_device_mapping” so that users won’t see any. Instead a separate file will be placed on each host. It will contain the same backend credentials parameters from similar sections in cinder.conf, e.g.

[vxflexos-1]
san_password = password1

[vxflexos-2]
san_password = password2
replication_san_password = replication_password2

Whenever Nova tries to connect a block device it will get the storage credentials from the file.

Revision history for this message
Jeremy Stanley (fungi) wrote :

If I'm reading correctly, the proposed fix will require configuration changes for existing deployments, so we'll likely want a security note (OSSN) for this but we would not produce an advisory (OSSA).

Revision history for this message
Brian Rosmaita (brian-rosmaita) wrote :

@Jeremy and other VMT people: Now that it looks like we're closing in on a solution, how can we handle this? It would be good if we could give operators a heads up before the OSSN is published, because until they both have os-brick patched on all computes and the config file deployed on all hosts with a new password, they can't really fix this (except to change the password early so that no new connections to the backend can be made, which would be pretty disruptive). The statement in the description says "This embargo shall not extend past 2020-05-27 and will be made
public by or on that date if no fix is identified" -- since a fix has been identified, can we extend the embargo a bit?

Revision history for this message
Jeremy Stanley (fungi) wrote :

It was meant to read "will be made public by or on that date EVEN if no fix is identified" since the policy change linked in my accompanying comment says:

    Embargoes for privately-reported vulnerabilities shall not last
    more than 90 days, except under unusual circumstances. Following
    the embargo expiration, reports will be publicly visible
    regardless of whether an advisory has been issued.

(now published at https://governance.openstack.org/tc/reference/tags/vulnerability_managed.html#requirements )

We also don't have any process identified for notifying consumers privately to make configuration changes; our OSSA process is focused on applying patches since the primary audience is downstream package maintainers for distributions (though we do have some large public cloud operators subscribed to receive advance copies of those patches for evaluation as well). In the past our policy for fixes requiring configuration changes has been to make them public as quickly as possible so that all operators/users can apply mitigations sooner.

That said, the embargo expiration policy does carve out an exception for "unusual circumstances" and we could attempt to reuse our pre-OSSA notification channel for OSSN guidance (I think it's been done once, several years ago). I still wonder why we need an exception here, since the report sat ignored for 10 months and saw no activity until it was nearing the new embargo expiration. If it wasn't critical enough for anyone to even comment on for nearly a year, is it really so critical that we need to continue to keep it a secret now? And if so, how long past May 27 do you propose extending it the embargo? Three days? A week?

Jeremy Stanley (fungi)
description: updated
Revision history for this message
Brian Rosmaita (brian-rosmaita) wrote :

os-brick patch:
Passes py36,37,38 tests
pep8 problem:
./os_brick/tests/initiator/connectors/test_scaleio.py:49:28: E241 multiple spaces after ':'
            'config_group': 'test',
(please fix or we'll have trouble when we try to merge this)

cinder patch:
passes pep8, py36,37,38, docs, functional-py36,38, pylint
Doc changes look OK, though someone who knows more triple-O should verify the text in the "Using VxFlex OS Storage with a containerized overcloud" section.

I think the code looks OK, but definitely need more eyes on this.

Revision history for this message
Jeremy Stanley (fungi) wrote :

Other things to consider: Is this patch backportable (at least as far as stable/stein)? Can someone draft the intended configuration guidance to operators which would be necessary for an OSSN? I assume there's not much point to a typical DevStack+Tempest run with it, but does it still work on the VXFlexOS third-party CI environment with no test regressions?

Revision history for this message
Brian Rosmaita (brian-rosmaita) wrote :

Thanks, Jeremy, those are all good points. Here are my thoughts, though I encourage other members of cinder coresec to add comments:

> Is this patch backportable (at least as far as stable/stein)?

It should be a clean backport, plus the change is isolated to vxflexos/scaleio components in both cinder and os-brick, so it would be a very low risk of destabilizing deployments not using that backend.

> Can someone draft the intended configuration guidance to operators which would be necessary for an OSSN?

I can do this as soon as we've reached agreement that this is the correct fix, unless someone at Dell/EMC would prefer to do it. (I think the configuration guidance in the docs change in the cinder patch is very clear.)

> I assume there's not much point to a typical DevStack+Tempest run with it, but does it still work on the VXFlexOS third-party CI environment with no test regressions?

Ivan or someone from the Dell/EMC team: please leave some details about your testing on this patch so we have a record that it doesn't cause a regression. Bonus points if you can provide some indication that it works, e.g., nova bdm record without the password showing, calls to the Block Storage Attachments API showing no password, etc.

Changed in cinder:
importance: Undecided → High
Revision history for this message
Walt Boring (walter-boring) wrote :

If I read the os-brick patch correctly, it is going to have brick read the username password from a config file. just a reminder that this wont work in the case of a user attaching a volume to a bare metal host unless the user has that password config file available as well. cinder client uses os-brick locally during a user attach from a BM host via the python brick cinder client extension. https://github.com/openstack/python-brick-cinderclient-ext

Revision history for this message
Ivan Pchelintsev (pcheli) wrote :
Revision history for this message
Ivan Pchelintsev (pcheli) wrote :

Hi, thanks all for comments/reviews.
> ./os_brick/tests/initiator/connectors/test_scaleio.py:49:28: E241 multiple spaces
Fixed, new patch is attached with the same name.

> just a reminder that this wont work in the case of a user attaching a volume to a bare metal host unless the user has that password config file available as well.
VxFlex OS volumes attach/detach operations do not work out of the box. To attach volume to bare metal host we need to install VxFlexx OS SDC component and create password file.

> Ivan or someone from the Dell/EMC team: please leave some details about your testing on this patch so we have a record that it doesn't cause a regression. Bonus points if you can provide some indication that it works, e.g., nova bdm record without the password showing, calls to the Block Storage Attachments API showing no password, etc.
Attached archive with tempest logs and screenshot from mysql block_device_mapping table.

Revision history for this message
Walt Boring (walter-boring) wrote :

So the security issue will still continue when users need to attach volumes to the BM host.

Revision history for this message
Brian Rosmaita (brian-rosmaita) wrote :

Good point, Walt. It sounds like we will have to recommend that vxflexos/scaleio not be used with bare metal, because all an attacker would have to do is boot a BM host, and they can obtain the credentials for the entire backend.

Ivan, do you see any way around that?

Revision history for this message
Ivan Pchelintsev (pcheli) wrote :

Sorry, can not understand the problem.
Can you give me more details?

Revision history for this message
Vladislav Belogrudov (vlad-belogrudov) wrote :

Do you mean Ironic-like cases with normal user BMs? It should not be allowed with the storage. Any host that needs connection to the VxFlex OS storage must have client side software installed and configured as superuser. And for OpenStack there is now additional requirement of the config file with admin credentials. Client side VxFlex software creates virtual block devices on hosts that are passed to VMs.

So I would say no user BMs are supported / recommended. VMs are welcome.

Revision history for this message
Brian Rosmaita (brian-rosmaita) wrote :

Vladislav: thanks for confirming.

Ivan: I looked at the tarfile, but the tempest.log is really hard to read about what tests were run and the results. Could you send the console log, or whatever would show that? What I mean is something like:

https://ftp.nimblestorage.com/openstack_ci/iscsi/83/730183/1/check/nimble-iscsi-driver-dsvm-volume/32f9c4e/console.out

About halfway through that file you can see the tempest regex filter being used and then the results of the individual tests. Something like that would be really helpful.

Changed in cinder:
status: New → In Progress
Revision history for this message
Jeremy Stanley (fungi) wrote :

As it stands now, this report is still scheduled to switch from Private Security to Public Security tomorrow with the expiration of its embargo. Do we have a reason to extend the embargo and keep it private for longer? This seems to be the current status:

1. There is a solution proposed where, once two patches are applied (comment #6 and comment #15), the operator can configure a safe operating mode for use with virtual server instances.

2. There is no identified solution for using this driver with bare metal instances, nor does one seem to be possible due to the design of the storage platform itself, so the guidance to operators is to not combine them (comment #20).

3. Tests of the proposed patch have been performed in a suitable lab environment, but sufficient evidence has not been provided for reviewers to confirm it's working to their satisfaction (comment #21).

4. Backports of the proposed patch to stable branches have not been provided yet, but it's expected to be trivial to cherry-pick and the implementation is presumed to meet OpenStack's stable branch policy (comment #13).

5. There was a suggestion that users of the driver should be provided an advance copy of the patches and configuration guidance so they will have time to secure their environments before the bug becomes public (comment #9).

If we were to extend the embargo on this report by a week, say to June 3, would that be enough time to address these points? Or will switching to public tomorrow (so patches can be pushed to Gerrit for broader review, more readable third-party test results can be generated and linked, et cetera) be preferable?

Revision history for this message
Brian Rosmaita (brian-rosmaita) wrote :

Jeremy, thanks for the update. If we can extend the embargo to June 3, that will be extremely helpful. While drafting the OSSN, I realized that the backports will not be as easy as I thought. To be specific, this problem applies to all stable branches, and we have a rename and some refactoring to deal with. So instead of having a single patch that could be applied to multiple releases, we're going to need multiple patches. The extra time would enable us to have these all ready for operators. I'll provide the details in another comment.

Revision history for this message
Brian Rosmaita (brian-rosmaita) wrote :

Draft of the OSSN for this issue attached.

Revision history for this message
Brian Rosmaita (brian-rosmaita) wrote :

Here's why the details in the OSSN patch are a TODO:

Cinder changes
--------------
"vxflexos" driver
master, ussuri: current cinder.patch attached to this bug
change to cinder/volume/drivers/dell_emc/vxflexos/rest_client.py
change to cinder/volume/drivers/dell_emc/vxflexos/driver.py

train: no rest client, all changes to be made to cinder/volume/drivers/dell_emc/vxflexos/driver.py

"scaleio" driver
pike, queens, rocky, stein: changes to cinder/volume/drivers/dell_emc/scaleio/driver.py
ocata: will need a different patch for cinder/volume/drivers/dell_emc/scaleio/driver.py due to refactoring in rocky

os-brick changes
----------------
Component was not renamed, so all scaleio.

os_brick/initiator/connectors/scaleio.py
looks like same change in
pike, queens, rocky, stein, train, ussuri, master

os_brick/privileged/scaleio.py
introduced in stein
ocata, pike, queens, rocky: doesn't exist

Revision history for this message
Brian Rosmaita (brian-rosmaita) wrote :

Vladislav and Ivan: Please get the info requested in comment #21 so we can verify that the patch isn't causing regressions. Once we're sure that patch will work, you'll need to put up some more branch-specific patches as noted in comment #25.

Revision history for this message
Jeremy Stanley (fungi) wrote :

After discussing with the other members of the OpenStack VMT, we've agreed bumping the embargo expiration out an additional week should be fine, so I've updated it to June 3.

description: updated
Revision history for this message
Summer Long (slong-g) wrote :

After reading through, it seems this flaw is CVE-worthy (vs an OSSN / hardening). The main security point is that a user can retrieve their own volume's connection information and then use it to access another user's volume/info.

Per Brian's draft OSSN notes: "When using Cinder with the Dell EMC ScaleIO or VxFlex OS backend storage driver, credentials for the entire backend are exposed in the ``connection_info`` element in all Block Storage v3 Attachments API calls containing that element. This enables an end user to create a volume, make an API call to show the attachment detail information, and retrieve a username and password that may be used to connect to another user's volume. Additionally, these credentials are valid for the ScaleIO or VxFlex OS Management API, should an attacker discover the Management API endpoint."

Will the OpenStack VMT move this to a CVE (OSSA)? Or is there a reason to see/keep this flaw at the hardening level?

Revision history for this message
Ivan Pchelintsev (pcheli) wrote :

Sorry for delayed response, had some issues with the environment.
Tempest logs from stable/ussuri with security patch attached.
Working now on backports.

Revision history for this message
Jeremy Stanley (fungi) wrote :

Summer: To be handled as an advisory, the patches provided would need to completely fix the flaw, not merely allow an operator to configure the environment so that the flaw was no longer present. Basically we'd need agreement of the driver and Cinder/Brick maintainers as well as the OpenStack stable branch reviewers that such a default behavior change is appropriate to backport to all supported stable branches. In this case, I think it basically means a violation of OpenStack's typical stable branch policies because there would be new configuration settings required for the deployment, effectively breaking the storage backend until they were set. If the vulnerability is so severe that stable deployments are better off taken down until they can be reconfigured, then we should discuss this option further (I just wish people were interested enough in securing this nearly a year ago when the vulnerability was reported rather than waiting until the VMT was ready to make it public so that concerned users could at least stop using this long-vulnerable driver).

Revision history for this message
Ivan Pchelintsev (pcheli) wrote :

Train patches for os-brick/cinder with tempest logs attached.

Revision history for this message
Brian Rosmaita (brian-rosmaita) wrote :

Just noticed a typo in comment #25:

when I said:
"ocata: will need a different patch for cinder/volume/drivers/dell_emc/scaleio/driver.py due to refactoring in rocky"

I meant "refactoring in pike".

Revision history for this message
Summer Long (slong-g) wrote :

Hi Jeremy, absolutely agree that this could have been dealt with sooner. That said, my comment was that the flaw is serious enough to be categorized as a CVE, regardless of how it's dealt with. The patch will at least offer a mitigation. Will you be asking mitre for a CVE? RH can do that once it's public if you want.

Revision history for this message
Ivan Pchelintsev (pcheli) wrote :

Stein patch is ready.

Revision history for this message
Jeremy Stanley (fungi) wrote :

Summer: Unless the plan changes to provide patches which fix this vulnerability for existing configurations or by breaking deployments until updated configuration is applied, which is likely even impossible for anyone who's been using the driver with bare metal instances unless the vendor alters the design of their product, the OpenStack VMT won't be issuing an advisory; and we only request CVEs from MITRE if an advisory is being drafted.

Publication of guidance to deployers and distributors for securing the software is still encouraged--we have a less formal "security note" process we recommend for this purpose--and if you wish to assign a CVE along with it then feel free to do so. All we ask is that you update this bug report with the CVE identifier so that multiple organizations don't do the same and wind up with duplicate CVEs.

Revision history for this message
Brian Rosmaita (brian-rosmaita) wrote :

According to the stable branch policy [0], "OpenStack Vulnerability Management will be reasonable efforts only" for branches in Extended Maintenance mode.

The following cinder and os-brick branches are in EM mode:
- ocata
- pike
- queens
- rocky

I think it is reasonable to push this fix as far back as Queens.

Ocata will take unreasonable effort. The requirements team was able to make some changes to get their Ocata gate moving again so they could push some requirements changes to hopefully unblock everyone else, but it hasn't worked for cinder [1] and os-brick [2], at least, and there seems to be a consensus building on the mailing list that Ocata needs to go EOL [3]. So I will declare right now we do not need to prepare an Ocata patch for this bug.

I'm willing to hear opinions about Pike (my personal opinion is that it is *not* reasonable effort). Right now, the cinder [4] and os-brick [5] gates are broken. The word on the street is that it can be fixed by modifying some of the test jobs to native zuul v3 jobs, but I haven't looked into it because the last change to cinder:stable/pike was 6 months ago, and the last change to os-brick:stable/pike was over 1 year ago. I am dubious that we will get the cinder/os-brick Pike gates working before 3 June (the PTG is next week, which basically leaves us tomorrow to get the gates fixed, and I would rather spend the time reviewing and getting the patches in place for Queens through master (Victoria). Further, there has not been a lot of interest in Pike (as evidenced by lack of backport activity), so I think it makes sense not to put effort into making a patch available for Pike.

So, to be completely clear:
* Ocata - no patch
* Pike - I'm inclined to say no patch, but am interested in other opinions.
* Queens through Victoria - we should have patches available

[0] https://docs.openstack.org/project-team-guide/stable-branches.html#extended-maintenance
[1] https://review.opendev.org/730938
[2] https://review.opendev.org/#/c/731193/
[3] http://lists.openstack.org/pipermail/openstack-discuss/2020-May/015112.html
[4] https://review.opendev.org/730959
[5] https://review.opendev.org/731196

Revision history for this message
Jeremy Stanley (fungi) wrote :

There's also the option of just getting the backports through stable/stein ready to push at the same time an OSSN is published, and let any interested parties backport to older branches afterward. If you do mention EM branch commits, the way the VMT usually phrases it is along the lines of, "the stable/rocky branch is under extended maintenance and will receive no new point releases, but a patch for it is provided as a courtesy."

Revision history for this message
Ivan Pchelintsev (pcheli) wrote :

Rocky patches.

Revision history for this message
Sean McGinnis (sean-mcginnis) wrote :

I agree with Brian's assessment.

We just need Queens yet, and we should be ready to move ahead.

If we can get a patch for Pike, great. If that becomes too difficult due to code changes or other factors, I think we're fine.

Ocata is definitely too old and is likely to go EOL soon. Again, if a patch is available, that's a bonus. But I don't see that as a requirement.

Revision history for this message
Brian Rosmaita (brian-rosmaita) wrote :

I'll update the OSSN draft later today and get these patches reviewed (though of course, everyone should feel free to review/test them!).

With the PTG next week, we should figure out the timing of this. Jeremy, can you suggest how this should go?

rosmaita
- git review of OSSN-0086 <-- what time should I submit this?
- after it is approved, will paste the text into the wiki and send a message to the ML

pcheli
- have patched local branches set up so that you can do 'git review' from each one
- should there be a patch directly to ussuri, or will we backport the patch from master?
- rosmaita and smcginnis - be available to approve patches as they are proposed

Ivan, what time zone are you in?

Revision history for this message
Ivan Pchelintsev (pcheli) wrote :

Moscow (UTC+3).

Jeremy Stanley (fungi)
Changed in ossa:
status: Incomplete → Won't Fix
Jeremy Stanley (fungi)
Changed in ossn:
assignee: nobody → Brian Rosmaita (brian-rosmaita)
Revision history for this message
Jeremy Stanley (fungi) wrote :

Brian: Basically whatever time you, Ivan and Sean are comfortable doing it should be fine. Just switch this bug from Private Security to Public first and add the "security" bugtag to it. That way if you include a Closes-Bug: #1823200 as a commit message footer for the various changes, this bug and the security ML should get updated automatically with links to them. I've marked the OSSN project as affected to it will get a bugtask, and assigned it to you. I recommend pushing the security-doc change around the same time as the cinder/os-brick changes. Your plan in comment #40 looks great, though if there is no convenient time overlap between you and Ivan, some delay between those is likely fine too. I probably wouldn't send the announcement about it to the ML until the related changes merge to affected branches you're listing, since interested parties may take that as a queue to pull updated branches immediately to obtain those patches.

Revision history for this message
Jeremy Stanley (fungi) wrote :

I've also added the security guide and os-brick projects as affected since there will be changes getting pushed for those, but you also may want to add series bugtasks for each of the cinder and os-brick branches getting backports so they're tracked too.

Revision history for this message
Brian Rosmaita (brian-rosmaita) wrote :

Thanks, Jeremy. I'll update the series info on this bug.

Changed in os-brick:
assignee: nobody → Ivan Pchelintsev (pcheli)
importance: Undecided → High
milestone: none → 3.1.0
status: New → In Progress
Changed in ossn:
status: New → In Progress
Revision history for this message
Brian Rosmaita (brian-rosmaita) wrote :

Draft of a release note for cinder master. Please review, and I will generate them for the remaining branches (they all reference different versions of os-brick) once we have agreed on the wording. Will also need something similar for os-brick, will post something soon.

Revision history for this message
Brian Rosmaita (brian-rosmaita) wrote :

Draft of os-brick release note.

Revision history for this message
Brian Rosmaita (brian-rosmaita) wrote :

Updated release note for master attached. (There was an error in the markup.)

Revision history for this message
Brian Rosmaita (brian-rosmaita) wrote :

@pcheli: I'm sorry for not mentioning this sooner, but I think you need to increment the version number and version history on the driver in each branch so that it will be easy for operators to tell if they are using a fixed driver or not. Just be sure to pick a number that won't conflict with a more recent branch (e.g., stein is at 2.0.4 and a 2.0.5 was already included in train.

Maybe Sean or someone can suggest the best way to handle this. I'm not sure if you can make the new stein driver 2.1.4 or whether you should make it 2.0.5.1

Revision history for this message
Ivan Pchelintsev (pcheli) wrote :

Brian,
Ok, I’ll prepare patches for each branch and will be ready to push them on June 3.
Ex. 2.0.5.1 will be good I think.
But for master branch I suggest to use 3.5.4.
Also do I need to include fix details in description for driver version or just bug number will be sufficient?

Revision history for this message
Brian Rosmaita (brian-rosmaita) wrote :

Ivan,

I think it would be sufficient to say "Fix for Bug #1823200. See OSSN-0086 for details."

Revision history for this message
Brian Rosmaita (brian-rosmaita) wrote :

Patches look ok (except for the versioning issue mentioned above).

Applied the patches and ran local tests:
patch for master
cinder: passed pep8, py36, py37, py38, docs, functional-py36, functional-38, pylint
os-brick: passed pep8, py36,37,38

--
ussuri: applied master patch to stable/ussuri
cinder: passed pep8, py37, functional-py37
os-brick: passed pep8, py37
--
patch for train
cinder: passed: pep8,py27,py36,py37,docs,functional-py36
os-brick: passed: pep8,py27,py36,py37,docs

--
patch for stein
cinder: pep8,py27,py36,functional-py36,docs
os-brick: passed: pep8,py27,py36,py37

---
patch for rocky
cinder: passed: pep8,py27,py35,py36,functional-py35,functional-py36,docs
os-brick: passed: pep8,py27,py35,docs

Revision history for this message
Brian Rosmaita (brian-rosmaita) wrote :

Attached release notes for cinder/os-brick master, ussuri, train, stein. (It's a tarball of files, not patches.)

Revision history for this message
Ivan Pchelintsev (pcheli) wrote :

All above mentioned patches are ready for pushing to gerrit with versioning added.
Testing Queens patch now.

Revision history for this message
Brian Rosmaita (brian-rosmaita) wrote :

Here's what I think about the ordering of this. We want there to be as little time between steps as possible.

(0) Make https://bugs.launchpad.net/cinder/+bug/1823200 public.

(1) Propose all os-brick patches, even ussuri. If you rebase before pushing the patches, we won't need merge commits, and I can get the release patches ready sooner. Don't forget to include the release note for each branch (attached to the Launchpad bug) and "Closes-bug: #1823200" in the commit message.

(2) Also propose the cinder patches. Include the release note and "Closes-bug" as above. We won't be able to merge them yet because they won't pass Dell-EMC CI until we update the requirements.txt and lower-constraints.txt (which we can't do until the new os-brick releases happen).

(3) Once all patches are posted, I'll update the OSSN with the gerrit urls, put up a security-doc patch, and update the OSSN in the wiki. Even if the patches haven't merged yet, they will be available for operators to look at and start planning. So I guess at this point I also send the OSSN to openstack-discuss and openstack-announce?

(4) I'll post release patches for all os-brick branches as soon as the patches in (1) have merged.

(5) The release patches will trigger an upper-constraints update. We can ask Sean to line up another requirements person in addition to himself to approve those patches. (We won't be able to merge the cinder change in any branch until the upper-constraints has changed, but at least the patches will be available.)

(6) Update the requirements.txt and lower-constraints.txt in each of (2). (I'm thinking that I'll probably do this because it will be late in UTC+3 at this point, but we can work that out.) I'll have to line up two other people in cinder coresec to approve.

(7) After all (6) have merged, I'll propose cinder releases.

And I think that's it?

Revision history for this message
Ivan Pchelintsev (pcheli) wrote :

Got it.
Do we need release notes also for Rocky and Queens?

Revision history for this message
Jeremy Stanley (fungi) wrote :

Brian: Your sequence in comment #55 should work, just bear in mind that OSSNs traditionally haven't linked to specific changes in Gerrit like OSSAs because they're usually not published/announced until after all related changes have merged. Since the "patches" section of your proposed OSSN includes that information, it should be fine for this particular case.

Revision history for this message
Jeremy Stanley (fungi) wrote :

Brian: Also, on step #0 there, when you make the bug public you should first remove the initial paragraph from the description (so that we don't have a public bug claiming to be under embargo), then switch the bug status from Private Security to Public (not Public Security since we generally only use that for advisories not notes) and add a "security" bugtag so that the openstack-security ML will get a copy of the bug updates from that point forward (patches proposed for review, patches mwerged, releases containing them, further discussion, et cetera).

Revision history for this message
Brian Rosmaita (brian-rosmaita) wrote :

@Ivan: no release notes for Rocky & Queens because there won't be any releases from those. I think there's sufficient info in the doc updates on the cinder patch + the OSSN so that operators will know what to do. Plus there are the release notes on the more recent patches they can use for reference.

@Ivan: also, about timing. Can you arrange to push the patches to gerrit around 2pm your time and then put a message into #openstack-cinder tagging rosmaita geguileo whoami-rajat eharney smcginnis to let us know that the patches are ready for review.

@Ivan: also, i will update the tarball of release notes today; will make sure it says "new" in the filename so you can tell they're updated (we had a security meeting and some clarifications were suggested).

Thanks!

Revision history for this message
Brian Rosmaita (brian-rosmaita) wrote :

Updated OSSN, still needs patch urls.

Revision history for this message
Brian Rosmaita (brian-rosmaita) wrote :

Updated OSSN; still needs patch urls.

Revision history for this message
Brian Rosmaita (brian-rosmaita) wrote :

Release notes for cinder and os-brick for victoria (master), stein, train, and ussuri.

Revision history for this message
Ivan Pchelintsev (pcheli) wrote :

@Brian no problem.

description: updated
information type: Private Security → Public
tags: added: security
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to cinder (stable/queens)

Fix proposed to branch: stable/queens
Review: https://review.opendev.org/733110

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to os-brick (master)

Reviewed: https://review.opendev.org/733098
Committed: https://git.openstack.org/cgit/openstack/os-brick/commit/?id=5414305a2b2c776be62b695c4144dd4ace7f5b30
Submitter: Zuul
Branch: master

commit 5414305a2b2c776be62b695c4144dd4ace7f5b30
Author: Ivan Pchelintsev <email address hidden>
Date: Mon Jun 1 11:28:08 2020 +0300

    Remove VxFlex OS credentials from connection_properties

    VxFlex OS password is not stored in block_device_mapping table. Instead of this
    passwords are stored in separate file and are retrieved during each attach/detach
    operation.

    Closes-Bug: #1823200
    Change-Id: Iab54c515fe7be252df52b1a0503a251779805759

Changed in os-brick:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to os-brick (stable/ussuri)

Reviewed: https://review.opendev.org/733099
Committed: https://git.openstack.org/cgit/openstack/os-brick/commit/?id=a1c9f649448bc91325b0735c48e780cce44df2c1
Submitter: Zuul
Branch: stable/ussuri

commit a1c9f649448bc91325b0735c48e780cce44df2c1
Author: Ivan Pchelintsev <email address hidden>
Date: Mon Jun 1 11:41:50 2020 +0300

    Remove VxFlex OS credentials from connection_properties

    VxFlex OS password is not stored in block_device_mapping table. Instead of this
    passwords are stored in separate file and are retrieved during each attach/detach
    operation.

    Closes-Bug: #1823200
    Change-Id: Iaa337518d6e6542a93d9e4f5d4d72094e9279c53

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to os-brick (stable/train)

Reviewed: https://review.opendev.org/733100
Committed: https://git.openstack.org/cgit/openstack/os-brick/commit/?id=55fc99852166f72b95d85dc917197f5544861e7c
Submitter: Zuul
Branch: stable/train

commit 55fc99852166f72b95d85dc917197f5544861e7c
Author: Ivan Pchelintsev <email address hidden>
Date: Mon Jun 1 11:51:54 2020 +0300

    Remove VxFlex OS credentials from connection_properties

    VxFlex OS password is not stored in block_device_mapping table. Instead of this
    passwords are stored in separate file and are retrieved during each attach/detach
    operation.

    Closes-Bug: #1823200
    Change-Id: Ia1d2b2151e5676037d40bfaf388b54023fc37093

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to os-brick (stable/stein)

Reviewed: https://review.opendev.org/733102
Committed: https://git.openstack.org/cgit/openstack/os-brick/commit/?id=b5891702cc24b0c9cedf6961d3223a37830341b9
Submitter: Zuul
Branch: stable/stein

commit b5891702cc24b0c9cedf6961d3223a37830341b9
Author: Ivan Pchelintsev <email address hidden>
Date: Mon Jun 1 11:59:06 2020 +0300

    Remove VxFlex OS credentials from connection_properties

    VxFlex OS password is not stored in block_device_mapping table. Instead of this
    passwords are stored in separate file and are retrieved during each attach/detach
    operation.

    Closes-Bug: #1823200
    Change-Id: I89bd58d79e5cd74cf283d026ada486b7f7122980

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to os-brick (stable/rocky)

Reviewed: https://review.opendev.org/733103
Committed: https://git.openstack.org/cgit/openstack/os-brick/commit/?id=88fbec6b1d8ac9a0f8f259a825e6139781021e3f
Submitter: Zuul
Branch: stable/rocky

commit 88fbec6b1d8ac9a0f8f259a825e6139781021e3f
Author: Ivan Pchelintsev <email address hidden>
Date: Mon Jun 1 12:11:19 2020 +0300

    Remove VxFlex OS credentials from connection_properties

    VxFlex OS password is not stored in block_device_mapping table. Instead of this
    passwords are stored in separate file and are retrieved during each attach/detach
    operation.

    Closes-Bug: 1823200
    Change-Id: I10a8aaddbf7dd09830cd4189cd1f99c0ad1f3b60

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to os-brick (stable/queens)

Reviewed: https://review.opendev.org/733104
Committed: https://git.openstack.org/cgit/openstack/os-brick/commit/?id=72c63681178286ed9cd1e1ab48969a64b9004d7c
Submitter: Zuul
Branch: stable/queens

commit 72c63681178286ed9cd1e1ab48969a64b9004d7c
Author: Ivan Pchelintsev <email address hidden>
Date: Tue Jun 2 16:23:04 2020 +0300

    Remove VxFlex OS credentials from connection_properties

    VxFlex OS password is not stored in block_device_mapping table. Instead of this
    passwords are stored in separate file and are retrieved during each attach/detach
    operation.

    Closes-Bug: #1823200
    Change-Id: Ib7778ba9d38a68d8b56ca632c5f1c353d55830b0

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to security-doc (master)

Reviewed: https://review.opendev.org/733116
Committed: https://git.openstack.org/cgit/openstack/security-doc/commit/?id=fade732411e3d349a49859fb7e9c3d89830ed792
Submitter: Zuul
Branch: master

commit fade732411e3d349a49859fb7e9c3d89830ed792
Author: Brian Rosmaita <email address hidden>
Date: Wed Jun 3 07:36:48 2020 -0400

    Add OSSN-0086

    Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure

    Closes-bug: #1823200
    Change-Id: I497c2ba8e297f9463f36313587de358cb1fde0ed

Changed in ossp-security-documentation:
status: In Progress → Fix Released
Revision history for this message
Brian Rosmaita (brian-rosmaita) wrote :

The Red Hat Product Security team has filed CVE-2020-10755 for this issue.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to os-brick (stable/pike)

Fix proposed to branch: stable/pike
Review: https://review.opendev.org/733615

Changed in cinder:
assignee: Ivan Pchelintsev (pcheli) → Sean McGinnis (sean-mcginnis)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to cinder (stable/ussuri)

Reviewed: https://review.opendev.org/733106
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=20a3cab7ddd9555eaa0406f539d491308f18e4e9
Submitter: Zuul
Branch: stable/ussuri

commit 20a3cab7ddd9555eaa0406f539d491308f18e4e9
Author: Ivan Pchelintsev <email address hidden>
Date: Mon Jun 1 11:43:20 2020 +0300

    Remove VxFlex OS credentials from connection_properties

    VxFlex OS password is not stored in block_device_mapping table. Instead of this
    passwords are stored in separate file and are retrieved during each attach/detach
    operation.

    Closes-Bug: #1823200
    Change-Id: I99de0b618d4ead78f921fde296cee4c7484387dd

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to cinder (stable/queens)

Reviewed: https://review.opendev.org/733110
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=89bdebd2a92f83a199c86855a63fd3deab9a489c
Submitter: Zuul
Branch: stable/queens

commit 89bdebd2a92f83a199c86855a63fd3deab9a489c
Author: Ivan Pchelintsev <email address hidden>
Date: Tue Jun 2 16:36:53 2020 +0300

    Remove VxFlex OS credentials from connection_properties

    VxFlex OS password is not stored in block_device_mapping table.
    Instead of this passwords are stored in separate file and are
    retrieved during each attach/detach operation.

    The stable/queens branch is in Extended Maintenance mode and is no
    longer released from. If you decide to apply this patch to your
    deployment, you must make a corresponding change to the os-brick
    library. You can find the os-brick patch for stable/queens here:
        https://review.opendev.org/#/c/733104

    Additionally, you must deploy a new configuration file on compute
    nodes, cinder nodes, and anywhere you would perform a volume
    attachment in your deployment. See the documentation change on
    this patch for details about the new config file.

    See OSSN-0086 for more information about this change:
        https://wiki.openstack.org/wiki/OSSN/OSSN-0086

    Closes-Bug: #1823200
    Change-Id: I831321d12a6df2b950f05e2452710b9ae105ada4

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to cinder (stable/pike)

Fix proposed to branch: stable/pike
Review: https://review.opendev.org/733662

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to cinder (master)

Reviewed: https://review.opendev.org/733105
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=b2c9592281b24824c2158f91a9295288f41dd81a
Submitter: Zuul
Branch: master

commit b2c9592281b24824c2158f91a9295288f41dd81a
Author: Ivan Pchelintsev <email address hidden>
Date: Mon Jun 1 11:32:38 2020 +0300

    Remove VxFlex OS credentials from connection_properties

    VxFlex OS password is not stored in block_device_mapping table. Instead of this
    passwords are stored in separate file and are retrieved during each attach/detach
    operation.

    Closes-Bug: #1823200
    Change-Id: Ia7cc17472677a693c6162f0b8b0529df62eed7cf

Changed in cinder:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to cinder (stable/stein)

Reviewed: https://review.opendev.org/733108
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=25ed65f1fa1d50cf3d5f757736b6cfb506ce402f
Submitter: Zuul
Branch: stable/stein

commit 25ed65f1fa1d50cf3d5f757736b6cfb506ce402f
Author: Ivan Pchelintsev <email address hidden>
Date: Mon Jun 1 12:00:50 2020 +0300

    Remove VxFlex OS credentials from connection_properties

    VxFlex OS password is not stored in block_device_mapping table. Instead of this
    passwords are stored in separate file and are retrieved during each attach/detach
    operation.

    Closes-Bug: #1823200
    Change-Id: I3f6bfe360491c295bdb81008c31ad2d4e3305736

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to cinder (stable/train)

Reviewed: https://review.opendev.org/733107
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=aadf0950c9c62f68a107c89c5b7c7632a2c732db
Submitter: Zuul
Branch: stable/train

commit aadf0950c9c62f68a107c89c5b7c7632a2c732db
Author: Ivan Pchelintsev <email address hidden>
Date: Mon Jun 1 11:50:01 2020 +0300

    Remove VxFlex OS credentials from connection_properties

    VxFlex OS password is not stored in block_device_mapping table. Instead of this
    passwords are stored in separate file and are retrieved during each attach/detach
    operation.

    Closes-Bug: #1823200
    Change-Id: Ie9c41f37ab5c186b9f9aa92539a363d0b2388035

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to cinder (stable/rocky)

Reviewed: https://review.opendev.org/733109
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=c427484d75e276aa02dcd7586e2f8bed3780878c
Submitter: Zuul
Branch: stable/rocky

commit c427484d75e276aa02dcd7586e2f8bed3780878c
Author: Ivan Pchelintsev <email address hidden>
Date: Mon Jun 1 12:12:53 2020 +0300

    Remove VxFlex OS credentials from connection_properties

    VxFlex OS password is not stored in block_device_mapping table.
    Instead of this passwords are stored in separate file and are
    retrieved during each attach/detach operation.

    The stable/rocky branch is in Extended Maintenance mode and is no
    longer released from. If you decide to apply this patch to your
    deployment, you must make a corresponding change to the os-brick
    library. You can find the os-brick patch for stable/rocky here:
        https://review.opendev.org/#/c/733103/

    Additionally, you must deploy a new configuration file on compute
    nodes, cinder nodes, and anywhere you would perform a volume
    attachment in your deployment. See the documentation change on
    this patch for details about the new config file.

    See OSSN-0086 for more information about this change:
        https://wiki.openstack.org/wiki/OSSN/OSSN-0086

    Closes-Bug: #1823200
    Change-Id: Ic115fbe455c00589e7b8e60eca91e979bac276ea

Changed in python-os-brick (Ubuntu Groovy):
importance: Undecided → High
status: New → Triaged
tags: added: patch
Changed in python-os-brick (Ubuntu Focal):
importance: Undecided → High
status: New → Triaged
Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "cinder.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

Changed in python-os-brick (Ubuntu Eoan):
importance: Undecided → High
status: New → Triaged
Changed in python-os-brick (Ubuntu Bionic):
importance: Undecided → High
status: New → Triaged
Changed in python-os-brick (Ubuntu Groovy):
status: Triaged → Fix Released
Changed in cinder (Ubuntu Groovy):
importance: Undecided → High
status: New → Triaged
Changed in cinder (Ubuntu Focal):
importance: Undecided → High
status: New → Triaged
Changed in cinder (Ubuntu Eoan):
importance: Undecided → High
status: New → Triaged
Changed in cinder (Ubuntu Bionic):
importance: Undecided → High
status: New → Triaged
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package cinder - 2:17.0.0~b1~git2020062409.85fcf1057-0ubuntu1

---------------
cinder (2:17.0.0~b1~git2020062409.85fcf1057-0ubuntu1) groovy; urgency=medium

  * SECURITY UPDATE: Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
    (LP: #1823200)
    - Remove VxFlex OS credentials from connection_properties. Passwords are
      now stored in separate file and are retrieved during each attach/detach
      operation. Cinder is patched in 16.1.0 stable point release.
    - d/control: Align (Build-)Depends with min version of python3-os-brick
      required to fix credential exposure.
    - CVE-2020-10755
  * New upstream snapshot for OpenStack Victoria.
  * d/control: Align (Build-)Depends with upstream.
  * d/p/py38skip.patch: Dropped. No longer needed.
  * d/p/skip-victoria-failures.patch: Rebased and updated with upstream bug.

 -- Corey Bryant <email address hidden> Wed, 24 Jun 2020 09:10:19 -0400

Changed in cinder (Ubuntu Groovy):
status: Triaged → Fix Released
Changed in cloud-archive:
status: Triaged → Fix Committed
Revision history for this message
Corey Bryant (corey.bryant) wrote :

This bug was fixed in the package cinder - 2:17.0.0~b1~git2020062409.85fcf1057-0ubuntu1~cloud0
---------------

 cinder (2:17.0.0~b1~git2020062409.85fcf1057-0ubuntu1~cloud0) focal-victoria; urgency=medium
 .
   * New upstream release for the Ubuntu Cloud Archive.
 .
 cinder (2:17.0.0~b1~git2020062409.85fcf1057-0ubuntu1) groovy; urgency=medium
 .
   * SECURITY UPDATE: Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
     (LP: #1823200)
     - Remove VxFlex OS credentials from connection_properties. Passwords are
       now stored in separate file and are retrieved during each attach/detach
       operation. Cinder is patched in 16.1.0 stable point release.
     - d/control: Align (Build-)Depends with min version of python3-os-brick
       required to fix credential exposure.
     - CVE-2020-10755
   * New upstream snapshot for OpenStack Victoria.
   * d/control: Align (Build-)Depends with upstream.
   * d/p/py38skip.patch: Dropped. No longer needed.
   * d/p/skip-victoria-failures.patch: Rebased and updated with upstream bug.
 .
 cinder (2:16.0.0-0ubuntu2) groovy; urgency=medium
 .
   * d/p/skip-victoria-failures.patch: Temporarily skipping groovy
     failures to unblock Ussuri.
 .
 cinder (2:16.0.0-0ubuntu1) groovy; urgency=medium
 .
   * d/watch: Update tarball version.
   * d/p/py38skip.patch: Refresh patch.
   * New upstream release for OpenStack Ussuri (LP: #1877642).
   * d/p/monkey-patch-original-current-thread.patch: Removed as it is
     merged into rc3 upstream.

Changed in cloud-archive:
status: Fix Committed → Fix Released
Revision history for this message
Corey Bryant (corey.bryant) wrote : Please test proposed package

Hello Eric, or anyone else affected,

Accepted cinder into train-proposed. The package will build now and be available in the Ubuntu Cloud Archive in a few hours, and then in the -proposed repository.

Please help us by testing this new package. To enable the -proposed repository:

  sudo add-apt-repository cloud-archive:train-proposed
  sudo apt-get update

Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-train-needed to verification-train-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-train-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

tags: added: verification-train-needed
Revision history for this message
Corey Bryant (corey.bryant) wrote :

Hello Eric, or anyone else affected,

Accepted python-os-brick into train-proposed. The package will build now and be available in the Ubuntu Cloud Archive in a few hours, and then in the -proposed repository.

Please help us by testing this new package. To enable the -proposed repository:

  sudo add-apt-repository cloud-archive:train-proposed
  sudo apt-get update

Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-train-needed to verification-train-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-train-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Revision history for this message
Corey Bryant (corey.bryant) wrote :

Hello Eric, or anyone else affected,

Accepted cinder into stein-proposed. The package will build now and be available in the Ubuntu Cloud Archive in a few hours, and then in the -proposed repository.

Please help us by testing this new package. To enable the -proposed repository:

  sudo add-apt-repository cloud-archive:stein-proposed
  sudo apt-get update

Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-stein-needed to verification-stein-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-stein-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

tags: added: verification-stein-needed
Revision history for this message
Corey Bryant (corey.bryant) wrote :

Hello Eric, or anyone else affected,

Accepted python-os-brick into stein-proposed. The package will build now and be available in the Ubuntu Cloud Archive in a few hours, and then in the -proposed repository.

Please help us by testing this new package. To enable the -proposed repository:

  sudo add-apt-repository cloud-archive:stein-proposed
  sudo apt-get update

Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-stein-needed to verification-stein-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-stein-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Revision history for this message
Corey Bryant (corey.bryant) wrote :

Hello Eric, or anyone else affected,

Accepted cinder into rocky-proposed. The package will build now and be available in the Ubuntu Cloud Archive in a few hours, and then in the -proposed repository.

Please help us by testing this new package. To enable the -proposed repository:

  sudo add-apt-repository cloud-archive:rocky-proposed
  sudo apt-get update

Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-rocky-needed to verification-rocky-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-rocky-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

tags: added: verification-rocky-needed
Revision history for this message
Corey Bryant (corey.bryant) wrote :

Hello Eric, or anyone else affected,

Accepted python-os-brick into rocky-proposed. The package will build now and be available in the Ubuntu Cloud Archive in a few hours, and then in the -proposed repository.

Please help us by testing this new package. To enable the -proposed repository:

  sudo add-apt-repository cloud-archive:rocky-proposed
  sudo apt-get update

Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-rocky-needed to verification-rocky-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-rocky-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to cinder (stable/pike)

Fix proposed to branch: stable/pike
Review: https://review.opendev.org/739545

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on cinder (stable/pike)

Change abandoned by Sean McGinnis (<email address hidden>) on branch: stable/pike
Review: https://review.opendev.org/739545
Reason: https://review.opendev.org/#/c/733662/

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package python-os-brick - 3.0.1-0ubuntu1.2

---------------
python-os-brick (3.0.1-0ubuntu1.2) focal-security; urgency=medium

  * d/gbp.conf: Create stable/ussuri branch.
  * SECURITY UPDATE: Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
    (LP: #1823200)
    - debian/patches/CVE-2020-10755.patch: Remove VxFlex OS credentials
      from connection_properties. Passwords are now stored in separate file
      and are retrieved during each attach/detach operation.
    - CVE-2020-10755

 -- Corey Bryant <email address hidden> Mon, 08 Jun 2020 09:25:57 -0400

Changed in python-os-brick (Ubuntu Focal):
status: Triaged → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package python-os-brick - 2.3.0-0ubuntu1.2

---------------
python-os-brick (2.3.0-0ubuntu1.2) bionic-security; urgency=medium

  * d/gbp.conf: Create stable/queens branch.
  * SECURITY UPDATE: Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
    (LP: #1823200)
    - debian/patches/CVE-2020-10755*.patch: Remove VxFlex OS credentials
      from connection_properties. Passwords are now stored in separate file
      and are retrieved during each attach/detach operation.
    - CVE-2020-10755

 -- Corey Bryant <email address hidden> Thu, 26 Apr 2018 13:34:33 -0400

Changed in python-os-brick (Ubuntu Bionic):
status: Triaged → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package cinder - 2:16.1.0-0ubuntu1

---------------
cinder (2:16.1.0-0ubuntu1) focal-security; urgency=medium

  [ Chris MacNaughton ]
  * New stable point release for OpenStack Ussuri (LP: #1883879).

  [ Corey Bryant ]
  * SECURITY UPDATE: Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
    (LP: #1823200)
    - Remove VxFlex OS credentials from connection_properties. Passwords are
      now stored in separate file and are retrieved during each attach/detach
      operation. Cinder is patched in 16.1.0 stable point release.
    - d/control: Align (Build-)Depends with min version of python3-os-brick
      required to fix credential exposure.
    - CVE-2020-10755

 -- Corey Bryant <email address hidden> Tue, 23 Jun 2020 16:52:33 -0400

Changed in cinder (Ubuntu Focal):
status: Triaged → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package cinder - 2:12.0.9-0ubuntu1.2

---------------
cinder (2:12.0.9-0ubuntu1.2) bionic-security; urgency=medium

  * SECURITY UPDATE: Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
    (LP: #1823200)
    - debian/patches/CVE-2020-10755.patch: Remove VxFlex OS credentials
      from connection_properties. Passwords are now stored in separate file
      and are retrieved during each attach/detach operation.
    - d/control: Align (Build-)Depends with min version of python3-os-brick
      required to fix credential exposure.
    - CVE-2020-10755

 -- Corey Bryant <email address hidden> Tue, 23 Jun 2020 15:58:12 -0400

Changed in cinder (Ubuntu Bionic):
status: Triaged → Fix Released
Revision history for this message
Corey Bryant (corey.bryant) wrote : Please test proposed package

Hello Eric, or anyone else affected,

Accepted python-os-brick into ussuri-proposed. The package will build now and be available in the Ubuntu Cloud Archive in a few hours, and then in the -proposed repository.

Please help us by testing this new package. To enable the -proposed repository:

  sudo add-apt-repository cloud-archive:ussuri-proposed
  sudo apt-get update

Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-ussuri-needed to verification-ussuri-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-ussuri-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

tags: added: verification-ussuri-needed
Revision history for this message
Corey Bryant (corey.bryant) wrote :

Hello Eric, or anyone else affected,

Accepted cinder into ussuri-proposed. The package will build now and be available in the Ubuntu Cloud Archive in a few hours, and then in the -proposed repository.

Please help us by testing this new package. To enable the -proposed repository:

  sudo add-apt-repository cloud-archive:ussuri-proposed
  sudo apt-get update

Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-ussuri-needed to verification-ussuri-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-ussuri-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Revision history for this message
Corey Bryant (corey.bryant) wrote : Update Released

The verification of the Stable Release Update for cinder has completed successfully and the package has now been released to -updates. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message
Corey Bryant (corey.bryant) wrote :

This bug was fixed in the package cinder - 2:16.1.0-0ubuntu1~cloud0
---------------

 cinder (2:16.1.0-0ubuntu1~cloud0) bionic-ussuri; urgency=medium
 .
   * New upstream release for the Ubuntu Cloud Archive.
 .
 cinder (2:16.1.0-0ubuntu1) focal-security; urgency=medium
 .
   [ Chris MacNaughton ]
   * New stable point release for OpenStack Ussuri (LP: #1883879).
 .
   [ Corey Bryant ]
   * SECURITY UPDATE: Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
     (LP: #1823200)
     - Remove VxFlex OS credentials from connection_properties. Passwords are
       now stored in separate file and are retrieved during each attach/detach
       operation. Cinder is patched in 16.1.0 stable point release.
     - d/control: Align (Build-)Depends with min version of python3-os-brick
       required to fix credential exposure.
     - CVE-2020-10755

Revision history for this message
Corey Bryant (corey.bryant) wrote :

The verification of the Stable Release Update for python-os-brick has completed successfully and the package has now been released to -updates. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message
Corey Bryant (corey.bryant) wrote :

This bug was fixed in the package python-os-brick - 3.0.1-0ubuntu1.2~cloud0
---------------

 python-os-brick (3.0.1-0ubuntu1.2~cloud0) bionic-ussuri; urgency=medium
 .
   * New update for the Ubuntu Cloud Archive.
 .
 python-os-brick (3.0.1-0ubuntu1.2) focal-security; urgency=medium
 .
   * d/gbp.conf: Create stable/ussuri branch.
   * SECURITY UPDATE: Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
     (LP: #1823200)
     - debian/patches/CVE-2020-10755.patch: Remove VxFlex OS credentials
       from connection_properties. Passwords are now stored in separate file
       and are retrieved during each attach/detach operation.
     - CVE-2020-10755

Revision history for this message
Corey Bryant (corey.bryant) wrote :

The verification of the Stable Release Update for cinder has completed successfully and the package has now been released to -updates. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message
Corey Bryant (corey.bryant) wrote :

This bug was fixed in the package cinder - 2:15.2.0-0ubuntu1~cloud0
---------------

 cinder (2:15.2.0-0ubuntu1~cloud0) bionic-train; urgency=medium
 .
   [ Chris MacNaughton ]
   * New stable point release for OpenStack Train (LP: #1883892)
   * d/control: Align (Build-)Depends with upstream.
 .
   [ Corey Bryant ]
   * SECURITY UPDATE: Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
     (LP: #1823200)
     - Remove VxFlex OS credentials from connection_properties. Passwords are
       now stored in separate file and are retrieved during each attach/detach
       operation. Cinder is patched in 15.2.0 stable point release.
     - d/control: Align (Build-)Depends with min version of python3-os-brick
       required to fix credential exposure.
     - CVE-2020-10755

Revision history for this message
Corey Bryant (corey.bryant) wrote :

The verification of the Stable Release Update for python-os-brick has completed successfully and the package has now been released to -updates. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message
Corey Bryant (corey.bryant) wrote :

This bug was fixed in the package python-os-brick - 2.10.0-0ubuntu1~cloud0.1
---------------

 python-os-brick (2.10.0-0ubuntu1~cloud0.1) bionic-train; urgency=medium
 .
   * d/gbp.conf: Create stable/train branch.
   * SECURITY UPDATE: Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
     (LP: #1823200)
     - debian/patches/CVE-2020-10755*.patch: Remove VxFlex OS credentials
       from connection_properties. Passwords are now stored in separate file
       and are retrieved during each attach/detach operation.
     - CVE-2020-10755

Revision history for this message
Corey Bryant (corey.bryant) wrote :

Eoan is EOL

Changed in cinder (Ubuntu Eoan):
status: Triaged → Won't Fix
Changed in python-os-brick (Ubuntu Eoan):
status: Triaged → Won't Fix
Revision history for this message
Corey Bryant (corey.bryant) wrote :

The verification of the Stable Release Update for cinder has completed successfully and the package has now been released to -updates. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message
Corey Bryant (corey.bryant) wrote :

This bug was fixed in the package cinder - 2:14.1.0-0ubuntu1~cloud0
---------------

 cinder (2:14.1.0-0ubuntu1~cloud0) bionic-stein; urgency=medium
 .
   [ Chris MacNaughton ]
   * New stable point release for OpenStack Stein (LP: #1884028).
 .
   [ Corey Bryant ]
   * SECURITY UPDATE: Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
     (LP: #1823200)
     - Remove VxFlex OS credentials from connection_properties. Passwords are
       now stored in separate file and are retrieved during each attach/detach
       operation. Cinder is patched in 14.1.0 stable point release.
     - d/control: Align (Build-)Depends with min version of python3-os-brick
       required to fix credential exposure.
     - CVE-2020-10755

Revision history for this message
Corey Bryant (corey.bryant) wrote :

The verification of the Stable Release Update for cinder has completed successfully and the package has now been released to -updates. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message
Corey Bryant (corey.bryant) wrote :

This bug was fixed in the package cinder - 2:13.0.9-0ubuntu1~cloud1.1
---------------

 cinder (2:13.0.9-0ubuntu1~cloud1.1) bionic-rocky; urgency=medium
 .
   * SECURITY UPDATE: Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
     (LP: #1823200)
     - debian/patches/CVE-2020-10755.patch: Remove VxFlex OS credentials
       from connection_properties. Passwords are now stored in separate file
       and are retrieved during each attach/detach operation.
     - d/control: Align (Build-)Depends with min version of python3-os-brick
       required to fix credential exposure.
     - CVE-2020-10755
   * d/control: Add python3-sqlalchemy-utils Build-Depends to enable successful
     test execution.

Revision history for this message
Corey Bryant (corey.bryant) wrote :

The verification of the Stable Release Update for python-os-brick has completed successfully and the package has now been released to -updates. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message
Corey Bryant (corey.bryant) wrote :

This bug was fixed in the package python-os-brick - 2.5.3-0ubuntu1~cloud0.1
---------------

 python-os-brick (2.5.3-0ubuntu1~cloud0.1) bionic-rocky; urgency=medium
 .
   * d/gbp.conf: Create stable/rocky branch.
   * SECURITY UPDATE: Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
     (LP: #1823200)
     - debian/patches/CVE-2020-10755*.patch: Remove VxFlex OS credentials
       from connection_properties. Passwords are now stored in separate file
       and are retrieved during each attach/detach operation.
     - CVE-2020-10755

Revision history for this message
Corey Bryant (corey.bryant) wrote :

This bug was fixed in the package python-os-brick - 2.8.1-0ubuntu1~cloud0.1
---------------

 python-os-brick (2.8.1-0ubuntu1~cloud0.1) bionic-stein; urgency=medium
 .
   * d/gbp.conf: Create stable/stein branch.
   * SECURITY UPDATE: Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
     (LP: #1823200)
     - debian/patches/CVE-2020-10755*.patch: Remove VxFlex OS credentials
       from connection_properties. Passwords are now stored in separate file
       and are retrieved during each attach/detach operation.
     - CVE-2020-10755

Revision history for this message
Corey Bryant (corey.bryant) wrote : Please test proposed package

Hello Eric, or anyone else affected,

Accepted cinder into queens-proposed. The package will build now and be available in the Ubuntu Cloud Archive in a few hours, and then in the -proposed repository.

Please help us by testing this new package. To enable the -proposed repository:

  sudo add-apt-repository cloud-archive:queens-proposed
  sudo apt-get update

Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-queens-needed to verification-queens-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-queens-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

tags: added: verification-queens-needed
Revision history for this message
Corey Bryant (corey.bryant) wrote : Update Released

The verification of the Stable Release Update for cinder has completed successfully and the package has now been released to -updates. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message
Corey Bryant (corey.bryant) wrote :

This bug was fixed in the package cinder - 2:12.0.9-0ubuntu1.2~cloud0
---------------

 cinder (2:12.0.9-0ubuntu1.2~cloud0) xenial-queens; urgency=medium
 .
   * New update for the Ubuntu Cloud Archive.
 .
 cinder (2:12.0.9-0ubuntu1.2) bionic-security; urgency=medium
 .
   * SECURITY UPDATE: Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
     (LP: #1823200)
     - debian/patches/CVE-2020-10755.patch: Remove VxFlex OS credentials
       from connection_properties. Passwords are now stored in separate file
       and are retrieved during each attach/detach operation.
     - d/control: Align (Build-)Depends with min version of python3-os-brick
       required to fix credential exposure.
     - CVE-2020-10755

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to os-brick (stable/pike)

Reviewed: https://review.opendev.org/733615
Committed: https://git.openstack.org/cgit/openstack/os-brick/commit/?id=4047948f1ac8055a025972ad73ec3ec421450775
Submitter: Zuul
Branch: stable/pike

commit 4047948f1ac8055a025972ad73ec3ec421450775
Author: Ivan Pchelintsev <email address hidden>
Date: Tue Jun 2 16:23:04 2020 +0300

    Remove VxFlex OS credentials from connection_properties

    VxFlex OS password is not stored in block_device_mapping table. Instead of this
    passwords are stored in separate file and are retrieved during each attach/detach
    operation.

    Closes-Bug: #1823200
    Change-Id: Ib7778ba9d38a68d8b56ca632c5f1c353d55830b0
    (cherry picked from commit 72c63681178286ed9cd1e1ab48969a64b9004d7c)

tags: added: in-stable-pike
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to cinder (stable/pike)

Reviewed: https://review.opendev.org/733662
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=ba785eef5f515b869c0d68016e84bb74f76ab45e
Submitter: Zuul
Branch: stable/pike

commit ba785eef5f515b869c0d68016e84bb74f76ab45e
Author: Ivan Pchelintsev <email address hidden>
Date: Thu Jun 4 19:57:56 2020 +0300

    Remove VxFlex OS credentials from connection_properties

    VxFlex OS password is not stored in block_device_mapping table.
    Instead of this passwords are stored in separate file and are
    retrieved during each attach/detach operation.

    The stable/pike branch is in Extended Maintenance mode and is no
    longer released from. If you decide to apply this patch to your
    deployment, you must make a corresponding change to the os-brick
    library. You can find the os-brick patch for stable/pike here:
        https://review.opendev.org/#/c/733615

    Additionally, you must deploy a new configuration file on compute
    nodes, cinder nodes, and anywhere you would perform a volume
    attachment in your deployment. See the documentation change on
    this patch for details about the new config file.

    See OSSN-0086 for more information about this change:
        https://wiki.openstack.org/wiki/OSSN/OSSN-0086

    Change-Id: I975922b2ac951988e51743cd9f2f6f76be520840
    Closes-Bug: #1823200

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to os-brick (master)

Related fix proposed to branch: master
Review: https://review.opendev.org/746109

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to os-brick (master)

Reviewed: https://review.opendev.org/746109
Committed: https://git.openstack.org/cgit/openstack/os-brick/commit/?id=54504830828757e9d72e9440dde9cff33684a74d
Submitter: Zuul
Branch: master

commit 54504830828757e9d72e9440dde9cff33684a74d
Author: Gorka Eguileor <email address hidden>
Date: Thu Aug 13 13:13:02 2020 +0200

    ScaleIO: Connection info backward compatibility

    When we fixed bug 1823200 in Change-ID
    Iab54c515fe7be252df52b1a0503a251779805759 we made the ScaleIO connector
    incompatible with the old connection properties dictionary as it only
    supported the new 'config_group' and 'failed_over' parameters to get the
    password.

    This is a problem in any system that is upgraded and has attachments to
    the array, because the connection properties of those volumes will not
    contain the new fields and detaching them will result in error
    "KeyError: 'config_group'".

    This patch adds compatibility code to support the old connection
    properties format so we can detach those volumes.

    Related-Bug: #1823200
    Change-Id: I6f01a178616b74ed9a86876ca46e7e46eb360518

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to os-brick (stable/ussuri)

Related fix proposed to branch: stable/ussuri
Review: https://review.opendev.org/746572

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to os-brick (stable/ussuri)

Reviewed: https://review.opendev.org/746572
Committed: https://git.openstack.org/cgit/openstack/os-brick/commit/?id=31589a624fe8d2ebb56ccbd9c94a8dd559a7da89
Submitter: Zuul
Branch: stable/ussuri

commit 31589a624fe8d2ebb56ccbd9c94a8dd559a7da89
Author: Gorka Eguileor <email address hidden>
Date: Thu Aug 13 13:13:02 2020 +0200

    ScaleIO: Connection info backward compatibility

    When we fixed bug 1823200 in Change-ID
    Iab54c515fe7be252df52b1a0503a251779805759 we made the ScaleIO connector
    incompatible with the old connection properties dictionary as it only
    supported the new 'config_group' and 'failed_over' parameters to get the
    password.

    This is a problem in any system that is upgraded and has attachments to
    the array, because the connection properties of those volumes will not
    contain the new fields and detaching them will result in error
    "KeyError: 'config_group'".

    This patch adds compatibility code to support the old connection
    properties format so we can detach those volumes.

    Related-Bug: #1823200
    Change-Id: I6f01a178616b74ed9a86876ca46e7e46eb360518
    (cherry picked from commit 54504830828757e9d72e9440dde9cff33684a74d)

tags: added: in-stable-ussuri
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to os-brick (stable/train)

Related fix proposed to branch: stable/train
Review: https://review.opendev.org/746621

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to os-brick (stable/train)

Reviewed: https://review.opendev.org/746621
Committed: https://git.openstack.org/cgit/openstack/os-brick/commit/?id=db95b001e2fe53a71ec0b881407ecdf7c3db32fc
Submitter: Zuul
Branch: stable/train

commit db95b001e2fe53a71ec0b881407ecdf7c3db32fc
Author: Gorka Eguileor <email address hidden>
Date: Thu Aug 13 13:13:02 2020 +0200

    ScaleIO: Connection info backward compatibility

    When we fixed bug 1823200 in Change-ID
    Iab54c515fe7be252df52b1a0503a251779805759 we made the ScaleIO connector
    incompatible with the old connection properties dictionary as it only
    supported the new 'config_group' and 'failed_over' parameters to get the
    password.

    This is a problem in any system that is upgraded and has attachments to
    the array, because the connection properties of those volumes will not
    contain the new fields and detaching them will result in error
    "KeyError: 'config_group'".

    This patch adds compatibility code to support the old connection
    properties format so we can detach those volumes.

    Related-Bug: #1823200
    Change-Id: I6f01a178616b74ed9a86876ca46e7e46eb360518
    (cherry picked from commit 54504830828757e9d72e9440dde9cff33684a74d)
    (cherry picked from commit 31589a624fe8d2ebb56ccbd9c94a8dd559a7da89)
    Conflicts:
            os_brick/initiator/connectors/scaleio.py

tags: added: in-stable-train
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to os-brick (stable/stein)

Related fix proposed to branch: stable/stein
Review: https://review.opendev.org/749833

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to os-brick (stable/stein)

Reviewed: https://review.opendev.org/749833
Committed: https://git.openstack.org/cgit/openstack/os-brick/commit/?id=173601116eb5e00274b10898b56b37dc42d685ac
Submitter: Zuul
Branch: stable/stein

commit 173601116eb5e00274b10898b56b37dc42d685ac
Author: Gorka Eguileor <email address hidden>
Date: Thu Aug 13 13:13:02 2020 +0200

    ScaleIO: Connection info backward compatibility

    When we fixed bug 1823200 in Change-ID
    Iab54c515fe7be252df52b1a0503a251779805759 we made the ScaleIO connector
    incompatible with the old connection properties dictionary as it only
    supported the new 'config_group' and 'failed_over' parameters to get the
    password.

    This is a problem in any system that is upgraded and has attachments to
    the array, because the connection properties of those volumes will not
    contain the new fields and detaching them will result in error
    "KeyError: 'config_group'".

    This patch adds compatibility code to support the old connection
    properties format so we can detach those volumes.

    This patch includes the release note from Change
    Ib98043358d51426ca650104ad59a7e09911ee8e9

    Related-Bug: #1823200
    Change-Id: I6f01a178616b74ed9a86876ca46e7e46eb360518
    (cherry picked from commit 54504830828757e9d72e9440dde9cff33684a74d)
    (cherry picked from commit 31589a624fe8d2ebb56ccbd9c94a8dd559a7da89)
    Conflicts:
            os_brick/initiator/connectors/scaleio.py
    (cherry picked from commit db95b001e2fe53a71ec0b881407ecdf7c3db32fc)

tags: added: in-stable-stein
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to cinder (stable/ussuri)

Related fix proposed to branch: stable/ussuri
Review: https://review.opendev.org/750050

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to cinder (stable/train)

Related fix proposed to branch: stable/train
Review: https://review.opendev.org/750051

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to cinder (stable/stein)

Related fix proposed to branch: stable/stein
Review: https://review.opendev.org/750052

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to cinder (stable/ussuri)

Reviewed: https://review.opendev.org/750050
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=7a20d32e85f0c1614a6687eb5142ef2e020f2fd4
Submitter: Zuul
Branch: stable/ussuri

commit 7a20d32e85f0c1614a6687eb5142ef2e020f2fd4
Author: Brian Rosmaita <email address hidden>
Date: Fri Sep 4 17:28:01 2020 -0400

    Require os-brick >= 3.0.3

    This version of brick contains a fix related to OSSN-0086, among
    other things.

    Change-Id: If0216831d616fc9d6c1907fc5ea6e796ab85ac39
    Related-bug: #1823200

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to cinder (stable/train)

Reviewed: https://review.opendev.org/750051
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=9e3e2ab25dac1e38d2344b0dd115204aa12db971
Submitter: Zuul
Branch: stable/train

commit 9e3e2ab25dac1e38d2344b0dd115204aa12db971
Author: Brian Rosmaita <email address hidden>
Date: Fri Sep 4 17:35:20 2020 -0400

    Require os-brick >= 2.10.5

    This version of brick contains a fix related to OSSN-0086, among
    other things.

    Depends-on: https://review.opendev.org/749905
    Change-Id: I2fb85babb34add6f705adc0e6a2b5b69fef3fbe7
    Related-bug: #1823200

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to cinder (stable/stein)

Reviewed: https://review.opendev.org/750052
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=4cc9e7b5f101fb099d4840e91ee068880e5d29bd
Submitter: Zuul
Branch: stable/stein

commit 4cc9e7b5f101fb099d4840e91ee068880e5d29bd
Author: Brian Rosmaita <email address hidden>
Date: Fri Sep 4 17:41:54 2020 -0400

    Require os-brick >= 2.8.7

    This version of brick contains a fix related to OSSN-0086, among
    other things.

    Depends-on: https://review.opendev.org/750045
    Change-Id: I68130667e9c454b7f4e6d023401796226175c4bd
    Related-bug: #1823200

Revision history for this message
Brian Rosmaita (brian-rosmaita) wrote :

I want to add an addendum to comment #55. That roll-out plan worked fine, except that we should have used the same Change-Id on all the cinder patches, and same Change-Id on all the os-brick patches. This would have made it easier for people looking to see which branches contained the fix, because they would have been connected in the way backports usually are.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/cinder queens-eol

This issue was fixed in the openstack/cinder queens-eol release.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/os-brick queens-eol

This issue was fixed in the openstack/os-brick queens-eol release.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/cinder rocky-eol

This issue was fixed in the openstack/cinder rocky-eol release.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/os-brick rocky-eol

This issue was fixed in the openstack/os-brick rocky-eol release.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.