Maven allows you to parse the project definition and understand its build definition without running arbitrary code, and you can configure it to only run signed code with a whitelist of keys.
does this still hold true if the project uses build plugins?
isn't this just an arbitrary distinction regarding complexity, because i can look at the gradle build script code and - theoretically - vet it in the same way i can vet the xml build file of a maven project. the main difference is just that the one's a relatively simple XML document and the other is a comparable more complex groovy or kotlin program.
> does this still hold true if the project uses build plugins?
Build plugins are the code I was thinking of, you can check the signatures of all the build plugins and whitelist only plugins signed with particular keys, or only specific versions of them. Of course some plugins allow executing arbitrary code, so you'd have to not whitelist those plugins, and if you whitelist keys then you have to trust the holders of those keys not to publish plugins that allow running arbitrary code. But that's reasonably practical, because most maven builds don't use that kind of plugin and maven culture is generally that plugins should only do one specific thing.
> isn't this just an arbitrary distinction regarding complexity, because i can look at the gradle build script code and - theoretically - vet it in the same way i can vet the xml build file of a maven project. the main difference is just that the one's a relatively simple XML document and the other is a comparable more complex groovy or kotlin program.
Theoretically you can't, because it's code in a Turing-complete programming language, and it's theoretically impossible to check any nontrivial property of general programs reliably, because you run into the halting problem.
More practically, it's very easy to safely e.g. pull out the list of dependencies of a Maven build, you just parse the XML (you can even use an XPath expression or something if you want). How would you even begin to do that for a Gradle build? You can't do anything with it until you've executed it as code (you can do a really awful hack like regex search for common patterns, but that's not going to be reliable), and once you've executed it as code it's game over.
(Of course if the maven build is using a plugin that adds extra undeclared dependencies then you'll miss those. But that's not a common thing in maven culture, and we've already said you'd need to check and whitelist plugins)
isn't this just an arbitrary distinction regarding complexity, because i can look at the gradle build script code and - theoretically - vet it in the same way i can vet the xml build file of a maven project. the main difference is just that the one's a relatively simple XML document and the other is a comparable more complex groovy or kotlin program.
or am i missing something else?