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.

Maybe we should hide profile details for newly registered users as well? Requiring approval would reduce the value that spammers derive from registering accounts. At least it would raise the amount of effort required of the spammers but unfortunately would also raise the effort required of us to monitor / approve accounts . and we would need to define what the user is required to do to prove themselves.

A bit about Security

It turns out that this is a duplicate:
T15443: Add Diffusion policy capability "Can Edit and View Identities"

But, they identities probably should be editable only for:

• people who can edit the repository (people who administer it)
• you, if the email matches yours (since you somehow pushed in the repository)

Uh thanks. Interesting. Yeah probably with considerations under Security probably.

Taking a stab at what it would look like in D25276: Add support for secure connections to the database. It's not tested at all yet but I think that's roughly the shape it would take. I haven't looked into how this would affect cluster environments but I think that is covered.

Yes. The trade off would be user experience. I have absolutely spent 15+ minutes waiting for a reset email on sites after having either typo’d or put in a different email address from the one I signed up with.

If I've understood correctly,

In T15091#9775, @RhinosF1 wrote:

Can this be made public?

Can this be made public?

It's 2023, I think "not supporting TLS" should count as "high pri bug" now.

Closing for now as "we're ok with this", and there was no interaction on this ticket for a while.

fwiw the phabricator-ava project also has the ability to roll back all changes by a user, however, it won't touch tasks which have been subsequently edited by a different user so the automated tool must be used before attempting to clean up manually or the automation fails.

We need a NO PULL REQUESTS! script. It reminds me in the old days people who says this in Phabricator in pull requests:

(By the way let's understand if this user has a local commit published somewhere) - thanks @Labricator for sharing this info

If you don't like Arcanist, feel free to just do a pull request on GitHub and we will convert that to an Arcanist patch.

In T15045#1474, @Labricator wrote:

I’d definitely try, but it depends if we are using GitHub or command line git.

Merging T15102 here; cc @marting, @valerio.bozzolan.

@avivey has fixed this on the upstream install.

In T15090#2141, @avivey wrote:

In T15090#2123, @Matthew wrote:

@avivey Would it make sense to add a public announcement to Diviner or Phiction? Or perhaps we use Phame for this use case (Create a "Security Incidents" blog)? I always think of a task as an actionable item, whereas we would want this to exist forever.

Yes, probably. "Announcements"-style thing

In T15090#2123, @Matthew wrote:

That's intentional (upstream) because it's very hard to make any actual attack with this information can't be made without it.

Note: reporter exploited without permission

In T15090#2127, @Matthew wrote:

In T15090#2126, @golyalpha wrote:

apparently, Ubuntu maintainers have backported a patch for the older version of git in 20.04 LTS, downgrading to version 1:2.25.1-1ubuntu3 seems to be a temporary workaround, losing the following patches:

I don't think having people downgrade is a good idea. I think we should probably cherry-pick Evan's fix from upstream into the phorge codebase.

In T15090#2126, @golyalpha wrote:

apparently, Ubuntu maintainers have backported a patch for the older version of git in 20.04 LTS, downgrading to version 1:2.25.1-1ubuntu3 seems to be a temporary workaround, losing the following patches:

ahh, I was wondering why my Phorge install suddenly broke - seems to be the case here too

We need to cherry-pick and import the changes Evan made into the Phorge repository as well...

err, I was trying to put it out as a Security PSA, so I clicked "Create security task" which I guess is the opposite of a PSA...