Sorry, no. I'm an indie developer so I wish I can make some money with it. It would be a fair price as I wrote on landing page, will less than $20/year.
But I can share the tech stack I use:
- WXT: the browser extension framework
- Vercel AI SDK. Both SDK core and SDK UI. I wrote a bridge that I can proxy the api request to background script which compat with the SDK streaming protocol, so that I can use the SDK UI.
- Next.js: for the landing page and the up coming cloud service (e.g. prompt sync)
I understand your concern. I think "access to much information" means this extension require <all_url> host_permission, which I don't want to either but it must.
Because custom AI provider's API base url is submit by user. If I want to call the API on background script, this base url must be listed on host_permissions. Otherwise it will cause a CORS problem.
optional_host_permissions may fix this problem, but since the base url is set by user, it's not possible to use this workaround.
Actually, the nice thing about chrome extensions is that users can view all requests made by content_script and background script through devtool. This is much more intuitive than checking the code.
Our approach to email is fundamentally different. We very much believe in the power of open source, and that's why we built react.email to support the creation of beautiful templates using modern technology like React, Tailwind, and TypeScript.
"Ruff, like pylyzer, is a static code analysis tool for Python written in Rust, but Ruff is a linter and pylyzer is a type checker & language server. pylyzer does not perform linting, and Ruff does not perform type checking."
I read somewhere that some recent changes in systems would've made the backdoor useless so they had to rush out, which caused them to be reckless and get discovered
This refers to the fact that systemd was planning to drop the dependency on liblzma (the conpression library installed by xz), and instead dlopen it at runtime when needed. Not for security reasons, but to avoid pulling the libs into initramfs images.
The backdoor relies on sshd being patched to depend on libsystemd to call sd_notify(), which several distros had done.
OpenSSH has since merged a new patch upstream that implements similar logic to sd_notify() in sshd itself to allow distros to drop that patch.
So the attack surface of both sshd and libsystemd has since shrunk a bit.
> The backdoor relies on sshd being patched to depend on libsystemd to call sd_notify
I remember when we added sd_notify support to our services at work, I was wondering why one would pull in libsystemd as a dependency for this. I mean, there's a pure-Python library [1] that basically boils down to:
> With proper error handling, that's about 50 lines of C code.
Writing proper error handling in C is a very tedious and error prone task. So it doesn't surprise me that people would rather call another library instead.
> So it doesn't surprise me that people would rather call another library instead.
Which shall be harder to justify now: "You're calling a gigantic library full of potential security holes just to call one function, to save writing a few lines of code, are you trying to JIA TAN the project?".
> I was wondering why one would pull in libsystemd as a dependency for this. I mean, there's a pure-Python library [...] With proper error handling, that's about 50 lines of C code.
There's also a pure C library (libsystemd itself) which already does all that, and you don't need to test all the error handling cases in your 50 lines of C code. It makes sense to use the battle-tested code, instead of writing your own.
The problem is people keep focusing on the libsystemd element because systemd has it's big hate-on crew and the vector was for what's deemed "simple".
The better question though is...okay, what if the code involved was not simple? xz is a full compression algorithm, compressors have been exploit vectors for a while, so rolling your own is a terrifically bad idea in almost all cases. There's plenty of other more sophisticated libraries as well where you could've tried to pull the exact same trick - there's nothing about it being a "simple" inclusion in this case which implies vendoring or rolling your own is a good mitigation.
The saying goes that everyone is always preparing to fight the last war, not the next (particularly relevant because adversaries are likely scouring OSS looking for other projects that might be amenable to this sort of attack - how many applications have network access these days? An RCE doesn't need to be in sshd).
Frankly, I think it is idiotic to require each program to parse an environment variable, open that named file, write a magic string, and all the error handling that that requires -- all for the purpose of having a backchannel between the daemon and its supervisor?
Compare with how s6 does the same thing: instead of passing a random path via an environment variable, it opens the file descriptor itself before exec()ing the binary. All the binary has to do is write a newline to that fd and close it.
