Hi, all I am resetting the time out for this case to be August 29th. Any issues please send an email before then.
Thanks --Irene Brian Cameron wrote: > > 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 >>> >
