Developments
In this section the people, personalities and debates on the @fedora-devel mailing list are summarized.
Contributing Writer: Oisin Feeley
Default ssh-agent Dialog Pop-up
Confusion abounded when user "nodata" reported[1] that running ssh-add from the command-line popped up a gnome dialog requesting his private SSH key. "nodata" disliked handing out his private key in such a manner. The confusion resulted from the availability of at least two possible ssh-agents[2] and also a change in configuration between Fedora 9 and Fedora 10 which presents the authentication dialog by default.
Ricky Zhou was among those who suggested (with a manpage quote) that the SSH_ASKPASS environment variable determined whether the passphrase was read from a terminal or by an X11 dialog. Separately Jesse Keating[3] and Nalin Dahyabhi explained[4] that the dialog was presented by gnome-keyring and not gnome-ssh-askpass.
"nodata" questioned[5] whether the behavior had changed between Fedora 9 and Fedora 10 and expressed irritation that a "[...] GUI is popping up when I am using a command line app." Jesse Keating responded[6]: "You're using a command line app from a graphical terminal. Also, cli apps aren't the only use for ssh and ssh keys." This did not appeal to many respondents including John Linville who questioned[7] the benefit of changing focus to a new window to type a passphrase. Callum Lerwick rather tartly outlined[8] some benefits including preventing key logging attacks.
Matthias Clasen suggested[9] using
gconftool-2 -s -t bool /apps/gnome-keyring/daemon-components/ssh false
to turn off the behavior for those who dislike it and this led to several requests to make this the default. Andrew Haley put[10] the case that "[t]he key argument against a pop-up dialog box that asks for the passphrase is that we're training people to type secrets into pop-up dialog boxes. Bad psychology, bad security."
][MatthiasClasen|Matthias Clasen]] and Tomas Mraz with Jerry Amundson explored[11] the use of SSH_ASKPASS as an alternate method to disable the GUI dialog.
[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00486.html
[2] Private keys are stored by ssh agents so that they may handle all key related operations requested by clients. The passphrase to decrypt the key thus need only be typed into the agent once instead of per-operation.
[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00487.html
[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00536.html
[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00492.html
[6] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00495.html
[7] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00523.html
[8] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00533.html
[9] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00498.html
[10] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00517.html
[11] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00540.html
Intel Graphics Installation Woes
"Mike" requested[1] information on when a working xorg-x11-drv-i810 driver for Intel graphics chipsets had a chance of appearing. He was disappointed that it was non-trivial to get two machines with 82945G and 82845G chipsets installed and had needed to fall back to using the vesa driver instead of the intel one.
Others listed outstanding bugzilla entries for a wide range of Intel chipsets. Dan Williams asked[2] if using Option "EXANoComposite" "true" as a workaround for problems with the i830 chipsets was succesfull and received mixed reports. It seemed that he was making some progress with resolving some of the issues.
MAYoung suggested[3] that setting "NoAccel true" in xorg.conf might work for some people but that "[...] intel graphics are highly flaky on Fedora 10."
Robert Arendt laid[4] the blame at the door of upstream merges of GEM/DRM into the kernel and noted that other distributions were suffering identical problems. "Mike" later confirmed[5] this with a list of bugzilla entries from upstream GNOME: "It would be nice if Intel would help to get this fixed, and there are indeed problems with Suse, Ubuntu and Mandriva also with newer drivers and Intel graphics chipsets of various flavors - this is really bad!"
[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00435.html
[2] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00475.html
[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00443.html
[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00445.html
[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00467.html
KPackageKit Auto-update Bug
Michael B Allen reported[1] that his system had performed an update without his permission and asked how to completely disable such behavior.
It appeared[2] that this was due to a bug in KPackageKit which has been unfixable[3] for over a month due in part to the complexity of the code.
[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00461.html
[2] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00504.html
[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00510.html
Disabling Staging Drivers ?
Rahul Sundaram asked[1] if enabling the many new drivers in the staging tree[2] would make sense in rawhide in order to support a wider range of hardware such as the EeePC's ralink wireless chipset.
Opinion was roughly split between those who were completely against the idea and those who suggested avoiding codifying a rigid policy. Matthew Garrett believed[3] that it would be "somewhat user-hostile" to, for example enable the ralink drivers in rawhide but possibly remove them for a general release. He argued that the ralink drivers were a dead-end[4] which would never merge upstream. On the other hand Dave Jones preferred[5] to take a case-by-case approach as long as "[...] we have someone responsible for working on it, with the goal of getting it out of staging, and dealing with bugs etc. Not unlike the same reasoning for us adding various not-yet-upstream drivers to the Fedora kernel really."
While preferring to completely disable the staging drivers Thorsten Leemhuis expressed[6] the intention to provide RPM Fusion kmods in that case. Dan Williams made[7] a strong argument that "-staging" itself was a bad idea as it gave "legitimacy to drivers of questionable quality" and John Linville limned[8] the tortured history of the at76 driver.
[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00459.html
[2] "linux-staging" is a kernel tree whose purpose is to test drivers and filesystems for later inclusion in mainline http://lkml.org/lkml/2008/6/10/329
[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00462.html
[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00474.html
[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00472.html
[6] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00465.html
[7] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00473.html
[8] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00476.html
git-* Commands Moved to /usr/libexec/git-core/
Adam Tkac worried[1] that scripts would break due to the latest git branch in rawhide which had moved all the git-* binaries to /usr/libexec/git-core in order to comply with upstream practice. The issue was previously discussed (see FWN#141[2)] with the resolution that updating to git-1.6.0 would be a flag day for this change. Adam suggested that the new location could be added to the PATH environment variable but this received no support.
Karel Zak advocated[3] that such scripts should be fixed as the change had been coming since 2006.
Bryn Reeves wondered[4] if compatibility symlinks and a release note would ease the transition over a couple of releases. Although the symlinks were generally felt to be a non-effective strategy Todd Zulinger was encouraged[5] by Paul W. Frields to open a bugzilla entry against the Release Notes to ensure that the documentation team take care of highlighting the issue for Fedora 11.
[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00404.html
[2] http://fedoraproject.org/wiki/FWN/Issue141#Git-1.6.0_Commands_to_be_Moved_Out_of_PATH
[3] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00408.html
[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00410.html
[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00460.html
Mandatory FHS Adherence
JasonTibbitts posted[1] a summary and links to the 2009-01-06 FPC meeting deliberations. Interest on @fedora-devel was mostly sparked by the item which declared that the FPC would "Make adherence to the FHS a MUST [.]" Jason encouraged reading of the full minutes in order to understand this item.
Doug Ledford discussed[2] the problem his MPI[3] implementations experienced with the FHS and Richard W. M. Jones expressed [4] concern that the FHS was a moribund standard and adhering to it would block projects such as MinGW without any method to evolve the standard. Toshio Kuratomi responded in detail in both threads and pointed out[5] that the MinGW case had been addressed in the meeting and also that there were problems with changing the FHS.
[1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00362.html
[2] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00424.html
[3] http://www.open-mpi.org/papers/ipdps-2006/
[4] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00469.html
[5] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00483.html