Modify

Opened 8 years ago

Closed 8 years ago

Last modified 5 years ago

#13074 closed defect (wontfix)

Notifications sent to all users

Reported by: Ben Gamari Owned by: Ryan J Ollos
Priority: highest Component: AccountManagerPlugin
Severity: critical Keywords:
Cc: ben@… Trac Release: 1.2

Description

Recently GHC upgraded its Trac installation to Trac 1.2 and AccountManagerPlugin HEAD (r16056). This installation has smtp_always_cc = ghc-tickets@haskell.org set in the [notification] section of trac.ini. Since the upgrade password reset and email verification messages have been getting sent to ghc-tickets@haskell.org, in addition to the intended recipient.

A bit of debug output added to SingleUserNotification.get_smtp_address reveals that get_smtp_address is only called for the intended recipient, suggested that the ghc-tickets address is only added later in the notification pipeline.

Attachments (0)

Change History (16)

comment:1 Changed 8 years ago by Ben Gamari

Cc: ben@… added
Priority: highhighest

Bumping priority since this exposes user passwords to a public mailing list.

comment:2 Changed 8 years ago by Ben Gamari

Severity: normalcritical

comment:3 Changed 8 years ago by Ryan J Ollos

Please share your [account-manager] settings from trac.ini with any sensitive configuration info obfuscated.

Last edited 8 years ago by Ryan J Ollos (previous) (diff)

comment:4 Changed 8 years ago by Ben Gamari

Here it is,

[account-manager]
account_changes_notify_addresses =
authentication_url =
db_htdigest_realm =
db_htpasswd_hash_type = md5
force_change_passwd = false
force_passwd_change = enabled
hash_method = HtPasswdHashMethod
htdigest_file =
htdigest_realm =
htpasswd_file = /home/trac/ghc/trac.htpasswd
htpasswd_hash_type = md5
notify_actions =
password_format = htpasswd
password_store = SessionStore
persistent_sessions = enabled
refresh_passwd = disabled
register_check = BasicCheck,EmailCheck,BotTrapCheck,RegExpCheck,RegistrationFilterAdapter,UsernamePermCheck
reset_password = enabled
username_regexp = (?i)^[A-Z0-9.\-_]{3,}$
verify_email = enabled

comment:5 Changed 8 years ago by Ben Gamari

Has there been any motion on this, Ryan?

comment:6 Changed 8 years ago by Ryan J Ollos

I will take a look at it soon. PatchWelcome.

comment:7 Changed 8 years ago by Ryan J Ollos

Status: newaccepted

comment:8 Changed 8 years ago by Peter Suter

