[FFmpeg-devel] CII Best Practices badge for FFMPEG

Wheeler, David A dwheeler at ida.org
Fri Jul 15 01:48:18 EEST 2016

>>> “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!

--- David A. Wheeler

More information about the ffmpeg-devel mailing list