Hi,
Thanks for your reply. Hm. I didn't know some packages couldn't be re-signed.
I knew about the --nogpgcheck option, but I was reluctant to use it in puppet - and puppet from epel does not support options for
the packages management...
But I just found out a way to not disrupt puppet, and to avoid using the nogpgcheck flag for automated installs (and site updates),
which is : exclude java/jdk from the SL yum repo, and create an SL repo with the "includepkgs" option set to "jdk*" and gpgcheck=0 :
that way I can still automate things, including java update and installation.
That's still unsecure, but for java only ...
Regards
Frederic
-----Message d'origine-----
De : Dr Andrew C Aitchison [mailto:[log in to unmask]]
Envoyé : lundi 8 octobre 2012 11:53
À : SCHAER Frederic
Cc : [log in to unmask]
Objet : Re: SL5.8 jdk errata RPMs not signed
On Fri, 5 Oct 2012, SCHAER Frederic wrote:
> Hi,
>
> I'm trying to install some software which requires a jdk, and the latest one is set to be installed... but installation fails
> because I have enabled gpg signature check, and that rpm isn't signed : is this a bug, or a feature ?
>
> Error :
> # yum install jdk.x86_64
> (...)
> Package jdk-1.6.0_35-fcs.x86_64.rpm is not signed
>
> If this is a feature, do how should security updates be applied using yum ?
It is a "feature".
Sun/Oracle build these packages, not SL,
and they are built with rpm version 3 which cannot be (re)signed
(there is/was some work around for the 32bit rpms,
but no known solution for the x86_64 packages).
> I would assume it is a security risk to disable gpg check on erratas, isn't it ?
I would agree.
I hand-install these packages with yum --nogpgcheck
--
Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge
[log in to unmask] http://www.dpmms.cam.ac.uk/~werdna
|
