On Sep 20, 2016 9:32 PM, "???(Uze Choi)" <uzchoi at samsung.com> wrote: > > From the app/service developer perspective, I?d like to raise the issue for removing SECURE=0 build check. > > > > 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) > > > > I had expected 1), 2) to work same but I figured out they behave differently. > > 2) will cause crash or ACL issue. we can refer to the Jira issue (IOT-1280 ~ IOT-1291). > > When we build the IoTivity basic sample application and execute it, then it will due to acl requiring. > > Until resolve this issue, we cannot give up the SECURE=0 build. (sorry for my previous proposal) > > > > IMHO, This case (SECURE=1 build, Create Resource with non-secure flag. OCCreateResource(?. uint8_t 0)) should skip the acl checking. >
but if security is the default, acls should never be skipped. an "unsecure" resource would just be one with a particular kind of "anything goes" acl, no? To me, this looks like a larger design issue. it looks to me like we have 2 ways to "provision" a resource: 1) an api function, an 2) a config file with creds and acls. so I'm wondering (having just begun to grok the acl stuff) why we even need an api. ok, the callback. But for everything else, since security is the default, why not do it only in the config file? > Or, We can make the API such as OCINIT (bool secure_setting) as like Gregg suggestion. Actually my suggestion was intended to be that the ps struct would be passed to OCInit, mainly to save the trouble of calling init in something (psi) that must always be done anyway. Gregg > Anyway, I?m not clearly aware how IoTivity security project or OCF security WG decided to handle it. > > > > Randeep or Nathan could you clarify it and share the plan? > > > > BR< UZe Choi > > From: iotivity-dev-bounces at lists.iotivity.org [mailto: iotivity-dev-bounces at lists.iotivity.org] On Behalf Of Gregg Reynolds > Sent: Wednesday, September 21, 2016 7:05 AM > To: Dave Thaler > > Cc: iotivity-dev at lists.iotivity.org > 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/4be2b720/attachment.html>
