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:[email protected]] Envoyé : lundi 8 octobre 2012 11:53 À : SCHAER Frederic Cc : [email protected] 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 [email protected] http://www.dpmms.cam.ac.uk/~werdna
smime.p7s
Description: S/MIME cryptographic signature
