[tor-relays] Archive key from deb.torproject.org was renewed!

lists · July 16, 2024, 12:03pm

Hi @all,

The package deb.torproject.org-keyring did not update the key
tor-archive-keyring.gpg in /usr/share/keyrings/
only deb.torproject.org-keyring.gpg was updated.

I had to replace it by hand. Renewing your key is important,
otherwise you will not receive any Tor updates. One line:

wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --dearmor | tee /usr/share/keyrings/tor-archive-keyring.gpg >/dev/null

More Info:

···

--
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

lists · July 16, 2024, 1:47pm

There are 2 keys. The key for the Repository must be added manually or per
ansible playbook role.
tor-archive-keyring.gpg =
https://deb.torproject.org/torproject.org/
A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc

apt update && apt install tor deb.torproject.org-keyring

Package deb.torproject.org-keyring installs Release key in:
/etc/apt/trusted.gpg.d/deb.torproject.org-keyring.gpg
/usr/share/keyrings/deb.torproject.org-keyring.gpg

It could be that Peter has the "release key" and extended it.
And the FTP owner has the “repository key”.

···

On Dienstag, 16. Juli 2024 14:15:01 CEST Toralf Förster via tor-relays wrote:

On 7/16/24 14:03, boldsuck wrote:
> wget
> -qO-https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8
> CBC9E886DDD89.asc | gpg --dearmor | tee
> /usr/share/keyrings/tor-archive-keyring.gpg >/dev/null
Is the name important?

I'm asking b/c Ansible [1] seems to use "deb.torproject.org-keyring.gpg"
as the file name.

[1]
https://github.com/toralf/tor-relays/blob/main/playbooks/roles/setup_tor/tas
ks/tor-debian.yaml#L4 --
Toralf

--
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

rhatto · July 17, 2024, 4:43pm

>> wget -qO-https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --dearmor | tee /usr/share/keyrings/tor-archive-keyring.gpg >/dev/null
>
> Is the name important?

I assume it's Debian? The onfiguration of the signing key and the repo is configured in Debian (and Ubuntu?) via source.list, see $man 5 sources.list.

In most cases this will look something like this:
$ cat /etc/apt/sources.list.d/tor.list

deb [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg] Index of /torproject.org bookworm main
deb-src [signed-by=/etc/apt/trusted.gpg.d/tor-archive-keyring.gpg] Index of /torproject.org bookworm main

You can place the key anywhere that ‘apt’ can access, you only need to change the path in the source file.

I would recommend placing it at /usr/share/keyrings/deb.torproject.org-keyring.gpg,
but only if you don't have the deb.torproject.org-keyring package already installed:

1. On a fresh system, manually download the key to
/usr/share/keyrings/deb.torproject.org-keyring.gpg.

2. Then configure sources.list, install apt-transport-https etc.

3. Finally, install the deb.torproject.org-keyring package.
It will overwrite /usr/share/keyrings/deb.torproject.org-keyring.gpg
with the version from the package.

Afterwards, you won't have to manually update the key once a new version
is available: it will be upgraded whenever a new
deb.torproject.org-keyring package version is installed.

I have created a merge request to update the documentation in order to
recommend this: https://gitlab.torproject.org/tpo/web/support/-/merge_requests/220

Note, however, that for keys that are not managed by a package or the package manager itself, they should be stored either in /usr/share/keyrings or /etc/apt/keyrings.

however, you can also overwrite the existing key. I'm not a fan of this and still keep all (old) versions in the keyring..

Since you are all tinkering with your servers anyway, why don't you try deb822-style

$ cat /etc/apt/sources.list.d/tor.sources

Types: deb deb-src
URIs: tor+http://apow7mjfryruh65chtdydfmqfpj5btws7nbocgtaovhvezgccyjazpqd.onion/torproject.org
URIs: Index of /torproject.org
Suites: bookworm
Components: main
Architectures: amd64
Signed-By: /etc/apt/keyrings/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.gpg

Interesting

