Re: [DISCUSS] Hadoop 3.4.2 release

+1 Thanks, Ahmar! On Fri, Feb 28, 2025 at 7:37 AM slfan1989 wrote: > +1 > > I can provide assistance with the ARM release, as I originally planned to > release Hadoop 3.5.0, which supports JDK17, and have been conducting > related tests. > > My approach is a workaround, and I hope it helps. > >

Re: way forward for Winutils excision from `FileSystem`

As Chris mentioned earlier, it would be wise to do this in pieces that can be reviewed properly. Bringing large refactorings in all at once, as Garret mentioned, is not likely to just get a +1. We do have a feature branch process and criteria and we could determine specific criteria for such a cri

Re: improving efficiency and reducing runtime using S3 read optimization

Hi Kumar - This looks very promising and you should absolutely pursue contributing it back! Whether you initially merge into S3A or bring S3E in separately could be determined through PR review or even on a DISCUSS thread here. Congrats on what seem to be very positive results! thanks, --larry

[jira] [Resolved] (HADOOP-16736) Best Big data hadoop training in pune

[ https://issues.apache.org/jira/browse/HADOOP-16736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Larry McCay resolved HADOOP-16736. -- Resolution: Invalid This is spam - resolving as Invalid. > Best Big data hadoop training

Re: CredentialProvider API

This is likely an issue only for issues where we need the password from HDFS in order to access HDFS. This should definitely be avoided by not having a static credential provider path configured for startup that includes such a dependency. For instance, the JIRA you cite is an example where we nee

[jira] [Created] (HADOOP-16076) SPNEGO+SSL Client Connections with HttpClient Broken

Larry McCay created HADOOP-16076: Summary: SPNEGO+SSL Client Connections with HttpClient Broken Key: HADOOP-16076 URL: https://issues.apache.org/jira/browse/HADOOP-16076 Project: Hadoop Common

Re: HADOOP-14163 proposal for new hadoop.apache.org

+1 from me On Fri, Aug 31, 2018, 5:30 AM Steve Loughran wrote: > > > > On 31 Aug 2018, at 09:07, Elek, Marton wrote: > > > > Bumping this thread at last time. > > > > I have the following proposal: > > > > 1. I will request a new git repository hadoop-site.git and import the > new site to there

Re: [DISCUSS]: securing ASF Hadoop releases out of the box

+1 from me as well. On Thu, Jul 5, 2018 at 5:19 PM, Steve Loughran wrote: > > > > On 5 Jul 2018, at 23:15, Anu Engineer wrote: > > > > +1, on the Non-Routable Idea. We like it so much that we added it to the > Ozone roadmap. > > https://issues.apache.org/jira/browse/HDDS-231 > > > > If there is

Re: [DISCUSS]: securing ASF Hadoop releases out of the box

Hi Steve - This is a long overdue DISCUSS thread! Perhaps the UIs can very visibly state (in red) "WARNING: UNSECURED UI ACCESS - OPEN TO COMPROMISE" - maybe even force a click through the warning to get to the page like SSL exceptions in the browser do? Similar tactic for UI access without SSL?

Re: [DISCUSS] Branch Proposal: HADOOP 15407: ABFS

This seems like a reasonable and effective use of a feature branch and branch committers to me. On Tue, May 15, 2018 at 11:34 AM, Steve Loughran wrote: > Hi > > Chris Douglas I and I've have a proposal for a short-lived feature branch > for the Azure ABFS connector to go into the hadoop-azure p

Re: When are incompatible changes acceptable (HDFS-12990)

ue to > reduce the pain point from either side of oppositions. > > > > Regards, > > Eric > > > > *From: *Chris Douglas > *Date: *Wednesday, January 10, 2018 at 7:36 PM > *To: *Eric Yang > *Cc: *"Aaron T. Myers" , Daryn Sharp , > Hadoo

Re: When are incompatible changes acceptable (HDFS-12990)

ce - >> we've made incompatible changes in the past when appropriate, e.g. >> breaking >> some clients to address a security issue. I and others believe that in >> this >> case the benefits greatly outweigh the downsides of changing this back to >> what it

Re: When are incompatible changes acceptable (HDFS-12990)

On Mon, Jan 8, 2018 at 11:28 PM, Aaron T. Myers wrote: > Thanks a lot for the response, Larry. Comments inline. > > On Mon, Jan 8, 2018 at 6:44 PM, larry mccay wrote: > >> Question... >> >> Can this be addressed in some way during or before upgrade that allows it

Re: When are incompatible changes acceptable (HDFS-12990)

Question... Can this be addressed in some way during or before upgrade that allows it to only affect new installs? Even a config based workaround prior to upgrade might make this a change less disruptive. If part of the upgrade process includes a step (maybe even a script) to set the NN RPC port

[jira] [Resolved] (HADOOP-15075) Implement KnoxSSO for hadoop web UIs (hdfs, yarn, history server etc.)

[ https://issues.apache.org/jira/browse/HADOOP-15075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Larry McCay resolved HADOOP-15075. -- Resolution: Not A Problem Closing as not a problem - since JWTRedirectAuthenticationHandler

Re: [DISCUSS] Feature Branch Merge and Security Audits

x27;t want that sort of notoriety for hadoop. Granted, it's not always possible to turn on all security features: for example you have to have a KDC set up in order to enable Kerberos. 8.1 Are there settings or configurations that can be shipped in a default-secure state? On Tue, Oct 31, 20

Re: [DISCUSS] Feature Branch Merge and Security Audits

e authority used to sign the certificate is in > the default certificate store, turn on HSTS automatically. > - Always turn off TLSv1 and TLSv1.1 > - Forbid single-DES and RC4 encryption algorithms > > You get the idea. > -Mike > > > >> >> >> On Wed, O

Re: [DISCUSS] Feature Branch Merge and Security Audits

have considered any settings of configurations that can be secure by default is an interesting idea. Can you provide an example though? On Wed, Oct 25, 2017 at 2:14 PM, Michael Yoder wrote: > On Sat, Oct 21, 2017 at 8:47 AM, larry mccay wrote: > >> New Revision... >> > > T

Re: [DISCUSS] Feature Branch Merge and Security Audits

ot released yet. 6.1. All dependencies checked for CVEs? On Sat, Oct 21, 2017 at 10:26 AM, larry mccay wrote: > Hi Marton - > > I don't think there is any denying that it would be great to have such > documentation for all of those reasons. > If it is a natural extension of g

Re: [DISCUSS] Feature Branch Merge and Security Audits

lling all such information across the project is a different topic altogether and wouldn't want to expand the scope of this discussion in that direction. Thanks for the great thoughts on this! thanks, --larry On Sat, Oct 21, 2017 at 3:00 AM, Elek, Marton wrote: > > > On 10/21/2

Re: [DISCUSS] Feature Branch Merge and Security Audits

; How do we want to enforce security completeness? Most features will not > meet all security requirements on merge day. > > Regards, > Eric > > On 10/20/17, 12:41 PM, "larry mccay" wrote: > > Adding security@hadoop list as well... > > On Fri, Oct 2

Re: 答复: [DISCUSSION] Merging HDFS-7240 Object Store (Ozone) to trunk

before bringing it into any particular merge discussion. thanks, --larry On Fri, Oct 20, 2017 at 12:37 PM, larry mccay wrote: > I previously sent this same email from my work email and it doesn't seem > to have gone through - resending from apache account (apologizing up from >

Re: [DISCUSS] Feature Branch Merge and Security Audits

Adding security@hadoop list as well... On Fri, Oct 20, 2017 at 2:29 PM, larry mccay wrote: > All - > > Given the maturity of Hadoop at this point, I would like to propose that > we start doing explicit security audits of features at merge time. > > There are a few reasons that

[DISCUSS] Feature Branch Merge and Security Audits

All - Given the maturity of Hadoop at this point, I would like to propose that we start doing explicit security audits of features at merge time. There are a few reasons that I think this is a good place/time to do the review: 1. It represents a specific snapshot of where the feature stands as a

Re: 答复: [DISCUSSION] Merging HDFS-7240 Object Store (Ozone) to trunk

I previously sent this same email from my work email and it doesn't seem to have gone through - resending from apache account (apologizing up from for the length) For such sizable merges in Hadoop, I would like to start doing security audits in order to have an initial idea of the attack surfa

Re: [DISCUSS] Merging API-based scheduler configuration to trunk/branch-2

Hi Jonathan - Thank you for bringing this up for discussion! I would personally like to see a specific security review of features like this - especially ones that allow for remote access to configuration. I'll take a look at the JIRA and see whether I can come up with any concerns or questions a

Re: Moving Java Forward Faster

Interesting. Thanks for sharing this, Allen. Question: Does GPL licensing of the JDK/JVM affect us negatively? On Thu, Sep 7, 2017 at 10:14 AM, Allen Wittenauer wrote: > > > > Begin forwarded message: > > > > From: "Rory O'Donnell" > > Subject: Moving Java Forward Faster > > Date: September 7

Re: [DISCUSS] Looking to Apache Hadoop 3.1 release

Hi Wangda - Thank you for starting this conversation! +1000 for a faster release cadence. Quicker releases make turning around security fixes so much easier. When we consider alpha features, let’s please ensure that they are not delivered in a state that has known security issues and also make s

Re: Apache Hadoop 2.8.2 Release Plan

If we do "fix" this in 2.8.2 we should seriously consider not doing so in 3.0. This is a very poor practice. I can see an argument for backward compatibility in 2.8.x line though. On Fri, Sep 1, 2017 at 1:41 PM, Steve Loughran wrote: > One thing we need to consider is > > HADOOP-14439: regressi

Re: [VOTE] Release Apache Hadoop 2.8.0 (RC3)

+1 (non-binding) - verified signatures - built from source and ran tests - deployed pseudo cluster - ran basic tests for hdfs, wordcount, credential provider API and related commands - tested webhdfs with knox On Wed, Mar 22, 2017 at 7:21 AM, Ravi Prakash wrote: > Thanks for all the effort Jun

Re: [VOTE] Release Apache Hadoop 2.6.5 (RC1)

+1 (non-binding) * Downloaded and verified signatures * Built from source * Deployed a standalone cluster * Tested HDFS commands and job submit * Tested webhdfs through Apache Knox On Fri, Oct 7, 2016 at 10:35 PM, Karthik Kambatla wrote: > Thanks for putting the RC together, Sangjin. > > +

[jira] [Created] (HADOOP-13556) Change Configuration.getPropsWithPrefix to use getProps instead of iterator

Larry McCay created HADOOP-13556: Summary: Change Configuration.getPropsWithPrefix to use getProps instead of iterator Key: HADOOP-13556 URL: https://issues.apache.org/jira/browse/HADOOP-13556

Re: [VOTE] Release Apache Hadoop 2.7.3 RC1

I believe it was described as some previous audit entries have been superseded by new ones and that the order may no longer be the same for other entries. For what it’s worth, I agree with the assertion that this is a backward incompatible output - especially for audit logs. On Thu, Aug 18, 2016

Re: [VOTE] Release Apache Hadoop 2.7.3 RC0

Oops - make that: +1 (non-binding) On Sun, Jul 24, 2016 at 4:07 PM, larry mccay wrote: > +1 binding > > * downloaded and built from source > * checked LICENSE and NOTICE files > * verified signatures > * ran standalone tests > * installed pseudo-distributed instance on m

Re: [VOTE] Release Apache Hadoop 2.7.3 RC0

+1 binding * downloaded and built from source * checked LICENSE and NOTICE files * verified signatures * ran standalone tests * installed pseudo-distributed instance on my mac * ran through HDFS and mapreduce tests * tested credential command * tested webhdfs access through Apache Knox On Fri, J

Re: Why there are so many revert operations on trunk?

-1 needs not be a taken as a derogatory statement being a number should actually make it less emotional. It is dangerous to a community to become oversensitive to it. I generally see language such as "I am -1 on this until this particular thing is fixed" or that it violates some common pattern or

Re: Why there are so many revert operations on trunk?

inline On Mon, Jun 6, 2016 at 4:36 PM, Vinod Kumar Vavilapalli wrote: > Folks, > > It is truly disappointing how we are escalating situations that can be > resolved through basic communication. > > Things that shouldn’t have happened > - After a few objections were raised, commits should ha

Re: Why there are so many revert operations on trunk?

This seems like something that is going to probably happen again if we continue to cut releases from trunk. I know that this has been discussed at length in a separate thread but I think it would be good to recognize that it is the core of the issue here. Either we: * need to define what will hap

Re: 2.7.3 release plan

are usually taken on a time basis: if they get in by the > proposed timelines, we get them in. Otherwise, we move them over. > > Thanks > +Vinod > > > On May 16, 2016, at 5:20 PM, larry mccay wrote: > > > > Curious on the status of 2.7.3 > > > > It

Re: 2.7.3 release plan

Curious on the status of 2.7.3 It seems that we still have two outstanding critical/blocker JIRAs: 1. [image: Bug] HADOOP-12893 Verify LICENSE.txt and NOTICE.txt 2. [image: Sub-task] HADOOP-13154

Re: Different JIRA permissions for HADOOP and HDFS

Likewise, I've found that I am unable to set fix version, etc on a JIRA that I committed and resolved. On Mon, May 16, 2016 at 8:29 AM, Junping Du wrote: > Zhihai, I just set you with committer permissions on MAPREDUCE JIRA. Would > you try if the JIRA assignment works now? I cannot help on Hive

[jira] [Resolved] (HADOOP-12942) hadoop credential commands non-obviously use password of "none"

[ https://issues.apache.org/jira/browse/HADOOP-12942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Larry McCay resolved HADOOP-12942. -- Resolution: Fixed > hadoop credential commands non-obviously use password of &q

[jira] [Reopened] (HADOOP-12942) hadoop credential commands non-obviously use password of "none"

[ https://issues.apache.org/jira/browse/HADOOP-12942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Larry McCay reopened HADOOP-12942: -- > hadoop credential commands non-obviously use password of &q

Re: Guidance needed on HADOOP-13096 and HADOOP-13097

or YARN, one for MR) in their own right. But I do > think C is the correct, long-term path. We should probably move hdfs and > common scripts into separate dirs as well, honestly. > > Thanks for the feedback! > > > > On May 5, 2016, at 7:22 PM, Larry McCay wrote: &

Re: Guidance needed on HADOOP-13096 and HADOOP-13097

I would vote for C or D with a filed JIRA to clean up the maven structure as a separate effort. Before moving to D, could you describe any reason to not go with C? On May 4, 2016, at 9:51 PM, Allen Wittenauer wrote: > > When the sub-projects re-merged, maven work was done, whatever, the

Re: Commit History Edit Alert

anch-Xs. Larry, could you > update INFRA-11236 with your empirical testing? Would be good to get these > branches protected again for the future. > > Thanks, > Andrew > > > On Thu, Apr 21, 2016 at 9:42 PM, larry mccay wrote: > > > I believe that he squashed my attempt

Re: Commit History Edit Alert

ith > periods, e.g.: > > HADOOP-13011. Clearly Document the Password Details for Keystore-based > Credential Providers. > > > On Thu, Apr 21, 2016 at 8:26 PM, larry mccay wrote: > > > All - > > > > My first hadoop commit for HADOOP-13011 inadvertently ref

Commit History Edit Alert

All - My first hadoop commit for HADOOP-13011 inadvertently referenced the wrong JIRA (HADOOP-13001) in the commit message. Owen O'Malley helped me out by fixing the history on all 3 branches: trunk, branch-2, branch-2.8. The message is correct now in the current history but you may need to rebas

[jira] [Created] (HADOOP-13011) Clearly Document the Password Details for Keystore-based Credential Providers

Larry McCay created HADOOP-13011: Summary: Clearly Document the Password Details for Keystore-based Credential Providers Key: HADOOP-13011 URL: https://issues.apache.org/jira/browse/HADOOP-13011

[jira] [Created] (HADOOP-13008) Add XFS Filter for UIs to Hadoop Common

Larry McCay created HADOOP-13008: Summary: Add XFS Filter for UIs to Hadoop Common Key: HADOOP-13008 URL: https://issues.apache.org/jira/browse/HADOOP-13008 Project: Hadoop Common Issue Type

Re: Branch policy question

ranch patch, he could in > >theory convert the entire branch into a single .patch for review. Not > >that I'd encourage that, just observing that its possible > > > > > >> > >> On Tue, Mar 22, 2016 at 10:56 AM, Allen Wittenauer < > >> allen

Re: Branch policy question

Just to clarify, we are talking about a feature branch in which Allen and others that are working on the branch could commit without requiring 3 +1’s. Then, at some point, we will need 3 +1’s to merge the branch to trunk. Correct? I think that if we have a set of usecases that are being added and

Re: Branch policy question

That sounds like a reasonable approach and valid use of branches to me. Perhaps a set of functional tests could be provided/identified that would help the review process by showing backward compatibility along with new extensions for things like dynamic commands? On Tue, Mar 22, 2016 at 12:14 PM

[jira] [Created] (HADOOP-12929) JWTRedirectAuthenticationHandler must accommodate null expiration time

Larry McCay created HADOOP-12929: Summary: JWTRedirectAuthenticationHandler must accommodate null expiration time Key: HADOOP-12929 URL: https://issues.apache.org/jira/browse/HADOOP-12929 Project

[jira] [Created] (HADOOP-12851) S3AFileSystem Uptake of ProviderUtils.excludeIncompatibleCredentialProviders

Larry McCay created HADOOP-12851: Summary: S3AFileSystem Uptake of ProviderUtils.excludeIncompatibleCredentialProviders Key: HADOOP-12851 URL: https://issues.apache.org/jira/browse/HADOOP-12851

[jira] [Created] (HADOOP-12846) Credential Provider Recursive Dependencies

Larry McCay created HADOOP-12846: Summary: Credential Provider Recursive Dependencies Key: HADOOP-12846 URL: https://issues.apache.org/jira/browse/HADOOP-12846 Project: Hadoop Common Issue

Re: Introduce Apache Kerby to Hadoop

Replacing MiniKDC with kerby certainly makes sense. Kerby-izing Hadoop 3 needs to be defined carefully. As much as a JWT proponent that I am, I don't know that that taking up non-standard features such as the JWT token would necessarily serve us well. If we are talking about client side only uptak

[jira] [Created] (HADOOP-12804) Read Proxy Password from Credential Providers in S3 FileSystem

Larry McCay created HADOOP-12804: Summary: Read Proxy Password from Credential Providers in S3 FileSystem Key: HADOOP-12804 URL: https://issues.apache.org/jira/browse/HADOOP-12804 Project: Hadoop

[jira] [Created] (HADOOP-12758) Extend CSRF Filter with UserAgent Checks

Larry McCay created HADOOP-12758: Summary: Extend CSRF Filter with UserAgent Checks Key: HADOOP-12758 URL: https://issues.apache.org/jira/browse/HADOOP-12758 Project: Hadoop Common Issue

[jira] [Created] (HADOOP-12691) Add CSRF Filter to Hadoop Common

Larry McCay created HADOOP-12691: Summary: Add CSRF Filter to Hadoop Common Key: HADOOP-12691 URL: https://issues.apache.org/jira/browse/HADOOP-12691 Project: Hadoop Common Issue Type: Bug

[jira] [Created] (HADOOP-12481) JWTRedirectAuthenticationHandler doesn't Retain Original Query String

Larry McCay created HADOOP-12481: Summary: JWTRedirectAuthenticationHandler doesn't Retain Original Query String Key: HADOOP-12481 URL: https://issues.apache.org/jira/browse/HADOOP-12481 Pr

Re: hadoop-hdfs-client splitoff is going to break code

Interesting... As long as #2 provides full backward compatibility and the ability to explicitly exclude the server dependencies that seems the best way to go. That would get my non-binding +1. :) Perhaps we could add another artifact called hadoop-thin-client that would not be backward compatible

[jira] [Created] (HADOOP-12076) Incomplete Cache Mechanism in CredentialProvider API

Larry McCay created HADOOP-12076: Summary: Incomplete Cache Mechanism in CredentialProvider API Key: HADOOP-12076 URL: https://issues.apache.org/jira/browse/HADOOP-12076 Project: Hadoop Common

Re: 2.7.1 status

Hi Vinod - I think that https://issues.apache.org/jira/browse/HADOOP-11934 should also be added to the blocker list. This is a critical bug in our ability to protect the LDAP connection password in LdapGroupsMapper. thanks! --larry On Tue, May 26, 2015 at 3:32 PM, Vinod Kumar Vavilapalli < vino

[jira] [Created] (HADOOP-11717) Add Redirecting WebSSO behavior with JWT Token in Hadoop Auth

Larry McCay created HADOOP-11717: Summary: Add Redirecting WebSSO behavior with JWT Token in Hadoop Auth Key: HADOOP-11717 URL: https://issues.apache.org/jira/browse/HADOOP-11717 Project: Hadoop

[jira] [Created] (HADOOP-11265) Credential and Key Shell Commands not available on Windows

Larry McCay created HADOOP-11265: Summary: Credential and Key Shell Commands not available on Windows Key: HADOOP-11265 URL: https://issues.apache.org/jira/browse/HADOOP-11265 Project: Hadoop Common

[jira] [Resolved] (HADOOP-10904) Provide Alt to Clear Text Passwords through Cred Provider API

[ https://issues.apache.org/jira/browse/HADOOP-10904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Larry McCay resolved HADOOP-10904. -- Resolution: Fixed > Provide Alt to Clear Text Passwords through Cred Provider

[jira] [Resolved] (HADOOP-11200) HttpFS proxyuser, doAs param is case sensitive

[ https://issues.apache.org/jira/browse/HADOOP-11200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Larry McCay resolved HADOOP-11200. -- Resolution: Duplicate Didn't realize that HADOOP-11083 addressed this for HttpFS. Closi

[jira] [Created] (HADOOP-11200) HttpFS proxyuser, doAs param is case sensitive

Larry McCay created HADOOP-11200: Summary: HttpFS proxyuser, doAs param is case sensitive Key: HADOOP-11200 URL: https://issues.apache.org/jira/browse/HADOOP-11200 Project: Hadoop Common

[jira] [Created] (HADOOP-11031) Design Document for Credential Provider API

Larry McCay created HADOOP-11031: Summary: Design Document for Credential Provider API Key: HADOOP-11031 URL: https://issues.apache.org/jira/browse/HADOOP-11031 Project: Hadoop Common Issue

[jira] [Created] (HADOOP-10933) FileBasedKeyStoresFactory Should use Configuration.getPassword for SSL Passwords

Larry McCay created HADOOP-10933: Summary: FileBasedKeyStoresFactory Should use Configuration.getPassword for SSL Passwords Key: HADOOP-10933 URL: https://issues.apache.org/jira/browse/HADOOP-10933

[jira] [Created] (HADOOP-10929) Typo in Configuration.getPasswordFromCredentialProviders

Larry McCay created HADOOP-10929: Summary: Typo in Configuration.getPasswordFromCredentialProviders Key: HADOOP-10929 URL: https://issues.apache.org/jira/browse/HADOOP-10929 Project: Hadoop Common

[jira] [Created] (HADOOP-10905) LdapGroupsMapping Should use configuration.getPassword for SSL and LDAP Passwords

Larry McCay created HADOOP-10905: Summary: LdapGroupsMapping Should use configuration.getPassword for SSL and LDAP Passwords Key: HADOOP-10905 URL: https://issues.apache.org/jira/browse/HADOOP-10905

[jira] [Created] (HADOOP-10904) Provider Alt to Clear Text Passwords through Cred Provider API

Larry McCay created HADOOP-10904: Summary: Provider Alt to Clear Text Passwords through Cred Provider API Key: HADOOP-10904 URL: https://issues.apache.org/jira/browse/HADOOP-10904 Project: Hadoop

[jira] [Resolved] (HADOOP-9534) Credential Management Framework (CMF)

[ https://issues.apache.org/jira/browse/HADOOP-9534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Larry McCay resolved HADOOP-9534. - Resolution: Duplicate This jira has been superseded by HADOOP-10141 and HADOOP-10607. All

[jira] [Created] (HADOOP-10607) Create an API to separate Credentials/Password Storage from Applications

Larry McCay created HADOOP-10607: Summary: Create an API to separate Credentials/Password Storage from Applications Key: HADOOP-10607 URL: https://issues.apache.org/jira/browse/HADOOP-10607 Project

[jira] [Created] (HADOOP-10491) Add Collection of Labels to KeyProvider API

Larry McCay created HADOOP-10491: Summary: Add Collection of Labels to KeyProvider API Key: HADOOP-10491 URL: https://issues.apache.org/jira/browse/HADOOP-10491 Project: Hadoop Common Issue

[jira] [Created] (HADOOP-10357) Memory Leak in UserGroupInformation.doAs for JDBC Connection to Hive

Larry McCay created HADOOP-10357: Summary: Memory Leak in UserGroupInformation.doAs for JDBC Connection to Hive Key: HADOOP-10357 URL: https://issues.apache.org/jira/browse/HADOOP-10357 Project

[jira] [Created] (HADOOP-10342) Extend UserGroupInformation to return a UGI given a preauthenticated kerberos Subject

Larry McCay created HADOOP-10342: Summary: Extend UserGroupInformation to return a UGI given a preauthenticated kerberos Subject Key: HADOOP-10342 URL: https://issues.apache.org/jira/browse/HADOOP-10342

[jira] [Created] (HADOOP-10244) TestKeyShell improperly tests the results of a Delete

Larry McCay created HADOOP-10244: Summary: TestKeyShell improperly tests the results of a Delete Key: HADOOP-10244 URL: https://issues.apache.org/jira/browse/HADOOP-10244 Project: Hadoop Common

[jira] [Created] (HADOOP-10238) Decouple the Creation of Key metadata from the creation of a key version

Larry McCay created HADOOP-10238: Summary: Decouple the Creation of Key metadata from the creation of a key version Key: HADOOP-10238 URL: https://issues.apache.org/jira/browse/HADOOP-10238 Project

[jira] [Created] (HADOOP-10237) JavaKeyStoreProvider needs to set keystore permissions properly

Larry McCay created HADOOP-10237: Summary: JavaKeyStoreProvider needs to set keystore permissions properly Key: HADOOP-10237 URL: https://issues.apache.org/jira/browse/HADOOP-10237 Project: Hadoop

[jira] [Created] (HADOOP-10224) JavaKeyStoreProvider has to protect against corrupting underlying store

Larry McCay created HADOOP-10224: Summary: JavaKeyStoreProvider has to protect against corrupting underlying store Key: HADOOP-10224 URL: https://issues.apache.org/jira/browse/HADOOP-10224 Project

[jira] [Created] (HADOOP-10201) Add Listing Support to Key Management APIs

Larry McCay created HADOOP-10201: Summary: Add Listing Support to Key Management APIs Key: HADOOP-10201 URL: https://issues.apache.org/jira/browse/HADOOP-10201 Project: Hadoop Common Issue

Re: [VOTE] Release Apache Hadoop 2.2.0

Congrats, guys - well done! On Wed, Oct 16, 2013 at 4:34 PM, Akira AJISAKA wrote: > Congrats! > > The current document > (http://hadoop.apache.org/**docs/current/) > is now hadoop-2.1.0-beta. I want someone to update. > > thanks, > Akira > > > (2013/10/15

[DISCUSS] Security Efforts and Branching

Hello Kai, Jerry and common-dev'ers - I would like to try and get a game plan together for how we go about getting some of these larger security changes into branches that are manageable, reviewable and ultimately mergeable in a timely manner. In order to even start this discussion, I think we ne

Re: [DISCUSS] Hadoop SSO/Token Server Components

13 6:45 AM > To: common-dev@hadoop.apache.org > Subject: Re: [DISCUSS] Hadoop SSO/Token Server Components > > On Tue, Sep 3, 2013 at 5:20 AM, Larry McCay > wrote: > > One outstanding question for me - how do we go about getting the > > branches created? > > Once

Re: [DISCUSS] Hadoop SSO/Token Server Components

Very good. Thank you, Chris! On Tue, Sep 3, 2013 at 6:44 PM, Chris Douglas wrote: > On Tue, Sep 3, 2013 at 5:20 AM, Larry McCay > wrote: > > One outstanding question for me - how do we go about getting the branches > > created? > > Once a group has converged on a pu

Re: [DISCUSS] Hadoop SSO/Token Server Components

C mailing list, and I > assume it would be the same for a branch committer vote. > > http://hadoop.apache.org/bylaws.html > > Chris Nauroth > Hortonworks > http://hortonworks.com/ > > > > On Tue, Aug 6, 2013 at 2:48 PM, Larry McCay > wrote: > > > That

Re: [DISCUSS] Hadoop SSO/Token Server Components

e: >> >>> Larry, >>> >>> Sorry for the delay answering. Thanks for laying down things, yes, it >> makes >>> sense. >>> >>> Given the large scope of the changes, number of JIRAs and number of >>> developers involved, wouldn&#x

Re: [DISCUSS] Hadoop SSO/Token Server Components

:59 PM, Larry McCay wrote: > Hello All - > > In an effort to scope an initial iteration that provides value to the > community while focusing on the pluggable authentication aspects, I've > written a description for "Iteration 1". It identifies the goal of the >

[jira] [Created] (HADOOP-9781) JWT SSO Token and Authority

Larry McCay created HADOOP-9781: --- Summary: JWT SSO Token and Authority Key: HADOOP-9781 URL: https://issues.apache.org/jira/browse/HADOOP-9781 Project: Hadoop Common Issue Type: Sub-task

Re: [DISCUSS] Hadoop SSO/Token Server Components

n moving forward > with pluggable authentication mechanisms within the RPC layer and would love > to see what others have done in this area (if anything). > > Thanks. > > -Brian > > -Original Message- > From: Alejandro Abdelnur [mailto:t...@cloudera.com] &g

Re: [DISCUSS] Hadoop SSO/Token Server Components

Alejandro, being the only voice on this thread that isn't represented in the votes above, please feel free to agree or disagree with this direction. thanks, --larry On Jul 5, 2013, at 3:24 PM, Larry McCay wrote: > Hi Andy - > >> Happy Fourth of July to you and yours. > &g

Re: Hadoop Summit: Security Design Lounge Session

nent ie 'hadoop-security' to be 'the' > security lib for all projects to use. > > Create a component/project that would provide the common security pieces > for all projects to use. > > -- > > If we agree with this, after any necessary corrections, I

Re: [DISCUSS] Hadoop SSO/Token Server Components

e self appointed "master JIRAs" and such, which have been > disappointing to see crop up, we should be collaboratively coding not > planting flags. > > I read Kai's latest document as something approaching today's consensus (or > at least a common point of view?

Re: [DISCUSS] Hadoop SSO/Token Server Components

to see crop up, we should be collaboratively coding not >> planting flags. >> >> I read Kai's latest document as something approaching today's consensus (or >> at least a common point of view?) rather than a historical document. >> Perhaps he and it can

Re: [DISCUSS] Hadoop SSO/Token Server Components

t;. The design update I > provided was meant to provide the necessary details so we can nail down that > relationship and collaborate on the implementation of these JIRAs. > > As you have also confirmed, this design aligns with related community > discussions, so let's co

Re: [DISCUSS] Hadoop SSO/Token Server Components

We should figure out some of the implementation > specifics for those JIRAs so both of us can keep moving on the code without > colliding. Kai has also recommended the same as his preference in response to > your comment on 9392. > > Let's work that out as a community of peers so

Re: [DISCUSS] Hadoop SSO/Token Server Components

e here to > engage in a collaborative process as peers. I've been encouraged by the > spirit of the discussions up to this point and hope that can continue > beyond one design summit. > > > > On Wed, Jul 3, 2013 at 1:10 PM, Larry McCay wrote: > >> Hi Kai - >

  1   2   >