HiveDAV

Les projets qui suivent les meilleures pratiques ci-dessous peuvent s'auto-certifier et montrer qu'ils ont obtenu le badge de la Open Source Security Foundation (OpenSSF).

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 afficher votre statut de badge de référence sur la page de votre projet ! Le statut du badge de référence ressemble à ceci :

Voici comment intégrer le badge de référence :

Vous pouvez afficher votre statut de badge de référence en incorporant ceci dans votre fichier markdown :

[![OpenSSF Baseline](https://www.bestpractices.dev/projects/14270/baseline)](https://www.bestpractices.dev/projects/14270)

ou en incorporant ceci dans votre HTML :

<a href="https://www.bestpractices.dev/projects/14270"><img src="https://www.bestpractices.dev/projects/14270/baseline"></a>

Voici les critères du niveau de référence 1. Il s'agit des critères version v2026.08.28.

Baseline Series: Niveau de référence 1 Niveau de référence 2 Niveau de référence 3

Notions de base

Général

Quel est le nom intelligible du projet ?
Notez que d'autres projets peuvent utiliser le même nom.

Pouvez-vous donner une brève description du projet ?

A curlable free/busy scheduler with CalDAV integration.

Quelle est l'URL du projet (dans son ensemble) ?
https://hivedav.p0c.ch

Quelle est l'URL du dépôt sous contrôle de version (qui peut être la même que l'URL du projet) ?
https://code.in0rdr.ch/hivedav

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) ». Ne pas inclure des guillemets simples ou doubles.

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

Quel est le nom de plate-forme commune d'énumération (CPE) pour le projet (s'il en a un) ?
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.

Autres commentaires généraux sur le projet :

A development instance and reference scheduler is hosted on https://meet.in0rdr.ch, try "curl meet.in0rdr.ch".

Contrôles 24/24 ●

Contrôles

Criterion [OSPS-AC-01.01]
Atteint

Non atteint

N/A

?

Lorsqu'un utilisateur tente de lire ou de modifier une ressource sensible dans le dépôt faisant autorité du projet, le système DOIT exiger que l'utilisateur termine un processus d'authentification multi-facteurs. ^{[OSPS-AC-01.01]}
Imposer l'authentification multi-facteurs pour le système de contrôle de version du projet, exigeant des collaborateurs qu'ils fournissent une seconde forme d'authentification lors de l'accès aux données sensibles ou de la modification des paramètres du dépôt. Les passkeys sont acceptables pour ce contrôle.

