YODA

https://gitlab.com/hepcedar/yoda

https://gitlab.com/hepcedar/yoda/-/commits/release-2-1-x?ref_type=HEADS

Development takes place in the open on GitLab at
https://gitlab.com/hepcedar/yoda. The repository contains the full commit
history, not only tagged releases: individual commits, feature branches
and merge requests are publicly visible and reviewable as work
progresses. Tagged releases are cut from this same public history.

The project uses git, hosted on GitLab at https://gitlab.com/hepcedar/yoda

Each release has a unique three-component version number (e.g. 2.1.0),
applied consistently across the git tag, the release tarball filename
(yoda-X.Y.Z.tar.gz) and the version reported by the library at runtime
and by yoda-config --version. Version numbers are never reused.

Every release is tagged in git, with tags visible at
https://gitlab.com/hepcedar/yoda/-/tags. The tag name corresponds to the
release version number, so the source state of any release can be
recovered directly from the repository.

Each release is accompanied by human-written release notes published on
the project's GitLab releases page:
https://gitlab.com/hepcedar/yoda/-/releases

The notes summarise new features, interface changes and significant bug
fixes for each version, written to help users assess the impact of
upgrading. They are composed by the maintainers, not generated from the
version control log. A separate hand-maintained ChangeLog in the
repository records development detail at finer granularity, and releases
are also announced with a summary on the project website and the MCnet
announcement mailing list.

No publicly known run-time vulnerabilities have been reported against YODA, and no CVEs have been assigned to the project, so there are none to identify in release notes.

Users can submit bug reports through the project's GitLab issue tracker:
https://gitlab.com/hepcedar/yoda/-/work_items

Anyone with a free GitLab account can open an issue. A support mailing
list (yoda-support@cern.ch) is also available for users who prefer email
or who are unsure whether a problem is a bug.

The project uses the GitLab issue tracker for individual issues:
https://gitlab.com/hepcedar/yoda/-/work_items

Each report is tracked as a separate issue with its own identifier and
URL, with status, labels, assignee and discussion history maintained per
issue. Bugs reported via the support mailing list are transferred to the
tracker where they warrant follow-up.

The maintainers monitor the GitLab issue tracker and respond to bug reports. Reviewing issues opened in the qualifying window, the large majority received a maintainer response -- typically triage, a request for a reproducer, or an explanation of the behaviour -- independently of whether a fix followed. Reports arriving via the support mailing list are answered directly by the maintainers.

Enhancement requests are submitted through the GitLab issue tracker and the support mailing list, and the maintainers respond to the majority of them -- whether by implementing the request, discussing design alternatives, or explaining why it falls outside the project's scope. Requests are frequently raised directly by the physics user community through the MCnet collaboration and at community meetings, and are discussed there as well as in the tracker.

All issues and their discussion, including closed issues, remain publicly
readable and searchable in the GitLab tracker:
https://gitlab.com/hepcedar/yoda/-/work_items

The archive is browsable without an account, supports full-text search
across open and closed issues, and every issue and individual comment has
a stable, addressable URL.

The vulnerability reporting process is published in the project's
SECURITY.md, at the root of the source repository and linked from the
project website:
https://gitlab.com/hepcedar/yoda/-/blob/release-2-1-x/SECURITY.md

It documents the private reporting address, the alternative of a
confidential GitLab issue, the information to include in a report, and
the expected response and disclosure process.

The SECURITY.md documents two private reporting routes: a dedicated
email address (yoda-security@cern.ch) that reaches the core
maintainers and is not publicly archived, and the option of opening a
confidential issue on the GitLab tracker, which is visible only to
project members.

https://gitlab.com/hepcedar/yoda/-/blob/release-2-1-x/SECURITY.md

No vulnerability reports have been received in the last six months, so there are no response times to report. The project's published policy in SECURITY.md commits to acknowledging reports within 14 days, and the private reporting address reaches multiple maintainers so that reports are not dependent on any single person's availability.

YODA provides a standard GNU autotools build system (autoconf, automake,
libtool). The software is built from source with the conventional
sequence:

    ./configure [options]
    make
    make install

The build is fully automated: dependency and compiler detection, C++
compilation, generation of the Python bindings (via Cython), and
installation are all handled by the build system without manual
intervention. Release tarballs ship with a pre-generated configure
script, so end users need only a C++ compiler, make and Python. Building from a git
checkout additionally requires the autotools, with the configure script
generated by running autoreconf -i.

The build uses the GNU autotools (autoconf, automake, libtool) together with make and a standard C++ compiler, all of which are widely available and packaged for every mainstream Linux distribution and macOS. No project-specific or unusual build tooling is required. The Python bindings are generated with Cython, also widely packaged.

YODA builds using only FLOSS tools: the GNU autotools (autoconf,
automake, libtool), make, and a standard C++ compiler. Both GCC and
Clang are supported, and [Cython] is used to generate the Python
bindings. No proprietary compiler, library or build tool is required at
any stage.

YODA includes an automated test suite in the tests/ directory of the
source repository, released under the same GPL-3.0 licence as the rest of
the project. It covers the core analysis-object types, fill and
aggregation behaviour, rebinning and merging operations, and I/O
round-tripping through the .yoda format, and includes both the C++ tests
and tests of the Python interface.

