Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A way to exclude sensitive files issue still open for OpenAI Codex

github.com

Post reply on HN
Print view View original

121–130 of 157 posts

Re: A way to exclude sensitive files issue still open for OpenAI Codex

#121

Post by pamcake »

skybrian wrote: post #88

To avoid the risk of exfiltration, we need to stop using .env for security. API keys needed when working in a repo should be handled by a proxy like ssh-agent, and we need something better than bearer auth.

Yes you should. It will come naturally if you go down the road of separating code from data and properly isolating dev and prod environments, applying principle of least privilege as you do.

.env files for creds are a convenience for dev and testing. They were never supposed to be used for security or carried around with sensitive stuff inside. None of this is new.

Re: A way to exclude sensitive files issue still open for OpenAI Codex

#122

Post by albedoa »

jgalt212 wrote: post #42
cowsandmilk wrote: post #15

Earlier quoted context omitted.

100% this. The idea that Codex should enforce this is putting the security boundary at the wrong layer. If you don’t want codes to access something, make it so it doesn’t have access.

I'm a fan of belt and suspenders.

Where did you run off to little boy.

Re: A way to exclude sensitive files issue still open for OpenAI Codex

#123

Post by tomjakubowski »

skybrian wrote: post #88

To avoid the risk of exfiltration, we need to stop using .env for security. API keys needed when working in a repo should be handled by a proxy like ssh-agent, and we need something better than bearer auth.

The desire not to leak valuable secrets is a strong argument for supporting local-first developer workflows. If an AI agent exfiltrates the credentials to connect to my local dev Postgres database which stores synthetic data, that's pretty low impact.

Re: A way to exclude sensitive files issue still open for OpenAI Codex

#124

Post by akoboldfrying »

aleph_minus_one wrote: post #85
atomicnumber3 wrote: post #72

Earlier quoted context omitted.

We managed to generate probably-correct code, which can then be probably-corrected recursively to get to something that runs (usually). This made everyone scream and lose their minds saying that code is finished, people think they don't need a technical cofounder anymore, think they don't need engineers anymore, etc. Then they're, at varying speeds, finding out they're wrong. It seems oddly circular to me that the _e…

> It seems oddly circular to me that the _exact hubris_ non-engineers have long accused engineers of - and we have indeed been too often guilty of - they themselves turn out to be JUST as guilty of! I have hardly ever seen this kind of hubris among software developers. The only thing that was common was many software developers were - let's say - somewhat direct in their feedback towards people who are not willing to…

> I have hardly ever seen this kind of hubris among software developers.

Dilbert's entire schtick is the profound ineptitude of "business people".

Re: A way to exclude sensitive files issue still open for OpenAI Codex

#125

Post by dijksterhuis »

atomicnumber3 wrote: post #72
embedding-shape wrote: post #44

Earlier quoted context omitted.

The Codex bug tracker is a great insight into how wide the knowledge gap seem to be between users. The issue where people ask them to add back /undo or whatever it is instead of just learning to use git, probably reached 100 comments at least by now. People seemingly don't really understand the computers they use on a daily basis, and refuse to learn too.

We managed to generate probably-correct code, which can then be probably-corrected recursively to get to something that runs (usually). This made everyone scream and lose their minds saying that code is finished, people think they don't need a technical cofounder anymore, think they don't need engineers anymore, etc. Then they're, at varying speeds, finding out they're wrong. It seems oddly circular to me that the _e…

> Just like engineers thought all sales did was bother people, and all marketing did was send emails

i mean, sure, the marketing one may be a bit simplified as the emails also need to have pretty pictures in them. and yeah, sure, sales people do need to find the people they’ll eventually start bothering later.

/s

> But all our CTOs seems to have collectively thrown us to the wolves.

the kind of person who usually finds their way into the executive class doesn’t get there by looking after those under them. they get there by avoiding blame and taking credit.

which, funnily enough, is exactly what a hype cycle is all about.

Re: A way to exclude sensitive files issue still open for OpenAI Codex

#126

Post by [deleted] »

aleph_minus_one wrote: post #85
atomicnumber3 wrote: post #72

Earlier quoted context omitted.

We managed to generate probably-correct code, which can then be probably-corrected recursively to get to something that runs (usually). This made everyone scream and lose their minds saying that code is finished, people think they don't need a technical cofounder anymore, think they don't need engineers anymore, etc. Then they're, at varying speeds, finding out they're wrong. It seems oddly circular to me that the _e…

> It seems oddly circular to me that the _exact hubris_ non-engineers have long accused engineers of - and we have indeed been too often guilty of - they themselves turn out to be JUST as guilty of! I have hardly ever seen this kind of hubris among software developers. The only thing that was common was many software developers were - let's say - somewhat direct in their feedback towards people who are not willing to…

[deleted]

Re: A way to exclude sensitive files issue still open for OpenAI Codex

#127

Post by ChrisRun »

martylamb wrote: post #46
lelandfe wrote: post #12

Earlier quoted context omitted.

Just be aware that AI agents will explore alternate means of accessing said files: https://news.ycombinator.com/item?id=48348578

Yes. I found this quickly after wrapping codex in a launcher that uses bubblewrap to exclude certain files and directories based on a config file at the project root. My best solution so far is to also include instructions for the agent that explain that it is not allowed to see certain files, and that their inaccessibility is not an error, and that it must not attempt to access them through other means (e.g. via git…

Interesting you said it's not foolproof. Did the agent ignore your instruction somehow?

Re: A way to exclude sensitive files issue still open for OpenAI Codex

#128

Post by TZubiri »

cozzyd wrote: post #86
TZubiri wrote: post #70

Earlier quoted context omitted.

Sounds overkill, how about giving the agent its own user?

That's what I do in part because I went it to use the same system libraries etc. installed on my laptop, but I worry it will try to use privesc exploits...

highly unlikely the LLM will try to do privesc exploits, LPE risk still exists and should be assumed though, although the more likely risk model is the LLM installing an infected left-pad package, or (on servers) installing a dependency with a RCE vuln, or creating a new RCE vuln from scratch.

If we are talking about running the agent on a dev machine, though, Codex doesn't seem to introduce a lot of risk, considering that I can already add OS protection layers, and that the devs added their own protection layers, and that I can direct the model towards my preferences (like not installing dependencies through npm or pip).

Re: A way to exclude sensitive files issue still open for OpenAI Codex

#130

Post by AdieuToLogic »

8organicbits wrote: post #64
SoftTalker wrote: post #55

Earlier quoted context omitted.

bash actually has a "restricted" mode which is sort of like that. In restricted mode, the following are disallowed: - Changing directories with cd. - Setting or unsetting the values of SHELL, PATH, HISTFILE, ENV, or BASH_ENV. - Specifying command names containing /. - Importing function definitions from the shell environment at startup. - Parsing the values of BASHOPTS and SHELLOPTS from the shell environment at star…

Does that work? I've never seen it used. It seems easy to escape. The docs seem to suggest using alternate approaches. > Modern systems provide more secure ways to implement a restricted environment, such as jails, zones, or containers. https://www.gnu.org/software/bash/manual/html_node/The-Restr...

>> bash actually has a "restricted" mode ...

> Does that work? I've never seen it used. It seems easy to escape.

Yes, it does work for its intended purpose. It has often been used in combination with chroot[0] as well.

> The docs seem to suggest using alternate approaches.

>> Modern systems provide more secure ways to implement a restricted environment, such as jails, zones, or containers.

These approaches are not mutually exclusive with restricted shell use. For example, one could use FreeBSD jails to secure Apache httpd and/or Nginx and still employ a restricted shell to evaluate requests.

0 - https://man.freebsd.org/cgi/man.cgi?query=chroot&apropos=0&s...

Post reply on HN