Add links

Author: pablogsal

peps/pep-0768.rst

@@ -287,7 +287,6 @@ This change has no impact on existing Python code or interpreter performance.
 The added fields are only accessed during debugger attachment, and the checking
 mechanism piggybacks on existing interpreter safe points.
 
-
 Security Implications
 =====================
 
@@ -297,23 +296,26 @@ the PEP doesn't specify how memory should be written to the target process, in p
 this will be done using standard system calls that are already being used by other
 debuggers and tools. Some examples are:
 
-* On Linux, the ``process_vm_readv()`` and ``process_vm_writev()`` system calls
+* On Linux, the `process_vm_readv() <https://man7.org/linux/man-pages/man2/process_vm_readv.2.html>`__
+  and `process_vm_writev() <https://man7.org/linux/man-pages/man2/process_vm_writev.2.html>`__ system calls
   are used to read and write memory from another process. These operations are
-  controlled by ptrace access mode checks - the same ones that govern debugger
-  attachment. A process can only read from or write to another process's memory
-  if it has the appropriate permissions (typically requiring either root or the
-  ``CAP_SYS_PTRACE`` capability, though less security minded distributions may
-  allow any process running as the same uid to attach).
-
-* On macOS, the interface would leverage ``mach_vm_read_overwrite()`` and
-  ``mach_vm_write()`` through the Mach task system. These operations require
+  controlled by `ptrace <https://man7.org/linux/man-pages/man2/ptrace.2.html>`__ access mode
+  checks - the same ones that govern debugger attachment. A process can only read from
+  or write to another process's memory if it has the appropriate permissions (typically
+  requiring either root or the `CAP_SYS_PTRACE <https://man7.org/linux/man-pages/man7/capabilities.7.html>`__
+  capability, though less security minded distributions may allow any process running as the same uid to attach).
+
+* On macOS, the interface would leverage `mach_vm_read_overwrite() <https://developer.apple.com/documentation/kernel/1402127-mach_vm_read_overwrite>`__ and
+  `mach_vm_write() <https://developer.apple.com/documentation/kernel/1402070-mach_vm_write>`__ through the Mach task system. These operations require
   ``task_for_pid()`` access, which is strictly controlled by the operating
   system. By default, access is limited to processes running as root or those
   with specific entitlements granted by Apple's security framework.
 
-* On Windows, the ``ReadProcessMemory()`` and ``WriteProcessMemory()`` functions
+* On Windows, the `ReadProcessMemory() <https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-readprocessmemory>`__
+  and `WriteProcessMemory() <https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-writeprocessmemory>`__ functions
   provide similar functionality. Access is controlled through the Windows
-  security model - a process needs ``PROCESS_VM_READ`` and ``PROCESS_VM_WRITE``
+  security model - a process needs `PROCESS_VM_READ <https://learn.microsoft.com/en-us/windows/win32/procthread/process-security-and-access-rights>`__
+  and `PROCESS_VM_WRITE <https://learn.microsoft.com/en-us/windows/win32/procthread/process-security-and-access-rights>`__
   permissions, which typically require the same user context or appropriate
   privileges. These are the same permissions required by debuggers, ensuring
   consistent security semantics across platforms.
@@ -327,7 +329,7 @@ All mechanisms ensure that:
 The memory operations themselves are well-established and have been used safely
 for decades in tools like GDB, LLDB, and various system profilers.
 
-It’s important to note that any attempt to attach to a Python process via this
+It's important to note that any attempt to attach to a Python process via this
 mechanism would be detectable by system-level monitoring tools. This
 transparency provides an additional layer of accountability, allowing
 administrators to audit debugging operations in sensitive environments.
@@ -336,12 +338,12 @@ Further, the strict reliance on OS-level security controls ensures that existing
 system policies remain effective. For enterprise environments, this means
 administrators can continue to enforce debugging restrictions using standard
 tools and policies without requiring additional configuration. For instance,
-leveraging Linux’s ``ptrace_scope`` or macOS’s ``taskgated`` to restrict
-debugger access will equally govern the proposed interface.
+leveraging Linux's `ptrace_scope <https://www.kernel.org/doc/Documentation/security/Yama.txt>`__
+or macOS's ``taskgated`` to restrict debugger access will equally govern the
+proposed interface.
 
 By maintaining compatibility with existing security frameworks, this design
 ensures that adopting the new interface requires no changes to established
-security practices, thereby minimizing barriers to adoption.
 
 How to Teach This
 =================