Mercurial > p > roundup > code
view doc/security.txt @ 8180:d02ce1d14acd
feat: issue2551068 - Provide way to retrieve file/msg data via rest endpoint.
Use Allow header to change format of /binary_content endpoint. If
Allow header for endpoint is not application/json, it will be matched
against the mime type for the file. */*, text/* are supported and will
return the native mime type if present.
Changes:
move */* mime type from static dict of supported types. It was
hardcoded to return json only. Now it can return a matching
non-json mime type for the /binary_content endpoint.
Edited some errors to explicitly add */* mime type.
Cleanups to use ', ' separation in lists of valid mime types rather
than just space separated.
Remove ETag header when sending raw content. See issue 2551375 for
background.
Doc added to rest.txt.
Small format fix up (add dash) in CHANGES.txt.
Make passing an unset/None/False accept_mime_type to
format_dispatch_output a 500 error. This used to be the fallback
to produce a 406 error after all processing had happened. It
should no longer be possible to take that code path as all 406
errors (with valid accept_mime_types) are generated before
processing takes place.
Make format_dispatch_output handle output other than json/xml so it
can send back binary_content data.
Removed a spurious client.response_code = 400 that seems to not be
used.
Tests added for all code paths.
Database setup for tests msg and file entry. This required a file
upload test to change so it doesn't look for file1 as the link
returned by the upload. Download the link and verify the data
rather than verifying the link.
Multiple formatting changes to error messages to make all lists of
valid mime types ', ' an not just space separated.
| author | John Rouillard <rouilj@ieee.org> |
|---|---|
| date | Sun, 08 Dec 2024 17:22:33 -0500 |
| parents | 4dfc07ee489a |
| children | abf1297e7a94 |
line wrap: on
line source
.. meta:: :description: Documentation on how to report security issues with Roundup. Index to recent security related (CVE) descriptions in other Roundup documentation. How to verify distribution using gpg. .. index:: single: Reporting Security Issues single: CVE announcements single: Security Issues, Reporting single: Security Issues, Remediation single: Security Issues, CVE announcements ======================= Roundup Security Issues ======================= This page documents CVE's fixed starting with version 2.4.0, how to report security issues, and verify the signatures for Roundup source release tarballs. .. contents:: :local: :depth: 2 CVE Announcements ----------------- * `CVE-2024-39124`_ - :ref:`classhelpers (_generic.help.html) are vulnerable to an XSS attack. <CVE-2024-39124>` Requires fixing tracker homes. * `CVE-2024-39125`_ - :ref:`if Referer header is set to a script tag, it will be executed. <CVE-2024-39125>` Fixed in release 2.4.0, directions available for fixing in prior versions. * `CVE-2024-39126`_ - :ref:`PDF, XML and SVG files downloaded from an issue can contain embedded JavaScript which is executed. <CVE-2024-39126>` Fixed in release 2.4.0, directions available for fixing in prior versions. .. _CVE-2024-39124: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-39124 .. _CVE-2024-39125: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-39125 .. _CVE-2024-39126: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-39126 Reporting Security Issues ------------------------- Security issues with Roundup should be reported by email to: rouilj@users.sourceforge.net (John Rouillard) rsc@runtux.com (Ralf Schlatterbeck) If these fail, you can find rouilj on irc in channel #roundup at irc.oftc.net (see Contact_ for more directions and web interface). Methods listed at Contact_ are all public, so they should be used to contact somebody with the Roundup project for establishing a proper method of reporting the security issue. .. _Contact: https://www.roundup-tracker.org/contact.html Verify Source Tarball --------------------- .. index:: single: Distribution, verify with gpg single: Signature, verify If you download the source tarball using ``python3 -m pip download roundup`` or from https://pypi.org/project/roundup/#files you can verify the file using gpg. This is the information on the public PGP/GPG key used to sign Roundup distributions. It is used to sign the 1.6.0, 2.2.0, and newer releases. (Note that the @ sign in email addresses have been replaced with the word "at" to reduce spam directed at the mailing list.):: Key info: Roundup Team (signing key for roundup releases) <roundup-devel at lists.sourceforge.net> Expires: 2028-07-17 Key fingerprint = 411E 354B 5D1A F261 25D6 2122 1F2D D0CB 756A 76D8 Releases 1.6.1, 2.0.0 and 2.1.0 were accidentally signed with this key [1]_:: Key info: John Rouillard (Roundup Release Key) <rouilj+roundup at ieee.org> Expires: 2023-07-09 Key fingerprint = A1E6 364E 9429 E9D8 2B3B 2373 DB05 ADC4 2330 5876 .. [1] Use gpg to import this key from the keyserver pgp.mit.edu if you need to verify one of these releases. Use the gpg pgp.mit.edu keyserver example replacing the key fingerprint with the one starting A1E6. Importing the Public Key ~~~~~~~~~~~~~~~~~~~~~~~~ This only has to be added to your keyring once. You can import a key from pgp.mit.edu using:: gpg --keyserver pgp.mit.edu --receive-keys 411E354B5D1AF26125D621221F2DD0CB756A76D8 where the fingerprint (without spaces) is used to identify which key to receive. You can also extract and import the file ``tools/roundup.public.pgp.key`` from the download source tarball using:: tar -xzvf roundup-2.2.0.tar.gz -O \ roundup-2.2.0/tools/roundup.public.pgp.key > pub.key gpg --import pub.key Once you have loaded the public key, you need a detached signature for your release. Download Detached Signature and Verify ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This needs to be done once for each release you wish to verify. The Python Package Index (PyPI) used to support uploading gpg detached signatures. However that is no longer supported and downloading existing signatures may not work in the future. As a result, the signatures for all Roundup final releases starting with 1.6.0 have been moved and are linked below: .. rst-class:: multicol * `2.4.0 <../signatures/roundup-2.4.0.tar.gz.asc>`_ * `2.4.0b2 <../signatures/roundup-2.4.0b2.tar.gz.asc>`_ * `2.3.0 <../signatures/roundup-2.3.0.tar.gz.asc>`_ * `2.3.0b2 <../signatures/roundup-2.3.0b2.tar.gz.asc>`_ * `2.2.0 <../signatures/roundup-2.2.0.tar.gz.asc>`_ * `2.1.0 <../signatures/roundup-2.1.0.tar.gz.asc>`_ * `2.0.0 <../signatures/roundup-2.0.0.tar.gz.asc>`_ * `1.6.1 <../signatures/roundup-1.6.1.tar.gz.asc>`_ * `1.6.0 <../signatures/roundup-1.6.0.tar.gz.asc>`_ To use the signature, download the correct versioned link and verify it with (note 1.5.7 is a dummy version, use the correct version number):: gpg --verify roundup-1.5.7.tar.gz.asc roundup-1.5.7.tar.gz You should see:: gpg: Signature made Wed 13 Jul 2022 12:24:14 AM EDT gpg: using RSA key 411E354B5D1AF26125D621221F2DD0CB756A76D8 gpg: Good signature from "Roundup Team (signing key for roundup releases) <roundup-devel at lists.sourceforge.net>" [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 411E 354B 5D1A F261 25D6 2122 1F2D D0CB 756A 76D8 which verifies the tarball integrity. The WARNING is expected and the date corresponds to the newest renewal of the Roundup key. As long as you see the output starting with "Good signature from" followed by the Key Info for your key, everything is OK. If something is wrong you will see:: gpg: Signature made Wed 13 Jul 2022 12:24:14 AM EDT gpg: using RSA key 411E354B5D1AF26125D621221F2DD0CB756A76D8 gpg: BAD signature from "Roundup Team (signing key for roundup releases) <roundup-devel at lists.sourceforge.net>" **do not use** the tarball if the signature is BAD. Email the mailing list: roundup-devel at lists.sourceforge.net if you have this happen to you.