Re: [PATCH] selinux-testsuite: update to work on Debian

[Petr Lautrbach <plautrba@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 4361 bytes --]

On Thu, May 07, 2020 at 10:22:09AM -0500, William Roberts wrote:
> >
> > On Thu, May 7, 2020 at 11:02 AM William Roberts
> > <bill.c.roberts@gmail.com> wrote:
> > >
> > > >
> > > > On Thu, May 7, 2020 at 10:49 AM Russell Coker <russell@coker.com.au> wrote:
> > > > >
> > > > > On Thursday, 7 May 2020 6:35:11 PM AEST Laurent Bigonville wrote:
> > > > > > If people are using preseed installations (kickstart equivalent), I
> > > > > > think that enabling SELinux in the installer shouldn't be too difficult
> > > > > > (installing the needed packages, modifying the files and relabeling with
> > > > > > fixfiles). It's obviously not user friendly, but the question is what's
> > > > > > the target here.
> > > > >
> > > > > If we want to do that properly then I guess we want SE Linux enabled in the
> > > > > kernel that the installer uses and then have the policy installed early in the
> > > > > installation so the files can have the correct labels from the start instead of
> > > > > having a relabel process afterwards.
> > > >
> > > > That would be good but might be overreach for Debian since SELinux is
> > > > not the default there.  It isn't strictly necessary; ever since we
> > > > went to using extended attributes for file labels, you can set them on
> > > > a non-SELinux-enabled kernel, so the installer can always set them
> > > > even if its kernel doesn't enable SELinux.  Optimally they would be
> > > > set by the package manager based on file_contexts; that is what rpm
> > > > does in Fedora/RHEL.  Or you can always run setfiles after package
> > > > installation but before rebooting into the SELinux-enabled kernel.
> > > > You don't need to defer labeling until you have SELinux enabled.
> > >
> > > On Thu, May 7, 2020 at 9:54 AM Stephen Smalley
> > > <stephen.smalley.work@gmail.com> wrote:
> > >
> > > I found this:
> > >   - https://man.sr.ht/builds.sr.ht/compatibility.md
> > >
> > > It seems to have Fedora-30,31 and rawhide.
> > > It seems to be free as well (for now)
> > > I would be a little leary using it, seems new, its only in alpha,
> > > and looks like it could disappear at any moment.
> > >
> > > The travis ubuntu to fedora VM might be heavy, but it would at least provide
> > > us with something stable... for awhile or we look at getting some
> > > better infrastructure support for running a CI job on.
> >
> > Fedora's own CI infrastructure seems like a better bet for the near
> > term wrt testing on Fedora; Petr appears to be already exploring using
> > it.
> 
> I though the Fedora CI was limiting the amount of testing and
> triggering tests, no?
> Or is that why he is exploring it to see if we can get around them?

The main purpose of Fedora CI is to test Fedora packages either when they're
built or when there's a pull request in pagure frontend [1]. It's configured via
tests/tests.yml [2] file.

In Fedora we use a set of integration tests originally used in Red Hat [3]

I've created "Run upstream tests on upstream sources" pull request [4] which
disables RH tests and add "upstream" test. This tests clones github repository,
build and install sources and runs `make test` from subdirectories. It's kind of
hack but seems to work [5]. I'd like to enable also Red Hat based tests for this
"upstream" test to get more and better results.

AFAIK the amount of testing is limited only in sense that you can have one run
for one pull request at the time and in order to create a pull request you
need to have a Fedora account, but you don't have to be a packager  -
https://docs.fedoraproject.org/en-US/ci/pull-requests/#_you_are_not_a_packager 


[1] https://src.fedoraproject.org/rpms
[2] https://src.fedoraproject.org/rpms/policycoreutils/blob/master/f/tests/tests.yml
[3] https://src.fedoraproject.org/tests/selinux/tree/master
[4] https://src.fedoraproject.org/rpms/policycoreutils/pull-request/15
[5] https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenkins/fedora-rawhide-pr-pipeline/detail/fedora-rawhide-pr-pipeline/3462/artifacts


> > My goal here though is to improve the level of support outside of
> > just Fedora and its derivatives.
> 
> Definitely a plus.
> 

-- 
()  ascii ribbon campaign - against html e-mail 
/\  www.asciiribbon.org   - against proprietary attachments

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]