cryptodotis / irssi-otr Goto Github PK

Hi!

I'm trying to install https://github.com/cryptodotis/irssi-otr into my user directory. It requires libotr-4.1.0, but my admin prefers not to use backports, so I managed to install it into ~/libotr (https://otr.cypherpunks.ca/libotr-4.1.0.tar.gz).

But now how do I actually install irssi-otr? I tried ~/irssi-otr$ ./configure --prefix="/home/dt1973/libotr/usr" but I'm getting checking for libotr headers version 4.x >= 4.0.0... not present.

Anybody know what to do?

Just tried git HEAD (cab3fc9) and ran into problems when trying to send long messages.
If the message I'm sending is longer than 49 characters, this happens:

Breakpoint 1, irssi_send_message (irssi=irssi@entry=0x0, recipient=recipient@entry=0x89b37c0 "somenick",
    msg=msg@entry=0x907ed70 "?OTR,00001,00002,?OTR:AA"...) at module.c:296
296                     IRSSI_MSG("ERROR: irssi is NULL in irssi_send_message()");
(gdb) bt
#0  irssi_send_message (irssi=irssi@entry=0x0, recipient=recipient@entry=0x89b37c0 "somenick", 
    msg=msg@entry=0x907ed70 "?OTR,00001,00002,?OTR:AA"...) at module.c:296
#1  0x00007a908f794934 in ops_inject_msg (opdata=0x0, accountname=<optimized out>, protocol=<optimized out>, 
    recipient=0x89b37c0 "somenick", 
    message=0x907ed70 "?OTR,00001,00002,?OTR:AA"...) at otr-ops.c:58
#2  0x00007a908f55b33b in fragment_and_send (opdata=opdata@entry=0x0, context=context@entry=0x8ce2900, message=<optimized out>, 
    fragPolicy=fragPolicy@entry=OTRL_FRAGMENT_SEND_ALL_BUT_LAST, returnFragment=returnFragment@entry=0x7e0d15e61320, 
    ops=0x7a908f99a320 <otr_ops>, ops=0x7a908f99a320 <otr_ops>) at message.c:106
#3  0x00007a908f55bd8c in otrl_message_sending (us=<optimized out>, ops=0x7a908f99a320 <otr_ops>, opdata=opdata@entry=0x457a400, 
    accountname=accountname@entry=0x87e44a0 "[email protected]", protocol=protocol@entry=0x7a908f795e45 "IRC", 
    recipient=recipient@entry=0x902bfa7 "somenick", their_instag=their_instag@entry=1, 
    original_msg=original_msg@entry=0x902bfb1 "123456789 123456789 123456789 123456789 123456789 12", tlvs=tlvs@entry=0x0, 
    messagep=messagep@entry=0x7e0d15e61320, fragPolicy=fragPolicy@entry=OTRL_FRAGMENT_SEND_ALL_BUT_LAST, 
    contextp=contextp@entry=0x7e0d15e612e0, add_appdata=add_appdata@entry=0x7a908f79233e <add_peer_context_cb>, 
    data=data@entry=0x457a400) at message.c:444
#4  0x00007a908f79272e in otr_send (irssi=irssi@entry=0x457a400, 
    msg=msg@entry=0x902bfb1 "123456789 123456789 123456789 123456789 123456789 12", to=to@entry=0x902bfa7 "somenick", 
    otr_msg=otr_msg@entry=0x7e0d15e61320) at otr.c:359
#5  0x00007a908f7952fc in sig_server_sendmsg (server=0x457a400, target=0x902bfa7 "somenick", 
    msg=0x902bfb1 "123456789 123456789 123456789 123456789 123456789 12", target_type_p=0x1) at module.c:71
#6  0x000000000048e31a in signal_emit_real ()
#7  0x000000000048e7cd in signal_emit ()
#8  0x0000000000490705 in cmd_msg ()
#9  0x000000000048e31a in signal_emit_real ()
#10 0x000000000048e7cd in signal_emit ()
#11 0x000000000043b160 in event_text ()
#12 0x000000000048e31a in signal_emit_real ()
#13 0x000000000048e7cd in signal_emit ()
#14 0x000000000048e31a in signal_emit_real ()
#15 0x000000000048e7cd in signal_emit ()
#16 0x000000000041c1eb in key_send_line ()
#17 0x000000000048e31a in signal_emit_real ()
#18 0x000000000048e7cd in signal_emit ()
#19 0x000000000044ec27 in sig_multi ()
#20 0x000000000048e31a in signal_emit_real ()
#21 0x000000000048e7cd in signal_emit ()
#22 0x000000000044f5f3 in key_pressed ()
#23 0x000000000041ba9e in sig_gui_key_pressed ()
#24 0x000000000048e31a in signal_emit_real ()
#25 0x000000000048e7cd in signal_emit ()
#26 0x000000000041cece in sig_input ()

OTR keys are tied to a single case-specifc username. Thus if you change your nick from USER to user, you will not be able to access your USER keys.

So I did a make install on this and help doesn't work, even after restarting irssi. I noticed that it gets installed in the wrong location, compared to the libraries:

anarcat@marcos:irssi-otr$ sudo make install
Making install in help
make[1]: entrant dans le répertoire « /home/anarcat/src/irssi-otr/help »
make[2]: entrant dans le répertoire « /home/anarcat/src/irssi-otr/help »
make[2]: Rien à faire pour « install-exec-am ».
 /bin/mkdir -p '/usr/local/share/irssi/help'
 /usr/bin/install -c -m 644 otr '/usr/local/share/irssi/help'
make[2]: quittant le répertoire « /home/anarcat/src/irssi-otr/help »
make[1]: quittant le répertoire « /home/anarcat/src/irssi-otr/help »
Making install in src
make[1]: entrant dans le répertoire « /home/anarcat/src/irssi-otr/src »
make[2]: entrant dans le répertoire « /home/anarcat/src/irssi-otr/src »
make[2]: Rien à faire pour « install-exec-am ».
 /bin/mkdir -p '/usr/lib/irssi/modules'
 /bin/bash ../libtool   --mode=install /usr/bin/install -c   otr.la '/usr/lib/irssi/modules'
libtool: install: /usr/bin/install -c .libs/otr.so /usr/lib/irssi/modules/otr.so
libtool: install: /usr/bin/install -c .libs/otr.lai /usr/lib/irssi/modules/otr.la
libtool: finish: PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/sbin" ldconfig -n /usr/lib/irssi/modules
ldconfig: /usr/lib/irssi/modules/otr.so is not a symbolic link

----------------------------------------------------------------------
Libraries have been installed in:
   /usr/lib/irssi/modules

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-Wl,-rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
make  install-data-hook
make[3]: entrant dans le répertoire « /home/anarcat/src/irssi-otr/src »
rm /usr/lib/irssi/modules/otr.la
mv /usr/lib/irssi/modules/otr.so /usr/lib/irssi/modules/libotr.so
chmod 644 /usr/lib/irssi/modules/libotr.so
make[3]: quittant le répertoire « /home/anarcat/src/irssi-otr/src »
make[2]: quittant le répertoire « /home/anarcat/src/irssi-otr/src »
make[1]: quittant le répertoire « /home/anarcat/src/irssi-otr/src »
make[1]: entrant dans le répertoire « /home/anarcat/src/irssi-otr »
make[2]: entrant dans le répertoire « /home/anarcat/src/irssi-otr »
make[2]: Rien à faire pour « install-exec-am ».
make[2]: Rien à faire pour « install-data-am ».
make[2]: quittant le répertoire « /home/anarcat/src/irssi-otr »
make[1]: quittant le répertoire « /home/anarcat/src/irssi-otr »

pardonnez mon français. ;)

notice:

 /usr/bin/install -c -m 644 otr '/usr/local/share/irssi/help'

vs

mv /usr/lib/irssi/modules/otr.so /usr/lib/irssi/modules/libotr.so

The readme says that irssi-otr needs libotr 4.0.x. This is not the latest version and it is an inconvenience.

When Bob runs xchat with the OTR plugin enabled, and Alice does ?OTR? in an irc channel they are in with various other participants, xchat will enable an OTR chat with Alice automatically. This should not happen. Only in a private message it should be able to start an OTR chat, it should ignore all the other messages.

I'd be happy to help package this for Debian - is it ready to be packaged?

When generating a key with irssi-plugin-otr from debian stable, irssi (v0.8.15) terminates with a segmentation fault when you close an empty window/query.

Create an AppArmor sandbox for the plugin and/or irssi together with the plugin.

Speaks for itself, check for security bugs, leaks, etc.

IM platforms:
Weechat
Xchat
Irssi

Provide packaging for .deb's and RPM's.

Hi, I'm using irssi (0.8.16), irssi-otr and irssi-xmpp from FreeBSD binary packages.

Sometimes when chatting over XMPP with OTR, I have an assertion failed here and this crashes my Irssi.

I use OTR only with a friend using Pidgin on Windows, so I don't know if this is part of the problem or no. I tried a few minutes an XMPP/OTR conversation with my Arch Linux PC with a test account, but I had no problem. Also fine with OTR over IRC query.

Usually the crash happens a few messages after the OTR initialization, just when I press enter to send a message (usualy the second or third message I send).

Is there anything I can do to help solving this bug?

If you get HTML crap in OTR sessions from your peers that's a known bug - although not of irssi-otr but of your peer's IM client.

References:
https://wiki.archlinux.org/index.php/Irssi-otr
https://bbs.archlinux.org/viewtopic.php?id=110923

Currently irssi-otr (git master) ties contexts down to "account" of form [email protected] and to "user" which is the peer's nickname. I think that this approach is flawed mostly because nicks and servers on IRC change often, causing excessive key regeneration and loss of trusted connections.

However, I am not very familiar with OTR and much less with the needs of Bitlbee integration, so I want to ask from those who are more knowledgeable before making any changes on this code.

Is there any reason to have multiple local identities? Why should I have more than one "account"?

If different contexts for different networks are deemed necessary, they should most likely be tied to network names (server->tag) rather than to server hosts (server->connrec->addr). Should the user have multiple connections to the same network, each connection will not only have its own nickname (because nicks within the network must be unique) but each of them will also have a different tag (IRCNet, IRCNet2, ...) despite possibly using the same server.

The use of local user's nickname in these bindings seems completely unnecessary and only harmful. Using the ident string (Irssi setting user_name) would seem to make more sense, but since this is a global setting not configurable per server/connection, it makes things not very different from just leaving out the value.

The contexts are also tied with peer nicknames which may cause trouble when nicks are changed for whatever the reason. Instead of this we could use peer's ident which tends to be more stable although also a bit less unique. The big drawback is that we need to /whois or /userhost to get the ident string.

Is it a problem if different people end up in the same context? Or even if everybody just goes into one big global context, and we only rely on the key fingerprints to tell them apart?

Thanks for any input.

Under some circumstances irssi-otr will automatically resend the last written message. Before resending the message it does not verify that the recipient is the one that the message was intended for. This means that if a third party can do MITM on the wire traffic then he can trick irssi-otr into resending a message, thus revealing the plaintext of that message. It does require some cooperation from the user, but that might be easy to get using irssi-otr issue 22 and the "?OTR Error:" mechanism.

You may verify the problem using an IRC bot that I've made:

1. Connect to irc.freenode.net.
2. Start a private conversation with the bot called OTRResend and start an OTR session.
3. Trust the bot using /otr trust. (Not strictly necessary).
4. Note that the bot echoes back your messages.
5. Send a message that contains the word "swap" and some secret. (Be careful to not make the message too long, or you'll trigger irssi-otr issue 21. Just try again). The word "swap" makes the bot swap out its keys and send an "?OTR Error:" message..
6. Note that irssi-otr has printed an error message. This message was sent by the bot, but may also be sent by a MITM attacker. It can contain any text message and there is no digital signature.
7. Type ?OTR? to restart OTR.
8. The bot will now start an OTR version 2 session. (I'm not sure if it's strictly necessary to use version 2 here, but this works).
9. Observe that you get a message indicating that the peer is not authenticated.
10. Observe that your client has just sent the message from step 5 to an unknown party.

To reset the bot type "/notice OTRResend forget".

Note the manual intervention required by the user at step 7. The attack is not automatic, so it is possible to protect yourself if you have some idea about what might be going on. But I've typed ?OTR? myself on some occasion, when a friend started a second Jabber client that got things confused.

Here is an example session:

06:36 <weinholt_> ?OTR?
06:36 OTR: Gone secure
06:36 OTR: Your peer is not authenticated. To make sure you're talking to the right guy you can either agree on a secret and use the authentication command /otr auth or /otr authq [QUESTION] SECRET. You can also use the traditional way and compare fingerprints (e.g. telephone or GPG-signed mail) and subsequently enter /otr trust.
06:36 OTR: Your fingerprint is: 6E0C4D30 2222E47B 9F1C4A84 884DB3C1 050EAE10
06:36 OTR: OTRResend's fingerprint is: 0DA17A5B 7316AFD4 03E5EF76 53DBDDFB CFF8CC3B
06:36 <OTRResend> Hello there... I am 0DA17A5B 7316AFD4 03E5EF76 53DBDDFB CFF8CC3B. Trust me.
06:36 OTR: Fingerprint 0DA17A5B 7316AFD4 03E5EF76 53DBDDFB CFF8CC3B trusted!
06:37 <weinholt_> echo
06:37 <OTRResend> [0DA17A5B] From you via OTR: 'echo'
06:37 <weinholt_> swap (attack at dawn)
06:37 OTR: General Error: Please type ?OTR? now..
06:37 <weinholt_> ?OTR?
06:37 OTR: Gone secure
06:37 OTR: Your peer is not authenticated. To make sure you're talking to the right guy you can either agree on a secret and use the authentication command /otr auth or /otr authq [QUESTION] SECRET. You can also use the traditional way and compare fingerprints (e.g. telephone or GPG-signed mail) and subsequently enter /otr trust.
06:37 OTR: Your fingerprint is: 6E0C4D30 2222E47B 9F1C4A84 884DB3C1 050EAE10
06:37 OTR: OTRResend's fingerprint is: CF42149C EBB6EFDC 99F8DF5D 8E3DCE57 F2E9B612
06:37 OTR: The last message to OTRResend was resent: 
06:37 <OTRResend> Hello there... I am CF42149C EBB6EFDC 99F8DF5D 8E3DCE57 F2E9B612. Do not trust me.
06:37 <OTRResend> [CF42149C] From you via OTR: '[resent] swap (attack at dawn)'

Verified with irssi 0.8.15-5 and ibotr5 4.0.0-2 on Debian wheezy amd64 with irssi-otr v1.0.0-alpha1-5-g5f685aa from git.

We should announce we are still kicking ass and writing awesome software. I'm on it!

We learned the hard way over at Cryptocat to have our shit audited properly

When one has a client like irssi, weechat, bitlbee or xchat, there isn't an easy way to show which fingerprints you own. This needs to be implemented to make verification and authentication happening as proposed in OTR.

It is a known bug that irssi-otr does not encrypt /me commands, maybe more actions are not encrypted, needs to be code reviewed.

Current usage: Requires user to explicitly type /otr init in a /msg window to start otr.

Better: otr looks to see if uid uses otr, and if so, automatically initiates.

Possible options: Only initiate for trusted FP.

I am trying to figure out why the Debian package (#26) is giving me this warning:

dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/irssi-plugin-otr/usr/lib/irssi/modules/libotr.so was not linked against libgmodule-2.0.so.0 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/irssi-plugin-otr/usr/lib/irssi/modules/libotr.so was not linked against librt.so.1 (it uses none of the library's symbols)

We don't specify any extra -lib to link against in our side of the build process, could there be too many depends in configure.ac?

So far this has happened thrice, twice in my main irssi (normal chatting), reproduced once artificially (typing random lines, pasting a bunch of lines finally triggered it)
irssi: module.c:295: irssi_send_message: Assertion irssi' failed.`

 nathan@panther  ~/irssi-otr4-git/irssi-otr   master git tip --oneline
cab3fc9 Fix: remove double quotes around a NULL value
 nathan@panther  ~/irssi-otr4-git/irssi-otr   master uname -a
Linux panther 3.8.7-1-ARCH #1 SMP PREEMPT Sat Apr 13 09:01:47 CEST 2013 x86_64 GNU/Linux

Program received signal SIGABRT, Aborted.
0x00007fe3250761c9 in raise () from /usr/lib/libc.so.6
(gdb) bt full
#0  0x00007fe3250761c9 in raise () from /usr/lib/libc.so.6
No symbol table info available.
#1  0x00007fe3250775c8 in abort () from /usr/lib/libc.so.6
No symbol table info available.
#2  0x00007fe32506f356 in __assert_fail_base () from /usr/lib/libc.so.6
No symbol table info available.
#3  0x00007fe32506f402 in __assert_fail () from /usr/lib/libc.so.6
No symbol table info available.
#4  0x00007fe3221280d0 in irssi_send_message () from /usr/lib/irssi/modules/libotr.so
No symbol table info available.
#5  0x00007fe3221273d3 in ?? () from /usr/lib/irssi/modules/libotr.so
No symbol table info available.
#6  0x00007fe321f12ab4 in ?? () from /usr/lib/libotr.so.5
No symbol table info available.
#7  0x00007fe321f13657 in otrl_message_sending () from /usr/lib/libotr.so.5
No symbol table info available.
#8  0x00007fe3221252eb in otr_send () from /usr/lib/irssi/modules/libotr.so
No symbol table info available.
#9  0x00007fe322127d6c in ?? () from /usr/lib/irssi/modules/libotr.so
No symbol table info available.
#10 0x0000000000488432 in ?? ()
No symbol table info available.
#11 0x000000000048889d in signal_emit ()
No symbol table info available.
#12 0x000000000048a8b9 in ?? ()
No symbol table info available.
#13 0x0000000000488432 in ?? ()
No symbol table info available.
#14 0x000000000048889d in signal_emit ()
No symbol table info available.
#15 0x0000000000437cd0 in ?? ()
No symbol table info available.
#16 0x0000000000488432 in ?? ()
No symbol table info available.
#17 0x000000000048889d in signal_emit ()
No symbol table info available.
#18 0x0000000000488432 in ?? ()
No symbol table info available.
#19 0x000000000048889d in signal_emit ()
No symbol table info available.
#20 0x000000000041a248 in ?? ()
No symbol table info available.
#21 0x000000000041a91a in ?? ()
No symbol table info available.
#22 0x00007fe325d0b9a3 in ?? () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#23 0x00007fe325d0ae46 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#24 0x00007fe325d0b198 in ?? () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#25 0x00007fe325d0b23c in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
---Type <return> to continue, or q <return> to quit---
No symbol table info available.
#26 0x000000000041686c in main ()
No symbol table info available.
(gdb) info registers
rax            0x0      0
rbx            0x7fe32698f000   140613581860864
rcx            0xffffffffffffffff       -1
rdx            0x6      6
rsi            0x325c5a 3300442
rdi            0x325c5a 3300442
rbp            0x7fe3251a86f0   0x7fe3251a86f0
rsp            0x7fff522f5818   0x7fff522f5818
r8             0xfefefefefefefeff       -72340172838076673
r9             0xfefefefeff092d63       -72340172837409437
r10            0x8      8
r11            0x206    518
r12            0x7fe3221290d6   140613505945814
r13            0x7fe32212a630   140613505951280
r14            0x190    400
r15            0x1d97920        31029536
rip            0x7fe3250761c9   0x7fe3250761c9 <raise+57>
eflags         0x206    [ PF IF ]
cs             0x33     51
ss             0x2b     43
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0
(gdb)

At the hackathon a friend of mine was trying to get irssi-otr running under arch. After typing in; /load otr. The irssi crashes with the following backtrace: http://sprunge.us/QiQe

Linux panther 3.8.7-1-ARCH #1 SMP PREEMPT Sat Apr 13 09:01:47 CEST 2013 x86_64 GNU/Linux

The 'otr' statusbar item becomes much less useful when it doesn't update itself when switching between query windows, else you end up switching from an OTR query to a cleartext query, but the statusbar still says OTR.

Manually running /otr when switching to a query works, but seems unnecessary. The UX would be much better if the statusbar redraw was triggered whenever switching to a new query window.

The OTR status bar can show the green "OTR" text, indicating that the peer is authenticated, even though the peer is not authenticated. To reproduce:

1. Connect three irssi clients to the same server (they should have different .irssi directories). I'll call the clients A, B and C. Add the status bar in client A.
2. Start an OTR session between A and B and authenticate them against each other (e.g. /otr auth foo). Note that /otr contexts on A now lists B as trusted.
3. Change the nick of B to something different and change the nick of C to the nick that B was using. The effect is that A will see B's nick talking with a different DSA key and OTR instance tag. Client B should not finish the OTR session.
4. Have C start an OTR session with A.
5. Client A will see a message that the peer is not authenticated, but the status bar will show the green "OTR" text anyway. /otr contexts will list two entries for the nick that C is now using. One is unverified and the other is verified with SMP.

It might look like this:

11:38 OTR: [ User - Account - Status - Fingerprint - Trust ]
11:38 OTR: > weinholt@localhost - alice - Encrypted -
11:38 OTR:   2DD1DF5E 28B043F6 DA08696F 2F060D18 2C361E5F - Unverified
11:38 OTR: > weinholt@localhost - alice - Encrypted -
11:38 OTR:   76713FCA E7D38481 6C71713B 7AF67A8D 3A583D70 - SMP

(At a few of the steps you'll also need to wait forever for libotr to generate DSA keys.)

It seems wrong that the OTR status bar should show the peer as authenticated when the peer you're actually communicating with is not authenticated.

This was tested with irssi 0.8.15-5 and ibotr5 4.0.0-2 on Debian wheezy amd64 with irssi-otr v1.0.0-alpha1-5-g5f685aa from git.

I see this when an OTR session is negotiated:

12:43:03 [IMC]  -!- [chat0.koumbit.net] <b>anarcat@localhost</b> Unknown command
12:43:06 [IMC]  -!- [chat0.koumbit.net] See Unknown command

chat0.koumbit.net is the IRC server I am on while negotiating a private OTR conversation. This looks an awful lot like parts of the message sent to the other party when initating the conversation ( foo has requested an OTR conversation, see foobar.com for more information...)

Hello,

according to the commit f0a4d99 it looks like 1.0.1 is already stated as "released" back in January. If thats the case, can you please also push a git tag for 1.0.1 so github is providing a tarball and also upstream release tracking works properly?

cheers,
anthraxx

At least, offer the option to disable logging automatically.

This should be done for the private conversation. Turn off any logging that may have access to it.

With Irssi, on the first look, it seems not that trivial but doable so I would gladly appreciate help if someone knows the irssi's insides. :)

When sending encrypted messages that need to be fragmented, only the last fragment is actually sent to the IRC server. I can reproduce this by connecting two irssi clients to the same IRC server, initiating an OTR session between them and sending an 80 character line from one client to the other. "/rawlog save" only shows the fragment that starts with "?OTR|...|...,00002,00002,".

I've tested this with irssi 0.8.15-5 and ibotr5 4.0.0-2 on Debian wheezy amd64 with irssi-otr v1.0.0-alpha1-5-g5f685aa from git.

"LibOTR functionality in popular IM's."

Should be:

"LibOTR functionality in popular IMs."

Sorry to be a prude. :P

Print account name along with the fingerprint of the key.

When two parties want to set up a secure line of communication using the irssi-otr plugin, party A initializes the process with the /otr init command.

When the party B does not have a key for party A, it will generate a key for comms with party A. This may take a while, but client B is still responsive.

When, in the mean time, party A issues the same command again, client B will become unresponsive until key generation is complete.

To Reproduce:
Start irssi, this will be client A
A: issue the command /connect irc.oftc.net
A: upon connection, issue the command /nick NICKA

Start irssi, this will be client B
B: issue the command /connect irc.oftc.net
B: upon connection, issue the command /nick NICKB

A: /load otr
B: /load otr
A: /msg message
A: from the private window with B, /otr init
B: should still be responsive, status window states key is being generated for [email protected]
A: from the private window with B, /otr init
B: now client B will be unresponsive until key generation is complete

It would be nice if several people would audit the security of the following clients:

http://www.imperialviolet.org/2012/01/14/gootr.html
http://mcabber.com/

common.h file appears to be missing. after ./bootstrap && ./configure --prefix="/usr" the following error is generated:

$ make
Making all in help
make[1]: Nothing to be done for `all'.
Making all in src
  CC       otr-formats.lo
clang: warning: -Wl,-z,relro,-z,now: 'linker' input unused
In file included from otr-formats.c:21:
In file included from ../src/otr.h:31:
../src/irssi-otr.h:27:10: fatal error: 'src/common.h' file not found
#include <src/common.h>
         ^
1 error generated.
make[1]: *** [otr-formats.lo] Error 1
make: *** [all-recursive] Error 1```

Instead of using assertions and crashing whole irssi, it would be more user-friendly to just print the location of the error and perhaps unload the module.

The contents of the first argument of asprintf() are undefined if the call fails. create_account_name() seems to think that 'accname' will be NULL if the call fails, which is wrong.

Check out http://blogs.23.nu/ilja/2006/10/antville-12995/ for more details.

Also, check the codebase for more similar uses of asprintf().

This is the oddest bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=499229

I originally thought it was fixed by the new version, but actually, it's not - I even opened a new issue against the XMPP plugin today, thinking it was at fault: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707758

However, the xmpp plugin maintainer believes the problem is in otr, as the crash happens when otr is unloaded.

The issues mentioned above have a couple of backtraces for you to help you reproduce the thing.

To reproduce:

1. Start irssi
2. /load otr
3. /otr genkey foo@bar
4. check with with "ps -eLf|grep irssi" that there are two irssi threads.
5. You will not get a confirmation message that key generation has completed.
6. check with with "ps -eLf|grep irssi" that there is one irssi thread.
7. /otr genkey foo@bar
8. Observe that a message appears that keygen has completed, and a new one is started
9. check with with "ps -eLf|grep irssi" that there is one irssi thread.

When closing a private conversation or finish a session, the account name printed is the user one and not the target (other person).

Ex: OTR: Finished conversation with [email protected]

Where "[email protected] " is my account name and not the target.

http://wiki.debian.org/Hardening

"-fstack-protector-all -D_FORTIFY_SOURCE=2 -O1 -Wl,-z,relro,-z,now -fPIE -pie"

Maybe move off cmake while you're at it :-)

Hello,

I'm trying this with 59ddcbe with irssi 0.8.15 on x86_64 and armv5tel linux, and although the module loads fine, after a bit of use, irssi dies:

irssi: module.c:295: irssi_send_message: Assertion `irssi' failed

Any idea? Can anyone reproduce this?

On systems where the shell, screen or irssi itself has consumed all the available file handles the irssi-otr plugin has a problem reacting on this.

It's triggered by having the plugin loaded, have the file handles depleted after the loading is done and getting a query with an OTR session start that still needs a key to be generated.

The subprocess will try to generate the key, but can't complete it and seems stuck. Killing it is the only way out. I'm guessing that errno's are missed and not handled properly.

Hello,

I found irssi-otr core dumping ("old" version even this new fork). It core dumps when generating key.

[(status)] /otr genkey [email protected] in free(): error: bogus pointer (double free?) 0x2bd40020

Program received signal SIGABRT, Aborted.
0x0bd6e67d in kill () from /usr/lib/libc.so.60.1
(gdb) bt
#0  0x0bd6e67d in kill () from /usr/lib/libc.so.60.1
#1  0x0bdd4de5 in abort () at /usr/src/lib/libc/stdlib/abort.c:68
#2  0x0bdd294d in wrterror (msg=Variable "msg" is not available.
) at /usr/src/lib/libc/stdlib/malloc.c:269
#3  0x0bdd3dc9 in free (ptr=0x2bd40020) at /usr/src/lib/libc/stdlib/malloc.c:1216
#4  0x008cf3f1 in g_free () from /usr/local/lib/libglib-2.0.so.2800.0
#5  0x0bcdf5ea in keygen_run () from /usr/local/lib/irssi/modules/libotr.so
#6  0x0bcdbbd8 in otr_deinit () from /usr/local/lib/irssi/modules/libotr.so
#7  0x1c092a8e in signal_stop ()
#8  0x1c09307f in signal_emit ()
#9  0x1c07e94f in command_runsub ()
#10 0x0bcdbc80 in otr_deinit () from /usr/local/lib/irssi/modules/libotr.so
#11 0x1c092a8e in signal_stop ()
#12 0x1c09307f in signal_emit ()
#13 0x1c07d71a in command_find ()
#14 0x1c092a8e in signal_stop ()
#15 0x1c09307f in signal_emit ()
#16 0x1c0147fc in get_idle_time ()
#17 0x1c092a8e in signal_stop ()
#18 0x1c09307f in signal_emit ()
#19 0x1c04d022 in key_info_find ()
#20 0x1c092a8e in signal_stop ()
#21 0x1c09307f in signal_emit ()
#22 0x1c04ce9f in key_pressed ()
#23 0x1c013c54 in get_idle_time ()
#24 0x1c092a8e in signal_stop ()
#25 0x1c09307f in signal_emit ()
#26 0x1c016c84 in gui_readline_init ()
#27 0x1c084a1e in mask_match ()
#28 0x0090edfd in g_io_channel_unix_get_fd () from /usr/local/lib/libglib-2.0.so.2800.0
#29 0x008c6397 in g_main_context_dispatch () from /usr/local/lib/libglib-2.0.so.2800.0
#30 0x008ca43e in g_main_context_prepare () from /usr/local/lib/libglib-2.0.so.2800.0
#31 0x008caa65 in g_main_context_iteration () from /usr/local/lib/libglib-2.0.so.2800.0
#32 0x1c026086 in main ()

If I should provide more info, please let me know. Thank you.

sys: OpenBSD 5.0-beta (i386)
irssi-otr: 25. 7. 2011 (git)
irssi: 0.8.15

From the otr-dev list:

So we did find one interop issue. It seems an irssi user and a piding
user cannot authenticate each other. We tried using shared secret, and
I tried on the pidgin side using question&answer (but I'm not sure if
the person on the irssi side had that option or confused it for
"secret")

Affects Ubuntu 13.10 at least. Backtrace included:

https://bugs.launchpad.net/irssi/+bug/1242358

The key generation can hang irssi for the duration of the key generation. It can also finish early without notice. I believe that these two problems are different sides to the same coin.

To reproduce the hanging:

1. Start an irssi that does not have the .irssi/otr directory.
2. Connect to an IRC server.
3. Open a private message window (/query anothernick).
4. Type /otr genkey foo@bar (or use your own ident).
5. Type a message in the query window.
6. Observe that irssi hangs until the key generation is completed.

To reproduce the lag in notification:

1. Repeat steps 1-3 from above.
2. Type "/otr init" in the query window.
3. Note that key generation has started.
4. Verify with "ps -eLf|grep irssi" that there are three irssi threads.
5. After a while there will only be two irssi threads. The key generation is complete.
6. Observe that there is no message in irssi that says that the key generation is finished.
7. Type "/otr init" again in the query window.
8. Observe that the "Key generation for foo@localhost completed" message now appears in the status window.

Tested with irssi 0.8.15-5 and ibotr5 4.0.0-2 on Debian wheezy amd64 with irssi-otr v1.0.0-alpha1-5-g5f685aa from git.

Would it be possible to consider to use ECDSA keys instead of DSA keys in OTR?

Does OTR currenty support multi party chat based on shared key? If so, I'd be happy to see that info on README how to set it up. Thanks!

Expanding on #52 -- does anybody know why it's still trying to install parts into /usr/ despite specifying --prefix=$HOME --with-irssi-module-dir=$HOME/.irssi/modules --docdir=$HOME --infodir=$HOME --mandir=$HOME?

make[2]: Nothing to be done for `install-exec-am'.
/bin/mkdir -p '/usr/share/irssi/help'
/usr/bin/install -c -m 644 otr '/usr/share/irssi/help'
/usr/bin/install: cannot create regular file `/usr/share/irssi/help/otr': Permission denied

When I try to add the OTR status message to IRSSI it segfaults
/statusbar window add otr

I am running debian wheezy and have used the backport of irssi-otr from jessie:
-!- OTR: OTR module version: 1.0.0
-!- Irssi: Client: irssi 0.8.15 (20100403 1617)

When I try to trust a chat partner after initiating secure chat it also segfaults:
[graffen] /otr trustSegmentation fault
lle@defiant:~$

Generally it segfaults whenever I use any /otr commands ("/otr version" works as one of the few)
Loading the plugin and initiating otr with ?OTR? works just fine.
Please let me know if there is anything I can do to give more and better info