The hyprland codebase is... really bad code, if one has ever looked at it. This is unfortunately problematic in a few different ways. Glaring examples (you can find lots of badness if you read the codebase, though): The plugin API is amd64 exclusive, because it involves running llvm-nm on /proc/self/exe and then using an asm disassembler on the plugin to patch functions Insecurely creating /tmp/hypr and compiling/running code in it: https://www.openwall.com/lists/oss-security/2024/04/28/3 https://github.com/hyprwm/Hyprland/issues/5787#issuecomment-2081572992 Replying with: > Does it actually allow an attacker to do anything that can't > be done with hyprctl plugin load malware-plugin.so? > No. Someone needs access to write to /tmp/hypr, so... they > have to be running code on your system already, at which > point they can also rm -rf /. That's why this CVE is a joke. I consider it dangerous in both the short term and the long term to distribute this WM at all, but if people are going to use it, they should really be getting it from GURU instead. There are other issues with hyprland as well. The author is an edgelord and very combative with it. Quoting Sam from the oss-security report: > I haven't reported it upstream because of their hostility on other matters. Affects: dev-libs/hyprland-protocols dev-libs/hyprlang gui-libs/hyprcursor gui-wm/hyprland
My impression is that it's not a good fit for ::gentoo either way, given: * the high rate of releases (-> hard for a proxied-maint to keep up, and for proxy-maint to handle the PRs) * keeps adding new dependencies * questionable quality and now this (where upstream seem to have initially rejected it and then started tightening permissions; I think there may still be missing checks for when the directory already exists and you race hyprland starting though). I was the person who merged the PR to bring hyprland to ::gentoo and I regret it.
So far, the fixes seem to be: * https://github.com/hyprwm/Hyprland/commit/82a6fba6ec0c5a667582b9ad48adadc36bef2702 (refactoring) * https://github.com/hyprwm/Hyprland/commit/28c85619243e6320e75d7abcfe8244fa99d054dd * https://github.com/hyprwm/Hyprland/commit/b164e67d8b1f12420ec44a1c837af7923559ccf2 But it doesn't seem to notice if the directory already exists.
(Not to get onto how fragile this code is even if the TOCTOU stuff is sorted; it calls 'cc' and 'objdump' directly, it only works on amd64, ...)
I very strongly believe this bug to be politically motivated. Hyprland is a very popular WM. Removing it from ::gentoo would be a disservice to the Gentoo community. (In reply to Sam James from comment #1) > * the high rate of releases (-> hard for a proxied-maint to keep up, and for > proxy-maint to handle the PRs) > * keeps adding new dependencies Granted, but I think given the popularity of Hyprland, this can be allowed? It has more GitHub stars than Sway (not that GitHub stars are an absolute measure popularity, but it gives an idea). I personally do not mind the extra work. I'm adding dlan to CC who has been merging my PRs for Hyprland for a long time now. Dlan ought to have an opinion on whether Hyprland is too much work and warrants removal. > * questionable quality Another reason I believe this bug to be politically motivated. A lot of packages ought to be treecleaned if ::gentoo only allows upstreams with upstanding code quality. > and now this (where upstream seem to have initially rejected it and then > started tightening permissions; I think there may still be missing checks > for when the directory already exists and you race hyprland starting though). From what I gather, you posted about it on oss-security today, April 28th, and already upstream has pushed 3 commits that help with that? And it warrants removal anyway?
If it were politically motivated, why would I just be talking about my impression? I was planning on leaving another comment making clear I'm not insisting at all, too, and that it's an opinion and not something being overridden. I'm not sure what politically motivated would even mean here. I made the point about the regular fixes being needed precisely because I wanted your (and the rest of proxy-maint's) take on whether the pace is even a good fit for ::gentoo. Back when we first merged it to ::gentoo, we discussed that very problem, even. Eli filed this, I assume, because it feels like there's a lot of problems which pop up and this tipped him over the edge. I've been feeling a bit fed up for a while too. wrt the fixes: I meant more the derisive response from upstream, not the response time.
(In reply to Julien from comment #4) > I very strongly believe this bug to be politically motivated. Care to elaborate which politics you're referring to? :) > > * questionable quality > > Another reason I believe this bug to be politically motivated. A lot of > packages ought to be treecleaned if ::gentoo only allows upstreams with > upstanding code quality. I think there's a stark difference between "not upstanding code quality" and: - being authored by someone that disparages people for reporting security issues - proudly blogs about how the security issue is actually a genius move - thinks people who say that security matters when protecting yourself against other uids running on the same machine, must be telling a ridiculous joke "because they can just rm -rf /" and also: - only works on amd64, whereas gentoo is quite proudly a supporter of many, many other architectures But assuming you're right and this package is truly no different from other packages with questionable code -- this is why there's a QA team that tries to fix packages with bad code that is dangerous for user systems, and if they can't be fixed, QA does sometimes move to have packages removed from Gentoo due to quality concerns. So I don't actually understand your point. > > and now this (where upstream seem to have initially rejected it and then > > started tightening permissions; I think there may still be missing checks > > for when the directory already exists and you race hyprland starting though). > > From what I gather, you posted about it on oss-security today, April 28th, > and already upstream has pushed 3 commits that help with that? And it > warrants removal anyway? Given the attitude upstream has about it I'm skeptical of hyprland's overall security profile and don't think Gentoo should be condoning a project where you're at high risk of security vulnerabilities unless you can socially pressure the hyprland author into fixing it by getting world-renowned security researchers to call him out on twitter about it.
(In reply to Sam James from comment #5) > I made the point about the regular fixes being needed precisely because I > wanted your (and the rest of proxy-maint's) take on whether the pace is even > a good fit for ::gentoo. Back when we first merged it to ::gentoo, we > discussed that very problem, even. Yes, I recall somewhat even though it's been a while. I've given my opinion, and that is that I do not mind the frequent releases, or new dependencies. I enjoy maintaining packages in ::gentoo and I maintain very few so it is not a problem for me. Of course it's not only my opinion that matters on this since devs have to review my PRs, which is why I added dlan since he's been the one merging them most of the time for the past several months. > Eli filed this, I assume, because it feels like there's a lot of problems > which pop up and this tipped him over the edge. I've been feeling a bit fed > up for a while too. I'm missing some context here. I have no idea what "a lot of problems" mean in this context. On b.g.o there's very few Hyprland bugs, so that can't be it. (In reply to Eli Schwartz from comment #6) > Care to elaborate which politics you're referring to? :) Drew Devault's blog is a good place to start. > I think there's a stark difference between "not upstanding code quality" and: > > - being authored by someone that disparages people for reporting security > issues > - proudly blogs about how the security issue is actually a genius move > - thinks people who say that security matters when protecting yourself > against other uids running on the same machine, must be telling a ridiculous > joke "because they can just rm -rf /" I think a lot of people have made similar points about systemd > and also: > > - only works on amd64, whereas gentoo is quite proudly a supporter of many, > many other architectures See: https://wiki.gentoo.org/wiki/KEYWORDS > But assuming you're right and this package is truly no different from other > packages with questionable code -- this is why there's a QA team that tries > to fix packages with bad code that is dangerous for user systems, and if > they can't be fixed, QA does sometimes move to have packages removed from > Gentoo due to quality concerns. Usually, packages with vulnerabilities are masked. If upstream abandons the project or simply does not fix the vulnerability, then yes, at some point it should be dropped from ::gentoo. In this instance though, another option would be to simply hide hyprpm behind a USE flag and mask that USE flag, or simply not compile it. > So I don't actually understand your point. My point is that you are jumping at this opportunity (potential vulnerability discovered by Sam) to remove a package developed by an upstream you dislike. > Given the attitude upstream has about it I'm skeptical of hyprland's overall > security profile and don't think Gentoo should be condoning a project where > you're at high risk of security vulnerabilities unless you can socially > pressure the hyprland author into fixing it by getting world-renowned > security researchers to call him out on twitter about it. I'm not sure ::gentoo having Hyprland means it's condoning the project? As for the potential risk of security vulnerabilities, as I said above, if hyprpm remains a problem, we can hide it behind a masked USE flag or remove it entirely, depending on what the Security team deems best. As for the overall security profile of the project, that seems very subjective and to me.
(In reply to Julien from comment #4) > I very strongly believe this bug to be politically motivated. > > Hyprland is a very popular WM. Removing it from ::gentoo would be a > disservice to the Gentoo community. > > (In reply to Sam James from comment #1) > > * the high rate of releases (-> hard for a proxied-maint to keep up, and for > > proxy-maint to handle the PRs) > > * keeps adding new dependencies > > Granted, but I think given the popularity of Hyprland, this can be allowed? > It has more GitHub stars than Sway (not that GitHub stars are an absolute > measure popularity, but it gives an idea). > I personally do not mind the extra work. > > I'm adding dlan to CC who has been merging my PRs for Hyprland for a long > time now. Dlan ought to have an opinion on whether Hyprland is too much work > and warrants removal. > > > * questionable quality > > Another reason I believe this bug to be politically motivated. A lot of > packages ought to be treecleaned if ::gentoo only allows upstreams with > upstanding code quality. > > > and now this (where upstream seem to have initially rejected it and then > > started tightening permissions; I think there may still be missing checks > > for when the directory already exists and you race hyprland starting though). > > From what I gather, you posted about it on oss-security today, April 28th, > and already upstream has pushed 3 commits that help with that? And it > warrants removal anyway? Not every stance you disagree with is "politically motivated".
> Insecurely creating /tmp/hypr and compiling/running code in it: Nitpick: net-p2p/kubo (f.k.a. ipfs) does basically the same thing - it downloads a "database migration" blob to /tmp/ and attempts to run it from there, which of course fails on a properly configured distro with tmp mounted noexec for security. That package has survived in ::gentoo for years though, so that fact alone wouldn't be enough to expel this one. In context, however, it does come across a bit different. I have to say that Streisanding a CVE that allows attackers to specifically target users of your software - while making a career out of pissing off the community of ten thousand application authors you have to co-habit with on any given local machine - certainly is an inspired choice. Like putting an ad for your project on a dirigible made of flammable materials and hydrogen.
(In reply to Enne Eziarc from comment #9) > > Insecurely creating /tmp/hypr and compiling/running code in it: > > Nitpick: net-p2p/kubo (f.k.a. ipfs) does basically the same thing - it > downloads a "database migration" blob to /tmp/ and attempts to run it from > there, which of course fails on a properly configured distro with tmp > mounted noexec for security. That package has survived in ::gentoo for years > though, so that fact alone wouldn't be enough to expel this one. In context, > however, it does come across a bit different. So you were aware of a security issue "for a long time", and instead of reporting it, you are using it as an argument now?
(In reply to Michał Górny from comment #10) > So you were aware of a security issue "for a long time", and instead of > reporting it, you are using it as an argument now? That package is keyword-constrained to two arches and is quarantined within a separate acct-user, which strongly indicates this was known baggage and accounted for. And no, I do not normally bother raising issues where there's a likelihood that they'll get swiftly dismissed with a maintainer insinuating I'm some flavor of time-wasting idiot. Gentoo seems far worse for that than most projects I've contributed to.
Keywording is really done on an as-needed basis and a separate group for a service isn't so unusual. Let's carry on any discussion as required wrt kubo in bug 930853. Thanks.
(In reply to Eli Schwartz from comment #0) > The hyprland codebase is... really bad code, if one has ever looked at it. > This is unfortunately problematic in a few different ways. Glaring examples > (you can find lots of badness if you read the codebase, though): > > The plugin API is amd64 exclusive, because it involves running llvm-nm on > /proc/self/exe and then using an asm disassembler on the plugin to patch > functions > > > > > Replying with: > > > Does it actually allow an attacker to do anything that can't > > be done with hyprctl plugin load malware-plugin.so? > > > > No. Someone needs access to write to /tmp/hypr, so... they > > have to be running code on your system already, at which > > point they can also rm -rf /. That's why this CVE is a joke. > > > I consider it dangerous in both the short term and the long term to > distribute this WM at all, but if people are going to use it, they should > really be getting it from GURU instead. > > > There are other issues with hyprland as well. The author is an edgelord and > very combative with it. Quoting Sam from the oss-security report: > > > I haven't reported it upstream because of their hostility on other matters. > > > Affects: > dev-libs/hyprland-protocols > dev-libs/hyprlang > gui-libs/hyprcursor > gui-wm/hyprland Having read this entire thread im not too happy with your snarkyness on the matter and clear bias. It is clearly done in poor taste. Regarding the plugin "issue". The user actively needs to load plugins they want using: "hyprctl plugin load myplugin.so". For this to be automated this needs to be added to an "autostart" of a type. Usually this is done in "hyprland.conf". > I consider it dangerous in both the short term and the long term to > distribute this WM at all, but if people are going to use it, they should > really be getting it from GURU instead. Calling this "dangerous" is nonsense. Should the code handling this be more robust? Absolutely and Vaxry is actively reworking this. A user would need to actively load a "bad actor" plugin and would have needed to have downloaded this plugin from an external source. Hyprland does __not__ include any plugins by default and has no "default" plugins. A user actively needs to find them. Just like gnome extensions and kde plasma themes. Difference is, with gnome extensions and plasma themes, these are automatically loaded. Unlike hyprland... Doesn't this mean Hyprland is more secure in this aspect? Should we remove kde-plasma and snap from ::gentoo as well? Recently a KDE theme removed someones home directory, which in my opinion is much MORE dangerous that a theme is allowed to do this in the first place. Additionally with Snap, there have been multiple "bad actor" apps uploaded which have possibly stolen data. KDE has had many issues in the past with bad acting themes as well. Hyprland has produced the best user experience a window manager ever has done. It is the most polished, consistent, even has its own ecosystem, has the most features. All mostly done by a single person (Vaxry) who not only needs to attend university and maintain an irl social life. But also develop this massive project. He is an extremely talented developer. > I haven't reported it upstream because of their hostility on other matters. A common trend ive noticed is that this is only true when someone over-steps their boundaries, talking to him in bad-faith in the first place or being generally rude. I have spoken with Vaxry multiple times and there has only been one time where I've had a negative experience. This was entirely my fault and he even apologized later on. Stop. Defaming. Vaxry. Please have some self responsibility. I do however think Vaxry needs to respond more professionally of course. > The hyprland codebase is... really bad code, if one has ever looked at it. > This is unfortunately problematic in a few different ways. Glaring examples > (you can find lots of badness if you read the codebase, though) This is also a load of nonsense and a massive exaggeration. Hyprland is massively popular and removing it from ::gentoo would be a dis-service to the community. Especially removing it over such petty and weak reasoning.
(In reply to James Kostadin from comment #13) > (In reply to Eli Schwartz from comment #0) > > The hyprland codebase is... really bad code, if one has ever looked at it. > > This is unfortunately problematic in a few different ways. Glaring examples > > (you can find lots of badness if you read the codebase, though): > > > > The plugin API is amd64 exclusive, because it involves running llvm-nm on > > /proc/self/exe and then using an asm disassembler on the plugin to patch > > functions > > > > > > > > > > Replying with: > > > > > Does it actually allow an attacker to do anything that can't > > > be done with hyprctl plugin load malware-plugin.so? > > > > > > > No. Someone needs access to write to /tmp/hypr, so... they > > > have to be running code on your system already, at which > > > point they can also rm -rf /. That's why this CVE is a joke. > > > > > > I consider it dangerous in both the short term and the long term to > > distribute this WM at all, but if people are going to use it, they should > > really be getting it from GURU instead. > > > > > > There are other issues with hyprland as well. The author is an edgelord and > > very combative with it. Quoting Sam from the oss-security report: > > > > > I haven't reported it upstream because of their hostility on other matters. > > > > > > Affects: > > dev-libs/hyprland-protocols > > dev-libs/hyprlang > > gui-libs/hyprcursor > > gui-wm/hyprland > > Having read this entire thread im not too happy with your snarkyness on the > matter and clear bias. It is clearly done in poor taste. > > Regarding the plugin "issue". The user actively needs to load plugins they > want using: > "hyprctl plugin load myplugin.so". For this to be automated this needs to be > added to an "autostart" of a type. Usually this is done in "hyprland.conf". > > > I consider it dangerous in both the short term and the long term to > > distribute this WM at all, but if people are going to use it, they should > > really be getting it from GURU instead. > > Calling this "dangerous" is nonsense. Should the code handling this be more > robust? Absolutely and Vaxry is actively reworking this. A user would need > to actively load a "bad actor" plugin and would have needed to have > downloaded this plugin from an external source. Hyprland does __not__ > include any plugins by default and has no "default" plugins. A user actively > needs to find them. Just like gnome extensions and kde plasma themes. > Difference is, with gnome extensions and plasma themes, these are > automatically loaded. Unlike hyprland... Doesn't this mean Hyprland is more > secure in this aspect? > > Should we remove kde-plasma and snap from ::gentoo as well? Recently a KDE > theme removed someones home directory, which in my opinion is much MORE > dangerous that a theme is allowed to do this in the first place. > Additionally with Snap, there have been multiple "bad actor" apps uploaded > which have possibly stolen data. KDE has had many issues in the past with > bad acting themes as well. > > Hyprland has produced the best user experience a window manager ever has > done. It is the most polished, consistent, even has its own ecosystem, has > the most features. All mostly done by a single person (Vaxry) who not only > needs to attend university and maintain an irl social life. But also develop > this massive project. He is an extremely talented developer. > > > I haven't reported it upstream because of their hostility on other matters. > A common trend ive noticed is that this is only true when someone over-steps > their boundaries, talking to him in bad-faith in the first place or being > generally rude. > > I have spoken with Vaxry multiple times and there has only been one time > where I've had a negative experience. This was entirely my fault and he even > apologized later on. Stop. Defaming. Vaxry. Please have some self > responsibility. > > I do however think Vaxry needs to respond more professionally of course. > > > The hyprland codebase is... really bad code, if one has ever looked at it. > > This is unfortunately problematic in a few different ways. Glaring examples > > (you can find lots of badness if you read the codebase, though) > > This is also a load of nonsense and a massive exaggeration. > > Hyprland is massively popular and removing it from ::gentoo would be a > dis-service to the community. Especially removing it over such petty and > weak reasoning. I forgot to mention. The majority of hyprland users never use plugins anyway.
Please try to only quote the relevant parts in replies to keep them more readable. Thanks. > Stop. Defaming. Vaxry. Please have some self responsibility. I'm not defaming vaxry. I didn't want to interact with him directly but it was beyond "he's only mean when people are mean". I don't think it's in the scope of this discussion otherwise. > A user would need to actively load a "bad actor" plugin and would have needed to have downloaded this plugin from an external source. Hyprland does __not__ include any plugins by default and has no "default" plugins. This is a misunderstanding of the issue. The issue was privilege escalation via unsafe permissions on a directory in /tmp (and not checking if it already exists). The user would not be required to load a malicious plugin.
(In reply to Sam James from comment #15) > This is a misunderstanding of the issue. The issue was privilege escalation > via unsafe permissions on a directory in /tmp (and not checking if it > already exists). The user would not be required to load a malicious plugin. I should add: part of why I was/am displeased is that the response was not particularly professional, including misrepresenting the issue (perhaps accidentally - but then he shouldn't have stated it so confidently). The fact that this misunderstanding has spread is part of that. > Should we remove kde-plasma and snap from ::gentoo as well? Recently a KDE > theme removed someones home directory, which in my opinion is much MORE > dangerous that a theme is allowed to do this in the first place. The relevant code in KDE Plasma was not particularly scary, nor was it responded to in an unprofessional manner once reported.
> Should the code handling this be more robust? Absolutely and Vaxry is actively reworking this. Initially dismissing the issue (and then doubling down on it a few times), then making commits with no reference to the context in its description makes "actively reworking it" non-obvious. But I hope he is.
(In reply to Sam James from comment #15) > Please try to only quote the relevant parts in replies to keep them more > readable. Thanks. Sorry, I will do this in the future. Thanks for letting me know :) > > This is a misunderstanding of the issue. The issue was privilege escalation > via unsafe permissions on a directory in /tmp (and not checking if it > already exists). The user would not be required to load a malicious plugin. A user still would need to manually load a malicious plugin. This is not done automatically by default. The hyprland wiki states that users should read through the source code of plugins to ensure they are not malicious. If a malicious program is swapping these originally safe plugins for malicious ones. You have much bigger problems to worry about. > nor was it responded to in an unprofessional manner once reported. This worries me... It sounds like this is fueled by certain people not liking Vaxry personally. This sounds likes creating double standards due to the simple fact that certain people do not like the software or developer(personally). KDE and Snap had these issues nonetheless. However much you like the developer or software does not take away from the issues they had. As I have already mentioned. Vaxry is completely overhauling parts of Hyprland making it more robust as we speak.
(In reply to James Kostadin from comment #18) > (In reply to Sam James from comment #15) > [...] > A user still would need to manually load a malicious plugin. This is not > done automatically by default. The hyprland wiki states that users should > read through the source code of plugins to ensure they are not malicious. > > If a malicious program is swapping these originally safe plugins for > malicious ones. You have much bigger problems to worry about. > No, the user would need to load _any_ plugin, and then a user with less permissions can camp and wait until that happens (possibly creating the directory first, before hyprland starts up), and inject their own plugin. This is a somewhat standard form of privilege escalation when it comes to unsafe handling of temporary files and directories. > > nor was it responded to in an unprofessional manner once reported. > > This worries me... It sounds like this is fueled by certain people not > liking Vaxry personally. > ? I'm just saying that the response by the KDE Plasma people in response to the theme issue wasn't to be dismissive, respond with memes, and say the whole thing was Not A Problem. It's got nothing to do with liking... > This sounds likes creating double standards due to the simple fact that > certain people do not like the software or developer(personally). KDE and > Snap had these issues nonetheless. However much you like the developer or > software does not take away from the issues they had. No, please, let's not conflate the two. I am *not* talking about installing malicious plugins, themes, or addons. > > As I have already mentioned. Vaxry is completely overhauling parts of > Hyprland making it more robust as we speak. I'm glad. It would be nice if they could've clarified their remarks and given context in the commit messages, but it is what it is.
(In reply to Sam James from comment #19) > No, the user would need to load _any_ plugin, and then a user with less > permissions can camp and wait until that happens (possibly creating the > directory first, before hyprland starts up), and inject their own plugin. > > This is a somewhat standard form of privilege escalation when it comes to > unsafe handling of temporary files and directories. This is simply untrue. See the commits related around the matter(335015f, a5a6480, 28c8561, f7815da) on Hyprland GitHub (I think I got them all but I may have missed some). Again, if you have a malicious program able to inject into an application. You have **much** bigger problems to worry about. > > I'm just saying that the response by the KDE Plasma people in response to > the theme issue wasn't to be dismissive, respond with memes, and say the > whole thing was Not A Problem. Vaxry never stated it wasnt a problem. He stated its overblown.
(In reply to James Kostadin from comment #20) > (In reply to Sam James from comment #19) > > > No, the user would need to load _any_ plugin, and then a user with less > > permissions can camp and wait until that happens (possibly creating the > > directory first, before hyprland starts up), and inject their own plugin. > > > > This is a somewhat standard form of privilege escalation when it comes to > > unsafe handling of temporary files and directories. > > This is simply untrue. See the commits related around the matter(335015f, > a5a6480, 28c8561, f7815da) on Hyprland GitHub (I think I got them all but I > may have missed some). > I don't know what you're saying is untrue. Those commits fix the problem I describe. There's some additional bits solar pointed out on Twitter and I'm not sure if they got handled yet. > Again, if you have a malicious program able to inject into an application. > You have **much** bigger problems to worry about. > That's what a privilege escalation vulnerability is. You get to traverse a boundary you couldn't otherwise. > > > > I'm just saying that the response by the KDE Plasma people in response to > > the theme issue wasn't to be dismissive, respond with memes, and say the > > whole thing was Not A Problem. > > Vaxry never stated it wasnt a problem. He stated its overblown. OK, people can interpret his response as they wish.
(In reply to Sam James from comment #21) > > > Again, if you have a malicious program able to inject into an application. > > You have **much** bigger problems to worry about. > > > > That's what a privilege escalation vulnerability is. You get to traverse a > boundary you couldn't otherwise. > i.e. you get to go from access on the system -> assuming the privileges of another user, where that user may be more privileged. It's, of course, always chained with something else (to get access to begin with).
(In reply to Sam James from comment #3) > (Not to get onto how fragile this code is even if the TOCTOU stuff is > sorted; it calls 'cc' and 'objdump' directly, it only works on amd64, ...) This is also untrue. See commit: (0c0907cfafa46dc0d26aed30361e2c00c35dcf6c) > I don't know what you're saying is untrue. Those commits fix the problem I > describe. There's some additional bits solar pointed out on Twitter and I'm not sure if they got handled yet. I said it was un-true as it has since been fixed and there is no point in mentioning that it exists when in reality, it doesnt and it was fixed :) Its quite misleading the way you put it so I wanted to correct you so that people do not develop misunderstandings around it. > OK, people can interpret his response as they wish. I dont think its nice to bend peoples words... Keep to what he said correct in the original source and people can interpret that how they wish! :)
(In reply to James Kostadin from comment #23) > (In reply to Sam James from comment #3) > > (Not to get onto how fragile this code is even if the TOCTOU stuff is > > sorted; it calls 'cc' and 'objdump' directly, it only works on amd64, ...) > > This is also untrue. > See commit: (0c0907cfafa46dc0d26aed30361e2c00c35dcf6c) > See below - 'untrue' is really not helpful here. Please say 'since been fixed'. It was true at the time of the comment there. > > I don't know what you're saying is untrue. Those commits fix the problem I > > describe. There's some additional bits solar pointed out on Twitter and I'm not sure if they got handled yet. > > I said it was un-true as it has since been fixed and there is no point in > mentioning that it exists when in reality, it doesnt and it was fixed :) > Its quite misleading the way you put it so I wanted to correct you so that > people do not develop misunderstandings around it. > I think it's obvious I was describing the vulnerability I originally reported, given you were talking in the present tense as well... It *absolutely* mentions that it exists, because that's what the whole vulnerability reported was!
s/mentions/matters/
(In reply to Sam James from comment #24) > See below - 'untrue' is really not helpful here. Please say 'since been > fixed'. It was true at the time of the comment there. Sorry about that, I didn't check the timestamp :) > > I think it's obvious I was describing the vulnerability I originally > reported, given you were talking in the present tense as well... > > It *absolutely* mentions that it exists, because that's what the whole > vulnerability reported was! Although the bug summary has since changed a little, this is still a joint discussion on whether Hyprland should be in ::gentoo or not. If the issue was fixed(which it has), there is no point mentioning it as a reason for it to be removed from ::gentoo. It creates needless possible misunderstanding. :)
I was correcting the description made of the vulnerability. Anyway, I agree it's confusing wrt bug summary. Let's keep this one for discussion of its future and I'll file a new one for the general security handling as usual for the vulnerability.
Hello! Long time no been here! I'll give my opinion on why this "bug report" is a VERY bad idea. I hope that my contribution helps to resolve this situation in a good way. (In reply to Eli Schwartz from comment #0) > The hyprland codebase is... really bad code, if one has ever looked at it. > This is unfortunately problematic in a few different ways. Glaring examples > (you can find lots of badness if you read the codebase, though): > If the code seems of "bad quality" to you, the best thing you can do is support the project to improve the quality of said code, and you can easily do that by making a PR that improves the quality of the hyprland project. We are here to create code, not just to complain about it without contributing anything. Going and creating a bug-report so that they close the door to the project in one distro (and the possibility of a cascading effect in other distros) certainly does not seem like the best thing to me. > The plugin API is amd64 exclusive, because it involves running llvm-nm on > /proc/self/exe and then using an asm disassembler on the plugin to patch > functions > And what's the problem with it being exclusive to AMD64? It is free software, if someone wants to support another arch, they can do so, Vaxry will surely receive the PR well, as long as it does not break the rest of the project. Also, I wonder: How many programs are there exclusive for AMD64 in Gentoo? I'm sure there are a few packages that meet that characteristic. For example dev-erlang/xmpp is focused mainly on amd64 and the rest of arch are masked on Gentoo. Does it mean we also have to remove dev-erlang/xmpp from Gentoo because they are focused on AMD64 only? No, that's absurd. AMD64 is the architecture with the greatest support currently. So saying that we should remove gui-wm/hyprland from Gentoo because they are only "for amd64" is very far-fetched and again: absurd. > > > Insecurely creating /tmp/hypr and compiling/running code in it: > https://www.openwall.com/lists/oss-security/2024/04/28/3 > https://github.com/hyprwm/Hyprland/issues/5787#issuecomment-2081572992 > A security issue. Great, good job helping to improve gui-wm/hyprland by detecting a security flaw and helping to fix it. But why do you use it to talk about "poor quality" of software? The problem has already been solved, and it has been solved in one day. One day and the security problem no longer exists. Does that sound like "poor quality" to you? Does it seem like a careless and unaware action by the creator? It seems the opposite to me. That they respond to you and solve a security problem in one day, a minimal security problem by the way, because it is local and depends entirely on the user's action, tells me that they take great care of the project and want to improve it. Better != Bad > Replying with: > > > Does it actually allow an attacker to do anything that can't > > be done with hyprctl plugin load malware-plugin.so? > > > > No. Someone needs access to write to /tmp/hypr, so... they > > have to be running code on your system already, at which > > point they can also rm -rf /. That's why this CVE is a joke. > And that's true, if you're able to do that attack, what's stopping you from doing an rm -rf /? Nothing. You can do it, you can watch the world burn if you have that kind of privilege. What we are getting at is that this requires a level of privileges and actions that YOU as users have to give/do. If you as a user do not take the slightest care of what you run on your PC, there is nothing a developer can do. > > I consider it dangerous in both the short term and the long term to > distribute this WM at all, but if people are going to use it, they should > really be getting it from GURU instead. > If you consider that to be dangerous, don't look at what you have with Xorg and its ability to read all keystrokes you make on the system. The most well-known vulnerability/feature in the FOSS world. Do we take out Xorg from Gentoo for that? No. Not to mention this old RCE from systemd: https://alvinsmith.gitbook.io/progressive-oscp/untitled/vulnversity-privilege-escalation Did we remove systemd from Gentoo because of this? No, we just fix systemd and go on our way. By the way, the systemd bug took several days to fix. > > There are other issues with hyprland as well. The author is an edgelord and > very combative with it. Quoting Sam from the oss-security report: > AND? Now no one is free to express themselves freely? The problem is a joke, and it is already solved, that is the truth. Also, what's the problem with Vaxry's expression? Now it turns out that if your feelings are hurt, that gives you the power to remove a project from wherever it is, even when you don't actually contribute anything, not a single line of code. And I'm talking about yours, because even m007x (the creator of issue in GitHub) seems to be happy with the solution. Let's not be innocent, Vaxry has been under attack for some time now after what happened with Freedesktop, and this seems to be just one more head of that Medusa created. You can agree with Vaxry or not, that is your freedom, but that does not give you the power to attack his work and try to tear it down, especially when that work is applauded and well received by thousands more than you.
(In reply to Sam James from comment #1) > My impression is that it's not a good fit for ::gentoo either way, given: > * the high rate of releases (-> hard for a proxied-maint to keep up, and for > proxy-maint to handle the PRs) This IS a real problem for inclusion in Gentoo. Releasing a 0.39 version on April 14, and then 0.39.1 on April 16, is certainly problematic. Perhaps asking Varxy to stabilize his versions would be the most prudent thing to do. > * keeps adding new dependencies I don't see the problem, unless the dependencies are things outside of the package repo supported by Gentoo. If it's the latter, then you already have a strong argument to remove it. > * questionable quality > I see this as questionable, let's say that at the code level, there are questionable things even in the kernel. > and now this (where upstream seem to have initially rejected it and then > started tightening permissions; I think there may still be missing checks > for when the directory already exists and you race hyprland starting though). > > I was the person who merged the PR to bring hyprland to ::gentoo and I > regret it. In this case, I tell you, your more strongest point, and the one where I support the decision to remove hyprland from Gentoo, is the second. If hyprland with each new version it releases comes dragging dependencies outside of the packages already supported by Gentoo, you already have an ideal point to remove it from Gentoo. But based on Eli's initial report, you have nothing. In any case, perhaps it would be good to knock on Varxy's door to create a roadmap of versions and have things more thought out. Releasing versions every two days doesn't help at all. It neither helps him create well-tested features, nor helps us package securely. And between one and the other, I prefer the second.
(In reply to Julien from comment #7) > (In reply to Eli Schwartz from comment #6) > > Care to elaborate which politics you're referring to? :) > > Drew Devault's blog is a good place to start. Ok. He appears to have a blog post from September 17, 2023 about how "Hyprland is a toxic community". I've been concerned about hyprland's code quality and robustness (and the difficulty of in practice efforts at collaboration with vaxry, since he seems to think you're stupid if you disagree with him, and uses rather crude and childish language to express that) since mid 2022 and probably a bit earlier, and don't have anything particular to say about some relative newcomer like Drew Devault. > > I think there's a stark difference between "not upstanding code quality" and: > > > > - being authored by someone that disparages people for reporting security > > issues > > - proudly blogs about how the security issue is actually a genius move > > - thinks people who say that security matters when protecting yourself > > against other uids running on the same machine, must be telling a ridiculous > > joke "because they can just rm -rf /" > > I think a lot of people have made similar points about systemd No, they have not. I'm not sure how else to answer this absolute non sequitur because it is just so wrong that I don't even know where to *start*. I have spoken to many people who don't like systemd and heard dozens of reasons for *why* they don't like systemd. I don't think I've ever heard anyone suggest what you're suggesting. > > and also: > > > > - only works on amd64, whereas gentoo is quite proudly a supporter of many, > > many other architectures > > See: https://wiki.gentoo.org/wiki/KEYWORDS I'm... very aware that gentoo has the technical mechanisms available to mark a package as unable to support gentoo's many arches. I wonder if you're aware of this: https://devmanual.gentoo.org/general-concepts/tree/index.html#what-belongs-in-the-tree Portable If software is unportable, it's generally because it's badly written. Remember that although x86 has a market majority now, it probably won't in the not too distant future once x86-64 catches on. Slightly out of date, actually. These days swap for amd64 and arm64. Yes, "packages that only work on a specific architecture" is quite literally listed in the devmanual as an argument against inclusion in ::gentoo. Does that mean Gentoo has a strict policy to ban packages that only work on one arch? No. But it does mean that it's an automatic bad mark against the package, which has to be considered when overall considering whether it is suitable for inclusion. ... hyprland is also keyworded for riscv but this looks bogus to me. Does the plugin system actually work there? > I'm not sure ::gentoo having Hyprland means it's condoning the project? > As for the potential risk of security vulnerabilities, as I said above, if > hyprpm remains a problem, we can hide it behind a masked USE flag or remove > it entirely, depending on what the Security team deems best. > As for the overall security profile of the project, that seems very > subjective and to me. Gentoo providing the package in its official repositories is *not* telling people it is software that is believed to be reasonably safe to install? Intriguing.
Please recall, that there is no divine right to be in ::gentoo -- it's not a punishment to be in GURU, and contrarily it's often better to be in GURU since it is easier to fix fast-moving software if it is in GURU. "A bunch of people want to use it" is not in and of itself a reason why a package *must* be included in ::gentoo. It is basically not even a hindrance to have to use GURU, you just add one more repository. If Gentoo were a binary distro then inclusion in the primary/official repository would be important in order to ensure that binary packages are available. But since Gentoo is a source based distro (and the official binhosts only provide select packages) the main purpose of being in ::gentoo is... to ensure that the package is covered by the QA and GLSA teams, arch stabilization, and GENTOO_MIRRORS.
(In reply to Eli Schwartz from comment #30) > > Ok. He appears to have a blog post from September 17, 2023 about how > "Hyprland is a toxic community". > > I've been concerned about hyprland's code quality and robustness (and the > difficulty of in practice efforts at collaboration with vaxry, since he > seems to think you're stupid if you disagree with him, and uses rather crude > and childish language to express that) since mid 2022 and probably a bit > earlier, and don't have anything particular to say about some relative > newcomer like Drew Devault. > Not having a code of conduct does not make you a toxic community. If you are a person who is incapable of treating others in a humane and dignified manner, there is no code of conduct that stops you from doing what you want. OpenBSD does not have a code of conduct, and when cases like that happen, it simply makes the point, and we downplay the troll or abuser. > > > No, they have not. I'm not sure how else to answer this absolute non > sequitur because it is just so wrong that I don't even know where to *start*. This is your assessment. The reality is what it is: entire distros that were created for the simple fact of not wanting to touch systemd with a stick, because they consider the project garbage or something unnecessary. > > I have spoken to many people who don't like systemd and heard dozens of > reasons for *why* they don't like systemd. I don't think I've ever heard > anyone suggest what you're suggesting. > The XZ fiasco is an example that systemd has huge flaws, so huge that they wanted to use a Trojan in XZ (liblzma) to be able to inject code into systemd and remotely. Something tells me that with what happened, they will now have more resistance and rejection of the project. Again, a security flaw of a magnitude greater than what we see in Hyprland (and which has been solved in both cases). > > I'm... very aware that gentoo has the technical mechanisms available to mark > a package as unable to support gentoo's many arches. What a tone and form of expression. And we are talking about toxicity precisely. > > I wonder if you're aware of this: > > https://devmanual.gentoo.org/general-concepts/tree/index.html#what-belongs- > in-the-tree > > Portable > If software is unportable, it's generally because it's badly written. > Remember that although x86 has a market majority now, it probably won't in > the not too distant future once x86-64 catches on. > > Slightly out of date, actually. These days swap for amd64 and arm64. Those guidelines that you have indicated are not something that must be followed 100%, it is only the ideal, and the ideal is not realistic. The reality is that Hyprland is made in C++ and, therefore, can be ported. Is Hyprland able to work on all arches? I really doubt it, especially for such a small and new project. Still, Hyprland can be compile for AMD64 and ARM64 as far as I can see, since other people have been able to compile it (showing portability). I leave some evidence of this. Build on ARM64: https://github.com/hyprwm/Hyprland/issues/1566 Archlinux ARM64: https://archlinuxarm.org/packages/aarch64/hyprland Archlinux ARMv7h: https://archlinuxarm.org/packages/armv7h/hyprland > > Yes, "packages that only work on a specific architecture" is quite literally > listed in the devmanual as an argument against inclusion in ::gentoo. > This is a very superficial and false reading of those guidelines. Ideally, the package should support several architectures, but it is not an element to reject the inclusion of a package. I have already mentioned it before, there are several packages in Gentoo that have very limited availability in other arches, generally they focus on the majority ones (AMD64 and X86, at most ARM64). For example, these packages: https://packages.gentoo.org/packages/games-board/atakks https://packages.gentoo.org/packages/app-emulation/spim https://packages.gentoo.org/packages/dev-java/jmc (Only AMD64) > Does that mean Gentoo has a strict policy to ban packages that only work on > one arch? No. But it does mean that it's an automatic bad mark against the > package, which has to be considered when overall considering whether it is > suitable for inclusion. > This is true, but you forget something: there are 8 different points, failing one does not mean that we should take it out. In fact, I see more relevant points than portability, such as "Reasonably useful", "Active" and "Reasonably stable". > > hyprland is also keyworded for riscv but this looks bogus to me. Does the > plugin system actually work there? > If the plugin function is not for RISCV or ARM64 (again, Hyprland can be compiled for that arch) it does not remove the fact that it can be marked as Testing, in fact, that is what the Testing tag is for. > > Gentoo providing the package in its official repositories is *not* telling > people it is software that is believed to be reasonably safe to install? > Intriguing. XZ was marked "Safe" and look what happened around him, quite a disaster. It's software, there are bugs, it's common, normal. If there is a bug, you detect it, fix it and continue. Furthermore, there is nothing 100% in the world of free software, and the software licenses already tell you this from the beginning, which is why we always see something like this in them: (GPL v3) 15. Disclaimer of Warranty. THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE . THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. Limitation of Liability. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Intriguing, right?
I don't think the discussion is really going to end up in a useful place here. Having the world and their dog comment about how hyprland is okay for them isn't useful, and nor is saying hyprland is evil garbage. There's no inherent right for software to be in Gentoo, we have alternative repositories, and not being in Gentoo isn't a punishment. The maintainer in Gentoo is happy for it to remain and the issues got fixed, so I don't think there's anything for us to do here. But of course, if issues come up in future, then previous context has to be taken into account too. There are many packages where they're better served by *not* being in Gentoo, but instead in an overlay, because they're a lot of work to keep up with, or too niche, and users get a better deal by getting updates quickly from an overlay. I do suggest reflection on the part of all of the people talking about toxicity given their tone in this bug. It's okay for the person you like to have free speech, but discussing whether software is appropriate for a distribution apparently isn't. Let's leave it here - there's not sufficient justification to remove it, even if we wouldn't necessarily add it anew at this point. Thanks.
