On 29/06/17 16:27, Ryan Sleevi wrote: > Well, the current certdata.txt is a text file. Do you believe it's > human-readable, especially sans-comments?
Human readability is, of course, a little bit of a continuum. You can open it in a text editor and get some sense of what's going on, but it's far from ideal. How it is sans-comments is irrelevant, because it has comments. :-) (For those not familiar, here's a sample from certdata.txt: # Trust for Certificate "Verisign/RSA Secure Server CA" CKA_CLASS CK_OBJECT_CLASS CKO_NETSCAPE_TRUST CKA_TOKEN CK_BBOOL CK_TRUE CKA_PRIVATE CK_BBOOL CK_FALSE CKA_MODIFIABLE CK_BBOOL CK_FALSE CKA_LABEL UTF8 "Verisign/RSA Secure Server CA" CKA_CERT_SHA1_HASH MULTILINE_OCTAL \104\143\305\061\327\314\301\000\147\224\141\053\266\126\323\277 \202\127\204\157 END CKA_CERT_MD5_HASH MULTILINE_OCTAL \164\173\202\003\103\360\000\236\153\263\354\107\277\205\245\223 END .... > Please realize that this makes it impossible to effectively test changes, > without running said tool. This is, again, why certdata.txt being generated > is part of the build - so that when you change a file, it's reflected in the > build and code and you can effectively test. Of course, those changing the root store might need access to the compilation tool. But from a Mozilla PoV, that's just Kai normally. And if people were used to editing and consuming certdata.txt, they could continue to do it that way. Thought experiment for you: if we decided to make the root store its own thing with its own repo and its own release schedule, and therefore NSS became a downstream consumer of it, where on occasion someone would "take a release" by generating and checking in certdata.txt from whatever format we decided to use, what problems would that cause? > That's why "machine-readable" is, in effect, a must-have. I'm not sure anyone is arguing with that. > So clearly, we get in situations where not all restrictions are expressible. Sure. As I said, I'm not interested in an arbitrarily complex file format, so it will always be possible to come up with restrictions we can't encode. But whatever format Apple chooses, unless they go the "arbitrary complexity" path, they will have that problem, no? Gerv _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
