Update tests to (oqs-)openssh v8 about libssh HOT 5 CLOSED

This leads me to conclude that it should be possible to upgrade oqs-libssh testing to using oqs-openssh (v8) for testing -- with the goal to eliminate continued support for oqs-openssh v7.

-> Doable & sensible?

I expect so. At a quick glance it looked like the on-wire formats for PQ/hybrid keys and messages didn't change from v7 to v8, and so I thought there was a good chance these were compatible, and they should still interop over whatever intersection of ciphersuites remain common between the versions.

I first want to look at updating the templates for libssh to match v8's ciphersuites exactly instead of the intersection, so we can test interop with all of them. This would also eliminate the need for v7. If this proves problematic for some reason, then I'll look at just swapping v8 in for the tests.

As a side note, it would be good to document which (version of) libssh oqs-libssh has been branched off from. When checking the git log it seems to be an intermediate commit (d1abe26). Related question: Why is this repo no fork of https://git.libssh.org/projects/libssh.git?

The master branch here is the upstream's master branch, although I duplicated it manually. The local version of master is also the current branch-off point for this work. I can note that commit ID in the README. I didn't duplicate the other branches and tags from upstream, as I didn't see a need. (If there's a way in GitHub to make a fork from a repo not hosted on GitHub, I was unaware of it.) So even if it's not an "official" fork as far as GitHub is concerned, the history is still there to allow merging libssh's official master in to take updates when we want.

There have been no official releases of 0.10 yet, so I have no tag to snap to. The branch-off pointed ended up being the head of master at the time. A potentially interested customer also said they tracked master for their use, rather than the 0.9 release branch, and so I did so as well.

from libssh.

He built and ran the official libssh against OQS-OpenSSH v8, and that worked.

Little correction: I built and ran the official libssh against openssh v8 and that worked. No OQS involved. My goal was to ascertain that (current) libssh tests OK against (current) openssh. Hence the question whether it shouldn't be possible to (successfully) test oqs-libssh against oqs-openssh (v8).

the latter will need updating to be compatible.

This surely is right -- so maybe it would be more correct to re-title this issue to read "update libssh to current upstream libssh code base" (and expecting the test cases afterwards to immediately work OK with oqs-openssh (v8)).

from libssh.

Using OQS-OpenSSH v8 to test against the current libssh looks less likely. I just came upon one breaking change: when the shared secret is added to the buffer that gets hashed and signed as part of kex, for PQ/hybrid kex, OQS-OpenSSH v7 adds it as an ssh_string, which prepends the 4-byte length. v8, and official OpenSSH for all algorithms, write the bytes of the shared secret directly.

I don't see how the tests could have passed, given this, unless they were actually using a non-PQ/hybrid ciphersuite. If updating libssh to parity with v8 proves problematic for some reason, we'll have to take a closer look at running the tests against v8 with the current version.

from libssh.

So are you saying that you think the v7 and v8 branches should be incompatible but seem not to be? If so, that's weird and worth investigating.

from libssh.

I just realized I misread what @baentsch said. He built and ran the official libssh against OQS-OpenSSH v8, and that worked. That is not surprising. Somehow I had it in my head he ran the OQS fork against it and it worked.

So, we haven't yet experimentally verified the branches are incompatible, but this alone suggests we should expect them to be.

And this means it looks unlikely we can use OQS-OpenSSH v8 to test against the current OQS-libssh as-is, and the latter will need updating to be compatible.

from libssh.