Backporting to stretch: OpenSSL versions mix
wferi at niif.hu
wferi at niif.hu
Wed Mar 20 21:29:56 GMT 2019
Etienne Dysli Metref <etienne.dysli-metref at switch.ch> writes:
> On 19/03/2019 10.38, wferi at niif.hu wrote:
>
>> Try reverting c03764e9a6f1efe97053d1a1aa5a1a3a61a875d6. Looks like
>> that fix requires OpenSSL 1.1.
>
> Thanks! It builds without error now. :)
OK, but if you run SignatureTest::testSignatureDSA of XMLTooling without
this patch in a loop, it will eventually fail.
>> Of course then you can expect occasional test failures, so
>> backporting it to OpenSSL 1.0 would be preferable. This is a
>> rather shady part of the code, the discussion died off without
>> reaching conclusion.
>
> I like crypto, but I also remember the lesson "don't write your own"
> ;) and since I'm not at ease with C++, I'll avoid introducing bugs here.
It isn't crypto, it's data representation...
> Would you prefer me to push a new version (~bpo9+2) of the packages
> that I rebuild with OpenSSL 1.0 or redo version ~bpo9+1 and force-push
> the debian/stretch-backports branch? This affects xml-security-c,
> xmltooling and opensaml (the ones I already uploaded on mentors.d.n).
Feel free to remove the mentors uploads, I don't use them. We don't
need bpo9+2 versions anyway, because bpo9+1 weren't uploaded officially.
I continued your work from before the changelog update in the new branch
wferi/debian/stretch-backports in the xml-security-c Salsa repo. It
contains an untested patch to make BN_bn2binpad() available under
OpenSSL 1.0, so that it builds at least.
--
Regards,
Feri
More information about the Pkg-shibboleth-devel
mailing list