Not sure if this fits in here exactly, but it seems close enough: There is a bunch of “official” or at least “official looking” (???) GitHub organizations in the Julia ecosystem. Some I am aware of:
and certainly many more. Some of them specify https://julialang.org/ as their homepage. Some people will give extra credence to these orgs and content below them because they “seem” official, i.e. endorsed by the Julia team. But are there? In reality there is no way to know.
I was suggesting to some people to use https://github.com/bcbi/CompatHelper.jl but they refused because they “don’t like running foreign code on the repository (which gives plenty of access permissions). TagBot at least belongs to the JuliaRegistries organization.” . While I don’t agree with this assessment (bcbi to me is not more less trustworthy than, say julia-action), it made me wonder…
What is stoping me from registering the org JuliaActions · GitHub and putting the content of Julia Actions · GitHub there, but with some nefarious extra bits inserted? And then also a copy of CompatHelper, and some other stuff… and then I convince people to switch to it. Not sure I could actually do harm with this, but it still seems problematic.
As you point out in your post, anyone could create a GitHub organization with “Julia” and the name and host repositories that contain popular Julia packages with malicious code inserted.
As a general rule, there is nothing “official” about a GitHub organization that has “Julia” in the name.
You are bringing up a very important topic about the trust and trustworthiness of Julia packages. There are many open questions that we in the Julia community need to answer about the trust and security of Julia packages and Julia code.
Just FYI: for people that are interested in this topic: we have a Slack channel #pkg-trust for chatting about this kind of stuff. Of course that is really only good for informal conversation, since the Slack message history quickly disappears. Longer more substantive conversations should take place on Discourse and/or Zulip, where the history will always be available.
For what it is worth, specifying https://julialang.org/ as your homepage doesn’t really mean anything. Anyone can put any URL as the homepage of their GitHub organization without any verification.
Now if you have the green verified badge from GitHub, then that does mean that you have verified (by some definition of the word “verified”) that you control (by some very vague definition of the word “control”) that domain. But the homepage without the green verified badge means nothing.
Maybe one thing to add is that GitHub workflows are not incompatible with a somewhat secure chain of code, because you can see all the steps in your workflow and lock down the versions of each bit of code called. (You are still trusting GitHub to actually execute the workflow as specified of course).
For example, now that Github Actions provides Julia in the standard image, the CompatHelper workflow does not actually need to even use setup-julia and just uses the Julia package manager to install the Julia package CompatHelper.jl (if it did though, you could specify exactly which version of setup-julia to use, and audit that code, etc). So one thing you can do is install CompatHelper in some local environment to get a Manifest.toml, audit all the code of CompatHelper and its dependencies as of the versions specified in the Manifest, and then upload the Manifest somewhere to your repo and tweak the CompatHelper workflow to use that Manifest. Then you should have visiblity into every bit of code that is running. (I think at that point you are just trusting the Julia General registry maintainers and GitHub).
@ericphanson It would be great to add this to the CompatHelper documentation. Could you make a PR? Probably we can start with exactly this text that you wrote, and then we can elaborate/add examples down the line.
Just to clarify, I am fully aware of that; I actually meant to write that they should set a homepage and have it verified, but now see I didn’t write that sigh.
Right now, none of the orgs I listed has that, other than the JuliaLang one, and people can only “trust” the others based on reputation / here say “this package I trust by the Julia devs uses JuliaCI, so it must be legit”. But this is rather fragile.
I am not saying that adding verified homepages pointing at a “trusted” URL (as opposed to e.g. https://julia.mydomain.org) is sufficient for that, but I think it is necessary as a first step. Could be to a subdomain of julialang.org; say trusted-org.julialang.org. Of course the Julia devs will likely want to limit this to things they really are closely related to. But maybe at least for things that are run as part of CI and other automation by thousands of repos out there, one could try to provide at least some measure of “apparent trustworthiness”, somehow?