silc-devel Mailing List for Secure Internet Live Conferencing (Page 4)
Secure chat and conferencing protocol
Brought to you by:
priikone
Menu
▾
▴
silc-devel — Main SILC development mailing list
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
(7) |
Sep
(10) |
Oct
(55) |
Nov
(6) |
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(3) |
Feb
(14) |
Mar
(10) |
Apr
(11) |
May
(7) |
Jun
(9) |
Jul
(19) |
Aug
(58) |
Sep
(36) |
Oct
(28) |
Nov
(152) |
Dec
(33) |
| 2002 |
Jan
(124) |
Feb
(92) |
Mar
(66) |
Apr
(35) |
May
(62) |
Jun
(16) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Pekka R. <pri...@ik...> - 2002-05-06 06:17:31
|
: : in silc-20020505 these commands do not work: : /who (does not show users on channel) , /nick (says "You're now known : as FOO" when I connect to network as FOO and try ANYTHING as parameter : to /nick) (these worked in silc-20020429) : Well, that's just BUU HUU! Don't use CVS. Pekka ________________________________________________________________________ Pekka Riikonen priikone at silcnet.org Secure Internet Live Conferencing (SILC) http://silcnet.org/ |
|
From: Timo S. <ts...@ik...> - 2002-05-06 04:59:06
|
> with efence loaded, I can see that silc accesses more data than it > has allocated: there's much better and much faster memory debuggers than efence: valgrind - http://devel-home.kde.org/~sewardj/ njamd - http://fscked.org/proj/njamd.shtml > #1 0x080710bf in gui_entry_draw_from (entry=0x5326efc0, pos=1395065172) > at gui-entry.c:121 > #2 0x0807115b in gui_entry_draw (entry=0x5326efc0) at gui-entry.c:133 > #3 0x08072ef3 in key_beginning_of_line () at gui-readline.c:242 I think someone else also complained that after writing lots of text, beginning-of-line key would crash irssi with solaris, but I could never reproduce that.. umm.. ah. last time i checked it with only efence, but valgrind shows now the bug - fixed :) |
|
From: Sami F. <sa...@ik...> - 2002-05-06 00:53:56
|
hi.
in silc-20020505 these commands do not work:
/who (does not show users on channel) , /nick (says "You're now known
as FOO" when I connect to network as FOO and try ANYTHING as parameter
to /nick) (these worked in silc-20020429)
I have Linux 2.4, glibc-2.2.4-24, gcc-3.0.4, binutils-2.12,...
and some backtraces.....
---
with efence loaded, I can see that silc accesses more data than it
has allocated:
#0 0x0807cc54 in term_clrtoeol (window=0x4d352fec) at term-terminfo.c:457
457 if (!term_lines_empty[vcy]) {
(gdb) print vcy
$4 = 32
#1 0x080710bf in gui_entry_draw_from (entry=0x5326efc0, pos=1395065172)
at gui-entry.c:121
#2 0x0807115b in gui_entry_draw (entry=0x5326efc0) at gui-entry.c:133
#3 0x08072ef3 in key_beginning_of_line () at gui-readline.c:242
#4 0x080bcd58 in signal_emit_real (rec=0x49ad0720, params=0, va=0x20)
at signals.c:216
#5 0x080bce47 in signal_emit (signal=0x5a3fafe8 "key beginning_of_line", params=0)
at signals.c:253
#6 0x08092dc5 in key_emit_signal (keyboard=0x4d354fe0, key=0x0) at keyboard.c:526
#7 0x08072cc3 in handle_key (key=72) at gui-readline.c:168
#8 0x0807322e in sig_input () at gui-readline.c:369
#9 0x080b16c6 in irssi_io_invoke (source=0x4d4b0ff0, condition=0, data=0x4d4b2ff4)
at misc.c:57
#10 0x400b728e in g_io_unix_dispatch (source_data=0x4d354fe0,
current_time=0xbfffe6e8, user_data=0x4d4b2ff4) at giounix.c:135
#11 0x400b8a72 in g_main_dispatch (dispatch_time=0xbfffe6e8) at gmain.c:656
#12 0x400b8e84 in g_main_iterate (block=1074576100, dispatch=1) at gmain.c:877
#13 0x400b91ce in g_main_iteration (block=1) at gmain.c:907
#14 0x08082ec1 in main (argc=1, argv=0x0) at silc.c:350
#15 0x40140647 in __libc_start_main (main=0x8082e20 <main>, argc=1,
ubp_av=0xbfffe7b4, init=0x806f3b0 <_init>, fini=0x81aae70 <_fini>,
rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbfffe7ac)
at ../sysdeps/generic/libc-start.c:129
---
I get this kind of crashes about one per hour:
#0 g_istr_hash (v=0x0) at misc.c:489
489 while (*s != '\0') {
(gdb) print s
$1 = 0x0
#1 0x400b0c09 in g_hash_table_lookup (hash_table=0x827af48, key=0x0) at ghash.c:114
#2 0x080b5082 in nick_hash_add (channel=0x827ae78, nick=0x831a3b8) at nicklist.c:39
#3 0x080b519b in nicklist_insert (channel=0x827ae78, nick=0x831a3b8)
at nicklist.c:84
#4 0x080a91ec in silc_nicklist_insert (channel=0x827ae78, user=0x8275180,
send_massjoin=0) at silc-nicklist.c:49
#5 0x080a272f in silc_channel_message (client=0x81fecd0, conn=0x0,
sender=0x827ae78, channel=0x8277ff8, flags=0, message=0x831a490 "re",
message_len=2) at client_ops.c:136
#6 0x08163807 in silc_client_channel_message_cb (client=0x81fecd0, conn=0x8277c28,
clients=0xbfffdfec, clients_count=1, context=0x8319c00) at client_channel.c:210
#7 0x0816098c in silc_client_command_get_client_by_id_callback (context=0x8319a00,
context2=0x82f9bf8) at idlist.c:522
#8 0x0815e585 in silc_client_command_reply_whois_i (context=0x82f9bf8,
context2=0x0) at command_reply.c:1833
#9 0x08159ed6 in silc_client_command_reply_process (client=0x81fecd0,
sock=0x8278148, packet=0x8319e48) at command_reply.c:124
#10 0x08165662 in silc_client_packet_parse (parser_context=0x831a108,
context=0x81fecd0) at client.c:942
#11 0x0816ff33 in silc_packet_receive_process (sock=0x8278148,
local_is_router=0 '\0', cipher=0x82735f8, hmac=0x82738e8, sequence=5339,
parser=0x8165580 <silc_client_packet_parse>, parser_context=0x81fecd0)
at silcpacket.c:405
#12 0x08165462 in silc_client_packet_process (schedule=0x8200628,
type=SILC_TASK_READ, fd=7, context=0x81fecd0) at client.c:881
#13 0x0818ff61 in silc_schedule_dispatch_nontimeout (schedule=0x82735f8)
at silcschedule.c:392
#14 0x08190330 in silc_schedule_one (schedule=0x8200628, timeout_usecs=1)
at silcschedule.c:623
#15 0x08166a24 in silc_client_run_one (client=0x0) at client.c:172
#16 0x0809f441 in my_silc_scheduler () at silc-core.c:59
#17 0x400b5a61 in g_timeout_dispatch (source_data=0x8205248,
dispatch_time=0xbfffe298, user_data=0x0) at gmain.c:1302
#18 0x400b4a72 in g_main_dispatch (dispatch_time=0xbfffe298) at gmain.c:656
#19 0x400b4e84 in g_main_iterate (block=0, dispatch=1) at gmain.c:877
#20 0x400b51ce in g_main_iteration (block=1) at gmain.c:907
#21 0x08082ec1 in main (argc=1, argv=0x0) at silc.c:350
#22 0x4013c647 in __libc_start_main (main=0x8082e20 <main>, argc=1,
ubp_av=0xbfffe364, init=0x806f3b0 <_init>, fini=0x81aae70 <_fini>,
rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbfffe35c)
at ../sysdeps/generic/libc-start.c:129
---
ummh.. this is odd, I only joined a couple of channels and immediately
got core dump:
#0 0x0827995b in ?? ()
#1 0x08276590 in ?? ()
(gdb) x/32c $eip-16
0x827994b: 8 '\b' 17 '\021' 0 '\0' 0 '\0' 0 '\0' 101 'e' 97 'a' 114 'r'
0x8279953: 116 't' 104 'h' 109 'm' 97 'a' 110 'n' 0 '\0' 0 '\0' 0 '\0'
0x827995b: 0 '\0' 25 '\031' 0 '\0' 0 '\0' 0 '\0' 115 's' 105 'i' 108 'l'
0x8279963: 99 'c' 46 '.' 115 's' 105 'i' 108 'l' 99 'c' 110 'n' 101 'e'
---
--
Safari - sa...@ik... - PGP key 0x427E7914 - http://iki.fi/safari/
"Talk is cheap. Show me the code." - Linus Torvalds
|
|
From: Sami F. <sa...@ik...> - 2002-04-29 15:48:15
|
On Mon, Apr 29, 2002 at 09:49:53AM +0200, Pekka Riikonen wrote:
...
> : maybe all of these crashes are caused by one little(!) bug,
> : who knows (not me).
> :
> Most of these should be fixed in CVS. They all come down to one and same
> problem.
20020429 version segfaulted with this kind of backtrace:
#0 0x0815838a in silc_client_command_register (client=0x807ce7c7, command=1 '\001',
name=0x0, command_function=0x807ce7c7, command_reply_function=0x807ce7c7,
max_args=0 '\000', ident=29286) at /c/silc/lib/silcutil/silclist.h:181
0x8158387 <silc_client_command_register+87>: mov 0x8(%ebp),%eax
0x815838a <silc_client_command_register+90>: mov 0x28(%eax),%eax <===
(gdb) printf "%0x\n", $eax
807ce7c7
#1 0x0815ffe1 in silc_client_get_client_by_id_resolve (client=0x807ce7c7, conn=0x8274518,
client_id=0x8224728, completion=0x807ce7c7, context=0x807ce7c7) at idlist.c:554
#2 0x08168a92 in silc_client_notify_check_client (schedule=0x81ff7f0,
type=SILC_TASK_EXPIRE, fd=0, context=0x8267358) at client_notify.c:41
#3 0x0818fc3e in silc_schedule_dispatch_timeout (schedule=0x81ff7f0)
at silcschedule.c:461
#4 0x0818fd20 in silc_schedule_select_timeout (schedule=0x81ff7f0)
at silcschedule.c:511
#5 0x0818fe06 in silc_schedule_one (schedule=0x827e770, timeout_usecs=136312920)
at silcschedule.c:587
#6 0x08166684 in silc_client_run_one (client=0x807ce7c7) at client.c:172
#7 0x0809f441 in my_silc_scheduler () at silc-core.c:59
#8 0x400b5a61 in g_timeout_dispatch (source_data=0x8204b40,
dispatch_time=0xbfffe298, user_data=0x0) at gmain.c:1302
#9 0x400b4a72 in g_main_dispatch (dispatch_time=0xbfffe298) at gmain.c:656
#10 0x400b4e84 in g_main_iterate (block=0, dispatch=1) at gmain.c:877
#11 0x400b51ce in g_main_iteration (block=1) at gmain.c:907
#12 0x08082ec1 in main (argc=1, argv=0x0) at silc.c:350
#13 0x4013c647 in __libc_start_main (main=0x8082e20 <main>, argc=1, ubp_av=0xbfffe364,
init=0x806f3b4 <_init>, fini=0x81aa7a0 <_fini>, rtld_fini=0x4000dcd4 <_dl_fini>,
stack_end=0xbfffe35c) at ../sysdeps/generic/libc-start.c:129
--
Safari - sa...@ik... - PGP key 0x427E7914 - http://iki.fi/safari/
"Talk is cheap. Show me the code." - Linus Torvalds
|
|
From: Pekka R. <pri...@ik...> - 2002-04-29 07:50:00
|
: : seven backtraces of silc client version : Irssi-SILC 0.8.2 (Irssi base: 0.8.4+ - SILC base: SILC Toolkit 0.8.2) : (20020423 20020423) : : silc-0.8.6 performed similarly wrt core dumping. : : RH x86 Linux, glibc-2.2.4-24, gcc-3.0.4, binutils-2.12, glib-1.2.10, : ncurses-5.2-13. : : maybe all of these crashes are caused by one little(!) bug, : who knows (not me). : Most of these should be fixed in CVS. They all come down to one and same problem. Pekka ________________________________________________________________________ Pekka Riikonen priikone at silcnet.org Secure Internet Live Conferencing (SILC) http://silcnet.org/ |
|
From: Sami F. <sa...@ik...> - 2002-04-28 23:03:35
|
hi.
seven backtraces of silc client version
Irssi-SILC 0.8.2 (Irssi base: 0.8.4+ - SILC base: SILC Toolkit 0.8.2)
(20020423 20020423)
silc-0.8.6 performed similarly wrt core dumping.
RH x86 Linux, glibc-2.2.4-24, gcc-3.0.4, binutils-2.12, glib-1.2.10,
ncurses-5.2-13.
maybe all of these crashes are caused by one little(!) bug,
who knows (not me).
---
#0 silc_client_command_register (client=3D0x0, command=3D1 '\001', name=3D=
0x0,=20
command_function=3D0, command_reply_function=3D0, max_args=3D0 '\000'=
, ident=3D26985)
at /c/silc/lib/silcutil/silclist.h:182
182 if (list->head =3D=3D NULL)
(gdb) print list
$3 =3D (struct link_map **) 0x1c
#1 0x0815ffe1 in silc_client_get_client_by_id_resolve (client=3D0x82672b=
0,=20
conn=3D0x8271da8, client_id=3D0x82418a8, completion=3D0, context=3D0x=
0) at idlist.c:554
554 silc_client_command_register(client, SILC_COMMAND_WHOIS, NULL, =
NULL,
#2 0x081689d2 in silc_client_notify_check_client (schedule=3D0x81ffbf8,=20
type=3DSILC_TASK_EXPIRE, fd=3D0, context=3D0x8229f38) at client_notif=
y.c:41
41 silc_client_get_client_by_id_resolve(client, conn, client_id, N=
ULL, NULL);
#3 0x0818fbce in silc_schedule_dispatch_timeout (schedule=3D0x81ffbf8)
at silcschedule.c:461
#4 0x0818fcb0 in silc_schedule_select_timeout (schedule=3D0x81ffbf8)
at silcschedule.c:511
#5 0x0818fd96 in silc_schedule_one (schedule=3D0x8279a58, timeout_usecs=3D=
136313952)
at silcschedule.c:587
#6 0x081665c4 in silc_client_run_one (client=3D0x0) at client.c:172
#7 0x0809f441 in my_silc_scheduler () at silc-core.c:59
#8 0x400b5a61 in g_timeout_dispatch (source_data=3D0x8204818,=20
dispatch_time=3D0xbfffe298, user_data=3D0x0) at gmain.c:1302
#9 0x400b4a72 in g_main_dispatch (dispatch_time=3D0xbfffe298) at gmain.c=
:656
#10 0x400b4e84 in g_main_iterate (block=3D0, dispatch=3D1) at gmain.c:877
#11 0x400b51ce in g_main_iteration (block=3D1) at gmain.c:907
#12 0x08082ec1 in main (argc=3D1, argv=3D0x0) at silc.c:350
#13 0x4013e647 in __libc_start_main (main=3D0x8082e20 <main>, argc=3D1,=20
ubp_av=3D0xbfffe364, init=3D0x806f3b4 <_init>, fini=3D0x81aa730 <_fin=
i>,=20
rtld_fini=3D0x4000dcd4 <_dl_fini>, stack_end=3D0xbfffe35c)
at ../sysdeps/generic/libc-start.c:129
---
#0 silc_client_command_get_clients_list_callback (context=3D0x827abd0,=20
context2=3D0x827d5d8) at idlist.c:309
309 SILC_GET16_MSB(idp_len, client_id_list->data + 2);
(gdb) print *client_id_list
Error accessing memory address 0x11: No such process.
#1 0x0815e505 in silc_client_command_reply_identify_i (context=3D0x11, c=
ontext2=3D0x0)
at command_reply.c:1853
1853 SILC_CLIENT_PENDING_EXEC(cmd, SILC_COMMAND_IDENTIFY);
#2 0x0815a0c6 in silc_client_command_reply_process (client=3D0x81fe298,=20
sock=3D0x8229fe0, packet=3D0x8272680) at command_reply.c:101
101 (*cmd->reply)((void *)ctx, NULL);
#3 0x081652c2 in silc_client_packet_parse (parser_context=3D0x827ee80,=20
context=3D0x81fe298) at client.c:942
#4 0x0816fa13 in silc_packet_receive_process (sock=3D0x8229fe0,=20
local_is_router=3D0 '\000', cipher=3D0x8274f80, hmac=3D0x8241808, seq=
uence=3D29,=20
parser=3D0x81651e0 <silc_client_packet_parse>, parser_context=3D0x81f=
e298)
at silcpacket.c:405
#5 0x081650c2 in silc_client_packet_process (schedule=3D0x81ffbf8,=20
type=3DSILC_TASK_READ, fd=3D7, context=3D0x81fe298) at client.c:881
#6 0x0818fa41 in silc_schedule_dispatch_nontimeout (schedule=3D0x8274f80=
)
at silcschedule.c:392
#7 0x0818fe10 in silc_schedule_one (schedule=3D0x81ffbf8, timeout_usecs=3D=
1)
at silcschedule.c:623
#8 0x081665c4 in silc_client_run_one (client=3D0x827abd0) at client.c:17=
2
#9 0x0809f441 in my_silc_scheduler () at silc-core.c:59
#10 0x400b5a61 in g_timeout_dispatch (source_data=3D0x8204818,=20
dispatch_time=3D0xbfffe298, user_data=3D0x0) at gmain.c:1302
#11 0x400b4a72 in g_main_dispatch (dispatch_time=3D0xbfffe298) at gmain.c=
:656
#12 0x400b4e84 in g_main_iterate (block=3D0, dispatch=3D1) at gmain.c:877
#13 0x400b51ce in g_main_iteration (block=3D1) at gmain.c:907
#14 0x08082ec1 in main (argc=3D1, argv=3D0x0) at silc.c:350
#15 0x4013e647 in __libc_start_main (main=3D0x8082e20 <main>, argc=3D1,=20
ubp_av=3D0xbfffe364, init=3D0x806f3b4 <_init>, fini=3D0x81aa730 <_fin=
i>,=20
rtld_fini=3D0x4000dcd4 <_dl_fini>, stack_end=3D0xbfffe35c)
at ../sysdeps/generic/libc-start.c:129
---
#0 0x401a368c in chunk_free (ar_ptr=3D0x402572a0, p=3D0x827e1b8) at mall=
oc.c:3228
3228 unlink(p, bck, fwd);
(gdb) d32
Dump of assembler code from 0x401a366c to 0x401a36ac:
0x401a366c <chunk_free+572>: adc %cl,0x57890c57(%ecx)
0x401a3672 <chunk_free+578>: or %ch,%bl
0x401a3674 <chunk_free+580>: movl $0x458bec45,0x1c72907(%ebx)
0x401a367e <chunk_free+590>: lock mov 0x8(%edi),%edx
0x401a3682 <chunk_free+594>: add $0x8,%eax
0x401a3685 <chunk_free+597>: cmp %eax,%edx
0x401a3687 <chunk_free+599>: je 0x401a3697 <chunk_free+615>
0x401a3689 <chunk_free+601>: mov 0xc(%edi),%eax
0x401a368c <chunk_free+604>: mov %eax,0xc(%edx)
0x401a368f <chunk_free+607>: mov %edx,0x8(%eax)
0x401a3692 <chunk_free+610>: jmp 0x401a347d <chunk_free+77>
0x401a3697 <chunk_free+615>: movl $0x1,0xffffffe4(%ebp)
0x401a369e <chunk_free+622>: jmp 0x401a347d <chunk_free+77>
0x401a36a3 <chunk_free+627>: add %esi,0xffffffec(%ebp)
0x401a36a6 <chunk_free+630>: and $0x1,%eax
0x401a36a9 <chunk_free+633>: je 0x401a3717 <chunk_free+743>
0x401a36ab <chunk_free+635>: mov 0xffffffec(%ebp),%eax
End of assembler dump.
(gdb) print $edx
$6 =3D 0
#1 0x401a33e4 in __libc_free (mem=3D0x827e1c0) at malloc.c:3154
3154 chunk_free(ar_ptr, p);
(gdb) print *p
$10 =3D {prev_size =3D 0, size =3D 0, fd =3D 0x0, bk =3D 0x0}
#2 0x0815f9cb in silc_client_del_channel (client=3D0x81fe298, conn=3D0x8=
272670,=20
channel=3D0x827bfe8) at idlist.c:765
(gdb) print *channel
$11 =3D {channel_name =3D 0x827c2d0 "#linux", id =3D 0x827e1c0, mode =3D =
0,=20
user_list =3D 0x827ced0, channel_key =3D 0x827d140,=20
key =3D 0x827d118 "=FEezx0JT=D6=AD\236;JO\222=D5D=D5\024\021=B6\023=C34=
=C39q=E03\234 \237M",=20
key_len =3D 256, iv =3D '\000' <repeats 15 times>, hmac =3D 0x827d358,=20
private_keys =3D 0x0, curr_key =3D 0x0, old_channel_key =3D 0x0, old_hm=
ac =3D 0x0,=20
rekey_task =3D 0x0}
(gdb) print *channel->id
$12 =3D {ip =3D {data =3D '\000' <repeats 12 times>, "\001\000\000",=20
data_len =3D 0 '\000'}, port =3D 0, rnd =3D 81}
#3 0x08165c89 in silc_client_close_connection_real (client=3D0x81fe298,=20
sock=3D0x8273348, conn=3D0x8272670) at client.c:1395
#4 0x081667e5 in silc_client_close_connection (client=3D0x81fe298, conn=3D=
0x8272670)
at client.c:1457
#5 0x0809fcd6 in sig_disconnected (server=3D0x8272e50) at silc-servers.c=
:247
#6 0x080bcd48 in signal_emit_real (rec=3D0x81f2988, params=3D136260616, =
va=3D0x0)
at signals.c:216
#7 0x080bce37 in signal_emit (signal=3D0x81bc0bc "server disconnected", =
params=3D1)
at signals.c:253
#8 0x080b7ec0 in server_disconnect (server=3D0x81f2c08) at servers.c:368
#9 0x080befd9 in cmd_disconnect (data=3D0x0, server=3D0x8272e50) at chat=
-commands.c:253
#10 0x080bf0a3 in cmd_quit (data=3D0x0) at chat-commands.c:273
#11 0x080bcd48 in signal_emit_real (rec=3D0x81f2c08, params=3D136259056, =
va=3D0x0)
at signals.c:216
#12 0x080bce37 in signal_emit (signal=3D0x8283480 "command quit", params=3D=
0)
at signals.c:253
#13 0x080abe1d in parse_command (
command=3D0x82861f1 "quit bork. I will be ass-laminated.", expand_ali=
ases=3D1,=20
server=3D0x8272e50, item=3D0x8285ab8) at commands.c:880
#14 0x080abfc2 in event_command (
line=3D0x82861f1 "quit bork. I will be ass-laminated.", server=3D0x82=
72e50,=20
item=3D0x8272e50) at commands.c:931
#15 0x080bcd48 in signal_emit_real (rec=3D0x81f25f0, params=3D136399360, =
va=3D0x0)
at signals.c:216
#16 0x080bce37 in signal_emit (signal=3D0x81aaab3 "send command", params=3D=
0)
at signals.c:253
#17 0x08072e1d in key_send_line () at gui-readline.c:191
#18 0x080bcd48 in signal_emit_real (rec=3D0x8214a00, params=3D136263576, =
va=3D0x0)
at signals.c:216
#19 0x080bce37 in signal_emit (signal=3D0x8284be8 "key send_line", params=
=3D0)
at signals.c:253
#20 0x080930dd in sig_multi (data=3D0x8221e88 "check_replaces;send_line",=
=20
gui_data=3D0x0) at keyboard.c:629
#21 0x080bcd48 in signal_emit_real (rec=3D0x81f3798, params=3D0, va=3D0x0=
)
at signals.c:216
#22 0x080bce37 in signal_emit (signal=3D0x8286180 "key multi", params=3D0=
)
at signals.c:253
#23 0x08092dc5 in key_emit_signal (keyboard=3D0x0, key=3D0x0) at keyboard=
.c:526
#24 0x08072cc3 in handle_key (key=3D10) at gui-readline.c:168
#25 0x0807322e in sig_input () at gui-readline.c:369
#26 0x080b16b6 in irssi_io_invoke (source=3D0x821c8e0, condition=3D0, dat=
a=3D0x821c8f8)
at misc.c:57
#27 0x400b328e in g_io_unix_dispatch (source_data=3D0x0, current_time=3D0=
xbfffe298,=20
user_data=3D0x821c8f8) at giounix.c:135
#28 0x400b4a72 in g_main_dispatch (dispatch_time=3D0xbfffe298) at gmain.c=
:656
#29 0x400b4e84 in g_main_iterate (block=3D1074559716, dispatch=3D1) at gm=
ain.c:877
#30 0x400b51ce in g_main_iteration (block=3D1) at gmain.c:907
#31 0x08082ec1 in main (argc=3D1, argv=3D0x0) at silc.c:350
#32 0x4013e647 in __libc_start_main (main=3D0x8082e20 <main>, argc=3D1,=20
ubp_av=3D0xbfffe364, init=3D0x806f3b4 <_init>, fini=3D0x81aa730 <_fin=
i>,=20
rtld_fini=3D0x4000dcd4 <_dl_fini>, stack_end=3D0xbfffe35c)
at ../sysdeps/generic/libc-start.c:129
---
#0 0x401ab47f in memcpy () from /lib/i686/libc.so.6
(gdb) d32
Dump of assembler code from 0x401ab45f to 0x401ab49f:
0x401ab45f <memcpy+15>: clc =20
0x401ab460 <memcpy+16>: cld =20
0x401ab461 <memcpy+17>: cmp $0x20,%ecx
0x401ab464 <memcpy+20>: jbe 0x401ab4bc <memcpy+108>
0x401ab466 <memcpy+22>: neg %eax
0x401ab468 <memcpy+24>: and $0x3,%eax
0x401ab46b <memcpy+27>: sub %eax,%ecx
0x401ab46d <memcpy+29>: xchg %eax,%ecx
0x401ab46e <memcpy+30>: repz movsb %ds:(%esi),%es:(%edi)
0x401ab470 <memcpy+32>: mov %eax,%ecx
0x401ab472 <memcpy+34>: sub $0x20,%ecx
0x401ab475 <memcpy+37>: js 0x401ab4b5 <memcpy+101>
0x401ab477 <memcpy+39>: mov (%edi),%eax
0x401ab479 <memcpy+41>: mov 0x1c(%edi),%edx
0x401ab47c <memcpy+44>: sub $0x20,%ecx
0x401ab47f <memcpy+47>: mov (%esi),%eax
0x401ab481 <memcpy+49>: mov 0x4(%esi),%edx
0x401ab484 <memcpy+52>: mov %eax,(%edi)
0x401ab486 <memcpy+54>: mov %edx,0x4(%edi)
0x401ab489 <memcpy+57>: mov 0x8(%esi),%eax
0x401ab48c <memcpy+60>: mov 0xc(%esi),%edx
0x401ab48f <memcpy+63>: mov %eax,0x8(%edi)
0x401ab492 <memcpy+66>: mov %edx,0xc(%edi)
0x401ab495 <memcpy+69>: mov 0x10(%esi),%eax
0x401ab498 <memcpy+72>: mov 0x14(%esi),%edx
0x401ab49b <memcpy+75>: mov %eax,0x10(%edi)
0x401ab49e <memcpy+78>: mov %edx,0x14(%edi)
End of assembler dump.
(gdb) print $esi
$1 =3D 0
#1 0x0827a1ac in ?? ()
#2 0x08192323 in silc_buffer_format (dst=3D0x82732b0) at silcbuffmt.c:46
46 ret =3D silc_buffer_format_vp(dst, ap);
#3 0x0817089d in silc_id_payload_encode_data (id=3D0x0, id_len=3D1368150=
20, type=3D2)
at silcid.c:158
#4 0x081707fd in silc_id_payload_encode (id=3D0x8241c18, type=3D2) at si=
lcid.c:140
#5 0x0815ffec in silc_client_get_client_by_id_resolve (client=3D0x81fe5a=
0,=20
conn=3D0x8273380, client_id=3D0x8241c18, completion=3D0, context=3D0x=
0) at idlist.c:559
#6 0x081689d2 in silc_client_notify_check_client (schedule=3D0x81fff00,=20
type=3DSILC_TASK_EXPIRE, fd=3D0, context=3D0x81f49a8) at client_notif=
y.c:41
#7 0x0818fbce in silc_schedule_dispatch_timeout (schedule=3D0x81fff00)
at silcschedule.c:461
#8 0x0818fcb0 in silc_schedule_select_timeout (schedule=3D0x81fff00)
at silcschedule.c:511
#9 0x0818fd96 in silc_schedule_one (schedule=3D0x8279d60, timeout_usecs=3D=
136314728)
at silcschedule.c:587
#10 0x081665c4 in silc_client_run_one (client=3D0x0) at client.c:172
#11 0x0809f441 in my_silc_scheduler () at silc-core.c:59
#12 0x400b5a61 in g_timeout_dispatch (source_data=3D0x8204b20,=20
dispatch_time=3D0xbfffe298, user_data=3D0x0) at gmain.c:1302
#13 0x400b4a72 in g_main_dispatch (dispatch_time=3D0xbfffe298) at gmain.c=
:656
#14 0x400b4e84 in g_main_iterate (block=3D0, dispatch=3D1) at gmain.c:877
#15 0x400b51ce in g_main_iteration (block=3D1) at gmain.c:907
#16 0x08082ec1 in main (argc=3D1, argv=3D0x0) at silc.c:350
#17 0x4013e647 in __libc_start_main (main=3D0x8082e20 <main>, argc=3D1,=20
ubp_av=3D0xbfffe364, init=3D0x806f3b4 <_init>, fini=3D0x81aa730 <_fin=
i>,=20
rtld_fini=3D0x4000dcd4 <_dl_fini>, stack_end=3D0xbfffe35c)
at ../sysdeps/generic/libc-start.c:129
---
#0 0x401a2a11 in chunk_alloc (ar_ptr=3D0x402572a0, nb=3D64) at malloc.c:=
2878
2878 unlink(victim, bck, fwd);
(gdb) print *victim
$1 =3D {prev_size =3D 0, size =3D 65, fd =3D 0xaf930800, bk =3D 0x2c2cd42=
}
#1 0x401a4337 in __libc_calloc (n=3D57, elem_size=3D1) at malloc.c:3844
3844 p =3D chunk_alloc (ar_ptr, sz);
#2 0x08196433 in silc_calloc (items=3D57, size=3D1) at silcmemory.c:34
34 addr =3D calloc(items, size);
#3 0x0815bf22 in silc_client_command_reply_join (context=3D0x8278118, co=
ntext2=3D0x0)
at /c/silc/lib/silcutil/silcbuffer.h:141
141 sb->head =3D (unsigned char *)silc_calloc(len, sizeof(*sb->head=
));
#4 0x0815a0c6 in silc_client_command_reply_process (client=3D0x39, sock=3D=
0x8274a58,=20
packet=3D0x8276ca8) at command_reply.c:101
101 (*cmd->reply)((void *)ctx, NULL);
#5 0x081652c2 in silc_client_packet_parse (parser_context=3D0x827f408,=20
context=3D0x81fe5a0) at client.c:942
#6 0x0816fa13 in silc_packet_receive_process (sock=3D0x8274a58,=20
local_is_router=3D0 '\000', cipher=3D0x8275130, hmac=3D0x827ae58, seq=
uence=3D64,=20
parser=3D0x81651e0 <silc_client_packet_parse>, parser_context=3D0x81f=
e5a0)
at silcpacket.c:405
#7 0x081650c2 in silc_client_packet_process (schedule=3D0x81fff00,=20
type=3DSILC_TASK_READ, fd=3D7, context=3D0x81fe5a0) at client.c:881
#8 0x0818fa41 in silc_schedule_dispatch_nontimeout (schedule=3D0x8275130=
)
at silcschedule.c:392
#9 0x0818fe10 in silc_schedule_one (schedule=3D0x81fff00, timeout_usecs=3D=
1)
at silcschedule.c:623
#10 0x081665c4 in silc_client_run_one (client=3D0x402572a0) at client.c:1=
72
#11 0x0809f441 in my_silc_scheduler () at silc-core.c:59
#12 0x400b5a61 in g_timeout_dispatch (source_data=3D0x8204b20,=20
dispatch_time=3D0xbfffe298, user_data=3D0x0) at gmain.c:1302
#13 0x400b4a72 in g_main_dispatch (dispatch_time=3D0xbfffe298) at gmain.c=
:656
#14 0x400b4e84 in g_main_iterate (block=3D0, dispatch=3D1) at gmain.c:877
#15 0x400b51ce in g_main_iteration (block=3D1) at gmain.c:907
#16 0x08082ec1 in main (argc=3D1, argv=3D0x0) at silc.c:350
#17 0x4013e647 in __libc_start_main (main=3D0x8082e20 <main>, argc=3D1,=20
ubp_av=3D0xbfffe364, init=3D0x806f3b4 <_init>, fini=3D0x81aa730 <_fin=
i>,=20
rtld_fini=3D0x4000dcd4 <_dl_fini>, stack_end=3D0xbfffe35c)
at ../sysdeps/generic/libc-start.c:129
---
This is the old crash, which happens when I type "/set ser[TAB]"
during connection.
#0 0x00000000 in ?? ()
#1 0x0809c240 in sig_complete_word (list=3D0x6e, window=3D0x820dc40,=20
word=3D0x82249d8 "ser", linestart=3D0x402576c0 "", want_space=3D0x826=
6518)
at chat-completion.c:572
#2 0x080bcd48 in signal_emit_real (rec=3D0x81f33d8, params=3D136400216, =
va=3D0x81e86b8)
at signals.c:216
#3 0x080bce37 in signal_emit (signal=3D0x81af64b "complete word", params=
=3D0)
at signals.c:253
#4 0x08083c9e in word_complete (window=3D0x82251f0, line=3D0x822a598 "/s=
et ser",=20
pos=3D0xbfffe31c, erase=3D0) at completion.c:201
#5 0x0807336b in key_completion (erase=3D0) at gui-readline.c:411
#6 0x080733cd in key_word_completion () at gui-readline.c:423
#7 0x080bcd48 in signal_emit_real (rec=3D0x8214d58, params=3D0, va=3D0x8=
1e86b8)
at signals.c:216
#8 0x080bce37 in signal_emit (signal=3D0x8266568 "key word_completion", =
params=3D0)
at signals.c:253
#9 0x08092dc5 in key_emit_signal (keyboard=3D0x8266430, key=3D0x0) at ke=
yboard.c:526
#10 0x08072cc3 in handle_key (key=3D9) at gui-readline.c:168
#11 0x0807322e in sig_input () at gui-readline.c:369
#12 0x080b16b6 in irssi_io_invoke (source=3D0x821cc48, condition=3D0, dat=
a=3D0x821cc60)
at misc.c:57
#13 0x400b328e in g_io_unix_dispatch (source_data=3D0x8266430,=20
current_time=3D0xbfffe728, user_data=3D0x821cc60) at giounix.c:135
#14 0x400b4a72 in g_main_dispatch (dispatch_time=3D0xbfffe728) at gmain.c=
:656
#15 0x400b4e84 in g_main_iterate (block=3D1074559716, dispatch=3D1) at gm=
ain.c:877
#16 0x400b51ce in g_main_iteration (block=3D1) at gmain.c:907
#17 0x08082ec1 in main (argc=3D1, argv=3D0x0) at silc.c:350
#18 0x4013e647 in __libc_start_main (main=3D0x8082e20 <main>, argc=3D1,=20
ubp_av=3D0xbfffe7f4, init=3D0x806f3b4 <_init>, fini=3D0x81aa730 <_fin=
i>,=20
rtld_fini=3D0x4000dcd4 <_dl_fini>, stack_end=3D0xbfffe7ec)
at ../sysdeps/generic/libc-start.c:129
---
#0 0x0815838a in silc_client_command_register (client=3D0x0, command=3D1=
'\001',=20
name=3D0x0, command_function=3D0, command_reply_function=3D0, max_arg=
s=3D0 '\000',=20
ident=3D1) at /c/silc/lib/silcutil/silclist.h:181
#1 0x0815ffe1 in silc_client_get_client_by_id_resolve (client=3D0x0, con=
n=3D0x8279020,=20
client_id=3D0x8267780, completion=3D0, context=3D0x0) at idlist.c:554
#2 0x081689d2 in silc_client_notify_check_client (schedule=3D0x81fff00,=20
type=3DSILC_TASK_EXPIRE, fd=3D0, context=3D0x8267318) at client_notif=
y.c:41
#3 0x0818fbce in silc_schedule_dispatch_timeout (schedule=3D0x81fff00)
at silcschedule.c:461
#4 0x0818fcb0 in silc_schedule_select_timeout (schedule=3D0x81fff00)
at silcschedule.c:511
#5 0x0818fd96 in silc_schedule_one (schedule=3D0x827ef30, timeout_usecs=3D=
136314728)
at silcschedule.c:587
#6 0x081665c4 in silc_client_run_one (client=3D0x0) at client.c:172
#7 0x0809f441 in my_silc_scheduler () at silc-core.c:59
#8 0x400b5a61 in g_timeout_dispatch (source_data=3D0x8204b20,=20
dispatch_time=3D0xbfffe298, user_data=3D0x0) at gmain.c:1302
#9 0x400b4a72 in g_main_dispatch (dispatch_time=3D0xbfffe298) at gmain.c=
:656
#10 0x400b4e84 in g_main_iterate (block=3D0, dispatch=3D1) at gmain.c:877
#11 0x400b51ce in g_main_iteration (block=3D1) at gmain.c:907
#12 0x08082ec1 in main (argc=3D1, argv=3D0x0) at silc.c:350
#13 0x4013e647 in __libc_start_main (main=3D0x8082e20 <main>, argc=3D1,=20
ubp_av=3D0xbfffe364, init=3D0x806f3b4 <_init>, fini=3D0x81aa730 <_fin=
i>,=20
rtld_fini=3D0x4000dcd4 <_dl_fini>, stack_end=3D0xbfffe35c)
at ../sysdeps/generic/libc-start.c:129
---
--=20
Safari - sa...@ik... - PGP key 0x427E7914 - http://iki.fi/safari/
"Talk is cheap. Show me the code." - Linus Torvalds
|
|
From: Pekka R. <pri...@ik...> - 2002-04-27 10:17:14
|
Hi, After a few weeks of intensive development the SILC protocol 1.1 is almost ready. I haven't yet finished writing the protocol specs but wanted first to let people know what to expect from 1.1. The new protocol specs will be submitted to the IETF during the first weeks of May. The purpose of this email is to give a list of "what's new in 1.1" for those that are not really interested in the protocol development but do want to know what's new. First off, I got a bit carried away doing this version and the end result is a lot more features that I had planned. The SILC started as being secure IRC alternative but this version detaches from this thinking by introducing features that are not found in IRC but are found in traditional IM systems. This don't mean SILC is IM system. It don't mean SILC is IRC-like system either. SILC is something different, something new, a new generation chat protocol. I know some people are going to think that some of these features aren't supposed to be in SILC and some people think they are great. Either way, here they are: o Anonymous support. The anonymous support has been added to the protocol level by introducing a user mode ANONYMOUS which can be set by a special server that provides these services. User cannot set or unset it itself. A user having ANONYMOUS flag also means that its username and hostname information is scrambled. There's other ways of being anonymous too but they don't belong to protocol level. o Multiple presence settings. Everybody knows what AWAY command in IRC does. Many IM systems defines more of these presence settings and I added that to SILC too. New user modes to represent presence are: INDISPOSED (I can't be present in the net now) BUSY (I'm busy don't bother me) PAGE (page me or something if you wanna talk) HYPER (I'm hyper active) o ROBOT user mode. A user in the network that is actually a robot should have the ROBOT user mode now set. o Message blocking. A new user mode: BLOCK_PRIVMSG can be used to block unwanted private messages. When set server doesn't deliver any private messages to you unless they have the Private Message Key flag set. It is set only if you and the sender of the message have negotiated private message key (or are otherwise using private message keys). Also a new user mode BLOCK_INVITE can be used to block incoming invite notifications and invite flooding. A new channel user mode: BLOCK_MESSAGES can be set to block all channel messages. When set server doesn't deliver any channel messages on that channel to you untill you unset the mode. Two other channel user modes: BLOCK_MESSAGES_USERS and BLOCK_MESSAGES_ROBOTS. The first mode blocks channel messages sent by normal users (only message sent by opers and founder are delivered to you). The second mode blocks messages sent by users having the ROBOT flag set, ie. messages sent by robots are not delivered to you. A separate service in a server could tune up these modes by providing a filtering service, like to block message but allow them from certain sender, etc. But, protocol doesn't define such service currently. o Services support. A new command SERVICE was added to the protocol to negotiate service agreement with a remote server. It can be used to start using some service on a remote server. The protocol doesn't define any services currently. o Session detachment/resuming. "Damn, I just upgraded the client and new version is out already". Don't worry anymore, you don't need to give /QUIT anymore. You can give /DETACH now, and get detached from the server, but still remain in the network. You can then reconnect to any server in the network and resume the old session and be like you was never gone. A new user mode DETACH is set by server for users that are detached so other people know that they really are not present in the network. Messages can be sent for detached users by the server drops them. This is IM system feature clearly but without the bloated infrastructure that is built around IM systems. o Watcher list. "Where is cras, where is salo, where are they!??". Just give "/WATCH -add cras" and the server will notify when cras comes to the network. It also notifies when cras leaves the network, changes nickname or changes user mode (like away, busy, detached etc). A new user mode REJECT_WATCHING was added and can be set by yourself so that nobody can watch you if you don't like it. o Moderated channels. Channel founder can now moderate the channel by setting SILCENCE_USERS channel mode. Only operators and the founder can then talk on the channel. There's also SILENCE_OPERS mode too that the founder can use to shut up operators too. When used with SILENCE_USERS only the founder can then talk on the channel. o Multimedia support. Message flag DATA was added and it was defined that message with that flag includes a MIME object. With this addition you can now effectively send any kind of data in SILC so that the receiver can interpret it. What is nice is that creating a "video conferencing" with SILC is trivial now; just send the stream, join the channel and invite your friends too. o STATS command. I added the network statistics after all to the protocol. The command can be used to fetch various network statistics (not server statistics). o Permanent channels. When founder mode is set the channel does not cease to exist even if last client leaves the channel. Also the founder can reclaim the founder rights back from any server in the network. o Trillion other smaller features and fixes has been added too. I will list all changes when I'll submit the drafts to IETF. There is one important note to make. Since I got carried away bit this new version is not fully compatible with the previous 1.0 version. Some security fixes and other new features causes that clients and servers using the old protocol version may have a have hard time working in network implementing 1.1 version. This don't matter to me much since after a couple weeks nobody remembers this little inconvenience anyway. I would say that's about it. 98% of those features has already been defined in the protocol specs and implemented in the CVS too. It's going to take a week or two still before SILC Toolkit 0.9 would come out (and new client and server too). We shall see. :) Pekka ________________________________________________________________________ Pekka Riikonen priikone at silcnet.org Secure Internet Live Conferencing (SILC) http://silcnet.org/ |
|
From: Tamas S. <to...@ru...> - 2002-04-23 19:38:12
|
On Tue, 23 Apr 2002, Pekka Riikonen wrote: yes, but i though, my server was affected, and you said, it will be fine in the next version. :) this misunderstanding led to this situation. :) okay, right now, everybody knows what's wrong. :) > : Subject: [bugreport] pfs > : > : ii silc-server 0.8.4-1 SILC - Secure Internet Live Conferencing > : > : and the effect with switched on pfs (with 4600 default option): > : key_exchange_pfs = true; > : key_exchange_rekey = 3600; > : > : seems, after that time, i got several packets which are not decrypatble, > : thus i'll seem online, but cannot send and receive further msgs. neither > : public, nor private one. > : > There is no bug in 0.8.4, the bug is in 0.8.3 which silc.silcnet.org > router still is. I tried to /MSG you that don't enable PFS but clearly > you didn't get it. Disable PFS. > > Pekka > ________________________________________________________________________ > Pekka Riikonen priikone at silcnet.org > Secure Internet Live Conferencing (SILC) http://silcnet.org/ > > > _______________________________________________ > Silc-devel mailing list > Sil...@li... > https://lists.sourceforge.net/lists/listinfo/silc-devel > -- VWOL Tamas SZERB <to...@ru...> GPG public key: http://people.debian.org/~toma/gpgkey-toma.asc |
|
From: Pekka R. <pri...@ik...> - 2002-04-23 19:09:01
|
: Subject: [bugreport] pfs : : ii silc-server 0.8.4-1 SILC - Secure Internet Live Conferencing : : and the effect with switched on pfs (with 4600 default option): : key_exchange_pfs = true; : key_exchange_rekey = 3600; : : seems, after that time, i got several packets which are not decrypatble, : thus i'll seem online, but cannot send and receive further msgs. neither : public, nor private one. : There is no bug in 0.8.4, the bug is in 0.8.3 which silc.silcnet.org router still is. I tried to /MSG you that don't enable PFS but clearly you didn't get it. Disable PFS. Pekka ________________________________________________________________________ Pekka Riikonen priikone at silcnet.org Secure Internet Live Conferencing (SILC) http://silcnet.org/ |
|
From: Tamas S. <to...@ru...> - 2002-04-23 18:04:49
|
ii silc-server 0.8.4-1 SILC - Secure Internet Live Conferencing and the effect with switched on pfs (with 4600 default option): key_exchange_pfs = true; key_exchange_rekey = 3600; seems, after that time, i got several packets which are not decrypatble, thus i'll seem online, but cannot send and receive further msgs. neither public, nor private one. idea, how to debug it, pekka? -- VWOL Tamas SZERB <to...@ru...> GPG public key: http://people.debian.org/~toma/gpgkey-toma.asc |
|
From: Matthew A. <ma...@al...> - 2002-04-21 11:21:12
|
> > > >: o Copying a missing file >: silc/lib/silccore/silcstatus.h >: >Cleraly you are using CVS version so you're on your own then. silcstatus.h >doesn't exist in any release. > Yep, I'm using the CVS release. If silc-devel isn't the place to report issues with development versions, where should I post things? (I don't mean to rock the boat - I've only just joined silc-devel, and don't know the 'right thing' to do. Is there a silc-release or silc-cvs mail list that would be better suited for minor details like this?) kr, matthew aldous. |
|
From: Pekka R. <pri...@ik...> - 2002-04-21 11:02:48
|
: I've just switched over to using the silc includes that : are installed (typically to /usr/local/silc), instead of using : the includes that are in the source tree. : : Fwiw, I've noticed that I need to.. : : o Use two include paths : -I/usr/local/silc/include : -I/usr/local/silc/include/mpi : : o Copying a missing file : silc/lib/silccore/silcstatus.h : Cleraly you are using CVS version so you're on your own then. silcstatus.h doesn't exist in any release. Pekka ________________________________________________________________________ Pekka Riikonen priikone at silcnet.org Secure Internet Live Conferencing (SILC) http://silcnet.org/ |
|
From: Matthew A. <ma...@al...> - 2002-04-21 08:49:53
|
Hi,
I've just switched over to using the silc includes that
are installed (typically to /usr/local/silc), instead of using
the includes that are in the source tree.
Fwiw, I've noticed that I need to..
o Use two include paths
-I/usr/local/silc/include
-I/usr/local/silc/include/mpi
o Copying a missing file
silc/lib/silccore/silcstatus.h
Kind regards,
matthew aldous.
|
|
From: Anders N. B. <de...@de...> - 2002-04-18 02:52:40
|
Didn't I fix this bug quite a few months ago? Who wrote it back in? > > Greetings > I apologize to you for a small bug in the server that drops root before writing the > pidfile, although it's not important enough to push a new release, so for those that > can't live without pid, there is a patch attached (the cvs is also fixed, and you > can safely use the stable branch). The RPM package is also fixed. > Please note that this interests only those that store the pid file in a root-owned > directory (like /var/run). |
|
From: Johnny M. <jo...@th...> - 2002-04-17 20:26:06
|
Greetings I apologize to you for a small bug in the server that drops root before=20 writing the pidfile, although it's not important enough to push a new=20 release, so for those that can't live without pid, there is a patch attac= hed=20 (the cvs is also fixed, and you can safely use the stable branch). The RP= M=20 package is also fixed. Please note that this interests only those that store the pid file in a=20 root-owned directory (like /var/run). About the client When you join a channel it seems to cut the last part of the nickname in = the=20 status bar: [22:19] [*@johnny_long_nic [1:the_test] the "*@" seems to cause that problem --=20 Johnny |
|
From: Pekka R. <pri...@ik...> - 2002-04-17 06:31:39
|
The SILC Server version 0.8.4 is now available! The software is available
from the following sources:
http://silcnet.org/
ftp://ftp.silcnet.org/
This version is bugfix release but also adds a better working rehash
support with the -HUP signal. The rekey protocol with PFS was also
totally broken but is fixed in this version. There's also now better
error logging during rekey protocol so if errors would occur during that
they will be logged now. A crash related to admin connection
configuration is also fixed. Upgrading is recommended.
Please refer to the ChangeLog on the website or the CHANGES file in the
package for complete list of changes.
Pekka
________________________________________________________________________
Pekka Riikonen priikone at silcnet.org
Secure Internet Live Conferencing (SILC) http://silcnet.org/
|
|
From: Lubomir S. <sa...@Xt...> - 2002-04-16 23:01:14
|
On Tue, Apr 16, 2002 at 10:28:59PM +0200, Matthew Aldous wrote:
> I've only recently joined silc-devel, and checked out the CVS release,
> on a NetBSD-current platform.
uname -sr
NetBSD 1.5ZB
> Fwiw, I had to upgrade autoconf (pkgsrc has autoconf 2.13) to version
> 2.53, as there is an entry in configure.in stating "AC_PREREQ(2.52)".
/usr/local/bin/autoconf -V | head -1
autoconf (GNU Autoconf) 2.52
> Please let me know what should happen. :)
rm -rf silc
cvs -Q co silc
cd silc
grep -v LIBTOOL configure.in.pre > c.pre && mv c.pre configure.in.pre
export PATH=3D/usr/local/bin:$PATH =20
./prepare =20
Preparing SILC source tree for configuration and compilation...
Preparing toolkit distribution version 0.8.2 (package 0.8.2)
doc/Makefile.am:98: warning: automake does not support conditional defi=
nition
of SILC_EXTRA_DIST in EXTRA_DIST
lib/Makefile.am:114: warning: automake does not support conditional def=
inition
of SILC_EXTRA_DIST in EXTRA_DIST
Preparing mpi
Preparing irssi
Done, now run ./configure and make.
./configure --prefix=3D/tmp/silc
[...]
configure: creating ./config.status
config.status: creating Makefile
config.status: creating config.h
gmake
[...]
gcc -O2 -g -Wall -finline-functions -g -O2 -o silcd protocol.o route=
.o
packet_send.o packet_receive.o idlist.o command.o command_reply.o silcd=
.o
server.o server_util.o server_backup.o serverconfig.o serverid.o
server_version.o -lncurses -L/usr/pkg/lib -lncurses -L/opt/build/silc=
/lib -lsilc
gmake[1]: Leaving directory `/opt/build/silc/silcd'
Making all in doc
gmake[1]: Entering directory `/opt/build/silc/doc'
Making all in .
gmake[2]: Entering directory `/opt/build/silc/doc'
gmake[2]: Nothing to be done for `all-am'.
gmake[2]: Leaving directory `/opt/build/silc/doc'
touch draft-riikonen-silc-spec-05.txt
touch draft-riikonen-silc-pp-05.txt
touch draft-riikonen-silc-ke-auth-05.txt
touch draft-riikonen-silc-commands-03.txt
touch draft-riikonen-silc-flags-payloads-00.txt
cd ..
gmake[1]: Leaving directory `/opt/build/silc/doc'
Making all in includes
gmake[1]: Entering directory `/opt/build/silc/includes'
cd ..
gmake[1]: Leaving directory `/opt/build/silc/includes'
Making all in win32
gmake[1]: Entering directory `/opt/build/silc/win32'
Making all in libsilc
gmake[2]: Entering directory `/opt/build/silc/win32/libsilc'
gmake[2]: Nothing to be done for `all'.
gmake[2]: Leaving directory `/opt/build/silc/win32/libsilc'
Making all in libsilcclient
gmake[2]: Entering directory `/opt/build/silc/win32/libsilcclient'
gmake[2]: Nothing to be done for `all'.
gmake[2]: Leaving directory `/opt/build/silc/win32/libsilcclient'
gmake[2]: Entering directory `/opt/build/silc/win32'
gmake[2]: Nothing to be done for `all-am'.
gmake[2]: Leaving directory `/opt/build/silc/win32'
gmake[1]: Leaving directory `/opt/build/silc/win32'
gmake[1]: Entering directory `/opt/build/silc'
gmake[1]: Nothing to be done for `all-am'.
gmake[1]: Leaving directory `/opt/build/silc'
gmake install
[...]
/usr/bin/install -c -m 644 mpi/mpi.h /tmp/silc/include/mpi/mpi.h
install: /tmp/silc/include/mpi/mpi.h: No such file or directory
/usr/bin/install -c -m 644 mpi/mplogic.h /tmp/silc/include/mpi/mplogic=
.h
install: /tmp/silc/include/mpi/mplogic.h: No such file or directory
/usr/bin/install -c -m 644 mpi/mpprime.h /tmp/silc/include/mpi/mpprime=
.h
install: /tmp/silc/include/mpi/mpprime.h: No such file or directory
/usr/bin/install -c -m 644 mpi/mpi-config.h
/tmp/silc/include/mpi/mpi-config.h
install: /tmp/silc/include/mpi/mpi-config.h: No such file or directory
gmake[4]: *** [install-includeHEADERS] Error 1
gmake[4]: Leaving directory `/opt/build/silc/lib/silcmath'
gmake[3]: *** [install-am] Error 2
gmake[3]: Leaving directory `/opt/build/silc/lib/silcmath'
gmake[2]: *** [install-recursive] Error 1
gmake[2]: Leaving directory `/opt/build/silc/lib/silcmath'
gmake[1]: *** [install-recursive] Error 1
gmake[1]: Leaving directory `/opt/build/silc/lib'
gmake: *** [install-recursive] Error 1
mkdir /tmp/silc/include/mpi
gmake install
[...]
/usr/bin/install -c -m 644 ./lib/doc/*.gif /tmp/silc/doc/toolkit
mkdir -p /tmp/silc/doc/examples/
/usr/bin/install -c -m 644 ./doc/examples/README /tmp/silc/doc/examples/
/usr/bin/install -c -m 644 ./doc/examples/silc* /tmp/silc/doc/examples/
/usr/bin/install -c -m 644 ./doc/examples/cell* /tmp/silc/doc/examples/
gmake[3]: Leaving directory `/opt/build/silc'
gmake[2]: Leaving directory `/opt/build/silc'
gmake[1]: Leaving directory `/opt/build/silc'
file /tmp/silc/bin/silc
/tmp/silc/bin/silc: ELF 32-bit LSB executable, Intel 80386, version 1
(SYSV), dynamically linked (uses shared libs), not stripped
regards,
--=20
-- Lubomir Sedlacik <sa...@Xt...> ASCII Ribbon campaign against /"\=
--
-- <sa...@si...> e-mail in gratuitous HTML and \ /=
--
-- Microsoft proprietary formats X =
--
-- PGPkey: http://Xtrmntr.org/salo.pgp / \=
--
-- Key Fingerprint: DBEC 8BEC 9A90 ECEC 0FEF 716E 59CE B70B 7E3B 70E2 =
--
|
|
From: Matthew A. <ma...@al...> - 2002-04-16 20:29:11
|
Hello all, I've only recently joined silc-devel, and checked out the CVS release, on a NetBSD-current platform. Fwiw, I had to upgrade autoconf (pkgsrc has autoconf 2.13) to version 2.53, as there is an entry in configure.in stating "AC_PREREQ(2.52)". (If I remove the requirement, the "AC_CONFIG_FILE" macro fails) The prepare & configure succeeds, the silc libraries build, but the irssi subdir fails in lib-popt. (below) -- Making all in irssi make all-recursive Making all in src Making all in lib-popt gcc -g -O2 -Wall -c findme.c findme.c:5: common.h: No such file or directory -- When I attempt to 'make install', the following fails. (below) -- Making install in mpi /bin/sh ../../mkinstalldirs /usr/local/silc/include .. /usr/bin/install -c -m 644 mpi/mpi.h /usr/local/silc/include/mpi/mpi.h install: /usr/local/silc/include/mpi/mpi.h: open: No such file or directory -- Please let me know what should happen. :) kr, matthew aldous. |
|
From: Pekka R. <pri...@ik...> - 2002-04-16 16:43:20
|
The SILC Client version 0.8.6 is now available! The software is available
from the following sources:
http://silcnet.org/
ftp://ftp.silcnet.org/
Just a bugfix release that fixes some ugly crash that I found in irssi.
Cras provided fix for it. If you are in more than one channels and you do
/QUIT it is quite possible that your client crashes. This version fixes
that. Some other minor stuff fixed too. Upgrading is not necessary
unless you are experiencing problems.
Please refer to the ChangeLog on the website or the CHANGES file in the
package for complete list of changes.
Pekka
________________________________________________________________________
Pekka Riikonen priikone at silcnet.org
Secure Internet Live Conferencing (SILC) http://silcnet.org/
|
|
From: Johnny M. <jo...@th...> - 2002-04-11 08:26:44
|
On Wednesday 10 April 2002 18:13, you wrote: > hi, > > On Thu, Mar 28, 2002 at 06:30:30PM +0100, Pekka Riikonen wrote: > > o Permanent channels? Wider founder support? Permanent channels vs= =2E > > Wider founder support? The founder support would be cell wide, and > > protected by backup routers as well. Permanency for channels can be > > achieved by defining that channel does not cease to exist even if > > last user leaves the channel, if the founder mode is set. This woul= d > > be cell wide as well. For these to fail, catastrophic network > > failure is required. > > with introduction of permanent channels and wider founder support we > will need to define anti-abuse practice which will help router > administrators to remove (kill) unwanted channels. this issue was > discussed some time ago and iirc we haven't decided what would be the > best solution. my idea to prevent abuse from the side of router > administrators was to require two router admins to agree on removing > a channel. this would reduce abuse which can be caused by one single > person but it's not a silver bullet for every occasion. i can imagine = a > situation when there will be need for quickly removing big amount of > channels etc. > Honestly, I don't think that permanent channels are a good idea at all. I= 'm=20 quite sure you discussed this topic a lot before my join to the SILC proj= ect=20 and I should go and read the archive but this is not something i'm going = to=20 do very soon :-) So for those who are interested to my opinion.. I think that users should= not=20 have the permission to do anything permanent on a network, because users = are=20 defined as untrusted, and unfortunately server and router admins too.=20 Avoiding permanent channels would prevent many troubles with privileges=20 (creating, killing, and so on). The only "sane" solution is Undernet's style. You have a service/bot and=20 channels can only be registered by server opers. This would prevent many=20 abuses if for example you allow only the same oper that registered the=20 channel to unregister it. But I still remain against permanent channels. --=20 Johnny |
|
From: Johnny M. <jo...@th...> - 2002-04-10 20:16:26
|
On Wednesday 10 April 2002 18:13, you wrote: > hi, > > On Thu, Mar 28, 2002 at 06:30:30PM +0100, Pekka Riikonen wrote: > > o Permanent channels? Wider founder support? Permanent channels vs= =2E > > Wider founder support? The founder support would be cell wide, and > > protected by backup routers as well. Permanency for channels can be > > achieved by defining that channel does not cease to exist even if > > last user leaves the channel, if the founder mode is set. This woul= d > > be cell wide as well. For these to fail, catastrophic network > > failure is required. > > with introduction of permanent channels and wider founder support we > will need to define anti-abuse practice which will help router > administrators to remove (kill) unwanted channels. this issue was > discussed some time ago and iirc we haven't decided what would be the > best solution. my idea to prevent abuse from the side of router > administrators was to require two router admins to agree on removing > a channel. this would reduce abuse which can be caused by one single > person but it's not a silver bullet for every occasion. i can imagine = a > situation when there will be need for quickly removing big amount of > channels etc. > Honestly, I don't think that permanent channels are a good idea at all. I= 'm=20 quite sure you discussed this topic a lot before my join to the SILC proj= ect=20 and I should go and read the archive but this is not something i'm going = to=20 do very soon :-) So for those who are interested to my opinion.. I think that users should= not=20 have the permission to do anything permanent on a network, because users = are=20 defined as untrusted, and unfortunately server and router admins too.=20 Avoiding permanent channels would prevent many troubles with privileges=20 (creating, killing, and so on). The only "sane" solution is Undernet's style. You have a service/bot and=20 channels can only be registered by server opers. This would prevent many=20 abuses if for example you allow only the same oper that registered the=20 channel to unregister it. But I still remain against permanent channels. --=20 Johnny |
|
From: Johnny M. <jo...@th...> - 2002-04-10 20:11:46
|
I'm sending a copy of this message.. it looks like the mailing list refus= ed=20 it :-) too bad. ---------- Forwarded Message ---------- Subject: Re: New branch and new protocol development Date: Wed, 10 Apr 2002 18:46:05 +0200 From: Johnny Mnemonic <jo...@th...> To: sil...@li... On Wednesday 10 April 2002 18:13, you wrote: > hi, > > On Thu, Mar 28, 2002 at 06:30:30PM +0100, Pekka Riikonen wrote: > > o Permanent channels? Wider founder support? Permanent channels vs= =2E > > Wider founder support? The founder support would be cell wide, and > > protected by backup routers as well. Permanency for channels can be > > achieved by defining that channel does not cease to exist even if > > last user leaves the channel, if the founder mode is set. This woul= d > > be cell wide as well. For these to fail, catastrophic network > > failure is required. > > with introduction of permanent channels and wider founder support we > will need to define anti-abuse practice which will help router > administrators to remove (kill) unwanted channels. this issue was > discussed some time ago and iirc we haven't decided what would be the > best solution. my idea to prevent abuse from the side of router > administrators was to require two router admins to agree on removing > a channel. this would reduce abuse which can be caused by one single > person but it's not a silver bullet for every occasion. i can imagine = a > situation when there will be need for quickly removing big amount of > channels etc. Honestly, I don't think that permanent channels are a good idea at all. I= 'm quite sure you discussed this topic a lot before my join to the SILC proj= ect and I should go and read the archive but this is not something i'm going = to do very soon :-) So for those who are interested to my opinion.. I think that users should= not have the permission to do anything permanent on a network, because users = are defined as untrusted, and unfortunately server and router admins too. Avoiding permanent channels would prevent many troubles with privileges (creating, killing, and so on). The only "sane" solution is Undernet's style. You have a service/bot and channels can only be registered by server opers. This would prevent many abuses if for example you allow only the same oper that registered the channel to unregister it. But I still remain against permanent channels. -- Johnny --=20 Johnny |
|
From: Johnny M. <jo...@th...> - 2002-04-10 19:43:44
|
I'm sending a copy of this message.. it looks like the mailing list refus= ed=20 it :-) too bad. ---------- Forwarded Message ---------- Subject: Re: New branch and new protocol development Date: Wed, 10 Apr 2002 18:46:05 +0200 From: Johnny Mnemonic <jo...@th...> To: sil...@li... On Wednesday 10 April 2002 18:13, you wrote: > hi, > > On Thu, Mar 28, 2002 at 06:30:30PM +0100, Pekka Riikonen wrote: > > o Permanent channels? Wider founder support? Permanent channels vs= =2E > > Wider founder support? The founder support would be cell wide, and > > protected by backup routers as well. Permanency for channels can be > > achieved by defining that channel does not cease to exist even if > > last user leaves the channel, if the founder mode is set. This woul= d > > be cell wide as well. For these to fail, catastrophic network > > failure is required. > > with introduction of permanent channels and wider founder support we > will need to define anti-abuse practice which will help router > administrators to remove (kill) unwanted channels. this issue was > discussed some time ago and iirc we haven't decided what would be the > best solution. my idea to prevent abuse from the side of router > administrators was to require two router admins to agree on removing > a channel. this would reduce abuse which can be caused by one single > person but it's not a silver bullet for every occasion. i can imagine = a > situation when there will be need for quickly removing big amount of > channels etc. Honestly, I don't think that permanent channels are a good idea at all. I= 'm quite sure you discussed this topic a lot before my join to the SILC proj= ect and I should go and read the archive but this is not something i'm going = to do very soon :-) So for those who are interested to my opinion.. I think that users should= not have the permission to do anything permanent on a network, because users = are defined as untrusted, and unfortunately server and router admins too. Avoiding permanent channels would prevent many troubles with privileges (creating, killing, and so on). The only "sane" solution is Undernet's style. You have a service/bot and channels can only be registered by server opers. This would prevent many abuses if for example you allow only the same oper that registered the channel to unregister it. But I still remain against permanent channels. -- Johnny --=20 Johnny |
|
From: Johnny M. <jo...@th...> - 2002-04-10 19:33:55
|
I'm sending a copy of this message.. it looks like the mailing list refus= ed=20 it :-) too bad. ---------- Forwarded Message ---------- Subject: Re: New branch and new protocol development Date: Wed, 10 Apr 2002 18:46:05 +0200 From: Johnny Mnemonic <jo...@th...> To: sil...@li... On Wednesday 10 April 2002 18:13, you wrote: > hi, > > On Thu, Mar 28, 2002 at 06:30:30PM +0100, Pekka Riikonen wrote: > > o Permanent channels? Wider founder support? Permanent channels vs= =2E > > Wider founder support? The founder support would be cell wide, and > > protected by backup routers as well. Permanency for channels can be > > achieved by defining that channel does not cease to exist even if > > last user leaves the channel, if the founder mode is set. This woul= d > > be cell wide as well. For these to fail, catastrophic network > > failure is required. > > with introduction of permanent channels and wider founder support we > will need to define anti-abuse practice which will help router > administrators to remove (kill) unwanted channels. this issue was > discussed some time ago and iirc we haven't decided what would be the > best solution. my idea to prevent abuse from the side of router > administrators was to require two router admins to agree on removing > a channel. this would reduce abuse which can be caused by one single > person but it's not a silver bullet for every occasion. i can imagine = a > situation when there will be need for quickly removing big amount of > channels etc. Honestly, I don't think that permanent channels are a good idea at all. I= 'm quite sure you discussed this topic a lot before my join to the SILC proj= ect and I should go and read the archive but this is not something i'm going = to do very soon :-) So for those who are interested to my opinion.. I think that users should= not have the permission to do anything permanent on a network, because users = are defined as untrusted, and unfortunately server and router admins too. Avoiding permanent channels would prevent many troubles with privileges (creating, killing, and so on). The only "sane" solution is Undernet's style. You have a service/bot and channels can only be registered by server opers. This would prevent many abuses if for example you allow only the same oper that registered the channel to unregister it. But I still remain against permanent channels. -- Johnny --=20 Johnny |
|
From: Johnny M. <jo...@th...> - 2002-04-10 19:20:11
|
I'm sending a copy of this message.. it looks like the mailing list refus= ed=20 it :-) too bad. ---------- Forwarded Message ---------- Subject: Re: New branch and new protocol development Date: Wed, 10 Apr 2002 18:46:05 +0200 From: Johnny Mnemonic <jo...@th...> To: sil...@li... On Wednesday 10 April 2002 18:13, you wrote: > hi, > > On Thu, Mar 28, 2002 at 06:30:30PM +0100, Pekka Riikonen wrote: > > o Permanent channels? Wider founder support? Permanent channels vs= =2E > > Wider founder support? The founder support would be cell wide, and > > protected by backup routers as well. Permanency for channels can be > > achieved by defining that channel does not cease to exist even if > > last user leaves the channel, if the founder mode is set. This woul= d > > be cell wide as well. For these to fail, catastrophic network > > failure is required. > > with introduction of permanent channels and wider founder support we > will need to define anti-abuse practice which will help router > administrators to remove (kill) unwanted channels. this issue was > discussed some time ago and iirc we haven't decided what would be the > best solution. my idea to prevent abuse from the side of router > administrators was to require two router admins to agree on removing > a channel. this would reduce abuse which can be caused by one single > person but it's not a silver bullet for every occasion. i can imagine = a > situation when there will be need for quickly removing big amount of > channels etc. Honestly, I don't think that permanent channels are a good idea at all. I= 'm quite sure you discussed this topic a lot before my join to the SILC proj= ect and I should go and read the archive but this is not something i'm going = to do very soon :-) So for those who are interested to my opinion.. I think that users should= not have the permission to do anything permanent on a network, because users = are defined as untrusted, and unfortunately server and router admins too. Avoiding permanent channels would prevent many troubles with privileges (creating, killing, and so on). The only "sane" solution is Undernet's style. You have a service/bot and channels can only be registered by server opers. This would prevent many abuses if for example you allow only the same oper that registered the channel to unregister it. But I still remain against permanent channels. -- Johnny |
1 message has been excluded from this view by a project administrator.
