This seems to impact mail deliverability to @icloud.com addresses too.

Is the extension still maintained? While there is no extension store yet, it's possible to host repositories here. https://we.phorge.it/w/docs/extensions/phactory/

In T15872#18251, @valerio.bozzolan wrote:

About this:

unset LC_ALL + LC_MESSAGES=C

I think it's not safe since other LC_STUFF can still be read 🤔

This [LANG=C] is supposed to be the default for missing LC_stuff

LC_ALL=C is not risky on GNU systems.

https://unix.stackexchange.com/a/87763 is also a useful reference, specifically:

Could be related to https://we.phorge.it/T15036. A short automated email containing a link to another domain is suspicious in the eyes of a spam filter.

Should the summary also include https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel/preconnect as a reference? https://developer.mozilla.org/en-US/docs/Web/Performance/dns-prefetch doesn't mention preconnect in the first few paragraphs, so it's somewhat confusing.

Any update on this? I don't think iCloud has a spam filter as strict as what Outlook has.

Thanks for the reminder!

Update comments

id, vs and /new/ in URL all affect content of the generated file.

In D25478#13957, @speck wrote:

What do you think about keeping the current naming scheme but whitelisting a handful of query params to use instead of using them all? The timestamp adds noise and it's probably nice to see the ID of the diff in the filename, e.g. D25478.id1541.diff? Maybe just allow the the id parameter and regex that it's value is just a string of numbers.

Should this be configurable and behind a feature flag, as some Phorge installations may not want this (plus may slow down performance a little bit)?

@avivey Nope, it's an icloud.com address.

In D25467#13453, @valerio.bozzolan wrote:

Uh! Nice!

Interestingly this CSS change only has effects on Chromium 119 and it does not change anything in my Mozilla Firefox 118. Can you give a quick look?

This is related to https://secure.phabricator.com/T13546. "classic" Arcanist workflows were being upgraded to Toolsets, but the migration was not complete. See comments starting with TOOLSETS: , e.g. in ArcanistConfigurationSource.php.

Phrasing

In D25464#13372, @speck wrote:

This will require documentation of some sort, specifically for the upgrade notes to indicate that if someone relies on rendering PDFs currently then after upgrading they would need to update that configuration.

I think making a task to document the issue and linking in the release notes would be a good approach and what upstream would typically have done.

In D25464#13328, @speck wrote:

The Referenced Files section of this diff looks like someone is looking for a vulnerability. Any idea what’s happening here?

arc diff throws an error and arc land ignores it. Instead of getting it to work with Differential, I'm amending the commit manually with git commit --amend -s after arc land --hold.

Update commit message

Update config description

Mozilla's fixes were quick but not in good quality for direct submission to Phorge. I have adapted or rewritten two of the changes into D25462 and D25464.

Before landing this change, I would like to know the right way to credit both the original author and my modifications with Arcanist (Q85).

Reword

@valerio.bozzolan If you didn't get an answer, try asking in #conduit. I didn't realize that # needs to be quoted in Remarkup. 😢

@valerio.bozzolan Upstream removed code that enforces $always_visible when $file->getIsProfileImage() is true in PhabricatorFileQuery.php, but I'm afraid that this change may break other things, so I did not apply it here, but on the other hand kept the description of "Image will be Public".

Mention upstream commit

It would be great if Mozilla's team could join forces with Phorge. Would you (the core team) contact them in #conduit on chat.mozilla.org and mozilla.slack.com?

Fix lint warnings

I have reviewed it and made some comments. On a remotely related topic, TLS handshakes are expensive and persistent connections can reduce latency and server load by reusing TLS connections, so maybe we should make it configurable outside of cluster.databases as well.