Bug#848890: [Pkg-swan-devel] Bug#848890: polished remaining delta for re-review

[Simon Deziel]

On 2017-12-05 04:12 AM, Yves-Alexis Perez wrote:
> On Tue, 2017-12-05 at 08:31 +0100, Christian Ehrhardt wrote:
>> On Mon, Dec 4, 2017 at 9:56 PM, Yves-Alexis Perez  wrote:
>>> On Thu, 2017-11-30 at 16:31 +0100, Christian Ehrhardt wrote:
 Pushed it to the same debian-submission-nov2017 branch as before.
>>>
>>> Thanks,
>>>
>>> I don't really have good news though. I took a look and first, it seems
>>> that
>>> the git commit entries aren't really good. git log --format=oneline is
>>> barely
>>> readable, for example.
>>
>> Yeah the format was meant for another tool which made debian/changelog
>> entries out of it.
>> I could rewrite them the next time we talk about this topic in
>> probably 6 months :-)
> 
> Ok :)
>>
>>> For the commit contents:
>>>
>>> 1aa409a5 (mass plugin enable): NACK again; I won't enable that many stuff
>>> (and
>>> especially not in one go)
>>
>> I can understand, this all is just a suggestion.
>> Things came up (way before my time) due to user requests and if I did
>> history research correctly at that point it was decided to enable a
>> few more to not get requests for extra plugins all the time.
>> You are not taking all - that is fine, if you take a few that is good
>> enough.
> 
> It might help to do one commit per feature (maybe one commit for consistent
> groups) too so I can cherry-pick commits.
> 
>> Since I wasn't part of that old enabling activity I wanted to sync
>> with you here and even considered dropping a bunch of them next (post
>> LTS) cycle.
>> Nobody remembers the particular reasons for some of them, so for all
>> that make no sense to you in a hard enough way to not even enable them
>> for "-extra-plugins I'd consider triggering bug reports in Ubuntu if
>> somebody really used them.
> 
> Yes, that could make sense. If no one asks for them, I prefer to keep them
> disabled in order to reduce attack surface, because strongSwan is really a
> beast. Even if there's the plugin architecture, plugins are default-enabled
> and that means a lot of exposed stuff.
> 
> For stuff like algorithms, there's also the security tradeoffs of default
> config. I don't want to endorse stuff that's too young for my test (like the
> various PQ bits) or too exotic.

That's one reason why it would be great to have AES-GCM available like
ChaCha20/Poly1305. Those are the 2 most reputable AEAD ciphers available
today.

>> I'm fine either way - all I request is that we look and discuss about
>> things every half year or so.
>> So far we benefitted both each time we did, so it isn't wasted time.
> 
> Indeed :)
>>
>>> d83c243b (duplicheck disable): one good reason for the NACK just above:
>>> it's
>>> not enabled in Debian, you just enabled it in 1aa409a5 :)
>>
>> That is a bummer, at the time I saw it the first time I thought it was
>> enabled in Debian and since then carried on.
>> /me feels ashamed and obviously drops that part :-)
> 
> No problem :)
>>
>>> 766d4f0d (ha disable): not really sure; it's way easier to have a custom
>>> kernel than a custom strongSwan
>>
>> Ok, so you had real cases where you or a Debian user used that?
>> Very interesting POV, I think neither is easier than the other but I
>> see your point.
> 
> I didn't, but I know for sure that building and using a custom kernel is way
> easier than using a custom strongSwan package.
>>
>>> 85150f06 (kernel-libipsec enable): for reference, this is #739641 and I'm
>>> still not sure I like it. I might pick it but end up disabling it before
>>> release
>>
>> It is disabled by default as Simon already outlined for the reason to
>> be an opt-in.
> 
> Yes, by “disabling” I meant more disabling at build time.
>>
>>> a587dc11 (TNC move): I might pick this one because TNC is pretty
>>> standalone
>>> per-se and it might make sense to split it, but really that's a lot of new
>>> binary packages.
>>
>> I understand the new-queue fight, but it really came handy for users
>> who wanted it standalone.
> 
> Do you have pointers on people asking for it?

I would appreciate not having the TNC bits pulled unless I really need
them. I never had to deal with TNC so I don't know if a standalone
package (cb55e029b7) make sense.

