TPA issueshttps://gitlab.torproject.org/groups/tpo/tpa/-/issues2021-10-29T13:13:54Zhttps://gitlab.torproject.org/tpo/tpa/dangerzone-webdav-processor/-/issues/11consider using upstream dangerzone code2021-10-29T13:13:54Zanarcatconsider using upstream dangerzone codewe have our own Docker runner code, but upstream has been working on a commandline version which we might be able to leverage, see https://github.com/firstlookmedia/dangerzone/pull/116
review the pull request, provide feedback to upstre...we have our own Docker runner code, but upstream has been working on a commandline version which we might be able to leverage, see https://github.com/firstlookmedia/dangerzone/pull/116
review the pull request, provide feedback to upstream on how it would be compatible with us, and consider repackaging with upstream as a dep.https://gitlab.torproject.org/tpo/tpa/team/-/issues/41303convert Puppet's cron resources into systemd timers2023-08-25T15:05:58Zanarcatconvert Puppet's cron resources into systemd timersPuppet's built-in cron resource is kind of crap:
1. if you first set a parameter like `hour` and then remove it, it doesn't turn it into `*`, e.g. if you have `cron { 'foo': hour => 5 }` and turn that into `cron { 'foo': }`, that's a n...Puppet's built-in cron resource is kind of crap:
1. if you first set a parameter like `hour` and then remove it, it doesn't turn it into `*`, e.g. if you have `cron { 'foo': hour => 5 }` and turn that into `cron { 'foo': }`, that's a noop but should logically turn it into a job that runs every minute
2. if you add a resource to a manifest, then remove it, it doesn't get removed from the host, e.g. if you remove the `Cron['foo']` resource above, it will stay in the crontab
3. it uses the `/var/spool/crontabs/root` resource instead of the more readable and intelligible `/etc/cron.d`
4. it was removed from core puppet and moved to a contrib module (see the [deprecation notice](https://www.puppet.com/docs/puppet/6/release_notes_puppet#new_features_puppet_x-0-0-select-moved-modules-types) and tpo/tpa/team#41285))
There are two options here.
1. voxpupuli maintains what seems to look like an [excellent cron module](https://github.com/voxpupuli/puppet-cron)
2. just ditch cron and turn everything into a systemd timer (that is [what wikimedia did](https://phabricator.wikimedia.org/T273673))
The former is easier: the [`cron::job`](https://github.com/voxpupuli/puppet-cron#cronjob) resource looks backwards compatible with the old `cron` type, except that it creates the resource in `/etc/cron.d` instead of `/var/...`
But I would very much like to use systemd timers instead: they provide built-in monitoring as failing timers will raise an alarm with systemd's internal status, which then triggers monitoring (as opposed to sending us email). It could also drastically reduce the amount of noise we're going through each morning, although *that* might be a problem if we actually rely on that output. We probably would need to go through each resource by hand to evaluate anyways.
Wikimedia has this trick to list hosts with the given resource:
```
cumin R:cron
```
Obviously, all hosts currently have a cron resource. But it's not as much work as I'd imagined:
```
puppetdb=# SELECT count(*),title FROM catalog_resources WHERE type = 'Cron' GROUP BY title ORDER by count(*) DESC;
count | title
-------+---------------------------------
87 | puppet-cleanup-clientbucket
81 | prometheus-lvm-prom-collector-
9 | prometheus-postfix-queues
6 | docker-clear-old-images
5 | docker-clear-nightly-images
5 | docker-clear-cache
5 | docker-clear-dangling-images
2 | collector-service
2 | onionoo-bin
2 | onionoo-network
2 | onionoo-service
2 | onionoo-web
2 | podman-clear-cache
2 | podman-clear-dangling-images
2 | podman-clear-nightly-images
2 | podman-clear-old-images
1 | update rt-spam-blocklist hourly
1 | update torexits for apache
1 | metrics-web-service
1 | metrics-web-data
1 | metrics-web-start
1 | metrics-web-start-rserve
1 | metrics-network-data
1 | rt-externalize-attachments
1 | tordnsel-data
1 | tpo-gitlab-backup
1 | tpo-gitlab-registry-gc
1 | update KAM ruleset
(28 rows)
```
that's 28 distinct resources to update, and many of them are basically the same (e.g. all the `podman` stuff is similar). some already *must* be moved out of cron to be ran as normal services (e.g. metrics stuff).
i doubt we need the output in *any* of those and it would logged in journald anyway. in fact, it might even allow us log *more* things as we wouldn't have to deal with the resulting email...cleanup and publish the sysadmin codebasehttps://gitlab.torproject.org/tpo/tpa/dangerzone-webdav-processor/-/issues/14crashes in the container leave files in `processing`2022-11-02T14:46:34Zanarcatcrashes in the container leave files in `processing`so this is happening:
```
Jun 11 17:00:01 dangerzone-01 dangerzone-webdav-processor[19331]: authenticated with webdav https://nc.torproject.net/remote.php/dav/files/dangerzone-bot/
Jun 11 17:00:06 dangerzone-01 dangerzone-webdav-process...so this is happening:
```
Jun 11 17:00:01 dangerzone-01 dangerzone-webdav-processor[19331]: authenticated with webdav https://nc.torproject.net/remote.php/dav/files/dangerzone-bot/
Jun 11 17:00:06 dangerzone-01 dangerzone-webdav-processor[19331]: sanitizing CVS/ 15/
Jun 11 17:00:06 dangerzone-01 dangerzone-webdav-processor[19331]: moving 15/ to CVS//dangerzone/processing/15/ before dangerzone/processing
Jun 11 17:00:08 dangerzone-01 dangerzone-webdav-processor[19331]: downloading CVS//dangerzone/processing/15/ to /tmp/tmp4te3htlj/danger/15/
Jun 11 17:00:15 dangerzone-01 dangerzone-webdav-processor[19331]: processing 3 files in dir /tmp/tmp4te3htlj/danger/15 to safe_dir: /tmp/tmpjpzjdnxc/safe//15
Jun 11 17:00:15 dangerzone-01 dangerzone-webdav-processor[19331]: sanitizing file /tmp/tmp4te3htlj/danger/15/nolanresume_fr.pdf into /tmp/tmpjpzjdnxc/safe//15
Jun 11 17:00:15 dangerzone-01 dangerzone-webdav-processor[19331]: the input device is not a TTY
Jun 11 17:00:15 dangerzone-01 dangerzone-webdav-processor[19331]: failed to run docker command: ['docker', 'run', '-it', '--cidfile=/tmp/tmpxux5tbee/cidfile', '--volum
Jun 11 17:00:15 dangerzone-01 dangerzone-webdav-processor[19331]: Traceback (most recent call last):
Jun 11 17:00:15 dangerzone-01 dangerzone-webdav-processor[19331]: File "/usr/bin/dangerzone-webdav-processor", line 469, in <module>
Jun 11 17:00:15 dangerzone-01 dangerzone-webdav-processor[19331]: main()
Jun 11 17:00:15 dangerzone-01 dangerzone-webdav-processor[19331]: File "/usr/bin/dangerzone-webdav-processor", line 336, in main
Jun 11 17:00:15 dangerzone-01 dangerzone-webdav-processor[19331]: client.process_path(folder, path)
Jun 11 17:00:15 dangerzone-01 dangerzone-webdav-processor[19331]: File "/usr/bin/dangerzone-webdav-processor", line 395, in process_path
Jun 11 17:00:15 dangerzone-01 dangerzone-webdav-processor[19331]: self.sanitizer.sanitize_dir(local_path)
Jun 11 17:00:15 dangerzone-01 dangerzone-webdav-processor[19331]: File "/usr/bin/dangerzone-webdav-processor", line 136, in sanitize_dir
Jun 11 17:00:15 dangerzone-01 dangerzone-webdav-processor[19331]: self.sanitize_file(os.path.join(root, file), safe_dir=safe_dir)
Jun 11 17:00:15 dangerzone-01 dangerzone-webdav-processor[19331]: File "/usr/bin/dangerzone-webdav-processor", line 145, in sanitize_file
Jun 11 17:00:15 dangerzone-01 dangerzone-webdav-processor[19331]: args=["document-to-pixels-unpriv"],
Jun 11 17:00:15 dangerzone-01 dangerzone-webdav-processor[19331]: File "/usr/bin/dangerzone-webdav-processor", line 258, in run
Jun 11 17:00:15 dangerzone-01 dangerzone-webdav-processor[19331]: with open(f"{tmpdir}/cidfile") as fp:
Jun 11 17:00:15 dangerzone-01 dangerzone-webdav-processor[19331]: FileNotFoundError: [Errno 2] No such file or directory: '/tmp/tmpxux5tbee/cidfile'
Jun 11 17:00:15 dangerzone-01 systemd[1]: dangerzone-webdav-processor.service: Main process exited, code=exited, status=1/FAILURE
```
the underlying bug (`the input device is not a TTY`) is bad enough without those files being stuck there in the first place...
to reproduce, run under systemd with `--tty`, which has been patched out in 39532430e14cbbf5a0dad4adf776bc63f19b8b23, or just branch off from the parent of that.https://gitlab.torproject.org/tpo/tpa/team/-/issues/29398Create a template for requesting infrastructure resources2024-02-20T16:16:07ZLinus Nordberglinus@torproject.orgCreate a template for requesting infrastructure resourcesPublish the template decided upon in the Brussels meeting and announce it internaly.
cf https://trac.torproject.org/projects/tor/wiki/org/meetings/2019BrusselsAdminTeamMinutes#Helpusersimprovewhenrequestingresources
templates to create...Publish the template decided upon in the Brussels meeting and announce it internaly.
cf https://trac.torproject.org/projects/tor/wiki/org/meetings/2019BrusselsAdminTeamMinutes#Helpusersimprovewhenrequestingresources
templates to create and specs
- [ ] OpenPGP key changes
- [ ] new VM / server, see https://gitlab.torproject.org/tpo/tpa/team/-/issues/29398#note_2801505 for spec, think about #40746 and #40578
- [ ] new account
- [ ] email alias changes
- [ ] account retirement
- [ ] static component changes (new / remove component)
- [ ] fallback "[default](https://docs.gitlab.com/ee/user/project/description_templates.html#set-a-default-template-for-merge-requests-and-issues)" template (AKA "describe your problem, service, etc")
when we talk about a "template", we mean an [issue template](https://docs.gitlab.com/ee/user/project/description_templates.html#create-an-issue-template) specifically. those need to be created by project, because group or instance-level templates are unfortunately non-free. But default templates work, see https://gitlab.torproject.org/tpo/tpa/wiki-replica/-/commit/bfd312ed61c6b6e992ae0ff46a60206dd25f591a for an example.
Templates live in `.gitlab/issue_templates` with the default named `Default.md`.
this also means we need to have some sort of repository here. i have tried to enable to repository but keep the wiki as the frontpage, but i have failed: i don't know if that's possible at all. this means that the tpo/tpa/team page would look like the wiki replica, basically:
https://gitlab.torproject.org/tpo/tpa/wiki-replica
... which kind of sucks, because there is no README.md file. one thing we could do would be to ditch the wiki completely and just rely on the builtin repository browser. which is not great.
alternatively, we could duplicate the `home.md` page into `README.md` so that we see the README in the TPA home page.
either way, if we want templates, we need a repo here, and it might make better sense to have the wiki replica. the question then is whether we can still have the hook system working there, but it should work, in theory. in practice that hasn't been tested, as far as I know.anarcatanarcathttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41387create an alert if a machine's network interface goes down2023-11-08T15:17:51ZKezcreate an alert if a machine's network interface goes downwe should crate some kind of big, scary, hard to miss alert when one of our machines has a network interface go down. a network interface going down could be a sign of an attack, hardware/software failure, misconfiguration, or other bad ...we should crate some kind of big, scary, hard to miss alert when one of our machines has a network interface go down. a network interface going down could be a sign of an attack, hardware/software failure, misconfiguration, or other bad things. this alert shouldn't disappear when the interface comes back up, and ideally TPA should be able to temporarily disable the alert for planned maintenance.https://gitlab.torproject.org/tpo/tpa/anon_ticket/-/issues/14Create Issue when in a specific project doesn't prepopulate form2021-05-03T13:40:43ZcypherpunksCreate Issue when in a specific project doesn't prepopulate formCurrently, the "Create issue" link on a project detail view links to the generic "create issue" view, and the user then needs to select the appropriate project from the dropdown. It would be nice to have it auto-select the dropdown objec...Currently, the "Create issue" link on a project detail view links to the generic "create issue" view, and the user then needs to select the appropriate project from the dropdown. It would be nice to have it auto-select the dropdown object for you.https://gitlab.torproject.org/tpo/tpa/team/-/issues/41538Create new email address for use with CiviCRM relationship management2024-03-25T16:59:30Zal smithCreate new email address for use with CiviCRM relationship managementHi TPA,
Fundraising + Mathieu need a new email address created for a function we're introducing in CiviCRM. (It will allow us to BCC an email address to automatically add a record of that email to an individual's records in CiviCRM. You...Hi TPA,
Fundraising + Mathieu need a new email address created for a function we're introducing in CiviCRM. (It will allow us to BCC an email address to automatically add a record of that email to an individual's records in CiviCRM. You can see the overarching ticket here: https://gitlab.torproject.org/tpo/web/civicrm/-/issues/112.)
I'm requesting `crm@torproject.org`.
Please let me know if there's anything I need to do to facilitate this. :) Thanks!Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.org2024-03-31https://gitlab.torproject.org/tpo/tpa/team/-/issues/40379Create onion service for GitLab Pages2023-10-12T10:51:48ZJérôme Charaouilavamind@torproject.orgCreate onion service for GitLab PagesThis might be possible to implement via the nginx reverse proxy, eg. by modifying the `Hosts:` header.This might be possible to implement via the nginx reverse proxy, eg. by modifying the `Hosts:` header.Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/tpa/anon_ticket/-/issues/60Current anonticket.onionize.space leak the identifier to URL, this is risk if...2024-02-12T18:37:46ZcypherpunksCurrent anonticket.onionize.space leak the identifier to URL, this is risk if user mistake create a bookmark.Ideally, the Anonymous Ticket Portal should similar to [secure drop](https://securedrop.org/), they avoid leak the identifier to URL and warn to user when user is not at Safest level.Ideally, the Anonymous Ticket Portal should similar to [secure drop](https://securedrop.org/), they avoid leak the identifier to URL and warn to user when user is not at Safest level.https://gitlab.torproject.org/tpo/tpa/dangerzone-webdav-processor/-/issues/21dangerzone-bot considered dangerous2023-09-21T20:43:38ZJérôme Charaouilavamind@torproject.orgdangerzone-bot considered dangerousAfter I finished working on #14, I realized that it may have only been by chance that `dangerzone-bot` has not gone into the Fundraising Team folder and wrecked havoc.
While troubleshooting the group access permissions on that folder, I...After I finished working on #14, I realized that it may have only been by chance that `dangerzone-bot` has not gone into the Fundraising Team folder and wrecked havoc.
While troubleshooting the group access permissions on that folder, I think there were a few short moments where the external storage was accessible to all NC users, including `dangerzone-bot`. If it has started processing files during that time, who knows what would have happened.
Currently, the Common folder in Nextcloud has a [special exemption](https://gitlab.torproject.org/tpo/tpa/dangerzone-webdav-processor/-/blob/main/dangerzone-webdav-processor#L314-L315) to work around this.
It would be good to address that risk, perhaps by somehow making `dangerzone-bot`-bot process incoming files on a opt-in basis, while keeping confidentiality requirements and the usage procedure as simple as possible.https://gitlab.torproject.org/tpo/tpa/team/-/issues/41448datacenter evacuation / replacement options2024-01-19T18:57:24Zanarcatdatacenter evacuation / replacement optionsFirst off, we are *not* currently planning to migrate, replace, or evacuate our presence at Hetzner or any other provider. That is a massive undertaking that we would not want to embark on without a significant cost/benefit analysis. The...First off, we are *not* currently planning to migrate, replace, or evacuate our presence at Hetzner or any other provider. That is a massive undertaking that we would not want to embark on without a significant cost/benefit analysis. The last time we evaluated this (#41374), we decided to stay.
That being said, it seems to me worthwhile to keep an eye out for other ... *opportunities* in hosting servers, specifically in Europe, but this could also include locations in Asia our south america. The point is to have diversity here.
Our [hardware requirements](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/doc/hardware-requirements) have been expanded to cover for hosting requirements found during the Cymru migration (#40897).
So this issue is to keep track of such ideas as they come up. Ideas should be documented as (possibly internal) comments(next) cluster scalinganarcatanarcathttps://gitlab.torproject.org/tpo/tpa/team/-/issues/27612dccbbv6cooddgcrq.onion (git.torproject.org) redirects to gitweb.torproject.org2022-04-07T16:18:05Ztraumschuledccbbv6cooddgcrq.onion (git.torproject.org) redirects to gitweb.torproject.orghttp://dccbbv6cooddgcrq.onion (git.torproject.org) redirects to https://gitweb.torproject.org/ instead of http://jqs44zhtxl2uo6gk.onion/http://dccbbv6cooddgcrq.onion (git.torproject.org) redirects to https://gitweb.torproject.org/ instead of http://jqs44zhtxl2uo6gk.onion/https://gitlab.torproject.org/tpo/tpa/team/-/issues/40987Deploy a new, sender-rewriting, mail exchanger2024-02-13T12:31:12ZanarcatDeploy a new, sender-rewriting, mail exchangerTPA-RFC-44 emergency procedures (#40981) was adopted, let's move on with the next step:
Configure new "mail exchanger" (MX) server(s) with TLS certificates
signed by a public CA, most likely Let's Encrypt for incoming mail,
replacing th...TPA-RFC-44 emergency procedures (#40981) was adopted, let's move on with the next step:
Configure new "mail exchanger" (MX) server(s) with TLS certificates
signed by a public CA, most likely Let's Encrypt for incoming mail,
replacing that part of `eugeni`.
This would take care of forwarding mail to other services
(e.g. mailing lists) but also end-users.
To work around reputation problems caused by SPF records (below),
deploy a [Sender Rewriting Scheme][] (SRS) with [postsrsd][]
(packaged in Debian) and [postforward][] (not packaged in Debian, but
zero-dependency Golang program).
[Sender Rewriting Scheme]: https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme
[postsrsd]: https://github.com/roehling/postsrsd
[postforward]: https://github.com/zoni/postforward
Having it on a separate mail exchanger will make it easier to swap in
and out of the infrastructure if problems would occur.
The mail exchangers should also sign outgoing mail with DKIM.improve mail servicesanarcatanarcathttps://gitlab.torproject.org/tpo/tpa/team/-/issues/31969deploy a puppet dashboard2023-11-23T21:08:17Zanarcatdeploy a puppet dashboardit would be useful to have a way to browse reports and facts in the cluster. there's a lot of information in the PuppetDB that's only visible when you inspect the database, and it would help to have a way to browse this and diagnose issu...it would be useful to have a way to browse reports and facts in the cluster. there's a lot of information in the PuppetDB that's only visible when you inspect the database, and it would help to have a way to browse this and diagnose issues with puppet.https://gitlab.torproject.org/tpo/tpa/team/-/issues/40861deploy dynamic environments on the Puppet server2024-03-26T15:14:06Zanarcatdeploy dynamic environments on the Puppet serverWe should be able to push to a new branch and have that be a specific environment that can be ran only on a subset of machines.
I've done something like this in my home lab: code in /etc/puppet/code/production is the default, but i can ...We should be able to push to a new branch and have that be a specific environment that can be ran only on a subset of machines.
I've done something like this in my home lab: code in /etc/puppet/code/production is the default, but i can make new ones (currently by hand) in /etc/puppet/code/BRANCHNAME. It's pretty useful to avoid "YOLO" commits that plague our history, but can also be used for more sensitive deployments.
This probably depends on first creating a role account (#29663) and goes along validation checks (#31226). It could probably be done without any of those though...Puppet CIJérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41484deploy fabric-tasks on install and keep up to date in puppet2024-03-27T14:40:01Zanarcatdeploy fabric-tasks on install and keep up to date in puppetall hosts should have a copy of fabric-tasks. there's many useful things in that repo, and we should keep expanding it to have more useful things.
it would skip a step in the install procedure, but it would also allow us to dump ad-hoc ...all hosts should have a copy of fabric-tasks. there's many useful things in that repo, and we should keep expanding it to have more useful things.
it would skip a step in the install procedure, but it would also allow us to dump ad-hoc scripts that we currently leave lying around in /root or elsewhere.
this is part of the automated install task (#31239).(next) cluster scalinganarcatanarcathttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40550deploy fail2ban on all services with password authentication2023-07-24T19:19:17Zanarcatdeploy fail2ban on all services with password authenticationany service using passwords for authentication should ban users attempting to bruteforce it.
consider that we have onion services and figure out how to thwart users there as well.
possible list:
* [x] db.tpo
* [ ] crm
* [ ] nextclo...any service using passwords for authentication should ban users attempting to bruteforce it.
consider that we have onion services and figure out how to thwart users there as well.
possible list:
* [x] db.tpo
* [ ] crm
* [ ] nextcloud
* [ ] forum
* [ ] prometheus/grafana?
* [ ] ... ? review the "Auth" column in the [service list](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/service/)
/cc @lavamindhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41415design and implement backup strategy for MinIO buckets or the entire server2024-01-19T18:57:23Zanarcatdesign and implement backup strategy for MinIO buckets or the entire serverWe're considering using MinIO for more and more things, mainly GitLab (artifacts storage in #41403 and gitaly backups in #40518) but possibly other (e.g. metrics storage in tpo/network-health/metrics/collector#40023).
Right now, we don'...We're considering using MinIO for more and more things, mainly GitLab (artifacts storage in #41403 and gitaly backups in #40518) but possibly other (e.g. metrics storage in tpo/network-health/metrics/collector#40023).
Right now, we don't have any backups of that server, which is probably fine: we only store container images there, which can be regenerated in case of a catastrophe. But if we start storing gitaly backups and gitlab artifacts, it needs to be permanent now.
Research how backups can be performed, develop a policy and implement it.
Next steps:
* [x] research articles anarcat found on the topic (see wallabag)
* [x] discuss the idea in the network
* [x] decide if we want this per bucket or per site
* [ ] write up a proposal
* [ ] implement proposal
* [ ] document and test backup/restore proceduresanarcatanarcathttps://gitlab.torproject.org/tpo/tpa/anon_ticket/-/issues/28Disable GitLab auto-reconnect looking for new comments on issue pages2021-09-08T18:51:25ZcypherpunksDisable GitLab auto-reconnect looking for new comments on issue pagesI, an anon-ticket cypherpunk, was on `safer` level in Tor Browser and visited a ticket on this GitLab. I changed to `safest` level, and a red floating box popped up on the page with the text, "Something went wrong while fetching latest c...I, an anon-ticket cypherpunk, was on `safer` level in Tor Browser and visited a ticket on this GitLab. I changed to `safest` level, and a red floating box popped up on the page with the text, "Something went wrong while fetching latest comments." The outermost HTML tag contained:
`div class="flash-container flash-container-page sticky" data-qa-selector="flash_container"`
A privacy-preserving GitLab should not auto-reconnect nor auto-refresh. A tab left open would periodically create new Tor circuits that could be analyzed to locate the browser.
Cypherpunks don't have permission to create this issue in tpa/gitlab, but I think that's where this issue is supposed to be.https://gitlab.torproject.org/tpo/tpa/team/-/issues/40651Disable SSLSessionTickets in Apache22022-04-06T20:57:59ZJérôme Charaouilavamind@torproject.orgDisable SSLSessionTickets in Apache2Mozilla's server-side TLS [guidelines](https://ssl-config.mozilla.org/#server=apache&version=2.4.41&config=intermediate&openssl=1.1.1k&guideline=5.6) suggest setting `SSLSessionTickets off` (default is `on`) in Apache2 because session ke...Mozilla's server-side TLS [guidelines](https://ssl-config.mozilla.org/#server=apache&version=2.4.41&config=intermediate&openssl=1.1.1k&guideline=5.6) suggest setting `SSLSessionTickets off` (default is `on`) in Apache2 because session key rotation isn't [handled properly](https://github.com/mozilla/server-side-tls/issues/135) and [weakens](https://timtaubert.de/blog/2017/02/the-future-of-session-resumption/) security properties of TLS connections.
There's a small performance cost, but we'd only pay it for TLS <=1.2 connections, since TLS 1.3 did away with TLS session tickets altogether.Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.org