On 28/06/17 06:38, Ryan Sleevi wrote: > Not really, at least from the NSS perspective. There's been the CVS -> > Mercurial -> Git(ish) transitions, but otherwise, the tools and > dependencies have largely remained the same.
Well, the fact that we now use Git, I suspect, means anyone could plug in a modern CI tool that did "Oh, you changed file X. Let me regenerate file Y and check it in alongside". Without really needing anyone's permission beyond checkin access. > Put differently: If a human-readable version could be generated from a > machine-readable file, is the objective met or not? Well, I don't do the actual maintenance of certdata.txt, but I assume (perhaps without evidence) that telling whoever does that "hey, you now need to use this tool to edit the canonical information store, instead of the text editor you have been using" might not go down well. It wouldn't if it were me. > For example, you highlight that computer-readable only requires other tools > to maintain, but that's not intrinsically true (you can have > machine-readable text files, for example), and one in which you're just > shifting the tooling concern from "NSS maintainers" to "NSS consumers" > (which is worth calling out here; it's increasing the scale and scope of > impact). No, because NSS consumers could choose to continue consuming the (autogenerated by the CI tool) certdata.txt. > You've proposed solutions and goals that appear to align with "We want > Apple to use our format", and are explicitly rejecting "We will > interoperate with Microsoft using their format", while presenting it as "We > want interoperability" You want me to rank my goals in order of preference? :-) If Apple said "we are happy to use the MS format", I guess the next thing I would do is find Kai or whoever maintains certdata.txt and say "hey, it's not ideal, but what do you think, for the sake of everyone using the same thing?". > 3) If neither party arrives at an interoperable solution, are your goals > met and is the work justified? It's not a massive improvement if we are the only group using it. I think there is value to Mozilla even if MS and Apple don't get on board, because our root store gets more descriptive of reality, but that value alone might not be enough to convince someone like the two people who have expressed interest thusfar to take the time to work on the spec. I don't know. > Well, regardless, you need the C file, unless you're also supposing that > NSS directly consume the computer-readable file (adding both performance > and security implications). The C file I meant was ExtendedValidation.cpp. > The wiki page you mention is already automatically generated (by virtue of > Salesforce), No. The wiki page I meant was https://wiki.mozilla.org/CA/Additional_Trust_Changes . Sorry for not being clear on this. Mozilla's opinions on roots are defined by the sum total of: 1) certdata.txt 2) ExtendedValidation.cpp 3) The changes listed on https://wiki.mozilla.org/CA/Additional_Trust_Changes It's these 3 files I'm hoping could be combined (almost totally or totally) into one machine-readable store. Gerv _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
