Subject: Future directions

Future directions

From: Etienne Samson <samson.etienne_at_gmail.com>
Date: Sat, 11 May 2019 22:41:14 +0200

Hello,

As some of you may be aware, I've been prodding at the code for a few months now, with quite a few "projects" at hand. I'm one of the current libgit2 maintainers, and we're using libssh2 as part of our SSH transport. Since right now maintainership time is kinda limited, and it can get far-reaching (and I've been asked to present it on the list), here I am.

I've got one open PR (https://github.com/libssh2/libssh2/pull/243 <https://github.com/libssh2/libssh2/pull/243>) that "overhauls" the CI system to use clar https://github.com/vmg/clar <https://github.com/vmg/clar>, which is the C "library" we use to write test cases, and was in the process of porting some of the examples to it (separate branch).
It does a valgrind run, which is nice, on all "buildable" backends, the downside is that it completely ignores autotools (which is otherwise fine).
Note that, currently, only the mbedTLS backend survives Valgrind. More details from Travis, but they might be out of date :
https://travis-ci.org/tiennou/libssh2/jobs/521032184#L736 <https://travis-ci.org/tiennou/libssh2/jobs/521032184#L736>
https://travis-ci.org/tiennou/libssh2/jobs/521032188#L884 <https://travis-ci.org/tiennou/libssh2/jobs/521032188#L884>

I've also "decided" that "struct string_buf" was to become our "git_buf" (https://libgit2.org/libgit2/#HEAD/type/git_buf <https://libgit2.org/libgit2/#HEAD/type/git_buf>), and started to use it as such, in the hope that its use could make memory ownership more "apparent" (I mean that, sometimes, even after taking a long look at a malloc call, with all the async code around, I feel like a quantum physicist and its proverbial cat). So some later PRs can have a dependency on this one.

On top of that, I've resurrected my "crypto backend" branch (at https://github.com/tiennou/libssh2/tree/fix/crypto/backend <https://github.com/tiennou/libssh2/tree/fix/crypto/backend>), which is an attempt at making the various backends more uniform (at least now an API difference results in the compiler complaining).

Then there's the half-done stuff, one that abstracts over the crypto digests, one that DRY up users of those digests that can actually benefit (a *good* chunk of code in kex.c), one that tries to make the PEM parsing consistent (my original test suite problem), and various other WIP things that bothered me along the journey.

So, well, there's a bunch, there's a release looming, some bugfixes left to do, I understand this might be out of scope, but let's keep the ball rolling, is there interest in things like those ? Should I tentatively file PRs/RFC for those ?

Regards,
Etienne Samson

--
samson.etienne_at_gmail.com

_______________________________________________
libssh2-devel https://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2019-05-11