@foss.global/gitmanager 2.9.0 → 2.11.0

package/.smartconfig.json

@@ -36,7 +36,7 @@
     },
     "schemaVersion": 2
   },
-  "@git.zone/tsrust": {
+  "@git.zone/rsrepo": {
     "rustflags": ["-Cstrip=symbols"],
     "targets": [
       "linux_amd64",

package/changelog.md

@@ -1,5 +1,33 @@
 # Changelog
 
+## 2026-11-14 - 2.11.0
+
+### Features
+
+- `pushRefs()` pushes to `ssh://` remotes with an `sshKey` credential, `{ kind: 'sshKey', privateKey, hostKey }` (`IGitManagerRemoteSshKeyCredential` from `@foss.global/interfaces` 3.5.0).
+  - `remoteUrl` is `ssh://<user>@<host>[:<port>]/<path>`; a user, host or path outside its character set is refused before any process starts, never escaped. `hostKey` is the remote's host key as one OpenSSH key line, checked exactly and pinned: `ssh` accepts that key and no other. `privateKey` is an unencrypted PEM key the OpenSSH client reads.
+  - The push has the semantics of an `https` push: the engine reads the remote's ref advertisement over the system `ssh` client, checks every lease against it, and relays `git send-pack --stateless-rpc --atomic` to the remote as remote-curl does over HTTP, so the remote checks every lease again inside one atomic ref transaction and no command line grows with the updates. Results, `reason`s and `atomicPushUnsupported` are those of `https`.
+  - The key exists for the push only, as a `0600` file in a `0700` `remote-ssh-<pid>-<nonce>` directory under `transferDir`, removed once the advertisement is read and on every error, abort and timeout, and swept at the next engine start after a kill. It is never on a command line, in an environment variable, an error or a log; `ssh` reads no config file, uses no agent and inherits only `PATH`.
+  - A failure before the advertisement throws a `GitManagerError`, and nothing was pushed: `sshHostKeyMismatch` (the key was never offered), `sshAuthenticationFailed`, `remoteConnectionRefused`, `remoteConnectionFailed` (any other `ssh` failure, including a server that does not offer the pinned key's type) or `remoteProtocolError` (the remote did not answer with a Git advertisement). They are classified from `ssh`'s exit status 255 and the fixed texts of the local OpenSSH client, pinned against the system `ssh` in a test; the message carries the redacted `ssh` output for operator logs only.
+  - Messages and `remoteMessages` redact the key's text, its base64 body and each of its lines of 16 characters or more. A shorter last line of the key, which can be as short as 4 characters, is not redacted on its own, so a hook's output that happens to contain it stays intact.
+  - `remoteTransportMismatch` refuses, before anything runs, an `sshKey` credential with any URL but `ssh://`, an `ssh://` URL without an `sshKey` credential, and `caCertificates` with an `sshKey` credential.
+- Every push result carries `remoteMessages`, for `https` and `ssh` alike: the remote's `remote: ` lines, such as a hook's output, without the prefix and padding, in order; `[]` when there are none. At most 100 lines and 16 KiB, with `[remote messages truncated]` as the last element when the remote sent more; credentials are redacted as in `message`.
+- Minor release. Upgrade: requires `@foss.global/interfaces` ^3.5.0 (from ^2.4.0; the 3.0.0 break concerns forge release types gitmanager does not use). `TGitManagerErrorCode` gains `sshHostKeyMismatch`, `sshAuthenticationFailed`, `remoteConnectionRefused`, `remoteConnectionFailed`, `remoteProtocolError` and `remoteTransportMismatch`; an exhaustive `switch` over the codes needs them. `remoteMessages` is a required result field, so code that builds push results, such as a test double, must add it. An `ssh://` push URL without an `sshKey` credential threw a plain URL-policy error and now throws `remoteTransportMismatch`. Rollback below this release refuses `sshKey` credentials and returns results without `remoteMessages`; a consumer that uses either (the foss.global website S11 SSH canary) must be rolled back with it.
+
+## 2026-11-11 - 2.10.0
+
+### Features
+
+- `listRepositoryLfsPointers()` throws a `GitManagerError` with the new code `lfsScanLimitExceeded` when its scan exceeds a bound, instead of a plain error.
+  - Every bound carries the code: 250,000 reachable objects, 100,000 pointer candidates, 64 MiB of object listing or metadata and 128 MiB of candidate content. The message names the bound; the object and candidate messages are unchanged, and a byte bound's message now ends with it (`...: git stdout exceeded maximum of 67108864 bytes`) where before it ended at the step. Other scan failures stay plain errors with unchanged messages.
+  - Callers branch on the code instead of the message: a repository too large to scan has an unknown pointer set, not an empty one.
+  - Minor release. Upgrade: `TGitManagerErrorCode` gains `lfsScanLimitExceeded`; an exhaustive `switch` over the codes needs the new case. Rollback below this release throws the plain error again; a consumer that relies on the code (the foss.global website S6 verifier, which reports the LFS class `unread`) must be rolled back with it.
+
+### Maintenance
+
+- Update release tooling: @git.zone/tsrepo 2.0.0 replaces the deprecated tsbuild, tstest, tsrun and tsdoc, and @git.zone/rsrepo 1.3.0 replaces the deprecated tsrust (scripts, test imports and the `.smartconfig.json` key `@git.zone/rsrepo`); @types/node 26.6.6, pnpm 12.17.0.
+  - The native notices are regenerated with rsrepo, which lists only the Cargo packages a build compiles: `aho-corasick` is no longer among them (103 packages per target instead of 104).
+
 ## 2026-10-14 - 2.9.0
 
 ### Features