CWE (Common Weakness Enumeration) has numbers (and URLs) and a graph model, and code examples, and mitigations for bugs, vulnerabilities, faults, design flaws, weaknesses. https://cwe.mitre.org/
Research Concepts https://cwe.mitre.org/data/definitions/1000.html Development Concepts https://cwe.mitre.org/data/definitions/699.html CWE CATEGORY: Time and State https://cwe.mitre.org/data/definitions/361.html CWE CATEGORY: Concurrency Issues https://cwe.mitre.org/data/definitions/557.html 17. Concurrent Execution https://docs.python.org/3/library/concurrency.html > 1. activating threads, tasks or pico-threads https://docs.python.org/3/library/threading.html#threading.Thread.start https://docs.python.org/3/library/threading.html#threading.Thread.run > 2. Directed termination of threads, tasks or pico-threads So, I looked this up: https://stackoverflow.com/questions/323972/is-there-any-way-to-kill-a-thread-in-python Do asynchronous programming patterns actually make this basically never necessary? (asyncio coroutines, greenlet (eventlet, gevent, ), twisted) https://docs.python.org/3/library/asyncio.html https://docs.python.org/3/library/asyncio-task.html If you really feel like you need the overhead of threads instead of or in addition to coroutines (they won't use multiple cores without going to IPC, anyway), you can. > 3. Premature termination of threads, tasks or pico-threads What is this referring to? Does it release handles and locks on exception? (try/finally?) > 4. Concurrent access to data shared between threads, tasks or pico-threads, and CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') https://cwe.mitre.org/data/definitions/362.html CWE-567: Unsynchronized Access to Shared Data in a Multithreaded Context https://cwe.mitre.org/data/definitions/567.html > 5. Lock protocol errors for concurrent entities CWE-667: Improper Locking https://cwe.mitre.org/data/definitions/667.html CWE-366: Race Condition within a Thread https://cwe.mitre.org/data/definitions/366.html The ``mutex`` module is removed in Python 3: https://docs.python.org/2/library/mutex.html 17.1. threading — Thread-based parallelism https://docs.python.org/3/library/threading.html ... Are there other good resources (in addition to Chapter 17) for concurrency in CPython and/or PyPy and/or Stackless Python, MicroPython, IronPython, Jython? - [ ] How do we add Python to the excellent CWE reference? - How can/could/should one add the things with labels (*) from the ISO PDF you speak of to thr CWE graph? (* schema:name, rdfs:label) On Wednesday, November 15, 2017, Guido van Rossum <gu...@python.org> wrote: > On Wed, Nov 15, 2017 at 6:50 PM, Guido van Rossum <gu...@python.org > <javascript:_e(%7B%7D,'cvml','gu...@python.org');>> wrote: > >> On Wed, Nov 15, 2017 at 6:37 PM, Armin Rigo <armin.r...@gmail.com >> <javascript:_e(%7B%7D,'cvml','armin.r...@gmail.com');>> wrote: >> >>> Hi, >>> >>> On 14 November 2017 at 14:55, Jan Claeys <li...@janc.be >>> <javascript:_e(%7B%7D,'cvml','li...@janc.be');>> wrote: >>> > Sounds like https://www.iso.org/standard/71094.html >>> > which is updating https://www.iso.org/standard/61457.html >>> > (which you can download from there if you search a bit; clearly either >>> > ISO doesn't have a UI/UX "standard" or they aren't following it...) >>> >>> Just for completeness, I think that what you can download for free >>> from that second page only contains the first few sections ("Terms and >>> definitions"). It doesn't even go to "Purpose of this technical >>> report"---we need to pay $200 just to learn what the purpose is... >>> >>> *Shrug* >>> >> >> Actually it linked to http://standards.iso.org/ittf/ >> PubliclyAvailableStandards/index.html from which I managed to download >> what looks like the complete c061457_ISO_IEC_TR_24772_2013.pdf (336 >> pages) after clicking on an "I accept" button (I didn't read what I >> accepted :-). The $200 is for the printed copy I presume. >> > > So far I learned one thing from the report. They use the term > "vulnerabilities" liberally, defining it essentially as "bug": > > All programming languages contain constructs that are incompletely >> specified, exhibit undefined behaviour, are implementation-dependent, or >> are difficult to use correctly. The use of those constructs may therefore >> give rise to *vulnerabilities*, as a result of which, software programs >> can execute differently than intended by the writer. >> > > They then go on to explain that sometimes vulnerabilities can be > exploited, but I object to calling all bugs vulnerabilities -- that's just > using a scary word to get attention for a sleep-inducing document > containing such gems as "Use floating-point arithmetic only when absolutely > needed" (page 230). > > -- > --Guido van Rossum (python.org/~guido) >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
