Debian Patches

Status for marisa/0.3.1+git20250817-2

Patch Description Author Forwarded Bugs Origin Last update
0001-Specify-python-module-version-for-litian4py-warning.patch Specify python module version for litian4py warning
This is pointed out by the following comment:

https://bugs.debian.org/714734#68		 Mitsuya Shibata <mty.shibata@gmail.com> no 2025-09-16
0002-Do-not-build-legacy-python2-bindings.patch Do not build legacy python2 bindings
See also https://github.com/s-yata/marisa-trie/issues/55		 Boyuan Yang <byang@debian.org> no 2025-09-16
0003-CMakeLists.txt-Enforce-global-PIC.patch CMakeLists.txt: Enforce global PIC Boyuan Yang <byang@debian.org> no 2025-09-16
0004-Bump-SOVERSION-to-1.patch Bump SOVERSION to 1 Boyuan Yang <byang@debian.org> no 2025-09-16
0005-tests-Fix-double-value-comparison-error-on-i386.patch tests/: Fix double value comparison error on i386 Boyuan Yang <byang@debian.org> yes 2025-09-23
0006-FlatVector-Zero-initialize-the-whole-units-vector.patch FlatVector: Zero-initialize the whole units_ vector
FlatVector::build_() allocates units_ with Vector::resize(), which only
placement-new's each element and therefore leaves integer elements holding
indeterminate memory. Only the last unit was explicitly zeroed afterwards,
relying on set() to overwrite everything else.

On a 64-bit host (MARISA_WORD_SIZE == 64) that is sufficient: num_units is
either 1 or exactly the number of units required, so the only element not
fully covered by set() is units_.back(), which is cleared.

On a 32-bit host (MARISA_WORD_SIZE == 32) it is not. Both

std::size_t num_units = values.empty() ? 0 : (64 / MARISA_WORD_SIZE);

and

num_units += num_units % (64 / MARISA_WORD_SIZE);

round the unit count up to a multiple of two, so units_[num_units - 2] is
neither cleared nor fully written by set(). Its uninitialized bits are then
passed to Writer::write() and stored in the serialized trie.

Values read back through operator[] are unaffected, since only bits written
by set() are ever read. The visible effect is that the serialized byte stream
is not deterministic: the leaked bytes are whatever the allocator left behind,
typically heap addresses, which differ between runs because of ASLR.

This was found via the Debian reproducible-builds rebuilder for src:opencc,
which generates its *.ocd2 dictionaries at build time using marisa. The
generated dictionaries differed between rebuilds on i386 and armhf while being
stable on 64-bit architectures. The differing bytes are the extras_ FlatVector
of each of the three nested tries, and appear as four garbage bytes followed
by four zero bytes.

Zero the whole vector instead. Output on 64-bit hosts is byte-for-byte
unchanged.		 Boyuan Yang <byang@debian.org> yes upstream 2026-08-06

All known versions for source package 'marisa'

Links