silc-devel — Main SILC development mailing list

Re: New branch and new protocol development

[Wojciech S. C. <oh...@se...>]

Lubomir Sedlacik wrote:
[on Wed, Apr 10, 2002 at 07:35:58PM +0200]
(>) Owego dnia Lubomir Sedlacik napisa=B3(a):

> > userland - i.e.: : /join #warchan : ServerAdmin: this channel is
> > unavaliable on this server [reason];
Forgotten. It was a misunderstanding.

> we don't want to restrict users and say them what they can
> and cannot do, we want to prevent abuse.
Hm. Contradictory.=20
We want to say to users: 'you cannot write four lines and then do=20
=2E/makemegod < /usr/share/dict/words=20
and become an founder of the whole universe'. We also want to say:=20
'you cannot hog the server sitin on 1000s of channels. And so on.

What kind of abuse you'd try to prevent then. From whom? From
a dial-up user? From cable user with one ip? From /24 net on a T1?
 From an AS operator having /8 net and four 155M legsi?
=20
If you'd meant 'from a router operator', IMHO you are trying to prevent
sun to shine.=20

I do think *mesh*. IOW, for me that it's an organisational,=20
not a programmatic issue.

> > I'd like to point out that routers are supposed to 'route' not to
> > 'decide' ;)
> please, read the specs and see what are silc routers for.
Mhm. I have current silc_protocol.pdf right at my eyes. Despite
docs say 'router servers are servers that actually handles the
message routing' it seems to me (from the mesh pics below) that=20
a routing layer is logically separated from 'normal server' layer=20
(I know I should RTFS too. In nearest spare time :)
Considering scalability of such mesh (in spite of base 'ring' config, if=20
'backup routes' were introduced - the real topology would be a mesh)

I think that in next generation of the protocol the functions performed
by the router should be minimalised to, ough, just routing - mostly due
to overheads of publickey crypto.

> > You cannot avoid DoSes if one can control a /24 or bigger subnet.  But
> > usually persons responsible for subnets from /26 up are easy to find.
> yes, that's exactly why killing channels is neccessary.

Excusme, never saw a human who won a race with simple while(1) loop.

Thou got the point. We need to kill channels done by such a loop.
And the simplest thing we can do to prewent such abuse is to force=20
enough delay to someone's else while(1) loop.

Imagine a token, tied at net level to the user's key.
You (a key) can become a founder of a i.e. I chans/weekly,=20
N channels/monthly. A channel protection (founder rights)=20
will disappear if ie. channel hasnt been attended by minimum of=20
M different keys by past O days.
Such automata was yrs ago quite functional on dalnet.

> -- Lubomir Sedlacik <sa...@Xt...>   ASCII Ribbon campaign against  /=
"\ --
> --                  <sa...@si...>   e-mail in gratuitous HTML and  \=
 / --

Regards, Ohir.

--

Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE
   =20

Re: New branch and new protocol development

[Lubomir S. <sa...@Xt...>]

hi,

first i would like to suggest everyone to read protocol specifications
and only then respond to protocol issues because i see a lot of
misunderstanding of current status and behaviour in replies.

On Wed, Apr 10, 2002 at 07:22:58PM +0200, Wojciech S. Czarnecki wrote:
> This is not practical. Now it can translate to "two of five persons
> decide".  Quite reasonably. Thou if it will became "two of fourty"..?

it is better than *one* person.  this is meant as a prevention mechanism
agains abuse from admins to users.  please, note that i said "router"
admins.  there wouldn't be that much router admins as server admins and
that was just an idea.  if you have a better solution, i will be glad to
hear about it.

> Me thinks, that particular server admin should be able to kill/ban
> particular channel on his/her *server*. With clear notification to the
> userland - i.e.: : /join #warchan : ServerAdmin: this channel is
> unavaliable on this server [reason];

this is about something completely different and it doesn't make any
sense to me.  we don't want to restrict users and say them what they can
and cannot do, we want to prevent abuse.

> I'd like to point out that routers are supposed to 'route' not to
> 'decide' ;)

please, read the specs and see what are silc routers for.

> Yep. Souldn't it be proper I-lines implementation (ie. not more than N
> channels -created-operated-attended- from ip/class/domain)?

that would be fine but it won't solve everything, it is worth
implementing, though.

> You cannot avoid DoSes if one can control a /24 or bigger subnet.  But
> usually persons responsible for subnets from /26 up are easy to find.

yes, that's exactly why killing channels is neccessary.


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     =
 --

Re: New branch and new protocol development

[Wojciech S. C. <oh...@se...>]

