maintainer-list: fix data published without consent #273146
Conversation
|
We can't squash the history. That's clear (to me). |
Which should make it clear that we should refrain from committing personal data without the affected people consenting (or even be informed). Or make it clear that contributing is not meant for Europeans or people from other regions with similar legal protection of personal data. |
|
@zeuner How do you prefer to proceed? Do you want me to merge this in the time being? |
|
GitHub already publishes your username anywhere you commit with your email address, and the GitHub ID is publicly available based on the username. So is this really private information? Not being able to look up a maintainer's GitHub username does make pinging them cumbersome:
I'd suggest a different approach: If you want to be listed as a maintainer, you must consent to us listing the one thing that is critical for follow-ups: you GitHub username. |
This was already discussed in the offending PR. I won't explain the GDPR again and again. If we want a post-GDPR Nixpkgs, let's state that clearly and remove misleading lines that suggest something else (https://github.com/NixOS/nixpkgs/blob/master/maintainers/maintainer-list.nix#L52).
If this becomes policy, it should be possible to submit new packages without a maintainer entry. Otherwise, this would essentially translate to: "go away, we'd rather go without your contributions". Be sure to discuss this with those who value my contributions. |
Isn't that already possible? Plenty of packages don't have a maintainer. It's just more at risk of being removed or falling into breakage eventually unless someone takes care of it. There is of course no problem maintaining it without being the official maintainer. In general, there's no need to assume bad faith, as I gather from your comments so far. Thinking that the GitHub username and ID fields were mandatory is a reasonable mistake to make, not an attempt at doxing. |
|
I would like this PR to focus on the mitigation we should put in place regarding the specific case rather than going on general policy but I want to address a single thing.
Well, I would argue that we would rather go without an introduction of a package or a NixOS module or a NixOS test that is maintained with insufficient data to reach out to folks. Sending contributions without being in the maintainer-list is completely fine in general. But introducing things is not a gift, it is a responsibility. |
Well, everyone who spoke on it on the offending PR seemed to agree that this shouldn't have been committed without prior consultation of those whose data was to be published. So I don't see any reason why a reverting commit (as the one contained in this PR) would not be committed ASAP. Regarding the commit history, @vcunat stated it's not possible to squash the offending commits. Technically, this seems implausible considering how often I've been asked to squash my own commits, suggesting that this should also be possible for commits where there is a good reason to not appear publicly anymore. Let alone the fact that this might help against existing GitHub automation that is already in the process of making copies in other branches: #273137. Maybe it's less a technical limitation and more a policy thing, which would suggest that whoever is legally responsible for data published under the NixOS name should find a solution. I'm open to whatever is effective in preventing unauthorized data from the offending PR from being processed further. However, should there be no good alternative to force-pushing a clean history, I guess doing it early might be preferable considering the hash-protected nature of git's commit history. |
I prefer to ask. I will wait for CI to be green and merge.
There's a difference in treatment when it comes to public branches like master or release branches and your own branches, in this instance, we usually aim and treat effectively all public branches as immutable. I'm cc'ing @zimbatm @thufschmitt who are board members and Jonas is GitHub organization owner. |
This is why it is mandatory to provide one means of communication, be it Matrix, E-mail or GitHub. Personally, I've dealt with plenty of packages where whoever is listed as maintainer and has a GitHub handle published does not react at all. I don't see why this would be better than providing whatever means of communication over which the maintainer is comfortable to be reached. Regarding the gift vs. responsibility: Providing code for an existing package is also a responsibility, and in my experience is common that people will get in contact about that code. Still, no one asks you to enter yourself in the maintainer list when providing code for an existing package. When adding a package, people do so. In the end, for many of us this is a volunteer effort, and publishing contact data of contributors won't help against them having no time for contributing anymore in the future. Neither does pressuring them to "consent" to providing contact data. |
Right, but that seems to express a preference and the example about how maintainers can be unresponsive is orthogonal, maintainers can provide any means of communication and be unresponsive at all of them, unfortunately. Nonetheless, GitHub is special compared to the other information in the sense that it is used by automation to perform actions, e.g. https://github.com/NixOS/ofborg/blob/de415d372959b7e6fc6b2f6c95f0c21e5010348d/ofborg/src/maintainers.nix#L80.
Well, it all depends on the code for an existing package. Maintainers ought to not accept code they are not comfortable with, if necessary, they may invite the contributor to join the maintainer team to maintain it with them. For sure, plenty of people may do what you describe but my point is really about the clear boundary on adding something vs. adding something to existing entities.
Sure, as it is for me. I still have trouble to grasp the importance of protecting contact data that you use to contribute (and I do have GDPR expertise but I am not really interested into continuing further this open conflict). Nonetheless, what matters to me is that volunteers are free to disappear from day to another but it's equally important to provide the right tools for the people who will take up their work in their stead not knowing if they disappeared for 3 months or 6 months or more. Otherwise, this will just push for more aggressive actions and heightened quality standards in Nixpkgs because it's not very nice for the remaining volunteers to be responsible to deal with the leftovers of the ones who stopped contributing while asking them to keep the contributions in. I don't want to pressure you into consenting to provide any consent data or anything. This is a social project and there's a social dimension, I wish we had better tools to collaborate safely, "anonymously", etc. Regrettably, there's also a tension between those goals and security and ease of use. I just hope this make it clearer that this is not a bullying attempt, we just want to make it easier for everyone here to work with everyone here. If those demands are too constrained, I fear this will create further friction in other parts of the project. |
Well, after years of |
|
@zeuner I opened #273332 to revert both GitHub account additions (I don't think we need to include anything extra like you did in this PR though). While we can't squash the history, a revert is better than nothing. Fully agreed that the original PR shouldn't have been merged without your consent. I'll merge the linked PR in a bit. |
This reverts commit 3429e79. GitHub names/ids are not mandatory for now. See #273220, #272199 and #273146. Furthermore this user has not consented to their account information being added to the listing. While we can't reasonably change the git history, we can revert the change so it won't be included in future revisions.
This reverts commit bc0adb2. GitHub names/ids are not mandatory for now. See #273220, #272199 and #273146. Furthermore this user has not consented to their account information being added to the listing. While we can't reasonably change the git history, we can revert the change so it won't be included in future revisions.
|
I merged the above-linked PR, so your GitHub account is not listed in master from now on. Whether GitHub accounts should be mandatory can be further discussed in #273220. |
I actually was also unsure about the comment. However, how would you intend to avoid future similar actions? It seems that people with commit rights gladly do detective work to figure out personal data and publish it, thinking that not giving consent was "just an overlook" (#272199 (comment)). Maybe a better solution would be a defined magic value for the data fields which is documented as "no consent given". This way, not giving consent would be explicit and (in contrast to the comment solution) also machine readable. From a GDPR perspective, this might be mandated anyways. |
I think that's a good idea if we end up with GitHub accounts really not being mandatory! Let's see what comes out of the discussion in #273220 first though |
I'm surprised that it's still open. This is a decision that impacts the whole Nix* community and not only Github users, so it should be discussed in a way that includes the whole community. However, the author explicitly stated he doesn't want to create an RFC. In my opinion, this should be closed and possibly reopened if some day someone finds it important enough to discuss this in a proper way. |
|
In order to remove that information we would have to contact GitHub support to delete the original PR, as the commit ID is still held there. Revert the history in master for all of the users. This would cause a massive disruption. The private information under GDPR is the name and email, but those are already in nixpkgs, and submitted voluntarily by the user. I don't think that the GitHub Account name falls under such a provision since it is by default public and should be covered by GitHub's License Grant to Other Users and signed by the user. Given that the user's name matches exactly the handle and no attempt has been made to distantiate those, making an association claim seems to be a bit of a stretch. Trying to read between the lines, it seems like the real conflict is for using GitHub as a platform in the first place. If that's the case, please try to engage in it directly. It's possible to have a conversation about this over Discourse, and I think you would see that Raito will agree with you on the matter. |
This is for sure. This is why I suggested to act quickly and thereby minimize the disruption if there is no other way to prevent processing of the published data. I know this is unpleasant. This is why projects that fall under the GDPR will usually define clearly who may work with personal data, and what they may do. In our case, we might want to learn from it and implement suitable checks into
I understand this may be non-obvious from a non-EU perspective, but the GDPR applies a concept called "purpose limitation". This means that it doesn't suffice that you were able to somehow find the personal data, even if it was easy. You still need to check whether the intended purpose (here: putting it into a text-based database meant to be immutable and feeding it into various automation systems) was permitted. If what you're stating is true and the permission stems from GitHub's License Grant, then GitHub should be able to confirm that they notified their users about the account name being transmitted to one of Nix*'s entities in order to be used like this. If this is the official position of the responsible person, I can file such a request to GitHub and check it. I do actually doubt it, though. The License Grant you linked provides an exhaustive list of permitted usages, which does not include what was happened here. Furthermore, it states that more permissions may be granted through a license. I'm also not aware of a license I accepted where I agreed to such a usage. So, in order to save time it might be more effective if we found some actual approaches that will help limiting further processing of the data.
I think this is getting a bit off-topic, but since you brought it up: As much as various other contributors as far as I'm aware of, I'm not a big fan of GitHub und would find it attractive to abandon it at some point. But I don't think it's the right time to discuss this. It might be when the Forge Federation efforts fly some day. On the other hand, what applies here is that I regard it as additionally offending to see that my personal data had been abused for an effort to even increase dependence on GitHub, which is for sure a step in the wrong direction considering that we already have some tooling to facilitate cross-platform collaboration, and could go further from there. I also read that @RaitoBezarius claims to agree with my position on using GitHub as a platform, considering that he suggested working on independence efforts (#272199 (comment)), for which I offered my help. However, this quickly turned out as implausible when only ten minutes later, he kicked off a campaign to severely limit contributions from people who prefer to keep some independence from GitHub. So, if there are really some shared goals, it might be helpful not to say something and do the opposite. Personally, I'm still available for contributing my time for better tooling that makes cross-platform collaboration easier, provided that he stops the attempt to lock me out of contributing. |
|
Thanks for bringing this up. From my understanding, using GitHub handles on GitHub generally fits the legitimate and compatible purposes criteria of the data. This isn't very dissimilar to @mentioning somebody in a commit message, or commenting a piece of code with a reference to a GitHub handle as a source of inspiration. Nevertheless, I understand that you had initial expectations to be able to participate in the project without needing a GitHub account. You were led to believe it was possible due to the current shape of the shema, and conversation with nlewo in your original PR. And this expectation got broken in this PR. It seems that this is the central piece of your disagreement. Any attempt to fix the schema to match reality is then subsequently seen by you as an attempt to lock you out. Am I correct? |
Thanks for the analogy attempt. Please note that I never objected against people using the Furthermore, even if your analogy would be fully agreeable regarding GitHub handles, it could not possibly serve as a justification for the processing and aggregation of GitHub IDs. This affects the effectiveness of EU-based participants' right to erasure. If a participant would at some point want to pull off his connection with the Nix* community, he might want to give up package maintainership ad change his GitHub handle. But if he is forced to have his GitHub ID stored forever, he would be forced to delete his GitHub account and re-register. Considering that despite me asking about it multiple times, no one seems to be willing and/or able to provide me with a position regarding the purpose limitation issue I brought up, and furthermore considering the obvious danger of re-offending (#273220 - still ongoing attempt to pressure users to accept the offense by threatening with reduced participation, #178656 - similar offense not even partially rectified until now, #273137 - still ongoing attempt to publish the offending data on a different branch expected to reach more end users), I would think that it may save all of us time if I delegated the assessment of the relevance in context of the GDPR to an external entity. A possibility would be asking GitHub as they should be able to provide a position on whether their previously cited "License Grant to Other Users" encompasses the mining, storage and aggregation of user handles and IDs and their usage for the automated system In case it will be required in the process, I assume that the postal address where the responsible NixOS Foundation will be able to receive enquiries would be: Hogeweide 346 Is this correct?
This doesn't actually belong here (PR regarding fixing a GDPR violation), but in case it helps: It seems fairly stretched to talk about "matching reality" considering that there were already two PRs (#178656, #272199) found where the authors doctored the maintainer list and thus created an impression of what you called "reality" here. The way how the maintainer entries were created initially shows what's actually reality. Therefore, it's merely an euphemism to call changing the schema to match the doctored maintainer list "fixing the schema to match reality". If we want to come to a consensus, we should avoid euphemisms and properly distinguish between fixes (e.g. NixOS/ofborg#665) and offenses (e.g. #272199). Indeed I think that there was the reasonable and legitimate expectation for me and the other at least 40 affected maintainers (only taking into account #272199 and #178656) to expect that there is no requirement for having a GitHub account or linking it somewhere. This becomes obvious not only because of the data schema (being like this for years, apart from e-mail becoming optional at some point) and the communication with one user. The documentation also explicitly contains an example workflow containing a maintainer without a linked GitHub account (see https://github.com/NixOS/nixpkgs/blob/master/maintainers/README.md?plain=1#L83). Whether GitHub could be made mandatory has also been discussed before and it was decided against it (see #209165 (comment)). Contribution without a GitHub account has been positively discussed on Discourse (https://discourse.nixos.org/t/contribute-without-a-github-account/25007/2). So there was no reason for contributors to expect something else than the schema documentation being correct. On the top of that, the community web site explicitly states the RFC process as a mechanism to create confidence in the community about the direction in which the ecosystem is evolving (see https://nixos.org/community/index.html). So these few users pushing aggressively to circumvent the RFC process here can hardly be seen as something else than a direct attack on this confidence in which community members want to trust. However, I do not consider any attempt to evolve the schema as a lockout attempt. It also depends on how it is done. In this case, as mentioned above the RFC process is being circumvented, questions about the actual beneficial impact of the intended change are being ignored, as well as non-excluding technical solutions for identified difficulties with the current schema. Taking all this into account, this does indeed look less like an attempt to actually improve something, and more like an attempt to persistently lock me and the other 40 maintainers out. But trying to generalize this to "any attempt" for something is besides the point. In this case and for me personally, it goes further. Since the web site created the impression of this being a community-driven project that includes its participants in its evolution (now seemingly disproved), I did not only contribute time, but I also endorsed the usage of Nix* products to individuals and organizations I work with, and recently applied for public funding of an envisioned improvement for Nixpkgs I plan to implement. For any other open source project, this would be considered a situation of mutual benefit. But other open source projects also don't act by creating the impression that contributing is welcome, only to pull a stunt like seen here. |
|
I'm no lawyer, but I fail to see how the NixOS foundation (the legal entity) is relevant here. IMHO in this community you're just dealing with various individuals from all over the world. |
|
@zeuner A bit rich that you're complaining about publishing private info, and then put my home address in a GitHub comment. |
|
@edolstra: That's the registered address of the NixOS Foundation, available publicly from the KVK. You're the one who now said it's your home address.. |
The activities in question took/take place on https://github.com/NixOS, which links to various online presences of the NixOS Foundation. So it's safe to assume that the foundation does claim responsibility for what happens on this institutional or corporate account. Furthermore, it can be assumed that the foundation decides who has write access based on its responsibilities. So, I think there is no reason to assume a claim against an entity different than the foundation here. Of course, as a part of its responsibilities it cannot be ruled out that the foundation might have to file claims against said individuals if they used the foundation's GitHub account for unlawful activities. But this is really beyond the scope of this PR. |
EU law protects personal data of natural persons, not of institutions, corporations, foundations etc. Since you claim you live at the same address where also the foundation resides, which is within the EU, I also don't see why you would claim something against me based on non-EU law. |
Well, I guess you can also see that there is not much room left for objective discussion here. People just post random comments to express disagreement, without caring about how much sense it makes in the given situation (GDPR claim, EU-based legal entity). Furthermore, there doesn't seem to be any interest to settle the remaining offenses internally. So I guess everyone would agree that the only reasonable way to proceed is to let an external entity decide, as already suggested on Friday. |
|
To comply with your request to remove personal information from this repository, I opened #275328 |
|
I saw this message too late. You can however add a new pull request to revert this change if you are still ok that this also links your GitHub account because of technical reasons. |
|
No. This is about, #275328 I will now disengage from this conversation after the last accusations in the same pull request. |
I don't see how that's relevant since the foundation has nothing to do with this. |
In case the NixOS foundation is not (anymore) responsible for activities under the https://github.com/NixOS organizational account, I suggest that someone with suitable privileges edits the organizational page to represent to correct legal entity. Otherwise we risk GitHub cutting off access to the account if they find out about it: https://docs.github.com/en/site-policy/acceptable-use-policies/github-impersonation |
|
What happened is certainly not impersonation. I wonder why so many of your comments feel like threatening. |
This reverts commit 3429e79. GitHub names/ids are not mandatory for now. See NixOS#273220, NixOS#272199 and NixOS#273146. Furthermore this user has not consented to their account information being added to the listing. While we can't reasonably change the git history, we can revert the change so it won't be included in future revisions.
This reverts commit bc0adb2. GitHub names/ids are not mandatory for now. See NixOS#273220, NixOS#272199 and NixOS#273146. Furthermore this user has not consented to their account information being added to the listing. While we can't reasonably change the git history, we can revert the change so it won't be included in future revisions.
Description of changes
Publishing personal data requires consent in many jurisdictions. This is known and led to an appropriate hint (https://github.com/NixOS/nixpkgs/blob/master/maintainers/maintainer-list.nix#L52). Apparently, there was still data published without consent: #272199. It was labeled a "data scheme breakage", which is obviously untrue since the file explicitly states that all fields apart from
nameare optional, and only one out ofemail,matrixorgithubIdmust be given (see https://github.com/NixOS/nixpkgs/blob/master/maintainers/maintainer-list.nix#L7).Please merge this soon and squash the related commit history so the data published without authorization cannot be retrieved from the history.
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 馃憤 reaction to pull requests you find important.