From Fedora Project Wiki

< FWN‎ | Beats

(FWN155 developments)
(FWN #156 Development beat pass 1)
Line 7: Line 7:
Contributing Writer: [[OisinFeeley|Oisin Feeley]]
Contributing Writer: [[OisinFeeley|Oisin Feeley]]


=== The PATH to CAPP Audits ===
=== Fedora 11: OSS and PulseAudio Conflict Resolved by CUSE ? ===


Some tough questioning about the purpose and usefulness of the Common Criteria for Information Technology Security Evaluation (CC)[1] was dished out to the maintainers of <code>shadow-utils</code> (the family of secure utilities for manipulating user accounts and passwords) when it appeared that the need to audit specific behaviors was causing some awkward constraints in OS design. The CC certifications are an ISO standard originally developed by the USA's National Security Agency to specify the expected behavior of systems under certain strictly defined criteria (so called Protection Profiles) to certain levels (Enterprise Evaluation Levels). ''Red Hat Enterprise Linux'' (a downstream derivative of Fedora) is able to boast several of them, including CAPP,LSPP and RBACPP to EAL4+[2], enabling ''RHEL5'' to be purchased for use in government programs which require "assured information sharing." See[3][4] for further information. In order to provide the auditing capabilities mandatory to achieve such certifications [[SteveGrubb|Steve Grubb]] and others on his team have been steadily committing changes to Fedora. The specific protection profile under discussion in this case was the Controlled Access Protection Profile (CAPP) and there has been a good deal of unease about the usefulness of such certification in other forums[5].
A thread[1] from November led [[WarrenTogami|Warren Togami]] to suggest[2] a plan to use CUSE[3] as part of a strategy to deprecate the near obsolete Open Sound System (OSS) which wreaks havoc with <code>PulseAudio</code> enabled boxes. The plan included a fallback to <code>OSS</code> for users who really wanted it.
 
[[BastienNocera|Bastien Nocera]] was[4] skeptical that <code>CUSE</code> would be ready in time for <code>Fedora 11</code> and suggested instead that a list of applications using OSS be created so that they could be fixed.
 
[1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01005.html


[1] http://en.wikipedia.org/wiki/Common.Criteria
[2] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02195.html


[2] http://www.redhat.com/solutions/government/commoncriteria/
[3] Character Devices in User space: http://lwn.net/Articles/308445/  


[3] A good blog entry by Sun's Jim Laurent: http://blogs.sun.com/jimlaurent/entry/faq.what.is.a.common
[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00872.html


[4] https://www2.sans.org/reading.room/whitepapers/standards/1078.php
=== Rawhide Report 2008-12-08 ===


[5] http://www.schneier.com/blog/archives/2005/12/microsoft.windo.html
When the latest ''Rawhide Report'' logged[1] one maintainers use of <code>cvs-import.sh</code> [[DominikMierzejewski|Dominik Mierzejewski]] criticised[2] the use of the script for updating. [[RichardJones|Richard Jones]] asked[3]: "[I]s this stuff really documented anywhere? I have tended to learn it by osmosis, deduction and reading the horribly complicated rules in Makefile.common."


When [[CallumLerwick|Callum Lerwick]] noticed[6] that he could not run <code>usermod</code> as an unprivileged user in order to get its <code>help</code> page he suggested that "[...] it and all the other account tools have been changed to mode 750, inaccessible to normal users" and erroneously attributed this to recent changes made to accommodate changes to the <code>PATH</code> environment variable. Earlier discussion of the addition of the <code>sbin</code> directories to users' PATHs can be found in FWN#146[7]. [[JonStanley|Jon Stanley]] replied[8] "These permissions have been in place for over 2 years, with valid reasoning. Just because it's in your PATH doesn't mean you should be able to execute it." Jon appended the 2006 log message which attributed the change to "fix regression. Permissions on user* group* binaries should be 0750, because of CAPP/LSPP certification." Callum posted a list of all the account tools which had such permissions including the shadow-utils account tools and the audit subsystem tools.
[[JasonTibbitts|Jason Tibbitts]] argued[4] that using <code>cvs-import.sh</code> nullified the potential advantages of using an <code>SCM</code> as it sequestered the sources elsewhere. [[JesseKeating|Jesse Keating]] disagreed[5] due to ease of use issues.


[6] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00489.html
A direct answer was provided[6] by [[PatriceDumas|Patrice Dumas]] with links to the relevant portions of the wiki.


[7] http://fedoraproject.org/wiki/FWN/Issue146#PATH:.2Fsbin.Tab.Confusion
[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00671.html


[8] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00495.html
[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00677.html


Although the change was actually several years old it appeared to cause surprise in many circles and prompted demands for information on what CAPP was and whether it was of any use to the Fedora Project. [[SteveGrubb|Steve Grubb]] responded[9] to the original query that "[...] you cannot do anything with [the user* commands] unless you are root. Allowing anyone to execute them would require lots of bad things for our LSPP/CAPP evaluations" and suggested that man pages should be used instead of running the tools with the <code>--help</code> argument.
[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00691.html


[9] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00501.html
[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00694.html


[[JesseKeating|Jesse Keating]] probed what appeared to be a reliance on restricting execution permissions for security. When Steve corrected[10] this to be "[...] more to do with the fact that we have to audit all attempts to modify trusted databases - in this case, shadow [...] if we open the permissions, we need to make these become setuid root so that we send audit events saying they failed" Jesse was even more perturbed[11] and asked "Why would the binary have to be suid? Why can't the binary detect that [the] calling user is not root, and just print out the usage and a message saying that you have to be root? How would this action make it any less auditable?" Later [[ChrisAdams|Chris Adams]] extended[12] the apparent logic: "[...] cat will have to be setuid root so it can audit? What about echo, bash, perl, etc.? This is absurd."
[5] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00695.html


[10] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00513.html
[6] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00701.html


[11] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00523.html
=== The D-Bus Problem ===


[12] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00575.html
[[IanAmess|Ian Amess]] asked[1] for the current status of a problem caused by a substantial update of the <code>D-Bus</code> package. The update had resulted in the incapacitation of many packages. The most important of these was <code>PackageKit</code>, the default graphical application for managing software.


From this point onwards the confusion and questioning gained in volume and intensity with several points being made to question the usefulness of this particular (CAPP) certification. These included the points that any user could obtain copies of the restricted binaries from outside of the system[13] for nefarious testing purposes; and that there were plenty of other tools[14] on the system which might allow violations of the policy.
[[ColinWalters|Colin Walters]] decided[2] that reverting the update was necessary and that changes to <code>D-Bus</code> policy would be postponed. <code>PackageKit</code>, and its <code>GNOME</code> and <code>KDE</code> clients were updated[3] by [[RichardHughes|Richard Hughes]] in an attempt to accommodate the changes. Richard testified that "[o]ver the last two days we've all been working really hard on fixing up all the projects after the DBus update. I know personally I'm closing a duplicate bugzilla every 30 minutes." He noted that the delay between creating an update and pushing it to a mirror was a limiting factor in being able to implement these fixes.


[13] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00514.html
A post to @fedora-announce by [[PaulFrields|Paul Frields]] explained[4] the series of steps which allowed users to re-enable normal system updates using PackageKit. As of 2008-12-15 this notice also appears at the top of all the Fedora Project wiki pages.


[14] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00626.html
[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01391.html


It would be fair to characterize most of the reactions as hostile. Some of this was due to an apparent impatience with "security certifications" which seemed to be of more interest to managers than achieving practical security. [[CallumLerwick|Callum Lerwick]] suggested[15] "[...] just because RHEL has to do stupid ignorant shit to appease certification authorities doesn't mean Fedora has to do it too." Another part was undoubtedly due to concern about who had made the decision to follow this path. [[JesseKeating|Jesse Keating]] expressed[16] some frustration and asked "Who's 'we'? Perhaps 'we' shouldn't piss on Fedora in order to meet some cert that I highly highly doubt any Fedora install will find useful." When [[SethVidal|Seth Vidal]] and [[DominikMierzejewski|Dominik Mierzejewski]] also wondered when, and by whom, the decision was made Steve answered[17]: "By me after a group presented the options back in 2005. Back in those days shadow-utils was in 'Core' and that was maintained by Red Hat."
[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01412.html


[15] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00528.html
[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00746.html


[16] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00534.html
[4] https://www.redhat.com/archives/fedora-announce-list/2008-December/msg00012.html


[17] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00584.html
=== Fedora Com System ? ===


Another part of the hostility seemed to originate in the novelty of the certification requirements to many participants. Steve answered many queries as they came in and suggested that it was necessary to take an overview of how the whole process worked. He was pressed by [[JeffSpaleta|Jeff Spaleta]] for further details. This led[18] to an interesting quote from the CAPP guidelines and the example of how they are applied to shadow-utils. The guidelines make some assumptions which many will find unrealistic, such as the "[t]he system administrative personnel are not careless, willfully negligent, or hostile, and will follow and abide by the instructions provided by the administrator documentation." While this criticism obviously calls into question the practical usefulness of the CAPP certification it is just one layer designed to perform a specific function, other more apparently useful security can only be built on top of these layers after they are implemented. Steve's post also contained some interesting practical examples of how administrators can use the audit tools to view information gained by instrumenting the shadow-utils code. To see who has modified accounts, and how, one can:
An exploration of possible ways to alert users to critical information was initiated[1] by [[ArthurPemberton|Arthur Pemberton]]. Most ideas seemed to center around some sort of <code>RSS</code> feed enabled by default on the desktop.


<pre>
[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01347.html
#ausearch --start this-month -m ADD_USER


#ausearch --start this-month -m ADD_GROUP
=== YUM: Enable --skip-broken by Default ? ===
</pre>


A view of attempts to change accounts both through the approved shadow-utils (restricted to root) or other non-approved tools can be obtained with a
Aliasing <code>yum update</code> to <code>yum --skip-broken update</code> was suggested[1] by [[StevenMoix|Steven Moix]] as a way to prevent a lot of recurring support problems by eliminating dependency problems.


<pre>
It was attempted[2] to strike a balance between reporting these broken dependencies so that they can be fixed and guarding the list of packages on a user's system as private information.
ausearch --start this-month -f /etc/shadow *raw -- aureport -x -i
</pre>


[18] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00585.html
A divergent sub-thread delved[3] into the appropriate use of <code>Conflicts:</code> in <code>rpm</code> packages.


[[EnricoScholz|Enrico Scholz]] pointed out[19] that this seemed like security through obscurity because there were other tools (<code>vipw</code> and <code>ldapadd</code>) which could modify the trusted database and Steve responded[20] that <code>vipw</code> was forbidden and that it would be possible to extend the auditing to <code>ldap</code> if someone had the time. In response to [[AndrewBartlett|Andrew Bartlett]] [[JesseKeating|Jesse Keating]] interpreted[21] this "forbidden" as "`forbidden by policy' in which using anything /but/ the audit-able tools is `forbidden by policy'. If you're expecting everybody to follow policy, why not just set policy that says `don't hack this box'. That'll work right?"
[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01161.html


[19] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00587.html
[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01171.html


[20] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00588.html
[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01349.html


[21] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00623.html
=== Making `updates-testing' More Useful ===


[[CallumLerwick|Callum Lerwick]] jumped[22] to what was for him the central point: "So I guess this is what all this really comes down to: Do we care about certification?" and asked whether the shadow-utils maintainer(s) would care to put the permissions to a FESCo vote. Steve affirmed[23] that certification was worthwhile with a detailed list of the positive side-effects of the certification process which include: man pages for each syscall, bug fixing and reporting, test suites, crypto work, virtualization with strong guarantees of <code>VM</code> separation and more. It was an impressive list which seemed to counter the dominant assumption that certification was merely another item to be ticked off on a bureaucrat's mindless list. Steve noted that "[a]s a result, Fedora is the ONLY community distribution that actually meets certification requirements. OpenSuse might be close for CAPP, but not LSPP/RSBAC, but that would be the only one I can think of that might be getting close."
The means to enable <code>PackageKit</code> to prompt willing users to install testing updates was explored in a thread opened[1] by [[MatthiasClasen|Matthias Clasen]]: "Basically, PackageKit should know that these are testing updates, and should ask me 'There are ... package updates available that need testing. Do you want to test these now ?' For extra points, we could even show a 'report back' link somewhere that allows to send comments to bodhi."


[22] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00560.html
[[RichardHughes|Richard Hughes]] prototyped a solution but worried[2] that it would be necessary to make changes to the users' repository configurations without their explicit consent.


[23] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00563.html
A sub-thread discussed[3] the problem of out-of-sync mirrors and the use of the <code>--skip-broken</code> option with yum (see also this same FWN#156"YUM: Enable --skip-broken by Default?".)


While this summary might make it seem as though certification is a slamdunk (and your correspondent has to admit a strong bias in favor of it) it has probably failed to convey the sense of unease expressed by Fedora Project contributors that decisions have been taken without discussion or consultation. [[JesseKeating|Jesse Keating]] asked[24] [[SteveGrubb|Steve Grubb]] to explain who was providing impetus to the shadow-utils/certification team: "Where is this yelling going on? Where are the bug reports? Where is the public discussion about supposed problems in our install processes? Where is the discussion with domain knowledge experts debating whether or not the complaint has merit? Where is the open and frank discussion?"
[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00925.html


[24] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00547.html
[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01063.html


One possible route around what seems to be an impasse was suggested by [[JeffSpaleta|Jeff Spaleta]]. Jeff observed[25] that CAPP certification for putative "appliance spins", but not the current set of spins, might make sense and asked[26]: "could some of the restrictions like the permissions be handled in a more modular way? Could for example, things be changed so I could install a specialized fedora-CAPP package at install time which tightens up aspects of the system to bring it into CAPP compliance, instead of expressing those restrictions in the default settings of all installs?"
[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01314.html


[25] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00556.html
=== Fedora Suckage ? ===


[26] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00625.html
The tinder for this week's massive flamewar was laid[1] by [[RobertScheck|Robert Scheck]] in the form of a dryly ironic, multiple-topic rant. Robert attacked the use of "memory wasting" python daemons, lags in pushing updates compared to the <code>EPEL</code> repositories, lack of information on the recent intrusion, poor German translation, the minimal requirements for <code>LiveCD</code> usage, <code>RPM-4.6</code> bugs, Red Hat employees blocking Merge Reviews, <code>PackageKit</code> bugs, and the EU support organisation for Fedora[2]!


=== The Looming Py3K Monster ===
Although there were several worthy attempts to make use of the above material
for a true conflagration in general the opportunity was wasted and instead
several rational, civil discussions of possible underlying causes and explanations took place. There were some worthy attempts to respond to all parts of this portmanteau complaint, but for the most part the discussion fractured naturally into several threads.


Last week we reported that [[User:ivazquez|Ignacio Vazquez-Abrams]] was busy shepherding <code>Python-2.6</code> into Fedora. This week [[MichaelDeHaan|Michael DeHaan]] raised[1] the question of what the plan for incorporating Python 3K will be. Michael worried that Py3K's incompatibilities with Python-2.6 "[are] pretty bad for someone who wants to keep a single codebase across EL 4 (Python 2.3) and up, which I think a lot of us do. That gets to be darn impossible and we have to double our involvement with code because we essentially have to maintain a differently-compatible fork for each project." He asked: "Are we looking at also carrying on with packaging 2.N indefinitely when we do decide to carry 3, because as I know it, the code changes to make something Python 3 compatible will be severe and that's a big item for any release, and will probably result in some undiscovered bugs even after the initial ports (if applied)."
One such thread was concerned with the pushing of a <code>D-Bus</code> update which broke many applications including <code>PackageKit</code>. [[KevinKofler|Kevin Kofler]] argued[3] that "[...] we need to be more careful with certain types of security updates, and better let them get some QA even if it means the fix gets delayed." [[MichaelSchwendt|Michael Schwendt]] asserted[4] the lack of active Quality Assurance as one of the contributing factors. KevinKofler explained[5] that the package had been rushed out "Because it was deemed a security update, complete with a CVE ID[.]" See this FWN#156 "The D-Bus Problem" for more details.


[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00379.html
[[MaxSpevack|Max Spevack]] took up[6] the complaints about ''Fedora EMEA'' and more of that discussion continued[7] on the more appropriate @fedora-ambassadors list.


Although there was some optimism that the "from future import" syntax would allow the use of <code>python-3</code> features in <code>python-2</code> [[DanielBerrange|Daniel P. Berrange]] quashed[2] the idea that this was a simple fix because it "[...] isn't much help if python 2.3, 2.4 and 2.5 don't support 'from future import' and you care about shipping stuff that works on the 99% of deployed Linux boxes today which don't have 2.6 let alone 3.0." [[BasilMohamedGohar|Basil Mohamed Gohar]] suggested[3] running the <code>2to3</code> tool on the Core packages to gain a sense of what needs to be done.
No further information on the security intrusion was forthcoming from [[PaulFrields|Paul Frields]] but he relayed[8] that the matter was not being forgotten or hushed up and that he planned to meet with others to discuss communication procedures for any possible future intrusions.


[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00394.html
[[RichardHughes|Richard Hughes]] asked[9] for specific bugs to be filed instead of general rants: "[...] I think you need to write much shorter, to the point emails. Ranting doesn't have much affect on anything, whilst filing bugs and getting involved upstream does." He also corrected Robert that many of the daemons which he complained about were written in C, not in Python.


[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00438.html
[[ColinWalters|Colin Walters]] issued[10] a mea culpa: "Just to be clear, the direct push into stable is my fault; not Red Hat's or other DBus developers or anyone else's. I had originally listed it for updates-testing, but then changed the update to security and in a moment of total stupidity also changed the listing for stable."


Some strategies and their implications were detailed[4] by [[ToshioKuratomi|Toshio Kuratomi]] in a post which comprehensively explains the options. Toshio suggested avoiding maintaining separate <code>python2</code> and <code>python3</code> packages within a single version of Fedora due to the resulting double work and space. He suggested that "[...] this decision is only partially within the powers of the Fedora Project to decide. If 80% of our upstream libraries move to py3, we'll need to move to py3 sooner. If 80% refuse to move off of py2, we can take our time working on migration code." In later discussion with [[ArthurPemberton|Arthur Pemberton]] he seemed[5] to favor the idea of using <code>python-2.6</code> while ensuring that all code is as compatible as possible with <code>python-3</code> and avoided estimating how hard this would be until actual experience is gained with "[...] porting code to 2.6 with 3.x features turned on at some point."
The idea of "repeatable updates" was raised[11] again by [[LesMikesell|Les Mikesell]] and critiqued for want of a practical implementation by [[JamesAntill|James Antill]]. [[JesseKeating|Jesse Keating]] made[12] a suggestion: "Treat rawhide as your 'new code' land, leave the release trees as your 'testing and working' code. That is don't be so goddamn eager to push new packages and new upstream releases to every freaking branch in existence."


[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00420.html
[[BehdadEsfahbod|Behdad Esfahbod]] tackled[13] the issue of Red Hat employees allegedly stalling on merge reviews. Behdad criticized the jumbling together of so many issues and repudiated any suggestion that as the maintainer of un-reviewed packages he "[...] must incorporate the merge reviews and close them, no thank you, I don't mind not maintaining anything in Fedora, and I certainly didn't block anyone from making progress in the merge reviews. When you say `The Red Hat people have to follow the Fedora packaging guidelines and rules same as the Fedora folks', does it mean that Fedora should feel free to decide what *I* work on, when it doesn't decide what `other Fedora folks' work on? That doesn't feel right."


[5] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00437.html
The criticism of <code>LiveCD</code> localization was handled[14] by [[JeroenvanMeeuwen|Jeroen van Meeuwen]] and he accepted that it would be useful if there were some manner in which the <code>Spin SIG</code> could create spins and torrent seeds outside of Fedora release engineering. It seemed that the need to make absolutely certain that such torrents and spins are kept available for support purposes may make this difficult.


[[JamesAntill|James Antill]] was[6] skeptical that Py3K would be seen in Fedora any time soon due to the massive changes required and the past history (FWN#114[7])of votes on maintaining compatibility packages: "I'll put money on python3k not being the default in Fedora 12. Hell, I'll even put some money on it not being the default in Fedora 14, at this point. My personal opinion is that we stay with 2.6.* for as long as possible, giving everyone time to dual port and the problems to be found/fixed and then it "should be easy" to have it as a feature and move for one release. But I'll point out that Ignacio Vazquez-Abrams did .all. the work for 2.6 in Fedora 11 ... so feel free to take this as just my opinion."
[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00722.html


[6] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00391.html
[2] EMEA is a non-profit organization with the mission to provide a focal-point and economic base for the European Fedora community. http://fedoraproject.org/wiki/Ambassadors/EMEA


[7] http://fedoraproject.org/wiki/FWN/Issue114#Policy.Proposal.For.New.Compatibility.Packages
[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00733.html


=== PackageKit Stealth Installations ===
[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00753.html


[[RobertLocke|Robert Locke]] asked[1] how <code>createrepo</code>, <code>anaconda-yum-plugins</code> and <code>preupgrade</code> had been installed without his permission on a fresh Fedora 10 install.
[5] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00855.html


[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00431.html  
[6] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00772.html


An answer was posted[2] by [[JesseKeating|Jesse Keating]] to the effect that this had been done by <code>PackageKit</code> "[...] so that it could offer you the ability to upgrade. We've moved that information to a public webserver rather than being in the preupgrade package so that PK can get this information without stealth installing packages." He added that while there were no "[...] current guidelines that would have caught this [...] it does fall into the `don't do that' category."
[7] https://www.redhat.com/archives/fedora-ambassadors-list/2008- December/msg00092.html


[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00448.html
[8] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00773.html


In further answers Jesse explained[3]: "It was installed so that PackageKit could have the appropriate information to check if there were distro level upgrades (say 9 to 10) available for you. The upstream has been asked to please not install any software in Fedora without a users consent, so hopefully this scenario won't happen again, at least not with PackageKit."
[9] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00798.html


[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00505.html
[10] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00812.html


=== DNS Resolution Unreliable ===
[11] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00832.html


Previously in FWN#154[1] we reported on some strange name resolution problems. [[SethVidal|Seth Vidal]], as maintainer of the <code>YUM</code> package which looked as though it might be implicated, requested[2] follow-up information.
[12] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00913.html


[1] http://fedoraproject.org/wiki/FWN/Issue154#Strange.Resolution.Problems
[13] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00834.html


[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00246.html
[14] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00899.html


[[TimNiemuller|Tim Niemuller]] replied that the problems persisted for him and were probably not to do with YUM. He added failures with <code>svn</code> to the mix and suggested[3] that "[...] yum is [not] the problem but there is a more general problem related to DNS lookups. As a specialty I'm using nss-mdns. But on F-8/F-9 this has never been a problem, so I suspect this is not what is causing the problem, especially because others have the same problem and I don't think nss-mdns is installed on many machines."
=== Help Needed: Sift "rawhide" for .pc Files ===


[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00305.html
[[JesseKeating|Jesse Keating]] requested[1] "[...] somebody to examine all the packages in rawhide that provide .pc [pkg-config] files and ensure proper placement of them based on the review guideline. This will likely require interaction with the packages maintainer(s) so the first step should probably be to produce a list of packages that ship .pc in a non -devel package and send the list (sorted by maintainer) to here so that we can discuss and pick off items."


[[JonathanUnderwood|Jonathan Underwood]] posted[4] a link to a heavily commented <code>bugzilla</code> entry opened by [[TomHorsley|Tom Horsley]] on 2008-08-21. The gist of the comments appears to be that with certain <code>DNS</code> servers there is a problem with simultaneous <code>IPv4</code> and <code>IPv6</code> requests being sent. A reported[5] work-around involved using a non-glibc resolver such as <code>dnsmasq</code> and was added[6] to the Fedora Project wiki by [[ChristopherStone|Christopher Stone]].
[[MichaelSchwendt|Michael Schwendt]] helped[2] to start the process by providing some lists of non-devel packages which included .pc files or had requires which pulled in packages which provided .pc files.


[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00308.html
[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00612.html


[5] http://www.fedorafaq.org/f10/#dns-slow
[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00648.html


[6] https://fedoraproject.org/wiki/Common.F10.bugs#DNS.Resolver.not.Reliable
=== Offtrac ===


[[JakubJelinek|Jakub Jelinek]] prepared[7] a <code>glibc</code> update which temporarily disables the simultaneous requests and [[BenWilliams|Ben Williams]] promised that once the issue is cleanly resolved the ''Fedora Unity'' team[8] will issue a Fedora 10 re-spin.
An itch scratched[1] by [[JesseKeating|Jesse Keating]] was to be able to interact with <code>Trac</code> via the commandline to create milestones for the Fedora 11 release cycle. He implemented his own python library, named Offtrac, to interact with <code>trac</code> using <code>XML-RPC</code> and asked for help in firming up the API and extending his client. Later Jesse explained[2] that the purpose was to "[...] make some aspects of using trac easier for folks, not just project owners but people who file tickets in track, like say for package tagging requests, or blocks, or... "


[7] https://bugzilla.redhat.com/show.bug.cgi?id=459756#c91
[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00738.html


[8] http://fedoraunity.org/
[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00808.html
 
=== Updates QA and Karma ===
 
The updates system came in for some more questioning (see this FWN#156 "Making `updates-testing' More Useful") when [[OrionPoplawski|Orion Poplawski]] showed[1] that an <code>rpcbind</code> update for <code>Fedora 9</code> may have been pushed to stable despite comments made by him indicating that it failed due to a dependency. Orion asked two questions: "[1] Should update submitters be allowed to give positive karma to their updates? Seems like that they are too biased. [2] Is there any requirement that an update have positive karma before being pushed to stable?"
 
It appeared that ultimately monitoring of such pushes are down to package maintainers and depend upon the good judgment of those doing the updates. [[MichaelSchwendt|Michael Schwendt]] provided[2] an overview of the situation.
 
[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01298.html
 
[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01427.html

Revision as of 16:12, 15 December 2008

Developments

In this section the people, personalities and debates on the @fedora-devel mailing list are summarized.

Contributing Writer: Oisin Feeley

Fedora 11: OSS and PulseAudio Conflict Resolved by CUSE ?

A thread[1] from November led Warren Togami to suggest[2] a plan to use CUSE[3] as part of a strategy to deprecate the near obsolete Open Sound System (OSS) which wreaks havoc with PulseAudio enabled boxes. The plan included a fallback to OSS for users who really wanted it.

Bastien Nocera was[4] skeptical that CUSE would be ready in time for Fedora 11 and suggested instead that a list of applications using OSS be created so that they could be fixed.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01005.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02195.html

[3] Character Devices in User space: http://lwn.net/Articles/308445/

[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00872.html

Rawhide Report 2008-12-08

When the latest Rawhide Report logged[1] one maintainers use of cvs-import.sh Dominik Mierzejewski criticised[2] the use of the script for updating. Richard Jones asked[3]: "[I]s this stuff really documented anywhere? I have tended to learn it by osmosis, deduction and reading the horribly complicated rules in Makefile.common."

Jason Tibbitts argued[4] that using cvs-import.sh nullified the potential advantages of using an SCM as it sequestered the sources elsewhere. Jesse Keating disagreed[5] due to ease of use issues.

A direct answer was provided[6] by Patrice Dumas with links to the relevant portions of the wiki.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00671.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00677.html

[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00691.html

[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00694.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00695.html

[6] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00701.html

The D-Bus Problem

Ian Amess asked[1] for the current status of a problem caused by a substantial update of the D-Bus package. The update had resulted in the incapacitation of many packages. The most important of these was PackageKit, the default graphical application for managing software.

Colin Walters decided[2] that reverting the update was necessary and that changes to D-Bus policy would be postponed. PackageKit, and its GNOME and KDE clients were updated[3] by Richard Hughes in an attempt to accommodate the changes. Richard testified that "[o]ver the last two days we've all been working really hard on fixing up all the projects after the DBus update. I know personally I'm closing a duplicate bugzilla every 30 minutes." He noted that the delay between creating an update and pushing it to a mirror was a limiting factor in being able to implement these fixes.

A post to @fedora-announce by Paul Frields explained[4] the series of steps which allowed users to re-enable normal system updates using PackageKit. As of 2008-12-15 this notice also appears at the top of all the Fedora Project wiki pages.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01391.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01412.html

[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00746.html

[4] https://www.redhat.com/archives/fedora-announce-list/2008-December/msg00012.html

Fedora Com System ?

An exploration of possible ways to alert users to critical information was initiated[1] by Arthur Pemberton. Most ideas seemed to center around some sort of RSS feed enabled by default on the desktop.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01347.html

YUM: Enable --skip-broken by Default ?

Aliasing yum update to yum --skip-broken update was suggested[1] by Steven Moix as a way to prevent a lot of recurring support problems by eliminating dependency problems.

It was attempted[2] to strike a balance between reporting these broken dependencies so that they can be fixed and guarding the list of packages on a user's system as private information.

A divergent sub-thread delved[3] into the appropriate use of Conflicts: in rpm packages.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01161.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01171.html

[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01349.html

Making `updates-testing' More Useful

The means to enable PackageKit to prompt willing users to install testing updates was explored in a thread opened[1] by Matthias Clasen: "Basically, PackageKit should know that these are testing updates, and should ask me 'There are ... package updates available that need testing. Do you want to test these now ?' For extra points, we could even show a 'report back' link somewhere that allows to send comments to bodhi."

Richard Hughes prototyped a solution but worried[2] that it would be necessary to make changes to the users' repository configurations without their explicit consent.

A sub-thread discussed[3] the problem of out-of-sync mirrors and the use of the --skip-broken option with yum (see also this same FWN#156"YUM: Enable --skip-broken by Default?".)

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00925.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01063.html

[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01314.html

Fedora Suckage ?

The tinder for this week's massive flamewar was laid[1] by Robert Scheck in the form of a dryly ironic, multiple-topic rant. Robert attacked the use of "memory wasting" python daemons, lags in pushing updates compared to the EPEL repositories, lack of information on the recent intrusion, poor German translation, the minimal requirements for LiveCD usage, RPM-4.6 bugs, Red Hat employees blocking Merge Reviews, PackageKit bugs, and the EU support organisation for Fedora[2]!

Although there were several worthy attempts to make use of the above material for a true conflagration in general the opportunity was wasted and instead several rational, civil discussions of possible underlying causes and explanations took place. There were some worthy attempts to respond to all parts of this portmanteau complaint, but for the most part the discussion fractured naturally into several threads.

One such thread was concerned with the pushing of a D-Bus update which broke many applications including PackageKit. Kevin Kofler argued[3] that "[...] we need to be more careful with certain types of security updates, and better let them get some QA even if it means the fix gets delayed." Michael Schwendt asserted[4] the lack of active Quality Assurance as one of the contributing factors. KevinKofler explained[5] that the package had been rushed out "Because it was deemed a security update, complete with a CVE ID[.]" See this FWN#156 "The D-Bus Problem" for more details.

Max Spevack took up[6] the complaints about Fedora EMEA and more of that discussion continued[7] on the more appropriate @fedora-ambassadors list.

No further information on the security intrusion was forthcoming from Paul Frields but he relayed[8] that the matter was not being forgotten or hushed up and that he planned to meet with others to discuss communication procedures for any possible future intrusions.

Richard Hughes asked[9] for specific bugs to be filed instead of general rants: "[...] I think you need to write much shorter, to the point emails. Ranting doesn't have much affect on anything, whilst filing bugs and getting involved upstream does." He also corrected Robert that many of the daemons which he complained about were written in C, not in Python.

Colin Walters issued[10] a mea culpa: "Just to be clear, the direct push into stable is my fault; not Red Hat's or other DBus developers or anyone else's. I had originally listed it for updates-testing, but then changed the update to security and in a moment of total stupidity also changed the listing for stable."

The idea of "repeatable updates" was raised[11] again by Les Mikesell and critiqued for want of a practical implementation by James Antill. Jesse Keating made[12] a suggestion: "Treat rawhide as your 'new code' land, leave the release trees as your 'testing and working' code. That is don't be so goddamn eager to push new packages and new upstream releases to every freaking branch in existence."

Behdad Esfahbod tackled[13] the issue of Red Hat employees allegedly stalling on merge reviews. Behdad criticized the jumbling together of so many issues and repudiated any suggestion that as the maintainer of un-reviewed packages he "[...] must incorporate the merge reviews and close them, no thank you, I don't mind not maintaining anything in Fedora, and I certainly didn't block anyone from making progress in the merge reviews. When you say The Red Hat people have to follow the Fedora packaging guidelines and rules same as the Fedora folks', does it mean that Fedora should feel free to decide what *I* work on, when it doesn't decide what other Fedora folks' work on? That doesn't feel right."

The criticism of LiveCD localization was handled[14] by Jeroen van Meeuwen and he accepted that it would be useful if there were some manner in which the Spin SIG could create spins and torrent seeds outside of Fedora release engineering. It seemed that the need to make absolutely certain that such torrents and spins are kept available for support purposes may make this difficult.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00722.html

[2] EMEA is a non-profit organization with the mission to provide a focal-point and economic base for the European Fedora community. http://fedoraproject.org/wiki/Ambassadors/EMEA

[3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00733.html

[4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00753.html

[5] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00855.html

[6] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00772.html

[7] https://www.redhat.com/archives/fedora-ambassadors-list/2008- December/msg00092.html

[8] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00773.html

[9] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00798.html

[10] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00812.html

[11] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00832.html

[12] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00913.html

[13] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00834.html

[14] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00899.html

Help Needed: Sift "rawhide" for .pc Files

Jesse Keating requested[1] "[...] somebody to examine all the packages in rawhide that provide .pc [pkg-config] files and ensure proper placement of them based on the review guideline. This will likely require interaction with the packages maintainer(s) so the first step should probably be to produce a list of packages that ship .pc in a non -devel package and send the list (sorted by maintainer) to here so that we can discuss and pick off items."

Michael Schwendt helped[2] to start the process by providing some lists of non-devel packages which included .pc files or had requires which pulled in packages which provided .pc files.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00612.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00648.html

Offtrac

An itch scratched[1] by Jesse Keating was to be able to interact with Trac via the commandline to create milestones for the Fedora 11 release cycle. He implemented his own python library, named Offtrac, to interact with trac using XML-RPC and asked for help in firming up the API and extending his client. Later Jesse explained[2] that the purpose was to "[...] make some aspects of using trac easier for folks, not just project owners but people who file tickets in track, like say for package tagging requests, or blocks, or... "

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00738.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00808.html

Updates QA and Karma

The updates system came in for some more questioning (see this FWN#156 "Making `updates-testing' More Useful") when Orion Poplawski showed[1] that an rpcbind update for Fedora 9 may have been pushed to stable despite comments made by him indicating that it failed due to a dependency. Orion asked two questions: "[1] Should update submitters be allowed to give positive karma to their updates? Seems like that they are too biased. [2] Is there any requirement that an update have positive karma before being pushed to stable?"

It appeared that ultimately monitoring of such pushes are down to package maintainers and depend upon the good judgment of those doing the updates. Michael Schwendt provided[2] an overview of the situation.

[1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01298.html

[2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg01427.html

Retrieved from "https://fedoraproject.org/w/index.php?title=FWN/Beats/Developments&oldid=65258"