Gkrellm for OpenSolaris [LSARC/2008/513 FastTrack timeout 08/19/2008]

[Brian Cameron]

Henry:

Much more clear.  Thanks.

Brian


> Brian Cameron 写道:
>>
>> Henry:
>>
>> The one pager does not mention the ~/.gkrellm2/plugins-gkrellmd/
>> interface, nor does it mention that end users can install their own
>> plugins.
>>
>> In section 4.1 you say:
>>
>>        And in order to make install plugin, you should be root,
>>        and ensure the plugin will not add additional security issue.
>>
>> The above seems a bit misleading since you can also install plugins
>> as users.  You don't need to be root.
> 
> That make sense, I added the content on the end-user plugin supports.
>>
>> In section 4.11, you say
>>
>>         This application uses OpenSSL, and support plugins, it may cause
>>         some security concern,
>>
>> It isn't clear if you are saying that there is some security concern
>> with OpenSSL or plugins, or both.  Is the security concern the same
>> or different for these two things?
>>
>>         but generally all data transfered through the connection
>>         is the system usage status information, and not very
>>         confidential,
>>
>> It is probably reasonable to say this for the default plugins, but
>> I'd think that an end user could install plugins that do not follow
>> this general rule.
>>
>>         addtionally in order to make the network connection more secure,
>>         this application is using SSH and some configuration on IP/port
>>         to use,
>>
>> Do you mean to say "this application uses SSH and allows the sysadmin
>> to specify which IP/port to use via configuration."   Are you suggesting
>> that being able to configure the IP/port adds security?  You misspell
>> "Additionally".
>>
>> In general I find section 4.11 a little hard to read since it is one
>> long sentence.
> I updated the one-pager, hope this make things more clear.
> 
>>
>> Brian
>>
>>
>>> I would summary the discussion below.
>>>
>>> 1, The battery support on Solaris:
>>> I investigated 2 solution, one is the  patch wrote by David, but this 
>>> patch is using acpidrv.h and /dev/acpidrv which are not on Solaris 
>>> now, the other solution is using HAL, I think this is a solution we 
>>> can use.
>>> So I am implementing to use HAL/Dbus for the battery information.
>>>
>>> 2, SSL certification authentication:
>>> I checked the bugzilla, and no category for GKrellM, I sent a mail to 
>>> the maintainer on this issue. I am discussing with him on how to fix 
>>> this problem..
>>>
>>> 3, Security impact:
>>> Add some content to describe the possible impaction.
>>>
>>> Attachment is the updated one-pager..
>>>
>>> Thanks,
>>> Henry
>>>
>>> Henry Zhang ??:
>>>> Hi Darren,
>>>>
>>>> Thanks, I will file a bug on this issue...
>>>>
>>>> Regards,
>>>> Henry
>>>>
>>>> Darren J Moffat ??:
>>>>> I see from the code that it is passing SSL_VERIFY_NONE to 
>>>>> SSL_CTX_set_verify()
>>>>>
>>>>>  From the man page:
>>>>>
>>>>>
>>>>>      SSL_VERIFY_NONE
>>>>>          Server mode: the server will not send a client
>>>>>          certificate request to the client, so the client will
>>>>>          not send a certificate.
>>>>>
>>>>>          Client mode: if not using an anonymous cipher (by
>>>>>          default disabled), the server will send a certificate
>>>>>          which will be checked. The result of the certificate
>>>>>          verification process can be checked after the TLS/SSL
>>>>>          handshake using the SSL_get_verify_result(3) function.
>>>>>          The handshake will be continued regardless of the
>>>>>          verification result.
>>>>>
>>>>>
>>>>> This is the answer for the case.  Personally I'm not happy with 
>>>>> this however it is what gkrellm does and it answers my question.  I 
>>>>> would like the project team to file a bug upstream (if there isn't 
>>>>> one already) to provide functionality to actually verify the 
>>>>> server's SSL/TLS certificate.
>>>>>
>>>>> -- 
>>>>> Darren J Moffat
>>