(Similar issue in the old NotifyEmail system: #8796.)

From: t:comment:8:ticket:5670:

  1. smtp_always_bcc and smtp_always_cc

Does always mean all emails or all ticket notification emails?

With NotifyEmail it meant all emails and plugins had no good way to opt-out.

In the new system AlwaysEmailSubscriber (since #11934) implements these and still forwards all emails. Plugins probably now have enough flexibility to deal with this. (e.g. higher priority subscriptions, disabled components, using distributors directly...)

Apparently #8796 did find a way to opt-out in the old NotifyEmail system.

Looks like AccountManagerPlugin currently relies on the deprecated NotifyEmail compatibility shims, where this workaround doesn't work. So this entire subsystem should be rewritten using the Trac 1.2 API. Then I guess a custom subscriber could provide a default subscription with priority 0 and adverb never for account notifications. (But AlwaysEmailSubscriber also has priority 0!) Or possibly the account notifications should be sent by calling directly e.g. NotificationSystem.distribute_event() instead of NotificationSystem.notify().

I would in any case recommend not using smtp_always_cc if you don't want all emails to be CC'd there.

Last edited 8 years ago by Peter Suter (previous) (diff)

comment:9 Changed 8 years ago by Ben Gamari

I would in any case recommend not using smtp_always_cc if you don't want all emails to be CC'd there.

Fair enough. We are using smtp_always_cc for our ghc-tickets mailing list, which receives all ticket traffic. While I wasn't around when this was configured, I suspect that the motivation for this was taken from the wiki:TracNotification page.

What is the recommended way to consolidate ticket traffic to a mailing list under Trac 1.2?

comment:11 Changed 8 years ago by Ryan J Ollos

Resolution: wontfix
Status: acceptedclosed

trac:#11871 will also add an AllTicketsSubscriber, so individual users can subscribe to all ticket changes. The difference in contrast to the recipe in comment:10, as far as I can tell, is that a user can configure the behavior for the account, whereas TicketAlwaysEmailSubscriber allows the administrator to configure the behavior.

Assuming you have a workaround, I'm closing this and will focus on #13124. Unfortunately I hardly have time to keep this important plugin working, but hope to eventually have a version that works well with Trac 1.2.

comment:12 in reply to:  8 ; Changed 5 years ago by Ryan J Ollos

Replying to Peter Suter:

Then I guess a custom subscriber could provide a default subscription with priority 0 and adverb never for account notifications. (But AlwaysEmailSubscriber also has priority 0!) Or possibly the account notifications should be sent by calling directly e.g. NotificationSystem.distribute_event() instead of NotificationSystem.notify().

Is the idea that we can filter out AlwaysEmailSubscriber from NotificationSystem.subscriptions before calling distribute_event?

comment:13 in reply to:  12 ; Changed 5 years ago by Peter Suter

a custom subscriber could provide a default subscription with priority 0 and adverb never for account notifications.

This approach would try to get NotificationSystem.subscriptions itself to drop the subscriptions by AlwaysEmailSubscriber by adding never "unsubscriptions" of higher priority.

(But AlwaysEmailSubscriber also has priority 0!)

I'm not sure if it's allowed to have higher priority (lower number) than priority 0, i.e. negative priority. It seems zero is already questionable according to this documentation:

priority: An integer priority. Smaller numbers have higher priority than bigger numbers. 1 is the highest priority.

I don't remember why (I thought) this is the case.


Or possibly the account notifications should be sent by calling directly e.g. NotificationSystem.distribute_event() instead of NotificationSystem.notify().

This alternative approach would not use NotificationSystem.subscriptions at all, based on the assumption that "normal subscriptions" are irrelevant e.g. to a password reset event, where Account Manager must send email to (and only to) the current user:

nsys = NotificationSystem(self.env)
special_current_user_subscription = (current_user_sid, current_user_auth, current_user_addr, 'email', 'text/plain')
subscriptions = [special_current_user_subscription]   # instead of nsys.subscriptions
nsys.distribute_event(event, subscriptions)   # instead of nsys.notify(event)

This shuts out flexible subscriber plugins configurable by users and admins from influencing the behavior. Instead the behavior is more hardcoded = predictable = reliable = secure.

comment:14 Changed 5 years ago by Peter Suter

Yet another approach would just change AlwaysEmailSubscriber itself, so it can be configured to ignore certain realms.


One more alternative is to disable AlwaysEmailSubscriber entirely and use e.g. TicketAlwaysEmailSubscriber instead, which only CC's the mailing list for the ticket realm.

comment:15 in reply to:  13 Changed 5 years ago by Ryan J Ollos

Replying to Peter Suter:

Or possibly the account notifications should be sent by calling directly e.g. NotificationSystem.distribute_event() instead of NotificationSystem.notify().

This alternative approach would not use NotificationSystem.subscriptions at all, based on the assumption that "normal subscriptions" are irrelevant e.g. to a password reset event, where Account Manager must send email to (and only to) the current user:

nsys = NotificationSystem(self.env)
special_current_user_subscription = (current_user_sid, current_user_auth, current_user_addr, 'email', 'text/plain')
subscriptions = [special_current_user_subscription]   # instead of nsys.subscriptions
nsys.distribute_event(event, subscriptions)   # instead of nsys.notify(event)

This shuts out flexible subscriber plugins configurable by users and admins from influencing the behavior. Instead the behavior is more hardcoded = predictable = reliable = secure.

This sounds good. I will give it a try. I seems like the preferable approach since we don't have permissions for subscribers.

comment:16 in reply to:  14 Changed 5 years ago by Ryan J Ollos

Replying to Peter Suter:

Yet another approach would just change AlwaysEmailSubscriber itself, so it can be configured to ignore certain realms.

That looks like it would be useful to implement in Trac 1.5.x. I might try implementing if I find time.

I think the implementation in r17492 went well following your suggestions. Thanks!

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Ryan J Ollos.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.