Re: [qubes-users] Can’t download large files
On Sat, Aug 8, 2020, 1:50 PM wrote: > Thanks for the reply. The system still prioritizes the tmp file even after > I change the settings and use a usb. Do you know any other command that can > disable the tmp folder? > Strange, I have never had any problem telling firefox where to download anything. You do have enough free space before starting the download? (e.g. df -H ) any volume has less than say 85% then you might want to grow that volume a little first. What you could try is to manually mount the USB volume on top of the Firefox tmp folder instead. Then that one directory will have that whole volume for that one temp directory/file. Alternately you can Google how to create a temp file in dom0 with 'truncate', create a loop device for it, and pass that device into the AppVM, format the volume ext4, and mount it where you need that extra space temporarily. If you look up how to upgrade a fedora template you can find the general instructions there to use as an example, only where you mount it will be different. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAJ5FDniH5CgNPXApSO4L5c%3DP3RC2nBF8NKZ2Pq2_Ynt28b2zDA%40mail.gmail.com.
Re: [qubes-users] Qubes dom0-update-guard script
On Sunday, 9 August 2020 04:22:02 UTC+8, awokd wrote: > > To stay in keeping with Qubes philosophy, at most dom0 should only run > jobs inside VMs and copy files between VMs. You don't want it to parse > results, but you could let dom0 copy/move output files to a separate VM, > then kick off a job to handle the parsing inside the destination VM. > > -- > - don't top post > Mailing list etiquette: > - trim quoted reply to only relevant portions > - when possible, copy and paste text instead of screenshots > So I'll have the users create an offline AppVM based on a clean Debian template, then have users point the script to it. Dom0 will copy the data from its 'rpm -qa' or 'yum list installed' to it, and also copy the Tor repodata from Whonix after it has been cross-checked there. The offline AppVM will then parse and cross-check the dom0 list and the repodata and return a result to dom0. Another option is to have the offline AppVM handle cross-checking between Tor and HTTPS repodata as well, so all Whonix does is fetch. Which sounds better? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e06fa923-9382-4823-bf03-7f511fabd0d3o%40googlegroups.com.
Re: [qubes-users] Playing Videos On Streaming Wesites
On 8/8/20 9:00 PM, Roland Forgel wrote: On 2020-08-07 13:16, Michael Carbone wrote: On 8/6/20 3:09 PM, Qubes wrote: Perhaps someone here can suggest something better than what I currently have. A default Firefox on a default Fedora-32 template does not play videos on something like Invidio.us. The video thumbnails display everything looks exactly as it should just the videos will not play. I've been scratching around and found that if I install the qt5-qtwebengine-freeworld package then videos play on various video streaming platforms, including Invidio.us. The 'problem' with having qt5-qtwebengine-freeworld installed in a fedora-32-media template (cloned from fedora-32), along with other bits of software , is it creates dependency issues. This causes trouble with the updater widget, it never goes away and it always displays updates for the fedora-32-media template. If the template is fully updated the widget will say it has outstanding updates. If you run through the process you get the output I have attached in the four files. This becomes endless. It is after having updated fedora-32-media several times and noticing the output of the update widget staying exactly the same that I ran 'sudo dnf upgrade' in a fedora-32-media terminal. Then seeing the below output. Instead of trying to fix this, which would likely mean I would have to install qt5-qtwebengine-freeworld in a dedicated template, the scenario I would like to avoid, is there perhaps a different package that I can install that also enables playing videos on streaming websites? [user@fedora-32-media ~]$ sudo dnf upgrade --refresh Fedora 32 openh264 (From Cisco) - x86_64 466 B/s | 986 B 00:02 Fedora Modular 32 - x86_64 6.3 kB/s | 16 kB 00:02 Fedora Modular 32 - x86_64 - Updates 6.3 kB/s | 16 kB 00:02 Fedora 32 - x86_64 - Updates 5.7 kB/s | 14 kB 00:02 Fedora 32 - x86_64 6.7 kB/s | 16 kB 00:02 Qubes OS Repository for VM (updates) 1.5 kB/s | 3.8 kB 00:02 RPM Fusion for Fedora 32 - Free 1.3 kB/s | 3.1 kB 00:02 RPM Fusion for Fedora 32 - Nonfree 1.4 kB/s | 2.9 kB 00:02 Dependencies resolved. Problem 1: package qt5-qtwebengine-freeworld-5.13.2-3.fc32.x86_64 requires qt5-qtbase(x86-64) = 5.13.2, but none of the providers can be installed - cannot install both qt5-qtbase-5.14.2-5.fc32.x86_64 and qt5-qtbase-5.13.2-4.fc32.x86_64 - cannot install both qt5-qtbase-5.13.2-4.fc32.x86_64 and qt5-qtbase-5.14.2-5.fc32.x86_64 - cannot install the best update candidate for package qt5-qtwebengine-freeworld-5.13.2-3.fc32.x86_64 - cannot install the best update candidate for package qt5-qtbase-5.13.2-4.fc32.x86_64 Problem 2: package vlc-core-1:3.0.9.2-3.fc32.x86_64 requires libdav1d.so.3()(64bit), but none of the providers can be installed - cannot install both libdav1d-0.7.1-1.fc32.x86_64 and libdav1d-0.5.2-2.fc32.x86_64 - cannot install both libdav1d-0.5.2-2.fc32.x86_64 and libdav1d-0.7.1-1.fc32.x86_64 - cannot install the best update candidate for package vlc-core-1:3.0.9.2-3.fc32.x86_64 - cannot install the best update candidate for package libdav1d-0.5.2-2.fc32.x86_64 Problem 3: package vlc-1:3.0.9.2-3.fc32.x86_64 requires libvlccore.so.9()(64bit), but none of the providers can be installed - package vlc-1:3.0.9.2-3.fc32.x86_64 requires vlc-core(x86-64) = 1:3.0.9.2-3.fc32, but none of the providers can be installed - package vlc-core-1:3.0.9.2-3.fc32.x86_64 requires libebml.so.4()(64bit), but none of the providers can be installed - cannot install both libebml-1.4.0-1.fc32.x86_64 and libebml-1.3.10-2.fc32.x86_64 - cannot install both libebml-1.3.10-2.fc32.x86_64 and libebml-1.4.0-1.fc32.x86_64 - cannot install the best update candidate for package vlc-1:3.0.9.2-3.fc32.x86_64 - cannot install the best update candidate for package libebml-1.3.10-2.fc32.x86_64 Problem 4: problem with installed package vlc-core-1:3.0.9.2-3.fc32.x86_64 - package vlc-core-1:3.0.9.2-3.fc32.x86_64 requires libmatroska.so.6()(64bit), but none of the providers can be installed - cannot install both libmatroska-1.6.0-1.fc32.x86_64 and libmatroska-1.5.2-2.fc32.x86_64 - cannot install both libmatroska-1.5.2-2.fc32.x86_64 and libmatroska-1.6.0-1.fc32.x86_64 - cannot install the best update candidate for package libmatroska-1.5.2-2.fc32.x86_64 Problem 5: problem with installed package qt5-qtwebengine-freeworld-5.13.2-3.fc32.x86_64 - package
Re: [qubes-users] Playing Videos On Streaming Wesites
On 8/7/20 7:16 PM, Michael Carbone wrote: On 8/6/20 3:09 PM, Qubes wrote: Perhaps someone here can suggest something better than what I currently have. A default Firefox on a default Fedora-32 template does not play videos on something like Invidio.us. The video thumbnails display everything looks exactly as it should just the videos will not play. I've been scratching around and found that if I install the qt5-qtwebengine-freeworld package then videos play on various video streaming platforms, including Invidio.us. The 'problem' with having qt5-qtwebengine-freeworld installed in a fedora-32-media template (cloned from fedora-32), along with other bits of software , is it creates dependency issues. This causes trouble with the updater widget, it never goes away and it always displays updates for the fedora-32-media template. If the template is fully updated the widget will say it has outstanding updates. If you run through the process you get the output I have attached in the four files. This becomes endless. It is after having updated fedora-32-media several times and noticing the output of the update widget staying exactly the same that I ran 'sudo dnf upgrade' in a fedora-32-media terminal. Then seeing the below output. Instead of trying to fix this, which would likely mean I would have to install qt5-qtwebengine-freeworld in a dedicated template, the scenario I would like to avoid, is there perhaps a different package that I can install that also enables playing videos on streaming websites? [user@fedora-32-media ~]$ sudo dnf upgrade --refresh Fedora 32 openh264 (From Cisco) - x86_64 466 B/s | 986 B 00:02 Fedora Modular 32 - x86_64 6.3 kB/s | 16 kB 00:02 Fedora Modular 32 - x86_64 - Updates 6.3 kB/s | 16 kB 00:02 Fedora 32 - x86_64 - Updates 5.7 kB/s | 14 kB 00:02 Fedora 32 - x86_64 6.7 kB/s | 16 kB 00:02 Qubes OS Repository for VM (updates) 1.5 kB/s | 3.8 kB 00:02 RPM Fusion for Fedora 32 - Free 1.3 kB/s | 3.1 kB 00:02 RPM Fusion for Fedora 32 - Nonfree 1.4 kB/s | 2.9 kB 00:02 Dependencies resolved. Problem 1: package qt5-qtwebengine-freeworld-5.13.2-3.fc32.x86_64 requires qt5-qtbase(x86-64) = 5.13.2, but none of the providers can be installed - cannot install both qt5-qtbase-5.14.2-5.fc32.x86_64 and qt5-qtbase-5.13.2-4.fc32.x86_64 - cannot install both qt5-qtbase-5.13.2-4.fc32.x86_64 and qt5-qtbase-5.14.2-5.fc32.x86_64 - cannot install the best update candidate for package qt5-qtwebengine-freeworld-5.13.2-3.fc32.x86_64 - cannot install the best update candidate for package qt5-qtbase-5.13.2-4.fc32.x86_64 Problem 2: package vlc-core-1:3.0.9.2-3.fc32.x86_64 requires libdav1d.so.3()(64bit), but none of the providers can be installed - cannot install both libdav1d-0.7.1-1.fc32.x86_64 and libdav1d-0.5.2-2.fc32.x86_64 - cannot install both libdav1d-0.5.2-2.fc32.x86_64 and libdav1d-0.7.1-1.fc32.x86_64 - cannot install the best update candidate for package vlc-core-1:3.0.9.2-3.fc32.x86_64 - cannot install the best update candidate for package libdav1d-0.5.2-2.fc32.x86_64 Problem 3: package vlc-1:3.0.9.2-3.fc32.x86_64 requires libvlccore.so.9()(64bit), but none of the providers can be installed - package vlc-1:3.0.9.2-3.fc32.x86_64 requires vlc-core(x86-64) = 1:3.0.9.2-3.fc32, but none of the providers can be installed - package vlc-core-1:3.0.9.2-3.fc32.x86_64 requires libebml.so.4()(64bit), but none of the providers can be installed - cannot install both libebml-1.4.0-1.fc32.x86_64 and libebml-1.3.10-2.fc32.x86_64 - cannot install both libebml-1.3.10-2.fc32.x86_64 and libebml-1.4.0-1.fc32.x86_64 - cannot install the best update candidate for package vlc-1:3.0.9.2-3.fc32.x86_64 - cannot install the best update candidate for package libebml-1.3.10-2.fc32.x86_64 Problem 4: problem with installed package vlc-core-1:3.0.9.2-3.fc32.x86_64 - package vlc-core-1:3.0.9.2-3.fc32.x86_64 requires libmatroska.so.6()(64bit), but none of the providers can be installed - cannot install both libmatroska-1.6.0-1.fc32.x86_64 and libmatroska-1.5.2-2.fc32.x86_64 - cannot install both libmatroska-1.5.2-2.fc32.x86_64 and libmatroska-1.6.0-1.fc32.x86_64 - cannot install the best update candidate for package libmatroska-1.5.2-2.fc32.x86_64 Problem 5: problem with installed package qt5-qtwebengine-freeworld-5.13.2-3.fc32.x86_64 - package qt5-qtwebengine-freeworld-5.13.2-3.fc32.x86_64 requires
Re: [qubes-users] Qubes dom0-update-guard script
fiftyfourthparal...@gmail.com: > I have Awokd, Chris, *and* Unman replying to my post--I feel pampered. It's an interesting security exercise; but agree, don't think our open source availability syncs up very often. :) > So the new overview of the script is: have a dedicated (and hardened?) tor > VM --basically, whonix-ws-- download the metadata from a few mirror sites, > compare them to the metadata from Tor, and if all checks out, compare the > tor version to the packages installed in dom0. If it doesn't check out, > alert user and ask whether to proceed. To do this entirely in dom0 (keeping > it safe and simple for a newbie at programming), I'm going to use qvm-run > with --pass-io somewhere in my script, along with something to read the > whonix output and run cross checks. To stay in keeping with Qubes philosophy, at most dom0 should only run jobs inside VMs and copy files between VMs. You don't want it to parse results, but you could let dom0 copy/move output files to a separate VM, then kick off a job to handle the parsing inside the destination VM. > A concern: I've noticed that a lot of Qubes mirrors are often offline. > Would this create vulnerabilities? Probably want your script to alert if under 3 reporting. -- - don't top post Mailing list etiquette: - trim quoted reply to only relevant portions - when possible, copy and paste text instead of screenshots -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/a705282f-bb56-3383-a840-bb9077b61a9c%40danwin1210.me.
Re: [qubes-users] Playing Videos On Streaming Wesites
On 2020-08-07 13:16, Michael Carbone wrote: > On 8/6/20 3:09 PM, Qubes wrote: >> Perhaps someone here can suggest something better than what I currently >> have. A default Firefox on a default Fedora-32 template does not play >> videos on something like Invidio.us. The video thumbnails display >> everything looks exactly as it should just the videos will not play. >> >> I've been scratching around and found that if I install the >> qt5-qtwebengine-freeworld package then videos play on various video >> streaming platforms, including Invidio.us. >> >> The 'problem' with having qt5-qtwebengine-freeworld installed in a >> fedora-32-media template (cloned from fedora-32), along with other bits >> of software , is it creates dependency issues. This causes trouble with >> the updater widget, it never goes away and it always displays updates >> for the fedora-32-media template. If the template is fully updated the >> widget will say it has outstanding updates. If you run through the >> process you get the output I have attached in the four files. This >> becomes endless. It is after having updated fedora-32-media several >> times and noticing the output of the update widget staying exactly the >> same that I ran 'sudo dnf upgrade' in a fedora-32-media terminal. Then >> seeing the below output. >> >> Instead of trying to fix this, which would likely mean I would have to >> install qt5-qtwebengine-freeworld in a dedicated template, the scenario >> I would like to avoid, is there perhaps a different package that I can >> install that also enables playing videos on streaming websites? >> >> >> [user@fedora-32-media ~]$ sudo dnf upgrade --refresh >> Fedora 32 openh264 (From Cisco) - x86_64 >> 466 B/s >> | 986 B 00:02 >> Fedora Modular 32 - x86_64 >> 6.3 kB/s >> | 16 kB 00:02 >> Fedora Modular 32 - x86_64 - Updates >> 6.3 kB/s >> | 16 kB 00:02 >> Fedora 32 - x86_64 - Updates >> 5.7 kB/s >> | 14 kB 00:02 >> Fedora 32 - x86_64 >> 6.7 kB/s >> | 16 kB 00:02 >> Qubes OS Repository for VM (updates) >> 1.5 kB/s >> | 3.8 kB 00:02 >> RPM Fusion for Fedora 32 - Free >> 1.3 kB/s >> | 3.1 kB 00:02 >> RPM Fusion for Fedora 32 - Nonfree >> 1.4 kB/s >> | 2.9 kB 00:02 >> Dependencies resolved. >> >> Problem 1: package qt5-qtwebengine-freeworld-5.13.2-3.fc32.x86_64 >> requires qt5-qtbase(x86-64) = 5.13.2, but none of the providers can be >> installed >> - cannot install both qt5-qtbase-5.14.2-5.fc32.x86_64 and >> qt5-qtbase-5.13.2-4.fc32.x86_64 >> - cannot install both qt5-qtbase-5.13.2-4.fc32.x86_64 and >> qt5-qtbase-5.14.2-5.fc32.x86_64 >> - cannot install the best update candidate for package >> qt5-qtwebengine-freeworld-5.13.2-3.fc32.x86_64 >> - cannot install the best update candidate for package >> qt5-qtbase-5.13.2-4.fc32.x86_64 >> Problem 2: package vlc-core-1:3.0.9.2-3.fc32.x86_64 requires >> libdav1d.so.3()(64bit), but none of the providers can be installed >> - cannot install both libdav1d-0.7.1-1.fc32.x86_64 and >> libdav1d-0.5.2-2.fc32.x86_64 >> - cannot install both libdav1d-0.5.2-2.fc32.x86_64 and >> libdav1d-0.7.1-1.fc32.x86_64 >> - cannot install the best update candidate for package >> vlc-core-1:3.0.9.2-3.fc32.x86_64 >> - cannot install the best update candidate for package >> libdav1d-0.5.2-2.fc32.x86_64 >> Problem 3: package vlc-1:3.0.9.2-3.fc32.x86_64 requires >> libvlccore.so.9()(64bit), but none of the providers can be installed >> - package vlc-1:3.0.9.2-3.fc32.x86_64 requires vlc-core(x86-64) = >> 1:3.0.9.2-3.fc32, but none of the providers can be installed >> - package vlc-core-1:3.0.9.2-3.fc32.x86_64 requires >> libebml.so.4()(64bit), but none of the providers can be installed >> - cannot install both libebml-1.4.0-1.fc32.x86_64 and >> libebml-1.3.10-2.fc32.x86_64 >> - cannot install both libebml-1.3.10-2.fc32.x86_64 and >> libebml-1.4.0-1.fc32.x86_64 >> - cannot install the best update candidate for package >> vlc-1:3.0.9.2-3.fc32.x86_64 >> - cannot install the best update candidate for package >> libebml-1.3.10-2.fc32.x86_64 >> Problem 4: problem with installed package vlc-core-1:3.0.9.2-3.fc32.x86_64 >> - package vlc-core-1:3.0.9.2-3.fc32.x86_64 requires >> libmatroska.so.6()(64bit), but none of the providers can be installed >> - cannot install both libmatroska-1.6.0-1.fc32.x86_64 and >> libmatroska-1.5.2-2.fc32.x86_64 >> - cannot install both libmatroska-1.5.2-2.fc32.x86_64 and >> libmatroska-1.6.0-1.fc32.x86_64 >> - cannot
Re: [qubes-users] Qubes dom0-update-guard script
On Saturday, 8 August 2020 20:51:25 UTC+8, unman wrote: > > Onion? Of course. > Check /etc/yum.repos.d/qubes-dom0.repo > Also, it's on mirror list at https://www.qubes-os.org/downloads, and has > been referenced on this list. > The repo is: > http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion > > What you should do is grab a few of those mirror sites, and compare the > metadata downloaded through Tor. i.e don't trust *any one* site, but look > at > them in the mass . > Just as you would with an iso or pgp key. > > unman > I have Awokd, Chris, *and* Unman replying to my post--I feel pampered. So the new overview of the script is: have a dedicated (and hardened?) tor VM --basically, whonix-ws-- download the metadata from a few mirror sites, compare them to the metadata from Tor, and if all checks out, compare the tor version to the packages installed in dom0. If it doesn't check out, alert user and ask whether to proceed. To do this entirely in dom0 (keeping it safe and simple for a newbie at programming), I'm going to use qvm-run with --pass-io somewhere in my script, along with something to read the whonix output and run cross checks. A concern: I've noticed that a lot of Qubes mirrors are often offline. Would this create vulnerabilities? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7cbe0823-78ff-4b71-b4ef-6a276a001805o%40googlegroups.com.
Re: [qubes-users] Qubes dom0-update-guard script
On Fri, Aug 07, 2020 at 09:07:39PM -0700, fiftyfourthparal...@gmail.com wrote: > On Saturday, 8 August 2020 06:38:38 UTC+8, Chris Laprise wrote: > > > > I think this is only properly done via a trusted .onion address, i2p > > address, etc... Unless Tor's DNS lookups have been improved since the > > last time I checked. > > > > Just for reference here, threat model I'm thinking of here is when an > > attacker tries to MiTM while having the cooperation of the certificate > > authority. > > > > -- > > Chris Laprise, tas...@posteo.net > > https://github.com/tasket > > https://twitter.com/ttaskett > > PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 > > > > Since dom0 can be updated via tor, is there an onion address? If not, what > would it take to make one or convince someone to make one? Without this > (since i2p is a whole can of worms I don't want to touch), the whole > exercise is meaningless. > > -- Onion? Of course. Check /etc/yum.repos.d/qubes-dom0.repo Also, it's on mirror list at https://www.qubes-os.org/downloads, and has been referenced on this list. The repo is: http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion What you should do is grab a few of those mirror sites, and compare the metadata downloaded through Tor. i.e don't trust *any one* site, but look at them in the mass . Just as you would with an iso or pgp key. unman -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200808125121.GA14753%40thirdeyesecurity.org.
