Digitally signed modules

[KevinPas]

Node's npm presents a huge security risk.  These is no way to know what is being downloaded or who wrote all of the sub packages.

The jvm has better built in security but is vertx able to take advantage of it when loading modules?  Is there a way to require that each module has been digitally signed?

[dgo...@squaredfinancial.com]

On Thursday, 21 August 2014 17:48:58 UTC+1, KevinPas wrote:

Node's npm presents a huge security risk.  These is no way to know what is being downloaded or who wrote all of the sub packages.

The jvm has better built in security but is vertx able to take advantage of it when loading modules?  Is there a way to require that each module has been digitally signed?

(Disclaimer: I'm just a vertx user, certainly don't speak for the project)
 
To the best of my present knowledge module functionality / "vertx platform" is officially just going away in vertx 3. So while in principle some sort of built-in checking of sigs on vertx 2 module zips might be a good thing, there may not be much motivation to implement it at this stage.

So speculating about the vertx 3 module-less world:

If you're handling deps and things more statically in the absence of modules, then, well, you can check signatures (when they exist in some form) statically with the relevant tools. There are already maven jarsigner and pgpverify plugins.  Other ecosystems may well have their  signing infrastructures too  (e.g. discussion still seems to be ongoing in python land, right now packages on pypi can (and sometimes do) already have gpg sigs, but tools also need to check them...).

OTOH, if you need/want more dynamic functionality, well I suppose at least vertx 3 having no platform/modules at all means that there aren't "too many cooks" if you do switch to some other modularity system instead of vertx 2 platform (which is different to abandoning vertx use altogether).  e.g. Existing osgi-ish containers may check bundle sigs, like http://help.eclipse.org/luna/topic/org.eclipse.platform.doc.isv/guide/bundle_security.html

In both cases, I guess vertx ends up washing its hands on the issue - fairly shortly, it's just going to be up to something else.

Another thing to note (and back to the present): bear in mind you don't have to keep the default repos.txt that's out-of-box in vertx 2. You can e.g. point it only at a more tightly-controlled in-house maven remote repo only, or just the maven local repo, and be a bit careful about what's in them.

[Julien Viet]

Hi,

I would like to shed some clarifications on Vert.x modules from my perspective (i.e as Vert.x 2 user and Vert.x 3 developer).

I see the Vert.x 2.x module system made of :
- deployment of verticle source file or zip files
- class loader isolation
- repository system (delegated to Bintray / Maven)

What has changed in Vert.x 3 ?

Vert.x 3 removed the repository system and zip file deployment and keeps the class loader isolation and the deployment of Verticles. It means that the repository system is delegated (by default) to the build system (Maven, Gradle, etc…).

So what happens if you need to deploy a Verticle in a jar file of your repository (let’s suppose you are using Maven): the Verticle is deployed you use its classname and Vert.x assumes the current classloader being able to load the resource, for instance:

before: vertx.deployModule(“my~module~1.0”);

now: vertx.deployVerticle(“java:my.Verticle”);

+

<dependency>
  <groupId>my</groupId>
  <artifactId>module</artifactId>
  <version>1.0</version>
</dependency>

One motivation for this seems to be the new Proxy stuff (that allows you to use a typed interface in front of a module using the event bus). If you use this feature (I’m saying *if* , this feature is optional) then you need the Proxy (it’s not only Java, it works for all languages, so you can a JS proxy for JS etc...) in your classpath which implies that the dependency has to be resolved *before* compilation by your build system and we fall in the use case of Vert.x 3.

That being said, I think (my opinion) I think a dynamic deployment system inside Vert.x is still useful (for instance I can deploy mod-web-server to serve some files, I don’t need a proxy!).

The good news is the new Vert.x verticle deployment provides more flexibility now. Basically now you provide a prefix when deploying something, for instance java:my.Verticle . The part after the prefix is completely opaque to Vert.x and will delegate it fully to the Verticle Factory. It means this can be anything you like.

I spend a couple of hours to make a proof of concept (https://github.com/vietj/vertx-maven-modules) of a “maven” verticle factory that loads a Verticle from the Maven repository at runtime and then deploys it with code like vertx.deployVerticle("maven:my:module:1.0”)

Last but not least, you can expect a Vert.x alpha/previous release in September, so you can use it and provide feedback. And you can be sure Tim will listen to you :-)

--
Julien Viet
www.julienviet.com

> --
> You received this message because you are subscribed to the Google Groups "vert.x" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

[Jordan Halterman]

