silc-devel — Main SILC development mailing list

SILC Client 0.9.1

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

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

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

A bugfix release as expected after major release version.  This fixes
several crahes, and especially the one that several people reported.  At
least, I can't get it crash like that anymore.  Anyhow, please test again
a lot and report those bugs here on the mailing list.

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: silc license change before v1.0 ?

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

--On Saturday, May 18, 2002 2:18 AM +0200 Anders Nor Berle 
<de...@de...> wrote:

> But which would you consider more (likely to be) secure, an
> implementation based on the reference implementation, or something
> written from scratch, with development time in mind?

> True. But we can add a clause to the license saying closed source
> implementations may not directly advertise using the silc toolkit if
> modified.

You can also use the Artistic License.  Which is much more *fun* if you ask 
me.

> The not holding up in court argument was for certain parts of LGPL
> (and not GPL as you later in this post state), I didn't even try to make
> it sound like anything else.

> Yes I did. GPL will limit adaption. Why would pekka and for that matter,
> the rest of the group bother to continue development if no one wants
> to use it? Remember, not everyone wants to develope their client under
> the terms of the GPL.

People that arnt willing to help develop on a project because of it's 
license, pardon my french need to get their head checked for holes.

I can think of better reasons to refuse helping a project, idiot head of 
project, dumb programmers, someone who removes your patch's because of the 
way you code.



> Not that "kind". :-)

There is a different license for every kind of mood, heck if pekka was so 
inclined he could start his own license if he so desired to.  Seen it 
before.

> Distribution was assumed, but sorry, I'll explicitly refer to that next
> time. :)

> Actually, we might both be right here, but I don't count the x11 split as
> the official wine project. All the contributors are still contributing to
> one of the wines, just not the official wine.

> But GCC isn't a reference implementation.

> Yes I am.. :-(
>
> But assume I said propetiary client for a second, wouldn't that make my
> argument more valid?


> Doesn't apply to other licenses, at least not for the same reason. LGPL
> assumes among other things that you can hold a copyright on devices. BSD
> and MIT certainly doesn't.

> But as you said, noninteresting discussion. See above for closing
> statements. :-)

Now i'm about to add a filter to sieve to further block this drivel.

Please, just voice  your opinion to pekka about what you want, and leave it 
be.  Stop beating the horse, it's dead, it's decomposed and it's rotting 
and making my mailbox stink.

Damm

Re: silc license change before v1.0 ?

[Anders N. B. <de...@de...>]

> Yes, but the GPL way, you ensure peer review and not allowing insecure
> implementations, that are based on reference implementation and then being closed.

But which would you consider more (likely to be) secure, an
implementation based on the reference implementation, or something
written from scratch, with development time in mind?

> By allowing proprietary code based on the silc toolkit, you can end up in a
> situation, where someone makes a bug, invisible to others and they feel secure by the
> reputation of silc toolkit.

True. But we can add a clause to the license saying closed source
implementations may not directly advertise using the silc toolkit if
modified.

> But your argument for license ,,holding up in court'' is absolutely irrelevant. You
> did not mention which court and why would somebody sue the author.

The not holding up in court argument was for certain parts of LGPL
(and not GPL as you later in this post state), I didn't even try to make
it sound like anything else.

> You didn't state the problem -- WHAT are you going to solve?

Yes I did. GPL will limit adaption. Why would pekka and for that matter,
the rest of the group bother to continue development if no one wants
to use it? Remember, not everyone wants to develope their client under
the terms of the GPL.

>> Just refering to what kind of people wrote the licenses. :)
>
> The same applies to all the other licenses in different countries. You can not be so
> anglo-americano-scandinavio-centric :-)).

Not that "kind". :-)

> again wrong. You don't have to return it. Only when you distribute something, you
> *must*. And if you distribute something, distribute it with the rights, that came.
> Simple.

Distribution was assumed, but sorry, I'll explicitly refer to that next
time. :)

> This is again wrong. The number of contributors of wine is the same. I don't know
> from where you get this information. But that's the issue for private talk, not for
> this list (/msg juraj).

Actually, we might both be right here, but I don't count the x11 split as
the official wine project. All the contributors are still contributing to
one of the wines, just not the official wine.

> The quality of the project does not depend on the license, but on the code. GCC is of
> high quality, even under commercial unixes, you often install gcc to compile your
> stuff. Absolutely irrelevant argument IMO.

But GCC isn't a reference implementation.

> you don't, use the silc toolkit. Commercial client does not mean it has to be
> proprietary. You are mixing the terms :).

Yes I am.. :-(

But assume I said propetiary client for a second, wouldn't that make my
argument more valid?

> I didn't see any problem you are trying to address, you just wrote, that you feel GPL
> is bad, BSD is better backing with arguments such as GPL won't hold up in court
> (which also applies to other licenses, as I said).
>
> You did not state your problem.

Doesn't apply to other licenses, at least not for the same reason. LGPL
assumes among other things that you can hold a copyright on devices. BSD
and MIT certainly doesn't.

But as you said, noninteresting discussion. See above for closing
statements. :-)

> In first one, you have the peer review.

See above for possible solution.

- Anders Nor Berle

Re: silc license change before v1.0 ?

[Juraj B. <ju...@be...>]

Hello,

> > If they use Pekka's and other's code, they can just contribute. Anyways, I feel
> > having a proper independent (even commercial) implementation of the protocol _NOT_
> > based on the Silc Toolkit.
> 
> We want to ensure quality though don't we? If people don't feel they've got the neccesary
> skills in security and programming to produce a quality piece of software, it'll only
> damage silc's reputation if they make an inferior, insecure program. And there's nothing
> stopping them from contributing their modifications.

Yes, but the GPL way, you ensure peer review and not allowing insecure
implementations, that are based on reference implementation and then
being closed.

There are always two views, nothing is black and white. 

By allowing proprietary code based on the silc toolkit, you can end up
in a situation, where someone makes a bug, invisible to others and they
feel secure by the reputation of silc toolkit. 

Especially -- GPL is nice in disallowing security by obscurity.

> > In our courts, neither MIT license or any other Free Software license won't hold up.
> 
> I think that's wrong. The copyright holder is allowed to grant/reserve permissions to do
> anything with his product, which is what these "simpler" licenses do.

So do I (think that's wrong). But for example our law does not allow you
to disclaim warannty, or to produce software without being rewarded.
Both do apply to MIT and BSD license, too. Is this a problem? No,
because noone is going to sue me, because I didn't get reward. And
nobody is going to sue me because they have no warranty, because that
would mean they're using the software illegaly. 

But your argument for license ,,holding up in court'' is absolutely
irrelevant. You did not mention which court and why would somebody sue
the author. 

You didn't state the problem -- WHAT are you going to solve?

> > Still, you make an assumption about ,,holding up''. For this to happen, there must be
> > someone to actually try it there :). The question is -- why?
> >
> 
> Just refering to what kind of people wrote the licenses. :)

The same applies to all the other licenses in different countries. You
can not be so anglo-americano-scandinavio-centric :-)).

...and in China, they would probably kill you after that ,,appereance in
court'', because you use cryptographic software.

> Yes, you should. *Should*. Not *must*, just *should*. With GPL, it's *must*. :)

again wrong. You don't have to return it. Only when you distribute
something, you *must*. And if you distribute something, distribute it
with the rights, that came. Simple.

> But we see how BSD and BSDish licensed projects (Apache, FreeBSD, etc) tends to be of high
> quality with a high number of contributions. The copylefting of wine (the *nix windows
> emulator) actually reduced the number of contributors to the project. So I don't see why
> it's bad.

This is again wrong. The number of contributors of wine is the same. I don't
know from where you get this information. But that's the issue for
private talk, not for this list (/msg juraj).

The quality of the project does not depend on the license, but on the
code. GCC is of high quality, even under commercial unixes, you often
install gcc to compile your stuff. Absolutely irrelevant argument IMO.

> And I will contribute any changes I make too, if I don't have to make my own
> implementation in order to make a commercial client.

you don't, use the silc toolkit. Commercial client does not mean it has
to be proprietary. You are mixing the terms :).

> Many world catastrophes could've been avoided if people realised the problems in time:)
> Seriously though. I can see obvious problems with the project being GPL, as mentioned in
> my previous post.

I didn't see any problem you are trying to address, you just wrote, that
you feel GPL is bad, BSD is better backing with arguments such as GPL
won't hold up in court (which also applies to other licenses, as I
said).

You did not state your problem.

> > Not allowing proprietary modifications of the libraries? What's the problem?
> > No ,,embrace and extend'' practices and if someone makes compliant
> > implementation, it is good for the project. If not, it will simply not be ,,silc''.
> It can be compliant and still have more holes than Titanic. For obvious reasons, it's sort
> of hard to state "must not have security holes" in the specs.

yes. You missed the point. Scenarios:

it's gpled

 - there's a hole -- someone finds it and fixes it
 - you gain the peer review

it's bsd-licensed

 - there's a hole in proprietary implementation
 - it's possibly not caused by the original code
     - people assume, that the silc is buggy, since it's the same code
       base
     - no peer review

In first one, you have the peer review. 







 J.

Re: silc license change before v1.0 ?

[Anders N. B. <de...@de...>]

Hi. :-)

> Hello,
>
>> Q: What's wrong with the GPL?
>> A: This is a legitimate question, but the answer is obvious. When the toolkit is
>> licensed under the GPL, it may not be used to create anything but GPL licensed
>> software. This will seriously prevent adaption from other projects. A dedicated silc
>> client *must* currently be licensed under the GPL. Do we want it to be impossible to
>> create commercial or closed-source silc clients, or for that matter, a less
>> restrictive client licensed under for instance the MIT license? Because that is our
>> current situation.
>
> The standards are free, they could very easily write a client, that conform to the
> standard.
>

Sounds like you've been sniffing IRC. :) This is a fairly more complex standard, it's not
an application you can just whip up in 2 minutes using perl. Or, we can let them use the
toolkit for all purposes.

> If they use Pekka's and other's code, they can just contribute. Anyways, I feel
> having a proper independent (even commercial) implementation of the protocol _NOT_
> based on the Silc Toolkit.

We want to ensure quality though don't we? If people don't feel they've got the neccesary
skills in security and programming to produce a quality piece of software, it'll only
damage silc's reputation if they make an inferior, insecure program. And there's nothing
stopping them from contributing their modifications.

>>
>> Q: Ok, can't we just use LGPL?
>> A: Most people asking this question hasn't actually read GPL or LGPL, and assume the
>> LGPL is just GPL without the clause about dependency. This is wrong. It's got it's
>> own additional quirks. Some of them won't even hold up in court in most civilized
>> countries. :-)
>
> In our courts, neither MIT license or any other Free Software license won't hold up.
>

I think that's wrong. The copyright holder is allowed to grant/reserve permissions to do
anything with his product, which is what these "simpler" licenses do.

> Still, you make an assumption about ,,holding up''. For this to happen, there must be
> someone to actually try it there :). The question is -- why?
>

Just refering to what kind of people wrote the licenses. :)

>> Q: But many many thousands of programmers are using the GPL/LGPL, shouldn't we? A:
>> There are reasons to use GPL/LGPL on some projects. These projects are usually
>> standalone applications intended to be replacements for commercial products, such as
>> gimp and gcc. We are making a reference implementation of the silc protocol, this
>> project in its current state is not intended for commercial distribution. If pekka
>> later wants to make a commercial program from this, there's nothing stopping him,
>> but that will not be a reference implementation. This is.
>
> So the reference implementation should stay free, away from ,,embrace and extend''
> practices of some onnamed proprietary vendors. If they want to implement proprietary
> implementation of the protocol, they are free to do so (and I hope even welcome to do
> so), but they can't use the code. If you get something, you should return something.
>

Yes, you should. *Should*. Not *must*, just *should*. With GPL, it's *must*. :)

>> Q: So what license should we use?
>> A: Personally, I think the BSD license is a good choice. It's not nazi restrctive
>> and it's simple enough for people to be able to read it, and more importantly,
>> understand it.
>
> While I personally use *BSD systems, I don't think this is good for the project in
> it's present state.
>

But we see how BSD and BSDish licensed projects (Apache, FreeBSD, etc) tends to be of high
quality with a high number of contributions. The copylefting of wine (the *nix windows
emulator) actually reduced the number of contributors to the project. So I don't see why
it's bad.

>> Q: Why are you constantly reffering to "we" when it's pekka's project. A: Isn't the
>> spirit of GPL to be a community about the project? ;) Seriously though, I see silc
>> as a community effort, even though pekka does most of the actual coding.
>
> Well, I think it's on pekka to decide, but I personally (I have my feelings about it
> too, since I like the SILC project -- I talk about it just like you do -- I hope this
> is a good place for such discussions, if not, please privately tell me not to comment
> :) feel, that current licensing is nice. I will probably, in a later time, even use
> the
> project commercialy (I have some plans too), but I _STILL_ want it to stay GNU GPL
> (and of course I will contribute any changes I make).

And I will contribute any changes I make too, if I don't have to make my own
implementation in order to make a commercial client.

> Anyways, you are trying to solve some ,,problem''. So please state what are the
> symptoms. Is there a project you want to base on silc libraries? I don't see the
> point here, you are trying to solve something, that not many of us perceive as a
> problem.

Many world catastrophes could've been avoided if people realised the problems in time:)
Seriously though. I can see obvious problems with the project being GPL, as mentioned in
my previous post.

> So where is the actual problem? GNU GPL not tested in court? Why should it
> matter, Pekka is doing the coding in Finland and there's no precendent-based law
> there.

But that assumes a violation would've been committed in Finland wouldn't it?

> Not allowing proprietary modifications of the libraries? What's the problem?
> No ,,embrace and extend'' practices and if someone makes compliant
> implementation, it is good for the project. If not, it will simply not be ,,silc''.
>

It can be compliant and still have more holes than Titanic. For obvious reasons, it's sort
of hard to state "must not have security holes" in the specs.

- Anders Nor Berle

Re: silc license change before v1.0 ?

[Juraj B. <ju...@be...>]

Hello,

> Q: What's wrong with the GPL?
> A: This is a legitimate question, but the answer is obvious. When the toolkit is licensed
> under the GPL, it may not be used to create anything but GPL licensed software. This will
> seriously prevent adaption from other projects. A dedicated silc client *must* currently
> be licensed under the GPL. Do we want it to be impossible to create commercial or
> closed-source silc clients, or for that matter, a less restrictive client licensed under
> for instance the MIT license? Because that is our current situation.

The standards are free, they could very easily write a client, that
conform to the standard. 

If they use Pekka's and other's code, they can just contribute. Anyways,
I feel having a proper independent (even commercial) implementation of
the protocol _NOT_ based on the Silc Toolkit.

This way -- all the people have to contribute their changes back, if
they make use and distribute the code. 

> 
> Q: Ok, can't we just use LGPL?
> A: Most people asking this question hasn't actually read GPL or LGPL, and assume the LGPL
> is just GPL without the clause about dependency. This is wrong. It's got it's own
> additional quirks. Some of them won't even hold up in court in most civilized countries.
> :-)

In our courts, neither MIT license or any other Free Software license
won't hold up.

Still, you make an assumption about ,,holding up''. For this to happen,
there must be someone to actually try it there :). The question is --
why?

> Q: So you're saying GPL/LGPL is bad? Isn't that just unconstructive?
> A: No, it's not bad, it's just that most people doesn't understand it, and blindly use it
> as many places as they can because they think it makes the world better.

I understand, have read and use it for most of my software (I use even
BSD license).

> Q: But many many thousands of programmers are using the GPL/LGPL, shouldn't we?
> A: There are reasons to use GPL/LGPL on some projects. These projects are usually
> standalone applications intended to be replacements for commercial products, such as gimp
> and gcc. We are making a reference implementation of the silc protocol, this project in
> its current state is not intended for commercial distribution. If pekka later wants to
> make a commercial program from this, there's nothing stopping him, but that will not be a
> reference implementation. This is.

