Mercurial > p > roundup > code
view doc/security.txt @ 8411:ef1ea918b07a reauth-confirm_id
feat(security): Add user confirmation/reauth for sensitive changes
Auditors can raise Reauth(reason) exception to require the user to
enter a token (e.g. account password) to verify the user is performing
the change.
Naming is subject to change.
actions.py: New ReauthAction class handler and verifyPassword() method
for overriding if needed.
client.py: Handle Reauth exception by calling Client:reauth() method.
Default client:reauth method. Add 'reauth' action declaration.
exceptions.py: Define and document Reauth exception as a subclass of
RoundupCGIException.
templating.py: Define method utils.embed_form_fields().
The original form making a change to the database has a lot of form
fields. These need to be resubmitted to Roundup as part of the form
submission that verifies the user's password.
This method turns all non file form fields into type=hidden inputs.
It escapes the names and values to prevent XSS.
For file form fields, it base64 encodes the contents and puts them
in hidden pre blocks. The pre blocks have data attributes for the
filename, filetype and the original field name. (Note the original
field name is not used.)
This stops the file content data (maybe binary e.g. jpegs) from
breaking the html page. The reauth template runs JavaScript that
turns the encoded data inside the pre tags back into a file. Then
it adds a multiple file input control to the page and attaches all
the files to it. This file input is submitted with the rest of the
fields.
_generic.reauth.html (multiple tracker templates): Generates a form
with id=reauth_form to:
display any message from the Reauth exception to the user (e.g. why
user is asked to auth).
get the user's password
submit the form
embed all the form data that triggered the reauth
recreate any file data that was submitted as part of the form and
generate a new file input to push the data to the back end
It has the JavaScript routine (as an IIFE) that regenerates a file
input without user intervention.
All the TAL based tracker templates use the same form. There is also
one for the jinja2 template. The JavaScript for both is the same.
reference.txt: document embed_form_fields utility method.
upgrading.txt: initial upgrading docs.
TODO:
Finalize naming. I am leaning toward ConfirmID rather than Reauth.
Still looking for a standard name for this workflow.
Externalize the javascript in _generic.reauth.html to a seperate file
and use utils.readfile() to embed it or change the script to load it
from a @@file url.
Clean up upgrading.txt with just steps to implement and less feature
detail/internals.
Document internals/troubleshooting in reference.txt.
Add tests using live server.
| author | John Rouillard <rouilj@ieee.org> |
|---|---|
| date | Mon, 11 Aug 2025 14:01:12 -0400 |
| parents | c7a2e01793cd |
| children |
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-2025-53865`_ - :ref:`XSS security issue with devel or responsive templates <CVE-2025-53865>`. Fixed in release 2.5.0, directions available for fixing trackers based on these templates. * `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-2025-53865: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-53865 .. _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.5.0 <../signatures/roundup-2.5.0.tar.gz.asc>`_ * `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. The date should be close to the release date of the version of Roundup. As long as you see the output starting with "Good signature from" followed by the Key Info above, 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.