As far as pulling this state from EC2, it's really easy to fetch the list of hosts that have a given tag: http://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instances.html

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

Good to hear, thanks!

Checked on Excel 2016 and it didn't run calc.exe or prompt for "update cells". Also checked on Excel for mac~

Oh, I see what you're saying. Yeah, whatever logical naming scheme we come up with, we should block that pattern for display names.

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

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).

FWIW, I'm heavily in favor of the "display rename" approach, and allocating logical ids like ErrantAnalyticalGiraffe. Breaking the coupling between instance display name and its backing resources is a band-aid that will only get more painful to remove after we launch private instances.

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.

@epriestley I know you've said no on accepting a patch for this one, but we've found that without the "author" field sent to Buildkite it's not very useful.

I have added some more details. Let me know if you need any more.

Ok sorry, I will improve the report.

Specifically we need steps to reproduce the issue. I don't know what "the pages" means, or where you expect an edit page to be found. We have lots of applications and fields that URIs could be in.

Please read and follow Contributing Bug Reports, we don't accept incomplete bug reports.

Nevermind, found another task. Thanks!

Does this reproduct against an up to date version of Phabricator?

Slightest of issues with the repository indexing mentioned above:

luca:~/phabricator$ ./bin/search index --type repository --force
Usage Exception: Type "repository" matches multiple indexable objects. Use a more specific string. Matching object types are: PhabricatorRepository, PhabricatorRepositoryCommit.
luca:~/phabricator$

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:

Thank you for the helpful summary. The Discouraged creative solution worked for me. I expect this will be a one off, if it is not I'll try and setup some ignored phrases.

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

I was trying to type the phrases "visible within O2's network" and "the O2 SIM card" but something is interpreting the company name as markup. I could type "visible within O2's network" but that seems a little odd. Is there a better solution for this off edge case?

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.

Same here with a german umlaut ("ä") in the file name.

Please how can i download it

Aha! That works wonderfully. I think this is INVALID, then.

i'd like to remark that this ticket is supposed to be about perhaps u2f or other direct hardware security, not saml, and thus i've had to unsubscribe from the recent back and forth :)

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!

Thanks for the fixes! Most folks are on Chrome at Dropbox, so Safari being subject to the Heisenprod Uncertainty Principle doesn't worry me much.

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.

makes sense. thanks!

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.

Shouldn't this behavior be blocked by the default settings of security.outbound-blacklist? 169.254.0.0/16 appears in that list, but as you say, a Harbormaster fetch to http://169.254.169.254 succeeds as expected

@epriestley I'm not saying you didn't do a serious technical evaluation of SAML. I can't see where I might have even vaguely implied that? For all I know you could be an expert on SAML. I've done multiple SAML implementations and frankly I can't blame you for not wanting to do / maintain one.

Looks like it was deprecated a while ago, without explanation. Luckily, there's --log-junit, which we have some code to parse.

ahhhhh

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