Re: [Linux-PowerEdge] RPM repo GPG key changed
Dell - Internal Use - Confidential Hi Anand, The Linux Repository will be Refreshed on July 13th to pick up this issue. Ray -Original Message- From: Giri, Aparna Sent: Wednesday, July 11, 2018 4:47 AM To: Anand Buddhdev; linux-poweredge-Lists; Hebert, Ray Subject: RE: [Linux-PowerEdge] RPM repo GPG key changed Hi Anand, Understand your concern. These fixed packages are being made available via YUM repo as well at the earliest. +Ray to provide a date on the availability of the same. Thanks -Original Message- From: linux-poweredge-bounces-Lists On Behalf Of Anand Buddhdev Sent: Wednesday, July 11, 2018 3:09 PM To: Giri, Aparna; linux-poweredge-Lists Subject: Re: [Linux-PowerEdge] RPM repo GPG key changed Hello Aparna, You're not making any sense. The URL below has a tarball containing some RPMs, but the srvadmin-omacs and srvadmin-omilcore packages are the same as in your repository here: http://linux.dell.com/repo/hardware/dsu/os_dependent/RHEL7_64/srvadmin/ Your packages in your yum repository are still signed with the newer key, for which there is no roll-over process. How are you expecting users with large numbers of Dell servers to automate installation of these packages? Do you actually even understand the problem? Anand On 11/07/2018 10:35, aparna.g...@dell.com wrote: > Hi, > > The fixed packages are available at the link below - > > https://www.dell.com/support/home/us/en/19/Drivers/DriversDetails?driv > erid=3R1H1 > > Thanks, > Aparna > > -Original Message- > From: linux-poweredge-bounces-Lists On Behalf Of Anand Buddhdev > Sent: Wednesday, July 11, 2018 12:15 PM > To: Giri, Aparna; linux-poweredge-Lists > Subject: Re: [Linux-PowerEdge] RPM repo GPG key changed > > Hi Aparna, > > Can you please tell us when the fixed packages will be available? Why is it > taking so long to just sign the packages with the old key? > > Anand > > On 09/07/2018 12:29, Anand Buddhdev wrote: >> Hi Aparna, >> >> It's been a week since your message. Could you please tell us when >> Dell is releasing updated packages? >> >> Regards, >> Anand >> >> On 02/07/2018 17:19, aparna.g...@dell.com wrote: >> >>> Hi, >>> >>> The RPMs will be SHA-1 certified. Thus there is no need to import a >>> new key. As indicated earlier, these RPMs would be available in ~1 week. >> >> ___ >> 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 > ___ 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
Re: [Linux-PowerEdge] RPM repo GPG key changed
Hi Anand, Understand your concern. These fixed packages are being made available via YUM repo as well at the earliest. +Ray to provide a date on the availability of the same. Thanks -Original Message- From: linux-poweredge-bounces-Lists On Behalf Of Anand Buddhdev Sent: Wednesday, July 11, 2018 3:09 PM To: Giri, Aparna; linux-poweredge-Lists Subject: Re: [Linux-PowerEdge] RPM repo GPG key changed Hello Aparna, You're not making any sense. The URL below has a tarball containing some RPMs, but the srvadmin-omacs and srvadmin-omilcore packages are the same as in your repository here: http://linux.dell.com/repo/hardware/dsu/os_dependent/RHEL7_64/srvadmin/ Your packages in your yum repository are still signed with the newer key, for which there is no roll-over process. How are you expecting users with large numbers of Dell servers to automate installation of these packages? Do you actually even understand the problem? Anand On 11/07/2018 10:35, aparna.g...@dell.com wrote: > Hi, > > The fixed packages are available at the link below - > > https://www.dell.com/support/home/us/en/19/Drivers/DriversDetails?driv > erid=3R1H1 > > Thanks, > Aparna > > -Original Message- > From: linux-poweredge-bounces-Lists On Behalf Of Anand Buddhdev > Sent: Wednesday, July 11, 2018 12:15 PM > To: Giri, Aparna; linux-poweredge-Lists > Subject: Re: [Linux-PowerEdge] RPM repo GPG key changed > > Hi Aparna, > > Can you please tell us when the fixed packages will be available? Why is it > taking so long to just sign the packages with the old key? > > Anand > > On 09/07/2018 12:29, Anand Buddhdev wrote: >> Hi Aparna, >> >> It's been a week since your message. Could you please tell us when >> Dell is releasing updated packages? >> >> Regards, >> Anand >> >> On 02/07/2018 17:19, aparna.g...@dell.com wrote: >> >>> Hi, >>> >>> The RPMs will be SHA-1 certified. Thus there is no need to import a >>> new key. As indicated earlier, these RPMs would be available in ~1 week. >> >> ___ >> 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 > ___ 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
Re: [Linux-PowerEdge] RPM repo GPG key changed
Hello Aparna, You're not making any sense. The URL below has a tarball containing some RPMs, but the srvadmin-omacs and srvadmin-omilcore packages are the same as in your repository here: http://linux.dell.com/repo/hardware/dsu/os_dependent/RHEL7_64/srvadmin/ Your packages in your yum repository are still signed with the newer key, for which there is no roll-over process. How are you expecting users with large numbers of Dell servers to automate installation of these packages? Do you actually even understand the problem? Anand On 11/07/2018 10:35, aparna.g...@dell.com wrote: > Hi, > > The fixed packages are available at the link below - > > https://www.dell.com/support/home/us/en/19/Drivers/DriversDetails?driverid=3R1H1 > > Thanks, > Aparna > > -Original Message- > From: linux-poweredge-bounces-Lists On Behalf Of Anand Buddhdev > Sent: Wednesday, July 11, 2018 12:15 PM > To: Giri, Aparna; linux-poweredge-Lists > Subject: Re: [Linux-PowerEdge] RPM repo GPG key changed > > Hi Aparna, > > Can you please tell us when the fixed packages will be available? Why is it > taking so long to just sign the packages with the old key? > > Anand > > On 09/07/2018 12:29, Anand Buddhdev wrote: >> Hi Aparna, >> >> It's been a week since your message. Could you please tell us when >> Dell is releasing updated packages? >> >> Regards, >> Anand >> >> On 02/07/2018 17:19, aparna.g...@dell.com wrote: >> >>> Hi, >>> >>> The RPMs will be SHA-1 certified. Thus there is no need to import a >>> new key. As indicated earlier, these RPMs would be available in ~1 week. >> >> ___ >> 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 > ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
Re: [Linux-PowerEdge] RPM repo GPG key changed
Hi, The fixed packages are available at the link below - https://www.dell.com/support/home/us/en/19/Drivers/DriversDetails?driverid=3R1H1 Thanks, Aparna -Original Message- From: linux-poweredge-bounces-Lists On Behalf Of Anand Buddhdev Sent: Wednesday, July 11, 2018 12:15 PM To: Giri, Aparna; linux-poweredge-Lists Subject: Re: [Linux-PowerEdge] RPM repo GPG key changed Hi Aparna, Can you please tell us when the fixed packages will be available? Why is it taking so long to just sign the packages with the old key? Anand On 09/07/2018 12:29, Anand Buddhdev wrote: > Hi Aparna, > > It's been a week since your message. Could you please tell us when > Dell is releasing updated packages? > > Regards, > Anand > > On 02/07/2018 17:19, aparna.g...@dell.com wrote: > >> Hi, >> >> The RPMs will be SHA-1 certified. Thus there is no need to import a >> new key. As indicated earlier, these RPMs would be available in ~1 week. > > ___ > 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 ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
Re: [Linux-PowerEdge] RPM repo GPG key changed
Hi Aparna, Can you please tell us when the fixed packages will be available? Why is it taking so long to just sign the packages with the old key? Anand On 09/07/2018 12:29, Anand Buddhdev wrote: > Hi Aparna, > > It's been a week since your message. Could you please tell us when Dell > is releasing updated packages? > > Regards, > Anand > > On 02/07/2018 17:19, aparna.g...@dell.com wrote: > >> Hi, >> >> The RPMs will be SHA-1 certified. Thus there is no need to import a >> new key. As indicated earlier, these RPMs would be available in ~1 week. > > ___ > 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
Re: [Linux-PowerEdge] RPM repo GPG key changed
Hi Aparna, It's been a week since your message. Could you please tell us when Dell is releasing updated packages? Regards, Anand On 02/07/2018 17:19, aparna.g...@dell.com wrote: > Hi, > > The RPMs will be SHA-1 certified. Thus there is no need to import a > new key. As indicated earlier, these RPMs would be available in ~1 week. ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
Re: [Linux-PowerEdge] RPM repo GPG key changed
Hi, The RPMs will be SHA-1 certified. Thus there is no need to import a new key. As indicated earlier, these RPMs would be available in ~1 week. Thanks, Aparna -Original Message- From: Anand Buddhdev [mailto:ana...@ripe.net] Sent: Monday, July 2, 2018 7:51 PM To: Giri, Aparna; linux-poweredge-Lists Subject: Re: [Linux-PowerEdge] RPM repo GPG key changed On 02/07/2018 16:16, aparna.g...@dell.com wrote: Hi Aparna, Can you please be more specific about your fix? What exactly are you going to do? Are you going to re-sign all the packages with the old key? Or will you sign them all with the new key? And if you do that, how exactly are all users going get the new key? Remember that not all users are on this list, so it's not enough to just announce here and tell folk to import the new key. That just won't cut it. I'd like to hear details about your fix. Anand > Hi All, > > We are working on fixing this. The fixed RPMs will be available in ~1 week. > > Thanks, > Aparna > > > -Original Message- > From: linux-poweredge-bounces-Lists On Behalf Of James Mathiesen > Sent: Friday, June 29, 2018 6:38 PM > To: linux-poweredge-Lists > Subject: Re: [Linux-PowerEdge] RPM repo GPG key changed > > Dell, > > We also use Spacewalk and the limitation Jeff mentions will be a problem for > us as well. > > There is no customer benefit in using stronger keys and signature algorithms > if Dell doesn’t stop requiring trust in the weaker keys and signature > algorithms. A complete transition would have been disruptive but at least be > a one-time cost with a clear fix, clear benefits and a clear end-state. Using > the existing 1024-bit key with a stronger signing algorithm would have been > non-disruptive but provide lesser benefits. > > If there is a commitment to improving customer security I don't see how this > specific change was a useful intermediate step. If there is no commitment to > improving customer security this change was a waste of everybody's time. > > james > > > > > On 6/28/18, 9:36 PM, "Linux-PowerEdge on behalf of Gottloeb, Jeff [US] (ES)" > > wrote: > > Chandra, > > Please provide the justification for not signing all of the RPMs with the > new key. There are Dell customers with systems that do not have Internet > connectivity and therefore need other solutions to manage the DSU and OMSA > repositories. Red Hat's disconnected Satellite server is one method designed > for this purpose but it does not support multiple GPG keys for the same > repository. > > Is there a target date when all of the RPMs will be signed with this new > key? > > > Jeff Gottloeb > Northrop Grumman IT Solutions > 310 812 4395 > > > > ___ > Linux-PowerEdge mailing list > Linux-PowerEdge@dell.com > > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.us.dell.com > _mailman_listinfo_linux-2Dpoweredge&d=DwICAg&c=9Hv6XPedRSA-5PSECC38X80 > c1h60_XWA4z1k_R1pROA&r=CfAaYCQEf7pGoAdbq0Icw0twCvsk5y-CVhkNDSSJWU0&m=7 > -VNCLmkBGYWR-b1BySKceKLSMsi72ECRpu5UYm29r0&s=age2iN5lvS7avxm90dRrt9mbQ > tsQZeHC_SJO-GL-57I&e= > > > ___ > 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 > ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
Re: [Linux-PowerEdge] RPM repo GPG key changed
On 02/07/2018 16:16, aparna.g...@dell.com wrote: Hi Aparna, Can you please be more specific about your fix? What exactly are you going to do? Are you going to re-sign all the packages with the old key? Or will you sign them all with the new key? And if you do that, how exactly are all users going get the new key? Remember that not all users are on this list, so it's not enough to just announce here and tell folk to import the new key. That just won't cut it. I'd like to hear details about your fix. Anand > Hi All, > > We are working on fixing this. The fixed RPMs will be available in ~1 week. > > Thanks, > Aparna > > > -Original Message- > From: linux-poweredge-bounces-Lists On Behalf Of James Mathiesen > Sent: Friday, June 29, 2018 6:38 PM > To: linux-poweredge-Lists > Subject: Re: [Linux-PowerEdge] RPM repo GPG key changed > > Dell, > > We also use Spacewalk and the limitation Jeff mentions will be a problem for > us as well. > > There is no customer benefit in using stronger keys and signature algorithms > if Dell doesn’t stop requiring trust in the weaker keys and signature > algorithms. A complete transition would have been disruptive but at least be > a one-time cost with a clear fix, clear benefits and a clear end-state. Using > the existing 1024-bit key with a stronger signing algorithm would have been > non-disruptive but provide lesser benefits. > > If there is a commitment to improving customer security I don't see how this > specific change was a useful intermediate step. If there is no commitment to > improving customer security this change was a waste of everybody's time. > > james > > > > > On 6/28/18, 9:36 PM, "Linux-PowerEdge on behalf of Gottloeb, Jeff [US] (ES)" > > wrote: > > Chandra, > > Please provide the justification for not signing all of the RPMs with the > new key. There are Dell customers with systems that do not have Internet > connectivity and therefore need other solutions to manage the DSU and OMSA > repositories. Red Hat's disconnected Satellite server is one method designed > for this purpose but it does not support multiple GPG keys for the same > repository. > > Is there a target date when all of the RPMs will be signed with this new > key? > > > Jeff Gottloeb > Northrop Grumman IT Solutions > 310 812 4395 > > > > ___ > Linux-PowerEdge mailing list > Linux-PowerEdge@dell.com > > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.us.dell.com_mailman_listinfo_linux-2Dpoweredge&d=DwICAg&c=9Hv6XPedRSA-5PSECC38X80c1h60_XWA4z1k_R1pROA&r=CfAaYCQEf7pGoAdbq0Icw0twCvsk5y-CVhkNDSSJWU0&m=7-VNCLmkBGYWR-b1BySKceKLSMsi72ECRpu5UYm29r0&s=age2iN5lvS7avxm90dRrt9mbQtsQZeHC_SJO-GL-57I&e= > > > ___ > 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 > ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
Re: [Linux-PowerEdge] RPM repo GPG key changed
Hi All, We are working on fixing this. The fixed RPMs will be available in ~1 week. Thanks, Aparna -Original Message- From: linux-poweredge-bounces-Lists On Behalf Of James Mathiesen Sent: Friday, June 29, 2018 6:38 PM To: linux-poweredge-Lists Subject: Re: [Linux-PowerEdge] RPM repo GPG key changed Dell, We also use Spacewalk and the limitation Jeff mentions will be a problem for us as well. There is no customer benefit in using stronger keys and signature algorithms if Dell doesn’t stop requiring trust in the weaker keys and signature algorithms. A complete transition would have been disruptive but at least be a one-time cost with a clear fix, clear benefits and a clear end-state. Using the existing 1024-bit key with a stronger signing algorithm would have been non-disruptive but provide lesser benefits. If there is a commitment to improving customer security I don't see how this specific change was a useful intermediate step. If there is no commitment to improving customer security this change was a waste of everybody's time. james On 6/28/18, 9:36 PM, "Linux-PowerEdge on behalf of Gottloeb, Jeff [US] (ES)" wrote: Chandra, Please provide the justification for not signing all of the RPMs with the new key. There are Dell customers with systems that do not have Internet connectivity and therefore need other solutions to manage the DSU and OMSA repositories. Red Hat's disconnected Satellite server is one method designed for this purpose but it does not support multiple GPG keys for the same repository. Is there a target date when all of the RPMs will be signed with this new key? Jeff Gottloeb Northrop Grumman IT Solutions 310 812 4395 ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.us.dell.com_mailman_listinfo_linux-2Dpoweredge&d=DwICAg&c=9Hv6XPedRSA-5PSECC38X80c1h60_XWA4z1k_R1pROA&r=CfAaYCQEf7pGoAdbq0Icw0twCvsk5y-CVhkNDSSJWU0&m=7-VNCLmkBGYWR-b1BySKceKLSMsi72ECRpu5UYm29r0&s=age2iN5lvS7avxm90dRrt9mbQtsQZeHC_SJO-GL-57I&e= ___ 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
Re: [Linux-PowerEdge] RPM repo GPG key changed
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 > 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 > To: linux-poweredge@dell.com > Subject: Re: [Linux-PowerEdge] RPM repo GPG key changed > Message-ID: > 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. > >
Re: [Linux-PowerEdge] RPM repo GPG key changed
Dell, We also use Spacewalk and the limitation Jeff mentions will be a problem for us as well. There is no customer benefit in using stronger keys and signature algorithms if Dell doesn’t stop requiring trust in the weaker keys and signature algorithms. A complete transition would have been disruptive but at least be a one-time cost with a clear fix, clear benefits and a clear end-state. Using the existing 1024-bit key with a stronger signing algorithm would have been non-disruptive but provide lesser benefits. If there is a commitment to improving customer security I don't see how this specific change was a useful intermediate step. If there is no commitment to improving customer security this change was a waste of everybody's time. james On 6/28/18, 9:36 PM, "Linux-PowerEdge on behalf of Gottloeb, Jeff [US] (ES)" wrote: Chandra, Please provide the justification for not signing all of the RPMs with the new key. There are Dell customers with systems that do not have Internet connectivity and therefore need other solutions to manage the DSU and OMSA repositories. Red Hat's disconnected Satellite server is one method designed for this purpose but it does not support multiple GPG keys for the same repository. Is there a target date when all of the RPMs will be signed with this new key? Jeff Gottloeb Northrop Grumman IT Solutions 310 812 4395 ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.us.dell.com_mailman_listinfo_linux-2Dpoweredge&d=DwICAg&c=9Hv6XPedRSA-5PSECC38X80c1h60_XWA4z1k_R1pROA&r=CfAaYCQEf7pGoAdbq0Icw0twCvsk5y-CVhkNDSSJWU0&m=7-VNCLmkBGYWR-b1BySKceKLSMsi72ECRpu5UYm29r0&s=age2iN5lvS7avxm90dRrt9mbQtsQZeHC_SJO-GL-57I&e= ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
Re: [Linux-PowerEdge] RPM repo GPG key changed
Chandra, Please provide the justification for not signing all of the RPMs with the new key. There are Dell customers with systems that do not have Internet connectivity and therefore need other solutions to manage the DSU and OMSA repositories. Red Hat's disconnected Satellite server is one method designed for this purpose but it does not support multiple GPG keys for the same repository. Is there a target date when all of the RPMs will be signed with this new key? Jeff Gottloeb Northrop Grumman IT Solutions 310 812 4395 ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
Re: [Linux-PowerEdge] RPM repo GPG key changed
Anand Buddhdev writes: > On 27/06/2018 18:37, Patrick Boutilier wrote: > >>> 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. > > That wouldn't be just a good solution, it would be the best solution! No... the BEST solution would be for Dell to release OMSA as proper Open Source software, and leave packaging and repository management to others. How about OMSA in EPEL? Wouldn't that be great? :) Cheers, -- Trond Hasle Amundsen ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
Re: [Linux-PowerEdge] RPM repo GPG key changed
On 28/06/2018 06:48, chandrasekha...@dell.com wrote: Hello Chandrasekhar, What is your plan to ensure that servers configured with the old key will pick up the new key and be able to update to the newer packages? Anand > 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 ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
[Linux-PowerEdge] RPM repo GPG key changed
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 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 To: linux-poweredge@dell.com Subject: Re: [Linux-PowerEdge] RPM repo GPG key changed Message-ID: 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
Re: [Linux-PowerEdge] RPM repo GPG key changed
On 27/06/2018 18:37, Patrick Boutilier wrote: >> 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. That wouldn't be just a good solution, it would be the best solution! I've just been reading all the messages in this thread, and I'm appalled at Chandrasekhar's (Dell's) response of telling folk to manually import some new key. It demonstrates a complete lack of understanding about managing systems and repositories. I'm asking Chandrasekhar/Dell: do you think everyone who uses the RPMs is on this list? For those who aren't on the list, how do you think they're supposed to find out about the solution? You need to start thinking about all the systems out there that are trying to update these tools and failing, and how you will allow for a graceful recovery from this f***-up. Telling folk here on this mailing list is NOT the solution; it's merely a temporary hack for those who choose to use it. it doesn't help all the others out there who're not on this list. I also have a case open with Dell support about this, but so far, no-one has come back to me with a solution. I hope Dell doesn't sign their dell.com domain with DNSSEC. They'll probably do key roll-overs just like this and screw it up too. A very annoyed user, Anand ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
Re: [Linux-PowerEdge] RPM repo GPG key changed
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 <>___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
Re: [Linux-PowerEdge] RPM repo GPG key changed
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 > ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
Re: [Linux-PowerEdge] RPM repo GPG key changed
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 -- John Hodrien Faculty of Engineering, IT 0113 3435471 10.39a EC Stoner ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
Re: [Linux-PowerEdge] RPM repo GPG key changed
Please make that rpm --import https://linux.dell.com/repo/hardware/dsu/public_gpg3.key changing http to https On Wed, 27 Jun 2018 11:35am, Patrick Boutilier wrote: External Email - Use Caution On 06/27/2018 11:02 AM, John Hodrien wrote: On Wed, 27 Jun 2018, chandrasekha...@dell.com wrote: Hi All, We have updated the Linux repository with SHA 512 public key. Please re-run repository setup command (curl -s http://linux.dell.com/repo/hardware/dsu/bootstrap.cgi | bash) to import the updated signature keys. Please let us know if you face any challenges. Can someone from Dell maintain a straight face whilst saying that piping the output of an http URL into a root bash process is a sensible thing to do? jh At the very least http://linux.dell.com/repo/hardware/dsu/bootstrap.cgi should be downloaded and inspected before running. But all that needs to be done for existing installations is to add this to the end of the gpgkey line in /etc/yum.repos.d/dell-system-update.repo : http://linux.dell.com/repo/hardware/dsu/public_gpg3.key yum will then ask to import they new key. Or just import it manually with: rpm --import http://linux.dell.com/repo/hardware/dsu/public_gpg3.key ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
Re: [Linux-PowerEdge] RPM repo GPG key changed
On 06/27/2018 11:02 AM, John Hodrien wrote: On Wed, 27 Jun 2018, chandrasekha...@dell.com wrote: Hi All, We have updated the Linux repository with SHA 512 public key. Please re-run repository setup command (curl -s http://linux.dell.com/repo/hardware/dsu/bootstrap.cgi | bash) to import the updated signature keys. Please let us know if you face any challenges. Can someone from Dell maintain a straight face whilst saying that piping the output of an http URL into a root bash process is a sensible thing to do? jh At the very least http://linux.dell.com/repo/hardware/dsu/bootstrap.cgi should be downloaded and inspected before running. But all that needs to be done for existing installations is to add this to the end of the gpgkey line in /etc/yum.repos.d/dell-system-update.repo : http://linux.dell.com/repo/hardware/dsu/public_gpg3.key yum will then ask to import they new key. Or just import it manually with: rpm --import http://linux.dell.com/repo/hardware/dsu/public_gpg3.key ___ 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
Re: [Linux-PowerEdge] RPM repo GPG key changed
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) 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 On Wed, 27 Jun 2018 10:02am, John Hodrien wrote: On Wed, 27 Jun 2018, chandrasekha...@dell.com wrote: Hi All, We have updated the Linux repository with SHA 512 public key. Please re-run repository setup command (curl -s http://linux.dell.com/repo/hardware/dsu/bootstrap.cgi | bash) to import the updated signature keys. Please let us know if you face any challenges. Can someone from Dell maintain a straight face whilst saying that piping the output of an http URL into a root bash process is a sensible thing to do? jh The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
Re: [Linux-PowerEdge] RPM repo GPG key changed
On Wed, 27 Jun 2018, chandrasekha...@dell.com wrote: Hi All, We have updated the Linux repository with SHA 512 public key. Please re-run repository setup command (curl -s http://linux.dell.com/repo/hardware/dsu/bootstrap.cgi | bash) to import the updated signature keys. Please let us know if you face any challenges. Can someone from Dell maintain a straight face whilst saying that piping the output of an http URL into a root bash process is a sensible thing to do? jh___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
[Linux-PowerEdge] RPM repo GPG key changed
Dell - Internal Use - Confidential Hi All, We have updated the Linux repository with SHA 512 public key. Please re-run repository setup command (curl -s http://linux.dell.com/repo/hardware/dsu/bootstrap.cgi | bash) to import the updated signature keys. Please let us know if you face any challenges. Regards, Chandra -- Message: 1 Date: Mon, 25 Jun 2018 10:33:06 -0400 From: Matt Vander Werf To: Trond Hasle Amundsen Cc: linux-poweredge@dell.com Subject: Re: [Linux-PowerEdge] RPM repo GPG key changed Message-ID: Content-Type: text/plain; charset="utf-8" I can confirm that it works on some systems but not on others when using Red Hat's latest version of libsmbios and smbios-utils-bin (2.3.3-6) on RHEL 7. When using the latest versions from Dell (2.3.1-3013.13047), it works everywhere. I haven't tested the versions in EPEL. I've found that on older 11G systems, the Red Hat versions don't work and I see the same things that Trond is seeing. This includes R815 systems and R810 systems (mostly all we have left from 11G). But on 12G and 13G systems the Red Hat versions work just fine. Presumably it works with 14G systems too, but we don't have any 14G systems up and running to test on yet. @Trond: What systems are you using that you're seeing the issues on? 11G systems by chance? So, it has something to do with the hardware itself that's not supported correctly with Red Hat's versions (but works fine with the latest Dell versions). Not sure is this is a Dell fix or Red Hat fix honestly (I would think Dell though). I can provide more info about systems I tested with, if that would help Dell. What Trond says is correct about the need for the new libsmbiosc++ package (see: https://access.redhat.com/solutions/3409271#comment-1307921...if anyone can't view this, let me know and I can send along the contents of the comment to the list). From my understanding, it looks there are some fixes that will be included in a new libsmbios release from Red Hat (possibly for the issues we're seeing with 11G systems, if it's already fixed in the newer EPEL version), which will eventually obsolete the EPEL libsmbios/smbios-utils-bin packages. So, sounds like there's still some planned work on this before everything works correctly. Thanks. -- Matt Vander Werf HPC System Administrator University of Notre Dame Center for Research Computing - Union Station 506 W. South Street South Bend, IN 46601 On Mon, Jun 25, 2018 at 9:41 AM, Trond Hasle Amundsen < t.h.amund...@usit.uio.no> wrote: > Patrick Boutilier writes: > > >> Installed smbios packages: > >> > >># rpm -qa|grep smbios > >>libsmbios-2.3.3-6.el7.x86_64 > >>libsmbiosc++-2.3.1-3013.13047.el7.x86_64 > >>smbios-utils-bin-2.3.3-6.el7.x86_64 > > > > Works fine here. I do have slightly more recent smibio rpms though. > > > > rpm -qa|grep smbios > > smbios-utils-bin-2.3.3-7.el7.x86_64 > > libsmbios-2.3.3-7.el7.x86_64 > > Yep, presumably those are from EPEL. However, since the libsmbios > package is now available through Red Hat official repositories, the > EPEL packages should be retired according to the EPEL policy. Packages > in EPEL should not conflict or override official Red Hat packages. > > Which means that the Dell packages should be made to function with the > Red Hat packages. It seems that the Red Hat libsmbios package is > missing some functionality, and that is the reasoning behind the new > libsmbiosc++ package from Dell. > > I've confirmed that it works with the (soon-to-be-retired) EPEL > packages, but it doesn't work with the new Red Hat libsmbios + Dell > libsmbiosc++ combo. Hopefully it's an easy fix for Dell :) > > Regards, > -- > Trond Hasle Amundsen > > ___ > Linux-PowerEdge mailing list > Linux-PowerEdge@dell.com > https://lists.us.dell.com/mailman/listinfo/linux-poweredge > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.us.dell.com/pipermail/linux-poweredge/attachments/20180625/d9fe0667/attachment-0001.html> -- Message: 2 Date: Mon, 25 Jun 2018 16:53:43 +0200 From: Trond Hasle Amundsen To: linux-poweredge@dell.com Subject: Re: [Linux-PowerEdge] RPM repo GPG key changed Message-ID: <15tpo0e29zc@tux.uio.no> Content-Type: text/plain Matt Vander Werf writes: > I can confirm that it works on some systems but not on others when > using Red Hat's latest version of libsmbios and smbios-utils-bin > (2.3.3-6) on RHEL 7. When using the latest versions from Dell > (2.3.1-3013.13047), it works everywhere. I haven't tested
Re: [Linux-PowerEdge] RPM repo GPG key changed
Matt Vander Werf writes: > I can confirm that it works on some systems but not on others when > using Red Hat's latest version of libsmbios and smbios-utils-bin > (2.3.3-6) on RHEL 7. When using the latest versions from Dell > (2.3.1-3013.13047), it works everywhere. I haven't tested the versions > in EPEL. > > I've found that on older 11G systems, the Red Hat versions don't work > and I see the same things that Trond is seeing. This includes R815 > systems and R810 systems (mostly all we have left from 11G). But on > 12G and 13G systems the Red Hat versions work just fine. Presumably it > works with 14G systems too, but we don't have any 14G systems up and > running to test on yet. @Trond: What systems are you using that you're > seeing the issues on? 11G systems by chance? Yes, I've tested this on a couple of 11G systems.. Didn't think to test on newer generations. > So, it has something to do with the hardware itself that's not > supported correctly with Red Hat's versions (but works fine with the > latest Dell versions). Not sure is this is a Dell fix or Red Hat fix > honestly (I would think Dell though). I can provide more info about > systems I tested with, if that would help Dell. > > What Trond says is correct about the need for the new libsmbiosc++ > package (see: > https://access.redhat.com/solutions/3409271#comment-1307921...if > anyone can't view this, let me know and I can send along the contents > of the comment to the list). From my understanding, it looks there are > some fixes that will be included in a new libsmbios release from Red > Hat (possibly for the issues we're seeing with 11G systems, if it's > already fixed in the newer EPEL version), which will eventually > obsolete the EPEL libsmbios/smbios-utils-bin packages. So, sounds like > there's still some planned work on this before everything works > correctly. Hmm.. If this is considered a bug or feature enhancement in the Red Hat package it could take some time before we have a fix. Red Hat usually only release (non-important) bug fixes as part of a major upgrade, meaning we may have to wait until RHEL 7.6. But with the EPEL packages working for 11G and the official Red Hat packages working for 12G and newer, and the Dell versions working everywhere, at least we have something that works. That's very good news! Thanks Matt :) Regards, -- Trond Hasle Amundsen ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
Re: [Linux-PowerEdge] RPM repo GPG key changed
I can confirm that it works on some systems but not on others when using Red Hat's latest version of libsmbios and smbios-utils-bin (2.3.3-6) on RHEL 7. When using the latest versions from Dell (2.3.1-3013.13047), it works everywhere. I haven't tested the versions in EPEL. I've found that on older 11G systems, the Red Hat versions don't work and I see the same things that Trond is seeing. This includes R815 systems and R810 systems (mostly all we have left from 11G). But on 12G and 13G systems the Red Hat versions work just fine. Presumably it works with 14G systems too, but we don't have any 14G systems up and running to test on yet. @Trond: What systems are you using that you're seeing the issues on? 11G systems by chance? So, it has something to do with the hardware itself that's not supported correctly with Red Hat's versions (but works fine with the latest Dell versions). Not sure is this is a Dell fix or Red Hat fix honestly (I would think Dell though). I can provide more info about systems I tested with, if that would help Dell. What Trond says is correct about the need for the new libsmbiosc++ package (see: https://access.redhat.com/solutions/3409271#comment-1307921...if anyone can't view this, let me know and I can send along the contents of the comment to the list). From my understanding, it looks there are some fixes that will be included in a new libsmbios release from Red Hat (possibly for the issues we're seeing with 11G systems, if it's already fixed in the newer EPEL version), which will eventually obsolete the EPEL libsmbios/smbios-utils-bin packages. So, sounds like there's still some planned work on this before everything works correctly. Thanks. -- Matt Vander Werf HPC System Administrator University of Notre Dame Center for Research Computing - Union Station 506 W. South Street South Bend, IN 46601 On Mon, Jun 25, 2018 at 9:41 AM, Trond Hasle Amundsen < t.h.amund...@usit.uio.no> wrote: > Patrick Boutilier writes: > > >> Installed smbios packages: > >> > >># rpm -qa|grep smbios > >>libsmbios-2.3.3-6.el7.x86_64 > >>libsmbiosc++-2.3.1-3013.13047.el7.x86_64 > >>smbios-utils-bin-2.3.3-6.el7.x86_64 > > > > Works fine here. I do have slightly more recent smibio rpms though. > > > > rpm -qa|grep smbios > > smbios-utils-bin-2.3.3-7.el7.x86_64 > > libsmbios-2.3.3-7.el7.x86_64 > > Yep, presumably those are from EPEL. However, since the libsmbios > package is now available through Red Hat official repositories, the EPEL > packages should be retired according to the EPEL policy. Packages in > EPEL should not conflict or override official Red Hat packages. > > Which means that the Dell packages should be made to function with the > Red Hat packages. It seems that the Red Hat libsmbios package is missing > some functionality, and that is the reasoning behind the new libsmbiosc++ > package from Dell. > > I've confirmed that it works with the (soon-to-be-retired) EPEL > packages, but it doesn't work with the new Red Hat libsmbios + Dell > libsmbiosc++ combo. Hopefully it's an easy fix for Dell :) > > Regards, > -- > Trond Hasle Amundsen > > ___ > 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
Re: [Linux-PowerEdge] RPM repo GPG key changed
Patrick Boutilier writes: >> Installed smbios packages: >> >># rpm -qa|grep smbios >>libsmbios-2.3.3-6.el7.x86_64 >>libsmbiosc++-2.3.1-3013.13047.el7.x86_64 >>smbios-utils-bin-2.3.3-6.el7.x86_64 > > Works fine here. I do have slightly more recent smibio rpms though. > > rpm -qa|grep smbios > smbios-utils-bin-2.3.3-7.el7.x86_64 > libsmbios-2.3.3-7.el7.x86_64 Yep, presumably those are from EPEL. However, since the libsmbios package is now available through Red Hat official repositories, the EPEL packages should be retired according to the EPEL policy. Packages in EPEL should not conflict or override official Red Hat packages. Which means that the Dell packages should be made to function with the Red Hat packages. It seems that the Red Hat libsmbios package is missing some functionality, and that is the reasoning behind the new libsmbiosc++ package from Dell. I've confirmed that it works with the (soon-to-be-retired) EPEL packages, but it doesn't work with the new Red Hat libsmbios + Dell libsmbiosc++ combo. Hopefully it's an easy fix for Dell :) Regards, -- Trond Hasle Amundsen ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
[Linux-PowerEdge] RPM repo GPG key changed
Dell - Internal Use - Confidential Hi All, Apologies for the inconvenience caused. We are working towards a solution and update the same as soon as possible. Regards, Chandra -- Message: 1 Date: Fri, 22 Jun 2018 14:28:11 +0200 From: Trond Hasle Amundsen To: Cc: linux-powere...@lists.us.dell.com Subject: Re: [Linux-PowerEdge] RPM repo GPG key changed Message-ID: <15tk1qr2eg4@tux.uio.no> Content-Type: text/plain writes: > We used to sign using SHA1 algorithm which is deprecated and the > latest packages are signed using SHA512. In-order to resolve this > issue, the corresponding public key needs to be imported before yum > update. Kindly run the following command to import the public key. > > rpm --import > http://linux.dell.com/repo/pgp_pubkeys/0x1285491434D8786F.asc > > Let us know if you face any challenges. New gpg key aside, the updated packages seems utterly broken on RHEL7.5: # /usr/sbin/smbios-sys-info-lite Libsmbios:2.3.3 System ID:0x0287 Service Tag: xxx Express Service Code: x *** Error in `/usr/sbin/smbios-sys-info-lite': free(): invalid pointer: 0x00634460 *** === Backtrace: = /lib64/libc.so.6(+0x81429)[0x7f3f7be13429] /usr/sbin/smbios-sys-info-lite[0x40ecc2] /usr/sbin/smbios-sys-info-lite[0x4067c4] /usr/sbin/smbios-sys-info-lite[0x40768e] /usr/sbin/smbios-sys-info-lite[0x401613] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7f3f7bdb43d5] /usr/sbin/smbios-sys-info-lite[0x401279] === Memory map: 0040-00434000 r-xp fd:02 4420107 /usr/sbin/smbios-sys-info-lite 00633000-00634000 r--p 00033000 fd:02 4420107 /usr/sbin/smbios-sys-info-lite 00634000-00635000 rw-p 00034000 fd:02 4420107 /usr/sbin/smbios-sys-info-lite 01171000-01192000 rw-p 00:00 0 [heap] 7f3f7000-7f3f70021000 rw-p 00:00 0 7f3f70021000-7f3f7400 ---p 00:00 0 7f3f75653000-7f3f75668000 r-xp fd:02 4195559 /usr/lib64/libgcc_s-4.8.5-20150702.so.1 7f3f75668000-7f3f75867000 ---p 00015000 fd:02 4195559 /usr/lib64/libgcc_s-4.8.5-20150702.so.1 7f3f75867000-7f3f75868000 r--p 00014000 fd:02 4195559 /usr/lib64/libgcc_s-4.8.5-20150702.so.1 7f3f75868000-7f3f75869000 rw-p 00015000 fd:02 4195559 /usr/lib64/libgcc_s-4.8.5-20150702.so.1 7f3f75869000-7f3f7bd92000 r--p fd:02 8444610 /usr/lib/locale/locale-archive 7f3f7bd92000-7f3f7bf55000 r-xp fd:02 4252246 /usr/lib64/libc-2.17.so 7f3f7bf55000-7f3f7c154000 ---p 001c3000 fd:02 4252246 /usr/lib64/libc-2.17.so 7f3f7c154000-7f3f7c158000 r--p 001c2000 fd:02 4252246 /usr/lib64/libc-2.17.so 7f3f7c158000-7f3f7c15a000 rw-p 001c6000 fd:02 4252246 /usr/lib64/libc-2.17.so 7f3f7c15a000-7f3f7c15f000 rw-p 00:00 0 7f3f7c15f000-7f3f7c181000 r-xp fd:02 4252239 /usr/lib64/ld-2.17.so 7f3f7c36c000-7f3f7c36f000 rw-p 00:00 0 7f3f7c37d000-7f3f7c38 rw-p 00:00 0 7f3f7c38-7f3f7c381000 r--p 00021000 fd:02 4252239 /usr/lib64/ld-2.17.so 7f3f7c381000-7f3f7c382000 rw-p 00022000 fd:02 4252239 /usr/lib64/ld-2.17.so 7f3f7c382000-7f3f7c383000 rw-p 00:00 0 7ffe7a5e7000-7ffe7a608000 rw-p 00:00 0 [stack] 7ffe7a6ba000-7ffe7a6bc000 r-xp 00:00 0 [vdso] ff60-ff601000 r-xp 00:00 0 [vsyscall] Aborted The OMSA services refuse to start after applying the update... same error output as above, which ends with: dsm_om_shrsvc: DSM SA Shared Services cannot start on an unsupported system. See the Dell EMC Systems Software Support Matrix for a list of supported systems. Installed smbios packages: # rpm -qa|grep smbios libsmbios-2.3.3-6.el7.x86_64 libsmbiosc++-2.3.1-3013.13047.el7.x86_64 smbios-utils-bin-2.3.3-6.el7.x86_64 Regards, -- Trond Hasle Amundsen -- Message: 2 Date: Fri, 22 Jun 2018 09:10:58 -0400 From: Robert Jacobson To: chandrasekha...@dell.com Cc: Linux-PowerEdge Subject: Re: [Linux-PowerEdge] RPM repo GPG key changed Message-ID: Content-Type: text/plain; charset="utf-8" Does this signature change also affect the OME catalog? ( http://downloads.dell.com/catalog/catalog.cab ) I tried to download today's catalog in OME and OME is reporting a bad signature: "Import Dell EMC Version Control Catalog for System Update from http://downloads.dell.com/catalog/catalog.cab failed.Exception message: Catalog signature
Re: [Linux-PowerEdge] RPM repo GPG key changed
The catalog.cab issue appears to be a server issue, not a problem with the change in signature. Either the download isn't completing or the server is providing different files: Here a two "wget" logs, 10 seconds apart. The first download completes (and the signature is valid). The second one says it completed, but the size is smaller, and the signature is not valid (probably due to signature being cut off) --2018-06-22 13:30:15-- http://downloads.dell.com/catalog/catalog.cab Resolving downloads.dell.com... 23.218.148.26, 2001:5014:101:198::1c, 2001:5014:101:19a::1c Connecting to downloads.dell.com|23.218.148.26|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1827802 (1.7M) [application/vnd.ms-cab-compressed] Saving to: âcatalog.cabâ 100%[==>] 1,827,802 9.62M/s in 0.2s 2018-06-22 13:30:26 (9.62 MB/s) - âcatalog.cabâ 27299e4d086debfbfe5e04ba845d846e catalog.cab -rw---. 1 rjacobson rjacobson 1827802 Jun 22 07:01 catalog.cab --2018-06-22 13:30:36-- http://downloads.dell.com/catalog/catalog.cab Resolving downloads.dell.com... 23.218.148.26, 2001:5014:101:19a::1c, 2001:5014:101:198::1c Connecting to downloads.dell.com|23.218.148.26|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1799282 (1.7M) [application/vnd.ms-cab-compressed] Saving to: âcatalog.cabâ 100%[==>] 1,799,282 10.4M/s in 0.2s 2018-06-22 13:30:36 (10.4 MB/s) - âcatalog.cabâ bdae143a8ab41feba8d600bd486c8a6f catalog.cab -rw---. 1 rjacobson rjacobson 1799282 Jun 22 07:01 catalog.cab [user@server dell]$ /usr/bin/cabextract -l catalog.cab catalog.cab: WARNING; file possibly truncated by 14064 bytes. catalog.cab: no valid cabinets found On Fri, Jun 22, 2018 at 9:10 AM, Robert Jacobson wrote: > > Does this signature change also affect the OME catalog? ( > http://downloads.dell.com/catalog/catalog.cab ) > > I tried to download today's catalog in OME and OME is reporting a bad > signature: > > "Import Dell EMC Version Control Catalog for System Update from > http://downloads.dell.com/catalog/catalog.cab failed.Exception message: > Catalog signature verification failed. Please enable/verify proxy settings > if required." > > ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
Re: [Linux-PowerEdge] RPM repo GPG key changed
On 06/22/2018 09:28 AM, Trond Hasle Amundsen wrote: writes: We used to sign using SHA1 algorithm which is deprecated and the latest packages are signed using SHA512. In-order to resolve this issue, the corresponding public key needs to be imported before yum update. Kindly run the following command to import the public key. rpm --import http://linux.dell.com/repo/pgp_pubkeys/0x1285491434D8786F.asc Let us know if you face any challenges. New gpg key aside, the updated packages seems utterly broken on RHEL7.5: # /usr/sbin/smbios-sys-info-lite Libsmbios:2.3.3 System ID:0x0287 Service Tag: xxx Express Service Code: x *** Error in `/usr/sbin/smbios-sys-info-lite': free(): invalid pointer: 0x00634460 *** === Backtrace: = /lib64/libc.so.6(+0x81429)[0x7f3f7be13429] /usr/sbin/smbios-sys-info-lite[0x40ecc2] /usr/sbin/smbios-sys-info-lite[0x4067c4] /usr/sbin/smbios-sys-info-lite[0x40768e] /usr/sbin/smbios-sys-info-lite[0x401613] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7f3f7bdb43d5] /usr/sbin/smbios-sys-info-lite[0x401279] === Memory map: 0040-00434000 r-xp fd:02 4420107 /usr/sbin/smbios-sys-info-lite 00633000-00634000 r--p 00033000 fd:02 4420107 /usr/sbin/smbios-sys-info-lite 00634000-00635000 rw-p 00034000 fd:02 4420107 /usr/sbin/smbios-sys-info-lite 01171000-01192000 rw-p 00:00 0 [heap] 7f3f7000-7f3f70021000 rw-p 00:00 0 7f3f70021000-7f3f7400 ---p 00:00 0 7f3f75653000-7f3f75668000 r-xp fd:02 4195559 /usr/lib64/libgcc_s-4.8.5-20150702.so.1 7f3f75668000-7f3f75867000 ---p 00015000 fd:02 4195559 /usr/lib64/libgcc_s-4.8.5-20150702.so.1 7f3f75867000-7f3f75868000 r--p 00014000 fd:02 4195559 /usr/lib64/libgcc_s-4.8.5-20150702.so.1 7f3f75868000-7f3f75869000 rw-p 00015000 fd:02 4195559 /usr/lib64/libgcc_s-4.8.5-20150702.so.1 7f3f75869000-7f3f7bd92000 r--p fd:02 8444610 /usr/lib/locale/locale-archive 7f3f7bd92000-7f3f7bf55000 r-xp fd:02 4252246 /usr/lib64/libc-2.17.so 7f3f7bf55000-7f3f7c154000 ---p 001c3000 fd:02 4252246 /usr/lib64/libc-2.17.so 7f3f7c154000-7f3f7c158000 r--p 001c2000 fd:02 4252246 /usr/lib64/libc-2.17.so 7f3f7c158000-7f3f7c15a000 rw-p 001c6000 fd:02 4252246 /usr/lib64/libc-2.17.so 7f3f7c15a000-7f3f7c15f000 rw-p 00:00 0 7f3f7c15f000-7f3f7c181000 r-xp fd:02 4252239 /usr/lib64/ld-2.17.so 7f3f7c36c000-7f3f7c36f000 rw-p 00:00 0 7f3f7c37d000-7f3f7c38 rw-p 00:00 0 7f3f7c38-7f3f7c381000 r--p 00021000 fd:02 4252239 /usr/lib64/ld-2.17.so 7f3f7c381000-7f3f7c382000 rw-p 00022000 fd:02 4252239 /usr/lib64/ld-2.17.so 7f3f7c382000-7f3f7c383000 rw-p 00:00 0 7ffe7a5e7000-7ffe7a608000 rw-p 00:00 0 [stack] 7ffe7a6ba000-7ffe7a6bc000 r-xp 00:00 0 [vdso] ff60-ff601000 r-xp 00:00 0 [vsyscall] Aborted The OMSA services refuse to start after applying the update... same error output as above, which ends with: dsm_om_shrsvc: DSM SA Shared Services cannot start on an unsupported system. See the Dell EMC Systems Software Support Matrix for a list of supported systems. Installed smbios packages: # rpm -qa|grep smbios libsmbios-2.3.3-6.el7.x86_64 libsmbiosc++-2.3.1-3013.13047.el7.x86_64 smbios-utils-bin-2.3.3-6.el7.x86_64 Regards, Works fine here. I do have slightly more recent smibio rpms though. rpm -qa|grep smbios smbios-utils-bin-2.3.3-7.el7.x86_64 libsmbios-2.3.3-7.el7.x86_64 <>___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
Re: [Linux-PowerEdge] RPM repo GPG key changed
Does this signature change also affect the OME catalog? ( http://downloads.dell.com/catalog/catalog.cab ) I tried to download today's catalog in OME and OME is reporting a bad signature: "Import Dell EMC Version Control Catalog for System Update from http://downloads.dell.com/catalog/catalog.cab failed.Exception message: Catalog signature verification failed. Please enable/verify proxy settings if required." ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
Re: [Linux-PowerEdge] RPM repo GPG key changed
writes: > We used to sign using SHA1 algorithm which is deprecated and the > latest packages are signed using SHA512. In-order to resolve this > issue, the corresponding public key needs to be imported before yum > update. Kindly run the following command to import the public key. > > rpm --import http://linux.dell.com/repo/pgp_pubkeys/0x1285491434D8786F.asc > > Let us know if you face any challenges. New gpg key aside, the updated packages seems utterly broken on RHEL7.5: # /usr/sbin/smbios-sys-info-lite Libsmbios:2.3.3 System ID:0x0287 Service Tag: xxx Express Service Code: x *** Error in `/usr/sbin/smbios-sys-info-lite': free(): invalid pointer: 0x00634460 *** === Backtrace: = /lib64/libc.so.6(+0x81429)[0x7f3f7be13429] /usr/sbin/smbios-sys-info-lite[0x40ecc2] /usr/sbin/smbios-sys-info-lite[0x4067c4] /usr/sbin/smbios-sys-info-lite[0x40768e] /usr/sbin/smbios-sys-info-lite[0x401613] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7f3f7bdb43d5] /usr/sbin/smbios-sys-info-lite[0x401279] === Memory map: 0040-00434000 r-xp fd:02 4420107 /usr/sbin/smbios-sys-info-lite 00633000-00634000 r--p 00033000 fd:02 4420107 /usr/sbin/smbios-sys-info-lite 00634000-00635000 rw-p 00034000 fd:02 4420107 /usr/sbin/smbios-sys-info-lite 01171000-01192000 rw-p 00:00 0 [heap] 7f3f7000-7f3f70021000 rw-p 00:00 0 7f3f70021000-7f3f7400 ---p 00:00 0 7f3f75653000-7f3f75668000 r-xp fd:02 4195559 /usr/lib64/libgcc_s-4.8.5-20150702.so.1 7f3f75668000-7f3f75867000 ---p 00015000 fd:02 4195559 /usr/lib64/libgcc_s-4.8.5-20150702.so.1 7f3f75867000-7f3f75868000 r--p 00014000 fd:02 4195559 /usr/lib64/libgcc_s-4.8.5-20150702.so.1 7f3f75868000-7f3f75869000 rw-p 00015000 fd:02 4195559 /usr/lib64/libgcc_s-4.8.5-20150702.so.1 7f3f75869000-7f3f7bd92000 r--p fd:02 8444610 /usr/lib/locale/locale-archive 7f3f7bd92000-7f3f7bf55000 r-xp fd:02 4252246 /usr/lib64/libc-2.17.so 7f3f7bf55000-7f3f7c154000 ---p 001c3000 fd:02 4252246 /usr/lib64/libc-2.17.so 7f3f7c154000-7f3f7c158000 r--p 001c2000 fd:02 4252246 /usr/lib64/libc-2.17.so 7f3f7c158000-7f3f7c15a000 rw-p 001c6000 fd:02 4252246 /usr/lib64/libc-2.17.so 7f3f7c15a000-7f3f7c15f000 rw-p 00:00 0 7f3f7c15f000-7f3f7c181000 r-xp fd:02 4252239 /usr/lib64/ld-2.17.so 7f3f7c36c000-7f3f7c36f000 rw-p 00:00 0 7f3f7c37d000-7f3f7c38 rw-p 00:00 0 7f3f7c38-7f3f7c381000 r--p 00021000 fd:02 4252239 /usr/lib64/ld-2.17.so 7f3f7c381000-7f3f7c382000 rw-p 00022000 fd:02 4252239 /usr/lib64/ld-2.17.so 7f3f7c382000-7f3f7c383000 rw-p 00:00 0 7ffe7a5e7000-7ffe7a608000 rw-p 00:00 0 [stack] 7ffe7a6ba000-7ffe7a6bc000 r-xp 00:00 0 [vdso] ff60-ff601000 r-xp 00:00 0 [vsyscall] Aborted The OMSA services refuse to start after applying the update... same error output as above, which ends with: dsm_om_shrsvc: DSM SA Shared Services cannot start on an unsupported system. See the Dell EMC Systems Software Support Matrix for a list of supported systems. Installed smbios packages: # rpm -qa|grep smbios libsmbios-2.3.3-6.el7.x86_64 libsmbiosc++-2.3.1-3013.13047.el7.x86_64 smbios-utils-bin-2.3.3-6.el7.x86_64 Regards, -- Trond Hasle Amundsen ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
Re: [Linux-PowerEdge] RPM repo GPG key changed
First, yes this is troublesome, especially with no notice that this change was going to occur. Second, you're going to have to explain that again in some detail as it just doesn't make sense to me. Why did you need a different key? I assume the move was from the 2048 bit key to your 4096 bit key? You could sign packages with either regardless of whether you used sha1, sha256 or sha512. -Erinn On 06/21/2018 11:03 PM, chandrasekha...@dell.com wrote: > Hi All, > > We used to sign using SHA1 algorithm which is deprecated and the latest > packages are signed using SHA512. In-order to resolve this issue, the > corresponding public key needs to be imported before yum update. Kindly run > the following command to import the public key. > > rpm --import http://linux.dell.com/repo/pgp_pubkeys/0x1285491434D8786F.asc > > Let us know if you face any challenges. > > Regards, > Chandra > -- > > Message: 1 > Date: Thu, 21 Jun 2018 12:33:24 -0700 > From: Kilian Cavalotti > To: linux-powere...@lists.us.dell.com > Subject: [Linux-PowerEdge] RPM repo GPG key changed? > Message-ID: > > Content-Type: text/plain; charset="UTF-8" > > Hi, > > Did the RPM repository GPG keys change somehow? > > Trying to update srvadmin packages today leads to the following error: > > - > Retrieving key from http://linux.dell.com/repo/hardware/dsu/public.key > > > The GPG keys listed for the "dell-system-update_dependent" repository are > already installed but they are not correct for this package. > Check that the correct key URLs are configured for this repository. > > > Failing package is: srvadmin-omilcore-9.1.0-3013.13047.el7.x86_64 > GPG Keys are configured as: http://linux.dell.com/repo/hardware/dsu/public.key > - > > FWIW, the repository configuration didn't change on that host, and it has > been working fine for months. > > Cheers, > -- > Kilian > > > > ------ > > Message: 2 > Date: Thu, 21 Jun 2018 13:37:37 -0600 > From: Erinn Looney-Triggs > To: linux-poweredge@dell.com > Subject: Re: [Linux-PowerEdge] RPM repo GPG key changed? > Message-ID: > Content-Type: text/plain; charset=utf-8 > > Same here just to confirm your findings. > > > On 06/21/2018 01:33 PM, Kilian Cavalotti wrote: >> Hi, >> >> Did the RPM repository GPG keys change somehow? >> >> Trying to update srvadmin packages today leads to the following error: >> >> - >> Retrieving key from http://linux.dell.com/repo/hardware/dsu/public.key >> >> >> The GPG keys listed for the "dell-system-update_dependent" repository >> are already installed but they are not correct for this package. >> Check that the correct key URLs are configured for this repository. >> >> >> Failing package is: srvadmin-omilcore-9.1.0-3013.13047.el7.x86_64 >> GPG Keys are configured as: >> http://linux.dell.com/repo/hardware/dsu/public.key >> - >> >> FWIW, the repository configuration didn't change on that host, and it >> has been working fine for months. >> >> Cheers, > > > -- > > Message: 3 > Date: Thu, 21 Jun 2018 22:45:07 +0300 > From: Anssi Johansson > To: linux-poweredge@dell.com > Subject: Re: [Linux-PowerEdge] RPM repo GPG key changed? > Message-ID: <34a6a06f-f383-0e33-8d1e-98a60af29...@miuku.net> > Content-Type: text/plain; charset=utf-8; format=flowed > > Kilian Cavalotti kirjoitti 21.6.2018 klo 22.33: >> Hi, >> >> Did the RPM repository GPG keys change somehow? >> >> Trying to update srvadmin packages today leads to the following error: >> >> - >> Retrieving key from http://linux.dell.com/repo/hardware/dsu/public.key >> >> >> The GPG keys listed for the "dell-system-update_dependent" repository >> are already installed but they are not correct for this package. >> Check that the correct key URLs are configured for this repository. >> >> >> Failing package is: srvadmin-omilcore-9.1.0-3013.13047.el7.x86_64 >> GPG Keys are configured as: >> http://linux.dell.com/repo/hardware/dsu/public.key >> - >> >> FWIW, the repository configuration didn't change on that host, and it >> has been working fine for months. > Yes, something has definitely changed. > > # yum update > ... > Depe
[Linux-PowerEdge] RPM repo GPG key changed
Hi All, We used to sign using SHA1 algorithm which is deprecated and the latest packages are signed using SHA512. In-order to resolve this issue, the corresponding public key needs to be imported before yum update. Kindly run the following command to import the public key. rpm --import http://linux.dell.com/repo/pgp_pubkeys/0x1285491434D8786F.asc Let us know if you face any challenges. Regards, Chandra -- Message: 1 Date: Thu, 21 Jun 2018 12:33:24 -0700 From: Kilian Cavalotti To: linux-powere...@lists.us.dell.com Subject: [Linux-PowerEdge] RPM repo GPG key changed? Message-ID: Content-Type: text/plain; charset="UTF-8" Hi, Did the RPM repository GPG keys change somehow? Trying to update srvadmin packages today leads to the following error: - Retrieving key from http://linux.dell.com/repo/hardware/dsu/public.key The GPG keys listed for the "dell-system-update_dependent" repository are already installed but they are not correct for this package. Check that the correct key URLs are configured for this repository. Failing package is: srvadmin-omilcore-9.1.0-3013.13047.el7.x86_64 GPG Keys are configured as: http://linux.dell.com/repo/hardware/dsu/public.key - FWIW, the repository configuration didn't change on that host, and it has been working fine for months. Cheers, -- Kilian -- Message: 2 Date: Thu, 21 Jun 2018 13:37:37 -0600 From: Erinn Looney-Triggs To: linux-poweredge@dell.com Subject: Re: [Linux-PowerEdge] RPM repo GPG key changed? Message-ID: Content-Type: text/plain; charset=utf-8 Same here just to confirm your findings. On 06/21/2018 01:33 PM, Kilian Cavalotti wrote: > Hi, > > Did the RPM repository GPG keys change somehow? > > Trying to update srvadmin packages today leads to the following error: > > - > Retrieving key from http://linux.dell.com/repo/hardware/dsu/public.key > > > The GPG keys listed for the "dell-system-update_dependent" repository > are already installed but they are not correct for this package. > Check that the correct key URLs are configured for this repository. > > > Failing package is: srvadmin-omilcore-9.1.0-3013.13047.el7.x86_64 > GPG Keys are configured as: http://linux.dell.com/repo/hardware/dsu/public.key > - > > FWIW, the repository configuration didn't change on that host, and it > has been working fine for months. > > Cheers, -- Message: 3 Date: Thu, 21 Jun 2018 22:45:07 +0300 From: Anssi Johansson To: linux-poweredge@dell.com Subject: Re: [Linux-PowerEdge] RPM repo GPG key changed? Message-ID: <34a6a06f-f383-0e33-8d1e-98a60af29...@miuku.net> Content-Type: text/plain; charset=utf-8; format=flowed Kilian Cavalotti kirjoitti 21.6.2018 klo 22.33: > Hi, > > Did the RPM repository GPG keys change somehow? > > Trying to update srvadmin packages today leads to the following error: > > - > Retrieving key from http://linux.dell.com/repo/hardware/dsu/public.key > > > The GPG keys listed for the "dell-system-update_dependent" repository > are already installed but they are not correct for this package. > Check that the correct key URLs are configured for this repository. > > > Failing package is: srvadmin-omilcore-9.1.0-3013.13047.el7.x86_64 > GPG Keys are configured as: http://linux.dell.com/repo/hardware/dsu/public.key > - > > FWIW, the repository configuration didn't change on that host, and it > has been working fine for months. Yes, something has definitely changed. # yum update ... Dependencies Resolved = Package Arch Version Repository Size = Updating: srvadmin-omacs x86_64 9.1.0-3013.13047.el7 dell-omsa-indep 2.7 M srvadmin-omilcore x86_64 9.1.0-3013.13047.el7 dell-omsa-indep37 k Transaction Summary = Upgrade 2 Packages Total size: 2.7 M Is this ok [y/d/N]: y Downloading packages: warning: /var/cache/yum/x86_64/7/dell-omsa-indep/packages/srvadmin-omilcore-9.1.0-3013.13047.el7.x86_64.rpm: Header V4 RSA/SHA512 Signature, key ID 34d8786f: NOKEY Retrieving key from http://linux.dell.com/repo/hardware/latest/RPM-GPG-KEY-dell GPG key retrieval failed: [Errno 14] HTTP Error 404 - Not Found ---
Re: [Linux-PowerEdge] RPM repo GPG key changed?
@Dell team, Could you please confirm if the GPG key was intentionally changed, and provide some information about that change, or if we should consider that the Dell RPM repository has been compromised and stop using it right away? Thanks, -- Kilian ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
Re: [Linux-PowerEdge] RPM repo GPG key changed?
Kilian Cavalotti kirjoitti 21.6.2018 klo 22.33: Hi, Did the RPM repository GPG keys change somehow? Further info: Current installed package: # rpm -qi srvadmin-omilcore Name: srvadmin-omilcore Version : 9.1.0 Release : 2757.12163.el7 Architecture: x86_64 Install Date: Tue 26 Dec 2017 10:26:04 PM EET Group : System/Configuration/Hardware Size: 85659 License : Dell Proprietary Signature : DSA/SHA1, Sun 22 Oct 2017 06:16:27 PM EEST, Key ID ca77951d23b66a9d Source RPM : srvadmin-omilcore-9.1.0-2757.12163.el7.src.rpm Build Date : Sun 22 Oct 2017 06:04:38 PM EEST Build Host : bsmvr70pbl01.blr.amer.dell.com Relocations : (not relocatable) Vendor : Dell Inc URL : http://support.dell.com Summary : Server Administrator Install Core, 9.1.0 Package that was downloaded: # rpm -qip srvadmin-omilcore-9.1.0-3013.13047.el7.x86_64.rpm warning: srvadmin-omilcore-9.1.0-3013.13047.el7.x86_64.rpm: Header V4 RSA/SHA512 Signature, key ID 34d8786f: NOKEY Name: srvadmin-omilcore Version : 9.1.0 Release : 3013.13047.el7 Architecture: x86_64 Install Date: (not installed) Group : System/Configuration/Hardware Size: 85659 License : Dell Proprietary Signature : RSA/SHA512, Wed 30 May 2018 10:41:04 PM EEST, Key ID 1285491434d8786f Source RPM : srvadmin-omilcore-9.1.0-3013.13047.el7.src.rpm Build Date : Wed 30 May 2018 10:31:15 PM EEST Build Host : bsmvr70pbl01.blr.amer.dell.com Relocations : (not relocatable) Vendor : Dell Inc URL : http://support.dell.com Summary : Server Administrator Install Core, 9.1.0.2 Note the Signature line, different keys are being used. 1285491434d8786f is a Dell key, but looks like it's primarily used for signing Debian/Ubuntu packages. If this change was intentional, I'd say it wasn't properly communicated. ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
Re: [Linux-PowerEdge] RPM repo GPG key changed?
Kilian Cavalotti kirjoitti 21.6.2018 klo 22.33: Hi, Did the RPM repository GPG keys change somehow? Trying to update srvadmin packages today leads to the following error: - Retrieving key from http://linux.dell.com/repo/hardware/dsu/public.key The GPG keys listed for the "dell-system-update_dependent" repository are already installed but they are not correct for this package. Check that the correct key URLs are configured for this repository. Failing package is: srvadmin-omilcore-9.1.0-3013.13047.el7.x86_64 GPG Keys are configured as: http://linux.dell.com/repo/hardware/dsu/public.key - FWIW, the repository configuration didn't change on that host, and it has been working fine for months. Yes, something has definitely changed. # yum update ... Dependencies Resolved = Package Arch Version Repository Size = Updating: srvadmin-omacs x86_64 9.1.0-3013.13047.el7 dell-omsa-indep 2.7 M srvadmin-omilcore x86_64 9.1.0-3013.13047.el7 dell-omsa-indep37 k Transaction Summary = Upgrade 2 Packages Total size: 2.7 M Is this ok [y/d/N]: y Downloading packages: warning: /var/cache/yum/x86_64/7/dell-omsa-indep/packages/srvadmin-omilcore-9.1.0-3013.13047.el7.x86_64.rpm: Header V4 RSA/SHA512 Signature, key ID 34d8786f: NOKEY Retrieving key from http://linux.dell.com/repo/hardware/latest/RPM-GPG-KEY-dell GPG key retrieval failed: [Errno 14] HTTP Error 404 - Not Found ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
Re: [Linux-PowerEdge] RPM repo GPG key changed?
Same here just to confirm your findings. On 06/21/2018 01:33 PM, Kilian Cavalotti wrote: > Hi, > > Did the RPM repository GPG keys change somehow? > > Trying to update srvadmin packages today leads to the following error: > > - > Retrieving key from http://linux.dell.com/repo/hardware/dsu/public.key > > > The GPG keys listed for the "dell-system-update_dependent" repository > are already installed but they are not correct for this package. > Check that the correct key URLs are configured for this repository. > > > Failing package is: srvadmin-omilcore-9.1.0-3013.13047.el7.x86_64 > GPG Keys are configured as: http://linux.dell.com/repo/hardware/dsu/public.key > - > > FWIW, the repository configuration didn't change on that host, and it > has been working fine for months. > > Cheers, ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge
[Linux-PowerEdge] RPM repo GPG key changed?
Hi, Did the RPM repository GPG keys change somehow? Trying to update srvadmin packages today leads to the following error: - Retrieving key from http://linux.dell.com/repo/hardware/dsu/public.key The GPG keys listed for the "dell-system-update_dependent" repository are already installed but they are not correct for this package. Check that the correct key URLs are configured for this repository. Failing package is: srvadmin-omilcore-9.1.0-3013.13047.el7.x86_64 GPG Keys are configured as: http://linux.dell.com/repo/hardware/dsu/public.key - FWIW, the repository configuration didn't change on that host, and it has been working fine for months. Cheers, -- Kilian ___ Linux-PowerEdge mailing list Linux-PowerEdge@dell.com https://lists.us.dell.com/mailman/listinfo/linux-poweredge