[
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)
