Re: Who should security issues be reported to?
Paul Rubin wrote: Fuzzyman [EMAIL PROTECTED] writes: The sourceforge bug tracker *is* the single right place to post such issues. The py-dev mailing list would be a second *useful* place to post such a comment, although not really the right place. The OP seemed to want an individual with whom he could have a private conversation about it. I think he wanted a place to send a bug report that wouldn't be exposed to public view until the developers had a chance to issue a patch. With bugzilla, for example, you can check a bug labelled this is a security bug, keep it confidential. There's lots of dilemmas and some controversy about keeping any bug reports confidential in an open source system. But the general strategy selected by Mozilla after much debate seems to mostly work ok. It basically says develop a patch quickly, keep the bug confidential while the patch is being developed, and once the patch is available, notify distro maintainers to install it, and then after a short delay (like a couple days), publish the bug. Note that anyone with access to the bug (that includes the reporter and selected developers) can uncheck the box at any time, if they think the bug no longer needs to be confidential. The bug then becomes visible to the public. Sounds like a useful feature request to Sourceforge. Regards, Fuzzy http://www.voidspace.org.uk/python/index.shtml -- http://mail.python.org/mailman/listinfo/python-list
Re: Who should security issues be reported to?
Paul Rubin wrote: More significantly, any security problem is likely to be with a specific function or object that has been implemented in C. False; the Cookie module example we talked about was caused by an unforeseen interaction between pure Python modules (Cookie and pickle). Fair cop on the C thing, but that example otherwise illustrates my point perfectly. Unpickling untrusted data is just as dangerous as evaluating or executing untrusted data. This is *still* dangerous, because there *is no patch* to fix the problem. There are only documentation changes to highlight the security risks associated with unpickling, and Deprecation Warnings on the Cookie classes which use this unsafe feature. So, the only effective mechanism is to get the word out to Python *users* that the feature is unsafe, and should be used with care, which basically requires telling the world about the problem. Any time Python has a problem of this sort, there is going to be at least one solution, and only possibly two: 1. Avoid the feature that represents a security risk 2. Eliminate the security risk in a maintenance update. The first solution applies regardless of whether the security risk is inherent in Python's design or not. Some obvious examples (given above) relate to execution of untrusted code. The second solution applies only to bugs in the CPython implementation and extension modules. And often, tweaking the application's Python code to avoid the dangerous features is going to be faster (and safer) than changing over to a new Python version. By keeping the process public, and clearly identifying the problematic features, application developers can immediately start working on protecting themselves, in parallel with the CPython developers (possibly) working on a new maintenance release. To go with the 72 hours + 8 example you gave - what if you could work around the broken feature in 6? I suspect we'll have to agree to disagree on this point. Where we can agree is that I certainly wouldn't be unhappy if SF had a feature like Bugzilla's security flag. Regards, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- http://mail.python.org/mailman/listinfo/python-list
Re: Who should security issues be reported to?
Nick Coghlan [EMAIL PROTECTED] writes: Fair cop on the C thing, but that example otherwise illustrates my point perfectly. I'm not sure what point you mean. Unpickling untrusted data is just as dangerous as evaluating or executing untrusted data. This is *still* dangerous, because there *is no patch* to fix the problem. Pickle is now documented as being unsafe for untrusted data. It's just like eval now. Nobody is going to make a patch for eval that makes it safe for untrusted data. It would be nice if there were a pickle alternative that's safe to use with untrusted data, but that's sort of a separate issue (see the marshal doc thread referenced earlier). There are only documentation changes to highlight the security risks associated with unpickling, and I would say that unpickle's feature set actually changed incompatibly, since (see analysis in the sf bug thread) unpickle was originally designed to be safe. Deprecation Warnings on the Cookie classes which use this unsafe feature. Yes, that means as soon as someone uses Cookie.Cookie, their application will throw a DeprecationWarning and they have to fix the error before the app can run. So, the only effective mechanism is to get the word out to Python *users* that the feature is unsafe, and should be used with care, which basically requires telling the world about the problem. That's true, but the problem still has to be analyzed and a recommendation formulated, which can take a little while. Any time Python has a problem of this sort, there is going to be at least one solution, and only possibly two: 1. Avoid the feature that represents a security risk 2. Eliminate the security risk in a maintenance update. You forgot 3. install a patch as soon as you become aware of the problem, without waiting for a maintenance update. By keeping the process public, and clearly identifying the problematic features, application developers can immediately start working on protecting themselves, in parallel with the CPython developers (possibly) working on a new maintenance release. The hope is that during the short period in which there's a confidential bug report in the system, the number of exploits in the wild won't change. Either attackers knew about the bug already and have exploits out before the bug is even reported, or they don't know about it yet. Either way, random application developers get the bug report at the same time as attackers. So the choices are that app developers get a raw bug report and have to figure out a solution while at the same time attackers who saw the same announcement are starting to launch new exploits, or else when the app developers get the bug report, they also get a bunch of analysis from the Python developers, which can help them decide what to do next. I think they benefit from the analysis, if they can get it. Keep in mind also that the submitters of the bug reports often don't see the full implications, that the app developers also might not see, but that attackers are likely to figure out instantly. So again, it helps if the Python developers can supply some analysis of their own. Finally, some reports of security bugs turn out to not really be bugs (I've submitted a few myself that have turned out that way). That kind of thing can panic an application developer into shutting down a service unnecessarily while figuring out what to do next, often at a cost of kilobucks or worse per minute of downtime, or maybe having some lesser fire drill to figure out that the problem is a non-problem. Better to let the Python developers explain the problem and close the bug before publishing it. To go with the 72 hours + 8 example you gave - what if you could work around the broken feature in 6? If 6 hours from seeing the raw bug report are enough to analyze the problem and develop a workaround, then given not only the raw bug report but also 72 hours worth of analysis and recommendations/fixes from the developers, I should need even less than 6 hours to install a patch. I suspect we'll have to agree to disagree on this point. Where we can agree is that I certainly wouldn't be unhappy if SF had a feature like Bugzilla's security flag. I do have to say that developer responsiveness to security issues varies from one program to another. It's excellent for OpenBSD and reasonably good for Mozilla; but for Python, it's something of a weak spot, as we're seeing. -- http://mail.python.org/mailman/listinfo/python-list
Re: Who should security issues be reported to?
Nick Upgrading your Python interpreter (even to a new maintenance Nick branch release) in a production environment is usually a fairly Nick involved exercise requiring a significant amount of testing, and Nick the fact of the matter is, you're unlikely to do so unless there Nick is some feature or bug-fix in a new version that you really Nick need. (I'm still using Python 2.2.2 at work - it's entirely Nick adequate for our needs, so there's no real pressure to upgrade on Nick the current project. For a new project, I'd probably start with Nick 2.4, planning to go to 2.4.1 in a couple of months time, but there Nick aren't really any post-2.2 additions to Python that I can't handle Nick living without). Still, if a security bug was serious enough, my guess is that someone would step up to supply patches (or Windows installers) for any of a number of versions that were affected by the bug, even 2.1 or 1.5.2. That someone might or might not be part of the core development team. That nothing like that has been done before doesn't preclude it being done in the future. Skip -- http://mail.python.org/mailman/listinfo/python-list
Re: Who should security issues be reported to?
In article [EMAIL PROTECTED], Skip Montanaro [EMAIL PROTECTED] wrote: Nick Upgrading your Python interpreter (even to a new maintenance Nick branch release) in a production environment is usually a fairly Nick involved exercise requiring a significant amount of testing, and Nick the fact of the matter is, you're unlikely to do so unless there Nick is some feature or bug-fix in a new version that you really Nick need. (I'm still using Python 2.2.2 at work - it's entirely Nick adequate for our needs, so there's no real pressure to upgrade on Nick the current project. For a new project, I'd probably start with Nick 2.4, planning to go to 2.4.1 in a couple of months time, but there Nick aren't really any post-2.2 additions to Python that I can't handle Nick living without). Still, if a security bug was serious enough, my guess is that someone would step up to supply patches (or Windows installers) for any of a number of versions that were affected by the bug, even 2.1 or 1.5.2. That someone might or might not be part of the core development team. That nothing like that has been done before doesn't preclude it being done in the future. While true, such coordination also requires public discussion, given the way the Python community works. Which obviates the OPs request for private correspondence. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ 19. A language that doesn't affect the way you think about programming, is not worth knowing. --Alan Perlis -- http://mail.python.org/mailman/listinfo/python-list
Re: Who should security issues be reported to?
Aahz wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Who are the appropriate people to report security problems to in respect of a module included with the Python distribution? I don't feel it appropriate to be reporting it on general mailing lists. There is no generally appropriate non-public mechanism for reporting security issues. If you really think this needs to be handled privately, do some research to find out which core developer is most likely to be familiar with it. Even before you do that, check SourceForge to find out whether anyone else has reported it as a bug. I find this response a bit dissappointing frankly. Open Source people make such a big deal about having lots of people being able to look at source code and from that discover security problems, thus making it somehow making it better than proprietary source code. From what I can see, if an Open Source project is quite large with lots of people involved, it makes it very hard to try and identify who you should report something to when there is no clearly identifiable single point of contact for security related issues. Why should I have to go through hoops to try and track down who is appropriate to send it to? All you need is a single advertised email address for security issues which is forwarded onto a small group of developers who can then evaluate the issue and forward it on to the appropriate person. Such developers could probably do such evaluation in minutes, yet I have to spend a lot longer trying to research who to send it to and then potentially wait days for some obscure person mentioned in the source code who has not touched it in years to respond, if at all. Meanwhile you have a potentially severe security hole sitting there wating for someone to expliot, with the only saving grace being the low relative numbers of users who may be using it in the insecure manner and that it would be hard to identify the actual web sites which suffer the problem. I'm sorry, but this isn't really good enough. If Open Source wants to say that they are better than these proprietary companies, they need to deal with these sorts of things more professionally and establish decent channels of communications for dealing with it. And yes I have tried mailing the only people mentioned in the module in question and am still waiting for a response. -- http://mail.python.org/mailman/listinfo/python-list
Re: Who should security issues be reported to?
[EMAIL PROTECTED] wrote: I'm sorry, but this isn't really good enough. If Open Source wants to say that they are better than these proprietary companies, they need to deal with these sorts of things more professionally and establish decent channels of communications for dealing with it. 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? Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- 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: Who should security issues be reported to?
Nick Coghlan wrote: I'm sorry, but this isn't really good enough. If Open Source wants to say that they are better than these proprietary companies, they need to deal with these sorts of things more professionally and establish decent channels of communications for dealing with it. 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? oh, please. this is a security issue. it needs a little more coordination than an ordinary bug report. /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Who should security issues be reported to?
[EMAIL PROTECTED] wrote: I find this response a bit dissappointing frankly. Open Source people make such a big deal about having lots of people being able to look at source code and from that discover security problems, thus making it somehow making it better than proprietary source code. I think part of the problem you are having is that Python doesn't make any representations about security, so it is pretty hard to come up with issues which really are security related. Products which are based on Python (e.g. Zope) and which do aim to provide some kind of secure environment probably will have some clear mechanism for reporting security related issues. The only part of Python which used to claim to offer security was rexec and the bastion module, but they had so many security issues that they were removed from the distribution. In other words, I'm intrigued how you managed to come up with something you consider to be a security issue with Python since Python offers no security. Perhaps, without revealing the actual issue in question, you could give an example of some other situation which, if it came up in Python you would consider to be a security issue? -- http://mail.python.org/mailman/listinfo/python-list
Re: Who should security issues be reported to?
Duncan Booth [EMAIL PROTECTED] writes: In other words, I'm intrigued how you managed to come up with something you consider to be a security issue with Python since Python offers no security. Perhaps, without revealing the actual issue in question, you could give an example of some other situation which, if it came up in Python you would consider to be a security issue? Until fairly recently, the pickle module was insufficiently documented as being unsafe to use with hostile data, so people used it that way. As a result, the Cookie module's default settings allowed remote attackers to take over Python web apps. See SF bug 467384. -- http://mail.python.org/mailman/listinfo/python-list
Re: Who should security issues be reported to?
[Duncan] I'm intrigued how you managed to come up with something you consider to be a security issue with Python since Python offers no security. Perhaps, without revealing the actual issue in question, you could give an example of some other situation which, if it came up in Python you would consider to be a security issue? I can't speak for the OP, but one hypothetical example might be a buffer overrun vulnerability in the socket module. -- Richie Hindle [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Who should security issues be reported to?
Duncan Booth wrote: I think part of the problem you are having is that Python doesn't make any representations about security, so it is pretty hard to come up with issues which really are security related. Products which are based on Python (e.g. Zope) and which do aim to provide some kind of secure environment probably will have some clear mechanism for reporting security related issues. security issues occur when code that claims to do something can be used to do something entirely different, by malevolent application users. (wxPython doesn't make any security claims either, but if it turned out that you could gain root access, modify the underlying database, modify variables in the program, execute arbitrary code, or some other similar thing simply by typing the right things into a password entry field, wouldn't you consider that a security issue?) (no, this issue isn't related to wxPython) /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Who should security issues be reported to?
Paul Rubin wrote: Duncan Booth [EMAIL PROTECTED] writes: In other words, I'm intrigued how you managed to come up with something you consider to be a security issue with Python since Python offers no security. Perhaps, without revealing the actual issue in question, you could give an example of some other situation which, if it came up in Python you would consider to be a security issue? Until fairly recently, the pickle module was insufficiently documented as being unsafe to use with hostile data, so people used it that way. As a result, the Cookie module's default settings allowed remote attackers to take over Python web apps. See SF bug 467384. SF doesn't seem to know about any such bug any more. Google finds me http://mail.python.org/pipermail/python-bugs-list/2001-October/007669.html which appears to be SF bug 467384, but it says nothing about security or the Cookie module, just that you wanted better documentation. I think its a bit borderline whether this really was a security bug in Python rather than just a problem with the way some people used Python. It was a standard library which if used in the wrong way opens a security hole on your machine, but there are plenty of ways to open security holes. The response seems to have been to document that there is a security concern here, but it is still just as possible to use python to expose your machine to attack as it was before. But thanks anyway, it does give me the sort of example I was asking for. -- http://mail.python.org/mailman/listinfo/python-list
Re: Who should security issues be reported to?
Duncan Booth [EMAIL PROTECTED] writes: SF doesn't seem to know about any such bug any more. Google finds me http://mail.python.org/pipermail/python-bugs-list/2001-October/007669.html which appears to be SF bug 467384, but it says nothing about security or the Cookie module, just that you wanted better documentation. The Cookie issue is discussed some in that bug thread. But more relevant is bug 471893. Sorry. I think its a bit borderline whether this really was a security bug in Python rather than just a problem with the way some people used Python. If using a module the way it's documented results in a security hole, that's definitely a security bug. If using the module in an obvious and natural way that looks correct results in a security hole, I'd say it's at least an issue needing attention, even if some sufficiently hairsplitting reading of the documentation says that usage is incorrect. Principle of least astonishment. I highly recommend reading the book Security Engineering by Ross Anderson if you're trying to implement anything that might ever be exposed to malicious parties. That includes any application that communicates over the internet (such as web servers or clients), and it includes any application that processes data downloaded from the internet (such as jpeg viewers). Each of those classes of programs has had examples of where hostile data could take over the application. -- http://mail.python.org/mailman/listinfo/python-list
Re: Who should security issues be reported to?
[EMAIL PROTECTED] wrote: Aahz wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Who are the appropriate people to report security problems to in respect of a module included with the Python distribution? I don't feel it appropriate to be reporting it on general mailing lists. There is no generally appropriate non-public mechanism for reporting security issues. If you really think this needs to be handled privately, do some research to find out which core developer is most likely to be familiar with it. Even before you do that, check SourceForge to find out whether anyone else has reported it as a bug. I find this response a bit dissappointing frankly. Open Source people make such a big deal about having lots of people being able to look at source code and from that discover security problems, thus making it somehow making it better than proprietary source code. From what I can see, if an Open Source project is quite large with lots of people involved, it makes it very hard to try and identify who you should report something to when there is no clearly identifiable single point of contact for security related The sourceforge bug tracker *is* the single right place to post such issues. The py-dev mailing list would be a second *useful* place to post such a comment, although not really the right place. The OP seemed to want an individual with whom he could have a private conversation about it. Regards, Fuzzy http://www.voidspace.org.uk/python/index.shtml issues. Why should I have to go through hoops to try and track down who is appropriate to send it to? All you need is a single advertised email address for security issues which is forwarded onto a small group of developers who can then evaluate the issue and forward it on to the appropriate person. Such developers could probably do such evaluation in minutes, yet I have to spend a lot longer trying to research who to send it to and then potentially wait days for some obscure person mentioned in the source code who has not touched it in years to respond, if at all. Meanwhile you have a potentially severe security hole sitting there wating for someone to expliot, with the only saving grace being the low relative numbers of users who may be using it in the insecure manner and that it would be hard to identify the actual web sites which suffer the problem. I'm sorry, but this isn't really good enough. If Open Source wants to say that they are better than these proprietary companies, they need to deal with these sorts of things more professionally and establish decent channels of communications for dealing with it. And yes I have tried mailing the only people mentioned in the module in question and am still waiting for a response. -- http://mail.python.org/mailman/listinfo/python-list
Re: Who should security issues be reported to?
Fuzzyman [EMAIL PROTECTED] writes: The sourceforge bug tracker *is* the single right place to post such issues. The py-dev mailing list would be a second *useful* place to post such a comment, although not really the right place. The OP seemed to want an individual with whom he could have a private conversation about it. I think he wanted a place to send a bug report that wouldn't be exposed to public view until the developers had a chance to issue a patch. With bugzilla, for example, you can check a bug labelled this is a security bug, keep it confidential. There's lots of dilemmas and some controversy about keeping any bug reports confidential in an open source system. But the general strategy selected by Mozilla after much debate seems to mostly work ok. It basically says develop a patch quickly, keep the bug confidential while the patch is being developed, and once the patch is available, notify distro maintainers to install it, and then after a short delay (like a couple days), publish the bug. Note that anyone with access to the bug (that includes the reporter and selected developers) can uncheck the box at any time, if they think the bug no longer needs to be confidential. The bug then becomes visible to the public. -- http://mail.python.org/mailman/listinfo/python-list
Re: Who should security issues be reported to?
Duncan Booth wrote: I think its a bit borderline whether this really was a security bug in Python rather than just a problem with the way some people used Python. It was a standard library which if used in the wrong way opens a security hole on your machine for SmartCookie, that should be if used, opens a security hole /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Who should security issues be reported to?
In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Aahz wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Who are the appropriate people to report security problems to in respect of a module included with the Python distribution? I don't feel it appropriate to be reporting it on general mailing lists. There is no generally appropriate non-public mechanism for reporting security issues. If you really think this needs to be handled privately, do some research to find out which core developer is most likely to be familiar with it. Even before you do that, check SourceForge to find out whether anyone else has reported it as a bug. I find this response a bit dissappointing frankly. Open Source people make such a big deal about having lots of people being able to look at source code and from that discover security problems, thus making it somehow making it better than proprietary source code. That's generally true, but not universally. The key point you seem to have missed in my response is non-public mechanism. Historically, Python security issues have been thrashed out in public; the Python project does not have a release cycle that makes it possible to quickly address security concerns, so keeping it private has little point. Your decision to take the private route makes it your responsibility to search for an appropriate mechanism. I'm sorry, but this isn't really good enough. If Open Source wants to say that they are better than these proprietary companies, they need to deal with these sorts of things more professionally and establish decent channels of communications for dealing with it. As other people said, sounds like you want to volunteer for this. Which would be fine -- but there's still not much point until/unless we get enough volunteers to manage quicker release cycles. Then there's still the problem of getting people to update their local copies of Python. This is a complex issue. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ 19. A language that doesn't affect the way you think about programming, is not worth knowing. --Alan Perlis -- http://mail.python.org/mailman/listinfo/python-list
Re: Who should security issues be reported to?
[EMAIL PROTECTED] Who are the appropriate people to report security problems to in respect of a module included with the Python distribution? I don't feel it appropriate to be reporting it on general mailing lists. The Python project has no non-public resources for this. Filing a bug report on SourceForge is the usual approach. If you must, you could send email directly to Guido mailto:[EMAIL PROTECTED]. He may or may not have time to follow up on it; public disclosure is the norm in this project. Be forewarned that despite that he currently works for a security startup, his threshold for security panic is very high. -- http://mail.python.org/mailman/listinfo/python-list
Re: Who should security issues be reported to?
In article [EMAIL PROTECTED], Tim Peters [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] Who are the appropriate people to report security problems to in respect of a module included with the Python distribution? I don't feel it appropriate to be reporting it on general mailing lists. The Python project has no non-public resources for this. Filing a bug report on SourceForge is the usual approach. If you must, you could send email directly to Guido mailto:[EMAIL PROTECTED]. He may or may not have time to follow up on it; public disclosure is the norm in this project. Be forewarned that despite that he currently works for a security startup, his threshold for security panic is very high. You mean s/despite/because/ don't you? ;-) -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ 19. A language that doesn't affect the way you think about programming, is not worth knowing. --Alan Perlis -- http://mail.python.org/mailman/listinfo/python-list
Re: Who should security issues be reported to?
OP: I find this response a bit dissappointing frankly. Open Source people make such a big deal about having lots of people being able to look at source code and from that discover security problems, thus making it somehow making it better than proprietary source code. OP: Did you discover this supposed security hole from black-box observation of behavior or by being one of the 'lots of people being able to look at source code', thereby giving evidence to the point? Everyone: I say 'supposed' because a) The OP has provided no info about his/her claim. b) The OP's original post is a classical troll: blast volunteer developers for not having anticipated and planned for a novel situation; argue against things not said, at least now here, not recently; imply that volunteers own him something. Most people with the expertise to detect a security hole would know better. c) The noise generated because of b) has alerted any malware writers monitering c.l.p for hints about exploitable security holes that there might be one in one of the few modules where such could reasonably be. OP: If my doubts are wrong and you really do have something to quietly report to the 'authority', then do so, and quit making a noise about it. Terry J. Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Who should security issues be reported to?
Fredrik Lundh wrote: Nick Coghlan wrote: I'm sorry, but this isn't really good enough. If Open Source wants to say that they are better than these proprietary companies, they need to deal with these sorts of things more professionally and establish decent channels of communications for dealing with it. 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? oh, please. this is a security issue. it needs a little more coordination than an ordinary bug report. /F Well, a less facetious answer to the OP's question would be Anthony Baxter. As the current release manager, he's the best contact point I can think of. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- http://mail.python.org/mailman/listinfo/python-list
Re: Who should security issues be reported to?
OP: Did you discover this supposed security hole from black-box observation of behavior or by being one of the 'lots of people being able to look at source code', thereby giving evidence to the point? The technique used which is the source of the problem was actually first discovered in a separate package to the Python distribution, but it was known that the same technique was used in a module within the Python distribution. It is quite possible that other third party packages might use it as well, although a few of the main stream packages have been checked and they don't use exactly the same technique so are okay. I could have just ignored the fact that the Python distribution had the problem and worried about the other package only. a) The OP has provided no info about his/her claim. Since the problem at least affects two packages and because of the potential for mischief, I am hardly about to identify the packages concerned, nor describe anything that is going to allow people to work out what the issue is. b) The OP's original post is a classical troll: blast volunteer developers for not having anticipated and planned for a novel situation; argue against things not said, at least now here, not recently; imply that volunteers own him something. Most people with the expertise to detect a security hole would know better. And the reaction is what I have more and more been seeing in Open Source circles. That, is either treat posters like ignoreant newbies who know no better, or assume they are a trolls trying to discredit Open Source. Quite sad really, one tries to do the right thing and gets abused for it. It doesn't matter if a large project may be perceived as being mostly immune to security problems, one could still occur and if it isn't simple to raise such an issue I am sure than some people wouldn't even bother. c) The noise generated because of b) has alerted any malware writers monitering c.l.p for hints about exploitable security holes that there might be one in one of the few modules where such could reasonably be. With approx 200+ modules in the Python distribution I can hardly see how this helps. If I had done what you had wanted in (a) and gave actual information about the problem I would have been narrowing down the problem to less than a dozen modules. You can't have it both ways. OP: If my doubts are wrong and you really do have something to quietly report to the 'authority', then do so, and quit making a noise about it. And so it is was and knowledgeable people are looking at the issue. It should not though have necessitated me making a noise in order to find someone to deal with it in a timely manner. When a proprietary company doesn't have an easy way of reporting problems or seems not to care too much, Open Source people are on top of them like wolves. Why can't Open Source people hold themselves to the same standard. Not sure why I have even bothered to respond to you as it is probably just the sort of attention you want. You even appear to have some history of taking issue with people, even though in one of your own posts you state: Responding to trollish postings. (Jan 26) My personal strategy is to read only as much of trollish threads as I find interesting or somehow instructive, almost never respond, and then ignore the rest. I also mostly ignore discussions about such threads. Terry J. Reedy Maybe you should simply have not responded. Lets see if you now ignore the followup discussion. :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Who should security issues be reported to?
[EMAIL PROTECTED] wrote: Who are the appropriate people to report security problems to in respect of a module included with the Python distribution? I don't feel it appropriate to be reporting it on general mailing lists. After my original flippant reply, I've been thinking some more about this, and whether CPython can really benefit from initial notification of a security flaw going privately to the developers first. And, due to CPython's release model, I really don't think it can. Upgrading your Python interpreter (even to a new maintenance branch release) in a production environment is usually a fairly involved exercise requiring a significant amount of testing, and the fact of the matter is, you're unlikely to do so unless there is some feature or bug-fix in a new version that you really need. (I'm still using Python 2.2.2 at work - it's entirely adequate for our needs, so there's no real pressure to upgrade on the current project. For a new project, I'd probably start with 2.4, planning to go to 2.4.1 in a couple of months time, but there aren't really any post-2.2 additions to Python that I can't handle living without). So, for CPython, the window of vulnerability is driven mainly by the time to when application developers, system administrators and end users get around to upgrading, not by the time to when a patched version is released. In that sort of environment, even if the developers were to release a new maintenance patch within an hour of being notified of the problem, the window of vulnerability is still going to be huge (there are still systems out there running Python *1.5*, fer cryin' out loud). More significantly, any security problem is likely to be with a specific function or object that has been implemented in C. This means any such security problem can be worked around by not using the affected feature, by employing appropriate safeguards against abuse, or by substituting a Python equivalent. This is something which is going to be application dependent, and relies on application developers being notified. So the most appropriate response to security issues in the CPython interpreter and standard library is to notify application developers as to what the issue is, and exactly which features it affects. Sending a private notification to the *interpreter* developers does nothing to assist in this. In accordance with the above, I would suggest that, even for security problems, Python's standard Sourceforge bug tracker is the most appropriate place to file the problem report. If the problem is significant, then it should also be brought directly to the attention of python-dev. At that point, the decision may be made to make a general announcement as to the feature which needs to be avoided or handled carefully. This would likely take the form of announcements on the www.python.org website, and on comp.lang.python.announce. Regards, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- http://mail.python.org/mailman/listinfo/python-list
Re: Who should security issues be reported to?
Nick Coghlan [EMAIL PROTECTED] writes: After my original flippant reply, I've been thinking some more about this, and whether CPython can really benefit from initial notification of a security flaw going privately to the developers first. And, due to CPython's release model, I really don't think it can. Upgrading your Python interpreter (even to a new maintenance branch release) in a production environment is usually a fairly involved exercise requiring a significant amount of testing, and the fact of That's true of any production environment, and yet if there's a serious flaw, you absolutely have to do it. So, for CPython, the window of vulnerability is driven mainly by the time to when application developers, system administrators and end users get around to upgrading, not by the time to when a patched version is released. No. If you're running a production system you have to stay on top of security patches and install them ASAP. If a vulnerability is bad enough, you have to close down your service until you're done installing the fix. If it takes 72 hours for the developers to make a patch, and 8 hours for you to install the patch once it's announced, then your exposure to attackers who learn of the bug from the announcement is 10 times smaller if the bug and patch are announced simultaneously than if the bug is announced immediately and the patch is released 72 hours later. More significantly, any security problem is likely to be with a specific function or object that has been implemented in C. False; the Cookie module example we talked about was caused by an unforeseen interaction between pure Python modules (Cookie and pickle). So the most appropriate response to security issues in the CPython interpreter and standard library is to notify application developers as to what the issue is, and exactly which features it affects. It helps a lot if when the application developers are notified, a patch is already available, since once there's a lot of notification, the bug is public. Sending a private notification to the *interpreter* developers does nothing to assist in this. Um, it lets them get a patch ready before they notify the app developers. If the problem is significant, then it should also be brought directly to the attention of python-dev. It's a sure bet that attackers are monitoring python-dev and one should generally assume that they're monitoring the email of any developer for projects with serious security footprints. Notifying python-dev isn't much different than broadcasting the info on Attack TV. Security bug reports should be made through SSL-encrypted web pages, not unencrypted email. Bugzilla already has this feature. I think it should also be added to Sourceforge, if it's not already there. If it's available in Sourceforge, then Python's Sourceforge project should enable it. Meanwhile, the OP can always open a CERT notification (www.cert.org), though it usually takes a very long time for anything to happen with those. -- http://mail.python.org/mailman/listinfo/python-list
Who should security issues be reported to?
Who are the appropriate people to report security problems to in respect of a module included with the Python distribution? I don't feel it appropriate to be reporting it on general mailing lists. -- http://mail.python.org/mailman/listinfo/python-list
Re: Who should security issues be reported to?
In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Who are the appropriate people to report security problems to in respect of a module included with the Python distribution? I don't feel it appropriate to be reporting it on general mailing lists. There is no generally appropriate non-public mechanism for reporting security issues. If you really think this needs to be handled privately, do some research to find out which core developer is most likely to be familiar with it. Even before you do that, check SourceForge to find out whether anyone else has reported it as a bug. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ 19. A language that doesn't affect the way you think about programming, is not worth knowing. --Alan Perlis -- http://mail.python.org/mailman/listinfo/python-list
