roundup-users — Go here to ask questions about how to use Roundup

[Roundup-users] Roundup 2.6.0 released

[John R. <ro...@ie...>]

Hello all:

I have uploaded 2.6.0 to pypi and a new docker image is also released.

I don't have access to the main web site at the moment. A ticket is
open with sourceforge. So hopefully the new docs will be deployed
sometime later today (July 13th).

Once the new docs are up I'll do another announcement. There are 14
items in the upgrading doc none of which are required. However the
first two items are
fixes for CVE's if you are running an older version of Roundup. Until
the new web site is up, you can look at the security page on the
current website to get the fixes.

I'm proud to release version 2.6.0 of the Roundup issue
tracker.  This release is a bugfix and feature release, so
make sure to read the upgrading doc at
https://www.roundup-tracker.org/docs/upgrading.html to
bring your tracker up to date.

The 49 changes, as usual, include some new features and many
bug fixes.

Version 2.6.0 requires Python version 3.10 or newer.

Note that you should run ``roundup-admin ... migrate`` to
update the database schema version. Do this before you use
the web, command-line or mail interface and before any users
access the tracker.

You can install it with::

   pip install roundup

(preferably in a virtual environment). To download it, use::

   pip download roundup

then unpack and test/install from the tarball.

Among the significant enhancements in version 2.6.0 compared to
the 2.5.0 release are:

* Fix old CSRF prevention for PATCH method

  The PATCH method was not covered by the old CSRF protection method.

* Filter history entries where permissions are handled by check function

  When a property's permission uses a check command, the history
  of changes for that property were shown. The permissions are now
  properly checked using the check function.

* Modern CSRF prevention method available

  This release implements CSRF protection using `Cross-Site Request
  Forgery by Filippo Valsorda <https://words.filippo.io/csrf/>`_.  This
  is an effective method for CSRF protection and is much simpler as
  well. There are no configurable options unlike the 8 options for the
  older method. This can be opted into using config.ini.

* Require reauthentication when making changes to sensitive fields

  You can trigger a reauthentication when the user changes particular
  fields. For example you can require a password be entered before the
  user changes their password.

* Classic UI interface modernization.

  The classic tracker has basic responsive support for mobile.  The
  table based layout was removed and HTML 5 landmarks (main, nav ...)
  are used along with flex and grid layouts.  The left hand menu now
  collapses to a grid layout in a single column when on a smaller
  display. This can be retrofitted to existing classic trackers.

  When you moved from one page to the next on an index, the
  query/search name was lost. This release now preserves the search
  name.

  Queries triggered from the query edit page now include the query
  name in the index view.

  The web UI now allows users to log in without a password. Before the
  password field was required which prevented completing the login
  action.

  The user.item.html template now generates valid javascript.

  The jinja2 template got an updated copy of bootstrap.

Other miscellaneous fixes include:

* Multiple internal cleanups:
  * remove some Python2 support code
  * reformat
  * refactor code replacing with faster/pythonic code
  * restructuring exception handling to stop ignoring important exceptions

* Documentation: wsgi updates replacing uwsgi (abandoned) with waitress
  (which also works on windows).

* rest updates with a null value no longer cause update failures.

The file CHANGES.txt has a detailed list of feature
additions and bug fixes for each release. You can view it at:
https://sourceforge.net/p/roundup/code/ci/default/tree/CHANGES.txt

-- rouilj

[Roundup-users] A little over 1 week for roundup release 2.6

[John R. <ro...@ie...>]

Hi all:

Just a reminder that a new release is due out on 7/13.

it's just a "pip roundup==2.6.0b1" away.

If you have any problems, now is the time to raise them.

-- rouilj

[Roundup-users] Roundup 2.6.0b1 release (and security notice)

[John P. R. <ro...@cs...>]

Hello all:

I have released roundup-2.6.0b1 for evaluation. I plan on a 2.6.0
release mid July. Release 2.6.0 requires Python version 3.10 or newer.

The announcement is at:

   https://www.roundup-tracker.org/dev_docs/docs/announcement.html

This fixes two CVE's (no numbers assigned yet by Mitre, still waiting
for them to respond to my request from a month ago, if anybody has a
contact there let me know.)

  1) The PATCH method is not properly protected from CSRF. This
     affects all versions since 2.0.0 when rest support was added and
     the PATCH verb became meaningful.

  2) The item history display does not use the check function of
     permissions. As a result some property changes are shown when
     they should not be. The current value of the property is still
     protected, only prior values are displayed.

These are fixed in version 2.6.0. Directions on fixing earlier
versions are linked from:

    https://www.roundup-tracker.org/docs/security.html.

The full set of 2.6.0b1 docs is at:

    https://www.roundup-tracker.org/dev_docs/

highlights fixes/features:

  issue2551413 - Broken MultiLink columns in CSV export. CSV export of
  a multilink to a class that does not have a ‘name’ property causes a
  crash.

  the classic tracker has basic responsive layout. There is more work
  to do, but even this basic page.html change makes things better.
 
  add support for authorized changes. User can be prompted to enter
  their password to authorize a change. If the user’s password is
  properly entered, the change is committed.

  the default log template includes an identifier unique for a
  request. This identifier (trace_id) can be use to identify all logs
  for a specific transaction. Also add support for dictConfig style
  logging configuration.

  add support for tokenless/nonceless CSRF prevention following
  https://words.filippo.io/csrf/. This will become the default in the
  future.

  add readline command to roundup-admin to list history, control input
  mode etc. Also support bang (!) commands to rerun commands in
  history or put them in the input buffer for editing.

Use the user's mailing list or open issues for any problems.

Thanks for testing.
--

John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.

Re: [Roundup-users] Looking for a howto on encrypting email inbound to Roundup

[John R. <ro...@ie...>]

Hi Ralf (and others) :

I just committed some verbage on PGP/GPG setup. Can you look at:

https://github.com/roundup-tracker/roundup/commit/5c79282f52b53a9f7cf6e8bf4d1f8413befd3156

and see if anything looks wrong?

Thanks.

-- rouilj

On Mon, Nov 10, 2025 at 2:29 AM Ralf Schlatterbeck <rs...@ru...> wrote:
>
> On Sun, Nov 02, 2025 at 08:08:18PM -0500, John P. Rouillard via Roundup-users wrote:
> > Hi all:
> >
> > Does anybody have a howto on sending gpg/pgp encrypted email to an
> > Roundup instance?
>
> I had used this a *long* time ago but the details have vanished in the
> mists of time .-)
> The setup has a private PGP key for decrypting incoming PGP mails. And
> it is supposed to have a bunch of public keys to verify incoming mails.
> For this the 'homedir' in the [pgp] section is used, it has a public and
> a private keyring. It plays the same role as the ~/.pgp directory of a
> user. You can enforce incoming emails to be signed with the
> 'require_incoming = signed' setting. You can force outgoing mails to be
> encrypted and you can define roundup roles for which PGP is used.
> Incoming mails are always pgp-handled when it is turned on.
>
> That's as far as I ever used this... but as said it is a long time ago.
>
> > Frankly any docs on setting up Roundup for use with pgp/gpg would be
> > useful as this feature is kind of useless without proper docs.
>
> Yes I think so, too. These days pgp isn't used much...
> When writing docs it might make a lot of sense to also update the tests
> to really support what is written in the docs, last time I looked pgp
> test coverage was minimal.
>
> Kind regards
> Ralf
> --
> Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
> Open Source Consulting                  www:   www.runtux.com
> Reichergasse 131, A-3411 Weidling       email: of...@ru...

