History / Release Process

The eight copies whose documents batch55 changes - the Assurance Case, the Command Line, Contributing, the Release Process, Secure Defaults, the Security Policy, The Update Feed and Third-Party Binaries - are copied again from the documents as master has them from batch55, 36bd59faa, on master since 26 October 2026, and each header says so and names what changed. The Security Policy's Verifying a release says that the release's SLSA provenance names every file of the release but the Sigstore bundles, how the commit, the tag and the pipeline its statement names are compared with those its signing certificate records, which from the release after 6.3.7 the release pipeline holds before it publishes, and, under SLSA Build level, that the releases from 6.3.6 meet Build L1 of SLSA v1.0 and claim no higher level, with why L2 and L3 are not met; For a security questionnaire names SECURITY-INSIGHTS.yml; and Renovate opens its merge request for an advisory at its next run, for a NuGet package with a fixed release, where it said at once for any dependency. Contributing says, under Code style and licence headers, that a file of the original hMailServer's whose own file in the original carried Martin Knafve's copyright notice keeps it on the line below the header, and that every file of the tree has its copyright and its licence as the REUSE Specification 3.3 asks, by its header or a table of REUSE.toml, with every licence's text in LICENSES/ and the reuse job holding it, which The checkers, the tables of the checkers and generators and Governance, conduct and licence name too. Secure Defaults says that a host added to AcmeDomains later is issued for at once, and that from the release after 6.3.7 the Compose file and the Helm chart secure a new installation's database at its first start, which the charts of 6.3.6 and 6.3.7 do not. The Command Line has the new passage on trusting a server's self-signed certificate on the machine you administer from; the Release Process's step 3 of The release on GitLab has release wait for the AArch64 packages' start jobs and linux-image-arm64, and its step 6 has container-image-start ask whether the update check knows it runs in a container; the Assurance Case's residual risk on coverage gives the linux-coverage job's weekly schedule and its first run on GitLab, where it said that the schedule had yet to be created; The Update Feed says that a server from 6.2.28 to 6.3.3 is offered only the newest release and so reaches neither it nor 6.3.3 by the live update, where it said that a 6.3.3 server found itself up to date and that one on 6.2.28 could go to 6.3.3 that way; and Third-Party Binaries says what the tree still carries that git shows as binary, and that the SQL Server Compact headers are 4.0's. A link of the copied text to a document the wiki copies is a wiki link, and every other link to a repository file points at it as 36bd59faa has it, where they pointed at 9336fdd59 or, in the Command Line, The Update Feed and Third-Party Binaries, at 0c0b6bae7, 5e49abf06 and 6fb8164c6 and, in Secure Defaults, at the tag v6.3.7, each document being the same at those commits as at 9336fdd59; the text is otherwise the documents', but for the adaptations and additions the headers declare. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 26, 2026

The six copies whose documents batch54 changes - the Assurance Case, Contributing, Governance, the Release Process, the Security Policy and the Upgrading Guide - are copied again from the documents as master has them from batch54, 9336fdd59, on master since 24 October 2026, and each header says so and names what changed. The Assurance Case's status note, the Release Process's The copy on GitHub and the opening of the Security Policy's Verifying a release say that GitHub's immutable-releases setting is on, that a release published there with it on keeps its files and its tag as published, though its notes can still be edited, and so do the copies of 6.3.6 and 6.3.7, published after it was switched on during the copying of 18 October 2026 (the Security Policy: at 05:26 and 05:31 UTC), and that the copies of the releases before them, published before it (the Security Policy: 6.0.0-B1 to 6.3.5 and the two build-inputs releases), can still be changed, where they said that a release published after the copies of 18 October 2026 could not be changed and that the copies could; Contributing's row Releases of the table of where things are and Governance's status note say that on GitHub the copies of 6.3.6 and 6.3.7, and every release published after them, are immutable, where they said a release published after that day's copies. The Upgrading Guide's Where you can upgrade from says that the Chocolatey package's log and the file with the refusal's words are in Chocolatey's cache folder, which its CLI makes setup's TEMP, where it said only that the package passes /LOG and shows that file's words when the install fails. A link of the copied text to a document the wiki copies is a wiki link, and every other link to a repository file points at it as 9336fdd59 has it, where they pointed at 6fb8164c6 or, in the Assurance Case and Governance, at 5e49abf06 and, in the Security Policy, at 72be22b4e, each document being the same at those commits as at 6fb8164c6; the text is otherwise the documents', but for the adaptations and additions the headers declare. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 24, 2026

The Release Process's note marked Now under step 13 of Order of operations, this wiki's own, says that a Chocolatey moderator approved hmailserver-progressiverobot 6.3.7, the package sent a third time on 23 October 2026 with the credit of the original hMailServer's author, Martin Knafve, at 11:56 UTC that day, so that choco install hmailserver-progressiverobot installs it, where it said that the community repository's feed listed it as Submitted, waiting for a moderator: the feed now gives PackageStatus Approved (PackageApprovedDate 2026-10-23T11:56:26, its virus scan NotFlagged), and on a clean Windows Server 2025 that afternoon choco install downloaded the release's installer (its SHA-256 the release's, its Authenticode signature Valid), installed 6.3.7 with the service running, and choco uninstall removed it. The page's header says so. Nothing else on the page changes. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 23, 2026

The Release Process's note marked Now under step 13 of Order of operations, this wiki's own, says that chocolatey-publish sent hmailserver-progressiverobot 6.3.7 a third time on 23 October 2026, with the credit of the original hMailServer's author, Martin Knafve, that the moderator asked for, and that the community repository's feed lists it as Submitted, waiting for a moderator, where it said that the 22 October package, still without that credit, was Submitted and not approved: chocolatey-publish (job 17399248551, in master's pipeline 2978723670) pushed it at 00:59 UTC that day, and the feed, read at 02:44 UTC, gives PackageStatus Submitted, PackageSubmittedStatus Updated, validation and verification Passing, and the authors "Christopher Holloway, Progressive Robot Ltd (the fork), Martin Knafve (the original hMailServer)". The page's header says so. Nothing else on the page changes. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 23, 2026

The Release Process's note marked Now under step 13 of Order of operations, this wiki's own, says that chocolatey-publish sent 6.3.7 again on 22 October 2026, still without the credit the moderator asked for, which the community repository's feed lists as Submitted, not approved, as hmailserver/docs/PackageManagers.md and Channels.md say with batch53 on master, 6fb8164c6, where 2c7abc8 left it saying that the package of 22 October waited for moderation: the documents say that its automated verification failed at 01:44 UTC that day, the verifier's download of it from Chocolatey's own feed having timed out, that its page again shows "Waiting for Maintainer to take corrective action", and that another press of chocolatey-release in master's pipeline sends 6.3.7 a third time, with the credit, once the templates' credit is on master. Installing hMailServer and Changes Since 6.2.10 already say it in the documents' words. The header's sentence on the note says the same, where it said only that the job sent 6.3.7 again, still without that credit. The feed, read at 23:43 UTC on 22 October 2026, gives the package of 22 October 2026 with PackageStatus Submitted, PackageSubmittedStatus Waiting and IsApproved false, its validation passing and its verification failing. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 22, 2026

The four copies whose documents batch53 changes - Contributing, the Release Process, Third-Party Binaries and the Upgrading Guide - are copied again from the documents as master has them from batch53, 6fb8164c6, on master since 22 October 2026, and each header says so and names what changed. Contributing's table of the Python checkers says that check-installer-scripts.py also checks that setup refuses an installation of the original hMailServer's 5.7 first, by bounds the upgrade chain in DBScripts holds, and that the Windows package jobs run that decision's self-test before they build the installer, and it has check-package-texts.py, which holds every package text the tree ships to saying that it is Progressive Robot's fork of hMailServer, the long descriptions and the Chocolatey and winget copyright and authors among them to crediting the original's author, Martin Knafve, and the packages' maintainer to being the project's. The Release Process's step 6 of The release on GitLab says that container-image-start starts the image beside PostgreSQL and beside MariaDB and asks each for SMTP and the REST API, where it said beside PostgreSQL alone, and its note marked Now under step 13, this wiki's own, says that a moderator returned the Chocolatey package of 20 October 2026 on 21 October, asking that its authors also credit Martin Knafve, and that chocolatey-publish sent 6.3.7 again on 22 October 2026, still without that credit, as PackageManagers.md says, where it said that the package of 20 October waited for moderation. Third-Party Binaries names libmariadb3, MariaDB Connector/C, with the mariadb-common and mysql-common it brings, among the packages the container image installs from the archive, from the release after 6.3.7. The Upgrading Guide's Where you can upgrade from says what setup up to 6.3.7 did over an installation of the original's 5.7 - replaced the program files and left a database this server refuses as too old, or, over one that the original's 5.7.0 build 3013 or later made new, set up a new, empty database beside the original's - and that from the release after 6.3.7 the installer refuses one before it changes anything, the installers of 6.3.7 and earlier not looking, so that they must not be run over one, with how setup decides and what the refusal says and where, where it said only that setup ran DBUpdater after it had replaced the program files and not to run this fork's installer over one; the list under If the upgrade fails of what else the installer refuses, this wiki's own, has that refusal as a third point, where it had two. A link of the copied text to a document the wiki copies is a wiki link, and every other link to a repository file points at it as 6fb8164c6 has it, where they pointed at 72be22b4e or, in Third-Party Binaries, at 5e49abf06; the text is otherwise the documents', but for the adaptations and additions the headers declare. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 22, 2026

The Release Process's note marked Now under step 13 of Order of operations, this wiki's own, says that winget's half of the step is done by hand and nothing has been submitted there yet, the project's submissions being paused, and that Chocolatey's is done in a master pipeline by chocolatey-release, started by hand, and chocolatey-publish, which verify the release's installer, render the package from it and push it, and which pushed hmailserver-progressiverobot 6.3.7 on 20 October 2026, where it waits for moderation, as hmailserver/docs/PackageManagers.md says with batch52 on master, 72be22b4e, where the note said that both halves of the step were done by hand; the community repository's feed, read on 22 October 2026, still gives that version as Submitted and not approved. The drawing The release at a glance, this wiki's own too, has at step 13 winget by hand and Chocolatey by its CI job, where it had by hand since the GitHub workflow, and the header says what both now say. RELEASE.md's own text at 72be22b4e - the history at the head of step 13, and item 7 of The release on GitLab - which still says that the package managers are done by hand, stays as the document has it, the page being its copy. Contributing's link to hmailserver/docs/Licenses, under Governance, conduct and licence, points at the folder as 72be22b4e has it, where ea3795b, which moved every other link of the copy to a repository file, left it at 5e49abf06, a tree link among blob links; the header's sentence that the document's links point at the documents as 72be22b4e has them now holds for every one of them. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 22, 2026

The four copies whose documents batch52 changes - Contributing, the Release Process, the Security Policy and the Upgrading Guide - are copied again from the documents as master has them from batch52, 72be22b4e, on master since 21 October 2026, and each header says so and names what changed. Contributing's table of the Python checkers has check-citation.py, which holds CITATION.cff's version and date-released to Version.h's release and its CHANGELOG.md date and the file to saying that this is Progressive Robot's fork, citing the original and claiming no DOI, and says that check-package-manifests.py also checks that every text a user reads in the winget and Chocolatey manifests says the package is Progressive Robot's fork of hMailServer and, with --release-date, that the manifest is dated by the release, where it checked the manifests against their schemas alone. The Release Process's step 7 stamps eighteen files, CITATION.cff among them, where it stamped seventeen, and the drawing The release at a glance, this wiki's own, says eighteen files at step 7, where it said eleven. The Security Policy's sentence on the upgrade chain - it runs from every earlier version of this fork - and the Upgrading Guide's paragraphs on the original hMailServer's databases - the original's up to schema 5708 are on the chain, its published 5.7 builds (5709 to 5711) are not, and a server of the original's 5.7 moves its mail over IMAP - are the documents' on master now, where 22057dd had brought them ahead of master; the two header notes that said so are gone, and the Upgrading Guide's paragraph ends, as the document does, with the pointer to Migration.md's "From the original hMailServer" and the sentence on ForkAndOriginal.md, which says what else differs between the two projects. A link of the copied text to a document the wiki copies is a wiki link, and every other link to a repository file points at it as 72be22b4e has it, where they pointed at 5e49abf06 or, in the Upgrading Guide, at the tag v6.3.7; the text is otherwise the documents', but for the adaptations and additions the headers declare. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 22, 2026

The ten copies whose documents batch51 changes - the Assurance Case, Contributing, Governance, the Release Process, the Security Policy, Regulatory Scope, Relocating an Installation, The Service Account, Third-Party Binaries and The Update Feed - are copied again from the documents as master has them from batch51, 5e49abf06 (21 October 2026), and each header says so and what the document changes, where they were the documents at batch50, 0c0b6bae7, or at batch49, f14412d39, which batch50 left as they were. Relocating an Installation: a new paragraph after the opening sends an installation whose programs somebody who is not an administrator may have changed to The Service Account's Reinstalling into a new folder; step 0 converts full message paths with the Data Directory Synchronizer on the installation before anything is copied, a row that names a file outside the data directory first, in the folder it names, in five numbered points, where step 8 ran the synchronizer against the new data directory after the copy, which would have imported each such message a second time, and step 8 checks that none is left and converts one that is the same way in the old data folder; step 3 makes the new root with the permissions setup gives a program folder before the copy, since a copy takes the permissions of the folder it lands in; step 4 says that the server reads Bin\hMailServer.ini under the folder the registry's InstallLocation names, so the edited copy only from step 5 on, where it said the file beside the running hMailServer.exe was read first, and, with step 1, that an edit of a stored setting in the file is put back only where the service may write the file; step 6 runs hMailServer.exe /ProtectFolders after /Register, and /GrantServiceAccess for a service that runs as anything but LocalSystem; step 7 names the Diagnostics page's Installation paths, where it named Settings, Directories; step 9 changes a certificate's files with Edit... rather than deleting it and adding it again; step 11 runs the release's setup again at the new root with /DIR, the 32-bit uninstall entry taken away first, and never the old uninstaller; and step 12 keeps the old tree private until it is deleted by hand. Three sentences of this wiki's own additions there say what the document now says: the passage that ends step 4 has a value edited into the file reported as HM5804 and the stored value used, the line put back where the service may write the file, so that the settings-store paths go on pointing at the old tree, and the store writing a new value into the file's copy where the service may write the file, where it had the line put back and the copy written whatever the account; and the paragraph on moving to new hardware has the stored settings written into the new machine's file at its first start where the service may write it. The Security Policy: Build provenance says that from the release after 6.3.7 a release also carries hmailserver-<version>.intoto.jsonl, the provenance bundle's DSSE envelope alone as one line of JSON, no second signature, which OpenSSF Scorecard's Signed-Releases check counts as provenance, where it said the provenance was not copied under that name; and What ran on GitHub has CodeQL there from GitHub's default setup at first and then .github/workflows/codeql.yml. The Release Process: release-verify writes the .intoto.jsonl and holds it to the bundle, the release has 161 links and files where it had 160, release-publish refuses an .intoto.jsonl that is not the envelope, the copy on GitHub carries it, the rehearsal writes and checks it, and GitHub Actions runs two workflows there, which make nothing a release carries; its note marked Now under step 9 of Order of operations stays. The Update Feed: a release from the one after 6.3.7 has 161 links, the .intoto.jsonl adding 308 bytes to releases.json and 302 to releases/latest. The Service Account: Reinstalling into a new folder points at Relocating an Installation for an installation whose programs only the administrators could have changed, and its table of the writes to hMailServer.INI says that the application log's line on the read-only file is written at a reinitialise where application logging is on and dropped at the service's start, where it said once per start. Contributing lists .github/CODEOWNERS and build/check-osv-ignores.py. The Assurance Case, Contributing, Governance, the Release Process, Regulatory Scope, Third-Party Binaries and The Update Feed say that GitHub Actions runs two workflows of the project's on the copy on GitHub, OpenSSF Scorecard's and .github/workflows/codeql.yml, which takes the place of GitHub's CodeQL default setup, where they said one workflow and the default setup; Governance also says that GitHub's rules there let the administrator role alone write master, the batch* branches and the release tags and hold a pull request to two approvals, the code owner's among them, and to CodeQL's check. A link of the copied text to a document the wiki copies is a wiki link, and every other link to a repository file points at it as 5e49abf06 has it, where they pointed at 0c0b6bae7 or at f14412d39; the text is otherwise the document's, but for the adaptations and additions the headers declare. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 21, 2026

Four pages say what the documents say with batch50 on master, 0c0b6bae7, of the files and the signatures of the releases up to 6.3.3, in sentences 9a56d55 left as they were: the residual risk on the installer's Authenticode signature, in the table this wiki adds to its copy of the Assurance Case, that every release up to 6.3.3 whose files GitLab has is re-published there, and since 18 October 2026 copied to GitHub, with its original files and signatures, byte for byte, 6.2.0 and 6.0.0-B4 being notes-only, where it said every release up to 6.3.3; section 10 of the Project Handbook that, for each release up to 6.3.3 whose files GitLab has, GitLab's releases page carries the same files, byte for byte, with the same signatures and, from 6.2.19, the same Sigstore bundles, 6.2.0 and 6.0.0-B4 being notes-only there, where it gave every release up to 6.3.3 the same files and the same bundles; Installing hMailServer that its table of assets is what the releases from 6.2.19 to 6.3.3 carry, the two SBOMs coming with every release from 6.2.3 and the five earlier releases that carry an installer having a CycloneDX SBOM of it alone, made afterwards, and that every asset but the two SBOMs of 6.2.22-pre3 has its Sigstore bundle, where it gave the table to every release up to 6.3.3 and a bundle to every asset; and Verifying what was published, in the section on publishing that this wiki adds to its copy of the Release Process, that the releases up to 6.3.3 are on GitLab, those whose files GitLab has with the same files, byte for byte, as when they were published on GitHub, 6.2.0 and 6.0.0-B4 being notes-only there, where it said so of every release (RegulatoryScope.md, SECURITY.md, and Roadmap3.md's row on the files GitLab does not have). The copies' headers are as they were. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 20, 2026

The eleven copies whose documents batch50 changes - the Assurance Case, Governance, the Release Process, the Security Policy, Regulatory Scope, Command Line, Event Scripts, Relocating an Installation, the Regression Test Environment, The Service Account and Migrating the Database Backend - are copied again from the documents as master has them from batch50, 0c0b6bae7, and each header says so and what the document changes, where they were the documents at batch49, f14412d39, or at v6.3.7, which batch49 left as they were. Migrating the Database Backend: step 3 runs DBSetup.exe - the wizard's Create a new hMailServer database, or DBSetup.exe /unattended with the HM_DB_* variables and HM_ADMIN_PASSWORD - which creates the database and its schema, writes the [Database] section through the service, the password encrypted (PasswordEncryption=6), and restarts the server on the new database, the login allowed to create a database and the database not existing yet, with Not DBSetupQuick.exe and the refusal of DBSetup under NT SERVICE\hMailServer, where it said to create an empty database, point hMailServer.ini at it by hand and run DBSetupQuick.exe, which made no usable database there; the short version, the MySQL and MariaDB section's account of who creates the database on Windows and on Linux, and step 4's first open of the new database follow it; the PostgreSQL row says that SQL Server's, PostgreSQL's and SQL Server Compact's DDL is transactional and that only MySQL and MariaDB commit each step's DDL as it runs, where it called PostgreSQL the only one of the four; and the note after the restore says that the schema is created in no transaction on every backend, where it said so of MySQL and SQL Server Compact alone. This wiki's comparison table under Choosing a target now has SQL Server and SQL Server Compact transactional and a failed upgrade leaving nothing applied on them, where it had SQL Server mostly transactional and SQL Server Compact committing as it goes, and its flowchart of the procedure has one step for DBSetup between the backup and the restore, where it stopped the service, created an empty database, edited the ini file, ran DBSetupQuick and started the service again; the table's link to DatabaseTls.md goes to this wiki's copy, Database TLS. The Service Account: in Reinstalling into a new folder, step 2 changes the settings file's other paths into the old installation - PostgreSQLSslRootCert and TlsCaFile, UpdateTrustRootsFile and UpdateLogPublicKeyFile, a path in [SettingsOverride] - to copies where nobody but the administrators may change them and deletes the lines the site did not set, and step 4 keeps the old folder private to SYSTEM and the Administrators until it is deleted; the live update's internal tests name 6.3.1 and 6.3.3 to 6.3.5, where they said 6.3.1 to 6.3.5; and its link to RelocatingAnInstallation.md under the message files outside the data folder goes to this wiki's copy, as its two others do. Relocating an Installation: step 1's inventory and step 4 name TlsCaFile beside PostgreSQLSslRootCert, and Seeing where the paths are says that Installation paths lists every path-shaped setting but that one. The Regression Test Environment: the list of what a new Windows bench needs names the release installers build/fetch-installer-fixtures.ps1 fetches for AdminUpdateTester and AdminUpdateStageTester. Command Line: the two queue examples filter on tries, the field a queue item has, where they named retry_count. Event Scripts: the rule action is "Run script function", as the Control Panel lists it, where it said "Run function". Regulatory Scope: the releases up to 6.3.3 whose files GitLab has are re-published there, 6.2.0 and 6.0.0-B4 being notes-only; SBOMs from 6.2.3, the five earlier releases that carry an installer having a CycloneDX SBOM of it alone; the assets from 6.2.19 to 6.3.3 signed but for 6.2.22-pre3's two SBOMs; and the releases before 6.3.1 unsigned because their original files are published byte for byte, where it gave a published release's immutability as the reason. The Assurance Case, Governance and the Release Process: GitHub's signer signed the releases from 6.2.19 to 6.3.3, where they said the releases up to 6.3.3. The Security Policy: Verifying a release names 6.2.22-pre3's two SBOMs and 6.3.4 beside the withdrawn and superseded pre-releases as the assets from 6.2.19 on without a Sigstore bundle. A link of the copied text to a document the wiki copies is a wiki link, and every other link to a repository file points at it as 0c0b6bae7 has it, where they pointed at f14412d39 or at v6.3.7; the text is otherwise the document's, but for the adaptations and additions the headers declare. The wiki's own tables on these pages say what the documents now say: the Assurance Case's traceability row for anyone downloading has the Sigstore signatures from 6.2.19 to 6.3.3 and the SBOMs from 6.2.3, and the Security Policy's row on the supply chain among the standing controls has 6.2.22-pre3's two SBOMs carrying no bundle and the SBOMs from 6.2.3, the five earlier releases that carry an installer having a CycloneDX SBOM of it alone, made afterwards. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 20, 2026

The wiki's own pages say what the documents say with batch49 on master: the Project Handbook's Scorecard record that the OpenSSF API serves the GitHub copy's score since 19 October 2026, published by the copy's workflow on its first run on master, where it said the API served none for the copy yet; Changes since 6.2.10 and the Settings Reference that nothing has run the Linux suite or the checkers on GitHub Actions since 18 September 2026, and that GitLab CI's checkers job runs every build/check-*.py since 26 September 2026, where they said GitHub Actions had not run for the project at all and the checkers were run by hand; the Glossary, Installing hMailServer and the Project Handbook that the releases before 6.3.1 stay unsigned because every release up to 6.3.3 is re-published on GitLab, and copied to GitHub since 18 October 2026, with its original files and signatures, byte for byte, where they gave a published release's immutability as the reason (SECURITY.md: the GitHub copies were published before the immutable-releases setting was switched on, and can be changed); the Glossary, Installing hMailServer, the Release Process, Upgrading hMailServer, the Settings Reference and Changes since 6.2.10 that GitHub's release workflow signed the releases from 6.2.19 to 6.3.3, where they said every release up to 6.3.3 (no release from 6.0.0-B1 to 6.2.18 carries a Sigstore bundle; SECURITY.md, Verifying a release); Regulatory Scope's Annex I table that the 6.3 line's support period is defined, security fixes until 30 September 2027 and, unless the maintainers write otherwise before then, no support from 1 October 2027, where it said no support period was defined; the Release Process's note at step 9 that since 6.3.6 static-analysis and semgrep fail the pipeline on a finding new to their baselines that master's exceptions file does not accept, while dependency-scan still does not, where it said all three may fail without failing it; and Contributing's paragraphs on the Service Desk and the board without the sentence that the address may change if the project moves to the group hmailserver, which it did on 29 September 2026, and without the clause that a scoped label is not exclusive on GitLab's Free tier, the group having been on GitLab's open-source plan since 13 October 2026. The re-check of the wiki brought to batch49 found these on 19 October 2026; the same shapes were swept on the wiki's own pages, and the copies of repository documents left as their documents have them. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 19, 2026

The eight copies whose documents batch49 changes - the Assurance Case, Contributing, Governance, Regulatory Scope, Release Process, Security Policy, The Update Feed and Third-Party Binaries - are copied again from the documents as master has them from batch49, f14412d39, in which 6.3.7 is reflected as at the tag, and each header says so and what the document changes since the tag, where they were the documents at v6.3.7 and said that GitHub had been unavailable to the project since 18 September 2026, that issues and questions went to GitLab alone and that the original project was no longer developed upstream. The Assurance Case's status note: the account Progressiverobot, which GitHub suspended on 18 September 2026, stays suspended, and since 18 October 2026 the project is published on GitHub again, at github.com/RainbowWizard-coder/hMailServer, with GitLab canonical; every release from 6.0.0-B1 to 6.3.7 is copied there with the same files byte for byte; no pipeline of the project's runs there, where GitHub Actions runs one workflow of the project's, scorecard.yml, beside GitHub's own CodeQL default setup; and sbom.yml and sign-release.yml, in the trees of the old tags, ran once there on 18 October 2026 on the copies of the releases from 6.2.3 to 6.2.22-pre6, what they wrote was undone, and both have been disabled since. Contributing: the original project went quiet for years and has since resumed development separately; GitLab is the one place the project is worked on and GitHub its mirror, with the repository, every release, the wiki's copy, pull requests and Discussions and no Issues; the table of where things are, the tree's .github/, the GitHub numbering, the rule that no build step downloads from GitHub, and a pull request on GitHub accepted and landed through a GitLab merge request. Governance: the status note, the private vulnerability reporting switched on and read by the maintainers, the repository on GitHub belonging to the account RainbowWizard-coder, its only administrator, Zainulabidin90 removed from it on 18 October 2026, and accepting, reviewing and proposing a change taking in a pull request on GitHub. Regulatory Scope: the releases copied to GitHub, GitHub's own CodeQL default setup there and the one workflow of the project's that GitHub Actions runs there, OpenSSF Scorecard's, which signs and publishes nothing of a release, the old release workflows run once there and disabled, and the one signer a server up to 6.3.3 trusts named as the release workflow of the repository under the former account Progressiverobot. Third-Party Binaries: the build-inputs files fetched from GitLab alone, both releases copied to GitHub with the others and never read there, and nothing on GitHub doing what the old binary-provenance workflow did. Release Process: GitHub unavailable to the project from 18 September to 18 October 2026; The copy on GitHub, under The release on GitLab; step 9's sentence on CodeQL's default setup, which the gate does not read; step 14's issues answered on GitLab; and the federated credential made on the app registration the protected variable AZURE_CLIENT_ID names. Security Policy: GitHub's private vulnerability reporting as a third route, and never a public issue, merge request or pull request on either forge or a GitHub discussion; a report made there carried into a confidential GitLab issue; the exceptions file counted again on 18 October 2026, 491 accepted findings, 157 expiring on 25 September 2027 and 3 on 12 October 2027, and in Why that date 159 and 42; and Verifying a release for a file from GitHub's releases page. The Update Feed: no server reads a feed on GitHub, the address 6.2.28 to 6.3.3 read is the suspended account's and still answers 404, and a certificate for a workflow of the repository on GitHub names an identity no server trusts. A link of the copied text to a document the wiki copies is a wiki link, and every other link to a repository file points at it as f14412d39 has it, where they pointed at v6.3.7. The text is otherwise the document's, but for the adaptations and additions the headers declare: Contributing's paragraph on reporting and asking keeps the Service Desk for anyone without a GitLab account, as SUPPORT.md does, and now also sends a question from someone with a GitHub account to the Q&A of GitHub's Discussions, where the document still says only a security report can go by email; Release Process's note marked Now at step 9 stands after the document's new sentence there; and the Assurance Case's own additions of 8 September 2026 - the chart of the trust boundaries drawn in section 4 in place of the document's text figure, the sentence on a forward proxy that ends section 6's paragraph on the update path, and the traceability table, the chart of which claim each weakness class answers and the table of the residual risks that close section 7 - are named as this wiki's own in its header, which named none of them. The wiki's own additions on these pages that name the reporting routes - Security Policy's decision chart and its timeline after a report, Governance's map of which document governs what - name GitHub's private vulnerability reporting and the Q&A of GitHub's Discussions beside the confidential issue, the Service Desk address and the forum, and never a pull request or a discussion for a vulnerability; and Governance's note on code-signing material says that the old release workflow could not sign once GitHub had suspended the project's account, where it said it cannot sign while GitHub is unavailable. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 19, 2026

Installing hMailServer gives 6.3.7's check, as its header says it does, and it and seven more pages say that the project's GitLab CI has signed every release since 6.3.5 - 6.3.5 at the path the project began at, and from 6.3.6 at the group's, which the project moved to on 29 September 2026 - where they said, as 6.3.4 was made, that the pipeline was to sign the releases after it, had signed none yet and would follow the project to the path it was to move to. Installing hMailServer, section 4.1: a paragraph on checking 6.3.7 - made by its tag's GitLab pipeline, each of its sixty-two files signed with Sigstore and its bundle beside it, hmailserver-6.3.7.intoto.sigstore.json its SLSA provenance, no .sig; the installer checked against the SHA-256 the Download table of the release's notes gives it, dcae96bd75d6cae8e5a910d15940567067539ed99db5aeed40a815added4d85f for hMailServer-6.3.7-x64.exe, or against its bundle with cosign, the identity https://gitlab.com/hmailserver/hmailserver//.gitlab-ci.yml@refs/tags/v6.3.7 and the issuer https://gitlab.com, the project's id 86730559 read as Security Policy's Verifying a release says, then its Authenticode signature - where the page checked releases up to 6.3.3 and 6.3.4 alone; the releases after 6.3.4 are signed by the project's GitLab CI, a signer every server from 6.3.4 on has compiled in, and Upgrading hMailServer 18.4f says which servers install 6.3.7 by their live update, where they were to be signed and a 6.3.4 server's live update was to install them; and what a 6.3.4 server trusts is that pipeline at the path the project began at, where it signed 6.3.5, and at the group's, where it has signed every release from 6.3.6, there only with the project's id. The same stale sentence, swept: Settings Overview (the update feed's two signers), Release Process (Verifying what was published, this wiki's own section: the identities the releases from 6.3.5 carry), the Glossary (Sigstore), the Control Panel Reference (the Updates card), The Control Deck (the Update view: a 6.3.4 server's live update trusts the releases after it, where the signing job was written and had not yet run), the Project Handbook's section 10 and the Settings Reference's UpdateSourceRepository row (the three settings at the path the project began at keep a server to it, so that it refuses every release from 6.3.6, and since the move a server from 6.2.28 to 6.3.3 is upgraded by hand; the row's link to UpdateFeed.md now at the group's path). Home: the Atom feed's entries' ids are made from each release's tag alone, so that they do not change when a release is edited or the project moves, as UpdateFeed.md's The Atom feed says, where they were to keep their ids when the project moved into the group. The sections for one release - Changes Since 6.2.10's 4e and Upgrading hMailServer's 18.4c, written for 6.3.4 - and Capabilities and Configuration's paragraph marked as of 6.3.4 say it as 6.3.4 stood, and stay as written. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 18, 2026

Release Process and The Update Feed give the path the project began at, gitlab.com/Progressiverobot/hmailserver, in the four lines where RELEASE.md and UpdateFeed.md at the tag v6.3.7 give it - the identity 6.3.5 was signed with, the repository a server from 6.2.28 to 6.3.3 is given beside that identity, the GitLab column's repository before the move, and the second of the two paths whose certificates no setting lets through without the project's id - where each copy gave the group's path, gitlab.com/hmailserver/hmailserver, and each line was false. Release Process, step 4 of The release on GitLab: 6.3.5, before the move, was signed as https://gitlab.com/Progressiverobot/hmailserver//..., as RELEASE.md:234 has it and as build/ci/release-chain.py's SIGNER_IDENTITY_PREFIX at v6.3.5 made it. The Update Feed: the ini example for a server from 6.2.28 to 6.3.3 names UpdateSourceRepository=https://gitlab.com/Progressiverobot/hmailserver beside the identity at the same path (UpdateFeed.md:175), the values the document says 6.3.5's certificate names exactly, where it named the group's path under a sentence that says these settings must not name it; the table's GitLab column, the signer before the move, gives the repository at the path the project began at (:362); and the certificates no setting lets through without the project's id are those that name the group's path or, from 6.3.6, the one the project began at, https://gitlab.com/Progressiverobot/hmailserver// (:498), where the copy gave the group's path for both. dacc831 put the group's path in the example and the table row on 5 October 2026, when it moved every link to the project to the group's address, and 95cbd71's copy from v6.3.6 that day carried it into the other two lines; 1cea3e0 kept all four, the documents' lines being the same at v6.3.6 and v6.3.7. Every line of the twenty-four copies that names the path the project began at in its document now names it as the document does. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 18, 2026

The twenty-two pages that copy a repository document are copied again from the documents as the tag v6.3.7 (31d656c0c), the release of 17 October 2026, has them, each keeping what this wiki adds of its own, and each header says so and what 6.3.7 changes in it, where the nine brought up on 17 October 2026 named the batch 6.3.7 was to be made from, at the same commit, and said that the rest of the copy was v6.3.6's. Re-copied from the tag: Security Policy (SECURITY.md: its latest release 6.3.7, published on 17 October 2026; "6.3.7 was the exception" under What gets a release, and step 3's pointer to it; Every change and Declaring a finding not exploitable; the release's scans as the second evaluation; the libraries dependency-scan says UNKNOWN for), Release Process (RELEASE.md: the release's notes and their Download table, step 9's gate asked before the tag with master's copy of the exceptions, 6.3.7's paragraph under A security release during the pause), Contributing (CONTRIBUTING.md: the runners each pipeline runs on, the change checks, the eighteen fetched inputs, the new checkers and generated files, the secret scans, sign-off since batch41, step 6 of Merge requests), Governance, Assurance Case, Regression Test Environment (Connector/C 3.4.11's folder; the 7-Zip path the document now writes right), The Service Account (/ProtectFolders hardening the program folder, Bin and ControlPanel, and the steps before upgrading an installation at a drive's root), The Update Feed (the Control Panel's Updates page, the summary past the Download table, the pages job on the project's own runners, where this copy said GitLab's shared runners), Upgrading Guide (the route between backends, the .NET 10 runtime setup leaves as it is), Third-Party Binaries (MariaDB Connector/C 3.4.11 built from MariaDB's source and fetched from build-inputs-2), Database TLS, Diagnosing Stalled Mail (the spam tests' failed lookups and the DNSSEC deferral's reasons), Event Scripts, Fuzzing (UTS 46 against ada), High Availability Runbook (the PROXY protocol behind a load balancer), Secrets at Rest, Secure Defaults, The SNMP Agent, Migrating the Database Backend, Regulatory Scope and Architecture (a transaction is its thread's). Command Line is unchanged at the tag; its header says so and its links point at it. A link to a document the wiki copies is a wiki link; every other link to a repository file that pointed at v6.3.6 points at it as v6.3.7 has it. The headers no longer list as this copy's departures what the tag's documents now say themselves: the day 6.3.6 was published (Security Policy, Contributing), the count of the findings accepted at 6.3.4 (Security Policy), the report of a command run as root on Linux (The Service Account), the route between backends (Upgrading Guide) and the 7-Zip path (Regression Test Environment). Release Process's notes marked Now at steps 9 and 11 say that every release since 6.3.5 has been made by its tag's pipeline, where step 9's said that no pipeline had run on a release tag, and that the installer's inputs are fetched from the build-inputs-1 and build-inputs-2 releases. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 18, 2026

