ORCUS Logo
Datenschutz Impressum Kontakt
Referenzen News Externe Links
email

externer Anbieter: translate.google.com

Datenschutz-Hinweis: Durch Auswahl von "OK":

OK

externer Anbieter: validator.w3.org

Datenschutz-Hinweis: Durch Auswahl von "OK":

OK

externer Anbieter: validator.w3.jigsaw.w3.org

Datenschutz-Hinweis: Durch Auswahl von "OK":

OK
prev. page next page / HOME / IRC - LM support / ot-snippet - simple IRC-helper /[internals]

param mode - side effects

Using the deprecated param mode of ot-snippet has some restrictions and side effects like any other shell application and has been the major reason for the new/prefered V002 stream mode.

IRC clients are typically using a shell call to run external applications like ot-snippet via exec. This causes implicit some argument handling by the used shell, like:

... before the processed arguments are handed over to called application (ot-snippet) itself.

stripping white space

Stripping away whitspace from call parameters is a regular command line behavior. If white space should be kept, arguments have to be single or double quoted.

# comment character

If you are using a channel name as a parameter to ot-snippet-param, it will contain a leading # character. The # character marks the start of a comment with bash, which is true with calling functions too: anything after the comment character will be ignored. You have to quote according parameters on calling ot-snippet in parameter mode to avoid that.

ot-snippet-strm is not affected by this unwanted shell interception, as it just reads the values from stdin as they are given.

A possible workaround in parameter mode is, to leave away the normally expected # character with channel names when using specific snippets. The snippet will then just add a hardcoded # character in front of the channel argument.

Note: This has the disadvantage, that using snippets requires knowledge about them, to use them 'correctly'.

With V001 there existed the now obsolete snippet "freenode", which did just that:

# freenode --------------------------------------------------------------------
# a generic snippet expecting <nick> <channel-name> (without leading #)
freenode=("
$2> there exists a specialized channel at freenode irc $open_irc:
$2> ircs://chat.freenode.net/#$3")

embedded variables

There are likely no IRC clients or networks accepting $ (dollar) being used with a valid nickname; nonetheless its possible to use \044 (the octal representation of the dollar character).

If such a value gets used with internal calls doing argument escaping, one might end up at some valid environment variable.

So - if you would feed in a nickname $USER as argument to exec yourself, the called application will just receive the expanded current user account name. Using the replaced content with your output will potentially leak it this way to the public.

Note: Using the stream mode of ot-snippet doesn't eliminate this problem entirely as it will just avoid the first/initial escaping done by the shell call performed by the IRC clients; using nested shell calls later on (using custom functions) could still end up at resolving unwanted variable results.

A typical use case for nested evaluation is using internal variables to keep shared text used with several snippets. Altough its tempting to use linebreaks, tabs or even IRC color codes as escape characters, on should avoid that. To expand the embedded characters one has to turn on escapce code expansion, which will at the same time "translate" a malicious nickname to a variable name. At the moment the internal variable gets used with a snippet, the output will contain the local user's account name instead of the expected nickname of the addressed user...

Note: Using the stream mode of ot-snippet doesn't eliminate this problem entirely as it will just avoid the first/initial escaping done by the shell call performed by the IRC clients; in this case the output should for a one call nesting contain the text $USER instead the expanded value.

#!/bin/bash

function nested
{
	# using any subshell feeding in parameters
	# in this case just returning the value of
	# a variable
	v=$(sh -c "echo \"$1\"")
	echo "nested: $v"
}

function outer
{
	v=$(sh -c "echo \"$1\"")
	echo "outer: $v"
	nested "$v"
}

outer "$1"
/exec para-show.sh "\044USER"
 outer: $USER
 nested: demo

embedded command expansion

The main reason to avoid using the parameter mode from IRC is, that one typically feeds in user nicknames with snippet names. As you got no control over usable nicknames (other than getting careful about suspicious looking ones) they could just contain malicious/unwanted instructions. Feeding in nicknames into a shell call is just handled like any other parameter and such expanded in case it contains according expressions.

Its seemingly allowed with (many/all?) IRC networks to use backticks with nicknames. In parameter mode a nickname like `ls` would be expanded as part of the call of ot-snippet via the shell function and the expanded result gets used as parameter(s).

It takes little to imagine to find more harmful samples than returning your own ~ directory. The parameter mode is kept available as its useful for testing at a terminal but should not be used from IRC clients.

ot-snippet-strm is not affected by this shell interception, as it just reads the values from stdin as they are given without any side effects.

suppress log entries

In a perfect world, ot-snippet logfiles wont contain any messages as long there are no real errors/warnings. To suppress some more often spammed "noise", ot-snippet offers ready made filters - following the comment:

# workarounds for known issues -----------------------------------------
# uncomment to suppress warning at ot-snippet*log

at the header section of ot-snippet.

dbind-warning

Using mate-terminal at centos adds a warning to the log (known bug):

(mate-terminal:10017): dbind-WARNING **: 20:39:15.346: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-5JpJNPCMtv: Connection refused

The warning can be ignored - to suppress it with ot-snippet, uncomment:

# uncomment to suppress dbind-warnings at ot-snippet-002.log (centos/mate-terminal)
# details https://orcus.de/main_support/ot-snippet.htm#ki-dbind
export NO_AT_BRIDGE=1

To suppress the warning for all gtk applications, one could export above variable from ~/.profile or ~/.xsessionrc , ~/.xinitrc too.

GLib-warning

Using the default zenity version 3.32.0+17+gfb0938f-1 with lxde at arch linux shows a known glitch/warning:

(zenity:584): GLib-WARNING **: 11:30:09.587: ../glib/glib/giounix.c:410Error while getting flags for FD: Bad file descriptor (9)

The warning can be ignored and has to be fixed with zenity - there is no other workaround available than filtering related messages from the ot-snippet logs. To filter the messages, search and uncomment:

# Glib-warnings (arch/zenity) - details:
# https://orcus.de/main_support/ot-snippet.htm#ki-glib
'Error while getting flags for FD'

GtkDialog warning

Like many other gtk applications is zenity affected by a change at gtk (demanding a parent window with a dialog window:

Gtk-Message: 03:21:25.615: GtkDialog mapped without a transient parent. This is discouraged.

The warning can be ignored and has to be fixed with zenity - there is no other workaround available than filtering related messages from the ot-snippet logs. To filter the messages, search and uncomment:

# GtkDialog-warnings (arch/zenity) - details:
# https://orcus.de/main_support/ot-snippet.htm#ki-gtkdialog
'GtkDialog mapped without a transient parent'

hexchat 2.16.x

With current hexchat versions (2022-02.12) using /execwrite echoes given parameters at the client textbox (seemingly more some debug output) while feeding them into ot-snippet. This echo is only visible to the caller and not shared at the current channel.

To address this (forgotten?) debug output an additional -q (quiet) switch has been added to the /execwrite function of hexchat. The pull request has been accepted on 2022-01-23 and will be available with coming hexchat versions.

If the switch is available generally, one can adjust the call to /execwrite , prepending parameters with -q to suppress the debug output. The adjusted command entries for the stream variant would look like:

NAME WII
CMD quote WHOIS %2 %2

NAME S
CMD exec -o ot-snippet-strm

NAME S
CMD execwrite -q &2

NAME P
CMD exec -o ot-snippet-para &2


prev. page next page / HOME / IRC - LM support / ot-snippet - simple IRC-helper /[internals]