Observer 0.25.2

Observer 0.25.2.

Less code for the same screen

This release changes nothing about what is measured or shown. The dashboard's snapshot projection no longer parses the row key twice: telling same-named rows apart reuses the existing helper, so there is a single place that knows the key's shape.

Tests. The full suite stays green on Windows and Linux, with only the usual platform-specific skips.

The packages are NOT signed

Windows will say so twice, in two different ways, and the two are not fixed
by the same thing:

• User Account Control will show "Unknown publisher". A signature removes
  this immediately, from the first download;
• SmartScreen will warn on first run of the installer. A signature does
  NOT remove this: since March 2024 not even an EV certificate bypasses it.
  It depends on how many clean downloads the file has accumulated, not on the
  certificate it carries.

To go ahead: More info, then Run anyway.

Where this package comes from

Every attached file carries a provenance attestation signed by GitHub, which
ties it to the commit and the workflow that produced it:

gh attestation verify Observer.msi --repo Akr0n/observer

It is not an Authenticode signature and Windows does not look at it. It answers
a different and equally useful question: does this file really come from that
source code, rather than does Windows trust whoever made it.

Windows

Installs the service, the dashboard and the command line. Needs an elevated terminal:

msiexec /i Observer.msi

Nothing else needs installing: the package bundles the .NET runtime, which is
why it weighs about fifty megabytes. Up to 0.2.0 it required ASP.NET Core 10
without checking that it was there, and on a machine without it the service
died at startup while the installer talked about insufficient privileges - a
cause that had nothing to do with the real one.

Note that this means the runtime's security fixes no longer come from
Windows Update. They come with a new Observer release.

If that machine already has an Observer service registered by hand, remove it
first, and empty the installation folder.

Linux

sudo apt install ./observer_0.25.2_amd64.deb

Requires Ubuntu 24.04 or later: aspnetcore-runtime-10.0 comes from the official
archive, so the runtime is not bundled and is updated with the system.

After installing

To watch the machine you are sitting at there is nothing to configure, and no token
is needed: the dashboard uses the local channel. The token and the certificate
fingerprint are needed only so that ANOTHER computer can query this one, and you get
them with observer share.

Observer 0.25.1

Observer 0.25.1.

Less work every second, same screen

This release cuts per-second overhead in the network path and in the dashboard. Nothing about what is measured or shown changes.

Dashboard. Rows whose text did not change are no longer rewritten. A steady "0 B/s" or an idle CPU used to touch every binding once a second; now a row whose label, value, gauge state and severity are identical is left alone, and a panel recomputes its visibility only when it changes.

Linux. Reading /proc/net/dev no longer allocates a string per counter. Only the two byte counters are parsed; the remaining fields are counted to keep the sixteen-field shape check. The only allocation per interface is its name.

Windows. Enumerating the network adapters no longer happens every second. The filtered adapter list is reused for thirty seconds and invalidated at once by the operating system's own network-change notification, so a cable pulled or a Wi-Fi dropped is picked up on the next round. The per-second counters are still read live on every round. A first enumeration that fails reads as a failure, not as a machine with no interfaces.

Tests. Five regression tests pin the new behaviour: an empty interface name and a counter past the 64-bit range are skipped, DOS line endings parse, the Windows provider answers consistently across two reads, and its off-Windows branch stays a clean false.

The packages are NOT signed

Windows will say so twice, in two different ways, and the two are not fixed
by the same thing:

• User Account Control will show "Unknown publisher". A signature removes
  this immediately, from the first download;
• SmartScreen will warn on first run of the installer. A signature does
  NOT remove this: since March 2024 not even an EV certificate bypasses it.
  It depends on how many clean downloads the file has accumulated, not on the
  certificate it carries.

To go ahead: More info, then Run anyway.

Where this package comes from

Every attached file carries a provenance attestation signed by GitHub, which
ties it to the commit and the workflow that produced it:

gh attestation verify Observer.msi --repo Akr0n/observer

It is not an Authenticode signature and Windows does not look at it. It answers
a different and equally useful question: does this file really come from that
source code, rather than does Windows trust whoever made it.

Windows

Installs the service, the dashboard and the command line. Needs an elevated terminal:

msiexec /i Observer.msi

Nothing else needs installing: the package bundles the .NET runtime, which is
why it weighs about fifty megabytes. Up to 0.2.0 it required ASP.NET Core 10
without checking that it was there, and on a machine without it the service
died at startup while the installer talked about insufficient privileges - a
cause that had nothing to do with the real one.

Note that this means the runtime's security fixes no longer come from
Windows Update. They come with a new Observer release.

If that machine already has an Observer service registered by hand, remove it
first, and empty the installation folder.

Linux

sudo apt install ./observer_0.25.1_amd64.deb

Requires Ubuntu 24.04 or later: aspnetcore-runtime-10.0 comes from the official
archive, so the runtime is not bundled and is updated with the system.

After installing

To watch the machine you are sitting at there is nothing to configure, and no token
is needed: the dashboard uses the local channel. The token and the certificate
fingerprint are needed only so that ANOTHER computer can query this one, and you get
them with observer share.

Observer 0.25.0

Observer 0.25.0.

Network traffic monitoring

The dashboard now shows network traffic. Each network interface appears as two rows in the Usage panel: bytes received per second and bytes sent per second, with the interface name in parentheses.

Windows. The collector uses the system's NetworkInterface API and filters out virtual adapters, filter drivers, and the loopback interface. The loopback interface is filtered because its traffic is internal to the machine and does not represent real network activity.

Linux. The collector reads /proc/net/dev and filters out the loopback interface for the same reason.

How it appears. Each interface shows two rows: "Network in" (bytes received per second) and "Network out" (bytes sent per second). When an interface has no traffic, the rows show "0 B/s". The collector samples every second and computes the rate from the difference between consecutive samples, like disk activity.

Why not gauges. Network metrics appear as text rows in the Usage panel, not as gauges. A rate (bytes per second) has no natural maximum, so a gauge would suggest a limit that does not exist. The project philosophy is: "A value that is not a fraction of a maximum is read, not glanced at". Network and disk activity metrics follow this rule: they are read as text, not glanced at as gauges.

Unsupported platforms. On platforms where network interfaces cannot be read, the collector reports itself as unsupported and the dashboard shows no network rows. This is information, not a fault.

Regression tests. Three tests verify that bytes-per-second metrics do not become gauges: Fraction_WithARateValue_ReturnsNull, Fraction_WithAPercentage_ReturnsTheFraction, and Fraction_WithBytes_ReturnsNull. These tests protect the project philosophy and prevent the same bug from recurring.

The packages are NOT signed

Windows will say so twice, in two different ways, and the two are not fixed
by the same thing:

• User Account Control will show "Unknown publisher". A signature removes
  this immediately, from the first download;
• SmartScreen will warn on first run of the installer. A signature does
  NOT remove this: since March 2024 not even an EV certificate bypasses it.
  It depends on how many clean downloads the file has accumulated, not on the
  certificate it carries.

To go ahead: More info, then Run anyway.

Where this package comes from

Every attached file carries a provenance attestation signed by GitHub, which
ties it to the commit and the workflow that produced it:

gh attestation verify Observer.msi --repo Akr0n/observer

It is not an Authenticode signature and Windows does not look at it. It answers
a different and equally useful question: does this file really come from that
source code, rather than does Windows trust whoever made it.

Windows

Installs the service, the dashboard and the command line. Needs an elevated terminal:

msiexec /i Observer.msi

Nothing else needs installing: the package bundles the .NET runtime, which is
why it weighs about fifty megabytes. Up to 0.2.0 it required ASP.NET Core 10
without checking that it was there, and on a machine without it the service
died at startup while the installer talked about insufficient privileges - a
cause that had nothing to do with the real one.

