[lsb-discuss] LSB conf call notes for 2008-05-14

[Jeff Licquia]

Attendees: Jeff Licquia, Robert Schweikert, George Wilson from IBM, Stew 
Benedict, Kai Engert from Red Hat, Carlos Duclos, Jesper Thomschultz, 
Juergen Doelle from IBM Germany, Ron Hale-Evans, Dan Kohn, George Kraft, 
Vladimir Rubanov, Alexey Khoroshilov, Marvin Heffler, Darren Davis, 
Nelson Bolyard, Ted Tso, Bob Releya from Red Hat, Wan-Teh Chang (Google 
developer on NSS), Kay Tate, Alan Clark.

Affinity.  Jeff: are Mats's APIs mentioned on the list today good 
enough?  Robert: probably good enough.

SSL discussion, part two.

Juergen: two crypto hardware feature; session open/close, and data 
encryption.  Drivers support them well; apps don't.  Problem is that 
they have to provide code for each hardware feature to support, which 
creates a large burden on developers (testing, etc.).  Bob Releya: could 
have a solution; NSS provides high-level interfaces, will use the 
hardware automatically if needed.

Juergen: apps using NSS?  OpenSSL is popular.  One point of 
configuration for crypto stuff, used by all apps/libs, so apps can just 
say "encrypt" and it happens, w/ hardware support.  Bob: OpenSSL shim 
thought about.  Problem: OpenSSL API exposes too much low-level stuff, 
difficult to shim.  Have software that can help convert OpenSSL code to 
NSS.  There is a page for crypto consolidation.  Jeff: link?  Robert: 
sent to list previously.  Bob: OpenSSL issues were why RH chose to move 
to NSS.

Ted: what is experience with upstream regarding patch acceptance?  Bob: 
mixed, better than expected, some pushback, but have gotten changes 
upstream.  More on OpenSSL conversion: when calling just the SSL stuff, 
is easy to convert.  More difficult when you poke at the data structures.

Juergen: is it possible to define a standard for Linux?  Bob: should 
define strict subset of OpenSSL if we do that.  OpenSSL like assembly 
language; NSS more like a high-level language.  People tend to wrap the 
OpenSSL API anyway.

Ted: if there's a desire for a standard, maybe we just need to promote 
NSS as standard.

Carlos: how difficult would it be to provide a NSS wrapper in Qt that 
was compatible with the OpenSSL-based wrapper?  Bob: important thing is 
what you expose.  If you expose key handles and not key data, the port 
should be simple.  Gets more complicated the more you expose things like 
hardware tokens and key material.  Carlos: should take offline to 
discuss details.

Jeff: any OpenSSL folks?  Ted: Ben Laurie said that the ABI would have 
to be completely reworked, would be a huge amount of effort, OpenSSL 
doesn't have the resources to do, also not a lot of interest.  Ben is a 
core maintainer, so he should know.  NSS looks like the way forward.

Jeff: should we implement in stages, doing the higher-level API first? 
Bob: some APIs are well-documented, others not so much.  That might be a 
better way to do stages.  ABI-compatible since 2000, w/ sane backward 
compatibility and deprecation policies.  Jeff: does NSS use symbol 
versioning?  Bob: yes, never get rid of old entry points, define old 
ones in terms of the new.

Juergen: LSB 4?  Jeff described the purpose of the LSB.  Juergen: 
standard applies to SuSE?  Jeff: yes.  Bob: NSS is already there.  Jeff: 
  we describe what distros are already doing.

Ted: we (ISPRAS, actually) also provide tests to ensure compatibility. 
Starting with well-documented interfaces would be good.  Upstream tests 
would also be good if they exist; otherwise we'd need to write them. 
Bob: NSS has a test suite as part of the source code.  Based on shell 
scripts.  Some holes.  Would take tests contributed by LSB.  Testing run 
continuously on Mozilla Tinderbox.  Jeff: we've worked with upstream 
test suites before.  Probably only need to report status in TET journal 
form.  Bob: single function that reports the results of the test, 
currently writes out HTML.  Should be easy to provide addditional types 
of output.

Nelson: do good regression, not so much unit testing.  Ted: our system 
from ISPRAS makes it easy to write additional tests; uses their own 
framework, so would need to integrate.

Robert: can Nelson send a list of proposed APIs to the list as a 
starting point?  Nelson: probably can be done.  There is a list of all 
exposed functions in the source.  Docs are also public.  Someone would 
need to cross-reference docs with exposed ABIs to get the list.  Bob: 
best place to start is our wiki page.  Most of docs are generated.  Did 
a "how to do SSL doc"; those functions are the best documented.  Ted: 
could rely on the PKCS 11 spec.  Bob: higher-level API wrapper is not 
PKCS, though it sometimes exposes PKCS structures.  PKCS 11 is more of a 
plugin layer for NSS.  Nelson: can program to PKCS if they wish to, but 
needs exposure of lots of details.  NSS is preferable for most apps. 
Ted: some people use OpenSSL for dumb crypto; might want to use PKCS.

Carlos: issues with using both OpenSSL and NSS?  Bob: no.  Juergen: 
converter?  Bob: toolkit for converting apps.  Low-level OpenSSL API is 
difficult to convert, but toolkit does a lot of the work.  Juergen: 
Apache?  Bob: mod_nss already exists.  Takes pretty much the same 
configuration as mod_ssl; some changes.  That was done by hand.  Will 
send a link to mod_nss.  Ted: Apache Foundation should take that.  Bob: 
should submit it upstream.

Jeff: in sum, we should identify the well-documented parts of NSS as 
standardization candidates.  Ted: should we use the "how to write an SSL 
app" document as a howto for ISVs to convert from OpenSSL?  Bob: there's 
a document on the crypto consolidation page on how to do the conversion. 
  Work in progress.  Ted: could we help promote the effort?  Bob: would 
love someone who could write docs.  Ted: we do have a tech writer. 
Might not be a long doc.  Ron: would be happy to help.  Will email Bob.

Bob will do the list of APIs as an initial run.

Jeff: don't need another SSL call, as the way forward seems clear. 
Thanks to everyone who participated; would appreciate continued 
participation as we move this to a real standard.