It happened: Now that I am an uploading DD for a few months I finally
made my first upload of
a package – mind you, not of apt, but of a package I declared my intend
to "steal" from another person a few weeks ago on
later also in a bugreport (#835128).
The result is that apt-transport-tor which used to be maintained by Tim
Retout as a modified copy of apt code is now maintained by the APT team
(with him and me as uploaders) using the apt code directly via a few
That brings along a bunch of changes which I mentioned in the list/bug
as well, but for completeness:
- tor+https options consistently fall back to tor -> https -> http
- tor+http options consistently fall back to tor -> http
- socks5h isn't forced. It is just the default (and the only one which
will work with (tor+)http at the moment; any with tor+https)
- a tor-proxy having apt-transport-tor as username & no password
(default) will automatically pick a password based on the target
host to get you in a new circuit for each host.
- the User-Agent isn't forced to an all-tor-users-have-the-same value.
Especially with tor+http being our normal http I think its better to
"hide" between other http users than saying straight that you are
a tor user (even if the IP gives it away that you are).
- tor+https doesn't allow redirection to tor+http. We have this for
a while for https -> http already (-tor "broke" it). I think if a user
went as far as configuring a https source it should stay an https
source or fail.
- http/https can be disabled to avoid accidentally adding such sources
- http will not try to connect to .onion domains (RFC7687) and the error
hints at using tor+http
- the methods run as
_apt instead of
root (like the rest of the apt methods)
I had tried a few times to get people to provide feedback, but there
wasn't much. I guess this is good as it means nobody has any complains
about it. We will see if that will change now that it is on its way to
archive, buildds, mirrors and users: Brace for impact in any case!
I sign all my mails with GPG for a few years now. Beside the huge
hypothetical boner and the moral highground this provides it is also
nice to get some minor benefits like a ham bonus on Debian mailinglists
(even if we all know how that is implemented).
It is hard to belief sometimes, but I don't sent mails to Debian only
through. Sometimes I get questions what that strange attachment is
nobody can open. Its okay through, I don't blame them.
What I can't tolerate through is mails from me ending up in Spam because
I don't sent mails from one of the big (free) mail providers (and to
a bunch of people all at once). There are a bunch of options available
to make my mails look a bit more legit even for those mailservers which
don't understand gpg in the form of
DMARC. The bonus they provide
isn't huge (if not non-existent) and there are problems and shortcoming
involved I don't have to deal with with gpg signing but the things you
do to avoid having to hear a "lets all just use
a facebook/whatsapp/whatever group for communication"…
[note that I have added most of this to kalnischkies.de, but the setup
was initially setup for and tested on an other domain – I will just say
example.org here to not have you confused by blogpost vs. reality]
Easy to do if you have just one place you sent mails from – which in my
case is true as I sent mails by letting msmtp connect to the SMTP of my
hoster, which for rough emergencies also has a webfrontend so all I had
to do is add a TXT record in DNS: "v=spf1 mx -all".
And as I have subdomains (for mailinglists mainly) which sent mails,
too, add for all these subdomains "v=spf1 mx:example.org -all" as well.
Additionally, if you have subdomains which do not sent mails, you can
say that they all should fail spf unconditionally: "v=spf1 -all" (You
can set this also for subdomains you don't have, but spammers use
Is a bit harder. My hosts SMTP doesn't support it (they are equally
dubious of its usefulness as I am), but don't fear: I can add a DKIM
signature locally before passing it on the hosts SMTP! Arch user
2ion has documented his
mine is rather similar, just that I installed python3-dkim, took
from git (changing interpreter to python3) and adapted my already
existent sendmail wrapper [= a forgot to attach attachement detection
script] to use that python script.
Of course, I had to generate some private keys for this exercise. I used
"opendkim-genkey -b 2048 -d example.org -s mail" for that (the default
keylength is 1024 – the spec seems to suggest that implementations are
required to support up to 2048, so if I have to do it, lets do it big).
The "-s mail" part is freely choosable by the way for keyrollovers and
stuff. Beside the private key that command also generates a textfile
which contains what has to be added as another TXT record in DNS.
That's easy again: Yet another TXT record in DNS: "v=DMARC1; p=none".
I think I will eventually use more stricter settings and might even
explore the report facilities but for now that seems to work okayish.
Sending mails to a Google Mail account (as they make use of those
features and add results to mail headers) can tell you if its working.
Mail-Tester is also a nice service to test
your setup (even through it targets mostly at newsletter creators) which
tests various details, presents it friendly and even gives some tips (if
it works that is, sometimes it seems to have problems).
A bit of busy work and I see how that could be oh so much more complex
if I would have a different setup, but in the one I have it seems to
have a very slight net-benefit, even if I would like to not need it in
the first place…
On the upside, it gives me another bunch of ham bonuspoints on Debian
mailinglists, which means I can probably spam quite a bit now… 😉︎
I just hope I also get enough bonus points on setups I was setting this