On 10/13/2017 11:07 PM, Jerry James wrote:
On Sat, Oct 7, 2017 at 9:34 AM, Jerry James <loganje...@gmail.com> wrote:
I don't believe that anybody looks at those pull requests on a regular
basis. Should somebody be doing so? There are 8 pull requests,
dating back to about the time of the above conversation. Five of
those don't contain a single comment.
I opened one for gcl on July 29, and added a comment a month later
asking if somebody was going to look at it. No response. This is a
bit annoying, considering that I opened a bugzilla request asking for
the same thing 4 years ago, and no action has ever been taken on it.
I thought maybe a PR would finally get something to happen.
Nearly a week has gone by, and no answer. I'm really stumped about
what to do. Let me summarize the whole long saga and solicit help.
GCL is a Common Lisp implementation. It is known for its speed
compared to other CL implementations. It has a long lineage,
summarized here: https://en.wikipedia.org/wiki/GNU_Common_Lisp. I
took over maintenance of the package in late 2008 when the previous
maintainer did not have time to continue. At that point, the package
did not build in Rawhide and was slated to be dropped from Fedora
soon. I got it working with help from upstream and Daniel Walsh, who
provided advice on putting together an SELinux policy to account for
the fact that GCL produces executable code on the fly by calling
mprotect on selected pages.
Fast forward to 2013. By that time, the GCL policy also had to
mention maxima executables, since executables built with GCL also use
the GCL memory allocator. I figured that meant it was time to merge
the GCL policy into the system policy, and consequently opened a
bugzilla ticket. In spite of me trying to reboot the conversation a
couple of times, those involved who held the SELinux reins for Fedora,
Just. Could. Not. Stay. On. Topic. We talked about the execheap
permission in general, and its place in the universe. Some of them
sneeringly, condescendingly wondered why upstream and I were both so
incompetent that we didn't just rewrite the allocator to use mmap.
(Hint: it isn't easy, and upstream isn't interested in the exercise.)
After multiple failures on my part to get something to happen, I gave
up in despair.
Fast forward to 2017. Attempts to build maxima with gcl on aarch64
started hanging at package install time. See
https://bugzilla.redhat.com/show_bug.cgi?id=1435395. This was blamed
on gcl, incorrectly I believe. As I pointed out in the bug, nothing
built from gcl sources runs at package install time, so the hang must
be happening inside one of fixfiles, semodule, or restorecon, which
ARE run from the gcl install scripts because GCL has to install its
own SELinux policy, due to that policy not being merged into the
system policy. So, policycoreutils maintainers! Something Is Afoot
on aarch64!
But that's not the end of the fun. GCL failed the mass rebuild this
summer. It built successfully on every architecture but s390x. On
s390x, the build failed due to a failed call to mprotect(), almost
certainly a sign that SELinux was in enforcing mode on the builder.
Was that a known issue with s390x builders? And, if so, has it been
rectified since? If so, I'll try building again.
I still want the system policy to account for GCL, in some way or
another. But, as you can see from the quoted text above, submitting a
pull request to the relevant git repository has resulted in months of
<crickets chirping>. And pointing that out on this list last weekend
has resulted in still more of the crickets.
So ... what is a packager supposed to do???? Why is it so hard to get
any attention for submissions to the system SELinux policy? There
should be a barrier to entry; I understand that. But I can't even get
the gatekeeper to have a conversation with me. Heeeeellllllppppp!!!
Frustratedly yours,
Hello community,
We, as Red Hat SELinux team, apologise for recent delays with our
answers to your requests and questions related to SELinux. We have been
quite busy last couple of weeks so we decided to set a lower priority
for Fedora work. We already responded and resolved what was needed and
we are ready to react more flexibly in the future.
Note: If you are interested in writing custom SELinux policy for your
package, you can follow the
https://fedoraproject.org/wiki/SELinux/IndependentPolicy documentation
on wiki.
Regards,
Lukas
--
Lukas Vrabec
Software Engineer, Security Technologies
Red Hat, Inc.
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
