Very good thoughts, Laszlo. The more I think about GitHub integration, the more I'm leaning against it. Another reason is that we can assign groups to certain organizational emails to allow/grant special rights to specific classes of issues. For example, it's plausible that we would give anyone from *@redhat.com for instance a group that identified them as part of that organization and then grant tha ability to perform special triage tasks or other organization specific tasks, while keeping the content visible to the community.
-----Original Message----- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Thursday, March 10, 2016 2:33 AM To: Mangefeste, Tony <tony.mangefe...@intel.com> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org> Subject: Re: [edk2] Tianocore Community Update 2016 #1 On 03/09/16 19:49, Mangefeste, Tony wrote: > I. Defect & Issue Tracking > There are several topics we're investigating, and your input is appreciated: First of all, thank you very much for going forward with Bugzilla! > * Considering tying the Bugzilla login to GitHub using GitHub as the > provider. This would mean that anyone wishing to submit an item into > BZ would require a GitHub account. I vote against this. I find 3rd party authentication providers insecure. While I find Single Sign On extremely useful (and also secure) in a single, centrally managed organization, GitHub and the edk2 Bugzilla (to be operated by Intel) are separate entities. A breach of GitHub could lead to a breach of the Bugzilla, and leakage of sensitive data (private comments, private bugs, private attachments). Downtime of GitHub would prevent us from logging into Bugzilla. Modern browsers have built-in password managers. The practice I generally follow is to have a unique, complex, machine-generated password for every public-facing website, and to store those in a reliable password manager (behind a very strong master password of coruse). --*-- Another practical remark: I insist on having access to the personal email addresses of people who report bugs, for two reasons. Less importantly, I want to be able to contact them in email, outside of bugzilla (they might have some files I need for debugging, but their data is too sensitive or too big to attach to the bug). More importantly, if I write patches for a BZ entry (bug or feature request), I always CC the reporter on the patches. Now, purely for informing the reporter about the patches, my "other" best practice would suffice in itself -- that best practice being: I link every patch submisson from the mailing list archive immediately into the bug --, but the main goal is that I want his/her testing feedback. For that the reporter should be able to build my patches, hence I CC him/her directly. Therefore I need his/her email address on the bug. Fishing the emails of reporters out of GitHub's issue tracker has been a pain. One clicks the "@reporter_nick" style link in the discussion, and hopes that the reporter's profile page lists his/her email address publicly. If it doesn't, then I have to ask for it in the tracker entry explicitly, or I can try googling it. Bugzilla normally gives me the email addresses of all commenters on the bug automatically, and so it should be. (Example: my profile page <https://github.com/lersek/> does not list my email address either. Why? Because I don't like spam, and my email is trivially googleable for humans, from my name & employer. The point with Bugzilla is that it only exposes email addresses to logged in users (no bots), but then logged in users do get all the addresses without further obstacles.) I'm worried that if GitHub provided the authentication for Bugzilla, it could withhold email addresses from Bugzilla, and break the above use case. Thank you Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
