bug#34861: TLS Error with Flatpak

bug#34861: TLS Error with Flatpak

[Raghav Gururajan]

[-- Attachment #1: Type: text/plain, Size: 490 bytes --]

Hello Guix!

Package: flatpak

Whenever I try "flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo"; I keep getting the error "Can't load uri https://flathub.org/repo/flathub.flatpakrepo: TLS support is not available".

I even tried following steps mentioned at https://www.gnu.org/software/guix/manual/en/guix.html#index-TLS. Still not working.

Unless this is fixed, flatpak in guix will be unusable with remote repositories.

Regards,
RG.

[-- Attachment #2: Type: text/html, Size: 740 bytes --]

bug#34861: TLS Error with Flatpak

[Ludovic Courtès]

Hello,

"Raghav Gururajan" <rvgn@disroot.org> skribis:

> Whenever I try "flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo"; I keep getting the error "Can't load uri https://flathub.org/repo/flathub.flatpakrepo: TLS support is not available".
>
> I even tried following steps mentioned at https://www.gnu.org/software/guix/manual/en/guix.html#index-TLS. Still not working.

To be more specific, did you install ‘nss-certs’?

If you did is it installed system-wide in /etc/ssl/certs, or per-user?

Did you set ‘SSL_CERT_DIR’, ‘SSL_CERT_FILE’, or related environment
variables?

Thanks,
Ludo’.

bug#34861: TLS Error with Flatpak

[Raghav Gururajan]

Hello Ludovic!

Yes, I did them. Still did not work.

I did the following to set env variables:

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

Regards,
RG.

March 18, 2019 9:49 AM, "Ludovic Courtès" <ludo@gnu.org> wrote:

> Hello,
> 
> "Raghav Gururajan" <rvgn@disroot.org> skribis:
> 
>> Whenever I try "flatpak remote-add --if-not-exists flathub
>> https://flathub.org/repo/flathub.flatpakrepo"; I keep getting the error "Can't load uri
>> https://flathub.org/repo/flathub.flatpakrepo: TLS support is not available".
>> 
>> I even tried following steps mentioned at
>> https://www.gnu.org/software/guix/manual/en/guix.html#index-TLS. Still not working.
> 
> To be more specific, did you install ‘nss-certs’?
> 
> If you did is it installed system-wide in /etc/ssl/certs, or per-user?
> 
> Did you set ‘SSL_CERT_DIR’, ‘SSL_CERT_FILE’, or related environment
> variables?
> 
> Thanks,
> Ludo’.

bug#34861: TLS Error with Flatpak

[Ricardo Wurmus]

Raghav Gururajan <rvgn@disroot.org> writes:

> Yes, I did them. Still did not work.
>
> I did the following to set env variables:
>
> $ guix package -i nss-certs
> $ export SSL_CERT_DIR="$HOME/.guix-profile/etc/ssl/certs"
> $ export SSL_CERT_FILE="$HOME/.guix-profile/etc/ssl/certs/ca-certificates.crt"
> $ export GIT_SSL_CAINFO="$SSL_CERT_FILE"

Flatpak uses libsoup with SOUP_SESSION_SSL_USE_SYSTEM_CA_FILE.  libsoup
delegates TLS handling to glib-networking.

Raghav, could you trace flatpak to see what certificate files it is
trying to access?

--
Ricardo

bug#34861: TLS Error with Flatpak

[Raghav Gururajan]

[-- Attachment #1: Type: text/plain, Size: 3018 bytes --]

Hello Ricardo!

Please find the following information.

FROM FLATPAK SOURECODE:

SoupSession *
flatpak_create_soup_session (const char *user_agent)
{
SoupSession *soup_session;
const char *http_proxy;

soup_session = soup_session_new_with_options (SOUP_SESSION_USER_AGENT, user_agent,
SOUP_SESSION_SSL_USE_SYSTEM_CA_FILE, TRUE,
SOUP_SESSION_USE_THREAD_CONTEXT, TRUE,
SOUP_SESSION_TIMEOUT, 60,
SOUP_SESSION_IDLE_TIMEOUT, 60,
NULL);
soup_session_remove_feature_by_type (soup_session, SOUP_TYPE_CONTENT_DECODER);
http_proxy = g_getenv ("http_proxy");
if (http_proxy)
{
g_autoptr(SoupURI) proxy_uri = soup_uri_new (http_proxy);
if (!proxy_uri)
g_warning ("Invalid proxy URI '%s'", http_proxy);
else
g_object_set (soup_session, SOUP_SESSION_PROXY_URI, proxy_uri, NULL);
}

if (g_getenv ("OSTREE_DEBUG_HTTP"))
soup_session_add_feature (soup_session, (SoupSessionFeature *) soup_logger_new (SOUP_LOGGER_LOG_BODY, 500));

return soup_session;
}

FROM LIBSOUP MANUAL:

The “ssl-use-system-ca-file” property

“ssl-use-system-ca-file” gboolean

Setting this to TRUE is equivalent to setting “tls-database” to the default system CA database. (and likewise, setting “tls-database” to the default database by hand will cause this property to become TRUE).

Setting this to FALSE (when it was previously TRUE) will clear the “tls-database” field.

See “ssl-strict” for more information on how https certificate validation is handled.

The “ssl-strict” property

“ssl-strict” gboolean

Normally, if “tls-database” is set (including if it was set via “ssl-use-system-ca-file” or “ssl-ca-file”), then libsoup will reject any certificate that is invalid (ie, expired) or that is not signed by one of the given CA certificates, and the SoupMessage will fail with the status SOUP_STATUS_SSL_FAILED.

If you set “ssl-strict” to FALSE, then all certificates will be accepted, and you will need to call soup_message_get_https_status() to distinguish valid from invalid certificates. (This can be used, eg, if you want to accept invalid certificates after giving some sort of warning.)

For a plain SoupSession, if the session has no CA file or TLS database, and this property is TRUE, then all certificates will be rejected.

--
Regards,
RG.

March 18, 2019 9:24 PM, "Ricardo Wurmus" <rekado@elephly.net (mailto:rekado@elephly.net)> wrote:
 Raghav Gururajan <rvgn@disroot.org (mailto:rvgn@disroot.org)> writes:
 Yes, I did them. Still did not work.

I did the following to set env variables:

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

Flatpak uses libsoup with SOUP_SESSION_SSL_USE_SYSTEM_CA_FILE. libsoup
delegates TLS handling to glib-networking.

Raghav, could you trace flatpak to see what certificate files it is
trying to access?

--
Ricardo

[-- Attachment #2: Type: text/html, Size: 3643 bytes --]

bug#34861: TLS Error with Flatpak

[Ricardo Wurmus]

Hi Raghav,

> Please find the following information. […]

Unfortunately, this is not very helpful as it only shows that flatpak
uses libsoup.

> Raghav, could you trace flatpak to see what certificate files it is
> trying to access?

I meant: could you run the flatpak command with “strace -f -o log -s
2048 flatpak …”?  This would show us what files it attempts to access,
hopefully including certificate files.

--
Ricardo

bug#34861: TLS Error with Flatpak

[Raghav Gururajan]

Hi Ricardo!

Please find the log at: https://bin.disroot.org/?597e32cb7e42e40e#r9lqwZ6w7sIAWlY2mt6dsgKCKRO5q0ZVt9U69vnZVZs=

Thank you!

Regards,
RG.

March 19, 2019 12:22 AM, "Ricardo Wurmus" <rekado@elephly.net> wrote:

> Hi Raghav,
> 
>> Please find the following information. […]
> 
> Unfortunately, this is not very helpful as it only shows that flatpak
> uses libsoup.
> 
>> Raghav, could you trace flatpak to see what certificate files it is
>> trying to access?
> 
> I meant: could you run the flatpak command with “strace -f -o log -s
> 2048 flatpak …”? This would show us what files it attempts to access,
> hopefully including certificate files.
> 
> --
> Ricardo

bug#34861: TLS Error with Flatpak

[Ludovic Courtès]

Hi Raghav,

"Raghav Gururajan" <rvgn@disroot.org> skribis:

> Please find the log at: https://bin.disroot.org/?597e32cb7e42e40e#r9lqwZ6w7sIAWlY2mt6dsgKCKRO5q0ZVt9U69vnZVZs=
> 
> 5462  connect(12, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("93.93.130.103")}, 16) = -1 EINPROGRESS (Operation now in progress)

[...]

> 5462  getsockopt(12, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
> 5462  setsockopt(12, SOL_TCP, TCP_NODELAY, [1], 4) = 0

[...]

> 5462  close(12)                         = 0

[...]

> 5461  write(2, "\33[31m\33[1merror: \33[22m\33[0mTLS support is not available\n", 54) = 54

Thanks for sending the strace output.  That output shows that Flatpak
never tries to access /etc/ssl/certs, ~/.guix-profile/etc/ssl/certs or
anything like that.

The error message comes from GLib, in gdummytlsbackend.c.  AFAICS our
GLib also includes the TLS (not dummy) backend:

--8<---------------cut here---------------start------------->8---
$ objdump -T /gnu/store/0q9pq9flr76rh4bv2524niknknnl2kvq-glib-2.56.3/lib/libgio-2.0.so | grep g_tls_backend
0000000000093e90 g    DF .text	0000000000000082  Base        g_tls_backend_get_default_database
0000000000093dd0 g    DF .text	000000000000006f  Base        g_tls_backend_supports_tls
0000000000093f40 g    DF .text	000000000000001b  Base        g_tls_backend_get_client_connection_type
0000000000093e40 g    DF .text	0000000000000049  Base        g_tls_backend_supports_dtls
0000000000093db0 g    DF .text	0000000000000015  Base        g_tls_backend_get_default
0000000000093f80 g    DF .text	0000000000000072  Base        g_tls_backend_get_dtls_client_connection_type
0000000000093f60 g    DF .text	000000000000001b  Base        g_tls_backend_get_server_connection_type
0000000000094000 g    DF .text	0000000000000072  Base        g_tls_backend_get_dtls_server_connection_type
0000000000094080 g    DF .text	000000000000007f  Base        g_tls_backend_get_file_database_type
0000000000093d20 g    DF .text	0000000000000084  Base        g_tls_backend_get_type
0000000000093f20 g    DF .text	000000000000001b  Base        g_tls_backend_get_certificate_type
--8<---------------cut here---------------end--------------->8---

Libsoup does this:

--8<---------------cut here---------------start------------->8---
static gboolean
soup_socket_setup_ssl (SoupSocket    *sock,
		       const char    *ssl_host,
		       GCancellable  *cancellable,
		       GError       **error)
{
	SoupSocketPrivate *priv = soup_socket_get_instance_private (sock);
	GTlsBackend *backend = g_tls_backend_get_default ();
--8<---------------cut here---------------end--------------->8---

‘g_tls_backend_get_default’ itself looks like this:

--8<---------------cut here---------------start------------->8---
GTlsBackend *
g_tls_backend_get_default (void)
{
  return _g_io_module_get_default (G_TLS_BACKEND_EXTENSION_POINT_NAME,
				   "GIO_USE_TLS", NULL);
}
--8<---------------cut here---------------end--------------->8---

Could you try setting the ‘GIO_USE_TLS’ environment variable?  Like:

  export GIO_USE_TLS=tls

or maybe:

  export GIO_USE_TLS=GTlsBackend

and then run Flatpak in that environment?

TIA,
Ludo’.

bug#34861: TLS Error with Flatpak

[Raghav Gururajan]

Thank you very much.

Should I be running just "export GIO_USE_TLS=tls" as it is mentioned or should I insert it in some other command/syntax?

Thanks!

Regards,
RG.

March 22, 2019 5:15 PM, "Ludovic Courtès" <ludo@gnu.org> wrote:

> Hi Raghav,
> 
> "Raghav Gururajan" <rvgn@disroot.org> skribis:
> 
>> Please find the log at:
>> https://bin.disroot.org/?597e32cb7e42e40e#r9lqwZ6w7sIAWlY2mt6dsgKCKRO5q0ZVt9U69vnZVZs=
>> 
>> 5462 connect(12, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("93.93.130.103")}, 16)
>> = -1 EINPROGRESS (Operation now in progress)
> 
> [...]
> 
>> 5462 getsockopt(12, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
>> 5462 setsockopt(12, SOL_TCP, TCP_NODELAY, [1], 4) = 0
> 
> [...]
> 
>> 5462 close(12) = 0
> 
> [...]
> 
>> 5461 write(2, "\33[31m\33[1merror: \33[22m\33[0mTLS support is not available\n", 54) = 54
> 
> Thanks for sending the strace output. That output shows that Flatpak
> never tries to access /etc/ssl/certs, ~/.guix-profile/etc/ssl/certs or
> anything like that.
> 
> The error message comes from GLib, in gdummytlsbackend.c. AFAICS our
> GLib also includes the TLS (not dummy) backend:
> 
> --8<---------------cut here---------------start------------->8---
> $ objdump -T /gnu/store/0q9pq9flr76rh4bv2524niknknnl2kvq-glib-2.56.3/lib/libgio-2.0.so | grep
> g_tls_backend
> 0000000000093e90 g DF .text 0000000000000082 Base g_tls_backend_get_default_database
> 0000000000093dd0 g DF .text 000000000000006f Base g_tls_backend_supports_tls
> 0000000000093f40 g DF .text 000000000000001b Base g_tls_backend_get_client_connection_type
> 0000000000093e40 g DF .text 0000000000000049 Base g_tls_backend_supports_dtls
> 0000000000093db0 g DF .text 0000000000000015 Base g_tls_backend_get_default
> 0000000000093f80 g DF .text 0000000000000072 Base g_tls_backend_get_dtls_client_connection_type
> 0000000000093f60 g DF .text 000000000000001b Base g_tls_backend_get_server_connection_type
> 0000000000094000 g DF .text 0000000000000072 Base g_tls_backend_get_dtls_server_connection_type
> 0000000000094080 g DF .text 000000000000007f Base g_tls_backend_get_file_database_type
> 0000000000093d20 g DF .text 0000000000000084 Base g_tls_backend_get_type
> 0000000000093f20 g DF .text 000000000000001b Base g_tls_backend_get_certificate_type
> --8<---------------cut here---------------end--------------->8---
> 
> Libsoup does this:
> 
> --8<---------------cut here---------------start------------->8---
> static gboolean
> soup_socket_setup_ssl (SoupSocket *sock,
> const char *ssl_host,
> GCancellable *cancellable,
> GError **error)
> {
> SoupSocketPrivate *priv = soup_socket_get_instance_private (sock);
> GTlsBackend *backend = g_tls_backend_get_default ();
> --8<---------------cut here---------------end--------------->8---
> 
> ‘g_tls_backend_get_default’ itself looks like this:
> 
> --8<---------------cut here---------------start------------->8---
> GTlsBackend *
> g_tls_backend_get_default (void)
> {
> return _g_io_module_get_default (G_TLS_BACKEND_EXTENSION_POINT_NAME,
> "GIO_USE_TLS", NULL);
> }
> --8<---------------cut here---------------end--------------->8---
> 
> Could you try setting the ‘GIO_USE_TLS’ environment variable? Like:
> 
> export GIO_USE_TLS=tls
> 
> or maybe:
> 
> export GIO_USE_TLS=GTlsBackend
> 
> and then run Flatpak in that environment?
> 
> TIA,
> Ludo’.

bug#34861: TLS Error with Flatpak

[Ricardo Wurmus]

Raghav Gururajan <rvgn@disroot.org> writes:

> Should I be running just "export GIO_USE_TLS=tls" as it is mentioned
> or should I insert it in some other command/syntax?

Just that.  And then after that run the flatpak command in the same
shell session.

--
Ricardo

bug#34861: TLS Error with Flatpak

[Raghav Gururajan]

Hello!

Adding remote repo in Flatpak is working now. Thank you very much. Can you make export variable information mentioned at the end "guix package -i flatpak" process?

Regards,
RG.

March 23, 2019 8:06 AM, "Ricardo Wurmus" <rekado@elephly.net> wrote:

> Raghav Gururajan <rvgn@disroot.org> writes:
> 
>> Should I be running just "export GIO_USE_TLS=tls" as it is mentioned
>> or should I insert it in some other command/syntax?
> 
> Just that. And then after that run the flatpak command in the same
> shell session.
> 
> --
> Ricardo

bug#34861: TLS Error with Flatpak

[Ludovic Courtès]

Hello,

"Raghav Gururajan" <rvgn@disroot.org> skribis:

> Adding remote repo in Flatpak is working now. Thank you very much.

Nice!

> Can you make export variable information mentioned at the end "guix package -i flatpak" process?

I think we should rather find out why GIO uses the “dummy” TLS backend
by default.  The GnuTLS backend is part of ‘glib-networking’, not GLib,
and ‘GIO_EXTRA_MODULES’ was not being set, which is why the correct TLS
backend wasn’t found.

Fixed in commit 16360cc884030eb69590dc18d9694b04c67273f6.

Once you’ve upgraded you should no longer need to set ‘GIO_USE_TLS’.

Thanks!

Ludo’.

bug#34861: TLS Error with Flatpak

[Ludovic Courtès]

Hello,

"Raghav Gururajan" <rvgn@disroot.org> skribis:

> Adding remote repo in Flatpak is working now. Thank you very much.

Nice!

> Can you make export variable information mentioned at the end "guix package -i flatpak" process?

I think we should rather find out why GIO uses the “dummy” TLS backend
by default.  The GnuTLS backend is part of ‘glib-networking’, not GLib,
and ‘GIO_EXTRA_MODULES’ was not being set, which is why the correct TLS
backend wasn’t found.

Fixed in commit 16360cc884030eb69590dc18d9694b04c67273f6.

Once you’ve upgraded you should no longer need to set ‘GIO_USE_TLS’.

Thanks!

Ludo’.