Hi Michał,
I do agree with the gist of what you're saying, and in absence of a
better solution I'm in support.
I also make a disclaimer: I only use amd64 so none of this really
affects me, so at the end of the day - I don't really care.
We have tinderboxes already running that does all kinds of testing for
amd64 and specifically, both musl and glibc as far as I'm aware. This
could be trivially extended to x86 by way of chroot I believe.
Given emulators I believe it's also possible to extend this to other
arches at somewhat crazy CPU overhead costs, and I'm not convinced of
the reliability of these emulators vs real hardware but for the purposes
of this discussion it may be a moot point (if it works on the emulator
it's more likely to work on real hardware than the other way around).
Given the work on nattka, is it possible that nattka could be extended,
in collaboration with he tinder hosts to submit a specific package for
compile testing? Specifically for security (and possibly stablereq)
bugs I'm thinking have the tinderboxes do the compile tests, as
requested by nattka, and then once amd64 and possibly x86 has confirmed,
give the security team the option to force stable on the other arches?
This may seem to be more controversial than dropping stable for those
arches, however, consider that ~arch just gets marked anyway, so
frankly, we're no worse off than with dropping stable for these arches.
The point of controversy is that we're taking out a testing point for
packages, and by implication, control as well as responsibility away
from the arch teams.
I'm also wondering about the overall stabilisation process. To be
frank: A LOT of work is being handed over to the arch teams. I'm not against this, but could we possibly come up with a better way?
Specifically, if anyone can request a stable request for an arch, and
the package maintainer can OK that within certain rules and constraints
(system enforced, with arch teams allowed to violate that, so if a
package manager can motivate why then arch can overrule). So in essence:
1. Anyone can request stable for an arch on a package.
2. Package maintainer does first ACK (or automatic after a time delay
and additional parties has requested?)
3. Tinderbox for compile tests (At least -* and * on the package
itself, ideally with "-* single" as well, and any other USE flags as
required by single ... this will burn a lot of CPU, which is arguably
better than developer time).
4. If there are tests, run these too, and if they all pass, proceed to stable.
5. If there are not tests ... ?
Anyway, just some thoughts, hoping to spark some ideas. At the end of
the day I agree with Michał (as I read his message) - differentiation
between stable supported and security supported doesn't make sense.
Kind Regards,
Jaco
On 2021/10/21 10:05, Michał Górny wrote:
Hello,
Splitting from the discussion in [1] (moving more arhitectures to
~arch), I'd like to propose that we remove the "security supported" architecture list from [2] and instead level security support with
the general architecture support in Gentoo, e.g. by having all
architectures with stable profiles be "security supported".
Rationale:
1. The architecture list seems to date way back and doesn't seem to have
been maintained properly. According to CVS history, the last time a new architecture was marked "supported" was in 2005; since then,
architectures were only removed. After the migration to new website,
the points of contact for architectures aren't even listed anymore.
The presence of 'ppc' on the list is doubtful at best. At the same
time, 'arm64' is not supported.
2. Keeping a separate list can cause confusion, if not make users of architectures such as arm64 feel belittled. I don't really see why
the Security team should be overriding the overall Gentoo architecture support status.
3. Per the policy, Security team "will not wait for a stable fix on
these arches before issuing the GLSA and closing the bug". The former
I don't have a problem with but how could you close the bug before
cleaning up old versions, and how would you clean up the old versions
when the new ones aren't stable yet everywhere?
4. In the end, Security team isn't really respecting this policy.
In the end, this leads to absurdities like GLSA being released before
a package is stable on amd64, and confusing the users [4].
While I agree we could probably establish some criteria when GLSAs
should be released, the current policy is incorrect and obsolete. In my opinion removing the list is the first step towards cleaning stuff up.
[1] https://archives.gentoo.org/gentoo-dev/message/fd18905401a1aec78aa6af7238f5ca1c
[2] https://www.gentoo.org/support/security/vulnerability-treatment-policy.html
[3] https://gitweb.gentoo.org/archive/proj/gentoo.git/log/xml/htdocs/proj/en/security/index.xml
[4] https://bugs.gentoo.org/789240#c2
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)