cve-bin-tool/community

peb

@peb-peb

Hello mentors! Thank you all for providing me with this wonderful opportunity to work with cve-bin-tool.

I had few doubts and wanted some suggestions -

is the title for the project fine as it is or should be changed to something different?
should there be any changes made in the weekly timelines?
regarding meetings and communication
I'm currently developing in wsl(windows subsystem for linux) on windows 10 in VScode, should I change my development environment?

During this community bonding period, I'm still learning and practicing the various things that would helpful for the project, like webscrapping and CLI and finding & listing various checkers that would be added during the coding period.

keesj-exset

@keesj-exset

anthonyharrison

@anthonyharrison

Hello @peb-peb . I think your project title is fine - I am particularly interested in seeing how you may find a 'fixed/safe' version for each vulnerability as there maybe some choices that I think we may need to consider (e.g. operating the cve-bin-tool in an 'offline' i.e. not connected to the internet). Regarding your timescales, they look OK and seem to have some time to address unforseen issues. I don't know how well WSL works (I have never used it for anything serious!) for cve-bin-tool development but it shouldn't be an issue; VSCode should be OK as a dev environment provided it is setup correctly. If you need any help or guidance reach out to me or one of the other mentors.

peb

@peb-peb

@anthonyharrison Thank you for answering my doubts! As for the finding the 'safe' versions for each vulnerability, I thought of web-scrapping it from the CVE Details. I am still figuring things out and learning stuff. I'll keep it in mind that 'cve-bin-tool could be operating offline' and figure out what are the possible solutions (I think caching the scrapped data could be a possible solution...).

Terri Oda

@terriko

Pycon talks are up here, for anyone who wants to do some listening: https://www.youtube.com/channel/UCMjMBMGt0WJQLeluw6qNJuA

My talk this year is about knitting so it's not a must-watch for cve-bin-tool developers :)

Terri Oda

@terriko

I'm back at work today! It's going to take me a few days to settle into a routine but I'll probably have some specific dedicated time for reviewing pull requests on my schedule once I figure out when that should be.

Terri Oda

@terriko

I'm reviewing and closing out some old pull requests today. If anyone's got time, I'd like a second opinion on intel/cve-bin-tool#1088 -- it looks fine to me and likely wasn't merged because CI was having (unrelated) trouble, but it's a couple of months old so I wanted to make sure it wasn't solving something we'd already solved.

Terri Oda

@terriko

(That's @imsahil007 's PR)

Hey all, I accidentally let intel/cve-bin-tool#1091 (the pull request to fix the rate limiting for nvd) go stale while I was waiting for licensing approval (we got it). A bunch has changed with nvd since we did it. Before I update the code to merge it I thought I'd ask: do we still want it as it is?

Terri Oda

@terriko

Okay, pull requests are triaged. I closed some old ones, merged some smaller stuff, and I think what's left we'll discuss tomorrow in the gsoc meeting.

I'm not sure what to do with intel/cve-bin-tool#1141 (docker setup instructions for cve-bin-tool) -- it's not merged because I don't want to maintain it, but I'm guessing we don't want to leave it open forever either. Anyone got an idea of what a good resolution would look like? Put the instructions in the issue and leave it as a 'use at your own risk" kind of deal?

Terri Oda

@terriko

Or just close both as "Terri doesn't have the resources to maintain and support this at this time" ?

I'm reviewing and closing out some old pull requests today. If anyone's got time, I'd like a second opinion on intel/cve-bin-tool#1088 -- it looks fine to me and likely wasn't merged because CI was having (unrelated) trouble, but it's a couple of months old so I wanted to make sure it wasn't solving something we'd already solved.

Edit: @pdxjohnny reviewed and merged for me, thanks!

Terri Oda

@terriko

Of potential interest: I set up a PR for Github's CodeQL workflow. I haven't decided if it's going to be useful for us long-term (since we currently scan using other tools) but if you want to see what it finds, it's running now: intel/cve-bin-tool#1179

anthonyharrison

@anthonyharrison

I'm not sure what to do with intel/cve-bin-tool#1141 (docker setup instructions for cve-bin-tool) -- it's not merged because I don't want to maintain it, but I'm guessing we don't want to leave it open forever either. Anyone got an idea of what a good resolution would look like? Put the instructions in the issue and leave it as a 'use at your own risk" kind of deal?

@terriko I think a 'use at your own risk' (or this may be useful to the community but no warranty etc...) would be OK.

Sahil

@imsahil007

@anthonyharrison If we were to add the docker guide along with a warning, do we need a docker-compose guide along with it as well? It will be mostly empty but it is quite helpful if the user wants to scan a single directory path multiple times.

Terri Oda

@terriko

@anthonyharrison unfortunately, "use at your own risk" isn't enough to let you out of any of our security requirements with current policy. Lucky Intel, someone from Lenovo abused a "use at your own risk" sample code and then they phoned our CEO at the time to complain, so policy is explicitly "we don't care what warning you put on it" now

Terri Oda

@terriko

Hm... @imsahil007 could probably put it in a blog post. I don't think anyone's going to hold Intel responsible for a student gsoc blog post if it goes stale and hasn't been run through docker bench security and all the other tools.

Terri Oda

@terriko

@SinghHrmn hey, can you see the codeql results? https://github.com/intel/cve-bin-tool/security/code-scanning/13?query=ref%3Arefs%2Fpull%2F1179%2Fmerge -- They're mostly related to html stuff and might be of interest. I expect some are false positives due to the templating but maybe not all of them?

(You don't need to fix them but I thought you might be interested if you can see them.)

peb

@peb-peb

Mentors, I have made a pr regarding the extraction and regex finding process #1182 . Please review and give your suggestions over it.

Bread Genie

@BreadGenie

I think we can merge intel/cve-bin-tool#1163 now and work on CSV and JSON (it leaves an empty file in this PR with --report flag) later and discuss on how to approach it in intel/cve-bin-tool#1148

Terri Oda

@terriko

@BreadGenie We've got an Intel user who wants us to do a release with intel/cve-bin-tool#1063 , so they'll be really happy to hear that it's ready.

Actually, let's put that out to @/all : any objections to doing a point release from master sometime soonish? (basically after intel/cve-bin-tool#1091 and intel/cve-bin-tool#1063 are merged, I think)

I need to do some checking to see if we've got too much else half-completed or any open bugs that desperately need fixing, and of course I've got to run it through a bunch of Intel processes, but I think there's enough small fixes and features that it warrants a point release (and not another backported one)

peb

@peb-peb

@terriko I was about to go to bed, but saw your ping ;)
intel/cve-bin-tool#1063 is almost ready. The things remaining are-
1) the output for the helper script (I was thinking of discussing it in the meeting in detail)
2) to write tests
3) to write docs
4) Today, I tested it on some files. It seems to working fine against small .rpm packages like logrotate #1184, but it is comparatively slower for larger .rpm packages (also, the strings result is a mess and would require some new regex searching for these types of files).
5) also, apparently it does not return any strings for .tar.gz files (my guess would be that this is not able to identify any executable.

Terri Oda

@terriko

@peb-peb It's going to take me at least until the end of this week to get #1091 in a place where it can be merged, and more time thereafter to start our licensing checks and code scans, so we've got some time!

That's weird about the .tar.gz files. I don't have time to look at it right now but yeah, might be an extractor issue.

peb

@peb-peb

@peb-peb It's going to take me at least until the end of this week to get #1091 in a place where it can be merged, and more time thereafter to start our licensing checks and code scans, so we've got some time!

That's great (but just for me T-T). I better get things moving quickly :)

That's weird about the .tar.gz files. I don't have time to look at it right now but yeah, might be an extractor issue.

I am able to extract these correctly, but no files are found to be scanned. I would be looking into this in detail tomorrow. I would be informing, if I encounter any problems...

Bread Genie

@BreadGenie

@BreadGenie We've got an Intel user who wants us to do a release with intel/cve-bin-tool#1063 , so they'll be really happy to hear that it's ready.

I've asked some doubts on intel/cve-bin-tool#1163 CSV and JSON files at https://github.com/intel/cve-bin-tool/issues/1148#issuecomment-849646777

I said it could be merged now and could be worked on a seperate PR because the PR would keep on accumulating conflicts and probably would if I change the JSON schema (for merge report)

or maybe did you mistook intel/cve-bin-tool#1163 with intel/cve-bin-tool#1063 ?

Terri Oda

@terriko

Yes, sorry, typo. I meant 1163

Terri Oda

@terriko

@peb-peb what's in the .tar.gz file? Often when people try those, they turn out to be source files (i.e. there is no compiled code in them, only uncompiled code and makefiles and stuff) so then yeah, it's not going to find anything.

peb

@peb-peb

@peb-peb what's in the .tar.gz file? Often when people try those, they turn out to be source files (i.e. there is no compiled code in them, only uncompiled code and makefiles and stuff) so then yeah, it's not going to find anything.

Oh, so that's why it wasn't showing up anything. I would be adding this note if these types of files are given as input.

peb

@peb-peb

(venv39_CVE_Binary_tool) peb@LAPTOP-M375SCBF:/mnt/c/Users/harsh/Downloads/binary packages/bugs$ cve-bin-tool -x
avahi-0.8-r1.apk                     avahi-daemon_0.8-5ubuntu3_arm64.deb  bash_5.0-4_aarch64_cortex-a72.ipk
(venv39_CVE_Binary_tool) peb@LAPTOP-M375SCBF:/mnt/c/Users/harsh/Downloads/binary packages/bugs$ cve-bin-tool -x avahi-0.8-r1.apk
[22:08:54] INFO     cve_bin_tool.CVEDB - Using cached CVE data (<24h old). Use -u now to update immediately.    cvedb.py:255
           INFO     cve_bin_tool.CVEDB - There are 165282 CVE entries in the database                           cvedb.py:279
[22:08:55] INFO     cve_bin_tool.VersionScanner - Checkers: avahi, bash, bind, binutils, busybox,      version_scanner.py:86
                    bzip2, cups, curl, dovecot, expat, ffmpeg, freeradius, gcc, gimp, glibc, gnutls,
                    gstreamer, haproxy, hostapd, icecast, icu, irssi, kerberos, libarchive, libcurl,
                    libdb, libgcrypt, libjpeg, libnss, libtiff, libvirt, lighttpd, mariadb, memcached,
                    mysql, ncurses, nessus, netpbm, nginx, node, openafs, openldap, openssh, openssl,
                    openswan, openvpn, png, polarssl_fedora, postgresql, python, qt, radare2, rsyslog,
                    samba, sqlite, strongswan, subversion, syslogng, systemd, tcpdump, varnish,
                    wireshark, xerces, xml2, zlib
           WARNING  cve_bin_tool.VersionScanner - Failure extracting /mnt/c/Users/harsh/Downloads/binary    extractor.py:184
                    packages/bugs/avahi-0.8-r1.apk
           INFO     cve_bin_tool -                                                                                cli.py:331
           INFO     cve_bin_tool - Overall CVE summary:                                                           cli.py:332
           INFO     cve_bin_tool - There are 0 products with known CVEs detected                                  cli.py:333
(venv39_CVE_Binary_tool) peb@LAPTOP-M375SCBF:/mnt/c/Users/harsh/Downloads/binary packages/bugs$ cve-bin-tool -x bash_5.0-4_aarch64_cortex-a72.ipk
[22:09:12] INFO     cve_bin_tool.CVEDB - Using cached CVE data (<24h old). Use -u now to update immediately.    cvedb.py:255
           INFO     cve_bin_tool.CVEDB - There are 165282 CVE entries in the database                           cvedb.py:279
           INFO     cve_bin_tool.VersionScanner - Checkers: avahi, bash, bind, binutils, busybox,      version_scanner.py:86
                    bzip2, cups, curl, dovecot, expat, ffmpeg, freeradius, gcc, gimp, glibc, gnutls,
                    gstreamer, haproxy, hostapd, icecast, icu, irssi, kerberos, libarchive, libcurl,
                    libdb, libgcrypt, libjpeg, libnss, libtiff, libvirt, lighttpd, mariadb, memcached,
                    mysql, ncurses, nessus, netpbm, nginx, node, openafs, openldap, openssh, openssl,
                    openswan, openvpn, png, polarssl_fedora, postgresql, python, qt, radare2, rsyslog,
                    samba, sqlite, strongswan, subversion, syslogng, systemd, tcpdump, varnish,
                    wireshark, xerces, xml2, zlib
           WARNING  cve_bin_tool.VersionScanner - Failure extracting /mnt/c/Users/harsh/Downloads/binary    extractor.py:184
                    packages/bugs/bash_5.0-4_aarch64_cortex-a72.ipk
           INFO     cve_bin_tool -                                                                                cli.py:331
           INFO     cve_bin_tool - Overall CVE summary:                                                           cli.py:332
           INFO     cve_bin_tool - There are 0 products with known CVEs detected                                  cli.py:333

this is the error i was getting. Is it just me not using the tool properly?

Terri Oda

@terriko

@peb-peb Did you file a bug about it? It looks like something we'll want to check more deeply. maybe the apk format changed a bit or something.

But yeah, that looks like a potential bug.

I did some bug triage on the things marked as 2.1 milestone: https://github.com/intel/cve-bin-tool/milestone/5

err, 2.2.

Terri Oda

@terriko

But of those, I think intel/cve-bin-tool#1007 and intel/cve-bin-tool#481 can probably be punted to 2.3

That's "improve icu checker" and "deal with - vs *"

I did some checking on the files with spdx headers and there's still a few missing so I'll be updating those today: intel/cve-bin-tool#1112

And I think I need a new PR for the jinja autoescape: intel/cve-bin-tool#988

But yeah, otehr than that, the two remaining issues were improving nvd and the empty reports, both of which have PRs open.

So we are on track for a 2.2 release. yay!

Terri Oda

@terriko

And I merged the codeql stuff, so you may all be able to see https://github.com/intel/cve-bin-tool/security/code-scanning (or you might not, I'm not sure if repo permissions block that)

Where communities thrive

People

Repo info

Activity