[Python-Dev] [Security-sig] PEP 551: Security transparency in the Python runtime (original) (raw)

Steve Dower steve.dower at python.org
Tue Aug 29 11:12:09 EDT 2017

On 29Aug2017 0801, Steve Dower wrote:

On 29Aug2017 0614, Wes Turner wrote:

Wouldn't it be great to have the resources to source audit all code? (And expect everyone to GPG sign all their commits someday.) If you care this much, then you will find the resources to audit all the code manually after you've downloaded it and before you've deployed it (or delegate that trust/liability elsewhere). Plenty of larger companies do it, especially for their high value targets.

On re-reading it wasn't entirely clear, so just to clarify:

Cheers, Steve

The rest of your email is highly platform-specific, and so while they are potential uses of this PEP, and I hope people will take the time to investigate them, they don't contribute to it in any way. None of these things will be added to or required by the core CPython release.

Cheers, Steve

Many Linux packaging formats do have checksums of all files in a package: {RPM, DEB,}

Python Wheel packages do have a manifest with SHA256 file checksums. bdistwheel.writerecord(): https://bitbucket.org/pypa/wheel/src/5d49f8cf18679d1bc6f3e1e414a5df3a1e492644/wheel/bdistwheel.py?at=default&fileviewer=file-view-default#bdistwheel.py-436

Is there a tool for checking these manifest and file checksums and signatures? Which keys can sign for which packages? IIUC, any key loaded into the local keyring is currently valid for any package? "ENH: GPG signatures, branch-environment map (GitFS/HgFS workflow)" https://github.com/saltstack/salt/issues/12183 - links to GPG signing support in hg, git, os packaging systems ... Setting and checking SELinux file context labels: Someone else can explain how DEB handles semanage and chcon? https://fedoraproject.org/wiki/PackagingDrafts/SELinux RPM supports .te (type enforcement), .fc (file context), and .if SELinux files with an semodule command. RPM requires various combinations of the policycoreutils, selinux-policy-targeted, selinux-policy-devel, and  policycoreutils-python packages. Should setup.py (running with set fcontext (eg root)) just call chcon itself; or is it much better to repack (signed) Python packages as e.g. RPMs? FWIW, Salt and Ansible do support setting and checking SELinux file contexts: salt.modules.selinux: https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.selinux.html https://github.com/saltstack/salt/blob/develop/salt/modules/selinux.py Requires: - cmds: semanage, setsebool, semodule - pkgs: policycoreutils, policycoreutils-python, Ansible sefcontext: http://docs.ansible.com/ansible/latest/sefcontextmodule.html https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/system/sefcontext.py Requires: - pkgs: libselinux-python, policycoreutils-python Does it make sense to require e.g. policycoreutils-python[-python] in 'spython'? ((1) Instead of wrapping ls -Z and chcon (2) in setup.py (3) as root)?

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve.dower%40python.org

More information about the Python-Dev mailing list