After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 633109 - ca-bundle file existence check in configure.ac
ca-bundle file existence check in configure.ac
Status: RESOLVED FIXED
Product: epiphany
Classification: Core
Component: Build
unspecified
Other All
: Normal normal
: ---
Assigned To: Epiphany Maintainers
Epiphany Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-10-25 15:28 UTC by sledz
Modified: 2011-11-30 11:36 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Use SoupSession:ssl-use-system-ca-file property (4.06 KB, patch)
2011-11-30 09:37 UTC, Dan Winship
committed Details | Review

Description sledz 2010-10-25 15:28:49 UTC
We hit a problem in configure.ac for epiphany while working with the OpenEmbedded environment. But the problem seems to be not OE specific so we report it here too.

configure.ac checks for the existence of a ca-bundle file *at buildtime at the buildhost* and compiles this path into the resulting binary. This is not a good idea because buildhost and target may have different locations for this ca-bundle file (e.g. may have different distribution). This is the case especially when cross compiling (like we do with OE).

Our solution is to remove the existence check totally. May be you have a better idea. ;-)

see also thread at OE ml: http://thread.gmane.org/gmane.comp.handhelds.openembedded/38251/focus=38830
Comment 1 Diego Escalante Urrelo (not reading bugmail) 2011-07-30 08:17:14 UTC
Do you have this same problem with GIO? Apparently we stole the ca-bundle snippet from its configure.ac.
Also, isn't it enough to force the path with --with-ca-file=path ?

OTOH, see that we check for existance of the file, maybe you can suggest a way to handle not finding the file, based on what you need for OE:

#ifdef GTLS_SYSTEM_CA_FILE
  /* Check SSL certificates */

  if (g_file_test (GTLS_SYSTEM_CA_FILE, G_FILE_TEST_EXISTS)) {
    g_object_set (session,
                  SOUP_SESSION_SSL_CA_FILE, GTLS_SYSTEM_CA_FILE,
                  SOUP_SESSION_SSL_STRICT, FALSE,
                  NULL);
  } else {
    g_warning (_("CA Certificates file we should use was not found, "\
                 "all SSL sites will be considered to have a broken certificate."));
  }
#endif
Comment 2 Akhil Laddha 2011-09-10 12:26:30 UTC
sledz, can you please respond to comment#1 ?
Comment 3 sledz 2011-09-12 09:35:11 UTC
Sorry for the late response, but the problem is not in my focus at the moment.

I tried to check if we have the same problem with GIO but i failed to do the check. May be there's a misunderstanding.

I did not found separate sources for GIO. In my understanding GIO is part of the glib (in our case glib-2.0 2.24.1). And in the glib-2.0 configure scripts i did not found the snippet we're talking about (or something similar).
Comment 4 Fabio Durán Verdugo 2011-11-30 06:22:46 UTC
any news for this issues?
Comment 5 Dan Winship 2011-11-30 09:37:40 UTC
Created attachment 202426 [details] [review]
Use SoupSession:ssl-use-system-ca-file property

Rather than copying glib-networking's logic for finding the system
trusted CA file and then telling libsoup to use it, just use the new
ssl-use-system-ca-file property.
Comment 6 Xan Lopez 2011-11-30 10:58:17 UTC
Review of attachment 202426 [details] [review]:

Great.
Comment 7 Dan Winship 2011-11-30 11:36:21 UTC
Attachment 202426 [details] pushed as 1455bc2 - Use SoupSession:ssl-use-system-ca-file property