1 files changed, 49 insertions, 0 deletions
diff --git a/debian/NEWS b/debian/NEWS
new file mode 100644
index 0000000..d1bd8c2
--- /dev/null
+++ b/debian/NEWS
@@ -0,0 +1,49 @@
+irssi (1.2.0-2) unstable; urgency=low
+
+    With the release of Irssi 1.2.0 we now bundle the OTR plug-in as part of
+    the Irssi source code. During the import phase of the irssi-otr codebase
+    we fixed a number of issues, but one of them caused us to break backwards
+    compatibility for old irssi-otr users.
+
+    With the updated OTR implementation the secret keys of the user is no
+    longer stored with an account name of $nickname@$server (for example:
+    user@chat.freenode.net), but is rather stored with the network (or chatnet
+    if you like) name from Irssi (for example: Freenode). This should remove
+    the issue that some users have reported where if they connect to another
+    server on a given network the OTR implementation generates new keys for
+    you.
+
+    You can see your list of OTR keys in Irssi using /otr info.
+
+    Upgrade Path
+    ============
+
+    This requires a bit of manual work, but if you look at your ~/.irssi/otr
+    directory you should have 3 files:
+
+    otr.fp - containing the fingerprints of your OTR buddies.
+    otr.instag - containing the tags from OTR.
+    otr.key - containing your secret keys.
+
+    In otr.fp and otr.key you should manually open these files and modify the
+    old strings to the new format. The otr.key file is the most important one
+    since it contains the secret key material. The file contains an
+    s-expression like structure where the account name key can be found in the
+    (name name-goes-here) tuple. The otr.fp file contains a list of known
+    fingerprints.  Correct the account name from your preview keys there as
+    well.
+
+ -- Rhonda D'Vine <rhonda@debian.org>  Tue, 12 Feb 2019 22:36:01 +0100
+
+irssi (0.8.10~rc5-1) unstable; urgency=low
+
+    This package has the beginnings of GNUTLS support for SSL rather
+    than the upstream OpenSSL code.  This may have many bugs in and is
+    not feature complete. In particular it does not support verification
+    of the server's certificate. As a result the connection is vunerable
+    to man in the middle attack. This is only a regression if you use
+    the -cafile or -capath options to /connect. The data is still
+    encrypted.
+
+ -- David Pashley <david@davidpashley.com>  Sun, 17 Jul 2005 19:39:37 +0300
+