https://github.com/OWASP/ASVS/blob/master/4.0/en/0x11-V2-Authentication.md#v21-password-security-requirements requirements numbered 2.2.3 and 2.5.5

recommends that changes to email addresses or password credentials result in
notification to the user. They prefer a push system, but notification
to email address can work.

To implement, a reactor that monitors primary email or password change and emails
user at:

   old and new primary email address about email address changes
   current primary email address for password change

Some text similar to:

  Your <(email|password) has changed on the xyz tracker. If you authorized this
  change you do not need to do anything. If this change is unauthorized,
  please notify the admin at .....

should be sent.

A few additional notes on this since there is interest in it.

When you set up your tracker (in the demo directory usually) change the
tracker's config.ini
as below. In the [mail] section, set the following three settings:

  debug = tracker.mail

to put emails into the file tracker.mail in your tracker's home
directory. It also
prevents any attempt to deliver the email. You can read the file to view
the email
that would be sent.

Note that debug mode adds two additional fields to the stored email.
The FROM: and TO: fields should duplicate the From: and To: fields in
the email. The all
caps version records the values sent into the mailer interface, the
Mixed case version
are the headers that would be sent over the network (if debug mode was
turned off) to send
the email. It allows you to compare the values to make sure things work
as intended.

Also set:

  charset = ISO-8859-1

to prevent the body of the email (saved to tracker.email) from being
encoded using base64.
This means you can read the body of the email without using mutt or
other email reader.

The setting 

  domain = localhost

should also be set. IIRC it's set automatically.

To send email from a detector you can use:

   ## put this at the top of the file
   from roundup.mailer import Mailer


      ## then in the body of your reactor function use it like:
      # we have one or more changes to a notifiable property.
      mailer = Mailer(db.config)
      subject = 'User properties changed'
      message = """the suggested message to send to the user"""
      mailer.standard_message(addresses, subject, message)

where addresses is a list of addresses taken from the database and
oldvalues
for the user whose properties are being changed.

There is one additional issue with reactors. To see if a property has
changed, you need
to compare the property value in oldvalues and in the db. For example
with a reactor
function defined like:

  def notify_on_pw_or_email_change(db, cl, nodeid, oldvalues):

    user = db.user.getnode(db.getuid())

    changed_props = []

    if oldvalues['address'] != user['address']:
        changed_props.apppend('address')

    [... check other props like password, alternate_addresses ]

    if not changed_props: return

    [... do the notification thing ]

Having to compare that values of the properties to see what has changed
is less than ideal.
However this is the correct way to do it through version 2.6.0 of
Roundup.

=====

The below can be ignored for the purpose of this issue. It addresses the
need to 
compare values of interesting properties in the reactor rather than
checking to see 
if the properties we are interested in are "in" oldvalues. Currently:

   "interesting_prop" in oldvalues

is always true even if interesting_prop wasn't changed in this
transaction.

The spec (references.txt) for reactors says olddata (usually named
oldvalues in actual code) says: 

  For a ``set()`` operation, ``olddata`` contains the names and previous
  values of properties that were changed.

oldvalues has the previous value for *all* properties of the object, not
just
changed properties. This differs from an auditor where "'propname' in
newdata" is a
useful statement. I'll open a discussion on the dev list. If this is a
mistake
(it has been this way since version 0.5.0 AFAICT) I'll open a ticket to
fix it
in the core and reference it in this issue.

thanks for teeing this up with some specifics, I'm considering how to
not underthink nor overthink this, working on moderate to-do list
initially before work/iteration, thanks again.

Personally wrangled my dev machine sufficiently.
Personally found and edited dev file '/roundup/demo/config.ini'.
Personally next for me is sufficiently, in the context of roundup tracker 
software dev, learning about reactor and detector usage.

These are all not very useful so far in terms of producing a public bug fix, 
just navigating my own personal stuff so far.

So I guess after this here comment I'll take further personal comments 
offline and just wait until I have further publicly useful questions and 
additions before posting back here in the issue comments again. thanks.