Re: [Linux-PowerEdge] RPM repo GPG key changed

2018-07-11 Thread Ray.Hebert
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

2018-07-11 Thread Aparna.Giri
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

2018-07-11 Thread Anand Buddhdev
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

2018-07-11 Thread Aparna.Giri
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

2018-07-10 Thread Anand Buddhdev
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

2018-07-09 Thread Anand Buddhdev
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

2018-07-02 Thread Aparna.Giri
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

2018-07-02 Thread Anand Buddhdev
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

2018-07-02 Thread Aparna.Giri
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

2018-07-02 Thread Anand Buddhdev
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

2018-06-29 Thread James Mathiesen
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

2018-06-28 Thread Gottloeb, Jeff [US] (ES)
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

2018-06-28 Thread Trond Hasle Amundsen
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

2018-06-27 Thread Anand Buddhdev
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


Re: [Linux-PowerEdge] RPM repo GPG key changed

2018-06-27 Thread Anand Buddhdev
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

2018-06-27 Thread Patrick Boutilier

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

2018-06-27 Thread Erinn Looney-Triggs
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

2018-06-27 Thread John Hodrien

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

2018-06-27 Thread Paul Raines


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

2018-06-27 Thread Patrick Boutilier

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

2018-06-27 Thread Paul Raines


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

2018-06-27 Thread John Hodrien

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


Re: [Linux-PowerEdge] RPM repo GPG key changed

2018-06-25 Thread Trond Hasle Amundsen
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

2018-06-25 Thread Matt Vander Werf
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

2018-06-25 Thread Trond Hasle Amundsen
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


Re: [Linux-PowerEdge] RPM repo GPG key changed

2018-06-22 Thread Robert Jacobson
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

2018-06-22 Thread Patrick Boutilier

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

2018-06-22 Thread Robert Jacobson
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

2018-06-22 Thread Trond Hasle Amundsen
 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

2018-06-22 Thread Erinn Looney-Triggs
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

Re: [Linux-PowerEdge] RPM repo GPG key changed?

2018-06-21 Thread Kilian Cavalotti
@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?

2018-06-21 Thread Anssi Johansson

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?

2018-06-21 Thread Anssi Johansson

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?

2018-06-21 Thread Erinn Looney-Triggs
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