Debian Bug report logs - #859751
xtrs: please pass buildflags

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Graham Inggs <ginggs@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: xtrs: please pass buildflags

Date: Thu, 6 Apr 2017 22:01:05 +0200

[Message part 1 (text/plain, inline)]

Source: xtrs
Version: 4.9c-4
Severity: wishlist
Tags: patch

Hi Maintainer

Welcome back!

According to the buildd log scanner [1],

Issues found in current buildd logs for xtrs:

W dpkg-buildflags-missing CPPFLAGS 27 (of 27), CFLAGS 27 (of 27),
LDFLAGS 5 (of 5) missing (amd64, arm64, armel, armhf, i386, mips,
mips64el, mipsel, powerpc, ppc64el, s390x)

You can check this locally with the 'blhc' tool.  After passing
CPPFLAGS, CFLAGS and LDFLAGS, as per the attached patch, the following
errors appeared:

debug.c:518:10: error: format not a string literal and no format
arguments [-Werror=format-security]
   printf(help_message);
          ^~~~~~~~~~~~

dis.c: In function ‘disassemble’:
dis.c:2118:2: error: format not a string literal and no format
arguments [-Werror=format-security]
  printf (code->name);
  ^~~~~~

These are also fixed in the patch.

Regards
Graham


[1] https://qa.debian.org/bls/packages/x/xtrs.html

[pass-buildflags.debdiff (application/octet-stream, attachment)]

Message #10 received at 859751@bugs.debian.org (full text, mbox, reply):

From: "G. Branden Robinson" <g.branden.robinson@gmail.com>

To: Graham Inggs <ginggs@debian.org>, 859751@bugs.debian.org, control@bugs.debian.org

Subject: Re: Bug#859751: xtrs: please pass buildflags

Date: Fri, 7 Apr 2017 07:12:58 -0400

[Message part 1 (text/plain, inline)]

package xtrs
tag 859751 + pending
thanks

At 2017-04-06T22:01:05+0200, Graham Inggs wrote:
> Source: xtrs
> Version: 4.9c-4
> Severity: wishlist
> Tags: patch
> 
> Hi Maintainer
> 
> Welcome back!

Thanks!

> According to the buildd log scanner [1],
> 
> Issues found in current buildd logs for xtrs:
> 
> W dpkg-buildflags-missing CPPFLAGS 27 (of 27), CFLAGS 27 (of 27),
> LDFLAGS 5 (of 5) missing (amd64, arm64, armel, armhf, i386, mips,
> mips64el, mipsel, powerpc, ppc64el, s390x)
> 
> You can check this locally with the 'blhc' tool.  After passing
> CPPFLAGS, CFLAGS and LDFLAGS, as per the attached patch, the following
> errors appeared:
> 
> debug.c:518:10: error: format not a string literal and no format
> arguments [-Werror=format-security]
>    printf(help_message);
>           ^~~~~~~~~~~~
> 
> dis.c: In function ‘disassemble’:
> dis.c:2118:2: error: format not a string literal and no format
> arguments [-Werror=format-security]
>   printf (code->name);
>   ^~~~~~
> 
> These are also fixed in the patch.

Hi Graham.  I already have these fixed in the 4.9d branch of the
package; my upload sponsor advised me that including these (and other)
changes violated the minimality constraints of the release freeze.

I'm arranging sponsorship for an upload of 4.9d-2 right now, but you can
preview the changes via the attachments.  I see only one remaining
issue:

$ blhc xtrs_4.9d-2_amd64.build
LDFLAGS missing (-Wl,-z,relro -Wl,-z,now): cc -o compile_rom
compile_rom.o error.o load_cmd.o load_hex.o

compile_rom is an utility internal to the build.  It's not shipped and
thus not subject to attacks.  I'm considering adding an --ignore-line
for it, but I need to figure out how to embed this information in the
package itself so the buildd log scanner knows to use this flag itself.

Please advise if you think the attachments don't address the issue.

Regards,
Branden

[xtrs_4.9d-2.debian.tar.xz (application/x-xz, attachment)]

[xtrs_4.9d-2.dsc (text/plain, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #17 received at 859751@bugs.debian.org (full text, mbox, reply):

From: Graham Inggs <ginggs@debian.org>

To: 859751@bugs.debian.org

Subject: Re: Bug#859751: xtrs: please pass buildflags

Date: Fri, 7 Apr 2017 14:10:06 +0200

On 07/04/2017 13:12, G. Branden Robinson wrote:
> compile_rom is an utility internal to the build.  It's not shipped and
> thus not subject to attacks.  I'm considering adding an --ignore-line
> for it, but I need to figure out how to embed this information in the
> package itself so the buildd log scanner knows to use this flag itself.

Is there any harm in linking compile_rom with those flags?

> Please advise if you think the attachments don't address the issue.

All looks good, thanks!  I see the 'format not a string literal and no 
format arguments' errors are already fixed in upstream 4.9d.

Message #22 received at 859751@bugs.debian.org (full text, mbox, reply):

From: "G. Branden Robinson" <g.branden.robinson@gmail.com>

To: Graham Inggs <ginggs@debian.org>, 859751@bugs.debian.org

Subject: Re: Bug#859751: xtrs: please pass buildflags

Date: Fri, 7 Apr 2017 13:06:53 -0400

[Message part 1 (text/plain, inline)]

At 2017-04-07T14:10:06+0200, Graham Inggs wrote:
> On 07/04/2017 13:12, G. Branden Robinson wrote:
> > compile_rom is an utility internal to the build.  It's not shipped and
> > thus not subject to attacks.  I'm considering adding an --ignore-line
> > for it, but I need to figure out how to embed this information in the
> > package itself so the buildd log scanner knows to use this flag itself.
> 
> Is there any harm in linking compile_rom with those flags?

Probably not, but what's the use case?

This compile_rom utility is only useful for, and only used to, embed
Z-80 instructions into the memory map of an emulated TRS-80 computer;
specifically _this_ emulator, xtrs.

All of this hardening stuff, as I understand it, involves mitigation
strategies for unsafe memory usage in the C language family in the ELF
object file format.

Again, the tool is not shipped.  I am having trouble thinking of any
attack vector involving compile_rom that isn't dwarfed by the fact that
it would have to be expoited during a package build, at which time there
are much simpler and nastier ways to attack a host, such as by embedding
hostile code into a maintainer script.  Those kinds of exploits are much
easier to write and we don't really screen for them.  Just the other I
saw on #debian-devel that we had a package that goofed up an rm -rf
command in its postinst and trashed /usr/bin or something like that.

My preference is to be fastidious about things, but I also have a strong
antipathy towards cargo-cult software engineering.  I cannot think of
any benefit of hardening compile_rom that is not extremely speculative.

Can you?

> > Please advise if you think the attachments don't address the issue.
> 
> All looks good, thanks!  I see the 'format not a string literal and no
> format arguments' errors are already fixed in upstream 4.9d.

Yes, and in the forthcoming -3 I fixed a bunch more that were exposed
when I compiled with -std=c11.

See attached patch.

Regards,
Branden

[this-one-goes-to-c11.patch (text/x-diff, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #27 received at 859751@bugs.debian.org (full text, mbox, reply):

From: Graham Inggs <ginggs@debian.org>

To: 859751@bugs.debian.org

Subject: Re: Bug#859751: xtrs: please pass buildflags

Date: Fri, 7 Apr 2017 20:08:05 +0200

On 7 April 2017 at 19:06, G. Branden Robinson
<g.branden.robinson@gmail.com> wrote:
> All of this hardening stuff, as I understand it, involves mitigation
> strategies for unsafe memory usage in the C language family in the ELF
> object file format.

It's not only hardening stuff, it's whatever flags someone building
the package locally would like, e.g.
one could 'export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed' from
debian/rules and expect everything to be linked with that option.

Message #32 received at 859751@bugs.debian.org (full text, mbox, reply):

From: "G. Branden Robinson" <g.branden.robinson@gmail.com>

To: Graham Inggs <ginggs@debian.org>, 859751@bugs.debian.org

Subject: Re: Bug#859751: xtrs: please pass buildflags

Date: Sat, 8 Apr 2017 13:08:27 -0400

At 2017-04-07T20:08:05+0200, Graham Inggs wrote:
> On 7 April 2017 at 19:06, G. Branden Robinson
> <g.branden.robinson@gmail.com> wrote:
> > All of this hardening stuff, as I understand it, involves mitigation
> > strategies for unsafe memory usage in the C language family in the ELF
> > object file format.
> 
> It's not only hardening stuff, it's whatever flags someone building
> the package locally would like, e.g.
> one could 'export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed' from
> debian/rules and expect everything to be linked with that option.

Ah, okay.  That melts my objections away like butter.

It looks like no great effort is required to address this; the problem
is that the compile_rom target in the Makefile is the only one that
invokes $(CC) without passing $(LDFLAGS).  With your argument above I
can even justify recommending this change to upstream.

Thanks for the discussion!

Regards,
Branden

Send a report that this bug log contains spam.