···

On Tue, Jul 16, 2024 at 05:01:09PM +0300, Martin Gebhardt via tor-relays wrote:

--
Silvio Rhatto
pronouns he/him

lists · July 21, 2024, 11:53am

Because that doesn't make sense for public Tor nodes, but rather for .onion
services.
Many ISPs and providers have a Debian and Tor mirror and I use them via
clearnet because reliability for security updates is important to me.

···

On Dienstag, 16. Juli 2024 16:01:09 CEST Martin Gebhardt via tor-relays wrote:

Since you are all tinkering with your servers anyway, why don't you try
deb822-style

--
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

lists · July 21, 2024, 1:25pm

2. Then configure sources.list, install apt-transport-https etc.

This is no longer necessary since several Debian releases:
apt-transport-https is just a dummy,
HTTPS has been moved to the apt package since version 1.5.

Afterwards, you won't have to manually update the key once a new version
is available: it will be upgraded whenever a new
deb.torproject.org-keyring package version is installed.

"The same procedure as every year, James!"

The repository key must be renewed manually every 2 years.
The rest is done by deb.torproject.org-keyring package

···

On Mittwoch, 17. Juli 2024 18:43:46 CEST rhatto wrote:

--
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

lists · July 25, 2024, 12:55am

What was the previous key for reminder?

The same

This looks like exactly the one I installed BEFORE all your messages
mentioning the requirement to update... manually.

Of course, it is the same key as before. When creating PGP keys, an expiration
date is defined by default. The Repo PGP key is always valid for 2 years and
the expiry date has been extended for the next 2 years.

I have a problem in that I like to remove ssh before I leave my
installations, to be conscious.

What do you mean exactly? 'exit', and you are logged out.

I would have to re-install yet I am pretty sure my key was also 89-ending.

QUESTION:

is there any one / way to tell whether my relays have the proper key
from any metrics / torproject admin / version showing up?

apt update gives error message that key has expired.

apt-key -list
/etc/apt/trusted.gpg.d/deb.torproject.org-keyring.gpg

···

On Donnerstag, 25. Juli 2024 01:29:41 CEST you wrote:
-----------------------------------------------------
pub rsa2048 2009-09-04 [SC] [expires: 2028-08-29]
A3C4 F0F9 79CA A22C DBA8 F512 EE8C BC9E 886D DD89
uid [ unknown] deb.torproject.org archive signing key
sub rsa2048 2009-09-04 [S] [expires: 2026-09-09]

--
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

lists · July 25, 2024, 11:38am

Sorry,
above is the key that is installed by the package deb.torproject.org-keyring.

gpg --show-keys /usr/share/keyrings/tor-archive-keyring.gpg
shows you the one imported via wget.

···

On Donnerstag, 25. Juli 2024 02:55:12 CEST boldsuck wrote:

> QUESTION:
>
> is there any one / way to tell whether my relays have the proper key
> from any metrics / torproject admin / version showing up?

apt update gives error message that key has expired.

apt-key -list
/etc/apt/trusted.gpg.d/deb.torproject.org-keyring.gpg
-----------------------------------------------------
pub rsa2048 2009-09-04 [SC] [expires: 2028-08-29]
A3C4 F0F9 79CA A22C DBA8 F512 EE8C BC9E 886D DD89
uid [ unknown] deb.torproject.org archive signing key
sub rsa2048 2009-09-04 [S] [expires: 2026-09-09]

--
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

lists · August 2, 2024, 2:03am

>> Since you are all tinkering with your servers anyway, why don't you try
>> deb822-style
>
> Because that doesn't make sense for public Tor nodes, but rather for
> .onion
> services.
> Many ISPs and providers have a Debian and Tor mirror and I use them via
> clearnet because reliability for security updates is important to me.

ok, you are probably referring to the fact that i use the repo via .onion.
But i actually wanted to point out the format of the APT source files, see
sources.list(5) — apt — Debian unstable — Debian Manpages
E_FORMAT

