Backporting to stretch: OpenSSL versions mix

[wferi at niif.hu]

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