(Of course, it'll probably just work the first time now...)

The export process is already robust at a coarse level: the dump is retained on disk and the process can be retried at the "upload the whole file again" level, then picked up with bin/host export using the --database or --database-file flags (probably with --keep-file).

The (anonymized) error the process encountered occurred while transferring the dump to central storage was:

There are some remaining non-security bugs with this that I'll follow up on in T13682. I believe the security side of this is now resolved.

The details of this attack will be disclosed at a later date, once installs have had some sort of plausible chance to upgrade.

I filed T13687 as a followup for preventing this particular sort of error (where a Phobject is incorrectly serialized directly).

That's very likely the same problem, and I think it should be fixed by updating to the current stable (rPf2a7db1 or newer).

I believe we may be hitting either the problem one of the above commit fixes, or suffering from a similar caused as side-effect from it.

...ideally this sort of thing should fail loudly at serialization time...

Resource (and Phame and Phurl) domains now respond to /status/.

This promoted without exploding.

These contexts are covered:

See one followup in T13326. The "import from disk" part seems to have worked properly in production.

In T4752#177071, @cspeckmim wrote:

setfacl -Rdm u:phab-phd:rw /var/local/phabricator/filestore
setfacl -Rm u:phab-phd:rw /var/local/phabricator/filestore

We no longer offer support for this kind of problem (that technically has reproduction steps, but is sufficiently involved to reproduce that no one has time to follow them, e.g. build a new server from scratch with assorted specific software versions).

Thanks! I was able to follow your steps to reproduce this and verify the fix.

Note that the lints and unit tests do pass on my end. I used the "Create Diff" action to do this instead of arc diff (which was silly of me)

Can't wait for "connect 2" to come out on playstation six.

I like that reasoning a lot better than mine, and simply omitting type appears to produce the correct behavior in every browser, at least for this file. I'll try that instead, and we can revisit this after we write a video transcoder in PHP and can offer files in multiple formats.

My knowledge is centred around broadcast video / IPTV (UDP multicast) rather than HTML5 video, but that seems fairly reasonable. I don't think anything should try and download the file twice unless it is a complete clownshoes implementation that probably has multiple other serious bugs wasting bandwidth. I think the worst case with no type that might be hit here is that the browser could decide to download the entire file on load to figure out the format and duration, rather than starting with byte-range requests, but this is easy to test and unlikely (I'd expect any sane one to always request chunks).

I can imagine that two <source /> tags might, in some bizarre world, cause browsers to download the file twice when you click "Play", if they're super confused about how to process videos, don't notice that the URLs are the same, and don't hit any caching. But that's a pretty minor bad effect, and I didn't immediately see any kind of bad behavior locally.

Thanks! I wouldn't mind parsing that but I'm hesitant to ask installs to install it -- but it's helpful in understanding that I'm not completely crazy here and that there's at least some basis for "video/mp4" being a quasi-legitimate way to label the video file.

mediainfo is the tool for this, but is really overkill for programmatic use.

One easy approach we could take is just:

From PHI604, for completeness, on the newer behavior of "Hide Blame":

validation for the configuration option

See T13125 for a more detailed breakout of coverage plans.

This particular page here is fataling:

• Source view rendering in Paste has a missing background color.

Still needs work:

• The secret $1-2,7-9 syntax for highlighting multiple noncontiguous blocks of lines in Diffusion is no longer supported.

• If a file is non-UTF8, we should try the repository's "Encoding" as a default (or maybe just remove this feature).

Junk I'm about to break in Diffusion (but plan to restore):

Changeset rPfb4ce851c4ae: Add a PDF document "rendering" engine allows to view PDFs from the Files application. However, {Fxxx, ...} references to a PDF file in Phriction still only allow to download the file or open a lightbox with only an icon (again with a download link).