Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

71–80 of 159 posts

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

#71

Post by bonzini »

chubot wrote: post #36
proctor wrote: post #29

this strongly reminds me of the hn post from five days back in which the main thread talked at some length about a very similar scenario > "He missed a big one: you have no way to stop Linux distributions from hacking up your software, and you'll suffer the consequences of whatever they do." https://news.ycombinator.com/item?id=19935648

Yeah I thought of the same comment. That is unfortunate. Maybe Debian is more respectful since it's open source not backed by a company with enterprise customers?

Not really, remember the ssh key fiasco which was also due to a Debian-only patch.

(Disclaimer: I work for Red Hat)

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

#72

Post by Kalium »

lstamour wrote: post #70
Kalium wrote: post #69

Earlier quoted context omitted.

Ah! Thank you for clarifying. That said, going up a directory would seem to imply that dstat could easily be loading completely arbitrary code from a directory it has no exclusive claim to and thus cannot meaningfully trust. Indeed, as I understand `share/` that is exactly the point. This really doesn't strike me as being a safe thing to do, and I can readily see why the author would reject it on security grounds. Th…

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.

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

#73

Post by bonzini »

loeg wrote: post #54
billfruit wrote: post #45

Earlier quoted context omitted.

But isn't red hat calling their version 'pcp-dstat' and not simply 'dstat', so they aren't shipping with the exact same name.

They install a symlink from plain "dstat" to pcp-dstat. That's the exact same name part and plausibly objectionable.

That is done so that existing scripts keep working. Nobody complains about the LLVM linker installing itself as /usr/bin/ld, or systemd providing /sbin/init, do they?

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

#74

Post by zaphirplane »

dagwieers wrote: post #49
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…

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

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

#75

Post by mehrdadn »

lstamour wrote: post #62
rurban wrote: post #56

Earlier quoted context omitted.

You added a security problem. The fix is obvious for everybody working in security, but it's questionable if it should be discussed there.

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.

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

#76

Post by zonidjan »

clhodapp wrote: post #63

Devil's advocate: Isn't this kind of behavior how we ended up with what became the POSIX command-line utilities? A bunch of people re-implementing and extending each other's stuff without changing the name? I know that the word has changed a bit since then and that it's a bit different to appropriate a soul-less corporation's command names vs an individual volunteer.. It just happened to strike me as odd at the momen…

I don't know that massively popular utilities were ever "reimplemented" with the same name. Ported, or forked, or extended, but not reimplemented. It's not clear to me if pcp-dstat is a fork or a total rewrite.

Also, most of those utilities were named things which solely described what they did. It's a bit different to make a new "cut" vs a new "clhodapp".

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

#77

Post by mehrdadn »

nemothekid wrote: post #68
jasonkester wrote: post #60

Earlier quoted context omitted.

No, the original was finished . Feature complete, bug free software doesn’t need to have patches released every week. That is the ultimate goal of a small utility like this. It’s a shame that so many developers mistake this state for “unmaintained”or “abandoned”.

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], ...

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

#78

Post by zonidjan »

nemothekid wrote: post #68
jasonkester wrote: post #60

Earlier quoted context omitted.

No, the original was finished . Feature complete, bug free software doesn’t need to have patches released every week. That is the ultimate goal of a small utility like this. It’s a shame that so many developers mistake this state for “unmaintained”or “abandoned”.

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…

Python 2 is EOL? Interesting. https://pythonclock.org/

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

#79

Post by appstateguy »

tedivm wrote: post #50
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…

Apparently reusing the name without talking to the author was a conscious decision on their behalf- https://bugzilla.redhat.com/show_bug.cgi?id=1614277#c7

meh. ultimately this is OSS. the maintainer was negligent. if you're not a good OSS maintainer, you don't deserve to maintain control. it's not reasonable to be indefinitely patient when the original author shows no initiative to maintain their project

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

#80

Post by appstateguy »

dagwieers wrote: post #30
codewiz wrote: post #11

Earlier quoted context omitted.

From the git changelog, it doesn't appear to be completely unmaintained, but not very vital either: https://github.com/dagwieers/dstat/commits/master Red Hat's announcement (posted in February 2019), also cites lack of Python 3 support as another reason for replacing the original dstat, but Python 3 compatibility was added last January.

Yeah, I added python 3 support after I learned that was the main reason for replacing it. It took me less than an hour to make it work on Python 3, including all (but 2) of the plugins. And given that PCP is using most of the original code, they must have made the same changes to get Python 3 support.

maybe you shouldn't have waited until the absolute last minute to do this or it wouldn't have been replaced.
Post reply on HN