What's so funny? WAS Re: rotor replacement

[phr at localhost.localdomain]

Skip Montanaro <skip at pobox.com> writes:
> Because good requirements specification is difficult and testing improves
> the breed.  Better to have the major API changes and bugs taken care of, and
> to have its popularity demonstrated *before* it gets into the Python
> distribution.  The best way to do something isn't always obvious at the
> outset.

That is sometimes true, but not always.  Sometimes the best way is
obvious.

> If multiple solutions exist in the community, everyone benefits.
> The best survive.  The worst don't.

What's needed here "good enough", not necessarily "the best
conceivable", a level of perfection which is perhaps unattainable.

> If one implementation is prematurely chosen for inclusion in the
> Python distribution, it stifles the vetting process.

There have been exactly zero alternative implementations proposed.

> Finally, what if, saints be preserved, your whizbang new module is

It is not a whizbang module.  It is a stripped-down, basic
implementation of a well-accepted set of standards that are being used
in thousands of other applications in other languages.

> included in the core distribution and it's just not as popular as
> was first thought?

There is demand for it.  Look at how this thread started: some crypto
user noticed that rotor was gone and wanted to know what to do instead.

The issue of whether there's enough desire for a crypto module to
warrant including one in the stdlib was decided a long time ago.  The
proof of that somebody decided to accept the rotor module into the
distro.

That decision, that enough users want crypto to make having a stdlib
module worthwhile, has never been reversed as far as I know.  Rather,
the specific module (rotor) was withdrawn because it turned out not to
do the job on technical grounds.  And the decision not to replace it
was based on new legal and political concerns that outweighed the
technical side, not on thinking that there wouldn't be enough users.

> It just winds up as a weight around the maintainers' necks.  Once
> included in the distribution it's difficult to remove.

The rotor module is gone (and good riddance).  That's how this thread
started, remember?  It shows that bogus modules can be removed.  

Have you ever used a crypto library in a serious way?  Which ones have
you used?  The python-crypto folks (including myself) have used quite
a few of them, and after a while one realizes that the usable ones all
do pretty much the same stuff.  The one we're talking about does about
the same stuff that the rest of them do.  It does the same stuff
listed in PEP 272, although it's organized a little bit differently in
order to make supplying multiple cipher primitives more convenient,
which the application that drove PEP 272 apparently didn't need to do.
Andrew (the author of PEP 272) has said that the different
organization is fine.  The different organization is similar to what's
done internally in OpenSSL, in Peter Gutmann's cryptlib, in GnuPG, and
various other successful programs.  It's not radical or experimental.
It's old hat and low risk.  It provides functionality that's missing
from the stdlib.

> Even rexec and Bastion, which are both known to be inadequate from a
> security standpoint, are still in the distribution.

They should be removed pronto, just as rotor was removed.  Some other
ones should be removed too, like SmartCookie.

> So, feel free to implement whatever it is you propose.

I don't need your permission to do that.  What I'm looking for is an
indication that it's worth my while, before I spend the effort.

> Register it with PyPI, announce it on comp.lang.python.announce, etc.

I don't know how to do that, but the folks who care about it are
mostly on the python-crypto mailing list, and the module has been
discussed at length there and has been well-received.

> Support it for awhile.  Run it through a couple revisions to fix API
> warts and bugs.  

I already did that with the Python implementation, and did in fact
revise the API somewhat based on reviewer feedback.  The C
implementation would have the exact same API that the reviewers seem
to be happy with.

> When it's the category king and there is substantial community
> support for inclusion,

It's already the category king, because there are precisely zero other
entrants in the category.  If someone else wants to do one and can get
it into the stdlib, I will gladly use theirs and stop worrying about
mine.

> it will be considered.

Not according to how I currently interpret Guido's posts to python-dev
about it.  I read those as saying that no crypto module will be
considered for inclusion whether or not it's the category king,
because any such module might conflict with crypto regulations in some
countries.  No matter how much community support or technical
perfection it has, it's just won't be included, period.  So tell me
again what to do after writing and releasing a C module.  There's just
no reason to write one, if the module can't go into the stdlib.  The
stdlib has some special requirements but there are existing crypto
modules that I'm using and that work just fine outside of the stdlib,
even though they don't meet the stdlib's special needs.  The only
reason to write a special module just to meet the stdlib's special
needs is so that the stdlib can use it.

> Python is popular in part because of its fairly conservative development
> strategy.  That goes for the libraries as well as the language itself.

Tell me again how rotor got into the distribution.