On Tue, Jun 27, 2017 at 02:29:33PM +0100, Dimitri John Ledkov wrote: > There is no way to distinguish changes of each microcode, what it > does, and which bugs it fixes and to create templates on how to > reproduce and validate each bug / vulnerability that is fixed. My > understanding is that normal SRU process is there to document every > change that goes into distribution, and validates that only the > changes to fix those particular issues go in, and that the bugs an > update claims to fix, are in fact actually fixed.
I am not asking for SRU documentation for the microcode update itself. Again, you're failing to distinguish between the microcode update and the changing of the packaging around it. I declined to accept the uploads not because of the microcode being changed, but because of the SRU-undocumented packaging changes around it. > This normal SRU process is not followed for an undocumented set of > packages. And imho intel-microcode should be part of that set. For expected ongoing exceptions, the SRU team has resolved to document them, since that way we can be consistent about what we expect for those updates, making things easier for developers by not surprising them with extra requirements every time some other SRU team is asked to review an upload. Let's not make the problem worse by adding to the undocumented set. Whatever conclusion is reached in this thread, we should make sure to document it. > > Maintaining distinct lines of packaging on a per-series basis is exactly > > what we choose do in Ubuntu by choosing to maintain multiple stable > > That clearly is not done for many packages that land in the updates > and security pockets. I have provided multiple examples of wholesale > backports landing into updates pocket which clearly do not maintain > minimal per-series changes. I fail to see any justification here for these uploads to be accepted. > > I'd appreciate opinions from other SRU team members. But I don't > > understand why you aren't prepared to seek a documented, ongoing > > exception. Isn't that what you want anyway? > > > > I believe I am already following the existing document process of hwe > feature backports to updates pocket. I understand the confusion, and for this reason I added to the documentation earlier this month. See "To obtain a new ongoing exception..." under "Documentation for Special Cases". If, rather than an ongoing exception, it's a one-off, then surely a blob-only update should be fine. > > personally I remain unconvinced. If the security team agree with you > > that it is, then shouldn't this be going in via the security pockets and > > be moot from an SRU policy perspective? Could you please decide which it > > is, getting agreement from the security team if required, to avoid > > further confusion? > > > > Upstream (Intel) are not following normal Linux security / CVE > disclosure process. It is unknown how many security vulnerabilities > microcode updates fix. It is prudent to assume it is an unsigned > integer value of more than zero. Then please get the security team to agree and then use the security upload process to get it fixed, rather than the SRU process. Robie
signature.asc
Description: PGP signature
-- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
