Hello Chandra, You still haven't answered my previous question, about how you (Dell) are going to undo this mess that you've created.
I'm sorry, but your suggestion of manually importing the key just doesn't fly for folks who have hundreds of systems. This is NOT how you manage a repository of RPMs. Please go back to your colleagues, and fix this mess properly. And do this quickly, because we're constantly getting errors from all our systems about they missing key. Anand On 28/06/2018 06:48, chandrasekha...@dell.com wrote: > Dell - Internal Use - Confidential > > Hi Erinn, > > As of now, not all OpenManage Server Administrator packages are signed with > new GPG key. Yes, we are keeping the old key along with new key. > > Regards, > Chandra > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 27 Jun 2018 10:18:40 -0600 > From: Erinn Looney-Triggs <erinn.looneytri...@gmail.com> > To: linux-poweredge@dell.com > Subject: Re: [Linux-PowerEdge] RPM repo GPG key changed > Message-ID: <36ca0788-f600-7d9f-f943-8550216b8...@gmail.com> > Content-Type: text/plain; charset=utf-8 > > Dell team, are all of the packages no signed with the new GPG key? Or are we > going to have to hold onto the old key as well as the new one? > > -Erinn > > > On 06/27/2018 09:44 AM, John Hodrien wrote: >> On Wed, 27 Jun 2018, Paul Raines wrote: >> >>> Definitely should have used https instead of http at least.? Other >>> than that is it pretty common and not really different than click >>> downloading a *.bin install file and running it with bash (I think >>> Oracle Java still does >>> this) >> >> Sure, but that doesn't make it nice. >> >>> Having public keys you download from an https site at a clear dell >>> URL that you install by hand and then only install rpms with yum is a >>> tad better. But pre and post scripts in RPMs can run anything they >>> want via bash. Ultimately it still comes down to trusting Dell and >>> the integrity of Dell's website certificate >> >> Trusting Dell's website certificate still means you man-in-the-middle >> protected. >> >> Look at how EPEL/ELrepo/most other repositories do it.? You provide a >> dell-release RPM, signed with their signing key, which is made >> available over HTTPS. >> >> First time you use it, you can download the release RPM, validate it >> to your satisfaction that it's legit, and put that into your internal >> repos, optionally resigning it or whatever else you'd like to do. >> >> Any changes Dell then want to make to their repositories they can >> release as an updated dell-release RPM, and nobody has to play games >> like this. >> >> jh >> > > > > ------------------------------ > > Message: 2 > Date: Wed, 27 Jun 2018 13:37:21 -0300 > From: Patrick Boutilier <bouti...@ednet.ns.ca> > To: linux-poweredge@dell.com > Subject: Re: [Linux-PowerEdge] RPM repo GPG key changed > Message-ID: <fedc33af-5a25-ef10-8b6e-c1093a3b1...@ednet.ns.ca> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > On 06/27/2018 12:44 PM, John Hodrien wrote: >> On Wed, 27 Jun 2018, Paul Raines wrote: >> >>> Definitely should have used https instead of http at least.? Other >>> than that is it pretty common and not really different than click >>> downloading a *.bin install file and running it with bash (I think >>> Oracle Java still does >>> this) >> >> Sure, but that doesn't make it nice. >> >>> Having public keys you download from an https site at a clear dell >>> URL that you install by hand and then only install rpms with yum is a >>> tad better. But pre and post scripts in RPMs can run anything they >>> want via bash. Ultimately it still comes down to trusting Dell and >>> the integrity of Dell's website certificate >> >> Trusting Dell's website certificate still means you man-in-the-middle >> protected. >> >> Look at how EPEL/ELrepo/most other repositories do it.? You provide a >> dell-release RPM, signed with their signing key, which is made >> available over HTTPS. >> >> First time you use it, you can download the release RPM, validate it >> to your satisfaction that it's legit, and put that into your internal >> repos, optionally resigning it or whatever else you'd like to do. >> >> Any changes Dell then want to make to their repositories they can >> release as an updated dell-release RPM, and nobody has to play games >> like this. > > > That would be a good solution. > > > > > >> >> jh >> > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: boutilpj.vcf > Type: text/x-vcard > Size: 286 bytes > Desc: not available > URL: > <http://lists.us.dell.com/pipermail/linux-poweredge/attachments/20180627/b89490d2/attachment-0001.vcf> > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Linux-PowerEdge mailing list > Linux-PowerEdge@dell.com > https://lists.us.dell.com/mailman/listinfo/linux-poweredge > > ------------------------------ > > End of Linux-PowerEdge Digest, Vol 169, Issue 20 > ************************************************ > > _______________________________________________ > Linux-PowerEdge mailing list > Linux-PowerEdge@dell.com > https://lists.us.dell.com/mailman/listinfo/linux-poweredge > _______________________________________________ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
