I wouldn't toss-off the idea that providing a POM can't be a security risk. It *depends* what you are coding and what assets are being protected. True, there is "a bigger problem at hand if someone knowing an internal server is a security risk", but even if there's no risk today, the risk can be tomorrow. That's how attackers work: pieces of puzzles at a time. Anyone trained in security would understanding this perspective. But if your assets are minimal/worthless, who cares anyway?
On Tue, Nov 19, 2013 at 9:07 AM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > I used (former employer) use a process akin to shade to publish "clean" > poms at an alternative groupId... it was OK but a bit of a pain > > > On 19 November 2013 14:47, Benson Margulies <bimargul...@gmail.com> wrote: > > > The security concern here is nonsense, at best it's 'security by > > obscurity'. > > > > However, there's a better reason to clean off the poms that happened > > to us. Our product poms use our internal parent POM, which encodes our > > chosen options for all the plugins we use at build time, and our > > infrastructure (e.g. Sonar). It makes no sense to distribute that POM, > > but without it, our poms don't work. So, our customers _asked us to > > remove our poms_ from the metadata, to make it _easier for them to > > push our jars to their repository manager_. > > > > The ideal solution would be for us to put 'clean' poms in the metadata > > that declared only dependencies and no parent. However, I am unaware > > of any way to get maven to automatically generate such things. Is > > anyone else? > > > > > > On Tue, Nov 19, 2013 at 5:57 AM, Adam Retter <adam.ret...@googlemail.com > > > > wrote: > > > I would of thought it would be better practice to keep a clean > > > separation between your pom.xml and settings.xml where any sensitive > > > server information goes in your settings.xml > > > > > > However, if you are worried that someone knowing a URL to an internal > > > server is a security risk, then I would suggest you have bigger > > > problems with your security infrastructure. > > > > > > As a developer, it it fantastically useful to have the pom's available > > > even when working with closed (or non-open) source products. > > > > > > On 19 November 2013 02:16, Paul Benedict <pbened...@apache.org> wrote: > > >> My personal opinion for closed-source products is not to include the > > >> generated POM. If someone somehow stole your proprietary jar, the POM > > might > > >> help to find out where to steal the rest -- URL locations and custom > > >> properties, in particular. > > >> > > >> > > >> > > >> > > >> On Mon, Nov 18, 2013 at 7:46 PM, Tang Kin Chuen <kct...@big2.net> > > wrote: > > >> > > >>> Same here. > > >>> > > >>> Just wondering if it's common practice for close sourced products to > > remove > > >>> maven manifest info from jars... something we cannot search in open > > source > > >>> codes! :-) > > >>> > > >>> I am hoping to get an authoritative reference that says it's OK to > > leave it > > >>> there. > > >>> On Nov 19, 2013 9:40 AM, "Adam Retter" <adam.ret...@googlemail.com> > > wrote: > > >>> > > >>> > I would be interested to know what your peers perceive the security > > >>> > concerns as being? > > >>> > > > >>> > On 19 November 2013 01:22, Tang Kin Chuen <kct...@big2.net> wrote: > > >>> > > Hi guys, > > >>> > > > > >>> > > Are there any security concerns in leaving the default pom > file(s) > > in > > >>> > > meta-inf of generated jars for "commercial products"? > > >>> > > > > >>> > > I find it useful to leave it there for troubleshooting purpose, > > >>> thinking > > >>> > > that there is not much security concerns but my peers are > thinking > > >>> > > otherwise. > > >>> > > > > >>> > > I would like to seek some advise/opinions on this topic. > > >>> > > > > >>> > > Cheers! > > >>> > > > >>> > > > >>> > > > >>> > -- > > >>> > Adam Retter > > >>> > > > >>> > skype: adam.retter > > >>> > tweet: adamretter > > >>> > http://www.adamretter.org.uk > > >>> > > > >>> > > --------------------------------------------------------------------- > > >>> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > >>> > For additional commands, e-mail: users-h...@maven.apache.org > > >>> > > > >>> > > > >>> > > >> > > >> > > >> > > >> -- > > >> Cheers, > > >> Paul > > > > > > > > > > > > -- > > > Adam Retter > > > > > > skype: adam.retter > > > tweet: adamretter > > > http://www.adamretter.org.uk > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > -- Cheers, Paul
