Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dev-libs/capnproto: Security cleanup (bug #618180) #4871

Closed
wants to merge 1 commit into from

Conversation

Whissi
Copy link
Contributor

@Whissi Whissi commented Jun 6, 2017

Security cleanup, dropping an old vulnerable version.

Package-Manager: Portage-2.3.5, Repoman-2.3.2
@gentoo-repo-qa-bot gentoo-repo-qa-bot added the assigned PR successfully assigned to the package maintainer(s). label Jun 6, 2017
@gentoo-repo-qa-bot
Copy link
Collaborator

Pull Request assignment

Areas affected: ebuilds
Packages affected: dev-libs/capnproto

dev-libs/capnproto: @aballier

@aballier
Copy link
Contributor

aballier commented Jun 6, 2017

0.5.3.1 is the fixed version

please fix commit message accordingly

@Whissi
Copy link
Contributor Author

Whissi commented Jun 6, 2017

Sorry, I don't follow. From https://bugs.gentoo.org/show_bug.cgi?id=618180#c0:

However, these fuzz tests were introduced after the 0.5.x release branch,
hence are not currently present in release versions of Cap'n Proto, only in
git. A 0.6 release will come soon, fixing this.

The bugfix commit forces the compiler to perform all checks by casting the
relevant pointers to uintptr_t. According to the standard, unsigned integers
implement modulo arithmetic, rather than leaving
overflow undefined, thus the compiler cannot make the assumptions that lead
to eliding the check. This change has been shown to fix the problem in
practice. However, this quick fix does not technically
avoid undefined behavior, as the code still computes pointers that point to
invalid locations before they are checked. A technically-correct solution
has been implemented in the next commit,
2ca8e41140ebc618b8fb314b393b0a507568cf21. However, as this required more
extensive refactoring, it is not appropriate for cherry-picking, and will
only land in versions 0.6 and up.

So to be really safe and avoid problems we should drop v0.5.3.1 and keep only >=0.6.0 which should contain all the fixes/refactoring work.

Is there actual any reason why you want to keep =0.5.3.1?

@aballier
Copy link
Contributor

aballier commented Jun 6, 2017

no reason to keep 0.5.3.1 but the commit msg should still be fixed as people using 0.5.3.1 are still safe I think

anyway, this is really nitpick, so merge as is if you wish

@FuzzyGophers
Copy link
Contributor

tree is clean.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
assigned PR successfully assigned to the package maintainer(s).
Projects
None yet
4 participants