Gilles 'SO- stop being evil''s questions

On one machine with an up-to-date Ubuntu 20.04, certificates issued by Let's Encrypt are rejected by GnuTLS and only GnuTLS. They fail with applications that are linked with GnuTLS, such as Git and Lynx. They work with applications that are linked with other TLS stacks, such as OpenSSL, Firefox and Chrome. Sites with certificates issued by other CAs work fine.

I don't often use Git on sites with certificates from Let's Encrypt on this machine, so it's likely that this has been going on since 30 September 2021 when the old root of LE expired. What I don't understand is how an up-to-date Ubuntu has trouble with that.

Example:

$ git clone https://git.savannah.gnu.org/git/bash.git/
Cloning into 'bash'...
fatal: unable to access 'https://git.savannah.gnu.org/git/bash.git/': server certificate verification failed. CAfile: none CRLfile: none

And here's more detail from gnutls-cli --print-cert -p 443 {--sni-hostname=,}git.savannah.gnu.org:

Processed 140 CA certificate(s).
Resolving 'git.savannah.gnu.org:443'...
Connecting to '209.51.188.168:443'...
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
 - subject `CN=git.savannah.gnu.org', issuer `CN=R3,O=Let's Encrypt,C=US', serial 0x04fb91dc102c76be8ac0ae2d77169d581a7d, RSA key 4096 bits, signed using RSA-SHA256, activated `2022-04-28 09:26:15 UTC', expires `2022-07-27 09:26:14 UTC', pin-sha256="QokL42m6ShyuyTUCH1OtbQRsDL92EWuwFY9wGQM4TGI="
        Public Key ID:
                sha1:a8b73346c9460221472b9dfa1a1b80b3b5273994
                sha256:42890be369ba4a1caec935021f53ad6d046c0cbf76116bb0158f701903384c62
        Public Key PIN:
                pin-sha256:QokL42m6ShyuyTUCH1OtbQRsDL92EWuwFY9wGQM4TGI=


-----BEGIN CERTIFICATE-----
MIIGaTCCBVGgAwIBAgISBPuR3BAsdr6KwK4tdxadWBp9MA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMjA0MjgwOTI2MTVaFw0yMjA3MjcwOTI2MTRaMB8xHTAbBgNVBAMT
FGdpdC5zYXZhbm5haC5nbnUub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIIC
CgKCAgEAnxN8JSu/p8zU9d3SV7K82K+wV0GJTaJe1GgtkJCd5GD3v62HtHlvj9W5
ZQ/52R3UFvr5RCsEPNkWy52t2606qk+eTj0YeSWMBI97RUjIDA+FfAT8gGCdt9S8
LMWAv/YLQDWpOhyOLjfEAYti9H8JwY0Wl9v9oD3FvGrYHC87lppe5AIABne0HhO1
L95rP6KryxDBrIk5rn435MxqYakMw0YlTdk7z+xWtMk+27gaWnBxz1XhROUCOs2f
4mAFt6CDo8KrlbNBWajpulOzSV7OE0y8iXKnkh0ufpJoYusF+ujxcNMnaKChoztv
RkUbSy9J3Ql5diuxNQYNHmA3/gJ9/Yt/8y/RdaC0Gl5tdDkpA2OfkDT4icxs2jWw
Kqg3b4mfOmTeGo4jibHSq/o7qFAijGerykyIHd8OnKOSIgbc+5KZFD9mNIT40cBN
xK1PWSmy5oURZVaSaAj3IcaMFLmKsng1a0V4Tj/LY/v7mHJRyBnePvP5ESDAK05S
MYOC+n6/fgkrBwYsQs66MP5qMirbpwsYfAVvJKi4hpskKpzMaIClIcAcHB2Jg833
84z4n1iD2YFrTSxuboQ4nEeo2XvJ81L5JzWg/qpslhtdFa2AaYDyQ94NgyfMKcMD
c5kY8Y6NL+AYXrue3KLvrgHfjdp5o1uTAB+lgdzkUcAXvnfrnHMCAwEAAaOCAoow
ggKGMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUH
AwIwDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQUrhEMLJItVCDPBFYcDJU7X+Qnyvgw
HwYDVR0jBBgwFoAUFC6zF7dYVsuuUAlA5h+vnYsUwsYwVQYIKwYBBQUHAQEESTBH
MCEGCCsGAQUFBzABhhVodHRwOi8vcjMuby5sZW5jci5vcmcwIgYIKwYBBQUHMAKG
Fmh0dHA6Ly9yMy5pLmxlbmNyLm9yZy8wWwYDVR0RBFQwUoIUZ2l0LnNhdmFubmFo
LmdudS5vcmeCF2dpdC5zYXZhbm5haC5ub25nbnUub3Jngg5naXQuc3YuZ251Lm9y
Z4IRZ2l0LnN2Lm5vbmdudS5vcmcwTAYDVR0gBEUwQzAIBgZngQwBAgEwNwYLKwYB
BAGC3xMBAQEwKDAmBggrBgEFBQcCARYaaHR0cDovL2Nwcy5sZXRzZW5jcnlwdC5v
cmcwggEDBgorBgEEAdZ5AgQCBIH0BIHxAO8AdgApeb7wnjk5IfBWc59jpXflvld9
nGAK+PlNXSZcJV3HhAAAAYBvtQWDAAAEAwBHMEUCIQCq3KjnGPbwjCPLRopaQg8k
44cSTOPXxwL6j2K3UinJzgIgZCLiSdMQXs+5SCgCco+TepIBuay6rea1EPcYBIgg
RGoAdQDfpV6raIJPH2yt7rhfTj5a6s2iEqRqXo47EsAgRFwqcwAAAYBvtQeHAAAE
AwBGMEQCIE9iQbm55QZA3z4CL10wf61vDTcFytEfqiK4Ih1iOghGAiAVxynyluTl
hjRnRm9+G2jj7pb7Q4zs8V8s4A9hrb2NkTANBgkqhkiG9w0BAQsFAAOCAQEAnQ9q
9ZfZLrvxSE6UJ9rDTEJerFXFLjt6+LjvSKCXU1/qyoOvqkmCXz7dZAEq/5H7Okzr
PIxzJNCmxpo8PdUeJpV++YYs1xMG2vrTG5r+jG1DgWH0/RC+MnChVXTQU+y+8Ckh
b7hOt4m/ddyfIUDQbTTeDJFdCNJVOqbikBXx/bTkTZeel8V6qXMRnwMPKx3SNQCL
r2OQA/C9J/DWGb9LDZUM/DOSl8Y4/FhnSZ2fgUv4nL7IdijvMpWSXwLOqJR+i1fK
OvOmCH39AVGLbpW/7FB2rOq5SONgk2QS97pQU4qzBjWDd97n+pGnpkw+8At0KxRl
cfWgxjtDVqMVBfhgxQ==
-----END CERTIFICATE-----

