I also think it would probably be reasonable to do this:

I generally don't think we should support this, and installs which have complex .arclint requirements should instead write a script which builds .arclint for them. If you want 5 files with a bunch of variables in them: write bin/rebuild-lint.py or whatever, have it merge the files and do variable replacement, and dump it to .arclint. This script is probably 10 lines long and can do exactly what your environment requires.

My general thoughts are:

Just to make sure we're on the same page, here's the expected behavior:

You can do this with arc upload. Is that sufficient?

The only important key we have which is active outside the cluster (production host identity key) is now separated, and deployment credentials have been made fully separable. (SSL keys are also active outside the cluster, but deployed manually at the moment.) We can improve segmentation here over time, but we're in stable shape now.

This is implemented and deployed.

Basically, target 90% of the use cases with the settings panel and let Herald fill in the "I want to put email about this specific repository in a special folder, if it's an accept or reject and the author isn't in project Y" stuff.

I'd maybe want to pare down the options we have right now to simplify the UI a bit, but I imagine keeping them more or less in their current form and letting this just serve the power use cases.

Yes, but it would stop all users from ever receiving those emails, not default them off.

After some thinking about this and T6309, I'm leaning toward building Herald rules for outbound mail, so you can write proper mail rules in Phabricator if you use Gmail or some other client with a low-power client-side filter.

The workflow also fails closed (i.e., puts the application into a state where there is too little access rather than too much) and bin/policy unlock allows the mistake to be fixed relatively easily, both of which serve to reduce the importance of preventing mistakes like this. But the major issue is just that we've seen very few users make mistakes that involve locking themselves out of objects they intended to retain access to.

It's normal/expected to sometimes leave projects and be unable to see them afterward. For instance, if you're on the "Security" team and then you switch teams internally and join the "Frontend" team, you might leave the "Security" project. That might prevent you from seeing it anymore, but that's fine, and you expected that to happen when you left the project.

Because policies can be complex, we can't always prevent mistakes like that. For example, a policy may depend on some external source of truth, which changes independent of any actions in Phabricator and accidentally locks everyone out of an object.

oh right this stuff isn't in config

Pretty sure D11904 fixed this.

@btrahan's answer is more complete than mine, I omitted setting "Joinable By".

To restrict add/remove users to one person:

In particular, if users who could edit the project could not edit the membership, they could still edit the "edit membership" policy, then add themselves to it, then edit members. "Edit Project" necessarily trumps all other edit policies.

with the darkest corporate goals

we are the evilest corporation

Rainbow logo was pretty fabulous.

Yeah, repros in Safari too, we just have the wrong link happening.

Clicking "Download" is expected to set Content-Disposition: attachment and force a download. We're probably either pointing the button at the wrong place (likely) or Chrome has gone crazy and no longer permits/recognizes this (unlikely).

Making the deploy.key available in order to make the other production keys available will take a bit of work. I think we have to pick it up as a side effect of deploying through the bastion. I was originally thinking I'd just lock to the cluster range, but the visible remote address won't be on the VPC.

Broadly, I'm not too concerned about the efficiency of pushing too excessive updates: the big advantage to always writing the entire correct state is that for a large class of bugs, we just fix it and move on and the dataset self-heals without an invasive migration. But we obviously shouldn't be deadlocking.

Another user (ki9a) hit this in IRC too, off API calls, with this trace:

Kicking this off Phacility 'cause it's just normal roadmap stuff.

I'm going to kick this off Phacility, since I don't think it's really a Phacility task (except maybe for monitoring, but that needs other work) -- yell if I'm missing something. We can drive this forward whenever, though.

• Users can disable instances, which is the same thing as canceling a subscription from a user perspective.
• All this other stuff we don't care about for a long time.

The urgency of fixing this is dramatically reduced by Almanac being a prototype and installs not having access to prototypes so this can be punted to the horizon.

Something changed an origin URL for me locally, but I can't figure out how it happened so it might have been a fluke and/or me being dumb.

Yeah, we specifically plan to make changes in this vein eventually:

You can use file.info from the Conduit API console to convert a file ID into a PHID, but will likely have to go to the database for the caching stuff in T4214 anyway.

bleh ugh yeuch

You have to bin/phd stop <only the second overseer PID>.

There's no way an over-overseer can know when the previous reload is finished

Maybe this is a misread, but it sounds like you're pitching your consulting services without really knowing anything about Phabricator. It's open source; if you have questions about the implementation you can look at the source code. If you identify vulnerabilities, you can submit them through our HackerOne program.

Cross site request forgery (CSRF) attacks specifically take advantage of persistent session tokens and use them to take action as the user that was granted the token.

In general, if your organization has a well-meaning policy or compliance guideline which mandates a behavior, but the behavior is not actually desirable on its own in the absence of the compliance concern (i.e., in practice, the mandated behavior is arbitrary), we are very unlikely to implement support in the upstream. We recommend you:

At least in Chrome, you can enforce a session-only cookie policy in Settings > Advanced Settings > Privacy > Content Settings > Cookies. But, as far as I can see, this is entirely pointless for session cookies.

Can you walk me through the specific concern? It seems misguided to limit login session cookies for privacy reasons: to get a session cookie, you must uniquely identify yourself to the server and prove your identity. We necessarily know who you are because the entire purpose of a login session is to prove that.

T7390 has another compliance-driven request.

(And I suppose I should have filed it against meta.)

This was resolved elsewhere, but probably won't push until Monday.

Make sure that ALTERing a binary collated column which contains utf8mb4 characters into utf8 column succeeds with --unsafe.

This is relatively simple to fix, but we need to:

Queuing multiple graceful exits just isn't a use case we're going to support in the upstream. You can conceivably have your over-overseer decline to send the second SIGINT if an overseer has already been SIGINT'd once. bin/phd stop <pid> --graceful ... can send the signals selectively. I'd maaaaaybe accept a bin/phd status --json since parsing bin/phd status is a bit of a mess, but the other tools to build this already exist.

@cburroughs: Thanks for pulling that data, it's reassuring to get some level of confirmation that my idea of what an "average" install size is isn't too far off.