I started using GnuPG in 2002. I dont usually do stuff that requires heavy privacy so I dont care much for it. From time to time, I just encrypt some useless crap so if anyday I had serious stuff to encrypt it would not look obviously suspicious.
Things is most of the people I communicate with are not using GnuPG and are probably not about to.
There is also an obvious issue with GnuPG is how to share key among computers/clients. How to decrypt messages with your phone or webmail? Copy the private key everywhere? It might just be worse than having no security at all.
I dont use GnuPG much, especially since I created my key in 2002 and don’t even know how secure this key is still now. I need it nonetheless to sign stuff like packages. Confronted to the problem of having to copy the key by hand on one more laptop, I considered dropping my current set and, inspired by this example of primary key/subkeys model and debian’s one, to have a primary key secure somewhere and give a short-lived subkey per device.
But, it fixes not much of GnuPG problems, and implies lot of annoying not automated work, not satisfying. And anyway, if en/decrypt can only work for one subkey. So one subkey per device is not really working.
To make the process less painy, on a box being made from time to time available over network, I did as follow:
I created a primary key running
gpg --expert --gen-key (cannot sign, cannot encrypt) with 4y expiry. (more entropy with
rngd -r /dev/urandom).
I added with
trust save the relevant additional addresses running
gpg --expert --edit-key myemail
I created a sign and a encrypt subkey with no expiry (considering that they ll be revoked on the fly from the primary whenever it make sense).
I made up gpg-grabsub.sh that prompt for the hostname of the box hosting the keyring, will import the ring and remove the primary key from it, leaving just the necessary keys to sign and encrypt.
This script could probably be used in a chain (box secured from the net -> script run on gate server -> script run on a end client). It requires further testing.
Using ssh-updatekeys, you can set up and maintain ~/.ssh/authorized_keys with specific sets on the fly.
You just have to put your public keys on a public git repository. The script will fetch the keys, either by git + SSH (for write access) or just git + https (for read access).
It can handle different sets of keys (for instance you may want to differenciate keys with or without passphrares). In the git repository, any directory with a name starting by set (set0, setA, setTest, etc) will be treated as a set.
(ssh-updatekeys.sh is part of my -utils package).
Update : you can now grab it with the command
wget ssh.rien.pl -O ssh-updatekeys.sh
I’m still using SquirrelMail, even though it looks a bit old. It’s robust and just works – and when I’m using a webmail, that’s mandatory.
SquirrelMail does not use CardDav but some sort of .abook format (that I hope is the same abook as mutt).
I just wrote carddav2abook.pl, a wrapper that requires an ~/.carddav2abookrc with the following:
carddav = https://HOST/remote.php/carddav/addressbooks/USER/contacts_shared_by_USER?export user = USER password = PASSWORD abook = /var/lib/squirrelmail/data/USER.abook wget_args = --no-check-certificate
As you notice, I’m using a specific export account that has been given only read access to this file. Otherwise the CardDav url would not include the _shared_by_USER part.
I configured it to directly write .abook in SquirrelMail data directly. Obviously, it means you need to adjust read write access for the relevant user (or use www-data, but I would not recommend to store password in an rcfile given to this user).
Once it works, just put up a cronjob (with 2>/dev/null since the perl vCard module tends to print some garbage).
(carddav2abook.pl is part of my -utils-webmail package).
After switching to Devuan, I got suddenly dolphin complaining that it cannot mount an USB Key. Since Devuan is back to polkit to get rid of systemd (but polkit is probably part of the problem too), the fix is to add a /etc/polkit-1/localauthority/50-local.d/auto-mount.pkla with:
And make sure users belong to plugdev.
I did some major changes to my local server Bind9 setup. I was at the begin caching apt and steam depots on this server using dnsspoof from dsniff. After a few upgrades dnsspoof started to do nothing: it was up, on the proper device, noticing requests relevant to be spoofed but the end clients were still getting the real DNS records, not the spoofed ones.
So, I eventually decided to use directly Bind9, already up as a cache server, to do the spoofing.
Good, except that then nginx, running on the same server as Bind9, then required another resolver than Bind9 in order to get the real DNS records, since Bind9 was replying spoofed crap.
Bind9 is fully featured and I found that the easier way to get it do gives tailored replies depending on the clients is to use the views. But using views implies that every zones are included into views. You cannot just add a “view” for a given purpose and let your general setup.
A setup that should work more or less out of the box is provided with my packages -utils-cache-steam and -utils-cache-apt.
Using this, you must edit your /etc/bind/named.conf so it no longer directly include zones definition files but include the /etc/bind/named.conf.views that in turn will include relevant zones. Clients are set in /etc/bind/named.conf.acl and by default handle 192.168.1.1, 10.0.0.1 and 10.0.1.0 as server host (the two later are being used in my silent low energy consumption home server proposed setup).
It includes /etc/bind/named.conf.cache.sh that will (re-)generate zones definition files (named.conf.cache…) depending on the services you are actually caching.
This could probably be improved (annoying to make differences between 192.168, 10.0.0 and 10.0.1…) but it works fine. You can test by pinging packages.devuan.org from the server (loopback) or any clients.
A while ago, I was encouraging to give a try to systemd. Well, now I know better and decided to get away from this tool that clearly wants to replace many parts of my system at once. There are many articles about systemd, why it’s good and why it’s not. I kept on open mind of the topic, I tried systemd on many boxes. Some stuff just stopped to work, or did not work as I expected it to work. Maybe I’m clueless but I’m not alone. Point is with systemd, I’m able to do less and it takes me more time.
Now devuan is installable so I installed it already on two of my boxes. So far, no problem. I wonder how Devuan will cope with bugs reports and stuff in the long run.
The process is as simple as:
# select ascii (= testing)
dpkg -i devuan-baseconf_0.6.4+devuan3_all.deb
# comment debian sources
apt-get install devuan-keyring
apt-get update && apt-get upgrade
apt-get --purge remove systemd systemd-shim
dpkg --list | grep systemd
apt-get --purge remove libsystemd-journal0 libsystemd-login0
apt-get --purge autoremove
One day you set up some service, for instance like this spam slayer setup. Later arises the situation when the distribution package use user account named X (for instance debian-spamd) while you set up things to use another one (for instance Debian-exim).
The easiest fix is to give them a common uid:
usermod –non-unique –uid 101 debian-spamd
(101 being user id of Debian-exim account).
Obviously it could be best to review the setup to really use two separates accounts. But it’s up to you to decide whether it’s changing it.
You may also add –gid too.