What's so funny? WAS Re: rotor replacement

["Martin v. Löwis"]

Paul Rubin wrote:
> An AES or DES addition to an existing module that implements just one
> call:
>    ECB(key, data, direction)
> would be a huge improvement over what we have now.

Apparently, people disagree on what precisely the API should be. E.g.
cryptkit has

obj = aes(key)
obj.encrypt(data)

I think I would prefer explicit encrypt/decrypt methods over a
direction parameter. Whether or not selection of mode is a separate
parameter, or a separate method, might be debatable - I'ld personally
prefer a separate method. However, we would have to ask users.

> If you think a function like that could be added to some existing
> module with less hassle than adding a new module, then I can write one
> and submit it.

I would trust my intuition more for a single function than for an
entire API. In this specific proposal, I think I would trust my
intuition and reject the ECB function because of the direction
argument.

> Come on, you're being deliberately obtuse, we've discussed this over
> and over.  There are plenty of AES modules that people can get from
> somewhere.  The topic is what it takes to have an AES module that
> people don't NEED to get from anywhere, because they already have it
> from having Python installed.  Do I have to keep repeating "batteries
> included" until you understand what it means?

I fully understand what you desire - to include the module "as a
battery". What makes this decision difficult is that you fail to
understand that I don't want included batteries so much that I
would accept empty or leaking batteries.

>>http://sourceforge.net/projects/cryptkit/
> Well, that code has been around for over a year, people are using it,
> etc.  Are you saying you'll support its inclusion if Bryan offers to
> contribute it?

*Now* you get it. Precisely that. I would ask the users what they
think about the API (shouldn't be too difficult because the module
does have users) and what they think about other aspects (performance,
stability, and so on).

> I've examined that module, I wouldn't consider it
> ideal for the core (besides AES, it has some complicated additional
> functions that aren't useful to most people)

Ok, that would be a problem. If this is a simple removal of functions
that you'ld request (which functions?), I'ld try to collect opinions
on that specific issue, and ask Bryan whether he could accept
removal of these functions.

>    So if the module was primarily written to be included in the core, I
>    would initially reject it for that very reason. After one year or so
>    in its life, and a recognizable user base, inclusion can be considered.
> 
> The context was new modules in general, not specifically an AES
> module.  Since "considered" means "thought about", so you said
> inclusion shouldn't even be thought about until the module is already
> done.  That's completely in conflict with the idea of inviting anyone
> to work on a new module, since inviting means that there's been some
> thought.

I rarely invite people to work on new modules. For new modules, I
normally propose that they develop the module, and ship it to users
for some time.

I may have made exceptions to this rule in the past, e.g. when the
proposal is to simply wrap an existing C API in a Python module
(like shadow passwords). In this case, both the interface and
the implementation are straight-forward, and I expect no surprises.
For an AES module (or most other modules), I do expect surprises.

> I would say there's an implied promise of something more than a code
> review.  There's an implied statement that you agree that the proposed
> new functionality is useful, which means the patch has a good chance
> of being accepted to the stdlib if it's not too messy or cumbersome.

I have said many times that I am in favour of including an AES
implementation in the Python distribution, e.g. in

http://mail.python.org/pipermail/python-dev/2003-April/034963.html

What I cannot promise is to include *your* AES implementation,
not without getting user feedback first. The whole notion of
creating the module from scratch just to include it in the core
strikes me as odd - when there are so many AES implementations
out there already that have been proven useful to users.

> So let me just ask you one final question: suppose I do all that
> stuff.  The question: in your personal opinion, based on the best
> information you have, what is the your own subjective estimate of the
> probability?

Eventually, with hard work, I estimate the chances at, say, 90%. That
is, eventually, unless the code itself shows flaws, the module *will*
be included. However, initially, when first proposed, the chances are
rather like 10%. I.e. people will initially object. Decision processes
take their time, and valid concerns must be responded to. I personally
think that there is a good response to each concern, but it will take
time to find it. Before that, it will take time to find out what
precisely the concern is.

Regards,
Martin