Dstat project ended due to RedHat replacing it with its own dstat tool • Hacker News Board

Re: Dstat project ended due to RedHat replacing it with its own dstat tool

#101

Post by bonzini » Thu, May 23, 2019, 10:17 AM UTC

mehrdadn wrote: post #77

nemothekid wrote: post #68

Earlier quoted context omitted.

The software isn't finished if the runtime it runs on has been EOL'd. dstat, up until earlier this year (a couple weeks before that announcement), did not support Python 3 - and the author may have just merged RedHat's changes anyways. RedHat's "fork" supported Python3 for months at that point. Yes, it was a useful tool, and what RedHat did was shitty but I can understand the motivation for not wanting to keep a Pyth…

> I can understand the motivation for not wanting to keep a Python2 install around just for one tool. I don't use a Red Hat distro but would this really only be one tool? On Arch I see the following packages depend on python2: mercurial [required], git [optional], texlive-core [optional], graphviz [optional], ...

RHEL8 doesn't include a Python 2 runtime that is supported for the whole life of the distro. There are a couple exceptions where Python 2 is used at build time, but that's it.

At the point when people started to work on pcp-dstat, it was clear that if you wanted X in the base distribution it had to be Python 3 compatible.

Re: Dstat project ended due to RedHat replacing it with its own dstat tool

#102

Post by contras1970 » Thu, May 23, 2019, 10:40 AM UTC

Kalium wrote: post #72

lstamour wrote: post #70

Earlier quoted context omitted.

If absolute share/ access were the problem, the line below wouldn’t hard-code it twice: https://github.com/dagwieers/dstat/pull/50/files The only bug in this PR that I can see is it might assume the system plugins are more important than the local overrides. Generally you’d put this sort of path in the least priority, to allow for /usr/local to override. That said, obviously hard-coding paths is worse than simply hav…

My read is that it's more that access control of `../share` in an unknown part of the filesystem is a matter for some concern. Given that the binary can be put basically anywhere, it would seem to be perilously close to CWD.

no, it's just cargocult security.

edit after your reply: if you install in /tmp, you'll end up with /tmp/bin/dstat and /tmp/share/dstat. you're concerned that an attacker could smuggle something into /tmp/share/dstat, but /tmp/bin/dstat is of no worry? what exactly is the threat here?

> access control of `../share` in an unknown part of the filesystem is a matter for some concern. Given that the binary can be put basically anywhere, it would seem to be perilously close to CWD.

another edit since i cannot reply to you: do you have any examples of the "threat model [which] includes that you can't trust every part of the filesystem you're working from"? something concrete, specific. a particular install prefix that would let you create $prefix/bin/dstat but $prefix/share/dstat would be dangerous.

aaand, see my reply at https://news.ycombinator.com/item?id=19989237

Re: Dstat project ended due to RedHat replacing it with its own dstat tool

#103

Post by dagwieers » Thu, May 23, 2019, 10:42 AM UTC

devnullbyte wrote: post #95

tedivm wrote: post #24

Having read through this post and the previous comments[1] I have to say that RedHat did the right thing in the completely worst possible way. Stealing the project name was a mistake. The authors are right to be upset by the fact that people used to get their project when they did "yum install dstat" but now are getting a completely different (and not completely compatible) project. I think a lot of the friction coul…

I disagree, they were right to use the same namespace and its questionable how you conflate that to stealing. If something is abandoned, how can you steal it? The project was dead, PR's and issues were ignored and the lack of Python 3 support was a huge issue (which the developer pathetically tried to shut down discussion over by releasing a python 3 port just hours before closing the project). Changing the name spac…

Nobody stepped up to maintain the project, not even Red Hat. Some people have offered help, and I have send out a few GitHub invitations to people that offered, but no takers.

I assume people offering to help only wanted to see their own contributions merged.

I shouldn't be surprised people here take positions while not having been involved in the project or know the whole history.

In my opinion, stopping the project was the only sensible thing to do at this point. Red Hat replacing the tool with one of their own (which I wholeheartedly disagree with for various reasons) created a dead-end. It's the final blow to a dying project.

Wrt. Python 3 support, I simply did it because it was so easy to do, not because I thought this would be a game-changer. But hey, please do read into whatever fits your narrative :-)

Re: Dstat project ended due to RedHat replacing it with its own dstat tool

#104

Post by dagwieers » Thu, May 23, 2019, 10:46 AM UTC

dralley wrote: post #52

dagwieers wrote: post #49

Earlier quoted context omitted.

It didn't just slip their mind, they did not really care: https://bugzilla.redhat.com/show_bug.cgi?id=1614277#c7 The decision to do this was made before June 2018, 18 months after the last activity. One of the reasons cited was lack of activity, but that is no thanks to them, I guess. That is why I am convinced the goal was to replace it from the onset, there was no interest in helping out the project. In fact "no ac…

I totally agree that they should have left a note on the issue tracker - even if they thought it would go unread. However I think you're being a little unfair on this one point. >there was no interest in helping out the project. They saw that people were filing issues and making pull requests and that those people were getting total radio silence. I can understand how someone might think "well, people are already try…

Huh? Jumping to conclusions while not knowing all the facts. Please read up on the discussions that we had _after_ Red Hat made this decision. Their decision was made, end of discussion.

I am sure they made a sound business decision, and I think as a result of that I made the right personal decision. And here we are now having this meta-discussion with people not having a clue. Welcome !

Re: Dstat project ended due to RedHat replacing it with its own dstat tool

#105

