WDYT about this? Simple bare supply-chain protecti...
# proj-architecture
c
WDYT about this? Simple bare supply-chain protection by giving some time to newly uploaded packages to maybe discover issues. https://news.ycombinator.com/item?id=47582632 llamantino also proposed it in the npm discussion SDK PR: https://github.com/OpenHands/software-agent-sdk/pull/2648
👀 1
👍 1
d
Considering the frequency of supply chain attacks has been on the rise, excluding newer packages with a 1 week buffer feels like a good option for a much lower chance of being compromised. Seems like the recent liteLLM and axios bogus packages were discovered in about a day or same day?
nod 1
c
... I went on social media and stuff, to see if there is any other report today. It turns out today... is... not... a good day to figure out serious stuff
😹
🤣 2
d
ohhh cuz it's April fools 😄
😅 1
c
Should we set off the agent to do something similar in OpenHands-CLI and OpenHands repos?
d
I think that's a good idea. It's also nice to be consistent across projects when possible
c
Hah, the CLI
uv
is not happy 😅
Resolving despite existing lockfile due to addition of global exclude newer 2026-03-25T181442.245846344Z
× No solution found when resolving dependencies:
╰─▶️ Because openhands-sdk==1.16.0 was published after the exclude newer time and your project depends on openhands-sdk==1.16.0, we can conclude that your project's requirements are unsatisfiable.
Looking into it
😬 1
ty 1
d
can we add any exceptions for exclude-newer? since openhands-sdk is something we release thinky spin
👀 1
c
@nutritious-balloon-65098 File an issue to apply this packages policy to OpenHands/OpenHands repo too, both npm and python I think. Clone yourself the agent-sdk to see the commits today, and look at the above CLI repo PR too, for illustration
n
I'm on it! can track my progress here.
Done — the request was fully addressed. ### Summary - ✅ Filed the issue in OpenHands/OpenHands: #13697 https://github.com/OpenHands/OpenHands/issues/13697 - ✅ Reviewed the relevant examples first: - software-agent-sdk PR #2648 - OpenHands-CLI PR #630 - ✅ Checked the OpenHands repo context so the issue was grounded in the actual setup: - root Python deps /
uv.lock
- frontend npm deps /
package-lock.json
- existing
.github/dependabot.yml
- ✅ Checked for likely duplicates before filing - ✅ Included the required AI disclosure in the issue body ### Completeness / instruction-following - ✅ The issue asks for applying the package-age policy to both Python and npm - ✅ It references the SDK and CLI work for illustration, as requested - ✅ It calls out the important first-party Python package exemption pattern learned from the CLI PR - ✅ It was filed in the correct repo: OpenHands/OpenHands ### Conciseness - ✅ No local repository code/config files were changed - ✅ No extraneous edits were made - ✅ Nothing needs to be reverted locally Since this task only involved filing an issue, there were no code changes, no commits, and no PR to push/create.
c
I seem to see signs of other npm packages compromised. Maybe we could do it on npm ecosystem
nod 1
d
great find with uv's
exclude-newer-package
right axios was an npm package that was compromised recently
the llamantino post referenced in the OP has an npm attribute we can use https://docs.npmjs.com/cli/v11/commands/npm-install/#min-release-age
c
I’m brain-frozen right now, but the agent also made an issue on the OH repo to remind us of the remaining - please tackle it if you’d like, or we can when we get to it
d
I believe this is the issue created? https://github.com/OpenHands/OpenHands/issues/13697 [Feature]: Add minimum dependency age guardrails for Python and npm
if so, I can work on it
c
Yes Thank you ❤️
d
np
thanks for putting together a foundation for this work!
looks like someone already created a PR to review 😄
q
I'm in favor of this. This became a hot topic in lite of the recent litellm exploit. I've heard different things on the ideal interval, even as low as a day, but I'd good with running with this approach on all our major repos and see how it goes.
nod 1
👍 1