Security and GNU

Reporting security issues

To report a security bug against a given package, please follow the bug-reporting guidelines for the package. If there are no security-specific instructions, just follow the general bug reporting instructions. If you don't think your report should be public, email the maintainers individually. The package web pages and/or Free Software Directory entry should provide contact information.

If you've reported an urgent security bug and there hasn't been any response in an appropriate amount of time, you can escalate to the general security mailing list for advice. You can also write there for help if you cannot find maintainer contact information. If you don't get an answer there either, as a last-ditch effort you can try <maintainers@gnu.org>.

Public security discussions

To discuss general security topics and questions (not report bugs), you can use the security-discuss mailing list. Its purpose is to provide a place to discuss security matters that are applicable to more than one project. For example, general secure programming techniques, cryptography, and network protocol issues.

Software authenticity and integrity

You can check that the software you downloaded is authentic by verifying the file's signature, normally stored along with the release archive on https://ftp.gnu.org/. To check the integrity of the downloaded file, compare the checksum with the release announcement for that particular software release, which are normally posted to the info-gnu mailing list.

The GNU Project recommends GnuPG to sign and verify signatures.

Use a .sig file to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding tarball. Then, run a command like this:

gpg --verify inetutils-2.3.tar.gz.sig

It will print a fingerprint of the key(s) used to sign the archive. They should match the fingerprint of the maintainer who released that particular version for that particular project.

If the command fails because you don't have the required public key, or that public key has expired, there are a number of ways to get the key:

• Use GnuPG's modern way to locate and download keys, for example if the maintainer's email address is simon@josefsson.org you would use:

  gpg --locate-external-key simon@josefsson.org

• Use the traditional OpenPGP key server infrastructure, which in recent years have become more unreliable, start with:

  gpg --recv-keys F8C4D73CF638C53C06BE

  and if it does not work add --keyserver for some public OpenPGP key server, like this:

  gpg --keyserver pgp.mit.edu --recv-keys F8C4D73CF638C53C06BE

• Download the key from the Savannah project page, which should contain current PGP keys, for example (using wget):

  wget -q -O- 'https://savannah.gnu.org/project/release-gpgkeys.php?group=inetutils&download=1' | gpg --import -

  To download the keys of all registered maintainers of a project, use instead:

  wget -q -O- https://savannah.gnu.org/project/memberlist-gpgkeys.php?group=inetutils&download=1 | gpg --import

• As a last resort to find the key, you can try the official GNU keyring:

  wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg
  gpg --keyring gnu-keyring.gpg --verify inetutils-2.3.tar.gz.sig

To confirm the integrity of the release, you can compute the checksum of the archive and compare it with the release announcement. Assuming you downloaded the file inetutils-2.3.tar.gz, you can run the sha1sum command (from Coreutils) like this:

sha1sum inetutils-2.3.tar.gz

Check that the output match what is printed in the release announcement, which may look like this:

cd728a91f03c5bd3c7a8d210904bb55e315ca0cd  inetutils-2.3.tar.gz

To avoid having to manual compare the string, you may use the sha1sum -c parameter, as follows:

echo 'cd728a91f03c5bd3c7a8d210904bb55e315ca0cd  inetutils-2.3.tar.gz'|sha1sum -c