Darren J Moffat wrote: > Hugh McIntyre wrote: >> Uros Nedic wrote: >>> [2] Let we extend libsoup with additional interfaces capable >>> to deal with this issue, or to change actual implementation >>> of interface we have conflict with. >> >> If you look at the following libsoup bugs, it looks like >> libsoup is planning to add new certificate APIs, and therefore >> OpenSolaris should preferably not add it's own conflicting APIs. >> >> http://bugzilla.gnome.org/show_bug.cgi?id=507802 >> >> and >> >> http://bugzilla.gnome.org/show_bug.cgi?id=507801 (pass certs in memory, >> not just files) >> >> and >> >> http://bugzilla.gnome.org/show_bug.cgi?id=334021 >> >> There's more than a suggestion in one of these bugs that Fedora plans >> to migrate the SSL backend to Mozilla's NSS for Fedora at least, >> which OpenSolaris may not want to. But either way it seems this case >> should not get sidelined into inventing new APIs nor really get into >> a discussion of different WebKit network stacks. > > I don't see why we wouldn't want to migrate to Mozilla NSS. In fact I > would strongly encourage it. Some of the core developers of Mozilla > NSS actually work for Sun. We already have core parts of OpenSolaris > that either depend on NSS to function at all or can use it as an option. >
>> Instead the discussion should maybe stick to just the question of >> what the default HTTPS setting should be, whether Darren's suggestion >> of linking this case to shipping a working root CA file is >> appropriate, and how to document how to load alternate certs. > > Lets assume there is a file that had the same set of CA certificates > as is present in firefox and it was in a format suitable for libsoup. > With that assumption is there any reason not to have HTTPS enabled > with Webkit pointing to that file ? > Makes sense to me. My experience so far is that in cases like this, an opinion is issued with advice language intended for project management/funding for another project to deliver that necessary deliverable. Do we need to continue to hold this project hostage or can we re-approve it with the directive that the PMO needs to fund a project to deliver CA certs so that we can switch the default from /dev/null to /home/of/certs? In the interest of moving along, I'd like to suggest something, thinking aloud as it were. I'm going to work on the assumption that delivery of CA certs involves only 3 non-trivial issues: a) where they go, and b) how/where are they obtained, and c) how to deal with CRL. Assuming that those issues could be solved by a quick discussion, then I believe the community could solve this issue quite quickly by proposing a project through the external project creation process, and delivering the dozen+/- certificates. I wonder if the aforementioned advice section could address an audience /other/ than the usual Sun funding sources -- would that be a first for an ARC advice to explicitly acknowledge an external community and source of projects? This seems like such a no-brainer that I'd like to offer leading that effort if I can get some confirmation on my assumptions. Of course, if the project team feels that they could name that tune in fewer notes, they're more than welcome to, and I'd still be happy to lend my keyboard in whatever way makes sense.
