FFmpeg

Les projets qui suivent les meilleures pratiques ci-dessous peuvent s'auto-certifier et montrer qu'ils ont obtenu le badge de la Core Infrastructure Initiative (CII).

Il n'existe aucun ensemble de pratiques qui garantissent que ce logiciel n'aura jamais de défauts ou de vulnérabilités ; même les méthodes formelles peuvent échouer si les spécifications ou les hypothèses sont fausses. Il n'y a pas non plus de pratiques qui peuvent garantir qu'un projet permettra de maintenir une communauté de développement saine et qui fonctionne bien. Toutefois, suivre les meilleures pratiques peut contribuer à améliorer les résultats des projets. Par exemple, certaines pratiques permettent la revue par plusieurs personnes avant publication, ce qui peut aider à trouver des vulnérabilités techniques difficiles à trouver autrement et à renforcer la confiance et un désir d'interaction répétée entre les développeurs de différentes entreprises. Pour gagner un badge, tous les critères DOIT et NE DOIT PAS doivent être satisfaits, tous les critères DEVRAIT doivent être satisfaits OU non satisfaits avec justification, et tous les critères PROPOSÉ doivent être satisfaits OU non satisfaits (nous voulons au moins qu'ils soient considérés). Si vous voulez entrer un texte de justification pour un commentaire générique, au lieu d'une raison justifiant que la situation est acceptable, commencez le bloc de texte avec '//' suivi d'un espace. Les commentaires sont les bienvenus via le site GitHub en tant que problèmes ou pull requests. Il existe également une liste de diffusion pour discussion générale.

Nous fournissons volontiers l'information dans plusieurs langues, cependant, s'il existe un conflit ou une contradiction entre les traductions, la version anglaise est la version qui fait autorité.
Si c'est votre projet, veuillez indiquer votre statut de badge sur votre page de projet ! Le statut du badge ressemble à ceci : Le niveau de badge pour le projet 235 est in_progress Voici comment l'intégrer :
Vous pouvez afficher votre statut de badge en incorporant ceci dans votre fichier markdown :
[![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/235/badge)](https://bestpractices.coreinfrastructure.org/projects/235)
ou en incorporant ceci dans votre HTML :
<a href="https://bestpractices.coreinfrastructure.org/projects/235"><img src="https://bestpractices.coreinfrastructure.org/projects/235/badge"></a>


Ce sont les critères du niveau Basique. Vous pouvez également afficher les critères des niveaux Argent ou Or.



 Notions de base 12/12

  • Identification

    Notez que d'autres projets peuvent utiliser le même nom.

    FFmpeg is the leading multimedia framework, able to decode, encode, transcode, mux, demux, stream, filter and play pretty much anything that humans and machines have created. It supports the most obscure ancient formats up to the cutting edge. No matter if they were designed by some standards committee, the community or a corporation. It is also highly portable: FFmpeg compiles, runs, and passes our testing infrastructure [FATE](fate.ffmpeg.org) across Linux, Mac OS X, Microsoft Windows, the BSDs, Solaris, etc. under a wide variety of build environments, machine architectures, and configurations.

    It contains libavcodec, libavutil, libavformat, libavfilter, libavdevice, libswscale and libswresample which can be used by applications. As well as ffmpeg, ffserver, ffplay and ffprobe which can be used by end users for transcoding, streaming and playing.

    Quel(s) langage(s) de programmation sont utilisés pour implémenter le projet ?
    S'il y a plus d'un langage, listez-les en tant que valeurs séparées par des virgules (espaces facultatifs) et triez-les du plus au moins utilisé. S'il y a une longue liste, veuillez lister au moins les trois premiers. S'il n'y a pas de langage (par exemple, il s'agit d'un projet uniquement de documentation ou de test), utilisez le caractère unique « - ». Utilisez une capitalisation conventionnelle pour chaque langage, par exemple « JavaScript ».
    La plate-forme commune d'énumération (CPE) est un schéma de dénomination structuré pour les systèmes, les logiciels et les paquetages des technologies de l'information. Il est utilisé dans un certain nombre de systèmes et de bases de données pour signaler des vulnérabilités.
  • Contenu basique du site Web du projet


    Assez pour un badge !

    Le site du projet DOIT décrire succinctement ce que le logiciel fait (quel problème résout-il ?). [description_good]
    Cela DOIT être dans un langage que les utilisateurs potentiels peuvent comprendre (par exemple, il utilise un jargon minimal).

    Assez pour un badge !

    Le site Web du projet DOIT fournir des informations sur la façon d'obtenir, de fournir des commentaires (comme des signalements de bogues ou des demandes d'amélioration) et de contribuer au logiciel. [interact]

    Assez pour un badge !

    L'information sur la façon de contribuer DOIT expliquer le processus de contribution (par exemple, les pull requests sont-ils utilisés ?) (URL requise) [contribution]
    Nous supposons que les projets sur GitHub utilisent les problèmes et les pull requests, sauf indication contraire. Cette information peut être courte, par exemple, en indiquant que le projet utilise les pull requests, un suivi des problèmes ou des messages dans une liste de diffusion (laquelle ?)

    https://ffmpeg.org/developer.html

    The above URL gives complete information regarding the contribution process. As a short summary: although mirrored on GitHub at https://github.com/FFmpeg/FFmpeg, the project does not accept pull requests as explained in https://github.com/FFmpeg/FFmpeg/pull/153. We instead use a mailing list ffmpeg-devel@ffmpeg.org instead; exact details are provided in the developer documentation link at the top.



    Assez pour un badge !

    Les informations sur la façon de contribuer DEVRAIENT inclure les exigences pour des contributions acceptables (par exemple, une référence à toute norme de codage requise). (URL requise) [contribution_requirements]
  • Licence FLOSS

    Sous quelle(s) licence(s) le projet est-il distribué ?
    Utilisez un format d'expression de licence SPDX ; des exemples sont « Apache-2.0 », « BSD-2-Clause », « BSD-3-Clause », « GPL-2.0+ », « LGPL-3.0+ », « MIT » et « (BSD-2-Clause OU Ruby) ».



    Assez pour un badge !

    Le logiciel produit par le projet DOIT être distribué en tant que FLOSS. [floss_license]
    FLOSS est un logiciel distribué d'une manière qui répond à la Définition de l'Open Source ou à la Définition du Logiciel Libre. Des exemples de ces licences sont CC0, MIT, BSD 2-clause, BSD 3-clause révisée, Apache 2.0, Lesser GNU General Public License (LGPL), et GNU General Public License (GPL). Pour nos besoins, cela signifie que la licence DOIT être : Le logiciel PEUT également être distribué avec d'autres licences (par exemple, « GPLv2 ou propriétaire » est acceptable).

    https://ffmpeg.org/legal.html provides complete information regarding the licensing of FFmpeg.

    A short summary quoted from the above is:

    FFmpeg is licensed under the GNU Lesser General Public License (LGPL) version 2.1 or later. However, FFmpeg incorporates several optional parts and optimizations that are covered by the GNU General Public License (GPL) version 2 or later. If those parts get used the GPL applies to all of FFmpeg.

    Read the license texts to learn how this affects programs built on top of FFmpeg or reusing FFmpeg. You may also wish to have a look at the GPL FAQ.

    Note that FFmpeg is not available under any other licensing terms, especially not proprietary/commercial ones, not even in exchange for payment.



    Assez pour un badge !

    Il est PROPOSÉ que toute licence requise pour le logiciel produit par le projet soit approuvée par l'Open Source Initiative (OSI). [floss_license_osi]
    L'OSI utilise un processus d'approbation rigoureux pour déterminer quelles licences sont OSS.


    Assez pour un badge !

    Le projet DOIT afficher la ou les licences de ses résultats dans un emplacement standard dans leur dépôt source. (URL requise) [license_location]
    Par exemple, dans un fichier à la racine du dépôt appelé LICENSE ou COPYING. Les noms de fichiers de licence PEUVENT être suivis d'une extension telle que « .txt » ou « .md ». Notez que ce critère est requis uniquement pour le dépôt de sources. Vous n'avez PAS besoin d'inclure le fichier de licence lors de la génération d'un élément à partir du code source (tel qu'un exécutable, un paquet ou un conteneur). Par exemple, lors de la génération d'un paquet R pour le réseau d'archives complet R (CRAN), suivez la procédure standard CRAN : si la licence est une licence standard, utilisez la spécification de standard courte (pour éviter d'installer une autre copie du texte) et listez le fichier LICENSE dans un fichier d'exclusion tel que .Rbuildignore. De même, lors de la création d'un paquet Debian, vous pouvez mettre un lien dans le fichier de copyright vers le fichier de licence dans /usr/share/common-licenses, et exclure le fichier de licence du paquet créé (par exemple, en supprimant le fichier après avoir appelé dh_auto_install). Nous encourageons l'inclusion d'informations de licence lisibles automatiquement dans des formats générés lorsque cela est possible.
  • Documentation


    Assez pour un badge !

    Le projet DOIT fournir une documentation de base pour le logiciel produit par le projet. [documentation_basics]
    Cette documentation doit se trouver dans un certain format (comme le texte ou la vidéo) qui comprend : comment l'installer, comment le démarrer, comment l'utiliser (éventuellement avec un tutoriel à l'aide d'exemples) et comment l'utiliser en toute sécurité (par exemple, quoi faire et ne pas faire) si c'est un sujet approprié pour le logiciel. La documentation de sécurité n'a pas besoin d'être longue. Le projet PEUT utiliser des liens hypertextes vers du matériel hors projet en tant que documentation. Si le projet ne produit pas de logiciel, choisissez « non applicable » (N/A).

    The documentation for FFmpeg is built from: https://git.ffmpeg.org/gitweb/ffmpeg.git/tree/HEAD:/doc. The documentation for the FFmpeg website is built from: https://git.ffmpeg.org/ffmpeg-web.

    As such, the recommended starting point for exploring the docs is: https://ffmpeg.org/documentation.html.

    FFmpeg provides security information such as CVE numbers and commits addressing them at: https://ffmpeg.org/security.html.



    Assez pour un badge !

    Le projet DOIT fournir une documentation de référence qui décrit l'interface externe (entrée et sortie) du logiciel produit par le projet. [documentation_interface]
    La documentation d'une interface externe explique à un utilisateur final ou un développeur comment l'utiliser. Cela inclut son interface de programmation (API) si le logiciel en possède une. S'il s'agit d'une bibliothèque, documentez les principales classes / types et méthodes / fonctions pouvant être appelés. S'il s'agit d'une application Web, définissez son interface URL (souvent son interface REST). S'il s'agit d'une interface de ligne de commande, documentez les paramètres et les options qu'elle supporte. Dans de nombreux cas, il est préférable que la plupart de cette documentation soit générée automatiquement, de sorte que cette documentation reste synchronisée avec le logiciel au fur et à mesure qu'il change, mais cela n'est pas nécessaire. Le projet PEUT utiliser des liens hypertextes vers du matériel hors projet en tant que documentation. La documentation PEUT être générée automatiquement (quand c'est possible, c'est souvent la meilleure façon de le faire). La documentation d'une interface REST peut être générée à l'aide de Swagger / OpenAPI. La documentation de l'interface de code PEUT être générée à l'aide d'outils tels que JSDoc (JavaScript), ESDoc (JavaScript), pydoc (Python) et Doxygen (plusieurs). Le simple fait d'avoir des commentaires dans le code source n'est pas suffisant pour satisfaire ce critère ; il doit y avoir un moyen simple de voir l'information sans lire l'intégralité du code source. Si le projet ne produit pas de logiciel, choisissez « non applicable » (N/A).

    https://ffmpeg.org/documentation.html - the starting reference for documentation.

    For some community documentation, please see: https://trac.ffmpeg.org/wiki. For a short tutorial, please see: http://dranger.com/ffmpeg/. For a short book, please see: http://ffmpeg.tv/.


  • Autre


    Assez pour un badge !

    Les sites du projet (site Web, dépôt et URLs de téléchargement) DOIVENT supporter HTTPS en utilisant TLS. [sites_https]
    Cela nécessite que l'URL de la page d'accueil du projet et l'URL du dépôt sous contrôle de version commencent par « https: » et non « http: ». Vous pouvez obtenir des certificats gratuits de Let's Encrypt. Les projets PEUVENT implémenter ce critère en utilisant (par exemple) des pages GitHub, des pages GitLab ou des pages de projet SourceForge. Si vous utilisez des pages GitHub avec des domaines personnalisés, vous POUVEZ utiliser un réseau de distribution de contenu (CDN) comme proxy pour prendre en charge HTTPS, tel que décrit dans le post de blog « Secure and fast GitHub Pages with CloudFlare », pour satisfaire ce critère. Si vous autorisez HTTP, nous vous invitons instamment à rediriger le trafic HTTP vers HTTPS.

    Assez pour un badge !

    Le projet DOIT avoir un ou plusieurs mécanismes de discussion (y compris les changements et les problèmes proposés) qui peuvent être recherchés, permettent de désigner les messages et les sujets par une URL, permettent aux nouvelles personnes de participer à certaines des discussions et ne nécessitent pas d'installation côté client de logiciels propriétaires. [discussion]
    Parmi les exemples de mécanismes acceptables figurent les listes de diffusion archivées, les problèmes de GitHub et les discussions sur les pull requests, Bugzilla, Mantis et Trac. Les mécanismes de discussion asynchrones (comme IRC) sont acceptables s'ils répondent à ces critères ; assurez-vous qu'il existe un mécanisme d'archivage adressable par URL. Une solution propriétaire en JavaScript, tout en étant découragée, est autorisée.

    Assez pour un badge !

    Le projet DEVRAIT fournir de la documentation en anglais et être en mesure d'accepter les signalements de bogues et les commentaires sur le code en anglais. [english]
    L'anglais est actuellement la langue véhiculaire des technologies informatiques ; l'utilisation de l'anglais augmente le nombre de développeurs et de relecteurs potentiels dans le monde entier. Un projet peut répondre à ce critère même si la langue principale de ses principaux développeurs n'est pas l'anglais.

    As can be seen at https://ffmpeg.org/documentation.html, all FFmpeg documentation is in English.



