But Alex, this could be a great improvement in system at all. This can
help administrators to measure better its systems, and may be "force"
developers to solve issues faster.

What do you think?


Daniel

On 8/26/11, Alex Legler <a...@gentoo.org> wrote:
> On Friday 26 August 2011 16:02:56 Kevin Bryan wrote:
>> I was not considering the entire process, just the part that really
>> impacts me: identifying vulnerable and patched packages.  Full
>> advisories are nice, but really what I want to know is when I need to
>> update a particular package.
>>
>> You are right that marking the packages that contain fixes doesn't
>> really scale because of increased baggage to carry forward.
>>
>> The problem I have with GLSA's is that they don't come out until after
>> the problem has been fixed.
>>
>> Perhaps it would be better to just have a system to label a particular
>> ebuild/version as vulnerable.  Maybe something closer to package.mask,
>> but for security would be appropriate.  With a package.security_mask,
>> you could have anyone on the security project update that file with
>> packages as soon as they know about it and while they are waiting on the
>> devs to fix it.  References/links/impact could be noted in the comments
>> above, as package.mask does now.
>>
>> As for interacting with 'emerge', I don't think we want the same
>> semantics as package.mask, since we don't want to force a downgrade (if
>> possible).  It should probably just warn when you ask it to install a
>> vulnerable version.  Upgrades to safe versions will be quiet that way.
>> The @security would contain packages with and without fixes so you get
>> warnings for things that remain vulnerable, and updates for things that
>> are fixed.
>>
>> Thoughts?
>
> I see this as an addition to sending advisories after fixing an issue, not
> as
> a solution to the issue at hand.
>
> --
> Alex Legler <a...@gentoo.org>
> Gentoo Security / Ruby

Reply via email to