On Tue, Jun 27, 2017 at 3:52 PM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> On 27/06/17 12:17, Ryan Sleevi wrote: > > This was something the NSS developers explicitly moved away from with > > respect to certdata.c > > It would be interesting to know the history of that; but we are in a > different place now in terms of the SCM system we use and the CI tools > available, versus what we were a few years ago. > 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. > If you were able to elaborate on the relevant history here, as you > obviously know it, that would be helpful. > Well, the obvious issue remains cross-compiling and what dependencies are acceptable. So the minimal set was - in order to maintain compatibility with NSS consumers like Red Hat and Oracle - the set of tools already integrated into the build system. Even the transition to GTests has not been without controversy, and not all GTests are run by all NSS consumers, due to the dependency on (modern) C++. I highlight this because the "Mozilla build environment" is not necessarily aligned with the "NSS Build environment" > >> That's one option. I would prefer something which is both human and > >> computer-readable, as certdata.txt (just about) is. > > > > Why? Opinions without justification aren't as useful ;) > > :-) Because human-readable only is clearly silly, and computer-readable > only is harder to maintain (requires tools other than a text editor). I > want it to be easily maintainable, easily browseable and also > unambiguously consumable by tools. > Put differently: If a human-readable version could be generated from a machine-readable file, is the objective met or not? You've put a very particular constraint here (both human and machine readable), which is very much a subjective question (as to whether it's human readable), and which arguably can be produced from anything that meets a machine readable format. 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). I can understand the preference, but I'm trying to suss out what the actual hard requirements and goals are, since as exciting as the prospect is, not only does it require work (to define said schema), but it requires work to integrate that schema, and wanting to understand what the long-term payout is. > > Apple suggested they'd like to make this data available; my hope would > >> be that if a format could be defined, they might be persuaded to adopt > it. > > > > And if they can't, is that justified? > > > > That is, it sounds like you're less concerned about cross-vendor > > interoperability, and only concerned with Apple interoperability. Is that > > correct? > > I'm after interoperability with whoever wants to interoperate. That doesn't really helpfully answer the question, but apologies for not making it explicit. 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" 1) Is it correct that you value Apple interoperability (because they've privately expressed some interest, or which you hope to convince them to, given their public statements) 2) Is it correct that you do not value Microsoft interoperability (because you're explicitly defining criteria that would reject that interoperability) 3) If neither party arrives at an interoperable solution, are your goals met and is the work justified? > The other > benefits I see for Mozilla are being able to better (if not perfectly) > express our root store's opinions on our level of trust for roots in a > single computer-readable file, rather than the combination of a text > file, a C++ file and a wiki page. > 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 wiki page you mention is already automatically generated (by virtue of Salesforce), and you're certainly not eliminating that burden of maintenance, so it seems like you still have three files - the 'source in tree', the generated code, and the Salesforce-driven output. Can you explain to me the benefit there? > Given that the plan is to auto-generate the old formats when necessary, > I didn't think that maintaining the data in a different format would > cause anyone significant difficulty or hardship. > Transitioning to txt caused hardship for downstream NSS consumers, some of which had to integrate manually regenerating the C file as part of their workflows (of which, Google was one). Was that justified by the transition? > >> Like, really? Developing a set of JSON name-value pairs to encode some > >> fairly simple structured data has potential IP issues? What kind of mad > >> world do we live in? > > > > It doesn't matter the format - it matters how and where it was developed. > > As in, if I just make it up and start using it, people will be scared > I'm going to sue them over its use? Yes. This is why, for example, certain large vendors working in the CA/Browser Forum found it necessary to establish the IP policy. Certainly, having worked with Microsoft and Apple in a variety of fora, and been indirect and incidental party to a number of the discussions related to choice of venue, I feel confident saying that, whether immediately or eventually, the need for a strong IP commitment will certainly be necessary once the lawyers are aware. It's not for lack of interest that certain members do not publicly comment in certain venues - it's part of the company policy. If your goal is to produce a standard - and not just a library that implements said code (and which would be directly integrated into these vendors products) - you should seriously consider reaching out to these parties - and their counsel - and determine an appropriate venue. Even something like WICG may be able to satisfy the various needs, but I have incredible difficulty imagining "throw it up on GitHub" would suffice, as would "hash it out in m.d.s.p" _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
