* libsepol releases @ 2020-04-05 9:46 Russell Coker 2020-04-07 8:59 ` Petr Lautrbach 0 siblings, 1 reply; 8+ messages in thread From: Russell Coker @ 2020-04-05 9:46 UTC (permalink / raw) To: selinux https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955154 We have the above Debian bug report requesting a GIT patch for libsepol for GCC-10 support. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955286 We also have the above for a policy constraint error. Could we have a new upstream release soon to cover all GCC-10 issues as well as any other important things? Maybe version 3.0.1? -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: libsepol releases 2020-04-05 9:46 libsepol releases Russell Coker @ 2020-04-07 8:59 ` Petr Lautrbach [not found] ` <20200422065053.GA167999@workstation> 0 siblings, 1 reply; 8+ messages in thread From: Petr Lautrbach @ 2020-04-07 8:59 UTC (permalink / raw) To: Russell Coker; +Cc: selinux [-- Attachment #1: Type: text/plain, Size: 691 bytes --] On Sun, Apr 05, 2020 at 07:46:37PM +1000, Russell Coker wrote: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955154 > > We have the above Debian bug report requesting a GIT patch for libsepol for > GCC-10 support. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955286 > > We also have the above for a policy constraint error. > > Could we have a new upstream release soon to cover all GCC-10 issues as well > as any other important things? Maybe version 3.0.1? > It's more than 4 months since the latest release so I think it's worth it to release 3.1. If there's no objection, I'll send a heads up that we'll release 3.1-rc1 next week. Petr [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <20200422065053.GA167999@workstation>]
[parent not found: <CAHC9VhQUmY=ue3zWdTnE1Ehi90Lj3077sLbu+jyaWoAVKuKyeQ@mail.gmail.com>]
[parent not found: <CAFftDdo1hqbacU2TD6zQp_t_KJq-KS5pWBMr89c4HA3=aUdUbQ@mail.gmail.com>]
[parent not found: <20200423150039.GC204116@workstation>]
* Fedora VM On Travis for Testing [not found] ` <20200423150039.GC204116@workstation> @ 2020-05-14 21:00 ` William Roberts 2020-05-14 22:03 ` Nicolas Iooss 2020-05-14 22:20 ` Stephen Smalley 0 siblings, 2 replies; 8+ messages in thread From: William Roberts @ 2020-05-14 21:00 UTC (permalink / raw) To: SElinux list Cc: Paul Moore, Stephen Smalley, Nicolas Iooss, Jason Zaman, Steve Lawrence, Chris PeBenito, Jeffrey Vander Stoep, James Carter, Joshua Brindle, Ondrej Mosnacek, Petr Lautrbach I just wanted to lay out a demo of a Fedora 32 cloud VM image booting on Travis with execution happening in the Fedora VM. The Fedora VM contains the selinux source code for that particular travis build, so it has the PR patches, etc. The VM has networking. The build logs for the Travis run are here: - https://travis-ci.org/github/williamcroberts/selinux/builds/687185489 Which comes from my git tree here: - https://github.com/williamcroberts/selinux/tree/kvm-fedora-testing Note that it's super messy, I need to go through and cleanup both the patch and the git history. I also should verify the downloaded image is signed for the VM. Also note that I may rebase/squash my git branch at any time. Petr started a release document here: - https://github.com/bachradsusi/SELinuxProject-selinux/blob/RELEASE/RELEASE_PROCESS.md I'd like to gather feedback, and perhaps more comments on: 1. Is this CI approach worth continuing? 2. Comments on the CI scripts (I have no idea what I am doing, common issue) 3. Comments, patches, suggestions on what tests to run in this CI environment. 4. More information in in the RELEASE_PROCESS.md file. I made some comments there as well on ideas. My goal here is that a release can occur if CI is passing without worry, and that we automate manual steps as much as possible. This way, if we get hit by a bus releases can occur without much effort. Thanks, Bill ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Fedora VM On Travis for Testing 2020-05-14 21:00 ` Fedora VM On Travis for Testing William Roberts @ 2020-05-14 22:03 ` Nicolas Iooss 2020-05-14 22:23 ` William Roberts 2020-05-14 22:20 ` Stephen Smalley 1 sibling, 1 reply; 8+ messages in thread From: Nicolas Iooss @ 2020-05-14 22:03 UTC (permalink / raw) To: William Roberts Cc: SElinux list, Paul Moore, Stephen Smalley, Jason Zaman, Steve Lawrence, Chris PeBenito, Jeffrey Vander Stoep, James Carter, Joshua Brindle, Ondrej Mosnacek, Petr Lautrbach On Thu, May 14, 2020 at 11:00 PM William Roberts <bill.c.roberts@gmail.com> wrote: > > I just wanted to lay out a demo of a Fedora 32 cloud VM image booting > on Travis with execution happening in the Fedora VM. > The Fedora VM contains the selinux source code for that particular > travis build, so it has the PR patches, etc. > The VM has networking. > > The build logs for the Travis run are here: > - https://travis-ci.org/github/williamcroberts/selinux/builds/687185489 > > Which comes from my git tree here: > - https://github.com/williamcroberts/selinux/tree/kvm-fedora-testing > > Note that it's super messy, I need to go through and cleanup both the > patch and the git > history. I also should verify the downloaded image is signed for the VM. > Also note that I may rebase/squash my git branch at any time. > > Petr started a release document here: > - https://github.com/bachradsusi/SELinuxProject-selinux/blob/RELEASE/RELEASE_PROCESS.md > > I'd like to gather feedback, and perhaps more comments on: > 1. Is this CI approach worth continuing? > 2. Comments on the CI scripts (I have no idea what I am doing, common issue) > 3. Comments, patches, suggestions on what tests to run in this CI environment. > 4. More information in in the RELEASE_PROCESS.md file. I made some > comments there > as well on ideas. > > My goal here is that a release can occur if CI is passing without > worry, and that > we automate manual steps as much as possible. This way, if we get hit by a bus > releases can occur without much effort. Hi, This sounds like a nice idea :) Also it appears it only takes 5 minutes to run the whole Travis CI job of setting the Fedora VM up and booting it, which is more than acceptable in term of delays (and is very quicker than building and testing the project itself). This could allow to run more tests that require to be able to manage the SELinux policy, automatically at every pull requests. By the way I wasn't expecting Travis-CI to easily allow nested virtualization ("nested" because jobs are already run inside VMs, IIRC). If it works, it is great! Some quick thoughts/suggestions/comments that I have in my head after reading very quickly your changes: - The networking setup of the VM seems to be more complex than needed because you are relying on getting the IP address from DHCP. Would it be possible to configure libvirt with port forwarding, so that "ssh -p 2222 127.0.0.1" always work? (with raw QEMU, the command-line parameters would be something like -net nic,model=virtio,macaddr=52:54:00:12:34:56 -net user,hostfwd=tcp:127.0.0.1:2222-:22) - Usually the helper scripts are located in directory scripts/, which make them more easily discovered by people reading the code (hidden files and directories seems more appropriate to store the configuration for different CI platforms that require them ; some projects choose to hide everything that is not useful for the build process but here it does seem to be so). Are there advantages of using .ci/ directory? - Moreover having a "fedora-test.run" (or "fedora-test.sh", I am more used to .sh extension for shell scripts) enables to easily reproduce tests on a local development machine using "vagrant init fedora/32-cloud-base && vagrant ssh" + "sudo /vagrant/.../fedora-test.run". Such a command could be documented in the header of the shell script. - Right now, there are many things in .travis.yml. This file could be split in shell script(s) if that reduces duplication. - To verify the download of Fedora cloud image, instead of hard-coding its SHA256 digest, you could download the checksum file which is signed using GnuPG and check its signature, as described on https://alt.fedoraproject.org/cloud/ Cheers, Nicolas ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Fedora VM On Travis for Testing 2020-05-14 22:03 ` Nicolas Iooss @ 2020-05-14 22:23 ` William Roberts 0 siblings, 0 replies; 8+ messages in thread From: William Roberts @ 2020-05-14 22:23 UTC (permalink / raw) To: Nicolas Iooss Cc: SElinux list, Paul Moore, Stephen Smalley, Jason Zaman, Steve Lawrence, Chris PeBenito, Jeffrey Vander Stoep, James Carter, Joshua Brindle, Ondrej Mosnacek, Petr Lautrbach On Thu, May 14, 2020 at 5:03 PM Nicolas Iooss <nicolas.iooss@m4x.org> wrote: > > On Thu, May 14, 2020 at 11:00 PM William Roberts > <bill.c.roberts@gmail.com> wrote: > > > > I just wanted to lay out a demo of a Fedora 32 cloud VM image booting > > on Travis with execution happening in the Fedora VM. > > The Fedora VM contains the selinux source code for that particular > > travis build, so it has the PR patches, etc. > > The VM has networking. > > > > The build logs for the Travis run are here: > > - https://travis-ci.org/github/williamcroberts/selinux/builds/687185489 > > > > Which comes from my git tree here: > > - https://github.com/williamcroberts/selinux/tree/kvm-fedora-testing > > > > Note that it's super messy, I need to go through and cleanup both the > > patch and the git > > history. I also should verify the downloaded image is signed for the VM. > > Also note that I may rebase/squash my git branch at any time. > > > > Petr started a release document here: > > - https://github.com/bachradsusi/SELinuxProject-selinux/blob/RELEASE/RELEASE_PROCESS.md > > > > I'd like to gather feedback, and perhaps more comments on: > > 1. Is this CI approach worth continuing? > > 2. Comments on the CI scripts (I have no idea what I am doing, common issue) > > 3. Comments, patches, suggestions on what tests to run in this CI environment. > > 4. More information in in the RELEASE_PROCESS.md file. I made some > > comments there > > as well on ideas. > > > > My goal here is that a release can occur if CI is passing without > > worry, and that > > we automate manual steps as much as possible. This way, if we get hit by a bus > > releases can occur without much effort. > > Hi, > This sounds like a nice idea :) Also it appears it only takes 5 > minutes to run the whole Travis CI job of setting the Fedora VM up and > booting it, which is more than acceptable in term of delays (and is > very quicker than building and testing the project itself). This could Yeah I was pretty happy with the timing it took to add this. But CI doesn't necessarily need to be fast. We run a huge test matrix, Travis only spins up a few at a time anyways. > allow to run more tests that require to be able to manage the SELinux > policy, automatically at every pull requests. > > By the way I wasn't expecting Travis-CI to easily allow nested > virtualization ("nested" because jobs are already run inside VMs, > IIRC). If it works, it is great! I was surprised too, I was expecting that to be disabled, when I cat cpuinfo, I was very happy. > > Some quick thoughts/suggestions/comments that I have in my head after > reading very quickly your changes: > - The networking setup of the VM seems to be more complex than needed > because you are relying on getting the IP address from DHCP. Would it > be possible to configure libvirt with port forwarding, so that "ssh -p > 2222 127.0.0.1" always work? (with raw QEMU, the command-line > parameters would be something like -net > nic,model=virtio,macaddr=52:54:00:12:34:56 -net > user,hostfwd=tcp:127.0.0.1:2222-:22) I would love something like that (no idea what I am doing), but it doesn't get rid of polling for network. We have to wait for the sshd to be ready. > - Usually the helper scripts are located in directory scripts/, which > make them more easily discovered by people reading the code (hidden > files and directories seems more appropriate to store the > configuration for different CI platforms that require them ; some > projects choose to hide everything that is not useful for the build > process but here it does seem to be so). Are there advantages of using > .ci/ directory? No benefit, just did something. They can live wherever.... > - Moreover having a "fedora-test.run" (or "fedora-test.sh", I am more > used to .sh extension for shell scripts) enables to easily reproduce and be named whatever.... > tests on a local development machine using "vagrant init > fedora/32-cloud-base && vagrant ssh" + "sudo > /vagrant/.../fedora-test.run". Such a command could be documented in > the header of the shell script. That sounds good, I like being able to do that. I have no idea what vagrant is. You could say im ignorant to vargrant! > - Right now, there are many things in .travis.yml. This file could be > split in shell script(s) if that reduces duplication. Yep I agree. Thats how I run all my other projects, I dislike large travis.yml files, but I don't want to take on that workload right now, ideally get this working and then port the other stuff. > - To verify the download of Fedora cloud image, instead of hard-coding > its SHA256 digest, you could download the checksum file which is > signed using GnuPG and check its signature, as described on > https://alt.fedoraproject.org/cloud/ Yeah I saw that. Thats why I had that verify link in the TODO comment: https://alt.fedoraproject.org/en/verify.html > > Cheers, > Nicolas Thank you, appreciate your feedback ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Fedora VM On Travis for Testing 2020-05-14 21:00 ` Fedora VM On Travis for Testing William Roberts 2020-05-14 22:03 ` Nicolas Iooss @ 2020-05-14 22:20 ` Stephen Smalley 2020-05-14 22:31 ` William Roberts 1 sibling, 1 reply; 8+ messages in thread From: Stephen Smalley @ 2020-05-14 22:20 UTC (permalink / raw) To: William Roberts Cc: SElinux list, Paul Moore, Stephen Smalley, Nicolas Iooss, Jason Zaman, Steve Lawrence, Chris PeBenito, Jeffrey Vander Stoep, James Carter, Joshua Brindle, Ondrej Mosnacek, Petr Lautrbach On Thu, May 14, 2020 at 5:03 PM William Roberts <bill.c.roberts@gmail.com> wrote: > > I just wanted to lay out a demo of a Fedora 32 cloud VM image booting > on Travis with execution happening in the Fedora VM. > The Fedora VM contains the selinux source code for that particular > travis build, so it has the PR patches, etc. > The VM has networking. > > The build logs for the Travis run are here: > - https://travis-ci.org/github/williamcroberts/selinux/builds/687185489 > > Which comes from my git tree here: > - https://github.com/williamcroberts/selinux/tree/kvm-fedora-testing > > Note that it's super messy, I need to go through and cleanup both the > patch and the git > history. I also should verify the downloaded image is signed for the VM. > Also note that I may rebase/squash my git branch at any time. > > Petr started a release document here: > - https://github.com/bachradsusi/SELinuxProject-selinux/blob/RELEASE/RELEASE_PROCESS.md > > I'd like to gather feedback, and perhaps more comments on: > 1. Is this CI approach worth continuing? > 2. Comments on the CI scripts (I have no idea what I am doing, common issue) > 3. Comments, patches, suggestions on what tests to run in this CI environment. > 4. More information in in the RELEASE_PROCESS.md file. I made some > comments there > as well on ideas. > > My goal here is that a release can occur if CI is passing without > worry, and that > we automate manual steps as much as possible. This way, if we get hit by a bus > releases can occur without much effort. I'm amazed travis-ci supports all of that (especially for free). Hopefully you aren't violating their terms of use. The biggest thing I'd add is to build and install the selinux userspace in place of the stock Fedora versions (sudo make LIBDIR=/usr/lib64 SHLIBDIR=/lib64 install install-pywrap relabel) and then build and run the selinux-testsuite to exercise the SELinux userspace and kernel runtime functionality. Other things to possibly add would be rebuilding upstream refpolicy (similar to its .travis.yml) with the latest userspace, rebuilding and running setools (but until we decouple it from libsepol internals this will periodically break). ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Fedora VM On Travis for Testing 2020-05-14 22:20 ` Stephen Smalley @ 2020-05-14 22:31 ` William Roberts 2020-05-15 20:51 ` William Roberts 0 siblings, 1 reply; 8+ messages in thread From: William Roberts @ 2020-05-14 22:31 UTC (permalink / raw) To: Stephen Smalley Cc: SElinux list, Paul Moore, Stephen Smalley, Nicolas Iooss, Jason Zaman, Steve Lawrence, Chris PeBenito, Jeffrey Vander Stoep, James Carter, Joshua Brindle, Ondrej Mosnacek, Petr Lautrbach On Thu, May 14, 2020 at 5:21 PM Stephen Smalley <stephen.smalley.work@gmail.com> wrote: > > On Thu, May 14, 2020 at 5:03 PM William Roberts > <bill.c.roberts@gmail.com> wrote: > > > > I just wanted to lay out a demo of a Fedora 32 cloud VM image booting > > on Travis with execution happening in the Fedora VM. > > The Fedora VM contains the selinux source code for that particular > > travis build, so it has the PR patches, etc. > > The VM has networking. > > > > The build logs for the Travis run are here: > > - https://travis-ci.org/github/williamcroberts/selinux/builds/687185489 > > > > Which comes from my git tree here: > > - https://github.com/williamcroberts/selinux/tree/kvm-fedora-testing > > > > Note that it's super messy, I need to go through and cleanup both the > > patch and the git > > history. I also should verify the downloaded image is signed for the VM. > > Also note that I may rebase/squash my git branch at any time. > > > > Petr started a release document here: > > - https://github.com/bachradsusi/SELinuxProject-selinux/blob/RELEASE/RELEASE_PROCESS.md > > > > I'd like to gather feedback, and perhaps more comments on: > > 1. Is this CI approach worth continuing? > > 2. Comments on the CI scripts (I have no idea what I am doing, common issue) > > 3. Comments, patches, suggestions on what tests to run in this CI environment. > > 4. More information in in the RELEASE_PROCESS.md file. I made some > > comments there > > as well on ideas. > > > > My goal here is that a release can occur if CI is passing without > > worry, and that > > we automate manual steps as much as possible. This way, if we get hit by a bus > > releases can occur without much effort. > > I'm amazed travis-ci supports all of that (especially for free). > Hopefully you aren't violating their terms of use. Not that I am aware of and I read their terms of use. https://docs.travis-ci.com/legal/terms-of-service/ They don't seem to limit what you can do, it seems to be centered around availability, liability and support. I stumbled into other projects on github that were running virsh commands > The biggest thing I'd add is to build and install the selinux > userspace in place of the stock Fedora versions (sudo make > LIBDIR=/usr/lib64 SHLIBDIR=/lib64 install install-pywrap relabel) and > then build and run the selinux-testsuite to exercise the SELinux > userspace and kernel runtime functionality. Other things to possibly Perfect, that's the info I was looking for. > add would be rebuilding upstream refpolicy (similar to its > .travis.yml) with the latest userspace, rebuilding and running setools > (but until we decouple it from libsepol internals this will > periodically break). If it breaks, it breaks, just means we need to merge something or actually fix it properly IIUC. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Fedora VM On Travis for Testing 2020-05-14 22:31 ` William Roberts @ 2020-05-15 20:51 ` William Roberts 0 siblings, 0 replies; 8+ messages in thread From: William Roberts @ 2020-05-15 20:51 UTC (permalink / raw) To: Stephen Smalley Cc: SElinux list, Paul Moore, Stephen Smalley, Nicolas Iooss, Jason Zaman, Steve Lawrence, Chris PeBenito, Jeffrey Vander Stoep, James Carter, Joshua Brindle, Ondrej Mosnacek, Petr Lautrbach On Thu, May 14, 2020 at 5:31 PM William Roberts <bill.c.roberts@gmail.com> wrote: > > On Thu, May 14, 2020 at 5:21 PM Stephen Smalley > <stephen.smalley.work@gmail.com> wrote: > > > > On Thu, May 14, 2020 at 5:03 PM William Roberts > > <bill.c.roberts@gmail.com> wrote: > > > > > > I just wanted to lay out a demo of a Fedora 32 cloud VM image booting > > > on Travis with execution happening in the Fedora VM. > > > The Fedora VM contains the selinux source code for that particular > > > travis build, so it has the PR patches, etc. > > > The VM has networking. > > > > > > The build logs for the Travis run are here: > > > - https://travis-ci.org/github/williamcroberts/selinux/builds/687185489 > > > > > > Which comes from my git tree here: > > > - https://github.com/williamcroberts/selinux/tree/kvm-fedora-testing > > > > > > Note that it's super messy, I need to go through and cleanup both the > > > patch and the git > > > history. I also should verify the downloaded image is signed for the VM. > > > Also note that I may rebase/squash my git branch at any time. > > > > > > Petr started a release document here: > > > - https://github.com/bachradsusi/SELinuxProject-selinux/blob/RELEASE/RELEASE_PROCESS.md > > > > > > I'd like to gather feedback, and perhaps more comments on: > > > 1. Is this CI approach worth continuing? > > > 2. Comments on the CI scripts (I have no idea what I am doing, common issue) > > > 3. Comments, patches, suggestions on what tests to run in this CI environment. > > > 4. More information in in the RELEASE_PROCESS.md file. I made some > > > comments there > > > as well on ideas. > > > > > > My goal here is that a release can occur if CI is passing without > > > worry, and that > > > we automate manual steps as much as possible. This way, if we get hit by a bus > > > releases can occur without much effort. > > > > I'm amazed travis-ci supports all of that (especially for free). > > Hopefully you aren't violating their terms of use. > > Not that I am aware of and I read their terms of use. > https://docs.travis-ci.com/legal/terms-of-service/ > > They don't seem to limit what you can do, it seems to be centered > around availability, liability and support. > > I stumbled into other projects on github that were running virsh commands > > > The biggest thing I'd add is to build and install the selinux > > userspace in place of the stock Fedora versions (sudo make > > LIBDIR=/usr/lib64 SHLIBDIR=/lib64 install install-pywrap relabel) and > > then build and run the selinux-testsuite to exercise the SELinux > > userspace and kernel runtime functionality. Other things to possibly > > Perfect, that's the info I was looking for. > > > add would be rebuilding upstream refpolicy (similar to its > > .travis.yml) with the latest userspace, rebuilding and running setools > > (but until we decouple it from libsepol internals this will > > periodically break). > > If it breaks, it breaks, just means we need to merge something or actually > fix it properly IIUC. So I just wanted to share, that the test suite is running with a PASS on a travis CI instance with a nested KVM of Fedora32. https://travis-ci.org/github/williamcroberts/selinux/builds/687592735 Next week I'll clean this up and make sure that its working consistently. I've had 2 hangs when building the libselinux src, not sure why.. I don't want a CI check that'd flaky, so I want to do some more testing. An example is on this build: https://travis-ci.org/github/williamcroberts/selinux/builds/687496735 I'm gonna assume I need to allocate more memory and im gonna bump the vcpu count as well to match the host. As Travis gives us two cores. Bill ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-05-15 20:51 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-04-05 9:46 libsepol releases Russell Coker 2020-04-07 8:59 ` Petr Lautrbach [not found] ` <20200422065053.GA167999@workstation> [not found] ` <CAHC9VhQUmY=ue3zWdTnE1Ehi90Lj3077sLbu+jyaWoAVKuKyeQ@mail.gmail.com> [not found] ` <CAFftDdo1hqbacU2TD6zQp_t_KJq-KS5pWBMr89c4HA3=aUdUbQ@mail.gmail.com> [not found] ` <20200423150039.GC204116@workstation> 2020-05-14 21:00 ` Fedora VM On Travis for Testing William Roberts 2020-05-14 22:03 ` Nicolas Iooss 2020-05-14 22:23 ` William Roberts 2020-05-14 22:20 ` Stephen Smalley 2020-05-14 22:31 ` William Roberts 2020-05-15 20:51 ` William Roberts
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.