Garrett D'Amore wrote: > Sorry, I guess I see a lot of apps using OpenSSL for pure crypto, rather > than for SSL per se.
True; it does happen. OpenSSL *does* have stable interfaces, but as far as I know, the unstable ones aren't properly scoped away. Having that done would be nice. (Perhaps have "libopenssl_naughty.so.1" with the interfaces exposed and "libssl.so.1" as a filter exposing just the stable ones ...) > 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? That's just what the existing contract mechanism is supposed to be. It's very lightweight (just requires a couple of email messages) and registers usage of an interface. I suppose if someone wanted to work on a spiffy new tool to do this, that'd be interesting, but I think it's putting lipstick on a pig. Contracts are -- by their very nature -- merely hacks. Proper engineering demands stable interfaces from producers and an avoidance of implementation details by consumers. Contracts allow us to put the normal rules of good design in abeyance, but you can't do that too often or for too long a time, or bad things start happening. In the case of openssl, it's been going on for a really long time. -- James Carlson 42.703N 71.076W <carlsonj at workingcode.com>
