You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Matthieu Riou <ma...@offthelip.org> on 2008/09/17 00:49:04 UTC
Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
On Tue, Sep 16, 2008 at 2:10 PM, William A. Rowe, Jr.
<wr...@rowe-clan.net>wrote:
> Justin Erenkrantz wrote:
>
>> On Mon, Sep 15, 2008 at 11:13 AM, Emmanuel Lecharny <el...@gmail.com>
>> wrote:
>>
>>> Craig L Russell wrote:
>>>
>>>> -1
>>>>
>>>> I believe that allowing incubating releases to be treated as full Apache
>>>> releases diminishes the Apache brand and makes incubation disclaimers
>>>> moot.
>>>>
>>>> With Maven, it is too easy to depend on a release with transitive
>>>> dependencies on incubating releases without even knowing it. When the
>>>> incubating release subsequently is abandoned, blame will be cast widely,
>>>> including Apache itself.
>>>>
>>>> Considering that dependencies on incubating releases can be resolved by
>>>> explicitly adding an incubating Maven repository into your settings, I
>>>> don't
>>>> think that wide, mirrored, distribution is warranted.
>>>>
>>>> Craig
>>>>
>>> -1 too, for the same reasons.
>>>
>>
>> -1. Craig pointed out my objections as well. -- justin
>>
>
> Just so everyone understands this in context, the objection above is moot
> because...
>
> ...maven is a package deployment mechanism
>
Beg your pardon? I know that the homepage casts a wide net ("Maven is a
software project management and comprehension tool.") but in my book Maven
is used to build stuff (which happens to be almost exclusively Java). I
don't know of anybody who goes to actual users and tell them "here you go,
unzip that stuff there, set your JAVA_HOME and your MAVEN_HOME properly,
execute 'mvn install' and once all test cases pass you're golden".
Maven is a build tool. Users don't build, developers do. And developers
should know about licenses and disclaimers.
Cheers,
Matthieu
>
> ...developers who determine what to bundle into their package don't spend
> a whole lot of time explaining to users that something within their
> package is 'incubating' code, or 'patched/forked' code, or virgin
> original code
>
> ...the developer who deploys an app is either going to explain it contains
> an incubating artifact to their users, or they won't
>
> ...no matter if the developer bundles an incubating jar, or calls it up
> out of maven...
>
> The user has ***exactly*** the same experience.
>
> Presenting a user with a dialog "Package FOO requires the BAR.jar, an
> Apache Incubating Bar Project artifact, which[1] carries 'the'[2]
> disclaimer" will leave them utterly befuddled and is entirely worthless
> information in the context that they install package FOO (nevermind that
> the "actual" disclaimer appears to be non-existent in our release
> documentation).
>
> We permit GPL, commercial, virtual anything to be deposited into Maven
> if I understand correctly. WTF not incubation artifacts, in that light?
>
> Bill
>
> [1] alternately... "is a tasty beverage container"
> [2]
> http://incubator.apache.org/guides/releasemanagement.html#notes-disclaimer
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Posted by Davanum Srinivas <da...@gmail.com>.
Guess, you don't get the role of the incubator at all. ah well.
Also, no one here made the argument that the disclaimer is a license
or something for legal protection. So the arguments are moot.
thanks,
-- dims
On Wed, Sep 17, 2008 at 6:57 AM, Daniel Kulp <dk...@apache.org> wrote:
>
> I voted +1, but I personally think the vote is kind of irrelevant.....
>
> FACT: The stuff in the incubator repo are Apache releases. They had the 3
> binding +1 votes from the incubator IPMC members. They are releases.
>
> FACT: The stuff in the incubator repo is all Apache Licensed artifacts.
>
> FACT: Nowhere in the Apache License is there a requirement that the user has
> to read and accept the Incubator disclaimer prior to use.
>
>
> Given the above:
> If RedHat decided to put incubator artifacts in their repository without a
> click through "this is incubator code" disclaimer, we'd have no legal reason
> to say no. The Apache License allows them to do so.
>
> If Debian decided to put incubator artifacts in their repository without a
> click through "this is incubator code" disclaimer, we'd have no legal reason
> to say no. The Apache License allows them to do so.
>
> If the CPAN maintainers decided to put incubator perl modules into their
> repository without a click through "this is incubator code" disclaimer, we'd
> have no legal reason to say no. The Apache License allows them to do so.
>
> If repo maintainer XXXXX decided to put incubator perl modules into their
> repository without a click through "this is incubator code" disclaimer, we'd
> have no legal reason to say no. The Apache License allows them to do so.
>
> If Ivy/Builder/Ant/etc.... decided to create their own repository and wanted
> the incubator artifacts in it, we'd have no legal reason to say no. The
> Apache License allows them to do so.
>
> Thus:
> If the central maven repository maintainers (Maven PMC) decide to put
> incubator artifacts into their repository without a click through "this is
> incubator code" disclaimer, we'd have no legal reason to say no. The Apache
> License allows them to do so.
>
>
> Thus, to me, the vote is kind of pointless. Jukka (or other maven users)
> should just ask the Maven folks to start syncing the m2-incubator-repo dir
> off of people.apache.org. If the Maven PMC thinks that's in the best
> interest of THEIR community and users, they should go ahead and do it
> (obviously working with infrastructure to work out logistics to reduce load
> and such). The license that applies to all the artifacts in that repo
> certainly allows it.
>
>
> Thus, this vote really is about reducing the burden on the Maven PMC and on
> infrastructure. There is an auto-sync dir already setup. Should we use it
> or should they be separate which would require new syncs setup which would
> result in more processes/connections on people.apache.org, extra bandwidth
> used for those extra rsyncs, etc....
>
> If the incubator wants to go off to the board and legal and ask for a
> new "Apache Incubator License" that would require the click through, fine.
> But until then, lets actually follow the license that is currently being
> used.
>
> Anyway, thats my 2 cents worth. (caveat: it may not be worth 2 cents to you)
>
> :-)
>
> Dan
>
>
>
>
>
> On Tuesday 16 September 2008 6:49:04 pm Matthieu Riou wrote:
>> On Tue, Sep 16, 2008 at 2:10 PM, William A. Rowe, Jr.
>>
>> <wr...@rowe-clan.net>wrote:
>> > Justin Erenkrantz wrote:
>> >> On Mon, Sep 15, 2008 at 11:13 AM, Emmanuel Lecharny
>> >> <el...@gmail.com>
>> >>
>> >> wrote:
>> >>> Craig L Russell wrote:
>> >>>> -1
>> >>>>
>> >>>> I believe that allowing incubating releases to be treated as full
>> >>>> Apache releases diminishes the Apache brand and makes incubation
>> >>>> disclaimers moot.
>> >>>>
>> >>>> With Maven, it is too easy to depend on a release with transitive
>> >>>> dependencies on incubating releases without even knowing it. When the
>> >>>> incubating release subsequently is abandoned, blame will be cast
>> >>>> widely, including Apache itself.
>> >>>>
>> >>>> Considering that dependencies on incubating releases can be resolved
>> >>>> by explicitly adding an incubating Maven repository into your
>> >>>> settings, I don't
>> >>>> think that wide, mirrored, distribution is warranted.
>> >>>>
>> >>>> Craig
>> >>>
>> >>> -1 too, for the same reasons.
>> >>
>> >> -1. Craig pointed out my objections as well. -- justin
>> >
>> > Just so everyone understands this in context, the objection above is moot
>> > because...
>> >
>> > ...maven is a package deployment mechanism
>>
>> Beg your pardon? I know that the homepage casts a wide net ("Maven is a
>> software project management and comprehension tool.") but in my book Maven
>> is used to build stuff (which happens to be almost exclusively Java). I
>> don't know of anybody who goes to actual users and tell them "here you go,
>> unzip that stuff there, set your JAVA_HOME and your MAVEN_HOME properly,
>> execute 'mvn install' and once all test cases pass you're golden".
>>
>> Maven is a build tool. Users don't build, developers do. And developers
>> should know about licenses and disclaimers.
>>
>> Cheers,
>> Matthieu
>>
>> > ...developers who determine what to bundle into their package don't spend
>> > a whole lot of time explaining to users that something within their
>> > package is 'incubating' code, or 'patched/forked' code, or virgin
>> > original code
>> >
>> > ...the developer who deploys an app is either going to explain it
>> > contains an incubating artifact to their users, or they won't
>> >
>> > ...no matter if the developer bundles an incubating jar, or calls it up
>> > out of maven...
>> >
>> > The user has ***exactly*** the same experience.
>> >
>> > Presenting a user with a dialog "Package FOO requires the BAR.jar, an
>> > Apache Incubating Bar Project artifact, which[1] carries 'the'[2]
>> > disclaimer" will leave them utterly befuddled and is entirely worthless
>> > information in the context that they install package FOO (nevermind that
>> > the "actual" disclaimer appears to be non-existent in our release
>> > documentation).
>> >
>> > We permit GPL, commercial, virtual anything to be deposited into Maven
>> > if I understand correctly. WTF not incubation artifacts, in that light?
>> >
>> > Bill
>> >
>> > [1] alternately... "is a tasty beverage container"
>> > [2]
>> > http://incubator.apache.org/guides/releasemanagement.html#notes-disclaime
>> >r
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Davanum Srinivas :: http://davanum.wordpress.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Posted by Gilles Scokart <gs...@gmail.com>.
Just to clarify things, the artefact published on the apache maven
repository are signed (well, to be exact, most are signed. See [1]
for the current status)
However, maven doesn't [yet] validate the signature when downloading
the artefacts (ivy neither). See [2]
[1] http://people.apache.org/~henkp/repo/
[2] http://jira.codehaus.org/browse/MNG-2477
2008/9/17 Noel J. Bergman <no...@devtech.com>:
> Dan,
>
> It is a policy matter, not a legal one. And enforcing artifact signing
> would address this and other crucial, fatal, flaws in Maven's repository
> management.
>
> I still maintain that unless Maven makes swift strides to enforce signing,
> the ASF should ban the use of the Maven repository for all ASF projects, and
> go so far as to remove all of our artifacts.
>
> --- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Gilles Scokart
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Posted by Hiram Chirino <hi...@hiramchirino.com>.
Hi Noel,
If the problem your trying to solve with artifact signing is detect
and reject malicious artifacts that have been deployed to hacked
repository, then there is a simpler fix that is available today. Just
use the checksum plugin that I described here:
http://hiramchirino.com/blog/2008/08/new-checksum-plugin.html
Basically the plugin helps you maintain a checksum database of all
dependencies needed in the build which is part of the project source
code. It will validate that all downloaded dependencies match their
checksums before running the build. This way you can feel safe that
all those random artifacts downloaded by maven are the actual
artifacts that the project intended you to use.
On Wed, Sep 17, 2008 at 1:19 PM, Noel J. Bergman <no...@devtech.com> wrote:
> Dan,
>
> It is a policy matter, not a legal one. And enforcing artifact signing
> would address this and other crucial, fatal, flaws in Maven's repository
> management.
>
> I still maintain that unless Maven makes swift strides to enforce signing,
> the ASF should ban the use of the Maven repository for all ASF projects, and
> go so far as to remove all of our artifacts.
>
> --- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://open.iona.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Posted by Matthieu Riou <ma...@offthelip.org>.
On Thu, Sep 18, 2008 at 10:26 AM, Daniel Kulp <dk...@apache.org> wrote:
> On Thursday 18 September 2008 1:14:53 pm Davanum Srinivas wrote:
> > "but they cannot require third parties to not sync it into their
> > repos." --> Is this something Maven PMC is
> > thinking-about/voted-on/discussing? basically overriding the current
> > un-written policy of the incubator? Please let us know.
>
> Not yet. But my point is if Maven was NOT an Apache project, what COULD
> we
> do?
>
Just not build a repo at all? They could download and publish each of our
releases and there's nothing wrong about it. It's just about what kind of
practices *we* want to promote or discourage. It's just a judgment call,
which is why I guess the issue is so disputed. Some people don't care which
dependency they end up using, where it comes from, what its quality or
license are. Why not make the life of those lucky people easy? Some others
are very finicky about it, caring about licenses, restrictions, maturity,
etc... and would probably not use a tool like Maven in the first place as it
wouldn't allow enough control.
So where should we stand? First we should allow the whole gamut of
practices, which we do. On one side we're very vigilant about our releases,
on the other side our license is extremely liberal for redistributors. So
from the start we make either ways possible. Then I happen to think that the
distribution channels for *our* (IPMC) projects should be fairly
conservative simply because we aim at being at least good open source
citizens and I don't see the undocumented distribution of binaries as being
part of that. Which I guess marks me finicky :)
Matthieu
>
> Well, I guess one option would be to follow the java.net example and
> pollute
> the m2-incubator-repository with a bunch of crap and overwrite releases and
> add snapshots and stuff. Then they wouldn't want it. :-)
>
>
> Dan
>
>
> >
> > thanks,
> > dims
> >
> > On Thu, Sep 18, 2008 at 11:17 AM, Daniel Kulp <dk...@apache.org> wrote:
> > > On Wednesday 17 September 2008 8:05:40 pm Henning Schmiedehausen wrote:
> > >> > Thus:
> > >> > If the central maven repository maintainers (Maven PMC) decide to
> put
> > >> > incubator artifacts into their repository without a click through
> > >> > "this is incubator code" disclaimer, we'd have no legal reason to
> say
> > >> > no. The Apache License allows them to do so.
> > >>
> > >> The Incubator PMC controls the policy on how podlings release. Not the
> > >> upstream policy. And this policy says: "You keep your releases
> separated
> > >> from the official releases".
> > >
> > > I'm not disputing that. Currently, podling maven artifacts go to:
> > > /www/people.apache.org/repo/m2-incubating-repository
> > > and non-podling releases go to:
> > > /www/people.apache.org/repo/m2-ibiblio-rsync-repository
> > > (which is now a completely inaccurate name :-( Should be
> > > m2-release-repository or similar)
> > > They are separate.
> > >
> > > The difference right now is that a non-incubator third party (Maven
> PMC)
> > > has decided to sync one of those trees into their repository. From
> > > what I can see, there is no way an INCUBATOR policy could prevent
> another
> > > third party from deciding to also sync the other tree in as well.
> > > Projects don't release to central. They release to one of the above
> > > directories and Maven pulls those into central. (as part of that, the
> > > maven team checks the sigs to make sure they are OK, etc...)
> > >
> > > Another example.... My friend sets up a Nexus repository manager for
> > > his users. He adds the incubator repo to the nexus config as he needs
> a
> > > single thing out of there. Then, any users using my Nexus instance
> will
> > > get incubator artifacts without setting the incubator repository in
> their
> > > settings.xml. My friend is a third party, incubator definitely cannot
> > > tell him not to do that.
> > >
> > >> Allowing the usage of a maven repo for
> > >> publishing these is a privilege, not a right.
> > >
> > > OK. What "RIGHT" does the Incubator PMC have to tell the Maven PMC
> (or
> > > RedHat or Debian or CPAN or ....) to not put incubator artifacts in
> their
> > > repo? Infrastructure probably would have the right if the method maven
> > > used caused bandwith issues or similar. Block IP type thing. They do
> > > the same thing for "svn abuse".
> > >
> > > I re-iterate: projects do NOT release to central. They deploy to a
> > > project or organization specific location and the MAVEN folks sync that
> > > into central if that location meets their requirements and the needs of
> > > their users. Basically, do the maven folks "trust" that location to not
> > > be full of crap? (and can they trust that the stuff in that repo has a
> > > license compatible with putting it in central?)
> > >
> > > One example of that NOT being the case is the java.net repo. Sun is
> > > notoriously bad at putting crap in the repo. Thus, the Maven folks do
> > > not sync that repo in anymore. They tried at one point, but it caused
> > > too many issues. So they don't now.
> > >
> > > That's basically why I think the vote is relatively irrelevant. I
> voted
> > > +1 cause I personally think the "policy" is bad for the incubator and
> > > makes it harder for podlings to develop their communities and thus
> > > graduate, but I also think the "policy" is completely irrelevant as
> it's
> > > not enforceable by the Incubator PMC. The Incubator PMC CAN require
> the
> > > podlings to keep their releases in a separate repo on
> people.apache.org,
> > > but they cannot require third parties to not sync it into their repos.
> > >
> > > --
> > > Daniel Kulp
> > > dkulp@apache.org
> > > http://www.dankulp.com/blog
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
RE: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
Conversely and more defendable, we could decide that anything with a
transitive dependency hull that is not completely contained by central
cannot be hosted in central. This is yet another approach to nuking the
issue. The unfortunate side-effect would be to exclude all apache (and
other) artifacts that happen to depend on sun, incubator etc.
It's nearly pointless and quite frustrating to the users to host
something in central that can't be used without a bunch of manual work
arounds. That means we either attempt to include these transitive
dependencies, or we simply don't allow anything that uses them.
-----Original Message-----
From: Davanum Srinivas [mailto:davanum@gmail.com]
Sent: Thursday, September 18, 2008 1:31 PM
To: general@incubator.apache.org
Subject: Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra
release distribution channels like the central Maven repository]
point taken.
-- dims
On Thu, Sep 18, 2008 at 1:26 PM, Daniel Kulp <dk...@apache.org> wrote:
> On Thursday 18 September 2008 1:14:53 pm Davanum Srinivas wrote:
>> "but they cannot require third parties to not sync it into their
>> repos." --> Is this something Maven PMC is
>> thinking-about/voted-on/discussing? basically overriding the current
>> un-written policy of the incubator? Please let us know.
>
> Not yet. But my point is if Maven was NOT an Apache project, what
COULD we
> do?
>
> Well, I guess one option would be to follow the java.net example and
pollute
> the m2-incubator-repository with a bunch of crap and overwrite
releases and
> add snapshots and stuff. Then they wouldn't want it. :-)
>
>
> Dan
>
>
>>
>> thanks,
>> dims
>>
>> On Thu, Sep 18, 2008 at 11:17 AM, Daniel Kulp <dk...@apache.org>
wrote:
>> > On Wednesday 17 September 2008 8:05:40 pm Henning Schmiedehausen
wrote:
>> >> > Thus:
>> >> > If the central maven repository maintainers (Maven PMC) decide
to put
>> >> > incubator artifacts into their repository without a click
through
>> >> > "this is incubator code" disclaimer, we'd have no legal reason
to say
>> >> > no. The Apache License allows them to do so.
>> >>
>> >> The Incubator PMC controls the policy on how podlings release. Not
the
>> >> upstream policy. And this policy says: "You keep your releases
separated
>> >> from the official releases".
>> >
>> > I'm not disputing that. Currently, podling maven artifacts go
to:
>> > /www/people.apache.org/repo/m2-incubating-repository
>> > and non-podling releases go to:
>> > /www/people.apache.org/repo/m2-ibiblio-rsync-repository
>> > (which is now a completely inaccurate name :-( Should be
>> > m2-release-repository or similar)
>> > They are separate.
>> >
>> > The difference right now is that a non-incubator third party (Maven
PMC)
>> > has decided to sync one of those trees into their repository.
From
>> > what I can see, there is no way an INCUBATOR policy could prevent
another
>> > third party from deciding to also sync the other tree in as well.
>> > Projects don't release to central. They release to one of the
above
>> > directories and Maven pulls those into central. (as part of that,
the
>> > maven team checks the sigs to make sure they are OK, etc...)
>> >
>> > Another example.... My friend sets up a Nexus repository manager
for
>> > his users. He adds the incubator repo to the nexus config as he
needs a
>> > single thing out of there. Then, any users using my Nexus
instance will
>> > get incubator artifacts without setting the incubator repository in
their
>> > settings.xml. My friend is a third party, incubator definitely
cannot
>> > tell him not to do that.
>> >
>> >> Allowing the usage of a maven repo for
>> >> publishing these is a privilege, not a right.
>> >
>> > OK. What "RIGHT" does the Incubator PMC have to tell the Maven
PMC (or
>> > RedHat or Debian or CPAN or ....) to not put incubator artifacts in
their
>> > repo? Infrastructure probably would have the right if the method
maven
>> > used caused bandwith issues or similar. Block IP type thing. They
do
>> > the same thing for "svn abuse".
>> >
>> > I re-iterate: projects do NOT release to central. They deploy to
a
>> > project or organization specific location and the MAVEN folks sync
that
>> > into central if that location meets their requirements and the
needs of
>> > their users. Basically, do the maven folks "trust" that location to
not
>> > be full of crap? (and can they trust that the stuff in that repo
has a
>> > license compatible with putting it in central?)
>> >
>> > One example of that NOT being the case is the java.net repo. Sun
is
>> > notoriously bad at putting crap in the repo. Thus, the Maven
folks do
>> > not sync that repo in anymore. They tried at one point, but it
caused
>> > too many issues. So they don't now.
>> >
>> > That's basically why I think the vote is relatively irrelevant. I
voted
>> > +1 cause I personally think the "policy" is bad for the incubator
and
>> > makes it harder for podlings to develop their communities and thus
>> > graduate, but I also think the "policy" is completely irrelevant as
it's
>> > not enforceable by the Incubator PMC. The Incubator PMC CAN
require the
>> > podlings to keep their releases in a separate repo on
people.apache.org,
>> > but they cannot require third parties to not sync it into their
repos.
>> >
>> > --
>> > Daniel Kulp
>> > dkulp@apache.org
>> > http://www.dankulp.com/blog
>> >
>> >
---------------------------------------------------------------------
>> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Davanum Srinivas :: http://davanum.wordpress.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Posted by Davanum Srinivas <da...@gmail.com>.
point taken.
-- dims
On Thu, Sep 18, 2008 at 1:26 PM, Daniel Kulp <dk...@apache.org> wrote:
> On Thursday 18 September 2008 1:14:53 pm Davanum Srinivas wrote:
>> "but they cannot require third parties to not sync it into their
>> repos." --> Is this something Maven PMC is
>> thinking-about/voted-on/discussing? basically overriding the current
>> un-written policy of the incubator? Please let us know.
>
> Not yet. But my point is if Maven was NOT an Apache project, what COULD we
> do?
>
> Well, I guess one option would be to follow the java.net example and pollute
> the m2-incubator-repository with a bunch of crap and overwrite releases and
> add snapshots and stuff. Then they wouldn't want it. :-)
>
>
> Dan
>
>
>>
>> thanks,
>> dims
>>
>> On Thu, Sep 18, 2008 at 11:17 AM, Daniel Kulp <dk...@apache.org> wrote:
>> > On Wednesday 17 September 2008 8:05:40 pm Henning Schmiedehausen wrote:
>> >> > Thus:
>> >> > If the central maven repository maintainers (Maven PMC) decide to put
>> >> > incubator artifacts into their repository without a click through
>> >> > "this is incubator code" disclaimer, we'd have no legal reason to say
>> >> > no. The Apache License allows them to do so.
>> >>
>> >> The Incubator PMC controls the policy on how podlings release. Not the
>> >> upstream policy. And this policy says: "You keep your releases separated
>> >> from the official releases".
>> >
>> > I'm not disputing that. Currently, podling maven artifacts go to:
>> > /www/people.apache.org/repo/m2-incubating-repository
>> > and non-podling releases go to:
>> > /www/people.apache.org/repo/m2-ibiblio-rsync-repository
>> > (which is now a completely inaccurate name :-( Should be
>> > m2-release-repository or similar)
>> > They are separate.
>> >
>> > The difference right now is that a non-incubator third party (Maven PMC)
>> > has decided to sync one of those trees into their repository. From
>> > what I can see, there is no way an INCUBATOR policy could prevent another
>> > third party from deciding to also sync the other tree in as well.
>> > Projects don't release to central. They release to one of the above
>> > directories and Maven pulls those into central. (as part of that, the
>> > maven team checks the sigs to make sure they are OK, etc...)
>> >
>> > Another example.... My friend sets up a Nexus repository manager for
>> > his users. He adds the incubator repo to the nexus config as he needs a
>> > single thing out of there. Then, any users using my Nexus instance will
>> > get incubator artifacts without setting the incubator repository in their
>> > settings.xml. My friend is a third party, incubator definitely cannot
>> > tell him not to do that.
>> >
>> >> Allowing the usage of a maven repo for
>> >> publishing these is a privilege, not a right.
>> >
>> > OK. What "RIGHT" does the Incubator PMC have to tell the Maven PMC (or
>> > RedHat or Debian or CPAN or ....) to not put incubator artifacts in their
>> > repo? Infrastructure probably would have the right if the method maven
>> > used caused bandwith issues or similar. Block IP type thing. They do
>> > the same thing for "svn abuse".
>> >
>> > I re-iterate: projects do NOT release to central. They deploy to a
>> > project or organization specific location and the MAVEN folks sync that
>> > into central if that location meets their requirements and the needs of
>> > their users. Basically, do the maven folks "trust" that location to not
>> > be full of crap? (and can they trust that the stuff in that repo has a
>> > license compatible with putting it in central?)
>> >
>> > One example of that NOT being the case is the java.net repo. Sun is
>> > notoriously bad at putting crap in the repo. Thus, the Maven folks do
>> > not sync that repo in anymore. They tried at one point, but it caused
>> > too many issues. So they don't now.
>> >
>> > That's basically why I think the vote is relatively irrelevant. I voted
>> > +1 cause I personally think the "policy" is bad for the incubator and
>> > makes it harder for podlings to develop their communities and thus
>> > graduate, but I also think the "policy" is completely irrelevant as it's
>> > not enforceable by the Incubator PMC. The Incubator PMC CAN require the
>> > podlings to keep their releases in a separate repo on people.apache.org,
>> > but they cannot require third parties to not sync it into their repos.
>> >
>> > --
>> > Daniel Kulp
>> > dkulp@apache.org
>> > http://www.dankulp.com/blog
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Davanum Srinivas :: http://davanum.wordpress.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Posted by Daniel Kulp <dk...@apache.org>.
On Thursday 18 September 2008 1:14:53 pm Davanum Srinivas wrote:
> "but they cannot require third parties to not sync it into their
> repos." --> Is this something Maven PMC is
> thinking-about/voted-on/discussing? basically overriding the current
> un-written policy of the incubator? Please let us know.
Not yet. But my point is if Maven was NOT an Apache project, what COULD we
do?
Well, I guess one option would be to follow the java.net example and pollute
the m2-incubator-repository with a bunch of crap and overwrite releases and
add snapshots and stuff. Then they wouldn't want it. :-)
Dan
>
> thanks,
> dims
>
> On Thu, Sep 18, 2008 at 11:17 AM, Daniel Kulp <dk...@apache.org> wrote:
> > On Wednesday 17 September 2008 8:05:40 pm Henning Schmiedehausen wrote:
> >> > Thus:
> >> > If the central maven repository maintainers (Maven PMC) decide to put
> >> > incubator artifacts into their repository without a click through
> >> > "this is incubator code" disclaimer, we'd have no legal reason to say
> >> > no. The Apache License allows them to do so.
> >>
> >> The Incubator PMC controls the policy on how podlings release. Not the
> >> upstream policy. And this policy says: "You keep your releases separated
> >> from the official releases".
> >
> > I'm not disputing that. Currently, podling maven artifacts go to:
> > /www/people.apache.org/repo/m2-incubating-repository
> > and non-podling releases go to:
> > /www/people.apache.org/repo/m2-ibiblio-rsync-repository
> > (which is now a completely inaccurate name :-( Should be
> > m2-release-repository or similar)
> > They are separate.
> >
> > The difference right now is that a non-incubator third party (Maven PMC)
> > has decided to sync one of those trees into their repository. From
> > what I can see, there is no way an INCUBATOR policy could prevent another
> > third party from deciding to also sync the other tree in as well.
> > Projects don't release to central. They release to one of the above
> > directories and Maven pulls those into central. (as part of that, the
> > maven team checks the sigs to make sure they are OK, etc...)
> >
> > Another example.... My friend sets up a Nexus repository manager for
> > his users. He adds the incubator repo to the nexus config as he needs a
> > single thing out of there. Then, any users using my Nexus instance will
> > get incubator artifacts without setting the incubator repository in their
> > settings.xml. My friend is a third party, incubator definitely cannot
> > tell him not to do that.
> >
> >> Allowing the usage of a maven repo for
> >> publishing these is a privilege, not a right.
> >
> > OK. What "RIGHT" does the Incubator PMC have to tell the Maven PMC (or
> > RedHat or Debian or CPAN or ....) to not put incubator artifacts in their
> > repo? Infrastructure probably would have the right if the method maven
> > used caused bandwith issues or similar. Block IP type thing. They do
> > the same thing for "svn abuse".
> >
> > I re-iterate: projects do NOT release to central. They deploy to a
> > project or organization specific location and the MAVEN folks sync that
> > into central if that location meets their requirements and the needs of
> > their users. Basically, do the maven folks "trust" that location to not
> > be full of crap? (and can they trust that the stuff in that repo has a
> > license compatible with putting it in central?)
> >
> > One example of that NOT being the case is the java.net repo. Sun is
> > notoriously bad at putting crap in the repo. Thus, the Maven folks do
> > not sync that repo in anymore. They tried at one point, but it caused
> > too many issues. So they don't now.
> >
> > That's basically why I think the vote is relatively irrelevant. I voted
> > +1 cause I personally think the "policy" is bad for the incubator and
> > makes it harder for podlings to develop their communities and thus
> > graduate, but I also think the "policy" is completely irrelevant as it's
> > not enforceable by the Incubator PMC. The Incubator PMC CAN require the
> > podlings to keep their releases in a separate repo on people.apache.org,
> > but they cannot require third parties to not sync it into their repos.
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org
> > http://www.dankulp.com/blog
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Posted by Davanum Srinivas <da...@gmail.com>.
"but they cannot require third parties to not sync it into their
repos." --> Is this something Maven PMC is
thinking-about/voted-on/discussing? basically overriding the current
un-written policy of the incubator? Please let us know.
thanks,
dims
On Thu, Sep 18, 2008 at 11:17 AM, Daniel Kulp <dk...@apache.org> wrote:
> On Wednesday 17 September 2008 8:05:40 pm Henning Schmiedehausen wrote:
>> > Thus:
>> > If the central maven repository maintainers (Maven PMC) decide to put
>> > incubator artifacts into their repository without a click through "this
>> > is incubator code" disclaimer, we'd have no legal reason to say no. The
>> > Apache License allows them to do so.
>>
>> The Incubator PMC controls the policy on how podlings release. Not the
>> upstream policy. And this policy says: "You keep your releases separated
>> from the official releases".
>
> I'm not disputing that. Currently, podling maven artifacts go to:
> /www/people.apache.org/repo/m2-incubating-repository
> and non-podling releases go to:
> /www/people.apache.org/repo/m2-ibiblio-rsync-repository
> (which is now a completely inaccurate name :-( Should be
> m2-release-repository or similar)
> They are separate.
>
> The difference right now is that a non-incubator third party (Maven PMC) has
> decided to sync one of those trees into their repository. From what I can
> see, there is no way an INCUBATOR policy could prevent another third party
> from deciding to also sync the other tree in as well. Projects don't
> release to central. They release to one of the above directories and Maven
> pulls those into central. (as part of that, the maven team checks the sigs
> to make sure they are OK, etc...)
>
> Another example.... My friend sets up a Nexus repository manager for his
> users. He adds the incubator repo to the nexus config as he needs a single
> thing out of there. Then, any users using my Nexus instance will get
> incubator artifacts without setting the incubator repository in their
> settings.xml. My friend is a third party, incubator definitely cannot tell
> him not to do that.
>
>> Allowing the usage of a maven repo for
>> publishing these is a privilege, not a right.
>
> OK. What "RIGHT" does the Incubator PMC have to tell the Maven PMC (or
> RedHat or Debian or CPAN or ....) to not put incubator artifacts in their
> repo? Infrastructure probably would have the right if the method maven used
> caused bandwith issues or similar. Block IP type thing. They do the same
> thing for "svn abuse".
>
> I re-iterate: projects do NOT release to central. They deploy to a project
> or organization specific location and the MAVEN folks sync that into central
> if that location meets their requirements and the needs of their users.
> Basically, do the maven folks "trust" that location to not be full of crap?
> (and can they trust that the stuff in that repo has a license compatible with
> putting it in central?)
>
> One example of that NOT being the case is the java.net repo. Sun is
> notoriously bad at putting crap in the repo. Thus, the Maven folks do not
> sync that repo in anymore. They tried at one point, but it caused too many
> issues. So they don't now.
>
> That's basically why I think the vote is relatively irrelevant. I voted +1
> cause I personally think the "policy" is bad for the incubator and makes it
> harder for podlings to develop their communities and thus graduate, but I
> also think the "policy" is completely irrelevant as it's not enforceable by
> the Incubator PMC. The Incubator PMC CAN require the podlings to keep their
> releases in a separate repo on people.apache.org, but they cannot require
> third parties to not sync it into their repos.
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Davanum Srinivas :: http://davanum.wordpress.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Posted by Daniel Kulp <dk...@apache.org>.
On Wednesday 17 September 2008 8:05:40 pm Henning Schmiedehausen wrote:
> > Thus:
> > If the central maven repository maintainers (Maven PMC) decide to put
> > incubator artifacts into their repository without a click through "this
> > is incubator code" disclaimer, we'd have no legal reason to say no. The
> > Apache License allows them to do so.
>
> The Incubator PMC controls the policy on how podlings release. Not the
> upstream policy. And this policy says: "You keep your releases separated
> from the official releases".
I'm not disputing that. Currently, podling maven artifacts go to:
/www/people.apache.org/repo/m2-incubating-repository
and non-podling releases go to:
/www/people.apache.org/repo/m2-ibiblio-rsync-repository
(which is now a completely inaccurate name :-( Should be
m2-release-repository or similar)
They are separate.
The difference right now is that a non-incubator third party (Maven PMC) has
decided to sync one of those trees into their repository. From what I can
see, there is no way an INCUBATOR policy could prevent another third party
from deciding to also sync the other tree in as well. Projects don't
release to central. They release to one of the above directories and Maven
pulls those into central. (as part of that, the maven team checks the sigs
to make sure they are OK, etc...)
Another example.... My friend sets up a Nexus repository manager for his
users. He adds the incubator repo to the nexus config as he needs a single
thing out of there. Then, any users using my Nexus instance will get
incubator artifacts without setting the incubator repository in their
settings.xml. My friend is a third party, incubator definitely cannot tell
him not to do that.
> Allowing the usage of a maven repo for
> publishing these is a privilege, not a right.
OK. What "RIGHT" does the Incubator PMC have to tell the Maven PMC (or
RedHat or Debian or CPAN or ....) to not put incubator artifacts in their
repo? Infrastructure probably would have the right if the method maven used
caused bandwith issues or similar. Block IP type thing. They do the same
thing for "svn abuse".
I re-iterate: projects do NOT release to central. They deploy to a project
or organization specific location and the MAVEN folks sync that into central
if that location meets their requirements and the needs of their users.
Basically, do the maven folks "trust" that location to not be full of crap?
(and can they trust that the stuff in that repo has a license compatible with
putting it in central?)
One example of that NOT being the case is the java.net repo. Sun is
notoriously bad at putting crap in the repo. Thus, the Maven folks do not
sync that repo in anymore. They tried at one point, but it caused too many
issues. So they don't now.
That's basically why I think the vote is relatively irrelevant. I voted +1
cause I personally think the "policy" is bad for the incubator and makes it
harder for podlings to develop their communities and thus graduate, but I
also think the "policy" is completely irrelevant as it's not enforceable by
the Incubator PMC. The Incubator PMC CAN require the podlings to keep their
releases in a separate repo on people.apache.org, but they cannot require
third parties to not sync it into their repos.
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow
extra release distribution channels like the central Maven repository]
Posted by Henning Schmiedehausen <he...@apache.org>.
On Wed, 2008-09-17 at 20:14 -0500, William A. Rowe, Jr. wrote:
> Henning Schmiedehausen wrote:
> > On Wed, 2008-09-17 at 06:57 -0400, Daniel Kulp wrote:
> >> I voted +1, but I personally think the vote is kind of irrelevant.....
> >
> >> Thus:
> >> If the central maven repository maintainers (Maven PMC) decide to put
> >> incubator artifacts into their repository without a click through "this is
> >> incubator code" disclaimer, we'd have no legal reason to say no. The Apache
> >> License allows them to do so.
> >
> > The Incubator PMC controls the policy on how podlings release. Not the
> > upstream policy. And this policy says: "You keep your releases separated
> > from the official releases". Allowing the usage of a maven repo for
> > publishing these is a privilege, not a right.
>
> That information is stale;
>
> http://www.apache.org/dist/incubator/{podling}/
> http://www.apache.org/dist/{tlp}/{subproject}/
>
> There was earlier confusion in the life of the Incubator that an incubating
> release is not an ASF release. This misunderstanding has been corrected
http://incubator.apache.org/incubation/Incubation_Policy.html#Releases
"Podlings are not yet fully accepted as part of the Apache Software
Foundation. No release made by a Podling will be endorsed by the ASF.
Unendorsed releases may be made by Podlings subject to the following
policy."
Maybe you should do some reading... :-)
Best regards
Henning
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Thu, Sep 18, 2008 at 11:41 PM, William A. Rowe, Jr.
<wr...@rowe-clan.net> wrote:
> Since the hash is not security, it's not terribly important, eh?
Hashes are a perfect tool for verifying message integrity. They won't
prove origin like signatures do, but verifiable integrity is hardly
*not* security.
Verifying integrity is what Hiram is trying to achieve with his
plugin. I.e. ensuring that the dependencies on the repository (or in
transit from the repository to the user) haven't been tampered with.
You have a valid concern about how the the upstream developer can
trust his dependencies. Hiram has a valid solution to the security of
the downstream user who builds a source release (with Maven
dependencies) from the upstream developer that he trusts.
PS. Should we take this somewhere else than general@incubator. It's
hardly on topic here.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release
distribution channels like the central Maven repository]
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Hiram Chirino wrote:
>
> Agreed. I never argued against this. But I fail to see the point?
> Are you saying initial trust is hard to secure? I totally agree on
> that point. You have any solutions?
Yes. You sign your package locally, never on the remote system. The ASF
hardware must never have your gpg signing key. And nobody trusts that
package without observing a valid gpg signature, especially not software
that is "blindly" installed (e.g. maven, other automated installers).
The security hole we perceive is that ASF packages are blindly created
using maven, relying on the fact that no machine that had touched that
dependent artifact or transmitting it had been compromised.
If the key is compromised, it's your job to revoke it. But there's a long
discussion about revocation trust, let's not go there.
>> If it were cracked again, MD5 signatures would not be trusted, and all of
>> those resources would be wiped if there were no gpg keys available to
>> validate the packages.
>
> Are you saying even the source code/svn would be wiped? If that's the
> case we would have a real tragedy on our hands. I hope we kept good
> backups.
Yes; and we have backups. We even have a mirror to retrace precisely what
commits happened after the breach, and determine if we want to reapply them
(presuming for a moment that the mirror could not be compromised).
> It's configurable.. We can default to whatever algorithm you think is
> the most secure for the foreseeable future.
Since the hash is not security, it's not terribly important, eh?
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Posted by Hiram Chirino <hi...@hiramchirino.com>.
Trust me I'm not trying to be difficult..
On Thu, Sep 18, 2008 at 4:53 PM, William A. Rowe, Jr.
<wr...@rowe-clan.net> wrote:
> Hiram, I wish you would desist already from debating positions that you
> can't defend...
>
> Hiram Chirino wrote:
>>
>> On Thu, Sep 18, 2008 at 3:07 PM, sebb <se...@gmail.com> wrote:
>>>
>>> On 18/09/2008, Hiram Chirino <hi...@hiramchirino.com> wrote:
>>>>
>>>> So the responsibility is still on us, the upstream distributor, to
>>>> verify the the checksums we list in our source distro are correct.
>>>
>>> And how do we do that?
>>> We cannot use the Maven repo as it has already been compromised.
>>
>> If you are a totally paranoid, you would build all the dependencies
>> your self and use those checksums. :) Since that's not practical,
>> you have to trust that an artifact on a maven repo has not been
>> hacked.. or even validate it has not been hacked (perhaps the project
>> provides a separate website with the checksums of the artifacts).
>
> www.apache.org has been breached at least once in it's history. Over the
> course of the next 100 years, it will likely happen once again. You have
> two ASF machines and two maven machines in the matrix, the DNS and www
> servers of both ASF and the maven host. That's four vectors already.
> I'm not even going into other upstream hosts.
>
Agreed. I never argued against this. But I fail to see the point?
Are you saying initial trust is hard to secure? I totally agree on
that point. You have any solutions?
> If it were cracked again, MD5 signatures would not be trusted, and all of
> those resources would be wiped if there were no gpg keys available to
> validate the packages.
Are you saying even the source code/svn would be wiped? If that's the
case we would have a real tragedy on our hands. I hope we kept good
backups.
>
> At least, you design for this scenario and pray that doesn't happen.
>
> Hiram Chirino wrote:
>>
>> Yes, but that kind of attack would only affect me if It's the first
>> time I'm creating a dependency to that artifact. Further more, other
>> existing users of the artifact would detect the artifact replacement,
>> and act to get the problem corrected. I consider the checksum
>> solution very similar to how SSH work in asking you to verify your
>> initial connection to a host. It's not 100% secure, but in practical
>> use, it's in the high 90s. :)
>
> Using SHA-384 and higher? Or MD5? MD5 can be cracked resulting in a
> same sized object.
It's configurable.. We can default to whatever algorithm you think is
the most secure for the foreseeable future.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://open.iona.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release
distribution channels like the central Maven repository]
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Hiram, I wish you would desist already from debating positions that you
can't defend...
Hiram Chirino wrote:
> On Thu, Sep 18, 2008 at 3:07 PM, sebb <se...@gmail.com> wrote:
>> On 18/09/2008, Hiram Chirino <hi...@hiramchirino.com> wrote:
>>> So the responsibility is still on us, the upstream distributor, to
>>> verify the the checksums we list in our source distro are correct.
>> And how do we do that?
>> We cannot use the Maven repo as it has already been compromised.
>
> If you are a totally paranoid, you would build all the dependencies
> your self and use those checksums. :) Since that's not practical,
> you have to trust that an artifact on a maven repo has not been
> hacked.. or even validate it has not been hacked (perhaps the project
> provides a separate website with the checksums of the artifacts).
www.apache.org has been breached at least once in it's history. Over the
course of the next 100 years, it will likely happen once again. You have
two ASF machines and two maven machines in the matrix, the DNS and www
servers of both ASF and the maven host. That's four vectors already.
I'm not even going into other upstream hosts.
If it were cracked again, MD5 signatures would not be trusted, and all of
those resources would be wiped if there were no gpg keys available to
validate the packages.
At least, you design for this scenario and pray that doesn't happen.
Hiram Chirino wrote:
>
> Yes, but that kind of attack would only affect me if It's the first
> time I'm creating a dependency to that artifact. Further more, other
> existing users of the artifact would detect the artifact replacement,
> and act to get the problem corrected. I consider the checksum
> solution very similar to how SSH work in asking you to verify your
> initial connection to a host. It's not 100% secure, but in practical
> use, it's in the high 90s. :)
Using SHA-384 and higher? Or MD5? MD5 can be cracked resulting in a
same sized object.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Posted by Hiram Chirino <hi...@hiramchirino.com>.
On Thu, Sep 18, 2008 at 3:07 PM, sebb <se...@gmail.com> wrote:
> On 18/09/2008, Hiram Chirino <hi...@hiramchirino.com> wrote:
>> On Thu, Sep 18, 2008 at 10:59 AM, sebb <se...@gmail.com> wrote:
>> > On 18/09/2008, Hiram Chirino <hi...@hiramchirino.com> wrote:
>> >> On Wed, Sep 17, 2008 at 9:42 PM, William A. Rowe, Jr.
>> >>
>> >> <wr...@rowe-clan.net> wrote:
>> >>
>> >> > Similarly, the issue of signature validation is a significant flaw which
>> >> > I also hope maven addresses even more promptly, and which they are aware
>> >> > of. The alternatives are to take down maven until it is secure, or to
>> >> > continue to populate maven with various released artifacts. And this too
>> >> > isn't germane to the question above, which is;
>> >>
>> >>
>> >> The signature validation issue has a simple fix which I have already
>> >> mentioned earlier. I'm not sure why folks continue to think it's
>> >> still a problem. All the projects need to do is enable a checksum
>> >> validation plugin, and at least that problem is resolved.
>> >>
>> >
>> > Not sure I agree that the checksum plugin solves the problem.
>> >
>> > As far as I can tell, all that the plugin does is to detect any
>> > changes to dependencies that occur *after the checksum list is
>> > initially generated*
>>
>>
>> Agreed.
>>
>>
>> >
>> > Unless I'm mistaken, it does not guard against the orignal dependency
>> > already being corrupt, nor does it protect the product itself.
>> >
>>
>>
>> So the responsibility is still on us, the upstream distributor, to
>> verify the the checksums we list in our source distro are correct.
>
> And how do we do that?
> We cannot use the Maven repo as it has already been compromised.
If you are a totally paranoid, you would build all the dependencies
your self and use those checksums. :) Since that's not practical,
you have to trust that an artifact on a maven repo has not been
hacked.. or even validate it has not been hacked (perhaps the project
provides a separate website with the checksums of the artifacts).
But even if you get it wrong, it's not the end of the world.. The
important thing is being able to detect and correct the problem.
>
>> But at least by doing this, down stream users of our source distros
>> can rest assured that the dependencies that they are using are the
>> correct ones.
>
> Only if our distro has not had its checksum list hacked.
The checksums are part of the source distro. If the source distro you
downloaded is hacked.. hey hack the checksum list.. the hacker might
as well put the malicious code in the source code.
>
>> If a committer by mistake adds an invalid checksum for an artifact
>> that he been hacked in his repo, hopefully, another developer doing
>> the build will notice that the build fails due to checksum error if he
>> has the valid artifact. At that point they can investigate who has
>> the valid copy of the artifact. The more users that are building the
>> software with the checksum validation, the better of chance you got at
>> some one noticing a hacked repo artifact.
>
> Depends on when the hacked version was uploaded.
> It's quite possible that every ASF use of the module will be after the
> original hack.
>
Possible.. But I'm talking about a wider audience than the ASF. I
hope if the ASF adopts this policy of using the checksum plugin, the
maven folks adopt it as a standard practice. And then we have every
other maven user out there helping detect repository attacks.
>> If by chance all repos being used only have the hacked version of the
>> artifact and, no one notices it hacked and we release with that.. then
>> that would be a serious issue yes. I think we should handle that like
>
> Which is what we should protect against from the start.
Sure.. but that starts at implementing good repository security. That
is the start after all.
>
>> we would handle any serious security flaw in our products. Re-release
>> with the flaw (checksum) corrected and advise all our users to
>> upgrade.
>>
>> On a side note.. a GPG web of trust would help in trusting the
>> original binary checksum. Note that down stream users of our source
>> distro may not trust people we trust, so they may want those checksums
>> anyways.
>
> How? By signing the checksum?
> If so, fine, but then why not just sign the jar.
>
Yes I mean signing the artifacts. If you are adding a new dependency
that has a trusted signature, it's a should be a no brainer to accept
that the artifact has not been tampered with. But remember not all
3rd party artifacts are going to have trusted signers. Also, what
happens if that key used to sign the artifact gets compromised.. so
it might not be so trusted anymore.. So even GPG may not be the solve
all of the problem of initial trust.
>>
>> > What's to stop the checksum list being corrupted?
>
> Any comment on this?
To corrupt the checksum list.. the source disto must be hacked. At
that point it's not a build tool issue.
>
>> >
>> >>
>> >> --
>> >> Regards,
>> >> Hiram
>> >>
>> >> Blog: http://hiramchirino.com
>> >>
>> >> Open Source SOA
>> >> http://open.iona.com
>> >>
>> >> ---------------------------------------------------------------------
>> >>
>> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> >> For additional commands, e-mail: general-help@incubator.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: general-help@incubator.apache.org
>> >
>> >
>>
>>
>>
>>
>> --
>>
>> Regards,
>> Hiram
>>
>> Blog: http://hiramchirino.com
>>
>> Open Source SOA
>> http://open.iona.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://open.iona.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Posted by sebb <se...@gmail.com>.
On 18/09/2008, Hiram Chirino <hi...@hiramchirino.com> wrote:
> On Thu, Sep 18, 2008 at 10:59 AM, sebb <se...@gmail.com> wrote:
> > On 18/09/2008, Hiram Chirino <hi...@hiramchirino.com> wrote:
> >> On Wed, Sep 17, 2008 at 9:42 PM, William A. Rowe, Jr.
> >>
> >> <wr...@rowe-clan.net> wrote:
> >>
> >> > Similarly, the issue of signature validation is a significant flaw which
> >> > I also hope maven addresses even more promptly, and which they are aware
> >> > of. The alternatives are to take down maven until it is secure, or to
> >> > continue to populate maven with various released artifacts. And this too
> >> > isn't germane to the question above, which is;
> >>
> >>
> >> The signature validation issue has a simple fix which I have already
> >> mentioned earlier. I'm not sure why folks continue to think it's
> >> still a problem. All the projects need to do is enable a checksum
> >> validation plugin, and at least that problem is resolved.
> >>
> >
> > Not sure I agree that the checksum plugin solves the problem.
> >
> > As far as I can tell, all that the plugin does is to detect any
> > changes to dependencies that occur *after the checksum list is
> > initially generated*
>
>
> Agreed.
>
>
> >
> > Unless I'm mistaken, it does not guard against the orignal dependency
> > already being corrupt, nor does it protect the product itself.
> >
>
>
> So the responsibility is still on us, the upstream distributor, to
> verify the the checksums we list in our source distro are correct.
And how do we do that?
We cannot use the Maven repo as it has already been compromised.
> But at least by doing this, down stream users of our source distros
> can rest assured that the dependencies that they are using are the
> correct ones.
Only if our distro has not had its checksum list hacked.
> If a committer by mistake adds an invalid checksum for an artifact
> that he been hacked in his repo, hopefully, another developer doing
> the build will notice that the build fails due to checksum error if he
> has the valid artifact. At that point they can investigate who has
> the valid copy of the artifact. The more users that are building the
> software with the checksum validation, the better of chance you got at
> some one noticing a hacked repo artifact.
Depends on when the hacked version was uploaded.
It's quite possible that every ASF use of the module will be after the
original hack.
> If by chance all repos being used only have the hacked version of the
> artifact and, no one notices it hacked and we release with that.. then
> that would be a serious issue yes. I think we should handle that like
Which is what we should protect against from the start.
> we would handle any serious security flaw in our products. Re-release
> with the flaw (checksum) corrected and advise all our users to
> upgrade.
>
> On a side note.. a GPG web of trust would help in trusting the
> original binary checksum. Note that down stream users of our source
> distro may not trust people we trust, so they may want those checksums
> anyways.
How? By signing the checksum?
If so, fine, but then why not just sign the jar.
>
> > What's to stop the checksum list being corrupted?
Any comment on this?
> >
> >>
> >> --
> >> Regards,
> >> Hiram
> >>
> >> Blog: http://hiramchirino.com
> >>
> >> Open Source SOA
> >> http://open.iona.com
> >>
> >> ---------------------------------------------------------------------
> >>
> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
>
>
>
> --
>
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
> Open Source SOA
> http://open.iona.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Posted by Hiram Chirino <hi...@hiramchirino.com>.
Right.. It's part of the source distro or SVN.
On Thu, Sep 18, 2008 at 3:10 PM, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On Thu, Sep 18, 2008 at 9:08 PM, sebb <se...@gmail.com> wrote:
>>> The checksums are _not_ downloaded from the Maven repository.
>>
>> So where are they stored?
>
> For example in our svn or signed source release packages. Along with
> the source code.
>
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://open.iona.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Posted by Hiram Chirino <hi...@hiramchirino.com>.
On Thu, Sep 18, 2008 at 4:57 PM, sebb <se...@gmail.com> wrote:
> On 18/09/2008, Hiram Chirino <hi...@hiramchirino.com> wrote:
>> On Thu, Sep 18, 2008 at 2:26 PM, William A. Rowe, Jr.
>>
>> <wr...@rowe-clan.net> wrote:
>>
>> > Hiram Chirino wrote:
>> >>
>> >> So the responsibility is still on us, the upstream distributor, to
>> >> verify the the checksums we list in our source distro are correct.
>> >> But at least by doing this, down stream users of our source distros
>> >> can rest assured that the dependencies that they are using are the
>> >> correct ones.
>> >
>> > Not if there is a man in the middle attack. If you didn't notice the
>> > recent noise w.r.t. DNS pollution, that's the very point of that vector.
>> > Had it been exploited, tens of thousands of download users could have
>> > been presented with inauthentic maven artifacts, complete with their
>> > freshly corresponding checksums. Welcome to the internet.
>>
>>
>> Yes, but that kind of attack would only affect me if It's the first
>> time I'm creating a dependency to that artifact.
>
> Which will be the case for everyone intially.
>
> Suppose you want to create a checksum list for Apache Foo.
> This uses say 30 Maven artefacts.
> You check each one against the official release version to validate
> the checksum list.
>
> Someone else creates list for Apache Wee.
> They have to go through the same process of validation.
>
> Someone else creates another list for Apache Foo.
> They have to go through the same process of validation.
>
> There's no easy way to share the result of a validation, except
> perhaps with a TLP.
>
> Whereas once a Maven artefact is signed, everyone who trusts the
> signature knows it is OK. Seems to me a lot less work overall.
>
You still have the problem of how do users start trusting the
signature? What if the signature is also hacked. This is a recursive
discussion IMHO.
>> Further more, other
>> existing users of the artifact would detect the artifact replacement,
>> and act to get the problem corrected.
>
> If you don't notice the problem, why would they notice?
Not all users start using a dependency at the same time. Odds are low
that a dependency gets hacked a soon as it gets deployed. Common and
that means old artifacts would be the most likely targets for
malicious attacks. And if it's an old artifact, chances are the lots
of folks know the right checksum for it.
>
>> I consider the checksum
>> solution very similar to how SSH work in asking you to verify your
>> initial connection to a host. It's not 100% secure, but in practical
>> use, it's in the high 90s. :)
>>
>
> Or the low 10s - who knows?
>
Guess you don't trust SSH either eh? :)
>>
>
> How does the process cope with a dependency on commons-foo, version
> 1.2 or later?
>
Maven releases should pin down to a specific revision for this to work.
> AIUI, Maven can pick a later version of a dependency, which may not
> have been available when the checksum list was created.
>
> The advantage of signatures is that if you trust the signer, you can
> trust the signed artefact.
> That's not true for checksums, which require additional validation.
>
Signatures a handy and I think they will make trusting checksums
easier.. But the problem is that not all our dependencies have signed
artifacts that we can trust so we need to work with checksums.
>> --
>>
>> Regards,
>> Hiram
>>
>> Blog: http://hiramchirino.com
>>
>> Open Source SOA
>> http://open.iona.com
>>
>> ---------------------------------------------------------------------
>>
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://open.iona.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Thu, Sep 18, 2008 at 9:08 PM, sebb <se...@gmail.com> wrote:
>> The checksums are _not_ downloaded from the Maven repository.
>
> So where are they stored?
For example in our svn or signed source release packages. Along with
the source code.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Posted by sebb <se...@gmail.com>.
On 18/09/2008, Hiram Chirino <hi...@hiramchirino.com> wrote:
> On Thu, Sep 18, 2008 at 2:26 PM, William A. Rowe, Jr.
>
> <wr...@rowe-clan.net> wrote:
>
> > Hiram Chirino wrote:
> >>
> >> So the responsibility is still on us, the upstream distributor, to
> >> verify the the checksums we list in our source distro are correct.
> >> But at least by doing this, down stream users of our source distros
> >> can rest assured that the dependencies that they are using are the
> >> correct ones.
> >
> > Not if there is a man in the middle attack. If you didn't notice the
> > recent noise w.r.t. DNS pollution, that's the very point of that vector.
> > Had it been exploited, tens of thousands of download users could have
> > been presented with inauthentic maven artifacts, complete with their
> > freshly corresponding checksums. Welcome to the internet.
>
>
> Yes, but that kind of attack would only affect me if It's the first
> time I'm creating a dependency to that artifact.
Which will be the case for everyone intially.
Suppose you want to create a checksum list for Apache Foo.
This uses say 30 Maven artefacts.
You check each one against the official release version to validate
the checksum list.
Someone else creates list for Apache Wee.
They have to go through the same process of validation.
Someone else creates another list for Apache Foo.
They have to go through the same process of validation.
There's no easy way to share the result of a validation, except
perhaps with a TLP.
Whereas once a Maven artefact is signed, everyone who trusts the
signature knows it is OK. Seems to me a lot less work overall.
> Further more, other
> existing users of the artifact would detect the artifact replacement,
> and act to get the problem corrected.
If you don't notice the problem, why would they notice?
> I consider the checksum
> solution very similar to how SSH work in asking you to verify your
> initial connection to a host. It's not 100% secure, but in practical
> use, it's in the high 90s. :)
>
Or the low 10s - who knows?
>
How does the process cope with a dependency on commons-foo, version
1.2 or later?
AIUI, Maven can pick a later version of a dependency, which may not
have been available when the checksum list was created.
The advantage of signatures is that if you trust the signer, you can
trust the signed artefact.
That's not true for checksums, which require additional validation.
> --
>
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
> Open Source SOA
> http://open.iona.com
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Posted by Hiram Chirino <hi...@hiramchirino.com>.
On Thu, Sep 18, 2008 at 2:26 PM, William A. Rowe, Jr.
<wr...@rowe-clan.net> wrote:
> Hiram Chirino wrote:
>>
>> So the responsibility is still on us, the upstream distributor, to
>> verify the the checksums we list in our source distro are correct.
>> But at least by doing this, down stream users of our source distros
>> can rest assured that the dependencies that they are using are the
>> correct ones.
>
> Not if there is a man in the middle attack. If you didn't notice the
> recent noise w.r.t. DNS pollution, that's the very point of that vector.
> Had it been exploited, tens of thousands of download users could have
> been presented with inauthentic maven artifacts, complete with their
> freshly corresponding checksums. Welcome to the internet.
Yes, but that kind of attack would only affect me if It's the first
time I'm creating a dependency to that artifact. Further more, other
existing users of the artifact would detect the artifact replacement,
and act to get the problem corrected. I consider the checksum
solution very similar to how SSH work in asking you to verify your
initial connection to a host. It's not 100% secure, but in practical
use, it's in the high 90s. :)
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://open.iona.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Posted by sebb <se...@gmail.com>.
On 18/09/2008, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On Thu, Sep 18, 2008 at 8:26 PM, William A. Rowe, Jr.
>
> <wr...@rowe-clan.net> wrote:
>
> > Not if there is a man in the middle attack. If you didn't notice the
> > recent noise w.r.t. DNS pollution, that's the very point of that vector.
> > Had it been exploited, tens of thousands of download users could have
> > been presented with inauthentic maven artifacts, complete with their
> > freshly corresponding checksums. Welcome to the internet.
>
>
> Using Hiram's plugin the checksums are already stored in the project
> that you're building and which you typically got either by checking it
> out of svn or by downloading a source release, both of which are
> separate from the Maven repository.
>
> Once you've confident that the sources you have are not compromised,
> the included checksums will verify that the dependencies that were
> downloaded by Maven are also valid (i.e. the same binaries that the
> original developer used).
>
> The checksums are _not_ downloaded from the Maven repository.
>
So where are they stored?
> BR,
>
>
> Jukka Zitting
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Thu, Sep 18, 2008 at 8:26 PM, William A. Rowe, Jr.
<wr...@rowe-clan.net> wrote:
> Not if there is a man in the middle attack. If you didn't notice the
> recent noise w.r.t. DNS pollution, that's the very point of that vector.
> Had it been exploited, tens of thousands of download users could have
> been presented with inauthentic maven artifacts, complete with their
> freshly corresponding checksums. Welcome to the internet.
Using Hiram's plugin the checksums are already stored in the project
that you're building and which you typically got either by checking it
out of svn or by downloading a source release, both of which are
separate from the Maven repository.
Once you've confident that the sources you have are not compromised,
the included checksums will verify that the dependencies that were
downloaded by Maven are also valid (i.e. the same binaries that the
original developer used).
The checksums are _not_ downloaded from the Maven repository.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release
distribution channels like the central Maven repository]
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Hiram Chirino wrote:
>
> So the responsibility is still on us, the upstream distributor, to
> verify the the checksums we list in our source distro are correct.
> But at least by doing this, down stream users of our source distros
> can rest assured that the dependencies that they are using are the
> correct ones.
Not if there is a man in the middle attack. If you didn't notice the
recent noise w.r.t. DNS pollution, that's the very point of that vector.
Had it been exploited, tens of thousands of download users could have
been presented with inauthentic maven artifacts, complete with their
freshly corresponding checksums. Welcome to the internet.
Checksums are not security. They are nothing but error checking.
>> What's to stop the checksum list being corrupted?
Now you are thinking :)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Posted by Hiram Chirino <hi...@hiramchirino.com>.
On Thu, Sep 18, 2008 at 10:59 AM, sebb <se...@gmail.com> wrote:
> On 18/09/2008, Hiram Chirino <hi...@hiramchirino.com> wrote:
>> On Wed, Sep 17, 2008 at 9:42 PM, William A. Rowe, Jr.
>>
>> <wr...@rowe-clan.net> wrote:
>>
>> > Similarly, the issue of signature validation is a significant flaw which
>> > I also hope maven addresses even more promptly, and which they are aware
>> > of. The alternatives are to take down maven until it is secure, or to
>> > continue to populate maven with various released artifacts. And this too
>> > isn't germane to the question above, which is;
>>
>>
>> The signature validation issue has a simple fix which I have already
>> mentioned earlier. I'm not sure why folks continue to think it's
>> still a problem. All the projects need to do is enable a checksum
>> validation plugin, and at least that problem is resolved.
>>
>
> Not sure I agree that the checksum plugin solves the problem.
>
> As far as I can tell, all that the plugin does is to detect any
> changes to dependencies that occur *after the checksum list is
> initially generated*
Agreed.
>
> Unless I'm mistaken, it does not guard against the orignal dependency
> already being corrupt, nor does it protect the product itself.
>
So the responsibility is still on us, the upstream distributor, to
verify the the checksums we list in our source distro are correct.
But at least by doing this, down stream users of our source distros
can rest assured that the dependencies that they are using are the
correct ones.
If a committer by mistake adds an invalid checksum for an artifact
that he been hacked in his repo, hopefully, another developer doing
the build will notice that the build fails due to checksum error if he
has the valid artifact. At that point they can investigate who has
the valid copy of the artifact. The more users that are building the
software with the checksum validation, the better of chance you got at
some one noticing a hacked repo artifact.
If by chance all repos being used only have the hacked version of the
artifact and, no one notices it hacked and we release with that.. then
that would be a serious issue yes. I think we should handle that like
we would handle any serious security flaw in our products. Re-release
with the flaw (checksum) corrected and advise all our users to
upgrade.
On a side note.. a GPG web of trust would help in trusting the
original binary checksum. Note that down stream users of our source
distro may not trust people we trust, so they may want those checksums
anyways.
> What's to stop the checksum list being corrupted?
>
>>
>> --
>> Regards,
>> Hiram
>>
>> Blog: http://hiramchirino.com
>>
>> Open Source SOA
>> http://open.iona.com
>>
>> ---------------------------------------------------------------------
>>
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://open.iona.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Posted by sebb <se...@gmail.com>.
On 18/09/2008, Hiram Chirino <hi...@hiramchirino.com> wrote:
> On Wed, Sep 17, 2008 at 9:42 PM, William A. Rowe, Jr.
>
> <wr...@rowe-clan.net> wrote:
>
> > Similarly, the issue of signature validation is a significant flaw which
> > I also hope maven addresses even more promptly, and which they are aware
> > of. The alternatives are to take down maven until it is secure, or to
> > continue to populate maven with various released artifacts. And this too
> > isn't germane to the question above, which is;
>
>
> The signature validation issue has a simple fix which I have already
> mentioned earlier. I'm not sure why folks continue to think it's
> still a problem. All the projects need to do is enable a checksum
> validation plugin, and at least that problem is resolved.
>
Not sure I agree that the checksum plugin solves the problem.
As far as I can tell, all that the plugin does is to detect any
changes to dependencies that occur *after the checksum list is
initially generated*
Unless I'm mistaken, it does not guard against the orignal dependency
already being corrupt, nor does it protect the product itself.
What's to stop the checksum list being corrupted?
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
> Open Source SOA
> http://open.iona.com
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Posted by Hiram Chirino <hi...@hiramchirino.com>.
On Wed, Sep 17, 2008 at 9:42 PM, William A. Rowe, Jr.
<wr...@rowe-clan.net> wrote:
> Similarly, the issue of signature validation is a significant flaw which
> I also hope maven addresses even more promptly, and which they are aware
> of. The alternatives are to take down maven until it is secure, or to
> continue to populate maven with various released artifacts. And this too
> isn't germane to the question above, which is;
The signature validation issue has a simple fix which I have already
mentioned earlier. I'm not sure why folks continue to think it's
still a problem. All the projects need to do is enable a checksum
validation plugin, and at least that problem is resolved.
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://open.iona.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Posted by Davanum Srinivas <da...@gmail.com>.
true. these are the reasons i voted the way i did. basically throwing
up my hands saying nothing much we can do other than just continue
pissing off our users...I am sure the numerous maven pmc members here
are taking note, but are probably waiting for patches :)
-- dims
On Wed, Sep 17, 2008 at 9:42 PM, William A. Rowe, Jr.
<wr...@rowe-clan.net> wrote:
> Davanum Srinivas wrote:
>>
>> Since you are stating facts. Let's make it clear that when someone
>> download the artifacts, there's a good chance that you will see the
>> disclaimers. With maven, we don't. That's the hiccup that caused the
>> policy in place right now and the bruising battle now being fought is
>> caused by the fact that there is no other
>> maven-pmc-blessed-and-approved-way to inform the folks who
>> auto-magically pull dependencies as of this moment and there is not
>> likely to be one in the future AFAICT.
>
> We don't disagree. For that matter, there are licenses, notices and
> other critical information present in maven artifacts which are unlikely
> to be noticed. That's a failure of maven and not germane to this
> discussion, although I certainly hope that maven addresses it! But in
> most cases, the disclaimer was only relevant to the individual developer
> who incited the dependency and triggered a maven build to fetch that
> particular artifact. Our disclaimer is really meaningless to the end
> user of that developer's combined work.
>
> Similarly, the issue of signature validation is a significant flaw which
> I also hope maven addresses even more promptly, and which they are aware
> of. The alternatives are to take down maven until it is secure, or to
> continue to populate maven with various released artifacts. And this too
> isn't germane to the question above, which is;
>
> "Allow extra release distribution channels like the central Maven
> repository?"
>
> If an incubating release is a release, with a specific DISCLAIMER (no
> different than incorporating other NOTICEs or LICENSE), and a specific
> release name format (apache-incubating-{podling}-{rev}), then the Maven
> specific side of this argument should happen on the Maven list, and this
> discussion should finally come to an end.
>
> Bill
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Davanum Srinivas :: http://davanum.wordpress.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release
distribution channels like the central Maven repository]
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Davanum Srinivas wrote:
>
> Since you are stating facts. Let's make it clear that when someone
> download the artifacts, there's a good chance that you will see the
> disclaimers. With maven, we don't. That's the hiccup that caused the
> policy in place right now and the bruising battle now being fought is
> caused by the fact that there is no other
> maven-pmc-blessed-and-approved-way to inform the folks who
> auto-magically pull dependencies as of this moment and there is not
> likely to be one in the future AFAICT.
We don't disagree. For that matter, there are licenses, notices and
other critical information present in maven artifacts which are unlikely
to be noticed. That's a failure of maven and not germane to this
discussion, although I certainly hope that maven addresses it! But in
most cases, the disclaimer was only relevant to the individual developer
who incited the dependency and triggered a maven build to fetch that
particular artifact. Our disclaimer is really meaningless to the end
user of that developer's combined work.
Similarly, the issue of signature validation is a significant flaw which
I also hope maven addresses even more promptly, and which they are aware
of. The alternatives are to take down maven until it is secure, or to
continue to populate maven with various released artifacts. And this too
isn't germane to the question above, which is;
"Allow extra release distribution channels like the central Maven
repository?"
If an incubating release is a release, with a specific DISCLAIMER (no
different than incorporating other NOTICEs or LICENSE), and a specific
release name format (apache-incubating-{podling}-{rev}), then the Maven
specific side of this argument should happen on the Maven list, and this
discussion should finally come to an end.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Posted by Davanum Srinivas <da...@gmail.com>.
Bill,
Since you are stating facts. Let's make it clear that when someone
download the artifacts, there's a good chance that you will see the
disclaimers. With maven, we don't. That's the hiccup that caused the
policy in place right now and the bruising battle now being fought is
caused by the fact that there is no other
maven-pmc-blessed-and-approved-way to inform the folks who
auto-magically pull dependencies as of this moment and there is not
likely to be one in the future AFAICT.
-- dims
On Wed, Sep 17, 2008 at 9:14 PM, William A. Rowe, Jr.
<wr...@rowe-clan.net> wrote:
> Henning Schmiedehausen wrote:
>>
>> On Wed, 2008-09-17 at 06:57 -0400, Daniel Kulp wrote:
>>>
>>> I voted +1, but I personally think the vote is kind of irrelevant.....
>>
>>> Thus:
>>> If the central maven repository maintainers (Maven PMC) decide to put
>>> incubator artifacts into their repository without a click through "this is
>>> incubator code" disclaimer, we'd have no legal reason to say no. The
>>> Apache License allows them to do so.
>>
>> The Incubator PMC controls the policy on how podlings release. Not the
>> upstream policy. And this policy says: "You keep your releases separated
>> from the official releases". Allowing the usage of a maven repo for
>> publishing these is a privilege, not a right.
>
> That information is stale;
>
> http://www.apache.org/dist/incubator/{podling}/
> http://www.apache.org/dist/{tlp}/{subproject}/
>
> There was earlier confusion in the life of the Incubator that an incubating
> release is not an ASF release. This misunderstanding has been corrected
> (repeatedly).
>
> The Maven team has an obligation to apply the same rules for ASF artifacts
> as for Third Party artifacts, owing to the fact that they assert no more
> control than any other typical mirror. And to correct your other
> misunderstanding, the maven repository is moving to the ASF, although
> still co-located out-of-house on ISP hardware.
>
> Bill
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Davanum Srinivas :: http://davanum.wordpress.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release
distribution channels like the central Maven repository]
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Henning Schmiedehausen wrote:
> On Wed, 2008-09-17 at 06:57 -0400, Daniel Kulp wrote:
>> I voted +1, but I personally think the vote is kind of irrelevant.....
>
>> Thus:
>> If the central maven repository maintainers (Maven PMC) decide to put
>> incubator artifacts into their repository without a click through "this is
>> incubator code" disclaimer, we'd have no legal reason to say no. The Apache
>> License allows them to do so.
>
> The Incubator PMC controls the policy on how podlings release. Not the
> upstream policy. And this policy says: "You keep your releases separated
> from the official releases". Allowing the usage of a maven repo for
> publishing these is a privilege, not a right.
That information is stale;
http://www.apache.org/dist/incubator/{podling}/
http://www.apache.org/dist/{tlp}/{subproject}/
There was earlier confusion in the life of the Incubator that an incubating
release is not an ASF release. This misunderstanding has been corrected
(repeatedly).
The Maven team has an obligation to apply the same rules for ASF artifacts
as for Third Party artifacts, owing to the fact that they assert no more
control than any other typical mirror. And to correct your other
misunderstanding, the maven repository is moving to the ASF, although
still co-located out-of-house on ISP hardware.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra
release distribution channels like the central Maven repository]
Posted by Henning Schmiedehausen <he...@apache.org>.
On Wed, 2008-09-17 at 06:57 -0400, Daniel Kulp wrote:
> I voted +1, but I personally think the vote is kind of irrelevant.....
>
[...]
> Thus:
> If the central maven repository maintainers (Maven PMC) decide to put
> incubator artifacts into their repository without a click through "this is
> incubator code" disclaimer, we'd have no legal reason to say no. The Apache
> License allows them to do so.
The Incubator PMC controls the policy on how podlings release. Not the
upstream policy. And this policy says: "You keep your releases separated
from the official releases". Allowing the usage of a maven repo for
publishing these is a privilege, not a right.
Best regards
Henning
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra
release distribution channels like the central Maven repository]
Posted by Henning Schmiedehausen <he...@apache.org>.
On Wed, 2008-09-17 at 13:19 -0400, Noel J. Bergman wrote:
> I still maintain that unless Maven makes swift strides to enforce signing,
> the ASF should ban the use of the Maven repository for all ASF projects, and
> go so far as to remove all of our artifacts.
sorry, but that is ridiculous. That might work for incubator, but the
PMCs can release in their own right through whatever channel they chose
to.
Best regards
Henning
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Posted by "Noel J. Bergman" <no...@devtech.com>.
Dan,
It is a policy matter, not a legal one. And enforcing artifact signing
would address this and other crucial, fatal, flaws in Maven's repository
management.
I still maintain that unless Maven makes swift strides to enforce signing,
the ASF should ban the use of the Maven repository for all ASF projects, and
go so far as to remove all of our artifacts.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Posted by Daniel Kulp <dk...@apache.org>.
I voted +1, but I personally think the vote is kind of irrelevant.....
FACT: The stuff in the incubator repo are Apache releases. They had the 3
binding +1 votes from the incubator IPMC members. They are releases.
FACT: The stuff in the incubator repo is all Apache Licensed artifacts.
FACT: Nowhere in the Apache License is there a requirement that the user has
to read and accept the Incubator disclaimer prior to use.
Given the above:
If RedHat decided to put incubator artifacts in their repository without a
click through "this is incubator code" disclaimer, we'd have no legal reason
to say no. The Apache License allows them to do so.
If Debian decided to put incubator artifacts in their repository without a
click through "this is incubator code" disclaimer, we'd have no legal reason
to say no. The Apache License allows them to do so.
If the CPAN maintainers decided to put incubator perl modules into their
repository without a click through "this is incubator code" disclaimer, we'd
have no legal reason to say no. The Apache License allows them to do so.
If repo maintainer XXXXX decided to put incubator perl modules into their
repository without a click through "this is incubator code" disclaimer, we'd
have no legal reason to say no. The Apache License allows them to do so.
If Ivy/Builder/Ant/etc.... decided to create their own repository and wanted
the incubator artifacts in it, we'd have no legal reason to say no. The
Apache License allows them to do so.
Thus:
If the central maven repository maintainers (Maven PMC) decide to put
incubator artifacts into their repository without a click through "this is
incubator code" disclaimer, we'd have no legal reason to say no. The Apache
License allows them to do so.
Thus, to me, the vote is kind of pointless. Jukka (or other maven users)
should just ask the Maven folks to start syncing the m2-incubator-repo dir
off of people.apache.org. If the Maven PMC thinks that's in the best
interest of THEIR community and users, they should go ahead and do it
(obviously working with infrastructure to work out logistics to reduce load
and such). The license that applies to all the artifacts in that repo
certainly allows it.
Thus, this vote really is about reducing the burden on the Maven PMC and on
infrastructure. There is an auto-sync dir already setup. Should we use it
or should they be separate which would require new syncs setup which would
result in more processes/connections on people.apache.org, extra bandwidth
used for those extra rsyncs, etc....
If the incubator wants to go off to the board and legal and ask for a
new "Apache Incubator License" that would require the click through, fine.
But until then, lets actually follow the license that is currently being
used.
Anyway, thats my 2 cents worth. (caveat: it may not be worth 2 cents to you)
:-)
Dan
On Tuesday 16 September 2008 6:49:04 pm Matthieu Riou wrote:
> On Tue, Sep 16, 2008 at 2:10 PM, William A. Rowe, Jr.
>
> <wr...@rowe-clan.net>wrote:
> > Justin Erenkrantz wrote:
> >> On Mon, Sep 15, 2008 at 11:13 AM, Emmanuel Lecharny
> >> <el...@gmail.com>
> >>
> >> wrote:
> >>> Craig L Russell wrote:
> >>>> -1
> >>>>
> >>>> I believe that allowing incubating releases to be treated as full
> >>>> Apache releases diminishes the Apache brand and makes incubation
> >>>> disclaimers moot.
> >>>>
> >>>> With Maven, it is too easy to depend on a release with transitive
> >>>> dependencies on incubating releases without even knowing it. When the
> >>>> incubating release subsequently is abandoned, blame will be cast
> >>>> widely, including Apache itself.
> >>>>
> >>>> Considering that dependencies on incubating releases can be resolved
> >>>> by explicitly adding an incubating Maven repository into your
> >>>> settings, I don't
> >>>> think that wide, mirrored, distribution is warranted.
> >>>>
> >>>> Craig
> >>>
> >>> -1 too, for the same reasons.
> >>
> >> -1. Craig pointed out my objections as well. -- justin
> >
> > Just so everyone understands this in context, the objection above is moot
> > because...
> >
> > ...maven is a package deployment mechanism
>
> Beg your pardon? I know that the homepage casts a wide net ("Maven is a
> software project management and comprehension tool.") but in my book Maven
> is used to build stuff (which happens to be almost exclusively Java). I
> don't know of anybody who goes to actual users and tell them "here you go,
> unzip that stuff there, set your JAVA_HOME and your MAVEN_HOME properly,
> execute 'mvn install' and once all test cases pass you're golden".
>
> Maven is a build tool. Users don't build, developers do. And developers
> should know about licenses and disclaimers.
>
> Cheers,
> Matthieu
>
> > ...developers who determine what to bundle into their package don't spend
> > a whole lot of time explaining to users that something within their
> > package is 'incubating' code, or 'patched/forked' code, or virgin
> > original code
> >
> > ...the developer who deploys an app is either going to explain it
> > contains an incubating artifact to their users, or they won't
> >
> > ...no matter if the developer bundles an incubating jar, or calls it up
> > out of maven...
> >
> > The user has ***exactly*** the same experience.
> >
> > Presenting a user with a dialog "Package FOO requires the BAR.jar, an
> > Apache Incubating Bar Project artifact, which[1] carries 'the'[2]
> > disclaimer" will leave them utterly befuddled and is entirely worthless
> > information in the context that they install package FOO (nevermind that
> > the "actual" disclaimer appears to be non-existent in our release
> > documentation).
> >
> > We permit GPL, commercial, virtual anything to be deposited into Maven
> > if I understand correctly. WTF not incubation artifacts, in that light?
> >
> > Bill
> >
> > [1] alternately... "is a tasty beverage container"
> > [2]
> > http://incubator.apache.org/guides/releasemanagement.html#notes-disclaime
> >r
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Posted by Davanum Srinivas <da...@gmail.com>.
Ah! i was just waiting for this response :)
" I don't see any patches yet to help out"
-- dims
On Wed, Sep 17, 2008 at 2:36 PM, Brian E. Fox <br...@reply.infinity.nu> wrote:
>
>>Maven is *too* transparent in what it does: it hides the disclaimer,
>>preventing the POLICY of ensuring that users are explicitly aware of
> and
>>agree to use of Incubator artifacts.
>
> Maven doesn't *hide* anything, it simply makes requests via http. You
> can use your browser to pull stuff from Central, does that mean FF
> "hides" things?
>
>>If the Maven PMC would get off its collective arse and enforce artifact
>>signing, we could put this issue to bed, since users would have to
> approve
>>the signing keys.
>
> Seriously, the Maven bashing is getting old. It's open source and I
> don't see any patches yet to help out. It's not like we don't do
> anything, and as was already pointed out in this thread, work has been
> started in several areas to make this happen.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Davanum Srinivas :: http://davanum.wordpress.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Posted by Matthieu Riou <ma...@offthelip.org>.
On Wed, Sep 17, 2008 at 11:36 AM, Brian E. Fox <br...@reply.infinity.nu>wrote:
>
> >Maven is *too* transparent in what it does: it hides the disclaimer,
> >preventing the POLICY of ensuring that users are explicitly aware of
> and
> >agree to use of Incubator artifacts.
>
> Maven doesn't *hide* anything, it simply makes requests via http. You
> can use your browser to pull stuff from Central, does that mean FF
> "hides" things?
>
Rhetoric. FF doesn't publish the repo. And there's a security model for what
is published (plugins) and what is executed (sandboxed JS).
>
> >If the Maven PMC would get off its collective arse and enforce artifact
> >signing, we could put this issue to bed, since users would have to
> approve
> >the signing keys.
>
> Seriously, the Maven bashing is getting old. It's open source and I
> don't see any patches yet to help out. It's not like we don't do
> anything, and as was already pointed out in this thread, work has been
> started in several areas to make this happen.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
RE: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
>Maven is *too* transparent in what it does: it hides the disclaimer,
>preventing the POLICY of ensuring that users are explicitly aware of
and
>agree to use of Incubator artifacts.
Maven doesn't *hide* anything, it simply makes requests via http. You
can use your browser to pull stuff from Central, does that mean FF
"hides" things?
>If the Maven PMC would get off its collective arse and enforce artifact
>signing, we could put this issue to bed, since users would have to
approve
>the signing keys.
Seriously, the Maven bashing is getting old. It's open source and I
don't see any patches yet to help out. It's not like we don't do
anything, and as was already pointed out in this thread, work has been
started in several areas to make this happen.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Posted by Hiram Chirino <hi...@hiramchirino.com>.
On Wed, Sep 17, 2008 at 1:19 PM, Noel J. Bergman <no...@devtech.com> wrote:
> Maven is *too* transparent in what it does: it hides the disclaimer,
> preventing the POLICY of ensuring that users are explicitly aware of and
> agree to use of Incubator artifacts.
>
We I think this could easily be fixed with proper notice in source
distro. I.E. maven may hide the disclaimer, but it's just a build
tool after all. If notice needs to be given, then that notice should
be in the README or the NOTICE file.
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://open.iona.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Posted by "Noel J. Bergman" <no...@devtech.com>.
Matthieu Riou wrote:
> > Exactly - that's when "actual users" are software developers, which is
> > the case for many of our projects.
> Precisely. And those should be aware of disclaimers if those serve any
> purpose.
Maven is *too* transparent in what it does: it hides the disclaimer,
preventing the POLICY of ensuring that users are explicitly aware of and
agree to use of Incubator artifacts.
If the Maven PMC would get off its collective arse and enforce artifact
signing, we could put this issue to bed, since users would have to approve
the signing keys.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Posted by Matthieu Riou <ma...@offthelip.org>.
On Wed, Sep 17, 2008 at 2:17 AM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:
> On Wed, Sep 17, 2008 at 6:14 AM, Noel J. Bergman <no...@devtech.com> wrote:
> >> I don't know of anybody who goes to actual users and tell
> >> them "here you go, unzip that stuff there, set your
> >> JAVA_HOME and your MAVEN_HOME properly, execute 'mvn install'
> >> and once all test cases pass you're golden".
> >
> > LOL Pretty much word for word:
> >
> > $ cd <PLUTO_SRCHOME>
> > $ mvn install
> > $ mvn pluto:install -DinstallDir=path/to/appserver
> >
> > And there are plenty of others.
>
> Exactly - that's when "actual users" are software developers, which is
> the case for many of our projects.
>
Precisely. And those should be aware of disclaimers if those serve any
purpose.
Cheers,
Matthieu
>
> -Bertrand
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Sep 17, 2008 at 6:14 AM, Noel J. Bergman <no...@devtech.com> wrote:
>> I don't know of anybody who goes to actual users and tell
>> them "here you go, unzip that stuff there, set your
>> JAVA_HOME and your MAVEN_HOME properly, execute 'mvn install'
>> and once all test cases pass you're golden".
>
> LOL Pretty much word for word:
>
> $ cd <PLUTO_SRCHOME>
> $ mvn install
> $ mvn pluto:install -DinstallDir=path/to/appserver
>
> And there are plenty of others.
Exactly - that's when "actual users" are software developers, which is
the case for many of our projects.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I don't know of anybody who goes to actual users and tell
> them "here you go, unzip that stuff there, set your
> JAVA_HOME and your MAVEN_HOME properly, execute 'mvn install'
> and once all test cases pass you're golden".
LOL Pretty much word for word:
$ cd <PLUTO_SRCHOME>
$ mvn install
$ mvn pluto:install -DinstallDir=path/to/appserver
And there are plenty of others.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org