Re: Maven GroupID authority

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Maven GroupID authority

Manfred Moser-4
From the very start of the work on the module system and throughout the work people from the Maven project have been involved.

There was never a willingness to create any sort of enforcement.. only a request to the community to do the right thing

From my point of view the Maven project can not do anything really.

With binary repositories all over the place that have very little to no enforcement what happens in Maven Central can at best be a good example. At worst a system that everyone avoids..

Things like github binaries, dockerhub, npmjs, bintray and many others have very little to no guidance or enforcement ...

The burden lies with the user not to be cheated.

Manfred

PS: and the cynic in me says that there are plenty of "open source security" companies out there that want to "help" you and provide tooling to organize the mess, so they of course have very little to no interest to have clear ownership and rules in repositories... Maven Central is really the only place with some real rules.

Jonathan Valliere wrote on 2020-02-13 20:28 (GMT -08:00):

> Java modules is going to compound this problem we already have.  If
> projects can't get on board with correctly structuring their
> GroupID/Artifacts then why would they use good naming conventions for the
> Modules?  Without good naming conventions, the risk of collisions
> increases.  Manfred's referenced problem, of having multiple versions of
> the same dependency in the same classpath, is only going to become
> impossible with Java Modules.
>
> Maven is at an optimal position within the community to prevent module
> naming from going haywire and becoming useless.  I believe these two issues
> are intrinsically linked.
>
> On Thu, Feb 13, 2020 at 10:38 PM Manfred Moser <[hidden email]>
> wrote:
>
>> Agreed ... which is why no one ever went down that road in the last
>> decade...
>>
>> Sander Verhagen wrote on 2020-02-13 19:35 (GMT -08:00):
>>
>> > Hi, y'all. (Disclaimer: I may not completely understand you're
>> proposing.) I
>> > wonder what problem you are really trying to solve. People by now have
>> lost the
>> > absolute expectation that the groupId is authoritative or certified in
>> any way.
>> > And the way that projects get moved between owners, without breaking
>> dependency
>> > resolution, would become a nightmare when it'd require a change to
>> groupIds.
>> > Also, please don't force projects to change their groupId/artifactId
>> combos. We
>> > are still struggling with dependency issues because of having multiple
>> versions
>> > of the (essentially) same dependency on our classpath, because a
>> > groupId/artifactId got changed (sometimes a decade ago). If you can drive
>> > better behavior going forward, all the better, but other than that, and
>> while I
>> > also like it when the world is nicely organized (groupId/artifactId),
>> there
>> > seems little to win here (and a lot to loose).
>> >
>> > Best regards, Sander.
>> >
>> >
>> >
>> > Sander Verhagen
>> > [  [hidden email]<mailto:[hidden email]>  ]
>> >
>> > On 13/02/2020 19.28, Jonathan Valliere wrote:
>> >
>> > Is there any kind of planned timeline to force compliance against old
>> > projects?
>> >
>> > For example:
>> >
>> >   - Force compliance
>> >   - Provide symlinks for backwards compatibility for a limited period of
>> >   time (1 year)
>> >   - Update Maven clients to provide warnings for symlinks during
>> >   builds/tests/etc
>> >
>> >
>> > On Thu, Feb 13, 2020 at 10:23 PM Manfred Moser
>> > <[hidden email]><mailto:[hidden email]>
>> > wrote:
>> >
>> >
>> >
>> > This is a left over from bad choices made decades ago. Now Maven Central
>> > has well documented criteria ... very contrary to nearly all other binary
>> > repos..
>> >
>> >
>> > https://central.sonatype.org/pages/ossrh-guide.html
>> >
>> > https://central.sonatype.org/pages/requirements.html#correct-coordinates
>> >
>> > And the videos linked on the site in which I explain more as well.
>> >
>> > Manfred
>> >
>> >
>> > Jonathan Valliere wrote on 2020-02-13 17:06 (GMT -08:00):
>> >
>> >
>> >
>> > I have been growing concerned about the process of allowing the creation
>> >
>> >
>> > of
>> >
>> >
>> > GroupIDs, within the Maven Central repository, which do not adhere to the
>> > naming guidelines. i.e. the GroupID must belong to a unique domain name
>> > controlled by the project owner.
>> >
>> > Even within the Apache family, there is no consistent naming enforcement.
>> > The project I belong to, org.apache.mina adheres to the conventions but
>> > many others do not.  Apache Commons for example uses a different GroupID
>> > for almost every sub-project within its scope.  Many of them simply
>> > starting with the word "commons" instead of "org.apache.commons".  Does
>> >
>> >
>> > the
>> >
>> >
>> > PMC have any ideas on how to combat this?
>> >
>> > Cheers,
>> > Jon
>> >
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail:
>> > [hidden email]<mailto:[hidden email]
>> >
>> > For additional commands, e-mail:
>> > [hidden email]<mailto:[hidden email]>
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven GroupID authority

