IDEAS
My Sonatype
Community
I put this in the wrong place. I also created
https://support.sonatype.com/hc/en-us/requests/73699
Our Sonatype release 144 is finding license blockers for pitcher/canvas-ui 1.1.0 and azinepages/common in our customer-tablet NPM application even though we can’t find any dependency which should include them in our build. We can’t find those libraries anywhere in our CFG repository or on the Internet.
If we could find them, we might be able to show our Legal department that they do in fact have a license, but we would rather understand why this dependency is being brought into our report.
We scanned all the files in the application looking for any mention of canvas-ui or azonepages and found none. Where did the dependencies originate?
N107576@WCLD-HRPT0F3 MINGW64 ~/Documents/Code/customer-tablet-frontend/customer-tablet-frontend (develop)
$ time find . -type f | wc -l
40006
N107576@WCLD-HRPT0F3 MINGW64 ~/Documents/Code/customer-tablet-frontend/customer-tablet-frontend (develop)
$ time find . -type f | xargs grep -isl canvas-ui
N107576@WCLD-HRPT0F3 MINGW64 ~/Documents/Code/customer-tablet-frontend/customer-tablet-frontend (develop)
$ time find . -type f | xargs grep -isl canvas | grep ui
N107576@WCLD-HRPT0F3 MINGW64 ~/Documents/Code/customer-tablet-frontend/customer-tablet-frontend (develop)
$ time find . -type f | xargs grep -in azinepages
This isn't really a Sonatype Lift issue but that's the closest choice offered. You also don't offer "bug report" in the feedback type pulldown.
Thank you very much - I'll look for the "occurrences" tab. Having worked with OSS people for a couple of decades, I know how totally unconcerned they can be with the niceties of licensing. This is a gnarly problem indeed.
We have on the order of 15,000 license issues enterprise-wide. I'm doing what I can to suggest changes in the way you find them to minimize the amount of manual work we have to do to clear them up. So far, every single License-None issue I've explored has found a license, but we can't get to that point until we can figure out a) what the library is and b) where it came from so we can look.
THANKS!
Hi,
Thank you for taking the time to submit this. The normal bug submitting process is through support, but we appreciate the feedback. I can see that you have a support ticket and that it looks to have been resolved.
For your information on the component details page within IQ there is an occurrences tab, that tab will show you the location of a dependency. I've included a screenshot here:
Additionally, a-name is authoritative naming. It is how we identify JavaScript files which may be copied in from other libraries outside of official NPM packages. This would explain why your developers didn't find the dependency in their build metadata, because it wasn't declared there. Even if the code wasn't declared you still have security and legal risk which is why we highlight it in the evaluation. And often times when people are copying files they change the names so our identification isn't on the name of the file but on the hash and syntax tree. So doing a grep or search for a similarly named file likely won't yield the best results. If you'd like additional information: https://help.sonatype.com/iqserver/analysis/npm-application-analysis#npmApplicationAnalysis-A-Namefilesvsnpmcomponents
To understand where a component was found I highly recommend using the occurrences tab.
Since we already provide a means of identifying where we found a component I'm going to mark this feature as "already exists". Let me know if this meets your needs or if you have any other concerns.
Thank you,
Dariush Griffin
Product Manager - Lifecycle