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

[Steve Dower]

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:

* above, "you" is meant as a generally inclusive term (i.e., not just 
Wes, unless Wes is also a sysadmin who is trying to carefully control 
his network :) )

* below, "you" is specifically the author of the email (i.e., Wes)

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. 
>> 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)?
> _______________________________________________
> 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