Bug 206607 - Forthcoming OpenSSL Security Releases (1.0.2f, 1.0.1r.)
Summary: Forthcoming OpenSSL Security Releases (1.0.2f, 1.0.1r.)
Status: Closed Not A Bug
Alias: None
Product: Services
Classification: Unclassified
Component: Security Team (show other bugs)
Version: unspecified
Hardware: Any Any
: --- Affects Many People
Assignee: Kubilay Kocak
URL: https://mta.openssl.org/pipermail/ope...
Keywords: needs-patch, needs-qa, security
Depends on: 206608 206610
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-25 13:43 UTC by Kubilay Kocak
Modified: 2016-04-17 11:46 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kubilay Kocak freebsd_committer freebsd_triage 2016-01-25 13:43:05 UTC
The OpenSSL project team would like to announce the forthcoming release of
OpenSSL versions 1.0.2f, 1.0.1r.

These releases will be made available on 28th January between approx.  1pm and
5pm (UTC). They will fix two security defects, one of "high" severity affecting
1.0.2 releases, and one "low" severity affecting all releases.
Comment 1 Remko Lodder freebsd_committer freebsd_triage 2016-01-25 13:50:45 UTC
This had been noted in our tracker. Closing this ticket. Note that I personally am not in favor of getting the information like this. Please send us an email instead.
Comment 2 Kubilay Kocak freebsd_committer freebsd_triage 2016-01-25 13:54:13 UTC
(In reply to Remko Lodder from comment #1)

FWIW, this was for tracking the progress, not for notification.

Beyond that the releases & announcements are already public. Having public issues to track security vulnerability resolution is a net benefit for our users

For embargoed issues, of course private channels should be used. I don't believe this is one of them
Comment 3 Kubilay Kocak freebsd_committer freebsd_triage 2016-01-25 13:56:02 UTC
I'd urge secteam to consider re-opening this issue, and leaving it assiged to yourselves. At a minimum we may communicate it's progress (for the port as well) to the community more easily.

You are quite welcome not to make any public changes to this meta issue.

If not, I'll gladly re-open the issue and assign it to myself, tracking the updates accordingly
Comment 4 Remko Lodder freebsd_committer freebsd_triage 2016-01-25 13:57:43 UTC
Secteam has a policy written that issues should be delivered through email to secteam@ or if a more secure way is needed to communicate to security-officer@.

I will not be doing double work to have multiple tickets. If you want to track this, fine, but we use our own tracker to track this incident. Once an advisory is needed we will work on that and get it out of the door, notifying people about that.
Comment 5 Kubilay Kocak freebsd_committer freebsd_triage 2016-01-25 14:01:06 UTC
I'll take this issue, while things happen internally.
Comment 6 Kubilay Kocak freebsd_committer freebsd_triage 2016-01-25 14:08:46 UTC
(In reply to Remko Lodder from comment #4)

FWIW, I believe there's only potential for double work due to their being a second issue tracker instance. 

In the meantime, users continue to report security issues both in base and ports in this issue tracker, and again I believe there is lot's of value in progress being visible to the community, even if the content of SA's and vulnerabilities remain undisclosed.

It's perfectly feasible to configure a 'Security Team' specific area in this issue tracker that defaults to all reported issues being private, or however secteam would like it configured.

Don't hesitate to let Bugmeister to know if and when you'd like the best of both worlds. Come join us!
Comment 7 Kubilay Kocak freebsd_committer freebsd_triage 2016-01-25 14:09:55 UTC
Whoops, forgot I removed you from CC, apologies Remko.

See my reply in comment 6, I'm happy to continue on email instead of here if you'd like to discuss (or argue ;])
Comment 8 Bartek Rutkowski freebsd_committer freebsd_triage 2016-04-17 11:46:10 UTC
Since SA for this issue were published long time ago, I am closing this PR.