[Python-Dev] [Security-sig] PEP 551: Security transparency in the Python runtime

[Steve Dower]

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.


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. 
> bdist_wheel.write_record():
> 
> https://bitbucket.org/pypa/wheel/src/5d49f8cf18679d1bc6f3e1e414a5df3a1e492644/wheel/bdist_wheel.py?at=default&fileviewer=file-view-default#bdist_wheel.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/sefcontext_module.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)?