)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":28410,"name":"Scott Little","email":"scott.little@windriver.com","username":"slittle1"},"change_message_id":"f216ef474e296716fb17a40f2fef4db5e174194b","unresolved":true,"context_lines":[{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Kernel modules\u0027 signing keys are generated by kernel building"},{"line_number":10,"context_line":"dynamically. So They differ for every build."},{"line_number":11,"context_line":"By now our kernel modules\u0027 signature checking are enforced in secure"},{"line_number":12,"context_line":"boot mode. So make kernel modules\u0027 signing key permanent to avoid"},{"line_number":13,"context_line":"possible issues for kernel upgrading process when secure boot enabled."},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"BTW, fix the copyright missing issue of dl_hook for kernel-std."},{"line_number":16,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"8fefe319_57291dd9","line":13,"range":{"start_line":11,"start_character":0,"end_line":13,"end_character":70},"updated":"2022-11-07 17:39:58.000000000","message":"Traditionally we have always shipped a new set of modules with every new kernel.  The changing key ensures that the kernel and modules are properly matched.  This change would allow an old module to be used with a new kernel.  This may cause subtle hard to diagnose bugs.  \n\nI need to know why we are doing this.  What upgrade issues are you solving? Is there a LaunchPad?  A spec?  Point me to them.\n\nPlease set a review topic, or otherwise please point me at whatever other changes relate to this change.","commit_id":"739c16e03d2e973821af01ad32d3e5d880ace1ae"},{"author":{"_account_id":32832,"name":"Li Zhou","display_name":"Li Zhou","email":"li.zhou@windriver.com","username":"lzhou2"},"change_message_id":"c993e5c3c32fc68eff808886d9335add8f08edc4","unresolved":true,"context_lines":[{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Kernel modules\u0027 signing keys are generated by kernel building"},{"line_number":10,"context_line":"dynamically. So They differ for every build."},{"line_number":11,"context_line":"By now our kernel modules\u0027 signature checking are enforced in secure"},{"line_number":12,"context_line":"boot mode. So make kernel modules\u0027 signing key permanent to avoid"},{"line_number":13,"context_line":"possible issues for kernel upgrading process when secure boot enabled."},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"BTW, fix the copyright missing issue of dl_hook for kernel-std."},{"line_number":16,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"782284bf_48eab0b3","line":13,"range":{"start_line":11,"start_character":0,"end_line":13,"end_character":70},"in_reply_to":"8fefe319_57291dd9","updated":"2022-11-08 02:10:37.000000000","message":"I do this change to prepare for such a user case:\nThere is no change in kernel and there are some changes in the out of tree kernel modules. If the system patch for upgrading is built on a different project than the initial one, kernel will be forced to upgrade too, or else signature verification will fail.\nThe only way to avoid this issue is: we build every system patch for upgrading on the same project to avoid kernel rebuilding in this user case.\n\nSo, does centos stx make patches on the same project? \nWill debian stx make patches in this way too? \n\nThanks.","commit_id":"739c16e03d2e973821af01ad32d3e5d880ace1ae"}],"/PATCHSET_LEVEL":[{"author":{"_account_id":28652,"name":"Jim Somerville","email":"jim.somerville@windriver.com","username":"jsomervi"},"change_message_id":"eefc5ad9f7922d4641018700ee8f47a8556a2cf2","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"f001e4f8_62e0ea60","updated":"2022-11-04 21:20:13.000000000","message":"Adding Scott because he has some experience with this sort of thing and may have an opinion.","commit_id":"739c16e03d2e973821af01ad32d3e5d880ace1ae"},{"author":{"_account_id":32832,"name":"Li Zhou","display_name":"Li Zhou","email":"li.zhou@windriver.com","username":"lzhou2"},"change_message_id":"61bcac0bcd6f4146b3b01b7bcd3c5828e25db825","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"e6c1a98f_8be5248d","updated":"2022-11-29 08:12:20.000000000","message":"Email from Scott:\n\nAll official patches are built in a single persistent build environment.\n\nEvery kernel patch always rebuilds and ships all the kernel modules as well.\n\nA kernel module patch can be built independently of the kernel due to the persistent build environment.\n\nThe CentOS Build avoidance feature allowed a designer to avoid kernel rebuilds when developing a module patch in his own dev environment.  I assume the Debian builds --reuse feature can be used the same way, but perhaps we ned to test that.\n\nScott","commit_id":"739c16e03d2e973821af01ad32d3e5d880ace1ae"}]}