4.2.0

4.2.0 follows 4.1.6. Mail portal accounts can now sign in with a passkey, and the website firewall's rule set can be updated from the mirror between panel releases. Two portal security gaps are closed: the portal API now answers only the portal apps, and a portal visitor can no longer choose the address the portal records for them. On AlmaLinux with SELinux enforcing, a WordPress site's own cache flush now runs through a service with its own SELinux domain.

Upgrade notes and behaviour changes​

• The portal API on 127.0.0.1:2094 refuses every call without the portal apps' shared secret with 403 (bff_secret); only its health check answers without it. The secret is /etc/hitechcloud/portals/bff.env, which the 4.1.6 update or a fresh install already made. If that file is missing or the secret in it is too short, the API refuses everything but its health check, and running the update (or hitechcloudcli portals converge) makes it. Anything of your own that called the portal API directly stops working. (hitechcloudcli#484, HiTechCloud-Panel#1806)
• The portals record the address of the connection, not what the browser sent in X-Forwarded-For. If you put a proxy of your own in front of the portals, the portals now see that proxy's address. (HiTechCloud-Panel#1814)
• Website firewall rule set updates are off by default. hitechcloudcli webfirewall rules auto on turns on the daily update; webfirewall rules update installs a newer set by hand. The shipped rule set now carries a VERSION file. (hitechcloudcli#492, HiTechCloud-Panel#1822)
• On a server with SELinux enabled, the update loads a small policy module, /etc/hitechcloud/selinux/hitechcloud_cacheflush.cil, for the WordPress cache flush service. Without SELinux nothing changes. (hitechcloudcli#489)

Added​

• Mail portal: passkeys. Sign in with a passkey, and add or remove passkeys under Settings > Passkeys (your password is asked again before a passkey is added). Passkeys use the same store as the hosting panel, the RP ID and origin come from the portal's configured address, user verification is required, cloned keys are refused, and every change is audited. Mail service accounts, which cannot open the hosting panel, can use passkeys too. (HiTechCloud-Panel#1819, #1820)
• Website firewall rule set updates between releases. hitechcloudcli webfirewall rules status|check|update|rollback (also waf rules ...) installs a newer firewall rule set from the mirror's waf-rules/ channel without a panel update. The set must be signed with the release key, the same key and signature check as a panel release. It is tested with the server's own firewall before it is applied, and the previous set comes back automatically if the test or the reload fails. 90-local.conf, imported rule sets and switched-off sets are never touched. A daily update can be turned on with webfirewall rules auto on (off by default), and 2087's Website Firewall > Rule sets page shows the version and the last check, with Check now, Update and Roll back buttons. The release side is devtools pack-waf-rules and the manual WAF rule set workflow (docs-internal/waf-rules-channel.md). (hitechcloudcli#492, hitechcloudadmin#330, HiTechCloud-Panel#1822)

Security​

• The portal API only answers the portal apps. On 4.1.x any process on the server (a site's PHP, a cron job) could call the portal API on 127.0.0.1:2094 as if it were the Mail, DNS or S3 portal. It could not read account data without a user's token, but it could set its own client address, which got around the per-address sign-in limits and a sign-in ticket's address binding and put false addresses in the audit log. The apps now send a shared secret from /etc/hitechcloud/portals/bff.env (root-only, made by the install or the update and kept afterwards), and the API refuses every other call except its health check with 403. (hitechcloudcli#484, HiTechCloud-Panel#1806)
• A portal visitor can no longer choose the address the portal records for them. The Mail, DNS and S3 portals took the first entry of the X-Forwarded-For header the browser sent. A visitor could set it to any address, which got around the per-address sign-in limit, met a sign-in ticket's address binding, and put a false address in the account's activity log. The portals now use the address of the connection itself. (HiTechCloud-Panel#1814)
• The WordPress cache flush service runs in its own SELinux domain. On AlmaLinux with SELinux enforcing, a WordPress site's own object-cache flush (Flush Cache, wp cache flush) now reaches the panel's flush socket. The service runs in its own domain, hitechcloud_cacheflush_t, and PHP may connect to that domain and to nothing else new. (hitechcloudcli#489)

Fixed​

• 2087's CSF firewall page always runs CSF's interface through the panel's own wrapper (/usr/local/hitechcloudcli/csf-ui.pl). Two outdated script locations were removed, so the page can no longer fall back to the csf command-line tool, which answers with its manual page. (hitechcloudadmin#327)

Changed​

• The portals' existing passkey step after a password sign-in now follows the same rule as the new passkey sign-in: the RP ID and origin come from the portal's configured address. Before, it took the RP ID from the forced domain even on a custom portal hostname, which a browser refuses. (HiTechCloud-Panel#1819)
• The weekly live test of real installs and updates now also checks phpMyAdmin and Mail/DNS/S3 portal single sign-on from 2083, 2087 package and reseller creation, the autoresponder, WP Helper in a new WordPress, and fresh installs on Ubuntu 26.04, Debian 13 and AlmaLinux 10. (HiTechCloud-Panel#1811, #1812, #1813)
• Continuous integration runs only the checks a change needs. This is internal and changes nothing on a server. (HiTechCloud-Panel#1818, #1821)

Known limitations​

• The SELinux module for the cache flush service has not been tested on a host with SELinux enforcing; it was checked offline against the AlmaLinux 9 policy. If it does not load, a WordPress site's flush behaves as in 4.1.6.
• 2087 has no page to see or revoke a customer's passkeys yet. Customers can still remove their own passkeys in 2083 or in the Mail portal.
• Greylisting stays off on Ubuntu 22.04 and Debian 12 when the cache is secured, as their rspamd cannot sign in with a username (see 4.1.4).
• The first signed website firewall rule set is published by the maintainers after the release. Until then there is no newer set to update to, and servers keep the set this release ships.