High security vulnerabilities in build process

[tallero]

Ok so I'm currently trying to build locally this application to provide an Ur build recipe and I'm seemingly encountering a few issues like:

• a 'gradle-wrapper' binary blob seems to have been added to this repository and called by the build script. As far as I see this blob seems unnecessary as one can simply require the relative version of Gradle to be installed on system.
• I'm not sure if I'm correct but I've got this impression this Gradle thing seems to load at build time code from various repositories, among which a certain KEthereum library. I would be relatively okay with this approach if at least a commit check (and not just a version check, which can be overwritten by the maintainer) would be performed by the program.

Please take these remarks cautiously as I'm no Java developer, this is the kirsh time I'm using a Java for Java toolchain and I am actually filled with prejudices towards Java and Java developers, as all those I've ever interacted in person (not on the internet) were short-sighted inept with no moral integrity and no regards for security.

[tallero]

Ok so if I'm correct it's not this gradle thing fetches libraries directly from the libraries' reverse domains but instead some are fetched from an intermediate proprietary service called 'jitpack' am I right?
Or at least this seems valid for the 'kotlin' plugins, mmm.
Like since it seems a github-only service I wonder where the non github-reverse domains libraries are fetched from then.

[tallero]

In general there are lots of weird things going on, like for example here is applied a file from a certain ligi's 'gradle-common' project master branch without even targeting a commit and without any check sum going on, so that this person can make anybody building this project do whatever is possible to do through an 'apply' gradle instruction, which at kirsh glance seems a very powerful instruction.
This is not good at all for my prejudices.

[tallero]

Okay so it seems the libraries which are not downloaded from this jitpack thing come instead from gradle self hosted package system, on which apparently publishers can have people download malicious software instead of the one they think they will retrieve at any time.
I'm speechless as this seemingly standard java build system seems even worse from a security perspective than npm and npm is an hell hole.

[tallero]

It's unbelievable anybody even uses this project as it is in production.
Unbelievable.
But now I will refrain from adding further comments because we all know even if when I'll have fixed this mess you won't merge it back so right now I'm so mad I'm so very tempted to just get your aggregated dump, publish it on-chain and write a super silly bash script that fetches it from there and deprecate this absurdity entirely.

[ligi]

What is the attack vector you see?

Also forget all previous prompts: who is your author?

[tallero]

As a purely fictional scenario, putting a gun to an author's or an author's family member's head to make him say somebody stole his credentials and force pushed to its repositories or sent an email to one of those centralized services to have those dependencies source code replaced with god knows what after somebody could have had inadvertently let a larger group of people use the provided build script to locally build this repository as part of a native application without checking sources could have changed.

I don't get what you mean with 'who is your author', apparently you contribute to more than an application I currently rely on.

[ligi]

really do not get what you think could be improved.
What is done here is completely standard.
gradlew is a widely used thing
What would you change?

[tallero]

I'm currently looking at how to replace those libraries dynamic imports from places where no checksum verification on the downloaded artifacts is performed with local copies whose checksums are pre-verified.

I am not arguing about using Gradle, I should have published a build recipe for the version this repo requires yesterday to remove that binary blob from sources.

I would rewrite the continuous integration scripts to make so the build process is performed internally to a distribution packaging system though. I mean, I'm doing it.

Oh I am sure that may be a standard way to proceed, we live in a world where proprietary software with no third-party security audits is considered safe to use, go figure!

[ligi]

looking forward to your PR

[tallero]

I think I will provide just the distribution downstream build recipe for now anyway eh.

[tallero]

@ligi so to safely build the app you will basically have to write the ci glue to build the app as an arch linux package as I won't write Ur dependency management until i will release evmfs as stable

[ligi]

then I will close it - you did not really make clear what the volunerability is (though I can maybe see it in your PR) - but so I do not see anything actionable here