标签：#opensource

GitHub热门项目 | | Stars: 12,155 | 86 stars today | 语言: TypeScript

GitHub热门项目 | Visual Studio Code | Stars: 185,505 | 62 stars today | 语言: TypeScript

GitHub热门项目 | Project N.O.M.A.D, is a self-contained, offline survival computer packed with critical tools, knowledge, and AI to keep you informed and empowered—anytime, anywhere. | Stars: 26,702 | 294 stars today | 语言: TypeScript

GitHub热门项目 | WebGoat is a deliberately insecure application | Stars: 9,134 | 5 stars today | 语言: JavaScript

GitHub热门项目 | 📄 Configuration files that enhance Cursor AI editor experience with custom rules and behaviors | Stars: 39,770 | 27 stars today | 语言: JavaScript

GitHub热门项目 | Clean Code concepts adapted for JavaScript | Stars: 94,393 | 18 stars today | 语言: JavaScript

GitHub热门项目 | Welcome to a calmer internet | Stars: 42,327 | 67 stars today | 语言: JavaScript

GitHub热门项目 | Turn any PDF or image document into structured data for your AI. A powerful, lightweight OCR toolkit that bridges the gap between images/PDFs and LLMs. Supports 100+ languages. | Stars: 78,940 | 148 stars today | 语言: Python

GitHub热门项目 | PentestAgent is an AI agent framework for black-box security testing, supporting bug bounty, red-team, and penetration testing workflows. | Stars: 2,489 | 30 stars today | 语言: Python

GitHub热门项目 | Deep Eye orchestrates multiple AI providers (OpenAI, Claude, Grok, Gemini, OLLAMA, Groq, Mistral, OpenRouter, LiteLLM, LM Studio) for intelligent payload generation, scans targets for 45+ vulnerability types, and produces professional reports with compliance mapping. | Stars: 1,562 | 42 stars today | 语言: Python

GitHub热门项目 | 自动化上传视频到社交媒体：抖音、小红书、视频号、tiktok、youtube、bilibili | Stars: 11,582 | 185 stars today | 语言: Python

GitHub热门项目 | A platform for reproducible world model research and evaluation | Stars: 1,058 | 346 stars today | 语言: Python

Supply chain attacks every other morning Unless you've lived under a rock for the last few months, you probably noticed that software supply chain attacks are getting trendy among threat actor groups. Over the last 12 months, we've seen more of those than ever before, to name only a few of them: tj-actions/changed-files : In March 2025, a popular reusable GitHub application workflow was compromised to dump secrets from CI/CD pipelines. Salesloft Drift : In August 2025, threat actors stole OAuth credentials from the compromised Drift chatbot application. Shai-Hulud : In September and November 2025, a wormed attack propagated through npm packages and collected secrets. The common thread among those incidents is that they all revolved around secrets, one way or another. Some used secrets as an initial access vector, and others were focused on collecting secrets from victim environments. March 2026 did not change the state of things, with two new severe attacks added to our dreadful collection: trivy-action & LiteLLM campaign by Team PCP. The most popular Axios package compromise. Both those attacks followed a now-classical pattern, spreading through compromised open-source dependencies to maximise the impact in the shortest possible time. Your all-time classic, now with added internal threats Open-source supply chain attacks are not new. Ever since we started using centralized open-source package registries, the risk has existed. Threat actors understood this and started exploiting it. What has changed since 2015 is how we have improved software development productivity through automation. And now, this very same automation that lets you test and build your projects without typing a single command is amplifying the supply-chain threat and the velocity of attacks. Let's see how. Keeping your malware up to date A very concerning pattern we've observed in the trivy-action and Axios campaigns is that automation can become the source of your compromise. One thing no develop

