Implementing enforce-victims-rule in wildfly builds
by David Jorm
Hi All
First I should introduce myself for those who don't know me, as I have not participated in wildfly dev discussions before. I am a security response engineer working for Red Hat, handling security patches for the commercial JBoss products. Recently some colleagues and I have been working on a tool called 'victims'. The victims tool aims to provide a canonical database of known-vulnerable JAR files, along with tools that allow developers and system administrator to determine whether their projects and systems contain any known-vulnerable JARs. The project's about page contains a more detailed explanation:
http://www.victi.ms/about.html
enforce-victims-rule is a maven plugin that walks the dependency tree at build time, and uses the victims database to check whether a project is including any known-vulnerable JARs as dependencies. The plugin is available on maven central:
http://search.maven.org/#artifactdetails|com.redhat.victims|enforce-victi...
Please see the README.md and sample app here for configuration details:
https://github.com/victims/victims-enforcer
I think there would be great value in incorporating this plugin into the wildfly POM(s). It can catch security flaws at build time, eliminating the need for much more work to ship patches for flaws later down the line. It is also designed such that it should not trigger any false positives. There will be false negatives where there are gaps in the database.
What do people think? Is this something you'd consider implementing?
Thanks
--
David Jorm / Red Hat Security Response Team
11 years, 10 months
Feature showcasing
by Jason Greene
One thing I think we should do for one of the Betas is to showcase some of the new features in WildFly 8. I am hoping for a volunteers to write up a blog or article by then which does a walkthrough of the feature.
So like as an example, the EE concurrency APIs are new to Java EE7, and it would be nice to show how they could be used with the Beta to build interest and momentum for the eventual final release.
Let me know if you are interested!
Thanks
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
11 years, 10 months
Package name
by Tomaž Cerar
Hi,
What should be package name for new stuff being added to WildFly?
org.wildfly.<subsystem-name>
or
org.wildfly.as.<subsystem-name>
or something else?
I would go for org.wildfly.<subsystem-name>
this mostly applies to new subsystems and as we agreed we won't rename
packages for existing code until it break compatibility.
--
tomaz
11 years, 10 months
SDDS (Silly Deployment Detector Subsystem)
by Nicklas Karlsson
(I know there has been some discussion on the topic (old community AS7-dev
postings, IRC-chat with Tomaz Cerar etc)
Hanging around the forums, I've noticed that a frequent source of
hard-to-debug deployment problems and other non-linear-behavior is that
people often try to deploy archives with conflicting dependencies (various
EE APIs/impls already on the AS, JDBC drivers, maven plugins, you name it).
Would it be worthwhile to implement a deployment processor (disabled by
default) that would act as a helpful bouncer for the deployment archive? We
could have a simple isSane(Archive) interface or something and people could
write their own implementations (that would be picked up through the java
services system or listed explicitly in some module?). Default
implementation that come to mind is
* Blacklisted packages (using Tattletale to warn users if they are bundling
e.g. EE impls/APIs)
* Version limiter (using Tattletale to warn if deployment contains too old
version of lib, e.g. Spring)
* Unused libs (using Tattletale to warn if deployment contains unused jars)
* Server provided libs (using Tattletale and JBoss Modules) to show which
dependencies could be handled by a server module dependency)
I'm not sure JBoss Modules contains any "directory" for
which-modules-provides functionality but I guess the module root could be
scanned and the resources indexed or something. Performance would not be an
issue because it's still going to be faster that a user playing around with
dependencies for days.
Thoughts?
--
Nicklas Karlsson, +358 40 5062266
Vaakunatie 10 as 7, 20780 Kaarina
12 years
Maven central repo sync
by Martin Kouba
Hi All,
is there a plan to sync WildFly artifacts (e.g. arquillian container)
with maven central?
Thanks
Martin
--
Martin Kouba
JBoss Quality Assurance Engineer
CDI TCK lead
Red Hat, Czech Republic
12 years
Cannot load module alias defined for root deployment
by Thomas Diesler
Folks,
currently we allow an arbitrary module alias to be defined with a deployment/subdeployment in jboss-deployment-structure.xml. The ServiceModuleLoader will however only accept module identifiers that have the 'deployment.' prefix.
I believe the 'deployment.' prefix is an unnecessary constraint for deployed module aliases. Deployments should be able to define any alias. This would allow for a deployment to get 'promoted' to a system module without breaking clients. A module alias should be unique, if a deployment defines an alias of an already existing module it should fail. System modules cannot have dependencies on deployment modules.
This change, provides a fallback in the ServiceModuleLoader that allows deployment modules to be loaded by their alias even if they don't have the 'deployment.' prefix. Unless I'm mistaken it only applies to inter deployment dependencies.
What do you think?
cheers
--thomas
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
12 years
Windows Batch Scripts
by James R. Perkins
Hello All,
There was an issue found with the Windows batch scripts if the
JBOSS_HOME path had a space or a ) in it. I created a fix and PR to fix
the issue [1].
If anyone has any good or better ideas on how to make this cleaner
please let me know. We are toying with the idea of just using an EXE
instead of batch scripts, but any input from someone with more Windows
batch scripting experience than me is welcome.
[1]: https://github.com/wildfly/wildfly/pull/4520
--
James R. Perkins
JBoss by Red Hat
12 years
Re: [wildfly-dev] SDDS (Silly Deployment Detector Subsystem)
by Rebecca Searls
comment on the original post.
>
> I think such a tool is a good stop gap measure but in general I think our
> perspective on this is all wrong. We have a great modular framework and
> isolated classloading. Its a framework that can support applications
> running
> different lib versions on it. Why not leverage that more?
>
> It's the changes to the server framework implementation that seems to
> always
> cause the most pain in moving an application from one server version to
> another.
> AS7 is a case in point. Providing a new improved framework is a good thing
> but why not provide an infra-structure (module) along with it to enable the
> move
> from the previous to the current seamless? Why make the customer do so
> much
> hard work?
>
> We've all seen the forum discussion where a user is attempting to migrate
> their
> AS 4 app lock stock and barrel to AS 7 and ask how to resolve related
> errors?
> I too have scratched my head and asked, "why would he ever want to do
> that".
> Well, the user has put in a lot of man hours writing that app, fixing bugs,
> and
> making it stable. He does not want to take the risk of introducing any new
> bugs with changes. He does want to write his new code to the current
> standard
> and run it in the current environment and he wants a single server
> environment
> to do it in.
>
> I've always envisioned JEE implementations to be an environment much like
> an
> OS. When I update my OS I don't have to alter any of the apps I'm running.
> I don't have to redeploy them or reconfigure them in any way. It just
> works.
> I expect the same of my JEE implementations, and to date I've been
> disappointed
> by all the vendors.
>
>
> I think the framework provided in AS 7 and WildFly empowers us to provide
> an
> JEE environment that supports that AS 4 app running unaltered in WildFly. I
> think there a number of functions that can and should be *retrofited* to
> WildFly.
> The Hibernate 3 module is an example of this. An AS4/AS5 server config
> loader module is another. Support for the predecessors of HornetQ and
> Infinispan
> are others.
>
> As we move forward with WildFly and future versions I would argue we need
> to
> design seamless support for prior versions of the components and provide
> backward
> compatibility not just at the JEE api level but the server framework
> implementation
> level. (Treat it like an OS)
>
>
>
12 years
Re: [wildfly-dev] SDDS (Silly Deployment Detector Subsystem)
by Rebecca Searls
comment on the original post.
>
> I think this would be a very valuable tool. Providing it as a CLI cmd
> would
> make it easist to use. Being able to evaluate the dependencies during
> deployment
> would be the most helpful. The user can run it as a deployment *lint* as
> Scott
> noted or as a *dry-run* before actually deploying the app. As Steve
> suggests
> it should report on the class loading env of each part of the deployment,
> and
> check for version issues and the like.
>
> Ales Justin has a utility that will help with module dependenise analysis
> and
> reporting see https://github.com/alesj/moduledeps. I've used this in
> conjuction
> with tattletale to identify deployed archive dependencies on AS 7 modules
> as well
> as missing missing classes.
>
>
12 years
