Your message dated Wed, 24 Jun 2026 00:38:29 +0200
with message-id <ajsK5Za-t1CuqLyi@seventeen>
and subject line Re: Bug#1124885: pari: please build using the default build
flags
has caused the Debian Bug report #1124885,
regarding pari: please build using the default build flags
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1124885: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1124885
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Source: pari
Version: 2.17.3-1
User: [email protected]
Usertags: hardening-buildflags
pari is not currently using the default build flags set by dpkg-buildflags(1).
The default flags are chosen for multiple reasons including security,
performance, reproducibility, adherence to standards, and error handling.
Please make sure that pari builds using the default build flags. blhc(1p)
and hardening-check(1) can be used to confirm that the issue is fixed.
In the general case, packages honoring CFLAGS, LDFLAGS, and other
similar environment variables get the default build flags for free
without the need for any work on the maintainer side. In the case of
pari, the flags are either ignored or overridden.
The most common reasons for this are:
Hand-written Makefiles
----------------------
Some upstream Makefiles either override the values of variables such as
CFLAGS and similar or do not use them at all. See:
https://wiki.debian.org/HardeningWalkthrough#Handwritten_Makefiles
Misconfigured build systems
---------------------------
If the upstream code uses autotools, CMake, or other popular build
systems, it usually requires no further modifications. If might however
be that some variables are hardcoded in some way.
In this CMake snippet, the value of CXXFLAGS is overwritten with "-O2":
set(CMAKE_CXX_FLAGS "-O2")
If the intention is to append to CXXFLAGS, one should use the following
instead:
set(CMAKE_CXX_FLAGS "-O2 ${CMAKE_CXX_FLAGS}")
See #655870 for a similar autotools example.
Very old debhelper usage
------------------------
Packages not using dh(1), or those using a debhelper compatibility level
less than 9, need to manually include /usr/share/dpkg/buildflags.mk in
order for the dpkg-buildflags variables to be set:
https://wiki.debian.org/Hardening#dpkg-buildflags
Flags hardcoded in debian/rules (either voluntarily or not)
-----------------------------------------------------------
Some packages voluntarily hardcode the values of CFLAGS and friends in
debian/rules, ignoring the defaults set by dpkg-buildflags(1).
Others attempt to append to the variables, but end up accidentally
overriding the defaults:
#!/usr/bin/make -f
export CFLAGS += -pipe -fPIC -Wall
%:
dh $@
Debhelper only sets CFLAGS if it is not set yet. In the example above,
when dh is invoked the value of CFLAGS is "-pipe -fPIC -Wall", hence the
hardened defaults are not used. The right way to append to CFLAGS is
using DEB_CFLAGS_MAINT_APPEND instead, as documented in
dpkg-buildflags(1).
For a detailed analysis of this issue, see https://hal.science/hal-05334704/
--- End Message ---
--- Begin Message ---
Version: 2.13.1-1
On Wed, Jan 07, 2026 at 11:14:04PM +0100, Bill Allombert wrote:
> On Wed, Jan 07, 2026 at 11:46:07AM +0100, Emanuele Rocca wrote:
> > Source: pari
> > Version: 2.17.3-1
> > User: [email protected]
> > Usertags: hardening-buildflags
> >
> > pari is not currently using the default build flags set by
> > dpkg-buildflags(1).
> > The default flags are chosen for multiple reasons including security,
> > performance, reproducibility, adherence to standards, and error handling.
>
> Hello Emanuele,
>
> Thanks for your bug report.
>
> PARI/GP is a HPC software, which requires different flags for optimal
> performance,
> and is not security-sensitive, so the flags set dpkg-buildflags are not
> appropriate
> fro this package.
>
> Also, due to potential compiler bugs or ABI requirments, it is dangerous to
> deviate from upstream choice. and until dpkg-buildflags is versionned,
> dpkg-buildflags is too dangerous to use since flags can change without input
> from the maintainer, see bug #724621.
I forgot to close this bug. Done!
Cheers,
--
Bill. <[email protected]>
Imagine a large red swirl here.
--- End Message ---
