Launchpad sends (unencrypted) mail notifications about private assets

One option might be to encrypt private bug mail (assuming that the user has registered a GPG key that is usable for encryption).

Yup. It might be interested to have a preferences option for Encrypt: Always, confidential, and never. Sign: Always, confidential, and never.

But I don't know that it would solve the problem for the average end user. If it's not set to encrypt the confidential email, I think it still shouldn't send the contents. Otherwise someone pasting logs with passwords might not realise that it's going over a plaintext session until after they've received a copy of it.

Tks,
Jeff Bailey

Won't this be seriously inconvenient for security personnel?

I wouldn't mind emails getting encrypted.

As for the other option, it would be a minor inconvenience to have no contents at all, as the majority of the security bugs are not marked private. Since I already use LP to do the security bug reviews (email notifications tend to just be a "reminder" to go check the bug lists), it wouldn't be too bad for me. (As long as there's still a bug URL in the email, I'm happy.)

How about this:

If a bug is not private, do what we've always done.

If a bug is private, and the user has accepted to get encrypted e-mail, encrypt it. If he hasn't accepted to receive encrypted mail, send only the status change stuff (and perhaps a notification of new comments). The footer should contain a link to the place where you change your "accept encrypted e-mail" setting.

When implementing this, it might make sense to go through all the bug mail that malone has received, find the GPG signed e-mails and set "accept encrypted e-mail" for the senders to "on" as they clearly have used gpg before and are likely to be able to use it. Also, when a user sends his first gpg signed e-mail to malone, this setting should be set to "on".

Soren,

I'd say status change, plus URL to get to the message. After that, it looks good to me.

I'm putting this back to high, because our notifications really make a bit of a mockery of our ssl-only approach.

good luck implementing this in the next two years

Turning on voluntary SMTP TLS on outgoing mail (from eg fiordland)
would get close to the security properties of https, with no code
changes and no user disruption. Like for https, this would protect
the data in transit, and it is fairly plausible (though not
guaranteed) that users have a secure path between their MUA and MX,
and that their MUA is as secure as their browser.

fwiw I think there is an existing, very old rt, for doing this.

Stakeholders would like this addressed in some fashion; optimistic TLS as a requirement is probably a decent approach - and route all non-optimistic-TLS mails tagged for private objects to a blackhole that logs the fact and swallows the mail.

I was just made aware of this bug report after mine was marked as a duplicate. I'm absolutely astounded that this has been known since 2005 and yet nothing has changed!

For example, It would be nice to have a toggle on account level to not mail out notifications about private things ever.

Or, for example, make a secure notification with a generic text and obfuscated authenticated url which will redirect to the whatever the notification is (i.e. build failure, bug report, merge proposal, etc). Apparently some banks in US do "secure mail" this way, to enforce TLS+http retrieval of notifications.