[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