- Certificate[1] info:
 - subject `CN=R3,O=Let's Encrypt,C=US', issuer `CN=ISRG Root X1,O=Internet Security Research Group,C=US', serial 0x00912b084acf0c18a753f6d62e25a75f5a, RSA key 2048 bits, signed using RSA-SHA256, activated `2020-09-04 00:00:00 UTC', expires `2025-09-15 16:00:00 UTC', pin-sha256="jQJTbIh0grw0/1TkHSumWb+Fs0Ggogr621gT3PvPKG0="

-----BEGIN CERTIFICATE-----
MIIFFjCCAv6gAwIBAgIRAJErCErPDBinU/bWLiWnX1owDQYJKoZIhvcNAQELBQAw
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwHhcNMjAwOTA0MDAwMDAw
WhcNMjUwOTE1MTYwMDAwWjAyMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNTGV0J3Mg
RW5jcnlwdDELMAkGA1UEAxMCUjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQC7AhUozPaglNMPEuyNVZLD+ILxmaZ6QoinXSaqtSu5xUyxr45r+XXIo9cP
R5QUVTVXjJ6oojkZ9YI8QqlObvU7wy7bjcCwXPNZOOftz2nwWgsbvsCUJCWH+jdx
sxPnHKzhm+/b5DtFUkWWqcFTzjTIUu61ru2P3mBw4qVUq7ZtDpelQDRrK9O8Zutm
NHz6a4uPVymZ+DAXXbpyb/uBxa3Shlg9F8fnCbvxK/eG3MHacV3URuPMrSXBiLxg
Z3Vms/EY96Jc5lP/Ooi2R6X/ExjqmAl3P51T+c8B5fWmcBcUr2Ok/5mzk53cU6cG
/kiFHaFpriV1uxPMUgP17VGhi9sVAgMBAAGjggEIMIIBBDAOBgNVHQ8BAf8EBAMC
AYYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMBMBIGA1UdEwEB/wQIMAYB
Af8CAQAwHQYDVR0OBBYEFBQusxe3WFbLrlAJQOYfr52LFMLGMB8GA1UdIwQYMBaA
FHm0WeZ7tuXkAXOACIjIGlj26ZtuMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcw
AoYWaHR0cDovL3gxLmkubGVuY3Iub3JnLzAnBgNVHR8EIDAeMBygGqAYhhZodHRw
Oi8veDEuYy5sZW5jci5vcmcvMCIGA1UdIAQbMBkwCAYGZ4EMAQIBMA0GCysGAQQB
gt8TAQEBMA0GCSqGSIb3DQEBCwUAA4ICAQCFyk5HPqP3hUSFvNVneLKYY611TR6W
PTNlclQtgaDqw+34IL9fzLdwALduO/ZelN7kIJ+m74uyA+eitRY8kc607TkC53wl
ikfmZW4/RvTZ8M6UK+5UzhK8jCdLuMGYL6KvzXGRSgi3yLgjewQtCPkIVz6D2QQz
CkcheAmCJ8MqyJu5zlzyZMjAvnnAT45tRAxekrsu94sQ4egdRCnbWSDtY7kh+BIm
lJNXoB1lBMEKIq4QDUOXoRgffuDghje1WrG9ML+Hbisq/yFOGwXD9RiX8F6sw6W4
avAuvDszue5L3sz85K+EC4Y/wFVDNvZo4TYXao6Z0f+lQKc0t8DQYzk1OXVu8rp2
yJMC6alLbBfODALZvYH7n7do1AZls4I9d1P4jnkDrQoxB3UqQ9hVl3LEKQ73xF1O
yK5GhDDX8oVfGKF5u+decIsH4YaTw7mP3GFxJSqv3+0lUFJoi5Lc5da149p90Ids
hCExroL1+7mryIkXPeFM5TgO9r0rvZaBFOvV2z0gp35Z0+L4WPlbuEjN/lxPFin+
HlUjr8gRsI3qfJOQFy/9rKIJR0Y/8Omwt/8oTWgy1mdeHmmjk7j1nYsvC9JSQ6Zv
MldlTTKB3zhThV1+XWYp6rjd5JW1zbVWEkLNxE7GJThEUG3szgBVGP7pSWTUTsqX
nLRbwHOoq7hHwg==
-----END CERTIFICATE-----

- Certificate[2] info:
 - subject `CN=ISRG Root X1,O=Internet Security Research Group,C=US', issuer `CN=DST Root CA X3,O=Digital Signature Trust Co.', serial 0x4001772137d4e942b8ee76aa3c640ab7, RSA key 4096 bits, signed using RSA-SHA256, activated `2021-01-20 19:14:03 UTC', expires `2024-09-30 18:14:03 UTC', pin-sha256="C5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M="

