[Yahoo-eng-team] [Bug 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection)
In Cinder, the following drivers are using six.moves.http_client, which on python 2.7 I believe calls httplib: Location: cinder/cinder/volume/drivers/blockbridge.py:149 Location: cinder/cinder/volume/drivers/cloudbyte/cloudbyte.py:116 Location: cinder/cinder/volume/drivers/prophetstor/dplcommon.py:102 Location: cinder/cinder/volume/drivers/prophetstor/dplcommon.py:124 Location: cinder/cinder/volume/drivers/qnap.py:814 Location: cinder/cinder/volume/drivers/zadara.py:238 See reference of six.moves.http_client calling httplib here: https://pythonhosted.org/six/ Re-opening the bug. ** Changed in: cinder Status: Invalid => Triaged -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: Triaged Status in OpenStack Identity (keystone): Fix Released Status in neutron: Fix Released Status in oslo.vmware: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Fix Released Status in python-keystoneclient: Fix Released Status in OpenStack Object Storage (swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1387807] [NEW] Rollback is needed if attach volume times out.
Public bug reported: During attach volume operation, initialize_connection in Cinder is called. If timeout happens during initialize_connection, the volume state will be changed back to available. However, volume could be already mapped to the host on the array. This leaves the database and array out of sync. If rescan happens on the host after this, the volumes could show up as faulty devices when issuing the multipath command. The timeout exception during attach volume should be handled and a rollback should be triggered by calling terminate_connection in Cinder. ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1387807 Title: Rollback is needed if attach volume times out. Status in OpenStack Compute (Nova): New Bug description: During attach volume operation, initialize_connection in Cinder is called. If timeout happens during initialize_connection, the volume state will be changed back to available. However, volume could be already mapped to the host on the array. This leaves the database and array out of sync. If rescan happens on the host after this, the volumes could show up as faulty devices when issuing the multipath command. The timeout exception during attach volume should be handled and a rollback should be triggered by calling terminate_connection in Cinder. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1387807/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1266051] [NEW] Attach/detach volume iSCSI multipath doesn't work properly if there are different targets associated with different portals for a mulitpath device.
Public bug reported: The connect_volume and disconnect_volume code in LibvirtISCSIVolumeDriver assumes that the targets for different portals are the same for the same multipath device. This is true for some arrays but not for others. When there are different targets associated with different portals for the same multipath device, multipath doesn't work properly during attach/detach volume operations. ** Affects: nova Importance: Undecided Assignee: Xing Yang (xing-yang) Status: In Progress ** Changed in: nova Assignee: (unassigned) = Xing Yang (xing-yang) ** Changed in: nova Status: New = In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1266051 Title: Attach/detach volume iSCSI multipath doesn't work properly if there are different targets associated with different portals for a mulitpath device. Status in OpenStack Compute (Nova): In Progress Bug description: The connect_volume and disconnect_volume code in LibvirtISCSIVolumeDriver assumes that the targets for different portals are the same for the same multipath device. This is true for some arrays but not for others. When there are different targets associated with different portals for the same multipath device, multipath doesn't work properly during attach/detach volume operations. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1266051/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp