Hacker Newsnew | past | comments | ask | show | jobs | submit | AdieuToLogic's commentslogin

>> Attacks like this are not helped by the increasingly-common "curl | bash" installation instructions ...

> It's not really any different than downloading a binary from a website, which we've been doing for 30 years.

The two are very different, even though some ecosystems (such as PHP) have used the "curl | bash" idiom for about the same amount of time. Specifically, binary downloads from reputable sites have separately published hashes (MD5, SHA, etc.) to confirm what is being retrieved along with other mechanisms to certify the source of the binaries.


If the attacker already controls the download link and has a valid https certificate, can't they just modify the published hash as well?

Which is the reason why it's better to actually cryptographically sign the packages, and put a key in some trusted keystore, where it can actually be verified to belong to the real distributor, as well as proving that the key hasn't been changed in X amount of days/months/years.

Still doesn't address the fact that keys can be stolen, people can be tricked, and the gigantic all-consuming issue of people just being too lazy to go through with verifying anything in the first place. (Which is sadly not really a thing you can blame people for, it takes up time for no easily directly discernable reason other than the vague feeling of security, and I myself have done it many more times than I would like to admit...)


> If the attacker already controls the download link and has a valid https certificate, can't they just modify the published hash as well?

This implies an attacker controlling the server having the certificate's private key or the certificate's private key otherwise being exfiltrated (likely in conjunction with a DNS poisoning attack). There is no way for a network client to defend against this type of TLS[0] compromise.

0 - https://en.wikipedia.org/wiki/Transport_Layer_Security


> Here's my ruleset ...

Thank you for sharing a non-trivial working example of a sandbox-exec configuration. Having an exemplar such as what you have kindly shared is hugely beneficial for those of us looking to see what can be done with a tool such as this.


Thank you - you inspired me to open-source this work properly -> https://eugene1g.github.io/agent-safehouse/

> Thank you - you inspired me to open-source this work properly

It is both myself and the OSS community which thank you.

  Great things are done by a series of small things brought 
  together.[0]
0 - https://www.brainyquote.com/quotes/vincent_van_gogh_120866

> A lot of how I form my thoughts is driven by writing code, and seeing it on screen, running into its limitations.

Two principles I have held for many years which I believe are relevant both to your sentiment and this thread are reproduced below. Hopefully they help.

First:

  When making software, remember that it is a snapshot of 
  your understanding of the problem. It states to all, 
  including your future-self, your approach, clarity, and 
  appropriateness of the solution for the problem at hand. 
  Choose your statements wisely.
And:

  Code answers what it does, how it does it, when it is used, 
  and who uses it. What it cannot answer is why it exists. 
  Comments accomplish this. If a developer cannot be bothered 
  with answering why the code exists, why bother to work with 
  them?

To your first point - so are my many markdown files that I tell Codex/Claude to keep updated while I’m doing my work including telling them to keep them updated with why I told them to do certain things. They have detailed documentation of my initial design goals and decisions that I wrote myself.

Actually those same markdown files answer the second question.


It's almost like programming via markdown.

Or like every tech lead has had to do when documenting specifications for a team…

> If a developer cannot be bothered with answering why the code exists, why bother to work with them?

Most people can't answer why they themselves exist, or justify why they are taking up resources rather than eating a bullet and relinquishing their body-matter.

According to the philosophy herein, they are therefore worthless and not worth interacting with, right?


>> Works if you supply the correct include path(s)

The location of Standard C headers do not need to be supplied to a conformant compiler.

>> You could arguably fault ccc's driver for not specifying the include path to find the native C library on this system.

This is not a good implementation decision for a compiler which is not the C compiler distributed with the OS. Even though Standard C headers have well-defined names and public contracts, how they are defined is very much compiler specific.

So this defect is a "somethingburger."


Well this compiler was written to build Linux as a proof of concept. You don't need a libc for building the kernel. Was it claimed anywhere that it is a fully compliant C compiler?

That's kind of moving the goal post no? They set out to build a C compiler that could compile the kernel, it can do that just fine?

Searching for "compliant" in the README doesn't seem to indicate that building a "conformant compiler" was even the goal here, so not sure why that's suddenly should be a requirement.


> Eloquent, moving, and more-or-less exactly what people said when cameras first hit the scene.

This is a non sequitur. Cameras have not replaced paintings, assuming this is the inference. Instead, they serve only to be an additional medium for the same concerns quoted:

  The process, which is an iterative one, is what leads you 
  towards understanding what you actually want to make, 
  whether you were aware of it or not at the beginning.
Just as this is applicable to refining a software solution captured in code, just as a painter discards unsatisfactory paintings and tries again, so too is it when people say, "that picture didn't come out the way I like, let's take another one."

Photography’s rapid commercialisation [21] meant that many painters – or prospective painters – were tempted to take up photography instead of, or in addition to, their painting careers. Most of these new photographers produced portraits. As these were far cheaper and easier to produce than painted portraits, portraits ceased to be the privilege of the well-off and, in a sense, became democratised [22].

Some commentators dismissed this trend towards photography as simply a beneficial weeding out of second-raters. For example, the writer Louis Figuier commented that photography did art a service by putting mediocre artists out of business, for their only goal was exact imitation. Similarly, Baudelaire described photography as the “refuge of failed painters with too little talent”. In his view, art was derived from imagination, judgment and feeling but photography was mere reproduction which cheapened the products of the beautiful [23].

https://www.artinsociety.com/pt-1-initial-impacts.html#:~:te...


Cameras have not replaced paintings, assuming this is the inference.

You wouldn't have known that, going by all the bellyaching and whining from the artists of the day.

Guess what, they got over it. You will too.


What stole the joy you must have felt, fleetingly, as a child that beheld the world with fresh eyes, full of wonder?

Did you imagine yourself then, as your are now, hunched over a glowing rectangle. Demanding imperiously that the world share your contempt for the sublime. Share your jaundiced view of those that pour the whole of themselves into the act of creation, so that everyone might once again be graced with wonder anew.

I hope you can find a work of art that breaks you free of your resentment.


Thank you for brightening my morning with a brief moment of romantic idealism in a black ocean of cynicism

So I'm the cynic here. That's a hoot.

[flagged]


Thank you for the AI warning, so I didn't have to read that.

Ah well, I'm neurodivergent and it’s challenging for me to write a comment while remembering that others don’t have access to my thoughts and might interpret things differently. And it's too late to edit it now

What I wanted to show is that, clearly different from a camera or other devices, AI can copy originality. OPs comment was pretty original in it's wording, and gpt came pretty close imo. It really wasn't meant as a low effort comment


If AI can copy originality, we should be questioning our concept of originality. Not that it isn't a very suspect concept already. It's something to praise children for (autonomously combining the concepts provided to them) - but I've had the unwisdom of lurking long enough on the pre-LLM noosphere to get a glimpse of what gets done to the real originals since time self-fulfillingly immemorial.

'sides, I'm also neurocute af and feel acutely endangered by stuff that's effectively channeled: expressions which represent coherent agentic thought, yet are not bound to the volition of any individual embodied organism by regular personal accountability. If psychology is any indication, as non-augmented humans we're already not consciously aware of half our driving forces, and that's been trouble enough throughout history. How do you find it at all safe for the environment to broadcast Big Nobody's thoughts towards sentient beings?

AI is the linguistic instrument of those who cast away their capacity for bona fide verbal cognition as a condition of entering the hierarchy. They're a rather dangerous bunch, what with no beans to spill or marbles to lose. Subtle too, "somehow" got all normies working for 'em and usually not even knowing it till it's too late. Tell em I said hi!


Plot twist. The comment you love is the cynical one, responding to someone who clearly embraces the new by rising above caution and concern. Your GPT addition has missed the context, but at least you've provided a nice little paradox.

What I especially enjoy is seeing those people accuse AI of being a "parrot" or a "mindless next-token predictor." Inevitably, these accusations are levied in comments whose every thought and token could have been lifted verbatim from any of a thousand such comments over the past few years, accompanied by the rusty squeak of goalpost wheels.

>> Cameras have not replaced paintings, assuming this is the inference.

> You wouldn't have known that, going by all the bellyaching and whining from the artists of the day.

