On Mon, Aug 9, 2021 at 4:44 PM Dominick Grift <dominick.grift@xxxxxxxxxxx> wrote: > > James Carter <jwcart2@xxxxxxxxx> writes: > > > On Fri, Aug 6, 2021 at 2:29 PM Petr Lautrbach <plautrba@xxxxxxxxxx> wrote: > >> > >> Hello, > >> > >> I's about 184 commits and 5 months since the last release so I think > >> it's time to slowly stop the development and start with 3.3 release > >> candidates. > >> > >> According to patchwork, there are few patches in queue which need to be > >> reviewed, or which were reviewed and some change for requested: > >> > >> * https://patchwork.kernel.org/patch/11436955/ New [RFC] > >> libsepol,secilc,policycoreutils: add unprivileged sandboxing > >> capability > >> * https://patchwork.kernel.org/patch/11668455/ New selinux: make use of variables when defining libdir and includedir > >> > >> old, without any activity for a long time > >> > >> * https://patchwork.kernel.org/patch/12291637/ New [v2] checkpolicy: fix the leak memory when uses xperms > >> > >> changes requested > >> > >> * https://patchwork.kernel.org/patch/12372487/ New [v2] libselinux: add lock callbacks > >> * https://patchwork.kernel.org/patch/12377593/ New libselinux/utils: drop requirement to combine compiling and linking > >> > >> no response yet > >> > >> * https://patchwork.kernel.org/patch/12420657/ New [userspace] libsepol/cil: remove obsolete comment > >> > >> acked, ready to be merged > >> > >> * https://patchwork.kernel.org/patch/12422971/ New mcstrans: Improve mlstrans-test output > >> > >> no response yet > >> > >> > >> if I missed something please tell me. > >> > >> > >> There's one issue opened on the mailing list > >> > >> https://lore.kernel.org/selinux/874kc57220.fsf@xxxxxxxxxxx/T/#t - > >> libsepol regressions > >> > > > > I am working to address this and hope to have something out in the > > next couple of days. I am also working on fixing some issues with the > > line mark stuff in CIL. It would be nice to have both of these in the > > next release, but I don't think they need to hold things up either. > > Jim > > It's too soon for me to start worrying about this but: > > I don't care if my dssp5 policy breaks due to this regression (that is > what it is) because other than me no one probably uses it, but I also > maintain a policy for OpenWrt which relies on this functionality (or > allowing duplicate blocks, macros) and I would not want to have this > break there come 3.3. > > > > >> If you agree and there's no obejction I can start with preparation and > >> plan to release 3.3-rc1 on Wed Aug 18 2021 Hello, For information I am currently on holidays with quite limited access to my mails and will be fully "back with my test machines" on 2021-08-30. In the meantime I can participate in some reviews but I am not willing to send patches myself. Nevertheless I will try to review the "libsepol/cil: move the fuzz target and build script to the selinux repository" patch properly before Wednesday. For the release, I am currently aware of two possibly-minor issues and I do not know whether they are tracked somewhere: 1. secil2tree can output wrongly indented blocks. For example "secil2tree -A resolve secilc/test/policy.cil" currently outputs: (block test_ba (blockinherit ba) (roletype test_ba.r test_ba.t) (blockabstract z.ba) ) (role test_ba.r) (type test_ba.t) ) The parenthesizing "(blockinherit ba) ... )" is wrong. The "(blockinherit ba)" could be replaced with a comment indicating that a blockinherit was expanded. 2. semanage's gettext setup is currently incompatible with Python 3.10. More precisely https://docs.python.org/3.8/library/gettext.html#gettext.install indicates: "Deprecated since version 3.8, will be removed in version 3.10: The codeset parameter.". When I stumbled upon this issue, it occured to me that the whole try-except statement in https://github.com/SELinuxProject/selinux/blob/libsemanage-3.2/python/semanage/semanage#L34-L49 could be replaced with "import gettext" (which is a built-in module in Python 3) and "gettext.install(PROGNAME, localedir="/usr/share/locale")". Nevertheless I did not find time to properly test this change, which is why I have not sent patches for it sooner. In my opinion, the first issue is not a release-blocker because "secil2tree -A resolve" is not expected to output a CIL policy which can be compiled. The second one could be, if we want to support Python 3.10 (which will be released in October) with the 3.3 release. Thanks, Nicolas
