------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.0-desktop-plasma_20170623-211337 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-6.3.0 * Available Python interpreters, in order of preference: [1] python3.4 [2] python2.7 (fallback) [3] pypy3 (fallback) Available Ruby profiles: [1] ruby21 (with Rubygems) [2] ruby22 (with Rubygems) * java-config: The following VMs are available for generation-2: *) IcedTea JDK 3.4.0 [icedtea-bin-8] Available Java Virtual Machines: [1] icedtea-bin-8 system-vm
Created attachment 480966 [details] emerge-info.txt
Created attachment 480968 [details] emerge-history.txt
Created attachment 480970 [details] environment
Created attachment 480972 [details] etc.portage.tbz2
Created attachment 480974 [details] logs.tbz2
Created attachment 480976 [details] net-analyzer:vnstat-1.17-r1:20170705-063808.log
Created attachment 480978 [details] temp.tbz2
Created attachment 480980 [details] tests.tbz2
This bug was brought to my attention by the the github commit comment https://github.com/vergoh/vnstat/commit/4e1b097d6062fcee67a386302bc074140f7059d8#commitcomment-24957839. After some digging, it looks like the test error is caused by the src_prepare() changes in vnstat-1.17-r1.ebuild which comment out a line in the example configuration file before the tests are executed. The tests in turn are using that specific line to validate that parsing the configuration file works correctly. Patching the test as done in https://gitweb.gentoo.org/repo/gentoo.git/commit/net-analyzer/vnstat?id=d7020024ba12df55773ebdd034a800aafe0a7124 causes this feature test to be essentially ignored which defeats the purpose of those tests. If any modifications to the configuration file is needed, I'd suggest doing such changes after the tests have been executed.
Apparently the buggy behaviour was introduced in bug #522226. I have reverted an earlier patch that fixed the test now and reverted the configuration back to the default, since that was the change that triggered the src_test() failure and added precisely nothing to the configuration that individual users shouldn't be able to figure out for themselves.
(In reply to Jeroen Roovers from comment #10) > Apparently the buggy behaviour was introduced in bug #522226. I have > reverted an earlier patch that fixed the test now and reverted the > configuration back to the default, since that was the change that triggered > the src_test() failure and added precisely nothing to the configuration that > individual users shouldn't be able to figure out for themselves. That's ridiculous and you know it. Like upstream said, no reason to revert *everything*, just modify configuration *after* src_test(). Now you brought back a bunch of already solved issues. If you don't understand what the configuration change was all about ASK but don't just revert if YOU don't understand. The default installation on OpenRC systems is now vulnerable to a priv escalation via PID file due to the partial revert, nice job!
(In reply to Thomas Deutschmann from comment #11) > That's ridiculous and you know it. Calm down. > Like upstream said, no reason to revert > *everything*, just modify configuration *after* src_test(). Now you brought > back a bunch of already solved issues. I might have missed some of the more arcane sed scripts. > nice job! Thanks!
(In reply to Thomas Deutschmann from comment #11) > If you don't understand what the > configuration change was all about ASK but don't just revert if YOU don't > understand. You mean you can dump anything into the tree without adding useful comments or explanations and expect people to ask you what your changes are for? > The default installation on OpenRC systems is now vulnerable to > a priv escalation via PID file due to the partial revert, nice job! Where is that security bug report, you say?
(In reply to Jeroen Roovers from comment #12) > (In reply to Thomas Deutschmann from comment #11) > > That's ridiculous and you know it. > > Calm down. Ehm, did I revert *everything* because I didn't understand the scope of a bug report and decided this is so critical I cannot wait for a response from the bad developer who probably caused the breakage of my hole package? :> But judging from your commit messages it looks like you had your fun. (In reply to Jeroen Roovers from comment #13) > Where is that security bug report, you say? Just for the records: https://gitweb.gentoo.org/repo/gentoo.git/commit/net-analyzer/vnstat?id=fa49bd03d6ed83cf14b30542dc1e57f9549d1154 fixed the potential security vulnerability I mentioned in comment #11.
s/my hole package/my holy package/ Yes I know that this typo ruined everything.
(In reply to Thomas Deutschmann from comment #14) > Ehm, did I revert *everything* because I didn't understand the scope of a > bug report and decided this is so critical I cannot wait for a response from > the bad developer who probably caused the breakage of my hole package? :> Nobody did that. > But judging from your commit messages it looks like you had your fun. I don't follow. I was cleaning up your mess. > > Where is that security bug report, you say? ... > Just for the records: > https://gitweb.gentoo.org/repo/gentoo.git/commit/net-analyzer/ > vnstat?id=fa49bd03d6ed83cf14b30542dc1e57f9549d1154 fixed the potential > security vulnerability I mentioned in comment #11. You're on the security team and you fix issues quietly in unstable revisions without reporting them to the community or even explaining to maintainers what the issues are in your commit messages, while the stable version remains apparently vulnerable to some kind of attack that you haven't actually exposed? So again, where is that security bug report? We're all waiting to see the vulnerability exposed. And please stop responding here now, as this issue is fixed and closed.