Security Policy, Release Process, Governance, the Assurance Case, Contributing, the Regression Test Environment and the Project Handbook say who sees a report, who can approve a batch, what the revoked token laptop-git can do, which runners and licences a release needs and when the accepted findings expire as the documents say it at batch48 (31d656c0c), the batch 6.3.7 is made from, where they said what v6.3.6 says. For 6.3.7 the tree's SECURITY.md, RELEASE.md, GOVERNANCE.md, ASSURANCE-CASE.md, CONTRIBUTING.md and RegressionEnvironment.md were corrected in what they say of the project's members, approvals, tokens, runners and licences, and the stamp counted the accepted findings again on 17 October 2026. The wiki's copies still said what v6.3.6 says: that Zain Ul Abidin can see every report and approves each merge request, that the project access token laptop-git holds the Owner role until 27 September 2027, that 298 findings expire in March 2027, that the release jobs have not run, that two machines run the builds and suites. The push of master to main, the branch GitLab serves the wiki from, would have made most of that live for the first time. Each paragraph, list item or table row that says one of these things is now the document's at 31d656c0c, with the wiki's own links kept and a link to a document the wiki has no copy of pointing at master: - Security Policy: who sees a confidential issue; Why that date and One date comes first, with bench150's Windows licence and the findings as counted on 17 October 2026; the opening and step 3 of How a report is handled; the opening, steps 1 and 4 and the runners of How a security release is made; the opening of What must stay valid and its rows for the exceptions file, the two Windows benches' licences, laptop-git and the release channels' credentials. - Release Process: the status note; who creates release tags; step 2's last paragraph and step 3's first under The release on GitLab; Before starting and steps 2, 3 and 6 of A security release during the pause; and step 7's paragraph on the release's notes, which the copy lacked. - Governance: every paragraph on the members' roles, the approvals, laptop-git and the landings by 14 October 2026, so that the whole copy is the document's, links aside. - Assurance Case: the residual risk "Bus factor is still effectively 1". - Contributing: the opening's paragraph on what runs where, On the project's own runners (the wiki's note marked Now kept), and steps 5 and 7 of Merge requests. - Regression Test Environment: GitLab CI's runs of the suite. Not taken, for the copy from v6.3.7 after the release: SECURITY.md's paragraph on 6.3.7 under What gets a release, with step 3's pointer to it, RELEASE.md's paragraph on 6.3.7 under A security release during the pause, and the latest release lines; Security Policy still gives 6.3.6 as the latest release until 6.3.7 is out. The Project Handbook, the wiki's own page, says the same in its own words: a batch lands through a merge request that a second person approves by the rule, and since 13 October 2026 on the owner's override; the release jobs made 6.3.5 and 6.3.6; the builds and suites run on the project's own runners, bench150, S1-WINBENCH, linix, server2 and s1-linux. Each header says what was brought up, from which commit, and what is left out. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 17, 2026

Security Policy, Release Process, the Upgrading Guide, The Service Account and The Update Feed name batch48 at 31d656c0c, its tip now, as the document their paragraphs brought up for 6.3.7 are copied from, where they named 7f685f0df, its tip when they were moved last. batch48 has moved on by two commits since, f4da607b8 and 31d656c0c, which change CHANGELOG.md and the server's code alone (PersistentMessageMetaData.cpp and .h, SQLStatement.cpp and WorkQueue.cpp): SECURITY.md, RELEASE.md, Upgrading.md, ServiceAccount.md and UpdateFeed.md are the same at both. Each paragraph these pages brought up for 6.3.7 is the document's at 31d656c0c, line for line, and each header's commit and its link to the document now name that commit, the batch 6.3.7 is made from. Nothing else on the pages changes. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 17, 2026

Security Policy, Release Process, the Upgrading Guide, The Service Account and The Update Feed name batch48 at 7f685f0df, its tip now, as the document their paragraphs brought up for 6.3.7 are copied from, where they named 834d7a3b8, its tip when they were copied. batch48 has moved on by two commits since the copies were made, 10fb5b5b4 and 7f685f0df, which change CHANGELOG.md and the server's code alone (WorkQueue.cpp, PersistentMessageMetaData.cpp and .h, ClassTester.cpp): SECURITY.md, RELEASE.md, Upgrading.md, ServiceAccount.md and UpdateFeed.md are the same at both. Each paragraph these pages brought up for 6.3.7 is the document's at 7f685f0df, line for line, and each header's commit and its link to the document now name that commit, the batch 6.3.7 is made from. Nothing else on the pages changes. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 17, 2026

Security Policy, Release Process, the Project Handbook and Home say what a release is while releases pause as SECURITY.md and RELEASE.md say it at batch48 (834d7a3b8), the batch 6.3.7 is made from: no release is planned by date, and each security release is cut from master with the finished work master holds then. The owner's decision of 16 October 2026 reworded the five places of the two documents that said what a release is during the pause (CHANGELOG.md's entry for the documents). The wiki's copies of them, and its summaries, still said what they said at v6.3.6, which 6.3.7 makes untrue: that 6.3.6 is the last release for the time being, that no feature release follows it, that a security release is 6.3.6 with fixes and that master takes fixes only. Security Policy: Supported versions, the opening of While releases pause and the first point of its What is supported, and for how long are SECURITY.md's paragraphs as batch48 has them, line for line; the last names 6.3.6 beside 6.3.5, 6.2 and older among the installations upgraded in place to the newest release, as the stamp (c92d3c80e) made it say. Release Process: its opening and the first paragraph of A security release during the pause are RELEASE.md's as batch48 has them; the opening, which the copy of 5 October 2026 (95cbd71) had twice, is there once, as the document has it. Each header says what was brought up on 17 October 2026, and that the rest of the copy is as it was copied from v6.3.6; Security Policy's says that it still gives 6.3.6 as the latest release until 6.3.7 is out, where SECURITY.md already names 6.3.7 of 17 October 2026. The Project Handbook's status note and its section 9, and Home's Current release row, say that 6.3.6 was the last release planned by date and that each security release is cut from master with the finished work it holds then. The two sections for one release that say the pause in 6.3.6's own words, Upgrading hMailServer 18.4e and Changes Since 6.2.10 4g, stay as written, as 6.3.6's section of the CHANGELOG does. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 17, 2026

The twenty-two pages that copy a repository document are copied again from the documents as the tag v6.3.6, the release, has them, each keeping what this wiki adds of its own. Re-copied from the tag v6.3.6 (e3c448aa6), each header saying so and what 6.3.6 changes in it: The Update Feed (UpdateFeed.md), The Service Account (ServiceAccount.md), Security Policy (SECURITY.md), Release Process (RELEASE.md), Upgrading Guide (Upgrading.md), Secure Defaults (SecureDefaults.md), Third-Party Binaries (ThirdPartyBinaries.md), Contributing (CONTRIBUTING.md), Secrets at Rest (SecretsAtRest.md), Assurance Case (ASSURANCE-CASE.md), Event Scripts (EventScripts.md), Command Line (CommandLine.md), Governance (GOVERNANCE.md), Regression Test Environment (RegressionEnvironment.md), The SNMP Agent (Snmp.md), High Availability Runbook (HighAvailabilityRunbook.md), Regulatory Scope (RegulatoryScope.md) and Fuzzing (Fuzzing.md). Architecture (ARCHITECTURE.md), Database TLS (DatabaseTls.md), Diagnosing Stalled Mail (DiagnosingStalledMail.md) and Migrating the Database Backend (MigratingDatabaseBackend.md) are unchanged at the tag; their headers say so and their links point at it. The wiki's own additions - the diagrams, the tables and the notes each header names as the wiki's - are kept. A link to a document the wiki copies is a wiki link; every other link to a repository file points at it as v6.3.6 has it. Where SECURITY.md and CONTRIBUTING.md say 6.3.6 was published on 1 October 2026, the copies give 6 October 2026, the day of its publication, and their headers say so. Where Upgrading.md says there is no first-class route from one database backend to another, the copy keeps its pointer at Migrating the Database Backend, the repository's own document on it. Secrets at Rest, "Who can open it": a wiki note under the paragraph that still describes the permissions hMailServer.ini inherits under Program Files, which 6.3.6's /ProtectFolders closes. Contributing, the wiki's own Service Desk section: the address at the group's path, as SECURITY.md gives it. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 5, 2026

Every link to the project points at its address in the group, gitlab.com/hmailserver/hmailserver, where it has been since 29 September 2026; the identities 6.3.5 was signed with, and the setting row that lists both paths, keep the path the project began at. The project's path in all 63 pages that linked it (548 links), 6.3.6 being the first release made at the group's path. Left as they were: the seven signing identities https://gitlab.com/Progressiverobot/hmailserver//.gitlab-ci.yml@refs/tags/v... (Release Process, Security Policy, The Update Feed, and the UpdateSigningIdentity row of Settings Reference), which name what 6.3.5 was signed as; and the UpdateSourceRepository row of Settings Reference, which lists both paths on purpose. The container registry's name is corrected with the container page. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Oct 5, 2026

Security Policy and Release Process: the project access token laptop-git holds the Owner role, so the owner is the only person, not the only member, with the Maintainer role or above; and the findings that expire in March 2027 hold a release from the day after, while the scans still report them. The same corrections as the repository's, in the branch b42-feeds-docs after 266c35577 (the second refute pass over it), to the copies 7b4d691 brought up to SECURITY.md and RELEASE.md: "He is the project's only member with the Maintainer role or above" and "nobody else can take them" left out the project access token laptop-git, a member with the Owner role until 27 September 2027 (Roadmap3.md's row on branch and tag protection), with which GitLab would let a landing and the release jobs be started; the table's row for it now says so. "From then, the release job refuses any release until each has been read again" is now "from the day after ... while any of them is still found": build/ci/security-gate.py accepts an exception through its expiry day and holds a release only on a finding a scan still reports. Not pushed: this wiki is pushed after 6.3.6. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Sep 29, 2026

