As discussed with robbat2 and the security@ alias, making a bug to better track this issue.
Bugzilla isn't secure to use for embargoed issues, as email notification is sent out in clear irrespective of restrictions put in place for group. Gentoo further allows developers to forward emails off of Gentoo infrastructure, so a secure environment is not guranteed for all developers.
In theory Bugzilla supports OpenPGP, in reality it doesnt:
Borrowing the text from [this year's GSoC proposal]:
Currently the OpenPGP bugzilla support is defunct in at least three ways:
It encrypts to the first public key it considers viable, not respecting usage flags, leading to scenarios where the message is un-decryptable
There is no mechanism for refreshing public keys from known public sources (e.g HKP keyservers) leading to a situation where subkey rotation or changers to primary certificate (e.g due to expiry or revocation) is not picked up automatically and needs to be manually adjusted, failure to do so can lead to encryption to a known non-viable certificate
There is no group definition where multiple public keys can be assigned e.g to an alias account (security@) in bugzilla.
Having support for OpenPGP is necessary to retain confidentiality of restricted bugs in bugzilla, a lack of this results in information leakage. Alternatively, bug emails for group restricted bugs should not include metadata or data that can identify the issue, but merely report e.g "bug XXX has been updated, please log in to see the changes"
Discussion about solution
Recapping some of the email discussion for archiving purposes:
* We should try to make a generic solution that can be upstreamed, not only a gentoo specific one
* Users should be able to provide fingerprint of OpenPGP public keyblock in bugzilla interface
* We already have fingerprint for devs in LDAP, we can use this to populate Bugzilla information for devs
* Bugzilla OpenPGP store needs to be able to be refreshed to get information about revoked keyblocks
* Refresh functionality should be configurable, there might be installations that do not want this feature, but default should be on.
* Failing to find a usable public keyblock to encrypt any message to should result in no email notification being sent to that user
* [MemoryHole] is needed if information other than bug ID provided in Subject
... I've probably forgotten something trying to summarize here, but lets not forget this at least...
[this year's GSoC proposal]
Promising comment on https://bugzilla.mozilla.org/show_bug.cgi?id=790487#c16 :
"This bug may have been resolved by the Securemail update last week. If anyone following along can verify whether it has or not, that would be very useful to know."