Public Access
jaap-jan
e252d337d1
Every project in the repository stopped building, on a warning about a package
none of them had changed:
error NU1903: Warning As Error: Package 'SSH.NET' 2025.1.0 has a known high
severity vulnerability
GHSA-q939-rpr3-3284 was published after the pin was written. ScpClient.Download
in recursive mode takes the filenames the server sends and joins them to the
local destination without validating them, so a malicious or compromised SCP
server can name "../" its way out of the download directory and write anywhere
the client process can — CWE-22, 7.1, and the same shape as OpenSSH's
CVE-2019-6111 with the traversal left in. Everything up to and including
2025.1.0 is affected; 2026.0.0 is the fix.
◆ THIS APPLICATION WAS NEVER EXPOSED, AND THE UPGRADE IS STILL THE RIGHT ANSWER.
Nothing here constructs a ScpClient. File transfer is SftpClient throughout —
SshNetSftpSession is the only path to a remote file — so the vulnerable method
has no caller to reach it from. That makes this a hygiene bump rather than an
incident, and it is worth saying plainly because the alternative on offer was a
scoped NuGetAuditSuppress with that reasoning written beside it. A suppression is
what you reach for when there is nothing to upgrade TO. There is: the maintainers
shipped the fix, taking it costs two nullable annotations, and a suppression
would have left this repository carrying a known-vulnerable library and a comment
explaining why that is fine — which stays true only until somebody adds the first
ScpClient call and has no reason to look here.
BouncyCastle.Cryptography moves 2.6.2 -> 2.7.0 as a consequence, not a
preference. CentralPackageTransitivePinningEnabled makes the PackageVersion here
the resolved version for a transitive dependency, and SSH.NET 2026.0.0 asks for
2.7.0, so a pin left at 2.6.2 is a downgrade error rather than a version this
repository gets to choose. Its comment records the constraint so the next person
does not try to walk it back.
◆ THE RELEASE NOTES SAY NO BREAKING CHANGES. THE NULLABLE ANNOTATIONS DISAGREE.
ConnectionInfo.CurrentServerEncryption is now string? — correct of them, since it
really is null until the key exchange completes — and that is CS8601 at both
places this codebase reads a cipher off a live connection. Neither can observe
the null: SshNetConnection and SshNetSftpSession are only ever constructed after
ConnectAsync has been awaited, which is what their existing remarks already say
and why the reads are at construction rather than lazy.
Coalesced to string.Empty rather than silenced with !, because empty is already
this codebase's word for a cipher that could not be read. MainWindowViewModel's
NullIfEmpty exists for exactly that, TerminalWorkspace.GetSessionFacts already
hands over string.Empty on the same grounds, and the status bar collapses on it.
So the boundary keeps the interface's non-nullable string, no consumer changes,
and an unreachable null would degrade the way a real one already does.
SshNetConnection's remark asserted that SSH.NET types the property non-nullable
and that reading straight through was therefore honest rather than lazy. That
sentence is now false, and a comment contradicting the line beneath it is worse
than no comment, so it says what is actually true: the coalesce is there for the
annotation and the pre-key-exchange window this call site cannot be in.
The Android head needed its own restore. It is outside DodoSSH.slnx, so the
solution-wide --force-evaluate does not reach it, and left alone it would have
kept the vulnerable pin and gone stale under locked mode — the hazard
platform-flags.md records, arriving on schedule.
Heeding the warning left by the ILLink commit: --force-evaluate on Windows
rewrote all 39 lock files with CRLF, and 21 of them had no content change. Only
the 18 that really moved are here.
Verified with `dotnet build` at the root, no audit-disabling flags: 0 errors,
NU1903 gone, and the 21 remaining warnings are the pre-existing Meziantou/CA and
Avalonia ones that were present in the failing build too.
A library upgrade is not a version string, so the suites that exercise it were
run against live containers rather than trusted: 87 Ssh, 80 Terminal, 27
ObjectStore, 10 Transfer, none failing.
225 lines
14 KiB
XML
225 lines
14 KiB
XML
<Project>
|
|
<PropertyGroup>
|
|
<ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
|
|
<CentralPackageTransitivePinningEnabled>true</CentralPackageTransitivePinningEnabled>
|
|
</PropertyGroup>
|
|
<!--
|
|
Versions are pinned here for the whole solution. Packages are added per milestone
|
|
rather than all at once, so that every entry is one we have actually verified and
|
|
restored. See docs/adr/ for the choices behind the notable ones.
|
|
-->
|
|
<ItemGroup Label="ASP.NET Core">
|
|
<PackageVersion Include="Microsoft.AspNetCore.OpenApi" Version="10.0.10" />
|
|
<PackageVersion Include="Microsoft.AspNetCore.Authentication.JwtBearer" Version="10.0.10" />
|
|
</ItemGroup>
|
|
<ItemGroup Label="Endpoints">
|
|
<!--
|
|
FastEndpoints drags FluentValidation, JobQueues and Messaging in behind it. None of the
|
|
three are used: validation lives in the feature services and is banned from moving into a
|
|
Validator<T> (see BannedSymbols.txt and ADR 0008), and there is no message bus. They are
|
|
left as plain transitives rather than declared here, because declaring a transitive under
|
|
central transitive pinning is a standing promise to keep its version current, and these are
|
|
not ours to steer. Declare one only to force a version forward for an advisory, as the
|
|
group below does.
|
|
-->
|
|
<PackageVersion Include="FastEndpoints" Version="8.2.0" />
|
|
</ItemGroup>
|
|
<ItemGroup Label="Pinned transitive dependencies">
|
|
<!--
|
|
Microsoft.AspNetCore.OpenApi 10.0.10 resolves Microsoft.OpenApi 2.0.0, which is
|
|
covered by GHSA-v5pm-xwqc-g5wc (high: circular schema references can terminate
|
|
OpenAPI parsing; vulnerable <= 2.7.4, patched in 2.7.5). Pinned forward within the
|
|
2.x major that ASP.NET Core 10 targets. Revisit when the ASP.NET Core package
|
|
itself moves off 2.0.0.
|
|
-->
|
|
<PackageVersion Include="Microsoft.OpenApi" Version="2.11.0" />
|
|
<!--
|
|
Microsoft.EntityFrameworkCore.Sqlite 10.0.10 resolves SQLitePCLRaw 2.1.11, whose bundled
|
|
SQLite build is covered by GHSA-2m69-gcr7-jv3q (high). 2.1.12 is the fix and is a patch bump
|
|
inside the minor EF asks for, so nothing needs to move. Pinned as a family: the bundle, the
|
|
core, the provider and the native library ship in lockstep and a mixed set is a loader error
|
|
at runtime rather than a build failure.
|
|
|
|
SQLitePCLRaw 3.x exists and is deliberately not used here. EF Core 10 is built against 2.1.x,
|
|
and 3.0 is also where bundle_e_sqlcipher was deprecated — which is one of the reasons the
|
|
local cache does not use SQLCipher at all. See DodoSSH.Client.Storage.
|
|
-->
|
|
<PackageVersion Include="SQLitePCLRaw.bundle_e_sqlite3" Version="2.1.12" />
|
|
<PackageVersion Include="SQLitePCLRaw.core" Version="2.1.12" />
|
|
<PackageVersion Include="SQLitePCLRaw.lib.e_sqlite3" Version="2.1.12" />
|
|
<PackageVersion Include="SQLitePCLRaw.provider.e_sqlite3" Version="2.1.12" />
|
|
</ItemGroup>
|
|
<ItemGroup Label="Persistence">
|
|
<!--
|
|
EF Core pinned explicitly. The Npgsql provider asks only for 10.0.4 while
|
|
Microsoft.EntityFrameworkCore.Design pulls 10.0.10, and because Design is
|
|
PrivateAssets=all that higher version does not flow to referencing projects — which
|
|
produces a CS1705 in any test project that references Infrastructure. Pinning here lifts
|
|
every project to one version via central transitive pinning.
|
|
-->
|
|
<PackageVersion Include="Microsoft.EntityFrameworkCore" Version="10.0.10" />
|
|
<PackageVersion Include="Microsoft.EntityFrameworkCore.Relational" Version="10.0.10" />
|
|
<PackageVersion Include="Npgsql.EntityFrameworkCore.PostgreSQL" Version="10.0.3" />
|
|
<PackageVersion Include="Microsoft.EntityFrameworkCore.Design" Version="10.0.10" />
|
|
<!--
|
|
Verified compatible with EF 10 before adopting; the plan flagged this package as
|
|
historically lagging EF majors. Fallback if it ever blocks an upgrade is explicit
|
|
HasColumnName in every IEntityTypeConfiguration: more code, zero risk.
|
|
-->
|
|
<PackageVersion Include="EFCore.NamingConventions" Version="10.0.1" />
|
|
<!--
|
|
The client's local cache. Plain SQLite, deliberately not SQLCipher: the rows are already
|
|
ciphertext, so an encrypted database file would add a native dependency and a licence
|
|
obligation to protect bytes that are protected already. SQLitePCLRaw's own
|
|
bundle_e_sqlcipher is deprecated as of 3.0 besides. See DodoSSH.Client.Storage.
|
|
-->
|
|
<PackageVersion Include="Microsoft.EntityFrameworkCore.Sqlite" Version="10.0.10" />
|
|
</ItemGroup>
|
|
<ItemGroup Label="Cryptography">
|
|
<!--
|
|
NSec wraps libsodium. Chosen over the BCL because .NET has no X25519 or Ed25519, and
|
|
because ChaCha20Poly1305.IsSupported is false on macOS, which rules out the in-box
|
|
AEAD for a cross-platform client. NSec also holds key material in libsodium's
|
|
guarded, non-swappable memory, which a byte[] cannot do. See docs/crypto.md.
|
|
|
|
26.4.0 targets net9.0; net10.0 consumes it by forward compatibility. Native binaries
|
|
arrive via the libsodium package, pinned here because central transitive pinning
|
|
requires it to be declared.
|
|
-->
|
|
<PackageVersion Include="NSec.Cryptography" Version="26.4.0" />
|
|
<PackageVersion Include="libsodium" Version="1.0.22" />
|
|
<!--
|
|
Managed differential oracle for the crypto test suite only. Also what SSH.NET pulls in,
|
|
so central transitive pinning makes this pin its floor too: 2.7.0 is what SSH.NET
|
|
2026.0.0 asks for, and pinning below that is a downgrade error rather than a preference.
|
|
-->
|
|
<PackageVersion Include="BouncyCastle.Cryptography" Version="2.7.0" />
|
|
</ItemGroup>
|
|
<ItemGroup Label="Desktop client">
|
|
<!--
|
|
SSH.NET already covers PTY shells, all three auth methods, ed25519/RSA/ECDSA, encrypted
|
|
keys including PuTTY .ppk, SFTP, and local/remote/dynamic forwarding. The gaps are
|
|
agent forwarding (needs an upstream change; de-scoped from v1) and being handed a
|
|
pre-connected Stream — it performs its own socket connect, which is why the relay and
|
|
ProxyJump both go through a loopback TCP bridge. See docs/adr/.
|
|
|
|
2026.0.0 is the fix for GHSA-q939-rpr3-3284, a path traversal in ScpClient.Download's
|
|
recursive mode that trusts server-supplied names (everything up to and including
|
|
2025.1.0 is affected). Nothing here uses ScpClient — transfers go through SftpClient —
|
|
so this was an upgrade on principle rather than an exposure, and the release notes
|
|
list no breaking changes over 2025.1.0.
|
|
-->
|
|
<PackageVersion Include="SSH.NET" Version="2026.0.0" />
|
|
<!--
|
|
The S3 client, for buckets as a remote in the file browser. First-party, Apache-2.0, and
|
|
managed only — no native assets — which is the bar this file sets for anything that gets
|
|
pinned. Taken rather than hand-rolled because the alternative here is implementing SigV4
|
|
request signing, and unlike the openssh-key-v1 container (which had no library at all) a
|
|
maintained implementation of this exists and is the one every S3-compatible service tests
|
|
against.
|
|
|
|
AWSSDK.Core is declared and pinned forward. What AWSSDK.S3 4.0.101.6 resolves on its own is
|
|
4.0.1, which is covered by GHSA-9cvc-h2w8-phrp — low severity, and this repository builds
|
|
with NuGet audit as errors, so "low" is not a reason to carry it. 4.0.100.9 is past it and
|
|
inside the same major. Same treatment as the OpenApi and SQLitePCLRaw entries above, and the
|
|
same standing obligation: this is now ours to keep current.
|
|
-->
|
|
<PackageVersion Include="AWSSDK.S3" Version="4.0.101.6" />
|
|
<PackageVersion Include="AWSSDK.Core" Version="4.0.100.9" />
|
|
<!--
|
|
Avalonia 12.1.0, with the WebView control on 12.0.1 — the latest it has shipped. Its
|
|
dependency is Avalonia >= 12.0.0 with no upper bound and it targets net10.0, so the skew
|
|
is fine. Checked rather than assumed, because a control package lagging the core version
|
|
is exactly where a silent runtime mismatch would hide.
|
|
-->
|
|
<PackageVersion Include="Avalonia" Version="12.1.1" />
|
|
<PackageVersion Include="Avalonia.Desktop" Version="12.1.1" />
|
|
<!--
|
|
The Android head. Same core version as the desktop one, which is not a courtesy: the two heads
|
|
share every view model, so a version skew between them would be a skew inside one object graph.
|
|
-->
|
|
<PackageVersion Include="Avalonia.Android" Version="12.1.1" />
|
|
<PackageVersion Include="Avalonia.Themes.Fluent" Version="12.1.1" />
|
|
<PackageVersion Include="Avalonia.Fonts.Inter" Version="12.1.1" />
|
|
<PackageVersion Include="Avalonia.Controls.WebView" Version="12.0.1" />
|
|
<!--
|
|
Lets a test lay out real XAML and measure it, which is the only way this repository can catch a
|
|
control clipped off the bottom of a column — the defect this window has already shipped once. Pinned
|
|
to the core version exactly rather than allowed to drift: the whole value of the harness is that the
|
|
numbers it measures are the numbers the application renders.
|
|
-->
|
|
<PackageVersion Include="Avalonia.Headless" Version="12.1.1" />
|
|
<!--
|
|
Source-generated MVVM, so there is no reflection and trimming stays viable. ReactiveUI's one
|
|
real advantage is observable composition over streams, and the place that would help — the
|
|
terminal data plane — is Pipelines and channel code rather than view models.
|
|
-->
|
|
<PackageVersion Include="CommunityToolkit.Mvvm" Version="8.4.2" />
|
|
<!--
|
|
Packaging and self-update for the Windows desktop head. MIT, and on net10.0 it declares no
|
|
dependencies at all — the whole package is one managed assembly, so it restores and compiles
|
|
on the Linux runner that builds the solution even though the thing it produces only runs on
|
|
Windows. That mattered enough to check: a per-OS conditional PackageReference is not available
|
|
here, because it would make packages.lock.json depend on the operating system and CI's locked
|
|
restore would then fail on whichever platform did not write it.
|
|
|
|
MSIX would have been the platform-native choice and is ruled out rather than deprioritised: a
|
|
packaged app runs WebView2 in an AppContainer where loopback is blocked, and the terminal data
|
|
plane is a loopback WebSocket. See docs/platform-flags.md.
|
|
|
|
The update feed this is pointed at is the project's own forge and never a DodoSSH deployment.
|
|
That is ADR 0011 rule 2, and it is the reason the repository URL in VelopackUpdateSource is a
|
|
constant rather than a setting: an operator who could answer the update check could pin a
|
|
chosen user to a known-vulnerable build. See docs/adr/0013-desktop-distribution-and-updates.md.
|
|
-->
|
|
<PackageVersion Include="Velopack" Version="1.2.0" />
|
|
</ItemGroup>
|
|
<ItemGroup Label="Versioning">
|
|
<!--
|
|
One version for the whole repository, derived from the nearest v* git tag. The tag was already
|
|
the version of record — ci.yml's "work out the tags" step parses refs/tags/v* for the docker
|
|
image — and nothing set an assembly version at all, so every binary reported the SDK's default
|
|
1.0.0 and the API served that as its ServerVersion. Deriving from the tag makes those one
|
|
number instead of two that can disagree.
|
|
|
|
MinVer's one real failure mode is that it answers plausibly rather than failing: a shallow
|
|
clone with no tags yields 0.0.0-alpha.0.N. Here that is not cosmetic — Velopack compares the
|
|
version baked into a package against the one it is running, so a wrong answer is a client that
|
|
never updates. Hence two guards in ci.yml: fetch-depth 0 on every checkout, and a step on tag
|
|
builds that fails if the computed version and the tag disagree.
|
|
-->
|
|
<PackageVersion Include="MinVer" Version="7.0.0" />
|
|
</ItemGroup>
|
|
<ItemGroup Label="Analyzers">
|
|
<PackageVersion Include="Microsoft.CodeAnalysis.BannedApiAnalyzers" Version="5.6.0" />
|
|
<PackageVersion Include="Microsoft.CodeAnalysis.PublicApiAnalyzers" Version="5.6.0" />
|
|
<PackageVersion Include="Meziantou.Analyzer" Version="3.0.137" />
|
|
</ItemGroup>
|
|
<ItemGroup Label="Testing">
|
|
<!--
|
|
xunit.v3 runs on Microsoft.Testing.Platform, not VSTest. Microsoft.NET.Test.Sdk and
|
|
coverlet.collector are VSTest components: referencing them alongside MTP raises
|
|
MTP0001 and their collector never runs, so neither is referenced.
|
|
|
|
No coverage collector yet. Microsoft.Testing.Extensions.CodeCoverage 18.9.0 pulls
|
|
Microsoft.Testing.Platform.MSBuild 1.9.1, which is built against MTP 1.x and throws
|
|
TypeLoadException on IDataConsumer against the MTP 2.3.x that xunit.v3 3.2.2 brings.
|
|
Coverage gates are an M3 concern (90% on Domain and Authorization); pick a version
|
|
aligned with MTP 2.x then rather than carrying a broken dependency until it matters.
|
|
-->
|
|
<PackageVersion Include="xunit.v3" Version="3.2.2" />
|
|
<PackageVersion Include="Shouldly" Version="4.3.0" />
|
|
<PackageVersion Include="NSubstitute" Version="6.0.0" />
|
|
<PackageVersion Include="Testcontainers.PostgreSql" Version="4.13.0" />
|
|
<!-- Generic container, for the OpenSSH server the SSH suite talks to. -->
|
|
<PackageVersion Include="Testcontainers" Version="4.13.0" />
|
|
<PackageVersion Include="Respawn" Version="7.0.0" />
|
|
<PackageVersion Include="Microsoft.AspNetCore.Mvc.Testing" Version="10.0.10" />
|
|
<!--
|
|
Stands in for the identity provider so integration tests exercise the real JwtBearer
|
|
pipeline. A TestAuthHandler that bypasses it would hide exactly the claim-mapping
|
|
mistakes that cause real authorization holes.
|
|
-->
|
|
<PackageVersion Include="WireMock.Net" Version="2.13.0" />
|
|
</ItemGroup>
|
|
</Project> |