If you have ever run a Lighthouse audit on a content-heavy WordPress site, you know the usual verdict: "Serve images in next-gen formats." Translation: your JPEGs and PNGs are too heavy, and WebP would cut them down a lot. The problem is that nobody wants to convert images by hand, and most automated options either run as a bulk job you have to remember to trigger, or push your images to a cloud service with a monthly quota. I wanted something simpler: upload an image, get a WebP, done. So I built a free plugin called Pixellize Image Optimizer , and this post walks through the problem, how the plugin solves it, and how it works under the hood. Why WebP is worth it WebP files are usually 25 to 35 percent smaller than the equivalent JPG or PNG at the same visual quality. On an image-heavy page that is a real difference: Faster Largest Contentful Paint, which is one of the Core Web Vitals Google uses for ranking. Less bandwidth, which matters if you pay for CDN traffic. No visible quality loss at sensible quality settings. Browser support is no longer a concern. Every current browser handles WebP. The approach: convert on your own server, on upload Instead of a cloud API, the plugin converts images locally with the PHP GD or Imagick extension (almost every host has one). There is no account, no API key, and no paid tier. The core flow: You upload an image to the Media Library as usual. The plugin generates a WebP version of the full image and every thumbnail size. Your front end serves the WebP automatically. How it works under the hood For WordPress developers, here is the interesting part. The plugin hooks into the standard upload and rendering pipeline rather than fighting it: On upload, it taps into the attachment metadata generation so it can convert the full image and every registered sub-size, not just the original. That matters because responsive images use srcset , and a half-converted set defeats the purpose. On the front end, it rewrites image URLs to the We

OpenTelemetry has quietly become table stakes. That's a good thing, but if you've instrumented a real codebase, you know the tax. A method that does one obvious thing slowly fills up with StartActivity , SetTag , AddEvent , SetStatus . The bookkeeping of telemetry starts to drown out the intent of the code, and in review you spend half your time mentally separating "what this code does" from "what we report about what it does." It's easy to think "oh, but the framework takes care of this with auto-instrumentation", but if you talk to the experts in OTel, they'll go to great lengths to explain that auto-instrumentation is a floor, not a ceiling. Most of the value in telemetry comes from the custom instrumentation you add to your code that adds business context to your traces. And that custom instrumentation is the stuff that clutters up your code. Here's the kind of thing I mean: // before - ugly, obtuse, who put that there var orderId = order . Id ; Activity . Current ?. SetTag ( "orderId" , orderId ); Sidemark is my answer to that code-obfuscation problem: non-invasive instrumentation via what I'm calling Active Comments . // after - glorious, beautiful, basking in the light of the sun, closer to god, happy, satiated var orderId = order . Id ; //? The idea A small set of comment syntaxes - //? , //! , //?! - become ride-along annotations . They travel next to the code, get read at build time, and turn into the equivalent Activity calls in the compiled output. The code you read stays the code that does the work. The telemetry rides along instead of competing with your logic for attention. The framing is loosely inspired by Wallaby.js's Live Annotations , which project runtime values inline next to the code that produced them. Sidemark takes the same instinct in the other direction: comments as a write surface for instrumentation, rather than a read surface for debug values. Comments are an under-used channel for information about code that isn't itself code - and su

A lot of Linux incident response starts with a login question, not a malware sample. Someone sees a spike of failed SSH attempts. A root login appears in the wrong time window. A service account logs in from an address nobody recognizes. A helpdesk ticket says "the server looks weird" and the only concrete clue is a username or IP address. At that point, the useful question is not "is this host compromised?" It is more boring and more important: Did anyone actually authenticate? Which account was involved? Was it password, key, sudo, su, or a scheduled task? Was the same IP seen in web logs, current sockets, process context, or command history? Did persistence, services, packages, or recent files change near the same time? Can another responder review exactly what evidence was collected? That last point matters. If you let an AI assistant freely run shell commands during the first pass, you can get speed, but you also create a new risk: the model may over-collect, mutate the host, or produce a confident answer that nobody can audit later. For a login anomaly, I prefer a read-only evidence loop. A practical first pass Start with the narrow clue if you have one. If the alert names a user: oi login --user root -s 7d If the alert names an IP address: oi login --ip 203.0.113.44 -s 7d If the alert is vague, start wider: oi login -s 7d oi scan -s 7d The goal of the first pass is not to prove every detail. The goal is to build a timeline that a human responder can challenge. For a suspicious SSH login, I want the initial report to answer five things. 1. Authentication pattern Look for the difference between noise and access. A server can receive thousands of failed SSH attempts from the internet. That is useful background, but it is not the same as a successful session. The first split should be: failed attempts only successful login after many failures accepted key from an unusual source login by an account that normally should not be interactive root login where root SSH