On the other hand, I routinely need EAP-MSCHAPv2 and XAUTH and in such
cases we don't want the TNC bits that comes from
libcharon-extra-plugins. I think that Christian's proposal of having
libcharon-standard-plugins (0ef9c2ad736) providing EAP-MSCHAPv2 and
XAUTH is a good compromise and I wouldn't mind if the TNC stuff remained
in libcharon-extra-plugins.

>>> 8dbf648b7 (libcharon-standard-plugin): I can understand the rationale
>>> (plugins
>>> for common password-based mobile VPN setup), but I don't really like it. I
>>> don't really like adding a new binary package, and the name is definitely
>>> not
>>> good. Also, as far as I understand it, the plugins are useful when you're
>>> actually configuring a client/roadwarrior to imitate a mobile client with
>>> its
>>> limitations. I don't think 

Bug#848890: [Pkg-swan-devel] Bug#848890: polished remaining delta for re-review

[Christian Ehrhardt]

> I'll come back with the revised version later today with all we
> discussed here so far.

To retain the old hashes used in the discussion before I pushed to a
new branch this time.
Branch: " debian-submission-nov2017-v2"

Get it from:
$ git clone -b debian-submission-nov2017-v2
https://git.launchpad.net/~paelzer/ubuntu/+source/strongswan
Or via browser at [1]

Changes overall:
- rewrote commit messages to match your needs for proper --oneline entries
- added Changelog changes as sibling commits to the changes instead of
a big final commit
- reordered with changes more likely to be taken first (less cherry-pick noise)
- added some more arguments of the discussion into the commit messages
- removed changes we identified that I will drop them in Ubuntu instead
- added breaks/replaces on the right Debian version for the two pkg
moves that are left

I can't bribe you to love the Debian new queue process, but for the
remaining cases (TNC* and libcharon-standard-plugins) I think at least
the reasons are clear now.

And for the "mass enablement" change, doesn't this come from the POV
as keeping the ha-plugin which needs a special kernel?
They are special plugins (mostly) added to the -extra plugins package
for just the same reason - usable without rebuild (we can move md4 to
extra as well if you want).


[1]: 
https://code.launchpad.net/~paelzer/ubuntu/+source/strongswan/+git/strongswan/+ref/debian-submission-nov2017-v2

Bug#848890: [Pkg-swan-devel] Bug#848890: polished remaining delta for re-review

[Yves-Alexis Perez]

On Tue, 2017-12-05 at 08:31 +0100, Christian Ehrhardt wrote:
> On Mon, Dec 4, 2017 at 9:56 PM, Yves-Alexis Perez  wrote:
> > On Thu, 2017-11-30 at 16:31 +0100, Christian Ehrhardt wrote:
> > > Pushed it to the same debian-submission-nov2017 branch as before.
> > 
> > Thanks,
> > 
> > I don't really have good news though. I took a look and first, it seems
> > that
> > the git commit entries aren't really good. git log --format=oneline is
> > barely
> > readable, for example.
> 
> Yeah the format was meant for another tool which made debian/changelog
> entries out of it.
> I could rewrite them the next time we talk about this topic in
> probably 6 months :-)

Ok :)
> 
> > For the commit contents:
> > 
> > 1aa409a5 (mass plugin enable): NACK again; I won't enable that many stuff
> > (and
> > especially not in one go)
> 
> I can understand, this all is just a suggestion.
> Things came up (way before my time) due to user requests and if I did
> history research correctly at that point it was decided to enable a
> few more to not get requests for extra plugins all the time.
> You are not taking all - that is fine, if you take a few that is good
> enough.

It might help to do one commit per feature (maybe one commit for consistent
groups) too so I can cherry-pick commits.

> Since I wasn't part of that old enabling activity I wanted to sync
> with you here and even considered dropping a bunch of them next (post
> LTS) cycle.
> Nobody remembers the particular reasons for some of them, so for all
> that make no sense to you in a hard enough way to not even enable them
> for "-extra-plugins I'd consider triggering bug reports in Ubuntu if
> somebody really used them.

Yes, that could make sense. If no one asks for them, I prefer to keep them
disabled in order to reduce attack surface, because strongSwan is really a
beast. Even if there's the plugin architecture, plugins are default-enabled
and that means a lot of exposed stuff.

For stuff like algorithms, there's also the security tradeoffs of default
config. I don't want to endorse stuff that's too young for my test (like the
various PQ bits) or too exotic.
> 
> I'm fine either way - all I request is that we look and discuss about
> things every half year or so.
> So far we benefitted both each time we did, so it isn't wasted time.

