IRC Devel Meeting - 2015-02-11

Date:

• Proposed: 15:00 UTC, Wednesday, Feb 11, 2015
  • can attend: dcm, oej, vseva
• Alternatives (add your id if you can attend)
  • Feb 12 (dcm)
  • Feb 17 (dcm)
  • 14:00 UTC (neuhaus)

Time of the meeting across the world:

• 16:00 - Berlin, Germany
• 15:00 - London, UK
• 10:00 - New York, USA

Utilities:

• Time Converter
• IRC webchat: http://webchat.freenode.net/
• IRC client apps: http://en.wikipedia.org/wiki/Internet_Relay_Chat#Clients

Place:

• #kamailio IRC channel on irc.freenode.net server

Participation is open to anyone, just join the IRC channel if you want to participate.

People adding notes in the agenda using abbreviations:

• dcm - Daniel-Constantin Mierla
• oej - Olle E. Johansson
• vseva - Victor Seva
• fisp - Fred Posner

Kamailio Development:

• open issues (dcm)
  • /tmp in defaults (vseva)
• new additions (dcm)
• roadmap to next major release (dcm)
• more consistency on name of main c file for a module (dcm)
• rename sercmd to kamcmd in the source code (dcm)

Kamailio Logo:

• settle on a final decision and next steps (dcm)

Kamailio Administration:

• RPM packaging and repositories (dcm)
• backups (dcm)
• unit tests (dcm)
• GitHub workflow - anything to tune or improve (dcm)
  • a rebased pull-request looses all their comments? (vseva)
• GitHub admin repo - admin/release scripts (vseva)
• Security vulnerability handling (proposal below) oej
  • consider RITR? (fisp)

References: * https://wiki.asterisk.org/wiki/display/AST/Asterisk+Security+Vulnerabilities

A security vulnerability is when a user of Kamailio can cause Kamailio to crash or lock up by sending messages to the server process.

If you believe there's a security vulnerability, please don't use the public forums. Send e-mail to security@kamailio.org and the issue will be handled properly.

1. Send an e-mail to security@kamailio.org and include the following information
   • A summary
   • A detailed explanation of how this issue can be exploited and/or reproduced
2. A member of the Kamailio Security Team will respond
3. The kamailio developer team will work to solve the issue. When there is a patch for the issue, it should NOT be committed directly. It should be coordinated with the release of a security release as well as the publication of a Kamailio project security vulnerability report.

Kamailio will publish security vulnerabilities, including an CVE ID, on the kamailio-announce mailing list, sr-users as well as related lists. The advisories will also be published on the kamailio.org web site.

A Kamailio Security team should be appointed with core developers of the project. These individuals will be part of the security process and review patches and text for the vulnerability report. Two persons should take the role of Kamailio Security Officers. One of these should manage each security incident - which does not mean solving the code issue, but managing the process from report to publication and patch release.

This address should have a PGP key associated, used by the security officers.