[Python-Dev] [Security-sig] PEP 551: Security transparency in the Python runtime
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:
* 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
More information about the Python-Dev
mailing list