Bitwarden clarifie la situation autour du fameux SDK : c’était un bug
Le 28 octobre à 08h52
2 min
Logiciel
Logiciel
Il y a une semaine, des développeurs s’inquiétaient d’un apparent virage de Bitwarden sur l’open source. Le gestionnaire de mots de passe propose en effet la quasi totalité du code de ses composants en GPLv3 ou AGPLv3.
Un développeur avait découvert que le client Bitwarden avait introduit une dépendance à un SDK interne. Il fallait non seulement l’avoir sous le coude pour compiler le client, mais la licence de ce kit de développement interdisait toute utilisation pour tout autre projet que la construction du client officiel. Beaucoup y voyaient alors une limite franche à la création de clients tiers, alors que c’est justement l’une des forces de Bitwarden.
Kyle Spearrin, fondateur et directeur technique de Bitwarden, avait pris la parole pour expliquer notamment qu’il s’agissait d’établir une clarification sur ce qui était sous GPL et ce qui ne l’était pas.
Dans un nouveau message, il tient cependant à clarifier de nouveau la situation. « Nous avons fait quelques ajustements sur la façon dont le code SDK est organisé et empaqueté pour vous permettre de construire et d'exécuter l'application avec seulement les licences GPL/OSI incluses. Les références du paquetage sdk-internal dans les clients proviennent maintenant d'un nouveau dépôt sdk-internal, qui suit le modèle de licence que nous avons historiquement utilisé pour tous nos clients », commence-t-il par expliquer.
Il ajoute surtout : « La référence sdk-internal n'utilise pour l'instant que des licences GPL. Si la référence devait inclure le code de la licence Bitwarden à l'avenir, nous fournirions un moyen de produire plusieurs variantes de construction du client, similaire à ce que nous faisons avec les builds des clients web de la chambre forte ».
Il précise que le dépôt originel de SDK sera renommé sdk-secrets et qu’il « conservera sa structure de licence Bitwarden SDK existante » pour les produits commerciaux Secrets Manager. « Le dépôt et les paquets sdk-secrets ne seront plus référencés à partir des applications clientes, puisque ce code n'y est pas utilisé », finit d’expliquer Kyle Spearrin. En d’autres termes, il s’agissait d’un bug.
Le 28 octobre à 08h52
Commentaires (11)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 28/10/2024 à 09h08
Le 28/10/2024 à 09h36
Le 28/10/2024 à 09h45
Le 28/10/2024 à 11h55
On utilise son fork vault warden au boulot et c’est un bonheur.
Le 28/10/2024 à 12h01
Et je confirme que c’est très chouette en auto hébergement !
Le 28/10/2024 à 12h23
Le 28/10/2024 à 13h48
Et il y a aussi la version officielle self hosted,
plus simplemoins lourde à déployer qu'à ses débuts (multiples containers)Le 07/11/2024 à 10h27
Modifié le 28/10/2024 à 14h25
Comme dit @aware2 , il y a aussi le conteneur all-in-one de Bitwarden, mais limité à un seul utilisateur (si pas de licence, https://bitwarden.com/help/licensing-on-premise/).
Attention quand-même à Vaultwarden, le code n'a pas été audité. À mon avis, c'est bien pour le perso, mais pour le pro, on ne sait rien sur sa fiabilité (cela dit, ça existe depuis 6 ans, et je n'ai pas entendu une fuite d'un Vaultwarden).
Le 28/10/2024 à 14h42
Comme tous nos systèmes internes, le nôtre est dans sa zone étanche (évidemment pas accessible de l'extérieur), et chaque flux interzone est contrôlé, même interne.
Modifié le 28/10/2024 à 10h18