[FFmpeg-devel] core infrastructure badge for FFmpeg

[Hendrik Leppkes]

On Tue, Jul 5, 2016 at 1:40 PM, Ganesh Ajjanagadde <gajjanag at mit.edu> wrote:
> 04.07.2016, 22:59, "Ronald S. Bultje" <rsbultje at gmail.com>:
>> Hi,
>>
>> On Mon, Jul 4, 2016 at 9:15 PM, Ganesh Ajjanagadde <gajjanag at mit.edu> wrote:
>>
>>>  04.07.2016, 15:55, "Ronald S. Bultje" <rsbultje at gmail.com>:
>>>  > Hi,
>>>  >
>>>  > On Mon, Jul 4, 2016 at 3:44 PM, Ganesh Ajjanagadde <gajjanag at mit.edu>
>>>  wrote:
>>>  >
>>>  >> 04.07.2016, 15:36, "Ronald S. Bultje" <rsbultje at gmail.com>:
>>>  >> > Hi,
>>>  >> >
>>>  >> > On Mon, Jul 4, 2016 at 3:29 PM, Ganesh Ajjanagadde <
>>>  gajjanag at mit.edu>
>>>  >> wrote:
>>>  >> >
>>>  >> >> 04.07.2016, 10:33, "Clément Bœsch" <u at pkh.me>:
>>>  >> >> > On Mon, 4 Jul 2016 at 13:41 Ganesh Ajjanagadde <gajjanag at mit.edu
>>>  >
>>>  >> >> wrote:
>>>  >> >> >> Hi,
>>>  >> >> >>
>>>  >> >> >> https://bestpractices.coreinfrastructure.org/.
>>>  >> >> >>
>>>  >> >> >> Thoughts on getting this done for FFmpeg?
>>>  >> >> >
>>>  >> >> > Any thing we need to adjust in the project? I don't see much
>>>  things
>>>  >> to
>>>  >> >> > change by looking at
>>>  >> >> https://bestpractices.coreinfrastructure.org/projects/1
>>>  >> >>
>>>  >> >> I could not either.
>>>  >> >> It was something I noticed a week back, judged low-hanging and of
>>>  some
>>>  >> >> benefit to the project.
>>>  >> >> I thus am willing to do it, provided there are no objections.
>>>  >> >
>>>  >> > I think if any changes are necessary to the website or
>>>  documentation or
>>>  >> > code, these would simply go through the relevant review process,
>>>  right?
>>>  >> Or
>>>  >> > am I missing something?
>>>  >>
>>>  >> True. At the moment, it seems like the relevant forms can be filled in
>>>  >> directly from existing information,
>>>  >> and no changes are necessary.
>>>  >>
>>>  >> I can send a screenshot of the filled out form before submitting if
>>>  people
>>>  >> want.
>>>  >
>>>  > Oh I see, I misunderstood. I personally don't have objections to that.
>>>
>>>  Turns out that the first few pages are easy to fill and we already achieve
>>>  them.
>>>  The last few are much harder, and FFmpeg does not currently meet all of
>>>  them.
>>>
>>>  Here is the progress so far:
>>>  https://bestpractices.coreinfrastructure.org/projects/235.
>>>
>>>  I have filled them to the best of my ability.
>>>  Here is a summary of where we fail to meet the criteria,
>>>  and some suggestions for what we could do.
>>
>> [..]
>>
>>>  4. If the project software is an application or library, and its primary
>>>  purpose is not to implement cryptography,
>>>  then it SHOULD only call on software specifically designed to implement
>>>  cryptographic functions;
>>>  it SHOULD NOT re-implement its own.
>>>  Note: This is one where I am personally interested as to why we fail; is
>>>  it for performance reasons that we reimplement crypto?
>>>  Suggestion: No idea until I understand the above.
>>>
>>>  5. The project security mechanisms MUST use default keylengths that at
>>>  least meet the NIST minimum requirements through the year 2030 (as stated
>>>  in 2012).
>>>  Suggestion: add --enable-unsafe-crypt to configure, and by default not
>>>  enable it.
>>>  Change API's and functions accordingly, document it.
>>>  Note: strictly speaking, per the sentence above, it is ok as we do not
>>>  really have "default" keylengths.
>>>  But the extended rationale shows why we fail.
>>>
>>>  6. The default project security mechanisms MUST NOT depend on
>>>  cryptographic algorithms that are broken
>>>  (e.g., MD4, MD5, single DES, RC4, or Dual_EC_DRBG).
>>>  Suggestion: same as 5 above.
>>
>> We don't use any of these for security purposes, we only use them for
>> checking frame hashes in automated tests. That should be totally fine.
>
> We do export them though. Just because the FFmpeg CLI progs don't use them for security,
> does not mean a client does not, or that a client can be easily configured to not use them.
> See e.g openssl's no-weak-ssl-ciphers or --enable-ciphers for libgcrypt
> for what I believe the intent of this requirement is.
>
> Second, are you sure about your claim?
> md5 is used in httpauth per RFC 2617.
> Now this is fixed by the RFC, but it does not mean FFmpeg needs to support it by default.
> In particular, I don't see how this honestly takes care of 6.

This is a rather bad example. The alternative to md5 password digests
is not using digests at all and only use base64 "encoded" passwords.
Would that be better? Certainly not. Its like calling every browser
insecure because it supports md5 digests in the HTTP auth protocol.
There just isn't a better variant, and disabling it would result in
either incompat with HTTP servers using it, or fallback to even worse
variants.

>
> In matroskaenc, mov, 160 bit SHA-1 is used.
> Unless someone who knows the code well, audits the codebase, and checks
> that the SHA-1 and the like are not really for security here (similar to the git model),
> 5 also has problems IMHO.

sha1 in matroskaenc is used to derive a hash as a bitexact fileuid -
the alternative is a randomuid (which wouldnt result in bitexact
files), it has no security implications whatsoever, its just a random
identifier.
mov uses sha1 for AAX keys (Audible files), which is mandated by the
specification.

This is really the general pattern of hash usage in avformat and
avcodec - its used when the specification asks for it.

As for re-implementing AES or hash algorithms - well those are rather
trivial, aren't they. Its not like we re-implement TLS.
The reasoning here is that some of those are strictly required for
some media formats, and having a dependency on an external library for
key features of some media formats is rather restrictive. Is there
even a simple library that offers simple AES/SHA implementations
without being something huge like openssl?

- Hendrik