-----BEGIN PGP SIGNED MESSAGE-----
Some people have already heard about the new Security Team making the rounds on BZ trying to clean up vulnerabilities that still linger within our OS. Until today I've not said much as I was waiting to see how successful we'd be at trying to remedy some of these situations. Turns out I had nothing to fear. So with that I formally announce the Security Team to Fedora and open the doors to all that are interested.
== What are we doing? ==
The Security Team's mission is to assist packagers in closing security vulnerabilities. Once alerted to a vulnerability on a package, the security team can help work with upstream to obtain a patch or a new release of a package. Once we have a patch or a new release we attach it to the vulnerability bug and work with packagers to get the fix pushed.
== How bad is the problem now? ==
As of a few days ago we had 566 open vulnerability tickets that cover both Fedora and EPEL. The breakdown of those bugs by severity looks like this:
* Critical: 3
* Important: 69
* Moderate: 366
* Low: 128
The good thing is that few of these vulnerabilities are considered "bad" (critical and important). There are likely bugs in there that no longer apply since the packages have been upgraded but the tickets never got closed. Also, a package that is in both Fedora and EPEL will get a ticket for each so from a pure numbers standpoint there are duplicates in those stats.
== How many people have signed up for the team? ==
Over twenty so far.
== How can I join/get involved/learn more about the project? ==
Go look at our wiki page, which is still being developed but does contain some basic information on the team. We also have a listserv and an IRC channel where we hang out.
 #fedora-security-team on irc.freenode.net
- -- Eric
Eric "Sparks" Christensen
sparks(a)fedoraproject.org - sparks(a)redhat.com
097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
-----END PGP SIGNATURE-----
devel-announce mailing list
I'm working with F20 and CentOS 7 to create some live booted images. I'm not looking to do live USB/CD media, but rather boot a server over the network with a kernel, initramfs, and squashfs. It's working well so far, but I have a filesystem issue that I can't seem to fix.
My build scripts create a 10GB sparse file and I fill that with an ext4 filesystem. I package that up into a squashfs as specified in the docs. That boots just fine.
However, if I attempt to fill the filesystem, it fills and becomes corrupt much earlier than I'd expect. I've put some log info into a gist.
My expectation is that if I create a 10GB live filesystem and and the system has > 10GB of RAM available, I'd expect that I could store somewhere around 10GB of data in the live filesystem before I run into a full filesystem. Is that expectation incorrect? Am I configuring something incorrectly?
Thanks for taking the time to read this far. :)
At the moment dhcp package contains dhcpd (dhcp server) and dhcrelay
(dhcp relay agent).
I'd like to move dhcrelay into separate subpackage and rename the
(sub)package with dhcpd to something better then 'dhcp'.
Now the question is how to call the new subpackages.
Given that package with dhcp client is called dhclient and not
dhcp-client my first idea has been just 'dhcpd' and 'dhcrelay'.
Other possibilities would be dhcp-server and dhcp-relay-agent
or dhcp-dhcpd and dhcp-dhcrelay.
dhcpd (or dhcp-server or dhcp-dhcpd)
dhcrelay (or dhcp-relay or dhcp-dhcrelay)
> On Tue, 2014-07-29 at 22:40 -0400, Adam Goode wrote:
>> I know this is old news, but Ghostscript switched to AGPL with version
>> 9.07 (Feb 2013). I was not able to find any announcement of this on
>> the Fedora lists.
> Here's the discussion from this list at the time:
Thanks for the background! I'm not sure how I missed it.
I know this is old news, but Ghostscript switched to AGPL with version
9.07 (Feb 2013). I was not able to find any announcement of this on
the Fedora lists.
Fedora 18 was the last release with the non-AGPL Ghostscript.
This is a surprise, because since Fedora 19 we've possibly introduced
a fairly large end-user burden on AGPL compliance, with ghostscript
being rather deep in the dependency tree. Here are just a few of the
affected packages by way of "repoquery --whatrequires --recursive
Is seems like a problem that these packages depend on an AGPL package.
This list suggests to me that running a print server (cups) or XMPP
server (ejabberd) would put a burden on me to comply with AGPL. Am I
My first reaction would be to fork ghostscript at a pre-AGPL version
at this point. Does this seem remotely feasible? Is there a better
(Also, there is another AGPL package, libquvi, which notably has
nautilus and other packages as depending on it. But that's a separate
I'm going to update evolution packages (evolution-data-server,
evolution, evolution-ews and evolution-mapi) in rawhide to their
3.13.4 versions during today, which brings soname version bumps in
evolution-data-server and evolution. I'll take care of rebuilds where
needed (and I have commit rights for).
There are also large changes in 3.13.4, in evolution-data-server are
used subprocesses for backends and evolution uses webkit-based
composer. Please use GNOME's bugzilla  for any issue you might find
Thanks and bye,