Closed dzwicker closed 3 years ago
👋 Hi @dzwicker, I'm a friendly neighborhood contributor here, but try to help out from time to time. 😄
So this is pretty similar to #130 and #134 as they both relate to the Gradle configurations and furthermore get into component variants and capabilities that build upon those configurations. Unfortunately it's not as simple as adding all of the attributes from a configuration because right now the init.gradle
merges all Gradle configurations into one flat, merged configuration. While you're right that all attributes should be observed because of this merged configuration there will be potentially conflicting attributes between each configuration. This is especially so when a build consumes Gradle capabilities or when the Gradle build would produce multiple build variants.
In my opinion the correct solution is to instead handle each resolvable configuration separately as these will be the containers under which Gradle will resolve it's dependencies. This would mean that all attributes would remain in place rather than having to copy them to a new configuration and try to resolve everything from there (might become impossible as time goes on). There are also other consumable configurations which denote the outgoing artifacts from a particular project and these can be safely ignored as they would never have any dependencies of the Gradle project.
Hi @shanman190,
i think you are right. Merge all configurations is not the way it should be as it will be really error-prone. And yes there are configurations to ignore.
I started thinking about the hole process. I think injecting the init script is an easy way to get startet, but the owner of the gradle build loses all his control. Gradle is highly configurable and flexible but there is nearly no way to adjust the snyk plugin. Perhaps the control should be hand over to the real build system to create a json graph and then import it to synk. So the enduser has a lot more control over the hole process.
What do you think?
So right now, the init.gradle
I think provides most everything that an end user would need or want. It's able to access everything that is necessary for providing the service that Snyk delivers and it's also a really easy way to blend the polyglot nature of this plugin. It does get a little tricky since the Snyk server API, at least at the moment and from what I've seen so far, has a 1:1 relationship of a project to a dependency set. As a result of Gradle being more able to model variants and developer intent, it makes gathering the dependency graph a little challenging in order to inspect it since a Gradle project has a 1:n mapping to dependencies where n equates to the number of resolvable configurations whether for capabilities or variants.
As long as each configuration is resolved independently and evaluated independently, then that should handle each of the use cases Gradle provides to it's users.
👋 I am currently looking at this issue. Thanks for raising the problem here @dzwicker and thanks @shanman190 for being friendly and helpful by giving toons of context about our tool.
---- EDIT
Currently Suggested in Support Ticket snyk test --configuration-matching=default
@dzwicker we have released a new version of the cli that should resolve this issue v1.431.4
cc @shanman190 https://github.com/snyk/snyk/pull/1548
By no longing merging the configurations we are no longer having this issue for gradle v6+. I am closing this issue
We use the kotlin and kotlin MMP plugins. The defined dependencies make heavy usa of the metadata model for dependencies which needs to set the attributes to select the write dependency at the configurations. Kotlin defines multiple values for attributes! This set is not copied to the merged configuration by your
init.gradle
script.Context is this ticket: https://support.snyk.io/hc/requests/7457
node -v
:v12.10.0
npm -v
:6.10.3
snyk -v
:1.373.0
gradle -v
: ```Gradle 6.7
Build time: 2020-10-14 16:13:12 UTC Revision: 312ba9e0f4f8a02d01854d1ed743b79ed996dfd3
Kotlin: 1.3.72 Groovy: 2.5.12 Ant: Apache Ant(TM) version 1.10.8 compiled on May 10 2020 JVM: 1.8.0_272 (AdoptOpenJDK 25.272-b10) OS: Mac OS X 10.15.7 x86_64```
snyk test --file=build.gradle.kts --package-manager=gradle --all-sub-projects
Expected behaviour
Select the write dependency as the normal build do!
Actual behaviour
Fails with because of:
Steps to reproduce
Setup a kotlin project. With the dependency
net.pearx.kasechange:kasechange:1.3.0
. Will brake.The debug shows the problem:
IMPORTEND:
"org.jetbrains.kotlin.platform.type":["jvm","common","js"]
and in the gradle error:
IMPORTANT:
- Provides attribute 'org.jetbrains.kotlin.platform.type' with value 'jvm' but the consumer didn't ask for it
The problem is inside the
init.gradle
script at line 245:if replacing this lines with the code beneath all attributes are copied and it works.
Please do not delete unambiguous build attributes