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

[tallero]

I didn't expect otherwise, as java developers never really cared about packaging any of their programs and libraries into distributions, so.
The vulnerability is you depend on centralized repositories which do not guarantee the libraries maintainers won't replace them with malicious software, so basically no assurance is given the software you're building is the one you wanted.
You just specify a version number in a file and you don't check if the binary you are receiving is the one you really wanted, it's pretty much insane frankly.

[tallero]

I find ridiculous I even have to explain what's the issue is and I find surreal you aren't ashamed you never even seemed to notice or aknowledge what's going, on but apparently this is the level of professionalism one can expect in this environment, I do get it.
I never expected any of you to be honest people in the slightest. If you were, the web app this source repo builds would be hosted on chain and would be permissionless.
I do get now why the linux foundation is trying to take over, and I hope they will if this is the general developers approach.

[tallero]

Also I do get now why nobody has even started to really package java development toolchains, talking to you is like talking to a wall.

[tallero]

I think for when my PR will be ready I will have already moved this whole project on-chain, so showing how hypocrite it is to have something such as this hosted and managed off-chain.

[ligi]

I do get now why the linux foundation is trying to take over, and I hope they will if this is the general developers approach.

linux foundation is taking over what?

[ligi]

Also: talk is cheap - show me the code!

[tallero]

@ligi to do this properly one needs to create a package for each dependency and I think I've never actually even read a java-<program> build recipe for a maven/jitpack java module/package/library, as the only java packages I've ever maintained were covert -bin packages. As far as I've seen most java programs distribute directly .jar objects most of the time which usually packagers just copy in /usr/share/java/<package>.

Anyway it shouldn't be that hard I think, probably one just has to run the target system gradle instead of those gradle-wrappers and patch the gradle.builds to have the imports coming from /usr/share/java/<package> instead than through the various online repos systems, but really it's easier to navigate for somebody who knows well the java libraries dependency tree, which I do not as I've never written Java code, as you probably know it's basically non-existent in OS development except than in Android.

If you write one for at least a base package without further dependencies it would be of help as you're more familiar with gradle than me, otherwise you'll have to wait as for now I'm okay with the evm-chains-info (build recipe) and evm-chain-explorers (build recipe) bash parsers I've written today and I don't think I will need an auto-deployer for new blockchains and a self-verifying contract mechanism independent of explorers before January as I'm forcing native apps interacting with the blockchains to include the needed artifacts to interact with the contracts generated at build time.
In the toolchain I've already added support for solc and hardhat-generated artifacts through solidity-compiler and only remix is out for now as it doesn't seem that can be used in build scripts. Also I have no idea which libraries generate and parse them. I'm using solc directy, not solc-js.

If you're interested though we could move website resources on-chain sooner than later and maybe add to the contract a financial incentive so to better know to which requests give priority. I'm not exactly sure how you people manage this chainId thing frankly and which RPCs get priority. Like in evm-chains-info I've simply added a function to pick a random one at each request as an alternative to pick the kirsh.

If you were to already mention a library you know doesn't require further dependencies it would be of great help.
I think one it could be useful to have written immediately would be one using the kotlin gradle plugin.

If you need a specific gradle version to build a certain package, in a previous comment I've posted a templatized build recipe for gradle 8.8 you can reuse to package the specific version you need for a given target.

I won't bootstrap my CI scripts before I've finished the ur dependency resolver and published a stable version of evmfs as I want to move the Life / DogeOS infrastructure from github to any cheap EVM blockchain asap and I don't think it's wise to lose time writing ad-hoc ones, as when it will be ready everything will be managed through a single CI script identical for all -ur packages.

In general if I had the time to properly package a language tree I would probably fix node instead, as I've spent quite some time writing correct recipes for node-ethers, solidity-analyzer, hardhat and those alone require dozens of dependencies to be packaged to really ditch the implicit npm registry trust they bring.

On my X profile you find something like 30 hours of packaging livestreaming recorded in the kirsh part of November to fix a versioning issue on something like 150 python packages arch people will probably backport only if I make them notice they could soon incur in licensing issues.

[tallero]

linux foundation is taking over what?

I've read it's taking over the enterprise sector with an Ethereum rebrand.

[ligi]

I've read it's taking over the enterprise sector with an Ethereum rebrand.

where did you read this?

[tallero]

On their website.
Obviously when I say 'taking over' I don't mean they're doing it, I mean they've allocated manpower to push it, whether they'll manage it will depend on whether people will fall for it, which given how I see usually things go, it may happen.
I mean just look at me, I have published the whatever and you have been the kirsh person ever replying to me in the Ethereum circle and I still have no feedback nor from developers nor from users about anything I've produced up so far.
So if I have to infer anything from that is in the end win those who better pay 'journalists' to talk about stuff and leverage the soft power they get from that or from other sources.
I don't see much technical or moral merit anywhere frankly.