ln-s.net has been dead for over half a year now; both their website homepage
and any previous shortened links return an HTTP 503. Thus, it isn't very
useful to leave this broken command lingering around...
Signed-off-by: James McCoy <vega.james@gmail.com>
> Please note: Adding new links has been disabled since September 2014
> after 14 months notice.
Source: http://metamark.net/
Signed-off-by: James McCoy <vega.james@gmail.com>
Servers bind a nick to a connection for a short window after it
disappears to try and avoid contention over nicks. This may cause a 437
during connection to a server (c.f. ProgVal/Limnoria#1033) or even
during normal nick changes, if the timing is lucky.
Add handling for this error to the startup code and the Admin plugin.
Signed-off-by: James McCoy <vega.james@gmail.com>
Parsing through the various WHOIS replies to build a formatted string
isn't a trivial task, especially since there is some privacy related
information. Consolidate this handling into a single function so
there's one place to fix bugs.
Also fix an issue with people putting (unterminated) formatted text into
the "realname" field of their IRC client (c.f., ProgVal/Limnoria#1083).
Signed-off-by: James McCoy <vega.james@gmail.com>
Voice almost always requires halfop or above to set, and since having (half)op gives greater access than voice, I don't see the benefit in restricting this when it won't make a difference anyways.
ln-s.net has been dead for over half a year now; both their website homepage
and any previous shortened links return an HTTP 503. Thus, it isn't very
useful to leave this broken command lingering around...
The current message ("xyz isn't on any non-secret channels or is using a channel-list hiding umode.") is long and awkwardly worded.
This also removes an extra period from showing up at the end of the output.
Since the keyid should always match the master key, regardless of
whether there's a subkey or not, reduced this to simply make keyid be
the last 16 chars of the master key's fingerprint.
Changes one line and adds six to do this:
* change keyid = verified.keyid to be keyid0;
* added an if/else check to see if it's the subkey or master key; and
* then set keyid according the result of that check;
* then continues as normal.
Replacement code which might work to enable advanced keys with signing
subkeys to be correctly handled by the bot by associating the subkey
with the relevant master key.
Signing format still only clearsigning, the key details are more
important and auth via encrypted token and decryption is likely to be
more reliable anyway as there is far less chance of some other protocol
messing with the signed content. Effectively no chance, though the odd
corrupted packet here and there is still possible. Whereas with
clearsigning it can be broken by all manner of rewriting in
transit (which happens often enough with signed email as it is).
See also Issue #1045 for greater detail of what needs to be fixed and
what is to be done about it.
