From: Shawn <sg...@op...> - 2006-09-07 16:12:46
|
david wrote: > I'm astounded by the thundering silence. For the time being I've simply > shut down postgres - I'm sure this is not an option for most users of > SL. > > Chris: You keep saying that you are being censored, but I keep getting > your emails from the list. I don't get that? > > Dieter: Please tell us this is not as serious as Chris says it is, or > else verify that his fix works. (or incorporate it?). > > thanks guys... either way, I'm grateful that users of this very useful > piece of open source software at least hear about security issues. :) Thundering silence. Because the issue at hand is technical enough that most average users don't understand it. The case here is only PARTIALLY an SQL-Ledger problem (IMO). Yes, the authentication process can be made stronger. But show me an application where that is not the case. THe problem with the cookies is NOT an SQL-Ledger specific problem. The way the info in the cookies can be used on the URL is. EVERY browser out there will have the same flaw with the cookies. So how is Dieter to fix that? Does he contact Microsoft, Mozilla, KDE, etc. and submit a patch for their browsers? Or does he focus on the SL specific problems. The fact that authentication details are placed on the URL is a bigger issue though. On the otherhand, let's not forget the way SL works. You can interact with it from the command line. Without a browser. I suspect these "session" fixes being proposed would utterly break that functionality, seeing as Sessions are web based. I do not see a disregard for this issue at all. It has been discussed on the list. Dieter has stated where he thinks the problem to be, and that the issue is browser and/or environment related. Chris himself has pointed out a fix for the issue that does not involve code - put the SL sites behind SSL. Or require .htaccess authentication. Both of these are very simple solutions, and *could* be a recommeneded practice for running SL. If an installer chooses not to use SSL or .htaccess, then it is their choice. A simple non-coding solution that does not break SL functionality in the slightest, or introduce new potential bugs/security holes. As for censoring, I don't see that happening at all. What I DO see happening is a bit of MUCH needed list moderation. You only have to read the messages from the past 2 weeks, and keep in mind the purpose of the list, to see why this is being done. So a fork is taking place. So be it. This is the nature of open source - if you don't like the way it's being done, do it yourself. But, most forks fail and/or are merged back into the original app. This is not a case of the app being abandoned, so I don't see any forks succeeding for too long. But I do wish the fork well as it's intent (at least initially) is respectable. But until I see a distinct improvement (not to mention a release) I won't be changing my routines or software at all. Shawn |