On Tue, Jul 16, 2013 at 11:04:19AM +0200, Jiri Kosina wrote: > - this doesn't seem to be explained *anywhere* in the changelog (please > correct me if I am wrong), and therefore completely invisible to > consumers of -stable branch, who are just going to be "ok, nice > /dev/random rework, but what the heck is it doing in -stable"? I plead guilty to this one. Even if we didn't want to go into great detail for security reasons, the explanation of why this patch was necessary in terms of other changes to the entropy gathering code would have been a good idea. > - was the rush really necessary? If I got the dates right, 3.6 (containing > big part of this) was released Sep 30th, first stable to contain this > was 3.0.41, released Aug 15th. With such a huge rework, it was likely > that there will be bug (and there indeed was). If the patches were kept > in mainline for a little longer, the bug will probably be fixed there, > and only then folded properly into -stable. I wasn't the one who pushed for these changes to be pushed to stable, so I can't speak authoratatively on what was the reason to get them to -stable. I assume that because it was considered a security problem, people thought there was urgency. In retrospect, it probably would depend a lot on who was using the stable tree; it has a lot of customers. If the goal was to make sure that various embedded device manufacturers might pick up the changes, it's much more likley that they would pick up changes from 3.0.40 to 3.0.41, than to jump to 3.6. OTOH, for enterprise distro kernels, most of those systems have plenty of entropy through other means, so perhaps it wouldn't be that critical. (Of course, many of the traditional enterprise distro companies are now dabbling with varying degrees of seriousness in the embedded/mobile/handset market, so maybe they would have wanted it anyway.) > But as it has been done this way, the bug was first discovered in > -stable and only then fixed in Linus' tree. To me, this clearly sounds > like failure of -stable process. They hit Linus's tree before v3.6-rc1 (which was released on August 2nd). That means it's not a failure of the -stable process, since they were in Linus's tree before 3.0.41 came out on August 15th. If you want to argue that patches shouldn't hit -stable until Linus releases a 3.x.0 final release containing the commits, that's a different argument; and we can have that discussion (I think it depends on the commit, myself) but what happened was consistent with the process in place at the time. > The buggy keys are spread all over the Internet already anyway, so > fixing this "now" or a 3 weeks later after much more testing is > performed doesn't really provide any additional security benefit anyway. Sure, but if we could get them out to embedded manufacturers sooner, before they cut a snapshot for devices targetting the Christmas gift buying season, I can see why there might be some urgency for getting it pushed to 3.x in a hurry. I wasn't involved with those discussions, though, so I don't know whether or not there was some reason why there was urgency to get them out to the stable kernels, or this was a case of "it's post -rc1, let's get all of the bug fixes that were justy merged pushed to stable ASAP!" Regards, - Ted -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html