Module: Pikuri::Thunderbird

Defined in:

lib/pikuri-thunderbird.rb,
lib/pikuri/thunderbird/gloda.rb,
lib/pikuri/thunderbird/profile.rb,
lib/pikuri/thunderbird/calendar.rb,
lib/pikuri/thunderbird/launcher.rb,
lib/pikuri/thunderbird/extension.rb,
lib/pikuri/thunderbird/ical_line.rb,
lib/pikuri/thunderbird/ics_event.rb,
lib/pikuri/thunderbird/mail_read.rb,
lib/pikuri/thunderbird/gloda/mail.rb,
lib/pikuri/thunderbird/mailto_uri.rb,
lib/pikuri/thunderbird/mail_search.rb,
lib/pikuri/thunderbird/date_helpers.rb,
lib/pikuri/thunderbird/mail_compose.rb,
lib/pikuri/thunderbird/calendar_read.rb,
lib/pikuri/thunderbird/compose_guard.rb,
lib/pikuri/thunderbird/contact_search.rb,
lib/pikuri/thunderbird/gloda/contacts.rb,
lib/pikuri/thunderbird/calendar_create.rb,
lib/pikuri/thunderbird/calendar_search.rb,
lib/pikuri/thunderbird/database_snapshot.rb

Defined Under Namespace

Modules: DateHelpers, IcalLine, IcsEvent, MailtoUri Classes: Calendar, CalendarCreate, CalendarRead, CalendarSearch, ComposeGuard, ContactSearch, DatabaseSnapshot, Extension, Gloda, Launcher, MailCompose, MailRead, MailSearch, Profile

Constant Summary

INBOUND_LEGS =

Legs of the five inbound tools: a mailbox and a calendar are private by domain, and their contents are written by whoever mailed you.

The private: true is the one place the framework declares that leg for you, and it is a narrow exception rather than a breach of the rule that the user declares sensitivity: elsewhere the framework cannot tell ~/work/scratch from ~/work/payroll, but a mailbox is sensitive by what it is, not by how it was configured. Nothing was inspected to know this — only the tool's domain.

Returns:

• (Pikuri::Tool::TrifectaLegs)

Pikuri::Tool::TrifectaLegs.new(
  private: true, untrusted: :hard, egress_payload_review: :no_egress
).freeze

OUTBOUND_LEGS =

Legs of the two opt-in outbound hand-offs.

:human_reviewed rather than :unreviewed because all four clauses of the approver seat hold, and the load-bearing one is payload visibility: the human commits in Thunderbird's own compose window / import wizard, so what is on screen is what leaves, byte for byte. That is why these are graded differently from a confirmer-gated shell command, where the human approves a program whose output was never shown.

The destination stays :attacker_reachable, and the pair is the clearest proof the two egress axes are orthogonal: the recipient is a drafted field, so an injection can address the mail to itself and a reviewed payload still lands in an inbox the attacker reads.

It stays true only while the outbound surface carries nothing but fields that render literally — no attachments, no HTML body. A tool that gained one would silently drop to hard :egress, since the human would be approving a reference to bytes nobody saw.

No private, unlike INBOUND_LEGS: these send, they do not read the mailbox. The one trickle back is ComposeGuard's recipient-novelty note, and it is a single incidental bit about an address the model itself supplied — worthless under attack, where a novel recipient is expected by construction. The private leg grades what a tool lets an attacker query over the pool, not whether any bit at all flows back.

Returns:

• (Pikuri::Tool::TrifectaLegs)

Pikuri::Tool::TrifectaLegs.new(
  private: false, untrusted: :none,
  egress_payload_review: :human_reviewed, egress_destination: :attacker_reachable
).freeze

LOADER =

Zeitwerk::Loader.new