Indeed :)
> 
> > d83c243b (duplicheck disable): one good reason for the NACK just above:
> > it's
> > not enabled in Debian, you just enabled it in 1aa409a5 :)
> 
> That is a bummer, at the time I saw it the first time I thought it was
> enabled in Debian and since then carried on.
> /me feels ashamed and obviously drops that part :-)

No problem :)
> 
> > 766d4f0d (ha disable): not really sure; it's way easier to have a custom
> > kernel than a custom strongSwan
> 
> Ok, so you had real cases where you or a Debian user used that?
> Very interesting POV, I think neither is easier than the other but I
> see your point.

I didn't, but I know for sure that building and using a custom kernel is way
easier than using a custom strongSwan package.
> 
> > 85150f06 (kernel-libipsec enable): for reference, this is #739641 and I'm
> > still not sure I like it. I might pick it but end up disabling it before
> > release
> 
> It is disabled by default as Simon already outlined for the reason to
> be an opt-in.

Yes, by “disabling” I meant more disabling at build time.
> 
> > a587dc11 (TNC move): I might pick this one because TNC is pretty
> > standalone
> > per-se and it might make sense to split it, but really that's a lot of new
> > binary packages.
> 
> I understand the new-queue fight, but it really came handy for users
> who wanted it standalone.

Do you have pointers on people asking for it?
> 
> > 7629c11a7 (test-vectors move): NACK, what's the justification? Also it'll
> > need
> > some breaks/replaces
> > f9e7f9007 (CCN move): NACK, what's the justification? Also, the
> > break/replace
> > have the ubuntu version in them, which is wrong for Debian.
> 
> Sorry for not converting the breaks/replaces for those two to Debian
> versions properly.
> @Simon - thanks for helping with arguments! (he is one of the
> known-to-me Ubuntu Strongswan users).
> But in this case it really is CCM.
> 
> Every time I come back to this I hate that I only inherited this delta
> - too often I don't know and sometimes even fail to find the reasons
> for them.
> In this case due to your Nack I once again spent some more time to
> search for its history.
> I didn't find any and honestly I don't care anymore - let me drop
> these two changes on my end (with Ubuntu breaks/replaces :-) ).

Ok :)
> 
> > 13300d3bf (libstrongswan.install reorder): ACK, I could pick it if there
> > was
> > an isolated changelog entry with it
> 
> I'll on rebase let this be a change+CL entry.
> I'll also reorder the likely to pick changes at the top so you have
> not CL conflicts.


Thanks, that'd be really helpful.
> 
> > 4fe0861e2 (kernel-netlink conffiles): NACK, these 

Bug#848890: [Pkg-swan-devel] Bug#848890: polished remaining delta for re-review

[Christian Ehrhardt]

On Mon, Dec 4, 2017 at 9:56 PM, Yves-Alexis Perez  wrote:
> On Thu, 2017-11-30 at 16:31 +0100, Christian Ehrhardt wrote:
>> Pushed it to the same debian-submission-nov2017 branch as before.
>
> Thanks,
>
> I don't really have good news though. I took a look and first, it seems that
> the git commit entries aren't really good. git log --format=oneline is barely
> readable, for example.

Yeah the format was meant for another tool which made debian/changelog
entries out of it.
I could rewrite them the next time we talk about this topic in
probably 6 months :-)

> For the commit contents:
>
> 1aa409a5 (mass plugin enable): NACK again; I won't enable that many stuff (and
> especially not in one go)

I can understand, this all is just a suggestion.
Things came up (way before my time) due to user requests and if I did
history research correctly at that point it was decided to enable a
few more to not get requests for extra plugins all the time.
You are not taking all - that is fine, if you take a few that is good enough.
Since I wasn't part of that old enabling activity I wanted to sync
with you here and even considered dropping a bunch of them next (post
LTS) cycle.
Nobody remembers the particular reasons for some of them, so for all
that make no sense to you in a hard enough way to not even enable them
for "-extra-plugins I'd consider triggering bug reports in Ubuntu if
somebody really used them.

I'm fine either way - all I request is that we look and discuss about
things every half year or so.
So far we benefitted both each time we did, so it isn't wasted time.