Aah.
Ooh, thanks. Interesting. I didn't know that. Must be new or I missed it in
the release notes.

And regardless of that: In my opinion, it makes perfect sense to also obtain
public services such as OS updates via Tor. The more data flying around the
Tor network, the better it is for the Tor network.

With 100 Tor instances and 20G for Tor traffic, the daily repo delta gives me
almost zero
On the other hand, we are currently building a hidden service exchange. Damn,
the Tor network is overloaded with DoS attacks, so I try to avoid any traffic.

···

On Freitag, 2. August 2024 02:10:21 CEST Martin Gebhardt via tor-relays wrote:

--
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

telekobold · August 2, 2024, 3:16pm

Hi boldsuck,

thank you for your messages and the explanations. To be honest, I wasn't aware that the GPG key has to be updated manually every two years. However, I still have a few comprehension questions:

wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --dearmor | tee /usr/share/keyrings/tor-archive-keyring.gpg >/dev/null

What exactly is the purpose of "gpg --dearmor" and of "tee" here? Why isn't is enough to just type
wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc > /usr/share/keyrings/tor-archive-keyring.gpg
?
I compared the output with and without the "gpg --dearmor" using diff, it is exactly the same. And the only effect of tee is that the binary output is also printed to the terminal. There is even something that is interpreted as a line break at the end of the binary .gpg file so that the terminal tries to execute "1;2c" which leads to an error. However, with the shortened command, everything also works without errors.

>> apt-key -list /etc/apt/trusted.gpg.d/deb.torproject.org-keyring.gpg
[...]
> Sorry, above is the key that is installed by the package deb.torproject.org-keyring.
> gpg --show-keys /usr/share/keyrings/tor-archive-keyring.gpg shows you the one imported via wget.

On my relays (installed "the standard way" using the manuals at the torproject.org website), both commands output the same GPG key with the fingerprint
A3C4 F0F9 79CA A22C DBA8 F512 EE8C BC9E 886D DD89
So, there seems to be no other Tor-related GPG key installed by the package deb.torproject.org-keyring, just the GPG key manually installed via the above wget command.

And finally, it would be nice if one could check the fingerprint of this key on future physical Tor relay operators meetups like the one at the Chaos Communication Camp. I'm not even sure if wget does any background check based on a hierarchical certificate check of the TLS certificate of torproject.org. If the TLS connection would be somehow corrupted at the moment where one executed the wget command an attacker could corrupt the whole relay, according to my understanding. Or do I have an error in my thinking here?

Kind regards
telekobold

···

On 16.07.24 14:03, boldsuck wrote:
_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

eff_03675549 · August 11, 2024, 12:06pm

Hi all,

wait: I just installed a fresh relay and the torproject is still outdated with the old keyring!
(I had to add sudo apt-key adv --recv-keys --keyserver keys.gnupg.net 74A941BA219EC810 to my script).

Isn’t this insane given that new comers are going to install vulnerable relays by default?

how come the new installs still have to update?

Carlos.

···

On 8/2/24 5:16 PM, telekobold wrote:

Hi boldsuck,

thank you for your messages and the explanations. To be honest, I wasn’t aware that the GPG key has to be updated manually every two years. However, I still have a few comprehension questions:

On 16.07.24 14:03, boldsuck wrote:

wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --dearmor | tee /usr/share/keyrings/tor-archive-keyring.gpg >/dev/null

What exactly is the purpose of “gpg --dearmor” and of “tee” here? Why isn’t is enough to just type
wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc > /usr/share/keyrings/tor-archive-keyring.gpg
?
I compared the output with and without the “gpg --dearmor” using diff, it is exactly the same. And the only effect of tee is that the binary output is also printed to the terminal. There is even something that is interpreted as a line break at the end of the binary .gpg file so that the terminal tries to execute “1;2c” which leads to an error. However, with the shortened command, everything also works without errors.

apt-key -list /etc/apt/trusted.gpg.d/deb.torproject.org-keyring.gpg
[…]
Sorry, above is the key that is installed by the package deb.torproject.org-keyring.
gpg --show-keys /usr/share/keyrings/tor-archive-keyring.gpg shows you the one imported via wget.

On my relays (installed “the standard way” using the manuals at the torproject.org website), both commands output the same GPG key with the fingerprint
A3C4 F0F9 79CA A22C DBA8 F512 EE8C BC9E 886D DD89
So, there seems to be no other Tor-related GPG key installed by the package deb.torproject.org-keyring, just the GPG key manually installed via the above wget command.

And finally, it would be nice if one could check the fingerprint of this key on future physical Tor relay operators meetups like the one at the Chaos Communication Camp. I’m not even sure if wget does any background check based on a hierarchical certificate check of the TLS certificate of torproject.org. If the TLS connection would be somehow corrupted at the moment where one executed the wget command an attacker could corrupt the whole relay, according to my understanding. Or do I have an error in my thinking here?

Kind regards
telekobold

tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

-- 
PGP updated every second week : please actualize our communication every time.

eff_03675549 · August 11, 2024, 1:20pm

OK, I code-solved my own misery :

This change is an improvement YET really the subtle minor 3-lettered increment is UNobvious to people like I:

BE VERY CAUTIOUS of the * D.E.B * novelty in the tor.list file:

echo ‘deb [signed-by=/usr/share/keyrings/deb.tor-archive-keyring.gpg] https://deb.torproject.org/torproject.org main’ >> …/…/etc/apt/sources.list.d/tor.list
echo ‘deb-src [signed-by=/usr/share/keyrings/deb.tor-archive-keyring.gpg] https://deb.torproject.org/torproject.org main’ >> …/…/etc/apt/sources.list.d/tor.list

…below…above…above…below
and associated command:
wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --dearmor | sudo tee /usr/share/keyrings/deb.tor-archive-keyring.gpg >/dev/null

sooo, unbovious.

Question is: how many relays are now running an out-dated gpg keyring?

Carlos.

···

On 8/11/24 2:06 PM, eff_03675549@posteo.se wrote:

Hi all,

wait: I just installed a fresh relay and the torproject is still outdated with the old keyring!
(I had to add sudo apt-key adv --recv-keys --keyserver keys.gnupg.net 74A941BA219EC810 to my script).

Isn’t this insane given that new comers are going to install vulnerable relays by default?

how come the new installs still have to update?

Carlos.

-- 
PGP updated every second week : please actualize our communication every time.

On 8/2/24 5:16 PM, telekobold wrote:

Hi boldsuck,

thank you for your messages and the explanations. To be honest, I wasn’t aware that the GPG key has to be updated manually every two years. However, I still have a few comprehension questions:

On 16.07.24 14:03, boldsuck wrote:

wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --dearmor | tee /usr/share/keyrings/tor-archive-keyring.gpg >/dev/null

What exactly is the purpose of “gpg --dearmor” and of “tee” here? Why isn’t is enough to just type
wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc > /usr/share/keyrings/tor-archive-keyring.gpg
?
I compared the output with and without the “gpg --dearmor” using diff, it is exactly the same. And the only effect of tee is that the binary output is also printed to the terminal. There is even something that is interpreted as a line break at the end of the binary .gpg file so that the terminal tries to execute “1;2c” which leads to an error. However, with the shortened command, everything also works without errors.

apt-key -list /etc/apt/trusted.gpg.d/deb.torproject.org-keyring.gpg
[…]
Sorry, above is the key that is installed by the package deb.torproject.org-keyring.
gpg --show-keys /usr/share/keyrings/tor-archive-keyring.gpg shows you the one imported via wget.

On my relays (installed “the standard way” using the manuals at the torproject.org website), both commands output the same GPG key with the fingerprint
A3C4 F0F9 79CA A22C DBA8 F512 EE8C BC9E 886D DD89
So, there seems to be no other Tor-related GPG key installed by the package deb.torproject.org-keyring, just the GPG key manually installed via the above wget command.

