Menu
▾
▴
audit-test-developer
|
From: Jiri J. <jja...@re...> - 2018-04-30 15:54:53
|
Hello, I'm not sure if anybody is still watching this as this project (at least this upstream) seems dead these days, possibly due to the nature of the project. Anyway, I've just pushed the audit-test suite version shipped with RHEL-7.1 (in the cc-config-rhel71 RPM) to the rhel7_1 branch. Maybe it'll be useful to somebody. Our plans were to move this project over to Github, but I'm not sure it's worth it - it might be better to just let it die on sourceforge. I have left the 'master' branch untouched as the rhel7_1 changes aren't 100% compatible and we don't have the resources dedicated to a full review / comments / maintenance / etc. in case any issues arise. Finally, if you would like to work further on this, please let us know. Thanks, Jiri PS: I have also made rhel5_6_testing into a tag instead of a branch. |
|
From: Paul M. <pa...@pa...> - 2018-05-01 15:30:52
|
On Mon, Apr 30, 2018 at 11:54 AM, Jiri Jaburek <jja...@re...> wrote: > Hello, > I'm not sure if anybody is still watching this as this project (at least > this upstream) seems dead these days, possibly due to the nature of the > project. > > Anyway, I've just pushed the audit-test suite version shipped with > RHEL-7.1 (in the cc-config-rhel71 RPM) to the rhel7_1 branch. > Maybe it'll be useful to somebody. > > Our plans were to move this project over to Github, but I'm not sure > it's worth it - it might be better to just let it die on sourceforge. > > I have left the 'master' branch untouched as the rhel7_1 changes > aren't 100% compatible and we don't have the resources dedicated to > a full review / comments / maintenance / etc. in case any issues arise. > > Finally, if you would like to work further on this, please let us know. > > Thanks, > Jiri > > > PS: I have also made rhel5_6_testing into a tag instead of a branch. I guess my question is do you expect to continue using this in the future for CC certification efforts? If the answer is "yes" then I think it might make sense to eventually move the tests to GH, if the answer is "no" then I think simply preserving the tests on SF.net is fine. -- paul moore www.paul-moore.com |
|
From: Cyril H. <ch...@su...> - 2018-05-02 14:33:22
|
Hi! > I'm not sure if anybody is still watching this as this project (at least > this upstream) seems dead these days, possibly due to the nature of the > project. > > Anyway, I've just pushed the audit-test suite version shipped with > RHEL-7.1 (in the cc-config-rhel71 RPM) to the rhel7_1 branch. > Maybe it'll be useful to somebody. > > Our plans were to move this project over to Github, but I'm not sure > it's worth it - it might be better to just let it die on sourceforge. > > I have left the 'master' branch untouched as the rhel7_1 changes > aren't 100% compatible and we don't have the resources dedicated to > a full review / comments / maintenance / etc. in case any issues arise. For what it's worth we do have a repo with SUSE specific patches here as well, but given the state of the project we have given up on upstreaming it and I doubt that this will change anytime soon. -- Cyril Hrubis ch...@su... |
|
From: Paul M. <pa...@pa...> - 2018-05-03 20:47:20
|
On Wed, May 2, 2018 at 10:31 AM, Cyril Hrubis <ch...@su...> wrote: > Hi! >> I'm not sure if anybody is still watching this as this project (at least >> this upstream) seems dead these days, possibly due to the nature of the >> project. >> >> Anyway, I've just pushed the audit-test suite version shipped with >> RHEL-7.1 (in the cc-config-rhel71 RPM) to the rhel7_1 branch. >> Maybe it'll be useful to somebody. >> >> Our plans were to move this project over to Github, but I'm not sure >> it's worth it - it might be better to just let it die on sourceforge. >> >> I have left the 'master' branch untouched as the rhel7_1 changes >> aren't 100% compatible and we don't have the resources dedicated to >> a full review / comments / maintenance / etc. in case any issues arise. > > For what it's worth we do have a repo with SUSE specific patches here as > well, but given the state of the project we have given up on upstreaming > it and I doubt that this will change anytime soon. It seems a shame that we can't combine efforts to maintain a common repository. Personally I think moving away from a common repository, even if it is one with distro-specific branches, is a big step backwards. What would it take to get folks to start contributing again? Is it as simple as moving to GH? -- paul moore www.paul-moore.com |
|
From: Cyril H. <ch...@su...> - 2018-05-15 12:49:19
|
Hi! > It seems a shame that we can't combine efforts to maintain a common > repository. Personally I think moving away from a common repository, > even if it is one with distro-specific branches, is a big step > backwards. > > What would it take to get folks to start contributing again? Is it as > simple as moving to GH? I guess that it's too late for past releases, I doubt that anybody would allocate resources for merging SLE12 related changes to upstream at this point. For the record we tried to upstream at least some of the changes but we have given up because there was no real upstream. What we need is a someone who reviews and applies patches and maybe then we can get most of the fixes upstream when we start working on next certification. -- Cyril Hrubis ch...@su... |
|
From: Paul M. <pa...@pa...> - 2018-05-16 21:56:20
|
On Tue, May 15, 2018 at 8:46 AM, Cyril Hrubis <ch...@su...> wrote: > Hi! >> It seems a shame that we can't combine efforts to maintain a common >> repository. Personally I think moving away from a common repository, >> even if it is one with distro-specific branches, is a big step >> backwards. >> >> What would it take to get folks to start contributing again? Is it as >> simple as moving to GH? > > I guess that it's too late for past releases, I doubt that anybody would > allocate resources for merging SLE12 related changes to upstream at this > point. What if we simply created a SLE12 specific branch in the upstream repo? I admit that it is unlikely anyone will spend a significant portion of time towards merging the entire set of changes, but there is always the possibility that there could be some smaller changes which are easy to merge and generally applicable. If nothing else it consolidates everything in one place which I think would be beneficial for everyone. > For the record we tried to upstream at least some of the changes but we > have given up because there was no real upstream. What we need is a > someone who reviews and applies patches and maybe then we can get most > of the fixes upstream when we start working on next certification. Ask not what you upstream can do for you, ask what you can do for upstream. ;) Would you be willing to work with Jiri to help reinvigorate the upstream effort? At the very least, what about distro/release specific branches? Jiri, what do you think? I'm trying to avoid the situation we had in the early days of the Linux CC effort where test development was done in private and there was a *lot* of duplicated effort. -- paul moore www.paul-moore.com |
|
From: Jiri J. <jja...@re...> - 2018-05-17 09:44:13
|
On 05/16/18 23:48, Paul Moore wrote: > On Tue, May 15, 2018 at 8:46 AM, Cyril Hrubis <ch...@su...> wrote: >> Hi! >>> It seems a shame that we can't combine efforts to maintain a common >>> repository. Personally I think moving away from a common repository, >>> even if it is one with distro-specific branches, is a big step >>> backwards. >>> >>> What would it take to get folks to start contributing again? Is it as >>> simple as moving to GH? >> >> I guess that it's too late for past releases, I doubt that anybody would >> allocate resources for merging SLE12 related changes to upstream at this >> point. > > What if we simply created a SLE12 specific branch in the upstream repo? > > I admit that it is unlikely anyone will spend a significant portion of > time towards merging the entire set of changes, but there is always > the possibility that there could be some smaller changes which are > easy to merge and generally applicable. If nothing else it > consolidates everything in one place which I think would be beneficial > for everyone. > >> For the record we tried to upstream at least some of the changes but we >> have given up because there was no real upstream. What we need is a >> someone who reviews and applies patches and maybe then we can get most >> of the fixes upstream when we start working on next certification. > > Ask not what you upstream can do for you, ask what you can do for upstream. ;) > > Would you be willing to work with Jiri to help reinvigorate the > upstream effort? At the very least, what about distro/release > specific branches? Jiri, what do you think? I unfortunately don't think I have the time needed to do upstream work for the project. I also don't think it's really worth putting the effort in - these days, you have things like https://github.com/SELinuxProject/selinux-testsuite https://github.com/linux-audit in addition to LTP and other projects. Keeping a project that exist as a blend of everything for the only and sole purpose of doing EAL4 alive as upstream is IMHO not realistic. Anyone who would like to help the overall Linux testing effort in general will likely contribute to LTP instead. That being said, the pushed RHEL-7.1 changes are only a very small portion of the work I've done on the suite and I have about 260 commits "sidestepping" it for generic Fedora testing. In that branch, I rewrote the entire network-server logic using a modular TCP server with proper locking logic everywhere in the suite, re-did the syscall relevancy logic and generally updated the whole suite to be more relevant to bleeding-edge distros. I'll see if I can get that published somewhere (here or on my github account), for posterity and code copy/pasting if nothing else. Jiri > > I'm trying to avoid the situation we had in the early days of the > Linux CC effort where test development was done in private and there > was a *lot* of duplicated effort. > |
|
From: Cyril H. <ch...@su...> - 2018-05-18 09:46:36
|
Hi! > >> It seems a shame that we can't combine efforts to maintain a common > >> repository. Personally I think moving away from a common repository, > >> even if it is one with distro-specific branches, is a big step > >> backwards. > >> > >> What would it take to get folks to start contributing again? Is it as > >> simple as moving to GH? > > > > I guess that it's too late for past releases, I doubt that anybody would > > allocate resources for merging SLE12 related changes to upstream at this > > point. > > What if we simply created a SLE12 specific branch in the upstream repo? I would have to confirm if it's okay to release the patches and locate the git repository but I suppose that this would be doable at least. > I admit that it is unlikely anyone will spend a significant portion of > time towards merging the entire set of changes, but there is always > the possibility that there could be some smaller changes which are > easy to merge and generally applicable. If nothing else it > consolidates everything in one place which I think would be beneficial > for everyone. The biggest problem would be locating these in the pile of, quite often unclean, patches. > > For the record we tried to upstream at least some of the changes but we > > have given up because there was no real upstream. What we need is a > > someone who reviews and applies patches and maybe then we can get most > > of the fixes upstream when we start working on next certification. > > Ask not what you upstream can do for you, ask what you can do for upstream. ;) > > Would you be willing to work with Jiri to help reinvigorate the > upstream effort? At the very least, what about distro/release > specific branches? Jiri, what do you think? To be completely honest here, I do have enough on my plate with maintaing LTP upstream. Hence unfortunately I do not have any resources for doing patch review for another upstream project. > I'm trying to avoid the situation we had in the early days of the > Linux CC effort where test development was done in private and there > was a *lot* of duplicated effort. Given that there are upstream repositories for audit and selinux it would probably makes sense to reuse these for the certification purposes in the long term. -- Cyril Hrubis ch...@su... |
|
From: Paul M. <pa...@pa...> - 2018-05-18 15:18:44
|
On Thu, May 17, 2018 at 5:44 AM, Jiri Jaburek <jja...@re...> wrote: > I unfortunately don't think I have the time needed to do upstream work > for the project. I also don't think it's really worth putting the effort > in - these days, you have things like > > https://github.com/SELinuxProject/selinux-testsuite > https://github.com/linux-audit > > in addition to LTP and other projects. On Fri, May 18, 2018 at 5:43 AM, Cyril Hrubis <ch...@su...> wrote: > Given that there are upstream repositories for audit and selinux it > would probably makes sense to reuse these for the certification purposes > in the long term. Granted my CC evaluation experience is quite old at this point, but I don't believe the current selinux-testsuite and audit-testsuite are sufficient, or even close to being sufficient, for CC evaluation. While I think both of those test suites could benefit from addition tests, the audit-testsuite is especially lacking, I believe that adding the tests necessary for CC certification is out-of-scope for those test suites. There is a reason why I started maintaining those test suites again and didn't attempt to use the audit-test suite. Regardless, it looks like the larger problem is a lack of resources needed to maintain the audit-test test suite. That's unfortunate, but I don't see any way to change that. -- paul moore www.paul-moore.com |
Thanks for helping keep SourceForge clean.
X