/langs/tala and everything below it, which tala.run and earlier links still point to, now redirect permanently to the language list of the ViGet home page, like /langs, instead of answering 404. The README, the architecture guide and the bug-report template name the C, C++ and Objective-C catalogs.
Tala and its tools are no longer developed (2026-11-10), and tala.run, talac.tala.run, talafmt.tala.run and talalint.tala.run lead to a notice that answers 503. The catalog still offered Tala, talac, talafmt and talalint with "Visit the site" buttons into that notice, and described Tazel as the build system of Tala. - Tala, talac, talafmt and talalint leave the catalog in all four languages, as Xide did; their product pages answer 404. - The catalog names Tazel and Catch3. - Tazel is described as it is now: it builds C, C++, Objective-C, Objective-C++ and Zig from MODULE.kts and BUILD.kts, finds Clang, GCC and zig cc, builds for other triples, is incremental per action, and runs commands of tazel_custom.txt. Nothing it does not do yet (ViGet packages, plugins) is promised. - The site tests list the two products and route through them. Answers the review of website#58, which found the product links leading into the closed sites.
Tala and its tools are no longer developed as of 2026-11-10; Progmasoft puts its work into Tazel, a build system for C, C++, Objective-C, Objective-C++ and Zig. ViGet follows: - /langs/tala is removed. /langs/c, /langs/cpp and /langs/objc are the language catalogs (Objective-C++ packages belong to /langs/objc), served by one page, app/viget/langs/[language], which knows only these three; any other language is 404. /langs leads to the language list on the ViGet home page. - lib/viget-catalogs.ts: three open language catalogs with their own title, description and empty state in en-US, de-DE, ru-RU and he-IL; the Tazel catalog describes Tazel as the build system for C, C++, Objective-C, Objective-C++ and Zig. - The ViGet home, header, footer and metadata name C, C++ and Objective-C; "Explore Tala" becomes "Explore Tazel" (tazel.net), and the footer links Tazel instead of Tala. The sitemap lists the three catalogs. - Tests: the catalogs, their texts in every language, no text naming Tala, and the proxy routes. pnpm test (37), lint, check and build pass; next start answers /langs/c, /langs/cpp and /langs/objc with their pages, /langs/tala and /langs/zig with 404, and /langs with 308 to the language list.
Xide is no longer developed as of 2026-11-08 (Progmasoft/xide#29), so Progmaweb stops presenting it: - product.progmasoft.com: Xide leaves the catalog, its card and its detail page; /xide on the product host is a 404 like any unknown product. The catalog's description in every language names the Tala language with its tools and Catch3. - ides.progmasoft.com served only the IDE list and the Xide page, so the whole site goes: the pages under app/ides, its texts in every language, idesRoute and its host in the proxy, and both nginx server blocks. The certificate of progmasoft.com no longer has to name it. Tests: the catalog lists the remaining products and refuses xide.
The review found four promises the policies made beyond what exists: - ViGet takes no uploads from accounts yet; only Progmasoft publishes, through a server command. The Privacy Policy now says so, and that ViGet will record the IP address of each upload, for that one purpose and for the same time, once uploads open. ops/README.md tells the upload endpoint to do exactly that. - A yank leaves a JAR served by nginx and cached by Cloudflare for a year. The Security Policy says a malicious version is taken off ViGet and kept out of reach as evidence; ops/README.md gives the four steps: yank, move the JAR into a root-only quarantine, purge the Cloudflare cache, close the account. - The API cannot delete an account. ops/README.md gives the procedure support follows on a request from the account's address: a dump, then one transaction that removes the OpenIddict tokens and authorizations of the account, the applications it alone owns, and the account with its sessions and ownerships. - Pages allow Cloudflare's analytics script besides their own, and the Security Policy now names it. ops/README.md also records the nginx logs without client addresses on both servers, which make the Privacy Policy's statement about web-server logs true.
progmasoft.com/privacy and progmasoft.com/security publish the two policies in en-US, de-DE, ru-RU and he-IL, and the footer links both. The Privacy Policy says what an account keeps and that Progmasoft keeps an IP address for one purpose only: with a ViGet upload, to establish where an upload that turns out to be malicious software came from and to give it to the competent authorities. It says that no data, the IP address included, is sold, rented or traded. The Security Policy covers passwords, sessions, HTTPS, the ban on malicious software in ViGet and how to report a weakness. The registration form asks the person to accept both policies, and the API refuses a registration without that acceptance, with a password (acceptPolicies, a validation error of that field) or through Google: the start of a Google registration without acceptPolicies=true goes back to /register?google=policies-required, and the completion creates no account unless the authentication state carries the current version. An account keeps the version it accepted and the moment, in two new columns that schema step 2 adds; accounts created before it keep null. PolicyAcceptance.CurrentVersion and policyVersion on the web side name the same date, and a web test reads the C# constant to keep them equal.
The pages of progmasoft.com and its hosts had no content security policy. The proxy now creates a 128-bit nonce for every request and sends the policy both ways: on the request, so that Next marks its own inline scripts with the nonce, and on the response. The layout reads the nonce for the theme bootstrap. Every page is rendered on demand already, so none is served with a stale nonce. Scripts may come from the host, carry the nonce, or be Cloudflare's Web Analytics beacon from static.cloudflareinsights.com, which reports to cloudflareinsights.com. 'strict-dynamic' is left out, because browsers ignore host sources under it and the beacon is added by Cloudflare without a nonce. Styles allow inline ones; objects, framing and other base URLs are refused. There is no form-action: sign-in and OAuth consent end in redirects to other hosts, loopback addresses included, and browsers apply form-action to them. The development server also gets 'unsafe-eval' for its hot reload. Tests check the nonce and each directive; ARCHITECTURE.md describes the policy.
The API of the previous commit holds the catalog; this adds what people and Tazel reach. Pages: - /dslplugins/tazel lists the published plugins, read from the API on its loopback address, and says when there is none. - /dslplugins/tazel/<Publisher>/<Name> is the page of a plugin: its description, publisher, latest version, license, authors, homepage and repository, the plugins block that uses it, and every version with its date, plugin API, size, SHA-256, yanked mark and JAR. - /dslplugins/gradle opens the Gradle catalog. It only lists: Gradle takes com.progmasoft.tazel.plugin from the Gradle Plugin Portal. - The availability note says that Progmasoft publishes first and every account later. Texts are in the four languages of the site. Nginx (ops/nginx/progmaweb.conf): - On viget.progmasoft.com, index.json of a plugin goes to the API and the JARs come from /srv/viget/files with immutable caching; /api/ stays closed. - maven.progmasoft.com serves /srv/maven, whose /tazel holds tazel-api. ops/README.md describes the directories, their SELinux labels, the publish and yank commands, and how a release of Tazel copies the API into the Maven repository. Tests cover the texts in every language, the plugins block, the Gradle list, and that a page asks the API only for identifiers.