Right now the C code expects "doxm", "acl", "pstat" and others to be byte 
arrays. In multiple places it read the value and checks if it is a bite array.

This could be fixed but it is not a trivial fix since it would involve working 
through a lot of the C code and fixing locations that expect the byte array and 
are doing error checking based on the assumption of having a byte array.

The big issue is keeping backward compatible with the security.dat files as 
they are now while making it possible to use more standard cbor encoding. 

-----Original Message-----
From: iotivity-dev-boun...@lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Thiago Macieira
Sent: Tuesday, March 6, 2018 9:08 AM
To: iotivity-dev@lists.iotivity.org
Subject: Re: [dev] .dat files not being .gitignored?

On Tuesday, 6 March 2018 01:41:47 PST Wouter van der Beek (wovander) wrote:
> Ok, why is this done like this?
> Since this can be done in 1 conversion from the top… I know this is an 
> implementation only (e.g. I am not aware that this is on the wire this 
> way..), but now we need to maintain code that does this..

Unknown at this point. I've just asked Nathan and he doesn't know for sure 
either. The leading theory is that the values need to be kept as-is for some 
reason.

Or a mistake.

Anyway, here's what the .dat file contains. Each of the values in the CBOR map 
is a byte array containing more CBOR code. It's a single level of nesting, so 
it's easy to do this with a Python tool.

$ $ ../../tinycbor/bin/cbordump ./resource/csdk/security/unittest/
oic_svr_db.dat
{_ "acl": 
h'a46761636c6973743284a465616365696401677375626a656374a168636f6e6e747970656a616e6f6e2d636c656172697265736f757263657383a16468726566682f6f69632f726573a16468726566662f6f69632f64a16468726566662f6f69632f706a7065726d697373696f6e02a465616365696402677375626a656374a168636f6e6e747970656a617574682d6372797074697265736f757263657383a16468726566682f6f69632f726573a16468726566662f6f69632f64a16468726566662f6f69632f706a7065726d697373696f6e02a465616365696403677375626a656374a168636f6e6e747970656a616e6f6e2d636c656172697265736f757263657381a164687265666d2f6f69632f7365632f646f786d6a7065726d697373696f6e0ea465616365696404677375626a656374a168636f6e6e747970656a617574682d6372797074697265736f757263657382a164687265666d2f6f69632f7365632f646f786da164687265666e2f6f69632f7365632f726f6c65736a7065726d697373696f6e0e6a726f776e657275756964782437353665366236652d366637372d363536342d343436352d373636393633363534393634627274816a6f69632e722e61636c32626966816f6f69632e69662e626173656c696e65',
"pstat": 
h'a963646f73a26173016170f46469736f70f462636d0262746d00626f6d0462736d046a726f776e657275756964782437353665366236652d366637372d363536342d343436352d373636393633363534393634627274816b6f69632e722e7073746174626966816f6f69632e69662e626173656c696e65',
"doxm": 
h'bf6373637400656f776e6564f46a64657669636575756964782430303030303030302d303030302d303030302d303030302d3030303030303030303030306c6465766f776e657275756964782430303030303030302d303030302d303030302d303030302d3030303030303030303030306a726f776e657275756964782430303030303030302d303030302d303030302d303030302d303030303030303030303030627274816a6f69632e722e646f786d626966816f6f69632e69662e626173656c696e65ff'}

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



_______________________________________________
iotivity-dev mailing list
iotivity-dev@lists.iotivity.org
https://lists.iotivity.org/mailman/listinfo/iotivity-dev
_______________________________________________
iotivity-dev mailing list
iotivity-dev@lists.iotivity.org
https://lists.iotivity.org/mailman/listinfo/iotivity-dev

Reply via email to