> Guess what, they got over it.

You conveniently omitted my next sentence, which contradicts your position and reads thusly:

  Instead, they serve only to be an additional medium for the 
  same concerns quoted ...
> You will too.

This statement is assumptive and gratuitous.


Username checks out, at least.

> Username checks out, at least.

Thoughtful retorts such as this are deserving of the same esteem one affords the "rubber v glue"[0] idiom.

As such, I must oblige.

0 - https://idioms.thefreedictionary.com/I%27m+rubber%2c+you%27r...


Logic needs to be shown the door on occasion. Sometimes via the help of an ole Irish bar toss.

There are other sites. Other doors, on other bars.

> Guess what, they got over it. You will too.

Prediction is difficult, especially of the future.


It ain't over 'til it's over. And when you come to a fork in the road, take it.

Cognitive skills are just like any other - use them and they will grow, do not and they will decline. Oddly enough, the more one increases their software engineering cognition, the less the distance between "The Builder" and "The Thinker" becomes.

> You almost never see a list of banned Java features ...

The instanceof[0] operator is typically banned from use in application code and often frowned upon in library implementations.

0 - https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.htm...


I've never heard of that being banned. It hasn't been banned anywhere i've written Java.


Similarly I never been in a company that outright banned c++ language of library features[1]. Turns out that different companies are different.

[1] I guess you would get some push back at review time if you used auto_ptr.


> I've never heard of that being banned. It hasn't been banned anywhere i've written Java.

Once code such as the below is rejected in a code review, the next version often submitted is an "if-else-if" ladder using `instanceof` (which is effectively the same thing).

  TheReturnType r = null;

  try {
    DomainType1 instance = (DomainType1)obj;

    r = ...
    }
    catch (ClassCastException ex) {}

  if (r == null)
    try {
      DomainType2 instance = (DomainType2)obj;

      r = ...
      }
      catch (ClassCastException ex) {}

  if (r == null)
    try {
      DomainType3 instance = (DomainType3)obj;

      r = ...
      }
      catch (ClassCastException ex) {}

  ...
And yes, I have seen the above scenario played out in a professional setting.


Never seen this being banned. Whats the reason?


If you have to ask an object what its type is, you're probably about to cast it, and these are operations that the language doesn't enforce that you do together (and so the habit of casting can lead to the habit of casting without the check...). There are times when it's appropriate but generally if you have to ask what type an object is, your code is already starting to smell (because typically dispatching on type is handled by polymorphism, not be the programmer manually implementing it).


>> The instanceof[0] operator is typically banned from use in application code and often frowned upon in library implementations.

> Never seen this being banned. Whats the reason?

Its usage encodes a priori assumptions of what a super-type could be, often expressed in an "if-else-if tree", thus making the logic doing so needlessly brittle and difficult to maintain.

Library logic sometimes needs to use this construct (I'd argue those abstractions need to be rethought however), but an application which does exhibits a failure in domain modelling IMHO.


It can be a code smell, but there are legitimate uses. This is not something that I would ever "ban".

Over-eager code analyser tools are themselves a "smell", in that you either justifiably or unjustifiably don't trust your developers, trying to make up for their real or perceived deficits with a rather dumb tool. That never goes well in my experience.


Both can be true if each group selectively provides LLM output supporting their position. Essentially, this situation can be thought of as a form of the Infinite Monkey Theorem[0] where the result space is drastically reduced from "purely random" to "likely to be statistically relevant."

For an interesting overview of the above theorem, see here[1].

0 - https://en.wikipedia.org/wiki/Infinite_monkey_theorem

1 - https://www.yalescientific.org/2025/04/sorry-shakespeare-why...


> This is artisans vs industry. ... But it's close enough often enough.

If I had a nickle every time I heard the equivalent of "close enough often enough" on root-cause analysis bridge calls during prod outages...


> I love this, it resonates so deeply with me. Code is, for me, joy.

A credo I have held for some time is:

  When making software, remember that it is a snapshot of
  your understanding of the problem.  It states to all,
  including your future-self, your approach, clarity, and
  appropriateness of the solution for the problem at hand.
  Choose your statements wisely.
HTH


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: