Ticket #1186 (new enhancement)

Opened 6 years ago

Last modified 6 years ago

Support the security set on exherbo

Reported by: zlin Owned by:
Priority: Sometime Milestone: cave Useful Functionality
Component: clients/cave Version: scm
Keywords: Cc:
Blocked By: Blocking:
Distribution: Exherbo

Description

And make it look at masks with token = security.

Change History

comment:1 Changed 6 years ago by ciaranm

The 'security' set isn't a set containing insecure packages, though. It's a horrible bit of voodoo containing the set of changes needed to get rid of security problems. The 'insecurity' set holds things that are insecure.

It's that way because GLSAs are perverse. Exherbo probably doesn't want the same logic or the same names.

comment:2 Changed 6 years ago by Apetrini

Despite of name, can we have something like insecurity (at least for now) on exherbo? In any way exherbo is going to handle "security" we will need an easy way to track buggy packages. I think it should be done with the insecurity set; "cave show insecurity" will show all buggy _installed_ packages; "cave show insecurity*" will show all known buggy packages/specs. cave should extract this kind of information from repository_mask.conf (token = security), as zlin said.

The use-case is to have a clean way to know what installed packages have security holes on your system and then act and proceed manually (for now) to handle/fix them one by one. I think this should be managed as not linked to the security set or any other way to perform automatic security fixes, because we cannot always assume there will be a solution in time(or a solution at all), so insecurity just tells you(hopefully as soon as possible) that there is a problem and then is up to you what to do about it(you can wait for the fix or stop the service in the meantime... you can also take the risk with low impact bugs). I mean... how to solve it is another problem.

P.s. it would be great to improve token=security mask's details with some other kind of informations like... exploitable locally/remotely, severity, type(dos, privilege escalation, code execution, information leak...) etc...

Note: See TracTickets for help on using tickets.