[Freeipa-devel] Adding client-side functionality in Vault

Alexander Bokovoy abokovoy at redhat.com
Tue Aug 25 05:35:59 UTC 2015


On Mon, 24 Aug 2015, Endi Sukma Dewata wrote:
>Hi,
>
>Recently I posted the following patches which are still pending review:
>* 371-2: Added support for changing vault encryption.
>* 375-1: Added mechanism to copy vault secrets.
>
>Here are the tickets:
>* https://fedorahosted.org/freeipa/ticket/5176
>* https://fedorahosted.org/freeipa/ticket/5223
>
>These patches add new functionality to the following commands:
>* vault-mod: changing vault encryption
>* vault-archive: copying a secret from a vault into an existing vault
>* vault-add: copying a secret from a vault into a new vault
>
>The changes are quite similar. In order to change the vault encryption 
>or to copy the vault secret, the old secret has to be retrieved with 
>the old encryption parameters, then the secret will be rearchived with 
>the new encryption parameters.
>
>The thing is these operations have to be done on the client side since 
>the encryption/decryption is done using a key only known to the 
>client. This also means that even if the server is upgraded, someone 
>using an old client will not be able to utilize the new functionality 
>unless the client is upgraded too. Also, the old vault-mod actually 
>has a bug because it will update the vault encryption attributes 
>without rearchiving the secret.
>
>Should we require old clients to upgrade? Or should we continue to 
>accept old clients, but the buggy operation will now be rejected? Is 
>this considered breaking backward compatibility?
We don't really have old clients for vaults yet as we only released
FreeIPA 4.2 into an experimental COPR repository.

I think it is OK to include these patches to fix incompatibility now
rather than releasing 4.2.1 without them and then dealing with the
incompatibility later.
-- 
/ Alexander Bokovoy




More information about the Freeipa-devel mailing list