[FFmpeg-devel] core infrastructure badge for FFmpeg

Ronald S. Bultje rsbultje at gmail.com
Tue Jul 5 15:08:22 EEST 2016


Hi,

On Tue, Jul 5, 2016 at 7:40 AM, 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.
>

I don't know if we can be held responsible for what clients do. The intent
of 6 is for our software, not client software, right?

We can add an option to httpauth to allow disabling md5 encryption in the
list of supported encryption protocols (if such an option doesn't already
exist). But I certainly wouldn't go beyond that.


> 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.
>

This is known as "FUD" (Google it if that sounds new). Don't make such
claims unless you have done research, the issue is that people will link to
your email in the mailinglist archives and then claim that "ffmpeg is
fundamentally insecure" - which is utterly untrue.

And yes, like in our tests, the sha1s in matroska are simply internal
checksums, they are not security-related. And yes, I'm extremely familiar
with matroska.

As for reimplementing crypto, AES encryption is done in lavf/srtp.c.
> We thus do not meet 4, though this is not a "must" requirement.


So there still isn't really an issue. Let's stick to issues for now.

Ronald


More information about the ffmpeg-devel mailing list