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.