Lubomir Sedlacik wrote:
[on Wed, Apr 10, 2002 at 06:13:01PM +0200]
(>) Owego dnia Lubomir Sedlacik napisa=B3(a):
> 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 is not practical. Now it can translate to "two of five persons decide".
Quite reasonably. Thou if it will became "two of fourty"..?

Me thinks, that particular server admin should be able to kill/ban
particular channel on his/her *server*. With clear notification
to the userland - i.e.:=20
: /join #warchan
: ServerAdmin: this channel is unavaliable on this server [reason];

> this would reduce abuse which can be caused by one single
> person but it's not a silver bullet for every occasion.
I'd like to point out that routers are supposed to 'route'
not to 'decide' ;)

> i can imagine a situation when there will be need for quickly=20
> removing big amount of channels etc.
Yep. Souldn't it be proper I-lines implementation (ie. not more than
N channels -created-operated-attended- from ip/class/domain)?

You cannot avoid DoSes if one can control a /24 or bigger subnet.=20
But usually persons responsible for subnets from /26 up are easy to find.

> regards,
> -- Lubomir Sedlacik <sa...@Xt...>   ASCII Ribbon campaign against  /=
"\ --
> --                  <sa...@si...>   e-mail in gratuitous HTML and  \=
 / --

Regards, Ohir.

--

Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE
    =20

Re: New branch and new protocol development

[Scott M L. <da...@bo...>]

--On Wednesday, April 10, 2002 6:13 PM +0200 Lubomir Sedlacik 
<sa...@Xt...> wrote:

> 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.

My only problem with this is simple, in an idealistic world you can find 2 
people agree.  My problem is more obtuse.  I see this everywhere with Opers 
telling other opers do this or i'll get your O removed, and what not.  It's 
a very paradoxial society, and i fear making 2 admins agree on something to 
be a bad idea.

Truthfully it would be more ideal and harder at the same moment, to have 
4-5 users (non-opers) who decide in a wholy and just manner wether the 
channel or user should stay/go.  Then those 4-5users report back to those 
2admins if you wish, and let them know their decision.

Truthfully people can circumvent it if they want to, i am just a little 
pessimestic.

> this could be accomplished similar way as private message or file
> transfer negotiation is done today.  one router admin send a request for
> killing a channel to the second one and he can accept it or not.  iirc
> Bostik has few ideas about similar(?) solution for killing channels so
> maybe he could have some comments.  of course i would like anyone to
> participate on searching for The_Right(tm) solution.

Re: New branch and new protocol development

[Lubomir S. <sa...@Xt...>]

hi,

On Thu, Mar 28, 2002 at 06:30:30PM +0100, Pekka Riikonen wrote:
>  o Permanent channels?  Wider founder support?  Permanent channels vs.
>  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 would
>  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.

this could be accomplished similar way as private message or file
transfer negotiation is done today.  one router admin send a request for
killing a channel to the second one and he can accept it or not.  iirc
Bostik has few ideas about similar(?) solution for killing channels so
maybe he could have some comments.  of course i would like anyone to
participate on searching for The_Right(tm) solution.

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     =
 --

[bombyx] Another release of Bombyx: Usability fixes and COLOR!

[Zed S. <ze...@ze...>]

Hello Again,

I just put up another release of Bombyx for everyone to try out.  This
release is fairly good and has most features you need for basic chat.
Still no private chat or file transfer, and that's probably the number 1
requested feature (more on that later).

This release offers the following good stuff:

* The Connect Window behaves as most people expected it. The close
button now has two states so that it understands that it should quit
when you are not connected, and "close" when you are.
* The first time you run, bombyx will ask if you want to seed your
server list with a couple of servers.
* Join window works like connect window (close vs. disconnect).
* All Chat and Focused chat windows are resizable, with working word
wrap (although, kinda hacked).
* The separator character between names has change to improve
readability.  Try it out and let me know if you hate it/like it.
* You can now select an arbitrary COLOR for each chat window.  And, all
colors look half decent (although some have weird side effects).
* Focused chat windows adopt the current color of their parent.
* Focused chat now works as expected.  When you type something in a
focused chat, it will replicate what you said in the parent chat window.
* Updated the README file to give some better instructions.
* Bunch of minor problems fixed as I ran into them.

That's about it for now.  Thanks to everyone who has tested thus far and
given feedback.  When I have time, I'll formally thank you in the docs.

And please, feel free to send me your feature requests and feedback.
They are greatly appreciated.

Finally, you can get both Linux and FreeBSD binaries for it at
http://bombxy.sourceforge.net/ and you can CVS checkout (anonymous) the
source if you'd like to compile it.  It should be much easier to do with
the build improvements from the last release.

Thanks a bunch, and let me know if anything is wrong.

Zed A. Shaw



