Re: [edk2] Tianocore Community Update 2016 #1

[Laszlo Ersek]

On 03/10/16 18:20, Mangefeste, Tony wrote:
> 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.

Sounds great. I think it also matches David's idea.

Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Tianocore Community Update 2016 #1

[Mangefeste, Tony]

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

Re: [edk2] Tianocore Community Update 2016 #1

[Laszlo Ersek]

On 03/10/16 14:11, David Woodhouse wrote:
> On Thu, 2016-03-10 at 13:58 +0100, Laszlo Ersek wrote:
>>
>>> Sure, actually getting vendor buy-in for that is a completely different
>>> story. But let's not design the system to make it hard :)
>>
>> I couldn't buy in.
> 
> That's fine. I'm not asking you to. I'm just asking that we don't make
> it *harder*.
> 

Okay.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Tianocore Community Update 2016 #1

[David Woodhouse]

On Thu, 2016-03-10 at 13:58 +0100, Laszlo Ersek wrote:
> 
> > Sure, actually getting vendor buy-in for that is a completely different
> > story. But let's not design the system to make it hard :)
> 
> I couldn't buy in.

That's fine. I'm not asking you to. I'm just asking that we don't make
it *harder*.

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Tianocore Community Update 2016 #1

[Laszlo Ersek]

On 03/10/16 11:58, David Woodhouse wrote:
> On Thu, 2016-03-10 at 11:33 +0100, Laszlo Ersek wrote:
>>
>>> * 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.
> 
> I concur.
> 
> The end goal should be a coherent bug tracking system where a user can
> file a bug, and it can be reassigned to TianoCore or to a specific
> vendor's "value subtract",

I think a cross-vendor tracker is too steep. Usually vendors (including
Red Hat) have their own public trackers already. For example, in Red Hat
Bugzilla you can report bugs for (downstream) OVMF today.

In Red Hat Bugzilla, bugs reported for downstream components that need
upstream fixes first are handled in two three ways:

- Sometimes the community decides to use Red Hat Bugzilla for upstream
tracking. (Example: libvirt.) In this case, RHBZ receives two bugs: one
for upstream, one for downstream. One is usually a clone of the other
(within a single BZ instance, you can clone bugs, and their dependencies
are set up automatically). They are also reported for separate products.

- If the upstream project has an independent tracker, then RHBZ offers
metadata fields for linking the upstream tracker entry. It even has some
ingrained knowledge about specific high-profile upstream trackers
(FreeDesktop.org Bugzilla, GCC Bugzilla, Kernel Bugzilla, and so on.)

- If the upstream project lacks a tracker completely, then the important
upstream mailing list threads are linked as comments in the RHBZ entry
(problem report message, patch submissions, and so on). The hashes of
the commits that fix the issue are also captured in a comment. (If the
upstream project has its own tracker, then the hashes are (should be)
listed there.)

> and its *whole* lifetime can be tracked
> until a fix is released for the specific instance that the user has
> reported it with.
> 
> For that, we *are* going to need the thing to live under the auspices
> of the UEFI Forum, and we are going to need to be able to mark things
> as private — using an account system that is *directly* under our
> control.

I don't think I'd be permitted to store data (private comments, for
example) related to product planning in an external tracker. Product
planning and many other managerial workflows can depend on bug metadata
that are specific to a company or a department.

I think a cross-vendor tracker is too much; my vote is an upstream-only
tracker.

> Sure, actually getting vendor buy-in for that is a completely different
> story. But let's not design the system to make it hard :)

I couldn't buy in.

Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Tianocore Community Update 2016 #1

[David Woodhouse]

On Thu, 2016-03-10 at 11:33 +0100, Laszlo Ersek wrote:
> 
> > * 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.

I concur.

The end goal should be a coherent bug tracking system where a user can
file a bug, and it can be reassigned to TianoCore or to a specific
vendor's "value subtract", and its *whole* lifetime can be tracked
until a fix is released for the specific instance that the user has
reported it with.

For that, we *are* going to need the thing to live under the auspices
of the UEFI Forum, and we are going to need to be able to mark things
as private — using an account system that is *directly* under our
control.

Sure, actually getting vendor buy-in for that is a completely different
story. But let's not design the system to make it hard :)

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Tianocore Community Update 2016 #1

[Laszlo Ersek]

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  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