I had a screenshot to send. Nothing secret — a stack trace from a side project — but it had an internal hostname, a file path with my username, and a chunk of a config file in the terminal behind it. The fast move is to drag it onto a free image host and paste the link. I sat there with my cursor over the upload button and couldn't do it. Because I know what happens next. That image lives on someone else's infrastructure, indefinitely, behind a URL I don't control, and I have no idea who else can reach it. For a throwaway screenshot, that's a permanent record I never agreed to. So I closed the tab and built a thing instead. It's called tmpdrop , and it's ~500 lines of Node. The threat model The problem with public file hosts isn't that they're evil. It's the gap between what you intend ("share this once, with one person") and what the platform delivers ("store this forever, serve it to anyone who finds the link"). A few specific things go wrong: Retention. "Temporary" hosts keep your files long after you've forgotten them. There's no expiry you can trust, and deletion is usually best-effort. Predictable URLs. Plenty of hosts use sequential or short IDs. Scrapers walk the keyspace and hoover up everything. Your "private" link was never private. Stored XSS via uploads. If a host serves an uploaded .html or .svg file inline with a permissive content type, an attacker can ship JavaScript that runs in your browser, in the host's origin. Your file host becomes an XSS delivery service. Abuse vectors. No rate limit means the box is a free CDN for whatever someone wants to dump on it — malware, spam payloads, the works. So the design goal wasn't "another uploader." It was: close each of those gaps, then stop. What I built tmpdrop is a single Fastify server backed by SQLite. The whole defensive surface is small enough to hold in your head: Unguessable URLs. Slugs are 9 random bytes, base64url-encoded — 72 bits of entropy. You cannot enumerate them. A TTL reaper. Every upload

MikuMikuDance still lives mostly on the desktop: PMX models, VMD motion, skirt physics, camera work. We built AnimaStage Lite — an open-source browser studio so you can load assets, preview motion, add FX, and export vertical Shorts without installing MMD. 🔗 Repository: https://github.com/FBNonaMe/animastage-lite 🌐 Live demo: https://animastage-lite.app/ 🎬 Open the studio: https://animastage-lite.app/app Why the browser? Short-form creators need: 9:16 framing and 1080×1920 export Fast PMX + VMD iteration Stable WebGL on everyday laptops AnimaStage Lite is not a full MMD clone — it’s a focused stage : load, animate, light, record. Stack Layer Tech UI React 19 + TypeScript 3D Three.js + React Three Fiber Build Vite 6 Physics Bullet (Ammo.js) HQ video WebCodecs + mp4-muxer Live video MediaRecorder All core features run client-side . What it does Drag & drop PMX/PMD, VMD, textures, HDR Timeline + dopesheet + Bézier curves + VMD export Bullet physics — skirt, hair, accessories RTX Lite — bloom, DOF, weather, style presets MP4 HQ (frame-by-frame) and Live recording Clean capture — no gizmos in the final video 9:16 Lite — lighter render path to reduce WebGL context loss Optional: MediaPipe mocap, Gemini AI keys, Local/WebRTC collab. Try it Online: https://animastage-lite.app/app — drop your PMX + VMD. Locally: bash git clone https://github.com/FBNonaMe/animastage-lite.git cd animastage-lite npm install npm run dev https://animastage-lite.app/ — landing http://localhost:3000/app — studio (local) Optional AI: copy .env.example → .env and set VITE_GEMINI_API_KEY. Open source Star ⭐ the repo, open issues, send PRs: https://github.com/FBNonaMe/animastage-lite MMD models are not bundled — use only content you have rights to publish. What would you use this for — Shorts, VTuber previews, or learning Three.js? Comments welcome. ---

