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: [email protected] [mailto:[email protected]] On Behalf Of Thiago Macieira Sent: Tuesday, March 6, 2018 9:08 AM To: [email protected] 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 [email protected] https://lists.iotivity.org/mailman/listinfo/iotivity-dev _______________________________________________ iotivity-dev mailing list [email protected] https://lists.iotivity.org/mailman/listinfo/iotivity-dev
