Allow for pip extras

[shanedell]

Allow for pip extras

• Allow pip packages to specify extras.
  • Syntax: package_name[extra1, extra2]
  • Using regex the extras will be removed from the package name.

Closes #1246

Testing

Filename: requirements.txt
Content:

celery[redis, pytest]==4.4.7
starlette==0.17.1

Command: go run main.go file:requirements.txt

Output Before

 ✔ Vulnerability DB        [no update available]
 ✔ Indexed requirements.txt 
 ✔ Cataloged packages      [2 packages]
 ✔ Scanning image...       [1 vulnerabilities]
   ├── 0 critical, 0 high, 1 medium, 0 low, 0 negligible
   └── 1 fixed
NAME       INSTALLED  FIXED-IN  TYPE    VULNERABILITY        SEVERITY 
starlette  0.17.1     0.25.0    python  GHSA-74m5-2c7w-9w3x  Medium  

Output After

 ✔ Vulnerability DB        [no update available]
 ✔ Indexed requirements.txt 
 ✔ Cataloged packages      [2 packages]
 ✔ Scanning image...       [2 vulnerabilities]
   ├── 0 critical, 1 high, 1 medium, 0 low, 0 negligible
   └── 2 fixed
NAME       INSTALLED  FIXED-IN  TYPE    VULNERABILITY        SEVERITY 
celery     4.4.7      5.2.2     python  GHSA-q4xr-rc97-m4xx  High      
starlette  0.17.1     0.25.0    python  GHSA-74m5-2c7w-9w3x  Medium 

[kzantow]

I think this should happen in Syft when parsing requirements.txt, no?

[shanedell]

@kzantow So in Syft it already works

 ✔ Indexed requirements.txt 
 ✔ Cataloged packages      [2 packages]

NAME                   VERSION  TYPE   
celery[redis, pytest]  4.4.7    python  
starlette              0.17.1   python

However, when it comes back over into Grype it doesn't scan celery[redis, pytest]. I assume it doesn't consider celery[redis, pytest] a proper package or package name? But if you remove the [redis, pytest] it works fine.

[kzantow]

I mean: celery[redis, pytest] doesn't seem like a valid package name. This should be just celery, shouldn't it? And maybe the extras get captured in the metadata?

[shanedell]

@kzantow So are you saying update Syft to remove the extras content ([.*]) from the package name, like done in this PR and then add that extras content to the metadata? If so that would make sense to me. But then would Grype need a to add a PythonMetaData type to support this parsing this data?