Backporting to stretch: OpenSSL versions mix

[wferi at niif.hu]

Etienne Dysli Metref <etienne.dysli-metref at switch.ch> writes:

> On 20/03/2019 22.29, wferi at niif.hu wrote:
>
>> We don't need bpo9+2 versions anyway, because bpo9+1 weren't
>> uploaded officially.
>
> Yeah, this makes sense. (I went with +2 because I had already pushed a
> changelog with +1.)

You can update the changelog entry later without changing the version
number if you haven't uploaded that version yet.  Generally the special
version string UNRELEASED is used in packaging workflows with
incremental changelog creation, but I find those suboptimal.

>> 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.
>
> In order to exercise this patch, would there be a simpler meaningful
> test than building the whole SP and trying it?

There's an XMLTooling test which occasionally fails without the patch:

$ i=0; while ./xmltoolingtest SignatureTest testSignatureDSA; do i=$(($i+1)); done; echo $i

printed 20, 6, 71, 6, 106, 279, 20, 25, 2, 27, etc.  after the
"Signature Length incorrect" exception before I added the padding in
unstable.  Check if you still get this with your original backports
binary (with the padding dropped), then replace libxml-security-c20 and
see if you still get the errors.

> In 36577efb, you used `libssl1.0-dev (>= 1.0.1)` while other packages
> (xmltooling in debian/stretch for example) have `libssl1.0-dev |
> libssl-dev (<< 1.1.0~)`. The latter looks safer, but is it really better?

I just reverted to what it was.  The latter is backporting-safe, so if
you plan to backport the SP3 stack to jessie, it's a better choice.
-- 
Regards,
Feri