Bug#1063647: sysconfig: missing required debian/rules targets build-arch and/or build-indep

[Guillem Jover]

Source: sysconfig
Version: 0.0.14
Severity: serious
Justification: Debian Policy section 4.9
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: missing-build-arch-indep

Dear maintainer,

Your package does not include build-arch and/or build-indep targets in
debian/rules. This is required by Debian Policy section 4.9, since 2012.
https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules

Please note that this is also a sign that the packaging of this software
could benefit from a refresh. For example, packages using 'dh' cannot be
affected by this issue.

This mass bug filing was discussed on debian-devel@ in
.
(The severity of this bug at the time of the mass bug filing was set to
'important', and bumped to 'serious' after a month, but given that quite
some time has passed, I'm just setting it directly to 'serious' now, as
I'm planning to remove the fallback workaround for these targets in the
next dpkg upload.)

Thanks,
Guillem

Re: Enabling -fstack-clash-protection for trixie

[Guillem Jover]

Hi!

On Sun, 2023-08-06 at 23:25:23 +0200, Moritz Mühlenhoff wrote:
> Following the procedure to modify default dpkg-buildflags I propose to
> enable -fstack-clash-protection on amd64. The bug for dpkg tracking this
> is #918914.
> 
> | -fstack-clash-protection
> | Generate code to prevent stack clash style attacks. When this option
> | is enabled, the compiler will only allocate one page of stack space
> | at a time and each page is accessed immediately after allocation.
> | Thus, it prevents allocations from jumping over any stack guard page
> | provided by the operating system.
> 
> This has been enabled on other distros for many years already (e.g.
> Fedora since 27, RHEL since 8, OpenSUSE since 15.1, Ubuntu since 19.10).
> 
> I worked with Lucas a while back and he made an archive rebuild on amd64,
> only a minimal list of packages will need to be adapted:
> http://qa-logs.debian.net/2023/05/24/
> 
> The open question is whether to also enable this for arm64, mips64el,
> ppc64el, riscv and s390x. I'm adding the respective porter lists, if there's
> consensus among porters of a given arch other than amd64 to also add
> the flag, please post a followup to #918914.

Given the results from the rebuilds for amd64 and arm64 with minimal
fallout, and no complaints, I'm going to enable this for amd64 and the
three arm arches (arm64, armhf and armel) with dpkg 1.22.0, to be
uploaded later today. We can later on modify the set of architectures
(by request from porters) or tune them if it ends up causing problems.

Thanks,
Guillem

[RFC] The PIE unholy mess

[Guillem Jover]

Hi!

I'd like to get some feedback from porters and package maintainers,
given that this affects at least both groups. Some background first.

One of the reasons PIE has in the past not been enabled by default in
dpkg-buildflags, is because it introduced some slowness on some arches,
although this has somewhat changed recently. But also because
unconditionally setting it, breaks at least PIC builds. So PIE got
enabled recently by default in gcc, as it could easily control when it
is relevant. Although this has been done only for release architectures.

At about the same time this was being considered, I realized that dpkg
could enable this "safely" by using gcc specs files. But this is in
any case also required to be able to disable PIE when it is implicitly
enabled by default in gcc. So we'll need specs files no matter what,
at least for now.

While adapting dpkg-buildflags to cover for the new gcc defaults, I
unintentionally enabled PIE by default on all architectures, and when
I noticed, it seemed to make sense to leave it like that, because:

  * All previous build flags from dpkg-buildflags have always been
enabled globally and only blacklisted completely when they have
been non-functional.
  * It's a more consistent interface for packages, as they get built
with the same flags everywhere. Otherwise we'd get PIE enabled by
default in release arches, disabled by default elsewhere, and
enabled or disabled depending on the package requesting so.
  * It will mean that PIE coverage reporting will be shadowed in
lintian, because the tags only cover i386 and amd64, so maintainers
will probably stop enabling them globally.

