My only concern is that sometimes a government customer will mandate using some flavor of RHEL 6, for whatever reason they may have. For example, we have a government customer mandating we use 6.5 at the moment. And they are perfectly happy to have us STIG the 6.5 OS manually, page by page, if there is no way to automate it.
William B. Boucher, BSEE Embedded Systems Software Engineer Information Systems Security Manager MZA Associates Corporation 4900 Lang Ave. NE, Suite 100 Albuquerque, NM 87109-9708 Phone: 505.245.9970 x166 Fax: 505.245.9971 Cell: 505.459.7620 william.bouc...@mza.com -----Original Message----- From: open-scap-list-boun...@redhat.com [mailto:open-scap-list-boun...@redhat.com] On Behalf Of Matej Týc Sent: Tuesday, February 26, 2019 9:12 AM To: open-scap-list@redhat.com Subject: [Open-scap] Phasing out the RHEL6 CI Dear community, the possibility to build the OpenSCAP "oscap" suite on RHEL6 using those dated utilities s.a. python2.6 is becoming a luxury. Sometimes, passing the CI for RHEL6 requires some weird workarounds that take time to design and implement and those workarounds just complicate the code, they don't bring benefits. As RHEL6 won't get any significant updates, the ability to compile recent versions of the scanner suite on RHEL6 seems irrelevant. Do you, our precious community around the project, have arguments why the RHEL6 should be part of the CI? If there are no agreed-upon reasons to do otherwise, we are leaning towards switching the RHEL6 CI off within two weeks, i.e. in the first half of March. On behalf of the Brno Security Compliance team, Matěj Týč _______________________________________________ Open-scap-list mailing list Open-scap-list@redhat.com https://www.redhat.com/mailman/listinfo/open-scap-list _______________________________________________ Open-scap-list mailing list Open-scap-list@redhat.com https://www.redhat.com/mailman/listinfo/open-scap-list
