Skip to main content
Version: 4.1

3.7.3

A patch release. Four of the five items below are things the product did wrong while reporting that it had done them correctly — the same shape as 3.7.2, found the same way: by running it on a real server and by reading what its own numbers actually meant.

Upgrading is hitechcloudcli update.

Security​

  • The webmail shipped image parsers that a single malformed file can hang. image-size 1.2.1 to 2.0.2 can be driven into an infinite loop by a malformed JXL, HEIF or ICNS file. The backend reached it through pptxgenjs, and the documents plugin exports and imports real decks with images in them — so those parsers sat on a path that reaches bytes an account did not write. pptxgenjs's latest release still asks for the vulnerable range, so there was no version to move to; it is pinned with an override instead. Checked, not assumed: image-size is not bundled into pptxgenjs (so the pin removes the code rather than leaving an inlined copy), and the whole suite — 150 files, 2249 tests — was run against the new major, whose export shape changed. The update verifies on your machine which version is actually installed and says so if the rebuild did not take.
  • The documentation site carried the same library, one range away from the fix. Refreshed.
  • Two advisories were assessed and are not being changed. gorilla/csrf's TrustedOrigins weakness needs TrustedOrigins to be set, and the panel never sets it — its own origin check compares the scheme as well as the host and refuses Origin: null, which is the same gap spelled correctly. And the lru soundness advisory arrives through the MySQL client library, whose only patched line is two major versions ahead; moving a database driver that far in a patch release is a larger risk than an unsound iterator inside its own statement cache. It is scheduled deliberately instead.

Fixed​

  • Every usage bar read zero, however hard an account was working. CPU and memory are shown as a percentage of the plan's allowance, and a plan can promise more than the machine has — one slip of the unit turns 2048m into 2048g. Nothing can reach a promise like that, so the percentage rounds to nothing. On the machine this was found on, an account holding 963 MB of an 8 GB server — an eighth of the whole thing — was reported as 0.05%, with the "24h peak" row beside it showing the real figure. Usage is now measured against the smaller of the plan and the machine, and the sample says when the plan promised more than the server has. Every sum in the old chain was correct, which is why nothing anywhere said a word.
  • Delete on the notifications page could remove a different notification. Each one was identified by its position counted from the newest, and the health monitor appends to that file every five minutes. A page rendered at 10:04:59 and a click landing at 10:05:01 disagree about what position 1 is, so the click removed the notification below the one being read — one row shorter, no warning, wrong row gone. A notification is now named by a digest of its own content, computed identically by both engines and pinned by a test on each side; one that has been removed in the meantime is reported as gone instead of resolved to its neighbour.
  • The dashboard shows the last hour of CPU, memory, disk and load. The health monitor has been sampling every five minutes all along and the endpoint already served it; nothing on the dashboard asked. Drawn as inline SVG rather than with a charting library, because a panel that needs a CDN to draw is a panel that is blank on a server with no outbound internet.
  • The four figures in the top bar have names. They were an icon and a number — 0.23, 67.1% — with the only label in a hover tooltip, which a phone and a screen reader never show. Below 1200px that whole strip is fixed to the bottom of the window and nothing reserved the space, so it sat on top of the last rows of every page; it no longer does.
  • Inode counts were unreadable. 8,827 inodes were shown as 8.827 regardless of the reader's locale — which in English reads as eight and a bit — and a five-billion allowance came out as 5000.00M. Grouped the way the reader's own locale groups digits, compact above a million.

Performance​

  • Resolving a thread scanned every message in the account. When a message arrives that settles a thread whose root had only been guessed, the real thread id is propagated to the messages holding the provisional one. An index covering exactly that pair existed — but it is partial, and the statement does not carry the predicate that would let PostgreSQL read it. Measured on 200,000 messages in one account: a sequential scan discarding 199,960 rows in 31.9 ms, against an index scan in 1.6 ms. The gap widens with the mailbox, and this runs on every threaded arrival.

Internal​

  • The upstream watcher's commit digest adds up. Three commits arrived reported as "1 new" with a note saying "skipped 1", on an issue whose own body reads "nothing hidden": the third had been lifted into an issue of its own, which no counter knew about. Nothing was hidden, but the arithmetic could not be reconciled, which is the doubt that note exists to remove.
Was this helpful?