Haelwenn /элвэн/ 

https://bugs.gentoo.org/971885 "app-editors/vim: Multiple High risk vulnerabilities in the past few days"

Pfahaha, makes me wonder if it's related to the vibe-code stuff it got in there lately.

971885 – app-editors/vim: Multiple High risk vulnerabilities in the past few days

Apr 2 at 10:36amWeb
Show threadHaelwenn /элвэн/ Apr 2
Seems to be modeline and that fucking zip plugin, I'm so glad vis is purely a text editor and I think if I ever enabled/added modeline support in it I'd make sure it's bulletproof as hell.

Same reason why I do not have less(1) on my machines.
Show threadsarah tonin Apr 2
@lanodan probably honestly
Show thread𝕹𝖞𝖝 妛彁  :labrys-45-sickle:  Apr 2
@lanodan same thing has been happening with chrome lately lmao
Show threadHaelwenn /элвэн/ Apr 2
@nyx Well chrome in the past few years always had a steady stream of vulnerabilities being discovered.
Show threadnicole mikołajczyk 🔜 sesja linuksowa ➡️ piwo ➡️ gpnApr 2
@lanodan @nyx doesn’t make much sense to compare chrome with a text editor
Show threadnicole mikołajczyk 🔜 sesja linuksowa ➡️ piwo ➡️ gpnApr 2
@lanodan @nyx also we got both more slopcoding and good code scanning tools at the same time
Show threadHaelwenn /элвэн/ Apr 2
@mkljczk @nyx Yeah that said I don't think you should have to play tower defense when it's a text editor.
A web browser meanwhile well… W3C loves designing the opposite of secure by design.
Show threadsilhouette   Apr 2
@lanodan @nyx that's because a browser engine is complex af

and i have seen my fair share of vim vulnerabilities in recent years. doesn't mean it's bad, just that bugs are found and fixed
Show threadOzzelot Apr 2
@lanodan
security-holes-as-a-service
Show threadsamApr 2

@lanodan I don't use vim so not for me to do really, but I'm just waiting for someone to package one of these "boring forks".

From what I saw, at least some of these vulnerabilities (not sure if it's the ones in this bug but wrt the ones going around recently), they got introduced pretty recently and couldn't be repro'd on say Debian stable, so any fork would likely be okay if it's from a little while ago..

Show threadHaelwenn /элвэн/ Apr 2
@thesamesam Well I don't use it either (I use app-editors/vis) so it's kind of me being on the peanut gallery, otherwise pretty sure I probably would have packaged one of those boring forks already.
Show threadsamApr 2
@lanodan Had a feeling. I feel like editors are one of those where you need someone who actually daily drives it to be sensitive to the various things that can go wrong, tweaked upstream defaults, blah blah
Show threadmid_kidApr 2
@thesamesam @lanodan I am a heavy user of vim, but have never poked much at its internals (or bothered learning vimscript) so I've yet to notice any of this ensloppification.
Looking around, it seems that too much of the software I rely on has started using AI overnight, making it unavoidable. Drew even has a blog post on replacing rsync with tar due to this, something I really don't see being anywhere near equivalent.
As someone who consistently fights losing fights, this doesn't seem worth it.
Show threadmid_kidApr 2
@thesamesam @lanodan Also the forks essentially propose feature freezes. I don't see this being a viable long-term solution, as many of the features added since I started using it with vim7 have significantly uplifted the experience... If you were to keep new features somewhat in-sync, you'd basically be transcribing code instead of doing any development.
It's sad how things go, but I don't think there's a technical solution to this social problem...
Show threadHaelwenn /элвэн/ Apr 2
@mid_kid @thesamesam Yeah, for rsync I'm so tied to the protocol for uses cases like fetching mirrors that I'll probably give openrsync a shot for replacing it unless a fork appears in the meantime.
Show threadHaelwenn /элвэн/ Apr 2
@mid_kid @thesamesam Plus well part of the problem is how the forks/re-implementations you can find don't always have an anti-LLM policy.
Add that to how there's quite few pieces of software we probably consider essential (like @system set stuff in Gentoo or BSD base, I think rsync goes in there) that either have got already slopified or nearby software has.
Show threadwitch_t *naviApr 2
@mid_kid @thesamesam @lanodan

honestly there's a few uses of rsync that i didn't realize i could use tar until the post

but that's like, only half of the uses rsync has to me... not all
Show threadsamApr 2

@mid_kid @lanodan rsync hasn't added a few features we've sent PRs for, but so what? I also don't think 2 claude commits really means full blown disregard for any quality whatsoever.

Supposing one does consider that tainted or it gets worse, we either use older rsync or openrsync perhaps, it's not like anyone is going to notice some missing feature in that.

Show threadHaelwenn /элвэн/ Apr 2
@thesamesam @mid_kid True but I think it's worth it to plan in advance, specially for ones where migrating could take time. (Like sure as hell don't want to just cold-turkey swap to openrsync as an /usr/bin/rsync provider without checking for some time)
Show threadsamApr 2

@lanodan @mid_kid Yes. I would've investigated this sooner (why not, long before LLMs) but I think openrsync had some problems that meant I lost interest in it.

Didn't revisit it since but I think they at least did a rebase from OpenBSD since then.

Show threadsamApr 2

@mid_kid @lanodan I do think Vim has always been a bit of a rough situation at least since the huge numbers of CVEs started, because you'd end up being nudged to upgrade quickly and there'd be various regressions.

This just means there's more regressions. It's not uncommon to move more slowly with such upstreams or to stick to an older version.

For this reason, we have (for as long as I've paid any attention to packaging) not rushed to update Vim, often being behind by quite a bit, because of how much broke even pre-LLMs.

Show threadmid_kidApr 2
@thesamesam @lanodan Oh, I wasn't aware about vim patches being so wonky. I guess you guys've been doing a good job shielding me from it :P
Show threadsamApr 2
@mid_kid @lanodan You're entitled to your nihilism but for me, it's resisting it, or not doing this at all anymore.
Show threadmid_kidApr 2

@thesamesam @lanodan FWIW, it does make me happy to see people fighting the fights I'm too tired to engage :)

Is there any big plans for gentoo regarding this? Will the project switch to non-AI alternatives where possible?

Show threadsamApr 2

@mid_kid @lanodan See the discussion at https://public-inbox.gentoo.org/gentoo-dev/[email protected]/

I don't think we have a clear plan or rule yet, though e.g. a bunch of Perl modules have newer versions masked because they're now nearly "autonomously developed", some Python libraries are in package.deprecated or last-rited, ...

[gentoo-dev] Dealing with (potential) slop packages - Michał Górny

Show threadHaelwenn /элвэн/ Apr 2
@thesamesam @mid_kid Ah yeah, that thread, I gave up on reading it all after like ~6 emails due to the length, I'm fine with leaving it to ones involved in it.
Show threadsamApr 2

@lanodan @mid_kid I did try to focus on practical technical measures and I think I killed the conversation, but nobody has complained (and several have supported) what we've done with Perl.

One of those things where sometimes having the discussion is useful in that there's no clear wrong (or right) answer, so you have some licence to go ahead.

Show threadxrvsApr 2
@lanodan trust me bros i’ve been doing this for decades bros i can’t be wrong
Show threadxrvsApr 2
@lanodan (this was literally an argument by dev of wordpress’s activitypub plugin)
Show threadHaelwenn /элвэн/ Apr 2
@xarvos Well… wordpress track record speaks for itself, sure it's popular but it has an *awful* reputation in terms of security.
Show threadxrvsApr 2

@lanodan yea…

but when that kind of thing happens to vim or linux or hurd it makes me lose hope 

Show threadHaelwenn /элвэн/ Apr 2
@xarvos Yeah, makes me feel like if I'd want to be purely slop-free I'd end up on something like Plan9 and a roughly equivalent Unix-like.
Which of course I can't do for most of my machines, specially desktop/laptop.