Re: How to send a query to the browser from time to time?
Admin [EMAIL PROTECTED] writes: If there were a way to have the server-side application send new messages to the browser this would be awesome because it would save dramatically on bandwidth. The application would consume bandwidth only when there are new messages. There would be no communication client-server until people write a new message. Do you know if it's possible? Some people have done stuff like that with multipart mime encodings and chunked transfers. I've looked into it but I'm not sure of the exact mechanism any more. It's kind of messy. The other usual way is to open a tcp connection from a java applet. I don't like that since it means you need java in your browser. There's a chat app called arsc that you might look at: http://manuel.kiessling.net/projects/software/arsc/ Warning, last time I looked at it, it had some security bugs. -- http://mail.python.org/mailman/listinfo/python-list
Re: Elliptic Code
Philip Smith [EMAIL PROTECTED] writes: Does anyone have/know of a python implementation of the elliptic curve factoring algorithm (lenstra) which is both: simply and cleanly coded functional It's not in Python but take a look at Mike Scott's C++ implementation in MIRACL, http://indigo.ie/~mscott/ It's the simplest and most direct implementation I know of, just the bare essentials. It could probably be translated into Python pretty straightforwardly. I'm aware of William Stein's code (from elementary number theory book) but I don't understand his coding style and the algorithm doesn't seem to work efficiently. A high performance implementation means complicated code, e.g. Peter Montgomery has done a few of those. If it's for instructional purposes I think the MIRACL version is far more understandable even if it's slower. If you mean you don't understand the algorithm, try Neal Koblitz's book A Course in Number Theory and Cryptography. It has no code but it explains the algorithm in a pretty accessible way. -- http://mail.python.org/mailman/listinfo/python-list
Re: Who should security issues be reported to?
Nick Coghlan [EMAIL PROTECTED] writes: Is that the sound of a volunteer I hear? All you have to do is put your hand up, and the problem will be solved. If not you, who? Tell me about it. See the rotor replacement thread. -- http://mail.python.org/mailman/listinfo/python-list
Re: What's so funny? WAS Re: rotor replacement
Skip Montanaro [EMAIL PROTECTED] writes: phr It is not a whizbang module. It is a stripped-down, basic phr implementation of a well-accepted set of standards that are being phr used in thousands of other applications in other languages. Then there should be a library already out there already. All you should need to do is wrap it (manually, with SWIG, whatever). I'm currently using something wrapped with SWIG, but my understanding is that core modules are not supposed to depend on SWIG. So a core module will likely use some existing primitives wrapped by hand. That is what I've offered to do, along with providing a somewhat more Pythonic interface (though still a straightforward one) than directly wrapping a C library intended for use from C applications. phr There is demand for it. Look at how this thread started: some phr crypto user noticed that rotor was gone and wanted to know what to phr do instead. Yes, and putting rotor back would be the wrong thing to do. Correct. The right thing is to replace rotor with something reasonable that follows standards. phr The issue of whether there's enough desire for a crypto module to phr warrant including one in the stdlib was decided a long time ago. phr The proof of that somebody decided to accept the rotor module into phr the distro. No, rotor was added in Python's early days (July 1992). Times have changed. I don't see that. There's surely even more demand for crypto now than there was in 1992. As long as we are discussing cryptography, what's wrong with m2crypto? http://sandbox.rulemaker.net/ngps/m2/ It's a good package but it's pretty heavyweight. It depends on both SWIG and OpenSSL. I think it's still under development--there's an occasional flurry of messages about it on python-crypto, but I haven't been following it closely. I'd have a hard time making a case for accepting it into the core given the difficulty I'm having making the case for something as simple as a block cipher wrapper. m2crypto+OpenSSL is at least 100 times as much code as the module I've proposed. I think the Python lib should someday have its own pure-Python SSL/TLS implementation sort of like the one Java has. But if m2crypto went into the lib, I'd use it. Why not incorporate it into the standard distribution? I don't have the authority to incorporate anything into the standard distribution. All I can do is offer to contribute stuff that I write, and let the distro maintainers decide whether to incorporate it. I don't have the authority to offer m2crypto, since I'm not the author. Only the authors can do that. They haven't done so, as far as I know. Or, what about Andrew Kuchling's crypto toolkit? http://www.amk.ca/python/code/crypto.html This is perhaps more suitable than m2crypto but as far as I know, Andrew hasn't offered to contribute it. Whatever his reasons are, I have to respect them. I think it has more stuff than a core crypto module really needs (e.g. numerous semi-obsolete algorithms that aren't in widespread use so aren't needed for interoperability) but the extra stuff doesn't really get in the way. If it were in the core, it would completely fulfill my desires and I would be transported with ecstacy. But I've never seen any indication that it's headed there. I believe both have been around awhile. If crypto-in-the-core is really what's needed why not see if one of them is ready to go? I don't think m2crypto is the answer, though maybe I'm wrong. And if Andrew's package is the answer, he would have submitted it already. phr Have you ever used a crypto library in a serious way? Nope, never directly. Don't make this about me. I'm interested in the Python development process and how you'd like to turn it on its head. Either you're the one turning the actual process on its head, or else it's already on its head and needs to be turned rightside up. Either way, the existing process has certainly been a total failure so far at producing good crypto support in the lib. phr It's already the category king, because there are precisely zero phr other entrants in the category. See my above references. Note, I don't use crypto at all, yet I was aware of both of these (no Googling required). The authors have not offered to contribute them, so they're not in the category. The category consists of crypto modules that have actually been offered. As I keep saying, I'd love it if someone else offered one. I'm not eager for this headache. I just saw that somebody really ought to do it, and nobody was doing it, so I decided I was elected. My guess would be they are substantially more mature than your proposed module. This may sound a little strange, since my module is not yet written, but if we take maturity to mean lower future maintenance needs, then I wouldn't say m2crypto is precisely more mature. m2crypto uses SWIG
Re: What's so funny? WAS Re: rotor replacement
Skip Montanaro [EMAIL PROTECTED] writes: As long as we are discussing cryptography, what's wrong with m2crypto? Or, what about Andrew Kuchling's crypto toolkit? Lucas Umm, is it just me or did we just discuss the legal issues of Lucas that?? You may have. Whether or not there are legal issues with them is of little relevance to the point I was making. Anything Paul writes would probably have the same legal entanglements. Andrew's toolkit does incorporate some patented algorithms, but those aren't critical and could be removed from a stdlib version. I was simply pointing out that maybe, just maybe, there are already suitable candidates from a technical standpoint and that he doesn't need to write anything. There really don't appear to be any that are both technically suitable, and that the authors are willing to contribute to PSF. I'd be delighted to be wrong. Of course that still leaves the legal issue. -- http://mail.python.org/mailman/listinfo/python-list
Re: Please suggest on the book to follow
santanu [EMAIL PROTECTED] writes: I know a little python (not the OOP part) learnt by studying the online tutorial. Now I would like to learn it more thoroughly. I think there's supposed to be a new version of Python in a Nutshell coming. That's a more serious book than Learning Python. -- http://mail.python.org/mailman/listinfo/python-list
Re: OT
Diez B. Roggisch [EMAIL PROTECTED] writes: Is this a problem with my dns? Most probably - he shows up as [EMAIL PROTECTED] for me. It's my news client configuration. Normally I post from a different machine but that one is temporarily down. I haven't bothered to configure this one properly because I didn't expect to have to be using it this long. I don't want to keep posting from this machine for long, so if the other machine is going to stay down, I'll figure out some other alternative. Sorry for this weirdness. --Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: What's so funny? WAS Re: rotor replacement
Martin v. Löwis [EMAIL PROTECTED] writes: That it's not appropriate for the distro maintainers to look at the spec and the reference (pure Python) implementatation and say yes, we want this, go write the C version and we'll include it after it's had some testing. I know that I'm not going to give a blanket promise to include some code in the future. I can give blanket promises to *review* such code. Actually, assuming I find the time, I will review *any* code that is contributed. I don't see why you can't make up your mind enough to issue simple statements like the Python lib should have a module that does so-and-so, and it should meet such-and-such requirements, so if someone submits one that meets the requirements and passes code review and testing and doesn't have unexpected issues or otherwise fail to meet reasonable expectations, we'll use it. Sure. That is because O'Reilly is willing to take a financial risk of failure of a book product. I'm not willing to take similar risks for Python code (risk of having to redesign the interface, Again, we're talking about straightforward modules whose basic interface needs are obvious. And interfaces in stdlib do get extended from version to version all the time, if users turn out to need additional features beyond the obvious basics. fix bugs in the implementation, Obviously there must be testing and review before inclusion. Acceptance is contingent on the module passing tests and review. or have the submitter run away after the contribution). There is no way to know in advance whether that's going to happen. A lot of work on the ANSI X9 crypto standards came to a screeching halt a few years ago when one of the more prolific contributors tripped over his vacuum cleaner cord, fell down the stairs, and was killed. So if you have to be absolutely sure that the submitter will always be around, you can never accept anything. I think you mostly have to go by how maintainable the code looks and how much maintainance you think it will actually need and how many people you think are around who can take care of it when needed. And I do believe that experienced programmers are capable of making reasonable judgements about those questions, so they should not refuse to ever make such judgements. Similarly, look at how the whole PEP process works. There are lots of times when a PEP has been accepted before any working code is distributed. Indeed. For new language features, it is more difficult to try them out in advance than for new library API. I don't see why that should be. Nothing stops anyone from implementing and testing a language feature before standardizing it. It will get even easier with PyPy, which is perhaps a reason to ban further language changes until PyPy is deployed. Taking it to the extreme misses the point. I'm asking for field testing for new modules - not for all changes. Field testing to most people means testing that a specific implementation is reliable enough for inclusion. It is the final step in a normal process of declaring a feature ready for deployment, not the initial step: 1) think about whether you want the feature 2) decide you want it 3) implement 4) field test (this naturally recognizes the possibility of reversing step 2, if something unexpectedly goes wrong in testing that's not easily repaired, but step 2 declares the basic intention for what should happen after a successful test). 5) deploy You wanted much more than for step 4 to always happen before step 5, which is reasonable. You claimed step 4 should always happen before step 1, which is silly. That's bizarre and abnormal as a development process. What kind of development process in industry doesn't decide whether to include a feature, until after the feature is completely implemented at a production scale? Any high-quality standardization process. Standards in IETF and OMG are only accepted after implementations have been available. I don't know what OMG is, but there is no IETF requirement that any implementations be available in any particular language. There are also plenty of instances where the IETF decides that it wants something to be standardized (e.g. IPSEC) so it invites a working group to develop a specification. The WG members then spend a lot of time in meetings and discussions reaching a consensus on what the spec should say. They are willing to spend that time because the IETF has already given them reasonable expectation that their end result will actually be used. The IETF doesn't say go develop a complete standard and implementation and put it in the field for a year before we [the IETF] will even think about whether we want to standardize it. They are capable of announcing in advance that they want to standardize something. I don't see why the Python folks have to be incapable of ever doing the same. For the module we're discussing, there is already a published
Re: What's so funny? WAS Re: rotor replacement
Skip Montanaro [EMAIL PROTECTED] 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
Re: What's so funny? WAS Re: rotor replacement
Jeremy Bowers [EMAIL PROTECTED] writes: The policy has been laid out, multiple times, by multiple people now. The answer is, you are not going to get any such indication that will satisfy you. Actually I already got an indication that satisfied me, from Guido and Andrew, although it was later withdrawn for nontechnical reasons (i.e. legal restrictions) that I don't feel entitled to argue against very much. I do, however, believe that what Frederik and Martin are saying is bogus on technical grounds, and furthermore, they're just being busybodies, since they've had no involvement at all in what's happened already with that module, and their picture of the Python development process doesn't have much resemblance to how the current Python distro got to be the way it is. Note that I am not a Python contributor of any kind. Also note that I figured this out about two days ago. You can wheedle these guys all you want, I have not asked them for anything, since they are not in a position to give it. but they are too experienced for you to extract a promise from them. Actually, one of them already gave a promise that he couldn't keep even if he wanted to. He said that if I wrote a crypto module and got it tested enough, it would be considered for inclusion (i.e. based on its technical merits). But, he doesn't get to decide that. Current policy per per Guido seems to be that because of the legal stuff, there will be no crypto module in the stdlib regardless of its merits. -- http://mail.python.org/mailman/listinfo/python-list
Re: Crypto in Python: (Was: What's so funny? WAS Re: rotor replacement)
Philippe C. Martin [EMAIL PROTECTED] writes: I do not know in which country the python.msi is compiled (Deuchland ?), but most likely, the county has rules like most other as far as crypto code in binary format export (especially if distributed as part of a commercial package): for instance, if you want to export a .exe in France, you usually have to go through the DCSSI, in the USA, the BIS . It is a _long_ and tedious process. In the USA, it's pretty simple, you just send an email to an address at the BXA telling them what you're exporting. See http://www.bxa.doc.gov/Encryption for info. -- http://mail.python.org/mailman/listinfo/python-list
Re: Help! Host is reluctant to install Python
Daniel Bickett [EMAIL PROTECTED] writes: I've been trying to convince my host to install python/mod_python on his server for a while now, however there are a number of reasons he is reluctant to do so, which I will outline here: I'm surprised that you're getting such detailed answers from him. Usually, low-cost web hosts want to offer a one-size-fits-all package that requires minimal interaction with customers. If you're paying $10 a month for hosting and a host admin has to spend 1 hour sending you email, that probably wipes out at least 6 months of profits from you as a customer. If you want custom service you usually have to pay a lo tmore. 1. His major reason is optimization. He uses Zend's optimization of PHP as an example, and he has stated that python is rather resource consuming. Maybe that's true, though if there's enough customer demand for Python anyway, the answer is to buy more equipment and pass the costs on. The real problem is there's not enough demand. 2. Another one of his points is that he is unexperienced in installing python, and he would not know how to do it securely. By 'securely', I'm assuming he means disallowing a malicious (or ignorant) user from harming the server That's a serious issue too, and securely means not just securing against the service's own customers, but also against outside attacks. I have no idea how carefully mod_python has been audited. I don't use it myself, though I do run some Python cgi's. I have no experience with this sort of thing, so I'm asking a little assistance in the direction of any documents or websites (or what have you) I could show him in order to answer some of these questions, or perhaps even some unspoken ones -- anything worth noting. (all I'm really going to do is link him to this thread once it has accumulated any answers) I think you should look into some type of virtual hosting that gives you more ability to install your own software. Typing uml hosting (UML is user-mode Linux) into Google finds a lot of such services. If you find one that you like, post it here, I'm interested in this myself. -- http://mail.python.org/mailman/listinfo/python-list
Re: Crypto in Python: (Was: What's so funny? WAS Re: rotor replacement)
Philippe C. Martin [EMAIL PROTECTED] writes: So far getting the agreement for my product has taken two months of work (http://www.bis.doc.gov/encryption/) I hope to get a positive response this week (wish me luck!) That sounds like you're doing a closed source product and need an ENC exception or something even worse. Python should qualify for the TSU exception which only requires sending an email. http://www.bxa.doc.gov/encryption/PubAvailEncSourceCodeNofify.html -- http://mail.python.org/mailman/listinfo/python-list
Re: What's so funny? WAS Re: rotor replacement
Fuzzyman [EMAIL PROTECTED] writes: I also feel the lack of a standard cryptography module in the core... even a *basic* one. At least rotor provided that, before it was deprecated. Rotor was insecure and really shouldn't have been used. If you need crypto in pure Python, try this: http://www.nightsong.com/phr/crypto/p3.py It's a nonstandard algorithm, but so was rotor. Its security should be much better than rotor's, and its speed should be tolerable for most purposes. -- http://mail.python.org/mailman/listinfo/python-list
Re: What's so funny? WAS Re: rotor replacement
[Note: this is a 2nd attempt at posting reply to Martin's message, since the first one didn't reach the server. It's a rewrite from memory but says about the same thing as the other attempt. --Paul] Martin v. Löwis [EMAIL PROTECTED] writes: Paul Rubin wrote: If he understood how Python is actually used, he'd understand that any C module is a lot more useful in the core than out of it. This is non-sense. I have been distributing C modules outside the core for quite some time now, and I found that the modules are quite useful. distutils makes it really easy for anybody to use them. Maybe we're not thinking about the same problems. Say I'm an app writer and I want to use one of your modules. My development environment is GNU/Linux, and I want to ship a self-contained app that anyone can run without having to download additional components. That includes people wanting to run my app on Windows, Macintosh, Amiga, and various other Python target platforms that I don't have compilers for. How do I do it? I'm sure your modules are excellent but as an app writer, I feel I must try to avoid needing them, in favor of modules that are already in the core, even if it means more work for me or worse functionality in my app, just for the sake of reducing installation headaches for my target audience. So, if your modules are generally useful, I hope you will try to get them into the core. There are already tons of 3rd party crypto modules outside the core, and the module I was writing wouldn't add anything useful to those. Why do you think these are not part of the core? It's not because they contain crypto code, or because they had been rejected. They are primarily not included in Python because they have not been contributed to Python, yet. I can't speak for the authors but I'd personally say that none of those old modules are really suitable for the core on technical grounds. They're too fancy and specialized, or they depend on external libraries like OpenSSL, or they're written mostly to support some specific application and don't present a simple, general-purpose interface like a core module should have. Maybe the authors felt the same way and chose not to submit them. Or maybe the authors had other reasons, such as licensing priorities that conflict with the Python license. The module I'm discussing would simply implement the FIPS standard block ciphers (AES and DES) and the FIPS operating modes. These are the basic building blocks that I feel are missing from the core. They should be enough to fill the crypto needs of most applications. If they were contributed, a number of things still would need to be considered, e.g. what is the size of the code, including libraries, is the contributor really the author, is the code likely going to be maintained, and so on. However, it never got that far. The module we're talking about wouldn't have had any of those problems. I know that *I* am very opposed to any contribution of a larger module that has not seen any real users, yet. We're not talking about a larger module, we're talking about a module that implements the basic AES and DES block ciphers (similar to how the sha module implements the basic SHA-1 hash algorithm) and wraps them with some well-defined FIPS operating modes (similar to how the hmac module wraps the sha module to compute RFC 2104 hmac authentication codes). This stuff isn't rocket science. It's just straightforward implementation of modes and algorithms that go back to the 1970's, are the subject of national and international standards, and are already in use in thousands of non-Python applications all over the world. Also, I've already released a pure-Python implementation of the interface, suitable for application testing but too slow for real use. I tried rather hard to design a convenient and general interface that I feel was an improvement over PEP 272. I don't know if anyone except me is using it, but several people including Andrew (author of PEP 272) have written favorably about it based on reading the specification. The spec was designed from the beginning to fill the needs of the core. If I were writing it as a non-core module I would have included more stuff. 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. That makes no sense; improving the core is a perfectly valid reason to write something. If someone wrote a straightforward patch that made the Python interpreter 3x faster, would you still want to wait a year before thinking about including it? I certainly believe that every contribution needs code review and user testing before entering wide release, but that doesn't seem to be what you're getting at. I fail to see the problem you seem to have with C modules. They are very easy to use if written properly. Well
Re: What's so funny? WAS Re: rotor replacement
Fredrik Lundh [EMAIL PROTECTED] writes:
please answer the question: have you done this? what kind of programs
have you successfully delivered as self-contained apps for use on arbi-
trary platforms?
Here's a simple one:
import sha
name = raw_input('Enter your name: ')
print 'Your name hashes to:', sha.new(name).hexdigest()
Maybe the sha module isn't in fact available on all platforms, but
it's definitely available on more platforms than I personally have
compilers for. Maybe some more complicated app will hit some
non-sha-related platform dependency and present a porting problem.
But it's worse if it has additional porting problems caused by the sha
module. Making the sha module available on multiple platforms is a
good thing regardless of what the rest of the app does. Doing that
means one less porting problem to worry about. So your question is an
irrelevant misdirection.
Anyway, I've written Python code that that's run under Linux and
Windows and the Macintosh without needing porting. That's not the
same as testing on every platform Python runs on, but if one of those
platforms fails other than from using a builtin module that's
documented as being platform specific, especially if the module is a
pure mathematically-defined algorithm like sha and not an OS-interfacing
module like threading or Tkinter, then I'd say the portability bug is
in Python or its library, not in my app.
--
http://mail.python.org/mailman/listinfo/python-list
Re: simultaneous multiple requests to very simple database
I agree with you, there's a crying need for something like that and there's no single one obvious way to do it answer. Have you looked at bsddb? See also www.sleepycat.com. -- http://mail.python.org/mailman/listinfo/python-list
Re: What's so funny? WAS Re: rotor replacement
James Stroud [EMAIL PROTECTED] writes: Applications that lack features force users to accept a limited feature set or they use an alternative program with other limitations. Putting the possibility for cryptographic storage increases the utility of any application that stores data, and it could be done without much work if it were properly included in the core distribution. I have found it amazing how few programs include encryption as an option. I believe this is because its hard for programmers to include it and/or they falsely reason that if I don't need it, the user doesn't, which is up there with if I can't see them, then they can't see me in terms of bad logic. The likely-best-known Python application in the world (probably more people have heard of it than have heard of Python) originally had crypto (an AES module distributed as a C extension with the beta test versions of the app) but the crypto was brutally ripped out of the application for the final release (you can still see scar tissue in the code where the crypto was, i.e., there's still a function called something like encrypt_packet which no longer actually encrypts the packet). I haven't found out exactly why the crypto was removed so I can't be certain that it's because of cross-platform installation headaches. I do know that its author wanted an AES module in the core to use for that application, in order to not have to distribute a C extension, and he did some of the early work with me on writing such a module to submit for that purpose. The module I ended up proposing is an offshoot of that effort. -- http://mail.python.org/mailman/listinfo/python-list
Re: What's so funny? WAS Re: rotor replacement
[Again I'm having news server trouble and made a previous attempt to post this, so sorry if you see it twice. This version is edited somewhat from the previous.] Martin v. Löwis [EMAIL PROTECTED] writes: This is not possible - whether the module is included in Python or not. People *will* have to download something besides your application, namely Python - and in the version your require, too. If they cannot compile Python themselves, they will have to find somebody who did that for them. Sorry, the presumption is that they already have Python installed. So, if your modules are generally useful, I hope you will try to get them into the core. Right - the critical condition is if the modules are generally useful. I cannot possibly know whether they are generally useful until a general public has commented that they are. There is considerable demand for a crypto module. Note how this thread started: someone who had been using the rotor module complained that it's now missing. Hmm. Most applications don't have any crypto needs. Those that do typically need TLS, or secure password hashing (crypt(3) specifically). So I somehow doubt that an AES module would be generally useful. I believe it's feasible to do TLS in pure Python with acceptable performance, given a DES module and the existing sha module. I think Trevor Perrin has already written something like that. It's feasible because outside of bulk crypto operations using DES and SHA, TLS's execution time is dominated by public-key math calculations, which are acceptably fast using Python's built-in longs. The rest of the stuff like certificate parsing happens just once per session and doing it in Python isn't too awful. On the other hand, it's impossible to do a general purpose TLS stack acceptably without a DES module. According to RFC 2246 sec. 9, supporting TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA is mandatory unless the application profile specifies otherwise. SHA is already in the core and DHE/DSS can be done with Python longs, so DES is the missing critical piece. Also, since DES is in the process of being decertified and AES is its replacement, supporting DES without supporting AES is silly. GnuPG for example uses AES by default, so writing an interoperating Python application (I have some parts of one working) needs AES. If by crypt(3) you mean the old thing of DES with the modified E table, I don't think it's used much any more. I don't see any reason against adding it if people want it, but it's not an encryption function, it's an authentication function, and shouldn't be subject to the legal concerns of a general purpose encryption module. I do think it would be nice to have TLS in the core someday, just like it's already in the Java distro (JSSE). However, that's much more ambitious and anyway it would rely on the block cipher module, so the block cipher module is needed anyway. Meanwhile, a pure-Python TLS implementation outside the core is ok as a workaround. Getting more pure Python modules into the core is in general less valuable than getting more C modules into the core. For an AES module with an interface nobody has ever used but yourself, it would be very difficult to argue that the module is generally useful. Eh? Lots of people have asked for general purpose crypto modules, and the interface follows the approach used by any number of existing libraries. It just does exposes the simplest possible interface to the block cipher and then implements the FIPS operating modes in a natural and obvious way. I've used a number of other such libraries and am pretty familiar with what they need to do. The main thing it tries to do differently from PEP 272 is separate the block ciphers from the FIPS modes, so that each new cipher module doesn't have to implement all the different modes. I hadn't thought there was any controversy over the technical side of this. There's the legal/political issue which I can gently suggest is overblown, but since I'm not the one who would have to take the heat if some government bigwig somewhere flipped their lid over crypto in the Python distro, I don't feel entitled to be very vociferous about this aspect. I'm primarily looking for the user testing. I require that this happens *outside* the Python distribution. Make a distutils package, and report the user feedback. Then propose inclusion into the core. I'm happy to have that kind of testing (and I requested it), given that the goal is inclusion in the core, and the core developers have told me (as they did) that the proposal looks good and they'd like to have the module, so I can reasonably expect it to go into the core if it meets its technical expectations. If the developers instead say (as they seemed to somewhat later) that because of legal/political concerns, there's no way the module can possibly go into the core no matter how good it is technically, then my motivation for writing the module dries up quite a bit.
Re: rotor replacement
Martin v. Lwis [EMAIL PROTECTED] writes: Some countries have laws about cryptography software (against some combination of export, import, or use). The Python maintainers didn't want to deal with imagined legal hassles that might develop from including good crypto functions in the distribution. Then it became obvious that the same imagined hassles could also befall the rotor module, so that was removed. Do you know this for a fact? I'm going by newsgroup messages from around the time that I was proposing to put together a standard block cipher module for Python. The PSF does comply with the U.S. American export procedures for crypto code, and reports the crypto code in Python appropriately to BXA. Since rotor was removed, there is no crypto code in Python that needs reporting. -- http://mail.python.org/mailman/listinfo/python-list
