Bug#659663: Support for hardened build flags

[Moritz Muehlenhoff]

Package: openafs
Severity: important

openafs already emits dpkg-buildflags during build, but the flags are
not put into effect by the upstream buildsystem:

| * Use dpkg-buildflags to get the default values of CFLAGS, CPPFLAGS, and
| LDFLAGS. Upstream does not entirely honor these yet, but we're
| getting closer.

I suppose that's due to src/cf/osconf.m4 overriding these flags.

Cheers,
Moritz



--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Russ Allbery]

Moritz Muehlenhoff <j...@debian.org> writes:

> openafs already emits dpkg-buildflags during build, but the flags are
> not put into effect by the upstream buildsystem:

> | * Use dpkg-buildflags to get the default values of CFLAGS, CPPFLAGS, and
> | LDFLAGS. Upstream does not entirely honor these yet, but we're
> | getting closer.

> I suppose that's due to src/cf/osconf.m4 overriding these flags.

The trick with hardening flags in OpenAFS is that it also builds a kernel
module, for which those flags are not appropriate.

I assume that you're filing these bugs against any package that has had a
security advisory. Note that the OpenAFS security advisory was for the
kernel code, where hardening flags are a trickier issue.

--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>

[Russ Allbery]

Russ Allbery <r...@debian.org> writes:
> Moritz Muehlenhoff <j...@debian.org> writes:

>> openafs already emits dpkg-buildflags during build, but the flags are
>> not put into effect by the upstream buildsystem:

>> | * Use dpkg-buildflags to get the default values of CFLAGS, CPPFLAGS, and
>> | LDFLAGS. Upstream does not entirely honor these yet, but we're
>> | getting closer.

>> I suppose that's due to src/cf/osconf.m4 overriding these flags.

> The trick with hardening flags in OpenAFS is that it also builds a
> kernel module, for which those flags are not appropriate.

I didn't explain that very well: the Debian build system for the kernel
modules and the rest of the package is, of course, separate, so it's not a
problem from that perspective. But that's the reason why upstream
overrides the build flags, so I need to figure out a good way to work with
that. If push comes to shove, I'll carry a Debian-specific patch, but
I'll try to figure out some way to avoid that.

> I assume that you're filing these bugs against any package that has had
> a security advisory. Note that the OpenAFS security advisory was for
> the kernel code, where hardening flags are a trickier issue.

I say this not to say that I won't do it (mostly, I was holding off
because switching to debhelper V9 carried multiarch implications, which
makes backporting a lot harder, but I'll take a look), just to mention
that it's probably not going to help on that security front. But it could
help with the servers.

The other worry I have is that the current version of the package uses
LWP, which does a bunch of really nasty internal tricks. (This will be
replaced with pure pthreads eventually, but not yet.) But hopefully that
shouldn't be a problem.