Bug#389934: severity of 389934 is important
severity 389934 serious thanks On Sun, Nov 26, 2006 at 04:24:22AM -080O0, Steve Langasek wrote: > Hi Bill, > > So my own opinion is that this class of bug should not be RC, at least when > the embedded rpath doesn't lie in an obviously user-writable space such as > /home or /tmp. If you feel strongly that these should be RC, please go > ahead and re-upgrade them. But you may also want to look at > <[EMAIL PROTECTED]>, posted to debian-release by a member of the > security team. Hello Steve, Thanks for the pointer. There is a difference though, between updating a stable release and fixing a new stable release. It seems to me that the security team is unwilling to fix the issue because it is too much work for little benefit for them and require to modify the package build system which is always something fragile that should not be done for stable update. However, the best course of action is to fix these bugs for Etch so that the release team does not have to make such compromise between stability and security. It is possible to achieve that thanks to lintian and indeed I have reported all such bugs already. If we do not fix them, we run the risk that a future upload of the packages introduce rpath pointing to more problematic locations and go unnoticed. Some of such bugs depends whether the package is installed when building itself. This might point to a larger problem with the packages that might link with the wrong version of libraries. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large blue swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389934: severity of 389934 is important
Hi Bill, On Mon, Nov 20, 2006 at 07:13:14PM +0100, [EMAIL PROTECTED] wrote: > On Thu, Sep 28, 2006 at 02:31:19PM -0700, Steve Langasek wrote: > > # Automatically generated email from bts, devscripts version 2.9.21 > > severity 389934 important > I don't see how you reached this conclusion. Users should be able > to rebuild packages without introducing security holes. Users should > be allowed to have users writable /buildd directory since it is > not a FHS mandated location. Add to that the directory /buildd is only > due to the way the buildd are setup currently. This detail of buildd configuration is one that isn't likely to change soon, so I don't think there's any real risk of these problems becoming exploitable as a result of rebuilds in stable. Users who have /buildd directories writable by untrusted users: possible, but fairly unlikely and obviously not a problem by default. Rebuilds in user home directories: this vector requires that a local rebuild of a package be done in the home directory of an untrusted user and then installed, or done in the home directory of a trusted user and then distributed to a system where a user of the same name exists and is untrusted. While plausible, this is also improbable. So my own opinion is that this class of bug should not be RC, at least when the embedded rpath doesn't lie in an obviously user-writable space such as /home or /tmp. If you feel strongly that these should be RC, please go ahead and re-upgrade them. But you may also want to look at <[EMAIL PROTECTED]>, posted to debian-release by a member of the security team. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389934: severity of 389934 is important
severity 389934 important thanks * Bill Allombert ([EMAIL PROTECTED]) [061126 07:27]: > However, the best course of action is to fix these bugs for Etch so that > the release team does not have to make such compromise between > stability and security. It is possible to achieve that thanks to lintian > and indeed I have reported all such bugs already. I fully agree to this statement. However, looking at the release policy I don't see how this bug is RC (though I really wish the bugs to disappear). Removal of all rpaths seem to be a typical release goal, and please feel free to attack them in future as such (i.e. severity important, 0-days-NMU policy applies). Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389934: severity of 389934 is important
On Mon, Nov 27, 2006 at 08:42:17AM +0100, Andreas Barth wrote: > severity 389934 important > thanks I upgraded the severity with permission from Steve. > * Bill Allombert ([EMAIL PROTECTED]) [061126 07:27]: > > However, the best course of action is to fix these bugs for Etch so that > > the release team does not have to make such compromise between > > stability and security. It is possible to achieve that thanks to lintian > > and indeed I have reported all such bugs already. > > I fully agree to this statement. However, looking at the release policy > I don't see how this bug is RC (though I really wish the bugs to > disappear). > > Removal of all rpaths seem to be a typical release goal, and please feel > free to attack them in future as such (i.e. severity important, > 0-days-NMU policy applies). I reported the bugs in March, then again in September. Unfortunatey new rpath got added in between. This one bug was reported two month ago, not today. As far as I am concerned, this is not a release goal, just basic sanity of the distribution, much like checking packages actually build from source. Cheers, Bill. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389934: severity of 389934 is important
* Bill Allombert ([EMAIL PROTECTED]) [061127 15:20]: > I upgraded the severity with permission from Steve. Yes. Nobody said you did something wrong. > As far as I am concerned, this is not a release goal, just basic > sanity of the distribution, much like checking packages actually > build from source. Actually, I agree that rpaths should not exist. Steve however convinced me today that we won't pull packages of Etch for this reason (basically, it is not in the release policy, and I'm not intending to change release policy) - I see that as good candidate for Lenny's release policy, though I prefer it to go via release goal in the policy (but that's something to be discussed/decided later on). Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
