Re: [libvirt] [PATCH 01/20] Secret manipulation step 1: Public API

On Sun, Aug 16, 2009 at 10:47:54PM +0200, Miloslav Trma?? wrote: > This patch adds a "secret" as a separately managed object, using a > special-purpose API to transfer the secret values between nodes and > libvirt users. Okay, interesting... > Rather than add explicit accessors for attributes of secrets, and > hard-code the "secrets are related to storage volumes" association in > the API, the API uses XML to manipulate the association as well as > other attributes, similarly to other areas of libvirt. > > The user can set attributes of the secret using XML, e.g. > <secret ephemeral='no' private='yes'> > <uuid>b8eecf55-798e-4db7-b2dd-025b0cf08a36</uuid> > <volume>/var/lib/libvirt/images/mail.img</volume> > <description>LUKS passphrase for our mail server</description> > </secret> > If <uuid/> is not specified, it is chosen automatically. Should secret always be tied to volumes. The API is generic enough that we should make sure we can use this later to get priviledged access to other resources, though right now I don't have a good example in mind.

> - use "unsigned char *" for secret value fine, assuming 0 terninated. though this may not work with everything but since we need to import/export to XML, unless uuencoding the value we won't be able to embed something which is not part of XML character range (#x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]) unicode code points.

> +int virSecretSetValue (virSecretPtr secret, > + const unsigned char *value, > + size_t value_size); > +unsigned char * virSecretGetValue (virSecretPtr secret, > + size_t *value_size); Ah, so we aren't relying on 0 termination, but in that case the value need to be uuencoded in the XML, and that should be made clear in the API description. Actually not having the secret completely in the clear in the XML dump sounds like a good idea.