Hacker News Reader

Comment by littlestymaar | Hacker News Reader

Nobody in this thread argues that npm is not bad (it is), the current topic is: “is maven's design[1] better” and there is little evidence on this front.

Maven was (yes, I'm using the past on purpose) not a panacea that later system failed to equal: it has the usability of an IRS form and never gained as much popularity in the Java world than npm in the JavaScript one for that reason. In 2014, last time I did Java for work, the main security feature against supply chain attack was: “we are getting .jar files individually and not using maven because it's a fucking mess”

[1]: not implementation, which is what's make npm arguably a pile of shit

View on HN

> it has the usability of an IRS form and never gained as much popularity in the Java world than npm in the JavaScript one for that reason.

I thought IRS forms were hard?

I have more than a decade of experience collected from work with CDs (Delphi), downloaded libraries (Delphi, Java, PHP), Ant (Java), Maven (Java), PEAR (PHP), Composer (PHP), Nuget (.Net), NPM/Yarn (Javascript/TypeScript) and Gradle (Java/Kotlin).

Two of these have been somewhat easy to work with for as long as I used them: Maven and Yarn. I hear NPM us usable now, but it absolutely wasn't good early on.

> “we are getting .jar files individually and not using maven because it's a [...] mess”

It seems obvious from your writing that you either worked in a place that was really serious about security or had no clue. Both could result in this conclusion, but based on your writing my bet is on the latter, i.e. they were clueless.

Edit:

Reading your comment here: https://news.ycombinator.com/item?id=26091480

I have concluded that it was a mix of those two: the people you worked for were trying really hard to be really serious about security and failing to automate it.

Sounds like you had some poor experiences with people who didn't know what they were doing.

The proper way to audit your dependencies is to run an in-house Maven repository server. Just like you would for npm, or any package repository really.

So you just spin up Sonatype Nexus, proxy the repositories you trust and disallow releases from being overwritten. That way you're certain the jar you're using today, is the exact same as the one you'll be using years from now.

Alternatively, if you have a vendor who ships their jars manually, you can just vet them, then upload them to your in-house Maven repository and have your developers pull them in as usual.

We do this. I had to work on a greenfield project and it used a ton of libs that weren’t in our repo. It was so annoying to have a list of repos to add to the in-house list, then discover things didn’t work, so now we need these. It literally added weeks of man-hours to the project, per day.

> It literally added weeks of man-hours to the project, per day.

Can you explain what exactly you mean here, because the way I read it realistic time estimates for the projects grew by weeks pr day which probably means

- I misread

- you wrote something you didn't mean

Anyways it sounds like something was way off and I have worked on some projects with Maven and other systems.

Due to the amount of bureaucracy and vetting required, each package needed four people to touch the task, it took about an hour each person (four man-hours). Then you throw in their dependencies and it grew to about 50 man-hours per top-level dependency.

OK, so again not Mavens fault but an utterly insane bureaucracy?

Because otherwise the workload should shrink fast after one has vetted the dependecies for a couple of packages?

I agree on "not maven fault" but I don't find that much bureaucracy insane, for one changing dependencies on a mature java project doesn't happen that often, and for another knowing licensing, possible patent violation and a scan against a known vulnerabilities database is not a bad thing to do and it's normal for it to take some time as it passes hand between different people, after all you don't want devs working on licensing and you don't want to waste legals just to run a package trough vuln scans software.

beside, companies that care usually also have a database of previously cleared packages, so one can reduce one own work/delays by picking from the approved deps list.

50 hours pr top level dependency not once or twice or ten times but every time does however sound like something "cache-like" is missing on the human level?

true I was reasoning more on the 4 hour per package, which is in line. but you're right for sure the unique dependency graph can't be averaging that high

Yes, vetting everything takes a LOT of time. Regardless of the language, package manager, etc.

We (small shop) don't vet the code of all of our dependencies, since we simply don't have the manpower. But we do run nexus to have the guarantee of version pinning. So something that is fine today will be fine in 5 years.

Maven is/was huge in the Java world. For years it was pretty much the only way to resolve dependencies, until people got fed up with its many idiosyncrasies.

> “we are getting .jar files individually and not using maven because it's a fucking mess”

That seems odd and a bizarre edge case. Nobody worked like that with Java projects, and I bet nobody does today either.

> until people got fed up with its many idiosyncrasies.

Many of us still prefer Maven.

Having to deal with other people's artistic Gradle files works wonders when it comes to understanding the goodness of standards.

Yes, of course.

Another example: SBT was supposed to be the "savior" in the Scala world and... I still have nightmares about SBT from a couple of years ago. Maybe it's finally become usable and intelligible in recent years.

I think you're confusing the client side build tool Maven with the artifact repository Maven.

Gradle for example still uses Maven for its dependency artifact repository. So Maven is still the standard for Java.

I am confusing what now? I'm the one arguing Maven is huge and that the parent post I'm replying to is mistaken. I never mentioned Gradle, that was a sibling comment.

I might have misinterpreted you the first time around. I thought you were saying that people have moved on from Maven, when in fact Maven is still the defacto repository for open source Java projects. Sorry if I did.

Maven is ubiquitous in the Java world and the de-facto package/dependency management system out there. Has been since the mid-2000's and as of 2018 when I last did Java development (Scala really), it is still widely in use. Getting jar files manually would have me running from whatever company that was doing that. Let me guess, they wrote all their code in Notepad because IDE's are a "fucking mess" too right?

You vastly underestimate the level of bureaucracy that can exist in the biggest Java users of this planet (namely banks and public administrations): in these organization (at least a few years ago, the Solarwind attack shows it may not be the case anymore) every single dependency you want to use must be justified, and then is audited by a dedicated team, which ends up handing you the validated .jar.

It was a common development practice in these entities (I was working as a contractor, for different customers), most of them have been using computer programs at there core long before the internet went mainstream.

That bureaucracy makes sense to me. You're _shipping_ those dependencies. When something misbehaves or allows an exploit it doesn't matter if it happened in a dependency or not -- the dependency isn't the one who's accountable to customers and the regulatory authorities.

It sounds like the processes in use to do this may have been pretty crappy in the organizations you've been with, but it also sounds like it would take less time than implementing a dependency's functionality from scratch in most cases you'd want to pull in a dep.

So you worked with customers using some particularly strict vetting protocols. That's a far cry from claiming Maven never reached the popularity in the Java world that NPM has in the Javascript world -- Maven is the dependency manager in the Java world. The entities you worked for are the exception.

Another thing that strikes me as odd in your comparison: those customers you worked with wouldn't have used javascript+NPM either, since it has all of the problems of Maven and external deps and then some! So what exactly are we comparing then?

This "bureacucracy" is very necessary if security is at all a concern. Solarwinds is hot to talk about right now but it has always been the case that having a build download code willy-nilly is a recipe for getting attacked.

In any security conscious organization the only way to pull dependencies is from a local trusted repository. And the only way they get placed there is through a review process.

Reply on news.ycombinator.com