[Roundup-users] Fwd: rich text editor to allow for formatted input

[John R. <ro...@ie...>]

I sent this to Norbert without including the list apparently.

---------- Forwarded message ---------
From: John Rouillard <ro...@ie...>
Date: Tue, Nov 11, 2025 at 12:27 PM
Subject: Re: [Roundup-users] rich text editor to allow for formatted input


Norbert asked:

> I would like to replace the "Note" field with a rich text editor to allow for
> formatted input (Markdown or HTML).

The jinja template uses simplemde so you can look there for ideas.
See: https://issues.roundup-tracker.org/issue2550856

As far as adding that to the classic template, there are no plans for
that at this time.
One issue with markdown is that it is not standardized. So the same
markup can have different presentation in a client side editor or the
server side rendered note.
See: https://issues.roundup-tracker.org/issue2551105 for one example.

However using a text input box with a preview button powered by server
side rendering could be suitable. Se
https://issues.roundup-tracker.org/msg6814 which is part of
issue2550856.

https://issues.roundup-tracker.org/issue2551176 mentions markdown-it
and markdown-py use. which are related implementations of what one
hopes is a single markdown understanding. Something like:
https://markdown-it.github.io/ for editing might work.

-- rouilj

[Roundup-users] rich text editor to allow for formatted input

[SCHLEMMER N. <Nor...@pd...>]

Hello everyone,

Now that I have successfully upgraded to version 2.5.0, I would like to replace the "Note" field with a rich text editor to allow for formatted input (Markdown or HTML).
My question is: Are there already any considerations or plans to use TinyMCE, EasyMDE, or a similar editor for the Note field?

Thank you very much and best regards
Norbert

Re: [Roundup-users] Looking for a howto on encrypting email inbound to Roundup

[Ralf S. <rs...@ru...>]

On Sun, Nov 02, 2025 at 08:08:18PM -0500, John P. Rouillard via Roundup-users wrote:
> Hi all:
> 
> Does anybody have a howto on sending gpg/pgp encrypted email to an
> Roundup instance?

I had used this a *long* time ago but the details have vanished in the
mists of time .-)
The setup has a private PGP key for decrypting incoming PGP mails. And
it is supposed to have a bunch of public keys to verify incoming mails.
For this the 'homedir' in the [pgp] section is used, it has a public and
a private keyring. It plays the same role as the ~/.pgp directory of a
user. You can enforce incoming emails to be signed with the
'require_incoming = signed' setting. You can force outgoing mails to be
encrypted and you can define roundup roles for which PGP is used.
Incoming mails are always pgp-handled when it is turned on.

That's as far as I ever used this... but as said it is a long time ago.

> Frankly any docs on setting up Roundup for use with pgp/gpg would be
> useful as this feature is kind of useless without proper docs.

Yes I think so, too. These days pgp isn't used much...
When writing docs it might make a lot of sense to also update the tests
to really support what is written in the docs, last time I looked pgp
test coverage was minimal.

Kind regards
Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   www.runtux.com
Reichergasse 131, A-3411 Weidling       email: of...@ru...

Re: [Roundup-users] Docker Container 2.5.0 / UniqueViolation: duplicate key value violates unique constraint "_issue_pkey"

[Ralf S. <rs...@ru...>]

On Tue, Nov 04, 2025 at 08:56:50AM +0000, SCHLEMMER Norbert wrote:
> Hello
> 
> Well, I performed the following steps:
[...]

Apart from the additional import/export to PostgreSQL 17 this looks like
the process I also would use.


> I then compared the tracker directory with one from version 2.5.0 and
> noticed a few changes, apart from the message files, which I still
> want to look at in detail.

Hmm, there should be no changes in the db directory.

On Mon, Nov 03, 2025 at 09:31:04PM -0500, John Rouillard via Roundup-users wrote:

> Also one thing I thought of. If you are using the same tracker home,
> you can export just the database with no files using roundup-admin.
> Then import just the database data. That should speed up the process.
> My guess is the 6 hours load time was spent shuffling those 85000
> messages.

I don't think the messages would be the problem, In the past I noticed
that for large database tables our import code can take a long time...

Also glad it worked :-)

Kind regards
Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   www.runtux.com
Reichergasse 131, A-3411 Weidling       email: of...@ru...

Re: [Roundup-users] Docker Container 2.5.0 / UniqueViolation: duplicate key value violates unique constraint "_issue_pkey"

[SCHLEMMER N. <Nor...@pd...>]

Hello

Well, I performed the following steps:

.) On the source system running Debian 12, I performed a database export from PostgreSQL and compressed the file.
.) On the source system, the tracker directory was also zipped.
.) Both zip files and the docker-compose.yml file were copied to the destination system running Debian 13 / Trixie and unzipped there.
.) The Roundup image has now been updated to version 2.5.0.
.) A PostgreSQL 17 container was started, and the export file was imported. Subsequently, another export was created, which was then imported into a PostgreSQL 18 container.
.) The PostgreSQL 17 container has now been deleted, and the PostgreSQL 18 container is being used as a service in the compose file.
.) Both services in the Docker Compose file, the PostgreSQL and the Roundup issue tracker, are now running, all previous data is present and appears to be intact.

I then compared the tracker directory with one from version 2.5.0 and noticed a few changes, apart from the message files, which I still want to look at in detail.

Br
Norbert


-----Ursprüngliche Nachricht-----
Von: John Rouillard <ro...@ie...> 
Gesendet: Dienstag, 04. November 2025 03:31
An: SCHLEMMER Norbert <Nor...@pd...>
Cc: rou...@li...
Betreff: Re: [Roundup-users] Docker Container 2.5.0 / UniqueViolation: duplicate key value violates unique constraint "_issue_pkey"

*EXTERNAL source*


How did you do it? What procedure worked?

Also one thing I thought of. If you are using the same tracker home, you can export just the database with no files using roundup-admin. Then import just the database data. That should speed up the process. My guess is the 6 hours load time was spent shuffling those 85000 messages.

The export/import method is really meant for changing between back end databases (e.g. anydbm or sqlite to postgres) and the export format is not guaranteed to work between roundup versions. However I don't know of any breaking issues between 2.2.0 and 2.5.0 releases.

Glad to hear you have it working.

-- rouilj

