Evolution team drops support for gtk2 in 2.91.6 release of
evolution-related packages (gtkhtml3, evolution-data-server and
evolution) which might make trouble for dependent packages which are
still gtk2. I expect there will follow gtk3 updates for them in the near
future too, if not done already (this is mainly for packages using
libedataserverui and gtkhtml3, the rest should be fine).
There are done soname bumps and api version bumps in above mentioned
packages as well. The release will be done on Monday, when I plan to
update rawhide too (+/- few days, if something will go wrong).
Summary: Fedora infrastructure intrusion but no impact on product integrity
On January 22, 2011 a Fedora contributor received an email from the Fedora
Accounts System indicating that his account details had been changed. He
contacted the Fedora Infrastructure Team indicating that he had received
the email, but had not made changes to his FAS account. The Infrastructure
Team immediately began investigating, and confirmed that the account had
indeed been compromised.
At this time, the Infrastructure Team has evidence that indicates the account
credentials were compromised externally, and that the Fedora Infrastructure was
not subject to any code vulnerability or exploit.
The account in question was not a member of any sysadmin or Release Engineering
groups. The following is a complete list of privileges on the account:
* SSH to fedorapeople.org (user permissions are very limited on this machine).
* Push access to packages in the Fedora SCM.
* Ability to perform builds and make updates to Fedora packages.
The Infrastructure Team took the following actions after being
notified of the issue:
1. Lock down access to the compromised account
2. Take filesystem snapshots of all systems the account had access to
3. Audit SSH, FAS, Git, and Koji logs from the time of compromise to the
Here, we found that the attacker did:
* Change the account's SSH key in FAS
* Login to fedorapeople.org
The attacker did not:
* Push any changes to the Fedora SCM or access pkgs.fedoraproject.org in
* Generate a koji cert or perform any builds
* Push any package updates
Based on the results of our investigation so far, we do not believe that any
Fedora packages or other Fedora contributor accounts were affected by this
While the user in question had the ability to commit to Fedora SCM, the
Infrastructure Team does not believe that the compromised account was used to
do this, or cause any builds or updates in the Fedora build system. The
Infrastructure Team believes that Fedora users are in no way threatened by this
security breach and we have found no evidence that the compromise extended
beyond this single account.
As always, Fedora packagers are recommended to regularly review commits to
their packages and report any suspicious activity that they notice.
Fedora contributors are strongly encouraged to choose a strong FAS password.
Contributors should *NOT* use their FAS password on any other websites or
user accounts. If you receive an email from FAS notifying you of changes to
your account that you did not make, please contact the Fedora Infrastructure
team immediately via admin(a)fedoraproject.org.
We are still performing a more in-depth investigation and security audit and we
will post again if there are any material changes to our understanding.
Fedora Project Leader
Just a heads up that EPEL will soon be moving it's EPEL6 branch from
the Beta mode (like rawhide) that it's been in to a release mode (like
EPEL4/5 are). (I have cc'ed Fedora's devel-announce here as there may
be people not on the epel-devel list that might find this of interest).
2011-01-13 - Have any builds you wish done before release done. After
this point you will need to request a package be tagged into the stable
or testing repos or wait until bodhi is up for EPEL6.
2011-01-14 - EPEL rel-eng will work on composing and moving things
around. This may include untagging packages that have broken deps, or
moving them into testing, test composing, etc. Hopefully we can mirror
2011-01-16 - Maintainers encouraged to check new trees and help with
wiki prep, etc.
2011-01-17 - Bodhi will be enabled for EPEL6 and things will move to a
release mode: All packages spend 2 weeks in testing or +3 karma, bodhi
is used for updates, buildroot overrides are required as usual.
2011-01-18 - RELEASE DAY. Help with press release or announcements
would be welcome.
- Would be great if someone could make us a press release and had a
way to distribute it out.
- We need work on our wiki pages. A EPEL6 FAQ would be very nice.
- Maintainers need to determine what packages they want to ship for
EPEL6. If you do not want to ship whats there now, please untag it
Feel free to drop by #epel on freenode or drop an email to the
Thanks for all the work folks, and enjoy EPEL6!
Hi, everyone. Thanks to everyone who sent feedback on the drafts for the
test case and package test plan creation SOPs. I have now put these SOPs
into production, at the following addresses:
I have created links to them from other places in the QA wiki space. It
would be nice to have them called out from within the developers/package
maintainers space, but I'm not sure where would be appropriate: does
anyone have suggestions?
Now these are in production, it would be great if people could start
contributing test cases for packages, particularly test cases covering
critical path functions. If you maintain a critical path package, please
take a look at these two SOPs, and consider contributing test cases
covering at least the critical path functionality of your package; this
would help us greatly, and contribute to the improvement of critical
path testing by the proven testers. For the QA group, please also
consider contributing critical path test cases - you don't have to be a
maintainer of a package to do it! If you know how to test the critical
path functionality of a given package, please read the SOPs, write up
test case(s) to do it, and categorize them appropriately. Thanks a lot!
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
I just pushed a new release of bodhi into production.
It's a minor release that contains a small number of fixes, including:
Backend bug fixes
- Don't try and remove the -pending koji tags when resuming a push
- Don't fetch security bug details when resuming a push
- Don't show obsolete critpath updates in our testing digest
- Ensure the updateinfo epoch is '0' as opposed to None (rel-eng#3971)
- Stop spamming proventesters with old critpath mails, as this
data is available in the updates-testing digests that go out with
Web frontend changes
- Fix the testing status tooltips for EPEL (#486)
- Add the update ID back to the search results (#558)
- Don't hide updates that are not approved by the security team
from the admin push view, since we no longer require approval
API changes (for AutoQA)
- Support querying and commenting on updates by the Update ID, as well as title
- Make `bodhi --push-type` work for updates going to testing as
well as stable (rel-eng only)
- Add pkg_resources __requires__ hacks to get things working on F14
As always, please file tickets here: https://fedorahosted.org/bodhi/newticket
I have just tagged gtk3-2.99.0 into rawhide. There are abi and api
changes, so all dependent packages will have to be rebuilt (the most
obvious change is that the libraries are now called libg[dt]k-3.0.so
instead of libg[gt]k-x11-3.0.so).
There are a number of api changes that I am not going to list one-by-one
here, the following changes are relevant for packagers:
* gtk-update-icon-cache-3.0 and gtk-builder-convert-3.0 have been
dropped (since they were identical to their un-suffixed cousins in the
gtk2 package). If you are using gtk-update-icon-cache in %post of a
gtk3-using package, you should add
(and similar for %postun).
* The .pc files no longer define a 'target' variable, instead there is
a 'targets' variable which can contain multiple gdk backend names (for
now, it is still just 'x11', eventually it might change to be 'x11
wayland' or so). Some configure scripts use that variable to detect the
platform they are running on and will need adjustment.
I have built most packages that had a gtk3 dependency already, and
tagged them into rawhide. The following are the leftovers:
with the recent evolution-data-server 2.91.5 release in Rawhide are done
some internal changes in the soname versions and a location where the
backend files for the addressbook and calendar should be saved.
>From the commit log:
Change the installation path for E-D-S backends.
Address book and calendar backend modules are now split into
different installation directories so the D-Bus factory processes
will only load relevant backend modules.
This changes some pkg-config details for third-party backend
Instead of querying the backend directory with:
pkg-config --variable=extensiondir evolution-data-server-1.2
you must query the directory for address book backends with:
pkg-config --variable=backenddir libedata-book-1.2
and the directory for calendar backends with:
pkg-config --variable=backenddir libedata-cal-1.2
Over the past few months, the Fedora Board has focused on coming up
with two or three overarching goals that can be accomplished over the
next few release cycles. We've got a fairly healthy list of goals at
this point, and welcome your input in helping us decide which two or
three goals are most important. The Fedora Board will be having its
bi-weekly IRC meeting this coming Friday, and we invite you to attend
that meeting and share your input with us. Instead of our normal
question and answer session, we'll instead focus on prioritizing our
list of goals.
The meeting is in the #fedora-board-meeting channel on the Freenode
IRC network at 2:00pm EST (19:00 UTC). In order to keep the meeting
organized and easy to follow, we ask that participants follow the
instructions in the "General Rules" section of
Fedora Project Leader