thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (THRIFT-4506) [CVE-2018-1320] Remove assertion in Java SASL code that would be ignored in release builds
Date Sat, 09 Mar 2019 16:15:00 GMT

    [ https://issues.apache.org/jira/browse/THRIFT-4506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16788723#comment-16788723
] 

Christopher Tubbs commented on THRIFT-4506:
-------------------------------------------

[~jking3] The ASF release process applies to any release that is backed by the foundation
(e.g. performed under the purview of a PMC). In this case, it was published through the ASF
distribution channel supported by INFRA, without proper vetting. It does not matter that it
affected one language or not. I would encourage the Thrift PMC to re-familiarize itself with
the ASF publication rules for releases at https://www.apache.org/dev/release-publishing.html
and the INFRA distribution policies for distributing releases through INFRA channels at https://www.apache.org/dev/release-distribution

[~jensg]; you can't unrelease from the Nexus repository. At this point, I think it would be
best to simply create a tarball from the contents of the 0.9.3.1 branch used to create the
artifacts which were pushed to Nexus/Maven Central (and a git tag, as per your usual process).
This could be created by simply checking out the branch, and deleting the '.git/' directory,
and creating a tarball from that, with signatures and checksums. If you vote on that, and
the vote passes, you can just put that on the ASF distribution mirrors, and consider the matter
resolved with lessons learned. The vote is what makes the artifacts in Maven Central go from
"a set of files prepared by an individual" to "a formal offering of the ASF" as per: https://www.apache.org/dev/release-publishing.html#voted
; but I don't think it's necessary to try to unrelease/re-release if the process would result
in the same built artifacts. A passing vote here would also save you from having to re-setup
any build environment, since you don't have to rebuild anything to prepare a source tarball
to vote on.

However, if the vote fails for any reason, then you'll probably have to vote on a newly built
0.9.3.2 and release that to supersede 0.9.3.1.

Either way, I think it'd be a good idea to summarize both the mistake and corrective action
in the next board report, because it may serve as a useful lesson-learned for others.

(Side note: it's also a good idea to make sure all your release votes happen on your dev@
list, and not on any private lists...; it's important that there be a public record of the
fact that a release is backed by the ASF.)

> [CVE-2018-1320] Remove assertion in Java SASL code that would be ignored in release builds
> ------------------------------------------------------------------------------------------
>
>                 Key: THRIFT-4506
>                 URL: https://issues.apache.org/jira/browse/THRIFT-4506
>             Project: Thrift
>          Issue Type: Bug
>          Components: Java - Library
>    Affects Versions: 0.5
>            Reporter: James E. King III
>            Assignee: James E. King III
>            Priority: Minor
>              Labels: SASL, security
>             Fix For: 0.9.3.1, 0.12.0
>
>
> There is an assertion in the SASL transport for Java that will only be processed in debug
builds, at https://github.com/apache/thrift/blob/master/lib/java/src/org/apache/thrift/transport/TSaslTransport.java#L298.
 The preceeding while loop can be changed to guarantee this assertion in all builds.
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-1320



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message