# Plethora of Julia related GitHub organizations and how to know which of them are "official"
**URL:** https://discourse.julialang.org/t/plethora-of-julia-related-github-organizations-and-how-to-know-which-of-them-are-official/37967
**Category:** Community
**Created:** [April 21, 2020, 2:42pm UTC](https://discourse.julialang.org/t/plethora-of-julia-related-github-organizations-and-how-to-know-which-of-them-are-official/37967 "2020-04-21T14:42:31Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@fingolfin](https://discourse.julialang.org/u/fingolfin)
#### Post date: [April 21, 2020, 2:42pm UTC](https://discourse.julialang.org/t/plethora-of-julia-related-github-organizations-and-how-to-know-which-of-them-are-official/37967/1 "2020-04-21T14:42:31Z")
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:
- [The Julia Programming Language · GitHub](https://github.com/JuliaLang)
- [Julia Registries · GitHub](https://github.com/JuliaRegistries)
- [https://github.com/JuliaBinaryWrappers](https://github.com/JuliaBinaryWrappers)
- [https://github.com/JuliaInterop](https://github.com/JuliaInterop)
- [Julia CI (Continuous Integration) · GitHub](https://github.com/JuliaCI)
- [Julia Actions · GitHub](https://github.com/julia-actions)
and certainly many more. Some of them specify [https://julialang.org/](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](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](https://github.com/JuliaActions) and putting the content of [Julia Actions · GitHub](https://github.com/julia-actions) 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.
So, some questions:
- Are there any “officially endorsed” (say, by the Julia stewards) GitHub organizations beyond \< [The Julia Programming Language · GitHub](https://github.com/JuliaLang)\>?
- If so, which are they, and how can one find out?
- If there are others, perhaps they could be marked as such by stating this in their description, and perhaps by also adding a “verified domain name”.
- If there are none, resp. if not all of the above are “official”: Maybe they should be asked to not list [https://julialang.org](https://julialang.org/) as their homepage?
---
### Author:  [@dilumaluthge](https://discourse.julialang.org/u/dilumaluthge)
#### Post date: [April 21, 2020, 7:14pm UTC](https://discourse.julialang.org/t/plethora-of-julia-related-github-organizations-and-how-to-know-which-of-them-are-official/37967/2 "2020-04-21T19:14:06Z")
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.
---
### Author:  [@dilumaluthge](https://discourse.julialang.org/u/dilumaluthge)
#### Post date: [April 21, 2020, 7:16pm UTC](https://discourse.julialang.org/t/plethora-of-julia-related-github-organizations-and-how-to-know-which-of-them-are-official/37967/3 "2020-04-21T19:16:44Z")
Currently, GitHub really only offers one method of verifying the ownership of a GitHub organization: domain verification.
It would be great if all Julia-related organizations could verify at least one domain name.
---
### Author:  [@dilumaluthge](https://discourse.julialang.org/u/dilumaluthge)
#### Post date: [April 21, 2020, 7:21pm UTC](https://discourse.julialang.org/t/plethora-of-julia-related-github-organizations-and-how-to-know-which-of-them-are-official/37967/4 "2020-04-21T19:21:13Z")
> [@fingolfin](#):
>
> Some of them specify [https://julialang.org/](https://julialang.org/) as their homepage.
For what it is worth, specifying [https://julialang.org/](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.
---
### Author:  [@ericphanson](https://discourse.julialang.org/u/ericphanson)
#### Post date: [April 21, 2020, 8:16pm UTC](https://discourse.julialang.org/t/plethora-of-julia-related-github-organizations-and-how-to-know-which-of-them-are-official/37967/5 "2020-04-21T20:16:26Z")
> [@dilumaluthge](#):
>
> 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.
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).
---
### Author:  [@dilumaluthge](https://discourse.julialang.org/u/dilumaluthge)
#### Post date: [April 21, 2020, 8:19pm UTC](https://discourse.julialang.org/t/plethora-of-julia-related-github-organizations-and-how-to-know-which-of-them-are-official/37967/6 "2020-04-21T20:19:56Z")
> [@ericphanson](#):
>
> 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.
---
### Author:  [@ericphanson](https://discourse.julialang.org/u/ericphanson)
#### Post date: [April 21, 2020, 9:15pm UTC](https://discourse.julialang.org/t/plethora-of-julia-related-github-organizations-and-how-to-know-which-of-them-are-official/37967/7 "2020-04-21T21:15:55Z")
Sure, I’ll make a PR. Maybe we can set up an example repo showing how to use a manifest too, or just describe it in more detail.
---
### Author:  [@fingolfin](https://discourse.julialang.org/u/fingolfin)
#### Post date: [April 28, 2020, 1:02pm UTC](https://discourse.julialang.org/t/plethora-of-julia-related-github-organizations-and-how-to-know-which-of-them-are-official/37967/8 "2020-04-28T13:02:41Z")
> [@dilumaluthge](#):
>
> For what it is worth, specifying [https://julialang.org/](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.
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?
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [April 29, 2020, 6:31am UTC](https://discourse.julialang.org/t/plethora-of-julia-related-github-organizations-and-how-to-know-which-of-them-are-official/37967/9 "2020-04-29T06:31:13Z")
> [@fingolfin](#):
>
> But this is rather fragile.
A somewhat related discussion is
> [@Pkg: attack vectors](https://discourse.julialang.org/t/pkg-attack-vectors/18340):
>
> [Pkg ecosystem: Learning from other's mistakes](https://discourse.julialang.org/t/pkg-ecosystem-learning-from-others-mistakes/18028) has gotten a bit long and wandering, as these discussions tend to. I’d like to have a very focused thread about attack vectors against the security of the package ecosystem. To that end, here are the attack vectors I’ve come up with so far. What are some other attack vectors? Attack: find an existing bug in some package that you can exploit Mitigation: fix the bug yank versions that have it Prevention: testing fuzzing basically anything that …