[scl.org] Python "latest" SCLo

Thu Jun 29 17:07:37 UTC 2017

So, maybe I've missed something, but is this more complicated than running rpmbuild with different Macros?    I'm pretty good with rpms, but I know I don't always follow Fedora Packaging Guidelines.   I know that our DevOps guys will not want to submit builds to Copr, etc., and may not even use a local chroot to assure than BuildRequires is right.

However, if most of the time, they can download a tarball for Python, download the SRPM for rh-python34 or rh-python34, and then run rpmbuild with different options, they would probably be OK, and I could break the back of that work so that they have some wikis and local knowledge to go from.

This is how I complied with security guidelines when I did a lot of rpm building, but generally it was slightly simpler packages than Python.    For instance, with Apache httpd, our customers network scanner would say, you are still running httpd X.Y.Z, and so I would pull the SRPM for httpd from Fedora 16 (going back a ways), take a look at the required libraries and versions on Fedora 16, and compare with CentOS 6, then I would copy the tarball and adjust version macros for our own custom version of httpd, make sure to include Conflicts with the system package, and so on.

So, I understand that SCLs aren't the only way to have other versions, but SCLs prevent conflicts.   It gives RedHat customers a step between tarball and rpm that may conflict.    That's what I'm looking for.

However, https://www.softwarecollections.org/en/docs/guide/#Creating_Your_Own_Software_Collections is somewhat imposing, even for me.   For our DevOps team, who normally deal with a little bash, a little ansible, and a lot of Jenkins, this is very imposing.

From: Brian Gollaher [mailto:bgollahe at redhat.com]
Sent: Thursday, June 29, 2017 12:52 PM
To: Davis, Daniel (NIH/NLM) [C] <daniel.davis at nih.gov>; sclorg at redhat.com
Subject: Re: [scl.org] Python "latest" SCLo

Yes, thanks Dan.  Many security scanning tools look for the latest version and flag older versions as being a potential risk.  I wanted to be sure that this is what is happening, rather than collections not receiving security updates fast enough and actually missing an important CVE.

On 06/29/2017 11:54 AM, Davis, Daniel (NIH/NLM) [C] wrote:
The DevOps team wants to update to the latest Python as a rule as a security from security mitigation technique.    I hope that makes sense.

From: Brian Gollaher [mailto:bgollahe at redhat.com]
Sent: Thursday, June 29, 2017 11:50 AM
To: Davis, Daniel (NIH/NLM) [C] <daniel.davis at nih.gov><mailto:daniel.davis at nih.gov>; sclorg at redhat.com<mailto:sclorg at redhat.com>
Subject: Re: [scl.org] Python "latest" SCLo

Hi Dan.  May I ask a question?  Is your security team looking for a fix to a specific security problem or CVE or are they asking that you run the latest version as a rule?

thanks,
Brian

On 06/29/2017 11:24 AM, Davis, Daniel (NIH/NLM) [C] wrote:
I've been lurking on this list for a while, and I wanted to bring myself up to date.   I noticed some talk of a community SCL for a "latest" Python, which would be a non-patched pure build of Python that is kept up-to-date by the community.   Where is that at?   Who is leading it?   How can I help?

For background, we've used rh-python34 for some time, but our security team recently dinged us for sticking with Python 3.4.2, and my DevOps team (who have less time due to tickets), just recompiled Python 3.4.6 blind to get past the security problem.   I would have argued we should move to rh-python35, but that would eventually suffer the same problem.   What we need is a distribution that keeps up to date, but is still distributed as an rpm.

Thanks,

Dan Davis, Systems/Applications Architect (Contractor),
Office of Computer and Communications Systems,
National Library of Medicine, NIH

_______________________________________________

SCLorg mailing list

SCLorg at redhat.com<mailto:SCLorg at redhat.com>

https://www.redhat.com/mailman/listinfo/sclorg

--

Brian Gollaher

Red Hat Platform Product Management

Phone: 978 392-3173

Cell: 508 740-6549

briang at redhat.com<mailto:briang at redhat.com>

--

Brian Gollaher

Red Hat Platform Product Management

Phone: 978 392-3173

Cell: 508 740-6549

briang at redhat.com<mailto:briang at redhat.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/sclorg/attachments/20170629/3f9642e0/attachment.htm>