| 1 |
Rich, |
| 2 |
|
| 3 |
Core should be fine to have a system that at least boots. And security |
| 4 |
still tracks ~arch's to get the system secured by removing vulnerable |
| 5 |
packages as time permits. |
| 6 |
|
| 7 |
We can not have an arch though blocking the security of the whole |
| 8 |
distribution because we can not call for cleanup or release the GLSA, |
| 9 |
waiting for a stabilization of a non-core package, while the actual |
| 10 |
package has been in a tree in ~arch status for weeks or months. If we |
| 11 |
limit the stable packages to only those that are required for core OS |
| 12 |
boot, then the stabilization of the limited packages should be quicker. |
| 13 |
|
| 14 |
|
| 15 |
On 5/8/17 6:48 AM, Rich Freeman wrote: |
| 16 |
> On Mon, May 8, 2017 at 9:21 AM, Thomas Deutschmann <whissi@g.o> wrote: |
| 17 |
>> |
| 18 |
>> It isn't like security project adds any additional load to any arch |
| 19 |
>> team, an architecture capable to keep up with normal keyword and |
| 20 |
>> stabilization requests should also be able to keep up with security. |
| 21 |
> |
| 22 |
> What about arches that use stable keywords only on a core set of |
| 23 |
> system packages to indicate that they're usable, so that they can have |
| 24 |
> a stage3 that actually boots? I'm not sure they even keep up with |
| 25 |
> security in this case. |
| 26 |
> |
| 27 |
> Perhaps they could just use ~arch for the same purpose, but then we'd |
| 28 |
> need to have a policy that REMOVES ~arch when doing bumps on those |
| 29 |
> architectures, which is not our current practice. Otherwise a revbump |
| 30 |
> could break stage3 on those arches. |
| 31 |
> |
| 32 |
> I'm not sure that stable+secure is necessarily a black-and-white thing |
| 33 |
> on our non-mainstream arches. Honestly, I think that people who want |
| 34 |
> to run linux on MIPS/sparc/etc are probably happy enough just to have |
| 35 |
> something that boots. |
| 36 |
> |
Archives