tommi: can you volunteer someone to own libsrtp and make sure it gets rolled at least once a month?

Unfortunately, upstream doesn't seem to have an especially robust or reliable release process. As of today, for example, the fix to issue 625698 hasn't been integrated into any released version.
(https://github.com/cisco/libsrtp/commit/078df3977e37827d93e5c26c7f80dd6c8fe6070e)

Meanwhile, master is under active development with no obvious guarantees of reliability.

Are you aware if master is intended to be in a good state? If so I don't think we should only roll to numbered versions of libsrtp.

tommi: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The existence of release tags and a 1.x servicing branch, along with a VERSION file that says "2.0.0-pre", suggests to me that the libsrtp project treats master as a prerelease/dev branch. If we just use master, I expect we miss out on some verification and we'll be running a different version from everyone else.

Matt - are you OK with owning this?  I don't have much time to devote to this right now but we could possibly find someone here in Stockholm to take a look if you don't have time.

It will be about a month until I can take a real look at this.

mattdr: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Does this really merit Security-High? At this point I don't think we're aware of any Security-High vulns in libsrtp.

My estimate in comment 10 still stands -- can't get to this until at least the end of the month.

mattdr@ -- it's a new month :)
Do you have an estimate of when you can start working on this?

tommi@ -- in case mattdr@ is still busy, could you please help find another owner for this?

We commit ourselves to a 60 day deadline for fixing for high severity vulnerabilities, and have exceeded it here. If you're unable to look into this soon, could you please find another owner or remove yourself so that this gets back into the security triage queue?

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Yes, I'm going to try to deal with this next week.

I believe "at least 2 known bugs" was referring to:
-  issue 627748 , which we established wasn't high severity
- issue 625698, which is fixed in M54
- CVE-2015-6360, which was fixed upstream in https://github.com/cisco/libsrtp/commit/704a3177 and in Chromium 10 months ago in https://chromium.googlesource.com/chromium/deps/libsrtp/+/b8dd754b

No doubt, it would be nice if we'd been more on top of this, but there doesn't seem to be a Sev-High security bug here.

Updating libsrtp to 2.0 is tracked in webrtc:6376.

Patrik is out for the next week or so. Who would be the best person to review a bunch of libsrtp-related CLs?

mattdr@, have you managed to update libsrtp? Can we mark this as Fixed?

Very close. The last CLs should land this week or early next.

libsrtp in Chrome has been updated as of https://chromium.googlesource.com/chromium/src/+/c2eb0266eee3348b00ad3cdc1261d71cefe47333.

Your change meets the bar and is auto-approved for M55 (branch: 2883)

**** Bulk edit -  please ignore if not applicable ****

Please merge your change to M55 branch 2883 today before 5:00 PM PT or latest by tomorrow, Tuesday (11/01/16) 4:00 PM PT so we can take it for this week Beta release. 

Cherry-pick CL is https://codereview.chromium.org/2462213002/. I'm not a committer, though, so looking for a reviewer.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/95ad82f20f781c2078837ad9e670087e5fb106de

commit 95ad82f20f781c2078837ad9e670087e5fb106de
Author: mattdr <mattdr@chromium.org>
Date: Mon Oct 31 21:26:46 2016

Upgrade libsrtp to version 2.0

Roll DEPS for libsrtp to pick up version 2.0. Fix up remaining client.

Roll src/third_party/libsrtp/ b17c065a8..71692eaab (5 commits).

https://chromium.googlesource.com/chromium/deps/libsrtp.git/+log/b17c065a8a63..71692eaab2a0

$ git log b17c065a8..71692eaab --date=short --no-merges --format='%ad %ae %s'
2016-10-20 kjellander Only build libsrtp tests if a build flag is set
2016-10-20 kjellander Don't build tests on Windows.
2016-10-12 kjellander Disable warning for signed/unsigned mismatch in MSVC
2016-10-10 kjellander Make libsrtp configuration public
2016-10-06 kjellander Update libsrtp to version 2.0

BUG= 625878 
NOTRY=true
NOPRESUBMIT=true

Review-Url: https://chromiumcodereview.appspot.com/2436913003
Cr-Commit-Position: refs/heads/master@{#426814}
(cherry picked from commit c2eb0266eee3348b00ad3cdc1261d71cefe47333)

Review-Url: https://codereview.chromium.org/2462213002
Cr-Commit-Position: refs/branch-heads/2883@{#397}
Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768}

[modify] https://crrev.com/95ad82f20f781c2078837ad9e670087e5fb106de/BUILD.gn
[modify] https://crrev.com/95ad82f20f781c2078837ad9e670087e5fb106de/DEPS
[modify] https://crrev.com/95ad82f20f781c2078837ad9e670087e5fb106de/testing/libfuzzer/fuzzers/libsrtp_fuzzer.cc

Merged:
https://codereview.chromium.org/2462213002

... which threw a flag, so Di helped me change DEPS in buildspec:
https://chromereviews.googleplex.com/531437013/

Compile failure after merge:
https://bugs.chromium.org/p/chromium/issues/detail?id=660985
... because I failed to *also* cherry-pick a WebRTC change.

Rolled back:
https://codereview.chromium.org/2464883004/
https://chromereviews.googleplex.com/532127013

As described in comment 16, this isn't a critical fix. It's going to wait for M56.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot