> understand them correctly. I encourage you to address concerns raised on > this thread about the complexion of the initial PMC and mentorships. There > have been a few suggestions worth exploring. >
+1 to Andrew's comment. Let us be real for a moment, when all PPMCs including mentors and committers are from same organizations, especially with project related to security, what or who could provide sanity check when a "competitor" contributor trying to contribute patch or someday be active committer if all decision makers (PPMCs) are paid developers from one commercial company? In a happy perfect world, all individuals will put aside their corporate hats when working with open source code, especially with neutral org like ASF or Eclipse, but that is actually true. Most of them would try to defend their employers "rights" to direct the project to the vision that they want it to be. The idea of having different orgs representing as initial team is exactly to prevent this situation. When I tried to champion the Apache MetaModel as incubator project I did my homework to "solicit" mentors from different orgs to make sure it is well represented. I saw similar things with Apache Spark, and Brooklyn projects. - Henry >> Similar discussion can be made between no-sql projects like Apache HBase, > Apache Accumulo and Apache Cassandra. > > Not similar at all. This isn't about choice, this is about trust. Security > and trust are wedded inseparably. > > > > On Thu, Jul 17, 2014 at 1:03 PM, Don Bosco Durai <bdu...@hortonworks.com> > wrote: > >> Andrews, thanks for your feedback. My responses are inline. >> >> Regards >> >> Bosco >> >> On Jul 17, 2014, at 11:41 AM, Andrew Purtell <apurt...@apache.org> wrote: >> >> > Thank you for writing back with a detailed clarification. >> > >> > Regarding encryption at rest, HDFS is adding it as HDFS-6134, so likely >> > there will be a new core feature option for the ecosystem to consider >> > shortly. >> > >> > > I don’t feel one technology or one company or one small group or one >> > approach can solve this problem. This has to be addressed by the >> community >> > working together. This would also require a lot of support from each >> > dependent projects and lot of co-ordination. And there would be multiple >> > security solutions available for the end users to pick from. >> > >> > Completely agreed. However, the desired community cooperation has both >> > technical and political components. I think there are some concerns about >> > how successful an outcome Argus may produce, informed by experience. >> > Perhaps it would be worthwhile to address those concerns. Argus proposes >> to >> >> The current Argus solution already has integration with the core Hadoop >> components like HDFS, Hive and HBase. There are work in progress to support >> additional Hadoop components, which includes Knox. Anytime, we cross >> project boundaries, there were would be always challenges wrt technical and >> political. Working this out within the community makes more sense, rather >> than doing this outside. Not attempting would be counterproductive. >> >> > develop a common security infrastructure for the Hadoop ecosystem. In my >> > opinion (and informed by personal experience) we have new incubating >> Hadoop >> > ecosystem security projects like Sentry and Knox and proposals such as >> > Argus because Hadoop core is locked down. Argus et. al. are like the >> > proverbial blocked river (user demand for features) seeking a new route >> > around a landslide (obvious poisonous contention and litigation-via-JIRA >> on >> > every significant topic). I would be curious your thoughts on how to >> avoid >> > the same end state in the Argus project. In my opinion, it would be a >> > tragedy if a potential solution ends up perpetuating the dysfunction it >> > seeks to bypass to a greater proportion of Foundation projects instead. A >> > Hadoop ecosystem project attempting to remain independent from the >> > dysfunction of Hadoop core would be well advised to stay away from >> adoption >> > of Argus components (security is so critical) if the governance of Argus >> I don’t believe Argus existence is because HDFS or any other component is >> locked down or dysfunctional. Each component will continue to evolve (core >> features and security) overtime based on their priority, severity and >> timeline. The option to externalize security is always a good thing. Option >> to externalize is a well accepted notion in the community. Commercial >> databases allow externalizing security, web applications externalize >> authentication and authorization, there are vulnerability management >> systems for file system/software version, etc. I don’t see a security >> provider like Argus or Sentry extending the native security as a risk or >> bad thing, instead, a good motivation for projects (particularly new) to >> focus on their core features. >> >> I also don’t feel this is a short term user demand. Security requirement >> changes on regular basis and as different type of industries adopt hadoop, >> their security requirements might be also different. They will look for >> different options for security and select what addresses their needs. >> >> > perpetuates that dysfunction. By the way, it is also not too late for >> Knox >> > and Sentry. >> > >> Security is most effective when it is deployed as layered solution. Knox >> addresses the perimeter security. Currently it is REST and they will extend >> it to support security for more external API technologies. Argus will not >> replace it, but complement Knox by centralizing the administration and >> common auditing. Sentry and Argus have some overlap, but at the core, they >> have different philosophies and approach. Similar discussion can be made >> between no-sql projects like Apache HBase, Apache Accumulo and Apache >> Cassandra. Varying options is always healthy. >> >> >> >> >> >> -- >> CONFIDENTIALITY NOTICE >> NOTICE: This message is intended for the use of the individual or entity to >> which it is addressed and may contain information that is confidential, >> privileged and exempt from disclosure under applicable law. If the reader >> of this message is not the intended recipient, you are hereby notified that >> any printing, copying, dissemination, distribution, disclosure or >> forwarding of this communication is strictly prohibited. If you have >> received this communication in error, please contact the sender immediately >> and delete it from your system. Thank You. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> > > > -- > Best regards, > > - Andy > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > (via Tom White) --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