Awesome Julien! Great explanation.

Sent from my iPhone

[Kevin Pastorino]

I'm not sure how to use Google Groups:  It has the appearance that it is going to reply to the previous entry instead of replying to the whole post.  But I want to thank everyone!

Anyway, first off, I view both node and vertx as awesome.

Maybe http://vertx.io/mods_manual.html could indicate at the top that 2 style is "deprecated" in version 3 and maybe a link to something like this post (I'm sure you have thousands of helpers sitting around doing nothing).

I almost dumped vertx for now so that I could get back to work on my client side javascript main concern.  But it looks worthwhile for me to spend some more time studying what was said here. I really want to use a javascript server & javascript db + javascript client. But need the security so probably back to java server (of some kind) & mySQL+ js client.

I'll start another post if there's more q's.

Thanks much to all.

You received this message because you are subscribed to a topic in the Google Groups "vert.x" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vertx/QDOWwkjqKX8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vertx+un...@googlegroups.com.

[dgo...@squaredfinancial.com]

Ah, interesting, thanks!!  (That .setExtraClasspath() was a missing piece of the puzzle for me)

I'd already been speculating (but nothing implemented) about something like that (no honest I was - some things already use the langs/prefix subsystem in vertx 2 e.g. vertigo) though then went down a bit of an osgi rabbit hole - think e.g. an embedded felix and subcommands hanging off the prefix. (Regarding the latter, I guess things on a prefix should make sense in an actual programmatic .deployVerticle("prefix:blah") calls too, not saying the subcommand thing was a good idea. If one were full-on adopting osgi, may make sense to switch to one of the osgi containers/runtimes at the toplevel not the vertx starter anyway, and inside deploy verticle instances (since vertx 3 can do that...) retrieved from factory services. or something.)

You've also already been providing vertx 3 stack snapshots, of course...

[Tim Fox]

In Vert.x 3.0 applications are typically assembled at build time from different jars, e.g. using Maven, so that should handle the signing requirement, aiui.

On 21/08/14 17:48, KevinPas wrote:

Node's npm presents a huge security risk.  These is no way to know what is being downloaded or who wrote all of the sub packages.

The jvm has better built in security but is vertx able to take advantage of it when loading modules?  Is there a way to require that each module has been digitally signed?

[Tim Fox]

On 22/08/14 09:46, Julien Viet wrote:
> Hi,
>
> I would like to shed some clarifications on Vert.x modules from my perspective (i.e as Vert.x 2 user and Vert.x 3 developer).
>
> I see the Vert.x 2.x module system made of :
> - deployment of verticle source file or zip files
> - class loader isolation
> - repository system (delegated to Bintray / Maven)
>
> What has changed in Vert.x 3 ?
>
> Vert.x 3 removed the repository system and zip file deployment and keeps the class loader isolation and the deployment of Verticles. It means that the repository system is delegated (by default) to the build system (Maven, Gradle, etc…).
>
> So what happens if you need to deploy a Verticle in a jar file of your repository (let’s suppose you are using Maven): the Verticle is deployed you use its classname and Vert.x assumes the current classloader being able to load the resource, for instance:
>
> before: vertx.deployModule(“my~module~1.0”);
>
> now: vertx.deployVerticle(“java:my.Verticle”);
>
> +
>
> <dependency>
> <groupId>my</groupId>
> <artifactId>module</artifactId>
> <version>1.0</version>
> </dependency>
>
> One motivation for this seems to be the new Proxy stuff (that allows you to use a typed interface in front of a module using the event bus). If you use this feature (I’m saying *if* , this feature is optional) then you need the Proxy (it’s not only Java, it works for all languages, so you can a JS proxy for JS etc...) in your classpath which implies that the dependency has to be resolved *before* compilation by your build system and we fall in the use case of Vert.x 3.
>
> That being said, I think (my opinion) I think a dynamic deployment system inside Vert.x is still useful (for instance I can deploy mod-web-server to serve some files, I don’t need a proxy!).
>
> The good news is the new Vert.x verticle deployment provides more flexibility now. Basically now you provide a prefix when deploying something, for instance java:my.Verticle . The part after the prefix is completely opaque to Vert.x and will delegate it fully to the Verticle Factory. It means this can be anything you like.
>
> I spend a couple of hours to make a proof of concept (https://github.com/vietj/vertx-maven-modules) of a “maven” verticle factory that loads a Verticle from the Maven repository at runtime and then deploys it with code like vertx.deployVerticle("maven:my:module:1.0”)

Nice feature :)