> d83c243b (duplicheck disable): one good reason for the NACK just above: it's
> not enabled in Debian, you just enabled it in 1aa409a5 :)

That is a bummer, at the time I saw it the first time I thought it was
enabled in Debian and since then carried on.
/me feels ashamed and obviously drops that part :-)

> 766d4f0d (ha disable): not really sure; it's way easier to have a custom
> kernel than a custom strongSwan

Ok, so you had real cases where you or a Debian user used that?
Very interesting POV, I think neither is easier than the other but I
see your point.

> 85150f06 (kernel-libipsec enable): for reference, this is #739641 and I'm
> still not sure I like it. I might pick it but end up disabling it before
> release

It is disabled by default as Simon already outlined for the reason to
be an opt-in.

> a587dc11 (TNC move): I might pick this one because TNC is pretty standalone
> per-se and it might make sense to split it, but really that's a lot of new
> binary packages.

I understand the new-queue fight, but it really came handy for users
who wanted it standalone.

> 7629c11a7 (test-vectors move): NACK, what's the justification? Also it'll need
> some breaks/replaces
> f9e7f9007 (CCN move): NACK, what's the justification? Also, the break/replace
> have the ubuntu version in them, which is wrong for Debian.

Sorry for not converting the breaks/replaces for those two to Debian
versions properly.
@Simon - thanks for helping with arguments! (he is one of the
known-to-me Ubuntu Strongswan users).
But in this case it really is CCM.

Every time I come back to this I hate that I only inherited this delta
- too often I don't know and sometimes even fail to find the reasons
for them.
In this case due to your Nack I once again spent some more time to
search for its history.
I didn't find any and honestly I don't care anymore - let me drop
these two changes on my end (with Ubuntu breaks/replaces :-) ).

> 13300d3bf (libstrongswan.install reorder): ACK, I could pick it if there was
> an isolated changelog entry with it

I'll on rebase let this be a change+CL entry.
I'll also reorder the likely to pick changes at the top so you have
not CL conflicts.

> 4fe0861e2 (kernel-netlink conffiles): NACK, these files are installed only on
> Linux and thus the handling is done in debian/rules

Ok, it seems the original author didn't think about non-linux in this case.
I'll convert it to a d/rules change inside the DEB_HOST_ARCH_OS check

> 76535cba5 (libfast disable): Should be ok, if I have an isolated changelog
> entry for this

I'll reorder and add CL for this as well

> 8dbf648b7 (libcharon-standard-plugin): I can understand the rationale (plugins
> for common password-based mobile VPN setup), but I don't really like it. I
> don't really like adding a new binary package, and the name is definitely not
> good. Also, as far as I understand it, the plugins are useful when you're
> actually configuring a client/roadwarrior to imitate a mobile client with its
> limitations. I don't think it's a good thing to do, I'd prefer simplifying the
> secure uses cases, like pubkeys-based ones.



> 9b5769771 (changelog update): NACK for obvious reason, I'd need isolated
> changes to the changelog (although obviously it's not simple to cherry-pick
> them either, I think I prefer it that way).

On the rebase I will revise the changes into the format that you 

Bug#848890: [Pkg-swan-devel] Bug#848890: polished remaining delta for re-review

[Simon Deziel]

Hello Yves-Alexis,

On 2017-12-04 03:56 PM, Yves-Alexis Perez wrote:
> On Thu, 2017-11-30 at 16:31 +0100, Christian Ehrhardt wrote:
>> Pushed it to the same debian-submission-nov2017 branch as before.
> 85150f06 (kernel-libipsec enable): for reference, this is #739641 and I'm
> still not sure I like it. I might pick it but end up disabling it before
> release

The plugin is configured /not/ to load by default which means the
kernel's implementation will be used as normal. Users would need to
opt-in to use this userspace stack.

> f9e7f9007 (CCN move): NACK, what's the justification?

CCM is apparently more popular in the embedded space so maybe it was a
typo for GCM? GCM would make more sense IMHO.

> 8dbf648b7 (libcharon-standard-plugin): I can understand the rationale (plugins
> for common password-based mobile VPN setup), but I don't really like it. I
> don't really like adding a new binary package, and the name is definitely not
> good. Also, as far as I understand it, the plugins are useful when you're
> actually configuring a client/roadwarrior to imitate a mobile client with its
> limitations. I don't think it's a good thing to do, I'd prefer simplifying the
> secure uses cases, like pubkeys-based ones.

