|
|
| (73 intermediate revisions by the same user not shown) |
| Line 5: |
Line 5: |
| mailing list are summarized. | | mailing list are summarized. |
|
| |
|
| Contributing Writer: [[OisinFeeley|Oisin Feeley]] | | Contributing Writer: [[User:Ush|Oisin Feeley]] |
|
| |
|
| === The PATH to CAPP Audits === | | === Would You Like to Write This Beat ? === |
|
| |
|
| 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].
| | Following this issue (FWN#178) I will, with regret, no longer be covering the @fedora-devel list. If you are interested in writing this weekly summary of the deeds and doings on the list then please contact fedora-news-list@redhat.com or [[User:Pcalarco|Pascal Calarco]]. A short overview of what you may need to do can be obtained by reading the workflow<ref>http://fedoraproject.org/wiki/FWN/WorkFlow</ref> section of the wiki. The @fedora-news list is also extremely open and helpful. Joining<ref>http://fedoraproject.org/wiki/FWN/NewsProject/Join</ref> the News Project is quite straightforward. |
|
| |
|
| [1] http://en.wikipedia.org/wiki/Common.Criteria
| | <references/> |
|
| |
|
| [2] http://www.redhat.com/solutions/government/commoncriteria/
| | === Is gNaughty a Hot Babe ? === |
|
| |
|
| [3] A good blog entry by Sun's Jim Laurent: http://blogs.sun.com/jimlaurent/entry/faq.what.is.a.common | | [[User:Sundaram|Rahul Sundaram]] posted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02071.html</ref> the results of a survey conducted, primarily on @fedora-list and on the forums, to discover which non-repository-packaged software Fedora consumers were using. |
|
| |
|
| [4] https://www2.sans.org/reading.room/whitepapers/standards/1078.php
| | One interesting point is that CMUCL<ref>One of the Common Lisp implementations: http://www.cons.org/cmucl/</ref> was revealed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02088.html</ref> to be only available for 32-bit systems. However what got people really excited was<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg02136.html</ref> Rahul's question about what to do concerning the <code>gNaughty</code> package. Its sole purpose seemed<ref>https://www.redhat.com/archives/fedora-devel-list/2009-May/msg02203.html</ref> to be downloading pornography. Rahul referenced the <code>hot-babe</code> CPU monitor which enjoyed controversy in Debian packaging circles due to its use of female nudity. Rahul wanted to find out "[...] is this allowed in Fedora?" |
|
| |
|
| [5] http://www.schneier.com/blog/archives/2005/12/microsoft.windo.html | | Amusingly a good deal of the controversy focused on whether the content was freely redistributable, but a predictable moral angle was raised<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02242.html</ref> by [[User:Alsadi|Muayyad AlSadi]] who asked for help in producing a spin which removed content deemed objectionable. Muayyad is a Jordanian developer who has been producing an Arabic-localized Fedora spin named "Ojuba" for some time. Muayyad sought a way to make identifying and tagging packages easier to facilitate this spin. [[User:Notting|Bill Nottingham]] was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02312.html</ref> skeptical about the chances of tags keeping meaning unless there was some sort of review board. Equally predictable was<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02295.html</ref> the reaction typified by [[User:Skvidal|Seth Vidal]] which resisted any attempt to restrict packages according to standards which had nothing to do with licensing or patent issues. [[User:bochcecha|Mathieu Bridon]] thought<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02355.html</ref> that the creation of a wiki-page by Muayyad would allow anyone interested in co-ordinating work on "Inappropriate Content" to just go ahead and do it without dragging in bureaucracy. |
|
| |
|
| 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.
| | <references/> |
|
| |
|
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00489.html
| | === Chrome9 Vx800 Graphics Support on LiveUSB === |
|
| |
|
| [7] http://fedoraproject.org/wiki/FWN/Issue146#PATH:.2Fsbin.Tab.Confusion | | [[KristapsViesalgs|Kristaps Viesalgs]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02146.html</ref> for help in getting the Fedora Live USB to boot correctly on a machine using a Via Vx800 "Chrome9" GPU. Kristaps had some success with the latest upstream version (from their subversion repository) and asked: "Is there any brutal option how to properly boot X with vesa driver, install Fedora, then make openchrome svn installation? Is Fedora planning to make for VIA graphic chipset autoconfiguration utility?" |
|
| |
|
| [8] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00495.html | | [[User:Ajax|Adam Jackson]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02154.html</ref> for a more specific bug report because the chip should be supported. He preferred not to ship an autoconfiguration utility instead of just getting the driver correct. Similar points were made by [[User:Adamwill|Adam Williamson]] and [[User:|Xavier Bachelot]]. The latter asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02163.html</ref> any interested developers to help out the openchrome project in both the 2D and 3D(Gallium) sides. |
|
| |
|
| 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.
| | <references/> |
|
| |
|
| [9] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00501.html
| | === Who Wants a Pony? === |
|
| |
|
| [[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." | | [[User:Kushal|Kushal Das]] promised<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02139.html</ref> a pony to anyone that would take the trouble to review<ref>http://bugzilla.redhat.com/show_bug.cgi?id=503021</ref> one of his packages. |
|
| |
|
| [10] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00513.html
| | <references/> |
|
| |
|
| [11] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00523.html
| | === Firestarter Retired as Unportable to PolicyKit === |
|
| |
|
| [12] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00575.html | | [[User:Maxamillion|Adam Miller]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02089.html</ref> whether he should just retire the <code>Firestarter</code><ref>Firestarter is a firewall configuration GUI</ref> package for which he had recently become the maintainer. His query was based on the recent filing of RFEs to integrate <code>Firestarter</code> with <code>PolicyKit</code>. These suggested to Adam that a large amount of work would be needed due to the lack of any upstream activity for four years and the need to grok <code>PolicyKit</code>. |
|
| |
|
| 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.
| | Following confirmation from [[User:Sundaram|Rahul Sundaram]] and [[User:Skvidal|Seth Vidal]] a decision was made<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02094.html</ref> by Adam: "I would honestly rather retire the package than do a WONTFIX, if the project as a whole is going the direction of PolicyKit and upstream is dead then I don't want to keep old and busted cruft around the repositories as Fedora continues to look towards the future." |
| | |
| | A further suggestion from "Cry" prompted<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02122.html</ref> Adam to start filing RFEs against <code>system-config-firewall</code> for any features present in <code>Firestarter</code> but missing in <code>system-config-firewall</code>. |
| | <references/> |
|
| |
|
| [13] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00514.html
| | === Russian Fedora ? === |
|
| |
|
| [14] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00626.html | | When [[User:Peter|Peter Lemenkov]] asked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02013.html</ref> about the idea of creating a Fedora Foundation outside of the U.S.A. the usual arguments from the past few years were rehashed. [[User:Kkofler|Kevin Kofler]] gave<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02025.html</ref> an able summary why this would still present Red Hat with a problem. |
|
| |
|
| 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."
| | An assertion by [[User:|Alexey Torkhov]] that there existed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02390.html</ref> a Red Hat-sanctioned "RussianFedora" spin which contained mp3 codecs and other material excluded from the actual Fedora Project repositories drew demands for proof from [[User:Sundaram|Rahul Sundaram]]. |
|
| |
|
| [15] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00528.html
| | <references/> |
|
| |
|
| [16] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00534.html
| | === Will FESCo Revisit Kmods ? === |
|
| |
|
| [17] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00584.html | | A discussion of why <code>VirtualBox</code> will not be a feature due to its code not yet heading upstream and consequently remaining as <code>kmods</code> drew a statement of support from [[User:Kkofler|Kevin Kofler]] for reverting the current banning of <code>kmods</code> should he become a FESCo member. Upon request from [[RichardJones|Richard W.M. Jones]] for a dispassionate summary of the reasons to avoid <code>kmods</code> drew<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02254.html</ref> a concise response from [[User:Skvidal|Seth Vidal]]. |
|
| |
|
| 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:
| | [[User:Adamwill|Adam Williamson]] and [[User:Mdomsch|Matt Domsch]] (Dell's DKMS mastermind) kicked<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02368.html</ref> some ideas back and forth over the advantages of <code>akmods</code> versus <code>kmods</code>. |
|
| |
|
| <pre> | | <references/> |
| #ausearch --start this-month -m ADD_USER
| |
|
| |
|
| #ausearch --start this-month -m ADD_GROUP
| | === Upgrade from Fedora 10 to Rawhide (Fedora 11) === |
| </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
| | Following a report from [[UweKiewel|Uwe Kiewel]] that a <pre>yum upgrade</pre> had spewed all sorts of errors the supported methods for upgrades were re-stated<ref>http://www.redhat.com/archives/fedora-devel-list/2009-May/msg02041.html</ref> by [[User:Adamwill|Adam Williamson]]: "[I]f you talk to the people most involved in implementing it (Seth) and testing it (Will) they will tell you that doing live upgrades via yum can't really ever be 100% safe for various reasons, but preupgrade can get very close and is useful in all the same cases. So their position is, we support preupgrade, we don't support yum. If yum works, great, if it doesn't, you can bug people to fix whatever it stopping it working, but it's not 'required' by any policy or guideline." |
|
| |
|
| <pre> | | <references/> |
| 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
| |
| | |
| [[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?"
| |
| | |
| [19] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00587.html
| |
| | |
| [20] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00588.html
| |
| | |
| [21] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00623.html
| |
| | |
| [[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."
| |
| | |
| [22] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00560.html
| |
| | |
| [23] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00563.html
| |
| | |
| 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?"
| |
| | |
| [24] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00547.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?"
| |
| | |
| [25] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00556.html
| |
| | |
| [26] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00625.html
| |
| | |
| === The Looming Py3K Monster ===
| |
| | |
| 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)."
| |
| | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00379.html
| |
| | |
| 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.
| |
| | |
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00394.html
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00438.html
| |
| | |
| 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."
| |
| | |
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00420.html
| |
| | |
| [5] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00437.html
| |
| | |
| [[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."
| |
| | |
| [6] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00391.html
| |
| | |
| [7] http://fedoraproject.org/wiki/FWN/Issue114#Policy.Proposal.For.New.Compatibility.Packages
| |
| | |
| === PackageKit Stealth Installations ===
| |
| | |
| [[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.
| |
| | |
| [1] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00431.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."
| |
| | |
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00448.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."
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00505.html
| |
| | |
| === DNS Resolution Unreliable ===
| |
| | |
| 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.
| |
| | |
| [1] http://fedoraproject.org/wiki/FWN/Issue154#Strange.Resolution.Problems
| |
| | |
| [2] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00246.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."
| |
| | |
| [3] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00305.html
| |
| | |
| [[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]].
| |
| | |
| [4] https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00308.html
| |
| | |
| [5] http://www.fedorafaq.org/f10/#dns-slow
| |
| | |
| [6] https://fedoraproject.org/wiki/Common.F10.bugs#DNS.Resolver.not.Reliable
| |
| | |
| [[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.
| |
| | |
| [7] https://bugzilla.redhat.com/show.bug.cgi?id=459756#c91
| |
| | |
| [8] http://fedoraunity.org/
| |
Developments
In this section the people, personalities and debates on the @fedora-devel
mailing list are summarized.
Contributing Writer: Oisin Feeley
Would You Like to Write This Beat ?
Following this issue (FWN#178) I will, with regret, no longer be covering the @fedora-devel list. If you are interested in writing this weekly summary of the deeds and doings on the list then please contact fedora-news-list@redhat.com or Pascal Calarco. A short overview of what you may need to do can be obtained by reading the workflow[1] section of the wiki. The @fedora-news list is also extremely open and helpful. Joining[2] the News Project is quite straightforward.
Is gNaughty a Hot Babe ?
Rahul Sundaram posted[1] the results of a survey conducted, primarily on @fedora-list and on the forums, to discover which non-repository-packaged software Fedora consumers were using.
One interesting point is that CMUCL[2] was revealed[3] to be only available for 32-bit systems. However what got people really excited was[4] Rahul's question about what to do concerning the gNaughty package. Its sole purpose seemed[5] to be downloading pornography. Rahul referenced the hot-babe CPU monitor which enjoyed controversy in Debian packaging circles due to its use of female nudity. Rahul wanted to find out "[...] is this allowed in Fedora?"
Amusingly a good deal of the controversy focused on whether the content was freely redistributable, but a predictable moral angle was raised[6] by Muayyad AlSadi who asked for help in producing a spin which removed content deemed objectionable. Muayyad is a Jordanian developer who has been producing an Arabic-localized Fedora spin named "Ojuba" for some time. Muayyad sought a way to make identifying and tagging packages easier to facilitate this spin. Bill Nottingham was[7] skeptical about the chances of tags keeping meaning unless there was some sort of review board. Equally predictable was[8] the reaction typified by Seth Vidal which resisted any attempt to restrict packages according to standards which had nothing to do with licensing or patent issues. Mathieu Bridon thought[9] that the creation of a wiki-page by Muayyad would allow anyone interested in co-ordinating work on "Inappropriate Content" to just go ahead and do it without dragging in bureaucracy.
Chrome9 Vx800 Graphics Support on LiveUSB
Kristaps Viesalgs asked[1] for help in getting the Fedora Live USB to boot correctly on a machine using a Via Vx800 "Chrome9" GPU. Kristaps had some success with the latest upstream version (from their subversion repository) and asked: "Is there any brutal option how to properly boot X with vesa driver, install Fedora, then make openchrome svn installation? Is Fedora planning to make for VIA graphic chipset autoconfiguration utility?"
Adam Jackson asked[2] for a more specific bug report because the chip should be supported. He preferred not to ship an autoconfiguration utility instead of just getting the driver correct. Similar points were made by Adam Williamson and [[User:|Xavier Bachelot]]. The latter asked[3] any interested developers to help out the openchrome project in both the 2D and 3D(Gallium) sides.
Who Wants a Pony?
Kushal Das promised[1] a pony to anyone that would take the trouble to review[2] one of his packages.
Firestarter Retired as Unportable to PolicyKit
Adam Miller asked[1] whether he should just retire the Firestarter[2] package for which he had recently become the maintainer. His query was based on the recent filing of RFEs to integrate Firestarter with PolicyKit. These suggested to Adam that a large amount of work would be needed due to the lack of any upstream activity for four years and the need to grok PolicyKit.
Following confirmation from Rahul Sundaram and Seth Vidal a decision was made[3] by Adam: "I would honestly rather retire the package than do a WONTFIX, if the project as a whole is going the direction of PolicyKit and upstream is dead then I don't want to keep old and busted cruft around the repositories as Fedora continues to look towards the future."
A further suggestion from "Cry" prompted[4] Adam to start filing RFEs against system-config-firewall for any features present in Firestarter but missing in system-config-firewall.
Russian Fedora ?
When Peter Lemenkov asked[1] about the idea of creating a Fedora Foundation outside of the U.S.A. the usual arguments from the past few years were rehashed. Kevin Kofler gave[2] an able summary why this would still present Red Hat with a problem.
An assertion by [[User:|Alexey Torkhov]] that there existed[3] a Red Hat-sanctioned "RussianFedora" spin which contained mp3 codecs and other material excluded from the actual Fedora Project repositories drew demands for proof from Rahul Sundaram.
Will FESCo Revisit Kmods ?
A discussion of why VirtualBox will not be a feature due to its code not yet heading upstream and consequently remaining as kmods drew a statement of support from Kevin Kofler for reverting the current banning of kmods should he become a FESCo member. Upon request from Richard W.M. Jones for a dispassionate summary of the reasons to avoid kmods drew[1] a concise response from Seth Vidal.
Adam Williamson and Matt Domsch (Dell's DKMS mastermind) kicked[2] some ideas back and forth over the advantages of akmods versus kmods.
Upgrade from Fedora 10 to Rawhide (Fedora 11)
Following a report from Uwe Kiewel that a
yum upgrade
had spewed all sorts of errors the supported methods for upgrades were re-stated[1] by Adam Williamson: "[I]f you talk to the people most involved in implementing it (Seth) and testing it (Will) they will tell you that doing live upgrades via yum can't really ever be 100% safe for various reasons, but preupgrade can get very close and is useful in all the same cases. So their position is, we support preupgrade, we don't support yum. If yum works, great, if it doesn't, you can bug people to fix whatever it stopping it working, but it's not 'required' by any policy or guideline."
