Let’s do it

If there are no objections I would be happy to accept the diff. @speck are your concerns addressed or should we continue discussion / consider other options?

In T15965#20144, @valerio.bozzolan wrote:

What is changing is, that unverified email will not match your unverified email as default, so that should need these 2 clicks manual configs (or, find a way to verify the email)

Yep, manually setting your unverified (and not verifiable) email would still be possible 👍 just two clicks are needed from this kind of pages:

Another edge case: Most of my contributions to Phorge happened as part of my work for Wikimedia. Those commits are under an email address that I no longer have access to, since I am no longer employed at the Wikimedia Foundation.

(I cannot edit this task lol - I would like to add Spam mitigation tag to keep an additional eye on these nice things)

Take for example this commit that has a default identity:

"Steal credit" might actually lead to a real issue: If a new user can get themselves identified as an old, trusted, user based on commit history, their changes might not be checked as rigorously by the rest of the team - similar to the XZ Utils backdoor issue, only faster.

Limitation: to steal a commit identity, it must be the default. Sorry I forgot to say.

In T15965#20052, @speck wrote:

What can a malicious user accomplish by claiming unverified email for commits?

What can a malicious user accomplish by claiming unverified email for commits? The idea outlined here sounds right but I’d like to understand what potential harm could be done on its current state, and also whether there’s any legitimate use case for the current behavior.

Adding @aklapper as subscriber in this security issue since I trust this user (unclear if this should be flagged as security thought, feel free to open)

CVE-2017-5223, CVE-2018-19296 and CVE-2020-36326:

CVE-2021-34551:
This one requires passing user-provided input as a filename to the "setLanguage" method; We don't call that method.

First pass, these one do not apply to us (and some of them do not apply to anyone at all):

(I also cannot see T15665)

Note that I cannot see Task T15663

I'm not able to find #conduit in Matrix mozilla.org homeserver btw

(It needs to be quoted just in we.phorge.it since indeed we have a Tag called Conduit :D Sorry for that)

@valerio.bozzolan If you didn't get an answer, try asking in #conduit. I didn't realize that # needs to be quoted in Remarkup. 😢

Nice! Thanks

It would be great if Mozilla's team could join forces with Phorge. Would you (the core team) contact them in #conduit on chat.mozilla.org and mozilla.slack.com?

I have reviewed it and made some comments. On a remotely related topic, TLS handshakes are expensive and persistent connections can reduce latency and server load by reusing TLS connections, so maybe we should make it configurable outside of cluster.databases as well.

I wonder if they are aware that Phorge exists and that we are open to contributions :)

I have this working now in https://we.phorge.it/D25276. I still have it marked as draft because there are some outstanding things that should be decided/addressed

1. Whether client certificate should be configurable. Ideally this is something that would be configured in the php.ini rather than directly in phorge but at the moment I don't think it can be.
2. Updating documentation to specify how to set up TLS/SSL. For database configurations there's now a use-tls flag which will require connecting to the database using TLS. Turning on TLS/SSL on the database we can probably provide pointers but it's left to the reader for determining that based on their database.
3. Database clusters with master & replicas? I don't know how to set this up. Those changes might affect cluster dbs but I'm unsure and it's untested.

Worked

I picked this up again recently. I’m stuck on getting mariadb valid certificates it uses for connections, for testing my Phorge changes.