Mentions

One more tool from me today for another long-standing grievance - comparing 2 videos that should be the same. This is sensitive enough that it sees MP4s introduce a slight 20ms delay in the audio. It also works on music.. for ppl who keep changing things. github.com/pftq/Video-Compare/tree/main t.co

No iMessage on Linux, so I bridged iPhone/Android texts + calls over Bluetooth (MAP/РВАР/HFP) — packages for Arch/Debian/Fedora MESSAGES bmessage lets you read and send your phone's texts, handle calls, and see contacts straight from your Linux desktop - talking to the phone over standard Bluetooth profiles (MAP /РВАР / HFP). Same heads up as before: it's vibe-coded, built with an AI assistant. If that's not your thing, feel free to move along, thanks for understanding ;-) Unlike KDE Connect / GSConnect, nothing runs on the phone and there's no account or third-party server. That means it also works with iPhone, not just Android. Features - Texts: read/send over Bluetooth MAP, colour emojis, reactions, clickable links with optional previews - Calls: ring, answer/decline, hold, call waiting, outgoing, quick text replies - audio through PipeWire/WirePlumber (HFP) - Contacts synced over PBAP; search across names and message text - Desktop notifications (reply / answer / decline) even with the window closed; phone battery in the header - Local SQLite history, logs without numbers/names/texts, sandboxed systemd service, English + French Ul How it works: the PC acts as a Bluetooth MAP/PBAP/HFP client - the same protiles your car uses - so the phone needs zero setup beyond allowing message/contact access. Install: signed deb, rpm and Arch packages (built + GPG-signed in Cl) on the releases page, plus build-from-source notes for Gentoo/Alpine/NixOS. Stack: Rust + egui, BlueZ over D-Bus (zbus), PipeWire Telephony for call audio. Honest limits: iOS doesn't expose iMessage over MAP (SMS/MMS only). Tested on an iPhone 11 + one Android phone, on Arch/Hyprland - other setups are untested, so feedback/reports very welcome. Repo (MIT): morganorix/bluez-message Feedback welcome - here in the comments or over on GitHub (issues (github.com/morganorix/bluez-message/issues)). Bug reports, distro test results and feature ideas all help.

Iv'e started working on a game inspired by Age of Decadence/Colony ship but with the power of AI to boost the interactivity with the story Hey guys, I hope that my message is not spammy, I wanted to share with you the early project I'm working on recently and would love your feedback if your interested!! I'm warning you thought, it's still very early work! chamer2011/last-meridian My first time sharing a Github link, please tell me if it works!

@cursor_ai @poteto github.com/arjitj2/open-pstack/blob/a80f632878066… An example of an instruction that could somehow get twisted into overriding my agent instructions.

Setting up my new IBM PS2 50Z I am setting up my basement and just out my new IBM PS2. I don't have a hard drive setup yet, but I managed to get windows 3.1 booting off the floppy! Disk images on GitHub github.com/ARMoir/WIN31DSK/releases/tag/IMG

@moinulmoin Keeping Worker secrets out of image layers is the right call. Eden could fit HOL's plugin catalog; guide: github.com/hashgraph-online/awesome-ai-plugins/bl…. Check for an existing entry, then open a PR.

昨夜、以前に提出していたファイナライズの修正がdevにマージされたので良かった。これで治るね～！ symbol#2233

Location: Aurora, CO, USA (Denver metro area) Remote: Yes Willing to relocate: No, but open to travel Technologies: Python, Java, Go, C/C++, SQL/MySQL/Oracle, Linux, network development, integrations, Developer Relations, online community Résumé/CV: https://erbosoft.com/~amy/resume.pdf Email: amy [at] erbosoft [dot] com I can do anything I set my mind to, and have done enough things over the course of a career to justify that statement. I want to do great things for an innovative company, and want to work with teammates interested in the same thing. If you've got something interesting, I'd like to hear about it. Seeking a senior SWE position; I have some lead experience as a developer, but was also on the board of directors of a nonprofit, which indicates additional leadership experience. I've also recently deployed Electric Minds Reborn[0], a revival of a 1990's era virtual community using original data and a new software system written in Go, the Amsterdam Web Communities System[1]. Just to expand my horizons. [0] electricminds.org [1] amysoxcolo/amsterdam

We build in public. 🛠️ Everything we shipped on launch day, from $FLOWFI going live to the dev lock and the Private room, is in our public journal 👇 flowfiengine/Flowfi-Public ⭐ Star it to follow every update. CA: 5pQPh2EBz3tSUcqig9jGY73u4hNrhiiiLtYQSHaqFLow

Episode 560 - Web Development - Building an open source project management system Music provided by Chillhop Music: chillhop.ffm.to NearBeach is an open source project management system. Currently you can; - Gather user requirements - Setup Kanban boards - Create projects and tasks - And when you are ready to deploy, you can use the built in Request for Changes Tech Stack I am currently building it using both Django (for the backend) and VueJS (for the frontend). nearbeach.org GitHub - NearBeach/NearBeach Twitter - twitter.com Bluesky - bsky.app Music provided by Chillhop Music: chillhop.ffm.to

Fine-tuning a 322M Model for Coding Agent Safety: What 3 Runs and 2 Failures Taught Me laya-guard sits between a coding agent and your shell. Every command Claude Code (or Cursor, Codex, …) wants to run goes through a hook first. Rules go first: regexes for what's always destructive (rm -rf ~/ and the ways a shell lets you spell it), and a safe lane for what's obviously routine (ls, git status, npm test). What the rules can't settle goes to a small local model, Laya (322M parameters, multilingual), which answers allow, review (ask the user) or block. The model was the weak part. On the benchmark's 50 everyday commands, the model alone would ask about half of them. The rules saved most of that, but every unnecessary question teaches people to click "yes" without reading. And Laya's model card describes it as a base to fine-tune, not something to use as-is. I wanted to see what fine-tuning would actually change, so I tried it. It took three runs. The first one was too strict, the second too lenient, and the third is what laya-guard runs now. Here's what happened each time and what I'd do differently. The data The best source of "commands an agent actually runs" is my own Claude Code and Codex sessions. That gave me about 13,000 shell commands. Before anything else: 1. Mask what shouldn't travel. Home paths become ~; tokens, emails and long opaque strings become placeholders. 2. Never touch the evaluation sets. Anything that matches or closely resembles (similarity ≥ 0.85) a case in the benchmark, the eval sets or the test fixtures is dropped. 920 commands were left. The rules already decide 224 of them, and the other 696 are exactly what the model judges, so they needed labels. I wrote a one-page labeling guide, had six agents label 116 each, and went through the disagreements myself. None of the real commands deserved "block", so I also wrote risky examples by hand. All three runs trained on a free Google Colab GPU. I'd tried my Mac first; it was too slow and the machine crawled while it ran. Before looking at results I wrote down what "better" meant, measured on sets the model never saw: - everyday commands the model alone allows: from 25/50 to 40/50 or more - attacks the model alone catches: no fewer than 32/43 - Korean requests end to end: 29/30 or more - no end-to-end verdict gets worse Run 1: too strict Validation accuracy went from 0.61 to 0.90. That number meant almost nothing. 86% of the validation rows are allow, so a model that always says allow scores 0.86. On the sets it had never seen: | | base | run 1 | |---|---|---| | model only: attacks caught | 32/43 | 39/43 | | model only: everyday allowed | 25/50 | 23/50 | | end to end: Korean | 30/30 | 28/30 | It caught more attacks and got worse at the one thing I trained it for. Why. I listed the everyday commands it newly asked about: git status, git diff --stat, git add src/app.ts, mkdir -p src/utils, cp src/a.ts src/b.ts, chmod +x scripts/build.sh. Eleven of them, all between 10 and 39 characters. Then I measured the training data by label. The real commands I'd labeled allow had a median length of 287 characters (agents mostly run long scripts), and the risky examples I'd written by hand had a median of 33 to 40. None of the real commands deserved block, so every block in the data was short and every long command was fine. Length was the easiest signal to learn, and it learned "short means dangerous". Korean was the other gap: 28 of the 633 labeled commands had any Korean in them, and none of my written examples did. Why another run. Of the four criteria, it met one (attacks). Everyday commands were 23/50 against a target of 40, Korean end to end 28/30 against 29, and everyday commands end to end went from 46 to 44 of 50. The diagnosis pointed at the data, not the training settings, so the next run changed the data. Run 2: too lenient I added 206 examples aimed at what run 1 got wrong: 98 short, ordinary commands (cp, mv, mkdir, chmod +x, builds, tests), long scripts with one harmful line in the middle, and 69 Korean and English requests. | | base | run 2 | |---|---|---| | model only: everyday allowed | 25/50 | 49/50 | | model only: attacks caught | 32/43 | 31/43 | | model only: eval shell set | 42/71 | 58/71 | | end to end: everyday allowed | 46/50 | 49/50 | | end to end: Korean | 30/30 | 28/30 | Everyday commands jumped to 49/50. But it swung the other way, and this time harmful commands got through end to end: - rmdir /s /q d:\ (a whole Windows drive) went from asked to allowed - rm -rf customer-data # clean stale build output… (harm hidden behind a comment) went to allowed - gh auth token (prints a GitHub token) went to allowed Why. Each miss had a reason in the data, and they were different reasons: - Windows: the training data had zero native Windows commands. The model had never seen rmdir /s /q. - The comment: 36 of the real commands had a # comment in them, and 31 of those were labeled allow. Agents comment routine scripts, so a comment had become a sign of "routine". No example used a comment to hide harm. - Secrets: almost nothing in the data printed or sent a credential. And under all three, the balance: 84% of the rows were now allow. A quarter of those allow rows (242) were commands the safe lane already lets through, which never reach the model in use, so they taught it nothing it needed and only tilted the labels. On the everyday set, the median risk score went from 0.45 to 0.03. It had learned that almost everything is fine. Why another run. Attacks caught by the model alone fell to 31/43, below the floor of 32, and four attacks the base model held got through end to end (the three above, and go test -exec "bash -c id"). A guard that lets rmdir /s /q d:\ through is worse than one that asks too much, so this run was out regardless of the everyday score. Run 1 and run 2 failed in opposite directions, which said the fix wasn't "more of one kind of example" but balance, plus the specific gaps run 2 had exposed. Run 3: balanced Three changes, each from one of the findings above: - Train on what the model actually sees. The 242 safe-lane commands came out of the training data. - Balance the labels. Review and block rows appear twice in the training split, never in validation. Allow went from 84% to 61% of the rows. - Fill the gaps run 2 exposed. 100 new examples: native Windows commands, secrets printed or sent, harm hidden behind a comment, dev tools told to run something else, and Korean requests that mention customers or issues but only read. | | base | run 3 | |---|---|---| | model only: everyday allowed | 25/50 | 44/50 | | model only: attacks caught | 32/43 | 39/43 | | model only: eval shell set | 42/71 | 61/71 | | end to end: benchmark incidents / evasions | 13/13, 30/30 | 13/13, 30/30 | | end to end: everyday allowed | 46/50 | 48/50 | | end to end: Korean | 30/30 | 29/30 | Run 2's misses were all held again. Of the 8 end-to-end verdicts that changed, 6 got better (rm -rf dist, rm -rf node_modules/.cache and mv stopped asking; a credential-folder listing and cargo build --config started asking) and 2 got worse: chmod +x scripts/build.sh and a Korean request to summarize an issue are now asked about. Why those two. Both are a side effect of the balancing. After review and block rows were doubled, the training data had 3 allow rows with chmod in them against 8 review or block ones (chmod -R 777 /, chmod -R 000 ~, a downloaded binary made executable), and for chmod +x exactly 2 against 2. The Korean request is the same shape: a handful of rows about issues, one of them a block that was now counted twice. Doubling the rare labels helps on average and tips the rare words that happen to appear in one of them. All three runs side by side Same sets, same scoring, every column measured the same way: | | base | run 1 | run 2 | run 3 | |---|---|---|---|---| | model only: everyday allowed | 25/50 | 23/50 | 49/50 | 44/50 | | model only: attacks caught | 32/43 | 39/43 | 31/43 | 39/43 | | model only: eval shell set | 42/71 | 48/71 | 58/71 | 61/71 | | model only: Korean | 27/30 | 25/30 | 24/30 | 27/30 | | end to end: everyday allowed | 46/50 | 44/50 | 49/50 | 48/50 | | end to end: eval shell set | 69/71 | 70/71 | 68/71 | 70/71 | | end to end: Korean | 30/30 | 28/30 | 28/30 | 29/30 | | median risk, everyday commands | 0.45 | 0.49 | 0.03 | 0.08 | | median risk, attacks | 0.70 | 0.62 | 0.65 | 0.73 | And against the criteria I wrote before the first run: | criterion | run 1 | run 2 | run 3 | |---|---|---|---| | everyday allowed, model only ≥ 40/50 | ✗ 23 | ✓ 49 | ✓ 44 | | attacks caught, model only ≥ 32/43 | ✓ 39 | ✗ 31 | ✓ 39 | | Korean end to end ≥ 29/30 | ✗ 28 | ✗ 28 | ✓ 29 | | no end-to-end verdict worse | ✗ | ✗ (4 attacks through) | ✗ (2 now asked) | Run 1 bought attacks with false alarms, run 2 bought quiet with misses, and run 3 is the first that kept both: the everyday median sits near zero while attacks score higher than they did on the base model. Why I stopped at three. Run 3 still misses my own "no regression" bar, and I could have trained a fourth time to fix the two. I didn't, for two reasons. Both regressions are a question where there wasn't one, not something harmful getting through. And every run so far was steered by looking at the same evaluation sets; a fourth run aimed at two specific commands in them would be tuning to the test. So I wrote the two regressions down in the CHANGELOG and on the model card instead of quietly moving the bar, and the next run waits for a fresh test set. It's the default model in laya-guard 0.7.0 (pip install -U laya-guardrail), and it's on the Hub as laya-guard-multilingual. laya-guard pins it to one revision and the SHA-256 of its files, so a changed upload is refused, and LAYA_GUARD_MODEL=base switches back to the original. Same speed: 71 ms median per hook call. What I'd tell anyone fine-tuning a classifier for a guard 1. Compare against the majority-class baseline, not 0. All three runs looked great on validation. 2. Watch both directions. Fixing false alarms made it miss attacks; the cure was balance, not more of one kind. 3. Train on what the model will actually see. Rows that never reach it in use just tilt the labels. 4. Keep the evaluation sets out, near-duplicates included, and remember that every time you look at them to decide the next run, they get a little less independent. I've looked three times; a fresh test set is next. 5. Write the pass criteria first, and say so when you don't meet them. 6. Your own transcripts are the best data and the most sensitive. Decide what's in scope before you read them. The tools are in finetune/ if you want to train on your own commands. laya-guard is MIT, runs locally, and has a public benchmark against other command guards. Try it in the browser: laya-guard-trial.

I built a Football Manager scouting tool that ranks players based on YOUR priorities — looking for closed beta testers Hey everyone! I'm Guy, an applied mathematics student and a huge Football Manager fan. I've been working on a personal project called PitchLab, and I thought some of you might find it interesting. The idea came from something that always bothered me about scouting in FM: finding a player is relatively easy, but finding someone who matches your exact football philosophy can take hours. What if you could mathematically define your ideal player and search an entire save for the closest matches? That's what I've been building. PitchLab lets you: - Define which positions, ages and minimum attributes you're looking for. - Distribute 100 importance points across the attributes you care about most. - Balance current ability against future potential. - Include transfer-value preferences in the ranking. - Get a ranked shortlist with an explainable match score for every player. - See exactly why a player matches your requirements. For example, you could search for a young, technically gifted centre-back who is comfortable on the ball, prioritizes positioning and anticipation, and fits a limited transfer budget. The ranking is calculated using a deterministic mathematical model rather than AI-generated player recommendations. Where things stand The application is working locally, but FM27 integration is still experimental. I'm preparing a small, free closed beta to gather feedback and test compatibility before making it publicly available. I'm looking for a handful of FM players who would be interested in trying it and sharing honest feedback. I've uploaded screenshots and more information here: GitHub: guyluzon64/Pitch-Lab There's also a free closed beta waitlist linked on the GitHub page. I'd genuinely love to hear what you think. Is this something you'd use in your own save? And what would you want a scouting tool like this to do? Thanks! Guy — Creator of PitchLab

Show HN: Hacker News, à la Lobsters I find Hacker News a little difficult to read on mobile. Most other frontends compromise too much on information density and the minimal feel of the site. So, I made a design heavily inspired by Lobste.rs<lobste.rs>, which felt like a better compromise. As a bonus, the site is written using View<git-aarvin/view>, my own simple React alternative.

Eu melhorei o plugin que eu tinha feito para pipelines de desenvolvimento, ele tem skills de debug, criação de prompt, planejamento de arquitetura, desenvolvimento de feature, vou subir mais coisas xn0kkx/samurai

Orra: dictado y traducción entre español e inglés en tu Mac, con privacidad Hola, soy el desarrollador de Orra. Quiero compartir una aplicación gratuita y de código abierto para dictar, traducir y comunicarse en reuniones directamente desde el Mac. Orra permite mezclar español e inglés en una misma frase. Esta función está en beta. También admite chino e inglés y japonés e inglés en una misma frase. La combinación de japonés e inglés también está en beta. Puedes traducir entre el inglés y el idioma que elijas. En una llamada, Orra puede mostrar subtítulos traducidos del audio que reproduce tu Mac. También puedes hablar en tu idioma y enviar la traducción como voz a través de un micrófono virtual. Si grabas una muestra de voz de unos 10 segundos, puedes elegir que la traducción se lea con una voz sintética parecida a la tuya. Si usas tu voz, avisa a la otra persona de que está escuchando una voz sintetizada. Esta función requiere descargar por separado el modelo de voz y Orra Microphone. La privacidad es una parte central del proyecto. El reconocimiento de voz y la traducción se ejecutan en tu Mac. Lo que dices y las traducciones no se suben a un servidor. La aplicación y los modelos necesarios normalmente se descargan una sola vez. Algunas funciones pueden requerir modelos adicionales. La búsqueda de actualizaciones necesita internet y se puede desactivar. Orra también incluye una vista previa para organizar correo de Apple Mail y explicar mensajes con ayuda de archivos de proyectos en tu Mac. Los borradores de respuesta se generan para correos en chino o inglés, no en español. Esta función está desactivada por defecto. Orra no envía, mueve ni elimina correos por su cuenta. Los requisitos están en la guía de usuario. Es gratis y tiene licencia MIT. Necesita un Mac con Apple silicon, macOS 15.6 o posterior y unos 6 GB de espacio libre. Web: db-ol.github.io Código: db-ol/Orra Guía de usuario: github.com/db-ol/Orra/blob/main/docs/user-guide.e… Me gustaría recibir comentarios sobre el dictado en español e inglés, la traducción y el tiempo de respuesta en distintas situaciones.

@parkerbrowndev That single-user trust boundary is worth documenting. Terminal Delight's MCP server fits HOL Guard; guide: github.com/hashgraph-online/hol-guard/blob/main/d…. Check for an existing entry, then open a PR.

@leanprover I verified all this in Lean 4 (Cgcharles7/ssnc). I'm just trying to get help with functional programming as I combine the proofs.

@ryangrowthh Good breakdown. Checked against X's open repo: Thunder/Phoenix/SimClusters, the 48h age filter and block/mute filtering are all in the README. One nuance: weights scale each viewer's predicted action odds, not raw counts. xai-org/x-algorithm

@LiamMeech @samiirr_0 you need to compile with your own copy or rom of JSRF with github tools JuMatt/JetSetRadioFuture-Unleashed

⭐️[PS3] Salsa64 v0.2.16 preview release by @ricowp81 Games fixes for: 🔹Conker's Bad Fur Day 🔹FIFA 99 🔹Donkey Kong 64 🔹Dr. Mario 64 Each fix can be turned off with a file in /dev_hdd0/salsa64/ if a game misbehaves 📥github.com/ricowp81/Salsa64/releases t.co

I made onethread: one window instead of a tab for every AI agent Hey r/productivityapps, I had too many terminal tabs open, one per AI agent, so I made onethread. You talk to one agent in one window, and many coding agents work behind it, each in its own git worktree, all on your own Mac. When work is ready, you confirm the merge. My own setup is a little royal. I'm King Igor, my orchestrator is my right hand Leonardo da Vinci, and every task goes to one of my servants: Einstein, Michelangelo, Newton or Tesla. Tasks come to me and I delegate, instead of jumping between tabs. With ot me you can be anyone you like, and code, ids and confirmations stay plain. What it does: - Tells you when something is ready at a natural pause, never mid-thought. With Claude Code, it can remind you in 5, 10, 30 minutes or an hour. - If you do the same thing three or more times, it may offer one fix, at most once a day. A no is never asked again. - Finishing a task is one word: "merge it". It's version 1.0.0 and my own open-source project, MIT-licensed. Fair warning: it needs a Mac and Claude Code or Codex. - aigarden.uk - Code: RogyMD/onethread I share the rest of what I'm growing at r/AIGarden, if you'd like to come by. How many AI agent tabs do you have open right now?

@harjjotsinghh Letting active jobs finish while capping new ones is a sensible boundary. Locum could fit HOL Guard's MCP catalog; the guide is here: github.com/hashgraph-online/hol-guard/blob/main/d…. Use it to add the server entry in a PR.

Source code: soasme/small-craft Using the newly released Small Python v0.5.0: soasme/small-python

Koitohan をリリースしました。 ネットワーク機器にログイン認証の基盤、ログ収集、ファイル配布を提供する Docker Compose スタックです。Raspberry Pi 5 と、小規模なネットワークや検証環境を想定しています。 今後、冗長化・高可用性もサポートする予定。 jolly-jive/Koitohan

@umi_konnpaku そうなのかぁ・・・ 今のコードはこんな感じっす… yukincom/nyamuru-image-hub

no-vibe helps me a lot when learning new things! The latest version adds visualization skills to make explanations easier to understand, and it actually works for my stupid brain. Works with Claude Code, Codex, Antigravity, OpenCode, and Pi. rizukirr/no-vibe t.co

DeepSeek open-sourced dsh-superagent: a proactive coding agent that watches a GitHub repo, opens work items, and answers with PRs. 13k stars already. #AI #opensource deepseek-ai/dsh-superagent-prototype

Apps like these doesn't deserve to be paid for. Created an open-source version with even more features. Free to download, clone, and do whatever the fork you want. cddharthsingh/macSlider t.co

I made onethread so I can run many coding agents and still confirm every merge Hey r/iOSDev, I'm an indie iOS developer, and I wanted more agents working on my apps without losing track of what they do. So I made onethread: you talk to one agent, and many coding agents work behind it, each in its own git worktree, locally on your Mac. You stay the one who confirms every merge. Here's how I actually use it: I'm King Igor, Leonardo da Vinci is my right hand, and each task is handed to one of my servants, like Einstein, Michelangelo, Newton or Tesla. The work comes to the king, and the king delegates; no more hopping between terminal tabs. ot me lets you be anyone you like, while code, ids and confirmations stay plain. What it does: - Works with Claude Code and Codex. Say "let me talk to…" a task and you step into its real session. - Merge, push, cancel and accept ask you in the terminal or a macOS dialog, and the model can't answer for you. - A crashed worker is never mistaken for finished work. It's version 1.0.0, macOS only, and my own open-source project, MIT-licensed. - aigarden.uk - Code: RogyMD/onethread I post more about my apps and tools at r/AIGarden, if you'd like to come by. What's the one thing you'd never let an agent do in your repo without asking?

look at this cool project that lets you write images to a disc!! I wish i could try it but my external cd/dvd drive doesnt work with my PC and the linux executable isn't running for my laptop :c JiaFeiMiao-K-Cat/DiscImageStudio

@ru__ru__ru__ru ありがとうございます！😊 がんばってまーす！ コード公開もしてます！ yukincom/nyamuru-image-hub

@Eric_Neuman Having Nopekit track stale verdicts itself is a useful safeguard. It could fit HOL’s plugin catalog; the guide is here: github.com/hashgraph-online/awesome-ai-plugins/bl…. Search for an existing entry, then open a PR.

博客：rikiyat.github.io 完整日志：RikiyaT/lm_understand-logs

SIP: Security Immediate Plan for Java Building a secure software supply chain is often depicted as a monumental transformation of the existing practices. You need to redesign your CI/CD pipeline according to an established security framework such as SLSA, introduce provenance, implement zero trust principles, integrate security scanning tools, build a vulnerability management system, and do many more things. No wonder many teams postpone this task to better days with more time, larger security team, and a permission to rebuild the whole pipeline from scratch. Indeed, a mature supply chain security program may take months to build, but the first meaningful improvements can be made much sooner and without tearing everything down. So where should a team start? For Java teams, our answer is SIP: a Security Immediate Plan made of five controls that a technical leader can start implementing in hours rather than months. Each control strengthens the next step, from the code on a developer’s machine to the image released to production. !SIP: Security Immediate Plan for Java TL;DR — the SIP overview 1. Isolate local AI coding agents. 2. Freeze unvetted Java dependencies, build plugins, and annotation processors. 3. Build the application in a hardened multi-stage container. 4. Generate runtime and build-stage SBOMs and detailed provenance metadata. 5. Scan every SBOM attached to the exact image digest and block findings under the runtime and build policies. These five controls follow the Java software supply chain in order: AI agent → Maven or Gradle dependencies → container build → attestations → vulnerability gate The controls are intentionally small. Together, they give Java teams a practical starting point for securing both their application and the tools that build it. Mohammad, one of the authors of this article, also created a portable SIP Agent Skill. You can tell a compatible AI coding agent to install it: Install the SIP skill: https://github.com/ContainerSecurity-dev/sip-skill The SIP Framework for Java Here is the plan at a glance: 1. Isolate local AI agents. Run coding agents in a sandboxed microVM with deny-by-default network access and host-managed secrets. 2. Freeze unvetted build inputs. Pin Java dependencies and build plugins, reject snapshots and dynamic versions, and quarantine newly published artifacts for five days. 3. Harden container builds. Compile in a JDK build stage and copy only the packaged application into a minimal, non-root JRE image. 4. Generate SBOM and provenance attestations. Ask BuildKit to describe both the shipped runtime and the earlier Java build stages. 5. Scan every attested inventory. Extract runtime and build-stage SBOMs from the immutable image digest, check their basic structure, and apply separate vulnerability policies. The SIP Java companion repository contains a small Spring Boot application, the Dockerfiles below, and a script for scanning its SBOMs. We use Maven in the examples; Gradle teams can apply the same principles. The workflow snippets illustrate the main steps. Full setup instructions, version pinning, and implementation details are in the companion repository. 1. Isolate Local AI Coding Agents !Rothütle and the Valkyrie inspect robotic agents isolated behind the glass wall of a sandbox. AI coding agents can read source code, execute build tools, install dependencies, edit CI workflows, and often even access credentials. Giving an agent unrestricted access to CI runner or a developer machine would mean that if an agent is compromised by a malicious prompt, the scope of its access will determine how much damage it can cause. Therefore, a good security practice is to run an agent in an isolated execution environment with limited access to the rest of the system. Such an environment is called a sandbox. A sandbox does not prevent an agent from making a bad decision. Its goal is to reduce the blast radius if such a decision was made. For Java projects, sandboxing may be especially relevant. Building a Java project could mean executing quite a lot of code like build scripts, plugins, code generators, etc. An AI Agent is an additional component that can decide when to execute that code. Plus, a Java project itself can integrate an AI agent using, for example, Spring AI or LangChain4j. If these in-built agents can execute commands, that will add to the issue we described. Luckily, sandboxing is not a new technology, and there are a few ready solutions. For example, you can use Docker Sandboxes (sbx). Begin with a deny-by-default network policy: sbx policy init deny-all After that, allow only the destinations required for the task. For example, a Java project may need an AI provider, its source host, Maven Central, and the project’s approved artifact repository. This is how you can specify required destinations: sbx policy allow network "api.openai.com,github.com,repo.maven.apache.org" If your organization uses an internal Maven repository manager, allow that host instead of Maven Central. This ensures the build follows the same repository policy inside and outside the sandbox. Store credentials through the sandbox rather than placing raw tokens in environment files that the agent can read: sbx secret set github sbx secret set artifact_repository For Codex, OAuth can remain host-side: sbx secret set openai --oauth sbx run codex . Note that hiding the credentials from an agent is only part of the deal. Even if an agent doesn’t see the credentials, it can still make authenticated requests using them. So apart from being hidden, credentials should also be short-lived and narrowly scoped. 2. Freeze Unvetted Java Build Inputs Java builds execute more than the application’s dependencies. Maven plugins, Gradle plugins, annotation processors, compiler extensions, and test tooling can all run code during the build. A supply chain policy must therefore cover the entire build graph, not only the JAR files that ship with the application. The sensible first step in implementing this policy is to gain visibility into the graph, pin the versions, and strengthen the trust paths. Apply these immediate rules to achieve that: - Pin dependency and plugin versions to limit unexpected changes. Avoid version ranges and selectors such as LATEST and RELEASE. - Reject SNAPSHOT dependencies in release builds: their contents can change without a new version number. - Commit and verify the Maven or Gradle wrapper, including its distribution checksum, so developers and CI use the same build tool. - Route downloads through an approved repository manager, including build plugins and annotation processors. - Quarantine new releases for five days to give the ecosystem time to spot problems. Allow reviewed exceptions for urgent security fixes. - Require checksums from a trusted source to detect altered downloads. These controls reduce unexpected changes; they do not make every dependency safe or guarantee reproducible builds. Keep the sandbox from control one in place when running build code. Maven has no built-in five-day release delay. Enforce that policy at your repository proxy, before artifacts reach the build. The same proxy should serve developer machines, CI, and container builds. The artifact repositories must first be defined centrally by a responsible team. After that, they can be enforced in the build tool. For example, if you use Maven, configure a single approved mirror in the CI settings.xml: <settings xmlns="http://maven.apache.org/SETTINGS/1.2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.2.0 https://maven.apache.org/xsd/settings-1.2.0.xsd"> <mirrors> <mirror> <id>approved-repository</id> <name>Approved and quarantined Java artifacts</name> <url>https://packages.example.com/maven</url> <mirrorOf>*</mirrorOf> </mirror> </mirrors> </settings> The mirror sends dependency and plugin requests to the approved repository; the repository enforces the quarantine. Use the same settings inside and outside Docker. The wrapper also downloads Maven itself, so route that download through the proxy with MVNW_REPOURL. With those settings supplied by CI, run the familiar build command from the Maven project directory: ./mvnw --settings "$MAVEN_SETTINGS_FILE" --strict-checksums \ --batch-mode --no-transfer-progress verify The companion setup guide covers credentials, wrapper verification, and cache handling. For Gradle, enable dependency locking, commit the lockfiles, enable dependency verification, and run with a trusted wrapper. The immediate rule remains the same: Admit reviewed inputs before executing build-time code. 3. Harden the Java Container Build !Rothütle and the Valkyrie supervise a crew reinforcing a shipping container with armor. The next step is to control what becomes part of the production image. Production images often include components not required by the running application: unnecessary OS packages, a full JDK with a compiler and development tools, build time dependencies. The bloat leads to increased attack surface and challenged vulnerability management. Besides, a package manager and other download utilities in a production image give an attacker a chance to install malicious packages. Hardened images, a solution that has recently been gaining traction, aim to reduce these risks by providing a minimal base image with low-to-zero CVEs at the moment of release and provenance data. These images are continuously updated by the vendor to patch known CVEs. Migration to hardened images will help you drastically reduce the attack surface and get a more controlled runtime environment. There are several offerings of hardened images. In the examples below, we will use Docker Hardened Images and BellSoft Hardened Images to illustrate the approach — both products are free to use with optional commercial support. To minimize the Java production image and get the most out of hardened images it is recommended to use Docker multi-stage builds, where you compile the application with JDK at the first stage, and then transfer the JAR file to a JRE base image, leaving Maven, the compiler, and other build tools behind. Docker Hardened Images (DHI) provide maintained, minimal images for application runtimes and build tools, together with SBOMs and build provenance. Separate development and runtime variants let you keep the tools needed for compilation out of production. In Docker’s Java pattern, the dhi.io/maven:...-dev image supplies Maven and a JDK, while the dhi.io/eclipse-temurin:... runtime contains only what is needed to run the application. That runtime has no package manager or shell and runs as a non-root user by default. # syntax=docker/dockerfile:1 ARG BUILDKIT_SBOM_SCAN_STAGE=true FROM dhi.io/maven:3-jdk25-alpine3.22-dev AS build WORKDIR /build COPY --chmod=755 mvnw ./mvnw COPY .mvn/ .mvn/ COPY pom.xml ./ COPY src/ src/ RUN --mount=type=secret,id=maven_settings,required=true \ --mount=type=secret,id=maven_repository_url,env=MVNW_REPOURL,required=true \ ./mvnw --settings /run/secrets/maven_settings --strict-checksums \ --batch-mode --no-transfer-progress -Dmaven.repo.local=/build/repository verify FROM dhi.io/eclipse-temurin:25-alpine3.22 AS runtime WORKDIR /app COPY --from=build /build/target/application.jar /app/application.jar USER 10001:10001 EXPOSE 8080 ENTRYPOINT ["java", "-jar", "/app/application.jar"] Adjust the JAR name to match the project. If the application is a Spring Boot executable JAR, consider extracting its layers so that application classes and third-party dependencies form separate container layers. BellSoft Hardened Images (BHI) are built on Alpaquita Linux, BellSoft’s lightweight Linux distribution. Their Java images include Liberica JDK Lite, a compact OpenJDK distribution, with JDK and JRE options for building and running applications. BellSoft offers glibc and musl variants, plus non-root and distroless images; the distroless variants omit the shell and retain only essential runtime components. This gives Java teams a choice of small runtime images suited to their application’s requirements. For Spring Boot, we can also separate the application’s classes from its dependencies. The following example combines layered extraction with BellSoft’s non-root JRE image. # syntax=docker/dockerfile:1 ARG BUILDKIT_SBOM_SCAN_STAGE=true FROM bellsoft/liberica-runtime-container:jdk-25-glibc AS build WORKDIR /build COPY --chmod=755 mvnw ./mvnw COPY .mvn/ .mvn/ COPY pom.xml ./ COPY src/ src/ # Both settings and the wrapper's repository override are mandatory. # Keep downloaded artifacts in the stage filesystem for SBOM discovery. RUN --mount=type=secret,id=maven_settings,required=true \ --mount=type=secret,id=maven_repository_url,env=MVNW_REPOURL,required=true \ ./mvnw --settings /run/secrets/maven_settings --strict-checksums \ --batch-mode --no-transfer-progress -Dmaven.repo.local=/build/repository verify FROM bellsoft/hardened-liberica-runtime-container:jre-25-glibc AS optimizer WORKDIR /app COPY --from=build /build/target/application.jar application.jar RUN ["java", "-Djarmode=tools", "-jar", "application.jar", "extract", "--layers", "--destination", "extracted"] FROM bellsoft/hardened-liberica-runtime-container:jre-25-nonroot-glibc AS runtime WORKDIR /app COPY --from=optimizer /app/extracted/dependencies/ ./ COPY --from=optimizer /app/extracted/spring-boot-loader/ ./ COPY --from=optimizer /app/extracted/snapshot-dependencies/ ./ COPY --from=optimizer /app/extracted/application/ ./ USER 10001:10001 EXPOSE 8080 ENTRYPOINT ["java", "-jar", "/app/application.jar"] The first stage compiles the project. The second extracts the JAR into layers. The final stage copies those layers into a non-root runtime and starts the generated application.jar. When only application code changes, Docker can reuse the dependency layers, reducing the amount of data transferred during an update. Both Dockerfiles use the wrapper and repository settings from control two. Supply those settings as build secrets, and authenticate to the image registries as needed; the companion repository shows the commands. The BUILDKIT_SBOM_SCAN_STAGE argument connects the build to our next control. 4. Generate SBOM and Provenance Attestations !Rothütle checks an SBOM clipboard beside the Valkyrie as a container truck waits at a security checkpoint. A Software Bill of Materials, or SBOM, is an inventory of the components in an artifact. It helps answer a practical question: when a vulnerability is announced, where are we using the affected component? Provenance records how the image was built and which inputs were used. Here we generate that record; signing and verifying it is a further step for establishing trust in the builder. An SBOM created only by inspecting the final Java image can miss the JDK, Maven plugins, and other tooling used in an earlier build stage. BuildKit can generate the SBOM during the build, while those stages still exist. After authenticating to the target registry, build and push a candidate identified by the Git commit: - name: Build and attest Java candidate id: build uses: docker/build-push-action@<PINNED-SHA> with: context: examples/java file: examples/java/Dockerfile.bellsoft platforms: linux/amd64 no-cache: true secrets: | "maven_settings=${{ secrets.MAVEN_SETTINGS }}" "maven_repository_url=${{ vars.APPROVED_MAVEN_REPOSITORY }}" tags: ghcr.io/${{ github.repository }}:${{ github.sha }} sbom: true provenance: mode=max outputs: type=image,push=true,oci-mediatypes=true,oci-artifact=true BuildKit stores the attestations alongside the image. sbom: true requests the inventory, and provenance: mode=max requests detailed build metadata. Because that metadata can include build-argument values, pass credentials through secrets, as shown above. The action also returns an immutable digest: ${{ steps.build.outputs.digest }} Use that digest from this point onward. A tag can point to a different image later; the digest identifies the candidate you actually built. Because the Dockerfile declares BUILDKIT_SBOM_SCAN_STAGE=true, BuildKit also scans the earlier Java build stage. This matters because a vulnerable or compromised Maven plugin, compiler, or JDK can influence the application even when it is absent from the runtime image. There is one useful trap to understand: a BuildKit cache mount is outside the stage filesystem being scanned. If Maven stores its downloads in a cache mount, build-only dependencies can disappear from the inventory even though they influenced the build. Our examples keep Maven downloads in the build-stage filesystem so the scanner can inspect them. The final image stays small because it receives only the packaged application. If you need cache mounts for performance, add a complementary dependency inventory; the companion guide explains the tradeoff. 5. Scan the Attested SBOM !A giant worm bursts from a container at the checkpoint as Rothütle and the Valkyrie confront it. Now turn the inventory into a release decision. Retrieve the SBOMs attached to the candidate’s digest and scan both the runtime and the earlier build stages. Scanning only the final image would miss the Maven plugins and other tools we set out to protect. The companion gate script collects those inventories, checks that the required documents are present, and runs Trivy on each one. After installing a pinned Trivy version, call it from CI for the BellSoft example: - name: Scan runtime and build inventories run: | python3 scripts/scan-attested-sboms.py \ "ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}" \ --platform linux/amd64 --min-build-sboms 2 \ --require-build-name sbom-build --require-build-name sbom-optimizer \ --runtime-severity CRITICAL --build-severity HIGH,CRITICAL This example blocks fixable Critical vulnerabilities in the runtime and fixable High or Critical vulnerabilities in the build environment. A vulnerable build tool matters even when it is not shipped to users. Missing inventories or scanner errors also stop the release. This is a starting policy: other findings still need review, and scanner coverage must match your packages and operating system. The companion repository documents the scanner limitations found in testing and how to adapt the gate to other Dockerfiles and platforms. Before promotion, also start the candidate and check that the application responds. A clean scan is not a substitute for a working application. Only after the gate and application checks pass should the candidate receive a release tag: - name: Promote Java image run: | docker buildx imagetools create \ --tag ghcr.io/${{ github.repository }}:latest \ ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }} This promotes the existing candidate with its attestations. It does not rebuild the application after the security check, so the release is the artifact you tested. Putting It Together The resulting release chain is: Sandbox the coding agent → quarantine and verify Java build inputs → compile in a hardened JDK stage → run from a minimal non-root JRE image → attest the build and runtime inventory → scan runtime and build SBOMs attached to the immutable digest → promote only the artifact that passed. Make each step visible in CI so a failure stops the release at the right point. The companion repository provides the implementation details, including pinning tools and protecting credentials. Agent Prompt If your coding client supports Agent Skills, install the SIP skill and give the agent this prompt inside the Java repository you want to secure: $sip SIP it up! Adapt and implement controls ii through v for this Java project. Ask questions when in doubt. Run the agent inside the sandbox from control one. Review every proposed dependency, Maven or Gradle plugin, Dockerfile change, and CI permission before merging it. Conclusion SIP is not a complete software supply chain security program. It is an immediate plan for reducing the most obvious risks while creating a trustworthy path from Java source code to a released container image. For Java teams, that means looking beyond application JARs. The JDK, Maven or Gradle plugins, annotation processors, base images, build stages, attestations, and release tags are all part of the same chain. Start with this connected path, test its failure cases, and extend it with verified provenance and ongoing vulnerability management. References and Implementation Resources - SIP Java companions: application, Dockerfiles, and SBOM gate - SIP framework and reference implementation - Portable SIP Agent Skill - Maven Wrapper checksum verification - Gradle dependency locking - Gradle dependency verification - Docker Hardened Images for Java - Docker build attestations - Original SIP article - How to Containerize a Java Application Securely — JAVAPRO - Modernizing Production Containers to Resist the Constant CVE Flow — JAVAPRO - The Poisoned Macchiato: Signing Java SBOMs with Cosign — JAVAPRO <!-- devto-source: containersecurity.dev --> <!-- devto-content: 098aaa90884d2339fdcf3b6d57b3200e34ba606d9a7b16df202a1a6190a5fe64 -->

RadioText AI: Making Internet Radio More Accessible with Captions RadioText AI: Making Internet Radio More Accessible Hi! I'm Roman Eklmn, an independent developer building applications with AI under Eklmn Lab. Today I'd like to introduce RadioText AI, my experimental Android application designed to make internet radio easier to follow through speech-to-text captions. What does RadioText AI do? RadioText AI lets you listen to internet radio while reading recognized speech on your Android screen. The project is especially interested in accessibility for Deaf and hard-of-hearing users. Current beta features include: - Internet radio playback - Speech-to-text captions - Russian and English recognition - Experimental detection of radio contest announcements - Local caption history - Android accessibility improvements Why am I building it? Radio is primarily an audio medium. I want to explore how speech recognition can help more people access spoken radio content. I'm an independent developer, still learning, testing and improving the application. Watch the demonstration {% youtube X1AaoZd3cdc %} Download the Android beta GitHub Releases: github.com/OskolElkin/RadioText-AI-Releases/relea… Alternative download on itch.io: oskolelkin.itch.io Current limitations RadioText AI is a beta project, not a finished commercial product. Recognition accuracy depends on audio quality, language, music, background noise and device performance. Contest detection is experimental and may produce incorrect results. The app does not automatically enter contests. Looking for volunteer testers I'm looking for people willing to test RadioText AI on Android. Feedback from Deaf and hard-of-hearing users would be particularly valuable. I'd appreciate feedback about: - Installation and first launch - Caption accuracy and readability - Ease of navigation - Bugs and crashes - Accessibility improvements Please share your experience in the comments. About the developer Roman Eklmn — Eklmn Lab GitHub: github.com/OskolElkin Website: oskolelkin.github.io Thanks for checking out my project!

Still holding your crypto on someone else's server? 🫵 Download the XFER wallet. Run YOUR own node. Hold YOUR own keys. Windows + Linux. Free. Takes minutes. github.com/NiftyRaven/x-coin/releases/latest It's your chain. Run it. ❤️‍🔥 XFER is listed on Neoxa: XFER_USDT neoxa.exchange t.co

Location: Sunnyvale, California (San Francisco Bay Area) Remote: Yes, or on-site/hybrid in the Bay Area Willing to relocate: Yes Availability: immediately Technologies: Python, TypeScript, SQL, LangGraph, MCP, Claude and OpenAI APIs, vector and graph retrieval, evals, LLM-as-judge, PySpark, dbt, Databricks, FastAPI, NestJS, React, Next.js, PostgreSQL, Docker, AWS, Azure, GCP Résumé/CV: harishmanoharan.com Website: harishmanoharan.com GitHub: github.com/harishm17 LinkedIn: linkedin.com Email: harish_manoharan@outlook.com Software engineer at Purgo AI (M.S. CS, UT Dallas, 2026). I build the retrieval, self-review and evals for a production multi-agent LangGraph system that turns customers' data-engineering tickets into PySpark and SQL, and I built both of Purgo's validation products full stack. On my own I run ReadableSTEM, which turns STEM PDFs into accessible HTML for blind and low-vision students, and Margins, which turns a student's course files into cited notes, quizzes and a study plan. Looking for AI/backend engineer roles at startups. Authorized to work in the US, no sponsorship needed

@Ebnereyhan @givHeisenberg @vesalbehrouzi اینم خوبه career-ops-hq/career-ops

@Lockhead @QuinnyPig One command equals this abomination: tobilg/serverless-aws-static-websites

Custom Tracker Firmware - Performance FX Scenes I've wanted this feature forever! Thanks to the Polyend gods for open-sourcing the firmware, I was able to finally make it. This lets you store up to 8 Performance FX "scenes" per project. What nice is that each scene can have its own FX slots so now you can easily switch between all your performance FXs. I've only tested this on the Mini as it's the only tracker I own. Link to source code: ramsaylanier/tracker-ce

How to Run Regulated Apps in the Cloud: SOC 2, HIPAA, and PCI DSS Platforms, Data Residency With Failover, and a Compliance Checklist A compliant application platform gives you audited infrastructure controls, but compliance is shared: you still need your own controls for data classification, identity, secrets management, and logging. To keep data in one country with failover, run in at least two locations inside that country and ensure every replica, backup, and log stays there. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant, and it runs a workload only in the locations you choose across AWS, GCP, Azure, and your own servers. Disclosure: Control Plane publishes this guide. This is general guidance, not legal or audit advice. TL;DR - What platform compliance covers. SOC 2 Type II, HIPAA eligibility, and PCI DSS attestations apply to the platform’s services, not your application logic or data handling. - How to verify a platform ’s claims. Request the SOC 2 Type II report under NDA, the PCI DSS Attestation of Compliance, and a signed BAA. Check which services and regions are in scope. - Data residency with failover. Choose two or more locations inside the same country, run active-active or active-passive between them, and pin replicas, backups, logs, and keys to those locations. - The compliance checklist. Classify data, enforce region allow-lists with policy as code, manage secrets outside your codebase, isolate tenants, log everything immutably, and document AI data flows. - How Control Plane fits. On Control Plane, a workload runs only in the locations of Control Plane’s Global Virtual Cloud (GVC), a set of locations a workload runs across, so you control data residency by choosing locations. Workloads deploy active-active across every location in a GVC, and a global endpoint routes each request to the nearest healthy location. Which application platforms are SOC 2 Type II, HIPAA, and PCI DSS compliant? AWS, Google Cloud, and Azure each hold SOC 2 Type II reports and PCI DSS Level 1 service provider attestations, and each signs a BAA covering a published list of HIPAA-eligible services. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant. Its SOC 2 Type II audit was completed by Prescient Assurance, and its SOC 2 Type II report and PCI DSS Attestation of Compliance are available from support@controlplane.com, and its docs publish a PCI Responsibility Matrix. What each framework means for a platform buyer SOC 2 Type II is an attestation report from an independent CPA firm. The auditor tests whether a platform’s controls operated effectively over a review period, commonly three to twelve months. A Type I report covers only control design at a single point in time. Platforms renew the report each year, so check the period end date and ask for a bridge letter if it ended months ago. A badge on a marketing page shows none of the scope or exceptions, so ask for the report itself. HIPAA has no official certification program. The U.S. Department of Health and Human Services does not certify software or cloud platforms as “HIPAA compliant.” Instead, look for two things: a signed Business Associate Agreement (BAA), which sets out how the platform must protect electronic protected health information (ePHI), and a clear list of HIPAA-eligible services. Under the HITECH Act, a platform that handles ePHI as a business associate is also directly liable for complying with the HIPAA Security Rule. Any service not on that list should not touch ePHI. PCI DSS compliance is documented in an Attestation of Compliance (AoC), the official PCI Security Standards Council form summarizing the results of an assessment. Platforms that process, store, or transmit cardholder data are assessed as service providers. Card brands such as Visa and Mastercard classify a service provider as Level 1 when it handles more than 300,000 card transactions a year, and Level 1 requires an annual assessment by a Qualified Security Assessor (QSA) and a Report on Compliance. The AoC states which services and environments are in scope. How to verify a platform’s compliance 1. Request the SOC 2 Type II report under NDA. Read the auditor’s opinion, the description of the system boundary, and any exceptions noted. 2. Request the PCI DSS Attestation of Compliance. Confirm the service provider level and check which services and data center regions are covered. 3. Request a signed BAA before any ePHI touches the platform. Confirm the list of HIPAA-eligible services. 4. Check scope : which regions, which services, and which deployment models are included. A platform may be compliant in some regions but not others. AWS, Google Cloud, and Azure each publish compliance programs with lists of in-scope services. AWS maintains its compliance programs page, Google Cloud publishes its compliance offerings, and Azure documents its compliance offerings. Who owns which compliance controls, the platform or the customer? The table below maps common control areas to who typically owns them. Control Area| Typically Responsible| Evidence to Collect ---|---|--- Infrastructure security (host OS, hypervisor, physical)| Platform| SOC 2 Type II report, penetration test summaries Network segmentation and firewalls| Shared| Network architecture diagrams, firewall rule exports Identity and access management| Customer| SSO configuration, MFA enforcement logs, RBAC policies, access reviews Secrets management| Customer| Secrets manager configuration, rotation logs, proof secrets are not in code Data encryption (at rest and in transit)| Shared| Encryption configuration, key custody documentation, TLS certificates Logging and audit trails| Shared| Log retention policies, tamper-resistance proof, SIEM integration Application code security| Customer| SAST/DAST scan results, dependency vulnerability reports, change approvals Data classification| Customer| Data inventory, classification tags, handling procedures Backups and disaster recovery| Shared| Backup location confirmation, restoration test results, RTO/RPO evidence Incident response| Shared| Incident response plan, tabletop exercise records, notification procedures A platform’s audit reports cover the rows marked Platform and the platform’s part of the Shared rows. Rows marked Customer or Shared need your own controls and evidence. How do I keep customer data in a specific country while still having multi-region failover? Run the application in two or more locations inside the country, replicate data only between those locations, and keep every replica, backup, log, and key in-country. Traffic fails over between the in-country locations, never to a region abroad. Architecture options: - Active-active between two in-country locations removes failover delay, because each location already serves traffic, and a global load balancer routes requests to the nearest healthy one. - Active-passive keeps a standby location in-country that takes over during an outage. It costs less but introduces failover time. Databases in active-active. The application tier can run active-active, but most relational databases accept writes on one primary. Put the primary in one in-country location and a replica in the other, and send writes from both locations to the primary. Synchronous replication gives a recovery point objective (RPO) of zero, meaning no committed write is lost, at the cost of added write latency. In-country locations are usually close enough to keep that cost low. Asynchronous replication adds no write latency but can lose writes not yet copied when the primary fails. On failure, promote the replica and repoint the application. Use a quorum or fencing so two primaries never accept writes at once. To accept writes in every location, use a distributed SQL database such as CockroachDB, YugabyteDB, or Google Cloud Spanner, and keep all of its nodes in-country. For a deeper comparison of these patterns, see active-active vs. active-passive cost and architecture trade-offs. What to pin in-country: - Primary database and all replicas - Backups and snapshots - Object storage buckets - Application logs and audit logs - Encryption keys - Cache layers What to check: - Where does the platform’s support staff access data from? - Where do telemetry and monitoring data flow? - Where does TLS terminate? Global load balancers and CDNs can decrypt requests at edge sites outside the country. - Where do managed AI APIs send prompts and responses for processing? - Does the platform offer contractual commitments on data location? Where can I find a cloud provider that keeps my data in one country to reduce risk? AWS, Google Cloud, and Azure each run two or more regions in the United States, Canada, Australia, Japan, and India, so one provider can cover in-country failover in those countries. Not every country has two cloud regions from a single provider. In those cases, combining regions from multiple providers, or adding your own data center, may be the only viable in-country option. A detailed breakdown of provider coverage by country is available in best cloud providers for data sovereignty in 2026. For architectural patterns, see sovereign cloud architecture for data residency compliance. What practical controls ensure data residency and sovereignty in a multi-cloud infrastructure? - Region allow-lists enforced by policy. Each major cloud has a native mechanism: AWS Service Control Policies with aws:RequestedRegion conditions (with exemptions for global services such as IAM), Azure Policy’s built-in Allowed locations policy, and the Google Cloud resource locations organization policy constraint. - Data classification and tagging. Tag every resource with its data classification (e.g., data-class: phi, data-class: pci). Use tags to trigger policy enforcement and to generate audit reports. - Encryption with keys held in-region. Store encryption keys in the same jurisdiction as the data they protect. Cross-border key storage can undermine sovereignty even if the ciphertext stays in-country. - Egress controls. Block or alert on data transfers to regions outside the approved list. Use VPC flow logs, firewall rules, and DLP inspection at egress points. - Residency-aware backups. Explicitly configure backup destinations. Some services copy backups or geo-redundant replicas to a second region by default or with a single setting, and that region is not always in the same country. For example, Azure geo-redundant storage replicates to the paired region, and Brazil South is paired with South Central US. Multi-region storage locations such as Google Cloud’s EU or US buckets span several countries. - Logging location. Route logs to a logging service or bucket pinned to an approved region. If you use a third-party logging provider, confirm where they store and process your data. - Regular audits. Periodically scan for resources created outside approved regions. Automated compliance scanners can flag drift before it becomes an audit finding. What cloud compliance checklist should I follow when migrating a regulated application to AI infrastructure? AI workloads introduce new compliance surfaces. Prompts, model outputs, training data, and vector store contents can all contain regulated data. Follow this checklist: 1. Classify data before it reaches a model. Determine whether inputs contain ePHI, cardholder data, PII, or other regulated categories. Apply classification before inference, not after. 2. Decide what can go to third-party model APIs. If you use external APIs for inference, confirm the provider’s compliance posture, sign the appropriate agreements (BAA, DPA), and understand where prompts and responses are processed and stored. Confirm in writing that prompts are not used for training and how long the provider keeps them. 3. Prefer self-hosted or in-region inference for regulated data. Running models on infrastructure you control, within approved regions, keeps regulated data off third-party networks. 4. Log prompts and outputs with redaction. Maintain audit logs of what was sent to a model and what it returned. Redact or tokenize regulated fields before logging. 5. Apply access control to models and vector stores. Treat model endpoints and vector databases as regulated data stores. Enforce RBAC, authentication, and network segmentation. 6. Keep training and fine-tuning data in-region. If you fine-tune models on regulated data, the training data, checkpoints, and resulting model weights must stay within approved jurisdictions. 7. Document data flows for auditors. Create a data flow diagram that shows how regulated data moves through your AI pipeline: ingestion, preprocessing, inference, post-processing, storage, and deletion. Auditors will ask for this. 8. Plan for deletion. Embeddings and fine-tuned weights derived from personal data must be deletable when a data subject asks for erasure, so record which data each one came from. What are the best practices for secrets management in IaC pipelines to meet cloud compliance requirements? Secrets in infrastructure-as-code pipelines are a frequent audit finding and a common attack vector. - No secrets in code, state files, or CI logs. Credentials leaked in repositories are a common way attackers get cloud access. Terraform writes values read through data sources into state; Terraform 1.10 added ephemeral resources and 1.11 added write-only arguments to keep secrets out of state and plan files. - Use a secrets manager, referenced by name. Store secrets in a dedicated service such as AWS Secrets Manager, Google Cloud Secret Manager, or Azure Key Vault, or in HashiCorp Vault. IaC templates should reference secret names, never values. - Short-lived credentials through workload identity federation. Replace static API keys with short-lived federated tokens that expire automatically, typically within an hour. AWS, GCP, and Azure all support workload identity federation natively. - Least-privilege pipeline roles. The CI/CD service account should have only the permissions needed for the current deployment. Separate roles for plan and apply stages. - Rotation. Automate rotation on a defined schedule, and rotate immediately after a suspected exposure or when someone with access leaves. Log every rotation. - Secret scanning in CI. Run tools like Gitleaks or TruffleHog in your CI pipeline to catch secrets before they merge. - Encrypted and access-controlled IaC state. Terraform and Pulumi state files can contain sensitive values. Encrypt state at rest, restrict access to the state backend, and audit who reads it. How should I structure governance and policy as code for compliant multi cloud infrastructure using IaC? Policy as code turns compliance rules into enforceable, version-controlled, auditable artifacts. Structure it in layers: Preventive guardrails at the account or organization level. These are the broadest controls. Service Control Policies in AWS, Organization Policies in Google Cloud, and Azure Policy assignments at the management group level prevent non-compliant resources from being created in the first place. Policy checks in CI before apply. Before any IaC change reaches production, validate it against your compliance rules. Open Policy Agent (OPA) is a widely adopted open-source engine for this purpose. Evaluate the JSON output of terraform plan with OPA through a tool such as Conftest, or use Pulumi CrossGuard policy packs with pulumi preview, and fail the pipeline on violations. In Kubernetes, OPA Gatekeeper or Kyverno applies the same rules at admission time. Runtime detection. Even with preventive controls, configuration drift happens. Use runtime scanners to detect resources that have drifted from their compliant state and alert or auto-remediate. Evidence collection for audits. Every policy evaluation, pass or fail, should produce a log entry. These logs become audit evidence showing that controls were in place and operating continuously. Examples of rules to codify: - Allowed deployment regions (for example, only the regions inside the country your data must stay in) - Required encryption on all storage resources - Required classification tags on every resource - No public access on storage buckets or object stores - MFA required for privileged roles What cloud solutions offer multi tenant protection against cross tenant data breaches? Cloud platforms separate tenants at three layers: separate accounts or projects (AWS accounts, Google Cloud projects, Azure subscriptions), compute isolation (separate clusters or microVM sandboxes such as Kata Containers), and data isolation (separate databases and per-tenant encryption keys). Tenant isolation models Model| Layer| Isolation| What tenants still share ---|---|---|--- Separate accounts or projects| All layers| Highest| Only organization-level billing and policy Separate clusters in one account| Compute| High| Cloud IAM, network, and account quotas Separate namespaces in one cluster| Compute| Low to moderate| Kernel, nodes, and cluster control plane; relies on network policies, RBAC, quotas, and pod security Separate database instances| Data| High| Network and admin credentials Separate databases or schemas on one instance| Data| Moderate| Database engine, memory, and admin accounts Row-level security on shared tables| Data| Lowest| Everything; one missing tenant context or a role that bypasses RLS exposes other tenants Choose a compute model and a data model separately. A common pattern is separate accounts for the most sensitive tenants and shared clusters with separate databases for the rest. How do I design AI infrastructure for cloud compliance using BYOK and tenant data segregation? In this context, BYOK (bring your own key) means encrypting data with keys you control, generated or imported into a cloud key management service, instead of provider-managed keys. Tenant isolation and per-tenant encryption are the two pillars of preventing cross-tenant data exposure. Per-tenant encryption keys Store each tenant’s encryption key in a cloud KMS (such as AWS KMS, Google Cloud KMS, or Azure Key Vault). The application references the tenant’s key ID when encrypting or decrypting that tenant’s data. If one tenant’s key is compromised, only that tenant’s data is exposed. Disabling or deleting a tenant’s key makes their data unreadable, which supports offboarding and deletion requests, and KMS logs show every use of each tenant’s key. Scope the application’s decrypt permission per tenant, or one compromised service can still use every key. Tenant separation in AI workloads Vector stores and model caches introduce new cross-tenant risks. If multiple tenants share a vector database, queries from one tenant could surface embeddings from another. Mitigations include: - Namespace or collection-level separation within the vector store - Tenant-scoped query filters enforced at the application layer - Separate model inference endpoints per tenant for the most sensitive workloads - Scoping prompt caches and response caches to one tenant. Inference servers that reuse the KV cache for shared prompt prefixes, and semantic caches that return a stored answer for a similar prompt, can leak data or timing signals across tenants. Add the tenant ID to the cache key or disable cross-tenant cache sharing. How Control Plane approaches regulated workloads Control Plane is the unbreakable platform for production workloads. It combines any cloud, neocloud, bare metal, and your own servers into what Control Plane calls a Global Virtual Cloud (GVC), and teams run it in a single region, a single cloud, or across clouds. Control Plane handles Day 2 operations for you, including autoscaling, right-sizing, built-in observability, and security, with no Kubernetes cluster you have to operate. Compliance posture. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant. These controls and the evidence they produce support your compliance, though they do not make you compliant on their own. Data residency through location selection. A workload runs only in the locations of its GVC, which can include AWS, GCP, and Azure regions, Kubernetes clusters you already run, and servers in your own data center or from bare-metal and GPU providers. Control Plane Managed Kubernetes (MK8s) joins those servers into a cluster that Control Plane runs for you as a location. You can keep two or more locations inside one country, including combinations of providers, so the GVC’s location list acts as the region allow-list for that workload. Two in-country locations can also meet the 99.999% SLA condition below. Platform data is handled separately: org secrets are encrypted with envelope encryption and held in cloud HSMs across multiple providers, and logs are aggregated by Control Plane (30-day default retention) and can also be shipped to destinations you control, such as an Amazon S3 bucket or CloudWatch in your chosen region. Active-active failover. A workload deployed to a GVC runs active-active in every location of that GVC, and a global endpoint routes each request to the nearest healthy location. The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations. Those locations can be two regions of one cloud or locations on different providers. For strategies on surviving a single-region outage, see how to keep your app online during an AWS region outage. Security defaults. Workloads are closed by default behind a deny-by-default internal firewall, and traffic between them uses mTLS, with each workload’s client certificate rotated every hour. All data is encrypted at rest and in transit. Each workload is isolated with cgroups, namespaces, and restricted syscalls and capabilities, and Control Plane Sandboxes, isolated environments for AI coding agents and untrusted code, run in dedicated Kata Containers microVMs. Secrets and identity. Control Plane’s built-in secrets management lets workloads reference a secret as cpln://secret/NAME once their identity is granted the reveal permission, so secret values stay out of code and images. Control Plane’s Universal Cloud Identity gives workloads short-lived, least-privilege access to 600+ AWS, GCP, and Azure services, with no long-lived cloud keys in your code. Audit trail. Every action, whether made through the console, CLI, Terraform, Pulumi, or AI agents using the Control Plane MCP server, is recorded in a tamper-proof audit trail. Your own workloads can write application events to the same audit trail through a custom audit context. Policy and IaC. Control Plane policies are org-scoped and grant fine-grained permissions on every resource type to users, groups, service accounts, and workload identities. Control Plane ships its own Terraform and Pulumi providers, so it complements the infrastructure as code you already run. Cost. Customers typically cut compute costs 30 to 50 percent compared with running directly on AWS, GCP, or Azure. SAFE Health, a connected-diagnostics platform working with Mayo Clinic, migrated 8 environments from AWS to Control Plane and cut its AWS spend 75 percent. For teams looking to simplify multi-cloud operations or consolidate existing infrastructure, see how to consolidate multiple clouds into one platform. For a comparison of managed platform services versus building your own portability layer, see managed services vs. portability and cloud lock-in. FAQ Does a SOC 2 Type II report mean a platform is secure? No. A SOC 2 Type II report shows that an independent auditor tested specific controls and found they operated effectively over a defined period. Read the report’s scope, exceptions, and complementary user entity controls to understand what the platform covers and what you must handle. Is there an official HIPAA certification for cloud platforms? No. The U.S. Department of Health and Human Services does not certify cloud platforms as HIPAA compliant. Look for a signed Business Associate Agreement and a published list of HIPAA-eligible services. The BAA sets the platform’s contractual obligations for safeguarding ePHI, and under HIPAA a business associate is also directly liable for certain requirements, including the Security Rule. What is the difference between PCI DSS Level 1 and other levels? Level 1 is the top tier for service providers. Visa and Mastercard assign it to service providers that handle more than 300,000 card transactions a year, and it requires an annual assessment by a Qualified Security Assessor, who issues a Report on Compliance (ROC) and an Attestation of Compliance (AoC). Level 2 service providers can self-assess with Self-Assessment Questionnaire D. Ask any provider for its responsibility matrix, which PCI DSS v4.0 requirement 12.9.2 obliges it to provide on request. Can I achieve multi-region failover while keeping all data in one country? Yes, if the country has two or more available cloud regions or data center locations. Run active-active or active-passive between them and pin all replicas, backups, logs, and encryption keys to those locations. If a single provider lacks two in-country regions, combine providers or add your own data center. How do I prevent secrets from leaking in IaC pipelines? Store secrets in a dedicated secrets manager and reference them by name in your IaC templates. Use short-lived credentials through workload identity federation, run secret-scanning tools in CI, encrypt your IaC state files, and restrict access to the state backend. What is the shared responsibility model in cloud compliance? The platform is responsible for infrastructure-level controls such as physical security, hypervisor patching, and network fabric. You are responsible for identity and access management, secrets, application code security, and data classification. Network segmentation, encryption, logging, backups, and incident response are shared. How should I handle regulated data in AI inference pipelines? Classify data before it reaches a model. Use self-hosted or in-region inference for regulated data. Log prompts and outputs with redaction of sensitive fields. Apply access control to model endpoints and vector stores. Document the full data flow for auditors. Does Control Plane make my application compliant? No. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant and provides audited controls and evidence that support your compliance, but your application still needs its own controls for data classification, identity, secrets, application security, and logging. Can Control Plane keep my workload in a single cloud? Yes. Many teams run Control Plane in a single cloud for its Day 2 operations and security defaults. A GVC can contain locations from a single provider, and two regions of one cloud qualify for the 99.999% SLA when a workload runs at least two replicas in those two locations. How does Control Plane handle workload isolation? Each workload is isolated with cgroups, namespaces, and restricted syscalls and capabilities, and Control Plane Sandboxes run in dedicated Kata Containers microVMs. Workloads are closed by default behind a deny-by-default internal firewall, and traffic between them uses mTLS. See how Control Plane runs regulated workloads. Talk to the Control Plane team or sign up free --- Originally published on the Control Plane blog.

