Re: Re: [RFC] Horde_Cipher -> Crypt_Cipher

Jon Parise wrote:

On Sun, Jul 27, 2003 at 03:02:09PM +0100, Davey wrote: Hi Davey, Please don't take any of my comments too personally. I might have the wrong impression of what you're trying to accomplish here.

And to all maintainers, you know your code and presumably you know the algorithms and stuff that lie beneath them whereas I do not, ...

You admit that you don't understand the way this code works and yet you're trying to refactor its design and distribution. I appreciate the fact that you're trying to champion a generalized cryptographic interface for PEAR, but I'm not sure I care for your approach.

Personally, I'd like to see each of the Horde_Cipher 'drivers' become standalone packages with a central blocking package, this means that when you only *need* DES, or blowfish, thats all you need to have. I don't want to use an entire abstraction class with Auth_HMAC for example, I *know* I'm only going to be using HMAC and nothing else.

I don't see the value in splitting up the Horde_Cipher package into "drivers". It will just increase the management overhead, and it will require the "base" interface and package consumers to do too many things conditionally.

My point is that some of these "drivers" are already split (the current PEAR ones). Should we continue with this split or deprecate and include them. There should be no conditional stuff, like MDB, your application doesn't care what Cipher/Hash is used, so long as one is. And by keeping the drivers seperate, it means their current maintainers can just carry on with their work and I can do mine on top... this keeps things cleaner IMO.

Imagine that I write some code that uses your new PEAR cryptographic interface. I wouldn't be able to rely on a specific cipher being always available because I couldn't guarantee (without runtime testing) that the site has that "driver" installed.

If you want a *specific* cipher, you use the stand-alones, thats the point, *why* add the overhead of abstraction when you're only using a *specific* cipher? i.e. why use MDB when you're only using PostgreSQL? The idea of how I would like to do it, is your scripts don't care about what cipher is used, it inputs plaintext and gets the encrypted version back (for storing in a DB or whatever) and vice versa.

Your argument about not *need*'ed certain drivers doesn't really hold water. The classes aren't that big nor do they pollute the PEAR namespace. _Not_ having them installed with the rest of the crypto infrastructure doesn't buy you anything.

Again, I don't want to have distribute the entire Crypt_Hash API + all drivers *just* to use HMAC within my script. Why distribute the drivers for MySQL, PostGreSQL, Oracle, Frontbase, Querysim, Interbase, Firebird, MSSQL when distributing something that only needs to run on *one* of these? You wouldn't, you'd use the internal functions.

As someone pointed out earlier, we don't distribute PEAR::(DB|MDB) drivers separately; that degree of granularity is excessive.

See above

I only see disadvantages to this driver model.

I meant to have stand-alone implementations which can be used on their own, or you can use the abstraction class and your code can use whatever the person running the code wants. This is your opinion you're entitled to it

I think once the current package owners have answered the questions above, we'll have a clearer idea of what wants doing, and then I'll just get on and do it.

I don't much care for your attitude toward the existing package authors. It feels like your trying to hold them responsible for explaining the details and implementation of their packages to you. While that's not unreasonable, I think there's a certain expectation for you to do this work yourself.

Did you even read the questions I asked? None of them, except for the CBC ones where "how does your package work? teach me!" they were "what would *you* like as this most likely affects your work".

You've admitted twice on the Horde mailing list that you a) don't understand the way crypto code works, and b) you haven't actually looked at the Horde_Cipher code. I don't understand how you can be proposing reorganizations to code that you haven't seen.

I've had a quick look at the Horde_Cipher code, and from what I understood it already runs on this "Abstract API + Drivers" implementation, all I'm proposing is moving the drivers to be stand-alone packages.

So, in summary, (and I'm biased here), I think the Horde_Cipher package is the most complete crypto implementation we have available right now. The code is living happily in Horde CVS, and Mike (Cochrane) has stated that he won't support a "driver" model.

s/"driver"/"Stand-alone drivers model"/

The Horde_Cipher code has also been "PEAR-ized" in that it conforms to the coding standards and is package-able. If the only problem here is distribution, we can make the package available via pear.horde.org. I see no reason to morph the code into something else or to even import the code into PEAR CVS.

One of things Horde_Cipher does *not* do, which I would like Crypt_Cipher/Hash to do, is handle the use of mcrypt/mhash instead of the userland implementations where available. As it doesn't, I'm quite happy to add it. In fact, I will most likely write the api stuffs from scratch using Horde_Cipher as a good example of the API. - Davey