You know that feeling when you join a new project or want to contribute to an open-source repo, and you spend the first two days just trying to figure out where everything is? I did. Every single time. Clone the repo. Open the files. Stare at 47 folders. Wonder which one actually matters. Grep for the entry point. Follow imports down a rabbit hole. Give up and ask someone. That's not learning. That's just wasted time. So I built CodeAutopsy. What it does Paste any GitHub URL. That's it. CodeAutopsy clones the repo, parses every file into an AST (Abstract Syntax Tree), traces every import and dependency, and gives you: An interactive dependency graph showing exactly what imports what The entry points — where execution actually starts A blast radius map — click any file and instantly see everything that breaks if you change it An AI-generated architectural summary explaining what the codebase does, how it's structured, and how to get started Live Health Telemetry: An Edge API that generates a live SVG health badge (A to F grade). Drop the markdown in your README once. Every time you refactor and re-scan, your badge updates everywhere instantly. My own CodeAutopsy repo just hit 99/100. Drop the markdown snippet once and forget about it. What used to take days now takes about 10 seconds. The real problem it solves Every developer has been here: You're onboarding at a new job. The codebase has 200 files. Your tech lead says "just read the code." You spend a week feeling lost. You want to contribute to an open-source project. The repo has no architecture docs. You don't know where to start. You're doing a code review on a PR that touches 15 files. You have no idea what the blast radius of those changes is. CodeAutopsy solves all three. The interesting engineering problems The hardest part wasn't the AST parsing — it was keeping it serverless without hitting Vercel's 504 timeout limits, while making the AI analysis feel instant. The Serverless Timeout Hack: Doing AST extra

Most scraping projects start by finding a website to scrape. This one started from the opposite direction: I knew the data existed as official government downloads, and my job was to make it accessible via a clean API. The data source Ofsted (the UK school inspections body) publishes monthly management information as CSV files on GOV.UK. The file covers all 22,000+ state-funded schools in England with their latest inspection grades, local authority, postcode, phase, and size data. It's 16 MB, published under the Open Government Licence v3.0 — explicitly permitting commercial use. No scraping needed. No authentication. Just a CSV download and some parsing logic. The architecture The actor is deliberately simple: Fetch the GOV.UK stats page to find the current month's CSV URL (the URL hash changes with each release) Download the CSV (~16 MB from assets.publishing.service.gov.uk ) Parse it with csv-parse Apply the user's filters (name, local authority, region, postcode prefix) Push matching records to the Apify dataset No Crawlee. No browser. No proxy. Just fetch() and a CSV parser. const match = html . match ( /href=" ( https: \/\/ assets \. publishing \. service \. gov \. uk \/[^ " ] +latest_inspections_as_at [^ " ] + \. csv ) "/ ); That one regex does the URL discovery. The GOV.UK page lists files in reverse chronological order, so the first match is always the latest release. The interesting part: Ofsted changed their grading system mid-build I built this in May 2026. In November 2025, Ofsted scrapped their 20-year-old four-word judgement system (Outstanding / Good / Requires Improvement / Inadequate) and replaced it with a report card format — six separate grade areas, each on a five-point scale: Exceptional Strong Expected standard Needs attention Urgent improvement Plus a standalone Safeguarding verdict (Met / Not met). The April 2026 CSV reflects this change entirely. There's no "Overall effectiveness" column. Schools inspected before November 2025 have null gr