slachiewicz commented on issue #680: URL: https://github.com/apache/maven-wagon/issues/680#issuecomment-5225726273
I evaluated the fork concretely. Summary: it looks like the right move, it is smaller than a port to another library, and one thing I wrote in my previous comment was wrong. **Correcting myself first.** I suggested this be considered together with #503. That was misleading — #503 is a bug in wagon's own `if`/`else` in `AbstractJschWagon`, where the agent is consulted only when no key file is found, and it survives any library swap unchanged. Details on that issue. The two are independent. **What the coupling actually is.** JSch appears in 7 files, ~1565 lines, all under `wagon-ssh/.../providers/ssh/jsch/`. `wagon-ssh-common`'s `InteractiveUserInfo` mentions `com.jcraft.jsch.UserInfo` only in a javadoc `@see`, so the shared module has no compile dependency on it. **The fork.** `com.github.mwiede:jsch`, latest **2.28.6** (2026-07-29 — note it moved to semantic versioning, so the `0.2.x` numbers some searches return are stale). It keeps the `com.jcraft.jsch` package, its base bytecode is Java 8, and every type this provider uses is present: `JSch`, `Session`, `ChannelExec`, `ChannelSftp`, `SftpATTRS`, `UserInfo`, `UIKeyboardInteractive`, `HostKey`, `HostKeyRepository`, `IdentityRepository`, `ProxyHTTP`, `ProxySOCKS5`. **It is not a pure coordinate change**, though close. The `com.jcraft.jsch.agentproxy.*` artifacts have no counterpart: `ConnectorFactory`, `Connector` and `RemoteIdentityRepository`, imported at lines 45–47, are absent. The fork integrates the agent instead, as `AgentConnector`, `SSHAgentConnector`, `PageantConnector` and `AgentIdentityRepository`. So lines 135–144 need rewriting — about fifteen lines in one file — and the 2014-era `jsch.agentproxy` 0.0.9 jars go away. **The case is stronger than "unmaintained".** 0.1.55 has no `rsa-sha2-256`/`rsa-sha2-512`, so RSA key authentication against OpenSSH 8.8 and later — the default since 2021 — does not work; and it cannot read OpenSSH-v1 private keys, which `ssh-keygen` has produced by default since OpenSSH 7.8 in 2018. This is closer to a bug fix than an upgrade. **What changes for users.** The fork disables `ssh-rsa` (SHA-1) by default, so anyone deploying to an old server or appliance needs `-Djsch.server_host_key=+ssh-rsa -Djsch.client_pubkey=+ssh-rsa`. That belongs in the release notes verbatim. Ed25519 keys need Java 15+ at runtime or BouncyCastle on the classpath. Agent support has its own runtime prerequisites below Java 16. **On Apache MINA SSHD**, which was raised here in 2021 and is the natural ASF-internal answer: I looked, and it does not fit this provider today. `AbstractJschWagon` supports connecting *through* HTTP and SOCKS5 proxies at lines 160–187, and MINA SSHD 2.x has no client-side connect-through-proxy — apache/mina-sshd#481, with a fix deferred to the 3.0 filter-chain work. Porting onto 2.x would silently drop that for exactly the corporate users most likely to still deploy over scp. Worth revisiting when 3.0 lands; not now. Licensing looks clear: the fork keeps JSch's BSD/ISC terms, and both Camel (CAMEL-17835) and Commons VFS (VFS-837) have already made this switch. Before proposing this on dev@ it should be done on a branch and run with `-Dssh-tests`, which the POM excludes by default. Those tests use the embedded MINA server and exercise the host-key error paths at lines 225–228, which match on JSch's exception *message text* — the one place where a library swap could break something quietly. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
