# Product Identification & Versioning

This page explains how to **unambiguously identify** the Flopsar product and the exact version of each of its components, and how to **verify the authenticity** of the artifacts you install. Providing the information that lets a user identify the product is an essential requirement of the Cyber Resilience Act (Annex II, point (c)); this page is how we meet it.

## Product identity

* **Product name:** Flopsar
* **Manufacturer:** Flopsar Technology Sp. z o.o.
* **Product type:** fault detection and diagnosis software for JVM systems (software with digital elements). 

"Flopsar" as a product is made up of three separately installable components, which together form the product:

* the **Flopsar Server**,
* the **Flopsar Agent** (loaded into monitored JVMs),
* the **Flopsar Workstation** (the web interface, served by the server). 

When identifying a deployment — in an advisory, a support case, or a conformity record — identify the **component** and its **version**, because the components are versioned and released together as a line but reported individually.

## Versioning scheme

Flopsar uses **semantic versioning**: `MAJOR.MINOR.PATCH` (for example `7.0.0`). A build may also carry **build metadata** after a `+`, for example `7.0.0+dev100`; this identifies the specific build and is informational. Each build additionally records a **build date**.

* **MAJOR** identifies the **product line** (the `7.x` line). Major releases may change behavior and compatibility.
* **MINOR** adds functionality within a line.
* **PATCH** delivers fixes, including security fixes, within a line. 

The version string is fixed at build time and is reported by the product (see below), so what you read from a running component is authoritative.

## Compatibility model

It is important to distinguish two independent kinds of "version" in Flopsar:

* The **product version** (`MAJOR.MINOR.PATCH`, e.g. `7.0.0`) identifies the release. Use it for advisories, the support lifecycle, and reporting issues.
* The **agent–server wire protocol version** is a **separate version number** (the current generation is **protocol v2**). It is carried in the protocol header on the wire and is **decoupled from the product version**. 

Agent–server interoperability is governed by the **protocol version**, not by the product's semantic version. An agent and a server interoperate when they implement the **same protocol version**. Because the protocol version only changes when the wire format itself changes — not on every release — a single protocol version typically spans many product releases. This is what allows agent and server builds from different product versions to work together, as long as they share the protocol version. 

Do **not** infer agent–server compatibility from the semantic version alone. Where a release changes the protocol version or imposes a specific agent/server pairing, that requirement is stated in the release notes and the relevant security advisory. Plan upgrades that cross a protocol-version boundary as a coordinated change of both the agent and the server.

## Determining the version of each component

### Flopsar Server

The server reports its version on the command line and at startup:

```bash
$ flopsar-server --version
```

The startup banner also prints the version and build date, and the `info` subcommand prints deployment/storage information. On a packaged installation you can additionally query the package manager:

{% code expandable="true" %}

```shellscript
# Debian/Ubuntu
$ dpkg -l flopsar-server

# RHEL family
$ rpm -q flopsar-server
```

{% endcode %}

### Flopsar Agent

**On Linux, the agent library is directly executable** — much like `libc.so.6`, which prints its version when run. Execute the agent shared object to print its version and build date:

```bash
./libflopsar.so
```

It prints, then exits:

{% code expandable="true" %}

```
Flopsar Agent <version>
Built: <date> <time>
```

{% endcode %}

This works for the Linux builds (x86\_64 and aarch64) and is the most reliable way to identify exactly which agent build is present on a host, independent of how or where the file was deployed.

Each agent also reports its version to the server when it connects, so connected agents and their versions are visible in the Agents view of the Workstation (subject to the appropriate permission). For other platforms, where the agent is a dynamic library without a direct-execution entry point, identify the deployed build through your asset inventory and the Workstation's Agents view.

Record which agent build is deployed to which host as part of your asset inventory; it is the basis for assessing whether an advisory affects a given agent.

## Verifying the authenticity of artifacts

Identification is only meaningful if the artifact is genuine. Flopsar distributes software through GPG-signed package repositories; verify signatures rather than trusting a file's name alone.

The key is published on the **keys.openpgp.org** keyserver under **<security@flopsar.com>**, so you can fetch and verify it independently:

```bash
gpg --keyserver keys.openpgp.org --search-keys security@flopsar.com
```

Import the key and confirm the fingerprint out of band before trusting the repository. This page is the canonical location for the fingerprint; treat a fingerprint presented anywhere else (including the keyserver copy) as untrusted until checked against the value above.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.flopsar.com/7/security/product-identification-and-versioning.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.