I'd like to propose a new "virtual" architecture, called "~sec" for security. This keyword is supposed to be a "secondary" one for users, who want to decrease possible vulnerabilities. Usage should be look like this: ACCEPT_KEYWORDS="arch ~sec". The reason to use this is the following: The time between an ebuild, that fixes a vulnerability and the time it gets stabilized by the arch team can be dangerous for a running box. It is also sometimes better to get more security than stability. My idea is to add this to the security procedure: If an ebuild that fixes a vulnerability (CVE, etc.) gets added to the tree, also ~sec is added as a keyword. Users, who use ~sec in ACCEPT_KEYWORDS, will get the fixes instantly on emerge and don't have to wait for stabilization time. Obviously some packages with fixes included won't compile or have dependencies, which are keyworded ~arch. I have no idea to get this problem fixed, otherwise than explaining it with: it's "~sec" and not "sec" and ~arches are for advanced users. If it doesn't compile then it is a bad fix, if it has unstable dependencies: this will be solved, when its stabilized for arch.
CC'ing portage devs for their opinion
>The time between an ebuild, that fixes a vulnerability and the time it gets >stabilized by the arch team can be dangerous for a running box. Yes. >It is also sometimes better to get more security than stability. Uh, well. That depends. I agree with you that the gap between commiting the ebuild and its stabilization should be closed. There is an additional gap: from stabilization to glsa release. In that period, users might not know that an update is a security fix and thus see no need to install it. Also automated tools that compare GLSAs with your installed files might not report a problem - this is important for large installations. We're way behind schedule with GLSAs, so this is a big problem, too. I think your proposed idea will not work, because it often has a reason that the packages are not stable yet (e.g. ABI breakage after bumps or the like), it's not only that devs just didn't look at it yet. I'm thinking about it the other way round: as soon as we know of a problem (that as, as soon as we file a bug) with a package, the security team adds a flag to that package that says it's insecure. Portage could spit out warnings for those and users know about bugs as soon as we know about them and not 6 months later when the GLSA is sent.
(In reply to comment #2) > I'm thinking about it the other way round: as soon as we know of a problem > (that as, as soon as we file a bug) with a package, the security team adds a > flag to that package that says it's insecure. Portage could spit out warnings > for those and users know about bugs as soon as we know about them and not 6 > months later when the GLSA is sent. > Yep, this seems to be a better solution. So we need something like packages.insecure, which consists of all vulnerable versions of packages in the tree. This could be managed by bugzilla, so if a security bug gets opened/closed the packages.insecure gets an update.
Offhand, the proposed ACCEPT_KEYWORDS="actual-arch sec" won't fly- ACCEPT_KEYWORDS is an OR set of allowed values. Think through what ACCEPT_KEYWORDS="~x86" actually is- it's ~x86 and x86 upon expansion. Personally I'd just look at generating a secondary set of glsa's automatically based off of bugzilla data... that seems like a cleaner integration.
(In reply to comment #4) > Offhand, the proposed ACCEPT_KEYWORDS="actual-arch sec" won't fly- > ACCEPT_KEYWORDS is an OR set of allowed values. Think through what > ACCEPT_KEYWORDS="~x86" actually is- it's ~x86 and x86 upon expansion. And those keywords need to be maintained, too...otherwise the ~sec keyword may be caried on from bump to bump. > Personally I'd just look at generating a secondary set of glsa's automatically > based off of bugzilla data... that seems like a cleaner integration. Some kind of provisional GLSA.
> Personally I'd just look at generating a secondary set of glsa's automatically > based off of bugzilla data... that seems like a cleaner integration. Did you have a look into that yet?
(In reply to comment #6) > > Personally I'd just look at generating a secondary set of glsa's automatically > > based off of bugzilla data... that seems like a cleaner integration. > > Did you have a look into that yet? I was telling folks what to do, I most definitely wasn't taking on the work myself ;) To do this isn't too hard- it's mostly glue. Interested parties need to step up and do the work however.
Closing due to lack of developments.
