-
-
Notifications
You must be signed in to change notification settings - Fork 86
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
support for maven-shade-plugin
#472
Comments
Yes, using a CycloneDX assembly would be the correct way to represent this. |
evidence.identity can also be used to describe the technique and confidence. |
By assembly do you mean |
Correct @ppkarwasz |
This makes sense embedded dependencies of dependencies, but I'm having trouble understanding how it works for embedded dependencies of the 'current' project: to take the example in https://github.com/raboof/maven-shade-sbom/, The current generated SBOM comes down to (removed some details)
I can see how if some project would depend on
To be able to construct this SBOM we need to know that |
We were just talking about this the other days with @hboutemy and the solution might be to introduce a property that says if a dependency is dynamically linked or _statically linked, or whatever couple of adjectives makes sense for the ecosystem. For the Java ecosystem:
|
"the solution": sadly it's not the full solution but only one key step, as we'll have other aspects to sort out too, like how to deal with a Maven module that produces both the "naked" artifact ("naked" => dynamic dependencies) AND the shaded one (=> a few static dependencies) IMHO, these 2 topics are the key aspects to be solved before trying to implement the feature |
OK. For the Maven ecosystem, the adjectives 'dynamically linked' and 'statically linked' seems a bit foreign. I think a boolean attribute named
That might be a topic for a different issue, or do you think it interacts with this issue strongly? I filed this as #574 - so far I think each artifact having 'their own' SBOM sounds most convenient? That also seems to work well for this use case, as then you don't have issues with how to tag a component that is embedded in one of the artifacts and a 'regular' dependency in the other: we can tag it as 'maven.embedded=true' for the shaded jar and 'maven.embedded=false' for the regular one. |
I know people are not used to this "dynamically linked" term, but they'll have to learn: in a library, a dependency is not not really a strict dependency, the consumer will have conflict resolution that will try to use the library's preferred version, but may finally select another dependencies in Java, given classpath conflict resolution, are always (and implicitely) "dynamic" = the effective version from a consumer perspective won't necessarily be the asked version On |
OK. I think |
in java (or JVM languages), I suppose we can say default is "not embedded" and exception is "embedded" we need IMHO to clarify SBOM semantics more widely than what is implicit in JVM. And define in which CycloneDX field put the resulting info |
@hboutemy since this ticket is specifically about the maven-shade-plugin, I would recommend supporting that specifically and supporting component assemblies. That way we can represent that a shaded component includes other components. If you want to support assemblies for other things or make it configurable, that enhancement should realistically be in another ticket and not conflict with the shade functionality described in this ticket. |
That seems reasonable (though it can't hurt to 'think ahead' a little and choose an approach that will be easy to generalize later, avoiding conflict)
I'm not entirely sure we're on the same page yet on how to encode this information. Given the example in #472 (comment), am I summarizing correctly that:
|
@stevespringett this does not answer how to encode, this does not answer how to differentiate ecosystem-specific default semantics |
created draft PR #576 to list all the cases (and associated plugins) where dependencies are copied to the output artifact and de-facto started to describe the default with JVM: Maven dependencies are just symbolic expectations, with very loose version preference description |
Unless I'm missing something, the information should be encoded in the following way:
|
If |
If A is the artifact that the SBOM describes, then use |
I doubt that |
Gotcha! Does this mean that when tools like Currently the vast majority of such tools put everything under |
When using maven-shade-plugin, the sbom should likely somehow encode which dependencies are 'embedded' in the jar, and which are 'regular' dependencies.
AFAIK there is no convention on how to express this difference yet in CycloneDX. Likely it would make sense to make use of the assembly concept?
I have a test/demo project for this at https://github.com/raboof/maven-shade-sbom/
The text was updated successfully, but these errors were encountered: