If I'm understanding you correctly, I first have to clarify when I say SUSE I'm including all "derivative" products - and both matter. I don't see what's wrong with invoking change [open]SUSE core from the community side - it's the interface I'm used to doing change with and my favorite Linux. I've seen non-upstreamable patches applied in distro, too, when there's cause. So yes, I think it's a legitimate reason for incorporation of the module, and shouldn't be considered in a negative light. I am familiar with many SUSE press releases and that SUSE Enterprise meets FIPS certification, but past that I'm not sure, although I've come across manual STIGs/benchmarks for older SLES (which use pam_tally2) - but I feel there is something here being missed. Coming at it as a linux developer who's been in the contractor ecosystem for many years now, there is a clear imbalance of Linux choice. I've come across [Open]SUSE (including both) used in contracting environments only 1 time in my career - but CentOS/RHEL have heavily dominated by more than 100 instances vs that 1. I'd like to address that lack of choice which details like this pam module contribute to - people don't want to deviate from the known working pam configs, as they're not easy to grok. And given the NIST 800-53 controls, one of these modules objectively meets those criteria more than the other. Sticklers may require you use the better module, and probably what they already know. -Jason On Fri, Jun 3, 2016 at 12:22 PM, Thorsten Kukuk <kukuk@suse.de> wrote:
On Fri, Jun 03, Jason Newton wrote:
Further, even if you don't think this should be upstream... and playing devils advocate here, you may still have problems meeting approved security configurations with only pam_tally2 - this has an effect on the usage of any SUSE product in government owned systems.
Very intersting that you now arguments with the business of SUSE to get your wishes into openSUSE...
And no, we have no problems meeting approved security configurations for government owned systems, we have the needed certifications to sell even to the US government. As you could have easily found out by reading our press releases ;)
Thorsten
-- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org