[trigger.pl] Add support for fish encrypted channel messages and PRIVMSGs

[wav10001]

This issue is confirmed with irssi-fish from repository https://download.opensuse.org/repositories/home:/ailin_nemui:/irssi-git-an/xUbuntu_22.04/amd64/ and possibly other FiSH plug-ins

Despite fish encryption/decryption working while the FiSH module is loaded in Irssi, trigger.pl does not currently read FiSH decrypted messages in channel. For example, consider the following message in #irssi on Libera:

> This is a FiSH decrypted message

trigger.pl sees this message in its encrypted format which looks something like this:

+OK YRAtW0aJTWs0FV2ij/pXiSp/X0..k.95Izl1FwABA/LJ0x60

So unless the trigger is set to some variation of the above string, the trigger will never work.

[Doug Freed]

There is not anything trigger.pl can really do about this. This needs to be fixed in irssi and the encryption modules, as both fish and otr are affected. The issue is that both trigger.pl and fish/otr use signal_add_first with the message private signal. The way that signal hooks are implemented, whoever calls signal_add_first last will be the first handler invoked when the signal is emitted. Since trigger.pl is generally loaded after fish/otr, it ends up being the last call to signal_add_first and so it gets called first when a message comes in, before fish/otr do their decryption. There are a few possible fixes. One is for irssi to add a separate signal for fish/otr to use that happens before message private to allow them to do their decryption, and then the result gets fed to the message private signal instead. Another is for fish/otr to stop the existing message private signal after decryption and then re-emit it, rather than using signal_continue, which just continues with later signal hooks, whereas trigger.pl's hook has already been called. A third possible option is for fish/otr to use signal_add_full manually and specify an even higher priority than the default signal_add_first uses, so that they are always the first signal hook called.

[Farzad Sadeghi]

I guess someone should tag @falsovsky and whoever it is that's maintaining otr(@ailin-nemui?) right now.

Also for anyone who's just trying to fix this and get on with their life, you can use the startup file to load everything on startup, in the order that you want. It's janky but it should work.

[wav10001]

The order that the trigger script and fish module are loaded does not appear to matter. I just tried testing it briefly (making sure to close and re-open Irssi after changing the startup order) by messaging myself with encryption enabled and the following test trigger set:

/TRIGGER ADD -all -nocase -regexp test -replace Test!

[Doug Freed]

You need to have the trigger added before fish is loaded. trigger.pl only runs signal_add_first for a given signal when there is a trigger that would need that signal. In addition, for testing purposes, it is best to load modules and scripts manually to ensure they execute in the right order. So empty .irssi/startup and /set -clear autoload_modules, /save, and restart irssi, then /load perl, /script load trigger.pl, /trigger add -all -nocase -regexp test -replace Test!, /load fish, then send a test message.

[wav10001]

With the suggestions in this thread, I was able to get the trigger working as intended. Steps:

1. Remove fish from autoload_modules, which in my case looks like this:

/set autoload_modules irc dcc flood notifylist perl otr

Also, make sure to:
/save

2. /trigger add "whatever"

Also, make sure to:
/trigger save

3a) Add a script file to load the scripts in the correct order

Example (fishTriggerLoadOrder.pl):

use strict;
use warnings;
use Irssi;

# Ensure trigger.pl is loaded after this script
Irssi::command("script load trigger.pl");

# Load FiSH module
Irssi::command("load fish");

Irssi::print("FiSH and trigger.pl have been loaded in the correct order.");

Save to ~/.irssi/scripts and add link to script in ~/.irssi/scripts/autorun . Will need to remove trigger.pl from autorun directory if you do it this way.

---------- OR (much easier) -----------

3b) Edit ~/.irssi/startup as @terminaldweller suggested to load the module and script in the correct order

4. Quit irssi and re-open it

@terminaldweller you had suggested using the startup file to change the startup order, and - while that does work - I was under the impression that method was deprecated as there is now ./.irssi/scripts/autorun/ . Can anyone confirm?

[Farzad Sadeghi]

You are confusing some things together.

The directory you mentioned, ~/.irssi/scripts/autorun, is for the perl module to autoload scripts on startup. It has nothing to do with modules or loading commands on startup.

Loading commands on startup is what the startup file is for.

Since v1.3, there is a setting variable that defines which modules to load which bypassed the module-autoloading-on-startup part of the startup file's use case, but you can still put other irssi commands in your startup file.

So, TL;DR, no, the startup file is not deprecated.

[wav10001]

So while this worked briefly, something seemingly caused it to break after a restart. Not sure if this is a viable solution as i cant get it to work again. Not sure why it happened because I had done /trigger save, and /save before restart, and all the scripts and modules are in the correct load order.