So, we should make it easier to feed that reliability back upstream.
Probably the most useful thing you can do with these LLM-transpilations for now: If the transpiled version passes all original tests, I can run my application test suite against it and use it to discover test coverage deficiencies in the original!
If it crashes or otherwise observably misbehaves, I know the real project was missing regression tests for something. We could make upstream so much more resilient against accidentally breaking stuff in future updates, if only it becomes safe (offline + no side effects) and easy (if it crashes/locks, it is not from some memory safety bug from 25k transactions earlier) to run these transpiled projects as one row in our everyday integration matrix.
If the return path is null that just clarifies unattended notifications should not be returned. The mail is still considered to be sent by the transmitting system, and when no mailbox is specified, the implied envelope sender simply defers to the "[email protected]" address.
(Accepting mail at the "postmaster" mailbox is a mandatory part of SMTP, as is mentioning your fully qualified domain name in the "Hello" message when initiating the session. Public mail exchanges are free to, and often do, reject clients that submit anything other than resolvable domains there. Same with clients that use <> for applications other than those very limited "notification about specific quoted/referenced message" scenarios where the standards mandate <>.)
> Nobody can send you a unicode file and make you run an infinite loop or whatever.
I find it interesting/weird (that the spec is written in such unrestricted DSL) for pretty much that reason. They could send you input for rules that are in the spec, and hope you translated them to your programming language of choice in a fairly straightforward manner. Which may then have perfectly acceptable average runtime properties, whether you do it in UTF-8 or UTF-32 (fixed-width) space .. but a worst-case that can reliably be triggered with chosen input!
In a way, the "let the money decide who is a good citizen" already works. Just not in our favor:
Most of the spam I receive is not from some rando using an IP I know nothing about. Its from providers that keep making good money with their current anti-abuse.. strategy. As much as I would like, I cannot refuse all mail from certain providers, because some of their customers are "important" and non-abusive. But I get the good and the bad all laundered together¹.
¹) Some do allow recipients to distinguish, e.g. Sendgrid add an X-Entity-ID header which is a stable 1:1 or <small-number>:1 map between short ascii identifiers and customers. So if you store that mapping, you can reject the usual "From: <[email protected]> but not sent using the account associated with bigcorp.example". (The way they easily could, if they cared.)
> Can you send mail from something that doesn't have a DNS entry?
You never really could. Participating in public email exchange requires that the sender can resolve then "fully qualified" domain in your return address. Except after prior agreement or authentication, messages simply that fail this are not generally accepted.
> If your headers are correct, are you guaranteed mail bounces for un-deliverable emails?
Even better: You are more likely to see an immediate refusal instead of a delayed bounce, if the recipient exchange can during transmission already determine that they do not want message claiming to be originally transmitted from X to Y yet breaking their ability to check the signature added by X.
Yes! Forwarding is the reason mail flow authentication does not work very well today. Fix the forwarding use cases (and by extension: mailing lists & out of office arrangements) and we can finally just tell all senders:
"Your domains do not match, please use DMARC so we can automatically detect whether that is OK. No excuses, no exemptions, your use case can be dealt with using DMARC!"
Because we may be missing comments that GitHub has deleted without leaving tombstones (which sucks), it is not entirely clear whether the person creating and responding to the issue I linked is the person trying to have others run that trojan file, or whether they have fallen victim to it .. and merely quoted the link from a now-vanished comment.
(Microsoft should stop it with the "This is not the web page you are looking for." where people specifically came looking to learn whether something was administratively blocked - or whether it is no longer available by choice of the affected party.)
Some scientific endeavors can be paused and maybe later relaunched, if funding has not dried up and temporarily-worthless machinery has not been left to rot.
But stuff like mitigating the constant threat of big enough objects showing up on a collision course with earth should not be paused until those eye-catchers fall out of the sky. If there is something coming at us that can wipe out more than the stock price of one particularly space-enthusiastic company, we should like to know within a time period appropriate for our current planetary defense capabilities. Which will surely improve, over time - so maybe we can pollute the sky, later.
Cloudflare does not notice (until a customer complains) that they are sending broken responses at scale? I would have thought they would notice this from sampling and linting a few replies.. just in case they did something like Cloudbleed again.
I think this one has more to do with excessive dependencies, and lack of splitting into individually installable packages and/or static linking.
I have already avoided having to evaluate whether I am affected by some issue because I added patches at startup that crash before certain unused-yet-installed modules are to be loaded.
Also, for those Python packages that still have a pure version that defers to stdlib and a separate muh-performance binary option with statically linked dependencies, I can generally just install the former and skip the version bumps for dependencies. The performance advantage may be negligible or negative outside of benchmarking 100k calls.. of code actually called 11 times a day, on a non-critical path.
This stuff has been brewing for years, but since technically you could fix all instances with minimal StackOverflow downtime [1] and a slightly different pattern, few people worked on either using engines with data structures less prone to the worst case or adding the generic workarounds for those that have them.
e.g. in cPython, until 3.11, there was no support for atomic grouping (roughly translation: "never backtrack inside of this expression"). There is little useful advice a linter can give, if there is no predictable-runtime way to express what you want within a single match step, because you really do want to unwind the stack and check for repeats (just without any of the exponential runtime stuff, please).
A German police officer was fatally shot in 2010 after failing to identify himself when his manipulation on the door had alerted the known-armed subject of a planned search. The shooter was (eventually) acquitted. Though the circumstances were rather unusual, the court noted that in that specific case, the inability to ascertain the nature & extent of the threat within available time made acting this way based on his assumptions excusable.
Since this can only underflow and some written bits are not attacker-chosen, does this not imply that the patchable part of the software could reliably detect this just in time and panic on suspected USB DMA corruption? Where is the catch?
>The original content doesn’t exactly disappear; it just becomes raw material that most people never touch directly.
It does disappear. There is already much less expert knowledge shared after the breakdown of those platforms that used to be so good at encouraging it. Both what the clankers can regurgitate and what humans can find themselves on the internet is increasingly stale and thinned. My GPU can generate fairly good content now.. 2023 content.
Do you have any company in mind (within the subset the argument refers to, so one that achieved >=15% monthly growth with sufficient consistency) without one or more worrying externalities?
Though what I have see so far is far from everything that could be learned from these surprisingly-humanlike mammals. Still need more research on timing. Maybe protein metabolism is not that different from the better studied methods of derailing glucose metabolism. Maybe the damage is set and done after any prolonged phase of inappropriate diet, and later minor adjustments in consumption have very little additional effect, after controlling for weight and caloric intake.
Maybe all humans need to do is watch their protein intake until puberty.. and then only 60 years later, as failing to retain muscle strength becomes more likely to kill them than any detrimental effect of excessive protein intake.
>the various ACME clients like acme.sh are run with elevated privileges
Its really not that difficult to not grant excessive privileges - at the very least for recurring ("cron") runs, once filesystem structure, cache invalidation triggers and web server configuration are in place. Its a shame this is still taught in the "just run as admin" style.
So, we should make it easier to feed that reliability back upstream.
Probably the most useful thing you can do with these LLM-transpilations for now: If the transpiled version passes all original tests, I can run my application test suite against it and use it to discover test coverage deficiencies in the original!
If it crashes or otherwise observably misbehaves, I know the real project was missing regression tests for something. We could make upstream so much more resilient against accidentally breaking stuff in future updates, if only it becomes safe (offline + no side effects) and easy (if it crashes/locks, it is not from some memory safety bug from 25k transactions earlier) to run these transpiled projects as one row in our everyday integration matrix.