[gnupg2] Provide systemd socket and service file for gpg-agent.

[dcaliste]

Following discussions on sailfishos/sailfish-secrets#178 and sailfishos/pth#1, here is a partial attempt to get a gpg-agent running in daemon mode on-demand.

I say partial for two reasons:

• I'm a noob regarding systemd and my new gpg-agent.socket from this MR is not started automatically like the PulseAudio one for instance with the user session. I didn't find why. Thus I need to start it by hand for test purposes with systemctl --user start gpg-agent.socket,
• the socket is then well handled by systemd and the associated service is started when a program like gpg-connect-agent or even gpg2 is used. But the first operation always hangs forever. I guess this is due to how the agent is coded, not knowing about systemd way to pipe the sockets. It is obviously working for recent versions of GnuPG, but well, you know. That being said, all next operations are then successfull, even from a jailed application.

So to summarize, it may be easier to run the gpg-agent always, and not just on-demand, like that we avoid the failure of the first operation. This is the first solution to get GnuPG operations working in jailed applications (it requires the pth patch also). For reference, the second solution consists of keeping the gpg-agent running in PIPE mode on demand in a transient way for the on-going operation (like asking a passphrase), like it is now. But this second solution requires to move the sailfish-secrets daemon socket to a subdirectory and requires to grant some new Secrets.permission to the GnuPG permissions.

@Thaodan and @pvuorela please feel free to ask other reviewers if you think it's worth discussing the matter.

[dcaliste]

Oh, I forgot, but there is a third solution actually:

• upgrade gnupg and friends (libgpgme for instance) to the greatest latest version which support natively systemd and for which bugs are actively corrected upstream.

This solution would require to create a gnupg-gplv3 like we currently have gnu-bash package for instance. This package would provide gnupg2 but would not be installed by default. The tiny problem with this solution is that gpg-agent is not speaking exactly the same IPC language between versions, which would make the pinentry implementation in sailfish-secrets at best fragile but surely complicated to support both prehistoric 2.0.4 IPC language and the new one. The same for libgpgme : some functions may be deprecated in recent versions.

Discussion is opened !

[Thaodan]

Oh, I forgot, but there is a third solution actually:

* upgrade gnupg and friends (libgpgme for instance) to the greatest latest version which support natively systemd and for which bugs are actively corrected upstream.

This solution would require to create a gnupg-gplv3 like we currently have gnu-bash package for instance. This package would provide gnupg2 but would not be installed by default. The tiny problem with this solution is that gpg-agent is not speaking exactly the same IPC language between versions, which would make the pinentry implementation in sailfish-secrets at best fragile but surely complicated to support both prehistoric 2.0.4 IPC language and the new one. The same for libgpgme : some functions may be deprecated in recent versions.

That is actually already covered by the upstream projects that use e.g. zypper which works with our old gpgme version but also with modern gpgme versions.
So a way to handle this would be to allow switching between gnugpg versions for those that want to have "better" support of gpg e.g. in case of email encryption or smartcards.

[dcaliste]

Ok, I'm going to try to package the latest GnuPG version and its friends. Do you have a preference for the naming scheme ?

• keep the current gnupg package as gnupg and labelled the recent versions gnupg-latest and make them provides gnupg and conflict with gnupg,
• rename current packages to gnupg-legacy make them provide gnupg and labelled the latest version gnupg and make them conflict with gnupg-legacy.

[Thaodan]

I would name our current gnupg to gnupg2.0 and the later to gnupg since that is more neutral.

[dcaliste]

Yes, I agree. I started to package it like that.

There is a minor issue with libassuan though. Because we need to move to version 2. So we need the two simultaneously the version 1 for gnupg 2.0.4 and the 2.5.0 for the latest gnupg. But the current repo is named libassuan. And creating a new one named libassuan2 would be uterly misleading with gnupg2 being the legacy and gnupg the latest...

[vigejolla]

I would rather keep the names of the old packages as they are, and name the new packages as gnupg2-gpl3 or something. Just to make sure we don't accidentally pull the new packages to images.

[dcaliste]

Thanks @vigejolla . For libassuan, gnupg and gpgme we'll need new repositories. I let you in Jolla create them in sailfishos/ and then I'll set up push requests there according to the name you chose.