1196623 - make gpg/smime cert requiremented for selected groups

Status: NEW

(bugzilla.mozilla.org :: General, enhancement)

Description

[:glob ✱]

make it possible for admins to configure groups to require a user has a certificate before they can be a member of that group.

- add lazy loaded "public_key_required" field to groups
- add a check when a user is created or edited to prevent adding them to groups
- extend the group membership report to show if a user has a key or not
  - should only be visible to owners or admins of that group

Comment 1

[Ed Morley [:emorley]]

I purposely _don't_ set a certificate, since I use gmail, and there's no good way to view encrypted mails in the web UI. If I were to set a key, the emails would be encrypted, which at best is a waste since I can't view the content, and at worst means I lose the link to the bug (since there is no plaintext fallback iirc).

By not setting a key that means I can simply use the bug link within the email, and view the content on bugzilla. The email is sanitised and so no information is leaked that would otherwise have been encrypted were I to have had a key set. It is also my understanding that password resets are blocked since I am a member of a security group, so it's not like that can leak either.

If I've understand the proposal here correctly, we're suggesting the above will be disallowed for members of certain groups. What is the benefit of doing this?

IMO this should block on adding the plaintext fallback to emails, or this breaks the web UI workflow.

Comment 2

[:glob ✱]

(In reply to Ed Morley [:emorley] from comment #1)
> I purposely _don't_ set a certificate, since I use gmail, and there's no
> good way to view encrypted mails in the web UI. If I were to set a key, the
> emails would be encrypted, which at best is a waste since I can't view the
> content, and at worst means I lose the link to the bug (since there is no
> plaintext fallback iirc).

bug 1190476 fixes the missing link issue if you're using pgp.
that should be live early next week.

> IMO this should block on adding the plaintext fallback to emails, or this
> breaks the web UI workflow.

i've heard that https://www.mailvelope.com/ works (although i don't have any personal experience with it).

Comment 3

[Daniel Veditz [:dveditz]]

(In reply to Byron Jones ‹:glob› from comment #0)
> make it possible for admins to configure groups to require a user has a
> certificate before they can be a member of that group.

What is the motivation for this feature? I can guess but it would be nice to document what's gained here. Clearly it's not security for the usual bugmail because we can already mark groups so that only buglinks get sent if there's no key. I assume therefore that this is primarily useful as a way to make sure plaintext password-reset links don't get sent--but I thought the existing group already did that, too (by sending mail saying you need to contact an admin)?

Comment 4

[:glob ✱]

(In reply to Daniel Veditz [:dveditz] from comment #3)
> What is the motivation for this feature? I can guess but it would be nice to
> document what's gained here.

i'm pretty sure this feature was requested by someone in the security team - needinfo'ing jeff.
should discussions reveal that this feature is undesirable i'm happy to wontfix.

> I assume therefore that this is primarily useful as a way to make sure plaintext
> password-reset links don't get sent

my preferred fix for that issue is in bug 1196733.

Comment 5

[Jeff Bryner [:jeff] (use NEEDINFO 😉)]

Yes the motivation is to take the admins out of the loop and secure the password reset process end-to-end for security group members. 

Any reason a security group member should not have a public key?

Comment 6

[Ed Morley [:emorley]]

(In reply to Jeff Bryner [:jeff]  (use NEEDINFO) from comment #5)
> Yes the motivation is to take the admins out of the loop and secure the
> password reset process end-to-end for security group members.

Could you be a bit more specific as to the use-cases/problems this is attempting to solve?

eg: Is this so that the process is self-serve (to avoid people being blocked on BMO admins), or to avoid mistaken identity over IRC whilst interacting with the BMO admin, or ...?

(In reply to Jeff Bryner [:jeff]  (use NEEDINFO) from comment #5)
> Any reason a security group member should not have a public key?

If I can still get the bug number in the email subject (obviously not the bug summary) and a link to the bug in plaintext in the email that gmail can read, then there wouldn't be a problem. However bug 738799 is still open, and the key I have locally is S/MIME not PGP. (And I've had bad experience with addons and leaks/perf, so I'm not keen on using Mailvelope for the couple of times a month I get a securemail).

I suppose I could create a throwaway PGP key so I can take advantage of bug 1190476 - though I'd still then probably end up resorting to pestering a BMO admin for a password reset, should I need one - seeing as I don't use PGP and have no need to keep it installed.

(In reply to Byron Jones ‹:glob› from comment #4)
> (In reply to Daniel Veditz [:dveditz] from comment #3)
> > I assume therefore that this is primarily useful as a way to make sure plaintext
> > password-reset links don't get sent
> 
> my preferred fix for that issue is in bug 1196733.

I can't see that bug - could I have a CC please? :-)