Suite à un joli mail d'information, je me connecte à mon compte gitlab.com pour découvrir ceci (les parties en gras sont de mon fait):
As part of my use of GitLab.com, I acknowledge that the use of my information will be processed in accordance with the agreed GitLab Privacy Policy and Terms of Service. By clicking Accept terms, I am hereby providing consent to this use and agree to all of the terms and conditions.
(For GitLab Contributors Only) As part of my voluntary contribution to any GitLab project, I acknowledge and agree that my name and email address will become embedded and part of the code, which may be publicly available. I understand the removal of this information would be impermissibly destructive to the project and the interests of all those who contribute, utilize, and benefit from it. Therefore, in consideration of my participation in any project, I hereby waive any right to request any erasure, removal, or rectification of this information under any applicable privacy or other law and acknowledge and understand that providing this information is a requirement under the agreement to contribute to the GitLab project.
I also acknowledge that Terms of Service and Privacy Policy have been updated to reflect these changes, as well as other updates in accordance with applicable law. By clicking Accept terms, I am hereby providing consent to this use and agree to all of the terms and conditions.
Traduction:
Dans le cadre de mon utilisation de GitLab.com, je reconnais que l'utilisation de mes informations sera traitée en accord avec la politique de données personnelles de GitLab et de ses conditions d'utilisation. En cliquant "Accepter les conditions", je donne par là même mon consentement à cette utilisation et accepte tous ces termes et conditions.
(Pour les contributeurs GitLab seulement) Dans le cadre de ma contribution volontaire à tout projet GitLab, je reconnais et accepte que mon nom et mon adresse email seront inclus et feront partie du code, qui peut être disponible publiquement. Je comprends que la suppression de ces informations serait innacceptablement devastateur pour le projet et les intérêts de ceux qui y contribuent, l'utilisent et en bénéficient. En conséquence, dans le cadre de ma participation à tous projets, je renonce par là même à tout droit de demander toute suppression, retrait ou rectification de ces informations sous quelques prétextes de respect de la vie privée ou autres lois, et reconnais et comprends que fournir ces informations est une obligation d'après l'accord de contribution au projet GitLab.
Je reconnais également que les Conditions d'Utilisation et la politique de respect des données personnelles ont été mises à jour pour refléter ces changements, de même que d'autres mises à jour en accord avec la loi en vigueur. En cliquant "Accepter les conditions", je donne par là même mon consentement à cette utilisation et accepte tous ces termes et conditions.
Si je ne fais pas d'erreur, je ne participerai donc plus aux projets hebergés par gitlab.com
Non pas que cela fera beaucoup de tort à ces projets qui ni ne m'attendaient, ni n'avaient besoin de moi, mais j'ai du mal à voir comment ce changement peut être légal dans le cadre de la RGPD/GPRD qui devient obligatoire aujourd'hui même.
# Git
Posté par Anonyme . Évalué à 10.
C'est juste que ça pourrait impacter des dépôts git qui ne sont pas les tiens, et ça serait vraiment le bazar.
T'imagines si tu voyais des commits disparaître de ton projet parce que un de tes contributeurs a décidé de faire supprimer ses données personnelles ?
[^] # Re: Git
Posté par HL . Évalué à 4.
Wikipédia rencontre le même problème (une modification d'un article, ça ressemble à un commit), mais propose tout de même le droit à disparaître.
[^] # Re: Git
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 9.
Oui, mais chez wikipedia, à priori, l'identifiant d'un "commit" n'est pas lié à son parent. Le modifier n'impacte en rien le système. Et puis j'imagine que l'utilisateur est identifié dans une autre table dédié aux utilisateurs, et qu'il n'y a dans le "commit" qu'une référence vers cet utilisateur. Il "suffit" dans ce cas, à priori, juste de modifier un enregistrement dans la base de donnée pour changer le nom en "anonymous1234".
Dans Git, c'est différent, car l'identifiant d'un commit est calculé en fonction de son contenu, c'est à dire en fonction du nom et email de l'auteur, de l'identifiant des commits parents etc.. Changer une information dans le commit, et ça change les identifiants de tous les commits descendants.
[^] # Re: Git
Posté par HL . Évalué à -1.
Est-ce qu'il est important de garder les informations servant à calculer l'identifiant une fois qu'il est généré ?
[^] # Re: Git
Posté par paipai62 . Évalué à 2.
Oui, pour vérifier l'intégrité
[^] # Re: Git
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 6.
Dans git, l'identifiant est le résultat du hashage de ces informations. Si tu les modifies, cela veut dire que l'id ne correspond plus. C'est la manière utilisée dans git pour certifier l'authenticité des informations.
Changer la manière dont c'est fait ou stocké, revient à créer un nouveau format de stockage de Git. Je te laisse en discuter alors avec les mainteneurs de git ;-)
[^] # Re: Git
Posté par Nils Ratusznik (site web personnel, Mastodon) . Évalué à 3.
On ne peut pas envisager de réattribuer les commits à un utilisateur "anonymous" ?
[^] # Re: Git
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 10.
Comme je le dis plus bas, en théorie, c'est possible. Mais en pratique, c'est un cauchemar pour les autres utilisateurs, puisque tous les identifiants de commits changent : ça fout la merde chez les développeurs, dans les systèmes d'intégration continue, dans les bugs trackers etc. Et plus le projet est gros, plus tu t'approches de l'enfer. Donc en pratique, c'est juste pas possible.
[^] # Re: Git
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
J'ai presque envie de dire, système mal fichu -> faire évoluer le système ;-)
Cela dit, avec le droit d'auteur, c'est compliqué… En supprimant ton identité, ta contribution passe t-elle sous domaine public (impossible en France).
On a un peu le même soucis dans la fonction publique ou théoriquement presque tout devrait être archivé. La mise en place du RGPD entraîne des complications non prévus par l'organisation / workflow actuel. À mon sens, cela passe quasi obligatoirement par une évolution des logiciels.
[^] # Re: Git
Posté par arnaudus . Évalué à 1.
Bah non, évidemment. Sans ton nom, ta contribution reste toujours sous la licence où tu l'as placée. Il n'y a pas besoin de t'identifier pour que cette licence soit applicable, vu qu'elle ne donne aucun droit à l'auteur, juste à l'utilisateur. L'auteur devra juste prouver la paternité par un autre moyen s'il souhaite faire valoir d'autres droits (poursuite pour contrefaçon, etc).
Certaines licences (comme les CC-BY) imposent de citer les auteurs, mais j'imagine que si un auteur décide de ne pas mentionner son nom, ou de se faire appeler "X" ou "anonyme", ça ne pose pas de problème particulier…
[^] # Re: Git
Posté par nud . Évalué à 3.
Pour pouvoir appliquer le droit de propriété intellectuelle il me semble que l'auteur doit être identifiable.
En Europe il me semble que tu ne peux pas céder les droits de propriété intellectuelle, tout au plus accorder une licence qui est toujours révocable (un peu comme pour les données personnelles de la RGPD, en somme). Cela entrait déjà en conflit avec l'obligation de cession des droits que tu as pour contribuer à certains projets (comme les projets de Cannonical). Mais personne ne s'en est jamais vraiment inquiété à ma connaissance.
[^] # Re: Git
Posté par dyno partouzeur du centre . Évalué à 2.
Bien sûr que si ! Seuls les droits moraux son inaliénables. Ainsi que le fait d'être l'auteur.
Tu peux très bien céder définitivement les droits patrimoniaux à quelqu'un qui devient libre de faire ce qu'il veut de l'oeuvre (dans les limites de l'atteinte à ton droit moral), dont tu reste l'auteur.
Pour en revenir aux commits git, ils peuvent pas utiliser quelque chose d'anonymisé au lieu de prendre directement les données personnelles ? Genre un id d'utilisateur ça pourrait suffire. Tant que l'utilisateur est ok, on peut faire le lien entre l'id et les infos personnelles. Le jour où l'utilisateur décide de ne plus communiquer ces infos, tu as juste un id unique.
[^] # Re: Git
Posté par nud . Évalué à 3.
Dans l'absolu tu pourrais déjà le faire en utilisant un identifiant du genre string aléatoire avec un mail sur, par exemple, contrib.gitlab.com.
On pourrait imaginer aussi que git gagnerait une indirection pour lier ces identifiants avec les noms réels, sachant que cette indirection ne peut pas faire partie du repo en lui-même et ne peut pas être versionnée (un peu comme les branches, en somme)
Ou bien on peut considérer que ceci fait partie de l'intérêt légitime et que ce sont des données minimales. Ce n'est pas comme si tu devais ajouter ton numéro de téléphone et ta date de naissance à tes commits.
[^] # Re: Git
Posté par Clément David (site web personnel) . Évalué à 4.
Exactement, c'est la stratégie documentée dans les documents de références sur le terme "Pseudonymisation". Le principe est d'introduire une indirection d'un identifiant unique vers des données personnelles et de n'utiliser que cet identifiant sur les données.
En y réfléchissant, c'est identique à un pseudonyme qui serait généré et c'est parfaitement utilisable avec git (ou autre). Il suffit que le projet auquel tu contribues accepte les contributions sans appliquer de convention stricte sur l'auteur du commit. Il faut bien sûr aussi penser à "pseudonymiser" sa clé ssh et son compte Gitlab.
$ git commit --author="Foo bar baz <foo.bar.baz@gmail.com>" -m "Commit anonyme"
[^] # Re: Git
Posté par Alex G. . Évalué à 4.
Oui mais est-ce que c'est compatible avec ton archive locale git. Git ne peut pas le faire à posteriori, tu push des commit, où ton nom est déjà dedans…
Je pense que tu peux très bien décider toi d'utiliser un pseudonyme et un mail lié à ce pseudonyme pour pousser tes commit, mais mieux que ça je vois pas.
[^] # Re: Git
Posté par abakkk . Évalué à 3.
En effet c'est plus un problème de Git que de Gitlab. Pour permettre une conformité Git ne devrait plus utiliser de mail.
[^] # Re: Git
Posté par FilG . Évalué à 0.
Oui, je comprend que le problème se pose pour tout dépôt Git, ainsi que les forges sociales qui les utilisent, donc Github, Tuleap, Bitbucket quand il est utilisé avec des dépôts git, etc.
[^] # Re: Git
Posté par feth . Évalué à 3.
Ça pose la question de la conformité de l'exception au droit de repentir propre au logiciel avec le RGPD. Je pense que c'est l'exception qui gagne mais les paris sont ouverts.
[^] # Re: Git
Posté par arnaudus . Évalué à 3.
De toutes manières, ce problème existe depuis le début des licences libres, qui imposent une licence irrévocable incompatible avec le CPI français. Il y a en fait au moins deux problème, le premier, c'est que la GPL n'a pas de limite de temps, et cette limite de temps est imposée par la jurisprudence dans le cas par exemple de la cession des droits d'auteur à un éditeur, une maison de disques, etc. Le deuxième problème, c'est le droit de repentir (un peintre a le droit de demander à détruire une toile, etc). En fait, ce deuxième cas n'est pas vraiment un problème, puisqu'évidemment le droit de repentir doit s'accompagner d'un dédommagement. Dans le cas du logiciel libre, le contributeur qui souhaite retirer ses contributions d'un projet doit donc dédommager les utilisateurs, j'imagine que ça peut être fait à la hauteur des frais correspondant au re-codage des parties manquantes. Donc c'est techniquement faisable, même si en pratique c'est compliqué.
Bref, rien ne nouveau avec la RGPD, ça fait juste remonter à la surface des problèmes d'incompatibilité entre le droit français et les licences libres habituelles.
[^] # Re: Git
Posté par feth . Évalué à 3.
le droit de repentir n'est pas applicable au logiciel, justement.
[^] # Re: Git
Posté par El Titi . Évalué à 1.
Je ne vois pas en quoi c'est compliqué pour l'avoir déjà fait avec du BFG.
https://help.github.com/articles/removing-sensitive-data-from-a-repository/
Et heureusement, quand tu laisses echapper des passwords dans le code …
Pour les liens avec les "issues" tu perds la trace de qqs commit mais bon.
Après c'est sûr que c'était une super idée de hasher le user.name et mail dans le code alors qu'on peut signer ses commits autrement.
https://fiat-tux.fr/2018/04/21/signer-ses-commits-git-et-transferer-son-gpg-agent-sur-un-serveur-distant/
(Hg is dead :()
[^] # Re: Git
Posté par Alex G. . Évalué à 5.
Les commentaires ne disaient pas que c'était impossibles, mais que ça casse tous les liens dans les tickets, ou changelog, que tout le monde se retrouve avec sa branche locale en conflit, etc…
[^] # Re: Git
Posté par Zenitram (site web personnel) . Évalué à 10.
Rassure-moi, car tu as l'air sérieux : tu plaisantes la?
Au cas où tu ne plaisantes pas : si un password s'est échappé, tu ne sais pas qui l'a, et remplacer le commit ne changera rien sur le fait que le password s'est échappé.
Quand on laisse échapper un password, on le remplace, c'est tout (et si on a envie, on ajoute un commit mettre un truc plus explicit "ici est le password", mais ça ne change rien à la sécurité).
[^] # Re: Git
Posté par feth . Évalué à -3.
Imaginons que tu laisses fuiter un mot de passe pour un service que tu ne gères pas toi-même. Ou une clef utilisée pour valider l'authenticité des mises à jour de micrologiciel (de voiture, par exemple) ?
Oui, tu peux révoquer la clef, mais comment transfère-t-on la liste de clefs révoquées ? par une mise à jour ?
[^] # Re: Git
Posté par Sufflope (site web personnel) . Évalué à 7.
J'en sais rien, mais ça ne change pas le fait que réécrire l'historique au moment où tu t'en rends compte, en répétant l'incantation "j'espère que personne ne l'a pull" en boucle à voix basse, n'est pas une solution.
[^] # Re: Git
Posté par feth . Évalué à 0.
Indépendamment des mesures à prendre, si tu le laisses en ligne tu commets potentiellement un délit. C'est gênant aussi.
Exemple de clef qui traîne dans la nature et qu'il n'est a priori pas anodin de mettre à disposition : DeCSS.
[^] # Re: Git
Posté par Zenitram (site web personnel) . Évalué à 3.
Tiens, ça devient honteux de défendre les mots de passe, donc changement de sujet qui n'a pas grand chose à voir mais sans accepter d'avoir dit une grosse bêtise et dire "oups, oui bêtise comme exemple et ma defense sur comment gérer etait vraiment nulle je devrais apprendre à mieux gérer les mots de passe dans la nature donc essayons un autre"?
Pour le code copyrighté (je t'aide vu que ton exemple est vraiment foireux étant donné que ces clés sont sur plein de t-shirt etc et tout le monde a abandonné l'idée de faire un procès pour), ça arrive oui, et C'est à virer. Mais on s'éloigne de plus en plus du sujet initial qui est que 10 après un commit, il peut être demandé de changer juste parce que une personne veut changer la typo de son nom. Exception car triche qui oblige à casser l'historique (généralement peu de temps après le commit) vs personne mal lunée qui veut casser un historique de 10 ans, que tu trouves peut être légitime mais perso je n'en suis pas convaincu et je demande donc de l'argumentation (des comparaisons sont bienvenues si pertinentes et défendues : un choix personnel pour le plaisir de changer un truc légal à l'époque est il comparable à du code à la source contrefaite donc jamais légal?)
[^] # Re: Git
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3.
En France, tu gardes le droit de paternité sur ton oeuvre, même si elle est anonyme. Donc ça ne règle pas le problème. C'est justement pour ça que Gitlab demande de renoncer à une liste de droits bien spécifiques, qui n'inclut pas le droit de paternité.
# Pour les projets open-source
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 10.
Dans le cadre d'une participation à un projet open-source, quel qu'il soit, depuis la nuit des temps, implicitement tu acceptes que ton nom et ton email soient publiques. Je ne vois pas comment cela peut être autrement. Il faut bien, à un moment ou à un autre, qu'on puisse t'identifier, ne serait-ce que pour appliquer les droits que t'autorise la licence libre utilisée.
Cette identification peut être réèlle (ton vrai nom, et une adresse mail contenant ton nom), ou peut être anonymisée (un pseudo, et une adresse basée sur un pseudo).
Quoi qu'il en soit, en contribuant, tu as donné ton accord pour que l'identité que tu as donné soit publique.
On peut maintenant s'interroger sur la retractation, puisque le RGPD te permet en théorie de supprimer tes données personnelles. Mais dans le cadre d'un dépot git (open-source ou pas), ça devient particulièrement complexe. Certes, en théorie, il serait possible de réécrire tous les commits où ton nom/email apparait. Mais cela revient à créer un nouveau dépôt puisque tous les identifiants des commits créés depuis ta première participation sont changés. Et si il y a besoin de faire ça régulièrement, dans la pratique, cela devient un cauchemar pour les développeurs, puisqu'il faudrait "rebaser" son travail en cours sur un dépôt totalement nouveau, sans parler de tous les outils qui référencent des commits (integration continue, bug tracker…). Bref, en pratique, ce n'est pas possible.
Et fort heureusement, je crois que le RGPD prévoit les cas où tes informations personnelles sont absolument nécessaires au fonctionnement d'un service ou d'une entreprise (vous imaginez ? "bonjour l'urssaf, supprimez toutes mes données personnelles siouplait").
Bref, la suppression de tes données personnelles dans les dépots git étant impossible, et ce cas d'impossibilité de suppression étant prévu par le RGPD, Gitlab respecte de mon point de vue le RGPD. Donc soit tu acceptes que ton nom/email soit utilisé et tu ne pourras pas faire machine arrière, soit tu n'utilises pas le service.
[^] # Re: Pour les projets open-source
Posté par lalmeras . Évalué à 3.
[Ecrit pendant la réponse de Laurent J, mais posté après… redondant, mais je ne voulais pas le jeter]
Sauf erreur de ma part, les informations nominatives et email font partie intégrante du commit et du hash calculé pour le commit. De ce fait, d'un point de vue technique, anonymiser des commits passés reviendrait à faire des rebases complet de l'historique, avec les inconvénients techniques qui en découlent (plus de référence à un technique par son sha, …).
Gitlab pourrait réécrire tous les commits entrant pour modifier les informations d'auteur pour y introduire une référence à une base d'auteur externe, qui pourrait, elle, devenir anonyme. Mais fini l'interopérabilité avec d'autres dépôts git.
Côté RGPD, les nécessités techniques associées aux traitements sont des éléments qui entrent en ligne de compte pour apprécier les limitations et contraintes sur les droits de modification et suppression. Je trouve que Gitlab, en détaillant de manière précise les données concernées, leur utilisation et la justification de la limitation des droits des utilisateurs satisfait à ces exigences.
Et soit dit en passant, tous les dépôts git qui n'impose pas l'utilisation d'un alias anonymisé pour les commits sont concernés par le même problème.
Dernier point, Gitlab n'empêche personne d'utiliser une identité et un email "factice" (email réel, mais pas forcément nominatif).
[^] # Re: Pour les projets open-source
Posté par Benoît Bailleux (Mastodon) . Évalué à 2.
Laurent, ton commentaire me fait penser à une question et une remarque sur le sujet :
(merci de corriger si je me trompe : ça m'intéresse)
[^] # Re: Pour les projets open-source
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
Je ne sais pas trop là. Tout dépend avec quel type de CLA on compare.
[^] # Re: Pour les projets open-source
Posté par arnaudus . Évalué à 3.
Ça ne veut pas dire que le nom doit être public. Les écrivains qui écrivent sous pseudonyme touchent leurs droits d'auteur, parce que l'éditeur peut faire le lien.
De toutes manières, je ne comprends pas ce que tu veux dire. Les licences libres ne donnent pas de droits aux auteurs, mais aux utilisateurs. Du coup, pourquoi aurais-tu besoin de connaitre les auteurs? Au pire, si les auteurs veulent te poursuivre parce que tu ne respectes pas la licence, ils ont besoin de prouver qu'ils sont les auteurs du code, ce qui peut être fait de beaucoup de manières, et pas seulement parce que leur email figure en haut des fichiers…
Pas de problème avec ça, du moment que cet accord est révocable.
Non, mais le problème, c'est que ces informations sont publiques. À ma connaissance, l'URSAFF ne publie pas les informations personnelles.
J'imagine aussi que c'est impossible de retirer des informations personnelles tant qu'on utilise un service qui en a besoin. Typiquement, les infos personnelles disponibles par whois sont indispensables pour l'identification du propriétaire d'un nom de domaine ; tant que tu possèdes ce nom de domaine, j'imagine qu'il est absurde de demander le retrait de tes infos personnelles. Par contre, il n'y a plus de raison de les conserver dès que tu ne payes plus.
J'ai l'impression qu'un bon compromis serait la possibilité de retirer les infos personnelles d'un dépôt Git à partir du moment où la personne l'a demandée. Les noms/emails restent dans l'historique du dépôt, bien sûr, parce que c'est impossible techniquement de faire autrement (*), mais ces infos restent enfouies dans l'historique, ce qui rend leur déterrage accidentel asssez peu probable.
(*) J'imagine d'ailleurs qu'il serait tout à fait possible de faire évoluer le logiciel de gestion de version pour gérer ce cas, par exemple en marquant des commits comme "synonymes" (éventuellement, en imposant que les seules différences entre les commits synonymes sont dans les commentaires, mais dans le détail, on s'en fout), et de rediriger de manière transparente toutes les requêtes sur les commits masqués vers le commit synonyme non-masqué. Bien sûr, on perd évidemment l'exactitude de l'historique (c'est exactement ce qu'on veut), et il faut faire confiance au "masqueur" sur la synonymie, mais l'opération laisse une trace (donc on ne peut pas "nettoyer" en douce un historique).
[^] # Re: Pour les projets open-source
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
Alors d'abord ça dépend des licences libres, il n'y a pas que la GPL dans la vie et encore, je doute qu'elle ne donne pas de droits aux auteurs. D'autres parts, si elles ne donnent pas de droits aux auteurs, cela veut dire qu'un contributeur peut par exemple s'attribuer la paternité de mes contributions sans que je puisse dire quelque chose ?? je ne crois pas..
C'est ce que j'ai écris. Le RGPD impose toutefois de signaler à l'utilisateur ce qu'il fait de ses données personnelles.
Je ne comprends pas, ces données, elles sont publiques ou pas ? ;-)
Quoiqu'il en soit, l'URSAFF échange ces données (une partie au moins) avec d'autres services de l'état il me semble.
Le cas de l'URSAFF et d'autres similaires, c'est que là, les données ne sont pas seulement nécessaire au fonctionnement du service, mais est aussi imposée par des lois (qui t'obligent à donner certaines données personnelles à l'URSAF).
Bref, les obligations imposées par des lois doivent probablement faire parti des exceptions dans le RGPD.
Le WHOIS est encore un cas intéressant, et fait d'ailleurs débat actuellement. Que l'on puisse t'identifier, oui, mais la question est, qui peut t'identifier. Que le registrar auprès duquel tu as réservé ton nom de domaine, stocke dans le WHOIS tes informations personnels, cela peut se comprendre. Mais que ces informations puissent être diffusées à n'importe qui dans le monde, c'est franchement discutable. Heureusement certains registrar comme Gandi permettent d'obfusquer ces informations (je crois que concrètement, les données restent dans leur base, et dans le WHOIS, elles n'y apparaissent pas)..
[^] # Re: Pour les projets open-source
Posté par Zenitram (site web personnel) . Évalué à 6. Dernière modification le 25 mai 2018 à 12:48.
Mais la fin de la discussion n'est pas forcément de cacher.
Ca me parait pas délirant que le proprio d'un nom de domaine soit accessible à n'importe qui dans le monde, pour voir les différents liens entre les gens et les sites.
Mais en fait, poussons juste le raisonnement jusqu'au bout : "Mais que ces informations puissent être diffusées à n'importe qui dans le monde, c'est franchement discutable" est l'argument de pays ne voulant pas diffuser les proprios d'entreprises ou trusts, et les xxxleaks ont justement cassé cette barrière, et je n'ai pas vu foule râler contre de telles informations diffusées à n'importe qui dans le monde alors que c'est le même contenu (nom, adresse…) et donc la même gestion de données personnelles. Les leaks doivent-ils être condamnés par le public?
infogreffe n'est pas anonymisé alors que c'est la même chose (qui possède quoi), est-ce aussi discutable? Si pas le cas, qu'elle différence fais-tu entre whois et infogreffe?
Bref, la phrase "Mais que ces informations puissent être diffusées à n'importe qui dans le monde, c'est franchement discutable." est aussi discutable.
[^] # Re: Pour les projets open-source
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2.
J'apprécie l'existence d'une liste rouge pour les numéros de téléphone. Un principe similaire pour le whois me semble approprié: on choisit si on veut, ou pas, que l'information soit publique.
De toutes façons, pour les quelques noms de domaines (en .tk) que j'utilise, le fournisseur rend déjà ce service: c'est son nom qui apparaît dans le whois, pas le mien.
[^] # Re: Pour les projets open-source
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 6.
Tu compares des choux et des carottes. Une entreprise par définition, c'est publique.
Un nom de domaine, est certes, publique, mais son propriétaire n'est pas forcément une personne morale. J'ai plusieurs noms de domaines que je possède à titre personnel, qui pointent vers des sites non commerciaux, et non, désolé, je n'ai pas envie que mon nom, adresse postale, numéro de téléphone et autres données personnelles soient diffusées à tout le monde. Je ne vois pas en quoi il faudrait que cela le soit.
C'est comme si il fallait obligatoirement qu'un livre contiennent la véritable identité de son auteur, ainsi que son adresse domicile, numéro de téléphone etc.
Il serait bon de vouloir arrêter d'imposer sa vision des choses à tous le monde. C'est pas parce qu'on place le curseur de sa vie privée à un certain niveau (genre diffusion à tous le monde de ses coordonnées domicile), qu'il faut imposer ce curseur à tous le monde. J'estime avoir le droit d'avoir un minimum de vie privée.
Non, je n'ai pas envie que n'importe qui voit les liens entre moi et des sites, en particulier les coordonnées de mon Domicile. Et j'emmerde ceux qui ne sont pas content.
Et si ils veulent voir pour des raisons légales (genre enquête de police ou autre), bah, ils ont à priori les moyens légaux d'aller interroger le registrar.
[^] # Re: Pour les projets open-source
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 25 mai 2018 à 14:55.
Argument bateau quand on ne veut pas débattre.
Un site web… Aussi. Donc?
En effet. C'est pareil d'ailleurs avec infogreffe (mon nom et adresse sont dessus, aux dernières nouvelles je ne suis pas une personne morale)
OK.
Mais tu n'as pas répondu pourquoi mon nom, adresse postale, numéro de téléphone et autres données personnelles doivent être diffusées, juste parce que je possède une entreprise et non pas un nom de domaine.
OK. Donc moi aussi pour mon entreprise, donc tu es contre infogreffe et les leaks on est d'accord?
Pareil pour infogreffe, on est donc d'accord qu'infogreffe devrait cacher? Pareil pour Panama (il y les moyens légaux, c'est "juste" plus long… comme pour whois maintenant)
Tu as évité de répondre à une question précise, en brodant autour, du HS (c'est bon j'ai compris ta position, je te demande juste si tu es d'accord pour que d'autres aient aussi leur vie privée, même quand ça ne te plait pas). Tu as évité d'argumenter en quoi ça serait différent, qui était la seule question (je n'ai pas demandé de dire pourquoi c'est pour toi une vie privée).
Perso qu'un domaine ne montre pas son auteur ne me plaît pas et le fait qu'une entreprise ne montre pas son proprio ne me dérange pas, et tu dis "Il serait bon de vouloir arrêter d'imposer sa vision des choses à tous le monde", donc je te demande juste si cette phrase s'applique que pour ce que tu aimes ou si tu l'acceptes pour les autres, car la j'ai l'impression de belles paroles pour justifier un truc qui te plaît à cacher (en gros tu utilises, donc tes données privées) mais que tu n'aimerais pas que j'utilise ce même argument pour un autre registre dont la visibilité te plaît (en gros tu n'utilises pas, donc pas tes données privées)…
Pour le moment, tous tes "arguments" démontrent le contraire de ce que tu "vends" (whois infogreffe pas pareil, mais arguments disent que c'est pareil : public, même données privée…)
[^] # Re: Pour les projets open-source
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 25 mai 2018 à 15:40.
Parce que tout simplement c'est la loi qui l'y oblige. Personnellement je ne trouve pas ça normal à notre époque. C'était peut-être acceptable à l'époque où il n'y avait pas internet, parce que c'était contraignant pour obtenir ces informations et que donc ça limitait les problèmes. Manifestement, il y a selon moi une incompatibilité avec le RGPD (il faudrait montrer patte blanche pour accéder aux extrait kbis).
oui on est d'accord.
bla bla bla. Tu as très bien compris mon propos. Ne te fait pas prendre pour moins intelligent que tu es.
[^] # Re: Pour les projets open-source
Posté par arnaudus . Évalué à 2.
Bof, je ne sais pas. Posséder une entreprise, ça n'est pas la même chose que de posséder un nom de domaine! Un nom de domaine, on peut le voir comme une sorte d'accès à la publication (et encore, beaucoup de noms de domaine ne correspondent pas à des sites web consultables…).
Une entreprise est une personne morale capable de faire beaucoup de choses en son nom : engager des poursuites en justice, signer des contrats, demander des permis de construire, financer tout un tas d'organisations, ouvrir des comptes en banque, employer / licencier des gens, collecter des impôts (TVA et maintenant IR)… Je ne vois pas ce qui est de comparable avec un nom de domaine, donc je pense que les deux situations sont en fait incomparables.
On est quand même dans un grand paradoxe, parce qu'on n'a aucune idée de l'arbitrage entre la vie privée et l'intérêt collectif. L'interêt collectif voudrait que tout propriétaire foncier soit très facilement identifiable et localisable à partir du cadastre, par exemple. C'est quand même un droit pour tout citoyen de connaitre l'identité réelle de ses voisins. De même, il me semble totalement sain de pouvoir connaitre le propriétaire d'une entreprise qui vient faire de travaux chez soi, qui propose la garde des enfants, etc.
Comme on a un système d'identification nom-prénom bien pourri qui permet des homonymies, il faut adjoindre des infos annexes (adresse, numéro de téléphone, date de naissance) pour lever les ambiguité. Et toutes ces infos deviennent disponibles, parfois en ligne, et parfois consultables pour des raisons qui n'ont rien à voir avec leur existance.
[^] # Re: Pour les projets open-source
Posté par kna . Évalué à 3.
Euh, pas forcément non…
Tu peux utiliser ton nom de domaine pour héberger du mail, des dépots git privés, du owncloud/seafile, des applis web à usage privé (kresus par exemple), etc.
Par ailleurs, pour un site public, la loi fait bien la différence entre personne morale, personne physique, site avec ou sans activité commerciale dans les mentions légales.
# Tu ne peux donc plus participer à aucune projet ayant un historique fiable
Posté par Zenitram (site web personnel) . Évalué à 8. Dernière modification le 25 mai 2018 à 11:21.
GitLab ne fait que mettre noir sur blanc le principe d'historique fiable.
Tu ne peux donc plus participer à aucune projet ayant un historique fiable, soit quasi tous les projets open source (et même sans doute non open source).
Par ta réaction tu condamnes tout gestionnaire de code décentralisé (tu demandes à casser les hash de commit sur simple demande de ta part, boom les autres repos)
Tu condamnes le messager, ça ne change pas que depuis le début du contrôle de source c'est voulu de ne pas corrompre un historique.
Sérieux, il faut arrêter le délire à un moment, j'ai même lu qu'il faudrait qu'on supprime les données des backups, quelqu'un a-t-il prévu de remonter tous les backup, supprimer la ligne avec un email, et regarder les backups? Ca part de bonnes intentions, mais à un moment ça va trop loin.
(Tiens, maintenant je pense aux mailing list publiques avec front end web, ou les newsgroups diffusés sur plusieurs serveurs de plusieurs gestionnaires… Je me demande comment ça va se passer en pratique pour virer une adresse mail de ces trucs).
C'est la partie "intérêt légitime à garder l'info". Ce n'est pas comme si un logiciel de peinture te demande ta date de naissance, c'est une site qui fait un historique de tes commits qui te demande le droit de faire un historique de tes commits.
[^] # Re: Tu ne peux donc plus participer à aucune projet ayant un historique fiable
Posté par fearan . Évalué à 2.
que le nom de l'auteur et son adresse de courriel fasse parti du commit me semble superflu; ce serait mieux si c'était un identifiant, et que cet identifiant soit rattaché aux informations personnelles; en cas de demande de suppression de compte, on supprime les données personnelles et on garde l'identifiant.
Ça permet même de mettre ces données à jours ; dingue ça.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Tu ne peux donc plus participer à aucune projet ayant un historique fiable
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4.
C'est comme ça que git fonctionne et là, gitlab n'y peut rien. Il faudra voir directement avec Linus Torvalds pourquoi il a fait ce choix pour git. Mais en tout cas ça ne va pas être simple à changer.
Dans SVN par exemple il y avait uniquement un "identifiant" sans format spécifique. Mais je suppose que dans le cas de Linux, c'est très utile de pouvoir récupérer le nom et l'e-mail de la personne qui a fait tel ou tel changement directement depuis le dépôt git, sans avoir besoin de passer par un annuaire centralisé.
[^] # Re: Tu ne peux donc plus participer à aucune projet ayant un historique fiable
Posté par fearan . Évalué à 4.
L'annuaire pourrait être fournis en même temps que le repos git; comme le code, et l'association se faire par le client.
Si je prends comme exemple ma première adresse mail c'était en IUT; puis très vite caramail, ma troisième un truc sur hotmail pour msn. Aucune des deux première n'est active aujourd'hui, quant à la troisième j'y retourne moins d'une fois par an.
J'en ai eu 2 autre à l'université.
J'ai aussi une adresse sur un serveur perso, mais j'utilise plus vraiment.
J'ai aussi une adresse datant d'avant le rachat de ma boite, perdu encore une fois.
J'en ai eu une associé à mon compte yahoo, perdu aussi.
Bref la seule qui a traversé les ans c'est celle de gmail, et j'essaye de limiter son emprise.
Une adresse de courriel c'est un peu comme ton adresse postale, ça change…
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Tu ne peux donc plus participer à aucune projet ayant un historique fiable
Posté par Zenitram (site web personnel) . Évalué à 6.
absolument rien n’empêche de mette "blabla blabla@example.com".
Met ce que tu veux!
tu peux associer une adresse email "virtuelle" à un compte, et voila.
Ca serait parfois plus pratique (genre on change d'adresse)
C'est un choix, oui, reste à savoir si on a envie de changer ça, ou si l'actuel ne convient finalement pas mieux, c'est un débat, mais qui n'est pas lié au RGPD à mon avis.
[^] # Re: Tu ne peux donc plus participer à aucune projet ayant un historique fiable
Posté par fearan . Évalué à 1.
Super pratique pour être contacté… Sans oublier ceux qui font ça avec leur adresse pro, changement de boite => changement compte.
Je serai curieux de savoir quel est la proportion de gens ici à savoir le faire, et s'ils sont capable d'en assurer la pérennité sur plus de 15 ans.
Le fait de mettre comme partie intégrante des données des informations à caractère personnel, et se cacher derrière une impossibilité technique pour refuser tout changement/suppression me parait non seulement douteux, mais aussi dangereux. Il suffirait qu'un procès décrète qu'il faut obligatoirement supprimer ces référence et c'est le repo qui va perdre en cohérence.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Tu ne peux donc plus participer à aucune projet ayant un historique fiable
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 0.
Linux (et d'autres aussi) utilise le nom de domaine des e-mails aussi pour faire des stats sur lesentreprises qui contribuent chez eux.
Et aupassage je rappelle que la license GPL oblige à mettre les code sources à disposition pendant 10 ans quand on distribue un programme. Donc si tu es contributeur à un projet sous GPL tu es déjà obligé d'assurer de la perrenité…
[^] # Re: Tu ne peux donc plus participer à aucune projet ayant un historique fiable
Posté par nud . Évalué à 5.
Et git permet de relier plusieurs adresses e-mail à une seule personne via le fichier .mailmap
[^] # Re: Tu ne peux donc plus participer à aucune projet ayant un historique fiable
Posté par fearan . Évalué à 2. Dernière modification le 28 mai 2018 à 09:10.
La disponibilité des sources n'a rien à voire avec la pérénité d'une adresse mail, tu peux très bien filer le code source en même temps que le programme. Hop, plus besoin de conserver un quelconque serveur pendant 10 ans. Tu peux aussi distribuer ton code uniquement et laisser les utilisateurs le compiler;
Bref c'est un problème orthogonal à l'impossibilité de changer une adresse mail.
C'est sympa d'expliquer le pourquoi, mais ça ne règle pas le problème.
En revanche Nud explique l'existence du .malmap qui permet de palier à ce problème; je n'ai donc plus d'objection.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Tu ne peux donc plus participer à aucune projet ayant un historique fiable
Posté par El Titi . Évalué à 3. Dernière modification le 25 mai 2018 à 19:09.
Définis-moi "historique".
Est-ce qu'un nom et une adresse mail doivent en faire partie et être figés ?
Un id utilisateur n'aurait pas suffit ? (comme ça on peut se marier et changer de nom, de pseudo,
changer de boite mail, et rester l'auteur … la vie quoi
Ca fait marrer de voir des tartines pour justifier une erreur de design. Cargo cult detected
# Github et tout les autres....
Posté par Fabien PRORIOL . Évalué à 2.
J'irais même plus loin… tout service qui utilise Git va avoir le même choix a faire; donc les GitLab, les Gitolite, les kernel.org…. Du moment que les données (user et email) font parties du hash d'un commit Git, et que ce hash est inclue dans le hash du commit suivant, elles ne peuvent pas être supprimé.
Je ne sais pas comment fonctionne Mercurial et les autres, mais le problèmes sera peut être le même…
[^] # Re: Github et tout les autres....
Posté par nud . Évalué à 2.
Dans l'absolu ils pourraient faire comme ce qui se fait pour les records whois, et utiliser un "pseudo" et une email propre au service. Càd que tes commits seraient identifiés comme venant de
glkfdgm <glkfdgm@contributor.gitlab.com>. Ce ne serait pas très pratique pour les utilisateurs de git, ceci dit.[^] # Re: Github et tout les autres....
Posté par Zenitram (site web personnel) . Évalué à 4.
On retrouvera le même problème qu'avec les raccourcisseurs d'URL : un maillon faible (fermeture du service, perte du lien entre alias et vrai adresse…).
Est-ce qu'on a vraiment envie de ça? Perso je suis plus d'avis de se passer de contributeurs n'étant pas capables de faire eux-même ce travail d'alias si ils souhaitent se cacher, ici le nom et mail d'une personne me parait quand même bien légitime pour le but à atteindre (gestion de source, et des auteurs).
Rien de nouveau, il verront "glkfdgm" comme aujourd'hui quand une personne veut se cacher, et enverront un mail à une adresse GitLab, c'est tout.
la question est de savoir si on veut généraliser (obliger) ce comportement, afin de ne pas casser l'historique si une personne change d'avis un jour.
Je me demande comment vont faire les journaux papier pour enlever le nom d'un auteur qui ne veut plus assumer ses écrits. Et même en ligne, un auteur peut-il demander à enlever son nom d'un article qu'il n'assume plus? A mon avis, l’intérêt légitime d'une info passe au dessus du GDPR, enfin c'est ce que je comprend du GDPR qui s’intéresse plus aux infos "non utiles au service".
[^] # Re: Github et tout les autres....
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4.
En fait c'est indépendant du RGPD, il existe déjà dans le droit d'auteur un droit de retrait et un droit de repentir.
https://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT000006069414&idArticle=LEGIARTI000006278894
Il serait tant de s'en préoccuper. Cela dit, c'est "contre indemnisation", il va donc falloir aller indemniser tous les cessionnaires, c'est-à-dire, dans le cas d'une licence de logiciel libre, toutes les personnes ayant accepté la licence (qui leur cède plein de droits). L'indemnisation risque de coûter cher…
C'est amusant de voir tout le monde paniquer autour du RGPD alors que bien souvent on parle de choses qui n'ont rien à voir et qui étaient déjà possibles auparavant.
[^] # Re: Github et tout les autres....
Posté par Yves (site web personnel) . Évalué à 1.
Je ne vois pas trop comment serait gérée la synchro avec le remote dans ce cas…
[^] # Re: Github et tout les autres....
Posté par abakkk . Évalué à 1.
Mais là tu rajoute de la centralisation; le dépôt est lié à la plateforme.
[^] # Re: Github et tout les autres....
Posté par nud . Évalué à 2.
Oui et non, on peut imaginer que git gérerait lui-même la liste des alias, comme il le fait pour la liste des branches par exemple.
[^] # Re: Github et tout les autres....
Posté par FilG . Évalué à 1.
Dans Mercurial (Hg), chaque nouvelle version est associé à un identifiant de modification (le changeset) qui est calculé en hachant des métadonnées et les données elles-même.
Ces métadonnées peuvent contenir des infos personnelles (https://www.mercurial-scm.org/wiki/FrenchChangeSet).
Il me semble qu'un moyen élégant et fonctionnel serait que les systèmes de gestion de version utilisent, en lieu est place de l'identification de l'auteur, une clé GPG. Elle resterait unique mais ne permettrait plus de remonter à l'auteur.
Néanmoins, cela complexifie le système…
[^] # Re: Github et tout les autres....
Posté par Sufflope (site web personnel) . Évalué à 2.
Mmmmoui alors euh un peu quand même si ? Parce que OK je peux me la faire voler, mais à ce compte-là, une connexion depuis mon IP peut être du fait de quelqu'un d'autre que moi, pourtant c'est "donnée personnelle".
# 2 articles à lire
Posté par patrick_g (site web personnel) . Évalué à 4. Dernière modification le 25 mai 2018 à 14:41.
Ce n'est pas légal.
J'ai trouvé que ces deux articles écrits par Jacques Mattheij étaient vraiment pédagogiques et écrits de façon très lisible :
https://jacquesmattheij.com/gdpr-hysteria
https://jacquesmattheij.com/gdpr-hysteria-part-ii-nuts-and-bolts
Dans le second il y a une FAQ avec cette entrée :
Can I have my users check a box that says they opt-out of their rights under the GDPR?
No, you can’t, full stop.
[^] # Re: 2 articles à lire
Posté par Psychofox (Mastodon) . Évalué à 4.
C'est le genre de phrase butoir sortie tout droit d'un chapeau.
La vérité c'est que la GDPR vient d'arriver, est probablement en conflit avec une foultitude d'autres lois (je pense par exemples à certaines lois qui imposent de garder certaines informations, par exemple dans le domaine de la santé) et que seules des décisions de juges pourront établir une jurisprudence permettant de savoir exactement ce que l'on peut faire ou pas dans de nombreux cas.
Et en l'occurence tant que personne ne sera assez con pour attaquer gitlab à ce sujet on n'en saura rien.
[^] # Re: 2 articles à lire
Posté par patrick_g (site web personnel) . Évalué à 2.
Ben la loi est quand même assez claire à lire (pour une fois). Une entreprise ne peut pas essayer d'esquiver les contraintes du GDPR en forçant les utilisateurs à accepter des conditions d'utilisations qui spécifient qu'ils renoncent à leurs droits.
https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:32016R0679&from=EN
Extrait de l'Article 43 :
Le consentement est présumé ne pas avoir été donné librement si un consentement distinct ne peut pas être donné à différentes opérations de traitement des données à caractère personnel bien que cela soit approprié dans le cas d'espèce, ou si l'exécution d'un contrat, y compris la prestation d'un service, est subordonnée au consentement malgré que celui-ci ne soit pas nécessaire à une telle exécution.
[^] # Re: 2 articles à lire
Posté par Ytterbium . Évalué à 2.
Le RGPD ne s'applique explicitement pas aux données conservées pur des raisons légales.
Imagine sinon si tu demandais aux impôts de supprimer toutes les données personnelles te concernant, ou à un commerçant de supprimer toutes tes factures.
[^] # Re: 2 articles à lire
Posté par patrick_g (site web personnel) . Évalué à 3.
Il me semble que ce n'est pas le sujet ici.
[^] # Re: 2 articles à lire
Posté par Ytterbium . Évalué à 1.
Je répondais à ça :
IL n'y a pas de conflit entre le RGPD et les autres lois, puisque toutes les données requises par la loi sont hors du champ du RGPD.
[^] # Re: 2 articles à lire
Posté par gnondpom74 . Évalué à 0.
je ne dirais pas hors du champ du RGPD. On ne peut pas demander à son employeur de supprimer son numéro de sécurité social, la loi l'oblige à le conserver, mais on peut toujours demander à exercer son droit d'accès.
Mais effectivement, le fait qu'il y ait une obligation légale permet de justifier la conservation d'une donnée personnelle.
[^] # Re: 2 articles à lire
Posté par Jean-Baptiste Faure . Évalué à 3.
Est-ce si sûr ? Il ne me semble pas absurde que gitlab.com soit en droit de s'assurer que l'auteur de toute contribution à un projet hébergé par gitlab.com soit identifié et puisse en répondre si nécessaire.
Imagine-t-on qu'un auteur ayant vendu plusieurs centaines de milliers de livres, demande à son éditeur de faire disparaître toute donnée personnelle de ceux-ci ? Pour moi le problème de gitlab.com et de toute forge logicielle n'est pas différent.
[^] # Re: 2 articles à lire
Posté par nud . Évalué à 2.
C'est même très pertinent dans le cadre des lois relatives aux droits d'auteur (licences, copyright, plagiat) notamment, dans la mesure où la personne identifiée par le nom dans le commit est responsable d'une éventuelle contravention à ces droits.
[^] # Re: 2 articles à lire
Posté par Zenitram (site web personnel) . Évalué à 5.
C'est binaire, es-tu prêt à parier et faire le point dans 5 ans (le temps de quelques procès)?
Ou c'est juste parce que tu n'as rien à risquer de le dire?
J'ai regardé sa bio vite fait, mais entre un "consultant to do technical due diligence" qui n'a rien à perdre à donne son point de vue (qui d'ailleurs ne dit pas exactement la même chose dans ce que tu as quoté que ce dont parle le journal) et les avocats d'une grosse boite comme GitLab qui a tout à perdre à faire de l'illégal (réputation pour les avocats et le site), je ne suis pas sûr de croire en priorité le gars technique pour du légal, quelque soit le niveau (je ne dis pas que le lire ne m'apportera rien, mais c'est une analyse avec un poids contre d'autres analyses).
Parce que bon, tout ce qu'on m'a vendu comme binaire "ce n'est pas légal, point" dans des débats à propos de procès surtout sur l'open source, les juges ont souvent décidé l'inverse…
[^] # Re: 2 articles à lire
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
gitlab ne parle que du nom et de l'adresse mail, il réduit donc le champs de sa demande. Il peut donc tout à faire définir qu'il s'agit d'élément indispensable pour un fonctionnement normale, ce qui est vrai en plus.
Le problème serait qu'il demande une adresse postale, qui n'est pas nécessaire pour rendre son service.
"La première sécurité est la liberté"
# git-replace(1)
Posté par benoar . Évalué à 3.
Ça sent le cas d'utilisation pour git-replace(1), ça…
[^] # Re: git-replace(1)
Posté par FilG . Évalué à 0.
ça ne suffira malheureusement pas : l'utilisateur peut choisir de récupérer ou pas les infos originelles avec l'option --no-replace-objects
Cette option ne fonctionne donc que si le client le décide, ce qui n'est pas suffisant à mon sens.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.