The Git repository allows pull-requests with picosh (https://pr.in0rdr.ch/repos/hivedav). No authentication required (except the identification with SSH pubkey, to attribute the patches to the user).

It's a "pastebin for patches" (from the community), which are then applied by the maintainer(s) using SSH credentials. There is no MFA on the SSH keys registered with the Git server (https://git.in0rdr.ch/hivedav.git), which is simply "Git on the server".

The "Stagit Web Interface" (https://code.in0rdr.ch/nomad/file/hcl/default/git/README.md.html) does not allow to do changes, it's a read-only & public interface.
Criterion [OSPS-AC-02.01]
Atteint

Non atteint

N/A

?

Lorsqu'un nouveau collaborateur est ajouté, le système de contrôle de version DOIT exiger une attribution manuelle de permissions, ou restreindre les permissions du collaborateur aux privilèges disponibles les plus bas par défaut. ^{[OSPS-AC-02.01]}
La plupart des systèmes de contrôle de version publics sont configurés de cette manière. Assurez-vous que le système de contrôle de version du projet attribue toujours les permissions les plus basses disponibles aux collaborateurs par défaut lorsqu'ils sont ajoutés, accordant des permissions supplémentaires uniquement lorsque cela est nécessaire.
Git push permissions on the repository are constrained by htpasswd (Smart HTTP, see https://git-scm.com/book/en/v2/Git-on-the-Server-Smart-HTTP).
- https://code.in0rdr.ch/nomad/file/hcl/default/git/README.md.html
Collaborators can contribute patch sets through https://pr.in0rdr.ch/repos/hivedav.

Collaborators on pr.in0rdr.ch are not added specifically. Any user with SSH public key is allowed to contribute code (patches).
Criterion [OSPS-AC-03.01]
Atteint

Non atteint

N/A

?

Lorsqu'un commit direct est tenté sur la branche principale du projet, un mécanisme d'application DOIT empêcher la modification d'être appliquée. ^{[OSPS-AC-03.01]}
Si le VCS est centralisé, définissez une protection de branche sur la branche principale dans le VCS du projet. Alternativement, utilisez une approche décentralisée, comme celle du noyau Linux, où les modifications sont d'abord proposées dans un autre dépôt, et la fusion des modifications dans le dépôt principal nécessite un acte distinct spécifique.
Direct commits happen frequently on the master branch. This branch is the development branch.

Patches from contributors (https://pr.in0rdr.ch/repos/hivedav) are merged into the master branch or patched in the master branch directly (w/o merge branch).

Tags on the master branch are used to reference stable releases:
- https://code.in0rdr.ch/hivedav/refs.html
Criterion [OSPS-AC-03.02]
Atteint

Non atteint

N/A

?

Lorsqu'une tentative est faite de supprimer la branche principale du projet, le système de contrôle de version DOIT traiter cela comme une activité sensible et exiger une confirmation explicite de l'intention. ^{[OSPS-AC-03.02]}
Définissez une protection de branche sur la branche principale dans le système de contrôle de version du projet pour empêcher la suppression.

The action "delete Git branch" is protected by the SSH keys. Only maintainers with the appropriate SSH keys on the Git server can (https://git-scm.com/book/en/v2/Git-on-the-Server-Smart-HTTP) delete the "primary branch" (called "master" in our project).

Criterion [OSPS-BR-01.01]
Atteint

Non atteint

N/A

?

Lorsqu'un pipeline CI/CD fonctionne sur des métadonnées non fiables, ces paramètres DOIVENT être nettoyés et validés avant d'être utilisés dans le pipeline. ^{[OSPS-BR-01.01]}
Les pipelines CI/CD doivent assainir (mettre entre guillemets, échapper ou quitter pour les valeurs attendues) toutes les entrées de métadonnées correspondant à des sources non fiables. Cela inclut des données telles que les noms de branches, les messages de commit, les tags, les titres des pull requests et les informations sur l'auteur.

The Jenkins pipeline uses the GIT_COMMIT metadata to create container builds with Buildah (https://code.in0rdr.ch/hivedav/file/Jenkinsfile.html).

We assume the Jenkins generic SCM step (https://plugins.jenkins.io/workflow-scm-step/#plugin-content-generic-scm-step) provides us with the sanitized metadata.

Criterion [OSPS-BR-01.03]
Atteint

Non atteint

N/A

?

Lorsqu'un pipeline CI/CD opère sur des instantanés de code non fiables, il DOIT empêcher l'accès aux identifiants et aux ressources privilégiés du CI/CD. ^{[OSPS-BR-01.03]}
Les pipelines CI/CD doivent isoler les instantanés de code non fiables des identifiants et des ressources privilégiés. En particulier, les projets doivent veiller à ce que les workflows qui compilent ou exécutent du code avant examen par un collaborateur n'aient pas accès aux identifiants CI/CD.

CICD credentials in Jenkins for fetching the latest code from Git are protected with OpenBao (https://code.in0rdr.ch/hivedav/file/Jenkinsfile.html).

See also https://plugins.jenkins.io/hashicorp-vault-plugin.

Criterion [OSPS-BR-03.01]
Atteint

Non atteint

N/A

?

Lorsque le projet liste un URI comme canal officiel du projet, cet URI DOIT être exclusivement fourni en utilisant des canaux chiffrés. ^{[OSPS-BR-03.01]}
Configurez les sites Web et les systèmes de contrôle de version du projet pour utiliser des canaux chiffrés tels que SSH ou HTTPS pour la transmission de données. Assurez-vous que tous les outils et domaines référencés dans la documentation du projet ne peuvent être accessibles que via des canaux chiffrés.

Project URLs use HTTPS exclusively.

Criterion [OSPS-BR-03.02]
Atteint

Non atteint

N/A

?

Lorsque le projet répertorie une URI comme canal de distribution officiel, ce canal DOIT être protégé contre les attaques de l'adversaire au milieu (adversary-in-the-middle) à l'aide de canaux authentifiés cryptographiquement. ^{[OSPS-BR-03.02]}
Les artefacts distribués par le projet devraient être distribués par des canaux qui garantissent l'intégrité et l'authenticité. L'utilisation de HTTPS pour les téléchargements, de versions signées ou de la distribution via des gestionnaires de paquets fiables sont toutes des méthodes acceptables pour se protéger contre les attaques de l'adversaire au milieu.

Distribution channels use HTTPS exclusively.
Criterion [OSPS-BR-07.01]
Atteint

Non atteint

N/A

?

Le projet DOIT empêcher le stockage involontaire de données sensibles non chiffrées, telles que des secrets et des informations d'identification, dans le système de contrôle de version. ^{[OSPS-BR-07.01]}
Configurez .gitignore ou équivalent pour exclure les fichiers susceptibles de contenir des informations sensibles. Utilisez des hooks de pré-commit et des outils d'analyse automatisés pour détecter et empêcher l'inclusion de données sensibles dans les commits.
The project pipeline uses Trivy vulnerability scanning to detect any secrets or sensitive data in the Git repo.
The Trivy scanners used:
- vuln
- misconfig
- secret
- license
Criterion [OSPS-DO-01.01]
Atteint

Non atteint

N/A

?

Lorsque le projet a effectué une publication, la documentation du projet DOIT inclure des guides utilisateur pour toutes les fonctionnalités de base. ^{[OSPS-DO-01.01]}
Créez des guides utilisateur ou de la documentation pour toutes les fonctionnalités de base du projet, en expliquant comment installer, configurer et utiliser les fonctionnalités du projet. S'il existe des actions dangereuses ou destructrices connues disponibles, incluez des avertissements très visibles.
The following Readme files and documentation are included with each release/tag:
- How to release: https://code.in0rdr.ch/hivedav/file/RELEASES.md.html
- How to setup & use: https://code.in0rdr.ch/hivedav/file/README.md.html
- Development/implementation details: https://code.in0rdr.ch/hivedav/file/docs/CALDAV.md.html
Additional files might be provided in the future, to further document the system as needed.
Criterion [OSPS-DO-02.01]
Atteint

Non atteint

N/A

?

Lorsque le projet a effectué une publication, la documentation du projet DOIT inclure un guide pour signaler les défauts. ^{[OSPS-DO-02.01]}
Il est recommandé que les projets utilisent le suivi de problèmes par défaut de leur VCS. Si une source externe est utilisée, assurez-vous que la documentation du projet et le guide de contribution expliquent clairement et visiblement comment utiliser le système de signalement. Il est recommandé que la documentation du projet établisse également des attentes quant à la manière dont les défauts seront triés et résolus.
See bottom of the Readme:
- https://code.in0rdr.ch/hivedav/file/README.md.html#l218
Defects/issues can be reported via IRC and the web.libera.chat interface.

The issues are recorded and tracked in a public Kanboard:
- https://board.in0rdr.ch/public/board/01171363fae4b8b81af1579708f7cda6d389062f05b75db860621eaed32b
```
## Development & Contributions
* All source code is available in this repository. Contributions are always
  welcome! Pull requests at https://pr.in0rdr.ch/repos/hivedav
* A [Kanban
  board](https://board.in0rdr.ch/public/board/01171363fae4b8b81af1579708f7cda6d389062f05b75db860621eaed32b)
documents plans, todos and decisions for further development of the project.

## Community and Support
For question and support visit
[#p0c/libera](https://web.libera.chat/gamja/#p0c) on IRC.
```
Criterion [OSPS-GV-02.01]
Atteint

Non atteint

N/A

?

Le projet DOIT disposer d'un ou plusieurs mécanismes pour les discussions publiques concernant les changements proposés et les obstacles à l'utilisation. ^{[OSPS-GV-02.01]}
Établissez un ou plusieurs mécanismes pour des discussions publiques au sein du projet, tels que des listes de diffusion, de la messagerie instantanée ou des systèmes de suivi de problèmes, pour faciliter une communication et des retours ouverts.

See the README.

For question and support visit #p0c/libera (https://web.libera.chat/gamja/#p0c) on IRC.

Discussions via patch sets are encouraged as well (https://pr.in0rdr.ch/repos/hivedav)
Criterion [OSPS-GV-03.01]
Atteint

Non atteint

N/A

?

La documentation du projet DOIT inclure une explication du processus de contribution, ou indiquer clairement que les contributions publiques ne sont pas acceptées ^{[OSPS-GV-03.01]}
Créez un fichier CONTRIBUTING.md ou un répertoire CONTRIBUTING/ pour décrire le processus de contribution, y compris les étapes pour soumettre des modifications et interagir avec les mainteneurs du projet.
There is no "process" setup specifically for the contribution. The "process" is kept simple/lean.

See bottom of the Readme:
- https://code.in0rdr.ch/hivedav/file/README.md.html#l218
All source code is available in this repository. Contributions are always welcome! Pull requests at https://pr.in0rdr.ch/repos/hivedav
Criterion [OSPS-LE-02.01]
Atteint

Non atteint

N/A

?

La licence du code source DOIT satisfaire à l'Open Source Definition de l'OSI ou à la Free Software Definition de la FSF. ^{[OSPS-LE-02.01]}
Ajoutez un fichier LICENSE au dépôt du projet avec une licence qui est une licence approuvée par l'Open Source Initiative (OSI), ou une licence libre approuvée par la Free Software Foundation (FSF). Des exemples de telles licences incluent 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). Publier dans le domaine public répond à ce contrôle s'il n'y a pas d'autres restrictions telles que des brevets.

The MIT license for the repository contents is approved by the Open Source Initiative (OSI).

Criterion [OSPS-LE-02.02]
Atteint

Non atteint

N/A

?

La licence des ressources logicielles publiées DOIT satisfaire à l'Open Source Definition de l'OSI ou à la Free Software Definition de la FSF. ^{[OSPS-LE-02.02]}
Si une licence différente est incluse avec les ressources logicielles publiées, assurez-vous qu'il s'agit d'une licence approuvée par l'Open Source Initiative (OSI), ou d'une licence libre approuvée par la Free Software Foundation (FSF). Des exemples de telles licenses incluent 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). Notez que la licence des ressources logicielles publiées peut être différente de celle du code source.

The MIT license is approved by the Open Source Initiative (OSI). [floss_license]

Criterion [OSPS-LE-03.01]
Atteint

Non atteint

N/A

?

La licence du code source DOIT être conservée dans le fichier LICENSE, le fichier COPYING, le répertoire LICENSES/ ou le répertoire LICENSE/ du dépôt correspondant. ^{[OSPS-LE-03.01]}
Incluez la licence du code source du projet dans le fichier LICENSE, le fichier COPYING, le répertoire LICENSES/ ou le répertoire LICENSE/ du projet afin de fournir de la visibilité et de la clarté sur les conditions de licence. Le nom de fichier PEUT avoir une extension. Si le projet dispose de plusieurs dépôts, assurez-vous que chaque dépôt inclut le fichier de licence.

see https://code.in0rdr.ch/hivedav/file/LICENSE.html
Criterion [OSPS-LE-03.02]
Atteint

Non atteint

N/A

?

La licence des ressources logicielles publiées DOIT être incluse dans le code source publié, ou dans un fichier LICENSE, un fichier COPYING, ou un répertoire LICENSE/ accompagnant les ressources de la version correspondante. ^{[OSPS-LE-03.02]}
Incluez la licence des ressources logicielles publiées du projet dans le code source publié, ou dans un fichier LICENSE, un fichier COPYING ou un répertoire LICENSE/ aux côtés des ressources de publication correspondantes pour fournir visibilité et clarté sur les termes de la licence. Le nom de fichier PEUT avoir une extension. Si le projet a plusieurs dépôts, assurez-vous que chaque dépôt inclut le fichier de licence.
The LICENSE file is included in the releases/tags:
- https://code.in0rdr.ch/hivedav/file/LICENSE.html
Criterion [OSPS-QA-01.01]
Atteint

Non atteint

N/A

?

Le dépôt de code source du projet DOIT être lisible publiquement à une URL statique. ^{[OSPS-QA-01.01]}
Utilisez un VCS commun tel que GitHub, GitLab ou Bitbucket. Assurez-vous que le référentiel est publiquement lisible. Évitez la duplication ou la mise en miroir de référentiels à moins qu'une documentation très visible ne clarifie la source principale. Évitez les changements fréquents du référentiel qui affecteraient l'URL du référentiel. Assurez-vous que le référentiel est public.

see https://code.in0rdr.ch/hivedav

Criterion [OSPS-QA-01.02]
Atteint

Non atteint

N/A

?

Le système de contrôle de version DOIT contenir un enregistrement publiquement lisible de toutes les modifications apportées, qui les a apportées et quand elles ont été apportées. ^{[OSPS-QA-01.02]}
Utilisez un VCS commun tel que GitHub, GitLab ou Bitbucket pour maintenir un historique de commits publiquement lisible. Évitez de fusionner ou de réécrire les commits d'une manière qui obscurcirait l'auteur de tout commit.

see https://code.in0rdr.ch/hivedav/log.html

Criterion [OSPS-QA-02.01]
Atteint

Non atteint

N/A

?

Lorsque le système de gestion de paquets le prend en charge, le référentiel de code source DOIT contenir une liste de dépendances qui tient compte des dépendances directes du langage. ^{[OSPS-QA-02.01]}
Cela peut prendre la forme d'un fichier de gestionnaire de paquets ou de dépendances de langage qui énumère toutes les dépendances directes telles que package.json, Gemfile ou go.mod.

see https://code.in0rdr.ch/hivedav/file/go.mod.html

Criterion [OSPS-QA-04.01]
Atteint

Non atteint

N/A

?

Les projets comportant plusieurs dépôts DOIVENT documenter une liste des bases de code qui font partie du projet. ^{[OSPS-QA-04.01]}
Documentez tous les référentiels de code de sous-projets supplémentaires produits par le projet et compilés dans une version. Cette documentation doit inclure l'état et l'intention du code source respectif.

The mentioned Git repo is the single source of truth for the project.

Criterion [OSPS-QA-05.01]
Atteint

Non atteint

N/A

?

Le système de contrôle de version NE DOIT PAS contenir d'artefacts exécutables générés. ^{[OSPS-QA-05.01]}
Supprimez les artefacts exécutables générés dans le système de contrôle de version du projet. Il est recommandé que tout scénario où un artefact exécutable généré apparaît critique pour un processus tel que les tests, il devrait plutôt être généré au moment de la compilation ou stocké séparément et récupéré lors d'une étape de pipeline spécifique bien documentée.

Criterion [OSPS-QA-05.02]
Atteint

Non atteint

N/A

?

Le système de contrôle de version NE DOIT PAS contenir d'artefacts binaires non révisables. ^{[OSPS-QA-05.02]}
N'ajoutez aucun artefact binaire non révisable au système de contrôle de version du projet. Cela inclut les binaires d'applications exécutables, les fichiers de bibliothèque et les artefacts similaires. Cela n'inclut pas les ressources telles que les images graphiques, les fichiers sonores ou musicaux et le contenu similaire généralement stocké dans un format binaire.
Criterion [OSPS-VM-02.01]
Atteint

Non atteint

N/A

?

La documentation du projet DOIT contenir des contacts de sécurité. ^{[OSPS-VM-02.01]}
Créez un fichier security.md (ou portant un nom similaire) qui contient les contacts de sécurité pour le projet.
We use the IRC chat as single point of contact.

For the SECURITY readme file, see:
- https://board.in0rdr.ch/public/task/72/01171363fae4b8b81af1579708f7cda6d389062f05b75db860621eaed32b

Vous pouvez utiliser des outils et des systèmes d'IA pour proposer des modifications via une URL simple, par exemple https://www.bestpractices.dev/fr/projects/14270/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. Consultez notre système de propositions d'automatisation pour savoir comment procéder. Ces données sont disponibles sous la licence Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Cela signifie qu'un destinataire de données peut partager les données, avec ou sans modifications, à condition que le destinataire de données rende disponible le texte de cet accord avec les données partagées. Veuillez créditer Andreas Gruhler et les contributeurs du badge des meilleures pratiques de la OpenSSF.

Soumission du badge du projet appartenant à : Andreas Gruhler.
Soumission créée le 2026-08-28 09:26:54 UTC, dernière mise à jour le 2026-08-28 09:59:31 UTC.

HiveDAV

Notions de base

Général

Contrôles 24/24 ●

Contrôles