On Tuesday, August 29, 2017, Steve Dower <steve.do...@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.
>>> bdist_wheel.write_record():
>>>
>>> https://bitbucket.org/pypa/wheel/src/5d49f8cf18679d1bc6f3e1e
>>> 414a5df3a1e492644/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.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/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
