According to
http://www.schneier.com/blog/archives/2005/02/sha1_broken.html
some Chinese researchers have just announced a break
against SHA1.  These are the same guys who broke MD5 a
few months ago and the SHA1 break, while not exactly
expected, is also not really shocking at this point. 
The break allows finding a free collision in the full
SHA1 in O(2**69) operations, still an awful lot in
practice.  So nobody should panic.  But it means that
new applications probably want to use SHA256, SHA384,
or SHA512, which were standardized by NIST at the same
time AES was standardized, as successors to SHA1.  The
hash lengths are 256, 384, or 512 bits respectively,
and correspond to 2x the AES key lengths of 128, 192,
or 384 bits.  Their design is strengthened from SHA1 to
resist attacks like this.  On the other hand, they are
slower than SHA1.

Anyway, there are various free implementations of the
algorithms around (libtomcrypt.org has some public
domain versions) so it should be straightforward enough
to transplant the Python C API wrapper from sha.c to it.

I think it's reasonable to put these all into the
existing sha module, rather than make a new module. 
They could be called by adding an optional arg to sha.new:
    x = sha.new(data, 256).digest()
would find the sha256 digest, etc.  

Note that sha512 and sha384 are the same algorithm,
with different initial parameters and with 128 bits
discarded for sha384. 

Logged In: YES 
user_id=593130

This is, of course, an RFE -- request for enhancement -- and 
not at all a bug report.  Will SF let you reclassify it?  I 
suspect your request is reasonable, but if you leave it here, it 
may get closed as Invalid -- not a bug.

If you really want this to happen, I suspect you know the 
drill: submit a patch and help review others.  What you may 
not know it that 'public domain' is mostly not acceptible for 
contributions.  The PSF's paid lawyer considers it bogus for 
modern creations other than government work.  What the 
PSF does want is stuff licensed under specific open source 
licenses and specifically contributed to Python by the 
author.  There also needs to be a code maintainer.  Getting 
all this takes more work that just visiting a site.

Logged In: YES 
user_id=72053

1. I submitted it as a feature request and thought that was
the same thing as an RFE.  If it needs to be reclassified in
some way, let me know how to do that.

2. The library I mentioned was explicitly released into the
public domain by the author.  I'd be interested to know what
the PSF's lawyer's objection is to using public domain code.
 The OSF license list doesn't include public domain but I
think that's just an oversight.  The FSF's license list says
public domain code is fine as free software. 
http://cr.yp.to/publicdomain.html cites a US Supreme Court
ruling that releasing stuff into the PD is perfectly legally
valid (at least in the US).  Is the lawyer complaining that
there's some obstacle in other countries?  If you have a
written opinion from him/her I'd appreciate seeing it.  I've
heard this claim before but it has always sounded bogus to me.

3. I'm not at the moment versed enough in the Python C API
to be able to do this patch quickly, and I have other things
going on so I can't spend time on it right now.  I'm also
not willing to be the long-term maintainer even if I do the
patch.  I submitted the report mostly to give the lib.
maintainers a heads-up to the new development. 
SHA256/384/512 (collectively known as SHA2) has been on the
horizon for a long time as an SHA1 successor, but the recent
results against SHA1  are going to make SHA2 into a higher
priority addition than before.  Other people are going to be
asking for it and its absence will become a somewhat serious
deficiency in the stdlib.  So, someone interested in this
kind of thing might want to look into it.

4. The SHA2 patches should be pretty simple.  SHA2 is just
like SHA1 in terms of API and basic functionality.  The
actual algorithms are different and the lengths of the
returned hash are different but that should be a
straightforward matter of adding wrappers for the new
functions.  

Logged In: YES 
user_id=72053

Oops, correction to previous, US court ruling was from 9th
circuit, not Supreme Court.  However it doesn't appear to be
a matter of controversy.  Prof. Lessig's pages about
Creative Commons also say that releasing stuff into the PD
is valid and I think Prof. Moglen has said something
similar.  The PSF lawyer might want to talk to Lessig or
Moglen if there's some uncertainty.

Logged In: YES 
user_id=72053

