>
>  Well, normally I am happy, if someone contributes code, but here I
> wonder, why suddenly an alternate implementation is presented to the
> existing one, without further notice before, that you want to work on the
> stuff or which requirements were not met with the existing code.
> You implemented actually a slightly different approach than that what we
> have in trunk. We have similar possibilities to allow/deny types.
> Configuration will follow our standard pattern using the XStream facade.
> Documentation is not finished and trunk has to be merged into the 1.4.x
> branch, but that's done as soon as possible.


Hi Jorg,

I wanted to provide a little more color on Rich's email. We evaluated
several different ways to patch this issue, including changes to Nexus and
Nexus' Restlet Bridge module. In the end, due simply to the fact that of
all the 2.x versions of Nexus, the version of xstream had the least
variation, we opted to build a patch there. This allowed us to have a
single patch that fixed all 2.x versions of Nexus, instead of several
different Restlet Bridge patches and/or a whole bunch of Nexus patches.

Obviously due to the nature of the vulnerability we needed to find a way to
patch the issue internally which precluded a more open collaborative
approach that would have been preferred.

We wanted to post this code as a heads up in case it is useful to the
project or as inspiration to other users, but it was never the intention or
expectation that this was going to solve a more generic issue for others as
a patch to be consumed directly into xstream since we were aware that your
team was already implementing a similar solution.

I hope that helps.

--Brian

Reply via email to