(Avancé) Quels autres utilisateurs ont les droits supplémentaires pour modifier cette soumission de badge? Actuellement : []
La plupart des projets devraient ignorer ce champ. Les soumissions de badge des projets peuvent toujours être modifiées par le propriétaire de la soumission de badge (créateur), les administrateurs de BadgeApp et toute personne qui peut committer dans le dépôt GitHub (s'il est sur GitHub). Si vous souhaitez que quelqu'un d'autre puisse modifier cette soumission de badge et que vous ayez déjà des droits d'édition sur cette soumission de badge de projet, vous pouvez ajouter d'autres utilisateurs avec des droits d'édition. Entrez simplement « + » suivi d'une liste d'entiers d'identifiants utilisateur séparés par des virgules. Ces utilisateurs seront également autorisés à modifier cette soumission de projet. Si vous êtes le propriétaire de la soumission du badge ou un administrateur BadgeApp, vous pouvez supprimer des utilisateurs de cette liste en entrant « - » suivi d'une liste d'entiers d'identifiants utilisateur séparés par des virgules. Nous nous attendons normalement à ce qu'une seule personne édite une soumission de badge spécifique à la fois. Cette application utilise un verrouillage optimiste pour éviter de sauvegarder des données périmées si plusieurs utilisateurs essaient de modifier une soumission de badge simultanément. Si vous avez plusieurs éditeurs, nous vous recommandons d'enregistrer les données de votre soumission de badge de manière incrémentale et régulière (c'est une bonne pratique en général).



 Contrôle des modifications 9/9

  • Dépôt source public sous contrôle de version


    Assez pour un badge !

    Le projet DOIT avoir un dépôt source sous contrôle de version qui est publiquement lisible et possède une URL. [repo_public]
    L'URL PEUT être identique à l'URL du projet. Le projet PEUT utiliser des branches privées (non publiques) dans des cas spécifiques alors que la modification n'est pas diffusée publiquement (par exemple, pour la correction d'une vulnérabilité avant qu'elle ne soit révélée au public).

    Assez pour un badge !

    Le dépôt source du projet DOIT suivre les changements apportés, qui a effectué les changements et quand les changements ont été effectués. [repo_track]

    https://git.ffmpeg.org/ffmpeg.git - it uses Git, and as such keeps track of the revisions. Note that revisions may also be viewed at the FFmpeg cvslog archives: https://lists.ffmpeg.org/pipermail/ffmpeg-cvslog/. Remark: The name cvslog dates to when the project used CVS. Now, the project uses Git.



    Assez pour un badge !

    Pour permettre une analyse collaborative, le dépôt source du projet DOIT inclure des versions provisoires pour examen entre versions officielles ; Il NE DOIT PAS inclure que les dernières versions. [repo_interim]
    Les projets PEUVENT choisir d'omettre des versions intermédiaires spécifiques dans leurs dépôts source publics (par exemple, celles qui corrigent des vulnérabilités de sécurité non publiques spécifiques, ne peuvent jamais être rendues publiques ou incluent des éléments qui ne peuvent être légalement publiés et ne sont pas dans la version finale).

    FFmpeg's repository is public, so in addition to the release branches (e.g https://git.ffmpeg.org/gitweb/ffmpeg.git/shortlog/refs/heads/release/3.0), we have a branch for master (https://git.ffmpeg.org/gitweb/ffmpeg.git/shortlog/refs/heads/master). Developers also sometimes maintain their own private forks for work in progress, e.g https://github.com/gajjanag/FFmpeg).



    Assez pour un badge !

    Il est PROPOSÉ qu'un logiciel reconnu de contrôle de version distribué soit utilisé (par exemple, git) pour le dépôt source du projet. [repo_distributed]
    Git n'est pas spécifiquement requis et les projets peuvent utiliser un logiciel de contrôle de version centralisé (comme subversion) avec justification.

    Git is currently used, as reflected by https://git.ffmpeg.org/ffmpeg.git .


  • Numérotation unique de la version


    Assez pour un badge !

    Les résultats du projet DOIVENT avoir un identifiant de version unique pour chaque version destinée à être utilisée par les utilisateurs. [version_unique]
    Cela PEUT être satisfait de diverses façons, y compris les identifiants de commit (comme git commit id ou mercure changeset id) ou un numéro de version (y compris les numéros de version qui utilisent la version sémantique ou les systèmes basés sur la date comme YYYYMMDD).

    https://ffmpeg.org/developer.html#Release-process-1 - this describes the release process. In particular, major and minor version numbers are maintained for releases.



    À peine suffisant pour un badge.

    Il est PROPOSÉ que le format de Versionage Sémantique (SemVer) soit utilisé pour les numéros de versions. [version_semver]
    D'autres systèmes de numérotation de version, tels que les identifiants de commit (tels que git commit id ou mercurial changeset id) ou les systèmes basés sur la date comme YYYYMMDD, PEUVENT être utilisés comme numéros de version, car ils sont uniques. Certaines alternatives peuvent causer des problèmes, car les utilisateurs peuvent ne pas être en mesure de déterminer facilement s'ils sont à jour. SemVer peut être moins utile pour identifier les versions de logiciels si tous les destinataires n'exécutent que la dernière version (par exemple, c'est le code d'un seul site Web ou d'un service Internet qui est constamment mis à jour via une livraison continue).


    Assez pour un badge !

    Il est PROPOSÉ que les projets identifient chaque version dans leur système de contrôle de version. Par exemple, il est PROPOSÉ que ceux qui utilisent git identifient chaque version à l'aide des tags de git. [version_tags]
  • Notes de version


    Assez pour un badge !

    Le projet DOIT fournir, avec chaque distribution, des notes de version qui sont un résumé lisible par les humains des changements majeurs dans cette version afin d'aider les utilisateurs à déterminer s'ils doivent se mettre à niveau et quel sera l'impact de la mise à niveau. Les notes de version NE DOIVENT PAS être la sortie brute d'un journal de contrôle de version (par exemple, les résultats de la commande « git log » ne sont pas des notes de version). Les projets dont les résultats ne sont pas destinés à être réutilisés dans plusieurs emplacements (tels que le logiciel pour un site Web ou un service unique) ET qui utilisent la livraison continue PEUVENT sélectionner « N/A ». (URL requise) [release_notes]
    Les notes de version PEUVENT être mises en œuvre de différentes façons. De nombreux projets les fournissent dans un fichier nommé « NEWS », « CHANGELOG » ou « ChangeLog », éventuellement avec des extensions telles que « .txt », « .md » ou « .html ». Historiquement, le terme « journal des modifications » signifiait un enregistrement de chaque changement, mais pour répondre à ces critères, il faut un résumé lisible par un humain. Les notes de version PEUVENT être fournies à la place par des mécanismes de système de contrôle de version tels que le GitHub Releases workflow.

    https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/Changelog - this file keeps track of the release notes.



    Assez pour un badge !

    Les notes de version DOIVENT identifier toutes les vulnérabilités publiquement connues avec une affectation CVE ou similaire qui est résolue dans chaque nouvelle version, sauf si les utilisateurs ne peuvent pas en général mettre à jour le logiciel eux-mêmes. S'il n'y a pas de notes de version ou qu'il n'y a pas eu de vulnérabilité publiquement connue, choisissez « non applicable » (N/A). [release_notes_vulns]
    Si les utilisateurs ne peuvent généralement pas mettre à jour le logiciel eux-mêmes sur leur ordinateur, mais doivent plutôt dépendre d'un intermédiaire pour effectuer la mise à niveau (comme c'est souvent le cas pour un noyau et un logiciel de bas niveau associé à un noyau), le projet peut choisir "non applicable" (N/A)

    https://ffmpeg.org/security.html - FFmpeg associates public vulnerabilities with the release that fixes them here.


 Compte-rendu 8/8

  • Procédure de signalement des bogues


    Assez pour un badge !

    Le projet DOIT fournir un processus permettant aux utilisateurs de soumettre des signalements de bogue (par exemple, en utilisant un suivi des problèmes ou une liste de diffusion). (URL requise) [report_process]

    https://trac.ffmpeg.org/ - the bug tracker for FFmpeg.



    Assez pour un badge !

    Le projet DEVRAIT utiliser un suivi des problèmes pour le suivi des problèmes individuels. [report_tracker]

    https://trac.ffmpeg.org/ticket/5689 - an illustration of an individual ticket.



    Assez pour un badge !

    Le projet DOIT confirmer une majorité des signalements de bogues soumis au cours des 2 à 12 derniers mois (inclus) ; la réponse ne doit pas nécessairement inclure une correction. [report_responses]

    Assez pour un badge !

    Le projet DEVRAIT répondre à une majorité (>50%) des demandes d'amélioration au cours des 2 à 12 derniers mois (inclus). [enhancement_responses]
    La réponse PEUT être « non » ou une discussion sur ses mérites. Le but est simplement qu'il y ait une réponse à certaines demandes, ce qui indique que le projet est toujours en vie. Aux fins de ce critère, les projets ne doivent pas compter les fausses demandes (par exemple, provenant de spammeurs ou de systèmes automatisés). Si un projet ne fait plus d'améliorations, sélectionnez « non satisfait » et incluez l'URL qui rend cette situation claire pour les utilisateurs. Si un projet tend à être submergé par le nombre de demandes d'amélioration, sélectionnez « non satisfait » et expliquez.

    https://trac.ffmpeg.org/query?status=closed&status=new&status=open&desc=1&order=priority - as can be seen here, all incoming reports are classified into categories, and can be associated with the "enhancement" type or the "wish" priority.

    Also clear from the above links is that a significant fraction are implemented.



    Assez pour un badge !

    Le projet DOIT avoir une archive publique pour les signalements et les réponses pour une recherche ultérieure. (URL requise) [report_archive]

    https://trac.ffmpeg.org/report - this allows searching through the report database via a variety of queries.


  • Processus de signalement de vulnérabilité


    Assez pour un badge !

    Le projet DOIT publier le processus de signalement des vulnérabilités sur le site du projet. (URL requise) [vulnerability_report_process]
    Par exemple, une adresse postale clairement désignée sur https://PROJECTSITE/security, souvent sous la forme security@example.org. Cela PEUT être identique à son processus de signalement des bogues. Les signalements de vulnérabilités PEUVENT toujours être publics, mais de nombreux projets disposent d'un mécanisme privé de signalement des vulnérabilités.

    As seen at: https://ffmpeg.org/security.html, vulnerabilities are reported to ffmpeg-security@ffmpeg.org.



    Assez pour un badge !

    Si les signalements de vulnérabilités privés sont pris en charge, le projet DOIT inclure la façon d'envoyer l'information de manière confidentielle. (URL requise) [vulnerability_report_private]
    Des exemples incluent un signalement de défaut privé envoyé sur le Web en utilisant HTTPS (TLS) ou un courrier électronique chiffré à l'aide d'OpenPGP. Si les signalements de vulnérabilités sont toujours publics (donc il n'y a jamais de signalements de vulnérabilités privés), choisissez « non applicable » (N/A).

    As seen at: https://ffmpeg.org/security.html, vulnerabilities reported to ffmpeg-security@ffmpeg.org are private.



    Assez pour un badge !

    Le temps de réponse initial du projet pour tout signalement de vulnérabilité reçu au cours des 6 derniers mois DOIT être inférieur ou égal à 14 jours. [vulnerability_report_response]
    S'il n'y a pas eu de vulnérabilité signalée au cours des 6 derniers mois, choisissez « non applicable » (N/A).

    As can be seen at: https://ffmpeg.org/security.html, regular point releases are made to address security vulnerabilities. For further evidence of a regular response time, please see: https://security.googleblog.com/2014/01/ffmpeg-and-thousand-fixes.html.

    For more detailed statistics, please check the commit log - any commit addressing a CVE has the CVE number associated with it via the commit message.


 Qualité 12/13

  • Système de construction opérationnel


    Assez pour un badge !

    Si le logiciel produit par le projet nécessite d'être construit pour être utilisé, le projet DOIT fournir un système de construction fonctionnel qui peut reconstruire automatiquement le logiciel à partir du code source. [build]
    Un système de construction détermine quelles actions doivent se produire pour reconstruire le logiciel (et dans quel ordre), puis exécute ces étapes. Par exemple, il peut invoquer un compilateur pour compiler le code source. Si un exécutable est créé à partir du code source, il doit être possible de modifier le code source du projet, puis de générer un exécutable mis à jour avec ces modifications. Si le logiciel produit par le projet dépend de bibliothèques externes, le système de construction n'a pas besoin de construire ces bibliothèques externes. S'il n'est pas nécessaire de construire quoi que ce soit pour utiliser le logiciel après la modification de son code source, sélectionnez « non applicable » (N/A).

    FFmpeg can be built on a variety of platforms, including but not limited to Windows, GNU/Linux, OS X, BSD's, Solaris. Generally, it may be accomplished via ./configure, make, make install with a few flags, see https://trac.ffmpeg.org/wiki/CompilationGuide/Generic for details.



    À peine suffisant pour un badge.

    Il est PROPOSÉ d'utiliser des outils courants pour la construction du logiciel. [build_common_tools]
    Par exemple, Maven, Ant, cmake, autotools, make ou rake.

    FFmpeg uses make and the configure script is written in sh. The configure script relies on some standard utilities, like tr, grep, etc for testing the availability of components for building. A standard C compiler and linker are required, but FFmpeg does not restrict itself to a particular toolchain. For good performance, yasm is required for building assembly files, though this is not strictly needed as --disable-yasm is supported by configure.



    Assez pour un badge !

    Le projet DEVRAIT être constructible en utilisant uniquement des outils FLOSS. [build_floss_tools]

    FFmpeg builds fine with FLOSS tools, please see e.g fate.ffmpeg.org.


  • Suite de tests automatisée


    Assez pour un badge !

    Le projet DOIT utiliser au moins une suite de tests automatisée publiée publiquement comme FLOSS (cette suite de tests peut être maintenue sous la forme d'un projet FLOSS distinct). [test]
    Le projet PEUT utiliser plusieurs suites de tests automatisées (par exemple, une qui s'exécute rapidement, par rapport à une autre qui est plus approfondie, mais nécessite un équipement spécial).

    FFmpeg uses the FATE automated test suite: http://fate.ffmpeg.org/. The client side infrastructure is maintained within the FFmpeg repo. Server side is maintained at https://git.ffmpeg.org/fateserver. For details on how this works, please see https://ffmpeg.org/fate.html.



    Assez pour un badge !

    Une suite de tests DEVRAIT être invocable d'une manière standard pour ce langage. [test_invocation]
    Par exemple, « make check », « mvn test » ou « rake test ».

    As seen from https://ffmpeg.org/fate.html, invoking the FATE test suite is usually as simple as make fate. To obtain the test samples, make fate-rsync pulls samples from the https://samples.ffmpeg.org/ directory.



    Assez pour un badge !

    Il est PROPOSÉ que la suite de tests couvre la plupart (ou idéalement toutes) les branches du code, les champs de saisie et les fonctionnalités. [test_most]

    The code coverage is generally at a 66%-75% level. It is still being actively worked upon, with http://coverage.ffmpeg.org/ showing the current status.



    Assez pour un badge !

    Il est PROPOSÉ que le projet utilise une intégration continue (où le code nouveau ou modifié est fréquemment intégré dans un dépôt de code central et des tests automatisés sont exécutés sur le résultat). [test_continuous_integration]

    A number of FATE clients are run, as can be seen from fate.ffmpeg.org. Clients get added and removed, but at any given moment there are a reasonable variety of CPU architectures, operating systems, and toolchains represented at fate.ffmpeg.org.


  • Nouveau test de fonctionnalité


    Assez pour un badge !

    Le projet DOIT avoir une politique générale (formelle ou non) qui spécifie que, dès qu'une nouvelle fonctionnalité majeure est ajoutée au logiciel produit par le projet, des tests de cette fonctionnalité devraient être ajoutés à une suite de tests automatisée. [test_policy]
    Dès qu'une politique est en place, même par le bouche à oreille, qui spécifie que les développeurs devraient ajouter des tests à une suite de tests automatisée pour toute nouvelle fonctionnalité importante, sélectionnez « Atteint ».

    This is currently only an informal requirement, and generally is enforced only in libavcodec, where new encoders and decoders must be accompanied by tests.

    However, this is not uniformly enforced. Roughly, libavfilter tends to lack a lot of tests, and many new filters do not have tests associated with them immediately. It is the general expectation (informal) that tests will be added by the developer over time.



    Pas assez pour un badge.

    Le projet DOIT avoir la preuve que la politique de test pour l'ajout de tests a été respectée dans les dernières modifications majeures apportées au logiciel produit par le projet. [tests_are_added]
    Les principales fonctionnalités sont généralement mentionnées dans les notes de version. La perfection n'est pas nécessaire, il suffit de prouver que les tests sont généralement ajoutés en pratique à la suite de tests automatisée lorsque de nouvelles fonctionnalités majeures sont ajoutées au logiciel produit par le projet.

    Tests are lacking for all libraries except libavcodec.



    À peine suffisant pour un badge.

    Il est PROPOSÉ que cette politique sur l'ajout de tests (voir la politique de test) soit documentée dans les instructions pour les propositions de modification. [tests_documented_added]
    Cependant, même une règle informelle est acceptable tant que les tests sont ajoutés dans la pratique.

    As seen above, the adding of tests is currently quite informal. Documentation is present at https://ffmpeg.org/developer.html, but it is sometimes vague.


  • Options d'avertissement


    Assez pour un badge !

    Le projet DOIT activer une ou plusieurs options d'avertissement du compilateur, un mode du langage « sûr » ou utiliser un outil « linter » séparé pour rechercher des erreurs de qualité de code ou des erreurs simples courantes, s'il existe au moins un outil FLOSS qui peut implémenter ce critère dans le langage sélectionné. [warnings]
    Des exemples d'options d'avertissement du compilateur incluent « -Wall » pour gcc/clang. Des exemples d'un mode de langage « sûr » incluent « use strict » en JavaScript et « use warnings » de perl5. Un outil « linter » distinct est simplement un outil qui examine le code source pour rechercher des erreurs de qualité de code ou des erreurs simples courantes. Ceux-ci sont généralement activés par le code source ou par les instructions de construction.

    There are FATE clients running the ubsan toolchain, valgrind, etc. Generally speaking, -Wall and some other warnings are enabled by default for all compilations.



    Assez pour un badge !

    Le projet DOIT résoudre les avertissements. [warnings_fixed]
    Ce sont les avertissements identifiés par la mise en œuvre du critère warnings. Le projet doit corriger les avertissements ou les marquer dans le code source comme faux positifs. Idéalement, il n'y aurait pas d'avertissement, mais un projet PEUT accepter certains avertissements (généralement moins de 1 avertissement pour 100 lignes ou moins de 10 avertissements).

    There are numerous commits in the repository addressing warnings, and patches are regularly submitted and reviewed for the same.

    However, it must be noted that as FFmpeg supports a variety of toolchains, some of which omit bogus warnings, and that too sometimes only for specific versions of the toolchain, it is infeasible to reach a 0 warnings policy across all FATE clients. Generally, on "standard" toolchains, such as GNU/Linux OR OS X + gcc OR clang, the warning count does not exceed 100, and most warning cleanup work addresses such toolchains.



    À peine suffisant pour un badge.

    Il est PROPOSÉ que les projets soient maximalement stricts avec les avertissements dans le logiciel produit par le projet, quand cela est approprié. [warnings_strict]
    Certains avertissements ne peuvent être efficacement activés sur certains projets. Ce qui est nécessaire est la preuve que le projet s'efforce d'activer les options d'avertissements où il peut, de sorte que les erreurs soient détectées tôt.

    As noted above, as FFmpeg supports a variety of toolchains, some of which omit bogus warnings, and that too sometimes only for specific versions of the toolchain, it is infeasible to reach a 0 warnings policy across all FATE clients. Generally, on "standard" toolchains, such as GNU/Linux OR OS X + gcc OR clang, the warning count does not exceed 100, and most warning cleanup work addresses such toolchains.

    It is thus counterproductive to enforce a maximal strictness policy wrt warnings in FFmpeg. However, it should be noted that some developers experiment with additional warning combinations, and when the warnings stop being too noisy, the project is open to introducing these flags into the default set of warning flags.


 Sécurité 16/16

  • Connaissance du développement sécurisé


    Assez pour un badge !

    Le projet DOIT avoir au moins un développeur principal qui sait comment concevoir un logiciel sécurisé. [know_secure_design]
    Cela nécessite de comprendre les principes de conception suivants, y compris les 8 principes de Saltzer et Schroeder :
    • économie de moyens (maintenez la conception aussi simple et petite que pratique, par exemple en adoptant des simplifications conséquentes)
    • valeurs sûres par défaut (les décisions d'accès par défaut devraient être de refuser l'accès et l'installation des projets devrait être sécurisée par défaut)
    • médiation complète (tous les accès qui pourraient être limités doivent être vérifiés pour l'autorité et ne pas être contournables)
    • conception ouverte (les mécanismes de sécurité ne doivent pas dépendre de l'ignorance par l'attaquant de sa conception, mais plutôt d'informations plus facilement protégées et modifiées comme des clés et des mots de passe)
    • séparation des privilèges (idéalement, l'accès aux objets importants devrait dépendre de plus d'une condition, de sorte que la défaillance d'un système de protection n'autorisera pas l'accès complet. Par exemple, l'authentification multi-facteurs, comme l'exigence d'un mot de passe et d'un jeton matériel, est plus forte qu'une authentification à un seul facteur)
    • principe de plus faible privilège (les processus doivent fonctionner avec le minimum de privilège requis)
    • mécanisme de partage minimal (la conception devrait minimiser les mécanismes communs à plus d'un utilisateur et nécessaires à tous les utilisateurs, par exemple, les répertoires pour les fichiers temporaires)
    • acceptabilité psychologique (l'interface humaine doit être conçue pour faciliter l'utilisation - la conception pour « l'étonnement minimal » peut aider)
    • surface d'attaque limitée (la surface d'attaque - l'ensemble des différents points où un attaquant peut essayer d'entrer ou d'extraire des données - devrait être limitée)
    • validation d'entrée avec des listes blanches (les entrées devraient généralement être vérifiées pour déterminer si elles sont valides avant qu'elles ne soient acceptées ; cette validation devrait utiliser des listes blanches (qui n'acceptent que des bonnes valeurs connues), et non des listes noires (qui tentent de répertorier les valeurs mauvaises connues)).
    Un « développeur principal » dans un projet est celui qui connaît la base de code du projet, est à l'aise pour faire des modifications et est reconnu comme tel par la plupart des autres participants au projet. Un développeur principal a effectué généralement un certain nombre de contributions au cours de l'année écoulée (du code, de la documentation ou des réponses aux questions). Des développeurs sont généralement considérés comme des développeurs principaux s'ils ont lancé le projet (et n'ont pas quitté le projet il y a plus de trois ans), ont la possibilité de recevoir des informations sur un canal privé de déclaration de vulnérabilités (s'il y en a un), peuvent accepter des contributions au nom du projet, ou effectuer les distributions finales du logiciel du projet. S'il n'y a qu'un seul développeur, cette personne est le développeur principal.

    Nicholas George and Michael Niedermayer (among possibly others) are developers who understand the above principles and actively use them. Michael Niedermayer is perhaps the only currently active developer who meets all of the above criteria.



    Assez pour un badge !

    Au moins l'un des principaux développeurs du projet DOIT connaître les types courants d'erreurs qui conduisent à des vulnérabilités dans ce genre de logiciel, ainsi qu'au moins une méthode pour contrer ou atténuer chacun d'eux. [know_common_errors]
    Des exemples (selon le type de logiciel) incluent l'injection SQL, l'injection OS, le débordement mémoire classique, le cross-site scripting, l'authentification manquante et l'autorisation manquante. Voir CWE/SANS top 25 ou OWASP Top 10 pour les listes couramment utilisées.

    FFmpeg uses Coverity (https://scan.coverity.com/), a number of FATE clients use aids like ubsan, Valgrind, Helgrind, etc.

    FFmpeg does address the issue of creating more secure defaults, defensive programming practices, etc from time to time.


  • Utiliser de bonnes pratiques de base de cryptographie

    Notez que certains logiciels n'ont pas besoin d'utiliser des mécanismes cryptographiques.

    Assez pour un badge !

    Le logiciel produit par le projet DOIT utiliser, par défaut, uniquement les protocoles cryptographiques et les algorithmes publiés publiquement et revus par des experts (si des protocoles et algorithmes cryptographiques sont utilisés). [crypto_published]
    Ces critères cryptographiques ne s'appliquent pas toujours car certains logiciels n'ont pas besoin d'utiliser directement de capacités cryptographiques.

    As seen from files like aes.c, blowfish.c, etc in libavutil/, FFmpeg only uses publicly known cryptographic algorithms by default.



    À peine suffisant pour un badge.

    Si le logiciel produit par le projet est une application ou une bibliothèque, et si son objectif principal n'est pas d'implémenter de la cryptographie, alors il DEVRAIT simplement appeler un logiciel spécialement conçu pour implémenter des fonctions cryptographiques ; il ne DEVRAIT PAS ré-implémenter les siennes. [crypto_call]

    FFmpeg reimplements common cryptographic primitives like AES, Blowfish, SHA, etc in files within FFmpeg. Many of them are simply used to meet a multimedia specification, and in many cases it is not security relevant. As FFmpeg is a very widely used library deployed in a variety of configurations, it is desired to have as few external dependencies as possible.



    Assez pour un badge !

    Toutes les fonctionnalités du logiciel produit par le projet qui dépendent de la cryptographie DOIVENT être réalisables à l'aide de FLOSS. [crypto_floss]

    This may be seen by examining the source code.



    Assez pour un badge !

    Les mécanismes de sécurité dans le logiciel produit par le projet DOIVENT utiliser des longueurs de clés par défaut qui satisfont au moins aux exigences minimales du NIST jusqu'à l'année 2030 (comme indiqué en 2012). Il DOIT être possible de configurer le logiciel afin que les plus petites longueurs de clés soient complètement désactivées. [crypto_keylength]
    Ces longueurs de bit minimales sont : pour une clé symétrique 112, pour un modulo de factorisation 2048, pour une clé de logarithme discret 224, pour un groupe du logarithmique discret 2048, pour une courbe elliptique 224 et pour un hachage 224 (le hachage de mot de passe n'est pas couvert par cette longueur de bit, plus d'informations sur le hachage de mot de passe peuvent être trouvées dans le critère crypto_password_storage). Voir http://www.keylength.com pour une comparaison des recommandations sur les longueurs de clés de diverses organisations. Le logiciel PEUT permettre de plus petites longueurs de clés dans certaines configurations (idéalement non, car cela permet des attaques de dégradation, mais des longueurs de clés plus courtes sont parfois nécessaires pour l'interopérabilité).

    Although FFmpeg does provide a low level DES API, it is used strictly for format interoperability and is thus not part of any security mechanism.



    Assez pour un badge !

    Les mécanismes de sécurité par défaut dans le logiciel produit par le projet NE DOIVENT PAS dépendre d'algorithmes cryptographiques cassés (par exemple, MD4, MD5, DES unique, RC4, Dual_EC_DRBG) ou utiliser des modes de chiffrement inappropriés dans le contexte, sauf si ils sont nécessaires pour implémenter un protocole d'interopérabilité (où le protocole implémenté est la version la plus récente du standard supporté largement par l'écosystème du réseau, l'écosystème requière l'utilisation de cet algorithme ou mode, et cet écosystème n'offre pas d'alternative plus sûre). La documentation DOIT décrire tous les risques de sécurité appropriés et les parades connues si ces algorithmes ou modes cassés sont nécessaires pour un protocole d'interopérabilité. [crypto_working]
    Le mode ECB n'est presque jamais approprié car il révèle des blocs identiques dans le texte chiffré, comme le montre le pingouin ECB, et le mode CTR est souvent inapproprié car il n'effectue pas d'authentification et provoque des doublons si l'état d'entrée est dupliqué. Dans de nombreux cas, il est préférable de choisir un mode d'algorithme de chiffrement de bloc conçu pour combiner le secret et l'authentification, par exemple Galois/Counter Mode (GCM) et EAX. Les projets PEUVENT permettre aux utilisateurs d'activer les mécanismes cassés (par exemple pendant la configuration) si nécessaire pour la compatibilité, mais les utilisateurs savent alors qu'ils le font.

    FFmpeg does implement and export a number of low level cryptographic primitives, some of which are broken such as MD5 and single DES. However, it should be noted that the usage of these primitives within FFmpeg are confined to instances where it is necessary in order to meet some specification.



    Assez pour un badge !

    Les mécanismes de sécurité par défaut dans le logiciel produit par le projet NE DEVRAIENT PAS dépendre d'algorithmes ou de modes cryptographiques avec des faiblesses sérieuses connues (par exemple, l'algorithme de hachage cryptographique SHA-1 ou le mode CBC en SSH). [crypto_weaknesses]
    Les préoccupations concernant le mode CBC en SSH sont discutées dans CERT : vulnérabilité SSH CBC.

    Same remarks as above. In particular, SHA-1 is used for creating identifiers, and is not used for a security purpose.



    Assez pour un badge !

    Les mécanismes de sécurité dans le logiciel produit par le projet DEVRAIENT implémenter la confidentialité persistante pour les protocoles d'échange de clés afin qu'une clé de session dérivée d'un ensemble de clés à long terme ne soit pas compromise si l'une des clés à long terme est compromise dans le futur. [crypto_pfs]


    Assez pour un badge !

    Si le logiciel produit par le projet entraîne la sauvegarde de mots de passe pour l'authentification d'utilisateurs externes, les mots de passe DOIVENT être sauvegardés comme hachages itérés avec un salage par utilisateur en utilisant un algorithme d'étirement de clé (itéré) (par exemple PBKDF2, Bcrypt ou Scrypt). [crypto_password_storage]
    Ce critère s'applique uniquement lorsque le logiciel applique l'authentification des utilisateurs utilisant des mots de passe, telles que des applications Web côté serveur. Il ne s'applique pas dans les cas où le logiciel sauvegarde des mots de passe pour l'authentification dans d'autres systèmes (par exemple, le logiciel implémente un client pour un autre système), car au moins certaines parties de ce logiciel doivent avoir souvent accès au mot de passe en clair.

    FFmpeg does not store passwords for authentication of external users.



    Assez pour un badge !

    Les mécanismes de sécurité dans le logiciel produit par le projet DOIVENT générer toutes les clés cryptographiques et les nonces en utilisant un générateur de nombres aléatoires cryptographiquement sécurisé, et NE DOIVENT PAS le faire en utilisant des générateurs qui ne seraient pas cryptographiquement sécurisés. [crypto_random]
    Un générateur de nombres aléatoires cryptographiquement sécurisé peut être un générateur de nombres aléatoires matériel ou un générateur de nombres pseudo-aléatoires cryptographiquement sécurisé (CSPRNG) utilisant un algorithme tel que Hash_DRBG, HMAC_DRBG, CTR_DRBG, Yarrow ou Fortuna. Des exemples d'appels de générateurs de nombres aléatoires sûrs incluent java.security.SecureRandom en Java et window.crypto.getRandomValues ​​de JavaScript. Des exemples d'appels de générateurs de nombres aléatoires non sûrs incluent java.util.Random en Java et Math.random en JavaScript.

    As can be seen from https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/libavutil/random_seed.c, FFmpeg makes a best effort at providing a cryptographically secure random number generator.


  • Livraison sécurisée contre les attaques man-in-the-middle (MITM)


    Assez pour un badge !

    Le projet DOIT utiliser un mécanisme de livraison qui contrecarre les attaques MITM. L'utilisation de https ou ssh+scp est acceptable. [delivery_mitm]
    Un mécanisme encore plus fort distribue le logiciel sous forme de paquetages signés numériquement, car cela atténue les attaques sur le système de distribution, mais cela ne fonctionne que si les utilisateurs peuvent être convaincus que les clés publiques pour les signatures sont correctes et si les utilisateurs vérifient la signature.

    PGP signatures are provided: https://ffmpeg.org/download.html#releases. The download is over https.



    Assez pour un badge !

    Un hachage cryptographique (par exemple, un sha1sum) NE DOIT PAS être récupéré par http et utilisé sans vérifier une signature cryptographique. [delivery_unsigned]
    Ces hachages peuvent être modifiés en transit.

    PGP signatures are provided: https://ffmpeg.org/download.html#releases. The download is over https.


  • Vulnérabilités publiquement identifiées et corrigées


    Assez pour un badge !

    Il NE DOIT PAS y avoir de vulnérabilités non corrigées de gravité moyenne ou élevée connues publiquement depuis plus de 60 jours. [vulnerabilities_fixed_60_days]
    La vulnérabilité doit être corrigée et diffusée par le projet lui-même (les correctifs peuvent être développés ailleurs). Une vulnérabilité devient publique (à cet effet) une fois qu'il a un CVE avec des informations non payantes publiquement publiées (signalé, par exemple, dans la Base de données Nationale des Vulnérabilités) ou lorsque le projet a été informé et que l'information a été diffusée au public (éventuellement par le projet). Une vulnérabilité est de gravité moyenne à élevée si son score de base CVSS 2.0 est 4 ou supérieur. Note : cela signifie que les utilisateurs peuvent être laissés vulnérables à tous les attaquants du monde entier jusqu'à 60 jours. Ce critère est souvent beaucoup plus facile à atteindre que ce que Google recommande dans son Redémarrage de la divulgation responsable, car Google recommande que la période de 60 jours commence lorsque le projet est notifié même si le rapport n'est pas public. Notez que ce critère de badge, comme d'autres critères, s'applique à un projet individuel. Certains projets font parti d'organisations ou de projets englobants, parfois à plusieurs niveaux, et de nombreux projets fournissent leurs résultats à d'autres organisations et projets au sein d'une chaîne approvisionnement potentiellement complexe. Un projet individuel ne peut souvent pas contrôler le reste, mais un projet individuel peut travailler à fournir un correctif de vulnérabilité à temps. Pour cette raison, nous nous concentrons seulement sur le temps de réponse des projets individuels. Une fois qu'un correctif est disponible de la part d'un projet individuel, les autres projets peuvent déterminer comment appliquer le correctif (par exemple, ils peuvent mettre à jour la dernière version ou ils peuvent appliquer uniquement le correctif).

    FFmpeg fixes public vulnerabilities much more quickly than this. Please see the commit logs for evidence of this.



    Assez pour un badge !

    Les projets DEVRAIENT corriger rapidement toutes les vulnérabilités critiques après leur signalement. [vulnerabilities_critical_fixed]

    FFmpeg has a track record of fixing CVE's promptly. Some evidence for this: 1. https://ffmpeg.org/security.html 2. Commit logs - all CVE related commits have the CVE number included in the message 3. https://security.googleblog.com/2014/01/ffmpeg-and-thousand-fixes.html.


  • Autres problèmes de sécurité


    Assez pour un badge !

    Les dépôts publics NE DOIVENT PAS fuiter un certificat privé valide (par exemple, un mot de passe ou une clé privée) qui est destiné à limiter l'accès public. [no_leaked_credentials]
    Un projet PEUT fuiter des « échantillons » de certificats pour les tests et pour des bases de données sans importance, pour autant qu'ils ne soient pas destinés à limiter l'accès public.

 Analyse 8/8

  • Analyse statique de code


    Assez pour un badge !

    Au moins un outil d'analyse statique de code (au-delà des avertissements du compilateur et des modes « sûrs » des languages) DOIT être appliqué à toute distribution majeure proposée avant sa sortie s'il existe au moins un outil FLOSS qui implémente ce critère dans le langage sélectionné. [static_analysis]
    Un outil d'analyse statique de code examine le code logiciel (au niveau du code source, du code intermédiaire ou de l'exécutable) sans l'exécuter avec des entrées spécifiques. Aux fins de ce critère, les avertissements du compilateur et les modes de langage « sûrs » ne comptent pas comme des outils d'analyse statique de code (ceux-ci évitent généralement une analyse approfondie car la rapidité est vitale). Des exemples de ces outils d'analyse statique de code incluent cppcheck, clang static analyzer, FindBugs (y compris FindSecurityBugs), PMD, Brakeman, Coverity Quality Analyzer, SonarQube, Codacy et HP Enterprise Fortify Static Code Analyzer. Des listes plus vastes d'outils peuvent être trouvées dans des endroits tels que la liste Wikipedia d'outils pour l'analyse statique de code, l'information OWASP sur l'analyse statique de code, la liste NIST des analyseurs de sécurité du code source et la liste des outils d'analyse statique de Wheeler. SWAMP est une plate-forme gratuite pour évaluer les vulnérabilités dans les logiciels utilisant une variété d'outils. S'il n'y a pas d'outil d'analyse statique FLOSS disponible pour le(s) langage(s) d'implémentation utilisés, sélectionnez « N/A ».

    FFmpeg uses Coverity (scan.coverity.com) before production releases, which checks for a variety of common C programming mistakes. It should be noted that Coverity is not perfect, and there are false positives which is why FFmpeg does not necessarily "clear" the list before release. Nevertheless, an effort is made to fix Coverity reports before release.



    Assez pour un badge !

    Il est PROPOSÉ qu'au moins l'un des outils d'analyse statique utilisés pour le critère d'analyse statique inclue des règles ou des approches pour rechercher des vulnérabilités courantes dans le langage ou l'environnement analysé. [static_analysis_common_vulnerabilities]
    Les outils d'analyse statique spécialement conçus pour détecter les vulnérabilités les plus courantes sont plus susceptibles de les détecter. Cela dit, l'utilisation d'outils statiques aidera généralement à trouver des problèmes, nous suggérons donc, sans l'exiger, de le faire pour le badge de niveau « passant ».

    FFmpeg uses Coverity (scan.coverity.com), which checks for a variety of common C programming mistakes.



    Assez pour un badge !

    Toutes les vulnérabilités exploitables de gravité moyenne et élevée découvertes avec une analyse statique de code DOIVENT être corrigées en temps approprié après leur confirmation. [static_analysis_fixed]
    Une vulnérabilité est de gravité moyenne à élevée si son CVSS 2.0 est 4 ou supérieur.

    FFmpeg fixes exploitable vulnerabilities promptly, regardless of whether they are found via static analysis (e.g privately via Coverity) or made public.



    À peine suffisant pour un badge.

    Il est PROPOSÉ que l'analyse statique du code source se produise à chaque commit ou au moins quotidiennement. [static_analysis_often]

  • Analyse dynamique de code


    À peine suffisant pour un badge.

    Il est PROPOSÉ qu'au moins un outil d'analyse dynamique soit appliqué à tout candidat pour une version majeure du logiciel avant sa distribution. [dynamic_analysis]
    Un outil d'analyse dynamique examine le logiciel en l'exécutant avec des entrées spécifiques. Par exemple, le projet PEUT utiliser un outil de fuzzing (par exemple, American Fuzzy Lop) ou un scanner d'application Web (par exemple, OWASP ZAP ou w3af). Dans certains cas, le projet OSS-Fuzz peut être prêt à appliquer des tests de fuzzing à votre projet. Aux fins de ce critère, l'outil d'analyse dynamique doit varier les entrées d'une manière ou d'une autre pour rechercher différents types de problèmes ou être une suite de test automatisée avec au moins 80% de couverture de branche. La page Wikipedia sur l'analyse dynamique et la page OWASP sur le fuzzing identifient certains outils d'analyse dynamique. Le ou les outils d'analyse PEUVENT être axés sur la recherche de vulnérabilités de sécurité, mais cela n'est pas nécessaire.


    Assez pour un badge !

    Il est PROPOSÉ que, si le logiciel produit par le projet comprend un logiciel écrit à l'aide d'un langage non sûr pour les accès mémoire (par exemple, C ou C ++), au moins un outil dynamique (par exemple, un fuzzer ou un scanner d'application Web) soit utilisé de façon routinière en combinaison avec un mécanisme pour détecter des problèmes de sécurité mémoire tels que les dépassements de zone mémoire. Si le projet ne produit pas de logiciel écrit dans un langage non sûr pour les accès mémoire, choisissez « non applicable » (N/A). [dynamic_analysis_unsafe]
    Des exemples de mécanismes pour détecter les problèmes de sécurité de la mémoire comprennent Address Sanitizer (ASAN) (disponible dans GCC et LLVM), Memory Sanitizer et valgrind. D'autres outils potentiellement utilisés incluent thread sanitizer et undefined behavior sanitizer. La généralisation de l'utilisation des assertions fonctionnera également.

    Fuzzing is certainly performed quite regularly on FFmpeg: https://security.googleblog.com/2014/01/ffmpeg-and-thousand-fixes.html, http://obe.tv/about-us/obe-blog/item/26-fuzzing-ffmpeg-for-fun-and-profit. Note that this is being done by third parties.



    Assez pour un badge !

    Il est PROPOSÉ que le logiciel produit par le projet comprenne de nombreuses assertions à l'exécution qui sont vérifiées lors d'une analyse dynamique. [dynamic_analysis_enable_assertions]

    FFmpeg uses assertions at various locations in the code (https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/libavutil/random_seed.c).



    Assez pour un badge !

    Toutes les vulnérabilités exploitables de gravité moyenne et élevée découvertes avec une analyse de code dynamique DOIVENT être corrigées en un temps approprié après leur confirmation. [dynamic_analysis_fixed]
    Une vulnérabilité est de gravité moyenne à élevée si son score de base CVSS 2.0 est 4. Si vous n'utilisez pas d'analyse de code dynamique et donc n'avez trouvé aucune vulnérabilité de cette façon, choisissez « non applicable » (N/A).

    FFmpeg does tend to fix vulnerabilities discovered via dynamic code analysis in a timely fashion: https://security.googleblog.com/2014/01/ffmpeg-and-thousand-fixes.html, http://obe.tv/about-us/obe-blog/item/26-fuzzing-ffmpeg-for-fun-and-profit. Note that is being done by third parties.



Ces données sont disponibles sous licence Creative Commons Attribution version 3.0 (CC-BY-3.0) comme indiqué dans les conditions d'utilisation de la Core Infrastructure Initiative. Chacun peut librement partager et adapter les données, à condition de créditer leur origine. Veuillez créditer Ganesh Ajjanagadde et les contributeurs du badge des meilleures pratiques de la CII.

Soumission du badge du projet appartenant à : Ganesh Ajjanagadde.
Soumission créée le 2016-07-04 19:43:22 UTC, dernière mise à jour le 2016-07-17 01:18:29 UTC.

Retour