|
From: Jim M. <jm...@hp...> - 2012-05-01 19:14:25
|
Duncan, I attached the patch to the defect and also committed the change to TOB. I'm going to close the bug out as fixed. Thanks again, :) -- Jim Mankovich | jm...@hp... -- On 5/1/2012 12:43 PM, Duncan Idaho wrote: > Jim, > > as it turns out, I can't attach anything to "artifact" that I don't > own(which makes some ... ehm ... sense). > Anyway. Patch is attached including commit message. Your call now :) > > --Duncan > > On Tue, May 1, 2012 at 5:49 PM, Jim Mankovich<jm...@hp...> wrote: >> Duncan, >> >> This patch looks good to me. >> >> Thanks, >> >> >> -- Jim Mankovich | jm...@hp... -- >> >> >> On 5/1/2012 5:12 AM, Duncan Idaho wrote: >>> Jim, >>> >>> it is all right. Attached is v2 which covers user name longer than 16 >>> bytes. I've also checked the code, again, and password length restrain >>> will work for all three methods - cli, ask-pass, file. Let me know if >>> we're done with this one, and I'll attach patch to SF.net ticket. >>> Funny enough, I've found a bug by testing this. Reading password from >>> file is limited only to 16byte passwords. I've logged SF.net ticket. >>> >>> As for 'user set password', don't think about it now. I think limiting >>> password length is sufficient for now. I've logged feature request >>> already, so it is noted and won't be forgotten. I don't think this is >>> feature that has to make it into 1.8.12. >>> I will eventually look at it, however I have nothing to test against >>> nor I'm optimistic about many, if any, BMCs actually supporting 20 >>> byte passwords. >>> >>> --Duncan >>> >>> On Mon, Apr 30, 2012 at 9:41 PM, Jim Mankovich<jm...@hp...> wrote: >>>> Duncan, >>>> >>>> Your validation is reasonable for password "input" verification since the >>>> input password is only >>>> applicable to lan/lanplus. >>>> >>>> You were correct when you said that I was talking about the code which >>>> sets >>>> the password. For that >>>> case, we simply permit folks to specify up to 20 characters independent >>>> of >>>> the interface or IPMI >>>> version. >>>> >>>> When I looked at your changes I was thinking about password "set" >>>> verification which is why I >>>> my comments didn't make sense with regard to your changes. >>>> >>>> Sorry for the all the confusion. >>>> >>>> >>>> -- Jim Mankovich | jm...@hp... -- >>>> >>>> >>>> On 4/30/2012 2:39 PM, Duncan Idaho wrote: >>>>> I'm probably have a very thick skull. Have any of you looked at the >>>>> patch? Because I still feel like it handles what's described in the >>>>> ticket. >>>>> Anyway, I obviously fail to understand and thus I'm not correct person >>>>> to fix it. Anyone else give it a go, please ;) >>>>> >>>>> --Duncan >>>>> >>>>> On Mon, Apr 30, 2012 at 8:33 PM, Andy Cress<and...@us...> >>>>> wrote: >>>>>> Duncan, >>>>>> >>>>>> From the remote client (before it connects), you would verify that the >>>>>> -P input is<= 20 characters. >>>>>> Then after initiating the connection (GetChanAuthCap), you could detect >>>>>> if it is IPMI 2.0 or not, and then be able to find out if it supports >>>>>> 20-byte passwords. >>>>>> >>>>>> IPMI 1.5 and prior = only 16-byte passwords can be used >>>>>> IPMI 2.0 = many vendors implement 20-byte passwords, but not all. >>>>>> >>>>>> To make it (much) simpler, just validate the input once at 20 >>>>>> characters, and let it go through after that. The user has to know the >>>>>> correct password anyway. >>>>>> >>>>>> Andy >>>>>> >>>>>> -----Original Message----- >>>>>> From: Duncan Idaho [mailto:dun...@gm...] >>>>>> Sent: Monday, April 30, 2012 4:10 PM >>>>>> To: Jim Mankovich >>>>>> Cc: ipm...@li...; Albert Chu >>>>>> Subject: Re: [Ipmitool-devel] Reg issue with password having 16 bytes >>>>>> [ID:3184687] >>>>>> >>>>>> Jim, >>>>>> >>>>>> I'm sorry, but I don't follow. What? I feel like you're talking about >>>>>> setting password now, eg. % ipmitool user set password UID PASSWORD;. >>>>>> I thought the issue is % ipmitool -P veryLongPassword -H myhost some >>>>>> commands here ; And that's what patch should address. I haven't tried >>>>>> password from file and via ask-pass, come to think of it, but I have >>>>>> tested -P parameter. >>>>>> >>>>>> Please, elaborate your e-mail a bit more. I'm, well, confused. >>>>>> >>>>>> Thanks, >>>>>> --Duncan >>>>>> >>>>>> On Mon, Apr 30, 2012 at 8:01 PM, Jim Mankovich<jm...@hp...> wrote: >>>>>>> Duncan, >>>>>>> >>>>>>> After I looked at this I came to the realization that I had over >>>>>> simplified >>>>>>> the 16 vrs 20 byte >>>>>>> password to lan vrs lanplus, when in fact it is really an IPMI 1.5 vrs >>>>>> IPMI >>>>>>> 2.0 issue. >>>>>>> It is also possible to set a password via the /dev/ipmi interface so >>>>>>> qualification of >>>>>>> password length using the interface is not sufficient to cover all the >>>>>>> cases. >>>>>>> >>>>>>> I believe doing this correctly will require password length >>>>>> verification >>>>>>> based on the current >>>>>>> IPMI version. >>>>>>> >>>>>>> This patch will ca >>>>>>> >>>>>>> -- Jim Mankovich | jm...@hp... -- >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 4/28/2012 5:41 AM, Duncan Idaho wrote: >>>>>>>> Jim, >>>>>>>> >>>>>>>> attached is proposed solution to constrain password length to 16, >>>>>>>> resp. 20, bytes when LAN, resp. LAN+, interface is used. >>>>>>>> >>>>>>>> Comments are, of course, welcome from anybody. >>>>>>>> >>>>>>>> --Duncan >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> ------ >>>>>> Live Security Virtual Conference >>>>>> Exclusive live event will cover all the ways today's security and >>>>>> threat landscape has changed and how IT managers can respond. >>>>>> Discussions >>>>>> will include endpoint security, mobile security and the latest in >>>>>> malware >>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>>>>> _______________________________________________ >>>>>> Ipmitool-devel mailing list >>>>>> Ipm...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/ipmitool-devel >>>>> |