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 > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: one-pager-gkrellm.txt URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080825/f18b7388/attachment.txt>
