On Sep 19, 2016 4:37 PM, "Thiago Macieira" <thiago.macieira at intel.com> wrote: > > On segunda-feira, 19 de setembro de 2016 15:53:26 PDT Gregg Reynolds wrote: > > > It shouldn't be *supported*. > > > > > > It was used for a long time during development so that we could do a > > > packet > > > capture and use it to debug what was happening. > > > > Sorry, I am a bear of small brain. do you mean it was used to disable dtls > > so that e.g. stuff captured by wireshark would not be encrypted? was there > > more to it than that? > > Correct, it disabled encryption and the ACLs, along with the security-related > resources that IoTivity implements on behalf of the application.
ok, thanks, I appreciate your patience. and will now presume to abuse it. ;) as far as I can see, security is layered. we have transport-level security in dtls. we need to be able to turn this off, for debugging. then we have, further up in the stack, ACLs, creds, etc. is there ever a reason to turn these off? I don't see that they have anything to do with lower-level encryption. am I missing anything? the problem as I see it is that SECURED=0/1 gloms together a bunch of stuff that should not be glommed. Howsabout this: there is no SECURED=0. Upper-level security is always enabled. If you really need to debug stuff you do WITHOUT_DTLS or sth like that - you can turn off transport-level encryption but that's all. what am I missing? gregg > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160919/197768f6/attachment.html>
