6 ms·

I love a good rant as much as the next guy, but unfortunately, rants are rarely actionable. > Maven, ivy and sbt are the go-to tools for having your system dow

I love a good rant as much as the next guy, but unfortunately, rants are rarely actionable. > Maven, ivy and sbt are the go-to tools for having your system download unsigned binary data from the internet and run it on your computer. The root of the problem is that out of the total number of libraries available in language X, only a small subset is packaged in Debian/RHEL. This may be more egregious with large, Java enterprisy software, but you could easily end up with the same problem in Ruby or Python. You cannot reasonably expect developers to package and maintain all their dependencies properly. The least worse solution would be to: - still use maven to manage dependencies - create a Debian/RHEL package incorporating the dependencies (effectively vendoring them in the package) Unfortunately, it is not that simple, because you need to make sure that your vendored-in-the-package dependencies are somewhere where they will not conflict with another package with the same idea and the same dependencies (or better, the same idea and a different version of the same dependencies). Which means you need to keep them out of /usr/share/java and make sure the classpath points at the right location. However, it seems that developer tend to avoid this kind of rigmarole and instead go for the "install dependencies as a local user" for certain classes of application (eg, webapps) because packaging is not fun.

rlpb 12y ago
> You cannot reasonably expect developers to package and maintain all their dependencies properly. I think that this is a good point, but it all comes down to quality control. You wouldn't accept a new dependency into your project if it is buggy or has a bad API. So why is bad packaging, a hacked-up build system or inability to build from an auditable source considered acceptable in many communities today?
- mercurial 12y ago
  I don't think that's acceptable, but ranting and ignoring the underlying issue doesn't help.
mike_hearn 12y ago
Maven packages aren't actually unsigned either. They're downloaded over SSL and to get into Maven Central you need to sign with a GPG key. The problem is that you normally cannot find a path to the developers through the web of trust, of course, but that's not Maven's fault. That's the fault of the web of trust (more accurately called "handful of strings of trust"). Debian/Red Hat code signing doesn't prove very much either. All it proves is that the package came from Debian or Red Hat. But did they modify the software along the way, doing some kind of MITM attack on the upstream developers? Quite possibly! At least with Maven you don't have that problem.
- danieldk 12y ago
  The problem is that you normally cannot find a path to the developers through the web of trust, of course, but that's not Maven's fault. It is Maven's vault. Debian could have taken the same approach, but instead they have decided to vet prospective developers for a few years, and use one signing key for package indexes. As a result, in Debian: - It is feasible to actually check packages, because you don't need a large WoT. - You know that the maintainer of a package was a least vetted for some time before they could put anything in the archive. With Maven: - It's infeasible to check the signatures, since nearly no one has a complete enough WoT. - Anyone can submit a library, no vetting necessary. - Maven does not check signatures by default. So, basically the only thing you can do in Maven is hand-pick a small set of libraries. Verify them in some way and stick to specific versions, putting their checksums in your POM. Unfortunately, as the article already touches upon, too many Java libraries pull in half of the internet, so it may not be very practical.
  - mercurial 12y ago
    > It is Maven's vault. Debian could have taken the same approach, but instead they have decided to vet prospective developers for a few years, and use one signing key for package indexes. Yes. But this creates a much higher barrier to entry. As usual, it is a trade-off, but it is obvious that with a Debian-like system, the number of packages on Maven/CPAN/Pypi/Rubygems would be considerably smaller.
sagichmal 12y ago
> You cannot reasonably expect developers to package and > maintain all their dependencies properly. What? With appropriate tooling, of course you can.
- deleted 12y ago
  [deleted]
