Control: noowner -1 Justification: lack of free time Hi,
On Thu, Oct 03, 2019 at 11:52:18PM -0400, Dev Null wrote: > On Sat, 21 Sep 2019 14:06:28 -0400 Nicholas D Steeves <[email protected]> > wrote: [snip] > > On Thu, Aug 31, 2017 at 10:07:25AM +0200, Jens Schmidt wrote: > > > Package: calibre > > > Version: 3.4.0+dfsg-1 > > > Severity: normal > > > > > > Dear Maintainer, > > > > > > I'm using cron and /usr/bin/ebook-convert to fetch RSS news daily. Some > > > generated ebooks are containing typos. The mistakes are located in a > so-called > > > "news fetching recipe" in Zip archive > /usr/share/calibre/builtin_recipes.zip. I > > > tried to edit the recipe code but the mistakes remain in ebooks. I > wrote an own > > > custom recipe, I edited built-in recipe in ZIP archive - nothing > helps. As a > > > last try I switched off network and had success. That maked me > curious, so I > > > repeated the procedures with Wireshark logging network traffic. The > result: > > > > > > Calibre completely ignores built-in recipes and loads python scripts > from a > > > server in Mumbai/India: https://code.calibre-ebook.com:443/... ( using > self- > > > signed wildcard certificate) > > > > > > It's a absolute taboo to load scripts in background from an untrusted > server > > > and execute them on a Linux computer without user permission and without > > > informing user. This is a Debian OS not Windows. What if the scripts are > > > containing malware or spyware? > > > > > > > Assuming good faith in the upstream, this is still a privacy breach, > > so I agree we ought to do something about this. Here is everywhere > > the this website is mentioned in the source code for debian/3.48.0+dfsg-1. > > > > $ ag code.calibre-ebook.com > > setup/linux-installer.py > > 644: 'https://code.calibre-ebook.com/tarball-info/' + > ('x86_64' if is64bit else 'i686')) > > 666: calibre_version = > urlopen('http://code.calibre-ebook.com/latest').read() > > > > setup/linux-installer.sh > > 693: 'https://code.calibre-ebook.com/tarball-info/' + > ('x86_64' if is64bit else 'i686')) > > 715: calibre_version = > urlopen('http://code.calibre-ebook.com/latest').read() > > > > src/calibre/ebooks/metadata/sources/update.py > > 95: 'https://code.calibre-ebook.com/metadata-sources/hashes.json') > > 112: raw = > get_https_resource_securely('https://code.calibre-ebook.com/metadata-sources/' > + name) > > > > src/calibre/gui2/dialogs/plugin_updater.py > > 28:SERVER = 'https://code.calibre-ebook.com/plugins/' > > > > src/calibre/gui2/store/loader.py > > 29:def download_updates(ver_map={}, > server='https://code.calibre-ebook.com'): > > > > src/calibre/gui2/update.py > > 24:URL = 'https://code.calibre-ebook.com/latest' > > > > src/calibre/gui2/icon_theme.py > > 48:BASE_URL = 'https://code.calibre-ebook.com/icon-themes/' > > > > src/calibre/utils/https.py > > 217: > print(get_https_resource_securely('https://code.calibre-ebook.com/latest')) > > > > Dear Maintainer, > > I hope I'm not following up on this bug too soon, but I'm curious as to > the status of this bug, as I am a current user of calibre. Are there any > changes either upstream or written by yourself to stop this third-party > code execution? > You're not following up on it too soon :-) As far as I know, nothing has been done yet, but I could be wrong. From what I can tell, the available options at this time is a patch to 1) present user with a warning yes||no confirmation box 2) disable the fetch & execution--I this would effectively break news fetching functionality if a news website changed, and would block access to the new news website options 3) Convince upstream to update in a more secure way. Given that they consider our package "buggy/outdated" and advocate a "wget -nv -O- https://foo.com/please-root-me.sh | sudo sh /dev/stdin" installation method I'm not sure how successful this will be. > I was notified of this bug during a routine 'apt-get upgrade' to the most > recent backported version of this program. (3.39.1+dfsg-3!bpo9+1) > Sorry that it's not possible to backport a newer version; that's not possible because the Calibre in testing requires a newer version of Qt5, and backporting that would break buster (Debian 10). Thus, blocked. From what I've been able to gather it's not possible to flatpak a Debian package, nor provide an appImage consisting of Debian packages, so it's starting to look like there are no good solution for buster... Maybe someone with experience containerising Debian packages in Docker could provide a solution; due to lack of free time it's unlikely I will be that person. I'm not sure how effective flatpak isolation is in Debian buster, nor who maintains this package, but a flatpak package for Calibre 4.22 does exist: https://www.flathub.org/apps/details/com.calibre_ebook.calibre Regards, Nicholas
signature.asc
Description: PGP signature
