wireshark

English

Overview

Wireshark is a network protocol analyzer. It is used to inspect live traffic and to analyze previously captured packet files. The upstream project provides Wireshark as a graphical application and publishes command-line manual pages and user documentation for the tools included in the distribution. (wireshark.org)

Purpose and typical use cases

Typical use cases include:

• analyzing packet captures during network troubleshooting,
• inspecting protocol behavior on a local host or across a network path,
• reviewing saved capture files for debugging or forensic analysis,
• validating capture filters and display filters,
• comparing traffic seen in development, test, and production environments.

Typical users include network administrators, developers, security engineers, incident responders, and other users who need to examine packet-level network behavior. This package provides the graphical Wireshark application; distribution maintainers should verify the exact set of auxiliary tools shipped by the build.

Upstream project

The upstream project is maintained by the Wireshark Foundation on GitLab. The project page identifies it as the official code repository. Upstream documentation is published on the Wireshark documentation site, including user documentation, command-line manual pages, display filter reference material, and release notes. (gitlab.com)

Dist-git repository contents

This NiceOS dist-git repository contains packaging metadata rather than the full upstream source tree.

• SPECS/ contains the RPM spec files and packaging logic.
• SOURCES/ contains source metadata and manifest files used by the build system.
• METADATA/ contains repository metadata used by packaging workflows.
• SBOM/ contains software bill of materials material when it is maintained for the package.

Large upstream source archives are intentionally not stored in this Git repository. Only the packaging inputs and source-tracking metadata are kept here.

Source storage and integrity policy

Source integrity is tracked through manifest files in SOURCES/. NiceOS maintainers should treat those manifests as the authoritative record for the imported upstream sources used by the package build.

This repository does not store the upstream archive itself. When updating the package, maintainers should verify that the manifest entries match the intended upstream source set and that any required source imports were refreshed consistently.

NiceOS maintenance notes

Before updating this package, NiceOS maintainers should verify:

• that the upstream source set still matches the packaging assumptions,
• that the build remains compatible with the target NiceOS branch,
• that any packaging patches still apply cleanly,
• that the spec file metadata, dependencies, and file lists remain correct,
• that any generated packaging metadata was regenerated if the source layout changed,
• that SBOM material, if present, still reflects the packaged contents.

Risks to consider:

• protocol-analyzer packages often depend on optional capture, GUI, and library integrations; changes in those areas may affect build or runtime behavior,
• upstream documentation and generated artifacts may change file placement between releases,
• packaging changes may affect desktop integration or tool availability.

If any of these points are uncertain, NiceOS maintainers should verify them against the current upstream sources and build logs.

Build and verification checklist

For an RPM update or rebuild, maintainers should typically:

1. confirm the intended upstream source revision,
2. verify SOURCES/ manifest entries after refreshing imported sources,
3. review the spec file for versioned paths or assumptions that may have become stale,
4. run the package build in a clean mock or equivalent build environment,
5. inspect build logs for missing build requirements, file conflicts, or install-path changes,
6. check the resulting RPM payload for expected binaries, desktop files, documentation, and licenses,
7. run basic startup and smoke tests if the build environment allows it,
8. verify that the package metadata and SBOM, if used, are still consistent,
9. review any packaging patches for upstream applicability and whether they are still needed.

References

• Wireshark official GitLab repository
• Wireshark documentation
• Wireshark command-line manual pages
• wireshark(1) manual page

Русский

Обзор

Wireshark — это анализатор сетевых протоколов. Он используется для просмотра трафика в реальном времени и для анализа ранее сохранённых файлов захвата пакетов. В upstream-проекте Wireshark распространяется как графическое приложение; также публикуются справочные страницы командной строки и пользовательская документация для входящих в поставку инструментов. (wireshark.org)

Назначение и типовые сценарии использования

Типовые сценарии использования:

• анализ дампов пакетов при поиске сетевых неисправностей,
• просмотр поведения протоколов на локальном узле или на участке сети,
• проверка сохранённых capture-файлов для отладки или расследования,
• проверка capture filters и display filters,
• сравнение трафика в средах разработки, тестирования и эксплуатации.

Типовые пользователи: сетевые администраторы, разработчики, специалисты по безопасности, участники реагирования на инциденты и другие пользователи, которым требуется анализ сетевого обмена на уровне пакетов. Этот пакет предоставляет графическое приложение Wireshark; сопровождающим дистрибутива следует отдельно проверить точный набор дополнительных утилит, входящих в сборку.

Upstream-проект

Upstream-проект поддерживается Wireshark Foundation в GitLab. На странице проекта он указан как официальный репозиторий исходного кода. Документация upstream публикуется на сайте Wireshark и включает пользовательскую документацию, страницы руководства для командной строки, справочник по display filters и release notes. (gitlab.com)

Содержимое dist-git репозитория

Этот dist-git репозиторий NiceOS содержит упаковочные метаданные, а не полный upstream-исходный код.

• SPECS/ содержит RPM spec-файлы и логику упаковки.
• SOURCES/ содержит метаданные исходных файлов и manifest-файлы, используемые системой сборки.
• METADATA/ содержит метаданные репозитория, используемые процессами сопровождения пакетов.
• SBOM/ содержит материалы software bill of materials, если они ведутся для пакета.

Крупные upstream-архивы исходного кода намеренно не хранятся в этом Git-репозитории. Здесь размещаются только входные данные упаковки и метаданные для отслеживания исходных файлов.

Политика хранения исходных файлов и контроля целостности

Целостность исходных файлов отслеживается через manifest-файлы в SOURCES/. Сопровождающим NiceOS следует считать эти manifest-файлы авторитетной записью о том, какие upstream-исходники были импортированы для сборки пакета.

Сам upstream-архив в этом репозитории не хранится. При обновлении пакета сопровождающим следует проверить, что записи в manifest соответствуют ожидаемому набору upstream-исходников и что импорт обновлён согласованно.

Замечания по сопровождению в НАЙС.ОС

Перед обновлением пакета сопровождающим NiceOS следует проверить:

• что набор upstream-исходников по-прежнему соответствует предположениям упаковки,
• что сборка совместима с целевой веткой NiceOS,
• что применяемые патчи по-прежнему накладываются без ошибок,
• что метаданные spec-файла, зависимости и списки файлов остаются корректными,
• что при изменении структуры исходников были переcгенерированы необходимые упаковочные метаданные,
• что материалы SBOM, если они присутствуют, всё ещё соответствуют содержимому пакета.

Следует учитывать следующие риски:

• пакеты для анализа протоколов часто зависят от дополнительных компонентов захвата, GUI и библиотек; изменения в этих областях могут повлиять на сборку или поведение на запуске,
• upstream-документация и сгенерированные артефакты могут менять расположение файлов между релизами,
• изменения в упаковке могут повлиять на desktop integration или доступность отдельных утилит.

Если какой-либо из этих пунктов неясен, сопровождающим NiceOS следует проверить его по текущим upstream-исходникам и логам сборки.

Контрольный список сборки и проверки

При обновлении или пересборке RPM обычно следует:

1. подтвердить требуемую upstream-ревизию исходников,
2. проверить записи manifest в SOURCES/ после обновления импортированных исходников,
3. просмотреть spec-файл на наличие устаревших путей или предположений о структуре файлов,
4. выполнить сборку в чистой среде mock или в эквивалентной среде,
5. проверить логи сборки на отсутствие build requirements, конфликтов файлов или изменений путей установки,
6. осмотреть содержимое RPM на наличие ожидаемых бинарных файлов, desktop-файлов, документации и лицензий,
7. при возможности выполнить базовый запуск и smoke-тесты,
8. проверить согласованность метаданных пакета и SBOM, если они используются,
9. оценить применяемые патчи на предмет актуальности и необходимости.

Ссылки

• Официальный GitLab-репозиторий Wireshark
• Документация Wireshark
• Страницы руководства Wireshark для командной строки
• Руководство wireshark(1)

Dist-git repository notes

• Package repository: rpms/wireshark
• NiceOS branch: niceos-5.2
• This README is intentionally stable and does not include EVR, source archive checksums or lock hashes.