Garrett D'Amore wrote: > Darren J Moffat wrote: >> >> The reason it was done for OpenSSL was because it was known not to >> have a stable API or ABI at the time. That has changed over time and >> the massive number of ARC contracts (more than any other case in >> history and I'm sure there as some missing) has become a total >> paperwork burned with no pay off. >> >> That is going to change very very soon as OpenSSL is quickly >> approaching a 1.0.0 release (it is currently in Beta 2). At the point >> it reaches 1.0.0 we plan to no longer use contracts. >> >> So given the above please don't use OpenSSL as a precedent setting >> case - unless it is to demonstrate that for unmodified upstream >> community FOSS the contract system is unworkable in some cases. >> > > But as we've seen recently, openssl's interface breakage across > consolidation boundaries can cause pain and suffering. While contracts > a pain in the neck, they *should* have the effect of helping project > teams track usage and figure out who needs to be worked with when > updating versions.
Except that it didn't work and no amount of contracts could have fixed that. > In the case of OpenSSL I think it should do something else -- > applications using OpenSSL that are developed *internally* really > shouldn't be using OpenSSL. We should be directing such applications to > PKCS#11 which is a standard and stable API, and plays much better with > our encryption framework. I very strongly disagree. PKCS#11 is a crypto API and a very low level one at that. Most applications that use OpenSSL are using it for the SSL API. PKCS#11 does not provide an SSL API. When we brought the proposition to ARC to create another SSL API in userland it was rejected so we defunded the effort. We have three perfectly good C APIs for doing SSL in Solaris: OpenSSL, NSS, GNUtls. The former two can use PKCS#11 provided crypto and thus take advantage of UltraSPARC T2 and SCA-6000 based acceleration. > I hope when the OpenSSL 1.0 is released, it also means that they will > give something beyond lip service to API and ABI stability. That would > be something new. :-) > > Now maybe the interface stability considerations aren't a big deal here > for ghostscript. I'd at least like the question answered -- if the > interfaces are generally stable, then I have no problem with a Volatile > or Uncommitted binding. If they are so unstable as to limit what we can > do with them (such as upgrading to newer releases of the upstream), then > I'd recommend a Contracted interface just to help us understand the uses > of the API. (I suspect far fewer applications use ghostscript than use > OpenSSL, so the concerns are probably much less severe here.) I strongly disagree that a contract will at all be useful here. This is a case where both the supplier and consumer are upstream unmodified FOSS projects that we do not directly influence nor are they strategic enough that would would want to. If this went to a vote I would vote to NOT require an ARC contract for this. Just make the interfaces Uncommitted and lets move on. -- Darren J Moffat
