Use case: Users behind a firewall or other restricted access lab could use an updated kernelinfo.xml and we would prefer not to spin a new package for the sole purpose of a new kernel has been released. Expected results: A kernelinfo.xml could be hosted on an internal server similar to the fv images allowing the info test to verify the GA kernel version info. Additional info: We could add a signature check to verify remove files including this xml (which is a reasonable idea anyway). The purpose isn't security as in saftey but more to verifying it's the content we expect/know since we do not have rpm verify to use. This could apply to fv images too or anything else we call home to retrieve. (Should this be a separate bug/feature?) We can also allow for a manually edited version with a warning or error the catalog/review team can catch but also provide a warning to the local user so they can address it before they do a bunch of testing against a bad file.
Looks ok to me, although I think the "hosting on the intranet" part is overcomplicating things. Just having a defined location on the local filesystem where an updated kernelinfo.xml might exist would be easier to use.
(In reply to comment #1) > Looks ok to me, although I think the "hosting on the intranet" part is > overcomplicating things. Just having a defined location on the local > filesystem where an updated kernelinfo.xml might exist would be easier to > use. This already exists in a way but it will cause the rpm -V of v7 to fail. I think if we just fully mimic the fv structure; which supports, RH hosted, $server hosts, and local hosted images; we'll cover all of the bases. Greg, should I open another bug for local filesystem provided kernelinfo.xml? Should the signing infrastructure be in it's own bug?
Singning and verifying the signature with a gpg pubkey which is part of the v7 suite sounds like a sane method indeed. Alternatively we could put the updated kernelinfo.xml into a separate rpm (but I favor the signature piece).
We've split off kernelInfo.xml into it's own package: hwcert-client-info. The info test verifies both hwcert-client and hwcert-info. I believe this satisfies the locally-hosted option, as the packages can be locally-hosted.
Should this bug be retitled?
I think so.