The pages on CI, the release process, the test environment and the project's home are brought up to the tree as it stands for 6.3.6 (batch42 at d8a84f66c, with the branch b42-feeds-docs) and to master's first full pipeline (GitLab work item #21). The five copies of repository documents take every change their documents have had since the tag v6.3.4 (51e2dbda0), merged three ways from the document at the tag to the document now, so that this wiki's own additions stay: Security Policy (SECURITY.md: "While releases pause" - 6.3.6 the last release for the time being, security fixes for the 6.3 line until 30 September 2027 by the maintainers' decision, what gets a release, how a report is handled, the five steps of a security release only the owner can take, what a release depends on that expires; no Azure secret on GitLab; the .sigstore.json copies and the SLSA provenance from 6.3.6), Release Process (RELEASE.md: "A security release during the pause", placed before this wiki's "The release at a glance"; the release jobs' fifty-seven files from 6.3.6 and the batch branches' rehearsal), Contributing (Roadmap3.md, the AppImage's own runtime, the upgrade gate from 6029's create script, linux-repro, three new checkers, and the package, release and rehearsal jobs in place of the release job the document called a placeholder, which the tree now corrects as well), Fuzzing (the commit the old workflow is at) and Regression Test Environment (the Linux suite's counts and the coverage schedule). Each header says what it was brought up to, and where it still differs from its document: the latest release is given as 6.3.4, published on 27 September 2026, until 6.3.5 is out, where the tree is already stamped for 6.3.5; Security Policy keeps its account of the 455 findings accepted at 6.3.4. The statements that no GitLab job had run are replaced with what ran. Master's pipeline 2886389460, 27 September 2026 04:19 to 07:55 UTC on 6bc09509d, read from GitLab's API on 29 September 2026: 29 jobs, 25 passed; windows-gate on bench150, 3,811 tests, 3,736 passed, 0 failed, 74 skipped, 1 inconclusive, and linux-suite on linix, 2,020 tests, 1,710 passed, 0 failed, 310 skipped, each 8,563 s; db-matrix left manual; secret_detection, semgrep and static-analysis failed, each on a fault of the tree's that batch41 mends (#21's notes). So on Home (the regression suite; the current release, with the pause; following releases, with updates.progressiverobot.com/releases.atom from 6.3.6 beside GitLab's own feed; the Security Policy and Release Process rows), the Project Handbook (the status note and sections 7, 8, 9, 11 and 12: GitLab CI's jobs have run, a change lands through a merge request the other maintainer approves with build/land-via-mr.py, the pause), Installing on Linux (linux-cross passed, 559 s), Running in a Container (linux-image and chart-and-compose passed), Changes Since 6.2.10 (GitLab CI runs the checks' replacements; the first full pipeline on the fixed tree), Contributing (a note marked Now) and Regression Test Environment (its header). Fuzzing's Now note: the schedule exists (4461177), and its first two nights, pipelines 2887914840 and 2891652158 on 28 and 29 September 2026, ran linux-fuzz alone and passed, about an hour each. Governance and Regulatory Scope were read and left: their documents have not changed since v6.3.4, and what they say of CI and the release jobs (written, not yet run on a release tag) is still true. Every wiki link and in-page anchor the changes add resolves. Signed-off-by: Christopher Holloway <chris.holloway@progressiverobot.com>

Christopher Holloway committed Sep 29, 2026

The wiki is brought up to the published release: 6.3.4 is the signed tag v6.3.4 at 51e2dbda0, published on GitLab on 27 September 2026 (02:37:56 UTC), not 8adce850a of 26 September, where the tag was first made and whose release gate failed. Every page that named 8adce850a as the tag or the release names 51e2dbda0, and every page that dated the release 26 September dates it 27 September: the footer, the sidebar, the page headers, the landing page's Current release, the release timeline's row and picture, section 4e's heading. Each fact those pages took from 8adce850a was checked at 51e2dbda0: the commits between the two change 42 files, whose only documents are CHANGELOG.md, BrandLogos.md, OpenPGP.md and SecretsAtRest.md, none of which a page copies, and which include none of Constants.h, Version.h, formMain.cs, the create scripts, IniFileSettings.cpp, SettingsDefaults.h, the IDL, the Control Panel or .gitlab/allowed_signers, so every file and line cited at the tag holds. Where a page said it read the tag on 26 September, it says it read 8adce850a and that what it read is the same at the tag. The suite has 3,811 [Test] attributes at the tag, not 3,809 (the fixes add two tests); twelve places say so. Changes Since 6.2.10 gains, in batch 40, what the release gate found and the eleven fixes: three change tests alone; of the other eight, three fix what 6.3.3 did too - a relay that refused the OAuth2 login got the server's token into the bounce and the logs (open since 6.2.22-pre1), a rule's forward, copy, reply or notice and an account's forwarding could wait a minute in the queue, and IMAP LIST and LSUB took a literal's length for the pattern - and five fix code new in 6.3.4 (sealed mail and an unnamed part, a closed key's FETCH refusal logged as a critical error, the help desk's password reset read as bytes, the logo and key-directory holds, an alert's encoded Subject over 76 characters). The gate table and the timeline give the re-run on 51e2dbda0 as the logs have it: 2,349 on the first bench (2,252 passed, 0 failed, 97 skipped) and 1,462 on the second (1,446 passed, 0 failed, 16 skipped), the 71 live-update tests elevated, all passed, and the Linux suite on the packaged binary, 2,013 tests, 1,562 passed, 0 failed, 451 skipped (results/b40full3 on linix); the database upgrade gates, the security scans, the fuzzers and the installer smoke test, 65 of 65. The JScript flaw is CVE-2026-100741 (CVSS 3.1 9.8), and the project's issue #43 is public: Security Hardening 17.11, the scripting page, the changes, the capabilities and the API reference name them. The project's download links work (the site has served HTTPS since 26 September; on 27 September they led to 6.3.4's files), so Installing on Linux and Running in a Container no longer say they work once it does. The copies of SECURITY.md and CONTRIBUTING.md give the day GitLab published the release, and the security policy's copy counts the 455 findings .gitlab/security-exceptions.yml accepts at the tag - the 169 of the SAST triage and the 286 that held the release scan - where the repository document still says 169; each header says where the copy differs. Three places said no pipeline had run on the fixed tree; one has, the schedule of 27 September 2026 on master 6bc09509d, which ran the update feed's pages and package-repos jobs alone, and they say so.

Christopher Holloway committed Sep 27, 2026

What the check of 2e1d40e against the tag v6.3.4 (8adce850a) found, put right. Changes Since 6.2.10, section 4e, named the seven High findings of GitLab's SAST as .gitlab/security-exceptions.yml at the tag does not: the seven are the crash-dump helper's dbghelp.dll, the Control Panel's elevated restart, DBSetupQuick handing DBUpdater the password on its command line (two), the backup index parser (two) and a MIME parser test that compared pointers into two arrays; the MySQL client's DLL search, the installer's command line and the %FILE% scanner path were found beside them. The audit item said an app password could change the account's keys; it could replace the own S/MIME key and publish an OpenPGP key, and a support session could change any of them or switch zero access off (CHANGELOG 6.3.4). Release Process: the note at step 9 said no pipeline had run the scans on the project's own runners; the first pipeline, on master 40c7d3e0c, ran dependency-scan, static-analysis and semgrep, which failed as they may without failing the pipeline, and semgrep-sast came in batch40. The note at step 12 said a tree lands on master by fast-forward with no merge request; that is so up to 6.3.4, and from the first landing after it a batch lands through an approved merge request (ContinuousIntegration.md, "Landing on master"). Installing hMailServer: the administrator password "may hold any character" and HM_ADMIN_PASSWORD "takes any character" were wider than the tag, which refuses a password holding U+0000 and whose /adminpassword switch drops a double quote; they now say what the variable carries. Control Panel Reference: the tag adds no page, text or index entry but rewrites one text, the one that explains ProtectStoredSecretsWithDPAPI, in every catalogue. Settings Reference: no passkey is taken while a relying party is set without PasskeyAllowedOrigins, not "until then". Regression Test Environment: the header says this copy gives the [Test] count where the document says roughly 2,000.

Christopher Holloway committed Sep 26, 2026

The wiki is brought up to the release itself, the signed tag v6.3.4 at 8adce850a: what it said of 6.3.4 had been read from master 92b8f9f63, which the tag's last batch, batch40, follows. Schema 6104, not 6103: 6.3.4 is sixty-four steps from 6.3.3's 6040, the last, 6103 to 6104, adding hm_fetchaccounts.faorigin (Constants.h:1224, formMain.cs:314 and the three create scripts at the tag); every header, table, count and diagram that gave 6103 as 6.3.4's schema says 6104, the upgrade table's step counts are each one more, the step tables gain the 6104 row, and where 6103 means the secrets-at-rest step it stays. No page calls 92b8f9f63 the release or the tree 6.3.4 was cut from any more: a page checked against it says so and that the tag adds a last batch, and a page that copies a repository document the tag leaves as it was says the document is the same at the tag. The copies of repository documents batch40 changes are brought up to the tag, hunk by hunk from the version each copy had reached, their own additions kept: Security Policy (the SSH-signed sums of a release made by hand and the two commands that check a download, an SBOM for every compiled file, a release held by its security scans, secrets refused before they are pushed; its note no longer says the document calls 6.3.3 the latest), Release Process (A release made by hand, the security gate, the SBOM jobs), Upgrading Guide (the installer's HM_ADMIN_PASSWORD, the named lock on MySQL and MariaDB, the probe that stops an upgrade on too old a server at 6041 and the repair of a half-done one), Contributing, Governance (rebuilt on the tag's document, which gives the GitLab roles the owner set on 26 September 2026; the map and the note on code-signing material kept), Assurance Case, Regulatory Scope, Third-Party Binaries, Fuzzing, Migrating the Database Backend and Regression Test Environment. The installer's password handling as the tag has it: the password page is skipped for HM_ADMIN_PASSWORD as for /adminpassword, the database step hands the password (or the live update's token, as token:<hex>) to DBSetupQuick and DBSetup in HM_ADMIN_PASSWORD and DBSetupQuick to DBUpdater the same way, never on a command line, the switch table has the variable, and the unattended upgrade takes either (Installing hMailServer, Upgrading hMailServer 18.4a). How to verify a download: 6.3.4's hmailserver-6.3.4-SHA256SUMS.txt and its .sig, checked with ssh-keygen -Y verify against .gitlab/allowed_signers and sha256sum -c, as SECURITY.md at the tag gives them, and each installer's and package's own SBOM (Installing hMailServer 4.1, Installing on Linux, Upgrading hMailServer 18.4 and 18.4c, home, Release Process, Project Handbook, Troubleshooting, Glossary, Assurance Case, Regulatory Scope). The /download/ links no longer wait on issue #30: the feed's site has had its certificate since 26 September 2026. Changes Since 6.2.10 gains batch 40 in section 4e (the audit before the release, GitLab's SAST and the release gate, the installer's password, the SBOMs and signed sums, the stable download links, the release chain and landing through merge requests, what the first pipeline found, Windows on ARM compiled), items 47 to 51 in section 5 (reserved domain names, a one-time code taken once, the outbound relay's OAuth2 token over TLS only, the fetchers and schema 6104, a pre-6.3.4 hash of a password above U+00FF refused), SQLOLEDB in item 38, the 6041 probe in item 36, and the installer's own PBKDF2 in item 39. Also what the tag makes false elsewhere: the suite has 3,809 [Test] attributes, not 3,698; hmailserver/docs holds 105 documents; Windows on ARM compiles and has never run, where it was "not built"; IMAP offers STARTTLS only before sign-in and TLS and COMPRESS=DEFLATE only after sign-in (Capabilities and Configuration); a parent-domain passkey relying party needs passkey_allowed_origins (Sign-in and Identity); the Settings Reference counts 193 hm_settings rows with PasskeyAllowedOrigins and WebPushLoopbackHttpForTests; and the Linux suite's CI job first ran in the pipeline of 26 September 2026 rather than never.

Christopher Holloway committed Sep 26, 2026

The wiki is brought up to the tree batch40 will contain: the branches ns-verifier, gl-project, gov, ci-hyg and tf, read from the repository on 26 September 2026. The copies of repository documents take the changes batch40 makes to them - CONTRIBUTING, SECURITY, RELEASE, GOVERNANCE, ASSURANCE-CASE, Fuzzing, RegulatoryScope, ThirdPartyBinaries and RegressionEnvironment - each header saying so. The seven links into /-/blob/master/.github/ point at .gitlab/allowed_signers, .gitlab/hmailserver.openvex.json, or name the GitHub workflow as being in the git history at v6.3.3, since .github/ is gone from the tree; the verify-tag commands read .gitlab/allowed_signers. What the sweep made false is put right: the PKGBUILD builds from the tag on GitLab; the Compose file and the chart name registry.gitlab.com/progressiverobot/hmailserver, a registry that is switched on and holds no image yet; OpenSSL's release archive comes from Debian's archive against its pinned hash; linuxdeploy is no longer downloaded; the build-inputs-1 files come from the package registry; the manifests name the installer's file there. The live update's third signer, the group hmailserver the project is to move to, with the project's id required, is on the update and security pages, the Settings Reference and the changes for 6.3.4, with the three GitLab settings that keep a server to the present path. Governance names Zain Ul Abidin as zainulabidin1990 on GitLab and gives the owner's rule that release tags are created by the Progressiverobot account alone. The /download/ links at updates.progressiverobot.com are given beside the permalinks, labelled as working once that site serves HTTPS (issue #30; it still failed at 05:16). Contributing gains a section of its own on the issue and merge-request templates, the Service Desk, the two boards and the labels as they are on GitLab.

Christopher Holloway committed Sep 26, 2026

What the check of the merged wiki found, put right. The landing page counted 61 pages, 34 guides and 'the other 60', and listed none of the four pages written for 6.3.4: it counts 65, 38 and 64, and Message Storage, Compliance and eDiscovery, Rooms and Equipment and Mail In to a Webhook have their rows where the sidebar groups them. Twelve sentences named the next release as 6.3.5; each now says the releases after 6.3.4, since nothing after 6.3.4 has a number yet. Installing on Linux said the AppImages began in 6.3.2, where the GitLab releases of 6.3.0 and 6.3.1 carry both of them. Capabilities and Configuration gave 23 per-account tables as today's count, where AccountStores.cpp declares 62 in 6.3.4, 24 carried and 38 exceptions; the old figures stay, labelled with 3233b0cc4. The Settings Reference counted 26 bootstrap keys, where build/ini-settings-baseline.txt has 29. And Stopping Spam said the quarantine digest needs its domain's switch and hour, when an account may hold a value of its own for both (EffectiveSetting.cpp, QuarantineDigestTask.cpp).

Christopher Holloway committed Sep 26, 2026

The eighteen pages that copy repository documents are copied again from master 92b8f9f63, the 6.3.4 release, so they say what the repository says on the day 6.3.4 is published. Each was brought forward from the version it was last copied from, 540347500, hunk by hunk, and the wiki's own additions were kept where they are still true. What the documents gained: the stored-secrets key in the command line, the high-availability runbook and the warm standby, which now say that it is made once, exported and imported on the other node, and what a node without it does (HM7495); the service account, the COM rule that a change to an item of a shared collection is written onto a copy until Save(), and MySQL's utf8mb4 step in the upgrading guide; database TLS and utf8mb4 in the backend migration; the fuzz job moved from GitHub Actions to GitLab CI's linux-fuzz; the Windows and Linux suites on GitLab CI in the regression environment; the security policy's scans on the project's own runner and its questionnaire pointer; the contributing guide's CI checks; MessageStore and QuickJS in the architecture; a pre-release tag's suffix and the pinned .NET runtime in the release checklist; the update verifier's two signers in the assurance case. Third-Party Binaries follows a rewritten document: the tree commits no executable binary, and the sections this copy had added about where the forty committed binaries lived and their dispositions described the tree before 11 September 2026, so they are gone. Regulatory Scope's note loses four of the five things it called out of date, which the repository has corrected, and its own Annex I table now says the installer has been Authenticode-signed since 6.3.1, that 6.3.x is the supported line, and what a new installation's secure defaults are. The wiki's labels that said "in the tree after 6.3.3, not yet released" now say what is new in 6.3.4, and each header names 92b8f9f63. Where the repository text itself is now stale - the release checklist's and Regulatory Scope's statements that no release can be cut while the chain is on GitHub, the contributing guide and the security policy naming 6.3.3 as the latest release, the assurance case pointing at the changelog's Unreleased section - the copy keeps the repository's words and the header says so where a reader would be misled; 6.3.4 was built and Authenticode-signed by hand and carries no Sigstore bundle.

Christopher Holloway committed Sep 26, 2026