OK, I understand. Thanks for your kindly reply. I have learned a lot from this discussion. Thank you again.
Cheers, Fan -----Original Message----- From: Paul Eggleton [mailto:[email protected]] Sent: Friday, January 16, 2015 8:55 PM To: Fan, Xin/樊 シン Cc: [email protected] Subject: Re: [oe] Question about ntp build option On Friday 16 January 2015 02:05:27 Fan, Xin wrote: > > There will always be differences in how people expect software to be > > configured for whatever target and application they are building > > for, hence why we make it fairly easy to adjust the configuration. > > Actually, I had the same opinion with you at the beginning. > > But in last December, the ntp published 4 serious > vulnerabilities(CVE-2014-9293, CVE-2014-9294,CVE-2014-9295,CVE-2014-9296). > So I think even the display a clock function, it should also be > protected by openssl for the safety connection. I'm not sure this follows. Correct me if I'm wrong, but SSL doesn't actually prevent me as an unauthorised user from making a connection - it just ensures that when I connect to a server that firstly the data sent over the connection is encrypted, and furthermore that the connection is directly to the server I think it is and not someone else masquerading as that server. This would mean that for example any buffer overflows such as the ones in the vulnerabilities you point to would still be accessible and potentially exploitable even if the connection were only available as encrypted using SSL, at least as far as I can tell. > And I find more packages in Yocto which also use the openssl as the > default option, so I think ntp also should set the openssl option as > default setting. In a lot of other cases SSL is on by default because it really makes sense; for example it's common to want to fetch files from https servers so in the general case you would want curl to be built with SSL support by default. I'm not sure the same can be said of ntp. Again, I'm happy to be corrected though. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-devel
