From the 1.80 changes: "Fix vulnerability from maliciously-crafted torrent files that could overwrite other files" Note that 1.77 already had this: "Protect against potential data loss by maliciously-crafted torrent files" so this bug report probably supersedes bug #301039 in some way.
*** Bug 301771 has been marked as a duplicate of this bug. ***
Created attachment 217243 [details] transmission-1.80.ebuild This is transmission-1.76.ebuild fixed There's transmission-1.81.ebuild in bug : #301900
*** Bug 301965 has been marked as a duplicate of this bug. ***
I've been using transmission-1.82.ebuild from #301965 for some time without any issues now. I have not tested the qt4 or gtk clients however. The configuration file and init script needs to be updated with the new options such as incomplete folder and incomplete file extensions in 1.82. I use a customized version of the init script from 1.76 and symlinked in conf.d to the settings.json file that transmission-daemon actually uses for its settings.
(In reply to comment #4) > I use a > customized version of the init script from 1.76 and symlinked in conf.d to the > settings.json file that transmission-daemon actually uses for its settings. > You will probably never see that in gentoo as transmission needs an initial configuration to generate that file from, and also the init.d script does stuff (like run as another user and more) which transmission-daemon itself does not support, and the logic place to configure that is in conf.d.
The 1.82 ebuild, renamed to 1.83, compiles and installs fine on my AMD64 system.
Xake, I see your point. Transmission does however pick reasonable defaults for most of its parameters, except for the home/config directory where it creates its default settings.json and supporting configuration folder/files. It would be possible to pick/set a default home and transmission daemon user as a script variable in init.d and put a default settings.json file in conf.d and a symlink to this in the chosen transmission home. This could be done in install/postinst in the ebuild, however I could see that getting messy fast. The problems I ran into are a) the transmission-daemon startup params do not allow you to set all settings (might be changed in future transmission versions) and b) in 1.80+ you can send a SIGHUP to read changes to its settings.json while its running. However startup options in init.d overwrite these changes on any restart. This wouldn't be an issue if transmission-daemon used a regular linux conf file. Also, I'm not sure if bugzilla is the proper place for discussions about packages. Is there any better option for discussing package enhancements/changes?
(In reply to comment #7) > This wouldn't be an issue if transmission-daemon used a regular linux conf > file. Also, I'm not sure if bugzilla is the proper place for discussions about > packages. Is there any better option for discussing package > enhancements/changes? Well, if it is about the init.d/conf.d then a new bug I think would be appropriate, if you think that maybe some things should be changed in how upstream handles their config file, then upstream is your place.
Some changed to the ebuild: - dht is not optional anymore. - new use flags canberra, cli and daemon. - warning for cli being deprecated. - patch to remove libevent from configure and build. - added gconf as dependency. The patch is for the 1.82 ebuild from bug #301900.
Created attachment 217925 [details, diff] the patch for the ebuild.
Created attachment 217928 [details, diff] the patch to disable libevent
can you add the ebuild in portage please?
Any reason not to commit this? Saw a bump to 1.77 today which is an old version.
*transmission-1.77 (04 Feb 2010) 04 Feb 2010; Rémi Cardona <remi@gentoo.org> +transmission-1.77.ebuild: bump to 1.77
I bumped 1.77 because I needed that version, but newer versions could interest me as well. Is there a full 1.83 ebuild? Or a patch on top of 1.76/77? Attachment #217925 [details, diff] seems to be on top of 1.82... Cheers
Created attachment 218523 [details] Complete Transmission 1.83 ebuild
Seems the 1.83 patch was a patch against an ebuild buried in a closed ticket. Wow. I've attached a full 1.83 ebuild built from these. Tested and functional - QT and GTK
Attached ebuild is 218523
*** Bug 301039 has been marked as a duplicate of this bug. ***
> - warning for cli being deprecated. but, in 1.83 with USE="daemon -canberra -cli -gtk -libnotify -qt4" is there a way to create torrent via transmission-remote? LP
1.83 in Portage. Arch's, please test and stabilize: =net-p2p/transmission-1.83
stable for me on amd64
Samuli, how could you stable with transmission 1.83 being EAPI 3, while only 2.1.7.17 supports that and is in testing?
(In reply to comment #23) > Samuli, how could you stable with transmission 1.83 being EAPI 3, while only > 2.1.7.17 supports that and is in testing? > Didn't realize stable portage is outdated, downgraded the ebuild to EAPI=2.
x86 stable
amd64 stable
please update to 1.90, renamed ebuild from 1.83 works fine for me.
(In reply to comment #27) > please update to 1.90, renamed ebuild from 1.83 works fine for me. > Will not happen in this bug, as this bug is about bumping (done) and stabilizing transmission-1.83. Could someone change the Summary to reflect that change of status?
ppc ping.
CVE-2010-0012 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-0012): Directory traversal vulnerability in libtransmission/metainfo.c in Transmission 1.22, 1.34, 1.75, and 1.76 allows remote attackers to overwrite arbitrary files via a .. (dot dot) in a pathname within a .torrent file.
Sorry, marked ppc stable.
security: The oldest version available in the tree now is 1.92, close out this bug and do whatever cleanup you guys need to do.
Vote: NO (*very* unlikely to be ever exploited).
Actually I vote YES here.
GLSA Vote: Yes too. Request filed.
Ehm, those versions in this bug are gone from portage since long, making the oldest in portage 2.22 and stable since May 2011. So is it time to close this bug?
removing net-p2p@ and myself from CC due to nothing left to be done here for us, please readd us if needed
This issue has been fixed since Mar 09, 2010 and users have already been advised to update from GLSA 201006-06. No GLSA will be issued for this bug.