So the reference implementation should stay free, away from ,,embrace
and extend'' practices of some onnamed proprietary vendors. If they want
to implement proprietary implementation of the protocol, they are free
to do so (and I hope even welcome to do so), but they can't use the
code. If you get something, you should return something. 

> Q: So what license should we use?
> A: Personally, I think the BSD license is a good choice. It's not nazi restrctive and it's
> simple enough for people to be able to read it, and more importantly, understand it.

While I personally use *BSD systems, I don't think this is good for the
project in it's present state.

> Q: Why are you constantly reffering to "we" when it's pekka's project.
> A: Isn't the spirit of GPL to be a community about the project? ;) Seriously though, I see
> silc as a community effort, even though pekka does most of the actual coding.

Well, I think it's on pekka to decide, but I personally (I have my
feelings about it too, since I like the SILC project -- I talk about it
just like you do -- I hope this is a good place for such discussions, if
not, please privately tell me not to comment :) feel, that current
licensing is nice. I will probably, in a later time, even use the
project commercialy (I have some plans too), but I _STILL_ want it to
stay GNU GPL (and of course I will contribute any changes I make). 

Anyways, you are trying to solve some ,,problem''. So please state what
are the symptoms. Is there a project you want to base on silc libraries?
I don't see the point here, you are trying to solve something, that not
many of us perceive as a problem. So where is the actual problem? GNU
GPL not tested in court? Why should it matter, Pekka is doing the coding
in Finland and there's no precendent-based law there. Not allowing
proprietary modifications of the libraries? What's the problem? No
,,embrace and extend'' practices and if someone makes compliant
implementation, it is good for the project. If not, it will simply not
be ,,silc''.




 Juraj.

silc license change before v1.0 ?

[Anders N. B. <de...@de...>]

The silc project has so far been developed under the GPL license. I suggest we start
looking at changing it before release of version 1.0. Why is explained in the answers to
the questions below.

This has previously been discussed more than once, so I'll begin this thread by answering
commonly asked questions, so we can avoid them.

Q: What's wrong with the GPL?
A: This is a legitimate question, but the answer is obvious. When the toolkit is licensed
under the GPL, it may not be used to create anything but GPL licensed software. This will
seriously prevent adaption from other projects. A dedicated silc client *must* currently
be licensed under the GPL. Do we want it to be impossible to create commercial or
closed-source silc clients, or for that matter, a less restrictive client licensed under
for instance the MIT license? Because that is our current situation.

Q: Ok, can't we just use LGPL?
A: Most people asking this question hasn't actually read GPL or LGPL, and assume the LGPL
is just GPL without the clause about dependency. This is wrong. It's got it's own
additional quirks. Some of them won't even hold up in court in most civilized countries.
:-)
Q: So you're saying GPL/LGPL is bad? Isn't that just unconstructive?
A: No, it's not bad, it's just that most people doesn't understand it, and blindly use it
as many places as they can because they think it makes the world better.

Q: But many many thousands of programmers are using the GPL/LGPL, shouldn't we?
A: There are reasons to use GPL/LGPL on some projects. These projects are usually
standalone applications intended to be replacements for commercial products, such as gimp
and gcc. We are making a reference implementation of the silc protocol, this project in
its current state is not intended for commercial distribution. If pekka later wants to
make a commercial program from this, there's nothing stopping him, but that will not be a
reference implementation. This is.

Q: So what license should we use?
A: Personally, I think the BSD license is a good choice. It's not nazi restrctive and it's
simple enough for people to be able to read it, and more importantly, understand it.

Q: Why not X license instead?
A: There are many other licenses which are suitable for the project.. as suggested in a
previous thread, the MIT license will not get any objections from me, but I think we
should use a license as common as possible, without putting a bundle of restrictions on
people.

Q: So should we change the license for all 3 modules?
A: No, the client should probably remain GPL, due to us using the irssi source and it not
really being our project.

Q: Why are you constantly reffering to "we" when it's pekka's project.
A: Isn't the spirit of GPL to be a community about the project? ;) Seriously though, I see
silc as a community effort, even though pekka does most of the actual coding.

Below is the BSD license. Other possible licenses are available at
http://www.opensource.org/licenses/ for your review.

- Anders Nor Berle

---- BEGIN BSD LICENSE ----
 Copyright (c) [year] [your name]
 All rights reserved.

 Redistribution and use in source and binary forms, with or without
 modification, are permitted provided that the following conditions
 are met:
 1. Redistributions of source code must retain the above copyright
    notice, this list of conditions and the following disclaimer.
 2. Redistributions in binary form must reproduce the above copyright
    notice, this list of conditions and the following disclaimer in the
    documentation and/or other materials provided with the distribution.

 THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
 ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
 FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 SUCH DAMAGE.
---- END BSD LICENSE ----

My backtrace on .9...

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

+ Irssi: silc: Total of 4 nicks [1 ops, 0 halfops, 0 voices, 3 normal]
+ Not enough parameters
[01:27][Damm][1:#unix(+f)]

That's the last i saw.

Got this pretty little backtrace

#0  silc_client_command_get_clients_list_callback (context=0x3640b0, 
context2=0x189000)
    at idlist.c:309
309         SILC_GET16_MSB(idp_len, client_id_list->data + 2);
(gdb) bt
#0  silc_client_command_get_clients_list_callback (context=0x3640b0, 
context2=0x189000)
    at idlist.c:309
#1  0x15a290 in silc_client_command_reply_identify_i (context=0x3622f0, 
context2=0x0)
    at command_reply.c:1882
#2  0x155e88 in silc_client_command_reply_process (client=0x1fb170, 
sock=0x362170,
    packet=0x310f28) at command_reply.c:124
#3  0x14348c in silc_client_packet_parse_type (client=0x1fb170, 
sock=0x362170, packet=0x310f28)
    at client.c:1030
#4  0x14338c in silc_client_packet_parse (parser_context=0x363100, 
context=0x1fb170)
    at client.c:942
#5  0x167458 in silc_packet_receive_process (sock=0x362170, 
local_is_router=0 '\000',
    cipher=0x362020, hmac=0x254c20, sequence=26, parser=0x143224 
<silc_client_packet_parse>,
    parser_context=0x1fb170) at silcpacket.c:405
#6  0x1431f8 in silc_client_packet_process (schedule=0x1fb680, 
type=SILC_TASK_READ, fd=10,
    context=0x1fb170) at client.c:877
#7  0x18987c in silc_schedule_dispatch_nontimeout (schedule=0x1fb680) at 
silcschedule.c:392
#8  0x189d50 in silc_schedule_one (schedule=0x1fb680, timeout_usecs=0) at 
silcschedule.c:623
#9  0x14472c in silc_client_run_one (client=0x1fb170) at client.c:172
#10 0x6b968 in my_silc_scheduler () at silc-core.c:59
#11 0xff1f7cbc in ?? ()
#12 0xff1f67a4 in ?? ()
#13 0xff1f6c38 in ?? ()
#14 0x4c528 in main (argc=3, argv=0xffbef754) at silc.c:350


It's quite pretty and i'm sure Pekka's aware of it... 

core backtrace.

[Juraj Z. <e...@hq...>]

(gdb) bt
#0  0x080c4bb7 in silc_client_command_get_clients_list_callback (
    context=3D0x817b550, context2=3D0x8175a20) at idlist.c:309
#1  0x080c3e5d in silc_client_command_reply_identify_i (context=3D0x8175a20,
    context2=3D0x0) at command_reply.c:1882
#2  0x080bfe8f in silc_client_command_reply_process (client=3D0x8137128,
    sock=3D0x8172d90, packet=3D0x817a008) at command_reply.c:124
#3  0x080b0491 in silc_client_packet_parse_type (client=3D0x8137128,
    sock=3D0x8172d90, packet=3D0x817a008) at client.c:1030
#4  0x080b037e in silc_client_packet_parse (parser_context=3D0x8179420,
    context=3D0x8137128) at client.c:942
#5  0x080ceda3 in silc_packet_receive_process (sock=3D0x8172d90,
    local_is_router=3D0 '\0', cipher=3D0x81753a0, hmac=3D0x816f030, sequenc=
e=3D43,
    parser=3D0x80b0264 <silc_client_packet_parse>, parser_context=3D0x81371=
28)
    at silcpacket.c:405
#6  0x080b0242 in silc_client_packet_process (schedule=3D0x8138e68,
    type=3DSILC_TASK_READ, fd=3D7, context=3D0x8137128) at client.c:877
#7  0x080eb73d in silc_schedule_dispatch_nontimeout (schedule=3D0x8138e68)
    at silcschedule.c:392
#8  0x080ebbca in silc_schedule_one (schedule=3D0x8138e68, timeout_usecs=3D=
0)
    at silcschedule.c:623
#9  0x080b141a in silc_client_run_one (client=3D0x8137128) at client.c:172
#10 0x0808c710 in my_silc_scheduler () at silc-core.c:59
#11 0x4002f3fa in g_main_set_poll_func () from /usr/lib/libglib-1.2.so.0
#12 0x4002e4d8 in g_get_current_time () from /usr/lib/libglib-1.2.so.0
#13 0x4002eae3 in g_get_current_time () from /usr/lib/libglib-1.2.so.0
#14 0x4002eb95 in g_main_iteration () from /usr/lib/libglib-1.2.so.0
#15 0x08071b30 in main (argc=3D1, argv=3D0xbffff934) at silc.c:350

i have not tried to recreate this crash, as i have no idea what caused
it.

[e]

--=20
___________________________________________________________________________=
____
>e...@hq...<                   /(bb|[^b]{2})/                 >http://hq.sk/~e=
uro<

SILC Server 0.9

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

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

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

And finally we have the new server version out as well.  This version now
implements the new SILC protocol version 1.1.  I will immediately upgrade
the silc.silcnet.org router and server to this version, and I will not
accept incoming connections to those servers from old 1.0 protocol
versions.  I know this causes inconvenience for you but since the older
version is not fully compatible I don't want to answer questions why it
doesn't work and so on.  Anyway, so upgrade the new client and you will
be able to connect again. :)  But then, let's go to this release...

There isn't much changes in the configuration file so upgrading from the
0.8.x version to 0.9 should be really simple.  However, there's some new
stuff there since this version has some new features.

o Detaching.  The detaching is the brand new feature in SILC which allows
  clients to detach from the server but still remain as valid user in the
  network.  After detaching they can then resume the session back from any
  server in the network.  But, you can control this as server
  administrator.  If you don't want to have the detach support in your
  server you can set "detach_disabled" config option to true and
  nobody can give the DETACH command in your server.  This don't prohibit
  for someone resuming a detached session into your server but at least
  no local user can detach.  By default the DETACH is enabled.

  Other option is to limit the time for how long a session can be
  detached.  If you don't do any changes to config file by default the
  detached sessions are persistent.  This means that they remain in your
  server as long as your server is up and running.  If you don't want this
  you can set a time limit.  This can be done with "detach_timeout" and
  to set the minutes value for how long they remain.  For example you
  could set it to 1440 (24 hours) so that if someone doesn't resume their
  session in 24 hours the server will automatically close the session.

o I could make a huge list of changes related to 1.1 protocol version but
  I just bundle them together and say that major changes regarding 1.1
  version were made.  So, caveat user!  There may be some problems with
  this version because this is major release.

I will be taking a little vacation from SILC after these releases,
probably couple of weeks.  To just recharge my batteries and so on.

Please test a lot, and report those bugs here on the mailing list.  And,
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/

SILC Client 0.9

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

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

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

And here we go with the new Irssi SILC client version 0.9, implementing
all the nice things found in the SILC protocol version 1.1.  Before going
into details a warning is due here.  This version is not fully compatible
with older servers so if you end up connecting to older server with this
new client you may experience minor problems.  Another warning is that
this is a major new release so it is quite possible there's some problems.

Also I'd like to announce that I won't be residing anymore on "#silc"
channel after this release.  I will pack my bags and move to "silc"
channel.  You are all welcome there. :)  I have updated every reference on
the silcnet.org webpage to point "silc" and not "#silc". :)

But then, let's talk a bit about new features in this version:

o New DETACH command.  This command can be used to detach from the server
  but still remain in the network.  When you give the /DETACH command
  (it takes no arguments) your connection to the server will be closed
  and a "detachment" data will be saved into ~/.silc/session file.
  Next time you connect to any server in the network the Irssi SILC client
  will read that file and use the data inside to resume your detached
  session back.  If you were joined on channels when you detached, you
  will also automatically "join" those channels when you resume.  It will
  only seem like you joined them, for real you were joined those all the
  time.  This is to just bring the user interface up to date after
  resuming.

  A note here I have to make.  If you have joined many channels then
  the resuming may take some time, something like 2 - 5 seconds maybe,
  depending on how many channels you were joined.  Reason for this is that
  when you resume your detached session to the server, the client will
  resolve information about channels, channel users, modes, topics etc
  from the server by sending commands, and server will think that you are
  flooding it with commands so it starts limiting for how many commands
  you may execute.  This is the reason it may take a few seconds, because
  server is limiting your command flooding.  If you have joined only one
  or two channels there should not be any delay during resuming.

  If there is an error during resuming the server will close connection
  and you will have to reconnect, and the session will not be resumed.
  Messages that has been sent to you while you were detached are always
  dropped by the server, so you never get them.

  So to test this you can do something like this:

    /server silc.silcnet.org
    /join silc
    send "blabla" to channel
    /detach
    *** connection lost to silc.silcnet.org
    /server silc.silcnet.org
    *** connection resumed to silc.silcnet.org
    send "blabla" to channel

  Also note that server may limit your detaching.  It is possible for
  the server to disallow the DETACH command.  You won't be able to detach
  your session in the server which has denied this.  Also, server may set
  a time limit for preserving detached sessions.  For example, server may
  have a 24 hour limit which means that if you don't resume your session
  back after 24 hours the server will disconnect your session and you
  won't be able to resume it back.

o New presence settings with UMODE command.  People have used to give
  the /AWAY when leaving the network.  Now there are other presence
  indicators in SILC as well, and you can set them with UMODE command
  (maybe later there's aliases like /AWAY is too):

    /umode +g		set to be "gone" (same as /AWAY)
    /umode +i		set to be "indisposed"
    /umode +b		set to be "busy"
    /umode +p		set to be "awaiting paging"
    /umode +h		set to be "hyper active"

  The "indisposed", "busy", "page me dummy" and "I'm hyper active" are
  the new presence indicators.  See /help UMODE for more information.
  If someone is for example "busy" you can see it with /WHOIS command.

o There's also a "robot" user mode that is suggested to be used if you
  are actually a robot program.  I'm sure bots will start appearing soon
  in SILC and I for sure will allow them only if they have the robot user
  mode set.  It can be set with the UMODE command.  See /help UMODE.
  This mode is important because some users can block messages from robots
  by setting +r mode with CUMODE command.

o Yeah, message blocking.  You can block unwanted private messages by
  setting yet another user mode with UMODE command, this time it's
  /umode +P.  If you set this no one can send you private messages unless
  they first negotiate private message key with you (for example with /KEY
  command).  This is nice feature if you don't want to talk with private
  messages unless they are strictly secured with private message key.

  Then blocking messages on channel.  The +r mode to CUMODE was to
  block channel messages sent by robots like I said.  If you want to live
  on the edge you can set +b mode; it will block *all* channel messages,
  just give: /cumode channel +b yournick.  If you don't want to be that
  extreme there's also +u mode which can be used to block messages sent
  by normal users.  You will receive only messages sent by operators and
  founder.

o Channel moderating.  "Would you like to shut up those that don't have
  ops?".  Well, just set +m mode with CMODE command and normal users
  won't be able to talk on the channel.  "Would you like to shut up those
  that DO have ops?" :)  Well, just set +M mode and those that have ops
  won't be able to talk.  Set both +m and +M if you want that only the
  founder on the channel can talk.

o "Tired of receiving invites to channels?".  You probably answer No, but
  if you would happen to answer Yes, you *can* block invites as well.
  Just set yet another user mode with UMODE, this time it's +I, and
  you won't get invites.  Note that this may make joining to invite only
  channels a bit harder.

o You want to have permanent channels, don't you?  Set the +f mode with
  CMODE command you have your very own channel, and you will be able
  to reclaim the founder rights back on any server in the network.
  The -pubkey option from CMODE, CUMODE and JOIN commands is history now.
  So to set the +f, give: /cmode channel +f, and that's it.  To reclaim
  founder rights during joining give: /join channel -founder, and that's
  it.  To reclaim founder rights after joining give: /cumode channel +f
  yournick.  So the difference is that you don't have to give the -pubkey
  option any more.  On the other hand, you cannot give passphrase anymore
  to +f mode, the public key is used automatically.

o New WATCH command.  It can be used to watch some nicknames.  To add a
  nickname to be watched give: /watch -add foonick.  When the "foonick"
  comes to the network, leaves the network, changes user mode (like /AWAY,
  or detaches from the network), or changes nickname you will be notified.
  To remove nickname from watch list give /watch -del foonick.

  If *you* don't want that someone can watch you, you can set yet another
  user mode with UMODE.  Give, /umode +w and nobody can watch you.
  See also /help WATCH.

o Latest bugfixes taken from the Irssi.org CVS for the Irssi SILC client.

That's about it.  Please test a lot since this version suffers from lack
of testing since I haven't had time to test.  Report bugs here on the
silc-devel mailing list.

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/

draft-riikonen-presence-attrs-00.txt

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

A new Internet Draft defining User Online Presence and Information
Attributes is available, and has been submitted to the IETF.

This draft is not officially part of SILC protocol specification, however
it is used by the SILC.  I am submitting it at the same time submitting
the new SILC drafts.  The development of this draft is independent from
the SILC development.

o User Online Presence and Information Attributes

  http://silcnet.org/docs/draft-riikonen-presence-attrs-00.txt

  Abstract

   This document defines set of attributes that can represent the online
   user's presence in a network, and to provide general information about
   the user.  The purpose is to provide a generic mechanism to share
   online presence and status, and general information about the user
   to be used in several kind of network protocols and applications.
   These attributes could be used by for example chat and conferencing
   protocols (such as Instant Message protocols), network games, and
   other similar network protocols and applications that has online
   users in a network.

This draft is initial submission.

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

draft-riikonen-silc-flags-payloads-00.txt

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

A new Internet Draft defining the SILC Message Flag Payloads is available,
and has been submitted to the IETF.

o SILC Message Flag Payloads

  http://silcnet.org/docs/draft-riikonen-silc-flags-payloads-00.txt

  Abstract

   This memo describes the data payloads associated with the SILC Message
   Flags, as defined in the SILC Packet Protocol Internet Draft [SILC2].
   The purpose of the Message Flags is to augment the function of the
   Private Message Payload and Channel Message Payload by allowing the
   sender to tell the receiver what type of data the payload includes, and
   how the data should be processed.  Some of the Message Flags may define
   additional payloads to be associated with the flag, and this memo
   describes these payloads.

This draft is initial submission.

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

draft-riikonen-silc-commands-03.txt

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

A new Internet Draft defining the SILC Commands is available, and has been
submitted to the IETF.

o SILC Commands

  http://silcnet.org/docs/draft-riikonen-silc-commands-03.txt

  Abstract

   This memo describes the commands used in the Secure Internet Live
   Conferencing (SILC) protocol, specified in the Secure Internet Live
   Conferencing, Protocol Specification Internet Draft [SILC1].  The
   SILC Commands are very important part of the SILC protocol.  Usually
   the commands are used by SILC clients to manage the SILC session, but
   also SILC servers may use the commands.  This memo specifies detailed
   command messages and command reply messages.

Changes to previous draft:

o Defined new <requested attributes> argument to SILC_COMMAND_WHOIS
  command, and defined the use of the attributes in new Appendix A.

o Defined that the <count> parameters in commands are 32 bit MSB
  first order integer.

o Defined that the SILC_COMMAND_WHOIS command reply returns also
  <channel user mode list> and <attributes> arguments.

o Fixed the Max Arguments in SILC_COMMAND_WHOIS and SILC_COMMAND_IDENTIFy
  to 256 Max Arguments.

o Defined the SILC_COMMAND_NICK command reply to return the new
  nickname as well.

o Removed commands SILC_COMMAND_CONNECT, SILC_COMMAND_SHUTDOWN and
  SILC_COMMAND_CLOSE commands from the specification.

o Defined new commands SILC_COMMAND_STATS, SILC_COMMAND_DETACH,
  SILC_COMMAND_WATCH and SILC_COMMAND_SERVICE.

o Defined new <founder auth> argument to SILC_COMMAND_JOIN command
  which is used to resume founder privileges on the channel during
  joining.

o Defined that if SILC_COMMAND_UMODE is given without mode argument
  it returns the current mode mask.

o Defined new SILC_UMODE_INDISPOSED, SILC_UMODE_BUSY, SILC_UMODE_PAGE,
  SILC_UMODE_HYPER, SILC_UMODE_ROBOT, SILC_UMODE_ANONYMOUS,
  SILC_UMODE_BLOCK_PRIVMSG, SILC_UMODE_DETACHED,
  SILC_UMODE_REJECT_WATCHING and SILC_UMODE_BLOCK_INVITE user modes.

o Defined that if SILC_COMMAND_CMODE is given without the mode
  argument it returns the current mode mask.

o Defined new SILC_CMODE_SILENCE_USERS and SILC_CMODE_SILENCE_OPERS
  channel modes.  Defined the channel to be permanent channel when
  the SILC_CMODE_FOUNDER_AUTH mode is set.  Also defined that only
  the public key authentication can be used with SILC_CMODE_FOUNDER_AUTH
  mode.  Further defined, that the SILC_CMODE_FOUNDER_AUTH Authentication
  Payload hash function MUST be sha1.

o Defined new SILC_CUMODE_BLOCK_MESSAGE,
  SILC_CUMODE_BLOCK_MESSAGES_USERS, SILC_CUMODE_BLOCK_MESSAGES_ROBOTS
  and SILC_CUMODE_QUIET channel user modes.

o Defined that SILC_COMMAND_LEAVE command reply returns the Channel ID
  of the left channel.

o Redefined the Command Status Payload to include possibility to send
  list of errors as well.

o Defined that status types can be also used with certain notify types,
  and not only with command reply.

o Defined new SILC_STATUS_ERR_INCOMPLETE_INFORMATION,
  SILC_STATUS_ERR_RESOURCE_LIMIT, SILC_STATUS_ERR_NO_SUCH_SERVICE,
  SILC_STATUS_ERR_NOT_AUTHENTICATED, SILC_STATUS_ERR_BAD_SERVER_ID,
  SILC_STATUS_ERR_KEY_EXCHANGE_FAILED and SILC_STATUS_BAD_VERSION
  status types.

o Removed SILC_STATUS_ERR_TOO_MANY_TARGETS status type.

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

draft-riikonen-silc-ke-auth-05.txt

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

A new Internet Draft defining the SILC Key Exchange and Authentication
Protocols is available, and has been submitted to the IETF.

o SILC Key Exchange and Authentication Protocols

  http://silcnet.org/docs/draft-riikonen-silc-ke-auth-05.txt

  Abstract

   This memo describes two protocols used in the Secure Internet Live
   Conferencing (SILC) protocol, specified in the Secure Internet Live
   Conferencing, Protocol Specification internet-draft [SILC1].  The
   SILC Key Exchange (SKE) protocol provides secure key exchange between
   two parties resulting into shared secret key material.  The protocol
   is based on Diffie-Hellman key exchange algorithm and its functionality
   is derived from several key exchange protocols.  SKE uses best parts
   of the SSH2 Key Exchange protocol, Station-To-Station (STS) protocol
   and the OAKLEY Key Determination protocol [OAKLEY].

   The SILC Connection Authentication protocol provides user level
   authentication used when creating connections in SILC network.  The
   protocol is transparent to the authentication data which means that it
   can be used to authenticate the user with, for example, passphrase
   (pre-shared-secret) or public key (and certificate).

Changes to previous draft:

o Defined that the security property strings in the Key Exchange
  Start Payload SHOULD be UTF-8 encoded.

o Defined that the passphrase sent in Connection Authentication protocol
  MUST be UTF-8 encoded.

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

draft-riikonen-silc-pp-05.txt

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

A new Internet Draft defining the SILC Packet Protocol is available,
and has been submitted to the IETF.

o SILC Packet Protocol

  http://silcnet.org/docs/draft-riikonen-silc-pp-05.txt

  Abstract

   This memo describes a Packet Protocol used in the Secure Internet Live
   Conferencing (SILC) protocol, specified in the Secure Internet Live
   Conferencing, Protocol Specification Internet Draft [SILC1].  This
   protocol describes the packet types and packet payloads which defines
   the contents of the packets.  The protocol provides secure binary packet
   protocol that assures that the contents of the packets are secured and
   authenticated.

Changes to previous draft:

o Defined "Compressed" flag to the packet header, to indicate that
  the payload is compressed.

o Defined new SILC_PACKET_RESUME_CLIENT packet type and payload
  for it.

o Redefined the Disconnect Payload to deliver the reason of the
  disconnection as SILC status type.  Defined that human readable
  error message MAY be set as well, and is UTF-8 encoded.

o Defined that all passphrases MUST be UTF-8 encoded.

o Redefined the SILC_NOTIF_TYPE_TOPIC_SET notify type to have
  generic ID Payload as first argument, instead of using Client ID
  as first argument.

o Defined new argument <nickname> to SILC_NOTIFY_TYPE_NICK_CHANGE,
  which is the new changed nickname.

o Defined new argument <founder public key> to the
  SILC_NOTIFY_TYPE_CMODE_CHANGE and SILC_NOTIFY_TYPE_CUMODE_CHANGE
  which is used to deliver the channel founder's public key.  Defined
  that the public key received in the notify MUST be saved by routers
  and servers.

o Defined new argument <Killer's ID> to the SILC_NOTIFY_TYPE_KILLED,
  which is the killer's ID.

o Defined new SILC_NOTIFY_TYPE_ERROR and SILC_NOTIFY_TYPE_WATCH
  notify types.

o Defined that for SILC_NOTIFY_TYPE_SIGNOFF,
  SILC_NOTIFY_TYPE_SERVER_SIGNOFF, SILC_NOTIFY_TYPE_KILLED,
  SILC_NOTIFY_TYPE_NICK_CHANGE and SILC_NOTIFY_TYPE_UMODE_CHANGE
  notify types the watcher list MUST be checked.

o Defined new SILC_MESSAGE_FLAG_REPLY and SILC_MESSAGE_FLAG_DATA
  message flags for Channel Message Payload and Private Message Payload.

o Redefined the MAC generation for the Channel Message Payload.

o Fixed errorin packet routing with primary routers from being
  clock-wise to being counter clock-wise.

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

draft-riikonen-silc-spec-05.txt

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

A new Internet Draft defining the Secure Internet Live Conferencing (SILC)
Protocol is available, and has been submitted to the IETF.

o Secure Internet Live Conferencing (SILC), Protocol Specification

  http://silcnet.org/docs/draft-riikonen-silc-spec-05.txt

  Abstract

   This memo describes a Secure Internet Live Conferencing (SILC)
   protocol which provides secure conferencing services over insecure
   network channel.  SILC is IRC [IRC] like protocol, however, it is
   not equivalent to IRC and does not support IRC.  Strong cryptographic
   methods are used to protect SILC packets inside the SILC network.
   Three other Internet Drafts relates very closely to this memo;
   SILC Packet Protocol [SILC2], SILC Key Exchange and Authentication
   Protocols [SILC3] and SILC Commands [SILC4].

Changes to previous draft:

o Changed nickname and channel name length statement from
  "characters" to "bytes".

o Defined that the nickname in SILC is lowercase always, and the
  Client ID hash MUST be computed from lowercase nickname.

o Defined that there MAY be commands that server can send to client.

o Defined that all passphrases sent in SILC protocol MUST be UTF-8
  encoded.

o Defined that if Authentication Data Length in Authentication
  Payload is zero (0), the payload MUST be discarded, and authentication
  fails.

o Defined that the hash() and sign() functions used in Authentication
  Payload may be seprately defined in the context where the payload
  is used, instead of just using functions selected in SKE.

o Added the references for computing signatures with different
  kind of keys.

o Defined that all strings in SILC Public key are UTF-8 encoded.

o Defined that the version string MUST be US-ASCII encoded.

o Incremented the SILC Protocol version from 1.0 to 1.1, and the
  required protocol version string is SILC-1.1 now.

o Defined the when new client comes to network its nickname MUST
  be checked from the watcher list.

o Defined that when client leaves the network its nickname MUST
  be checked from the watcher list.

o Defined that if channel message is sent to unknown Channel ID
  the SILC_NOTIFY_TYPE_ERROR must be sent to the sender of the
  message.

o Defined that if private message is sent to unknown Client ID
  the SILC_NOTIFY_TYPE_ERROR must be sent to the sender of the
  message.

o Added session detaching and resuming definition.

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

SILC Toolkit 0.9

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

The SILC Toolkit version 0.9 is now available!  The software is
available from the following sources:

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

SILC Toolkit 0.9 implementing the new SILC protocol version 1.1 is now
out.  The Toolkit is released before any other package so that the Toolkit
programmers can get their programs up to date supporting protocol version
1.1 as soon as possible.  If you are not SILC Toolkit programmer then it
is not necessary for you to read this email any further.

For Toolkit programmers this email can be used as reference to modify
your application to support this Toolkit version and new protocol
version.  I will list here changes in the Toolkit in code level, and list
all required changes for Client Library users.

o New commands:  "DETACH" and "WATCH".  The SILC_COMMAND_DETACH is a
  command which can be used to detach from the server without actually
  signing off from the network.  When called, the library will call
  a new 'detach' client operation to the application to deliver a
  detachment data.  More of this later in this email.

  The SILC_COMMAND_WATCH is a command which can be used to add or delete
  a nickname in a watch list.  When nickname is added to watch list
  the server will notify the client when the nickname comes or leaves
  the network, changes user mode (like AWAY) or changes nickname.
  The notify will call the 'notify' client operation with a new
  notify type SILC_NOTIFY_TYPE_WATCH.

  The server does not provide a mechanism to fetch the current
  watch list, so it is application's responsible of keeping a list
  if you want to provide such feature for a user in user interface.

  Ref:
  http://silcnet.org/docs/toolkit/silccommand.html
  http://silcnet.org/docs/toolkit/silccommand-SilcCommand.html


o 'connect' client operation API change:  The 'connect' client operation
  that is called after the connection to the server has been created,
  now has SilcClientConnectionStatus argument, which replaces the old
  boolean success/failure indicator.  SILC_CLIENT_CONN_SUCCESS indicates
  that connection was created successfully,
  SILC_CLIENT_CONN_SUCCESS_RESUME indicates that connection was created
  successfully, and old session was resumed in the server.  Any other
  status value is currently an error.

  Ref:
  http://silcnet.org/docs/toolkit/silcclient.html
  http://silcnet.org/docs/toolkit/silcclient-SilcClientOperations.html
  http://silcnet.org/docs/toolkit/silcclient-SilcClientConnectionStatus.html


o A new 'detach' client operation:  This new client operation is called
  after the new DETACH command is called.  Library delivers a data block
  to application which the application must save in order to able to
  resume the detached session at a later time.  Application may save
  it for example into a file.  If application does not save it, it
  is impossible to resume the session in the server later.

  To resume a detached session, the application must provide the
  detachment data to the library when creating a new connection to a
  server.  There is a new structure SilcClientConnectionParams which
  includes generic connection creation parameters, including the
  detachment data.  This structure can be given as argument to either
  silc_client_connect_to_server, or silc_client_add_connection, which
  ever your application use currently.  When the detachment data is
  saved in the stucture the library will use the data to resume the
  session in the network.  If this is successful the new connection
  status SILC_CLIENT_CONN_SUCCESS_RESUME is returned in 'connect'
  client operation.  After the detachment data is used, it cannot
  be re-used later, so application should delete after using it
  (regardless whether the resuming was successful or not).

  When resuming a session to server the library will call various
  client operations, such as 'command_reply' client operation for
  JOIN, UMODE, CMODE, USERS, TOPIC etc.  The reason for this is
  that the library sets itself into the same state it was when the
  session was detached.  So if the client was on 3 channels, all
  those channels are created again, and the library calls command
  reply for JOIN command.  The application should do exactly the
  same thing as it would do normally when receiving these client
  operations.  This is to make the resuming as simple as possible
  for application.  Also note that these client operations are
  called *before* the 'connect' client operation so make sure you
  handle this in your application.

  This is a great new feature which makes a difference for users
  and I hope that applications start supporting this.

  Ref:
  http://silcnet.org/docs/toolkit/silcclient.html
  http://silcnet.org/docs/toolkit/silcclient-SilcClientOperations.html
  http://silcnet.org/docs/toolkit/silcclient-silc_client_connect_to_server.html
  http://silcnet.org/docs/toolkit/silcclient-silc_client_add_connection.html
  http://silcnet.org/docs/toolkit/silcclient-SilcClientConnectionStatus.html


o New user modes:  If you application handles user modes like
  SILC_UMODE_GONE, SILC_UMODE_SERVER_OPERATOR and
  SILC_UMODE_ROUTER_OPERATOR you need to know that there is a bunch of
  new ones now: SILC_UMODE_INDISPOSED, SILC_UMODE_BUSY,
  SILC_UMODE_PAGE, SILC_UMODE_HYPER, SILC_UMODE_ROBOT,
  SILC_UMODE_ANONYMOUS, SILC_UMODE_BLOCK_PRIVMSG,
  SILC_UMODE_REJECT_WATCHING and SILC_UMODE_BLOCK_INVITE modes
  are defined in lib/silccore/silcmode.h.

  Ref:
  http://silcnet.org/docs/toolkit/silcmode.html
  http://silcnet.org/docs/toolkit/silcmode-SilcUserMode.html


o Two new channel modes: SILC_CHANNEL_MODE_SILENCE_USERS
  and SILC_CHANNEL_MODE_SILENCE_OPERS which are defined in
  lib/silccore/silcmode.h.  These modes can be handled through
  the CMODE command.

  Ref:
  http://silcnet.org/docs/toolkit/silcmode.html
  http://silcnet.org/docs/toolkit/silcmode-ChannelModes.html


o Four new channel user modes: SILC_CHANNEL_UMODE_BLOCK_MESSAGES,
  SILC_CHANNEL_UMODE_BLOCK_MESSAGES_USERS,
  SILC_CHANNEL_UMODE_BLOCK_MESSAGES_ROBOTS and
  SILC_CHANNEL_UMODE_QUIET which are defined also in
  lib/silccore/silcmode.h.  These modes can be handled through
  the CUMODE command.

  Ref:
  http://silcnet.org/docs/toolkit/silcmode.html
  http://silcnet.org/docs/toolkit/silcmode-ChannelUserModes.html


o The silc_client_command_status_message function is removed and a new
  generic silc_get_status_message function was added.  The old
  status types SilcCommandStatus is now renamed to SilcStatus
  and the silc_get_status_message can be used to map the SilcStatus
  into human readable message if your application wants to do it.

  Also note that all client operations that had the old
  SilcCommandStatus argument now use the SilcStatus argument, so
  update your code on this.

  Ref:
  http://silcnet.org/docs/toolkit/silcstatus.html
  http://silcnet.org/docs/toolkit/silcstatus-SilcStatus.html
  http://silcnet.org/docs/toolkit/silcutil.html
  http://silcnet.org/docs/toolkit/silcutil-silc_get_status_message.html


o New notify types:  SILC_NOTIFY_TYPE_ERROR and SILC_NOTIFY_TYPE_WATCH.
  The ERROR is a generic error notification which the server may
  send to client when an error has occurred.  The error is SilcStatus
  so your application can use silc_get_status_message to map the
  error message if wanted.  The WATCH notify type is called when
  a nickname which was added using "WATCH" command has had a
  change.  The WATCH notify returns SilcClientEntry, char *nickname,
  SilcUInt32 mode and SilcNotifyType in 'notify' client operation.
  The SilcNotifyType indicates which action happened for the
  watched nickname.  The nickname returned may be NULL.  Notify
  types that may be returned in this WATCH notify are:
  SILC_NOTIFY_TYPE_NICK_CHANGE, SILC_NOTIFY_TYPE_UMODE_CHANGE,
  SILC_NOTIFY_TYPE_KILLED, SILC_NOTIFY_TYPE_SIGNOFF or
  SILC_NOTIFY_TYPE_SERVER_SIGNOFF.

  Ref:
  http://silcnet.org/docs/toolkit/silcnotify.html
  http://silcnet.org/docs/toolkit/silcnotify-SilcNotifyType.html
  http://silcnet.org/docs/toolkit/silcclient-SilcClientOperations.html


o silc_client_close_connection does not have SilcSocketConnection
  argument anymore.

  Ref:
  http://silcnet.org/docs/toolkit/silcclient.html
  http://silcnet.org/docs/toolkit/silcclient-silc_client_close_connection.html


o The SILC_NOTIFY_TYPE_KILLED notify type now returns the killer's
  SilcClientEntry as last argument in 'notify' client operation.

  Ref:
  http://silcnet.org/docs/toolkit/silcnotify.html
  http://silcnet.org/docs/toolkit/silcnotify-SilcNotifyType.html
  http://silcnet.org/docs/toolkit/silcclient-SilcClientOperations.html


o API changes in 'channel_message' and 'private_message' client
  operations:  The message which used to be the 'msg' argument is
  now const unsigned char *message, and new argument
  SilcUInt32 message_len indicates the message length.  The reason
  for this change is that the 'message' may be now pure binary
  data.  More of these binary messages later in this email.

  Ref:
  http://silcnet.org/docs/toolkit/silcclient.html
  http://silcnet.org/docs/toolkit/silcclient-SilcClientOperations.html


o API change in 'command' client operation.  Applications usually
  don't use this client operation much, but anyway, now it returns
  the specific error status (SilcStatus) to application to indicate
  which went wrong when executing the command in the library.

  Ref:
  http://silcnet.org/docs/toolkit/silcclient.html
  http://silcnet.org/docs/toolkit/silcclient-SilcClientOperations.html
  http://silcnet.org/docs/toolkit/silcstatus.html
  http://silcnet.org/docs/toolkit/silcstatus-SilcStatus.html


o New message flag SILC_MESSAGE_FLAG_DATA, which represents
  binary data.  The message that has this SilcMessageFlag includes
  a MIME object as a message.  Make sure you check for this flag
  in your application and display the message only if you first
  parse the MIME object.  A new function silc_mime_parse was
  added for you convenience in lib/silcutil/silcstrutil.h if you
  do not have your own MIME parser available.  I also suggest
  checking all the other message flags that exist and handle the
  message only if you know how to handle it.  This new message
  flag makes it possible to send any binary data, such as video
  stream, audio stream, images, etc. as channel message or private
  message.

  Ref:
  http://silcnet.org/docs/toolkit/silcchannel-SilcMessageFlags.html
  http://silcnet.org/docs/toolkit/silcstrutil.html
  http://silcnet.org/docs/toolkit/silcstrutil-silc_mime_parse.html


o API change in silc_client_file_receive.  A new argument 'path'
  was added which can be used to tell the destination path (directory)
  where the received file should be saved.  If omitted, current
  directory is used.

  Ref:
  http://silcnet.org/docs/toolkit/silcclient.html
  http://silcnet.org/docs/toolkit/silcclient-silc_client_file_receive.html


o I'm sure there's other minor changes in APIs and stuff but I'm
  sure you can figure them our really quickly.  Use the new Toolkit
  Reference Manual also as much as possible.


Also remember that everything listed here is implemented in the Irssi
SILC client.  It is the reference client implementation and the code
is included in the Toolkit package.  If you are in doubt or want to see
how it is done in Irssi SILC client, be sure to check the code in
irssi/src/silc/core/.  For troubleshooting use this silc-devel mailing
list.  It is preferred to use this mailing list instead of talking online
since there are many people usually wondering the same problem.  You can
also test your own client against the server found in the Toolkit package
instead of silc.silcnet.org which is still old version.

Note also that this is major new release and it is quite expected that
there are bugs because of lack of testing.  Expect bugfix releases soon.

The Win32 binary package is also coming soon for Win32 application
programmers on the website.  Please refer to the ChangeLog on the website,
or the CHANGES file in the package for a lot more detailed list of
changes.  Reading the changes list for all the way down to April 1st is
suggested.

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

SILC Protocol 1.1 specs out for comments

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

Hi,

The SILC Protocol 1.1 specification Internet Drafts are now available
for commenting before submitting them to the IETF.  If you would like to
comment on the specifications you can send comments either to this
mailing list or directly to me this by Saturday latest.  Please, do not
comment on typos or textual layout related issues since neither are
checked yet.  The specs will be submitted to the IETF next week.

There are two new drafts in addition of the four old ones.  The sixth
draft is not completed yet and thus is not available for commenting yet.
The fifth one is however available now.  See the specs at:

http://silcnet.org/docs/draft/draft-riikonen-silc-spec-05.txt
http://silcnet.org/docs/draft/draft-riikonen-silc-pp-05.txt
http://silcnet.org/docs/draft/draft-riikonen-silc-ke-auth-05.txt
http://silcnet.org/docs/draft/draft-riikonen-silc-commands-03.txt
http://silcnet.org/docs/draft/draft-riikonen-silc-flags-payloads-00.txt

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

New Release of Bombyx, Project Fully Open Now

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

Hello Everyone,

After being gone for a short amount of time, I have just made a
significant release of Bombyx.  What makes this release significant is
that I've cleaned up the build system and the dependencies considerably
so as to make porting much, much easier.  Everyone who is interested can
pick-up FreeBSD and Linux binaries, as well as source at
http://bombyx.sourceforge.net/ in the Files section.  Also, anyone who
wants to join the project and help me can e-mail me to get on.  All are
welcome.


This release now uses the FLTK 1.1.0rc1 release, SILC Toolkit 0.8.2 and
the SCons 0.07 build system instead of autoconf/automake.  SCons is a
fantastic build system written in Python (1.5.2) that does lots of nice
things like automated dependencies, cross platform operation,
configuration, and other great stuff.  I would have to say that it is
probably going to be the best thing for building C/C++ projects in the
near future.  You can get SCons (if you want to compile) at
http://www.scons.org/ and it is open source.

There is updated documentation (only a few things are incorrect) that
walks through the whole install.  Please read it and let me know if it
works for you.

The functionality of this release is pretty much the same as the last
release, except for a bunch of GUI improvements here and there, and the
removal of SigC++ (replacing it with sigslot which is included).

So, if you have time, go check it out at http://bombyx.sourceforge.net/
by either downloading source and compiling or getting a binary for Linux
or FreeBSD.

I'm also asking anyone who wants to help to lend a hand with the
project.  I'm looking for people who want to help me finish off this
initial release so that it is at a usable state.  After which, I want to
redesign the interface with some really radical ideas and finish up the
back-end code so that it has all the features needed, possibly releasing
it as a separate library for C++ SILC work.  I'm looking for anyone who
wants to get started on writing code (C++), doing win32 builds, and
creating graphics or other nice things.  Anyone who wants to join is
welcome.

The next few months will be when I start writing the File Sharing and
Private Chat features, and fix up the Agents hell that I started. 
Anyone who is interested, just e-mail me and let me know what you wanna
do.

Have a good one.

Zed A. Shaw

Re: silc-20020505

[Sami F. <sa...@ik...>]

On Mon, May 06, 2002 at 01:10:52PM +0200, Johnny Mnemonic wrote:
... 
> > Sami Farin wrote:
> > >
> > >I wanted to test CVS version because 0.8.6 release dumps core
> > >after every 2h or so.
> 
> Sami Farin: what OS are you using? what about reporting these core dumps to 

It's the same OS I mentioned in the bug report.

> someone? (if it's not a known bug..)

I reported the core dumps to this mailing list (subject corefest 2002).
I was told that the bug is fixed in CVS so I tried CVS version.

-- 
Safari - sa...@ik... - PGP key 0x427E7914 - http://iki.fi/safari/
"Talk is cheap. Show me the code." - Linus Torvalds

Re: silc-20020505

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

On Monday 06 May 2002 11:23, Matthew Aldous wrote:
> There are interface changes between toolkit (0.8.2) and
> client (0.8.6) which are a bother, as I try to isolate
> a compilation error that I know worked with the toolkit,
> but doesn't work with the client.

If once worked (as you say later) and now it doesn't work any longer, try=
=20
with previous releases until you find the exact step which broke the thin=
gs=20
down. Then you can try with the diff to isolate the exact changes and the=
n=20
you can report it.


>
> I understand there are some different branches, and that
> using the CVS source is wrong (when should the CVS
> source be used?) - could someone summarise what we
> have now, and what the ETA of things in the future may be?

No, using the main trunk is wrong.. but using the silc_protocol_1_0_branc=
h is=20
*good*! you are encouraged to use it.


> Sami Farin wrote:
> >
> >I wanted to test CVS version because 0.8.6 release dumps core
> >after every 2h or so.

Sami Farin: what OS are you using? what about reporting these core dumps =
to=20
someone? (if it's not a known bug..)

--=20
Johnny

Re: silc-20020505

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

:
: I understand there are some different branches, and that
: using the CVS source is wrong (when should the CVS
: source be used?) - could someone summarise what we
: have now, and what the ETA of things in the future may be?
:
From:

---
Date: Sat, 27 Apr 2002 12:17:06 +0200 (CEST)
From: Pekka Riikonen <pri...@ik...>
To: sil...@li...
Subject: What's new in SILC protocol 1.1

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

Re: silc-20020505

[Matthew A. <ma...@al...>]

What versions are people using at the moment? (And is there
an expected release date for the toolkit to sync up?)

There are interface changes between toolkit (0.8.2) and
client (0.8.6) which are a bother, as I try to isolate
a compilation error that I know worked with the toolkit,
but doesn't work with the client.

I understand there are some different branches, and that
using the CVS source is wrong (when should the CVS
source be used?) - could someone summarise what we
have now, and what the ETA of things in the future may be?

kr,
matthew aldous.

(PS, although the toolkit once worked for me, this is no
longer true. I'm pretty sure I'm experiencing compiler problems,
not a silc related issue. (everything links, starts, but after
connection, things just stop. I can't use silc_debug, so I'm
trying alternatives.))

Sami Farin wrote:

>On Mon, May 06, 2002 at 08:17:24AM +0200, Pekka Riikonen wrote:
>
>>:
>>: 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.
>>
>
>I wanted to test CVS version because 0.8.6 release dumps core
>after every 2h or so.
>

Re: silc-20020505

[Sami F. <sa...@ik...>]

On Mon, May 06, 2002 at 08:17:24AM +0200, Pekka Riikonen wrote:
> :
> : 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.

I wanted to test CVS version because 0.8.6 release dumps core
after every 2h or so.

-- 
Safari - sa...@ik... - PGP key 0x427E7914 - http://iki.fi/safari/
"Talk is cheap. Show me the code." - Linus Torvalds