> On Jul 30, 2015, at 3:42 PM, Blibbet <blib...@gmail.com> wrote:
> 
> [...]
>>>> Sorry I was thinking more about routine maintenance (like the string n
>>>> cleanup recently), or refactoring of the code disabling the exploit
>>>> mechanism with out knowledge that the exploit exists.  I guess an older
>>>> branch can get patched, but the commit history in master is not going to
>>>> record the CVE.
>> 
>> Ah, right. That makes sense, absolutely. A fresh release may not contain
>> the bug any longer, as random luck, without any clues for the user.
> [...]
> 
> Sorry, I'm dim, this makes no sense to me, unless both of you forgot
> smileys.
> 
> Why strip off useful metadata in the public release, if you have it? Why
> not add useful metadata to the public release?
> 

The point was about commit messages. My example cases where the code base had 
the bug, the code got removed for some random reason not related to the CVE, 
and then the CVE comes along. In this lifecycle there is no commit message that 
the CVE has been fixed. 

> Or is it that the CVE data is only available internally to UEFI Forum
> members?
> 

The public data should be public :). 

Thanks,

Andrew Fish

> UEFI Forum's antis numbers are already in the UEFI spec, in the revision
> section. And a CVE isn't supposed to be a private/internal identifier,
> it's supposed to be public, for people to search for, not something an
> industry trade group should be obfuscating from the public.
> 
> Why  keep people in the dark about vulnerabilities in the public code? I
> can see how some vendors want to keep their customers ignorant, but this
> is code that's shared but multiple vendors, exploitable open source is
> not useful to anyone.
> 
> Thanks for any clarification.
> 
> PS: CHIPSEC is working on a new security test for this. I hope QA teams
> at all OEMS will start using it when it's out:
> https://github.com/chipsec/chipsec
> 
> 
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Reply via email to