something that's been bothering me about the phpocalypse - which, talking with @rain I was able to put a pin in, after they pointed out what they would do in a similar situation - is that this doesn't feel like a security patch at all.
-
and yes, I think they've been suborned by claude because the solution is "way more code" instead of "simplify oom handling in an easy to understand way" and claude has a history of suggesting "create a vast new thing" before any other solution, as claude is a paperclip maximizer for software and it's gotten into everything.
@munin idk about claude, but we also believe "abort on OOM" is the correct behavior
this is *already* a cgi-bin-inspired execution model, you are *perfectly suited* to just abort!
-
something that's been bothering me about the phpocalypse - which, talking with @rain I was able to put a pin in, after they pointed out what they would do in a similar situation - is that this doesn't feel like a security patch at all.
this feels like a major feature upgrade.
which is weird in the circumstances.
the kind of patch that you would expect to see during a major all hands on deck kind of emergency would be the smallest, least-touch change possible - Rain suggested "abort on OOM" which is a nice sensible solution; sure it hits availability a little but in a way that synergizes nicely with defender goals (denying materiel to an attacker; reducing blast radius to "an instance becomes momentarily unavailable until the service gets restarted")
instead, this has a massive rework of how OOM situations are handled, with a completely new error handling mechanism added and -backported- to other prior versions?
that doesn't smell right at all.
and now a massive patch drops that MUST BE APPLIED NOW - so, intense pressure to comply without careful evaluation?
call me paranoid, sure. but this doesn't fit what I expect to see, and I don't like it, and I am feeling very suspicious that the people making these decisions are having their decisionmaking compromised in some fashion.
@munin i am pretty sure it was vibe coded. so.
-
@munin idk about claude, but we also believe "abort on OOM" is the correct behavior
this is *already* a cgi-bin-inspired execution model, you are *perfectly suited* to just abort!
right. it -doesn't make sense- to not adopt that, especially in a high pressure time constrained situation.
something -isn't right-
-
@munin i am pretty sure it was vibe coded. so.
well yes that's obvious; you don't -get- that much code that fast without the connivance of that horseshit.
-
something that's been bothering me about the phpocalypse - which, talking with @rain I was able to put a pin in, after they pointed out what they would do in a similar situation - is that this doesn't feel like a security patch at all.
this feels like a major feature upgrade.
which is weird in the circumstances.
the kind of patch that you would expect to see during a major all hands on deck kind of emergency would be the smallest, least-touch change possible - Rain suggested "abort on OOM" which is a nice sensible solution; sure it hits availability a little but in a way that synergizes nicely with defender goals (denying materiel to an attacker; reducing blast radius to "an instance becomes momentarily unavailable until the service gets restarted")
instead, this has a massive rework of how OOM situations are handled, with a completely new error handling mechanism added and -backported- to other prior versions?
that doesn't smell right at all.
and now a massive patch drops that MUST BE APPLIED NOW - so, intense pressure to comply without careful evaluation?
call me paranoid, sure. but this doesn't fit what I expect to see, and I don't like it, and I am feeling very suspicious that the people making these decisions are having their decisionmaking compromised in some fashion.
-
@munin esp a half assed solution that only touches _most_ of what needs to be touched
-
-
@munin i am pretty sure it was vibe coded. so.
-
something that's been bothering me about the phpocalypse - which, talking with @rain I was able to put a pin in, after they pointed out what they would do in a similar situation - is that this doesn't feel like a security patch at all.
this feels like a major feature upgrade.
which is weird in the circumstances.
the kind of patch that you would expect to see during a major all hands on deck kind of emergency would be the smallest, least-touch change possible - Rain suggested "abort on OOM" which is a nice sensible solution; sure it hits availability a little but in a way that synergizes nicely with defender goals (denying materiel to an attacker; reducing blast radius to "an instance becomes momentarily unavailable until the service gets restarted")
instead, this has a massive rework of how OOM situations are handled, with a completely new error handling mechanism added and -backported- to other prior versions?
that doesn't smell right at all.
and now a massive patch drops that MUST BE APPLIED NOW - so, intense pressure to comply without careful evaluation?
call me paranoid, sure. but this doesn't fit what I expect to see, and I don't like it, and I am feeling very suspicious that the people making these decisions are having their decisionmaking compromised in some fashion.
-
Write up said it was found by researchers using AI.
The solution was also AI created.
-
well yes that's obvious; you don't -get- that much code that fast without the connivance of that horseshit.
-
@munin idk about claude, but we also believe "abort on OOM" is the correct behavior
this is *already* a cgi-bin-inspired execution model, you are *perfectly suited* to just abort!
-
something that's been bothering me about the phpocalypse - which, talking with @rain I was able to put a pin in, after they pointed out what they would do in a similar situation - is that this doesn't feel like a security patch at all.
this feels like a major feature upgrade.
which is weird in the circumstances.
the kind of patch that you would expect to see during a major all hands on deck kind of emergency would be the smallest, least-touch change possible - Rain suggested "abort on OOM" which is a nice sensible solution; sure it hits availability a little but in a way that synergizes nicely with defender goals (denying materiel to an attacker; reducing blast radius to "an instance becomes momentarily unavailable until the service gets restarted")
instead, this has a massive rework of how OOM situations are handled, with a completely new error handling mechanism added and -backported- to other prior versions?
that doesn't smell right at all.
and now a massive patch drops that MUST BE APPLIED NOW - so, intense pressure to comply without careful evaluation?
call me paranoid, sure. but this doesn't fit what I expect to see, and I don't like it, and I am feeling very suspicious that the people making these decisions are having their decisionmaking compromised in some fashion.
-
something that's been bothering me about the phpocalypse - which, talking with @rain I was able to put a pin in, after they pointed out what they would do in a similar situation - is that this doesn't feel like a security patch at all.
this feels like a major feature upgrade.
which is weird in the circumstances.
the kind of patch that you would expect to see during a major all hands on deck kind of emergency would be the smallest, least-touch change possible - Rain suggested "abort on OOM" which is a nice sensible solution; sure it hits availability a little but in a way that synergizes nicely with defender goals (denying materiel to an attacker; reducing blast radius to "an instance becomes momentarily unavailable until the service gets restarted")
instead, this has a massive rework of how OOM situations are handled, with a completely new error handling mechanism added and -backported- to other prior versions?
that doesn't smell right at all.
and now a massive patch drops that MUST BE APPLIED NOW - so, intense pressure to comply without careful evaluation?
call me paranoid, sure. but this doesn't fit what I expect to see, and I don't like it, and I am feeling very suspicious that the people making these decisions are having their decisionmaking compromised in some fashion.
-
something that's been bothering me about the phpocalypse - which, talking with @rain I was able to put a pin in, after they pointed out what they would do in a similar situation - is that this doesn't feel like a security patch at all.
this feels like a major feature upgrade.
which is weird in the circumstances.
the kind of patch that you would expect to see during a major all hands on deck kind of emergency would be the smallest, least-touch change possible - Rain suggested "abort on OOM" which is a nice sensible solution; sure it hits availability a little but in a way that synergizes nicely with defender goals (denying materiel to an attacker; reducing blast radius to "an instance becomes momentarily unavailable until the service gets restarted")
instead, this has a massive rework of how OOM situations are handled, with a completely new error handling mechanism added and -backported- to other prior versions?
that doesn't smell right at all.
and now a massive patch drops that MUST BE APPLIED NOW - so, intense pressure to comply without careful evaluation?
call me paranoid, sure. but this doesn't fit what I expect to see, and I don't like it, and I am feeling very suspicious that the people making these decisions are having their decisionmaking compromised in some fashion.
@munin@infosec.exchange @rain@hachyderm.io it sure would be convenient if openai could be the saviour of everything once more in 6 months when it’s revealed the silly humans couldn’t patch properly, or something
i mean this entire thing was already used to prop up oai as it is -
something that's been bothering me about the phpocalypse - which, talking with @rain I was able to put a pin in, after they pointed out what they would do in a similar situation - is that this doesn't feel like a security patch at all.
this feels like a major feature upgrade.
which is weird in the circumstances.
the kind of patch that you would expect to see during a major all hands on deck kind of emergency would be the smallest, least-touch change possible - Rain suggested "abort on OOM" which is a nice sensible solution; sure it hits availability a little but in a way that synergizes nicely with defender goals (denying materiel to an attacker; reducing blast radius to "an instance becomes momentarily unavailable until the service gets restarted")
instead, this has a massive rework of how OOM situations are handled, with a completely new error handling mechanism added and -backported- to other prior versions?
that doesn't smell right at all.
and now a massive patch drops that MUST BE APPLIED NOW - so, intense pressure to comply without careful evaluation?
call me paranoid, sure. but this doesn't fit what I expect to see, and I don't like it, and I am feeling very suspicious that the people making these decisions are having their decisionmaking compromised in some fashion.
-
have you seen the size of the thing?
-
have you seen the size of the thing?
-
-
-
M mjack@mastodon.bsd.cafe shared this topic
