Bug 669251 - rtorrent fails to announce to invalid https trackers
Summary: rtorrent fails to announce to invalid https trackers
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: rtorrent
Version: 13
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ---
Assignee: Conrad Meyer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-01-13 01:49 UTC by Richard Guest
Modified: 2011-05-27 00:29 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2011-05-27 00:29:24 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
rtorrent insecure https patch (1.88 KB, patch)
2011-01-13 03:16 UTC, Richard Guest
no flags Details | Diff
patch for rtorrent-0.8.7 (2.47 KB, patch)
2011-01-13 03:50 UTC, Richard Guest
no flags Details | Diff
A less munged patch against 0.8.7 (2.73 KB, patch)
2011-01-13 20:51 UTC, Richard Guest
no flags Details | Diff

Description Richard Guest 2011-01-13 01:49:55 UTC
Upstream bug/RFE is http://libtorrent.rakshasa.no/ticket/1402

I've been frustrated by this bug for a while, with trackers using self-signed certificates and expired but otherwise valid certificates... when the underlying libcurl guff is perfectly capable of using https in insecure mode.

...so for the sake of brevity and in the interests of openess and what-not, here's my patch against rtorrent-0.8.6-4.fc13.

rtorrent -o https_insecure=yes

Comment 1 Conrad Meyer 2011-01-13 03:08:59 UTC
I'm happy to take a patch, but I don't see one here or on the upstream tracker. Can you post it? Thanks!

Comment 2 Richard Guest 2011-01-13 03:16:24 UTC
Created attachment 473191 [details]
rtorrent insecure https patch

Apologies for earlier attachment fail.

Comment 3 Richard Guest 2011-01-13 03:50:27 UTC
Created attachment 473198 [details]
patch for rtorrent-0.8.7

rtorrent-0.8.7 does the command line parsing slightly differently.
This patch should do the trick.

Comment 4 Conrad Meyer 2011-01-13 04:08:43 UTC
Thanks. Applied in rawhide, built in koji:

http://koji.fedoraproject.org/koji/taskinfo?taskID=2718382

I think we should be fine pushing this to released branches as well, assuming they're on 0.8.7 as well.

Comment 5 Conrad Meyer 2011-01-13 04:21:31 UTC
Er, patch didn't apply cleanly. Will try to sort it out.

Comment 6 Richard Guest 2011-01-13 20:43:00 UTC
Hmmm... I didn't do a very good job generating the patch, which may have caused it to get munged somewhere along the way.

The attached patch is against three files, but the build in koji has attempted to patch just the first file.

Comment 7 Richard Guest 2011-01-13 20:51:54 UTC
Created attachment 473424 [details]
A less munged patch against 0.8.7

Patching the following files:
rtorrent-0.8.7/src/command_network.cc
rtorrent-0.8.7/src/core/curl_stack.cc
rtorrent-0.8.7/src/main.cc

Comment 8 Conrad Meyer 2011-01-15 00:08:37 UTC
New patch seems to work fine.

http://koji.fedoraproject.org/koji/taskinfo?taskID=2722463

Comment 9 Fedora Update System 2011-01-29 13:03:23 UTC
rtorrent-0.8.7-4.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/rtorrent-0.8.7-4.fc14

Comment 10 Fedora Update System 2011-02-15 21:29:28 UTC
rtorrent-0.8.7-4.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 11 Conrad Meyer 2011-05-26 21:50:32 UTC
Hi Richard,

We've bumped to rtorrent 0.8.8 in rawhide and plan to push it to F-15 and F-14 as well; however, your https_insecure patch against 0.8.7 no longer applies against 0.8.8. If you still want this functionality, is there any chance you can update it to apply to 0.8.8? Otherwise we'll just drop it, sorry.

Comment 12 Richard Guest 2011-05-26 23:57:16 UTC
Thanks for the heads up Conrad - don't be sorry, it was only intended as a stop-gap measure.
The upstream bug is closed:fixed http://libtorrent.rakshasa.no/ticket/1402

Looking at the source, there appears to be an option network.http.ssl_verify_peer which will do the same thing.

Either ack -i or grep -ir for ssl_verify in src should show you similar lines to what I submitted in that patch.

I haven't had time to build and test the upstream changes, but I'm fairly certain it will have the same effect.

Feel free to close this ticket.

Comment 13 Richard Guest 2011-05-26 23:57:16 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
?GoAheadAndLogIn=1

Comment 14 Richard Guest 2011-05-26 23:59:30 UTC
Hmmm. Bit of a balls up trying to submit that comment while Bugzilla was down for upgrades...
Sorry about that!

Comment 15 Richard Guest 2011-05-26 23:59:30 UTC
Deleted Technical Notes Contents.

Old Contents:
?GoAheadAndLogIn=1

Comment 16 Conrad Meyer 2011-05-27 00:29:11 UTC
Ah, great. Ok, I won't worry about it then =).


Note You need to log in before you can comment on or make changes to this bug.