Hi all! Currently all security bugs are assigned to security@g.o,
always. This can easily lead to some confusion about who needs to do
something about a given bug; right now this is generally tracked by
whiteboard magic strings that probably not many people outside of the
Security Project understand [1] and this has been a source of
confusion around security bugs for a long time.

To make it abundantly clear who needs to take action for a given bug,
I propose we move away from the dogma of security@ always being
assigned to security bugs, and instead assign bugs to whoever needs to
take action for the bug. For example, on security bugs that need a
package bumped or cleaned up, the package maintainer would be
assigned. For bugs needing a GLSA, security@ would be assigned.

As a nice side effect, this would be a step towards making security
bug state discernable outside of the human-maintained and oft-stale
whiteboard. In the long term, a maintainer's security bugs could be
more easily tracked via things like packages.g.o.

As far as bug handling goes, I see two obvious (though rathor minor)
sticky points:

- Who do we assign bugs to when a bug is in stabilization
state? The stabilization bug will always be assigned to the
maintainer, but the security bug will be neither actionable by the
maintainer nor security@ until the stabilization is finished.

- Rarely, we have a security bug that affects multiple packages with
different maintainers (e.g. a package and its -bin variant). Under
this scheme, we would have to always separate bugs by package
maintainer.

I'm not proposing any change to the Bugzilla product or component, so
security bugs will still be able to be exhaustively enumerated this
way, but any tooling that relies on security bugs always being
assigned to security@ would have to be changed.

What do you all think?

[1] https://www.gentoo.org/support/security/vulnerability-treatment-policy.html "Severity Level" section
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEElFuPenBj6NvNLoABXP0dAeB+IzgFAmJYzIsACgkQXP0dAeB+ IzhE2A//dN66liaaUI3AryDDYsCV2yqz9Y9V126QAtBIefjeMF2tSGPk4STac970 X7dPq7IUxi37gZt6Ol8/vgDhH8U6s5U3upUmgda9adJ4FJkNfv2SHS5hEwIHXT1h e5+f04wH5cAF0s+nofjin5gKCSbQHGZQdHmHhWGf2Ape7TkIkwBYsKU5Y0KbDBi7 HGJ8ZgnVQEYFDcdpls/7T9XjFQv5ZVVr5IdjyVMuffLRQiStk7fdk+KCs9k5IWSC d2fGEzOG8wtl3X4CT8DVpaaPvKyGXCC3OQxCWaSz5KNrQ/h6cnbUwDNezA7w/dON vQwDqnKzQmGHQeDDuPKkSlla9LhYHDRnNF6BJrIsZ8LhtbaGN1V5CW7KzRpPMB72 8Oo2avqvOes7ZbMZKseGemydAz0MGQDWtKW02lh2cWInr+46g/Dw1t30eymDnsa8 AgmSdTcxtNSwfCEAn7v7E7BTLmxOe3ebXIJG5vTmZNBf8pJd9tr/yqE2DDgv0xSc Vp58ebdWPw3p2uWfjN0SOM7B5iVYkF+iSjIH7hgnMgOuTvEq1aYbiXOWx/IdIk7R EgX9G34VDCtdXkau84M3NJDdrzOdk1Zk7lV0b6orcDL2U9eGDo8ABnTBMvqG5Jk+ WdM+RWmnkLc92cR8rgHp3DciYg+TiwTWvvHdERYL/vGTdJQs38A=
=UhzV
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------MCZqeAm2ZRW5ZnvotkOtcTWe
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 15.4.2022 4.38, John Helmert III wrote:

Hi all! Currently all security bugs are assigned to security@g.o,
always. This can easily lead to some confusion about who needs to do something about a given bug; right now this is generally tracked by whiteboard magic strings that probably not many people outside of the Security Project understand [1] and this has been a source of
confusion around security bugs for a long time.

Is there a specific group that has this problem? E.g. inactive
developers, proxied maintainers, (dead) projects? Like is this actually
a wide-spread problem?

To make it abundantly clear who needs to take action for a given bug,
I propose we move away from the dogma of security@ always being
assigned to security bugs, and instead assign bugs to whoever needs to
take action for the bug. For example, on security bugs that need a
package bumped or cleaned up, the package maintainer would be
assigned. For bugs needing a GLSA, security@ would be assigned.

As a nice side effect, this would be a step towards making security
bug state discernable outside of the human-maintained and oft-stale whiteboard. In the long term, a maintainer's security bugs could be
more easily tracked via things like packages.g.o.

p.g.o already has a "security" tab for maintainers, but the bug listing
is pretty ineffective already as-is.

As far as bug handling goes, I see two obvious (though rathor minor)
sticky points:

- Who do we assign bugs to when a bug is in stabilization
state? The stabilization bug will always be assigned to the
maintainer, but the security bug will be neither actionable by the
maintainer nor security@ until the stabilization is finished.

- Rarely, we have a security bug that affects multiple packages with
different maintainers (e.g. a package and its -bin variant). Under
this scheme, we would have to always separate bugs by package
maintainer.

I'm not proposing any change to the Bugzilla product or component, so security bugs will still be able to be exhaustively enumerated this
way, but any tooling that relies on security bugs always being
assigned to security@ would have to be changed.

What do you all think?

[1] https://www.gentoo.org/support/security/vulnerability-treatment-policy.html "Severity Level" section

I don't mind either way as long as it's really fixing a problem. Just
got familiar with the new workflow after most recent change...

Anyway hope things have gotten better since sending this e-mail, but I
fear (assume) people who had these problems aren't actively reading the
mailing list either.

-- juippis

--------------MCZqeAm2ZRW5ZnvotkOtcTWe--

-----BEGIN PGP SIGNATURE-----

iQGTBAEBCgB9FiEEltRJ9L6XRmDQCngHc4OUK43AaWIFAmJj9d1fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk2 RDQ0OUY0QkU5NzQ2NjBEMDBBNzgwNzczODM5NDJCOERDMDY5NjIACgkQc4OUK43A aWK+BwgAgEtLNAF94LjYnC9P1gI4/OVkA4kHfn1kgB8jbS1RYKk6LkNa4cibSscz qV4LpzjouA95TqObTywCsr7/5K3JhX/LDH/Oqww0M03ziknefi/99V97GSX6G6OH o3qI5kqzajMxa+7atMvf4CQdfXpZkXDdLrbTDFbkejfhAlufbIWb58drq1cfDr9k yCwGzwkO3R2XO8/qwOxq5g9cpkfAu8DOsz8YMBUIE12UNinRah12ytXBz+AdBk2V BCyNVFqOS28tVnelXkEtjprOYxDigKOPPhta+G9QIRwBqtLvho4q29IV+YohbU2g qFr/hmZPfx/fm2EgY4ZQIAx27LwJpQ==
=3NEw
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Apr 23, 2022 at 03:49:32PM +0300, Joonas Niilola wrote:

On 15.4.2022 4.38, John Helmert III wrote:

Hi all! Currently all security bugs are assigned to security@g.o,
always. This can easily lead to some confusion about who needs to do something about a given bug; right now this is generally tracked by whiteboard magic strings that probably not many people outside of the Security Project understand [1] and this has been a source of
confusion around security bugs for a long time.

Is there a specific group that has this problem? E.g. inactive
developers, proxied maintainers, (dead) projects? Like is this actually
a wide-spread problem?

No, I don't think so. But currently the one who is expected to act on
a bug is only discernable via whiteboard, which is somewhat unique in
security bugs. Removing some of that 'magic' would seem to be a good
thing in any case.

To make it abundantly clear who needs to take action for a given bug,
I propose we move away from the dogma of security@ always being
assigned to security bugs, and instead assign bugs to whoever needs to
take action for the bug. For example, on security bugs that need a
package bumped or cleaned up, the package maintainer would be
assigned. For bugs needing a GLSA, security@ would be assigned.

As a nice side effect, this would be a step towards making security
bug state discernable outside of the human-maintained and oft-stale whiteboard. In the long term, a maintainer's security bugs could be
more easily tracked via things like packages.g.o.

p.g.o already has a "security" tab for maintainers, but the bug listing
is pretty ineffective already as-is.

Right, because there's not a trivial way to identify who needs to do
something for a security bug. Under this new scheme, a bug would only
be under a maintainer's security bug tab if they were assigned (i.e.,
the package needs a bump), and then removed when security@ is
assigned.

As far as bug handling goes, I see two obvious (though rathor minor)
sticky points:

- Who do we assign bugs to when a bug is in stabilization
state? The stabilization bug will always be assigned to the
maintainer, but the security bug will be neither actionable by the
maintainer nor security@ until the stabilization is finished.

- Rarely, we have a security bug that affects multiple packages with
different maintainers (e.g. a package and its -bin variant). Under
this scheme, we would have to always separate bugs by package
maintainer.

I'm not proposing any change to the Bugzilla product or component, so security bugs will still be able to be exhaustively enumerated this
way, but any tooling that relies on security bugs always being
assigned to security@ would have to be changed.

What do you all think?

[1] https://www.gentoo.org/support/security/vulnerability-treatment-policy.html "Severity Level" section

I don't mind either way as long as it's really fixing a problem. Just
got familiar with the new workflow after most recent change...

I didn't think it was that invasive or disruptive of a change.

Anyway hope things have gotten better since sending this e-mail, but I
fear (assume) people who had these problems aren't actively reading the mailing list either.

I don't think this is really relevant to my proposal. If we decide to
implement this and people get it wrong, oh well. The situation will
still gradually get better.

-- juippis

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEElFuPenBj6NvNLoABXP0dAeB+IzgFAmJkrG0ACgkQXP0dAeB+ IzjZ3A//SEuIUP9ZreJsbhQKRFdaDX8st5PMtZE1wQBzi2f743UeynHnHpL4akYm zbYZBoEcZMFuzpqpi4SaWrX7R6Ow3JZSea4ZZMjeEZeL9jnd+17ntlFHcd/GOIBr DLFSJvzYPUeIogRn9ktvFCm21BQG2OA1ygrws+GTAvUw+TG3iA0p9QpRW2Ckotv7 RQcQA0DRXy54zlqfknsRdesSV0maJahlIrbCG/xacNF5kALRuvQRW5dBsazi5xGH N9x50/+e/GL7fl339Jxhsh00xDDvzCiU+p5/WP8zX7vx1RvSdbEGFKElocCRe/iC QJyZS1GdmsekjKu0C35UvIppJxJBppmf51aI/6vqoiV8YUJNzRSo9rte+nKqI/SD SDCVEbhcTwFoAddnuwY4Ti8x8UC343K3bv2AkLawG0d1CWUC835pjK5QLTeqF0EJ YZkiYHTxCCO0C+locWkpuTjn7M/uVcOr0HGbCbHVbew3bjmgho/7W1i1+JeNpkRZ vA411XR+smQ5CUc8tBg8jRTr34FPtUJnNJUrZiPIXN727EFt68ncjUoWtdyttPQ7 Vzfo77A6+jA3jYUbRHH/3FnHiqxnGnU7XuNRwfcdTL2r6npnUY+A8buqRkXGhuJD HpkMZs7c8I2oEW6iYq3vPF9P7mI6PELGeQ4Z6PNxk9OegzzLO10=
=/tLa
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 15 Apr 2022, at 02:38, John Helmert III <ajak@gentoo.org> wrote:

Hi all! Currently all security bugs are assigned to security@g.o,
always. This can easily lead to some confusion about who needs to do something about a given bug; right now this is generally tracked by whiteboard magic strings that probably not many people outside of the Security Project understand [1] and this has been a source of
confusion around security bugs for a long time.

To make it abundantly clear who needs to take action for a given bug,
I propose we move away from the dogma of security@ always being
assigned to security bugs, and instead assign bugs to whoever needs to
take action for the bug. For example, on security bugs that need a
package bumped or cleaned up, the package maintainer would be
assigned. For bugs needing a GLSA, security@ would be assigned.
[...]

What do you all think?

Yes, please. It's led to no end of confusion and had many requests
for this over the years.

[1] https://www.gentoo.org/support/security/vulnerability-treatment-policy.html "Severity Level" section

Best,
sam

-----BEGIN PGP SIGNATURE-----

iQGTBAEBCgB9FiEEYOpPv/uDUzOcqtTy9JIoEO6gSDsFAmJmAxpfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDYw RUE0RkJGRkI4MzUzMzM5Q0FBRDRGMkY0OTIyODEwRUVBMDQ4M0IACgkQ9JIoEO6g SDsniwf+P5CcQEvwSeNucU3sLej4O0SBJMY8bW17cGzeKJ0oJLDSH8lePKP4TPyj Es5HoG3Fg0jkC1oPbcuFAoFZt2YGBecgzSfK42dkjWYiAbN95h96RJriI6NKEdeB QDTUSr5qEDh3naTDFTADpXLoo5NJJc1wfc8XFhYoP9nXLRlJMjo9mz2jpg7pD0Pn 1ebrQGZ/fakwHTCPIBNd4fMqUqxHAQOuzy3vSQIBuA8qZrd3bPbh1k5Imi7cstKl 0P7wCd3g+/02JyOMuKefF8pr4490bKsYY0fM4ptyHGizKxUzhfIxT/Tfk5MbGoHG kVMYva3Z5NwW0xn/BD175lfUd+mgyQ==
=0mcT
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)