From Fedora Project Wiki

Vulnerability tracking consists primarily of watching common security and vulnerability mailing lists or web sites such as:

Red Hat Enterprise Linux Announcements

Fedora Core Announcements (April, 2006 and before)
Fedora Core Announcements (May, 2006 and later)

Fedora Core Patches

Security Focus ~BugTraq

CERT

US-CERT

SANS Network Security List (no address available)

LinuxSecurity.com


Following the Red Hat advisory mailing lists for current releases of Red Hat Enterprise Linux and Fedora Core is perhaps the easiest way to find information about updates which may apply to Fedora Legacy supported distributions.

Once you have identified a vulnerability or fix, you should try to verify that it applies to a Fedora Legacy Project support distribution. If in doubt, you can always post a question about it to the Fedora Legacy mailing list to get help or advice from other people.

Once you've identified that a bug is relevent to one or more Fedora Legacy supported distributions, you should report this fact to the Fedora Legacy Project. The best way to do this is to open a Bugzilla bug detailing your findings. As an alternative (or in addition to) the Bugzilla entry you may simply post the details of your findings to the Fedora Legacy mailing list.

In either case, you should provide as much detail as possible. But if you don't have any information about the vulnerability, still open a Bugzilla ticket or report it to the mailing list so that others can research the details.

The type of information which might be appropriate to include in a report are:

  • What the bug or vulnerability is; links or references to reports or articles about it.
  • What distributions are known to be affected or not affected by it.
  • Links to any patches, if any exist. Your own patch if you have created one.

This may seem like a lot of work but don't worry, you don't need to monitor everything alone; vulnerability tracking is spread over various people. You should pick one or more areas you are interested in, or you already track, and get involved there. Others will do the same, until all areas are covered.

For information on using Bugzilla, see the LegacyBugzilla page.

TODO:

  • How to proceed if there is new vulnerability in the same package which is already in the QA process but not released to updates yet.
  • How to go about proposing an updated package, and how that gets into the build system.
  • How to get a place to post updates to if you don't have sufficient local resources.