Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
On 18/10/2008, at 6:12 AM, Jason van Zyl wrote: Jukka, Are you intending here to just redirect poddlings distribution management to: http://people.apache.org/repo/m2-ibiblio-rsync-repository/ This alternative seems the most practical suggestion, by the reasoning: * the separation would be meaningless if both were synced * projects out there refer to the incubator repo, probably don't want to double up on the location they can find an artifact * podlings that don't wish to publish to central can continue to use the incubator repo unaffected Do you want me to sync the existing repository here: http://people.apache.org/repo/m2-incubating-repository/ to http://people.apache.org/repo/m2-ibiblio-rsync-repository/ Or are you handling that? On 13-Oct-08, at 4:00 PM, Jukka Zitting wrote: Hi, On Mon, Oct 13, 2008 at 3:30 PM, Jukka Zitting <[EMAIL PROTECTED] > wrote: Just a final heads up that, based on the majority vote, I will be implementing this policy change tonight unless anyone wants to propose an alternative policy. See revision 704280. It is now OK for podlings to deploy approved releases (that satisfy the labeling and disclaimer requirements) to the central Maven repository through m2-ibiblio-rsync-repository. BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Jukka, Are you intending here to just redirect poddlings distribution management to: http://people.apache.org/repo/m2-ibiblio-rsync-repository/ Do you want me to sync the existing repository here: http://people.apache.org/repo/m2-incubating-repository/ to http://people.apache.org/repo/m2-ibiblio-rsync-repository/ Or are you handling that? On 13-Oct-08, at 4:00 PM, Jukka Zitting wrote: Hi, On Mon, Oct 13, 2008 at 3:30 PM, Jukka Zitting <[EMAIL PROTECTED] > wrote: Just a final heads up that, based on the majority vote, I will be implementing this policy change tonight unless anyone wants to propose an alternative policy. See revision 704280. It is now OK for podlings to deploy approved releases (that satisfy the labeling and disclaimer requirements) to the central Maven repository through m2-ibiblio-rsync-repository. BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Thanks, Jukka--- Very much admire your leadership on navigating us through a decision making process on this tricky issue. Not to mention your peaceful attitude in the midst of much passion. cheers, WILL On Mon, Oct 13, 2008 at 4:00 PM, Jukka Zitting <[EMAIL PROTECTED]>wrote: > Hi, > > On Mon, Oct 13, 2008 at 3:30 PM, Jukka Zitting <[EMAIL PROTECTED]> > wrote: > > Just a final heads up that, based on the majority vote, I will be > > implementing this policy change tonight unless anyone wants to propose > > an alternative policy. > > See revision 704280. > > It is now OK for podlings to deploy approved releases (that satisfy > the labeling and disclaimer requirements) to the central Maven > repository through m2-ibiblio-rsync-repository. > > BR, > > Jukka Zitting > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Hi, On Mon, Oct 13, 2008 at 3:30 PM, Jukka Zitting <[EMAIL PROTECTED]> wrote: > Just a final heads up that, based on the majority vote, I will be > implementing this policy change tonight unless anyone wants to propose > an alternative policy. See revision 704280. It is now OK for podlings to deploy approved releases (that satisfy the labeling and disclaimer requirements) to the central Maven repository through m2-ibiblio-rsync-repository. BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Hi, On Mon, Oct 6, 2008 at 9:45 PM, Jukka Zitting <[EMAIL PROTECTED]> wrote: > So, unless within a week from now we start seeing constructive efforts > at forming an alternative policy (or clarifying the current > undocumented policy) that we could vote on, I will declare this vote > as passing and implement the proposed change based on the measured > majority. Just a final heads up that, based on the majority vote, I will be implementing this policy change tonight unless anyone wants to propose an alternative policy. BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
The central repository is not an Apache project's resource. We've always discussed issues of the central repository in private (except for technical details of syncing other project repositories) and as far as policy goes it's the Maven PMC that will sets it. Members can see the list and we're fine with that. We already know what everyone and their uncle wants and it's unlikely a productive discussion will ensue. You just have to look here to see that. We're not wasting our time in endless debate. We'll decide, take feedback, adjust, and move on. We're actually going to setup a group call to discuss the issues on the table. So by next week we'll stuff for people to discuss. As far as Maven development goes, we work like just like every other project, the repository is different and affects every project and organization. What we are deciding is beyond the realm of Apache. On 7-Oct-08, at 11:23 AM, Doug Cutting wrote: Jason van Zyl wrote: The central repository is the Maven PMC's business. What results will be public policy but we'd like to avoid the banter of the misinformed so we can arrive at a decision quickly. I'd love to avoid the banter of the misinformed too, but that's not the way Apache projects are supposed to work, is it? Private lists should only be used for things which cannot be discussed in public, e.g., personnel issues, security breaches, etc. Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Jason van Zyl wrote: The central repository is the Maven PMC's business. What results will be public policy but we'd like to avoid the banter of the misinformed so we can arrive at a decision quickly. I'd love to avoid the banter of the misinformed too, but that's not the way Apache projects are supposed to work, is it? Private lists should only be used for things which cannot be discussed in public, e.g., personnel issues, security breaches, etc. Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
On 7-Oct-08, at 12:02 AM, Niclas Hedhman wrote: On Tue, Oct 7, 2008 at 11:47 AM, Jason van Zyl <[EMAIL PROTECTED]> wrote: The central repository is the Maven PMC's business. What results will be public policy but we'd like to avoid the banter of the misinformed so we can arrive at a decision quickly. Yes, although the PMC is expected to do all non-sensitive discussion on the public dev@ list. But, so far I think the central repo has served the Java communities (not only Apache) very well. It allows sync'ing from other repository hosts, which has made life a lot easier for smaller projects. That said, I think that Maven should move away from a central repository, and instead go with distributed ones and possibly harness the power of search engines (Yahoo RDF?) to locate stuff everywhere. This is already possible with Nexus (http://nexus.sonatype.org). Nexus, or the Nexus CLI tool, produces a Lucene index which Nexus uses to create a federated searching and retrieval mechanism. One instance of Nexus can proxy any other Maven repository -- a repository manager or normal webserver -- and with the presence of the Nexus index allows federated searching and retrieval of artifacts through that single instance. Some groups are already starting to provide Nexus indices: http://docs.codehaus.org/display/M2ECLIPSE/Nexus+Indexed+Maven+Repositories This means you as a user can setup Nexus locally, create proxied repositories and get access to the contents of those repositories. So if everyone did this we could federate all the repositories around the world and then central just becomes a switchboard. This would be great as it would distribute the load around, but I think we still might want to collect everything in one place for safety. To be able to do that securely, some clever security mechanisms must first be developed, and since that is in line with security-concerned people, I think it is a good thing to do so. "How hard can it be?", considering the expertise around detailing the requirements almost at code level, right ;-) ? Mercury will support PGP validation, and we are building support for PGP into Nexus so the indices could be retrieved and validated, and subsequent retrieval of artifacts could then also be validated. The technology is pretty much there to do what you're asking for but producing the indices in all the repositories will take time. But people are doing because it also provides value in the IDEs. m2eclipse, Netbeans, and IDEA are already integrating Nexus index technology to provide full POM auto-completion support, and we also use the index to find Maven plugins, Maven archetypes, and flag artifacts as having sources, javadocs, and valid checksums and signatures. So people will create indices to get the value in IDEs and as a consequence federating everything is possible. Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
On Tue, Oct 7, 2008 at 11:47 AM, Jason van Zyl <[EMAIL PROTECTED]> wrote: > The central repository is the Maven PMC's business. What results will be > public policy but we'd like to avoid the banter of the misinformed so we can > arrive at a decision quickly. Yes, although the PMC is expected to do all non-sensitive discussion on the public dev@ list. But, so far I think the central repo has served the Java communities (not only Apache) very well. It allows sync'ing from other repository hosts, which has made life a lot easier for smaller projects. That said, I think that Maven should move away from a central repository, and instead go with distributed ones and possibly harness the power of search engines (Yahoo RDF?) to locate stuff everywhere. To be able to do that securely, some clever security mechanisms must first be developed, and since that is in line with security-concerned people, I think it is a good thing to do so. "How hard can it be?", considering the expertise around detailing the requirements almost at code level, right ;-) ? Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
The central repository is the Maven PMC's business. What results will be public policy but we'd like to avoid the banter of the misinformed so we can arrive at a decision quickly. On 6-Oct-08, at 10:22 AM, Noel J. Bergman wrote: Jason van Zyl wrote: The discussions are taking place on the Maven PMC list. If you are a member you can join the list. Why are those discussions taking place on a private, closed, list instead of an open one? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- Simplex sigillum veri. (Simplicity is the seal of truth.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Hi, On Wed, Sep 24, 2008 at 3:40 PM, Jukka Zitting <[EMAIL PROTECTED]> wrote: > This is a slight majority (of binding votes) for accepting the > proposed change, but given the clear lack of consensus and the > concerns voiced about that, I unfortunately need to conclude that this > issue should be tabled until better consensus is reached. The followup discussion seems to be running in circles, with no clear compromises or alternative solutions being presented. Meanwhile a few opponents of this proposal have mentioned that their opinion has changed and a few others that they'd accept the majority decision and that we should move on. So, unless within a week from now we start seeing constructive efforts at forming an alternative policy (or clarifying the current undocumented policy) that we could vote on, I will declare this vote as passing and implement the proposed change based on the measured majority. BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Jason van Zyl wrote: > The discussions are taking place on the Maven PMC list. If you are a > member you can join the list. Why are those discussions taking place on a private, closed, list instead of an open one? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
On Sat, Oct 4, 2008 at 12:45 AM, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: > Color me confused again, but during setup and formation of the Incubator, > a podling had to graduate before doing a release. It was rather well > established before this rule was modified, but it seems that this change > resulted in a number of different interpretations, some of which aren't > compatible with the ASF license. I will support the "initial intent" of no releases out of Incubator. This not only puts an end to this discussion, incl Maven's stance that policy enforcement is not their responsibility, but also accelerates the need to graduate for podlings and hopefully make incubation periods shorter. I would also move for requirement that Mentors remain PMC members of the graduated project and overseas the initial releases. Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
The discussions are taking place on the Maven PMC list. If you are a member you can join the list. On 4-Oct-08, at 8:31 AM, Gilles Scokart wrote: 2008/10/3 Jason van Zyl <[EMAIL PROTECTED]>: On 2-Oct-08, at 9:19 PM, Noel J. Bergman wrote: Emmanuel Lecharny wrote: Better a bad decision than no decision, otherwise, soon, nobody will vote anymore... Not really. Consider that there appears to be a clear consensus that if Maven were to fix the download situation, requiring that users approve the user of Incubator artifacts, rather than transparently use them, many of the -1 would be +1. That's unlikely to happen. We're not going to be implementing policy enforcement for you. Our opinion is forming in the Maven PMC that we will not enforce third party policy but will adhere to the legal distribution rights set forth by the license. All PMC members who have voiced an opinion thus far have this opinion, Where does this dicussion took places? Is there a thread we can read? but we are scheduling a call for next week and we will have a decision and stated policy shortly. We will keep you posted when we reach a decision. It appears that the Maven community is finally getting a clue, and we can hope for a resolution, perhaps 6 months out or less if they don't falter. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gilles Scokart - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
2008/10/3 Jason van Zyl <[EMAIL PROTECTED]>: > > On 2-Oct-08, at 9:19 PM, Noel J. Bergman wrote: > >> Emmanuel Lecharny wrote: >> >>> Better a bad decision than no decision, otherwise, soon, nobody will >>> vote anymore... >> >> Not really. Consider that there appears to be a clear consensus that if >> Maven were to fix the download situation, requiring that users approve the >> user of Incubator artifacts, rather than transparently use them, many of >> the -1 would be +1. >> > > That's unlikely to happen. We're not going to be implementing policy > enforcement for you. > > Our opinion is forming in the Maven PMC that we will not enforce third party > policy but will adhere to the legal distribution rights set forth by the > license. All PMC members who have voiced an opinion thus far have this > opinion, Where does this dicussion took places? Is there a thread we can read? > but we are scheduling a call for next week and we will have a > decision and stated policy shortly. We will keep you posted when we reach a > decision. > >> It appears that the Maven community is finally getting a clue, and we can >> hope for a resolution, perhaps 6 months out or less if they don't falter. >> >>--- Noel >> >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > jason at sonatype dot com > -- > > A man enjoys his work when he understands the whole and when he > is responsible for the quality of the whole > > -- Christopher Alexander, A Pattern Language > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Gilles Scokart - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Noel J. Bergman wrote: > William A. Rowe, Jr. wrote: > >> Jukka Zitting wrote: > >>> Does the ASF "endorse" these releases, and what does that endorsement mean? > >> yes... > > You are talking about a legal licensing matter, whereas discussion during the > setup and formation of the Incubator was quite clear that Incubator releases > are NOT to carry the ASF's imprimatur and unfettered brand. Hence the > restrictions and disclaimer requirements. Color me confused again, but during setup and formation of the Incubator, a podling had to graduate before doing a release. It was rather well established before this rule was modified, but it seems that this change resulted in a number of different interpretations, some of which aren't compatible with the ASF license. Nobody is disputing the need for DISCLAIMER at the same visibility as the LICENSE and NOTICE files. But Maven doesn't demand click through license acceptance, so click through disclaimers make little sense, either. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
On 2-Oct-08, at 9:19 PM, Noel J. Bergman wrote: Emmanuel Lecharny wrote: Better a bad decision than no decision, otherwise, soon, nobody will vote anymore... Not really. Consider that there appears to be a clear consensus that if Maven were to fix the download situation, requiring that users approve the user of Incubator artifacts, rather than transparently use them, many of the -1 would be +1. That's unlikely to happen. We're not going to be implementing policy enforcement for you. Our opinion is forming in the Maven PMC that we will not enforce third party policy but will adhere to the legal distribution rights set forth by the license. All PMC members who have voiced an opinion thus far have this opinion, but we are scheduling a call for next week and we will have a decision and stated policy shortly. We will keep you posted when we reach a decision. It appears that the Maven community is finally getting a clue, and we can hope for a resolution, perhaps 6 months out or less if they don't falter. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Emmanuel Lecharny wrote: > Better a bad decision than no decision, otherwise, soon, nobody will > vote anymore... Not really. Consider that there appears to be a clear consensus that if Maven were to fix the download situation, requiring that users approve the user of Incubator artifacts, rather than transparently use them, many of the -1 would be +1. It appears that the Maven community is finally getting a clue, and we can hope for a resolution, perhaps 6 months out or less if they don't falter. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
William A. Rowe, Jr. wrote: > Jukka Zitting wrote: > > This is a slight majority (of binding votes) for accepting the > > proposed change, but given the clear lack of consensus and the > > concerns voiced about that, I unfortunately need to conclude that this > > issue should be tabled until better consensus is reached. > Nonsense. That's as if to say [VOTE] was actually supposed to be [POLL]. > A decision, however frustrating, has been reached. Actually, Jukka's approach is correct. Greg Stein has discussed this sort of situation on multiple occasions with the same conclusion and guidance as Jukka. > > Does the ASF "endorse" these releases, and what does that endorsement mean? > yes... You are talking about a legal licensing matter, whereas discussion during the setup and formation of the Incubator was quite clear that Incubator releases are NOT to carry the ASF's imprimatur and unfettered brand. Hence the restrictions and disclaimer requirements. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
On Fri, Sep 26, 2008 at 9:55 AM, William A. Rowe, Jr. <[EMAIL PROTECTED]>wrote: > Matthieu Riou wrote: > > > > I've also looked at the mentors votes, those who are basically running > this > > place. I'm a small player but Craig mentors 6 poddlings, Jim, Henning and > > Jukka 4 and Doug 3. I'm not saying their votes count more than others, > just > > that when those people disagree, we should listen. > > Ahhh, and by ommission I suspect you've failed to count those who have > mentored projects to graduation, and into the graveyard. No omission, just laziness I must confess :) Do we have good records for past mentorships? I've checked the project.xml but not all podlings have listed their mentors (even the current ones, like shindig - nudge). Matthieu > Valuable lessons > there, in both. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Matthieu Riou wrote: > > I've also looked at the mentors votes, those who are basically running this > place. I'm a small player but Craig mentors 6 poddlings, Jim, Henning and > Jukka 4 and Doug 3. I'm not saying their votes count more than others, just > that when those people disagree, we should listen. Ahhh, and by ommission I suspect you've failed to count those who have mentored projects to graduation, and into the graveyard. Valuable lessons there, in both. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
On Fri, Sep 26, 2008 at 5:31 AM, Jukka Zitting <[EMAIL PROTECTED]>wrote: > Hi, > > On Thu, Sep 25, 2008 at 12:58 AM, Niall Pemberton > <[EMAIL PROTECTED]> wrote: > > If this vote doesn't pass then we need to re-write the rules to > > define how much of a majority overturns the status quo. > > I'm following http://www.apache.org/foundation/voting.html and the > express wish of our PMC chair. I think both are well founded. > > > Perhaps two thrids, perhaps no negative votes. If this policy isn't > > implemented, then I think all the people who voted +1 at least deserve > > a definition of how short we fell of passing this vote and what the bar > is. > > The way I see it, we make decisions based on consensus, not numbers. > On procedural issues we define consensus to be the majority opinion, > but there's a clear reservation for cases where it's unclear whether > the measured majority is representative of the whole community. > I've also looked at the mentors votes, those who are basically running this place. I'm a small player but Craig mentors 6 poddlings, Jim, Henning and Jukka 4 and Doug 3. I'm not saying their votes count more than others, just that when those people disagree, we should listen. Matthieu > > This vote has made it quite clear that we have a much deeper > disagreement over the status of incubating releases, and that we > really should reach some consensus on that before nailing down > decisions on release distribution. > > BR, > > Jukka Zitting > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Hi, On Thu, Sep 25, 2008 at 12:58 AM, Niall Pemberton <[EMAIL PROTECTED]> wrote: > If this vote doesn't pass then we need to re-write the rules to > define how much of a majority overturns the status quo. I'm following http://www.apache.org/foundation/voting.html and the express wish of our PMC chair. I think both are well founded. > Perhaps two thrids, perhaps no negative votes. If this policy isn't > implemented, then I think all the people who voted +1 at least deserve > a definition of how short we fell of passing this vote and what the bar is. The way I see it, we make decisions based on consensus, not numbers. On procedural issues we define consensus to be the majority opinion, but there's a clear reservation for cases where it's unclear whether the measured majority is representative of the whole community. This vote has made it quite clear that we have a much deeper disagreement over the status of incubating releases, and that we really should reach some consensus on that before nailing down decisions on release distribution. BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
On Thu, Sep 25, 2008 at 5:15 AM, Doug Cutting <[EMAIL PROTECTED]> wrote: > This is the crux of the issue. > Do releases from the Incubator project differ from those of other projects? The people who created the Incubator should be able to answer this question. IMHO (I didn't vote), what we all think for our convenience shouldn't be muddled up with "What was the intention of the Incubator?" from the Devil's Mouth (The people who constructed this some 5-6 years ago). There are voices here saying; Incubator releases are just another release from ASF. With RAT and highly concerned PMC individuals, the Incubator releases are at least as legally safe as any other ASF project. whereas some others are on the track of; ASF does not "endorse" Incubator releases. So, IF we could all agree that the above is somewhat the essence or crux of the issue, and mostly true, then we are looking at "What does 'endorse' mean?". Well, if Incubator should really by totally legally safe, then I think the Mentors+PMC really need to step up to make that a reality, and the "endorsement" will only come down to; "ASF does not yet think this community will make it." But that is not a guarantee for any of our project communities anyway... So, that leaves me with a simple conclusion; The Incubator is a training ground for incoming projects. We don't let the podlings move on until they are "fit" and understand what ASF is all about. While being a podling, they are effectively a subproject in Incubator (another umbrella ;-) ), where the PMC ensures that all releases are legally sane, and that the Incubator PMC is the community that has the ultimate responsibility of releases. HENCE, releases should be treated no differently... no "-incubating" and no special distro channels needed. BUT, that also means; We should be a lot more concerned over projects arriving, and not blindly accept whatever sounds cool. Well, I hate my own reasoning as I think Incubator is missing the mark and becoming an Elephant in the Fridge (don't ask)... bah! Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
William A. Rowe, Jr. wrote: > David Crossley wrote: > > William A. Rowe, Jr. wrote: > > > > [snip] > >> I liked the way you put the question; it's not up to incubator project to > >> set the rules for Maven. If the maven PMC decides that these incubator > >> releases don't belong in the primary repository, that's their call. But > >> this vote makes clear that the incubator has nothing to say about an > >> artifact's distribution once the release vote is finalized. > > > > Other than this important statement from > > http://incubator.apache.org/incubation/Incubation_Policy.html#Releases > > "Releases for podling MUST be distributed through > > www.apache.org/dist/incubator/podling" > > Exactly. This doesn't state that "Releases for podling must be EXCLUSIVELY > distributed through www.a.o/dist/incubator/podling". > > It was a statement to quit posting the release artifacts in the un-mirrored > corners, and that these are the first initial official release paths. > Previously these were scattered throughout on un-mirrored servers in a > fairly haphazard way. > > So they must be shipped through /dist/incubator/podling or there is no > assertion that they are releases. Once there, they travel unassisted > to dozens of mirror servers and on to other locations and uses. We are getting to the nub of it. This is beyond any particular build system. We have an infrastructure already, with our mirror system. If every project would distribute not only their primary source releases from there, but also secondary artefacts (e.g. jars, poms, ivys, zips, whatever). These all would have signatures and checksums. Then any build system can rely on that distribution mirror infrastructure. There is a beautiful gem with our mirror system that i reckon is underutilised. It can generate an xml list of the preferred mirrors. Therefore it can be automated. Over the last few days i have been taking some steps to solve our Apache Forrest plugin distribution system, and use the mirror system to do it. Made good progress on that with an Ant-based build. (If someone wants a demo of the core part then i can stick it in my home directory.) Anyway my point is that any build system (Maven, Ivy, Ant, etc.) can rely on our mirror infrastructure if we populate it in a consistent manner. They can replicate it from the official source to maintain their own mirrors. We don't need to worry. In the Incubator case, we do need to find ways to make people aware of what they are using. -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
On Wed, Sep 24, 2008 at 2:21 PM, William A. Rowe, Jr. <[EMAIL PROTECTED]>wrote: > Jukka Zitting wrote: > >> Of which we have two; released, or not released, and that's a product > >> of oversight and a [VOTE]. There are no magical in-betweens. > > > > As evidenced by this vote this is hardly the consensus. See comments > > like "incubating releases to be treated as full Apache releases" or > > "incubator artifacts are distributed the same way as 'regular' > > artifacts". There is clearly a widely held feeling that incubating > > releases are different than "normal" ASF releases. > > Can you point me to any document which defines the code, social, and/or > legal difference between them? If not I'd humbly suggest we are still > stumbling over fud. > I'm getting mildly annoyed by your insistence. We can all disagree and it's fine, hopefully the IPMC is mature enough to find a way to solve this (like Emmanuel proposed for example). But I don't really understand why you keep on pressing Jukka and tried to declare the vote as irrelevant. Matthieu > > Bill > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
David Crossley wrote: > William A. Rowe, Jr. wrote: > > [snip] >> I liked the way you put the question; it's not up to incubator project to >> set the rules for Maven. If the maven PMC decides that these incubator >> releases don't belong in the primary repository, that's their call. But >> this vote makes clear that the incubator has nothing to say about an >> artifact's distribution once the release vote is finalized. > > Other than this important statement from > http://incubator.apache.org/incubation/Incubation_Policy.html#Releases > "Releases for podling MUST be distributed through > www.apache.org/dist/incubator/podling" Exactly. This doesn't state that "Releases for podling must be EXCLUSIVELY distributed through www.a.o/dist/incubator/podling". It was a statement to quit posting the release artifacts in the un-mirrored corners, and that these are the first initial official release paths. Previously these were scattered throughout on un-mirrored servers in a fairly haphazard way. So they must be shipped through /dist/incubator/podling or there is no assertion that they are releases. Once there, they travel unassisted to dozens of mirror servers and on to other locations and uses. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
William A. Rowe, Jr. wrote:
> Jukka Zitting wrote:
> >
[snip]
>
> > Are incubating releases official releases of the ASF?
>
> Yes. Otherwise they must be removed from ASF servers.
> There's no middle ground.
>
[snip]
>
> > How strong disclaimers are needed and what level of explicit
> > acknowledgement from users is required?
>
> how much more explicit do you want? Well, we've added that a disclaimer
> in the package (not a click-through requirement) that this is an incubating
> artifact, and each has a naming convention of {podling}-incubating.
Good. Recently i also added a disclaimer to the top-level
of our mirror system www.apache.org/dist/incubator/
and proposed [1] that each podling do the same, i.e. follow
the ASF release guidelines. This assists the people who
reach the mirrors by other means. It tries to explain and
then redirect them to each podling's download page where
they should have other disclaimers and encouragement to
assist the project to graduate.
[1] header notices for mirrors a.o/dist/incubator
http://marc.info/?t=12217128714
Trying to re-direct this aspect of the discussion to
that thread.
[snip]
> I liked the way you put the question; it's not up to incubator project to
> set the rules for Maven. If the maven PMC decides that these incubator
> releases don't belong in the primary repository, that's their call. But
> this vote makes clear that the incubator has nothing to say about an
> artifact's distribution once the release vote is finalized.
Other than this important statement from
http://incubator.apache.org/incubation/Incubation_Policy.html#Releases
"Releases for podling MUST be distributed through
www.apache.org/dist/incubator/podling"
-David
> Please remember the earliest examples, where IBM distributed the very
> earliest Geronimo incubating releases through other channels, as was
> their right do so. Let's call this decision on "Allow extra release
> distribution channels" approved 15:12, let people who want to use
> the Maven channel take this thread up with Maven folks, and let this
> thread die at last.
>
> Bill
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Niall Pemberton wrote: This is a slight majority (of binding votes) for accepting the proposed change, but given the clear lack of consensus and the concerns voiced about that, I unfortunately need to conclude that this issue should be tabled until better consensus is reached. If this was a release vote then I could understand it - since people judge the importance of issues differently - and fixing the issues and moving on to a new release is often easier since it maintains consensus. On this issue though, its been well debated several times - it s clear that there won't be consensus in the near future - so why should the minority get their way when they lost the vote? If this vote doesn't pass then we need to re-write the rules to define how much of a majority overturns the status quo. Perhaps two thrids, perhaps no negative votes. If this policy isn't implemented, then I think all the people who voted +1 at least deserve a definition of how short we fell of passing this vote and what the bar is. having voted -1 myself, and even if I still think that it's not a result I like, I also think that we need to move on and consider the vote as positive. If we discover after a few months that it was a bad idea, then we can vote again, and fix the problem. Better a bad decision than no decision, otherwise, soon, nobody will vote anymore... And about the other concerns, we can also start some discussions and vote, too. -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
On Wed, Sep 24, 2008 at 2:40 PM, Jukka Zitting <[EMAIL PROTECTED]> wrote: > Hi, > > On Wed, Sep 10, 2008 at 8:34 AM, Jukka Zitting <[EMAIL PROTECTED]> wrote: >> Please vote on accepting or rejecting this policy change! > > The vote ends with the following 15 +1, 12 -1, and one 0 binding votes. > >+1 Bertrand Delacretaz >+1 Brett Porter >+1 Bruce Snyder >+1 Davanum Srinivas >+1 Doug Cutting >+1 Guillaume Nodet >+1 James Strachan >+1 Jason van Zyl >+1 Jeffrey Genender >+1 Jukka Zitting >+1 Martin Dashorst >+1 Niall Pemberton >+1 Roland Weber >+1 Upayavira >+1 William Rowe > > 0 Thomas Fischer > >-1 Ant Elder >-1 Craig Russell >-1 Emmanuel Lecharny >-1 Henning Schmiedehausen >-1 Jim Jagielski >-1 Justin Erenkrantz >-1 Kevan Miller >-1 Matt Hogstrom >-1 Matthieu Riou >-1 Noel J. Bergman >-1 Paul Querna >-1 Will Glass-Husain > > The following eight +1 and one -1 non-binding votes were also cast: > >+1 Assaf Arkin >+1 Eelco Hillenius >+1 Dan Diephouse >+1 Daniel Kulp >+1 Felix Meschberger >+1 Les Hazlewood >+1 Niklas Gustavsson >+1 Stephen Duncan Jr > >-1 Sebastian Bazley > > This is a slight majority (of binding votes) for accepting the > proposed change, but given the clear lack of consensus and the > concerns voiced about that, I unfortunately need to conclude that this > issue should be tabled until better consensus is reached. If this was a release vote then I could understand it - since people judge the importance of issues differently - and fixing the issues and moving on to a new release is often easier since it maintains consensus. On this issue though, its been well debated several times - it s clear that there won't be consensus in the near future - so why should the minority get their way when they lost the vote? If this vote doesn't pass then we need to re-write the rules to define how much of a majority overturns the status quo. Perhaps two thrids, perhaps no negative votes. If this policy isn't implemented, then I think all the people who voted +1 at least deserve a definition of how short we fell of passing this vote and what the bar is. Niall > The main impression I got from the related discussion is that the main > concern is not that much the security or transparency of the Maven > repository but rather the status of incubating releases in general. > > Are incubating releases official releases of the ASF? Does the ASF > "endorse" these releases, and what does that endorsement mean? How > strong disclaimers are needed and what level of explicit > acknowledgement from users is required? Until we have a clearer policy > on what we actually require of incubating releases and their > distribution, it seems premature to debate whether the Maven > repository meets those requirements. > > So, before reopening this release distribution issue, I would expect > us to clarify the policy on incubating releases. > > BR, > > Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Jukka Zitting wrote: >> Of which we have two; released, or not released, and that's a product >> of oversight and a [VOTE]. There are no magical in-betweens. > > As evidenced by this vote this is hardly the consensus. See comments > like "incubating releases to be treated as full Apache releases" or > "incubator artifacts are distributed the same way as 'regular' > artifacts". There is clearly a widely held feeling that incubating > releases are different than "normal" ASF releases. Can you point me to any document which defines the code, social, and/or legal difference between them? If not I'd humbly suggest we are still stumbling over fud. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Jukka Zitting wrote: There is clearly a widely held feeling that incubating releases are different than "normal" ASF releases. This is the crux of the issue. I fail to see how they are fundamentally different. Releases and the release process is one of the most standardized things in the ASF: 3+1 PMC votes, distributed on www.apache.org/dist, etc. Do releases from the Incubator project differ from those of other projects? I've always thought felt that the Incubator is just another project, one that specializes in nursing new projects to maturity. But it has no special privileges or responsibilities, does it? Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Hi, On Wed, Sep 24, 2008 at 8:17 PM, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: > Jukka Zitting wrote: >> This is a slight majority (of binding votes) for accepting the >> proposed change, but given the clear lack of consensus and the >> concerns voiced about that, I unfortunately need to conclude that this >> issue should be tabled until better consensus is reached. > > Nonsense. That's as if to say [VOTE] was actually supposed to be [POLL]. > A decision, however frustrating, has been reached. >From http://www.apache.org/foundation/voting.html, on majority votes: If the number of votes seems too small to be representative of a community consensus, the issue is typically not pursued. We had 28 binding votes out of 85 and the difference in result was just three votes, which in my opinion is "too small to be representative". > I suspect some would prefer the choice against their preference just be > implemented, over having this thread persist ad infinitum. If Noel or other people who voted against the proposal feel that the result is representative, then I will implement the proposed change >> The main impression I got from the related discussion is that the main >> concern is not that much the security or transparency of the Maven >> repository but rather the status of incubating releases in general. > > Of which we have two; released, or not released, and that's a product > of oversight and a [VOTE]. There are no magical in-betweens. As evidenced by this vote this is hardly the consensus. See comments like "incubating releases to be treated as full Apache releases" or "incubator artifacts are distributed the same way as 'regular' artifacts". There is clearly a widely held feeling that incubating releases are different than "normal" ASF releases. BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Jukka Zitting wrote:
>
> The vote ends with the following 15 +1, 12 -1, and one 0 binding votes.
>
> This is a slight majority (of binding votes) for accepting the
> proposed change, but given the clear lack of consensus and the
> concerns voiced about that, I unfortunately need to conclude that this
> issue should be tabled until better consensus is reached.
Nonsense. That's as if to say [VOTE] was actually supposed to be [POLL].
A decision, however frustrating, has been reached. I suspect some would
prefer the choice against their preference just be implemented, over having
this thread persist ad infinitum.
This is a contentious issue. Mostly, because the change - from pseudo
incubator release artifacts in a non-release location - into proper
releases available from www.a.o/dist/incubator/ - was never reflected
in other relevant policies. In hindsight, it's clear they were.
RAT and other methodologies helped us validate the legal aspects of
the ASF releases to the point that this is not uncomfortable anymore.
> The main impression I got from the related discussion is that the main
> concern is not that much the security or transparency of the Maven
> repository but rather the status of incubating releases in general.
Of which we have two; released, or not released, and that's a product
of oversight and a [VOTE]. There are no magical in-betweens. There
are other artifacts, of course. Snapshots are not released. Nightly
builds are not released. Source packages are our official releases.
Binaries are also released when built from release source packages.
> Are incubating releases official releases of the ASF?
Yes. Otherwise they must be removed from ASF servers. There's no
middle ground.
> Does the ASF
> "endorse" these releases, and what does that endorsement mean?
yes...
7. Disclaimer of Warranty. Unless required by applicable law or
agreed to in writing, Licensor provides the Work (and each
Contributor provides its Contributions) on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied, including, without limitation, any warranties or conditions
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
PARTICULAR PURPOSE. You are solely responsible for determining the
appropriateness of using or redistributing the Work and assume any
risks associated with Your exercise of permissions under this License.
> How strong disclaimers are needed and what level of explicit
> acknowledgement from users is required?
how much more explicit do you want? Well, we've added that a disclaimer
in the package (not a click-through requirement) that this is an incubating
artifact, and each has a naming convention of {podling}-incubating.
Most folks main complaint is that incubator makes things more complicated
than they are or need to be. Why help to persist that modus operandi, or
subvert the decision of the list?
I liked the way you put the question; it's not up to incubator project to
set the rules for Maven. If the maven PMC decides that these incubator
releases don't belong in the primary repository, that's their call. But
this vote makes clear that the incubator has nothing to say about an
artifact's distribution once the release vote is finalized.
Please remember the earliest examples, where IBM distributed the very
earliest Geronimo incubating releases through other channels, as was
their right do so. Let's call this decision on "Allow extra release
distribution channels" approved 15:12, let people who want to use
the Maven channel take this thread up with Maven folks, and let this
thread die at last.
Bill
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Hi, On Wed, Sep 10, 2008 at 8:34 AM, Jukka Zitting <[EMAIL PROTECTED]> wrote: > Please vote on accepting or rejecting this policy change! The vote ends with the following 15 +1, 12 -1, and one 0 binding votes. +1 Bertrand Delacretaz +1 Brett Porter +1 Bruce Snyder +1 Davanum Srinivas +1 Doug Cutting +1 Guillaume Nodet +1 James Strachan +1 Jason van Zyl +1 Jeffrey Genender +1 Jukka Zitting +1 Martin Dashorst +1 Niall Pemberton +1 Roland Weber +1 Upayavira +1 William Rowe 0 Thomas Fischer -1 Ant Elder -1 Craig Russell -1 Emmanuel Lecharny -1 Henning Schmiedehausen -1 Jim Jagielski -1 Justin Erenkrantz -1 Kevan Miller -1 Matt Hogstrom -1 Matthieu Riou -1 Noel J. Bergman -1 Paul Querna -1 Will Glass-Husain The following eight +1 and one -1 non-binding votes were also cast: +1 Assaf Arkin +1 Eelco Hillenius +1 Dan Diephouse +1 Daniel Kulp +1 Felix Meschberger +1 Les Hazlewood +1 Niklas Gustavsson +1 Stephen Duncan Jr -1 Sebastian Bazley This is a slight majority (of binding votes) for accepting the proposed change, but given the clear lack of consensus and the concerns voiced about that, I unfortunately need to conclude that this issue should be tabled until better consensus is reached. The main impression I got from the related discussion is that the main concern is not that much the security or transparency of the Maven repository but rather the status of incubating releases in general. Are incubating releases official releases of the ASF? Does the ASF "endorse" these releases, and what does that endorsement mean? How strong disclaimers are needed and what level of explicit acknowledgement from users is required? Until we have a clearer policy on what we actually require of incubating releases and their distribution, it seems premature to debate whether the Maven repository meets those requirements. So, before reopening this release distribution issue, I would expect us to clarify the policy on incubating releases. BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Jukka Zitting wrote: > > I extended the vote "for another week", which IMHO clearly puts the > endpoint to this morning. As such, I will be closing the vote in a few > hours. :) Sounds great - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Hi, On Wed, Sep 24, 2008 at 5:45 AM, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: > Jukka Zitting wrote: >> Please vote on accepting or rejecting this policy change! This >> majority vote is open for a week and only votes from the Incubator PMC >> members are binding. > > Just as a point of reference, extending a vote for a given period of time > is a good thing to accommodate all input. Failing to set an endpoint isn't. > > Since at the 3-6 day timeframe you extended the vote, the 10 day timeframe > would have been appropriate, but you let that slide. I extended the vote "for another week", which IMHO clearly puts the endpoint to this morning. As such, I will be closing the vote in a few hours. > I'd suggest you cut this off about 10a GMT on the 24th, 2 at weeks This is exactly as planned and communicated. BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Jukka Zitting wrote: > Please vote on accepting or rejecting this policy change! This > majority vote is open for a week and only votes from the Incubator PMC > members are binding. Just as a point of reference, extending a vote for a given period of time is a good thing to accommodate all input. Failing to set an endpoint isn't. Since at the 3-6 day timeframe you extended the vote, the 10 day timeframe would have been appropriate, but you let that slide. I'd suggest you cut this off about 10a GMT on the 24th, 2 at weeks, if only to bring things to closure at last. That's about 28 hrs away. Infinite duration votes might as well not carry a [vote] subject. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Doug Cutting wrote: > > +1 All releases by ASF PMC's should be equal. If the Incubator PMC > isn't confident of a release then it shouldn't release it. The release > process should not just check legal concerns, but also the quality of > the code and its community. A responsible PMC should not release code > that sucks or that has a badly flawed community. WTF? Why not release code that sucks? W.R.T. the incubator, how do you persuade new people to come along and start fixing bugs that don't exist? Community, well, that's why they are called '-incubating' artifacts. A community may congeal around the incubating effort. It might not, so you just have to be doubly prepared to "keep both pieces". - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
I think incubating projects should go through "phases." The first phase is to make sure all IP concerns are cleared up. The second phase is where the project exhibits that it "gets" the Apache way of doing business by doing some internal-only releases (this is where package names would change and stuff of course). The third phase (don't know if any others would be required or not) would be the "community building" phase. I'd say that projects in phase 1 should not be allowed to do releases (duh). The releases done during phase 2 should be internal-only. The phase 3 releases should be allowed to be full fledged ASF releases. Phase 3 may not be necessary for some projects, if their community is proven to be "healthy" after phase 2. On Tue, Sep 23, 2008 at 6:15 PM, Doug Cutting <[EMAIL PROTECTED]> wrote: > Jukka Zitting wrote: >> >> [ ] +1 Yes, allow extra release distribution channels like the central >> Maven repository >> [ ] -1 No, keep the current policy > > +1 All releases by ASF PMC's should be equal. If the Incubator PMC isn't > confident of a release then it shouldn't release it. The release process > should not just check legal concerns, but also the quality of the code and > its community. A responsible PMC should not release code that sucks or that > has a badly flawed community. > > Doug > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
On Tue, Sep 23, 2008 at 3:15 PM, Doug Cutting <[EMAIL PROTECTED]> wrote: > Jukka Zitting wrote: >> >> [ ] +1 Yes, allow extra release distribution channels like the central >> Maven repository >> [ ] -1 No, keep the current policy > > +1 All releases by ASF PMC's should be equal. If the Incubator PMC isn't > confident of a release then it shouldn't release it. The release process > should not just check legal concerns, but also the quality of the code and > its community. A responsible PMC should not release code that sucks or that > has a badly flawed community. +1 Assaf > > Doug > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Will Glass-Husain wrote: It's very tempting to allow it, but in the end too dangerous to facilitate downloads that are hidden from the end user and may be undesireable. Folks using Maven are already getting "hidden" downloads. Why are incubating releases any more dangerous? Is the bar any lower for an incubating release? The incubating release process is a monitored release process, with oversight to make sure that it upholds Apache's ways. What undesirable bits are we including in incubator releases? Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
-1 from me. It's very tempting to allow it, but in the end too dangerous to facilitate downloads that are hidden from the end user and may be undesireable. I suggest incubating projects put "how-to's" on their front page describing how to link to the incubator repository. WILL On Tue, Sep 23, 2008 at 3:15 PM, Doug Cutting <[EMAIL PROTECTED]> wrote: > Jukka Zitting wrote: > >> [ ] +1 Yes, allow extra release distribution channels like the central >> Maven repository >> [ ] -1 No, keep the current policy >> > > +1 All releases by ASF PMC's should be equal. If the Incubator PMC isn't > confident of a release then it shouldn't release it. The release process > should not just check legal concerns, but also the quality of the code and > its community. A responsible PMC should not release code that sucks or that > has a badly flawed community. > > Doug > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Forio Business Simulations Will Glass-Husain [EMAIL PROTECTED] www.forio.com
Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Jukka Zitting wrote: [ ] +1 Yes, allow extra release distribution channels like the central Maven repository [ ] -1 No, keep the current policy +1 All releases by ASF PMC's should be equal. If the Incubator PMC isn't confident of a release then it shouldn't release it. The release process should not just check legal concerns, but also the quality of the code and its community. A responsible PMC should not release code that sucks or that has a badly flawed community. Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
+1. A release is a release is a release. If we are concerned about projects staying in the incubator, then let's ban them from releasing anymore. Or, say, only max five releases during incubation. But once a release is done under the ASL, there's not really much we can do to stop its onward distribution. Regards, Upayavira On Tue, 2008-09-23 at 09:00 -0400, Jim Jagielski wrote: > -1 (Binding) > > On Sep 22, 2008, at 6:41 PM, Paul Querna wrote: > > > -1, (Binding). > > > > (For the reasons explained by Craig and Justin in this Thread) > > > > Thanks, > > > > Paul > > > > 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 > >> On Sep 9, 2008, at 11:34 PM, Jukka Zitting wrote: > >>> Hi, > >>> > >>> We've had a number of long discussions about the incubating projects > >>> using the central Maven repository to distribute their releases. The > >>> current policy is that incubating releases should not go to there. > >>> The > >>> related discussion threads have died with no consensus but the issue > >>> still exists and affects many podlings. I would like to finally > >>> resolve the issue one way or another by calling the Incubator PMC to > >>> vote on the matter. > >>> > >>> In INCUBATOR-82 I have prepared a patch (also attached below) that > >>> changes the policy document to explicitly _allow_ extra distribution > >>> channels like the central Maven repository for incubating releases. > >>> Note that the proposed patch allows any such channels instead of > >>> focusing just on the Maven repository. Also, any releases must still > >>> be approved, comply with the disclaimer and naming rules, and be > >>> primarily distributed through the official > >>> http://www.apache.org/dist/incubator/ channel. > >>> > >>> Please vote on accepting or rejecting this policy change! This > >>> majority vote is open for a week and only votes from the Incubator > >>> PMC > >>> members are binding. > >>> > >>> [ ] +1 Yes, allow extra release distribution channels like the > >>> central > >>> Maven repository > >>> [ ] -1 No, keep the current policy > >>> > >>> My vote is +1 > >>> > >>> BR, > >>> > >>> Jukka Zitting > >>> > >>> Patch from https://issues.apache.org/jira/browse/INCUBATOR-82: > >>> > >>> Index: site-author/incubation/Incubation_Policy.xml > >>> === > >>> --- site-author/incubation/Incubation_Policy.xml(revision > >>> 692094) > >>> +++ site-author/incubation/Incubation_Policy.xml(working copy) > >>> @@ -489,6 +489,8 @@ > >>> > >>> Releases for podling MUST be distributed > >>> through > >>> http://www.apache.org/dist/incubator/podling. > >>> +In addition, the Podling MAY choose to distribute approved > >>> releases through > >>> +other channels like the central Maven repository. > >>> > >>> > >>> > >>> > >>> - > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >> Craig L Russell > >> Architect, Sun Java Enterprise System http://db.apache.org/jdo > >> 408 276-5638 mailto:[EMAIL PROTECTED] > >> P.S. A good JDO? O, Gasp! > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
-1 (Binding) On Sep 22, 2008, at 6:41 PM, Paul Querna wrote: -1, (Binding). (For the reasons explained by Craig and Justin in this Thread) Thanks, Paul 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 On Sep 9, 2008, at 11:34 PM, Jukka Zitting wrote: Hi, We've had a number of long discussions about the incubating projects using the central Maven repository to distribute their releases. The current policy is that incubating releases should not go to there. The related discussion threads have died with no consensus but the issue still exists and affects many podlings. I would like to finally resolve the issue one way or another by calling the Incubator PMC to vote on the matter. In INCUBATOR-82 I have prepared a patch (also attached below) that changes the policy document to explicitly _allow_ extra distribution channels like the central Maven repository for incubating releases. Note that the proposed patch allows any such channels instead of focusing just on the Maven repository. Also, any releases must still be approved, comply with the disclaimer and naming rules, and be primarily distributed through the official http://www.apache.org/dist/incubator/ channel. Please vote on accepting or rejecting this policy change! This majority vote is open for a week and only votes from the Incubator PMC members are binding. [ ] +1 Yes, allow extra release distribution channels like the central Maven repository [ ] -1 No, keep the current policy My vote is +1 BR, Jukka Zitting Patch from https://issues.apache.org/jira/browse/INCUBATOR-82: Index: site-author/incubation/Incubation_Policy.xml === --- site-author/incubation/Incubation_Policy.xml(revision 692094) +++ site-author/incubation/Incubation_Policy.xml(working copy) @@ -489,6 +489,8 @@ Releases for podling MUST be distributed through http://www.apache.org/dist/incubator/podling. +In addition, the Podling MAY choose to distribute approved releases through +other channels like the central Maven repository. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
-1, (Binding). (For the reasons explained by Craig and Justin in this Thread) Thanks, Paul 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 On Sep 9, 2008, at 11:34 PM, Jukka Zitting wrote: Hi, We've had a number of long discussions about the incubating projects using the central Maven repository to distribute their releases. The current policy is that incubating releases should not go to there. The related discussion threads have died with no consensus but the issue still exists and affects many podlings. I would like to finally resolve the issue one way or another by calling the Incubator PMC to vote on the matter. In INCUBATOR-82 I have prepared a patch (also attached below) that changes the policy document to explicitly _allow_ extra distribution channels like the central Maven repository for incubating releases. Note that the proposed patch allows any such channels instead of focusing just on the Maven repository. Also, any releases must still be approved, comply with the disclaimer and naming rules, and be primarily distributed through the official http://www.apache.org/dist/incubator/ channel. Please vote on accepting or rejecting this policy change! This majority vote is open for a week and only votes from the Incubator PMC members are binding. [ ] +1 Yes, allow extra release distribution channels like the central Maven repository [ ] -1 No, keep the current policy My vote is +1 BR, Jukka Zitting Patch from https://issues.apache.org/jira/browse/INCUBATOR-82: Index: site-author/incubation/Incubation_Policy.xml === --- site-author/incubation/Incubation_Policy.xml(revision 692094) +++ site-author/incubation/Incubation_Policy.xml(working copy) @@ -489,6 +489,8 @@ Releases for podling MUST be distributed through http://www.apache.org/dist/incubator/podling. +In addition, the Podling MAY choose to distribute approved releases through +other channels like the central Maven repository. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
On Sun, Sep 21, 2008 at 6:13 PM, Roland Weber <[EMAIL PROTECTED]> wrote: > Users who would care about "incubating" disclaimers will > find those via Maven too. Users who don't care will ignore > them no matter what you do. You can't force users to care. Although I agree with your standpoint, your argument doesn't hold water. Maven have the nastiness/"cool feature" that transitive dependencies are near invisible to users. So although projectA thinks that Incubating releases are Ok, projectB/companyC may not think so but think that projectA is pretty cool... One really need to go looking for them. Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
+1 (binding) They are releases, they are meant to go out to users, so let them get out. If podlings feel too comfortable in the Incubator, then take the direct approach: go to those podlings and make them feel uncomfortable. Block them from making any more incubating releases at all if you want to, but don't try to put artifical barriers on the distribution of the code that is released. Users who would care about "incubating" disclaimers will find those via Maven too. Users who don't care will ignore them no matter what you do. You can't force users to care. cheers, Roland Jukka Zitting wrote: I would like to finally resolve the issue one way or another Until somebody on the other way reopens it in a few months ;-( [ ] +1 Yes, allow extra release distribution channels like the central Maven repository [ ] -1 No, keep the current policy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Hi, On Thu, Sep 18, 2008 at 11:41 PM, William A. Rowe, Jr. <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] It's hardly on topic here. BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
On Thu, Sep 18, 2008 at 4:57 PM, sebb <[EMAIL PROTECTED]> wrote: > On 18/09/2008, Hiram Chirino <[EMAIL PROTECTED]> wrote: >> On Thu, Sep 18, 2008 at 2:26 PM, William A. Rowe, Jr. >> >> <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://open.iona.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Trust me I'm not trying to be difficult.. On Thu, Sep 18, 2008 at 4:53 PM, William A. Rowe, Jr. <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: >>> >>> On 18/09/2008, Hiram Chirino <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://open.iona.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
On 18/09/2008, Hiram Chirino <[EMAIL PROTECTED]> wrote: > On Thu, Sep 18, 2008 at 2:26 PM, William A. Rowe, Jr. > > <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
0. There were good reasons for both sides. Regards, Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
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 <[EMAIL PROTECTED]> wrote: On 18/09/2008, Hiram Chirino <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
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:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 exampleMy 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. Basicall
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
On Thu, Sep 18, 2008 at 3:07 PM, sebb <[EMAIL PROTECTED]> wrote: > On 18/09/2008, Hiram Chirino <[EMAIL PROTECTED]> wrote: >> On Thu, Sep 18, 2008 at 10:59 AM, sebb <[EMAIL PROTECTED]> wrote: >> > On 18/09/2008, Hiram Chirino <[EMAIL PROTECTED]> wrote: >> >> On Wed, Sep 17, 2008 at 9:42 PM, William A. Rowe, Jr. >> >> >> >> <[EMAIL PROTECTED]> 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 po
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Right.. It's part of the source distro or SVN. On Thu, Sep 18, 2008 at 3:10 PM, Jukka Zitting <[EMAIL PROTECTED]> wrote: > Hi, > > On Thu, Sep 18, 2008 at 9:08 PM, sebb <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://open.iona.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
On Thu, Sep 18, 2008 at 2:26 PM, William A. Rowe, Jr. <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Hi, On Thu, Sep 18, 2008 at 9:08 PM, sebb <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
On 18/09/2008, Jukka Zitting <[EMAIL PROTECTED]> wrote: > Hi, > > On Thu, Sep 18, 2008 at 8:26 PM, William A. Rowe, Jr. > > <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
On 18/09/2008, Hiram Chirino <[EMAIL PROTECTED]> wrote: > On Thu, Sep 18, 2008 at 10:59 AM, sebb <[EMAIL PROTECTED]> wrote: > > On 18/09/2008, Hiram Chirino <[EMAIL PROTECTED]> wrote: > >> On Wed, Sep 17, 2008 at 9:42 PM, William A. Rowe, Jr. > >> > >> <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > -- > > Regards, > Hiram > > Blog: http://hiramchirino.com > > Open Source SOA > http://open.iona.com > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Hi, On Thu, Sep 18, 2008 at 8:26 PM, William A. Rowe, Jr. <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
On Thu, Sep 18, 2008 at 10:26 AM, Daniel Kulp <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 exampleMy 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.
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
On Thu, Sep 18, 2008 at 10:59 AM, sebb <[EMAIL PROTECTED]> wrote: > On 18/09/2008, Hiram Chirino <[EMAIL PROTECTED]> wrote: >> On Wed, Sep 17, 2008 at 9:42 PM, William A. Rowe, Jr. >> >> <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://open.iona.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 exampleMy 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 >> > [EMAIL PROTECTED] >> > http://www.dankulp.com/blog >> > >> > - >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- > Daniel Kulp > [EMAIL PROTECTED] > http://www.dankulp.com/blog > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Davanum Srinivas :: http://davanum.wordpress.c
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
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 <[EMAIL PROTECTED]> 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 exampleMy 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 > > [EMAIL PROTECTED] > > http://www.dankulp.com/blog > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] -- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
"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 <[EMAIL PROTECTED]> 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 exampleMy 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 > [EMAIL PROTECTED] > http://www.dankulp.com/blog > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Davanum Srinivas :: http://davanum.wordpress.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Alternative proposition [Was: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
On Thu, Sep 18, 2008 at 1:48 AM, Gilles Scokart <[EMAIL PROTECTED]> wrote: > I think the vote (and discussions) about the use of extra distribution > channel is going in a bad direction. > > I would like to try to summarize the two positions, see if we could > not reconcile the two positions and found a better consensus. > > Here is what the 2 camps say: > +1 : say: >- We can not forbid the incubator artefact to be published in the > maven repository. Once an incubating release is done, anyone is free > to redistribute it. >- It bring benefits for the incubating project (more users, more > visibility) > > -1 say: >- It allow the user to ignore the disclaimer. >- It is useless. There is work around. >- We want to put obstacles to incubating project in order to > motivate > them to graduate. >- We should not take decision on it without consensus, so -1 is > better. >- The maven repository present some security issues > > I think the main reason of the -1 is to protect the name of Apache. > The incubating project are not allowed to have an excessive > fascination for the apache brand [1]. The incubating project should > not abuse the Apache brand. That's why the incubator distributions > are done only on channel well controlled by the ASF. > > I think both arguments are valuable. And it is maybe possible to > reconciliation them. > > The alternative proposition that I think could reconciliate both camp is: > Why not allow the incubating project to release to any channel they > want, provided that they don't use the apache name. > That's already allowed, the code is ASL 2.0. Anybody can build from sources or even take a given release and distribute it using whichever channel they want as long as it's not called Apache Foo. Several newly incubated projects have done this during their transition period. Matthieu > > > > PS: Please, don't discuss the specific case of the maven repository. > Start an other thread somewhere else if you want to discuss it. > > > -- > Gilles Scokart > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
On Thu, Sep 10, 2008 at 9:34 AM, "Jukka Zitting"
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> We've had a number of long discussions about the incubating projects
> using the central Maven repository to distribute their releases. The
> current policy is that incubating releases should not go to there. The
> related discussion threads have died with no consensus but the issue
> still exists and affects many podlings. I would like to finally
> resolve the issue one way or another by calling the Incubator PMC to
> vote on the matter.
>
> In INCUBATOR-82 I have prepared a patch (also attached below) that
> changes the policy document to explicitly _allow_ extra distribution
> channels like the central Maven repository for incubating releases.
> Note that the proposed patch allows any such channels instead of
> focusing just on the Maven repository. Also, any releases must still
> be approved, comply with the disclaimer and naming rules, and be
> primarily distributed through the official
> http://www.apache.org/dist/incubator/ channel.
>
> Please vote on accepting or rejecting this policy change! This
> majority vote is open for a week and only votes from the Incubator PMC
> members are binding.
>
> [ ] +1 Yes, allow extra release distribution channels like the central
> Maven repository
> [ ] -1 No, keep the current policy
+1
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://activemq.org/
Apache Camel - http://activemq.org/camel/
Apache ServiceMix - http://servicemix.org/
Blog: http://bruceblog.org/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
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 exampleMy 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 [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
On 18/09/2008, Hiram Chirino <[EMAIL PROTECTED]> wrote: > On Wed, Sep 17, 2008 at 9:42 PM, William A. Rowe, Jr. > > <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
+1 (non-binding) The current policy is silly. On Wed, Sep 10, 2008 at 8:34 AM, Jukka Zitting <[EMAIL PROTECTED]>wrote: > Hi, > > We've had a number of long discussions about the incubating projects > using the central Maven repository to distribute their releases. The > current policy is that incubating releases should not go to there. The > related discussion threads have died with no consensus but the issue > still exists and affects many podlings. I would like to finally > resolve the issue one way or another by calling the Incubator PMC to > vote on the matter. > > In INCUBATOR-82 I have prepared a patch (also attached below) that > changes the policy document to explicitly _allow_ extra distribution > channels like the central Maven repository for incubating releases. > Note that the proposed patch allows any such channels instead of > focusing just on the Maven repository. Also, any releases must still > be approved, comply with the disclaimer and naming rules, and be > primarily distributed through the official > http://www.apache.org/dist/incubator/ channel. > > Please vote on accepting or rejecting this policy change! This > majority vote is open for a week and only votes from the Incubator PMC > members are binding. > > [ ] +1 Yes, allow extra release distribution channels like the central > Maven repository > [ ] -1 No, keep the current policy > > My vote is +1 > > BR, > > Jukka Zitting > > Patch from https://issues.apache.org/jira/browse/INCUBATOR-82: > > Index: site-author/incubation/Incubation_Policy.xml > === > --- site-author/incubation/Incubation_Policy.xml(revision 692094) > +++ site-author/incubation/Incubation_Policy.xml(working copy) > @@ -489,6 +489,8 @@ > > Releases for podling MUST be distributed through > http://www.apache.org/dist/incubator/podling. > +In addition, the Podling MAY choose to distribute approved releases > through > +other channels like the central Maven repository. > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Dan Diephouse http://netzooid.com/blog
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
On Wed, Sep 17, 2008 at 9:42 PM, William A. Rowe, Jr. <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
On Wed, Sep 10, 2008 at 2:34 AM, Jukka Zitting <[EMAIL PROTECTED]>wrote: > Hi, > > Please vote on accepting or rejecting this policy change! This > majority vote is open for a week and only votes from the Incubator PMC > members are binding. > > [ ] +1 Yes, allow extra release distribution channels like the central > Maven repository > [ ] -1 No, keep the current policy > > My vote is +1 > > BR, > > Jukka Zitting > > +1. While I understand the concern with the need for it to be clear to users (developers using Maven) that they are using an incubator release, and not an endorsed-by-Apache release, I believe the requirement to have "incubating" in the version number handles this requirement. The type of user that cares about the distinction will see the incubating in the jar file name, and/or at least look at the site of the dependencies being used. Conversely, if a user never looks at the dependencies being used because they just let Maven do magic, then they don't even know the code is from Apache, so there can't be any implied endorsement by the ASF. -- Stephen Duncan Jr www.stephenduncanjr.com
Re: [DISCUSS] Alternative proposition [Was: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
Gilles, Sorry. "they don't use the apache name." is a non-starter for me :( -- dims On Thu, Sep 18, 2008 at 4:48 AM, Gilles Scokart <[EMAIL PROTECTED]> wrote: > I think the vote (and discussions) about the use of extra distribution > channel is going in a bad direction. > > I would like to try to summarize the two positions, see if we could > not reconcile the two positions and found a better consensus. > > Here is what the 2 camps say: > +1 : say: >- We can not forbid the incubator artefact to be published in the > maven repository. Once an incubating release is done, anyone is free > to redistribute it. >- It bring benefits for the incubating project (more users, more > visibility) > > -1 say: >- It allow the user to ignore the disclaimer. >- It is useless. There is work around. >- We want to put obstacles to incubating project in order to motivate > them to graduate. >- We should not take decision on it without consensus, so -1 is better. >- The maven repository present some security issues > > I think the main reason of the -1 is to protect the name of Apache. > The incubating project are not allowed to have an excessive > fascination for the apache brand [1]. The incubating project should > not abuse the Apache brand. That's why the incubator distributions > are done only on channel well controlled by the ASF. > > I think both arguments are valuable. And it is maybe possible to > reconciliation them. > > The alternative proposition that I think could reconciliate both camp is: > Why not allow the incubating project to release to any channel they > want, provided that they don't use the apache name. > > > > PS: Please, don't discuss the specific case of the maven repository. > Start an other thread somewhere else if you want to discuss it. > > > -- > Gilles Scokart > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Davanum Srinivas :: http://davanum.wordpress.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DISCUSS] Alternative proposition [Was: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
I think the vote (and discussions) about the use of extra distribution channel is going in a bad direction. I would like to try to summarize the two positions, see if we could not reconcile the two positions and found a better consensus. Here is what the 2 camps say: +1 : say: - We can not forbid the incubator artefact to be published in the maven repository. Once an incubating release is done, anyone is free to redistribute it. - It bring benefits for the incubating project (more users, more visibility) -1 say: - It allow the user to ignore the disclaimer. - It is useless. There is work around. - We want to put obstacles to incubating project in order to motivate them to graduate. - We should not take decision on it without consensus, so -1 is better. - The maven repository present some security issues I think the main reason of the -1 is to protect the name of Apache. The incubating project are not allowed to have an excessive fascination for the apache brand [1]. The incubating project should not abuse the Apache brand. That's why the incubator distributions are done only on channel well controlled by the ASF. I think both arguments are valuable. And it is maybe possible to reconciliation them. The alternative proposition that I think could reconciliate both camp is: Why not allow the incubating project to release to any channel they want, provided that they don't use the apache name. PS: Please, don't discuss the specific case of the maven repository. Start an other thread somewhere else if you want to discuss it. -- Gilles Scokart - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
On Thu, Sep 18, 2008 at 4:57 AM, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > William A. Rowe, Jr. wrote: > > > Noel J. Bergman wrote: > >>> The current tally is extremely close (9 +1 vs. 8 -1 binding) > >>> I don't want to close an issue with such a small margin. > >> I suggest that we should not change policy on anything like this lack of > >> concensus. I do, however, suggest that pressure be put on Maven to > >> enforce signing. > > As no-maven still hasn't been justified, and when we authorized releases > > we had not explicitly called out specific channels, so I'm wondering what > > the "change" you refer to actually is :) > > Right now, the policy has been an Incubator-specific repository, not the > main one. > > And the general statement is that when we have an issue with no clear > consensus, we should take care about making changes on slim margins. > > > I'd not been able to decide how to vote on this but it doesn't feel right to have it decided by a 9 to 8 vote. There clearly isn't consensus and there's still lots of discussion going on about it in this and other threads so for now my vote is -1. ...ant
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
William A. Rowe, Jr. wrote: > Noel J. Bergman wrote: >>> The current tally is extremely close (9 +1 vs. 8 -1 binding) >>> I don't want to close an issue with such a small margin. >> I suggest that we should not change policy on anything like this lack of >> concensus. I do, however, suggest that pressure be put on Maven to >> enforce signing. > As no-maven still hasn't been justified, and when we authorized releases > we had not explicitly called out specific channels, so I'm wondering what > the "change" you refer to actually is :) Right now, the policy has been an Incubator-specific repository, not the main one. And the general statement is that when we have an issue with no clear consensus, we should take care about making changes on slim margins. > the only two incubator specific answers I've seen are "because we want > incentive for projects to graduate" That's not mine. > and "because users will come to rely on incubating project artifacts" > which is an issue with the developer who creates the dependency to an > -incubating' artifact, and disclaimer to the consumer is that > developer's issue. We have a long standing policy that users should have to make a conscious decision to use Incubator artifacts, regardless of build tool. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
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.
<[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Davanum Srinivas :: http://davanum.wordpress.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
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.
<[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Davanum Srinivas :: http://davanum.wordpress.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
On Wed, Sep 17, 2008 at 6:34 PM, Noel J. Bergman <[EMAIL PROTECTED]> wrote: >> The current tally is extremely close (9 +1 vs. 8 -1 binding) >> I don't want to close an issue with such a small margin. > > I suggest that we should not change policy on anything like this lack of > concensus. I do, however, suggest that pressure be put on Maven to enforce > signing. I don't understand why the signing issue keeps coming into this debate - in your own words regarding maven from the July 2008 Incubator board report "...there are real and significant issues/consequences to the ASF, but they are not Incubator specific..." Craig made a couple of points that quite a few agreed with, the first about configuration, but AIUI you configure maven for the current incubating repository either at a project or user level - not at an artifact level. So, for example, I decide that despite its incubating status I want to use Tika and configure the repo - but after that I get any other incubating artifacts (e.g. PDFBox, which once it has a release will probably be a Tika dependency) without having to stop and do something explicit. So this argument is flawed - at least to a certain extent. It would be more consistent IMO if those voting -1 were arguing to not put any artifacts in any maven repo. The other point that Craig made was the risk of abandonement. Perhaps this is true (not sure how many failed podlings we've had) - but its a generalization that isn't always the case. For example wicket entered with vibrant community and on the other side of the coin there are fully fledged ASF projects, still releasing today, that are far more of a risk in that department. The reality then is that users really need to look at this on a case-by-case basis for any project - incubating or fully-fledged - if abandonement is something that would be of concern to them. Niall >--- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Majority voting (Was: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository)
Hi, On Wed, Sep 17, 2008 at 7:34 PM, Noel J. Bergman <[EMAIL PROTECTED]> wrote: >> The current tally is extremely close (9 +1 vs. 8 -1 binding) >> I don't want to close an issue with such a small margin. > > I suggest that we should not change policy on anything like this lack of > concensus. IMHO this issue needs to be resolved one way or another as even the current policy is undocumented and confusing. A negative result on this vote will also serve to clarify the position of the IPMC. The IPMC already has 85 members and I'm afraid this is probably just the first example of an issue where we will not be able to form consensus through discussion. Consensus doesn't scale, and we need to find ways to deal with that. Adopting and accepting majority rule is IMHO one key element in dealing with growth. Yes, it'll change community dynamics, but I can't see a way around that without decreasing the size of the the community. A big issue with majority votes (and the key reason why I wanted to extend the vote period) is legitimacy of the decisions when a large part of binding votes are not cast. To increase confidence that the result of this vote reflects the wishes of the IPMC as a whole, I'd appreciate more IPMC members to cast their votes. Even an explicit 0 vote is better than silence. I appreciate that majority decisions without clear community consensus are a new aspect at Apache, and it would be best to discuss the ramifications and related rules when there is no active vote ongoing. I'll be following up on this at members@ once the dust settles, and until that I'm ready to table this issue if more votes won't made the result clearer. BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
On Wed, Sep 17, 2008 at 11:36 AM, Brian E. Fox <[EMAIL PROTECTED]>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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
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 <[EMAIL PROTECTED]>: > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Gilles Scokart - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
On Wed, Sep 17, 2008 at 1:19 PM, Noel J. Bergman <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Davanum Srinivas :: http://davanum.wordpress.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
>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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://open.iona.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
Noel J. Bergman wrote: The current tally is extremely close (9 +1 vs. 8 -1 binding) I don't want to close an issue with such a small margin. I suggest that we should not change policy on anything like this lack of concensus. I do, however, suggest that pressure be put on Maven to enforce signing. As no-maven still hasn't been justified, and when we authorized releases we had not explicitly called out specific channels, so I'm wondering what the "change" you refer to actually is :) We seem to believe that Maven releases were "prohibited" but I don't ever recall a vote on that. I do recall a policy change when we said "no more people.a.o release artifacts!" and shifted it all to www.a.o/dist/incubator But I suggest we don't close the vote until 10 days have passed, people do have strong opinions, but not all of the opinions have been registered. When it's this close, we need to be sensitive to the fact that some folks are traveling or absorbed in work, on vacation, etc. I think Daniel Kulp did a much better job that I did asking "what is the basis or justification for this policy?" And the only two incubator specific answers I've seen are "because we want incentive for projects to graduate" which is non sequitur if releases are allowed at all, and "because users will come to rely on incubating project artifacts" which is an issue with the developer who creates the dependency to an -incubating' artifact, and disclaimer to the consumer is that developer's issue. Of course, the disclaimer does land in the META-INF/ tree along with any licensing, correct? Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository
> The current tally is extremely close (9 +1 vs. 8 -1 binding) > I don't want to close an issue with such a small margin. I suggest that we should not change policy on anything like this lack of concensus. I do, however, suggest that pressure be put on Maven to enforce signing. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Incubator Maven repo [WAS Re: [VOTE] [POLICY] Allow extra release distribution channels like the central Maven repository]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
