16:01:03 <defionscode> #startmeeting Lockdown Working Group
16:01:03 <zodbot> Meeting started Thu Nov  1 16:01:03 2018 UTC.
16:01:03 <zodbot> This meeting is logged and archived in a public location.
16:01:03 <zodbot> The chair is defionscode. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:03 <zodbot> The meeting name has been set to 'lockdown_working_group'
16:01:11 <shepdelacreme> hello
16:01:34 <defionscode> Alright roll-call, who's here? Already got shepdelacreme and cyberpear checked.
16:02:03 <alikins_> howdy
16:02:15 * defionscode waves
16:02:32 <defionscode> ansible hardening folks will be a bit later
16:03:18 <defionscode> everyone have the agenda handy? I was thinking just to go down the list, but if someone has limited time and wants to hit something off the bat we can do that first
16:03:28 <defionscode> #link https://github.com/ansible/community/issues/388#issuecomment-435033692
16:04:30 <shepdelacreme> yup
16:04:49 <defionscode> alright lets start
16:05:09 <defionscode> #meetingtopic general project
16:05:32 <defionscode> cyberpear brought up making a policy for adding new repos to lockdown
16:06:21 <defionscode> so i think there are two paths
16:06:45 <cyberpear> It's easy enough to use the bench parse tool to generate the template for a given Stig
16:06:58 <defionscode> 1) repos which we 'endorsed/curated' and others which might be entirely driven outside our own policies/governance
16:07:00 <defionscode> cyberpear: I agree
16:07:19 <defionscode> #agreed use benchparse to init new role
16:07:28 <cyberpear> Do we need a category kind of like the kubernetes incubator?
16:07:48 <defionscode> not sure what the incubator is?
16:08:09 <cyberpear> It's basically the experimental stuff that's not production grade yet
16:08:51 <defionscode> just googled it's been superceded the idea is the same
16:08:54 <defionscode> #link https://github.com/kubernetes/community/blob/master/github-management/kubernetes-repositories.md#sig-repositories
16:09:09 <defionscode> #idea model after k8s subprojects
16:10:33 <defionscode> hmm any preference on the GH hosting org?
16:10:36 <shepdelacreme> Are we talking about the SIG repositories stuff and creating a new github org or something?
16:11:27 <defionscode> I suppose that's on the table?
16:11:31 <defionscode> so questions are
16:11:41 <shepdelacreme> What if we maintain a list of projects in the main lockdown repo with a status: Official, Incubating, etc
16:11:46 <defionscode> 1) how is a new repo requested added and 2) where does it live?
16:12:11 <defionscode> shepdelacreme I dont think we would have issues just having it live in the mindpointgroup org, or what do you think?
16:12:19 <shepdelacreme> those repos can sit in individuals GH accounts or we can host at the MPG org if they want?
16:12:48 <defionscode> I would prefer for us to have some level of control over it, to prevent funky settings or the repo being deleted outright
16:12:56 <shepdelacreme> To get in lockdown or whatever they have to accept the projects CoC, style guidelines, etc?
16:13:04 <shepdelacreme> ok
16:13:09 <shepdelacreme> IO
16:13:17 <shepdelacreme> I'm fine with that as well
16:13:21 <defionscode> i think that should be a given regardless of official/incubating
16:13:50 <defionscode> and the request can/should be made in the ansible-lockdown repo
16:14:02 <shepdelacreme> If we host them in the MPG org we can see about making the maintainers outside collaborators on those repos?
16:14:13 <defionscode> yeah exactly
16:14:46 <defionscode> the difference could be that 'incubating' repos would have no restrictions on direct merges/pushes to master by the maintainer
16:15:00 <defionscode> once it 'graduates' then changes/tags/etc would be restricted
16:16:04 <shepdelacreme> I'm fine with that...playing devils advocate though. Do you think some folks will have issue having those repos be within the MPG org?
16:16:32 <defionscode> so 1) requests happen as issues in lockdown root repo 2) repo is made in MPG org 3) 'incubating' repos let contributors make direct changes, wild-west style 4) once it's ready then it can be graduated and changes would follow governance
16:16:57 <defionscode> shepdelacreme: if they do then we can figure it out later? IOW it's not a real problem yet
16:17:04 <defionscode> cyberpear: what do you think?
16:17:11 <shepdelacreme> I'm good with that :thumbsup:
16:17:42 <cyberpear> Not sure how often people will want to add new repos, but it's easier to convince a company to contribute to an existing project...
16:17:56 <cyberpear> Than convince them to release their own thing
16:18:16 <defionscode> especially in this space
16:18:43 <defionscode> ok just to be explicit cyberpear shepdelacreme any objections? (also anyone else lurking can chime in)
16:19:28 <shepdelacreme> I'm good with this approach
16:19:55 <cyberpear> Sorry, I'm high latency today. Typing on a phone... it might be worthwhile to create an ansible lockdown GitHub organization and automatically create repos for every Stig, then move them into the mpg repo once they're stable
16:20:21 <cyberpear> But no objection to what's already been mentioned
16:20:45 <defionscode> oh that's not a bad idea
16:21:48 <defionscode> we probably will exclude certain stig benchmarks but i like the gist
16:21:50 <shepdelacreme> The only reason I'd be opposed to that is because it would be another thing to manage hehe
16:22:33 <defionscode> shepdelacreme: i think the additional overhead would be negligible, i already have a crawler that parses the DISA site for stigs, I can script out a generator
16:22:35 <shepdelacreme> also would the org just house incubating stig repos? The official AL repo would stay where it is in the Ansible org?
16:22:41 <defionscode> shepdelacreme: correct
16:22:57 <cyberpear> Yeah, it'd take a few hours to automate
16:22:57 <defionscode> we want to make sure folks understand it's a formal part of the upstream Ansible community
16:23:04 <shepdelacreme> Oh I mean the overhead of managing another GH org
16:23:38 <defionscode> shepdelacreme: even that shouldnt be tough, it wont have private repos, or billing, or anything, just the three of us and whoever else jumps on board as a maintainer later
16:23:48 <shepdelacreme> But I'm generally fine with it
16:24:27 <defionscode> ok let me mark this up
16:24:32 <shepdelacreme> ansible-lockdown-incubating
16:24:34 <shepdelacreme> ?
16:24:47 <defionscode> #agreed create ansible-lockdown org to house incubating roles
16:24:55 <defionscode> we can probl just call the org ansible-lockdown
16:24:57 <defionscode> dont see why not
16:25:28 <shepdelacreme> confusion about what is housed in the Ansible org, the MPG org, and the ansible-lockdown org?
16:25:44 <shepdelacreme> I will defer to you two though
16:26:05 <defionscode> ansible org repo is for global issues, housing submodules, github project stuff
16:26:27 <defionscode> mpg org for 'official/endorsed/ready-for-primetime' roles
16:26:37 <defionscode> ansible-lockdown for beta/incubating roles
16:26:40 <defionscode> thats how I grok it
16:27:47 <defionscode> #action defionscode to make org and role scaffolding for stigs
16:27:48 <cyberpear_> In the long run, I'd anticipate minimal resistance to having "supported" roles in a 'ansible-lockdown' org
16:28:01 <cyberpear_> vs "who is MindPointGroup"...
16:28:03 <shepdelacreme> right...I mean confusion having an "ansible-lockdown" org that doesn't house the official ansible-lockdown repo? Do you think people that search for ansible-lockdown and hit the org are going to ask...why isn't the ansible-lockdown repo housed here/etc
16:28:31 <defionscode> hmm
16:28:39 <cyberpear_> perhaps ansible-lockdown for stable and ansible-lockdown-incubator for unstable?
16:28:56 <cyberpear_> with as-is git submodules from the official ansible org
16:29:15 <cyberpear_> (I'm guessing that ansible doesn't want 200 repos in their org directly...)
16:29:33 <shepdelacreme> I'd prefer not to move the official roles out of the MPG repo
16:29:39 <defionscode> cyberpear_: yeah probably not, esp since lockdown is already a unique repo in that it's a repo that subs to other repos
16:30:14 <cyberpear> no strong opinion here
16:30:23 <cyberpear> MPG has done most of the work
16:30:29 <defionscode> ok so middle ground, just an ansible-lockdown-incubator org then?
16:30:41 <cyberpear> sounds good to me
16:30:53 <defionscode> ok
16:31:00 <defionscode> shepdelacreme that good with you?
16:31:07 <shepdelacreme> yup
16:31:49 <defionscode> #agreed create ansible-lockdown-incubator org for things not-yet-endorsed by lockdown maintainers as 'ready'
16:32:08 <defionscode> ok done
16:32:23 <defionscode> next item
16:32:28 <defionscode> ansible version support
16:33:19 <defionscode> I think Im inclined to say current and previous dot release and only current major release?
16:33:59 <defionscode> but...the modules issue is a tricky one
16:34:10 <defionscode> ie pamd is gonna work differently even between dot releases
16:34:11 <cyberpear> At a minimum, I'd expect that.
16:34:31 <defionscode> but as a stop gap we could 'host' the upstream pamd module relative to the role
16:34:35 <cyberpear> We could ship fixed modules with our repo to continue supporting older releases...
16:34:38 <defionscode> right
16:34:55 <shepdelacreme> yeah...that might be the only "good" way to do it
16:35:22 <cyberpear> or create a dependent role that has those fixed items so they don't need to be duplicated
16:35:29 <shepdelacreme> How do we bring in new changes from the upstream official module though?
16:35:49 <cyberpear> it would be an extra thing to track.
16:35:49 <defionscode> shepdelacreme: you can just have a library/ dir in the role
16:36:10 <cyberpear> also, we'd have to have an upstream-first policy: don't fix issues in our copy of the module w/o fixing it in upstream ansible first
16:36:23 <defionscode> easy to agree with that
16:37:04 <defionscode> cyberpear: i like the dependent role thing at face value but I think that'd be tricky b/c 1) you'd need to use galaxy and 2) would be pointless for people on latest or devel
16:37:40 <defionscode> I dont think that galaxy automatically pulls in deps at the moment, but i could be wrong, I just know they're in the middle of a big re-write
16:38:29 <cyberpear> perhaps a better question for #ansible or #ansible-devel, but is it possible to have 'ansible-galaxy install' pull in a role without having that role explicitly run when the depending role is run?
16:38:37 <defionscode> I _think_ we could do something really hacky where we get_url the latest <insert buggy module> here via the github raw link and then still use it in a subsequent task
16:38:39 <cyberpear> yes, it does if it's listed as a dependency in meta/main.yml
16:39:07 <defionscode> cyberpear: ah ok
16:39:39 <shepdelacreme> what about making the library dir a submodule pointing at another repo that houses "fixed" modules
16:40:04 <odyssey4me> o/ apologies for being late
16:40:06 <defionscode> shepdelacreme: that's not a bad idea
16:40:06 <cyberpear> that could work, then only clone w/ submodules when on an older ansible
16:40:09 <shepdelacreme> that way it can be used across all the different repos without having to keep them all in sync
16:40:11 <defionscode> odyssey4me: n oworries
16:40:18 <defionscode> yeah that wfm
16:40:44 <defionscode> ok so submodule at /library inside roles that point to fixed modules, any objections there?
16:40:44 <cyberpear> does the git-1.8 in rhel 7 support submodules?
16:40:49 <cyberpear> not from me
16:41:02 <cyberpear> (I always use the rhscl version, currently rh-git29)
16:41:18 <cyberpear> +1 to /library submodule
16:42:00 <defionscode> cyberpear: do you know how galaxy interacts with submodules when publishing?
16:42:00 <shepdelacreme> Submodule support has been available in Git since version 1.5.3.
16:42:02 <defionscode> I've never tried
16:42:11 <cyberpear> no experience w/ galaxy and submodules
16:42:15 <cyberpear> nor galaxy pushing
16:42:20 <shepdelacreme> https://git.wiki.kernel.org/index.php/GitSubmoduleTutorial
16:42:27 <cyberpear> always use galaxy w/ git repos internally
16:42:42 <defionscode> lets try that path and if it doesnt work well with galaxy we can revisit, any objections?
16:42:57 <shepdelacreme> none from me
16:43:43 <defionscode> #agreed create a submodule at /library to house patched modules in order to support older ansible releases
16:44:12 <defionscode> ok so odyssey4me is here and I want to respect his time so lets talk merger stuff now for a bit, cool?
16:44:44 <defionscode> #topic merger with ansible hardening
16:45:26 <defionscode> odyssey4me: what do we gotta do to be able to start leveraging the openstack infra for testing?
16:45:33 <odyssey4me> TBH I've not had much time to look into any of the action items from last week. I'm not sure if any others have managed to.
16:46:11 <defionscode> ok i'll table the follow-up agenda items then
16:46:41 <odyssey4me> defionscode That's a good question. Let me make a note to follow up on that - where do the meeting logs go so that I can have them handy for that discussion.
16:47:36 <defionscode> odyssey4me: at the end of the meeting zodbot will show the url but they are all available here https://meetbot.fedoraproject.org/sresults/?group_id=ansible-lockdown&type=channel
16:48:12 <cyberpear> https://meetbot.fedoraproject.org/ansible-lockdown/2018-10-17/hardening-lockdown_merger_first_steps.2018-10-17-14.04.html
16:48:20 <defionscode> #action odyssey4me to follow up internally regarding ansible lockdown's use of openstack infra
16:48:41 <defionscode> cyberpear: that was the first meeting though
16:48:53 <odyssey4me> ok, got them - thanks, and apologies for not already following that up - it's been a rough week
16:49:02 <odyssey4me> https://meetbot.fedoraproject.org/ansible-lockdown/2018-10-17/hardening-lockdown_merger_first_steps.2018-10-17-14.04.html
16:49:16 <odyssey4me> lol, same link
16:49:16 <defionscode> odyssey4me: shit happens, we'll all be alright ;)
16:49:19 <odyssey4me> <--- nitwit
16:50:15 <defionscode> odyssey4me next q, have you any clue what we need to do to get a green light on adding rackspace branding to lockdown stuff?
16:50:24 <defionscode> if it's not desired/wanted that's fine with me too
16:50:26 <odyssey4me> given cloudnull and mnaser aren't around, I guess all the action items will have to carry forward
16:50:32 <defionscode> yep totally
16:51:04 <mnaser> I’m semihere
16:51:22 <defionscode> haha
16:51:28 <mnaser> I defer to odyssey4me though for any decision!  Dunno about branding stuff tho
16:51:36 <odyssey4me> on rackspace branding - I'll have to follow up on whether that's desired and what the terms would be...
16:52:08 <odyssey4me> mnaser can make decisions about vexxhost branding though :p
16:52:17 <defionscode> ok, thats entirely your call, it could just be openstack branding or nothing at all, it's really up to you folks
16:52:50 <mnaser> I think as an open source project it’d be better to leave brands out of it. But I don’t mind having us there
16:53:32 <cyberpear> +1
16:53:40 <defionscode> there is a formal partnership with MPG and RedHat (IBM now I guess) around this project hence some branding on the landing page, it's not an exclusive club though
16:54:06 <defionscode> but alright, just lemme know if the desire changes or starts leaning one way or another
16:54:17 <odyssey4me> Cool, will do.
16:54:48 <odyssey4me> #action odyssey4me to find out whether Rackspace wishes to add branding, and what the terms are if they do.
16:55:30 <defionscode> mnaser: odyssey4me regarding Ubuntu, right now AH has content work with Debian based distros and I think this was made prior to there being an Ubuntu STIG Benchmark, any object to having Ubuntu hardening exists as a function of that role? versus having rhel7 stig content be usable against ubuntu?
16:56:02 <defionscode> last meeting it seemed that odyssey4me and cloudnull were delegating that decision to mnaser hence the question now
16:58:02 <defionscode> also more of a non-committal question, odyssey4me cloudnull mnaser (and anyone else) would you like to be listed as active members in the Lockdown working group?
16:58:21 <defionscode> doesnt bind you to anything other than the occassional person seeing that you're active in this circle
16:58:36 <odyssey4me> I'm happy to be listed - I doubt cloudnull will have an issue with it either.
16:59:25 <defionscode> #action defionscode to add odyssey4me and cloudnull to active members list on the community page
16:59:43 <defionscode> mnaser is probably tied up so we can defer the ubuntu question until next time too
17:00:16 <defionscode> shepdelacreme: cyberpear odyssey4me mnaser (or others) have anything to add regarding merger talks?
17:00:37 <defionscode> shepdelacreme: is already doing some proof of concept work using the ansible-hardening docs builder on ansible-lockdown stuff
17:01:49 * cyberpear has nothing at the moment
17:03:09 <defionscode> ok, it's the top of the hour, cyberpear & shepdelacreme are you able to continue on or shall we push remaining agenda stuff to next week?
17:03:18 <defionscode> im fine either way
17:03:31 <cyberpear> I'm still here
17:03:43 <shepdelacreme> I can keep going for 30 min
17:03:53 <defionscode> ok lets proceed then
17:04:12 <defionscode> #topic how to best address manual and not remediated tasks
17:04:47 <defionscode> my idea is to have a callback plugin that just outputs the rule data (maybe name + rule id) at the end of a playbook run
17:05:09 <defionscode> but that could be not-desired if teh content is being used as part of a larger playbook with several other roles
17:06:02 <cyberpear> do role-included callback plugins run by default?
17:06:15 <defionscode> cyberpear: I think you'd still need to whitelist it
17:06:25 <shepdelacreme> I could see it being useful to aggregate the results of those things at the end instead of mixed in the output as it is now
17:06:26 * cyberpear thought so, but wasn't sure
17:07:01 <defionscode> tbh i havent written a callback plugin a while so maybe the behavior changed, if it's whitelisted then I suppose users are able to dictate if it's enabled or not
17:08:02 <defionscode> should it be sufficient to output "$RULE_ID $SEVERITY $RULE_TITLE"?
17:08:03 <cyberpear> what would be really awesome is a results-xccdf.xml that could be imported to STIG viewer
17:08:08 <odyssey4me> I remember that we wanted to do something similar in AH, but never figured out a good way.
17:08:42 <odyssey4me> I think we thought it better to have the results recorded in a file which could then be imported into some sort of tool.
17:09:12 <defionscode> cyberpear: you up to make that? Im not against it, but I really dont wanna mess with XML more than i have to
17:09:31 <defionscode> odyssey4me: yeah that's what cyberpear is alluding to
17:09:47 <defionscode> im personally not an xccdf schema expert but im not opposed to the idea
17:09:50 <odyssey4me> It may be nice to use a callback to drop it into a sqlite DB or an xml file.
17:10:02 <cyberpear> Put it on the "wish list"... unlikely I'll be able to allocate time to it in the next few months.
17:10:30 <defionscode> #idea generate xccdf xml report that can be ingested into DISA's STIG viewer
17:11:22 <defionscode> ok so short term we can do the callback route with plain text output on stdout? Then we can iterate from there?
17:11:52 <defionscode> odyssey4me: i like the sqlite idea though i wouldnt want it to bork the run on account of someone not having sqlite locally
17:12:14 <defionscode> especially ansible tower users
17:13:42 <defionscode> shepdelacreme: cyberpear odyssey4me any objections to just having a stdout report for now via callback?
17:13:51 <shepdelacreme> nope
17:14:00 <odyssey4me> nope, that's what AH does now actually IIRC
17:14:19 <defionscode> odyssey4me: oh? so there is a callback plugin in your repo? i didnt notice it
17:15:33 <defionscode> #agreed callback plugin to output manual/nonremediated benchmark rules
17:15:46 <odyssey4me> oh, it got removed https://github.com/openstack/openstack-ansible-plugins/commit/bfc26ac6983bc97201403be36f6d564a3ab7031d
17:16:00 <defionscode> #action defionscode to make mvp of callback plugin for manual/nonremediated rules
17:16:24 <odyssey4me> it was a simple thing which wasn't great anyway, you can do something similar with built-in plugins these days
17:16:29 <defionscode> odyssey4me: ok cool
17:16:47 <defionscode> alright this topic is done i think
17:16:54 <defionscode> #topic Style Guidelines
17:17:10 <defionscode> a simple one
17:17:34 <defionscode> line length, shoudl we have a line length limit? I vote no, for this type of project I think it would make things less readable to enfroce a length limit just cuz
17:18:11 <shepdelacreme> I vote no...I dislike arbitrarily short line length limits in general
17:18:27 <cyberpear> I'm generally in favor of limited line lengths
17:18:45 <cyberpear> but it'd be hard to implement for benchparse
17:18:49 <cyberpear> so I'm fine leaving as-is
17:18:56 <odyssey4me> apologies - I need to run, something just broke that needs my full attention
17:19:08 * cyberpear 's commits will generally be limited in line-length regardless
17:19:09 <defionscode> odyssey4me: no worries, thanks for making the time
17:19:26 <defionscode> cyberpear: yeah I dont think we should refuse them in a dogmatic way
17:19:32 <defionscode> but simply not enforce/require it either
17:19:44 <cyberpear> +1
17:20:05 <defionscode> #agreed no line limit lenght, but allow for changes/commits that do line breaks/continuation
17:20:14 <cyberpear> ansible upstream also ignores the line-length limit item from pep8
17:20:29 <defionscode> ok, this one i think we all agree on already
17:20:44 <defionscode> removing severity, audit, and patch tags
17:20:55 <defionscode> severity tags go to the include level in main.yml
17:21:03 <defionscode> and audit/patch tags go away completely
17:21:03 <cyberpear> +1
17:21:20 <cyberpear> audit/patch is handled at '--check' and ansible_check_mode
17:21:25 <defionscode> yep
17:21:37 <defionscode> shepdelacreme, you're on board?
17:21:37 <shepdelacreme> +1
17:21:40 <defionscode> ok
17:22:09 <defionscode> #agreed removing severity, audit, and patch tags severity tags go to the include level in main.yml and audit/patch tags go away completely
17:22:41 <defionscode> remove audit playbook? i think it's safe to do at this point
17:22:48 <defionscode> so +1 from me
17:23:18 <shepdelacreme> What audit playbook?
17:23:42 <cyberpear> in the rhel7-stig role, there's audit-cat1.yml and fix-cat1.yml
17:23:45 <shepdelacreme> I mean yes I agree the audit playbooks should go away but I thought they were removed
17:23:57 <defionscode> oh ha i must have been looking at an old commit hash
17:24:05 <defionscode> cyberpear: not anymore
17:24:13 * defionscode is not sure how he missed htat
17:24:16 <shepdelacreme> cyberpear I don't see that in devel
17:24:22 <cyberpear> k, at some point, would be nice to rename fix-cat1.yml to cat1.yml
17:24:33 <defionscode> yeah i think we can do that now
17:24:34 <cyberpear> to be consistent across roles
17:24:41 <defionscode> it would be a non breaking change
17:24:44 <shepdelacreme> ahh looks like RHEL6-STIG still needs work
17:24:51 <shepdelacreme> to remove the audit playbooks
17:25:00 <defionscode> #agreed rename fix-cat* to cat*.yml
17:25:16 <defionscode> maybe thats what i was looking at
17:25:26 <shepdelacreme> agree with the rename
17:25:32 <defionscode> next thing
17:25:59 <defionscode> ensuring blocks have names, even though it has no output utility at the moment it's still a +1 for dev-exp purposes
17:27:12 <shepdelacreme> I agree with that...however what is the policy for naming tasks under the block
17:27:31 <cyberpear> +1 names on blocks, even though they are not printed at runtime (yet)
17:27:42 <defionscode> i think that should stay the same shepdelacreme
17:28:11 <cyberpear> I've generally been keeping the task name the same as the stig title, except when it's a complicated block, then I explain what's going on
17:28:23 <shepdelacreme> right
17:28:59 <defionscode> #agreed blocks should be named, and should follow convention unless it's complex and further details are warranted
17:29:00 <shepdelacreme> The block name should be the official STIG title or whatever...tasks underneath can have a different title that explains the action a little better I think
17:29:12 <defionscode> shepdelacreme: the problem is output
17:29:47 <defionscode> lets go into details next week on block specifics, for now we agree it should be used
17:29:59 <defionscode> it's 30 after now so you have to go, right?
17:30:00 <shepdelacreme> yeah no I am agreeing with you and cyberpear :)
17:30:10 <defionscode> kk
17:30:23 <shepdelacreme> Lets finish up these style guidelines
17:30:30 <defionscode> ok
17:30:34 <shepdelacreme> then I need to leave
17:30:58 <defionscode> 'yes/no' to actual boolean values? I think i was hitting yamllint issues with yes/no values
17:31:05 <defionscode> what do you guys think
17:31:22 <defionscode> would be easy to sed for it i think
17:31:34 <shepdelacreme> I'm good with moving to true/false
17:32:37 <cyberpear> I'm partial to yes/no
17:32:46 <cyberpear> they are native booleans in yaml
17:33:02 <cyberpear> and more English-like
17:33:34 <cyberpear> I don't think we have "yes" and "no" (strings) anywhere
17:34:01 <cyberpear> on my .yamllint, I have
17:34:02 <cyberpear> truthy: disable
17:34:04 <shepdelacreme> a lot the "changed_when" stuff uses yes/no
17:34:24 <cyberpear> not sure if that made it to the .yamllint in rhel7-stig
17:34:47 <shepdelacreme> yeah truthy: disable is in there
17:35:58 <defionscode> hm ok we should be consistent in any case
17:36:09 <cyberpear> +1 for consistency
17:36:11 <defionscode> we can just as easily convert 'true' => yes
17:36:23 <defionscode> and 'false' => no
17:36:27 <cyberpear> +1
17:36:36 <defionscode> i'll concede
17:36:37 <shepdelacreme> agreed
17:36:53 <defionscode> #agreed standardize on yes/no for BOOL
17:37:00 <shepdelacreme> however :)
17:37:06 <defionscode> :O
17:37:18 <shepdelacreme> this is just for something like "changed_when: no" right?
17:37:39 <defionscode> and for rhel7stig_RULEID: yes/no
17:37:56 <shepdelacreme> and not "changed_when: somevar == false"
17:38:08 <shepdelacreme> obviously that syntax is garbage but hope you get the gist
17:38:24 <defionscode> correct, at that point it's more python than yaml
17:38:36 <shepdelacreme> ok I'm good with yes/no then
17:38:46 <defionscode> ok
17:38:49 <defionscode> next style item
17:38:57 <defionscode> move "myvar | failed
17:39:00 <defionscode> syntax
17:39:01 <cyberpear> yes, once you get more complicated, you are in python land
17:39:07 <defionscode> to myvar is failed
17:39:12 <cyberpear> +1
17:39:13 <shepdelacreme> +1
17:39:17 <defionscode> ok
17:39:31 <cyberpear> it can be done in a way that maintains compat w/ ansible-2.4
17:39:42 <defionscode> #agreed move away from "myvar|failed" to "myvar is failed"
17:39:43 <cyberpear> 99% of  the time it "just works" w/ 2.4
17:40:01 <defionscode> cyberpear: is there a trick for the 1%?
17:40:16 <cyberpear> the only caveat is "myver is version('>=', '2.4')"
17:40:27 <cyberpear> "myver is version_compare('>=', '2.4')"
17:40:33 <cyberpear> ^use the latter
17:40:48 <cyberpear> it exists in 2.4, the former doesn't
17:41:11 <cyberpear> that's the only one I've run into where the autoconverter doesn't do it optimally
17:41:39 <cyberpear> don't remember how much we use that, though
17:41:47 <defionscode> ok well that's 3 dot release ago so I dont know that i'd add those changes as a 'guarantee' but I wouldnt refuse contribs/changes that allow for 2.4 support just not 'promised'
17:41:55 <cyberpear> +1
17:42:07 <defionscode> kk
17:42:10 <defionscode> last item
17:42:43 <defionscode> i have a soon-to-be PR'd to upstream module that can parse oscap results.xml and expose the important data as facts
17:42:47 <defionscode> it's a facts module
17:43:08 <defionscode> should we start making CI check for pass % on oscap eval?
17:43:26 <defionscode> it can be done at the severity or at the global score level
17:43:38 <defionscode> or both
17:44:15 <shepdelacreme> hmm
17:44:41 <shepdelacreme> how would that work for in progress roles? The builds would be failing until they hit a score level?
17:46:25 <defionscode> shepdelacreme: it can be tuned
17:46:33 <defionscode> initially the pass criteria can be 0
17:46:42 <defionscode> and adjusted as it makes sense to
17:47:19 <shepdelacreme> ok
17:47:40 <defionscode> cyberpear any opinions?
17:47:44 <cyberpear> sounds great to me
17:47:56 <defionscode> ok
17:48:08 <cyberpear> oscap can process DISA content, as well
17:48:21 <cyberpear> *DISA benchmarks, rather
17:48:31 <defionscode> #agreed once accepted into the upstream, use the scap_facts module to trigger failures in CI for roles
17:49:01 <defionscode> cyberpear: the problem, AFAICT, is that sans a tailoring file, you cant have it fail conditionally
17:49:10 <defionscode> i think it does a non zero rc if any check fails
17:49:57 <shepdelacreme> ok I gotta jump
17:50:04 <shepdelacreme> ttyl
17:50:32 <defionscode> my module exposes a "scap_facts: min_high_score=100 min_medium_score=50"
17:50:35 <defionscode> type of interface
17:51:10 <defionscode> cyberpear: i added you to the repo so you can see the WIP
17:51:20 <defionscode> it's functional now, just want to make sure I addressed any kinks
17:51:20 <cyberpear> k, I'll look when I get a chance
17:51:52 <defionscode> cyberpear: anything else you want to go over before we wrap up?
17:52:03 <cyberpear> close it out!
17:52:14 <defionscode> alikins_: you're here no? anything from you?
17:52:42 <defionscode> going once...
17:53:00 <defionscode> alright, thats a wrap
17:53:02 <defionscode> #endmeeting