Oh, you removed openTransaction(), so that's probably not the culprit.

It's vaguely possible that openTransaction() is the culprit. applyPlan() queues a daemon task, and I could imagine the race might be:

It sounds like this no longer reproduces for you.

• If the changes are relatively minor, add a bunch more #ifdefs? We already have some of this to deal with prior API changes, and I believe this approach is historically a standard one across other extensions.
  • If the changes are substantial, maybe we need to get more creative.

If you want to test that something in this vein works, I'm happy to bring it upstream.

We should be able to just omit the final argument if remote is not specified. We can refine that later, but our usage seems like it's in the wrong to me.

If a Phurl doesn't have a name, should we still show the empty name property on the object view?

I can't immediately reproduce this. Here's what I did:

The default value of metamta.email-body-limit is 512KB. Does your server reject 512KB messages, or have you raised this limit, or do you expect 512KB messages to send cleanly?

cdda79e9 is not a commit in rARC or rPHU, and the last commit to libphutil was on 12 Nov (while that output shows a change on 13 Nov), and it's impossible for both libraries to have the same commit at HEAD. Is he running a forked version of arc with local modifications?

What version of arc does the user have (per arc version)?

If you have long-term local access to a user's machine and can install a keylogger, you can just steal the session cookie. Being able to establish a second session instead of stealing the first session cookie is not a meaningful escalation.

Maybe adding --trace will reveal what's going on?

We apply a Space constraint when executing this query and the object never makes it as far as the application. This is broadly by design, as it hugely improves the scalability of Spaces.

Your HTTP request should start a build, it should not wait for the build to complete. See:

Never mind, this was straightforward to reproduce:

This should be fixed at HEAD. Let us know if you run into anything else.

Do you have a stack trace in the error log offhand? I can't immediately reproduce this on this install after upgrading. I have a good idea what's going on, but if you have a stack handy that might be faster.

It looks like this database did exist as of D3659, but the name was mistaken (pushed as xhpast, should have been xhprof). It was renamed in D3670.

The Sendgrid v3 API does not currently include an API method for sending mail.

This install is just a little out of date, second issue should be fixed at HEAD.

I was able to reproduce this easily by following your instructions. We'll get this fixed. Thanks for the report!

I'm partly just guessing here but I think It's almost certainly my fault.

File should be getting attached to the paste, but isn't. I think I accidentally caused a side effect here when changing how the transaction works.

User Guide: Prototype Applications

(HTTP over public wireless has those properties, but using MFA and not using HTTPS is silly and the lack of HTTPS is a far greater problem than the larger MFA vulnerability window.)

could MITM the connection between the verifier and prover

There are some attacks that could be performed on such MFA schemes but that are not applicable in phabricator's security model.

I think the RFC should be followed.

I can't reproduce this either, nor does it reproduce on this install.

I'd like to understand the reason behind this before moving forward.

I don't want to introduce this level of complexity into Herald.

Is there a specific security purpose behind this? That is, what attack is this measure aimed at defusing?

Just to clarify, you would rather rely on an external script to activate and deactivate this rule every day instead of having a Herald condition like "Current time is between 5PM and 9AM"?

I don't plan to support this in the upstream. This configuration is inherently dangerous because the custom application has access to Phabricator's cookies, and not one we recommend.

You should be able to batch edit infinite tasks.

Right, Almanac does not support autoscaling. We'll have an EC2 blueprint (and similar) in the future which can manage autoscaling more simply. Almanac is the ground level "I have a list of IPs" version of things.

bin/almanac register is just a shortcut for "put the private half of a key in the right place on disk, and the public half on the specified Almanac device". Maybe a clearer name would be bin/almanac install-keys.

This just means adding a device interface?

Right. You just need to:

Don't do steps (3) or (4)! Those are useless at best, and dangerous at worst.

• The view page doesn't actually show the short URL anywhere. You can copy it from "View URL", but I think this isn't totally obvious, and we probably have enough room to reasonably add it (e.g., "Short URL: ..." under "Original URL: ...").
• If a link has an alias, "View URL" still links to the non-alias version (e.g. U6 links to /u/6, but a more-preferred link would be /u/bug).
• The "Remarkup Reference" document (https://secure.phabricator.com/book/phabricator/article/remarkup/) should explain how to use ((6)) and ((bug)). It might be worthwhile to hint these on the U6 page itself, e.g. In Remarkup: ((bug)) in the properties? Not sure how useful/cluttered that would look.
• Maybe show aliases on the list at /phurl/?
• Maybe let users search for the link with a particular alias? If I know ((bug)), there's no way for me to actually find the URL object right now. Hovercards would be one fix but just going to Phurl and being able to search for "Alias: bug" is probably good too.

This also seems to work properly on this host, although I hit the "daemons are not running" setup warning once, presumably by racing their restart. If this is an issue we can tweak how that warning works, I think.

Oh, transaction publishing from Phurl also currently fails in the daemons:

One possible minor followup to maybe keep on the radar is showing some extra warnings in a few cases:

A couple of notes so far, after poking at this:

The resolution of T7053 should indirectly resolve this.