🏡
  • ↔
  • →
  1. July 25, 2026
    1. 🔗 r/reverseengineering CFP Open – Looking for Technical AI & Security Research for Après-Cyber Slopes Summit 2027 rss

      submitted by /u/PilotSmooth9439
      [link] [comments]

    2. 🔗 @binaryninja@infosec.exchange Current Binary Ninja newsletter subscribers are automatically entered. New mastodon

      Current Binary Ninja newsletter subscribers are automatically entered. New subscribers who sign up during the giveaway will also be entered for remaining drawings. Sign up here: https://v35.us/dn6rcg5

    3. 🔗 @binaryninja@infosec.exchange It’s day 3 of our 10-year anniversary celebration! Today, 3 winners will each mastodon

      It’s day 3 of our 10-year anniversary celebration! Today, 3 winners will each receive a Binary Ninja Journey bottle! Newsletter subscribers are automatically entered. Check out full list of giveaways: https://binary.ninja/10years

    4. 🔗 earendil-works/pi v0.82.1 release

      New Features

      • Claude Opus 5 — Available on Anthropic and Amazon Bedrock with adaptive thinking (including xhigh), inference profiles, and prompt caching. See Providers.
      • Anthropic gateway bearer auth — ANTHROPIC_AUTH_TOKEN authenticates against Anthropic-compatible gateways that require Authorization: Bearer, including compaction and branch summaries. See Environment Variables or Auth File.
      • Faster, more resilient model catalogs — pi.dev catalogs revalidate with If-None-Match so unchanged providers answer with an empty 304, and llama.cpp models stay listed across restarts. See llama.cpp.

      Added

      • Exposed the outputPad setting to custom message renderers. See Extensions (#7045 by @xl0).
      • Added inherited ANTHROPIC_AUTH_TOKEN bearer authentication for Anthropic-compatible gateways. See Providers (#5871).
      • Added inherited Claude Opus 5 support for Anthropic and Amazon Bedrock with adaptive thinking, inference profiles, prompt caching, and preserved AWS validation messages (#7081 by @unexge, #7083 by @davidbrai).

      Changed

      • Changed pi.dev model catalog refreshes to revalidate with If-None-Match, so unchanged provider catalogs answer with an empty 304 instead of a full download.
      • Changed inherited Radius OAuth device authorization, token exchange, and refresh requests to use the configured gateway directly.
      • Changed inherited model loading errors to append the underlying cause, so auth failures such as OAuth refresh failed for openai-codex report the provider response instead of a bare wrapper message.

      Fixed

      • Fixed compaction and branch summaries for providers whose authentication resolves entirely to request headers (#5871)
      • Fixed unavailable scoped models being hidden from /models, allowing them to be removed without editing settings manually (#6949, #7032 by @christianklotz).
      • Fixed startup context file discovery to skip directories that match context file names such as AGENTS.md, which produced EISDIR warnings (#7106 by @mrexodia).
      • Fixed the llama.cpp extension to persist its model catalog, so llama.cpp models stay listed before the first successful refresh. See llama.cpp (#7072 by @davidbrai).
    5. 🔗 Anton Zhiyanov Solod 0.3: Concurrency, JSON, more safety rss

      Solod (So) is a subset of Go that translates to regular C — with zero runtime, manual memory management, and source-level interop. It's designed for two main audiences:

      • Go developers who want low-level control without having to learn another language.
      • C developers who like Go's style.

      At the end of the v0.2 post, I said the obvious goal for the next release was concurrency, along with the stdlib packages that support it. That's what v0.3 is about. So now has threads, channels, worker pools, mutexes, and atomics — enough tools for parallel data processing or handling network connections.

      This release also adds a streaming JSON package, a bunch of safety checks (escape analysis, leak checking, nil-pointer panics, stack traces), and proper so test and so bench commands.

      Threads • Channels • Worker pools • Sharing state • JSON • Safety net • Tooling • Wrapping up

      Threads The new conc package is the foundation. It provides real OS threads, backed by pthreads. If you're familiar with Go's goroutines, the code will look similar — but there are some important differences. // greet prints a label three times. func greet(arg any) any { from := arg.(string) for i := range 3 { println(from, "->", i) } return nil } func main() { // Run greet on a separate OS thread, concurrently with main. name := "thread" th := conc.Go(greet, name) // Wait blocks until the thread finishes. th.Wait() println("done") } thread -> 0 thread -> 1 thread -> 2 done Solod doesn't support closures, so conc.Go takes a function and an any argument, instead of just a func() like you'd expect in Go. Other important differences: starting an OS thread isn't free, and you always have to Wait on it (or Detach it), or it will leak. That makes conc.Go a good fit for a small, fixed number of long-lived threads — but not for thousands of short-lived tasks. For those cases, it's better to use a pool (shown below). Channels Threads in Solod communicate with each other through channels, like goroutines in Go. A channel carries values of a specific type. By default, sending or receiving on a channel blocks until both sides are ready, so a channel also works as a synchronization point. // ping sends a single message on the given channel. func ping(arg any) any { messages := arg.(*conc.Chan[string]) messages.Send("ping") return nil } func main() { // An unbuffered channel (buffer size 0): each send blocks // until a receiver is ready to take the value. messages := conc.NewChan defer messages.Free() // Launch a thread that sends "ping" into the channel. th := conc.Go(ping, &messages) defer th.Wait() // Receive the message and print it. var msg string messages.Recv(&msg) println(msg) } ping A couple of So-specific moments here. When you create a channel, you give it an allocator (mem.System in this case), and you call Free when you're done with it. Also, Recv writes to a pointer you pass in, instead of returning the value directly. It returns a bool, which is false when the channel is closed and empty. So, a typical for msg := range ch loop in Go becomes for ch.Recv(&msg) { ... } in Solod. Allocators are a key concept in Solod. The language doesn't allow hidden heap allocations, so any function that needs to allocate memory must take an allocator (the mem.Allocator interface) as its first argument. Buffered channels can hold a limited number of values without having a receiver ready — just pass a non-zero size with NewChan. If you don't want to block forever, use RecvTimeout or SendTimeout with a duration. They return conc.Ok or conc.Timeout instead of getting stuck. Worker pools

      Threads are expensive, so spawning one per task doesn't scale. For handling many short-lived tasks, use conc.Pool: it uses a fixed number of worker threads that take tasks from a queue.

      // job holds input and the result.
type job struct {
    id     int
    result int
}

// process handles one job.
func process(arg any) {
    j := arg.(*job)
    time.Sleep(100*time.Millisecond)
    j.result = j.id * 2
}

func main() {
    // A pool of 4 worker threads. Each submitted job is handled
    // by the next available worker.
    pool := conc.NewPool(mem.System, conc.PoolOptions{NumThreads: 4})
    defer pool.Free()

    // Submit 8 jobs. Each writes into its own struct, so keep
    // the structs alive in a slice until the jobs finish.
    start := time.Now()
    jobs := make([]job, 8)
    for i := range jobs {
        jobs[i].id = i + 1
        pool.Go(process, &jobs[i])
    }

    // Wait until all submitted jobs have finished.
    pool.Wait()

    for i := range jobs {
        println("job", jobs[i].id, "->", jobs[i].result)
    }
    elapsed := time.Since(start) / 1_000_000
    println("took", elapsed, "ms")
}



job 1 -> 2
job 2 -> 4
job 3 -> 6
job 4 -> 8
job 5 -> 10
job 6 -> 12
job 7 -> 14
job 8 -> 16
took 200 ms

      pool.Wait() works similar to Go's WaitGroup.Wait — it blocks until all submitted jobs are finished. This program takes about 200 ms to run (even though there's 800 ms of total work), because 4 workers run concurrently.

      You might think OS threads are much slower than Go's goroutines, but for pools, that's not the case. On realistic workloads, conc.Pool is usually only about 10% slower than Go, whether the tasks are CPU-bound or waiting on I/O. Channels are a different story: handing off work between threads requires a kernel wakeup, while Go does this in user space, so it can be several times slower. Check out Go-flavored concurrency in C for more details.

      Sharing state One way to share state in Solod is by using channels to communicate it. However, sometimes you just need a shared counter or a lock. For that, the new release introduces the sync and sync/atomic packages. Here's an example of an atomic counter being updated by 50 tasks running on 4 threads: // increment atomically increases the shared counter 1000 times. func increment(arg any) { ops := arg.(*atomic.Uint64) for range 1000 { ops.Add(1) } } func main() { // An atomic value is safe for concurrent reads and writes. var ops atomic.Uint64 pool := conc.NewPool(mem.System, conc.PoolOptions{NumThreads: 4}) defer pool.Free() // 50 tasks, each incrementing the counter 1000 times. for range 50 { pool.Go(increment, &ops) } pool.Wait() println("ops:", ops.Load()) } ops: 50000 A regular int incremented with ops++ would cause a data race and give a different result each time. Here, the result is exactly 50,000 on every run, thanks to the atomic Uint64 counter. The atomic package provides Int64, Uint64, Bool, and Pointer[T] types, all of which are lock-free and safe for concurrent use. For anything more complex than a counter, use sync, which provides Mutex, Cond (a condition variable), and Once (runs a function exactly once). One thing to watch out for: unlike Go, a So mutex's zero value isn't ready to use — you need to Init it before locking and Free it when done. var mu sync.Mutex mu.Init() defer mu.Free() mu.Lock() defer mu.Unlock() // ... critical section ... JSON Go's encoding/json relies on reflection to marshal arbitrary structs. Solod has no reflection, and uses a different approach: a token-level API. You read and write one JSON token at a time, and the Encoder and Decoder types take care of the syntax — adding commas and colons, checking UTF-8, and rejecting bad input. Encoding is done through a series of calls that match the structure of your document: out := make([]byte, 256) sb := strings.FixedBuilder(out) enc := json.NewEncoder(&sb) enc.BeginObject() enc.Str("name") enc.Str("Alice") enc.Str("age") enc.Int(25) enc.EndObject() enc.Flush() println(sb.String()) {"name":"Alice","age":25} Decoding pulls one validated token at a time with Next. You can check each token with Kind and read its value using typed getters like Str, Int, or Bool: src := `{"name":"Alice","age":25}` dec := json.NewDecoder(mem.System, []byte(src)) defer dec.Free() var name string var age int64 dec.Next() // the opening { for dec.Next() && dec.Kind() == json.KindString { switch dec.Str() { case "name": dec.Next() name = dec.Str() case "age": dec.Next() age = dec.Int() default: dec.Next() dec.Skip() } } println(name, age) Alice 25 This is a simplified example that works only because the decoder doesn't allocate any memory. In a real-world situation, you'd need to use an allocator. The decoder works the same way whether you're using an in-memory document (NewDecoder) or reading from a stream with an io.Reader (NewReader). This means you can decode data directly from a source without having to buffer the entire message first. Both the encoder and decoder use minimal memory and will reject invalid JSON or non-UTF-8 strings. As you can see, API is low-level and not nearly as ergonomic as it is in Go, especially when it comes to decoding. But on the bright side, it's 10 times faster and almost doesn't allocate, unlike in Go. Safety net Solod compiles to plain C, which is fast but not very forgiving: if you use an out-of-bounds index, dereference nil, or divide by zero, you get undefined behavior that could crash the program or silently give wrong results. The new release addresses some of these issues. Escape analysis. Returning a pointer to a stack-allocated value is a classic C footgun. So now catches the common cases at compile time: type Point struct{ x, y int } func newPoint(x, y int) *Point { return &Point{x: x, y: y} // ^ compile-time error: stack-allocated // value escapes function frame } func main() { p := newPoint(3, 4) println(p.x, p.y) } so run: /tmp/sandbox/main.go:26:12: stack-allocated value escapes function frame return &Point{x: x, y: y} ^here (exit status 1) While the escape analyzer doesn't catch every case, it's still quite useful in practice. I actually found a couple of dangling pointers in the standard library code with it, even though I was sure there weren't any. Leak detection. Solod has no garbage collector, so a forgotten Free is a real memory leak. mem.Tracker helps catch these leaks: it wraps an allocator and keeps track of every allocation and free that goes through it. This way, you can monitor the program's memory usage in real time instead of guessing. Wrap mem.System once, allocate memory through the tracker, and have a background thread log the stats at regular intervals: // monitor periodically logs live allocation stats. func monitor(arg any) any { t := arg.(*mem.Tracker) for { time.Sleep(100 * time.Millisecond) s := t.Stats() println("live:", s.Mallocs-s.Frees, "allocations,", s.Alloc, "bytes") } return nil } func main() { // Wrap the system allocator to count every allocation and free. heap := &mem.Tracker{Allocator: mem.System} // Watch memory from a background thread. conc.Go(monitor, heap).Detach() // Allocate through heap so the monitor sees it. for i := range 10 { v := mem.Alloc // intentionally not freeing it *v = i time.Sleep(50*time.Millisecond) } // ... } live: 2 allocations, 16 bytes live: 4 allocations, 32 bytes live: 6 allocations, 48 bytes live: 8 allocations, 64 bytes live: 10 allocations, 80 bytes The tracker is lock-free and only uses a few atomic operations for each allocation, so it's cheap enough to keep enabled in production. Nil-pointer panics. If you try to dereference a nil pointer, it will cause a panic at runtime instead of a raw segmentation fault: type Rect struct{ width, height int } func (r *Rect) area() int { return r.width * r.height // ^ runtime error: nil pointer dereference } func main() { var r *Rect println(r.area()) } panic: nil pointer dereference Stack traces. When a program panics, the -panic flag controls what happens next: so run -panic=trace . # print a stack trace, then exit(1) - the default so run -panic=exit . # just exit(1) after the message so run -panic=abort . # raise SIGABRT for a debugger or core dump Stack trace frames represent each function in the call chain: func main() { Work() } func Work() { res := Calc(42) println(res) } func Calc(x int) int { if x == 42 { panic("can't handle 42") } return x * 2 } panic: can't handle 42 /tmp/solod_build764532392/main.c:27 (func main_Calc) /tmp/solod_run1106942066(main_Calc+0x51) /tmp/solod_run1106942066(main_Work+0x12) /tmp/solod_run1106942066(main+0x9) The same system handles assertions like slice bounds, index-out-of-range, c.Assert, and similar checks. Instead of calling C's assert, they panic in a way that respects the -panic flag. There's also a new -sanitize flag that enables C sanitizers (address and undefined by default) to help you catch more issues during development: so run -sanitize -panic=abort example/play Tooling

      'so test' and 'so bench'. Solod now has built-in test and benchmark runners. so test finds TestXxx(t *testing.T) functions in a package's test subdirectory, creates a runner, transpiles it, and runs it. so bench does the same for BenchmarkXxx(b *testing.B).

      A typical package layout with tests and benchmarks looks like this:

      so/uuid
├── bench
│   ├── main.go
│   └── uuid.go
├── test
│   ├── main.go
│   └── uuid.go
└── uuid.go

      There's also a quick check for memory leaks: t.Allocator() gives you a tracking allocator (described in the 'Safety net' section above), and the test will fail if anything allocated with it isn't freed by the end of the test.

      === RUN   TestAlloc
    memory leak: 1 unfreed allocation(s), 16 byte(s)
--- FAIL: TestAlloc

      Fuzzing. Since Solod is a strict subset of Go, any So package is also a valid Go package. This means you get Go's built-in fuzzer for free, making fuzz testing pretty easy. So's encoding/json package takes advantage of this by using Go's own encoding/json as an oracle, making sure that every JSON document accepted by So is also accepted by Go.

      Automatic linking. The new so:link directive lets a package specify which C library it needs, and so build gathers these libraries and passes them to the C compiler. The standard packages already use the new directive, so importing so/math links with -lm, and so/sync or so/conc links with -lpthread — you no longer have to set LDFLAGS manually.

      Wrapping up

      With v0.3, Solod reaches an important milestone: a program can now do multiple things at once. The JSON package gives programs a standard way to communicate, and the safety checks help prevent silent failures — both during development and in production.

      There's still a lot to do, of course. In the next release, the standard library will keep growing, and the language and tooling will get better to make programming in So more convenient and safe.

      If you're interested, take a look at So's readme — it has everything you need to get started. Or try So online without installing anything.

    6. 🔗 modem-dev/hunk v0.17.6 release

      What's Changed

      • Avoid loading OpenTUI’s embedded native library for headless commands, preventing temporary native-library artifacts from leaking during help, version, session, daemon, markup, and non-interactive pager operations by @benvinegar in #590
      • Optimize terminal cell-width measurement for faster rendering of diffs containing CJK, emoji, and other wide characters by @kazu728 in #586
      • Republish the 0.17.5 application changes as 0.17.6 with downloadable binaries for every supported platform by @benvinegar in #593

      Full Changelog : v0.17.4...v0.17.6

    7. 🔗 pydantic/pydantic-ai-harness v0.11.0 (2026-07-24) release

      What's Changed

      Full Changelog : v0.10.0...v0.11.0

  2. July 24, 2026
    1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-07-24 rss

      IDA Plugin Updates on 2026-07-24

      New Releases:

      Activity:

      • augur
        • 043ba9cb: ci: set dependabot cooldown to 10 days
        • b9a59184: ci: add zizmor action
        • c4ef72c6: ci: add dependabot cooldown
        • 820baa96: ci: remove unnecessary submodules from doc workflow
        • 92b5f497: Merge pull request #2 from 0xdea/dependabot/cargo/anyhow-1.0.104
        • 5d82557b: Merge pull request #3 from 0xdea/dependabot/github_actions/actions-de…
        • 16609f77: ci: bump the actions-dependencies group with 3 updates
        • 1cdd3421: chore: bump anyhow from 1.0.103 to 1.0.104
        • 6e7f17c9: ci: add cargo-audit and dependabot config
      • capa
        • c1e7510d: build(deps): bump ws from 8.17.1 to 8.21.1 in /web/explorer (#3126)
        • cce0431d: Sync capa-testfiles submodule
        • 0683946f: Sync capa rules submodule
        • 04170f01: Sync capa rules submodule
        • db309bc2: Merge pull request #3131 from mandiant/dependabot/npm_and_yarn/web/ex…
        • 9cec0cd3: Merge pull request #3130 from mandiant/dependabot/npm_and_yarn/web/ex…
        • dafe1a7a: build(deps): bump pyasn1 from 0.6.3 to 0.6.4 (#3129)
        • 23ab04c6: build(deps): bump postcss from 8.5.15 to 8.5.23 in /web/explorer
        • 1561d891: build(deps-dev): bump js-yaml from 4.2.0 to 4.3.0 in /web/explorer
        • 4dd9274d: build(deps): bump python-flirt from 0.9.2 to 0.10.0 (#3128)
        • 5fe45bb9: build(deps-dev): bump mypy from 2.1.0 to 2.3.0 (#3127)
      • disrobe
        • 05b7022b: native: decode aarch64 scalar float and double registers, moves, load…
        • 6fd9f9da: native: reject an aarch64 high-half multiply whose operands are not 6…
        • e4c74f58: native: decode aarch64 rbit so trailing-zero count recovers, and reco…
        • a3369ef7: native: decode aarch64 rev, clz, umulh and bfi so byte-reverse, leadi…
        • 1d72b8d3: native: lift the aarch64 64-bit d-register post-index vector load and…
        • 05401791: native: recover the aarch64 vector lane insert as a read-modify-write…
        • 3324488b: native: rustfmt the recovery probe test
        • 23c61865: native: track the aarch64 recovery corpus, its clang generator, a non…
        • b4b42c63: native: recover the aarch64 conditional compare so a branchless short…
        • 647f99eb: native: recover the aarch64 signed-overflow condition so an adds-set …
        • 46ea21d0: native: lift the aarch64 sign-extended register add so a 32-bit index…
      • ffxiv_bossmod
      • haruspex
        • 89c46d0c: ci: set dependabot cooldown to 10 days
        • 0031da21: ci: add zizmor action
        • b90f9715: ci: add dependabot cooldown
        • 91965cc4: Merge pull request #6 from 0xdea/dependabot/cargo/thiserror-2.0.19
        • cb0d1c51: Merge pull request #4 from 0xdea/dependabot/cargo/anyhow-1.0.104
        • 908df22b: Merge pull request #5 from 0xdea/dependabot/github_actions/actions-de…
        • c28e3f8c: chore: bump thiserror from 2.0.18 to 2.0.19
        • 8bf08534: ci: bump the actions-dependencies group with 3 updates
        • d156dd20: chore: bump anyhow from 1.0.103 to 1.0.104
        • 15f19b8a: Create dependabot.yml
        • c38ef554: ci: add cargo-audit and dependabot config
      • ida-pro-mcp
        • 9236fc62: Merge pull request #478 from NeKroFR/fix/476-stale-strings-cache
        • 060d15d3: Merge pull request #488 from Zzoomrus/fix/idalib-sigterm-deadlock
        • b3cb7e5c: ci: allow approved fork PR checkout
        • 492a569f: fix(idalib): avoid SIGTERM/SIGINT handler deadlock in idalib_server
      • ida-pro-mcp
        • c798aee1: Make blackboard updates merge evidence under a write lock.
        • 8eebb592: Bind truncation tokens to the owning MCP connection.
        • 0ef263f8: Require risk_ack on mutating ops and expose session health.
      • IDAPluginList
        • 3f2bc811: chore: Auto update IDA plugins (Updated: 19, Cloned: 0, Failed: 0)
      • mcrit-plugin
        • fa5fc331: defer MCRIT GUI imports until form use
      • rhabdomancer
        • 8d0eb6b0: ci: set dependabot cooldown to 10 days
        • 64438a26: ci: add zizmor action
        • cb6b13f8: ci: add dependabot cooldown
        • 5eb6bc90: Merge pull request #3 from 0xdea/dependabot/cargo/anyhow-1.0.104
        • 82036e63: Merge pull request #4 from 0xdea/dependabot/cargo/serde-1.0.229
        • 9945395b: Merge pull request #5 from 0xdea/dependabot/github_actions/actions-de…
        • c77c52d3: ci: bump the actions-dependencies group with 3 updates
        • 1edb0ded: chore: bump serde from 1.0.228 to 1.0.229
        • c5ebc34e: chore: bump anyhow from 1.0.103 to 1.0.104
        • fa95ed1a: ci: add cargo-audit and dependabot config
      • twdll
        • 79888454: docs: generate docs
        • 2432cdd3: fix: cleanup for proper import of twdll
        • 95cfc438: tools: set cpu affinity for win11
    2. 🔗 r/reverseengineering Reverse-engineered CME's undocumented USB-MIDI config protocol (U6MIDI Pro / U2MIDI Pro) off the wire — full byte map + a public-domain codec rss

      submitted by /u/wmellema
      [link] [comments]

    3. 🔗 modem-dev/hunk v0.17.5 release

      chore(release): add 0.17.5 benchmark snapshot

    4. 🔗 r/reverseengineering Fortinet ppl bypass rss

      submitted by /u/nanaynunay
      [link] [comments]

    5. 🔗 idursun/jjui v0.10.9 release

      A release with per-file diff navigation, targeted bookmark pushes, filtering for changed files and choice dialogs, and adaptive light and dark themes.

      Features

      Browse Individual Files in the Diff Viewer

      Press ctrl+t in the diff viewer to choose a changed file and show only its diff. Select (all files) to restore the complete diff.

      Use [ and ] to move directly to the previous or next changed file. Navigation wraps at either end of the file list and is available for revision, Details, Diff Range, and Evolog diffs.

      Push Bookmarks from Selected Changes

      The Git menu can now push all eligible bookmarks from the highlighted revision or a multi-selection in one command. Open the menu with g, press p to show push commands, then press b.

      The command includes non-conflicted local bookmarks that are new or tracked on the selected remote and deduplicates bookmark names across the selected changes.

      (#701, #702, #715, #716)

      Adaptive Light and Dark Themes

      Theme files can now define shared colors with separate light and dark overrides in a single file. Selected backgrounds can also be blended toward the active component or terminal background, with a global or per-appearance strength configured through ui.background_blend.

      For example, a theme can share role styles while changing the selected background and blend strength for each terminal appearance:

      [colors]
":selected" = { bold = true }
"revset completion text" = { fg = "green" }
"revset completion text:selected" = { fg = "bright green" }

[light]
background_blend = 0.2

[light.colors]
":selected" = { bg = "white" }

[dark]
background_blend = 0.4

[dark.colors]
":selected" = { bg = "bright black" }

      The active theme's blend strength can also be overridden from config.toml:

      [ui]
background_blend = { light = 0.2, dark = 0.7 }

      Selected rows blended against different component backgrounds

      jjui queries the terminal background and ANSI palette when blending is enabled and reapplies the active theme when the terminal appearance changes.

      Theme selectors now support the :selected suffix, including role-specific selectors such as revset completion text:selected. The legacy selected selector syntax remains supported.

      (#406, #637, #668, #712)

      Improvements

      Filter Changed Files in Details

      Press / in the Details view to filter changed files by a case-insensitive path substring. Matching text is highlighted, and existing file selections are preserved while filtering.

      image

      Press enter to keep the filter active or esc to clear it.

      Filter Any Choice Dialog

      Press / to filter any choice dialog, including dialogs created by Lua scripts. The obsolete filter option has been removed from the Lua choose() helper.

      (#717)

      Fixes

      Selected Bookmark Push Eligibility

      Fixed selected bookmark pushes so local bookmarks that exist on the chosen remote but are not tracked there are not included.

      Selected Theme Styles

      Selected rows now preserve role-specific styles for text, dimmed content, and matched text. Git and Bookmarks remote selectors also receive the correct scoped styles, and custom themes no longer inherit unspecified colors from the built-in theme.

      Notes

      Minimum Supported jj Version

      jjui now requires jj v0.37 or later because the revision log uses the change_offset template keyword introduced in v0.37.

      (#714)

      What's Changed

      New Contributors

      Full Changelog : v0.10.8...v0.10.9

    6. 🔗 3Blue1Brown (YouTube) The 64 sugar cubes puzzle rss

      See all monthly puzzles: https://momath.org/mindbenders/

    7. 🔗 r/reverseengineering The quirks of CPU extended mode in “Comanche: Maximum Overkill” (1992) rss

      submitted by /u/alberto-m-dev
      [link] [comments]

    8. 🔗 pydantic/monty v0.0.19 - 2026-07-24 release

      What's Changed

      New Contributors

      Full Changelog : v0.0.18...v0.0.19

    9. 🔗 r/reverseengineering Workshop map for MECCHA CHAMELEON is a malware dropper (full breakdown) rss

      submitted by /u/feintbe
      [link] [comments]

    10. 🔗 earendil-works/pi v0.82.0 release

      New Features

      • Constrained tool sampling — Tools can prefer or require strict JSON Schema sampling or use OpenAI Lark/regex grammars, with model capability metadata preventing unsupported requests. See Constrained Sampling for Tools.
      • OpenRouter and Kimi Code sign-in — Use /login to authorize OpenRouter or a Kimi Code subscription without manually configuring API keys. See OpenRouter.
      • Session-aware, streaming bash integrations — Bash tools receive current session/model metadata, while direct RPC bash commands stream correlated output. See Bash Tool Session Environment and RPC bash events.

      Added

      • Added inherited Tool.constrainedSampling with strict JSON Schema (prefer/require) and OpenAI Lark/regex grammar variants across OpenAI, Anthropic, Amazon Bedrock, Google Gemini, and Mistral. See Constrained Sampling for Tools.
      • Added inherited supportsGrammarTools and supportsStrictTools compatibility flags, expanded supportsStrictMode coverage, and generated model capability metadata to gate constrained sampling.
      • Added inherited Kimi Code subscription OAuth login for the Kimi For Coding provider, including device authorization and automatic token refresh (#6935 by @zaycruz).
      • Added inherited OpenRouter OAuth PKCE login through /login, minting a user-controlled API key. See OpenRouter (#6927 by @rsaryev).
      • Exposed PI_SESSION_ID, PI_SESSION_FILE, PI_PROVIDER, PI_MODEL, and PI_REASONING_LEVEL to commands run by built-in and factory-created bash tools. See Bash Tool Session Environment.
      • Added streaming bash_execution_update events for direct RPC bash commands, correlated with request IDs. See RPC bash events (#6971 by @ananthakumaran).

      Changed

      • Changed inherited generated model catalogs to expose only provider-verified reasoning effort levels from models.dev (#6928 by @davidbrai).

      Fixed

      • Fixed inherited DNS lookup failures such as getaddrinfo, ENOTFOUND, and EAI_AGAIN to trigger automatic assistant retries (#6946 by @christianklotz).
      • Fixed inherited OpenRouter Anthropic cache breakpoints to advance through tool results and enabled cache control for ~anthropic/*-latest aliases (#6941 by @mteam88).
      • Fixed inherited OpenAI Codex WebSocket sessions to retry once without a missing previous-response continuation after previous_response_not_found errors (#6955 by @davidbrai).
      • Fixed TUI debug and crash logs to respect custom agent directories instead of always writing under ~/.pi/agent (#6958 by @davidbrai).
      • Fixed slow Ctrl+G external-editor startup when the system temporary directory contains many entries (#6903 by @christianklotz).
      • Fixed startup resource display to preserve relative paths for sibling npm extensions loaded by a package (#6964 by @davidbrai).
      • Fixed compaction and branch-summary requests to use fresh routing session IDs with prompt caching disabled where supported (#6618 by @tmustier).
      • Fixed explicit self-updates when PI_SKIP_VERSION_CHECK is set (#6977).
      • Fixed scoped model IDs containing brackets to resolve as literal exact matches before glob matching (#6210).
      • Fixed inherited OpenAI and Anthropic provider retry waits to honor abort signals and configured delay limits (#6980 by @petrroll).
      • Fixed fresh installs from preferring bundled model catalogs over newer remote catalogs because package file mtimes were newer (#7016 by @davidbrai).
      • Fixed inherited editor scroll indicators overflowing narrow terminals (#7015 by @christianklotz).
      • Fixed llama.cpp models to use the loaded context window as their output token limit instead of capping it at 16K (#7034 by @christianklotz).
      • Fixed release source archives to include the generated provider model data used to build standalone binaries.
      • Updated the packaged protobufjs dependency to 7.6.5 to address GHSA-j3f2-48v5-ccww (#7005).
      • Fixed /copy on Wayland to fall back to X11 or OSC 52 when wl-copy fails (#7009 by @rkfshakti).
      • Fixed /model to reload updated models.json configuration when opening the model picker (#6999).
    11. 🔗 r/reverseengineering Escaping Claude Cowork’s local VM sandbox via CVE-2026-46331 rss

      submitted by /u/natcoba
      [link] [comments]

    12. 🔗 @binaryninja@infosec.exchange Last chance to register for our Firmware Reverse Engineering class next week! mastodon

      Last chance to register for our Firmware Reverse Engineering class next week! Some embedded architectures are completely unlike what we're used to from x86, ARM, or MIPs, and we want you to know about them: https://shop.binary.ninja/products/fre- july-26

      https://www.youtube.com/shorts/0AQPnGtivko

    13. 🔗 Armin Ronacher Codeberg Divides rss

      Codeberg recently changed its terms to exclude projects that are largely written with generative AI. Since I want GitHub to face competition I have thoughts.

      Codeberg is entirely within its rights to do this. It is an association with members and a democratic process, and that process produced a result. But democracy is a way of making a decision, not a guarantee that the decision is inclusive, wise, or even good for the people already depending on it. A majority can still decide that certain projects and people no longer belong.

      GitHub's governance has never been democratic and there is plenty about the platform that I dislike. Yet democracy is not the main property I need from infrastructure. I need it to be predictable, dependable, and reasonably neutral towards the legal Open Source software hosted on it. A democratic provider without a clear constitution can be worse at those things than a corporation.

      The actual wording makes this more difficult. The terms prohibit projects that mostly consist of code written by generative AI tools. In an actively developed codebase, what does "mostly" mean, and who can still tell? I could not reliably assign authorship percentages to many of my own recent projects. The line is open to interpretation precisely where it needs to be enforceable. In practice the center will probably lose out, as it has a bias.

      A harsher line would probably be preferable. If Codeberg wants no LLM involvement, it should say so. If it wants to prevent autonomous repository spam and abusive resource consumption, it should write rules for those instead. The current middle ground delegates too much of the policy to moderators and community norms. I'm currently assuming the community around it draws a much harsher social boundary, making projects and maintainers unwelcome even when they technically comply.

      It is a real shame that the Open Source and Free Software communities are splitting this deeply over LLMs and agents. There are serious questions about copyright, labor, energy use, slop, and maintainers drowning in generated contributions. But these tools are also becoming part of how software is made. The Open Source world needs to figure out how to engage with that future, not just divide into camps. More importantly, LLMs if done and used well, should be welcome to all of us. They could be used to reclaim control and power, away from large corporations and institutions.

      As I mentioned before, I want GitHub to face true competition in the Open Source space. I would particularly like some of it to come from associations rather than another large corporation. As a European project, Codeberg naturally matters to me even more. It can choose to be a smaller community with a stronger political identity, but that is a different ambition from being a broad and dependable European alternative to GitHub.

      I wish Codeberg were more forward-looking here: willing to host the Open Source software of tomorrow, not only software made in the ways its community approves of today. It has every right to make the choice it made, but I just do not think it is a good one.

    14. 🔗 New Music Releases Above & Beyond - One Mix with Above & Beyond rss

      Above & Beyond - a new release is available:

      • 2026-07-24: One Mix with Above & Beyond (Album)

      Amazon: Canada | Deutschland | France | United Kingdom | United States

      Visit muspy for more information.

    15. 🔗 New Music Releases The Revivalists - Get It Honest rss

      The Revivalists - a new release is available:

      • 2026-07-24: Get It Honest (Album)

      Amazon: Canada | Deutschland | France | United Kingdom | United States

      Visit muspy for more information.

    16. 🔗 New Music Releases The HU - Hun rss

      The HU - a new release is available:

      • 2026-07-24: Hun (Album)

      Amazon: Canada | Deutschland | France | United Kingdom | United States

      Visit muspy for more information.

    17. 🔗 exe.dev tailmix: Connect to Multiple Tailnets at Once rss

      Tailscale is one of those magical technologies that I can no longer imagine living without. Its use cases range from homelab setups to enterprise workloads spread across complex, disparate environments. At exe, we use it to connect much of our internal infrastructure.

      That said, there are points of friction. One of my pet peeves is having to switch tailnets whenever I want to briefly connect to Home Assistant or Frigate to see who’s at the door while working on exe’s infrastructure. Tailscale’s fast user switching helps, but switching still disconnects one tailnet before connecting the other. That disrupts existing connections, takes a few seconds, and requires me to remember to switch back.

      Why can’t I just be connected to multiple tailnets at the same time?

      A few technical complications make it tricky, starting with the fact that Tailscale allocates IPv4 addresses independently within each tailnet. This means two nodes in two different tailnets can end up with the same IPv4 address. If both tailnets were connected simultaneously, the address alone wouldn’t tell the client which node I intended to reach.

      I could disable IPv4 and use IPv6 exclusively, but that still doesn’t work everywhere. It’s getting better, but the long tail is, well, long. Disabling IPv4 requires updating the Tailscale policy file and passing some pain along to my teammates, which feels unjustified.

      Node sharing has similar challenges. Tailscale does the work of making sure those IPs don’t collide, but it requires that I be an admin on both tailnets, and I’d have to individually share every device I wanted to reach. As my kid is fond of saying: I don’t want to!

      A couple of weeks ago, I wondered whether I could have an agent write me a new Tailscale client that would let me connect to multiple tailnets at once. As usual, I spun up a new VM on exe and told Shelley about my problem, and we went back and forth on the design until I was convinced the solution would work for the vast majority of use cases.

      The solution was fairly straightforward: spin up a couple of tsnet.Server instances, put them behind a single TUN interface, assign each peer node in each tailnet a new IPv4 from a locally configured pool such as 10.58.0.0/16, and hijack MagicDNS to return those IPs. Traffic sent to one of them is then routed through the corresponding tailnet.

      It worked the first time I tried it. All of the Tailscale policies worked just as they should, and I didn’t have to implement any of that, as the upstream tsnet.Server is a full-fledged Tailscale client already.

      The result is tailmix, an independent, open-source client that lets one machine connect to multiple tailnets simultaneously. The source, installation instructions, and current limitations are all in the repository—or you can ask Shelley to tell you all about it.

      I still have two tailnets, two identities, and two separate sets of policies. The difference is that now my laptop no longer makes me choose between them.

  3. July 23, 2026
    1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-07-23 rss

      IDA Plugin Updates on 2026-07-23

      New Releases:

      Activity:

      • augur
      • binsync
        • 0b1b449b: Allow the server to correctly track which users are connected. (#519)
      • DeepExtractIDA
        • 7dbdbbb7: Add v3 schema (function addresses, imports/globals tables, EA-prefixe…
      • disrobe
        • e9361488: harden pyfreeze parser fuzz coverage
        • 313fddfc: native: keep sign and zero extended aarch64 indexes out of array aggr…
        • 34009fa0: native: model aarch64 sign and zero extended 32-bit index registers s…
        • b40470b6: harden scriptlang parse paths
        • b1ac85f9: native: decode aarch64 scaled register-index addressing [base, xindex…
        • 315fa0aa: native: accept aarch64 bitmask and move immediates above the signed r…
        • c56a8857: native: decode aarch64 umull and smull as 32-by-32 into 64 widening m…
        • 5a959c91: native: decode the aarch64 vector bic as an elementwise and-not
        • 43c12a25: harden py disasm fuzz paths
      • haruspex
        • ae585c22: test: improve unit test names
      • hrtng
        • 59dba8e5: - autorename: revert "ignoring nice names"
      • ida-hcli
        • c80e825c: fix: address install script review findings
        • d9d446a0: fix: use direct GitHub download URLs in install script
        • 87aa5b36: fix: use None check for falsy plugin setting defaults in non-interact…
        • 489bc306: fix: rename running binary aside before replacing during update (#261)
        • 2bda7356: fix: detect existing install dir before attempting ida install
        • 6542169d: fix: skip repo fetch for plugin subcommands that don't use it
        • 5542eaff: Merge pull request #253 from HexRaysSA/gha-update
        • 841ca17e: Fix zizmor findings
        • 93d3ecb4: Update and pin GHA
      • IDA-Plugins
        • ba11c7d4: Add new plugins and extend existing analysis features
        • 65f6c8b7: Consolidate IDA plugins into a single repo
      • ida-pro-mcp
        • e2664060: Add host tests for recent isolation and safety fixes.
        • 4d5bc997: Fix disasm start address and funcs write synchronization.
        • d0a4dc4b: Scope insight indexes to sessions and IDBs.
        • fab177c7: Use high-entropy continuation tokens for truncation.
        • f9908f35: Isolate blackboard workspaces per analysis session.
        • 436c1394: Clarify agent contract docs and enforce SKILL sync.
        • 7538ef2e: Tighten batch and graph result semantics.
        • 6c4fe5d0: Align semantic indexing with search entry-EA windows.
        • 652ff78d: Fix blackboard scoping and workspace brief hygiene.
        • 1aa49846: Harden policy fail-closed paths and installer packaging
        • b26fcad1: Gate destructive session actions and fix high-impact tool crashes
        • 2341c843: Harden MCP session ownership for tools, switch, and background jobs
      • Luc-Nhan
        • 3dbaa907: feat(glm): distinguish Standard vs Coding Plan endpoints
        • ba459fab: Merge remote-tracking branch 'EliteClassRoom/master'
        • 0e11cde0: adding emulation to rikugan
        • 08e49f93: fix(settings): show GLM in provider dropdown and auto-config on select
        • 2e9abc07: feat(glm): add GLM-5.x reasoning resilience
      • plugin-ida
        • 67ec8db7: Merge pull request #171 from RevEngAI/refactor/v3-collections-endpoints
        • 8187b3f0: refactor(PLU-325): use v3 collections endpoint for search
      • quokka
        • 0f01c85b: Merge pull request #134 from DarkaMaul/dm/fix-115
        • 9220e374: Merge pull request #133 from DarkaMaul/test/relax-ida93-inport-control
      • ToCode
        • b6d7f1c3: Merge pull request #12 from buzzer-re/dev/fix-deadlock
        • 3839dd57: Make the atomic-write lock test type-check on Linux
        • 35b0f392: Fix Windows-only mypy and test failures so ci-local passes
        • ea741be8: Drop the redundant Command log line from the CLI export path
        • 301e0639: Retry atomic file replace to survive transient Windows locks
      • twdll
        • 3db4cf22: build(gh-actions): fix more submodules
    2. 🔗 modem-dev/hunk v0.17.4 release

      What's Changed

      • fix(ui): restore threaded rendering on macOS by @benvinegar in #539
      • fix(review): save draft notes exactly once under rapid Ctrl+S by @endotakuya in #581

      Full Changelog : v0.17.3...v0.17.4

    3. 🔗 crosspoint-reader/crosspoint-reader v1.5.0 release

      Summary

      This is one of the biggest updates we've shipped: new hardware support, faster loading on big books, offline dictionary lookups, and a UI overhaul.

      Seeed reTerminal Sticky support

      For the first time, CrossPoint is expanding beyond its original ESP32-C3 roots (XTeink X3/X4). We are officially introducing support for ESP32-S3 devices!

      • First Supported Device: The upcoming Seeed reTerminal Sticky
      • A huge shoutout to Seeed Studio for reaching out, sending test hardware, and being incredible partners throughout the process.
      • Get Yours: You can order a Sticky (Launching July 30th) at crosspointreader.com/devices using our affiliate link to support the project.

      Note

      The XTeink X4 Pro isn't supported in this build yet, but a dedicated release will follow once we've got hardware to test against.

      Big books open fast now

      Big books used to take minutes to open the first time. That's basically gone: sections index on demand in the background while you read, so books open in around 5 seconds. Page turns feel smoother too, from rendering and memory work throughout the app, and we fixed memory allocation and CSS parser bugs that were causing out-of-memory crashes on complex EPUBs.

      Offline dictionary lookups

      Drop a StarDict dictionary onto your SD card and you can look up words with no connection. Select a word, get the definition popup. There's a setup guide if you want to get one running.

      "What to read next"

      Finish an EPUB and CrossPoint looks at what's on your device and suggests something next, right on the end-of-book screen.

      Text settings got a rework

      Font and layout options now live in one menu, with a live preview so you can watch line spacing, margins, and font changes happen without leaving the settings screen.

      There's also a new selection popup. Any setting with three or more choices opens a dialog now instead of making you cycle through options one at a time.

      Arabic, Farsi, and Urdu

      1.4.0 added right-to-left text support. This one finishes the job for Arabic, Farsi, and Urdu: proper bidi handling and contextual glyph shaping, built-in fonts with full Arabic character sets, and the UI itself translated into Arabic.

      Everything else

      KOReader sync now handles custom sync servers, account registration, and metadata uploads. Wi-Fi should behave better — it reconnects to saved networks automatically, including hidden ones, and picks access points more sensibly. The web UI shows image previews in the file browser now and lists device serial numbers. OPDS downloads let you set your own folder and file format.

      We also added the Vollkorn serif font (grab it from Manage Fonts), cleaned up <br> handling and list bullet alignment, and expanded CSS text-decoration support.
      Translations got updates across Swedish, Italian, Spanish, Catalan, Valencian, Czech, Turkish, Portuguese (BR & PT), and Vietnamese, and we added brand new Norwegian Bokmål , Indonesian and Bosnian translations. Chinese entries are now shown correctly in the File Browser and chapters list.

      Note

      If you are upgrading from v1.0.0 or earlier , please upgrade to v1.4.1 first before installing the latest release. Skipping this step will cause your settings to be reset to their default values.

      What's Changed

      New Contributors

      Full Changelog : 1.4.1...1.5.0

    4. 🔗 r/reverseengineering Remus Stealer Analysis: Fileless Execution, In-Memory Payload Extraction & C2 Discovery rss

      submitted by /u/StructBreaker
      [link] [comments]

    5. 🔗 The Pragmatic Engineer The Pulse: New trend - concern about massive increase in code review load rss

      Hi, this is Gergely with a bonus, free issue of the Pragmatic Engineer Newsletter. In every issue, I cover Big Tech and startups through the lens of senior engineers and engineering leaders. Today, we cover one out of four topics of last week 's The Pulse issue . Full subscribers received the article below seven days ago. If you 've been forwarded this email, you can subscribe here .

      One thing I am hearing that's top of mind for many engineering leaders is what is being done to deal with the continuous increase in code review load. It's been a topic for a while, and more such conversations seem to be taking place.

      For me, it began in January, when Opus 4.5 and GPT 5.4 started to write more and better code at most companies. Around then, Director-level folks started talking about the bottleneck of building software moving from coding to the review phase.

      There 's been a boom in AI code review tools to deal with the increase in load since February, and an explosion of experimentation with and adoption of dedicated AI code review tools like CodeRabbit, Greptile, Qodo, SonarQube (now also Gitar). There's also tools offered by coding harnesses themselves like Claude Code review, Cursor review, GitHub Copilot review. And then tools previously not involved in code reviews - but which have context on the codebase - are also adding this, like Sentry 's Seer AI reviews, Linear code reviews.

      Larger companies are building in-house tools to improve the code review experience. Uber's Code Inbox is one case:

      altUber 's Code Inbox. From How Uber uses AI for software development

      Smart assignments are a feature inside Code Inbox for having reviews progress:

      altSmart assignment settings for Code Inbox

      Then there's Risk Profiles which estimate the impact of a change, and encourage devs to pay extra attention to risky ones:

      altCode Inbox tries to estimate the risk of a code change, and bring attention to it

      We covered how Uber uses AI for software development, and it's not just Uber: companies like Cloudflare (AI Code Reviewer), Faire (Fairey), and HubSpot (Sidekick) and many others have also built tools to make their code review flows more fluid, after finding that an in-house implementation worked better than integrating a vendor.

      Another approach is thinking about how to verify code, instead of reviewing. This is easier said than done; in theory, thorough testing should be able to verify that code works as expected. But how much testing is 'thorough'? What type of tests are we talking about? Integration and end-to- end as well? What about fuzz testing? Or formal methods? What about verifying that new tests exercise the functionality as expected? And how do we connect all of this with observability?

      Too much thorough code review is burning out engineers, and resulting in sub-par code reviews. I hear a lot anecdotally that devs see others as no longer able to review code with intent, whereby, if the AI code review has no real comments, they just approve it. Meanwhile, those devs who put the same effort and energy into code review as before feel overloaded by AI slop PRs sent their way.

      The problems exist, and the solutions feel more like experiments.

      What are you seeing inside your company, and how are you dealing with the increase in code reviews? Share your ideas for practical, workable "replacements"?

      Read the full issue of The Pulse this excerpt is from, or check out the latest The Pulse from today. Today's issue covers:

      1. Moving video podcasts off Spotify due to constant reliability issues
      2. "Kimi K3" moment & a US lobby for closed-source AI models
      3. AWS laughs off huge billing error
      4. Industry Pulse

      Read the full issue here

    6. 🔗 Hex-Rays Blog Teams: Git-native Versioning & Collaborative Reversing rss

      Teams: Git-native Versioning & Collaborative Reversing

      Teams is a collaboration add-on for IDA Pro recently revised to focus on two pillars: version control and team collaboration with features like Deep Links. It brings Git-based versioning and real-time sharing directly into IDA, so reverse engineering teams can work together on the same binaries without losing work, duplicating effort, or managing files manually.

    7. 🔗 @binaryninja@infosec.exchange Current Binary Ninja newsletter subscribers are automatically entered. New mastodon

      Current Binary Ninja newsletter subscribers are automatically entered. New subscribers who sign up during the giveaway will also be entered for remaining drawings. Sign up for our newsletter here: https://v35.us/dn6rcg5

    8. 🔗 @binaryninja@infosec.exchange 10 years ago today, we shipped the first build of Binary Ninja to our mastodon

      10 years ago today, we shipped the first build of Binary Ninja to our customers! We’re kicking off our anniversary celebration by giving away a Binary Ninja Non-Commercial license. See the full giveaway schedule: https://binary.ninja/10years

    9. 🔗 r/reverseengineering Transformers Forged To Fight Revival Offline Version Updated rss

      submitted by /u/GeamzAngryBirds1
      [link] [comments]

    10. 🔗 pydantic/pydantic-ai-harness v0.10.0 (2026-07-22) release

      What's Changed

      • feat: add ModalSandbox for isolated cloud sandboxes by @strawgate in #269
      • feat: Macroscope CLI code-review capability by @strawgate in #350
      • Fix step persistence snapshot after completed tool boundary by @nmoturi in #374
      • Fix ClampOversizedMessages clamping typed ToolCallPart subclasses (ToolSearchCallPart, LoadCapabilityCallPart) by @dsfaccini in #411
      • fix(memory): scope-qualify injection marker so multiple Memory capabilities coexist by @sevakva in #409
      • feat: add LocalStack capability for emulated AWS environments by @strawgate in #268
      • StepPersistence: drop the provider-validity gate, single error-save site, snapshot state classification by @dsfaccini in #412
      • Harden LocalStack capability after post-merge review by @dsfaccini in #425
      • docs(agent): capability CI scoping, post-merge resync, external-service refresh by @dsfaccini in #423
      • Fix release job silently skipping on tag pushes by @dsfaccini in #429
      • Actually fix release skipping on tag pushes: opt out of skipped-ancestor propagation by @dsfaccini in #430

      New Contributors

      Full Changelog : v0.9.0...v0.10.0

    11. 🔗 Console.dev newsletter Databasement rss

      Description: Database server backups.

      What we like: Manage database (MySQL, Postgres, MongoDB, SQLite, Redis, etc) backups through a web UI. Supports local, S3, SFTP locations and connections to sources through SSH. Can be automated via an API and MCP server.

      What we dislike: No fine-grained user permissions. UI looks a bit vibe-coded.

    12. 🔗 Console.dev newsletter Neko Master rss

      Description: Network traffic dashboard.

      What we like: Real time visualization of network traffic through a minimal PWA. Pulls data from the network gateway (OpenWrt, Linux, router, etc) through an agent or by directly connecting to the gateway. Runs as a simple container. Does domain, IP, proxy stats with trends.

      What we dislike: Data is stored in SQLite by default, which is a good place to start, but you can connect to Clickhouse for more robust storage.

    13. 🔗 Drew DeVault's blog AI in Linux rss

      The role of AI tools (LLMs, mainly) in Linux is under discussion, or it was, until Linus Torvalds “put his foot down” in support of the use of AI in Linux kernel development.

      I can identify two major ways in which AI is used for Linux kernel development: authoring code and reviewing code. There are, at the time of writing, just over 1,200 kernel commits with an “Assisted-by” tag, from September 2025 to the present, most of which indicate patches which were written or assisted by LLM tools.

      The second important use of AI for Linux comes with a new code review tool called Sashiko, which generates code reviews for patches considered for various subsystems. Sashiko ignited the current debate on AI in Linux because it pushes the envelope on AI in Linux: people who oppose or do not want to use AI could previously just refrain from using it to write their patches, but now there is a growing expectation that anyone who wants to contribute to Linux will have to interact with Sashiko or other AI tools like it to iterate on AI-generated feedback on their work.

      One of the major lines of this discussion in the Linux kernel community has been with respect to the ethical considerations of the use of LLMs. Linus shuts this line of reasoning down entirely, firmly grounding the discussion in technical merits and rejecting any political discourse on the matter:

      The kernel project has been and will continue to be about the technology.

      Sure, the social angle of working on open source is important and often a very motivating part of the project, but in the end that’s a side benefit, not the point of the project.

      This is NOT some kind of “social warrior” project, never has been, and never will be.

      In the kernel community we do open source because it results in better technology, not because of religious reasons.

      This argumentation is disingenuous and hypocritical. Linux is a political project and Linus is a political actor. Consider the use of the GPLv2 for licensing Linux. One can argue from technical merits – for instance, the copyleft nature of the GPLv2 pushes people, and in particular commercial entities, to upstream their drivers and other contributions into the Linux kernel. This contributes to the technical excellence for the kernel as a result.

      But is this not a political choice, and a political act? The purpose of this choice is to influence the behavior of others and to advance the interests of the kernel ahead of their own. And Linus stuck to this decision for political reasons when GPLv3 was introduced, reasoning from morality and ethics when objecting to the license and the manner in which it was deployed, and called for a tacit boycott of the FSF.

      Linus, and Linux, wields a tremendous degree of power and influence over the world, and it should be wielded responsibly. When Linus says the following:

      Linux is not one of those anti-AI projects, and if somebody has issues with that, they can do the open-source thing and fork it.

      Or just walk away.

      I find it completely disingenuous. Linus is surely aware that, for all practical purposes, Linux cannot be forked. It is the world’s largest software project, and one of the most well-funded, too. The institutional knowledge among its contributors, the prospect of keeping up with the blistering pace of change, or even putting together a group of people with the time and funding to understand and maintain even a fraction of the kernel’s code independently of upstream, is, quite simply, intractable. Linus knows, this, too – it’s an explicitly cited reason for decisions like the use of the GPL, GPL-only symbols, and the unstable internal kernel ABI: to make the process of independently maintaining a fork of the kernel as difficult as possible.

      People are right to petition Linux upstream to amend its behavior and policies before resorting to the impossible. Working on Linux requires practicing politics, both internally – see for example Linus’ response to the discussions around bcachefs, which had high technical excellence and low social/political competence – and at the intersection of Linux and the rest of the world. Therefore, we must table political, moral, and ethical arguments when we discuss how we go about the work. It’s a cheap, weak argument to direct the discussion away from political and ethical considerations when it wouldn’t serve your point and to table it when it would.

      I’m willing to believe that the LLM-powered Sashiko code reviews provide a lot of good insights. However, to address just one externality of this tool, consider that AI companies are driving up the price of consumer hardware. An AI powered code review may improve a patch, but that patch won’t be of much use to the increasingly large cohort of people who are being priced out of the hardware they could run Linux on to enjoy the better patch.

      Looking at it from another angle: how many tons of CO₂ added to the atmosphere or liters of fresh water supplies disrupted is a tolerable price for a better code review? Temperatures during heat waves are exceeding 50°C in India, causing tens thousands of deaths. The AI built-out is by far the fastest growing energy consumer in the world, and they’re being built with fossil fuels, or drawing green energy demand away from replacing the fossil fuels depended on by other industries. The same process is pricing regular people out of the energy they need to power their air conditioner during those heat waves and the technology it enables is pushing them out of the labor market and into poverty.

      These externalities are very real, and are affecting a lot of people, including Linux kernel contributors and maintainers, and their friends and families, who are trying to bring these problems to Linus’ attention.

      And what of the intangible effects of the use of these tools in Linux? Linux is lending some of the project’s immense influence towards legitimizing the makers of these tools, and Linus’ insistence on focusing narrowly on the technical applications of these tools is a generous gift to them. They will be sure to mention his support in boardrooms, meetings between lobbyists and governments, and anywhere else it will advance their interests.

      It’s fair to ask: what are those interests, and what are they doing with this influence?

      Photograph prominently featuring Mark Zuckerberg, Jeff Bezos and his wife, Sundar Pichai, and Elon Musk
      Google CEO Sundar Pichai pictured at Donald Trump’s inauguration, together with other influential commercial leaders in AI. Sashiko primarily depends on Google Gemini for Linux kernel code reviews.

      There are a lot of smart, passionate people who care about these kinds of questions. Where is the technical excellence in refusing to do this moral calculus, refusing to allow anyone else to do so, and driving away the talented Linux contributors who care about these problems? Linus Torvalds, the Linux community, and all of our communities should have the courage and insight to address these dimensions of the AI question honestly and in good faith.

    14. 🔗 Filip Filmar The FPGA Hardware Interview: A Topic Guide with Questions and Exercises rss

      Interviews for FPGA and digital-design roles draw from a stable, well-defined body of knowledge, yet candidates routinely stumble on it because the questions are asked crisply and must be answered under pressure. I am publishing a preparation guide for exactly that situation: a 29-page report, “The FPGA Hardware Interview”, organized as a sequence of topic reviews, each followed by interview-style questions with model answers and, for the design topics, coding exercises solved in both VHDL and SystemVerilog.

    15. 🔗 Ampcode News Event Driven Orbs rss

      Amp's orbs can now receive requests and react to events outside Amp.

      That means an orb can wake up when CI fails on GitHub, when someone opens a Linear issue, when a monitor raises an alert, or when an event arrives from Discord. If it can send an HTTP request, it can wake an orb.

      More Ways to Wake an Orb

      GitHub issues are just one example. You can use the same pattern to:

      • Investigate every CI failure on main and post the findings to Slack.
      • Watch for new releases of your dependencies, then review the changes and open an upgrade PR.
      • Start a fresh thread when someone opens a Linear issue, then comment with a fix or report.
      • Turn a bug report from Discord into a reproduction and pull request.
      • Resume a rollout when a deployment or security scan reports back.

      The event decides when the orb wakes up. You decide what it does next.

      From a GitHub Event to an Orb

      Here is the whole setup. Start a thread in an orb for your repository and tell Amp which events to watch and what to do with them:

      Prompt asking Amp to monitor GitHub issues and pull requests with a webhook

      Amp turns that request into a project-specific plugin. It scopes the listener to the repository and events you asked for, verifies GitHub's signature, deduplicates deliveries, and starts a read-only orb thread with trusted event metadata.

      Amp describing the GitHub webhook plugin it will build

      Then Amp loads the plugin and registers its durable endpoint:

      Amp registering the plugin's durable webhook endpoint

      If the orb's GitHub token can administer repository webhooks, Amp connects the endpoint for you. In this case it could not, so Amp gave us one manual step without printing the private URL or signing secret into the thread:

      Amp explaining the manual GitHub webhook configuration step

      A Wild Issue Appears

      Once the webhook is active, someone opens issue #57:

      GitHub issue 57 reporting a typo in a completion description

      GitHub sends the signed event to Amp. Amp verifies it and starts a fresh orb thread with the trusted repository, event, issue, and actor metadata. The issue itself remains untrusted input, not agent instructions:

      A new Amp thread created from a verified GitHub issue webhook

      The new thread inspects the current issue and relevant code, then reports what it found:

      Amp report confirming issue 57 as a low-impact UI typo

      The typo is real, appears once, and only affects secondary menu text. Now the same workflow runs for every issue and pull request event while the original orb sleeps.

      How It Works

      Webhooks work through the Amp Plugin API. When you ask Amp to listen for an event, it creates a plugin in the orb and calls amp.createWebhook to register a durable endpoint for that thread. Then it loads the plugin and gives you the URL to connect to GitHub, Linear, Discord, or another service. If the orb already has access, Amp can connect it for you.

      When a request arrives, Amp stores the event and wakes the orb. The plugin validates and filters the payload, then handles it using the instructions you gave Amp. The URL stays the same across plugin reloads and orb restarts, so the orb does not need to keep running while it waits.

      React to Events However You Want

      amp.createWebhook gives the plugin a handler, not a fixed workflow. That handler is ordinary TypeScript with access to the rest of the Plugin API. The handler can:

      • Continue the owning thread with its context intact by appending the event to ctx.thread.
      • Start a fresh thread in an orb with amp.getBuiltinAgent(...).createThread({ executor: 'orb' }).
      • Keep durable state so it can react every time, or handle one matching event and then stop listening.

      That is where the flexibility comes from. Tell Amp how you want to handle an event and it writes the handler that way. It can also call external APIs to post results back to Slack, Linear, GitHub, or wherever the work began. Return to the owning thread whenever you want to change the behavior.

      The webhook URL is a credential. Keep it private, and tell Amp to remove it when you no longer need it.

    16. 🔗 muffinman SpaceDeck X July devlog: upgrades, backgrounds, and more rss

      I've been developing SpaceDeck X since December last year. It started as me playing with a random framework I found fun, and it grew so much that I'm now working towards releasing it on Steam. I kept a devlog on Itch, but I feel like it is time to bring it to my own website. Especially considering that these updates are exclusive to the Steam version.

      I have a pretty clear vision for the release, and lately I've made amazing progress. Here are the major things I've made, in no particular order.

      Upgrades system

      The new upgrades system was brewing in my head for a long time. Honestly, I thought it would take me longer to implement it, but once I started, I got in the zone and built a completely new system.

      This is the new upgrades selection screen:

      New select an upgrade screen

      Compare it to the old one:

      Select an upgrade screen before the update

      Upgrades library

      Upgrades got their own library, so players can inspect and learn about all of them.

      New upgrade library screen

      In two days I managed to draw 44 upgrade icons. Some of them I just winged and now I'm retrofitting them to the actual game upgrades.

      Upgrade icons in aseprite

      Redesigned UI panels

      After making new upgrade cards, I got an urge to redesign some of the game's UI. I'm trying to avoid scope creep, but I had to create a way for the player to see their upgrades, so I decided to give a facelift to the deck panel as well.

      You can open both panels by holding Tab in the boss fight:

      New UI panels opened during a boss fight

      And they show automatically in the pause menu:

      New UI panels automatically open in the pause menu

      Ships

      Ships are not brand new, but in the last few weeks I tweaked their specific weapons and characteristics. It is still a work in progress, but all ships are functional and have their own quirks.

      All three ships shooting shown in the game level

      Backgrounds and shadows

      These are purely decorative, but I think they elevate the experience a lot. These background objects add more visual depth. They also change every few levels, giving the player a better sense of progression.

      For now I created two sets of backgrounds (the gray tech-industrial one and an Aztec/Protoss-inspired one). The plan is to have four or five for the full game. These are quite time consuming, but I enjoy doing pixel art.

      New backgrounds New backgrounds

      For the gray background set, I drew a tileset and I'm using Tiled to assemble them, while the Aztec ones are all drawn by hand.

      New backgrounds

      Other

      Run history is still in progress, but I have the base for the stats screen:

      Run stats screen

      I postponed it for months, and finally I created controller button customization:

      Controller buttons customization screen

      See you soon

      Ever since I started working on this game, I've been obsessed with game dev. You can probably tell from the fact that I haven't published almost any blog posts this year.

      That's why I'll keep these devlogs casual and try to post them more often.

  4. July 22, 2026
    1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-07-22 rss

      IDA Plugin Updates on 2026-07-22

      New Releases:

      Activity:

      • disrobe
        • cab04b7e: mobile: route arsc and axml chunk reads through the shared bytereader
        • 89e4cc6d: js: route sourcemap data-url decoding through the shared codec percen…
        • 513eb793: php: route urldecode/rawurldecode through the shared codec percent-de…
      • distro
        • e23820b9: Add container mode to restrict-egress (apply/off/status without systemd)
        • 6d9cc808: Show domain-to-IP mapping in restrict-egress status
      • ffxiv_bossmod
      • hrtng
      • ida-hcli
        • f8908d1d: Merge pull request #251 from HexRaysSA/fix/bundle-python3-dll-windows
        • a8cb563f: fix: bundle python3.dll in the Windows binary
        • 2d916e62: fix(asset): strip leading slash from key in asset API paths (#215)
        • 0067acbc: fix: add hcli/main.py so python -m hcli runs the CLI (#226)
        • 5dac83b4: fix: return argv tokens from get_hcli_command (was get_hcli_executabl…
        • 0b5d0cb7: Harden ida:// KE deep-link handler (RCE, path traversal, SSRF, drive-…
        • 679e0f56: fix: ida install -a/-accept-eula flag was inverting, skipping EULA a…
      • project
      • quokka
        • bb8dc9d6: Merge pull request #132 from quarkslab/dm/upgrade-protobuf
        • 6b45902c: Align Python package with protobuf 7.35
      • SignatureGenerator
      • Spectra
        • dff32c95: Skip exploration for non-analysis tasks
        • 93bb73fa: Skip exploration mode for non-code-analysis tasks
      • twdll
        • a8460bf3: docs: fix docs building
        • f5dbd420: build: fix CI submodules init
        • fbfc3418: chore: add AGENTS.md
        • 24cdb988: feat(wip): add campaign ui and world globals
    2. 🔗 Simon Willison OpenAI’s accidental cyberattack against Hugging Face is science fiction that happened rss

      This story is wild. The short version: OpenAI were running a cybersecurity test against an unreleased model, with the model's guardrail features turned off. Rather than solve the test, the model broke its way out of OpenAI's sandbox, then found exploits to break in to Hugging Face, all so it could cheat on the test by stealing the answers.

      Along the way it helped make the strongest case yet for how the imbalance of model availability is hurting our ability to secure our software.

      Here's what happened

      We currently have three documents to help us understand what happened here.

      1. ExploitGym: Can AI Agents Turn Security Vulnerabilities into Real Attacks? is a paper published on 11th May 2026 describing ExploitGym, a new eval suite for LLM-powered agent systems.
      2. Security incident disclosure — July 2026 by Hugging Face on 16th July 2026 describes how they detected an attack from an "agentic security-research harness - used LLM still not known" that breached some of their systems.
      3. OpenAI and Hugging Face partner to address security incident during model evaluation from OpenAI on 21st July 2026 confesses that it was their agent harness that did this, and that they're working with Hugging Face to clean up the mess.

      ExploitGym

      I hadn't seen the ExploitGym paper before and it's a really interesting one. Authors from UC Berkeley, the Max Planck Institute, UC Santa Barbara, and Arizona State designed a new benchmark for evaluating models on their ability to turn a reported vulnerability into a concrete exploit. OpenAI, Anthropic, and Google provided feedback and helped run the benchmark against their models.

      The benchmark "comprises 898 instances derived from real-world vulnerabilities that affected popular software projects" - including the Linux kernel and V8 JavaScript engine. The ExploitGym benchmark is available on GitHub.

      Here's the paragraph that best represents their benchmark results:

      Among all configurations, Claude Mythos Preview and GPT-5.5 achieve the highest success counts (157 and 120 successes, respectively), demonstrating that current frontier agents can exploit a substantial subset of real-world vulnerabilities under controlled conditions. GPT-5.4 also solves a notable 54 tasks, placing it in an intermediate tier. The remaining model–agent pairings solve fewer than 15 tasks each, underscoring that end-to-end exploitation remains challenging and sharply differentiates today’s frontier systems. Notably, Claude Opus 4.7 achieves fewer successes than Claude Opus 4.6 despite being a newer checkpoint, and does so at substantially lower cost on the full set. Trace inspection reveals that Claude Opus 4.7 and Gemini 3.1 Pro frequently conclude early after judging the target vulnerability non-exploitable.

      The paper also describes the approach they took to preventing the agents from cheating by going outside the parameters of the test. This becomes relevant in a moment!

      Outbound connections are restricted to a curated allowlist that permits routine package installation (Ubuntu apt repositories and PyPI) and fetching the toolchains required for building V8. All other external endpoints are blocked.

      The paper concludes with this (emphasis mine):

      Our results show that autonomous exploit development by frontier AI agents is no longer a hypothetical capability. While current agents are not yet reliable across all targets, they already exploit a non-trivial fraction of real-world vulnerabilities, including complex targets such as kernel components. This rapid emergence is itself a central finding, showing that capabilities that would have seemed implausible are now present in deployed frontier models.

      An important detail here: this paper isn't about discovering vulnerabilities; it's about being able to take those vulnerabilities and turn them into working exploits.

      When Anthropic first restricted access to Mythos back in April they talked about this capability as well. A model that can act on vulnerabilities is a lot more dangerous than one that can just discover them.

      One of the ways Fable differs from Mythos is that it's more likely to refuse to weaponize vulnerabilities in this way. I get the impression the US government did not understand that distinction when they banned Fable last month.

      The Hugging Face incident

      The first hint we got of the attack was in this blog post by Hugging Face on 16th July 2026:

      A malicious dataset abused two code-execution paths in our dataset processing (a remote-code dataset loader and a template-injection in a dataset configuration) to run code on a processing worker. From there, the actor escalated to node-level access, harvested cloud and cluster credentials, and moved laterally into several internal clusters over a weekend.

      I hope they release more details about the code that pulled this off. I'm assuming this means packages using the datasets library, a Hugging Face project for bundling up and sharing datasets on their platform. That library used to execute arbitrary code but has been steadily locked down over time, with the 4.0.0 release in July 2025 removing the trust_remote_code=True flag entirely.

      Assuming the attack used that library it must have either abused pickle serialization in some way, found some other non-obvious code execution path, or (most likely) specified datasets<4.0.0 as the dependency.

      The campaign was run by an autonomous agent framework (appearing to be built on an agentic security-research harness - used LLM still not known) executing many thousands of individual actions across a swarm of short-lived sandboxes, with self-migrating command-and-control staged on public services.

      This was a sophisticated attack!

      Then Hugging Face hit a wall: they tried to use "frontier models behind commercial APIs" - I'm guessing from Anthropic and OpenAI - to help analyze the attack, and were blocked:

      When we started the log analysis, we first used frontier models behind commercial APIs. This did not work: the analysis requires submitting large volumes of real attack commands, exploit payloads, and C2 artifacts, and these requests were blocked by the providers' safety guardrails, which cannot distinguish an incident responder from an attacker.

      They switched to their own self-hosted instance of MIT licensed GLM-5.2 and it helped them figure out what was going on.

      This indicated a fundamental asymmetry between the defending team and the (so-far unknown) attacker:

      We do not know which model powered the attacker's agents, whether a jailbroken hosted model or an unrestricted open-weight one; either way, the attacker was bound by no usage policy, while our own forensic work was blocked by the guardrails of the hosted models we first tried.

      As a useful indicator of how seriously they took the attack:

      [...] Finally, we have also reported this incident to law enforcement agencies.

      So who was responsible for this "autonomous agent framework"? It turned out to be OpenAI themselves.

      The OpenAI confession

      Five days later, on July 21st, OpenAI revealed the culprit. They had been running the ExploitGym benchmark against a new, as-yet undisclosed model, and that model had been operating way outside its intended parameters (emphasis mine):

      After investigating, we now know that this particular incident was driven by a combination of OpenAI models — including GPT‑5.6 Sol and an even more capable pre-release model, all with reduced cyber refusals for evaluation purposes — while being internally tested on a benchmark⁠ [ExploitGym] of cyber capabilities. [...]

      We estimate maximal cyber capabilities by running this evaluation without production classifiers used to prevent models from pursuing high-risk cyber activity. Our benchmarks run in a highly isolated environment, with network access constrained to the ability to install packages through an internally hosted third-party software that acts as a proxy and cache for package registries.

      The models identified and chained vulnerabilities across OpenAI’s research environment and Hugging Face’s production infrastructure to obtain test solutions directly from Hugging Face’s production database. All evidence suggests that the models were hyperfocused on finding a solution for ExploitGym, going to extreme lengths to achieve a rather narrow testing goal.

      It's pretty clear what happened here. OpenAI removed safety filters for an in-progress model, locked it up in a sandbox and told it to solve the ExploitGym problems. Given the absence of guardrails there was nothing to prevent the model from attempting to break out of that sandbox, break into Hugging Face, and read the answers from there instead.

      OpenAI's sandbox used the now common pattern of allowing access to an allow-list of sites related to installing additional packages via a controlled proxy. In OpenAI's words:

      While operating in our sandboxed testing environment, our models spent a substantial amount of inference compute finding a way to obtain open Internet access, in pursuit of solving the evaluation problem. To gain access, the models identified and exploited a zero-day vulnerability (which we’ve now responsibly disclosed to the vendor) in the package registry cache proxy. With this access, our models performed a series of privilege escalation and lateral movement actions in our research testing environment until the models reached a node with Internet access.

      So step one was to break out onto the public internet. The model then broke into Hugging Face to find the answers:

      After gaining Internet access, the models inferred that Hugging Face potentially hosted models, datasets and solutions for ExploitGym. Knowing this, the model searched for and successfully found ways to gain access to secret information that it could use to cheat the evaluation. In one example, the model chained together multiple attack vectors, including using stolen credentials and zero-day vulnerabilities to find a remote code execution path on the Hugging Face servers.

      Chaining together multiple attack vectors is exactly the kind of thing these new models can do, where previous generations of models might have failed.

      I wrote last month about how Claude Fable is relentlessly proactive, when I noticed it spinning up custom web servers and deploying CORS tricks on my own laptop just to help debug a WebKit CSS issue. It turns out relentless proactivity is the defining trait of this new generation of Mythos-class models. If you set them a goal and give them a way to get there, even inadvertently, they will figure it out.

      Resist the temptation to write this off as a stunt

      There will inevitably be some people who dismiss this story as a dishonest marketing trick by OpenAI to make their models sound terrifyingly effective. I found 81 instances of the term "marketing" in the Hacker News discussion of the incident.

      To those people I say pull your heads out of the sand - you're now including Hugging Face in your conspiracy theories, just so you can deny the crescendo of evidence here!

      The best models we have today have the ability to both find and exploit new vulnerabilities. The ExploitGym paper itself concludes that "autonomous exploit development by frontier AI agents is no longer a hypothetical capability", and this incident is a perfect example of exactly that.

      The asymmetry is increasingly frustrating

      One of the most infuriating details of this story is how Hugging Face, faced with an accidental and aggressive attack from one of OpenAI's models, were unable to then turn to OpenAI's models to help them fend off the attack.

      The frontier models we have access to are increasingly being constrained in how much they can help us protect our software, heavily influenced by the US government's ongoing threat of export controls. Claude Fable 5 wouldn't even proofread this article for me! It insisted on downgrading me to a less capable model.

      Meanwhile open weight models from China such as GLM-5.2, Kimi 3 and the new Qwen 3.8 Max appear to have none of these restrictions - and any restrictions that do exist can likely be fine-tuned out of them by modifying the weights

      These constraints are meant to make us safer. I think there's a risk that they are having the opposite effect.

      You are only seeing the long-form articles from my blog. Subscribe to /atom/everything/ to get all of my posts, or take a look at my other subscription options.

    3. 🔗 HexRaysSA/plugin-repository commits sync repo: +2 releases rss 
      sync repo: +2 releases

## New releases
- [SigMaker](https://github.com/mahmoudimus/ida-sigmaker): 1.14.2, 1.14.1
    4. 🔗 BarutSRB/OmniWM OmniWM v0.5.8 release

      What's New Since 0.5.7

      Appearance and Layout

      • Added system-wide window corner controls under Settings → General → Appearance on macOS 26.4 or later. Choose the macOS default, square corners, or a custom radius; affected apps must be fully quit and reopened. OmniWM’s focus border now follows each window’s actual corner geometry.
      • Added per-display inner-gap overrides alongside the existing outer-margin overrides. Display IPC and CLI queries now report resolved inner and outer gaps with cleaner whole-number formatting.
      • Fixed Dwindle interactive resizing so minimum-size limits use the active display’s resolved inner gap.

      Focus and Gestures

      • Trackpad column scrolling now focuses the snapped landing window after a completed gesture, while cancelled or interrupted gestures leave focus unchanged.
      • Trackpad gestures now recover automatically after sleep or wake, unlock, and trackpad connection or removal.
      • Follow Window to Monitor now also applies when moving windows up or down between workspaces and when moving columns to numbered or adjacent workspaces.
      • Cross-workspace window selection, including Focus Previous Window and Workspace Bar navigation, now completes focus reliably after relayout without overriding a newer focus action or issuing duplicate transitions.

      Reliability and Fixes

      • Closing a Niri column now clamps the viewport to the remaining content, preserving its centering policy and preventing dead space or partially off-screen windows.
      • Further hardened the window-reliability work from 0.5.7: delayed Accessibility callbacks, retries, rescans, and frame writes are now tied to the exact current window so stale work cannot affect its replacement.
      • Fixed Workspace Bar clicks for workspaces whose names contain emoji.

      Project

      • Refreshed contributor and sponsor acknowledgements and documented how to capture trace files for bug reports.

      Release Integrity

      • OmniWM-v0.5.8.zip contains the Developer ID signed, notarized, and stapled OmniWM app.
      • OmniWM-v0.5.8.zip SHA-256: e61337daace74a8741cc001a0c874bc45d95e0219c415fd3fae8f5833e670f9b
      • GhosttyKit.xcframework-v0.5.8.zip SHA-256: 557f08c7f89467d1f28a2caa734216ade8673ba1ecfa27802c276975c0a53ac5
    5. 🔗 r/reverseengineering 10 Years of Binary Ninja rss

      submitted by /u/Psifertex
      [link] [comments]

    6. 🔗 @binaryninja@infosec.exchange Current Binary Ninja newsletter subscribers are automatically entered. New mastodon

      Current Binary Ninja newsletter subscribers are automatically entered. New subscribers who sign up during the giveaway will also be entered for remaining drawings. Sign up here:https://v35.us/dn6rcg5

    7. 🔗 @binaryninja@infosec.exchange Discount valid for up to one year of support renewal and new purchases. We mastodon

      Discount valid for up to one year of support renewal and new purchases. We love our existing customers and our new ones!

    8. 🔗 @binaryninja@infosec.exchange Celebrate 10 years of Binary Ninja! For the first time ever, we’re offering a mastodon

      Celebrate 10 years of Binary Ninja! For the first time ever, we’re offering a 35% discount! Join us for 10 full days of giveaways including licenses, merch, and more. Huge shoutout to everyone who has been with us since the beginning, and here’s to everything still to come. Join in on the celebration: https://binary.ninja/10years

    9. 🔗 r/reverseengineering Great introduction to ARM using pwnable challenge rss

      submitted by /u/AdvisorPowerful9769
      [link] [comments]

    10. 🔗 pydantic/monty v0.0.19-beta.6 - 2026-07-22 release

      What's Changed

      Full Changelog : v0.0.19-beta.5...v0.0.19-beta.6

    11. 🔗 r/reverseengineering Hey everyone, I wasn’t a fan of the official software for the ChargerLab POWER-Z KM003C, so I decided to reverse-engineer the USB interface and build my own open-source terminal tool: VoltReaver. rss

      submitted by /u/dan89156108
      [link] [comments]

    12. 🔗 pydantic/pydantic-ai-harness v0.9.0 (2026-07-21) release

      What's Changed

      Important

      This release raises the pydantic-ai-slim floor to 2.14.1.

      • feat(cache_stability): observational CacheStabilityMonitor capability by @dsfaccini in #327
      • feat: web_search text_summary mode and deferred ExaAgent capability by @ryahern in #386
      • Fix ClearToolResults corrupting typed ToolReturnPart subclasses (ToolSearchReturnPart) by @dsfaccini in #383
      • Bump pydantic-ai to 2.14.1, migrate durable tests to the durability capabilities, raise the floor by @adtyavrdhn in #397

      New Contributors

      Full Changelog : v0.8.0...v0.9.0

    13. 🔗 jellyfin/jellyfin 12.0 RC3 release

      🚀 Jellyfin Server 12.0 RC3

      We are pleased to announce the third release candidate preview release of Jellyfin 12.0!

      This is a preview release, intended for those interested in testing 12.0 before its final public release. We welcome testers to help find as many bugs as we can before the final release.

      As always, please ensure you stop your Jellyfin server and take a full backup before upgrading!

      A note about versioning

      Starting with this release, we are dropping the preceding10. from our versioning. Thus, 10.11.x -> [10.]12.x = 12.x. The reason is simple: at this point in the project, we don't envision a hard break in the API like we planned way back in the early days, and this version scheme was causing a lot of confusion amongst users about what a "major" release was. For more information, please see the RC1 release notes.

      What's new?

      The main goal of this release has been performance. 10.11.0 dropped a major backend rewrite, and while it was broadly functional, it had a lot of rough edges. This release seeks to polish out most of those rough edges and bring better performance to all users.

      There are many other small fixes, improvements, changes, and translations. See our draft release notes here or below for the full list of pull requests. You can also view the Web side changelog here.

      Note: You must be on Jellyfin 10.10.7+ or 10.11.x (ideally, 10.11.11) before upgrading! If you are not, the upgrade will fail. Ensure you upgrade to one of these versions first!

      Note: The initial load of Jellyfin 12.x will run a few migrations and will take several minutes. Please be patient and do not interrupt the process. You can leverage the (newly improved!) startup UI on your local network to see specific progress, or off-network to see general progress, by visiting the server URL in your web browser during startup.

      Note: If you install the RC, you should disable all external plugins and reinstall using the unstable plugin repository, or plugins may fail to load and cause unintended side effects.

      Installing

      This preview release is distributed in all our traditional forms, though not automatically via our Apt repository or latest tag.

      • For all non-Docker environments, you can find the files for manual download in our repository by selecting "Stable Preview" for your OS.
      • For Docker, you can pull the 12.0-rc3 or preview tags.

      What's Changed (since

      v12.0-rc2)

      New Contributors

      Full Changelog : v12.0-rc2...v12.0-rc3

    14. 🔗 r/reverseengineering GitHub - NtProtectVirtualMemory/PE-Library: A modern C++ library for parsing and manipulating Windows Portable Executable (PE) files. rss

      submitted by /u/Effective-Fly7516
      [link] [comments]

    15. 🔗 Mitchell Hashimoto Everyone Should Know SIMD rss
      (empty)
    16. 🔗 New Music Releases Imminence - Crestfallen rss

      Imminence - a new release is available:

      • 2026-07-22: Crestfallen (Single)

      Amazon: Canada | Deutschland | France | United Kingdom | United States

      Visit muspy for more information.

    17. 🔗 exe.dev Run a Slack Bot from Your VM (Without Giving It the Keys) rss

      You can now interact with your VM on Slack. We store your Slack credentials outside your VM so you don’t have to worry about agents running amok (incidentally, that’s true of all our integrations). There are two flavors of Slack integration:

      Slack

      The first is a send-only version of Slack (just labelled “Slack” on the integrations page). You can read more about it here: https://exe.dev/docs/integrations-slack

      Hooking it up is simple. When you create an integration, you will be directed to Slack to choose a workspace and channel. Then, attach the integration to a VM and call it from there:

      curl --json '{"text":"Everything is groovy"}' https://<slack-integration-name>.int.exe.xyz/

      Your message will show up in the linked channel.

      Slack Bot

      The second flavor is a little more complex, but much more flexible. It’s called “Slack Bot” on the integrations page. It will allow you to make a fully fledged Slack bot that can read/write and do whatever else you give it permissions to do. The setup is a little more involved because you need to make the app and grant it all the permissions you want your bot to have. More detailed instructions are on the documentation page: https://exe.dev/docs/integrations-slack-bot

      Once you’ve created your app, drop its two tokens into the integration. Then you can do a simple curl call to write to the channel:

      curl -X POST https://<slackbot-integration-name>.int.exe.xyz/api/chat.postMessage --json '{"channel": "#exe-dev-integration-test","text":"hi"}'

      Or you can make a full-blown responsive chatbot. There’s demo code included in the documentation.

      Have fun and enjoy slacking!

    18. 🔗 Ampcode News Multiplayer rss

      Three weeks ago, we shipped agents in orbs.

      Today, more and more of our work happens inside orbs. In fact, the orbs are quickly becoming the de facto "unit of work." They contain not just the code of the solution, but also the description of the problem, and often they are the running, executing solution itself. The lines between description, solution, code, and computation are all blurring and merging into the orb.

      As more of our work moves into orbs, we need better ways to share, control, and collaborate on those orbs and the artifacts they create.

      Multiplayer now lets you do just that.

      Turn any of your orbs into a multiplayer environment from the thread's Share menu.

      Anyone in your workspace can then join the thread, send messages to the agent, and access the orb's portal, file changes, and shared terminal until multiplayer mode expires.

generated: July 25, 2026 at 21:42:46