Upgrade note for kscreenlocker to Plasma 5.10

[Fabian Vogt]

Hi,

Am Donnerstag, 9. März 2017, 07:10:30 CET schrieb 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)

Wouldn't it be technically feasible for kscreenlocker_greet to just restart
itself if it notices that it cannot talk to kcheckpass anymore?

> >> 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 is exactly what I'm asking for here, a way to check whether the new
kcheckpass is compatible with the old running kscreenlocker_greet.
I dislike both offline upgrades and killing processes during an upgrade,
so I'd like to avoid both if possible.

Cheers,
Fabian

> 
> > 
> >> 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
>