On Mon, Nov 3, 2025 at 2:03 AM SCHLEMMER Norbert <Nor...@pd...> wrote:
>
> Hi John
>
> I successfully upgraded to PostgreSQL 18.
> We have approximately 12,000 issues with 85,000 messages.
>
> Br
> Norbert
>
> -----Ursprüngliche Nachricht-----
> Von: John Rouillard <ro...@ie...>
> Gesendet: Samstag, 01. November 2025 02:51
> An: SCHLEMMER Norbert <Nor...@pd...>
> Cc: rou...@li...
> Betreff: Re: [Roundup-users] Docker Container 2.5.0 / UniqueViolation: duplicate key value violates unique constraint "_issue_pkey"
>
> *EXTERNAL source*
>
>
> Hi Norbert:
>
> Sorry, I'm kind of tied up with other things.
>
> On Wed, Oct 29, 2025 at 5:00 AM SCHLEMMER Norbert <Nor...@pd...> wrote:
> > What is the recommended upgrade path from Docker "2.3.0 / PostgreSQL 17" to "2.5.0 / PostgreSQL 18"
> > and for migrating to a different host with Debian 13 / Trixie?
>
> I suggest:
>
>    dump/restore the database from postgresql 17 to 18 using pg_dump etc.
>
>    then copy over the tracker home directory and follow the steps in upgrading.txt
>    (https://www.roundup-tracker.org/docs/upgrading.html) from 2.3.0 to 2.4.0 and then 2.5.0.
>    The required steps need to be done. If you omit the rest, it should still allow Roundup to work, but there may be security or other issues.
>
> > Can the Docker image simply be changed from roundup:2.3.1a0 to roundup:2.5.0-1?
> > I did this and didn't find any problems during testing. Is this procedure permissible and recommended?
> > If so, I can then upgrade to PostgreSQL 18 in the next step using SQL dump/restore.
>
> That should work provided you do the changes in upgrading.txt.
>
> Ralf said on Mittwoch, 29. Oktober 2025 09:29
> > On Wed, Oct 29, 2025 at 07:31:32AM +0000, SCHLEMMER Norbert wrote:
> > > An export was created from the productive Roundup instance 2.3.0.
> > > After importing in version 2.5.0, new messages can be added to an 
> > > existing issue but creating a new issue result in this violation; 
> > > see logs attached (the import process takes approximately 6 hours...).
>
> How many issues do you have?
>
> > Note that using the roundup-export / roundup-import is not 
> > recommended for version upgrade, that should happen in-place. This might be the reason of the error-message you're seeing.
>
> > > UniqueViolation: duplicate key value violates unique constraint 
> > > "_issue_pkey" DETAIL: Key (id)=(3)
> >  >       already exists.    Python 3.13.5
> > > /usr/local/bin/python3.13
>
> > Hmm, this might be because a retired node (e.g. an issue) is first 
> > created and then retired, it could produce a duplicate primary key if a non-retired node *with the same key* already exists.
> > But under normal circumstances duplicate primary keys should not occur (even including retired nodes).
>
> This is happening post import, correct Norbert?
>
> We fixed an import issue with duplicate keys back in the 2.1.0 release. it was caused when a user was created with the name "A". Then it was retired. Later a new user with the name "A" was created. When the export/import was done if the retired entry was imported after the non-retired entry the name "A"
> which is a pkey conflicted.
>
> However for issues, the title is not a primary key so I am not sure how you would get this conflict.
>
> It almost looks like the sequence used to number (id) the issues isn't set properly.
> Can you connect to the database and run:
>
>   select * from _issue_ids;
>
> you should see something like:
>
>  last_value | log_cnt | is_called
> ------------+---------+-----------
>             1 |         0 |          f
>
> where last_value is one more than the largest id number in the _issues table.
> Something like `select max(id) from _issue;` might do the trick to find the current max id number.
>
> If the last_value is wrong, check the rest of the sequences (use \ds to list sequences and select like above to see the value).
>
> I haven't seen an issue like that in my (limited) postgres testing of import/export.
>
> -- rouilj

Re: [Roundup-users] Docker Container 2.5.0 / UniqueViolation: duplicate key value violates unique constraint "_issue_pkey"

[John R. <ro...@ie...>]

How did you do it? What procedure worked?

Also one thing I thought of. If you are using the same tracker home,
you can export just the database with no files
using roundup-admin. Then import just the database data. That should
speed up the process. My guess is the 6 hours
load time was spent shuffling those 85000 messages.

The export/import method is really meant for changing between back end
databases (e.g. anydbm or sqlite to postgres)
and the export format is not guaranteed to work between roundup
versions. However I don't know of any breaking
issues between 2.2.0 and 2.5.0 releases.

Glad to hear you have it working.

-- rouilj

On Mon, Nov 3, 2025 at 2:03 AM SCHLEMMER Norbert
<Nor...@pd...> wrote:
>
> Hi John
>
> I successfully upgraded to PostgreSQL 18.
> We have approximately 12,000 issues with 85,000 messages.
>
> Br
> Norbert
>
> -----Ursprüngliche Nachricht-----
> Von: John Rouillard <ro...@ie...>
> Gesendet: Samstag, 01. November 2025 02:51
> An: SCHLEMMER Norbert <Nor...@pd...>
> Cc: rou...@li...
> Betreff: Re: [Roundup-users] Docker Container 2.5.0 / UniqueViolation: duplicate key value violates unique constraint "_issue_pkey"
>
> *EXTERNAL source*
>
>
> Hi Norbert:
>
> Sorry, I'm kind of tied up with other things.
>
> On Wed, Oct 29, 2025 at 5:00 AM SCHLEMMER Norbert <Nor...@pd...> wrote:
> > What is the recommended upgrade path from Docker "2.3.0 / PostgreSQL 17" to "2.5.0 / PostgreSQL 18"
> > and for migrating to a different host with Debian 13 / Trixie?
>
> I suggest:
>
>    dump/restore the database from postgresql 17 to 18 using pg_dump etc.
>
>    then copy over the tracker home directory and follow the steps in upgrading.txt
>    (https://www.roundup-tracker.org/docs/upgrading.html) from 2.3.0 to 2.4.0 and then 2.5.0.
>    The required steps need to be done. If you omit the rest, it should still allow Roundup to work, but there may be security or other issues.
>
> > Can the Docker image simply be changed from roundup:2.3.1a0 to roundup:2.5.0-1?
> > I did this and didn't find any problems during testing. Is this procedure permissible and recommended?
> > If so, I can then upgrade to PostgreSQL 18 in the next step using SQL dump/restore.
>
> That should work provided you do the changes in upgrading.txt.
>
> Ralf said on Mittwoch, 29. Oktober 2025 09:29
> > On Wed, Oct 29, 2025 at 07:31:32AM +0000, SCHLEMMER Norbert wrote:
> > > An export was created from the productive Roundup instance 2.3.0.
> > > After importing in version 2.5.0, new messages can be added to an
> > > existing issue but creating a new issue result in this violation;
> > > see logs attached (the import process takes approximately 6 hours...).
>
> How many issues do you have?
>
> > Note that using the roundup-export / roundup-import is not recommended
> > for version upgrade, that should happen in-place. This might be the reason of the error-message you're seeing.
>
> > > UniqueViolation: duplicate key value violates unique constraint
> > > "_issue_pkey" DETAIL: Key (id)=(3)
> >  >       already exists.    Python 3.13.5
> > > /usr/local/bin/python3.13
>
> > Hmm, this might be because a retired node (e.g. an issue) is first
> > created and then retired, it could produce a duplicate primary key if a non-retired node *with the same key* already exists.
> > But under normal circumstances duplicate primary keys should not occur (even including retired nodes).
>
> This is happening post import, correct Norbert?
>
> We fixed an import issue with duplicate keys back in the 2.1.0 release. it was caused when a user was created with the name "A". Then it was retired. Later a new user with the name "A" was created. When the export/import was done if the retired entry was imported after the non-retired entry the name "A"
> which is a pkey conflicted.
>
> However for issues, the title is not a primary key so I am not sure how you would get this conflict.
>
> It almost looks like the sequence used to number (id) the issues isn't set properly.
> Can you connect to the database and run:
>
>   select * from _issue_ids;
>
> you should see something like:
>
>  last_value | log_cnt | is_called
> ------------+---------+-----------
>             1 |         0 |          f
>
> where last_value is one more than the largest id number in the _issues table.
> Something like `select max(id) from _issue;` might do the trick to find the current max id number.
>
> If the last_value is wrong, check the rest of the sequences (use \ds to list sequences and select like above to see the value).
>
> I haven't seen an issue like that in my (limited) postgres testing of import/export.
>
> -- rouilj

Re: [Roundup-users] Docker Container 2.5.0 / UniqueViolation: duplicate key value violates unique constraint "_issue_pkey"

[SCHLEMMER N. <Nor...@pd...>]

Hi John

I successfully upgraded to PostgreSQL 18.
We have approximately 12,000 issues with 85,000 messages.

Br
Norbert

-----Ursprüngliche Nachricht-----
Von: John Rouillard <ro...@ie...> 
Gesendet: Samstag, 01. November 2025 02:51
An: SCHLEMMER Norbert <Nor...@pd...>
Cc: rou...@li...
Betreff: Re: [Roundup-users] Docker Container 2.5.0 / UniqueViolation: duplicate key value violates unique constraint "_issue_pkey"

*EXTERNAL source*


Hi Norbert:

Sorry, I'm kind of tied up with other things.

On Wed, Oct 29, 2025 at 5:00 AM SCHLEMMER Norbert <Nor...@pd...> wrote:
> What is the recommended upgrade path from Docker "2.3.0 / PostgreSQL 17" to "2.5.0 / PostgreSQL 18"
> and for migrating to a different host with Debian 13 / Trixie?

I suggest:

   dump/restore the database from postgresql 17 to 18 using pg_dump etc.

   then copy over the tracker home directory and follow the steps in upgrading.txt
   (https://www.roundup-tracker.org/docs/upgrading.html) from 2.3.0 to 2.4.0 and then 2.5.0.
   The required steps need to be done. If you omit the rest, it should still allow Roundup to work, but there may be security or other issues.

> Can the Docker image simply be changed from roundup:2.3.1a0 to roundup:2.5.0-1?
> I did this and didn't find any problems during testing. Is this procedure permissible and recommended?
> If so, I can then upgrade to PostgreSQL 18 in the next step using SQL dump/restore.

That should work provided you do the changes in upgrading.txt.

Ralf said on Mittwoch, 29. Oktober 2025 09:29
> On Wed, Oct 29, 2025 at 07:31:32AM +0000, SCHLEMMER Norbert wrote:
> > An export was created from the productive Roundup instance 2.3.0.
> > After importing in version 2.5.0, new messages can be added to an 
> > existing issue but creating a new issue result in this violation; 
> > see logs attached (the import process takes approximately 6 hours...).

How many issues do you have?

> Note that using the roundup-export / roundup-import is not recommended 
> for version upgrade, that should happen in-place. This might be the reason of the error-message you're seeing.

> > UniqueViolation: duplicate key value violates unique constraint 
> > "_issue_pkey" DETAIL: Key (id)=(3)
>  >       already exists.    Python 3.13.5
> > /usr/local/bin/python3.13

> Hmm, this might be because a retired node (e.g. an issue) is first 
> created and then retired, it could produce a duplicate primary key if a non-retired node *with the same key* already exists.
> But under normal circumstances duplicate primary keys should not occur (even including retired nodes).

This is happening post import, correct Norbert?

We fixed an import issue with duplicate keys back in the 2.1.0 release. it was caused when a user was created with the name "A". Then it was retired. Later a new user with the name "A" was created. When the export/import was done if the retired entry was imported after the non-retired entry the name "A"
which is a pkey conflicted.

However for issues, the title is not a primary key so I am not sure how you would get this conflict.

It almost looks like the sequence used to number (id) the issues isn't set properly.
Can you connect to the database and run:

  select * from _issue_ids;

you should see something like:

 last_value | log_cnt | is_called
------------+---------+-----------
            1 |         0 |          f

where last_value is one more than the largest id number in the _issues table.
Something like `select max(id) from _issue;` might do the trick to find the current max id number.

If the last_value is wrong, check the rest of the sequences (use \ds to list sequences and select like above to see the value).

I haven't seen an issue like that in my (limited) postgres testing of import/export.

-- rouilj

[Roundup-users] Looking for a howto on encrypting email inbound to Roundup

[John P. R. <ro...@cs...>]

Hi all:

Does anybody have a howto on sending gpg/pgp encrypted email to an
Roundup instance?

I have a couple of use cases where that would be useful/required along
with an encrypted database/filesystem.

It looks like the method decrypt is meant for this in mailgw.py but I
don't see any docs anywhere on how to set up/maintain/use pgp/gpg with
the gateway.

Frankly any docs on setting up Roundup for use with pgp/gpg would be
useful as this feature is kind of useless without proper docs.

Thanks.

--
				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.

Re: [Roundup-users] Docker Container 2.5.0 / UniqueViolation: duplicate key value violates unique constraint "_issue_pkey"

[John R. <ro...@ie...>]

Hi Norbert:

Sorry, I'm kind of tied up with other things.

On Wed, Oct 29, 2025 at 5:00 AM SCHLEMMER Norbert
<Nor...@pd...> wrote:
> What is the recommended upgrade path from Docker "2.3.0 / PostgreSQL 17" to "2.5.0 / PostgreSQL 18"
> and for migrating to a different host with Debian 13 / Trixie?

I suggest:

   dump/restore the database from postgresql 17 to 18 using pg_dump etc.

   then copy over the tracker home directory and follow the steps in
upgrading.txt
   (https://www.roundup-tracker.org/docs/upgrading.html) from 2.3.0 to
2.4.0 and then 2.5.0.
   The required steps need to be done. If you omit the rest, it should
still allow Roundup to
   work, but there may be security or other issues.

> Can the Docker image simply be changed from roundup:2.3.1a0 to roundup:2.5.0-1?
> I did this and didn't find any problems during testing. Is this procedure permissible and recommended?
> If so, I can then upgrade to PostgreSQL 18 in the next step using SQL dump/restore.

That should work provided you do the changes in upgrading.txt.

Ralf said on Mittwoch, 29. Oktober 2025 09:29
> On Wed, Oct 29, 2025 at 07:31:32AM +0000, SCHLEMMER Norbert wrote:
> > An export was created from the productive Roundup instance 2.3.0.
> > After importing in version 2.5.0, new messages can be added to an
> > existing issue but creating a new issue result in this violation; see
> > logs attached (the import process takes approximately 6 hours...).

How many issues do you have?

> Note that using the roundup-export / roundup-import is not recommended for version upgrade, that
> should happen in-place. This might be the reason of the error-message you're seeing.

> > UniqueViolation: duplicate key value violates unique constraint "_issue_pkey" DETAIL: Key (id)=(3)
>  >       already exists.    Python 3.13.5
> > /usr/local/bin/python3.13

> Hmm, this might be because a retired node (e.g. an issue) is first created and then retired, it could
> produce a duplicate primary key if a non-retired node *with the same key* already exists.
> But under normal circumstances duplicate primary keys should not occur (even including retired nodes).

This is happening post import, correct Norbert?

We fixed an import issue with duplicate keys back in the 2.1.0
release. it was caused when a user was
created with the name "A". Then it was retired. Later a new user with
the name "A" was created. When
the export/import was done if the retired entry was imported after the
non-retired entry the name "A"
which is a pkey conflicted.

However for issues, the title is not a primary key so I am not sure
how you would get this conflict.

It almost looks like the sequence used to number (id) the issues isn't
set properly.
Can you connect to the database and run:

  select * from _issue_ids;

you should see something like:

 last_value | log_cnt | is_called
------------+---------+-----------
            1 |         0 |          f

where last_value is one more than the largest id number in the _issues table.
Something like `select max(id) from _issue;` might do the trick to
find the current max id number.

If the last_value is wrong, check the rest of the sequences (use \ds
to list sequences and select like above
to see the value).

I haven't seen an issue like that in my (limited) postgres testing of
import/export.

-- rouilj

Re: [Roundup-users] Docker Container 2.5.0 / UniqueViolation: duplicate key value violates unique constraint "_issue_pkey"

[Ralf S. <rs...@ru...>]

On Wed, Oct 29, 2025 at 08:59:46AM +0000, SCHLEMMER Norbert wrote:
> Hi Ralf
> 
> What is the recommended upgrade path from Docker "2.3.0 / PostgreSQL 17" to "2.5.0 / PostgreSQL 18" and for migrating to a different host with Debian 13 / Trixie?
> 
> Can the Docker image simply be changed from roundup:2.3.1a0 to roundup:2.5.0-1?
> I did this and didn't find any problems during testing. Is this
> procedure permissible and recommended?

Yes, this should work. Note that the postgres version is of minor
concern.

> If so, I can then upgrade to PostgreSQL 18 in the next step using SQL
> dump/restore.

Yes, if you're installing postgres on the same machine postgres comes
with a pg_upgradecluster command that should be even faster than
dump/restore (and it is much easier if you have several databases), but
it needs both postgres versions to be installed at the same time (then
next you would pg_dropcluster the old cluster after having verified that
everything is in the new cluster and then you can uninstall the old
postgres version).

Thanks + kind regards
Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   www.runtux.com
Reichergasse 131, A-3411 Weidling       email: of...@ru...

Re: [Roundup-users] Docker Container 2.5.0 / UniqueViolation: duplicate key value violates unique constraint "_issue_pkey"

[SCHLEMMER N. <Nor...@pd...>]

Hi Ralf

What is the recommended upgrade path from Docker "2.3.0 / PostgreSQL 17" to "2.5.0 / PostgreSQL 18" and for migrating to a different host with Debian 13 / Trixie?

Can the Docker image simply be changed from roundup:2.3.1a0 to roundup:2.5.0-1?
I did this and didn't find any problems during testing. Is this procedure permissible and recommended?
If so, I can then upgrade to PostgreSQL 18 in the next step using SQL dump/restore.

Thanks
Norbert


-----Ursprüngliche Nachricht-----
Von: Ralf Schlatterbeck <rs...@ru...> 
Gesendet: Mittwoch, 29. Oktober 2025 09:29
An: rou...@li...
Betreff: Re: [Roundup-users] Docker Container 2.5.0 / UniqueViolation: duplicate key value violates unique constraint "_issue_pkey"

*EXTERNAL source*


On Wed, Oct 29, 2025 at 07:31:32AM +0000, SCHLEMMER Norbert wrote:
> Hello All
>
> Running the Roundup Docker container 2.5.0-1 with PostgreSQL 18 and 
> Debian 13 / Trixie as host
>
> An export was created from the productive Roundup instance 2.3.0.
> After importing in version 2.5.0, new messages can be added to an 
> existing issue but creating a new issue result in this violation; see 
> logs attached (the import process takes approximately 6 hours...).

Umm, how much data do you have in that database?
If you're migrating between the same version of roundup *and* the same database, an SQL dump/restore should be *much* faster.

Note that using the roundup-export / roundup-import is not recommended for version upgrade, that should happen in-place. This might be the reason of the error-message you're seeing.

> UniqueViolation: duplicate key value violates unique constraint "_issue_pkey" DETAIL: Key (id)=(3) already exists.    Python 3.13.5
> /usr/local/bin/python3.13

Hmm, this might be because a retired node (e.g. an issue) is first created and then retired, it could produce a duplicate primary key if a non-retired node *with the same key* already exists.

But under normal circumstances duplicate primary keys should not occur (even including retired nodes).

Kind regards
Ralf
--
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   www.runtux.com
Reichergasse 131, A-3411 Weidling       email: of...@ru...


_______________________________________________
Roundup-users mailing list
Rou...@li...
https://lists.sourceforge.net/lists/listinfo/roundup-users

Re: [Roundup-users] Docker Container 2.5.0 / UniqueViolation: duplicate key value violates unique constraint "_issue_pkey"

[Ralf S. <rs...@ru...>]

On Wed, Oct 29, 2025 at 07:31:32AM +0000, SCHLEMMER Norbert wrote:
> Hello All
> 
> Running the Roundup Docker container 2.5.0-1 with PostgreSQL 18 and Debian 13 / Trixie as host
> 
> An export was created from the productive Roundup instance 2.3.0.
> After importing in version 2.5.0, new messages can be added to an
> existing issue but creating a new issue result in this violation; see
> logs attached (the import process takes approximately 6 hours...).

Umm, how much data do you have in that database?
If you're migrating between the same version of roundup *and* the same
database, an SQL dump/restore should be *much* faster.

Note that using the roundup-export / roundup-import is not recommended for
version upgrade, that should happen in-place. This might be the reason
of the error-message you're seeing.

> UniqueViolation: duplicate key value violates unique constraint "_issue_pkey" DETAIL: Key (id)=(3) already exists. 	Python 3.13.5
> /usr/local/bin/python3.13

Hmm, this might be because a retired node (e.g. an issue) is first
created and then retired, it could produce a duplicate primary key if a
non-retired node *with the same key* already exists.

But under normal circumstances duplicate primary keys should not occur
(even including retired nodes).

Kind regards
Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   www.runtux.com
Reichergasse 131, A-3411 Weidling       email: of...@ru...

[Roundup-users] Docker Container 2.5.0 / UniqueViolation: duplicate key value violates unique constraint "_issue_pkey"

[SCHLEMMER N. <Nor...@pd...>]

Hello All

Running the Roundup Docker container 2.5.0-1 with PostgreSQL 18 and Debian 13 / Trixie as host

An export was created from the productive Roundup instance 2.3.0.
After importing in version 2.5.0, new messages can be added to an existing issue but creating a new issue result in this violation; see logs attached (the import process takes approximately 6 hours...).
It makes no difference whether PostgreSQL 17 or 18 is used.

I will test the import with version 2.3.0 later today.

Thank you in advance for your support.
Br
Norbert



UniqueViolation: duplicate key value violates unique constraint "_issue_pkey" DETAIL: Key (id)=(3) already exists. 	Python 3.13.5
/usr/local/bin/python3.13

A problem occurred while running a Python script. Here is the sequence of function calls leading up to the error, with the most recent (innermost) call first. The exception attributes are:
      __cause__ = None
      __class__ = <class 'psycopg2.errors.UniqueViolation'>
      __context__ = None
      __delattr__ = <method-wrapper '__delattr__' of UniqueViolation object>
      __dict__ = {}
      __dir__ = <built-in method __dir__ of UniqueViolation object>
      __doc__ = None
      __eq__ = <method-wrapper '__eq__' of UniqueViolation object>
      __format__ = <built-in method __format__ of UniqueViolation object>
      __ge__ = <method-wrapper '__ge__' of UniqueViolation object>
      __getattribute__ = <method-wrapper '__getattribute__' of UniqueViolation object>
      __getstate__ = <built-in method __getstate__ of UniqueViolation object>
      __gt__ = <method-wrapper '__gt__' of UniqueViolation object>
      __hash__ = <method-wrapper '__hash__' of UniqueViolation object>
      __init__ = <method-wrapper '__init__' of UniqueViolation object>
      __init_subclass__ = <built-in method __init_subclass__ of type object>
      __le__ = <method-wrapper '__le__' of UniqueViolation object>
      __lt__ = <method-wrapper '__lt__' of UniqueViolation object>
      __module__ = 'psycopg2.errors'
      __ne__ = <method-wrapper '__ne__' of UniqueViolation object>
      __new__ = <built-in method __new__ of type object>
      __reduce__ = <built-in method __reduce__ of UniqueViolation object>
      __reduce_ex__ = <built-in method __reduce_ex__ of UniqueViolation object>
      __repr__ = <method-wrapper '__repr__' of UniqueViolation object>
      __setattr__ = <method-wrapper '__setattr__' of UniqueViolation object>
      __setstate__ = <built-in method __setstate__ of UniqueViolation object>
      __sizeof__ = <built-in method __sizeof__ of UniqueViolation object>
      __str__ = <method-wrapper '__str__' of UniqueViolation object>
      __subclasshook__ = <built-in method __subclasshook__ of type object>
      __suppress_context__ = False
      __traceback__ = <traceback object>
      __weakref__ = None
      add_note = <built-in method add_note of UniqueViolation object>
      args = ('duplicate key value violates unique constraint "_issue_pkey"\nDETAIL: Key (id)=(3) already exists.\n',)
      cursor = <cursor object at 0x7f32fc58ea70; closed: 0>
      diag = <psycopg2.extensions.Diagnostics object>
      pgcode = '23505'
      pgerror = 'ERROR: duplicate key value violates unique cons...ssue_pkey"\nDETAIL: Key (id)=(3) already exists.\n'
      with_traceback = <built-in method with_traceback of UniqueViolation object>

/usr/local/lib/python3.13/site-packages/roundup/backends/rdbms_common.py in sql(self=<roundpsycopgsql 0x7f32fc1f49e0>, sql='insert into _issue (_activity,_actor,_assignedto...us,_title,id) values (%s,%s,%s,%s,%s,%s,%s,%s,%s)', args=('2025-10-29 07:16:36.917', 4, 4, '2025-10-29 07:16:36.917', 4, 4, 8, 'Roundup 2.5.0 : Layout Modifications', '3'), cursor=<cursor object at 0x7f32fc58ea70; closed: 0>)
  260             cursor = self.cursor
  261         if args:
  262             cursor.execute(sql, args)
      cursor = <cursor object at 0x7f32fc58ea70; closed: 0>, global execute = undefined, sql = 'insert into _issue (_activity,_actor,_assignedto...us,_title,id) values (%s,%s,%s,%s,%s,%s,%s,%s,%s)', args = ('2025-10-29 07:16:36.917', 4, 4, '2025-10-29 07:16:36.917', 4, 4, 8, 'Roundup 2.5.0 : Layout Modifications', '3')
  263         else:
  264             cursor.execute(sql)

/usr/local/lib/python3.13/site-packages/roundup/backends/rdbms_common.py in addnode(self=<roundpsycopgsql 0x7f32fc1f49e0>, classname='issue', nodeid='3', node={'assignedto': '4', 'files': [], 'keyword': ['18'], 'messages': [], 'nosy': ['4'], 'priority': '4', 'status': '8', 'superseder': [], 'title': 'Roundup 2.5.0 : Layout Modifications'})
 1078         # perform the inserts
 1079         sql = 'insert into _%s (%s) values (%s)' % (classname, cols, s)
 1080         self.sql(sql, vals)
      self = <roundpsycopgsql 0x7f32fc1f49e0>, sql = 'insert into _issue (_activity,_actor,_assignedto...us,_title,id) values (%s,%s,%s,%s,%s,%s,%s,%s,%s)', vals = ('2025-10-29 07:16:36.917', 4, 4, '2025-10-29 07:16:36.917', 4, 4, 8, 'Roundup 2.5.0 : Layout Modifications', '3')
 1081 
 1082         # insert the multilink rows

/usr/local/lib/python3.13/site-packages/roundup/backends/rdbms_common.py in create_inner(self=<hyperdb.Class "issue">, **propvalues={'assignedto': '4', 'files': [], 'keyword': ['18'], 'messages': [], 'nosy': ['4'], 'priority': '4', 'status': '8', 'superseder': [], 'title': 'Roundup 2.5.0 : Layout Modifications'})
 1860 
 1861         # done
 1862         self.db.addnode(self.classname, newid, propvalues)
      self = <hyperdb.Class "issue">, global db = undefined, global addnode = undefined, global classname = undefined, newid = '3', propvalues = {'assignedto': '4', 'files': [], 'keyword': ['18'], 'messages': [], 'nosy': ['4'], 'priority': '4', 'status': '8', 'superseder': [], 'title': 'Roundup 2.5.0 : Layout Modifications'}
 1863         if self.do_journal:
 1864             self.db.addjournal(self.classname, newid, ''"create", {})

/usr/local/lib/python3.13/site-packages/roundup/backends/rdbms_common.py in create(self=<hyperdb.Class "issue">, **propvalues={'assignedto': '4', 'keyword': ['18'], 'nosy': ['4'], 'priority': '4', 'status': '8', 'title': 'Roundup 2.5.0 : Layout Modifications'})
 1708         """
 1709         self.fireAuditors('create', None, propvalues)
 1710         newid = self.create_inner(**propvalues)
      newid = undefined, self = <hyperdb.Class "issue">, global create_inner = undefined, propvalues = {'assignedto': '4', 'keyword': ['18'], 'nosy': ['4'], 'priority': '4', 'status': '8', 'title': 'Roundup 2.5.0 : Layout Modifications'}
 1711         self.fireReactors('create', newid, None)
 1712         return newid

/usr/local/lib/python3.13/site-packages/roundup/cgi/actions.py in _createnode(self=<roundup.cgi.actions.NewItemAction object>, cn='issue', props={'assignedto': '4', 'keyword': ['18'], 'nosy': ['4'], 'priority': '4', 'status': '8', 'title': 'Roundup 2.5.0 : Layout Modifications'})
  743         # create the node and return its id
  744         cl = self.db.classes[cn]
  745         return cl.create(**props)
      cl = <hyperdb.Class "issue">, global create = undefined, props = {'assignedto': '4', 'keyword': ['18'], 'nosy': ['4'], 'priority': '4', 'status': '8', 'title': 'Roundup 2.5.0 : Layout Modifications'}
  746 
  747     def isEditingSelf(self):

/usr/local/lib/python3.13/site-packages/roundup/cgi/actions.py in _editnodes(self=<roundup.cgi.actions.NewItemAction object>, all_props={('issue', None): {'assignedto': '4', 'keyword': ['18'], 'nosy': ['4'], 'priority': '4', 'status': '8', 'title': 'Roundup 2.5.0 : Layout Modifications'}}, all_links=[('issue', None, 'messages', [('msg', '-1')])])
  686                 else:
  687                     # make a new node
  688                     newid = self._createnode(cn, props)
      newid = undefined, self = <roundup.cgi.actions.NewItemAction object>, global _createnode = undefined, cn = 'issue', props = {'assignedto': '4', 'keyword': ['18'], 'nosy': ['4'], 'priority': '4', 'status': '8', 'title': 'Roundup 2.5.0 : Layout Modifications'}
  689                     if nodeid is None:
  690                         self.nodeid = newid

/usr/local/lib/python3.13/site-packages/roundup/cgi/actions.py in handle(self=<roundup.cgi.actions.NewItemAction object>)
  896         try:
  897             # when it hits the None element, it'll set self.nodeid
  898             messages = self._editnodes(props, links)
      messages = undefined, self = <roundup.cgi.actions.NewItemAction object>, global _editnodes = undefined, props = {('issue', None): {'assignedto': '4', 'keyword': ['18'], 'nosy': ['4'], 'priority': '4', 'status': '8', 'title': 'Roundup 2.5.0 : Layout Modifications'}}, links = [('issue', None, 'messages', [('msg', '-1')])]
  899         except (ValueError, KeyError, IndexError, Reject) as message:
  900             escape = not isinstance(message, RejectRaw)

/usr/local/lib/python3.13/site-packages/roundup/cgi/actions.py in execute(self=<roundup.cgi.actions.NewItemAction object>)
   48         """Execute the action specified by this object."""
   49         self.permission()
   50         return self.handle()
      self = <roundup.cgi.actions.NewItemAction object>, global handle = undefined
   51 
   52     def examine_url(self, url):

/usr/local/lib/python3.13/site-packages/roundup/cgi/client.py in handle_action(self=<roundup.cgi.client.Client object>)
 2406                 return getattr(self, action_klass)()
 2407 
 2408             return action_klass(self).execute()
      action_klass = <class 'roundup.cgi.actions.NewItemAction'>, self = <roundup.cgi.client.Client object>, global execute = undefined
 2409         except (ValueError, Reject) as err:
 2410             escape = not isinstance(err, RejectRaw)

/usr/local/lib/python3.13/site-packages/roundup/cgi/client.py in inner_main(self=<roundup.cgi.client.Client object>)
  907                 # It can change self.classname and self.template,
  908                 # and may also append error/ok_messages.
  909                 html = self.handle_action() if csrf_ok else None
      html = undefined, self = <roundup.cgi.client.Client object>, global handle_action = undefined, csrf_ok = True
  910 
  911                 if html:

 
Environment Variables
CONTENT_LENGTH	'1792'
CONTENT_TYPE	'multipart/form-data; boundary=----geckoformboundary22d88e55123b32825148a07d5667ae74'
HTTP_ACCEPT_LANGUAGE	'de,en-US;q=0.7,en;q=0.3'
HTTP_AUTHORIZATION	None
HTTP_COOKIE	'roundup_session_Roundupissuetracker=yTP8g7rLjQp0JIPplS/xCUslpb2PeMkU3wB/Nx5lABY; _pk_id.1.28af=d4ef3913f72d42f0.1759845249.'

Re: [Roundup-users] Docker Container 2.5.0 / roundup_healthcheck

[SCHLEMMER N. <Nor...@pd...>]

As workaround I use the healthcheck defined by the compose file

    healthcheck:
      test: ["CMD", "wget", "-q", "-O", "/dev/null", "http://127.0.0.1:8080/${tracker:-issues}/"]
      interval: 30s
      timeout: 5s
      retries: 3
      start_period: 1m

now the container is "healthy"

Re: [Roundup-users] Docker Container 2.5.0 / roundup_healthcheck

[SCHLEMMER N. <Nor...@pd...>]

If GNU wget is used instead of BusyBox, wget can be restricted to IP v4.
wget -4 -q -O /dev/null http://localhost:8080/

Or simply use 127.0.0.1 for health checks in the container

Br
Norbert


-----Ursprüngliche Nachricht-----
Von: Ralf Schlatterbeck <rs...@ru...> 
Gesendet: Montag, 27. Oktober 2025 16:25
An: rou...@li...
Betreff: Re: [Roundup-users] Docker Container 2.5.0 / roundup_healthcheck

*EXTERNAL source*


On Mon, Oct 27, 2025 at 02:49:55PM +0000, SCHLEMMER Norbert wrote:
> Hello All
>
> Running the Rundup Docker container 2.5.0-1 with Debian 13 / Trixie as 
> host
>
> There seems to be a problem with the roundup_healthcheck script using 
> localhost

This looks like localhost on your machine maps to both, 127.0.0.1 and
::1 (IPv4 and IPv6). But it seems the roundup-server is listening only on the IPv4 address.

Maybe you can fix it by making localhost only an ipv4 address and have a separate name for ipv6 localhost.

e.g. in /etc/hosts:

127.0.0.1  localhost
::1        ip6-localhost ip6-loopback

I'm not familiar with the container setup...

Kind regards
Ralf
--
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   www.runtux.com
Reichergasse 131, A-3411 Weidling       email: of...@ru...


_______________________________________________
Roundup-users mailing list
Rou...@li...
https://lists.sourceforge.net/lists/listinfo/roundup-users

Re: [Roundup-users] Docker Container 2.5.0 / roundup_healthcheck

[SCHLEMMER N. <Nor...@pd...>]

The Docker host has IP v6 disabled, but the container V 2.5.0 has enabled IP v6

noschvie@tvmtdevroundup:~/Roundup$ cat /proc/sys/net/ipv6/conf/all/disable_ipv6
1 

noschvie@tvmtdevroundup:~/Roundup$ docker exec -it roundup /bin/sh
~ $ ping localhost
PING localhost (::1): 56 data bytes
64 bytes from ::1: seq=0 ttl=64 time=0.166 ms
64 bytes from ::1: seq=1 ttl=64 time=0.060 ms
^C
--- localhost ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.060/0.113/0.166 ms

~ $ sysctl net.ipv6.conf.all.disable_ipv6
net.ipv6.conf.all.disable_ipv6 = 0


But the container image 2.3.0 has IP v6 disabled

noschvie@tvmtmcsdebian12dev:~$ docker exec -it roundup /bin/sh
~ $ ping localhost
PING localhost (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: seq=0 ttl=42 time=0.048 ms
64 bytes from 127.0.0.1: seq=1 ttl=42 time=0.070 ms
64 bytes from 127.0.0.1: seq=2 ttl=42 time=0.103 ms

Br
Norbert 

Re: [Roundup-users] Docker Container 2.5.0 / roundup_healthcheck

[Ralf S. <rs...@ru...>]

On Mon, Oct 27, 2025 at 02:49:55PM +0000, SCHLEMMER Norbert wrote:
> Hello All
> 
> Running the Rundup Docker container 2.5.0-1 with Debian 13 / Trixie as host
> 
> There seems to be a problem with the roundup_healthcheck script using
> localhost

This looks like localhost on your machine maps to both, 127.0.0.1 and
::1 (IPv4 and IPv6). But it seems the roundup-server is listening only
on the IPv4 address.

Maybe you can fix it by making localhost only an ipv4 address and have a
separate name for ipv6 localhost.

e.g. in /etc/hosts:

127.0.0.1  localhost
::1        ip6-localhost ip6-loopback

I'm not familiar with the container setup...

Kind regards
Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   www.runtux.com
Reichergasse 131, A-3411 Weidling       email: of...@ru...

[Roundup-users] Docker Container 2.5.0 / roundup_healthcheck

[SCHLEMMER N. <Nor...@pd...>]

Hello All

Running the Rundup Docker container 2.5.0-1 with Debian 13 / Trixie as host

There seems to be a problem with the roundup_healthcheck script using localhost


~ $ wget  -O /dev/null --proxy off --no-verbose http://localhost:8080/"${tracker:-issues}"/
Connecting to localhost:8080 ([::1]:8080)
wget: can't connect to remote host: Connection refused

~ $ wget  -O /dev/null --proxy off --no-verbose http://127.0.0.1:8080/"${tracker:-issues}"/
Connecting to 127.0.0.1:8080 (127.0.0.1:8080)
saving to '/dev/null'
null                 100% |*****************************************************************************************************************| 23949  0:00:00 ETA
'/dev/null' saved


Any idea?



Thanks

Norbert

Re: [Roundup-users] Reauthorization for changes

[John R. <ro...@ie...>]

Hi all:

The Reauth code has been pushed to the mercurial sourceforge repo on the
reauth-confirm_id branch.  I am keeping the Reauth naming scheme since
that's closer to how OWASP refers to it.

Please take a look at the docs. I have updated the upgrade documents,
the customization document and the reference document along with adding
the appropriate modules/classes to the pydoc generated from docstrings.
Also check out the code and test for the workflow. The test code could use
some refactoring.

The last question I have is should I add the reauth workflow when changing a
user's password or address to the packaged templates?

I'm planning on merging it this weekend.

Thoughts, comments?

Thanks.

-- rouilj

Re: [Roundup-users] Reauthorization for changes

[John R. <ro...@ie...>]

Hi Ralf:

Thanks for replying. Notes inline.

On Mon, Aug 11, 2025 at 4:39 AM Ralf Schlatterbeck <rs...@ru...> wrote:
> On Sat, Aug 09, 2025 at 01:02:25AM -0400, John Rouillard via Roundup-users wrote:
> > Consider a user changing a password. You as the admin want to make sure
> > that the user is actually present and that the request isn't being made on
> > an unlocked computer by some random person.
> >
> > One way to add an extra layer of protection on sensitive changes is
> > to require the user to authorize the change by typing their password.
> [...]
> > Has anybody done something like this already?
> No.
> > Does this seem useful?
> Yes, definitely. Although most of my trackers run authentication against
> a Kerberos instance (usually active directory)

With the current POC, you can replace
roundup.cgi.actions::ReauthAction::verifyPassword
(may need to change name) with a method to validate a password (or
other token) using
interfaces.py. So it could be used to verify against kerberos.

> > Are there other sequences other than reauth that I should consider adding
> > and maybe build this into a better framework to allow other use cases?
> > (YAGNI would seem to say no but....).
> Hmm, I would leave it at that for now, better to refactor later when the
> need arises...

Fair enough.Sadly adding functionality like this can't be done from a tracker.
It requires changes to core code. The question is will we remember we need
to refactor this the second or third time this code has to change 8-)?

For future refactoring. My thought was to leave a hook in the final
exception handler in
Client::inner_main() (parallel to where RateLimitExceded is handled).
The hook calls a
"handle_exception(exception)" method. In interfaces.py, the admin could create a
NewException and (re)define handle_exception to process it.. Then NewException
can be raised in a detector/action/extension and it is handled handled by
handle_exception in inner_main.

> Thanks for looking into this!

Sure, it was a thought from a company I put Roundup at in 2020. They
are upgrading to
2.5.0 in the next month or so.

The big trick was making sure that all the data from the original
form, including files, survives
the reauthorization page and is faithfully submitted to the original
endpoint. Getting the javascript
written to preserve files was both icky and tricky.

So far I have 14 hours in, but it looks pretty good.

One issue I do have is naming things. I currently use the following scheme:

  exception: Reauth
  exception handler: Client::reauth()
  action class: ReauthAction
  action name: reauth (used in web @action=reauth)
  template: _generic.reauth.html

I have mixed feelings about the name. I have also considered:

    AuthNeeded, Client::auth_change, AuthAction, auth, _generic_auth.html
    ValidateNeeded, client:validate_change, ValidateAction, validate,
_generic.validate.html
    ApprovalNeeded, Client::approve_change, ApproveAction, approve,
_generic.approve.html
    ConfirmId, client::confirm_id, ConfirmIdAction, confirmid,
_generic.confirmid.html

along with VerifyId, ConfirmActor, ConfirmUser...

The user isn't really authorizing or validating the change. The user
gets a page with a password
field in a form. There is no info about what is changing and they have
no way to verify the
changes are correct/abort the change or approve of the change.
(Currently using the browser's
back button is the way to abort the reauth loop.)  So auth/reauth is
kind of the wrong model.

I think ConfirmId is the best of the lot but.... Thoughts?

-- rouilj

Re: [Roundup-users] Reauthorization for changes

[Ralf S. <rs...@ru...>]

On Sat, Aug 09, 2025 at 01:02:25AM -0400, John Rouillard via Roundup-users wrote:
> 
> Consider a user changing a password. You as the admin want to make sure
> that the user is actually present and that the request isn't being made on
> an unlocked computer by some random person.
> 
> One way to add an extra layer of protection on sensitive changes is
> to require the user to authorize the change by typing their password.
> 
> We see this with github and other places. My POC runs like this:
[...]

> So my questions:
> 
> Has anybody done something like this already?

No.

> Does this seem useful?

Yes, definitely. Although most of my trackers run authentication against
a Kerberos instance (usually active directory)

> Are there other sequences other than reauth that I should consider adding
> and maybe build this into a better framework to allow other use cases?
> (YAGNI would seem to say no but....).

Hmm, I would leave it at that for now, better to refactor later when the
need arises...

Thanks for looking into this!

Kind regards
Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   www.runtux.com
Reichergasse 131, A-3411 Weidling       email: of...@ru...