The rational for having EAP-MSCHAPv2 and XAUTH easily available is to
support users connecting to corporate VPNs configured to be compatible
with Windows and macOS.

Public keys would be far better indeed but in the enterprises/govs I had
to deal with, they were not popular. In the past 6-7 years, I only had
one client using public keys for roadwarrior scenario.

Regards,
Simon




signature.asc
Description: OpenPGP digital signature

Bug#848890: [Pkg-swan-devel] Bug#848890: polished remaining delta for re-review

[Yves-Alexis Perez]

On Thu, 2017-11-30 at 16:31 +0100, Christian Ehrhardt wrote:
> Pushed it to the same debian-submission-nov2017 branch as before.

Thanks,

I don't really have good news though. I took a look and first, it seems that
the git commit entries aren't really good. git log --format=oneline is barely
readable, for example.

For the commit contents:

1aa409a5 (mass plugin enable): NACK again; I won't enable that many stuff (and
especially not in one go)
d83c243b (duplicheck disable): one good reason for the NACK just above: it's
not enabled in Debian, you just enabled it in 1aa409a5 :)
766d4f0d (ha disable): not really sure; it's way easier to have a custom
kernel than a custom strongSwan
85150f06 (kernel-libipsec enable): for reference, this is #739641 and I'm
still not sure I like it. I might pick it but end up disabling it before
release
a587dc11 (TNC move): I might pick this one because TNC is pretty standalone
per-se and it might make sense to split it, but really that's a lot of new
binary packages.
7629c11a7 (test-vectors move): NACK, what's the justification? Also it'll need
some breaks/replaces
f9e7f9007 (CCN move): NACK, what's the justification? Also, the break/replace
have the ubuntu version in them, which is wrong for Debian.
13300d3bf (libstrongswan.install reorder): ACK, I could pick it if there was
an isolated changelog entry with it
4fe0861e2 (kernel-netlink conffiles): NACK, these files are installed only on
Linux and thus the handling is done in debian/rules
76535cba5 (libfast disable): Should be ok, if I have an isolated changelog
entry for this
8dbf648b7 (libcharon-standard-plugin): I can understand the rationale (plugins
for common password-based mobile VPN setup), but I don't really like it. I
don't really like adding a new binary package, and the name is definitely not
good. Also, as far as I understand it, the plugins are useful when you're
actually configuring a client/roadwarrior to imitate a mobile client with its
limitations. I don't think it's a good thing to do, I'd prefer simplifying the
secure uses cases, like pubkeys-based ones.
9b5769771 (changelog update): NACK for obvious reason, I'd need isolated
changes to the changelog (although obviously it's not simple to cherry-pick
them either, I think I prefer it that way).

Regards, and again thanks for the work you do.

Regards,
-- 
Yves-Alexis

signature.asc
Description: This is a digitally signed message part

Bug#848890: [Pkg-swan-devel] Bug#848890: polished remaining delta for re-review

[Christian Ehrhardt]

On Fri, Dec 1, 2017 at 7:14 PM, Gerald Turner  wrote:
> Hi Christian,
>
> I don't want to distract from the purpose of this bug report, but I have
> a question regarding one particular piece...

Hi Gerald,
thank you so much - perfect question and not distracting from the
purpose of the bug at all.
I was in this case carrying forward an old change which was (in
Ubuntu) separate from some other changes.
In one of our last runs to synchronize between Ubuntu and Debian this
particular Delta was already taken as 9e71a108
 "add and install apparmor profiles" into v5.5.1-3

So I obviously have to drop it from this series  ... updated the branch.
Thanks a lot to trigger me spotting this issue.

> On Thu, Nov 30 2017, Christian Ehrhardt wrote:
>> The TL;DR of the remaining changes are:
>> - some fixes (like the stroke apparmor profile)
>
> Do the Ubuntu packages install AppArmor profiles for charon-systemd and
> swanctl as well?
>

As you already outlined below the usr.sbin.charon-systemd profile was
added in 5.6.0-1 and we don't have it (yet).
I'm working on a recent merge, once done we will have the same profile
as in debian (it works fine for me in tests so far).

For usr.sbin.swanctl we already had the same file as in latest Debian.