The suite is run with:

    make check

after configuring and building, as documented in https://gitlab.com/hepcedar/yoda/-/blob/release-2-1-x/doc/installation.md

It is also run automatically in CI on every push: https://gitlab.com/hepcedar/yoda/-/blob/release-2-1-x/.gitlab-ci.yml

The test suite is invoked with make check, the standard target for
autotools-based projects, after the usual ./configure && make build
steps. No project-specific test runner or wrapper script is required.

The test suite covers over 90% of lines (4391 of 4642), measured with gcov/lcov automatically in CI on every merge request. Function-level coverage figures are not meaningful for this codebase: YODA is largely header-only and heavily templated, so gcov counts every instantiated specialisation — including implicit special member functions — as a distinct function, inflating the denominator.

The project uses GitLab CI. Every merge request triggers an automated
pipeline that builds the library and runs the full test suite, including
coverage measurement with gcov/lcov. Changes are merged into the main
branch only after the pipeline passes, so the integration branch is
continuously tested.

CI configuration: https://gitlab.com/hepcedar/yoda/-/blob/main/.gitlab-ci.yml
Pipeline history: https://gitlab.com/hepcedar/yoda/-/pipelines

The project's CONTRIBUTING.md states that contributions adding new
functionality are expected to include corresponding tests in the
automated test suite. This is applied in practice during merge request
review, and the CI pipeline reports test results and coverage on every
merge request, so gaps in test coverage are visible to reviewers before
merge.

https://gitlab.com/hepcedar/yoda/-/blob/release-2-1-x/CONTRIBUTING.md

The policy is stated in CONTRIBUTING.md, the project's documented
instructions for proposing changes, so contributors encounter it before
submitting a merge request rather than discovering it in review.

https://gitlab.com/hepcedar/yoda/-/blob/release-2-1-x/CONTRIBUTING.md

The build enables compiler warnings by default: -Wall and -Wextra
are passed to the C++ compiler via the build system, for both GCC and
Clang. Warnings are visible in the CI build logs for every merge request,
so newly introduced warnings are apparent during review.

Warnings are enabled with -Wall and -Wextra under both GCC and
Clang, and warnings arising in YODA's own sources are fixed as they
appear, with the CI build log for each merge request making new ones
visible during review.

The build is not currently warning-free, because the bundled copy of the
third-party Eigen3 library has aged and emits warnings under recent
compilers. This has been addressed on the main branch: the bundled Eigen3
has been updated, and the build now additionally supports linking against
an external Eigen3 installation. These changes will appear in the
2.2.x release series.

At least one primary developer is familiar with these secure design
principles, including the Saltzer and Schroeder principles, attack
surface limitation and input validation.

They are applied to YODA where relevant to its architecture. The library
is an offline data-analysis and I/O component: it performs no network
communication, requires no elevated privileges, and handles no
credentials or personal data, so the attack surface is deliberately
limited to file parsing. Input parsing is written defensively, with
malformed input rejected rather than accepted with undefined behaviour,
and the parsing code is exercised by the automated test suite (94.6% line
coverage) run in CI on every merge request. The codebase is fully open,
developed in public, and reviewed through merge requests.

At least one primary developer is familiar with the classes of defect
that lead to vulnerabilities in C++ libraries of this kind, and with
means of countering them. The relevant classes for YODA, whose principal
untrusted input is data files that users routinely exchange and download,
and the mitigations applied, are:

• Out-of-bounds reads and writes when parsing input (CWE-125,
  CWE-787): the codebase uses standard library containers and std::string
  rather than raw buffers and manual pointer arithmetic, so bounds are
  managed by the container rather than by hand.
• Integer overflow in size and index calculations (CWE-190): values
  read from input that determine bin counts or dimensions are range-checked
  before use.
• Uncontrolled resource consumption from malicious input (CWE-400,
  CWE-789): input that would imply implausible allocations is rejected
  rather than acted on.
• Use-after-free and dangling references (CWE-416): object lifetimes
  are managed by RAII and smart pointers rather than manual
  allocation and deallocation.
• Use of uninitialised memory (CWE-457): members are initialised at
  construction; the codebase is compiled with warnings enabled, which
  diagnoses many such cases.

These are exercised by the automated test suite (94.6% line coverage) run
in CI on every merge request.

Distribution channels use HTTPS exclusively. [osps_br_03_02]

The project does not retrieve cryptographic hashes over HTTP. YODA's build system does not download dependencies at build time; all sources, including the bundled Eigen3, are contained in the source tree or supplied by the user's own installation. The source repository is served over HTTPS from GitLab, and release tarballs are distributed over HTTPS from the project website.

No vulnerabilities have been publicly reported against YODA, and no CVEs have been assigned to the project, so there are none unpatched. The project undertakes to fix any that are reported within the timescales set out in SECURITY.md.

No critical vulnerabilities have been reported against YODA. The project's published policy in SECURITY.md commits to acknowledging reports within 14 days and issuing fixes in the next release, and the private reporting address reaches multiple maintainers so that reports are not dependent on any single person's availability.

The repository contains no credentials intended to limit public access. YODA is an offline library requiring no authentication, network access or external services, so no such credentials exist to leak. CI authentication uses GitLab's masked project variables rather than values committed to the repository.