TPA issueshttps://gitlab.torproject.org/groups/tpo/tpa/-/issues2024-03-21T15:12:23Zhttps://gitlab.torproject.org/tpo/tpa/anon_ticket/-/issues/61Internal Server Error (500) when attempting to access a ticket2024-03-21T15:12:23ZcypherpunksInternal Server Error (500) when attempting to access a ticketWhen I attempt to access a ticket, I become redirected to a empty page with a plan text:
"Error 500 Internal Server Error"
in the top left page cornerWhen I attempt to access a ticket, I become redirected to a empty page with a plan text:
"Error 500 Internal Server Error"
in the top left page cornerAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41044investigate a tiered approach to gitlab CI runners2024-02-20T16:09:04Zanarcatinvestigate a tiered approach to gitlab CI runnersWe've had multiple cases of users abusing our runners (e.g. https://gitlab.torproject.org/tpo/tpa/team/-/issues/41032) which wouldn't be *that* bad if it wasn't blocking production for our users.
At the Wikimedia foundation, they use a ...We've had multiple cases of users abusing our runners (e.g. https://gitlab.torproject.org/tpo/tpa/team/-/issues/41032) which wouldn't be *that* bad if it wasn't blocking production for our users.
At the Wikimedia foundation, they use a tiered approach to managing their fleeet of runners:
https://wikitech.wikimedia.org/wiki/GitLab/Gitlab_Runner/Security_Evaluation
Analyze this approach and see if it's something we'd want to adopt, and how. This might mean deploying more runners or having a call out for the community to provide some.
Consider that teams are likely to need much more resources in large runners, as the applications team is likely to start using CI as well in the future.
Also consider that some teams will need some reliance on the integrity of the build process for some runners, particularly TPA as we shift away from gitolite for our git hosting. Other teams might make release builds on GitLab as well.
/cc @lavamind @ahf @jnewsome @trinity-1686a @mikeperryanarcatanarcathttps://gitlab.torproject.org/tpo/tpa/team/-/issues/33062investigate kreb's advice on DNS hijacking2022-06-03T23:47:50Zanarcatinvestigate kreb's advice on DNS hijackingAfter reviewing [this article about recent DNS hijacking incidents](https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/), I think it might be worth reviewing the recommendations given in the ar...After reviewing [this article about recent DNS hijacking incidents](https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/), I think it might be worth reviewing the recommendations given in the article, which are basically:
1. [x] use DNSSEC
2. [ ] Use registration features like Registry Lock that can help protect domain names records from being changed
3. [ ] Use access control lists for applications, Internet traffic and monitoring
4. [ ] Use 2-factor authentication, and require it to be used by all relevant users and subcontractors
5. [x] In cases where passwords are used, pick unique passwords and consider password managers
6. [ ] Review accounts with registrars and other providers
7. [ ] Monitor certificates by monitoring, for example, Certificate Transparency Logs (#40677)
Some of those are impractical: for example 2FA will not work for us if we have one shared account with a provider.
Others have already been done: we have a good DNSSEC deployment and manage passwords properly.
Mainly, I'm curious about investigating Registry lock and CT logs monitoring, the latter which could be added as a Nagios thing, maybe.https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/98Investigate push-signing and transparency logs as mitigation for repository a...2024-03-27T15:21:35ZNick MathewsonInvestigate push-signing and transparency logs as mitigation for repository attacksFor background see:
* https://people.kernel.org/monsieuricon/signed-git-pushes
* https://korg.docs.kernel.org/gitolite/transparency-log.html
The idea here would be that some repositories (eg tor.git) could require signed _pushes_. Th...For background see:
* https://people.kernel.org/monsieuricon/signed-git-pushes
* https://korg.docs.kernel.org/gitolite/transparency-log.html
The idea here would be that some repositories (eg tor.git) could require signed _pushes_. Then we could archive these signed pushes in an append-only log, for auditing.
There are subproblems that would need to be solved for this to work:
* Only allow signed pushes on certain repositories (would require a per-repository gitolite hook).
* Allow signed pushes (requires setting certain options in gitconfig, see `certNonceSeed`, `certNonceSlop`, and `advertisePushOptions`)
* Make an append-only log of these signed pushes (possibly using trillian, possibly using some simpler transparency-log tool).
* Make a tool to audit this log and make sure that it's consistent and that it generates the current state of the repository.
* Decide what to do about key management.
And possibly:
* Make a tool that can be used at pull time to check the latest branch against the log.
There are also some sub-sub problems:
* Can we disable the merge button on target repositories?legacy Git infrastructure retirement (TPA-RFC-36)https://gitlab.torproject.org/tpo/tpa/team/-/issues/40993keep an inventory of installed software2022-12-21T12:07:45Zanarcatkeep an inventory of installed softwareWe should have an inventory of programs and software installed and managed by TPA (and service admins, ideally).
This was an issue in the handling of the log4j security issue (tpo/tpa/team#40551), as we didn't actually *know* where the...We should have an inventory of programs and software installed and managed by TPA (and service admins, ideally).
This was an issue in the handling of the log4j security issue (tpo/tpa/team#40551), as we didn't actually *know* where the software was installed. It was actually relatively easy to tell if we had the *debian package* installed everywhere (basically by running Cumin), but even that takes some time to run.
Ideally, we'd have a full inventory of all Debian packages, but also JARs, Python wheels, Ruby gems, and so on, installed everywhere, including dependencies, in one location, alongside version information. Container images are also probably something to take into account.
It's a hard problem, especially with our bespoke deployment systems, but one worth fixing. This should be part of our security policy (tpo/team#41).
Prior art:
* [debian upgrade procedures](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/upgrades/)
* upgrade automation (#31957)
* reboot automation (#33406)
* limoncelli test (#40944)https://gitlab.torproject.org/tpo/tpa/team/-/issues/29380Link to db.tpo from infrastructure page, for service expiration dates2022-05-03T17:45:36ZLinus Nordberglinus@torproject.orgLink to db.tpo from infrastructure page, for service expiration datesInformation about when a system expires will be present in LDAP.
Add appropriate links to db.tpo on https://trac.torproject.org/projects/tor/wiki/org/operations/Infrastructure, per service, making it easy to figure out when a service is...Information about when a system expires will be present in LDAP.
Add appropriate links to db.tpo on https://trac.torproject.org/projects/tor/wiki/org/operations/Infrastructure, per service, making it easy to figure out when a service is about to expire.https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/126Links to "Commented on issue" on GitLab user's activity use https on the onio...2022-08-29T20:38:20ZPier Angelo VendrameLinks to "Commented on issue" on GitLab user's activity use https on the onion serviceIf you go to GitLab user's activity from the onion service, the "Commented on issue #..." entries have a HTTPS URL instead of a HTTP one.
![Screenshot_from_2022-06-14_15-05-20](/uploads/40bc753ac596de727444b4c1030c5e96/Screenshot_from_2...If you go to GitLab user's activity from the onion service, the "Commented on issue #..." entries have a HTTPS URL instead of a HTTP one.
![Screenshot_from_2022-06-14_15-05-20](/uploads/40bc753ac596de727444b4c1030c5e96/Screenshot_from_2022-06-14_15-05-20.png)
All the other links seem to work.Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/tpa/gitlab-lobby/-/issues/14Lobby needs to limit new gitlab name to something like A-Z, a-z, and 0-92023-06-28T18:43:07ZRoger DingledineLobby needs to limit new gitlab name to something like A-Z, a-z, and 0-9When people attempt usernames with surprising characters in them, gitlab-lobby fails to make the gitlab account. If this is a gitlab-lobby bug, we should fix it and be happy. If this is a gitlab limitation (e.g. "you can't have chinese a...When people attempt usernames with surprising characters in them, gitlab-lobby fails to make the gitlab account. If this is a gitlab-lobby bug, we should fix it and be happy. If this is a gitlab limitation (e.g. "you can't have chinese account names"), we should hack around it in gitlab-lobby by enforcing some rules on names. Otherwise we have people attempting to make accounts which we know will fail.
Thanks!https://gitlab.torproject.org/tpo/tpa/team/-/issues/40416long server names crash the backup server2022-04-07T16:02:52Zanarcatlong server names crash the backup serverin tpo/tpa/team#40364 I went a little overboard and created a server named:
static-gitlab-shim-source.torproject.org
I even thought of adding a -01 in there. That short name (`static-gitlab-shim-source`) is 25 characters long which...in tpo/tpa/team#40364 I went a little overboard and created a server named:
static-gitlab-shim-source.torproject.org
I even thought of adding a -01 in there. That short name (`static-gitlab-shim-source`) is 25 characters long which leads to a label on the backup server that crashes Bacula:
Sep 24 17:14:45 bacula-director-01 bacula-dir[1467]: Config error: name torproject-static-gitlab-shim-source.torproject.org-full.${Year}-${Month:p/2/0/r}-${Day:p/2/0/r}_${Hour:p/2/0/r}:${Minute:p/2/0/r} length 130 too long, max is 127
Now: maybe I should have used a shorter server name (and I have since retired the box). But it seems to me that a single server with a bad configuration shouldn't hang the entire backup server.https://gitlab.torproject.org/tpo/tpa/team/-/issues/12436Mail archive lint2020-09-28T16:02:41ZgrarpampMail archive lintSome messages in the gzip pipermail archives (lists.torproject.org)
lack the correct metadata and format for what would otherwise be
full use by MUA's.
If the full raw archives exist, it may be easier to see what
reimporting with curren...Some messages in the gzip pipermail archives (lists.torproject.org)
lack the correct metadata and format for what would otherwise be
full use by MUA's.
If the full raw archives exist, it may be easier to see what
reimporting with current mailman tools looks like.
From a concatenation of the three main lists: dev, relays, talk
(the others were not checked and may suffer as well)
There is...https://gitlab.torproject.org/tpo/tpa/team/-/issues/25880mailing list archive download not working2020-09-28T16:02:42Zcypherpunksmailing list archive download not working
Steps to reproduce (using torbrowser, but probably also any other browser):
- login to any private ML on lists.tpo
- click on the Archives URL e.g. https://lists.torproject.org/cgi-bin/mailman/private/bad-relays/
- in the last column ("...
Steps to reproduce (using torbrowser, but probably also any other browser):
- login to any private ML on lists.tpo
- click on the Archives URL e.g. https://lists.torproject.org/cgi-bin/mailman/private/bad-relays/
- in the last column ("Downloadable version") choose any entry -> right click -> "Save as..."
- try to open the file (it is an html file instead of a .gz)
and it does not contain any emails (just the html authentication form)Jens KubiezielJens Kubiezielhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40974make a list of licenses and copyright policies used in TPA repositories2023-09-05T16:32:52Zanarcatmake a list of licenses and copyright policies used in TPA repositoriesin this week's all hands, we discussed copyright policy and established we should at least make an inventory of what licenses are used by which team. we should make a tour of our git repositories (an interesting exercise in itself) and f...in this week's all hands, we discussed copyright policy and established we should at least make an inventory of what licenses are used by which team. we should make a tour of our git repositories (an interesting exercise in itself) and figure out which repository is using which license.
if we do find repositories *without* licenses, we should mark that as a bug and set a license. make sure we have a stated policy on inbound=outbound, for example, and, why not, start using CONTRIBUTING and code of conducts and proper READMEs for all repos...
the output of this should possibly be a RFC setting a team-wide policy about copyright assignment as well.https://gitlab.torproject.org/tpo/tpa/gitlab-lobby/-/issues/1Make it easy for people to create accounts AND contribute first comment/ticket2023-08-10T19:10:13ZAlexander Færøyahf@torproject.orgMake it easy for people to create accounts AND contribute first comment/ticket@nickm had an interesting point for a Gitlab Lobby to avoid the round-trip for new users who wants to submit a ticket/comment:
Users should have a way to request an account + submit their first issue or comment in one go, instead of hav...@nickm had an interesting point for a Gitlab Lobby to avoid the round-trip for new users who wants to submit a ticket/comment:
Users should have a way to request an account + submit their first issue or comment in one go, instead of having to first create an account, then wait to get access to the account, then submit their issue. This could lead some people who otherwise would prefer the anonymous account (for ease) to create an account.https://gitlab.torproject.org/tpo/tpa/team/-/issues/41506Make it harder to forget to deploy tpo/web changes2024-01-30T15:03:48ZKezMake it harder to forget to deploy tpo/web changesIn tpo/web/tpo#403, I made a change, checked the review app, merged the change, checked the staging site, and *forgot* to deploy it to production. I only noticed because I was checking the pipelines for an unrelated issue and noticed the...In tpo/web/tpo#403, I made a change, checked the review app, merged the change, checked the staging site, and *forgot* to deploy it to production. I only noticed because I was checking the pipelines for an unrelated issue and noticed the deploy job didn't run. Bekeela also pointed out to me that the change wasn't deployed, but without the two of us checking, I never would've noticed and the change wouldn't have been deployed until the next time a change was needed on tpo.
I think it would really benefit us and our stakeholders to make it harder to forget to deploy to production. Maybe we could make a simple bot that checks if a change has been deployed to staging, but not production.Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/tpa/status-site/-/issues/12make resolved/resolvedWhen useful for experiments2023-11-09T22:50:07Zanarcatmake resolved/resolvedWhen useful for experimentsin !12, I noticed that we can't quite change the severity of an experiment or mark it as resolved as we typically do with other issues.
it would be nice if we could use the same workflow than other issues. in !12, for example, it would ...in !12, I noticed that we can't quite change the severity of an experiment or mark it as resolved as we typically do with other issues.
it would be nice if we could use the same workflow than other issues. in !12, for example, it would this part irrelevant:
```diff
## When did it stop?
-Not yet, it's still ongoing as far as we know.
+Around 2021-09-08 13:00:00 UTC.
```
which would be less error-prone.https://gitlab.torproject.org/tpo/tpa/gitlab-lobby/-/issues/17Make separate settings.py file for production and development2023-08-10T19:10:13Zasu1996Make separate settings.py file for production and developmentWe can add separate settings.py file for production and development and use python-decouple to increase the security of certain elements.
Also, separate files can help in preventing really long settings file
This can be an extension to...We can add separate settings.py file for production and development and use python-decouple to increase the security of certain elements.
Also, separate files can help in preventing really long settings file
This can be an extension to #5
Opinions on this? @ahf @gabahttps://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/76make wikis more editable2022-10-13T13:17:43Zanarcatmake wikis more editablewikis can only be edited by members of the Developer group in a project, according to the [upstream documentation](https://docs.gitlab.com/ce/user/permissions.html#project-members-permissions). that is problematic because that permission...wikis can only be edited by members of the Developer group in a project, according to the [upstream documentation](https://docs.gitlab.com/ce/user/permissions.html#project-members-permissions). that is problematic because that permission also grants access to the source code in a project.
we'd like to have more flexibility in that regard: wikis are ideal for drive-by contributions who we might not want to grant special privileges to. similarly, teams should be able to edit each other's wiki, since documentation is often collaborative across teams.
let's see if that's possible at all.
There's an upstream feature request to make [wikis publicly editable](https://gitlab.com/gitlab-org/gitlab/-/issues/27294) and another to [allow visitors to suggest edits](https://gitlab.com/gitlab-org/gitlab/-/issues/42412). the wireshark team uses a [separate wiki with MR wokflow](https://gitlab.com/wireshark/editor-wiki/) to allow outside contributions, but that feels rather clunky.https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/124Making GitLab more searchable for Tor Log entries2022-05-05T23:57:17ZcypherpunksMaking GitLab more searchable for Tor Log entriesComment on GitLab Layout:
Gitlab issues would be easier to search if the List overview contained a "symptom"-column or a search- & sort-able subtitle that matched the "symptom"s appearing in Tor Log since this is what people would copy/p...Comment on GitLab Layout:
Gitlab issues would be easier to search if the List overview contained a "symptom"-column or a search- & sort-able subtitle that matched the "symptom"s appearing in Tor Log since this is what people would copy/paste from Tor Log and search for.https://gitlab.torproject.org/tpo/tpa/team/-/issues/29304Manage the lifecycle of systems2022-12-20T19:25:37ZJens KubiezielManage the lifecycle of systemsDuring the sysadmin meeting in Brussels we discussed our infrastructure. Systems are managed by service admins/owners. They sometimes disappear or services become irrelevant. This means we have systems without proper owner which are rott...During the sysadmin meeting in Brussels we discussed our infrastructure. Systems are managed by service admins/owners. They sometimes disappear or services become irrelevant. This means we have systems without proper owner which are rotting over time.
To better handle such systems we decided that systems like `$host.torproject.org` should have an expiration date which is initially one or two years in the future. When the expiration date is near the service owner receives an email informing about the possible shutdown and the means to prevent it (write an email answer to tpa). If the mail is answered the expiration date will be prolonged. If not, the system will be deactivated. The deactivation can easily be revoked. However after some more time without any feedback the host will be decommissioned.
This ticket is to track the several steps for implementing this new policy.https://gitlab.torproject.org/tpo/tpa/team/-/issues/40380mandos monitoring2023-03-30T01:37:59Zanarcatmandos monitoringas part of the automate reboots project (#33406), it seems like we could automatically reboot *some* nodes provided that (a) they are correctly set in mandos and (b) that mandos actually works.
this requires monitoring of the individual...as part of the automate reboots project (#33406), it seems like we could automatically reboot *some* nodes provided that (a) they are correctly set in mandos and (b) that mandos actually works.
this requires monitoring of the individual nodes in mandos, which we do not seem to be currently doing.anarcatanarcat