> FYI, earlier this year I copied the existing usr.lib.ipsec.charon
> profile to usr.sbin.charon-systemd, and created a usr.sbin.swanctl from
> scratch (although it's similar to usr.lib.ipsec.stroke).  Filed bug
> #866327.  Yves-Alexis applied changes in 5.6.0-1.
>
> I suppose that if there are usr.lib.ipsec.charon or usr.lib.ipsec.stroke
> specific changes coming from Ubuntu, that these should be synchronized
> with the usr.sbin.charon-systemd or usr.sbin.swanctl variants in Debian.

I checked and so far we have no difference left to the profiles uses in Debian.
So we should all be good in the sense that no one knows better yet how
to improve the profiles.

Looking towards hopefully enabling apparmor in Buster [1] by default
strongswan should be in good shape.

[1]: https://lists.debian.org/debian-devel/2017/08/msg00090.html

Bug#848890: [Pkg-swan-devel] Bug#848890: polished remaining delta for re-review

[Gerald Turner]

Hi Christian,

I don't want to distract from the purpose of this bug report, but I have
a question regarding one particular piece...

On Thu, Nov 30 2017, Christian Ehrhardt wrote:
> The TL;DR of the remaining changes are:
> - some fixes (like the stroke apparmor profile)

Do the Ubuntu packages install AppArmor profiles for charon-systemd and
swanctl as well?

FYI, earlier this year I copied the existing usr.lib.ipsec.charon
profile to usr.sbin.charon-systemd, and created a usr.sbin.swanctl from
scratch (although it's similar to usr.lib.ipsec.stroke).  Filed bug
#866327.  Yves-Alexis applied changes in 5.6.0-1.

I suppose that if there are usr.lib.ipsec.charon or usr.lib.ipsec.stroke
specific changes coming from Ubuntu, that these should be synchronized
with the usr.sbin.charon-systemd or usr.sbin.swanctl variants in Debian.

-- 
Gerald Turner Encrypted mail preferred!
OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80  3858 EC94 2276 FDB8 716D


signature.asc
Description: PGP signature

Bug#848890: [Pkg-swan-devel] Bug#848890: polished remaining delta for re-review

[Christian Ehrhardt]

On Thu, Nov 30, 2017 at 2:12 PM, Yves-Alexis Perez  wrote:
> On Thu, 2017-11-30 at 12:00 +0100, Christian Ehrhardt wrote:
>> The TL;DR of the remaining changes are:
>> - enable more plugins/features to be able to run more use-cases
>> - restructuring to be able to run common cases without all of -extra
>> - removal of unusable plugins
>> - some fixes (like the stroke apparmor profile)
>>
>> I'd be happy if we could find time to continue on this, let me know
>> how I can provide any further help.
>
> Thanks for the work and the update on this.
>
> I'll review and cherry-pick relevant changes, but could you rebase against
> recently released 5.6.1-2 (or actually against
> 50347594b2411c23f9314bead2b5cf9ee43cb129)
>
> Looking at the changes, I can already say I won't pick up everything. I'll
> give you a detailed list when I have a chance to cherry-pick them.

Thanks for taking a look!
For those you Nack, I can then comment on the detailed list you'll provide.
On that we can then discuss if e.g. you'd consider to take a
subset/adapted commit or anything like it.

I actually already based it on 5.6.1-2 essentially, but from a
different tree so you had no ancestry match.
It would be bit identical, but sure to match yours on import I'll
rebase onto the commit you mentioned.

Pushed it to the same debian-submission-nov2017 branch as before.

Bug#848890: [Pkg-swan-devel] Bug#848890: polished remaining delta for re-review

[Yves-Alexis Perez]

On Thu, 2017-11-30 at 12:00 +0100, Christian Ehrhardt wrote:
> The TL;DR of the remaining changes are:
> - enable more plugins/features to be able to run more use-cases
> - restructuring to be able to run common cases without all of -extra
> - removal of unusable plugins
> - some fixes (like the stroke apparmor profile)
> 
> I'd be happy if we could find time to continue on this, let me know
> how I can provide any further help.

Thanks for the work and the update on this.

I'll review and cherry-pick relevant changes, but could you rebase against
recently released 5.6.1-2 (or actually against
50347594b2411c23f9314bead2b5cf9ee43cb129)

Looking at the changes, I can already say I won't pick up everything. I'll
give you a detailed list when I have a chance to cherry-pick them.

Regards,
-- 
Yves-Alexis

signature.asc
Description: This is a digitally signed message part