[mohaine]

Isn't this the exact opposite of what you want security wise? To even read the most basic project metadata (project name, version, deps, ... ), you have to run arbitrary in project code. So you have to do a code review of the project file before you can even open the project in your IDE. Programmatic project scanning is right off the list.

[packetlost]

At some level of complexity/edge-case-ey-ness you just need arbitrary execution to get things done. At some point you need to accept that that if you're pulling in a dependency, you trust the authors of that code enough to execute their code. That being said, getting project version, deps, etc. should be statically available for packages, but being computed from source isn't the worst thing IMO, though it's not what I would go with.

[znpy]

> Isn't this the exact opposite of what you want security wise?

Quite the opposite, I'd say? Everything needed is source controlled (and signed, if commits are signed).

Also, all the metadata can be queried by the ide (any ide) via an LSP. can you do that with the xml from maven/ant ?

I like this 1JPM so much I might adopt it for all my personal java projects.

[Osiris-Team]

Haha glad to hear that! But really don't at the moment, the project is really fresh and I published a early access release to see if there was even demand, and I guess there is!

Contributions are welcome and I am happy to work on this project.

[andylynch]

Gradle is no different here. Ditto many other build tool.

[krzyk]

But maven does not.

[oftenwrong]

Maven plugins and extensions can execute arbitrary code, so you should still exercise care when running an untrusted maven project.

[stefs]

you mean because it's xml instead of executable code?

[krzyk]

No, because it was designed that way - declarative.

You can have xml with code-like-structures, e.g. Ant

[mvc]

Doing this does not preclude publishing that kind of metadata as part of the build/deploy process.

[metadat]

All build systems allow arbitrary code execution at some point / layer. This isn't a real criticism or issue.

[lmm]

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.

[stefs]

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.

or am i missing something else?

[lmm]

> 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)