Submitting Packages
If you decide to create update packages, the following is the procedure we suggest following in order to submit them for inclusion in the Fedora Legacy Project.
1. Identify the vulnerability and the solution for it. You may want to get some consensus on your approach with the Fedora Legacy members (e.g., by soliciting feedback on the Bugzilla entry) before you proceed if you are uncertain about anything.
2. Obtain the patch(es) needed to fix the vulnerability and update the package .spec file for the patch(es). For making QA easier, it's a good idea to re-use existing, publicly available patches and packages (especially from RHEL) as far as possible and reasonable.
3. Create your updated SRPM package. Use the latest update (by Red Hat, Fedora, or Fedora Legacy) as a basis. A Script may help to find the latest updates.
4. Check that your package conforms to the QA Checklist below. You may want to test build your package using mach or mock . See here for more info.
5. Sign the package with your GnuPG key (see PGPHowTo ). Do not use rpmbuild --sign but instead use rpm --addsign to sign the package.
6. Upload the package to a public server (preferably web accessible).
7. Submit a new Bugzilla entry (making sure you select Fedora Legacy for the package), which includes at least the following
- A direct URL to the SRPM package(s).
- sha1sum of the package(s)
- Short description of the package changes (usually a copy of the changelog in the .spec file).
- List and provide a link to the used sources, patches and/or advisories (unless they're already posted in previous comments for that bug).
- Ensure the StatusWhiteboard is set up properly. (Not everyone has Bugzilla privileges to be able to do this. If Bugzilla won't let you change it, don't worry about it, as all bugzilla items are reviewed by those who can change the StatusWhiteboard for you.
- The Bugzilla entry should be GnuPG signed ("gpg --clearsign"). (Bear in mind that it is often helpful to ensure that your text lines are not longer than 80 characters, as the Bugzilla web server will wrap lines > 80 chars and corrupt the posting so the GPG signature cannot be properly verified. Also bear in mind that failure to verify GPG signature never has held up progress on a Legacy bug ticket.)
QA Checklist
The following is a QA checklist (adapted from the fedora.us QAChecklist). This is simply a checklist of things that can be done for each source package during the package creation/modification process. Each package may have steps unique to that package which are not listed here.
(Please note that a lot of this checking may not be necessary for Legacy packages which are udpated from previously-existing Fedora Core packages, as most of these things should have already been done by the Core developer. Much of the below may be overkill for Legacy usage; but it is good to know of these items anyway.)
1. Are the sources from upstream pristine and free from trojans?
- Whenever possible verify GnuPG signatures, or even ask the upstream developers themselves to confirm the integrity of sources.
- Another good source is to look within SRPMS of other distributions.
2. Are the pre- and post-install and uninstall scripts correct?
- If it installs files named .so. into %{_libdir}, is there a %post -p /sbin/ldconfig and a %postun -p /sbin/ldconfig?
- If it has info files, is there a %post script which installs them, and a %postun script which removes them (and only on removal, not on an upgrade)?
- Do the scripts do anything which might be a security risk?
- Changing or adding root GnuPG keys.
- Changing existing firewall or tcp_wrapper settings.
- Creating accounts without proper security or with default passwords.
- Installing daemons which run as root, or as another standard user such as nobody, instead of as a dedicated user created for that deamon?
If so, at a minimum the installer must be warned about the issue during the install process. Preferably such issues should be removed if at all possible.
- If a daemon's configuration is changed, is the deamon restarted or forced to reload the configuration? If not, is a suitable message displayed to alert the installer about the changes?
3. Check for missing BuildRequires. For more information, see this posting. 4. Is the Group tag an official one? See /usr/share/doc/rpm-*/GROUPS. 5. Are all paths within the .spec replaced with macros? 6. If the package has a DesktopEntry, are the VFolder categories ok?
- See FedoraDesktopEntryGuidelines
- When the .spec uses desktop-file-install for to install menu entries, do not forget "BuildRequires: desktop-file-utils"
7. Does the package have any %{buildroot} macros? If so, they should be replaced with $RPM_BUILD_ROOT. 8. Does the package have any %{optflags} macros? If so, they should be replaced with $RPM_OPT_FLAGS. 9. Does the package install any unowned directories? Read the thread at http://www.fedora.us/pipermail/fedora-devel/2003-June/001458.html for details. 10. Parallel makes using -jX generally speed up builds, especially on SMP machines. This is correctly accomplished by using make %{?_smp_mflags} in .spec files. However, not all packages are parallel build clean. To catch some of these errors, packagers and QA testers may want to add %_smp_mflags -j3 to /.rpmmacros, even if they use UP machines. 11. Does the package naming scheme follow the Fedora Legacy RPM Versioning conventions?
(Disclaimer: QA checklist above copied on 10/23/2006 by D.Eisenstein from <http://web.archive.org/web/20040622150829/www.fedoralegacy.org/wiki/index.php/QaTesting>. Please note that it may be buggy or have wiki-links missing. If there are errors, please either fix them, bring them up on the fedora-legacy-list, or write me about them. Thanks!)