UpdatePage.hpp

1. Overview

The UpdatePage.hpp header defines the UpdatePage class, a GTKmm (GTK4) UI component responsible for managing BastionGuard’s update and signature refresh subsystem. This page provides both manual and automated update controls, integrates with background services, and supports the configuration of multiple update sources with optional authentication.

Functionally, UpdatePage provides:

  • Manual triggering of database and engine updates
  • Service enable/disable control for background update daemons
  • Management of multiple update sources (repositories/endpoints)
  • Support for authenticated sources using secure credential storage
  • Live logging of update operations
  • Optional automatic update scheduling (SaneSecurity integration)
  • Connection testing and validation for configured sources

2. Dependencies and Includes

#include <gtkmm.h>
#include <vector>
#include <string>
  • gtkmm.h – GTK4 widgets, notebook containers, and signal handling
  • <vector> – container for update source definitions
  • <string> – URLs, credentials keys, and log messages

3. Data Structures

3.1 SourceItem

struct SourceItem {
    std::string name;
    std::string url;
    std::string username;
    std::string secret_key;
    bool requires_auth = false;
};

Represents a single update source definition. Each source may optionally require authentication credentials stored in the system keyring.

  • name – human-readable source name
  • url – update endpoint
  • username – authentication username (if required)
  • secret_key – keyring identifier for password lookup
  • requires_auth – indicates whether credentials are needed

4. Class Declaration and Scope

class UpdatePage : public Gtk::Box

The class derives from Gtk::Box, making it suitable as a navigable page within the main application interface.

5. Public Interface

5.1 Constructor and Destructor

UpdatePage();
~UpdatePage();

Initializes the update UI, loads persisted source configurations, and connects signal handlers. The destructor ensures safe cleanup of timers, services, and dynamically allocated widgets.

5.2 SaneSecurity Update Trigger

void updateSaneSecurity();

Initiates an update of the SaneSecurity database or related security feeds. This method may be invoked by other components when a global refresh is required.

6. UI Components

UpdatePage exposes a composite interface combining action buttons, switches, notebooks, and log viewers.

6.1 Primary Controls

Gtk::Button updateButton;
Gtk::Switch serviceSwitch;
Gtk::Label  sourcesLabel;
Gtk::Button addSourceButton, saveSourcesButton;
  • updateButton – triggers a manual update
  • serviceSwitch – enables or disables the background update service
  • sourcesLabel – descriptive label for source configuration
  • addSourceButton / saveSourcesButton – manage custom sources

6.2 Output and Logging View

Gtk::TextView outputView;
Glib::RefPtr<Gtk::TextBuffer> buffer;

Scrollable log view used to present update progress, diagnostics, and error messages.

6.3 Sources Notebook and Dynamic Container

Gtk::Notebook* sourcesNotebook = nullptr;
Gtk::Box* sourcesBox = nullptr;

Container used to host dynamically generated source configuration rows. Each source is represented by a UI sub-panel within the notebook.

6.4 Automatic Update Controls

Gtk::Switch saneAutoSwitch;

Toggle that enables or disables automatic SaneSecurity updates. The associated timer logic is handled internally.

7. Internal State and Data Model

This header exposes minimal explicit state. Internal runtime state (service status, timers, source lists, and credentials mapping) is managed in the implementation file.

8. User Actions (Callbacks)

void onUpdateClicked();
void onServiceToggled();
void onAddSourceClicked();
void onSaveSourcesClicked();
void onSaneAutoToggled();
  • onUpdateClicked() – executes a manual update workflow
  • onServiceToggled() – enables/disables background update services
  • onAddSourceClicked() – adds a new editable source entry
  • onSaveSourcesClicked() – persists source configuration
  • onSaneAutoToggled() – manages automatic update scheduling

9. Internal Logic

9.1 Service and Timer Management

bool checkServiceStatus();
bool checkSaneTimer();

Inspects the current state of update-related services and periodic timers, updating the UI accordingly.

9.2 Source Management

void loadSources();
void saveSources();
void createSourceRow(const SourceItem& src = {});
void updateFromExtraSources();

Handles loading, persistence, dynamic creation, and aggregation of update source definitions.

9.3 Connectivity Testing and Logging

void testConnection(const std::string& name,
                    const std::string& url,
                    bool auth,
                    const std::string& user);

void logSafe(const std::string& msg);

Provides safe, UI-thread-aware logging and source reachability testing to validate configuration before use.

9.4 Keyring and Credential Handling

std::string generateSecretKey();
std::string lookupPassword(const std::string& key);
bool storePassword(const std::string& key,
                   const std::string& password);

Integrates with the system keyring to securely store and retrieve authentication secrets for protected update sources.

10. Settings Storage

Update configuration is persisted using application-specific storage, typically in user-scoped configuration directories. This includes:

  • Service enablement state
  • Automatic update preferences
  • Custom update source definitions
  • Keyring references (not plaintext secrets)

11. Helper Functions and Filesystem Layout

While exact paths are implementation-defined, a typical deployment may use:

~/.config/BastionGuard/sources.json
~/.config/BastionGuard/update.conf
/usr/share/BastionGuard/update/

Temporary files and downloaded artifacts should be stored under application-specific cache directories.

12. Runtime and Security Considerations

  • Credential security: passwords must only be stored in the system keyring, never in plaintext configuration files.
  • Transport security: update endpoints should enforce HTTPS with certificate validation.
  • Atomic updates: database and signature updates should be applied atomically to avoid partial or inconsistent states.
  • Service control: enabling/disabling update services may require elevated privileges and should provide clear feedback to users.
  • Logging hygiene: logs displayed in outputView must avoid exposing sensitive credentials or tokens.
  • Resource cleanup: timers, subprocesses, and network handles must be properly released in the destructor.
Published on:
Last updated on: