Open Stack

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

Log:
commit b37c5ad35ee09f79fbb8f4ba180ed9aebc031107
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