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/A3C4F0F979CAA22CDBA8F512EE8CBC9E88... | gpg --dearmor | tee /usr/share/keyrings/tor-archive-keyring.gpg >/dev/null
More Info: https://support.torproject.org/apt/tor-deb-repo/
On 7/16/24 14:03, boldsuck wrote:
wget -qO-https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E88... | 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... -- Toralf
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
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”.
Hi,
wget -qO-https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E88... | 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] https://deb.torproject.org/torproject.org bookworm main deb-src [signed-by=/etc/apt/trusted.gpg.d/tor-archive-keyring.gpg] https://deb.torproject.org/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.
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/torpro... URIs: https://deb.torproject.org/torproject.org Suites: bookworm Components: main Architectures: amd64 Signed-By: /etc/apt/keyrings/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.gpg
Ahoy, Martin
On Tue, Jul 16, 2024 at 05:01:09PM +0300, Martin Gebhardt via tor-relays wrote:
wget -qO-https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E88... | 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] https://deb.torproject.org/torproject.org bookworm main deb-src [signed-by=/etc/apt/trusted.gpg.d/tor-archive-keyring.gpg] https://deb.torproject.org/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/torpro... URIs: https://deb.torproject.org/torproject.org Suites: bookworm Components: main Architectures: amd64 Signed-By: /etc/apt/keyrings/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.gpg
Interesting :)
On Mittwoch, 17. Juli 2024 18:43:46 CEST rhatto wrote:
- 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. https://packages.debian.org/en/bookworm/apt-transport-https
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 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 ;-)
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.
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 https://manpages.debian.org/unstable/apt/sources.list.5.en.html#DEB822-STYLE... :-)
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.
Ahoy, Martin
On Freitag, 2. August 2024 02:10:21 CEST Martin Gebhardt via tor-relays wrote:
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 https://manpages.debian.org/unstable/apt/sources.list.5.en.html#DEB822-STYL 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.
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/A3C4F0F979CAA22CDBA8F512EE8CBC9E88... | 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/A3C4F0F979CAA22CDBA8F512EE8CBC9E88...
/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
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/A3C4F0F979CAA22CDBA8F512EE8CBC9E88... | 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/A3C4F0F979CAA22CDBA8F512EE8CBC9E88...
/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
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 <DISTRIBUTION> 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 <DISTRIBUTION> main' >> ../../etc/apt/sources.list.d/tor.list
................................below...................................above.....................................................above.......................................................................................................................below and associated command: wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E88... | 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.
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/A3C4F0F979CAA22CDBA8F512EE8CBC9E88... | 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/A3C4F0F979CAA22CDBA8F512EE8CBC9E88...
/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.
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?
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 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?
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 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?
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:
https://prometheus.io/docs/alerting/latest/alertmanager/
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/... [2] https://github.com/toralf/tor-relays/blob/main/playbooks/roles/setup_common/...
-- Toralf
I just typed up a huge reply and it did not get saved for some reason.
Okay, let's do it this way then:
1.) I don't think we need to re-invent the wheel, (q)Tox can be used over Tor, that is likely one of the messengers you mentioned. 2.) I am currently not receiving the medication I really need for adult ADD (Lisdexamphetamine), so my attention span is very short. 3.) I'd rather be honest and tell you now that I am not particularly interested in your project, except for sending useless answers.
I have one good doctor specialized on ADD near me, but I keep forgetting to make an appointment, but until after my mental illness problems are not solved, I will not be able to fully commit to any task long term.
So, if you want to ask me questions about Tor operations, especially regarding Guard/Exit nodes, and hidden services, I will help to my best extent.
If you want to get into the nitty gritty side of things, the source code repository and this site: https://spec.torproject.org are probably your best bet.
I am tired, and it's getting late in Europe.
However, I sincerely do hope that you find someone that has the will to help you with your project, no matter how it's going to end up.
Greetings, George
On Wednesday, August 14th, 2024 at 9:07 PM, Toralf Förster via tor-relays tor-relays@lists.torproject.org 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/... [2] https://github.com/toralf/tor-relays/blob/main/playbooks/roles/setup_common/...
-- Toralf
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays@lists.torproject.org
-
boldsuck -
eff_03675549＠posteo.se -
George Hartley -
Louis-Philippe Véronneau -
Martin Gebhardt -
Martin Gebhardt
-
rhatto -
telekobold -
Toralf Förster