On Wed, Dec 18, 2019 at 02:52:03PM -0500, Robbie Harwood wrote:
David Cantrell <dcantrell@xxxxxxxxxx> writes:On Tue, Dec 17, 2019 at 11:21:45PM +0100, Miro Hrončok wrote:On 17. 12. 19 21:57, David Cantrell wrote:1) Are modules allowed to bundle packages that are provided by and currently maintained in the base system? Are there are restrictions to what a module can bundle (e.g., can a module bundle glibc)?I am not aware of any policy against modularizing existing packages. Modular maintainers can module-bundle glibc. OTOH I don't know all the policies. There is a policy for making a default modular stream: if it overrides existing non-modular packages, it requires FESCo approval. So far this has not been retroactive and the ant and maven default modular streams do that. See also https://pagure.io/modularity/issue/170I feel there should be some restrictions around this bundling. glibc is a good example, but I am also concerned about the ability for modules to bundle security-libraries which could lead to a system with multiple different versions of a shared library on a system. With protobuf as the example again, we saw that the eclipse module's bundled protobuf took the lead in depsolving and dnf upgraded systems to that regardless of whether or not they had the module installed. So the multiple shared library scenario is only a concern in a world where we do parallel installability. Putting that aside for the moment, I'd like to refine the above concern: We should have some restrictions about packages that can and cannot be bundled with modules. This may require defining some sort of criteria or a set of core packages or some other test. Likewise, packages like openssl need some thought because while we do not currently do parallel installability, even having parallel availability still means we could have multiple different builds of an openssl package. There should be a plan around that because having that be unbounded sets us up for a lot of panic mode work should there be something like Heartbleed happen again.Agreed. Especially with the work we do on crypto deprecations, I worry that there will be strong temptation to create bundled crypto packages that "make the old workflow work again" or so.
That's exactly my thought as well.
2) Using protobuf as an example, if a bug is found by a user and they happen to deduce that the error is in protobuf, how do they file a bug? Do they file the bug against protobuf if the bundled one from the module has the issue? What maintainer is on the hook for handling that bug report? My assumption here is that the module maintainer is ultimately responsible for everything they bundle. Another concern I see here is we are opening ourselves up for N+1 different builds of protobuf where N is the number of modules installed on a system and all of them could have protobuf bundled.I would assume they file it in protobuf. They haven't opted for any module and they don't know it's modular, really. The non-modular maintainer may deduce from the NERVA that it is modular build and do some nontrivial digging to figure out where is this package coming from - if they can, they will reassign the bug report to that module component. I agree that the modular maintainers are ultimately responsible for everything they bundle. I share your concerns.Filing against protobuf makes sense, but then we get to the maintainers. The protobuf maintainer did not know eclipse bundled protobuf. Without being involved in that decision, I think it's unfair to expect package maintainers to be the triage point for all incoming bugs, either regular packages or bundled packages. That's just not going to really scale very well and will result in frustration among package maintainers and users. Maybe if a module bundles a package, the module maintainer also becomes a co-maintainer on the bundled package?This worries me because I don't think we have sufficiently fine-grained commit controls since the pkgdb retirement. While I would love to be incorrect about this, I don't see a way to restrict what branches can be committed to by those with access to a package - and I don't think it's at all reasonable for someone who makes a module version of a package to gain commit bits to all branches. (Especially without consent of the existing maintainer(s).)
All reasonable concerns. I don't think we have the necessary controls in place for this either. In my mind I was thinking a discussion like this would involve both "do we think this is a good idea to implement" as well as "how would our tools need to change to allow that". An important part of this is communication so that module maintainers know who the regular package maintainer is (e.g., for coordinating work, etc) and that regular package maintainers know what modules are bundling the package at different points. I'm still not convinced this is a good workflow for all software we ship, but may be an ok mechanism for large things. That is, be the exception rather than the norm.
5) How are CVEs handled for packages that are also bundled with a module?I don't think they are reported properly. Hence they are handled on the modular maintainer's discretion. See also https://pagure.io/modularity/issue/169I would like to see modules have a stronger policy around tracking and handling CVEs. At the very least, what Fedora already does for regular packages.I would like this as well, but don't think "what Fedora already does for regular packages" is sufficient here. To criticize process (and only process, not people) for a moment here: Right now, the impetus for CVEs to be fixed[1] comes solely from the maintainer. Unless the CVE becomes a buzzword issue with a name and logo (Heartbleed has already been mentioned upthread), there are basically no consequences to not fixing CVEs in one's packages until non-responsive maintainer bugs start getting filed. There doesn't seem to be any monitoring of these, and unlike FTBFS bugs, they're not grounds for removing packages from the distro. I don't want to put blame on anyone for this, of course - if it were easy to fix we would have done it already. My understanding is that a lot of the problems I described above are due to lack of capacity to perform the work associated. Asking the folks performing security-related tasks in the distro - who are already overloaded - to perform even more work does not strike me as a good idea. There needs to be an easy way for them to query what versions of what packages are present in Fedora - anywhere in Fedora - and file bugs against all of them individually such that they reach the correct maintainers without additional triage. Thanks, --Robbie 1: Often, even knowing that CVEs exist also requires the maintainer to be paying attention to upstream development. This is because tracker bugs are often missing, and usually late when they are created - in many cases, after the issue in question has already been fixed.
Sorry, I over-simplified my comment. My main concern here is that modules are opening up a risk for security vulnerabilities and we lack the tools to know what packages are at risk and whether or not users know if they are vulnerable or not. I personally don't like this and want Fedora to provide me with the tools to know where my software came from and what the versions are. When I suggested "what Fedora does for regular packages", I was referring to the work that everyone already does above and beyond. I think this is worth a separate discussion. While security updates in Fedora are handled well now and I trust the builds, it's due to the above and beyond work of maintainers and not by some process we have in place. It's the process I would like to capture because modules make this situation worse in my mind. Using Heartbleed as an example again, right now if something of that scale happened again I can trust that updates will be available for Fedora. But what if we have 392 modules each with a different bundled version of openssl? And what if only some of them are vulnerable to the new problem? Without any kind of policy in place, what does that look like for the end user? Will module maintainers also be aware of CVEs for packages they bundle? Will they handle those updates? Should we expect them too? Your comments above touch on this as well. Thanks, -- David Cantrell <dcantrell@xxxxxxxxxx> Red Hat, Inc. | Boston, MA | EST5EDT
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
