Fedora Weekly News, Issue 140

[Huzaifa Sidhpurwala]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

  Fedora Weekly News Issue 140
=================================

Welcome to Fedora Weekly News Issue 140 for the week ending August 24, 2008.

http://fedoraproject.org/wiki/FWN/Issue140

Fedora Weekly News keeps you updated with the latest issues, events and
activities in the Fedora community.

If you are interested in contributing to Fedora Weekly News, please see
our 'join' page. Being a Fedora Weekly News beat writer gives you a
chance to work on one of our community's most important sources of news.
Ideas for new beats are always welcome -- let us know how you'd like to
contribute.

http://fedoraproject.org/wiki/NewsProject/Join

=Announcements=

In this section, we cover announcements from the Fedora Project.

http://www.redhat.com/archives/fedora-announce-list/

http://www.redhat.com/archives/fedora-devel-announce/

Contributing Writer: Max Spevack
Fedora Infrastructure's ongoing issues

Paul Frields continued to post[0] periodic updates about Fedora
Infrastructure.

"Our team has been hard at work for several days now, restoring services
in the Fedora infrastructure. We started with what we identified as
Fedora's "critical path," those systems required to restore minimum
daily operation. That work to be completely finished by the end of the
day. We then move on to our other value services to complete them as
soon as possible."

[0]
http://www.redhat.com/archives/fedora-announce-list/2008-August/msg00011....

On August 22nd, a more complete report[1] was published. Rather than
excerpt it here, Fedora Weekly News encourages readers to review the
entire announcement.

[1]
http://www.redhat.com/archives/fedora-announce-list/2008-August/msg00012....

Finally, Dennis Gilmore announced[2] that "effective immediately we have
replaced the CA that is in use for cvs.fedoraproject.org and
koji.fedoraproject.org This effects uploading to lookaside cache and
building packages."

[2]
http://www.redhat.com/archives/fedora-devel-announce/2008-August/msg00008...
Email bounces

Seth Vidal explained[3] that "a number of addresses @fedoraproject.org
there were windows when those email addresses would have bounced
reporting that the address did not exist."

He goes on to say that the problem has been corrected, but anyone who
wants the details should read the full message.

[3]
http://www.redhat.com/archives/fedora-devel-announce/2008-August/msg00007...


=Planet Fedora=

In this section, we cover the highlights of Planet Fedora - an
aggregation of blogs from Fedora contributors worldwide.

http://planet.fedoraproject.org

Contributing Writer: Max Spevack

This week on Planet Fedora...

    * Mairin Duffy posted[0] another draft of the Gears/Steampunk
proposed wallpaper, and also [1] reminded everyone that the "deadline
for round 2 of the Fedora 10 artwork process is 1 September 2008."[1]

[0] http://mihmo.livejournal.com/60668.html

[1] http://mihmo.livejournal.com/60797.html

    * Rex Dieter wrote several posts[2] about his trip to Akademy, the
KDE uber-conference which was held this year in Brussels.

[2] http://rdieter.livejournal.com/tag/akademy

    * Paul Frields announced[3] the Fedora Scholarship[4] program.

"Now it?s finally official: a Fedora Scholarship. A while back, we
started talking about ways to identify and cultivate young contributors
to Fedora. We are starting to see more and more young people taking the
opportunity to be full participants in the open source world. As part of
our mission to develop a culture of contribution in FOSS and not just
consumption, we want to identify and reward those individuals.

One way we can do this is through the incentive of scholarship funds.
This year we started the Fedora Scholarship to lead that effort. The
inaugural winner, Ricky Zhou, is someone that many people may know from
his exceptional work on our websites and infrastructure."

[3] http://marilyn.frields.org:8080/~paul/wordpress/?p=1136

[4] https://fedoraproject.org/wiki/Scholarship

    * Karsten Wade has written a two[5] excellent posts[6] about the
need for a Fedora CMS. His posts cover the differences between a CMS and
a wiki, general requirements for any CMS that we choose, as well as a
discussion of the scope of the project. Suggested reading for any
members of the websites or documentation projects.

[5] http://iquaid.org/2008/08/13/why-and-where-fedora-needs-a-cms-solution/

