https://bugzilla.redhat.com/show_bug.cgi?id=1304882 awilliam@xxxxxxxxxx <awilliam@xxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mgrepl@xxxxxxxxxx, | |zbyszek@xxxxxxxxx --- Comment #1 from awilliam@xxxxxxxxxx <awilliam@xxxxxxxxxx> --- I was kinda planning to clean this up a bit and comment some things before submitting the review request, but I figured I could submit what I had and we can go from there. This is the exact package currently in use on https://openqa.fedoraproject.org/ . As with os-autoinst the spec is based on the openSUSE one and I'd like to keep it similar as far as possible, to make it easy to sync back future changes from them. One particular note, explaining this line: %requires_eq perl-Mojolicious-Plugin-Bootstrap3 perl-Mojolicious-Plugin-AssetPack and this chunk: # strange way to precompile assets :) ./script/initdb --init_database ./script/openqa version -m production cp -a public/packed %{buildroot}%{_datadir}/openqa/public/ openQA uses a web framework (Mojolicious) with an asset management plugin (AssetPack), and a plugin that basically just provides Bootstrap in an AssetPack-y way (Bootstrap3). The way this is kinda envisioned to work is that the app will 'compile' the needed assets on-demand - that is, bundle up all the CSS and JS bits it actually needs into single, minified files - and keep them around, tracking whether the source files have changed with checksums, and re-generating the minified and flattened copies when the source files change. The SUSE guys decided to handle it a bit differently: they make it so the app has no write permissions to the directory where the app stores the assets when run normally, and pre-create the minified+flattened assets by running it as root during the package build. The reason for doing this is to reduce the security exposure of the webapp, which seems like a pretty reasonable point to me. The tradeoff is that if the source files change, the webapp will notice and try to recompile the flattened assets, but it will fail because it can't write to the asset directory. This is why the package has that %requires_eq line. "%requires_eq foo" creates a dependency on the exact EVR of 'foo' that was installed at the time of the package build. So by having %requires_eq for Bootstrap3 and AssetPack, any time those packages (which provide the source assets) are updated, openQA's deps will break, cueing us to rebuild it (whereupon the assets included in the package will be the correct ones again). If we were to just go ahead and let the app write to the asset dir we could simplify the spec file and avoid the need to rebuild the package any time Bootstrap3 or AssetPack changed, but I do think there's a valid point about potential security exposure by allowing the server to write files it will later serve out to clients for execution. So I'm kinda on the fence about this one and willing to hear reviewers' thoughts. On this topic - I do want to build an SELinux policy for openQA, but a) I haven't had time to yet and b) I can't really do a proper one until the selinux-policy folks look at https://bugzilla.redhat.com/show_bug.cgi?id=1277312 . Right now the actual openQA webapp runs unconfined (as it's a separate process which a full-fat web server is intended to reverse proxy, as in the included sample Apache configuration). CCing Zbyszek (as he's kindly reviewed several things for me, including os-autoinst, openQA's underlying test runner) and mgrepl for thoughts on SELinux. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review