[FFmpeg-devel] core infrastructure badge for FFmpeg

[Ronald S. Bultje]

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.

Ronald