Open Stack

Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/514734

Log:
commit d75726f09ac04f8252a6187ba861618e9a9cbc5f
Author: Alan Bishop <abishop at redhat.com>
Date:   Tue Oct 24 14:53:36 2017 +0000

    Support handling legacy all-zeros key ID
    
    This patch addresses a specific use case, where a user has encrypted volumes
    based on the fixed_key used by Cinder's and Nova's ConfKeyManager. The user
    wishes to switch to Barbican, but existing volumes must continue to function
    during the migration period.
    
    The code conditionally adds a shim around the backend KeyManager when both
    of these conditions are met:
    
    1) The configuration contains a fixed_key value. This essentially signals
       the ConfKeyManager has been in use at one time
    2) The current backend is *not* the ConfKeyManager
    
    When the shim is active, a MigrationKeyManager class is dynamically created
    that extends the backend's KeyManager class. The MigrationKeyManager exists
    solely to override two functions:
    
    o The KeyManager.get() function detects requests for the secret associated
      with the fixed_key, which is identified by an all-zeros key ID.
    
      - Requests for the all-zeros key ID are handled by mimicing the
        ConfKeyManager's response, which is a secret derived from the fixed_key.
      - Requests for any other key ID are passed on to the real backend.
    
    o The KeyManager.delete() function is similar:
    
      - Requests to delete the all-zeros key ID are essentially ignored, just as
        is done by the ConfKeyManager.
      - Requests to delete any other key ID are passed on to the real backend.
    
    All other KeyManager functions are not overridden, and will therefore be
    handled directly by the real backend.
    
    SecurityImpact
    Change-Id: Ia5316490201c33e23a4206838d5a4fb3dd00f527