Note that this means the runtime's security fixes no longer come from
Windows Update. They come with a new Observer release.

If that machine already has an Observer service registered by hand, remove it
first, and empty the installation folder.

Linux

sudo apt install ./observer_0.25.0_amd64.deb

Requires Ubuntu 24.04 or later: aspnetcore-runtime-10.0 comes from the official
archive, so the runtime is not bundled and is updated with the system.

After installing

To watch the machine you are sitting at there is nothing to configure, and no token
is needed: the dashboard uses the local channel. The token and the certificate
fingerprint are needed only so that ANOTHER computer can query this one, and you get
them with observer share.

Observer 0.24.5

Observer 0.24.5.

Linux: root no longer follows or waits on what the service account puts in /etc/observer

Mostly Linux (.deb). On Windows, the package changes in its version number and in a few small things, listed at the end.

What was wrong. sudo observer share, rotate-key and doctor run as root inside /etc/observer, which belongs to the observer account the service runs as. They read credentials.json and certificate.pfx with the ordinary file calls. An attacker who had already taken over that account could put something else where those files belong. Measured with 0.24.4 run as root: a FIFO made the command wait for ever, a link to /dev/zero made it run out of memory, a socket ended in an unhandled exception, and a link to a file only root can read was read as root. When that file happened to be shaped like the store, share printed its secret, and a plain rotate-key (not --now) copied it into previous in the new store, which the observer account can read. Nothing in the package made the account easier to take over; this closes what root did once it had been.

What changes. Root opens each file once, never through a link at the file's own name, asks the open file what it is, and only then reads it, up to 64 KiB. A link, a FIFO, a device, a directory, a socket or a file over 64 KiB is refused with a sentence that says which, and nothing of it is read. So is a file with a second name (a hard link) that belongs to another account than the folder; the service's own file with a backup name next to it is read as before. rotate-key writes nothing when it refuses, and says that nothing was rotated. doctor says that what is where the store belongs is not a regular file, is over 64 KiB, or has a second name of another account, and offers no chown for it, because a chown changes the file behind the other name too, which may be root's. It also waits at most its own time limit for the local channel, and reports a socket whose queue of connections is full as STUCK. The answer of the local channel is read up to 64 KiB, and control characters in what it says are shown as ?. share and rotate-key refuse a token that holds a character a terminal acts on, and print nothing of it; the text of a damaged store's error, which may quote a key of the file, is shown without such characters too.

rotate-key --now does not need what the old store holds. It writes a store with nothing of the old one in it, so a link or a FIFO at that name, a store that cannot be parsed and one that holds something that is not a token no longer stop it: it says that the old store was not read, and replaces the name, never what a link pointed to. An access denied still stops it, because the write would fail for the same reason. A plain rotate-key carries the old key over and still refuses all of these.

If a command now refuses. If you made the link or the extra name yourself, the refusal is deliberate: read what it points at with sudo cat <that file>. If you did not, stop the service (sudo systemctl stop observer), look with sudo ls -l /etc/observer, remove what does not belong and start it again. Removing credentials.json makes the service create a new token, and every dashboard that holds the old one stops connecting until it is given the new one. Removing certificate.pfx makes it create a new certificate: the fingerprint changes, and observer share shows the new one. If the sentence says that nothing is known to be wrong with the file, this machine could not check it: do not delete it, look at it with the two commands the sentence gives, and report what uname -m and uname -r print.

Unchanged. The packaged service is not root and reads its own folder as before, and so does root in a folder that root owns. A service started by hand as root in a folder another account owns now refuses to start, with one sentence, when the store or the certificate is a file root will not read or could not check. A file that is not there is reported as before.

On Windows, rotate-key --now no longer stops on a store it cannot parse; share and rotate-key refuse a token that holds a control character; rotate-key says that nothing was rotated when it does not rotate; and the answer of the local channel is read up to 64 KiB. Nothing else changes.

Not fixed here. rotate-key --now and doctor talk to the running service through a socket in /run/observer, a folder the same account controls, so a taken-over account can answer for the service, and its answer still reads as a verdict. A FUSE file system mounted by that account (off by default on most systems) can lie about who owns a folder. With fs.protected_hardlinks=0 (not the default on Debian and Ubuntu) a link count is only a snapshot. Only x86-64 was measured: on other architectures a wrong value of O_NOFOLLOW makes root refuse to read, and does not make it follow. A directory planted at credentials.json.new stops a rotation with the error the write gives. Until these have their own changes, treat "the old key is refused" as true only if you trust the service account.

The packages are NOT signed

Windows will say so twice, in two different ways, and the two are not fixed
by the same thing:

• User Account Control will show "Unknown publisher". A signature removes
  this immediately, from the first download;
• SmartScreen will warn on first run of the installer. A signature does
  NOT remove this: since March 2024 not even an EV certificate bypasses it.
  It depends on how many clean downloads the file has accumulated, not on the
  certificate it carries.

To go ahead: More info, then Run anyway.

Where this package comes from

Every attached file carries a provenance attestation signed by GitHub, which
ties it to the commit and the workflow that produced it:

gh attestation verify Observer.msi --repo Akr0n/observer

It is not an Authenticode signature and Windows does not look at it. It answers
a different and equally useful question: does this file really come from that
source code, rather than does Windows trust whoever made it.

Windows

Installs the service, the dashboard and the command line. Needs an elevated terminal:

msiexec /i Observer.msi

Nothing else needs installing: the package bundles the .NET runtime, which is
why it weighs about fifty megabytes. Up to 0.2.0 it required ASP.NET Core 10
without checking that it was there, and on a machine without it the service
died at startup while the installer talked about insufficient privileges - a
cause that had nothing to do with the real one.

Note that this means the runtime's security fixes no longer come from
Windows Update. They come with a new Observer release.

If that machine already has an Observer service registered by hand, remove it
first, and empty the installation folder.

Linux

sudo apt install ./observer_0.24.5_amd64.deb

Requires Ubuntu 24.04 or later: aspnetcore-runtime-10.0 comes from the official
archive, so the runtime is not bundled and is updated with the system.

After installing

To watch the machine you are sitting at there is nothing to configure, and no token
is needed: the dashboard uses the local channel. The token and the certificate
fingerprint are needed only so that ANOTHER computer can query this one, and you get
them with observer share.

Observer 0.24.4

Observer 0.24.4.

Windows: a corrected recovery line, and what a refused start looks like

Windows only. The Linux package changes only in its version number.

What was wrong. When the service refuses a credential folder that nothing vouches for (0.24.1 and later), the message it writes to the Windows Application log tells you, if Windows will not let you delete the folder, to run takeown /F "<folder>" /A /R /D Y. The /D option takes the letter for "yes" of the language of Windows, so on every Windows that is not English the Y is rejected with a syntax error and the line does nothing. It now says takeown /F "<folder>" /A /R, and that takeown may ask a yes/no question in the language of Windows: answer yes.

What else changes in that message. A folder the service cannot list counts as not empty. An empty folder whose owner took SYSTEM out of its permissions was refused with "is not empty" and sent whoever read it looking for files that are not there; the message now says why, and observer doctor says that the service does not replace such a folder. The recovery is the same three icacls lines as for any refused folder, in the README under Packages.

What a refusal looks like, measured. On a real machine, with the recovery actions the package sets (restart after five seconds) applied by hand to a throwaway service, Windows did not retry a refused start in the 40 seconds that were watched: starting the service waited about 30 seconds and failed with error 1053, and the reason was in the Application log (source .NET Runtime, event 1026) and nowhere the System log points to. The service stayed stopped for as long as it was watched, so plan on starting it yourself once the folder is fixed. Not tried: a service that crashes after it has started, the start at boot, and an MSI upgrade that rolls back with error 1920.

No action needed. Nothing about the token, the certificate or who can read them changes.

The packages are NOT signed

Windows will say so twice, in two different ways, and the two are not fixed
by the same thing:

• User Account Control will show "Unknown publisher". A signature removes
  this immediately, from the first download;
• SmartScreen will warn on first run of the installer. A signature does
  NOT remove this: since March 2024 not even an EV certificate bypasses it.
  It depends on how many clean downloads the file has accumulated, not on the
  certificate it carries.

To go ahead: More info, then Run anyway.

Where this package comes from

Every attached file carries a provenance attestation signed by GitHub, which
ties it to the commit and the workflow that produced it:

gh attestation verify Observer.msi --repo Akr0n/observer

It is not an Authenticode signature and Windows does not look at it. It answers
a different and equally useful question: does this file really come from that
source code, rather than does Windows trust whoever made it.

Windows

Installs the service, the dashboard and the command line. Needs an elevated terminal:

msiexec /i Observer.msi

Nothing else needs installing: the package bundles the .NET runtime, which is
why it weighs about fifty megabytes. Up to 0.2.0 it required ASP.NET Core 10
without checking that it was there, and on a machine without it the service
died at startup while the installer talked about insufficient privileges - a
cause that had nothing to do with the real one.

Note that this means the runtime's security fixes no longer come from
Windows Update. They come with a new Observer release.

If that machine already has an Observer service registered by hand, remove it
first, and empty the installation folder.

Linux

sudo apt install ./observer_0.24.4_amd64.deb

Requires Ubuntu 24.04 or later: aspnetcore-runtime-10.0 comes from the official
archive, so the runtime is not bundled and is updated with the system.

After installing

To watch the machine you are sitting at there is nothing to configure, and no token
is needed: the dashboard uses the local channel. The token and the certificate
fingerprint are needed only so that ANOTHER computer can query this one, and you get
them with observer share.

Observer 0.24.3

Observer 0.24.3.

The packages are NOT signed

Windows will say so twice, in two different ways, and the two are not fixed
by the same thing:

• User Account Control will show "Unknown publisher". A signature removes
  this immediately, from the first download;
• SmartScreen will warn on first run of the installer. A signature does
  NOT remove this: since March 2024 not even an EV certificate bypasses it.
  It depends on how many clean downloads the file has accumulated, not on the
  certificate it carries.

To go ahead: More info, then Run anyway.

Where this package comes from

Every attached file carries a provenance attestation signed by GitHub, which
ties it to the commit and the workflow that produced it:

gh attestation verify Observer.msi --repo Akr0n/observer

It is not an Authenticode signature and Windows does not look at it. It answers
a different and equally useful question: does this file really come from that
source code, rather than does Windows trust whoever made it.

Windows

Installs the service, the dashboard and the command line. Needs an elevated terminal:

msiexec /i Observer.msi

Nothing else needs installing: the package bundles the .NET runtime, which is
why it weighs about fifty megabytes. Up to 0.2.0 it required ASP.NET Core 10
without checking that it was there, and on a machine without it the service
died at startup while the installer talked about insufficient privileges - a
cause that had nothing to do with the real one.

Note that this means the runtime's security fixes no longer come from
Windows Update. They come with a new Observer release.

If that machine already has an Observer service registered by hand, remove it
first, and empty the installation folder.

Linux

sudo apt install ./observer_0.24.3_amd64.deb

Requires Ubuntu 24.04 or later: aspnetcore-runtime-10.0 comes from the official
archive, so the runtime is not bundled and is updated with the system.

After installing

To watch the machine you are sitting at there is nothing to configure, and no token
is needed: the dashboard uses the local channel. The token and the certificate
fingerprint are needed only so that ANOTHER computer can query this one, and you get
them with observer share.

Observer 0.24.2

Observer 0.24.2.

Linux: sudo observer rotate-key could leave the service unable to start

Linux (.deb) only, every release since 0.1.2. The Windows package is not affected: it gives the store an explicit permission list when the file is created, and that list names SYSTEM, the account the service runs as, whoever creates the file.

What was wrong. The service runs as the observer account and keeps its machine token in /etc/observer/credentials.json. sudo observer rotate-key runs as root, and the file it wrote to replace the token belonged to root. The account the service runs as could no longer read its own store: the running service carried on, but its next start failed and it restarted in a loop until the file was repaired by hand. Since 0.24.0, observer rotate-key --now also reported DID NOT APPLY and advised restarting the service, which is the step that made it fail.

Are you affected? If you ran sudo observer rotate-key on a Linux machine with an earlier .deb. ls -l /etc/observer/credentials.json shows it: the owner is root instead of observer.

What to do. Install the .deb attached to this release. Upgrading gives the file back to observer before it restarts the service, so a machine already in that state starts working again. Without upgrading:

sudo chown observer:observer /etc/observer/credentials.json
sudo systemctl restart observer

The file holds the token the rotation wrote, so the service uses that one once it runs again; sudo observer share prints it.

After upgrading. sudo observer rotate-key leaves the store owned by observer. If root cannot hand the new file over, the command stops with an error, says nothing was rotated, and the store that was working stays as it was.

The packages are NOT signed

Windows will say so twice, in two different ways, and the two are not fixed
by the same thing:

• User Account Control will show "Unknown publisher". A signature removes
  this immediately, from the first download;
• SmartScreen will warn on first run of the installer. A signature does
  NOT remove this: since March 2024 not even an EV certificate bypasses it.
  It depends on how many clean downloads the file has accumulated, not on the
  certificate it carries.

To go ahead: More info, then Run anyway.

Where this package comes from

Every attached file carries a provenance attestation signed by GitHub, which
ties it to the commit and the workflow that produced it:

gh attestation verify Observer.msi --repo Akr0n/observer

It is not an Authenticode signature and Windows does not look at it. It answers
a different and equally useful question: does this file really come from that
source code, rather than does Windows trust whoever made it.

Windows

Installs the service, the dashboard and the command line. Needs an elevated terminal:

msiexec /i Observer.msi

Nothing else needs installing: the package bundles the .NET runtime, which is
why it weighs about fifty megabytes. Up to 0.2.0 it required ASP.NET Core 10
without checking that it was there, and on a machine without it the service
died at startup while the installer talked about insufficient privileges - a
cause that had nothing to do with the real one.

Note that this means the runtime's security fixes no longer come from
Windows Update. They come with a new Observer release.

If that machine already has an Observer service registered by hand, remove it
first, and empty the installation folder.

Linux

sudo apt install ./observer_0.24.2_amd64.deb

Requires Ubuntu 24.04 or later: aspnetcore-runtime-10.0 comes from the official
archive, so the runtime is not bundled and is updated with the system.

After installing

To watch the machine you are sitting at there is nothing to configure, and no token
is needed: the dashboard uses the local channel. The token and the certificate
fingerprint are needed only so that ANOTHER computer can query this one, and you get
them with observer share.

Observer 0.24.1

Observer 0.24.1.

Security fix for Windows (0.24.0 and earlier)

Windows only. The Linux package is not affected with its default path: /etc can be written only by root, and the package creates /etc/observer for the account the service runs as.

What was wrong. The service creates C:\ProgramData\Observer the first time it starts and keeps its machine token and certificate there. On Windows any standard user can create a folder under C:\ProgramData and own it. If someone did that first and put a credentials.json or a certificate.pfx inside, every published release up to 0.24.0 repaired the folder's ownership and permissions and then used the file it found: a token that is accepted from the network, and that can also end processes, or a certificate whose private key that person holds. Uninstalling removes the folder, so a reinstall reopens the same chance.

Are you affected? Only if someone else had a local account, or code you did not trust ran as a standard user, on the machine and could create that folder before the service first started. On a machine only you use, and where nothing untrusted has run as a standard user, no.

The folder itself no longer tells you: the old service rewrote its owner and permissions until it looked exactly like its own. The files inside do. The old service repaired the folder only, never the files in it, so a file that was planted keeps its planter as owner, while the service creates credentials.json and certificate.pfx as SYSTEM or Administrators. From an elevated terminal:

Get-ChildItem C:\ProgramData\Observer | ForEach-Object { '{0}  {1}' -f (Get-Acl $_.FullName).GetOwner([Security.Principal.SecurityIdentifier]).Value, $_.Name }

S-1-5-18 is SYSTEM and S-1-5-32-544 is Administrators (or the account the service runs as, if it is not LocalSystem). Any other owner on either file means that account put it there.

What to do

1. Upgrade: from an elevated terminal, msiexec /i Observer.msi with the package attached to this release. Your token and certificate are kept. Upgrading does not undo an earlier adoption: whoever planted the files still owns them and can rewrite them.
2. If either file is owned by another account, or you cannot tell: delete C:\ProgramData\Observer\certificate.pfx and C:\ProgramData\Observer\credentials.json, then run Restart-Service Observer. The service creates both again. Every machine that watches this one is cut off until it is given the new fingerprint and token; observer share prints both.

What to expect after upgrading. Usually nothing. The service now refuses to start when the folder is not empty and its owner or permissions are not SYSTEM and Administrators alone, and it changes nothing. That happens to a folder recreated by hand, restored from a backup without its permissions, or left by the service run by hand or under another account. The reason is in the Windows Application event log (source .NET Runtime), and the recovery, three icacls lines, is in the README under Packages. An empty folder that kept the permissions it inherited is replaced with a protected one and the service starts. On a machine in that state the installer may stop with error 1920 and go back to the previous version: fix the folder first, then run the installer again, because restarting the service would only restart the old one.

One weakness remains, and it is availability, not the token: someone who creates the folder and puts anything in it, or a file at that path, or who takes SYSTEM out of the permissions of an empty folder they own, can keep the service from starting until an administrator clears it.

The packages are NOT signed

Windows will say so twice, in two different ways, and the two are not fixed
by the same thing:

• User Account Control will show "Unknown publisher". A signature removes
  this immediately, from the first download;
• SmartScreen will warn on first run of the installer. A signature does
  NOT remove this: since March 2024 not even an EV certificate bypasses it.
  It depends on how many clean downloads the file has accumulated, not on the
  certificate it carries.

To go ahead: More info, then Run anyway.

Where this package comes from

Every attached file carries a provenance attestation signed by GitHub, which
ties it to the commit and the workflow that produced it:

gh attestation verify Observer.msi --repo Akr0n/observer

It is not an Authenticode signature and Windows does not look at it. It answers
a different and equally useful question: does this file really come from that
source code, rather than does Windows trust whoever made it.

Windows

Installs the service, the dashboard and the command line. Needs an elevated terminal:

msiexec /i Observer.msi

Nothing else needs installing: the package bundles the .NET runtime, which is
why it weighs about fifty megabytes. Up to 0.2.0 it required ASP.NET Core 10
without checking that it was there, and on a machine without it the service
died at startup while the installer talked about insufficient privileges - a
cause that had nothing to do with the real one.

Note that this means the runtime's security fixes no longer come from
Windows Update. They come with a new Observer release.

If that machine already has an Observer service registered by hand, remove it
first, and empty the installation folder.

Linux

sudo apt install ./observer_0.24.1_amd64.deb

Requires Ubuntu 24.04 or later: aspnetcore-runtime-10.0 comes from the official
archive, so the runtime is not bundled and is updated with the system.

After installing

To watch the machine you are sitting at there is nothing to configure, and no token
is needed: the dashboard uses the local channel. The token and the certificate
fingerprint are needed only so that ANOTHER computer can query this one, and you get
them with observer share.

Observer 0.24.0

Observer 0.24.0.

The packages are NOT signed

Windows will say so twice, in two different ways, and the two are not fixed
by the same thing:

• User Account Control will show "Unknown publisher". A signature removes
  this immediately, from the first download;
• SmartScreen will warn on first run of the installer. A signature does
  NOT remove this: since March 2024 not even an EV certificate bypasses it.
  It depends on how many clean downloads the file has accumulated, not on the
  certificate it carries.

To go ahead: More info, then Run anyway.

Where this package comes from

Every attached file carries a provenance attestation signed by GitHub, which
ties it to the commit and the workflow that produced it:

gh attestation verify Observer.msi --repo Akr0n/observer

It is not an Authenticode signature and Windows does not look at it. It answers
a different and equally useful question: does this file really come from that
source code, rather than does Windows trust whoever made it.

Windows

Installs the service, the dashboard and the command line. Needs an elevated terminal:

msiexec /i Observer.msi

Nothing else needs installing: the package bundles the .NET runtime, which is
why it weighs about fifty megabytes. Up to 0.2.0 it required ASP.NET Core 10
without checking that it was there, and on a machine without it the service
died at startup while the installer talked about insufficient privileges - a
cause that had nothing to do with the real one.

Note that this means the runtime's security fixes no longer come from
Windows Update. They come with a new Observer release.

If that machine already has an Observer service registered by hand, remove it
first, and empty the installation folder.

Linux

sudo apt install ./observer_0.24.0_amd64.deb

Requires Ubuntu 24.04 or later: aspnetcore-runtime-10.0 comes from the official
archive, so the runtime is not bundled and is updated with the system.

After installing

To watch the machine you are sitting at there is nothing to configure, and no token
is needed: the dashboard uses the local channel. The token and the certificate
fingerprint are needed only so that ANOTHER computer can query this one, and you get
them with observer share.

Observer 0.23.1

Observer 0.23.1.

The packages are NOT signed

Windows will say so twice, in two different ways, and the two are not fixed
by the same thing:

• User Account Control will show "Unknown publisher". A signature removes
  this immediately, from the first download;
• SmartScreen will warn on first run of the installer. A signature does
  NOT remove this: since March 2024 not even an EV certificate bypasses it.
  It depends on how many clean downloads the file has accumulated, not on the
  certificate it carries.

To go ahead: More info, then Run anyway.

Where this package comes from

Every attached file carries a provenance attestation signed by GitHub, which
ties it to the commit and the workflow that produced it:

gh attestation verify Observer.msi --repo Akr0n/observer

It is not an Authenticode signature and Windows does not look at it. It answers
a different and equally useful question: does this file really come from that
source code, rather than does Windows trust whoever made it.

Windows

Installs the service, the dashboard and the command line. Needs an elevated terminal:

msiexec /i Observer.msi

Nothing else needs installing: the package bundles the .NET runtime, which is
why it weighs about fifty megabytes. Up to 0.2.0 it required ASP.NET Core 10
without checking that it was there, and on a machine without it the service
died at startup while the installer talked about insufficient privileges - a
cause that had nothing to do with the real one.

Note that this means the runtime's security fixes no longer come from
Windows Update. They come with a new Observer release.

If that machine already has an Observer service registered by hand, remove it
first, and empty the installation folder.

Linux

sudo apt install ./observer_0.23.1_amd64.deb

Requires Ubuntu 24.04 or later: aspnetcore-runtime-10.0 comes from the official
archive, so the runtime is not bundled and is updated with the system.

After installing

To watch the machine you are sitting at there is nothing to configure, and no token
is needed: the dashboard uses the local channel. The token and the certificate
fingerprint are needed only so that ANOTHER computer can query this one, and you get
them with observer share.