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