And finally, it would be nice if one could check the fingerprint of this key on future physical Tor relay operators meetups like the one at the Chaos Communication Camp. I’m not even sure if wget does any background check based on a hierarchical certificate check of the TLS certificate of torproject.org. If the TLS connection would be somehow corrupted at the moment where one executed the wget command an attacker could corrupt the whole relay, according to my understanding. Or do I have an error in my thinking here?

Kind regards
telekobold

tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

-- 
PGP updated every second week : please actualize our communication every time.

lists · August 14, 2024, 2:13pm

I don't see any problem:
If you do 'apt upgrade' via commandline, you will get an ERROR output.
If you have 'unattended upgrades' enabled, you will get an ERROR email.

Question is:
Why are there so many relays, some with over a year of uptime? They have not
experienced any OS, kernel or tor security upgrades for a long time.

···

On Sonntag, 11. August 2024 15:20:01 CEST eff_03675549@posteo.se wrote:

Question is: how many relays are now running an out-dated gpg keyring?

--
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

lists · August 14, 2024, 5:44pm

That's clear. But without mailout I don't even know whether unattended
upgrades are running or not. And that I have to reboot because of the kernel
upgrade or similar. (I don't like auto reboots)
Who runs a server in the data center without getting raid-, smart-, log-,
whatever emails?

If for some reason you do not receive any mails from OS and IPMI, I can
recommend subscribing to:
tor-announce@lists.torproject.org
announce@your.os.whatever
security-announce@your.os.whatever

and do updates manually.

PS:
Thanks, your Grafana pics on github inspired me to use prometheus

···

On Mittwoch, 14. August 2024 18:20:43 CEST Toralf Förster via tor-relays wrote:

On 8/14/24 16:13, boldsuck wrote:
> If you have 'unattended upgrades' enabled, you will get an ERROR email.

Highly depends on a configured mailer IMO.

--
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

pollo · August 14, 2024, 5:59pm

I do run unattended upgrades on my servers and I find `needrestart` is a pretty nice tool to know when a machine has to be rebooted.

`needrestart -p` provides a standard output that can be imported in different monitoring systems (I use icinga2) and most of them can also do alerting.

If you're planning to go the prometheus way, it does support alerting too:

···

On 2024-08-14 1 h 44 p.m., boldsuck wrote:

On Mittwoch, 14. August 2024 18:20:43 CEST Toralf Förster via tor-relays > wrote:

On 8/14/24 16:13, boldsuck wrote:

If you have 'unattended upgrades' enabled, you will get an ERROR email.

Highly depends on a configured mailer IMO.

That's clear. But without mailout I don't even know whether unattended
upgrades are running or not. And that I have to reboot because of the kernel
upgrade or similar. (I don't like auto reboots)
Who runs a server in the data center without getting raid-, smart-, log-,
whatever emails?

--
   ⢀⣴⠾⠻⢶⣦⠀
   ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau
   ⢿⡄⠘⠷⠚⠋ pollo@debian.org / veronneau.org
   ⠈⠳⣄

eff_03675549 · August 14, 2024, 8:44pm

Hi all and cheers for all your replies.

···

On 8/14/24 9:07 PM, Toralf Förster via tor-relays wrote:

On 8/14/24 19:44, boldsuck wrote:

upgrades are running or not. And that I have to reboot because of the kernel
upgrade or similar. (I don’t like auto reboots)

Ah, ok.
I like it and have therefore unattended upgrade configured
unconditionally for all packages [1].

Furthermore I do use needrestart to detect services and/or kernel
requiring a reboot and do it [2].

So it works all out of the box w/o manual intervention here.

[1]
https://github.com/toralf/tor-relays/blob/main/playbooks/roles/setup_common/tasks/auto-update.yaml
[2]
https://github.com/toralf/tor-relays/blob/main/playbooks/roles/setup_common/tasks/reboot.yaml

–
Toralf

tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

--