[FFmpeg-devel] CII Best Practices badge for FFMPEG

[Ganesh Ajjanagadde]

14.07.2016, 18:48, "Wheeler, David A" <dwheeler at ida.org>:
>>>>  “The project SHOULD implement perfect forward secrecy for key agreement protocols so a session key derived from a set of long-term keys cannot be compromised if one of the long-term keys is compromised in the future. [crypto_pfs]
>
>>>  This might be okay to state as “unmet” or “N/A” depending on what you do.  In [crypto_call] you note that “FFmpeg reimplements common cryptographic primitives like AES, Blowfish, SHA, etc in files within FFmpeg. Many of them are simply used to meet a multimedia specification, and in many cases it is not security relevant. As FFmpeg is a very widely used library deployed in a variety of configurations, it is desired to have as few external dependencies as possible.”  If the crypto isn’t security-relevant, then it’s N/A.  If it’s relevant but you have a good reason to not do it, you can mark it as “Unmet” and provide a (reasonable) justification.
>
>>  Is this referring to the project infrastructure, or the project itself?
>
> My intent was for the project itself (the software that you're developing). It states the top of the section that 'A "project security mechanism" is a security mechanism provided by the delivered project's software.' Looks like we should make that clearer, sorry about that.
>
> I wouldn't be surprised if this is N/A for FFMEG.
>
> Of course, I'd encourage using PFS for the project infrastructure too, but that's a different issue.
>
>>>>  “At least one static code analysis tool MUST be applied to any proposed major production release of the software before its release, if there is at least one FLOSS tool that implements this criterion in the selected language. [static_analysis]
>
>>>>  FFmpeg uses Coverity (scan.coverity.com) before production releases, which checks for a variety of common C programming mistakes. It should be noted that Coverity is not perfect, and there are false positives. This is not enforced though.”
>
>>>  I’m not sure what you mean by “enforced” – what we care about is what you *do*.  If you do it, then you do it.  This criterion requires that you apply a tool before a major release – so if you use Coverity scan to meet this, then you meet it!  Given what you’ve said, I suspect this is actually “Met”.
>
>>  I meant the following by "not enforced": practically, yes, it is done at least once before release. However, it is not a "release blocker" AFAIK.
>
> If you do it, then you do it. We don't care if you label it "release blocker" or not.
>
> In particular, since practically all tools have false positives, what we're really looking for is an effort to scan the code, examine the results, and work down reported or potential problems.
>
> I hope that helps!

Thanks. Updated except for the tests aspect, which I am still uncomfortable with -
there is often a > 3 month gap between adding a new component and adding a test for it.
A new filter (for example) is definitely what I would call a major change.
Concretely, aemphasis was added in 3.0, filter itself dating to Dec 2015.
A test was added in late May 2016, way after the 3.0 release in Feb 2016.
Examples may be given in a similar fashion for the 3.1 release.
Apart from that, I believe every hard requirement is met.

>
> --- David A. Wheeler