Matthias Klose recently filed an unclear report (#848129) on dpkg-dev
requesting to not enable PIE globally from dpkg-buildflags, and pretty
much immediately added a patch into gcc [P] to ignore dpkg-buildflags
PIE -specs flags if DEB_BUILD_OPTIONS or DEB_BUILD_MAINT_OPTIONS did
not enable PIE explicitly (I only fully understood the request after
seeing the gcc patch).

  [P] 


Besides this being completely broken, as DEB_BUILD_MAINT_OPTIONS
does not even need to be exported from debian/rules, nor from the
dpkg architecture.mk fragment, or when dpkg-buildflags is used with its
--export=configure or --export=cmdline. It's also a layer violation.
It also breaks unrelated stuff as now gcc emits notes when it thinks
the -specs option should not be passed. And while I could certainly
have started an arms-race by adding counter-measures by randomizing
the filenames or something similarly ugly, that'd be pretty much silly
and childish.

For better or worse, this does not affect the release architectures,
so by extension it should not affect the release, but it still sucks.

So, I'd like to know how people feel about the requested interface
(i.e. not enabling PIE globally from dpkg-buildflags). If there's
consensus that porters and maintainers want that, I'll just change
dpkg-buildflags to do this, even though I think it's a very
suboptiomal behavior.

Alternatively, porters could as well request PIE be enabled by default
in gcc on their port, which could make this also globally enabled.

Thanks,
Guillem

Re: Bug#845193: dpkg: recent -specs PIE changes break openssl

[Guillem Jover]

Hi!

On Thu, 2016-11-24 at 14:52:33 +, Thorsten Glaser wrote:
> clone 845193 -1
> reassign -1 dpkg
> retitle -1 dpkg: please do not add -specs= flags only on some architectures
> thanks

I'm afraid I'll have to wontfix this because it is not really
implementable. See below… :/

> Guillem Jover dixit:
> >Those specs files should make it possible to build stuff with PIE
> 
> Yes, but they *do* break anything that
> - acts on the CFLAGS (and LDFLAGS) variables
> - uses klcc or other compiler wrappers that don't understand -specs
> - uses clang or pcc or whatever other compilers

The default dpkg build flags have always been tied to the specific
language compiler version currently marked as the default (for C that
would currently be gcc-6).

> Worse, they break *differently* on whether…
> 
> >Precisely to make the behavior consistent on all architectures, dpkg
> >enables PIE (conditionally if no other flags marks it as to be
> >disabled) on all architectures were gcc has not enabled this by
> >default.
> 
> … that. And that is just plain wrong. Either dpkg should inject
> -specs= stuff on all architectures or on none. Differing like this
> just invites hidden and hard to track down bugs.

As long as gcc enables PIE on a subset, there will be need to inject
some form of specs on either subset of those arches, either on
hardening=+pie or on hardening=-pie, pick yout poison. :(

Injecting just the raw -fno-PIE and -no-pie does not work, so when you
need to disable those we need to pass via specs files.

> Please get an agreement with the GCC maintainer on how to proceed
> from here.
>
> Personally, I’d still prefer for GCC to behave as on other systems,
> i.e. not to enable PIE by default, and to have it done completely
> within dpkg, but I can *also* live with it being done exclusively
> in GCC.
> 
> Either are *much* better than the current way.

Well you and me both, I'm just adapting the dpkg-buildflags to the
current gcc situation. :/

> >Also BTW the gcc maintainer asked that porters
> >interested could request PIE to be enabled by default in gcc.
> 
> What difference does it make on whether GCC or dpkg enables PIE?

It means it should at least get the same behavior from gcc as all
official ports, it is more transparent and should not suffer from
unbalanced passing of CFLAGS w/o LDFLAGS or the other way around,
for example. Of course that does not mean that package might still
not fail, in case they try to link PIE code into a shared library
or similar.

> The two last quote sections make it clear that any architecture
> that currently has PIE enabled in dpkg should have it enabled in
> GCC in the first place.

Enabling new build flags in dpkg has always been done globally,
except for specific blacklists on things that were completely broken
in the toolchain, which have then been enabled eventually when they
got fixed.

Having a subset of architectures is a pain for maintainers as they
get different resulting objects depending on the architectures, it
also changes the semantics from before the gcc default change, as
previously explicitly enabling PIE was global, and now would be for
a subset.

Or worse, the new semantics would need to be that by default you get
PIE on a subset but if you pass hardening=+pie on each package you get
it enabled globally? Pretty unintuitive IMO.

> (Did dpkg enable that on porters’ requests?
> It does not look like that to me. This smells like overstepping
> boundaries.)

If porters are unhappy about this, I'll revert PIE for those ports in
dpkg, but this will not make the situation less of a mess, hardening=-pie
will still need the specs files on ports were gcc enables it by default,
and hardening=+pie might need them on the ones that do not…

> tl;dr: I don’t care as much _which_ of GCC xor dpkg does it,
> as long as only one does it. FFS, just enable it on all of them
> unless known to absolutely not work; that’d still be better than
> the current mess.

Well I think we should be enabling all hardening flags directly in
gcc, but now that we have the specs files I guess it would not be
too bad to enable them just in dpkg, but I agree either would be
preferable. :/

Thanks,
Guillem

Re: Porter roll call for Debian Stretch

[Guillem Jover]

Hi!

On Sun, 2016-08-21 at 08:22:09 +0200, Niels Thykier wrote:
> Kurt Roeckx:
> > On Wed, Aug 17, 2016 at 10:05:06PM +0200, ni...@thykier.net wrote:
> >>  * If we were to enable -fPIE/-pie by default in GCC-6, should that change
> >>also apply to this port? [0]
> > 
> > If -fPIE is the default will -fPIC override it?
> > 
> > It will also default to tell the linker to use -pie, but then
> > don't do it when you want to create a shared library?
> 
> I believe so.  At least, Ubuntu made PIE default in their compiler
> without having to change all SO packages to still build.

As I mentioned on IRC, the Gentoo people seems to have done so as well
in their Gentoo Hardened Toolchain project
.

> Admittedly, it could also be that GCC uses some built "compiler spec"
> files for this case (a la an implicit "-specs=$FILE"), which are similar
> to those Redhat uses for this purposes (see [1] for an example of such
> files).

I think there are some bugs tracked in Fedora about this
, And this
is what I based the dpkg patch on as a potential alternative instead
of modifying our toolchain, which I think would be preferable. But see
below.

> >>From what I understand, depending on what the .o file is going to
> > be used for you want different things:
> > - shared library: -fPIC
> > - executable: -fPIC or -fPIE both work, but prefer -fPIE
> > - static library: Same as executables
> > 
> > For static libraries we now have a policy to not use -fPIC,
> > should that then get replaced by using -fPIE?

> Honestly, I had not thought about that.  From the looks of it, de facto
> we will end up with -fPIE being the default for static libraries as well.
>   I would be supporting that change on the assumption that it requires
> less work from individual maintainers (and presumably has no notable
> downsides in the final result).

I think that's what we are getting right now for any package enabling
the "pie" build flags feature anyway.

> [1] Example spec files for this case seems to be something like:
> 
> pie-compile.specs
> """
> *cc1_options:
> + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}
> """
> 
> pie-link.specs:
> """
> *self_spec:
> + %{!shared:%{!r:-pie}}
> """
> 
> NB: I manually carved them out of a diff without testing them.

That would be
,
which neither I tested. Testing should first be done for gcc, g++, gcj,
gobjc, gobjc++, gccgo (although I've not managed to use shared libraries
with latest releases, but used to be able to) and gfortran. If someone
wants to test these first to see if it works and then later on do an
archive rebuild, that would also be appreciated.

At that point I could then at least switch the current implementation
so that we can just enable the "pie" feature per package regardless of
it building prorgrams or shared libraries. Enabling it by default
globally would require the usual process described in the dpkg FAQ.

Thanks,
Guillem