The userhost Irssi uses for line splitting can in some cases be wrong,
for instance when a proxy is used or when a server cloaks the hostname
without telling the client. Now Irssi always assumes the userhost is of
maximum length. 10 for username (common value) and 63 for hostname (in
RFC 2812).
irssi supports letting you specify the client SSL password
using the ssl_pass primitive on the configuration file. Its
a terrible idea to be putting passwords on unencrypted files
though so some security rational folks won't ever want to
do this. If you currently don't supply one irssi goes on and
assumes you do not want to use it, and depending on the server
configuration it may or not fail on the SSL handshake and not
allow any connection to go through... Freenode lets you
authenticate your username with an SSL client certificate
so this is not desirable behavior.
This adds support to irrsi so that if an SSL client
certificate was supplied and if no password was set we prompt
the user for one.
Upon disconnects we won't have to re-enter the password but
just in case for whatever reason SSL needs it we redraw the
screen to the console screen should the user have to enter
a password again. Users that do not have a password on the
SSL client certificate can just either enter an empty
password upon the prompt or set an empty password on the
configuration file. Its a bad idea to be using passwordless
client certificate files anyway, so let them do a bit more
work.
We only prompt for a password if and only if the client
certificate was set, if you have different client certificate
files or use the client certificate for different connections
you'll be asked for a password for each server SSL connection.
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
We can't go to the console window easily right now, we'll
want this in case irssi needs to prompt the user for something
sensitive such as a password.
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
The Linux kernel started to embrace a light weight development contribution
agreement process called the Developer Certificate of Origin (DCO) circa
2004. Attorneys all over the planet have conferred a lot of respect and
appreciation for this document and it provides a light weight alternative to
cumbersome and controversial Contribution License Agreements (CLAs).
Similar to streamlining FOSS licenses we also all stand to gain from
streamlining a light weight contribution agreement process for development
and in light of this the the Linux Foundation recently has made the DCO a
standalone project [0] so that any FOSS project under any FOSS license can
take advantage of the same gains. The motivation and intent is documented
on my blog post [1] and later covered extensively on lwn [2] after
James Bottomley's talk, and Bradley Kuhn went on extensively about it
as well [3].
Lets take advantage of the new shiny DCO and embrace it for contributions.
[0] http://developercertificate.org/
[1] http://www.do-not-panic.com/2014/02/developer-certificate-of-origin.html
[2] http://lwn.net/Articles/592503/
[3] http://ebb.org/bkuhn/blog/2014/06/09/do-not-need-cla.html
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
this fixes a crash due to illegal memory access that can occur if
something is printed to the screen on the "terminal resized"
handler. It is not clear to me whether this race condition can be
triggered by external incoming messages, but it might be better safe
than sorry.
while the last patch did stop /path/.xxx from turning italic, it also
stopped any other /emphasis/ from becoming italic. correct this by
testing for ispunct, so spaces are valid italic terminators
the colour 0 was broken by the extended colours patch because it needs
an explicit bit check (lower bits will be false since it is 0)
Thanks to lhynes for the report
Fixes Github issue #97https://github.com/irssi/irssi/issues/97
Fix proposed by ailin-nemui, built and tested on Debian Jessie using
0.8.15 source, tested by GeertHauwaerts as well.
