Darren J Moffat wrote:
>
>
> 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.
Sorry, I guess I see a lot of apps using OpenSSL for pure crypto, rather
than for SSL per se. NSS is probably a superior choice for SSL, but
I've not much direct experience with SSL itself, so I'll defer to your
wisdom.
>
>> 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.
But even if they aren't modified, they might have to be kept
synchronized. I think it is useful, if there is significant risk of
this kind of breakage, to know what the likelihood is. Particularly
for stuff we deliver and support. I care less about what other people
might compile and install on their system.
>
> 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.
Okay, it was just a suggestion -- I'm not sure I'm in agreement, but I
never suggested that I'd stand firm on a requirement. The
recommendation still stands -- if the interface is going to potentially
cause breakage when it changes, and if changes in the interface are part
of the norm, then we should have some way to track the interface
consumers. That is what contracts are for.
Maybe what is needed here is a ilghter weight form of contract.. one
that doesn't require signatures or such. I'm thinking of some kind of
"restricted" or "registered" use. The producer can say what the
interfaces in the ARC case and give a commitment (hypothetically
"Registered", and the Consumers are free to use it by simply filling out
a basic form and dropping it in the case directory. The form could
include : consuming project, bugster category, and an engineering
contact. That would be a better shrink to fit process, while still
achieving the goal of knowing who the consumers are.
Thoughts?
- Garrett
