[Python-Dev] Restricted Entry Point from PEP-551/578
I sent in a couple of PRs, accepted and merged (Thanks!), lately that switch to using io.open_code when appropriate. In the process of making those PRs I spent a bit of time reading the two related PEPs. In PEP-551 there's a suggestion that people use a restricted entry point in production environments. I googled around a bit and couldn't find any evidence that there was an existing implementation, at least not made public, that people were using in a general sense. So I created a branch from my fork and over the last few days have implemented part of what's suggested in PEP-551. Specifically my changes remove most of the command line options, ignore envvars (except for a possible logging filename for the audit hooks), and registers an audit hook that logs everything to the defined envvar when provided or stderr if not. Now the questions: 1) Does anybody care? Is anyone currently doing this or planning on doing this? 2) Do we want to provide an "official" version of a restricted entry point that could be used as-is or easily modified per specific needs? Seems kinda silly to make everyone roll their own version but I'm happy to yield to the will of the people. 3) What's the chance we wanna merge something like this into the official master branch? I accomplished what I wanted to do using a few #ifdef's and some funky makefile magic. I think it would merge easily. Maintaining a fork sounds like a lot of work to me. And here's the code: I'm very open to suggestions. I basically have no idea what I'm doing. I haven't touched C in about 7 years so don't expect the Mona Lisa. https://github.com/python/cpython/compare/master...jsnklln:PEP551_restricted_entry_point -- Jason Killen jsnk...@gmail.com Pain is inevitable, misery is optional. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/KYEKDEGSI5B7BSY7XCJ36TE6XCBM2GML/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Restricted Entry Point from PEP-551/578
On 21Nov2019 0927, Jason Killen wrote: I sent in a couple of PRs, accepted and merged (Thanks!), lately that switch to using io.open_code when appropriate. In the process of making those PRs I spent a bit of time reading the two related PEPs. In PEP-551 there's a suggestion that people use a restricted entry point in production environments. I googled around a bit and couldn't find any evidence that there was an existing implementation, at least not made public, that people were using in a general sense. So I created a branch from my fork and over the last few days have implemented part of what's suggested in PEP-551. Specifically my changes remove most of the command line options, ignore envvars (except for a possible logging filename for the audit hooks), and registers an audit hook that logs everything to the defined envvar when provided or stderr if not. Hi Jason. Great to see that you're interested! Right now there isn't an existing implementation, mainly because the value is very limited unless you also integrate into other system security services. Since CPython runs on so many platforms, there was no way for us to support all the possible combinations upstream, so instead we made it easy to extend so that distributors can customise it for their own platform (including sysadmins who want to customise for their own internal setups). You can watch the presentations I gave on this recently (top few links at https://stevedower.id.au/speaking), or read my whitepaper at https://aka.ms/sys.audit (which will be rolled into PEP 551 soon). I have also some samples at https://github.com/zooba/spython (that are shown and discussed in the whitepaper). Now the questions: 1) Does anybody care? Is anyone currently doing this or planning on doing this? Yes, quite a few people care. It's mostly being discussed with me on backchannels right now though, and I haven't even connected everyone together yet. If you're interested, I'll include you when I do? 2) Do we want to provide an "official" version of a restricted entry point that could be used as-is or easily modified per specific needs? Seems kinda silly to make everyone roll their own version but I'm happy to yield to the will of the people. As I said above, an "official" one can only go so far. I'd prefer to see the Linux distros have their own official one (e.g. if I'm on RHEL then I use Red Hat's restricted entry point, etc.) 3) What's the chance we wanna merge something like this into the official master branch? I accomplished what I wanted to do using a few #ifdef's and some funky makefile magic. I think it would merge easily. Maintaining a fork sounds like a lot of work to me. The fork is very minimal now that the hooks are available in core. I've been involved in maintaining a true fork (based on 3.6 without the hooks) and *that* is a lot of work, but now that it can all be done from the entry-point it's actually pretty simple. And here's the code: I'm very open to suggestions. I basically have no idea what I'm doing. I haven't touched C in about 7 years so don't expect the Mona Lisa. https://github.com/python/cpython/compare/master...jsnklln:PEP551_restricted_entry_point I think this looks almost exactly like what we would merge if we were going to merge anything. My concern is that I think if we offer anything at all it will discourage people/distros from actually implementing it properly for their context, and so we make things worse. Making it easy to extend without actually doing it seems like a better place to be. And I'm totally in favour of publishing ready-to-build samples (again, see https://github.com/zooba/spython). I just don't want people to think we've "solved" security for them, when there's honestly no way for us to do it from here. Cheers, Steve ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/QRIZNJTTL54DE3CYUIGTOHWO2SPBHOJW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Restricted Entry Point from PEP-551/578
Thanks. Yea if you bring all the backchannels together at some point I would like to be included mostly as a listener. I totally agree about not wanting people to think we've "solved" security. I expected that might be the reason this hadn't been done. On the other hand I think some sort of starting point or examples are very useful so we don't all reinvent the wheel. Your spython branch seems to be what I was looking for but couldn't find. I'm gonna clone it and poke around a bit. How can we make your fork easier to find? Googling for spython doesn't even get you in the right neighborhood. Can we include a link in the PEP? On Thu, Nov 21, 2019 at 1:09 PM Steve Dower wrote: > On 21Nov2019 0927, Jason Killen wrote: > > I sent in a couple of PRs, accepted and merged (Thanks!), lately that > > switch to using io.open_code when appropriate. In the process of making > > those PRs I spent a bit of time reading the two related PEPs. In > > PEP-551 there's a suggestion that people use a restricted entry point in > > production environments. I googled around a bit and couldn't find any > > evidence that there was an existing implementation, at least not made > > public, that people were using in a general sense. So I created a > > branch from my fork and over the last few days have implemented part of > > what's suggested in PEP-551. Specifically my changes remove most of the > > command line options, ignore envvars (except for a possible logging > > filename for the audit hooks), and registers an audit hook that logs > > everything to the defined envvar when provided or stderr if not. > > Hi Jason. Great to see that you're interested! > > Right now there isn't an existing implementation, mainly because the > value is very limited unless you also integrate into other system > security services. Since CPython runs on so many platforms, there was no > way for us to support all the possible combinations upstream, so instead > we made it easy to extend so that distributors can customise it for > their own platform (including sysadmins who want to customise for their > own internal setups). > > You can watch the presentations I gave on this recently (top few links > at https://stevedower.id.au/speaking), or read my whitepaper at > https://aka.ms/sys.audit (which will be rolled into PEP 551 soon). > > I have also some samples at https://github.com/zooba/spython (that are > shown and discussed in the whitepaper). > > > Now the questions: > > 1) Does anybody care? Is anyone currently doing this or planning on > > doing this? > > Yes, quite a few people care. It's mostly being discussed with me on > backchannels right now though, and I haven't even connected everyone > together yet. If you're interested, I'll include you when I do? > > > 2) Do we want to provide an "official" version of a restricted entry > > point that could be used as-is or easily modified per specific needs? > > Seems kinda silly to make everyone roll their own version but I'm happy > > to yield to the will of the people. > > As I said above, an "official" one can only go so far. I'd prefer to see > the Linux distros have their own official one (e.g. if I'm on RHEL then > I use Red Hat's restricted entry point, etc.) > > > 3) What's the chance we wanna merge something like this into the > > official master branch? I accomplished what I wanted to do using a few > > #ifdef's and some funky makefile magic. I think it would merge easily. > > Maintaining a fork sounds like a lot of work to me. > > The fork is very minimal now that the hooks are available in core. I've > been involved in maintaining a true fork (based on 3.6 without the > hooks) and *that* is a lot of work, but now that it can all be done from > the entry-point it's actually pretty simple. > > > And here's the code: > > I'm very open to suggestions. I basically have no idea what I'm doing. > > I haven't touched C in about 7 years so don't expect the Mona Lisa. > > > https://github.com/python/cpython/compare/master...jsnklln:PEP551_restricted_entry_point > > I think this looks almost exactly like what we would merge if we were > going to merge anything. My concern is that I think if we offer anything > at all it will discourage people/distros from actually implementing it > properly for their context, and so we make things worse. Making it easy > to extend without actually doing it seems like a better place to be. > > And I'm totally in favour of publishing ready-to-build samples (again, > see https://github.com/zooba/spython). I just don't want people to think > we've "solved" security for them, when there's honestly no way for us to > do it from here. > > Cheers, > Steve > -- Jason Killen jsnk...@gmail.com Pain is inevitable, misery is optional. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Messag
[Python-Dev] Re: Restricted Entry Point from PEP-551/578
On 21/11/2019 18.27, Jason Killen wrote: > I sent in a couple of PRs, accepted and merged (Thanks!), lately that > switch to using io.open_code when appropriate. In the process of making > those PRs I spent a bit of time reading the two related PEPs. In > PEP-551 there's a suggestion that people use a restricted entry point in > production environments. I googled around a bit and couldn't find any > evidence that there was an existing implementation, at least not made > public, that people were using in a general sense. So I created a > branch from my fork and over the last few days have implemented part of > what's suggested in PEP-551. Specifically my changes remove most of the > command line options, ignore envvars (except for a possible logging > filename for the audit hooks), and registers an audit hook that logs > everything to the defined envvar when provided or stderr if not. As Steve already pointed out, https://github.com/zooba/spython contains examples examples for Windows and Linux. The linux_xattr is a PoC that I developed for our joined talk at EuroPython 2019. > Now the questions: > 1) Does anybody care? Is anyone currently doing this or planning on > doing this? > 2) Do we want to provide an "official" version of a restricted entry > point that could be used as-is or easily modified per specific needs? > Seems kinda silly to make everyone roll their own version but I'm happy > to yield to the will of the people. > 3) What's the chance we wanna merge something like this into the > official master branch? I accomplished what I wanted to do using a few > #ifdef's and some funky makefile magic. I think it would merge easily. > Maintaining a fork sounds like a lot of work to me. Yes, we still care. Steve has been more active on the Windows side than me on the Linux side. Please keep in mind that the feature is new to Python 3.8 and 3.8.0 just came out a little more than a month ago. It's going to take a while until major vendors will make use of the feature. PEP 578 features require distribution and vendor-specific adjustments. For example it makes sense to disable byte code compilation and usage on Windows. On the other hand RPM based platforms like RHEL always want to use precompiled byte code because PYC files are shipped with RPM packages. > And here's the code: > I'm very open to suggestions. I basically have no idea what I'm doing. > I haven't touched C in about 7 years so don't expect the Mona Lisa. > https://github.com/python/cpython/compare/master...jsnklln:PEP551_restricted_entry_point Thanks for your work! Prototypes like this are useful to figure out how Python's configuration should be improved. Eventually it should not be necessary to modify any code in CPython to create an spython interpreter. I like to reach a state in which it is possible to configure all these flags by providing a custom configuration. Victor's new config system in 3.8 can accomplish almost everything. It is currently not possible to modify argument parsing, though. One comment about your implementation: You are logging to a file. It's not very useful to log to a target in the same security context except for debugging. If an attacker is able to compromise the interpreter, then the attacker most likely gains enough privileges to wipe the file. That's why Steve uses the Windows event log in his examples and I'm going for syslog and journald. These logging system run as a different user and log files are protected by additional means, e.g. SELinux. I have been working on structures journald logging recently. Christian ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/HCSME57BS2AEAATLFMPLCKMWUYZX4SCM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Stalemate on bringing back PEP 523 support into Python 3.8
An unfortunate side-effect of making PyInterpreterState in Python 3.8 opaque is it removed [PEP 523](https://www.python.org/dev/peps/pep-0523/) support. https://www.python.org/dev/peps/pep-0523/ was opened to try and fix this, but there seems to be a stalemate in the issue. A key question is at what API level should setting the frame evaluation function live at? No one is suggesting the stable ABI, but there isn't agreement between CPython or the internal API (there's also seems to be a suggestion to potentially remove PEP 523 support entirely). And regardless of either, there also seems to be a disagreement about providing getters and setters to continue to try and hide PyInterpreterState regardless of which API level support is provided at (if any). If you have an opinion please weight in on the issue. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/4UZJYAZL3NHRAGN5WAMJC4IHAHEXF3QF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Restricted Entry Point from PEP-551/578
I knew the audit hooks were new but didn't realize they were quite that new. I didn't mean to come across as pejorative asking if people cared about this. The fact that I had trouble finding more information made me think this good stuff had been left by the wayside. It's new, I'll to pump the brakes a little and let things take their course. I wasn't aware of the configuration system for 3.8. I'll look into that. When I was in there poking around I kept wondering why we didn't have a fancy configuration system. The good news is we do I just didn't know about it. You're completely right about my implementation logging to a file. I fully admit my code wasn't camera ready. Once I learned that the hooks existed I wanted to give them a try. Once I got it working I wanted to get some feedback. Thank you for the feedback. I'm glad somebody is thinking about these types of things and I'd love to help if I can. On Thu, Nov 21, 2019 at 2:49 PM Christian Heimes wrote: > On 21/11/2019 18.27, Jason Killen wrote: > > I sent in a couple of PRs, accepted and merged (Thanks!), lately that > > switch to using io.open_code when appropriate. In the process of making > > those PRs I spent a bit of time reading the two related PEPs. In > > PEP-551 there's a suggestion that people use a restricted entry point in > > production environments. I googled around a bit and couldn't find any > > evidence that there was an existing implementation, at least not made > > public, that people were using in a general sense. So I created a > > branch from my fork and over the last few days have implemented part of > > what's suggested in PEP-551. Specifically my changes remove most of the > > command line options, ignore envvars (except for a possible logging > > filename for the audit hooks), and registers an audit hook that logs > > everything to the defined envvar when provided or stderr if not. > > As Steve already pointed out, https://github.com/zooba/spython contains > examples examples for Windows and Linux. The linux_xattr is a PoC that I > developed for our joined talk at EuroPython 2019. > > > Now the questions: > > 1) Does anybody care? Is anyone currently doing this or planning on > > doing this? > > 2) Do we want to provide an "official" version of a restricted entry > > point that could be used as-is or easily modified per specific needs? > > Seems kinda silly to make everyone roll their own version but I'm happy > > to yield to the will of the people. > > 3) What's the chance we wanna merge something like this into the > > official master branch? I accomplished what I wanted to do using a few > > #ifdef's and some funky makefile magic. I think it would merge easily. > > Maintaining a fork sounds like a lot of work to me. > > Yes, we still care. Steve has been more active on the Windows side than > me on the Linux side. Please keep in mind that the feature is new to > Python 3.8 and 3.8.0 just came out a little more than a month ago. It's > going to take a while until major vendors will make use of the feature. > > PEP 578 features require distribution and vendor-specific adjustments. > For example it makes sense to disable byte code compilation and usage on > Windows. On the other hand RPM based platforms like RHEL always want to > use precompiled byte code because PYC files are shipped with RPM packages. > > > And here's the code: > > I'm very open to suggestions. I basically have no idea what I'm doing. > > I haven't touched C in about 7 years so don't expect the Mona Lisa. > > > https://github.com/python/cpython/compare/master...jsnklln:PEP551_restricted_entry_point > > Thanks for your work! Prototypes like this are useful to figure out how > Python's configuration should be improved. Eventually it should not be > necessary to modify any code in CPython to create an spython > interpreter. I like to reach a state in which it is possible to > configure all these flags by providing a custom configuration. Victor's > new config system in 3.8 can accomplish almost everything. It is > currently not possible to modify argument parsing, though. > > One comment about your implementation: > You are logging to a file. It's not very useful to log to a target in > the same security context except for debugging. If an attacker is able > to compromise the interpreter, then the attacker most likely gains > enough privileges to wipe the file. That's why Steve uses the Windows > event log in his examples and I'm going for syslog and journald. These > logging system run as a different user and log files are protected by > additional means, e.g. SELinux. I have been working on structures > journald logging recently. > > Christian > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python
[Python-Dev] Re: Restricted Entry Point from PEP-551/578
On 21/11/2019 21.19, Jason Killen wrote: > I knew the audit hooks were new but didn't realize they were quite that > new. I didn't mean to come across as pejorative asking if people cared > about this. The fact that I had trouble finding more information made > me think this good stuff had been left by the wayside. It's new, I'll > to pump the brakes a little and let things take their course. > > I wasn't aware of the configuration system for 3.8. I'll look into > that. When I was in there poking around I kept wondering why we didn't > have a fancy configuration system. The good news is we do I just didn't > know about it. > > You're completely right about my implementation logging to a file. I > fully admit my code wasn't camera ready. Once I learned that the hooks > existed I wanted to give them a try. Once I got it working I wanted to > get some feedback. > > Thank you for the feedback. I'm glad somebody is thinking about these > types of things and I'd love to help if I can. I'm sorry, I wasn't trying to stop you or discourage you in any way. It was my intent to provide an explanation why there is not much adoption of the new hooks yet. Please go ahead, put the paddle to the metal and play around with the new features! For example you could look into the new config system and figure out what is missing to build an spython interpreter. Christian ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/5KKLTIKNY37GK4ZK4DJGGOHAPZFQHGN5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Restricted Entry Point from PEP-551/578
I'm good, not discouraged. Thank you for the explanation I've got my bearings now. I will try and figure out what's missing with the new config system. If you have tips or reading material or anything else I should know just send it on otherwise I'll start googling. On Thu, Nov 21, 2019 at 4:30 PM Christian Heimes wrote: > On 21/11/2019 21.19, Jason Killen wrote: > > I knew the audit hooks were new but didn't realize they were quite that > > new. I didn't mean to come across as pejorative asking if people cared > > about this. The fact that I had trouble finding more information made > > me think this good stuff had been left by the wayside. It's new, I'll > > to pump the brakes a little and let things take their course. > > > > I wasn't aware of the configuration system for 3.8. I'll look into > > that. When I was in there poking around I kept wondering why we didn't > > have a fancy configuration system. The good news is we do I just didn't > > know about it. > > > > You're completely right about my implementation logging to a file. I > > fully admit my code wasn't camera ready. Once I learned that the hooks > > existed I wanted to give them a try. Once I got it working I wanted to > > get some feedback. > > > > Thank you for the feedback. I'm glad somebody is thinking about these > > types of things and I'd love to help if I can. > > I'm sorry, I wasn't trying to stop you or discourage you in any way. It > was my intent to provide an explanation why there is not much adoption > of the new hooks yet. Please go ahead, put the paddle to the metal and > play around with the new features! > > For example you could look into the new config system and figure out > what is missing to build an spython interpreter. > > Christian > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/5KKLTIKNY37GK4ZK4DJGGOHAPZFQHGN5/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Jason Killen jsnk...@gmail.com Pain is inevitable, misery is optional. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/6E3CKBZXKFRXZLRD5SCAWBERUYBUP3QI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Restricted Entry Point from PEP-551/578
On 21Nov2019 1337, Jason Killen wrote: I'm good, not discouraged. Thank you for the explanation I've got my bearings now. I will try and figure out what's missing with the new config system. If you have tips or reading material or anything else I should know just send it on otherwise I'll start googling. Googling won't get you too far right now; you won't find much besides what's in the docs and PEPs (there are a couple of blog posts, but nothing that really adds much colour or detail yet). FWIW, we added the cpython.run_* events to make it easier to handle/block configuration options like "-c" and "-m" without having to parse the entire command line. You can see all the events at https://docs.python.org/3.8/library/audit_events.html (though some won't be raised until 3.8.1... we should probably mark those, or at least update that page to warn that events may have been added over time). Cheers, Steve ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/7ZD62K2U6VSP6W5JXFFKSYWKFFFHITMF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Stalemate on bringing back PEP 523 support into Python 3.8
(Replying here since b.p.o doesn't seem to want to let me log in) I've used the PEP 523 API several times for multiple projects, from analyzing bytecode frequency (which probably could be done with other means) to inspecting type information from function calls. I could probably do such analysis a different way too, (some people do it via tracing). But from what I have experienced, the PEP 523 API is much faster than alternatives, and I would be sad to see it go. I also have written some of these experiments in Rust, and it would make it harder to use if I had to deal with enabling it. I would much prefer the proposed setters/getters. Also the discussion is here for those who are interested https://bugs.python.org/issue38500 Best, Ethan On Thu, Nov 21, 2019 at 12:07 PM Brett Cannon wrote: > An unfortunate side-effect of making PyInterpreterState in Python 3.8 > opaque is it removed [PEP 523](https://www.python.org/dev/peps/pep-0523/) > support. https://www.python.org/dev/peps/pep-0523/ was opened to try and > fix this, but there seems to be a stalemate in the issue. > > A key question is at what API level should setting the frame evaluation > function live at? No one is suggesting the stable ABI, but there isn't > agreement between CPython or the internal API (there's also seems to be a > suggestion to potentially remove PEP 523 support entirely). > > And regardless of either, there also seems to be a disagreement about > providing getters and setters to continue to try and hide > PyInterpreterState regardless of which API level support is provided at (if > any). > > If you have an opinion please weight in on the issue. > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/4UZJYAZL3NHRAGN5WAMJC4IHAHEXF3QF/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/55CY7JXPYJWXUO7HE4S334AOIWACKV75/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Restricted Entry Point from PEP-551/578
On 11/21/2019 4:46 PM, Steve Dower wrote: (though some won't be raised until 3.8.1... we should probably mark those, or at least update that page to warn that events may have been added over time). I included this in a new audit doc issue. https://bugs.python.org/issue38892 -- Terry Jan Reedy ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/OBHSBXUMM6EML35MY76QPAP7PQVNEHBY/ Code of Conduct: http://python.org/psf/codeofconduct/
