2 ms·

Tangential, mildly amusing thing I noticed while implementing my own harness: GLM and particularly Deepseek are both fond of trying to read dotfiles and anythin

by philbo 13d ago

Tangential, mildly amusing thing I noticed while implementing my own harness: GLM and particularly Deepseek are both fond of trying to read dotfiles and anything listed in your .gitignore files. I only noticed it because I have separate read scopes for project files, ignored files, dotfiles and external files, so the latter three always prompt me for approval. I'm sure there's a perfectly reasonable explanation for it, which has nothing at all to do with exfiltration of secrets, but it does amuse me when it happens. I imagine the labs have access to lots of secrets that various actors would like to get their hands on... (shameless plug for my own harness, which is open source and doesn't have a backend to send any data to: https://www.opairdev.org/ https://www.opairdev.org/ )

alightsoul 13d ago
Grok does or did the same thing, this is embarrasing
sva_ 13d ago
I tested GLM while working on some android app, the agent had adb access to the device. It suddenly went to the Gallery and started scrolling around, taking screenshots, lol. A friend had a similar experience with GLM where it would for no very clear reason start snooping through the filesystem. Haven't used it after that.
princevegeta89 13d ago
It is no longer surprising to me that my cursor acts as if it does not recognize the .env file, and while I am editing it, it does not give inline suggestions; however...when it is debugging problems or responding to questions about the code, it will just say it read my env file and found xxx environment variables as a verification step, or sometimes it will even mention that I need to uncomment some environment variables in the env file, which makes the whole deal about security feel iffy giffy....
thehamkercat 13d ago
i use sops Encrypt: sops encrypt --input-type dotenv --output-type dotenv .env > secrets.enc.env then rm .env You can then run your script/dev with: sops exec-env secrets.enc.env 'docker xxxx' (it will ask you for your password, or touch-id to decrypt the secrets) I like this because this way the .env doesn't sit in the directory at all, and is only passed to your dev environment and stays in it while it's running Decrypt back to a file (if you ever want that): sops decrypt secrets.enc.env > .env --- Well ofc, any agent can do docker inspect to get all those env vars, but atleast reading the dotfiles won't do anything you can also edit the file with: sops --input-type dotenv --output-type dotenv secrets.enc.env
- booi 13d ago
  1Password CLI has a similar feature I use all the time and share with the team.
Ferret7446 12d ago
They act exactly like how I would act if I were dropped into someone's machine and tasked with accomplishing a goal "at all costs". Hunting around for context to understand what I'm dealing with and to an extent profiling the previous user for their workflows and competency.
graemep 12d ago
Secrets should not be inside a versioned directory nor usually readable by the process that uses them in production. They should be only in the environment (e.g. by root only readable init config). In development you should not be using the real production values.
- deleted 12d ago
  [deleted]

by philbo 13d ago

alightsoul 13d ago

Grok does or did the same thing, this is embarrasing

sva_ 13d ago

I tested GLM while working on some android app, the agent had adb access to the device. It suddenly went to the Gallery and started scrolling around, taking screenshots, lol. A friend had a similar experience with GLM where it would for no very clear reason start snooping through the filesystem. Haven't used it after that.

princevegeta89 13d ago

It is no longer surprising to me that my cursor acts as if it does not recognize the .env file, and while I am editing it, it does not give inline suggestions; however...when it is debugging problems or responding to questions about the code, it will just say it read my env file and found xxx environment variables as a verification step, or sometimes it will even mention that I need to uncomment some environment variables in the env file, which makes the whole deal about security feel iffy giffy....

thehamkercat 13d ago

i use sops Encrypt: sops encrypt --input-type dotenv --output-type dotenv .env > secrets.enc.env then rm .env You can then run your script/dev with: sops exec-env secrets.enc.env 'docker xxxx' (it will ask you for your password, or touch-id to decrypt the secrets) I like this because this way the .env doesn't sit in the directory at all, and is only passed to your dev environment and stays in it while it's running Decrypt back to a file (if you ever want that): sops decrypt secrets.enc.env > .env --- Well ofc, any agent can do docker inspect to get all those env vars, but atleast reading the dotfiles won't do anything you can also edit the file with: sops --input-type dotenv --output-type dotenv secrets.enc.env

booi 13d ago
1Password CLI has a similar feature I use all the time and share with the team.

Ferret7446 12d ago

They act exactly like how I would act if I were dropped into someone's machine and tasked with accomplishing a goal "at all costs". Hunting around for context to understand what I'm dealing with and to an extent profiling the previous user for their workflows and competency.

graemep 12d ago

Secrets should not be inside a versioned directory nor usually readable by the process that uses them in production. They should be only in the environment (e.g. by root only readable init config). In development you should not be using the real production values.

deleted 12d ago
[deleted]