Addendum: Note that this RFE is an enhancement request for
the sha module.  Therefore I think the best way to triage it
is to assign it to the current sha module maintainer and let
him decide what if anything to do about it.  If he accepts a
patch (or does one himself), it's logical for him to also
take ownership of the patch at that point.  Sha is a
relatively uncomplicated module and it doesn't make much
sense for it to have multiple maintainers.  

I don't think any harm will be done if this stays open for a
while until someone gets around to doing a patch.  But
sooner or later there will be a need for it.

Logged In: YES 
user_id=593130

Yes, feature request = RFE.  However, this somehow got into 
the tracker as a bug item, not an RFE item.  Check the top of 
the page or beginning of email subject line or body text.  
Hence my comment.

My FYI legal issue summary was based on a PyDev thread 
within the last week and the Contribution pages at 
python.org.  I have no opinion on the lawyer dispute over 
PD.  PSF's lawyer wrote his opinion in a LinuxJournal piece 
referenced in that thread.  PSF Board is inclined to follow 
advice paid for.

Yes, Sha module should be maintained by one person.  Hope 
one of crypto people sees and responds to this item.

There is also a current PyDev thread about sha?, md5, ssl, 
and licensing, but I barely paid attention.

Logged In: YES 
user_id=72053

I couldn't find the "Contributions" section of Python.org;
got a url?

I did find PEP 241 says public domain is a legitimate choice
of license, and also the PSF patch submission agreement near
the bottom of
http://www.python.org/psf/psf-contributor-agreement.html 
suggests releasing the patch to the PD (but only if the
contributor wrote the entire patch, which wouldn't apply to
wrapping some existing public domain work).  Also a lot of
the PEP's are released as PD.  So maybe you want to revisit
all those docs, if there's now some problem with PD releases.

I think the Linuxjournal article you refer to might be
http://www.linuxjournal.com/article/6225 .  It is just
bizarre.  Is that the same lawyer?  It says he also advises
the OSI, so I might email him with that Bernstein cite.  

This tracker item clearly says "Feature request" in the
"Group" pulldown when I look at it in Sourceforge.  That's
the way I entered it and if it's showing up differently for
you, something is going wrong somewhere.

Logged In: YES 
user_id=593130

Here is the top of this page:
Project: Bugs: Trackers 
and here is the beginning of the email sent to me:
Bugs item #1123660, was opened at 2005-02-16 04:14

I found the explanation:  on 
https://sourceforge.net/tracker/?group_id=5470
you need to click RFE instead of Bugs on this line:
Summary |  Admin |  Home Page |  Tracker |  Bugs |  
Patches |  RFE |  

When you click Bugs, Feature Request shows up under 
Group because it was put there before there was a separate 
RFE list and now, I remember, it cannot be removed.  
(SF 'feature')  But it would be if it could be.
---

Yes, that is the lawyer and article.  Yes, I noticed the 
discrepancy 'PD not real' and current PEP PD policy, but 
refrained from saying anything yet.  I have no more to do 
with those and other docs than you do.

Contributor agreements: your link is to a 3 1/2 year old 
draft, badly misleading, but first hit on 'contributor' search.  
I have suggested its removal.  Current, I believe,  is 
http://www.python.org/psf/contrib which links to
http://www.python.org/moin/PythonSoftwareFoundationLicen
seFaq and 
http://www.python.org/psf/contrib-form.html

Logged In: YES 
user_id=593130

Addition to the previous: current does not necessarily mean 
final.  I am not a party to any ongoing non-public discussion 
of these issues.  Over and out.

Logged In: YES 
user_id=72053

Well, I don't see an obvious way to reclassify this item. 
If someone knows how to do it, please go ahead.

I sent an email to the lawyer and haven't gotten a response
yet.  

Logged In: YES 
user_id=593130

Ok, next time....
You might want to look at 
https://sourceforge.net/tracker/index.php?
func=detail&aid=1121611&group_id=5470&atid=305470

Logged In: YES 
user_id=80475

"Break" is a bit of an over-statement.  

Logged In: YES 
user_id=1188172

This should be addressed by the addition of the hashlib
module in 2.5.