Resources from system packages are not being associated with that package #407
Comments
|
Shrikes... so I think the best course of action may be to improve extractcode with an option to normalize names for windows or not. The ":" in a filename is illegal on Windows and extractcode is running on all OSes. |
JonoYang
added a commit
that referenced
this issue
Jun 15, 2022
* extract_tar uses the built in tar command, which does not do filename sanitization Signed-off-by: Jono Yang <[email protected]>
JonoYang
added a commit
that referenced
this issue
Jun 16, 2022
Signed-off-by: Jono Yang <[email protected]>
|
We are now using |
JonoYang
added a commit
that referenced
this issue
Jun 16, 2022
* Update expected test results Signed-off-by: Jono Yang <[email protected]>
JonoYang
added a commit
that referenced
this issue
Jun 16, 2022
* Update expected test results Signed-off-by: Jono Yang <[email protected]>
tdruez
pushed a commit
that referenced
this issue
Jun 17, 2022
* Use extract_tar to extract images and layers #407 * extract_tar uses the built in tar command, which does not do filename sanitization Signed-off-by: Jono Yang <[email protected]> * Update expected test results #407 Signed-off-by: Jono Yang <[email protected]> * Recreate docker-images.tar.gz with valid tars #407 * Update expected test results Signed-off-by: Jono Yang <[email protected]>
|
@JonoYang we're having new kind of issue following the recent extraction changes. |
|
I run the Docker pipeline on docker://rabbitmq:3.9.13-management and got the same errors. I also tried running I then took a closer look at the symlinks. In I also noticed that the |
Since we exclude the symlinks form the results, it's probably not an issue to skip them early during extraction. |
|
@tdruez I updated the code in Should messages like these be returned as error messages by |
|
@JonoYang I'm not sure about the value of logging those as ProjectError. |
|
@tdruez this is since we now use plain tar over extractcode. we will need to either revert or add capabilities to extract links. The later seems better |
pombredanne
added a commit
that referenced
this issue
Jul 30, 2022
Use the latest container-inspector to fix symlinks extraction. In particular broken synlinks are not treated as an error anymore and symlinks are extracted correctly. Reference: #471 Reference: #407 Signed-off-by: Philippe Ombredanne <[email protected]>
pombredanne
added a commit
that referenced
this issue
Jul 30, 2022
Use the latest container-inspector to fix symlinks extraction. In particular broken synlinks are not treated as an error anymore and symlinks are extracted correctly. Reference: #471 Reference: #407 Signed-off-by: Philippe Ombredanne <[email protected]>
pombredanne
added a commit
that referenced
this issue
Jul 31, 2022
Use the latest container-inspector to fix symlinks extraction. In particular broken synlinks are not treated as an error anymore and symlinks are extracted correctly. Reference: #471 Reference: #407 Signed-off-by: Philippe Ombredanne <[email protected]>
pombredanne
added a commit
that referenced
this issue
Jul 31, 2022
Use the latest container-inspector to fix symlinks extraction. In particular broken synlinks are not treated as an error anymore and symlinks are extracted correctly. Reference: #471 Reference: #407 Signed-off-by: Philippe Ombredanne <[email protected]>
tdruez
added a commit
that referenced
this issue
Aug 1, 2022
Co-authored-by: Philippe Ombredanne <[email protected]>
tdruez
added a commit
that referenced
this issue
Aug 1, 2022
* Correctly extract symlinks #407 #471 Use the latest container-inspector to fix symlinks extraction. In particular broken synlinks are not treated as an error anymore and symlinks are extracted correctly. Reference: #471 Reference: #407 Signed-off-by: Philippe Ombredanne <[email protected]> * Update container_inspector to 32.0.1 version #407 #471 Co-authored-by: Philippe Ombredanne <[email protected]> Co-authored-by: tdruez <[email protected]>
|
I've merged in the latest changes from |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am running the docker pipeline on a docker image that uses Ubuntu 20.04 as the base image. The pipeline is able to report the installed system packages but does not correctly associate the package Resources to the package.
I've done some digging and found that the issue is with how the debian package info files are named.
By default, the files from
/var/lib/dpkg/info/that Debian based distros use to list the install location of package files has the format of<package name>:<arch>.<ending>e.g.guile-2.0-libs:amd64.md5sumsWhen we extract the Docker image layer using extractcode, the colon in these filenames turns into an underscore:
guile-2.0-libs_amd64.md5sums. This causesDebianPackage.get_list_of_installed_files()(https://github.com/nexB/scancode-toolkit/blob/develop/src/packagedcode/debian.py#L60) to not find themd5sumorlistfile for the package, and the package resources are not associated with it.The text was updated successfully, but these errors were encountered: