Mercurial > p > roundup > code
changeset 7109:561c66232347
Merge
| author | Ralf Schlatterbeck <rsc@runtux.com> |
|---|---|
| date | Thu, 08 Dec 2022 11:18:46 +0100 |
| parents | b26207712c2b (current diff) 8e2219abbde3 (diff) |
| children | 0597120e0a74 |
| files | |
| diffstat | 16 files changed, 401 insertions(+), 213 deletions(-) [+] |
line wrap: on
line diff
--- a/.github/workflows/ci-test.yml Thu Dec 08 11:17:07 2022 +0100 +++ b/.github/workflows/ci-test.yml Thu Dec 08 11:18:46 2022 +0100 @@ -3,7 +3,8 @@ # reference docs: # https://blog.deepjyoti30.dev/tests-github-python # https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-python -# +# https://github.com/pypa/twine/blob/main/.github/workflows/main.yml + name: roundup-ci on: @@ -44,30 +45,36 @@ max-parallel: 4 matrix: # Run in all these versions of Python - python-version: [ "2.7", "3.10", "3.9", "3.8", "3.6", "3.11-dev" ] + python-version: + - "2.7" + - "3.10" + - "3.9" + - "3.8" + - "3.7" + - "3.11" # use for multiple os or ubuntu versions #os: [ubuntu-latest, macos-latest, windows-latest] - os: [ubuntu-latest, ubuntu-22.04] + # ubuntu latest 22.04 12/2022 + os: [ubuntu-latest, ubuntu-20.04] # if the ones above fail. fail the build experimental: [false] include: - # example: if 3.12 fails the jobs still succeeds - # - python-version: 3.12 - # experimental: [true] - # version 2.7 not available on unbuntu-22.04 github - # - python-version: 2.7 - # os: ubuntu-22.04 - # experimental: true - - python-version: 3.11-dev + # example: if 3.12 fails the jobs still succeeds + - python-version: 3.12-dev os: ubuntu-22.04 experimental: [true] + - python-version: 3.11-dev + os: ubuntu-20.04 + # 3.6 not available on new 22.04 runners, so run on 20.04 ubuntu + - python-version: 3.6 + os: ubuntu-20.04 exclude: - # skip all python versions on 22.04 except explicitly included - - os: ubuntu-22.04 + # skip all python versions on 20.04 except explicitly included + - os: ubuntu-20.04 env: # get colorized pytest output even without a controlling tty
--- a/CHANGES.txt Thu Dec 08 11:17:07 2022 +0100 +++ b/CHANGES.txt Thu Dec 08 11:18:46 2022 +0100 @@ -50,6 +50,11 @@ more than one issue with a matching parent message, fall back to subject matching. See upgrading.txt for details. (John Rouillard) - issue2551195 - port scripts from optparse to argparse (Ralf Schlatterbeck) +- issue2551246 - mitigation, document how -u doesn't work for + roundup-admin. (John Rouillard) +- Document better that files in the template or static_files + directories accessed via @@file are available to any user with the + url. Features: @@ -182,6 +187,9 @@ if the user doesn't have edit permissions. (John Rouillard) - issue2551216 - create new mysql databases using COLLATE utf8_general_ci to prevent crashes in test suite. (John Rouillard) +- issue2551146 - fix issues with strings that have multiple %s + substutions that were not labeled making i18n difficult/impossible. + (John Rouillard) Features:
--- a/doc/admin_guide.txt Thu Dec 08 11:17:07 2022 +0100 +++ b/doc/admin_guide.txt Thu Dec 08 11:18:46 2022 +0100 @@ -878,6 +878,22 @@ Run ``roundup-admin help commands`` for a complete list of subcommands. +One thing to note, The ``-u user`` setting does not currently operate +like a user logging in via the web. The user running roundup-admin +must have read access to the tracker home directory. As a result the +user has access to the files and the database info contained in +config.ini. + +Using ``-u user`` sets the actor/user parameter in the +journal. Changes that are made are attributed to that +user. The password is ignored if provided. Any existing +username has full access to the data just like the admin +user. This is an area for further development so that +roundup-admin could be used with sudo to provide secure +command line access to a tracker. + +In general you should forget that there is a -u parameter. + .. _`customisation documentation`: customizing.html .. _`upgrading documentation`: upgrading.html .. _`installation documentation`: installation.html
--- a/doc/customizing.txt Thu Dec 08 11:17:07 2022 +0100 +++ b/doc/customizing.txt Thu Dec 08 11:18:46 2022 +0100 @@ -2309,6 +2309,16 @@ See the previous section `determining web context`_ where it describes ``@@file`` paths. +These files are served without any permission checks. Any user on the +internet with the url can download the file. + +This is rarely an issue since the html templates are just source code +and much of it can be found in the Roundup repository. Other +decoration (logos, stylesheets) are similarly not security sensitive. +You can use the static_files setting in config.ini to eliminate +access to the templates directory if desired. + +If a file resolves to a symbolic link, it is not served. Performing actions in web requests ----------------------------------
--- a/doc/developers.txt Thu Dec 08 11:17:07 2022 +0100 +++ b/doc/developers.txt Thu Dec 08 11:18:46 2022 +0100 @@ -4,73 +4,120 @@ .. note:: The intended audience of this document is the developers of the core - Roundup code. If you just wish to alter some behaviour of your Roundup - installation, see `customising roundup`_. + Roundup code. If you just wish to alter some behavior of your Roundup + installation, see `Customising Roundup`_. Contents .. contents:: :local: -If you are looking for info on managing the roundup-tracker.org -infrastructure, that information has migrated to website/README.txt -in the roundup repo. Getting Started --------------- -Anyone wishing to help in the development of Roundup must read `Roundup's -Design Document`_ and the `implementation notes`_. +If you are looking for a good first issue, search for `StarterTicket +on https://issues.Roundup-tracker.org`_. These include issues where +Python development, Documentation or Web design skills are useful. + +You can continue the conversation using the issue or join the +Roundup-devel list to get assistance and verify your planned changes. All development is coordinated through two resources: -- roundup-devel mailing list at - https://sourceforge.net/projects/roundup/lists/roundup-devel +- Roundup-devel mailing list at + https://sourceforge.net/projects/Roundup/lists/Roundup-devel - The issue tracker running at - https://issues.roundup-tracker.org/ + https://issues.Roundup-tracker.org/ + +In addition, the Roundup IRC channel on irc.oftc.net can be accessed +via the web interface shown on the Contact page. The channel is logged +and the web sites for the logs are shown in the channel topic. You can +ask questions and use it to coordinate work discussed using the +resources above. + +Anyone wishing to help in the development of the Roundup Python core +may find `Roundup's Design Document`_ and the `implementation notes`_ +helpful. + +People working on Documentation or designing changes to the Web +interface don't need to get into the implementation internals. Small Changes ------------- Most small changes can be submitted as patches through the -`issue tracker`_ or sent to `roundup-devel mailing list`_. - - -Source Repository Access ------------------------- - -See https://www.roundup-tracker.org/code.html. -For all other questions ask on the development mailinglist. +`issue tracker`_ or sent to `Roundup-devel mailing list`_. Project Rules ------------- -Mostly the project follows Guido's Style (though naming tends to be a little -relaxed sometimes). In short: +Be polite to others. There is no place for ad hominem attacks. + +Mostly the project follows Guido's Python Style (though naming tends +to be a little relaxed sometimes). In short: - 80 column width code - 4-space indentations -- All modules must have an Id line near the top Other project rules: -- New functionality must be documented, even briefly (so at least we know - where there's missing documentation) and changes to tracker configuration - must be logged in the upgrading document. -- subscribe to roundup-checkins to receive checkin notifications from the - other developers with write access to the source-code repository. -- discuss any changes with the other developers on roundup-dev. If nothing - else, this makes sure there's no rude shocks -- write unit tests for changes you make (where possible), and ensure that - all unit tests run before committing changes -- run pychecker over changed code +- new functionality must be documented, even briefly (so at + least we know where there's missing documentation) and + changes to tracker configuration must be logged in the + upgrading document. +- discuss any changes with the other developers on + Roundup-dev. If nothing else, this makes sure there's no + rude shocks. +- write unit tests for changes you make (where possible), + and ensure that all unit tests run before committing + changes. +- run flake8_ or pylint_ over changed code. +- if you have direct commit access to the repository, + subscribe to Roundup-checkins to receive checkin + notifications from the other developers with write access + to the source-code repository. + +The goal is to have no flake8 issues. Current code does include long +lines and use of mutable objects in function signatures. Some third +party code (e.g. ZPT) vendored into the codebase has more issues. The administrators of the project reserve the right to boot developers who consistently check in code which is either broken or takes the codebase in directions that have not been agreed to. +Source Repository Access +------------------------ + +Roundup is developed using the `Mercurial distributed version control +system (DVCS)`_ [1]_. It is `hosted at Sourceforge`_. See +https://www.Roundup-tracker.org/code.html for details. +For all other questions ask on the development mailing list. + +Other Resources - CI, Code Coverage +----------------------------------- + +Roundup has a `copy of the mercurial repository on GitHub`_. It is +updated manually after every few commits to the Mercurial +repository. Updates trigger the CI pipeline which happens on two +services: + + 1. `GitHub Actions`_. It runs Docker container scans using Anchore as + well as security scans for dependencies using CodeQL. Also it + runs the test suite on multiple versions of Python. + 2. `TravisCI`_ is also used to run CI. It runs the test suite on + multiple Python versions. It also provides alpha and development + Python releases faster than GitHub. + +GitHub actions upload coverage statistics to both `CodeCov`_ and +`Coveralls`_. TravisCI only uploads to CodeCov. + +We run our own issue tracker so we can dogfood the code. So we do not +use GitHub issues. Pull requests are grudgingly accepted. They have to +be exported and applied to the Mercurial repository. This is time +consuming so patches attached to the issue are preferred. Debugging Aids -------------- @@ -126,7 +173,7 @@ This chapter is full of references to GNU `gettext package`_. GNU gettext is a "must have" for nearly all steps of internationalizing -any program, and it's manual is definetely a recommended reading +any program, and it's manual is definitely a recommended reading for people involved in `I18N`_. There are GNU gettext ports to all major OS platforms. @@ -269,7 +316,7 @@ will translate the caption (and return value) for the "wink" button. * explicit msgids. Sometimes it may be useful to specify msgid - for the element translation explicitely, like this:: + for the element translation explicitly, like this:: <span i18n:translate="know what i mean?">this text is ignored</span> @@ -400,6 +447,11 @@ At run time, Roundup automatically compiles message catalogs whenever `PO`_ file is changed. +.. [1] Roundup is written in Python and we believe in using tools in + the Python ecosystem whenever possible. + + + .. _`Customising Roundup`: customizing.html .. _`Roundup's Design Document`: spec.html .. _`implementation notes`: implementation.html @@ -409,33 +461,47 @@ .. _alexander smishlajev: .. _als: https://sourceforge.net/u/a1s/profile/ +.. _CodeCov: https://app.codecov.io/gh/roundup-tracker/roundup +.. _copy of the mercurial repository on GitHub: + https://github.com/roundup-tracker/roundup +.. _Coveralls: https://coveralls.io/github/roundup-tracker/roundup .. _cygwin: https://www.cygwin.com/ .. _emacs: https://www.gnu.org/software/emacs/ -.. _gettext package: http://www.gnu.org/savannah-checkouts/gnu/gettext/manual/gettext.html +.. _flake8: https://flake8.pycqa.org/en/latest/ +.. _gettext package: https://www.gnu.org/savannah-checkouts/gnu/gettext/manual/gettext.html .. _gettext module: https://docs.python.org/2/library/gettext.html -.. _GNU: http://www.gnu.org/ -.. _GNU mirror sites: http://www.gnu.org/prep/ftp.html +.. _GitHub Actions: https://github.com/roundup-tracker/roundup/actions +.. _GNU: https://www.gnu.org/ +.. _GNU mirror sites: https://www.gnu.org/prep/ftp.html +.. _hosted at sourceforge: + https://sourceforge.net/p/roundup/code/ci/default/tree/ .. _issue tracker: https://issues.roundup-tracker.org/ .. _Lokalize: https://apps.kde.org/lokalize/ .. _KDE: https://kde.org/ .. _linux: https://www.linux.org/ +.. _Mercurial distributed version control system (DVCS): + https://www.mercurial-scm.org/ .. _Plural Forms: - http://www.gnu.org/savannah-checkouts/gnu/gettext/manual/gettext.html + https://www.gnu.org/savannah-checkouts/gnu/gettext/manual/gettext.html .. _po filetype plugin: https://vim.sourceforge.io/scripts/script.php?script_id=695 .. _PO utilities: https://github.com/pinard/po-utils .. _poEdit: https://poedit.net/ +.. _pylint: https://pylint.pycqa.org/en/latest/ .. _Roundup Source: .. _Roundup source distribution: .. _Roundup binary distribution: https://sourceforge.net/projects/roundup/files/ .. _roundup-devel mailing list: https://sourceforge.net/projects/roundup/lists/roundup-devel +.. _StarterTicket on https://issues.roundup-tracker.org: + https://issues.roundup-tracker.org/issue?@columns=title,id,activity,status&@sort=activity&@filter=status,keywords&status=-1,1,2&keywords=15&@dispname=Starter%20tickets .. _TAL: .. _Template Attribute Language: https://pagetemplates.readthedocs.io/en/latest/history/TALSpecification14.html .. _TALES: .. _Template Attribute Language Expression Syntax: https://pagetemplates.readthedocs.io/en/latest/history/TALESSpecification13.html +.. _TravisCI: https://app.travis-ci.com/github/roundup-tracker/roundup .. _vim: https://www.vim.org/ .. _ZPTInternationalization: http://grok.zope.org/documentation/how-to/how-to-internationalize-your-application/view
--- a/doc/index.txt Thu Dec 08 11:17:07 2022 +0100 +++ b/doc/index.txt Thu Dec 08 11:18:46 2022 +0100 @@ -17,23 +17,25 @@ features installation upgrading + security FAQ user_guide customizing admin_guide + security debugging xmlrpc rest - overview + tracker_templates + glossary + acknowledgements + license + Design Overview <overview> Design (original) <design> developers - tracker_templates Notes about the MySQL Database backend <mysql> Notes about the PostgreSQL Database backend <postgresql> - glossary - acknowledgements Richard Jones implementation notes <implementation> - license See: https://wiki.roundup-tracker.org/ReleaseErrata for fixes to documentation.
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/security-history.txt Thu Dec 08 11:18:46 2022 +0100 @@ -0,0 +1,163 @@ +.. meta:: + :description: + Security mechanism implementation document for historical purposes. + +:orphan: + +=================== +Security Mechanisms +=================== + +Current situation +================= + +Current logical controls: + +ANONYMOUS_ACCESS = 'deny' + Deny or allow anonymous access to the web interface +ANONYMOUS_REGISTER = 'deny' + Deny or allow anonymous users to register through the web interface +ANONYMOUS_REGISTER_MAIL = 'deny' + Deny or allow anonymous users to register through the mail interface + +Current user interface authentication and controls: + +- command-line tool access controlled with passwords, but no logical controls +- CGI access is by username and password and has some logical controls +- mailgw access is through identification using sender email address, with + limited functionality available + +The web interface implements has specific logical controls, +preventing non-admin users from accessing: + + - other user's details pages + - listing the base classes (not issues or their user page) + - editing base classes + +Issues +====== + +1. The current implementation is ad-hoc, and not complete for all use cases. +2. Currently it is not possible to allow submission of issues through email + but restrict those users from accessing the web interface. +3. Only one user may perform admin functions. +4. There is no verification of users in the mail gateway by any means other + than the From address. Support for strong identification through digital + signatures should be added. +5. The command-line tool has no logical controls. +6. The anonymous control needs revising - there should only be one way to be + an anonymous user, not two (currently there is user==None and + user=='anonymous'). + + +Possible approaches +=================== + +Security controls in Roundup could be approached in three ways: + +1) at the hyperdb level, with read/write/modify permissions on classes, items + and item properties for all or specific transitions. +2) at the user interface level, with access permissions on CGI interface + methods, mailgw methods, roundup-admin methods, and so on. +3) at a logical permission level, checked as needed. + +In all cases, the security built into roundup assumes restricted access to the +hyperdatabase itself, through operating-system controls such as user or group +permissions. + + +Hyperdb-level control +--------------------- + +Control is implemented at the Class.get, Class.set and Class.create level. All +other methods must access items through these methods. Since all accesses go +through the database, we can implement deny by default. + +Pros: + + - easier to implement as it only affects one module + - smaller number of permissions to worry about + +Cons: + + - harder to determine the relationship between user interaction and hyperdb + permission. + - a lot of work to define + - must special-case to handle by-item permissions (editing user details, + having private messages) + + +User-interface control +---------------------- + +The user interfaces would have an extra layer between that which +parses the request to determine action and the action method. This layer +controls access. Since it is possible to require methods be registered +with the security mechanisms to be accessed by the user, deny by default +is possible. + +Pros: + + - much more obvious at the user level what the controls are + +Cons: + + - much more work to implement + - most user interfaces have multiple uses which can't be covered by a + single permission + +Logical control +--------------- + +At each point that requires an action to be performed, the security mechanisms +are asked if the current user has permission. Since code must call the +check function to raise a denial, there is no possibility to have automatic +default of deny in this situation. + +Pros: + + - quite obvious what is going on + - is very similar to the current system + +Cons: + + - large number of possible permissions that may be defined, possibly + mirroring actual user interface controls. + - access to the hyperdb must be strictly controlled through program code + that implements the logical controls. + + +Action +====== + +The CGI interface must be changed to: + +- authenticate over a secure connection +- use unique tokens as a result of authentication, rather than pass the user's + real credentials (username/password) around for each request (this means + sessions and hence a session database) +- use the new logical control mechanisms + + - implement the permission module + - implement a Role editing interface for users + - implement htmltemplate tests on permissions + - switch all code over from using config vars for permission checks to using + permissions + - change all explicit admin user checks for Role checks + - include config vars for initial Roles for anonymous web, new web and new + email users + +The mail gateway must be changed to: + +- use digital signatures +- use the new logical control mechanisms + + - switch all code over from using config vars for permission checks to using + permissions + +The command-line tool must be changed to: + +- use the new logical control mechanisms (only allowing write + access by admin users, and read-only by everyone else) + +
--- a/doc/security.txt Thu Dec 08 11:17:07 2022 +0100 +++ b/doc/security.txt Thu Dec 08 11:18:46 2022 +0100 @@ -1,157 +1,27 @@ -=================== -Security Mechanisms -=================== - -Current situation -================= - -Current logical controls: - -ANONYMOUS_ACCESS = 'deny' - Deny or allow anonymous access to the web interface -ANONYMOUS_REGISTER = 'deny' - Deny or allow anonymous users to register through the web interface -ANONYMOUS_REGISTER_MAIL = 'deny' - Deny or allow anonymous users to register through the mail interface - -Current user interface authentication and controls: - -- command-line tool access controlled with passwords, but no logical controls -- CGI access is by username and password and has some logical controls -- mailgw access is through identification using sender email address, with - limited functionality available - -The web interface implements has specific logical controls, -preventing non-admin users from accessing: - - - other user's details pages - - listing the base classes (not issues or their user page) - - editing base classes +.. meta:: + :description: + Documentation on how to report security issues with + Roundup. Also index to security related portions in other + Roundup documentation. -Issues -====== - -1. The current implementation is ad-hoc, and not complete for all use cases. -2. Currently it is not possible to allow submission of issues through email - but restrict those users from accessing the web interface. -3. Only one user may perform admin functions. -4. There is no verification of users in the mail gateway by any means other - than the From address. Support for strong identification through digital - signatures should be added. -5. The command-line tool has no logical controls. -6. The anonymous control needs revising - there should only be one way to be - an anonymous user, not two (currently there is user==None and - user=='anonymous'). - - -Possible approaches -=================== - -Security controls in Roundup could be approached in three ways: - -1) at the hyperdb level, with read/write/modify permissions on classes, items - and item properties for all or specific transitions. -2) at the user interface level, with access permissions on CGI interface - methods, mailgw methods, roundup-admin methods, and so on. -3) at a logical permission level, checked as needed. - -In all cases, the security built into roundup assumes restricted access to the -hyperdatabase itself, through operating-system controls such as user or group -permissions. +.. index:: + single: Reporting Security Issues + single: Security Issues, Reporting -Hyperdb-level control ---------------------- - -Control is implemented at the Class.get, Class.set and Class.create level. All -other methods must access items through these methods. Since all accesses go -through the database, we can implement deny by default. - -Pros: - - - easier to implement as it only affects one module - - smaller number of permissions to worry about - -Cons: - - - harder to determine the relationship between user interaction and hyperdb - permission. - - a lot of work to define - - must special-case to handle by-item permissions (editing user details, - having private messages) - - -User-interface control ----------------------- +====================================== +Reporting Security Issues with Roundup +====================================== -The user interfaces would have an extra layer between that which -parses the request to determine action and the action method. This layer -controls access. Since it is possible to require methods be registered -with the security mechanisms to be accessed by the user, deny by default -is possible. - -Pros: - - - much more obvious at the user level what the controls are - -Cons: +Security issues with Roundup should be reported by email to: - - much more work to implement - - most user interfaces have multiple uses which can't be covered by a - single permission - -Logical control ---------------- - -At each point that requires an action to be performed, the security mechanisms -are asked if the current user has permission. Since code must call the -check function to raise a denial, there is no possibility to have automatic -default of deny in this situation. + rouilj@users.sourceforge.net (John Rouillard) -Pros: - - - quite obvious what is going on - - is very similar to the current system - -Cons: - - - large number of possible permissions that may be defined, possibly - mirroring actual user interface controls. - - access to the hyperdb must be strictly controlled through program code - that implements the logical controls. - - -Action -====== - -The CGI interface must be changed to: - -- authenticate over a secure connection -- use unique tokens as a result of authentication, rather than pass the user's - real credentials (username/password) around for each request (this means - sessions and hence a session database) -- use the new logical control mechanisms + rsc@runtux.com (Ralf Schlatterbeck) - - implement the permission module - - implement a Role editing interface for users - - implement htmltemplate tests on permissions - - switch all code over from using config vars for permission checks to using - permissions - - change all explicit admin user checks for Role checks - - include config vars for initial Roles for anonymous web, new web and new - email users - -The mail gateway must be changed to: +Also you can find rouilj on irc in channel #roundup at irc.oftc.net (see +Contact_ for more directions and web interface). -- use digital signatures -- use the new logical control mechanisms - - - switch all code over from using config vars for permission checks to using - permissions +Use these mechanisms to establish initial contact. -The command-line tool must be changed to: - -- use the new logical control mechanisms (only allowing write - access by admin users, and read-only by everyone else) - - +.. _Contact: https://www.roundup-tracker.org/contact.html
--- a/doc/upgrading.txt Thu Dec 08 11:17:07 2022 +0100 +++ b/doc/upgrading.txt Thu Dec 08 11:18:46 2022 +0100 @@ -3670,7 +3670,7 @@ .. _`customisation documentation`: customizing.html -.. _`security documentation`: security.html +.. _`security documentation`: security-history.html .. _`administration guide`: admin_guide.html .. _`xmlrpc guide`: xmlrpc.html .. _FTS5 full-text search engine: https://www.sqlite.org/fts5.html
--- a/doc/user_guide.txt Thu Dec 08 11:17:07 2022 +0100 +++ b/doc/user_guide.txt Thu Dec 08 11:18:46 2022 +0100 @@ -850,6 +850,20 @@ If either the name or password is not supplied, they are obtained from the command-line. +The ``-u user`` setting does not currently operate like a +user logging in via the web. The user running roundup-admin +must have read access to the tracker home directory. As a +result the user has access to the files and the database +info contained in config.ini. + +Using ``-u user`` sets the actor/user parameter in the +journal. Changes that are made are attributed to that +user. The password is ignored if provided. Any existing +username has full access to the data just like the admin +user. This is an area for further development so that +roundup-admin could be used with sudo to provide secure +command line access to a tracker. + When you initialise a new tracker instance you are prompted for the admin password. If you want to initialise a tracker non-interactively you can put the initialise command and password on the command
--- a/roundup/admin.py Thu Dec 08 11:17:07 2022 +0100 +++ b/roundup/admin.py Thu Dec 08 11:18:46 2022 +0100 @@ -240,7 +240,7 @@ . ROUNDUP_LOGIN environment variable . the -u command-line option If either the name or password is not supplied, they are obtained from the -command-line. +command-line. (See admin guide before using -u.) Date format examples: "2000-04-17.03:45" means <Date 2000-04-17.08:45:00>
--- a/roundup/cgi/client.py Thu Dec 08 11:17:07 2022 +0100 +++ b/roundup/cgi/client.py Thu Dec 08 11:18:46 2022 +0100 @@ -477,6 +477,9 @@ # flag to indicate that the HTTP headers have been sent self.headers_done = 0 + # record of headers sent for debugging + self.headers_sent = [] + # additional headers to send with the request - must be registered # before the first write self.additional_headers = {} @@ -495,6 +498,8 @@ self.nodeid = None self.classname = None self.template = None + self._ok_message = [] + self._error_message = [] def _gen_nonce(self): """ generate a unique nonce """
--- a/roundup/configuration.py Thu Dec 08 11:17:07 2022 +0100 +++ b/roundup/configuration.py Thu Dec 08 11:18:46 2022 +0100 @@ -991,13 +991,16 @@ "Path to the HTML templates directory."), (MultiFilePathOption, "static_files", "", "A list of space separated directory paths (or a single\n" - "directory). These directories hold additional static\n" - "files available via Web UI. These directories may\n" - "contain sitewide images, CSS stylesheets etc. If a '-'\n" - "is included, the list processing ends and the TEMPLATES\n" - "directory is not searched after the specified\n" + "directory). These directories hold additional public\n" + "static files available via Web UI. These directories\n" + "may contain sitewide images, CSS stylesheets etc. If a\n" + "'-' is included, the list processing ends and the\n" + "TEMPLATES directory is not searched after the specified\n" "directories. If this option is not set, all static\n" - "files are taken from the TEMPLATES directory."), + "files are taken from the TEMPLATES directory. Access to\n" + "these files is public, it is not checked against\n" + "registered users. So do not put any sensitive data in\n" + "the files in these directories."), (MailAddressOption, "admin_email", "roundup-admin", "Email address that roundup will complain to if it runs\n" "into trouble.\n"
--- a/share/man/man1/roundup-admin.1 Thu Dec 08 11:17:07 2022 +0100 +++ b/share/man/man1/roundup-admin.1 Thu Dec 08 11:18:46 2022 +0100 @@ -9,7 +9,9 @@ Specify the issue tracker "home directory" to administer .TP \fB-u\fP \fIuser\fP[\fB:\fP\fIpassword\fP] -The user and password to use for commands +The user and password to use for commands (partial implemention, see +Security Notes below). +.TP \fB-h\fP Print help text. .TP @@ -253,6 +255,28 @@ Commands may be abbreviated as long as the abbreviation matches only one command, e.g. l == li == lis == list. +.SH SECURITY NOTES + +The \fB-u user\fP setting does not currently operate like a +user logging in via the web. The user running roundup-admin +must have read access to the tracker home directory. As a +result the user has access to the files and the database +info contained in config.ini. + +Using \fB-u user\fP sets the actor/user parameter in the +journal. Changes that are made are attributed to that +user. The password is ignored if provided. Any existing +username has full access to the data just like the admin +user. This is an area for further development so that +roundup-admin could be used with sudo to provide secure +command line access to a tracker. + +.SH ENVIRONMENT VARIABLES + +.TP +\fBROUNDUP_LOGIN\fP +Provides an alternate way to set the user. + .SH FURTHER HELP roundup-admin -h roundup-admin help -- this help