Post by Kalium » Thu, May 23, 2019, 10:49 AM UTC

contras1970 wrote: post #102

Kalium wrote: post #72

Earlier quoted context omitted.

My read is that it's more that access control of `../share` in an unknown part of the filesystem is a matter for some concern. Given that the binary can be put basically anywhere, it would seem to be perilously close to CWD.

no, it's just cargocult security. edit after your reply: if you install in /tmp, you'll end up with /tmp/bin/dstat and /tmp/share/dstat. you're concerned that an attacker could smuggle something into /tmp/share/dstat, but /tmp/bin/dstat is of no worry? what exactly is the threat here? > access control of `../share` in an unknown part of the filesystem is a matter for some concern. Given that the binary can be put bas…

I don't know. If your threat model includes that you can't trust every part of the filesystem you're working from, being extra paranoid about it isn't the most unreasonable thing in the world.

EDIT: A sibling points out the issue in more detail - https://news.ycombinator.com/item?id=19989237

Re: Dstat project ended due to RedHat replacing it with its own dstat tool

#106

Post by dagwieers » Thu, May 23, 2019, 10:53 AM UTC

jeltz wrote: post #99

dagwieers wrote: post #49

Earlier quoted context omitted.

It didn't just slip their mind, they did not really care: https://bugzilla.redhat.com/show_bug.cgi?id=1614277#c7 The decision to do this was made before June 2018, 18 months after the last activity. One of the reasons cited was lack of activity, but that is no thanks to them, I guess. That is why I am convinced the goal was to replace it from the onset, there was no interest in helping out the project. In fact "no ac…

While Redhat did not handle this situation well you are also being very unfair to them. Why would they waste their time trying to contribute to a dead project? If I see that patches do not get merged and that bug reports go unanswered I will not bother doing anything because I know my time will be wasted, and I do not fault RedHat for doing the same. What they should have done is tried to reach out to you before fork…

Unfair in what way?

They included in RHEL and sold it as part of their product when it suited them, and now they have replaced it because it suited them. That's fine, I don't have to agree.

Re: Dstat project ended due to RedHat replacing it with its own dstat tool

#107

Post by dagwieers » Thu, May 23, 2019, 10:53 AM UTC

zaphirplane wrote: post #74

dagwieers wrote: post #49

Earlier quoted context omitted.

It didn't just slip their mind, they did not really care: https://bugzilla.redhat.com/show_bug.cgi?id=1614277#c7 The decision to do this was made before June 2018, 18 months after the last activity. One of the reasons cited was lack of activity, but that is no thanks to them, I guess. That is why I am convinced the goal was to replace it from the onset, there was no interest in helping out the project. In fact "no ac…

Are you the person that used to maintain a bunch of rpm(s) ? Thanks a lot for doing that, it helped me a couple of times

Thanks :-)

Re: Dstat project ended due to RedHat replacing it with its own dstat tool

#108

Post by ben0x539 » Thu, May 23, 2019, 10:57 AM UTC

gigatexal wrote: post #94

anthony_doan wrote: post #58

Earlier quoted context omitted.

> Why not come up with a new name for the project instead of rage quitting? Why should he change the project name when he originally have it first? Also why did you have to frame it as rage quitting?

It’s the way of the world that larger fish get to do as they please. A simple name change and he can continue to do his work. It’s the idea of turning the other cheek. That or trademark the name I guess.

Would redhat ship dstat under the new name?

Re: Dstat project ended due to RedHat replacing it with its own dstat tool

#109

Post by contras1970 » Thu, May 23, 2019, 11:00 AM UTC

mehrdadn wrote: post #75

lstamour wrote: post #62

Earlier quoted context omitted.

I can see how the original CVE patch removed using the current working directory for loading plugins, but it seems like less of a security issue to simply look up one directory relative to the current binary install, assuming the binary is stored in ./bin after being built and plugins would be stored in ./shared ... Now, it might be inconsiderate to look up a folder when one could be preconfigured based on a common r…

This isn't relative to the binary install, it's relative to argv[0]. It's the same security issue -- that argument is under user control. You can make a symlink to your target wherever you want and then argv[0] will be the symlink location. I don't think there is any secure way to get the current script path in Python.

so you install dstat in /usr/bin/dstat + /usr/share/dstat (because you are root), and an attacker creates /home/eve/bin/dstat with /home/eve/share/dstat/evil.py. why would you run /home/eve/bin/dstat? if eve can get you to run dstat from here ~/bin, why wouldn't she just have ~/bin/dstat with completely different contents?

i'm still convinced this is cargocult security.

Re: Dstat project ended due to RedHat replacing it with its own dstat tool

#110

Post by Macha » Thu, May 23, 2019, 11:00 AM UTC

mehrdadn wrote: post #92

Conan_Kudo wrote: post #90

Earlier quoted context omitted.

Mercurial 5.0 is Python 3 compatible. The Python code in Git is Python 3 compatible. I don't know about TeXLive or Graphviz, though...

Confused, so why is Python 2 a requirement? Name : mercurial Version : 5.0-1 Description : A scalable distributed SCM tool Depends On : python2 Optional Deps : tk: for the hgk GUI [installed] Required By : None Optional For : None Conflicts With : None Replaces : None Installed Size : 25.95 MiB

Possible options:

1. Some of mercurial's bundled plugins are not Py3 compatible (I recall reading a discussion as an outsider a while back that some plugins are planned to be ported to Rust, not Python 3, but that may have changed) 2. Nobody involved in packaging it for Arch has had time to verify mercurial 5 on python 3.