KAuth buildability: new CI architecture

[Ben Cooksley]

On Mon, Apr 17, 2017 at 12:48 AM, Martin Gräßlin <mgraesslin at kde.org> wrote:
> Am 2017-04-16 13:52, schrieb Ben Cooksley:
>>
>> On Sun, Apr 16, 2017 at 11:09 PM, Harald Sitter <sitter at kde.org> wrote:
>>>
>>> Not particularly related to the issue at hand (which is probably
>>> polkitqt having meh cmake files), but relocating stuff in general is
>>> suuuuper unreliable and I would absolutely advise against it as it can
>>> easily screw up test results and builds alike, often in unobvious ways
>>> (all it takes is a bit of libexec use). Instead, as a general
>>> principle, I would suggest that you get stuff mounted in suitably
>>> stable/consistent/generic paths inside the build containers.
>>> Ultimately what things look like natively on the host file system
>>> shouldn't factor into what they look like in the build environment.
>>
>>
>> While I have thought of using a consistent path, this would simply
>> workaround the fact that our binaries are frail and have hardcoded
>> paths baked into them.
>
>
> note that this is partially intended for security reasons. E.g.
> kscreenlocker starts kcheckpass through a hardcoded path for security
> reasons (we want to be sure it's the kcheckpass we created and not a
> fakekcheckpass injected by a malicious tool). So overall especially in
> plasma lots of Wayland stuff is hardcoding paths for this reason and
> partially they are used in testing.
>
> In the case of kscreenlocker this can become a problem when KWin tests are
> run. We have tests verify that locking the screen works on Wayland. For that
> kscreenlocker_greet gets started and that has a hardcoded path as well. So
> if the paths is relocated we test an unsupported setup.

Would it be possible to use relative-to-calling-binary paths? The new
CI scripts do this to find their configuration and other resources
they need so it should be doable (note that the new CI environment
unpacks everything into the same directory when assembling an install
prefix so one can run with that assumption - and it's one that should
be true on 99% of systems out there)

This should meet the security requirements (if someone is running
their own kscreenlocker / kwin / etc binaries then chances are they
can modify the executable directly anyway)

>
> Cheers
> Martin

Cheers,
Ben