knewstuff's gpg use

[Aleix Pol]

On Thu, Jan 19, 2017 at 12:58 PM, Harald Sitter <sitter at kde.org> wrote:
> Morning,
>
> I had the most peculiar incident just now. KNewstuff shouted at me
> because I have no bin/gpg(2). As it turns out core/security.cpp
> implements some form of gpg signing verification. Based on the gpg CLI
> app.
>
> Naturally, I am perplexed by this because CMake doesn't actually
> report gpg as a RUNTIME dep. that's not really the problem though. The
> problem is in core/installation.cpp where the Security class is
> "used".
>
> It is used by: ctoring and setting up signal connections and then the
> following marvel happens:
>
>>     // ==== FIXME: security code below must go above, when async handling is complete ====
>>
>>     // FIXME: security object lifecycle - it is a singleton!
>>     Security *sec = Security::ref();
>>
>>     // FIXME: change to accept filename + signature
>>     sec->checkValidity(QString());
>
> I am pretty sure that is no-op. Except for the fact that knewstuff
> will complain visually [1] if gpg is not found in $PATH.
>
> There is a bunch of issues with all of this:
> - Security isn't actually used
> - Security operates the bin/gpg CLI rather than using libgpgme which
> supposedly would fit here?
> - The gpg requirement is not codified in cmake
> - The class while saying it is private and not meant to be used,
> actually installs its header and exports itself -.-
> - The class doesn't even have an actual development history in git
> (sans mass refactoring and a workaround for the very noop code seen
> above)
>
> I move that we remove every "usage" of the Security class, mark the
> entire thing deprecated and rip it out with KF6.
>
> If no one has objections I'll prep a review for this tomorrow.
>
> [1] http://i.imgur.com/joGDtfT.png
>
> HS

Hi,
While debugging different issues I've also ran through this code and
wondered about its usefulness.

I agree that if it's actually a no-op (which could very well be, the
code is full of FIXMEs from a developer who hasn't touched the
codebase for several years) the best approach would be to keep it out
and if we ever want to add signing again, which would be actually
rather good, we can design it again, properly.

Aleix