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@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/steve.dower%40python.org
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
