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.
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.
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
