Developments
In this section the people, personalities and debates on the @fedora-devel mailing list are summarized.
Contributing Writer: Oisin Feeley
Security Exceptions to the Mass ACL Opening
MichaelDeHaan initiated[1] discussion on why he had chosen not to open access (previously covered in FWN#148[2], FWN#136[3]) on some of his systems management software packages. His main reasoning was that obtaining provenpackager[4] status was too easy and could lead to at least two undesirable security outcomes: "(A) provenpackager decides to correct what he thinks is an rpmlint error and thus unintentionally breaks the security of the packaged application, (B) credentials of provenpackager are compromised allowing $evil to replace the contents of a said package. In either case, the change could either be making a new release of an application (which contains an exploit and/or unwitting bug), or updating the specfile in a way that breaks file permissions in a way that may not be immediately obvious (whether intentional or not)." The packages omitted by Michael were koan, cobbler, func and certmaster all of which could, if compromised, "[...] allow reprogramming of an entire datacenter in very easy steps."
[1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00382.html
[2] http://fedoraproject.org/wiki/FWN/Issue148#The_Big_ACL_Opening
[3] http://fedoraproject.org/wiki/FWN/Issue136#New_libraw1394_Rebuild_Exposes_Closed_ACLs
[4] After a flamewar (see FWN#148 "PackageGurus, SpecMentats or UeberPackagers?") the group name for packagers with access to any package in CVS is provenpackager: https://fedorahosted.org/packagedb/browser/fedora-packagedb-stable/ChangeLog#L45
Toshio Kuratomi shared[5] Michael's concerns but pointed out that it would be possible to introduce compromised code into his packages' dependencies: "I'd like to mention, though, that func depends on the following packages with open acls: pyOpenSSL, python, python-simplejson So in terms of protecting against $EVIL, restricting provenpackager isn't very effective."
[5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00384.html
Daniel Berrange thought[6] it would be more effective to have more co-maintainers: "The ideal should be for every package in the distro to have at least 1 extra comaintainer, or preferrably 3 or 4. People with a little domain knowledge for the package who can handle both the low-hanging fruit the main maintainer misses, with less risk of making mistakes due to lack of package specific knowledge." Toshio countered[7] with a detailed reply which investigated the problems of non-responsiveness and trust which would be encountered by such a change. Michael Schwendt added[8] his experiences of the practical problems involving non-responsive maintainers and the difficulty of informing people without overloading them.
[6] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00387.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00392.html
[8] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00405.html
Jesse Keating returned[9] to the main topic and remarked that he agreed with Michael DeHaan's logic with regard to these specific packages but that membership of "provenpackagers" was now obtainable by requesting membership via the account system and approval of said request by a provenpackager. The requirement to have at least five packages was merely for initial seeding.
[9] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00385.html
Tim Lauridsen wondered[10] when co-maintainers would be enabled to submit updates to packages through bodhi and subsequent discussion with Michael Schwendt suggested that it should be possible. Kevin Kofler had similar concerns and Michael shared[11] the last public information on the topic which was that anyone with commit access to the devel branch can submit updates.
[10] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00407.html
[11] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00411.html
Who Moved My Bug ?
Debarshi Ray's question sounded[1] alluringly like a parody of a self-help book but expressed genuine concern over why the status of bugs assigned to him were being changed. Till Maas reassured[2] Debarshi that the status ASSIGNED means "that the bug has been triaged, i.e. it is assigned to the rigth component and all necessary information is provided. A member of the Fedora Triage Team probably did the changes to your bugs [,]" he included a useful link[3] to the BugZappers wikipage. Bryn Reeves explained[4] how to see every change made to a bug. John Poelstra also suggested[5] using the "history" link and explained that the use of the "FutureFeature" keyword was to insure that bugs would continue to be given the version "rawhide" even after the GA release of Fedora 10.
[1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00273.html
[2] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00274.html
[3] https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow
[4] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00279.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00290.html
It appeared[6] that this was a different process to that used to handle package review submissions and this had difference had caused some confusion. Confusion also reigned[7] about when this use of the ASSIGNED keyword had become standard and Dominik Mierzejewski argued[8] that it had not been approved by FESCo, but Brian Pepple posted the FESCo logs and Jesse Keating suggested[9] following the discussions on @fedora-devel. Dominik declined to rely on following such a high-volume list and Steve Grubb agreed[10].
[6] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00325.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00285.html
[8] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00285.html
[9] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00310.html
[10] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00420.html
Kevin Kofler added[11] some useful information for those working in teams: "[...] when you're actively working on fixing something (so you don't duplicate work in the team), you can use the ON_DEV status for that purpose."
[11] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00283.html
HOWTO: Get an SELinux Policy Change
Jerry James requested[1] information on how to get the correct security context in place for the GCL binaries which he was packaging. He needed to know both whether it was acceptable to use a chcon -t java_exec_t within the Makefile and how to have this reflected explicitly in Fedora policy.
[1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00259.html
Hans de Goede suggested[2] filing a bug against selinux-policy as Dan Walsh was "[...] usually very fast and correct in fixing issues like this one." Dan posted that Jerry could get the final destination of the file with a chcon .
matchpathcon -n /usr/bin/gcl LOCALPATH/gcl
[2] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00261.html
Jochen Schmitt suggested[3] that Jerry create a SELinux module to fix the issue and then actually did it himself and shared[4] it with the list, which impressed Jerry.
[3] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00289.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00294.html
The problem evolved[5] to be a little deeper than modifying the Makefile as Jerry explained[6]: "I need a non-default security context for binaries that are both built and executed in the %build script, when the policy module has not yet been installed. It appears to me that there are only two ways to accomplish this: keep abusing java_exec_t like I have been, or get a GCL policy incorporated into selinux-policy* prior to building GCL. Am I wrong?" After Paul Howarth pointed out that selinux-policy needed to provide a context type for /usr/bin/gcl Dan modified[7] his previous matchpathcon suggestion and advised that this would be provided in selinux-policy-3.5.13-19.fc10.
[5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00307.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00350.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00367.html
Comps Czar Appointed to Encourage Modifications
An important decision made[1] by FESCo in its 2008-10-29 deliberations was to try and encourage further modification of comps.xml[2] by defining some clearer procedures. These included the appointment of Bill Nottingham as a "Grand Arbitrator of Comps" to decide which packages should be included in comps. The main concern expressed during the deliberation was that packagers tended not to modify comps and that awareness of its purpose had not been clearly communicated. It was hoped that extending the wiki page[3] and making one person formally responsible would help. Currently there are filters in place and only those with uberpackager status can commit changes. Jesse Keating (f13) wanted to "[...] rather correct bad behavior than prevent good behavior [.]"
[1] http://bpepple.fedorapeople.org/fesco/FESCo-2008-10-29.html
[2] Comps is an XML file which is used by anaconda (the installer) to present groups of available packages for selection by the administrator during the installation of a new operating system. See: https://fedoraproject.org/wiki/PackageMaintainers/CompsXml
[3] https://fedoraproject.org/wiki/PackageMaintainers/CompsXml
One worry was to ensure that not everything is added to comps as this would produce an unreadable, large list. This latter problem was foregrounded when Christopher Stone advocated[4] that "[a]ll packages should go in comps. I don't know why notting is against this?!!? Why should my php-pear-* packages be excluded from comps for example? Just because some newb might not want to install them does not mean a php web developer would not use comps to install them." Matt Miller explained[5] that the current scheme was inflexible: "If comps ends up with a thousand programs under Games and Entertainment, another thousand under Graphical Internet, etc., it's even more useless than having nothing in comps at all. What would be the point? On the other hand, having a thousand small comps groups is also no good."
[4] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00098.html
[5] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00120.html
Seth Vidal and Toshio Kuratomi seemed[6] interested in the idea of allowing Flickr-like tagging of package as a replacement for the problem of assigning them to groups. Denis Leroy also suggested[7] such a system: "Comps evolved over time into something that doesn't make a whole bunch of sense to me. Is the main use of comps still for installation groups within yum and anaconda ? A lot of packages are not installation "targets" but simply libraries that should only be installed by being pulled in from dependency resolution. Now if we're trying to "categorize" all packages nonetheless, it'd be better to have a tagbased system from packagedb, where packages can be "tagged" a-la-gmail, and also belong into multiple tag groups as some things really belong into multiple categories..."
[6] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00134.html
[7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00107.html
Nicolas Mailhot listed[8][9] the advantages of the current format of comps as: human-editable, version-controllable, diff-able, grep-able, platform-agnostic and scalable. Toshio leaned[10] towards having tag information stored in packagedb which could generate static "[...] separate files for the installer and general use (so that the installer isn't sprinkled with thousands of libraries but one could still use yum to search for "all packages that have a 'python' 'library' to do 'ssl'")."
[8] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00108.html
[9] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00158.html
[10] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00122.html
In another post Nicolas raised[11] another series of pertinent questions which included thinking about other repositories and alternate views of any data which might shoehorned into a particular model. Bill Nottingham wondered[12] where Nicolas was going with all this and re-capped the current purpose of comps as both an input to a graphical package selector and an input to tree composition tools. The discussion with Bill revealed that Nicolas advocated[13] "[...] just add everything in comps and run basic scripts that check every package we ship appears there (say in a dev-null group for libs or such stuff). You can easily cull the dev-null group at comps.xml.in -> comps.xml stage if needed" in order to ease the QA burden.
[11] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00125.html
[12] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00165.html
[13] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00226.html
Jeremy Katz wondered[14] who was the audience and task for Seth Vidal's "tree hierarchy plus tags" interface and distinguished between users looking for an application and administrators installing a system. Seth suggested[15] that using kickstart to install a minimal base and then the desired packages was the appropriate solution for the latter problem. He later explained[16] that having a tag-based presentation of the packages online would make it easier to determine which packages were available. Les Mikesell wished to reproduce specific machine configurations easily which led[17] Seth to suggest using yum-groups-manager to create a comps.xml file and then createrepo -g that_comps.xml somedir which produces "[...] a repository that ONLY has comps.xml in it that is then instantly usable by any site which can get to the baseurl where it lives."
[14] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00147.html
[15] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00148.html
[16] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00150.html
[17] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00152.html
LiveConnect Feature Approved for Fedora 10
FESCo's 2008-10-29 discussions[1] contained a decision to include the LiveConnect[2] feature in Fedora 10. LiveConnect is a way for web browsers to allow JavaScript and Java classes to call each other's methods. The project to develop a completely FLOSS implementation was initiated[3] by Tom Fitzsimmons and brought to completion by Deepak Bhole. Tom's work[4] on a rewrite of gcjwebplugin as an XPCOM plugin has been named IcedTeaPlugin and is the default in IcedTea6.
[1] http://bpepple.fedorapeople.org/fesco/FESCo-2008-10-29.html
[2] http://fedoraproject.org/wiki/Features/Liveconnect
[3] http://people.redhat.com/fitzsim/fosdem-2008/fosdem-2008-liveconnect.pdf
[4] http://fitzsim.org/blog/?p=23
The practical implications for end users are that many popular sites[5][6] are now usable without the problems associated with the installation of Sun Microsystems' non-FLOSS Java plugin.
There was[7] some agonizing over the problem that LiveConnect was being approved as a Feature post freeze date while other exciting projects had been dropped because they were not complete at that time. Brian Pepple worried: "Those folks we booted since they weren't complete would be justified in being pissed about us." Although this seemed to be a non-controversial opinion Deepak's work was also felt to be very important and fully tested. In addition Deepak submitted that "[...] no new packages introduced for this feature. Just an update to an existing package, that now installs a different Java plugin."
[7] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg00097.html