# Published VS unpublished // registered vs unregistered

**URL:** <https://discourse.julialang.org/t/published-vs-unpublished-registered-vs-unregistered/34838>\
**Category:** General Usage\
**Created:** [February 19, 2020, 12:18am UTC](https://discourse.julialang.org/t/published-vs-unpublished-registered-vs-unregistered/34838 "2020-02-19T00:18:34Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![markushhh](https://avatars.discourse-cdn.com/v4/letter/m/f1d935/32.png) [@markushhh](https://discourse.julialang.org/u/markushhh)\
**Post date:** [February 19, 2020, 12:18am UTC](https://discourse.julialang.org/t/published-vs-unpublished-registered-vs-unregistered/34838/1 "2020-02-19T00:18:35Z")

</div>

I read a couple of times that “people” tend to trust registered packages. Where does the difference in trust come from? Is a registered package checked for harmful code?  
Do I miss a point?

---

<div class="post-metadata">

**Author:** ![anon94023334](https://avatars.discourse-cdn.com/v4/letter/a/e274bd/32.png) [@anon94023334](https://discourse.julialang.org/u/anon94023334)\
**Post date:** [February 19, 2020, 12:55am UTC](https://discourse.julialang.org/t/published-vs-unpublished-registered-vs-unregistered/34838/2 "2020-02-19T00:55:19Z")

</div>

My understanding is that registration confers no special security accreditation to a package. There are more eyes on making sure things aren’t going to break other packages, and that the requisite configuration / dependency-specifying files are in place, but to my knowledge no code review is performed (at least a code review that looks at security implications).

The trust that people place in registered packages probably stems from the fact that it’s easy to see how many other packages depend on them (via [Julia Observer](https://juliaobserver.com/), for example), and the risk calculation that the more widely-used a package is, the less likely it is to deliberately misbehave.

Edited to add: there’s a great (if often quiescent) channel in Slack called `#pkg-trust` that might be of interest to you and others wishing to discuss this and related issues.

---

<div class="post-metadata">

**Author:** ![Elrod](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/elrod/32/22461_2.png) [@Elrod](https://discourse.julialang.org/u/Elrod)\
**Post date:** [February 19, 2020, 1:54am UTC](https://discourse.julialang.org/t/published-vs-unpublished-registered-vs-unregistered/34838/3 "2020-02-19T01:54:13Z")

</div>

The checks for automatically registering a package are fairly basic. It has to be able to automatically be installed and loaded.

> [@anon94023334](#):
>
> The trust that people place in registered packages probably stems from the fact that it’s easy to see how many other packages depend on them (via [Julia Observer](https://juliaobserver.com/), for example),

FWIW, none of my registered packages show up on JuliaObserver.

---

<div class="post-metadata">

**Author:** ![ericphanson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ericphanson/32/215186_2.png) [@ericphanson](https://discourse.julialang.org/u/ericphanson)\
**Post date:** [February 19, 2020, 2:22am UTC](https://discourse.julialang.org/t/published-vs-unpublished-registered-vs-unregistered/34838/4 "2020-02-19T02:22:42Z")

</div>

One small bit of trust could be that if a registered package was found to have malicious code, the version would be removed (“yanked”) from the registry, so at least you know packages from the registry aren’t known-malicious (which maybe could be different from some git repo found elsewhere on the internet?).

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [February 19, 2020, 7:11am UTC](https://discourse.julialang.org/t/published-vs-unpublished-registered-vs-unregistered/34838/5 "2020-02-19T07:11:20Z")

</div>

No, registered packages are not checked in detail. You may be interested in

> [@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 …