[6] http://iquaid.org/2008/08/19/fedora-cms-focus-and-scope/

=Ambassadors=

In this section, we cover Fedora Ambassadors Project.

http://fedoraproject.org/wiki/Ambassadors

Contributing Writer: JeffreyTadlock


Updated Q3 Budget Draft

Max Spevack posted [1] an updated draft for the upcoming Q3 budget. The
draft attempts to give more discretionary funds to North America,
address concerns for FAD EMEA and leave a small amount in reserve for
additional Q3 expenses that arise. Review the mailing list post for the
detailed view.

[1]
https://www.redhat.com/archives/fedora-ambassadors-list/2008-August/msg00...


North America Polo Shirt Order - Round Two

Pascal Calarco is ready to start a second round of ordering for
Ambassador Polos as announced on the Fedora Ambassador mailing list [1].
There is also additional information in the wiki [2].

[1]
https://www.redhat.com/archives/fedora-ambassadors-list/2008-August/msg00...

[2]
https://fedoraproject.org/wiki/Ambassadors/NA#Fedora_Ambassador_Polo_Shir...
Help Wanted: Austria LinuxDay 2008

Fabian Affolter posted [1] a request for help to organize a Fedora booth
at the Austria LinuxDay 2008. The event is November 29, 2008 and
expected attendance is 1000 visitors. If you are in the area and can
attend, contact Fabian Affolter.

[1]
https://www.redhat.com/archives/fedora-ambassadors-list/2008-August/msg00...

=Developments=

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

Contributing Writer: Oisin Feeley
Mysterious Fedora Compromise

The mysterious unavailability of much of the FedoraProject
infrastructure (see FWN#139 "General Outage of Fedora
Infrastructure"[1]) continued to provoke speculation during the week.
Some light was shed[2] on 22-08-2008 when Paul Frields announced that
there had been an intrusion onto several FedoraProject servers. The
announcement emphasized that although one of the servers was used for
signing rpm packages it was believed, based upon an absence of positive
evidence, that the key and packages had not been tampered with.
Nevertheless prudence and caution were being exercised and the
opportunity was being seized to completely re-install and upgrade all
systems. As a result it was necessary for most contributors to reset
authentication tokens of various types (see this same issue[3].) It also
appeared[4] that a concurrent event had led to the signing of some Red
Hat OpenSSH packages, but that these had been quickly detected and had
not led to the distribution of compromised packages.

[1]
http://fedoraproject.org/wiki/FWN/Issue139#General_Outage_of_Fedora_Infra...

[2]
https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00012...

[3] "Epiphany, Konqueror and Plague Hamper Updating SSL Client-side
Certificates" [4] http://www.redhat.com/security/data/openssh-blacklist.html

Prior to that announcement all that was known was that there were
problems on the build servers which became obvious to a wide audience on
13-08-2008 and that users were advised[5] on 14-08-2008 not to install
updates. The wiki and email lists continued to function during this
period thanks to the efforts of their administrators.

[5]
https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00008...

An update[6] was posted on 18-08-2008 by Paul Frields that listed the
services which had returned to normal and those which were expected to
return to normal soon. Public speculation latched on[7][8] to the
changing of "fedorahosted" SSH keys. Most guesses used this as evidence
that something similar to the recent 2008 Debian OpenSSL
vulnerabilities[9] had occurred. Some confusion prevailed[10] on
@fedora-devel as to whether it was possible to trust the new key
fingerprint on the website. Jim Meyering added[11] a useful post which
explained how to change from using a DSA ssh key to an RSA ssh key.
Overall there was a surprisingly low level of public discussion of the
problem and it was not until 18-08-2008 that some complaints about the
lack of information were expressed[12] on @fedora-list. On 22-08-2008
another bulletin was released[13] by Paul Frields that explained that
the Fedora key had not been obviously compromised but that it was still
being changed on the precautionary principle.

[6]
https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00011...

[7] http://lwn.net/Articles/294547/

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

[9] Metasploit has an excellent writeup on the topic here:
http://www.metasploit.com/users/hdm/tools/debian-openssl/

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

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

[12] https://www.redhat.com/archives/fedora-list/2008-August/msg01953.html

[13]
https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00012...

Although many responses to complaints about the limited information
suggested[14] that the Fedora developers could be trusted to "do the
right thing" in terms of alerting users to immediate threats of
compromise there was still strong disquiet expressed[15] over the lack
of information. This also occurred[16] on @fedora-list. Jef Spaleta
wondered[17] if there might be a better way of getting information out
than relying on everyone to subscribe to @fedora-announce. Alan Cox
suggested[18] that an RSS feed for critical announcements could be
picked up by a system's default package updater and that repositories
could communicate errors to yum. Alan was also unhappy with the absence
of important notices on the very front of the website and as a separate
matter criticized the content of the information issued: "[...] leaving
people in the dark assuming the worst [is] a very bad way to create long
term trust." Bruno Wolf III also suggested[19] that information should
have been conveyed by a more central announcement on fedoraproject.org
and co-ordination with media such as LWN.net.

[14] https://www.redhat.com/archives/fedora-list/2008-August/msg01955.html

[15] https://www.redhat.com/archives/fedora-list/2008-August/msg02034.html

[16] https://www.redhat.com/archives/fedora-list/2008-August/msg02426.html

[17] https://www.redhat.com/archives/fedora-list/2008-August/msg02010.html

[18] https://www.redhat.com/archives/fedora-list/2008-August/msg02012.html

[19] https://www.redhat.com/archives/fedora-list/2008-August/msg02013.html

Most comments on @fedora-devel made a point of thanking the Fedora
Infrastructure admins, even to the extent of providing internet
beers[20] and Hans de Goede commented[21] that "Even before the
unfortunate events of the last few weeks the infrastructure team has
been doing an amazing job[.]"

[20]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01037.html

[21]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01028.html
Epiphany, Konqueror and Plague Hamper Updating SSL Client-side Certificates

As part of the general overhaul of Fedora Project infrastructure
security occasioned by the recent intrusion[1] Dennis Gilmore advised[2]
that the certificate authority governing access to cvs.fedoraproject.org
and koji.fedoraproject.org had been changed. As a result it was
necessary for those who wished to build packages or upload to the
lookaside cache to manually import a new client-side certificate and to
remove their old certificate.

[1]
http://fedoraproject.org/wiki/FWN/Issue139#General_Outage_of_Fedora_Infra...

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

Martin Sourada reported[3] that after following the procedure he still
received a (Error code: ssl_error_unknown_ca_alert). Kai Engert
suggested[4] that Martin might need to import the Fedora Project root CA
certificate after verifying its fingerprint. As Martin had allowed
exceptions for the Fedora websites this was not the problem and it
turned out[5] to be due to a problem with the epiphany web browser
failing to offer an option to remove old certificates.

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

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

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

Problems were also experienced[6] by Jose Matos, but this time with the
konqueror web browser (version 4.1.0). Kevin Koffler replied[7] that in
KDE 4 there was no support for SSL certificate authentication with
konqueror and pasted a link[8] to an upstream bug report filed with the
KDE project on this issue.

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

[7]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00999.html

[8] https://bugs.kde.org/show.bug.cgi?id=167668

Tim Jackson reported[9] that plague-client[10] was acting up and Michael
Schwendt quickly provided[11] a patch which removed an assumption about
how many bytes would be in the certificate. Dennis Gilmore commented
"it's probably due to the new ca cert being 8096 bit and user certs are
now all 2048 bit" and Chris Weyl filed[12] a bugzilla.

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

[10] plague is the distributed package build system used by the EPEL
repository

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

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

Later Paul Howarth encountered[13] what seemed to be a problem with his
key or koji but which turned out, as suggested[14] by Jason Tibbitts to
be due to denyhosts blocking him.

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

[14]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00971.html
System Autodeath

Seth Vidal raised[1] the possibility of including a non-default option
to include an "autodie" feature in future Fedora releases. The idea,
originally expressed[2] in Glen Turner's blog is that each OS release
should ship with an expected expiry date and a means to automatically
remove the default route from that machine once the expiry date arrives.
This would prevent old, unmaintained machines from being quietly exploited.

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

[2] http://www.gdt.id.au/~gdt/blog/linux/autodeath.1024px

Agreement was expressed[3] by Jon Masters that it would be useful if "a
sysadmin consciously wants to remember to remove a system from
production/upgrade it after a certain time but then loses track of
it[.]" Rahul Sundaram also thought[4] that something should be done but
preferred the idea of modifying PackageKit to notify users when an
upgrade was due and fixing up PreUpgrade to allow users to easily update
without burning media. Jon Ciesla and Colin Walters wrangled over
whether LiveUpgrade or PreUpgrade was the appropriate place to present
such notifications with Colin disliking the LiveUpgrade due to support
logistics. Richard Hughes was pleased to relate[5] that most of Rahul's
desired feature had been implemented only a couple of days previously.

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

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

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

Although Dave Jones was not worried[6] about desktop machines being
abandoned this was contested. Dominik Mierzejewski related[7] anecdotes
of people still running Fedora Core 2 while Stephen Smoogen regaled[8]
the list with tales of hundreds of ancient Windows 3.11 clients on his
network. Seth Vidal shared[9] Dave's insouciance and was more concerned
about servers and "appliance-like machines" but promised to "look at
putting a simple cron job together in a package to do this" while
inviting anyone more motivated to go ahead and implement it.

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

[7]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00862.html

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

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

A slight misunderstanding of Seth's intentions led[10] Horst H. von
Brand to put the case "[...] against forcing people forward, even for
their own good[.]" Horst argued that some systems could not be updated
due to reliance on unmaintained legacy software. After Seth explained
that he was not recommending that the "autodeath" feature be made a
default Horst still expressed[11] a worry that casual installation
followed by forgetfulness could result in the unexpected deactivation of
systems later on. He suggested that instead of removing the default
route "to a nag screen when EOL nears, offer to set up for upgrade, show
(current) pointers to scripts helping check if 3rd party stuff will
still work, ... install /that/ by default, allow to disable/uninstall it
(even while it is nagging)." Seth objected[12] forcefully to describing
the removal of the default route as "kills itself" and this resulted in
a spate of alternate name suggestions.

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

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

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

James Hubbard saw[13] similarities to "Windows Genuine Advantage where
you can't use your machine anymore if you can't validate your
installation" and suggested instead that users be notified of the EOL
and in a separate part of the thread Jef Spaleta suggested that
"autoannoy", via motd or the login banner, instead of "autodeath"
might
educate and help users more than cutting off connectivity.

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

Commenting on responses from Matt Miller[14][15] and Jason Tibbitts[16],
among others, Seth Vidalcommented[17] that it appeared that "all the
.edu people seem to get this". But Horst was skeptical[18] that it was
necessary to force sysadmins to make such changes.

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

[15]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00935.html

[16]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00868.html

[17]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00869.html

[18]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00931.html

James Hubbard also made[19] a strong argument that lack of updates was
as much of a security problem as being EOL'ed and thus any such measures
should also be applied to systems lagging in their updates.

[19]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00959.html
GNUstep Filesystem Layout Discussion

A very clearly presented[1] explanation by Michel Salim kick started a
discussion about how the GNUstep application development framework could
finally be included in Fedora. Michel explained that GNUstep's
idiosyncratic filesystem layout had previously made it impossible to
install on an FHS[2] compliant system but that it was now possible. A
choice had to be made for the layout of what GNUstep terms "application
bundles" bearing in mind that "flattened" layouts are platform specific
while "unflattened" can support multilib with little pain. Michel saw
three main choices including a non-FHS-compliant one and noted that
there were potential conflicts between utill-linux-ng and the default
installation of GNUstep tools in /usr/bin/<arch>. He also noted that
Debian had chosen to use an unflattened layout.

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

[2] http://www.pathname.com/fhs/pub/fhs-2.3.html#INTRODUCTION

- From this point onwards the discussion became a little difficult to
follow due to the use of GNUstep specific terminology. The simplest
information your correspondent could find was the online version[3] of
the library-combo manpage and is probably essential reading before even
attempting to grasp the outlines of the following.

[3] http://linux.die.net/man/7/library-combo

A suggestion[4] from Axel Thimm was "[...] to place [the GNUstep tools]
directly under %{_bindir} and let rpm deal with the different archs as
it does for all other %{_bindir} mixing of subarchs with colors etc" and
to put the libraries under %{_libdir}. He argued that multilib or
multiarch binaries were not generally supported in Fedora. Axel was also
encouraging about the idea of starting a wiki page to attract as wide a
possible contribution from GNUstep developers including non-Fedora
contributors. Even more importantly Axel contrasted the ability of an
unflattened layout to support different compilers and libraries to that
of a flattened layout which could make OpenGroupware[5] conflict with
other applications due to its use of libFoundation[6.] Kevin Koffler was
unimpressed[7] with "packages which think they are a distro" and posited
the solution that "[...] they need to be fixed to work with the system
libraries instead (or the system libraries fixed to work with the
packages[.]" While Axel agreed he explained[8] that what was being
chosen was an "Objective-C runtime/ foundation library/graphical
interface tuple (flattened)" and that it was necessary to allow a choice
at runtime of the middle component in order to support applications
depending on either libFoundation or gnustep-base[9]. Axel concluded
"[...] IMHO we need to start with gnustep-make's FHS and non-flattened
layout and fix it where it still needs fixing (gnustep-make FHS layout
is very young and one could say that we are shaking out the bugs and
when we are finished hopefully upstream will be glad to accept any patch
we will have made to the FHS mode layout of gnustep-make)."

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

[5] A groupware server integrating office suites through XML-based
interfaces: http://www.opengroupware.org/en/about/mission.html

[6] Cocoa, libFoundation and gnustep-base all provide implementations
of, and non-standard extensions to, the OpenStep API. Apart from
licensing differences gnustep-base also has better platform coverage
(Windows is not supported by the others) and full unicode support.

[7]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01021.html

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

[9] http://www.gnustep.org/developers/suite.html

Discussion with Dominik 'Rathann' Mierzejewski and Kevin led Michel to
post[10] that "[...] the consensus so far seems to be for using a
flattened layout. Removing --disable-flattened from gnustep-make
actually causes a much tighter adherence to the FHS, with %{_bindir} and
%{_libdir} not containing any subdirectories." Michel was worried that
this would result in duplicating data files and that "[...] keeping the
unflattened layout might be too much trouble; if we are already
flattening /usr/bin and /usr/lib*, might as well stick with a flattened
layout after all."

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

Apparently different conclusions were being reached at this stage and
Axel attempted[11] to expand upon what he had said, explaining that this
would result in having to choose between the Foundation libraries at
buildtime. He presented unflattened layouts as allowing a choice of
"libcombo" at runtime as opposed to flattened which forced a choice at
buildtime. Dominik was[12] apparently comfortable with the idea of
choosing between the two Foundation libraries and cited the precedent of
not mixing lesstif and openmotif. To solve the problem he suggested
"[put binaries in unflattened %{_libdir}/GNUstep/* and symlink to
/usr/bin ." After Axel replied that the problem was the incompatible
API/ABI of the Foundation libraries Michel posted[13] another summary of
the current apparent state of knowledge.

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

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

[13]
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01054.html
Varnish 2.0 Test Suite Fails in Rpmbuild

An interesting post from Ingvar Hagelund, the maintainer of the varnish
http accelerator package, asked[1] why a test suite in the package would
behave differently within the rpmbuild created environment than when run
from an interactive shell. Ingvar had eliminated selinux as a
possibility and speculated "[...] the problem seems to be related to
some missing communication between the test scripts and the test server
process."

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

A response from Mogens Kjaer contained[2] a report that it was to do
with a missing libvarnish.so.0 and wondered "[...] is the build system
using an already installed libvarnish.so.0 if one is available and not
the newly built libvarnish.so.0?" Jason Tibbitts suggested[3] that it
was usual to reference such newly built libraries by manipulating
LD_LIBRARY_PATH in the specfile. After Mogens added LD_LIBRARY_PATH and
rebuilt from scratch he found[4] that all the tests were passed but that
no varnish-libs had been installed and this led him to conclude that
there was indeed a difference to the rpmbuild environment.

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

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

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

Ingvar ended up[5] filing a bug report upstream with the conclusion that
the soname version should be bumped as the old libraries were
incompatible with varnish-2.0.

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


=Infrastructure=

This section contains the discussion happening on the
fedora-infrastructure-list

http://fedoraproject.org/wiki/Infrastructure

Contributing Writer: HuzaifaSidhpurwala
So everyone is aware

Mike McGrath writes for fedora-infrastructure-list [1]

This is the first notice when came out to the community that there will
be outages and a lot of the servers are being rebuild. Mike pointed to
the mail on fedora-announce-list [2]

[1]
https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/ms...

[2]
http://www.redhat.com/archives/fedora-announce-list/2008-August/msg00008....
securing FAS certs

Toshio Kuratomi writes for fedora-infrastructure-list [3]


The Fedora Certificates issued by FAS are currently set to be
autogenerated if you have an account in FAS. This has one drawback. We
have to keep the password for the CA keys that sign the FAS certificates
in a file on the filesystem so that the automatic signing can use them.
Toshio suggested that we use a system which utilizes human interaction
to sign the certs.

[3]
https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/ms...

=Artwork=

In this section, we cover the Fedora Artwork Project.

http://fedoraproject.org/wiki/Artwork

Contributing Writer: Nicu Buculei
One Canvas Workflow

MartinSourada talked[1] on the Fedora Art list about the One Canvas
Workflow: "I think we need to be up to date with technology, so I
started downloading the One Canvas Workflow screencast by jimmac. I
haven't tried it yet (but going to do so very soon), but from the people
who already tried it and shared their thoughts about it, it seems like
it would be improvement for the Echo Icon Theme creation workflow".

And quickly after this he presented[2] the first icons created using
this process, an opportunity to introduce icons at a very large size
(256x256px) and with an increased amount of details[3].

Editor's note: One Canvas Workflow is an improved way to create multiple
icon size in one single sheet, advocated by the famous designer and
GNOME hacker Jackub Steiner "jimmac"[4].


[1]
https://www.redhat.com/archives/fedora-art-list/2008-August/msg00290.html

[2]
https://www.redhat.com/archives/fedora-art-list/2008-August/msg00292.html

[3]
https://www.redhat.com/archives/fedora-art-list/2008-August/pngNdtP7y3qw7...

[4] http://jimmac.musichall.cz/log/?p=436


Fedora Art Team Monthly Picks

MairinDuffy proposed an initiative: "maybe the Fedora Art Team could do
a monthly art pack (kind of along the likes of the iCE and ACiD art
groups' monthly art packs) that would be a selection of say the top 10
best art works producing using Fedora (inkscape, gimp, etc., it just has
to be software that's available in Fedora used to produce it.)", with
the intention to promote the works created by the member of the team: "I
think this might be a good way of getting more recognition to our
artists as well as to what Fedora can do".

The talk is open for details about the technical implementation.

[1]
https://www.redhat.com/archives/fedora-art-list/2008-August/msg00298.html


Round 2 theming developments

With the deadline for the second round for theming the upcoming Fedora
10, a number of theme proposals received updates: Gears[1], Solar[2] and
InvinXible[3] and each of them is under evolution in the remaining week.

[1] http://mihmo.livejournal.com/60668.html

[2]
https://www.redhat.com/archives/fedora-art-list/2008-August/msg00293.html

[3]
https://www.redhat.com/archives/fedora-art-list/2008-August/msg00300.html

=Security Advisories=

In this section, we cover Security Advisories from fedora-package-announce.

https://www.redhat.com/mailman/listinfo/fedora-package-announce

Contributing Writer: David Nalley
Fedora 9 Security Advisories
None

Fedora 8 Security Advisories
None


> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
> Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org
>
> iD8DBQFIsouNzHDc8tpb2uURAha9AJ4zU09+HRTb5qWzjNkB/12rF+z3SACgjOLa
> d6o4kC3gaPbsa0Ud8wlS3nM=
> =FRVA
> -----END PGP SIGNATURE-----