-----BEGIN CERTIFICATE-----
MIIFYDCCBEigAwIBAgIQQAF3ITfU6UK47naqPGQKtzANBgkqhkiG9w0BAQsFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
DkRTVCBSb290IENBIFgzMB4XDTIxMDEyMDE5MTQwM1oXDTI0MDkzMDE4MTQwM1ow
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwggIiMA0GCSqGSIb3DQEB
AQUAA4ICDwAwggIKAoICAQCt6CRz9BQ385ueK1coHIe+3LffOJCMbjzmV6B493XC
ov71am72AE8o295ohmxEk7axY/0UEmu/H9LqMZshftEzPLpI9d1537O4/xLxIZpL
wYqGcWlKZmZsj348cL+tKSIG8+TA5oCu4kuPt5l+lAOf00eXfJlII1PoOK5PCm+D
LtFJV4yAdLbaL9A4jXsDcCEbdfIwPPqPrt3aY6vrFk/CjhFLfs8L6P+1dy70sntK
4EwSJQxwjQMpoOFTJOwT2e4ZvxCzSow/iaNhUd6shweU9GNx7C7ib1uYgeGJXDR5
bHbvO5BieebbpJovJsXQEOEO3tkQjhb7t/eo98flAgeYjzYIlefiN5YNNnWe+w5y
sR2bvAP5SQXYgd0FtCrWQemsAXaVCg/Y39W9Eh81LygXbNKYwagJZHduRze6zqxZ
Xmidf3LWicUGQSk+WT7dJvUkyRGnWqNMQB9GoZm1pzpRboY7nn1ypxIFeFntPlF4
FQsDj43QLwWyPntKHEtzBRL8xurgUBN8Q5N0s8p0544fAQjQMNRbcTa0B7rBMDBc
SLeCO5imfWCKoqMpgsy6vYMEG6KDA0Gh1gXxG8K28Kh8hjtGqEgqiNx2mna/H2ql
PRmP6zjzZN7IKw0KKP/32+IVQtQi0Cdd4Xn+GOdwiK1O5tmLOsbdJ1Fu/7xk9TND
TwIDAQABo4IBRjCCAUIwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYw
SwYIKwYBBQUHAQEEPzA9MDsGCCsGAQUFBzAChi9odHRwOi8vYXBwcy5pZGVudHJ1
c3QuY29tL3Jvb3RzL2RzdHJvb3RjYXgzLnA3YzAfBgNVHSMEGDAWgBTEp7Gkeyxx
+tvhS5B1/8QVYIWJEDBUBgNVHSAETTBLMAgGBmeBDAECATA/BgsrBgEEAYLfEwEB
ATAwMC4GCCsGAQUFBwIBFiJodHRwOi8vY3BzLnJvb3QteDEubGV0c2VuY3J5cHQu
b3JnMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaWRlbnRydXN0LmNvbS9E
U1RST09UQ0FYM0NSTC5jcmwwHQYDVR0OBBYEFHm0WeZ7tuXkAXOACIjIGlj26Ztu
MA0GCSqGSIb3DQEBCwUAA4IBAQAKcwBslm7/DlLQrt2M51oGrS+o44+/yQoDFVDC
5WxCu2+b9LRPwkSICHXM6webFGJueN7sJ7o5XPWioW5WlHAQU7G75K/QosMrAdSW
9MUgNTP52GE24HGNtLi1qoJFlcDyqSMo59ahy2cI2qBDLKobkx/J3vWraV0T9VuG
WCLKTVXkcGdtwlfFRjlBz4pYg1htmf5X6DYO8A4jqv2Il9DjXA6USbW1FzXSLr9O
he8Y4IWS6wY7bCkjCWDcRQJMEhg76fsO3txE+FiYruq9RUWhiF1myv4Q6W+CyBFC
Dfvp7OOGAN6dEOM4+qR9sdjoSYKEBpsr6GtPAQw4dy753ec5
-----END CERTIFICATE-----

- Status: The certificate is NOT trusted. The certificate chain uses expired certificate. 
*** PKI verification of server certificate failed...
*** Fatal error: Error in the certificate.

The machine's clock is correct, and the certificates listed here are not expired. However, the issuer CN=DST Root CA X3,O=Digital Signature Trust Co. has a certificate in the trusted store (/etc/ssl/certs/ca-certificates.crt — I've confirmed that GnuTLS reads this file), which expired on 2021-09-30.

This should not be a problem, because this certificate is not needed to establish a chain of trust: the entity CN=ISRG Root X1,O=Internet Security Research Group,C=US has a self-signed certificate in /etc/ssl/certs/ca-certificates.crt. Other TLS implementations cope with it just fine, so why can't GnuTLS figure it out on my machine?

How do I make GnuTLS accept Let's Encrypt certificates on my Ubuntu 20.04?

I have an Ubuntu machine with Docker installed. (The Ubuntu version is 20.04, but this also affects 18.04, and possibly non-LTS versions as well.) The upgrade of the docker.io package to the current version from focal-security fails:

Preparing to unpack .../docker.io_20.10.7-0ubuntu1~20.04.1_amd64.deb ...
The aufs storage-driver is no longer supported.
Please ensure that none of your containers are
using the aufs storage driver, remove the directory
/var/lib/docker/aufs and try again.
dpkg: error processing archive /var/cache/apt/archives/docker.io_20.10.7-0ubuntu1~20.04.1_amd64.deb (--unpack):
 new docker.io package pre-installation script subprocess returned error exit status 1
dpkg: error while cleaning up:
 installed docker.io package post-installation script subprocess returned error exit status 1

This is a known bug, but the bug has been marked as “won't fix” based on the Ubuntu Docker packaging policy.

Quoting multiple people here:

This is a breaking change for an update that should not happen on an LTS version.

An upgrade requiring so much manual intervention like this should never happen in an LTS release.

You're correct about this in the general case. Unfortunately Docker is an exception. (…)

So, as an exception for Docker, we update to newer upstream releases without concern for backwards compatibility of the behaviour of Docker itself, instead relying entirely on upstream's decisions. In this case and based solely on the analysis already presented by others here, this means that we don't expect to be patching the aufs storage driver back in to our packaging ourselves. (…)

Following the policy as it stands, this isn't something we expect to fix, and therefore I'm marking this bug Won't Fix.

I find the reasoning baffling — if I'm using a stable distribution, I expect upgrades to be seamless, and I don't expect to have the latest version of programs. If I want a rolling release, I know where to find it, and it won't be called LTS. But this isn't the venue for this discussion.

My question here is, what do I do next? How do I “ensure that none of [my] containers are using the aufs storage driver”? Keeping an older, unmaintained version of Docker is a no-starter. I need to have security updates.

None of my containers use advanced features that would depend on the storage driver. I'm perfectly happy with upgrading or migrating my containers. How do I do that?

On a default Ubuntu 16.04 (xenial) installation, GTK3 applications (which include most of the default GUI applications) have smooth scrolling activated. How do I disable it?

For example, in Gedit, pressing PageUp/PageDown causes the text to scroll one pixel line at a time until it settles to its final position one page further up/down. The same behavior occurs in the file selection dialog box, in Nautilus, etc. How do I turn off smooth scrolling, i.e. how do I make the PageUp/PageDown keys show the previous/next page immediately?

I just discovered that many Gnome dialog boxes do have keyboard shortcuts to reach controls or tabs with Alt+letter — only they are not displayed. The shortcuts do appear in the form of an underlined letter when I hold Alt down.

How can I make the shortcut letter always underlined, so that the shortcuts are discoverable? Same question for menu items, by the way.

What I see normally:

What I see with Alt held down, and I want to see all the time:

I found https://stackoverflow.com/questions/10103922/gnome-3-always-show-altx-keyboard-shortcuts, which suggests adding gtk-auto-mnemonic = 0 to ~/.gtkrc-2.0 for Gnome 2 and dconf write /org/gnome/desktop/interface/automatic-mnemonics false for Gnome 3. Neither seems to have any effect in my session though.

In Ubuntu 12.04, in my sessionafter setting automatic-mnemonics to false, shortcut letters still don't appear unless I hold Alt down (I tried in pavucontrol, evince and gnome-control-center). I start my session from Lightdm and I am not running a Gnome session. My window manager is Sawfish. I do have a D-Bus daemon, and other dconf settings take effect immediately (e.g. /org/gnome/desktop/background/draw-background). If I start another session with startx on the same machine, the change of automatic-mnemonics is not reflected. However, if I run a default (Unity or Gnome) session in a different account, automatic-mnemonics takes effect immediately.

When my laptop (running Ubuntu 12.04) is on battery, the disk powers off after a few seconds of inactivity — about 20s. I use lightdm to log in, and have some Gnome components running (I have gnome-panel and a number of dependencies), but I use neither Gnome nor Unity as a desktop environment (I start the Sawfish window manager manually).

20 seconds is ridiculously fast: in practice the disk keeps powering down and back up immediately, which is slow (bad user experience), potentially damaging the drive (though I've never been able to find concrete data abouth this), and actually consumes more energy when the spun-down time is very short (a 2008 analysis found that for a particular disk, standby mode saved energy if it lasted for more than 9s; mine often last less).

Therefore I want to increase this timeout. How can I do this? I don't know what software is causing the spindown.

Looking at the running processes, I only see upowerd which might be related to power management. Killing it makes no difference.

The timeout probably comes from the disk itself: hdparm -I /dev/sda reports “Advanced power management level: 1” (which doesn't match the 20 seconds, as it should mean 5 seconds according to the hdparm documentation…). I have seen that same machine with the value 254 at other times.

What is causing the value to change while on battery power? I can't see any call to hdparm in /etc/acpi/*.

I'm about to reinstall Ubuntu on a netbook with a tiny disk. Because of the tiny disk size, I'd strongly prefer to have a swap file than a swap partition. However, I want to be able to hibernate.

I know that hibernation needs to be manually enabled. I also know that hibernation to a swap file works on the old Eeebuntu that I'll be replacing, so hardware support is not a concern.

Does the precise kernel support hibernation to a swap file? What if anything do I need to configure?

Please note that I'm looking for reliable, up-to-date information. I don't mind if hibernation isn't supported out-of-the-box, but I'd prefer not to have to recompile a kernel if I can do without. I'll balk at patching the kernel for that machine.

What is the Ubuntu way for system administrators to receive system notifications, which typically take the form of e-mail sent to the root account?

Examples of such notifications are the output of cron jobs, or degraded RAID notifications.

On a pretty much default Ubuntu 10.04 installation, I can't find any way that anything happens to root's mail other than being deposited in /var/mail/root. How are users supposed to 1. discover it and 2. read it as it arrives?

I observe that on a warty, the installer added root: myusername to /etc/aliases. So back then the user who installed the system if (s)he read the local mail. So there seems to have been a regression somewhere along the way. Still this was not a complete solution, because Ubuntu users can't be expected to be aware that they have local mail and should set up their mail client to read it.

ADDED: given current replies, a server user should be able to cope, provided he's aware of the issue. Fair enough. But consider J. Random Desktop User, who doesn't know how to use a command line, and only knows how to click the mailbox icon to read his mail. How can he be notified that his system wants to tell him something? (Allow a one-time intervention by a more competent user if that's unavoidable.)