CVE-2015-5474 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2015-5474): BitTorrent and uTorrent allow remote attackers to inject command line parameters and execute arbitrary commands via a crafted URL using the (1) bittorrent or (2) magnet protocol.
Is there any movement on this?
Find me a patch and I'll apply it. bittorrent hasn't been updated since 2006.
(In reply to Ryan Hill from comment #2) > Find me a patch and I'll apply it. bittorrent hasn't been updated since > 2006. should we even keep such crap in the tree rather than remove or at least mask it?
The last time I tried to remove it infra asked me not to. Bug #336166.
So for now lets Mask it. Any objections to that?
None, go right ahead.
# Sergey Popov <pinkbyte@gentoo.org> (25 Nov 2015) # Dead upstream, security issues, see bug #557856 # Removal in a month net-p2p/bittorrent
Infra are you OK with removal of BitTorrent from tree, because of dead upstream. We have other clients that are actively developed. Do you see any reason for not removing it from tree?
What is the replacement for programmatic modification of Torrents? Here's the most recent version of the script we have for infra usage: http://dev.gentoo.org/~robbat2/scripts/changetorrent-console-20120102 Older versions in that directory. It's mostly feature complete so hasn't needed changes since 2012. It only gets used for the LiveDVD releases, which are quite infrequent. That's the ONLY usage of the original net-p2p/bittorrent left in infra.
I should also note that app-arch/cfv[bittorrent] requires it. And masking it broke that package. And nobody even cared to reply to my mail about it, until monsieurp volunteered to fix it himself because it triggered the failure in all incoming PRs. If you want to remove stuff, sure, but please clean up after yourselves.
> I should also note that app-arch/cfv[bittorrent] requires it ...on hppa.
Could this one be added instead https://en.wikipedia.org/wiki/Opentracker? There seems to be an already ebuild at http://gpo.zugaina.org/net-p2p/opentracker
@octavian: opentracker does not provide an API to edit .torrent files. That's all the infra script does. We use public trackers, we do not run out own.
(In reply to Robin Johnson from comment #13) > @octavian: > opentracker does not provide an API to edit .torrent files. > That's all the infra script does. We use public trackers, we do not run out > own. Do you think there is a replacement that is possible?
(In reply to Yury German from comment #14) > (In reply to Robin Johnson from comment #13) > > @octavian: > > opentracker does not provide an API to edit .torrent files. > > That's all the infra script does. We use public trackers, we do not run out > > own. > > Do you think there is a replacement that is possible? Yes, just nobody seems to have written it at all! Most torrent code is aimed at just running a tracker or client, not generating or editing .torrent files. Even libtorrent doesn't let you edit the pieces that my code uses the original libraries for.
http://search.cpan.org/~sanko/Net-BitTorrent-0.052/lib/Net/BitTorrent/Torrent.pm Is probably the closest in functionality to the original Python API, but I'm not sure it's complete either.
@Robin Johnson 1. I do run my own tracker to distribute family/friends photos. The torrents I create are also marked as private. 2. I use mktorrent to generate torrent files net-p2p/mktorrent.
(In reply to Octavian from comment #17) > @Robin Johnson > > 1. I do run my own tracker to distribute family/friends photos. Yes, opentracker is a good replacement for this. > The torrents I create are also marked as private. Beware, there are clients that ignore the private bit as specified by BEP0027 [http://www.bittorrent.org/beps/bep_0027.html]. Mostly those that don't explicitly implement the required special handling for that key. > 2. I use mktorrent to generate torrent files net-p2p/mktorrent. Which does NOT allow the detailed tweaking of the torrent files that the old code did.
removed from the tree
Arches and Maintainer(s), Thank you for your work. Thank you all. Closing as noglsa.
According to https://en.wikipedia.org/wiki/BitTorrent_(software) ```` Version 4.20 of the client was dubbed Allegro by BitTorrent Inc., in reference to protocol extensions developed by the company to accelerate download performance and ISP manageability. Since version 6.0, the BitTorrent client has been a rebranded version of µTorrent. As a result, it is no longer open source. ```` In fact until the latest 5.30 version available from Internet Archive <http://web.archive.org/web/20100330145634/http://www.bittorrent.com/btusers/download/directory-list> as BitTorrent-5.3-GPL.tar.gz, net-p2p/bittorrent is not vulnerable. Also, would you use BitTorrent-5.3-GPL.tar.gz to update the python lib to a newer version ?
We have removed bit torrent from tree.
I did not notice until it is masked. Since there is in fact no CVE problem, is this OK to restore it ?
That version required packages that aren't in the tree anymore, namely wxpython-2.6. It might be possible to restore 5.3 without the GUI bits, but someone else would need to step up and do the work. There are much better torrent clients available that are actually maintained. Or you could just throw the ebuild into an overlay if you really can't live without it.
(In reply to Galaxy from comment #23) > I did not notice until it is masked. > > Since there is in fact no CVE problem, is this OK to restore it ? There s a high vulnerability assigned to this: BitTorrent and uTorrent allow remote attackers to inject command line parameters and execute arbitrary commands via a crafted URL using the (1) bittorrent or (2) magnet protocol. This project is not maintained.
