Well for the security issue: this is trivially solved since we own the
parser and the related implementation so we can enforce the include is in
project.basedir of the root module.
About solving an issue:
> If we only allow importing other files that reside in the same
repository, then those bits can just as well be in the pom.xml itself.
I'm in this case but can't solve it without fatty extensions. Here is the
case:
root
| - servers
| |- base-server
| |- my-server1
| `- my-server2
` - libs
|- lib1
`- lib2
I want my-server1 and my-server2 (similarly for libs) to have ~80 lines of
pom in common (build.plugins + profiles) and it would be convient to be
able to import .mvn/includes/server.build.xml or so.
How do I do: "those bits can just as well be in the pom.xml itself".
Side note: you can think restructuring the project (don't think it is a
good option but could be) but some plugins don't have a skip property or
skip pom modules so it does not work.
Include option would be very convenient there.
Indeed I can have a meta-pom with a pre-processor which generates actual
runtime poms but I don't like much to duplicate the root build files (I
would have a root one for the preprocessor and another root for maven
itself) and have to not rely on the default CLI to build (maven or gradle
these days).
I can solve it quite easily with an extension but I can't put it in the
project - and the structure and config is quite specific - so overall, even
if copy/paste works, I'm not super happy with what I tried today and
include was exactly what I need.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mer. 17 nov. 2021 à 17:19, Maarten Mulders <[email protected]> a
écrit :
> Gary beat me to it :-) I would be hesitant to add support for XML
> Entities or XML Includes. Both have proven themselves to be a frequent
> source of security issues ([1], [2] and probably a lot more). The
> problem is that XML parsers typically do not allow selective includes,
> so if we want to prevent anything from outside the project folder we
> would probably have to code that ourselves.
>
> Apart from that, I feel it does not solve a real-world problem our users
> are facing. If we only allow importing other files that reside in the
> same repository, then those bits can just as well be in the pom.xml itself.
>
>
> Thanks,
>
> Maarten
>
>
> [1] https://en.wikipedia.org/wiki/Billion_laughs_attack
> [2] https://en.wikipedia.org/wiki/XML_external_entity_attack
>
> On 17/11/2021 17:17, Gary Gregory wrote:
> > The parsers I've seen don't "prevent" XI, you have to enable the feature;
> > note that some folks don't like DTD processing and XI for security
> reasons.
> >
> > Gary
> >
> > On Wed, Nov 17, 2021, 09:17 Romain Manni-Bucau <[email protected]>
> > wrote:
> >
> >> Hi all,
> >>
> >> Almost everything is in the subject: any reason our pom parser prevents
> to
> >> use XML includes (https://www.w3.org/TR/xinclude/)?
> >>
> >> It would be very convenient to import some part of pom definition from
> >> .mvn/ or a project folder (indeed remote/insecured imports would be
> >> forbidden).
> >>
> >> Just a xpp3 limitation or something deeper?
> >> Do we want to support it?
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> >> <https://rmannibucau.metawerx.net/> | Old Blog
> >> <http://rmannibucau.wordpress.com> | Github <
> >> https://github.com/rmannibucau> |
> >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >> <
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >>>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
