Bug 1284655
| Summary: | TLS certificate validation fails with alternative chains | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Kai Engert (:kaie) (inactive account) <kengert> | ||||||
| Component: | glib-networking | Assignee: | Matthias Clasen <mclasen> | ||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 22 | CC: | danw, dwmw2, hkario, lucilanga, mbarnes, mclasen, mcrha, nmavrogi, tmraz, tpopela | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2015-11-27 10:02:45 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Kai Engert (:kaie) (inactive account)
2015-11-23 19:34:18 UTC
When testing, please ensure you NEVER click the "accept permanently" buttons when evolution reports the error, to ensure your verification environment remains at the clean default. Created attachment 1098069 [details]
test.c
Thanks for a bug report. Evolution's IMAPx (and Camel in general) uses glib's gio streams and relies on its results. If I recall correctly, the TLS gio stream uses gnutls in the background.
I extracted the relevant code from the evolution-data-server to a single file (attached). The first line contains a comment with a command line to compile and run it.
I can reproduce the issue with the test in the environment setup as you suggested above. Either the evolution-data-server is using the GIO callbacks incorrectly (unlikely, from my point of view, because before the update to the ca-certificates the same code works like a charm), or there should be done a fix on the glib/gio side, or somewhere deeper, just as you suggested above.
Could that be related with https://bugzilla.redhat.com/show_bug.cgi?id=1246492 ? It seems gio reimplements certificate verification rather than using gnutls' functions. Yes, that looks like a duplicate. Milan, thank for the test attachment. I tried a few experiments, and the results are confusing. First, I compiled the test as you said. I can reproduce the failure using it. I tried to debug/trace with gdb, but I failed, because the optimized binaries make it difficult to follow the execution path. Because of that, I decided to build glib2 myself. I cloned branch glib-2-44 of glib and installed it to /opt/evolution. With that, the test reported TLS not available. In addition I built glib-2-44 of glib-networking. With that combination, to my surprise, your test no longer reports a failure. It prints Connection 0x... error: none Does that mean that something has been fixed in latest git already? In addition, I've also built evolution-data-server and evolution locally (prefix /opt/evolution), following the instructions in the evolution README. When running my local evolution build, the connection to imap.googlemail.com works fine. However, there are other errors remaining. I didn't mention it earlier, but the mentioned error wasn't the only one. In addition, I have google calendars configured. With the standard f22 evolution, I also get error messages for each of the google calendar connections, which seem to be about the same cause, because they mention a certificate for www.google.com which has been issued by the same Google intermediate CA. Can you suggest which additional component might require a rebuild to fix the calendar TLS verification? Should we try to suggest to the maintainer of glib* to produce rebuilt RPM packages for f22 testing? FYI, I built branch gnome-3-16 of evolution and data-server. I think for all locally builds I used the same branches that are used by f22. I see that my environment still executes data-server processes from /usr/libexec ... I need to figure out how to make it use the builds from /opt/evolution/libexec Milan has explained to me how I run the local libexec binaries. I need to start them first manually, source-registry first, then calendar-factory -w and addressbook-factory-w. With that, no more certificates errors, both imap and calendar connections work. Changing component to glib-networking. Milan pointed me to https://git.gnome.org/browse/glib-networking/log/?h=glib-2-44 This commit from september seems the likely cause for the fix with the local build: https://git.gnome.org/browse/glib-networking/commit/?h=glib-2-44&id=44d02b8c57e24f0a796d75b6270ecee265f35f6f The commit points to https://bugzilla.gnome.org/show_bug.cgi?id=750457 Could you please rebuild glib-networking for Fedora 22 and later, to ensure this fix gets picked up? This is a scratch build that applies the patch. http://koji.fedoraproject.org/koji/taskinfo?taskID=11967051 With this build installed, the bug is fixed for me. Created attachment 1098181 [details]
patch for glib-networking package in fedora f22 dist/git
(In reply to Nikos Mavrogiannopoulos from comment #3) > Could that be related with > https://bugzilla.redhat.com/show_bug.cgi?id=1246492 ? It seems gio > reimplements certificate verification rather than using gnutls' functions. (In reply to Tomas Mraz from comment #4) > Yes, that looks like a duplicate. In bug 1246492, David said: not a duplicate This should be testable with the 'socket-client' test from gio, rather than having to use the Evolution stack? What I said in bug 1246492 was slightly more nuanced than 'not a duplicate'. If you retitle this bug to "glib-networking reimplements stuff it shouldn't", and fix it *properly* to use the GnuTLS functionality, then it's a duplicate. If you're going to paper over the cracks without fixing the real underlying problem, then it isn't — bug 1246492 covers a *different* symptom of the same problem. So actually, I think we really *should* be treating them as the same bug. (In reply to Kai Engert (:kaie) from comment #10) > Could you please rebuild glib-networking for Fedora 22 and later, to ensure > this fix gets picked up? FYI, I just upgraded to Fedora 23, and it already uses a version of glib-networking that has picked up the "papering" fix, so, this specific bug doesn't occur in F23. (In reply to David Woodhouse from comment #15) > What I said in bug 1246492 was slightly more nuanced than 'not a duplicate'. > > If you retitle this bug to "glib-networking reimplements stuff it > shouldn't", and fix it *properly* to use the GnuTLS functionality, then it's > a duplicate. Let's do that then. I believe we are going to have many more issues like that if we don't. I'll open a new bug and mark these as duplicates. *** This bug has been marked as a duplicate of bug 1286034 *** |