Roy,
I've created a JIRA here on the securing the artifacts request :
http://jira.codehaus.org/browse/MNG-3659
Thanks,
dims
PS: Seriously why can't the mvn issue tracker be inhouse and not at codehaus? :(
On Mon, Jul 7, 2008 at 8:06 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
> Dims, I have to disagree. The releases that we allow incubating projects
> to make, with three +1s and a majority approval, are full Apache releases.
> They have been officially approved by the foundation and we are 100%
> responsible for their content. That's okay, because they also tend to
> receive far more detailed inspection and thus are better quality and more
> conforming to our policies then our pre-incubator TLPs.
>
> There is no reason for a separate repository. It certainly isn't relevant
> to a podling's desire to become a TLP -- that is more than adequately
> compensated by the freedom from slow IPMC approvals and ability to host
> their own website without the butt-ugly egg icon and disclaimers. A
> separate repo does not help protect "users" from incubator code, since
> users don't set the Maven configs that define which repos to use and
> which modules are dependencies. At best, what it does is add an
> irrelevant incubator layer on top of all Maven repo requests that masks
> the "normal" repo path from developers, introduces another way to inject
> insecure code, and wastes our bandwidth sending 404 responses to
> automated build requests.
>
> In contrast, if real incubator releases are allowed to be placed in the
> normal Maven locations, then the incubating config does not mask the
> normal Maven path, there is no need to send *all* repo requests to
> incubator first, the project documentation for Maven doesn't have to
> be a special-case, and releases are still subject to the same quality
> controls as all Apache releases.
>
> Regardless, the user never makes a decision regarding incubator code
> in the Maven repo. The user is either going to pull the incubator
> release directly and then build it using Maven with the provided pom,
> or some other project is going to make a decision to add the artifact
> (with incubator in its name) as a dependency. The Maven repo path is
> irrelevant to the user's decisions -- it just changes the background
> bit traffic and the load on our servers. In short, the policy is
> just plain stupid (speaking as a C developer who builds a few
> projects via Maven only a couple times a year).
>
> Yes, it would be nice if Maven was more secure, properly checked
> signatures, and properly delegated namespaces so that third-parties
> would be unable to add artifacts within other org's trees. None of
> those issues are specific to incubator.
>
> ....Roy
>
>
> ---------------------------------------------------------------------
> 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
|