phage remote status --pools db,repo and such work now, using Conduit credentials from the bastion to query admin. We can swap that stuff later if we want to switch to EC2.

Come up with a plan for where phage --pool repo is going to get the host list from.

Good to hear, thanks!

If anyone actually has bona fide Excel.exe installed, you could try opening this file to double check that we're not currently vulnerable:

I think I disagree with this but I want to be sure about what you're saying.

If we stop generating internal IDs from instance names, I think we should pick a generation scheme such that they can not ever collide -- backups/ErrantAnalyticalGiraffe/ on disk should never exist and be a different instance than ErrantAnalyticalGiraffe.phacility.com in the web (technically these namespaces are different today because you can not use uppercase letters in an instance name, but that feels very flimsy as a dividing line).

Another adjacent piece of work here is automating provisioning (e.g., through autoscale groups or bin/provision) but I think we should mostly leave that for the future too since we're theoretically bringing up only one new host (or maybe two, natXXX + repoXXX). Many of the other changes here give us tools toward that anyway, and it would probably be better to pursue that as part of a future change that involves launching a larger number of new hosts (e.g., chassis swap on the whole tier).

I plan to take these steps specifically:

@amckinley, I'd like to try to do this as part of T12798. Here's my rough understanding of what we need to do:

To summarize where we've ended up:

The general shape of the change is reasonable. However:

Thanks for updating your report with reproduction instructions, they were very helpful in reproducing and fixing the bug.

D18069 appears to fix this, but I want to understand where it blames to and possibly pursue a more graceful fix since D18069 feels a little flimsy.

Arguments against:

If you want to type sequences like O2 without triggering remarkup, you can:

We haven't received more information on this, so we don't know how to reproduce it and can't move forward. Feel free to file a new issue in the future with complete reproduction steps, per above.

We don't know how to reproduce this, so we can't move forward, and haven't received more information in several days.

We don't know how to reproduce this, and haven't received more information in several days.

This appears to have been resolved by D18042. I'm letting the mail stuff fall by the wayside for now.

I can't reproduce this at HEAD, so presuming this was resolved by rP7b290b94a7.

It's possible that didn't get everything, but yell if you hit anything else and we can shovel on some more test cases. Thanks for the report!

This is still not working very well for me in Safari in production, although I don't seem to be able to break it in Chrome or Firefox anymore after a few tries.

There may also be a similar attack possible by adding address in local network space as a JIRA install, outbound HTTP hook (unlikely a problem today, but maybe in the future), Phabricator OAuth install, LDAP server, etc. Today, we're generally balancing things as "by default, it's OK for administrators to register services in local network space".

Harbormaster and Diffusion do not use the outbound blacklist, since it would prevent users from interacting with local-network build hosts (for example, a local install of Jenkins) or local-network repositories (for example, a local install of GitHub Enterprise). We currently consider these use cases to be common / valuable.

In practice, every paying customer who has ever asked us about SAML has wanted to use OneLogin as a SAML provider. OneLogin's breach does not imply SAML is bad; it implies OneLogin is bad. For paying customers who are interested in understanding our stance on SAML support, criticism of OneLogin is materially relevant because they all want to use OneLogin.

Why do you believe I haven't performed a serious technical evaluation of SAML?

Why did you think that a sarcastic, condescending comment was the best way to convince me to reserve judgement?

@siepkes, what are you hoping to get out of making that comment? How do you believe it benefits you?

@lvital, I can only reproduce this if use "Weak Dominion". Is that the case in your example, too?

This transaction uses shouldHideForFeed(), which isn't currently supported by Modular Transactions. It got swapped over in D17844 or some related change and we didn't catch that the logic wasn't firing anymore since this is a bit of an obscure case.

More on SAML:

Thanks, this reproduces here for me.

(This is still on my radar.)

I believe this was fixed by 7b290b94a726f7c9eb3efd9e065499fde1b0ad00. Are you 100% sure that the image was updated after that change?

Use tsprintf() ("terminal string print formatted") instead of phutil_console_format():

But most of all, it shouldn't depend on ... any bloated framework. That's why clipboard.js exists.

Sorry I guess it is 5 lines:

I super hate that feature but it looks like it's literally three lines of JS. How does that repository have 18K stars? This is like left-pad v2.

Yeah, I think we get even more design leeway here if we do T9713 and the actual commit page becomes less of "big blog of poorly aligned text" and more "list of revisions, tasks, diffs, builds" + "option to view raw".

(I've got some kind of family thing going on myself so I may not be around too much longer tonight.)

I think the link to the revision is probably the most generally useful piece of information, but we could replace this:

You can just click the commit title to get to builds/diffs/etc. GitHub has no direct link to builds/tasks/issues; GitLab has a direct link to builds only.

The "Browse" buttons also don't actually do anything right now, but probably don't need an icon.

we have icons

What if we just removed the icons completely?

I don't think any icon is ever really going to say "Revision", "Audit", "Lint", "Build", "Task", "Commit", etc., no matter how many fancy illustrators we hire.

Without changing the design much:

Also: one of these commits has an important build failure, can you find it in less than 15 minutes as a user with poor color vision?

I think that got things closer but we aren't quite there yet. I'll poke at this a bit more tomorrow.

Possibly fallout from T11784 / D17911, although those shouldn't really interact here unless there are other bugs.

For pulls (vs mirrors), we switched to ls-remote to detect no-ops in D17497. The primary motivation was to let us make better clustering decisions, but it also "appeared" to improve performance, which suggests that it may not be outlandish to imagine that git ls-remote would use fewer resources here as well.