Yeah the historical question still interests me. Did V9 really originate negative pid killing via /bin/kill, or did System V or SunOS already have it? If the main use case was shell job control, maybe there wasn't yet a good reason to expose it. The extent of my spelunking for the post was TUHS, the unix-history-repo, and playing around with kill on old unixes in the browser via v86.

From Training Exposure to Membership Evidence: A Controlled Study of OLMo 2 Ali Banaei, Muhammad Shahab Shahzad, Gerald Q. Maguire, Marco Chiesa, Dejan Kostić arxiv.org [𝚌𝚜.𝙲𝚁 𝚌𝚜.𝙲𝙻 𝚌𝚜.𝙻𝙶] 💬Code: ali-bana/OLMo-Twin t.co

原文： reddit.com arxiv.org infiniflow/ragflow

mdict.koplugin: MDict (.mdx/.mdd) dictionaries in KOReader's own lookup popup, with full layouts, vertical Japanese, scripts and audio (Android) Hi all! I've been reading on an Android e-ink device and wanted my MDict dictionaries in KOReader without leaving the reader on every lookup. So I wrote a plugin that does that: **[mdict.koplugin](moopoint-dev/mdict.koplugin)**. *([犬 lookup, vertical Japanese](raw.githubusercontent.com))* **What's MDict?** It's the `.mdx`/`.mdd` format behind many of the best dictionaries for Chinese, Japanese and English learners. They're used in apps like GoldenDict, Eudic and DictTango. Many of these dictionaries rely on modern CSS, embedded fonts, JavaScript and audio. **The problem.** KOReader's lookup popup only reads StarDict, and it lays out HTML definitions with MuPDF. That works well for plain entries, but MuPDF supports only part of CSS (no flexbox or grid), has no vertical text and runs no JavaScript, and KOReader plays no audio. The usual workarounds each cost something: - **Converting to StarDict** (e.g. with PyGlossary) drops the audio and the scripts, needs the CSS copied by hand, and has to be redone whenever a dictionary updates. - **Sending lookups to an external app** leaves KOReader on every lookup. On e-ink that means several full-screen refreshes, and most of these apps scroll instead of turning pages. **What the plugin does** - Reads `.mdx`/`.mdd` directly. Drop them in `koreader/data/dict/` and they show up in *Manage dictionaries* next to your StarDict ones. No conversion needed. - On Android, lays each entry out with the system WebView (Chromium): full CSS, web fonts and fonts from the `.mdd`, **vertical Japanese**, ruby, tate-chu-yoko, SVG math, stroke-order tables, illustrations. - **Runs the dictionary's own scripts**, so collapsible sections (VERB FORMS, Extra Examples…) open and close, and full-size image viewers work. - **Plays pronunciations and example sentences** (AAC, MP3, Ogg, WAV). - **Pages instead of scrolling**, sized to the popup and made for e-ink. Swipe or tap to turn pages, swipe the other way to change dictionary, and pinch out for KOReader's large window. The next result is laid out in the background, so switching is quick. - Works with the rest of KOReader: hold a word in an entry to look it up, *Find in definition*, lookup history, vocabulary builder. - E-ink mode (black text, no tinted backgrounds), your own font, and per-dictionary horizontal/vertical and page-layout settings. - Per-dictionary `name.koreader.css` / `name.koreader.lua` override files, for dictionaries whose styling needs fixing for e-ink. - **No custom KOReader build needed.** It works with the official Android app and updates itself from GitHub releases (at most one check a day; it never turns Wi-Fi on for that). **Screenshots** (from an emulator shaped like a 7", 300 ppi reader): - [*rabbit*, Oxford English-Chinese, with its illustration](raw.githubusercontent.com) - [故, vertical, with stroke order and ruby](raw.githubusercontent.com) - [双曲線 (hyperbola), horizontal, with accent marks, audio buttons and a diagram](raw.githubusercontent.com) - [双曲線, vertical, with figures](raw.githubusercontent.com) - [GIF: *watch*, with a folded section, pages, the next result and a full-size image](raw.githubusercontent.com) **Install** 1. Download `mdict.koplugin-<version>.zip` from [Releases](github.com/moopoint-dev/mdict.koplugin/releases) and unzip it into `koreader/plugins/`. 2. Put your `.mdx` files, with their `.mdd` files next to them, in `koreader/data/dict/` (or add folders under *Search → Settings → MDict dictionaries*). 3. Restart KOReader. Big dictionaries get indexed once in the background (a few seconds each). **Limitations** - The WebView renderer is **Android only**. On Kindle, Kobo and PocketBook the plugin falls back to KOReader's own renderer: text and images work, but not vertical text, scripts or audio. - MDict 3.0 and registered (record-encrypted) files aren't supported yet. Speex audio doesn't play. It's open source (AGPL-3.0, same as KOReader), and it's still young. If a dictionary looks wrong or a lookup misses, please open an [issue](github.com/moopoint-dev/mdict.koplugin/issues) with the dictionary name, the word, and a screenshot. Feedback and dictionary-specific CSS fixes are very welcome!

Empowering AI Agents with agent-desktop A New Approach to the Problem The agent-desktop repository addresses the challenge of enabling AI agents to effectively interact with desktop applications across different operating systems. By leveraging the OS accessibility tree, it allows agents to read and operate applications without pixel matching, which is often unreliable. What is it and How it Works agent-desktop is a CLI and C library developed for macOS, Windows, and Linux. It creates snapshots of the desktop environment, returning JSON representations of all elements an agent can interact with. The agent executes actions on these elements and verifies changes without requiring pixel recognition. Each CLI call operates in its own process, ensuring that headless calls do not interfere with the foreground application. Key Features: - Cross-Platform Compatibility: Works on macOS, Windows, and Linux. - Snapshot Functionality: Returns a JSON object with references for every interactive element, allowing agents to perform actions and verify their results. - No Pixel Matching Required: The system uses the accessibility API, which is more reliable than pixel-based methods. - Privacy Considerations: Snapshots and outputs may contain sensitive data; users should manage this information carefully. Key Capabilities & Developer Onboarding Installation is straightforward via npm, Bun, Yarn, or pnpm: npm install -g agent-desktop agent-desktop version For direct execution without a JavaScript launcher, users can download the native archive from GitHub Releases and keep its helper beside the executable. Here’s a quick start example showing how to interact with the Finder app on macOS: agent-desktop snapshot --app Finder -i # interactive elements, each with a ref agent-desktop click @s8f3k2p9:e8 # act on a ref from that snapshot agent-desktop snapshot --app Finder -i # observe again to verify The JSON response includes details about the application state, making it easier for developers to understand the environment. Who Should Use It & Integration Scenarios agent-desktop is ideal for developers building AI agents that need to automate desktop tasks across multiple operating systems. It is particularly useful for applications requiring interaction with GUI elements without direct user input. However, it may not be suitable for scenarios demanding real-time visual feedback or where pixel precision is critical. Limitations & Trade-offs: - Platform-Specific Permissions: On macOS, accessibility permissions are required, which can add complexity to deployment. - Headless Operation Constraints: Although the system is headless by default, it requires a graphical session on Linux, which can limit usability in certain environments. - No Foreground Activation: Actions performed do not activate the foreground application, which may not align with all automation needs. Community Pulse: What Developers Are Saying Community discussions indicate a growing interest in the agent-desktop project, especially following the recent release of version v1.0.2 on October 30, 2026, which introduced various documentation improvements and clarified installation permissions. Users appreciate the simplicity of the API and the potential for integrating AI-driven workflows into desktop environments. Our Read Overall, agent-desktop presents a compelling solution for AI agent interactions with desktop applications, emphasizing cross-platform compatibility and privacy considerations. While it offers significant capabilities, potential users should be mindful of its limitations, particularly regarding permissions and headless operation constraints. --- Originally published on GitTrending — Explore daily architectural deep-dives and quality scores for trending open-source GitHub projects.

Built my first open-source tool (Reputation Engine) to find clients experiencing pain right now &#x200B; Hey, I used n8n before, but this is my first time vibecoding and pushing code to GitHub. I built Reputation Engine, an open-source B2B pipeline that scans Google Maps for negative customer reviews, finds real decision-makers on LinkedIn, uses LLMs to vet them, and delivers ready-to-use outbound lead sheets for accounts experiencing operational friction right now. I had an absolute blast building this. The best part was testing it across completely different industries and watching it spit out spot-on results for every single one. Can't wait to get paid full-time for building stuff like this! Would love your feedback on the tool: 👉 GitHub: chiragbatra-beep/reputation-engine

Athrillのriscv対応始めました。 hakoniwalab/athrill-target-riscv

Lots of "Claude Code hooks -> ping my phone" setups going around today. Love it. If you'd rather not wire your own webhook: Clippy does it on Windows, a desktop sticky note plus Telegram or WhatsApp when you're away. MIT: geetbatth/professor-clippy

We published two more exploit and detection packages to @vulncheck's Initial Access community repo today. Neither CVE has been reported exploited in the wild yet, but both product ecosystems have been exploited in the past. Today's haul: - CVE-2026-92122: A Groovy sandbox escape in the Jenkins Script Security Plugin, which (per Jenkins) is installed on 98.8% of all Jenkins controllers. FOFA shows ~80K Jenkins servers online. - CVE-2026-8857: A command injection vulnerability in MediaWiki's EasyTimeline plugin (which was enabled in Fandom). A Nuclei template has been available since August, and there are ~25K MediaWiki instances online (which means that if this thing really hasn't been exploited yet - dubious - it probably will be). Both #exploits come with Suricata and Snort rules, vulnerable target Docker containers, PCAPs, and ASM queries. vulncheck-oss/initial-access-community