GNU bug report logs -
#7379
On the fix for CVE-2009-4029 Automake security fix for 'make dist*'
Previous Next
Reported by: Behdad Esfahbod <behdad <at> behdad.org>
Date: Thu, 11 Nov 2010 21:14:03 UTC
Severity: normal
Tags: wontfix
Done: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 7379 in the body.
You can then email your comments to 7379 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
owner <at> debbugs.gnu.org, help-debbugs <at> gnu.org
:
bug#7379
; Package
debbugs.gnu.org
.
(Thu, 11 Nov 2010 21:14:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Behdad Esfahbod <behdad <at> behdad.org>
:
New bug report received and forwarded. Copy sent to
help-debbugs <at> gnu.org
.
(Thu, 11 Nov 2010 21:14:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi guys,
I recently read about the fix for the chmod 777 issue. Just wanted to note
that it may be preferred if you continue with chmod 777 and instead fix the
problem by moving the dist dir inside another direction that is 700.
The reason a 777 mod in the tarball may be preferred (or 775 for that matter,
but not 755) is for systems that users of a group are using sticky-bit on the
group to share writable files with eachother. By letting the umask decide
what bits should not be set you you enable such settings, whereas using 755,
the user expanding the tarball has to reset it to 775 or the rest of the group
cannot write to it.
Cheers,
behdad
Information forwarded
to
owner <at> debbugs.gnu.org, bug-automake <at> gnu.org
:
bug#7379
; Package
automake
.
(Thu, 11 Nov 2010 21:25:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 7379 <at> debbugs.gnu.org (full text, mbox):
[ This was sent to "bugs-automake <at> gnu", apparently an alias for
"bug-automake". Because debbugs was unaware of this, it was assigned
to the default package, debbugs itself. I have reassigned it to
automake and am resending this so it goes to the right list.
The alias (along with "automake-bugs?" has been added to debbugs for
the future. ]
Original message:
From: Behdad Esfahbod <behdad <at> behdad.org>
To: bugs-automake <at> gnu.org
Subject: On the fix for CVE-2009-4029 Automake security fix for 'make dist*'
Date: Thu, 11 Nov 2010 16:17:22 -0500
Hi guys,
I recently read about the fix for the chmod 777 issue. Just wanted to note
that it may be preferred if you continue with chmod 777 and instead fix the
problem by moving the dist dir inside another direction that is 700.
The reason a 777 mod in the tarball may be preferred (or 775 for that matter,
but not 755) is for systems that users of a group are using sticky-bit on the
group to share writable files with eachother. By letting the umask decide
what bits should not be set you you enable such settings, whereas using 755,
the user expanding the tarball has to reset it to 775 or the rest of the group
cannot write to it.
Cheers,
behdad
Information forwarded
to
owner <at> debbugs.gnu.org, bug-automake <at> gnu.org
:
bug#7379
; Package
automake
.
(Sat, 13 Nov 2010 07:56:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 7379 <at> debbugs.gnu.org (full text, mbox):
[ Thanks Glenn for rerouting the bug report! ]
Hi Behdad,
> From: Behdad Esfahbod
> Subject: On the fix for CVE-2009-4029 Automake security fix for 'make dist*'
> Date: Thu, 11 Nov 2010 16:17:22 -0500
> I recently read about the fix for the chmod 777 issue. Just wanted to note
> that it may be preferred if you continue with chmod 777 and instead fix the
> problem by moving the dist dir inside another direction that is 700.
>
> The reason a 777 mod in the tarball may be preferred (or 775 for that matter,
> but not 755) is for systems that users of a group are using sticky-bit on the
> group to share writable files with eachother. By letting the umask decide
> what bits should not be set you you enable such settings, whereas using 755,
> the user expanding the tarball has to reset it to 775 or the rest of the group
> cannot write to it.
Thanks for the bug report. At the time we fixed this, we considered
going this other option. It was a fairly close call. The downside of
the solution you suggest was that it would complicate 'make dist' a
little, and maybe break a few packages that rely on the exact subdir
structure of $(distdir) being one directory below the toplevel build
directory. Such reliance is probably bad style anyway, but we didn't
know of many uses that would benefit from more relaxed permission inside
the tarball. How useful is that for you, how come you don't use a
version control repository rather than an extracted tarball for
collaborative work (honest question)?
You are the first person to report this in the 12 months since we
released fixed versions of Automake. I don't have other data to go on
but it thus doesn't seem to be a very wide spread issue to me, and
there's the obvious workaround of a chmod -R after extraction, no?
I'm open to arguments here, but so far I'm slightly leaning toward
keeping the current behavior.
Thanks,
Ralf
Information forwarded
to
owner <at> debbugs.gnu.org, bug-automake <at> gnu.org
:
bug#7379
; Package
automake
.
(Wed, 17 Nov 2010 16:41:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 7379 <at> debbugs.gnu.org (full text, mbox):
Hi Ralf,
Scroll down for my comments.
On 11/13/10 03:00, Ralf Wildenhues wrote:
> [ Thanks Glenn for rerouting the bug report! ]
>
> Hi Behdad,
>
>> From: Behdad Esfahbod
>> Subject: On the fix for CVE-2009-4029 Automake security fix for 'make dist*'
>> Date: Thu, 11 Nov 2010 16:17:22 -0500
>
>> I recently read about the fix for the chmod 777 issue. Just wanted to note
>> that it may be preferred if you continue with chmod 777 and instead fix the
>> problem by moving the dist dir inside another direction that is 700.
>>
>> The reason a 777 mod in the tarball may be preferred (or 775 for that matter,
>> but not 755) is for systems that users of a group are using sticky-bit on the
>> group to share writable files with eachother. By letting the umask decide
>> what bits should not be set you you enable such settings, whereas using 755,
>> the user expanding the tarball has to reset it to 775 or the rest of the group
>> cannot write to it.
>
> Thanks for the bug report. At the time we fixed this, we considered
> going this other option. It was a fairly close call. The downside of
> the solution you suggest was that it would complicate 'make dist' a
> little, and maybe break a few packages that rely on the exact subdir
> structure of $(distdir) being one directory below the toplevel build
> directory. Such reliance is probably bad style anyway, but we didn't
> know of many uses that would benefit from more relaxed permission inside
> the tarball. How useful is that for you, how come you don't use a
> version control repository rather than an extracted tarball for
> collaborative work (honest question)?
>
> You are the first person to report this in the 12 months since we
> released fixed versions of Automake. I don't have other data to go on
> but it thus doesn't seem to be a very wide spread issue to me, and
> there's the obvious workaround of a chmod -R after extraction, no?
When I read about the fix, this was the first thing that popped into my mind.
I didn't actually hit this issue.
But I agree: most probably no one actually relies on the permissions being
correct right off the tarball anyway.
Cheers,
behdad
> I'm open to arguments here, but so far I'm slightly leaning toward
> keeping the current behavior.
>
> Thanks,
> Ralf
>
Information forwarded
to
owner <at> debbugs.gnu.org, bug-automake <at> gnu.org
:
bug#7379
; Package
automake
.
(Thu, 16 Dec 2010 23:14:02 GMT)
Full text and
rfc822 format available.
Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):
Hello Ralf and Behdad.
On Wednesday 17 November 2010, Behdad Esfahbod wrote:
>
> On 11/13/10 03:00, Ralf Wildenhues wrote:
>>
>> You are the first person to report this in the 12 months since we
>> released fixed versions of Automake. I don't have other data to go on
>> but it thus doesn't seem to be a very wide spread issue to me, and
>> there's the obvious workaround of a chmod -R after extraction, no?
>>
> When I read about the fix, this was the first thing that popped into my mind.
> I didn't actually hit this issue.
>
> But I agree: most probably no one actually relies on the permissions being
> correct right off the tarball anyway.
>
> Cheers,
> behdad
>
Given this rationale, would it be ok to close this bug now?
Regards,
Stefano
Information forwarded
to
owner <at> debbugs.gnu.org, bug-automake <at> gnu.org
:
bug#7379
; Package
automake
.
(Thu, 16 Dec 2010 23:14:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-automake <at> gnu.org
:
bug#7379
; Package
automake
.
(Fri, 17 Dec 2010 04:54:03 GMT)
Full text and
rfc822 format available.
Message #23 received at 7379 <at> debbugs.gnu.org (full text, mbox):
On 12/16/10 18:19, Stefano Lattarini wrote:
> Hello Ralf and Behdad.
>
> On Wednesday 17 November 2010, Behdad Esfahbod wrote:
>>
>> On 11/13/10 03:00, Ralf Wildenhues wrote:
>>>
>>> You are the first person to report this in the 12 months since we
>>> released fixed versions of Automake. I don't have other data to go on
>>> but it thus doesn't seem to be a very wide spread issue to me, and
>>> there's the obvious workaround of a chmod -R after extraction, no?
>>>
>> When I read about the fix, this was the first thing that popped into my mind.
>> I didn't actually hit this issue.
>>
>> But I agree: most probably no one actually relies on the permissions being
>> correct right off the tarball anyway.
>>
>> Cheers,
>> behdad
>>
> Given this rationale, would it be ok to close this bug now?
Yes, as far as I'm concerned.
behdad
> Regards,
> Stefano
>
Information forwarded
to
owner <at> debbugs.gnu.org, bug-automake <at> gnu.org
:
bug#7379
; Package
automake
.
(Fri, 17 Dec 2010 04:55:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-automake <at> gnu.org
:
bug#7379
; Package
automake
.
(Fri, 17 Dec 2010 14:13:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 7379 <at> debbugs.gnu.org (full text, mbox):
tags 7379 wontfix
close 7379
thanks
On Friday 17 December 2010, Behdad Esfahbod wrote:
> On 12/16/10 18:19, Stefano Lattarini wrote:
> > Given this rationale, would it be ok to close this bug now?
>
> Yes, as far as I'm concerned.
>
> behdad
>
I'm closing the bug then. I'm also tagging it as "wontfix", since
it referred to a real (albeit minor) limitation which we agreed it's
better not to lift.
Thanks,
Stefano
Added tag(s) wontfix.
Request was from
Stefano Lattarini <stefano.lattarini <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Fri, 17 Dec 2010 14:13:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to Behdad Esfahbod <behdad <at> behdad.org>
Request was from
Stefano Lattarini <stefano.lattarini <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Fri, 17 Dec 2010 14:13:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 15 Jan 2011 12:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 14 years and 163 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.