221–230 of 263 posts
Earlier quoted context omitted.
Then what stops the malware accessing the keyring?
On disk, it’s encrypted. The running service, at least on macOS, only hands the item out to specific apps, based on their code signing identity.
If all Homebrew "apps" are the same key then accepting a keyring notification on one app is a lost cause at it would allows things vulnerable to RCE to read/write everything?
Earlier quoted context omitted.
Maybe I am missing something but how and why would a display protocol have anything to do with file access model??
In Wayland you have these xdg-portals that broker access to the filesystem, microphone, webcam, etc. I am not knowledgeable about the security model though.
E.g. under X you can use bubblewrap or firejail to restrict access to the web or whatever for some program, but still give that program access to for example an xdg portal that lets you "open url in web browser" (except the locked-down program can't for example see the result of downloading that web page)
Earlier quoted context omitted.
What is a proper solution for this? I don't imagine gpg can help if you encrypt it but decrypt it when you login to gnome, right? However, it would be too much of a hassle to have to authenticate each time you need a token. I imagine macOS people have access to the secure enclave using touch ID but then even that is not available on all devices. I feel like we are barking up the wrong tree here. The plain text token…
The way I solve the plain text problem is through a combination of direnv[1] and pass[2]. For a given project, I have a `./creds` directory which is managed with pass and it contains all the access tokens and api keys that are relevant for that project, one per file, for example, `./creds/cloudflare/api_token`. Pass encrypts all these files via gpg, for which I use a key stored on a Yubikey. Next to the `./creds` dir…
Earlier quoted context omitted.
You don’t need certificates , just use PGP keys like Maven.
PGP keys don't tell you anything about a developers "real identity". Theoretically theres some "web of trust", but realistically everyone just blindly downloads whatever PGP key is listed on the repo's install instructions.
The credential harvesting aspect is what concerns me most for the average developer. If you've ever run `npm install` on an affected package, your environment variables, .npmrc tokens, and potentially other cached credentials may have been exfiltrated. The action item for anyone potentially affected: rotate your npm tokens, GitHub PATs, and any API keys that were in environment variables. And if you're like most deve…
Also a good reminder that you should be storing secrets in some kind of locker, not in plain text via environment variables or config files. Impossible to get everyone on board but if you can you should as much as possible. I hate that high profile services still default to plain text for credential storage.
If I just need to `fly secrets set KEY=hunter2` one time for production I can copy it from a paper pad even but if it's a key I need to use every time I run a program that I'm developing on, it's likely going to end up at least being in my program's shell environment (and thus readable from its /proc/pid/environ). So if I `npm install compromised-package` – even from some other terminal – can't it just `grep -a KEY= /proc/*/environ`?
Or are you saying the programs we hack on should use some kind of locker api to fetch secrets and do away with env vars?
Earlier quoted context omitted.
PGP keys don't tell you anything about a developers "real identity". Theoretically theres some "web of trust", but realistically everyone just blindly downloads whatever PGP key is listed on the repo's install instructions.
Bullshit. The public key can be obtained by several easy means, like visiting the publisher website or social network site like GitHub which is common. That verifies the identity just as well as any certificate! But with much less trouble.
Earlier quoted context omitted.
PGP keys don't tell you anything about a developers "real identity". Theoretically theres some "web of trust", but realistically everyone just blindly downloads whatever PGP key is listed on the repo's install instructions.
Bullshit. The public key can be obtained by several easy means, like visiting the publisher website or social network site like GitHub which is common. That verifies the identity just as well as any certificate! But with much less trouble.
Earlier quoted context omitted.
> This does mean entering your keyring password a lot. Not when you put that keyrings password into the user keyring. I think it is also cached by default.
Then what stops the malware accessing the keyring?
I have an friend that starts an project next month that will rely on npm. He is quite a noob and didn't code in ages. He will have almost no clue how to harden against this, he will probably not even notice if he becomes a victim until something really bad happens. Pretty sad.
"a friend" because friend starts with a consonant sound, not a vowel sound. "a project" for the same reason. HTH.
Earlier quoted context omitted.
char * left_pad (const char * string, unsigned int pad) { char tmp[strlen (string)+pad+1]; memset (tmp, ' ', pad); strcpy (tmp+pad, string); return strdup (tmp); } Doesn't sound too hard in my opinion. This only works for strings, that fit on the stack, so if you want to make it robust, you should check for the string size. It (like everything in C) can of course fail. Also it is a quite naive implementation, since i…
strndup would be safer if I correctly recall from my C days?
strndup prevents you from overrunning the allocation of a string given that you pass it the containing allocations size correctly. But if you got passed something that is not a string, there will be a buffer overrun right there in the first line. Also what outer allocation?
You use strcpy when you get a string and memcpy when you get an array of char. strncpy is for when you get something that is maybe a string, but also a limited array. There ARE use cases for it, but it isn't for safety.