On Sep 21, 2016 6:34 PM, "Dave Thaler" <dthaler at microsoft.com> wrote: > > Two responses? > > > > Gregg wrote: > > ? fwiw imho SECURED should be removed from the build system altogether. Non-encryption security features should just always be enabled. > > > > Agree. > > > > ? But for debugging, something like --DISABLE_DTLS should be supported by the build logic > > > Disagree. Debugging does not require a build-time option, just a run-time option as Uze and I mentioned. > ok, but what kind of debugging? if you need to debug packets over the wire you need to disable dtls. But if you need to debug ACLs etc. maybe not?
by "runtime option" do you refer to setting security for resources? it seems to me that a runtime option to turn off dtls is problematic. it would introduce a whole 'nother security issue to guard this, which AFAIK is not adressed by the OIC protocol dpec. (Bear with me, I'm still learning this stuff). gregg > Uze subsequently wrote: > > > By investigating several option for secure resource setting by real execution, I can list up the three possible ways. > > 1) SECURE=0 build > > 2) SECURE=1 build, Create Resource with non-secure flag. OCCreateResource(?. uint8_t 0) > > 3) SECURE=1 build, Create Resource with secure flag. OCCreateResource(?. uint8_t OC_SECURE) > > > > We should delete way #1 and leave ways 2 and 3. The ?SECURED? flag can then be deleted since it?s always 1. > > > > Dave > > > > From: Gregg Reynolds [mailto:dev at mobileink.com] > Sent: Wednesday, September 21, 2016 7:05 AM > To: Dave Thaler <dthaler at microsoft.com> > Cc: iotivity-dev at lists.iotivity.org; Thiago Macieira < thiago.macieira at intel.com> > Subject: RE: [dev] SECURE build flag setting as default configuration > > > > On Sep 20, 2016 4:27 PM, "Dave Thaler" <dthaler at microsoft.com> wrote: > > > > I've now thought about this some more and I am now convinced that we should remove > > support for SECURE=0 builds (in master). > > > > As Uze mentioned, the choice to disable security should be a config/run-time decision, not > > a compile-time decision. There is no reason to consume build resources to build a version > > that cannot even be configured to enable security. > > > agreed in general but I think there is still a "problem", namely that "security" conflates multiple distinct functionalities. encryption is one thing; creds are another, and ACLs yet another. > > fwiw imho SECURED should be removed from the build system altogether. Non-encryption security features should just always be enabled. But for debugging, something like --DISABLE_DTLS should be supported by the build logic. > > this suggests also that that API should be changed. OCInit should be parameterized by persistent storage, and client code should not have to separately call an init function for persistent storage. in other words there should not be two ways to get going, one for SECURED=0 and one for SECURED=1. client app code should never need to make a secured/unsecured distinction. of course apps can still designate resources as secure or not but that is a completely separate topic. > > my 2 cents. > > gregg -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160921/86054a0c/attachment.html>
