[gitweb] "GnuTLS recv error" on clone/push/pull

Hi FB Community.

Problem Description

I’ve been running gitweb on my FB for a while now successfully with no issues. My setup is as follows:

  • FB exposed on the internet with a DNS name and LetsEncrypt certificate, managed by FB, say “box.example.com
  • FB is also reachable in my internal network with a fixed IP
  • I use both external and internal Git clients, so I disable certificate validation when using the internal IP.
  • I have a dedicated user account on my FB who has access to Git repos, “kopfkind”

This has been working perfectly until last week. I’ve discovered today that I now cannot clone/push/pull anymore. I get an error message:

GnuTLS recv error (-110): The TLS connection was non-properly terminated.

I’ve been trying different clients (git 2.30.2 from a Debian stable box, WorkingCopy on an iPad). The gitweb UI is available when logging into my FB, I can see and browse my repos there.

I’ve put a full verbose log on pasebin here: gitweb issue on freedombox - Pastebin.com (will expire in 30d from now)

Steps to Reproduce

  1. Set up a git repo and user on FB
  2. Use a remote client, try to pull

Expected Results
No errors, as before.

Actual results

Excerpt from the full log (linked above) - and yes, the binary gibberish is part of it:

git clone https://box.example.com/gitweb/writing.git
16:38:20.952376 http.c:756              == Info: Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
16:38:20.969666 http.c:756              == Info: GnuTLS recv error (-110): The TLS connection was non-properly terminated.
16:38:20.969707 http.c:756              == Info: Failed receiving HTTP2 data
16:38:20.969728 http.c:756              == Info: Failed sending HTTP2 data
16:38:20.969744 http.c:756              == Info: Connection #1 to host box.example.com left intact
fatal: unable to access 'https://box.example.com/gitweb/writing.git/': GnuTLS recv error (-110): The TLS connection was non-properly terminated.


  • “You are running Debian GNU/Linux 11 (bullseye) and FreedomBox version 22.24. FreedomBox is up to date.”
  • Raspi 2 Model B
  • Official FB Raspi image, been running for quite some time, even through major OS upgrades underneath

Am I having some protocol issues there? It’s complaining about some HTTP2 stuff, but I do not understand what the root cause for this is.

Any help would be greatly appreciated, thanks a lot!


Retrying today showed that it is now working with all my clients. I do not see any FB update logs in the meantime, so I am still puzzled as to the root cause of yesterday’s issues. But I am not able to reproduce it anymore.

I will keep an eye on it. Thanks for everybody who’s read my question and put some thought to it.


I’ve removed the “[solved]” tag from the title again, since the issue has reappeared. I am clueless as to what the root cause it. There are no indications in dpkg.log, unattended-upgrades.log, apache logs, auth logs etc.

If anybody has an idea what could cause these issues, please do let me know. I’ll need to move my git repos off my FB due to this :crying_cat_face:


Hi Axel,

I noticed that your log mentions a NTLM proxy. Do you get the same error without this proxy?

16:38:20.758813 http.c:756              == Info: NTLM-proxy picked AND auth done set, clear picked!

I think the relevant Debian package in FreedomBox that could possibly throw this error is libcurl3-gnutls. You can run apt search libcurl3-gnutls on your FreedomBox to find the installed version.

This Debian bug seems to be remotely related: https://bugs.debian.org/671827

Joseph, thanks for picking up this thread. I am not aware of any proxies in use, my connection is laptop => freedombox directly with both on the same local wifi. However I do see that libntlm0 is installed, I assume FB uses it internally somewhere.

That being said your suggestion pointed me in the right direction. Most results I could find onthe web would suggest recompiling git with libssl instead of libgnutls. This would be possible on my laptop (also running Debian), but not for my iPad client - I am using “WorkingCopy” there, a closed product.

What I did in the end was upgrading git and gitweb from debian backports on my freemdombox, now it seems to work on all clients (fingers crossed!).

kopfkind@box:~$ dpkg -l gitweb
ii  gitweb         1:2.34.1-1~bpo11+1 all          fast, scalable, distributed revision control system (web interface)

Administration through plinth / the web interface is still possible. I can access the section and create new repos as before. Thanks for the nudge in the right direction!


1 Like

Update: I got a minor package update of libtiff this morning which somehow broke the setup again, same error as before. I’ve checked /var/log/dpkg.log and saw that there has been an additional update to libcurl3-gnutls on Jan 28. Maybe the package updates today have triggered a reload of apache2 so that the new version of the library got loaded - I would not expect libtiff to break git-web.

However, fixing it was easy. I just had to upgrade the gitweb package from backports again:

sudo apt update && sudo apt upgrade
sudo systemctl reload apache2

This gave me a gitweb-upgrade from 2.34.1-1~bpo11+1 => 2.39.1-0.1~bpo11+1. After having reloaded Apache, pulling/pushing from my clients worked again.

In order for future stable upgrade not breaking this again, I apt-pinned the backports version of gitweb:

kopfkind@box:~$ cat /etc/apt/preferences.d/99debian-backports 
Package: gitweb
Pin: release a=bullseye-backports
Pin-Priority: 501

I hope this is the last time I needed to tweak this manually :slight_smile:

Cheers & HTH!

1 Like