Connexion
Abonnez-vous

Bitwarden clarifie la situation autour du fameux SDK : c’était un bug

Le 28 octobre à 08h52

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 (10)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar
Au cas où, j'étais passé sur Proton Pass... mais j'en suis revenu. Pas que la qualité ou la sécurité ne soient moins bonnes, mais le côté pratique étais moins bien, obligé d'utiliser son compte complet en identifiant à chaque ouverture, des petits trucs qui freinaient un peu l'utilisation au quotidien... Bon, ben je reste sur Bitwarden alors !
votre avatar
Je suis sur Proton Pass et je n'ai pas à me re authentifier à chaque fois. J'ai en plus mis un pin à 6 chiffres pour justement le déverrouiller plus rapidement
votre avatar
Faut que je le teste ce Proton Pass car je l'ai dans mon package ... Bon, je reste fidèle à KeePass 2 offline ceci dit.
votre avatar
A noter, bitwarden est auto hebergeable et ça c’est vraiment chouette.
On utilise son fork vault warden au boulot et c’est un bonheur.
votre avatar
Ce n’est pas vraiment un fork mais une réécriture de l’API en rust 😁

Et je confirme que c’est très chouette en auto hébergement !
votre avatar
Je confirme aussi pour vaultwarden. Je l'utilise aussi pour le boulot, pour échanger de manière sécurisé des informations avec mes clients. Ca marche au poil !
votre avatar
+1 pour Vaultwarden.

Et il y a aussi la version officielle self hosted, plus simple moins lourde à déployer qu'à ses débuts (multiples containers)
votre avatar
La puissance de Vaultwarden est surtout de rendre accessible de manière libre et en open-source, (quasiment) toutes les fonctionnalités de la version payante de Bitwarden (notamment la capacité de pouvoir gérer une "organisation" et de partager des mots de passe).
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).
votre avatar
C'est vrai, mais c'est aussi le cas pour pas mal de code open source, et ce n'est pas une garantie de sécurité de toutes façons.
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.
votre avatar
J'ai vu ça hier, et ça confirme ce que j'indiquai en commentaire.

Bitwarden clarifie la situation autour du fameux SDK : c’était un bug

Fermer