See PHI2090 for another report of this. Chrome hasn't changed behavior since the last update, so I'm more inclined to look at workarounds.

A point against AllowEncodedSlashes Off which I hadn't connected the dots on is that "security researchers" from HackerOne will report URLs like this as "content injection vulnerabilities" for all time:

It may be doing it that way to avoid the possibility for missed timer overflows?

In T13652#255834, @epriestley wrote:

I'm starting with an absolute bottom-of-the-line 3018, I've "upgraded" it with a plotter collet I made out of a pool noodle and a piece of cable gland so I'm less likely to hurt myself for now:

So far, I've mostly been implementing controller software, following heavily in the footsteps of GRBL. I think I'm maybe ~25% of the way toward having a similar-ish capability set? But I don't really know what I'm doing, I am doing a few things a bit differently, and haven't written any meaningful amount of C in many years, and suspect I may run into a wall with the CPU.

One thing I've changed is that the computer tells the board what hardware it is connected to at startup, e.g. "Linear Stepper Axis 1 is enabled by pin 8, driven by pin 2, and direction is controlled by pin 5", since I'd like to be able to rewire the board without updating the software, and generally have more control over the hardware configuration, and have an arbitrarily large number of axes and actuators and blinking lights and whatnot. My motion commands then reference axis IDs ("2D linear motion on axis 0 and axis 1 to relative position 15, 35") instead of spatial axes like "X" and "Y" directly.

I'm starting with an absolute bottom-of-the-line 3018, I've "upgraded" it with a plotter collet I made out of a pool noodle and a piece of cable gland so I'm less likely to hurt myself for now:

Now that I realized this isn't an April fools joke (or if it is, it's kinda late...) anyway I have a whole lot of experience in this department, having built several cnc controllers. My latest one is using a beaglebone black but I also experimented quite a lot with an arduino running grbl and another one running on a $30 esp32 board. If you have any unanswered questions I'd be happy to comment. I should have slightly better than ignorant responses.

lol

The digestWithNamedKey() issue above generally impacts anything using immutable caches, so it can affect CSRF too.

• This is far afield from any application I have today, but it seems plausible to operate a small-scale DIY plastic foundry (Ref) that converts plastic waste into blanks for machining or injecting into machined molds.
  • The cost to just buy premade plastic blanks doesn't seem particularly high (roughly comparable to plywood?) although I know nothing about plastic qualities.
  • Unsurprisingly, it seems like the market for recycled plastic material doesn't have a lot of DIY buyers (unit sizes are often: 1,500 pounds; per metric ton; per 40,000 pound truckload; "*Only Quantities of 10k lbs Plus").
• There are a handful of people doing extremely high-precision DIY EDM machining (Ref).

Hmm okay that might only take effect at the time of making commits, though I've run into other issues where phabricator/arcanist fails to parse the contents of a commit message and forcing it to interpret as UTF-8 via --encoding utf-8 in the mercurial command has worked.

I don't think HGENCODING applies to the content of changesets, since that would invalidate the changeset hashes and the whole revision graph with it.

To clarify I think having the environment variable set as HGENCODING=utf-8 would be a possible solution/workaround.

I have not tried this out yet but mercurial claims to respect an HGENCODING environment variable (https://www.mercurial-scm.org/doc/hg.1.html#environment-variables). It's possible that setting this on the phabricator server might fix the issue by affecting any hg commands run by phabricator. Note that the environment variable would need to be set/exported for both the system user account which phabricator web server runs under (like httpd or nginx) and the system user account which the daemons run under, as they both run mercurial commands.

Is this workaround now the recommended way to deal with this issue / ever going to be merged into the code base?

ran generate_sprites.php

This issue is still occurring.. the root cause is related to phabricator being set to allow-public. My fix still works and it would be nice if anyone here would support me bringing this upstream.

Yes. I closed down registration on this install (secure.phabricator.com) several years ago because the overwhelming majority of users who registered accounts here didn't read or follow the rules. Access to secure.phabricator.com is now invite-only.

In T13589#254320, @epriestley wrote:

Please use Discourse to report bugs.

Ah, I think it's:

(This might need to be sprite-sheeted too, but I think the sprite stuff hasn't been used in years -- since we switched pretty much everything to icon fonts -- and don't remember exactly how it works. I can look into it and do the actual bin/uh-generate-a-sprite-sheet or whatever in a followup.)

Thanks!

tweak wording

One call to for-each-ref comes from resolving a list of commit hashes, to test if they still exist. This is accomplished with DiffusionLowLevelResolveRefsQuery, which calls git for-each-ref first and falls back to git cat-file --batch-check.

Has this repository changed?