Note: Moving/copying PGP keys

List existing keys to find key ID$ gpg --list-keys
pub rsa4096 2014-03-06 [SC]
uid [ultimate] Bård Bjerke Johannessen
uid [ultimate] Bård Bjerke Johannessen
sub rsa4096 2014-03-06 [E]

Export public and private key for selected key ID$ gpg --output public.gpg --armor --export 1EE9C2829B27AD4CC0BB3201EFC8F593CE2E378F$ gpg --output private.gpg --armor --export-secret-key 1EE9C2829B27AD4CC0BB3201EFC8F593CE2E378F

copy keys to another host$ scp public.gpg private.gpg

Import public key$ gpg --import public.gpg 
gpg: directory '/home/bbj/.gnupg' created
gpg: keybox '/home/bbj/.gnupg/pubring.kbx' created
gpg: /home/bbj/.gnupg/trustdb.gpg: trustdb created
gpg: key EFC8F593CE2E378F: public key "Bård Bjerke Johannessen" imported
gpg: Total number processed: 1
gpg: imported: 1

Import private key$ gpg --import private.gpg 
gpg: key EFC8F593CE2E378F: "Bård Bjerke Johannessen" not changed
gpg: key EFC8F593CE2E378F: secret key imported
gpg: Total number processed: 1
gpg: unchanged: 1
gpg: secret keys read: 1
gpg: secret keys imported: 1

Set trust

gpg --edit-key 1EE9C2829B27AD4CC0BB3201EFC8F593CE2E378

Apache proxying for backends with self-signed, invalid or expired certificates

When proxying for an HTTPS backend, Apache will attempt to verify the validity of the certificate provided by that backend. In cases where the backend is using a self-signed, invalid or expired certificate, this will fail with an internal server error (HTTP status code 500) and messages such as these in the servers error log:

[proxy:error] [pid 15150] (502)Unknown error 502: [client] AH01084: pass request body failed to (
[proxy:error] [pid 15150] [client] AH00898: Error during SSL Handshake with remote server returned by /path/to/file.html
[proxy_http:error] [pid 15150] [client] AH01097: pass request body failed to ( from ()

Now, self-signed, invalid or expired certificates are normally not a particularly good idea, but as long as you are familiar with the pitfalls, there’s nothing inherently wrong with using them. To force Apache to allow it, all you need to do is include the following directives in the affected context (server/virtual host/proxy section):

SSLProxyCheckPeerCN off

SSLProxyCheckPeerName off

SSLProxyCheckPeerExpire off

Disabling mouse-support from vim on Debian Stretch

For some insane reason, mouse support (via GPM) is enabled by default i vim on Debian Stretch (and maybe other, what do I know). Due to the equally insane practice of letting system defaults (from /usr/share/vim/vim80/defaults.vim) override site local configurations (from /etc/vim/vimrc), figuring out how to disable the madness was not trivial. Luckily though, the fix was simple enough once I figured it all out:

--- /etc/vim/vimrc-ORIG	2019-01-31 13:45:57.998082982 +0100
+++ /etc/vim/vimrc	2019-01-31 13:46:13.607915228 +0100
@@ -14,7 +14,9 @@
 " any settings in these files.
 " If you don't want that to happen, uncomment the below line to prevent
 " defaults.vim from being loaded.
-" let g:skip_defaults_vim = 1
+source $VIMRUNTIME/defaults.vim
+let g:skip_defaults_vim = 1
+set mouse =
 " Uncomment the next line to make Vim more Vi-compatible
 " NOTE: debian.vim sets 'nocompatible'.  Setting 'compatible' changes numerous