Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Junling Zheng <zhengjunling@huawei.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: "peifeiyue@huawei.com" <peifeiyue@huawei.com>,
	OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] file: remove the original magic.h
Date: Sat, 28 Mar 2015 17:37:19 +0800	[thread overview]
Message-ID: <5516764F.8050805@huawei.com> (raw)
In-Reply-To: <1427532804.14020.220.camel@linuxfoundation.org>

On 2015/3/28 16:53, Richard Purdie wrote:
> On Sat, 2015-03-28 at 10:36 +0800, Junling Zheng wrote:
>> I backport some commits from upstream to fix CVE-2014-9620, and some of them involve the modifying of magic.h.in:
>>
>> 90018fe22ff8b74a22fcd142225b0a00f3f12677
>> 6ce24f35cd4a43c4bdd249e8e0c4952c1f8eac67
>> 0056ec32255de1de973574b0300161a1568767d6
>> 09e41625c999a2e5b51e1092f0ef2432a99b5c33
>> ce90e05774dd77d86cfc8dfa6da57b32816841c4
>>
>> And the final difference between magic.h and magic.h.in is:
>>
>> z00238152@Patch-Test:file-5.14>0$ diff -u src/magic.h src/magic.h
>> magic.h     magic.h.in
>> z00238152@Patch-Test:file-5.14>0$ diff -u src/magic.h src/magic.h.in
>> --- src/magic.h	2015-03-28 02:01:46.000000000 +0000
>> +++ src/magic.h.in	2015-03-28 02:01:47.000000000 +0000
>> @@ -74,7 +74,7 @@
>>  #define	MAGIC_NO_CHECK_FORTRAN	0x000000 /* Don't check ascii/fortran */
>>  #define	MAGIC_NO_CHECK_TROFF	0x000000 /* Don't check ascii/troff */
>>
>> -#define MAGIC_VERSION		514	/* This implementation */
>> +#define MAGIC_VERSION		X.YY	/* This implementation */
>>
>>
>>  #ifdef __cplusplus
>> @@ -100,7 +100,12 @@
>>  int magic_list(magic_t, const char *);
>>  int magic_errno(magic_t);
>>
>> -#define MAGIC_PARAM_MAX_RECURSION	0
>> +#define MAGIC_PARAM_INDIR_MAX		0
>> +#define MAGIC_PARAM_NAME_MAX		1
>> +#define MAGIC_PARAM_ELF_PHNUM_MAX	2
>> +#define MAGIC_PARAM_ELF_SHNUM_MAX	3
>> +#define MAGIC_PARAM_ELF_NOTES_MAX	4
>> +
>>  int magic_setparam(magic_t, int, const void *);
>>  int magic_getparam(magic_t, int, void *);
>>
>>
>> So, if Makefile doesn't generate a new magic.h, there will be some "symbol undeclared" errors during compiling.
>>
>> By the way, the upstream code has only magic.h.in, and no magic.h, which only exists in release version tarballs.
>>
>> And I think the original magic.h is redundant.
> 
> We ran into this problem in our branches. You need to ensure that your
> CVE patches just touch magic.h.in and *not* magic.h. If you do that, the
> timestamp of magic.h.in will be more recent that magic.h and your build
> will function correctly.
> 
> The problem is that patch can patch those two files "at the same time"
> on fast machines. You should never patch generated filed in patches in
> OE in general.
> 
> Cheers,
> 
> Richard
>
Hi, Richard

You're right. My CVE patches indeed touch the original magic.h, and that's also why this problem reproduces probabilistic.

I remove the modifying of magic.h in my patches, and this problem seems to be fixed.

However, I still think the origin magic.h is confusing and redundant...:)

Thanks,

Junling



  reply	other threads:[~2015-03-28  9:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-26  9:18 [PATCH] file: remove the original magic.h Junling Zheng
2015-03-26  9:54 ` Richard Purdie
2015-03-26 11:31   ` Junling Zheng
2015-03-26 11:58     ` Jack Mitchell
2015-03-26 12:58       ` Junling Zheng
2015-03-26 13:08         ` Burton, Ross
2015-03-27  3:31           ` Junling Zheng
2015-03-27  9:56             ` Burton, Ross
2015-03-28  2:36               ` Junling Zheng
2015-03-28  8:53                 ` Richard Purdie
2015-03-28  9:37                   ` Junling Zheng [this message]
2015-03-28 11:05                     ` Richard Purdie
2015-03-30  1:49                       ` Junling Zheng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5516764F.8050805@huawei.com \
    --to=zhengjunling@huawei.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=peifeiyue@huawei.com \
    --cc=richard.purdie@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox