Usage of ungh.cc is not documented and potential security issue about nx HOT 9 CLOSED

Also a concern for me.

Even if my email comes from a commit info, I explicitly made it private on Github:
Settings > Emails > Keep my email addresses private

So I don't want my email to be used anywhere.

Plus: because my email is private on Github, ungh.cc cannot find me and I end up as plain text in changelogs. Which sucks because I do have a public Github profile...

from nx.

We will document the dependency.

There is no actual security vulnerability though because ungh provides a caching layer on top of Github API so.. anything which is accessible via ungh is already accessible via the Github API. So any user-emails harvested via ungh could already be harvested via Github's API without ungh.

@JamesHenry please correct me if I'm wrong.

from nx.

I don't think you are correct. You are sending committers email addresses to a 3rd party service and you can't guarantee what this service does with the data. It might as well harvest the emails and sell them. For GitHub Enterprise, email addresses might not be publicly available.

For our security officer, this is a huge concern preventing us from using nx.

I proposed 2 solutions (points 2 and 3 above) how to overcome this problem. I am also happy to provide a PR for this.

from nx.

@pkuczynski

I have created #26672 to address this.

It has always been possible to create a custom changelog renderer to control the exact nature of your commits being turned into changelog markdown, however, I agree if that it is shame if avoiding this lookup is the only reason someone would need to do that.

Therefore I have added a new default changelog renderer option mapAuthorsToGitHubUsernames which will only do anything if authors is enabled, but allows for the lookup/matching behaviour to be skipped but still print the author names.

I have also documented the requests made by the default behaviour.

from nx.

@Badisi I am not sure what you mean, ungh.cc is just a cached form of what is available via the GitHub Search API.

The git commit data has an email in it. I went to the first open-source repo on your public GitHub profile and your gmail address is freely available to scrape via git log. Setting that email option on GitHub does not update your commit history on your repos.

Plus: because my email is private on Github, ungh.cc cannot find me and I end up as plain text in changelogs. Which sucks because I do have a public Github profile...

By setting that option, you are explicitly preventing the GitHub Search API from allowing your user to be found via the email in your commit data. There is no way around it if you continue to use your gmail for your commit data but do not allow it to be used as a query to the search API.

However, if you want to update your git commit data to use your anonymized GitHub email address {USERNAME}@users.noreply.github.com instead of your gmail:

A) your gmail will stop being added to new commits going forward (it will not be scrubbed from previous commits though naturally)
B) our existing logic will already not perform the ungh.cc lookup, and instead just extract the username directly from that email string:

Hope that helps!

from nx.

Thank you @JamesHenry! This is for sure useful. However when I set release.changelog.renderOptions: false, the calls to ungh.cc stopped, and I still see authors properly linked to theirn GitHub profiles in the GH releases. Not sure why and how, but this is how it works atm!

from nx.

@JamesHenry, I got your point.

It's true that in the context of GitHub I chose to anonymize my email (using their settings) but in the context of Git, I'm using SourceTree which obviously uses my personal email during commits..

Using {USERNAME}@users.noreply.github.com as you suggested could be a solution, but I would also like to suggest an improvement to your existing logic:

Currently, you are searching for email to retrieve a user but you are neglecting the name.
In my case, commit author look like: Badisi <[email protected]>.
It's true that you won't find me with my email (as it is disabled on GitHub) but my name does exists and https://ungh.cc/users/find/Badisi does work.

So maybe you could improve the lookup by searching by email first, then by name, and if not found default to name as plain text 😊 ?

from nx.

@Badisi I feel like it's relatively uncommon for folks to have an exactly matching name and username on here, but I am happy to accept a PR to add that behaviour if you would like to submit it.

You could potentially also have it handle cases like mine where my name is my username just minus the spaces (although in my case the email is already resolvable).

I don't think we should keep trying a ton of permutations and slow down the changelog generation, but if you could process the name string to strip all spaces before looking it up on the API (in the case that the email address has already not matched) then I think that would be a decent compromise.

from nx.

This issue has been closed for more than 30 days. If this issue is still occuring, please open a new issue with more recent context.

from nx.