The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-05-11T17:27:30Zhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41160Upgrade userdir-ldap to Python 32023-05-11T17:27:30ZJérôme Charaouilavamind@torproject.orgUpgrade userdir-ldap to Python 3Currently it's not possible to fully integrate a Debian `bookworm` machine (such as `forum-test-01`) into the fleet because `userdir-ldap` requires Python 2.7, and it's been removed from Debian.
Please port `userdir-ldap` to Python 3.Currently it's not possible to fully integrate a Debian `bookworm` machine (such as `forum-test-01`) into the fleet because `userdir-ldap` requires Python 2.7, and it's been removed from Debian.
Please port `userdir-ldap` to Python 3.Debian 12 bookworm upgradeanarcatanarcathttps://gitlab.torproject.org/tpo/network-health/metrics/tagtor/-/issues/11Create a note attribute for a router2023-06-14T16:43:18ZHiroCreate a note attribute for a routerIn https://gitlab.torproject.org/tpo/network-health/team/-/issues/278 we have discussed how we could benefit by attaching free text annotations to routers.
This could take the form of a note that can be displayed as a comment to the rou...In https://gitlab.torproject.org/tpo/network-health/team/-/issues/278 we have discussed how we could benefit by attaching free text annotations to routers.
This could take the form of a note that can be displayed as a comment to the router page.HiroHirohttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40851Integrate tools/signing/android-signing in do-all-signing2023-06-12T20:17:58ZboklmIntegrate tools/signing/android-signing in do-all-signingboklmboklmhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41159Manage Ganeti cluster domain secret in Puppet2024-01-17T16:51:35ZJérôme Charaouilavamind@torproject.orgManage Ganeti cluster domain secret in PuppetThe cluster domain secret, stored in `/var/lib/ganeti/cluster-domain-secret` on all nodes of a Ganeti cluster, must be identical between all nodes involved in a cross-cluster migrations. Furthermore, the [upstream documentation](https://...The cluster domain secret, stored in `/var/lib/ganeti/cluster-domain-secret` on all nodes of a Ganeti cluster, must be identical between all nodes involved in a cross-cluster migrations. Furthermore, the [upstream documentation](https://docs.ganeti.org/docs/ganeti/3.0/html/move-instance.html#configuring-clusters-for-instance-moves) offers this recommendation:
> It is recommended to assign the same domain secret to all clusters of the same security domain, so that instances can be easily moved between them.
The documentation suggests using `gnt-cluster renew-crypto --cluster-domain-secret=/.../ganeti.cds` to install the new secret, but it seems like simply dropping the file content into place is sufficient. `gnt-cluster verify` will only complain if the file not identical between nodes.Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/177Change help links in `about:preferences` and menu2023-10-03T13:30:05ZruihildtChange help links in `about:preferences` and menuRight now, we link to https://mullvad.net/en/help/ in:
- `about:preferences` under `Mullvad Browser Support` link at the bottom left
- the menu `Help > Get Help`
I might be forgetting other places where this link exists.
There's now a ...Right now, we link to https://mullvad.net/en/help/ in:
- `about:preferences` under `Mullvad Browser Support` link at the bottom left
- the menu `Help > Get Help`
I might be forgetting other places where this link exists.
There's now a dedicated sub-section link we can use instead https://mullvad.net/en/help/tag/mullvad-browser/richardrichardhttps://gitlab.torproject.org/tpo/core/arti/-/issues/853Questions and suggestions wrt key-management.md2024-01-09T17:27:40ZNick MathewsonQuestions and suggestions wrt key-management.mdHi @gabi-250 !
I've read over `key-management.md` and have a few ideas, questions, and suggestions. Please feel free to defer these or to handle them whenever you get to the corresponding parts of code; none of them is urgent.
## Mayb...Hi @gabi-250 !
I've read over `key-management.md` and have a few ideas, questions, and suggestions. Please feel free to defer these or to handle them whenever you get to the corresponding parts of code; none of them is urgent.
## Maybe we should rename `KeyIdentity`, `HsClientIdentity`, etc.
The Tor protocol has the notion of an "identity key"–a key that uniquely identifies a relay, an onion service, or a a directory authority. With that in mind, I think having a "key identity" could get confusing. Possible alternatives: "KeyLocator", "KeySpecifier", "KeyName", "HsClientName", "HsClientAcct", ...
## Possibly we should version `ArtiKeyStore`.
Maybe we should have a top-level file in the arti keystore hierarchy to indicate "this is an arti keystore" and to apply a version number to it. That way, if we wanted to, we could make changes in the design in the future.
## What does a C keystore look like for onion services?
In C Tor, most keys are kept in `${DATADIR}/keys`. But the keys for each onion are kept in a separate directory configured for each onion service. How would we migrate these to arti, if arti expects that a c-tor keystore will be configured in a single location?
## How should we store metadata?
In several cases we need to store extra data associated with a given key, and keep that data in sync. Types of data include:
* An expiration date or a time range
* A certificate
One challenge here is keeping such data in sync with the key itself, if we're allowing concurrent access.
## Are paths relative to the store root?
I think that `ArtiPath` and `CTorPath` are relative paths, with respect to the root of the keystore, containing no ".." elements. If that's right, great.
## Features to avoid key misuses.
The C Tor key format (or one of them, at least) encodes the usage of the key in the file itself. Thus, you can't (for example) store a new relay ed25519 identity key without knowing that it is a relay identity key (and not, say, an onion service identity key).
The goal of this design was to prevent key misuse: it makes it a little harder for somebody to accidentally use a key file in a location of the wrong type. (I do not know how often it has prevented this type of error:, but in the past, we have found that power users can sometimes create extremely confusing shufflings of their keys, under the theory that it "ought to work".)
But having keys tagged this way creates two questions:
1. Are C keystores read-write, or read-only? If they are read-write, then when we're telling a C keystore to store something, we need to encode its intended usage, not only its KeyType.
Personally, I'm okay with making C keystores read-only, or even making it so that the only thing you can use a C keystore for is to copy all of its keys to arti.
2. Should we try to build a similar feature for Arti?
This would be hard to do with our chosen ssh-style key format, since we want Arti to be able to consume keys generated with e.g. `ssh-keygen`, and since there is nowhere good to store extra information except in the "comment" field.
One possibility would be to put this information in the comment field anyway, and to warn (but not reject the key) if we see that a comment field indicates that a key has the wrong usage. For example, we could create a relay identity key with the comment "Arti: Relay Ed255519 Identity Key" and an ntor onion key with the comment "Arti: ntor onion key (Expires 2023-07-01)". If we see a relay identity key with the comment "" or the comment "key for my relay", then we allow it silently. But if we see a relay identity key with the comment "Arti: ntor onion key" we could warn the user.
I don't know whether this feature is worthwhile or not.Arti: Onion service supportgabi-250gabi-250https://gitlab.torproject.org/tpo/network-health/exitmap/-/issues/45exitmap on macOS/Windows is busted2023-06-15T10:32:49ZGeorg Koppenexitmap on macOS/Windows is busted@art wrote a MR (!21) that fixes this ticket and gives stacktraces etc. for this problem.@art wrote a MR (!21) that fixes this ticket and gives stacktraces etc. for this problem.Arturo FilastòArturo Filastòhttps://gitlab.torproject.org/tpo/core/arti/-/issues/852tor-hsclient test failure2023-05-10T15:25:52Zajaktor-hsclient test failure### Summary
Continuing with running tests after #843, I discovered another test failure.
### Steps to reproduce:
1. `cargo test -p tor-hsclient`
### What is the current bug behavior?
Test fails
### What is the expected behavior?
T...### Summary
Continuing with running tests after #843, I discovered another test failure.
### Steps to reproduce:
1. `cargo test -p tor-hsclient`
### What is the current bug behavior?
Test fails
### What is the expected behavior?
Test should pass
### Environment
- Version: 3725939aba62f6ff4770ae8df3171fa31e090cbd
- Operating system: Gentoo
- Install method: Running from git
### Relevant logs and/or screenshots:
```
~/git/arti $ cargo test -p tor-hsclient
warning: unused import: `SelfSigned`
--> crates/tor-netdoc/src/doc/hsdesc.rs:26:21
|
26 | use tor_checkable::{SelfSigned, Timebound};
| ^^^^^^^^^^
|
= note: `#[warn(unused_imports)]` on by default
warning: unused import: `Timebound`
--> crates/tor-netdoc/src/doc/hsdesc.rs:26:33
|
26 | use tor_checkable::{SelfSigned, Timebound};
| ^^^^^^^^^
warning: `tor-netdoc` (lib) generated 2 warnings
Compiling tor-hsclient v0.2.0 (/home/jake/git/arti/crates/tor-hsclient)
error[E0599]: no function or associated item named `parse_decrypt_validate` found for struct `HsDesc` in the current scope
--> crates/tor-hsclient/src/connect.rs:333:30
|
333 | let hsdesc = HsDesc::parse_decrypt_validate(
| ^^^^^^^^^^^^^^^^^^^^^^ function or associated item not found in `HsDesc`
error[E0599]: no function or associated item named `parse_decrypt_validate` found for struct `tor_netdoc::doc::hsdesc::HsDesc` in the current scope
--> crates/tor-hsclient/src/connect.rs:333:30
|
333 | let hsdesc = HsDesc::parse_decrypt_validate(
| ^^^^^^^^^^^^^^^^^^^^^^ function or associated item not found in `HsDesc`
error[E0599]: no variant or associated item named `BadTimeBound` found for enum `ParseErrorKind` in the current scope
--> crates/tor-hsclient/src/err.rs:151:22
|
151 | PEK::BadTimeBound | PEK::BadSignature => EK::OnionServiceDescriptorValidationFailed,
| ^^^^^^^^^^^^ variant or associated item not found in `ParseErrorKind`
error[E0599]: no function or associated item named `parse_decrypt_validate` found for struct `tor_netdoc::doc::hsdesc::HsDesc` in the current scope
--> crates/tor-hsclient/src/connect.rs:598:30
|
598 | let hsdesc = HsDesc::parse_decrypt_validate(
| ^^^^^^^^^^^^^^^^^^^^^^ function or associated item not found in `HsDesc`
For more information about this error, try `rustc --explain E0599`.
error: could not compile `tor-hsclient` due to 2 previous errors
warning: build failed, waiting for other jobs to finish...
error: could not compile `tor-hsclient` due to 3 previous errors
```gabi-250gabi-250https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/126Research about designing an armored bridge line sharing URL format2024-03-04T15:32:16ZshelikhooResearch about designing an armored bridge line sharing URL formatTor's bridge line format is well suited for professional developers and power users on desktop environments. However, for other users the current bridge line does not work so well because:
1. The bridge line contains white space and oth...Tor's bridge line format is well suited for professional developers and power users on desktop environments. However, for other users the current bridge line does not work so well because:
1. The bridge line contains white space and other special characters that could make it hard to copy and paste correctly.
2. When the bridge line was corrupted, the client software can neither detect it, nor correct it. This results in user confusion as the corrupted bridge line results in silent error.
3. User tries to edit the bridge line without understanding how it works internally. This results in inconsistency between how the user expects a bridge line to work and how it actually works.
This ticket tracks the research and discussion about creating a new bridge line format specialized in sharing to address the issues mentioned.
Let's make some initial discussion before I write the full spec and write a reference implementation.
## Goals and non-goals
This armored bridge line format will try to:
1. auto detect/auto correct error occurred during transmission. Give the user explicit feedback when the bridge line is corrupted and avoid silent errors.
2. improve its operating system integration, allowing the user to click on the armored bridge line and be redirected to a bridge line recipient application.
3. avoid any characters or design that could make it harder to transmit the bridge line correctly.
4. signal user not to modify the shared bridge line by intuitively
It won't:
1. try to replace the current bridge line format. It is used to share bridge lines, and original bridge line format will still be accepted by all Tor applications and shown to users by default. The current bridge line format will still be the way bridge configurations are represented.
2. prevent users from editing bridge lines. Users still will be able to edit the bridge line once it is decoded from armored format.
3. prevent the bridge line from being censored or detected by authority.
## Expected Usage Context
This armored bridge line design will be used exclusively for sharing.
Specifically:
1. On Tor Browser, there will be a share bridge line button, when clicked, an armored bridge line will be converted from an ordinary bridge line, and shown to the user as plain text and QR code.
2. The user support team will share an armored bridge line generated from Tor Browser or command line tool to users requesting a bridge when appropriate.
3. Users can share armored bridge lines with each other.
4. Tor client implementations MAY support armored bridge line input. It is optional since this design is targeted toward ordinary users, and Tor Browser already supports converting bridge lines between different forms with command line tools. Advanced users can just use command line tools to convert bridge lines between its different formats.
## Internal design (for discussion)
The 2 way convention between armored bridge line and ordinary bridge line is through a sequence of reversible transform steps. Some of them are optional(under discussion), and may or may not be included in the final design. There are no dynamic or skipable step in the final version of the design.
### Compression (optional)
A compression like 7 bit UTF8 can be used to reduce the length of the final url string.
It will however make conversion more complex to implement.
### All or none transform (optional)
A all or none transform(AONT) like [SAEP+](http://crypto.stanford.edu/~dabo/abstracts/saep.html) can make sure the final output is completely random looking, polymorphic without any resemblance of underlying data.
This ensures:
1. Data are covered by checksum(see SAEP+ design), so any corruption will be detected.
2. Because data are encoded differently each time, if the final output contains a censored keyword, the user can just try again.
3. there will be less observable patterns in the final URL, preventing users from attempting to modify or interpreting it. The users will need to use a supported application to process the armored bridge line.
4. (less of a concern for Tor ecosystem) prevent client implementation from ignoring the checksum and process anyway.
This is a complex transform step.
### Checksum (if All or none transform step is not used) (optional)
Use a CRC64 or SHA-3 to generate a checksum to detect corruption.
This step should be skipped if AONT step was used.
### Forward error correction (optional)
Split the data into chunks and use Reed Solomon coding to encode the data and generate recovery shreds.
When the bridge line is corrupted, forward error correction attempts to repair content directly, without asking the user to try again. This non-interactive repair makes it easier for the user to get the bridge line working, without asking and waiting for assistance. Some environments like bad email clients/line breakers corrupt the content each time it processes it, retry itself won't work and frustrate users.
This is a complex transform step.
### URLSafe base64 encoding without padding + concreted
URL safe base64 encoding without padding will convert the binary result of previous steps into a URL safe string. If there is more than one shard of contents, they will be concreted with ~ symbol, which is URL safe and not used by URL safe base64.
### URL Prefix
The final string will be prefixed with either `bridgeprefix:?` or `https://bridgeprefix/#` to allow it to be clicked and be redirected to Tor client application by operating system.shelikhooshelikhoo2024-03-08https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/141Give permissions to @juga to merge requests, assign labels to issues, etc .to...2023-05-05T18:02:29ZjugaGive permissions to @juga to merge requests, assign labels to issues, etc .to anon_ticket and gitlab-lobbyto work on what we comented at [Anonticket and gitlab lobby: plans and possibilities](https://gitlab.torproject.org/tpo/team/-/wikis/costa-rica-anonticket-discussion)to work on what we comented at [Anonticket and gitlab lobby: plans and possibilities](https://gitlab.torproject.org/tpo/team/-/wikis/costa-rica-anonticket-discussion)anarcatanarcathttps://gitlab.torproject.org/tpo/network-health/metrics/descriptorParser/-/issues/21Clean up descriptorparser code while going over it again2023-06-14T16:36:46ZGeorg KoppenClean up descriptorparser code while going over it againI am double-checking all the tables we have over in collector#40016 and this ticket is for typos etc. I am finding while looking over the code again to get some clean up done.I am double-checking all the tables we have over in collector#40016 and this ticket is for typos etc. I am finding while looking over the code again to get some clean up done.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41155Ensure emails from weather-01 are DKIM-signed2023-06-08T13:14:22ZJérôme Charaouilavamind@torproject.orgEnsure emails from weather-01 are DKIM-signedCurrently, the Tor Weather platform on `weather-01` is sending emails as `weather@torproject.org` but they're not DKIM-signed so its likely there might be some deliverability issues for these notifications.Currently, the Tor Weather platform on `weather-01` is sending emails as `weather@torproject.org` but they're not DKIM-signed so its likely there might be some deliverability issues for these notifications.Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41154reconsider Firefox key pinning for *.torproject.org domains2023-05-16T19:09:14Zanarcatreconsider Firefox key pinning for *.torproject.org domainsFirefox wrote security@torproject.org to ask us whether or not we want to continue the public key pinning program they have. We have 14 days to respond with, and I quote:
> - The list of domains and/or subdomains you believe are pinned...Firefox wrote security@torproject.org to ask us whether or not we want to continue the public key pinning program they have. We have 14 days to respond with, and I quote:
> - The list of domains and/or subdomains you believe are pinned.
> - The list of public keys / certificates you believe your domains are pinned to.
Honestly, I'm not absolutely sure what this is about. @ma1 said that we can find the pins with this GitLab search:
https://gitlab.torproject.org/search?search=kPinset_tor&nav_source=navbar&project_id=472&group_id=477&search_code=true&repository_ref=tor-browser-102.10.0esr-12.5-1
That would seem to say the answer is:
| domain | cert |
|--------------------------|----------------------------|
| `blog.torproject.org` | "lots" |
| `bridges.torproject.org` | `kISRG_Root_X1Fingerprint` |
| `check.torproject.org` | "lots" |
| `dist.torproject.org` | "lots" |
| `torproject.org` | "lots" |
| `www.torproject.org` | "lots" |
The "lots" cert is a rather [long list of certs](https://gitlab.torproject.org/tpo/applications/tor-browser/-/blob/tor-browser-102.10.0esr-12.5-1/security/manager/ssl/StaticHPKPins.h#L438):
```
static const char* const kPinset_tor_Data[] = {
kGOOGLE_PIN_R4LetsEncryptFingerprint,
kTor3Fingerprint,
kDigiCert_High_Assurance_EV_Root_CAFingerprint,
kLet_s_Encrypt_Authority_X3Fingerprint,
kTor1Fingerprint,
kGOOGLE_PIN_R3LetsEncryptFingerprint,
kGOOGLE_PIN_RapidSSLFingerprint,
kLet_s_Encrypt_Authority_X4Fingerprint,
kTor2Fingerprint,
};
```
That looks like:
* DigiCert
* Let's Encrypt R3
* Let's Encrypt R4
* Let's Encrypt X4
* Rapid SSL
* some tor-specific fingerprints (!?)
The latter is:
```
/* Tor1 */
static const char kTor1Fingerprint[] =
"bYz9JTDk89X3qu3fgswG+lBQso5vI0N1f0Rx4go4nLo=";
/* Tor2 */
static const char kTor2Fingerprint[] =
"xXCxhTdn7uxXneJSbQCqoAvuW3ZtQl2pDVTf2sewS8w=";
/* Tor3 */
static const char kTor3Fingerprint[] =
"CleC1qwUR8JPgH1nXvSe2VHxDe5/KfNs96EusbfSOfo=";
```
not sure what those represent at all.
The CAs in use that I am aware of are documented in [this TPA page](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/tls/#certificate-authorities-in-use-at-tor), excerpt:
> * [Let's Encrypt](https://letsencrypt.org): automatically issues certificates for most websites and domains, managed by TPA
> * [Globalsign](https://globalsign.com): used by the [Fastly](https://www.fastly.com/) CDN used to distributed TBB updates
> * [Digicert](https://www.digicert.com/): used by other teams to sign software releases for Windows
> * [Harica](https://harica.gr): used for HTTPS on the donate.tpo onion service
> * [howto/Puppet](/tpo/tpa/team/-/wikis/howto/Puppet): our configuration management infrastructure has its own X.509 certificate authority which allows "Puppet agents" to authenticate and verify the "Puppet Master", see [our documentation](/tpo/tpa/team/-/wikis/howto/puppet) and [upstream documentation](https://puppet.com/docs/puppet/latest/ssl_certificates.html) for details
> * [howto/ldap](/tpo/tpa/team/-/wikis/howto/ldap): our OpenLDAP server uses a custom self-signed x.509 certificate authority that is distributed to clients via Puppet, see [the documentation](/tpo/tpa/team/-/wikis/howto/ldap#server-certificate-renewal) for instructions to renew this certificate manually
> * internal "auto-ca": all nodes in Puppet get their own X.509 certificate signed by a standalone, self-signed X.509 certificate, documented below. it is used for backups (Bacula) and mail deliver (Postfix)
Of those, I think the first 4 are relevant to this case. It seems like Harica and Globalsign are not in the pin list provided to Firefox, interestingly.
So what should we do with this?
It seems to me we should add GlobalSign to the list for stuff that's served over Fastly at least. We should keep Digicert, and remove RapidSSL. Not sure what to do about Harica, because that's for onion services... Also not sure what to do about those three standalone fingerprints.
Thoughts?
/cc @micah @ma1anarcatanarcat2023-05-16https://gitlab.torproject.org/tpo/network-health/team/-/issues/300Create a stem point release (1.8.2)2023-07-03T08:23:43ZGeorg KoppenCreate a stem point release (1.8.2)We should create a new stem point release making sure stem is working well with Python 3.11 which seems to be a problem currently many Linux distributions at least are facing.We should create a new stem point release making sure stem is working well with Python 3.11 which seems to be a problem currently many Linux distributions at least are facing.jugajugahttps://gitlab.torproject.org/tpo/network-health/margot/-/issues/18Write bad relay rules directly to approved-routers.conf and/or bad.conf2023-06-14T16:41:57ZGeorg KoppenWrite bad relay rules directly to approved-routers.conf and/or bad.confOur [`badconf-entry.py`](https://gitlab.torproject.org/tpo/network-health/helper-scripts/-/blob/master/badconf-entry.py) script writes the entries for `approved-routers.conf` and, if necessary, `bad.conf` directly into those files. We wa...Our [`badconf-entry.py`](https://gitlab.torproject.org/tpo/network-health/helper-scripts/-/blob/master/badconf-entry.py) script writes the entries for `approved-routers.conf` and, if necessary, `bad.conf` directly into those files. We want to have something similar in `margot` as that makes the work of rejecting relays a lot easier and, most importantly, way less error-prone than copying around lines printed to stdout or something.jugajugahttps://gitlab.torproject.org/tpo/web/donate-static/-/issues/116the staging site is built in live mode2023-05-02T20:49:00ZKezthe staging site is built in live modewe have two different "modes" that we can build the frontend in: development, and prod ("live" as stripe calls it). normally, this is what we want. staging should reflect the production site exactly, so there are no surprises when we dep...we have two different "modes" that we can build the frontend in: development, and prod ("live" as stripe calls it). normally, this is what we want. staging should reflect the production site exactly, so there are no surprises when we deploy to production. unfortunately, this means we can't make test donations on the staging site unless we use an actual credit card. the frontend would need to be built in dev mode for us to use a [test card](https://stripe.com/docs/testing), and be able to properly test staging.
this doesn't just affect the frontend though. we are also unable to test the donate middleware staging site, becuase we can't make any test payments through the staging frontend
we'll need to change donate-static's CI script to build in development mode and deploy to staging, then build in production mode and prepare to deploy to production. i'm not sure that the lektor ci script is flexible enough to do what we need, so i might need to just copy that entirely into this repo, and edit as needed.
this is blocking #115, because we can't test the fix for that ticket.https://gitlab.torproject.org/tpo/tpa/team/-/issues/41152Lost network on ns5.torproject.org2023-05-03T15:07:39ZJérôme Charaouilavamind@torproject.orgLost network on ns5.torproject.orgThe machine was rebooted after switching to static IP config. There must be some issue because its not reachable over the network anymore.The machine was rebooted after switching to static IP config. There must be some issue because its not reachable over the network anymore.Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41151Retire gitlab-dev-012023-06-07T15:53:49ZJérôme Charaouilavamind@torproject.orgRetire gitlab-dev-01This machine was brought up from backups as a (successful) proof of concept. Now, we realize the machine might have apparently been interacting with CI and accumulating data beyond normal limits, so Nagios is starting to complain. Also, ...This machine was brought up from backups as a (successful) proof of concept. Now, we realize the machine might have apparently been interacting with CI and accumulating data beyond normal limits, so Nagios is starting to complain. Also, the usefulness of keeping is around isn't really established: we might have had use for it in tpo/tpa/gitlab#23 until we realized that if we flip the switch on mail on that server, this could potentially unleash a torrent of irrelevent notifications on many unsuspecting users.
1. [x] announcement
2. [x] nagios
3. [x] retire the host in fabric
4. [x] remove from LDAP with `ldapvi`
5. [x] power-grep
6. [x] remove from tor-passwords
7. [x] remove from DNSwl
8. [x] remove from docs
9. [x] remove from reverse DNSJérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.org2023-06-05https://gitlab.torproject.org/tpo/team/-/issues/162Review browser-based code verification options for proposal with FPF2023-05-10T19:20:56ZGabagaba@torproject.orgReview browser-based code verification options for proposal with FPFproposal for client-side encryption in Tor Browser to better project whistleblowers and journalists.
To mitigate the risk of users executing compromised JavaScript, we are running up against the problem that there are no established mec...proposal for client-side encryption in Tor Browser to better project whistleblowers and journalists.
To mitigate the risk of users executing compromised JavaScript, we are running up against the problem that there are no established mechanisms for code-signing and verifying web applications.
Related issues:
- https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40458
- https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41041
Existing efforts:
- https://www.pageintegrity.net/
- https://blog.cloudflare.com/cloudflare-verifies-code-whatsapp-web-serves-users/
- https://arxiv.org/pdf/2104.06136.pdf
- https://github.com/vs-uulm/wait-prototype
cc @pierov @micah @richardhttps://gitlab.torproject.org/tpo/team/-/issues/158Process any CR meeting notes2023-05-02T14:44:14ZGabagaba@torproject.orgProcess any CR meeting notesGabagaba@torproject.orgGabagaba@torproject.org