[Spice-devel] oVirt support in aSPICE stalled due to broken network file I/O

[i iordanov]

Hi Christophe,

I've tested the function and made one small change (bytes had to be
unref-ed before ca_file). This works for my purposes and solves my
issue of not being able to download the file using glib network I/O.
Would you be willing to include it in govirt? Notice that it
automatically uses set_downloaded_ca_cert() to set the ca property of
OvirtProxy.

void ovirt_proxy_load_ca_cert_file (OvirtProxy *proxy,
                                    const gchar *ca_file_name,
                                    GError **error)
{
    GMappedFile *ca_file = NULL;
    GBytes *bytes = NULL;
    gconstpointer ca_data;
    gsize cert_length = 0;

    ca_file = g_mapped_file_new(ca_file_name, FALSE, error);
    if (ca_file == NULL) {
        goto error;
    }

    bytes = g_mapped_file_get_bytes(ca_file);
    cert_length = g_bytes_get_size(bytes);
    ca_data = g_bytes_get_data (bytes, &cert_length);
    set_downloaded_ca_cert(proxy, (char*)ca_data, cert_length);

error:
    if (bytes != NULL)
        g_object_unref(bytes);
    if (ca_file != NULL)
        g_object_unref(ca_file);
    return;
}

Thanks!
iordan

On Fri, Sep 13, 2013 at 4:52 PM, i iordanov <iiordanov at gmail.com> wrote:
> Hi Christophe,
>
> If adding a ca-file property to OvirtProxy is not acceptable, would you
> consider adding (something like) the following function to ovirt-proxy.c?
>
> Please note that this is a preliminary variant that I haven't tested much,
> and may not have enough error checking!
>
> void ovirt_proxy_load_ca_cert_file (OvirtProxy *proxy,
>                                            const gchar *ca_file_name,
>                                            GError **error)
> {
>     GMappedFile *ca_file = NULL;
>     GBytes *bytes = NULL;
>     gconstpointer ca_data;
>     gsize cert_length = 0;
>
>     ca_file = g_mapped_file_new(ca_file_name, FALSE, error);
>     if (ca_file == NULL) {
>         goto error;
>     }
>
>     bytes = g_mapped_file_get_bytes(ca_file);
>     cert_length = g_bytes_get_size(bytes);
>     ca_data = g_bytes_get_data (bytes, &cert_length);
>     set_downloaded_ca_cert(proxy, (char*)ca_data, cert_length);
>
> error:
>     if (ca_file != NULL)
>         g_object_unref(ca_file);
>
>     if (bytes != NULL)
>         g_object_unref(bytes);
> }
>
> Cheers,
> iordan
>
>
> On Fri, Sep 13, 2013 at 12:53 PM, i iordanov <iiordanov at gmail.com> wrote:
>>
>> Hi Christophe,
>>
>> I hope this is not too much to ask, but would it be possible for
>> OvirtProxy to have a ca-cert-file property as well as a ca-cert property?
>> This way, supporting the spice-ca-file option as well as the existing aSPICE
>> functionality will be much easier.
>>
>> Thanks!
>> iordan
>>
>>
>> On Fri, Sep 13, 2013 at 12:09 PM, i iordanov <iiordanov at gmail.com> wrote:
>>>
>>> Hi Christophe,
>>>
>>> I read through some govirt code, and I think you're right that gvfs is
>>> only used during the fetching of the certificate. If that's the case, I will
>>> start by not fetching the CA automatically, but requiring for users to
>>> provide it to aSPICE the same way as they have to provide it for a simple
>>> SPICE connection (within the "Import CA" dialog in aSPICE, which is
>>> analogous to the --spice-ca-file option in virt-viewer). I think this will
>>> work for most if not all people.
>>>
>>> Thanks again!
>>> iordan
>>>
>>>
>>>
>>> On Thu, Sep 12, 2013 at 1:20 PM, Christophe Fergeau <cfergeau at redhat.com>
>>> wrote:
>>>>
>>>> Hey Iordan,
>>>>
>>>> On Thu, Sep 12, 2013 at 01:11:45PM -0400, i iordanov wrote:
>>>> > Hi Christophe,
>>>> >
>>>> > It is currently very hard, bordering on impossible to build gvfs for
>>>> > Android, because it ends up depending on GTK. The sequence of
>>>> > dependencies is:
>>>> >
>>>> > glib network I/O -> gvfs -> libsoup-gnome -> gnome-keyring -> gcr-3 ->
>>>> > gcr-ui-3 -> GTK
>>>> >
>>>> > The glib guys are arguing that this is not a bug, since it's just a
>>>> > dependency that's missing, but I am trying to convince them that the
>>>> > low-level glib should not end up depending on a UI library...
>>>> >
>>>> > Hence for the moment, I absolutely cannot use glib network I/O. Can
>>>> > you tell me, since you've written libgovirt, do you think it's
>>>> > possible to add functionality to *it* rather than writing workarounds
>>>> > for client software? I could work around this issue in aSPICE, but
>>>> > that would not help for any other client on any other platform that
>>>> > doesn't have GTK.
>>>> >
>>>> > Regardless of whether you do agree it's best if govirt either stopped
>>>> > relying on glib network file I/O or had an option to use a different
>>>> > method, what library would you say would be best suited to replace all
>>>> > the network file I/O operations that you have in govirt with a
>>>> > download -> local file I/O sequence? Libcurl comes to mind, but
>>>> > perhaps libsoup is better suited for the purpose in your opinion?
>>>>
>>>> Could you try what I suggested in
>>>>
>>>> http://lists.freedesktop.org/archives/spice-devel/2013-September/014430.html
>>>> ? I think gvfs is only used if you use the helpers to fetch the
>>>> certificate, and the rest of the code is just doing calls into
>>>> librest/libsoup which I think are not using gio/gvfs.
>>>> If this is a correct, then I think it's not a big issue that you don't
>>>> have
>>>> gvfs on your platform. If it is, I'll have to look where/how it's used
>>>> to
>>>> figure out how to workaround this.
>>>>
>>>> Hope that helps,
>>>>
>>>> Christophe
>>>
>>>
>>>
>>>
>>> --
>>> The conscious mind has only one thread of execution.
>>
>>
>>
>>
>> --
>> The conscious mind has only one thread of execution.
>
>
>
>
> --
> The conscious mind has only one thread of execution.



-- 
The conscious mind has only one thread of execution.