Custom Query (1098 matches)
Results (55 - 57 of 1098)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #1190 | fixed | Accepting SSL certs too late resets bitlbee-libpurple | ||
| Description |
On BitlBee 3.2.2+20141207+devel+1070-2 API version 030202, this happens: 11:31 <@root> New request: Request: SSL Certificate Verification
11:31 <@root>
11:31 <@root> Accept certificate for [server name removed]?
11:31 <@root>
11:31 <@root> The certificate for [server name removed] could not be
validated.
11:31 <@root>
11:31 <@root> The certificate is not trusted because no certificate that can
verify it is currently trusted.
11:31 <@root> You can use the yes/no commands to accept/reject this request.
11:33 <@root> jabber3 - Login error: Connection timeout
11:33 <@root> jabber3 - Logging in: Signing off..
11:33 <@root> jabber3 - Logging in: Reconnecting in 900 seconds..
11:34 <@me> yes
11:34 -!- me [me@localhost] has joined &bitlbee
11:34 -!- ServerMode/&bitlbee [+Ct] by localhost
11:34 [Users &bitlbee]
11:34 [@me] [@root]
11:34 -!- Irssi: &bitlbee: Total of 2 nicks [2 ops, 0 halfops, 0 voices, 0
normal]
11:34 -!- Topic for &bitlbee: Welcome to the control channel. Type help for
help information.
11:34 -!- Topic set by root [root@localhost] [Tue Jan 13 11:34:05 2015]
11:34 <@root> Welcome to the BitlBee gateway!
That is, if you answer yes to a certificate verification question after the connection has timed out, Bitlbee gets confused and resets to its initial state, after which you have to identify all over again. I don't know if this happens in ordinary (non-libpurple) Bitlbee as I haven't got any SSL errors there. |
|||
| #791 | duplicate | Account Specific OTR Settings | ||
| Description |
Currently Bitlbee allows setting OTR policy on a global scale. I would like to see the ability to set OTR policy specifically on individual accounts. For example, my global setting for otr_policy may be opportunistic, but for User X I want it to be always. |
|||
| #565 | worksforme | Accounts with Spaces in Password | ||
| Description |
I am trying to connect to a jabber (google talk) account that has spaces in the password. When I added the account said: Warning: Passing a servername/other flags to `account add' is now deprecated. Use `account set' instead. I tried 'account set #/password long password with spaces' which resulted in "Setting changed successfully". However the password did not take. 'account set #' states "password is empty". I saw that bug #224 was the same issue, but that was closed 3 years ago, so I believe there is a different root cause. |
|||