- mercurial 12y ago
  I don't know any tooling that turns (recursively) a Maven pom file into a Debian repository of Debian policy-abiding .debs, which are magically updated when the pom file changes.
  - lmm 12y ago
    If you mean Debian policy-abiding in the sense of "signed by a Debian developer in the Debian WoT" then no, but that's not something you could ever do automatically. But for the rest, I've done all the individual pieces before: it is trivial to generate a .deb from a maven pom and put it in a debian repository, it's trivial to do some operation on all the dependencies of a maven project, and it's trivial to hook something into a maven repository to happen whenever a new artifact is uploaded. You absolutely could do this if you wanted to, and it wouldn't be more than a few days' work. (Of course it wouldn't provide any value, which is why no-one does it).
    - mercurial 12y ago
      If they are not public, that's obviously not the same thing, though you're still going through a lot more complexity than "here is this .war, put it on the server and reload the webapp".
jkyle 12y ago
> You cannot reasonably expect developers to package and maintain all their dependencies properly. Why not? This is exactly what developers are expected to do. Every developer must manage dependencies for their application to work. What you mean is they can't be reasonably expected to do it well. In most situations, this is truly a trivial amount of investment relative to the overall cost of developing and maintaining an application. There are ecosystems which make the task easier or more difficult/annoying, but that cost should be accounted for when choosing which development platform to use.
- mercurial 12y ago
  > In most situations, this is truly a trivial amount of investment relative to the overall cost of developing and maintaining an application. I wouldn't say that creating and owning packaging for, say 50 libraries (assuming you only deploy to a single platform) represents a "trivial amount of investment" for a standard small developer team.
  - jkyle 12y ago
    Honestly, if a particular development environment for a project required tracking 50 libraries not supported by any distro community and my development team was so small that I couldn't do that in a sane manner... I might reevaluate the suitability of that particular language for the project. On a side, it only takes marginally more time to build a package for a distro as it does to build the package by itself. If you've already got the build done, 3 experienced guys could knock out 50 packages in a week. Inexperienced (in this task), but competent, devs should be able to do it in 2 weeks.

rlpb 12y ago

> You cannot reasonably expect developers to package and maintain all their dependencies properly. I think that this is a good point, but it all comes down to quality control. You wouldn't accept a new dependency into your project if it is buggy or has a bad API. So why is bad packaging, a hacked-up build system or inability to build from an auditable source considered acceptable in many communities today?

mercurial 12y ago
I don't think that's acceptable, but ranting and ignoring the underlying issue doesn't help.

mike_hearn 12y ago

Maven packages aren't actually unsigned either. They're downloaded over SSL and to get into Maven Central you need to sign with a GPG key. The problem is that you normally cannot find a path to the developers through the web of trust, of course, but that's not Maven's fault. That's the fault of the web of trust (more accurately called "handful of strings of trust"). Debian/Red Hat code signing doesn't prove very much either. All it proves is that the package came from Debian or Red Hat. But did they modify the software along the way, doing some kind of MITM attack on the upstream developers? Quite possibly! At least with Maven you don't have that problem.

danieldk 12y ago
The problem is that you normally cannot find a path to the developers through the web of trust, of course, but that's not Maven's fault. It is Maven's vault. Debian could have taken the same approach, but instead they have decided to vet prospective developers for a few years, and use one signing key for package indexes. As a result, in Debian: - It is feasible to actually check packages, because you don't need a large WoT. - You know that the maintainer of a package was a least vetted for some time before they could put anything in the archive. With Maven: - It's infeasible to check the signatures, since nearly no one has a complete enough WoT. - Anyone can submit a library, no vetting necessary. - Maven does not check signatures by default. So, basically the only thing you can do in Maven is hand-pick a small set of libraries. Verify them in some way and stick to specific versions, putting their checksums in your POM. Unfortunately, as the article already touches upon, too many Java libraries pull in half of the internet, so it may not be very practical.
- mercurial 12y ago
  > It is Maven's vault. Debian could have taken the same approach, but instead they have decided to vet prospective developers for a few years, and use one signing key for package indexes. Yes. But this creates a much higher barrier to entry. As usual, it is a trade-off, but it is obvious that with a Debian-like system, the number of packages on Maven/CPAN/Pypi/Rubygems would be considerably smaller.

sagichmal 12y ago

> You cannot reasonably expect developers to package and > maintain all their dependencies properly. What? With appropriate tooling, of course you can.

deleted 12y ago
[deleted]
mercurial 12y ago
I don't know any tooling that turns (recursively) a Maven pom file into a Debian repository of Debian policy-abiding .debs, which are magically updated when the pom file changes.
- lmm 12y ago
  If you mean Debian policy-abiding in the sense of "signed by a Debian developer in the Debian WoT" then no, but that's not something you could ever do automatically. But for the rest, I've done all the individual pieces before: it is trivial to generate a .deb from a maven pom and put it in a debian repository, it's trivial to do some operation on all the dependencies of a maven project, and it's trivial to hook something into a maven repository to happen whenever a new artifact is uploaded. You absolutely could do this if you wanted to, and it wouldn't be more than a few days' work. (Of course it wouldn't provide any value, which is why no-one does it).
  - mercurial 12y ago
    If they are not public, that's obviously not the same thing, though you're still going through a lot more complexity than "here is this .war, put it on the server and reload the webapp".

jkyle 12y ago

> You cannot reasonably expect developers to package and maintain all their dependencies properly. Why not? This is exactly what developers are expected to do. Every developer must manage dependencies for their application to work. What you mean is they can't be reasonably expected to do it well. In most situations, this is truly a trivial amount of investment relative to the overall cost of developing and maintaining an application. There are ecosystems which make the task easier or more difficult/annoying, but that cost should be accounted for when choosing which development platform to use.

mercurial 12y ago
> In most situations, this is truly a trivial amount of investment relative to the overall cost of developing and maintaining an application. I wouldn't say that creating and owning packaging for, say 50 libraries (assuming you only deploy to a single platform) represents a "trivial amount of investment" for a standard small developer team.
- jkyle 12y ago
  Honestly, if a particular development environment for a project required tracking 50 libraries not supported by any distro community and my development team was so small that I couldn't do that in a sane manner... I might reevaluate the suitability of that particular language for the project. On a side, it only takes marginally more time to build a package for a distro as it does to build the package by itself. If you've already got the build done, 3 experienced guys could knock out 50 packages in a week. Inexperienced (in this task), but competent, devs should be able to do it in 2 weeks.