Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PEP 578: Mark as Final #3811

Merged
merged 4 commits into from
Jun 3, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 8 additions & 9 deletions peps/pep-0578.rst
Original file line number Diff line number Diff line change
@@ -1,16 +1,15 @@
PEP: 578
Title: Python Runtime Audit Hooks
Version: $Revision$
Last-Modified: $Date$
Author: Steve Dower <[email protected]>
BDFL-Delegate: Christian Heimes <[email protected]>
Status: Accepted
Status: Final
Type: Standards Track
Content-Type: text/x-rst
Created: 16-Jun-2018
Python-Version: 3.8
Post-History: 28-Mar-2019, 07-May-2019

.. canonical-doc:: :ref:`python:audit-events`

Abstract
========

Expand Down Expand Up @@ -85,7 +84,7 @@ The aim of these changes is to enable both application developers and
system administrators to integrate Python into their existing
monitoring systems without dictating how those systems look or behave.

We propose two API changes to enable this: an Audit Hook and Verified
We propose two API changes to enable this: an Audit Hook and Verified
Open Hook. Both are available from Python and native code, allowing
applications and frameworks written in pure Python code to take
advantage of the extra messages, while also allowing embedders or
Expand Down Expand Up @@ -284,7 +283,7 @@ API Availability

While all the functions added here are considered public and stable API,
the behavior of the functions is implementation specific. Most
descriptions here refer to the CPython implementation, and while other
descriptions here refer to the CPython implementation, and while other
implementations should provide the functions, there is no requirement
that they behave the same.

Expand Down Expand Up @@ -506,7 +505,7 @@ The argument that this is "security by obscurity" is valid, but
irrelevant. Security by obscurity is only an issue when there are no
other protective mechanisms; obscurity as the first step in avoiding
attack is strongly recommended (see `this article
<https://danielmiessler.com/study/security-by-obscurity/>`_ for
<https://danielmiessler.com/p/security-by-obscurity/>`_ for
discussion).

This idea is rejected because there are no appropriate reasons for an
Expand Down Expand Up @@ -557,7 +556,7 @@ a secure or audited environment.
References
==========

.. [1] Python Performance Benchmark Suite `<https://github.com/python/performance>`_
.. [1] Python Performance Benchmark Suite `<https://github.com/python/pyperformance>`_

.. [2] Python Security model - Sandbox `<https://python-security.readthedocs.io/security.html#sandbox>`_

Expand All @@ -567,4 +566,4 @@ Copyright
Copyright (c) 2019 by Microsoft Corporation. This material may be
distributed only subject to the terms and conditions set forth in the
Open Publication License, v1.0 or later (the latest version is presently
available at http://www.opencontent.org/openpub/).
available at https://spdx.org/licenses/OPUBL-1.0.html).
Loading