kurento-media-server

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

Al the code pushed to master is a interim version with appropriate comments and public available nightly versions to test.

Repository on GitHub, which uses git. git is distributed.

https://doc-kurento.readthedocs.io/en/stable/dev/release.html here you can find how the versioning works and how it must be interpreted.

https://github.com/Kurento/kurento-media-server/tags

Non-trivial release notes file in repository: https://github.com/Kurento/kurento-media-server/blob/master/CHANGELOG.md. Change log is also available in the project main page https://doc-kurento.readthedocs.io/en/latest/project/relnotes/index.html

We will use the security label in the bugtracker in combination with the rest of the badges to mark the criticalness. And then in the release notes the id of the github issue will be used. Within the Release Notes we have a section "Fixed" where all the bugs fixed are listed -with its reference to the github issue id (if any) is provided- We don't have an specific way of register or link them with known CVE. That is because all the security bugs found and solved have been bugs on third party libraries, for example a bug on the libnice library that is reported to have a security bug, and we will update this third party library in the next release, with the latest version that solves this issue. Kurento could be probably added to the low-level software.

We have both mailing list https://groups.google.com/forum/#!forum/kurento and issue trackerhttps://github.com/Kurento/bugtracker

https://github.com/Kurento/bugtracker

Met on best effort the project is maintained by a small group but is big and heavily used and we try to acknowledge all the issues reported and provide workarrounds or evaluate the criticalness.

Met on best effort the project is maintained by a small group but is big and heavily used and we try to acknowledge all the enhancement request .

https://github.com/Kurento/bugtracker

There is an specific label on the GitHub. We don't have an specific way of reporting but the usual one, the community has used the bugtracker or the mailing list effectively and the issues have always being addressed. https://github.com/Kurento/bugtracker/issues

No private reports are requested or supported by default.

We give our first response to all the issues reported as soon as possible being always under 7 days from reporting. This is no a vulnerability exactly but is an enhanced related to security and you can assess that we are actively listening the community regarding this. https://github.com/Kurento/bugtracker/issues/518 yo may take also any other issue of the last 6 months.

Non-trivial build file in repository: https://github.com/Kurento/kurento-media-server/blob/master/CMakeLists.txt.

Non-trivial build file in repository: https://github.com/Kurento/kurento-media-server/blob/master/CMakeLists.txt.

We have a Jenkins CI in place with some jobs that run the available jobs found in the repositories. https://doc-kurento.readthedocs.io/en/stable/dev/ci.html

https://doc-kurento.readthedocs.io/en/latest/dev/testing.html here there is a whole explanation of what are the provided test and how execute them.

Kurento not only provides a big set of unitary tests but provides functional tests over demo projects to address the validation of each release and validate it is working. Kurento doesn't maintain different code branches, doesn't have user interaction (no input fields).

We have a Jenkins CI in place that compiles, test and submit the compiled and dockerized software to the standard repositories.

Unitary tests are always developed for new functionalities, unless they are irrelevant. The CI/CV server executes all test before any release and the tests are public for al the contributors and users to use.

The tests are public and main functionality is quite stable. Major changes that affect tests provoke the tests to be changed or they will fail and the release could not happen. Just if the SW has been released it means it has been tested.

In the "Instructions for change requests" the template of PR ask twice for the tests (https://github.com/Kurento/.github/blob/master/pull_request_template.md): 1. In a free text field where it should be explained how it has been tested 2. Checkbox indicating if new tests have been written. We usually evaluate those conditions as compulsory requirement.

Kurento Releases are built firstly as .deb packages to be instaled in Debian/Ubuntu systems. The system tools which generate this files are also the ones activating all security mechanisms when compiling sources: (i) all warnings as errors, (2) memory safety ASLR and many other following the usual recomendations of binary compilings.

As treating all WARNING as ERRORS at compilation time if the WARNING isn't addressed there wouldn't be a new release.

https://github.com/j1elo

https://github.com/j1elo

We delegate the secutirty to our standard distribution mechanisms. Deb repositories verify all the packages with a unique GPG for each project this way even HTTP downloads can be granted as secured. On the other hand we deliver the software as Docker images publicly hosted on DockerHub and we relay on the download security mechanism DockerHub may implement.

See previous answer.

We prioritize vulnerabilities and crashes over any other issue or request for changes.

We prioritize vulnerabilities and crashes over any other issue or request for changes.

No need of private Keys

We use clang-tidy y clang-analyzer.

Valgrind & AddressSanitizer, but we don't have them integrated in the release cycle we use them when we see fit.

Valgrind y AddressSanitizer. But as our memory leaks or similar problems usually occur under scenarios very difficult to reproduce. Thus we offer a custom Docker image with AddressSanitizer to users. Then in the case any user finds memory leaks the execution of this image in their specific use case will provide us (and all the community) with the results and can help us to solve the issue.