Russ Allbery <[email protected]> writes: > Moritz Muehlenhoff <[email protected]> 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. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
