I'd expect that a user's contact numbers might show up on their profile to other registered users. I suspect this might be something that upstream considered implementing at some point but never did for some reason...

Seems to be gone for now, the only time I get increased lookup times or complete fails is when there's high internet traffic on my own network. Might've just been some of us got unlucky.

When I said inconsistencies, I was talking specifically issues where certain UI elements have the original English version of the text, while others have the "translated" Pirate English version of the text.

Working around this right now by setting up a Relayed Domain on my mail server and pointing it to the server that my Phorge instance is running on. Obviously only an option if you are running your mailserver, and your configuration isn't too complex to support it.

Another example of broken dark theme

There's a difference between deleting data as a Phab/Phorge admin (which is done via the bin/delete script, and prints out a massive warning about it potentially breaking stuff and generally being a bad idea), and schema migrations done as part of an upgrade, which would happily delete data without a second thought.

Also, this is fairly similar to T15082. Having Epics would probably also resolve that.

I feel like the idea behind milestones being strictly ordered is from the viewpoint that milestones are sequential "events" that happen in development one after another in a given order.

I setup a cron that makes a bunch of DNS queries for different records within the phorge.it zone from all the authoritative nameservers for the zone (see T15080#1985).

Just resurfaced today (now).

I'm actually gonna close this as Resolved - we can always reopen, or refer back to this, if the issue resurfaces.

Nothing new since last time I commented here.

I mean, that's not a particularly good solution to the problem. It just makes the time for which it appears to be fixed longer (even though nothing has changed)

To be fair, I wouldn't discount already needing access as a viable attack vector, even on private installations.

The disclosed issue is that someone can gain access to Files objects they don't have access to by, for example, getting someone with permissions to edit a task they wrote (by including a reference to that file which gets "activated" when the person with permissions to view it saves the edit), which makes the file accessible via the task description.

Upstream-T13683

IMPORTANT: This release mitigates a severe security issue which allows attackers with few permission to gain access to files they can not otherwise see. All installs are strongly advised to upgrade.

In T15094#2292, @speck wrote:

I did not think we had Harbormaster set up to run unit tests - I think that involves configuring both Harbormaster and Drydock, and possibly Almanac which I don't think anyone has done.

I'll go back and review those Harbormaster file changes. Thanks for pointing that out!

In T15094#2281, @dcog wrote:

This would be a legitimately good exercise to try and do "properly"... although, the thought of not doing it optimally can be a bit of a barrier to starting..

Given the edge cases outlined in T15094#2279, would there be cases in step 2 (or 1?) from T15094#2259 that might benefit from Git cherry-picking? @golyalpha, any thoughts on that? I nearly never have to use cherry-picking, or maybe I should, but either way I'm not very familiar with it other than I'm wondering if it may be relevant

After some reading I'm finding that, as far as I can tell, it's not designed to pick/integrate *specific lines* from a diff, but rather a specific whole commit (from any local or remote branch most likely).. if I'm understanding it correctly

But, perhaps, it could still have the same effect as removing lines from one, and keeping lines from the other when grabbing specific whole commits

The more I think about this the more I'm confusing myself, but hopefully some fraction of this makes sense

If we merge, a force-push should not be required - unless you mean something other than standard git merge here. (Force-push is required when rewriting already pushed history - git merge simply adds a new commit that applies the changes on top of the branch)

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.

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

Alright, I've just went through a similar process - they apparently have changed their process a little but there still is a form to fill out: https://support.microsoft.com/en-us/getsupport?oaspworkflow=start_1.0.0.0&wfname=capsub&productkey=edfsmsbl3 (you need a Microsoft Account to fill it out, but they'll contact you on the contact email you give in the form)

Obviously spam.

Reordering milestones is convenient when you want to treat milestones as workflow steps rather than sequential numerical versions.

Since all changes are going to be submitted to the upstream prior to landing here in Phorge it would be easiest if changes were made to a clone of Phabricator and not a clone of Phorge.

epriestley was very much against this idea but wikimedia's users loved it.

In T15080#1970, @speck wrote:

Unfortunately this type of issue is in an area that's beyond my network/configuration experience. Is CloudFlare our NS provider?

What you're talking about is more like mTLS (mutual TLS), that's not actually how WebAuthn works. (Though supporting mTLS for sign-ins might also be something worth looking into)

We should definitely focus on implementing WebAuthn, as that allows us to support almost every standard hardware key solution out there.

Another one popped up: https://we.phorge.it/p/seo-auckland/

I had experience with emails from my self-hosted mailserver not reaching Microsoft-hosted mailboxes. As far as I remember, their SMTP replies to "suspicious" mail servers with a message that includes a link to some sort of a form which the mail admin should fill out. That worked for me - might need to dig through the server logs to see the link though.

Might be worth it having the linter classes inherit from a language-specific class that would handle things like environment initialization and dependency installation.

Checking the source in Arcanist repo, it seems like none of the python linters are actually configured to use an interpreter. (If I attempt to specify one for Pylint anyway, it fails with Got unexpected parameters: interpreter)

Right now,arc lint doesn't really allow for the activation of a virtual env. That's okay when I'm just running arc lint locally, because I can just activate the environment myself and run it in that environment.

Hmm, yeah, looks to be something with how Firefox renders sites... Can confirm that reload fixes the layout.

Well, there are inconsistencies. For example, subscribers are called "spies" in the task overview, but "subscribers" in the task history, and "spies" again in task actions.

It's a 720x1440 device, which is on the low end of screen resolutions nowadays.

In T15033#1516, @gadgetsteve wrote:

@golyalpha As my current employer is one of the largish companies, (50,000+ international employees), but not primarily software focused we have all been given GDPR awareness training but do not have a general, all employees, GDPR statement available nor a standard text or set of texts to use.
When I was deploying a Phabricator instance I actually had to come up with the wording myself and then get it approved by the legal & compliance team - my biggest hurdle was convincing them of the required data retention period - they were much more used to systems such as payroll & HR where records are only retained for a fixed number of years after the period of employment as demanded by things like the local tax regulations and the idea that due to legal liability, etc., we needed to retain the information for the full life of the product being developed and possibly beyond if components were reused.

I18n is also fairly important from the point of view that citizens in certain jurisdictions are basically legally immune against documents written in a language different from the official language of their jurisdiction, so, +1 on that.

Yes, that's why I'm saying "yeah, great idea, let's do this, but let's also create a config toggle so that it can be disabled for people and orgs who don't need it".

Yes, the GDPR notice must inform about each and every purpose specifically. But it must do so only once - that can be at sign up.

It's not just visual - I'm actually unable to open the individual tasks.

+1 to removing default.pem
/shrug on keeping custom.pem

What was the original rationale behind shipping a certificate bundle with Arcanist? It may be better to rely on the system certificate bundle instead (that also tends to have certificates from, for example, internal company issuers as well).

A perfect example of "hard to see" things in dark mode

Definitely a good idea for anyone who wants to run Phorge in EU/UK or work with EU/UK contributors. Though it really is only necessary for the signup page - individual repositories really only have to worry about CLAs (if relevant).