Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Runtime Dependency Checking #342

Closed
dave-tucker opened this issue Oct 10, 2018 · 1 comment · Fixed by #520
Closed

Runtime Dependency Checking #342

dave-tucker opened this issue Oct 10, 2018 · 1 comment · Fixed by #520

Comments

@dave-tucker
Copy link

Is your feature request related to a problem? Please describe.
In some of our projects we are making use of Cgo. This bring in several runtime dependencies that must be met in order for the binary to be run. Currently, fossa isn't able to find these dependencies.

Providing runtime dependencies is solved by specifying packages that we depend on in our DEB/RPM packaging. While the dependencies are dynamically linked at runtime, we still need to understand the licenses of these dependencies.

Describe the solution you'd like
Support scanning of debian/control files and/or RPM spec files.
License information is available in via a dependencies copyright file or via rpm -q $dep --queryformat '%{license}'

Describe alternatives you've considered
Using ldd to resolve dynamically linked dependencies from a binary.
This wouldn't require knowledge of packaging but would require a way to query a license of a shared object file.

Using nm to resolve statically linked dependencies (if symbols haven't been stripped) from a binary.
You'd need a mechanism to resolve from symbols -> library -> license

Additional context
This solution will work for any binaries complied for Linux that have runtime dependencies.
It obviously won't work for:

  • Windows
  • Statically linked dependencies
@dave-tucker
Copy link
Author

dave-tucker commented Oct 12, 2018

@liftM FWIW I've been thinking some more on this and it looks like it could be pretty hard.
The main reasoning is that the debian/control file doesn't actually contain the dependencies but it uses a special shLibs:Depends macro which calls out to dpkg-shlibdep .

A simpler implementation might just be to get the dependencies from a DEB/RPM archive directly.
E.g using dpkg or rpm.

Another way of addressing this use case in the shorter term would be to provide a means of manually specifying the dependencies within the fossa.yml file. Obviously an automated solution to this would be best, but I can see that it might take longer to work through.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants