Upgrade note for kscreenlocker to Plasma 5.10

[Martin Gräßlin]

Am 2017-03-08 20:12, schrieb Fabian Vogt:
> Hi!
> 
> Am Mittwoch, 8. M?rz 2017, 19:50:40 CET schrieb Martin Gr??lin:
>> Hi distributions,
>> 
>> I'm currently planning to change the interaction between
>> kscreenlocker_greet and kcheckpass. As a result a kscreenlocker_greet
>> started in Plasma 5.9 won't be able to unlock with a kcheckpass from
>> Plasma 5.10. This is a situation which could happen during an upgrade.
>> Kcheckpass gets invoked when trying to unlock, so an upgrade while the
>> session is locked could result in this situation.
> 
> Thanks for letting us know!
> Isn't there a way to make kscreenlocker from the next 5.9 release 
> capable
> of unlocking the 5.10 kcheckpass? That way nothing special would 
> happen.

Even if it were technically possible (which it isn't) it would not solve 
the
problem as we also want to support transitions like 5.8 (or earlier) to
5.10 (or later)

> 
>> There are two solutions to the problem which might need a small change
>> for your packaging:
>> 1) Perform offline updates for the upgrade (my preferred solution)
>> 2) send SIGTERM to any running kscreenlocker_greet after installing
>> kcheckpass. This will trigger a restart of kscreenlocker_greet which 
>> is
>> then also from Plasma 5.10 and thus will work.
> 
> If fixing 5.9.4 is not an option, please bump the version that
> kscreenlocker_greet --version outputs to 0.2 and maybe also kcheckpass,
> so that we can reliably tell which version(s) is needs to be treated 
> specially.

Please don't consider the version 5.10 special. Please implement a check 
which
will run on every upgrade. Maintaining the upgrade path in kscreenlocker 
is
extremely difficult. Thus if distros implement a solution now, it would 
be
really appreciated if that would be a standard part of any kscreenlocker 
upgrade
Even for minor version upgrades.

> 
>> This change will happen pretty soon, so if you provide developer 
>> builds
>> (looking at Neon, Argon and friends ;-) ), please consider this. I
>> intend to push the changes on Monday next week. For the Plasma 5.10
>> cycle more such changes might happen.
>> 
>> In case you wonder why I change what isn't broken: I'm working on
>> integrating libseccomp into kscreenlocker_greet and for that I need to
>> change the interaction to kcheckpass as I want to forbid fork+exec and
>> kcheckpass needs to be started prior to activating seccomp as 
>> kcheckpass
>> calls a setuid binary of PAM which wouldn't work with seccomp enabled.
>> Thus some changes are needed.
>> 
>> Which is another heads-up: kscreenlocker will most likely get a new
>> optional dependency to libseccomp. I encourage all distributions to
>> enable this dependency. It will only be available if kcheckpass is not
>> setuid, that is if PAM is used. Given that I encourage all 
>> distributions
>> which are not yet using PAM to migrate to PAM.
> 
> Already added, will it require a new config option or just get enabled
> automatically?

It will be a normal optional build dependency specified through CMake.
That is it will be picked up automatically.

Cheers
Martin