GNU bug report logs - #61557
vdirsyncer fails to verify certificates

Previous Next

To reply to this bug, email your comments to 61557 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ethan Blanton <elb <at> kb8ojh.net>
To: bug-guix <at> gnu.org
Subject: vdirsyncer fails to verify certificates
Date: Thu, 16 Feb 2023 15:29:23 -0500

Package: vdirsyncer
Version: 0.19.0

I am using Guix on a foreign distro of Debian GNU/Linux 11 (bullseye).

I have the following manifest installed in particular profile:

(specifications->manifest
 (list "go"
       "sbcl"
       "khal"
       "mutt"
       "nss-certs"
       "protobuf"
       "vdirsyncer"))

Since vdirsyncer updated to 0.19.0, I cannot sync with any remote host
using CalDAV or HTTPS iCalendar files.  This is reproducible with my
private servers, Microsoft Outlook 365 calendars, Google Calendars,
and others.  I have moset recently verified it with Guix 312f1f4 and a
vdirsyncer producing
/gnu/store/9aa2bj3likla61zqbsim1a1c99k3jk93-vdirsyncer-0.19.0 (I don't
know how to give a more precise or useful install, please let me know
if I should, and how I would), but I have narrowed the breaking change
down to Guix revision f635f725778f86abaa77f674f8f670f74bffd7be.
Revision ed18b697c4783f139e23731f5bd0b0ed197997bb, which is vdirsyncer
0.18.0, works as expected.

The lightly redacted error that vdirsyncer produces is:

error: Unknown error occurred for [config entry]/calendarname: Cannot connect to host cloud.kb8ojh.net:443 ssl:True [SSLCertVerificationError: (1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate
(_ssl.c:1129)')]

An example configuration that causes this is:

[storage samplecalendar_public]
type = "http"
url = "https://calendar.google.com/calendar/ical/[redacted]group.calendar.google.com/public/basic.ics"

[storage localcalendar_public]
type = "filesystem"
path = "~/.calendars/public"
fileext = ".ics"

[pair public_calendar]
a = "samplecalendar_public"
b = "localcalendar public"
collections = [ "from a" ]

It appears that the root cause is in Python aiohttp, as starting the
python3 interpreter invoked by the vdirsyncer binary in the installed
profile with the GUIX_PYTHONPATH provided, then attempting to fetch an
HTTPS URL using aiohttp, will fail with an SSL error.  I cannot tell
if the root configuration problem is in vdirsyncer and its
dependencies or in aiohttp, so I am reporting it against vdirsyncer,
which I can confirm is broken.

I have tried installing various certificate packages and other
packages that seemed like they might be related (such as nss-certs,
nss itself, gnutls, etc.), but not found anything that seemed to
resolve the issue.

This bug that I have reported upstream is related, but I think the
problem is with the Guix packaging and/or dependencies, not with
vdirsyncer itself:

https://github.com/pimutils/vdirsyncer/issues/1034

Ethan

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ethan Blanton <elb <at> kb8ojh.net>
To: bug-guix <at> gnu.org
Subject: bug database indexing problem for bug #61557
Date: Fri, 24 Feb 2023 21:30:55 -0500

Bug #61557, filed against the vdirsyncer package in Guix and having
the title "vdirsyncer fails to verify certificates", does not show up
in the Guix bug database at issues.guix.gnu.org when searching by
keywords such as "vdirsyncer" or "certificates", although it does
appear when searching for "61557".

There may be an indexing problem.

(Filing at the request of nckx/irc)

Message #15 received at 61557 <at> debbugs.gnu.org (full text, mbox):

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: control <at> debbugs.gnu.org, 61557 <at> debbugs.gnu.org
Subject: vdirsyncer fails to verify certificates
Date: Sat, 25 Feb 2023 03:44:01 +0100

reassign 61557 guix
thanks

Hi,

I had missed the Package: pseudo-header because I shouldn't be alive at 
this point.

All Guix bugs should be filed against the ‘guix’ package, no matter what 
the package—confusing, I know.  Luckily, sending mail to bug-guix@ does 
this for you, so you don't usually need to think about it.

Thanks again!

Kind regards,

T G-R

Sent from a Web browser.  Excuse or enjoy my brevity.

Message #18 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Ethan Blanton via "General discussion for the tracker at
 debbugs.gnu.org" <help-debbugs <at> gnu.org>
Cc: Ethan Blanton <elb <at> kb8ojh.net>, bug-guix <at> gnu.org
Subject: Re: bug#61557: bug database indexing problem for bug #61557
Date: Sat, 25 Feb 2023 09:58:57 +0100

Ethan Blanton via "General discussion for the tracker at
debbugs.gnu.org" <help-debbugs <at> gnu.org> writes:

Hi Ethan,

> Bug #61557, filed against the vdirsyncer package in Guix and having
> the title "vdirsyncer fails to verify certificates", does not show up
> in the Guix bug database at issues.guix.gnu.org when searching by
> keywords such as "vdirsyncer" or "certificates", although it does
> appear when searching for "61557".

When I search for vdirsyncer, bug#61557 appears in the hit list.

Searching for certificates does not show such a hit. However, in the bug
messages this word appears only as certificates" or "certificates". This
seems to prevent the word to be indexed. The HyperEstraier search engine
counts only words, and a leading or trailing apostrophe seems to
suppress a string to be regarded as word. Just a guess, but it is the
most plausible explanation.

Best regards, Michael.

Message #21 received at 61557 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: 61557 <at> debbugs.gnu.org
Subject: Re: vdirsyncer fails to verify certificates
Date: Sat, 25 Feb 2023 16:52:08 -0500

Thanks for the report!

Did you follow the instructions about X.509 Certificates in the manual
section Application Setup? That section is about using Guix on other
distros.

I use vdirsyncer from Guix on Debian and it works fine when validating
X.509 / TLS / HTTPS certificates.

Message #24 received at 61557 <at> debbugs.gnu.org (full text, mbox):

From: Ethan Blanton <elb <at> kb8ojh.net>
To: 61557 <at> debbugs.gnu.org
Subject: Re: vdirsyncer fails to verify certificates
Date: Sun, 26 Mar 2023 18:05:25 -0400

(Pardon the delay, for some reason I do not get email notifications
for this bug.)

I had read the X.509 Certificates section of the manual, but since my
certificates ARE in the default location of /etc/ssl/certs, and
vdirsyncer had previously worked, for some reason I did not dig into
it deeply enough, or perhaps I attempted to set it up wrongly at some
point in the past.

Setting SSL_CERT_DIR=/etc/ssl/certs in my environment fixes the
vdirsyncer package, and it syncs correctly.

I have also discovered that python aiohttp will correctly verify
certificates WITHOUT this environment variable with:

guix shell -P -C -N python python-aiohttp nss-certs openssl

Leaving out EITHER nss-certs OR openssl causes aiohttp to exhibit the
same behavior as vdirsyncer.

However, including both of these packages in the same (foreign distro)
profile that includes vdirsyncer does NOT cause vdirsyncer to
correctly verify certificates.

I am not sure what this means for this bug; certainly the change from
"working without extra configuration" to "broken without extra
configuration" is a regression in user experience, but it may be that
it is working as intended.  It seems to me that the principle of least
astonishment for foreign distro users would suggest that python
aiohttp defaults to loading /etc/ssl/certs from the foreign distro, if
present.

Message #27 received at 61557 <at> debbugs.gnu.org (full text, mbox):

From: Giovanni Biscuolo <g <at> xelera.eu>
To: Ethan Blanton <elb <at> kb8ojh.net>, 61557 <at> debbugs.gnu.org
Cc: Leo Famulari <leo <at> famulari.name>
Subject: Re: bug#61557: vdirsyncer fails to verify certificates
Date: Mon, 27 Mar 2023 14:50:04 +0200

[Message part 1 (text/plain, inline)]

Hi Ethan,

I'm also using Guix on a foreign distribution (Debian)

Ethan Blanton via Bug reports for GNU Guix <bug-guix <at> gnu.org> writes:

> I had read the X.509 Certificates section of the manual, but since my
> certificates ARE in the default location of /etc/ssl/certs, and
> vdirsyncer had previously worked, for some reason I did not dig into
> it deeply enough, or perhaps I attempted to set it up wrongly at some
> point in the past.

I'm pretty sure my default profile vdirsyncer was working in the past
but stopped working while ago for this very same issue [1]; vdirsyncer
it's not working in my default profile but it's working in my "emacs"
profile

Reading (again) the "X.509 Certificates" section [2] I realized that I
had not set up SSL_CERT_DIR and SSL_CERT_FILE env variables in my
.profile

After adding this to my .profile:

--8<---------------cut here---------------start------------->8---

export SSL_CERT_DIR="$HOME/.guix-profile/etc/ssl/certs"
export SSL_CERT_FILE="$HOME/.guix-profile/etc/ssl/certs/ca-certificates.crt"

--8<---------------cut here---------------end--------------->8---

now "vdirsyncer sync" is working (in my default profile, including cron
jobs)

As I said before, the SSL_CERT_* variables setting was/is not necessary
in my emacs profile and it depends on this:

within a shell in my emacs profile I have:

--8<---------------cut here---------------start------------->8---

$: cat $GUIX_PROFILE/etc/profile | grep -i ssl
export CURL_CA_BUNDLE="${GUIX_PROFILE:-/gnu/store/hwc2pm42r2xg3mv0f7jlkf7dlvi6rpxh-profile}/etc/ssl/certs/ca-certificates.crt"
export SSL_CERT_FILE="${GUIX_PROFILE:-/gnu/store/hwc2pm42r2xg3mv0f7jlkf7dlvi6rpxh-profile}/etc/ssl/certs/ca-certificates.crt"
export SSL_CERT_DIR="${GUIX_PROFILE:-/gnu/store/hwc2pm42r2xg3mv0f7jlkf7dlvi6rpxh-profile}/etc/ssl/certs"
export GIT_SSL_CAINFO="${GUIX_PROFILE:-/gnu/store/hwc2pm42r2xg3mv0f7jlkf7dlvi6rpxh-profile}/etc/ssl/certs/ca-certificates.crt"

--8<---------------cut here---------------end--------------->8---

within a shell in my default profile:

--8<---------------cut here---------------start------------->8---

$: cat $GUIX_PROFILE/etc/profile | grep -i ssl
export GIT_SSL_CAINFO="${GUIX_PROFILE:-/gnu/store/ylycvfsnm1gkzhph39g62bwbc9lbh3g7-profile}/etc/ssl/certs/ca-certificates.crt"

--8<---------------cut here---------------end--------------->8---

For sure it depends on the fact that an installed package in my emacs
profile (curl, not installed in my default profile) is adding
"SSL_CERT_FILE" and "SSL_CERT_DIR" in $GUIX_PROFILE/etc/profile

Since I usually source the latter when I switch to my "emacs" profile
before starting emacs in a shell:

--8<---------------cut here---------------start------------->8---

GUIX_PROFILE="$GUIX_EXTRA_PROFILES"/emacs/emacs; . "$GUIX_PROFILE"/etc/profile

--8<---------------cut here---------------end--------------->8---

I get the two env variables defined in my "emacs" profile, while in my
default profile I don't

> Setting SSL_CERT_DIR=/etc/ssl/certs in my environment fixes the
> vdirsyncer package, and it syncs correctly.

I'd use the Guix certs installed via nss-certs, but both dirs works
obviously

Please note that you should set SSL_CERT_FILE for other software

> I have also discovered that python aiohttp will correctly verify
> certificates WITHOUT this environment variable with:
>
> guix shell -P -C -N python python-aiohttp nss-certs openssl
>
> Leaving out EITHER nss-certs OR openssl causes aiohttp to exhibit the
> same behavior as vdirsyncer.
>
> However, including both of these packages in the same (foreign distro)
> profile that includes vdirsyncer does NOT cause vdirsyncer to
> correctly verify certificates.

Strange behaviour, please can you tell us what is the output of this
command:

--8<---------------cut here---------------start------------->8---

guix shell --pure --container coreutils grep nss-certs openssl -- env | grep -i ssl

--8<---------------cut here---------------end--------------->8---

I get this (meaning that both SSL env variables are defined):

--8<---------------cut here---------------start------------->8---

SSL_CERT_DIR=/gnu/store/1ghginmnzplmp3nbv2jsavjgdjhgq4i3-profile/etc/ssl/certs
SSL_CERT_FILE=/gnu/store/1ghginmnzplmp3nbv2jsavjgdjhgq4i3-profile/etc/ssl/certs/ca-certificates.crt

--8<---------------cut here---------------end--------------->8---

while with

--8<---------------cut here---------------start------------->8---

guix shell --pure --container coreutils grep nss-certs -- env | grep -i ssl

--8<---------------cut here---------------end--------------->8---

I get no output (meaning that env is missing SSL_CERT_* variables)

So in my tests openssl (and curl) are defining "SSL_CERT_FILE" and
"SSL_CERT_DIR" in $GUIX_PROFILE/etc/profile

I guess that also nss-certs package could add both "SSL_CERT_FILE" and
"SSL_CERT_DIR" in $GUIX_PROFILE/etc/profile but I don't know the ratio
for this choiche

> I am not sure what this means for this bug; certainly the change from
> "working without extra configuration" to "broken without extra
> configuration" is a regression in user experience, but it may be that
> it is working as intended.

The bug I see here is that X.509 certificates are "working without extra
configuration" **depending** on installed packages.

If possible I'd patch nss-certs in order to add "SSL_CERT_FILE" and
"SSL_CERT_DIR" to $GUIX_PROFILE/etc/profile, this would also avoid the
extra step of "manually" defining X.509 related variables on foreign
distros

I'd also investigate this "meta-issue" for other packages, e.g. for R
that needs "CURL_CA_BUNDLE", added when installing curl but not
r-minimal

> It seems to me that the principle of least astonishment for foreign
> distro users would suggest that python aiohttp defaults to loading
> /etc/ssl/certs from the foreign distro, if present.

IMHO it's better to use the nss-certs installed via Guix than the
foreign distro ones

HTH!  Gio'


[1] maybe I was using a Guix package able to add "SSL_CERT_FILE" and
"SSL_CERT_DIR" to $GUIX_PROFILE/etc/profile and then I removed it

[2] https://guix.gnu.org/en/manual/en/html_node/X_002e509-Certificates.html

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.