Question is the goal of the factor output. From my point of view, only CVEs
not implemented in the system are relevant (i.e. for reporting). CVEs
already implemented are not really from interest to me. So if the standard
behavior is, only show facts with CVEs not implemented yet and show all
CVEs o
On 10/13/2014 09:23 PM, Trevor Vaughan wrote:
> Unfortunately, I very much share Felix's fear in getting swamped by
> facts. I mean, there are *thousands* of CVEs.
Yeah, but then...
> > Would it be possible to side-load this into PuppetDB?
...this made me think of blackjack. And hookers ;-)
But
Unfortunately, I very much share Felix's fear in getting swamped by facts.
I mean, there are *thousands* of CVEs.
Good goal though, I'll have to think about this.
Trevor
On Mon, Oct 13, 2014 at 12:41 PM, Garrett Honeycutt wrote:
> On 10/13/14 8:59 AM, Trevor Vaughan wrote:
> > Would it be poss
On 10/13/2014 06:36 PM, Garrett Honeycutt wrote:
> Hi Felix,
>
> I agree this should be configurable, though I'm not sure the best way to
> go about that. Facts do not take parameters, so I'm not sure what you
> mean by that.
>
> Best regards,
> -g
Good point. You *could* manage an external fact
On 10/13/14 8:59 AM, Trevor Vaughan wrote:
> Would it be possible to side-load this into PuppetDB?
>
> For instance, instead of running the full list of checks with every run
> of puppet, have a cron job (or something) that runs the list and feeds
> the data directly into PuppetDB for the node.
>
On 10/12/14 5:16 PM, Felix Frank wrote:
> On 10/11/2014 02:22 AM, Garrett Honeycutt wrote:
>> We could check if a file exists in a directory and if so, skip the fact.
>>
>> Suggest using /usr/local/etc/cve/
>>
>> What do you think?
>
> Sure, some thing in the file system.
>
> I suggest to not har
Would it be possible to side-load this into PuppetDB?
For instance, instead of running the full list of checks with every run of
puppet, have a cron job (or something) that runs the list and feeds the
data directly into PuppetDB for the node.
That would take the pressure off of each Puppet run bu
On 10/11/2014 02:22 AM, Garrett Honeycutt wrote:
> We could check if a file exists in a directory and if so, skip the fact.
>
> Suggest using /usr/local/etc/cve/
>
> What do you think?
Sure, some thing in the file system.
I suggest to not hard code locations. This should be a parameter.
Cheers,
On 10/10/14 8:07 PM, Jeremy T. Bouse wrote:
> Granted I haven't completed taking a good look at the code yet, but to
> address Felix's concerns. What about a method of caching successful (ie:
> non-vulnerable) CVE fact results for an administratively configured
> time? This could limit the nu
On 10/10/14 7:23 PM, Felix Frank wrote:
> Hi Garrett,
>
> cool idea. I think it could use a dial to explicitly whitelist the facts
> that I want to be populated. Deploying an ever growing range of
> (sometimes expensive) checks to all agents, all of which will forever
> return false after patching
Granted I haven't completed taking a good look at the code yet, but to
address Felix's concerns. What about a method of caching successful (ie:
non-vulnerable) CVE fact results for an administratively configured
time? This could limit the number of facts that have to run through
their logic
Hi Garrett,
cool idea. I think it could use a dial to explicitly whitelist the facts
that I want to be populated. Deploying an ever growing range of
(sometimes expensive) checks to all agents, all of which will forever
return false after patching, is not a merry perspective.
What do you think?
C
Hello,
Published puppet-module-cve[1] to act as a framework for adding facts
for specific CVE's that tell you if you are vulnerable to them.
Inspiration came after ShellShock where I saw people had written modules
with corresponding facts exclusively for that exploit. Our community
needs a simple
13 matches
Mail list logo