P.S. I'm desperate for time, and would like to get a Win32 binary.  If
anyone can swing compiling bombyx on Win32 with the MinGW compiler (or,
whatever), I will be forever in your debt.  I've managed to get pretty
close, but I have limited experience with the tools, and even more
limited time.  So, anyone willing to help?

[bombyx] Another release of Bombyx: Usability fixes and COLOR!

[Zed S. <zed...@ub...>]

Hello Again,

I just put up another release of Bombyx for everyone to try out.  This
release is fairly good and has most features you need for basic chat.
Still no private chat or file transfer, and that's probably the number 1
requested feature (more on that later).

This release offers the following good stuff:

* The Connect Window behaves as most people expected it. The close
button now has two states so that it understands that it should quit
when you are not connected, and "close" when you are.
* The first time you run, bombyx will ask if you want to seed your
server list with a couple of servers.
* Join window works like connect window (close vs. disconnect).
* All Chat and Focused chat windows are resizable, with working word
wrap (although, kinda hacked).
* The separator character between names has change to improve
readability.  Try it out and let me know if you hate it/like it.
* You can now select an arbitrary COLOR for each chat window.  And, all
colors look half decent (although some have weird side effects).
* Focused chat windows adopt the current color of their parent.
* Focused chat now works as expected.  When you type something in a
focused chat, it will replicate what you said in the parent chat window.
* Updated the README file to give some better instructions.
* Bunch of minor problems fixed as I ran into them.

That's about it for now.  Thanks to everyone who has tested thus far and
given feedback.  When I have time, I'll formally thank you in the docs.

And please, feel free to send me your feature requests and feedback.
They are greatly appreciated.

Finally, you can get both Linux and FreeBSD binaries for it at
http://bombxy.sourceforge.net/ and you can CVS checkout (anonymous) the
source if you'd like to compile it.  It should be much easier to do with
the build improvements from the last release.

Thanks a bunch, and let me know if anything is wrong.

Zed A. Shaw



P.S. I'm desperate for time, and would like to get a Win32 binary.  If
anyone can swing compiling bombyx on Win32 with the MinGW compiler (or,
whatever), I will be forever in your debt.  I've managed to get pretty
close, but I have limited experience with the tools, and even more
limited time.  So, anyone willing to help?

Re: rehash

[Pekka R. <pri...@ik...>]

HI,

: today i was changing my silcd.conf and was wondering if there is the
: possibility to rehash the config other than 'kill -HUP silcd.pid'.
: more like '/silcoper rehash'.
:
Currently there isn't command for that.  The reason for this is that I
don't want the SILC protocol to define any of administrative commands.
How server is started, shutdown or reconfigured is totally implementation
issue and protocol should not touch that.  To solve this, it is planned
that some kind of admin-plugin will be programmed for the silcd which then
can be used to give for example the rehash command.

: also i imagined the scenery when e.g. everybody would leave channel #silc
: on silc.silcnet.org. - allthough pekka set '/cmode #silc +ft' the client
: who first creates the channel #silc again would be founder. this could be
: managed by creating default channels with apropriate channelmodes via
: config...
:
This is actually on TODO/think list for protocol version 1.1.  Probably I
will do this. :)

	Pekka
________________________________________________________________________
 Pekka Riikonen                                 priikone at silcnet.org
 Secure Internet Live Conferencing (SILC)       http://silcnet.org/

rehash

[rene p. <re...@so...>]

hi,
today i was changing my silcd.conf and was wondering if there is the
possibility to rehash the config other than 'kill -HUP silcd.pid'.
more like '/silcoper rehash'.

also i imagined the scenery when e.g. everybody would leave channel #silc
on silc.silcnet.org. - allthough pekka set '/cmode #silc +ft' the client
who first creates the channel #silc again would be founder. this could be
managed by creating default channels with apropriate channelmodes via
config...

what you think?

greetings

rene

--
pgp-key:
/usr/local/bin/lynx -dump http://www.so36.net/~rene/rene.asc | pgpin

SILCNET.ORG

[Christine H. <re...@tr...>]

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3D=
iso-8859-1">
<!-- 2.2 --> 
<title></title>
</head>
<body bgcolor=3D"#FFFFFF">
<table width=3D"600" border=3D"0" cellspacing=3D"0" cellpadding=3D"0">
  <tr>
    <td><font face=3D"Verdana, Arial, Helvetica, sans-serif" size=3D=
"2">Hi<br>
      <br>
      I visited <a href=3D"http://www.trafficmagnet.net">SILCNET.ORG</a>, and =

      noticed that you're not listed on some search engines! I think we can =
offer 
      you a service which can help you increase traffic and the number of =
visitors 
      to your website.<br>
      <br>
      I would like to introduce you to <a href=3D=
