> Le 13 mai 2019 à 15:16, Daniel Stenberg <daniel_at_haxx.se> a écrit :
>
> On Sat, 11 May 2019, Etienne Samson wrote:
>
>> 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 ?
>
> From my point of view these all sound like Good Things.
>
> As you probably have noticed, we have a small problem with maintainer presence (myself included) in the project so getting someone to actually review your code and merge it might not be a quick operation...
Not an issue, I can be patient with the more major changes, so if any of you "in the know" have an idea about what you feel would be the most bang-for-the-buck in that forest of new branches, that would be much appreciated.
My current "fear" is the test suite, I don't know what's the current test regimen, but I'm having a hard time pinpointing if my "new" tests' failures are caused by one of my changes, or if that specific feature/backend combination was already shaky to begin with. Is there something more to it that I missed ?
I've just noticed that AppVeyor builds OpenSSL, not WinCNG, and that the 4 "unknown" (to me, that's neither Travis, Azure, or AppVeyor) are the one that do WinCNG. Is that normal ? I'm just completely baffled that I missed that after bashing hard against CI…
If I were to propose a roadmap, it would look like this:
- merge the clar integration (mostly done, I'm just concerned about the Valgrind failures against OpenSSL & libgcrypt). I feel that point might need some discussion about build systems, as I'm one of the "modernist", can't write as complex things as CMake allows me too, yadda-yadda, but it's not that major.
- convert as much example code to clar test cases to have a baseline (most of the basic things all have an example written).
- merge the "generic" crypto backend, reaudit all uses of the crypto so that more error checking happens (things like #179).
- fix the few API issues that cause duplication (generic digests), or strange memory semantics (the encrypt/decrypt happens in place because of OpenSSL is "the baseline", even though all other backends support it, and there's a comment about it somewhere). I also had a vision that an iovec-taking crypto digest function would simplify some code, eg. `libssh2_digest_update_v(digest_ctx *ctx, struct iovec *data, size_t count)`. Stuff like calculating digests on disparate bunch of things (the kex code has lots of this) from an incoming packet.
After that, anything goes. I'm very interested by the PEM support, because it's currently the only thing I have failing tests for. I guess that technically, anyone willing to help is welcome to take a look at the ci/testcases branch, look at the examples I've ported, and either write a green testcase using the examples or file an issue with a broken testcase 😉.
Regards,
Etienne Samson
-- samson.etienne_at_gmail.com _______________________________________________ libssh2-devel https://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-develReceived on 2019-05-15