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?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
iordan
On Fri, Sep 13, 2013 at 12:53 PM, i iordanov <iiordanov@xxxxxxxxx> 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!
iordanOn Fri, Sep 13, 2013 at 12:09 PM, i iordanov <iiordanov@xxxxxxxxx> wrote:
iordanThanks again!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.
On Thu, Sep 12, 2013 at 1:20 PM, Christophe Fergeau <cfergeau@xxxxxxxxxx> wrote:
Hey Iordan,
Could you try what I suggested in
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?
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@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel