The release: https://github.com/Bitmessage/PyBitmessage/releases/tag/v0.6.3 The ebuild: https://github.com/g1itch/altcoins-overlay/blob/master/net-p2p/pybitmessage/pybitmessage-0.6.3.ebuild
CCing Michael for most recent commits to this package, hope that is fine.
This package depends on PyQt4 when not running as a daemon, right? We may need to place some restrictions on the ebuild in ::gentoo, because Qt4 is all but dead.
(In reply to Michael Orlitzky from comment #2) > This package depends on PyQt4 when not running as a daemon, right? We may > need to place some restrictions on the ebuild in ::gentoo, because Qt4 is > all but dead. $ grep -r 'dev-python/PyQt4' /usr/portage/ | grep -Ev '(profiles|metadata)' | cut -d '-' -f 1,2 -s | sort -u | wc -l 33 But It's more important now to mask 0.6.2. Critical vulnerability found in that release and an exploit exists. Read the release note, please.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a7e6fdeb9422af7e5d90543a1e27674f0b7bbb98 commit a7e6fdeb9422af7e5d90543a1e27674f0b7bbb98 Author: Michael Palimaka <kensington@gentoo.org> AuthorDate: 2018-02-14 12:05:07 +0000 Commit: Michael Palimaka <kensington@gentoo.org> CommitDate: 2018-02-14 12:05:47 +0000 net-p2p/pybitmessage: remove vulnerable 0.6.2-r2 Bug: https://bugs.gentoo.org/647568 Package-Manager: Portage-2.3.19, Repoman-2.3.6 net-p2p/pybitmessage/Manifest | 1 - .../pybitmessage/files/noninteractive-build.patch | 18 ------ net-p2p/pybitmessage/pybitmessage-0.6.2-r2.ebuild | 72 ---------------------- 3 files changed, 91 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3b33173f06f417136f6fa8eb9176ceb732bfeec9 commit 3b33173f06f417136f6fa8eb9176ceb732bfeec9 Author: Michael Palimaka <kensington@gentoo.org> AuthorDate: 2018-02-14 12:04:40 +0000 Commit: Michael Palimaka <kensington@gentoo.org> CommitDate: 2018-02-14 12:05:46 +0000 net-p2p/pybitmessage: version bump 0.6.3.2 Bug: https://bugs.gentoo.org/647568 Package-Manager: Portage-2.3.19, Repoman-2.3.6 net-p2p/pybitmessage/Manifest | 1 + net-p2p/pybitmessage/pybitmessage-0.6.3.2.ebuild | 66 ++++++++++++++++++++++++ 2 files changed, 67 insertions(+)}
Thanks Michael; now that the vulnerable version is gone, there are still some improvements that can be made to the new ebuild: * dev-python/u-msgpack can be used instead of dev-python/msgpack (setup.py) * If the daemon is all we can support going forward, we should install the OpenRC and systemd stuff. It looks like a new user is needed for the init script. * The LINGUAS stuff from Dmitri's ebuild (except LINGUAS is probably the wrong name, these days). * My comment about the deps is now obsolete, the info is split between setup.py and checkdeps.py. * Dmitri's ebuild lists some new dependencies that should be considered; but if they are automagic, I would suggest making them unconditional so that the features don't mysteriously disappear for users.
(In reply to Michael Orlitzky from comment #5) > Thanks Michael; now that the vulnerable version is gone, there are still > some improvements that can be made to the new ebuild: > > * dev-python/u-msgpack can be used instead of dev-python/msgpack (setup.py) > * If the daemon is all we can support going forward, we should install the > OpenRC and systemd stuff. It looks like a new user is needed for the init > script. > * The LINGUAS stuff from Dmitri's ebuild (except LINGUAS is probably the > wrong name, these days). > * My comment about the deps is now obsolete, the info is split between > setup.py and checkdeps.py. > * Dmitri's ebuild lists some new dependencies that should be considered; but > if they are automagic, I would suggest making them unconditional so that the > features don't mysteriously disappear for users. Don't bother about any new dependencies (and sound use-flag) because without qt it worth nothing. Also you discouraged the use of LINGUAS in my previous bug. Upstream provides systemd unit but I didn't test in.
Sorry, I'm not trying to be annoying, I just want to ensure that we don't commit something that needs to be fixed as soon as it hits the tree. The Qt4 removal process has already begun: $ grep -i qt4 $REPOS/gentoo/profiles/package.mask # Requires dead Qt4 (bug #645420). Removal in 30 days # Dead upstream, depends on deprecated Qt4. # Depends on deprecated Qt4, unmaintained, no one bothers to bump. # Dead upstream, depends on deprecated Qt4. # Dead upstream, depends on deprecated Qt4. # Dead upstream, depends on deprecated Qt4. # Depends on deprecated Qt4, no revdeps left. # Depends on deprecated Qt4, dead project. # Depends on deprecated Qt4, upstream is slowly doing a qml port. # Depends on deprecated LINGUAS/Qt4/kde4-functions.eclass. # Dead upstream, depends on dead Qt4/poppler-qt4. # Depends on dead PyQt4/Qt4, upstream needs help w/ PyQt5. # Depends on dead Qt4, upstream porting inquiry pending. Bug #631788 # The old yafaray-0.1.1 depends on qt4 and has bugs we can not fix. # Qt4WebKit is ancient and full of security holes. # Depends on dead Qt4WebKit. Masked for removal in 30 days. Bug #620702 and there are bugs open against the packages that still use it. The right way to move forward would be to port pybitmessage to PyQt5; of course that may not be easy.
If we consider the amount of existing Qt4 revdeps before starting work on removing individual revdeps, then it will remain in tree forever. So that's not really a valid argument. For pybitmessage, if you depend on this package and want it to remain in Gentoo in the near term, you should get active and tell upstream they should really really make PyQt5 a priority (they are citing Windows XP support even in 2017...), see also https://github.com/Bitmessage/PyBitmessage/issues/897
s/want it to remain/want to continue use its GUI/
Seems I've stirred up upstream a bit in the linked issue. :)
Thanks asturm and mjo, I see that 0.4.x was stable in ebuild repo, is that version affected by this vulnerability?
(In reply to Christopher Díaz Riveros from comment #11) > Thanks asturm and mjo, I see that 0.4.x was stable in ebuild repo, is that > version affected by this vulnerability? 0.4.2 does not contain the relevant code. 0.6.x was never stable.
