tomaswolf commented on issue #767:
URL: https://github.com/apache/mina-sshd/issues/767#issuecomment-3070693448
Correct. Unfortunately the class `SkED25519PublicKey` references class
`net.i2p.crypto.eddsa.EdDSAPublicKey` in its public API, so this cannot be
fixed without breaking API.
We can fix this for sure in a future new version 3.0 (API breaks are fine on
major version number bumps), but in the 2.X stream, I don't see how it could be
done without breaking API.
Maybe we could risk an API break all the same? On the client side, I think
SK keys are currently unusable anyway since the required native interface and
configuration are missing, and if they existed, they aren't used, and on the
server side, all uses of SK keys are probably deep in the framework itself and
user code never cares about them: a server only needs to be able to reconstruct
the underlying ed25519 key from binary data sent as an sk-ed25519 key (or
possibly from authorized_keys).
In particular, fixing this would require changing
```
public class SkED25519PublicKey implements
SecurityKeyPublicKey<EdDSAPublicKey> {
```
to
```
public class SkED25519PublicKey implements SecurityKeyPublicKey<PublicKey> {
```
which widens the return type on `SkED25519PublicKey.getDelegatePublicKey()`
and is thus not binary compatible.
I wonder if there is existing user code that would have a problem with
this...
--
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: dev-unsubscr...@mina.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
