Welcome!
Important information
-- Spectre and Meltdown vulnerabilities
-- Change in MX sources

News
-- MX Linux on social media: here
-- Mepis support still here

Current releases
-- MX-17.1 Final release info here
-- antiX-17 release info here

New users
-- Please read this first, and don't forget to add system and hardware information to posts!
-- Here are the Forum Rules

MX 17 Repository: The Polo File Manager Thread

Message
Author
User avatar
asqwerth
Forum Guide
Forum Guide
Posts: 2795
Joined: Sun May 27, 2007 5:37 am

Re: MX 17 Repository: The Polo File Manager Thread

#21 Post by asqwerth » Sun Apr 15, 2018 11:18 am

Thanks. I'll explore this when I have more time after the next 2 weeks.

It will be great if I can choose just one-way copying - as in new files in my HDD not found in the NAS backup folder gets copied, but not the other way. I don't want my NAS and HDD folders to be exactly synchronised and mirrored.
Desktop: Intel i5-4460, 16GB RAM, Intel integrated graphics
Clevo N130WU-based Ultrabook: Intel i7-8550U (Kaby Lake R), 16GB RAM, Intel integrated graphics (UEFI)
ASUS X42D laptop: AMD Phenom II, 6GB RAM, Mobility Radeon HD 5400

User avatar
richb
Administrator
Posts: 16604
Joined: Wed Jul 12, 2006 2:17 pm

Re: MX 17 Repository: The Polo File Manager Thread

#22 Post by richb » Sun Apr 15, 2018 1:19 pm

That can be done.
Forum Rules
Guide - How to Ask for Help

Rich
SSD Production: MX 17.1
AMD A8 7600 FM2+ CPU R7 Graphics, 16 GIG Mem. Three Samsung EVO SSD's 250 GB, 350 GB HD

skidoo
Forum Regular
Forum Regular
Posts: 786
Joined: Tue Sep 22, 2015 6:56 pm

Re: MX 17 Repository: The Polo File Manager Thread

#23 Post by skidoo » Sun Apr 15, 2018 3:52 pm

.
We're witnessing a democritization of application packaging/distribution, and this "polo" exemplifies a scenario in which the end user(s) extend trust to the application developer... who, in turn, proxies trust to 3rd-party "plugin" maintainers, each of whom supplies a blob ~~ hosted on, and downloadable from, "gawd knows where".

Although we can discern the "where hosted" in the immediate example ~~ it's a security "house of cards" scenario, founded on trust and ripe for exploitation.
No facility to inspect wget|sudo -injected blobs whenever any of the plugins (potentially compromised) elects to push an "update"...
...but one can happily TRUST that's it's perfectly safe b/c it wasn't "downloaded from a PPA" ?!?

github.com/teejee2008/polo/debian/control
Package: polo-file-manager
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, libgee-0.8-2, . . . gvfs, gvfs-bin, gvfs-backends, wget
github.com/teejee2008/polo/...install-rclone.sh
echo "Downloading $zipFile"
wget "https://downloads.rclone.org/$zipFile"
. . .
unzip $zipFile
. . .
sudo cp rclone /usr/bin/
sudo chown root:root /usr/bin/rclone
sudo chmod 755 /usr/bin/rclone
===============
github.com/teejee2008/p7zip-installer...install.sh
if command -v sudo >/dev/null 2>&1; then
sudo "${SCRIPTPATH}/${SCRIPTNAME}"
EXIT $?
elif command -v su >/dev/null 2>&1; then
su -c "${SCRIPTPATH}/${SCRIPTNAME}"
EXIT $?
else
echo ""MSG_ERROR "** Installer must be run as Admin (using 'sudo' or 'su') **"
github.com/teejee2008/polo/...install-p7zip.sh
wget "https://github.com/teejee2008/p7zip-ins ... 2/$runFile"
. . .
echo "Installing binaries"
. . .
sh $runFile
v-----------^
https://github.com/teejee2008/p7zip-ins ... -amd64.run
v-----------^ "because reasons", the bulk of the content within the retrieved .run script (2.3MB!) is obfuscated within an eval() block
ahhhh, but one can happily TRUST that's it's perfectly safe b/c it wasn't "downloaded from a PPA" ?!?
Image

