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

Wes Turner wes.turner at gmail.com
Tue Aug 29 12:04:19 EDT 2017

On Tuesday, August 29, 2017, Steve Dower <steve.dower at python.org> wrote:

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)

avc: denied <[{/end>

Thanks!

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/5d49f8cf18679d1bc6f3e1e 414a5df3a1e492644/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.mo dules.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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20170829/83017931/attachment.html>

More information about the Python-Dev mailing list