# Moving away from "manual JLL packages" in the General registry

**URL:** <https://discourse.julialang.org/t/moving-away-from-manual-jll-packages-in-the-general-registry/135754>\
**Category:** Internals & Design\
**Created:** [February 20, 2026, 5:18pm UTC](https://discourse.julialang.org/t/moving-away-from-manual-jll-packages-in-the-general-registry/135754 "2026-02-20T17:18:02Z")\
**Posts on this page:** 14\
**Page:** 2

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [February 25, 2026, 9:07am UTC](https://discourse.julialang.org/t/moving-away-from-manual-jll-packages-in-the-general-registry/135754/21 "2026-02-25T09:07:54Z")

</div>

For what is worth, for some time I considered to create the [JLL for the open source bindings of a proprietary vendor SDK](https://github.com/JuliaIPU/IPUToolkit.jl/issues/18). Because of _reasons_, this couldn’t work in Yggdrasil, but I have a [working prototype of a workflow in an external repository](https://github.com/JuliaIPU/IPUToolkit.jl/pull/48). Now, because of _reasons_ I’m not going to pursue this further, but I just wanted to show an arguably legitimate case where I believe the JLL couldn’t reasonably be produced in Yggdrasil, but I don’t understand why this should be banned altogether.

---

<div class="post-metadata">

**Author:** ![goerz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/goerz/32/3269_2.png) [@goerz](https://discourse.julialang.org/u/goerz)\
**Post date:** [February 25, 2026, 1:46pm UTC](https://discourse.julialang.org/t/moving-away-from-manual-jll-packages-in-the-general-registry/135754/22 "2026-02-25T13:46:02Z")

</div>

> [@giordano](#):
>
> Because of _reasons_, this couldn’t work in Yggdrasil

It would be important to be explicit about those reason, so that we can formulate workarounds in the guidelines around this policy. Could you elaborate on this?

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [February 25, 2026, 3:16pm UTC](https://discourse.julialang.org/t/moving-away-from-manual-jll-packages-in-the-general-registry/135754/23 "2026-02-25T15:16:03Z")

</div>

Here are two reasons (that I know) which may preclude the usage of Yggdrasil:

- There may be legal restrictions demanding (or insinuating in a fuzzy way) that we not repackage/redistribute some product. This is Gurobi (the fuzzy flavor, I think).
- There definitely are technical limitations to the BB/Yggdrasil stack. Some compiler toolchains simply aren’t supported.

* * *

I don’t know about the motivations of Dilum and Keno, but I suspect they intersect with mine — I need better provenance and licensing information about artifacts. Centralizing _everything_ under BinaryBuilder+Yggdrasil certainly solves the problem (or at least, points a centralized path towards solving the problem for everyone at once).

That said, for the purposes of provenance, I’m 100% ok with a “manual JLL” like Gurobi\_jll. It’s downloading a tarball built and hosted _directly_ by Gurobi Optimization LLC. The Gurobi EULA, however, is not distributed in the BB-standard fashion (under `./share/licenses/`). This could potentially be addressed by other means.

On the other hand, I’m 100% **not ok** with what I did to PlotlyKaleido.jl. I added a GitHub action that simply grabs mathjax 2.7.9 and plops it into a tarball as a release asset so it can be used as an Artifact. There are three problems with this:

- There’s now a second build system we need to track and trust (in addition to Yggdrasil). Were any of the GHA extensions compromised when this was built?
- I did not do anything with its license
- And perhaps most importantly, it’s unclear _where_ that file came from. While I did put the project name and version into the release name, it’s unstructured and ad-hoc. It’s a whole lot easier to connect a “canonical” URL like `https://cdn.jsdelivr.net/npm/mathjax@2.7.9/MathJax.js` to a known project & version. This is particularly important, because I would very much like to know that PlotlyKaleido contains a component that is vulnerable to [CVE-2023-39663](https://nvd.nist.gov/vuln/detail/CVE-2023-39663) (ok, that CVE is junk, but it’s a good example of the idea).

---

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [February 25, 2026, 4:49pm UTC](https://discourse.julialang.org/t/moving-away-from-manual-jll-packages-in-the-general-registry/135754/24 "2026-02-25T16:49:41Z")

</div>

Is “some vendors _really_, _ **really** _ make the life hard and miserable unless you use the single system they bless (and even when you use that, good luck)” a valid answer?

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [February 25, 2026, 5:08pm UTC](https://discourse.julialang.org/t/moving-away-from-manual-jll-packages-in-the-general-registry/135754/25 "2026-02-25T17:08:21Z")

</div>

I guess boiling this down, this all revolves around one concrete issue with Artifacts: they’re opaque, both in the ends and the means. We require packages to be git-based, for _many_ very good reasons. But Artifacts live _outside_ of that. Unlike package code, there’s no human readable diff between versions. Unlike code, they’re often not human readable at all. Unlike code, there’s often a creation process that’s just as important to know about as the end result. Unlike code, I can’t just fork a git repo and re-host or make a change myself and create a new version.

These are exactly the properties I care about for package registration, not unlike the git-hosted requirement for the code itself. Yggdrasil addresses these challenges; perhaps that’s how we should evaluate the workarounds?

---

<div class="post-metadata">

**Author:** ![nhz2](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nhz2/32/44428_2.png) [@nhz2](https://discourse.julialang.org/u/nhz2)\
**Post date:** [February 25, 2026, 5:27pm UTC](https://discourse.julialang.org/t/moving-away-from-manual-jll-packages-in-the-general-registry/135754/26 "2026-02-25T17:27:36Z")

</div>

I don’t get that, nothing stops packages from committing opaque blobs using git. And nothing stops packages from carefully documenting where the artifacts are coming from.

---

<div class="post-metadata">

**Author:** ![goerz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/goerz/32/3269_2.png) [@goerz](https://discourse.julialang.org/u/goerz)\
**Post date:** [February 25, 2026, 5:44pm UTC](https://discourse.julialang.org/t/moving-away-from-manual-jll-packages-in-the-general-registry/135754/27 "2026-02-25T17:44:02Z")

</div>

> [@giordano](#):
>
> Is “some vendors _really_, _ **really** _ make the life hard and miserable unless you use the single system they bless (and even when you use that, good luck)” a valid answer?

I suppose in that instance, we could end up making an exception. None of the rules for the General registry are ever 100% hard. But we’d at least want to try to push back in a situation of “third party lawyers have no idea what Yggdrasil is, don’t want to hear about it, and are making demands that make no sense, but aren’t budging”. It would be good to think about how one might best communicate with that third party and have some materials prepared to convince them that the standard JLL process is fine. But at the end of the day, if some lawyer absolutely won’t budge, we’ll have to see if an exception is necessary; or decide it’s not worth it, since they’re probably making your life miserable in other ways, too.

Hopefully, that situation will be extremely rare.

---

<div class="post-metadata">

**Author:** ![goerz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/goerz/32/3269_2.png) [@goerz](https://discourse.julialang.org/u/goerz)\
**Post date:** [February 25, 2026, 5:47pm UTC](https://discourse.julialang.org/t/moving-away-from-manual-jll-packages-in-the-general-registry/135754/28 "2026-02-25T17:47:07Z")

</div>

> [@nhz2](#):
>
> nothing stops packages from committing opaque blobs using git

This isn’t checked automatically right now (I think), but opaque binary blobs in a package would definitely be something I’d flag in a package.

---

<div class="post-metadata">

**Author:** ![GunnarFarneback](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gunnarfarneback/32/1827_2.png) [@GunnarFarneback](https://discourse.julialang.org/u/GunnarFarneback)\
**Post date:** [February 25, 2026, 6:13pm UTC](https://discourse.julialang.org/t/moving-away-from-manual-jll-packages-in-the-general-registry/135754/29 "2026-02-25T18:13:39Z")

</div>

That’s a difficult area. There are packages which deal with binary file formats, which legitimately need binary files in their test data. There are also known cases where exactly that has been used to hide malignant payloads in compromised packages (don’t remember which ecosystem, wasn’t Julia).

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [February 25, 2026, 6:37pm UTC](https://discourse.julialang.org/t/moving-away-from-manual-jll-packages-in-the-general-registry/135754/30 "2026-02-25T18:37:31Z")

</div>

Yep, that was the infamous XZ Utils issue, [NVD - CVE-2024-3094](https://nvd.nist.gov/vuln/detail/CVE-2024-3094). It used _both_ an opaque binary blob in a test file _and_ only activated it through _some_ build systems (_and_ required a malicious actor years to build trust and maintainership).

Yggdrasil actually built an XZ with the exploit code, but it wasn’t activated on _that_ build system. [PSA: backdoor in xz-utils and relevance for the Julia ecosystem](https://discourse.julialang.org/t/psa-backdoor-in-xz-utils-and-relevance-for-the-julia-ecosystem/112328)

---

<div class="post-metadata">

**Author:** ![goerz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/goerz/32/3269_2.png) [@goerz](https://discourse.julialang.org/u/goerz)\
**Post date:** [February 25, 2026, 7:10pm UTC](https://discourse.julialang.org/t/moving-away-from-manual-jll-packages-in-the-general-registry/135754/31 "2026-02-25T19:10:42Z")

</div>

> [@GunnarFarneback](#):
>
> There are packages which deal with binary file formats, which legitimately need binary files in their test data

I didn’t mean “the repo can’t contain any binary files”. Of course a package that reads or write MP3s can have `.mp3` files in its tests. I’m talking about packages with `.dll` files in their `src` folder (which people have tried to register).

> [@GunnarFarneback](#):
>
> here are also known cases where exactly that has been used to hide malignant payloads in compromised packages

I don’t think there’s anything that’s bullet-proof for preventing an XZ style attack. That’s just something were people have to be vigilant (and actually, AI’s might be getting pretty good at potentially flagging “there’s something fishy going on here”). That XZ attack _did_ get caught, so that’s actually a success story in my book.

---

<div class="post-metadata">

**Author:** ![dilumaluthge](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dilumaluthge/32/29283_2.png) [@dilumaluthge](https://discourse.julialang.org/u/dilumaluthge)\
**Post date:** [February 28, 2026, 5:18pm UTC](https://discourse.julialang.org/t/moving-away-from-manual-jll-packages-in-the-general-registry/135754/32 "2026-02-28T17:18:44Z")

</div>

I’ve drafted some documentation to answer the questions in this Discourse thread. See my WIP PR here:

> <https://github.com/JuliaRegistries/General/pull/149502>

That PR is the result of internal discussion and review by the registry maintainers. However, some maintainers are still working on reviewing it, so I may make edits/updates based on their feedback.

We can continue to have the discussion in this Discourse thread (no need to move the discussion to the PR).

---

<div class="post-metadata">

**Author:** ![dilumaluthge](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dilumaluthge/32/29283_2.png) [@dilumaluthge](https://discourse.julialang.org/u/dilumaluthge)\
**Post date:** [March 24, 2026, 11:32pm UTC](https://discourse.julialang.org/t/moving-away-from-manual-jll-packages-in-the-general-registry/135754/33 "2026-03-24T23:32:14Z")

</div>

Have folks had a chance to review my documentation (see [my previous post](https://discourse.julialang.org/t/moving-away-from-manual-jll-packages-in-the-general-registry/135754/32))?

Are there outstanding questions that my documentation doesn’t address?

---

<div class="post-metadata">

**Author:** ![odow](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/odow/32/28685_2.png) [@odow](https://discourse.julialang.org/u/odow)\
**Post date:** [March 25, 2026, 12:05am UTC](https://discourse.julialang.org/t/moving-away-from-manual-jll-packages-in-the-general-registry/135754/34 "2026-03-25T00:05:32Z")

</div>

Okay by me.

What happens if I make a Yggdrasil build for Gurobi\_jll/Xpress\_jll etc? I assume that it’ll publish to JuliaBinaryWrappers okay, and then there will be a conflict registering in `General` that we could work-around. Should I try this?

Edit: actually, I guess I can’t do that because of our agreement with upstream about not hosting the binaries.

[Previous page](https://discourse.julialang.org/t/moving-away-from-manual-jll-packages-in-the-general-registry/135754.md?page=1)