We ran the script provided above to get an audit of at-risk files. Afterwards we upgraded our instance and the upgrade succeeded however its attempts to delete the affected files failed. The failure is due to using a local file store which is accessible to our web service account but not the phabricator phd services account (T4752). After correcting the file permissions so both accounts have appropriate access, running upgrade again doesn't seem to remove the files.

It is likely that the vulnerable code predates significant portions of the Files and permissions systems, and was just overlooked as these other systems upgraded and gained more powerful policy and permissions capabilities.

The fix is now available on master (rP7626ec0c) and stable (rP6f879559). I've upgraded this install without incident. Per above, note that upgrading destroys evidence, so you should plan any audit or response actions you want to take before upgrading.

I've implemented the sudo approach at some point - P2016 - and I think it worked alright.

I didn't "ref" it here, but D17401 sort of technically did this. I'd like to clean it up a bit more before calling this resolved, though -- particularly, this is basically a secret that only I know about.

Removed apache settings:

<LocationMatch "\.(?i:os)$">
    ForceType application/octet-stream
    Header set Content-Disposition attachment
</LocationMatch>

I think that the problem is the content itself. This is evident by thumbnail fails to be generated when the second one is ok. On my OS/browser combo (Gentoo/firefox) first video loads very slowly while the second is perfectly ok. On Chrome first video refuses to load.
After downloading and testing locally, everything is fine. My guess is that chrome and firefox can guess proper values for decoders for "normal" video, while for "weird" video firefox tries it's best and chrome just gives up.

Yeah, same here. Both videos are of similar size (1.6MB vs 2.1MB) and both appear to legitimately be MP4 / H264 videos (neither is some kind of obviously spooky magic like an AVI named .mp4).

I can't play the top one in safari either

Here's what I see in Chrome at time of writing:

We need a neologism for "bad workaround".

(A "workaround" is to not use dashboards, but we'll fix this soon.)

Ah, cool -- thanks!

See T12174 -- this is an issue with the new embedded-on-Home dashboards.

They are not related. That search uses fulltext indexes (see T11922 / T11741 for recent discussion), not ngram indexes.

I don't think this is quite the same issue, but seems related, so I thought I'd err on the side of not creating a dupe.

Obsoleted by upstream changes.

Can't reproduce this - assuming fixed?

From elsewhere:

https://mozilla.github.io/pdf.js/

Ah I totally missed the F1234 being in the lightbox already. And I did figure that using 3rd party code to render PDF would be out of the question. I don't really know what the current state of PDFs in browsers is so I had my project manager hat on for that question~

• I don't think that's a lightbox bug, just a general blog bug.
• To be fixed.
• If it's native? We won't be adding third party code for this.
• We added F1234 to the header of the lightbox for resharing.

Woo came here from the blog. Just a few notes so far:

1. The lightbox on the blog doesn't seem to show anything under the Comment pane even though I should be logged in (to admin.phacility.com). Or is the blog.phacility.com completely isolated/separate? These were errors I got in Firefox console, which I don't get when using lightbox on this instance.
   • Error: JX.$('phabricator-help-menu') call matched no nodes.
   • XHR POST https://blog.phacility.com/file/thread/PHID-FILE-3ittlvgojn2326tbg22z/ [HTTP/1.1 404 Not Found 338ms]
2. I'm very used to "click anywhere that isn't the image to close the lightbox" behavior. My personal preference would be to maintain that when clicking on any empty space outside the image/file. I think this is due to where my mouse is located when I click the image (towards center of screen usually) and where I would go to click to close (in most cases just slightly down vs. top right corner). But then I use a trackball so...
3. Is PDF preview considered? PDFs were specifically mentioned in the blog so I have to ask~
4. (Maybe not totally related) Some way to easily reference the same file instance from different areas. Most users I see will continue to drag/drop the same file in different areas and not use the same file reference object {F1234} - which I'm assuming would mean two separate comment chains, etc. Maybe somewhere in the lightbox listing the tasks/diffs/etc. where the file is referenced would help understanding. Or a way to view/copy the file remarkup to be used elsewhere. Or maybe this is all T11543.

(To answer your question more directly: yeah, no way to do pht() with variables in Javascript. We can build that without TOO much trouble, but I'd like to wait for a really good use case first.)

I'd say just get rid of it, or render "X / Y" without pht()?

Doesn't look possible to do "Image x of y" in current phtize from JS... Worth adding or just changing the language? I don't have any great ideas on updating the language. Unsure x of y is useful though.

Partly, just haven't gotten there yet.

Looking through the code, looks like Maniphest doesn't use ngrams yet? Any reason?

You are right, I also can't reproduce it on the Phacility instance. I really don't know what do do next ^^

Please take the time to try to reproduce the issue on a Phacility instance, and report back if you can. We have not been able to reproduce the issue with these set up steps. Reproduction steps must includes everything we need to review and fix the issue locally.

No, there's no specific support for LFS mirroring yet.

This doesn't add any compatibility with mirroring, does it?

The driving install dropped off the grid a while ago, so this is no longer prioritized.

I'm going to merge this into T11357. We can provide a "Delete File Data" transaction type when we implement a third-generation file.edit API.

T11774 wants a "delete file data" transaction, which is reasonable.

This is working as intended, and not a bug. Administrators can not bypass policies. See the User Guide: Account Roles documentation: