The companion to the DSC Hub reference documentation, for readers who want the whole picture. [more]
[hide]
DSC Hub sends nothing about you
It only reads from our server: the catalog, the packages you pick and module icons. Nothing about you, your modules, your licenses or your computer is ever sent. No telemetry, no analytics, no account. The one exception is yours to start: asking for a lost key sends the bundle code and e-mail you type.
[hide]
Everything DSC Hub knows about Deep Sky Colors processes comes from one file it downloads from the Deep Sky Colors server. That file lists each process, its title and description, what changed in its latest release, the version published for each operating system and each PixInsight version range, and the checksum of every package.
The file carries a digital signature over its entire contents. DSC Hub verifies that signature before it believes a single line, so a file that was altered anywhere on its way to you is refused and the previous list stays in place. When the server cannot be reached at all, DSC Hub falls back to the list of processes built into it, which is enough to show what you have installed and how your licenses stand.
Because each package is listed with its own version, platforms can move independently: a fix that only affects Linux can be published for Linux alone, and the table shows the version that applies to the PixInsight you are running.
[hide]
Each row is one process: its name, the version installed on your computer, the version available to you, its status, and its license. What is installed is read from PixInsight's own module folder, not remembered from a previous session, so a module installed or removed by any other means is reported correctly.
A module removed through PixInsight returns to Not installed, but not immediately: PixInsight schedules a disabled module for removal and carries it out at the next start, so until then the row still reads as installed and DSC Hub is right to say so. It reports the removal on the Process Console at that next start.
This is the one status that arrives from outside DSC Hub, which is why it is read rather than remembered. What is installed comes from three sources, in order of authority: the processes this PixInsight has actually loaded, which proves a module works rather than merely being listed; PixInsight's own module list, which is only as current as its last exit; and the binary on disk, which an uninstall leaves behind and which therefore cannot be trusted on its own.
An installed row whose license can be acted on carries the words Get your license, or Update your key when you already hold one, and the cell opens that page when clicked. Rows for processes you have not installed carry no such link, since there is nothing yet to license.
Clicking a column header sorts by it, and clicking again reverses the order. The order the window opens in is a preference, and one of the choices is Importance, which is not a column: it puts what deserves your attention first, from packages already downloaded, through updates available, to what is merely up to date.
The Show box narrows the table to everything, to what is installed, or to the contents of one bundle. The panel under the table describes the selected process and lists what changed in the version being offered. The divider between table and panel can be dragged to give either one more room.
[hide]
Selecting one or more rows and clicking Download and install downloads each package into DSC Hub's own folder under your user data, in a downloads subfolder, and records the queue in a file named pending.txt beside it. Progress is reported on the Process Console, and cancelling abandons only the download in flight: whatever was already verified stays queued.
Every package is proved authentic twice, by two independent mechanisms with two different keys: once by DSC Hub when it lands, and once by PixInsight when it loads.
When it lands. Every downloaded package is hashed and compared with the checksum published for it in the catalog. A package that does not match is discarded and reported, and nothing is installed from it. The catalog carries its own signature over its entire contents, so the checksum cannot be altered either: the bytes installed are the bytes Deep Sky Colors published.
When it loads. Every Deep Sky Colors module ships with the code signature PixInsight requires, and PixInsight checks it at every start, whatever put the files on disk. This is not something DSC Hub performs, or could skip. In PixInsight's own words:
Module signatures are mandatory. When the core application loads a module, it verifies the signature before loading the shared library, that is, before any code of the module can be executed. If the signature is invalid, the module is rejected. If no signature file exists, the module is rejected as well.
The Allow installation of unsigned modules option is disabled in standard distributions of the core application, so it cannot be used to bypass this requirement.
So a module altered after we published it is refused by PixInsight before a single instruction of it runs, and DSC Hub could not prevent that if it wanted to. Nothing DSC Hub installs bypasses PixInsight's code signing, and the modules it installs are verified on exactly the same terms as modules installed from a repository.
What DSC Hub does replace is the check PixInsight's repository installer makes at download time, when it verifies the Developer and Repository certificates. In its place, the signed catalog and the per-package checksum above do the same work. The signature check at load time is common to both routes and is untouched.
PixInsight's module folder usually belongs to the system, and PixInsight holds its own modules open while it runs, so the files are put in place by a small helper program that ships beside DSC Hub. The helper starts as soon as the downloads are queued and then waits: it does nothing until PixInsight has exited.
Once PixInsight is gone, the helper asks for permission to write into the PixInsight installation. On Windows that is a UAC prompt. On macOS and Linux the helper first tests whether it can write where it needs to, and asks only when it cannot: an administrator password on macOS, the system password dialog on Linux. The prompt comes once for the whole batch, however many processes you selected.
The helper installs only what is in the queue DSC Hub wrote, refuses any path that tries to climb out of PixInsight's own folders, and unpacks nothing it has not verified. Show files in the dialog that follows lists every file that was copied and where it went.
There is one check PixInsight makes for a repository installation that it cannot make for this one. PixInsight keeps a list of protected files, at etc/security/protected, naming 202 files a package may neither contain nor remove: core executables, the updaters, the standard modules and their signatures, every bundled shared library, and the whole etc directory. A repository package that touches any of them is rejected as a failed download. That list is enforced by PixInsight's own package installer, and DSC Hub does not go through it.
So the helper enforces its own equivalent, and it is stricter about where files may land than the protected list is about which files are sacred. Every archive is listed in full before a single byte is written, and the whole package is refused unless every entry sits under bin/, doc/, rsc/, lib/ or src/. An entry carrying a drive letter, a leading slash, or a .. component is refused outright. A package cannot reach etc, or anywhere else outside those five directories, because the helper will not unpack it at all.
This is the second line of defense rather than the first. The packages are ours and their checksums were already checked against the signed catalog before the helper ever saw them, so these rules exist to make a bad package impossible rather than merely unlikely.
A module PixInsight has loaded is in use, and an operating system does not let a file in use be replaced. This is why PixInsight's own updater works the same way, and why nothing is copied while PixInsight is running: the packages are downloaded and verified straight away, and they go in the moment PixInsight closes.
DSC Hub offers to restart PixInsight once the installation has finished. That choice decides only whether PixInsight comes back by itself. The files go in when PixInsight closes either way, and until then the table shows those rows as downloaded.
[hide]
A bundle is bought once and covers several processes, and each process still needs its own license. The purchase e-mail carries all of them at once, as a single multi-license key: one long block of text. Pasting it is the whole job.
The key also carries the bundle code, a short identifier for the purchase itself, which DSC Hub files separately: it is the record that this computer owns the bundle, and it is not a module license. The same code appears at the foot of the purchase e-mail.
The lower half of that window asks for the bundle code, and exists for two cases only: the purchase e-mail was lost, or a process has joined the bundle since it was bought. The code is checked here first, so a typo never reaches the server, and a fresh multi-license key is then sent to the address the bundle was bought with. Nothing is ever returned in the reply itself, only by e-mail, so the window cannot be used to fish for licenses.
When the Show box has a bundle selected and you own no part of it, a Register this bundle link appears beside the box and opens the page where it can be bought. Holding the bundle code is enough to hide that link, as is holding a license for any process in the bundle.
A license lives in two places: PixInsight's own settings, which is where each module reads it, and a small separate store outside PixInsight, which is what allows a key to be recorded for a module that is not installed yet, and allows a module to find its key again after PixInsight's settings have been reset. DSC Hub keeps the two in step, and the License column reflects what the module itself will see.
Nothing else about you is stored. The address you enter is kept only as part of the license, because a key is valid for one address.
[hide]
When PixInsight starts, DSC Hub reads the catalog in the background and compares it with what is installed. An update waiting, or a process that has joined the catalog since your last look, is always written on the Process Console, and optionally shown in a small window with a button that opens DSC Hub. Both notices can be set to the console alone, or turned off, in Preferences.
An update is announced at every start for as long as it is waiting. Nothing is remembered and nothing is suppressed, so the news stops when the update is installed, which is the only thing that settles it. This is how PixInsight announces its own updates.
A new process is different, and is announced once: it is new exactly once, so DSC Hub remembers which ones it has already named and does not repeat them at every start.
A third notice is about PixInsight's repository list rather than about modules: if any of the old per-module Deep Sky Colors repositories is still in it, DSC Hub names how many and offers to review them. That one is not governed by the two settings above, because it is a problem to put right rather than news, and it stops being raised once the repositories are gone. Preferences > Repositories... opens the same window at any time.
These notices never install anything.
[hide]
[hide]
Copyright © 2026 Deep Sky Colors. All Rights Reserved.