Hi, On Mon, Jul 4, 2016 at 9:15 PM, Ganesh Ajjanagadde <gajja...@mit.edu> wrote:
> 04.07.2016, 15:55, "Ronald S. Bultje" <rsbul...@gmail.com>: > > Hi, > > > > On Mon, Jul 4, 2016 at 3:44 PM, Ganesh Ajjanagadde <gajja...@mit.edu> > wrote: > > > >> 04.07.2016, 15:36, "Ronald S. Bultje" <rsbul...@gmail.com>: > >> > Hi, > >> > > >> > On Mon, Jul 4, 2016 at 3:29 PM, Ganesh Ajjanagadde < > gajja...@mit.edu> > >> wrote: > >> > > >> >> 04.07.2016, 10:33, "Clément Bœsch" <u...@pkh.me>: > >> >> > On Mon, 4 Jul 2016 at 13:41 Ganesh Ajjanagadde <gajja...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
