Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

fix(agent): browser tools leak owner state, and can key a permission on the wrong site

Aperta
  • Qualcosa non va?
#600 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python
Ambito
devtools, security

Direzione di ricerca

Start in raven/agent/browser.py at lines 179, 231, and 551, then read the related _mark, _touched, _reap_owners, Browser.release, url_for, and _page_for paths. Reproduce the owner-retention case and the concurrent-owner permission case at fe3b6278f before choosing between the two stated binding approaches. Done means owner state follows the binding lifetime, permission text identifies the page actually acted on, and browser_tabs explains the unowned-tab close rule.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Two defects in the browser tools that #578 shipped, found in a post-merge review of its raven/agent/** slice. Both are on main at 608cedf18, both are nonblocking, and neither was raised by the two rounds that ran while the PR was open. The full review, including three observations outside raven/agent/**, is the summary on #578.

1. _BrowserTool._acted is never pruned (browser.py:179)

_BrowserTool._acted is class-level state keyed by owner, written by _mark() and read by _touched(), with no path that ever removes an entry. Since the owner is now run:<uid>, every delegated run that acts on the browser adds a key that outlives it for the life of the process.

Reproduced at fe3b6278f: 50,000 activity.collecting() runs each calling _mark(current_owner()) leave 50,000 live entries and 6.6 MiB retained after gc.collect(). The same loop under the id(run) key this replaced produced 2 distinct keys, because addresses recycle - so the correct fix for the tab binding also turned a self-collapsing key space into one that never collapses.

The driver half of the same pairing does reap: _reap_owners drops a binding past OWNER_IDLE_S, and Browser.release(owner) exists for the explicit case (currently uncalled). The tool-side map that mirrors it has neither. Dropping _acted[owner] wherever the binding is released, or aging entries on the same clock, would keep the two halves on one lifetime.

2. A permission key can name a site the call will not act on (browser.py:231)

_ActingTool.cast_params resolves the site from url_for(owner), which falls back to the panel's active page when the owner has no live binding. If that active tab is held by another owner, _page_for then opens a fresh tab and the action lands there instead - so the site the gate is asked about is a page the call never touches.

Reproduced at fe3b6278f. A parent owner holds the active tab at bank.test; a delegated run whose first browser call is browser_press:

site written into the permission call : bank.test
page the keystroke actually landed on : about:blank
keystrokes delivered to bank.test     : []

And the grant that lands is reusable. session_keys returns one digest for all three acting verbs on a site, so the key banked by that call is identical to the key a later real click, type or press on bank.test would present:

mislabelled press : 235fc70fec980b49
later real press  : 235fc70fec980b49   same
later real type   : 235fc70fec980b49   same
later real click  : 235fc70fec980b49   same

Nonblocking because the person did see bank.test and approve it, so no grant appears for a site never shown, and the precondition is narrow: two concurrent owners, and the asking owner holding no live binding - its first browser call is an acting verb, since a snapshot would bind it, or its binding lapsed past OWNER_IDLE_S while a sibling holds the active tab. Worth fixing anyway, because the prompt is the one surface where the sentence shown to the person has to describe the call being approved, and the reachable case is the delegation case this feature exists for.

Two directions, and the choice between them is a design call rather than a patch: resolve the site after _page_for has bound the owner, or have url_for answer empty for an unbound owner instead of falling back to the panel, which would make the call key per-call until the owner has a page of its own.

3. Minor: browser_tabs does not say that close refuses an unheld tab (browser.py:551)

Its description names one thing a call cannot do, taking a tab "marked held". Since fe3b6278f that is no longer the whole rule - tab_close also refuses every tab with no owner, because an unowned tab is the reader's and may hold the login HANDOFF_NOTE just asked them to complete. The listing marks such a tab with neither yours nor held, so nothing the model reads tells it apart from one it may close. The recovery (activate, then close what you hold) is written only in tab_close's docstring, which the model never sees; the driver's refusal text does point at it, so the cost is one wasted call rather than a stuck agent.

Lingua principale
Python
Stelle
4.1k
Fork
94
Merge medio
10h 2m
PR unite (30g)
376

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di EverMind-AI/Raven

Tutte le issue di EverMind-AI/Raven

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.