Fedora Weekly News #151 - Developments
Developments
1.2.1 Security Exceptions to the Mass ACL Opening
1.2.2 Who Moved My Bug ?
1.2.3 HOWTO: Get an SELinux Policy Change
1.2.4 Comps Czar Appointed to Encourage Modifications
1.2.5 LiveConnect Feature Approved for Fedora 10
== 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.
[5] http://www.jigzone.com/
[6] http://games.yahoo.com/
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