User avatar
Stevo
Forum Veteran
Forum Veteran
Posts: 15398
Joined: Fri Dec 15, 2006 8:07 pm

Re: MX 17 Repository: The Polo File Manager Thread

#24 Post by Stevo » Sun Apr 15, 2018 3:59 pm

Can anyone reproduce the Properties crash if they use the deb from the github Releases page instead?

User avatar
Stevo
Forum Veteran
Forum Veteran
Posts: 15398
Joined: Fri Dec 15, 2006 8:07 pm

Re: MX 17 Repository: The Polo File Manager Thread

#25 Post by Stevo » Sun Apr 15, 2018 4:09 pm

Skidoo, those scripts are in the source as a convenience for someone compiling and installing everything from scratch. We can install rclone, p7zip, etc. from the Debian repo instead. The package build doesn't download anything at all. I know this because pbuilder cuts off all Net access to the build environment during the build specifically to make sure that doesn't happen, because it's against Debian policy. The scripts aren't even in the finished packages. That's also why I had to make some changes to deb-multimedia's version of Handbrake, which does try to download its own libav-12.3 during the build.

However, your point does apply to TG's extra, donation-only Polo plugins. Then you have to trust Tony.

User avatar
Stevo
Forum Veteran
Forum Veteran
Posts: 15398
Joined: Fri Dec 15, 2006 8:07 pm

Re: MX 17 Repository: The Polo File Manager Thread

#26 Post by Stevo » Sun Apr 15, 2018 4:24 pm

bakedcookie wrote:Thank you, Steve. I use dh_make --createorig with dpkg-buildpackage -us -uc method.
It's easy to build. I might learn pbuilder from you later because I can't get the picture yet.
If you already made tutorial about pbuilder you can throw the link here.
I made a PDF of our Developer's forum thread about getting started with it, though adding a local repo for your own debs that pbuilder can also use seems hit and miss. It works fine for me...for Polo I first backported valac from Buster and copied all those debs into my local repo, and then pbuilder automatically picks those up for every valac build until I remove them. But you don't need that now that the new valac is in the test repo. I also have some edited commands that aren't in the thread, like this one to add the MX 17 main and test repos to the amd64 Stretch pbuilder...and to revert to vanilla Stretch you just delete the two MX repo lines and rerun the command. I have &&exit at the end so the terminal closes when done. Note that command is actually one long string, but I have backslashes to keep each repo on its own line to make them easy to add and remove in a text editor.

Code: Select all

sudo OS=debian DIST=stretch ARCH=amd64 pbuilder --update --override-config --othermirror "\
| deb [trusted=yes] http://ftp.us.debian.org/debian/ stretch-updates main contrib non-free\
| deb [trusted=yes] http://security.debian.org/ stretch/updates main  contrib  non-free\
| deb [trusted=yes] http://iso.mxrepo.com/mx/repo/ stretch main non-free\
| deb [trusted=yes] http://iso.mxrepo.com/mx/testrepo/ stretch test\
" && exit
Here's the thread and a sample pbuilderrc config file: https://drive.google.com/open?id=1Hxtnw ... ulotfXCqOl

skidoo
Forum Regular
Forum Regular
Posts: 786
Joined: Tue Sep 22, 2015 6:56 pm

Re: MX 17 Repository: The Polo File Manager Thread

#27 Post by skidoo » Sun Apr 15, 2018 10:25 pm

those scripts are in the source as a convenience for someone compiling and installing everything from scratch.
Although (for MX) the debian/conrol file could be modified to state Depends:rclone, the copy on github does not.

The makefile contains no reference to that "for convenience copy" of rclone (as you pointed out: the scripts aren't even in the finished packages)
Instead, the package installs a stubfile to /usr/share/polo/files/install-rclone.sh (ref src/Common/Main.vala) which, at runtime, performs wget https://downloads.rclone.org/...

> TG's extra, donation-only Polo plugins. Then you have to trust Tony.

That's fine. Given that those plugins are hosted on a server under his control, there's no proxied trust granted to a 3rd party.

Post Reply

Return to “Package Requests/Status - MX 17”