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 <iiorda...@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 <iiorda...@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
>> <cferg...@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.
_______________________________________________
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
