[Summary] MIR Team Ack no security evaluation needed. Notes: - It was stated that tests on cloud instance types happened, it would be nice to hear if this will be done continuously in some place (e.g. on image publish)? - Is there any chance this conflicts with normal use cases like alice&bobs laptops. If so should we add conflicts to avoid that?
[Duplication] It is a vehicle to get intel-microcode and amd64-microcode loaded and going in cases they are not yet. This means that this is only a hook to get it processed - all the heavy lifting eventually is done by the microcode packages themselves. There is no other package in main providing the same functionality (under the special conditions this targets). The VCS links point to non existing https://salsa.debian.org/debian/microcode-initrd and copyright mentioned 2012-2016 Henrique de Moraes Holschuh, so there might ne same/similar code in Debian in other places? He is the maintainer of the two depended -microcode packages. This then becomes clear on the comment "based on intel-microcode & amd64-microcode initramfs-tools hooks". Ok in that case the functionality really isn't present already for the corner case this tries to cover. [Dependencies] OK: - no other Dependencies to MIR due to this (intel-microcode, amd64-microcode) - no -dev/-debug/-doc packages that need exclusion [Embedded sources and static linking] OK: - no embedded source present - no static linking [Security] OK: - history of CVEs does not look concerning - does not run a daemon as root - does not use webkit1,2 - does not use lib*v8 directly - does not parse data formats - does not open a port - does not process arbitrary web content - does not use centralized online accounts - does not integrate arbitrary javascript into the desktop - does not deal with system authentication (eg, pam), etc) It doesn't have enough history for CVEs but it is essentially an apply-vehicle for the microcode. There are other such means for already common setups, this just adds a new vector to apply the microcode. So the CVEs and such would be on those microcode packages already (and they are fine for now). [Common blockers] OK: - does not FTBFS currently - The package has a team bug subscriber (Foundations is already subscribed) - no translation present, but none needed for this case (user visible)? - not a python/go package, no extra constraints to consider int hat regard - no new python2 dependency Problems: - does have a test suite that runs at build time - test suite fails will fail the build upon error. - does have a test suite that runs as autopkgtest => This will be tested as part of the image delivery to azure and already stated to be tested that way - this won't be boot or autopkgtest testable anyway I guess. [Packaging red flags] OK: - Ubuntu does not carry a delta - symbols tracking not applicable for this kind of code. - d/watch is present and looks ok - Upstream update history is irrelevant (we are upstream) - Ubuntu update history is yet unknown - the current release is packaged - promoting this does not seem to cause issues for MOTUs that so far maintained the package - no massive Lintian warnings - d/rules is rather clean - Does not have Built-Using [Upstream red flags] OK: - no Errors/warnings during the build - no incautious use of malloc/sprintf - no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH - no use of user nobody - no use of setuid - no important open bugs (crashers, etc) in Debian or Ubuntu - no dependency on webkit, qtwebkit, seed or libgoa-* - no embedded source copies - not part of the UI for extra checks ** Changed in: microcode-initrd (Ubuntu) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1895200 Title: [MIR] microcode-initrd To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-meta-aws/+bug/1895200/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
