[FFmpeg-devel] core infrastructure badge for FFmpeg

[Ganesh Ajjanagadde]

05.07.2016, 08:16, "Ronald S. Bultje" <rsbultje at gmail.com>:
[...]
>>  > [..]
>>  >
>>  >> 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?

It is a subtle point, taking your argument, openssl and libgcrypt don't need to provide the option.
It is needed for them, if for nothing else, for FIPS requirements.
A client could maintain their own patchset, but it is useful to do it there.

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

I am aware of the term "FUD".

You have done this repeatedly in the past, accusing me of making claims when there is no claim made.
There was a basic "Unless..." qualifier.
Anyone with a working knowledge of English who pulls the mail will realize that there is no such accusation
about FFmpeg.

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

Matroska was given as a single example. I doubt you could make the claim of familiarity for everything in FFmpeg.
Nevertheless, to a reasonable degree, this is fine.

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

Ok, there are a number of others in the original post.

>
> Ronald
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel