From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)
Description of problem:
As I understand it from gaim.sourceforge.net and www.silcnet.org, gaim
now ships with the silc protocol, however the gaim-0.82.1-1 RPM does
not appear to ship with silc enabled. In order to use the built-in
silc functionality, I have to recompile from gaim sources, rather than
use the RPM.
As documented on the silcnet.org site, silc is a media-rich IM
protocol built from the ground up with security as a primary concern.
In the spirit of RedHat moving towards more secure systems (such as
SElinux) and enterprise platforms (RHEL), it seems this would be an
extremely useful modification to the existing gaim RPM.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Run gaim, notice no ability to create an account using silc.
Actual Results: Unable to use the silc protocol in gaim.
Expected Results: silc protocol should be available.
SILC is not in Fedora Core. Due to this, the SILC plugin cannot be in
the Fedora-supplied Gaim package.
Naturally, after submitting this and googling around a little bit more
I found a snipping in the changelog for the gaim RPM circa FC1, so it
looks like some thought has been put into this before now.
* Sun May 30 2004 Warren Togami firstname.lastname@example.org 0.78-2
- update to 0.78 (without SILC support for now)
I asked for libsilc inclusion into FC. Technical leadership said no.
was any reason given? if so, has that reason been communicated to the
silc people? i'm curious because i get asked why we can't build with
silc support frequently (the reason being the lack of packages in the
1. They felt that nobody actually uses it.
2. Feature creep.
Actually, I asked if there was a server that existed for it. And no
- is it implemented in any client other than gaim
- is there a) server code b) public servers
- since it's a draft spec, are we going to get bitten by protocol
changes in the future?
Yes, there are several client implementations (Silky -
http://silky.sf.net/, the reference client at http://silcnet.net/,
possibly others). There is a plublic, open source server implentation
at silcnet.net, as well as a server running for public use. There are
also numerous private SILC servers in use by various organizations and
individual around the 'net -- I use one daily.
As far as the spec being draft, the SILC protocol specification has
been very stable for years... It has changed from time to time, but
not often. I do not anticipate major changes to the draft
specification at this point. (Caveat emptor, I am not a SILC dev, I
am a Gaim dev.)
I have tentative approval to include libsilc in FC3, but only if the
concerns addressed in this report are fixed first. nosnilmot is
investigating now, but it would help if upstream silc could comment on it.
Forgot to include this report.
First of all, I wanted to mention that the response to this has just
been incredible. I never expected the responsiveness on this to be
anything near what I've seen. This has been a first to me: mentioning
something that I felt was really missing in the Linux builds that I
prefer to use, and then seeing positive responses from both the Gaim
team and the RedHat team. Thanks to everyone here for listening to
me, and for taking my request under consideration!
On the nature of SILC, I believe the most compelling argument is that
it is the only instant messaging protocol to really have any degree
of security in mind. I don't believe that it is perfect, but I do
believe it is the best thing out there at this point. Instant
messaging is on the corporate network, it has some degree of
usefulness, and it is here to stay. RedHat's implementing a secure IM
protocol, personally, I see as an excellent move.
If there is anything I can do to help research or test this
functionality, please don't hesitate to mention it in this medium.
Again, thanks to everyone for running with this.
The gaim package in Fedora Core rawhide includes SILC as a transport
protocol. I am closing this ticket; feel free to file new entries as
bugs if you do discover problems.