On 7 February 2017 at 17:07, Mariano Lopez <mariano.lopez@linux.intel.com>
wrote:

> On 06/02/17 09:17, Jussi Kukkonen wrote:
>
>
>
> On 6 February 2017 at 16:56, Burton, Ross <ross.burton@intel.com> wrote:
>
>>
>> On 6 February 2017 at 14:43, Sona Sarmadi <sona.sarmadi@enea.com> wrote:
>>
>>>     bbdebug 2 "Updating cve-check-tool database located in $cve_dir"
>>>     if cve-check-update -d "$cve_dir" ; then
>>>         printf "CVE database was updated on %s UTC\n\n" "$(LANG=C date
>>> --utc +'%F %T')" > "$cve_file"
>>>     else
>>>         bbwarn "Error in executing cve-check-update"
>>> <<<<<<<<<<<<<<<<<<<<<<<<<
>>>
>>
>> This definitely needs to be rewritten so you can see the output if it
>> fails.  Just run cve-check-update -d <dir> yourself and see what it says.
>> Last time I had this failing it was because the mitre servers were offline.
>>
>
> Agreed about the error output.
>
>
> Also you need to patch the tool, most of the time there is no output from
> it; I think Ikey would integrate those patches without hesitation.
>

I don't know... the branch we're using is called 'legacy-tool' and is quite
different from master (which isn't usable).


> I think recipe specific sysroots broke the setup somehow (so the tools are
> not actually in sysroot when they're needed). I'm taking a look at this
> tomorrow.
>
>
> I tried today, but I'm having a hard time with the proxies (like always)
> so I can't really verify this. Were you able to check?
>

Yes, the problem is indeed that cve-check-update is not found when
do_populate_cve_db() is run. In addition to that curl-native is currently
broken by recipe-specific sysroots as well (CA certificates are looked for
in the wrong place) and this makes all downloads in cve-check-tool fail.

TL;DR: working on it.

Jussi