*Obj methods appear to rely on object property order

[jtremback]

Is this the case or am I missing something?

[pfrazee]

I think you may be right /cc @dominictarr

[dominictarr]

yes. okay this is something we need to discuss... technically, the order in js is not defined in the spec. But, v8 does give you an order that matches the order items where added... same with firefox.

one thing here is that objects in ssb and basically immutable, so we arn't adding properties except after it's first created.

[jtremback]

It doesn't seem very safe to me, have you looked at stuff like bencode?

[jtremback]

https://www.npmjs.org/package/json-stable-stringify

[pfrazee]

That could be a good solution

[dominictarr]

the other approach that could be used: https://camlistore.googlesource.com/camlistore/+/master/doc/json-signing/json-signing.txt

this might be better (and not require parsing then reparsing ever) but would require some special stuff to keep track of the raw string, so it can be used instead of parsing. it also has the nice effect of insuring immutability.

[jtremback]

What are the constraints here? I'm assuming:

• Avoid requiring a bunch of stuff in this security-critical module
• Retain some form of readability of the documents in the db (?)

I'm not sure I completely understand what's going on with the Camilstore link, but it doesn't appear to do anything about field order.

-- Serialize in-memory JSON object 'O' with whatever JSON
   serialization library you have available.  internal or trailing
   whitespace doesn't matter. We'll call the JSON serialization of
   'O' (defined in earlier step) 'J'
   (e.g. doc/example/signing-before-J.camli)

I'd be in favor of stable-stringify if there are no concerns

[dominictarr]

@jtremback it addresses that indirectly. Instead of forcing an order, instead it never re-serializes the object. This means that whatever order the object was first written in is always used. The trick here being that when it removes the signature to check the hash of the unsigned message, it removes it from the static serialized string, not the parsed object... so the order can never change.

[jtremback]

Nice. I'm definitely in favor of the forced immutability. However, if we just assume that SSB will never re-save a document I suppose we arrive at the same thing.... so maybe this issue is just not relevant right now if people are using SSB correctly.

[dominictarr]

@jtremback currently it reserializes when it creates and verifies a signature...

on the other hand, it will probably be much easier to have a well defined order than to ensure that the order is preserved while copying the object over rpc etc etc... We'd have to put special encoding functions all over the place. What we could do, is first check whether the object is already ordered correctly, which won't copy the object, so extra memory won't be allocated even after verifying thousands of objects...

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.