1 dec 2011 kl. 12:54 skrev Daniel-Constantin Mierla: > > > On 12/1/11 12:44 PM, Olle E. Johansson wrote: >> 1 dec 2011 kl. 11:43 skrev Daniel-Constantin Mierla: >> >>> >>> On 11/29/11 9:28 PM, Olle E. Johansson wrote: >>>> 29 nov 2011 kl. 18:57 skrev sip-router: >>>> >>>>> THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. >>>>> >>>>> A user has added themself to the list of users assigned to this task. >>>>> >>>>> FS#184 - Crash if t_release() is executed after t_relay_to(), when this >>>>> last returns -1 >>>>> User who did this - Iñaki Baz Castillo (ibc) >>>>> http://sip-router.org/tracker/index.php?do=details&task_id=184 >>>>> >>>> Now this was caused by bad configuraiton, but if we have had or will have >>>> crashes based on incoming MI, RPC or SIP messages, we should have a >>>> routing for how to handle security fixes in Kamailio. When evaluating open >>>> source projects I always check the security procedures. >>>> >>>> Anyone interested in assisting in writing up a document about this we can >>>> publish on the web site and try to follow if we get such an issue? I think >>>> we can happily steal from other projects, so it should not be hard work. >>>> >>>> Anyone objecting to implementing a process for handling security incidents? >>> I have no objection in this regard, any contribution/managing process that >>> will make usage of the project easier/more attractive for various people is >>> welcome. The question will be who will take the work (e.g., reviewing, >>> categorization, announcements to devels and community, ...). >>> Personally, I try not to make a difference between bugs, but just try to >>> solve asap, with priority on how common use case is the situation rising >>> the bug. >>> >>> Another question is categorizing 'security bugs' - in my understanding I >>> consider such bugs when one can gain access to server or steal/compromise >>> data from/on the server. Chasing situations are not in this category (IMO). >> That's one side of it. The other is when a message sent over the network can >> put the server in a bad state or crash it - a DOS attack oppurtunity. > > Yes, it is, but this causes crashes even when it is not an intentional > attack. Maybe a better phrasing would have been "security risk" bugs -- those > that can compromise the privacy and integrity of data on the server. > Otherwise, yes, they are bugs causing crashing and server unavailability -- > the very common bugs we had and going to have many times. > > I would rather use two categories: > - security - like access to server, data loss or unauthorized routing causing > financial damages > - stability - like crashing, memory leaks, etc... (when they don't cause a > security flaw) > > Again, this is my perception and I know the limits of security depends on the > point of view of each person. At the end, perhaps who is going to undertake > the job will make the decision...
I think there are clear definitions here we can copy. I'll take a look. /O _______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