"http://www.trafficmagnet.net">TrafficMagnet.net</a>. We offer a unique =
technology 
      that will submit your website to over 300,000 search engines and =
directories 
      every month.<br>
      <br>
      </font> 
      <table width=3D"398" border=3D"0" cellspacing=3D"0" cellpadding=3D"0" =
align=3D"center">
        <tr><td><a href=3D"http://www.trafficmagnet.net"><img src=3D=
"http://image10.trafficmagnet.net/image/logo.gif" width=3D"137" height=3D=
"136" border=3D"0"></a></td>
          <td><a href=3D"http://www.trafficmagnet.net"><img src=3D=
"http://image10.trafficmagnet.net//SC173/001/019/gec.jpg" width=3D"197" =
height=3D"141" border=3D"1"></a></td>
          <td valign=3D"bottom"><a href=3D"http://www.trafficmagnet.net"><img =
src=3D"http://image10.trafficmagnet.net/image/signup.gif" width=3D"62" =
height=3D"136" border=3D"0"></a></td>
        </tr>
      </table>
      <font face=3D"Verdana, Arial, Helvetica, sans-serif" size=3D"2"><br>
      You'll be surprised by the low cost, and by how effective this website =
promotion 
      method can be. <br>
      <br>
      To find out more about TrafficMagnet and the cost for submitting your =
website 
      to over 300,000 search engines and directories, visit <a href=3D=
"http://www.trafficmagnet.net">www.TrafficMagnet.net</a>. 
      <br>
      <br>
      I would love to hear from you. <br>
      <br><br>
      Best Regards,<br><br>
      Christine Hall <br>
      Sales and Marketing <br>
      E-mail: chr...@tr... <br>
      <a href=3D=
"http://www.trafficmagnet.net">http://www.TrafficMagnet.net</a> 
      </font> </td>
  </tr>
</table>
</body>
</html>

Re: Have problems with SILC. (fwd)

[rasto r. <ric...@is...>]

hello,


 > Hello (I'm using Windows XP.)
 > First of all I downloaded the windows SILC (silc-0.7.6.2.exe.zip), and I
 > extract the files to c:\silc\. And I started the program.I've got the
 > massage: Couldn't create //.silc directory". And I typed "Set
 > home=c:\silc\". IT created a private key and a public key.And I 
started the
 > program, but the "Couldn't create //.silc directory" came back, and 
it did't
 > help to type "set home=c:\silc\".I downloaded the newst version i found,
 > (silc-0.8.5.exe.zip).And I replaced it with the old exe file. But 
then this
 > error came: "this application has failed to start because cygncurses5.dll
 > was not found.Re-install the application may fix this problem." And now I
 > don't know what to do. Can you mail me back what to do?


this ncurses linkage problem in 0.8.x release is the thing why i don`t 
contributed new version, i have problem compiling ncurses statically 
into 0.8.x client. copying ncurses dll into same directory as .exe file 
doesn`t help.

your env. variables problems should be solved by running silc with .bat 
file included in package. as you can see while reading it, it is setting 
all needed term and home variables as well as executing binary.

working on "good" 0.8.x :))


riki

Have problems with SILC. (fwd)

[Pekka R. <pri...@ik...>]

Somebody please answer this.  Riki?


---------- Forwarded message ----------
Date: Wed, 03 Apr 2002 18:45:08 +0200
From: Eirik Swifty <ei...@ms...>
To: in...@si...
Subject: Have problems with SILC.

Hello (I'm using Windows XP.)
First of all I downloaded the windows SILC (silc-0.7.6.2.exe.zip), and I
extract the files to c:\silc\. And I started the program.I've got the
massage: Couldn't create //.silc directory". And I typed "Set
home=c:\silc\". IT created a private key and a public key.And I started the
program, but the "Couldn't create //.silc directory" came back, and it did't
help to type "set home=c:\silc\".I downloaded the newst version i found,
(silc-0.8.5.exe.zip).And I replaced it with the old exe file. But then this
error came: "this application has failed to start because cygncurses5.dll
was not found.Re-install the application may fix this problem." And now I
don't know what to do. Can you mail me back what to do?

1 question.
Can I use SILC to seet up a server on LAN?And what do I have to do so I can
join a local sever like that..??

PS:Can you please answer me.....becasue to me SILC sound's like a great
computer program.
Eirik

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

Silsa project need developers

[Dejan L. <le...@en...>]

Hi to all,
maybe Mikka has posted some similar post like this but, anyway, sorry if so... :)

Well on https://sourceforge.net/people/viewjob.php?group_id=49891&job_id=7329 You can see Mikka's call to developers to help Silsa (sub)project. SILSA is cross-platform SILC client mainly developed in VisualC++, based on FLTK (www.fltk.org), the best cross-platform library ever made in my (our) opinion...

Unfortunately, we don't have so much time for all things... SILSA project is part of EDE (Equinox Desktop Environment), something similar to KDE, or GNOME let's say, and it's development is taking a lot of our free time.

If there are C/C++ coders willing to help, please contact somebody from EDE crew ... EDE project is on http://www.sf.net/projects/ede and SILSA source is already available from our main CVS repository.

Best regards


            .------------------------------------------------.
    .^.     | Dejan Lekic           | le...@en...  |
    /V\     |-----------------------| http://dl.9mb.net      |
   // \\    | phone: +46739310378   `------------------------|
  /(   )\   | Developer, MySQL DBA, sysadmin :: LekaMan#IRC  |
   ^^-^^    `------------------------------------------------'

[Bombyx] New Release of Bombyx. Very functional. Very pretty.

[Zed S. <ze...@ze...>]

Hello Everyone,

This is just a quick message to let everyone know that I released
another version of Bombyx.  This release is very functional and has most
of the "big" features needed to chat.  It also has a very nice look to
it.

You can get the latest releases at http://bombyx.sourceforge.net/ (look
for the releases link) which are:

* bombyx-20020331.tar.gz -- source code (should compile on Linux, maybe
FreeBSD).
* bombyx-20020331-freebsd.tar.gz -- FreeBSD 4.5 static binary.
* bombyx-20020331-linux.tar.gz -- Linux static binary.


This release is very usable, but still has some kinks to iron out.  This
is pretty much the way bombyx will look and work from now on.  Here's
the major things to note:

* Manages a list of servers for you, remembering server keys.
* Multiple servers and multiple channels at the same time.
* Based on extensive usability studies, with more to come.
* A VERY annoying agent called Simple Sammy.  Only use him if you want
to be hated :-)
* Joining channels is very sane, with all the usual things.
* Connecting to servers is very easy.
* Public and Private keys are generated properly, and not regenerated
every time.
* Chat window lists users properly.
* Chat window word wraps now, and is a little wider.
* You can do a "Focus Chat" which lets you focus on a few people.  The
focus window simply displays only what these people say, and will
"pop-up" if someone talks while it is minimized.
* Most commands work and are connected to their windows.  /list will
update the list of channels in Join, etc.
* Nice new "Plastic" look for artistic appeal.
* Should be fairly internationalized, but I'm not sure.

That's all I can remember off the top of my very tired head.  This
release is fairly significant, and very much different from previous
releases.

Please feel free to shoot me an e-mail or chat with me on #silc or
#bombyx on silc.silcnet.org anytime.  Especially if you have a crash, a
bug, a complaint, or you get it to compile on Windows.  If you get it to
compile on windows, I will be forever in your debt.

Thanks for your time.

Zed A. Shaw

SILC Client 0.8.5

[Pekka R. <pri...@ik...>]

The SILC Client version 0.8.5 is now available!  The software is available
from the following sources:

        http://silcnet.org/
        ftp://ftp.silcnet.org/

This release fixes only cygwin related problems and you do not need to
upgrade unless you want to use client on cygwin.  Our last cygwin client
was 0.7.6.2 and all 0.8 versions crash on cygwin.  Well, I took the time
today to debug it on cygwin and found out that our old friend Glib is
again to blame for the crashes.  After changing some glib function calls
to our own utility routines everything works again fine.  I made cygwin
binary now myself, but I hope that riki continues to contribute the cygwin
binary later. :)  Someone may think that making anew release just for
cygwin fixes is too much, then you thought wrong. :)  Cygwin binary is the
most downloaded client package from silcnet.org, which only tells that the
need to proper Windows client is huge.

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/

(no subject)

[Henrik A. <he...@br...>]

** ERROR **: Couldn't create file://.silc directory
aborting...
      0 [sig] silc 760 open_stackdumpfile: Dumping stack trace to =
silc.exe.stack
dump



Greetings
Henrik

SILC Server 0.8.3

[Pekka R. <pri...@ik...>]

The SILC Server version 0.8.3 is now available!  The software is available
from the following sources:

        http://silcnet.org/
        ftp://ftp.silcnet.org/

Sorry but here we go again.  Another bugfix release.  This version fixes
nasty decryption failure at the client end because server produces MAC
with wrong HMAC when relaying notify packets (such as INVITE notify
packets).  Also hostname resolving is fixed on those systems that does not
support IPv6 and doesn't compile it in.  Also some minor logfile flushing
bug is fixed as well.

Please refer to the ChangeLog on the website or the CHANGES file in the
package for complete list of change.  And, please report all bugs here on
the mailing list.

	Pekka
________________________________________________________________________
 Pekka Riikonen                                 priikone at silcnet.org
 Secure Internet Live Conferencing (SILC)       http://silcnet.org/

New branch and new protocol development

[Pekka R. <pri...@ik...>]

Hello,

I will soon, in about week or so, start the development of the new SILC
protocol version 1.1  This includes designing the protocol, writing new
specifications and implementing it to the server and to the client.  Some
time during April we will release 0.9 version of the Toolkit, and
thereafter client and server will start using the 1.1 version of the
protocol.  I will also submit the new protocol specifications to the IETF.

To prepare this work I have now branched the SILC CVS.  Actually, I've
branched it for protool version 1.0, since I will develop the 1.1 version
in the trunk.  The name of the branch is silc_protool_1_0_branch, and all
0.8.x bugfix releases while waiting 0.9 version will be done and released
from that branch.  The trunk will include the protocol version 1.1
development and the 0.9 version will be released from the trunk.  This way
we'll also have the history in the CVS for checking out protocol version
1.0 if needed.

After 0.9 is ready I will actually create yet another branch for the 1.0
development, most likely named silc_1_0_branch.  It will be the branch
that is used to create the stable 1.0 release, and the trunk will continue
with the development of the new stable 1.1 version of the server and
client (see TODO-1.0).  But, I will get back on this after 0.9 is ready.

To checkout the new branch, if you want to do that, can be done by giving
the command:

	cvs co -r silc_protocol_1_0_branch silc


New Protocol Development:

I will paste here the TODO list for the 1.1 protocol version, and after
that I'll shortly go through some issues that are still open, and I'm open
for discussion on what 1.1 should include and how they should be done.
Here is what WILL be done into protocol version 1.1:

 1. Re-define the Status Payload: it is now 16 bits, split it into two
    8 bits fields.  First field includes status types from 0 - 9 and
    10 - n *if* it is not an list of errors.  If it is list of errors then
    the first field includes 1, 2 and/or 3, and the second field includes
    the error status 10 - n.  This way it is possible to send multiple
    errors (list of errors) and we have a way to tell the receiver that
    there will be other errors as well.  The second field is used only
    if there is list of errors.  If normal status, or normal (single)
    error status the second field is set to zero, and must be ignored.
    Hence, the status works same way as now except for list of errors.

 2. Define that WHOIS and IDENTIFY commands must send list of errors
    if multiple Client ID (or Channel ID and Server ID for IDENTIFY) was
    requested and was not found.  Each unfound entry must cause an error
    command reply to the sender.  Also define that errors must be sent
    *after* sending successfully found entries (this way receiver may
    ignore them).

 3. Define the NICK_CHANGE notify to send the changed nickname as a new
    third argument.  This will make the NICK_CHANGE notify handling easier
    in the receiver's end (client primarily) since it removes the
    requirement that receiver must resolve (using IDENTIFY or WHOIS) the
    new Client ID received in the notify (because of the new nickname is
    unknown).

 4. Add "request parameters" or similar to the WHOIS command, which can
    be used to request various parameters (something not returned by
    standard WHOIS command) about clients (info that could be fetched
    even from clients).  Additional specification (or appendix) should
    be done to define the payload and the parameters.  It could be used
    to make the WHOIS command support various search conditions as well.
    This would be the way to extend the WHOIS command to support various
    new features without always making the command incompatible to previous
    version.

 6. Add perhaps SILENCE_USERS, SILENCE_OPERS channel user modes which
    can be used to silence (moderate) normal users and opers (this set
    only by founder).

 7. Channel Message Payload needs slight redesining to include the IV
    field to the MAC generation of the payload.  It is authenticated
    by the packet's MAC but not by the payload's MAC.  Since the IV
    belongs to the payload, its integrity should be protected by the
    payload MAC and not alone by packet MAC.

 8. Remove the administrative commands from the protocol all together.
    It does not make sense for the protocol to define how a server is
    reconnected or shutdown, since they are implementation and
    configuration issues.  Besides protocol provides only limited set of
    administrative commands and cannot define all that one could imagine.

 9. Add SILC_MESAGE_FLAG_REPLY for being other side to the
    SILC_MESSAGE_FLAG_REQUEST.  Add generic SILC_MESSAGE_FLAG_DATA, which
    can include generic payload, which can include generic data.  The
    payload definition is left out for now.

 10. Check command reply error status types in various commands,
     specifically NO_FOPRIV is missing from many commands.

 11. Change the wording in Private Message Key Payload definition to
     describe the problems of trusting the payload, and to indicate that
     the receiver may not accept the key in the payload, and to describe
     other means of distributing a key.

 13. Add the killer's client ID to the KILLED notify.

 14. The length of Arguments Num field in Notify Payload and Command
     Payload enforces that total of 256 arguments can be associated
     to a such payload.  However, command-xx draft specified much higher
     values, and these should be fixed.

And, here is some issues that I have not decided yet whether they are to
be done, and how they should be done.  These issues are open for general
discussion and actually I'd like to hear some ideas of what people think
the new protocol version should include and what it should not include,
and better yet, how the new stuff should work.  So now is the chance for
everyone to give their input to the development of the protocol.
Remaining issues:

 o Permanent channels?  Wider founder support?  Permanent channels vs.
   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 would be
   cell wide as well.  For these to fail, catastrophic network failure is
   required.

 o UTF-8 support/requirement?  How to be defined?  Maybe addition of
   SILC_MESSAGE_FLAG_UTF8 would solve the issue of sending text inside
   message payload.  This way, the preferred method of sending text
   as message (since a message == a binary message) would be to use that
   flag and UTF-8 encoding.  When the flag is not used, the issue is
   equivalent to present situation, and it is the recipient's
   responsibility to figure out the encoding.

   Some other text that is sent in protocol (like proposals in SKE) could
   be UTF-8 encoded, however US-ASCII definition for these can be
   sufficient too.

 o Payload for the new SILC_MESSAGE_FLAG_DATA (I have written preliminary
   draft, and it's available at http://silcnet.org/priikone/payload.txt).

 o Should SILC_MESSAGE_FLAG_ACTION flag associate payload?  This was
   discussed some time ago to figure out a way to send "actions" as
   messages, to make the message more alive.

 o Anything else?

If you have questions about these changes and/or the CVS situation please
do ask.

	Pekka
________________________________________________________________________
 Pekka Riikonen                                 priikone at silcnet.org
 Secure Internet Live Conferencing (SILC)       http://silcnet.org/

SILC Server 0.8.2

[Pekka R. <pri...@ik...>]

The SILC Server version 0.8.2 is now available!  The software is available
from the following sources:

        http://silcnet.org/
        ftp://ftp.silcnet.org/

As expected after major feature release here follows the bugfix release.
Very bad and unpleasent crash bug is fixed in this version.  I actually
had the test version of the 0.8.1 running for days on silc.silcnet.org 707
without any problems but this bug surfaced after I made a little change
and didn't test it. :)  It only tells that every little change should be
tested thoroughly always.

This version also adds new feature.  The rehash, or config file
reconfiguration suppor in HUP signal.  Johnny made great work and
introduced this feature in this release.  Note that currenty everything in
the config file cannot be reconfigured but all the basic stuff can be.
There's still features missing from this but for example reconfiguring
connections etc. is possible.

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/

/exec can't send output to channel

[Marian D. <ma...@st...>]

Hello,

It seems, it is impossible to send output of /exec to channel:

[#silc] /exec -out cat hm

[msg(#silc)] hm
 --- Irssi: process 0 (cat hm) terminated with return code 0
 --- Irssi: #silc: There is no such client

Tested with silc client 0.8.4.

Marian

SILC Client 0.8.4

[Pekka R. <pri...@ik...>]

The SILC Client version 0.8.4 is now available!  The software is available
from the following sources:

        http://silcnet.org/
        ftp://ftp.silcnet.org/

Just a quick bugfix release.  There isn't much changes but since this
version fixes some crashes I though to put it out.  KICKED notify handling
caused the client to crash later at some point and was generally handled
wrong way otherwise too so /KICK command didn't work too well.  There was
also bug in nickname formatting which caused that two same nicknames could
appear with same formatted name and thus make accessing those clients
difficult.  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/

Re: [bugreport] silc client 0.8.3 crashed on /DISCONNECT

[Pekka R. <pri...@ik...>]

: Date: Wed, 27 Mar 2002 21:47:52 +0100
: From: Lubomir Sedlacik <sa...@Xt...>
: To: sil...@li...
: Subject: [bugreport] silc client 0.8.3 crashed on /DISCONNECT
:
: #0  0x80b6ed3 in silc_client_remove_from_channels ()
: #1  0x80c9bf0 in silc_client_del_client ()
: #2  0x80b602a in silc_client_close_connection ()
: #3  0x808c820 in silc_queries_deinit ()
: #4  0x80a6fc0 in signal_remove ()
: #5  0x80a709e in signal_emit ()
:
Fixed in 0.8.4.

	Pekka
________________________________________________________________________
 Pekka Riikonen                                 priikone at silcnet.org
 Secure Internet Live Conferencing (SILC)       http://silcnet.org/

[bugreport] silc client 0.8.3 crashed on /DISCONNECT

[Lubomir S. <sa...@Xt...>]

#0  0x80b6ed3 in silc_client_remove_from_channels ()
#1  0x80c9bf0 in silc_client_del_client ()
#2  0x80b602a in silc_client_close_connection ()
#3  0x808c820 in silc_queries_deinit ()
#4  0x80a6fc0 in signal_remove ()
#5  0x80a709e in signal_emit ()
#6  0x80a2674 in server_disconnect ()
#7  0x80a8e76 in write_buffer_deinit ()
#8  0x80a6fc0 in signal_remove ()
#9  0x80a709e in signal_emit ()
#10 0x8097872 in commands_remove_module ()
#11 0x809799c in commands_remove_module ()
#12 0x80a6fc0 in signal_remove ()
#13 0x80a709e in signal_emit ()
#14 0x80635ce in handle_key ()
#15 0x80a6fc0 in signal_remove ()
#16 0x80a709e in signal_emit ()
#17 0x8080e8b in keyboard_entry_redirect ()
#18 0x80a6fc0 in signal_remove ()
#19 0x80a709e in signal_emit ()
#20 0x8080bc3 in key_configure_remove ()
#21 0x8080d38 in key_pressed ()
#22 0x806351b in handle_key ()
#23 0x80639db in handle_key ()
#24 0x809c7c3 in log_away_deinit ()
#25 0x4827b5a0 in g_io_unix_dispatch () from /usr/pkg/lib/libglib.so.13
#26 0x4827cc3e in g_main_dispatch () from /usr/pkg/lib/libglib.so.13
#27 0x4827d237 in g_main_iterate () from /usr/pkg/lib/libglib.so.13
#28 0x4827d2e9 in g_main_iteration () from /usr/pkg/lib/libglib.so.13
#29 0x80720ce in main ()
#30 0x8061760 in ___start ()

--=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     =
 --

SILC Server 0.8.1

[Pekka R. <pri...@ik...>]

The SILC Server version 0.8.1 is now available!  The software is available
from the following sources:

        http://silcnet.org/
        ftp://ftp.silcnet.org/

And here we have finally a new version of server.  It's been over a month
and definitely too long, but there's some very nice new features and
fixes in this version.  This version fixes the checking of number of
incoming connections from same host.  There was a bug that if it was
configured for only one connection per host for servers, it affected
clients as well.  This is now fixed.  There's also bunch of fixes to
various notify type handlings on router.  Router now checks that incoming
notify is actually valid and what ever the notify is supposed to perform
is now checked whether it is allowed.  We used to trust notifys from
servers without checking whether they should even happen or not.  IPv6 is
also now fixed and the server supports IPv6 addresses.  Very much other
minor bugfixes and additions to the server as well was done.

Talking about new features then.  Major new feature in authentication is
the possibility to configure several public keys for one client connection.
I don't remember who was it but someone suggested this and after thinking
about it the idea was great.  So, it is now possible to for example make
configuration that says "I accept all incoming client connections, with
these listed public keys".  This means that you don't have to anymore bind
the public key to any specific host with client connections.  So, this is
valid now:

Client {
	PublicKey = "/path/to/the/user_my.key";
	PublicKey = "/path/to/the/user_221.key";
	PublicKey = "/path/to/the/user_313.key";
	PublicKey = "/path/to/the/user_314.key";
	PublicKey = "/path/to/the/user_399.key";
	Params = "clients";
};

Which says that all incoming client connections is allowed assuming they
provide correct public key, and the keys are listed there.  Note that this
feature works only with Client section.

Another nice feature is the version control of incoming connections.  One
can now configure the required version for the client or server that is
connecting to your server.  This way you can block some old version that
you don't want to support or something else.  Please, see the
doc/example_silcd.conf for example configuration of this feature.

Please refer to the ChangeLog on the website or the CHANGES file in the
package for complete list of changes.  I also assume there's going to be
bugfix releases shortly coming out.

	Pekka
________________________________________________________________________
 Pekka Riikonen                                 priikone at silcnet.org
 Secure Internet Live Conferencing (SILC)       http://silcnet.org/

silc client 0.8.3 RPM

[Johnny M. <jo...@th...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Greetings

Sorry for the delay I'm releasing the compiled client package with.
As some of you may have noticed, with the 0.8.x branch the client RPM bin=
ary=20
haven't been very portable, because of the hardcoded perl5 path.
Now it is modularized and included in the package, so if your perl5 path =
does=20
not match RedHat 7.2's one, you can still run the silc client without any=
=20
problem.
I have updated also the RPM Release Notes with some notes about the perl=20
support.

Please test the binary package and report any bad behaviour.

- --=20
Johnny
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8oeB3wX9QzTTiq0ARAhMEAJ9IRKgHr/2F3JcdjKIAfZkjQOS5JQCeKIMz
EPIpBa5uOAbwSZj3yqnyX48=3D
=3D3d6P
-----END PGP SIGNATURE-----