Elliotte Rusty Harold
Changing group IDs of existing projects is a very bad idea. Not only
does this break too many projects to count that are in production
today. It also introduces diamond dependencies and weird classpath
issues into projects because the same classes can now be pulled in
from multiple artifact jars. In Java 9+ compiles the breakage would
early. immediate, and complete though still hard to debug and work
around. In Java 8-, the breakage could be subtle and unnoticed. See
https://jlbp.dev/JLBP-6.html for more details.

There are efforts underway to improve the provenance and vouching of
open source artifacts to avoid issues like the ones that affected NPM:
https://www.csoonline.com/article/3324599/hacker-adds-malicious-bitcoin-stealing-code-to-popular-javascript-library.html

However in many ways Maven is already ahead of the curve here, and
much better than it was 15 years ago. I'm not sure enforcing group IDs
as domain names, even if we could do that, would materially improve
our security posture.

On Thu, Feb 13, 2020 at 10:28 PM Jonathan Valliere
<[hidden email]> wrote:

>
> Is there any kind of planned timeline to force compliance against old
> projects?
>
> For example:
>
>    - Force compliance
>    - Provide symlinks for backwards compatibility for a limited period of
>    time (1 year)
>    - Update Maven clients to provide warnings for symlinks during
>    builds/tests/etc
>
>
> On Thu, Feb 13, 2020 at 10:23 PM Manfred Moser <[hidden email]>
> wrote:
>
> > This is a left over from bad choices made decades ago. Now Maven Central
> > has well documented criteria ... very contrary to nearly all other binary
> > repos..
> >
> >
> > https://central.sonatype.org/pages/ossrh-guide.html
> >
> > https://central.sonatype.org/pages/requirements.html#correct-coordinates
> >
> > And the videos linked on the site in which I explain more as well.
> >
> > Manfred
> >
> >
> > Jonathan Valliere wrote on 2020-02-13 17:06 (GMT -08:00):
> >
> > > I have been growing concerned about the process of allowing the creation
> > of
> > > GroupIDs, within the Maven Central repository, which do not adhere to the
> > > naming guidelines. i.e. the GroupID must belong to a unique domain name
> > > controlled by the project owner.
> > >
> > > Even within the Apache family, there is no consistent naming enforcement.
> > > The project I belong to, org.apache.mina adheres to the conventions but
> > > many others do not.  Apache Commons for example uses a different GroupID
> > > for almost every sub-project within its scope.  Many of them simply
> > > starting with the word "commons" instead of "org.apache.commons".  Does
> > the
> > > PMC have any ideas on how to combat this?
> > >
> > > Cheers,
> > > Jon
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >



--
Elliotte Rusty Harold
[hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven GroupID authority

Jonathan Valliere
In reply to this post by Manfred Moser-4
Christian,

Those references are amazing and prove my point about the need to improve
the process to prevent imposters and other types of name collisions.


On Fri, Feb 14, 2020 at 1:35 AM Christian Stein <[hidden email]> wrote:

> On Fri, Feb 14, 2020 at 6:37 AM Manfred Moser <[hidden email]>
> wrote:
>
> > From the very start of the work on the module system and throughout the
> > work people from the Maven project have been involved.
> >
> > There was never a willingness to create any sort of enforcement.. only a
> > request to the community to do the right thing
> >
> > From my point of view the Maven project can not do anything really.
> >
> >
> Except for doing some related sanity checks, like [0]. (-:
> As of today, there are already 13263 artifacts at Maven Central with
> invalid module names, due to not checking the "Automatic-Module-Name"
> manifest attribute.
> More details at [1], the daily-updated index of "unique" Java modules
> published to Maven Central.
>
> Perhaps "we" should guide users to adhere to name their Maven artifacts
> like the Java module it contains. And start the artifact name with the
> Group ID...
> More details about this naming convention proposal at [2].
>
> Cheers,
> Christian
>
> [0] https://issues.apache.org/jira/browse/MSHARED-773
> [1] https://github.com/sormuras/modules#suspicious-modules
> [2]
>
> https://sormuras.github.io/blog/2019-08-04-maven-coordinates-and-java-module-names.html
>
Reply | Threaded
Open this post in threaded view
|

Re: Maven GroupID authority

Elliotte Rusty Harold
In reply to this post by Elliotte Rusty Harold
On Fri, Feb 14, 2020 at 5:12 PM Hervé BOUTEMY <[hidden email]> wrote:
>
> Le vendredi 14 février 2020, 14:11:07 CET Elliotte Rusty Harold a écrit :
> > Changing group IDs of existing projects is a very bad idea.
> there is relocation strategy:
> https://maven.apache.org/guides/mini/guide-relocation.html
> but AFAIK, it is under-tested...
>

Interesting. How does that affect dependency mediation? That is, if an
old artifact (pre relocation) and a newer artifact both appear in the
dependency graph will both be added to the classpath? Or does Maven
treat them as the same and pick the one it sees first?



--
Elliotte Rusty Harold
[hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven GroupID authority

Elliotte Rusty Harold
In reply to this post by Elliotte Rusty Harold
On Sat, Feb 15, 2020 at 1:29 PM Jonathan Valliere
<[hidden email]> wrote:
>
> If Central indicated a redirect/reallocation then there would never be the
> duplicate classpath problem because Maven would resolve it internally.  The
> redirect then warns the user of the redirect and to update the pom.
>

I really don't think Maven works like that, but feel free to point me
to the code in Github that proves me wrong.

--
Elliotte Rusty Harold
[hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven GroupID authority

Jonathan Valliere
Maybe we need to rework how this functionality works.  It should be
essentially a symlink with a warning message within the resolver so they
both resolve to the same artifact.

On Wed, Feb 19, 2020 at 8:58 AM Anders Hammar <[hidden email]> wrote:

> In real practice it doesn't work well though, as someone already brought
> up. It can result in duplication of libraries on the class path (the same
> library under different groupId).
>
> /Anders (mobile)
>
> Den ons 19 feb. 2020 14:52Elliotte Rusty Harold <[hidden email]>
> skrev:
>
> > I set up some simple projects and tested this manually. As best I can
> > determine, relocation does work as one would hope, at least in Maven
> > and M2E. (No idea about Gradle or Ivy.)
> >
> > The documentation should probably be rewritten because it assumes you
> > can change published pom.xml files, which isn't true on Maven central.
> >
> > On Mon, Feb 17, 2020 at 3:36 PM Hervé BOUTEMY <[hidden email]>
> > wrote:
> > >
> > > you can test with
> > > https://repo.maven.apache.org/maven2/ant/ant/1.7.0/ant-1.7.0.pom
> > >
> https://repo.maven.apache.org/maven2/javax/xml/jaxrpc/1.1/jaxrpc-1.1.pom
> > >
> >
> https://repo.maven.apache.org/maven2/javax/xml/jaxb-api/1.0.1/jaxb-api-1.0.1.pom
> > >
> > > testing relocation was on my todo list for years, but I never really
> test
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le dimanche 16 février 2020, 15:18:17 CET Elliotte Rusty Harold a
> écrit :
> > > > On Sun, Feb 16, 2020 at 2:35 AM <[hidden email]> wrote:
> > > > > see:
> > > > > -
> > > > >
> >
> http://maven.apache.org/ref/3.6.3/maven-model/maven.html#class_relocation
> > > > > - https://maven.apache.org/guides/mini/guide-relocation.html
> > > >
> > > > The guide to relocation seems to assume a lot more access and control
> > > > to the repo than is the case with public repositories like Maven
> > > > Central. I'm not sure it's actually possible to follow these steps
> > > > today, though perhaps that could be changed.
> > > >
> > > > I'd still like to see the code in the repo that implements support
> for
> > > > this or, better yet, a sample project that demonstrates relocation is
> > > > possible.
> > > >
> > > > If this does work, I can see a lot of use cases for it, but I'm
> > > > currently working with the assumption it is not.
> > >
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> >
> >
> > --
> > Elliotte Rusty Harold
> > [hidden email]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
--

CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally protected
from disclosure.