GnuGP -- problem with installation

[FranekW]

I installed GnuGP from sources but for some reason it doesn't work.

I downloaded all sources from https://www.gnupg.org/download/index.en.html and installed each library using the common sequence:

Code: Select all

./configure
make
sudo make install

The `gpg2` did not start at first due to an issue reported on this website https://lists.gnupg.org/pipermail/gnupg ... 39357.html--workaround worked and I could run `gpg2`. Then, I tried to generate keys with this error:

Code: Select all

gpg: agent_genkey failed: No pinentry
Key generation failed: No pinentry

I noted two extra libraries on GnuGP website (the link above) under the section `Pinetry` which I did not install, so I downloaded them and tried to install the first: "GPGME". The ./configure reported some problems with Python and QtCore v5 but it got through, so run `make`. However, make install reported missing libraries:

Code: Select all

Could not find gpg-error-config.  Please install the libgpg-error development package.
make[3]: *** [all-local] Error 1
make[3]: Leaving directory `/opt/gpg-install/gpgme-1.9.0/lang/python'
make[2]: *** [install-recursive] Error 1
make[2]: Leaving directory `/opt/gpg-install/gpgme-1.9.0/lang/python'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/opt/gpg-install/gpgme-1.9.0/lang'
make: *** [install-recursive] Error 1

I installed lilgpg-error before using default settings, otherwise I could not even install gnugp v2 from sources. I also restarted system and still cannot get through with this.

Additionally, .configure reported my Python has inconsistency (????) that libraries are not installed properly. I have never messed with Python in the system. Yes, I installed Anaconda3 but in different folder, which is `/opt/Anaconda3`. The $PATH is set such that access to original Python in the system is not broken. I use Python only via editors: Spyder, PyCharm, etc. which has custom access to Python.

Eventually, I though I would get back to original gpg2 which was installed but I guess I somehow overwrote the binaries by using default settings when installing GnuPG 2.1.12.

Any suggestions what I could do now? I cannot use any of this at the moment.

Thanks

[TrevorH]

We do not support source installs. If you want gpg then we package it and supply it in the base repos where you can just yum install gnupg2

[FranekW]

I am confused about the versions of GPG available at the moment.
I read on this website https://superuser.com/questions/655246/ ... each-other that there is a couple of gpg versions. The way how GnuPG 2.1.x generate and stores keys is different from GnuPG 1 and GnuPG 2.0.

If I run yum install gnupg2[/b, which version of GnuPG will I have installed? Will it be compatible with the GnuPG v2.1.12 available on the website?

Thanks


EDIT. I think I messed up with gpg that was installed before I tried to install gpg from sources. Is it possible to reinstall required files using yum or rpm to recover to the previous state?

[TrevorH]

Basically, if you install something from source then you are completely on your own. We don't support it. If you install something from the CentOS repos then that package will get updated with security and bug fixes from RHEL as they are released, as and when you run yum update.

So the gnupg package that we supply is gnupg2-2.0.22-4.el7.x86_64

[FranekW]

Perhaps I have installed wrong system, then :/

Those applications I tried to install from CentOS are outdated. The available git version is 1.8.x, Python is 2.7.x, latest GnuPG is 2.0 with old approach where you use two files for security keys; apparently less secure.I am not sure, don't have time to look at internet again, but I have read it is recommend to update git into something higher than 1.8.

If I am on my own then ok. I can't do anything about it but I can't keep so much outdated software.

[TrevorH]

You're running the wrong distro then. Yes, CentOS (and RHEL) ship older versions of things but that is for stability purposes. Redhat take care of security, backporting security patches from the newer versions to the older ones, but the whole idea is that by running the older versions, you get less buggy apps because there has been time to get all those annoying bugs patched without devs rewriting everything and introducing even more new bugs. You also get the stability of being able to run secure apps that are at fixed versions so there's no "Oh, I deployed a new version of X and it broke Y, Z and Q" because a security fix says that you need to go from X 1.0.0 to X 1.6.12 and no-one told you that the API to use X changed in the meantime.